We did talk about something basically like what you describe for both slicehost and RAX, but it really doesn't solve the problem. Take that EC2 definition itself (which is frozen in time in 2007, surprise surprise), how many 2007 Opterons are there on the market now? none, they are using completely different CPUs and they've benchmarked them to be roughly equivalent, but by what benchmark? performance just isn't that simple to benchmark and there are hidden tradeoffs.
Regarding the guaranteed capacity, this is another one we spent a lot of time thinking about. At the time EC2 made the call of guaranteeing CPU share by hard-limiting the ceiling of performance by any VM. We (slicehost and RAX) took the opposite approach of weighting CPU by vm size when under contention, but allowing for burst-ability to full core power when the box was idle. That meant that in the case of low-ish utilization customers Slice/RAX VMs had a higher higher average performance but EC2 had more predictable performance.
It's a super interesting tradeoff. People would benchmark us and we'd come out way better one day but not so hot the next and that was the reason why. The flip side of that was that EC2 is stranding CPU capacity on physical hosts that are full of underutilized VMs. Even without us describing this well to the market, customers and workloads adjusted and customers and use cases migrated to each provider according to better fit (higher 'average' performance with tolerance of variability go to RAX, hardline predictable guarantees go to EC2). We had some video transcoding services that could not deal with the volatility and preferred lower performance that was predictable (and therefore kept a lot of workload on AWS).
A similar tradeoff where AWS did it one way and we did it the other is around the expectation for persistence on local disk versus ephemeral VMs. Persistence (what we did) was more like what people were used to. ephemeral is more 'cloudy'. EBS as well as hosted datastore services mitigated the difference, but the AWS approach required legacy customers and applications to re-architect for cloud and ours was more friendly to the transitional customers or people that just wanted classic feeling hosting on demand. The AWS bet was right in the sense that more of the usage of cloud (and everything actually) is in the future and not the past, and the choices we were making were more as a gap solution (but with eyes wide open about that).
Regarding the guaranteed capacity, this is another one we spent a lot of time thinking about. At the time EC2 made the call of guaranteeing CPU share by hard-limiting the ceiling of performance by any VM. We (slicehost and RAX) took the opposite approach of weighting CPU by vm size when under contention, but allowing for burst-ability to full core power when the box was idle. That meant that in the case of low-ish utilization customers Slice/RAX VMs had a higher higher average performance but EC2 had more predictable performance.
It's a super interesting tradeoff. People would benchmark us and we'd come out way better one day but not so hot the next and that was the reason why. The flip side of that was that EC2 is stranding CPU capacity on physical hosts that are full of underutilized VMs. Even without us describing this well to the market, customers and workloads adjusted and customers and use cases migrated to each provider according to better fit (higher 'average' performance with tolerance of variability go to RAX, hardline predictable guarantees go to EC2). We had some video transcoding services that could not deal with the volatility and preferred lower performance that was predictable (and therefore kept a lot of workload on AWS).
A similar tradeoff where AWS did it one way and we did it the other is around the expectation for persistence on local disk versus ephemeral VMs. Persistence (what we did) was more like what people were used to. ephemeral is more 'cloudy'. EBS as well as hosted datastore services mitigated the difference, but the AWS approach required legacy customers and applications to re-architect for cloud and ours was more friendly to the transitional customers or people that just wanted classic feeling hosting on demand. The AWS bet was right in the sense that more of the usage of cloud (and everything actually) is in the future and not the past, and the choices we were making were more as a gap solution (but with eyes wide open about that).