The Sunshower.io Blog

If you’ve heard of cloud computing at all, you’ve heard of Amazon Web Services (AWS), Microsoft Azure and Google Cloud. Between the three of them, they’ll be raking in over $50 billion in 2019. If you’re on the cloud, chances are good you’re using at least one of them.

The latest RightScale State of the Cloud Report pegs AWS adoption at 61%, Azure at 52% and Google Cloud at 19% (see the purple above). What’s more, almost all respondents (as denoted in blue) were experimenting with or planned to use one of the top three clouds. Which, if you math that up, means that 84% of respondents are going to be using AWS at some point, 77% will be using Azure and 55% will be using Google Cloud.

Multi-cloud strategies are definitively A Thing, contrary to some folks’ opinions and the overwhelming one-cloud-to-rule-them-all desire of AWS. So it’s worth comparing them. On a broad level, AWS rocks and rolls with capabilities set to lock you into their cloud, while Azure’s great for enterprises and Google Cloud’s your go-to if you want to do AI. But, as with all things, there’s more to it than that, and it’s not just where you can get the best cloud credit deals.

You wouldn’t think that the primary issue with optimizing cloud computing workloads would be getting good data. Figuring out math problems (hello, integer-constrained programming) worthy of a dissertation, sure. Writing a distributed virtual machine, maybe. Getting good data about a workload to run against good data about what the viable machines to put it on are? Not so much.

Well, you would be wrong. While the majority of the IP is in said math problems, the majority of the WORK is in the data — getting it and cleaning it up. And the data problem alone is enough to make you realize why everyone just picks an instance size and rolls with it until it doesn’t work anymore.

Last week we started the work to expand our platform from AWS-only to Azure. One of the first steps to that is what we call a “catalog”: a listing of all the possible virtual machine sizes across all possible regions with all of their pricing information (because, of course, pricing and availability vary). You would hope that this sort of catalog would be readily accessible from a cloud service provider (CSP). At the moment, the state-of-the-art is the work of many open-source contributors working together to scrape different CSP sets of documentation.

For AWS, we love ec2instances.info for this information, though we still had to get all of the region information in less savory ways. Different folks have attempted to do similar things for Azure, but Azure doesn’t make it easy. Pricing is different across Linux and Windows, because of course it is, but the information they give you when trying to look at pricing is missing some bits:

Reserved Instances are an enormous investment.

At first glance, that statement might seem counter-intuitive. Reserved Instances (RIs) are widely advertised as the best way to save big on your Amazon Web Service (AWS) cloud compute bill. And in many cases, they are. With Reserved Instances, companies commit to long-term usage by agreeing to rent virtual machines for a set amount of time (typically 1 to 3 years) in exchange for a significantly lower rate than on-demand pricing. When viewed through this lens, they appear to be a vital part of an AWS cost management strategy.

Cost Savings

Take Amazon EC2 as an example. When compared to on-demand pricing, Amazon EC2 RIs offer customers potentially deep discounts — sometimes as much as 75%, per their marketing. While reserving cloud capacity in advance seems like the smart thing to do because it has the potential to deliver a significant amount of savings, the savings promised by RIs often have a dangerous downside — and any missteps can have substantial costs for your company.

The calculations involved in deciding which RI to purchase can be frustratingly complicated. One year or 3 year contract? What about tenancy? Instance size? Region and zone? New or from the marketplace? And don’t forget about the nuance of offering class — do you want your RI standard, convertible or scheduled?

These calculations are difficult, but absolutely vital when committing to a RI. Rather than signing a contract for exactly what you have now (in terms of size, region, and tenancy) and guessing at the length of time that will fit your instance, it’s essential to understand the exact shape of your usage needs. Without that kind of granular insight into your workload, it’s impossible to choose a RI that will be the right fit six months from now, let alone three years in the future.

In the end, many companies buy RI capacity that ends up exceeding their actual needs, because they’re already using capacity that exceeds their needs. Unfortunately, committing to more capacity than you actually need can be very costly over the length of a RI contract. When that happens, the long-term return on investment (ROI) ultimately evaporates.

We’ve talked about the most common causes of cloud waste, and how they can negatively impact your company’s bottom line.

Whether it’s choosing the wrong instance size, not fully understanding cloud pricing options, leaving unused resources running, or locking yourself into inflexible reserved instance contracts, there are lots of ways to end up with a cloud bill that wreaks havoc on your financials.

What can you do to keep cloud costs down and reduce your part of the $14.1 billion that will be wasted on cloud compute resources in 2019? You can avoid cloud waste by adopting smart cloud cost optimization strategies. Here are a few good places to start.

1. Don’t Over-Provision Your Cloud Infrastructure

Remember when there was that great deal on strawberries so you bought a bunch because you thought you’d surely eat them? And then you never did? Just like it’s hard to figure out what you’re really going to eat in a week, it’s hard to figure out what resources your software really needs in order to run. You can use a monitoring solution to determine what your resource utilization actually looks like in production, determining how much of critical resources like memory, CPU, disk, networking and more you’re using. Then, it’s a matter of aligning that with an instance size (which unfortunately sometimes feels more like blindly buying strawberries in bulk than reaching for a pre-packaged pint, considering the sheer number of options per cloud service provider).

2. Turn Off Idle Cloud Infrastructure

The main cause of idle capacity is leaving non-production machines up and running 24/7. Consider spinning down build, QA, demo and development environments during off hours. You can schedule them to turn off when your night owls leave and turn back on before the early birds come in. On the production side, use auto-scaling groups to help meet peak demand times. And of course, be vigilant that as people and products come and go you’re monitoring what systems are actually being used.

Cloud over-provisioning is a lot like like buying strawberries in bulk.

I know that sounds weird, but hear me out:

I once bought a huge tub of strawberries at Costco. Sure, there were way more strawberries than I could probably eat, but they were such a great deal– just a little more expensive than a small box of berries at the grocery store. The lure of the deal was strong, so I caved.

What happened next? I ate a few berries out of the tub when I got home, promptly put them in the crisper drawer, and completely forgot about them. The next time I opened the drawer it was like a scene out of Avatar — a mysterious new greenish-blue ecosystem, composed of fuzzy, strawberry-shaped blobs.

Bulk strawberries sound like a great deal, but only if you’re going to, you know, actually eat all those strawberries.

We all pay for stuff we don’t end up using. Whether it’s those strawberries slowly creating a new ecosystem in the fridge or your company’s public cloud infrastructure, that waste can seriously add up. The moral of the story? It’s never a good deal if you don’t use what you’re paying for.

As cloud computing continues growing in popularity, more and more companies are turning to the cloud for their computing needs. But if you’re spending any money on a cloud service provider, it’s pretty darn likely that some of those funds are being lost on overprovisioned or underutilized cloud infrastructure. (Think: the proverbial untouched, moldy strawberries in the fridge.) It’s human nature to buy more than you need “just in case,” and this applies to cloud infrastructure too.

The heart of the Sunshower.io cloud management platform is a distributed virtual machine that we call Gyre. Developers can extend Gyre through Sunshower’s plugin system, and one of the nicer features that Gyre plugins provide is a dependency-injection context populated with your task’s dependencies, as well as extension-point fulfillments exported by your plugin. For example, take (part) of our DigitalOcean plugin:

The details are beyond the scope of this post, but basically Gyre will accept an intermediate representation (IR) from one of its front-ends and rewrite it into a set of typed tuples whose values are derived from fields with certain annotations. The task above will be rewritten into (ComputeTask, Vertex, TaskResolver, TaskName, Credential). This tuple-format is convenient for expressing type-judgements, especially on the composite and recursive types that constitute Gyre programs.