High Performance SOA

In the world of information technology, the concept of abstractions are particularly handy. Take, for example, the Services abstraction at the heart of SOA, which masks the complexity of the underlying technology implementation while presenting composable business Services to internal and external users. But every abstraction comes at a price, and the Services abstraction is no exception. Loose coupling, composability, agility, and the other benefits of SOA all introduce performance overhead. For limited sets of Services with small numbers of users, this performance hit may be minimal. For SOA implementations with large numbers of users, Services, or traffic, however, maintaining the necessary performance levels presents a substantial challenge, both to the architects who design the infrastructure as well as IT operations personnel who are responsible for keeping the lights on.

In fact, in SOA environments with the highest performance requirements, maintaining the Services abstraction in the face of high traffic is a paramount concern. Fail to maintain the abstraction, and the Services no longer meet the agile needs of the business, and the quality of the SOA implementation comes crashing down like a house of cards.

Performance Beneath the Services Abstraction
The SOA performance problem falls into two broad areas: ensuring sufficient performance of atomic Services as well as of composite Services. Atomic Services provide Service interfaces that abstract existing systems, so ensuring their performance necessitates managing the performance of the components, applications, and systems that lie beneath the Services abstraction. As you might expect, dealing with the performance of atomic Services leverages well-established capacity planning and performance quality assurance (PQA) techniques, including clustering, virtualization, and load testing. Today’s architects are adept at making infrastructural decisions that ensure, for example, sufficient database performance, distribution of traffic onto a cluster of application servers, and the like.

Furthermore, traditional PQA also serves atomic Services well. Simulating loads on Service interfaces is quite similar to simulating traditional Web page performance, after all — and many Web Service PQA tool vendors have predictably based their products on Web page PQA tools that performance test traditional Web applications via their Web interfaces. But while Web Services share some similarities with Web pages, there are some fundamental differences. In particular, Web page interactions are usually request/reply, but Web Services support a wide variety of interaction styles, including asynchronous, synchronous, event-driven, publish/subscribe, and one-way. Load testing a Service that has such a wide range of interaction styles requires more sophisticated tooling than traditional Web page-centric PQA tools.

Performance Above the Services Abstraction
While SOA manifestly relies upon Services, there is far more to properly architecting SOA than simply building a bunch of Services. Architects must consider the consumption of those Services as well, including the dynamic, business-driven composition of Services into Service-Oriented Business Applications (SOBAs). Unfortunately, the very nature of SOBAs as flexible, continually changing, potentially ad hoc compositions presents complex performance challenges to architects and operations personnel alike.

In fact, there are several dimensions of SOBA performance that architects must consider as they plan their SOA:

Balance between use and reuse — Some services expect high use, meaning large volumes of traffic from specific consuming applications, while others expect high reuse, implying a range of different consumers that may use Services in different ways, for example, in different SOBAs. High usage is often (but not always) more predictable than high levels of reuse, but the architect must plan for both, as well as the combination of the two.
Very Large Messages and Granularity — Some Service interactions involve the exchange of very large messages (VLMs). Addressing the performance issue of VLMs requires different infrastructure and different planning from Service interactions that exchange large volumes of messages. Sometimes the VLM problem directly relates to the granularity of the Services, while other times it might concern SOAP attachments, encryption, or other features that increase the size of messages. But in any case, the architect must take the sizes of messages into account as part of the SOA performance plan.
Dynamic Performance policies — In some cases, the service level requirements of individual Services is part of the contract for each Service, but in other cases, the organization requires performance policies that they can apply to Services as part of their governance framework. In fact, being able to reconfigure performance policies may be a business requirement the architect must take into account when planning the SOA.
Service dependencies — Service compositions come in many flavors: orchestrated flows, flexible choreographies, data virtualizations, and various combinations thereof. String several Services together where the output of one contributes to the input of the next, for example, and if one Service in the chain is too slow, the entire composition suffers. Multiply this bottleneck issue by the numerous ways that people can create SOBAs, and the architect has a complex task ahead.

Tackling the SOA Performance Problem
Dealing with performance bottlenecks is like playing whack-a-mole: defeat one and another immediately pops up. Even worse, implementing SOA just increases the number of moles you have to whack. It’s essential, therefore, for the architect to plan for performance bottlenecks at different levels, both above and beneath the Services abstraction. In other words, the architect must craft a performance plan that might take advantage of some combination of the following approaches:

Service and infrastructure virtualization — Various virtualization techniques can provide cost-effective approaches to dealing with variable performance issues, essentially by abstracting a specific part of the infrastructure. Virtualization is especially useful for dealing with unexpected spikes in demand, but the complexity of virtualizing heterogeneous resources can often limit such approaches’ effectiveness.
Combining judicious loose coupling with strategic tight coupling — While a simplistic view of SOA might suggest that loose coupling is always better than tight coupling, the fact of the matter is that loose coupling introduces overhead, while tight coupling can smooth out bottlenecks. The architect’s challenge, therefore, is in identifying those situations where the business requires some level of loose coupling, and then providing only as much as it needs, for example, by implementing transactionality in compiled code and distributing that code for high concurrency parallel processing underneath the Services abstraction.
Registry-based dynamic routing — A Service-oriented approach to load balancing leverages registry-based location independence to route Service requests to the appropriate Service instances in order to satisfy performance requirements. This dynamic routing approach to scalability and fault tolerance is unlikely to be as performant as tightly coupled clustering, but works well in heterogeneous environments, and can leverage the declarative policy management capabilities of the registry.
Performance as part of the SOA governance framework — Leveraging the registry’s policy management features should be more than an afterthought, however. In fact, the broadest, most agile approach to SOA performance is to plan for it as part of the governance framework for the SOA implementation. Based on the performance constraints of the technology, craft policies that will maintain the required performance levels while empowering users as much as is practical. For example, if the architecture team can distinguish particular types of SOBAs that the infrastructure can support from others that it cannot, then the team should be able to craft policies that will appropriately limit SOBA creation, and thus create predictable limits for overall performance.
PQA throughout the Service lifecycle — Traditional PQA typically applies simulated loads before deployment to a QA environment that closely mimics the production environment. After all, such traffic loads can bring systems to their knees, so nobody would want to run them in a live environment. Maintaining parallel QA environments for SOA implementations, however, is difficult to impossible, because of the wide range of possible configurations of SOBAs and the Services that feed them. PQA for SOA must therefore take a more subtle approach than the “pound on it until it fails” technique. Instead, SOA PQA relies upon the use of configurable policies that indicate whether a Service is in live or test mode, combined with active SOA management that proactively monitors live performance and takes preventative steps should Services cross pre-set warning thresholds.

The ZapThink Take
Analyzing SOA performance highlights the fact that SOA is more evolutionary than revolutionary. Architects must still know how to use every capacity planning and performance enhancement tool in their toolbelt, only now they’re able to add a few new tools to the mix. In fact, there’s no way we’d be able to figure out how to scale Web Services if we hadn’t already worked out how to scale traditional Web applications.

It’s also important to note that SOA performance is about more than ensuring that Services perform as required, just as SOA is about more than building Services. SOA best practices also cover the consumption of Services — within SOBAs as well as at the user interface. As a result, the comparatively mundane world of SOA performance has direct relevance to the sexy world of Enterprise Web 2.0. After all, no enterprise would depend upon rich, collaborative applications if there were no way to ensure their performance.

Finally, dealing with SOA performance requires an Enterprise Architecture approach to SOA. Those bottleneck moles in the whack-a-mole game can appear anywhere in the enterprise, at any level of abstraction. The fact that SOA hides the complexity of the infrastructure from the user only exacerbates the need for an enterprise perspective, because high quality, high performance SOA requires high performance from every part of the enterprise.