Responsibility 2: Meet performance and availability requirements. As requirements and usage patterns change over time, be prepared to adapt.
Background
Sometimes we encounter situations where an existing service does not meet the performance or availability requirements for a new project. Resolving the matter often involves a technical constraint of some variety. Here are a couple examples:
- The service makes very heavy use of database stored procedures. The approach to scalability long term is complicated.
- The service interface supports very large request/response payload sizes. The worst case is probably where an "unbounded" size is allowed (e.g. by the XML Schema Definition or XSD). Under low volumes the service may work fine. However, the service becomes unstable as volume and number of concurrent requests increases (e.g. due to exhausting the JVM memory allocation).
Issues such as these and/or organizational concerns can prevent changes from being made in a timely manner to meet requirements. This can impact the re-usability of a service.
Considerations
This requirement, or principle, is front and center so it is clear to service providers the architecture must scale to meet current and future requirements. Even a re-architecture should not be out of the question for any unforeseen situations. The service provider must have "ownership" of a solution to meet the purpose and general objectives of a SOA.
Typical patterns and decision points:
- Implement stateless request/response services that scale by adding additional computers or virtual machines behind a load balancer to handle additional volume.
- Use of an "intelligent" load balancer to direct requests away from failed instances during a period of outage (as opposed to static DNS RR).
- Clear separation between data persistence and application tiers to enable each to scale independently.
- Business logic is best suited in the application tier where scalability is much easier to achieve. If there is a belief it belongs within a stored procedure to meet performance requirements, evaluate this belief very carefully. (Maybe I'll cover this topic in a later blog post.)
- Where applicable, an in-memory caching strategy can and should be employed behind the service interface to meet aggressive requirements.
- The application team must make critical decisions around the appropriate level of granularity for the service. For instance very fine-grain RPC style invocations are typically not appropriate when the technology is SOAP or REST over http. A more coarse-grain approach is best with these technologies.
- Where applicable enable a client to submit multiple "units of work" in a single request. This will cut down on the number of round trips across the network.
