Our advice to new data protection-as-a-service vendors

Being the industry’s first cloud-native SaaS offering gives Druva several years of experience at leveraging the power of the cloud to make a scalable, powerful, secure, and affordable data protection service. We’re glad other vendors are joining us in this dynamic space. In fact, I’d like to offer the following advice to our new data protection-as-a-service competitors.

Lift-and-shift backup is not a long-term solution

Whether you’re a legacy software product, or a newer one built on a converged architecture, your quickest path to SaaS is to simply take the same software that you run in servers/VMs and run it in VMs in the cloud. However, if that’s your approach, your infrastructure costs will be huge. You will then have two choices: price your product higher than the competition or sell the data protection service at a loss. Lose out on sales to competitors or lose out on profits — neither of these is where you want to be as a business. This is why lift-and-shift backup is a short-term solution at best. I’ve written on this multiple times.

Do not use block storage for backups

There is absolutely no reason that you should be using block storage to store backups in the cloud – and that includes performance. Yes, many vendors think that object storage is slower than block storage; however, if your restore performance from object storage is slower than your performance from block storage, you’re doing it wrong.

Block storage costs at least twice per gigabyte than object storage, and you also pay for it differently. Block storage requires you to provision a volume up front and size it appropriately.  The moment you do that, you’re paying for the size of the provisioned volume, even though it may be months or years before you fill it up. With object storage, you only pay for what you use as you use it. This means object storage is less expensive to maintain, as there are no volumes to create, expand, or destroy – completely elastic on-demand capacity that is always exactly the right size.

The best reason to use object storage is restore performance. A restore coming from a block volume reads the data in a single stream; however, a restore from object storage can read from thousands of objects simultaneously – giving you a restore speed faster than anything you can do with block storage. This restore speed is why Druva has won many bake-offs against one of the largest on-premises vendors in the space. (That’s probably why they described us recently as being “very aggressive.”) This is another example of why you have to code to how the cloud works.

Serverless is not the answer to everything

If you’re not going to use the lift-and-shift backup approach (which you shouldn’t), you’re going to need to program to the APIs of dozens or hundreds of various services offered by your infrastructure-as-a-service (IaaS) vendor of choice. Don’t go into your design meetings saying, “We must use Lambda functions,” or, “We must use containers.” Start each design discussion with a list of possible services to do the job, and then select the one that meets the requirements for the lowest total cost. We use AWS Lambda functions, containers, and VMs because each type of compute AWS offers has distinct advantages and disadvantages. Use the most appropriate tool for each job.

What’s great about Lambda functions is that AWS automatically scales the necessary infrastructure to deliver as many Lambda functions as your service needs, but you do pay $0.20 for every million Lambda calls. That might not sound like much, but as the largest data protection-as-a-service vendor, Druva performs millions of backups per day, and each of those will require innumerable Lambda calls. At some point, it’s more appropriate to use a container or VM where you’re not paying for every single function call. This is why the idea that you should use Lambda functions for everything is at best naïve – and yet another way to increase your infrastructure cost and price yourself out of the market.

Make your pricing dead simple

With Druva’s data center backup, customers pay each month for the number of terabytes we store on their behalf in the cloud after source-side global deduplication. Druva’s customers that backup SaaS services (e.g., Office365, G-Suite) and endpoints pay each month for the number of users they are backing up. Both pay a very predictable cost that stays basically the same every month.

There are no VM, storage, or egress charges, like all of our competitors that are running their software in your cloud account. There isn’t one charge for the front-end storage and another for the backend storage. Both of these pricing models result in large spikes for our competitors’ customers, where they really have no idea what their monthly cost will be until the month is over. Customers want pricing that is easy to understand and predictable, and giving them just that has worked well for Druva.

Don’t take the easy path

If you want to get into this space, take the time to do it right. If you take the easy path and take a lift-and-shift backup approach, you will certainly have some people that like that. They’ll get the product they already know in a new way. But you can’t be successful with a cloud-based service unless you program to how the cloud works. So take the time to understand how computing, networking, and storage work in the cloud — then write a product designed to behave that way. Then we can all compute on a level playing field, which is what we all want.

Learn more about how Druva saves you time and money, while providing a data protection service that’s secure, scalable, and always available.