3 ms·
The idea of unnecessarily replacing nanosecond scale function calls with network communication that is five orders of magnitudes slower makes me shiver. Yeah, y
by kryptiskt 3y ago
The idea of unnecessarily replacing nanosecond scale function calls with network communication that is five orders of magnitudes slower makes me shiver. Yeah, you can make a microservice that does one thing with a well-defined API and it's nice and clean. But you might as well make a module that does one thing with a well-defined API, and it will be so much faster because it's right there in memory with you.
- doctor_eval 3y agoIf you’re replacing nanosecond function calls with microservices, you’re doing it wrong. It’s a specious argument. In the domains in which I’ve worked, most services receive calls over the network, and go on to make database calls that also go over the network. So whether you do the routing inside or outside a monolith makes almost no difference to latency. And what’s more, with a front end like GraphQL, you can parallelise the work which reduces latency further. Microservices have a lot of benefits relative to monoliths, but they aren’t a panacea any more than monoliths are. They’re a useful architecture for certain workloads and a poor fit for certain others. But in my experience it’s quite a lot more difficult to maintain discipline over the long term with monolithic architectures, and that’s why I tend to prefer microservices attached to messaging architectures like NATS. YMMV, and that’s fine.
- objektif 3y agoI would love to hear a valid argument against it. Why microservices as opposed to say modules or libraries.
- vintermann 3y agoSpeed isn't the main argument as I see it, rather complexity is. How much of each of your microservices is boilerplate code? How much is outright copy-pasted? Microservices can be an invitation to write lots of lines of code, so that management sees that you're "efficient".