Another announcement from last week that got strangely little attention was Amazon’s introduction of EC2 Reserved Instances. Now reserved instances in the cloud may sound like an oxymoron but it is simply guaranteed capacity. You pay an upfront fee for the guarantee that your instance will be availabl and then a lower ongoing usage fee.
Amazon clearly has a ton of usage information on EC2 available that let’s them price this fairly aggressively. For instance paying a 1-year guarantee fee reduces the ongoing usage fee enough to result in a total fee reduction of 33% (when you amortize the fee you get to 6.7 cents per hour versus 10 cents per hour without paying a guarantee). Paying a 3-year guarantee fee results in a 50% reduction of effective fees. EC2 was reasonably cheap before, but now it will be really cheap for folks who use it a lot.
This is of course a direct stab at the heart of the dedicated hosting industry. Some of the dedicated players are ramping up their own cloud offerings in response, such as Rackspace with their Mosso offering. Mosso is promising server availability for as little as 1.5 cents per hour, which will clearly cannibalize Rackspace’s dedicated offering.
All of this is great news for startups because it is further driving down the cost of hosting. At this point I am encouraging everyone who is starting up to write for the cloud from day one. In fact, I think it is time to be somewhat suspect of a technical team that is not doing that.
One issue that this brings up is of course the question of cloud lock-in and how to best avoid it. There are a whole bunch of startups working on this, including Right Scale, Standing Cloud, enStratus, cloudkick and others. I would say that it is very early days for these offerings as the underlying clouds themselves are still evolving rapidly, new cloud offerings are still emerging and there are no standards to speak of. So it is worthwhile trying these services out and seeing if they help simplify tasks (and maybe supress some of the issues described by Brad Feld here and here). More importat though is to architect the service itself to be native to the cloud and to internally abstract from cloud specifics as much as possible (just like you shouldn’t sprinkle unwrapped SQL calls throughout your code it is not a good idea to do the same with S3 references).
