Pensieri di un lunatico minore

Amazon, get out of my head

Besides offering both an amazing shopping experience and the leading cloud computing offering, Amazon apparently also owns a mind-reading robot. I say this because today, Amazon announced persistent disk volumes. While they’re not available yet, they are coming very soon. There’s a couple of observations I’d make about what’s there, and what’s missing at this point. First the great things:

Familiarity As far as I can tell, it looks to be a familiar structure with some twists. This means that applications should be able to run unmodified on this new capability.

Public Discussion I think the recent pattern that Amazon has demonstrated, with explaining and exploring new features publicly prior to announcement, is one to be applauded in a company. While this won’t work for everyone—often the user has no idea what they need—it does work well to polish up the last bit of a service offering.

So what’s missing? What would I like more information on?

Technology Not that it matters overly, since it’s only exposed via web services, but I’m guessing this is an iSCSI service. It might be FCoIP, but I doubt it since we’re not having to worry about non-UNIXy traffic (i.e. FICON).

Pricing The suitability of this solution will come down to cost. As with S3, it’s likely that there’s going to be multiple components to pricing, but above the cost of storage itself, I’m wondering how transfers will be accounted for. This could have the biggest impact on databases that do an enormous amount of reading and writing. While you could simply ignore utilization and charge only for the storage itself, I think that unfairly penalizes people who are “sane” with their read/write patterns.

Performance The big elephant in the room is performance. I’m sure it’ll be acceptable for 99% of applications, but it would be nice to understand that rough performance model of the system. Also, can they be put into RAID arrays to speed up sequential reads/writes?

Reliability Amazon has done well at demonstrating a high level of reliability, but I think it would be nice to know a little more about what’s underneath the volumes, if only to better recognize the risks.

Snapshot Format It would be useful to fully understand the snapshot format that gets written. I’m assuming it will be very similar to what is used for AMIs, but documentation is key. Since S3 only supports objects up to 5GB, obviously many situations will require splitting this up. This would accomplish two things: 1) Protect against long-term tie-in with Amazon, 2) Allow for pulling down snapshots to debug locally.

Snapshot Timing How long is it going to take to snapshot large elements? This has two phases. First, the “marking” of a point in time to snapshot. The second is the actual movement of the snapshot to S3. The first is important because, at least in the case of many applications like databases, you must quiesce the database prior to snapshotting for best effect. If this is less than 1 second, then it’s great. If it’s longer, then hiccups could happen. The second simply tells you what your exposure window is.

All in all, this represents the last major piece of the puzzle to adoption. There’s other things that would be nice, and perhaps I’ll write about those another time, but these give you everything you need to take existing infrastructure and “move it into the cloud”. I think it’s clear that Amazon intends to be the player in this space, and isn’t content to leave a great offering alone.