If you don't mind telling this story, why did you end up merging them back in? I would have thought that needlessly making microservices is bad but not bad enough to justify merging back.
It kind of depends how well you chose the service boundaries. If you chose well, there's not a huge downside, just a bit of extra overhead. If you chose poorly, it can make it practically impossible to have a reliable app with acceptable performance. If you start out with microservices before you understand the problem space, you are much more likely to choose poorly.
You can still build a "monolith" but in a very modular way. Can't scale independently like microservices, but what if you don't need scale! Compile times are higher but what if you don't need to compile that much code! One error can bring down all "monolith services" but what if your app is not that big!
I'd wager, something like 90% of software projects in companies can just get by with monoliths.
You know...there are monoliths that are well architected, and then there are monoliths that are developed for job security.
Agreed. I've found propogating an error across multiple services to be a much harder problem than handling it with return values/exceptions in a monolith.
>Can't scale independently like microservices, but what if you don't need scale!
What do you mean? Aside from deployed codebase, I don't quite see it - if you need memory, allocate - start small/empty for any datastructure. If managed/gc setup delallocating is inherent, so no special case about freeing memory. Don't create unnecessary threads - but even then dormant threads are very cheap nowadays. There you go - it scales vertically nicely, make sure the application can scale horizontally (say, partitioning by user) and you have all the benefits with close to no drawbacks
We had very similar settings where our codebase was built modular but deployed as monolith. At once we wanted to scale just the Queue processor module out of. We did deploy complete monolith and only enabled Queue processor on other machine. It did add up to extra memory & disk usage. But in the end it helped our team to deploy without going through microservice architecture.
The most amazing thing I saw with a microservices first approach was someone building a betting system with microservices. So if you made a bet, one microservice would make an http call to another to request your balance, make a decision based on that and then move the funds. No locks, no transactions, no nothing. I wasn't sure whether to laugh or cry. Fortunately I got there in time before this thing was launched...
