Application builds when broken down into multiple smaller service components, are known as . When compared to the traditional Monolithic way, a Microservice Architecture treats , essentially helping to ease the maintenance of its code and related infrastructure. Each microservice of an application can be written in a different technology stack, and further be deployed, optimized and managed independently. Microservices each microservice as a standalone entity/module Though in theory, a Microservice Architecture specifically benefits build of complex large-scale applications, however, it is also widely used for small-scale application builds (for example, a simple shopping cart) - with an eye to scale further. Benefits of a Microservice Architecture Individual microservices within an application can be developed and deployed through different technology stacks. Each microservice can be optimized, deployed or scaled independently. Better fault handling and error detection. Components of a Microservice Architecture A modern cloud-native application running on Microservice Architecture relies on the following critical components - (through platforms like ) - for effective management and deployment of services by breaking them into multiple processes. Containerization Docker (through platforms like ) - for configuration, assignment and management of available system resources to services. Orchestration Kubernetes (through platforms like ) - for inter-service communication through a mesh of service- proxies to connect, manage and secure microservices. Service Mesh Istio The above three are the most important components of a Microservice Architecture which allow applications in a cloud-native stack to scale under load and perform even during partial failures of the cloud environment. Complexities of a Microservice Architecture A large application when broken down to multiple microservices, each using a different technology stack (language, DB, etc.), requiring multiple environments form a complex architecture to manage. Though Docker containerization helps to manage and deploy individual microservices by breaking each into multiple processes running in separate Docker Containers, the inter-services communication remains critically complicated as you have to deal with the overall system health, fault tolerance and multiple points of failure. Let us understand this by how a shopping cart works on a Microservice Architecture. Microservices here would relate to the inventory database, the payment gateway service, the product suggestion algorithm based on the customer's access history, etc. While all these services remain a stand-alone mini-module theoritically, they do need to interact among each other. It is important to note that . a service-to-service communication is what makes microservices possible Why do we need a Service Mesh? Now that you know the importance of a service-to-service communication in a Microservice Architecture, it seems apparent that the channel remains fault-free, secured, highly-available and robust. This is where a . A Service Mesh is responsible for fine-tuning communication among different services rather than adding new functionalities. communication Service Mesh comes-in as an infrastructure component, which ensures a controlled service-to-service communication by implementing multiple service proxies In Service Mesh, proxies deployed alongside individual services enabling inter-service communication is widely known as the . The sidecars (proxies) might be designed to handle any functionalities critical to inter-service communication like load balancing, circuit breaking, service discovery, etc. Sidecar Pattern Through a Service Mesh, you can - Maintain, Configure and Secure all service-to-service communications among all or selected Microservices of an Application. Configure and perform network functions within Microservices such as network resiliency, load balancing, circuit breaking, service discovery, etc. Network functions are maintained and implemented as a separate entity from the Business Logic, fulfilling the need of a dedicated layer for service-to-service communication decoupling from application code. As a result, developers can focus on the Application's Business Logic, while all or most of the work related to network communication is handled by the Service Mesh. Since a Microservice to Service Mesh proxy communication is always on top of standard protocols such as HTTP1.x/2.x, gRPC, etc., developers can use any technology to develop individual services. Components of a Service Mesh Architecture This contains the core application logic and the underlying code of a microservice. A business logic also retains the application's computation as well as the service-to-service integration logic. Due to the beauty of a Microservice Architecture, the business logic can be written on any platform and remains completely independent from a different service. Business Logic This includes basic network functions used by a microservice to initiate a network call and connect with the service mesh sidecar proxy. Though major network functions among Microservices are handled through the Service Mesh, a given service must contain the basic network functions to connect with the sidecar proxy. Primitive Network Functions Unlike Primitive Network Functions, this component through a service proxy maintains and manages critical network functions including circuit breaking, load balancing, service discovery, etc. Application Network Functions All service mesh proxies are centrally managed and controlled by a Control Plane. Through a Control Plane, you can specify authentication policies, metrics generation, and configure service proxies across the mesh. Service Mesh Control Plane Implementing Service Mesh with Istio While there are several others, being the most popular, we will explore how Istio can be used to implement a Service Mesh architecture for a cloud-native application. As explained in the sections above, in a Microservice Architecture, Istio deploys an next to each service with few or no code changes to the service in itself. All inter-service traffic is directed to the Istio proxy, which uses policies to control inter-service communication alongside implementing essential policies of deployments, fault injections, and circuit breakers. Istio does this by forming an infrastructure layer to connect, secure and control communication among distributed services. Istio proxy (called an Istio sidecar) Core Capabilities of Istio Secure service-to-service communication through authentication and authorization. Implement policy layers supporting access controls, quotas and resource allocation. Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic. Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress. Configure and control of inter-service communication through failovers, fault injection and routing rules. Implement policy layers supporting access controls, quotas and resource allocation. Istio being , including Cloud, On-Premise, Kubernetes, and more. Istio currently supports: platform-independent can be run in a variety of environments Service deployment on Kubernetes Services registered with Consul Services running on individual virtual machines Core Istio Components Core Istio Components (Image Source - istio.io) An Istio service mesh consists of a and a . data plane control plane The consists of the sidecar service proxies (through ), while sidecar communication among microservices is achieved through a policy and telemetry hub (through ). data plane Envoy Mixer The manages and configures communication among all sidecar proxies through and . While enforces routing rules and service discovery of Envoy proxies, acts as the authentication and authorizing channel. , on the other hand, acts as Service Mesh's configuration validation, ingestion, processing and distribution component. control plane Pilot, Citadel Galley Pilot Citadel Galley The control plane eventually ends up managing and maintaining components of the data plane, and hence forms to be the most important layer of the Istio Service Mesh. In this article today, we got an understanding of how a Service Mesh is critical towards the implementation of a Microservice Architecture, and how Istio solves the purpose of achieving those. Taking a step further, in the next article, we would go through the steps involved in installing Istio on different platforms, including Kubernetes.
