I'm excited today to announce s28 Capital's investment in OpsLevel. While we've been long-time supporters of the company - having led their first institutional round back in March 2019 - we've been even longer-time friends with the founders, John Laban and Ken Rose. John, Ken, and I worked together for many years at PagerDuty. Together with the rest of the early PagerDuty team, we built a product that set the standard for how technical teams respond to high priority incidents. But our story starts even earlier.
John and I first met in 2001 as classmates at the University of Waterloo, but we really got to know each other well in 2005 when we started working together at Amazon.com. At the time, Amazon was in the final stretch of moving from a monolith (all functionality compiled into one binary) into a service oriented architecture (SOA). Even as a junior employee, the advantages of this architecture were clear. We could push changes to our team’s components into production ourselves, without first having to check in with an integration or QA team. If something went wrong, it was easy enough for us to roll back the change without affecting other teams' deployments. In general, Amazon's adoption of SOA allowed each engineering team to move faster and more autonomously than either of us had experienced in our (short!) careers up until then.
To be clear, SOA wasn't something invented by Amazon. However, they were doing it at a scale and at a pace of development that was pretty unique . To do so, Amazon created an engineering culture and collection of best practices and tooling that were adopted to varying degrees by the broader tech world in the 2010s. For example, Amazon engineers had (and probably still have!) a very strong sense of ownership over their services. Engineers knew that if they shipped buggy code, it would be them (and not a separate ops team) that would get paged when the order volume unexpectedly dropped. So while the engineering team could ship changes without having to get signoff from QA & ops, it was the same engineers who would be responsible for correcting any problems that might crop up at 2am. Sound familiar? Amazon was practicing what today we call DevOps at least four years before the term was coined.
The word "DevOps" has come to mean a lot of different things lately, but to me it simply means that the people responsible for developing a unit of software will also be the same people responsible for operating it in production. Every service (micro or otherwise!) is owned by one team that is responsible for the service over all stages of its lifecycle. We built the initial version of PagerDuty assuming that the DevOps approach of strong service ownership was going to win, and very fortunately for us, it did. Unlike many prior incident response systems, PagerDuty focussed just as much on the people aspects of incident response as on the cataloguing and tracking of the incidents themselves.
Fast forward to early 2019. John and Ken approached me about a product they were building that would bring our learnings from PagerDuty and Amazon on the importance of service ownership and “people focus” to a wider audience. Specifically, they wanted to build a system that would link machine data (ex. when was a service last deployed, what are its dependencies), and combine it with people data (ex. who owns this service, who is available now to answer a question about it) that normally lives only in an engineering team's collective mind. However, unlike PagerDuty, which focuses just on the incident resolution process, they were going to bring this combination to all stages of the software development lifecycle.
Someone once told me that "we shape our tools, but then our tools go on to shape us". I'm excited to be working with John, Ken, and the rest of the OpsLevel team in building this critical tool. I can't wait to see how their rethinking of the service catalog changes the way we collectively build software.
 As an aside, check out Steve Yegge’s “Platform Rant”: https://gist.github.com/chitchcock/1281611. He describes some of the lessons Amazon learned during their adoption of SOA. Many of these are or could be the core of large businesses. Working at Amazon in 2005 really was like living 10 years in the future.