One of the core tenets of the Microservice Architecture, quoted in the now-classic Lewis and Fowler list, is the principle of: Products not Projects. In brief, this principle explains that “a team should own a product over its full lifetime”, where by ‘product’ we imply an individual microservice.

It’s a great principle that promotes number of important messages, such as: development team taking responsibility for the software in production and developers’ relationship with the service not being done as soon as they ship the first version. However, when viewed from a team culture perspective, it carries significant risk of being misunderstood. Specifically, the emphasis on “owning the service” can be misleading. It does imply that there’s a dedicated team “owning” each service, which can easily be misconstrued as: nobody outside the “owning” team should modify the code of a service. This is the opposite of what a healthy microservices organization should aspire to.

Organizations adopting Microservice Architecture will eventually find themselves with large number of microservices. Many of those microservices will call each other to acquire the capability expressed by the microservice being called. If a fellow developer depends on “your” microservice and you are on vacation, or if you have moved-on to another job (which never happens in tech industry, right?), the worst thing would be nobody else, in the organization, having the understanding or experience with your microservice’s code. Indeed, one of the most important traits of Microservice Architecture is each service being small enough, hence: simple and clear enough, for any developer in the organization to quickly look at the code, comprehend it and modify it, when and if they need to. Obviously there is always certain QA process for accepting modifications, even within the service “owning” team, but service’s code should be open for collaboration to the entire organization, not just the “owning” team!

For a microservice architecture, ideal organizational culture is achieved when the ecosystem is run like an open-source community (think Github): lots of different repositories that many people have understanding of, since they not just use those, but also actively contribute to various “projects”.

If your organization is set up with rigid responsibility lines over service code ownership, or if service code-base is hard to “dive into” – you may want to rethink the culture of the team and its fit with the architectural style.