@DevOpsSummit Authors: Elizabeth White, Zakia Bouachraoui, Pat Romanski, Liz McMillan, AppDynamics Blog

Related Topics: @DevOpsSummit, Microservices Expo, Open Source Cloud, Containers Expo Blog

@DevOpsSummit: Article

DevOps Book Review | @DevOpsSummit #DevOps #Containers #Microservices

SEI Series in Software Engineering

DevOps: A Software Architect's Perspective

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 five 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)

More Stories By Tad Anderson

Tad Anderson has been doing Software Architecture for 18 years and Enterprise Architecture for the past few.

@DevOpsSummit Stories
Today most companies are adopting or evaluating container technology - Docker in particular - to speed up application deployment, drive down cost, ease management and make application delivery more flexible overall. As with most new architectures, this dream takes significant work to become a reality. Even when you do get your application componentized enough and packaged properly, there are still challenges for DevOps teams to making the shift to continuous delivery and achieving that reduction in cost and increase in speed. Sometimes in order to reduce complexity teams compromise features or change requirements
GCP Marketplace is based on a multi-cloud and hybrid-first philosophy, focused on giving Google Cloud partners and enterprise customers flexibility without lock-in. It also helps customers innovate by easily adopting new technologies from ISV partners, such as commercial Kubernetes applications, and allows companies to oversee the full lifecycle of a solution, from discovery through management.
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, discussed why containers should be paired with new architectural practices such as microservices rather than mimicking legacy server virtualization workflows and architectures.
Using serverless computing has a number of obvious benefits over traditional application infrastructure - you pay only for what you use, scale up or down immediately to match supply with demand, and avoid operating any server infrastructure at all. However, implementing maintainable and scalable applications using serverless computing services like AWS Lambda poses a number of challenges. The absence of long-lived, user-managed servers means that states cannot be maintained by the service. Longer function invocation times (referred to as cold starts) become very important to track, because they impact the response time of the service and will impose additional cost. Additionally, the transition to smaller individual components (much like breaking a monolithic application into microservices) results in a simpler deployment model, but makes the system as a whole increasingly complex.
In 2014, Amazon announced a new form of compute called Lambda. We didn't know it at the time, but this represented a fundamental shift in what we expect from cloud computing. Now, all of the major cloud computing vendors want to take part in this disruptive technology. In his session at 20th Cloud Expo, John Jelinek IV, a web developer at Linux Academy, will discuss why major players like AWS, Microsoft Azure, IBM Bluemix, and Google Cloud Platform are all trying to sidestep VMs and containers with heavy investments in serverless computing, when most of the industry has its eyes on Docker and containers.