3 situations where SOA may be preferable to microservices

Many people consider microservices to be the latest evolution of service oriented architecture. A microservice oriented architecture is a next-gen SOA, it is argued.

But the two architectures aren't necessarily the same thing, argues Mark Richards, in a new ebook, Microservices vs. Service Oriented Architecture. As this title suggests, Richards dissects the mechanics behind the two philosophies, noting that microservices do build upon SOA, but there are some missing pieces.

(NGINX, an open-source scalability provider, is offering copies of the book for free download. Richards is a software architect specializing in microservices and SOA.)

Here is the main point of distinction between microservices and traditional SOA, as pointed out by Richards:

"One of the fundamental concepts to remember is that microservices architecture is a share-as-little-as-possible architecture pattern that places a heavy emphasis on the concept of a bounded context,whereas SOA is a share-as-much-as-possible architecture pattern that places heavy emphasis on abstraction and business functionality reuse."

As we all know, SOA has taken its fair share of knocks in recent years, often viewed as techno mega-projects that delivered precious little return to businesses. In this view, SOA itself is seen as bloated and monolithic -- precisely the same qualities of the applications it was intended to replace.

Microservices are more granular and less monolithic than traditional SOA. They are lighter and faster to implement, and are not dependent upon formal, slow-moving, industry-driven specifications -- they instead are constructed via APIs and HTTP.

However, as Richards explains, microservices do "lack some of the core capabilities provided by a SOA." The gist of it is, the bigger the infrastructure, the more likely SOA is a better fit. He outlines some areas where full, traditional SOA may serve applications better:

Contract decoupling: Contract decoupling enables services and service consumers to evolve separately, but still maintain a contract. "Things tend to get a bit more complicated when the data sent by a service consumer differs from the data expected by the corresponding service," says Richards. SOA keeps data aligned. "Microservices architecture does not support contract decoupling, whereas contract decoupling is one of the primary capabilities offered within a SOA," says Richards. "If you require this level of abstraction in your architecture, you will need to look toward a SOA solution rather than a microservices one for your application or system."

Hetergensous interoperability: SOA is better suited for integrating with multiple heterogeneous systems and services, Richards says. "The microservices architecture style attempts to simplify the architecture pattern and corresponding implementations by reducing the number of choices for services integration."

Enterprise application scope:"SOA is well-suited for large, complex, enterprise-wide systems that require integration with many heterogeneous applications and services. It is also well-suited for applications that have many shared components, particularly components that are shared across the enterprise." Microservices, which lack messaging middleware, are "better suited for smaller, well-partitioned web-based systems rather than large-scale enterprisewide systems."