Service Mesh
In Chapter 7 , “Integrating Microservices,” we discussed that microservices have to talk to each other and inter-service communication is one of the key challenges in realizing the microservices architecture. In the conventional Service Oriented Architec
- PDF / 1,152,143 Bytes
- 30 Pages / 504 x 720 pts Page_size
- 58 Downloads / 272 Views
Service Mesh In Chapter 7, “Integrating Microservices,” we discussed that microservices have to communicate with each other and inter-service communication is one of the key challenges in realizing the microservices architecture. In the conventional Service Oriented Architecture (SOA), the centralized Enterprise Service Bus (ESB) facilitated most of the inter-service communication requirements and with the shift to the smart endpoints and dumb pipes with Microservices architecture, now the service developers have to take care of all the complexities of inter-service communication. Service Mesh has immerged as a pattern to overcome most of these challenges. It does this by providing a generic distributed layer that encapsulates the commodity features of inter-service communication which are not part of the business logic of the service.
Note Some of the concepts and examples in this chapter may require prior knowledge of Docker and Kubernetes. If you are new to either of these technologies, we recommend you read Chapter 8, “Deploying and Running Microservices” first. In this chapter, we delve deep into the motivation and key concepts behind the Service Mesh pattern. Then we discuss some of the main Service Mesh implementations with real-world examples.
Why Service Mesh? The main motivation behind the inception of Service Mesh is the challenges we started to encounter after the elimination of the centralized ESB architecture, which lead us to build smart endpoints and dumb pipes. As with many emerging technologies, there is a lot of hype around the microservices architecture. Most people think that microservices architecture is the answer to all the problems they had with the previous SOA/ESB architecture. However, when we © Kasun Indrasiri and Prabath Siriwardena 2018 K. Indrasiri and P. Siriwardena, Microservices for the Enterprise, https://doi.org/10.1007/978-1-4842-3858-5_9
263
Chapter 9
Service Mesh
observe the real-world microservices implementations, we can see that most of the functionalities that a centralized bus (ESB) supports are now implemented at the microservices level. We are more or less solving the same set of fundamental problems, but we are solving them at different dimensions with microservices. For example, let’s consider a scenario where you need to call multiple downstream services in a resilient manner and expose the functionality as an another microservice. As shown in Figure 9-1, with the ESB architecture, you can easily leverage the built-in capabilities of ESB, in order to build virtual/composite services and functionalities such as circuit breakers, timeouts, service discovery, etc., which are useful during inter-service communication, are already provided as out of the box capabilities of an ESB.
Figure 9-1. From ESB to smart endpoints and dumb pipes When you implement the same scenario using microservices, you no longer have a centralized integration/ESB layer, but a set of microservices. You have to implement all these functionalities at the each microservice level. Therefo
Data Loading...
