Isn't IT automation inherently evil? (I mean, you saw 'The Terminator,' right?)

While the general take on CloudWorld in San Francisco last week may have been that it was merely a shadow of what industry attendees were expecting, at least one presentation seems to have registered on the "worthy-of-discussion" meter. Lew Tucker from Sun was written up by Larry Dignan of ZDNet, Reuven Cohen, The Register, and others, for Lew's commentary on self-provisioning applications and "future cloud apps that won't need humans."

A couple things strike me about this "humanless computing" (as Reuven put it): first, whether people really think it through or not, this kind of automation is absolutely required for cloud computing. The types of dynamic infrastructures that businesses are hoping to get from the cloud just can't have a human in the minute-by-minute IT operations loop. (See also: human telephone switch operators.)

OK, fine. But that brings me to point #2: people hate automation. It's assumed to be faceless, out of control, and most likely up to no good. There's a whole Terminator movie & TV franchise built on the premise that the "rise of the machines" is to be avoided at all costs.

But while the evil of IT automation is great fodder for summer blockbusters, it's bad IT policy. Some specifics to think about:

Automation is a big part of cloud computing

Automation similar to what Lew was explaining is at the core of what cloud computing really is (or more honestly, what it will be when it's fully realized). Contrary to what many folks assume, the core requirement for a cloud is not virtualization. Virtualization is a technology that can be helpful in creating a cloud-style model, but it's not an absolute necessity. On the other hand, automation is one of those core cloud requirements -- the ability for systems to scale up and down without manual efforts, adding and releasing resources, and in many respects managing themselves.

Lori MacVittie of F5 explained this well in her post about "Putting the Cloud Before the Horse." "It isn't really a cloud unless it's automated," said Lori. "Without that automation what do you have? A bunch of servers running applications. That those applications are virtualized is really irrelevant to the architecture because you haven't done anything but changed which physical server they're being deployed on. Without the ability for the infrastructure to make decisions based on actionable data that's shared between the components, you really don't have anything all that much different than you did before."

Automation remains scary to IT shops

Earlier this year, before CA's acquisition of the Cassatt assets and expertise, I wrote a bit about some of the reasons that IT remains leery of automation and boiled it down to three reasons: the IT operations folks are a conservative bunch (and rightly so), automation requires a great deal of trust, and vendors have made it hard on themselves by frequently overpromising and under-delivering.

The complexity of IT environments is part of the problem here, something that Forrester’s Glenn O’Donnell underscored in "IT Operations 2009: An Automation Odyssey" (Forrester client link) last month (Denise Dubie of Network World did a nice analysis of Glenn's paper here.) "A combination of forces, including skyrocketing complexity and severe economic pressure, are radically and irreversibly altering the IT landscape," said Glenn. "Evidence indicates an automation 'tipping point' is already under way this year."

2009 as the tipping point for automation?

So, if you agree that automation is an important piece for enterprises to begin to use public and private clouds, and you agree that IT avoids automation like the plague, are we at an impasse? Why would this year (of all years) see huge shifts?

As I speculated earlier and as Glenn notes, "the one-two punch of virtualization and economic pressure represents a tectonic shift for IT. For many IT services, complexity has surpassed human ability." (Once again, see also: human telephone switch operators.)

So does that mean it's time to jump in whole hog? As with anything in the enterprise, don't bet on it. Glenn has two good bits of advice here. First, find your threshold for automation. For every IT organization that will be different.

To steal (and probably mangle) an analogy from Cassatt's former CTO Rob Gingell, some IT folks are like new Prius owners that go through their daily commute entranced by the little dashboard graphics showing when & how different parts of their hybrid engine are charging up or firing away. Others are less interested in the moment-by-moment changes going on and trust that the engine will do what it's supposed to do. (Often these are the same people, just a few weeks later.) This second group are the ones who are more willing to try more automation (after they see it perform admirably on its test runs, of course). Those are also the ones where the costs of tools, people, and process improvements (what Glenn calls "automation pain") are going to be offset by their org's "automation gain," an important balance to strike.

Another point Rob Gingell often makes is that the history of computing has been all about the drive toward increasing automation. Cloud computing is just another step. Previously you'd have to tell your operating system to do things in order for computing to proceed -- a step that we've thankfully evolved beyond. It will be the same with applications self-provisioning to maintain their service levels. Eventually.

OK, but shouldn't we still be a little worried about the Terminator scenario?

Lew Tucker's CloudWorld talk referenced Skynet, the self-aware (and quite nasty) computing system from the Terminator movies. He gave a nod to the underlying worry we humans have (at least, IT operations humans have) that the moral equivalent of a T-1000 is going to show up and take out some critical part of your data center and bring down important applications. And, sure, there are some twisted ways that automation can go wrong. (Stuart Charlton of Elastra pointed me to some amusing ones, which also note where humans make things worse.)

But, it was with no small amount of irony that Cassatt used the Skynet name as the internal codename for our next-generation product architecture, in which more and more of the things your system needs to do to were handled autonomously, not for purposes of world domination or hunting down the last remaining humans, but instead to maintain application service levels.

Be on the correct side of history

So, scary as things could seem around cloud computing and automating IT operations, it's logical that it will follow the pattern that enterprise IT has followed since it began: there is a gradual move toward making the impossible or hard-to-imagine things possible, even if the rate of that movement is somewhat unpredictable. Not long ago, doing e-commerce and Internet banking were seen as science fiction. Little by little, the risks became manageable and/or understood. IT incorporated what was needed and moved on.

I expect much the same is in store for the automation that's needed to enable cloud computing. Why? Lori MacVittie put it well: "If you want to take it to the next level, you're going to have to automate processes because that's where real operational benefits will be realized."

One other suggestion for those whose jobs are potentially impacted by automation comes from Glenn's work at Forrester: "Be the automator not the automated." Especially as the economy is forcing drastic cuts or at least hard choices, being on the side of providing the solution is more advisable. So, think a bit about how automation could actually make a difference, and help advocate that change.

So, in the end, IT automation is both important and possible. It's the key to some of the new cloud-driven capabilities that are within reach for organizations. Some organizations are jumping in with both feet now, and if Glenn's right a lot more will be experimenting this calendar year.

Which by some estimates is even a little late. I mean, wasn't Skynet supposed to take over starting in 1997?