Intro
Ever heard the words "monolithic" and "microservices" tossed around in tech conversations? Don't worry if they sound a bit confusing – you're not alone! These terms are hot topics in the world of software design, and for good reason.
In this article, we're going to break down what monolithic and microservices mean. We'll compare them in simple terms and talk about when you might want to use each one.
Monolithic and microservices are both types of software architecture. In simple terms, architecture is just a fancy word for the overall design of a computer program - it's the plan that lays out how all the pieces of the software will fit and work together. These are just different ways to build web applications.
We are going to understand each architecture with the help of an example.
We'll consider designing an online travel booking web application that offers hotel reservations, flight bookings, and train ticket purchases, along with payment processing and user account management for understanding these architectures.
We will be discussing these architectures concerning backend logic.
Monolithic
In a monolithic architecture, we would design the application as a single, unified system. All the code for every feature would reside within one codebase(project). This includes:
- Hotel booking functionality
- Flight reservation system
- Train ticket booking
- Payment processing
- User authentication (sign-up and login)
The entire codebase, encompassing all these functions, operates as one cohesive unit.
In a monolithic architecture, you build and deploy the entire application as one single unit. This means you have to use just one technology stack for the whole app, whether it's Java with Spring Boot, Python with Django, JavaScript with Node.js, or any other combination.
Monolithic architecture is often the go-to choice for small startups, personal projects, or companies that don't deal with a huge user base.
Benefits of Monolithic Architecture
Easier to Develop:
- You work with a single codebase, which means less complexity to manage.
- All parts of your application are in one place, making it simpler to understand the overall structure.
- When you need to add new features, you can easily integrate them into the existing codebase.
- Testing is more straightforward because you can run all tests in one go.
Easier to Manage:
- Deployment is simpler because you're dealing with just one application.
- You only need to monitor and maintain a single system.
These advantages make monolithic architecture a practical choice for smaller projects or teams that want to get their application up and running quickly without dealing with the complexities of more distributed systems.
Challenges with Monolithic Architecture
Some major issues that come with using a monolithic architecture include:
Single Point of Failure
In a monolithic setup, all parts of the application are tightly interconnected. This means if something goes wrong in one area—like a bug or performance issue—it can affect the entire system. Imagine if a glitch in one feature causes the whole app to crash, leaving users unable to access anything. This dependency on a single codebase makes the system vulnerable to widespread failures, impacting reliability and user experience. It also limits flexibility in updating and scaling different parts of the app independently, which can lead to more downtime and operational headaches.
Redeployment
Imagine we need to make a minor update to improve the payment functionality in our application. Even though it's a small change, we have to redeploy the entire app. This can be incredibly frustrating. A simple tweak to one part of the system forces us to go through the whole deployment process again, involving all components of the app, even those not affected by the change. This not only wastes time and resources but also increases the risk of introducing new bugs and downtime, making the process unnecessarily cumbersome.
Scaling Issues
When user traffic spikes, a monolithic application can struggle to cope. Every part of the app—from hotel bookings to payments—feels the strain on the single server. This overload leads to slow responses, timeouts, and errors, frustrating users.
To manage increased traffic, you typically need to scale horizontally by deploying multiple copies of the entire app across many servers.
However, this method is inefficient because it requires replicating the entire application, even for parts that don't need more resources. And with scaling, comes a hefty bill to manage.
Balancing performance needs with cost efficiency becomes challenging. Scaling down during quieter periods also poses challenges, including safely decommissioning excess servers without disrupting service and managing data consistency.
These challenges highlight why monolithic architectures struggle with fluctuating loads and why organizations often turn to more flexible solutions like microservices, which offer better scalability and cost management capabilities.
Lots of Dependence(Rigid)
If too many developers are working on the same codebase, even making a small change can become problematic. Each change can impact other parts of the application, leading to conflicts and dependencies that need to be resolved. This often results in longer development times, as developers must coordinate closely, perform extensive testing, and handle merge conflicts. The interdependence of various components means that a small tweak by one developer might require adjustments or fixes in seemingly unrelated parts of the code, complicating the development process and slowing down progress.
Solution
Enter microservices:
And one of the pioneers in adopting microservices was the renowned media streaming platform, Netflix. Originally built on a monolithic architecture, Netflix faced significant challenges as its user base grew exponentially. With millions of subscribers globally streaming movies and TV shows simultaneously, the monolithic approach struggled to handle the increasing traffic efficiently.
This led Netflix to innovate and transition towards a microservices architecture, marking a pivotal shift in how modern applications are designed and operated. Today, Netflix operates using hundreds of microservices to power their application. This architectural shift has become a standard for high-traffic applications.
Netflix’s adoption of microservices revolutionized the way large-scale applications handle scalability, flexibility, and user experience.
For more info check out these blogs published by Netflix:
https://netflixtechblog.com/tagged/microservices
Similarly, Atlassian noted in their monolithic vs microservices blog:
In January 2016, we had about 15 total microservices. Now we have more than 1300. We moved 100K customers to the cloud, built a new platform along the way, transformed our culture, and ended up with new tools. We have happier, autonomous teams and a better DevOps culture.Microservices may not be for everyone. A legacy monolith may work perfectly well, and breaking it down may not be worth the trouble. But as organizations grow and the demands on their applications increase, microservices architecture can be worthwhile.
Reference:
https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith
Microservices
To sum up microservices in one phrase: don't put all your eggs in one basket.
In a microservices setup, we take a big application and break it down into smaller, manageable pieces, each handling a specific function. These smaller pieces, or services, operate independently, have their codebase, and can be developed and deployed on their own. This makes them loosely connected, allowing for greater flexibility and easier management.
Microservices architecture is generally not adopted by small teams or small organizations. It is more commonly implemented by large companies with millions of users and thousands of developers, such as Amazon, Uber, Netflix, Airbnb, etc.
Deciding the Number of Microservices
When transitioning from a monolithic application to a microservices architecture, we need to divide the single, unified application into multiple smaller, independent services.
But the question arises: how many independent services should a monolithic application be divided?
There's no exact answer or strict rule for this—it varies from company to company based on their specific business needs. For example, in our monolithic travel application, the company might choose to split it into smaller services like payments, hotel bookings, flight bookings, authentication, and train bookings. This way, the monolithic travel application becomes five separate microservices, each handling a specific part of the application and working together.
Benefits of Using Microservices
Independent Deployment (Isolation development and Deployment)
One of the key advantages of a microservices architecture is the ability to independently deploy individual services. The independent deployment results in major cost savings, lower downtime, and more time saved as we don't have to redeploy the whole application. In this approach, each microservice has its own:
- Codebase
- Development team
- Database
- CI/CD pipeline
Independent deployment means you can update, modify, or scale a single service without affecting the entire application. Changes to one service don't require redeploying the whole system.
Flexible Scaling (granular scaling)
- Flight Booking Service: During a flash sale on airline tickets...
- Hotel Booking Service: If it's the off-season...
- Payment Service: Increased activity...
- User Authentication and Signup Service: Moderate scaling...
- Train Booking Service: Base capacity...
Technology Flexibility
Each service can use different technologies best suited for its needs.
But how do microservices interact with each other?
There are three major ways for microservices to communicate:
- Synchronous Communication
- Asynchronous Communication
- Service Mesh
Synchronous Communication
- API Endpoints
- Request-Response Mechanism
- Real-Time Interaction
Asynchronous Communication
Using Message Brokers
- Producer → Broker → Consumer
Service Mesh: Brief overview
A service mesh is a system that helps microservices communicate efficiently and securely using sidecar proxies.
Issues with Microservices
Complex to Develop
Management Overhead
High Infrastructure Cost
Because of these challenges, small teams or startups often prefer not to use microservice architecture.
Summary: Choosing Between Monolithic and Microservices
When to Use Monolithic Architecture:
- Simple Apps
- Small Teams
- Lower Costs
- Quick Development
- Easy Management
When to Opt for Microservices:
- Big and Complex Apps
- Need to Scale
- Multiple Teams
- Frequent Updates
- High Reliability
- Different Tech Needs
This article is based on and adapted from content originally published by Unlogged.
Cheers!
Happy Coding.
Top comments (0)