SOA: Responsibilities of Service Providers (Part 3)

This blog post is one in a series.  An overview and general outline of this series is linked here.

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:

1. Implement stateless request/response services that scale by adding additional computers or virtual machines behind a load balancer to handle additional volume.
2. Use of an "intelligent" load balancer to direct requests away from failed instances during a period of outage (as opposed to static DNS RR).
3. Clear separation between data persistence and application tiers to enable each to scale independently.
4. 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.)
5. Where applicable, an in-memory caching strategy can and should be employed behind the service interface to meet aggressive requirements.
6. 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.
7. 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.

In a later installment, we will touch on a related topic--Service Level Agreements and measuring planned vs. actual metrics.

SOA: Responsibilities of Service Providers (Part 2)

This blog post is one in a series.  An overview and general outline of this series is linked here.

Responsibility 1:  The functional needs of the enterprise as a whole must be considered to maximize reuse

Background

It can be common to find feature/function duplicated across multiple applications and development organizations, especially in companies that have been around a while.  For instance, "address validation", "geocoding", "credit card validation", and "currency conversion" are examples of functionality that might be duplicated.  In each case, the features might differ, the underlying technology might differ, and where applicable underlying software vendors might differ.  Ultimately this duplication translates into increased hardware, license, labor, and maintenance costs.

What are some reasons duplication exists?

In using "currency conversion" as an example:

1. Technology and platform differences:  A distributed application invokes currency conversion directly using a C API.  A COBOL application uses currency conversion on the mainframe and inaccessible to distributed applications.
2. Differing requirements:  An application area supporting North American operations deploys conversion between U.S. and Canadian currencies only.  At some other point in time, another development area supporting international operations requires conversion for a broader set of countries.  Or an application needs "historical" conversion rates but the service owner is only able to support "current" rates.
3. Differing priorities and timelines:  An existing service cannot be extended to meet the needs of others due to project workload and competing priorities.
4. Ownership considerations:  An application area is unwilling to take responsibility for any impacts resulting from outages.  Or is unwilling to coordinate changes/testing with any other development groups.
5. Differing performance and availability requirements:  An application team with more stringent availability or performance needs decides to deploy duplicate capability to maintain control of their own destiny.
6. Lack of visibility to existing services that are available

At this point you might see a common thread:  some of these relate to underlying organizational considerations/issues.  Additionally, without a productive governance program, issues are accentuated in organizations operating in vertical silos (e.g. associated to line-of-business) as opposed to certain functions aligned in a more horizontal manner.

These items are sometimes used as justification for sprouting duplicate functionality.  An archaeological dig into the history of how duplication came to be is educational.  Sometimes the reasons for duplication can be rationalized.  And sometimes the reasons aren't valid at all, especially after a certain amount of time has passed.

Considerations

When building a new service or transitioning a legacy environment to common services, it is important to ensure "functional ownership" is clear.  Achieving reuse can have different context.  Some services have utility across the enterprise.  Others are more domain-specific but hold the promise of greater use across the enterprise in the future.  This is the reason I slipped the word "enterprise" into Responsibility 1.

To paint a simple picture of a good "currency conversion" service, it is one that maximizes reuse for both today's use cases as well enables future use cases to be supported.  It supports currencies for the countries presently served and can expand to support other countries when needed.  It supports conversions for current conversion rates as well as historical rates if there is a need to do so.  And the architecture and development team is able to flex to meet additional functional, performance, and availability needs to maximize reuse across multiple applications.

This can be difficult to achieve without organizational considerations and/or a formalized governance process.  Additionally, standing-up a service suitable for the enterprise requires the ability to perform a necessary level of business analysis.  This is to ensure the broad functional needs of the enterprise are identified.

As briefly mentioned in a prior post, the goals of SOA typically involve reducing duplication and increasing reuse as a means to promote a more cost effective and agile operating model.  It is difficult to meet these objectives without taking at least the spirit of this principle seriously.

Next time I'll explore...Responsibility 2: Meet performance and availability requirements. As requirements and usage patterns change over time, be prepared to adapt.