It is easy to mix up between microservices and SOA, as microservices look, walk and talk like SOA but there is a cruicial and important distinction. Microservices are more agile and independent than SOA. This blog intends to explain why.
Microservices gained prominence thanks to an article written by Martin Fowler in March 2014. In it he stated that "The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery."
Whilst talking to our customers the same thing would come up “aren’t microservices another way to market a correct implementation of SOA?” The answer is no, not really though SOA and microservices to share a common pattern. They are both systems that typically contain sets of loosely coupled distributed components. 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.