Multi-cloud is often talked about as a deliberately chosen strategy. Something you think about first, plan for, and then execute. And it makes sense. Different cloud providers have different pros and cons, so why not consume the best services from each (and every) cloud?
The reality is that for many, if not the vast majority of cloud customers, multi-cloud just unconsciously happened. It wasn’t a thought-out plan. It’s not part of any architecture, design or budget discussion.
Enterprises are already multi-cloud, even if they don’t realize it. They use multiple SaaS applications, some public cloud services, and datacenters on-prem, co-located or hosted by a 3rd party. Or they merged with, or acquired another company that made different cloud choices.
Another cause of unconscious multi-cloud environments are developers. They’re often in a hurry to create new features. Creating new code often is an act of combining existing components into something new; developers prefer to use services they know and love. So they use whatever component or service they used in a previous job or project, which may, or may not, be approved to use. Or they simply forget to talk to IT Operations before swiping a credit card to use a service.
Companies End Up With Disjointed Multi-Cloud
If you don’t guide the process of cloud consumption within your organization, you’ll end up with a disjointed multi-cloud. In other words: many different disconnected islands, each with incomplete, badly implemented, unaudited security and compliance standards.
Imagine having to go in there and fix security and compliance issues retroactively.
Another downside of disjointed, unconscious multi-cloud environments is the sprawl of skills required to operate and manage IT environments. Lack of skills lead to issues with security, compliance, performance, stability, and cost. You need to be enough of an expert for security and compliance reasons.
Because, like with any other technology, you need the right people, with the right skills for cloud. And these different clouds differ enough that specific knowledge does not translate well between them.
By intentionally balancing the number of clouds used across the enterprise, but also on a more local level, skills and experience can be optimized, leading to better efficiency in cloud usage. It allows deliberation of the benefit of using a new cloud service versus the time and effort of having to learn the skills to do it well.
Conscious Multi-Cloud
Do the right thing: only do multi-cloud if you do single cloud right. Multi-cloud comes after mastering single-cloud. Make sure to have the resources to scale up skills and experience for multi-cloud.
A big part of getting multi-cloud right is in connectivity, security, identity, access, and data management and compliance. This means implementing a fabric of connectivity where security policies, (single) identity and access management, data management and compliance, and audits checks can be uniformly applied to on-prem, SaaS, and public cloud.
Only after implementing this cloud fabric are organizations able to adopt new clouds and cloud services seamlessly, quickly, and often. These guardrails are a good way to balance the speed of innovation on the developer and business side with operational aspects of IT, allowing developers to consume new cloud services quickly while security and compliance are ensured.
Ownership of application and cloud architecture is constantly shifting and is becoming a shared responsibility of business, operations, developers, architects, and security. However, the architecture of the fabric interconnecting the multi-cloud (including SaaS, on-prem, and hosting) is vital, and needs a well-defined responsibility, shared between security and operations. It is the foundation, the bedrock, for any business or development-led project.
The Multi-Cloud Fabric
A common approach for the multi-cloud fabric is using SD-WAN on top of a Cloud Exchange that physically interconnects public clouds, SaaS-providers, on-prem and co-located, or hosted resources.
The SD-WAN technology layers security and compliance policies on top of all resources, making these policies portable across public clouds, SaaS-providers, and existing on-prem assets.
Source: The Technology Depot
The resulting network is zero trust and secure by default. It’s easy to onboard new services onto the fabric and apply existing or new security policies. When moving existing workloads, their policies travel along with the workload, ensuring security compliance in a consistent, hands-off way.
