I used to think that I was rather a 'DevOps' sort of guy, until I was recently reproached for ignoring microservices. I'm not sure how microservice architecture became part of the orthodoxy of 'DevOps', but everyone seems to nod wisely whenever it's mentioned. It is still a 'cool' technology because it promises independent development and deployment, and easy reusability.

For me, the most intractable problem with service-oriented architectures, in general, besides the obvious complexity, was the difficulty of maintaining long running transactions, and managing a Two-Phase Commit that involved more than one service. In microservices, it would be a journey, and in SOA it was a Saga. The insidious nature of the problem is that it tends not to show itself in testing or development, and when it happens the cause is hard to pin down. In fact, the whole problem of managing state is hard, especially if it must survive network problems. Microservices don't so much represent an architecture as a design pattern for distributed services. It provides no intrinsic solution to this two-phase commit problem. It has been described as a technical solution to a man-management problem.

With a 'monolithic' relational database acting as a coordinator, the whole problem disappears, as long as you avoid anything that tries to circumvent it. With Microservices, you can use the Events/Choreography approach, which can work well with short Sagas but is inherently complex and hard to test. The other alternative is Command/orchestration. This involves a service whose only task is to act as coordinator and broker. This can work well, especially if it is all carefully monitored, but it begins to seem reminiscent of the moral tale of 'Animal Farm' where the revolutionary pigs began to look like the hated farmers, because as the tasks grow more complex, these orchestrators or coordinators begin to look like the monolithic databases that so many of the microservices visionaries like to condemn.

My worst problem wasn't transactions, managing versioning, or providing resilient messaging, but explaining and communicating such a complex solution to a business that was considering it. At the start, it is fine: everyone likes the presentation where you show all the microservice boxes in PowerPoint, all running their well-bounded service, and intercommunicating as peers, as compared with the nasty old monolith. It is in describing the management of business processes that the anxiety in the room increases: expensive skill-sets, reliance on bleeding-edge technologies, expensive consultancy.

The even scarier problem is that very few processes, even in well-established businesses, exhibit the dreamy clarity and autonomy of a microservice. Real processes are riddled with interdependencies that sometimes don't emerge until after launch. Your business sponsor may be pleasant and conscientious but unlikely to understand the naked reality of the typical business process in its full arcane horror.

Microservices can work with social-media apps and well-funded green-field projects, and they work well to solve specific problems, but this pattern isn't necessarily right for you.

Phil Factor