Rob Daly: It's the SLA, Stupid

Before the partial outage of Amazon’s compute cloud on the East Coast last month, selling the benefits of third-party cloud computing was an easy task. The obscenely low price of processor time made it a no-brainer for financial organizations to move costly charges on their capital expense budgets to much smaller entries on their operating expenses budgets. And you didn’t have to consider business continuity requirements because the service was based in a cloud, so if one portion went down, other portions of the cloud would take over—at least in theory.

Although none of the financial technologists I’ve spoken to admit that they were affected by Amazon’s outage, it is clear that everyone has taken away a couple of lessons from this experience.

First, never keep all of your eggs in one basket. Organizations that relied on Amazon’s service not only lost out on access to the resources but they also missed the opportunities they could have had to generate revenue during the outage.

The second lesson is that most current third-party cloud service-level agreements (SLAs) are extremely weak. While purchasing these computing resource services is relatively cheap, so is the refund that users will get in the case of an outage.

Third-party cloud providers could raise the resiliency of their cloud environments so that it would read 99.99 percent uptime—or even reach the magic Six Sigma rate of 99.9999 percent uptime—but it’s not really in their economic interest to do so. Such reliability is needed by a small subset of their client base and the vendors make their money by servicing the lowest common denominator.

Taking Advantage
That said, however, it doesn’t mean that financial services firms won’t be taking advantage of these current offerings. I’m sure that most firms do not know how many separate contracts they have with these providers that are paid for by company credit cards. But these usages are more for spinning up temporary development and test environments than integrating production processes into the cloud.

Eventually a vendor, or even a consortium of banks, will get together to create a multi-member compute cloud for the financial services and other highly regulated industry verticals. The services will probably look similar but cost more, as the providers will not be able to enjoy the same economies  of scale as the Amazons, Googles and Rackspaces of the world.

It will be a little while before we see these offerings brought to market since some critical issues need to be addressed. At the top of the list is security. It would probably be easier to see how the general cloud providers handle security in their own environment first, before an industry-specific cloud provider tackles the problem, since the general cloud providers would face more attacks as they have a wider variety of users. Taking their best practices would only help industry-specific cloud providers build a secure base for their environments.

But we cannot forget all the haggling and standards writing that will need to be done in order to create that extra level of security and resiliency that the financial services industry needs. This is where existing network operators will probably have a leg up over a greenfield startup since they’ve already addressed the security portion of the puzzle. Then there’s creating the interface standards and the rest of the stack. Will firms want to go with a model based on open-source technology to avoid vendor lock-in? Will they create yet another proprietary stack that all of the other middleware and connectivity vendors will have to add to their suite of products?

Considering the current state of third-party cloud providers, it’s going to be at least 12 months before we see a dedicated offering for the financial services industry.