Deploying to multiple clouds is considered, by some, to be the nirvana of maturity in and around engineering resiliency. It comes up constantly in the context of vendor security questionnaires and is flagged as a risk when technology providers don’t comply. Working in technology companies for the past decade, I’ve often heard nothing more than nightmare stories about decisions made to take a product in the multi-cloud direction.
Why Is Multi-Cloud Hard?
This complexity often exists because engineering teams make decisions to rely on a cloud provider’s native resources. An example of this might be Amazon’s S3 or RDS services. These services are built for convenience and they oftentimes are. They are also specific to the cloud provider. While databases or object storage should not be overly unique, application and infrastructure delineations are rarely clean enough to fully abstract away the nuance of the provider’s managed resources.
Can Containers Really Help?
“It worked on my machine.” That was the common trope about the friction between operations and development teams. The reason for this was the lack of parity between the development environment on a developer’s environment and the environment that operations teams were deploying into.
One of the core properties of a container is that it is an immutable build artifact. If a change needs to happen, a new container is built and deployed. This property of immutability is important because it also aids in portability across environments. In many cases, this manifests as a container moving between development, test, staging, and production environments. Parity is achieved across the environments which increase confidence in the production build.
Enter, Kubernetes
Kubernetes has exploded from a popularity and community support perspective. For good reason, the ability to scale, network, secure, and generally “orchestrate” sets of containers is powerful.
Similar to other common functional application needs (e.g., storage, networking, firewalls, etc.), most of the major cloud infrastructure providers offer some form of managed Kubernetes. The functionality that Kubernetes provides can abstract away the core functions at the IaaS layer necessary to run an application service. For this reason, Kubernetes opens up an attractive opportunity to do multi-cloud deployments in a way that doesn’t conjure up nightmares.
There are still many choices to make when considering Kubernetes in your application environment.
- Should I purchase a managed Kubernetes wrapper solution, such as D2IQ or Rancher?
- Should I purchase a solution to assist with the actual deployment (and possibly multi-cloud deployment) process?
- Is there anything we can’t containerize that will need to operate in a different way anyway?
- Are there any third-party services I need to bolt onto my Kubernetes deployment? Examples might include security sidecar products, service mesh, monitoring/logging, auditing, and so much more.
Having technology partners to assist in the setup, deployment, and management of a Kubernetes environment can be incredibly helpful. This is especially true in lieu of talent shortages in the job market.
The Risk of a Multi-Cloud Strategy
Deciding to pursue a multi-cloud strategy, like anything, comes with benefits and risks. In some ways, risk is diversified in a multi-cloud strategy, as you avoid vendor lock-in and are able to failover quickly in the event of a provider outage.
However, there is risk in complexity, which cannot be understated. If the means of deploying or managing secrets across cloud environments become overly burdensome, it could have the opposite of the intended benefit in times of stress or failure. If complexity is such that only one or two key people can fully understand what’s happening, there is tremendous operational risk at play. These dynamics can be managed quite effectively through wise combinations of technology partners to assist with the work, but products alone do not solve problems.
It’s also important to understand what the real driver behind a multi-cloud strategy is. There is no one-size-fits-all risk management strategy. Every organization is different, with unique missions, assets, and operational environments. Spending the time to truly understand the goals, needs, and corresponding risk posture is time well spent. This is a classic situation of an ounce of prevention equaling a pound of cure.
Want more cybersecurity insights? Visit the Cybersecurity channel:
