Architecture predicts DevOps success

I recently authored a post for the AWS Architecture blog regarding why DevOps requirements are important when making architectural decisions - said another way, is why considerations for how you’re going to deploy and maintain an application is important at design time. Here in this post I want to provide some of the context and thinking around why I wrote that post

I wish I could put it as succinctly as Chris Richardson does in his post on microservice architecture: enabling rapid, reliable, frequent and sustainable development

The requirement to deliver software rapidly, frequently and reliably is achieved using DevOps and small teams, which requires a loosely coupled, modular and deployable architecture. But how does one achieve such an architecture? By incorporating key characteristics in the architecture, of which I highlighted three in my post:

1. Deployability: Flow and agility to consistently deploy new features
2. Observability: feedback about the state of the application
3. Disposability: throwing away resources and provision new ones quickly

The first two were primarily inspired by The Three Ways: The Principles Underpinning DevOps from the The DevOps Handbook:, How to Create World-Class Agility, Reliability, and Security in Technology Organizations by Gene Kim, Jez Humble, Patrick Debois, John Willis

I’ve selected a few quotes from the book, highlighting the importance of the correct architecture:

Indeed, one of the findings in the 2015 State of DevOps Report validated that the age of the application was not a significant predictor of performance; instead, what predicted performance was whether the application was architected (or could be re-architected) for testability and deployability.

the architecture allows small teams to work safely and architecturally decoupled from the work of other teams who use self-service platforms that leverage the collective experience of Operations and Information Security. Instead of everyone waiting all the time, with large amounts of late, urgent rework, teams work independently and productively in small batches, quickly and frequently delivering

Overly tight architecture: We cannot achieve deployments on demand if overly tight architecture means that every time we want to make a code change we have to send our engineers to scores of committee meetings in order to get permission to make our changes. Our countermeasure is to create more loosely-coupled architecture so that changes can be made safely and with more autonomy, increasing developer

As Randy Shoup, formerly a director of engineering at Google, observed, large organizations using DevOps “have thousands of developers, but their architecture and practices enable small teams to still be incredibly productive, as if they were a startup.”

Because our goal is to enable small teams of developers to independently develop, test, and deploy value to customers quickly and reliably, this is where we want our constraint to be. High performers, regardless of whether an engineer is in Development, QA, Ops, or Infosec, state that their goal is to help maximize developer productivity.

I’ve written about Org structures and Conways Law, regarding the importance of small multi-disciplinary that is fully responsible for all parts of the lifecycle of their products.

I also wanted to talk about Day 2 Ops, and that with the correct architecture, you can also design for the phases before Day:
Day 0: this maps to to the Deployability characteristic, helping developers to deploy
Day 1: Disposability helps to make the app more deployable, and Observeabiltty gives insight into the performance of the app when its running (after being deployed).

If I had to summarise all of this with a tagline, it would: True digital transformation lies at the intersection of Cloud, DevOps cultural practices, Agile principles, scalable architectures, and efficient team structures.

There were other noteworthy articles that helped shaped my post:

• Requirements vs architecture
• Microsoft Azures Architecture styles
• What is Developer Experience (DX)?
• Octoverse spotlight: An analysis of developer productivity
• Principles for Microservice Design: Think IDEALS, Rather than SOLID
• Monitoring and Observability — What’s the Difference and Why Does It Matter?

I really benefited from listening to The Idealcast with Gene Kim by IT Revolution: Architecture as the Organizing Logic for Components, and the Means for their Construction, which talks about how architecture is one top predictors of performance.