9 Proven Poor Ways to Select a Cloud Provider

Updated: May 25, 2021 Updated: Cloud

Selecting a cloud provider is a big deal. It’s the start of a multi-year relationship and often involves tens or hundreds of millions of Dollars. So, you want to choose wisely. However, selecting a technology that is quite different from what you use today makes even sophisticated buyers susceptible to common pitfalls (an effect similar to Hiring a digital Hit(wo)man). That’s why I want to share nine easy traps that I’ve seen customers fall into.

Meeting the C-Suite

My job involves meeting with lots of customers. I truly enjoy the conversations with senior execs (CxOs or senior IT leaders) and decision makers who are looking to employ technology to accelerate or transform their business. I discuss parallels between managing cloud capacity and monetary supply, compare transformations to balancing acts, explain why execs should act like pilots, or describe what anarchy looks like in large enterprises.

As busy and influential people, most execs I meet seem to suffer from one specific curse:

Everyone wants to talk to the C-Suite, but the C-Suite doesn’t want to talk to everyone.

So, especially when you’re associated with a vendor, it’s good style to make sure that you are using your customers’ time wisely and bring them value, not just a sales pitch. I use my 9 commandments of speaking to IT executives to keep myself on track, which includes answering questions directly and honestly.

That’s a Good Question!

In such conversations I get many great questions and the occasional oddball one, like “do you support enterprises?” A day after having presented to a major bank’s board of directors, this one really did seem rather far-fetched.

Another somewhat unexpected but actually very welcome question is “how should one select a cloud provider?” It’s a great question of course, especially knowing that IT has a tendency to struggle with big decisions. It only came unexpectedly as I work for one vendor—perhaps the client did sense a welcome departure from the usual sales pitches in my talk and wanted to see if I’ll have a different point of view.

I never hide whose payroll I am on, but I make sure the opinions I express are my own, especially on my personal blog. So, I’ll steer clear of directly answering the question. Instead of telling you what to do, I’ll tell you what not to do. I have come across all of these fallacies, either because they’re enticing enough that even intelligent people fall for them or because they have been pitched by someone who is gaining from it.

Many of these points are also included in my book Cloud Strategy, which has a whole chapter about how selecting a cloud provider is different from traditional IT procurement. However, a blog post allows me to be a bit more pointed than in a published book, so I believe it makes a welcome addendum.

9. Considering the Technology Only

Most cloud providers will pitch their mighty technology – how could you not, if you have pre-trained machine learning models, globally distributed transactional data stores, and AI-powered code review frameworks in your arsenal. Therefore, many customers are inclined to conduct a side-by-side comparison of the available technology: who’s got the larger virtual machine, the higher network bandwidth, lower network latency, the latest CPU generation, or custom CPUs. This isn’t a bad idea per se—you’ll find many exciting things—but it’s only part of the picture.

Unless things go horribly wrong, you should prepare for a long-term relationship with your cloud provider. After all, it’s the platform that much of your IT will operate on. So, you’re going to want to have a closer look at the organization you’re dealing with. Luckily all three major cloud providers have a quite different origin, ranging across fulfillment/ecommerce, enterprise/consumer software, and on-line search/advertising. Having been employed by two and having been a long-term consultant to the third, I can pretty confidently state that their operating models are very much shaped by their respective mothership’s business model. I consider that a good thing—all are extremely successful in their respective markets.

An easy way to figure this out is to visit the respective executive briefing centers in short succession (I had a chance to do so as a customer). If you carefully watch for style and vocabulary, you might find that my following summary is only a mild exaggeration (caution: snark and political incorrectness ahead):

• “It’s all just enterprise software, anyhow. That’s why we’ll simply fold it into your existing enterprise agreement. There’s nothing to worry about.”
• “Listen, I traveled back all the way from the future just to tell you what it’s going to look like. And, see, you’ve been doing it all totally wrong!”
• “We built some stuff and customers seem to like it, so we’re building more of it. Oh, and please take a copy of our Watchtower magazine.”

I’ll leave you with the easy task of matching the quotes to the respective organization and pick the one that is the best match for your organization.

The cloud vendors’ operating models are shaped by their respective parent organization’s business model.

8. Looking at Single Products

Each cloud provider loves to have a product that competitors find difficult to match. I used to get a lot of mileage out of pitching BigQuery and Spanner, and now can’t resist showing customers how Graviton2 processors deliver 40% better price performance over x86 instances. And I am sure Azure Arc is being pitched right now against Anthos in an enterprise not so far away.

All these are great individual products. But the magic of cloud computing lies in it being a platform—a collection of services that works together in unison. The whole is bigger than the sum of the parts and certainly bigger than one part. Some cars have amazing gauge clusters - I love mine (I call it minimalist retro). Dealers love to show them off but you decide whether that’s what makes a car great.

The magic of cloud computing lies in it being a platform—a collection of services that work together.

When speaking to vendors, pay attention to whether they quickly zoom into a specific product or whether they convey the breadth of their service offerings as a cohesive platform. Some will claim that their product is a platform in and of itself, but then it good to consider whether you want to have another platform on top of an already pretty good cloud platform.

7. Taking a Snapshot

I frequently state that architects live in the first derivative - it’s a chapter in The Software Architect Elevator and I also gave a Yow! talk about it. The short version is that you don’t need much architecture if there is no change, but that rate of change is a critical input into our architecture decisions.

Today’s cloud platforms are anything but static. The 2020 re:Invent page lists 146 announcements, the Google Cloud Next page doesn’t number them, but there are dozens upon dozens, and Ignite has so many that they made a book.

On the flipside, some providers also discontinue services, leaving their customers to play an odd version of the hideous TV show Takeshi’s Castle. Most providers have a 12-months’ notice period for discontinued services in their terms, so better to look at their track record to see how often it’s invoked.

So, just looking at today’s cloud services is like hitting the pause button on an action movie. You are going to want to watch carefully the pace of innovation and the areas of focus. This time you should really skate to where the puck is going, not where it is right now.

Just looking at today’s cloud services is like hitting the pause button on an action movie

6. Selecting the Best vs. the Best for You

My book on Cloud Strategy contains quite a few punchy quotes, one of them being:

Does a better knife make you a better cook?

The quote plays off the fact that many modern hobby cooks fall in love with $300+ Japanese carbon steel knives but the correlation to tastier food has yet to be demonstrated. Looking at cloud tech is like being a hobby cook at Williams Sonoma or a kid in the candy store. You don’t even know where to start with so much cool stuff. It’s only natural to want the best for your company (after all, you’re not paying out of pocket), so you find many customers comparing niche metrics that they may never actually need. OK, you might be bound to a ludicrous VM size due to years of overdosing on SAP but most customers won’t benefit from a datastore that can scan 2 PB per second over one that scans 1.9. As always, your selection should start with your needs, not with what cool stuff you could have.

Your selection should start with your needs, not with what you could have.

5. Matching Existing Workloads

Many customers look at their existing workloads to select a cloud provider. This approach is particularly common with environments that are heavy on Windows. It also happens in SAP shops, which often feel like they need a “real enterprise” sort of cloud. Others have progressed to containers (at least in a few lighthouse projects) and also see their favorite home right in front of them, perhaps slightly intoxicated by CNCF elixir.

The reality is that the majority of Windows workloads are not on Azure, all cloud providers have decent offerings for SAP (GCP also seems to have hired quite a few folks from there for extra credibility points), and in 99% of cases your containers will run just fine on AKS, EKS, GKE, or ACK. Believe it or not, they also run totally fine on ECS, even though you won’t look as cool at the next KubeCon.

You will see much bigger differences in philosophy in infrastructure (the stuff you don’t actually see like custom hardware, availability zones, etc.), in identity and access management, infrastructure automation (IaC), governance, cost management, or billing. Oops, that’s all the “uncool” ops stuff, isn’t it? But guess what your IT management is most keen on: the Kubernetes version you are running or effective cost management and governance?

You will see much bigger differences in supporting services between cloud producers as compared to VMs or container runtimes.

4. Calculating Unit Cost

Cloud promises (and delivers) cost savings. So, it’s natural to want to compare costs before and after migration and in fact all providers feature fancy TCO to project savings. From time to time, I do see customers with a spreadsheet comparing their on-premises server cost per unit with the equivalent cloud VMs. This approach can be quite misleading, though. For one, it’s difficult to correctly capture all costs associated with a server (trust me, service pricing is a major topic for a cloud provider!): facilities, depreciation, energy cost, network, compliance reporting–the list goes on.

Second, the cloud has units that on premises environments don’t have. Most serverless environments bill per request plus per GB-second (to the tune of $0.0000166667 for AWS Lambda and possibly GHz-seconds ($0.000010-$0.000014 for Google Cloud Functions, depending on location). Some allow you to allocate 1MB increments while others make you choose from a limited set of types. Two (trick) questions: 1) which one is the better deal? 2) how do you possibly compare this to your on-premises environment?

The new pricing units aren’t limited to compute. How much does your API gateway cost you per request? The last time I procured one, the vendor pushed aggressive “tiers” and we ended up paying a license for several Billion requests, which we may or may not reach over 3 years. Oh, and hardware, operations, upgrades etc. come on top of that.

However, pricing can also swing the other way. Some customers are surprised to find they pay for extra instances of their data store that were auto-provisioned when someone bulk-loaded data and exceeded the usual bandwidth. Paying for provisioned IOPS also tends to result in little cheer just like needing to upgrade to larger storage volumes to gain more bandwidth. Again, it’s a different ballgame and you need to actively manage your cloud costs. However, a unit cost comparison to your current environment isn’t going to be very helpful.

The cloud has units that on-premises environments don’t have, making unit-cost comparisons difficult.

3. Listening to Developers (Or Consultants)

I once tweeted a statistic showing the reasons that enterprises are in the cloud:

Of course, this is totally made up. But it highlights my real-life experiences: not all cloud migrations are master-planned efforts. Too many of them start with a development team somewhere and a credit card (you’d think folks know better but I have seen this first hand from enterprise to public sector).

Developer experience (DX) is a key element of velocity and often staff retention. That doesn’t mean, though, that your developers should make the final decisions. Developers are known to be opinionated (surprise, surprise!) and often favor complex solutions that are seen as “challenges”. In the worst case, technologies are preferred because they boost your resume and promise a pay bump (that’s why I tend to be very careful with the “the highest paid cloud certification” charts–these backfire for employers).

Before making major IT investments, many enterprises solicit the advice of external consultancies. That’s a great idea because externals work with many customers and have more data points. However, large consultancies tend to favor complex solutions that promise long-term engagements.

So, where do you turn? Sadly, virtually every party has something to gain from your complexity. This explains Why Enterprise IT Is So Complex. The best advice I have is to have transparency into your needs and carefully evaluate your options.

Virtually every party around you has something to gain from your complexity.

2. Harvesting Credits

At some point in your evaluation cycle, you are going to negotiate for price. There’s percentage discounts to be had, free training, complimentary professional services engagements, and then there are credits. Credits are not only the things you have in your video game, but they are also a major token for vendors to secure deals. Back in the 90ies I routinely pocketed $75 by switching my long-distance plan from AT&T to MCI and Sprint and back to AT&T. One day the providers realized how dumb this way of luring customer was, and then Skype made it all go away.

Cloud computing hasn’t come to that insight yet—as a customer I have seen credits extended into the millions of Dollars. As an architect you usually find out by procurement calling you and asking whether our stuff would also run on XYZ cloud.

All cloud vendors are commercial, for-profit business. Some actually don’t make a profit, so you might think that you’re getting more than what you pay for. And even better if you can pocket a credit. Not so fast, profitability has a lot to do with scale, accounting, and cost control (folks flying business class across Asia despite being unable to secure a single customer meeting–team building!). 2020 all but eliminated travel expenses, but the best relationships are those where both vendor and customer gain. A vendor with a sustainable business model will be around for a good while.

Of course, you should be a shrewd negotiator. But don’t let credits be the decision maker. Remember the casino ground rule: there is only one source of money—you.

There is only one source of money: you. You’ll pay for it one way or another.

1. Following the HiPPO

Time for a quiz: what does one in IT do when there’s a big and perhaps risky decision to be made? Right, you get someone else to make it! This very dynamic is the frequent source of consultancy engagements, but you can also accomplish it in house—after all we are supposed to insource, right? So, you leave the decision to the most senior person, an approach commonly known as HiPPO, the Highest Paid Person’s Opinion.

There’s not so much wrong with having senior decision makers, but the last letter of the acronym gives a hint as to how these “decisions” typically happen. They are opinions, not based on data, but made on the golf course (or equivalent), stirred by FUD (fear, uncertainty, and doubt), or occasionally by currying favors.

That’s likely the worst way but one that is a carry-over from the enterprise IT days. As we are transforming the IT tech landscape, perhaps we can also leave that piece of legacy behind us.

Make your decision based on data, not opinions.

Worse Yet: Not Deciding

We’re not done yet! On top of these proven poor ways of selecting a cloud vendor, there’s a bonus one! And it’s at least as dangerous: not deciding. Not deciding comes in two flavors:

1. Analysis paralysis, meaning endless evaluations and discussions
2. An ill-construed multi-cloud strategy that avoids making a selection by selecting all

It’s obvious that version 1 will get you nowhere but version 2 often accomplishes the same, just after spending even more time and money. They reason lies in the following insight, charmingly dubbed Gregor’s Law:

Complexity is nature’s punishment for organizations that are unable to make decisions.

There are legitimate reasons for using more than one cloud provider, especially if you count SaaS offerings as part of your cloud strategy—I actually wrote a quite popular blog post about multi-cloud a little while ago. However, not being willing to decide isn’t one of them.

The Selection Is the Beginning, Not the End

I hope this checklist proves useful to your cloud vendor evaluation. Of course, making such a decision is a big deal: there’s lots at stake. Lots of money but also your organization’s ability to compete in fast-moving environments while remaining cost-efficient and compliant. However, as important as the selection is (clouds aren’t a commodity and that’s a good thing!), what comes after the selection will have an equally profound impact on your success. It’s wise to see the vendor selection as the starting point of a long series of decisions that you’ll need to make. So, it’s best to leave the old way of making decisions (and the roulette table) behind you, right from the start. And keep the good questions coming!

Read more on cloud strategy on my blog