Consider Microsoft Exchange. If you wanted to move it into the cloud, how would you do it? Would you license Exchange and run it in a VM in the cloud? You would need to pay for and manage a cluster of VMs running all the time, pay for and manage Microsoft Windows and Exchange — as well as make sure that you keep the system secure from viruses and ransomware attacks. Or you could use Office 365. Why in the world would you do the former if you could do the latter?
There may be reasons other than cost or functionality that a company may want to run and manage their own software — even if it’s running in AWS VMs. But there is no doubt that this is a very different experience than simply using a cloud-native service like Salesforce or Office 365. In addition, running software in always-on VMs will cost a lot more. More on that later.
I had a conversation with a friend who recently started working at one of Druva’s hosted competitors. He was saying he was a solution architect. I mentioned that we didn’t really have those (at least customer-facing ones), as our customers don’t have anything to architect. They install a piece of client software on each server, laptop, mobile device, or VM to be backed up and point it at our already-architected, automatically scalable system. For example, I know of a large Druva customer that decided to go from backing up a few thousand laptops to backing up 20,000 of them. All they had to do was push out the software to the other laptops. Our system did everything else. Obviously, Druva has architects in the background, and a lot of design and development is required, but it’s Druva’s responsibility — not our customers’.
Advantages of licensing backup software
Data Management as a Service (DMaaS) is not the only way to go. The other method, that of licensing and installing your own software on VMs or physical servers, is a long-standing model that comes with its own pros and cons. Let’s first take a look at the advantages of this approach.
Support of extremely large data centers — There are some applications that are too big to back up to the cloud. “Too big” is relative, of course, and depends on the total amount of data, the daily change rate after deduplication, and the amount of available bandwidth. For example, if you’ve got 10 petabytes of data in a single application, you might have difficulty backing that up to the cloud. Druva could use our seeding option to get the first 10 PB to the data center, and we could meet your RTO requirements with our CloudCache product (at no extra cost), but if the amount of data that changes each day (post dedupe) is more than you have bandwidth for, it’s not going to work. The laws of physics simply aren’t in your favor. If you use a traditional backup product, however, you could create a very large hardware configuration that should be able to back it up. This is why I’m listing this as the main advantage of such systems.
Having said this, the reader might be surprised at the size of some of the data centers that back up to the Druva Cloud Platform. We do have customers that have petabytes that are being protected by our services. This is why Druva’s experience is that environments that can’t be protected by the Druva Cloud Platform are becoming an edge case and are increasingly rare. We also believe that the data center of the future is much more “cloudy,” so it doesn’t make sense to focus on this edge case at the expense of cloud-native support.
It’s also important that this advantage only applies when talking about backing up an app to its own data center. If you’re considering backing up your data center to VMs running in the cloud, this advantage no longer applies. That product will have as much trouble getting its data to the cloud as Druva would.
Variety — There are certainly more traditional backup & recovery software products, and many of these products have had decades to develop their offerings. You might find more support for a particular platform, especially platforms outside the current norms of Windows, Linux, VMware, and Hyper-V. You might even be able to find multiple products to support you, allowing you to pit one against the other during price negotiations.
In contrast, Druva is the only company that does what we do. There are cloud-native offerings that can back up endpoints, such as laptops and mobile devices. There are others that can handle SaaS apps like Salesforce and Office 365. There are even cloud-native products that are designed to back up VMware, Hyper-V, Windows, and Linux. Finally, there are starting to be products that can handle native data within the cloud, such as EC2 data. You might occasionally find a product that does more than one of these things, but Druva is the only company that does all of these things and delivers it as a service in the way Salesforce delivers theirs. With Druva, you won’t have to contact your vendor, change your licensing, and create more VMs in a public or private cloud in order to expand your system.
What about fast restores? — There is a perceived advantage that having an onsite solution results in faster restores, since a cloud solution would have to pull data down from the cloud. However, Druva Cloud Platform has a no-charge option called CloudCache that caches hot data on an appliance of your choice and acts as a local store for more immediate recovery purposes. We find this satisfies most companies’ RTO needs, but the heart of the system still remains in the cloud, making it much easier to have central policy management and visibility across data regardless of sites, users, and devices.
Disadvantages of licensing software
Licensed backup software costs more to buy, run, and maintain than the Druva Cloud Platform. This is due to a number of disadvantages of licensing software. The reasons behind these advantages come down to the fundamental difference between data centers and the cloud. Infrastructure products like software can assume the servers or VMs on which they run will always be on, so they do not build into the software the idea of turning off unused resources. You also do not pay for every bit transferred across the network, and storage is also cheap. Products designed for the cloud know that every transfer and every byte costs money, so they work to reduce these operations when they can.
Lack of on-demand scale — Our competitors’ customers need to contact customer support if they add enough additional backup clients to require a backend configuration change. It will more than likely result in a change to their licensing structure and require a contract negotiation to pay for the additional licenses. Then someone (the vendor, customer, or both) must configure additional VMs and storage to handle the additional capacity.
In contrast, Druva automatically adds more nodes as customers scale, and all backups are stored on automatically expanding S3 storage. There is nothing a customer has to do to double, triple, or even decuple (10x) the number of systems or terabytes they are sending to Druva. There’s not even anything they have to do from a licensing perspective. An unexpected increase in the number of terabytes stored on Druva’s storage would just consume their purchased credits sooner than anticipated. The worst this might mean is they need to negotiate their contract renewal sooner than planned — but they don’t need to do anything to start backing up more systems (save installing the client software and adding each new client to the configuration).
Always-on VMs — If you run backup software in VMs hosted in the cloud, those VMs are going to be running all the time — at a significant cost. I recently priced the cost of the VMs needed for a competitor’s offering: four VMs with 1 TB of EBS storage each. The cost of running the VMs for a single year was $40,000! That’s before you even pay for the software.
Druva Cloud Platform is a cloud-native service designed for the cloud, and it increases and decreases its resources as appropriate. It only turns on enough nodes to get the current job done, then deactivates them when it no longer needs them. That is a huge savings that gets passed onto the customer.
Pre-provisioned storage — Most backup products still want to talk to a traditional file system, which means EBS if you are running in AWS. Even if they know how to write to S3 storage, rarely can they do so natively. They can send older backups or copies to S3, but not back up directly to it. So instead of sending all backups to inexpensive S3 storage, and paying only for the amount of storage you consume, you’ll need to provision and pay for EBS storage ahead of time. You will then need to provision more storage when you run out of room. Since that tends to be difficult to do, you’ll probably overprovision, increasing your costs even more.
Peak load issues — There are times when you need more power in your backup system. For example, when you acquire a new company, add a new department to the system, or start backing up laptops when you previously hadn’t been doing so. These occasional periods of peak demand mean you have to do one of two things: allow backups to take much longer during peak periods or overprovision to deal with peak periods. Unfortunately, both choices have negative consequences. In contrast, the Druva Cloud Platform automatically scales up to meet your peak demand and scales down when it’s over in order to reduce costs.
Sometimes require onsite hardware — The strangest — and most surprising — disadvantage of the traditional software approach is that some “cloud” solutions require an onsite component in order to work. This is different than the optional caching system mentioned earlier. These products require you to have a full onsite system — which may require several servers and another license of the software — in order to have base functionality.
Software updates — Customers managing their own backup servers and software must maintain that software. Every few months they will come out with another version with updated features or bug fixes, and that version will need to be installed on all backup servers in your environment. This may require downtime and a lot of work. Any updates to the Druva Cloud Platform are managed by Druva, and are completely invisible to customers.
OS updates — Even if the backup software can automatically update itself, you are responsible for updating and maintaining the operating system of the backup servers. This is for security and performance reasons. Sometimes new features in the backup software are tied to certain operating systems versions, forcing you to upgrade one before you can get the other. This, of course, is handled by Druva if you are Druva Cloud Platform customer.
Microcode updates — These are rare, but they do happen, due to things like the Spectre and Meltdown vulnerabilities. Customers running their own backup servers have had to be responsible for this as well. Druva customers have nothing to worry about.
What it comes down to
Products designed for standard hardware and even VMs are not the same as a product designed specifically to run in a cloud environment. Could-native cloud applications like Druva do not require customers to license or manage VMs in the cloud. Dedicating VMs to each customer costs much more than simply activating additional VMs as necessary in order to satisfy a peak load. These significant differences will make the hosted products cost more to purchase and administer. Scaling such systems will take more time and require a renegotiation of your contract. In contrast, Druva Cloud Platform will be less expensive to buy and administer, and will automatically scale to meet your needs — without having to renegotiate your contract or needing the services of a systems architect.
Find out more about the advantages of the Druva Cloud Platform by visiting our Data Management-as-a-Service page.
