 So, today I am going to discuss about it means I think you have worked with service mesh and microservices I think all of you have worked with those stuff right. So, after microservice come into the picture what people thought of the just know requirement of API management in this around these use cases. So, basically today what I am going to discuss about why still we need API management even though there are service mesh and microservice architecture how we are going to use API manager there. So, if I go through the agenda today I will discuss about the how the application evolves then I discuss why microservice architecture is required then I will go through the challenges that we face while we are working on the microservices then why we need service mesh and how service mesh going to solve the challenges we face with the microservices. Then I will do a simple demo to expose one service connecting with my studio then I will discuss the today's main topic why we need API management even though we have service mesh in place then I will discuss how WSU to API manager integrate with STO and then I will do quick demo integrating WSU to API manager with STO and show that those capabilities. So, to start with so you know over the last let us say five decades the application evolved it moved into the desegregated architecture. Let us say we came into the desegregated architecture because there are industry demands so we have to deliver let us say our business capabilities very soon to the outside. So, due to that reason as a solution this desegregated architecture came popular. So, in that case we can very easily bring our functionalities to the outside. So, that is the advantage of this desegregated architecture. So, nowadays serverless microservices APIs are become known when developing applications with desegregated architecture. So, let us see how the microservices and the monolithic services are getting different. So, yes there are monolithic services the microservice in between that we have the service oriented architecture. So, the main difference is in the monolithic you have one application. So, that application may have several functionalities. So, if you think about the CRM system there are 100 functionalities you need to expose. So, all will be in a single application. So, if there is a high demand or a given functionality there is no way to scale it out. At the same time even if you want to improve a one segment of that application you have to work on the whole application. So, later that service oriented architecture came there you can develop the component basis, but still the within a one application those all the components will reside. So, it means one processor is running when it comes to the deployment time again we have all the challenges that it face with monolithic application. Then the microservice architecture so we can say it is kind of doing the so in the correct way. So, each business functionality will run in a different process. So, there can be a different team working on that given business functionality. So, they can manage their own delivery life cycles and if we need to scale that up easily that component can be scaled up. So, at the same time each business component may require different technology. So, if someone is like to use a different technology that team can use another technology and then other team can use a different technology. Likewise they can develop their component in a different way in the way that that team prefer to implement. So, those are the kind of advantages we see with this microservice architecture. So, if we closely look at this microservice architecture. So, it means for the outside it can be a one application, but internally there are several components. So, if it is a small application there can be very few number of components. So, there is no issue in managing those components right. So, but in reality if you build a if you build up the business level application there should be many functionalities which means there are many number of components over the microservices different processors. So, managing the huge number of microservices is not is not easy and the main challenges face is the communication right. So, those are communicating over the network. So, how to manage these number of services and how to manage those communications? Likewise there are several challenges we are facing in Microsoft software. So, let us see what are the other challenges that we face then we can see how service mesh come into picture and help to solve these stuff. The first challenge is resilience right. So, we know we have set of processors running individually. So, those are communicating over the network. So, networks are not 100 percent reliable even it is a local network. So, but we build reliable application on top of unreliable network. So, we have to handle those challenges. So, when we talk to service to service that call may be time out or one call can fail and sometimes in different levels it may add latency and all together in another layer it can get failed. So, it is kind of a challenge. So, we have to implement some other ways to handle that some kind of circuit breaking we have to retry if something fail likewise at least a new API right. Then it can be a new service and due to this immutable nature of these nodes it will bring up with a new IP address. So, let us say one service used to communicate with the previous API. So, at that time it that the first service may know we are the second service reside, but what happen they roll out the existing service and bring a new one. Then we cannot hard code over we cannot rely that this service may run in this space right. So, we have to handle that thing we have we should have a way to discover the other microservices where they reside and what are the end points we have to get that information that is another challenge we face when we are dealing with the microservices. Then the next challenge is the security in the microservices we are communicating with each service through the network. So, we have to communicate secure each communication right. So, when we if we have different components managed by different teams each team has to think about how they secure these communication, how they handle that authentication the service service communication and their related security. At the same time they might have developed these microservices using different technology. In that case those technologies may have different ways to handle the security. So, they have to think of that sometimes some technology may not handle a given protocol. Let us say we are going to use JWT to do the communication and do the authentication. In that case one language may do support to validate the JWT ECD there can be a live before that thing, but in the another language that you are trying to use may not support that thing. Then you will have to write it from the scratch. So, those are the the challenges we face in the security phase. So, if you have questions you can ask right is it clear right what I am good. Then the observability then other challenge. So, if you think about the monolithic application you have a one application you know we have to implement the login how to trace it how to get the matrices all you know because you have only a single application, but when it comes to the microservice architecture each component resides in different places. So, each component level you have to do the login you have to do the tracing and other material and at the same time we have to collect those information to a single place and have to process. So, you have to think those aspect then again we talk that all the time that each team can release their own component at any time they prefer right. So, in that case how do they roll out. So, if something happened they have to roll back whatever the version they release. So, we have to manage those things as well. So, how we are going to solve this problem. So, that is the place where service mesh came into play. So, the service mesh is a dedicated infrastructure layer that control all of these challenges. So, the whatever the microservice developers they do not need to worry about these challenges they can directly go and implement their business functions. So, the service mesh is going to handle the other challenges that we discuss. In the service mesh sidecar is a very important I think do you all know about sidecar I think you know right. So, sidecar is a proxy kind of component which reside with the service right. So, the sidecar handle the all the complexities the at the actual microservice only do whatever the business function it require. So, with the sidecar the sidecar concept is used in the service mesh. So, if you see in this picture in the green color we have all the service they do not know about any other service and how they works, but the the proxies reside with each of these microservice handle these capabilities. So, the if we take all of these proxies together it help to build the service mesh. In a service mesh we can divide it into two parts. One is the one is called the data plane and the second thing is called the control plane. So, the data plane is the actual the proxy services which intercept these messages and it handle all of these let us say the communication challenges or the security all the things handle by the actual the proxy service. Though this set of proxy service are called as the data plane. So, having only the this proxy service does not handle our requirement. So, now again we have the challenge how we manage these proxy service, how we define the proxy service and how we define the policies how to handle these request and how we push these policies into these each proxy service. To do that thing we should have some kind of control plane. So, when we have this control plane and data plane together we call it as a service mesh. So, Istio is a open source service mesh implementation. So, basically Istio is mainly represent this control plane for the data plane it use the NOI proxy. So, Istio is implemented on top of the NOI proxy and there are another service mesh implementations as well like smart stack like that. So, but Istio is the the most common service mesh implementation we have at the moment. So, if we look at the Istio there are several components. So, first we have the proxies which represent the data plane actually those are the NOI proxies. Then the actual Istio which consist of this data plane it has let us say four main components one is the mixture that the part which push the policies into the proxies and how the policy evolution happen those are decided through the proxy and this is kind of this has a kind of pluggable architecture. So, you can write your own component and put it there. So, this is the extension point we use to plug Istio into the WC2 API manager. So, then we have the Citadel where it controls the credentials and the certificate in this service mesh and we have the pilot it manage all the how the traffic smooth especially this circuit breaking service discovery everything will be handled through the pilot and gallery is kind of a component which handle the all the policies and this integration. Okay, I will do a quick demo there I will I will use the simple service which is simple service and I will expose it to configuring Istio. So, if you have used Istio anyone used Istio just then you might have used this sample. So, I will just show you that thing. So, I am not going to discuss more about the Istio and how it works, but I will later go and discuss how to configure connect API manager with Istio and how it is. I am running all these components on top of the GKE. So, there I have installed the Istio you can see there are Istio related components are installed. So, now I am going to install the services the HTTP bin sample I think you might have used that thing. So, I will install that thing and expose it. So, first I will deploy the HTTP bin sample then I will expose it via the ingress gateway. Okay. So, with this command so whatever the stuff I do here there is a git project. So, later you can go and try it out. So, I will just go through these commands and show how it works. So, later you can try it out. So, first I will deploy the HTTP bin sample then I will try to expose it outside to the ingress gateway. So, do not worry about these commands and anything. So, when you try the sample you can see it. So, it seems the services are created and it is exposed to the outside. So, we need to now we now we need to find the IP address and the other stuff to connect. So, let us find it and try to get that response. So, here what I found is this is the IP address which exposed to outside and this is the port. Yes. So, with this port and IP address I will talk to the service and get the response. Now, I got the response from the microservice I have already installed. So, do not worry that much about this response and how it is deployed. So, later I want to I am trying to secure this service and manage this service via the API manager. So, I will more discuss in that part. So, now the main topic that we are going to discuss today. So, if we have a service mesh why we need to API management. So, let us first see the difference between the service mesh and the API management solution. So, the first thing is the API the routing happened in service mesh in layer 3 or the layer 7 in the API manager is between the layer 7 application layer it can be HTTP, GR2C, 4, Graph SQL in that way. And the in the service phase specially that in the security perspective this service to service authentication is the main thing and in the API management layer it has the concept of the application and it use the users. So, in the service mesh layer we do not have this the user concept or the application concept. So, that only comes with the API manager. Then in the analytics in the service mesh we just analyze the service operation related but when it comes to the actual business we need to get the information about our actual API for the people going to use that thing how many people going to use that thing like that the real business related information should be gathered. So, that is another requirement of the API management solution and the rate limiting. So, that rate limiting also mainly focus on the service layer but in the API management solution we have to focus about the business related stuff. So, and when it come to service mesh again developers will involve in that layer. So, they develop individual services and they will expose those services the other service mesh. So, after exposing these different kind of services eventually as organization there are set of APIs which are exposed to the outside. So, now it is very similar to the things what you have what you are doing at the moment. So, regardless of its microservice architecture or the monolithic architecture you have a set of business APIs you have exposed those APIs outside to the world. Now we have the business requirement. So, we need to let people to come and find these APIs right the public APIs. We want them to subscribe those APIs and consume those APIs. Once they try to consume we have to gather the strategy and see how these people are used and if they are using we need to provide the proper security for these people and we need to guarantee all the authentic users only accessing these API which are exposed to the outside. So, this is the primary requirement of the API management solution which is not covered with the service mesh. So, we can clearly see service mesh is addressing a different problem and the API management solution is addressing a different problem. But to build a business application we have to combine these two. We have we should have the APIs at the same time we have to expose these APIs and manage this API. So, this is the place where API management come into picture even though we have a service mesh in place. Yes. So, these are the occasions we need service mesh. So, when user need to expose microsize to the outside in a secure and control manner we need to have API management solution because in the microsize we do not have the concept core users. So, then we cannot do the use authentication. So, we have to bring another layer. So, that is the API management. Then we need to enforce the fine grail security to the API. So, if you I think at the moment also you may be using 002 to secure the API. You may use scopes to define different business capabilities. So, we need to bring it into the picture. So, API manager will do that. Then we when we need to gather the information about the business usage. Yes. We have to use the API manager. Especially we need to have a place where people come and discover this API kind of a market place. So, if you are not trying to use API management solution from the scratch you have to write something like that. So, even if you write it will become another API management solution. So, you can use whatever the existing API management solution to cater that requirement. So, if I do you have any questions? No. Cool. So, 002 API manager for this demonstration and other purpose I use the 002 API manager. So, if you read 002 API manager also leading API management solution in the garden reports we are recognized as one of the leader in API management solution. So, I will use 002 API manager for this. So, first this is the architecture how we expose service through the interest gateway and configuring the STO. So, as I said earlier we have the data plane where the actual message interception and business functionality is executing. Then we have the control plane where we control this service message. So, there you have you can see all the components. So, mixture is there. So, when request come into the service the way when they when someone trying to invoke the service exposed by service. First it will come to the invoice proxy there then it will talk to the mixture and see whether there is a applicable policy and if there is a applicable policy it will be evaluated between the proxy then it will let that request go into the actual service if something happen noise means if the validation fail it will send the error message back. So, this is mixture is the place where we plug WC to API manager. So, we have written adapter extended component where we connect mixer or the service mesh into the API manager. So, API manager will do the API publishing part and when you publish create the API when you publish the API there you can define the security level scopes related to that API and everything. Then this API manager will push that that policy into the mixture. So, later when the request come into the service those policies will be evaluated and we have the WSO to API store which kind of a market place for the develop the outside people who want to find out those APIs they can come to the API store and discover the API. At the same time we have API analytics where you can see the business related analytics right. So, this is how API manager then again another component is not shown here that is the key manager or the token issuer where you get the token. So, basically when you try to involve the service first you come to the API management layer and discover the whatever the available API. Then you subscribe to the whatever the API you want to implement your client once you subscribe you will get a consumer key and the secret in the default overflow. Then you should get a token from this API management solution with that token you will try to involve the service that is exposed through the service mesh. Then in the in the proxy layer it will talk to the mixture and see if they are applicable policy. So, if we have defined if we have published the API saying this is secured. So, these are the scopes that should be validated when we involve then that information will be available in the mixture. So, based on the policy that will be validated. So, in the current this adaptive implementation we do support for two types of authentication one is the normal O2 token bear token then the second thing is the JWT token. So, let I will discuss how these are validated. Yes, now I will show you. Yes, cool. There we use the ingress gateway. Yes, true. Yes. So, in the in the normal it means there are two ways right. One thing yes actually there are two ways API manager bring into this picture. One is we are not going to use the ingress gateway instead you can directly use the API gateway and it will be fronted from the all the APIs right. That is the one way and the second way is use the inbuilt gateway and it is used the gateway of the API manager. So, there are two patterns actually you are correct. So, in this scenario we are not using the actual gateway component. So, there is no good kind of thing to describe. So, yes. So, let us. Oh no, no it is true. It is true sir. It is true. So, in actually there are two ways you can bring API management solution into the picture. So, one way is there is no this kind of integration with your microservice right. So, you have all the APIs and you directly expose those APIs to the outside. So, again we have this API management requirement. So, in that case we front API manager and the API gateway front. So, all the API request will go through that gateway right. So, then this API manager component will come here and it will create another layer from there and all the request will go through there and the subscription and everything handled in this way. So, we are not going to use anyway the request will go through the ingress gateway and anything, but the managed the API management part will happen in this way. So, that is the one way to do that thing and the second way is yes we are going to use the existing ingress gateway, but only the management part will be done in the this way. Thanks for bringing that question. I answered your question right. Good thanks. Okay, I will do a quick demo on that thing. First I will deploy the WSP API manager analytics component then I will create the relevant config maps for the API management analytics and API manager component. Now, I am going to deploy the WSP API manager. So, you can see here I will expose the API manager as a notepad sorry. So, I will use this notepad to access this. So, I have created the first entry for the the IP address. So, I am going to know the API publisher first. I will access the API publisher and try to create an API for that thing. So, I will create a new API and publish it. This is the API manager publisher view. I think this is to the screen. It will go here and there things. So, I will create a new API first. Now, I am going to create an API for the Httbin API that we have already exposed and here we will create and publish. So, then it will go to the API store. So, anyone can come to the store and discover the service and subscribe to that and you know that. So, I will create an API. So, if you have a stagger file or something, you can upload it and create and from the scratch on or you can create. So, I will go to create it from the scratch. I need a name. Then I can version this API to give the end point. So, we can define who can access this thing whether this should be visible to the public or not. Likewise, this is the API management related functionality. So, I will go into publish it. So, if you can add. Yeah, before that thing I have to define the path available. So, one is the IP and gate. Yeah, these are the path supported by my sample API. Then I am going to save it. Then I have to set the production input. So, I have to set the API input. So, there are a lot of capabilities in the API manager, API publisher. So, I am not going to discuss more about these capabilities. So, if you like you can go through these product and verify those capabilities. So, when you publish we can define the subscription levels. So, these are the basic capabilities. So, here I will put unlimited. So, there is no I do not config other tier. So, anyone can subscribe to this one and continue any number of days. And the most important thing is now we can secure this API. So, here we are going to use the O2.0 to secure that thing. So, I will discuss the I will configure the relevant scopes and here scopes are validated against the role. So, I will bind a scope into the roles. I will say here I will say only the users in the admin role only can get the scope called scope IP. So, other users if they are in a different role they would not be able to get scope IP. So, that validation will be happen when you try to get a access scope. So, I will add this scope and I will add another scope for the header APL. So, here I will use the same API key as a scope name asset. So, you can use different scope name. So, you can with different roles. So, if you try you can do different things. So, I have added a scope. So, I will bind those scopes with relevant APL. Yes. So, to get the IP we did have a scope IP to get the headers we should have scope headers. Now, I will go into publish it. So, once I publish it it will publish the API. So, I can go to the API store and see at the same time it will create a policy and it will push into the mixture. You can see this is the API store view. You can see the published API. So, here I will create a public API. So, even without login into the store I can see this API. So, now I login into the system. Before try to subscribe and invoke the API let us now this API is secured. So, let us try to invoke that API without this token. So, anything and see how the response comes. So, you can see previously with just invoking the API we were able to get the response. Now, let us see if we can get it now up. So, I think I did not deploy the mixture adapter and other stuff. Let me do it. Which means even though I said it push the policies to the mixture adapter I have not deployed the mixture adapter it means it might not have created. So, I will delete the API and deploy the mixture adapter and create the API. If you see this picture. So, when I create the API it need to publish the policies to the mixture. So, it will directly talk to the adapter and through the adapter I will publish the policies to the mixture. But since I have not deployed the adapter even if I create the APIs it cannot publish those information to the adapter. So, now I quickly create that API I will take the window to this machine and create it. Now, you can see we are getting the error that missing credentials. So, now you we have to get a token if you want to access this API. So, let us subscribe to that API and get a token and invoke this API. So, first I try to get a JWT token from here and invoke that thing. So, now I am I do not going to mention any scope and I will just generate the token. So, I will copy that thing. Now, we are getting still unauthorized because I did not specify any scope. So, let us see this JWT token. Here you can see as a scope I am getting only the default scope. I did not get scope IP or scope header. Let us get a new token with scope header. I think I did not do the subscription for that. Just for the JWT application I did not subscribe the third one. There I have subscribed to that thing anyhow then I cannot access that API. So, I will get a new key and now with the scope of IP I will get a token. I will copy this. So, you see first I try to invoke the header API. Here I will try to access the header API with the JWT token. So, I did not get chance to access but IP API could because if you remember when I mentioned the scope I said configure only the scope IP. So, with that JWT I cannot invoke the header API. I can only invoke the IP API. So, in the similar way we can get a normal bearer token and access the API. So, I am not going to demo that thing but I will discuss how it works. Yes, in the JWT scenario. So, when you pass the JWT it will go to the mixer and see whether they are applicable API. Then since we have applied policy I try to validate the token. So, if we pass a JWT then there is no need to talk to the API manager to do the validation even though API manager he provide the key management capabilities and API subscription. Because since we are using the JWT token we can verify that token validating the signal. So, I did not show you in the initially when we deploy I will get the key from the API manager and push it into the mixer. So, there it will validate the signature and it do validate that it does validate that scopes as well scope and other relevant parameter validated there if it is a valid token it will let the API go into the survey. So, when it come to the this is what happened in the scope and JWT validation if it did not use the correct scopes it did not allow me to go inside. So, I had to use the correct scopes. So, then if it is a normal bearer token what it happened it will go to the API mixer then it need to talk to the authorizing server and see whether this token is valid or not. So, it will talk to the API manager and validate the token if it is a valid token and if it has the relevant scope it will let the code go into the service. So, yeah at the same way this information will be published into the WSO to API manager analytics. So, from there you can see the dashboards as well. So, this is how it works it seems times really fast. Do you have any questions before that? Yes. Sorry. Yes. So, when you added JWT on top of it what happened to it is still there or no in this scenario I have disabled mutual TLS. So, one part talking to another part it is still in the token. Yes with the token they are there are different ways one is the you can secure the service to service communication with the mutual TLS. So, then only the service will be authenticated. So, if you use the JWT token at the service at the same time whatever the user who is trying to access the service both can be validated. So, you can support through this. Yes. Yeah. You know so, like when you expose the service the IP that you taught that was from the on the yes yes. No in this one. Yeah. Because in this scenario we are not choosing the API manager as a gateway only the English gate. Yes. Yes. If we deploy in the other way it means the full gateway capabilities then the API manager gateway will be used. Since authentication is a network and since it is the same part you do not have to technically authenticate it on the it is a no authentication. Yes. But application itself does not care for the. Yes. Yes. Basically kind of normal gateway also validate in that layer. So, that happened the same thing will be happening here. Okay. With about now I am not going to that much talk about WSO2. So, we are one of the open source vendor and we have mainly three products one is four products API manager WSO2 identity server and WSO2 enterprise integrator and WSO2 stream processor. So, those are mainly for the integration related technology and we have offices all around the globe and at the moment we have more than 550 employees and all the products are open source. So, this is just a bit about WSO2. So, do you have any other questions? Okay.