Micro Vs Macro Vs Mono

Microservices are going to be the de facto way of building applications. If you are thinking of coming up with hundreds of microservices, I suggest you read this blog to understand why you should not go with the microservices approach every time. What is the better way to migrate your legacy monolith applications to microservices?

What is Monolith Application?

A monolithic application comprises all of the business functionalities in as one unit. Technically, it can contain UI, business, and persistent layers in one place. It is built on a platform that may be with or without functional modularity. That includes all the practical steps needed to execute a particular business task.

What is Microservice?

A microservice is a single lightweight process that is focused on doing one thing precisely. Interaction with microservice is done using technology-agnostic protocols like HTTP. It can independently be deployed and scaled based on the demand for that functionality.

Is Monolith Bad?

Monolith was never an issue with enterprises. For some time, It has become a way of application development. In fact, it is the only way we could able to enable business value.

Monolith Hotel Application

Service-Oriented Architecture (SOA) comes to existence and basically introduced separation of one single significant functionality in small functionalities and interacted using SOAP or Rest.

Even though SOA addressed many challenges that monolith applications have. The composition of small steps bundled in as a significant function (also in SOA) on a platform lead to few complications.

Let's consider, Hotel management software built as a monolith application. The application is built over the years and a lot of code is unorganized. This application contains 6 functionalities tied in.

Here are few complications with Monolithic applications

1. The codebase is for all the steps for all the functions that will be in one place. The result of this is that even if you want to enhance a step, You have to carefully ensure there is no impact with other steps and functionalities. The overall testing effort even for small change is enormous.
2. Chained impact: If you have a bug in a step and you happen to find it in production and needs to be addressed asap. Now what? You have to bring down the entire application, which means you have brought other functionalities down as well, even though they are not impacted.
3. Building an application takes minutes. Some times hours depend on no. of functionalities involved and dependencies on other features.
4. Enhancing or adapting to the latest technologies is very difficult Since the impact of enhancement has to be assessed for every function.
5. Scaling is a significant issue. Where you utilize full CPU or not, you have to ensure full capacity is allocated to your application.
6. Bring application up might take minutes, some cases even hours.

Microservices

Microservices addressed the above challenges. That is the crucial reason why microservices has become so popular. Let’s see the benefits of the microservice.

1. Single process application that carries steps of a functionality. At times a step itself is exposed as a function.
2. Faster build and application start up time.
3. A microservice can be containerized, this helps in scale up or down.
4. Upgrading the technologies or functionalities is simple and can be down independent of other microservices.

Hotel management system can be separated as 6 Microservices.

Is it all good news with Microservices?

The answer is “NO”. Imagine you have team decided to take your product to market faster and the best way to do it is by developing hundreds of small functionalities. You might be successful in going to the market. But are you going to be successful in maintaining that many services? Communication between microservice might hit overall performance.

Designing microservices should be handled with a lot of foresight? This will save you from ending up in a hail of microservices. Now if you have a requirement and not aware of all microservices functionality will lead to adding duplicate services.

The benefits of using microservices precede building a monolith application. By taking careful design decisions, we don’t have to fall deep into a mesh of microservices, Unless you are Netflix.

Monolith is not good and Microservices have issues, Then what is the other solution.

What is Macroservice?

Macroservices

Macroservice is in between Monolith and Microservices. Macroservice will have benefits of Microservice and avoid Monolithic applications shortfalls.

Hotel Management system is divided into microservice and an application with multiple modules. UI can be designed as Microservice as changes can be independent, very frequent and all the other functionalities are separated as modules and bundled into an application.

These are the characteristics I define for Macroservice.

1. Every function with its steps is configured in a module within Macroservice.
2. Macroservice can have many functions (Modules) within.
3. Macroservice modules are tightly coupled with the capability of loosely coupled with minimum effort.
4. Every module should have its own entry point (Rest service)
5. A module within microservice should be able to depend on another module as long as it can be converted to Rest service.

This does sound like a monolith application with modules. Maybe, it is. But this can address shortfalls of monolith applications.

1. Each module (functionality) can be separated from Macroservice as needed.
2. You can use Blue-Green deployment to overcome issues related to production.
3. Upgrading with new libraries (tech) should not be an issue. Since they are confined to a particular library.

Approach to migrate monolith application to microservices:

If you are tasked to migrate a legacy application to microservices. It will be challenging due to the code that is accumulated over the years. There could be dead code that might blow your understanding so far.

Before determining what microservices and count, I prefer the following approach.

Migrate Monolith application to Macroservices and then convert each Macroservice to microservice, based on demand for functionality.

Each application is unique. Few might need to migrate to microservices, few might not need to be migrated at all. Migrate to Macroservice is an option that needs to be considered.