Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

This article is more than 1 year old

Storage greybeard: DevOps, plagiarism and horrible wrongness

There's nothing new under the Sun

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! ®

 

Similar topics

TIP US OFF

Send us news


Other stories you might like