Anypoint Service Mesh Overview


In current business scenario most of the companies are adapting micro service architecture because of the drawbacks of the monolithic architecture where the complete application is built on either on single technology or on single platform which is tightly coupled, if we need to make any changes with one functionality we need to shutdown the whole application and make the changes as the entire application is deployed at a single place

While in case of micro service architecture each service is deployed independently and manages

There are also some challenges to manage the micro service architecture as well below are few challenges

  • Multiple teams who manages the multiple application use different api management and security consoles
  • Difficult to manage the multiple service built on different languages and platform w.r.t fault tolerant and load balancing
  • Difficult to view all the services on a single view
  • Microservice architecture several services talking to each other on network which required different authentication and authorization mechanism sometimes which is difficult to manage

To overcome the few challenges of the microservice architecture, there is a concept called service mesh which is architectural pattern for microservices deployment ,it’s main goal is to make service calls secure, faster and reliable

Mulesoft offered a solution to manage the services through single platform view which is Anypoint Service Mesh

Anypoint Service Mesh

Anypoint Service Mesh is used to extend the microservices by including the non mulesoft applications/microservices which is written in different languages or on different platform in to anypoint platform.

How it works:

In service mesh a sidecar proxy as shown below is used to  bring your existing non-Mule microservices from the Kubernetes Cluster as APIs into Anypoint Platform You can then manage these APIs within API Designer, API Manager, and Exchange. also you can monitor the health of your APIs using API analytics

As shown in the diagram, at the top of the architecture is Anypoint Platform, which brings complete lifecycle API management capabilities to the microservices built with Mule runtime engine (Mule). These Mule instances might be deployed within CloudHub, or Runtime Fabric at your location.

The mixer is architected on a general-purpose plug-in model, which provides flexibility in dealing with different infrastructure backend applications. These plug-in applications, known as adapters, enable the mixer to interface with the backend applications that deliver core functionality, such as logging, monitoring etc

Istio, which is installed on a Kubernetes Cluster, uses Envoy to manage the services using a sidecar proxy. The sidecar is responsible for any communication with the service, and resides within the same container as your service. With Anypoint Service Mesh enabled, you can continue to use Istio’s native policies for traffic control and security. These policies help ensure reliable and secure service-to-service communication.

The MuleSoft adapter and broker, which reside within the Istio mixer, connect components to Anypoint Platform. The adapter and broker enable sharing of metadata about all the services that are managed by the mesh. This allows for discovery of your existing microservices from the Kubernetes Cluster as APIs into Anypoint Platform.



Thank you for taking out time to read the above post. Hope you found it useful. In case of any questions, feel free to comment below. Also, if you are keen on knowing about a specific topic, happy to explore your recommendations as well.
For any latest updates or posts on our website, you can follow us on LinkedIn. Look forward to connecting with you there.

Share this:
Notify of
Inline Feedbacks
View all comments