People often get mixed up between microservices and SOA; after all, the argument goes, microservices look like SOA, walk like SOA and talk like SOA. But there is an important distinction—microservices are more agile and independent than SOA. We will explain why here.
In our previous blog in this series on microservices, we saw how microservices evolved as the new, agile and flexible approach to enterprise development. But what we kept hearing was: “Aren’t microservices simply a new way to market a correct implementation of SOA?”
Not really, but SOA and microservices do share a common pattern. Both are based on the concept of a service, and both ideally separate the interface exposed to a caller from the implementation. However, microservices apply a practice that is neither defined nor enforced by SOA. In essence, both represent the construct of an Application Programming Interface (API) within the context of a larger system.
The main difference is that a microservice employs a practice that attempts to eliminate any dependencies on other microservices. SOA does not make this practice explicit as a requirement; it is left as an implementation detail. Suppose a developer builds a Web service that does a credit check based on a customer's social security number and some other basic information. In order for that particular service to function in an SOA-style implementation, it may invoke a chain of dependent services. With the microservices style, you would try and avoid forming those dependencies.
One of the things a developer should do when creating a microservices architecture is to set some finite rules. One rule should be that each particular part of the system, the discrete functionality, is autonomous, meaning that it functions all by itself. It has its own persistence, its own interface and supports its own wire level protocols.
The only way that one microservice should ever speak to another microservice is through a common network protocol, such as REST. SOA, by contrast, does not go so far as to dictate the implementation approach. In an SOA, it is left up to the system designer to decide whether those service chains should be called internally, in process or through a network protocol. Here again, microservices offers a more specific approach to building an SOA.
Are microservices, as some have argued, simply a way of “finally getting SOA right?” No: Microservices are a subset of SOA and apply some additional rules. It is the adherence to those rules that gives microservices their own unique “mission” in application development and enterprise architecture. In the final installment we’ll examine the fundamental kind of change needed within an organization to be successful at microservices.