Hacker News Reader

Comment by sbov | Hacker News Reader

> significant load

Please define significant load.

Sometimes it's not about load, but speed of innovation. A huge complex monolithic codebase might not have a lot of load, but it can still limit a team's ability to experiment with new features due to big ball of mud. Decomposing areas into service might enable faster innovation better than refactoring the whole monolith.

That seems orthogonal to me: is adding a network boundary really the only way to enforce basic software engineering practices? It seems just as likely that the same organizational issues would lead to e.g. learning that your data model is wrong and part of the app now needs to dispatch thousands of queries, and fixing this is harder than refactoring a couple parts of the same codebase.

(Note: I'm not saying microservices are bad – I just think that the process which lead to that ball of mud will unfold similarly with a different methodology)

30+ requests/sec

Some would consider it light, but I work alongside a company that is currently struggling to get beyond that mark.

So it would probably surprise you to hear that companies I've worked for in the past have built monolithic applications serving pages that were per-user dynamic that can handle upwards of 20,000 requests per second?

This is why I hate this subject. People use terms and don't define them. If you think microservices is the only way to scale past 30 requests per second you're extremely wrong.

I need to give you an internet fistbump for this. I mean...you know what you can even do instead of The Holy Microservice? You can take parts of your API, facade them behind a different load balancer, and call into different instances of your monolith that only handle user management or billing or whatever. Un-run code's cost is, in the general case, basically zero--act like it. You don't need to do something like this, of course, unless your system has very spiky/expensive calls that have to be intelligently routed to systems that have capacity, but heck, you've just insulated yourself from load spikes and can granularly scale.

If you need to. You probably don't, and you definitely don't if you're struggling with 30 reqs/second. This isn't just YAGNI. This is YAHYBDI. You Are Hurting Yourself By Doing It. You need to write better code and examine the assumptions that have created the mess you're dealing with.

Not sure why the contempt with an opinion.

I get that microservices are trite, and most people think they need them long before necessary; however, they have uses beyond scale.

I'm sure that there are ways to mitigate every point I can make within monoliths.

My points are just opinions.

It's not contempt, it's frustration because you're making assertions that are not backed up by reality.

This is what I do for a living, and I am regularly but-but-microserviced by people who are equally ignorant of competent application design and who think that breaking it into HTTP-intermediated chunks will solve that they are choosing to write bad code. That segmentation doesn't--it does nothing. It isn't YAGNI, but YAHYBDI, and I'll get hot under the T-shirt occasionally 'cause people who read discussions like this will get the wrong idea and stick their hands into the saw, too.

I could get paid more by letting people mangle themselves, but it'd be mean.

Their main use is scale, but not tech scale. Scale of engineering teams.

There's the occasional case where a single language won't fit the bill, but there's a big difference between 2 services and 200.

That sounds like it's SoA. It's the forgotten intermediary step between a monolith and a microservice architecture.

Reply on news.ycombinator.com