To encourage EU cloud adoption, in January 2012 EU Commissioner Neelie Kroes announced the establishment of a ‘European Cloud Partnership’, aiming to overcome fragmented EU public sector demand for cloud and harmonise and integrate public sector buying power, with a comprehensive cloud strategy due out before autumn 2012. To that end, on 12 April 2012 there was an open information day on the ECP (agenda here), and there is industry support for the ECP too.
But specifying ‘cloud computing’ requirements for government or others is a bit like specifying requirements for ‘the internet’. It is critical to be clear exactly which element is under consideration.
So, to summarise what I personally feel are the fundamental points about cloud, let me serve up my culinary confection: the 12 Cs of Cloud Computing!
1. Combo Term.
‘Cloud computing’ is really an umbrella term that’s more complex than it might seem. It is often used as shorthand to refer generically to a combination of several very different types of services, which happen to share some common features.
But, like the internet, not all cloud computing is the same. It is important that attempts to formulate cloud computing regulation/standards/requirements should not assume that all forms of cloud computing are equal, or treat all types of cloud services or providers the same way.
Here’s my first foodie analogy.
SaaS: ready meals – or fast food.
IaaS: rent a standard kitchen complete with sink, worktop, ovens, some utensils. Want a bigger kitchen or more ovens? Ask and it’ll be magicked up automatically for you. Cook away.
PaaS: rent a kitchen pre-equipped for your favourite cuisine. One type of kitchen comes with woks for Chinese cooking, another with thalis for Indian food. (Java, Python, PHP, .NET… )
You wouldn’t deal with cooker rentals in the same way as ready meals or fast food. Or you could try to, but to do it effectively you’d need to keep in mind their differences.
2. Componentised.
Food involves several components: cooking equipment, utensils, ingredients. You could rent a kitchen from X, rent a cooker from Y, and buy ingredients from Z or even grow them yourself. Or you might get the whole lot from X, who offers a take-out service.
Similarly, cloud computing utilises several components: hardware infrastructure, cloud software infrastructure, application software. Not all must be from the same supplier; often, different providers are involved. Users may even install their own application software, with IaaS/PaaS.
Accordingly, cloud contracts/requirements/regulation should be careful to pinpoint, and be appropriate for, the exact component(s) in question. If you are worried about supermarket sales of possibly unsafe chicken, specifications or regulations regarding kitchen rentals won’t address the problem.
3. Cake (layer).
Cloud computing is often a layer cake. Cloud services offered to end-users may be laid on top of one or more layers of other services, which may supplied by different providers, meaning chains of dependencies are possible.
Culinary analogy: I can cook food to eat myself, or to sell to others. I could market Italian ready meals I’ve cooked using rented kitchens, perhaps pre-equipped for Italian food. My customers don’t necessarily know where I’ve got the ingredients from, or whose (or what type of) kitchen I used. And if I’m a supermarket using third-party suppliers of ready meals, who might depend on food growers, kitchen rental companies, etc, my customers and I might well want to know who they were, or at least that they’d met minimum hygiene etc standards.
Similarly, some cloud providers are both providers and users, offering services to their own customers/end-users built on other providers’ services. Notably, SaaS can be built on IaaS or PaaS (which itself may be built on IaaS). Examples: storage provider Dropbox’s SaaS service is built on Amazon’s IaaS, while collaboration services provider Skydox’s SaaS service is built on Engine Yard’s PaaS, in turn built on Amazon’s IaaS.
You might say there’s a further, bottom physical infrastructure layer, comprising data centres and servers/storage equipment, because some cloud providers use third-party data centre operators. Before April 2011, Facebook didn’t provide its SaaS social networking service via its own data centres, but leased server space from separate data centre providers. But end-users won’t always know who all suppliers are, in the cloud of unknowing.
With cloud, it is important to distinguish and bear in mind which layer(s) you need to know about, and which layer you are subjecting to regulation or contractual specifications or commitments. A provider of one layer might have some control over a lower-layer provider – but it might not. It might not even have a direct relationship with a lower-layer supplier.
4. Commoditised, Common Infrastructure.
Public cloud, particularly SaaS, generally offers commoditised, standardised resources. Some options can be customised a little, but mostly you are limited to getting what you get.
KFC specialises in things chicken. Want burgers? Perhaps try McDonald’s instead. Both McDonald’s and KFC have set menus, although you can choose your sauce. Having a limited, standard range of food available, ie commoditisation, makes it faster and cheaper for customers. Ask McDonald’s for a 9″ bun, they’ll say ‘Can’t!’ They won’t re-tool their bakeries to make 9″ buns just for one customer. Ask them to sign a contract to do that, and you’ll probably just go hungry.
Similarly, modular rental kitchens are built/equipped to the owner’s standard specifications – not to the customers’ specifications. Tailoring kitchens for individual customers may be impracticable although, once in, you could rearrange utensils to your liking, and cook as you wish.
Private cloud is more likely to be customisable. Put together your own kitchen, perhaps in your own building, from a kitchen supplier’s range of units. Or get someone to build one to your specifications. But, it will probably cost more.
Commoditised public cloud computing also involves using common, shared infrastructure. Your take-out burger is cooked in a kitchen used to cook other people’s food (rather than a separate kitchen per burger!), probably using the same grill. With IaaS/PaaS, perhaps a better analogy is renting space in a kitchen used by other people; different users might share the same fridge, etc.
Again, shared resources and economies of scale permit efficiencies. However, you might also be concerned about the kitchen owner or other users nicking your food from the shared fridge – so the individual setup could make a difference; some owners might be better than others at segregating securely individual users’ workspaces and food.
5. Cook-it-yourself.
Cloud is cook-it-yourself. With IaaS/PaaS, you are renting DIY, self-service resources, to use as you choose within the constraints of the, usually standardised, service offered. Again think identikit, modular rental kitchens. Different suppliers might offer different units, but each generally standardises its ranges internally. Even with ready meals or take-out (SaaS), the ingredients and range of meals available are as specified by the provider.
But you are still the one processing data when using cloud; that’s not the same as paying someone else to do it for you. Using passive tools is different from hiring active agents. Analogy: buying take-out, or hiring a kitchen you use to cook in, is different from engaging a caterer or chef to cook meals according to your instructions.
EU data protection laws require controllers of personal data (cloud users, here) to include, in their contracts with processors (providers), clauses effectively designed for hiring caterers. They don’t really suit buying ready meals, or cooking things for yourself using rented resources. Unfortunately, the draft Data Protection Regulation, which would reform these laws, won’t improve things here, but instead would regulate use of caterers even more tightly.
6. Cost (Not Necessarily Cheap).
You generally get what you pay for. You can’t have your cake and eat it. There ain’t no such thing as a free lunch…!
So, for rock-bottom prices (or nothing), don’t expect cordon bleu. Public cloud is cheap because it is commoditised, standardised, using common resources (see 4). Cloud providers may not think it fair if the highest security requirements are imposed on all providers (some of whom are SMEs or individual developers), without allowing them to raise prices accordingly. If you insist, they might refuse to offer services in your market, or withdraw completely.
You want cordon bleu private cloud, or top security levels, you can get it – but it will cost more.
7. Control.
Of course you want hygienic kitchens/utensils, edible ingredients. However, you also have some responsibility to cook carefully – buy safe ingredients if they’re self-supplied, wash your hands, use oven gloves, wear hat and apron; you are the one working in the kitchen!
Similarly, cloud users don’t necessarily lose all control. Users have some control, especially with IaaS/PaaS and passive SaaS storage, and should consider exercising it actively.
Worried providers may access your data, or disclose data to law enforcement authorities? Encrypt or tokenise before uploading. Granted, you can’t do that if you need to operate on data in-cloud rather than just storing it, or if you want provider services like indexing/searching. But research continues on how to operate securely on data while encrypted. Some IaaS providers also maintain they can’t spy on processing within users’ virtual machines. It would help if they explained more clearly how and why.
Concerned providers might lose or corrupt your data? Backup. Pay extra for a provider backup, where not included in its basic (probably free, or cheap) service. Or backup to your own servers, or to another cloud service.
Consider insuring your cloud computing too, treated as outsourced processing by many insurers. But check the coverage scope.
8. Country of location.
Country of data location shouldn’t be the be-all and end-all. Cloud data can move round different data centres, possibly even in different countries, to maximise efficient resource utilisation. That’s a key point frequently made about cloud. Constraining location may reduce efficiencies, increasing costs.
However, EU data protection laws ban transfer of ‘personal data’ outside the European Economic Area (the EU plus Iceland, Liechtenstein, Norway). Transfers are allowed in limited situations, eg under the US Safe Harbor scheme, but they’re not always straightforward, leading to EEA-only data centres as the main practical solution for compliance.
Yet, over the internet, personal data are transferred outside the EEA everyday, through businesses sending to non-EEA recipients e-mails containing names or other personal data. Also, given remote internet access, confining data to European servers is neither necessary nor sufficient for security. Even European servers can be hacked from outside.
Ensuring appropriate security, transparency and accountability seems more important for data security than focusing narrowly on data location as such. Canada’s Personal Information Protection and Electronic Documents Act 2000 doesn’t prohibit data export or restrict data location per se, but stipulates that organisations remain responsible and accountable for personal information they control, even when transferred to third parties (wherever in the world) for processing, so they must use contractual or other means to provide adequate protection during that processing.
Readers may be relieved to know that I offer no food analogies here!
9. Customers, especially Consumers.
Restaurants should recognise certain customers need food that is kosher, or nuts- or seafood-free. Some customers might shrug, thinking, ‘It is cheap, I’ll eat it anyway’, and take the risk of the meal containing nuts. Others want to scrutinise the menu, even ask the chef to ensure utensils used for their dish haven’t touched any prawns. However, ideally the restaurant industry should cater for a wide range of customer requirements. Similarly, the cloud industry should serve a range of customer needs.
But equally customers need enough awareness and information to enable them to make informed choices. It is important to improve education of cloud users, and indeed lawyers and policymakers, so that they understand better how cloud works: what is possible, what isn’t; what customers can control, what they can’t; what self-protective actions are possible, and their cost and other implications. Users, particularly organisations, also have some responsibility to seek education.
Developing industry standard, trustworthy certifications and/or codes of conduct would assist users – the equivalent of ‘Guaranteed nut-free’ or ‘Kosher’, eg ‘Fit for personal data’.
10. Competition and Competitiveness.
Encouraging competition and addressing lock-in are critical too.
Data (and metadata) portability, application portability, interoperability between different cloud services: they’re all relevant. Customers are more likely to use cloud if they can be confident they won’t be trapped, ‘locked in’, to one provider and its proprietary systems, data formats etc.
Industry standards and certifications, on portability and interoperability as well as security, are urgently needed to reduce user confusion and hesitation. Lawmakers might step in if what is needed is not done soon enough. For example, the proposed Data Protection Regulationcontains certain data portability requirements for personal data – flavoured with consumer protection and competition as well as data protection concerns.
As new players offer cloud services, providers may need to work harder to stay competitive, just as restaurants may need to improve menu items, make them clearer, include more information about their food, display certifications, memberships or subscriptions to industry codes of conduct, and recognised star ratings.
11. Comparisons.
For cloud to develop to its full potential, and to protect consumers, it is also important to enable and empower users to compare services easily – not just prices but also features such as security levels.
Standards and certifications should again help here, as should greater provider transparency. Make restaurants display menus in windows, perhaps in standardised formats; customers shouldn’t have to ask for them. Make menus state clearly whether the food is vegan, kosher, contains nuts! Establish systems for checking claims, with a variety of (correspondingly priced) options – self-certified, independently-certified, perhaps subject to occasional or indeed regular inspections; even institute mystery shopping by food guides.
However, cloud services can be very different. So it is important that apples should be comparable with apples, pears with pears. Users need to know when they check out other apples, or other pears; that’s part of educating users and fostering, indeed perhaps even requiring, transparency and standards, including recognised certifications etc.
12. Contracts.
Many providers’ contracts involve ‘Click to accept our standard terms’. Unsurprisingly, those terms are generally provider-favourable; some might even be invalid under consumer laws.
Customers may therefore find providers’ standard terms don’t suit their risk profile (eg total liability exclusions) or compliance needs (eg omitting terms they must include in their contracts for regulatory reasons).
So, equally unsurprisingly, there’s been pushback from customers who have enough bargaining power to negotiate, and from regulators concerned about data or consumer protection.
Providers whose standard terms aren’t more balanced may find authorities or others taking legal action or passing new laws. Customers may move to other providers, including newer entrants and solutions providers/systems integrators, who are more willing to share risk and offer more competitive, customer-suitable standard terms (eg by accepting some monetary liability).
Big customers, like government or financial institutions, can influence terms in the market by requesting changes to providers’ terms (and indeed minimum standards, certifications etc), educating providers about users’ needs. Then perhaps changes will filter down to the middle market.
Some large customers even insist on their own standard terms (for a mixed approach, see the UK G-Cloud programme v1). However, customers’ standard terms, based on traditional outsourcing contracts, may, like some current laws, not always be appropriate to how cloud computing works. So, just as some providers may need to make their terms more customer-appropriate, some cloud users may need to make their own terms more cloud-appropriate.
Concluding: Customer Choice
In summary, all these should boil down to improving informed customer choice.
Legislation, regulation and governments should encourage a bigger range of cloud services to be developed, rather than restricting too early or too narrowly what certain (or indeed all) cloud services can or can’t, must or mustn’t, do.
Kitchen rentals aren’t like fast food. I’m all for ensuring take-out places serve food that won’t poison me but, equally, kitchen or cooker rental companies shouldn’t be treated in the same way as fast food outlets or supermarkets.
If a restaurant advertises cheap, fast food but says nothing about nuts, and people with nut allergies eat there, they might well be affected. But the solution isn’t to make all restaurants remove all nuts on pain of fines or jail.
Diners have some responsibility for knowing and understanding what they need and choosing suitable restaurants, eg asking about nuts. If a restaurant can’t or won’t meet their requirements, they should be able to go elsewhere. But to do that, they need education, knowledge and information to recognise and assess their own needs and how suitable a restaurant is for those needs, and they also need a reasonable selection of alternative restaurants they can try instead if a restaurant uses nuts, or doesn’t give information about nuts.
We shouldn’t make vegans eat meat, but neither should we make steakhouses stop serving steak, or serve vegan-only options. Put another way, rather than forcing all restaurants to change menus or prices, or serve food suitable for those with particular needs, isn’t it better to improve education of users, providers and others, and foster a range of restaurants offering a wide variety of food and prices, some with short menus, some long, but all with clear menus enabling like-for-like comparison of food and prices, displaying any recognised certifications, codes of practice, and star ratings? That way, people can make an informed choice amongst restaurants that are suitable.
In other words, why not encourage development of a full menu of services to suit a broad range of needs, each with corresponding contract terms that are both customer-appropriate and cloud-appropriate? For example, cheap services for non-sensitive data, more expensive services reliably certified as fit for personal data or confidential data, and top price, top of the range, cordon bleu clouds for military secrets.
Let’s hope work proceeds quickly enough on cloud-suitable industry standards/certifications and laws/regulations/contracts, to reduce bureaucracy while promoting innovation, transparency, trust – and true choice for customers.
Kuan Hon, a non-practising English solicitor and New York attorney, is a joint law and computer science PhD candidate at Queen Mary, University of London, and part-time consultant to the Cloud Legal Project. This article expresses her personal views only.
