Hey friends. APIs are the foundational building
blocks of modern applications, and in today's world of API driven
development, your APIs are often spread across on-premises
and multi-cloud environments. Now you can use a self-hosted gateway
in Azure API Management on your infrastructure to control, secure,
and operate your API in a consistent way. Tom Kerkhove is here to show me how. Today on Azure Friday. Hey friends, it's Azure Friday. I'm here with Tom. How are you, sir? Thank you. I'm doing fine. How are you? I am excited to talk to you and excited
to learn about Azure API Management, which I have talked about before,
except not self-hosted. I actually don't know how
that would be possible If you've got a software as a service
that I've always thought of as being some of the secret sauce of Azure
and now I can host it anywhere. I'm fascinated to learn
how you made that happen. Now I'm happy to bring you that gateway
closer to where you want to use it. All right, let's hear about it. I understand you have a slide to give me
a sense of how this fits together. Yes. So if we have a high level view of API
management, there's three main components. We have the developer portal
where app developers can explore, try and use the APIs. We also have the management plan
where you can basically authored the APIs you want to expose to
who you want to expose, etc. And then we have the heart of
API management, which is basically the API gateway. So we have a couple of options
for these gateway where you can use a consumption gateway,
you can have a PaaS gateway and you can also now run
this as a self-hosted gateway where you basically want to run it. So if you have a closer look at the cloud
based approach is you basically open up
an API management instance and all your app users or integrators
talk to the gateway in the cloud, which then connects
to the various backends. However, in certain situations
you do not want to call Azure to go to, let's say,
another cloud or an inference system. Instead, what we do
is we allow you to bring the gateway closest to where your applications are so that you can reduce the latency,
increase the security, etc. while still using API management
because it is a federated solution. So you still offer
everything on the API management, but then these gateways
connect and synchronize serving the latest configuration
on your local infrastructure interest and all
that is totally disconnected solution. So this brings location
transparency to it, but also control of exactly
what gets in and out of my network. I have absolute control now. Yes, Correct. So if you're running completely on prem
and traffic cannot go outside of that boundary,
you can use our self-hosted gateway so that you still can benefit
from our API gateway without exposing it
to the public internet. So if you can self-hosted this, probably you've containerized the entire product
or a portion of the product. That must mean that you could self-hosted that gateway
like on your laptop as a developer. Yes. So that's also a big
plus for your developer experience is instead of always talking to the cloud,
I can now spin up a gateway. I can apply a policy on the cloud
and basically have that propagated to my machine and anchor it, integrate it
in your local testing as well. So it's a lot simpler now
to test your policies. It changes locally. I would love to see that. Yeah. So one of the benefits is that because it's a container,
you can basically run it anywhere. You can run in Docker, you can run it on
Kubernetes, you can run it on VMs with Docker, you can even run it on as a container on top of a case,
which we will see as well. So as you mentioned, it is a docker image. It is only for Linux and is available
in the Microsoft Container Registry. And the only requirement that we have
is that it needs to have an outbound connection to Azure, which should be fairly easy to set up from a security perspective
so that it can pull down the configuration and send telemetry to the cloud
if you want, because that is optional. It's also good to point out that
if it loses the connectivity to the cloud, your requests will not stop
working your gateway on prem or wherever it runs, be it on the ship,
even it will still work, but it will not have the latest
configuration. So there's no risk of having an outage
because it lost connectivity. You say that
it only needs outgoing connectivity. This may be an ignorant question on my part, but is there some kind of VPN
or mesh that is running on this? I mean, how are you able to do that over
just one port outgoing? Yeah. So basically the gateway is just talking
to our configuration API and checking
Are there any changes in the AIS? If you are, it is receiving them
and processing them so we don't have a connection from the cloud
because of security as well. Yes. Right.
So then it is truly self-hosted. So it bootstrapped itself with that
outgoing connectivity for the config and then it's just running. It's just a piece of azure in your
infrastructure that you control, correct? Yes. That's brilliant. I love it. And there's more we also have
with this gateway support for adapters. So we have adapter policies
so that if you have it running for example, on Kubernetes
or Azure Container apps, you can talk to these dapper applications
without having to know what that power is. You just use one of our policies
and it basically just works. And this is also an example
of a small difference between the cloud and self-hosted is
there is not 100% parity, there are differences,
but we're trying to close the gap as much. For example, Dapper is one
We also have open telemetry metrics for the self-hosted gateway because you have to run it,
so you also have to operate it and we want to give you that
transparency on how is the gateway doing? All right. Well, this makes it clear
how it's supposed to work. I'd love to see it work. Yes, I agree. Talk is cheap, so let's go to Azure. So I have here a pre-provision
API management instance, which is a premium tier. You can also use developer tier
where you have self-hosted gateway. Now I have some pre created APIs here on the left
where we will use the products API, which is just returning fixed
set of chase and payload. So if you have a look
it is talking to a monolith API on web apps, which is great. So actually what it does is it has a Get products API where for today
we want to get rid of this monolith. So even before we introduce
self was a gateway, we will do some traffic splitting
between the monolith and the future backend
which runs on Kubernetes. Later on. We will then run the self-hosted gateway
on that Kubernetes cluster instead. So how do we do this? So an API management,
you have the policies which allow you to basically extend your API traffic and in this case we will split the
traffic in a 50/50 faction. So here I have a policy where we generate a random Uralla numeral ID,
which is basically one or two, which is to generate a 50/50 split
if the value is one. We will not do anything
and use the default back end. If it is to, we will basically say,
hey, switch the traffic and send it to this other backend service
which points to a back and entity in API management,
which is called Product API or Kubernetes. So if I saved this, I can now talk to this managed Gateway by using the nice text test
explicit experience here. If I click send,
we will get a response back and you can already see that there is
some additional headers that I added based on the context properties
that we have. For starters,
we can see this is the managed gateway because there's no self-hosted yet. This instance is running in North Europe and my API management service is this one and the upstream URL is the monolith. So in this case I'm in the first bucket. If I do the call again,
I am in the same bucket. If I do the other call again, it fails. So this is not intentional, but this shows that it is talking to the say
to the other API. Now, while this is not intentional,
I can now also show that we have the trace capabilities
which help you troubleshoot these issues. So if I do another request
with the trace here, if we get a request to the other backend, we should see why it is failing. And here we can basically see the whole pipeline
that there request went through. So we can see that
they've got two requests and I will skip ahead where it is
basically generating the value. So here it is WAN and it is going to here send the request to the monolith. So this request was successful. So if I do it again, we will now see that hopefully
it went to the second backend here. We will now also see why it failed. This is why I am curious,
because this is not expected to fail. So we see it
successfully changes it to my back end on Kubernetes
and I can already see that it is using the local Kubernetes DNS,
which is why it is failing. I will skip the fix
for the sake of the demo, but you can already see that it is switching to traffic successfully
and we can add some headers to basically split the traffic. Now, if we want to run this gateway
ourself, we can go to a new resource in API management, which is called Gateway. So here you can create a gateway
which you can then self deploy. So I already created one
which is called Azure Friday and the location is Belgium because I live in Belgium
and this is where it becomes interesting. Here we have dedicated metrics
just for this single gateway, which are the same
as for the bridge Gateway. You can also see that I did some testing earlier today and I was doing fairly, fairly
nice amount of requests. We have the duration, etc.. And then the interesting point
is deployment. So all you need is a gateway token and the link to the configuration endpoint
and actually a build. We also released eight authentication. So instead of having this gateway token,
you can now also authenticate with an Azure
ad or enter application as well. And then we provide some nice deployment examples to get started. So Scarlett,
you asked about running Docker image locally, so let's just do it so I can basically copy this snippet and I can go to a new command line and I can basically just save that
to a local file. So let's do the cons, which I already have open. So let me go here. Save this and the columns. Let me copy the path
so that I don't forget. Then you can just come back and copy
the Docker command. We will use different ports. So let me go right to 80 grand
and then let's get rid of the second port. Give it a name maybe you can control, scroll
and make this image larger. There we go. Oh, I'm just running a regular docker
run command, which is going to spin up this image. And if you if you check the logs, you will you can see I made a typo. No. So happens to the best of us. So as with every Docker
image, you have to have the art. So that's where we start. And then you can basically see
the whole process of this gateway starting up, exposing some endpoints
for synchronization locally. And then it's
connecting to the configuration API and you can basically see
which policies are available, etc., etc.. You can see anything
that the gateway does. So now we have this up and running. I can just talk to it. So I already have this ready. So here I am talking to local hosts 8899 and I can just hit send. I have an API key here
and I get a response. I also get the same headers
that I had from the cloud, but now you can see that instead of managed, it is not managed. I can see the region as Belgium
and I get the gateway ID, but I am still talking to that cloud
backend. That's so cool. So at this point here
you can do anything right? Like it's just another container
or part of your orchestration. You could run all your telemetry
collectors, you could run Prometheus. You can you're a member of the team. Yes. So what we actually do ourselves
when we run, when we work on the south of, say, Gateway, is we also run it
as a container and we use Docker compose. So we also spin up Prometheus, open
telemetry call. After that, perhaps just add one command,
which is really super nice as a developer. Another thing to also point out is that by default
it does not expose any APIs. You basically have to opt in
for the APIs that you want to expose. So this basically gives you as an API
admin control on which gateway is deployed, where
and what is allowed to be exposed as well, which is also important for security. Now this is nice, Docker is fine for local development, but what if we use Kubernetes
for Kubernetes? We also give you a YAML file
that you can use. But let's not jump through hoops,
let's just make it simple and use. Hal So we also have an open source
helm chart which you can just deploy with this one command,
which is already pre-populated for you. We have various knobs for you to turn
if you want, and once you're ready you can just deploy this to your cluster. So I already went ahead and deployed this. So we're no longer in dock land. So it'll at all and you will see that when you install it by default, it already creates three paths
to ensure you're highly available. It installs the service 4 to 2
and basically talk to it. And also in discovery endpoints,
which is when you run multiple instances, they can synchronize the rate
limit information, etc. And this is what we install
just one deployment, two services and you're also good to go. So in theory, if you do a CTO logs for logs, you will see the same log style. It's the same logs basically. And you can
now talk to this gateway in the cloud. And actually I have some other tricks to show for the policies because we were still talking to that cloud back end. But instead we want to talk to the local
API that's running on Kubernetes. So we used to do this 50/50 traffic split. But what we will do now is
we will basically change the logic so that oops, right click save to fast. So instead, what we basically do
is we use this context property, which basically says
if I'm talking to the cloud, I want to use the default,
which is also based in the cloud. If I'm talking to the Kubernetes workload,
which is managed, I will switch to the Kubernetes workload,
which is using the Kubernetes DNS and sending traffic inside the
cluster so that we don't to go outside
of the cluster and come back in. We reduce the network, etc.. So I have here a similar request,
which is just a Kubernetes service exposed through a load
balancer on Kubernetes. I have the same API key and I hit send and I get a response back. Or we can see it's also the same gateway. I did not manage, etc.. But the interesting point is here,
so if you're familiar with Kubernetes, you will recognize that
this is a local Kubernetes DNS entry that just talked to the service
in another namespace right now, clusters local here
you're using internal DNS, correct. So if I would go back now to the cloud here, you will see that it keeps talking to the cloud one. Right. And North Europe is managed through. Correct. So this shows that you can basically shift
your traffic also based on the gateways that you have. While Kubernetes is great, why do you need to basically host your own cluster,
deploy apps, infrastructure, etc. if you don't want to do that, you can also run the same API
gateway on Azure Container apps. So that's when your apps are integrating. You can do that over an API
gateway as well. So I also have a container app created which is already running or self-hosted gateway. And as part of that I have Dapp arised the gateway
meaning in container apps. It is using dapper with an API and an app port. And on my container app environment, we also have a pop up component. So what we will now
do is for every request we will basically check
which gateway am I talking to because this has an other gateway idea
than the one on Kubernetes. If it is the one on container apps, we will also use the dapper policy
to queue a message. And if it is talking to Kubernetes,
we will just only talk to the to the API. So I have this ready already here and let me deploy this policy. So as they mentioned,
there's a couple of things here. First is we're checking,
are we using a managed gateway or not? If not,
then we check what the gateway ideas. If it is Azure Friday, that is the one
that runs on our Kubernetes cluster. And then we basically apply Heather and we change to the back end
that we were already using. If we are on container apps,
we are changing to another API,
which is hosted on the container wraps. We add the header, and then here we basically use a dapper policy to send the message
to a pop up subcomponent and the topic name is product
underscore request. And as part of that body,
we basically just add the subscription
that I used to authenticate. So once the context is in there,
you've got all the information that you need
to direct it however you want. Yes. So
we have the nice documentation page, so you get access to the user,
to the groups, to the API product. Basically anything
in the context of that request. So if I go here, this is my container app which is running our API gateway,
and if we click send, you can see similar things where I have the upstream header. Oh sorry, the upstream URL
which is another container app and you can also see oops, the deeper heather is not here, but you basically can also get access
to the response from the app and send that in the request as well
or your telemetry or whatever. So if I send a couple of requests,
this is going to queue messages for us which we will then find here on our surface bus. So if I do a receive, you will see that as part of this policy, it has just queued them by using dapper and I didn't have to know
how to do all of that. Just say publish to this pop up component. And we were good to go. So very cool. I hope you understand
this is available now. People can sign up right away. Can I? I'm already using API management. Can I just start using it
self-hosted correct itself for this game? You can just get started. It costs $1,000 per gateway resource and you can scale to as many instances
as you want. So it's fairly cheap to do that, but you have to manage the infrastructure,
right? Okay. And then all this flexibility that you
show me, whether it be deeper integration, other things that we've talked about
but haven't seen like metrics and open telemetry collector and manage
Prometheus all available to us once we're set up correct everything's ready today and I didn't show it yet but if you're also using application
insights, the same app
map functionality is available. So we will see all your various gateways and how they integrate
with the various back that they have. Very cool. Well, folks are going to able
to check all of that out in the docs. We've got links in the show notes on various topics on the comparison
between managed and self-hosted and all of the things that that Tom
has shown us and a few that he hasn't yet. Thanks so much for spending time with me
today. Thank you very much for having me. All right. This has been another episode
of Azure Friday. I'm learning all about managed APIs and
Azure API Management, self-hosted gateway Today on Azure Friday. Hey, thanks for watching
this episode of Azure Friday. Now I need you to like it. Comment on it.
Tell your friends. Retweet it. Watch more Azure Friday.
