Choosing a Cloud Provider: Building and Launching Servers (Part 2 of 2)
Note: The purpose of this post is to explain how we go about choosing a cloud provider and to share some of the lessons we’ve learned along the way. For context, while cloud vendors provide a wide and growing range of services, SOASTA’s primary requirement is acquiring scalable, pay-per-use compute power. Part 1 discusses what to look for as you get started.
After we get familiar with the cloud provider’s UI and have built our base image, it’s usually pretty easy to build and launch servers. In most cases, getting a public IP address is either straightforward or automatic. We have seen some vendors bring up servers only with a non-routable IP address, and then require multiple steps to tie the server to a publicly facing address. Most applications need a public-facing IP address, so this is inconvenient, at best.
Performance is important in every application, and understanding the requirements of a particular workload may influence which vendor and/or configuration options are best. Because everything happens in memory for SOASTA during a test, high performance I/O, which is challenging for cloud vendors, is not much of a factor. For some, I/O speed may be critical, in which case the range of available storage options, both for performance and persistence, becomes a much more important part of the decision criteria.
For SOASTA, bandwidth in and out of the data center and speed to provision are important. Bandwidth is important for any application that has high traffic. In some cases, available bandwidth is tied to the size of compute instance being used, the bigger the instance the greater the available bandwidth. In other cases bandwidth allocations are associated with a deployment, which may consist of multiple instances servicing a workload. And, there are data centers that have very restrictive pipes into the data center, which in our case limits the amount of load we can drive from that location. Another consideration, as always, is cost. Bandwidth in and out, along with utilization between data centers for a single provider can all have different price points.
For any application workload that regularly starts and stops servers, or that leverages elasticity to handle spikes or unexpected growth, provisioning speed is critical. How long it takes a server to launch is the first critical factor SOASTA looks at before committing to use an API. In addition, increasing the number of servers launched has a greater negative impact for some vendors than others. Amazon and Rackspace, for example, can launch a single server in a matter of minutes and, even if we request many servers at once, we’ve seen minimal impact on overall launch time. They handle parallel operations very well.
Some vendors ask that you launch only a small number of instances at a time, and in some cases don’t even support batch requests for servers. SOASTA’s implementation of those APIs takes this into account, making it easier for our customers and performance engineers. Still, if too many servers are launched at once, it can overwhelm the provisioning system with a much higher likelihood of bad instances or instances that timeout, which then need to be replaced. All providers queue requests so that the infrastructure can handle requests for new instances, however some have exceedingly low thresholds before forcing their customers to get in line. This means that, depending on how long the queue is, even if the actual deployment is relatively fast, you could be waiting quite a while for your servers to even start to spin up.
We also evaluate the UI based on the operations that are available for managing a server, which again is an indicator of what’s exposed in the API. Of course, starting and stopping instances is universal, but not status, error reporting, reboot, resize or rebuild, all of which can be useful and should be supported through the UI. The information you can get while in the UI also varies from vendor to vendor. You can always see how many servers are running, what locations they are running in, the configuration of the servers and their state (running, stopped, provisioning, etc.). But not all clouds will show how long a server has been running, who launched it and other metadata that can be helpful in managing cloud deployments.
After spending time working through the UI, we always peruse the tech support forums to see what kind of questions are asked. If there are many posts asking for help stopping or deleting or rebooting an instance we assume that the tools available to the consumer to manage their own instances are not quite complete. In addition, we consider how often they have maintenance windows, how pro-active are they in notifying the customer about maintenance and what’s the impact? For SOASTA, being locked out of starting instances for a few hours is incredibly inconvenient, and there are a number of vendors who still require downtime for an entire datacenter when they perform maintenance.
When support is needed, it’s important to look at the ease of use and comprehensiveness of the knowledgebase and other support resources, as well as how easy it is to actually talk to someone. As you can see, at SOASTA we consider a broad range of criteria in choosing our cloud vendors, but sometimes it comes down to a simple conversation to make a partnership work
Recent Comments