Microservices has become the de-facto architecture standard amongst modern software development teams. Netflix is widely known for its microservices architecture, and technologies like Microsoft Azure and Confluent place microservices at the center of their product's value-add. For teams who haven't adopted it, there is a wealth of information available on why transitioning from a monolithic application to one defined by independently deployable services is critical to building a reliable product at scale.

As much as it's doted upon in the industry, however, adopting microservices in and of itself isn't quite enough to claim success. To ensure that your application architecture truly enforces a separation of concerns and is resilient to failure in the long run, software development teams must build systems of ownership, accountability, and traceability around it.

In this post, we'll focus on service ownership. Why is service ownership important? How should teams self-organize to achieve it? Where's the best place to start?

Software as a Product, not Project.

Product and engineering leaders at the world's most successful technology companies will agree that an application should be regarded as a product, not a project. Traditional teams who treat software as a project may have one development team responsible for writing some piece of code, and another operations team responsible for maintaining that code in production. If you're familiar with Amazon's "you build it, you run it" mentality, you know that this model is organizationally risky at best, and a disastrous barrier to success at worst.

Inspired by Amazon CTO Werner Vogels in 2006, engineering teams have since worked towards a world where developers who build a piece of software are accountable for operating it — accountable for responding to late-night outages, fixing bugs, enhancing testing, and assisting with customer support tickets throughout the course of its lifetime. This makes for high-quality code, increased agility, and stronger empathy with users. Thirteen years later, this model continues to prove successful.

The Service Ownership Dream.

In the context of microservices, the developer accountability that comes with software as a product is what service ownership is all about. Let's say you're on a DevOps team that runs some combination of the following: A collection of APIs, front-end component libraries, a Grafana and Prometheus stack for monitoring, and a set of Docker images for users to deploy your application. Adopting a microservices architecture means decentralizing everything such that each service is independent and has an explicit boundary from the rest. But what does service ownership in this context actually mean — or not mean?

Service ownership means that there is a clear person or group of people who are ultimately held accountable for the success of each service. Successful service ownership does NOT mean that the owners of a service are or should be the only humans modifying its code. Larger teams typically host over 200+ services (some of which will inevitably have interdependencies) and it's critical that the knowledge around that service doesn't live in a silo. Service owners are simply responsible for making sure that the rest of the team has access to the information they need to properly modify it.

At Cortex, we'd say that if service ownership is done well, the following is true: