Monolith vs. Microservices Architecture in a Nutshell

If you want to keep an existing, lucrative business and manage it simply and efficiently: choose the Monolith.

But if you operate in a dynamic market segment, if you’re facing competition, if speed, agility and time-to-market are important to you, or if you have big plans and scalability is a priority, then the Microservices architecture is the right way to go.

Why does Microservices architecture offer these advantages over the Monolith?

Microservices architecture cuts a big problem down into many small manageable ones. Of course, many small problems aren’t necessarily easier to deal with but the trick is the defined interfaces between these little problems. Thanks to these interfaces, it’s possible that each small problem (area/feature/team) can be handled relatively independently. In each case an optimized way can be chosen, which solves the problem best and as quickly as possible.

The idea isn’t new in software architecture (SOAP, etc.). What’s changed in recent years is the performance of processors and networks and their easy availability as virtual cloud services.

So, today it’s possible to do what was unthinkable 10 years ago: distributed “best-of-breed” Microservices (API-First) in which different providers work together – in “real time”, without noticeable delays.

Only through the consistent use of a Microservices architecture was it possible for well-known brands like Amazon, Netflix, Uber, eBay, … to grow so quickly. They all started with a classic Monolithic architecture and quickly realized that the Microservices way was better.

Since the big companies mentioned earlier also had virtually unlimited capital available, they were able to set themselves apart from the competition very quickly and thus set new standards – especially in terms of customer experience. Classical, medium-sized companies may still have the chance to create a one-time digital product that meets the current requirements of their customers. But with a Monolithic architecture they have no chance to keep up with the current speed of change. New devices (smartphones, TV, voice, …) are always coming into the market and the big players are setting new standards in terms of user guidance, services and usability too quickly.

Of course, small and medium-sized companies don’t have the power to build their Microservices-based IT completely on their own, as the companies mentioned above have done. But fortunately, more and more of the established vendors are opting for API-first and new vendors are entering the market as “headless” or “API-native”.


To graphically express the possibility of growth of a Monolithic architecture: The curve rises very steeply at first, i.e. the ratio of capital employed to benefits achieved is very good. But the larger and more extensive the project becomes, the more the curve flattens. Everybody knows that small projects are often incredibly efficient. With large projects, one is astonished that even a doubling of personnel costs leads to hardly any noticeable increased output.

If we now transfer these graphs to the Microservices, the curve is not so steep at the beginning, but the small projects or Microservices don’t reach the size at which the curve flattens. The reason why the curve isn’t so steep at the beginning is that Microservices require a significant overhead for abstraction or for the creation of defined standard interfaces. Overall, however, the individual Microservices achieve a significantly better cost-benefit ratio for the same total effort and are practically unlimited in their scaling.

End to End Microservices

All areas of customer-oriented digital communication can now be easily implemented in this way. All areas? No, one essential area has been left out so far: the digital frontend, the digital shop window, the shop counter, the interface to the customer.

Up until two years ago, companies only had the option of building their own custom-made products or having them built by a service provider. And not only that, each company also had to take care of the operation individually. While the other services were simply consumed as cloud services, this crucial part remained the classic bottleneck.

It’s no coincidence that manufacturers hadn’t offered exactly this part for a long time: offering an API-oriented cloud service that’s both generic and customizable is no trivial undertaking.

In 2018, Frontastic came out with the new genre Frontend-as-a-Service, providing the last necessary part that companies need to keep up with the big players or simply to be able to adapt their offering more quickly.

Frontend-as-a-Service in a Nutshell

How “Frontend-as-a-Service” (FaaS) or “Frontend Management Platform” (FMP) works is easy to explain: all information necessary for the customer experience is available via APIs. They’re linked to generic or individual frontend components (building blocks) and the business team can easily build new business models – just like with a homepage builder – and make them available to customers or partners. What’s known today from the classic (consumer) world with WordPress, wix, Shopify etc. is now also available for the modern API-based world.

The Frontend Management Platform is also structured in a service-oriented manner: this allows the business team to work largely independently of the design team and the design team to work largely independently of the development and integration team. In this way, new features and business ideas can be brought to the customer with maximum speed and minimum dependencies.

However, a service-oriented architecture not only offers advantages over the Monolith in terms of dynamics: due to the open architecture, individual components can be exchanged much more easily. For the customer experience, this can mean, for example, that the eCommerce system, the search or even just the recommendation can be exchanged without changing the user guidance or the interface.

But as I said, if you have an existing, lucrative business and just want to administer it easily and efficiently: then choose the Monolith. The advantage here – for the sake of completeness – is that you get everything from one source and usually only have one central interface for managing all components.

In the End

Even with providers like Shopify you can scale your business very well. And – to stay with the example – Shopify also has an API. This allows you to connect individual services but also individual frontends like Frontastic.

Henning Emmrich

Henning is a Software Expert with strong enterprise skills. He’s worked in many management positions like Product Management, Marketing, Business Development and Digitalization. He’s one of the Co-Founders of Frontastic and works as Integrator and COO.

Stay In The Loop

Subscribe to our newsletter to keep up to date on all the latest Frontastic news.