How API Gateways help to improve your security with Nicolas Fränkel from API7.ai

This interview is part of the Simplyblock Cloud Commute Podcast, available on Youtube, Spotify, iTunes/Apple Podcasts, Pandora, Samsung Podcasts, and our show site.

In this installment of the podcast, we talked to Nicolas Fränkel (X/Twitter) from API7.ai, the creator of Apache APISIX, a high-performance open-source API gateway, discusses the significance of choosing tools that fit your needs, and emphasizes making choices based on what works best for your requirements.

Chris Engelbert: Hello, everyone. Welcome back to the next episode of simplyblock's Cloud Commute podcast, your weekly 20-minute podcast show about cloud, cloud security, cloud storage, cloud Kubernetes. Today I have Nicolas with me, Nicolas Frankel. I think it's a German last name, right?

Nicolas Fränkel:  It's a German last name. I'm French, and it's spoken mostly by English speaking, so I don't care anymore.

Chris Engelbert: All right, fair enough. You can jump right into that. Tell us a little bit about you, where you're from, why you have a German last name, and being French, and everything else.

Nicolas Fränkel:  I'm Nicolas Frankel. Yeah, I'm French. I was born in France. For a long time, I was a consultant in different roles, developer, architects, cloud architect, solution architect, whatever. I worked in projects with crazy deadlines, sometimes stupid management, changing requirements and stuff. And so I got very dissatisfied with it, and since a couple of years now I'm doing developer advocacy.

Chris Engelbert: Right, right. And we know each other from the Java world, so you've been a lot around the Java community for a long, long while. 

Nicolas Fränkel:  Yeah, I think we first met at conferences. I don't remember which one, because it was quite long ago, but my main focus at the time was Java and the JVM.

Chris Engelbert: I think the first time was actually still JavaOne or something. So people that know a little bit of the Java space and remember JavaOne, you can guess how long this must be, or how far this must be ago. Right, so right now you're working for a company called API7.

Nicolas Fränkel:  So API7 is a company that is working on the Apache APISIX. Yeah, I agree. That's funny. That was probably designed by engineers with no billboard marketing, but it's still good, because 7 is better than 6, right? So Apache APISIX is an API gateway, and it's an Apache project, obviously.

Chris Engelbert: All right, so you mentioned APISIX, and you obviously have the merch on you. So API7 is like the Python version, right? It's one-based. APISIX is the zero-based version. We can argue which one is better.

Nicolas Fränkel:  it's a bit more complicated. So API7 is the company. All right. APISIX is the Apache projects, but API7 also has an offering called API7. So either you have an API7 on-premise version or an API7 cloud version. Yet you can think about it just like Confluent and Kafka. Of course, again, API7, APISIX, it's a bit confusing. But just forget about the numbering. It's just Confluent and Kafka. Confluent contributes on Kafka, but still they have their own offering. They do support on their own products, and they also have an on-premise and cloud version.

Chris Engelbert: All right, so that means that API7 as a company basically has probably the majority of engineers working on APISIX, which itself is a project in the Apache Foundation, right?

Nicolas Fränkel:  I wouldn't say they have the majority. To be honest, I didn't check. But regarding the Apache Foundation, in order for a project to be promoted to top level, you must uphold a certain number of conditions. So the process goes like this. You go to the Apache Foundation, you give the project, and then you become part of the incubator. And in order to be promoted, you need to, as I mentioned, uphold a certain number of conditions that I didn't check. But one of them is you must have enough committers from different companies. In order for one company not to be the only driving force behind the product, which in my opinion is a good thing. Whereas the CNCF, the project is managed by a company or different companies. In the Apache Foundation, the granularity is the contributor. So a contributor can afterwards, of course, change company or whatever. But in order to actually graduate from the incubator, you must have a certain number of people from different companies.

Chris Engelbert: Yeah, Ok. That makes sense. It's supposed to be more of a community thing. I think that is the big thing with the Apache Foundation. 

Nicolas Fränkel:  That's the whole point.

Chris Engelbert: Also, I think also in comparison or in difference from the Eclipse Foundation, where a lot of the projects are basically company driven.

Nicolas Fränkel:  I don't know about Eclipse. I know about this CNCF. I heard that in order to give your projects to the CNCF, you need to pay them money, which is a bit weird. Again, I didn't proof-check that. But it's company driven. You talk to companies. CNCF talk to companies. Whereas the Apache Foundation talk to people.

Chris Engelbert: Yeah, OK. Fair enough. All right. Let's see. You said it's an API gateway. So for the people that have not used an API gateway and have no idea what that means-- and I think APISIX is a little bit more than just a standard gateway. So maybe can you elaborate a little bit?

Nicolas Fränkel:  You can think about an API gateway as a reverse proxy on steroids that allows you to do stuff that is focused on APIs. I always use the same example of rate limiting. Rate limiting has been a feature of any reverse proxy since the 80s, because you want to protect your information system from distributed denial of service attacks. The thing is, it works very well. But then you need to consider every one of your clients the same. So you rate limit them exactly the same. Now imagine you are providing APIs. Probably there is a huge chance that you will want to give some offerings so that a couple of customers can get a higher limit than others. And it means that you can do that in a reverse proxy probably, but you would need to now add business logic into the reverse proxy. And as I mentioned, reverse proxy were designed at a time where they were completely, purely technical. They don't like business logic so much. Nothing would prevent you from creating a C module and put it in NGINX and do that. But then you have or you encounter a couple of issues. The first one is the open source version of NGINX. If you need to change the configuration, you need to switch it off and on again. If it sits at the entrance of your information system, it's not great. And now the business logic might change every now and then and probably quite often, meaning it's not great. That's why those technical components, in general, they are not happy about business logic. You want to move the business logic away from those components. API gateways in my definition, because we will find plenty of definitions, first, you need to change the configuration dynamically. You don't need to switch it then off and on again. And although you still don't want to have too much business logic, it's not unfriendly to business logic, meaning you can, for example, in Apache APISIX, you would create your plugin in Lua, and then you can change the Lua code. And then it's fine.

Chris Engelbert: Right. Ok, so APISIX also uses Lua. I think that seems to be pretty much stable along a lot of the implementations.

Nicolas Fränkel:  Not really. I mean, regarding the architecture, it's based on NGINX. But as I mentioned, NGINX is not great for that. So on top of that, you have something called OpenResty. And OpenResty is actually Lua code that allows you to change the configuration of NGINX dynamically. The thing is, the configuration of OpenResty itself maps only one-to-one to the configuration of NGINX. So if you are doing it at scale, it's not the best maintainability ever. So Apache APISIX provides you with abstractions. So what is an upstream? What is a route? Then you can reuse an upstream across several routes. What is a service? And everything is plugin-based. So it's easy for routes to add a plugin, to remove a plugin, to change the configuration of plugin, and so on and so forth.

Chris Engelbert: Right, So from an applications perspective, or application developer's perspective, do I need to be aware of that? Or does that all happen transparently to me?

Nicolas Fränkel:  That's the thing. It's an infrastructure component. So normally, you shouldn't care about it. You mostly don't care about it. Even better, in general, a lot of stuff that you would do with frameworks or libraries like Spring or whatever, you can remove them from every individual app that you create and put them in these entry points at a very specific place. So your applications itself don't need to protect the DDoS because the API gateway will do it for you. And you can also have authentication, authorization, caching, whatever. You can mostly move all those features away from your app, focus on your business logic, and just use the plugins that you need.

Chris Engelbert: Right, so you mentioned authentication. So I think it will hand me a JWT token or whatever kind of thing.

Nicolas Fränkel:  For that we have multiple plugins. So yes, we have a JWT token. We have a Keycloak integration with a plugin. We have OpenID Connect. We have lots and lots of plugins. And if it's plugin-based, then nothing prevents you from creating your own plugin. So either to interface with one of your own proprietary authentication systems, or if there is something that you want that is still generic, and then you can always contribute it back to the Apache Foundation, and then it becomes part of the products. And I mean, that's the beauty of open source. 

Chris Engelbert: Yeah, I agree. And I mean, we know each other for a long time. You know that I'm a big fan of open source for exactly all those reasons. Also from a company perspective, like a backing company, like in this case, API7, I think it makes a lot of sense. Because you get-- I don't want to say free help, but you get people that love your project, your product, and that are willing and happy to contribute as well.

Nicolas Fränkel:  Exactly. I mean, we both worked for Hazelcast, although at different periods. And that was open source. But for me, this is the next step. The product is not only open source, and open source right at the moment is very interesting moment, because some companies are afraid that your product will be shrink-wrapped by the cloud provider, and they switch to an open license, which is not truly open source according to the creo. But the Apache Foundation is fully open source. So even if, for whatever reason, API7 decides not to work on the project anymore, then you can still have the project somewhere. And if you find a couple of maintainers, it means it's still maintained.

Chris Engelbert: So from a deployment perspective, I guess I deploy that into Kubernetes, or?

Nicolas Fränkel:  That's the thing. It's not focused on Kubernetes. So you can deploy that in any cloud provider, or even directly on the machine you choose. You have basically two modes. The first mode is the one that you would like to play with at first. So you deploy your nodes, and then you deploy etcd. So the same one used by Kubernetes to store its configuration. It's a key-value distributed store. And then you can change the configuration of APISIX through an API call itself, and it will store its configuration in etcd. And then it's very dynamic. If you have more maturity in GitOps, if you have more maturity in DevOps in general, perhaps you will notice that, oh, now where is my configuration? Well, in etcd. But now I need to back it up. How do I migrate? I need to move the data from etcd to another cluster. So it's perhaps not the best production-grade way. So another way is to have everything static in YAML file. I hate YAML. But at the moment, everybody is using YAML, and that's the configuration. Like, at least Ops understand how to operate that. And so you have every node as its own set of YAML file, and then those YAML files are synchronized for GitOps to a GitHub repository. And then the GitHub repository is the source of truth, and it can be read, it can be audited, it can be whatever. Whereas if you store everything in etcd, it still works the same way, but it's opaque. You don't know what happens, right?

Chris Engelbert: I mean, the last thing you said with the GitHub repository being basically infrastructure as code, source of truth, that would probably then play into something like ArgoCD to deploy the updated version.

Nicolas Fränkel:  Right, Ok. That makes sense. We don't enforce any products. And actually, we just provide a way to statically configure Apache APISIX, and then you use whatever product you want. We are not partisan. We just allow you to do it.

Chris Engelbert: So from your own feeling, what do you think is the most common use case why people would use API gateways? Is that, as you said, rate limiting? I can see that as a very common thing, not only for companies like X or Twitter or whatever you want to call those these days, but also GitHub. I think every meaningful API has some kind of a rate limit. But I could also see DDoS attack, whereas I think people would probably use Cloudflare or any of these providers. What do you think is the biggest typical use case for that?

Nicolas Fränkel:  If you are using APIs, you probably need something more than just a traditional reverse proxy. If you are using a reverse proxy, you are happy with your reverse proxy. You didn't hit any limits of your reverse proxy. Just keep using your reverse proxy. As I mentioned, once you start to delve your feet into the API world, you will notice the reverse proxy is as the features are. It has some of the features that you want, but perhaps not the ease or the flexibility of configuration that you want. That said, you want to consider different clients in different ways. In that case, that's probably the time where you need to think about, Ok, I need to think about migrating to an API gateway. But context are so different that it's very hard to provide a simple solution that caters to everybody's need. But you could have a reverse proxy at the entrance of your whole information system. And at the second level, you would have the API gateway. Or you could have an API gateway for each different, I don't know, domain of your organization, because your organization has different teams for every domain. And then, though it would be possible to have one gateway that is managed by different teams, then it makes a lot of sense to have different teams managing all their own configuration on their own component. But it's like one micro-service. So everybody manages their own stuff. And you are sure that nobody will step on each other's foot. But again, it depends a lot on the size, on how well you're organized, on the maturity, on many different things. There are as many architectures as probably organizations.

Chris Engelbert: Just quickly, hinting back at Kubernetes, I think when-- and I may be wrong here. If I use APISIX, I do not need any other ingress system, because APISIX can be the ingress provider for Kubernetes, doesn't it?

Nicolas Fränkel:  So getting back to Kubernetes, yes, we have an ingress controller. Or we have a hand chart. You can install APISIX inside your Kubernetes cluster. And it will serve as an ingress controller. So you will have the ingress controller itself. And it will configure Apache APISIX according to your manifests.

Chris Engelbert: All right, cool. So just looking at the time. Yeah, 20 minutes is not a lot. So when I want to use APISIX, should I call you guys at API7 Or should I go with the Apache project? Or should I do something else.

Nicolas Fränkel:  It depends. I would always encourage people, if you are a tech person, to just take the project, use the Docker container, for example, try to play with it, try to change if it's exactly what you need, try to understand the limits and the benefits in your own organization. Then if you've got questions, we've got a Slack that I can send you the reference, and then you can start to ask questions like, "Why in this case I tried to do that, and it works like this, and I wanted it to do that?" Then when you think that Apache APISIX is the right solution, then check if the open source version is enough. I believe if you are managing, if you are running a company, you will need to have some kind of support at some points. Up until that point, of course, just use the open source version, be happy with it. If you want to use it in a production-grade environment with support, with guarantees, and stuff, of course, please call us. It also pays my salary, so it's also great. You're welcome to play with the open source version and to check if it suits your requirements.

Chris Engelbert: Before we come to the last question, which is something I always have to ask people, maybe a quick comparison to other products. There are a lot of API gateways, at least in air quotes on the market. Why is APISIX special?

Nicolas Fränkel:  First, every cloud provider comes with its own API gateway. My feeling is that all of them are much better integrated, much more limited in features. Again, if it suits you, then use them. That's fine. If you find yourself at some point, you need to find workarounds, then perhaps it's time to move away from them. Then about the comparison, the only really in-depth comparison I've done so far is with the Spring Cloud API gateway. I have written a blog post, but in short, if you are a developer team using Spring, knowing Spring, then use the Spring Cloud API gateway. It will be fine. If you want an Ops team to operate it, then probably it won't be that great. The basic level, you can do a lot with YAML, and then you find yourself needing to write Java code. Ops people, I'm sorry, but they are not experts in writing Java code. You don't want to have a compile phase. Anyway, if you are a team, as I mentioned before, if you are a team, you manage your own domain, you have only developers or DevOps people, you are familiar with Java, you are expert in Spring, you want to only manage your own stuff, then perhaps it could be a very good gateway for your needs. Otherwise, I'm not sure it's a great idea. Regarding the others, I honestly have no clue what's the pros and the cons compared to Apache APISIX, but I know that Apache APISIX is the only truly open source project, the only one managed by the Apache Foundation. If you care about open source, not because you love open source so much, but you care about the future of the project, you care about long-term maintainability of the project, then it's our main benefit. I won't talk about performance or whatever, because, again, I didn't do any benchmark myself, and every benchmark that is provided by any vendor can probably be discarded out of the box directly, because you should do your own benchmark in your own infrastructure.

Chris Engelbert: Yeah. I couldn't have said that any better. It's something that I keep telling people when they ask, whatever company you work for, there's always people asking for benchmarks, and it's always like, don't believe benchmarks. Even if a vendor is really honest and tries to do meaningful benchmarks, it’s always an artificial dataset or whatever. Run your own benchmarks, do it with your own datasets, operational behavior and figure it out yourself. We can help you but you just don’t want to believe your benchmarks or not.

Nicolas Fränkel:  Right. Exactly.

Chris Engelbert: Alright. Ok. So we're coming to the end of our episode. And something that I always ask everybody is if there's one thing that you think people should take away from our conversation today, what would that be?

Nicolas Fränkel:  I think the most important thing is that regardless of the project or the tool that you choose, that you choose it for the right reasons. As I mentioned, if you're using a cloud provider and if it suits your needs, then use it. If it doesn't suit your needs, if it's too limited, then don't hesitate to move away. The good thing with the cloud is that you're not stuck, right? And if you want a product that is focused on open source, and if you are in the open source space, I think Apache APISIX is a very good solution. And yeah, that's it. Always make choices that fit your needs. And it's good that you don't have just one choice, right? You have a couple of them.

Chris Engelbert: That's really well said. All right, so thank you very much, Nicolas, for being on the show. It was great having you.

Nicolas Fränkel: Thank you.