At first, I was a developer. One day the guy in charge of the infrastructure/ops resigned and my boss asked me to take over his duties. Well… The handover was basically me asking dumb questions like “What the hell is SystemD?”, “Why do you want me to use docker?”, “Amazon? The bookstore?”… Again, I was a dev…

When he left, I still had no idea of what needed to be done in order to host our brand new web application. I learned.

One day, we asked an AWS expert to consult us. He taught me how to deploy an entire AWS EC2 infrastructure in few hours. He showed me how cool are AutoScaling Groups and Cloud-init/Userdata. And we started a new infrastructure, from scratch, with only 3 basic concepts:

User-data/Cloud-init

When you spin a new instance up in the cloud, you can add a little script. That script (user-data or cloud-init) is executed as soon as the machine is up. You can use it in order to set up your Linux server, install packages, get your code and run it!

#!/bin/bash
# Install NodeJS
curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs
# Install git
sudo apt-get install -y git
# Get our code
git archive --format=tar --remote=https://login:pass@github.com/mycompany/myproject.git HEAD | tar xf -
# Run the app
cd myproject
npm start

AutoScaling group (ASG)

Even if you don't need to “Auto-scale”, it is an elegant way to manage your machine(s). Imagine you have an API server, you need 3 instances in order to be highly available, you just tell your ASG to start 3 machines (using userdata to set up and run your api server). If you need 4, scale-it to 4 in one click. When a machine dies (memory full, etc), it will automatically be replaced! You need to upgrade, no problem, once you have updated your ASG (a new Launch configuration actually), you can kill one instance, it will be replaced by the new one with your new version! yay! Rolling upgrade!

Elastic Load Balancer

In order to have one public endpoint you can place an Elastic Load Balancer in front of your Autoscaling Group. It will also perform health checks for helping your ASG replacing unhealthy instances. Done: you have a single public endpoint!

Seriously, the AWS consultant helped my workmates and I to set this up in one afternoon. One afternoon. You don't need more to have a robust infrastructure, no need to have a multi-year experienced ops background.

Of course, we also needed databases, a file storage, etc. The key is Managed Services. Cloud providers like Amazon or Google can provide it in one click. No need to take care of backup, logs, patch, etc. They will manage it for you.
By the end of the day, even if I was the Designated Ops Survivor, the entire dev team was able to deploy a new version of our code on our servers, on a real robust, highly available infrastructure, auto-managed by the team.

My job as ops expert became more about exploring new techs rather than dealing with daily issues like backups, patches, installing new versions of our app, etc.

That's why I'm thinking Sysadmins, ops, etc as a thing of the past. A few companies will probably still need them. Amazon need some in order to offer us a nice sparkling AWS Cloud! But if you are a start-up, creating a web application as a lot of us, you don't need to deal with linux patches. You need to focus on your business. With Cloud providers and a DevOps oriented organization: an infrastructure can be managed by the dev team. You can use the leverage of the IAAS (infrastructure as service) without the burden of sysadmin daily duties.

Are ops OPSolete?