3 ms·

> Microservices conversations are abstract, with little tie-in to real business goals In my experience there's plenty of blame to lay here. Some organizations

> Microservices conversations are abstract, with little tie-in to real business goals In my experience there's plenty of blame to lay here. Some organizations are too siloed and some architects are too inexperienced. The following aren't inherent to microservices, but are general architecture concerns: scaling up to handle more concurrent requests, hitting your SLA uptime, reducing defects or memory usage by avoiding statefulness, reducing latency, separation of concerns to improve maintainability, etc. Are these not immediately obvious impacts to the business? Is it not obvious how microservices can help here even if it's not the only way to solve these? My main question is whether the author is as similarly inexperienced as the architects.

mkesper 2y ago
These may be sold as points for microservices but in the end are wishful thinking. No microservice can turn statefulness into stateless, the state still needs to be handled somewhere. Microservices also do not magically improve uptime or anything.
lelanthran 2y ago
> scaling up to handle more concurrent requests, hitting your SLA uptime, reducing defects or memory usage by avoiding statefulness, reducing latency, separation of concerns to improve maintainability, etc. > Are these not immediately obvious impacts to the business? Depends; for b2b loads all those concerns but the final one can be be met with a single beefy server for DB writes, with multiple read only replicas. Run multiple instances of your monolith app behind a load balancer and you should be good for maybe 100k users working on that app at mostly the same time. With care (redis serving session data) this is fine for even very high loads. Once you start doing b2c and have millions of users logged in and doing stuff at the same time then those concerns are valid.

mkesper 2y ago

These may be sold as points for microservices but in the end are wishful thinking. No microservice can turn statefulness into stateless, the state still needs to be handled somewhere. Microservices also do not magically improve uptime or anything.

lelanthran 2y ago

> scaling up to handle more concurrent requests, hitting your SLA uptime, reducing defects or memory usage by avoiding statefulness, reducing latency, separation of concerns to improve maintainability, etc. > Are these not immediately obvious impacts to the business? Depends; for b2b loads all those concerns but the final one can be be met with a single beefy server for DB writes, with multiple read only replicas. Run multiple instances of your monolith app behind a load balancer and you should be good for maybe 100k users working on that app at mostly the same time. With care (redis serving session data) this is fine for even very high loads. Once you start doing b2c and have millions of users logged in and doing stuff at the same time then those concerns are valid.