Re:Why we ditched Django for Microservices
by StavrosK on Monday January 12, 2015 @09:29AM
(#8873999)
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.
Re:Why we ditched Django for Microservices
by tmwatson100 on Monday January 12, 2015 @09:36AM
(#8874036)
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.
Re:Why we ditched Django for Microservices
by statictype on Tuesday January 13, 2015 @12:50PM
(#8881384)
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.
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?