Cloud Native Infrastructure with Azure

Chapter 7. Service Discovery and Service Mesh: Finding New Territories and Crossing Borders

As modern applications moved to a microservices architecture, they became scalable and efficient over the cloud. Microservices favor breaking down an application into independent, decoupled components. Decoupling is usually achieved by separating the codebases into standalone applications that are connected using the network and well-defined APIs/interfaces that microservices use to communicate. Once you move your applications to a microservices architecture, a lot of opportunities open up: you can scale each individual service, decouple the release cycle for each service, choose a different language to write your individual application components, and even organize your team structure based on these independent services.

However, now that you have broken your application into smaller applications, these binaries have their own lifecycle. This lifecycle gets scheduled independently and terminated independently as needed, while it’s maintaining communication over the network. Imagine if, in this scenario, you had a lot of microservices running and communicating with one another. You would likely start asking several questions, including the following:

• How do the services communicate with one another when they are dynamic in nature? (That is, since services communicate over a network, the IP address doesn’t provide enough information to reach the services as they can be terminated independently ...