Deployment Approaches - Serverless Applications Lens

This whitepaper is in the process of being updated.

Deployment Approaches

A best practice for deployments in a microservice architecture is to ensure that a change does not break the service contract of the consumer. If the API owner makes a change that breaks the service contract and the consumer is not prepared for it, failures can occur.

Being aware of which consumers are using your APIs is the first step to ensure that deployments are safe. Collecting metadata on consumers and their usage allows you to make data driven decisions about the impact of changes. API Keys are an effective way to capture metadata about the API consumer/clients and often used as a form of contact if a breaking change is made to an API.

Some customers who want to take a risk-adverse approach to breaking changes may choose to clone the API and route customers to a different subdomain (for example, v2.my-service.com) to ensure that existing consumers aren’t impacted. While this approach enables new deployments with a new service contract, the tradeoff is that the overhead of maintaining dual APIs (and subsequent backend infrastructure) requires additional overhead.

The table shows the different approaches to deployment:

Deployment Consumer Impact Rollback Event Model Factors Deployment Speed
All-at-once All at once Redeploy older version Any event model at low concurrency rate Immediate
Blue/Green All at once with some level of production environment testing beforehand Revert traffic to previous environment Better for async and sync event models at medium concurrency workloads Minutes to hours of validation and then immediate to customers
Canary/Linear 1–10% typical initial traffic shift, then phased increases or all at once Revert 100% of traffic to previous deployment Better for high concurrency workloads Minutes to hours