Weeding your micro service landscape
When you look at how a given organization develops software over time, it’s not uncommon to spot evolutionary patterns that mimic what we see in nature. Particularly where micro services are involved, you might well be able to deduce which services came first, and which were developed later in time, by looking at various subtle variations in project structure, tools, dependencies, build pipelines and deployment descriptors. Later services copy elements from the initial template services, apply variations to fit their needs, and successful variations are again used in future services, or even applied in the original template services.
Variations from service to service are essential to maintaining a vibrant engineering culture, with room for experimentation within appropriate boundaries. Over time however, all the subtle variations can make it harder to reason across services, particularly when you want to apply broader changes.
In this blogpost I’ll outline, and provide various samples of, how I harmonize such diverse micro service landscapes, and the scripts I use to reduce the accidental complexity in maintaining the various variations.