The Pros and Cons of Amazon Pay Web Services


When one thinks of Pay Web Services these days, it is hard not to think of Jeff Bezos and his Amazon Web Services. In a nutshell, Amazon provides developers with access to a suite of web services, some pay and some complementary. It is my goal of this post, to analyze these various web services, and use them as a model to discuss Pay Web Services in general. Is it possible to create a reliable business based off of Web Services as a platform?

To start things off, let's look at the various building blocks Amazon provides to developers (and consequently, entrepreneurs). Since I am only evaluating pay web services, only the following services will be considered. These, incidentally, are ordered by how rad I think they are.

  • Amazon Simple Storage Service (Amazon S3)
  • Amazon Elastic Compute Cloud (Amazon EC2) - NOTE: This is totally rad, but only in limited beta so it will not be covered in this post.
  • Amazon Simple Queue Service (Amazon SQS)
  • Amazon Mechanical Turk (Beta) - NOTE: Also in beta, so I won't cover it in here.


Amazon S3 (Amazon Simple Storage Service) is an amazing service. It is a very simple web services interface that can be used to store and retrieve data. In a nutshell, it allows developers to write, read, and delete objects containing from 1 byte to 5 gigabytes of data each via REST or SOAP interfaces. To tangent: I really like Amazon S3 for a number of reasons, ranging from automatic bittorrent support for each object uploaded, to the flexibility it provides for third party developer applications.

Amazon S3 is great in that it could allow any Joe Blow with two-bit programming skill to start selling backup software, and operating as the middle man. Or a web 2.0 website that cannot afford to maintain its own server infrastructure can suddenly have a huge amount of scalability, reliability and capacity within their grasp. Previously, if you wanted to create the next
flickr.com, you really had to do your server hardware homework in advance. Building an application from the ground up as Amazon S3 as your data provider seems both an intelligent and financially sound decision. Considering the fact that pricing is very affordable ($0.15 per GB-Month of storage used / $0.20 per GB of data transferred), it surprises me that we haven't heard of more large scale success stories.

The black eye? Amazon provides no service level agreement (SLA). A SLA typically presents up-time guarantees, and also details the consequences of not meeting those guarantees (As an industry norm, outages usually involve a refund of some kind). Imagine that you build a web application and it is making lots of revenue (High five!!). All of a sudden, all your media (which you are using S3 to store) is no longer available. Users leave your site in droves -- you lose revenue. Clearly, Amazon has a gaping whole in this service that they need to deal with. And, Outages at Amazon S3 are nothing new.

Amazon Simple Queue Service (Amazon SQS) offers a reliable, highly scalable hosted queue for storing messages as they travel between computers. In a nutshell: The Queue service makes it much easier for developers to create scalable distributed applications.

Open source solutions have long provided messaging capabilities; for example, there are
several open source Java Messaging solutions freely available. Despite these numerous open source packages, any implementation would also involve managing an independent hardware environment. This is part of the value that Amazon provides here. Amazon is able to leverage the huge hardware infrastructure to provide reliability, backup and scalability with respect to messaging. All for a cheap price.

The kick in the nuts? Amazon SQS also has no mention of a SLA either. I highly doubt that any enterprise companies will be relying on the SQS service until Amazon can provide some sort of official agreement.

There is no doubt about this: Amazon has provided a sweet platform to develop on, and I suppose one could take comfort in the fact that if S3 or SQS has an outage, it means that Amazon.com is also having an outage. And you can bet the bank that Amazon's highest priority will be bringing that sucker back online. It's the cash cow.

Pros:
- In general, they provides developers / entrepreneurs with a hardware platform that they couldn't otherwise afford
- Provides simple, building blocks for developing robust applications
- Stability, backup, scalability -- right out of the box

Cons:
- No service level agreement (SLA). How can a third party seriously build a profitable application or service on top of something that has no uptime guarantee or refund consequence for severe outages.
- It does not remove the need for a database. It would be awesome if Amazon introduced some variety of database replication to complement their storage service.

So what have we learned (If anything at all) about Pay Web Services?

If you are paying for a web service, you need an enforceable service level agreement. (And for a robust SLA, expect to pay a premium for it.)

Comments

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options