To the Cloud (Safely)

After all these years of outsourcing and Cloud computing, people are still blogging about the crazy risks of putting corporate data and emails in the Cloud.

Most of these arguments just put a negative spin on the whole Cloud concept rather than looking at the reasons and solutions. So let’s do that.

The first task of any Cloud Consultant is to ask *why* a business is considering moving to the cloud. The second task is to give advice on the benefits and risks. And where there are risks, what the various strategies are to minimise them. Nine times out of ten, businesses make changes in IT to keep costs down. As IT is generally not the core business it is viewed as an overhead as opposed to a revenue earner. Cloud is no different and businesses look to the cloud to save them money.

However, simply looking at cloud services with $ filtered spectacles falls short of understanding the complexities involved, both internally and externally. Consuming services from the cloud is a very different proposition to running services internally. Most of the skills needed to run services internally are not in the same basket as skills needed to manage vendors and consume services.

Moving to the cloud generally involves two big issues: 1. putting corporate data in the cloud and 2. putting corporate email in the cloud. Email is a kind of corporate data, but more on this later.

Let’s deal with issue 1. first.

The most common scenario is that a large company has evolved with internal systems, including SANs or NASs which are kept in a “secure” data centre. A place where physical access is restricted and where connectivity is all internal and on networks owned by the company. This is generally regarded as being high security. In order to circumvent the security of the data you need to be a malicious external hacker or a malicious internal employee. Where physical devices and storage are outside company premises, i.e. laptops these are generally protected by encryption and biometrics.

Companies who perform tape backups typically send them offsite in the care of a third party. In principal this is no different to cloud computing. You are trusting a third party with the management and content. This brings us to trust. Most people, and most organisations have a black and white view of trust. Either you trust an employee / third party, or you don’t. This idea is encouraged, almost forced by the fact that there is only one view of data: highly confidential.

One of my favorite lines from THHGTTG is when Ford Prefect asks Arthur Dent to trust him, to which Arthur replies “I do trust you. Just not very much”. Trust, like most things comes in shades of grey.

Pretty much all business is based on trust so why the big hang-up about trusting someone with your data? The problem is not the trusting per se, I think it is (lack of) knowledge about the data in question.

The first step for companies moving to the cloud is to think about the types of data they have and how to classify it. Depending on the size of the company this can be a short 1/2 day exercise or a mammoth project in it’s own right staffed by a dedicated team and implementations of filesystems capable of recording and enforcing classification metadata.

Hand-in-hand with a data classification exercise (or merely thinking about what types of data you have) is a risk assessment: what risks are the company concerned about: availability, public disclosure of sensitive information, industrial espionage? And how likely are those scenarios to occur. Given, as we are led to believe, that 80% of data breaches comes from internal employees with a grudge to bear, a company’s data might well be safer in the cloud.

Once a company has determined what types of data they have and they have assessed the risk, then it’s time to think about putting that in the cloud. The complexities I mentioned above now arise as there may need to be a process to classify data and a way of managing data based on it’s classification. The industry is immature in this regard. But the cloud can help!

Depending on what the risk view is, the cloud can be an ideal home for a large part of the companies data and in itself be a (crude but effective) method of data classification: if it’s in the cloud, we manage the risk like this, and if it’s on-premise we manage the risk like this.

So to re-cap, arguments about risking your entire company IP or being embarrassed about sensitive information being disclosed should not point the finger at the cloud: these risks exist already, wherever your data is. Understand the data, understand the risk and carefully choose your cloud provider and technology. Adopting the cloud, when approached correctly, will result in a more efficient and secure business.

More on the topic of mail later.


Recently, I have been getting more familiar with Azure. It’s good. Since it’s initial launch way back in 2010, Azure has been maturing and has become a leading contender for businesses seeking to take advantage of Cloud technologies. Whilst Azure was later to market than it’s competitors, this has allowed it to be more forward thinking and to direct itself more towards the service aspects of Cloud, rather than just a new home for old servers and apps.

My initial impression, which is formed not only from experience but by the Azure documentation, is that it is targeted at cloud native applications, an environment for companies to build new apps in and for the cloud. This makes sense. Whilst it is entirely possible and valid to lift and shift your existing business processes, as embodied in the applications a business uses, into the cloud, it is certainly not the same as developing new cloud native apps.

Typically, large companies will have a mixture of bought and internally developed apps. In almost all cases, these applications were designed for a client-server or standalone on-premise environment, with connectivity “out” to the world. Moving those apps to the cloud is a task not to be underestimated, from recent experience. It would be a little bit like taking old fashioned analogue telephone handsets and installing them on the space station.

The trade-off for a business is how much cost is involved in the migration as opposed to re-development whilst at the same time delivering an overall cost saving by migrating to the cloud.

One final comment is that Azure is, in practice, a server only environment. Client’s are not “allowed”. As far as I can tell without wishing to delve into the mysteries of Microsoft licensing, virtualising Windows 7 or 8 is forbidden under nearly all license agreement types. There is no technical reason I know of that it would not work but I’m fairly sure Microsoft are intending to stop that particular use case, which is a bugbear if you are using Azure as a lab environment.