I’ve never seen an appliance solution that I would call “pay as you go.” I might call it “pay as you grow,” but never “pay as you go.” There is a distinct difference between the two.
What is “pay as you go?”
I’ll give you a perfect example. BackupCentral.com runs on a Cpanel-based VM. Cpanel can automatically copy the backups of my account to an S3 account. I blogged about how to do that here.
I tell Cpanel to keep a week of daily backups, four weeks of weekly backups, and 3 months of monthly backups. A backup of backupcentral.com is about 20 GB, and the way I store those backups in S3, I have about fifteen copies. That’s a total of about 300 GB of data I have stored in Amazon S3 at any given time.
Last time I checked, Amazon bills me about $.38/month. If I change my mind and decrease my retention, my bill drops. If I told Cpanel to not store the three monthly backups, my monthly bill would decrease by about 20%. If I told it to make it six months of retention, my monthly bill would increase by about 20%.
What is “pay as you grow?”
Instead of using S3 — which automatically ensures my data is copied to three locations — I could buy three FTP servers and tell Cpanel to back up to them. I would buy the smallest servers I could find. Each server would need to be capable of storing 300 GB of data. So let’s say I buy three servers with 500 GB hard drives, to allow for some growth.
Time will pass and backupcentral.com will grow. That is the nature of things, right? At some point, I will need more than 500 GB of storage to hold backupcentral.com. I’ll need to buy another hard drive to go into each server and install that hard drive.
Pay as you grow always starts with a purchase of some hardware –– more than you need at the time. This is done to allow for some growth. Typically you buy enough hardware to hold three years of growth. Then a few years later when you outgrow that hardware, you either replace it with a bigger one (if it’s fully depreciated) or you grow it by adding more nodes/blocks/chunks/bricks/whatever.
Every time you do this, you are buying more than you need at that moment, because you don’t want to have to keep buying and installing new hardware every month. Even if the hardware you’re buying is the easiest to buy and install hardware in the world, pay as you grow is still a pain, so you minimize the number of times you have to do it. And that means you always buy more than you need.
What’s your point, Curtis?
The company I work (Druva) for has competitors that sell “pay as you grow” appliances, but they often refer to them as “pay as you go.” And I think the distinction is important. All of them start with selling you a multi-node solution for onsite storage, and (usually) another multi-node solution for offsite storage. These things cost hundreds of thousands of dollars just to start backing up a few terabytes.
It is in their best interests (for multiple reasons) to over-provision and over-sell their appliance configuration. If they do oversize it, nobody’s going to refund your money when that appliance is fully depreciated, and you find out you bought way more than you needed for the least three or five years.
What if you under-provision it? Then you’d have to deal with whatever the upgrade process is sooner than you’d like. Let’s say you only buy enough to handle one year of growth. The problem with that is now you’re dealing with the capital process every year for a very crucial part of your infrastructure. Yuck.
In contrast, Druva customers never buy any appliances from us. They simply install our software client and start backing up to our cloud-based system that runs in AWS. There’s no onsite appliance to buy, nor do they need a second appliance to get the data offsite.(There is an appliance we can rent them to help seed their data, but they do not have to buy it.) In our design, data is already offsite. Meanwhile, the customer only pays for the amount of storage they consume after their data has been globally deduplicated and compressed.
In a true pay as you go system, no customer ever pays for anything they don’t consume. Customers often pay up front for future consumption, just to make the purchasing process easier. But if they buy too much capacity, anything they paid for in advance just gets applied to the next renewal. There is no wasted capacity, no wasted compute.
In one mode (pay as you grow)l you have wasted money and wasted power and cooling while your over-provisioned system sits there waiting for future data. In the other model (pay as you go), you pay only for what you consume — and you have no wasted power and cooling.
What do you think? Is this an important difference?