Microservices vs SOA: What’s the Difference?

Microservices have been trending upwards for several years at this point. This makes sense, given that the most notable microservice success stories belong to the biggest tech behemoths in the game — Netflix, Amazon, Uber, and eBay.

By adopting microservices, those Big Tech firms were suddenly much more agile. As a result, they could scale up faster by ramping up deployment speed and release frequency. Seeing that potential play out in the public sphere has inspired developers to decouple their monolithic applications and make the migration to the cloud.

Microservices’ predecessor, service-oriented architecture (SOA), didn’t fare quite so well. SOA, like microservices, aimed to free organizations from the issues caused by monolith applications. However, without the tools and established best practices we have today, SOA was largely written off as a failure.

In this article, we’ll look at service-oriented architecture vs. microservices and discuss how SOA’s reputation as a massive failure isn’t really accurate.

If this is the first time you’ve encountered the whole SOA vs. microservices debate, we recommend checking out our microservices overview first.

Otherwise, read on to learn more about the similarities and differences between SOA and microservices.

Service-Oriented Architecture vs. Microservices: SOAs Often Get Stuck with a Bad Rap

When SOA burst onto the scene in the 1990s, it was considered a revolutionary innovation.

Then later, when microservices appeared, developers were skeptical, and many critics felt compelled to define the key differences between the two architectures, leaning into that human tendency to categorize the unfamiliar.

As such, developers began comparing the two — SOA architecture vs. microservices — that led to a widespread resistance to microservices. After all, SOA failed to fix all of the problems it promised to address.

In all honesty, SOA was a scapegoat. The truth is, the main problem facing SOA architecture was people. Or rather, mistakes made by people during the implementation process, some of which include the following:

• Failing to align services to business objectives
• Adopting SOA before making sure the culture could handle it. (Our informative whitepaper Making Microservices Work for Your Organization digs into why culture is one of the most important pieces of any DevOps strategy).
• Moving forward without the blessing from the C-Suite — again, culture.
• Implementing an SOA strategy before gaining an understanding of the complexity and scope at play when you’re using a distributed application.
• Working without a strategic plan in place.

These examples are only a small percentage of the reasons why so many SOA initiatives failed.

However, the idea of loosely coupled applications made up of multiple function-oriented services is fundamentally sound.

Over the years, developers have been continuously making refinements to this idea, culminating in a rebrand under the buzzword “microservices.”

The reality is, microservices are a form of SOA architectures, and as such, have more in common than you might initially assume. But, the connection shouldn’t factor into your decision to adopt microservices. After all, it doesn’t make a whole lot of sense to base that decision on the technical capabilities of the systems available in the 1990s. That’s like avoiding mobile tools because they weren’t all that reliable ten years ago.

Microservices today are a product of the lessons learned from every SOA success and failure. Developers and architects were able to take those lessons and use them to fine-tune microservices to the point that they can make good on the promises SOA couldn’t keep.

What is SOA?

SOA or service-oriented architecture, is an architectural design style made to break monolithic applications into a series of smaller modules applied to specific business objectives.

If you’re thinking that SOA sounds a lot like microservices, you’re absolutely right.

However, SOA modules aren’t defined by their size.

Instead, they range from small application services to large enterprise services. SOA relies on messaging protocols such as (AMQP or SOAP) to communicate between services.

Why Did SOA Fail?

SOA was unable to fulfill its mission of addressing various issues associated with monolithic architectures.

In some aspects, SOA is a monolith. While, like microservices, SOA is made up of several smaller services, SOA architectures are still relatively coarse-grained with a high-level of dependency between services.

As such, SOAs are prone to many of the same issues you’ll find with monolithic architectures, including interdependencies that force application-wide rebuilds anytime developers make changes.

Also, communication in SOA passes through an enterprise service bus or ESB. An ESB promotes a monolithic structure, is characterized by slow communication speeds, and often ends up becoming a single point of failure.

Essentially, SOA didn’t provide significant enough improvements to deployment speed, issue resolution, productivity, and more to justify the risk.

Still, SOA paved the way for microservices and represent a stepping stone that took us from inefficient monoliths to the flexible, scalable architecture we have today.

What Are Microservices?

A simple definition of microservices is; a collection of loosely coupled, independently deployable services. Each service is designed to perform a specific task or function and contains all of the components necessary to carry out that function.

All services found in a microservice architecture are fine-grained and use language-agnostic APIs such as REST to communicate with one another. The benefit here is that developers can develop a service using the best language for the job, while APIs work behind the scenes to create a cohesive front-end experience for users.

That flexibility addresses many of the biggest issues associated with monoliths and SOAs — offering the rapid deployment, scalability, and fault resistance that SOA couldn’t manage to pull off.

How are Microservices and SOA Similar?

Service-oriented architectures are like microservices in that they’re both a collection of services focused on performing one specific function.

Both are smaller in scope than an entire monolith architecture, and both require an internal culture where decentralization and cross-functional collaboration are the norm.

SOA and microservices also give developers the freedom to work in whichever programming language they choose.

This allows them to choose the programming language best-suited for that service’s use case.

SOA vs. Microservices: Key Differences to Know

Microservices and SOA are both service-oriented architectures designed to resolve many of the problems associated with a monolithic architecture. While they have a goal in common, microservices and SOA have a long list of differences.

Here’s a quick comparison of SOA and microservices you should be aware of:

Data Storage

SOA is similar to monolithic applications in that they typically share a single relational database. As an application grows, its data characteristics and processing requirements can be heterogeneous.

At which point, a one size fits all data solution is no longer ideal. In contrast, in a microservices architecture, each service can utilize its own data store, allowing developers to choose the storage type that best meets the storage and processing requirements of the data being utilized by the service.

Size and Scope

Microservices focus on achieving one function and performing that function very well. As such, microservices tend to be much smaller in size and scope when compared to SOA services. This creates a major benefit when onboarding new talent.

Services are easy to understand and are independent. Therefore, new developers don’t need to understand the entire scope of all the applications. In contrast, SOA services can be composed of multiple functions with many interdependencies, a single database, and ESB. This requires new talent to understand not only the service but also the application interdependencies in full.

Communication

The way that microservices and SOA services communicate is also very different. Microservices communicate through language-agnostic protocols, typically over the network. While this increases the number of remote calls, and in turn overhead, it results in faster communication, with a high degree of fault resistance.

On the other hand, SOA communicates through an ESB. While this results in lower overhead, it does slow down communication. It also presents itself as a single point of failure with the potential to bring down all communication throughout the application.

Coupling and Cohesion

The reasons for the differences in coupling and cohesion are related to the size, scope, and communication differences presented above. Microservices feature extremely low coupling and high cohesion. They achieve this by focusing on a single business function, and because all of the components necessary to handle its function, messaging, and data storage (including the operating system required to deploy them) are encapsulated in a container. This results in services that can be independently built, deployed, and tested.

Another major benefit of microservices low coupling and independent design is that a failure in one service is unlikely to cause a failure elsewhere in the system. In addition, when errors do occur, it is simple to locate and isolate the source of the failure.

These features become extremely helpful at deployment time, as buggy updates can easily be rolled back, resolved, and redeployed.

SOA services are much larger in scope, have more interdependencies, and communication and data storage are handled outside the services. This requires the entire application to be rebuilt and redeployed, leading to slow deployment times and cascading failures.

SOA vs. Microservices in a Nutshell

What’s the Verdict: SOA vs. Microservices?

Ultimately, this service-oriented architecture vs. microservices idea doesn’t hold a lot of weight.

Microservices have come a long way in avoiding the issues that plagued SOA in the early days. But they have the advantage of technology that is leaps and bounds ahead of what was cutting edge in the 90s. And, of course, today’s developers can look back and learn from mistakes made by those who came before them.

That said, launching a microservices migration still carries many of the same cultural and planning requirements involved in rolling out an SOA initiative. Organizations considering adopting microservices must perform their due diligence before jumping in too soon.

3Pillar Global draws on deep experience in using microservices as an integral part of the digital products we create for our clients. Contact us today to learn more.
[adinserter name=”Microservices-Whitepaper”]