Cloud mania continues at VMworld. Some CIOs still seem to think that simply migrating all of their VMs from on-site VMware to VMs in AWS (or some other provider) is going to be easier and save the money. There wasn’t any big news today from VMware, so this blog will focus on some conversations in the Druva booth about just this topic.
An IT person mentioned that his new CIO can’t believe they haven’t moved everything to the cloud yet. He believes it’s only going to take one or two months to move their huge data center into the cloud, after which they will save piles of money. He has no plan to re-architect their systems in order to take advantage of how the cloud works; he’s just going to move his VMs from VMware to either VMC or EC2. It just doesn’t work like that.
Moving any application – let alone all of your applications – to the cloud without redesigning it for the cloud will do nothing but make things more expensive, and this really isn’t that hard to understand. It’s the equivalent of moving from a car that you are making payments on, and swapping it with another car from a rental company. You will have essentially the same functionality; you will have a car that is available for your use 24×7. But the fact that you are allowed to return that car at any moment is built-in to the cost of a rental. That’s fine if you’re using it for a day or two. But think about what it costs to purchase a car and what it costs to rent a car long-term; you should have some understanding of how much more expensive the cloud will be because it’s a very similar pricing model.
The pricing model for the cloud is built around the idea that you can turn it off at any time and walk away with no commitment. That works perfectly if you’re going to be in the cloud for a day, a week, or even a few months (i.e.like a rental car). But if you simply move all of your VMs from on-site to similar VMs in the cloud that will reside there permanently, you are going to pay dearly for that resource.
If you are going to move into the cloud, you need to redesign your application to leverage cloud functionality. If you do that, you may indeed pay less. For example, if you are able to use the AWS load leveler to increase and decrease the number of VMs that are running at any given moment in order to meet the performance requirements of your application at different times in the day, you may save money. But, if all your VMs are just going to run all day long, that isn’t going to happen.
Druva sees this with our competitors all the time. They say they have a “cloud” version of their product, but really all they have is software that can run in a VM in the cloud, or perhaps a virtual appliance that runs in the cloud. Because their products were designed for the data center and not the cloud, these VMs will run 24×7 and use block storage (EBS). In contrast, Druva only uses S3 for our customer data and automatically scales the number of VMs that we need up and down throughout the day in order to meet the demands of all of our customers. They never see these VMs, nor do they manage them. All they see is a service. Running only the number of VMs that we need at any given moment reduces our costs, a savings that is reflected in our lower cost when compared to competitors. This is what we mean when we say you can save money in the cloud if you design your application for the cloud. But if you don’t do so, all you will do is add cost.
Hafþór Júlíus Björnsson (a.k.a. The Mountain from Game of Thrones) continued to amaze people yesterday. It was a lot of fun seeing all of the reactions to the thousands of people that took a picture with him. He even put yours truly in a chokehold. If you didn’t get a chance to take a picture with him, he will be with us at VMworld Barcelona and AWS re:Invent. We will see you there!