Part 2 of my “Responsible Microservices” series went live last week!
Should that be a Microservice? Part 2: Multiple Rates of Change
In the first part of this series, we laid out a set of principles to help you understand when microservices can be a useful architectural choice. We promised follow-up pieces describing each of the factors in more detail. Here’s the first of such posts; let’s explore multiple rates of change.
Recall our Widget.io example, a prototypical shopping app.
We discovered that our Cart and Inventory functions hadn’t been updated in some time. Meanwhile, the Recommendation Engine and Search capabilities are modified frequently.
Splitting those two modules - Recommendation Engine and Search - into microservices would allow the respective teams to iterate at a faster pace. This approach will help us quickly deliver business value.
In this fictitious example, we can simply declare “these modules change a lot.” But that won’t fly in the real world. How do we find parts of our application that evolve at different rates? More specifically, how do we find the components that change far faster than the rest?
Normally, software developers skew logical. But let’s use our emotional and rational brains in concert. Odds are, you have an inkling about the part of your app most likely to benefit from faster iteration. Trust your gut instincts!
But you shouldn’t rely entirely on feelings. We can use our source code management system to give us a “heat map” of our code. With a git repository for instance, we can run git log with a few command line options piped through common Linux tools. We can generate a “top ten list” of most commited files with a command like this:
git log --pretty=format: --name-only | sort | uniq -c | sort -rg | head -10
Continue reading Should that be a Microservice? Part 2: Multiple Rates of Change on the Pivotal blog.