The Wisdom of Clouds

To date, this series has tried to guide you through the changes happening from the infrastructure, developer, and end user perspectives that signal the demise of the full-featured server operating system and the virtual server. Virtualization, and the large scale, multi-tenant operations model we know and love as "cloud computing," are enabling IT professionals to rethink the packaging, delivery, and operation of software functionality in extremely disruptive--and beneficial--ways.

(Credit: Wonderlane)

So, what does this mean to the future of information technology? How will the role of IT, and the roles within IT, change as a result of the changing landscape of the technology it administers? What new applications--and resulting markets--are enabled by the "big rethink"?

Here are just a few of my own observations on this topic:

1. Software packaging will be application focused, not server focused. As anyone who has deployed a distributed application in the last two decades can tell you, the focus of system deployment has been the server, not the application, for some time now. In the highly customized world of IT systems development before virtualization and the cloud, servers were acquired, software was installed upon the servers in very specific ways, and the entire package was managed and monitored largely from the perspective of the server (e.g. what processes are running, how much CPU is being used, etc.).

   As OS functionality begins to get wrapped into application containers, or moved onto the hardware circuitry itself, the packaging begins to be defined in terms of application architecture, with monitoring happening from the perspective of software services and interfaces rather than the server itself. These packages can then be moved around within data centers, or even among them, and the focus of management will remain on the application.

   That's not to say that no one will be watching the hardware. Infrastructure operations will always be a key function within data centers. However, outside of the data center operations team, it will matter less and less.

2. Enterprise IT will begin to bend enterprise and solutions architectures to align better with what is offered from the cloud. I may not agree with some that the cloud will stifle differentiation in software systems, but one thing is very true.

   As end users select software-as-a-service applications to run core pieces of their business, meet integration and operations needs from the cloud, and generally move from systems providers to service providers, the need to reduce customization will be strong. This is both to reduce costs and strengthen system survivability in the face of constant feature changes on the underlying application system.

3. The changing relationship between software and hardware will result in new organizational structures within the IT department. When it comes to IT operations--specifically data center operations--we've generally lived with administrative groups divided along server, storage, and network lines from before the dawn of client-server application architectures.

   This organization, however, is an artifact of a time when applications were tightly coupled to the hardware on which they were deployed. In such a static deployment model, expertise was needed to customize these technologies in pursuit of meeting specific service-level goals.

   When you decouple software deployment from underlying hardware, it begins to allow for a re-evaluation of these operational roles. Today, most companies are already in a transition in this respect, with increasing reliance on roles like "virtualization administrator" and "operations specialist" to fulfill changing needs.

4. The changing landscape of software development platforms will result in new philosophies of software architecture, deployment, and operations. I'm thinking here primarily of two things.

   First, agility will become king in large-scale systems development for classes of applications ranging from web applications to data processing to core business systems. Agility from the service provider's perspective, in the frequency in which they can release features and fixes. Agility from the perspective of the enterprise developer, through the ways in which they can rapidly iterate over the write-build-test cycle. Agility from the perspective of the entrepreneur, in that data center services are now a credit card away.

   Second, I think project management, whether for commercial offerings or for custom enterprise applications, will see rapid change. Agile programming and project management methods make a ton of sense in the cloud, as do service-oriented approaches to software and systems architecture. Project managers wondering what cloud computing will do to their day-to-day jobs should consider what happens if development can outpace a Gant chart.

5. The need for tactical systems administrators will be reduced. I've written about this in the past, but the tactical system administrator--the man or woman who grabs a trouble ticket from the top of the queue, takes care of the request, closes the ticket, then takes the next ticket from the queue--is going to largely (though probably not entirely) go away.

   Why? Automation. Most of the tasks such an admin does day to day are highly automatable: provisioning, failure recovery, scaling, infrastructure management and so on. These administrators are among the last "clerks" in business, and a result of the unfortunate fact that IT has been excellent at automating everything in business--except IT.

   Where tactical systems administration will still be needed, however, is in what I like to call the "private cloud operations center," a concept similar to the network operations centers that exist in many Fortune 500 companies today. There, the administrator would monitor overall performance of applications running in the cloud (on both internal and external resources), as well as monitoring the performance of the cloud providers themselves.

There are a lot more forward-thinking thoughts that you and I could probably come up with when we think of the demise of traditional IT in favor of a lean, tight, cloud-oriented IT model. However, the great thing about being involved in cloud today is that the ground is shifting so fast, that I find myself changing many of the long-term predictions I made last year. I wouldn't presume to be able to see the future clearly in the face of cloud computing, but many of the key drivers are already out there.

The trick is to be open-minded about what you see, and to be willing to "rethink"...big.

So far in this series, I've described why the very form of application infrastructure delivery will change in the coming years, and why both infrastructure and software development will play a major role in that. These are powerful forces that are already at work, and you are already seeing their effects on the way enterprise IT and consumer Web applications are being operated.

There is one more key force that will change the way we acquire, build, and consume enterprise application functionality and data, however. It is the very reason that enterprise IT exists. I am speaking, of course, of the users--the business units and individuals that demand IT give them increased productivity and competitive advantage.

How is it that end users could affect cloud-based architectures? After all, isn't one of the key points about cloud computing that it hides infrastructure and operations from hosted applications and services? The answer is simple: the need for cloud-operated infrastructure comes from the need for more efficient application delivery and operations, which in turn comes from the accelerated need for new software functionality driven by end users.

The most obvious place where this is the case is software as a service. Cloud applications and services that fall under this category are targeted at end users; they deliver computing and storage functionality that meet specific business needs (such as customer relationship management (CRM) or application development and testing).

Here's the thing about most business applications, though, regardless of how they are delivered: they are almost never used out of the box, as is, without some form of customization. I worked for a short time at enterprise content management vendor, Alfresco, and I don't think there were any "as is" deployments. Every engagement involved customization.

For CRM vendor Salesforce.com, the evidence is the importance and success of its Force.com cloud development platform, as well as its AppExchange marketplace. Both allow users to customize or extend Salesforce.com for their needs, and even build new business applications that leverage customer data.

The result of this is that the cloud itself must be not only elastic, but agile. It must bend at all levels to the will of its users, and the degree and ease of configuring and customizing will quickly become competitive differentiators for vendors in all categories of cloud computing.

What are the best ways to accommodate this agility at scales large enough to meet the needs of cloud computing? Well, today that would be two technologies:

• Virtualization--the abstraction of computing, storage, and networking resources from underlying infrastructure
• Automation--the elimination of the need for human intervention in common, repeatable tasks and decisions

Now, if you are going to virtualize and automate infrastructure in support of a customization of a SaaS application, do you need an entire virtual server with a full featured operating system? Of course not. In fact, I would argue that you need least-common-denominator systems infrastructure to enable the customization to work. Otherwise you are creating unnecessary storage and computing baggage.

I think in many ways only the cloud-computing model enables this degree of efficiency in running customized business systems for end users. Because the service vendors (be it software, platform, or infrastructure services) are able to optimize for all customers at once, a given advancement in efficiency pays off much more (and much faster) for the service provider than it would for a single customer. Multi-tenancy is what makes the economics work for both the business user and the service provider.

My next and final post in the series will attempt to wrap all of this up, and to present a vision of what the cloud of the future may look like when the evolution and/or demise of the operating system and virtual server is complete. Though I harbor no illusions about it happening all at once, or being a pain-free transition, I, for one, am excited about the new technologies this future may enable. I hope you are, too.

In the second part of this series, I took a look at how cloud computing and virtualization will drive homogenization of data center infrastructure over time, and how that is a contributing factor to the adoption of "just enough" systems software. That, in turn, will signal the beginning of the end for the traditional operating system, and in turn, the virtual server.

However, this change is not simply being driven by infrastructure. There is a much more powerful force at work here as well--a force that is emboldened by the software-centric aspects of the cloud computing model. That force is the software developer.

Let me explain. Almost 15 years ago, I went to work for a start-up that was trying to change the way distributed software applications were developed forever. The company was Forte Software, since acquired by Sun (itself soon to be acquired by Oracle), and its CTO, Paul Butterworth, and his team were true visionaries when it came to service-oriented software development (pre-"SOA"), event-driven systems, and business process automation.

What I remember most about Forte's flagship product, a fourth-generation language programming environment and distributed systems platform, was the developer experience:

• Write and test your application on a single machine, naming specific instances of objects that would act as services for the rest of the application.

• Once the application executed satisfactorily on one system, use a GUI to drag the named instances to a map of the servers on your network, and push a single button to push the bits, execute the various services, and test the application.

• Once the application tested satisfactorily, create a permanent partitioning map of the application, and push a single button to distribute the code, generate and compile C++ from the 4GL if needed, and run the application.

This experience was amazingly productive. The only thing it could have used was automation of the partitioning step (with runtime determination of scale, etc.), and the ability to get capacity for the application dynamically from a shared pool. (The latter was technically possible if you used a single Forte environment to run all of the applications that would share the pool, but there still would be no automation of operations.)

I have spent the last 10 years trying to re-create that experience. I also believe most distributed systems developers (Web or otherwise) are looking for the same. This is why I am so passionate about cloud computing, and why I think developers--or, perhaps more to the point, solutions architects--will gain significant decision making power over future IT operations.

I look at it this way: if an end user is looking for an IT service, such as customer relationship management, a custom Web application, or even a lot of servers and storage for an open-source data processing framework, there is almost always something that takes the knowledge and skills of someone who can create, compose, integrate, or configure software systems to meet those needs.

Furthermore, there remains a lot of reliance by nontechnical professionals on their technical counterparts to determine how computing can solve a particular problem. For the most part, in most corporate and public sector settings, the in-house IT department has traditionally been the only choice for any large-scale computing need.

Until recently, if a business unit hired a technologist to look for alternatives to internal IT, the costs of any other "IT-as-a-service" offering (outsourcing, service bureaus, etc.) was extremely expensive and would immediately have to be rationalized against internal IT--usually to the detriment of the alternative. On top of that, all of those alternatives required long-term commitments, so "trying things out" wasn't really an option.

The economics of the cloud change things dramatically. Now the cost of those services are cheap, can be born for very short periods of time, and can all be put on a credit card and expensed. A business unit can go a long way to proving the economic advantages of a cloud-based alternative to internal IT before their budget is significantly impacted.

Developers are increasingly choosing alternative operations models to internal IT, and will continue to do so while the opportunity is there. Internal IT ultimately has to choose between competing with public clouds, providing services that embrace them, or both.

(There are often reasons why internal IT can and should provide alternatives to public cloud computing services. See just about the entire debate over the validity of private clouds.)

So, how does the cloud accommodate and attract software developers? I believe the key will be the development experience itself; key elements like productivity, flexibility, types and strength of services, and so on will be critical to cloud providers.

We need more development tools that are cloud focused (or cloud extensions to the ones we have). We need more of an ecosystem around Ruby on Rails and Java, currently the two most successful open development languages in the cloud, or innovative new approaches to cloud development. We need to tighten up the development and testing experience of PaaS options like Google App Engine, making things "flow" as seamlessly as possible.

We need more IaaS providers to think like Amazon Web Services. We always hold up AWS as the shining light of Infrastructure as a Service, but the truth is that they are actually a cloud platform that happens to have compute and storage services in their catalog. How much more powerful is AWS with other developer-focused services, such as DevPay, Simple Queue Service, and Elastic Map Reduce? This attracts developers, which in turn attracts CPU/hrs and GB/hrs.

How does all of this affect the virtual server and operating system, the topic of this series? Well, if the application developer is getting more services directly from the development platform, what is the need for a bevy of advanced services in the operating system? And if that platform is capable of hiding the infrastructure used to distribute application components--or even hide the fact that the application is distributed altogether--then why use something that represents a piece of infrastructure to package the bits?

Next in the series, I want to consider the role of the business users themselves in rethinking enterprise architectures. In the meantime, you can check out part 1 of this series about how cloud computing will change the way we deliver distributed applications and services; and part 2 about how server virtualization is evolving.

In the opening post of this series, I joined Chris Hoff and others in arguing that cloud computing will change the way we package server software, with an emphasis in lean "just enough" systems software. This means that the big, all-purpose operating system of the past will either change dramatically or disappear altogether, as the need for a "handle all comers" systems infrastructure is redistributed both up and down the execution stack.

The reduced need for specialized software packaged with bloated operating systems in turn means the virtual server is a temporary measure; a stopgap until software "containers" adjust to the needs of the cloud-computing model. In this post, I want to highlight a second reason why server virtualization (and storage and network virtualization) will give way to a new form of resource virtualization.

I'll start by pointing out one of the unexpected (for me at least) effects of cloud computing on data center design. Truth be told, this is actually an effect of mass virtualization, but as cloud computing is an operations model typically applied to virtualization, the observation sticks for the cloud.

Today's data centers have been built piecemeal, very often one application at a time. Without virtualization, each application team would typically identify what servers, storage and networking were needed to support the application architecture, and the operations team would acquire and install that infrastructure.

Specific choices of systems used (e.g. the brand of server, or the available disk sizes) might be dictated by internal IT "standards," but in general the systems that ended up in the data center were far from uniform. When I was at utility computing infrastructure vendor Cassatt, I can't remember a single customer that didn't need their automation to handle a heterogeneous environment.

But virtualization changes that significantly, for two reasons:

• The hypervisor and virtual machine present a uniform application programming interface and hardware abstraction layer for every application, yet can adjust to the specific CPU, memory, storage, and network needs of each application.

• Typical virtualized data centers are inherently multitenant, meaning that multiple stakeholders share the same physical systems, divided from one another by VMs, hypervisors, and their related management software.

So, the success of applications running in a virtualized environment is not dependent of the specialization of the underlying hardware. That is a critical change to the way IT operates.

In fact, in the virtualized world, the drive is the opposite; to create an infrastructure that drives toward homogeneity. Ideally, rack the boxes, wire them up once, and sit back as automation and virtualization tools give the illusion that each application is getting exactly the hardware and networking that it needs.

Now, if the physical architecture no longer needs to be customized for each application, the question quickly becomes what is the role of the virtual server in delivering the application's needs. Today, because applications are written against operating systems as their deployment frameworks, so to speak, and the operating systems are tuned to distribute hardware resources to applications, virtual machines are required.

But imagine if applications could instead be built against more specialized containers that handled both "glue" functions and resource management for that specialization--e.g., a Web app "bundle" that could deal with both network I/O and storage I/O (among other things) directly on behalf of the applications it hosts. (Google App Engine, anyone?)

A homogeneous physical architecture simplifies the task of delivering these distributed computing environments greatly, as there is a consistency of behavior from both a management and execution perspective. However, as it turns out, a homogeneous virtual container environment has the same effect.

So, if the VM isn't hiding diversity at the hardware layer, or diversity at the software layer (which is hidden by the "middleware") what is its purpose? Well, there is still a need for a virtual container of some sort, to allow for a consistent interface between multiple types of cloud middleware and the hardware. But it doesn't need to look like a full-fledged server at all.

Thus, the VM is a stopgap. Virtual containers will evolve to look less and less like hardware abstractions, and more and more like service delivery abstractions.

In my next post, I want to look at things from the software layers down, and get into more detail about why applications will be created differently for the cloud than they were for "servers." Stay tuned.

(Credit: James Martin/CNET)

SAN FRANCISCO--The claim has been made in the last couple of weeks that cloud computing has reached the top of analyst firms' famous hype cycle and is a top-of-mind issue for most IT organizations.

That's a bit misleading, as the interest in cloud computing is often taken out of context, and when you bring virtualization into the picture, that interest seems to remain exploratory rather than strategic.

Amazing innovation is happening in both public- and private-cloud offerings, and the overwhelmingly positive response to cloud computing--in particular to Amazon's top-notch Elastic Compute Cloud, Simple Storage Service, and related offerings, as well as Google Apps and the first generation of software-as-a-service superstars, such as Salesforce.com.

But the critical truth--that interest in virtualization technologies currently outweighs interest in the cloud-computing model--has been evident at trade shows I've attended over the the last several months targeting subjects ranging from networking to next-generation data centers to cloud computing itself, and it has hit home here at VMworld this week. The bottom line is that virtualization is where the money is this summer; cloud computing isn't.

Technology trends follow the patterns described by the science of complex adaptive systems. There is constant change and mutation, and there is a feedback loop that encourages stronger innovations to survive and grow while killing weaker ones, yet somehow, the system maintains a working balance that doesn't get too chaotic to manage or too ordered to allow innovation.

As with any complex adaptive system, traits that eventually come to dominate the system tend to start small: a single mutation, or the introduction of a small number of invasive foreign entities, for example. In the case of the "invasive" cloud computing model, the "DNA" is strong.

Amazon Web Services proves that you can get your infrastructure over the Internet. Salesforce.com proves you can run your business relationships through a browser. Both public and private clouds introduce flexibility and efficiency into IT services.

Cloud-computing bellwethers
Cloud computing is definitely in your future, in one form or another. It probably already plays a strong role in your day-to-day computing experience. That said, when you measure audiences at technology trade shows such as Cisco Live and Interop, you see where the real interest of the everyday IT professional is. At VMworld, the audiences at virtualization-related sessions have been consistently larger than those at cloud-centric sessions.

Recent cloud-only conferences have remained quite small--typically in the tens or hundreds of participants--in comparison to their brethren, and cloud-focused sessions at larger shows have been attended by fewer people their virtualization peers. Several of my cloud-focused colleagues have even noted that some shows end up with the same vendors pitching to each other over and over again.

Without a doubt, this is simply an indication of the current stage in which we find ourselves in the long evolution from internal data centers to cloud-centric operations. The ratio of interest will change (or, more appropriately, converge). But if you want to get into the head of most IT tech geeks today, you need to address the subject of virtualization first, then acknowledge cloud computing as a future target.

The best evidence I can personally attest to are the breakout sessions and panels in which I've participated. I have been giving two basic talks this summer, one focused on cloud computing's future ("Achieving the Intercloud"), and one about the journey from virtualization to cloud computing. Without a doubt, sessions with the term "virtualization" in the title have seen the best attendance, whether measured by room capacity or interaction after the talk.

Transitions ahead
What does that mean to the average cloud enthusiast? Well, for one thing, it remains important to see cloud computing as a transition--an operations model that requires addressing technology and cultural issues before widespread adoption. The good news here? Current trends in virtualization, automation, and early cloud offerings are forcing most of those issues to be faced head-on.

It also highlights how much work is ahead of us in helping those responsible for application operations see the value in cloud environments. This education will be greatly accelerated this year, thanks to the amazing work that customers large and small are doing, especially in public clouds. However, it will also require technologies that address the concerns that many have about moving virtualized workloads into someone else's infrastructure.

I'm betting that at this time next year (or the following year, at the latest), most of the convergence of virtualization and cloud interest will have happened, with the exception of the continued interest that service providers and enterprise data center operators will have in the physical infrastructure and management systems needed to provide cloud services.

It will be harder and harder to tell the difference between a talk discussing how to manage an application running in a virtual machine and one discussing how to manage a cloud workload. Many management vendors will demonstrate tools that manage virtualization (such as VMware vSphere) and public cloud services (especially Amazon's EC2 and S3) at the same time, with the same interfaces. Long lines will be form for topics that will have little to do with who owns the infrastructure or how it is paid.

At that point, the decoupling of physical infrastructure management and virtual workload management will nearly be complete--and the cloud-computing DNA will really begin to take over.

Nick Carr's classic vision of cloud computing, The Big Switch, spent a lot of time exploring the evolution of the electric utilities in the early part of the 20th century. That history is a powerful one, and one that shows the true value that can be derived from centralized generation and distribution of a critical commodity.

However, some have taken electricity as an analogy to cloud adoption to an extreme, and declared that there will be a massive and sudden shift from corporate data centers to entirely external cloud computing environments--public cloud utilities, if you will. They are wrong, and the reason why they are wrong can be captured in a single simple statement.

Data is not electricity.

Here is the fundamental difference between data and electricity: With electricity, I don't care what electrons pushed the electrons that ultimately come out of the socket. I also don't care that if I were to generate power and supply it to the grid (through, say, solar panels on my home) who might take that electricity and store it in a battery someplace. An amp is an amp is an amp.

With the cloud, however, I care about exactly which bits come out of my ethernet port. Furthermore, if I generate data and put it out on the Internet, I care exactly where and how my data is stored, and who can have access to it. The Internet is not a shared information grid, its a shared network for transmitting information from one specific point to another. There is a difference.

While the physical infrastructure we use to deliver information technology might be getting commoditized, the information itself isn't.

Thus, "trust" becomes the biggest problem to be solved in cloud computing. The value of the external cloud is worthless if it can't be trusted. The speed and agility provided to developers and operators alike just can't be leveraged if cloud systems can't be secured and audited, the data stored in a way in which the accountable parties can control what happens to it, and the laws of the land protect the cloud vendor, cloud customers, and (perhaps most importantly) the privacy and safety of all of us.

And there's the rub. What we have right now is a multifaceted problem: until there is some way of consuming the cloud with verifiable security, control, service levels and compliance, much of the most valuable data in business today will not move to external clouds. It just won't.

Don't get me wrong, I truly believe that there will be some amazing parallels between the evolution of IT and the move from mechanical systems to on-site generators to centralized utilities that forms the history of electric utilities.

Over time, I do actually believe that much of enterprise computing will find its way out of corporate data centers, and into the cloud. However, I also believe that such migration will take place over several decades, and that there are tremendous hurdles yet to be overcome to get us there.

The technical hurdles are the easiest to target, though the solutions will likely be quite difficult to implement. For example, check out the cloud security API proposal known tentatively as A6. (Also check out the excellent exploration of a REST implementation of A6 on the Ironfog blog.)

However, even with something like A6, the laws of the United States and the European Union do not provide the same protections for external cloud storage that they do for data stored in house. That alone may be the single biggest difference between electricity and data.

While electricity can power commerce, data can power politics.

That alone will encourage enterprises to keep a lot of data close to home, and out of the public cloud utilities.

IBM launched late Monday a new portfolio of products and services for the enterprise cloud computing market, which the company claims builds on lessons learned from earlier cloud initiatives.

Targeted at providing standardized platforms for specific computing workloads, the products and services, launched under the Smart Business and IBM CloudBurst monikers, aim to change the way IT organizations build and deliver IT services.

"Cloud is an important new consumption and delivery model for IT and business services. Large enterprises want our help to capitalize on what this model offers in a way that is safe, reliable, and efficient for business," Erich Clementi, general manager of enterprise initiatives at IBM, said in a statement. "Today's Smart Business announcement demonstrates that we take this responsibility seriously with cloud investment and solutions targeting the early opportunity."

I spoke with Dennis Quan, director of autonomic computing at IBM, and asked him to break the announcement down with a little more detail. Quan started by noting that IBM has been pursuing cloud and autonomic computing initiatives for some time now and that these initiatives have taught the company lessons that were invaluable in developing Smart Business.

"For instance," said Quan, "new workloads like large-scale business analytics and information processing are driving new specialized approaches to computing."

Quan noted that standardizing these approaches, through automation and service management, is critical to meeting new IT demands.

Initially, IBM is focusing on two core workload types in the Smart Business offerings: development/test and virtual desktop infrastructure (VDI). According to Quan, the company will expand the list of workload offerings over the coming months and years.

Quan highlighted three delivery models for Smart Business cloud products and services:

• Public cloud. IBM will provide its Smart Business portfolio as software services delivered directly from its IBM Cloud data centers located around the world.

• Private cloud services. For Smart Business workloads, customers can engage IBM Global Services to assist them in building cloud computing infrastructures within their own data centers.

• CloudBurst private cloud infrastructure. Initially only available for development/test workloads, IBM will offer a 42U data center rack of pre-installed and configured hardware and software as a "drop-in" private cloud option.

Data Center Knowledge had some more details about the CloudBurst rack:

The basic CloudBurst package includes:

• 1 42U rack
• 1 BladeCenter Chassis
• 1 3650M2 Management Server, 8 cores, 24GB RAM
• 1 HS22 CloudBurst Management Blade, 8 cores, 48GB RAM
• 3 managed HS22 blades, 8 cores, 48GB RAM
• DS3400 FC attached storage
• IBM CloudBurst service management pack
• IBM Tivoli Provisioning Manager v7.1
• IBM Tivoli Monitoring v6.2.1
• IBM Systems Director 6.1.1 with Active Energy Manager; IBM ToolsCenter 1.0; IBM DS Storage Manager for DS4000 v10.36; LSI SMI-S provider for DS3400
• VMware VirtualCenter 2.5 U4; VMware ESXi 3.5 U4 hypervisor

James Staten, principal analyst at Forrester Research, told me that IBM has an advantage here.

"IBM came to these solutions from a point of credibility based on conversations they started over a year ago," said Staten. "Many other systems vendors haven't done that, and it could hurt them in the long term."

Staten also noted, however, that IBM has chosen to handle the public cloud elements of Smart Business entirely on its own, choosing to compete with service providers rather than partner with them. This could put IBM into direct competition with some large customers, such as telecommunications companies and large hosting providers, according to Staten.

The Smart Business services are available now, while the IBM CloudBurst system will ship Friday.

One of the most common questions I get from those exploring cloud computing for the first time is "what is the difference between cloud computing and virtualization?" It is an excellent question, as most IT departments are currently exploring the ways in which virtualization enables automation and provisioning agility. Given the fact that cloud is often touted for providing similar benefits, it can be confusing to understand why the two terms aren't equivalent.

My response to that question requires a bit of explanation, so let's step through the differences between the two concepts.

Virtualization is a technology.

(Credit: CNET/James Urquhart)

When you run software in a virtual machine, the bits that represent the program's instructions run through a layer of software that "pretends" to be a dedicated server infrastructure, the hypervisor. The hypervisor is the heart and soul of server virtualization, and is the enabler of the consolidation and agility values that virtualization brings to the data center.

It is because of the hypervisor that virtualization is the true disruptive technology that enables cloud computing on a massive scale. Hypervisors allow servers to be multi-tenant without rewriting applications to be multi-tenant. Hypervisors allow operating systems and applications to install to a consistent hardware profile, even though they end up running on a variety of actual physical system implementations. Hypervisors also allow servers to be manipulated by software APIs, which greatly simplifies the act of automating IT operations.

Cloud computing is an operations model, not a technology.

When you run an application in a public or private cloud, there is no "cloud layer" that your software must pass through in order to leverage the physical infrastructure available to it. In the vast majority of cases, there is probably some virtualization involved, but the existence of hypervisors clearly does not make your data center resources into a cloud. Nor is the fact that Amazon EC2 uses Xen hypervisors the reason that they are a cloud.

What makes a cloud a cloud is the fact that the physical resources involved are operated to deliver abstracted IT resources on-demand, at scale, and (almost always) in a multi-tenant environment. It is how you use the technologies involved. For the most part, cloud computing uses the same management tools, operating systems, middleware, databases, server platforms, network cabling, storage arrays, and so on, that we have come to know and love over the last several decades.

Specific technologies, of course, gain significant importance in a cloud computing environment, such as policy-driven automation, metering systems, and self-service provisioning portals. However, all of these technologies--with the possible exception of the self-service portal--existed before cloud computing became a much hyped paradigm.

There is no doubt cloud borrows much from long established technologies. It is also true that cloud has borrowed from many long standing operations models, such as mainframe service bureaus. However, the combination of on-demand, at scale, in a multi-tenant infrastructure is relatively unique for the post client-server era, and is the reason why cloud computing is disruptive, rather than just another operations fad.

Update: Corrected Reuven Cohen's title and added link to Chris Hoff's post.

Update 2:The NIST has added a Web page with links to the definition, and an email address where one can send comments.

Reuven Cohen, CTO of cloud infrastructure vendor Enomaly, recently posted a review of his trip to Washington, D.C. to speak to a variety of federal officials about the potential for cloud computing in government. Reuven points out that the enthusiasm with which the federal government is pursuing the cloud may in fact be putting the private sector to shame.

And it makes sense--my own trip to Cleveland for Collaboration Technology and Engaging the Campus 2009 at Case Western Reserve University showed me that the public sector is eager to get rid of data centers in order to focus funds and effort on delivering value to their respective "customers." For higher education, it appears that SaaS and collaborative technologies stand to benefit greatly from this trend. I would expect the same from most nondefense government agencies.

Reuven also notes that one of the most impressive artifacts from his trip was "a draft definition for federal use of cloud computing" from the National Institute of Technology and Standards, a nonregulatory arm of the Commerce Department. I'll include the definition in its entirety at the end of this post

Reuven argues (I think rightly) that the feds pretty much have this definition well in hand at this point:

...(The NIST's) definition of cloud computing will be the de facto standard definition that the entire US government will be given...In creating this definition, NIST consulted extensively with the private sector including a wide range of vendors, consultants and industry pundants including your truly. Below is the draft NIST working definition of Cloud Computing. I should note, this definition is a work in progress and therefore is open to public ratification & comment. The initial feedback was very positive from the federal CIO's who were presented it yesterday in DC. Baring any last minute lobbying I doubt we'll see many more major revisions.

Chris Hoff reviewed the definition on his Rational Survivability blog, and notes one key disappointment with Reuven's claim that the definition is open to public review:

...for being "...open to public ratification & comment," I can't seem to find it anywhere except for references to its creation as a deliverable in FY09 in a presentation from December, 2008. I searched NIST's site, but perhaps I'm just having a bad search day.

I went looking as well, and also failed to find the "public review" process and/or site. If anyone reading this knows where to find it, please comment below.

All in all, I love what I read here. It goes well against the definition we have been using at Cisco Systems (which you can read in an earlier post). It also sounds like it jibes well with Chris Hoff's work on the Cloud Security Alliance guidance paper. Both the fed and CSA definitions are a little long, but you know what? I can live with that if they can drive concensus and further the conversation past this marketing infighting the "cloud-o-sphere" has been experiencing for the last year.

The one thing I was initially concerned about was the introduction of the "community cloud" concept, which is defined as a cloud "shared by several organizations and support(ing) a specific community that has shared concerns." My unease was the same as the discomfort I had with Hoff's "Managed Cloud" concept--they are both just variants of "Private Clouds" targeted at specific types of implementations.

However, I'm beginning to believe that subdividing "private cloud" for a few specific use cases makes some sense. "Community cloud" is certainly something with a specific, useful connotation. I think "managed cloud" also fits that bill. As long as they are used consistently, I think both are valuable terms--and there probably are others.

Anyway, take a look at the NIST definition, and let me know what you think.

Draft NIST Working Definition of Cloud Computing

4-24-09

Peter Mell and Tim Grance - National Institute of Standards and Technology, Information Technology Laboratory

Note 1: Cloud computing is still an evolving paradigm. Its definitions, use cases, underlying technologies, issues, risks, and benefits will be refined in a spirited debate by the public and private sectors. These definitions, attributes, and characteristics will evolve and change over time.

Note 2: The cloud computing industry represents a large ecosystem of many models, vendors, and market niches. This definition attempts to encompass all of the various cloud approaches.

Definition of Cloud Computing:

Cloud computing is a pay-per-use model for enabling available, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is comprised of five key characteristics, three delivery models, and four deployment models.

Key Characteristics:

On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed without requiring human interaction with each service's provider.

Ubiquitous network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Location independent resource pooling. The provider's computing resources are pooled to serve all consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. The customer generally has no control or knowledge over the exact location of the provided resources. Examples of resources include storage, processing, memory, network bandwidth, and virtual machines.

Rapid elasticity. Capabilities can be rapidly and elastically provisioned to quickly scale up and rapidly released to quickly scale down. To the consumer, the capabilities available for rent often appear to be infinite and can be purchased in any quantity at any time.

Pay per use. Capabilities are charged using a metered, fee-for-service, or advertising based billing model to promote optimization of resource use. Examples are measuring the storage, bandwidth, and computing resources consumed and charging for the number of active user accounts per month. Clouds within an organization accrue cost between business units and may or may not use actual currency.

Note: Cloud software takes full advantage of the cloud paradigm by being service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability.

Delivery Models:

Cloud Software as a Service (SaaS). The capability provided to the consumer is to use the provider's applications running on a cloud infrastructure and accessible from various client devices through a thin client interface such as a Web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Cloud Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created applications using programming languages and tools supported by the provider (e.g., java, python, .Net). The consumer does not manage or control the underlying cloud infrastructure, network, servers, operating systems, or storage, but the consumer has control over the deployed applications and possibly application hosting environment configurations.

Cloud Infrastructure as a Service (IaaS). The capability provided to the consumer is to rent processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly select networking components (e.g., firewalls, load balancers).

Deployment Models:

Private cloud. The cloud infrastructure is owned or leased by a single organization and is operated solely for that organization.

Community cloud. The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations).

Public cloud. The cloud infrastructure is owned by an organization selling cloud services to the general public or to a large industry group.

Hybrid cloud. The cloud infrastructure is a composition of two or more clouds (internal, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting).

Each deployment model instance has one of two types: internal or external. Internal clouds reside within an organizations network security perimeter and external clouds reside outside the same perimeter.