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.
At Intellias, we’ve extensively worked with SOAs and want to share our experience with this underrated architecture. After all, if it’s suitable for a Fortune 500 company, why shouldn’t we highlight its specifics and unique use cases?
So, what exactly is a service-oriented architecture and why does it still have a place in companies such as Airbnb and Twitter?
What is a service-oriented architecture?
The SOA architecture approach to software design enables the creation and use of reusable service components via service interfaces. See an example of an SOA architecture diagram below.
Source: Infoworld
In 2009, Gartner placed SOA at the Peak of Inflated Expectations alongside cloud computing, Web 2.0, Internet TV, and virtual worlds, highlighting its early widespread adoption. It was seen as a game-changing technology for the next five years.
Although SOA software lost its mainstream dominance to microservices, surveys in the 2020s show that it is still adopted by 35% of businesses.
How SOA works
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). See how monolithic architecture differs from SOA in the service-oriented architecture diagram below.
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.
You can also use SOA to reorganize supply chain architecture, creating services for inventory management, order processing, and logistics coordination, leading to more flexible and efficient operations.
Architectural principles of SOA
Service-oriented architectures 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.
- Better integration for enterprise software platforms. SOA helps different enterprise software components work together smoothly, making it easier to build and maintain flexible platforms that grow with business needs.
Example of SOA architecture implementation
We’ve personally implemented SOA many times as part of our software engineering services. For example, we used it to overhaul a European bank’s system, transitioning from legacy infrastructure to a modern payment microservice architecture.
Our SOA approach prioritized round-the-clock, instant payment processing, along with high scalability, availability, and resiliency. The architecture complies with the ISO 20022 standard, providing more detailed transaction information and eliminating payment delays due to compliance checks.
This SOA-based system now serves nearly 30,000 enterprise clients, 5 million mobile users, and 7,000 internal users. It processes 3 million transactions in 8 hours with 99.741% failure resistance.
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.
Check out the table below to see the key differences between SOA and microservices.
As you can understand, microservices are relatively small (hence the name) and are used for high-priority niche tasks, whereas SOA serves as a comprehensive solution, particularly in large organizations.
The main SOA 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.
SOA 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 API strategies 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.” However, this was a leftover from their MVP product development days.
To split the architecture, 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.
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 SOA 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. For example, one of the challenges was to significantly simplify the service dependencies using the concept of Service Blocks, as illustrated in the SOA diagram below.
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.
To conclude
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.”
Ready to upgrade? Contact the Intellias team to schedule a discovery workshop — a structured investigation of your company’s architecture that will help you find the optimal route to modernization.
