Exploring microservice ownership and organizational coupling in open-source projects: an empirical study

Abstract

<p>Together with the rising popularity of microservices, practitioners have started to pay more attention to the longevity and sustainability of microservices on the organizational level. Many argue—supported by Conway’s Law—that each microservice should be owned by a specific team or individual developer, although each team or developer may only contribute to a maximum of one microservice. With such a “one microservice per team/developer” strategy, the architecture shall be better maintained in a fashion of “high cohesion, low coupling”, which is a recommended setting for modular software systems. However, it is difficult to achieve such ideal circumstances when the coupling phenomena commonly exist therein, which are caused by cross-service calls and dependencies in microservice-based systems. Especially besides the couplings in functions and modules latent in the source code, it is also noticeable that the microservice project teams can suffer from high coupling issues regarding their cross-service contribution. Such an issue on the organizational level can inevitably result in technical debt and high managerial costs, which need to be detected and mitigated in time to prevent future losses. In this paper, we investigate the existence of the recommended “one microservice per team/developer” setting via an empirical study on 38 microservice-based open-sourced projects together with the different developer roles who are in charge of single or multiple microservices. Furthermore, by taking into account microservice ownership and cross-service contribution, we also investigate the organizational coupling of these projects and the developer roles that contribute to such couplings. The results show that it is rare that such “one microservice per team/developer” phenomenon exists in microservice projects, while the couplings are majorly caused by the leaders and major contributors of the microservices.</p>