What is devops? This is the million-dollar question. CIOs are clamoring to get "the devops" ASAP to benefit from devops's promise of delivering software to customers faster, with fewer bugs by creating a culture where developers and operations work hand-in-hand.
The hype around devops is massive but even though the word devops was coined nearly eight years ago, people still are having trouble wrapping their head around the concept. Why? Because 'devops' is not a piece of software, it's not a project management principle, and it's not a new development methodology. devops is a culture and cultures are traditionally hard to define.
If devops has a foundation to build upon that foundation would probably be called The Three Ways. Originally developed by Gene Kim, these three principles underpin what devops is about. From here, many other principles are built but The Three Ways is what every other higher-level principle should be based on.
Systems thinking
First and foremost, devops organizations think in systems. One definition of a system is a set of processes working together towards a common goal. For a devops organization, that system is the business itself; not specific teams or departments. To release reliable software can entail many different processes and procedures. A team of developers has to write the code, testers then test the code, operations provisions the infrastructure for the code to run on, and the customers then consume the code. There can be hundreds or thousands of people and processes involved here.
Devops is meant to open your eyes and notice how your actions may affect not only you or your team but the entire system. This means a developer might have more visibility into the full lifecycle of a piece of code she wrote. It also means being more aware of the potential ramifications of that change rather than being able to forget about the modification after the code commit. It could also mean a system administrator fully realizing the performance impact on an application once released to the customer. Systems thinking means that each team should be aware of the actions of every team in the pipeline and ultimately the customer.
Systems thinking is also an excellent way to think about blame as well. Traditionally, if someone pushed a piece of code out to production, that caused a major service outage, they'd be crucified by their peers and their management. They'd be singled out, scolded and potentially fired. Systems thinking removes that initial inclination for individual blame. It's about not blaming the individual that might have been unfortunate enough to push the button but the system that allowed it to happen in the first place.
Systems thinking treats an incident like this as a failure of the system. devops organizations immediately investigate the cause; not by the person that did it but by how it even got to production in the first place. In this case, they may look into why their automated testing did not catch this which leads me to the next principle.
Experimentation and learning
Devops organizations are always experimenting and learning from their mistakes. In the case of the developer that took down production, this incident would be thoroughly investigated bringing together the appropriate people and incorporating a fix that would prevent this in the future. The incident wouldn't just be forgotten afterward. It will be fixed so even if someone else does the same thing again; the system would prevent it.
People learn from their mistakes, and the organization allows everyone to experiment rather than forcing them to focus on a restricted set of tasks. Devops organizations encourage creativity and thinking outside of the box rather than keeping the "the way we've always done it" mentality. This naturally encourages everyone to remain humble because no one is privy to perfect ideas that no one can challenge.
devops sets a precedent that experimentation is OK even if it ends up in a failure. After all, failure is typically the best way to learn. Devops organizations understand this and are an important part of the Three Ways.
Feedback
Without feedback, learning would be stifled. This is why devops encourages feedback of all types. Not only between peers on the same team but, more importantly, feedback from the business through the form of customers. devops sets to open up channels necessary for feedback to percolate back up from customers to development and operations.
Devops is about speed. Feedback cycles are no different. To provide the features to customers in the shortest time possible it's critical to get feedback as soon as possible. Traditional IT is top-down. This was a time when IT thought they knew best and provided services to users with little to no feedback. Users were simply expected to make due with what they had.
Devops turns the traditional model on its head. Rather than IT assuming they know what's best for their customers, customers now have more control through open feedback channels. Customers now provide immediate feedback which gets sifted and prioritized by IT, and actionable steps are created to implement that feedback. This then turns into new code which gets applied to infrastructure and out to customers again. This is known as the feedback loop and is essential for a devops organization to provide services that are valuable to its clients.
Summary
The next time you see an advertisement for the latest software attempting to define devops as something you can buy, remember The Three Ways. No organization can be considered a devops team without embracing these principles. They may seem some initially limited benefit, but a piece of software or a single motivated team is not going to embed the necessary thinking that a devops culture requires.
Devops requires buy-in from all areas of an organization; not just from IT. At the end of the day, devops and The Three Ways are not about technology; it's about a better way to deliver business value at a much faster rate.