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.

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?

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.

Chris Hoff, my friend and colleague at Cisco Systems, has reached enlightenment regarding the role of the operating system and, subsequently, the need for the virtual machine in a cloud-centric world.

His post last week reflects a realization attained by those who consider the big picture of cloud computing long enough.

He summarizes his thoughts nicely at the opening of the post:

Virtual machines (VMs) represent the symptoms of a set of legacy problems packaged up to provide a placebo effect as an answer that in some cases we have, until lately, appeared disinclined and not technologically empowered to solve.

If I had a wish, it would be that VM's end up being the short-term gap-filler they deserve to be and ultimately become a legacy technology so we can solve some of our real architectural issues the way they ought to be solved.

Hoff goes on to note that the real problem isn't the VM, but the modern operating system:

The approach we've taken today is that the VMM/Hypervisor abstracts the hardware from the OS. The applications are still stuck on top of operating systems that don't provide much in the way of any benefit given the emergence of development frameworks/languages such as J2EE, PHP, Ruby, .NET, etc. that were built around the notions of decoupled, distributed and mashable application "fabrics."

My own observation here is that our current spate of operating systems were designed when competitors were pushing to use the OS as a differentiator--a way of distinguishing one company's product experience from another. OSes started out being targeted at software, providing a way for applications to use a generalized API to acquire and consume the resources they needed.

At the time, computers had one CPU and the logical thing to do was to design a single OS that could run multiple applications, preferably at once. This created the need for additional functionality to both manage resources and manage the applications themselves.

Furthermore, the operating system increasingly targeted not the needs of software, but the needs of people; more specifically, the needs of computing buyers. Take a look at OS X, or Windows, or even "enterprise" Linux distributions today. The number of features and packages that are included to entice software developers, system administrators, or even consumers to consume the product is overwhelming.

However, any given application doesn't need all those bells and whistles, and most OSes are unfortunately not designed to adjust their footprint to the needs of a specific application.

So, the problem isn't that OS capabilities are not needed, just that they are ridiculously packaged, and could in fact be wrapped into software frameworks that hide any division between the application and the systems it runs on.

By the way, that this is exactly why EMC purchased Fastscale last month, as noted by Chuck Hollis, EMC's CTO of global marketing, on the day the acquisition was announced. Simon Crosby, CTO of the data center and cloud division at Citrix, also notes that this change is coming but sees the OS playing a more important transitional role.

This is a critical concept for application developers wondering how cloud computing will affect software architectures. It is also a critical concept for why IT operations professionals need to understand that their roles and responsibilities are changing.

Because of this, I'll be following up with a few posts this week that will expand on this concept and give you much more of a sense of why the operating system, along with most server, network, and storage virtualization is a stop-gap measure as we move to a cloud experience centered on the application user and the developer.

Next on the list is an explanation of why cloud computing drives infrastructure toward homogeneity (at least within a data center) and why that is the bane of server virtualization.

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.

For some time now I've been advocating to my core network provider customers (and anyone else who would willingly listen) a concept that I think is both central to the future of cloud computing and one of the great opportunities this market disruption presents. The idea is simple: who will be the cloud service aggregator to enterprises, large and small?

(Credit: Michael Gray)

Think about it. Even the smallest of businesses require multiple software systems to both meet minimal data management and creative expectations and (I would hope) to establish come competitive differentiation where it counts. Large enterprises scale this need to the hundreds or even thousands of services, meeting the needs of everything from simple departmental database applications to core ERP and CRM systems on which the enterprise itself is managed.

Picking and choosing vendors to meet these needs makes sense; no one vendor is likely to deliver and end-to-end, differentiated IT offering for each and every business it serves. Mix-and-match is the name of the game in the cloud, and it should be expected that every enterprise will have a variety of functionality delivered to it from a variety of cloud service vendors and platforms. Many of which might be on internal cloud systems.

So how does one manage such a hodge-podge of business systems, serving a large number of stakeholders with unpredictable, often dynamic functional, integration and operational requirements?

What I've been advocating is the need for a cloud aggregator and broker service. I don't claim that is unique, or even new. The term "cloud broker" is one piece of this, as is integration, aggregation and customer support services.

Allan Leinwand, founder of open source switch platform, Vyatta, wrote a very well thought out post recently describing a cloud network aggregation business that he nicknamed a CloudNAP (Cloud Network Access Point). His description is of a private networking service that would specialize in delivering value to cloud consuming enterprises in a very specific way:

This new provider -- let's call it CloudNAP (Cloud Network Access Point) -- would solely be in the business of providing a toll road between the enterprise and the public cloud providers. The business of selling connectivity to the Internet, or transit, is a common ISP offering. The CloudNAP transit service would be different, however, in that it would be focused on delivering connectivity solely between enterprises and cloud services providers and not between enterprises or between clouds. In order to make network connectivity to the toll road cost-effective for an enterprise, CloudNAP would offer POPs (point-of-presence) in multiple geographies. Each CloudNAP POP would have dedicated leased lines to the networks of the major cloud services providers such as Amazon Web Services, Microsoft Azure, Google AppEngine, the Rackspace Cloud, etc.

The CloudNAP network could guarantee performance between the enterprise and the cloud by working with the service providers to enable the use of quality-of-service techniques that are not available over the public Internet such a Multiprotocol Label Switching (MPLS) classes for WAN connections or IEEE 802.1p priorities for LAN connections. Perhaps CloudNAP could even restrict the use of connections to cloud service protocols and services like REST (representational state transfer) or HTTPS (Hypertext Transfer Protocol Secure) -- thus preserving the network for its intended use by the enterprise.

I think Leinwand is on to something here, though I think he is a little bit pessimistic about what could be done with existing core Internet services. I am certainly not sure that an independent business would--or even could--win at this game. My own thinking has led me to believe there are two likely winners in the cloud network brokering game: either the biggest cloud infrastructure service providers will be the enterprise's entry point into the cloud, or the telecommunications giants will extend their network service offerings to address cloud computing.

An independent firm would just be too beholden to both the cloud service providers and the ISPs to make the end-to-end story work seamlessly. If such businesses are created and establish footholds, I would predict rapid consolidation through acquisition into one of the two market options I described.

Now, my personal preference would be for the telecoms to take this market, as it would set up independence from the services being provided, assuming there is no attempt to push users into a service wholly owned by the telecom. The telecom option would also allow for aggregation of billing, monitoring, and auditing streams across most if not all of the marketplace. Having Google or Amazon or Microsoft also provide network services to their clouds and those of their partners would in effect lock the customer into a slice of the overall market, which would appear much less desirable.

Unfortunately, for a variety of reasons, the telecoms just aren't seeing this massive opportunity. Instead, they are all working very hard to build "enterprise-ready clouds"--those compute, storage, and occasionally software services that just about every other cloud service provider is targeting with dollar signs in their eyes. There is no doubt in my mind that the telecoms will capture a reasonable share of that overcrowded marketplace.

Add to that an insight into AT&T's revenue model that I got from Joe Weinman, the leader of that company's business portfolio development for emerging technologies (and my fellow panelist at CloudWorld last week). Joe noted once that AT&T does not recognize revenue that is passed on to another business. In other words, if they resell somebody's cloud service, the only revenue that AT&T would recognize would be the cut they took off the top. Thus, according to Joe, they are driven towards building all of these services themselves, as it allows them to recognize the full range of revenue for the services they sell.

Update: Jeff Kaplan of ThinkStrategies, and the moderator of the CloudWorld panel, emailed me to point out an excellent post he wrote covering the telecoms' dilemma in more detail.

However, just imagine for a moment that AT&T and their peers put aside the desire to "out enterprise" Savvis or Terremark or even Amazon or Google, and instead focused on doing what they do best: being the provider of services that act as a gateway to a much wider market of services. Imagine those services are sold much like mobile phone plans, with monthly base charges for a certain level of service, and overages charged by CPU hour or whatever other metric makes the most sense. The service, in turn, provides a single face to almost the entire cloud marketplace.

I personally think that would be a very welcome addition to the existing ISP services offered by the big guys, and something that would make cloud computing palatable to a larger number of enterprises that they would have been otherwise.

Oh, and just imagine if the telecoms were to further extend the Internet infrastructure itself to provide much of the QoS and other services that Leinwand noted. For example, imagine technology that extends the enterprise network into the Internet infrastructure itself, allowing the VPN and other services to behave exactly as if they were under the control of the enterprise network administrators. No need to buy a separate, dedicated private network for your cloud systems, but instead subscribing to a list of services directly through the Internet.

That's something that only the ISPs and telecoms can do, and it is--in my opinion--a requirement for the Inter-Cloud of the future. I only hope one of the core networking greats will take the chance and be the first doorway to the cloud.

VMWare's acquisition of SpringSource this week is a significant development in the history of the Java development platform.

I have been working closely with VMWare for some time now, and I know a little bit about how the company sees its role in the cloud. The acquisition of the commercial open-source middleware/framework company makes perfect sense to me.

SpringSource gives VMWare a development "platform," of sorts, to deliver in VMWare-based cloud services and a unique declarative environment in which to define both application construction and deployment architectures. The vision painted by SpringSource CEO Rod Johnson speaks to an environment in which developers can declare not only how objects should connect with one another, but how they should be packaged into virtual machines and deployed into the virtualized infrastructure:

Working together with VMware we plan on creating a single, integrated, build-run-manage solution for the data center, private clouds, and public clouds. A solution that exploits knowledge of the application structure, and collaboration with middleware and management components, to ensure optimal efficiency and resiliency of the supporting virtual environment at deployment time and during runtime. A solution that will deliver a Platform as a Service (Paas) built around technologies that you already know, which can slash cost and complexity. A solution built around open, portable middleware technologies that can run on traditional Java EE application servers in a conventional data center and on Amazon EC2 and other elastic compute environments as well as on the VMware platform.

Much of the early analysis of this acquisition has focused on how it plays as a counter to Microsoft Azure, which--when combined with the Hyper-V virtualization platform--threatens VMWare's dominance in the enterprise. Forrester Research's James Staten thinks it's much more than that, however:

VMware has a bigger agenda SpringSource helps to fulfill making vCloud bigger than simply an Infrastructure as a Service (IaaS) alternative and keeping Microsoft at bay. Enterprises are already demanding that cloud environments and internal cloud solutions support their hypervisor standard VMware. So it wasn't going to be a stretch to get vCloud adopted, assuming it delivered as promised. But the battle isn't IaaS, it's becoming the equivalent of the operating system for the next generation data center and you can't achieve that aim without applications; and you can't become application-relevant without being relevant to developers.

Redmonk's Stephen O'Grady thinks it's not just about the development and integration, but also about tooling:

When (colleague Michael) Cote and I met with SpringSource CEO Rod Johnson at OSCON a few weeks ago, one of the primary topics of discussion was the development experience. This could wind up one of the unheralded benefits of the acquisition: Rod gets the tooling story. He understands that Microsoft, again, is setting the bar for the development experience by allowing its developers to localize the cloud environment via Visual Studio. With VMware's virtualization capabilities, the tooling story for SpringSource could get very interesting vis a vis cloud development and deployment.

This goes to the vision that has me most excited about the future of cloud computing right now. I think that there are technologies evolving for both public and private clouds that actually give developers and solutions architects just as much control over every element of how their applications are built, deployed, and operated as they have had in the past.

These technologies are a combination of declarative descriptive configuration policies and automated software and systems that can interpret those policies and respond as required. Contrary to Harvard Professor Jonathan Zittrain's well-read New York Times OpEd piece, developers would keep control over their application environments.

SaaS offerings could allow for customization at levels of granularity unthinkable before Spring demonstrated dynamic instantiation. Custom applications deployed to IaaS offerings could declare that they require a isolated networks for backplane communication, connectivity to two different storage systems by name (perhaps even one in the cloud and one through FCoE), or provide monitoring through specific protocols.

By the way, I don't think VMWare is the only company that can achieve this vision. As noted in the earlier quotes, Microsoft is in a great position to allow a similar story for its developers, assuming it partners with the right systems companies to push dynamic configuration beyond Hyper-V into the physical infrastructure layers. .Net and the Microsoft tool set are already quite capable of delivering significant coordination between application development and deployment. Citrix and Red Hat, by contrast, do not yet seem to have such a sophisticated vision.

Oh, and VMWare got cloud monitoring powerhouse Hyperic in the deal as well. More on that in a later post.

I'd love to hear your opinion of the VMWare's acquisition of SpringSource. Is it as important as the cloud pundits and I say it is, or is there little excitement to be found here?

Follow James Urquhart on Twitter.