Published on May 22, 2016 by Nicola Rizhikov
Everybody is talking about microservices as a preferred approach to structure complex informational systems.
Here are some popular reasons:
- Our monolithic app became too big and complex, so we're going to split it into services
- Weâve reached the performance limit for our monolith, by splitting into services we hope to boost it
- Our system will be huge, so we are starting from microservices architecture to scale in the future
- Successful companies are using microservices, we just want to use industry best practices.
From my point of view these motivations do not have a direct connection to this architectural pattern and may bring you into real troubles or waste. Decision to use a microservices architectural style should be conscious and with understanding of all consequences and trade-offs.
Letâs list some serious penalties you will pay for microservices:
Consistency and dependency management
When you split your system into independently evolving services, these parts still have logical dependencies between each other and the system as a whole should be consistent. In a monolithic app these dependencies are hard-coded explicitly in your code, but with splitting it into pieces, dependencies became âimplicitâ and you need additional efforts (versions, contracts, tests etc) to make sure they are satisfied. Your system becomes more fragile and unpredictable. This in some ways similar to choice between ACID and BASE options. In case of ACID in every point of time you have only one confident version of the world, in BASE worldâââmany parallel galaxies could coexist and you have to manually handle consistency. In worst case you could end up with well known problemâââdependency hell. So without solid âdependency managementâ skills and tools you are on a dangerous road.
âRightâ decomposition
The most challenging concern in micro-services approach (in programming at all :)â how to decompose the whole into pieces? As many matured architects knowâââinitial decomposition almost always incorrect. Doing this ârightâ means you are able to predict the future. Instead of refer you to theoretical hints, letâs discuss consequences of âwrongâ decomposition.
Cross-cutting feature: itâs easy to get new feature request, which require to make changes in many services and then consistently ship it. Sometimes this feature would take minutes in monolith and hours/days in microservices environment. Same about cross-cutting bugs.
Re-compositionâââif youâve found better way to structure your system, then you have to re-compose your architecture. In monolithâââitâs just well known ârefactoringâ, which could be done relatively safely. With microservices such transformation in many cases is not a trivial task.
Operational Expenses
Itâs relatively known paymentâââevery new component brings operational overhead in a non-linear manner. Distributed systems require qualitatively more complicated infrastructure, tools and experts to make it work reliably.
Microservices Pros
Growing your company and system right is not easy. You have to manage two interrelated entitiesâââorganization and system. The most important argument for microservices, for me, is align both in agreement with Conwayâs law. (Micro)Services make it possible to feed service to cross-functional team boundariesâââto make teams independent as much as possible. The critical constraint, you should not miss, is that the team should be able to design, develop and deliver âreal valueâ to the end user with minimal overlapping and conflicts with other teams. âScale your system and organizationâ is worth goal to pay microservices price. The simple formula sounds like:
- one team â many services â wrong (overheads)
- many teams â one service â wrong (conflicts)
- one teamâ one service â right
Under this conditions the size of the service should not be âtoo microâ, but defined only by the size and skills of your teams. As we know, team could scale in very limited intervalâââ2â7 people, but skills can vary in couple of orders.
Another valid argument for me is âtechnological switchâ, situation when your current technology could not provider required technical characteristics, for example performance, and you have to âwrite in câ some critical portion of your system.
Conclusion
This challenges and itâs derivatives will eat most of your time at the start, significantly slow you down in critical section. Thatâs why âmicro-services firstâ approach for me sounds very suspicious. Most of successful âmicroservicesâ applications were done as re-work of monoliths in production into pieces. In that cases engineers had deep understanding system internals and problems.
In most of cases, I vote for âMonolitish Fistâ.
