Hybrid or Multi-Cloud
There is nothing wrong with pursuing a hybrid or multi-cloud strategy. How-
ever, suggesting that the best way to combat outages, such as the S3 event we
witnessed, is to pursue multiple cloud providers is short sighted. Before invest-
ing the time, money, and resources to pursue a multi cloud strategy for the sole
purpose of redundancy and HA (high availability), consider these things:
1. Make sure your current architecture is designed for failure. For example,
AWS recommends cross-region replication for S3 for HA and DR.
2. Test your systems for failure. If you just assume every AWS API will
always work and don’t design and test for use cases where they fail, you
get what you deserve when the service is down. Simulate outages, test
HA and recovery solutions, leverage the Simian Army, etc.
3. Understand the true TCO of adding another cloud vendor to the mix and
don’t underestimate the effort.
Is multi-cloud worth it just as a safety net? I think with all the buzz with con-
tainers and tools like Terraform, there is a perception that whatever you build
on one cloud is easy to port to another. Let me dispel that myth.
I agree that the OS and virtual machines can be very portable. Wrap them in a
container and they should run easily on any cloud or non-cloud provider
(assuming your setup is cloud agnostic). But the OS and virtual machines are
only a small part of the story. What about identity access management (IAM),
Virtual Private Cloud design (VPC), security tooling, networking, etc.?
I have yet to find a viable solution to abstract the cloud vendor specific APIs
around security and networking so that you can design once and port many.
You could argue that a PaaS solution handles that for you but there is still a one
time integration that takes place for each cloud. There are many good argu-
ments for and against pure play PaaS solutions which I’ll leave for another arti-
cle on another day.
It takes a great amount of upfront work to harden what AWS calls the “landing
zone” or the infrastructure required to run your apps. When moving to your
next cloud provider, much of the landing zone build out is not portable. Each
cloud vendor has its own APIs for the security and networking capabilities.
There are also one time integrations with the various 3rd party security, mon-
itoring, and logging tools. Many SaaS implementations of those 3rd party tools
are either too expensive or lack the required feature set of their non-SaaS ver-
sion, so they must install and manage those tools on the cloud providers infra-
structure. Of course, the implementation of each of these tools is different on
each cloud provider because of the different security and networking APIs of
each cloud provider.
Then there is the cost. If you have hundreds of terabytes of data stored on S3,
do you really want to duplicate that on another cloud provider just as a safety
net for the one time a year that an outage might impact a storage API? Maybe
8 | THE DOPPLER | SPRING 2017