DevOps: A Software Architect's Perspective Book Review

This is the first DevOps book that shows a realistic and achievable view of the full implementation of DevOps. Most of the books and other literature I have read on DevOps are all about the culture, the attitudes, how it relates to Agile and Lean practices, and a high level view of microservices. This book includes all that, but they are not its main focus, and it goes several steps further with respect to the architecture and infrastructure needed for the implementation. The book is broken down into 5 parts. I have listed each part below along with the chapters they include. Part One: Background Chapter 1. What Is DevOps? Chapter 2. The Cloud as a Platform Chapter 3. Operations Part Two: The Deployment Pipeline Chapter 4. Overall Architecture Chapter 5. Building and Testing Chapter 6. Deployment Part Three: Crosscutting Concerns Chapter 7. Monitoring Chapter 8. Security and Security Audits Chapter 9. Other Ilities Chapter 10. Business Considerations Part Four: Case Studies Chapter 11. Supporting Multiple Datacenters Chapter 12. Implementing a Continuous Deployment Pipeline for Enterprises Chapter 13. Migrating to Microservices Part Five: Moving Into the Future Chapter 14. Operations as a Process Chapter 15. The Future of DevOps The first chapter introduces DevOps and puts it into context with respect to the rest of the book. The definition of DevOps the authors provide focuses on the goals, rather than the means- DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality. They also identify five different categories of DevOps practices that help define their definition of DevOps. I have repeated them below. 1. Treat Ops as first-class citizens from the point of view of requirements. 2. Make Dev more responsible for relevant incident handling. 3. Enforce the deployment process used by all, including Dev and Ops personnel. 4. Use continuous deployment. 5. Develop infrastructure code, such as deployment scripts, with the same set of practices as application code. Chapter 1 also talks about the reduction of coordination and different barriers that can present themselves. The barriers include the culture, type of organization, the goals operations verses development, silo mentality, tool support, and personnel issue such as the difference in salaries between developers and operation staff. Moving operation tasks to a developers plate may not make much sense if the time to do the task is not drastically reduced. Chapter 2 gives a nice introduction to using a cloud environment as a platform. The way in which this book describes the implementation of DevOps, the cloud is a key component. The chapter does a really great job of introducing a ton of material in a very concise way. They start by introducing and discussing the characteristics of the cloud- on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Chapter 2 also covers the 3 types of service - Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). The authors go into detail of how the cloud impacts DevOps - the ability to create and switch environments simply, the ability to create VMs easily, and the management of databases. Chapter 3 is a discussion of the core concepts and phases of Information Technology Infrastructure Library (ITIL) and how traditional IT Ops and DevOps interact. Part 2 covers the deployment pipeline. This part is where the microservice architectural style is covered. Deploying, monitoring, debugging, performance management, testing, and team skills are all different than what most development teams are going to be used to. Most teams will not be able to achieve instancing a microservice architecture, for various reasons, but there are some really good practices in this part of the book that teams can achieve. I just got done researching microservices and NServiceBus. I came to the conclusion I would not be able to move in that direction in my current environment. Although team skills where of some concern, the culture is what killed the possibility. It is a command and control environment that is anything but transparent. In order to make such a fundamental shift in the way things are done there would have to be major changes. The environment allows for no agile or lean practices, although it claims to be agile, and is completely closed to change. Certain parts of the book may come across as completely academic and unrealistic, but depending on your environment all best practices and software development principles written by the gurus of our profession may be unrealistic. Do yourself a favor and push through. The case studies do a great job of taking the first three part of the book and showing how organizations are doing their best to move towards a DevOps environment. I thought the case studies were very thorough, maybe even too thorough. Although I think SEI's books contain some of the most important information that has been released in our industry, their books are not always the easiest to read. For as short as this one is, it took me quite a while. A lot of that was my schedule, but not all of it. I can tell you from experience that most of the places I go think the same thing about all of SEI's materials. They mostly view it as purely academic. They are wrong. The places that have allowed me to practice the processes found in Software Product Lines: Practices and Patterns, Software Architecture in Practice, Documenting Software Architectures: Views and Beyond, Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives, CMMI for Development, and The CERT Guide to Insider Threats, have seen how well their advice works. Places that don't allow me to apply the practices only did themselves a disservice because I did them anyway. It is the only way I know how to successfully build complex software successfully. For those places that micromanaged my activities to make sure I was not wasting time documenting or planning I had to tell - Find someone else to do it. I don't know how to build something wrong, and I have no interest in learning how to. Right now in my current environment they would love me to come in, sit down, shut up, and just go with the flow. The problem with that is the flow is currently taking us down a toilet hole, so I have no choice but to go against the flow! If DevOps can make it across the chasm you will be very happy to have the material found in this book in your arsenal of knowledge.

DevOps: A Software Architect's Perspective (SEI Series in Software Engineering)

DevOps: A Software Architect's Perspective (SEI Series in Software Engineering)