Cloud Native Checklist
- Cloud Native checklist
- Principles and Practices
Cloud Native checklist
|Capability||Yes / No|
|Domain Context diagram current with dependencies shown|
|Logs stream or self-purge|
|Dynamically configurable log levels|
|Database connections self-heal|
|Dependency connections self-heal|
|Service auto-restarts on failure|
|Automated resource and performance monitoring|
|Have NFRs & SLAs defined for each service|
|Automated alerting for SLAs and NFRs|
|No manual install steps|
|Utilize Correlation ID|
|Automated smoke tests after each deployment|
|Heartbeat responds in less than 1 minute after startup|
|No start-up ordering required|
|Minimal critical dependencies|
|Graceful degradation for non-critical dependencies|
|Circuit breakers and request throttles in place|
Principles and Practices
While practices may change over time, principles are expected to be less volatile.
Small, autonomous, highly-cohesive services
- Prefer event-driven, asynchronous communications between services.
- Prefer eventual consistency / replication of select data elements over shared data structures.
- Be cautious about creating shared binary dependencies across services.
- Services are able to be checked out and run locally using embedded DBs, and/or mocked endpoint dependencies as necessary.
Hypermedia-driven service interactions
- Model resources on the domain.
- Use embedded links to drive resource state transitions.
- HATEOAS Reference
Modeled around business concepts
- Produce a system context diagram to understand your system boundaries. Consider following c4 architecture diagramming techniques.
- Follow Domain Driven Design practices to understand your domain early in development, and model your domain in your code.
- Use bounded contexts to isolate service boundaries and converse with canonical-model-based systems.
Hide internal implementation details
- Model bounded contexts
- Use packaging to scope components.
- Services own their data & hide their databases.
- No database-driven integration.
- Technology-agnostic APIs (ReST).
- Self-service whenever possible.
- Teams own their services (but also consider internal open source practices).
- Align teams to the organization.
- Prefer choreography over orchestration.
- Dumb middleware, smart endpoints.
- Deployable to cloud and local (DC/store) environments
- Coexist versioned endpoints.
- Prefer targeted releases of individual services over habitual mass-installs of several services at once.
- Avoid tightly bound client/server stub generation.
- One service per host.
- Blue/green release testing techniques.
- Consumer-driven upgrade decisions.
- Don’t treat remote calls like local calls.
- Set timeouts appropriately (consider TCP connect and read timeouts in the 90ish-percentiles)
- Apply bulk-heading & circuit breaker patterns to limit fallout of failure.
- Understand and design for what should happen during network partitioning (network failures)
- Use redundancy & load balancing
- Monitored endpoints.
- Use synthetic transactions to simulate real user behavior.
- Aggregate logs and statistics.
- Use correlation IDs to trace calls throughout the system.
Culture of automation
- Automated developer driven testing: unit, functional, contract, integration, performance, & etc.
- Deploy the same way everywhere.
- Implement continuous delivery practices.
- Trunk based development over branching by feature/team/release to promote continuous integration practices.
- In the face of a lack of automation/provisioning/monitoring, prefer a properly structured monolith over many segregated smaller services.
- Building Microservices by Sam Newman
- 12 Factor Application
- Production Ready Microservices (PDF)
- Choosing an HTTP Status Code
Last modified February 2, 2022: Switch to hugo (#2) (a244f74)