Author: Pratik Saha
Introduction
Microservices were looked upon as an improvement to the legacy monolithic style which provides greater agility with smaller, targeted services. Earlier, a monolithic approach was followed for applications wherein each application was deployed in a single dedicated server, i.e one server hosts all the applications. The downside to a monolithic approach was if a change was made in one application, the entire server had to restart. Also, there was limited scope of reuse for large monolithic applications having various functionalities clubbed together. Scaling these applications individually was also a cumbersome task as each of them were in the same server.
Microservices came as a solution to these problems. A microservice has its own set of resources, memory, and computational power. If any change is made, only that API is affected and not others. The services were encouraged to be small and thus were possible to reuse for the functionality they provided. Also, services exist as independent deployment artifacts and can be scaled independently of other services.
What is a Service Mesh?
Service Mesh is an architectural pattern for microservice deployments, with the primary focus of making service-to-service communications secure, fast and reliable. It is an independent entity encapsulated in a Kubernetes cluster. The Anypoint Service Mesh primarily uses Istio (an open source service mesh platform) with Envoy filters to manage services by using sidecar proxy.
In the above image, we could see the service mesh is enclosed in a Kubernetes cluster. There are three independent services — A, B & C each written in different tech stacks. Each service has its own sidecar proxy which helps these services communicate with each other and with the control plane. The control plane takes care about the rules for security and communicating.
Features of the Anypoint Service Mesh
- It supports communication between services not written in mule i.e. non-mule services can communicate with services written in mule and vice-versa. This is possible because of the sidecar proxy which eliminates the differences these technologies have and provide a common ground for them to communicate and eventually share their functionality.
- The Anypoint service mesh allows non-mule services to use a few of its features like Security, Policies, Monitoring, Exchange, and more. This helps smoothen the integration process and reduce any issues that may arise due to different technologies.
- It helps reuse of services both mule and non-mule by allowing them to be uploaded and discovered on the Anypoint exchange. This extends the ability for these services to be used in the future.
Service Mesh architecture
A Service Mesh is an independent layer, encapsulated either in Kubernetes or a Red Hat OpenShift Cluster. The services do not talk to one another directly, rather use a sidecar proxy to interact. The sidecar proxy allows communication between mule and non-mule applications. It helps bring non-mule applications into the Anypoint Platform, and hence reap the benefits of API Designer, Manager, Analytics, and Exchange.
A Mule adapter connects components to the Anypoint Platform. The adapter manages all of these using a broker and generates metadata for all the services and feeds them to the Anypoint platform. This metadata helps the Anypoint platform identify and apply the features to non-mule applications like Analytics, exchange visibility, etc.
Understanding how each Service request works
It follows the following steps :
- The client or service user could be another microservice or any Kubernetes Ingress component which sends a request to the service to access its functionality.
- The outer dotted line represents the Kubernetes Cluster whereas the inner one represents the Istio cluster.
- Envoy captures the request and redirects it to the MuleSoft adapter using the Envoy filter.
- MuleSoft Adapter now validates the request against different policies and security protocols.
- Once the MuleSoft adapter confirms no violations, the request is transferred to the actual microservice.
- The microservice is executed and returns the expected logic back to the client.
- Meanwhile, the MuleSoft adapter periodically communicates with the Anypoint Platform to update any changes in policies or security protocols.
- Also, the MuleSoft adapter shares analytic data on how the service is performing back to the Anypoint platform.
Conclusion
A service mesh helps us integrate microservices faster, easier, and in a stable way. However, microservices almost always need to work together with other services and applications to eventually create larger applications. The forming services and applications for the larger applications often use different languages, deployment models, etc which results in increased complexities and cost. This is the prime reason they are not extensively being used.
Another fault in this architecture is that Istio already provides security, tracing, traffic policy enforcement, etc. So, why do we put another Mule layer on top of Istio to do what Istio already does? These factors have affected the use of Anypoint Service Mesh today and are awaiting MuleSoft to launch better versions of it.
