Over the last decade or so a lot has been written about SOA and microservices. And for each blog or tweet there is probably a corresponding failed project based on these more or less ambiguous architecture styles. In this blogpost I will provide my point of view on why they fail and what the remedy could be.
Let´s have a look at the following scenario:
If I were to set up a brand new telecom company (which by the way is not very hard) I would definitely not hire a bunch of developers to build my core IT systems based on microservices. I would rather buy the core systems off-the-shelf. Why would I even consider engaging consultants that bill by the hour to create something I could easily buy, either as a system or as a service? I would basically need a CRM-system, a rating engine, a billing solution and provisioning system and I would be up and running within a few weeks. And then after a few years neglecting the need for consistency and integrations in my IT-stack (stupid me) the answer from the microservices camp would be to split my monolithic IT-stack into microservices. I might get convinced and start the project. But down the line I will stop the project having spent a lot of dough on consultants and getting nothing in return. Why is that? What´s going on?
What is going on is that the consultants preaching the architecture styles does not respect the complexity and the fact that business logic and their data belongs in the core systems. These are systems being developed by experts (yes there are actually software vendors with skilled developers) within their domains over several years. They are complex, well proven and designed to solve particular problems. A “new” architecture style won´t make it any easier. Unless you have a very clear understanding of the complexity along with an even clearer strategy on how to get on air, trying to “service orient” these systems will fail. Over and over again. Simply because the systems (or monolithic systems) you are trying to understand (or worse, think you understand) and refactor to good microservices are too complex.
All the buzz around microservices and DevOps, especially when presented by various flashy speaking CTO´s from Netflix, Amazon, Spotify and such might fool you to believe that microservices are the blueprint for all companies trying to disrupt the way we do business today. The big difference from these companies and more traditional companies are that they have created new services with fewer options buying things off-the-shelf. Hence, they have successfully been able to create sound IT-systems based on sound architecture styles such as microservices. And luckily for them they probably have a shorter time2market than my telco. But when you try to apply microservices for instance on a pension system or financial transaction system and by doing it right, the microservices should hold its own data, be autonomous, have strict boundaries etc. you will fail. Because the business logic is just too complex. Customers with the persistence and patience required to see the project to the end comes around once every leap year. Therefore the label on your microservices toolbox should be “Handle with care”.
In short, my observation is that these projects fails simply because of a more or less religious belief that the architecture style itself will make everything easier, neglecting the complexity of the very problem you are trying to solve. It´s a complex world. Respect it and respect your client’s budget. After all, it’s all about the money.
