Problem Statement
Typically, an enterprise application is often built using a three tier architecture:
- Client-side interface
- Server-side application
- Relational database or other persistent storage module
When the client sends a request, the backend code or server-side application processes the same by executing business logic, accessing the database to retrieve data and sends back the html views to the client browser. This server-side application is a monolithic one – single, logical & executable. Any changes to the system involve building and deploying a new version of the server-side application. Even the smallest change requires the entire system to be rebuilt and re-deployed. Below are few more problems with monolithic architecture:
- Tightly Coupled – All modules/features are tightly coupled with each other as it is a single application.
- Language dependency – If we have an application implemented in java, we have to stick to Java for any enhancements to that application.
- Scalability issue – We have multiple applications deployed on one server. If we want to scale one application in that we have to do it for all applications deployed on it.
- Difficulty to have the Root Cause Analysis – If something goes wrong in an application identifying the root cause becomes a daunting task and many a times requires developers to build this into the application to ease post-production analysis
- Performance Management – We have multiple applications deployed on one server. If we have an issue with one application, total server may go down because of it
- Transaction Management – We have to have transaction management implemented in all required applications leading to code redundancy
- Logging, Audit & Metric – similar to Transaction Management, these cross-cutting concerns are implemented inside each application leading to code redundancy. This adds to the implementation, review, testing, and impact analysis effort.
Microservices intends to address the typical issues with the monolithic architecture. Let us see how?
What is Microservices?
Wikipedia defines this nicely:
“Microservices is a specialization of and implementation approach for service-oriented architectures (SOA) used to build flexible, independently deployable software systems. Services in a microservice architecture (MSA) are processes that communicate with each other over a network in order to fulfill a goal. These services use technology-agnostic protocols. The microservices approach is a first realization of SOA that followed the introduction of DevOps and is becoming more popular for building continuously deployed systems”
Introduction
Microservice is a small and independent process which will do its defined job for us.
In other words, Microservices is a way of breaking large software projects into smaller, independent, and loosely coupled modules. Individual modules/services are responsible for highly defined and discrete tasks and communicate with other modules through simple, universally accessible APIs.
Each service can be deployed independent of other services that make it easier to deploy new versions of services, frequently.
With Microservices, it is much easier to scale development. It enables you to organize the development effort around multiple teams. Each team/member is responsible for a service. Each team can develop, deploy and scale their service independent of all of the other members.
Microservices provide high degree of fault isolation. For example, if there is a memory leak in one service then only that service will be affected. The other services will continue to handle requests. In comparison, one misbehaving component of a monolithic architecture can bring down the entire system.
There are several technologies – NodeJS, SpingBoot, Dropwizard, to name a few – using which one can develop microservices.
Details and advantages
- This architectural pattern leads to truly scalable systems. Each service can be scaled independent of other services
- No dependency towards a particular technology stack
- Each microservice is relatively small, which makes:
- it easier for a developer to understand
- it easier to maintain
- the IDE is faster that makes developers more productive
- the web container starts faster, which makes developers more productive, and speeds up deployments
- Each service can be deployed independent of other services – easier to deploy new versions of services, frequently
- It is easier to scale development. It enables you to organize the development effort around multiple teams
- Improves fault isolation
- Based on the specific module need, we can choose the best among the different technologies, which necessarily may not be the same technology we used for other modules.
Microservices Architecture
So far we discussed about the Microservices introduction, details and advantages. Here are two different versions of the architecture:
- Simple Microservice architecture – It is similar to a Monolithic web application. While migrating the monolithic application to Microservices, we can use this architecture. We take an independent module of monolithic application and implement microservices.
- Microservices architecture with UI – In this, UI will be communicating with multiple Microservices. Also, one microservice may communicate with other microservice, get the required data and return to UI.
Example – 1
This is a small application to manage the patient’s’ data of a hospital. We have a microservice called patient. It provides APIs like, createPatient, updatePatient, deletePatient to perform all CRUD operations. UI application will get/push the required data from/to microservice to manage the Patient data.
Example – 2
This is enhancement for the above application, managing the patient data along with medical reports. We will have one more microservice named as medical to have the medical report details. When UI application requests medical microservice for medical reports of a patient, microservice will get the required patient details from patient microservice, prepare the response data and return it to UI.
Summary
The microservice architectural style is an approach to develop a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
To learn about how to build your first microservice, you may refer to the Getting Started with Microservices presentation.
Known uses
Most large scale web sites including Netflix, Amazon and eBay have evolved from a monolithic architecture to a microservices architecture.
Netflix, which is a very popular video streaming service that’s responsible for up to 30% of Internet traffic, has a large scale, service-oriented architecture. They handle over a billion calls per day to their video streaming API from over 800 different kinds of devices. Each API call fans out to an average of six calls to backend services – Ref
Amazon.com originally had a two-tier architecture. In order to scale they migrated to a service-oriented architecture consisting of hundreds of backend services. Several applications call these services including the applications that implement the Amazon.com website and the web service API. The Amazon.com website application calls 100-150 services to get the data that used to build a web page.
References
