AI-translated. Read the original in KoreanEmbedded slides, videos and images remain in their original language.
Comparing Software Architectures: Monoliths, SOA, and Microservices
CPO
When you hear “software architecture,” client engineers may first think of MVC, MVP, or MVVM, while server engineers may think of microservices. Others may think of Clean Architecture or event-driven architecture. I discussed how to define the term in Software Architecture: The Important Stuff, so I won’t revisit that here.
[caption id="" align="aligncenter" width="495"]
https://mherman.org/blog/developing-microservices-node-react-docker/\[/caption\]
Microservices are certainly a major trend. Companies such as Netflix and Amazon run them successfully, and many technically strong Korean companies have adopted them or are trying to. It can make you wonder, “Everyone else is doing this—are we falling behind?”
But as I said in the previous post, there is no universally correct answer, and microservices are no exception. Every choice involves trade-offs. We need to understand what microservices offer compared with other architectures. Many excellent articles already explore this, so this post offers a brief overview and comparison of a few architectural approaches.
Monolithic Architecture
Monolithic architecture is the standard counterpoint whenever the benefits of microservices are discussed. A monolith is a single large unit, with all functionality concentrated in one project. It is straightforward to set up and makes it easy to add features quickly early on. As complexity grows, however, feature development can slow and problems become more likely. It can suit lightweight proof-of-concept projects or projects at a very early stage.
Semi-Monolithic Architecture
This architecture is smaller than a single monolith, but functionality remains concentrated in a few projects. For example, a frontend and backend may be separate projects, while each remains a monolith.
“Semi-monolith” appears in some discussions, but doesn’t seem to be a widely established architectural term. Systems described this way could still be classified as monolithic. Even if an architecture is divided into more services than just a frontend and backend, it can still be considered monolithic if those services are themselves monoliths.
Service-Oriented Architecture
Service-oriented architecture was proposed to let multiple organizations share logic and data across applications. Unlike a monolith, it divides functionality into services that communicate through APIs.
The Enterprise Service Bus, or ESB, frequently appears in comparisons of SOA and microservices. The ESB was proposed as a lighter, common approach to communication compared with Enterprise Application Integration, but became increasingly heavyweight in pursuit of control and management, moving away from its original intent. As SOA became heavier, it drifted from the goals of quick adoption, agile development, and low integration costs, and lost momentum. Some distinguish SOA from microservices by whether services may share a database, but SOA’s broad definition leaves room for disagreement.
[caption id="" align="aligncenter" width="800"]
Because SOA is broadly defined, it is difficult to define it solely by the use of an ESB or a shared database. By definition, microservices can also be viewed as a form of SOA. Netflix and Amazon, often cited as microservices examples, called their systems SOA before “microservices” became a common term. Matt McLarty, co-author of Microservice Architecture: The O’Reilly Book, argues in Learn from SOA: 5 lessons for the microservices era that debating whether SOA and microservices are the same is less important than what we have learned from SOA.
Microservice Architecture
Microservices aim to maintain delivery speed and reliability even as a system grows rapidly. Sufficiently small services communicate to provide functionality. Some view microservices as a well-executed form of SOA; others see a substantial difference because “micro” explicitly calls for services smaller than those described in SOA.
Keeping services small and lightweight can make them clearer and easier to maintain. With a well-designed system, a failure in one service can have limited impact elsewhere, or be handled flexibly, helping avoid system-wide failures such as a single point of failure. Each service can be deployed and scaled independently, enabling quick feature releases and a flexible response to heavy traffic.
On the other hand, microservices increase structural complexity and add the maintenance cost of more services and their communications. A well-designed, sufficiently automated system is essential to manage that complexity.
Conclusion
Judgment and decisions need evidence. Sometimes, admittedly, you have to trust your instinct—perhaps when deciding that today’s lunch must be hangover soup. But without a persuasive case, it is difficult to get everyone charging toward the same goal. Choosing an architecture requires understanding the vision and the business, then making a decision and bringing the team along with reasoning grounded in those needs.
Buzzvil formed an Architecture Task Force to support faster, greater growth. The ATF is working to identify, design, and implement the architecture that best suits Buzzvil.
Characteristics of Buzzvil’s services:
- We offer multiple products, each requiring many features.
- Many capabilities are shared across products.
- Traffic requirements differ by service and feature.
- A system-wide outage creates many downstream problems.
- Particular events can cause large swings in traffic.
Given these characteristics of our products and business, we decided that microservices were the most appropriate architecture. We are now making changes on several fronts to benefit from microservices and reach our goals quickly and reliably.