Cloud Wars: Friendly Fire – Part 1

October 27, 2011 by Pat O'Day

The Cloud Wars have already begun and as in all conflicts, the most unfortunate incidents are caused by friendly fire. From a cloud computing perspective, it occurs most often when people who want to try or have tried public or hybrid cloud are challenged by peers or counterparts in their own companies. 

I’ve been thinking a lot about the challenges my fellow technologists have experienced in trying to sell their public, private or hybrid cloud initiative inside an organization. I also realized that not only was this a difficult task for them during their initial project, but that they are compelled to continue to justify their cloud initiatives on an ongoing basis. I know that in most situations the team that needed to be convinced of moving forward with a cloud project was corporate IT. In some cases the "cloud champions" were trying to convince the CIO to try something new. In some cases a cloud committee or cloud strategy working group was already working on it and the project was a distraction to their process, or it ended up under a microscope as a learning opportunity instead of the business critical application that it was for the department. In other cases it was actually IT leadership trying to encourage their teams that the old world might be changing, just a little bit, but the going was pretty slow because no one was really sure what that meant.

In each case a lot of the core challenges were similar but there were also some differences.

Most of my fellow technologists were headed to or ended up in the cloud in the first place because they needed or place a high value on agility. I define agility as being able to:cloud

  • Act quickly
  • Deal with the unknown
  • Change your mind

And they generally felt like going outside of core IT made the most sense because:

  • Cloud was less expensive because you only pay for what you use
  • They perceived the service was better
  • The response to issues would be faster
  • Promises about service delivery and uptime were written with financial penalties for under-performance, typically in a Service Level Agreement (SLA ) document
  • They or their team members could provision resources rapidly, and via self service
  • There was transparency and true visibility on the cost of IT
  • As a cloud customer, they were a priority and could vote with their dollars
  • They felt wanted because multiple vendors were competing for their business
  • It was a more cost effective and lower risk way to try newer technology or new idea

And though those things made a lot of sense, when they exposed their plans to the internal team or in some cases, when the internal team found out they were already using the cloud, the reaction was generally:


  • We have capacity internally already, why can't you use that?
  • Buy some servers and a SAN, we'll manage it for you.
  • Cloud is more expensive.
  • We do understand service, we can act fast, just submit a ticket.
  • Our standard cloud offering is [fill in cloud vendor here], use them.
  • Can you wait six months? We are implementing a private cloud.
  • Security, security, security!
  • They were in a busy with a big company-wide project and were unavailable for the meeting.


Those questions and challenges are legitimate and can be quite difficult hurdles to navigate especially if you are trying public cloud for the first time.

In my next post I’ll share some cloud adoption challenges in more detail as well as ways that I’ve seen people overcome them.