These days people talk a lot about "DevOps". Well, in IT they do. But the definition of DevOps seems quite elusive to me. Originally I though about it as just Development and Operations working closer together. As in DEVelopment and OPerationS. Of couse, this is a quite vague definition, as I have noticed. Over time, I have seen many quite different definitions.
The most popular definition I seem to come across is one where people call a tools (or platform?) team a "DevOps" team. This is a team running the Continous Integration (CI)-systems, and providing some common development (and test) infrastructure. Or any other type of development platform service, such as software based infrastructure setup (containers, clouds, …).
I have also seen roles where people call themselves "DevOps Engineers", and they are really writing the product code, building it, testing it, operating it, … So pretty much doing everything you can do. Must be nice for the employer. Well, as long as you enjoy your job..
In some places there is the development team, and then there is a "DevOps" team working on infrastructure setup scripts using tools like Terraform. Which, BTW, is a nice tool like most from Hashicorp. At the same time, the dev team might be running all their code on whatever setup they have available, typically on their laptops using some combinations of Docker and whatnot.
This seems like a large disconnect to me. But on a second thought, maybe it makes sense (to some extent). You have to develop it somewhere, so you need some setup locally. This makes me think, it might be useful to have some model of a DevOps lifecycle, like what points in a project lifecycle do the Dev and Ops benefit most from collaboration, and what kind of collaboration is best suited at different times? Where do the QA and security best fit in?
Overall, it seems there is no single right definition for DevOps. Whatever works for you I guess. Except that many could learn a lot from others and improving, if they realized enough to have an open mindset. And if they supported people in initatives to learn and improve related processes, tools, techniques, … (..)
Regarding such different approaches, and benefits and problems, I find the DevOps Topologies website has some good definitions for both "good" DevOps and anti-DevOps teams. Their definition of anti-DevOps seems to be largely about keeping the Dev and Ops separate but still calling it "DevOps". Because it’s trendy I guess. Somehow this does not surprise me..
The types listed as working better on DevOps Topologies on the other hand seem to be focused on building more overlap between the Dev and Ops. I guess it depends on the type of work and organization that is in question. There is something that seems related in Team Topologies but the website is a bit vague. Maybe I should get the book, but then I have an overly long reading list already. And somehow manage to distract myself from reading.. I used to have more chance for reading when I had some business trips, with less distractions on a plane, hotel, etc. But I digress.
I find I got the best idea of what DevOps is from reading the book The Phoenix Project. It is from 2013, so already about 7 years old at the time of this writing, but every description in it seems perfectly fine for today. Much like the 20+ years old Office Space movie, where you could just change monitors to be flatter, and software UI’s a bit flashier. The main part of office politics would not change, much like it seems to stay the same for DevOps related development processes. But I digress again.
The Phoenix Project felt like a long story to get started, but in the end it gave me a great perspective on what the term might originally have been intended to mean. I interpret it as development working closely with operations (and testing+security) to make sure they share the exact same infrastructure (Terraform etc today), as well as QA sharing it.
Overall, I also interpret it to indicate dev not creating their own setups and throwing stuff over the wall to Ops and QA. Rather all working closely together to figure out issues, build extensive monitoring and logging to make all their lives easier, improve everything overall. Make it all work better and more reliable for the customer and for yourself (less need to get up at 4am (for this..)). And so on.
For me the Phoenix Project story delivered the message much better than all the websites and powerpoints with their diagrams and abstract descriptions. I guess I prefer stories that make things concrete with realistic examples. And yet, as I discussed above, there still seem to be many quite different definitions as well. I guess with something becoming popular this happens, and maybe for different systems and organizations a different approach with the same higher level goal works. I am sure there are plenty expensive consultants for all this with better answers than me :).
So to summarize my brief lamentations here, a few points:
- DevOps seems to vary quite a bit across organizations, both in how they do it, and what might be a suitable model for them.
- There seem to be many ways to do DevOps "wrong". Which I guess means just not getting optimal benefit from it.
- I would be interested to understand better how all this relates to the different software engineering lifecycle. Early development, adding new features, maintenance, …
- Stories on how Dev, Ops, QA, Security, and anything else have successfully worked together in different companies and software projects would be great to hear.
That’s all for today.
Leave some comments now. Like what do you think DevOps is? And what did I say all wrong? 🙂
Random experiments in software engineering 