What DevOps means is quickly explained: Development + Operations together. ,But what does DevOps really mean for development teams and their day-to-day work? And what is ‘operations’ to begin with…?
“Operations” explained
What is operations, does all software need to be operated? To explain this let’s take your local Word and Excel, or whatever local software you have installed, as an example. It just sits on your notebook. Once in a while you’ll probably update it to a newer version but that’s it. It is your personal software on your own machine – no real operation involved.
Compare that to your email. Here again you may use some local client, or just the browser. No operations. But then there is your email provider and all that is required to manage your mail account and transmit your mails. This is done by services that run in some datacenter and you can count on a team of experts that look after that software. They’ll make sure that the system runs smoothly, they apply the latest security patches, protect it against hacking attacks and securely back up your data, to name just a few of the tasks. This is what an operations team does. And you need to rely on it because you are using services that are not under your own control. Means whatever software runs in a cloud or datacenter will need operations.
Software development vs. operation
Traditionally there has been a very clear separation between teams that develop software and the ones that operate it:
Photo by Raj Eiamworakul on Unsplash (stuff in red by Tom)
The developers would write their code and maybe even test it 🙂 but as soon as possible throw it over the wall to the operations team. Then it would be up to them to figure out how to install and run it. Okay, maybe there are companies with good collaboration between these groups, but still there may be some conflict of interest. Developers will want their new versions out on the productive system as soon and as frequently as possible to bring new features and bug fixes to their users. The Ops team will try to slow things down a bit and play it safe since every update is considered a risk and may required some system downtime.
Operation for cloud software
Now fast forward to cloud world with an agile team in Scrum mode. Software sitting idle waiting to be deployed is considered ‘waste’. The infrastructure does not consist of physical servers owned by administrators any more. Now infrastructure is code and the dev teams’ architectural design decisions have a huge impact on the required cloud building blocks and corresponding cost. Also the ongoing operations effort is to a large part determined by the architecture. System changes may require modification of the infrastructure code, too: adapted configuration of the used cloud provider services, extensions to the system monitoring etc. The entire separation between development and operations does not make sense any more. As they say: you can do it, but it’s not good.
DevOps to rescue
Instead let’s put everybody in one team. Ensure that operational concerns are considered during development and when designing the system architecture. The team should consider the overall lifecycle cost and minimize effort accordingly. This is what DevOps is supposed to mean. No wall any more, not even two distinct groups, hopefully.
Check out these related articles:
- Should we use SCRUM ? How to organize a dev teams work
- Tools? These are the must-haves for every dev team
- Cloud Native ? What it means to develop software for the cloud