From Monolith to Microservice architecture

The way we are building systems has changed in the past 10 years. Systems are increasingly complex, to the point that having one system that does it all is no longer sustainable. The industry has moved from Monolith to Microservice architectures, in order to improve speed, scalability and reliability.

Netflix is the one of the main driver of this change in the industry. In 2009 Netflix platform was a Monolith, today its platform is powered by more than 1000 microservices.

The Monolith

Monolith are system built as single unit. Even though the system can be logically modularized, user interface, business logic and data access are built, packaged and deployed as a single unit.

Monolith have the advantage to be simpler to develop and deploy at the beginning. But overtime, monolith grows as new functionalities are added; and it becomes increasingly difficult to keep a good modular structure and manage the complexity of the system:

• Any simple change or bug fix would require the deployment of the whole system.
• Much harder to understand impact of changes. Ex: In a Bus Ticketing System built as monolith, a change in Order module cause bugs on Ticketing module
• Hard to adopt new technologies, a change of framework or language would require a rewrite of the whole system
• Startup time increases as the system grows

Microservice

Microservice architecture favour breaking systems in smaller services build and deployed independently, communicating over network (usually using REST API). The scope of every service is limited to only one business capability, so each service does only one thing!

For example, the Bus Ticketing System backend can be composed of

• Search Service for searching available bus tickets
• Order Service for placing customers orders
• Ticket Service for creating electronic tickets
• Delivery Service for sending the electronic tickets to customer via SMS

Advantages of Microservice Architecture

1. It addresses the complexity by breaking the problem is smaller manageable problems. Each microservice solving one and only one problem.
2. Microservices can be built independently by different teams. Instead of having 10 developers all working on the same codebase, you can have 2 teams of 5 developers, each team owning 1 to 2 services.
   
3. It reduces the barrier of entry for new technologies. You have your services build in PHP and want to adopt Java? You can start by rewriting only the Delivery Service to Java! As long as you don't maintain the communication contract (REST API), the other PHP services will not be impacted. 
4. It enables each microservice to be re-deployed independently. You have a bug on Delivery Service, you only have to change that service and re-deploy it. No need to re-deploy the other services.
5. It enables each service to scale independently. For example, in the bus ticketing system, for every 100 searches, only 2 orders are placed. This mean that you'll have more traffic on the Search Service, compared to Order Service. So you could provision 3 servers for Search, but only 1 or Order.
   Because the scope of each microservice is smaller, you can also provision them with much smaller server instances. 

Challenges of Microservice Architecture

1. Microservices architecture inherit the complexity of distributed system. Because the communication between the different component of your system are network based, it could lead to latency and network related issues.
2. Testing microservices is more difficult than on monolith. You have to use technics like Stubbing or Mocking to simulate the communication between the different services. 
3. Coordination of transactions span between multiple services is more complex. In a monolith, you can rely on the database with a BEGIN TRANSACTION and END TRANSACTION block to guarantee the consistency of your data. In Microservice architecture, because the data are spread across different services (and databases), developers have to code the orchestration of the transaction.
4.  Operational complexity is higher, since you have to monitor multiple microservices, each of them being a potential point of failure.

Building system is complex by nature. Monolith Architecture are more suitable for simple and lightweight applications. Microservice architecture suit better for more complex, evolving applications despite the drawbacks and implementation challenges.  IMHO, microservice architecture enable faster and more autonomous teams, which compensate the drawbacks inherited from distributed applications.

The fact that companies like Amazon, Netflix, Facebook have fully embraced the microservice architecture is a testimonial that this architecture is here to stay!