How API Gateways help to improve your security - Nicolas Fränkel from API7.ai
Cloud CommuteApril 19, 2024
1
x
8
00:27:1624.97 MB

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

Nicolas Fränkel from API7.ai, the major company behind the Apache APISIX API gateway, talks about how APISIX helps you implement rate limiting, customer-specific behavior, and how API gateways in general help secure your APIs.

Editor's note: Sorry for the bad audio quality. The recording got messed up.

For questions, you can reach Nicolas at:

If you are interested in Apache APISIX and want to learn more:

The Cloud Commute Podcast is presented by simplyblock (https://www.simplyblock.io)


01:00:00
Regarding the others, I honestly

01:00:02
have no clue what's the pros and

01:00:05
the cons compared to

01:00:06
Apache APISIX, but I know that

01:00:08
Apache APISIX is the only truly

01:00:12
open source project, the

01:00:14
only one managed by

01:00:15
the Apache Foundation.

01:00:17
If you care about open source, not

01:00:20
because you love open source so

01:00:21
much, but you care about the

01:00:23
future of the project, you care

01:00:25
about long-term maintainability of

01:00:27
the project, then it's our

01:00:29
main benefit.

01:00:31
I won't talk about performance or

01:00:33
whatever, because, again, I didn't

01:00:34
do any benchmark myself, and

01:00:38
every benchmark that is provided

01:00:39
by any vendor can probably be

01:00:42
discarded out of the box directly,

01:00:44
because you should do your own

01:00:46
benchmark in your

01:00:47
own infrastructure.

01:00:52
You're listening to simplyblock's Cloud Commute Podcast,

01:00:55
your weekly 20 minute

01:00:56
podcast about cloud technologies,

01:00:58
Kubernetes, security,

01:00:59
sustainability, and more.

01:01:01
Hello, everyone.

01:01:02
Welcome back to the next episode

01:01:04
of simplyblock's Cloud Commute

01:01:05
podcast, your weekly

01:01:07
20-minute podcast

01:01:09
show about cloud, cloud security,

01:01:11
cloud storage, cloud

01:01:12
cloud cloud cloud Kubernetes.

01:01:16
Today I have Nicolas with me,

01:01:20
Nicolas Fränkel.

01:01:23
I think it's a

01:01:23
German last name, right?

01:01:24
It's a German last name.

01:01:26
I'm French, and it's spoken mostly

01:01:28
by English speaking,

01:01:30
so I don't care anymore.

01:01:32
All right, fair enough.

01:01:33
You can jump right into that.

01:01:36
Tell us a little bit about you,

01:01:37
where you're from,

01:01:39
why you have a German last name,

01:01:41
and being French,

01:01:45
and everything else.

01:01:46
I'm Nicolas Fränkel.

01:01:48
Yeah, I'm French.

01:01:50
I was born in France.

01:01:51
For a long time.

01:01:53
I was a consultant in different

01:01:56
roles, developer, architects,

01:01:59
cloud architect,

01:02:00
solution architect, whatever.

01:02:02
I worked in projects with crazy

01:02:06
deadlines, sometimes

01:02:07
stupid management, changing

01:02:09
requirements and stuff.

01:02:11
And so I got very

01:02:12
dissatisfied with it,

01:02:13
and since a couple of years now

01:02:15
I'm doing developer advocacy.

01:02:17
Right, right.

01:02:18
And we know each

01:02:19
other from the Java world,

01:02:20
so you've been a lot

01:02:21
around the Java community

01:02:23
for a long, long while.

01:02:25
Yeah, I think we

01:02:27
first met at conferences.

01:02:29
I don't remember which one,

01:02:30
because it was quite long ago,

01:02:32
but my main focus at the time was

01:02:35
Java and the JVM.

01:02:37
I think the first time was

01:02:38
actually still JavaOne

01:02:40
or something.

01:02:40
So people that know a little bit

01:02:42
of the Java space

01:02:43
and remember JavaOne, you can guess

01:02:46
how long this must be,

01:02:48
or how far this must be ago.

01:02:51
Right, so right now you're working

01:02:53
for a company called API7.

01:02:56
So API7 is a company that is

01:02:59
working on the Apache APISIX.

01:03:03
Yeah, I agree.

01:03:05
That's funny.

01:03:06
That was probably

01:03:07
designed by engineers

01:03:09
with no billboard marketing, but

01:03:11
it's still good,

01:03:12
because 7 is better than 6, right?

01:03:15
So Apache APISIX is an API gateway,

01:03:20
and it's an Apache

01:03:21
project, obviously.

01:03:22
All right, so you mentioned APISIX,

01:03:24
and you obviously

01:03:25
have the merch on you.

01:03:29
So API7 is like the

01:03:30
Python version, right?

01:03:31
It's one-based.

01:03:32
APISIX is the zero-based version.

01:03:35
We can argue which one is better.

01:03:37
And it's a bit more complicated.

01:03:39
So API7 is the company.

01:03:41
All right.

01:03:42
APISIX is the Apache

01:03:45
projects, but API7 also

01:03:48
has an offering called API7.

01:03:50
So either you have an API7

01:03:53
on-premise version

01:03:55
or an API7 cloud version.

01:03:58
Yet you can think about it just

01:04:00
like Confluent and Kafka.

01:04:02
Of course, again, API7, APISIX,

01:04:05
it's a bit confusing.

01:04:06
But just forget

01:04:07
about the numbering.

01:04:09
It's just Confluent and Kafka.

01:04:11
Confluent contributes

01:04:12
on Kafka, but still they

01:04:14
have their own offering.

01:04:15
They do support on

01:04:17
their own products,

01:04:19
and they also have an on-premise

01:04:21
and cloud version.

01:04:22
All right, so that means

01:04:23
that API7 as a company

01:04:25
basically has probably the

01:04:27
majority of engineers

01:04:28
working on APISIX, which itself is

01:04:31
a project in the Apache

01:04:33
Foundation, right?

01:04:35
I wouldn't say they

01:04:36
have the majority.

01:04:37
To be honest, I didn't check.

01:04:38
But regarding the

01:04:41
Apache Foundation,

01:04:42
in order for a project to be

01:04:46
promoted to top level,

01:04:48
you must uphold a

01:04:49
certain number of conditions.

01:04:52
So the process goes like this.

01:04:53
You go to the Apache Foundation,

01:04:55
you give the project,

01:04:56
and then you become

01:04:57
part of the incubator.

01:04:59
And in order to be promoted, you

01:05:01
need to, as I mentioned,

01:05:02
uphold a certain number of

01:05:03
conditions that I didn't check.

01:05:05
But one of them is you must have

01:05:07
enough committers

01:05:09
from different companies.

01:05:11
In order for one company not to be

01:05:15
the only driving

01:05:17
force behind the product, which in

01:05:19
my opinion is a good thing.

01:05:23
Whereas the CNCF,

01:05:25
the project is managed

01:05:28
by a company or

01:05:29
different companies.

01:05:31
In the Apache Foundation,

01:05:32
the granularity

01:05:33
is the contributor.

01:05:35
So a contributor can

01:05:36
afterwards, of course,

01:05:37
change company or whatever.

01:05:38
But in order to actually graduate

01:05:41
from the incubator,

01:05:43
you must have a

01:05:44
certain number of people

01:05:45
from different companies.

01:05:46
Yeah, OK.

01:05:47
That makes sense.

01:05:48
It's supposed to be more of a

01:05:49
community thing.

01:05:50
I think that is the big thing with

01:05:51
the Apache Foundation.

01:05:52
That's the whole point.

01:05:55
Yeah.

01:05:56
Also, I think also in comparison

01:05:57
or in difference

01:05:59
from the Eclipse Foundation, where

01:06:00
a lot of the projects

01:06:03
are basically company driven.

01:06:05
I don't know about Eclipse.

01:06:07
I know about this CNCF.

01:06:08
I heard that in order to give your

01:06:10
projects to the CNCF,

01:06:13
you need to pay them

01:06:14
money, which is a bit weird.

01:06:16
Again, I didn't proof-check that.

01:06:18
But it's company driven.

01:06:21
You talk to companies.

01:06:22
CNCF talk to companies.

01:06:24
Whereas the Apache

01:06:25
Foundation talk to people.

01:06:27
Yeah, OK.

01:06:28
Fair enough.

01:06:29
All right.

01:06:31
Let's see.

01:06:32
You said it's an API gateway.

01:06:35
So for the people that have not

01:06:37
used an API gateway

01:06:39
and have no

01:06:40
idea what that means--

01:06:41
and I think APISIX is a

01:06:42
little bit more than just

01:06:43
a standard gateway.

01:06:45
So maybe can you

01:06:46
elaborate a little bit?

01:06:48
You can think about an API gateway

01:06:50
as a reverse proxy on steroids

01:06:52
that allows you to do stuff

01:06:57
that is focused on APIs.

01:07:00
I always use the same

01:07:02
example of rate limiting.

01:07:04
Rate limiting has been a feature of

01:07:07
any reverse proxy since the 80s,

01:07:10
because you want to

01:07:11
protect your information

01:07:12
system from distributed denial of

01:07:15
service attacks.

01:07:18
The thing is, it works very well.

01:07:19
But then you need to consider

01:07:21
every one of your clients

01:07:23
the same.

01:07:24
So you rate limit

01:07:25
them exactly the same.

01:07:28
Now imagine you

01:07:29
are providing APIs.

01:07:31
Probably there is a

01:07:32
huge chance that you

01:07:34
will want to give

01:07:35
some offerings so

01:07:36
that a couple of customers can get

01:07:39
a higher limit than others.

01:07:41
And it means that you can do that

01:07:43
in a reverse proxy

01:07:44
probably, but you would need to

01:07:47
now add business logic

01:07:49
into the reverse proxy.

01:07:50
And as I mentioned, reverse proxy

01:07:52
were designed at a time where they

01:07:55
were completely, purely

01:07:56
technical.

01:07:57
They don't like

01:07:58
business logic so much.

01:08:00
Nothing would prevent you from

01:08:02
creating a C module

01:08:04
and put it in Nginx and do that.

01:08:07
But then you have or you encounter

01:08:09
a couple of issues.

01:08:10
The first one is the open source

01:08:12
version of Nginx.

01:08:13
If you need to

01:08:14
change the configuration,

01:08:15
you need to switch

01:08:16
it off and on again.

01:08:18
If it sits at the entrance of your

01:08:20
information system,

01:08:22
it's not great.

01:08:23
And now the business logic might

01:08:25
change every now and then

01:08:26
and probably quite

01:08:28
often, meaning it's not great.

01:08:31
That's why those technical

01:08:33
components, in general,

01:08:34
they are not happy

01:08:35
about business logic.

01:08:37
You want to move the

01:08:38
business logic away

01:08:39
from those components.

01:08:41
API gateways in my definition,

01:08:43
because we will find plenty

01:08:44
of definitions, first, you need to

01:08:48
change the configuration

01:08:49
dynamically.

01:08:50
You don't need to switch it then

01:08:51
off and on again.

01:08:53
And although you still don't want

01:08:56
to have too much

01:08:57
business logic, it's

01:08:59
not unfriendly to business logic,

01:09:01
meaning you can, for

01:09:02
example, in Apache APISIX,

01:09:05
you would create

01:09:05
your plugin in Lua,

01:09:08
and then you can

01:09:08
change the Lua code.

01:09:10
And then it's fine.

01:09:12
Right.

01:09:13
OK, so APISIX also uses Lua.

01:09:15
I think that seems to

01:09:16
be pretty much staple

01:09:18
along a lot of the

01:09:20
implementations.

01:09:22
Not really.

01:09:23
I mean, regarding

01:09:25
the architecture,

01:09:27
it's based on Nginx.

01:09:29
But as I mentioned,

01:09:30
Nginx is not great for that.

01:09:32
So on top of that, you have

01:09:33
something called OpenResty.

01:09:35
And OpenResty is actually Lua code

01:09:38
that allows you to change the

01:09:39
configuration of Nginx

01:09:41
dynamically.

01:09:42
The thing is, the configuration of

01:09:44
OpenResty itself

01:09:47
maps only one-to-one to the

01:09:48
configuration of Nginx.

01:09:50
So if you are doing it at scale,

01:09:52
it's not the best

01:09:55
maintainability ever.

01:09:56
So Apache APISIX

01:09:58
provides you with abstractions.

01:10:00
So what is an upstream?

01:10:02
What is a route?

01:10:03
Then you can reuse an upstream

01:10:05
across several routes.

01:10:06
What is a service?

01:10:08
And everything is plugin-based.

01:10:11
So it's easy for

01:10:12
routes to add a plugin,

01:10:13
to remove a plugin, to change the

01:10:15
configuration of plugin,

01:10:16
and so on and so forth.

01:10:18
Right, OK.

01:10:19
So from an

01:10:20
applications perspective,

01:10:21
or application

01:10:22
developer's perspective,

01:10:24
do I need to be aware of that?

01:10:25
Or does that all happen

01:10:26
transparently to me?

01:10:28
That's the thing.

01:10:30
It's an infrastructure component.

01:10:32
So normally, you

01:10:33
shouldn't care about it.

01:10:35
You mostly don't care about it.

01:10:38
Even better, in

01:10:40
general, a lot of stuff

01:10:42
that you would do with

01:10:43
frameworks or libraries

01:10:45
like Spring or

01:10:46
whatever, you can remove them

01:10:48
from every

01:10:49
individual app that you create

01:10:52
and put them in these entry points

01:10:54
at a very specific place.

01:10:57
So your

01:10:58
applications itself don't need

01:11:00
to protect the DDoS because the

01:11:02
API gateway will do it for you.

01:11:04
And you can also have

01:11:06
authentication, authorization,

01:11:09
caching, whatever.

01:11:10
You can mostly move all those

01:11:13
features away from your app,

01:11:16
focus on your business logic, and

01:11:18
just use the plugins

01:11:20
that you need.

01:11:22
Right, so you

01:11:23
mentioned authentication.

01:11:25
So I think it will hand me a JWT

01:11:27
token or whatever kind of thing.

01:11:30
For that we

01:11:32
have multiple plugins.

01:11:33
So yes, we have a JWT token.

01:11:36
We have a Keycloak

01:11:37
integration with a plugin.

01:11:40
We have OpenID Connect.

01:11:42
We have lots and lots of plugins.

01:11:44
And if it's plugin-based, then

01:11:46
nothing prevents you

01:11:47
from creating your own plugin.

01:11:49
So either to interface with one of

01:11:52
your own proprietary

01:11:54
authentication systems,

01:11:56
or if there is something

01:11:57
that you want that

01:11:58
is still generic,

01:12:00
and then you can

01:12:01
always contribute it back

01:12:03
to the Apache

01:12:03
Foundation, and then it

01:12:05
becomes part of the products.

01:12:07
And I mean, that's the

01:12:08
beauty of open source.

01:12:10
Yeah, I agree.

01:12:12
And I mean, we know

01:12:13
each other for a long time.

01:12:14
You know that I'm a

01:12:15
big fan of open source

01:12:17
for exactly all those reasons.

01:12:19
Also from a company perspective,

01:12:21
like a backing company,

01:12:23
like in this case, API7, I think

01:12:24
it makes a lot of sense.

01:12:25
Because you get--

01:12:27
I don't want to say

01:12:28
free help, but you

01:12:29
get people that love

01:12:32
your project, your product,

01:12:34
and that are willing and happy to

01:12:36
contribute as well.

01:12:38
Exactly.

01:12:39
I mean, we both

01:12:40
worked for Hazelcast,

01:12:42
although at different periods.

01:12:44
And that was open source.

01:12:46
But for me, this is the next step.

01:12:48
The product is not

01:12:50
only open source,

01:12:53
and open source

01:12:54
right at the moment

01:12:56
is very interesting moment,

01:12:58
because some companies are

01:13:00
afraid that your

01:13:00
product will be shrink-wrapped

01:13:02
by the cloud

01:13:03
provider, and they switch

01:13:04
to an open license, which is not

01:13:07
truly open source

01:13:08
according to the creo.

01:13:10
But the Apache

01:13:11
Foundation is fully open source.

01:13:14
So even if, for

01:13:16
whatever reason, API7

01:13:18
decides not to work

01:13:19
on the project anymore,

01:13:21
then you can still have the

01:13:22
project somewhere.

01:13:24
And if you find a

01:13:25
couple of maintainers,

01:13:26
it means it's still maintained.

01:13:29
So from a deployment perspective,

01:13:31
I guess I deploy that

01:13:32
into Kubernetes, or?

01:13:35
That's the thing.

01:13:35
It's not focused on Kubernetes.

01:13:40
So you can deploy that

01:13:42
in any cloud provider,

01:13:44
or even directly on

01:13:46
the machine you choose.

01:13:48
You have basically two modes.

01:13:50
The first mode is the one that you

01:13:55
would like to play with at first.

01:13:57
So you deploy your nodes, and then

01:14:00
you deploy etcd.

01:14:02
So the same one used by Kubernetes

01:14:04
to store its configuration.

01:14:05
It's a key-value

01:14:06
distributed store.

01:14:08
And then you can change the

01:14:10
configuration of APISIX

01:14:13
through an API call itself, and it

01:14:15
will store its configuration

01:14:17
in etcd.

01:14:18
Oh, I see.

01:14:19
And then it's very dynamic.

01:14:22
If you have more

01:14:24
maturity in GitOps,

01:14:26
if you have more

01:14:27
maturity in DevOps in general,

01:14:29
perhaps you will

01:14:30
notice that, oh, now where

01:14:33
is my configuration?

01:14:34
Well, in etcd.

01:14:35
But now I need to back it up.

01:14:38
How do I migrate?

01:14:42
I need to move the data from etcd

01:14:44
to another cluster.

01:14:45
So it's perhaps not the best

01:14:48
production-grade way.

01:14:50
So another way is to have

01:14:52
everything static in YAML file.

01:14:54
And then YAML-- yeah, YAML--

01:14:57
I'm sorry.

01:14:58
I hate YAML.

01:15:00
But at the moment,

01:15:01
everybody is using YAML,

01:15:03
and that's the configuration.

01:15:05
Like, at least Ops understand how

01:15:08
to operate that.

01:15:10
And so you have every node as its

01:15:12
own set of YAML file,

01:15:14
and then those YAML

01:15:15
files are synchronized

01:15:16
for GitOps to a

01:15:17
GitHub repository.

01:15:19
And then the GitHub repository is

01:15:21
the source of truth,

01:15:22
and it can be read, it can be

01:15:23
audited, it can be whatever.

01:15:25
Whereas if you store

01:15:26
everything in etcd,

01:15:28
it still works the

01:15:28
same way, but it's opaque.

01:15:30
You don't know

01:15:31
what happens, right?

01:15:33
I mean, the last thing you said

01:15:35
with the GitHub repository

01:15:38
being basically infrastructure as

01:15:41
code, source of truth,

01:15:44
that would probably then play into

01:15:46
something like ArgoCD

01:15:48
to deploy the updated version.

01:15:50
Right, OK.

01:15:51
That makes sense.

01:15:52
We don't enforce any products.

01:15:54
And actually, we

01:15:56
just provide a way

01:15:57
to statically

01:15:57
configure Apache APISIX,

01:16:00
and then you use

01:16:01
whatever product you want.

01:16:03
We are not partisan.

01:16:04
We just allow you to do it.

01:16:06
So from your own

01:16:07
feeling, what do you

01:16:08
think is the most common use case

01:16:10
why people would use API gateways?

01:16:13
Is that, as you

01:16:15
said, rate limiting?

01:16:16
I can see that as a

01:16:17
very common thing,

01:16:18
not only for

01:16:19
companies like X or Twitter

01:16:21
or whatever you want to call those

01:16:22
these days, but also GitHub.

01:16:25
I think every meaningful API has

01:16:27
some kind of a rate limit.

01:16:28
But I could also see DDoS attack,

01:16:30
whereas I think

01:16:31
people would probably

01:16:32
use Cloudflare or

01:16:34
any of these providers.

01:16:36
What do you think is the biggest

01:16:38
typical use case for that?

01:16:41
If you are using

01:16:42
APIs, you probably

01:16:43
need something more than just a

01:16:46
traditional reverse proxy.

01:16:47
If you are using a reverse proxy,

01:16:49
you are happy with

01:16:49
your reverse proxy.

01:16:51
You didn't hit any

01:16:52
limits of your reverse proxy.

01:16:54
Just keep using

01:16:54
your reverse proxy.

01:16:56
As I mentioned, once you

01:16:58
start to delve your feet

01:16:59
into the API world, you will

01:17:01
notice the reverse proxy

01:17:04
is as the features are. It has some of the

01:17:06
features that you want,

01:17:08
but perhaps not the ease or the

01:17:11
flexibility of configuration

01:17:12
that you want.

01:17:14
That said, you want to

01:17:15
consider different clients

01:17:17
in different ways.

01:17:19
In that case,

01:17:20
that's probably the time

01:17:22
where you need to think about, OK,

01:17:24
I need to think about

01:17:26
migrating to an API gateway.

01:17:30
But context are so

01:17:32
different that it's

01:17:33
very hard to provide a simple

01:17:36
solution that caters

01:17:38
to everybody's need.

01:17:39
But you could have a reverse proxy

01:17:42
at the entrance of your whole

01:17:44
information system.

01:17:45
And at the second level, you would

01:17:47
have the API gateway.

01:17:48
Or you could have an API gateway

01:17:51
for each different, I don't

01:17:53
know, domain of your organization,

01:17:57
because your

01:17:57
organization has different teams

01:17:59
for every domain.

01:18:02
And then, though it would be

01:18:03
possible to have one gateway

01:18:05
that is managed

01:18:06
by different teams,

01:18:08
then it makes a lot of sense to

01:18:10
have different teams managing

01:18:13
all their own configuration on

01:18:14
their own component.

01:18:16
Right, ok.

01:18:17
But it's like one micro-service.

01:18:20
So everybody

01:18:21
manages their own stuff.

01:18:23
And you are sure that nobody will

01:18:24
step on each other's foot.

01:18:26
But again, it

01:18:27
depends a lot on the size,

01:18:29
on how well you're

01:18:29
organized, on the maturity,

01:18:32
on many different things.

01:18:33
There are as many architectures as

01:18:35
probably organizations.

01:18:37
Right.

01:18:39
Just quickly, hinting back at

01:18:41
Kubernetes, I think when--

01:18:44
and I may be wrong here.

01:18:46
If I use APISIX, I do not need any

01:18:48
other ingress system,

01:18:49
because APISIX can be the ingress

01:18:51
provider for Kubernetes,

01:18:53
doesn't it?

01:18:54
So getting back to

01:18:55
Kubernetes, yes, we

01:18:56
have an ingress controller.

01:18:59
Or we have a hand chart.

01:19:00
You can install APISIX inside your

01:19:03
Kubernetes cluster.

01:19:05
And it will serve as

01:19:06
an ingress controller.

01:19:07
So you will have the ingress

01:19:09
controller itself.

01:19:11
And it will configure Apache APISIX

01:19:13
according to your manifests.

01:19:17
All right, cool.

01:19:18
So just looking at the time.

01:19:22
Yeah, 20 minutes is not a lot.

01:19:26
So when I want to use APISIX,

01:19:28
should I call you guys at API7

01:19:31
Or should I go with

01:19:32
the Apache project?

01:19:33
Or should I--

01:19:34
I don't know.

01:19:35
Do something else.

01:19:36
It depends.

01:19:39
No. I would always encourage

01:19:43
people, if you are a tech

01:19:46
person, to just take the project,

01:19:49
use the Docker container, for

01:19:50
example, try to play with it, try

01:19:53
to change if it's exactly

01:19:55
what you need, try to understand

01:19:57
the limits and the benefits in

01:19:59
your own organization.

01:20:01
Then if you've got questions,

01:20:03
we've got a Slack that I can send

01:20:06
you the reference, and

01:20:09
then you can start to ask

01:20:10
questions like, "Why in this case

01:20:12
I tried to do that, and

01:20:13
it works like this, and

01:20:15
I wanted it to do that?"

01:20:17
Then when you think that Apache

01:20:19
APISIX is the right solution, then

01:20:22
check if the open source

01:20:23
version is enough.

01:20:25
I believe if you are managing, if

01:20:29
you are running a company, you

01:20:31
will need to have some kind

01:20:32
of support at some points.

01:20:35
Up until that point, of course,

01:20:37
just use the open source version,

01:20:38
be happy with it.

01:20:41
If you want to use it in a

01:20:42
production-grade environment with

01:20:44
support, with guarantees,

01:20:46
and stuff, of

01:20:47
course, please call us.

01:20:49
It also pays my

01:20:50
salary, so it's also great.

01:20:53
You're welcome to play with the

01:20:56
open source version and to check

01:20:58
if it suits your requirements.

01:21:02
Before we come to the last

01:21:05
question, which is something I

01:21:06
always have to ask people,

01:21:08
maybe a quick

01:21:09
comparison to other products.

01:21:14
There are a lot of API gateways,

01:21:17
at least in air

01:21:18
quotes on the market.

01:21:20
Why is APISIX special?

01:21:23
First, every cloud provider comes

01:21:27
with its own API gateway.

01:21:33
My feeling is that all of them are

01:21:35
much better integrated, much more

01:21:39
limited in features.

01:21:42
Again, if it suits

01:21:43
you, then use them.

01:21:45
That's fine.

01:21:45
If you find yourself at some

01:21:47
point, you need to find

01:21:49
workarounds, then

01:21:50
perhaps it's time

01:21:50
to move away from them.

01:21:53
Then about the comparison, the

01:21:55
only really in-depth comparison

01:21:58
I've done so far is with

01:22:00
the Spring Cloud API gateway.

01:22:03
I have written a blog post, but in

01:22:05
short, if you are a

01:22:07
developer team using Spring,

01:22:10
knowing Spring, then use the

01:22:12
Spring Cloud API gateway.

01:22:13
It will be fine.

01:22:15
If you want an Ops team to operate

01:22:20
it, then probably it

01:22:22
won't be that great.

01:22:24
The basic level, you can do a lot

01:22:26
with YAML, and then you find

01:22:29
yourself needing to write

01:22:31
Java code.

01:22:33
Ops people, I'm sorry, but they

01:22:35
are not experts in

01:22:37
writing Java code.

01:22:38
You don't want to

01:22:38
have a compile phase.

01:22:41
Anyway, if you are a team, as I

01:22:45
mentioned before, if you are a

01:22:47
team, you manage your

01:22:48
own domain, you have only

01:22:50
developers or DevOps people, you

01:22:51
are familiar with Java, you are

01:22:53
expert in Spring, you want to only

01:22:55
manage your own stuff, then

01:22:57
perhaps it could be a

01:22:59
very good gateway for your needs.

01:23:01
Otherwise, I'm not

01:23:03
sure it's a great idea.

01:23:05
Regarding the others, I honestly

01:23:08
have no clue what's the pros and

01:23:11
the cons compared to

01:23:12
Apache APISIX, but I know that

01:23:14
Apache APISIX is the only truly

01:23:17
open source project, the

01:23:20
only one managed by

01:23:21
the Apache Foundation.

01:23:23
If you care about open source, not

01:23:25
because you love open source so

01:23:27
much, but you care about the

01:23:29
future of the project, you care

01:23:31
about long-term maintainability of

01:23:32
the project, then it's our

01:23:34
main benefit.

01:23:37
I won't talk about performance or

01:23:38
whatever, because, again, I didn't

01:23:40
do any benchmark myself, and

01:23:44
every benchmark that is provided

01:23:45
by any vendor can probably be

01:23:47
discarded out of the box directly,

01:23:50
because you should do your own

01:23:51
benchmark in your

01:23:52
own infrastructure.

01:23:56
Yeah.

01:23:56
I couldn't have

01:23:57
said that any better.

01:23:59
It's something that I keep telling

01:24:00
people when they ask, whatever

01:24:03
company you work for, there's

01:24:04
always people asking for

01:24:05
benchmarks, and it's always like,

01:24:07
don't believe benchmarks.

01:24:09
Even if a vendor is really honest

01:24:11
and tries to do meaningful

01:24:13
benchmarks, it's always an

01:24:15
artificial data set or whatever.

01:24:18
Run your own benchmarks, do it

01:24:21
with your own data set, do it with

01:24:22
your own operational behavior,

01:24:25
and figure it out for yourself.

01:24:27
We can help you, but you just

01:24:30
don't want to believe our

01:24:31
benchmarks.

01:24:32
Exactly.

01:24:33
Yeah.

01:24:34
All right.

01:24:34
Last question.

01:24:36
What do you think is the next big

01:24:38
thing or the current trend?

01:24:40
What is taking up right now in

01:24:42
Cloud, Kubernetes,

01:24:44
containers, API gateways?

01:24:47
I don't know.

01:24:48
What else?

01:24:49
Honestly, I'm very,

01:24:50
very bad at forecasts.

01:24:53
Really, a long time ago, I was

01:24:58
still a developer.

01:24:59
I was betting on

01:25:00
Flex, the Adobe Flex.

01:25:02
That was amazing.

01:25:03
Instead of having to cater for

01:25:08
each browser specific

01:25:10
implementation details, you would

01:25:12
just compile your stuff and it

01:25:15
would be rendered exactly the same

01:25:16
way on every browser.

01:25:18
Wait, you know

01:25:18
what happened, right?

01:25:20
Yeah, Steve Jobs just killed it.

01:25:24
I'm very bad at forecasts.

01:25:28
I can't imagine

01:25:30
what will happen next.

01:25:32
I think that we are going to see a

01:25:35
solidification on Kubernetes.

01:25:37
I mean, a lot of companies are

01:25:40
really seriously using it.

01:25:44
It's not going to be a toy

01:25:46
technology anymore.

01:25:47
Even a couple of years before, I'm

01:25:49
not sure it's a forecast.

01:25:51
It's already been going for a

01:25:53
couple of years.

01:25:56
I find it interesting

01:25:57
that Docker is coming back.

01:26:02
There was this Docker thing a

01:26:04
couple of years ago.

01:26:05
Everybody's saying

01:26:06
Docker is amazing.

01:26:08
Then it went, whoops.

01:26:11
I see they are trying

01:26:14
slowly to come back.

01:26:16
I don't know if it will be

01:26:17
successful or not, but I find it

01:26:19
interesting anyway.

01:26:22
On API Gateway, I have no clue.

01:26:25
All right. Fair enough.

01:26:26
You could have just went the same

01:26:27
way as everyone else and say, AI,

01:26:29
blah, AI here, AI.

01:26:32
Thank you very much.

01:26:34
We're unfortunately out of time.

01:26:36
It was a pleasure.

01:26:38
It was very interesting.

01:26:39
I haven't tried APISIX myself yet,

01:26:41
so I've actually learned quite a

01:26:43
few things, and I hope some of the

01:26:44
listeners did too.

01:26:47
Thank you very

01:26:48
much for being here.

01:26:49
Thanks a lot for your invite.

01:26:51
All right.

01:26:52
For the audience, next show next

01:26:54
week, or next episode next week,

01:26:57
hope you all will be

01:26:59
listening in again.

01:27:00
Thank you very much,

01:27:01
and see you next week.

01:27:03
The cloud commute podcast is sponsored by

01:27:05
simplyblock your own elastic

01:27:06
block storage engine for the cloud.

01:27:08
Get higher IOPS and low predictable

01:27:10
latency while bringing down your

01:27:11
total cost of ownership.

01:27:13
www.simplyblock.io