4 ms·

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

sbov 9y ago
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.
- eropple 9y ago
  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.
  - olingern 9y ago
    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.
    - eropple 9y ago
      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.
    - bpicolo 9y ago
      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.
  - true_religion 9y ago
    That sounds like it's SoA. It's the forgotten intermediary step between a monolith and a microservice architecture.

sbov 9y ago

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.

eropple 9y ago
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.
- olingern 9y ago
  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.
  - eropple 9y ago
    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.
  - bpicolo 9y ago
    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.
- true_religion 9y ago
  That sounds like it's SoA. It's the forgotten intermediary step between a monolith and a microservice architecture.