Before You Build Your Own Private Cloud

Cloud is a HUGE marketing term right now. I hear it thrown around all the time. I hear some companies saying they want it even though they don’t know what they would do with it, and I hear others who seem scared of it. This entry will be at a very high-level and covers topics relevant to IaaS clouds.

Topics

First, what is a good definition of cloud computing?
NIST provides what I consider a good definition:

"Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."

Cloud vs virtualization

I have heard people ask how cloud is different from using VMware. I usually respond with “VMware only provides virtualization, which is only part of what you need for cloud computing.” I know VMware has a product called vCloud… I’m not talking about this, just the ESX hypervisor and vSphere/vCenter. A simple equation I use to explain cloud is:

Cloud = Virtualization + Automation
  • Automation
    • Cloud is all about speed, agility, and efficiency.
    • Cloud: Every function has an API that can be used by end users or applications
      • Starting/Terminating VMs
        • 1 to 2 minutes, not hours or days
      • Configuring the network instantly (IP assignment, firewall, etc)
      • Storage creation and allocation
      • These APIs make automated elastic scaling possible
    • VMware/vSphere provides none of the above to end users
      • All functions must be carried out by a VMware administrator (middleman)
      • An end user must call or email a VMware administrator to request VMs
        • Lucky to receive VMs within a few hours, sometimes days
      • Automatic elastic scaling is not possible
  • Insight and Transparency
    • Cloud
      • End users can see exactly how many, what types (OS), size of VMs they are running.
      • How long each VM has been running.
      • Create and manage their own VM image library (snapshots/templates).
      • Create/snapshot their own VMs.
    • VMware provides none of the above insights and transparencies to end users
      • This kind of information is only available to the VMware administrators.

Legacy Applications

Cloud is not meant to be used as a static environment, it is meant to be very dynamic and automatically adjust according to application needs such as traffic spikes, increasing work loads, etc. If your distributed system has N number of machines in it and that number of machines never changes then there is probably not a good reason to move that application into a cloud infrastructure. If your applications can’t or don’t take advantage of the benefits of cloud, such as elastic scaling, then those applications probably won’t see a great benefit by moving them into the cloud. Legacy applications usually aren’t architected in a way that allows them to benefit from running in a cloud.

Running commercially licensed software (COTS) in a cloud

Licensed commercial software can be very difficult and cumbersome to use effectively in a cloud in order to leverage cloud dynamics. Commercially licensed operating systems and software can make cloud dynamics a lot harder to achieve. Most licensed software that requires license keys or some form of licensing that can’t be managed in a totally automated fashion doesn’t make good sense to use in a cloud. Trying to figure out a way to apply licenses to VMs that may only live for a couple hours and them reclaim the license when the VMs are shutdown can really make things difficult to manage and track license usage. This is why open source applications and software is such a good fit in a cloud, you are free to start and run as many VMs as you want running open source software and you don’t have to worry about figuring out how to apply, manage, and track licenses. I think if Amazon released a breakdown of percentages on what operating systems are used throughout Amazon that Linux would be the overwhelming winner, probably being used around 90% or more (dare I say 99%…).

More on COTS

Commercial software solutions and their license expenses are NOT balanced by lower integration and support costs. Most COTS were not built with cloud infrastructures in mind, they generally lack:

  • Flexible licensing
  • Multi-tenant support
  • Automation support
  • Scalability
  • Resilience

Before building your private cloud talk to…

If you are thinking of, or planning to build a private cloud and you aren’t talking to your software engineers or developers who will be using it you will probably end up building something they won’t want to use or won’t fit their needs. The biggest users of cloud will be your software engineers and developers who will be building the new cutting edge applications that really take advantage of everything cloud offers for high availability, elastic scaling, and self healing. If you aren’t talking to you software teams when planning how to build your cloud infrastructure you are making a major mistake. (I may be biased since I’m a software engineer…) Also, make sure your “cloud team” is attending multiple cloud computing conferences and is involved in the cloud community.

Test the waters first before betting the farm

Don’t plan on diving in head over heals straight into a large scale cloud infrastructure build out without first starting small to learn what works and what doesn’t work… or you will likely fail. Don’t rely on a vendor or partner company to tell you what you should buy and build without testing the “solutions they are selling” first and fully understand repercussions of your choices. There are a lot of vendors who practice what is known as “cloud washing”, which is the simple act of rebranding existing products, services, and technologies to capitalize on cloud marketing trends. Make sure you have someone who will know if and when the BS flag needs to be pulled.