to LooselyCoupled.com homepage
 
 Weekly emails: how to advanced search
 Glossary lookup:

 

> stories > decision point


Web services without warranties

by David Longworth
October 4th, 2004

Embedding web services from the likes of Amazon and eBay into enterprise applications is a leap of faith.

 
• print  • comment
Enterprises risk becoming dependent on service providers that provide no SLAs or support desks and interoperate poorly:
  • Enterprise developers are linking to web services from Amazon, eBay, Google and others
  • Such providers normally offer no service level guarantees or helpdesks
  • Each of them manages connections in a different way
  • Third-party service networks aim to add consistency and monitoring
  • Businesses remain exposed to unforeseen service interruptions


Glossary terms: on demand, SLA, web services, WSDL, lookup tool

But despite a lack of service guarantees and a raft of inconsistencies between different providers, growing numbers of enterprise developers are taking the plunge. They are leading where others are destined to follow; research group IDC in a July report, Disruption from Below: The Emergence of Amazon, eBay, Google, and Yahoo! as On-Demand Service Providers, predicted that the Amazons and eBays of this world, rather than traditional suppliers such as IBM, will become the main providers of on-demand services. Using platforms such as Amazon Web Services or Sforce from Salesforce.com, developers will not only build out their existing applications to make use of new functionality available on the Web, they'll also be developing new applications from scratch.

"There's this groundswell of innovation, like back when electricity was first discovered," says Bob Brauer, co-founder and VP of business development at StrikeIron, a business service network and Amazon development partner. "Now the Internet is somewhere you go to find innovative methods for data transfer."

Some enterprises may be tempted to batten down the hatches and forbid all contact with such services. But such a gesture would be as futile today as it was to forbid the deployment of PCs in the 1980s. For all their shortcomings, PCs delivered competitive advantage that could not be ignored. Early adopters believe the same is true of today's on-demand web services — despite the absence of performance guarantees that makes reliance on such services a risky proposition in mission-critical applications.

Take the example of a StrikeIron customer in the UK, which has built the network's "Do Not Call" service into its call centre application. The service carries a list of consumers who have registered their number as unavailable to the Direct Marketing Association, thus ensuring compliance with DMA rules. Or consider a customer of Grand Central Communications, running a composite process that receives leads at its marketing website, uses a selection of web services to verify the details based on the country of origin, and then posts the verified data back to Salesforce.com.

In either example, if the services were not available, performance was poor or security was in some way compromised, the repercussions for the organizations in question could be serious. Developers need to be confident in services they build into enterprise-class applications, but that confidence can rarely be guaranteed in the case of on-demand services — a shortcoming that has opened up opportunities for service network operators such as Grand Central and StrikeIron to step in and fill that gap. Providers are under no obligation to provide such guarantees; nor do they show much inclination at the moment.

No guarantees
Jeff Barr, program manager for Amazon Web Services, is unapologetic for the online commerce site's failure to provide any service guarantees: "We have not found it necessary to offer any kind of formal guarantee in this regard. What works best is to realize that our interests are aligned with the interests of our developers — if the service is not running then their sites are not running, and no transactions are occurring. Clearly, this is bad, and we do all that we can to make sure that it doesn't happen."

In fact, Barr claims that self-regulation among Amazon's 50,000-strong developer community provides much of what is needed, including ensuring other developers do not transgress on its rule of no more than one call per second. "The developers in our community are very conversant with the terms in the license, and have a pretty good understanding of how these policies are made manifest in an application. If they see an application which does not appear to be following the rules, more often than not they will bring it to our attention. What's interesting is that they do this to protect the service from untoward use, and to make sure that it will be open and accessible to everyone."

Such a laissez-faire attitude to quality of service is perhaps justified when the offering is still something of a novelty. But sooner or later the sophistication of the services on offer is bound to mature, says David Butler, VP of marketing at Systinet, whose server technology underpins Amazon's merchant program. He believes the likes of Amazon will ultimately provide a business service registry, specifying things like performance.

"They will need to provide SLAs to retailers on their merchant network. Unless they find a way to organise their services and enforce their rules and policies, [the take-up of their service platforms] will not happen on a mass commodity basis. What retailers want is security and reliability." Butler points out that retailers can already physically call Amazon and ask about performance, while several networks and service management suppliers provide performance charts. He says the next step is to dynamically maintain that information so that users can access it in real-time.

Mind the gap
The gap in providers' offerings stems back to the unplanned way in which their business models have evolved. Although Amazon is best known as an online bookseller that has since expanded into selling everything from underwear to garden furniture, what is less recognized is that it now generates more than a fifth of its revenues from stock that is inventoried at partners and affiliates rather than on its own systems. Butler says this is indicative of the way companies like Amazon are developing into "customer software providers," whose main role is to provide the software functionality that underpins their operations as a set of on-demand services made available to others.

Amazon's transformation was in part inspired by author and tech publisher Tim O'Reilly, who summarized his views last year in The Open Source Paradigm Shift, observing that: "Web services are starting to make even huge database-backed sites like Amazon or Google appear like components of an even larger system." The evolution of interlocking 'service platforms' is now seen by many as the beginning of the next phase in the evolution of the Internet — a topic that will be discussed in depth this week at OíReillyís Web 2.0 conference in San Francisco.

Barr himself sees this evolution as perfectly natural. "Amazon has always been a software developer, but the product is available for use on our web site instead of in a shrink-wrapped box. We are trying to provide developers with a healthy set of functions for access to various parts of the Amazon technology platform."

With such roles come new responsibilities, however. When people start relying on platforms, they expect the platform owner to ensure consistency and to help them out when things go wrong. Barr is conscious of Amazon's responsibility for backward compatibility with the services on its platform. "Versions 2 and 3 [of AWS] were each compatible with the previous release," he says. "In our new release we decided to make some changes so as to best meet the needs of our development community. We did not do this lightly; one of the hallmarks of a good platform is the fact that it is stable for the long term. In the new release we do provide them with guidelines and examples of the changes that they need to make in order to upgrade."

Amazon and others like it will also have to meet a growing demand for technical support, either directly or through third parties, says Systinet's Butler. "They've got a revenue stream based on the software they've enabled to use their business processes," he points out. "But they don't have a large support staff out there supporting it. That's why they partner with service-oriented ISVs."

Provider of choice
Stepping into the trust gap left by the on-demand service providers, specialist service networks are lining up to position themselves as the reliable providers of choice. "The opportunity is there [for us] to become the place you go to find web services you can work with because you are familiar with the experience," says Brauer. StrikeIron has built up different classes and sets of services that it offers — a handful for CRM and marketing and another set for e-commerce, for example.

Although these service aggregators still can't guarantee the performance of the services they link to, they aim to add value by certifying the pedigree of the providers they work with, and by easing the process of getting started with services that 'in the wild' might have taken extra effort to connect to. Grand Central goes further, providing performance monitoring, alerts and even failover options in the event of service failures. Offering such added features as a service allows the provider to trump tools vendors like BEA, which certifies providers for its controls program but leaves its customers to work out how to keep an eye on how they perform.

Another problem when connecting to multiple services is that each has its own idiosyncratic way of establishing connections and managing functions such as security and error reporting. Aiming to normalize these integrations for developers, Grand Central recently introduced its own certified connectors to a range of services and applications, including Amazon, eBay and Google, NetSuite and salesforce.com.

Ron Palmeri, Grand Central's VP of development, points out a service like Salesforce only requires a user name and password to start a session whereas NetSuite requires a client certificate. Ironing out these discrepancies in the connection protocol is just the starting point, he adds: "You need a fully normalized way of interacting with a business process for how you handle errors."

Storing connections in a LDAP-based secure credential store, Grand Central's network then goes on to document entire process flows that provide the right context for service reuse. "Most developers donít think through the notion of reuse quite as completely as they might," says Palmeri. "There's a certain expectation that because there's a WSDL, the service is automatically loosely coupled." That underestimates the hurdles, he says. "You still need to architect the connection and localize the differences in flow."

This of course will only become a major issue once applications are connecting to a number of different service platforms — but many are today just approaching that point. Grand Central hopes to stimulate demand further with the launch of an expanded developer program tomorrow, along with its first annual Golden Spike contest for the best developments on its Business Services Network (disclosure: Loosely Coupled's Phil Wainewright is one of the contest judges).

Meanwhile, says StrikeIron's Brauer, users are stepping up their commitment to on-demand services without necessarily being aware of the pitfalls that exist today: "Applications are being hooked into the Internet and data is going back and forth — but to the end user it's seamless, it's just new data they didn't have available before."

So long as users are getting value out of the information and capabilities available from service providers, they're going to increase consumption, becoming more and more dependent on the continued provision of those services. But until service providers are made to feel some kind of support is a competitive advantage, businesses will remain seriously exposed to unexpected service interruptions. It's only when a service stops being available that anyone reaches for the service level agreement. Many will be dismayed to discover that there is no SLA for services they have come to rely on.


More on this topic


Related

Measuring services in a business context
When web services emerge out of the test lab into live commercial environments ...

Loosely coupled invention
To glimpse the awesome potential of loosely coupled systems, take a look at BookWatch Plus ...


Research

Disruption from Below
IDC report on "the emergence of Amazon, eBay, Google, and Yahoo! as on-demand service providers"


 
 


Copyright © 2002-2006, Procullux Media Ltd. All Rights Reserved.