If you work in IT or the cloud computing field, you’re probably aware of the service-oriented architecture (SOA) versus microservices debate. After all, everyone is talking about microservices and agile applications these days.

At first glance, the two approaches sound similar, and in some ways, they are. Both involve cloud or hybrid cloud environments for agile application development and deployment, and both can scale to meet the speed and operational demands of big data. Both break large, complex applications into small, flexible components that are easier to work with. And both differ from a traditional, monolithic architecture in that every service has its own responsibility.

However, even with these key commonalities, a closer examination of the two approaches reveals important differences.

Service-oriented architecture (SOA) is an enterprise-wide approach to software development of application components that takes advantage of reusable software components, or services. In SOA software architecture, each service is composed of the code and data integrations that are required to run a specific business function — for example, checking a customer’s credit, signing into a website or processing a mortgage application.

The service interfaces provide loose coupling, which means that they can be called with little or no knowledge of how the integration is implemented underneath. Because of this loose coupling and the way the services are published, development teams can save time by reusing components in other applications across the enterprise. This is both a benefit and a risk. As a result of the shared access to the enterprise service bus (ESB), if issues arise, it can also affect the other connected services.

XML data is a key ingredient for solutions that are based on SOA architecture. XML-based SOA applications can be used to build web services, for example.

SOA emerged in the late 1990s and represents an important stage in the evolution of application development and integration. Before SOA was an option, connecting a monolithic application to data or functions in another system required complex point-to-point integration that developers had to re-create for each new development project. Exposing those functions through SOA eliminates the need to recreate the deep integration every time.

SOA provides four different service types:

1. Functional services (that is, business services), which are critical for business applications.
2. Enterprise services, which serve to implement functions.
3. Application services, which are used to develop and deploy apps.
4. Infrastructure services, which are instrumental for backend processes like security and authentication.

Each service consists of three components:

1. The interface, which defines how a service provider executes requests from a service consumer.
2. The contract, which defines how the service provider and service consumer should interact.
3. The implementation, which is the service code.

SOA services can be combined to create higher-level services and applications.

Like SOA, microservices architectures are made up of loosely coupled, reusable, and specialized components that often work independently of one another. Microservices also use a high degree of cohesion, otherwise known as bounded context. Bounded context refers to the relationship between a component and its data as a stand-alone entity or unit with few dependencies. Rather than being adopted enterprise-wide, microservices typically communicate via application programming interfaces (APIs) to build individual applications that perform a specific business functionality. This approach makes them more agile, scalable, and resilient, especially for specific areas of the business. Typically, Java is the programming language of choice to develop Microservices. Other programming languages may also be used, such as Golang and Python.

Microservices are a true cloud-native architectural approach, often operating in containers, which make them more scalable and portable for the creation of independent services. Teams can use microservices to update code more easily, use different stacks for different components and scale the components independently of one another. This approach reduces the waste and cost that is associated with having to scale entire applications because a single feature might be facing too much load. Because of their independence, microservices produce services that are more fault-tolerant than the alternatives.

Check out the following video for more information on microservices architecture:

The main distinction between the two approaches comes down to scope. To put it simply, service-oriented architecture (SOA) has an enterprise scope, while the microservices architecture has an application scope.

Many of the core principles of each approach become incompatible when you neglect this difference. If you accept the difference in scope, you may quickly realize that the two can potentially complement each other, rather than compete.

Here are a few use cases where this distinction comes into play:

In SOA, reusability of integrations is the primary goal, and at an enterprise level, striving for some level of reuse is essential. Reusability and component sharing in an SOA architecture increases scalability and efficiency.

In microservices architecture, creating a microservices component that is reused at runtime throughout an application results in dependencies that reduce agility and resilience. Microservices components generally prefer to reuse code by copying and accepting data duplication to help improve decoupling.

The reusable services in SOA are available across the enterprise by using predominantly synchronous protocols like RESTful APIs.

However, within a microservice application, synchronous calls introduce real-time dependencies, resulting in a loss of resilience. These dependencies may also cause latency, which impacts performance. Within a microservices application, interaction patterns based on asynchronous communication are preferred, such as event sourcing, in which a publish/subscribe model is used to enable a microservices component to remain up to date on changes happening to the data in another component.

A clear aim of providing services in an SOA is for all applications to synchronously obtain and alter data directly at its primary source, which reduces the need to maintain complex data synchronization patterns.

In microservices applications, ideally, each microservice has local access to all the data it needs to ensure its independence from other microservices — and indeed from other applications — even if this means some duplication of data in other systems. Of course, this duplication adds complexity, so it must be balanced against the gains in agility and performance, but this is accepted as a reality of microservices design.

• Communication: In a microservices architecture, each service is developed independently, with its own communication protocol. With SOA, each service must share a common communication mechanism that is called an enterprise service bus (ESB). SOA manages and coordinates the services that it delivers through the ESB. However, the ESB can become a single point of failure for the whole enterprise, and if a single service slows down, the entire system can be affected.
• Interoperability: In the interest of keeping things simple, microservices use lightweight messaging protocols like HTTP/REST (Representational State Transfers) and JMS (Java Messaging Service). SOAs are more open to heterogeneous messaging protocols such as SOAP (Simple Object Access Protocol), AMQP (Advanced Messaging Queuing Protocol) and MSMQ (Microsoft Messaging Queuing).
• Service granularity: Microservices architectures are made up of highly specialized services, each of which is designed to do one thing very well. The services that make up SOAs, on the other hand, can range from small, specialized services to enterprise-wide services.
• Speed: By using the advantages of sharing a common architecture, SOAs simplify development and troubleshooting. However, this also tends to make SOAs operate more slowly than microservices architectures, which minimize sharing in favor of duplication.
• Governance: The nature of SOA, involving shared resources, enable the implementation of common data governance standards across all services. The independent nature of microservices does not enable consistent data governance. This provides greater flexibility for each service, which can encourage greater collaboration across the organization.
• Storage: SOA and microservices also differ in terms of how storage resources are allocated. SOA architecture typically includes a single data storage layer that is shared by all services within a given application, whereas microservices will dedicate a server or database for data storage for any service that needs it.

For some organizations, SOA architecture is a stepping stone to replace the monolith, providing a more flexible and agile environment. SOA services can be developed and used in a large environment, but they do not address specific needs of individual businesses that want to address business processes within their purview. DevOps can be used to help an organization transition from SOA architecture to microservices to address specific needs.

Architectural styles have their advantages, so how can you determine which one works best for your purposes? In general, it depends on how large and diverse your application environment is.

Both SOA and microservices can use automation to speed up business processes. Larger, more diverse environments tend to lean toward service-oriented architecture (SOA), which supports integration between heterogenous applications and messaging protocols via an enterprise-service bus (ESB). Smaller environments, including web and mobile applications, do not require such a robust communication layer and are easier to develop by using a microservices architecture.

Some will point out that the SOA vs. microservices debate is much more complicated, and that’s true. There is a great deal more to it. For a more detailed technical explanation of these nuances, we encourage you to delve into the SOA and microservices Learn Hub articles, which provide a great deal of in-depth information. However, from a business perspective scope is the crucial distinction.

• What are Microservices?
• What is SOA (service-oriented architecture)?
• Agile versus Waterfall

To learn more about how to build agile applications, download your free copy of the Agile Applications Architecture ebook.