The Wisdom of Clouds

Cloud computing providers have a difficult marketing challenge, in my opinion. Think about it--no matter what service model or deployment model a provider is delivering, they must differentiate their service while meeting the "commodity" needs of as many customers as possible. It would seem these businesses are stuck between providing least common denominator service capabilities and being accused of intentional customer lock-in.

(Credit: Jake Shepherd/Flickr)

From a customer perspective, it is equally challenging when one is "looking for servers and storage" and must choose between a bunch of services that essentially run Linux or Windows and store your files. How does one choose? How do the cloud providers set themselves apart in the customers' eyes?

Unfortunately, I've been inundated of late by an increasing number of cloud service announcements that lack any sense of differentiation. Hosting providers are announcing "on-demand server capacity billed on a pay-as-you-go basis." Platform vendors are simply announcing what language they support, and how much they charge for services. Software-as-a-Service vendors have the easiest job to differentiate service, as they can do so based on functionality alone if they wish, but even there some vendors struggle to differentiate themselves by anything other than the fact they run as a cloud service.

This has to change. Forrester's James Staten is telling us that clients are getting "cloud weary." I believe a lot of this has to do with the ridiculousness of "cloudwashing" that we've seen for some products and services, and the relative monotony of pitches for things are arguably cloud services, especially in the IaaS space.

Below is a list of five key categories of competitive differentiation for cloud computing. It is not a complete list, nor do I think all vendors would look at this question in the same way. However, if you are looking to acquire cloud services, these are the elements I think you start with as you evaluate any service, be it SaaS, PaaS, or IaaS. If you are selling these services, consider this an outline for your next requirements document.

1. Ease of operations. Yeah, I could have kept things simple and just said "ease of use," but "use" in the cloud computing service sense is much more than how humans interact with the system. For instance, how does a company with hundreds of applications in the cloud strewn across a dozen or more vendors monitor and manage those applications to manageable service levels?

   And yes, phenomenal user interfaces will set some providers apart from others, but it will be the "behind the scenes" interfaces--such as APIs, publish and subscribe event streams, transparency and auditability systems, etc.--that will make the most significant differences between providers.

   Will many of the aspects of "ease of operations" be standardized? Sure. The Open Cloud Computing Interface (OCCI) is an example of an attempt to deal with a large part of this challenge. However, differentiation will still be possible through extensions, quality of features and--yes--some custom interfaces.

2. Configurability. One of the things about today's best-known cloud computing environments is that they are essentially infrastructure and software architecture frameworks that dictate a lot about the application architectures that can be built on them. For example, the Amazon Web Services Elastic Compute Cloud (EC2) allows each server to be on one widely shared network. No separation of management traffic from DMZ traffic here (at least not explicitly from the point of view of the OS).

   No, application architects are instead forced to consider how they would build and operate their application in the infrastructure architecture given them. Good books have been written with this in mind, but ultimately the complexity of the problems we wish to solve with information technology will dictate the amount of configurability we require from our infrastructure systems--even if they are delivered as a service by a third party.

   The low-hanging fruit here for IaaS vendors are things like network architectures, data storage options, server options and so on. Also useful here are services that enhance the infrastructure, like security systems, message queueing, and storage tiering.

3. Performance. One public relations contact I got recently was quite interesting. A hosting company sent me an email indicating that they have an increasing number of customers coming to them from AWS, and finding that their applications actually perform better in the former than the latter. I haven't confirmed the truth of that claim, but it is an interesting claim nonetheless.

   Processing speed, memory speed, storage access, read and write speeds, latency, bandwidth--these are all things that are tunable by the cloud provider, either through technology acquisition, or through superior engineering and operations expertise. And, as with servers and storage, the fastest speeds per dollar spent will generally win.

   I would not be surprised if we saw a cloud performance war, similar to the RDBMS benchmark wars, especially in the IaaS category (though it would make sense in the PaaS and SaaS categories as well).

4. Reliability and security. I debated combining these two elements, as they represent different aspects of the same concept. However, that core concept--risk mitigation--is at the heart of so much of the decision over whether public cloud services are better than private data centers, that I think they will often be viewed through the same lens.

   Companies will need time to demonstrate differentiation in both of these categories, but features can be introduced today to increase the transparency of both operations and security in any provider. Redundant distributed data stores, "early warning" DDoS detection events, auditability APIs; these are all features that would "open the kimono" in a controlled fashion and increase customer's ability to trust that their provider has made the protection and availability of their data and functionality a core competency.

5. Customer service. After I wrote my closing post for the "big rethink" series, Kevin Magee, COO of ZeroTouch IT, wrote a post in which he noted several additional predictions for the effect of cloud computing on IT. Most notably, he pointed out that cloud will change "[h]ow Vendor Relationship Management will become a key discipline in IT organizations." Amen, brother, and I completely agree.

   In a tongue-in-cheek post from early 2008, I noted that system administrators should "get good at waiting on hold for customer service representatives." In reality, there is truth to that, but the providers have a lot of room to craft that experience.

   One thing they can do is advance the technical leading edge in terms of customer self-service and operations transparency. (Hmm. Has anyone else noted how often 'transparancy' comes up in this discussion.) I noted some ideas about this in a previous post. Smart providers will find others.

Cloud computing is one of those truly disruptive market opportunities that makes or breaks companies. The winners will find ways to differntiate. Those that don't almost certainly can't win. So, please, no more press releases that fail to differentiate in any meaningful way.

With a nod toward the heterogeneous application development environments that exist in most enterprise IT departments, IBM on Wednesday launched a pair of services targeted at building cloud applications.

The first, the IBM Smart Business Development and Test on the IBM Cloud, is a cloud service hosted in IBM's data centers that provides tools and interfaces designed to support developers using Java, .NET, and Open Source environments. This service provides computing and storage capacity, and support for WebSphere middleware, Rational Software Delivery Services, and its Information Management database. It also provides "pre-configured integrations" of some Rational services based on IBM's Jazz framework, its collaborative software platform.

There are no pre-configured integrations announced for third-party or open source tools or languages.

In addition to the Smart Business offering, IBM is adding private cloud-targeted tools and services to the IBM Rational Software Delivery Services for Cloud Computing offering. These tools and services target three key elements of the development and testing of cloud applications:

• Agile development services, aimed at enabling collaborative development and testing through a set of best practices.

• An integrated set of services for test management and planning and test lab management.

• Tools, such as IBM Rational Asset Manager, which are targeted at increasing the efficiency of distributed application development teams.

By combining the expertise gained by IBM's Global Services organizations and the Rational Lab Services team in building and delivering development and test tools and practices in IBM-based clouds, the company hopes to become a one-stop shop for companies looking for a solid return on investment from adopting the cloud model in development and test.

IBM Smart Business Development and Test on the IBM Cloud can be accessed as a free beta, and the IBM Rational Software Delivery Services for private clouds are also available in beta through the companies sales force.

Recent failures to protect consumer data stored on the Internet (aka "the cloud") point to an alarming gap between the value of that data and the care with which some vendors treat that data.

Microsoft subsidiary Danger failed to put in even adequate safeguards for its customers' data. Amazon Web Services failed to discover an obvious problem that kept a loyal customer down for 20 hours. Coghead's agreement to sell to SAP without any provisions to continue support for existing customers.

(Credit: DB King/Flickr)

The truth is that cloud computing means that now, more than ever, IT operations is a profession that has a very real economic and quality-of-life effect on its consumers--in very many ways much like health care or the law. I think it's time we hold ourselves as individual and organizations to similar standards that we expect from doctors, lawyers, and law enforcement. Our ethics must reflect an understanding of the responsibility we are being granted by the rest of society.

The instances above are examples of companies failing to follow well-known professional protocols, or putting the needs of the business ahead of the needs of the client. Heck, look at just about any cloud operator's terms of service, and you see paragraph after paragraph of text that basically states, "If something goes wrong, you can't blame us."

I think its time to change this attitude. I see a couple of options, neither of which I love, to achieve this. I'd love to hear from some innovative thinkers on others.

1. Pass "cloud consumer protection" laws. This was something that was briefly explored after I wrote my "Cloud Computing Bill of Rights" post in August of 2008. However, the folks who got involved at that time weren't a) vendors or b) policymakers, so we didn't get far.

   The biggest issue with using the law to enforce professional culpability is that it requires government bureaucracy for enforcement. That bureaucracy doesn't exist today, and would be expensive to create.

2. Allow for "cloud malpractice" suits. Oh, I know, I know. Most of you in the IT profession are squirming in your chairs right now, ready to jump down my throat about how medical malpractice has created as many problems as it has solved. Again, I don't love this option, either.

   However, if Danger had lost arguably hundreds of thousands of dollars worth of data (or more) because it didn't tangibly fear the reprisals that would come if it lost it, it would be nice to see a big ol' sledgehammer of justice ready to rain down. I'm sorry, but failure to follow known professional practices is malpractice, and malpractice suits exist to punish those who forget that.

Let me reemphasize that I don't love either option, but I do know something has to change. The public is placing an extremely high level of trust on "cloud" services, and there has to be more than the simple threat of loss of revenue to reflect this. What do you think? Is it time to wield a big stick with respect to cloud service operations, or will the natural evolution of the market do the job for us?

Was the failure of Microsoft acquisition Danger to protect the data of Sidekick smart phone users (its core customer base) a failure of cloud computing?

This question was argued vehemently earlier in October when the outage was first reported. Several articles appeared, including some on CNET and ZDNet, that indicated that the Danger failure should give users pause before putting their data into "The Cloud." On the other hand, several of us who have been involved in cloud-computing implementations were appalled at the use of the term "cloud" in regard to Danger. Clearly, as a provider, Danger was not practicing core cloud-computing principles.

(Credit: Ed Uthman/Flickr)

Lori MacVittie, of application delivery networking vendor F5 and one of my favorite bloggers on the effects of the cloud-computing model on application control systems, wrote a post recently that summed up what a lot of us realized as the aftermath of Danger unfolded; that the word "cloud" is now being used in two increasingly divergent senses.

MacVittie puts it so well, I'll let her spell it out for you:

Thanks to the nearly constant misapplication of the phrase "The Cloud" and the lack of agreement on a clear definition from technical quarters I must announce that "The Cloud" is no longer a synonym for "Cloud Computing". It can't be. Do not be misled into trying, it will only cause you heartache and headaches. The two no longer refer to the same thing (if they ever really did) and there should be no implied - or inferred - relationship between them. "The Cloud" has, unfortunately, devolved into little more than a trendy reference for any consumer-facing application delivered over the Internet.

Cloud computing, on the other hand, specifically speaks to an architectural model; a means of deploying applications that abstracts compute, storage, network, and application network resources in order to provide uniform, on-demand scalability and reliability of application delivery.

In other words, "The Cloud" is a consumer concept. It represents a way of looking at the seemingly (but not really) new concept of using commercial Internet applications to create, update, and delete personal and/or professional information. It represents a tactical decision on the part of the consumer to trust third parties with data access, management, and security.

With that in mind, it's no wonder Richard Stallman, Larry Ellison and others are less than wowed by cloud computing. That model is both nothing new, and something everyone needs to understand has consequences to the way valuable data is handled.

On the other hand, "cloud computing" is a systems concept--an operations model that is mainly visible to those who build, deploy, and/or operate applications. End users (or "consumers" as Lori explains above) do not see "cloud computing."

Have there been cloud computing failures? Sure. The denial of service attack on Bitbucket (hosted on Amazon Web Services) was arguably an excellent example. There have been and will be more.

William Vambenepe may have explained a relationship between The Cloud and cloud computing months ago, but in slightly different terms. In a post titled "Exploring 'IT management in a changing IT world,'" Vambenepe describes an interesting way to conceive of the different facts of the term "cloud":

There are two main parts in the "Cloud" buzzword: the "Technical Cloud" and the "Business Cloud". The "Technical Cloud" is where we take virtualization and standardization (of machines, networks and application infrastructure) and turn that mind-boggling complexity into a manageable system that can be programmed to deliver applications (Cisco recently called it "Unified Computing"; HP, IBM and others have been trying to describe and brand it for a long time). Building on these technical capabilities comes the second part of "Cloud", the "Business Cloud". It is the ability to use infrastructure owned by a third party (presumably one able to leverage economies of scale) and all the possibilities this opens in the business realm. That's what "Cloud" started as, back when it was known as "Utility Computing" and before it was applied to everything under the sun. A recent illustration of the relationship between the "Technical Cloud" and the "Business Cloud" is the introduction of vCloud by VMWare (their vision includes using VMotion technology, a piece of the "Technical Cloud", not just to move machines between neighboring hypervisors but between organizations, enabling the "Business Cloud").

In the days since the Danger event, I've found my own ability to interpret where others come from in the "cloud" discussion has been made much easier by understanding this distinction. It's just too bad that the distinction will confuse non-technical people more than help them.

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.

I'm one of many who believe this week's announcement of Apps.gov--a portal targeted at reducing the cost and effort for public agencies to acquire cloud services--is forcing all of IT to face the economics of cloud computing.

Apps.gov, a federal government initiative out of the General Services Administration, demonstrates several concepts that have been the dream of many private enterprise IT departments for some time, but have been successfully executed by very few. Here are the five trends that I think Apps.gov demonstrates, and why you should pay attention:

1. The IT service catalog. For years, business managers--sick of the bureaucracy inherent in most service provisioning processes--have imagined a world in which they could select desired IT services from a catalog and click a button to complete the transaction. This Amazon-like service acquisition experience has many appealing advantages over process-heavy provisioning processes.

   For one thing, it demonstrates the power of applying superior consumer Web experiences to traditionally human IT processes. However, it also enables--heck, encourages--agencies to explore and validate the cost savings that are purported to be inherent in cloud computing.

   This should be great news to IT service catalog vendors like NewScale and the like. When CEOs see the App.gov interface--rightly or wrongly--many will wonder why they can't give their organization the same experience.

2. Core categories of service from an end user's perspective. One of the things that greatly simplifies the home page for Apps.gov is the simple four-category breakdown of cloud service offerings. This makes it much less intimidating for users to go exploring to see what they can find and gives vendors an opportunity to consider how to best position their offerings.

   What the categories are is "Business Apps", "Produtivity Apps", "Cloud IT Services," and "Social Media Apps."

   What they aren't is "SaaS," "PaaS," and "IaaS" (the so-called "SPI" model). While the latter categorizations helps technologists classify the types and audiences of various cloud services, they mean nothing to most end users of those services (especially SaaS services).

   I will be the first to admit that categorization of anything as complex as the IT market is difficult, if not impossible. But my initial experience with this site tells me these groupings aren't too bad. I would expect to hear more IT organizations and vendors talking about service delivery in these terms instead of the SPI model.

3. Automation and/or removal of bureaucracy. This to me is perhaps the most intriguing thing about Apps.gov. When federal CIO Vivek Kundra announced Apps.gov this week, he noted that the site is largely aimed at removing the costs for each agency to acquire cloud services. He gave the example of the Transportation Safety Administration, which was looking to add blogging capabilities to its IT portfolio. The estimated cost to taxpayers: $650,000. Kundra pointed out that consumers can get blogs for free.

   I see two ways bureaucracy is removed through cloud computing and Apps.gov. First, automation will eliminate many of the manual processes that have to be put in place to manage the volume of service requests most agencies experience. Second, the removal of redundant approvals, certifications, price negotiations, service level agreement negotiations, and so on will take out tremendous waste in an organization as large as the federal government.

   Both of these practices can be applied to commercial IT infrastructure as well, and I expect to see many companies watching and learning from the government's experience.

4. "Adopt at your own pace" mentality. Another common mistake made by many enterprises is to look for magic bullets that solve budget, agility, or performance problems. Chuck Hollis, EMC's CTO of global marketing, once told me he sees three ways that companies can move toward the cloud: they can try to move all legacy infrastructure into a cloud model at once, they can put an ultimatum in place that demands that all new work be done in the cloud, or they can experiment with "baby clouds"--small, noncritical projects that can prove both capability and economy, thus rationalizing a steady expansion into more critical application domains.

   I believe that the federal government is in fact taking the third approach, allowing agencies to see what is available, but to adopt those services at their own pace. That's not to say the White House won't put incentives and guidance into future budgets to encourage adoption. In fact, Kundra confirmed that this is indeed the case. However, there is no "mandate" that punishes an agency for working at its own pace and rationalizing its adoption as it goes.

5. Cloud is not defined by who runs it, but by the service provided. Kundra also noted that the government will always run its own infrastructure for some workloads and some data sets, whether for national security or due to the sensitivity of the data. The federal government will build its own clouds, and those clouds will in time be available through Apps.gov. The public sector is one space where the future of private cloud computing is assured.

   I will concede that the U.S. government is practically an IT marketplace in and of itself, but it is surprisingly similar to many industries that must deal with sensitive data, such as the payment card industry, health care, or military manufacturing. As the feds find that balance of public, private, and hybrid cloud services, you'd better believe that the private sector will follow.

Kundra is no slouch. He understands that a transition to cloud computing is a long-term technology goal for, not only Obama's administration, but likely the administration that follows. He also knows that this is a rare opportunity for the federal government to set an example for private industry in no uncertain terms--an example that may go a long way to ensuring the United States sets an example for the rest of the world.