Making a decision on what type of platform a developer should design is one of the longest-standing debates within the world of programming. The endless battle between monolithic and microservices architectures is -in truth- a harmonized “dance” between these two architecture concepts, which de facto we cannot compare to each other since they offer quite different perspectives on the same subject.

To better understand why a debate is in place, it is important to explain each architecture. Below we will see what monolithic and microservices architectures have to offer. After all, it is a matter of what you want to offer to prospective clients.

Monolithic approach

Just by name one can understand much about the monolithic architecture. Monoliths are single slabs of stone upon which the first humans used to write and draw. They also used them as markers for places of great importance. When it comes to the monolithic approach, it is essentially a packaged application that contains all of the components within the same environment. The inner workings of a monolith are hard to see and are not transparent. Therefore, if a developer is not familiar enough with a platform, they might need some time and quite some effort to find code they need to adjust. As stated above, everything in monolithic architecture is connected into one piece. Also, developers make it with the same programming language.

Microservices approach

Anyone can easily understand the concept of microservices architecture if they think about a PC and its peripherals. If one of the peripherals breaks down, the rest will keep working properly. In the microservices architecture, every aspect of the application is built as a separate application, powered by its own server, and works as a stand-alone part of the bigger application. Each service is connected to its own database. A means of communication is used to help them communicate with each other. Each service is a completely separate entity, with its own programming language. The programming language between services need not be the same. They are built on the best language suitable for each service and are then “translated” into the entire service package through the means of communication used for them to communicate with each other.

Why go ‘Monolith’?

Monolithic architecture is an approach that is used widely, and there are several reasons that lead developers to select it to build applications. First and foremost, comes the word “Simplicity”. The monolith approach is simple to develop and simple to deploy. Development requires a tight code that includes all services offered within the architecture. Deploying the monolithic architecture is as simple as “copy and paste”. This is exactly what it is done for deployment: the developer copies the app and pastes it to a server.

Also, the monolith approach is usually created by small teams, since it does not require dedicated teams for each separate service/entity. It is less complex and is written in the same programming language. A good example of a client who would use a monolithic approach for their application is a company that wants an application for its e-shop, not planning to expand to other types of services in the future.

What about ‘Monolith’ drawbacks?

An architecture without drawbacks is a utopia. The monolithic approach has some drawbacks, which should be taken into consideration. “Domino effect” is the main word in this case, and we elaborate. Making a single change on any part of an application with a monolithic architecture will have an immediate impact on all other parts of it. Since they are all interwoven, any change has to be done for all aspects. In addition, the simple approach might limit the size and complexity of the application built. Testing can become a hectic process, especially when monoliths are used for big projects. Furthermore, the size can slow down start-up time, while each update will lead to the re-deployment of the entire application. New developers entering the team will need to have much more context in order to understand the system than with microservices. Finally, the monolith architecture can be expensive in both time and cost.

Why go ‘Microservices’?

On the other hand, microservices architecture works better for those who want multi-tasking to be an integral part of their application. The most important word in the case of microservices architecture is “Independency”. Each service is an independent entity and therefore these services do not depend on each other. They allow the scale-up of individual components, instead of the entire app. For example, developers can update the Search Bar of an eCommerce website app built with microservices architecture separately. The Cashier service will remain operating and untouched.

The microservices architecture allows a new developer who joins the team to focus on a specific service, without having to read the entire code. Each service/entity can be written in a different programming language since they use a means of communication chosen by the developer to help them communicate with each other. Finally, each service in the microservices approach can be developed and deployed independently. Also, it can be tested separately, which makes testing easier than in the case of monolithic approach.

Is ‘Microservices’ all… paradise?

Since the beginning of this article, we have reiterated that Monolith and Microservices are not in a battle with each other. Each one finds its own application on client needs. The developer decides which one will work better case-by-case. It is obvious that the microservices approach has its own drawbacks, with complex deployment being the one that stands out. Since each service within the microservices architecture is considered a separate entity,  deployment needs to be very detailed and can be very complex. Moreover, the microservices approach requires really skilled architects. Also, developers cannot make changes that span multiple services. Instead, each service has to be changed separately, which can be good when a bug occurs, but time-consuming when an across-the-board change needs to be made.

How to decide

After analyzing both architectures, we understand that there is no definitive answer to the question “which one to use?”. And this is no paradox since the question does not occur from an ethical matter. These are architectures used to create applications, and therefore are tools. Imagine having a hex screw and a slot drive screw that need to be removed, and you have a hex screwdriver and a slot drive screwdriver. Each screw has its own tool, and likewise, each application type has an architecture that can work better for it than the other.

A good example of a client that can use the monolithic approach is a company with an eCommerce website that will not be expanded greatly. On the other hand, clients who are ever-evolving will probably need a microservices approach implemented. Building complex applications is difficult, and a monolithic architecture suits simple lightweight applications. Complex, ever-evolving applications are better when built with the microservices architecture. Understanding the monolith approach, however, can help developers get an idea of how the microservices architecture works. After all, they are both ways to the same result, using different tools. It is just a matter of how the developer will optimize their approach, keeping in mind the needs of their client.

Tags: Microservices, Microservices architecture, Monolith, Monolithic architecture, Software Development, Technology