Chapter 5. App redundancy: Scale-out and statelessness

 

This chapter covers

  • Scale-out as a central tenet of cloud-native apps
  • Pitfalls of stateful apps in cloud-native software
  • What it means for an app to be stateless
  • Stateful services and how they’re used by stateless apps
  • Why sticky sessions shouldn’t be used

The title says “Scale-out,” but really, it’s not just a matter of scaling. There are many reasons for what is probably the core tenet of cloud-native software: redundancy. Whether your application components are micro or macro, whether they can be configured via environment variables or have config baked into property files, whether they fully implement fallback behaviors or not, a key to change tolerance is that there is no single point of failure. Apps always have multiple instances deployed.

But then because any one of those multiple instances of the app can satisfy a request (and you’ll see shortly why that is essential), you need those multiple instances to behave as a single logical entity. Figure 5.1 depicts this clearly.

Figure 5.1. Given the same input, the result produced by an app instance must be the same, regardless of whether there are one, two, or one hundred instances of the app.

5.1. Cloud-native apps have many instances deployed

5.2. Stateful apps in the cloud

5.3. HTTP sessions and sticky sessions

5.4. Stateful services and stateless apps

Summary