StorageBod 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.
The most important conclusion that I have come to 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 the 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 plagiarised 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 out a bit.
So as per usual, the wheel has been re-invented and re-branded.
I’ve boiled 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
It turns out that my teams are already pretty much 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. But equally, 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! ®