Hacker News Reader

Comment by Alupis | Hacker News Reader

> shift their services to and from AWS relatively painlessly

Couldn't you already do this? AWS lets you import/export in OVA (an open, standardized format which is cross-hypervisor compatible) and VMDK (VMware's proprietary virtual disk format)[1]

[1] http://docs.aws.amazon.com/vm-import/latest/userguide/import...

View on HN

Aside from cases where you can just shoot a guest VM in the head and respawn it elsewhere (still relatively uncommon, especially in big vSphere shops), vSphere -> AWS has historically been a mostly one-way migration path, whereby the guest VM that's migrated lands in a new ecosystem that is beyond the reach of whatever vSphere management tools you have on hand (unless you're doing very heavy customization and extension of vRO+vRA).

This move opens the gate to more seamless migration of workloads between on-premises vSphere clusters and AWS, and extends native vSphere management and configuration functions into AWS. For big vSphere shops with large investments in the platform (especially those running legacy workloads), this product offering is a very, very big deal. If the costs are right, it will put true hybrid cloud operating models into reach of a lot of Enterprises for which the pricing or level of effort to get there previously didn't make sense.

shoot a guest VM in the head? That particular wording indicates you might have been doing Linux HA a little bit too much :)

No, actually, it's very common terminology among people managing large enough installations to "treat servers as cattle, not like pets". Re-deploying the entire service, with a copy of the previous data or without, should be a common exercise.

Is it really? I've never heard this particular wording before (and neither had Google, mind you) but it very strongly resembles Shoot The Other Node In The Head (STONITH).

We (I work for AWS) call it "Architecting for Failure", but yes, you could call it that too. =)

In an ideal application, instances are a commodity. Not every workload is there yet, so there's a need still for individual instance recovery. But it's something we and our customers strive for.

Big vSphere shops with large investments in vSphere should stay in their private datacenters. It's not worth migrating everything.

If they want to innovate. They can move to IBM SoftLayer + VmWare on top, which is allegedly a solid offering, while keeping their ways of doing things.

Why should they remain in their private datacenters? In AWS they have access to a wealth of platform services like fully managed relational and NoSQL databases, autoscaling, resilient queueing, data movement, analytics, and data warehousing services.

The value in migrating is that you get access to the same VMware hypervisor and ecosystem, but now you have access to a wealth of new data services that are fully managed and much lower cost than building your own.

I know this is hard to believe, but in the early 1900s, any large business had a power generator in the basement, because the power grid was unreliable and daily outages were common. How many businesses today have their own power generators? In 2050, how many businesses do you think will have their own datacenters?

Kinda sucks for images that license to the network interface. They added elastic network interfaces, but you can't use those for eth0 (which a lot of software licenses to), so you're still screwed

How do you mean?

I've never personally dealt with software that licenses to a network interface (and the idea does seem silly...), so I can't fully comment on your situation, but it seems you could find out what specifically the license is attaching to and set that up again (if it's MAC, you just override the MAC, etc...).

The software I've used that bound to the CPU (which is silly as well) always had a mechanism to "de-register" the software specifically for migrating to new hardware. So you could setup your vm, install all your software, etc... then de-register the software (but leave it installed). Make your "appliance" image (OVA), import to the new "cloud" and re-register your application.

>I've never personally dealt with software that licenses to a network interface (and the idea does seem silly...)

This is super, super common with legacy software products narrowly scoped to very specific business functions.

Very common with niche analysis/grid computing apps:

https://en.wikipedia.org/wiki/FlexNet_Publisher

I've never personally dealt with software that licenses to a network interface (and the idea does seem silly...)

This was super super super super fun on IRIX when NIC died. Usually in the midst of work chaos.

I'll just be happy when I can stop dealing with products that license by USB dongles. Try putting THAT in AWS.

I'm not sure you understand what was announced. The VMware Cloud on AWS will use standard vSphere Distributed Switch and NSX overlay networking. This means you can completely control what MAC and IP addresses get assigned to all of your VMs, and can hard code MAC addresses for those troublesome applications that hard-code their license to your NIC's MAC address.

tl;dr In the VMware world you've always had the ability to specify your own MAC and IP address. In VMware Cloud on AWS you'll have the same ability.

re-reading my comment, I have no idea what I was thinking at the time... thanks

Reply on news.ycombinator.com