Blogs

Tony Pearson is a Master Inventor and Senior IT Architect for the IBM Storage product line at the
IBM Systems Client Experience Center in Tucson Arizona, and featured contributor
to IBM's developerWorks. In 2016, Tony celebrates his 30th year anniversary with IBM Storage. He is
author of the Inside System Storage series of books. This blog is for the open exchange of ideas relating to storage and storage networking hardware, software and services.
(Short URL for this blog: ibm.co/Pearson )

My books are available on Lulu.com! Order your copies today!
Featured Redbooks and Redpapers:

Safe Harbor Statement: The information on IBM products is intended to outline IBM's general product direction and it should not be relied on in making a purchasing decision. The information on the new products is for informational purposes only and may not be incorporated into any contract. The information on IBM products is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described for IBM products remains at IBM's sole discretion.

Tony Pearson is a an active participant in local, regional, and industry-specific interests, and does not receive any special payments to mention them on this blog.

Tony Pearson receives part of the revenue proceeds from sales of books he has authored listed in the side panel.

Tony Pearson is not a medical doctor, and this blog does not reference any IBM product or service that is intended for use in the diagnosis, treatment, cure, prevention or monitoring of a disease or medical condition, unless otherwise specified on individual posts.

Of course, EMC isn't the first, and won't be the last, vendor to [hear the sirens] of Cloud Computing and crash their ships on rocky shores. Just because you manufacture hardware or write software does not guarantee your success as a Cloud service provider.

(FTC disclaimer: I work for IBM. IBM is a successful public cloud service provider, as well as offering products that can be used to deploy a private, hybrid or community cloud, and provides technology to other cloud service proviers.)

An amusing excerpt from Steve Duplessie's post:

"Side Note: There is no such thing as a private cloud. A private cloud is called IT. We don’t need more terms for the same stuff."

I have to agree that when vendors like EMC say "Journey to the Private Cloud", skeptics hear "How to keep your IT administrator job by sticking with a traditional IT approach". Butchers, bakers, candlestick makers and the specialty shop "arms dealers" of Cloud Computing IT equipment may not want to see their market shrink down to a dozen or so service providers, and drum up the fear that "Public Cloud" deployments will "disintermediate" the IT staff.

But does that mean the use of term "Private Cloud" should be discontinued? The US National Institute of Standards and Technology [NIST] offers their cloud model composed of five essential characteristics, three service models, and four deployment models. Here's an excerpt:

"Essential Characteristics:

On-demand self-service

Broad network access

Resource pooling

Rapid elasticity

Measured Service

Service Models:

Cloud Software as a Service (SaaS)

Cloud Platform as a Service (PaaS)

Cloud Infrastructure as a Service (IaaS)

Deployment Models:

Private cloud.

Community cloud.

Public cloud.

Hybrid cloud"

Like traditional IT, a private cloud infrastructure is operated solely for an organization, so I can see how many might consider the term unnecessary. However, unlike traditional IT, a private cloud may be managed by the organization or a third party and may exist on premise or off premise.

How many traditional IT departments meet the five essential characteristics above? Instead of "on-demand self-service", many IT departments have complicated and lengthy procurement and change control procedures. A few might have "measured service" with a charge-back scheme, and a few others prefer to use a "show-back" aproach instead, showing end users or managers how much IT resources are being consumed without assigning a monetary figure or other penalty. Rapid elasticity? Giving any resource you asked for back can be just as painful because re-purposing that equipment follows the same complicated and lengthy change control procedures.

Just like the term "intranet" refers to a private network that employs Internet standards and technologies, I feel the term "private cloud" is useful, representing an infrastructure that meets the above criteria, employing Public Cloud standards and technologies, that can distinguish itself from traditional IT in key ways that provide business value.

What I do hope "vaporizes" is all the hype, and all the misuse of the Cloud terminology out there.

Continuing my coverage of last week's Data Center Conference 2009, I attended another "User Experience" that was very well received. This time, it was Henry Sienkiewicz of the Department Information Systems Agency (DISA) presenting a real-world example of the business model behind a private cloud implementation. DISA is the US government agency that develops and runs software for the Army, Navy and Air Force.

Being part of the military presents its own unique set of challenges:

Acquisition of hardware to develop and test software is difficult

Budgets fluctuate so an elastic pay-for-use was desirable

End user access had to be secure and meet government regulations

It had to meet the technical aspects of scalable, elastic, dynamic, multi-tenant using shared resources

Using Cloud Computing simplifies provisioning, encourages the use of standards, and provides self-service. DISA has several solutions.

Rapid Access Computing Environment (RACE)

RACE is an internal private cloud with 24-hour provisioning for development and test requests, and 72 hour provisioning for production requests. The amount used is billed on a month-to-month basis, and offers a self-service portal so that developers and administrators can just pick and choose what they need. The result is a hosted server, similar to what you get from 1and1.com or GoDaddy.

Global Content Delivery Service (GCDS)

This provides long-term storage of data. An internal version of "Cloud Storage" for archive and fixed content.

Forge.Mil

This provides a place to maintain source code, basically their internal version of "SourceForge" used by Open Source projects.

In their traditional approach, a software project would take six months to procure the hardware, another 6-12 months code and test, and then another 6 months in certification, for a total of 18-24 months. With the new Cloud Computing approach that DISA adopted, procurement was down to 24-72 hours with RACE, code test took only 2-6 months with Forge.Mil, and certification could be done in days on RACE, resulting in a new total of only 3-6 months. Some challenges they found:

Service Level management and continuing the use of ITIL best practices

Balancing Military-level Security with Self-service Usability

Internal Funding and Chargeback, they had even adopted a way for developers to pay with their credit card

Cultural inertia, developers don't like to change or do things in a different way

Controlling expectations

Some lessons learned from this two-year experience:

It's a journey. Most of the user experiences for cloud adoption took two or more years to complete

Infrastructure Fundamentals continue to matter

Know your "marketplace", in this case, software development for military applications

Engage in your end-users early. In this case, Henry had wished he had involved input from software developers that would be using RACE, GCDS and Forge.MIL earlier in the process.

Return on Value analysis, this is different than Return on Investment, as many of the benefits of cloud like higher morale are intangible at first

Avoid fixed costs in negotiations with vendors. For example, he cited they use a lot of IBM because of IBM's pay-for-use billing model. They pay for MIPS used on IBM mainframes, and their IBM Tivoli software pricing is usage-based.