Which Architecture Fits Your Business Best?
It’s a question no company hosting their own app or software program can avoid: Microservices or monoliths? Which system architecture shall it be?
Skimming through the world wide web of tech talk, you might notice a distinct tendency: The Monolith seems to have fallen out of favor in behalf of microservice SOAs. But there are counter voices, too. They point out that microservice architecture comes with its own set of problems.
But what are the specific advantages and disadvantages of microservices and monoliths? First and foremost it’s all…
A Question of Perspective
Which system architecture will prove best for a given software is very much a matter of probing the battlefield. When thinking about the ideal approach for your project, you should mind the following questions:
- What are the core functionalities of your product? Do you want a straightforward application with a strong focus or have you already planned to add more and more functionalities as you go along?
- How big is your development team? And how streamlined is the communication flow between your team members?
- What does your system infrastructure look like already? Did you already decide on a system infrastructure and want to migrate on another one? Why?
How you answer these questions will give you an idea which architecture, microservices or monoliths, might work better for your company. In the end, it all comes down to the division between centralized and autonomous. It’s time for a comparison.
The Microservice Multiplex
Flexibility through autonomy: It’s what microservice architectures strive to achieve
Aspects of Microservice Architectures
Small, Individual Building Blocks
Every service runs its own processes on its own code base. When working together those singular building blocks form the whole of the application. That means development teams can modify, extend and deploy each service independently. They can even base each microservice on very different technologies and program languages. But mind, that multi-technology software is harder to keep consistent, as Martin
In microservice environments, there are few hard dependencies among teams. Development processes are decoupled. Coding teams can work on their specific features without stepping on each other’s toes. It’s also easier to update the system to the newest technology, as this can be done one part at a time.
Microservices easily scale horizontally, as they scale independently from each other. Thus, they can cope with high traffic. Services that reach the end of their capacities can be updated without touching the rest of the system. This allows for continuous delivery of features.
Coding teams can tackle different features of an application simultaneously. While doing so, they don’t have to fear
The Practicality Question
As corporations like Google or Netflix settled for microservice frameworks, many small companies do the same. But not all business models are suited for microservices. The microservice approach works best when backed by big, specialized teams. Keeping a multitude of microservices consistent is
Smaller Is Not Faster
It’s not trivial to build up a distributed system in a fashion, that the singular services don’t slow down the whole. Every service is connected through remote calls. Such calls take time, especially when many services are called in at once. Increasing the granularity of the calls can somewhat alleviate the problem. In
Microservices? Yes, if …
… your company wants to release a complex product, based on a variety of program languages. Microservice SOAs are also preferable, if the software’s features shall scale individually. Before inviting the complexity of a microservice framework, ask yourself how much decoupling your application will need. A straightforward app with clear, linear features doesn’t necessarily require a fractured architecture.
The Mighty Monolith
In contrast to microservices, monoliths
Aspects of Monolithic Architectures
As Sinclair Schullerrightly point out, many applications are reliant on a large number of cross-cutting concerns, be it audit trails, logging or similar processes. Monoliths have an easier time incorporating such recurring concerns, as everything shares one code basis.
Monoliths are basically one giant, linear
Less Compatibility Issues
In a monolithic system every line of code stands on the same foundation. Thus, compatibility can be determined easier as in cases, where the app consists of several services using different technologies. Furthermore, the unified nature of the code
Big and Speedy
If constructed properly, monoliths are often more performant than microservices. Shared memory and code allow faster communication between components of the software. On the other hand, microservice environments are only as fast as the communication of their processes allows.
It Stands and Falls With Communication
Monolitic architectures work best if maintained by small teams. Changing any part of the system requires updating the monolith as a whole, so team members plan their deploys in conclusion. Microservices can also suffer from bad communication — especially when the updated services are communicating with other services often. But it’s easier to spot obstacles and bottlenecks there.
Monoliths? Sure, but …
… mind scalability and team setup. A monolith has advantages for companies and startups consisting of small teams. It allows them to get their initial product released in short time and with a clear, comprehensive code foundation.
Monoliths? Microservices? The Best of Both Worlds!
Monoliths and microservices aren’t as mutually exclusive as the paragraphs above
It is perfectly possible to arrange a pool of microservices around a single, monolithic core application. The monolith runs the main business logic, while its subservices scale independently and can be deployed without changing the monolith’s code foundation.
Small companies and startups benefit from this approach. Building up their central product as a monolith will enable them to release it with short time to market. The micro-subservices add to this. They give opportunities to expand the monolith while avoiding dependencies. However, keep the microservices small enough to quickly communicate with the monolith. Otherwise you are giving away the performative edge gained by using a monolithic core.
For balancr and its sister products, we’ve decided to settle for the monolithic approach, as it fits our workflow and the layout of the software better. We are convinced by the advantages of monolithic SOAs: While monoliths have their disadvantages, they are also more reliable and easier to handle for us and for the startups and companies we’ve entered partnerships with. And as we have seen, monoliths and microservices can complement one another as the software grows.
Our products base on the monolithic architecture, but we also offer software development services. If you want to learn more, shot us an email at email@example.com.
Images © balancr GmbH, Cologne