Scaling SOA

Based upon conversations with architects in ZapThink’s Licensed ZapThink Architect (LZA) course, our High Performance SOA ZapFlash back in the fall of 2006 was a bit ahead of its time. In 2006, most architects were simply focusing on how to put SOA implementations together, but today, the focus has unquestionably shifted to how to make SOA implementations enterprise-class. As a result, there is predictably an increasing emphasis on scalability.

Conventional wisdom might suggest that SOA implementations scale poorly. While it’s true that abstraction layers always add some overhead, if your SOA implementation is too slow or doesn’t scale properly, the problem is more likely with how you went about architecting it, rather than a problem with the SOA approach itself. Understanding the best practices for building scalable, high performance SOA implementations, therefore, is an essential skill for any SOA architect.

The Three Dimensions of Scalability
Building scalable SOA implementations begins predictably with broad-based scalability best practices. The SOA architect must then understand how to apply these practices in the SOA context. SOA introduces some new scalability challenges to be sure, but from the systems perspective (where scalability lives), SOA is just one more approach for accessing enterprise resources.

The scalability approach this ZapFlash will focus on is called the “Scalability Cube,” which is one way of looking at the core best practices for enterprise scalability. This cube has three dimensions, which you can think of as the X, Y, and Z axes. Basically, there are three essentially orthogonal approaches to scalability, and the architect’s challenge is in properly combining them to achieve the best results.

Each axis consists of multiple instances of an underlying implementation. Each instance contains some subset of the infrastructure necessary to support one or more Services, including data stores, data integration technology, legacy applications and integration technology, Service run time containers, and whatever middleware glues the lot together. The key to scaling the SOA implementation is to duplicate such instances in particular ways depending upon which axis we’re following.

The most straightforward scalability dimension is the X axis. The X axis represents the distribution of the same work or mirroring of data. To scale an implementation along the X axis, deploy multiple identical systems that are essentially mirror images of capabilities and data. A typical example of X axis scaling would be multiple identical databases on the back end supporting identical Service implementation instances. Scaling out, then, depends upon the straightforward process of adding identical instances.

The advantages of scaling along the X axis are as follows:

It’s simple to implement and simple to scale out. Simply distribute Service requests via a simple round robin algorithm on a load balancer or other intermediary.
It provides the best recovery from failure. If anything goes wrong with one of the instances, simply route traffic to other instances until you fix the problem. As a result, most disaster recovery strategies rely upon X axis scalability.
It works well with Entity Services, because Entity Services tend to abstract database tables or data integrations, which easily fit into an X axis instance.

There are disadvantages of X axis scaling as well:

It doesn’t maintain process instance state well, because multiple requests from the same consumer may be routed to different X axis instances in an essentially random fashion. Therefore, you must typically rely on messages to maintain state, which may require custom message headers and Service contracts.
X axis scaling doesn’t work for Services that abstract legacy systems that can’t be duplicated further. If you only have that one old mainframe acting as the back end for your Services, it will prevent X axis scaling of the infrastructure that supports the Service interfaces to the legacy system.

Orthogonal to the X axis is the Y axis, which represents the distribution and separation of work responsibilities or data across multiple instances. The distribution of capabilities along the Y axis are by resource, and such instances separate data based on data type or type of work. An example of scaling along the Y axis would be where each database and corresponding middleware instance supports a separate set of Services. To scale up, run fewer and fewer Services on any particular implementation instance as you add instances.

The advantages of Y axis scaling are:

It’s the best way to scale reusable Services. As the demand for reusable Services increases, their implementations can be distributed to as many implementation instances as necessary.
It works well with Task Services, because Task Services are less likely to abstract capabilities across multiple data sources as Entity Services are.
Y axis scaling also works well for abstracting legacy systems that can’t be duplicated further, although the scalability of such systems will still impact the overall scalability of the Services that abstract them. (Resolving that issue typically involves some kind of caching scheme.)

The disadvantages of Y axis scaling are:

Entity Services that abstract complex joins do poorly with Y axis scaling, because the complexity of the underlying implementation limits how narrow each instance can become.
Y axis scaling also deals with state poorly, when compositions include Services from different Y axis instances. However, because it’s possible in some cases to plan for Y axis scaling that maintains compositions in separate Y axis instances, it can maintain state more effectively than X axis scaling some of the time.

Finally, the Z axis represents distribution and segmentation of work by customer, customer need, location or value, in other words, by Service consumer or by type of request. For example, each database and corresponding Service container instance supports a separate, pre-defined set of consumers.

The advantages of Z axis scaling include:

It’s the best approach for addressing the state issue of the other approaches. There’s no chance a user’s state will be lost within the context of a particular Z axis instance, as long as that instance is working properly.
In some cases, individual compositions could also be allocated to individual Z axis instances, if different consumers consume different processes implemented by those compositions. This advantage would only apply for those processes that are specific to particular consumers.

The disadvantages of Z axis scaling are:

It doesn’t work well for reusable Services, for obvious reasons: consumers assigned to one Z axis instance can’t consume Services in another.
Z axis scaling also doesn’t deal well with legacy systems that can’t be duplicated further, as with X axis scaling.

Putting the Cube Together
In general, no one axis is sufficient to scale a SOA implementation fully. The architect must plan combinations of approaches that fit into the Cube as though it were a Chinese puzzle. Some examples of pairwise combinations are as follows:

X and Y axis — mirrored, identical clusters of servers, where each server in a particular cluster runs some set of Services distinct from the other servers in the cluster. Alternately, the X and Y axis combination might be several clusters, where each cluster addresses a specific set of Services, and each cluster is made up of a set of mirrored, identical servers.
X and Z axis — mirrored, identical clusters of servers, where each server in a particular cluster is dedicated to requests from a specific subset of consumer requests. Alternately, the X and Z axis combination might be several clusters, where each cluster addresses a specific subset of consumers, and each cluster is made up of a set of mirrored, identical servers.
Y and Z axis — a set of clusters of servers, where each cluster hosts a set of Services and each server in a cluster responds to requests from a particular set of consumers, or vice versa, naturally.
X, Y, and Z axis — Leveraging the full cube essentially requires clusters of clusters. There are too many possibilities to list here, so we’ll leave this option as an exercise for the reader!

The ZapThink Take
It’s important to remember that scalability, for all its complexity, is still only one part of the SOA performance problem. High performance begins with good design, as design mistakes like improper Service granularity or overly complex schemas can sink your performance. It’s just as important to deal with potential bottlenecks, which in the SOA case, typically involve XML processing issues of various sorts. High performance SOA means getting all of these elements right, as any one of them can limit the overall performance of your implementation.

We’d like to hear from you about your SOA performance challenges and solutions! Please email us at performance@zapthink.com if you have any SOA performance stories — either horror stories or success stories. If you have a product or service that can help with SOA performance, we’d like to hear from you too! We’ll use the information we receive in our presentation at our upcoming High Performance SOA seminar in New York City on March 29th. Watch the new ZapThink Web site for more information on that event as it develops. Hope to see you there!