Are Microservices The Same Old SOA?

Are microservices the same old SOA (Service Oriented Architecture)? Isn’t it just a rehash of the SOA hype? Let’s discuss the similarities and differences.

While microservices and Service Oriented Architecture (SOA) are two architecture patterns that deal with services, they have some differences. In fact, despite all the attention you see being given to microservices there are a couple use cases where SOA is the better choice.

So What Is a Microservice?

A microservice a stand-alone process that communicates with its clients using a lightweight mechanism, usually HTTP. Its datastore is a database of some sort. The service is the only application that interacts with its datastore. So let’s say for example you have a CustomerService that reads from and writes to the CUSTOMER table and any related child tables. Only the CustomerService performs SQL actions on those tables; any other services that do something with Customer information must go through the CustomerService using its published interface.

When implemented in Java or any other JVM language, a microservice is usually a JAR file that is launched by running java -jar CustomerService-1.0.0.jar. It has an embedded HTTP server and servlet container, usually Tomcat or Jetty for JVM-based services. Think of it as a Tomcat, JBoss or WebSphere server with one application running in it. Each other service is a JAR file invoked with java -jar, or an EXE file in the case of a .NET service.

Now you may think having several microservices, each with their own copy of an application server is a bit of wasteful duplication. Moreover, being compelled to use the HTTP protocol is a performance penalty due to its additional overhead. Well, yes there is some truth to that. But what you gain is the ability to deploy changes quicker. From an operational perspective, there is far less risk in deploying a stand-alone JAR file than deploying a WAR or EAR file to a centralized Tomcat, JBoss, WebSphere, etc. instance that is hosting a dozen other applications. In larger organizations this can great simplify the internal procedures and reduce the number of approvals needed for a deployment, giving the ability to deploy more frequently.

Having many of these stand-alone processes running does introduce additional complexity from an operational perspective. But if an organization is able to handle and manage this complexity, the benefits are simpler individual deployments, thus allowing a faster response to business change.

So What’s The Difference?

Mark Richards is the author of the O’Reilly book Microservices vs. Service Oriented Architecture, released in November 2015. He does a great job highlighting the similarities and differences between these two patterns. He summarizes them quite succinctly:

SOA is built on the concept of a share-as-much- as-possible architecture style, whereas microservices architecture is built on the concept of a share-as-little-as-possible architecture style.

Architectures based on SOA share infrastructure components such as the runtime environment, database connection pools in some cases, and email services. They often also share business services as much as they can, so our CustomerService may be shared by not just the Customer Management system, but the Warehouse Management and Order Fulfillment Systems too.

The drawback comes when you need to make a change. Suppose you need to modify the CustomerService as part of adding new functionality to Warehouse Management? With this tighter coupling now you have to assess the impacts to Customer, Warehouse and Order Fulfillment, test all of them to ensure you’ve thought of everything, have back out plans in place, and on and on.

With a microservice-based architecture, our CustomerService is broken up into three separate variations, each serving a specific domain. This is the notion of bounded context, where there is a CustomerService from the Warehouse perspective another from the Order Fulfillment perspective, etc.

So given these three different CustomerServices, and that each has its own datasource representing its perspective of a Customer, how do we maintain consistency? How do we ensure a change to a customer’s name is propagated to the other two CustomerServices? Transactions in the typical database sense are difficult to implement across multiple distributed services. Many microservice architectures solve this by adopting Eventual Consistency. Using this technique, when one CustomerService updates some information, it notifies its siblings and they update their respective datastore accordingly. Chris Richardson has a great explanation of this in his blog entry titled Event-Driven Data Management for Microservices.

About Those Use Cases Favouring SOA

I mentioned earlier microservices typically communicate using JSON over HTTP. Microservices use a homogenous interface. Where SOA shines is where services need to collaborate, but they use different payload structures or transport mechanisms. For example, one services uses JSON but its collaborator used SOAP. Or one speaks HTTP but the other expects Java Messaging Service (JMS). With an SOA pattern to your architecture, you have a piece of middleware to handle these differences. It can be Apache Camel, Spring Integration, or a full-blown solution like an ESB. It would have a component that transforms JSON from the calling service to the SOAP expected by the called service. Or another component that will take an incoming HTTP call and call the target service using JMS. Often large organizations with services developed over many years with many different interfaces will find SOA a more compelling alternative.

Summary

Microservices are stand-alone processes having a homogenous interface that use their own embedded HTTP server to exchange JSON or XML payloads with their clients. They have a finer level of granularity than their SOA counterparts. An SOA architecture may be suitable for organizations with an extensive catalog of services with a heterogenous set of interfaces. But the loose coupling of microservices make them a compelling choice for organizations that can accept the extra complexity they entail.