The Sound of Water Dripping in the Cloud
There’s nothing worse than opening your water bill and finding that it’s a hundred dollars more than you expected. You scour your house and find the culprit: a leaky toilet or perhaps a dripping faucet. Hard to believe a simple drip drip drip can run up your water bill so dramatically, but those drips add up, quickly.
Replace the water with IT capability, and you have Cloud Computing. The pay-as-you-go utility model for Cloud promises dramatic cost savings, especially when unpredictable demand in a traditional, on-premise environment would require poorly utilized servers, sitting mostly idle on the off chance some spike in demand comes along. But just as with your water bill, there are many ways for your Cloud bill to go through the roof unexpectedly. Recognizing the Cloud equivalents to your problem plumbing fixtures can make the difference between saving money in the Cloud and flushing your savings down the drain.
Listening for the Drip
In fact, there are so many different mistakes you can make that will run up your Cloud bill unnecessarily that it’s a wonder anybody can save money in the Cloud at all. The most commonly discussed of these mistakes is the problem of zombie instances. If your IT shop doesn’t have adequate deprovisioning policies, then people will tend to leave instances running long after they’ve served their purpose. Over time people forget why they’re still around, and nobody will want to deprovision them on the off chance there’s something important on them.
But zombie instances are just the precipice of the Cloud money pit. An entire class of coding mistakes can also inadvertently consume Cloud resources. For example, a simple infinite loop may not only cause an application to hang, it may also spin the Cloud meter as well. And while such a loop in a single piece of code is a beginner’s mistake, sometimes the loops involve multiple instances, for example, when two apps call each other ad infinitum. Other basic coding errors that can run up the bill include memory leaks or pushing garbage collection to an excessively low priority. In a traditional deployment environment such mistakes may simply cause a process to freeze once the memory runs out, but the Cloud may provision additional instances to deal with the low memory situation. Cha-ching!
Then there are the attacks from outside. Since the ZapThink Web site runs on WordPress, we are always subject to floods of comment spam, which we must filter out. If we were running in the Cloud, then we’d have to pay for the privilege, adding insult to injury. And what about Denial of Service (DoS) attacks? Such attacks can consume immense amounts of bandwidth and other pay-as-you-go resources, again costing you more. If you’ve configured the Cloud to autoscale to deal with spikes in demand, then there may be no limit as to how much damage a DoS attack can do to your monthly Cloud bill.
Improperly configured dependencies among different workloads (or parts of a workload) can also lead to unnecessary expense. For example, let’s say you provision three Web servers and three app servers in the Cloud, and set up a round-robin policy where any of the Web servers can talk to any of the app servers. So far so good, but what happens when the whole shebang scales up? Instead of nine possible communication paths, you quickly have hundreds, consuming pay-as-you-go Cloud networking resources and also possibly bogging down your servers. And what does the Cloud do when your servers bog down? Provision more servers of course, making the problem worse.
This network communication problem can be especially onerous when you’re provisioning a Hadoop cluster in the Cloud. With Hadoop, your analytics algorithm runs in parallel on many different nodes, and the Cloud may increase the number of nodes depending on how big your Big Data sets are. As a result, if you construct the algorithm so that each node must talk to every other node, you have the same kind of network explosion issue detailed above. Even if the nodes aren’t talking to each other, but instead the algorithm “phones home” to a system outside the Hadoop cluster (say, a simple query to an on-premise system of record), then not only will you have a spike in network traffic in the Cloud, but you’ve also mounted your very own DoS attack on your mission-critical system. Your admin will not be at all pleased with you after that kind of mistake.
Another Hadoop configuration problem is actually an example of a broader issue that might run up your bill even if Hadoop isn’t on your to-do list: how you set up mirroring. By default, the Hadoop File System (HDFS) calls for three instances of each data node, scattered redundantly onto different VM instances similar to how RAID drives work. As a result, many instances can fail at random without hosing your Hadoop job. The downside to this mirroring, of course, is that it triples the size of your data sets, which triples your data storage bill for the time your HDFS is provisioned. You can configure the tripling factor, but it’s not a good idea to set it any lower. Setting it higher, of course, sends your costs into the stratosphere.
Of course, you want to do mirroring in the Cloud in other situations as well, for example, whenever you want to set up a disaster recovery or failover scenario – or simply when you want your data to have higher availability than the Cloud would normally offer. But beware: excessive mirroring is a great way to balloon your Cloud cost, especially if you’re dealing with large quantities of data. It’s also important to remember that mirroring may already be built into your Cloud storage offering. Don’t layer on additional mirroring if what you get out of the box is sufficient to meet your needs.
Sometimes the problem has to do with how you set up your Cloud instances ahead of time. Developers are used to requesting all the server resources they will require at design time, in order to avoid problems down the road. But that way of thinking is obsolete in the Cloud, since it leads to the provisioning of underutilized resources. Instead, developers should provision the minimum necessary resources for going live, and let the Cloud scale up if – and when – their workload needs additional resources.
Setting up autoscaling inefficiently is a related, but different problem. Let’s say you establish an autoscaling threshold of 80%: if an instance reaches 80% utilization, then the Cloud provisions another instance. Simple enough, but why 80%? If 90% will meet your elasticity requirements just as well, then the 80% configuration will pour your money down the drain. Unfortunately, there’s no hard and fast rule about how to set the perfect autoscaling threshold, since it depends on just how spiky your traffic spikes are, how long the Cloud will take to provision additional instances, and other factors. In other words, expect to tweak this number over time to squeeze the most cost savings out of your Cloud.
The ZapThink Take
In most of the developed world, drinking water is cheap, plentiful, and ubiquitous. In the developing world, however, it’s a different story. For those communities where drinking water is a precious resource, people have entirely different water consumption habits than we do here in the US, for example.
In the Cloud, there is no developed world. We’re all in that remote village, where only recently did a single well replace daily five-hour treks to a polluted river. Yes, we have water on tap, thank goodness – but we cannot fool ourselves that it is so plentiful and inexpensive that we can leave the faucet running while we brush our teeth.
Perhaps the most important lesson of this ZapFlash, however, is that the responsibility for proper consumption of Cloud resources doesn’t fall to a single role in our organization. Rather, developers, operations personnel, as well as the managers responsible for the Cloud provider business relationship must work together to ensure the code is correct, the configurations are efficient, and the costs are transparent and carefully monitored. True, squeezing value out of the Cloud is more difficult than we first thought. But remember, we’re still in the early days. Give it a few years, and we won’t have to think twice about simply turning a faucet to get all the Cloud we want.
Image credit: Maegan Tintari