Tech/Engineering

The pitfalls of cloud-washing to lift-and-shift backup to the cloud

January 24, 2020 W. Curtis Preston, Technical Evangelist

The benefits of the cloud for backup and recovery are significant, leading many data protection companies to introduce “cloud products” — which are at best an exaggeration of being cloud ready. These products advertising themselves as “cloud” are doing damage to the reputation of the value of the cloud.  As companies deploy these products they find they are reaping few of the expected benefits of cloud because the product was not actually designed to leverage how the cloud works. The product the customer purchased is what many call cloud-washed. Cloud-washing is a company that chooses to lift-and-shift an application to the cloud without changing the design of the application.

I often get blank stares when I talk about the concepts of lift-and-shift and cloud-washing (or their antonym cloud-native). Who cares how a product works underneath, as long as it works? The reasons it matters how a product works in the cloud is cost, management, and scalability. Designing for the cloud makes all of these variables better, and cloud-washing either makes them worse, or at best doesn’t change anything.

Lift and shift costs more

When one takes a software product designed for the datacenter, and lifts-and-shifts it into the cloud, many call that cloud-washing. The software is going to expect what it had in the datacenter, which is VMs running 24 hours a day, storing data on block storage – just like it would in the datacenter. For example, the cloud-washed version of one popular clustered backup product requires AWS customers to use a minimum configuration of a cluster of four VMs hosted on m4.xlarge Amazon EC2 instances, each with at least 3 TB of block storage. Since storing data on a single backup system violates the 3-2-1 rule for data protection, you’re going to need two of these clusters. The AWS simple cost calculator says that the estimated AWS cost of this system would be a one-time payment of $17,606 and a monthly cost of $1,320, for a total annual infrastructure cost of ~$33K.

Even simple design changes (not possible in a lift-and-shift model) can save huge amounts of money. Consider a product that only runs VMs when backups are running, and uses Amazon S3 storage instead of Amazon EBS. S3 automatically stores data in three separate locations, so you don’t need two backup systems to comply with the the 3-2-1 rule. Assuming no other major differences between the backup systems, you’d need four VMs on m4.xlarge EC2 instances, and the VMs would run for approximately 8 hours per day. We’ll give it the same capacity as the other system, for a total of 12 terabytes of S3 data. AWS says the annual cost of this should be ~$9,288 for the VMs and another ~$4,000K for S3. (That includes 12 TB of S3, and 10M GET and PUT requests per month.) That’s an annual infrastructure cost of $13.5K vs the $33K bill for the other solution. That doesn’t even take into account that S3 will be billed on-demand, which will significantly lower the cost as well.

Some backup vendors have made steps toward being more cloud-friendly. For example, supporting object storage as the primary backup store (e.g. sending all backups to S3), which would save about $11K/year from the previous $33K estimate. It’s a step in the right direction.

But consider what would happen if you really designed for the cloud, and started using serverless resources (e.g. Lambda), noSQL database services (e.g DynamoDB), other pay-as-you-go database services (e.g. RDS), and even less expensive versions of S3 (e.g. S3 Glacier Deep Archive). Imagine the infrastructure cost savings if you truly designed for the cloud. Cloud-washing may make it easier for the vendor to put “cloud” in their marketing, but it has a real cost to the customer.

Lift and shift is harder to manage

Software that designs for cloud services (instead of just running software in VMs) are easier to manage than products that just run in VMs and use block storage. Serverless resources require no management on the part of the user, and on-demand services like S3 and DynamoDB only require you to insert and delete data. Block storage, on the other hand, is still pretending to be a disk drive, requiring you to monitor free space and adjust volume sizes as appropriate. Adding space to block storage often requires downtime. VMs must be monitored for security reasons and patched accordingly, versus serverless resources that require no such work.

Systems designed for the cloud can also leverage the concept of multi-tenancy and be offered as-a–service, where the customer maintains no infrastructure at all. Imagine the idea of a backup and recovery environment where you manage none of the backend infrastructures. Cloud-washed, lift-and-shift systems can’t do this, because it places you at risk of having your data compromised by the vendor, so these products run in the customers cloud account. (This is probably the dead giveaway that you’re using a cloud-washed product, by the way.)

Lift and shift is harder to scale

Products designed for the cloud are able to take advantage of cloud scalability features for each of the services they utilize. These products can automatically run as many (or as few) compute resources as needed to get the job done at that moment, even if it means spinning up thousands of VMs for a few minutes. Object storage (e.g. S3) isn’t just better protected and easier to manage than block storage, it also automatically scales to meet whatever storage requirement you have — while you only pay for what you use. Database services like DynamoDB charge you only for inserts and queries, and can perform as many of those as you need as often as you need — without scalability limitations.

Lift-and-shift products, on the other hand, have all the same scalability issues as a typical datacenter configuration. At some point your backup cluster will not have enough compute, storage or bandwidth to get the job done. For example, the amount of bandwidth your VMs have in the cloud is usually tied to the type of VM you’re using. This may require you to upgrade to a more expensive VM to get more bandwidth. You also may need more VMs and storage, each of which will need to be created in your cloud vendor, then you’ll most likely need to upgrade the license of your backup software as well. There are also upgrade cliffs, where you can’t upgrade the version you’re using and must upgrade to the “enterprise” version, often at a huge expense and migration effort.

Don’t fall for cloud-washed backup products

It may be the most recent “advancement” your backup software company is offering, but it will cost you far more than changing to a product actually designed for the cloud. If your backup product is requiring you to run backup server VMs 24×7 and store your backup data on EBS —run, don’t walk, to a vendor that actually understands the cloud.

Learn more about Druva Cloud Platform, built on AWS, delivers the benefits of the cloud.