Anyone working in IT has heard of DevOps. It's a phrase associated with giant cloud companies like Amazon, Netflix, and Salesforce. But DevOps also seems obscure, like a secret handshake that's hiding in plain sight.
To demystify DevOps, I invited one of the world's most prominent DevOps figures to join me on CXOTalk. Gene Kim is an entrepreneur, researcher, and author focused on IT operations, information security, and DevOps. He is best known as the founder of Tripwire and as author of The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, Visible Ops Security, and The Visible Ops Handbook.
I first met Gene years ago, when he was writing The Phoenix Project; our shared interest in addressing the causes of large IT failures created a fast connection.
The entire conversation is embedded below or you watch on the CXOTalk site:
Here are key parts of the transcript, which I edited for length and clarity:
What is DevOps?
DevOps represents a set of principles or patterns that result in very fast flow work from dev though test into operations while preserving world class reliability, stability, and security.
Not only does it create fast flow and reliability, it allows small teams to quickly and independently develop tests and safely deploy the code to customers.
For developers, they can work in a production-like environment on a daily basis. Instead of testing code in a production-like environment one year later, developers can run that code in production, ideally, on the same day they wrote it.
For operations, instead of doing work that comes out of ticketing machines, instead of being involved only at the last stage of the project, we create the automation required to make these environments on-demand. Automation helps developers be productive.
This means the organization can achieve its goals, whether delivering new features to the customer, being reliable and stable and secure to protect organizational commitments, or passing audits. It really does change how we do work, whether in dev, test, operations and security.
The DevOps movement has tried to stay away from being very prescriptive, but I would say it encompasses cultural norms, processes, procedures, and technical practices. All of those things in combination cause the outcomes.
High-performance organizational behaviors
There are seven or eight things that we found that are pre-requisites to high performance:
Version control, especially operations because that's where the greatest number of variants occur.
Automated testing. We must be able to test whatever we put into version control so we have confidence in good outcomes when actually deploying into production. As opposed to only testing at the end of the project and having armies of people execute the test plans encoded in Word docs.
Proactive monitoring in production environments. So when something goes wrong we find out first before our customers, to detect issues and correct them quickly.
High-trust cultures. This is something that can only come from leadership: set the cultural norms where we actively seek information and encourage bridging between teams.
Metrics. What metrics can we use to drive our DevOps improvement programs?
Organizational alignment. Development is motivated to features to market quickly and to make changes faster than ever. And then you have operations, which is measured on reliability and stability, and that leads to the desired outcome of making no changes ever.
When you take those two diametric opposite goals and put them next to each other in the org chart, terrible things happen. So DevOps is about organization, culture, cultural norms, governance, policies, and most importantly how we can get it to work.
Architecture is one of the most important things that a leader should care about. To achieve high performance, we need an architecture that allows small groups to work with autonomy, freedom, and safety without having to coordinate with hundreds or even thousands of other developers, every time they want to deploy into production.
DevOps and ITIL
ITIL represents the codification of all the up-and-coming processes that we need within IT operations to get world-class availability, and it was written by the office of OGC, part of the British government. It defines how you handle change management, configuration management, lease management, vendor management and so forth.
I think ITIL works very well when you are doing hundreds or thousands of changes per week. But with DevOps we are potentially doing hundreds of thousands of changes per day, and so this means that we can't have manual configuration management practices. We can't have a lot of change approval boards we can't do releases manually.
DevOps automates this management process to make it very predictable so that we can do them on demand and even have them performed by developers, which is something that I think is alien to ITIL and auditors.
Impact on the DevOps on the business
We have to stop optimizing our technology organizations for cost and instead optimize for speed.
Gets out of the trap of, "How do we reduce the IT operations budget by 3%" and instead have a totally different conversation of what does it take to be able to get omni-channel capabilities, for example.
Organizations rarely win on just cost efficiency. More and more we win by innovation and time to market. DevOps enables quickly delivering functionality to customers.
We can experiment with functionality to understand what actually best fulfills customer goals. There is a growing school of thought is that says it is by out-experimenting the competition that actually enables us to win in the marketplace.
It can be about cost, but actually the calculated decisions that organizations make is being willing to pay more to get to market faster, get in the game and win the game.
What we need out of IT is so great that the survival of the organization often depends on it. We need to reframe this question to ask, "Is what you're doing so important that you are actually willing to fund it?" That brings up the next question which is, do you have confidence that if we had the funding that would actually achieve those goals.
If we do things the old way in large waterfall projects, expecting outcomes only at the end, where we don't fund testing and integrate that daily work of dev and operations -- do we really have confidence that money is going to get transformed into the desired outcomes. That's where we start having a real conversation about doing things differently.