Get a warm take on the service-oriented architecture (SOA) — a not-so-new but still important tool in the evolution of software architectures
The service-oriented architecture (SOA) is a software architecture pattern that was all the rage in the early 2000s. Two decades later, SOA remains largely undervalued. Perhaps this is because it’s often misunderstood and misinterpreted.
What is a service-oriented architecture and why does it still have a place in companies such as Airbnb and Twitter? Let’s go on a deep dive.
What is a service-oriented architecture?
The service-oriented architecture (SOA) approach to software design enables the creation and use of reusable service components via service interfaces.
In 2005, a survey by InfoQ estimated the planned use of SOA would reach 92% in retail, 89% in finance, and 76% in manufacturing in 2006.
Think of your office building. Point-to-point integration is like having one elevator — if you pack in more than five people, the system is overloaded and no one travels anywhere. Instead, everyone crowds in the lobby and slowly goes up four or five at a time.
SOA was innovative in the sense that it allowed developers to build a more spacious lobby (enterprise service bus) with different elevators (communication protocols such as SOAP and later REST) to send people to their respective floors (services).
In essence, SOA enabled access to different chunks of data and business logic encapsulated in various apps and made it possible to connect them to various services.
A service in SOA is a set of code plus the data integrations needed to run a certain business process.
For example, a lending application can include a risk engine service, a loan underwriting service, and a decision engine service.
SOA services have several important characteristics:
- Loosely coupled. They can be called with little insight into the technical aspects of how they’re implemented.
- Reusable. SOA services are built to be easily discovered and incorporated into other applications.
- Protocol-based interactions. The standard network protocols SOA services use to read/exchange data are SOAP (simple object access protocol) plus HTTP or REST and HTTP.
- No max size. Services don’t have fixed boundaries — they can be delivered individually or combined in composite service stacks.
- Process matched. The scope of a service is modeled to power a specific business process within a company. Services are often developed by exposing functions from legacy systems.
- Self-contained. Services can remain independent of other system elements.
Benefits of SOA
The main advantage of a service-oriented architecture is increased system interoperability. Compared to a monolithic architecture, SOA enables a wider range of cross-system communication, which, in turn, leads to a higher degree of automation and productivity for end users.
From a technical perspective, the benefits of a service-oriented architecture are as follows:
- Easier to maintain. SOA enables progressive decoupling of important services from outdated legacy software. It also provides an opportunity to consolidate and retire legacy functionality.
- Lower total cost of ownership (TCO) resulting from increased maintainability. Migrating to SOA helps reduce the cost of technical debt.
- Greater agility. Reusability and loose coupling decrease the development timeline for new services and functionality.
- Gradual legacy modernization. A properly defined SOA helps enterprises unlock core functionality siloed in older computing platforms and deliver it to customers in the form of new digital products.
SOA vs microservices: What are the differences?
SOA is often called the predecessor of the microservices architecture. Indeed, as SOA does, a microservices architecture assumes the use of loosely coupled, reusable, scoped services that can be deployed independently.
However, microservices are lighter and have more granular context than SOA services. Also, microservices support a cloud-native architecture and are often adopted as part of cloud migrations. SOA appeals more to enterprises who run operations on-premises or in hybrid environments.
Service-oriented architecture vs microservices: Quick comparison chart
Service-oriented architecture: The main communication protocols
An enterprise service bus (ESB) is the main middleware component for enabling service-to-service communications. In short, an ESB acts as a “lobby” where different people (services) can come to exchange information.
In contrast to microservices, SOA services talk to the bus rather than connect with one another directly.
For enterprises, ESB is an effective way to expose internal applications to their counterparts without building a point-to-point integration. Extra benefits of ESB include:
- Protocol transformation and standardization. If your services use different protocols (REST, SOAP, FTP, etc.), an ESB can act as a “converter.”
- Simplified transactional message flows. An ESB can be used to securely process messages between two or more heterogeneous transactional data sources.
- Service orchestration. An ESB helps you create the optimal service hierarchy and ensure smooth routing.
SOAP (Simple Object Access Protocol) is one of two standard network protocols for inter-service communication. It primarily relies on XML to provide messaging services — a somewhat heavy way to structure messages. This makes SOAP rigid in terms of the messaging structure and not as common and effective as JSON these days.
Service-oriented architecture and REST. REST (Representational State Transfer) is a low-bandwidth protocol that works with an array of data formats (plain text, XML, HTML, and JSON). Primarily used by microservices, REST-based architectures provide speed and agility in communications.
The SOA architecture is compatible with RESTful APIs, though more complicated tech implementations are required than when using SOAP.
Is the service-oriented architecture modern enough?
The prime time for SOA was in the early 2000s, when it was indeed revolutionary. At that time, SOA also caught some flack after several high-profile migration failures among enterprises who opted for vendor-specific SOA stacks.
In the 2020s, a service-oriented architecture still has its merits. But they have little to do with top-to-bottom migration scenarios driven by vendors. Enterprises and complex platforms see SOA as an intermediate step to wider digital transformation and cloud adoption.
The best part? You don’t need to try to rip apart your legacy software and put something new atop it. Instead, you can gradually decouple service elements from the bottom up, as Airbnb did.
The Airbnb platform used to have a monolithic architecture developed with Ruby on Rails. The dev team lovingly called it “Monorail.” To split it, Airbnb engineers phased the migration and compared Monorail functionality to that of new services. Then they’d take 1% of the load to the new service-oriented architecture, compare the results, and keep switching loads. Eventually, they moved 100% of processes to SOA.
Like traditional SOA, we [Airbnb] focus on reusing common components as much as possible, including business functionality and storage.
Jessica Tai, Tech Lead Manager at Airbnb
Each of the newly decoupled services addresses a specific concern. Services at Airbnb are bounded by a large scope of relevant business processes, but they don’t duplicate each other’s functionality. Overlaps are prevented by reusing shared services and libraries. Airbnb also purposefully avoids fine-grained services.
In addition, each service has a strict flow of dependencies and directions as the diagram below illustrates:
Source: Infoq — Airbnb’s Great Migration: From Monolith to Service-Oriented
However, Airbnb focus on building independent build and deploy pipelines for each service so that their engineers can run each service independently, which is more common for microservices. Teams use Kubernetes clusters to scale individual services.
Jessica Tai mentions that with Monorail, Airbnb developers had to push code to three different repositories in the correct order or else the service wouldn’t run. Also, there was a lot of manual work and inconsistencies, resulting in glitches. Post-migration to SOA, the Airbnb team can create new Ruby gem clients with a single click. The overall predictability and structure of the development process increased, and so did the team’s productivity.
A service-oriented architecture may no longer sound aspirational or innovative for cloud-native companies or newly emerging startups. Microservices are indeed a better starter option.
But companies with a monolithic core can gain significant value from moving to a service-oriented architecture before upgrading to microservices. The key to such a successful transformation, however, is to make small, phased changes that positively contribute to the bigger picture. By moving incrementally and decoupling one small chunk of your core at a time, you can significantly reduce the chances of operational disruptions and big-time failures.
In the words of Jeremy Cloud, the leader of Airbnb’s Tweet service team: “1) make the smallest possible change you can make; 2) verify that it works; 3) repeat. Do it over and over. With each step, you’re making course corrections, and you can minimize the risk at each step.”
Read the original article here.