A Lengthy Introduction
It was a big week for geeks in the valley. Structure, Velocity, DevOpsDays left many of us running up and down the peninsula with powercords, swag and severe sleep dep. On a personal note, I got epically destroyed in the ”Give me an API or give me death” challenge, accidentally caused a Twitter argument discussion through poor hashtag handling, survived the cloud rite-of-passage that is Bitten By Squirrel without crying (ok, there were a few tears), and lived through watching Mr. Marc Benioff talk about Cloud 2.0 at Structure. (On the latter point, it should be noted that I would rather spin perpetually on a Hamster Wheel of Pain welded at the bottom of the Trough of Disillusionment, encapsulated within the very Chasm, than hear about Cloud 2.0 again.)**
I’ve attended a number of cloud-cloudy-cloudish events and meetups of late (in addition to the above, Gluecon, Google I/O, Web 2.0 expo, CloudCamps, API meetups, and etc.), and I’ve been talking to a ton of developers using, considering, implementing cloud tech, and sometimes I read stuff, like blogs, but mainly Twitter. This blog is about something I’ve seen over the past few months: the arrival and early sedimenting of a new cloud user profile, an emerging archetype- the “Rogue Clouder.”

What is the Rogue Clouder?
Devs and other IT peeps experimenting with, implementing and testing IaaS and cloud platforms at work and with work “stuff” (dolla bills, time, data, apps, workloads) but outside the purview of corporate structure. In the real world, this plays out in a number of different scenarios- running some workloads in EC2 without the boss, CIO or security team knowing; testing out a few apps on the Rackcloud without seeking any formal permissions; throwing some files up into S3 without getting sign-off; doing some early-stage deployments using a cloud abstraction API without explaining to anyone what a cloud abstraction API is- end game, it varies in commitment, scope, and ultimately in consequence.

The emergence of this user type has gotten a lot of attention- and not just because it is has enough drama and controversy to fill a Tom Clancy novel or at least a TweetDeck column-  but because it is INEVITABLE and IMPORTANT.

The Inevitability of Rogue
It’s INEVITABLE because you can buy cloud with a credit card and get it in variable amounts. Like a beer sampler plate, this permits an unprecedented ability to experiment with radical new approaches to IT. Cloud is a process innovation in the delivery of infrastructure that makes the lab rat psychotically pounding the food dispenser button look like a study in delayed gratification. Unlike previous infrastructure changes (virtualization, new server architectures, etc) that have required lots of up-front cash and elaborate processes of discovery, research and implementation, with cloud, you can just play around a little bit and then ramp up- no task force required. This obviously has enormous implications for sales cycles but also just means it changes the process of how people engage with cloud and services and tools delivered by it and with the “aaS” model. Rogue is now POSSIBLE and cloud’s seductive promises to eliminate provisioning and scalability pains- as well as to provide the enormous pleasure of massive responsiveness at the infra level (I CAN SPIN UP A SERVER ON A PLANE OMG THIS IS BETTER THAN EITHER SEX OR CANDY), means that the possible has quickly become the unavoidable.

The Importance of Rogue
It’s IMPORTANT because it indicates a new phase in the cloud market. Companies creating, distributing and selling products in the infancy of new markets- like cloud- are tasked with creating hypotheses for how adoption will happen in an unrealized and yet nonexistent customer base. This involves a lot of conversation, a lot of studying the market- but eventually it comes down to coming up with informed guesses about who is going to want it, how they are going to find it, how it is going to lead to larger adoption and how you can nurture that. This is why you saw so much discussion and debate a year ago about who you were going to sell cloud to- the CIO? The CEO? Well, at least no one proposed selling to the CISO. That would just be crazy talk.

It shows we’ve reached a new phase in the evolution of the market that we are able to form more substantiated user profiles based on user stories, data, and connecting the dots of patterns across the board and in different communities- from business audiences at Structure to developer audiences at other events. The ability to segment and analyze cloud adopters and more importantly their processes of adoption leads to a new wave of major opportunity in the market.

But the Rogue Clouder is also problematic for a number of reasons, not the least of which being that he is hated and hunted by security teams across the globe. But don’t worry. I have reduced this problem to a Chasm Analogy. (You’re welcome).

The Rogue Chasm
Here’s the problem. Having leagues of rogue clouders inside the enterprise DOESN’T smoothly translate or transition to large-scale enterprise adoption. Unsanctioned cloud experiments aren’t just going to happily work their way up to the CEO, who shall declare: And Now, Thanks to Rogue Clouder, AKA Employee of the Month, WE CAN ALL HA__S CLOUD. No. In fact, it might be a perfect recipe for Crash and Burn if the “higher ups” start deciding that the way to deal with this problem is to squash rogue once and for all with various Death Methods such as firing and security policies.

The point is that while the cloud generation and the aaS model has theoretically enabled a new process and ramp for adoption (try a little, pay as you go, scale up when you are ready), this is not matched by process innovations inside the enterprise that accommodate progressive, sanctioned experiments in new technology. Again, the speed, ease and flexible scale of IT experimentation that we have today hasn’t existed before, and so the enterprise naturally doesn’t have a methodology for initiating, dealing, securing, evaluating results, and eventually transitioning to larger and larger levels of adoption. This leads to increased levels of isolation, siloing, and antagonism between, for example, the Rogue Clouder and the security team. And for cloud sellers especially who are hoping that bottom-up adoption started by Rogue Clouders will lead up the command chain, this should be especially troubling. Vendors have a vested interest in helping Rogue Cloud Adopters cross the internal chasm into higher levels of sanctioned adoption.

What Next?
It is my personal opinion that the emergence of this “chasm” is leading to an acceleration in conversations around internal IT processes (like agile, devops, etc.). Either way, it is important that companies, devs and everyone can safely evaluate and benefit from escalating rates of change in the space and the new opportunities they afford by implementing formal, audit-able processes for Trying New Things, Fast. I think these conversations are necessary and at greater and greater levels of maturity and formality.

I don’t have an answer to the problem, but I do know that enterprises need to evolve processes that bring the Rogue Clouder- who really isn’t trying to be disingenuous or dangerous but just trying to find better ways to do their job- under corporate purview in ways that enable SAFE and WELL CONSIDERED experimentation with things that might just have the ability to revolutionize your efficiency and speed, make you rich and allow you to buy a fleet of ponies. (Ponies are the new yacht.)

There is urgency around this for a simple reason: Abstinence-Only doesn’t work.

On Abstinence-Only Education
Abstinence-only education in the school system doesn’t work because it denies the inevitability of hormones, the ubiquitous opportunity of unsanctioned after-school congress, and the general corruption of the youth by television and music videos. Abstinence-only education doesn’t work for public cloud either: it denies the inevitability of curiosity, the ubiquitous opportunity of unsanctioned congress with EC2, and the general corruption of developers by Twitter and tech bloggers.

It is what it is. And just like you don’t want the first time you explain “The Birds and the Bees” to your teenager to be six weeks after spring formal, you don’t want the first time you have “The EC2 and S3” talk with your developers to be when you are digging through their expense reports and find a series of suspicious Amazon invoices. So while you might not be ready for a process yet, but it IS, at the very least, time for a conversation.

A Small Request
That’s all I have. Please don’t skewer me. This is my first blog and I’m emotionally fragile.

Thanks.