Clouds in the Open: The Operations Evolution of Open Source & Public Clouds

May 28 2013   1:51PM GMT

Cloud Washing Back Lash

Aaron Delp Aaron Delp Profile: Aaron Delp

I noticed a pretty interesting trend while I was at Citrix Synergy last week meeting with customers, specifically Enterprise customers.  This trend continues a pattern I have been seeing for some time in the Enterprise: Sometimes you can’t call Cloud a Cloud.  Many customers want (I would even say NEED) all the operational advantages of cloud computing but they don’t want “Cloud Computing”.

Most Enterprise customers are looking for the advantages of cloud computing but don’t want a product labeled cloud computing.  Think of it as “cloud washing back lash”.  Most customers will adopt cloud computing over time based on what is most painful to the organization and address one or more cloud computing characteristics they would like to adopt.  

Let me elaborate with a simplified theoretical customer conversation that followed the pattern of many I had last week.


Me: “Are you interested in cloud computing for your organization or your customer?”

Them: “No.  I have a cloud project my CIO is forcing me to look at but I don’t have time for it.”

Me: “What are some of the challenges you are facing in your organization today?”

Them: “You name it, tight budgets, overworked staff, under staffed, too many projects, too much overhead on existing operations.  I have to do more with the same or less. I don’t have time or resources to take on a cloud computing project.”

Me: “Do you have a challenge building/provisioning new resources today?  Do you have challenges around your daily operations and support?  Are your customers (internal or external) happy today?”

Them: “Yes. Yes. No.”

Me: “These are all basic characteristics of cloud computing. Let’s take the word cloud out of the conversation for a moment and just talk about your operational issues.  Want to hear a little more about how we could help your existing operations”

Them: “Absolutely. I thought cloud was this new “thing” that would require me to replace everything. Let’s talk…”

I personally turned more Enterprise customers around this week than I could count.  I did it by not calling it cloud computing but calling out the operational benefits of cloud computing.  There is an episode of Engineers Unplugged that will see the light of day in the near future that I recorded with Giles over at Shape Blue that expands on this concept further.  To me cloud computing isn’t about a rip and replace of infrastructure and products as much as it is a long-term operations goal that must be managed over time.  It is about increasing IT operations efficiency through offering services instead of products to your users/customers.

There will be those clouderati type folks that will pooh pooh what I’m saying.  They will say you need to rip and replace everything, change your entire infrastructure (commodity hardware, SDN, object storage) and your entire operations (fire all the operations folks, they stink) and replace everything with go fast DevOps and every day you don’t do it is a day your competitors are gaining ground.  That simply isn’t a realistic scenario for 99% of customers today.  The legacy infrastructure has to continue to operate but should be replaced over time at a pace that fits the needs of the business.  This isn’t a rip and replace (build big walls around the old) as much as it is a “starve the old gradually, build the new over time as needed” mentality.

Enterprises in most cases aren’t looking for a shocking dramatic shift that happens overnight, even if the most of the vendors and service providers out there want this to happen.  Customers are looking to ease into cloud computing over time and the best way to this is to treat cloud computing as a long term goal and address what is most important to the Enterprise instead of telling them they are doing it wrong.

It’s technical sales 101, find a problem, fix a problem, don’t get in the customers face (they are the customer after all and are writing the check).  Don’t call it a cloud.

3  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • Mark Szynaka
    I could not agree more there is an entrenched resistance from within the Enterprise to "move" to the cloud or even to create a private cloud.  The word cloud evokes visions of outsourcing and I suppose it suffers from overuse.  They want an evolutionary change not revolutionary change and they definitely don't want a forklift upgrade.  If coating the benefits with a little sugar helps the paradigm shift go down by calling it maybe Service Oriented Architecture improvements than so be it.The smart IT managers will adopt a shift in the delivery of services regardless of what it is called.
    65 pointsBadges:
  • Aaron Delp
    Mark - Thanks for your comment!
    20 pointsBadges:
  • TomLiotta
    One source of resistance is the failures of technologies of the past. Finding ways to pull value from past failures might lead to ways of soothing some resistance.   There is a gradient to the experience of IT personnel that generally correlates with resistance to new technologies. It's not perfect, yet it's noticeable. A longer tenure can breed more resistance. With some 40+ years of experience behind me, I have felt resistance in myself for numerous IT advances.   Much of it arises out of the uncountable "advances" from the past that were often the-next-big-thing yet went nowhere. I have no doubt that one or more forms of 'cloud' are inevitable, so 'cloud' is not something I personally feel resistance against. Still, I can certainly sympathize with resisters. I've felt like time was wasted on multiple technology implementations in the past, so I can understand resistance.   The issue, then, would be in how to assure resisters that investigating and implementing a specific cloud solution is worth the effort. If I throw myself into such a project, what is the benefit to me if it flames out? Easy to answer is the benefit if it succeeds. Assurance of benefit if the project dies is much harder.   I'm reasonably successful writing sockets applications for TCP/IP, but it'd be nice if everything I know about SNA and APPC/APPN could have been skipped. I can do a lot of successful troubleshooting in Ethernet networks, but some of the diagnostic tools I wrote for myself for token-ring took a big chunk of my time that can't be recovered. Some 20+ years ago, another developer and I learned Forth for a decently sophisticated app for hand-held units that I'm pretty sure have long been discarded. And I've never needed Forth since then.   Yet, I recognize that none of it was truly wasted. An understanding of APPN Network Nodes gave an early step to start grasping DNS. Building functions out of Forth primitives gave something to compare against objects and inheritance. Many lost or fading technologies contain seeds or concepts that transfer to emerging ones.   Finding ways to instill interest in the face of failure will go a long way towards reducing some of the resistance. This kind of resistance will be strongest in those with the longest time in the field, and they will tend to be decision makers.   Tom
    125,585 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: