It's not a link bait title, bear with me as I try to explain myself.
Every once in a while, I get asked the question of "how to be better at DevOps". This is an extremely confusing question, because it depends entirely on what DevOps means to you.
define ( ‘DEVOPS’ );
For some, it means Infrastructure As Code (Puppet, Chef, Ansible, …). For others, it means collaborating between developers and operations more, exchanging ideas and documentation. Others see it as a single person doing both development and system operations.
Whatever DevOps means to you, it’s OK.
There is no single definition that works for everyone, despite what Wikipedia might say.
To me, this is what DevOps means:
DevOps is about understanding each other. It’s about developers understanding enough of the IT infrastructure to have it make sense. It’s about sysadmins knowing enough about development to be able to speak on the same terms. Once you understand each others’ vocabulary and system setup (both dev and ops), communication and collaboration comes naturally.
Once you start to collaborate, you can inherit each others’ best practices and design patterns. You’d be amazed how much system administration and software development have in common in terms of writing code, testing, monitoring and automation.
With that said, how do you get better at DevOps?
Getting Better At DevOps
Well, this is the part where I hate to say the words.
You see, to me DevOps isn’t a single person doing both development and operation. It’s far from it. I think having both qualities, to be able to develop and manage your infrastructure, is very rare. You may think you’re good at both, but chances are you’re better at specializing in one area and focussing on it.
It’s for this exact reason we all mock the recruiters looking for DevOps engineers, thinking they can find someone to fulfill both the developer and operations role in a company at the same time. That’s just not how it works.
Yet, as much as I mock those recruiters (or the companies looking for that same silver bullet), DevOps is partly about Ops doing Dev work and Dev doing Ops work. Just not in the same way companies see it.
If you’re {dev,ops}, try some {ops,dev}
What has helped me the most in my professional career, was the fact that I started as a developer and slowly switched to system administration. It gave me the background I needed to fully understand my role as a sysadmin.
My best piece of advice I can give anyone trying to be better at DevOps? Switch roles.
If you’re an ops, try some dev
If you’re currently a system administrator, try to write an application the same way your coworkers/clients would.
To put this in my perspective, from a hosting industry point-of-view, that means understanding mostly PHP (80%), Ruby (10%), Java (5%) & NodeJS (5%).
If you’re a fulltime sysadmin, try to write a web application in your spare time. Make it a hobby. Use a popular framework like Symfony, Laravel or Zend Framework 2. Use Composer. Write unit tests. Try some Test Driven Development (TDD). Deploy your code in an automated way.
Need a concrete challenge? Write a TODO-list application that can send reminders by mail if you’ve missed a time-based TODO (aka a deadline). It gives you UI design, background tasks, you can use validation libraries through composer, you can write tests, …
Understanding object-oriented designs, patterns like singleton & MVP, template engines, application-based caching layers, … will all make you appreciate your sysadmin tasks even more.
It will give you insight in how the application needs to work together with the system.
If you’re a dev, try some ops
If you’re currently a developer, set up your own server and manage it yourself.
Install your own server, preferably the same kind your coworkers/clients would use, and manage it entirely by yourself. Try some Ansible to get a feel of infrastructure as code. Or try Chef or Puppet, if you’re looking for a slightly more complex setup. Set up unit testing for your own infrastructure code. Check out ServerSpec.
Configure your own monitoring. Set up alerting. Play with the triggers until you get notified when needed, not sooner. Just set it up on the same server you’re managing. Get a feel of what it’s like to configure it entirely by yourself.
(So just to be safe, if you’re actually going to use your own server, add some external monitoring as well. Installing the monitoring on the same server is just to get the feel from managing it entirely by yourself.)
Configure backups. Add some monitoring to your backups. Now secure your server. Add HTTPs. Add some firewalling. Benchmark your system and squeeze every last drop out of it.
Now that you have your system running, move every component to it’s own Docker container. Set up private networking and a persistent datastore. Expose only your public ports.
And then if you think you’re ready, destroy your server and run a single configuration management command to completely deploy your server again from scratch, using the same infrastructure as code tools you just learned to use.
Dip Your Toes
So as much as I hate recruiters looking for the silver bullet, there is some truth to it. If you want to be a better sysadmin, try to be a dev. If you want to be a better dev, try to be a sysadmin. There, I just gave you the worst possible piece of DevOps advice. Right now, I’m sure there’s some recruiter doing a happy dance for his victory.
Just understand that you’re probably better off focussing on one area and keeping the other as a hobby. It’s extremely hard to master both. Make sure you master one and play around with the other.