Chapter 8. Accessing apps: Services, routing, and service discovery

This chapter covers

  • Single services representing multiple app instances
  • Server-side load balancing
  • Client-side load balancing
  • Dynamic routing to service instances
  • Service discovery

I’ve already been going on a bit about apps being deployed as multiple instances but needing to behave as a single logical entity. You learned that you must keep your apps stateless so that one request to an app isn’t dependent on previous requests having hit the same instance. You saw how configurations need to be carefully managed across all instances so as to ensure the same outcome regardless of which instance ends up serving a particular request, even during application lifecycle events. At this point, I want to formalize this single logical entity, and in doing so you’ll be able to get rid of the brittle connectivity between the three microservices in our sample application.

Bear with me a moment while I start with first principles. They’re important. You know your apps will be deployed as multiple instances, thereby affording you an effective way to scale deployments to meet demand, and to create a more resilient system. Figure 8.1 shows multiple instances for each of the three apps that make up our running example.

Figure 8.1. In cloud-native software, apps are deployed as multiple instances. For the software to function predictably, you want each set of app instances to operate as a single logical entity.

8.1. The service abstraction

8.2. Dynamic routing

8.3. Service discovery

Summary

sitemap