Cloud Native Patterns: Designing Change-tolerant Software

1. Cloud-Native (CN) Software

  • Cloud-native software
    • Cloud is about where we are computing. Cloud-native is about how.
    • It’s resilient against changes (redundant).
    • Smaller, loosely coupled and independent services that can be released in an agile method.
    • Scales dinamically and continues to function adequately.
    • DIAGRAM
    • It must be distributed to protect against failure.
    • It should adapt to changes.

Cloud-native software is highly distributed, must operate on a constantly changing environment, and is itself constantly changing.

  • Familiar elements of a basic software architecture
    • App implements key business logic.
    • The App depends on Services, which may store business logic or data.
    • DIAGRAM
    • An App depends on multiple services, which depend on other services.
    • Some apps depend on stateful services.
    • Apps will have most of the time many instances deployed
    • Some services are stateless, whereas others are stateful.

The Three Parts of Cloud-Native Software

  1. The cloud-native app is where you write code, containing the business logic of your software.
    • The right patterns should be used for each component to integrate well with each other.
    • It should be constructed in a manner that allows cloud-native operational patterns such as upgrading or scaling to be performed.
  2. Cloud-native data is where the state lives in your cloud-native software. Data (and databases) are decomposed and distributed.
  3. Cloud-native interactions define how cloud-native apps and cloud-native data interact - many of these patterns are new. They may be request/response, push-centric or pull-centric.

Cloud-Native Apps Concerns

  • Their capacity is scaled up or down by adding or removing instances (scale-out/in).
  • Keep the state separated from the apps for faster recovery (resilience).
  • Configuration has to be shared between distributed deployments.
  • The application lifecycle (start, configure, reconfigure and shutdown) must be re-evaluated in this context.

Cloud-Native Data Concerns

  • Centralized data models are slow to evolve, brittle and affects the agility and robustness of loosely coupled apps.
  • The distributed data fabric is made of independent, fit-for-purpose databases, as well as some that may be acting only as materialized views of data, where the source of truth lies elsewhere.
    • Caching is a key pattern and technology in cloud-native software.

Cloud-Native Interactions

  • Accessing an app when it has multiple instances requires a routing system.
  • Synchronous request/response and asynchronous event-driven patterns must be addressed.
  • Automatic retries and circuit breakers must be taken into account.

2. Running Cloud-Native Applications in Production

  • Factors that contribute to the difficulty in deploying software and keeping it running well in production:
    • Snowflakes: difference between environments and artifacts being deployed (“it works on my machine!”).
    • Risky deployments: often deployments require or cause downtime.
    • Change is the exception: the app is considered stable and simply handed over to an operations team.
    • Production instability: an unstable production environment makes deployments harder to make.
  • Factors that develop a system of effiency, predictability, and stability.

DIAGRAM

Continuous Delivery

Repeatability

Safe deployments

Change is the rule

3. The Platform for Cloud-Native Software