Guide to building the enterprise cloud

There is no single guide that works, but these are the right questions to ask.

It may not be the reason someone named it Cloud Computing, but the truth is there's more smoke and uncertainty in the highly abstracted, distributed, shared-resource model of computing than almost anything else in IT right now. (BTW, higher concentrations of smoke and mirrors can be found mostly in the neighborhood of certain high-vision, low-detail IT-vendor CEOs and evangelists.)

Some of the uncertainty is inherent in a technology specifically designed to hide the servers and storage from users and lie to the hardware about what is running on it and where everything is.

On a physical server a sysadmin knows the boot sequence that supports a specific app and how well the OS microkernel and server firmware get along.

In the cloud you're lucky if you know where your data is physically stored and whether the app you're using even lives in your time zone.

Issues like those and the almost infinite variability of how "cloud" can be configured and used often confuses even IT architects who specialize in structuring uncertainty.

According to the CIOs, cloud architects, IT vendors and analysts I've interviewed, the key to cloud, as with most new technologies, is to lock down a detailed plan of what you want to accomplish first, whether that means:

  • Consolidating your physical servers into a virtual infrastructure that uses less hardware;
  • Incorporate SAAS apps into an existing virtual or traditional infrastructure;
  • Integrate SAAS apps IT recommends and implements or the host of SAAS apps business managers didn't tell you about;
  • Port some apps to run in an external cloud to give dev/testing more flexibility and resources, for example;
  • Capacity plan via "cloudburst" so you can rent extra compute or storage capacity easily when you need it;
  • Establish a DMZ computing area for partnerships or a public-infrastructure to plug in remote business units;
  • Create an internal cloud to make more efficient use of resources and make access to IT resources simpler for everyone;
  • Offload part or most of your application and/or storage load onto data center with better performance than you can afford to build;
  • or Integrate an internal/external cloud/SAAS/physical infrastructure into on effective, scalable, flexible infrastructure.

Those are categories, not project descriptions, by the way, no matter how often a cloud-service salesweasel tells you the cloud is so flexible you can implent now and change as much as you want later. You have to spec out your own project in the same mind-numbing detail you would if cloud weren't involved, no matter how simple some cloud advocate tells you it will be.

Once you have everything spec'd out, then you can design the internal/external data pathways and system connections needed to deliver on them, and decide on an app-by-app basis which would work better on the new platform or the old.

The most important part of the rest of the implementation isn't actually doing the work. It's making sure the contracts you sign with SAAS and cloud providers require them to deliver what you actually want them to deliver, not just generic promises about the dynamic availability of resources.

Detailed guidelines useful enough for you to plop them into your own plans are difficult to come by, but you can get to the same place by asking the right questions.

Here's a list of some of the questions that will cause trouble if you don't get good answers, risks you may not be sufficiently aware of, and ways to mitigate both.

Ad hoc course on cloud implementation:

What’s wrong? The new clean desk test
Join the discussion
Be the first to comment on this article. Our Commenting Policies