Concerns Managing Microservices Repositories With Mono-repo

DZone 's Guide to

Concerns Managing Microservices Repositories With Mono-repo

When it comes to microservices, many people prefer to get a mono-repo. Here, the author offers his perspective and why he prefers multi-repo.

· Microservices Zone ·
Free Resource

About half of the teams I work with on microservices strategy are beginning to freak out about the number repositories they have. In fact, one co-worker regularly debates the subject of having a mono-repo. This type of debate is usually a sign for me that a group is not ready for the hard work involved with microservices. However, it also shows a lack of ability to think, act, and respond to things in a distributed way. It can be a challenge to manage many different repositories. However, with a decoupled awareness of the sprawl that can exist, some adjustments and aggregation to your strategy can be quite doable, even for a small team.

The most important part of sticking to multiple repositories is for the sake of the code. Keeping services decoupled in reality — not just name — is extremely important. Allowing the code behind each service to have its own repository and to build a pipeline keeps everything more efficient, nimble, and fast. Each service you layer into a mono-repo will be one more chunk of time needed when it comes to builds and understanding what is going on with the codebase. I know there are a growing number of strategies for efficiently managing mono-repos, but it is something that will begin to work against your overall decoupling efforts. In all, you are better off having a distribution strategy in place, because the code is only the first place you’ll have to battle centralization, in the name of a more distributed reality.

Github, Gitlab, and Bitbucket all have an API that makes your repositories accessible in a programmatic way. If you are building microservices and working towards a distributed way of doing things, it seems like you should be using APIs to aggregate and automate your reality. It is pretty easy to set up an organization for each grouping of microservices and to set up a single master or control repository where you can aggregate information and activity across all repositories. This can be done using Github Pages (or other static implementation) as a central dashboard and command center for managing and containing microservice sprawl. Your repository structure should reflect your wider microservices organization strategy, and all the moving parts should be allowed to operate in a distributed fashion. This not only includes the code but the conversation, support, and other essential elements.

Recently, I've been spending more time learning about Kubernetes and studying how microservices are being orchestrated. Like other aspects of the API world, I’m going to focus on not just the code, but also the other communications, support, dependencies, security, testing, and critical building blocks of delivering APIs. I feel like many folks that I am talking with are getting hung up on the distributed nature of everything else, while also trying to distribute and decouple their code base. Microservices are definitely not easy to do. Decoupling isn’t an automatic solution to all our problems. From what I am seeing, it is opening up more problems than it is solving in some of the organizations I am working with. As a result, this causes a lot of anxiety about the scope of what teams will have to tackle when trying to find success with microservices across their increasingly distributed organizations.

microservices ,mono repo ,multi repo ,repository ,repository management ,apis

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}