I've heard "we tried to move our app to AWS but we couldn't tolerate instance failure so we moved back to on-prem" so many times in the past.
I'm afraid managers are going to see this as an easy way to jump to the cloud and lift and drop their on-prem apps to AWS without re-architecting to handle failures and expect high uptime.
>I'm afraid managers are going to see this as an easy way to jump to the cloud and lift and drop their on-prem apps to AWS without re-architecting to handle failures and expect high uptime.
Of course they will, but that's hardly unique to this product announcement.
In my experience working with many vSphere-heavyfirms investigating AWS for use in production, the lack of seamless workload portability between on-premises vSphere and AWS ends up being one of the major factors that leads to abandonment of any ambitions to adopt AWS, even if there are workloads that can tolerate instance failure.
>Clueless engineers. The AWS instances don't fail more often or any differently than old school servers.
Instance and host reliability aren't the issue here. The issue is that a disgustingly high number of enterprises rely on vSphere High Availability and Fault-Tolerance features to restart VMs or keep them alive when an OS hangs or the host fails, instead of architecting for high availability at the app layer.
To be entirely fair though, vSphere HA and FT are incredibly friendly to the bottom line relative to rebuilding apps that simply weren't designed for HA.
My bad. I didn't get that you were talking about the built-in vSphere HA. This thing is truly amazing =)
I thought it was the usual complain about AWS instances dying and needing to be replaced on regular basis. That thing is a myth. An instances can run for years without any issues, if noone stops it manually.
That said, you're right, it's not any more common than hardware failure. But that's common enough. Keep a backup and don't expect your stuff to always be there no matter what.
Whether Amazon VMs go for years seems to be a matter of luck in my experience. You need to bake in HA for any service you really depend on either by having copies or ability to start new ones at will.
You can also do that in AWS using CloudWatch Auto Recovery functionality. Of course it's still better to design for HA, but if it's not possible Auto Recovery should be able to add a bit of resiliency.
> High Availability and Fault-Tolerance features to restart VMs or keep them alive when an OS hangs or the host fails
"High Availability and Fault-Tolerance" would hopefully involve more than restarting the VM.
I mean, you have like bajillion people that solved the above "challenge" with a three-line bash script.
And not one of those people would call it "High Availability and Fault Tolerance". It's just a small shell script.
> vSphere HA indeed restarts the VM on a different host with its storage, network, etc. intact. This is so trivial that EC2 didn't offer it for years.
How often is your hardware fucked up enough that you need to move to another machine?
Honestly, if that happens often, there is something wrong with your hardware or your hardware provider or something.
On a 900-servers fleet on AWS, yeah, sometimes it would warn me that "the server needs to be retired" or whatever. Then I stop the server, then start it. Sure, inconvenient, but happens maybe... once a month? In fact, the frequency is decreasing so maybe once every two months?
> vSphere FT replicates a VM while it runs so that it doesn't even notice the failure of one of the underlying servers.
That would be great, right? You paid some $ to VMWare and now your servers never go down?
"How often is your hardware fucked up enough that you need to move to another machine?"
VMware HA runs quite a bit IME for a variety of reasons (network failure, storage issues, etc). "The network is reliable" is a classic fallacy of distributed computing.
More often used is Vmotion and DRS which transparently moves VMs around physical hosts at runtime with no downtime and very minimal performance hit . Servers, switches, and fabrics need maintenance, firmware upgrades, hypervisor OS patches, etc. in most data centers.
"That would be great, right? You paid some $ to VMWare and now your servers never go down?
Excuse me but, that did not happen."
VMware FT is used in almost every major company on the planet that runs virtualized database instances that can't go down. It is serious technology.
AWS has mopped up the IT industry to date, and this is them going hard after Microsoft which is making inroads.
Enterprise data centers are probably much less reliable than AWS. My take on HA & DR in general is that it's the kind of thing that you might use once in your career but it's probably worth it since it saves you from being fired.
Networking and storage have been traditionally the biggest differences with cloud vs. on prem. Bandwidth and latency has been quite variable on AWS. Disk I/O and IOPS sucked for many years.
That said in recent years it's much less of a problem , though the fixes tend to require a lot more expenditure for provisioned IOPS, dedicated hardware instances and 10 gigE network instances. But then nearly any legacy shit app can run in AWS ...unless it needs some crazy specific configs like live hardware assisted disk replication, or VMware FT levels of resilience.
There are other advantages to this beyond an alternative deployment method: Many vendor-supplied application stacks only support ESX. Yes, it is possible with some hacking, to get them on to EC2, but at the expense of losing vendor support.
Furthermore, with this comes vMotion. EC2 has yet to implement live migration.
If I understand it right, this gives companies ability to shift their services to and from AWS relatively painlessly. Do other cloud provides offer anything comparable?
Openstack doesn't have the in-product hooks to detect hardware failures on the host machine to prompt an automatic, vm-state preserving live migration to other hosts.
If you are using kvm w.r.t. openstack, the vm machine actually is suspended by way of acpi, then moved, then unfrozen again. VMware doesn't do that in vmotion. All your problems with clock skew, dropping of network traffic are lessened (they don't completely go away) with vmotion.
Those are all absolutely valid options, none of those "have this ability".
Nothing in the open source world currently matches NSX's ability to extend the network from on-prem to the cloud. I really wish they did, but it's not even a discussion.
Sorry, maybe I am misunderstanding what feature you are talking about. Al of the solutions mentioned are ones you can run on your own hardware, as well as their respective 'cloud' services, using the same APIs. Are you wanting some sort of live migration of vms between the two?
> 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]
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.
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?
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.
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.
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).
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
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.
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.
Yet AWS is much cheaper than vCloud Air. Although it's hard to compare, due to the way it's usually bundled with ISP agreements.
This service will either need to choose between being much more expensive than raw AWS, and effectively killing Air overnight, regardless of the current claims.
Ehh, in the end, cloud orchestration is only going to get easier (lowest common denominator of primitives) and as long as you don't marry yourself to cloud provider-specific tooling, you'll be able to push your VMs and/or containers to where you can optimize for performance, cost, whatever.
I think containers are hyped _far greater_ than the benefit that they provide, and I still think it'd be swank if you could have CDNs retrieve containers and run them at the POPs if your workflow allows for it.
This is huge for a long list of middle market companies who shudder at the prospect of moving a data center from their on premise closet to a hosted solution while leveraging the same exact vSphere infrastructure they already have sunk time and money into.
I have always been impressed with the amount of lock-in some companies have gotten themselves into with VMWare. Every place I've worked at which used VMWare, their tooling had a stranglehold on the entire business, with the exception of some totally greenfield stuff done on GCE or AWS.
You're not familiar with the operational costs of most Fortune 100 data centers (and more importantly, basic services built on top of a reliable infrastructure) if this sounds eye-watering expensive. Almost everyone I've ever moved to AWS is pretty bad at O&S and pays at least double the monthly costs of AWS for far worse systemic reliability. Add in AWS support being far, far better by every metric than whatever crappy offshore helplessdesk was contracted and it's a no-brainer. Delta's recent debacle just wouldn't have happened, for starters, and that's costing them more than a billion dollars in raw costs.
I am familiar enough with that. Traditional datacenters are a money sink and anything will do cheaper, more reliable and easier to manage.
But why AWS + VmWare? That makes no sense.
If you want to have special snowflakes, you go for SoftLayer + VmWare. You can be as exotic as you want with that.
Otherwise, just use AWS. And you get the benefit of all the services that VMWare don't and can't provide. (servers, storage, load balancer, databases...).
Better, go for GCE. It's the same as AWS for 20-50% cheaper. :D
AWS + VmWare is the worst of any world. It's not even a real solution. It's an experimental idea waiting to be released and go though years of bugfix/improvements.
If you're my customers? AWS + VMware makes plenty of sense because you have gazillions of dollars sunk into vSphere management and automation that's narrowly tailored to the enterprise's needs. Making the case that all of that prior work should be abandoned or phased out in favor of going all-in on AWS is a difficult up-hill battle in these situations.
>AWS + VmWare is the worst of any world. It's not even a real solution. It's an experimental idea waiting to be released and go though years of bugfix/improvements.
This isn't even a real argument. The same could be said of any new product anywhere.
VMware is the de facto private cloud incumbent and switching costs are incredibly high, and AWS is the de facto enterprise public cloud incumbent with perhaps even higher switching costs and the same kind of inertia as legacy on-premises systems. What this signals to me is that the "hybrid cloud" management voodoo software that's been peddled for years by various vendors isn't sufficient enough to keep VMware viable enough on its own, and VMware wants to partner with the incumbent enterprise public cloud for continued relevance rather than to risk partnering with anyone that's competing against AWS.
GCE has so little of the enterprise compliance and security solutions engineering bureaucracy that enterprises love to spend tens of millions of dollars and years doing POCs with it's just not viable at this time.
Say I have 30,000 VMs deployed in my VMWare infrastructure. I have a good licensing agreement with them and have thousands of applications.
By just shifting workload to AWS without doing anything to the VM, I can save a ton of money. In my case, for every dollar I spend on AWS/VMWare, I could probably avoid spending $2.50 in data center buildout costs and $3 in application rationalization.
With Softlayer, you're inviting IBM into your house, which is rarely a good idea. Give them an inch, they take a mile.
> With Softlayer, you're inviting IBM into your house, which is rarely a good idea. Give them an inch, they take a mile.
Not a very accurate statement. SoftLayer is IaaS, everything is monthly or hourly on the compute, storage, and networking side. You pay SoftLayer monthly for VSphere 6 licenses with zero contracts.
> Traditional datacenters are a money sink and anything will do cheaper, more reliable and easier to manage.
This is 100% false. Unless you are running your infrastructure at less than 50% utilization 24/7, it will ALWAYS be more expensive to go to "the cloud".
Depends if you can replicate to S3 and spin up as a DR site when you need it, you will be paying for it, but it shouldn't kill the bank for the corps who would look at this.
That would be the killer use case, to use AWS low cost storage while being able to stand up your entire infrastructure.
That was my first thought... though I do think that some of VMWare's orchestration tools are a bit easier than AWS's... just the same, I'm thinking, wow that sounds expensive. Now I'm waiting for Oracle to buy out VMWare if this even looks like it will succeed.
Not totally kidding. There's a subset of the market for whom being more expensive both in complexity and cost is seen as an obvious sign of a more "serious" "enterprise" product.
I think this is just embracing and extending. VMWare has the on premise infrastructure market cornered for the most part. But if they don't leverage that and pivot into using off premise stuff, then they stand to lose ground to Azure, as you can orchestrate just about all of Azure from Active Directory/Powershell.
I'm afraid managers are going to see this as an easy way to jump to the cloud and lift and drop their on-prem apps to AWS without re-architecting to handle failures and expect high uptime.