The word “DevOps” means different things to different people and teams. I thought I’d collect together a few common usages, from worst to best.
The worst way a DevOps team is created is from a simple re-branding of an existing old-school operations team. Unless this re-branding is aspirational in nature (i.e. the team intends to change), this sort of DevOps is the worst possible: those higher up in the organization might not be able to tell the difference, and this fake DevOps team will squash any other teams attempting to do DevOps properly, in order to protect its own existence.
Don’t be like this.
In many organizations, there is a historical divide between Development and Operations teams, and the two teams do little more than the bare minimum of communication. Developers build applications without thought to non-functional requirements such as logging or resilience, then throw what they have built “over the wall” to operations. Meanwhile, the Operations team are blamed for every outage, and they respond with more and more complicated processes that make it as inconvenient as possible to make changes. The balance of power in such organizations is often towards development, which means operations cannot feed back any suggested improvements to help them support the application.
In this sort of environment, any improvement in communication between teams is beneficial. Allow both teams to raise issues in a blame-free culture. Both teams should also be able to raise requests for change, and these should be given suitable priority: product owners need to understand that non-functional requirements are as important as functional ones.
Another approach organizations might take is simply to let the development team handle operations tasks – often something along the lines of “developers have both root access and pager-duty”. I think this approach has both potential upsides and downsides.
The potential downsides are largely down to hubris and over-confidence:
The potential upsides are essentially what I think DevOps is all about: see the section below the break…
I’ve been a proponent of infrastructure-as-code (IaC) for a good long time now, but I have to say the best summary of why that’s a good approach came to me recently, from my previous manager: she said (paraphrasing):
Infrastructure-as-code is great because it allows us to take all the hard-won lessons and techniques we use in development, and apply them to operations.
I think the best way to illustrate what this means is by way of the filenames of documents that get emailed around all too often:
Copy of Updated-TPS-Report-(draft)-September-v3-revised FINAL [amended].docx
These sorts of document names make developers laugh because we can see a process that desperately needs some form of source control: there are clearly multiple authors making changes over time that need to be merged together, and that just screams “use source control”, something the software development community learned long ago.
(Although I’m just old enough to remember a time before that: in my first job, source was kept on a file share, and if you wanted to edit a file, you just shouted across the office to make sure no-one else was editing it at the same time).
Traditional operations is like those sadly funny document filenames: people request changes to infrastructure and the result is an amalgamation of ad-hoc, poorly-controlled changes.
Very often this lack of control is recognized, but the subsequent “fixes” are in the wrong direction: extra process is added and further manual controls are added in an attempt to codify the changes – ticketing systems, inventory list software, and so forth – but because these systems are managed in the same, manual, way, they quickly drift away from the reality of the infrastructure itself, and become simply a drag on the ability to change.
DevOps, by contrast, asserts that the best tools to manage infrastructure are based on the same tools that we use to develop large software systems – tools that are based around the humble text file.
Infrastructure-as-code is of course a fantasy – the infrastructure itself clearly isn’t code – but if enough people accept it, it becomes “true enough”. Acceptance needs to be nearly universal, and managed via agreement, mandate, authorization, or a combination thereof.
But once IaC is in place, it’s as if a whole suite of new abilities and behaviors are unlocked:
In fact I’d argue that IaC is so core to DevOps, that if you aren’t representing your infrastructure as code, then you aren’t really doing DevOps:
(In the above I’ve said “to make changes” to distinguish from simply reading information).
That’s great! It shows that non-functional requirements in general, and security specifically, are being taken seriously.
Published: Thursday, September 03, 2020
Hackification.io is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to amazon.com. I may earn a small commission for my endorsement, recommendation, testimonial, and/or link to any products or services from this website.