DevOps: A Software Architect's Perspective of Overall Architecture
- 4.1 Do DevOps Practices Require Architectural Change?
- 4.2 Overall Architecture Structure
- 4.3 Quality Discussion of Microservice Architecture
- 4.4 Amazon's Rules for Teams
- 4.5 Microservice Adoption for Existing Systems
- 4.6 Summary
- 4.7 For Further Reading
This chapter is from the book
This chapter is from the book
This chapter is from the book
- 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.
- Treat Ops as first-class citizens from the point of view of requirements. Adding requirements to a system from Ops may require some architectural modification. In particular, the Ops requirements are likely to be in the area of logging, monitoring, and information to support incident handling. These requirements will be like other requirements for modifications to a system: possibly requiring some minor modifications to the architecture but, typically, not drastic modifications.
- Make Dev more responsible for relevant incident handling. By itself, this change is just a process change and should require no architectural modifications. However, just as with the previous category, once Dev becomes aware of the requirements for incident handling, some architectural modifications may result.
- Enforce deployment process used by all, including Dev and Ops personnel. In general, when a process becomes enforced, some individuals may be required to change their normal operating procedures and, possibly, the structure of the systems on which they work. One point where a deployment process could be enforced is in the initiation phase of each system. Each system, when it is initialized, verifies its pedigree. That is, it arrived at execution through a series of steps, each of which can be checked to have occurred. Furthermore, the systems on which it depends (e.g., operating systems or middleware) also have verifiable pedigrees.
- Use continuous deployment. Continuous deployment is the practice that leads to the most far-reaching architectural modifications. On the one hand, an organization can introduce continuous deployment practices with no major architectural changes. See, for example, our case study in Chapter 12. On the other hand, organizations that have adopted continuous deployment practices frequently begin moving to a microservice-based architecture. See, for example, our case study in Chapter 13. We explore the reasons for the adoption of a microservice architecture in the remainder of this chapter
- Develop infrastructure code with the same set of practices as application code. These practices will not affect the application code but may affect the architecture of the infrastructure code.