More seriously, the first piece of advice I’d give a monolith-owner about converting to microservices would be to work very hard to factor their monolith well. Interestingly, across dozens of cases, I’ve never seen that advice taken.
There’s always a well-dressed person with excellent powerpoint who is happy to give a compelling case for a technical solution to a problem that isn’t technical.
If you can’t factor the monolith, you won’t be able to factor your microservices. All of the same forces will be in play, all of them, with the difference that in a monolith excellent factoring is extremely important, but in microservices, excellent factoring is mandatory.
The lurking idea here: over-emphasis on the made, under-emphasis on the making and the makers. The technology sell is based on the idea that the chief difference between before-microservices and after-microservices is the artifacts, the made.
But every artifact that’s made depends on having makers doing the making. If they’re weak, the artifact is weak. If they’re strong, the artifact is strong.
What you have now is a weak monolith. (Weak in your terms, you’re the one wanting it to change.) It got there because the making of it was also weak. If you don’t change the making — and correspondingly the lives of the makers — you won’t change the made.
The proposed benefits, scalability, measurement, a/b alternation, robustness, and above all parallel changability, all of these derive from changes in the making caused by changes in the minds of the makers.
All of them, with the possible exception of scalabilty-by-spinning-up, are perfectly available in a monolithic architecture as well. In order to get them, you have to have makers making them that way. Which is exactly true of microservice architectures.
So, my response to orgs contemplating the microservice jump is pretty straightforward: most of them haven’t even begun to press on the limits of what a monolith can do. All they’ve done is press on the limits of what command-and-control rule-based programming teams can do.
And hence my advice: before you leap to microservices or serverless or clouds, get your making strong enough to maximize what can be done in simpler architectures. When you hit the real limits of the monolith, your making and your makers will be strong enough to make the change.
The GeePaw Podcast
If you love the GeePaw Podcast, show your support with a monthly donation to help keep the content flowing. Support GeePaw Here. You can also show your support by sending in voice messages to be included in the podcasts. These can be questions, comments, etc. Submit Voice Message Here.