The Doppler Quarterly Special Edition 2019 | Page 15

Multi-Cloud
This term seems relatively self-explanatory: deploy cloud infrastructure on more than
one public cloud provider, with or without an existing private cloud. However, the moti-
vation for WHY companies might consider multi-cloud approaches and architectures is
where things get interesting.
Risk Reduction, (“Don’t put all your eggs in one basket!”)
When organizations decide to go to public cloud, a typical concern is the perception of
risk associated with dependency on one external firm, such as Amazon, Google or Mic-
rosoft. In response, it is common to wonder whether it makes sense to minimize that per-
ceived risk by using more than one cloud provider, thus maintaining a complete and sep-
arate environment in each one. This provides an additional option in case the relationship
with one provider becomes untenable for some reason, and, in theory, makes it possible
to maintain services in the event of an outage at one provider. There is an instinctive
logic to this approach; however there are also some realities that argue against it.
The first challenge is the complexity of maintaining an additional complete set of archi-
tectures and operational relationships, one for each provider. Given that most compa-
nies will already be operating in a hybrid cloud, this makes a total of three environments
that must be maintained and operated. That doesn’t make multiple cloud providers
impossible, but it needs to be understood. Note that there are vendors who offer valu-
able third-party products and services that can help provide standardized abstraction
layers, theoretically minimizing the complexity of managing multiple cloud providers. A
good example that comes to mind is Pivotal Cloud Foundry, especially known for
enabling applications to run on multiple clouds.
But an important note here is that as soon as you depend on an “abstraction” provider,
you have now re-created the single provider failure point you were trying to avoid in the
first place. In addition, there is nearly always lag time between cloud providers releasing
a feature, and the abstraction providers being able to support that feature. This creates
an agility penalty. Given that enterprise agility and time-to-market for new products and
features are critically important motivations for organizations to move to the cloud in
the first place, giving away some of that agility is counter-productive. Finally, because
the goal is to support duplicate environments with consistent capabilities regardless of
which cloud provider is operating underneath the abstraction layer, it requires that each
cloud provider has the same underlying capabilities. This leads to the next challenge.
The second (and larger) challenge to the “distribute your eggs” approach arises from
the drive to the lowest common denominator. By definition, if the goal is to operate
duplicate environments, then all the capabilities that are relied upon must exist in both
environments. Of course, it is obvious that while the three main cloud providers have
services and features that significantly overlap, they are not even remotely close to
being identical. The result? Any full-fledged implementation of the “don’t put all your
SPECIAL EDITION 2019 | THE DOPPLER | 13