Education labs and classrooms are excellent use cases for private cloud

Not surprisingly, since the release of my new book, Visible Ops – Private Cloud, I have been talking with a lot of people about how to deploy private cloud, where to start, what to avoid, etc. So far, the most common question has been, “What type of existing workloads are organizations putting into private cloud environments today – and what are they avoiding?”

So I thought I would jot down some of my answers, specifically related to ‘cloud-migrant’ services, as opposed to ‘cloud-native’ services – and without getting too hung up on whether the use cases are 100% cloud or not!

One recurrent use case is to provide dynamic desktop allocation, especially for education and projects use cases. A number of schools, universities, training centers, and even some larger enterprises, have adopted private cloud to allocate servers, clients, applications and data for reusable desktop systems.

This seems especially prevalent for short-term learning facilities, repeatable one-off classroom systems, training/demo labs at conventions (or user groups), and contractor setup. It is also similar to the executive briefing centers and ‘demos on demand’ that many software sales organizations (like CA Technologies) use.

Another service-based use case I have seen in several universities is self-service access for students and faculty, using pooled resources, not only for application services but also for full VDI desktop allocation.

I have seen this in other enterprises too – most notably for home-source process workers (e.g. call center, data entry) – but mostly as a proof-of-concept, not a large-scale production deployment.

However, most cloud-migrant workloads I see deployed to private clouds today still tend to be server-based. Most of these are at ‘Phase 1′ in the Visible Ops Private Cloud – a reorientation of virtualization deployments to pilot a private cloud that works, proving results, gaining skills, and hopefully measuring opportunities. It is still focused on servers, not services, but provides a vital part of the learning curve toward private cloud.

For example:

• Dev/test/QA servers – 3-tier LAMP stacks (app/Db/WS), but also LAMP components, IDEs, source code management tools, etc. (which often results in applications that run on a private cloud in production)
• Collaboration servers – especially SharePoint, but also Web-based collaboration services like team chat servers, content repositories, blogs, wikis, and project management tools
• Engineering servers – I have seen a number of engineering firms move their design project systems (especially CAD tools) into private clouds so engineers can fire up new design projects on-demand
• Web servers – popular for marketing teams who can fire up their own Web servers, especially for short-term and/or localized promotions & campaigns
• Analytics servers – short-term number crunching of ‘big data’ (including BI applications) in medical research, social marketing, pharmaceutical research, higher education, financial, logistics, etc

The workloads that are less suited to private cloud deployment are harder to identify, because it requires positive evidence of absence, so my thoughts here are much more anecdotal. I do see CIOs push back on migrating ‘core’ applications, even to private clouds, citing lack of confidence, performance concerns, potential security and compliance issues, and lack of ROI. I would not agree these are always good reasons, but they can be, and are certainly understandable.

In my opinion, private cloud is not ideally suited to relatively large, static, predictable, and resource-saturating workloads – think ERP or Data Warehouse. After all, used internally such applications are almost never deployed ‘on demand’; they are rarely if ever ‘multi-tenant’; they have no real benefit from an ‘infinitely scalable’ infrastructure; and are mostly viewed as a cost of doing business, without any ‘resource measurement’ or chargeback.

(btw, there are certainly good arguments to deploy these applications on a public cloud, as ‘cloud-native’ services using SaaS, to outsource them to a non-cloud third-party, or to just virtualize them – even with 1:1 virtualization – without the other trappings of cloud. Such alternatives could deliver better cost savings, higher up-time, faster DR, and other benefits. However, I think the upside of putting such applications in a private cloud is less apparent.)

That said, I do think that we will see more and more strategic services – as opposed to project servers – deployed in both private and public cloud as it matures. In fact, recent IDC data suggests CIOs that are adopting private cloud will migrate many core applications in the coming years. Moreover, some of the more advanced customers I talk with are already doing this, although they are by far in the minority.

Either way, I will be very interested to see how this all pans out.

What do you think? What have I missed? What types of workloads do you see being deployed in a private cloud? What are CIOs passing over in their evaluations? Are they right, or wrong? What criteria should they use?

Please feel free to continue the discussion in the comments below, or hit me up on Twitter with your ideas.

This post was originally published on the CA Communities website.

I have been talking with many CIOs for some time about strategic adoption of cloud solutions. A key step in these conversations is always the review of the portfolio of services they provide to business users, so they can choose which clouds to adopt and why.

This has led me to describe a high-level taxonomy that segments the service portfolio according to the different cloud requirements, capabilities, and approaches in different types of applications and services.

Essentially, this work has segmented most (all?) service portfolios into four areas, which (roughly) follow the adoption curve of cloud computing

Cloud Service Taxonomy - Cloud-Free, Cloud-Migrant, Cloud-Native, and Rogue Cloud

Cloud-Free Services

For most of the large enterprises I talk to, some services will not be part of any cloud. These ‘cloud-free’ services may migrate from physical to virtual, but do not need elastic scalability and self-service, are too impractical or incomprehensible, are too locked into non-commodity (e.g. z-Series) hardware, or are too sensitive or mission-critical to migrate to (especially public) cloud environments. With apologies to the ‘pure cloud’ fantasists, it is a reality for many organizations, especially larger enterprises, many services will not be part of their cloud adoption plans – at least not soon, perhaps not ever. It is important to identify these ‘cloud-free’ services.

Cloud Migrant Services

As CIOs get a handle on cloud, they start proactively evaluating their service portfolio and migrating selected existing workloads – from the OS up – initially from physical to virtual, then to appropriate public or private cloud choices. These ‘cloud migrant’ services are not fundamentally changed, as they simply ‘lift and shift’ the same code, requirements, interconnections, users, data sources, etc. from traditional environments to (typically IaaS) clouds. Many benefits can accrue from running these services in a cloud – agility, flexibility, efficiency, cost reduction – but the services themselves are not specifically built in or for the cloud.

Cloud Native Services

As organizations embrace cloud computing, they start developing and using new ‘cloud-native’ services built in the cloud and for the cloud. Mobile and social services, for example, really blossom when built on cloud-native characteristics like self-service, mobility, scalability, and ‘big data’, while cloud-native development also allows business ideas to ‘fail fast’ or prove success with minimal upfront investment. Of course, rogue-cloud services (see below) can become cloud-native services when they move to ‘official’ production status; and SaaS applications are also cloud-native services, just delivered out-of-the-box by public providers.

Rogue Cloud Services

In many organizations, business users or developers have adopted cloud already, outside of the normal IT procurement process. The term ‘rogue’ may seem pejorative, but is not intended to be – I simply described a process that is outside of IT’s knowledge or control. As I wrote back in 2009, rogue cloud can be very positive, and there is no per se reason for IT should to shut it down. However, IT does need to establish visibility into rogue cloud to ensure security or compliance, avoid cost overruns, drive broader adoption of good cloud choices, or even to promote better cloud choices.

Why Does This Matter?

This segmentation came about not as an academic exercise, but to help CIOs with a taxonomy for service portfolio analysis and cloud choice. Each of these cloud service types has different needs, from both platform and management perspectives. By identifying cloud service types, a CIO can better adopt their choice of cloud as appropriate for different services at different times.

For example,

• A cloud-native service can be ‘designed to fail’, whereas a cloud-migrant service needs additional management (e.g. real-time replication) to maintain the same level of continuity.
• A cloud-migrant application that has been QA’d on a closed and proprietary hypervisor may need additional testing and QA before it can be moved to a different (or unspecified) hypervisor.
• A rogue cloud service must be discovered before it can be managed as part of a whole portfolio, whereas a cloud-native or cloud-migrant service will be catalogued as it is deployed.
• A cloud-free service needs none of the above, and specifically can fall outside the cloud portfolio and be exempt from new policies specifically designed to enable cloud services.

This segmentation is not meant to replace a thorough service portfolio analysis in making good cloud choices. In my session at VMworld 2011 in Las Vegas, for example, I presented analysis models from Visible Ops – Private Cloud, a CA Technologies quadrant framework, Forrester Research’s Evaluating Application Fit With Cloud model, and Freeform Dynamics’ model from Applied Cloud Computing: A practical guide to identifying the potential in your environment.

However, I do think it is a useful taxonomy to start making sense of your own service portfolio as you start to take stock of where you are in your cloud strategy, and where you want to go. So far, the CIOs I have worked with on this have agreed.

What do you think?

Corporations look better with clouds too! La Defense, an office park in Paris. The building on the left houses the CA Technologies office.

In several recent posts, I have concentrated on the benefits of private cloud for large enterprises. For example:

• Hitchhiker’s Guide to the Cloud: The Evolutionary Path
• The cost benefit myth of the public cloud
• Launching my first book – Visible Ops Private Cloud
• Public Cloud Computing is NOT For Everyone

However, I want to be very clear about something:

Public cloud offers great benefits, even – or especially – for large organizations.

Public cloud may well be the only IT architecture ever needed for most small organizations, many startups, and some emerging enterprises. Why build even a server cupboard, let alone a data centre, if you don’t need to? And many of these organizations will never need to.

However, even large enterprises should use public cloud. It certainly offers substantial benefits for large enterprises too, including:

• cost reductions – avoiding any upfront spend on hardware can drive down the cost of creating and delivering some new products and services, and even reduce their total service cost over the lifetime of a short- or medium-term deployment.
• agile service delivery – when reacting to market forces, public cloud services can pivot in ways even private cloud cannot, because they are designed to accommodate immediate delivery of large scale, semi-permanent, additive compute resources.
• strategic flexibility – if your strategy depends on deep investment in IT hardware, a major course correction can be prohibitively expensive. Using public cloud resources, even if only temporarily, can be the difference between making the market and missing it.
• workforce mobility – physical hardware and data centers, even agile private clouds, can dramatically limit your ability to expand, insource, offshore, outsource, or move staff remotely, especially limiting small distributed teams, and even larger regional office deployments.
• mobile/social support – mobile and social services are king and queen of public cloud-native applications, driven by unique needs for global mobility, fast response, load spikes and troughs, massive data volumes, content crowdsourcing, and more.
All of these benefits ultimately drive significant competitive advantage
• best of breed services – specialization, scale, and experience means large public cloud providers may deliver better quality services in non-differentiating areas like e-mail, CRM/SFA, or hosting than an organization can deliver internally.
• enabling risk and innovation – low CapEx risk enables enterprises to foster incubators to explore new technologies, datasets, and integrations. This can deliver new high-reward innovations such as the New York Times ‘TimesMachine’, Netflix’s streaming model, and many many many others.
• new communities – public cloud is a fantastic shared sandbox, allowing businesses to connect with and through new audiences, workforces, behaviours, collaborations and more, at massive scale and with global influence, to attract and retain customers at fractional acquisition costs.
• higher availability – with some clairvoyance; the luxury of spare time, money, skills, and people to (re-)design your applications to survive extended catastrophic infrastructure failure; and some ongoing reliance on private infrastructure; you can achieve better uptime even from a limited 99.95% uptime guarantee. No, really – average enterprise uptime is actually even worse.
• competitive advantage – all of these benefits ultimately drive significant competitive advantage, measurable in outcomes like higher customer attraction and retention, better customer satisfaction, increased revenues, and improved shareholder value.

All these benefits are applicable to large enterprises. Some are even more applicable than for smaller organizations, due to the larger benefits of scale. And no doubt you all can think of many more.

Of course there are also many challenges. Public cloud may not work for every service, or even for every organization. For some services, the issues will be insurmountable – maybe forever, maybe just for now – while for others they will be trivial. Similarly, some cloud providers will be unacceptable for certain services, where others pass with flying colours.

The key is in evaluating which services in your portfolio are suited to public cloud; and evaluating the public cloud providers where you may migrate them.

To maximize the benefit for any public cloud deployment, evaluate each service’s requirements for cost, risk, performance, portability, security, uptime, recovery time, visibility, control, compliance; and measure these against the ability of cloud service providers to meet those requirements.

Easy to say, harder to do – but there are solutions (from my employer, CA Technologies, for example) to help you evaluate both your service portfolio and possible cloud providers, so you are not on your own. Which also means you have no excuse.

Because one thing is certain – if you avoid the public cloud altogether, even if you are a large enterprise, then you will miss substantial benefits.

The front cover of Visible Ops Private Cloud

Today is a very exciting day for me.

After many months of blood, sweat, and tears, today we are finally launching a brand new book that I co-wrote (alongside a couple of amazing people – Kurt Milne and Jeanne Morain), called Visible Ops Private Cloud: From Virtualization to Private Cloud in 4 Practical Steps.

I am certainly excited because this is my very first ‘real’ book – a hard-copy print volume (Kindle and PDF versions will be available soon too), available for purchase on Amazon.com and ITPI.org, with a real ISBN and everything!

But that is not the only reason.

I am excited to be working with the book’s publisher, the IT Process Institute. The ITPI is a renowned independent research organization “that exists to support the membership of IT operations, security, and audit professionals” with a  mission “to identify practices that are proven to improve the performance of IT organizations.”

In addition, I am thrilled to have worked with experienced professionals like Jeanne and Kurt . Together, we have over 60 years experience in systems management, automation, virtualization, and cloud with some of the best and brightest vendors including VMware, CA Technologies, BMC Software, InstallFree, Thinstall and more.

Moreover, I am proud that Visible Ops Private Cloud is based on over 30 in-depth interviews with actual practitioners – managers, architects, CIOs, administrators, and others working in healthcare, finance, service providers, education, manufacturing, hi-tech, and other enterprise IT organizations, who have successfully implemented private cloud solutions.

Most especially I am excited because with this combination, we have created something uniquely valuable in Visible Ops Private Cloud.

If you are aware of the famous Visible Ops series of books from the IT Process Institute (ITPI), you will instantly understand how proud I am of this effort, and my association with these great texts and their publisher. You will know that these books are concise and easy to read (Visible Ops Private Cloud is just over 100 pages in a paperback-sized book), providing “simple, practical, step-by-step advice on how to quickly gain the biggest benefit from proven best practices.” You will know that they are “the ideal way to get an IT organization to rally behind a simple approach to operational excellence.”

You will also know that this is a book for ‘doers’, not just ‘thinkers’. Indeed, in keeping with the mantra of the Visible Ops series, Visible Ops Private Cloud aims to provide prescriptive, actionable guidance on how to drive cloud success by turning your virtualization project into an enterprise private cloud strategy, based on best practices from other professionals and organizations.

This is why in Visible Ops Private Cloud we broke down the evolution from virtualization to cloud into four clear, pragmatic phases:

• Phase 1: Cut through cloud clutter – plan and communicate objectives, manage initial proof of concept efforts, and develop competency road maps.
• Phase 2: Design services, not systems – design business optimized cloud services, enable one-touch service ordering, and implement a repeatable approach for build and deploy.
• Phase 3: Orchestrate and optimize resources – update monitoring and alerting, deploy a policy engine to codify response, automate resource changes and workload moves.
• Phase 4: Align and accelerate business results – complete transition to a resource rental model, reshape consumption behavior, and streamline response to changing business needs.

While we were trying to provide useful content for an audience anywhere from a sysadmin up to CIO, the real sweet spot will be those practitioners who are responsible for the initial design, ongoing deployment, and ultimate success of their organization’s private cloud strategy – the ops manager, sysadmin team lead, enterprise architect, CTO office, development manager, virtualization lead, or the virtualization/cloud project manager.

Mainly we tried to recognize where these people were really up to with their cloud strategies, and to provide useful and actionable advice to help them advance their progress. So in this book you will not read much about how to optimize hypervisor configuration settings, or how to schedule a VM backup; nor will you see much high-level exploration of elementary cloud definitions or the conceptual ‘journey to the cloud’.

What you will see is a concise run-down of the situations in which you might find yourself; the defined steps you need to take to make and show progress; how to put this advice into action across the affected people, processes, and technologies; and some real-life war stories highlighting how to avoid specific problems, and explaining critical issues you will need to understand.

That said, we certainly hope that Visible Ops Private Cloud will provide an excellent resource not just for these strong practitioners’ own use. We also expect this book to be a valuable resource they can use to educate their CIOs on the tactical realities of building a private cloud, and to educate their more focused hands-on colleagues on the important strategic business and IT goals that their work is helping to accomplish.

Perhaps the most important part of Visible Ops Private Cloud is that our personal experience is not the sole factor – or even necessarily the main factor – in how good the content in this book turned out. Despite the authors’ sometime involvement with various software vendors, this is truly an independent effort, without a single brand or product name mentioned throughout.

On the contrary, the real stars throughout the book are the practitioners – the administrators, sysadmins, programmers, operators, CIOs, enterprise architects, and others – and their experiences in virtualization and cloud. Their insights into what makes a private cloud successful – and some of their war stories too – come through loud and clear. Their stories ensure Visible Ops Private Cloud delivers a very realistic, pragmatic, and independent investigation based on real-life implementations.

So how good is Visible Ops Private Cloud really? Well, you can do a search for it, and see what other people are saying (I will try to update this blog with some links as they come out).

[Edit: Here are some of the reviews that have come through so far:]

• By The Bell: Book review: Visible Ops Private Cloud: from virtualization to private cloud in 4 practical steps

You can go over to Amazon.com and check out the reviews (there are already a couple there, and hopefully more to come). You can read the back cover and see some of the endorsements that came in after we sent out some preview copies:

Visible Ops Private Cloud back cover quotes

Or you can simply order a copy from Amazon or direct from the ITPI and read it yourself. If you do – and I really hope you will – please let me know. I would love to hear what you thought.

So, here is something interesting I discovered today, courtesy of a tweet from Christian Reilly (@ReillyUSA) – the US federal agency, the National Institute of Standards and Technology (NIST), today released Version 1 of their Cloud Computing Reference Architecture (PDF). It is free and, like all US Federal Government content, it is open.

I have written about NIST before – both in my research work at EMA and in my personal blog – and wholeheartedly endorse their excellent definitions for cloud computing. If we can trust them to define time – and a thousand more standards besides – we can trust them to define cloud.

So I am more than willing to let them have a go at describing a cloud reference architecture.

The document essentially provides a brief outline of the five key actors:

• Cloud Consumer – Person or organization that maintains a business relationship with, and uses service from, Cloud Providers.
• Cloud Provider – Person, organization or entity responsible for making a service available to Cloud Consumers.
• Cloud Auditor – A party that can conduct independent assessment of cloud services, information system operations, performance and security of the cloud implementation.
• Cloud Broker – An entity manages the use, performance and delivery of cloud services, and negotiates relationships between Cloud Providers and Cloud Consumers.
• Cloud Carrier – The intermediary that provides connectivity and transport of cloud services

Then through a combination of definition, example, and illustration, it places these actors into a big picture end state ‘reference architecture’:

NIST Cloud Reference Architecture V1

Despite some clear flaws, I think this is a great document. More than just a series of definitions, far less than a ‘true’ technical reference architecture, it is advisory and high-level, but practical and usable.

Some key standouts for me include:

‘Grown-up’ management finally takes center stage

I am particularly excited that such a powerful voice in cloud computing is finally highlighting the primary importance of management in their cloud documentation. Almost half this document is focused in cloud management – something I have been deeply committed to for many years. It does not just rehash simplistic notions of cloud – that it is just live migration, capacity management, or an orchestration engine. It shows that you need to maintain many mature enterprise management disciplines – even as ‘old school’ as performance management and SLM – as you grow your cloud maturity. All actors – including consumers and providers – must mature as well. You can call it names like ‘legacy’, or pretend ‘enterprise’ is code for ‘mainframe’ – like that’s a bad thing – but NIST clearly believes a cloud computing environment needs mature management discipline.

It’s all about the service

Of the eleven management slides, six are devoted specifically to a concept NIST calls Cloud Service Management (CSM) – something I first wrote about in 2008, and which likely has been around for longer than that. NIST defines CSM as:

all the service-related functions that are necessary for the management and operations of those services required by or proposed to cloud consumers.

It breaks these down into three main management areas as follows:

NIST Architecture for Cloud Service Management

This is a huge step forward in pragmatic (dare I say, responsible?) cloud service delivery. Many vendors are trying to define cloud as advanced virtualization, or rapid provisioning, or service catalog, or automation – or a proprietary ‘cloud in a box’. Others claim public cloud vendors will do it all, as though there is no need to deal with performance assurance, incident reporting, or bandwidth management. A rational, independent, authoritative body explaining the breadth of integrated enterprise service management required to deliver a high quality cloud service is important information for many CIOs who have been led to believe a more simplistic vision.

Service orchestration needs breadth and deep

This cloud reference architecture devotes special attention to service orchestration across multiple layers of the cloud environment:

• physical resources – including hardware  (memory, storage networking, etc.) and facilities (HVAC, power, comms, etc.)
• virtual systems – hypervisors, virtual machines, virtual data storage, and VM platform tools
• physical systems – NIST specifically accommodates non-virtual resources for cloud delivery
• application delivery – top-down delivery of end-user software clients or other programs
• platform delivery – various development environments, databases, app servers, etc
• infrastructure services – processing, storage, networks, and other fundamental resources

In clearly delineating the need for sophisticated process automation, real-time management, and integration, it shows the need to orchestrate not just a single platform or silo, but end to end across multiple layers, platforms, technologies, and vendors.

The value of an independent judge

I also really like the idea of specifically including an independent arbiter – the Cloud Auditor – that is empowered to “evaluate the services provided by a Cloud Provider in terms of security controls, privacy impact, performance, etc.” The need for an independent reviewer is already well overdue. Today, even cloud leaders like Amazon, WordPress, Salesforce, and Netflix can be down for hours with no reporting or explanation, and with no more payback than a sorry letter and few pennies in credit for time lost. They are also killing off any expectation of security, compliance, or privacy by hiding away fine print like the right to “access, retain, use and disclose your account information and your files … as [they] determine is necessary”. In this climate, we already desperately need an independent agent to adjudge the operations, performance and security of all cloud providers, especially public cloud providers.

However, the reference architecture is not all good, and some significant issues also stood out for me:

Security is a one-sided activity

The reference architecture hangs the responsibility for security almost entirely on the Cloud Provider, which is poor advice. Unlike cookies, security is not a ‘sometime’ food, and active participation in security cannot be attributed to any one actor or interaction. For example, two-factor authentication necessarily requires active participation by both service provider and service consumer. Cloud Auditors and Cloud Brokers also have significant responsibilities for security.

Everyone is a ‘Cloud Carrier’

The ‘Cloud Carrier’ actor essentially elevates all telcos to the role of ‘Cloud Carrier’ with no change in business model or technology. It also actually classifies cabs, couriers, and even the UPS as ‘Cloud Carriers’, as this actor includes any provider of “physical transport of storage media such as high-capacity hard drives.” A requirement for Cloud Providers to set SLAs with Cloud Carriers is especially unlikely for a public cloud, though it makes more sense in the context of a private cloud. It also leads to difficult questions of carrier interoperability, quality of service, traffic shaping, and even ‘Net neutrality.

Encryption is optional

Encryption is included as an optional (!) activity, which of itself is unacceptable for mission-critical enterprise applications. Even then it is ascribed to the Cloud Carrier. The idea sounds great – carriers provide “dedicated and encrypted connections” for the “connectivity and transport of cloud services.” However, it is unrealistic for carriers to implement interoperable encryption for ‘cloud traffic’ (whatever that is). It also forgoes the current, quite logical, de facto standard – encryption directly between the provider and the consumer, regardless of carrier. Again, much of this architecture seems to be more directed at private cloud networks, rather than public networks including the Internet.

Privacy is not having to say you’re sorry

Privacy is included as a single line item without much meat on the bone:

Protect the assured, proper, and consistent collection, processing, communication, use and disposition of personal and personally identifiable information (PII) information on the cloud.

This is so neutral as to be unhelpful. Sharing personal data with advertisers, handing over corporate data to warrantless investigations, or even selling your customer database on eBay, may all be ‘assured, proper, and consistent’ according to some so-called ‘privacy policies’. The document does allow the Cloud Auditor to “evaluate the services provided by a cloud provider in terms of … privacy impact,” but beyond this it has no advice on what privacy actually means. Perhaps this is asking too much of a high-level document, but personal privacy and data loss prevention are critical issues in cloud computing. From controversy over Facebook’s exposure of personal details to cloud providers cutting off legitimate businesses, there is significant concern over privacy. I expected more prescriptive advice, rather than a neutral academic definition, especially from a public body setting policy for the IRS, the Pentagon, Department of Social Security, and other sensitive departments.

Management is entirely a provider activity

NIST attributes cloud management – including security and service management – entirely to the cloud provider. This is rare (if it exists at all) among public cloud providers today, and is unlikely to ever be acceptable for most enterprises. With providers doing all the management the fox is watching the hen house. Consumers will require at least some participation. We learned that it is bad to give total control to third-party providers when we did things like IT outsourcing. Just as with cloud computing itself, the majority of enterprises will probably always want a hybrid model for cloud management.

The bottom line

I do see this as a very useful document. It is really quite good – as far as it goes. It is also a very important document – for what it gets right, for what it gets wrong, and for where it comes from, as NIST is helping to shape cloud standards for the world’s largest consumer of information technology. It is far from perfect, and I believe has some truly fundamental flaws, but it is only a Version 1, and who among us has delivered a perfect product on the first release?

So ultimately, it is good enough for now, but I am very much looking forward to the ongoing development of this document. To quote Raymond Umerley (@SecJitsu):

'Close Enough for Government Work'

There is a perennial debate in cloud computing about whether a failure of one cloud service provider can be more generalized to a ‘failure of cloud computing’. It is an important question because availability is a key decision factor in choosing between private and public cloud, and between public cloud providers.

The most recent example of such failures is the power outage at IaaS provider Rackspace’s London facility, but of course, we have seen this before from many public cloud providers – including Rackspace in particular, and not just once. SaaS provider Salesforce.com (and its PaaS arm, Force.com) has also had one outage already this year, an event that is far from unusual, and nothing new. Amazon, Yahoo, Microsoft, GoGrid, RIM, Twitter, Paypal and many others have also had substantial (and often repeated) outages.

There are some who dismiss these failures as one-offs, write off partial or short-term failures as too low-impact to matter, or just give poor DR a pass because it is the cloud, and we should not expect any better. Others reach to find semantic differences, calling it a service outage, an application failure, a facilities outage, a power outage, or a resource shortage. Some just redefine cloud to include only those services that did not go down this week (bonus points for adding a vainglorious reference to the ‘real cloud’ or ‘true cloud’).

YMMV, but I don’t see it that way at all. With so many repeated failures in so many cloud providers, these are not just one-off failures. They don’t just happen to isolated providers, they happen across the board. Regardless of the cause – the application, the facilities, the power supply, the lightning rod – an outage of a cloud service provider is still a cloud outage. And the definition of cloud I use is not dogmatic enough to exclude any of the providers that I have cited (and others), let alone define a ‘true cloud’.

So I see every reason to believe that downtime in the public cloud is not the exception, it is the rule; that outages in the public cloud are endemic, and they are systemic.

However, this judgement is absolute, not relative. Failure in one cloud provider may (and I believe does) implicate all cloud providers, but it does not imply downtime is more of a problem in the public cloud than in traditional enterprise IT. Indeed, there is a strong argument that enterprise IT has as many if not more outages, so uptime and availability is no worse in the public cloud than with traditional IT.

In fact, EMA research has shown average enterprise IT uptime is just ‘two nines’, at 99.5%. For a 24×7 system, that is over 50 minutes of downtime, each and every week. Contrast this with public cloud providers. Even with their problems, Amazon EC2 offers a “reasonable effort” to deliver an annual uptime of at least 99.95% – or about 5 minutes downtime per week – and offers a 10% credit for “eligible” breaches. Google guarantees ‘three nines’ (99.9%) uptime for its Premier Edition, or around 10 minutes downtime per week (although it promotes a study that claims an average downtime of 15 minutes a week). The Rackspace SLA promises network, HVAC, and power will be up 100%, though it does not guarantee server availability (beyond promising a 60 minute maximum repair window), and all promises exclude ‘scheduled maintenance’.

So for the average enterprise, ‘normal’ cloud computing outages, while endemic, can still be 5 to 10 times less frequent than in their own data centers.

However, it is not a black and white issue, not least because a focus on broad uptime percentages or on single instance failures ignores the huge nuance behind a single uptime number.

For example, many environments report ‘five nines’ (99.999%) or even 100% uptime – less than one second of unplanned downtime each day – for their critical systems by using processes and tools for high availability, fault tolerance, asset maintenance, live migration, etc. EMA has also found that best performers in Virtual Systems Management – 15% of enterprises – report an average of five nines uptime.

If they need to, enterprise CIOs can invest in technology to provide two, three, four or five nines uptime within their own data center. They can implement redundant hardware, HA and FT, multi-site replication, and more – if they want to pay for it. They can monitor for outages, know exactly when they happen, and react automatically to fix them immediately (or even use predictive analytics and automation tools to avoid them entirely). They can provide this as required, as a value-add to their business unit customers, or as an additional charge (or at least an exposed cost)  to the business to let them choose how critical their applications really are.

However, with the public cloud, neither the business nor the CIO has any real choice. With few or no management or automation tools, public cloud providers simply do not currently offer the same flexibility and accountability as internal IT. Without good management tools, no public cloud provider currently matches enterprise IT at the higher mission-critical reaches of availability.

So, this fight does not end in a knock-out for either side. As is common in the real world, nothing is black and white, but rather many shades of grey.

In the end, the solid achievements of public cloud providers, despite the bad press, does not absolve them of any blame or negate generalizations of downtime being endemic in the public cloud. However, the relatively poor performance of enterprise IT on average still does not ensure public cloud will be any better in any specific cases.

What this does show, however, is that CIOs who are planning to build their own private cloud have a surprisingly high bar to reach. They should not dismiss public cloud options out of hand, but rather should strongly consider whether they can realistically and cost-effectively meet the three, four, and even five nines that public cloud providers guarantee.

I am getting so sick of the continual bickering over definitions of cloud computing. Even more frustrating is the hype from all the vested interests – vendors and analysts, mostly – trying to define cloud computing in ways that they imagine will best contribute to their own commercial success. And I know that I am not alone.

What is wrong with the definition that the US National Institute of Standards and Technology (NIST) – a division of the US Department of Commerce – uses?

You can read the entire definition online [link updated 8/12/11]. It is only 2 pages. Here, for the unaware, is the meat of it:

“Cloud computing is a model for enabling 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.”

Does this suck so badly that every [insert your preferred expletive epithet here] needs a new definition?

It goes on to include:

• Five essential characteristics: On-demand self-service; Broad network access; Resource pooling; Rapid elasticity; and Measured Service.

• Three service models: Software as a Service (SaaS); Platform as a Service (PaaS); and Infrastructure as a Service (IaaS).

• Four deployment models: Private cloud; Community cloud; Public cloud; and Hybrid cloud.

So what exactly is wrong with that?! Why does every man and his dog feel the need to throw their own definition of could computing into the ring?

Don’t get me wrong. Definitions are important. Definitions enable a common understanding of terminology, essential when talking about complex technologies. And I have pushed my own definitions before (like my definition for virtualization, widely adopted after Wikipedia picked it up in 2006).

But why fight city hall (in this case, almost literally)? NIST has a very elegant definition that is:

• Intelligent – it has been through (to date) 15 iterations, and has accepted input from many of the brightest minds in cloud computing (while presumably ignoring some dimmer bulbs)
• Independent – it is from a mature, well-established, and exceptionally talented US government agency, which is both apolitical, and science-based
• Commercially agnostic – it does not specify that anyone needs to be making money, nor does it preclude it, allowing cloud to be B2B, B2C, B2G, G2C, or any other model
• Accommodating – all established cloud vendors (like Amazon, Google, Rackspace, Salesforce, and others) fit into this definition, as well as private and government models.
• Clear – it is not full of jargon or ‘cloudwash’, but rather has easily understood, plain English concepts that are not only unambiguous but also usefully prescriptive
• Comprehensive – it includes all the important core concepts such as self-service, resource pooling, rapid elasticity, accessibility, usage costing, multiple use cases, and more
• SMART – it does not try to create anything exceptional or outrageous, but does define a set of Specific, Measurable, Achievable, Relevant, and Timely objectives

We trust NIST to define the official time for all of the United States. We trust it to calibrate instruments for NASA. We trust it to supply “industry, academia, government, and other users with over 1100 reference materials”.

Moreover, this is what the US government is using to define cloud computing, as noted by Vivek Kundra (the US Federal CIO). Indeed, Kundra has strongly indicated that the US government will be one of the strongest, largest, and most important proponents, providers, and consumers of cloud computing (cf. sites like apps.gov and data. gov). Other levels of government – and even other nations – will almost certainly follow their lead, and the NIST definition of cloud computing.

So why can’t people trust NIST with the definition of cloud computing, and just get on with the job of solving real problems for their customers? Bickering and chest-beating over self-enriching definitions is not needed, it is not useful, and it is not helpful.