“The greatest improvement in the productive power of labour, and the greatest part of the skill, dexterity, and judgment with which it is anywhere directed, or applied seem to have been the effects of the division of labour.” Adam Smith
This Scottish moral philosopher, Adam Smith, very well stated the caliber of microservices through stating the importance of smart division of labour. The same cogitation, to provide radical flexibility and improved simplicity through a platform led, Dr. Peter Rodgers, to use this term “Micro-Web-Services” first time in 2005. And since then it has evolved as a choice for developing complex APIs requiring less brittle and scalable code. Choice of architecture is the base of any successful API and hence, for accurate understanding of Microservices and its utility, a comparative study between Monolithic and Microservices is necessary:
Prologue to Monolithic and Microservices Architecture
What is Monolithic Architecture?
A software system is called “monolithic” if it has a monolithic architecture, in which functionally distinguishable aspects (for example data input and output, data processing, error handling, and the user interface), are not architecturally separate components but are all interwoven.
What is Microservices Architecture?
In computing, microservices is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task, facilitating a modular approach to system-building.
Why to choose Microservices over Monolithic architecture?
Complex applications are inevitable as air these days and hence selection of architecture has become a key issue for app development. To understand the utility of ‘in vogue’ architecture microservices, let us understand the pattern in which monolithic architecture works:
It is a conventional way of developing APIs. In Monolithic Architecture, all the business logic for servicing a user request is packaged into a single application process and all the features of the application are written as a separate division(modules) that are further packaged into a single large application. For example, if the application is made in Java, then the all the components are packaged into a war file and is deployed to a tomcat, jboss or a jetty server. If the application is built in Python Django or Rails then the same is deployed as an entire application directory structure.
Superficially, it seems an easy and uncomplicated architecture, but before jumping to any conclusion, let us go through some caveats:
Sometimes so many iterations makes the application bigger than expected and of course adding features can make it huge. Once it happens, quick development and delivery becomes too much difficult. Bug tracking and fixing also becomes too more difficult to handle. These blocking difficulties result in extravagant usage of time
Even for a minor bug fixing you will require to re-deploy entire application.
Another sad disadvantage is scaling. To scale, you need to scale the entire monolithic application, even though you only need more resources on one of the components of the big application. Basically selection of server resources and sizing will always depend upon the highest resource intensive component in the big application (although the other components do not need much resources)
The modules being interdependent, implementing technologies or languages individually is not possible, which will make adopting new technologies or languages difficult.
Now let’s analyze how microservices tackles these deficiencies. In Microservices, smaller components together make a big application and these components can talk to each other when required. These micro components can be called as interconnected services.
The main advantages of Microservices are:
The form and size will be maintained due to its structure, where components are dissected into smaller services.
Independence is the key here, continues deployment is easily possible, unlike monolithic architecture as each service can be deployed independently.
It follows the Single Responsibility Principle, where each service is responsible over a single part of the functionality.
Scaling components individually is possible here, as components are de-coupled to different services, so can be scaled horizontally and individually without impacting the overall system.
Light-weight Communication: Services communicate with each other using a lightweight communication, such as REST over HTTP.
Pseudo Examples of Microservices:
Early Users of Microservices–
Being one of the poster kiddie for microservices, it has undergone a paradigm shift in its design and other system to employ this architecture. Adrian Cockroft, very well puts his experiences in Migrating to Microservices, with all that he learned and gained while this migration.
Amazon made a distinguished transformation from the Obidos monolithic application to a service-oriented architecture with encapsulated databases and small, “two-pizza” teams. Albeit, the term Microservices was never used by Amazon, those who were a part of microservices movement were much inspired by this step. The 2006 ACM Queue interview with Werner Vogels, remains the best source for information on what they did.
Ebay & Google
Randy Shoup describes experiencing of working with microservices from his time at eBay and Google . He focuses on the common evolutionary path from monoliths to microservices and paints a picture of a mature services environment at Google. It’s also worth watching his follow-up interview(with transcript), which elaborates on some of the lessons from this experience.
Other Companies like Airbnb, Disney, Dropbox, GE, Goldman Sachs and Twitter have seen development lead times cut by as much as 75 percent when using microservices.Other than these giants Gilt, PayPal, Condé Nast etc. also use Microservices as their architecture.
Some of the smaller issues or I must say drawbacks in migrating to microservices based architecture are mentioned below.
Developers have to employ logic for intercommunication in microservices architecture, they also have to deal with failures between them. This can be toilsome as compared to monolithic applications.
Complexity and dependency of one service on other makes testing tedious compared to monolithic application.
There needs to be a service discovery mechanism, that will help services to find other service. This is necessary, because in a microservice architecture, service instances are mostly immutable. Also the location(the IPaddress) of the service will change dynamically(during scale up, scale down, or new deployment etc.), and other needs to get the new location without delay.
So as an afterthought, to conclude this article..
If the application itself is small, with limited logic and modules in it, Monolithic is the best suited architecture for it. But for really huge, intricate and challenging applications, there is no way out other than MIcroservices architecture.
If you differ or agree with this opinion regarding the use of Monolithic or Microservices architecture, please share your viewpoint with us.