4 ms·
Both approaches can fail. Especially in environments like Node.js or Python, there's a clear limit to how much code an event loop can handle before performance
by maxdo 10mo ago
Both approaches can fail. Especially in environments like Node.js or Python, there's a clear limit to how much code an event loop can handle before performance seriously degrades.
I managed a product where a team of 6–8 people handles 200+ microservices. I've also managed other teams at the same time on another product where 80+ people managed a monolith.
What i learned? Both approaches have pros and cons.
With microservices, it's much easier to push isolated changes with just one or two people. At the same time, global changes become significantly harder.
That's the trade-off, and your mental model needs to align with your business logic. If your software solves a tightly connected business problem, microservices probably aren't the right fit.
On the other hand, if you have a multitude of integrations with different lifecycles but a stable internal protocol, microservices can be a lifesaver.
If someone tries to tell you one approach is universally better, they're being dogmatic/religious rather than rational.
Ultimately, it's not about architecture, it's about how you build abstractions and approach testing and decoupling.
- strken 10mo agoCan you explain a bit more about what you mean by a limit on how much code an event loop can handle? What's the limit, numerically, and which units does it use? Are you running out of CPU cache?
- joker666 10mo agoI assume he means, how much work you let the event loop do without yielding. It doesn't matter if there's 200K lines of code but no real traffic to keep the event loop busy.
- BoorishBears 10mo agoMost people don't realize their applications are running like dogwater on Node because serverless is letting them smooth it over by paying 4x what they would be paying if they moved 10 or so lines of code and a few regexes to a web worker. (and I say that as someone who caught themselves doing the same: severless is really good at hiding this.)
- rozap 10mo agoTo me this rationalization has always felt like duct tape over the real problem, which is that the runtime is poorly suited to what people are trying to do. These problems are effectively solved on beam, the jvm, rust, go, etc.
- rubenvanwyk 10mo agoWait, do people at scale use NodeJS and Python for services? I assume always it’s Go, Java, C# etc.
- Nextgrid 10mo agoDepends on your definition of "scale", but yes. I ran an app serving ~1k requests/second from a Django monolith around 2017, distributed across ~20 Heroku "dynos". Nowadays a couple bare-metal servers will handle this.
- dragonwriter 10mo ago> If your software solves a tightly connected business problem, microservices probably aren't the right fit. If your software solves a single business problem, it probably belongs in a single (still micro!) service under the theory underlying microservices, in which the "micro" is defined in business terms. If you are building services at a lower level than that, they aren't microservices (they may be nanoservices.)
- Seattle3503 10mo agoHow do people usually slice a single business problem?