TL;DR: My new employer has built their software as many separate services, communicating through well-defined networked interfaces. I have spent the past few years working on monoliths, so this takes some adjustment.
While these sound negative, I don’t mean to say this is a negative experience. There are many positive things I’ve noticed too, but I already expected them because proponens of microservices have done a good job of marketing the idea to me already.
The things above are those I didn’t expect. But first, let’s kill a myth, and then go into these points in a little more detail.11 Please note that these are the very early observations of a microservice beginner, and drawn mainly from a specific system that may or may not be well-architected. I’ve tried to tease out more general lessons from this specific system, but I still have a lot to learn and it’s likely that one year from now I will re-read this article and wonder what I was smoking.
A monolith is not synonymous with a bowl of spaghetti. we can have separate projects, well-delineated modules, stable interfaces, etc. If we build all of that up into one huge binary deployed as single unit, it is a monolith. There are some benefits to doing that: