 So, good evening everyone. So, I'm Ireland and most of you will know me as Padawan of Pathivodit. Yes, you'll always see me recording videos right here. So, now I think it's time to speak as well. So, the presentation for today is all about API Gateways in a nutshell. So, how many of you guys have been working with microservices? Cool. That's cool. So, just a little thing about me. So, I'm a simple guy that loves software architecture. So, I'm a cameraman for engineers SG. So, I'm a polyglot developer, meaning I code in C-Sharp, Java, Node.js. And then I Google better than an average graph. So, I'm not really smart at any of those. I'm just an average guy. And I'm quite active on Sack Overflow and I write my blog. Then, I'm the author of the API Gateway in a nutshell. So, it's an article that was referenced by Microsoft on its microservice articles. So, the resources that I use for this talk is the two books from the architecture guidance of API Microsoft, API Gateways for Microsoft, and some of the O'Reilly books. So, if you want to learn more about API Gateways, this session is all about simple introduction and the basic concepts that you can take about it. But, I'm not here to give the whole approach that you can use to build your API Gateways, because there are several use cases that there are several ways that you can use to build your own API Gateway. There are more approach that we will discuss today. So, the agenda of this talk is to explain what is the general concept of an API Gateway, the benefits that you reap out of the implementation tools and frameworks that you can use. And then, we'll have a little demo of Ocelot. Ocelot is like the open source API Gateway for building that net core base applications. And then, we'll see how that will help in API Gateway development and how Kubernetes helps in the third state management of your API cluster. And then, we'll also check the things that you want to consider when building API Gateways. So, how many of you guys are familiar with this? So, it's the International Space Station. So, when I was a young kid, I would always admire those people who built this thing because it's huge, it's big, it's just out there in the sky and it's mammoth. And if you think about how they built this thing, you'll end up wondering how did they do that thing? Because it's building this thing is complex already, right? Trying it to the sky is way more troublesome. So, apparently, what they did is they split this thing into several small pieces built by different countries. And then, what they did is they flew them one by one in the sky and then they assembled there. So, what's the lesson? Why did I tell you about this spacecraft ship that I just showed you? So, huge complex problems don't need huge complicated solutions. And sometimes, all you need is just a combination of small and simple solutions, right? So, in the world of microservices, I mean, software engineering, it's called microservices. And then, most of the people now want to build this thing but they always aim to build something elegant that looks like this wherein you have a client application contacting several APIs. But then, they'll end up with something that looks like this. So, what you see in the screen is called the Death Star FitWalk. So, it's an architectural anti-pattern wherein your application and microservices are coupled, highly coupled with each other. So, I changed on one service, it's completely dragging the other services down. So, it's basically bad because any form of coupling is very bad in software engineering. It's hard to make changes as well and the maintenance chaos that introduced is quite stressful. So, to solve the problem, smart architects introduced the concept of bounded context. So, bounded context is a mechanism that you can use to group your technical services, meaning the physical applications that behave together as a physical service from an outer point of view. So, this is how you group your services properly. But still, the problem of communicating with the APIs is still there, right? If you have an application, this kind of approach still won't work because there are several drawbacks that are related to it. So, the first issue associated with building microservices is that you have multiple points of contact, right? So, if you have multiple points of contact, you are leaking the domain knowledge of your application. So, if you have a client application and you have several bounded contexts in the background, it's quite difficult to make a change because an API team makes a change and the UI team is not yet done. So, it breaks the coupling or the contracts used, so your application will break. The next trouble that is associated with is that since you have multiple points of contact, you have multiple points of attack. When you expose several APIs and one of the teams forgot to set up the security policies of your organization, it's potential vulnerability. Then the next issue that you'll find is that how do I communicate with the seven APIs if I can only use one cookie, right? How do I communicate with seven APIs if I can have one JW2 token for a passport in JavaScript? So, it's quite troublesome, right? Then the next problem that you'll have is that you'll have to buy multiple SSL certificates and domain names. You'll have to deal with the cross-origin sharing. So, if some of you are already cross-issued or cross-origin sharing, it's a mechanism of the browser to depend on you from being attacked using cross-origins SSS attacks. So, when you are referencing a JavaScript or a resource from a domain that you don't, that is not identical with a domain that serves your website. It's not allowed by a browser to make communication unless the server allows you to do so. So, if you have seven or 10 APIs, it's troublesome to set this up, especially when there are several teams managing those APIs. So, like I said earlier, you'll also have tightly-coupled clients and APIs. So, how do we solve this? It's all about the API gateway. So, API gateway is an architectural pattern that allows you to have a single physical layer of contact from the outside world. So, what this job is that it aggregates your bounded context so that it can look like a single entity from the outside world. So, most of the people will compare and ask, isn't that a reverse proxy? Because how many of you guys have worked with reverse proxy so far? Reverse proxy, yeah? So, for those who are not aware, what is a reverse proxy? So, a reverse proxy is something that hides which server processes the request that was handled by an entry point in a cloud application. So, most of the people usually confuse API gateway with this one. So, just to crack what is the difference between an API gateway and a reverse proxy, reverse proxy is just a small thing inside your API gateway. There are more things inside that you can implement inside an API gateway. It's what you call rate limiting. So, it depends mechanism against the dos attacks. So, any form of logging, response application, caching and authentication. So, this is the power of API gateway. It's not a simple reverse proxy and there's a use case on why you want to use this. So, the benefits of using an API gateway is that, aside from solving the first five problems that I shared earlier, you will also have an added layer of security because if an attacker wants to penetrate one of your servers, he needs to go first against your API gateway. It doesn't, you don't have to expose those sensitive APIs that you usually go unauthenticated. So, you will also have a centralized place for implementing your cross-cutting concerns. So, how many of you guys are aware of cross-cutting concerns in software engineering? Yeah, so cross-cutting concerns are things that you want to be implemented on a single layer that is required by all of your applications. Let's say you have authentication. You don't want to repeat this for seven, the independent APIs and then if you want to do logging, API gateway is a perfect place to place this system. Then you can also have monitoring system side guard with your API gateway. You want to have circuit breaking, retries, SSL termination, whiteness thing and response aggregation. This is what you can put inside your API gateway. So, let's go now to what are your choices when implementing an API gateway. So, the first one is to consume a cloud management platform like Azure API management or EWS API gateways. Next one is a generic software. There are several softwares out there that perform API gateways and I'll share later which ones are them. Then you can also build your own API gateway using raw C-sharp and Java. I will explain what is the specific use case that requires this kind of approach later. And then you can also, my favorite one is using code and config hybrid. So, later I will also showcase this one. So, let's go first on cloud provider based API gateway. So, a cloud provider choice when implementing an API gateway helps you to quickly bootstrap an API gateway. So, if you all start up that don't have enough resources to build your own custom tailored API gateway, this is what you want to consume because in just a matter of an hour you'll be able to do and aggregate your APIs from the background. So, the one that I really like is Azure API management. This is a Windows Azure at the whole session. So, it's quite cool you need to give this a try because it allows you to perform the aggregation of your APIs, reverse proxying, versioning. So, how many of you guys have worked with APIs before? And do you have any experience wherein when you make a change in your API it breaks the client software when they went out there uninformed, right? Then you can also perform MAC responses. So, whenever you set up an API, you don't need to connect it with your data layer. With Azure API management you'll be able to MAC responses. Then you can also have your test console so that you can ping the API that you just set up. And you'll also have public and private APIs. If you're still working on an API, you can choose to make it private for the meantime. Then you can also set up a rate limiting policy. So, rate limiting policy. It's a defense mechanism that enables you to prevent leaders attacks. So, I won't go deeper into it and I wrote a single article that I'll share later about it. Then you can also have applications inside integration with telemetry in Azure. And then you'll also have live metric system. So, this is really cool because all you need to do is just pay around $50 per month and you'll have all of this in a sudden. So, what are the pros and cons of building your using cloud provider-based API gateway? So, let's start first with the pros so you can get up quickly. So, it's the cheapest solution out there because you don't need developers to build the gateway infrastructure itself. Then you also have white community support if you're having trouble with certain implementations. So, you can access it using, you can access help from Stack Overflow from Google and all these online things. And then it's especially good for startups. So, the points of this approach is that you're going to be married to Windows Azure or AWS which is something to consider. What if you're a startup that wants a temporary solution? Because later on you want to do your on-prem infrastructure. So, you just intend to build your cloud gateway for key four months and then switch to the on-prem infrastructure. This is the perfect use case for that one. And then it's also hard to migrate, especially if you're from Azure and you found something that some product offerings in AWS that you want to do, it's going to make it difficult because you need to set up your API gateway on the competitor cloud provider. Then of course, it's a generic thing that they built for general audience. You won't have all the limit features that you want to do. Then for financial institutions, you will also be facing compliance issues like are you allowed to expose your data? Are you allowed to expose certain endpoints? So, it's a thing to consider when using this approach. Then the next approach is to use generic software. So, it's either you use com or mix API gateway and GenX API gateway. So, com is the most dominant one and the most used one. So, somebody from the API crowd community gave a video which is like went viral in YouTube. So, you can search it as well. So, the pros and cons of using generic software is that you can also get up quickly. It's a semi-cheap solution since you need to provide your license. So, use this software and then it has smaller community support because the number one rule when building applications and cloud is that I mean in software engineering is that it's never cool. I did not build it. This is the general rule for developers. And then another pros of it is that you can install a lot of plugins. So, com has a spare notorious for this one and GenX is quite new in this market and I really like com for doing the generic software approach. So, the cons of this is that it's also hard to migrate. If you want to go to Azure you can spin up your VM but then how do you replicate or scale it efficiently? It's going to be trouble. So, then you will have limited features as well because open source things and things that are built by small companies are not that much feature rich by the way. Then you also face the risk of dying plugins. So, most of the time when the open source community stops building things you'll run into problems. Then you also have compliance issues because when you install generic software we never know what it does inside unless we have like good network policies that prevent unknown software from sending traffic outside of your application. So, it's a thing that you need to consider as well. So, the next one is to build your developer favorite which is build your own API gateway from scratch. So, it offers you the highest form of control. So, for example, HTTP2 was just recently released and you want to do server HTTP2 server push. You can implement it since you're the one coding the gateway in yourself. Then you can also have unlimited options since you're going to build it on your own as long as you can think of a solution that will aggregate the APIs. It's going to be a good approach. And then you don't need specializations like Azure API. You just need a guy that understands C-sharp and HTTP. You'll be able to build the coded API gateways. Then you'll have highly difficult solutions as well. Then you can build and ship what you only need. So, that's the main problem with generic and cloud providers. You're getting charged for things that you don't use. So, let's say you just want to aggregate things and you don't want to do certain stuff. You'll be paying for those things that you don't actually use. So, this is a very big issue for big companies. Then since you're going to build it, let's say you're a bank, it's really cool because you won't face any compliance issues because you're just doing raw Java and C-sharp and not JS. Then the cons of it is that of course it takes time to build API gateways don't grow on trees, so you need to build them yourself. And then it's expensive to build because you need developers and it takes time. And then it's a good thing about it that I consider because it's like an investment. So, when you build software, when you invest on good and higher form of control on what you do, you're more likely going to be able to maintain it properly in the long run if it's properly built. Then my favorite is a coded hybrid software. This, I think, is the most, is a better way than coding the thing manually. So, you can use frameworks like Express Gateway, Ocelot, and Sprint API gateways, which are really cool because you can perform simple configurations. I will show. So, this is a sample of configuration-based gateway, wherein you just define your downstream and upstream path. So, a downstream service is something that lives behind your API gateway. So, the gateway is the app considered as the upstream route. So, all you need to do is just define the upstream path and the HTTP method and then route it to the exact service that you want to target. So, for the first example above, this one, it's a configuration to set up an endpoint for retrieving users and user records into a specific port of an API URL. So, let's proceed to the slides. So, later on, it's a simple gateway that I have here as well. So, when building microservices, you don't want to build on a microservice approach right away. But you want to build this to a monolith at first because when you build a monolith, you'll be able to identify properly which things do we really need to extract into its own independent bounded context. You don't want to run into building microservices and then failing because you forgot some important concept behind it. So, the best approach to build microservices is to do stronger migration. So, stronger migration is an approach that is for migrating a monolith into microservice architecture by stripping your services and bounded context one by one. So, API gateway is very useful for this use case. So, if you see, in this most of the time, you want to extract your authentication API from your monolith and then you can do extract the next bounded context until you eliminate the whole, all this monolith at the end of the process. So, how Docker helps in API gateway development. So, Docker helps in API gateway development because let's say you have polyglot teams where a certain team specializes for Java and certain teams specializes on Node.js and you have a .NET team. For example, you have like libraries that you need to work with Microsoft systems. So, this is a perfect use case for ESP.NET core apps. If you're using some open source libraries for managing PDFs, you know, the licenses are very big factor and deciding if you want to use Java over .NET. Then you can also have Node.js systems. Then Docker helps you make this software running dependent of each other in same machine, same development machines and in your infrastructure in the cloud. Then you can also use the latest version of the application framework. So, let's say you use Node.js for everything, but let's say the ledger, I mean the authentication is built up front. I adopt the other bounded context. So, let's say that Node.js supports this specific process. So, you can build another microservice with Node 8 support in a way and Node 10 with HTTP2 support. You do Docker because you're not really lack of specific version of a framework that you would like to use. The next one is cluster desired state management with Kubernetes. So, Kubernetes is really cool for working with API gateways because it allows you to target your services in a fine grain passion. So, let's say that your authentication is getting it five times more than the other services, you'll be able to build your cluster with Kubernetes by just defining how many replica sets that you want for your authentication service. Then you can also define the certain number of instances for your ledger and catalog with Kubernetes. Then in case that your services are dying, this is a job of Kubernetes. So, if some Docker containers die, it is in charge of making it work again by spinning up new instances in replacement of the dead instances. Now, so everybody thinks that your gateway is already cool once you have Docker and Kubernetes running on your infrastructure. But actually, API gateways, there's a concept called path gateways. So, a path gateway is that it's a form of gateway that knows everything about your infrastructure. So, this is bad especially if you want to do some migration. So, let's say that you have a million HTTP hits per hour. So, how would I release another ledger service if I, what do you call this? If I have a million thousand hits? Because if I deploy and replace that one, the ledger service, all the hits that are occurring while I'm deploying are going to be lost. So, this is where Istio helps a lot. So, Istio is another, it's the new key in the block of containerization, which enables you to perform a certain set of deployment and governance in your clusters. So, Istio allows you to have an inventory and visibility of the services. Let's say you have 17 bounded contexts, you'll be able to know which ones are dying and which ones are running. You'll be able to know which ones are already sending 404s and 501s with the help of Istio. So, you can also mark the performance of your cluster in your staging environments by specifying some, all these rules that will allow you to add another layer of delay in the gateway in your staging environments. Then you can also have security policy management. So, you can prevent certain services from getting access by the API gateway if they're not needed to. Let's say you have endpoints that are required by your background jobs and not required by the gateway to be accessed. You can lock down those using Istio, which is really cool. And then you can also perform traffic management with Istio. Let's say that you want to deploy a new version of your application. You can spin out another cluster of Kubernetes up there and then just run an independent YAML file that will point your API gateway to the new version instead of the old version. You can retain that version without dropping it. And then in case that anything goes wrong in the new version, you can just roll back with Istio. So, it's really cool. And then you can also have native reliability. So, let's say that you have a polyglot team working on Node.js, Java, and Cshark. So, let's say that most of them are familiar with certain set of circuit breakers. So, circuit breakers are things that prevent the HTTP traffic flow whenever something is throwing a lot of exceptions from the downstream services. So, what if I want to do Python API that don't have any circuit breaking framework at all? So, this is going to be introduced by Istio. So, you don't need to build your circuit with the help of Istio. You don't need circuit breakers anymore. All you need to do is just install and enable the picture using YAML files and it will spin up the generic circuit breakers for all the independent teams. So, you don't need to know, let's say that most of your developers are writing circuit breakers and it tries. So, you can just prevent them from writing those and just upload the workload from the level 3 networking using Istio. Then, you can also test your system's reliability with the help of Istio by introducing what you call this, the network delays that are intended using Chaos Engineering. So, Chaos Monkey by Netflix is a really good help when performing this one. So, Istio can help you do canary deployments and say, you want to release your new pictures for Asian users instead of releasing it globally. Istio will help you do canary deployments. There are several tutorials out there that will help you see this one. Then, you also have blue-green deployments that say that this is a specific use case that I was referring to earlier where you can release the version 2 of your application without disturbing the HTTP traffic and then just executing command to reroute all of this traffic to the ledger version 2. Then, of course, API gateways are not a silver bullet. It has its own set of cons, which is like it's another set of cons that you need to deal with. It adds a little communication latency and then you need highly matured teams to operate this kind of architecture. So, another thing and the biggest thing to watch out when doing API gateways is that in it tends to replace the old monolith to be a configuration monolith in front. So, because let's say that the ledger team will release a new version of their API. So, how do I disturb the gateway? How do I deploy a new gateway? It becomes a thing, right? And let's say that I want to make some changes for my desktop app and not for the mobile users. So, this one is troublesome to deal with when you have an API gateway. So, the approach that Microsoft and most of the architects suggest to solve this is to use back-end support components. So, back-end support components is a set of, it's an architectural pattern that encourages the development of multiple gateways for client apps. So, the gateways should be coupled to your client so that it can, you can release without disturbing other client apps that say you have a mobile application that you don't want to break. Let's say that you want to release for desktop version first. You can do this approach, which is BFF. So, does anybody have a question? Usually, com in mix, they provide you some open source, I mean com is an open source API gateway, but they also offer higher level of usage of com, which is, which provides like dashboard and monitoring tools. So, com itself is open source, but if you want to use the premium version of it, you need to pay for that. So, it will like give you the full monitoring style. Yeah, so, it has its own pros and cons. So, I also built an application running right now. So, I have a running set of API gateways for me just that I built before the talk. So, let's see them. Yeah, so, I have them running on my local machine. So, I have three running services right now on my machine, which is the ledger service, authentication service, and a catalog service. So, let's try to hit one of my services from the background. So, it's the user. So, what this does is that it returns to you the list of users. So, you will see, I'll try to hit the endpoint of the gateway. Pay attention to the port of this guy, which is 52792. So, basically, it's just a simple reverse proxy that I set up earlier, but then it gets interesting once you can perform response aggregation. So, how many of you have worked with an application that had to deal with multiple endpoints for just for loading a single page? Yeah. So, basically, let's say you have a profile page where you want to see the user report and all the transactions that he had to meet. Most applications will perform two separate HTTP requests, right? With the help of an API gateway, you can aggregate this course using one single HTTP transaction. This proves to be really valuable, especially if the server is located on a different geographical location. Let's say a client in Asia wants to do HTTP transactions with the EU-based server. So, if you do this, if you do the first approach where you want to hit the server with two calls, it takes you the latency of communication from Asia to Europe, right? Which is like very expensive. But if you make one single request through an API gateway, it becomes more cheaper. So, earlier I showed an endpoint for hitting the user, right? User endpoint. So, this is the endpoint for hitting transaction list. So, what I'll do is that I'll aggregate it using an API gateway. So, if you check the approach earlier that I showcase, configuration, you'll see something that looks like this. So, basically, I have set up a route for redirecting the HTTP request for a user record. And I also set up one more hitting the transaction records of a user. So, it looks like this. So, if you set up two routes with keys, with the help of Ocelot, you'll be able to set up an aggregated route that looks like this. So, basically, there's no single backing endpoint. It's just an aggregation of the reroute keys that I set up on top of the file. And then you can just hit this upstream path and provide the parameter on it. So, there you go. We have the aggregated route of the two routes that I showcase earlier. It's really cool. So, does anybody have any questions? So, the route configuration you configured via files, right? Is there any way to configure it in dynamic? Sorry? The route configuration you are doing in the old way. Yeah, fine. You can't do that in the old configuration. Ah, yeah, it's a JSON. Okay, it's a JSON thing, right? Yeah. Is there any way to dynamically configure via IUI? With the approach that I use, which is like a hybrid config and code approach, right down there's not. But you can do it with the API management in Azure, which is like very cool. What is approach, right? How we dynamically add other endpoints? Other endpoints. So, you can, there are two sets of configurations that you can set up with Ocelot. The first one is the static routes or the manual routes that you want that I set up. So, static route looks like this one. So, I know the exact endpoint that I want to hit. So, this one. So, in this endpoint, I know that I want to hit the specific user profile endpoint from the downstream service located at 45792. So, with the dynamic route, you can just use a wildcard that says everything that is starting with API slash user redirect them to this specific downstream path. So, there are Ocelot manuals that will help you configure this, but I don't know the specific demo at the moment of doing this. But it's actually a good question for configuration in this approach. Yeah. Are we okay or good already? Thank you for attending and I'm sorry if I'm kind of nervous today because it's my first time to share. And so, I really appreciate you spending time with me tonight. Thank you. Thank you all. Thank you to all the likeers at the bottom. It's a great question.