Microservices are hard

Microservices are great. Easy to reason about each component, easy to deploy/upgrade/scale. But here’s the rub – it’s quick tricky to see the wood for the trees.

If you push more of the logic about how your system co-operates down into the glue (say nginx, or some other middleware-esque solution), then you can struggle to follow the flow through the system. You definitely need some form of centralised logging, which includes capturing logs from such supporting apps.

I like to think that Microservices are very much like Agile. Deliver small, self-contained components, and allow them to be iterated (upgraded/expanded) frequently. But like Agile, the benefits are balanced by needing greater discipline at the outset.

You should be able to argue for why a component should be a microservice rather than a library or component within a larger single application.

And you’re probably going to need to keep a flow diagram up to date, so you don’t have to ask each time you want to modify the flow, and to quickly bring people up to speed as people roll on and off the project.

You’re also going to need people who understand how the glue works, to help diagnose when things don’t seem to be working.

A very disciplined approach to the interfaces between components is also needed to avoid problems when evolving the contracts – I would recommend semantic versioning and following some guidance for developing HTTP+REST services.

And finally, you’re going to be aware that adding in network hops will invariably make your app slower than having everything in a single app on a single host. Best not to leave your performance testing and/or user-experience testing until the last minute!

The HighScalability blog has a good post on things you should consider.