[statictype]

What about the headache of monitoring 10s of microservices, making sure they stay up and running and healthy?

I assume that REST or Thrift (or something similar) is the way most microservices talk to each other. What if the latency isn't acceptable?

I've thought about switching our architecture to microservices but these two potential issues are making me hesitate.

How important are these issues in practice?

[StavrosK]

In my experience with microservices, the vast majority of bugs were in services not talking to each other properly, or in some variation of that interface. There are some security complications that means services aren't very free to talk to each other (which introduces complexity), but, overall, I think I prefer the monolithic model. Our Django app isn't too hard to set up, requirements.txt contains everything and the rest is in an Ansible playbook.

[tmwatson100]

It depends on what you're building. For us, we haven't noticed any issues with latency just yet and there are plenty of steps you can take to optimise this down the line.

As for monitoring there are plenty of tools to do that. You have bigger problems if you expect your services to go down often.

[statictype]

As for monitoring there are plenty of tools to do that. You have bigger problems if you expect your services to go down often.

Yes, even in your monolithic app, you probably used some tooling to monitor it. But now that single service being monitored has multiplied into 10-20 services being monitored.

Nobody expects their services to go down, but if you don't plan for it, then that means you haven't thought about high availability or disaster recovery enough.