> In my experience, monoliths are universally bad in every imaginable way.
I just imagined a different way. Monoliths can do transactionally consistent stuff.
I just imagined a different way. Monoliths can do transactionally consistent stuff.
This is how you e.g. can split a bank transaction service from a bank balance-telling service, with different requirements for scaling, latency, SLAs, deployment schedules, etc. You can deploy a change to the balance-telling service and then roll it back if it exhibits a problem, all without touching transaction proceeding in any way.
These abilities are worth something if you're a big enough. But this is not a starting point for a new side project. You start with a monolith.
I think that is the HN syndrome; people start projects like they will be larger than facebook even though the project will probably never launch and if it does, get more than 10 users. Yet it runs all services aws has to offer and has 100 microservices and the little company(‘s investors) are paying through the nose in both dev time and hosting while a raw php script on a $1/mo vps would’ve been sufficient to validate the idea and get to ramen profitability and (far) beyond. Like someone said in another thread; focus on your market and acquisition channels first, build great stuff (much) later.
An architecture that fits well for a small company is inadequate for a large company, and vice versa.
Instead of a balance of a checking account, think about the karma balance of a reddit post, where this approach more emphatically belongs.
So can microservices, both internal to the service (via simple transactions) and between services (via distributed transactions, e.g., 2PC), though a good service design minimizes the need for the latter and is mostly guided by consistency boundaries as to where to draw service boundaries.)
(It's true that there are naive microservices architectures pursued that are essentially normalized relational designs with a one-service-per-table rule, but that's just bad—and usually cargo-cult—design.
I suppose in the end it depends on if you want to trade the hard problem of managing a monolith for possibly a much harder problem.
I find that for these discussions, the definition of a microservice is too nebulous. Personally I think that if you have "state" that crosses service boundaries (ie. a fault in either service causes the loss of that aggregate state) you have instead built a distributed monolith.
Eg, in our case, there's simply no reason why we should have a single monolith service that has both our b2b partners user profiles and, I don't know, internal staff vacation hours?
They have nothing to do with each other, have vastly different load profiles, tolerance for failure etc etc.
In fact, I think its quite common.