Service-Oriented Architecture (SOA) and Microservices Architecture (MSA) are known to be reliant on services, which happen to be their main component. However, soa architecture and microservices architecture are quite diverse in their characteristics, features and services. In this article, we intend to throw light on soa meaning, microservices meaning, main points of service oriented architecture vs microservices, etc. Before heading for the key features of soa microservices and their architecture, here’s a quick look at the comparative chart depicting soa vs microservices.
Microservices vs SOA
Basis of Differentiation |
SOA |
MSA |
Building approach |
SOA is based on the idea related to “share-as-much-as-possible” approach to architecture. |
MSA is based on the idea related to “share-as-little-as-possible” approach to architecture. |
Importance given to |
In SOA, more importance is given to business functionality reuse. |
In MSA, more emphasis is laid upon the “bounded context” concept. |
Governance and standards |
SOA is guided by common standards and governance. |
MSA has more relaxed governance. It lays greater focus on freedom of choice and people collaboration. |
Communication system |
ESB or Enterprise Service Bus is used or communication purposes. |
Simple and less elaborate messaging systems are put to use by MSA. |
Message protocols |
Supportive of multiple message protocols |
Supportive of lightweight protocols of the kinds of HTTP/REST & AMQP |
Platform |
A common platform is used for the purpose of all services deployed to SOA. |
In MSA, application servers are not used. Node.JS and other platforms are generally used. |
Single / multi threaded |
SOA is multi-threaded and contains more overheads for handling I/O. |
MSA is single-threaded in case of usage with event loop features for the purpose of non-locking I/O handling. |
Usage of containers |
The usage of containers such as Dockers and Linux Containers is not so popular. |
Containers are known to perform very well in case of MSA. |
Focused on |
Lays focus on the maximization of application service reusability |
MSA lays more focus on decoupling |
Type of database used |
Traditional relational databases are used very often. |
Modern and non-relational databases are put to use by MSA. |
Systematic change |
A systematic change needs modification of the monolith in SOA. |
A systematic change in MSA is needed to create a new service. |
DevOps / Continuous Delivery |
The use of DevOps / Continuous Delivery has started becoming popular but is yet to become mainstream. |
MSA lays a lot of importance on DevOps / Continuous Delivery. |
What is SOA?
Service-Oriented Architecture or SOA refers to a collection of services that communicate with one another. The communication may either involve simplistic data passing or may deal with dual/ more services coordinating certain activities. Basically, SOA provides a sound means of connecting services to enable high performance and better functionality.
SOA comprises of 4 basic service types these are:
1. Business services (Business users): These are coarse-grained services that are responsible for defining core business operations. The services are generally represented via Web Services Definition Language (WSDL), XML, Business Process Execution Language (BPEL), etc.
2. Enterprise services (Shared services team): These services implement the functionality as defined by other business services. In order to fulfil business requests, these services are reliant on infrastructure services and application services.
3. Application services (Application development team): These fine-grained services are specifically bound to any given application context. The services are capable of being invoked directly and via dedicated user interfaces.
4. Infrastructure services (Infrastructure services team): These services are responsible for the implementation of non-functional tasks of the likes of auditing, security, authentication, and logging. The services are capable of being invoked either from enterprise services or application services.
What is Microservices Architecture
Microservices Architecture or MSA refers to an architectural style that is useful for the purpose of structuring an application in the form of a set of small autonomous services. These services are generally modelled around business domains. In general, MSA possesses limited service taxonomy.
MSA comprises of two basic service types, these are:
- Functional services: These services are supportive of specific business operations. The accessing of services in their case is performed externally; they are not shareable with other services.
- Infrastructure services: Just as in case of SOA, infrastructure services in MSA are used for the implementation of tasks like logging, auditing and security. These services are veiled and not visible to the outside world.
Key differences between SOA and Microservices Architecture
The key differences between Microservices and SOA architecture can be discussed as follows:
1. Service Granularity: The service components present within any microservices architecture is capable of single-tasking and can perform any given task quite well. In case of SOA architecture, the service components may vary in size and range from small application services to really large enterprise services. It is commonplace to have service components within SOA that are represented by a subsystem or large-sized products.
2. Component Sharing: Considered to be an important tenet of SOA, component sharing pertains to what enterprise services refer to primarily. Component sharing is enhanced by SOA whereas MSA minimizes the sharing via “bounded context” that refers to the coupling of any single component as well as its data as one unit with minimal dependencies. As SOA is reliant on multiple services for the fulfilment of business requests, the systems constructed on SOA tend to be slower than that of MSA.
3. API layer versus Middleware: The microservices architecture possesses the API layer, whereas messaging middleware components are contained by a MSA. Many different types of capabilities are hosted by messaging middleware in case of SOA that are not found in MSA. These capabilities include message enhancement, mediation and routing, protocol transformation, simple messaging, etc. In case of MSA, there exists an API layer in between the service consumers and services.
4. Remote services: The SOA architecture is reliant on SOAP and messaging (AMQP, MSMQ) as its primary remote access standards/ protocols. On the other hand, most MSAs are dependent on two protocols –simple messaging (JMS, MSMQ) and REST; the standards/ protocols related to MSA are usually homogeneous.
5. Heterogeneous interoperability: SOA is responsible for propagating multiple heterogeneous protocols via messaging middleware component. In contrast, MSA make the architecture pattern simpler by decreasing the number of choices that are available for integration. In case several systems are to be integrated using various protocols in any heterogeneous environment, then SOA stands to be a better option. MSA serves to be a good choice if the systems have to be exposed and accessed via the same remote access protocol.
6. Coordination: Multiple groups have to be coordinated in SOA for creating business requests while there is negligible coordination among the services in case of MSA. In case advanced coordination is required among service owners then the same is possible via small-sized application development teams wherein the services can be developed, tested, deployed, etc. in a quicker fashion.
7. Contract decoupling: It is an important component of abstraction. Contract decoupling provides optimum levels of decoupling between the consumers and services. This feature is among the fundamental capabilities on offer by SOA; however, contract decoupling is not supported by MSA.
Conclusion
MSA serves to be the logical evolution of the features and benefit of SOA; it is designed to take care of modern businesses, related use cases, partitioned/smaller web based systems, etc. SOA is well-suited for complex and large business application environments that necessitate integration with different heterogeneous applications. The absence of messaging middleware serves to be an important factor that makes MSA unsuitable for complex environments.
MSA provides more control to developers. In case a number of business processes have to be coordinated, then SOA offers a better set of features and tools; as in the case of complex business environments and applications. Basically the choice between microservices vs soa is dependent on the application and the purpose it is meant to serve. So, what will you choose? MSA or SOA architecture?