For the last few years, we have seen a massive increase in the usage of microservice architecture, along with the traditional way of developing systems, i.e. monolithic architecture.

The essential questions here are:
How does it affect the way we think about building software?
Why would we need a new architecture?
and many more...

Let's find out why tech giants like Netflix, Google and Amazon have moved to the microservice architecture and what are the use cases of monolithic architecture? 

Monolith:
Monolithic systems are large blocks of code that have multiple business functions inside a single execution context or a process. The modules are tightly coupled to each other. The Architecture mainly has three components: the UI, the business logic and the database. The application and business logic reside in a single system. This makes the systems complex as they evolve.

Microservice:
Microservice is designing software applications as suites of independently deployable services. We can even have different technologies for different microservices based on what functionality we are building. Ideally, each business logic is handled by each microservice. And each microservice mainly communicates via API calls over or HTTP/ HTTPS.

Communication within the microservice architecture can happen via API calls over HTTP/HTTPS. Still, communication between different microservices can happen in two different ways.

Synchronous Communication:
When a request is made to an endpoint under HTTP, the caller is locked in the interaction until received.
The caller might receive the response in a mere millisecond or a few seconds. Regardless of the application latency, the caller cannot move forward to the next task until received. Thus, REST is an excellent example of a synchronous microservice.

Asynchronous Communication:
An asynchronous microservice is a request to a service, and the subsequent response occurring independently from each other. The general practice for implementing an asynchronous microservice is to use a message broker technology, such as Kafka or RabbitMQ, to act as a go-between for services. The intended service receives the message in its own time. The sending service is not locked to the broker.

Monolithic architecture Pros:
Effective development and deployment: A single chunk of code needs to be deployed; making changes in one code base is more accessible.
Performance: Since the memory and code are centralized, one API call can serve when the screens are loaded rather than calling different APIs in different microservices.


Monolithic architecture Cons:
1. Tight coupling: Several modules are tightly coupled, making the individual differential scalability of each module a challenge in a monolithic architecture.
2. The slow build and continuous deployment: Since the code base is heavy, the build takes time. Also, the extensive system takes a lot of time to deploy, making continuous deployment a challenge.
3. Inefficient testing: Since one change in the system can affect multiple places, regression testing becomes necessary and challenging. Due to one change, the entire system needs to be tested to assure nothing breaks.


Microservice Architecture Pros:
1. Increased Agility.
Since the whole system is divided into microservices, it is easier to manage the code, and any change request development is sped up.

2. Increase scalability and Better Organization.
Since the microservices are divided into multiple services, each microservice can scale upon its level. In addition, the codebase is also managed well.


Choosing appropriate architecture for the system:
Small-sized team: A monolithic architecture would be better if the team size is small because designing so many microservices will consume time and resources.
Simple applications: An application with no business logic and complex structures can go for monolithic architecture.
Right skill set: If the team doesn't have the skillset for building microservices, it will be better to go with a monolithic architecture.
Faster launch: If you want to launch your system quickly, it will be easier with just business rules validation.

Choosing a microservices architecture
Microservices expertise: A team with a proper skill set on the architectural level and having proper DevOps skills to manage the microservice can go with microservice architecture.
A scalable and complex system: If there are many modules in the system and the complexity is high, it's better to go with microservice architecture. Since then, the design of the system would be better and easily scalable.
The team should be big enough to build these microservices, which does not delay the development process.
High throughput systems whose workload keeps fluctuating over time.


Understanding Architecture through the system learnings
Suppose we build an airline reservation system considering the large user base with almost 1 lakh transactions per day. In this case, we may require the system to be scalable enough and fault-tolerant so that if any service fails, the downtime period of the system should not be impacted. Also, we have a large team knowing microservices and other technologies supporting microservices. Therefore, resource availability is not an issue, and it can scale enough. The cost factor is considered.

In case of such a requirement, we will make the system architecture in a microservice model, where we will be having different services for each business function. For example, one service could manage to search for flights by different users, while the other handles the booking, cancellation and rescheduling of the tickets. Another benefit could be the communication that is sent out to the end-users.

Considering such an extensive system, latency could be an issue. But the microservice facing resource management issues can be scaled, keeping other systems unchanged, making the overall system more robust.

Opposed to that, considering an application that is just used for internal purposes like a snack ordering system, where the system user base is not that large, and the team is not that skilled enough to manage microservices, downtime is not an issue since the application does not have a 100% uptime requirement. Here, we will be going with monolith systems to integrate all the business processes in one system itself.


When the tradeoff doesn’t make you decide, consider your organizational structure. Having many teams on one product, microservices would be a good fit. On the other hand, a team of few developers is better suited for monolithic architecture.
Other factors to be considered are the agility and complexity of the project. A fast-paced project with complex business logic fits in well with the microservice concept.
But if you are unfamiliar with technologies that build microservices, consider monolithic architecture with a modular structure. When your solution grows, a modular structure will help us in achieving the transition to microservices.

About Neebal:

Neebal, a technology solutions provider, has delivered top of the line solutions across Agro, Pharma, and BFSI verticals. Neebal aims to provide top tier services for API Integration, RPA, and advanced mobility with prime focus on Hyperautomation. Founded in 2010, Neebal is a proud recipient of the Deloitte Technology Fast 500 Award (APAC) and the Deloitte Fast 50 Award (India) for four consecutive years (2017-20).