What Is a Service Mesh?

New IT and network technologies have led to an important paradigm shift in the software industry. The software is a central component of any complex system. The software quality is not only characterized by the range of functions and the implemented features, but is primarily due to the software architecture. New communication technologies such as eCommerce, mobile internet, and cloud technologies place additional demands on the interoperability, flexibility, scalability, maintainability, and security of implemented software solutions. In order to meet the growing market and customer requirements, new solution approaches in software development and in software architectures are inevitable.
 
[st_adsense]  

What Is a Service Mesh?

The software components of a complex system must communicate with one another. A distributed system can contain hundreds of services and thousands of service instances as components. The communication channels of the components and their transactions (requests, responses) cannot always be firmly defined and cannot be predicted in advance. The complexity of the individual components is also great. Modern software components (apps) must have sufficient intelligence to make an optimal decision in every possible situation. This is not just about optimal local data processing in the classic sense, but about optimal and secure communication between the software components. Individual tasks of an application are implemented as services. In order to perform communication tasks, these services are equipped with appropriate interfaces (APIs). Nevertheless, application components have to be further divided, specialized, and structured.

The complexity problem can be solved with the help of the special microservices, control plans, and software proxies implemented in the software – a so-called Service Mesh. A Service Mesh implements the layer model known from network engineering, in which each layer functions as an independent service and solves its specific tasks. With the layer model, the Service Mesh enables a service-based approach in software architecture. The typical tasks of a Service Mesh are service discovery, load balancing, health checks (self-checking), and access control (authentication, policies, security). Service-based architectures (service-oriented architecture, SOA), SaaS (software-as-a-service) technologies, container technologies (microservices), and SDN networks (software-defined networking) are closely connected with the Service Mesh concept related.

Service Mesh enables secure, fast, and reliable interaction between authorized microservices and is implemented as a dedicated infrastructure layer. In contrast to individual microservices and containers, a Service Mesh builds a kind of microservices infrastructure and assume the tasks of secure and optimal communication between the participating microservices. The Service Mesh uses standardized interfaces and protocols. The Service Mesh provides the required resources and services efficiently and securely to every authorized microservice. The strength of the Service Mesh model lies in its infrastructure capability.
 
[st_adsense]  

When does a Service Mesh make sense?

The use of a Service Mesh makes sense for complex, demanding, and security-critical distributed applications if the number of microservice instances is too large and increased requirements are placed on interoperability, flexibility, scalability, configurability, maintainability, and security. The Service Mesh separates the communication, transaction, and security tasks of a distributed application from data processing and presentation. The Service Mesh realizes its tasks as services that it makes available to every authorized microservice. Each individual microservice communicates with the outside world through an embedded software proxy, which takes on the communication and security tasks and forwards the required data and transactions via the standardized interfaces. A Service Mesh makes complex, distributed applications agile, flexible, transparent, and secure.

A Service Mesh is not yet mature and widespread software technology. Although Service Mesh technology is strategically correct and leads directly to Industry 4.0, its operational uses are still isolated and isolated. It is not yet possible to provide evidence of best practice experience in order to accelerate development with this technology and avoid possible implementation errors and difficulties. Nevertheless, this technological path is suitable for ambitious, innovative large companies that quickly reach their limits with conventional microservices technology and want to achieve more flexibility, agility, and transparency with a Service Mesh.

Service Mesh is responsible for the reliable transmission of requests and the delivery of responses via a cloud topology. For the application services, Service Mesh provides an application-specific infrastructure and the infrastructure services that a modern application needs to function in the cloud. A service mesh is best suited for new demanding and security-critical applications that are specially developed for cloud networks.
 
[st_adsense]  

How does a Service Mesh work and how does it differ from microservices?

A Service Mesh solves the tasks of the control plane and controls the entire data communication on behalf of the microservices. The Service Mesh builds a software-supported virtualized network infrastructure for the microservices and provides the microservices with numerous infrastructure services. Typical services of Service Mesh include service discovery, authentication, encryption (mTLS, etc.), load balancing, and access control.

The Service Mesh uses dynamic routing rules to determine the recipient of the request. After the desired recipient has been found, it requests the corresponding pool of instances from the discovery service of the corresponding endpoint. If the information received does not match its own information, the Service Mesh decides which information source to trust. Based on a number of factors such as If there is a delay in the last request, the Service Mesh selects the instance that will likely return a quick response. If the target instance keeps returning errors, the Service Mesh removes them from the load-balancing pool and checks them regularly in the future (the malfunction can be short-term). If the timeout provided for the request occurs, the Service Mesh returns a critical request error and does not attempt to retry the same failed transaction. The Service Mesh logs the observed communication behavior in the form of metrics and tracking and sends this data to a central metric system.

To create a better structure, the application layer of a component is divided into several smaller services. These are known as microservices. The Service Mesh differs from a microservice in that each microservice instance has its own (read “personal”) embedded Layer7 proxy. The pair consisting of a microservice and a responsible Service Mesh proxy is located in the same container. The Service Mesh proxy combines the functionalities of a proxy server and a reverse proxy server, carries out all communications and transactions on behalf of the microservice, and forwards incoming external requests to the microservice. Like the outside world, the microservice only knows its Service Mesh proxy and communicates exclusively with the proxy, not with the cloud. Thus, the data plane (data plane) and the control plane are effectively separated from each other in a Service Mesh container. The additional infrastructure tasks of a Service Mesh include tracing, traffic control, and the collection of metrics.

In a Service Mesh, the infrastructure functions are moved to the control plane. This functional relief makes every microservice leaner and less complex. Without Service Mesh support, microservice monoliths had to implement and run the infrastructure functions (security, networking) themselves.
 
[st_adsense]  

Properties and special features of a Service Mesh

Organizing and orchestrating the interaction of microservices is not only a complex process, but also a fundamental property of a Service Mesh. While the TCP protocol (Layer 4) handles individual transport errors in communication, the Service Mesh must also handle network failures in order to maintain the reliability of the application functions and to solve possible communication problems in real-time.

A special feature of Service Mesh is that it’s completely accommodated and implemented as a network model on protocol layer 7 (application layer of the ISO / OSI layer model). Each Service Mesh instance works as an embedded Layer7 proxy and serves its microservice instance, for which it’s responsible and with which it works in pairs on a host.

While traditional network applications such as client-server applications simply require an external network infrastructure and the security and reliability of this infrastructure, the Service Mesh provides the application with a virtualized network infrastructure and provides additional security functions such as load balancing, access control, authentication, and data encryption. The Service Mesh is implemented on a separate infrastructure service layer of the same application and has the required standardized interfaces. One interface is used for communication with the application instance and the other for communication with the cloud network on behalf of the application instance.

The Service Mesh is separated from the application layer and takes over all network-relevant functions that the components of the distributed application need for secure and reliable communication in clouds. The Service Mesh solves every network problem that occurs (a protocol error, a failure) and finds an optimal solution intelligently and in real-time. As long as alternative solutions exist and are possible, the application continues to function undisturbed and does not notice any communication disruptions that have occurred, as if nothing had happened.

The combination of the complexity and criticality of a distributed application means that a dedicated layer is required for the interaction between the microservices. This layer, which is implemented as a special communication service on the same host, is separate from the application code and is called the Service Mesh.
 
[st_adsense]  

How can you use and implement Service Mesh in development?

When implementing a Service Mesh, the main task of a developer lies in the conception, topology, and the configuration model, but not in the coding. There are several Service Mesh tools available for implementing and managing a Service Mesh. The most famous representatives of these tools are:

• Istio (from Google, IBM, Lyft)
• Linkerd (Linkerd 1 and 2 from Buoyant; open-source project; available under the Apache 2.0 license; Linkerd 2 is limited to Kubernetes)
• Consul Service Mesh (by HashiCorp)
• Red Hat OpenShift Service Mesh (Istio + Jaeger as tracing system + Kiali for visualization)

The topology, policies, and ACL rules can be defined and configured with these tools, so that there is no programming effort for you. Additional tools such as Prometheus (monitoring) and Zipkin (tracing) are available for special tasks. You can visualize the Service Mesh topology with a tool like Kiali.

With Linkerd you can develop a lean Service Mesh quickly and easily. The implementation has a minimal configuration and offers immediate added value. This is very important because increased configuration complexity is a known weak point in Service Mesh solutions.

Microsoft, HashiCorp, Buoyant, and Solo.io have jointly developed an API specification for Service Mesh – the Service Mesh Interface (SMI). The SMI is supported by Istio and Linkerd. The official tutorials from Istio and Linkerd are the best way to get started and implement a Service Mesh.
 

Conclusion

Moving from monolithic apps through containers and microservices to a Service Mesh significantly improves the flexibility, structurability, and maintainability of distributed applications and increases the architecture level. The Service Mesh model helps increase stability, manageability, communication reliability, and resilience. Distributed applications built and implemented according to the concept of Service Mesh generally do without a traditional client-server model and are best suited for cloud environments.

Cloud-based network technologies and Service Mesh applications are an ideal match and will continue their further development and success together. Although Service Mesh technology is still in its infancy and not yet mature enough for broad market use, cloud mesh has the best chance of replacing the client-server model in the cloud market segment, expanding the market in the near future, and become a leading application technology for clouds. In order for a Service Mesh to meet expectations and to carry out its orchestration tasks smoothly, error-free, and transparently. The infrastructure services, the API interfaces, and the protocols used in all app components involved (microservices, proxies) must be implemented in a uniform, consistent, and standards-compliant manner. In order to secure the future of this future-oriented technology, the Service Mesh should establish itself as a pioneer of cloud technology and develop itself into an industrial standard for distributed cloud-based applications.
 
[st_adsense] MCQPractice competitive and technical Multiple Choice Questions and Answers (MCQs) with simple and logical explanations to prepare for tests and interviews.Read More