How reuse impacts performance of the service-oriented delivery network

Reuse is one of the most commonly cited benefits of implementing SOA. It is cited as a cost-reducing, developer productivity enhancing benefit that enables agility by reducing the number of application logic "touch points" spread across the enterprise.  

In the early days of SOA the word "reuse" was a common mantra throughout the SOA community. Reuse meant reuse of code, no - it meant reuse of existing assets through service enablement, no - it meant reuse of application logic.

Realistically, all three definitions apply and under a common bullet point of "reuse" has become one of the primary business and IT benefits associated with SOA. While many might argue we need a better term than reuse to describe the process of extracting application logic into a single, consistent service for use across an entire organization, that's beyond the scope of this post.

What we're most concerned about is how that process impacts delivery of your service-oriented applications. Productivity gains and a reduction in overall cost to deploy an application can be rapidly offset by the losses incurred because of poor application performance.

The Old Paradigm

Back in the day, we implemented application logic that performed common tasks in every application that needed it. Customer look ups, updates, order entry - all this logic was hard-coded in every application, and thus the compute burden of these tasks was spread around the data center.

The New Paradigm

In a service-oriented world, we create a service that performs a common task that can be shared by applications. Instead of five or six "copies" of the code littered about the data center in little silos, we create a single silo containing the code to perform the task and direct five or six applications to access that single service. Running on a single machine.

See the problem?

How Reuse Impacts Performance

The burden of executing that one piece of code has now been multiplied by the number of applications accessing it. Added to the general compute costs of the code is additional overhead added by XML parsing, marshaling of parameters, and TCP session setup and tear down.

That one service is going to be very busy if you architected your SOA properly. That one service can become a bottleneck for multiple applications, and can impede compliance with service-level agreements across the enterprise. Yeah, it's gonna be s l o w.

You're going to need another copy of that service running to spread the load across multiple servers. That will take care of some of the overhead, but it doesn't address the overhead inherent in TCP session setup and tear down and the XML parsing process. In fact, you're going to need another instance of your application server to handle the clustering, and that's going to incur yet another hop in the network, which is going to add even more latency as another player sets up a TCP session, parses the XML, and decides where to send it - server1 or server2.

Rule: Every intermediary in a SOA requires the overhead of a TCP session, the parsing of XML and marshalling of XML into a form understandable by the intermediary, memory in which to store the parsed XML (usually as a DOM) and the re-serialization of those objects into XML as it is routed to the next intermediary.

Thus, the more "reuse" you get out of a single service, the higher the performance penalty you're likely to see.

So think carefully about the design of your architecture and what you'll use to manage it from a traffic management perspective before you get too far down the road. It's better to address the potential performance issues up front (proactive) by including a solid infrastructure capable of delivering SOA services securely, within expected service level agreements, and keeping them available than to put out the fire later (reactive). Consider the use of an intermediary like an application delivery controller that minimizes the overhead of TCP and can react to changing conditions on the network to ensure compliance with service-level agreements instead of introducing yet another bottleneck by using an application server to load balance instances.

Imbibing: coffee