S3 in Business: 8 – Commercial risk

[Complete series]

It is risky to offer a business that depends entirely on a service provided by someone else. Amazon S3 might stop tomorrow, or it might become too expensive for us to use. It’s only been going for a few months, so we don’t even have a track record to go by. Here are some of the things that might happen to S3 in the next few years:

  • Amazon go bust.
  • Amazon are taken over by someone with no interest in continuing Amazon Web Services as an external product offering.
  • The stock market decides that Amazon ought to stick to selling books, and, faced with a steep decline in its share price, the company obeys.
  • At the next scheduled review of the project, Amazon decide that Amazon Web Services hasn’t been the success they hoped. They get tired of it and pull the plug.
  • Amazon decide that it’s too much bother dealing with all those tiny customers with tiny payments, and impose a $100-per-month minimum spend on S3.
  • Amazon realise they got their sums wrong and double their prices.

We are like a fly hitching a ride on a racehorse: it is taking us where we want to go, fast and with no effort, but we could be swatted off at any moment. How do we reassure our backers that we are safe? How can Amazon reassure us that we are safe?

Contractual reassurance

Amazon need to reassure us that S3 will not be switched off tomorrow. How do they do this while keeping their commercial freedom of manoeuvre? It is for them to think of something and for the market to decide whether it is good enough. Perhaps they could write a notice period of a few months into their contract, long enough for users of S3 to retrieve their data and store them somewhere else. They might also ring-fence S3 financially in such a way that it would continue for at least the notice period (possibly with reduced performance) whatever else might be happening at Amazon as a whole.

S3 without Amazon?

When the Cardbox Server does its automatic backup to S3, it sends S3 commands to a server and waits to receive S3 responses back from the server. Tunesafe would work in the same way. The server used is Amazon’s S3 server at s3.amazonaws.com, but it doesn’t have to be that particular server. Cardbox (and Tunesafe) would work just as well with any other server, as long as it also understood S3 commands and sent S3 responses in return.

If a different data storage supplier also supported the S3 protocol then we could choose whether to use Amazon’s service or its rival’s, and if one company failed then we could switch to the other one. There is nothing new about second-sourcing, which has long been a standard method of risk limitation in the defence and aerospace industries. There is an art to it: you want the second source of your designs to be big and efficient enough to be credible but not so big and efficient that they will take too much business away from you.

Amazon claim that the big value in S3 is not the S3 protocol itself – anyone could have designed that – but the enormous investment that they have made to ensure that information stored in S3 is always available, available fast, and never lost. That being the case, it would not be a threat to their business if someone else also offered an S3-protocol service. It would encourage customers to commit themselves to S3, knowing that they would not be completely dependent on Amazon’s continuing benevolence.

One could even imagine Amazon publishing a simple open-source program that turns any single computer into an S3 server. A single computer (or even a single data centre full of computers) would not be a rival to the full S3 service, but it would mean that no matter what happened – even if every contractual assurance offered by Amazon failed – a business dependent on S3 would have something to fall back on.

If this discussion seems a bit abstract, let’s compare Amazon’s data storage service with the electricity supply. Defining the S3 protocol is the equivalent of deciding that electricity should be provided at 220 volts and 50 cycles per second. Once that decision has been made, the market for electrical appliances blossoms because everyone can build appliances to use just one kind of supply. If some people get themselves diesel generators that generate 220V/50Hz as a backup in case the mains supply fails, that is no threat to the electricity company – it’s actually a benefit, because it means that those customers won’t look for alternative kinds of power. Even giving away diesel generators would make sense, if they were cheap enough, because no-one would rely exclusively on generator power when the mains supply was cheaper than diesel, more reliable, and of unlimited capacity. (If you are in America, please read “220” as “110” and “50” as “60”.)

Allowing widespread use of a protocol one has developed is not quite risk-free and Amazon will have to be careful how they do it. But if they can state publicly that they have no problem with certain kinds of services that use the S3 protocol then that is a perfect additional reassurance for us to give to doubting investors. “We use Amazon S3,” we can say. “We hope that we’ll always use Amazon S3. But if ever we can’t, for whatever reason, then we do have an alternative that will work without any of our systems having to be changed”.

Next time, technical risk. What if Amazon S3 doesn’t work exactly as advertised? What if it starts forgetting things from time to time?

One Response to “S3 in Business: 8 – Commercial risk”

  1. James Webster Says:

    There’s already at least one S3 clone, thanks to the Ruby community’s Why The Lucky Stiff. Its primarily targetted at giving people a lightweight and free way to test applications that integrate with S3.

Comments are closed.