Hacker News Reader

Comment by foreigner | Hacker News Reader

I'm embarrassed to say that I recently built microservices first, and am now kicking myself as I merge them back in to a monolith.

View on HN

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 depends how many you have. Microservices can make things like updating dependencies a massive pain (now you have to do it 10 times)

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.

>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

You're actually right. Just don't call the portions of the app and you can horizontally scale too.

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.

Never really got this "One error can bring down all "monolith services"".

Can you share one example where an error couldn't be handled gracefully in a monolith?

Say if my shipping service fails for some reason, I can still fallback to a default cost in a monolith.

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.

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...

Reply on news.ycombinator.com