Selecting a Cloud Provider: What NOT to Do

Just this week I had the opportunity to present on a panel at a partner event. One of the audience members brought up the topic of evaluating cloud service providers for her business. I look at the problem a bit differently than most, so I wanted to share a few things NOT to do when you are searching.

1) “Boy, they have a lot of big customers!”

Not all cloud environments are built the same. They run different hardware, have unique network implementations, and run varying hypervisors, to name a few variations. Be wary of cloud providers that won’t explain their guts when you ask. While it’s all about the SLA of your environment, thus you shouldn’t care what logo gear has on it, make sure that the service provider is willing to explain how they can really support that SLA. Many customers circumvent a cloud service provider’s less-than-stellar internal OLA/SLAs by augmenting their application for multiple availability zones or even by using multiple cloud service providers in a “multi-cloud” strategy. In many cases, if you don’t, you’ll be facing an outage.

Go back to identifying your business problem. Why are you looking for a cloud service provider? Is it to be the arms and legs of your IT staff, for example? If so, think about what foundational functionality you will need to solve your problem… and what you will not. Personally, I’ve been blown away by many of the features that others in the industry have within their cloud. The release cycle of Openstack is staggering based on its maturity. The question you need to ask yourself is, “Will I consume most of the functionality the cloud service provider has — and solve my problem — or is it not enough/too much?”

The most recent example I encountered is an organization that was looking to deploy their application instances quickly. They were considering both Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) options. They evaluated multiple service providers on the basis of how quickly they could spin up the application through either a portal or a restful API. When they went back to their business problem, however, they realized that the reason they had to spin them up so quickly was because their existing solution didn’t have any kind of capacity planning or warning system. The moment they realized their business problem was predictable growth, their list of service providers changed significantly.

3) “I won’t need help.”

The hosting industry started with service. If you look back at the most successful traditional hosting organizations they exploded thanks to the exceptional service they provided to customers. You can probably follow a recipe and make me a delicious doughnut. I would love one. That doesn’t mean that you should distract yourself from your day to make me a doughnut, taking your eye off of your business.

Managed cloud service providers see themselves the same way. They see thousands of customer applications all day long and realistically have more experience troubleshooting hosting-related issues than you do. You shouldn’t be distracted from your core business to know the ins and outs of what it takes to keep your applications online and performing. That’s their job. At the same time, balance this with your requirement for self-service. Effective cloud service providers have both options so, based on your business needs at that time, you can leverage either.

4) “It’s as easy as spinning up a VM in 5 minutes.”

Sometimes it is. I personally love being able to tell a customer to simply go into the HOSTING portal, spin up a VM, upload your web application, and be done. However, be wary of service providers that won’t ask you about the current state of your application. There are some platforms out there that will require you to make significant application code changes in order to get your application to work in their environment. Do you have the time and resources to both learn and execute the changes that are required? How does this affect your change management process for your application moving forward when their code base may also require future change as it evolves? Make sure you are considering resource costs as you consider migration.

5) “I don’t need to think about Disaster Recovery. It’s the Cloud!”

While my children may be fooled by the “To the Cloud” Microsoft commercials, you shouldn’t be. Disasters happen. And, believe it or not, most of them are clinical in nature, i.e., not natural disasters. They are the disasters that you let into your data center; the one you allow to push code changes outside of a change window or maybe even the one that administrates your machines with a password of ‘p@5swOrd’.

You need to plan for disasters based on the availability requirements for your application within your business. This may mean a multi-cloud strategy. More often today, it’s traditional disk based cloud backup or real-time replication services that enable customers to both restore and do live failovers to their other environment. Be sure to ask the cloud service providers you are considering how they work through this business problem, and what SLAs they are willing to offer you to ensure, at time of disaster, that you aren’t worrying if your data is still available.