Service Mesh: A Brief Overview

  • 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.
  • 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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store