IT Staff Fearful Of Cloud? Try Cloud Whispering

20 Great Ideas To Steal In 2015

Last week at Interop and Cloud Connect, I shared a bit about how my staff and I have worked through some very natural fears about our organization expanding the production use of cloud computing. The bottom line: It's all about communication, mutual flexibility, managing the real operating risks, dispelling irrational fears, and providing a career path forward.

As with many IT and leadership topics, the "how" matters just as much as the "what." The "how" we did it is what I focused on in my Cloud Connect slide deck, and what I explore here.

Consider Point Of View

Business leaders see the cloud in very different ways from IT workers. Business leaders see improved speed to market; the ability to rent instead of own, especially as things relate to new ventures that might not be permanent; and the ability to rent infrequently used assets (like those for disaster recovery). And, of course, business leaders read those annoying tech-light biz strategy magazines like all executives do, and they may have an overly inflated sense of what cloud computing can do for their organizations.

Hey, as long as we're enumerating what execs are thinking, we might as well be complete.

[ For more on cloud, read The Weather Company: Cloud Journey Requires Cultural Change. ]

IT pros tend to fall into two different camps. There are those that see the value of public cloud -- think of developers who don't have to wait for weeks to create a new app, or those that don't have to wait for weeks to scale their apps. And then there are those who fear that Death has arrived, and that he rides a pale and cloudy horse.

Why the fear? There are three primary reasons:

There's definitely what I think of as functional fear, and that's primarily what we saw at our organization. That expresses itself in hallway conversations or private, closed-door sessions where a staffer or manager unburdens. The trouble with functional fear is having team members scared to death to make mistakes. Forcing them into a situation they're afraid of creates a recipe for trouble. I'll share one of those key conversations in a moment.

But there's also dysfunctional fear, which expresses itself in two primary ways -- cloudwashing and sabotage. Cloudwashing is the dubious ability to convince management that because you're running a boatload of virtualization, that you're "doing cloud." That may work today, but it won't work in the long run, especially as more tech-savvy executives enter the workforce, and especially as the benefit of hybrid and public clouds becomes more obvious. My prediction is that over time, only the very largest companies (think Fortune 100) will solely utilize their own gear in a "private cloud." The rest of us will be using public cloud infrastructure and software.

News flash: If your app can run on a true private cloud stack -- like Cloudstack, Openstack, or in privately owned containers -- it will also run in the public cloud. And the economics and security of large-scale providers are already impossible for any but the very largest of organizations to meet or beat.

Sabotage? Let's also get to that in a moment.

Let The Cloud Whispering Begin

My team and I have been students of cloud for a long time. I'm still a student, just a far less ignorant one than I was in the mid- and late 2000s. But sometime in late 2010, when some colleagues and I started to think about production, it became apparent that there truly was a lot of fear, although of the functional variety.

That led to these three practices of the cloud whisperer:

1. Peer validation

It's really hard to be surrounded by a peer group that you respect and to ignore what they're saying. We're not wired that way. That's why teen peer pressure is so insidious.

To that end, in 2011 my IT organization launched our first mini conference, the unimaginatively yet effectively titled "Cloud Day 2011." We invited public thinkers about the cloud to explain to folks what cloud was and what it could do. But more importantly, we also invited technology practitioners who were using cloud infrastructure in production to strut their stuff. We even did a live contest -- a server-provisioning race between two pros, one provisioning a server in a virtual environment, one in the public cloud. Cloud easily won.

As much as anything, this type of peer validation is a marketing activity. Marketing is not a dirty word. IT folks are very familiar with marketing when they're the ones doing the convincing -- they call it "change management." This is no different. Change management is the practice of sharing information and engaging in dialog in order to bring a team to a better, ultimately more effective place. Some folks call this marketing.

It offered a good beginning.

2. Find the easy button

I asked the audience how many people use Amazon's site to buy books versus Barnes and Noble's. Of course, most folks said Amazon; it's a ridiculously easy site to use. Too easy, my spouse says. In the jargon of marketers, the site has extraordinarily low friction -- that is, very few barriers to use.

Similarly, put some effort into selecting cloud tools that are easy to use, recognizing that the definition of easy depends on your audience.

If folks are Windows administrators, they're probably used to a user friendly GUI and not a lot of mucking about with the command line. Command line folks also have their preferences; learn what those preferences are (Ruby-like syntax? SSH?) and make them a factor in product selection.

Point being that there is no beauty in complexity. One example: While the disaster recovery system that we use from CloudVelox has parts of the setup that are necessarily complex, when it's time to failover, you really do just hit a big red easy button on a Web console. (With our DR configuration, auto-failover wasn't desirable because a network interruption could cause a big problem with apps that aren't capable of resolving high availability "split brain" syndrome.)

3. Compare security capabilities, then apply common sense

When I first had discussions with infrastructure staff about using public infrastructure, their reaction was vigorous: Jonathan, you have to understand, we don't control that firewall, anything could happen. Why would you want to expose our servers to all the nastiness that is the public Internet? Since then, I've heard this concern echoed at other organizations that I've visited or where I've helped out.

You must separate fear from fact. And to do this, you must be very implementation specific. We contemplated using Amazon Web Services infrastructure-as-a-service at the time. Would our servers, in fact, be exploit cannon fodder in the ever-escalating Battle of the Bugs? Well, actually, there were and are granular firewall controls on AWS that our staff could use to prevent such things. And why would a firewall that you control, even if it resides somewhere else, make you crazy? In fact, most if not all enterprise IT staffs have multiple firewalls in multiple locations, not all of which are owned by the company. Point of fact: You, not Amazon, are in control of and are responsible for your own security, particularly on the app side.

And Amazon is likely quite a lot better at security than you are. Bruce Schneier said to me once that rich people don't have their own exclusive, private doctors because doctors need lots and varied clinical experience to be top in their fields. Amen to that, rich, poor, or somewhere in the middle. When I look for a surgeon, I look for someone who has done a lot of surgeries and who has very few bad outcomes.

Amazon, Google, and the other big providers do quite a lot of "surgeries" -- aka incident prevention and response -- every day.

But as I said, forcing the issue in the face of fear doesn't yield desirable results. The key conversation that I had with staff was one where I yielded some measure of control.

A staffer came to see me, very concerned that we would even contemplate using infrastructure outside of our physical span of control.

I proposed the following bargain: Let's do a pilot with low-risk systems and get a vigorous audit of those systems. Infrastructure staff would totally be in control of the audit. If the setup failed, we would back off of this initiative and say no more about it. But if the setup survived a third-party audit, using an auditor selected by the infrastructure team, we would move forward.

We struck that bargain, and to make a long story shorter, we moved forward with our successful cloud project. Would we have been as successful if we had forced forward without truly mitigating the fear? I doubt it.

[Did you miss any of the InformationWeek Conference in Las Vegas last month? Don't worry: We have you covered. Check out what our speakers had to say and see tweets from the show. Let's keep the conversation going.]