Cultural Elements of Microservices: Service Ownership

Image for post
Image for post

One of the core tenets of microservice architecture, as quoted in the now-classic Lewis and Fowler list, is the principle of Products not Projects. In brief, this principle states that “A team should own a microservice over its full lifetime.” This promotes a number of important practices, such as having development teams take responsibility for the software in production and developers’ relationship with the service not ending when the first version ships.

These are important, battle-tested practices and I am a strong supporter of this principle. However, the effects of the ownership principle on a team’s culture is sometimes misunderstood. Specifically, the emphasis on “owning the service” can be misinterpreted as the existence of a dedicated team in charge of each service, preventing anybody outside of the “owning” team from modifying the source code of the service.

In reality, a control-centric understanding of the service ownership is the opposite of what a healthy microservices organization should aspire to. Let’s explain why.

Image for post
Image for post

Organizations adopting microservice architecture usually accumulate large numbers of microservices. Normally, at the outset of adoption, teams start with a few coarse-grained services. Over time, they end up splitting services and as adoption matures, eventually achieve high levels of service granularity. This is a natural and welcome progression since smaller services are easier to maintain and deploy.

Once high service granularity is achieved, many of an application’s business capabilities may require orchestration of multiple purpose-built microservices for a single unit of customer job to be fulfilled. Imagine that a developer from another team depends on “your” microservice and you are on vacation — or you have moved on to another job (which never happens in tech industry, right?). Due to your unavailability, they could be blocked in completing their work — possibly for a prolonged time.

To mitigate the risks of such coordination delays, teams should build services that are small, focused, and simple enough for any qualified developer in the organization to quickly comprehend and modify them without having any prior experience with that part of the code. A service’s code should be open for collaboration to the entire organization, not just the “owning” team!

Indeed, I have found that for successfully building a microservice architecture, an ideal organizational culture is achieved when the ecosystem is run like an open-source community (think GitHub) and is comprised of many repositories, each actively contributed to by developers from different teams.

If your organization is set up with rigid responsibility lines over service code ownership — or if the service code-base is large, complex and hard to “dive into” — it will be challenging to maintain the open and collaborative internal organizational culture (frequently referred as “inner sourcing”) that a mature microservice architecture requires. Instead, teams should welcome contributions and changes to the code of any microservice in the ecosystem and make service implementations easy to comprehend.

A good rule of thumb is that if the design and code of your service cannot be understood by a qualified developer in a matter of 1–2 days (at most) it is probably too complex or too large. Such services should be simplified or split in order to encourage a robust, and highly functional, microservice architecture culture.

Image for post
Image for post

DISCLOSURE STATEMENT: These opinions are those of the author. Unless noted otherwise in this post, Capital One is not affiliated with, nor is it endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are the ownership of their respective owners. This article is © 2018 Capital One.

Capital One Tech

The low down on our high tech from the engineering experts…

Sign up for Capital One Tech

By Capital One Tech

The low down on our high tech from the engineering experts at Capital One. Learn about the solutions, ideas and stories driving our tech transformation. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Irakli Nadareishvili

Written by

Changing banking for good, one microservice at a time

Capital One Tech

The low down on our high tech from the engineering experts at Capital One. Learn about the solutions, ideas and stories driving our tech transformation.

Irakli Nadareishvili

Written by

Changing banking for good, one microservice at a time

Capital One Tech

The low down on our high tech from the engineering experts at Capital One. Learn about the solutions, ideas and stories driving our tech transformation.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store