Cloud compute: AWS, Azure, Google, SoftLayer compared

AWS still offers the greatest variety of instance types, but its top rivals have differentiating features of their own

Cloud compute: AWS, Azure, Google, SoftLayer compared
Thinkstock

Back in the olden days (early 2007), there was one player in IaaS: Amazon Web Services (AWS). And AWS had one instance family, the M1. It was good. But as tech years move faster than dog years, the landscape has changed quickly and dramatically. There are new players -- notably Azure, Google, and IBM SoftLayer -- and new offerings. Even when you consider only the compute offerings of the IaaS providers, the options are vast and varied. Granted, compute is at the core of what these providers offer, and as such they look to differentiate those items. The result has been an explosion in the number of options in the compute realm of IaaS.

Because the underlying hardware and virtualization mechanisms vary among providers, apples-to-apples comparisons are not always possible. As such, in the discussion below, I will focus on describing each vendor’s offerings, with references to similarities and differences in the competing services. I will not go down the rabbit hole of pricing as it can get quite convoluted with varying pricing tiers for on-demand, spot, and preemptible instances, as well as sustained usage discounts and reserved instance pricing, enterprise license agreements, reseller discounts, and so on. I will touch on pricing at a high level, but I’ll leave the gory details for another article.

With those caveats behind us, let’s evaluate the compute offerings of AWS, Azure, Google, and IBM SoftLayer. For a high-level view of the differences (in compute, network, storage, database, analytics, and other services) among these cloud providers, check out the free RightScale Cloud Comparison tool.

Amazon Web Services

AWS was first to market with a cloud compute offering, and it gained a sizable head start. Today AWS Elastic Compute Cloud (EC2) has approximately 40 different instance sizes in its current generation (“instance” is the term AWS and Google use for what others call a “virtual machine,” “VM,” “virtual server,” or “VS”). The previous generations of instance types (including the aforementioned M1) are still available, although they are not “above the fold” on any AWS price sheets or product description literature. There are about 15 instance sizes in the previous generations. While they are currently fully supported, it would not be surprising if AWS looks to sunset these instance types at some point in the future.

Focusing on the current generation, some of these instance types come with attached “ephemeral” storage (storage that is deprovisioned when the instance is terminated), while many others come with no attached volumes and instead specify “EBS only” with regard to storage. This means you must separately provision, attach, and pay for the storage. (EBS is AWS’s Elastic Block Storage offering, which will be discussed in a future article in this series.)

Advertisement

The current generation of instances is organized into instance families that are optimized for certain use cases. Some of the current instances address general-purpose workloads, while others are tailored for computationally intensive applications. Still others are optimized for workloads with high memory requirements or for applications that require high amounts of storage (up to 48TB). Some instances provide GPUs that can be used for video rendering, graphics computations, and streaming.

Additionally, some instance families support “burstable” performance. These provide a baseline CPU performance, but can burst to higher CPU rates for finite periods of time provided by “CPU credits” that the instance accumulates during periods of low CPU utilization. Evaluate your use case and workload carefully before deciding upon burstable instance types.

It is important to benchmark your application to ensure that on average it stays at or below the baseline. Not only that, you want to ensure that the CPU bursts are not so long they exhaust your credits, and the CPU valleys are sufficiently long to allow for credit replenishment. If you exhaust your CPU credits, your application may run in a “CPU starved” state that will obviously hinder performance. Burstable instances are a great tool for the right application, but they can prove very problematic when used incorrectly.

AWS instance types can be optionally configured to meet specific use cases, performance targets, or compliance regulations. For example, certain instance types can be configured in an enhanced networking model that allows for increased packet rates, lowers latencies between instances, and decreases network jitter. Additionally, instances can be launched into high-performance computing (HPC) clusters or deployed on dedicated hardware that allows for single-tenant configurations, which may be required for certain security or compliance regulations.

There are also different pricing structures and deployment models that can be used within AWS EC2. The standard deployment model is “on-demand,” which means, as the name implies, you launch when you need them. On-demand instances run for a fixed hourly cost (fractional hours are rounded up to the next hour) until you explicitly terminate them. There are also “spot instances,” which allow you to bid for any excess compute capacity AWS may have at any given time. Spot instances can often be obtained for a fraction of the on-demand cost (savings in excess of 80 percent are not uncommon).

However, they come with the caveat that they may be terminated at any time if the current spot price exceeds your bid price. It is a real-time marketplace in which the highest bid (the price you are willing to pay per hour for the instance) “wins.” You can achieve tremendous cost savings with spot instances, but they are only suited for workloads that can be interrupted (processing items from an external queue, for example). 

AWS offers “spot blocks,” which are similar to spot instances in that you specify the price you are willing to pay, but you also specify the number of instances you want at that price, and a duration in hours up to a maximum of six. If your bid is accepted, your desired number of instances will run for the time specified without interruption, but they will be terminated when the time period expires. This deployment model is useful for predictable, finite workloads such as batch processing tasks. 

AWS offers discounts through reserved instances (RIs), which require you to commit to a specific instance type running a specific operating system in a specific availability zone (AZ) of your desired AWS region. You must commit to a one- or three-year term, and in return your hourly cost for the instance will be greatly reduced (up to 75 percent for a three-year commitment).

However, you are generally constrained to the instance type, operating system, and AZ that you selected for the duration of the contract, so careful planning is essential. You can request modifications within certain limitations, but those requests are subject to approval by AWS based on available capacity. Clearly, committing to one or three years of reserved instances isn’t for everyone. Other providers have similar discounting policies that are far simpler to implement and don’t require having years of visibility into your workload (Google’s Sustained Use Discounts, for example, which will be described shortly).

AWS has the most complete set of offerings in the compute arena, but it doesn’t have a lock on unique and interesting features. Other vendors are continually adding new compute options that make them attractive alternatives for many use cases.

Microsoft Azure

Microsoft takes a similar approach to compute instance types with Azure, but uses slightly different nomenclature. Instances are called virtual machines (VMs), although you will see the word “instance” sprinkled throughout the online documentation. VMs are grouped into seven different series with between five and a dozen different sizes in each group. Each series is optimized for a particular type of workload, including general-purpose use cases, computationally intensive applications, and workloads with high memory requirements. An eighth group (the “N” series), which is composed of GPU-enabled instances, were recently released for general availability this month.

All told, Azure has approximately 70 different VM sizes, covering a wide array of use cases and workload requirements. All VM types in Azure come with attached ephemeral storage, varying from about 7GB to about 7TB. (Azure measures attached storage in gibibytes, not gigabytes, so the numbers don’t come out as neat and clean as we are typically used to.)

As the maximum capacity of attached storage for an Azure VM is considerably less than for an AWS EC2 instance (the aforementioned 48TB, for example), you may want to provision additional storage. This can be allocated from an Azure Storage account associated with your Azure subscription (“subscription” is the Azure term for what is generally known as an “account”). Azure provides both a standard storage option (HDD) and a “premium” storage option (SSD). I’ll discuss these in more detail in a later post in this series.

Azure also provides a VM size (the A0) that is intentionally oversubscribed with regard to the underlying physical hardware. This means the CPU performance on this VM type can be affected by “noisy neighbors” running VMs on the same physical node. Azure specifies an expected baseline performance, but acknowledges that performance may vary as much as 15 percent from that baseline. The A0 is a very inexpensive VM, and if a particular workload can tolerate the variability, it may be an attractive option. 

1 2 Page 1
Page 1 of 2