Yesterday I attended a meetup by Marcel Birkner and Dennis Schulte from codecentric Germany about everything cool in the buzzing arena of infrastructure as a service (IaaS). They were all there: Terraform, Ansible, Vagrant and of course Docker. I myself, a mere builder of functionality, marvelled at how virtualisation has changed our profession. The only physical machine you’re likely to see or even care about is your laptop workhorse. All services that a team needs to be productive (continuous integration, source control, artefact repository) is conjured up by just running a script.

In the not so distant past setting up this landscape was the domain of a curious breed of IT specialists: the helpful sysadmin. Now, inspired by the devops methodology, developers are allowed (required?) to take care of their own infra. No wonder the room was packed with developers: it’s so much more fun to automate it. Halfway through the demonstration I had decided for myself that this was quite a lot to take in and my mind drifted, aided by the heat and recent beer intake. It was plainly obvious that this was the way forward. Tools like Chef, Puppet and Ansible basically do the same, but a de-facto standard will eventually emerge. Docker is well on its way to becoming that. Yet it also became clear to me that I should not try to become an expert in them and I didn’t mind too much having to leave twenty minutes early. Let me explain.

There’s a good reason why everybody’s talking about infrastructure as a service. It’s where the innovations are being made. It’s cool thanks to advances in the old and boring tech like cheaper, faster and more reliable bandwidth that has made it possible in the first place. Without it you couldn’t have moved the servers to a remote data center in the first place. But just because everybody’s talking about Docker and not about RDBMS doesn’t mean Postgres and Oracle are any less pervasive. This is the availability bias: we (over)estimate the importance and prevalence of events depending on the amount of talk. It goes for plain crashes as well as build tools. So despite the potential we should put the buzz into some perspective.

What makes me feel less compelled to dive into IaaS is the feeling that there just won’t be an awful lot to do in the future. Once the tools are ubiquitous and the quirks ironed out it’s unavoidable that they’ll take less skill and fewer people to administer. There’s something else at play too: with IAAS the effort to administer a big infrastructure compared to a huge one isn’t linear at all. Getting more storage for gitlab and memory for Jenkins are achieved with a few lines of code. But when your software’s functionality doubles then your code base, developer workforce and budget is more likely to treble. In a large project the effort to provision the infrastructure will shrink to insignificance compared to that for writing the actual code. It would be weird if it were otherwise.

If you want to grow as a developer there are plenty of indispensable skills to hone, not all of them of a technical nature. By all means learn IAAS if you’re so inclined, but you can still call yourself a competent programmer if you let others take care of it.