The intangibles of picking a public cloud

A CIO's viewpoint of the costs and capabilities that can make or break a favorable outcome

glass office building cloud
Scott Webb (CC0)

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) just announced a managed service while Google Cloud Platform (GCP) has provided a managed Kubernetes service 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):

  • Security across services, regions, etc.
  • Read and write of persistence of time-series data, high-volume string data, etc.
  • Indexing of special data types for quick retrieval
  • Ingest and egress of data from/to external systems
  • Autoscaleing (up and down) of key services

Operations: People and processes

Just because a development and/or operations team can spin up a high-performance cluster across a few compute nodes, it does not mean scaling one or more of these clusters will result in success. In fact, building the development, staging, and ultimately production environments for these self-managed services will prove to be a nightmare, except for those with an unlimited budget (that is, almost none of us). Plainly put, the ability to use more vendor managed services is directly proportional to the overall longevity of the project, and finding the magic recipe of vendor and self-managed services will require some research.

Another key element to consider is whether enough SMEs exist in your company and/or your reachable market to ensure continuity. Software developers often underestimate the specialized knowledge needed to self-manage a multinode cluster at scale, and the operations team will be surprised to see befuddled developers during the first significant outage. With many of these newer technologies, whether they exist as cloud services or are self-managed, the talent pool is quite limited, and in-house expertise will only happen via self-education and trial and error. Some companies have countered this problem by paying others to help with the essentials that are not adequately supplied by the cloud vendor, and this is an excellent option for projects with large budgets. Unfortunately, vendor lockin and margin become more of a concern as additional external services are added, which make the upfront research all the more important.

Intelligence: Of the artificial kind

Artificial intelligence deserves a few extra thoughts because it’s not often something planned for a minimal viable product (MVP), especially for a new offering; however, it cannot be overlooked as a next-have item on the roadmap. Every IT executive in the world is being asked about his or her AI strategy these days, and while compelling AI implementations are mostly unicorns at the time of this writing, AI as part of your digital transformation will be table stakes in five years. What makes AI unique is its dependence on machine learning 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.

Copyright © 2018 IDG Communications, Inc.

How to choose a low-code development platform