3 ms·

Most real world microservice projects (I've worked on several) already have many single points of failure. Often there is one service that needs to be up for t

Most real world microservice projects (I've worked on several) already have many single points of failure. Often there is one service that needs to be up for the system to be up (such as the one that processes your customers orders), you don't realise some VMs are sharing a physical disk or everything is dependent on a single router somewhere you've never heard of that will one day run out of memory and drop TCP connections. This is not to mention the risks posed to availability by third-party tracking software that push changes that break web forms (#1 cause of long outages in my experience). Message brokers like RabbitMQ give you a lot of benefit and introduce only a small number of failure modes. You can obviate tricky service discovery boot orders, do RPC with without caring about whether about your server could be restarted and of course you get a good implementation of pub-sub too. If you stay away from poorly considered high availability schemes I am absolutely fine with recommending it for intra-service communication.

pm90 11y ago
Great comment. One thing I don't like very much about microservices is simply that my service often will have some such hard dependency. e.g. if the logging service is down, I lose all logs-based statistics. If the authentication microservice is down, I'm screwed. The parent comment made the excellent point about SPOF, but it seems like for microservices to work correctly, there will always be some SPOFs. Maybe I'm being too pessimistic. I use microservices, but without significant engineering rigor, I think its a recipe for disaster.
- zeisss 11y ago
  > If the authentication microservice is down, I'm screwed. Well, make sure your sevice is not dependent on those services then. Use signed tokens to only rely on the authenticator for logins. everything afterwards can work it our by themself. logging: keep your stuff in a queue or logfile, until the log service is back up.

pm90 11y ago

Great comment. One thing I don't like very much about microservices is simply that my service often will have some such hard dependency. e.g. if the logging service is down, I lose all logs-based statistics. If the authentication microservice is down, I'm screwed. The parent comment made the excellent point about SPOF, but it seems like for microservices to work correctly, there will always be some SPOFs. Maybe I'm being too pessimistic. I use microservices, but without significant engineering rigor, I think its a recipe for disaster.

zeisss 11y ago
> If the authentication microservice is down, I'm screwed. Well, make sure your sevice is not dependent on those services then. Use signed tokens to only rely on the authenticator for logins. everything afterwards can work it our by themself. logging: keep your stuff in a queue or logfile, until the log service is back up.