> "In short, the microservice architectural style is an > approach to developing a single application as a suite > of small services" Sure, it's a si

> "In short, the microservice architectural style is an > approach to developing a single application as a suite > of small services" Sure, it's a single application from the perspective of the user, and that's a great abstraction to keep in mind when you're talking about things like uptime. But from the perspective of the operator, it's purely an abstraction -- a name you give to the collection of things you're manipulating. As such, I'm not sure building a single repo of git submodules makes much sense. Maybe for accountability reasons, but not for actual operations. The ·raison d'être· of microservices is to decouple the lifecycle of each service totally. By recombining them into a tagged release repo, you're arguably subverting that intent. > The problems occur when you have multiple commits to > different services. If a build is marked "red" because > it fails a "future integration" then it just means that > it is failing at that point in time. It may, following a > commit of a dependency, become valid. However, it would > need to have its build manually retriggered . . . Yep. To solve this problem, your CD system needs to automatically trigger rebuilds (and re-tests) of dependent (downstream) services when a dependency (upstream) changes. The easiest way to do that, in my experience, is to have a manifest in every repo that specifies dependencies as a flat list, which the CD system can parse to build a dependency graph. Tangential point, but -- with this, we're just scratching the surface of the incidental complexity that comes when you move to a microservices architecture. This is the stuff that isn't in all of those exalting blog posts -- beware! :)