‘Microservices is an extension of SOA’. ‘Micro-services is SOA done right’. ‘Micro-services architecture is a specialization of SOA.’…Today there is much discussion on the relationship (or the lack of it) between Micro-services and SOA, and how different Micro-services really is from the more traditional SOA. Much of the information surrounding these two software architectures only manages to confuse the mind further. On the surface, one seems to have evolved from the other. Given varying viewpoints, it makes sense to take a deeper dive into these architectures to try to gain a clearer understanding. However, before defining the differences, let’s first understand what these two architectures mean and what they stand for.
What is SOA?
SOA, an acronym for Service Oriented Architecture, is essentially a collection of services that communicate seamlessly with one another. The services are loosely coupled. This allows the developers to build applications by composing one or more service irrespective of the underlying implementations. Since IT infrastructure is heterogeneous and spread across operating systems, system software, application infrastructure, it can be a challenge for organizations to build new infrastructure from scratch for applications that are running current business processes. Considering businesses need to respond to market demands with agility, they need to ensure that the existing infrastructure investments can be leveraged to address new business demands. This helps the application grow organically, and at a rapid rate. SOA integrates multiple large components to form an interoperable suite. The focus here is on business services and how to make them reusable by building them on top of large monolithic applications. This achieves more flexibility and scalability. SOA can be used to easily upgrade services or add functionalities to an existing application to address changing business demands. This also helps to safeguard IT infrastructure investments because of service granularity.
What is Microservices?
We had recently written a blog on why Micro-services is rising up the popularity charts which covers the basics of Micro-services. In a nutshell though, Micro-services is an architecture where complex applications are made up of smaller and independent processes that communicate with each other using language agnostic API’s. In this architecture, applications can be built, tested and even deployed independently of one another. This enables faster iteration cycles, reduces the amount of code that needs to be written, and promotes easy application maintainability. Micro-services has a decoupled design and as such avoids synchronous dependencies which make the application more resilient.
SOA and Micro-services – what’s the difference?
While the definitions of SOA and Micro-services are deceptively similar as both are aligned from the aspect of granularity, despite the similarities these two architectures do have some clear differences. Torsten Winterberg, SOA expert and founder of SOA Systems Inc. succinctly describes the essential difference between the two as, “Microservices are the kind of SOA we have been talking about for the last decade. Micro-services must be independently deployable, whereas SOA services are often implemented in deployment monoliths. Classic SOA is more platform driven, so microservices offer more choices in all dimensions.”
Services contained in Micro-services are often smaller, standalone, and follow the Single Responsibility Principle when compared to SOA designs. A service in Micro-services usually has a singular responsibility, a single task or a single domain while a service in SOA may have many responsibilities and hence can be harder to evolve. Micro-services is also leaner and more agile in its approach when compared to SOA as SOA generally uses heavyweight technologies and protocols such as SOAP.
Microservices relates more to the application architecture and focusses on building an ‘application’ while SOA is more of an enterprise-level concept that believes in componentization via services. Here services become the mechanism that binds the needs and capabilities by organizing a framework that is separate from the action itself. SOA breaks up a business application into major sets of business logic and develops each logic as a separate application that is integrated later. SOA employs a central governance model to allow application interoperability. Microservices is more task-oriented and builds an application by first breaking up the application components into smaller task-oriented services and focuses on decentralized governance.
Finally, the goals of SOA and Micro-services are different. The goal of SOA is to ensure that applications can interoperate easily while Micro-services focuses on deploying new features and scale applications faster by physically breaking down the application into specific modules.
Having pointed out the differences between the two, it would be irresponsible not to reiterate that both these architectures share many principles – independent scalability, independent life cycle, and independent data for starters. What essentially separates the two are the separation of concerns within the context of the application, as developers must deal with architecture complexity and distributed systems in both.
Software development has always been about the endurance of great concepts and their subsequent reinventions. Micro-services is an example of convergent evolution of SOA that stemmed from the changing modern day development methodologies, increased focus on testing and faster deployment needs. So, while Micro-services and SOA might be different architecture styles, they share many characteristics and are focused on making development teams more productive, build robust applications, reduce costs and reduce the time-to-market. Choose what is most appropriate for your business need, and if the information in this post helps you in making that choice then do let us know!
