Article Banner Image

Monolith Vs Microservices

In recent years the application development process has been shifted from monolith to microservice architecture. Each architecture has its own pros and cons in the real world. To understand the pros and cons, we first need to understand about the architecture itself.  

 

  • What is monolith?  

Monolith is the standard way of developing applications. The name monolith comes from mono which means one basic unit in biological terms. Now if you put it in technological terms, monolith applications have one single codebase. All the functionalities of a project exist in that single codebase. The application is designed in various layers like presentation, service and persistence and later deployed as a single file. If monolith services were doing their job, what led us to start developing in microservices? 

 

  • Advantages of Monolith Application: 
  1. Simple to develop relative to microservices.  
  2. Easy to deploy. 
  3. The security and network latency problems are less.  
  4. Fewer resources are needed to develop. 

 

  • Disadvantages of Monolith Applications: 

  1. Difficult to manage as it increases with time. 

  2. If a small change is made, whole application needs to be redeployed. 

  3. If the size of the application increases, the start-up and deployment time will also be increased. 

  4. Horizontal scaling is not feasible. 

  5. Difficult to understand the logic of large applications. 

  6. A single bug in any program section can bring the application down.  

  7. Application is developed in one framework because of this some functionalities can be compromised.

 

  • What are microservices? 

If monolith is developing every module in a project, in microservices the same project can be divided into different services. A service can be developed and deployed independently. A service also has its own database, due to this reason some data may be duplicated across various services. A developer has his/her option to choose a particular database for a particular service. Services communicate with each other using synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP.  

 

  •  Microservices are built around three main principles:  
  1. Single responsibility: This principle is a part of the SOLID design pattern. It states that a microservice should only have one responsibility and provide single functionality. The number of functionalities a developer requires is as same as the number of services. 

  2. Built with business capabilities: A particular technology can be best suited for implementing a particular functionality. In microservices, as each service is independent of the other a developer can choose to implement various technologies to build a single application. A developer will never be restricted to using an appropriate stack or a backend database which is more suitable for business requirements. 

  3. Design for failure: If a microservice is down it should not affect the entire application. The other services must be available to the user.  All the services must be built with failure in mind.

 

  • Microservice patterns 

                    1. Decomposition patterns: 

  • Decompose by business capability: 

To build a service related to business capability. A business capability is something that a business does in order to generate value e.g. 

  1. Exam service is responsible for exams  

  1. Member service is responsible for members 

 

 

  • Decompose by subdomain:   

The services are related to Domain-Driven Design (DDD) subdomains. The application is the domain in this pattern. A domain and each domain will have different subdomains. These subdomains will have a particular service with a given functionality. 

The subdomains of our application will be 

  1. Exam management  

  2. Member management 

 

        2. Database per Service pattern: 

 To keep the data private to its own service, each service must have its own database.The data is   only accessible via API.

       

 

 

 

        3. API Gateway pattern:  

API gateway is the only point of entry for a microservice call. It can work as a proxy service to route a request to the desired microservice. An API gateway may also handle security issues        like verifying whether the client is authorized to perform the request or not.

 

 

  • The Client-Side Discovery and Server-Side Discovery 

  • The Client-Side Discovery:  

The client does most of the work in this discovery. Example of a man ordering a pizza from a pizza store.  

  1. He needs to call a pizza store  
  2. He searches pizza stores near him. (Google) 
  3. He gets the information about the pizza store and makes an order.In the microservices context client is also a microservice which looks up in the service registry to identify the location of the service needed and later makes the actual request to the service needed itself. This is client-side discovery. 

 

 

  • Server-Side Discovery:  

The server does most of the work in this discovery. The client service sends a request, the service registry transports the request to the service it wants to use. The advantages of this model are that the client doesn’t need to make multiple requests. The disadvantage is that the server-side component needs to be running all the time.  

  1. The Single Service per Host: Deploy each service on its own host.  

  2. Multiple Services per Host: Deploy many services on a single host. 

  3. Circuit Breaker: Helps to prevent a network or service failure from damaging other services. 

 

 

  • Advantages of microservices 

    1. Easy to manage as it is smaller in size. 

    2. No need to redeploy whole application, you can only redeploy a single service 

    3. Easy to understand the functionalities implemented in a particular service 

    4. Easily scalable Each service can be built with different technology.  

    5. If a service goes down, the other services and their functionalities are still available to the users.  

 

  • Disadvantages of Microservices 

    1. More complex than monolith applications. 
    2. Communication between two services is complicated.  
    3. Writing queries that retrieve data from multiple services.  
    4. Inter-service communication can lead to security risks.  

 

  • Real case scenarios 

Big companies like Netflix, Amazon and eBay have moved from a monolith architecture to microservice architecture.  Here below is a list of articles to get to know more about their experiences about using microservices. 

  1. Uber: https://eng.uber.com/service-oriented-architecture/ 
  2. Netflix:https://netflixtechblog.com/netflix-conductor-a-microservices-orchestrator-2e8d4771bf4
  3. Amazon:  http://highscalability.com/amazon-architecture 
  4. Zalando: https://www.infoq.com/news/2016/02/Monolith-Microservices-Zalando/ 
  5. Sound Cloud: https://developers.soundcloud.com/blog/building-products-at-soundcloud-part-2-breaking-the-monolith
  6. Comcast Cable: https://qconnewyork.com/ny2015/ny2015/presentation/partial-failures-microservices-jungle-survival-tips-comcast.html 

 

To conclude, adopting a microservices architecture may not be a suitable approach in all circumstances. A monolith has its own pros and has long-lasting advantages which work better for many use cases. 

 

If you're new to the market and you want to test & validate your solution, you should start with a monolith. With a small development team aiming to develop a simple and lightweight application, there is no need to implement microservices. This way, a monolithic application will be much more cost effective, easier to build, make changes, deploy, and provide testing.

 

Microservices architecture is more beneficial for complex, evolving applications & for enterprise level of applications. It offers effective solutions for handling a complicated system of different functions and services within one application. Microservices are ideal when it comes to the platforms covering many user journeys and workflows. It would be a RedFlag to go ahead with this approach if you lack expertise. 

 

If your development team does not have any of this expertise, you can get in touch with us, we would consult & be a software development partner of yours having hands-on experience in building a monolith or microservices architecture which fits your needs. 

RELATED ARTICLES

POPULAR ARTICLES