How to choose a cloud provider

If you look up the phrase “boiling the ocean,” it’s defined as writing a post on choosing a cloud provider—there are so many different facets and use cases, and each variable complicates your choice. The key is to narrow the field to your specific situation and needs. In this article, I share some of the early questions and decisions I use when working with a team to choose a cloud provider.

Simple pass/fails

I recently worked with a large financial organization who was considering a move to the cloud. When I started the engagement, we began with quick pass/fail decisions to see if a cloud move was feasible. These pass/fail choices allowed the team to make an initial go-forward decision before they went too deep down the rabbit hole. The following considerations helped mitigate their risk.

Can we use the cloud?

This might sound like an easy one, but some teams actually forget this step. There may be an outright prohibition on using the cloud at your organization, or the political climate may be so terrible that you decide not to fight that battle.

Will the technologies work for your use case?

Can the cloud technologies do what you need them to do? With small data problems, this isn’t usually an issue: they can handle almost anything. With big data problems, however, capability can be a sticky issue—there are bigger tradeoffs that the technology designers had to make.

I’ve written some in-depth posts covering some of these tradeoffs and comparisons. For example, I compared Amazon Kinesis and Apache Kafka, and Google Cloud Pub/Sub and Apache Kafka. You’ll notice there are subtle differences. In the lens of a use case, these differences can make a requirement of your use case impossible to implement with a technology.

In order to make this initial call, you need to really understand and know your use case. You’ll want to have a general idea of where and what you want to do in the future, and validate those use cases, too.

Compare providers

At the 10,000-foot level, there isn’t a glaring difference at small data scales. At these small data scales, there are fewer distinguishing factors. But at big data scales, the different cloud providers have bigger differences.

Generally, the providers distinguish themselves on:

• How easy are the managed services to use and operate? For example, how easy is it for me to spin up a database and have it replicate all over the world?
• Since the services are managed, how good is their uptime and how reliable is the system? In other words, how often does the service go down, and for how long? Some outages are system-wide, but how often do your instances disappear?
• The cloud providers fight each other on price. What is the total cost of running infrastructure on the cloud provider? Unfortunately, this question can be difficult to answer because working with a single technology can have three or four different costs associated with it. For example, a messaging system could have costs for the message transfer, the storage of the message, and an hourly fee for the managed messaging system.
• How prevalent are engineers with knowledge of that cloud provider in the marketplace? These days, you can’t throw a stone without hitting someone with some knowledge of Amazon Web Services. That said, the skills are largely similar at an operation level. The skills at a developer level are only somewhat similar.
• How difficult will it be for you to move between cloud providers and technologies—aka “lock in”? For example, some providers use an open source technology or its API, but have their managed service behind the scenes. Conversely, using a managed service with a proprietary API really couples you to that cloud provider.

Keep your options open

As you’re looking over providers, don’t just look at the big cloud providers. Take the time to investigate niche providers as well. They may be able to provide a level of service that the big providers don’t (although, be warned that some smaller providers don’t provide tech support). Still other niche providers handle the operations of open source technologies that aren’t necessarily managed services.

Ask the right questions

Once you’ve considered the big-picture factors, you’re ready to fine-tune your decision process. Here are the questions I ask teams to consider when choosing a provider:

• Cost: Is cost a primary factor? Have you created an accurate calculation for your comparisons?
• Popularity contest: How popular is this cloud provider and do they have enough customers not to go the way of the dodo bird?
• Availability of people: How difficult will it be to train the existing staff on the provider’s technologies (for both operations and development)? How difficult will it be to hire people who are familiar with the provider?
• SLAs: What level of SLA does the provider give for the services you’ll be using (remember that some services are ghosted under a main service)? Does management know that during a large-scale outage, you won’t be able to scream loud enough to speed things up?
• Use case: Does the technology work for your use case? Do you really understand your use case well enough to validate the technologies?
• Lock-in: Are you comfortable with the potential level of lock-in? Will you write your software to be highly coupled to that service?
• Company politics: Have you settled the company politics? In other words, have you established who owns what, and who is responsible for each piece?

Once you’ve thought about and answered these questions, you’ll be in a better position to make an accurate comparison of the cloud provider landscape. A little preparation and careful groundwork are the keys to making the right choice.