Architecting for DevOps

Principle · Chapter 13

Architecting for DevOps

Some DevOps practices are independent of architecture, but certain practices only pay off with the right architectural decisions. Architects should weigh DevOps when designing systems and defining architecturally significant requirements.

Important quality attributes for DevOps

Systems architected for DevOps emphasize testability, deployability, and maintainability.

• Testability — crucial because tests are automated. Requires:
  • Components isolated so they can be tested independently.
  • Controllability — dictate inputs to exercise the component.
  • Observability — see inputs and outputs to judge correctness.
  • See Testability.
• Maintainability — needed to make and deploy changes fast. Improve it by:
  • Minimizing complexity (easier to understand and change; shorter cycle times).
  • Reducing component size, increasing cohesion, reducing coupling.
  • See Maintainability.
• Deployability — how easily and reliably the system deploys from staging into production. Even a testable system loses CD’s value if changes can’t reach production. Improve it by:
  • Minimizing environment differences — staging and production as similar as possible, so a successful staging delivery predicts a successful production deploy.
  • Separating application from configuration — environment-specific config (e.g. DB connection info) lives in external configuration, not in code.

Design for operations and for failure

• Consider operations when gathering requirements: robust monitoring and logging help ops detect faults fast and diagnose issues. These rarely need intrusive architectural changes but matter when changes ship fast and often.
• Design for failure: expect failures and build in fault tolerance so recovery is quick and downtime minimal.

Patterns that complement DevOps

The microservice architecture fits DevOps requirements well (orgs adopting one often adopt the other):

• Small, focused services with well-defined interfaces → changes are easier and less risky; implementations can be swapped as long as the interface holds.
• Each service is autonomous and independently deployable, can own its data, and deploys with low risk and quick downtime.
• Better fault isolation than a monolith: one failing service doesn’t take down the whole system; monitoring plus reverting a bad deployment enables fast recovery.
• DevOps doesn’t require microservices, but some patterns work better than others.
• See Microservice architecture.

Related

• DevOps practices
• Deploying to the cloud
• Quality attributes

Citations

• Software Architect’s Handbook (Packt, 2018), Ch.13 “Architecting for DevOps”, pp. 1016-1019.