In this chapter from DevOps: A Software Architect's Perspective , the authors discuss how DevOps achieves its goals partially by replacing explicit coordination with implicit and often less coordination, and how the architecture of the system being developed acts as the implicit coordination mechanism. They begin by discussing whether DevOps practices necessarily imply architectural change.



A distributed system is one in which the failure of a computer you didnt even know existed can render you own computer unusable.

—Leslie Lamport

In this chapter we begin to see the structural implications of the DevOps practices. These practices have implications with respect to both the overall structure of the system and techniques that should be used in the systems elements. DevOps achieves its goals partially by replacing explicit coordination with implicit and often less coordination, and we will see how the architecture of the system being developed acts as the implicit coordination mechanism. We begin by discussing whether DevOps practices necessarily imply architectural change.

4.1 Do DevOps Practices Require Architectural Change?

You may have a large investment in your current systems and your current architecture. If you must re-architect your systems in order to take advantage of DevOps, a legitimate question is Is it worth it? In this section we see that some DevOps practices are independent of architecture, whereas in order to get the full benefit of others, architectural refactoring may be necessary.

Recall from Chapter 1 that there are five categories of DevOps practices.