Is the way to the European Cloud paved mainly with good intentions?

At the end of last month the EU released its plans for “Unleashing the Potential of Cloud Computing in Europe”. But although the document (s) - just like EU commissioner Kroes in this video - do a good job describing in non-technical terms what cloud is and why Europe should care about having a competitive cloud position, it kind of stops there.

Even though it defines three key actions – around Standards, Terms and Public Sector taking a lead role - most described actions consist of softer items such as “promoting trust by coordinating with stakeholders”, “identifying best practices”, ”promoting partnerships” and “investigating how to make use of other available instruments”. Now of course European cloud computing can benefit from funding reserved for other EU initiatives such as the Connecting Europe Facility and from side initiatives such as the “Opinion on Cloud Computing” published by the Article 29 working party that gives privacy-related contracting guidance, but in general the recent published plan seems to be more about what could and should be, than about what is or will be.

Meanwhile, both regular and social media seem to be increasingly negative regarding the progress that Europe is making. With the North American continent clearly being the biggest cloud geo and ASIAPAC – also thanks to its many emerging economies – claiming the position of fastest growing cloud geo, it only leaves less desirable labels – such as slowest or most fragmented - for describing the state of cloud activities in Europe.

Continuing to look at why things are harder and slower in Europe will just further reinforce negative sentiments, better to focus on European examples that are showing success. And in “Switch: How to Change Things When Change Is Hard” the brothers Dan and Chip Heath offer an engaging recipe for doing just that. In their book they describe how by identifying “Bright Spots” (small pockets of positive exceptions) potential future success scenarios can be discovered. Next, they encourage promoting very specific actions instead of giving broad directions. For example: Instead of asking people to eat healthier (too vague, too hard), they suggest healthcare activists promote a specific action such as "buying skimmed instead of full fat milk" (simpler, easier, more actionable, more effective).

So in Europe, instead of pushing cloud as a concept (too vague, too hard), why not focus on identifying a few very specific and very simple scenarios including their specific benefits. Next Europe can concentrate on removing any (legal, fiscal, economic, cultural) barriers to these specific scenarios and promote these few clearly and broadly. And in doing so best to follow the Heath brothers advice to promote this both on a rational and on an emotional level (or as the brothers put it eloquently: both "Direct the Rider and Motivate the Elephant" ).

PS What potential European cloud Bright Spots would you suggest (using the comment field on this blog)?

A Cloud That Cares? Or About Eating Your Cloud And Having it too.

Although self-service -together with elasticity, pooling/sharing, etc. - is a defining attribute of cloud computing, many of the companies expressing an interest in cloud computing do not seem to be aware of that.

In fact, when asked: who do you expect to provision your services to the cloud?; who will monitor your services' performance and availability? and; who do you expect to take action if something goes wrong?, a majority of the companies asked look to be somewhat surprised by the question, as they simply assumed that their service provider would do so.

This is a bit like going to a supermarket (a typical self-service facility), pointing to the ingredients you like and expecting the cashier to clean, cook and serve them for you. The name we generally use for such a service however is "restaurant" and it comes with significant different expectations and pricing, as demonstrated by the price of a bottle of the wine in a restaurant versus that same bottle at a supermarket (which is one reason restaurants prefer to buy from exclusive wine merchants and not to put bottles or their wine list that are available in retail).

The supermarket versus restaurant analogy may sound like a silly comparison, but is useful to further illustrate the difference between cloud computing and more traditional IT services. It is not just that the product is vastly different: a raw steak on styroform and a brown bag with vegetables versus a prepared steak - cooked to our liking - on a nice plate, brought to our table with a smile.

The much more telling difference lies in what we would reasonable expect to happen if something goes wrong. For example: if a supermarket burns down, we would expect the supermarket to - first and foremost - concentrate on building a new facility so it can restore its service. We would not expect the supermarket to call us and help us plan tonight’s meal or offer any alternatives on an individual basis. Likewise expect cloud providers to focus primarily on getting their cloud back up in case of problems.

However, if a restaurant burns down we would find it reasonable they would call people that have made reservations. And if we booked a wedding there for next weekend, we would expect the restaurant to help us find a new facility, help us agree the new menu with the new chef and reimburse any additional cost (unless we change the menu from steak to lobster).

Self-service in most cases means the provider is not aware of what the individual customer is using its product or service for. As a result it is not getting involved with individual outcomes (as it simply does not know those). This separation is also not uncommon in self-service infrastructure and even used as line of defense in case that infrastructure turned out to be used in “less than legal” ways.

Hybrids

Self-service supermarket have a lot of benefits that restaurant customers may also be interested in: choice, speed, price, no need to make a reservation, ample parking, to name just a few. So is there a way to eat our cake and have it to?

One option are self-service restaurants, like the ones you may find along most European highways. Service tends to be fast, no need to make a reservation and if the restaurant happens to be full, we just drive to the next one. Here self-service is the overriding attribute. It’s a supermarket with cooked foods, in most cases without the price advantage. And we probably would not plan having something important, like a wedding (or another mission critical event) there.

An option closer to the desired experience may be eating at a full service restaurant that sources from a supermarket. Such a restaurant could source it ingredients on demand (by simply walking across the street), it could offer enormous choice and would in most cases not run out of ingredients. It would however likely have to pay retail prices for these ingredients (supermarkets margins are thin and they do not have a lot of room for additional discounts, especially if you don't buy in bulk). But retail prices might conceivably still be lower than what a restaurant would normally pay from it traditional channels (like the exclusive wine merchant).

Pricing

As the prices of the underlying ingredients are now transparent, end-user pricing becomes an issue. Do we pay for an all in price a cooked meal (including seat and cutlery) or do we pay separate for cooking, serving and use of the facilities. In North America paying separate for service is still customary, and although not too long ago - in the southern parts of Europe - you would be charged separately for the couvert and the service, European restaurants now largely evolved to all-in-pricing. The drawback of such fully inclusive prices is that people compare it to the publicly known ingredient prices (a problem not unfamiliar to many an IT manages, who tried to explain the difference between the TCO based price of the fully managed PC their department offered and the price of that same PC in the local mall or - even more pronounced - from an on-line retailer).

Resilience

But -just like cloud computing is not all about cost - eating out is not just about price, it is also about agility, productivity and resilience. By not having to spend time cooking, people can have more quality time or -more likely - spend more time at work: finishing that last assignment, winning that additional customer. This does however mean we are now dependent on the restaurant for a pretty essential part of our life: eating. So what happens if our restaurant - that now sources from a third party self-service supermarket- runs into problems?

As we are not buying this as self-service, we would expect the restaurant to care about the outcome (us being hungry or fed) and take DR measures in case something goes wrong. But in how far is it fair to expect that the restaurant can reasonably do this, as they are now dependent on the supermarket? Can the restaurant stay open if the supermarket closes for a holiday or if I order something after supermarket closing hours. Or is it relegated to being a middle man no longer able to control its own SLAs.

Having the supermarket and the restaurant under the same management (meaning the restaurant guys have keys to the supermarkets’ back door) can help. But only if the supermarket manager allows his restaurant colleagues to interfere in his operations and impact his targets and quality (something not very common in larger organizations).

Smart restaurant would likely source from two or more supermarkets - preferably from separate chains, located in different streets. So it will be able to serve its customers even if one of them closes or burns down. And maybe that should also be the conclusion if you are looking (even though the definition would argue there is no such thing) for a non self-service cloud. In other words if we want to eat your cloud and have it too.



Disclosure: Before getting caught up in IT & Clouds, the author worked as a manager at the largest restaurant in the Netherlands, which indeed did burn down during that period but managed to restore it services within a week and keep it running throughout the reconstruction.