CA Community






July 2010 - Posts

On Cloud Lock-in, Standards, Decoupling and why SaaS does not scale.

Published: July 27 2010, 08:55 AM | no comments
by CA Community

With security and legal concerns being slowly addressed by the industry, lock-in and standards are rapidly becoming the biggest concerns regarding cloud computing. If the cloud industry is to make good on its promise, these will need to somehow be addressed. Let's examine some recent developments.

This post originally appeared on July 27 at ITSMportal.com

Interesting to see how, just a week after my blog on "The Principles and Perils of Vendor Lock-in" *1 several vendors made announcements seemingly supporting my suggested approach.  For example, after hinting at the potential benefit of decoupling SaaS and PaaS from its underlying Infrastructure (IaaS) layers, Microsoft announced it is making Azure available as a PaaS platform to several large IaaS providers *2. Now I am sure this had nothing to do with my blog on preventing lock-in and all to do with a desire in Redmond to increase market share for their PaaS platform, which ironically - if too successful - may even increase lock-in. But the move will offer customers who select Microsoft's PaaS platform a choice of vendors for the underlying Infrastructure services (IaaS).  

At the same time NASA and Rackspace announced they are joining forces around an open source platform for Private Clouds called OpenStack *3. Rackspace's initiative is no doubt as commercially motivated as Microsoft's. If Rackspace -in my view correctly - expects that many private clouds in the foreseeable future will start to source additional capacity (cloud burst) from public clouds, then having these private clouds be based on the same architecture as their public cloud offering will help Rackspace. NASA's motives stem from the US government's cloud stimulus approach*4 , a specific stated goal of which is "to accelerate the creation of cloud standards".  If history is to repeat itself, we can expect to first see industry standards lead to a "plug-compatible" cloud market", before a serious "open standards" cloud market will take shape. As NASA is determined to have workable cloud standards a lot faster than the decade or so it took to get a man on the moon, it is understandable they see the Rackspace route as a viable shortcut. This is also understandable because agreeing on open cloud standards today would be as difficult as agreeing 3D TV standards back in the days of the black & white moon landing broadcasts. (And, reader beware: if there ever was a time to keep options open and not lock yourself into what looks to become an early standard , it would be today).

A decoupled cloud

For many readers, my recommendation to prevent lock-in by decoupling the choice of application (SaaS) and platform (PaaS) vendors from the underlying choices of infrastructure (IaaS) vendors was pure heresy. Their logic was this: if you want control over underlying layers you should not embark on cloud computing because the whole idea of cloud computing is that someone else is responsible for the underlying layers. But that's like saying that if you don't want to buy clothes that were made by under-aged children, you should get a sewing machine and make your own clothes.

Others struggled with imagining what such a decoupled cloud would look like in practice. Luckily, also last week (it was indeed an eventful week for cloud computing) a first real live example of such a decoupled offering went live. Skygone Inc.  announced they were offering a choice of GIS (Geographical Information System) services *5 by aggregating solutions from several GIS software vendors across a choice of infrastructure platforms and vendors. Companies in need of such geographical information - which is a complex and specialized area, beyond the expertise and interest of most internal IT departments - can now simply source this without locking themselves into a specific vendor or platform. (Disclosure: Skygone uses as underlying platform Applogic from 3Tera, now owned by my employer CA Technologies.)

Several analyst firms predicted early on that this type of "brokering of cloud services" would become an important market force. But in recent months -maybe under the influence of several self-proclaimed 100-pound gorillas entering the cloud market - the analyst community became very quiet about the concept, which is a shame because it also addresses the fact that in an enterprise context "SaaS does not scale".

SaaS does not Scale?
Now before readers get all wound up (again), with "SaaS does not Scale," I do not mean that SaaS applications cannot scale to service millions of users. They do already, although some more successful and reliable than others. I mean that the average enterprise or government organization, which typically has a portfolio of several hundreds or even thousands of applications, can simply not afford to source these from a similar number of SaaS providers. The mandatory auditing of the infrastructure and processes of all these providers would simply not be feasible, also as a leading analyst firm just pointed out that a SAS70 certificate is no replacement for such mandatory due diligence *6a. They did so at about at the same time they suggested that for many a SaaS vendor it would make sense to partner with IaaS vendors for delivery of their services *6b and that the traditional SaaS market may not grow to be as big as many initially expected *6c (shows once more that predicting developments and/or placing customer bets in a brand new area like cloud computing continues to be a risky business). 

A better way

Summarizing the described mix and match approach of a decoupled, brokered cloud aims to allow enterprises to select the applications they need from several SaaS vendors, pick the platforms they like from a choice of PaaS vendors and deploy these across their choice of selected and audited IaaS vendors, without running into lock-in or scalability issues.


Now it is important to understand that this approach does not in any way, shape or form resemble the old way IT used to work. Let's use an analogy from the consumer IT market to describe the difference:

IT, the old way: As a consumer you would go to a computer store to pick a software package, let's say a cooking application. From the 20 available offers you pick one (likely the one with the nicest picture on the box), only to arrive home and discover your PC has a release of the operating system/database/browser that is not supported. After fixing this (there goes the weekend), you still cannot get it to run. You solicit some consulting from your neighbor/nephew/colleague; while your spouse remarks that at this rate you will be eating take out for another month (no pressure!). Finally during week 3 you get it to work, although printing still has it quirks. You learned a lot more about your PC, but little about cooking. One month later you buy a new PC and strangely the whole thing stops working again. Luckily the vendor sends you an email in which they offer an upgrade that runs on your new PC. Comparing it to the cost of takeout, you decide to buy the upgrade.

IT, the new way: You feel hungry, without leaving your seat you visit the appstore on your phone, they offer 60 cooking applications, you pick the one most downloaded (after reading some of the user comments). You prepare your first dish. It is too salty. You blame the application, remove it, and pick another one. That tastes better. You decide whether you use the free version (that includes a automatically printed shopping list for the supermarket chain sponsoring the app) or you pay 20 cents per recipe cooked.

The decoupled cloud experience we are aiming for should of course feel like the second scenario. Also note how in the first example we talked mainly about technology and in the second mainly about cooking. Somehow we in IT moved from talking about what our companies do (selling soup, soap or insurance) to mainly discussing technologies (like SOA, SOAP and yes: Cloud). In other words we need to find a way to change from being mainly Supply Driven, with IT in the role of factory managers running production of services, to a Demand-Driven IT organization, with IT in the role of a supply chain manager, finding the best way to source the functionality for the business, preferably without locking our company into a dead-end street. End goal is being able to deliver the 20% that really differentiates our company, while at the same time being able to source the 80% that is pretty much the same for all companies.

That type of agility is the real promise of cloud computing.

Notes:

*1      The Principles and Perils of Vendor Lock-In

*2      Microsoft announced it is making Azure available as a PaaS platform to several large IaaS providers

*3      NASA and Rackspace announced they are joining forces around an open source platform for Private Clouds called   OpenStack

*4      The US government investments in cloud computing could be seen as a modern day industry stimulus package. In my view current efforts of NASA and the like may have as deep an impact on cloud computing as the cold war DoD budgets had on the development of computer networks and the Apollo project had on technology advancement in general.

*5      Skygone Inc.  announced offering a choice of GIS (Geographical Information System) services

*6a    SAS 70 is Not Proof of Security, Privacy, or Continuity Compliance

*6b   Public Cloud Infrastructure Helps SaaS Vendor Economics

*6c    Organizations Need to Re-Evaluate the Rationale for SaaS  

Share this post:  

 

By: CA Community
CA Community is the blog manager’s account used to post general updates and news items.
Read More..

Might the cloud prove Thomas J. Watson right after all?

Published: July 21 2010, 02:13 PM | no comments
by CA Community

In 1943 former IBM president Thomas J. Watson allegedly *1 said: "I think there is a world market for maybe five computers". Will cloud computing prove Watson to be right after all?

mage of IBM President, @1920s, from IBM Corporate Archives Paul C. Lasewicz (talk) 14:07, 7 October 2009 (UTC)

Anyone who visited a computer-, internet- or mobile-conference in recent years, is likely to have been privy to someone quoting Watson. Most often to show how predicting the future is a risky endeavor. But is it? Maybe five for the world is not so crazy after all?

Now don't get me wrong, I am not suggesting there will be less digital devices in the future. In fact there will be more than we can imagine (phones, ipads, smart cars and likely several things implanted into our bodies). But the big data crunching machines that we - and I suspect Mr. Watson - traditionally think of as computers are likely to reduce radically in numbers as a result of cloud computing. One early sign of this may be that a leading analyst firm - who makes a living out of publishing predictions - now foresees that within 2 years, one fifth of business will own no IT assets*2.

Before we move on, let's further define "computer" for this discussion. Is a rack with six blades one computer or six? I'd say it is one. Same as I feel a box (or block) hosting 30 or 30000 virtual machines, is still one computer. I would even go so far that a room with lots of boxes running lots of stuff could be seen as one computer. And let's not forget that computers in the days of Mr. Watson were as big as rooms. So basically the proposed idea is: cloud computing may lead to "a world market with maybe five datacenters". Whether these will be located at the bottom of the ocean (think we have about 5 of those*5), distributed into outer space to solve the cooling problem or located on top of nuclear plants to solve the power problem, I leave to the hardware engineers (typical implementation details).

Having five parties hosting datacenters (a.k.a. computers) to serve the world, how realistic is this? Not today, but in the long run, let's say for our children's children. It seems to be at odds with the idea of grids and the use all this computing power doing little or nothing in all these distributed devices (phones, ipads). But does that matter. Current statistics already show that a processor in a datacenter with 100.000 CPU's is way cheaper to run than that same processor in a datacenter with 1000 CPUs. But if we take this "bigger is better" (Ough this hurts, at heart I am a Schumacher "small is beautiful" *6 fan) and apply it to other industries, companies would logically try and have one factory. So Toyota would have one car factory and Intel one chip factory. Fact is they don't , at least not today. Factors like transport cost and logistical complexity prevent this. Not to mention that nobody would wont to work there or even live near theseand that China may be the only country big enough to host these factories (uhm, guess China may be already trying this?).

But with IT we theoretically can reduce transport latency to light speed and logistical complexity in a digital setting is a very different problem. Sure managing 6000 or 600.000 different virtual machines needs some thought (well maybe a lot of thought), but it does not have the physical limitations of trying to cram 60 different car models, makes and colors through one assembly line. If instead of manufacturing we look at electricity as a role model for IT - as suggested by Nicholas Carr - then the answer might be something like ten plants per state/country (but reducing). Now we need to acknowledge that electricity suffers from the same annoying physical transport limitations as manufacturing. It does not travel well.

So guess my question is: What is the optimal number?

How many datacenters will our children's children need when this cloud thing really starts to fly.

  • A. 5 (roughly one per continent/ocean)
  • B. .5K (roughly the number of Nuclear power plants (439) *3
  • C. 5K (roughly 25 per country)
  • D. .5M (roughly/allegedly the current number of Google servers) *4
  • E. 5M (roughly the current number of air-conditioned basements?)
  • F. 5G (roughly the range of IP4 (4.2B))

Please post you thoughts / votes / comments below

*1 Note: Although the statement is quoted extensively around the world, there is little evidence Mr Watson ever made it http://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_misquote  /Picture is from wikipedia.org
*2 http://www.gartner.com/it/page.jsp?id=1278413  
*3 http://www.icjt.org/an/tech/jesvet/jesvet.htm
*4
http://www.datacenterknowledge.com/archives/2009/05/14/whos-got-the-most-web-servers/  
*5 http://geography.about.com/library/faq/blqzoceans.htm
*6 http://en.wikipedia.org/wiki/Small_Is_Beautiful   

 

Share this post:  

 

By: CA Community
CA Community is the blog manager’s account used to post general updates and news items.
Read More..

The concept of vendor lock-in and how it relates to cloud computing

Published: July 14 2010, 11:06 AM | no comments
by CA Community

This blog originally was published at ITSMportal.com on July 14st , 2010   

IT vendor lock-in is as old as the IT industry itself. Some may even argue that lock-in is unavoidable when using any IT solution, regardless of whether we use it "on premise" or "as a service". To determine whether this is the case, we examine traditional lock-in and the to-be-expected impact of cloud computing.

Vendor lock-in is seen as one of the potential drawbacks of cloud computing. One of Gartner's research analysts recently published a scenario where lock-in and standards even surpass security as the biggest objection to cloud computing. Despite efforts like Open Systems and Java, we have managed to get ourselves locked-in with every technology generation so far. Will the cloud be different or is lock-in just a fact of live we need to live with? Wikipedia defines vendor lock-in as:

In economics, vendor lock-in, also known as proprietary lock-in, or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs. Lock-in costs which create barriers to market entry may result in antitrust action against a monopoly.

Let's examine what lock-in means in practical terms when using IT solutions and how cloud computing would make this worse or better. For this we look at four dimensions of lock-in:

Horizontal lock-in: This restricts the ability to replace a product with a comparable or competitive product. If I choose solution A (let's for example take a CRM solution or a development platform), then I will need to migrate my data and/or code, retrain my users and rebuild the integrations to my other solutions if I want to move to solution B. This is a bit like when I buy a Prius, I cannot drive a Volt. But it would be nice if I can use the same garage, loading cable, GPS, etc. when I switch. 

Vertical lock-in: This restricts choice in other levels of the stack and occurs if choosing solution A mandates use of database X, operating system Y, hardware vendor Z and/or implementation partner S. To prevent this type of lock-in the industry embraced the idea of open systems, where hardware, middleware and operating systems could be chosen more independently. Before this time hardware vendors often sold specific solutions (like CRM or banking) that only ran on their specific hardware / OS etc. and could only be obtained in their entirety from them. So a bit like today's (early market) SaaS offerings, where all needs to be obtained from one vendor.

Diagonal (of inclined) lock-in: This is a tendency of companies to buy as many applications as possible from one provider, even if his solutions in those areas are less desirable. Companies picked a single vendor to make management, training and especially integration easier but also to be able to demand higher discounts. A trend that let to large, powerful vendors, which caused again higher degrees of lock-in. For now we call this voluntary form of lock-in diagonal Lock-in (although "inclined"- a synonym for diagonal - may describe this better).

Generational lock-in: This last one is as inescapable as death and taxes and is an issue even if there is no desire to avoid horizontal, vertical or diagonal lock-in. No technology generation and thus no IT solution or IT platform lives forever (well, maybe with exception of the mainframe). The first three types of lock-in are not too bad if you had a good crystal ball and picked the right platforms (eg. Windows and not OS/2) and the right solution vendors (generally the ones that turned out to become the market leaders). But even such market leaders at some point reach end of life. Customers want to be able to replace them with the next generation of technology without it being prohibitively expensive or even impossible because of technical, contractual or practical lock-in.

The impact of cloud computing on lock-in
How does cloud computing, with incarnations like SaaS (software as a service), PaaS (platform as a service) and IaaS (infrastructure as a service) impact the above? In the consumer market we see people using a variety of cloud services from different vendors , for example Flickr to share pictures, Gmail to read email, Microsoft to chat, Twitter to Tweet and Facebook to ... (well, what do they do on Facebook?), all seemingly without any lock-in issues. Many of these consumer solutions now even offer integration amongst each other. Based on this one might expect that using IT solutions "as a service" in an enterprise context also leads to less lock-in. But is this the case?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Horizontal: For the average enterprise moving from one SaaS solution to another is not so different from moving from a traditional software application to another, provided they agreed whether and how their data can be transferred. What does help is that SaaS in general seems easier and faster to implement and that it is not necessary for the company to have two sets of infrastructure available when migrating.

For PaaS it is a very different situation, especially if the development language is proprietary to the PaaS platform. In that case, the lock-in is almost absolute and comparable to the lock-in companies may have experienced with proprietary 4GL platforms, with the added complexity that with PaaS also the underlying infrastructure is locked-in (see under vertical).

Horizontal lock-in for IaaS may actually be less severe than lock-in to traditional hardware vendors as virtualization - typical for any modern IaaS implementation - isolates from underlying hardware differences. Provided customers do not lock themselves in to a particular hypervisor vendor, they should be able to move their workloads relatively easy between IaaS providers (hosting companies) and/or internal infrastructure. A requirement for this is that the virtual images can be easily converted and carried across, a capability that several independent infrastructure management solutions now offer. Even better would be an ability to move full composite applications (more about this in another post).

Vertical: For SaaS and PaaS vertical lock-in is almost by definition part of the package as the underlying infrastructure comes with the service. The good news is the customer does not have to worry about these underlying layers. The bad news is that if the customer is worried about the underlying layers, there is nothing he can do. If the provider uses exotic databases, dodgy hardware or has his datacenter in less desirable countries, all the customer can do is decide not to pick that provider. He could consider contracting upfront for exceptions, but this will in almost all case will increase the cost considerably, as massive scale and standardization are essential to business model of real SaaS providers.

On the IaaS side we see less vertical lock-in, simply because we are already at a lower level, but ideally our choice of IaaS server provider should not limit our choice of IaaS network or IaaS storage provider. For storage the lesson we learned the hard way during the client server area -for enterprise applications logic and data need to be close together to get any decent performance - still applies. As a result the storage service almost always needs to be procured from the same IaaS provider as used for processing. On the network side most IaaS providers offer a choice of network providers, as they have their datacenter connected to several network providers (either at their own location or at one of the large co-locators).

Diagonal or inclined: The tendency to buy as much as possible from one vendor may be even stronger in the cloud than in traditional IT. Enterprise customers try to find as single SaaS shop for as many applications as possible. Apart from the desire for out of the box integration, an - often overlooked - reason for this is that customers need to regularly audit the delivery infrastructure and processes of their current SaaS providers, something which is simply unfeasible if they would end up having hundreds of SaaS vendors.

For similar reasons we see customers wanting to buy PaaS from their selected SaaS or IaaS vendor. As a result vendors are trying to deliver all flavors, whether they are any good in that area or not. A recent example being the statement from a senior Microsoft official that Azure and Amazon were likely to become more similar, with the first offering IaaS and the second likely to offer some form of PaaS soon.

In my personal view, it is questionable whether such vertical cloud integration should be considered desirable. The beauty of the cloud is that companies can focus on what they are good at and do that very well. For one company this may be CRM, for another it is financial management or creating development environments and for a third it may be selling books - um, strike that - hosting large infrastructures. Customers should be able to buy from the best, in each area. CFOs do not want to buy general ledgers from CRM specialists, and for sure sales people don't want it the other way around. Similar considerations apply for buying infrastructure services from a software company or software from an infrastructure hosting company. At the very least this is because developers and operators are different types of people, which no amount of "devops training " will change (at least not during this generation).

Generational: As with any new technology generation people seem to feel this may be the final one: "Once we moved everything to the cloud, we will never move again." Empirically this is very unlikely - there always is a next generation, we just don't know what it is (if we did, we would try and move to it now). The underlying thought may be: "Let the cloud vendors innovate their underlying layers, without bothering us". But vendor lock-in would be exactly what would prevent customers from reaping the benefits of clouds suppliers innovating their underlying layers. Let's face it, not all current cloud providers will be innovative market leaders in the future. If we were unlucky and picked the wrong ones, the last thing we want to be is locked-in. In today's market picking winning stocks or lotto numbers may be easier then picking winning cloud vendors (and even at stock picking we are regularly beaten by not very academically skilled monkeys).

Conclusion
My goal for this post was to try and define lock-in, understand it in a cloud context and agree that it should be avoided while we still have a chance (while 99% of all business systems are not yet running in the cloud). Large scale vertical integration is typical for immature markets - be it early-day cars or computers or now clouds. As markets mature companies specialize again on their core competencies and find their proper (and profitable) place in a larger supply chain. The lock-in table at the end, where I use the number of padlocks to indicate relative locking of traditional IT versus SaaS, PaaS and IaaS, is more meant for discussion and improvement than as an absolute statement. In fact our goal should be to reduce lock-in considerably for these new platforms. In a later post I will discuss some innovative cross cloud portability strategies to prevent lock-in when moving large numbers of solutions into the cloud, stay tuned.

PS Not that I for a minute think my blogs have any serious stopping power, but do not let the above stop you from moving suitable applications into the cloud today. It's a learning experience that we will all need as this cloud thing gets serious for serious enterprise IT (and I am absolutely sure it will, as the percentage of suitable applications is becoming larger every day). Just make sure you define an exit strategy for each first, as all the industry analysts will tell you. In fact, even for traditional IT it always was a good idea to have an exit strategy first (you did not really think these analysts came up with something new, did you?).

Share this post:  

 

By: CA Community
CA Community is the blog manager’s account used to post general updates and news items.
Read More..

Cloud Standards: Critical to an Evolving Cloud Market?

Published: July 13 2010, 01:54 PM | 2 Comment(s)
by Marvin Waschke

A little over a year ago, the DMTF (Distributed Management Task Force) created a cloud standards incubator to, wrestle with standards for the cloud environment, particularly Infrastructure as a Service (IaaS). The incubator's goal was to help create a set of standards that will provide for interoperable, portable, and consistently manageable cloud services.

This incubator published a white paper in November 2009 entitled Interoperable Clouds on high-level architecture and use cases for IaaS consumer-provider interaction. The DMTF cloud DMTF - Cloud Computing Incubator then handed the baton to the DMTF Cloud Management Working Group.  The job of the incubator was to determine the feasibility of standards. Establishment of a working group represents a consensus that standards are feasible and in the interest of the DMTF membership. The working group is chartered to build upon the work of the incubator, other DMTF and non-DMTF standards, and other groups such as the Cloud Security Alliance (CSA) and the TeleManagement Forum. The incubator focused on describing standard management scenarios. The work group is expected to be prescriptive and formulate rules a compliant installation must follow.

Anyone who has used public IaaS services will not be surprised by the recommendations of the incubator. The incubator recommended a standard management model based on a service catalog, service offerings, service templates, service requests, and service instances as major abstractions. In the incubator's use cases, consumers select service offerings from the catalog. A service offering is comprised of one or more service templates that specify the hardware, software, storage, and network characteristics of the offering. In addition to templates, the offering may also contain service level agreements, contracts and other aspects of the business relationship between consumer and provider.

The service request represents a request from a consumer to a provider for an offering configured in a certain way. After a request is accepted by the consumer and provider, a service instance is created, which corresponds to the service represented by the accepted request. Actual deployment and activation of the instance may occur any time after the request is instantiated.

Cloud services currently available-include Amazon EC2, Microsoft Azure, and SalesForce.com-which, respectively, represent IaaS, Platform as a Service (PaaS), and Software as a Service (SaaS).  SaaS is currently the most type of cloud service. In part, this is because the standards it relies on-- HTTP, HTML, XML, TCP/IP, etc. -- are intrinsic to the Internet itself.  SaaS products are attractive because the consumer only needs a standard browser and a network connection. The SaaS provider takes care of all the administration and setup that makes traditional on-premises applications so expensive to own.

IaaS and PaaS, on the other hand are a bit different. Let's consider IaaS. If you need a bunch of servers provisioned with classic LAMP stacks (Linux operating system, Apache HTTP server, MySQL database, and Perl or PhP), an IaaS offering like EC2 can have you up and running in minutes. Plus, if you use a metered service that charges only for the computing capacity use actually use, you can get a great deal (less than ten cents an hour for a basic Linux server).

For the time being, IaaS is being used primarily in limited situations-such as temporary development, testing, and demonstration needs-rather than for more mission critical applications like ERP that have substantial security and compliance requirements.

As IaaS providers begin prove their worth and security and compliance issues are ironed out, purchases of, on-premises hardware will likely decline and IaaS providers will begin to compete against each other for customers.  Hardware vendors may get into this business themselves. Telcos may, too. So every time a customer has a new infrastructure need, or a contract expires, a crowd of IaaS vendors will be eager to compete   

In other words, consumers will want to be able to shop for the best deal switch IaaS providers in much the same way as we compare and switch cell phone providers today.

But to achieve this fluidity, there must be a more standardized interface between the cloud provider and the cloud consumer. A service deployed with one IaaS provider must be specified in a way that allows an equivalent service to be quickly deployed by a competing provider.

As IaaS offerings become more complex, the demands on this specification standard will become more complex. In addition to describing the service, specifications for control utilities such as starting and stopping the service must also become sufficiently standardized to allow a transparent switch from one provider to another without writing new control scripts or retraining personnel. 

The same holds true for other service attributes such as security, compliance, and reliability.  

These are just a few of the considerations that make it clear how important standards will be to the future of cloud computing.  We are still early in the development of this market, so the next few years should be quite interesting.  One thing is for certain, though: our industry continues to evolve in ways that enable customers to get more business value for every dollar they spend on technology-and that force vendors to continuously and even disruptively innovate.

 

Share this post:  

 

By: Marvin Waschke
Marv Waschke is a senior principal architect at CA Technologies. He has represented CA Technologies in several standards groups including the Cloud Management Working Group and Configuration Management Database Federation working groups of the Distributed Management Task Force (DMTF). He is also a member...
Read More..

Best lessons about Cloud Computing 101 are actually for the one teaching the class

Published: July 01 2010, 03:01 PM | 3 Comment(s)
by Jay Fry

I've noticed that I have a tendency to get a bit impatient with the pace of cloud computing adoption.

Sure, there are lots of examples of leading-edge companies that are dabbling with it. And, I know some big ones that are making notable strides as well. And folks like Werner Vogels are talking about the great progress that's been made (see his Structure 2010 conference keynote summary here).

But I keep forgetting that things generally don't happen quickly in IT. Even revolutionary things. Or maybe the correct way to phrase that is *especially* revolutionary things.

When I signed on as the instructor for the Cloud Computing 101 session at the recent CA World conference, I didn't realize how clear this would become. In fact, my first worry was how to navigate the definitional debates that rage in the industry (often in 140 character bursts) and get to some of the more advanced topics during the session.

How do you start talking about cloud computing? Humbling lessons for the "experts"

But, as I started to think about my audience a bit more, I realized skipping the basics would be a big mistake. In fact, I learned some pretty instructive lessons myself simply from leading the Cloud 101 session, lessons that I think most of us involved in cloud computing would do well to remember.

Those of us immersed in discussing the possibilities and realities of cloud computing in the industry (check out http://twitter.com/clouderati/all for a good start at that list) have a tendency to listen intently to the others doing much the same thing. Some people call it the vendor "echo chamber" - picture this one filled with clouds, of course.

The problem, though, is not with all the talking about cloud computing. The issue is with the listening. Or rather, with *not* listening. If there's one thing that a room full of customers trying to learn the basics about cloud computing will teach you, it's to worry less about you think you want to say and instead listen to what they're asking.

Here are a few humbling lessons I learned along the way while presenting Cloud 101. They seem pretty basic, but that's my point:

Lesson #1: Don't leave out the definition or fail to explain your terms. Without it customers will be lost. But explain where to go from there.

We amuse ourselves with jokes about how passé it is to define cloud computing. We all know that the industry debate about the definition of cloud computing has been overly convoluted and filled with bluster. In fact, this bluster is what makes things like this old James Urquhart joke funny: "Question: How many cloud experts does it take to change a lightbulb? Answer: Define 'lightbulb'."

I've even made a bit of fun of the definitional talk myself last year when I was asked to write a "what is cloud computing?" article for a local New York pub.

But, in fact, definitions and starting points are useful. James Staten of Forrester recently posted a very good article called "Could Cloud Computing Get Any More Confusing?" doing exactly this - providing basic definitions -- years after he published his first research on the topic. In my Cloud 101 session, I tried to do the same. Why? Let's just say that during the part of my presentation where I covered the basic definition (I used the NIST definition), for example, I had people taking pictures of the screen. The basics are important. So, I guess: mission accomplished.

A key point I emphasized throughout, though, is that a basic definition should be a starting point for your organization's discussion of cloud computing, not something to be slavishly followed or picked apart under an electron microscope. Your definition needs to have some key basics, and then be the thing that you need it to be in the real world (here's a pointer to a back & forth I had with Lee Gomes of Forbes on this same topic a few months back).

Lesson #2: Arguments that you think have been debated and put to bed are only now being considered by those just getting started.

My session also reminded me that just because you, Mr. Presenter Guy, are tired of a given line of discussion (like, say, on whether or not private clouds are really clouds or are simply "false clouds"), doesn't mean you should ignore it. Instead, take the time to lead people through the debate, talking about both sides, letting them benefit from the experience of hearing from someone who has thought about this quite a lot. But, in the end, let them make up their own minds.

Lesson #3: Use real-world examples. Even if they seem basic - or if you've heard them many, many times before

On advice from a Carl Brooks tweet (@eekygeeky, editor at SearchCloudComputing), I made sure to include particular customer examples from across the industry to illustrate the different things cloud computing can mean and do. Those real-world examples from organizations like Intuit, Raymond James, Eli Lily, the New York Times, and the U.S. government (Congressional hearings notwithstanding) are few and far between - and often over-used. But that's OK. Sure, we need many more of them. But they bring this highly conceptual stuff home.

You want proof that customers are interested in these stories? The session by CA's Sudhrity Mondal called "The Process and Pitfalls of Moving to the Cloud: Lessons Learned from Actual Cloud Implementations" had 25 people attending -- in the last CA World time slot, on the last day. That's saying something.

Lesson #4: If you have first-hand experiences yourself, talk about them.

Not everything, though, starts from ground zero. Once you've laid the ground work about the basics, make use of your real-world experience, especially when it's something counterintuitive or unexpected.

One of the things I made sure to bring up was something that those getting started often miss: IT culture is often one of the biggest (if not *the* biggest) stumbling blocks. Not technology. Politics, organizational issues, and existing processes are all disrupted by cloud computing. That's something that organizations need to plan for, but that often gets overlooked. Better to know that up front, I say. (As does former Cassatt compatriot Ken Oestreich, now at Egenera, in a recent blog.)

Lesson #5: When speaking about cloud, start at the beginning - exactly where customers are starting. And don't forget to listen.

I had a whole bunch of material in my presentation about advanced, "trending" topics that I figured we'd get to once we sprinted through the basics. It didn't happen. Yes, folks will want to know about legal issues, the concept of devops, hybrid clouds, and where we are with standards. But cloud computing is a big enough topic that you can't get through it all in a single one-hour session.

Start at the beginning. And go slowly enough to enable yourself to listen. I had session attendees chime in with thoughts on the topic throughout the session. They expressed concern about losing control if they used public clouds. They asked if cloud computing wasn't simply virtualization. Both were great topics to cover, and are very straightforward issues that everyone has to deal with as they start. Thankfully the audience didn't let me skip right over them.

Lesson #6: There's too much info to cover all at once, so point out where else to go.

At some point in every cloud computing overview presentation (or is it just me?), the audience gets that worried, glassy-eyed look. They start to think through all the implications of what the cloud can help with, all the new issues it brings up, and begin getting a little concerned. And they wonder how to throw themselves into researching the issues that just popped into their heads. I used this as a great opportunity to pitch blogs and other resources that may not be as well known as they should be.

In my Cloud 101 presentation, I mentioned blogs from folks like Joe Weinman, Christofer Hoff, Laurie MacVittie, Bernard Golden, James Urquhart, and others (many of which are in my blogroll here). I mentioned the cloud computing customer write-ups being done by Gartner's Tom Bittman and others. I pointed out events like Structure, Cloud Connect, and even Cloud Camps. And, yes, I even mentioned Cloud Commons and this blog. The goal is to help others get up-to-speed faster by pointing them to sources that the rest of us have had to discover on our own over the course of several years.

Lesson #7: If you have an opinion, share it as such. Give practical, useful advice. Give them something they can use as soon as the session ends

I could have put up lots of detailed maturity models, complex and convoluted explanations of what to do, etc., but I think that's a mistake. Instead, start folks with a snapshot of how to get started: some on-ramps to try or places in their org where they might be able to get their feet wet.

So at what stage of cloud computing adoption were the people in my session?

No doubt the CA audience isn't the most advanced or cutting edge. Evidence of that: Cloud 101 had the biggest pre-registration (70) of any of the cloud and SaaS track's sessions at CA World.

I polled the room and the vast majority of folks hadn't yet started with any sort of cloud computing work. Instead, they were in the early investigation stage. Given the Cloud 101 topic, you might wonder why all this surprised me. But I guess this underscores my point: it's easy to forget that starting with the basics means, well, starting with the basics. Remember, I had people taking pictures of my slides (and they were no work of art, I confess - one of my evaluations was pretty clearly not complimentary about the slides themselves).

Was I successful?

So, people are hungry for basic cloud computing information. And those of us working in the space should try hard to make sure they can get it. And to portray what's going on with cloud computing in a realistic, hype-free way.

Did I manage to do so? I think so. Sure, I spotted someone snoozing in the back at one point, but, hey, no one's perfect. An encouraging sign, though, was the answer I got to one of my last questions: when I asked if people thought cloud computing was a fad, they said no. It wasn't something they'd necessarily be going whole-hog on in the next 30 days, but it was something they believed was here to stay.

Which means I bet I get to give this Cloud 101 presentation again sometime.

If you have similar experiences - or even markedly different feedback -- I'd love to hear it. Post a comment or drop me a line in e-mail or on Twitter.

Also, if you're interested in my Cloud 101 slides, you can e-mail me at jay.fry@ca.com. They will be available on the CA site, but aren't up there yet for some reason or another (like, maybe, I turned them in a bit, well, late).

This article is cross-posted at my Data Center Dialog blog.

Share this post:  

 

By: Jay Fry
Jay Fry is vice president of marketing, Cloud Computing, at CA Technologies. He has over 20 years of experience in marketing and management for innovative enterprise software companies. Prior to CA, Jay was vice president of marketing at cloud computing start-up Cassatt and founded the marketing department...
Read More..

More Posts