Microservices vs. Service-Oriented Architecture (SOA)
Microservices vs. Service-Oriented Architecture (SOA)
We take a look at two of the more popular architectural patterns in software, discussing the pros and cons of each and how they differ.
Join the DZone community and get the full member experience.Join For Free
Record growth in microservices is disrupting the operational landscape. Read the Global Microservices Trends report to learn more.
With increasing complexity and demand for highly scalable and robust applications, the conventional monolithic architecture is no longer the best choice. After a certain threshold, monolithic architecture tends to hinder application performance and scalability. Moreover, with an enormous codebase, making changes to the tightly coupled, dependent processes in the monolithic architecture drastically increases the impact of single process failure.
To deal with these limitations of a monolithic architecture, developers have adopted the Single Responsibility Principle coined by Robert C. Martin (co-author, Agile Manifesto), which says: Gather together those things that change for the same reasons and separate those things that change for different reasons.
Eventually, Service-Oriented Architecture (SOA) and microservices architecture gained acceptance and enabled developers to build applications as a suite of small, de-coupled services, running in their own environments that are independently deployable.
While microservices and SOA have application modularity in common, they differ in how the services are deployed and the size of modules. Before we discuss the fundamental differences between the two, let’s understand these architectures in detail.
Microservices: An Overview
Microservices is a software modularization approach that aims at dividing larger software systems into smaller components. With a microservices architecture, an application is built with an independent group of components that run each application process as a service. Such an architecture makes it easier for applications to scale, accelerate the software application development process, offers space for experimentation, and reduces time-to-market for new features.
Microservices Architecture: Benefits
- Continuous Development and Deployment: Each component in a microservices architecture is developed, deployed, operated, and scaled independently, i.e. a change in one service does not affect the functioning of other services. Moreover, these services do not share code or implementation with other services. This ensures continuous development and deployment of large, complex applications.
- Eliminates Technology Commitment: Microservices can be created using different technologies (frameworks, languages, or OS). Therefore, it eliminates any long-term commitment and dependability on a particular technology stack. While building a new service or updating an existing one, a new, better technology stack can be chosen.
- Improved Fault Isolation: Since all services in an application are independent of each other, any halt in a process does not affect another. For example, a memory leak in a particular service will not have any impact on another service, ensuring that rest of the services keep receiving and handling incoming requests. If this is compared to a monolithic architecture, a single misbehaving component affects the entire system.
Large Scale Websites Are Using Microservices Architecture
Realizing these benefits, organizations (such as Netflix) are moving from monolithic architecture to microservices. Netflix handles over a billion calls per day on their video streaming API, from over 800 kinds of devices. Each API call is then spread out to an average of six calls to backend services.
Service-Oriented Architecture (SOA): Overview
Similar to microservices, SOA is a software modularization approach. SOA is an architecture based on disparate services. Herein, a service is a well-defined, self-contained functionality. In the SOA architecture, different services communicate with each other to execute a function.
The SOA services are loosely-coupled, i.e. a service interacting with another might not know the technical details of another service. An SOA service consists of two fundamental components: a service consumer that requests a service and a service provider that returns the result of the request.
Since microservices and SOA enable developers to build an application by building independent services, they more or less share a similar set of benefits. However, there are some basic differences between the two, which we'll discuss shortly.
Large Scale Websites Are Using SOA
Realizing the benefits, large-scale e-commerce websites such as Amazon have migrated from a monolithic to Service-Oriented Architecture (SOA). Amazon calls 100-150 services to get the data that is used to build a web page.
Microservices vs. SOA
In both architectures, each service has a certain responsibility, unlike a monolithic architecture. Thus, developers have the flexibility to develop the services in different technologies, which enables the team to choose the most relevant use-case for their needs. However, both architectures differ in the following terms:
- Service Deployment and Scalability: The service deployment can be assigned and managed within multiple teams. However, each member of the team needs to know the common communication mechanism in SOA, which is not a dependency while building an application with a microservices architecture. In the case of microservices, the services can be operated and deployed independently, unlike SOA. Therefore, is it easier to deploy a new version of services frequently and thus scale the application accordingly.
- Fault Tolerance: In SOA, an Enterprise Service Bus (ESB) can be a single point of failure, which impacts the functioning of the entire application. An Enterprise Service Bus (ESB) implements communication between mutually interacting applications in SOA. It can perform a variety of functions, ranging from message transformation, routing, logging, protocol transformation, acting as a security gateway, etc. If one of the ESB services slows down, it will clog up the requests for that service. In comparison to SOA, microservices are fault tolerant and their deployment is independent of each other.
- Sharing Data Storage: In a Service-Oriented Architecture, services share data storage, while in microservices, each service can have an independent data storage. Data storage brings its own set of advantages and disadvantages. For example, while the data can be reused between all services, it can bring dependencies between services due to tight-coupling.
- Service Size and Scope: One of the major differences between microservices and SOA is the size and scope of services. Microservices are significantly smaller in size than SOA. On the other hand, an SOA can either be monolithic or can have multiple microservices.
Published at DZone with permission of Archna Oberoi . See the original article here.
Opinions expressed by DZone contributors are their own.