Author Sam Newman is an industry expert on the subject. He has:
written for Infoq, presented at Javazone and various other events regarding microservices.
His book 'Building Microservices' does an excellent job introducing the key concepts of microservices:
- services are autonomous, live on their machines
- resilience - one service fails, it doesn't impact other services
- scaling - because services are independent they can be independently scaled
- deployment - deployment should be easy. A change to a service means that's all that's deployed.
- Reactive extensions (running operations as a result of multiple calls not caring if they were blocking / non blocking. For ref: see here and here).
- Catastrophic Failover
- Postel's law
- Tolerant Readers
- Don't get too hung up on DRY. It may make it harder to keep your services independent.
- Consider using CDC's for your testing approach
- Canary releasing / Blue, Green testing for releasing.
- Using bulkhead and circuit breaker patterns to make services ore resilient.
My first concern with microservices is more a practical than a technical one. Doing modular design for everything from your schema, service layer, end points, configuration isn't as easy as some people might think. Especially in teams of varied skill level, varied backgrounds and inevitable commercial pressure that happens in every project. It requires a lot of technical aptitude, leadership and discipline. If a project is not good at achieving modular design in a monolith - for whatever reason - I think it will really struggle at modular design in microservices when the complexity of the network has to be also considered.
The second concern I'd have is that when explaining the principle ideas of microservices, it is often compared with a monolith to the point the word monolith is a pejorative term. The two approaches: monolith and microservices are presented as if it's either one or the other. I think this a false dichotomy fallacy. There are other approaches available.
Thirdly, microservices are no doubt, a clever idea. But that doesn't mean there are a panacea. In some projects they will be a good fit, in others they will not be worth it. One obvious factor to bear in mind is your non-functional requirements. One useful point of reference, that is worth considering is the project James Lewis (another Thoughtworks guru) described in his talk about microservices in 2012. In this presentation, three non-functional requirements for the project caught my attention:
- One component had to handle 1,000 TPS
- Another had to support a user base of 100 million users
- Another had to support batch loads of 30 - 90 million records
Some other references:
- Microservices Anti-Patterns
- Martin Fowler, Microservices
- James Lewis microservices talk at Infoq
- James Lewis microservices Software Engineering Radio podcast
- James Lewis 33 Degree conference http://2012.33degree.org/talk/show/67
Until the next time enjoy yourselves.