Comments on: Organizing microservices in a single git repository

By: Gustavo Dutra

Gustavo Dutra — Tue, 10 Feb 2015 20:10:00 +0000

In reply to Richard Santos. I'd say it depends. You can deploy normally and make only the relevant services/microservices run on a given machine. Or, maybe, it can be part of the process to remove not used code from the deployed machine. It may differ from deploy tool to deploy tool, maybe I can help you better by asking if you have any specific deploy question.

By: MatthewWAdams

MatthewWAdams — Tue, 27 Jan 2015 16:45:00 +0000

While I don’t disagree with any individual thing you’ve said here, the cumulative effect is that you

1) version all your microservices together

2) upgrade common dependencies together

3) tightly couple microservices in subsystems

4) commonly change several coupled microservices to implement a feature

That doesn’t sound to me like you are talking about microservices at all. What I think you are describing is a standard component-based application architecture.

Microservices add additional design constraints: e.g. small surface-area (single function) services which tend to be built once, well tested at the public API (integration) level, which is strongly defined and long outlasts any particular implementation. Updates fix bugs rather than add features; additional features necessarily imply a new microservice.

Within that context, a feature-based development focus is certainly a good approach, and is not incompatible with the rapid creation of new microservices. These can be developed in the parent repo until the feature is ready (while their APIs are being discovered and iterated), and migrated into their own repositories once they have stabilized at the end of the particular feature delivery sprint.

By: Richard Santos

Richard Santos — Thu, 22 Jan 2015 19:54:00 +0000

How about your deployment process?

By: Rodrigo Rosenfeld Rosas

Rodrigo Rosenfeld Rosas — Thu, 22 Jan 2015 17:36:00 +0000

In reply to milgner.

That’s what we use too to handle our custom gems required by the project, but we don’t often need to work on them. Maybe if those gems were constantly changing to adapt the main project changes we’d have to re-evaluate it and see if getting rid of the submodules could lead to a better experience. Anyway, I don’t feel any pain in working with submodules as I’m pretty used to them for years, so maybe this might be a matter of personal preferences on how to manage the small pieces… I’d probably be fine with either submodules or using the same repository…

By: Carlos Ribeiro

Carlos Ribeiro — Thu, 22 Jan 2015 13:14:00 +0000

In reply to milgner. Here we use this solution too. Works fine for us.

By: iain

iain — Thu, 22 Jan 2015 13:00:00 +0000

We have multiple repositories, and we use a bunch of bash scripts to manage that. My feeling is that most features that we develop have one service that is most involved, and that is where we open the pull request. If that’s not the case, then maybe the new feature is too big.