Capacity planning for SOA infrastructure is complex for several reasons. Given
the loosely coupled nature of SOA, services can have unexpected load demands and
services may be consumed in unexpected ways - for example, file systems have been
implemented on top of Google's GMail presenting much different capacity demands
than email. Also, the SOA infrastructure consists of many components, such as
Message Oriented Middleware (MOM), Business Process Management (BPM) engines,
brokers for mediation and orchestration, integration services (such as security,
monitoring, exception handling) and the network infrastructure. Within the network
infrastructure there are many components that impact performance and capacity
including connection speeds, routers, switches, traffic load balancers, and encryption
(SSL) and transformation (XLST) accelerators.
Another complication arises from constructing a composite application from
services with varying performance and availability characteristics. Including
a service with no Service Level Agreement (SLA) within a composite application
having a rigid SLA can result in a failure to comply with the SLA. Also, architecting
for recovery via retries simply adds to the demand for the service. One must
consider the SLA of every service within the composite since the weakest link
impacts overall performance and availability. This implies that an SLA is needed
for every service. It is also necessary to document the service use for each
business process - a dependency matrix works well cross referencing processes
and services.
A typical response to these challenges is to over engineer the infrastructure.
In some cases, for example network connection speeds; this is an acceptable
practice since it is cheap and effective - it does not cost much more for a
100GB network than 10GB. However, taking an over-engineering approach with components
such as a BPM engine is expensive and overkill. A more effective approach than
simple over engineering is to have flexible resources such as clusters, blade
servers, logical partitions, grids (future) and load balancing techniques. Using
flexible resources, which can be allocated from a pool among different applications,
still implies some idle resources but multiple applications bare the cost.
It is however desirable to achieve a predictable capacity plan. A capacity
plan should time infrastructure spends with capacity needs. This not only ensures
SLAs are met, but also creates an accurate budget for upgrades. To establish
a capacity plan one must establish the baseline performance characteristics
of the infrastructure then plan for future growth. This is certainly more difficult
to do for SOA than for network elements, but possible.
1
Solution Center Resources