At my current employer1 The one with the microservices., I see someone deploying a new version of a service about every 10–20 minutes. At my previous employer2 The one with the monoliths., I had to fight an uphill battle to introduce even daily deployments of one of the most fast-moving products. The slowest moving product had in effect twice-a-year deployments.3 Which is a shame, because that was also the most innovative product that could benefit a lot from shorter cycle times!
“Okay”, I hear you say, “But that’s just a culture difference between two organisations, and not inherent to monoliths/microservices.”
Let’s look more closely. The monolith/microservice distinction is not a dichotomy, but a continuum between large and small independently deployable units. What I’ve oberved in every organisation so far is that the binary size of a deployment strongly correlates with how much time passes between when a change is approved and when it hits production. In other words, even within a single organisation, the larger … things just seem to deploy more slowly.
I don’t know why that happens, but it consistently does.
Besides, there’s another way microservices promote shorter cycle times: the clear service boundaries, combined with separate repositories for each service, force commits to be small. An atomic change can only affect one service, because there’s no way to make cross-repo commits. In some way, this might be one of the biggest benefits I’ve come across so far, because I know how tempting it is to bunch a couple of unrelated changes into the same commit.