IDG Contributor Network: The intangibles of picking a public cloud


Moving all or part of your operations to a public cloud provider will be the most substantial decision many CTOs and CIOs will make in their careers, and a misstep could cripple your company for years. For some, the decision is strictly a cloud cost comparison, though trying to compare costs across public cloud vendors is like mattress shopping, where there’s enough nuance to make the apples-to-apples comparison virtually impossible.

On the other hand, sticking with one of the top four cloud vendors (Amazon, Microsoft, Google, and IBM) significantly cuts down the cost risk because these behemoths are in a constant price war. With cloud costs aside, what’s often much more crucial are the deep intangibles that exist to drive current and future projects to a definitive success. Unfortunately, these intangibles are applicable to the objective in slightly different ways and often require reasonable scrutiny to deduce.

Capabilities: microservices, serverless, latest hotness

Comparing the matrix of services from each public cloud vendor will be an exercise in shear torture; consequently, some upfront design is needed to ensure the basic building blocks are there to support the application. Yes, this is agile heresy in some respects, but the harsh reality is some experimental design spikes in prospective clouds will be necessary to avoid significant work efforts in the future. For instance, each vendor has specialized in certain areas to differentiate themselves; consequently, if the project has any sort of unique traits (which they all do), leaning heavily on inherent vendor strengths is sure to speed the project.

A recent example of this is Kubernetes, for which Amazon Web Services (AWS) a managed service while Google Cloud Platform (GCP) has provided a for years. Granted, this example is semidated, but these service offerings are changing so fast that it’s difficult to stay current. At first glance, you might be tempted to think the gorillas will eventually reach some sort of parity, and while that might be marginally true, the question is whether the time and/or expertise exist in your organization to wait. Unfortunately, the devil is in the details and what may look like similar offerings may actually vary significantly in terms of read/write performance, streaming data, etc. Here’s a sampling of current differentiators to be wary (at the time of this writing):

 to provide useful value. In other words, it’s not a trivial add-on service to be tacked on at the end, and in fact, machine learning requires component services to work together as vast amounts of information are flowing between services. Each component service must have autoscaling and intimate knowledge of one another; otherwise, engineering teams will spend valuable resources connecting and managing instead of coding user value. Here’s sample questionnaire to help in the selection process:

  • Are AI and machine learning touted as first-order items or add-ons?
  • Do machine learning component services autoscale in tandem with neighboring services?
  • Do machine learning component services easily exchange data?
  • Do AI services align with your project’s expected needs?

But wait, there’s more

Sadly, the journey in picking a cloud vendor for the next big venture is just beginning because these are just a few of the items beyond shear cloud costs that can make or break a favorable outcome.