Comment by contingencies | Hacker News Reader

Comment by contingencies | Hacker News Reader

Parent Full thread

Yep. Cloud stuff is still immature.

While guarantees that would remove all such issues ("leave me on system 'x' with no shifting sands forever!") are costly and therefore undesirable within a cloud context, this describes but one example of an edge case that could be elegantly handled by informing the node that it must go down and come up again a while later, after which its swapped-out guts with the potential to cause issue might be more easily resolved.

I would generalize this in to a broader statement: "Environment-related guarantees do need to be further specified on commercial cloud providers, and a better interface given to clients when changes are scheduled".

Other areas of cloud APIs (particularly cross-cloud) that are presently missing: legal jurisdiction, site/availability zone enumeration, available hardware configuration enumeration (including network bandwidth policies), resource guarantees (including network bandwidth).

I recently posted these as bugs to CIMI @ deltacloud's teambox - https://teambox.com/#!/projects/deltacloud/task_lists

I don't think the hardware on the individual instances are changing, it's that Amazon is putting new hardware online in some of the older instance classes and you can't predict which one you'll get when you spin up an instance.

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.

Would you run a service on EC2, that you are planning to run over, say, next decade? And want it to run in a setup&forget mode?

Would you use a hammer to drive in a screw?

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.

I agree. I think, if I'd create an AMI image now, I'll be able to boot it in 2018. But how about 2023?

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.

>this describes but one example of an edge case that could be elegantly handled by informing the node that it must go down and come up again a while later, after which its swapped-out guts with the potential to cause issue might be more easily resolved.

Huh? They manually and explicitly stopped their own instance and then started it up again. Given that you don't pay for stopped instances it's sort of obvious that they don't really exist but are recreated upon being started again. What does amazon have to do with this?

To me, it's not an edge case so much as missing the meaning of "stopping" and "starting" an instance on ec2.

Amazon has to do with it because their hypervisor is set to disable a feature but still report it as available. THAT's the bug here.

Reply on news.ycombinator.com