Microservices vs. 3-Tier vs. Monolithic
The main goal of this article is to address and understand the foundation of Microservice and tackle the pain point of old system architecture from Monolithic to 3-tier architecture.
When deciding which software architecture we should implement, Three prominent paradigms — Microservices, 3-tier, and Monolithic architectures — distinctly shape how systems are organized and function.
To help the architect decide which approach we should follow, let’s first understand each approach's history and main goals.
Monolithic Architecture
The short and simple definition of the monolithic approach is All-In-One. That means we have a single piece of code encapsulating data storage and data access, business logic, and user interfaces, and all components are interconnected and deployed together.
You need to keep in mind below key features when choosing a Monolithic
- Simplicity: Easier to develop and initially deploy due to a single codebase.
- Complexity with Scale: Scaling requires deploying the entire application, which can become challenging and inefficient as the system grows.
- Dependency Management: Changes or updates often require redeployment of the entire application, leading to potential downtime.
Soon, however, this all-in-one model showed its limit when building complex systems, and since everything is tangled together which becomes difficult to maintain, software engineers later proposed the second approach 3-tier architecture design.
3-Tier Architecture
The 3-Tier architecture divides an application into three logical tiers: Presentation, Business Logic, and Data Storage layer. Each tier handles specific functionalities.
The Presentation tier manages the user interface like a user's PC, laptop, or phone. The Business Logic tier handles application logic which is a set of rules, processes, and operations that define the core functionality and behavior of a software application in alignment with specific business requirements. And lastly, the Data Storage tier deals with database interactions and managing and storing data within a software application.
Key benefits of choosing 3-Tier
- Dividing the application into distinct tiers allows for better organization and maintenance.
- Each tier can be scaled independently based on demand — which is 😎
- Reusability of the Business logic across the application since it resides separately.
While separating logic and data storage in two different layers made things better, it was still a centralized way to design the application and it didn’t address quite well the challenges associated with complex applications and systems.
Microservices Architecture
Microservices is an architectural style where an application is composed of small, independent, and loosely coupled services, each responsible for a specific business function. These services communicate through well-defined APIs.
The best practice of splitting the application into microservices should be based on the business functionality, not on technical functionality. Imagine an e-commerce platform where services like user authentication, product catalog, payment processing, and order management are separate microservices. Each service operates independently, uses its database, and communicates with others via APIs.
Another important part of microservices, the services should be self-contained and independent from each other, so that each developer can work on a specific service without affecting other developers' services — as described in below figure.
This called lose coupling , which means , if we have an issue in Cart service , we only check on Cart service and not on other service , and then you can build a new image from Cart service and deploy it independently.
Communication Between Microservices
There are several common communication types between microservices and the type of communication patterns and protocols used can determine which type we could use!
- Sync communications- It’s a common way due to it’s simplicity to to interact between each services using an API ( HTTP/s call) allowing synchronous communication where one service sends a request to another and waits for a response.
- Async communications- This called a message broker , where the services communicate using a queue or topic ( E.g. Kafka ). One service publishes a message, and other services subscribe to these messages, allowing async communication with potential benefits in scalability, decoupling, and fault tolerance.
3. Service Mesh (Sidecar Proxies) - The third way for communication which is becoming a popular on field of Kubernates. The service Mesh deploy proxies alongside services to manage communication and handle tasks like load balancing, service discovery, and security and providing additional functionalities without affecting the services directly.
Downsides of Microservices
While microservices offer many benefits, they also come with challenges that organizations need to address. Here are some of them and what tools can be used to tackle the challenges:
1- Complexity- Due to distributed systems nature, which leading to increased operational overheads. One of the possible solution is to use Service Mesh tools like Istio or Linkerd.
2. Increased Operational Complexity- Robust operational practices, including deployment, monitoring and debugging. Possible good solution is to use Container orchestration tools like Kubernetes and OpenShift Platform.
3. Data Management- Distributing data across multiple services become complex. Use Event streaming platforms like Apache Kafka.
4. Pipeline automation — Use GitLab or AWS Pipeline.
5. Logging and Audit- Use ElasticSearch or DATADOG.
6. Performance Monitoring- Use Dynatrace or Prometheus Monitoring tools.
Summary Comparison
I tried to make it very simple comparison 🤝
In conclusion, the choice of architecture depends on factors like the complexity of the application, scalability needs, and team expertise. While Microservices offer flexibility and scalability, 3-Tier architecture strikes a balance, and Monolithic architecture suits smaller applications with simpler needs.
And there you have it, If you’ve made it this far without feeling the urge to take a power nap, congratulations! 🥳 and clapp for appreciation 👏
Remember, behind every great software engineer is a cup of coffee ☕️
