Cloud Architecture (Part 2) – Resource Pool

This post is part two of a five part series of posts on what should be designed into any cloud architecture. In this post, I will be going into some detail on the resource pool layer of a cloud architecture.

Part 1 can be found here and the entire series will be grouped under the Cloud Architecture category.

Infrastructure Reference Architecture

Within the vast majority of datacentres, there exists the following components:

  • Application software
  • Servers
  • IP Network infrastructure and software
  • Storage (SAN, direct attached, internal)
  • Data protection infrastructure (backup and archive)
  • SAN infrastructure
  • Security appliances
  • Identity management Infrastructure

A cloud architecture will have the same components with three major differences:

  1. Each part of the architecture is tightly integrated with the other parts – Typically, the layers at the top of the diagram above will have some “knowledge” of the layers below
  2. The layers in the diagram above can be hosted in the cloud rather than within an organisation’s datacentre. This means that the identity management function must have the ability to federate
  3. Each of the layers in the diagram above must support the 5 characteristics of the cloud individually

A number of large vendors are now offering converged infrastructure where all of the layers above are developed and soled in one package that already has the tight integration and is certified to work with all of its components. A good example is the Vblock that is being offered by VCE (a joint venture between VMware, Cisco and EMC).

The stack shown above, if implemented well, will bring benefits in the ability to provision parts of the infrastructure quickly and will move an organisation towards being able to holistically manage their infrastructure. Services that are built on a stack like the one described in this post, will also have the ability to move services onto public clouds that support the components (e.g. if VMware is the virtualisation provider in this stack, virtual workloads can be moved onto a supported virtual infrastructure in a public cloud).

The challenge, which I will go into in part 3, is how to orchestrate the entire stack and apply functions across the whole infrastructure such a charge back and monitoring.

Sharing Options

  • Twitter
  • LinkedIn
  • Google Plus
  • Facebook
  • Reddit
  • StumbleUpon
  • Delicious
  • Email

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>