curious arista and not force10 - and lack of scale up?
Is the storage hardware based on dell too? Given force10 is owned by Dell they probably would of gotten a good deal to be all Dell. Though maybe Force10 lacks the APIs or something.
Couldn't see whether or not the hardware was swappable, the system seems like it could be constrained by the choice of server hardware with the max VM size being the size of one server or 4 cores and 32GB of ram. For many workloads this is fine but databases and stuff often want or need more. Technically I'm sure it's easy to do just no indication whether or not it's possible in the canned integrated solution.
No obvious indication if the system supports HA - I assume it does. things like moving VMs between servers without impact is pretty important, and something that Amazon can't do.
The choice of Nexenta for storage seems good from a cost perspective but as a Nexenta customer(NAS only - very small installation w/SAN back end) I don't think it would be my first (or second, or third) choice as primary storage for a cloud system. One of my co-workers used to work for a Nexenta reseller and has similar thoughts. The system just needs more work.
But then again I would not be at a company that participates in the great race to the bottom for pricing. Those in the race have few options available to them.
Is the system really 100% SSD? The web site seems to make it seem so. I know Nexenta is agnostic to SSD vs spinning rust so technically there is no limitation, just wondering about the integrated offering.
Seems like a nice approach just needs a few more tiers of capacity - bigger servers, fatter storage (especially with the Nexenta tiering/caching - not that I've used that feature nor do I plan/need to ).
Competing with Amazon on pricing with your own stuff is simple as can be for the most part, the critical failing of the Amazon infrastructure is they lack the ability to pool resources and over subscribe your services. Instead they want you to start and stop VMs on demand and have your resource requirements precisely nailed down - guess what, in most cases that is not possible. You can provide all of the infrastructure APIs in the world to make it easy but there's the little complicated part called the application running on top of the infrastructure and it's dependencies and configuration. Most are not built for that and will continue to not be built for that because only a tiny fraction of customers need it and it's really complicated to get right.
Where Amazon and other players get you is selling you on the 'cloud' concept in itself. Which sounds nice - it's the implementation that sucks. Most people looking at this stuff aren't technical enough to know what is going on and only sometimes do they come to a realization that they are way over spending for something that doesn't work as well as leveraging technology you can get in house to do the same thing. You may not have a self service portal and stuff out of the box in many solutions - though most organizations don't need a self service portal. Unless your big enough to have complicated budgets and charge backs between departments and stuff self service portal drives resource utilization down, and costs up because people are under the impression that the resource is unlimited they can just go provision whatever they want.
An extreme example at one company I was at there was more than 200 VMs in EC2 that was costing over $80k/mo that nobody knew what they did. So I killed them all, nobody noticed. There was high turnover in the company and a mentality that the resource was basically unlimited so they spent massive amounts and got terrible results. Management was convinced cloud was the way to go despite wasteage like that. If you have 200 VMs in house not doing anything, resource utilization on them will be much lower, slashing costs to run those VMs. Because resources are shared they aren't taking away much from the pool. In Amazon each of those VMs has a fixed amount of resources.
Good controls are very important to properly controlling costs and maximizing utilization.