Hi All, The intention of this mail is to discuss about API Manager istio integration and come to conclusion on design and architecture. With this particular feature our target group is users who already use API Management and have requirement to move towards service mesh architecture. We believe this will help us to prove our capability to integrate with service mesh architecture. This feature will allow users to expose their services deployed on service mesh as APIs and apply different QoS. Here is a brief overview on what we are planning to do.
*Overview of the feature* - When users move towards microservice architecture from monolithic app architecture we will have thousands of microservices. When we break each monolith app to microservices it will create more services. - So managing all these microservices would be a challenge. - Istio helps to reduce the complexity of this type of deployments. It is a platform, including APIs that let it integrate into any logging platform, or telemetry or policy system. - Istio creates a “service mesh” that routes traffic between interrelated services in a secure and robust way so that the developers of each individual service can focus on what a service does rather than the details of how it communicates. - However when users need to expose these microservices services to outside in a secured controlled manner we need API Management. - Most of the time we need to create APIs(for microservices) and share them with other developers who might be part of your organization or who might be external. - So API Management within service mesh solution is required to operate successfully. With this capability, user can expose one or more services from an Istio mesh as APIs by adding API management capabilities. *Approach*When it comes to enabling API Management for service mesh there are multiple approaches we can follow. One way is use the mixer plugin model, which is a standard extension point available in Istio. We believe this is most suitable way of integrating API Management with istio. *Mixer* is a core Istio component which runs in the control plane of the service mesh. Mixer's plugin model enables new rules and policies to be added to groups of services in the mesh without modifying the individual services or the nodes where they run. API management policies authentication (by API key validation), throttling, etc can be deployed and managed at API Manager side without doing any changes to the actual microservice or sidecar proxy each time deployment happens. Following diagrams will explain how the mixer plugin captures telemetry and performs the policy check. Whenever user deploys a service, Istio injects a sidecar to the particular service as a proxy. For each request sent to the service, the sidecar proxy will capture a set of data and publish it to the Mixer. If the user needs to expose this service to outside in a managed way, an API should be created in API Manager. This can be done via different methods: - Automated process - When a user deploys a service which is required to be exposed, an API will be created in API Manager automatically. - Manual process - Once a service is deployed, the user can go to the API Manager developer portal and create API by giving service data and swagger file. *Route of a Successful Request* 1. The client sends the request to the service (Istio capture the request and redirect to the istio-proxy). This enters the Kubernetes cluster via an ingress point. 2. Proxy captures attributes and sends to the Mixer as attributes. 3. Mixer adapter does the throttling, authentication parts and calls for the API Manager Deployment. 4. API Manager Deployment captures the request and sends the relevant response to the mixer. 5. Mixer makes the policy decisions and sends back to the istio-proxy. 6. The proxy delivers the request to the microservice. 7. Microservice executes the service logic and sends the response 8. The response is sent out to the client API Manager team started initial work on this project and we will work on features in phased approach. First we will do introspection call which validates access token. Then we can think of throttling, usage data monitoring etc. We will create repo named istio-apim and start our work there. If you have any suggestions to above proposal please let us know. Thanks, sanjeewa. -- *Sanjeewa Malalgoda* Software Architect | Associate Director, Engineering - WSO2 Inc. (m) +94 712933253 | (e) [email protected] | (b) Blogger <http://sanjeewamalalgoda.blogspot.com>, Medium <https://medium.com/@sanjeewa190> GET INTEGRATION AGILE <https://wso2.com/signature> Integration Agility for Digitally Driven Business
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
