Monolith First (2015)

Nearly all the micro services based designs were terrible. A common theme was a one or two scrum team dev cohort building out dozens of Micro services and matching databases. Nearly all of them had horrible performance, throughout and latency.

The monolith based systems were as a rule an order of magnitude better.

Especially where teams have found you don’t have to deploy a monolith just one way. You can pick and choose what endpoints to expose in various processes, all based on the same monolithic code base.

Someday the Internet will figure out Microservices were always a niche architecture and should generally be avoided until you prove you need it. Most of the time all you’re doing is forcing app developers to do poorly what databases and other infrastructure are optimized to do well.

It seems people think "Big Ball of Mud" when they hear Monolith but they're not equivalent. Jut like I tend to hear "Spaghetti Code" when I hear Microservices. But again they're not equivalents. Both architectures are equally capable of being messy.

Tbh, it didn't work for us: our org chart changes more frequently than the codebase's architecture (people come and go, so teams are combined, split, etc. to account for that, many devs also like rotation, because it's boring to work on the same microservices forever), so in the end basically everyone owns everything. Especially when to implement a feature, you have to touch 10 microservices -- it's easier and faster to do everything yourself, than to coordinate 10 teams.

>Second, with monoliths, there is some temptation to violate API boundaries if it let's you get the job done quickly, at the expense of causing headaches later: Just reuse a private until method from another module

This is solvable with a simple linter: it fails at build time if you try to use a private method from another module. We use one at work, and it's great.

That depends on the context. If I come to the paint store I would be surprised if I'm offered either black OR white paint. As If I can not buy and use both, depending on my scenario. Black and white are generally not the same thing, but they are not mutually exclusive in your practice.

(and by the way comparing sizes to color is a bad analogy. the better one would be comparing a big ship with a set of ships. So I state that I can have a fleet of ships, some of which are also big. And one big ship is also can be considered a temporily outnumbered fleet: if it has means to cooperate I can easily add more smaller ships when needed, instead of builidng yet another deck on the main ship).

My point is: microservices vs monolith is a false dichotomy. You can use both approaches at the same time, since each one of them has its own advantages.

If your infrastructure is ready and you know how to manage microservices, than you can just start building monolith unless you decide that some particular part is better be separated due to some reasons like context isolation, separate deployment, separate scaling etc. It will take you a day for the first time. And an hour for the second time and further.

However if your "infrastructure" is just local files with logrotate on a bare-metal machine, if you don't know how to reuse the common code base for different deployment units or if you do not know how to do backward compatible protocol schema evolution, then bad luck -- you just do not have a choice when it comes to designing a new functionality. You'll have to add the new feature to your monolith despite all the benefits you could reap by separating it.

Microservice-ready infrastructure is all about having the capability to separate parts of logic easily when you want to. It neither dictates you to break your monolith right away nor to build only 30 lines of code services from now on