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?

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.

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.

Update: Paul Albright's title was incorrectly stated as CEO. He is GM and CMO.

Earlier this summer, Jonathan Zittrain wrote a New York Times OpEd piece that discussed his concerns with the cloud computing paradigm. Zittrain stated that, while it may seem on the surface that cloud adoption is as "inevitable as the move from answering machines to voice mail," he sees some real dangers.

(Credit: SuccessFactors)

Zittrain covered the usual concerns about data ownership, privacy, and the access that data placed in the cloud gives governments all over the world--a concern I certainly share. He went on to point out that these problems are solvable "with a little effort and political will," a view that I also adhere to.

To Zittrain, however, the biggest threat the cloud posed to computing wasn't privacy, but innovation--or a lack thereof:

This freedom is at risk in the cloud, where the vendor of a platform has much more control over whether and how to let others write new software. Facebook allows outsiders to add functionality to the site but reserves the right to change that policy at any time, to charge a fee for applications, or to de-emphasize or eliminate apps that court controversy or that they simply don't like. The iPhone's outside apps act much more as if they're in the cloud than on your phone: Apple can decide who gets to write code for your phone and which of those offerings will be allowed to run. The company has used this power in ways that Bill Gates never dreamed of when he was the king of Windows: Apple is reported to have censored e-book apps that contain controversial content, eliminated games with political overtones, and blocked uses for the phone that compete with the company's products.

When I first read Zittrain's words, I was concerned that he had a point--that the future of software would be a few big platform owners controlling user experience and functionality much the same way that Apple has for both the Mac and the iPhone. Where would the next radical disruption come from if none of the platforms would allow disruption?

However, my eyes were opened a little bit last week when I met with Paul Albright and Tom Fischer, CMO and CTO respectively of a business productivity software vendor called SuccessFactors. I went to the meeting expecting to talk cloud, hearing something about how SuccessFactors was going to change the cloud landscape. I'm not a business process guy (anymore), and I thought I was going to be bored to tears by Albright's explanation.

Instead, SuccessFactors wanted to talk to me about what they claimed was a new class of business software--one that would greatly improve business productivity. They called it "business execution software."

My eyes rolled.

To my surprise, however, what I found appeared to be a very innovative way of dealing with organizations, their goals, and their measurement. Unobtrusive, the new SuccessFactors business execution software and its related SuccessCloud SaaS (software as a service) offering aim to leverage the company's extensive experience in business performance measurement and create a real-time monitor of business execution against goals.

Sounds innovative to me.

(It is important to note that SuccessFactors isn't a "pure" SaaS play, but the SuccessCloud services are critical to the business execution story, so it qualifies as a SaaS cloud to me.)

So the question arises: why would one of the most successful SaaS offerings--if not the most successful--work so hard to disrupt the way performance measurement was done? And are there any guarantees that this innovation will continue if cloud computing becomes a dominant paradigm?

The answer came to me this weekend as I contemplated how to measure the SuccessFactors story against Zittrain's prediction. Innovation in SaaS, and probably in PaaS (platform as a service) and IaaS (infrastructure as a service) as well, is driven by competition--the same competition that drove shrink wrap vendors to innovate in the past. However, SaaS has an advantage: upgrades are easier, and all customers are guaranteed to upgrade at the same time, enabling rapid, iterative development and deployment.

Think the barrier to build and release an alternative is insurmountable? Think again. If an entrepreneur thinks they can beat SuccessFactors at their own game, they can build their alternative on Amazon Web Services, or Google App Engine, or Microsoft Azure, or any of a number of cloud platforms and infrastructures. They can build their own SaaS business against that software, or they can simply make the image/code available to be replicated by whoever wants their own instance. The important thing is: the fact that SuccessFactors owns their own data center gives them little advantage.

In the end, it is the ability to deliver application functionality that makes a cloud desirable, not simply the technology used to deliver functionality. So, in the enterprise SaaS category at least, innovation remains alive and well.

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.