For this article, we will be getting to understand what a Service Mesh is, why it is needed, and how it works in relation to Kubernetes (Orchestration framework). Definitions, terminologies will be broken down so you can better understand the aforementioned concept. Without further-ado, let’s get right into it.
Photo by Clint Adair on Unsplash
Well before we get to understand what a Service Mesh is, there are fundamental terminologies that need to be defined and addressed. These terminologies include:
N/B: (The above are not in any specific order).
The above terminologies need to be defined as said earlier, before we fully understand what a Service Mesh is.
“Software architecture can be defined as a structured framework used to define or conceptualize software elements, relationships and their inherent properties”
“Software architecture can also be simply defined as a functional structuring or organization of a system. (Definition of how elements and properties are to interact in a system).”
With the definitions above, you now get to understand what software architecture is. Let’s head over to the next definition.
“An Infrastructure Layer is a layer in a software system that manages communication and interaction between systems by way of receiving data, storing data, and providing data when requested. (Including resources such as computing and storage).”
“Microservices — also known as the microservice architecture is an architectural style that structures an application as a collection of services that are highly maintainable and testable, Loosely coupled, Independently deployable, Organized around business capabilities and Owned by a small team.” — Chris Richardson @ microservices.io
“The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.”
Now you have a basic understanding of the aforementioned terminologies. The aforementioned terms are in one way or the other related to the concept of Service Mesh.
Now for the interesting part, let’s get to know what a Service Mesh is:
“In software architecture, a service mesh is a dedicated infrastructure layer for facilitating service-to-service communications between services or microservices, using a proxy.” — Wikipedia
“In simple terms, Service Mesh manages the network traffic between services in an application.”
Three main goals are to be accomplished with the aid of Service Mesh in inter-service communication. These goals include:
In legacy microservices architecture or distributed systems, inter-service communication traffic was unencrypted. Unencrypted internal traffic is nowadays considered a bad practice in terms of security, particularly for public cloud infrastructure and zero-trust networks.
Another goal of service meshes is to bring visibility to interservice communications. By controlling the network, a service mesh covers observability, providing layer-seven (application layer) metrics, which in turn allow for automatic alerts when traffic reaches certain rate limits.
This section of a service mesh architecture allows for service discovery and dynamic routing. It also deals with communication resiliency, such as timeouts, retries, and circuit breaking. This section or aspect of a service mesh can also aid in load balancing for individual services, to promote adequate connectivity.
More and more companies continue to implement the distributed or microservice approach. With each service performing one business function or the other hence, the need for each business function to be managed from time to time. The Service Mesh being a dedicated infrastructure layer — is built inside of applications. Remember what an infrastructure layer is, it is simply a system that manages communication or interactions between systems or services.
Let’s site an example, an online restaurant — you as a customer, may have a dish you order most of the time, you suddenly start getting recommendations on dishes that are somewhat related to the dish you order the most. Inside of that online restaurant application, there’s a service that communicates with another service (Probably a machine learning algorithm) by way of an API (Application Programming Interface) to give you the user a good experience which is the dish recommendation. Modern applications are often broken down in this way, as a network of services each performing a specific business function.
As stated earlier, a Service Mesh simply manages traffic between services in an application. With the aid of the Service Mesh, developers will not need to place so much focus on the communication between services but focus more on the business logic of the application and more value to each service.
A service mesh works by implementing a proxy instance called “sidecar” for each service instance. This “sidecar” or proxy instance handles monitoring, communication and security policies and protocols between each individual service instance.
Image by RedHat on RedHat
This “sidecar” or proxy operates alongside each service instance or pod inside of a container thereby forming a mesh-like structure. The purpose of this “sidecar” is to route traffic to and from the pods it runs alongside. This “sidecar” communicates with other “sidecars” and is then managed by the orchestration framework such as Kubernetes.
For communication or interaction between services, the service instances perform a DNS lookup to search for available services ready for communication. With the aid of the orchestration framework, sets of available service instances are made ready to receive requests.
Proxies or “sidecars” in service mesh implement a sophisticated layer-seven (Application layer) load balancing and more powerful traffic routing and management.
Proxies or “sidecars” in service mesh can encrypt and decrypt requests and responses during an interaction between instances. The service mesh can authorize and authenticate requests made from both outsides and within the application, sending only validated requests to instances.
A Service Mesh is made up of two components:
Image by Nginx on Nginx
Control plane:
This component can be considered the “brains” or “control center” of a Service Mesh. The control plane interacts with the proxy instances otherwise called “sidecars” that are connected to each service inside of a pod. This control performs actions such as pushing configurations to each service, ensuring service discovery, and centralizing observability.
Data plane:
This is a plane or section of a Service Mesh that contains the network of proxies or sidecars that communicate with each service. This section is deployed together with the application, all part of the infrastructure layer.
You may also be wondering, what are some examples of Service Meshes? Well, they include:
All of the above are examples of Service Mesh technologies that serve the purpose of managing service-service communication in a microservice architecture (distributed system) application. Each has its strong suit, one may be preferred over the other.
2018, Cryptoland Theme by Artureanec - Ninetheme
