Table of Contents
Software development projects are complex beasts, so making the right choices early on is crucial to safeguard time, money, and peaceful weekends. Choosing an adequate software architecture is one of these core decisions. Monolith, Microservices, SOA, Serverless… Which one is the best software architecture?
Luckily, if you have precise requirements and knowledge about the main software architectures right now, it can be a quite straightforward pick.
We hope this blog post clears up any confusion to help you with the process.
Too Long Didn’t Read
The scope of your project dictates which is the best fit:
- Monolith – Quickest, but doesn’t scale well. Best for small apps
- Microservices – Flexible and scales very well, but demands good architects. Best for complex systems
- Serverless – Fast deployment, but infrastructure depends on third-party vendors. Best for apps with constant updates
What is Software Architecture (And Why It Matters)
Software architecture dictates how the system parts integrate and communicate with each other.
The architecture metaphor is not accidental. Imagine you are about to start building and would like the process to be fast and safe to provide the best ROI.
Should you construct a ground-level gallery? Aim for a skyscraper with modular components? Rent existing space and expand?
If you think “well, it depends on what I’m building!” you are on the right track, as the question applies to software as well.
The Shopping Mall Example
Let’s suppose you are planning a shopping mall. These events might happen:
- Shopping season is on and shoppers overwhelm your staff
- Five suppliers join you, and the warehouse is suddenly full
- There is a fire (sorry!), so evacuation is imminent
The mall’s architecture will heavily influence how to handle each scenario.
The same applies to eCommerce. Systems such as user interface, inventory, payment, employee management, live chat, and so on, will be connected differently depending on the software architecture.
Physical or virtual, the choice of architecture is extremely important. If it doesn’t fit the project’s needs, the architecture will generate roadblocks and bottlenecks at lightspeed. In the worst case scenario, it will even require a complete demolition.
The Most Important Software Architecture Models
Below we’ll cover Monolith, Microservices, and Serverless, as well as two that we’ll treat as variants: Modular Monolith, and SOA (Service-oriented architecture).
The list is not intended to be exhaustive, and instead focuses on the models that are more often applied.
1) Monolithic Software Architecture
As the name implies, monolithic software is self-contained and cannot be divided. Everything stays in the same codebase
All components, be it database, client-side UI, or server-server side application, are stored and managed in a single place.
It is the oldest software architecture. When Software Development started, back in the 1950s, software as a whole was virtually always monolithic. The Monolithic approach gained a bad reputation in the last decades, with the advent of newer practices.
1.1) Modular Monolithic Software Architecture
In the 1970s, the increasing complexity of software pressured engineers to somehow separate them into parts. One solution was the so-called modular monolithic software architecture.
It professes modules with minimal dependency between each other. They should be able to work independently and be replaceable. In practice, it should be possible to update modules separately. For example, adding a new payment gateway to your store without touching the inventory system.
It is still monolithic, however, because the whole system must be deployed at once.
Let’s take a look at some specific pros and cons of monolithic architecture.
Pros Of Monolithic Software Architecture
Quick at First
Since all parts are inside the same monolith, time spent interconnecting modules is minimal. Along with the small number of modules, it makes the software quick to deploy.
Lower Latency
Parts are directly integrated instead of communicating via APIs, increasing performance ever so slightly.
Simple Design
Everything is self-contained, meaning the architecture and relations between parts are straightforward and easy to conceptualize.
Safety
Fewer parts means less openings to attacks, and, at first, vulnerabilities are easier to manage.
Cons Of Monolithic Software Architecture
Very Limited Scaling
When the application grows or goes out of scope, the codebase easily becomes messy.
Changes to the code become exponentially hard, and onboarding of new team members is more and more time-consuming and challenging.
Costly Deployment
Even for small updates or fixes, it’s necessary to deploy the entire application. It might happen that new issues arise during deployment.
Single Technology Stack
The whole software must follow the same stack. Migration of technology, programming language or even libraries will likely require code overhaul.
Monolithic is Good For
The main issue is surely the limited scalability. As the monolithic project gets more complex, its pros quickly turn into cons. The resulting “spaghetti” codebase puts developers into tremendous stress as they might spend more deciphering than updating it. Handling nasty bugs and emergencies will likely mean shutting down temporarily.
However, we must be fair. It is still useful for small, single-purpose applications, as it is easy to manage at first. If you plan on expanding the solution over time, though, it’s definitely not recommended.
2) Microservices Software Architecture
With software growing even more complex and services more and more interconnected, the monolithic approach reached its limits. It was necessary to update and deploy different modules separately.
So, in the 2010s, engineers came up with what came to be known as microservices architecture. It breaks apart the single monolithic block into discrete, independent parts.
Back to the eCommerce example: inventory, payment, and customer accounts will likely be individual subsystems that can be handled separately. And it will be possible to, at the same time, add a product attribute, troubleshoot a checkout bug, and rollback a faulty account feature.
Pros of Microservices Software Architecture
Quick Testing and Deployment
Modules can be deployed separately. Any error will have limited impact and not generate overall conflicts.
Easy Scaling, More Features
Scaling, especially horizontally, is easy: new services can be added, updated and integrated to the solution at any time. In practical terms, the solution can be updated multiple times a day without the customer even noticing.
Virtually No Downtime
Since every module is configured separately, it’s possible to update and troubleshoot each one independently. Having to shut down the service is very unlikely.
More efficient and easier to understand
Developers can focus on smaller, more specialized code. With this focus, dev teams are more productive.
Better Performance
Microservices communication is not limited to API, so, with proper setup, it can present the best performance out of all architectures. For example, using AMQP protocol and responding to events which happen in other services.
Cons of Microservices Software Architecture
Harder to Design
A complete microservices architecture has complex and evolving relationships between modules, so specifying the scope of each service is a demanding task better suited to a specialist.
Microservices Software Architecture is Good For
Overall, microservices is the most advantageous software architecture, especially when compared to the monolithic model. It encourages scalability and is easier to maintain without sacrificing control over code and technology.
If your project will scale and benefit from continuous development (CD) and continuous integration (CI), it’s the way to go.
2.1) Service-Oriented Architecture (SOA)
The distinction between microservices and service-oriented architecture (SOA) has been a topic of intense debate for many years. SOA started in the 1990s to push beyond adopting microservices in a single application, instead focusing on the repurpose of modules across multiple projects.
This neat clarification comes from IBM:
“[It] comes down to scope. To put it simply, service-oriented architecture (SOA) has an enterprise scope, while the microservices architecture has an application scope.”
SOA allows teams to develop multiple apps in parallel within a unified database. Precious time is saved by repurposing modules and their integrations.
In general, SOA presents the same Pros and Cons as the microservice architecture. Additionally:
Pro of Service-Oriented Architecture
Efficiency across projects
Devs can build and integrate applications big and small much more efficiently by repurposing existing modules.
Con of Service-Oriented Architecture
High complexity
The overall picture of SOA solutions, with its multiple applications and modules, can be complex enough. Moreover, there are multiple points of connections between each.
As such, SOA requires thorough planning and experts to oversee it.
3) Serverless Software Architecture
In this case, the name is a bit misleading. Serverless applications do run on servers, but on servers managed by third-party providers. In other words, cloud vendors manage most, if not all, infrastructure, from execution environment and resource scaling to database and storage. Examples of providers: Microsoft (Azure), Amazon (Amazon Web Services), and Google (Cloud).
Inseparable from cloud computing, serverless architecture makes it easier for developers to focus on functionality. The burden (and cost) of maintenance is left to the cloud provider.
Pros of Serverless Software Architecture
Quick and Easy
Since infrastructure is taken care of, developers apply all their effort to the client’s needs. Deployment becomes much quicker and predictable.
Different cost model
As the cloud providers like to say, you only pay for what you use. Idle processing power often is not billed, since the hardware is owned by the provider (and surely rented to another company).
Very flexible capacity
It’s possible to adjust server capacity with a few clicks, and even automatically in cases of load spikes, blinding applications from downtimes.
Cons of Serverless Software Architecture
Different cost model
This plus can be a con. Constant exceeded usage of the vendor’s service might incur on high costs, maybe even higher than owning your own infrastructure. The billing terms have to be studied carefully to avoid surprises.
Vendor lock-in
Renting the vendor’s infrastructure does implicate trusting an important part of the business on a third-party company. Migrating to another provider will also prove difficult.
It should be noted that the market has matured tremendously in the past decade, and the big players have already proven themselves to be dependable.
Serverless Software Architecture is Good For
Serverless architecture shows its true power to applications with wildly varying usage levels. For instance, an eCommerce with both predictable (i.e. sales holidays) and random shopping spikes.
Apps with constant updates also benefit tremendously from developers focused on code and not worried with infrastructure.
However, choosing the right vendor is critical, as migrations will be complex. Finally, it’s important to study the billing model carefully – no one wants surprise costs.
Ok, So What’s The Best Software Architecture?
As any interesting answer, this one starts with “it depends.”
Take into consideration the scope, budget and workforce of your project. If it’s a quick internal app handled by a couple of developers or if you prioritize performance over scalability, the monolithic approach might just do the trick.
Now, thinking about the longer term. If a team of devs will often scale the application with new functionalities that should be updated independently, microservices is a good bet. Enterprises will do well in evaluating SOA early on to optimize development of multiple apps.
Last but not least, if your app is client-heavy and demands almost instant infrastructure and feature adjustments at the expense of a little flexibility, serverless will be the way to go.
