Who needs a private cloud anyway? Part 1 - Self Service IT

  • warning: Parameter 1 to texy_image_texy_handler() expected to be a reference, value given in /usr/share/drupal6/includes/module.inc on line 482.
  • warning: Parameter 1 to texy_syntaxhighlighting_texy_handler() expected to be a reference, value given in /usr/share/drupal6/includes/module.inc on line 482.
  • warning: Parameter 1 to texy_texy_settings() expected to be a reference, value given in /usr/share/drupal6/includes/module.inc on line 482.
  • warning: Parameter 1 to texy_image_texy_settings() expected to be a reference, value given in /usr/share/drupal6/includes/module.inc on line 482.
  • warning: Parameter 1 to texy_syntaxhighlighting_texy_settings() expected to be a reference, value given in /usr/share/drupal6/includes/module.inc on line 482.

In my last blog, I tried to explain what is Canonical's strategy regarding cloud computing.  A few people (they'll recognize themselves) got back to me asking why they would use a private cloud.  They found the idea really "cool", but could not see how they could use it.

As with all new technologies, there is always a very big chance that there will be a disconnect between what the people putting some tool together think they are addressing and what the "real" people end up doing with it. Chances are  that what I describe below is not what people will really end up using it for, but I have none the less decided to start a series of blog posts where I'll try to describe quickly some of the possible scenarios that I think makes a private cloud useful. I'll start today with the concept of self service IT.

Part 1: Self-service IT

I am quite sure a few of you have worked in a large IT department, and if you have, do you remember how painful it was to react to requests such as:

  • "Our marketing manager needs us to put together a mockup of our next great service: we need 3 machines ready to do this by tomorrow"
  •  or "Our recent audit reported that we could have a very quick win in the finance department by offering an internal service that would allow users to share virtual post-its, we need a machine asap to build it on".

In general, this types of requests would take from a few hours to a few days for a technician to:

  • order and then set up the new hardware,
  • install a base os,
  • configure the security on it
  • and create the accounts.

A lot of it could be automated, particularly the install part, but it would still take time away from doing other much more interesting tasks.

The larger your organization becomes, the more frequent this type of urgent requests are, to the point where some very large ones have dedicated a few technicians to it.  Since this type of requests have a tendency to pile up and group themselves toward the end of the quarter, they also generally lead to some dissatisfaction of the requesters, as it takes way too long.  The IT department is then pointed at as being the blocker...

A first response to this type of need was to use some type of virtualization technology to setup virtual servers instead of real hardware when such requests came in.  Quite cool, but it only allowed to reduce the number of idle computers and save on hardware.  The actual set up time would remain the same, and user statisfaction would remain quite low.

Since the first public cloud computing offering where made, a lot of companies have started to use it to build their mockup or quick win project, and are coming to the point to make it a standard policy. But then the security officer kicks in and tells everyone that it is crazy to put confidential data/projects/whatever outside the firewall.

This is one place where the private cloud makes a lot of sense. Using a private cloud technology, such as Ubuntu Enterprise Cloud, organizations can now put together:

  • a pool of hardware inside the firewall,
  • a set of standard base images that should be used,
  • and provide a simple web interface for their internal users to create instances on the fly.

The results should be drastic:

  • no more wait for the machine to be set up,
  • no more technician time consumed on setting up new machines,
  • and a lot less idle servers piling up in the server room,

suming up to a pretty quick return on investment.

Of course someone will still need to add new hardware to the pool once resource usage gets to some threshold but as the adding a node to the pool is a very standard operation (all the nodes are configured exactly the same way). It can be done quite fast, with very little overhead and be very easily automated, and will be made even easier in Ubuntu 9.10 Server Edition (karmic).

So, what do you think? Could your organization benefit from such a self service private cloud? I'd love to hear from you whether you agree or disagree.

Stay tuned for Part 2, where I'll describe the concept of "on demand offload".

Share this

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I See It. And, I Need It...

…as part of an innovation platform we're prototyping for the U.S. Army.

http://kitplummer.github.com/…the-dod.html

Are we aligned?

Very much. Please let me

Very much. Please let me know how it goes.

Policy

Ofcourse there is a bit of security risk in letting the (l)users activate server instances on their own… So a policy in using this private cloud should be also a part of this in every company.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.