The advent of microservices has disrupted the existence and architecting for SOA. Although microservices and SOA are similar things, as both are service oriented, there are some subtle technical differences in architecture and their implementation. With the high usage of cloud-based applications, DevOps processes, and agile methodologies, it's becoming more common, and rather natural, to follow the microservices approach.

Certainly, many of the techniques used in microservices come from the experiences of the development community in SOA and DDD. According to some pundits, microservices architecture is a form of SOA, and it is also referred to as SOA done right. Microservices has principles and patterns of service orientation around business capabilities, independent and autonomous, bounded-context, event-driven and more, all of these have roots in SOA and DDD.

In SOA, all organizations tend to follow a certain theme, standards, and programming languages with conventions uniformly all across pieces of code. On the other hand, in microservices, each microservice package is independent--it can use its own programming language, its own configuration, and data (SQL, NoSQL), which is common only across its team. Two microservices packages can be implemented entirely differently using different implementation technologies while having a common way of exposing and consuming the service interfaces.

In SOA, heavy focus is on centralization, and therefore, inclusion of a certain Enterprise Service Bus (ESB) is inevitable. A specific ESB brings its own set of ontologies and conventions. In microservices, the focus is on decentralization in the form of completely independent components designed for failure situations independently. Microservices are sometimes even referred to as an ESB anti-pattern.

In SOA, centralized governance often inhibits change, while in microservices, each service package is its own owner, that is, completely autonomous.