Microservices and software oriented architecture (SOA) are two componentized architectures for software development. As the cloud computing era has gained steam, the more highly granular microservices architecture (MSA) has evolved from the earlier SOA. Yet both approaches remain widely used. Where SOA is enterprise-focused, microservices is application-focused.
First we'll look at each of these technologies, then we'll compare and contrasts the two.
Understanding Service Oriented Architecture
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 the best choice for integrating disparate systems in a large mixed environment running multiple OS, such as Linux and Windows.
In microservices, on the other hand, 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 in the forefront of the design.
Microservices work better for building small, well 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:
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 granual 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.
SOA and microservices both rely on services as their main component, yet the two architectures differ considerably around service characteristics.
SOA defines 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.
In contrast, MSA defines only 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.
Middleware vs. APIs
SOA's middleware provides many capabilities absent from the API's used for communications between service providers and consumers in MSA.
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 the best architecture for large and complex enterprise systems.
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.
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." 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.
A major tenet of SOA is contract decoupling, which provides the highest degree of decoupling between service provider and consumer.
MSA, however, doesn't support contract decoupling.
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 a microservice application moves 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.
SOA and MSA both provide support for Web services. In fact, some but not all MSA microservices can be characterized as Web services.
Like Web services, microservices are agnostic to 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 Queing 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.
SOA's ESB can present a single point of failure (SPOF) for the entire system. If one service slows down, the the ESB can become overwhelmed by requests for that service.
MSA is more fault tolerant. For example, a memory leak is one microservice will only impact that specific microservice. Other microservices will be able to keep on handling requests.
SOA is multi-threaded, with more overheads to handle inputs/outputs (IOs).
MSA is single-threaded. However, microservice architectures typically include an event loop for handling I/Os.
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 which 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 which 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: offering access through resources, representing resources through representations, exchanging self-descriptive messages, and connecting resources through links.
- Middleware: Middleware is a layer of software residing outside of the OS providing services to applications which can't be obtained through the kernel. It supplies uniform, high-level interfaces for building applications which 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.