Welcome!

@DevOpsSummit Authors: Pat Romanski, Elizabeth White, Liz McMillan, Dalibor Siroky, Stackify 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
ChatOps is an emerging topic that has led to the wide availability of integrations between group chat and various other tools/platforms. Currently, HipChat is an extremely powerful collaboration platform due to the various ChatOps integrations that are available. However, DevOps automation can involve orchestration and complex workflows. In his session at @DevOpsSummit at 20th Cloud Expo, Himanshu Chhetri, CTO at Addteq, will cover practical examples and use cases such as self-provisioning infrastructure/applications, self-remediation workflows, integrating monitoring and complimenting integrations between Atlassian tools and other top tools in the industry.
As DevOps methodologies expand their reach across the enterprise, organizations face the daunting challenge of adapting related cloud strategies to ensure optimal alignment, from managing complexity to ensuring proper governance. How can culture, automation, legacy apps and even budget be reexamined to enable this ongoing shift within the modern software factory? In her Day 2 Keynote at @DevOpsSummit at 21st Cloud Expo, Aruna Ravichandran, VP, DevOps Solutions Marketing, CA Technologies, was joined by a panel of industry experts and real-world practitioners who shared their insight into an emerging set of best practices that lie at the heart of today's digital transformation.
"Storpool does only block-level storage so we do one thing extremely well. The growth in data is what drives the move to software-defined technologies in general and software-defined storage," explained Boyan Ivanov, CEO and co-founder at StorPool, in this SYS-CON.tv interview at 16th Cloud Expo, held June 9-11, 2015, at the Javits Center in New York City.
As Marc Andreessen says software is eating the world. Everything is rapidly moving toward being software-defined – from our phones and cars through our washing machines to the datacenter. However, there are larger challenges when implementing software defined on a larger scale - when building software defined infrastructure. In his session at 16th Cloud Expo, Boyan Ivanov, CEO of StorPool, provided some practical insights on what, how and why when implementing "software-defined" in the datacenter.
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, answered these questions and demonstrated techniques for implementing advanced scheduling. For example, using spot instances and cost-effective resources on AWS, coupled with the ability to deliver a minimum set of functionalities that cover the majority of needs – without configuration complexity.