The concept of microservices vs. software-oriented architecture (SOA) is a debate that is largely settled.
To simplify, both microservices and SOA are technologies based on using modular, componentized design in software and system architecture, with the goal of producing an infrastructure that is more easily and efficiently updatable.
SOA was the earlier version of this concept, and was most popular before about 2010. But even as SOA has faded, its core concept – componentized architecture – is stronger than ever in microservices.
The trend is clear: while both microservices and SOA are componentized architectures for software development, as cloud computing has gained steam, the more highly granular microservices architecture (MSA) has evolved from the earlier SOA. Yet both approaches remain in use. Where SOA is enterprise-focused, microservices is application-focused.
First we’ll look at each of these technologies, then we’ll compare and contrast the two.
As microservices takes the lead over SOA in terms of componentized infrastructure, it is forecast to see rapid growth in the years ahead.
Service-Oriented Architecture: Componentized Communications
A SOA is a collection of services that use a messaging middleware component for communications between services. The middleware layer also supports interoperability of multiple protocols. Services can range in size all the way up to subsystems used enterprise-wide.
SOA is generally regarded as a technique for integrating disparate systems in a large mixed environment running multiple OSes, such as Linux and Windows.
Microservices: Using APIs to Build Small, Partitioned Services
In microservices, each application is structured as a collection of small services, modeled around a business domain. This architecture uses an application programming interface (API) layer instead of middleware, and protocols are lightweight. Microservices best practices requires developers to build with the API at the forefront of the design.
Microservices work well for building small, partitioned web-based systems which give considerable control to the developer. Each service is designed to fulfill a specific purpose – such as a web service for activating an order or providing shopping cart services – and to excel in delivering on that purpose.
Comparing Microservices vs. SOA
SOA and microservices both ease software development by replacing older monolithic structures with more easily manageable modular components. However, SOA and MSA differ markedly along lines that include general architecture, service characteristics, approaches to component sharing, database support, and more.
Here are some key differences:
General Architecture: Microservices vs. SOA
SOA defines both a provider layer, comprising all services within the system, and a consumer layer, or the point at which consumers such as human users or other services interact with the system.
The Enterprise Service Bus (ESB) allows for various point-to-point connections between service providers and service consumers. Services can be created by multiple development teams, but each team needs to be aware of the common communication mechanism.
In MSA, on the other hand, small, independent processes communicate with each other inside highly granular and agile applications. Each service is independently deployable, meaning that it can be shut down when not in use without impacting the entire system. MSA also makes it easier and faster to develop new versions of existing services, suiting this architecture well to DevOps best practices. Also, services can be scaled independently, depending on load requirements.
Service Characteristics: Microservices vs. SOA
SOA and microservices both rely on services as their main component, yet the two architectures differ considerably around service characteristics.Â
SOA’s four basic service types:
- SOA’s functional services, also referred to as business services, are coarse-grained services used for defining core business operations. Functional services are represented through protocols such as eXtensible Markup Language (XML) and Business Process Execution Language (BPEL).
- Enterprise services implement the functionality defined by business services, using both application services and infrastructure services to fulfill business requests.
- Application services are fine-grained services used only within the context of specific applications. Services can be invoked through a dedicated user interface (UI).
- Infrastructure services implement non-functional tasks like logging, authentication, auditing and security. These services can be invoked from either application services or enterprise services.
MSA’s two basic service types:Â
- In MSA, functional services support specific business operations. These services are accessed externally and are not shared with other services.
- As in SOA, MSA’s infrastructure services are used to support tasks such as logging, auditing, and security. MSA’s infrastructure services, though, are not shared with other services, and are only accessible internally.
Feature by Feature: Microservices vs. SOA
Again, microservices and SOA are conceptually similar, with key differences in how they achieve their end goals.
Middleware vs. APIs
SOA’s middleware provides many capabilities absent from the APIs used for communications between service providers and consumers in MSA.
The advantages of the middleware layer include protocol transformation, message enhancement, and mediation and routing. Because MSA doesn’t support middleware, and MSA applications are so small and specifically purposed, SOA is generally regarded as a better architecture for large and complex enterprise systems.
Database Support
In SOA, all services use the same underlying database. Services typically support traditional relational databases.
MSA is also more agile and flexible in this way. A database can either be dedicated to a specific microservice or shared among multiple microservices. MSAs are also more likely to use newer nonrelational databases. Unlike relational databases, which only support structured data, nonrelational databases also support semi-structured data such as emails and XML documents and unstructured data such as Microsoft Windows documents, web pages, social media messages, and video files.
Component Sharing
SOA is designed to promote business functionality reuse by enhancing component sharing. In fact, component sharing is the main role of SOA’s enterprise services. Services are often implemented as complete subsystems. However, because SOA uses multiple components to fulfill business requests, SOA services can be less efficient than microservices.
Microservices, on the other hand, minimizes component sharing through “bounded context.” That is, a component and its data are coupled as a single unit with minimal dependencies. An application is required to access a persistent data store via a service implementation-provided API.
Contract Decoupling
A major tenet of SOA is contract decoupling, which provides the highest degree of decoupling between the service provider and consumer.
MSA, however, doesn’t support contract decoupling.
Containers
Containers and microservices are a natural match. Containers such as Dockers and Linux Containers work quite well with microservices architectures but are used less frequently in SOA.Â
By encapsulating a lightweight runtime environment for applications, containers provide a consistent software environment as microservices applications move through the continuous development, testing, and deployment cycles of DevOps. Containers can be run on both virtual machines (VMs) and physical machines, and with high server utilization rates.
Web Services
SOA and MSA both provide support for Web services. In fact, some but not all microservices can be characterized as Web services.
Like Web services, microservices are agnostic in terms of programming languages such as Java, Perl, Ruby, and C++.
Remote Access Protocols
SOA architectures typically use Simple Object Access Protocol (SOAP) and messaging protocols such as Microsoft Message Queuing (MSMQ) and the open standard Advanced Message Queuing Protocol (AMQP) as their main remote access protocols. However, Representation State Transfer (REST) is sometimes used with SOA.
MSA generally uses the more streamlined REST API, together with AMQP messaging, for remote access.
Fault Tolerance
SOA’s ESB can present a single point of failure (SPOF) for the entire system. If one service slows down, the ESB can become overwhelmed by requests for that service.
MSA is more fault tolerant. For example, a memory leak in one microservice will only impact that specific microservice. Other microservices will be able to keep on handling requests.
Threading
SOA is multi-threaded, with more overheads to handle inputs/outputs (IOs).
MSA is single-threaded. However, microservices architectures typically include an event loop for handling I/Os.
Systematic changes
In SOA, a systematic change requires modifying the entire system.
In MSA, a systematic change can be accomplished by creating a new service.
Microservices and SOA Related Terms
- API: An API facilitates software development by providing a set of functions and procedures for accessing data or features of another application, an OS (operating system), or other software services.
- Web service: A Web service is an API that uses a standardized way of providing interoperability between applications for clients and servers over the web. A Web service communicates over Hypertext Transport Protocol (HTTP) using technologies which can include REST, SOAP, XML, Web Service Definition Layer (WSDL), and Universal Description, Description, and Integration (UDDI).
- RESTÂ API: A REST API is an API that follows the rules of REST, an architectural style now being used to replace older architectures such as SOAP as a simpler, faster method of accessing web services. The REST API uses Hypertext Transfer Protocol (HTTP) requests to indicate desired actions on the web. The main rules of REST are the four rules of uniform interface for clients and servers: 1) offering access through resources, 2) representing resources through representations, 3) exchanging self-descriptive messages, and 4) connecting resources through links.Â
- Middleware: Middleware is a layer of software residing outside of the OS providing services to applications that can’t be obtained through the kernel. It supplies uniform, high-level interfaces for building applications that can run interoperably across diverse systems and a set of common services for improving collaboration between applications. Used in SOA but not MSA, middleware hides the heterogeneity of OS, hardware, and protocols in addition to the complexities of distributed applications.
