Deployment Patterns MOC
Deployment Patterns MOC
Map of Content for microservices deployment and cloud-native release patterns. Covers two layers: (1) Microservices infrastructure patterns (Phase 14: Sidecar, Ambassador, Strangler Fig, Service Mesh, Circuit Breaker, API Gateway) and (2) Cloud-native release patterns (Phase 15: Blue/Green, Canary, Rolling, Feature Flags, 12-Factor App). These patterns sit above the enterprise integration layer (DDD/EIP/CQRS/Saga) and address how services are deployed, evolved, and released safely in production.
Evolutionary Lineage Chains
How deployment and release patterns derive from GoF and enterprise ancestors.
| Chain | Lineage |
|---|---|
| Proxy/Interception | Proxy-Pattern -> Sidecar-Pattern -> Ambassador-Pattern -> Service-Mesh-Pattern |
| Encapsulation/Migration | Facade-Pattern -> Anti-Corruption-Layer-Pattern -> Strangler-Fig-Pattern |
| Strategy/Variation | Strategy-Pattern -> Feature-Flags-Pattern -> Canary-Release-Pattern -> Blue-Green-Deployment |
| Decorator/Middleware | Decorator-Pattern -> Pipes-and-Filters -> Sidecar-Pattern |
Microservices Infrastructure Patterns
Patterns for structuring and operating individual services within a distributed system.
| Pattern | Intent | Suitability Threshold |
|---|---|---|
| Sidecar-Pattern | Attach auxiliary functionality to a service without modifying it | When cross-cutting concerns (logging, config, networking) must be language-agnostic |
| Ambassador-Pattern | Proxy outbound traffic from a service through a dedicated helper | When services need circuit breaking, routing, or telemetry on outbound calls |
| Service-Mesh-Pattern | Coordinate a fleet of sidecar proxies to manage all service-to-service communication | 10+ services AND dedicated platform team |
| Strangler-Fig-Pattern | Incrementally replace a legacy system by routing traffic to new implementations | When legacy modernisation is required but big-bang rewrite is too risky |
| Circuit-Breaker-Pattern | Prevent cascading failures by failing fast when a downstream service is unhealthy | When services call unreliable downstream dependencies |
| API-Gateway-Pattern | Single entry point for external clients, routing to internal microservices | When multiple microservices must be exposed through a unified external API |
Infrastructure selection guide: Start with Circuit Breaker and API Gateway — they address the most universal failure modes (cascading failures and multi-service exposure). Add Sidecar and Ambassador when cross-cutting concerns (telemetry, retries, auth) threaten to pollute service code. Escalate to Service Mesh only when 10+ services and a dedicated platform team justify the operational overhead. Use Strangler Fig only when a big-bang rewrite is too risky.
Cloud-Native Release Strategies
Patterns for deploying new versions of services with controlled risk.
| Pattern | Intent | Key Constraint |
|---|---|---|
| Blue-Green-Deployment | Atomic switch between two identical production environments | Requires 2x infrastructure capacity; DB schema must be backward-compatible |
| Canary-Release-Pattern | Gradual traffic shift to new version based on observed metrics | Requires automated rollback triggers; Feature Flags enable traffic splitting |
| Rolling-Deployment | Replace instances one-by-one until all run the new version | Requires stateless services; both versions coexist during rollout |
Choosing a release strategy:
- Blue/Green when: high-risk change, instant rollback needed, compliance/audit, budget for 2x capacity
- Canary when: gradual confidence needed, observable metrics available, A/B testing desired
- Rolling when: low-risk change, cost-constrained, stateless services, Kubernetes default is sufficient
For the full 8-row comparison table, see Blue-Green-Deployment#Choosing a Release Strategy.
Supporting Patterns
Foundational patterns that enable and underpin the release strategies above.
| Pattern | Role |
|---|---|
| Feature-Flags-Pattern | Runtime strategy selection enabling Canary traffic splitting and Blue/Green pre-validation |
| 12-Factor-App | Foundational methodology: stateless processes, config from environment, dev/prod parity |
Cross-Layer References
These MOCs cover the upstream pattern layers that deployment patterns build upon.
- GoF-Patterns-MOC — GoF patterns are upstream ancestors (Proxy, Facade, Strategy, Decorator originate here)
- Enterprise-Patterns-MOC — DDD/EIP/CQRS/Saga sit between GoF and deployment layers; lineage chains connect all three
Sources
This MOC synthesizes patterns documented in Phases 14 (Microservices Deployment Patterns) and 15 (Cloud-Native Release Patterns). Individual pattern sources, implementation notes, and code examples are in their respective topic notes.