Why the path to a Microservices Architecture is a promising one.
The latest entrant in the world of technological development is the microservice architecture, also abbreviated as MSA. It would not be completely illogical to think of the MSA as a refined version of a Service Oriented Architecture (SOA) , which has been the go to approach of most enterprises as the needs and demands of users for better applications is increasing manifold.
But, first, let us see why do we need to do away from the traditional monolithic applications:
Let us take an example of a live video streaming mobile application. The following pictorial representation provides a general idea:
It seems that the application has a structured architecture, but it is delivered as single package. The format could be a WAR of a JAR depending upon the language the application is built on and the framework its written in.
Now, let us look at an MSA of the same application:
The differences between the two approaches can be tabulated as:
| MONOLITHIC ARCHITECTURE | MICROSERVICE ARCHITECTURE |
|---|---|
| As the application grows, it grows more and more complex. | The embedded microservices can be developed individually keeping the complexity in check |
| It is deployed as a single component. Usually a single WAR/JAR file serves the entire application.Even if one feature malfunctions, it would imply the application is malfunctioning. | It is deployed as a cluster of multiple components. There would be multiple WAR/JAR files serving different features of the applications. A downtime on one component would not severely affect the other components. |
| If a new developer joins the team, the entire code base of the application would have to understood, in order for further development without impacting any prior functionality. | A new member in the team would only be concerned with the microservice being worked upon with just an understanding of the communication protocols being followed such as RPCs or API Gateway interface. |
| The infrastructure of the application can be scaled as a single unit. Even if one feature does not require scaling it would still be scaled as it is a part of the monolith. Also the entire application would be subject to a single hardware type, regardless of the needs. | In a microservice architecture, since each component is deployed independently, it can also be scaled up or down as per need. The different microservices could have different server requirements, such as, being memory, storage or compute intensive. Such a need can be easily met in an MSA. |
| In a monolithic application, a single database schema is shared among all the services. All services would have to content with the general offerings of a single database type. | In a microservice architecture, each service can have its own database. Hence, all databases would differ as per schema, type, and functionality. |
It would also be prudent to keep some of the drawbacks of the MSA in mind:
- As the name suggests, the service size must be kept small, which sometimes does not agree with developers.
- The partitioned database architecture may present a challenge. Since every microservice has its own database, the multiple transactions occurring over a multitude of databases simultaneously may be difficult to design and develop. Also, there is a risk of increased redundancies in the data.
- Since the components are loosely coupled, there is a need of extra coding to handle failovers of the inter-services communications (Messaging, RPCs) .
- From a QA point of view, it proves to be easier to write and implement test cases for a single monolith rather than singular test cases for each microservice.
Looking at both the pros and cons, the need and demand of robust applications could be met by following an agile form of development which is much easier to practice in a microservice architecture.
This is nice to understand systems are now moving into MSA.
About time, wouldn’t you say 🙂