API Gateway explained

hi developers and for some d'lai Microsoft MVP in this light burst session I'll give you an overview about the API gateway so we'll see what is an API gateway how we can use it enter the context of micro-services architecture and what are the benefits and the drawbacks of such an approach in terms of security and latency for our application so let's get started well we are developing software application using micro services you might have actually different micro services so might have micro service number one responsible for the catalog services for example so let's draw this one right here so this is my macro service number one I might have another micro service responsible for the products pricing for example so this is gonna be my micro service number two and I might have many micro services hundreds or dozens of micro services so let's say this one is my micro service number n and from our application we want to connect to those micro services we might have different types of applications what we call front ends so we might have web application like a spa application based on react or UGS or angular or we might have also mobile applications so anything that could be a front-end application here let's take the example of having a web app so let's draw that here and this year I have my web app represented us this is the front-end for my application and those are my micro services or my back-end actually you from the front-end application if I want to connect to those different micro services than here I can use direct connection from the web up to the micro service so if the web app wants to get the list of the products from micro service number one it will connect directly to that micro service and get the response back to web app but if in addition to that information it wants to get the pricing for each product then it needs to create another connection for micro service number two and get their spins back this means that those micro services should be exposed publicly to my front end which also means that here I need to have public IP for each micro service so for my micro service number one and have public IP and also each one of my micro services should have a public ID with the port number this means that those micro services will be exposed publicly through the internet they will be exposed to the hackers so this is a security issue let's mention that here in addition to this security issue because of exposing to public IP addresses to the to the internet we'll have another problem actually we said if web app needs to get information from two three or five different micro services then needs to create a first connection to the micro service number one get the rest - back then create a second connection to microservice number two get the response back and the same for my five micro services then at the level of the web app at the end of those five micro service calls it will aggregate the data inside the web app so this is lots of connections between the web app to the micro services and we want to reduce this number of connections in order to to have less latency inside our application so that's the second point that we want to address with the API a gateway it's the latency of the requests so as we said here the solution would be simply using the API gateway so what is an API gateway so as we said here for the web app to connect to those different micro services it needs to know their IP addresses so it's caplet to do their or traduce micro services with their IP address so instead of having the direct connection between the web app and the micro service what we'll do here is that we introduce a mid there and then in the middle here which will be the API gateway so here we introduced something let's say it could be another micro service at middle right here so we'll add another component and this one is the API gateway it's basically another micro service that the app should go through it in order to call those different micro services so if here I have a request from my web app to get information from those micro services don't want to go directly to the micro service but needs to pass through the API gateway so basically an API gateway is like a reverse proxy that will get the client request and redirect it to the to the micro service that the web app wants to connect to so it will just get that request then redirected to the forum micro service if it gets the response back from that micro service the response back will will get back to the API gateway then the API gateway will return that response to the web app so here we'll have a response this is the basic functionality of an API gateway it gets the request from the web app redirect them to the micro service then get back the resonance to the web app this basic feature the reverse proxy solves the problem of security how because here we don't need to have those IPS as exposed as public IPS over the internet but because the API gateway and those micro services could live inside one a network and that network could be secured so all loose as part of my back-end could live inside inside one network so let's draw that here so let's say this part could live inside a secured Network which means that loose IP addresses will be private IP addresses and the only IP address that will expose here is the one for the API gateway so here this will be a public IP address so that the web app could retrieve the API gateway through its IP address and now the API gateway and those micro services could live inside the same platform or they could use a shared network Afra structure in order to communicate together and a private network so those IP addresses will be private and then they are not accessible to the public Internet so this solves the problem of security for the micro services so we'll have less surface for attackers in order to attack our micro services they need if they want to access my system then they need to go through the API gateway I only have one publicly exposed IP address instead of all the IP addresses for my micro service so that enhances security for my app so here security will be solved by using the private IP now for the second problem for the latency of those requests coming from the web up to the different micro services if we don't have IP a gateway now actually with the API gateway the client or the front end needs only to send one request to the API gateway and it's up to the API gateway to know from where to get the data from those different micro services so here for the sample of getting the products details with their prices a first request could go to the micro service number one we get back the part of the data right here the details for the product then a second request could be issued by the API gateway to the micro service number to another to get the pricing for the products and we can have as many requests as we want here and the data will be aggregated at this level at the level of the API gateway so here we create the view model that contains not only the product details but contains also and the pricing for their products and here the residents will get back to the Web API so what we what have changed it here is that instead of the web up standing multiple requests to the different micro services then aggregating the data at the web app level now the data or the requests will be stand through the API gateway so here we'll have less latency than previously with the web app sending the request is directly to the micro service because as we said this could live inside the same network and this is a server component so here we have good internet connection so the API gateway could aggregate data at this level so that's why here instead of having the latency between different and the backend here we'll have we can use the aggregate pattern in order to to reduce the latency of the requests so with the an API gateway we will have those two main benefits and hence the security and latency for our micro services but when we implemented the API gateway we saw that actually we can get benefits of some other cool features that could be implemented at the API gateway level those are could be the cross-cutting concerns first of all we have the authentication and authorization before having the API gateway the web app if it wants to connect to any of those micro services the micro service should implement the authentication and authorization in each one of those microservices this means we'll have lots of duplicated code and if you want to update the authentication or the authorization code then we need to update it in all the micro services and that's lots of pain and that's not good and for interview of good practices when writing the code for my app so that's one added benefit actually those are benefits of the using api gateway and to this list i'll add here authentication and authorization a second advantage is the service discovery because here the API gateway could know the different microservices that has it here because this new micro service will expose its own swagger swagger API definition to the API gateway so that the API gateway could know those different micro services so I don't have to update the web app that's I'd have less coupling between the web app and the different micro services the only coupling I have it here is between the web app and only one API gateway instead of coupling it with multiple micro services so this enhances a service discovery integration another adventure advantage is the third the responsed caching so instead of implementing this and all my medical services I can implement response caching only on the API gateway so again I have less less code for my micro service I'm actually putting only the main business logic code inside my micro service and I'm extracting all the cross-cutting concerns from my macro services and adding them to the API gateway so I'll have lighter micro services with cleaner code and code responsible only for my business application logic code so this enhances the recipients caching when we use micro-service we want our application to be highly available for that we attempt to implement the attempts for our try policies and circuit breaker if the first request fails to my maker service then I might try after two seconds after four seconds under try again after eight seconds and so on until I have reaches like tries during for four minutes for example then if for some reason we might think that the micro service one would be saturated then we should stop sending it requests through using the circuit breaker pattern those different patterns are would be translated into code and add it to my micro services to each one of the micro services we are using api gateway we can extract that code from the micro service to go to live inside the application or the api gateway again we'll have lighter micro services so let's add that here as an advantage and here we'll say the retry policies and the circuit breaker another advantage is coming when we want actually to apply a limit for the number of requests to each micro service we say for example I cannot call micro service number one more than 100 100 times and one second for example we can apply that if we have external access to our micro services applications like third party applications that wants to access my micro services so I want to limit their access to my back-end we can implement that and all my micro services but using API gateway we can apply those limits to or inside the API gateway because at the end it gets all the requests so it can know who is the issuer of that request and it can monitor and see how many times it did connect in a second or any minute so let's add that here as rate limiting another responsibility that could be extracted from the micro service to go to the API gateway is the load balancing so if they have many multiple instances of micro service number one and I want to load balanced the requesters between the different instances then instead of implementing or adding some code or some API right here before the micro service number one I can implement that inside the API gateway and they can define multiple policies for distributing the charge or the requests on on top of the different instances of my micro service so again that's the load balancing another cool feature is to extract the lobbying tracing and correlation from the micro service to the API gateway at this level we can trace or we can log all the request is coming from the web app and at this level we can see to twitch micro service those requests will go and we can create some logging data at this level to attract each request and each response to my web app now because we get this request from the web app at this level we can apply transformation for this request we can add headers for authentication for example or for authorization and we can apply any kind of transformation to the request or also to the response coming to the web app like adding some new attributes and to the model that we'll get back to the web app or removing data especially here for aggregating that data coming from the micro-services so here we're not query transformation the API gateway will get all the requests coming from the web app so it can track and monitor each tube up or each third-party application that wants to connect to my micro-services does it can stop boost connections to my micro service because to have the feature that can whitelist the API or the IP addresses coming from the different client applications that's useful to stop attackers from using things like those attack to my micro service so this is the IP whitelisting so here we mentioned the different advantages of using api gateway but at the end have also some drawbacks some actually serious drawbacks one of them is because the api gateway is the only or it's getting all the requests from the web app here we are creating a single point of failure for our entire application because if the api gateway will get down or if it crashes or doesn't work for any reason then my entire application won't work so that's an issue to be addresses to be addressed through scaling the api gateway so you might have for example multiple instances of the api gateway if one instance get down then the second and third instances will get the load instead of the first one so this is worth mentioning single point of failure for this api gateway the API gateway is the concept and terms of implementation or in terms of tools we have multiple API or multiple tools that uses the API gateway one of the most unknown tools is conch which is an open source project available on github they have an enterprise offering also another API gateway that is really known as the open source community is ambassador we have also a slit which is a dotnet core API gateway so it's implemented using a c-sharp and we can change even the source code of this API a gateway we have also other offering from Asia for example I sure have this thing called as your IP I management and the other cloud vendors like Amazon Web Services and Google they also have their own offering for API gateway I hope you like it this video and thank you

Channel: Houssem Dellai

Views: 95,023

Keywords: api gateway, api management, reverse proxy, kong, ambassador, azure, microservices, frontend, cloud

Id: 8WuVBbXsHzg

Length: 22min 30sec (1350 seconds)

Published: Thu Aug 08 2019