More about the ‘people side’ of cloud: good-bye wizards, hello wild ducks and T-shaped skills

One of the problems that has dragged down the transformational ideas around cloud computing is the impact of this new operating model on organizations and the actual people inside them. I noticed this back in my days at Cassatt before the CA acquisition. The Management Insight survey I wrote about a few weeks back pointed this out. And, if you’ve been following this blog, I’ve mentioned it a couple other times over the past few months as the hard part of this major transition in IT.

While the technical challenges of cloud computing aren’t simple, the path to solve them is pretty straightforward. With the people side of things…not so much.

However, I’m optimistic about a new trend I've noticed throughout the first month of 2011: much of the recent industry discussion is actually talking through the people issues and starting to think more directly about how cloud computing will affect the IT staff.

Now, maybe that’s just beginning-of-the-year clarity of thought. Or people sticking to some sort of resolutions.

(I have a friend, for example, who swears off alcohol for 31 days every January 1st. He does it to make up for the overly festive holiday season that has been in high-gear the previous month. But I think he also uses it as an attempt to start the year out focusing himself on the things he thinks he should be doing, rather than having an extra G&T. And it usually works. For a while, anyway.)

Whatever the reason, I thought it was worth highlighting interesting commentary that’s recently appeared in the hopes of extending (and building on) the discussion about the human impact of cloud computing.

It’s got to be you

Back in December, the folks on-stage at the Gartner Data Center Conference had a bunch of relevant commentary on IT and its role in this cloudy transition.

Gartner analyst Tom Bittman noted in his keynote that for cloud computing, IT needs to focus. The IT folks are the ones that “should become the trusted arbiter and broker of cloud in your organization.” He saw evangelism in the future of every IT person in his audience from the sounds of it. “Who is going to be the organization to tell the business that there is a new opportunity based on cloud computing? That’s got to be you.” Are people ready for that level of commitment? We’ll find out. With great power comes great responsibility, right?

Automation & staffing levels

With cloud also comes an increasing reliance on automation. That hands IT people a big reason to push back on cloud computing right there. As Gartner analyst Ronni Colville said in one of her sessions, “the same people who write the automation are the ones whose jobs are going to change.”

In another session, Disney Interactive Media Group’s CTO Bud Albers talked about how the company’s cloud-based approach to internal IT has impacted staffing levels. “No lay-offs,” he said, “but you get no more people.” That means each person you do have (and keep) is going to have to be sharpening their skills toward this transition.

T-shaped business skills

In the era of cloud computing, then, what do you want that staff to be able to do?

Gartner’s Dave Cappuccio talked about creating a set of skills that are “T-shaped” – deep in a few areas, but having broad capabilities across how the business actually works. He believes that “technology depth is important, but not as key as business breadth.” The biggest value to the business, he said, is this breadth.

So that means even more new IT titles from cloud computing

To get to what Cappuccio is proposing, organizations are going to have to create some new roles in IT, especially focusing on the business angle. A few posts ago, I rattled off a whole list of new titles that will be needed as organizations move to cloud computing. Last week, Bernard Golden’s blog at CIO.com talking about “Cloud CIO: How Cloud Computing Changes IT Staffs” made some insightful suggestions (and some, I’m happy to say, matched mine). He noted the rising importance of the enterprise architect, as well as an emphasis on operations personnel who can deal with being more “hands-off.” He saw legal and regulatory roles joining cloud-focused IT teams and security designers needing to handle the “deperimeterization” of the data center. And, IT financial analysts become more important in making decisions.

Gartner’s Donna Scott agreed with that last one in her session on the same topic at the Gartner Data Center Conference. She believed that the new, evolved roles that would be needed would include IT financial/costing analysts. She also called out solution architects, automation specialists, service owners, and cloud capacity managers.

Wild ducks & the correct number of pizzas

So what personalities do you need to look for to fill those titles?

At the same conference, Cameron Haight discussed how to organize teams and whom to assign to them. “If you have that ‘wild duck’ in your IT shop, they’re dangerous. But they are the ones who innovate,” he said.

Haight noted that the hierarchical and inflexible set up of a traditional IT org just won’t work for cloud. What’s needed? Flatter and smaller. “Encourage the ‘wild duck’ mentality,” said Haight. “Encourage critical thinking skills and challenge conventional wisdom” in individuals.

As for organizing, “use 2-pizza teams,” he suggested, meaning groups should be no larger than 2 pizzas would feed. (He left the choice of toppings up to us, thankfully.) Groups then should support a service in its entirety by themselves. Haight believes this drives autonomy, cohesiveness, ownership, and will help infrastructure and operations become more like developers, lessening the “velocity mismatch” between agile development and slow and methodical operations teams.

To take this even farther, take a look at the Forrester write-up called “BT 2020: IT’s Future in the Empowered Era.” Analysts Alex Cullen and James Staten talk about a completely new mindset that’s needed for IT (or, as they call it, BT – business technology) by 2020. Why? Your most important customers today won’t be so important then, what those new customers will want IT doesn’t yet provide, and the cost of energy is going to destroy current operating models.

Other than that, how was the play, Mrs. Lincoln? But, hey, 2020 is still a ways off.

Moving past wizardry: getting real people onboard with real changes today

Getting the actual human beings in IT to absorb and actually be a part of all these changes is hard and has to be thought through.

At a recent cloud event we held, I interviewed Peter Green, CTO and founder of Agathon Group, a cloud service provider that uses CA 3Tera AppLogic (this clip has the interview; he talks about cloud and IT roles starting at 3 min., 55 sec.). These changes are the hardest, Green said, “where IT sees its role as protector rather than innovator. They tend to view their job as wizardry.” That’s not a good situation. Time to pull back the curtain.

Mazen Rawashdeh, eBay’s vice president of technology operations, noted onstage at the Gartner conference that he has found a really effective way to get everyone pointed the same direction through big changes like this. “The moment your team understands the ‘why’ and you keep the line of communications open, a lot of the challenges will go away.” So, communicate about what you're up against, what you're working on, and how you're attacking it. A lot.

Christian Reilly posted a blog last month that I thought was a perfect example of that eyes-wide-open attitude, despite the uncertainty that all of these shifts bring. Reilly (@reillyusa on Twitter) is in IT at a very large end-user organization dealing with cloud and automation directly.

“I am under no illusion,” Reilly posted, “that in the coming months (or years)…automation, in the guise of the much heralded public and private cloud services, will render large parts of my current role and responsibility defunct. I am under no illusion that futile attempts to keep hold of areas of scope, sets of repeatable tasks or, for that matter, the knowledge I’ve collected over the years will render me irreplaceable.

“Will I shed tears? Yes. But they will be tears of joy.”

A little over the top, sure, but he gets a gold star for attitude. Green of Agathon Group thinks the cloud is actually the opportunity to bring together things that have been too separate.

“Where I see a potential, at least,” said Green, “[is] for cloud computing to act as a common area where tech and management can start to converse a little bit better.”

So, as I said, January has given me a little hope that the industry is on a good path. Let’s hope this kind of discussion continues for the rest of the year.

Cloud conjures up new IT roles; apps & business issues are front & center

So you’ve managed to avoid going the way of the dodo, and dodged the IT job “endangered species list” I talked about in my last post (and at Cloud Expo). Great. Now the question is, what are some of the roles within IT that cloud computing is putting front & center?

I listed a few of my ideas during my Cloud Expo presentation a few weeks back. My thoughts are based on what I’ve heard and discussed with IT folks, analysts, and other vendors recently. Many of those thoughts even resonated well with what I’ve heard this week here at the Gartner Data Center Conference in Las Vegas.

IT organizations will shift how they are, well, organized

James Urquhart from Cisco put forth an interesting hypothesis a while back on his “Wisdom of Clouds” blog at CNET that identified 3 areas he thought will be (and should be) key for dividing up the jobs when IT operations enters “a cloudy world,” as he put it.

First, there’s a group that James called InfraOps. That’s the team focused on the server, network, and storage hardware (and often virtual versions of those). Those selling equipment (like Cisco) posit that this area will become more homogenous, but I’m not sold on that. James followed that with ServiceOps, the folks managing a service catalog and a service portal, and finally AppOps. AppOps is the group manages the applications themselves. It executes and operates them, makes sure they are deployed correctly, watches the SLAs, and the like.

I thought these were pretty useful starting points. I agree whole-heartedly with the application-centric view he highlights. In fact, in describing the world in which IT is the manager of an IT service supply chain, that application-first approach seems paramount. The role of the person we talk to about CA 3Tera AppLogic, for example, is best described as “applications operations.”

Equally important as an application-centric approach are the skills to translate business needs into technical delivery, even if you don’t handle the details yourself. More on that below.

Some interesting new business cards

I can already see some interesting new titles on IT peoples’ business cards in the very near future thanks to the cloud. Here are some of those that I listed in my presentation, several of which were inspired by the research that Cameron Haight and Milind Govekar have been publishing at Gartner. (If you’re a Gartner client, their write-up on “I&O Roles for Private Cloud-Computing Environments” is a good one to start with.):

· “The Weaver” (aka Cloud Service Architect) – piecing together the plan for delivering business services
· “The Conductor” (aka Cloud Orchestration Specialist) – directing how things actually end up happening inside and outside your IT environment
· “The Decider” (aka Cloud Service Manager) – more of a vendor evaluator and the person who sets up and eliminates relationships for pieces of your business service
· “The Operator…with New Tools” (aka Cloud Infrastructure Administrator) – this may sound like a glorified version of an old network or system administrator, but there’s no way this guy’s going to use the same tools to figure all this out that he has in the past.

In Donna Scott’s presentation at the Gartner Data Center Conference called “Bringing Cloud to Earth for Infrastructure & Operations: Practical Advice and Implementations,” she hit upon these same themes. Some of the new roles needed that she listed included solution architects, the automation specialist, the service owner, cloud capacity manager, and IT financial/costing analyst. Note the focus on business-level issues – both the service and the cost.

Blending

Or maybe the truth is that these roles blend together a bit more. I could see the IT organization evolving to perform three core functions in support of application delivery:

— Source & Operate Resource Pools This person would be someone who would maintain efficient data center resources, including the management of automation and hypervisors. The first is the ability to more effectively manage resources—to determine how much memory and CPU is available at any given time, to scale up and down capacity in response to demand (and have the ability to pay only for what you use). These resources might eventually be sourced either internally or externally, and will most often be a combination of the two. This function will be responsible for making sure the right resources are available at the right time and that the cost of those resources is optimized.

— The second function is Application Delivery, focused on building application infrastructure proactively, so that when the next idea comes down the pike, you can be ready. You can proactively build an appropriately flexible application infrastructure. You can provide the business with a series of different, ready-made configurations from which to choose, and you would have the ability (when they are needed) to quickly get these pre-configured solutions up and running quickly.

— The last, higher-level function is the process of engaging with the business closely. Your job is to Assemble Service. You’ll be able to say to the business ‘bring me your best ideas’ and you’ll be able to turn those concepts into real, working systems quickly, without having to dive into lower-level technical bits & bytes that some of the previously mentioned folks would.

In all cases, I’m talking about ways to deliver your application or business service, and the technical underpinnings are fading into the background a bit. “Instead of being builders of systems,” said Mike Vizard in a recent IT Business Edge article, “most IT organizations will soon find themselves orchestrating IT services.”

James Urquhart talks about this as an important tenant of the DevOps approach: The drive to make the application the unit of administration, not the infrastructure. James had another post more recently that underscored his disappointment that shows like Cloud Expo are focusing more on the infrastructure guys still, not the ones thinking about the applications. I’m all in favor. I heard Gartner’s Cameron Haight suggest why this might be true in most IT shops: while development has spent a lot of time working toward things like agile development, IT ops has not. There’s a mismatch, and work is starting on the infrastructure side of things to address it.

Still, how do you get there from here?

So the premise here is that cloud will change the role of IT as a whole, as well as particular IT jobs. So what should you do? How do you know how to ease people into these roles, how to build these roles, or even how to try to make these role transitions yourself?

I’ll repeat the advice I’ve been giving pretty consistently: try it.

— Figure out what risks you and your organization want to take. Understand if a given project or application is more suited to a greenfield, “clean break” kind of approach or to a more gradual (though drawn-out) shift.
— Set up a “clean room” for experimentation. Create the “desired state” (Forrester’s James Staten advocated that on a recent webcast we did with him). Then use this new approach to learn from.
— Arm yourself with the tools and the people to do it right. Experience counts.
— Work on the connection between IT & business aggressively
— Measure & compare (with yourself and others trying similar things)
— Fail fast, then try again. It’s all about using your experience to get to a better and better approach.

There was one thing that I heard this week at the Gartner show from Tom Bittman that sums up the situation nicely. IT, Tom said, has the opportunity to “become the trusted arbiter and broker [of cloud computing] in your organization.” Now that definitely puts IT in a good place, even a place of strength. However, there’s no denying that many, many folks in IT are going to have to get comfortable with roles that are very different from the roles they have today.

(If you would like a copy of the presentation that I gave at Cloud Expo, email me at jay.fry@ca.com.)

As cloud computing changes IT roles, which IT jobs are on the ‘endangered species list’?

A funny thing happened during my Cloud Expo presentation in Santa Clara recently that I wasn’t expecting. I was trying to come up with a few points in the session where I could get a read on whether the audience was following me or not. And since my topic was “How Cloud Computing is Changing the Role of IT…and What You Can Do About it,” I figured at least someone would have an opinion. So I asked a few questions of the audience.

And (you guessed it), there was no shortage of opinions. In fact, I found myself in the middle of a full-fledged discussion. Especially when we started talking about which IT job titles were or were not going to exist any longer as a result of cloud computing. Interesting stuff. Here’s a summary of the presentation I gave, plus a few comments from the audience thrown in for color:

Cloud computing is causing two big IT-related role shifts. Cloud computing has given business users choices it didn’t have before; it’s breaking the monopoly that IT has had on the sourcing of IT service. It means business can go around IT, can “go rogue” and find the services they think best suit themselves. The doom & gloom scenario for IT is that it’s time to pack up and go do something else.

Will IT go away because of cloud computing? Half of my session attendees (which was two-thirds end users) thought that cloud computing will at least cause IT to lose jobs. However, I’m not nearly that negative; I tend to agree with our own Bert Armijo who likes to say that IT jobs don’t go away when faced with the Next Big Thing. They just reshuffle. So the real question, then, is what does the deck look like after all the shuffling is done? More on that in a moment.

First: IT is becoming an orchestrator of a new IT service supply chain

What I told folks at Cloud Expo is that from what I see, cloud computing and its focus on business services, rather than the underlying technology, are altering the broad responsibilities and the approach of IT. Cloud is changing IT’s role inside an organization. It opens up the possibility of getting IT service from many different sources and the corresponding need to orchestrate those many sources. Mike Vizard talked about this in a recent IT Business Edge article: “Senior IT leaders,” he said, “will soon find themselves managing a supply chain of IT services.”

This role as orchestrator of things you don’t own is a new one in some ways, though many folks have been managing outsourcing (similar in some ways) for a while now. Shifting all of IT to have this mindset is very significant; it means adjusting to a role as a service provider, selecting the best of both internal and external services as appropriate.

And that’s where things get interesting for the actual jobs inside the IT department. Some of those are going to have to change.

Second: how IT jobs themselves are changing

One of my points was that this IT supply chain concept creates a whole new set of questions, opportunities, and requirements to make things work. (Here’s an earlier post of mine describing some of those new requirements.) IT will certainly be more business-oriented and less focused on the underlying infrastructure components as layers of abstraction help make it smarter -- and possible -- to think beyond the nitty gritty.

So how is cloud changing the individual roles and jobs within the IT department? I identified 3 important influencers:

· Automation – fewer manual tasks means less demand for the people who do them today
· Abstraction – technical minutiae are less important to focus on, while the business service itself takes on a much more primary role
· Sourcing – vendor management and comparison (and some way to make choices) move to the forefront

Products (like several of ours) can help take these new approaches in what are often very fast, effective steps. But the IT folks themselves need to realize that they really need a new way of looking at their jobs, and, in fact, some of their jobs may end up very different from where they are today. That’s not a quick problem to solve. I remember this issue being a weighty problem back in my Cassatt days, too.

So what IT jobs are on the endangered species list?

At Cloud Expo, I listed off a bunch of titles to see what the audience thought were the soon-to-be-extinct IT jobs. I let people categorize the jobs as either Cockroaches (as in, “will always have a job,” you can’t get rid of them), Chimps (“need to adapt to survive”), or Dodos (“buh-bye”). OK, so the categories weren’t necessarily flattering, but it added a touch of levity to what can be a somber topic for IT.

My in-room responses had some dissenting opinions, obviously, but they were, in fact, surprisingly uniform. Here's where people more or less categorized a few different IT jobs:

Cockroaches: service provider vendor manager, SLA manager
Chimps: software/apps deployment person, network administrator, server monitoring/ “Mr. Fix-it”
Dodos: capacity planning, CIO

Yes, you just read that my audience thought CIOs were going to go extinct.

I sensed a bit of dramatic license was being taken for impact in the room, but the discussion was definitely interesting. There is certainly a case to be made that the tools, approaches, and processes that the CIO relies on today, for example, need to get a major revamp, or things will look pretty bleak for the folks in those jobs.

There was agreement that the business-level capabilities of the IT people who look at service levels and manage service providers matches up well with the shift that seems to be going on toward business-level conversations.

And, the realization that even the most core of administrator roles (network, server) and the break-fix mentality currently in place in a huge majority of IT shops just doesn’t seem as relevant in a world seriously involved with cloud computing. Or, at least, it makes sense that there will need to be an important set of adaptations. In the world of cloud computing, you don’t fix the malfunctioning commodity server. Instead, you ensure that your systems route around it (through internal or external sources) and continue to deliver the service.

It’s time for quite a lot of staff evolution, from the sounds of it. At least, that’s what my Cloud Expo audience thought. My next post will cover exactly that: I’ll build on these comments and look at the approaches, roles, and solutions that I highlighted to help IT leverage the cloud computing trend.

And for the squeamish, I'll try not to mention cockroaches again.

(If you'd like a copy of my Cloud Expo presentation, e-mail me at jay.fry@ca.com.)

Making cloud computing work: customers at 451 Group summit say costs, trust, and people issues are key

A few weeks back, the 451 Group held a short-but-sweet Infrastructure Computing for the Enterprise (ICE) Summit to discuss "cloud computing in context." Their analysts, some vendors, and some actual customers each gave their own perspective on how the move to cloud computing is going -- and even what's keeping it from going.

The customers especially (as you might expect) came up with some interesting commentary. I'm always eager to dig into customer feedback on cloud computing successes and roadblocks, and thought some of the tidbits we heard at the event were worth recounting here.

(A side note: if you're interested in more cloud-related customer comments, you can look at some previous Data Center Dialog posts, including this one recounting questions overheard about internal clouds from a few months back.)

Clouds under the radar

As a way to set the stage, 451 Group analyst and ICE practice lead Rachel Chalmers compared cloud computing’s adoption to that of Linux in the late '90s, and to the beginnings of server virtualization in dev/test environments. "There was a lot of VMware [being used in IT] before CIOs even knew it was there. It only belatedly comes to the attention of the architects." Chalmers was clear that adoption is underway ("Customers are already using cloud," she said), and emphasized how under-the-radar adoption like this can really help. "They come pre-evangelized," said Chalmers. That means there are a lot fewer people to convince when it comes time to make the case to roll this out widely.

Customers: Some hesitate to call it cloud

Yuvi Kochar, CTO from the Washington Post Company, saw the work that his teams were doing as shared services, and said, "I hesitate to call this work a cloud." He acknowledged that they were enabling elasticity and cost accounting, but that some of what they were working on was still "hand-wired." What was the thing that pushed Kochar over the edge to move toward dynamic, shared IT services (even if he can't bring himself to actually it "cloud")? Cost. "We want to move everything to a variable cost model," Kochar said. Another customer, Ljubomir Buturovic, VP & chief scientist from Pathworks Diagnostic, said they told their server vendor they would be buying no more hardware, and they haven't. Again: cost was the driver -- in this case, capital costs.

Cloud: It's (still) not for the faint of heart

I thought some of the most useful insights of the customer panel were from Jim Houghton, now co-founder and CTO of Adaptivity. Houghton reflected back on his experiences a few years ago getting what could now be termed a private cloud -- then called utility computing -- off the ground at Wachovia and Bank of America. He characterized the work as something which eventually turned into a $100-million project to stabilize a "chaotic environment" in IT and "took out $500 million in op ex."

Houghton noted that he and his employers at the time "learned a lot of hard lessons along the way." For example, the mechanisms for truly automated provisioning and handling dynamic shifts in demand are "really important," but really hard, especially since the tools at that time he started (early to mid-2000s) were still quite immature. Metering what you're using is critical, he said, but "it's hard to meter when you're separate from the physical environment." Overall, said Houghton, cloud-style dynamic infrastructure is "not for the faint of heart."

Funny. I heard Donna Scott of Gartner make the same observation about creating a real-time infrastructure back in December. We've come a long way, but there's more to do, for sure.

Biggest pain: impact on the people and the organization

Houghton identified a couple best practices for making the shift to a dynamic, shared infrastructure to support your applications: for example, workloads that are entirely self-contained and in which you have access to the source code make excellent candidates for these types of deployments. However, he said, you need to truly understand the workload characteristics. That last bit is something I've heard many large IT organizations lament as a huge problem -- profiling what they currently have and how it runs.

However, he said, the more painful thing is the change in the operational model and its impact on a company's organization and the people that work in it. I've heard this many times over the past several years, from customers, analysts, and even vendors. You can't underestimate the impact that the cloud operating model will have on personnel.

"It gets to be a very touchy subject for clients," said Houghton. "It's hard to do the business cost model without talking about 'these 20 people will be out of a job.'" Or at least who can be moved to focus different things than they're focused on today.

Need to move beyond just virtualization

Houghton also made a comment that infrastructure that's "mildly virtualized may be efficient, but is not all that dynamic." I have to agree: there is a lot more needed to make a private cloud-style infrastructure fly than loading up on a bunch of virtual servers. In fact, that point was made pretty strongly when Dan Kusnetzky lined up his fellow 451 Group analysts to highlight some of the cloud computing inhibitors. William Fellows conveniently rattled off some of his (and the industry's) favorites: security, SLA support, corporate governance, interoperability, vendor viability, job security, and misaligned business models. To name a few.

These are issues we've heard before, for sure, and are at the top of the list of things to be addressed in order for cloud computing to be viable day-to-day in an IT shop. I think it's good news that we're hearing more and more about the manageability side of the issue.

Can I drive your Mercedes while you're not using it?

One of the strongest objections to an internal cloud, or really a shared infrastructure of any sort, still boils down to what's called "server hugging." Houghton gave an amusing explanation of the mentality by putting it this way: "Just because I have 4 Mercedes and I can only drive 1 at a time, doesn’t mean I'm going to let you drive the other 3." In his case, the team of coworkers and vendors pitching this new approach had to put in "years of work" to "build up the trust. What you have to say in response is, 'You'll get everything you wanted, plus a lot more.'" And, of course, you have to back it up by delivering on your promises with great cost savings, excellent service levels, and an improved ability to respond to new requirements from the business.

Are we making progress on cloud computing?

Chalmers noted that in many cases a move to cloud computing doesn't feel like progress at all. "All we're doing is moving the headaches somewhere else. But," she said, those management headaches "still need to be solved."

Fellows noted that there really isn't any definition of success so far. Early adopters of grid, utility computing, and virtualization have been the ones in his experience to be most aggressive in working toward cloud-style environments. "It’s a logical end-point for any of those [earlier] activities," said Fellows.

In fact, said Chalmers, "very often when we see an early adopter of cloud that's successful, it's because they understood HPC [high-performance computing] and putting everything under control in the data center."

So, are we making progress toward incorporating cloud computing in today's IT environment?

Houghton from Adaptivity made the point that "the economic malaise has put a lot of power back into the CTO's hands." It's a chance to use this power to instigate more sweeping changes to how IT operates than any time in recent memory. But people are being judicious with that power.

Appropriately, Chalmers probably did the best job of putting cloud computing in that context: "In this world of financial crisis, the acid test of any technology is: 'Does anyone care enough to sign a purchase order?'" Clearly, some do. (And some fraction of those are on stage at events like this talking about what they've done and learned.) And, as the industry matures the management capabilities and works out the kinks that many of these customers noted, others will start to feel that it's time to sign on the dotted line, too. And hopefully join them on stage.

Webcast polls: Fast progress on internal clouds, but org barriers remain

Today's free advice: you should never miss out on the opportunity to ask questions of end users. Surprise, surprise, they tell you interesting things. And, yes, even surprise you now and again. We had a great opportunity to ask some cloud computing questions last week, and found what looks like an interesting acceleration in the adoption -- or at least consideration -- of internal clouds.

As you've probably seen, Cassatt does an occasional webcast on relevant data center efficiency topics and we like to use those as opportunities to take the market's temperature (even if we are taking the temperature of only a small, unscientific sample). Back in November, we asked attendees of the webcast Cassatt did with James Staten of Forrester (covering the basics of internal clouds) some very, well, basic questions about what they were doing with cloud computing. The results: enterprises weren't "cloudy" -- yet. 70% said they had not yet started using cloud computing (internal or external).

Last Thursday we had another webcast, and again we used it as an opportunity to ask IT people what they actually are doing with internal clouds today. As expected, end users have only just started down this path and they are being conservative about the types of applications they say they will put into an internal cloud at this point. But you'd be surprised how much tire-kicking is actually going on.

This is a bit of a change from what we heard from folks back in the November Forrester webcast. In last week's webcast we were a little more specific in our line of questioning, focusing our questions on internal clouds, but the answers definitely felt like people are farther along.

Some highlights:

The webcast itself: tips on how to create an internal cloud from data center resources you already have. If you didn't read about it in my post prior to the event, we had Craig Vosburgh, our chief engineer and frequent contributor to this blog, review what an internal cloud was and the prerequisites your IT operations team must be ready for (or at least agree upon) before you even start down the path of creating a private cloud. He previewed some of what he said in the webcast in a posting here a few months back ("Is your organization ready for an internal cloud?"). The second part of the webcast featured Steve Oberlin, Cassatt chief scientist and blogger in his own right, covering 7 steps he suggests following (based on direct Cassatt customer experiences) to actually get an internal cloud implementation going.

On to the webcast polling question results:

IT is just beginning to investigate internal cloud computing, but there's significant progress. The biggest chunk of respondents by far (37%) were those who were just starting to figure out what this internal cloud thing might actually be. Interestingly, 17% had some basic plans in place for a private cloud architecture and were beginning to look into business cases. 7% had started to create an internal cloud and 10% said they were already using an internal cloud. Those latter two numbers surprised me, actually. That's a good number of people doing serious due diligence or moving forward fairly aggressively.

One word about the attendee demographics before I continue: people paying attention to or attending a Cassatt webcast are going to be more likely than your average bear to be early adopters. Our customers and best prospects are generally large organizations with very complex IT environments -- and IT is critical to the survival of their business. And, I'm sure that we got a biased sampling because of the title of our webcast ("How to Create an Internal Cloud from Data Center Resources You Already Have"), but it's still hard to refute the forward progress. Another interesting thing to note: we had more registrations and more attendees for this webcast than the one featuring Forrester back in November. I think that's another indication of the burgeoning interest level in the topic (and certainly not a ding at Forrester or their market standing -- James Staten did a bang-up job on the November one).

Now, if it makes the cloud computing naysayers feel any better, we did get 10% of the respondents to the first polling question saying they had no plans to create an internal cloud. And, there was another 20% who didn't know what an internal cloud was. We were actually glad to have that last group at the event; hopefully they had a good feel for some basic terminology by the end of the hour.

IT organizational barriers are the most daunting roadblocks for internal clouds. At the end of Craig's section of the webcast, he recapped all the prerequisites that he mentioned and then turned around and asked the audience what they thought their organization's biggest hurdles were from the list he provided. Only one of the technical issues he mentioned even got votes. Instead, 45% of the people said their organization's "willingness to make changes" was the biggest problem. A few (17%) also mentioned problems with the willingness to decouple applications and services from their underlying compute infrastructure -- an issue that people moving to virtualization would be having as well. 5% weren't comfortable with the shifts in IT roles that internal clouds would cause.

So, despite the 17% that said they had the prerequisites that Craig mentioned well in hand, this seems to be The Big Problem: how we've always done things. Getting a whole bunch of very valuable benefits still has to overcome some pretty strong organizational and political inertia.

IT isn't sure what its servers are doing. One of the 7 steps Steve mentioned was to figure out what you already have before trying to create an internal cloud out of it. Sounds logical. However, by the look of things from our recent survey work and in this webcast poll, this is a gaping hole. Only 9% said they had a minute-by-minute profile of what their servers were doing. Instead, they either only had a general idea (41%), they knew what their servers were originally set up to do but weren't sure that was still the case (24%), or they didn't have a really good handle on what their servers were doing at all (18%). Pretty disturbing, and as Steve mentioned on the webcast, it's important to get this information in hand before you can set up a compute cloud to handle your needs. (We found this problem so prevalent with our customers that Cassatt actually created a service offering to help.)

Test and development apps are the first to be considered for an internal cloud. In the final polling question (suggested from a question I posed on Twitter), we asked "What application (or type of application) was being considered to move to an internal cloud first?" And, despite the data nightmare that would ensue, we decided to let the answer be free-form. After sifting through and trying to categorize the answers, we came up with roughly 3 buckets of responses. People were interested in trying out an internal cloud approach first with:

· Development/test or non-mission-critical apps
· Web servers, often with elastic demand
· New, or even just simple, apps

While a few people also said back-up or DR applications (you can read about one approach to DR using an internal cloud in a previous post) and some pointed to specific apps like electronic health records, most were looking to try something with minimal risk. A very sensible approach, actually. It matches the advice Steve gave everyone, to be honest (step #3: "Start small").

For those who missed the webcast, we've posted the slides on our site (a quick registration is required). Helpful hint when you get the deck: check out the very last slide. It's a great summary of the whole thing, subtly entitled "The 1 Slide You Need to Remember about Creating Internal Clouds." The event recording will also be posted shortly (to make sure you are notified when it is, drop us an e-mail at info@cassatt.com).

In the meantime, let us know both what you thought was useful (or not) about the webcast content, and also what topic we should cover in the follow-on webcast that we've already started planning. Hybrid clouds, anyone?

Is your organization ready for an internal cloud?

I'm going to take a post off from the "-ilities" discussion (Disaster Recoverability will be up next) and spend a little time talking about the technical and organizational challenges that many Fortune 1000 companies will face in their move to an internal cloud computing infrastructure.

Since I've lived through a number of these customer engagements over the past few years I thought I'd write up my cheat sheet that basically outlines the things that you need to be aware of and get worked out in your organization before you embark on a move to cloud computing. If you don't pay attention to these, I predict you'll be frustrated along the way by the organizational tension that a move such as this will cause.

Internal clouds are a game-changer on the economics front for companies that have large investments in IT. Creating a cloud-style architecture inside your own data center allows the company to unlock the excess capacity of their existing infrastructure (often locked into vertical stovepipes supporting specific applications.) Once this excess capacity is released for use within the IT environment, the company can then decrease their capital purchasing until the newfound capacity is consumed by new applications. In addition to the capital savings as a result of not having to purchase new hardware to run new applications, there are substantial power savings to the company as well, since the excess capacity is no longer powered up all the time, and is instead brought online only when needed.

Now, this sounds like motherhood and apple pie to me. Who wouldn't want to move to an IT environment that allowed this type of flexibility/cost savings? Well, it turns out that in many large companies the inertia of "business as usual" gets in the way of making this type of transformational change, even if they could see huge benefits in the form of business agility and cost savings (two things that almost everyone is looking for in this current economy to make them more competitive than the next guy).

If you find yourself reading the list below and going "no way, not in my company," then I'd posit that while you may desire the virtues of cloud computing, you'll really struggle to succeed. The limits you'll be placing on the solution due to the organizational issues will mean that many of the virtues of a cloud approach will be lost (I'll try to call out a few while I walk though the list to give you an idea of the trade-offs involved).

What you’ll need to be successful at internal cloud computing:
• Organizational willingness to embrace change. To fully adopt an internal cloud infrastructure, the system, network, and storage admins -- along with application developers -- are all going to have to work together as each group brings their specialty to bear on the hosting requirements of the application being deployed into the cloud. Also, if your organization likes to know exactly where an application is running all the time then cloud computing is only going to be frustrating. In cloud computing, the environment is continually being monitored and optimized to meet the business needs (we call them service-level agreements in Cassat Active Response.) This means that while at any point in time you can know what is running where, that information is only accurate for that instant. Why? In the next instant, something may have failed or an SLA may have been breached, causing the infrastructure to react, changing the allocation of applications to resources. Bottom line, be willing to embrace change in processes, policies, roles and responsibilities or you'll never be successful with a cloud computing solution.

• Willingness to network boot (PXE/BOOTP/DHCP) the computing resources. One of the major value propositions of an internal cloud computing approach is the ability to re-use hardware for different tasks at different times. To allow for this rapid re-deployment of resources, you can't use traditional approaches for imaging a node’s local disk (it takes a long time to copy down a multi-Gb image across the network and once done, if that node fails then the data is lost, since it resides on the local disk). Instead, the use of standard network protocols (NFS/iSCSI) allows for the real-time association of the image to the hardware. This approach also has the byproduct of allowing for very fast failure recovery times. Once a node is found to have failed, it only takes a few seconds to associate the image to new node and start the boot (we recover failed nodes in the time it takes to boot a node plus a few seconds to affect the re-association of the image to its new compute resource)

• Computing resources that support remote power management either through on-board or off-board power controllers. For all of this dynamicism to work, the internal cloud infrastructure must be able to power-control the nodes under management so that a node can be powered down when not needed (saving power) and power it back up when necessary. Most recent computing hardware has on-board controllers specifically for this task (iLo on HP, DRAC on Dell, ALOM/ILOM on Sun…) and the cloud computing infrastructure simply uses these existing interfaces to affect the power operations. If you find yourself in an environment that has older hardware that does not have this support, don't despair. There are numerous vendors that manufacture external Power Distribution Units (PDUs) that can provide the necessary power management for otherwise "dumb" compute nodes.

• Understand that your current static Configuration Management Database (CMDB) becomes real-time/dynamic in an internal cloud computing world. I touched on this under the "embrace change" bullet above, but it's worth calling out specifically. In a cloud computing world where you have pools of capacity (computing, network, and storage) that are associated in real time to applications that need that capacity to provide service, NOTHING is constant. As an example, depending on how you set up your policy, a failure of a node in a higher priority service will cause a node to be allocated from the free pool. If one is not available that matches the applications requirements (number of CPUs, disks, network cards, memory…) then a suitable replacement may be "borrowed" from a lower-priority service. This means that your environment is always changing and evolving to meet your business needs. What this also means is nothing is constant and you'll only find yourself frustrated if you don't change the mindset of static allocation.

• Understand that much of the network configuration will be handled by the internal cloud infrastructure. Now this doesn't necessarily mean your core switches have to be managed by the cloud infrastructure. However, if you want the ability to allocate new compute capacity to an application that has specific networking requirements (like a web server would have if you want it behind a load balancer), then the infrastructure must reconfigure the ports connected to the desired node to be on the right network. This issue can be a show-stopper to providing a full cloud computing solution so talk about this one early and often with your network team so they have input on how they want to architect the network and have time to become comfortable with the level of control required by the infrastructure.

• Boot image storage on the IP network. As I mentioned above, for internal cloud computing to work, you have to separate the application image from the physical node so that the image can be relocated on the fly as necessary to meet your policies. We currently leverage NFS for this separation as it can easily be configured to support this level of dynamicism. Also, using a NAS allows the leveraging of a single IP network and reduces cost/complexity as redundant data paths only have to be engineered for the IP network rather than the IP and the Storage network. I don't mention SAN for the boot device because it can be problematic to move around LUNs on the fly due to the myriad of proprietary vendor switch management APIs. In addition, every server out there ships with at least two on board NICs while SAN HBAs are aftermarket add-ons (to the tune of hundreds of dollars if you want redundant channel bonding). Now this single network approach comes with a downside that I'm going to be upfront about: currently, IP networks are in the 1Gigabit range with 10Gigabit on the horizon, while SAN networks are 2-4Gigibit (you can bond or trunk multiple Ethernets together to get better throughput, but for now we'll leave that aside for this discussion). If you have a very disk-intensive application, you'll need to architect the solution to work within a cloud infrastructure. Specifically, you don't want to be sending that traffic across to a NAS as the throughput can suffer due to the limited bandwidth. You should look to either use local tmp space (if you only need temporary storage) or locally attached SAN that is zoned to a specific set of nodes that can act as a backup to one another in case of failure.

• Applications that run on commodity hardware. Internal cloud computing provides much more benefit when the applications to be managed run on commodity hardware. This hardware could be x86, POWER, or SPARC, depending on your environment, but should be the lower- to mid-level servers. It doesn't make a lot of sense to take something like a Sun SPARC F25K and put it into a cloud infrastructure, as it is already built to address scalability/availability issues within the chassis and has built-in high-speed interconnects for fast data access. With commodity hardware comes numbers and that is where a cloud infrastructure really shines, as it dramatically increases the span of control for the operators as they manage more at the SLA level and less at the node level.

Well, that's a lot to digest so I think I'll stop now. I'm not trying to scare anyone away from moving to an internal cloud computing infrastructure. On the contrary, I believe they are the future of IT computing. The current “best” practices are, to a large extent, responsible for the current management and over-provisioning issues facing most IT shops. However, for you to address the over-provisioning and benefit from a continuously optimized computing environment where the excess capacity you have is efficiently allocated to the applications that need it (instead of sitting idle in a specific stove pipe), you need to understand the fundamental issues that stand ahead of you. In your transition to internal cloud computing you will need to actively work to address these new issues, or else you will find yourself with just a different set of problems to chase than the ones you have now.