None of the experts in DevOps will 100% agree on WHAT it is. But the essence is understood. DevOps is some combination of culture, tooling, and processes that enhance the quality and speed of software delivery. In the remainder of this post I will give you my definition. The rest is up to you.
We often joke that if you are in a DevOps role your job is to be the marriage counselor between your development team, and your IT team. It’s no secret that the two have had a love hate relationship for a long time. And as the pressures of more rapid software delivery increase, the relationship gets even rockier. Developers want their infrastructure now, but don’t really care about how it’s done. And the IT team wants to maintain oversight and control of all the infrastructure and tools the organization uses.
Depending on if you find yourself in a software company or a traditional business, your experience with this relationship might be different. Traditional industry, as in companies who offer products and services that are not software, but seeing more and more that software is key to interacting with prospects and customers. For example a huge bank. And ISVs who’s product is a software product. For example Google. The two are very different, and because of this difference we see a terminology challenge when the conversation of development comes up.
In the enterprise who is modernizing their development shops to deliver mobile and web applications. The gap between the traditional line of business (LOB) developers, and the new modern dev teams is huge. Some do not even use the term DevOps, or even the term operations at all. The developers deliver the code, and the IT team delivers that stuff the code runs on. IT still very much rules the roost here. And many such organizations think they are just out of the scope of DevOps, or they can take some suggestions from DevOps but not embrace it fully. This is not true.
On the other side is the software ISV. Where operations is well known. And IT and development get along much better, because they are both part of the bottom line of the company. And goals are well aligned. But there is still a territory conflict. Often in ISVs developers are moving so fast, that they bring in new tools that Operations/IT are not aware of and pose risk to a long term sustainable processes. Many think they are already doing DevOps because they know who Atlassian is, but this also is not true.
The good news is that DevOps is equally beneficial and possible for both types of organizations. The bad news is it’s so confusing if you get a CIO from traditional enterprise, and an R&D manager from an ISV in the same room talking about it. While the tooling might be harder for one organization over another to embrace, the processes, and culture are the same. The easiest place to start is to look at DevOps as three distinct components, tooling, processes, and culture. Tooling being the easiest place to understand. Lets begin:
A DevOps engine is operating by a collection of great development, monitoring, and provisioning tools. Many of these tools overlap in functionality, which causes a lot of organizations to find ways to stretch them beyond their intended use. But they all have a very important purposes. And I break them into the following categories.
- Project / Product Management
- Design and Mocks
- Infrastructure / Platform
- Source Repository
- Development Tools
- Programming Language
- Tickets and Tracking
- Orchestration and Configuration Management
- Release Automation
- Quality Assurance and Testing
- Reporting, Analytics and Logging
- APIs and Frameworks
Even here the technical world does not agree. You can find a different but similar list on New Relics DevOps micro-site, and in this Presentation from XebiaLabs. My list is a more similar an approach to Xabialabs. But compared to New Relic who breaks categories based solely on features and I based on features and uses cases, the list seems very different. The net result however is that all the tools for DevOps are in there somewhere.
The important thing about DevOps tooling is that there are SO many tools, and SO many permutations to put them together, thus it is more important an organization be aware of what is possible, know about how a tool will benefit their operations short and long term, and finally how to deliberately select and integrate them.
Once the tools are in place, they are connected to feed a process. For the longest time organizations have been talking about ALM and Agile. So they are very familiar with processes. Even before that it was waterfall and other various project management approaches. The thing about DevOps is not just that the processes move faster, but that they are a never ending flow. The meta-process I suppose.
In ALM and Agile processes happened in chunks. Some like to argue this with me, but really if you look at most “modern” development organizations that have not embraced DevOps fully. What they are doing is just REALLY fast waterfall, otherwise known as sprints. In DevOps the processes are a continuous stream of consciousnesses, code, and delivery of applications. This is often called Continuous Integration and Continuous Delivery. These are nice buckets to define the processes, but there is much more too it. Oh and by the way, it’s unique for all organizations.
Because it’s a stream and it’s unique for all, it is very important that there is someone to manage it, and that the tools and the link between the tools be thought out and established.
Culture is the glue that binds the tooling and processes together. Culture to some degree is a style, yes. In this case the style being, automate everything, and lets all get along and stop pointing fingers.
But it tactically also consists of the people. And for organizations that are serious about DevOps the people should be designated as the facilitators of DevOps and be given specific teams. We like to see organizations who actually have a DevOps department. These departments often evolve from individuals previously from QA ( QA in the world of DevOps changes substantially), IT Operations, and even developers ( usually back-end ). They may be part of the development business unit, or IT. But in any case they are responsible to both.
The DevOps team lives to facilitate faster and better code. They pick the tools, setup the tools, and control the processes. Some might like to call them the police of DevOps. But really they should be the friends of the developers, and have the power of IT. They should also encourage the culture around DevOps which is to fail fast, innovate, and think quality first. Organization have to be very careful not to encourage the conflict between the new DevOps team and development. As the whole point is to put them on the same playing field and working together. Ultimately you have to start with the culture first before the tooling and processes can be assimilated appropriately.
Now, from a high level you know as much about DevOps as anyone else. What the experts bring to the table is not a better definition, but a deep understanding of implementing the tools, designing the processes, and fostering the culture.
It will only be a few years before we stop saying the word DevOps all together, because it will be assumed. Much like the Cloud and Agile is today. For those ISVs that are on the path there, keep it up. For Enterprise IT that is thinking about it, don’t limit yourself. And for Enterprise IT that is brushing it off … let me know and I can help you with your resume.