Making solutions scale is nothing new. However, the SOA technology and approaches recently employed are largely untested with higher application and information and service management traffic loads. SOA implementers were happy to get their solutions up-and-running, however in many cases scalability is simply not a consideration within the SOA, nor was load testing, or other performance fundamentals. We are seeing the results of this neglect now that SOA problem domains are exceeding the capacity of their architectures and the technology.

What is more, many SOA technology vendors have not focused on scalability within their solutions. Instead, feature/function enhancements are the rule of the day. It's more important to add orchestration features and more adapters to your solution than to figure out how to pump more information, and manage more services, reliably with your product.

Eventually the number of connected services and the information traffic will saturate the available resources of the integration or application server (memory, processor, disk). The saturation point is dependent on the efficiency of the vendor's product as well as the how course or fine grained the services are as they exist within the SOA. Indeed, using a single server, means that the saturation point is fairly static.

So, what do you do?

First, SOAs are all about distributed services, and the ability to leverage and managed those services. Thus, the more processing you can place at the origin of the service, the better your SOA will perform. In many SOAs, the architects abstract the services to a single server, and performance can be somewhat problematic in larger implementations.

Second, many services are built on top of more traditional legacy APIs, and as such the translations between legacy APIs to expose them as services may cause performance problems.

Third, use of too many fine grained services may cause performance problems. Indeed, you should not be afraid to leverage fine grained services within your SOA. However, you need to understand the performance issues with doing so, taking careful consideration of the network bandwidth and how other applications leverage the services.

Forth, make sure to consider performance when selecting your orchestration layer. Many BPEL engines and process tools are notoriously poor performers, and can become the bottleneck for the SOA.

Fifth, understand the basic rule that while the value of a SOA is the ability to leverage many remote services, the more services you leverage the more problematic that your SOA will become. It's like links in a chain. This is just an architectural tradeoff that you need to consider, no magic formula here.

Finally, performance modeling and performance testing are not just good ideas, they are essential. No matter how much thought that went into your SOA, you won't know how it will behave until you put it through its paces, before it goes into production. Modeling allows you to predict behavior, and you should use that during the design. However, testing is the final validation. Make sure that your test plans consider real-life scenarios, simulating production as much as possible.

Posted by Dave Linthicum on December 13, 2006 08:40 AM