Background
A microservices architecture is a gold mine for software business. Modularity, component independency and reuse, scalability, and the freedom to choose a technology are good arguments for any architect planning meeting. Unfortunately, it is only the half-truth.
There is no free lunch
Microservices encapsulate business logic into small and loosely-coupled services. This has been argued as a justification for microservices. Though individual service complexity is reduced, orchestrating a large and distributed system makes things more complicated. A microservices architecture simply shifts complexity from the code design and implementation to system operations.
Designing and building a microservices architecture is a massive investment. A build pipeline, centralized logging system, and orchestration engine are needed from the first version. In addition to this, a microservices architecture makes daily software development such as developing, testing, and deploying more complicated.
Reuse is overrated
The reuse of components is one of the core principles of a microservices architecture. Reuse has been a strong sales argument for numerous frameworks, platforms, and architecture models. Unfortunately, the system that is based on reused components doesn’t come without a cost.
Fred Brooks made the observation that it took about nine times the effort to design and maintain a reused component compared to a single use component. This ratio may be higher than today’s standards, but is nevertheless a substantial difference.
Additionally, organisations often overestimate reuse needs. Nowadays, the products change rapidly and their lifetimes are short. One-size-fits-all solutions are wasteful in many cases.
Is your organisation ready?
Big companies, such as Netflix and Amazon, love to talk about microservices. These companies are able to make an enormous investment, both economically and culturally. If your organisation wants to adopt microservices, it must be ready for these changes.
Microservices principles put pressure on organisations to be more adaptive and flexible. Teams should have the authority to design, plan, and deploy their work. This DevOps culture lifts up the organisation’s maturity demands.
Conway’s Law states that the structure of your software is likely to reflect the structure of your software development organisation. The organisation must create integrated cross-functional teams where business, marketing, and developing teams work closely together to get all the potential from microservices. These organisation changes might be slow and painful.
Microservices provide technological freedom. This could lead to a situation where one system contains countless software languages, paradigms, and frameworks. The outcome is dramatically higher maintenance costs and teams’ standard of excellence.
Time to Rollback?
Should we turn back time and start building a ‘monolithic architecture’ again though ‘serverless architecture’ is just around the corner? Maybe not, although it is always a good idea to see both sides of the moon (even when discussing your favourite technology).
Graphic design
Ville Takala
Read more:
https://martinfowler.com/articles/microservice-trade-offs.html
https://www.oreilly.com/ideas/microservices-shift-complexity-to-where-it-belongs
https://blog.codecentric.de/en/2015/10/the-broken-promise-of-re-use/
https://techbeacon.com/want-develop-great-microservices-reorganize-your-team
