Rethinking Ops

Looking back at my years working with infrastructure and going through it’s changes, I believe its time we start to rethink Operations because clearly this model of Ops as cluster or infrastructure admins does not scale. Developers will always out-demand their capacity to supply. Either your headcount is out of control or your ability to innovate and deliver is severely hamstrung. Operations becomes this interrupt-driven thing where we’re just fighting fires as they happen. Ops as masters of production usually devolves to Ops becoming human incident routers, trying to figure out what team or person can help resolve problems because, being responsible for everything, they don’t have the insight to fix it themselves.

The idea of “Ops lock-in” can be a major problem, where your own Ops team who just isn’t able to support the kind of innovation that you’re trying to do slows down innovation.

My thought and vision for the future of Operations is taking combined engineering to its logical conclusion. Just like with QA, Ops capabilities should be embedded within development teams. The reality is you can’t be an effective software engineer today without some Ops skills, and I think every role should be working towards automating itself out of a job. Specifically, my thought and vision is that we should look at enabling developers to self-service through a continuous operation platform and empowering them to deploy and operate their services…with minimal Ops intervention..

With this, Ops become force multipliers. We move away from the reactive, interrupt-driven model where Ops are masters of production responsible for everything. Instead, we make dev teams responsible for their services but provide the tools they need to actually own their systems end-to-end — from the code on their laptops to operating it in production.

Enabling developers to self-service means treating Ops as a product team. The infrastructure automation, deployment automation, configuration management, logging, monitoring, and production tools — these are all products and it’s these products that allow teams to fully own their services. This leads to empowerment.

Products enable ownership. We move away from Ops as masters of production responsible for everything and push that responsibility onto dev teams. They are the experts for their services. They are best equipped to deal with problems that arise but we provide the tools they need to diagnose and resolve those problems on their own.

I believe the near future is exciting and I’m excited to see how we bridge more and more the gap between Devs and Ops while helping organizations to transition to a more effective model, that delivers value faster while reducing toil