DevOps, Tear Down that Wall!
The important evolution between developers and operations
In the past, with monolithic code bases and long development cycles, it was much easier to justify siloing developers into one group and sysadmins into another. However, building a wall between them encouraged distrust, with each group having different goals and metrics. I had to deal with this a lot in my previous companies.
One of the issues I’ve seen arise all too often is around deployments, which are always a stressful time for those responsible for monitoring and assuring uptime. I have experienced engineering cultures where developers feel their responsibility ends once they hand the project over to operations team for deployment — compounding the stress and deepening the tension. Things can go wrong and often do go wrong during deployment. Distrust tends to breed when you can’t get the help you need to quickly resolve issues, and it perpetuates when something changes on the infrastructure side with no communication to the developers.
These Times, They Are a Changin’
Times have changed with the disruption caused by the rising popularity of cloud services and DevOps roles. The change began in startups where it wasn’t economically feasible to hire a dedicated sysadmin. Instead, they needed developers to know how to stand up an EC2 instance, configure a load balancer with SSL, and set up pipelines to handle continuous integration and deployment. At the same time, with in-house data centers shrinking, traditional operations engineers needed to increase their value. They did this by not just being script jockeys, but instead, learning to code in popular languages and putting in the effort to convert manual processes into automated systems.
Startup Advice: Evolving from Full Stack to DevOps
Today, startups go through the same evolution: Start with a full stack engineer and utilize them until the workload hits a threshold. At this point, a dedicated DevOps role will need to be filled to make the infrastructure scalable and allow the developers to focus more on features.
A DevOps engineer should join the organization with two goals: to automate as much as possible and to increase developer velocity by removing obstacles. At Vurb, I work to ensure these goals by identifying pain points and manual tasks across the company.
Developers, should of course, always understand and have input into the processes and workflows. But they should no longer have to worry about things, like the intricacies of how the code gets deployed. Instead, they can focus on features.
Other things to consider
- Don’t wait until you need a dedicated DevOps person to start thinking about automation and testing.
- Embrace cross training between the disciplines, not only does this foster collaboration it provides additional resources in an emergency.
- Always evaluate build vs. buy when you need new tooling in your stack.
- Don’t fear new mindsets or tools that could increase velocity. Staying with what you have because you don’t want to invest the time to learn always comes back to haunt you.
- Building the right team can be hard. You need to make sure that all members show respect, personal responsibility, and are a culture fit.
Blurred Line Harmony — It’s Good for Everyone
I have found in my experience that when communication exists and both sides understand the challenges each other faces, it reduces complexity and accelerates the entire organization. When I joined the Vurb team last year, I was determined to use these experiences to shape the engineering team. Luckily for me, I found a team that was not only united behind common goals and values, but also embraced the ideas I put forth. No more throwing it over the wall and letting it just be someone else’s problem, no more putting requirements and processes intended to block the other side. When teams are united and work together, life is just better.
Trevor Bossert — DevOps Engineer at Vurb
