For Monolith vs Microservices - 1
Why some companies still prefer to go for Monolith architecture?
Biggest advantage of using Monolith Architecture:
We will further look on what exactly is the biggest advantage of using Monolith Services over the Microservices
If your application is small and not subjected to large scale in terms of complexity and user base then the development and deployment is pretty easy when compared to Microservices, even if you are planning to use cloud technologies and decided to host the Website and Services separately the Monolith approach would be ideal for this scenario.
The developers of fictional software "PinPointer" would have a very quick time in developing and deploying the application, the initial maintainability is very easy, having said that the maintenance become tedious when the application grows in size
Disadvantages of Monolith Architecture:
Where exacly the Monolith approach fails?
Now our fictional software "PinPointer" is growing and it became a huge success in the Website market, as we discussed the company want to provide the service via mobile phones and tablets, since the company is using the "Loosely Coupled Monolith" architecture it would be easy to do that, additionally the company wants to adopt cloud technologies, deploying the 2 separate boxes A and B into the cloud would be a cakewalk for the deploying team, so where lies the problem? let's see that one by one.
What Monolith Services Lacks:
* Single failure, whole failure, Since the Monolith is a single box, a failure is a complete failure in most cases, regardless of small or big failure in the service
* Heavy dependency on single software vendor, when tough times the application needs support from the single software vendor.
* Limited Modularity, the Monolith is lacking the luxury of attaching any super performing plugins or modules which is available in different platform as the current platform doesn't supports the portability
* May need to stick to one version of a software, needless to say that some of the software compatibility is limited to a version, upgrading to higher version won't supported by supplement modules / software, due to this the application may be missing a improved updates by the key software due to the additional software aren't supporting it.
* Lack of Scalability, this is the key thing when your user base and data volume increases.
* Loading unnecessary objects in memory, this is very critical, you may want to print a document and calling the service, but the service is loading all the elements for the whole application like initializing objects for user information, initializing objects for non related authenticated information, geographical information and so on, ideally the motto "Load what is needed" is getting a hit, so does the performance.
* Rapid Development Limitation, if the development work is subdivided and spread across then the sum of the productivity will be high in contract to the single code base management.
* Lack of Load Balancing the requests, since this is running in the same box load balancing the requests accordingly is a tedious process as it requires lot of work, one option is to put a clone of the service box to serve requests, but again this is accessing the same database most of the case, again we need to do a database clone additionally
* Lack of quick response for request processing, this is purely compared against the Microservices, say our fictional software consists of the following modules for bug-tracking
1) Bugs Management
2) User Management
3) Reports Management
4) External Services Management
5) Print Management
6) Email Management
7) Sync Management
"One service fits all" concept will not work here as if the requests are flooding in and one single service is responding to all affects the performance of the processor, so does the application.
* Lack of quick detection of issues, needless to say that if any issue happens instead of searching in whole application, think of we look for the issue in appropriate single micro-service.
To Be continued
Comments