The Myths of the Single Cloud

Contrary to what many people believe, single cloud really doesn’t exist in our highly connected world anymore.

There’s an infamous Zen koan that asks, “What is the sound of one hand clapping?” Like one hand clapping, a single cloud application is enigmatic — but not useful. To get real work done, we need to connect cloud applications and information together. A well-designed cloud should make that easier.

If you use more than one cloud-based service (and who doesn’t?), you’re using multicloud. Maybe it would be better to think of it as “complex cloud” or an “interdependent cloud” or a “real-world cloud.” But we’ll work with what we have.

Definition: Multicloud is the use of multiple cloud computing and storage services in a single heterogeneous architecture. This also refers to the distribution of cloud assets, software, applications, etc. across several cloud-hosting environments.

You trust Google with your personal email, photos and files. You trust Salesforce with your customer’s personally identifiable information (PII) because it tells you who your customers are and how your sales processes are working. There’s an entire world of enterprise cloud software, so trusting a cloud contact center platform built for security and resiliency should be easy. But for many businesses, it’s not.

Here are some common single-cloud myths that perpetuate the belief that cloud (multicloud) isn’t safe.

Myth #1: Connecting Multiple Systems Makes Cloud Brittle.

Brittle code and integrations stop working when a step in a process goes wrong. This was common with older systems with limited resources, but it still pops up when you don’t design systems to recover or self-heal. Unfortunately, bad things happen – servers go down, processes get hung up, data routing is glitchy, cosmic rays flip bits. It’s inevitable. Try as we might to prevent it, we can’t predict or prevent everything. No matter where your software operates, things will go wrong.

Knowing perverse behaviors can happen with any system leads to two things.

1. Better coding. When we expect things to fail, we’re always looking for problems and designing to recover. How do you test for truly random problems? We use code to pseudo-randomly disturb processes to uncover problems as part of our development systems and test automation. We actually force features and resources to fail to avoid as many failures in live environments as possible. In production our expectations don’t change. We prepare for the inevitable. Which leads us to number two.
2. Like the Boy Scouts, always be prepared. When you expect things to fail, you have back-up plans in place. In fact, you have back-up plans for your back-up plans.

For example, when we make a call to get customer data from Salesforce, or FedEx or your legacy inventory system, we expect that it won’t answer and we’ve planned for that. If our call goes unanswered, we revert to recent data to fulfill the request while also making the call again.

In the end, good multicloud is anything but brittle. It’s actually stronger and more resilient than hosted systems that don’t have the agility to respond and prepare for when things go wrong.

Myth #2: Multi-Tenant Cloud Gives Other Organizations Access to Your Data.

Hard limits can be programmed into systems. One limit in our system is that any request that mixes data from multiple organizations is invalid. That creates a lot of work for us when two accounts want to merge, but it protects and separates data for each company with hard rails.

For another organization to access our data, we require a request from a valid user, at a valid organization, with permissions to perform the action and access the data only for that organization.

In a modern cloud architecture, there are many small operations to complete for any response. We’ve built a checkpoint into our processes that lies between every operation. At each of those points, we check and verify that the permissions are (still) valid. In the cloud, we’re not limited in resources. We can check everything and log everything – even those checks. Operating under this premise allows us to ensure business continuity for our customers.

To prevent a kink in the security chain, every multi-tenet organization needs to adopt a zero-trust approach to every intersection point. This means assuming that every request has an ill intent and is unreliable. It’s not “trust but verify;” instead it’s “always verify, always.”

Ironically, doubting the validity and intent of every user, every organization, and every system is what makes a good partner in the cloud. This is why we authenticate every request multiple times as we work on answering it. We also fully encrypt data both in transit and at rest. This relentless encryption is applied on top of the cloud storage, so even our cloud service vendors can’t see your data.

Not only do we do this, we partner with organizations that also take similar zero-trust approaches. Because when you control access you limit exposure.

Responsibility and Opportunity
Security is every organization’s responsibility. And when operating in the cloud, we assume every partnering organization has been breached — and we protect our data and systems accordingly.

The cloud doesn’t lead to security vulnerabilities. It creates opportunities such as layering data from different sources in comparison to increase confidence in acting on that data. Without using many clouds, you’re actually inhibiting your business success — limiting the information available to accurately know, understand and proactively serve your customers.

Take the Genesys Cloud tour to see what the most secure and resilient cloud contact center platform can do for your business.