I wouldn't call this immaturity on the part of Cloud especially considering how unique a case this is. Even at its maturity cloud isn't going to get to the 100% perfect platform for all individualized use cases. These kinds of checks/validations have to be handled by the client who relies on them, and it seems like the cpuinfo check is doing just that perfectly fine.
Edit: The promise of cloud hosting is to be highly dynamic and let you scale up or down at a moment's notice. In order to achieve that, there are tradeoffs. It's silly to live with the cons if you don't need the pros. Each tool for it's own job.
Have you tried maintaining some infrastructure over a decade? I did. And I sincerely don't know, which way is better.
There are tradeoffs. Physical hardware doesn't change underneath you, but can fail, require expensive maintenance itself and reliable infrastructure around it (colo). Hosting providers tend to phase out services or even go out of business completely. PaaS limits you, providers change the APIs all the time.
Having been a EC2 user since its announcement and first open beta, I'm actually more and more inclined to think that it IS mature enough to be considered. I'm pretty sure that if I'd try, I can find an AMI from 2007 and it would run perfectly well.
On the other hand from costs perspective, reserved instances are not that expensive, and, unlike regular hosting providers, costs pretty much guarantied to go down, in the long term.
I would actually argue that much of high performance computing (which benefits hugely from advanced processor instructions like AVX and SSE) is just as fit if not more fit for cloud computing than a web backend. Much of HPC is for simulation related work which tends to be ad-hoc and bursty and generally speaking, is more horizontally distributable than web services (i.e. double the # of machines and simulation will run twice as fast). Thus a pool of shared resources (read: the cloud) is far more efficient (thus cheaper) than individual companies maintaining silo'ed compute resources.
Doing that is probably fine for 80% of applications.
Even internally, we have a few crusty applications that have been running in virtual environments since sometime around 2006 without any modifications other than security patching and VM migration as the underlying hardware is refreshed.
That said, if you have a real business requirement for a system that's expected to sit and spin for a decade without care and feeding, that's different. You probably want to use physical hardware that is going to be static OR use a PaaS where the provider in obliged to support your app in it's as-is state for the time that it needs to exist.
In the olden days, companies that provided things like accounting and billing solutions to SMBs and vertical markets (doctors, auto dealers, etc) would put it on an AS/400 or HP 9000 that was reliable and would phone home to call a tech in to replace failed components.
Actually I am building one such service now. The key factor has been realizing how bad the cross-provider toolkits are at really exposing their feature sets, in the places that they don't like to talk about: some of those listed above. Essentially, right now, you have to build it yourself. There are toolkits, but none of them are effective. I emailed an academic working in this area circa new year to compare notes, but am yet to receive a response.
ie: The assumption is that any given provider may fail, any given provider site may fail, any given provider host may fail. You have to have a programmatic, automated response for that.
