Many developers I know are intimidated when they hear the phrase "DevOps". Docker, Kubernetes, clusters, bash scripts, cloud, and others can make them take a step back and get all insecure. I personally find DevOps super interesting, exciting, and attractive. Modern front-end development can be also very complex but still many devs are facing this challenge.
Why do you think devs are "afraid" of DevOps?
Lack of public knowledge?
Prejudice?
Anything else?
Top comments (22)
Yes, I agree that it's less commodity and straightforward than application coding. I think the potential is great and once you've mastered it, you can make great things. At the end of the day, DevOps is about automating operations that used to be done by devs
It seems that I confused DevOps with SysAdmin as well.
But it seems that DevOps is very broad?
Yes, DevOps is definitely very broad and spans across lots of domains.
Some people also refer to changing your webpack configuration as a front-end devops
Honestly, I don't understand it. Ive been studying about it for a while now and every place where I learn about it has something different to say. I understand DevOps could really help us out in projects but I don't understand how.
DevOps is everything that integrates development and the operations behind it. The classic use case is CI/CD pipeline. Instead of deploying manually your code to a remote server, nowadays it's super popular to automate the process. For example, when you write a GitHub Workflow or CircleCI pipeline you are doing DevOps. I believe many devs are doing DevOps without even knowing. If there is any specific topic you are having difficulty with, maybe I can help.
What does DevOps do?
I don't say that to be snarky. The last 4 places I've been at, DevOps had extremely different roles at each place.
The current place I'm at, DevOps is chartered with such things as: care-and-feeding of the Jenkins continuous build server, care-and-feeding of the Git source control servers, tasked with making the projects that comprise the product to build faster and more reliably, tasked with reducing the warnings in the code base to zero (and not by disabling warnings!), tasked with being the scouts to try out and certify the latest compilers against the code base, tasked with working with the build teams to help make the build process better from the repo to publishing the executable, tasked with helping the localization team be plugged into the build system, tasked with helping the technical documentation team be able to do their jobs, tasked with doing audits and working with legal, and I'm sure another dozens tasks and charters I've missed.
That's a lot of work!
But I've also been at other places where DevOps did none of those things. Thus, my question.
DevOps is so broad, no doubt. Every company or team can adapt the concept of DevOps to different practical tasks. It's tough to answer your question.
My first two ideas:
A lot of docs are thorough, but not truly beginner friendly. It took me 7 tries to learn Git! Quite a few attempts before I could spin up my own EC2 instance! This is getting better because there are so many blogs and tutorials on sites like Dev.to, but frequently our tools and docs are not intuitive for absolute beginners.
There may not be incentives for a person to learn DevOps! I come from academic science, and most research labs could seriously benefit from taking stock of their technical debt and investing in DevOps. But careers are advanced by writing papers, not by fixing technical debt. And since the cost of that debt is never measured, you can functionally ignore it until a catastrophe hits.
Usually, when catastrophe hits you can't do anything besides fixing it. Sometimes it takes less work to prevent it. But I can't agree more that no one cares about tech debt. Managers/supervisors would like to see results.
I think the tools & integration that needs to make CI/CD work is still kind of complicated IMO depending on the type of app you built and where you are deploying. I'm not saying there are no easy ways like for static sites GitHub + Netlify + GH actions are pretty straightforward.
But at an enterprise level, apps become so complex & their integration with some DevOps tools become so hard & tedious process. Due to many constraints like legacy frameworks, security restrictions, not enough support & many more ., causing developers to put some hacks on top of existing processes and make the CI/CD work.
This makes the whole thing risky & causes fear among dev when they hear they need to setup CI/CD process. And don't forget management/manager doesn't think DevOps need good enough time to achieve but they want it for sure as it sounds cool & in quick time.
There is still a long way to go !
Might be that DevOps is still pretty young, I believe in the future we can expect many more toolings to lower the barrier of entry.
Even though I've developed some familiarity with tools like docker & k8s along with cloud platforms. I've been managing the whole CI/CD pipeline of a MERNstack-based project recently. But I don't think I've learned something very useful which could benefit me for years in the sense of career development. I think "Ops" is just a set of tools that any dev could learn anytime and get used to it.
I think that it isn't just a set of tools, but a set of mindsets and experience patterns. Ops people spend a lot of time thinking about stability, persistence, and safety, and that's not always something that we reward in developers.
Just as devs learn patterns for how to build and architect systems that don't take up too much memory or have message collisions, ops folks learn about patterns of storage, single points of mechanical or network failure, or overusage threat profiles.
There are no programming techniques or logic behind managing cloud infrastructure and resources. Anyone who has some familiarity with systems can easily learn these sets of tools, follow good practices, and manage "Ops".
I tend to beg to differ on this. Infrastructure as code is a well-known pattern that you can apply almost every programming technique for managing your infrastructure. I agree that any dev can learn the tools, though.
All said, I don't mind learning more about it. Maybe I will feel better if I learn more about CS fundamentals. But if I have to specialize, I won't choose this as career.
It indeed takes a lot of time but everything takes a lot of time to learn. But every journey starts with a first step.
I’d add these reasons to your list:
I totally get the risk factor. While application programming can be risky, it's usually much easier to rollback or fix. I might be old-school but I believe that at least senior devs should be familiar with the DevOps concept. After all, it's a pretty new domain that was rose by developers.
Yep, totally agree. And with the advent of “infrastructure as code” (like Terraform and similar) and containerization, hopefully the ease of rollback and risk factor/etc. will reduce over time, making it seem less “risky.”
Not afraid of it. It just doesn't click with me as a developer.
My favorite things are building sites, little apps, and games.
My least favorite things around those spaces are setting up security, databases, and or setting up configurations. Once I get docker set up and it works, I want to go back to what I love doing - frontend dev.