Tune Into The Cloud

The ultimate dream of any marketer is to have its brand become a verb. “Let me quickly Xerox that”, “I Fedexed it to you yesterday”, “I just Googled it”. In cloud computing I do not see that happening any time soon. At least I haven’t heard anyone say they Amazoned their intranet or forced their custom apps yet. But it is also unlikely we will be calling it cloud computing forever.

The number of initiatives is overwhelming. For years the joke was that any time two Dutch meet, they are likely to start an association or co-operative initiative, but apparently that is also true for security and cloud experts. I won’t bore you with all the clever acronyms (it’s a true alphabet soup), but I do want to highlight the more interesting overall findings.

In one of the first forum sessions – called “In Cloud We Trust” – Dr. Laurent Liscia of OASIS gave an interesting perspective on these competing standards. He compared the process of establishing an accepted standard to a Petri dish (no relation).  Multiple cultures in a nutritious environment all trying to do a land grab. A process that is not orchestrated, it’s ‘eat or be eaten’ and it is hard to predict the outcome because the process takes time.  No amount of pressure  or additional heat can accelerate it and watching a Petri Dish real-time is about as useful and as interesting as watching grass grow. Meaning, it’s better to wait for history to run its course.

Having said that, there one initiative from this forum – which had participants from ENISA, The World Economic Forum, TRUSTe and CA Technologies – that I do want to highlight, even though the implementation is still in an incubation phase.

The recommendations are not earth shattering, but if governments and the cloud ecosystem participants could streamline their efforts around these eight, it would further these efforts in a useful and pragmatic way. For more info read the (very readable) full report, but in a nutshell the recommendations are:

1. Explore and facilitate the realization of the benefits of cloud
2. Advance understanding and management of cloud related risks
3. Promote service transparency
4. Clarify and enhance accountability across all relevant parties
5. Ensure data portability
6. Facilitate interoperability
7. Accelerate adaptation and harmonization of regulatory frameworks
8. Provide sufficient network connectivity to cloud services

P.S. During the event I participated as a forum member in “Cloud Standardization: From Open Systems to Closed Clouds?,” and “Identity and Access in the Cloud.” I will be speaking more about the topic of lock-in at the upcoming International Cloud Expo in New York (June 6-9), and I will cover cloud computing and risk during the Middle East Financial Technology Conference (MEFTEC) in Abu Dhabi (May 30-31).

A lot has been written about the outage, so I won’t repeat that here (if you want to catch up suggest you read: TechCrunch for the PlayStation story, GigaOM for an overview of the Amazon issue, eWeek for some interesting analysis and the DotCloud blog for a very readable explanation of day to day use of a public cloud service like Amazon).
Instead, let’s focus on the big picture of the cost of reliable cloud, comparing it – again – with the move from mainframe to distributed computing.  History tends to repeat itself, especially in IT where generations of technology tend to be heavily siloed, and staffed with different generations of people who often do not even sit at the same table in the canteen.

Somewhere during the 1980s, IT pros started to realize they could get the same processing power for significantly less money, when selecting distributed servers – till that time used mainly for scientific work – instead of traditional mainframes.  Soon after, companies began porting existing applications to the new platforms, focusing initially on applications that were more compute than I/O or data intensive (sounds familiar?). And indeed, initially the new departmental platform, not requiring all the resource intensive water cooling, air-conditioning or a heightened floor did seem a lot more cost effective. But, it didn’t take long after initial proofs-of-concept to find that for some applications we needed more processors or to set up clusters, or uninterruptable power supplies and other redundant features. On the storage front, we started to use the same – not so cheap – storage solutions as we did on the mainframe. And shortly thereafter, the distributed boxes started to look and cost about the same as the systems they were replacing. Let’s not forget that at the same time, smart mainframe developers – pushed by the competition from distributed systems – found ways to abandon water cooling, leverage off the shelf standard components like NICs and RISC processors and even re-examined their licensing cost for specific (Linux) workloads.

What does this all have to do with cloud computing? Likewise, we see that running a certain “compute intensive” workload can be done much faster and cheaper in the new environment. But when replacing these one-off batch jobs with services that have higher availability and reliability needs, the picture changes. We need to have redundant copies and failover machines in the data center, and in many cases a backup data center in another part of the country, preferably located on an alternate power grid and connected to multiple network backbone providers. All of a sudden it sounds a lot like the typical set-up a bank would have – and likely with a similar cost profile. So far cloud seems to offer cost benefits, but will this cost advantage still exist if we need to replicate our whole cloud setup at a second vendor – worst case scenario, doubling the cost.  Now cloud has many other advantages beyond cost (elasticity, scalability, ubiquitous access, pay per use, etc.), so many specific use cases are still ideally suited  for the cloud, but if a certain application has no need for these, then it may be worth (re-)considering the business case for a move to the cloud.

Regarding redundancy, the cloud business case actually has two opposing vectors. On one hand, there is the fact that as a user you have less control (you can’t fly there and ‘kick’ the server) leads to requiring a secondary backup installation. On the other hand, the cloud – with its pay-as- you-go model – offers much more efficient ways to arrange for a backup configuration for running your applications, than finding your own second location and filling it with shiny new kit.

At the same time you have to take into account the likelihood of the cloud having capacity available at the moment you need it. If your own data center fails, I am sure you could find another cloud provider with some capacity. But in this case, where one of the largest (cloud) data centers in North America had issues, all customers, in principle, could be looking to move their workloads elsewhere, it is not certain that enough excess capacity would be available at alternate providers.

In this specific case there seemed to have been technical issues inside Amazon and Sony’s data centers that caused a series of events impacting the services running within, but what if there had been a major physical problem, such as a large fire or accident? With more mission critical applications moving to the cloud, companies need to make contingency planning a top priority.

As a result of last week’s incidents, enterprises should take stock to assess what services are truly vital to their customers and/or to their own continuity. Organizations (and the world) seem to be more resilient than you might expect. In the Netherlands we saw Telcos ceasing mobile service in a large part of the country  for periods of up to half a day, with ISPs unable to offer Internet services for as long as a week in certain regions. And yet, these companies did not go under. Each industry, government and organization will have to assess its own priorities and success metrics/criteria and standards. As I mentioned in a past blog post, aiming to continue your on-demand video services after a mayor flood, hurricane or nuclear disaster may be over-shooting what is necessary under those circumstances – survival will be the only concern in a case like that.

Looking at the reactions in the market so far, the responses of the vendors impacted by the Amazon mishap seem to be a lot more benign that the reactions of impacted PlayStation gamers. Maybe because these vendors feel they have a good thing going and the last thing they won’t to do is kill it by too much honesty. What is refreshing is that not too many vendors crawled out of the woodwork saying “private cloud, private cloud, private cloud” — not even my colleagues who recently published a book on the topic. Good!  Nobody loves “I told you so” types and there’s no point in kicking your opponent when he is down. But the case for private cloud did get a bit better, or is it just me thinking that?

Now this may seem like contradictory advice, but there is a great risk of vendor lock-in with cloud computing than there is with traditional on premise software, and I’m sure that you will be aware of the downside of vendor monopolies such as high cost, low responsiveness and inflexible vendor business practices, which result in vendor lock-in and prohibitive switching costs.
A second important reason to avoid vendor lock-in to any cloud computing services is that unlike today, where software is purchased and then used to deliver services to customers, in the cloud era organizations are directly dependent on external providers to deliver those services. The impact of a breakdown or contract termination of as a service delivery is much more immediate to the business, it is therefore imperative to have a plan B.
Ideally you will architect your cloud services and contracts in such a way, that you can move to an alternative (Plan B) within a reasonable timeframe. A definition of reasonable depends on the type of business and may vary be between six months and six seconds. Standards, although currently just emerging, will play a crucial role and I recommend that you consider any implementations that are not based on such standards as temporary. Meanwhile the automation capabilities of vendor neutral management tools can help enable such exit strategies in a cost effective manner.


2. Design IT as a supply chain
Although deceivably simple, this analogy will help to change both the way the IT organization thinks and acts and, how other departments perceive IT. Supply chain thinking allows you to both buy and build; it allows you to make all your decisions in the context of what your company needs in order to deliver services to its customers. It allows you to look at what your IT department owns in-house but also all the services you sourced externally too. A good rule of thumb in setting your IT supply chain strategy is the lean mantra: Only do what adds value to your customers and remove any steps/activities/processes that don’t add value or aren’t legally required.
A supply chain approach means dynamically balancing resources (both internal and external) against rapidly changing goals and constraints towards an optimal end result. This is a very different game from traditional IT where IT operations avoided changing anything that was not broken to “keep the lights on” in the most reliable and stable manner possible. Just as in a car factory the product mix changes constantly, new products are introduced while others are phased out, the supply chain will enable IT to switch services on and off as and when required.

A good cloud strategy is as much about WHAT to do as about HOW to do it. A portfolio approach helps you identify which services could be moved to the cloud and deliver cost savings and agility to the business, versus the more business critical services which – at this time – are less desirable to move to the cloud.
A portfolio approach needs to begin with the strategic goals of your organization in mind. These goals may vary from becoming customer focused to launching products in emerging markets or; reducing cost within the business.
Once the strategic goals are identified, these need to be matched to business or market constraints for example legislation, resources, geography or finance. The final step would be to map the goals and constraints to existing IT services and your cloud based opportunities.
From this exercise you will produce a roadmap of what you need to do; how you allocate human, financial and technical resources to deliver the most critical services and, monitor progress against your plan.
IT portfolio planning is not a one-off exercise and not something that can implemented overnight. It will constantly evolve as the business evolves and as IT gains maturity and experience in consuming and deploying cloud services.  It is a good starting point to determine  your “low hanging cloud fruit” which could add considerable value in terms of benefits or cost savings quickly and, those services which are too business critical to be put into the cloud.


4) Make service costing a core competency
If cloud computing it going to achieve one of the goals it is heralded for, then it needs to remove unnecessary cost – not just move CAPex to OPex.
Regardless of whether a service is completely rendered in house, composed from various sourced components or procured completely as a service, it is essential to understand the exact cost characteristics and the impact on the overall cost of doing business.
IT needs to be able to determine the cost of each service delivered rather than just the cost of individual IT functions. For example, services may include payment processing, issuing tickets, sending invoices, creating an order, facilitating video conference calls and delivering online training courses.
In electronics manufacturing the heads of production are not interested in how much the company spends in total on plastic versus aluminum or copper, but they want to know whether they can offer their new product at a competitive price compared to their competitors.  In the same way, IT needs to prepare itself for such discussions, can they deliver services at an optimal cost, and if not, can they suggest a viable alternative?
Cost reduction is not the only reason or benefit when adopting cloud computing, increased accountability and agility and reliability are a few other areas which cloud computing can really impact positively. So whilst increasing transparency in the cost of IT services will give you insight into areas to optimize from a cost perspective, you may need to balance this view with potentially needing to increase investment in the short term for greater business agility.


5. Treat security as a service
Security or to be precise “fear of a lack of security” is consistently cited as the biggest barrier to cloud computing. However, a recent study conducted by Management Insight and sponsored by CA Technologies showed that 80 percent of mid-sized and large enterprise organizations have implemented at least one cloud service, with nearly half saying they have implemented more than six cloud services. This adoption is happening even though 68 percent of respondents cite security as a barrier to cloud adoption. These survey results indicate that for now cost and speed of deployment are leading reasons for cloud adoption and are strong enough to offset the perceived risks associated with deploying cloud services. This may be a sufficient for now, but as increasingly sensitive data and applications are selected to migrate to the cloud, organizations will quickly reach an impasse.
The security challenge with the “supply chain” model is an organization’s ability to dynamically control access of a variety of users across a changing portfolio of applications running internally and externally from multiple suppliers.
The cloud computing model demands a rethink about how security is approached- making it an enabler instead of an inhibitor. The challenge is, not denying access to everyone, but letting the right people access the data they need to have access to (and no more than that) and to actively control the usage to prevent any out-of-the-ordinary activities.

Now having shared some advice and suggested first steps to start planning, I’d like to add one last thought.
The appropriate speed for deploying cloud computing depends on the culture and current state of your organization and realistically you aren’t going to be in the cloud tomorrow. The US Federal government issued a directive called “Cloud First.” This is basically a type of “Comply or Explain policy” which states that cloud options should be evaluated first (comply) unless there are significant reasons not to do so (in which case departments should explain). Pushing the accelerator that hard might not be everyone’s cup of tea, but whatever you do: don’t rush in, but also make sure you do not get left behind!

In my last post I covered the concept of fabric computing and why it matters in the world of cloud computing.  With a “fabric” approach towards creating a cloud application, we include the virtual compute, storage and network components inside a fully software-based model of the service. This is distinctly different from a more traditional approach, where the various resources are added and configured one by one.

In response to a comment, I also suggested that this new approach could be compared to a modern espresso machine.  Such a machine delivers a complete service (coffee!) – in an integrated fashion.  No need to worry about the temperature of the water, grinding the beans, any other steps or equipment required to make it happen.

In a cloud computing context, the fabric is integrated “out of the box,” like the espresso machine. It doesn’t require provisioning, managing, integrating and monitoring lots of VMs and appliances individually. Most cloud solutions approach building a cloud by automating these individual steps – typically through scripting — but this approach has distinct drawbacks. I included a short demo of the fabric approach below, but to understand these drawbacks we will use another analogy:

                                                    

Have a look at the demo below to see how that applies also to a fabric cloud application (including “save as”, creating multiple versions, send it to someone else to run).  But first ask yourself: when did you last see an accountant with a calculator? In fact automated calculators never really took off. Spreadsheets (fabrics) are simply the better way.

Seeing is believing: the epiphany of a demo
When I personally saw my first demo of this concept in action, it reminded me of two earlier occasions where a demo later reshaped IT as I knew it. The first was after I installed Windows 1.0 (all 12 floppies). Sure back then it was still monochrome, there were no applications and the performance was not great, but it did make me think: “Boy, if they ever get this to work, it will really change how we use desktop computers.”

The second “epiphany” was my first experience with X86 virtualization. After having confiscated the biggest machine in the office with the most memory, and after quite some tinkering I saw an actual X86 machine boot inside a window (of course this was not an actual machine – it was a virtual one). After it booted, it could not do much, and running two of them brought the whole machine to a grinding halt. Yet, it did make me think: “Wow, if this ever scales, it can completely change how we handle our machines.” And (admittedly somewhat to my surprise), about a decade later around 2009, X86 virtualization did actually start to scale and it developed into the billion dollar industry that is changing the way we manage our servers.

Just like Windows profoundly changed the way we use desktops and virtualization is changing the way we manage servers, this new software-based, virtual fabric approach, in my view will change the way we manage data centers. Now I was certainly not the first person to realize this. Nicholas Carr already acknowledged the power of this approach in his book “The Big Switch.” In an interview with eCommerce Times, he subsequently said:

“In 3Tera’s AppLogic, you can see the broad potential of virtualization to reshape how corporate IT systems are built and managed…”

How is that so? Well, my marketing colleagues here created quite an entertaining video , but the original – now vintage – 5-minute demo that shows how to define an application as an integrated fabric is also still out there (and shows the potential much better than my above ramblings).
CA 3Tera AppLogic software essentially enables you to do three things: 

1) First, you set it up on commodity x86 servers, creating a single fabric for the storage, network and compute capabilities on those servers.
2) Then, using an integrated modeling tool, you take your application or service – including all its components, such as data, networking, load balancing, security etc.– and create a 100% software based model (using a Visio-like drawing tool – check out this InformationWeek demo from Cloud Connect to see this in action).
3) Next, you can deploy a model of the fabric, with the software allocating resources based on the model, and providing automated scaling, metering and fail over capabilities.
You can also move the service or application to another data center very simply, even to one in another country or at another provider. Or, you can copy it and provide the same service to another department or customer (nearly instantly).

For a long time, CA 3Tera AppLogic software was kind of an industry insider secret. Several analysts and writers – like Nicholas Carr – were aware of it, discussed it and listed it in their publications. But today there are many case studies and real life success stories of both small and large implementations out there. This may be a good time for you to have a closer look; if only as an interesting implementation of these new fabric computing trends and principles in action.

If we check our handy Wikipedia for fabric computing, we get:

In the context of data centers it means a move from having distinct boxes for handling storage, network and processing towards a fabric where these functions are much more intertwined or even integrated. Most people started to note the move to fabric or unified computing when Cisco started to include servers inside their switches, which they did partly in response to HP including more and more switches in their server deals. Cisco’s UCS (Unified Computing System), and its bigger sibling, VCE, are the first hardware examples of this trend (although inside the box you can still distinguish the original components).

One reason to move to such a fabric design is that by moving data, network and compute closer together (integrating them) you can improve performance. Juniper’s recent QFabric architecture announcement is another similar example. But, the idea of closer integration of data, processing, and communication is actually much older. In some respects, we may even conclude IT is coming full circle with this trend.

Let me explain.

Many years ago I spoke to Professor Scheer, founder of IDS Scheer and a pioneer in the field of Business Process Management (BPM). (Disclosure: years later IDS Scheer became part of my former employer: Software AG.) He spoke about how – in the old days of IT – data and logic were seen as one. Literally! If – while walking with your stack of punch cards to the computer room (back then it was a computer the size of a room, not a room with a computer in it) – you dropped your stack of punch cards, both data and logic would be in one pile on the floor. You would spend the rest of your afternoon sorting them again. There was just one stack: first the processing/algorithm logic, and then the data. Scheer’s point was that just like we figured out after a while that data did not belong there and we moved it to its own place (typically a relational database), we should now separate the process flow instructions from the algorithms and move these to a workflow process engine (preferably of course his BPM engine). All valid and true – at that time.

But not long after, Object Oriented programming became the norm, and we started to move data back with the logic that understood how to handle that data, and treat them as objects. This of course created a new issue of having these objects perform in an even more remotely acceptable way, as we used relational databases to store or persist the data inside these objects. You could compare this to disassembling your car every night into its original pieces in order to put it in your garage. Over the years the industry figured out how to do this better,in part by creating new databases which design-wise looked remarkably similar to the (hierarchical) databases we used back in the day of punch cards.

And now , under the new shiny name of fabric computing we are moving all these processes back in the same physical box.

But this is not the whole story — there is another revolution happening. As an industry we are moving from using dedicated hardware for specialized tasks to generic hardware with specialized software instead. For example, you might use a software virtualization layer to simply emulate a certain piece of specific hardware.

Or, look at a firewall: traditionally it was a piece of dedicated hardware built to do one thing (keeping non-allowed traffic out). Today, most firewalls are software-based. We use a generic processor to take care of that task. And we’re seeing this trend unfold with more equipment in the data center. Even switches, load balancers and network-attached storage are becoming software-based (virtual appliance seems to be the preferred marketing buzzword for this trend).

Using software is more efficient than having loads of dedicated hardware, and we can’t ignore the fact that software, because of its completely different economic and management characteristics, has numerous inherent advantages over hardware. For example, you can copy, change, delete and distribute software, all remotely, without having to leave your seat, and even do automatically. You’d need some pretty advanced robots to do that with hardware (if it could be done today).

So how do these two trends relate to cloud computing?
By combining the idea of moving stuff that needs to work together closer together (the idea of fabric) and the idea of doing that by using software instead of hardware (which gives us the economics and manageability of software) we can create higher performance, lower cost and easier to manage clouds.

Virtualization has been on a similar path. First we virtualized servers, then storage and networking, but all remained in their separate silos. Now we are virtualizing all of it in the same “fabric.” This means that managing the entire stack gets simpler, with one tool to define it, make it work and monitor it. And that’s something that should make any IT pro smile.

In my next post, I’ll share my thoughts on why I think this approach has the power to change IT as we know it, based on some of my own epiphanies.

The decision framework for cloud migration that US Federal CIO Vivek Kundra recently published as part of his Federal cloud computing strategy, offers advice applicable to all organizations.

Cloud computing is gaining rapid acceptance, but not everywhere. Governments across Europe – in what many call “the old countries” –  are still remarkably conservative or even reluctant to embrace cloud computing.
 

This week President Obama organized a dinner with the CEO’s of 12 high-tech and cloud companies to stimulate job creation in North America, meanwhile – over in Europe – the Dutch Minister of the Interior replied to questions of parliament about the use of cloud computing by governments.The fact that this particular minister had to be invited three times by Dutch Employers Association to switch from his pre-war model cast iron bike to a more modern bicycle with gears and suspension, says something about the tone of this debate.

A hilarious misunderstanding was that the official government delegation kept referring to cloud computing as a new invention, while the representatives of the industry (including Google and a large international accounting firm) tried to explain that cloud computing was an established practice with many real life use cases and success stories, both inside and outside government organizations.

Remarkably the US and this European government announced almost at the same time a plan to radically reduce the number of government data centers:  by about 60 in the Netherlands, and by about 800 in the U.S. The underlying idea in the U.S. is to make greater use of “data centers as a service” a.k.a. cloud computing. On the other hand, the Dutch plan so far sounds more like a traditional consolidation approach with the objective of creating more efficiency by increasing the scale of use (an approach that has so far not proven to be very successful; in fact, we see globally that the bigger the scale of the projects, the more spectacular the reports in the public press about the outcomes).

In the meantime, the CIO of the U.S. Federal government, Vivik Kundra, published a very readable cloud strategy – at only 43 pages this is a must read for anyone involved in setting IT strategy (a shorter analysis can be found at sys-con). Kundra presented his strategy not as a way to save on IT costs, but as a way to get more value from existing IT investments. In many places, but certainly in the public sector, “protection of budgets” has become a primary survival strategy. By positioning cloud computing not as a way to cut cost but as a way to increase value he makes  IT (and of the whole civil apparatus) an ally to his plans, instead of a potential opponent.

The technology industry likely was already on his side, because the government’s ‘promised’ cloud spending in cloud services is likely to amount to about $20 billion per year, or 25% of the total budget. This annual amount is approximately equal to the total government investment required to put a man on the Moon. In my view, the U.S. government’s cloud program is also a way to create and safeguard jobs for the coming decade – in a sense, an industry stimulus program.

Due to European free trade rules and regulations, creating stimulus packages for national industries in Europe is at best complicated, and in many cases even illegal. Within the European Union, Neelie Kroes – the former free trade commissioner – has taken on the role of Commissioner for the Digital Agenda.  In a recent lecture, she indicated her ambition is to make Europe not only “Cloud-Friendly” but “Cloud-Active” (a kind of “all-in” strategy?). The plan is built around three core areas: 1) a legal framework, 2) technical and commercial fundamentals) and 3) the market. There are now more than 100 actions on her European Digital Agenda, of which more than 20 specifically addressing the European “Digital Single Market”, an online equivalent of the European single market for goods and services.

However, a fundamental problem for cloud computing in Europe is that the European Union was based on enabling free traffic of persons, goods and services, and NOT free traffic of DATA. This puts European providers of cloud services immediately at a disadvantage. American, but also Chinese, companies have a huge domestic market, which they can serve from one geographic location. Europe has, in theory, a similar large domestic market for cloud services, but the various European languages, cultures and laws make this market a lot less uniform than the American market. Some argue that this diversity has made European suppliers (or European divisions of global providers) better at providing a differentiated approach, instead of the more traditional “one size fits all” solutions. But in a fast growing new market like cloud computing, all this diversity does makes achieving the required scale more difficult.

And in addition to issues with European privacy laws as described in this NY Times article,
there are a variety of local and national laws preventing local suppliers from serving the European (government) market from one location, even if this location lies within the European Union. For example, the German Government requires that all data of local government agencies is kept within Germany. From a historical perspective this may be understandable, but it prevents the European government sector from becoming a launching force for “One European Cloud Market.”

Maybe it’s time for a European cloud of two speeds? Just like we saw smaller groups of countries signing the Schengen treaty (which enabled traveling between selected European countries without checkpoints) or for the introduction of the Euro single currency, a small leading group of countries could opt for accelerated introduction of uniform cloud legislation.

Comments: Please leave them below or send a message to @ gregor petri on Twitter

PS for some links to the European local language sites we used automatic web translation facilities from Microsoft and Google. Thought that with #IBMwatson defeating the human trace at Jeopardy the time might be right for this. Let me know whether you felt these were useful or not.