Having survived several monolith to micro service transitions I can confidently say that you don’t want to go there if you don’t have to. Modular monoliths are the next logical progression in scaling your architecture for the next magnitude of growth. You get a lot of the same benefits and separation of concerns without the overhead. If you find yourself ready to take things to the next level (congrats!) you’ve already got some logical boundaries to chop things out. Even then you might want to consider the “macro services” approach the author recommends.
Microservices are a variation on UNIX philosophy. I think programmers will use them whether or not they're appropriate because stuff that's small and does one thing is like free cocaine to programmers.
I completely agree that most developers will pick architectures and tools that are completely wrong for the problems they are supposed to solve. I have seen it so many times that it greatly surprises me when it isn’t true. Micro-services is a perfect example of this. It inherently complicates everything.
Author here. I wrote this in 2020 and while my thoughts haven't quite changed since, I acknowledge that all architectures have their advantages and disadvantages.
For example, I mentioned GitLab Omnibus, which I still think is a good way of getting up and running, but when a single package includes multiple different components (a PostgreSQL instance, Redis, some other software), then updates can become a bit of a challenge, if there are issues with that abstraction: https://blog.kronis.dev/everything%20is%20broken/gitlab-upda... (disclaimer: the "Everything is Broken" articles aren't always entirely serious)
Though that's more about different types of software, rather than various code modules in your back end. There, I still think that going with microservices first is likely to have issues with complexity for many teams and perhaps that most successful projects that use microservices grew into that architecture gradually, with plenty of lessons learnt along the way.
Since, I've actually heard someone use the term "singleton app" to describe an application that cannot be scaled horizontally (e.g. all user sessions in app memory, or using app memory instead of DB or external key-value store for business processes), which is probably the real thing to avoid whenever possible - in contrast, monoliths and modular monoliths should both be more scalable, while remaining relatively simple, at least while they're not too large.
It is always important to learn History. As it enables to understand the world as it is. That's the best advice I'd give to my younger self.
Some well-known huge companies had problems with scaling. And gradually came to microservices, inventing them along the way.
Everyone else simply uses that invention without knowing the History that they went through. So, they are usually missing many important trade-offs that were made.
Shortcuts and bliss are usually nice, but they always come with a price. Like all those pesky leaky abstractions.
Nitpick: I dislike when there is no indication of the year something was written in. As it fully helps with the context. History is made of dates, as the sequencing is very important to understanding it.
> Nitpick: I dislike when there is no indication of the year something was written in. As it fully helps with the context. History is made of dates, as the sequencing is very important to understanding it.
Noted, thank you for the feedback! The publish dates show up in the article list, but not in the view of an individual article. Might need to mess around with the Grav theme (it's a nice flat-file oriented CMS otherwise), or maybe sometime get around to writing my own static site generator, like all of the cool bloggers do.
Having survived several monolith to micro service transitions I can confidently say that you don’t want to go there if you don’t have to. Modular monoliths are the next logical progression in scaling your architecture for the next magnitude of growth. You get a lot of the same benefits and separation of concerns without the overhead. If you find yourself ready to take things to the next level (congrats!) you’ve already got some logical boundaries to chop things out. Even then you might want to consider the “macro services” approach the author recommends.