Choosing the Right Software Architecture: monolith vs microservices
TL;DR: It’s about tech. But that’s what they need you to believe.
monolith vs microservices: It’s a management and culture choice. Microservices were designed to segment management bottlenecks in big corporations.
Yes you get the performance. But the real gain is when you have many teams under your belt.
Understanding Monolithic Architecture
Imagine building a house where every component, from plumbing to electricity, is interconnected. A monolithic architecture operates similarly.
It’s like building a house that doesn’t depend on a room across the street.
Benefits of adopting a monolithic architecture include:
- Simplified development and deployment processes: With everything housed in a single platform, deployment becomes straightforward.
- Ease of management for smaller teams: Less complexity in understanding the codebase as every member deals with the same unified structure.
- Lower initial costs: Generally, monolithic systems require less investment to set up and maintain initially, making it ideal for startups and small businesses.
If your development team is expected to remain between three to six members over the next few years, going monolithic might be your best approach.
Understanding Microservices Architecture
Conversely, microservices architecture divides the application into small, loosely coupled services. Each service handles a specific business function and operates independently.
Engineers often claim the architecture was designed for performance, but in reality it was designed to allow multiple teams to work independently on different parts of the project while reducing management costs and approvals.
And hosting platforms love this trend since it has become an excuse to package servers under different names to increase the number of offerings they can sell to engineering teams.
Perks of opting for microservices include:
- Enhanced scalability: As your business grows, scaling specific parts of your service without affecting others becomes possible.
- Specialized database optimization: Each microservice can be optimized for different scenarios, potentially leading to better performance.
- Independence in deployment: Issues in one service do not necessarily cripple the entire application, facilitating more robust fault isolation and quicker troubleshooting.
Cultural Implications and Conway’s Law
An often overlooked aspect of choosing the right software architecture concerns the cultural fit.
Conway’s Law suggests that software designs are reflected and constrained by the communication structures of the organizations creating them.
Distributed systems exist because at a certain scale and complexity, it is required to increase workforce. But this has the insidious cost of communication between teams. If not budgeted, it becomes chaos, and microservices break that cycle.
👉 Monolithic architecture = better suit a smaller, more collaborative team
👉 Microservices architecture = larger organization with multiple, autonomous units.
Making the Right Choice for Your Business
Understand that it’s not just a technical choice, but also the operational and cultural dimensions of each architecture type.
The golden question:
Will you be able to feed your engineering department with one New York-style pizza at lunch?
Then go monolithic. Performance can always be improved. Culture is harder.
When Microservices Kicks You Back
Imagine you’re working in Service B.
Service B reads data from Service A, D, G, P, and K. Additionally, Service B is used by 4 other services.
Here is a visual representation.
You’re on-call that day, and there’s a bug in your system.
It turns out that a call to P isn’t working because G is failing.
Now, you have 4 angry teams coming at you, but you can’t fix G because it’s not your team’s responsibility.
Half of Team G is on holiday (yes, the team that owns Service G), and you end up reading code you don’t know.
Visual representation of how the humain factor can blow up a system.
Can you imagine fixing your favorite restaurant’s oven just because you can’t eat?
This is the type of issue that really arises in microservices architectures.
Conclusion
The decision between choosing a monolithic or microservices architecture should not be taken lightly.
If you are reading this and looking to understand the difference, there is a probability that you are starting a project in tech.
Just send me an email to chat about your project—maybe you just need to delegate part of your business logic to a provider and you can make your project efficient.
Sometimes creating a simple POC can help start conversations with customers to study their reaction to the solution.
I believe every amazing product stems from great conversation, and starting those should not be delayed.
Delivering a simple MVP shouldn’t put you in debt or take half a year.