The DevOps Team Bottleneck

It's 2016, Software has been busy eating the world for a while now, and with the boatloads of new software being released every day, a major shift has been happening in the ways that software is being developed, deployed and hosted. The biggest change of all on the hosting and deployment side has been the the rise of containers, and the need for continuous delivery. But why has there been such a huge jump in adoption? Companies have been doing continuous delivery and server automation with configuration management for years, right? Well, yes, but when your goal is to change the culture of your software development organization, and promote self sufficient teams, that can deploy and manage their own projects, getting there with Config Management will become a major bottleneck. Until Docker made easy to use linux container tech open source, there wasn't any real viable alternative to do it better, and still run on your own hardware or cloud account. Even a product like RightScale that saw significant success, required extensive scripting, or learning Chef.

 The Problem

When a team of developers can't easily deploy their own projects and applications, look at and filter logs, or even have the option of being responsible for the performance and uptime of their own software, because of "magic stuff the ops team handles", you're doing it wrong. It's my humble opinion that the best person to monitor, manage, and scale an application is the team or person who wrote it, not a dedicated ops team. That can be hard to achieve.

All too often, the ops team has a proprietary web of scripts, cloudformation templates, chef/puppet/salt/cfengine/ansible/homemade config management code, and maybe 10-100 other scripts or "gotchas" everyone needs to be aware to modify anything. Doing any customization to how the infrastructure works, specific to each application or service that needs to be deployed, is very painful. That is in no way the fault of the systems and ops people, I'm an ops guy,  we've just been trying to create something that is really hard to create using the open source tools that are available. A platform.

In the beginning, the goal certainly was to get the whole dev team on board with the custom templating and cookbook layout and various command line tools you and the team cooked up.. or maybe to write a wrapper around a bunch of them.. but lots of business, pivots, and day to day yak shaving have made that seem like a fantasy.

PaaS All The Things!

Every SysOps/WebOps/DevOps/*Ops department is secretly building a platform as a service, or wants to be.

  • Developers love Platform as a Service.
  • Developers work faster when they have access to a Platform.
  • When not inhibited by inefficient processes or handoffs, more quality code is produced, in less time.
  • Once a developer has used Heroku, they expect that level of simplicity.
  • Developers want to be able to do all of the stuff the ops team usually does.

And the kicker... The ops/systems team wants the exact same things, they just don't want to get married to a black-box PaaS. So they are toiling away, building their own.

  • Getting stuck in the situation where you're in charge of a system that only a handful of people in the company fully understand is a painful place to be.
  • Getting stuck in the middle of the deployment process, where you are the only one who can "unstick" or fix the build is a painful place to be.
  • Giving self service to developers, and getting out of the way to focus on more interesting things like performance optimization, security, or real innovation is the dream.

Just one small problem: 

Don't Reinvent the Platform 

So many companies spend so much time and money trying to reinvent the platform. It might take years of work, and many engineers and challenges, to develop a system that is fully automated. What you get in the end is a "special snowflake" as I like to call it. It works. It meets the needs of the business as it exists today. But god forbid the person who architected the system is hit by a bus, because likely nobody else in the organization really understands how the whole thing fits together. In a large majority of cases, things are changing so fast that they are not fully documented, or are half baked. This leads to situations where people in the company become the "go to" for certain issues that arise, or certain tasks that need to be completed. Bottleneck detected.

Instead of employing a work force to reinvent the platform, it's much more advantageous to pick a platform off the bat, and let your developers focus on creating value and products that propel your business forward instead. Doing so has serious benefits. It's time to accept that your company is not Netflix, and creating custom everything is probably bad. 

Self-sufficient and Capable

Imagine a scenario where every developer on staff is fully capable of setting up their own hosting environments, deploying their own code, and managing their project in production through it's lifecycle. Does that seem crazy?

Imagine a team where being on-call is something that everyone shares in the pain of handling. Instead of a dedicated ops team getting woken up at 3:00AM to debug and try to fix issues with someone else's software, the person who created it and deployed it gets the alert. Talk about motivation to write well performing and bug-free code.

When the whole engineering team is self sufficient, it opens the entire company up to efficiencies and improvements that are almost impossible when done any other way.

These goals can be reached by deciding on a platform, and pushing application specific automation down to the developer who wrote it, using containers.

Configuration management exists in a disconnected parallel space that is far too challenging to educate and implement in a large team.

Unless you're a company developing a PaaS, it's time to pick a platform and double down on building software that pushes your business forward. You'll be amazed at the benefits. 

Do platforms, and containers interest you? We'd love for you to give our solution a try and let us know how it goes.

Show Comments