Recently I’ve been spending time thinking about what DevOps really means to my teams and to me. A lot of reading has been done and a lot of pondering of the navel.
Tne most important conclusion that I have come too is that the DevOps movement is nothing new; the second conclusion I have come to is that it can mean pretty much what you want it to and hence there is no right way to do it but there might well be horribly wrong ways to do it.
As a virtual greybeard; I started my IT career in the mainframe world as a PL/1 programmer but I also did some mainframe systems programming. As an application programmer, I was expected to do the deployment, support the deployment and be involved with application from cradle to undeath.
As a systems programmer, we scripted and automated in a variety of languages; we extended and expanded functionality of system programs; user exits were/are an incredibly powerful tool for the systems programmer. VSAM and VTAM – the software-defined storage and networking of their time.
We plagarised and shared scripts; mostly internally but also at times, scripts would make their way round the community via the contractor transmission method.
Many DevOps engineers would look at how we worked and find it instantly familiar…although the rigorous change control and formalised processes might freak them a bit.
So as per usual, the wheel has been re-invented and re-branded.
I’ve boiled down DevOps and the idea of the Site Reliability Engineering function down in my mind to the following –
Fix Bad Stuff
Stop Bad Stuff Happening
Do Good Stuff
Make Good Stuff easier to do
Keep Developing Skills
It turns out that my teams are already pretty working in this way; some folks spend more time dealing with the Bad Stuff and some spend more time dealing with the Good Stuff.
DevOps could be a great way to work; you might find that you already are on this journey and don’t believe anyone who tells you that it is new and revolutionary.
It’s not!