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, it while cloud vendors provide a wide and growing range of services, SOASTA’s primary requirement is acquiring scalable, pay-per-use compute power.
In a recent blog post we described how SOASTA leverages the APIs of cloud providers to quickly and reliably provision and terminate many servers across a wide range of vendors. Before writing to a new API, we evaluate each provider for the features that are important to us. We start with the user interface (UI) because we’ve found it to be a great way to understand the capabilities of potential cloud partners.
Every cloud infrastructure provider has a self-service UI, a dashboard that allows you to interactively manage instances. Working with the UI is a quick way to get a feel for the cloud provider’s overall implementation, and help determine if you want to take the time to integrate with the provider’s API. In most cases, this UI is built on the same API exposed for all users … and if it’s not, that’s probably a sign that the API is not quite ready.
There’s a lot you can learn before diving into the API. Beginning with the sign-on process, we’ve found that companies that haven’t made it really easy to sign up and get started are typically the ones who’ve not quite made the shift from a managed-services-centric approach to doing business in the cloud. If the support for signing up, should you need it, is less than stellar, that’s certainly another indicator that the provider’s heart is not yet in the cloud.
Before we get into the technology, it’s important to note that there are key differences in how different vendors do business. There are a number of account management features that may prove important for applications or use of the cloud. These include:
- The ability to have master and child accounts. This might be useful for internal billing or possibly managing the visibility of instances for different users.
- Requiring unique accounts for each data center. If your application can take advantage of using servers from multiple locations, perhaps for failover or performance reasons, you may not want to deal with the overhead of managing multiple accounts.
- Role and user-based access to the account(s), which can be important if you don’t have a single set of requirements and need to control how the account is used; or need to charge for utilization by department, while maintaining centralized control.
- Detailed accounting and tracking of all services from bandwidth and servers to IP addresses and VPN services. Some vendors do a far better job of itemizing exactly what resources are being consumed.
- Requirements for pre-paid, pre-allocated Internet Protocol (IP) addresses. This is problematic for an application like ours, which is constantly starting and stopping variable numbers of servers. Any application that takes advantage of auto-scaling or instantiates servers on a temporary basis for specific jobs (such as the massive, on-demand calculation and analysis applications in the financial and pharmaceutical industries) will find this inconvenient at best.
- Disclosure of available IP ranges in cases where publicly used cloud resources need to be whitelisted.
After sign-up, the first experience will be interacting with the portal. Some are just plain slow, require too many clicks to achieve relatively simple goals, artificially limit what you can do (typically to protect some weakness on the back end), timeout too quickly and/or for no reason, or provide little to no feedback after a request has been made. Virtually every new provider, while still working out the kinks, suffers from some of these challenges. However, these issues tend to shake out, given time.
After gaining familiarity with the UI, we check out the available base images. For some vendors it’s simply a set of common, stripped-down Linux and Windows operating system images. The range of images and the OS options that are supported may be an important consideration. Some vendors allow for publishing of public images and, as a result, have relatively large libraries of available starting points: the more robust the set of choices, the better.
We also consider the range of available server configuration options. Again, the more the better. The SOASTA application uses a slightly different configuration for each cloud provider. Because our tests often span providers, we try to normalize memory and CPU so that each instance across clouds is roughly comparable.
Once you’ve created an image you want it to be easily deployed; at SOASTA, we regularly deploy instances across data centers. Some providers do a great job of helping to keep distributed images manageable and consistent. Others force the customer to make sure they stay in sync. As an aside, not all ‘cloud’ providers allow you to build and save your own images. In some cases, if you want to instantiate versions of your own image, you need to keep it running and ready to be duplicated. This makes speedy deployments impossible unless you’re willing (or need to) have an instance running at all times. Rebuilding an image each time we want to deploy eliminates those vendors from SOASTA’s consideration.
In Part 2 of Choosing a Cloud Provider, we’ll cover Building and Launching Servers.
About the Author