From Buzzwords to Basics – Microservices vs. SOA

Buzzwords?

It is no exaggeration to say that everyone involved in software development over the last few decades has heard of microservices and Service-Oriented Architecture (SOA). While SOA was a prominent buzzword in the 1980s, it has since become a term to avoid. Microservices, however, remain popular and relevant; most major tech companies, such as Amazon, Netflix, Microsoft, Spotify, Uber, and PayPal, utilize them to varying extents.

However, these terms are often ambiguous and confusing, with many possible interpretations depending on whom you ask. This article aims to discuss the definitions and explore their interpretations to clarify and compare these concepts from various perspectives. Most importantly, it will address the following questions: Is there a “silver bullet,” an architecture that fits everywhere, or do all of these have their specific purposes and use cases? This is not an in-depth exploration but a stroll through the basics and various viewpoints.

Whether you're a developer or simply curious about software architecture, this article will provide valuable insights. You can also follow this discussion in our video:

Before undertaking all this, we must begin with the concept often cited as the bad example: the monolith.

The “m word”

The monolith is the ancestor of all software architectures, although it was almost certainly named retroactively when newer architectures emerged. While it is nearly a curse word, this article will demonstrate that it still has a place in software development.

Let’s see a simplified example of a monolith application structure!

This is an example of an application. The word “web” is in brackets because these applications tend to be “classic” desktop applications, though they can also be web apps. The point is that all services (account, inventory, shipping) are in the same code base and are typically connected to a central database. The code base is generally complex and difficult to understand, and the services are not sufficiently separated.

This structure has evident disadvantages:

• It is inflexible because even the most minor code changes require re-testing and re-deployment of the application.
• The components are not reusable unless you consider copying the source code as reusability.
• If one component lacks resources, the entire application needs to be scaled, which can result in resource wastage.
• The application's fault tolerance is limited; a single error will likely cause the entire application to fail, resulting in significant downtime and potential data loss.
• Adopting new technologies, such as frameworks and programming languages, can be challenging.

Given these disadvantages, software development shifted towards component-based architectures, including microservices.

Understanding Microservices

Let’s explore a comparable application structure that employs the microservices architecture principles!

The most crucial difference is that the application's services (account, inventory, and shipping) are moved to separate entities called microservices, each using its own database. Multiple frontends, like web and mobile applications, can exist, and a desktop application is also possible. A new, optional component named the API gateway acts as the primary proxy, responsible for connecting the frontends to the services and performing other vital functions such as collecting metrics, handling authentication and authorization, transforming data structures, and validating input. If multiple frontends exist (such as a web app and a mobile app), there may be another optional component called Backend For Frontend (BFF) that is responsible for formatting and aggregating data from the services.

This architectural style offers clear advantages:

• The components can be developed, deployed, and scaled individually.
• Different technologies can be used for the services, allowing for the selection of the best one for the task.
• The services can be reused in various applications if they are written in a sufficiently general way.
• The application's fault tolerance improves; the failure of one component does not necessarily bring down the entire application (it depends on the circumstances, but chances are good that only some functionality suffers).

So, is this the "silver bullet"? Does it solve all problems? Of course not.

Let’s explore some potential disadvantages:

• The development and deployment are often more complex.
• The more services there are, the higher the infrastructure costs, and the more challenging the testing and debugging become as they follow requests through many services.
• The lack of standardization can hinder troubleshooting, especially when the logging style or data structures are inconsistent.
• The HTTP calls and large JSON object transfers between services, authorizations, and permission checks can create overhead, resulting in application performance issues.

Stricter governance, often lacking in microservices applications, can help to mitigate some of these drawbacks. This brings us to our next topic: Service-Oriented Architecture (SOA).

Understanding the Service-Oriented Architecture

Emerging in the 1980s, Service-Oriented Architecture (SOA) defines a method for making software components reusable and interoperable through service interfaces. It represents more of an architectural style and an enterprise-wide concept.

To understand SOA, one must grasp what a service is. A service is a reusable software component that encapsulates the code performing the business logic and the data on which this business logic operates, creating a complete and discrete business function.

According to one of the many definitions of SOA, there are four properties of a service:

1. It logically represents a repeatable business activity with a specific outcome.
2. It is self-contained, meaning it has everything necessary to operate independently, although it still requires input from other services.
3. It is a black box for its consumers, so they do not need to know about the service's inner workings.
4. It might be composed of other services.

Services are the essential building blocks of a SOA. They can implement one or more of the following functionalities:

• Provider: creates, maintains, and offers one or more services,
• Consumer: requests a provider to execute a specific operation of a service, and
• Registry/discovery: a network-accessible directory of available services.

A service has the following features:

• An interface that defines how to invoke the service,
• A contract that defines the nature of the service. It may also specify terms and conditions (prerequisites, cost, quality of service, etc.), and
• An implementation, which is the code that builds the logic and can be written in any programming language.

The following are the most essential principles of a SOA:

• Interoperability means that systems and services work together, utilizing heterogeneous technologies and platforms.
• Decoupling means that changing one service does not affect others. It minimizes dependencies, facilitates reusability, and allows the composition of existing services into new applications.
• Abstraction hides the inner workings and complexity of the service by defining clear interfaces. Thus, it limits the exposure of sensitive information, which can enhance security.
• Granularity refers to the level of detail at which services are designed and implemented. Services can be either fine-grained or coarse-grained.
  • Fine-grained services are smaller and more specialized but may lead to overhead.
  • Coarse-grained services provide more functionalities, although they may not be as flexible or reusable as smaller ones.

There are two primary types of services: business (or application) services, which perform specific business functions, and infrastructure services, which are typically part of a centrally managed infrastructure component that handles functions such as authentication, event logging, and exception handling. Additionally, there is one more optional component, the Enterprise Service Bus (ESB), which performs several infrastructure-related functions, including data model transformations, various connectivity and messaging functions, routing, and converting between communication protocols. In recent SOA implementations, these functions may be performed using other technologies, such as REST, SOAP, MQTT, etc.

Let’s see a possible application structure using the SOA principles!

The differences between this and the microservices architecture version are significant, if not ground-breaking. The services can share a database, and a central infrastructure component (ESB, REST, SOAP, or MQTT) connects the components. The clients can be users (from browsers, mobile, or desktop apps) or other cloud service consumers.

This structure provides the following benefits:

• Faster time to market: Due to reusability, assembling new applications from existing services requires significantly less time.
• A typical use case for SOA involves leveraging legacy functionality, which means exposing services and capabilities from legacy systems.
• Improved collaboration between business and IT teams may lead to the distribution of services based on business terms.
• Parallel development: Features are isolated, allowing for independent development.

We have established the concepts of microservices and SOA; now it is time to compare and provide valid use cases for them.

Microservices vs. SOA: The Showdown

Reading this article, one might conclude that microservices and SOA are two sides of the same coin. While this is not far from the truth, significant differences exist, particularly concerning the scope and potential use cases.

Microservices represent an application architectural style centered around individual applications. In contrast, SOA, or Service-Oriented Architecture, is more like an integration architectural style and an enterprise-wide concept. Microservices are typically used to decompose a single application into smaller components, while SOA exposes existing applications and data from legacy systems through loosely coupled interfaces. Regarding storage, microservices maintain localized access to the data they need, whereas in a SOA, all components retrieve and modify data from a primary source.

Microservices utilize lighter messaging protocols like HTTP and REST, whereas SOA accommodates a broader range of heterogeneous messaging protocols, including SOAP and AMQP. Regarding service granularity, as illustrated in the figure above, microservices consist of highly specialized services optimized for a specific task. In contrast, services within SOA can range from small, specialized components to large, enterprise-wide applications. Because microservices reduce data sharing by emphasizing duplication, they can be faster, though this is not always guaranteed. SOA can significantly streamline development and troubleshooting, often at the expense of system speed. As previously mentioned, microservices generally lack consistent data governance, while SOA typically necessitates common data governance standards across all services.

Microservices and SOA both aim to decompose monolithic applications into smaller components. The main difference is that microservices use smaller components and may adopt various technologies. This architectural style is also more common in agile development and is characterized by independently developed components and cloud systems. In contrast, SOA mainly exposes data from legacy systems, creates independent and highly reusable services, and supports high data distribution, which refers to applications with multiple data sources. It has a broader enterprise scope, incorporating various messaging protocols that smaller organizations and simpler applications do not need.

An earlier question in this article was whether microservices are the "silver bullet." An example of the opposite is Amazon Prime Video’s Video Quality Analysis (VQA) story from 2023. They developed a serverless monitoring tool, initially based on a microservices architecture. During testing, they encountered many issues: the infrastructure costs were too high, and the transfer of video frames between components resulted in significant performance problems. They ultimately migrated back to a monolithic architecture, achieving a 90% reduction in operational costs.

Ultimately, it all depends on choosing the appropriate architecture for our applications. In summary, here are some guidelines for each architecture:

• Monolithic is suggested for simple applications, prototypes, or single-server solutions.
• Microservices thrive when teams plan to use different programming languages or frameworks, but they must possess the necessary skill set (cloud, APIs, containerization, troubleshooting). Additionally, teams must embrace the DevOps culture and mindset for this to succeed.
• SOA is ideal for legacy or enterprise applications, in a single application environment that uses multiple data sources. It is particularly beneficial when highly reusable services are essential or when there is a need to share functionality and/or data with external clients or partners.

What’s next?

Predicting the future is difficult, but trends can be observed in microservices and Service-Oriented Architecture.

For microservices, the rise of cloud technologies such as containerization and Kubernetes will continue. A new trend called Edge Computing (which means that devices in remote locations process data at the "edge" of the network, either by the device or a local server) is gaining traction. DevSecOps is becoming increasingly popular, which means that security is becoming an integral part of the CI/CD pipeline, along with automated security checks, threat detection, and risk assessments. With the rapid advancement of AI, related technologies such as AI-driven analytics, real-time dashboards, and anomaly detection will become more prominent. Serverless microservices create a new category called Function-as-a-Service (FaaS), while event-driven technologies like Kafka are also expanding. Lastly, the Zero Trust Security Model is an emerging trend for microservices, making applications more secure and less vulnerable.

Regarding SOA, it is gaining traction, with the lines blurring between "traditional" SOA and microservices as they adopt more cloud-native principles and containerization technologies. Like microservices, AI integration, and a notable shift towards event-driven infrastructures are trends that cannot be ignored. Additionally, there is a growing emphasis on compliance and governance. Lastly, new communication protocols are being created to facilitate easier communication between components and systems.

Summary

In conclusion, the architecture of an application should progressively adapt and evolve according to changing requirements. While monolithic architecture suits simpler applications, microservices offer flexibility and scalability for complex systems, provided the team possesses the necessary expertise. Service-Oriented Architecture (SOA) remains valuable for enterprise-level applications that require high data distribution and reusable services.

Does your organization lean towards a specific architectural approach? We invite you to join us for further discussions on this topic!