People erroneously think that you only pay for what you use in the cloud – and that is technically true. What you might not realize is that what you pay for is what you provision and not what you actually use. Specifically in cloud computing and associated block storage, you are not charged for the amount of computing power you use or the amount of data sitting in your file system. You are charged for the number of CPUs you specified and the size and type of the volume you created. This is true of all major cloud computing vendors, and is definitely true of Amazon Web Services (AWS).
For example, I took a quick look at AWS’s Advanced Wizard, and found that I could specify an instance of up to 128 CPUs, 2TB of RAM, 4 TB of local SSD, and 20 GB of guaranteed bandwidth. I’m guessing that it costs a little bit more than the default instance that has 1 CPU, 1 GB of RAM, 8 GB of non-flash storage, and no bandwidth guarantee. If I had launched that instance, I would be paying for 128 CPUs, 2TB of RAM, 4 TB of SSD, and 20 GB of guaranteed bandwidth – whether or not I ever use anything of the sort. My bill for all of that starts the moment I turn on that instance. Another example is AWS EBS. If I provision a 1TB EBS volume and store say only 200GB data on it, I will still pay for 1TB capacity.
The real problem is that due to limitations of the operating systems – we have brought into the cloud many of our bad practices from the data center. Specifically, we continue to over-provision both our computing and storage resources. It takes a lot of effort to figure out exactly how many CPUs an application needs, so we tend to just give it more than it needs to make sure that it has enough. It also still takes effort to grow a file system once it has been created, so we tend to make a file system that is as big as we think it will ever be. If we create a file system only big enough to hold the current amount of data, we are guaranteeing additional work later. Even worse, we are potentially creating an outage by not giving our application enough space. Meanwhile, we are being billed for all of the storage, RAM, and CPUs, that we provision.
Those of us who have spent a lot of time looking at object storage systems have perhaps not noticed this interesting problem. That is because object storage systems – including those in the cloud – don’t work like this. With an object storage system, you don’t need to provision in advance and can provision as you go. In the cloud, you don’t need to provision at all. Create a bucket and start putting things in it. You will be billed per gigabyte per month.
So we were somewhat taken aback when FittedCloud started the briefing the same way. After explaining how you pay for what you provision, they claimed that the average environment uses less than half of the AWS resources that they provision. The problem was easy enough to understand, but what could FittedCloud do about it?
FittedCloud customers install the software on their virtual machine that stands between the traditional system drivers and the cloud storage drivers. The first thing it does is allow you to thin-provision volumes. If you create a one terabyte volume, their software will make your operating system think that that’s what it has; however, it will create a much smaller volume in the cloud just big enough to hold the actual amount of data that you need to store. As you use up more space, it will dynamically grow the volume in the background without any intervention from you – and without any downtime. FittedCloud software can be installed live without application disruption.
It can even “right size” an existing volume that you created before installing the FittedCloud software. It will inspect your volumes and resize the cloud version to match the amount of data you are currently using. It can then dynamically grow the volume as your needs dictate – up to the size of the original volume created.
The FittedCloud solution also supports rightsizing the number of CPUs that you use. It will observe your applications and let you know which of them are using far fewer CPUs than you provisioned. At your instruction, FittedCloud will then re-provision the virtual machine with the appropriate number of CPUs. Currently this does take a brief amount of downtime. FittedCloud solution will also scale number of CPUs up the same way when needed.
The FittedCloud solution also supports other AWS services such as DynamoDB. Machine learning is used to ensure that provisioned read/write capacities match application utilization to maximize cost savings.
Once FittedCloud “fits the cloud” to exactly how you are using it, savings should be immediate. AWS bills you by the hour for the services that you have provisioned. Currently FittedCloud only supports AWS, but if it is successful there, there is no reason why the company can’t support other cloud providers.
When a vendor describes a problem we did not realize existed, we often wonder if the cure is any better than the disease. Or sometimes we don’t even agree with the vendor that the problem even exists, wondering if is this a product in search of a problem. This is one of those rare times when neither of those is the case. FittedCloud articulates an easy to understand problem with a perfect motivator – paying too much. If the products solves this problem with no performance impact and little or no downtime, FittedCloud should have great success.