Cultural Elements of Microservices: Service Ownership
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.
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.
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.
