Author: Pratik Saha
Introduction
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. Often, we have multiple questions in and around new technology. This article is to solve a few of those doubts to make sure we understand the complete potential of service mesh.
FAQ’s :
Q) What is a data plane and a control plane?
Sol: An Istio service mesh(open-source, developed collaboratively by Google, IBM, and Lyft) is logically split into a data plane and a control plane. The data plane is composed of a set of intelligent proxies (Envoy ) deployed as sidecars. These proxies mediate and control all network communication between microservices.
Q) What are the various tasks that the Mule Adapter performs?
Sol: A MuleSoft adapter performs the following tasks :
⦁ Performs validations and checks to comply with the security policies.
⦁ Periodically updates the policies and contracts.
⦁ Periodically sends metadata to Anypoint Platform to be able to use their analytics and monitoring features.
Q) Is it possible to use Istio without Kubernetes?
Sol: In practice, not really, since pretty much all the Istio runbooks and guides are available for Kubernetes.
In theory, Yes. Istio components are designed to be ‘platform independent’.
While Istio is platform independent, using it with Kubernetes (or infrastructure) network policies, the benefits are even greater, including the ability to secure pod-to-pod or service-to-service communication at the network and application layers.
But unless we know really well the details of each of the components: Envoy, Mixer, Pilot, Citadel, and Galley and are willing to spend a lot of time it becomes not practically feasible to get it running outside of Kubernetes.
Q) What are non-mule services? How are non-mule services created?
Sol: Non-mule services are any microservice that is not leveraging the Mule runtime (like integration apps, pass through API proxies), all polyglot applications — Java, Ruby, Python, Node.
They can be used in a service mesh with the help of a sidecar proxy and can also leverage few features of the Anypoint Platform (monitoring, exchange, designer, analytics)
Q) How are the cores counted when a service mesh is installed?
Sol: Cores are counted per adapter, which is bound to a single Kubernetes namespace.
Q) What is canary deployment?
Sol: A deployment strategy in which only smaller traffic is routed to the new version of an API and the larger traffic still goes to the older version until confirmed that the new version is stable enough to handle the load.
(A service mesh with help of the control tower can help in canary deploys, setting up header based responses, and applying communication protocols directly through sidecars)
For more information on Service Mesh refer here.
