Microservices architecture addresses many concern of application development but does not solve all the problems. It has its own advantages and limitations. In order to understand it fully, we need to understand one common architecture pattern in practice, i.e. Monolithic Architecture
Monolithic architecture are highly tightly coupled and you can’t change something without impacting other. Look at this building and tell me how easy it is to change
Let’s take an example of an e-commerce website that has many components and services i.e.
Now let’s see what are some common problems associated with it
Ever Growing Container size
Generally all these components are packaged in one archive, EAR or WAR (if you want to deploy it in J2EE certified web/application servers). Size of this file will only grow as you add more functionalities. It will grow in every release if you are launching new features progressively.
Slow IDE (Think sometime about developers also)
When application gets enhanced and new functionalists and features are added the codebase grows. You can neglect it initially but eventually it hampers developer’s productivity as IDE cannot handle large amount of code efficiently. I have experienced this in Eclipse IDE many times.
Understand what you don’t have to
Every developer need to understand how to setup this project in their IDE workspace and struggle to make it work. This includes all other modules for which developer will contribute nothing except keeping it in his/her workspace. This is very tedious task and it takes lots of time for new joiners in the team.
Long application start time
Web containers are overloaded and they take lot of time to boot when you deploy/re-deploy your application.
Application deployment for small changes
For changes made in invoices module demands deployment of entire application. Disconnecting all the database connections which are in use for rendering some important application functionalities.
Technology stack changes are costly
Very tightly coupled with technology stack, so next time when your technology consulting partners recommends you costly technology stack and later when you realize that you can reduce the cost by employing open sources nut and bolts you might find it very difficult.
Micro services architecture
All these problems are addressed by Micro Services Architecture
Functionalists are broken down in small services which talks to each other using HTTP/REST, it can be synchronous or asynchronous. For example, an application might consist of services such as the invoice management service, the user administration service etc.
This is also known as Y axis scaling. Break one module into multiple small services that you can manage easily.
These services can be developed independently and you can deploy them independently. You have options of having one to one, one to many mapping between services and database. Which will keep things smooth when you touch one module and be relaxed because your other module will still be operational.
Building inter service communication and complexity of deployment architecture are some of the drawbacks of Micro service architectures but it does solve all the above problems. You have to make an informed decision when you choose between monolithic and micro services architecture.
Start-ups these days look for rapid deployment and progressive release. During the inception Micorservices based solution might take lot of time to set but eventually they serve the purpose very well.
Monolithic architecture are highly tightly coupled and you can’t change something without impacting other. Look at this building and tell me how easy it is to change
Let’s take an example of an e-commerce website that has many components and services i.e.
- Order service
- Invoice service
- Payment services will talk to various payment gateways.
- User Administration services.
- Graphical user interface for web, WAP and for various mobile platform like android, iOS, blackberry etc.
- Database services, possibly more than one database will be involved.
Now let’s see what are some common problems associated with it
Ever Growing Container size
Generally all these components are packaged in one archive, EAR or WAR (if you want to deploy it in J2EE certified web/application servers). Size of this file will only grow as you add more functionalities. It will grow in every release if you are launching new features progressively.
Slow IDE (Think sometime about developers also)
When application gets enhanced and new functionalists and features are added the codebase grows. You can neglect it initially but eventually it hampers developer’s productivity as IDE cannot handle large amount of code efficiently. I have experienced this in Eclipse IDE many times.
Understand what you don’t have to
Every developer need to understand how to setup this project in their IDE workspace and struggle to make it work. This includes all other modules for which developer will contribute nothing except keeping it in his/her workspace. This is very tedious task and it takes lots of time for new joiners in the team.
Long application start time
Web containers are overloaded and they take lot of time to boot when you deploy/re-deploy your application.
Application deployment for small changes
For changes made in invoices module demands deployment of entire application. Disconnecting all the database connections which are in use for rendering some important application functionalities.
Technology stack changes are costly
Very tightly coupled with technology stack, so next time when your technology consulting partners recommends you costly technology stack and later when you realize that you can reduce the cost by employing open sources nut and bolts you might find it very difficult.
Micro services architecture
All these problems are addressed by Micro Services Architecture
Functionalists are broken down in small services which talks to each other using HTTP/REST, it can be synchronous or asynchronous. For example, an application might consist of services such as the invoice management service, the user administration service etc.
This is also known as Y axis scaling. Break one module into multiple small services that you can manage easily.
These services can be developed independently and you can deploy them independently. You have options of having one to one, one to many mapping between services and database. Which will keep things smooth when you touch one module and be relaxed because your other module will still be operational.
Building inter service communication and complexity of deployment architecture are some of the drawbacks of Micro service architectures but it does solve all the above problems. You have to make an informed decision when you choose between monolithic and micro services architecture.
Start-ups these days look for rapid deployment and progressive release. During the inception Micorservices based solution might take lot of time to set but eventually they serve the purpose very well.
Comments
Post a Comment