Nowadays, big MNCs like Amazon, Google, and Netflix have been using microservices architecture to meet their business needs. In addition, debates about microservices vs. monoliths are unavoidable in the emerging microservices trend.
To understand how microservices are playing a vital role in recent times, let’s understand what monolithic architecture is, and what led us to make a move from monolithic to microservices architecture 🤔
What are microservices?
Microservices are not only feature-based services but also provide particular business functionality. In addition, it is a collection of loosely coupled services that can be independently developed, deployed, and maintained.
In simple words, to solve the complex business problem, each of the services is responsible for assigned tasks & can communicate with each other with a set of simple REST APIs.
Amazon is one of the best examples which migrates to microservices as they get many calls, either from mobile apps, websites, or even from the applications that manage the web service API 🌐 Without microservices, it’s impossible to handle those calls for their old, two-tiered architecture.
The client doesn’t communicate directly to the microservices. It communicates with the API gateway, which communicates with microservices internally. In the figure above, the developer will easily do parallel development and deployment.
Let’s have an example of one of the stakeholders working on feature 1 microservices, and the other working on feature 2 microservices, so they can develop and deploy independently at the same time.
What is monolithic?
Monolithic is a traditional way of designing and building an application. In addition, it comprises of layers i.e. User Interface, Business Logic & Data Interface, and then deploys that codebase as a single file. In monoliths, the server-side and UI logic are all bundled in the jar, war file, etc. The figure below shows a high level of monolithic architecture.
All the functions are managed and served in one place. In addition, it has one large codebase. Let’s take an example: if the developer wants to modify or change the code base, then they have to access the same code base to make changes in the whole stack of code. However, it is very hard to add new features in the future sprints, if the application is too big.
In monolithic, all the clients are connected to a huge machine instead of a single machine. There might be multiple machines that are connected to the databases, and the clients are connected to them respectively, as shown in the figure below. By doing that, we can achieve horizontal scaling even with a monolithic architecture.
From monolithic to microservices architecture
Monolithic architecture is a good choice for small teams and less complex apps, with the benefits of having a single code base with multiple features. But as the additional features are going to be added in the upcoming sprints, it will soon become chaotic and uncontrollable. There are some cons of the monolithic architecture while opting for it, here are a few examples:
- Tightly coupled
- Slow performance
- Slow continuous development
Whereas microservices architecture is one of the architectures that aims to break down the business logic into small suites of services, to handle the large and complex applications. All the microservices communicate with each other by using REST API. This makes their performance better, as the microservice-based applications may get 100 API calls to different services to load the website page 📃
Below are some of the benefits we get:
- Agile and flexible
- Independent development
- Independent deployment
- Mixed technology stack
API gateway in microservices
API gateway is used to build an abstraction layer. In addition, this abstraction layer routes the requests and responses made by anyone outside the microservice system, so there is no need for the front developer to know each and every microservices in the backend. However, it acts as a traffic controller or ROUTER as it forms a single entry point for all your microservices.
With the help of an API gateway, one can do:
- Monitoring of systems (measures how many requests are coming & how long they are taking)
How do we start using an API Gateway?
Either we can create the API gateway on its own and expose the API, or we can use open source API gateway implementation, like the one from the Netflix microservices stack, called Zuul.
In conclusion, we can implement as many API gateways and split the incoming calls using load balancers. Since it’s a single entry point to the whole system, if one of the API gateways goes down, then the other gateways route the incoming call. In the below figures, you see how one can easily implement an API gateway using KONG:
How did big MNCs move towards microservices?
Uber has also started its journey as a startup by using a monolithic architecture with very few features like connecting drivers and riders, billing, and payments. At that time, the application needed to offer only a single city i.e. San Francisco.
When Uber started growing and expanding their business into more cities, adding more features into the app became a real challenge. Their old architecture consists of:
- Connected drivers & passengers with REST API
- 3 different adapters within the APIs were used for billing, payments, emails, and messages
- MySQL as a database
After moving to the microservices architecture style, UBER had the following benefits:
- Scale-up independent services
- Assigned ownership of each module to different stakeholders in a team, which results in boosting speed, quality, and maintainability of new development and deployment
Earlier, Amazon’s retail website acted as a “single monolithic application”. Due to tight coupling, developers got lots of challenges i.e. development delays, coding challenges to upgrade or scale up Amazon’s system. To overcome these problems, Amazon’s service oriented architecture was the beginning of what we can now call microservices.
The productivity started to slow down as developers were working on the same task, again and again, to keep the amazon services up. That’s how the idea of AWS (Amazon Web Services) hit them, which currently sells to many enterprises throughout the world 🌎
Tinder is hosted over the AWS cloud. As of now, it doesn’t have any web application, only an Android and iOs app. It uses AWS amplify to build applications, MongoDB as Database, Redis as caching, and in-memory database.
In the below figure, the client communicates either through web sockets or HTTP long pole to the routing/gateway service and followed by communicating with the microservices.
We come to know that both the architectures are good at their own place, depending on the project requirements. It’s important to consider the team size, flexibility towards development and deployment, etc.
Monolithic might be a good option if we have a small team, and it also allows us to save time in the initial development stages. One might also go for microservices architecture, as it offers more flexibility and the ability to split the task in the development team, for their large/complex applications.
These were some microservices basics, let me know your thoughts and comments 🤗