Why Do You Always Choose Microservices Over Me? (Said the Monolithic Architecture)
Why Do You Always Choose Microservices Over Me? (Said the Monolithic Architecture)
See why all the major companies are moving to microservices architecture, and whether it's worth the effort to change over from the monolith.
Join the DZone community and get the full member experience.Join For Free
Ever wonder why companies like Apple, eBay, and Netflix care so much about microservices? What makes this simple architecture so special that it is being hyped so much? Is it worth the pain and effort to shift an entire running application from monolithic to microservices architecture? Many such questions came to our minds when we started using the microservices in our projects.
In this blog, we will try to cover the answers to these questions and have a deeper look into the microservices architecture and compare it with the monolithic architecture.
What Are Microservices and How Are They Different From the Monolith?
Microservices are small, autonomous services that work together. Let's simplify this definition a little bit more.
Microservices - also known as microservice architecture - are an architectural style that structures an application as a collection of loosely coupled services which implement business capabilities. The microservice architecture enables the continuous delivery/deployment of large, complex applications.
Codebases grow as we write code to add new features. Over time, it can be difficult to know where a change needs to be made because the codebase is so large.
Within a monolithic system, we fight against these forces by trying to ensure our code isWithin a monolithic system, we fight against these forces by trying to ensure our code is more cohesive, often by creating abstractions or modules. Microservices take this same approach to independent services. We focus our service boundaries on business boundaries, making it obvious where the code lives for a given piece of functionality.
Why Not Monolithic Architecture?
The main question here is, if we have a fully functional monolithic application running, why is there a need to convert it? Why is there a need to increase the overhead and put in extra effort? Also, is the conversion worth the pain and effort?
The first thing we need to understand is that monolithic applications are not evil. Change and evolution are a part of life. Although monolithic applications did solve many of the classic architectural problems like deployment (as it is to be deployed as a single unit) and testing it is easier, it has far more drawbacks as compared to the benefits. The major problems we face while working with monolithic applications include
Scalability – Scaling an application can be difficult – monolithic architecture is such that it can only scale in one dimension. On the one hand, it can scale with an increasing transaction volume by running more copies of the application. With monolithic architecture, we cannot scale each component independently, so the entire application needs to be scaled even though most of the applications might not require scaling.
Reliability –Another problem with monolithic applications is reliability. A bug in any module (e.g. memory leak) can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug will impact the availability of the entire application.
Availability –Even if one service fails, the entire application has to be brought down. As all the services are deployed as a single unit, it is a headache to pull down the application each time a service fails or a bug appears.
Agility –In a monolithic application, even if a small component in an application has to be changed, the entire application needs to be repackaged and assembled together. We can definitely say that application has reduced agility, since rebuilding the whole application takes a decent amount of time.
Continuous deployment –If you bring continuous delivery into the picture, then it fails miserably on this side, since even for a small change in the application, build time increases tremendously and it definitely decreases the frequency of deployments. Moreover, you must redeploy the entire application on each update even if it is a small change.
Software Stack Autonomy –Monolithic applications have a barrier to adopting different software stacks. Since changes in frameworks or languages will affect an entire application, it is extremely expensive in both time and cost.
Apart from these issues, there are many other issues that programmers keep facing while working with the monolithic applications. So taking these issues into account, there seems to be a requirement for a different architecture which can at least resolve some of these issues.
This is where microservices come into the picture.
Microservices - A Savior?
Now we have gone through some of the problems one can face while working with monolithic applications. So, can microservices overcome those problems? Are they any better or are they just another architecture that is being hyped?
As we have already seen, the main idea of microservices is to split your application into a set of smaller, interconnected services instead of building a single monolithic application. Each microservice is a small application that has its own architecture consisting of business logic.
Now that we have a rough idea about microservices, let us go through some of the advantages that microservices provides us which monolithic architecture couldn't:
Scalability: Each microservice can scale independently without affecting other microservices. Thus, it definitely serves an advantage over monolithic applications, wherein a lot of resources are wasted for scaling unrequired services since they are all packed together into one single deployable unit.
Reliability: A microservice’s fault affects only that microservice and its consumers, whereas in the monolithic model, a service fault may bring down the entire monolith. Even if one service fails, other microservices are highly available and the failed microservice can be rectified very quickly.
Availability: Rolling out a new version of a microservice requires little downtime, whereas rolling out a new version of a service in the monolith requires a typically slower restart of the entire monolith. A failed microservice can be rectified very quickly with minimal downtime, as well.
Agility: Changes in a particular microservice can be done very rapidly and can be deployed very quickly, which makes it a highly suitable architecture for ever-changing business requirements, meaning a highly agile environment.
Continuous deployment: Microservice architecture enables each microservice to be deployed independently. As a result, it makes continuous deployment possible for complex applications. Moreover, unlike monolithic applications, code changes in microservices can be done very quickly to follow changes in business requirements, which results in a faster development cycle.
Software Stack Autonomy: With microservices, as each service is independent and each service is a new project; each service can be developed in any language that fits best for the requirements. Thus, different software stacks can be used for different microservices.
Apart from these, microservices also provide us with more advantages:
Management: Application development efforts are divided across teams that are smaller and work more independently.
- Data decentralization: There is no centralized database. Each module has its own, so there’s data decentralization. You can use NoSQL or a relational database, depending on the module.
- Better Understandability: The distributed services make it easier for a new developer to understand the functionality of a service. Also, as a particular module is dedicated to a particular service, it helps the developers to have a better understanding of that service rather than trying to figure out the entire application.
And the list goes on and on...
But Wait, No One Is Perfect, Right? Neither Are Microservices
Just because something is all the rage around the industry doesn't mean it has no drawbacks. Believe it or not, microservices are not perfect. They do have a different set of drawbacks. Let's have a look at some of them:
Operational Complexity: You need a mature operations team to manage lots of services, which are being redeployed regularly.
- Testing: Testing a microservices application is also much more complex than in the case of a monolithic web application. For a similar test for a service, you would need to launch that service and any services that it depends upon.
- Deployment: Deploying a microservice becomes more complex with many jobs, scripts, transfer areas, and config files for deployment in the case of distributed systems.
- Multiple databases and transaction management: Microservices has a partitioned database architecture. Business transactions that update multiple business entities in a microservices-based application need to update multiple databases owned by different services.
- Communication: With microservices, each service communicates through API/remote calls, which have more overhead than with monolithic software’s interprocess communication calls.
- The Complexity of a Distributed System: As a distributed system, microservices introduce a level of complexity and several issues to take care of, such as network latency, fault tolerance, message serialization, unreliable networks, asynchronicity, versioning, varying loads within our application tiers, etc.
Now we have a rough idea of what monolithic and microservices are and what their pros and cons are.
To summarize, the monolithic architecture better suits simple, lightweight applications. The microservices architecture pattern is the better choice for complex, evolving applications, despite the drawbacks and implementation challenges.
One needs to make their choice wisely before starting off with either of the architectures, and also consider if the effort you put into the transformation or migration from monolithic to microservices is worth the pain and complexities.
In our next blog, we will be looking forward to talking about some of the best practices one should take care of while moving towards the microservice architecture. Stay tuned for more.
Hope this helps. Happy coding!
Published at DZone with permission of Anmol Sarna , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.