Are the drawbacks of service-oriented architecture significant?
In the age of the native cloud, service-oriented approaches to development can seem to be enjoying the old news. It’s easy for developers and architects to assume that it is long dead and has been supplanted by microservice architectures.
Yet, there are cases where the drawbacks of Service Oriented Architecture (SOA) automatically make microservices the best choice. And in many cases, companies can choose to work with a microservices architecture and SOA architecture in parallel.
Before writing 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 in which applications and their associated components interact through a centralized service messaging interface. The service interface defines how applications communicate with each other, typically using standardized network protocols and data structures such as HTTP or JSON.
The main advantage 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 in each individual service. Instead, these functions can be accessed over a network using the service interface.
For example, a business can use the SOA approach to link its payment processing system to multiple websites, applications, and user interfaces for customers. In this case, SOA allows these various sets of resources to easily connect to the same payment processing service.
SOA and microservices
SOA implementations exploded in the early 2000s, heralded as a way for enterprises to add much-needed scalability to enterprise-level application systems. In the early 2010s, the reviewed drawbacks of service-oriented architecture supported 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 overstated by the introduction of Docker, Kubernetes, and other container-based technologies that directly targeted the market’s growing appetite for microservices.
In some ways, the line between SOA and microservices is blurry. The main difference, however, is that SOA divides functionality at the business logic layer level. Each individual core business process (i.e. processing payments, registering customers, or tracking inventory) is repackaged into a single abstract software unit.
In contrast, microservices separate functionality at the application layer. Rather than processes, different parts of a larger business application (such as a front-end, back-end database, or user authentication process) and divide 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 work in a particular, larger business application.
In other words, you probably wouldn’t want to take a microservice out of one app and just drop it in another. On the other hand, an SOA architecture will allow several applications to use the same function, such as a payment processing service accessible by several windows.
SOA is alive and well
Although the approach has apparently lost its luster over the past decade, there are still many use cases where the disadvantages of service-oriented architecture are outweighed by its overall advantages.
The main benefit of SOA is that it offers application scalability and code reuse on large software systems without having to deplete development resources. As noted above, the same service can be shared by many applications simultaneously. For large enterprises, provides an efficient way to share functionality across multiple business units without the need for intensive code rewrites and refactoring efforts.
The reusability of SOA code also means there is less code to document and maintain over time. This can be a real benefit, especially for development teams already overwhelmed with other development and management tasks. Getting the most out of microservices requires rapid development and deployment cycles that only DevOps and CI / CD allow. However, not all teams want or can embrace DevOps. If you just want a modular code base without going through a full CI / CD, SOA makes a lot of sense.
When to leave SOA behind
On the other hand, there are still situations where SOA just doesn’t make sense. The most important factor, of course, is whether a development team wants to aggressively pursue the efficiency and speed associated with DevOps. In such cases, the microservice approach places companies in the strongest position to capitalize on faster development cycles and CI / CD.
SOA also ceases to be a useful approach when it comes to a newly written codebase, or one that is already heavily refactored to allow microservices. If there’s no legacy code to process in any form, it’s probably best to use full microservices.
However, keep in mind that the SOA and microservices debate doesn’t have to be a proposition of one or the other. Most enterprise-level organizations don’t have the luxury of being able to refactor every application to run as microservices. It is quite possible – and often necessary – to deploy some of your applications as microservices, while using SOA to maintain and integrate other existing business functions.