Real World Software Architecture

Real World Software Architecture is dedicated to providing information and experiences from the field of Software Architecture.



Subscribe with RSS or ATOM Add to Google

Links

  • Home Page
  • Real World Software Process Engineering
  • Suggested Reading
  • .NET Dev and Arch Collection
  • SEI Essays on SA
  • Software Architecture
  • Bredemeyer
  • wwisa
  • Product Line Engineering
  • PLEES
  • Software Product Lines
  • MSDN Architecture Center
  • patterns & practices






Friday, September 04, 2015

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)

posted by tadanderson at 5:52 AM 0 comments

Previous Posts

  • DevOps: A Software Architect's Perspective Book Re...
  • Scaled Agile Framework (SAFe) LiveLessons Video Se...
  • Bulletproof Android: Practical Advice for Building...
  • Swift for Programmers Book Review
  • Security in Computing (5th Edition) Book Review
  • Swift in 24 Hours, Sams Teach Yourself Book Review
  • Sparx Systems Releases Enterprise Architect 12
  • Learning Swift Programming Book Review
  • Android Security Internals: An In-Depth Guide to A...
  • Adaptive Code via C#: Agile coding with design pat...



Archives

  • December 2005
  • January 2006
  • February 2006
  • March 2006
  • April 2006
  • June 2006
  • August 2006
  • October 2006
  • November 2006
  • December 2006
  • January 2007
  • February 2007
  • March 2007
  • April 2007
  • May 2007
  • June 2007
  • July 2007
  • August 2007
  • September 2007
  • October 2007
  • November 2007
  • December 2007
  • January 2008
  • February 2008
  • March 2008
  • April 2008
  • May 2008
  • June 2008
  • July 2008
  • August 2008
  • September 2008
  • October 2008
  • December 2008
  • January 2009
  • February 2009
  • March 2009
  • April 2009
  • May 2009
  • June 2009
  • July 2009
  • August 2009
  • September 2009
  • October 2009
  • November 2009
  • December 2009
  • January 2010
  • February 2010
  • March 2010
  • April 2010
  • May 2010
  • June 2010
  • August 2010
  • September 2010
  • October 2010
  • November 2010
  • December 2010
  • January 2011
  • February 2011
  • March 2011
  • April 2011
  • May 2011
  • June 2011
  • July 2011
  • August 2011
  • September 2011
  • October 2011
  • November 2011
  • December 2011
  • January 2012
  • February 2012
  • March 2012
  • April 2012
  • May 2012
  • June 2012
  • July 2012
  • August 2012
  • September 2012
  • October 2012
  • November 2012
  • December 2012
  • January 2013
  • February 2013
  • March 2013
  • April 2013
  • May 2013
  • June 2013
  • July 2013
  • August 2013
  • September 2013
  • October 2013
  • November 2013
  • December 2013
  • January 2014
  • February 2014
  • March 2014
  • April 2014
  • May 2014
  • June 2014
  • July 2014
  • August 2014
  • September 2014
  • October 2014
  • December 2014
  • February 2015
  • March 2015
  • April 2015
  • June 2015
  • July 2015
  • September 2015

Powered by Blogger