I spent the early part of my career in IT support maintaining workstations, before eventually moving into infrastructure support, virtualisation and eventually cloud. I’ve never been much of a coder, bar a few basic batch and powershell scripts to help me out along the way and with the DevOps role being used more often than not – its made me sit down and think whether I missed the boat in coding early in my career, or whether there is still a place out there for the ‘old school’ infrastructure guys?
At a conference last year, I was speaking to a fellow attendee, who used to be a DBA. He was (rightly so) waxing lyrical of how he used to write automation scripts to backup and restore his databases and that the only difference is the commercialisation of automation. In years gone by, you’d write scripts to make your own life easier, not to a standard or using a standard toolset. Nowadays, not a day goes by without the big automation toolsets, such as Ansible, Cloudformation or Terraform getting mentioned. I understood the ex-DBAs point, but I think DevOps is far more than writing a bit of automation to build a bit of infrastructure. It’s about playing a key part of the software lifecycle, automating the assembly, testing and deployment of applications, ensuring a consistent, predictable output. I don’t know about any other infrastructure engineers, but that’s not something I’ve ever worked to in the past.
I’m happy to say, my colleagues are interested in configuration management of servers and network infrastructure, using configuration templates to ensure a standard across the estate, and I think that is common across the enterprise IT landscape. Tools such as Terraform alongside VMWare Cloud and AWS native saves time, so there’s an enthusiasm there, but it’s a long way from DevOps, even if the concepts are loosely there. I’m hoping we see a larger adoption of these type of tools, as I’m sure HashiCorp are too!
For greenfield workloads, and by that, I mean self-developed applications, the concept of Infrastructure-as-code makes sense on a few levels. Firstly, you can use your devs as infrastructure specialists, keep your head count down and secondly, you can design your apps around your chosen technology stack and automation toolset. The challenge for us more ‘traditional’ folk, is that you’re reliant on third party software companies, who develop to their standards, and their stack. In some occurances, these could be industry-specific applications which serve a specific purpose. Those apps don’t lend themselves to automation, or testing. You can’t tear them down, because the lack of understanding of the application structure and configuration is critical to the process.
So, back to the million dollar click-bait article heading, is the role of a traditional infrastructure engineer dead? I don’t think so, it’s just changing. Tools are available to improve the quality of the infrastructure that is being provisioned, so to ensure that infrastructure is predictable and repeatable, it’s something I’d encourage. I’m heeding my own advice, looking into Terraform as we speak, so not being too preachy for a change!
Leave a Reply