SMEs, Steer Clear of Microservices!

For more than a decade, hardly a conference goes by without the topic of microservices. Industry magazines publish numerous articles on the subject, and external consulting firms sell workshops, actively advise on switching to a microservice architecture, and tout its benefits. For many small and medium-sized enterprises (SME), this sounds attractive—what helps the big players so much can’t hurt the smaller ones, right? This is a dangerous misconception.

Overengineering — the use of unnecessarily complex software — costs SMEs not just a lot of money and time, it also deprives them of their most significant competitive edge against large corporations.

As diverse as SMEs can be — companies with up to 250 employees and up to 50 million euros in turnover, from startups to scale-ups to hidden champions — their challenges are often similar. This especially concerns resources. Many of these companies have just one or two dozen developers who must quickly adapt to changing product visions or project requirements. The architecture must support this, which is why SMEs are increasingly considering microservices. But beware of overengineering, as it achieves exactly the opposite.

Microservices solve the problems of large corporations…

In large enterprises, with more than 250 employees, the microservice architecture is successfully implemented. It resolves issues of scaling and collaboration among their development teams. Hundreds, sometimes thousands, of developers must work on a single product. Allowing these teams to work autonomously and independently, a microservice architecture is a good solution.

Netflix employs 13,000 people globally, including 2,500 software developers. With this number of developers, a microservice architecture is a way to let many small teams work independently. In the German-speaking region, there are examples too: According to LinkedIn, nearly 1,000 German-speaking employees at Deutsche Bank report having Java skills. Trivago has over 300 software developers. And Check24, according to LinkedIn, has more than 800 employees with knowledge of Javascript. These figures show that companies operate on a different scale than SMEs. The challenges, but also the opportunities, are fundamentally different compared to SMEs.

…and create problems in SMEs

SMEs try to handle with one or a handful of developers what large corporations manage with hundreds. Teams in SMEs often underestimate the overhead in maintaining a microservice landscape and the associated costs.

A microservice architecture is a distributed system. In distributed systems, compromises must be made between data consistency, processing speed, and reliability. It costs much more time, energy, and ultimately money to meet these features for the product than in a monolithic application.

Infrastructure and its maintenance become exponentially more complex and costly with each additional component. Instead of a single application, five or ten must be deployed, maintained, and monitored. Automated alarm systems must be built, and CI/CD pipelines need to be more complex. More extensive processes are required to manage versioning, API compatibilities, and maintenance tasks.

A closer look reveals an additional cost factor: many development teams in SMEs have not correctly partitioned their software. The software of an SME is usually within a single domain. There may be a few minor peripheral domains, but these are rarely critical. And this realization is consistent: Why would a company with ten software developers have multiple domains, but not a large corporation where a team of ten also manages a single domain?

The software of an SME does not have the scope and feature set of a Spotify, Netflix, Check24, or Deutsche Bank. And according to domain-driven design, a domain should be managed by a single application. When a single domain is mistakenly split into multiple applications — presumed microservices — a distributed monolith is created. This architecture then only combines the disadvantages of both the microservice architecture and the monolithic architecture.

Too complicated software architecture often leads to the gradual failure of the product. Costs rise exponentially with ongoing development, rendering the project unprofitable. Or the software becomes inflexible, and new market insights or strategic adjustments to the product cannot be incorporated, or only at great expense.

Let’s Talk About Overengineering!

Microservices are typically not the suitable solution for the requirements of SMEs. Why are they still so frequently used in SMEs?

The survivorship bias might explain why the microservice architecture is now the dominant architecture form in SMEs. This cognitive bias describes the phenomenon where successful events are more memorable than failed ones. For instance, we are more likely to read stories about people who became millionaires overnight with Bitcoin than all the tales of losses in cryptocurrency trading.

Most development teams are not even aware of the overengineering problem, as it is seldom discussed. We need to start discussing it. Software architecture is adaptable. It must and can adjust to the specifics of the business. At present, a monolithic application might be the best solution for SMEs. In the future, it can be adapted to the growth of the business and transition to microservices. But:

SMEs need different solutions than large corporations.