Nmedia - Fotolia
Do the disadvantages of service-oriented architecture matter?
While it doesn't carry the shiny appeal of microservices, there's no reason to believe that SOA is totally down for the count. In fact, sometimes it's an essential approach.
In the age of cloud-native, service-oriented development approaches can seem to like old news. It's easy for developers and architects to assume that it died a long time ago and has been supplanted by microservices architectures.
Yet, there are instances where the disadvantages of service-oriented architecture (SOA) automatically make microservices the better choice. And in many cases, businesses may choose to work with microservices architecture and SOA alongside each other.
Before writing off SOA, take a look at how it really differs from microservices, and learn some critical facts about the potential benefits of SOA for modern software development efforts.
What is SOA?
SOA is an approach to software design where applications and their related components interact via a centralized service messaging interface. The service interface defines how the applications communicate with each other, typically using standardized network protocols and data structures like HTTP or JSON.
The primary benefit of SOA is that developers can use the same functions for multiple applications and services in a variety of scenarios. In other words, SOA eliminates the need to repetitively code functionality into each individual service. Instead, those functions can be accessed over a network using the service interface.
For example, a company can use the SOA approach to link its payment processing system to multiple customer-facing websites, applications and user interfaces. In this case, SOA makes it easy for these diverse sets of resources to connect to the same payment processing service.
SOA vs. microservices
SOA implementations soared in the early 2000s, heralded as a way for companies to add much-needed scalability to enterprise-level application systems. By the early 2010s, the scrutinized disadvantages of service-oriented architecture propped up the case for microservices, which gained a reputation as a more flexible, scalable and web-friendly alternative to the original service-oriented approach. This shift was also exaggerated by the introduction of Docker, Kubernetes, and other container-based technologies that directly targeted the market's increasing appetite for microservices.
In some ways, the line separating SOA from microservices is blurry. However, the main difference boils down to the fact that SOA divides functionality at the business logic layer. Each individual core business process (i.e. payment processing, customer registration or inventory tracking) gets repackaged as a single, abstracted unit of software.
In contrast, microservices separate functionality at the application layer. Rather than the processes, different parts of a larger business application (such as a front-end interface, back-end database or user authentication process) and breaks these entities into their own independently-operating services.
The concepts behind SOA and microservices also diverge when it comes to code reusability. In SOA, the same service can be accessed by multiple applications at the same time as needed. Typically, in a microservices application, each service will only operate within a particular, larger business application.
In other words, you probably wouldn't want to take a microservice out of one application and simply drop it into another one. In contrast, a SOA architecture will allow multiple applications to use the same function, such as a payment processing service accessed by multiple storefronts.
SOA is alive and well
While the approach has seemingly lost its luster over the past decade, there are still plenty of use cases where the disadvantages of service-oriented architecture are outweighed by its overall benefits.
The primary advantage of SOA is that it provides application scalability and code reusability across large software systems without the need to exhaust development resources. As noted above, the same service can be shared simultaneously by numerous applications. For large businesses, provides an efficient means of sharing functionality across multiple business units without the need for intensive code rewrites and refactoring efforts.
The code reusability of SOA also means that there is less code to document and maintain over time. This can be a real advantage, especially for development teams already overwhelmed by other development and management duties. Getting the most out of microservices requires rapid development and deployment cycles that only DevOps and CI/CD enable. However, not every team wants to or is able fully embrace DevOps. If you just want a modular codebase without going full-on CI/CD, SOA makes a lot of sense.
When to leave SOA behind
On the other hand, there are still situations where SOA simply doesn't make sense. The biggest factor, of course, is if a development team wants to aggressively pursue the efficiency and speed associated with DevOps. In cases like these, the microservice approach puts businesses in the strongest position to capitalize on faster development cycles and CI/CD.
SOA also ceases to be a useful approach when dealing with a newly-written codebase, or one that is already heavily refactored to allow for microservices. If there is no legacy code to deal with in any shape or form, it's probably better to go full-on microservices.
However, keep in mind that SOA vs. microservices architecture debate doesn't have to be an either-or proposition. Most enterprise-level organizations don't have the luxury of being able to refactor every application to run as microservices. It's completely possible -- and often necessary -- to deploy some of your applications as microservices, while at the same time using SOA to uphold and integrate other existing business functions.
