Cause DevOps.
Some would say that you should learn it simply because you should, end of story. But it’s not that simple. Regardless of your reasons, I think that you should learn it to be a better dev and to boost your technical career.
Lets quickly look at DevOps
Think about the traditional Dev vs Ops goals that existed “long ago” (Hopefully, you’re past dealing with this today): Devs were rewarded for shipping features and making changes, while Ops were rewarded by keeping things stable, and thus change was an enemy.
A massive number of methodologies were created, or borrowed, to get rid of this conflict, like Blameless Postmortems and Just Culture. Another example is error-budgeting, in which SLAs and SLOs define how stable something has to be, and also how unstable it 'must' be. This is done to cut costs while encouraging change.
These things, paired with the LEAN practices, reflect the cultural and organizational pillars of DevOps. They are crucial, but often disregarded by some people. The other pillars use automation to cut down on repetitive tasks, and improve intelligent decision making with better data through monitoring, observing, and using this data as a guide.
With all that in mind, I would say that there is a lot more about DevOps than just Devs knowing Ops.
So, why would you, as a Dev, need to know some Ops, if not because of DevOps ? I’ll now try to give you four reasons that answer this question in a more career-oriented vibe. Maybe your company or your current position doesn’t require this knowledge, but knowing it will make you a better Dev overall, helping you write better services and giving you more “power”.
1- You can be part of important technical decisions/discussions
Ops knowledge can open many doors for you. If your company has an architecture-steering committee or something similar, having such knowledge may play a big role in you becoming part of it, or even in bringing things for the committee to discuss. You may have a say in decisions related to stack, architecture, and even business.
Let’s say your company has a bit of a delay when it comes to response in some situations and in some services. One possible solution is to re-implement some of these services and part of the architecture. However, this could be very time consuming and demand a lot of effort. A better option might be to do a mix of software and infrastructure architecture change, hopefully with less effort. You might arrive at this solution by yourself from having a “mixed bag” of knowledge. You can then bring more people in for discussion on the topic.
2- You can write better services
In the same way that you can provide better answers to problems that emerge in your services regarding its architecture and code, Ops knowledge may allow you to foresee problems that are bound to happen.
Your development can be really modular and focused on the thing your service is solving. But the ability to visualize problems regarding how your service interacts with other services and with the systems holding it is crucial for applications with really high SLOs and SLAs. This makes your services both reliable and available.
Hopefully, with some Ops or System Administrator experience under your belt, you will also feel the need to keep your services observable. With operability and observability you make possible to have people on call with less stress.
3- Being on call can make you foolproof when coding
Here I am not talking about just Ops knowledge, but also Ops experience with being on call. With enough of it, you start to see the weak links and parts most prone to failure in your system. This gets to you, you start feeling it under your skin, and when you go back to coding , it should influence you to write better code.
This one is almost the same as the second item, but I believe that the experience of being on call brings something that only it can bring: empathy for service operability. The second item refers to Ops knowledge you can acquire by reading or listening to people. This one refers to the knowledge acquired by your own experience and how this can later be used in writing code.
4- You can be part of all the life cycle of your code
You can write your code, and test it; you know how to CI/CD it, and you know how to operate it in the production. You also know how to observe everything. I’m not saying you will be doing all these things every time, but you have the know-how, and may have done it before.
Your company shouldn’t expect everyone to know all of these things. But knowing them might reward you greatly. And thus, this pursuit should be encouraged by your company.
So, how do we go about this?
I hope I have convinced you to learn some Ops. If you don’t know how, here are some options:
References
I like the opsschool readthedocs. There are a lot of topics missing content, but you can still use it as a list of topics to further research on the internet, and maybe get some books and articles on.
There are lots of specific tools-focused books that I could suggest, but you’d be better off looking for them based on what your company uses and what you want to learn.
For more general learning you could get The Practice of Cloud System Administration and UNIX Linux System Administration Handbook.
For Linux, Linux Programming Interface System Handbook is a great book. Mostly to be used as reference.
For networking you can read Computer Networks by Tanenbaum.
You can read this references about observability: Honeycombio Guide to Achieving Observability and Distributed Systems Observability.
I know this seems like a lot, but don’t be intimidated by it all! Remember, there’s no need to read all of it. And here’s the actual best way to learn Ops:
Just do it!
See if your company gives you the option to try other positions and go for it. Ask for guidance and try to stay on call sometimes. If you have people around you who know something, talking to them and sharing what you know might be the best way to learn. So long as you have solid development skills, the addition of Ops experience could help you achieve even greater things!
Top comments (12)
Nice article, great reasons, and totally agree - the more Ops Devs know, the better; just don't expect most Devs to be excited about being Ops and Ops services experts, though they should support their code in production.
I recommend Devs who want to learn Ops should learn to use infrastructure as code tools, like Ansible for config mgmt and HashiCorp Terraform for provisioning workflow (many devs already are using TF from a self-service module template standpoint).
Then for networking, service mesh seems to be what's making it more dev-approachable these days. For that you should check out HashiCorp Consul, Istio, or Linkerd.
And of course there's Kubernetes, but that's got quite a learning curve. I think a simpler container orchestrator to start with would be HashiCorp's Nomad.
I intentionally avoided to give specific tool suggestions, but since you did:
Great tips!
Just don't go to service mesh 'because it makes networking more dev approachable', ideally you should have a good reason to mess with it, and there are a lot of people just going cause it's trending.
Same for kubernetes some times. That's why I said to look for tools that your company already uses, and expand from there.
I did not give any references about CI/CD, orchestration, and other important Ops/DevOps topics since they so closely relate to tools... But we could give more tips like that here in the comments!
I 100% agree with you. It's one of the reasons I started to write vpsformakers.com as an introduction to the world of managing a server. Even if you end up using a managed platform it will help you tremendously to know how this things work. I would be careful though to recommend people to start with "service mesh" or Kubernetes. It's better to start really simple and add more complexity step by step.
Totally agree with you!
And nice book!
As a front end developer can I make the transition to a DevOps career? Just being curious ... :)
See the last gif of that post :)
ALL of this. I started out in old-fashioned sysadmin, so I've always been "the developer on my team who isn't afraid of ops". Which means I become, by default, the devops guy if there isn't already one. And I see my fellow engineers being kind of afraid not just of the servers but of their own machines, and I'm like, "Dude...you are a wizard. The machine exists to do what you tell it to do. You'd better know exactly how to tell it how to do stuff and why and when."
I don't understand any developer who doesn't get that...
I like the way you approach the question. Should you? If you want to be a better developer.
There's Google's Site Reliability Engineer book as well that talks a lot about DevOps. A really good primer for understanding it.
I did not want to share any "organizational" reference since in Twitter I also shared @lizthegray article about Production Excellency together with this one. (Also she worked at Google and the reference that you linked is in her blood)
Here I only wanted to share pure ops references. In this post I'm only talking to devs. In @lizthegray post she talks to companies.