What is a Service Mesh and do you need one?

Studies show that 91% of enterprises are using or have plans to use microservices. The reasons are well documented — monolithic architectures are hard to develop and maintain, while microservices allow for greater agility with smaller, targeted services. 

However, microservices can’t function alone — they often work together to compose larger applications. As organizations build out more microservices, often using different languages and deployment models, they end up with complex environments that can be costly and difficult to operate. This complexity can stifle innovation, negating the promise of microservices.

How can enterprises govern and manage all their services holistically, and at scale? A good first step is to use a service mesh

What is a service mesh?

A service mesh is an architectural pattern for microservices deployments. It’s primary goal is to make service-to-service communications secure, fast, and reliable. 

In a service mesh architecture, microservices within a given deployment or cluster interact with each other through sidecar proxy’s. The security and communication rules behind these interactions are directed through a control plane. The developer can configure and add policies at the control plane level, and abstract the governance considerations behind microservices, regardless of the technology used to build. Popular service mesh frameworks, such as Istio, have emerged to help organizations implement these architectural patterns. 

Do I need a service mesh?

Service mesh is already seen as a crucial component to companies invested in microservices. According to Gartner and IDC, companies deploying microservices to production will require some form of service mesh capabilities in order to scale.

However, a service mesh does not solve all challenges in the microservices lifecycle on its own. Organizations still need a way to easily publish and reuse services across teams. Furthermore, as mentioned above, a service mesh intends to make service-to-service communication within a specific cluster. In the typical enterprise, several services will also have consumers outside any one specific domain. 

Businesses require a method of centralizing the discovery, management, and security of their services, regardless of language, domain or deployment model.

Extend your application network with Anypoint Service Mesh

MuleSoft customers can realize a microservices architecture using Anypoint Platform and an API-led approach. These microservices leverage the Mule runtime engine, and become a part of the customers application network — a way to connect applications, data, and devices through APIs. Anypoint Platform already brings full lifecycle API and service-management capabilities to support your application network. 

We recognize however that microservices exist outside the MuleSoft ecosystem that do not leverage the Mule runtime engine. That is why we are excited to announce Anypoint Service Mesh, a MuleSoft solution that allows you to discover, manage, and secure any service deployed to Kubernetes — no matter what language it is built in. 

With Anypoint Service Mesh, we allow organizations to extend the benefits of the application network to any service, allowing them to:

  • Empower innovation teams to build with technologies that best align to their skillsets.
  • Accelerate microservice adoption with discovery and reuse of non-Mule services.
  • Maintain flexibility across services with a network that is built for change.

To learn more about how you can extend the benefits of your application network to any service and what’s in store for Anypoint Service Mesh register for our webinar.


We'd love to hear your opinion on this post


4 Responses to “What is a Service Mesh and do you need one?”

  1. Is there any vCore needed to include the service mesh or to add micro-services on API manager considering the microservices are deployed in non-mulesoft Kubernetes clusters

  2. Nice article but there are some points which are not addressed e.g.

    1) Why do you have different region control planes
    2) Do you mandate default Data Plane proxies/proxy servers and
    3) Where can one find your Service Mesh articles and diagrams

    Your response would be greatly appreciated

    Thank you,
    Tim

  3. Hi Kevin,
    Thank you for the reply to my previous comment and I’ve got another question.

    Is Mule 4 Service Mesh based or is Service Mesh just another layer ontop of Mule ESB and if Service Mesh is just another layer ontop of Mule ESB, what’s the combined architecture of the two ?
    A diagram would be well appreciated.
    Thank you in advance,
    Tim