I was at first developer. One day the guy in charge of the infrastructure/ops resigned and my boss asked me to take over his duty. 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 guy…
Once 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 a AWS expert to came over and 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:[email protected]/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”, that 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. Well you just tell your ASG to start 3 machines (using userdata to set up and run your api server). You need 4: scale-it to 4 in one click. Then a machine dies (memory full, etc), it will automatically replace it! 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 provider 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 actually more 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. Some companies will probably still need some, 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 organisation: 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.
Ops are OPSolete?
本文系统（linux）相关术语:linux系统 鸟哥的linux私房菜 linux命令大全 linux操作系统