Thursday, 30 June 2011

The Cloud and the Patriot Act

The Patriot Act is a US Act that essentially says that the US Government can access and intercept any data held by anyone on US territory. There has been quite a lot of vagueness about whether or not the scope of this Act extended beyond US territory and cloud providers such as Amazon have, in my view, avoided making any statements on this.

Microsoft in their official release of Office 365 have now clarified the position as they see it. Their view is that any US-headquarted company that maintains data are bound by the Act irrespective of where that data is stored. Therefore, data stored on a public cloud run by one of the big providers can be accessed by the US Government.

This hasn't yet been tested in court but what it means for cloud users is that if you have any reason to think that your data might be of interest to the US Government, then don't use a US headquartered company for cloud services. Even if (like me) your data is completely innocuous, Governments have been known to get things wrong and you may not wish to take the risk.

This clarification is great news for local cloud providers in the UK and an opportunity to pick up business from organisations that are risk averse on compliance issues. For sure, they are not bound by the Patriot Act and they can guarantee that there will be no US Government snooping.   

Tuesday, 14 June 2011

Cloud confusion

We are involved in project where we are helping a number of companies in managing the migration of their software products to the cloud (website here). At today's meeting, it became clear that even these technically-sophisticated companies were a bit confused by the fact that everyone is talking about 'clouds' but are (perhaps deliberately) using the term in quite different ways.

This blog post by Paul Woodward from Symetriq, a Scottish hosting company, sums up part of the problem but some of the confusion comes from mixing up the notion of service provision (infrastructure, platform, software), remote hosting of servers, payment models (pay per use rather than outright ownership) and the management of scale and elasticity. The notion of 'private' and 'public' clouds doesn't help, especially when sometimes 'private clouds' are remotely hosted by a 'public cloud' provider.

So to clarify what I am talking about, here are my thoughts on what some of these terms mean.

A cloud is a set of servers that is controlled by some cloud management software that can automatically start and stop virtual machines running on these servers. The overall cloud configuration therefore is elastic and changes dynamically. A statically configurable set of VMs which is manually configurable is not a cloud.

You have a private cloud if the physical servers running your software are only used for that purpose. These servers can be remotely hosted but you should be able to identify your specific servers at that site which are yours.

You are running on a public cloud if the cloud provider decides on the server where your virtual machines will be scheduled and you have no control over this.

There is no such thing as 'the cloud' as an entity. However, 'the cloud' may be an easy way to refer to the general notion of running software or managing date on remote clouds, without being specific about what these are.

A service is something that is potentially offered to a number of customers who use that service without owning the underlying system that provides the services. Now ownership is a confusing notion for software anyway. When you buy a licence for some software, the terms and conditions mean that you don't necessarily own it in the same way that you own a book that you buy from a bookshop. However, I think of owning software as paying for the right to deploy the software on whatever machines I wish, obviously depending on the licence. If I don't control the deployment, I don't own it.

Therefore, if you buy some software functionality from someone else who deploys that software, you are buying a service. Buying a service doesn't have to be pay per use - you might pay according to a subscription model, which allows unlimited use over some time period. Dropbox, for example, offer a storage service where you pay an annual subscription for a given amount of storage whether or not you use it.

A cloud service, however, is distinguished by pay per use. Therefore, buying storage on Amazon is definitely pay per use - you pay according to the amount used. Dropbox don't offer a cloud storage service although they may actually use a cloud storage service to implement their service (this is a guess - I don't know). Interestingly, you can offer a cloud service without actually hosting the underlying platform on a cloud.

So, if we are talking about migrating software products to the cloud, then there may be a number of stages in this process

1. Moving the payment model for the product from a one-off licence to an annual subscription, with the product provider responsible for hosting the software.

2. Re-architecting the software product so that it is implemented as a set of services. The product is still presented as a monolithic system.

3. Selling individual services rather than the whole product, perhaps on a subscription model

4. Implementing a metering system that allows services to be charged according to usage

It is only when you have reached this last stage, that you can say truly say that you have implemented services on the cloud. But, from a business point of view, you might want to stop earlier in the process.