11 ms·
The flaw in your logic/math is assuming that the resulting 5 microservices each have the same 99% uptime as the original monolith. In practice some microservice
by trevor-e 3y ago
The flaw in your logic/math is assuming that the resulting 5 microservices each have the same 99% uptime as the original monolith. In practice some microservices are much simpler and therefore more reliable than others, especially when broken out.
- andy_ppp 3y agoWell, even that depends, the overhead to do microservices well is a lot - versioning of what services are deployed and guarantees around compatibility between said deployments can be a huge amount of work. I’ve seen systems where 2 month old containers are just floating around still being sent incompatible messages. Then there’s teaching developers about CAP theory properly, at Netflix great everyone is sharp enough to get it but at AverageCompanyX, well my experience is 30% of developers actually can’t reason about eventual consistency. Therefore I would question the assumption that things are simpler, code certainly, infrastructure, debugging and deployment certainly not. I would say breaking things down into services, slowly, as it makes sense is enough. They don’t need to be micro.
- trevor-e 3y agoYea totally agreed with your points, a bunch of new problems arise that most orgs aren't equipped to solve and should probably stick with monolith. I was merely pointing out the probability part and how nobody would use microservices if it meant (.99 ^ 5) reliability, although to your point that can definitely happen at some places!
- tester756 3y ago>In practice some microservices are much simpler and therefore more reliable than others, especially when broken out. Much simpler in what way? You mean less close = less crash/segfault potential? If yes, then oh c'mon, modern stacks are incredibly reliable that they almost never crash. More microservices = more infra level stuff needed = WAY more potential problems