Taking Back DevOps

Let’s get DevOps to mean Service Ownership again.

We broke DevOps. And it’s preventing us from building.

When the first cloud providers emerged in the mid-2000s, they unlocked a new superpower: the ability to near-instantly provision hardware. Service-oriented architecture and microservices developed as a new architectural pattern. As a result, DevOps emerged as a practice to organize engineering teams around those new services - combining development and operations responsibilities onto the same team.

In 2006, Werner Vogels, CTO at Amazon, described DevOps as: “You build it, you run it.” Fast forward to today and DevOps is a far cry from these origins. Code is no longer deployed efficiently, and the practice of DevOps has weakened. Here’s how this happened:

1. We rendered the term DevOps meaningless.

Over the last several years, DevOps has become simultaneously a practice, a culture, a team, a job title, and a vendor product. You can hire some DevOps, buy some DevOps, adopt DevOps, and sprinkle a little bit of DevOps on top for good measure.

• ‘DevOps’ is a team, responsible for horizontal engineering concerns like standardized CI/CD and observability.
• ‘DevOps’ is a trendy job title, merely renamed from “Operations”.
• ‘DevOps’ is a vendor product, like “Azure DevOps”, “ServiceNow Enterprise DevOps”, and “IBM DevOps”.

2. We spent way too much time debating microservices vs monolith.

This is the wrong debate. And it’s distracted teams from focusing on how to own and operate code efficiently. For some companies, a monolith works just fine. For others, microservices is the way to go. For many, it’s a hybrid of fat services or serverless or applications or some other mix. The more important question is: How do you get your team to a place where engineers own the code they write so everyone can ship faster and safer?

3. We built some DevOps tools, but for crucial needs we’re stuck in spreadsheets.

DevOps tools are siloed around monitoring, logging, tracing, incident management, CI/CD, etc. But there is nothing that unifies the information from those tools to answer broad questions about production architecture. Companies with the best DevOps cultures use this set of siloed tools, but they have also spent millions of dollars to build their own tools and systems–everything from lists of owners to full-fledged internal tools. We’ve seen teams with:

• Giant wikis of services that answer basic questions about architecture, including simply who owns what.
• Spreadsheets of services that are painstakingly created (and later tossed away) during engineering initiatives like upgrades or security improvements across a large and complex architecture.
• Eventually spreadsheets and wikis are thrown away and complex internal tools are created that require a lot of engineering resources to build and maintain.

Building these stop-gap solutions are a huge barrier to entry; there needs to be a way for all teams to adopt DevOps culture.

Let’s take back DevOps.

If we want to get back to shipping code even faster, more securely, and with less risk, we need to reset DevOps so that it’s synonymous with Service Ownership.

When DevOps = Service ownership, teams get:

• Autonomy: Teams fully control how their systems are built and run in production. Architecture becomes less prescriptive.

• Speed: As long as your team’s SLOs are being met, there should be nothing stopping you from shipping quickly.
• Resiliency: Shifting reliability and security concerns to dev teams naturally increases risk, but ownership involves educating/measuring teams against critical practices so that they can still deploy with low risk.
• Accountability: People are no longer paged because a service goes haywire - or, worse yet, has a security breach - and learn that nobody owns the service, wants to touch it, or even knows anything about it.

We’ve underinvested in tools to make DevOps actually work. There’s a lot we still need to build to help engineering teams adopt service ownership and unlock the full power of DevOps.

__________________________________

OpsLevel enables Service Ownership. It’s the future of DevOps.

OpsLevel helps DevOps teams own, operate, and understand their entire production infrastructure. You can easily catalog all your services, tools, ownership, and changes, while you continuously measure and improve how you build and operate your software. Teams ship faster, with confidence.

Forward-thinking engineering teams at Segment, Zapier, Auth0, Convoy, Under Armour, Chegg, and more use OpsLevel to drive service ownership. We’re proud to announce we’ve raised $5M in funding led by Vertex Ventures, with participation from S28 Capital, Webb Investment Network, Union Capital, and a number of angels including:

• Alex Solomon, Andrew Miklas, and Baskar Puvanathasan (founders of PagerDuty)
• Anne Raimondi (CCO of Guru, Board member Asana, Gusto, Patreon)
• Frederic Kerrest (Executive Vice Chairman, COO, and co-founder of Okta)
• Jean-Michel Lemieux (CTO of Shopify)
• Maynard Webb (ex-COO of eBay)
• Yuri Sagalov (co-founder of AeroFS)
• Evan Weaver (CTO and co-founder of Fauna)
• Paul Judge (co-founder of Pindrop Security)
• Bill Clerico (co-founder of WePay)

If you’re interested in joining our mission to take back DevOps and empower cultures of service ownership, check out our open roles.

_{John Laban and Ken Rose are co-founders of OpsLevel. John was previously PagerDuty’s first engineer and the pair of them bring senior technical expertise from Shopify, Amazon, and more.  They’ve spent the last decade scaling engineering teams and helping them transition to DevOps and service ownership.}