When I first began researching this topic, I was faced with a plethora of articles where architectural styles are placed in opposition to one another, such as the well-known monolith vs. microservices debate.
While I understand the underlying intention—to highlight the contrasting approaches and benefits of each solution—focusing solely on comparisons misses the point.
The value of these designs lies not in how they differ from one another but in how they can be leveraged to meet specific use cases and achieve particular business goals. There is no clear winner in the 'microservices vs. monolith' debate because no single system architecture is universally 'right' or 'wrong.’
As Brendan Burns, co-creator of Kubernetes, aptly puts it:
“If you insist on microservicing everything, you’re definitely going to microservice some monoliths that you probably should have just left alone. But if you say, ‘We don’t do microservices,’ you’re probably leaving some agility, reliability and efficiency on the table.”.
Ultimately there are two main truths to keep in mind when choosing an architectural style:
- When given a choice, the best approach is to keep it simple - boring even!
- Your architecture will (or, at least, should) evolve as your business, requirements, and technological landscape change.
This article is a collection of interesting facts I found while researching the article “Six Modern Software Architecture Styles” - although interesting is indeed subjective 😉.
(1) Architectural Style or Pattern?
Unsurprisingly, as with many IT terms, “Architecture Styles” and “Architecture Patterns” are often used synonymously, while other times they are treated as distinct categories of software concepts.
The confusion became so pervasive that I had to sit down with my team to decide on the terminology we would use to stop confusing ourselves further (that’s also how I ended up writing “System Design and Software Design in Distributed Systems”).
We landed on these definitions:
- Architectural Style: It’s the overall structure and organization of a software system from a 10,000-foot view, showcasing the highest level of system design abstraction. Architectural styles address fundamental questions about how system components communicate, how data flows, and how the system is divided into modules or layers. Changes to an architectural style are significant and can be costly, as they involve restructuring the fundamental aspects of the system and can have a long-term impact on the project.
- Distributed System Design Patterns: These are frequently used solutions to common industry problems related to data storage, messaging, system management, and compute capability. Examples of common Distributed System Design Patterns include Ambassador, Circuit Breaker, CQRS, Event Sourcing, Leader Election, Publisher/Subscriber, Sharding.
(2) Monolithic Architectural Style
In recent years, starting a project with a straightforward, simple, and performant monolith has often been stigmatized. Yet, many large enterprises like Dropbox, X (formerly known as Twitter), Netflix, Facebook, GitHub, Instagram, and WhatsApp initially built their successes on monolithic codebases. Furthermore, several prominent companies such as Istio, Segment, StackOverflow, and Shopify still rely on them to this day.
Historically, monoliths were the standard in the early days of software development. However, due to some of the more challenging aspects of this architecture, the concept of Service-Oriented Architecture (SOA) began to gain traction in the 2000s. It was during this period that the term “Big Ball of Mud” was coined to describe monolithic legacy architectures.
What’s interesting to me is that the initial idea of the Big Ball of Mud doesn’t match the current image of monoliths!
Today, we often envision a monolith as a tower of rigid, inflexible, tightly-coupled processes, where deploying a simple change to one part of the application might inadvertently affect a completely different one.
However, when Professors Brian Foote and Joseph Yoder originally introduced this term, they were describing a chaotic architecture composed of programs haphazardly piled onto one another, with data exchanged between them via file dumps onto floppy disks.
(3) Microservices Architectural Style
Microservices represent the epitome of modular architecture, where small, autonomous components (modules) operate on separate processes and communicate over networks to form a cohesive application.
Interestingly, the rise of microservices wasn’t solely due to the challenges faced by Service-Oriented Architecture (SOA) implementations, which often struggled with defining clear service boundaries.
There is a direct correlation between the popularity of microservices and the growing need for organizational clarity, autonomy, and independence within engineering teams.
“Amazon, one of the first companies to openly discuss the microservice concept, really wasn't trying to push the architectural principle as much as they were trying to push the idea of an independent development team whose blockers were few and far between.” - Ted Neward
Companies were struggling to optimize developer velocity due to cross-team dependencies. Most organizations were organized into ‘skill-centric’ departments, leading to common development hurdles such as waiting for the infrastructure team to procure a server, waiting for the DBA team to implement a schema change, or waiting for the QA team to develop a test to identify a bug.
Microservices liberate development teams, fostering flexibility that, in turn, accelerating teams' velocity. Teams gain autonomy —deploying their code independently and at their own pace— and can select the most suitable technologies for their specific services, unhindered by standardized, one-size-fits-all approaches.
It also feels like Conway’s Law at work, which states that ‘Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.’
(Another interesting tidbit: engineers at Amazon Prime Video’s didn’t actually migrate from microservices to a monolith, but rather to a “macroservice” - I dive a bit more in detail in my article.)
(4) Event-Driven Architectural Style
Event-Driven Architecture (EDA) complements both Microservices and SOA. It stems from the need of modern digital businesses to respond instantaneously to events, ensuring users receive the most current information and rapid feedback.
With the rise of cloud-native architectures, container-based workloads, and serverless computing, EDA has gained renewed popularity.
However, the concept of components or services communicating through events is not new. EDA has been around for decades, in fact Gartner proclaimed it the “next big thing” nearly 20 years ago!
Maybe the fact that EDA seems like a fairly recent concept might be due to my own skewed perception of time—much like how, as Millennial, the 1980s feel like just 20 years ago, even though it’s already been 40 years.
(5) Serverless Architectural Style
Like all other architectural styles, the principles underpinning Serverless Architecture—specifically, the ability to build and run services without managing the underlying infrastructure—have existed for some time. However, they've become mainstream in software development with the rise of cloud computing, notably since Amazon launched the first widely-used Function as a Service (FaaS) platform, AWS Lambda, in 2014
However, when adopting this architectural style, many engineers may not have top of mind that FaaS providers typically support only specific technologies, and migrating to a different cloud provider can be exceedingly complex and problematic.
Intellectually, the advantages of cloud-agnostic deployment are well recognized, but the practical importance of this flexibility becomes starkly apparent when issues arise that necessitate a migration to another provider.
“His team was using GCP’s Cloud Run, a container service, to host their API. They had a unique use case that required them to call back to their own API to kick off more work. It turns GCP monitors for this type of behavior and flags it as crypto mining. One sunny day, their infrastructure was gone, and their account was locked. They spent the next week working ~18 hours a day to move to AWS.” - Ray Epps
In summary, one of the significant challenges of Serverless Architecture is vendor lock-in - it’s not possible to run the same function with different providers and any migration will require some degree of reconfiguration.
(6) Edge Computing Architectural Style
Edge computing represents an evolution of cloud computing and a variation of the serverless architecture. It brings data and computational power closer to the sources of data production, as well as to the applications and users that consume it, significantly reducing bandwidth and response times.
However, contrary to popular belief, 'speed' is not the primary benefit of adopting this architectural style; rather, it’s compliance.
“Today, I’m convinced that we were wrong when we launched Cloudflare Workers to think of speed as the killer feature of edge computing, and much of the rest of the industry’s focus remains largely misplaced and risks missing a much larger opportunity. I'd propose instead that what developers on any platform need, from least to most important, is actually: Speed < Consistency < Cost < Ease of Use < Compliance.” - Matthew Prince, Co-founder & CEO of Cloudflare
One significant advantage of edge computing is that sensitive data never has to leave the 'edge'—the physical area where it is collected. This is particularly beneficial in light of increasing country specific compliance regulations regarding their citizens’ personal data.
(7) Peer-to-Peer Architectural Style
It can be argued that the foundational concepts of Peer-to-Peer (P2P) computing—decentralized communication and resource sharing directly between devices—were envisioned early on in the discussions about software systems and networking. In fact, these ideas are mentioned in RFC 1, 'Host Software,' by Steve Crocker, and echoed in Tim Berners-Lee’s vision for the World Wide Web.
However, it was the rise of the file-sharing application Napster in 1999 that catapulted P2P into the public consciousness—not only for its innovative approach to sharing music files for free with strangers but also for the ensuing legal controversies.
The relevance of this architectural style is likely to surge again with increasing discussions on network neutrality, distributed Machine Learning, and distributed social networks.
Choosing the Best Architectural Style for You
When selecting the best architectural style, start by considering the specific business outcomes you aim to achieve. There is no one-size-fits-all approach to building a software system; it always hinges on your particular application. Evaluate the trade-offs of each decision and the potential benefits to your design.
An immutable truth in system design is its inherent mutability and continuous evolution. Always aim to refine and improve your architecture as your organizational needs shift, the IT landscape evolves, and the capabilities of your providers expand.
For a complete deep dive into these architectural style check out “Six Modern Software Architecture Styles”
Top comments (0)