One thing I’ve recently been made painfully aware of is sovereignty issues when it comes to cloud computing. I’m specifically referring to a situation where a consumer organization – let’s say for the sake of argument that we’re talking about a Canadian company – has restrictions on where it’s data and services can physically be in terms of geographical locality. In simple terms, a company here in Canada, depending on the regulations its under, likely has restrictions on whether it can have services or data hosted from a US-based cloud service. This means any component of their cloud service cannot be outside the Canadian physical border. This makes for an interesting exercise in technology and service mapping when it comes to cloud computing and utility.

Imagine you’re the ACME Corp. trying to find a public cloud service to host your retail application …except due to regulatory and compliance restrictions Canadian citizen’s data cannot be hosted outside the Canadian physical borders. How would you, the consumer, go about making sure this is true during the procurement of such services?

The fact is, that CIOs are challenged now more than ever to ensure the agility, security, resiliency, performance, and cost-effectiveness (among other things) of their IT services and this can create a challenging situation when it comes to cloud computing. Being sure your data and services are within your sovereign borders is one thing when you’re dealing with a single provider – but let’s look at it from a cloud perspective. More and more often services such as Software as a Service (SaaS) are being delivered “stacked on” one, two or many other services the customer may never be aware of.

If you’re purchasing a Software as a Service (SaaS) cloud service you load your data into your SaaS provider confident that their entire operation is within your country’s sovereign borders. Unfortunately, your SaaS provider uses multiple Platform as a Service (PaaS) service providers to deliver things like resiliency and performance so they’re reasonably sure the services they utilize all reside within the same borders. Where this gets complicated and out of control is when those multiple PaaS providers start to utilize various IaaS providers and Storage as a Service providers. Odds are the storage provider never even knows they’re doing business with ACME Corp. …only that their downstream customer is buying services from them to build yet another service. On the other side of that coin, there is a chance that your SaaS provider is unaware that your IaaS provider gets their storage from a company which has their service physically located in Canada, Switzerland, and California …those last two don’t meet your regulatory and compliance requirements.

Since cloud computing is a paradigm of computing as a utility (or service) it’s not uncommon to have these deeply nested relationships which aren’t aware of each other several layers up or down, and if requirements aren’t laid out clearly and investigated thoroughly it’s entirely possible that regulations and compliance needs can be broken even with a reasonable amount of due diligence. So how do you proceed forward if you’ve got these types of requirements and needs? Do you simply stay away from cloud computing providers and build out your private cloud? The answer is not mutually exclusive.

While the question of public cloud cannot be dismissed simply because it requires complex relationships, thorough investigation and attestation, and complete situational awareness of services being delivered and consumed – there are some use-cases which make public cloud an unlikely and unfit option. It’s entirely OK to come to the conclusion that private clouds (entirely within your premise or sovereignty) are the only option. There seems to be this prevailing conventional wisdom that cloud computing is right for all business models and use-cases …this is simply not true. I’ve had several conversations with CIOs and CISOs where the conclusion after a thorough discourse is to simply build a private cloud because public clouds were too high of a risk. You can’t always chase the “because it’s cheaper we need to…” model of public cloud. And heck, it’s even a fallacy to say that public cloud is somehow always cheaper (but that’s a story for another time).

From the consumer viewpoint my advice to you is if you’re facing these types of issues, is to simply take a deep breath and ask lots of questions. Be thorough in your investigation and don’t allow vendors to give you the “trust us, we’re the experts” line because you’re the consumer of these cloud services and you have the right to know …and often the legal requirement to be fully aware of the environments you employ for your compute services.

From the provider perspective, the advice isn’t much different. Be aware of what kind of service you’re building. Know the benefits as well as the limitations of your service. Understand that it may not be right for everyone, and that sometimes compliance regulations dictate a no-go situation. Most importantly make sure you’re able to provide your consumers with as much information as legally allowable, and don’t just do the typical vendor brush-off. You should know where the physical and logical services you’re potentially using as building blocks for your service are coming from, and who’s managing them. This is your responsibility.

In the end, it’s all about due care, process, and not rushing into a cloud computing migration because you heard it’s the big buzz-word from your peers or from a trade magazine. Take a rational approach and first understand the parameters from which you need to operate and the requirements you have. Then enforce, with prejudice, those requirements on your vendors and know the potentially deep relationships that exist in the way cloud computing is delivered. Let’s measure twice, go in with our eyes wide open and aware, and then make the cut.