Private Cloud Build-Out: 4 Prerequisites

As we've discussed previously, software-as-a-service, engineered stacks and private cloudwill be the biggest IT winners in the next five to ten years. Private clouds hold the most potential -- in fact, early adopters such as JP Morgan Chase and Fidelity are seeing larger savings and greater benefits than initially anticipated.

While savings is a key reason to move to a private cloud, shorter development cycles and faster time to market are more significant. Organizations can test risky ideas more easily as small, low-cost projects, quickly dispensing with those projects that fail and accelerating those that show more promise.

Meantime, early implementations at scale are producing savings well in excess of 50%. This is well beyond my earlier estimate of 30% savings, occurring in large part because of the vastly reduced labor requirements to build and administer a private cloud versus traditional IT infrastructure.

[ What does the proliferation of cloud services mean to your IT organization? Read IT As Cloud Service Provider: New Skills Required. ]

Given those potential benefits, how should an IT department go about building a private cloud? The building blocks are virtualized servers running on commodity hardware. There's also a strong early trend toward leveraging open source software for private clouds, from the Linux operating system to OpenNebula and Eucalyptus for infrastructure management. And of course, you need server engineering and administration expertise to support the platform. But having just a virtualized server platform doesn't a private cloud make.

First, establish a set of standardized images that constitute most of the stack. Preferably, that stack will go from the hardware layer to the operating system to the application server layer, and it will include systems management, security, middleware and database. Ideally, go with a dozen or fewer server images and certainly no more than 20. Consider everything else to be custom and treated separately and differently from the cloud.

Second, build a catalog and ordering process that's easy to use and whose costs are clear.

Third, couple the catalog with highly automated provisioning and de-provisioning. Your objective should be to deliver servers quickly -- certainly within hours, preferably within minutes (once your customer authorizes the costs). De-provisioning should be just as rapid and regular. In fact, you should offer automated "sunset" servers in test and development environments (e.g., after 90 days the servers automatically get returned to the pool).

Fourth, do clear cost and allocation reporting to drive the right user behaviors. Such reporting will encourage rapid adoption, more efficient usage and rapid decommissioning.

With these four prerequisites in place, you're ready to start your private cloud.

Global CIOs: A Site Just For YouVisit InformationWeek's Global CIO -- our online community and information resource for CIOs operating in the global economy.

Build your private cloud in parallel with your traditional data center platforms. Build both a development and test private cloud and a production private cloud. Seed the cloud with an initial investment of servers of each standard type. Transition demand into the private cloud as new projects initiate, and then proceed project by project.

Speeding up provisioning should shorten development times. Begin by routing small and medium-size projects to the private cloud environment, and as you amass scale and work out the provisioning kinks, migrate more and more server requests until nearly all of them are routed through your private cloud.

As you achieve scale and prove out your ordering and provisioning (and de-provisioning) processes, tighten the criteria for projects to proceed with traditional custom servers. Within six months, custom servers should be the rare exception and you should charge fully for the excess costs they generate.

Once you've established the private cloud, verify the cost savings and advantages. Armed with that data, circle back to existing environments and legacy servers. A good time to transition to a private cloud is during another event (e.g., a major application release or end-of-life server migration). A few early adopters are seeing outsized benefits and a strong developer push into these private cloud environments. So if you build yours well, you should reap the same advantages.

How is your private cloud journey proceeding? Are there other steps necessary for success? I look forward to hearing your perspectives in the Comments section below.