3 ms·

I see the strengths and weaknesses in the article, and the complaints from all the comments here, but I still find the trade off of microservices worth it. It r

by krisdol 11y ago

I see the strengths and weaknesses in the article, and the complaints from all the comments here, but I still find the trade off of microservices worth it. It requires sophisticated ops and well defined deployment tools and dev environments, but we have to handle ten billion requests a month on our stack. The ease at which we handle that scale, and the speed at which engineers get to iterate and deploy makes microservices all the more worth it.

StavrosK 11y ago
That's exactly the problem, though. You would find the trade-off worth it if you have ten billion requests a month. The problem is that people do it while only needing a million requests a month.
twic 11y ago
If you used those sophisticated ops and well defined deployment tools and dev environments to develop a monolith, wouldn't it be just as easy? As for scale: are you suggesting that having extra code executing and network calls being made in your system makes it more scalable, rather than less? Ten billion requsts a month is 3805 requests per second on average; i'd guess that means 10 000 requests per second in the peaks (correct me if i'm wrong!). Is this considered challenging scale today? I'd buy four DL380s and call it done.
- krisdol 11y ago
  >If you used those sophisticated ops and well defined deployment tools and dev environments to develop a monolith, wouldn't it be just as easy? No, it wouldn't allow us to be as fast. Most of our services are under <200LOCs (not a policy, just happens to be the point where people seem to split things out). The idea is that any service can be rewritten completely in a few days. There are no tie ins to any platform, compiler version, syntax, or language. This might sound like chaos, but it's a huge productivity gain, as I feel full ownership over features I write. Naturally, we aim for good docs and code coverage, and use continuous deployment and integration tools to keep everything green. As for scale, any microservice can be run across any number of instances without having to scale up the entire platform. This allows us to identify hot areas and deal with them effectively. We don't use network calls (well, not HTTP or TCP) to communicate between services. Services themselves are pretty transport-independent and work well over tcp, but NATS is the transport of choice at the moment for inter-service communication.

by krisdol 11y ago

StavrosK 11y ago

That's exactly the problem, though. You would find the trade-off worth it if you have ten billion requests a month. The problem is that people do it while only needing a million requests a month.

twic 11y ago

If you used those sophisticated ops and well defined deployment tools and dev environments to develop a monolith, wouldn't it be just as easy? As for scale: are you suggesting that having extra code executing and network calls being made in your system makes it more scalable, rather than less? Ten billion requsts a month is 3805 requests per second on average; i'd guess that means 10 000 requests per second in the peaks (correct me if i'm wrong!). Is this considered challenging scale today? I'd buy four DL380s and call it done.

krisdol 11y ago
>If you used those sophisticated ops and well defined deployment tools and dev environments to develop a monolith, wouldn't it be just as easy? No, it wouldn't allow us to be as fast. Most of our services are under <200LOCs (not a policy, just happens to be the point where people seem to split things out). The idea is that any service can be rewritten completely in a few days. There are no tie ins to any platform, compiler version, syntax, or language. This might sound like chaos, but it's a huge productivity gain, as I feel full ownership over features I write. Naturally, we aim for good docs and code coverage, and use continuous deployment and integration tools to keep everything green. As for scale, any microservice can be run across any number of instances without having to scale up the entire platform. This allows us to identify hot areas and deal with them effectively. We don't use network calls (well, not HTTP or TCP) to communicate between services. Services themselves are pretty transport-independent and work well over tcp, but NATS is the transport of choice at the moment for inter-service communication.