Monolithic and Microservices

Do not miss this exclusive book on Binary Tree Problems. Get it now for free.

If you have been doing some cool projects or were working in an organization which is large in size, microservices would be up your sleeves. To the college grads and enthusiasts, In today's article in OpenGenus, we would go indepths of monolithic architecture and microservices architecture.

Software Architecture:

Very vague term used in the software industry, it's related to the design decisions of the system. It deals with implementation details, implementation design decisions, tech stack, system design, infrastructure decisions. There could be several possibilities in each and every step.

Client-Server Architecture:

Whenever we are building any application we essentially divide it into two parts, the one which is a client and the other is a server. The client is the entity which requests a resource or service to the server. The server provides the resource or service. Clients are normally the front end facing applications built for web or mobile although it could also be for other platforms, they are also programs. The server is an application/ program which runs on a port in a computer. Every computer has an IP address and an application listens on a particular port for requests if it's a server. The IP address with the port number is collectively called a socker address. Newbies make a mistake of assuming server as a large machine, although it might be true anything that gives a resource to a client is a server.

How do client and server communicate?

They communicate through API's which is the intermediary between them. It's set of rules with which one communicates with the other. Rules are necessary because server should understand what client is requesting for and the other way around.

Now that we understand basics of how an application can be created, we'll see about monolithic architecture.

Monolithic architecture:

Whenever you see an application created for a college project who have not studied software engineering as a subject or had not dealt with potentially thousands of lines of code, for them monolithic architecture would seem the way to go. Let's understand it using an example.

Let's say an application has different components like login, streaming, order and logout components and the code for everything is coupled into one server which on the request of the user responds. There could be different clients like mobile, web.
The above could be represented as follows.

Drawbacks:

Single point of failure: Because the components of the system are tightely coupled and the cohesion is not followed if the codebase has dependent entities. Failure in one component would largely affect the system entirely.
Scalability: Since all the components are tightely coupled we need to scale horizontally the entire application than the component which is requiring extra resources. This is a costly affair.
Deployment: Because the entire codebase needs to be revamped the deployment of the application is lesser compared to that of microservices but the rate at which the errors might occur would mean that cost would be more which fixing and redeploying. The deployment could take a lot of time, in present day and age being fast is the way to get ahead.
Complex: Since everything is dependent and connected for an intern or a new joiner it would be hard to study the codebase and perform tasks.
Limits: If an organization is planning on making changes or adding new components a small bug would make the entire application crash.

Who used it?

Almost all the companies were once startups and every system that is designed is made for a particular purpose. Once a company starts to get attention, they need to make changes to their design accordingly otherwise the fame that was acquired dies down. Netflix, Amazon, Uber and many more have started with the monolithic architecture. Initially the codebases are designed to raise funds and users of a product. This starts to get complex as we already discussed in the disadvantages. The scalability of an application comes into the picture as load on a component increases. There is a migration phase for almost every startup. If a startup is lucky enough to have a seed fund which can handle infrastructure costs of deployable services then they go for microservices.

Microservices:

To make sure we have less coupling and more cohesion, we opt for microservice architecture. In this every component is treated as a seperate entity and they are deployed independently. Because of that, we are levied of a lot of drawback which might occur due to monolithic architecture. Every component in the application is called a service in microservice architecture. For intercommunication between the deployed services, we create API's. There is no hard requirements for an application to be considered part of micro service architecture, it all depends on how the application is created.

we intentionally didn't add a messaging broker as it becomes complex for beginners to grasp, but it is essential in building good microservice based applications for smooth communication between the services

Advantages:

Fault tolerance: Since every single component or service of the application is deployed independently, working on bugs and fixing in realtime would be easy than affecting user experience by bringing the entire system down to fix one part.
Scalability: The heavily used services can be scaled horizontally if it's attracting a lot of traffic, this could not be done in monolithic architecture as we need scale an entire application. Since the demand is not the same for the other resources we might be wasting computing resources and increasing cost.
Easy to understand: Although the systems built using microservices could be complex, each and every individual entity in it are easy to understand and deal with. A new intern could probably understand it in no time and productivity of the organization would increase.
Deployment: Incase of this, we might deploy more services but it could be better if it's pulling huge traffic at once.
Scope for experimentation: Since the services are loosely coupled, we can work on new components and add it to the existing code base independently without disturbing the integrity of the system.

Disadvantages:

Overall Complexity: Since the application has been divided into small parts, taking a bird's view might make us terrified if an organization is dealing with many services in their application.
Communication: Independent entities need to communicate with each other and there could be dependency of one over the other and hence a lot of APIs have to written to make different parts communicate.
Transactional Failure: If a request falls apart in one of the co-dependent entities then in this architecture we need to use different distributed transaction related patterns to handle it.

Who are using it?

Think of all the big multinational companies which needs to cater to different set of audience in different geographical locations. Netflix was one of the primary adopters of microservice architecture, this was due to the incident at a data center which made, then, a DVD rental company to shut it's operations for three days. This brought some major decisions for them, they decoupled the connected components and removed single point failure. This change brought in the capacity for Netflix to handle mutiple components independently and solve issues. Spotify handles traffic by scaling components independently and this help them to isolate issues and work on them when needed. This is the primary reason why many opted for this architecture.

Although there are no rules saying which architecture to choose, many are migrating to the microservice architecture due to the ease at which operations are going. Amazon is being funny and moving to monolithic architecture and reported a decrease in costs by 90% (we don't know the full picture yet!). So, everything is dependent on the usecase and the organization handling it. The next time you build an application think of these.

Contents: