Why private cloud will make IT think like Wal-Mart

Public. Private. Hybrid. Cloudburst. Much of the discussion about cloud computing focuses on deployment options and choices, with a surprisingly large number of enterprises inclining toward internal private clouds-that is, a cloud-capable infrastructure residing within a company's own data center.

A just-published survey by Evans Data supports this trend, indicating that 30 percent of developers (sample = 500) are currently working on projects that will run in private clouds (Important: the article notes that this is probably skewed, as the survey participants are self-selected). This seems quite high to me, given that the number of actual private clouds is pretty darn small. However, one can design and build an app in a public cloud environment with the ultimate goal of hosting the app in a private cloud. In any case, the survey reinforces an anecdotal sense that enterprises are very attracted to the concept of building and operating their own cloud.

It's easy to understand the attraction of a private cloud: it bypasses issues of security and uncertainty associated (fairly or not) with public cloud providers like Amazon, while offering tangible cloud benefits like agile deployment and easy scalability. In a sense, a private cloud offers the best of both worlds: safety and innovation. I did a series of posts on private clouds a few months ago that discussed the topic at length. In this post, I want to focus on one very important topic regarding private clouds: the supply chain.

If you look at the chart that accompanied my private cloud postings, you'll note a dark black dotted line that demarcates application groups (cloud consumers) and IT operations (cloud providers). It illustrates and symbolizes the fact that the working relationships between these two groups will change with the advent of private clouds.

Today, the process of provisioning internal compute resources is an extended, manual process punctuated with meetings, emails, telephone calls, etc. Application groups discuss (i.e., signal) their resource requirements well ahead of need for the resources, allowing plenty of time for operations to (if necessary) order equipment, install and configure server resources, connect and configure storage, and finally make the compute resources available to the application group. In many companies, IT operations has no independent budget for capital equipment; rather, hardware procurement is tied to application demand. A new application needs hardware, the cost is placed in the app's project budget, and money is transferred to the infrastructure group (after, of course, many emails, phone calls, etc.) for actual purchase and emplacement.

You probably noticed that the current process-manual and extended timelines-does not align very well with the cloud vision of resource provisioning as automated and near-real time. In fact, one could say that the clamor for private clouds is rooted in frustration with current provisioning timeframes that can extend to weeks, if not months.

What does this have to do with supply chains?

Most everyone is familiar with the concept of a supply chain-an interlinked vector of individual participants who cooperate to satisfy end user demand. In retail, for example, Wal-Mart capitalized on its supply chain efficiencies of coordinating product sourcing, transportation logistics, and sales data feedback to fuel its leap to biggest retailer in the world. Many of us in the tech industry are familiar with the analogous chain that ties together ODM (Original Devices Manufacturers like HTC), transport firms, product designer (e.g., HP), and retail outlets-all coordinated to deliver a, say, server to an IT operations group so that it can install it in response to demand from an applications group.

But I'd like to posit that in cloud computing, particularly the private variant, another supply chain exists, one based on virtual resources within the data center. In this supply chain, demand emanates from a member of an applications group who (in the vision of cloud computing) fills out a web form that identifies type and amount of resources, (e.g., two virtual processors, so much memory, network connectivity, storage, and so on) clicks the submit button, and, voila, compute resources appear, ready to use, in a matter of minutes. It is the job of IT Operations to emulate Wal-Mart and coordinate sourcing, logistics, and shelf (or in this case, rack) stacking to ensure sufficient resources are available to meet application group demand.

Page Break

I think this is going to pose some challenges to IT operations, and, by extension, to IT organizations that want to implement a private cloud.

Here are a few of the interesting challenges this resources-in-a-jiffy pose:

Reduced demand signal insight In today's processes, an application's group's need for compute resources is signaled well ahead of time, allowing the Operations group sufficient time to procure and provision resources. While manual and slow, these processes enable overall demand to be assessed, prioritized, compared against available funding and implemented (and, by the way, did you see that Gartner and Forrester noted that IT spend was being further revised downward for 2009? Bet there's going to be plenty of angst about this in provisioning meetings!)

By contrast, the "submit and get" cloud provisioning model totally removes those processes, allowing applications to make immediate demand upon Operations infrastructure and-crucially-removing insight about likely demand patterns previously discerned via the manual processes. Wal-Mart forecasts demand via real-time checkout data, married to insights gleaned from examining historical consumption patterns: e.g., it sells a lot of candy around October 15, year-in and year-out. IT operations has less historical data, and demand for compute resources is likely to be more unpredictable, especially over the next few years as initial private clouds are implemented.

Increased demand As resource provisioning becomes easier, more resources will be demanded. Classical economics focuses on price and asserts that reduced costs are associated with increased demand (called price elasticity). Cloud computing is often characterized as less expensive than traditional provisioning models, although there is some controversy about that. No controversy exists, however, about the fact that cloud computing makes it easier to obtain compute resources. The manual processes outlined earlier have the effect of introducing friction into the provisioning process; with cloud computing the process is much smoother and easier. When it becomes easier to do something, people generally do more of it. This translates into increased demand for compute resources in private clouds, over and above migrating the established resource consumption patterns already established in the previous manual domain.

Need for rationing mechanism Given increased demand and a fixed amount of resources, how will those resources be allocated among competing demands? This verges on the concept of chargeback, which is rather controversial within cloud computing. Some assert that the billing arrangements of how cloud computing is paid for is a mere detail; others asset that the concept of charging for resource use if fundamental to the concept. If one accepts that demand will increase and that capacity is fixed (at least in the short term), it's likely demand will outstrip supply and some mechanism is needed to mediate demand. Those who maintain that actual monetary chargeback is not necessary tend to support usage reports, indicating how much compute capacity has been consumed. My belief is that there will be a lot of pressure to move to actual chargeback, not least because the public cloud providers offer it; application groups will maintain that the internal cloud should offer as much transparency and immediate feedback as a public cloud. A different tack would be to place limits within the provisioning process, preventing people from requesting too high a level of resources or forcing them to get a signoff, etc., but doesn't that sort of negate the whole purpose of cloud computing?

Pressure on IT Operations capacity planning Nobody wants a "404" when they press the "submit" button requesting resources. This pressure is the logical companion to reduced demand signaling and increased overall demand: Operations is going to have to make sure that they manage the underlying compute infrastructure so that resources are always available when requested. Even if a rationing mechanism is in place, the consumption signals it sends (an invoice or a usage report) are retrospective (i.e., they report on previous month's use) and don't help at the moment of truth when someone requests resources. IT Operations will come under significant pressure to always have sufficient compute resources available. This doesn't get discussed much, but expect it to be a hot topic in the future regarding private clouds. Of course, this is a challenge for all cloud providers, as they all promise what the UC Berkeley RAD Lab Report calls "the illusion of infinite resources." Amazon is characterized as having trouble with this issue, so it's not unique to private clouds; however, this problem may be more acute for private clouds, since this skill is, today, not that prepared.

Changed budget practices So where is the CAPEX? Much of the enthusiasm for cloud computing focuses on the shift of payment structures for cloud users. Instead of having to pay for a capital asset (so-called CAPEX), users instead pay only for the compute services they consume (so-called OPEX). This is great, but neglects to recognize that someone, somewhere, has to spend the CAPEX so that cloud users can enjoy paying via OPEX. In the case of internal clouds, this means that the IT organization will have to make the CAPEX investment. One difficulty with this is that, today, common budget practices are that application projects fund capital expenditure; when application groups need only pay for actual usage, capital will not be allocated to apps nor transferred to Operations to fund equipment acquisition. This means that capital investment will need to be directed away from applications and toward IT Operations. Obviously, this represents changed practices and the next couple of years should be interesting as the implications of the budget shifts are explored.

Overall, one might say that the functionality of a cloud environment will need to be matched by changed processes. This means that not only are products (e.g., vSphere) involved, but so is the dread word: re-engineering. It makes sense, because every innovation that is disruptive, as cloud computing is so often characterized, well, disrupts things. And, as I noted in a recent posting, disruption is messy thing with lots of organizational angst. The disruption is inevitable and necessary; usually, the only question is whether one embraces it as a so-called early adopter, or impedes it (laggard). In the end, however, disruption arrives, whether bidden or unbidden. The IT supply chain is under pressure to adapt and adapt it will.

Bernard Golden is CEO of consulting firm HyperStratus, which specializes in virtualization, cloud computing and related issues. He is also the author of "Virtualization for Dummies," the best-selling book on virtualization to date.

Follow everything from CIO.com on Twitter @CIOonline