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 programming languages. But mind, that multi-technology software is harder to keep consistent, as Martin Fowler points out.
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 to break the whole thing. If one service fails, this doesn’t cause the entire system to fail. On the other hand, having multiple services increases effort and costs of maintenance, as interdependencies that exist between services must be closely monitored.
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 a huge organizational effort – all the more if they are built on different programming languages. Mind Conway’s Conway’s law.
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 turn, it increases the complexity of the programming, though. Given time, microservices can easily amass significant overhead.
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, monolithic applications are built as a single, consistent unit. This unit holds the whole core functionality of the application. All its singular components use the same code foundation, the same memory, and other system resources.
Aspects of Monolithic Architectures
As Sinclair Schuller rightly points 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 application. As such, they are easier to plan and design than microservices, which can require some “back and forth” between the teams of several services. It’s true that deployment of single features can proceed quicker in microservice infrastructures. But getting a project ready in the first place often takes more planning time. And thus, it’s more expensive.
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 simplifies testing and debugging the application.
If planned and implemented properly, monoliths can benefit in performance. It’s simply because monoliths have less overhead and thus fewer systems that could increase latency. This boosts performance for some application when compared to microservices. But scalability eventually might become a challenge.
It Stands and Falls With Communication
Monolithic 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 a short time and with a clear, comprehensive code foundation.
Monoliths? Microservices? The Best of Both Worlds!
Monolithic and microservice architectures aren’t as mutually exclusive as the paragraphs above suggest.
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 systems: 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 are based on monolithic architecture, but we also offer software development services. If you want to learn more, shoot us an email at email@example.com.