Open in app

Sign in

Write

Sign in

Service Oriented Architecture vs Microservice Architecture

Gonzalo Vázquez
6 min readSep 14, 2021

--

This blog post aims to help define what a microservices is and compare it to service oriented architecture(SOA). Hopefully, by the end of this post, we can understand common integration patterns and critical differences between SOA and Microservices.

Microservice(noun): “a system that can make change easier.”

Microservice architecture is an approach in which a single application is composed of many loosely coupled and independent deployable, small services. Let’s break that sentence down.

Microservice architecture is just that, an approach to solving a problem. The problem we are trying to solve with this design is the typical “monolith” approach in which we develop tightly coupled services in which change is complex and lengthy.

However, microservices is not a silver bullet. In some cases, the monolith architecture is the right approach.

Before we delve into characteristics, let’s define a service. A service is a program that can be interacted with via well-defined message exchanges. A service can be a manifestation of an OS-specific process like a Unix deamon, a Windows Service or the most common representation a Web Service. Services are built to last, while service configuration and aggregations are built for change. Services are designed to perform simple, granular functions with limited knowledge of how messages are passed to or retrieved from it.

Key characteristics of a Microservice Architecture

Let us explore common key characteristics of a microservice architecture.

Independent deployments

Components are deployed independently and communicate over some combination of REST, event streaming and message brokers. By having independent deployments it:

  • Enables an organization to create small, cross-functional teams around one service
  • The small size of services, combined with their clear boundaries and communication patterns.

Precise Scaling

Microservices require less infrastructure than monolith applications because they enable precise scaling of only the components needed.

Messaging

While we may want to design stateless services, the state nonetheless exists, and services need to be aware of it. When using a microservice architecture, it is necessary to couple to API calls with messaging or event streaming so that services can broadcast changes in state and other interested parties can listen for those changes and adjust accordingly.

API Gateways

Microservices often communicate via APIs, however API gateways are often a useful intermediary layer, especially as the number of services in an application grows over time. An API gateway acts as a reverse proxy for clients by routing requests, fanning across multiple services, and provide additional security and authentication.

Serverless

In the case of serverless, the unit of execution is not just a small service, but a function, which can often be just a few lines of code. The lines between microservices and serverless function is a blurry one, but serverless are commonly understood to be even smaller than a microservice.

Key characteristics of a Service Oriented Architecture

Now, let us explore common key characteristics of service oriented architecture (SOA).

Message Broker

In SOA, each service shares a common communication mechanism called the enterprise service bus (ESB). The enterprise service bus is a messaging middleware which acts as a communication point or the interaction point between different services.

Service Re-Use

In SOA, a Service must be clearly described, and their descriptions must be readily available to developers. The simplest way to making service descriptions available is to publish them as documents. A more common and sophisticated mechanism is a service repository, which enables us to maintain and search a database of service descriptions. The Web Services Description Language (WSDL) defined by the World-Wide Web Consortium (W3C) is a commonly-accepted standard for service descriptions.

Remote Procedure Call (RPC)

Most commonly services in a SOA architecture exchange data via Hypertext Transfer Protocol (HTTP). In contrast, a binary exchange service, also called RPC is also commonly found in SOA architecture as it delivers faster runtime response than web services and it avoids the need to maintain configuration files. Remote procedure calls consist of three primary components:

  • A client (caller), which is making the remote call
  • A server(callee), which implements the procedure being invoked
  • An interface definition language (IDL), which is the language through the client and server communicate.

A quick note, it is recommended to avoid RPC interfaces in order to free the developer from any impact on the service consumer and also to insulate the consumer from the internals of the service implementation.

Hierarchical

Service Oriented Architecture is hierarchical by nature, this means we usually have well defined defined roles for the services, such as the business service, enterprise service, application service and the infrastructure service. Each service playing it’s unique role, usually controlled by one director service.

Common Integration Patterns

Now that we have a good understanding of Microservices architecture and it’s predecessor Service Oriented Architecture, below are common integration patterns that you can use.

Backend for Frontend

Key features:

  • Allows service to be customized for the specific interface.
  • Allows to fine-tune the behaviour of each backend to best match the needs of the frontend environment.

Aggregate Pattern

Key features:

  • Aggregator collects related items of data and displays them.
  • Aggregator service receives a request, then makes requests of multiple services, combines the result and responds to the initial request.

API Gateway

Key features:

  • Acts as a reverse proxy to redirect or route requests (layer 7 routing) to the endpoints of internal microservices.
  • Aggregate multiple client requests targeting multiple internal microservices into a single client requests.
  • Consolidate cross-cutting concerns such as authentication into one tier.

CQRS

Key features:

  • CQRS allows the read and write workloads to scale independently, and may result in fewer lock contentions.
  • The read side can use a schema that is optimized for queries, while the write side uses a schema that is optimized for updates.
  • By storing a materialized view in the read database, the application can avoid complex joins when querying.

Circuit Breaker

Key features:

  • Prevents an application from repeatedly trying to execute an operation that’s likely to fail.
  • Enables an application to detect whether the fault has been resolved.

Strangler Application Pattern

Key features:

  • Minimizes the risk from migrating to a Microservice Architecture and spreads the development efforts over time.
  • Add functionality to the new system, while ensuring the legacy applications continues to function.
  • The legacy system is eventually “strangled” and it can be safely retired when is no longer necessary.

Asynchronous Messaging

Key features:

  • Creates events regarding the changes in the application state.
  • Services are automatically issued notifications of relevant events to itself and it’s subscribers.

I hope you enjoyed this blog post and have a good understanding of microservices and different implementation patterns. In the following blog post, we will be discussing how to implement user tracking (analytics) without relying on cookies or a specific library. A clue? The MutationObserver.

Resources:

Microservices
Software Architecture
Soa

--

--

Gonzalo Vázquez
Gonzalo Vázquez

Written by Gonzalo Vázquez

401 Followers
154 Following

Entrepreneur. Data-Driven Decision Maker

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams