Microservices
To understand microservices, we first need to understand what monolithic architecture is. Monolithic application in that in which all the modules are in the same application. That can be run as a single unit. Although the codebase can be little bit smaller, there are different inherent problems. For our example, lets consider College management system.
College Management system modules
- Registration module – managing all student registration process
- Accounting module – managing all the money related transactions
- Staff management – Manages all the staffs, attendance, etc.
- Examination management – Managing student examinations
- Library management – Manages books and reading resources for the college
- Records management – Managing old records and current records about students
All the above modules and more if required are present in the single application. Overtime, as this application grows, this will generate a very large codebase. It will be very difficult to fix a simple bug
- Huge codebase – Code from all the modules in single place
- Hard time to fix a bug – Searching for bug is very hard in huge codebase
- Deploy entire application – Every time we fix a bug or roll out new features
- Difficult to add new features – Other modules may be impacted. We must make sure it will not break other features.
On the contrary, microservices are small and focused services. We gather the smaller pieces which perform the same feature of monolithic application. We can create smaller services of each of different modules. Code boundaries for each of the modules are defined by the business boundaries or the business problems they are solving. That way we can avoid them to grow too large to maintain.
They are
Small and focused
Focused on single business problem and focused on the specific goal of that modal. Code does not spill beyond the business boundaries.
Autonomous
Every microservice is autonomous i.e. they are full fledged application on their own. Independent of other services.
Independent servers
Microservices are Packaged and deployed to their own machines or servers.
- Registration module – Server1
- Accounting module – Server2, Server3
- Staff management – Server4
- Examination management – Server5
- Library management – Server6
- Records management – Server7, Server8
API
Expose out the API, so that other services consume that API to communicate.
Network calls
All Communication between them occurs through network calls to the exposed API. Accounting, staff, examination, Library management uses information from the registration module. Accounting and paycheck management uses information from records management and staff management and so on
If we can change and deploy our application without changing or impacting other services that use our services, then it is a good microservice
Properties of Microservices
Heterogenous
Each of our microservices can be heterogenous. That means each of the microservices can be written in a different programming language and can be deployed in different platform and operating systems. They can communicate through API they expose, which usually are REST. For example, in our college management system, with registration module, examination module, accounting module, staff management module, library management module etc. One of them can be written in Java, another in Python, some other in .net, some in NodeJs, Some in PHP and so on.
College Management system modules can be coded and deployed in different languages, technologies, and platforms. We can choose a technology that suits a particular requirement. Use whichever system is better suited to the given job.
We cannot do that in monolithic applications. We have to write all the modules in same language and deploy to a same server.
Migration to better technology
It is harder to migrate to a new and better technology which is out in the market in the future, because we have to migrate the entire application. But in Microservices, we can migrate module by module basis without impacting the whole application.
Robustness
Robustness means if some part of the application fails, it will not bring down the entire application. In monolithic application, a small failure can bring down entire application. But in monolithic architecture, we can gracefully degrade that specific service and still run all other services.
If the examination management module goes down, entire college management system does not go down. Other services will run as usual. They can make registration, run accounting system, lend books in library and so on.
Scalable
In monolithic applications, if some part needs to serve a large amount of traffic, then we have to deploy whole system to multiple and better server.
For example in the registration season, lot of registration is happening. During examinations, examination management system is used exclusively and there is load in library management too. But other parts can have low levels of usage.
In microservices we can deploy only those specific modules to more servers and leave others, depending on the number of users that are using that module or microservices.
- Registration module – Server1, Server2 … more servers
- Accounting module –Server3
- Staff management – Server4
- Examination management – Server5, Server6 … more servers
- Library management – Server7
- Records management – Server8
Easy to deploy
In monolithic application, we have to deploy entire application even to fix a small bug fix. In microservices architecture however, we can deploy the specific service. Even a new feature can be added and deployed to the server quite easily. This will not impact the whole application and it continues to run as usual.
Reusable and replaceable
As each of microservices use one another it should be easy to replace them. For example, registration module is used by examination, library, accounting system. Microservices are highly reusable
Microservices are easily replaceable. If we have the same service from different vendor, or new and better system developed for registration, we can easily replace the old one with the third party system.
No comments:
Post a Comment