DevOps seems to have a different meaning to everyone. A Google search for the term brings up varying definitions, but some level of consistency in the meaning can be found on an organizational level. Courtney Wang, Sr. Software Engineer at Reddit, describes it as “empowering the developer” and figuring out how to scale operations to a rapidly growing team, while Heidi Waterhouse, Developer Advocate at LaunchDarkly, says her team focuses heavily on “automating away as much tedious crap as possible.”
There does exist a consensus among most experts that DevOps is a culture and a philosophy. At , , says there’s a mixture of automation and human-process, but his team’s core mission can be summarized as “How do I reduce those ‘uh-oh’ moments?”. He also emphasizes a “blame-free” culture, reinforced by the belief that everyone is in it together, trying to solve problems.
The team at Sentry has built a foundation upon the idea that there must be a mutual respect between developers and operations - no one’s job is more important than another and technical aptitude is not necessarily a measure of worth to the company. James Cunningham notes that while he’s not the world’s greatest developer, he has a strong talent for empowering his developers to excel at their jobs.
Why choose a career in DevOps?
If you’re the kind of person who loves helping others and is constantly challenging yourself and learning, DevOps might be a good choice. A strong technical foundation is definitely helpful, but communication and collaboration skills are also vital. Perhaps you majored in CS in college but found yourself more interested in the high-level aspects of how pieces work together than solving algorithms.
Teamwork is a big part of the job, and like Wang, Cunningham loves empowering his co-workers to succeed. Wang also enjoys the benefit of getting a bird’s eye view of the product and having a hand in everything Reddit is building. “If we fail, then we fail together,” says Katy Farmer, Developer Advocate at InfluxData.
You should also enjoy solving problems. Brian Lucas, Sr. Staff Software Engineer at Optimizely, says his favorite part of the job is taking something that “at one time was extraordinarily complex, figuring out how to do it, and then getting out of the way.” In DevOps, you’re constantly looking for ways to improve the development and deployment process of software.
Automation > People?
There’s a fear held by some that DevOps will automate people out of a job. But while automation is an important part of the role, its real purpose is to minimize the amount of painful tasks performed by humans and allow them to be more productive. Lucas believes that “If you can move on to something else by automating it… then by all means you should pursue that.”
Brad Green also points out that engineers worried about their jobs being automated away should instead focus on the fact that automation of low-level tasks gives them more time to write features and get new users. A startup won’t be around for long if the engineers spend all of their time setting up dev environments and doing manual deploys.
At LaunchDarkly, Waterhouse stresses that the goal is to give developers their lives back. Rather than worrying about deploying a new feature at midnight or the weekend, when no one is on the system, they can actually get some sleep and spend time with their families.
It’s a fear that has existed since the Industrial Revolution, but as we’ve seen in the past, automation frees us to be more creative and work on interesting problems. As James Cunningham reminds us, “There’s always going to be the problem that you need human eyes on.”
Lessons learned in DevOps
Like any career, you’re bound to encounter problems in DevOps. Lack of documentation for the tooling and an incomplete understanding of the underlying systems are just a couple of the headaches experienced by people working in this field.
A common thread among the experts is that many DevOps engineers tend to automate processes without fully documenting how they work. Writing good technical documentation isn’t necessarily fun, but it is crucial to have when things break.
The tools that DevOps engineers have at their disposal now are powerful. It’s easy to string together a bunch of them into a functional (for now) system without really understanding how they work. That’s fine until things go wrong, which is why James C. says it’s important to understand the process, “what’s going on underneath the hood”.
In a similar vein, Courtney Wang points out that it’s important to “balance how quickly something can get built with how safe it is”. Heidi says that in Minnesota, they call it the “4x4 problem” - “You can get stuck in a lot worse snow if you have a more powerful car.”
Choosing the right tools
We built StackShare because we wanted to empower developers and make it easier for them to find and compare the right tools for the job. There are thousands of tools out there for developers. Some tools have pretty websites with strong marketing messages, others have sites that were clearly built by developers with very little experience writing copy. We wanted to create a place that cut through the noise and offered real feedback from people and companies using the tools, with helpful advice.
It’s also important to consider your personal or organizational priorities when choosing a tool. One of the most common dilemmas, says Katy Farmer, is picking between something stable and mature and a tool that’s “new and innovative”. Wang also warns that we engineers have a tendency to pick the shiny new tech that we want to try out. He reminds us that it’s crucial to be honest with ourselves about the problem we’re trying to solve and not “massage the problem you have into something that will fit that thing”.
At StackShare, we believe you should use something pre-built by default and only roll your own when absolutely necessary. As people who love problem-solving and tinkering, it can be very tempting to try and create your own tool when you don’t find something that fits 100% of your needs. The reality is that almost every problem has already been solved by many more people who have spent much longer solving it than you. Even when a tool’s price seems expensive, Heidi advises that “so are your engineers”. If anything, James recommends building on top of something that already exists.
The present and future of DevOps
The rapid pace of change is one of the most exciting things about working in tech. Tools, platforms, and methodologies are constantly evolving and improving. At the same time, Cunningham says he’s “excited that technologies are becoming more stable… that we’re actually slowing down”.
One of the major movements in methodology has been the concept of “shifting left”, which means that blocking processes like QA or load testing that were typically done at the end of the development lifecycle are now moving upstream and becoming a shared responsibility. Brian Lucas at Optimizely says this philosophy has allowed his team to roll features out to production much more quickly.
Super Pro Tip: If you’re curious about what sorts of cool DevOps tools are out there, browse the DevOps section here on StackShare.
