In the last post, we defined the cloud. This post delves into cloud construction at a conceptual level.

It’s important to talk about the structure conceptually before diving into the nuts and bolts. The reason is that your cloud will evolve over time, in terms of the immediate objectives, the technologies you use, and your expectations. Looking at the concepts now will make it easy to see which technologies go where. And you can see how each element lays the foundation for your long term vision — while also delivering immediate value.

We can think of the cloud in three layers. Each layer offers unique functionality, and each builds towards the five defining cloud attributes discussed in the last post. But as with any layered model, each layer relies on the foundation created underneath.

Flexible architecture: The most fundamental layer is the flexible architecture. But this is really vague — what does “flexible” mean? One definition might be, “an infrastructure that can be adapted in real time to changing requirements.” But this needs more specificity to avoid a classic vendor-speak trap; if an architecture can be changed, but it takes multiple hours (or multiple people, or involves a trip to the data center), is that considered flexible?

A few defining points make “flexible” a little more tangible.

1. No silos: Here’s a quick test: are apps tied to particular servers or groups of servers, either due to storage connections, network connections, or server performance? If so, then it’s not a cloud. Some limits are obviously tougher to work around than others (legacy apps that don’t run on your newer processors, for example), but the idea is to break down the walls that limit flexibility.
2. Lights out: If you need to go to the data center for anything other than break-fix, or to scale your infrastructure, it’s not really a cloud.  Everything else should be software controlled.
3. Any to any connectivity: It’s not a cloud if every server cannot be configured with access to every network or storage asset. This does not mean everything is connected to everything all the time. There are certainly good reasons why you wouldn’t want that. But it means that you strive towards an environment where you can configure access entirely in software when you need it.
4. Rapid scalability: If adding gear is a major undertaking, it’s not a cloud. In complex data centers, adding gear may require substantial advance planning. In which case you’d be irresponsible to not have a lot of capacity headroom. But that lead time then means reduced utilization. If you could add servers in, say, two hours — from dock to production – you’d be more likely to run your operation closer to its limits, and therefore become more efficient.
5. Common elements: If you have substantial variation among gear (to the point that you cannot employ a common management model) it’s not a cloud. The ultimate goal is automation which  requires some commonality in how all the pieces are managed.

Processes: The next layer defines the process by which the first layer is managed. What happens when a user needs a new service, or requires a new service level for an existing service? How do you respond when something fails, or you’re running out of a resource? As much as possible, responses should be a series of software actions that can be easily implemented and perhaps automated.

Another key process is of course monitoring. How much of your resource pool is being used? And who’s using it? This type of monitoring can bring two wins: you’ll know your efficiency, and you can justify IT costs based on user demand.

Automation: Ultimately, automation will come into play as you adopt self-service models for the most commonly used processes. What you automate will depend on your users needs and your management needs. But by building on the first two layers, you have the ability to change things in software. And you’ll have the methodology to quickly design, implement, and get paid for the services that your users need.

Public vs Private Cloud

The cloud has spawned a variety of hybrid concepts, but for this purpose, two models will suffice: the public and private clouds. They serve this purpose because they’re pretty much the extremes. “Public cloud” means everything goes on outside your data center, a concept that today may be difficult to accommodate with most day-to-day IT workloads. Renting a server or cage in a colo is one thing — you’re still in control. But putting your data out into an amorphous cloud is entirely another.

The “private cloud” means that cloud concepts are implemented inside your own shop. For several reasons, this is a great starting point and can, as Gartner points out, serve as an ideal steppingstone to the public cloud. Why?

First, you’re reaping a substantial portion of the cloud benefits.  Think about why a cloud makes sense, and then consider how many of these concepts would be useful in your own environment:

• Right-sized, not oversized: Add resources quickly to help maximize resource utilization
• Grow on demand: When you can scale quickly, you can respond to change rather than building in excess capacity
• Service-based: With defined performance and availability SLAs
• Highly virtualized: Truly interchangeable resources

Second, by developing the private cloud, you’re actually designing in the tools and processes that will accelerate the transfer of specific workloads to the public cloud when it makes business sense.

So far, we’ve covered what the cloud is, and what constitutes the cloud at a conceptual level. Next time we’ll start on the hardware and software building blocks, and strip away the hype and breathless hyperbole that some attach to their solutions.

Tags: cloud

This entry was posted on Tuesday, March 9th, 2010 at 3:55 PM and is filed under cloud. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.