Microservices vs. SOA: Choose the right app architecture (original) (raw)

This primer explains the ins and outs of a microservices vs. SOA architecture: when and where to use either one, and how both are evolving, thanks to containers.

The notion to create applications from a set of services is almost three decades old. The framework that launched it all, service-oriented architecture (SOA), now coexists with the more modern concept of microservices. For many, this coexistence often creates a question: Do microservices replace SOA, or do they have symbiotic missions? Let's look at how microservices and SOA work, what sets them apart and their evolving roles in enterprise app development.

What is a service-oriented architecture?

In a service-oriented architecture, services are components of business logic, designed to be woven into an application or an entire set of related applications. These services usually represent discrete applications and distribute transactions across multiple affected business functions. In most cases, a service bus (commonly, an enterprise service bus) distributes the work to SOA services, and a business processing language routes transactions to the proper services. These flows are transactional in nature and represent a change to a business condition and the databases that are associated with the conditions.

The final point on SOA is that the web services (WS) standards define specific APIs and models to build SOA applications. These are normally synchronous APIs with a high degree of complexity and overhead, but they focus on back-end work distribution so this doesn't affect the user experience.

What is a microservices architecture?

Microservices are an outgrowth of cloud computing -- in particular, the desire to create highly interactive user experiences that support a wide range of traffic volumes and offer resilience to maximize uptime. In a microservices architecture, each service is a small and specialized piece of logic. They are often stateless, which means nothing is stored internally between executions. As a result, any copy of a given microservice can process a request.

Microservices represent tasks, rather than complete business functions. Think of them as the framework to create highly interactive user experiences that involve ad hoc selection of a few components to run. A complete business function created from microservices might string together a considerable number of components; this likely creates latency troubles and diminishes quality of experience.

Microservices vs. SOA: Compare their major differences

How do SOA and microservices relate to modern application development and deployment? The best way to address this is to contrast them in four areas.

Scope . SOA extends companywide -- the services represent complete business functions, they're normally coupled to database access and update, and services are assembled by applying broad-scope transactions to all the applications they should impact. Microservices typically focus on an application or multiple applications, they offer more primitive functionality and their data usage more likely resides within each microservice.

Agility . SOA services' level of scalability and resilience depends on the relationship of the service to databases. It's possible to scale SOA services and to replace failed services, but the service must be designed to support these features. Database use can limit both scalability and resilience for SOA; in most cases, SOA services operate on entire transactions, so a failure or scale-in or scale-out occurs at the transaction level. Microservices, strictly interpreted, are largely stateless, so any copy of a microservice can process a request. This makes them far more agile than SOA services.

Hosting and deployment . SOA services are almost always persistent, meaning they load and run continuously. As a result, they can be deployed and redeployed with less priority on speed and agility. SOA operations tend to resemble traditional load-and-run IT on bare metal; although, it's possible to host them on VMs and containers. You can deploy microservices in a persistent way as well, but because they're regularly scaled and redeployed, the deployment process must be quicker and more flexible. Therefore, most microservices are either containerized or deployed as functions in a serverless/lambda hosting environment.

Process model . SOA almost always processes transactions that are routed to services and represent specific business functions. The service bus steers the transactions, and business process language logic governs which services are run. Microservices almost always process events, which might be pieces of a transaction or might simply be representations of some real-world condition. There is no specific model to compose microservices into an application; you can use API brokers or API gateways, as well as other models such as message queues to steer messages from sources to front-end destinations.

When to use microservices vs. SOA -- and how containers change the rules

SOA defines services as units of business logic, while microservices define components of low-level functionality. This basic contrast dictates how an organization uses either approach. SOA builds business IT from services that are largely transactional in nature; microservices builds interactive application elements that are largely event-based. The present focus on microservices is largely because a lot of enterprise development activity is a good fit for it: interactive application elements that run in the cloud, and the front-end or user interface portion of transaction processing and analytical applications.

SOA that strictly conforms to WS standards and uses enterprise service buses (ESBs) to connect components has unquestioningly declined as a portion of overall development. What's really happening, however, is that formal SOA/WS is giving way to a more open-API containerized application model. These new applications may use RESTful APIs instead of WS APIs, and API brokers or "storefront" front-end design patterns instead of ESBs, but inside they still represent business functions and transactions.

Meanwhile, a true microservices model with very small, stateless and independent functions can introduce too much overhead to use them extensively in high-volume transaction processing -- they generate significant latency as the workflow hops from component to component. Just as SOA is evolving to something more like containerized components, some microservices architectures are evolving from stateless functions with limited scope to something more like a component of business logic.

In real-world enterprise development, SOA services and microservices components are increasingly being subsumed into containers, and APIs and workflow management for both are adapting to modern container principles. The dominant services-architecture model is now componentization -- it's carrying both SOA and microservices along with it and, perhaps, finally converging them. This trend redefines the old microservices vs. SOA debate.