Thomas Bittman

I’ve been inundated with inquiries about cloud computing, from vendors and users. A lot of the discussion on cloud computing is about technologies in the cloud, maturity of cloud services, which workloads/services could be sourced in the cloud. I think there is a major challenge that isn’t discussed enough – how are we going to manage cloudsourcing?

If this was a “simple” outsourcing contract, it’s straightforward: we create a contract, with service level agreements, price, etc., etc. But unlike traditional outsourcing, cloudsourcing will be extremely dynamic, and extremely granular (unless you believe that everything will filter through a handful of megaproviders, which I don’t). Sourcing choices won’t be made once every few years, they could be made daily. Even worse, cloudsourcing will not just require finding a service in the cloud that meets business needs for a particular situation, it will likely be about logically doing systems integration – services integration – between many potential cloud service providers.

And the dynamic nature of cloudsourcing won’t only be reflected in internal decisions to use the cloud – the cloud itself will be dynamically changing. Today, one provider might have the best price, the appropriate quality of service. Tomorrow, their costs might rise, they might incur an outage, they might go out of business. Somehow we need to manage these dynamic decisions and the dynamic turmoil in the cloud to our best advantage.

Another issue is that business customers will be confronted with the same kind of opportunity they faced in the early days of client/server – IT says “no”, so the business customers went out and bought their own servers and packaged software. If business customers start making these decisions in the cloud, since they often don’t understand their service level requirements to the level of detail needed to cloudsource, the failures will be rampant.

I believe there are two entities that will be created to respond to this: in large enterprises, they will create a dynamic sourcing team that makes day-to-day decisions about sourcing. They orchestrate the services in the cloud to meet business needs. This team needs to be business- and technology-savvy – a rare mix of skills that we need to generate to cloudsource effectively.

Smaller businesses are even more likely to rely on cloudsourcing, but they will not have the skills needed to orchestrate cloud services efficiently. For them, a breed of service brokers will emerge. These service brokers will be an evolution of today’s VARs/resellers/systems integrators. They will take responsibility for the overall service level requirements in the business. They will likely be skilled in specific industries (and perhaps their unique regulatory requirements, etc.). They will be able to monetize their value by having deeper skill in the cloud market than small businesses can muster, and by leveraging a rapidly changing market to continue to find the best deals to keep costs as low as possible (and still meet service level requirements).

On the opposite side of the equation are businesses who are thriving in the cloud and the connections enabled by the cloud. For them, being “discovered”, finding a market need (even temporary) and filling it – this is how they succeed. It will be the challenge of dynamic sourcing teams and service brokers to sift through the noise and find the best providers – and orchestrate their services.

I’ve had a number of posts on the structure of the cloud computing market, (Can A Cloud Computing Provider Be Too Massive?, Is Google the Mainframe of Cloud Computing?, Partly or Mostly Cloudy?) and I’m getting more and more comfortable talking about three major phases of market evolution. Very simply, I think they look like this:

Phase 1: Monolithic (Early). Early cloud computing services will be based on proprietary/internal architectures – islands of cloud services delivered by megaproviders. This is what Google, Salesforce and Microsoft look like today.

Phase 2: Vertical Supply Chain (2+ Years). Over time, some cloud providers will leverage cloud services from other providers (for example, ISVs moving into SaaS on top of Microsoft’s Azure Services Platform, use of Force.com, use of Google App Engine). Still proprietary islands, but ecosystems starting to build.

Phase 3: Horizontal Federation (4+ Years). Smaller providers will federate horizontally to gain economies of scale (and efficient use of assets) – also, enterprises will leverage horizontal federation for peak capacity (overdraft protection, cloudbursting). There will be more choices at each layer of cloud computing, and standards will gain momentum.

Again, very similar to the development of the overall server market.

Jeremiah Owyang of Forrester had a wonderful post called “The 7 Tenets of the Connected Analyst”. I really appreciate his list, but I felt he didn’t discuss the challenges enough to strike the right balance between his first six tenets, and the last (“Be profitable”). This is very hard! For those of us in the business of selling our knowledge and expertise, the online community is a valuable resource and tool, but we must draw a line between what we freely discuss with the community, and the value we give to our paying customers.

So, with respect, I’ve riffed off his list and made my own that helped me to describe that balance a little better. I would encourage my industry colleagues (including those from Gartner!) to comment.

1) Listen: All good analysts are good listeners. They learn from every useful resource. Social communities are a valuable and very dynamic source of information and feedback – especially as analysts are forming their early thinking about a subject. Good analysts are willing to make mistakes, publicly, get feedback, and adjust.

2) Connect: A connected analyst not only finds and learns from connections, but shares those connections with others. A successful analyst is a resource not only for personal knowledge, but knowledge elsewhere in the online community – they can’t be seen as a dead-end of information, but as a router to other information (some of which may be behind the paywall, and that’s OK).

3) Contribute: Connected analysts should add to the discussions that relate to their areas of expertise, comment on industry trends and events, and build relationships with members of the community (including competitors!). A successful analyst doesn’t use the community as an obvious sales tool. On the other hand, the successful analyst cannot freely distribute all of their knowledge. Finding the right balance point where they are a valued community contributor (but can obviously do more) is critical.

4) Lead: Connected analysts should be very active in leading community dialogue, especially in terms of new trends, major changes, etc. Successful analysts will draw the line on sharing specific ramifications and specific recommendations – this is value that should be reserved behind the paywall.

5) Succeed: A successful analyst must do more than build a reputation as a public thought leader, or a great public collaborator. Successful analysts also participate in communities to learn and grow, and ultimately provide better advice and counsel to their paying customers. It’s relatively easy for a smart analyst to elevate themselves on a public stage – it’s much harder to elevate yourself while not sacrificing how you or your company actually make money. Successful analysts can do both – and that’s mainly about finding the right balance between public sharing of knowledge, and keeping high-value knowledge behind the paywall.

Is Azure a hopeful name? An azure sky implies cloudless, doesn’t it?

No question, Microsoft would like cloud computing to go away. Selling gazillions of copies of Windows and Office, not to mention mere zillions of Windows Server and Server products has been a nice business. This whole cloud idea is ruining their bright, clear, sunny day.

Cloud computing is just too easy for developers. Amazon, Force.com and Google Apps Engine are platforms that are just there, easy to get started. Not to say that Amazon, Salesforce or Google have all the kinks worked out – but they sure have lowered the barrier to entry for a developer looking to build a global-class application on the cheap. The Azure Services Platform is Microsoft’s answer to their loyal .NET developers – they will provide the same low barrier to entry and global-class experience. (By the way, the acronym for the Azure Services Platform is really, really unfortunate.)

That doesn’t mean that Azure has the management ecosystem, the elasticity, the quality of service controls that developers need – but give Azure time. This is a long-term play.

Software as a service and cloud computing is also appealing – within limits – to enterprises. Cloudsourcing commodity software, short-term software and capacity peaks sounds great. Extending desktop apps sounds great. Moving critical business data off-premises is less appealing. Finding that right balance – that’s what most enterprises want. Microsoft’s Software Plus Services strategy is intended to respond to that, providing the spectrum and the hybrid offerings that respond to more conservative enterprise demand – and also retaining as much of Microsoft’s traditional business as possible. This is a pragmatic strategy, and Azure will help Microsoft deliver on it.

But, Azure doesn’t support existing applications – applications need to be targeted originally for Azure. With Azure, sourcing is not a runtime operations decision, it is an application design decision. The software and/or services decision is kinda hardwired at design time, which is unfortunate, and means that enterprises will need to look elsewhere for solutions to cloudsource some of their computing requirements.

But what these enterprises really want is help being more efficient internally. What are the Secrets of Azure (doesn’t that sound alluring? Gotta use that again…) that could help enterprises be more efficient and cloud-like?

What about this new Windows Azure “Cloud Operating System”? Sounds pretty cool to me. The only problem – this isn’t a cloud operating system at all. Windows Azure is just the operating system used on all the servers that are supporting the Azure Services Platform, and it is unclear that there is really anything significantly different at all in this operating system than packaged Windows Server 2008 running Hyper-V virtual machines. The real “cloud OS” is the unnamed “fabric” that does all the neat stuff, like monitoring applications, spinning up new VMs when needed, and detecting failed applications. Whatever that is, please box it and sell me some!

Without a doubt, what Microsoft needs to do is to maintain synergy between Azure and “traditional” Windows computing (Software Plus Services), as well as ensure learnings from Azure make it into the “traditional” Windows computing experience. If Microsoft wants the sky to stay azure, they should give enterprises as much of the cloud experience that they can internally – help them build “private clouds” – but always with the option to slide slowly and easily into the direction of Azure – at least easier than into the arms of Google.

Rather than summarize the entire discussion that Ken Dulaney and I had with Cisco’s CEO and Chairman, John Chambers on October 14th at Gartner’s Symposium in Orlando, I’d like to focus on two key points that many people may have missed, but should prove to be critical opportunities and challenges for Cisco in the near future.

(Photo by John Costa)

The first is the overall challenge of gaining a “loftier” role in the enterprise. In other words, expanding their influence beyond the networking experts, and increasing their overall value to the enterprise. As servers and storage and networking become more and more virtualized, there is a growing opportunity to provide service level intelligence that automates how the server, storage and networking capacity is orchestrated to meet service level requirements. The risk for Cisco is that the network could be relegated to the role of commodity plumbing (and Cisco’s history of using third parties for network management make this a continued risk). The opportunity is that Cisco could take increased responsibility in providing the intelligence to ensure service levels beyond just the network, including server and storage assets. In other words, turn “the network is the platform” into “the network is the service provider”. This will include, of course, the actual delivery of services (through collaboration software and telepresence, for example). I’m not sure Cisco is focused on this challenge enough – the “Intelligent Information Network” strategy has been there for several years, but I don’t believe they have much to show for it.

The second is the “lofty” opportunity presented by cloud computing, and here I think there is much more promise for Cisco. Cloud computing disintermediates the traditional solution platform providers, such as Microsoft, from customers. Windows isn’t going away, but more and more services will be offered from the cloud, rather than installed and managed on specific on-premises platforms. This seems to me to be a huge opportunity for Cisco to move into market adjacencies, especially software that enables the networking of people or companies. Don’t just think simple collaboration software. Think service brokering across clouds, networking cloud services together to deliver solutions. The opportunity is huge. Is Cisco ready to go for it?

Already, Cisco is promoting their WebEx flagship. And their acquisition of PostPath shows their commitment to extend into many broader areas of services based in software that enable collaboration. As Mr. Chambers said in response to my question, “Cisco is, and will be more.” The only things required are big bets. Mr. Chambers pointed out a significant leadership change at Cisco. In the past, they had two or three major priorities they focused on per year. This year, they have 26 – and his expectation is that these priorities will go from vision to execution much, much faster. Aggressive enough? Maybe.

Cisco likes to focus on market transitions, rather than competitors. Well, here we are. The only question is whether Cisco will place the big bets large and fast enough. My bet is that Cisco will be one of the vendors that flourishes and expands into many new markets as cloud computing becomes a reality.

Here’s an excerpt from the discussion, before we got into the challenges listed above:

This week at Gartner’s Symposium in Orlando I will be presenting “Virtualization Changes Virtually Everything” and “The Future of Infrastructure and Operations: The Engine of Cloud Computing”. Ken Dulaney and I will also be leading a Masterminds discussion with Cisco’s CEO and Chairman, John Chambers. Here’s what you can expect:

On Monday, my “Virtualization” presentation focuses on virtualization as a catalyst for change in data centers and in business use of IT; virtualization as a part of overall infrastructure evolution; alternate delivery models enabled by the abstraction of virtualization at many layers; cloud computing as an example that is enabled by virtualization concepts; discussion of the VMware vs. Microsoft choices, and the role of the Xen-based players; virtualization as a change agent in operating system architectures, client computing, software pricing and licensing, IT chargeback, management processes; virtualization as a force eliminating market boundaries and changing the competitors. I give specific advice on how to navigate these changes. And all in an hour!

My “Future of Infrastructure” presentation covers the gamut of infrastructure and operations trends, including automation, server fabrics, storage changes, unified communications, client application delivery, virtualization 3.0, ten approaches to infrastructure cost reduction, and Gartner’s Infrastructure and Operations Maturity Model. A fundamental message is that the future of infrastructure looks a lot like private cloud computing.

On Tuesday, I’ll have a discussion on stage with John Chambers. My conversation will be focused on Cisco’s relevance to the business (not just networking), Cisco’s role in servers and virtualization, Cisco’s part in making networks intelligent – including managing their own products, green IT and energy efficiency, and Cisco’s role in cloud computing – including as a software provider. Should be fun. I believe this will also be webcasted publicly on gartner.com. I’ll report back after the discussion (Tuesday evening).

My head has been in the clouds for the past week or so – I’ve literally been working full-time on cloud computing. Cloud services are popping up right and left, and more are coming. Some of these are not cloud by our definition. But what about the ones that fit the definition, but barely? From a cloud customer perspective, what makes one service more “cloudy” than another?

I think there are two obvious dimensions to “cloudiness”: Service and Elasticity. There is a third less obvious dimension that I’ll talk about later.

By definition (ours, at least), cloud services are services-oriented, but how much? At one end of the spectrum, a cloud service is highly standardized, uniform, one-size fits all. A service, but not very rich – probably designed more for high-volume and reach. I’m thinking John Belushi on SNL saying “No Coke – Pepsi!” At the other end, a cloud service is highly customized to meet cloud consumer needs, perhaps with a wide range of quality of service options – like Burger King’s “Have it your wayyyy!” (OK, that’s just marketing, but you know what I mean). In the early days of cloud computing, most cloud services will tend to be relatively simple, with limited options. As cloud services mature, more and more personalization and choices will emerge.

Elasticity is also a requirement, but how elastic? At one extreme, elasticity might be slow, or come in chunks. It might be difficult, and require some intervention. It might reach some low-end or high-end scale limits. There might be a high barrier to entry, or high barrier to exit. Kinda sorta elastic. At the other extreme, elasticity is rapid, very smooth and granular. Entry and exit are easy. Sourcing could dynamically move from one provider to another. The nirvana of utility computing. Early cloud offerings have elastic qualities, but they also have a long way to go. With Amazon EC2, for example, you need to define the size of server you need. You can add another one, but it takes a little intervention. This too shall pass.

I think there is another dimension, but I am struggling to name it (please let me know if you have ideas). Let’s call it market, for lack of a better term. At one end of the spectrum, a cloud service is highly monolithic, built on a customized architecture, an integrated top-to-bottom solution, perhaps less innovative and dynamic. A relatively closed market. I discussed this kind of cloud service in my last blog post. The other end? A cloud service built on top of cloud services, an ecosystem of services working together, very organic and dynamic. An open market of federated providers, constantly changing. These are quite rare today, but I expect more to develop over time.

The early cloud service providers are building castles in the clouds. Frankly, in these early days, we need to start this market with a few successful castles. But I expect dynamic and vital markets to bloom around and away from the castles as cloud computing matures. I also expect those monolithic providers to evolve to interact with the market at many different levels – but not right away. Will salesforce.com always have their own data centers? Do they want to? What about Microsoft? Maybe now, but later, after the market evolves? We will see.

I’m currently flying above 30,000 feet, well above a solid bank of confused clouds. Seems appropriate to think about the structure of cloud computing in the future.

Conceptually, cloud computing services can and will be provided at any layer of the IT computing stack, from raw compute services to business process services. So, conceptually, a cloud service might actually include a supply chain of cloud services – a cloud process provider using cloud software providers using cloud compute and storage providers, etc.

But that isn’t what’s happening today.

In these pioneer days, cloud service providers are doing it all. Software as a service providers are building data centers filled with customized infrastructure – and in Google’s case, highly customized and proprietary hardware. They are building, essentially, silos of vertically integrated solutions in the cloud. To be sure, these are cloud services, but why aren’t they using cloud services themselves?

One answer is that it is early, the supply chain, as such, doesn’t exist, and what does exist is not standardized. Another answer is that many cloud services are highly-focused and purpose-built (e.g., web search), and therefore underlying cloud enablers do not need to be general-purpose, and in fact, are more efficient if they are customized to do just a few things well.

But what happens when the supply chain starts to emerge? When standards improve for accessing services? What happens when the cloud service provider wants to expand into new businesses?

I believe that the future of cloud services will be much more dynamic and fluid, with both horizontal and vertical federation. While highly integrated and proprietary vertical cloud services will exist, they will be a minority – and in fact, their competition will be fluid, federated solutions of smaller competitors who should be much more agile. A future challenge for existing vertically-integrated cloud service providers will be to componentize their offerings – open up cloud services at lower levels of their cloud computing stack, and leverage other cloud service providers when appropriate. To be sure, they can differentiate by having customized hardware or unique management software, or unique performance capabilities – but betting on this differentiation going forward seems extremely risky as the markets mature.

This is exactly what happened to servers – they went from highly integrated and proprietary mainframes (proprietary hardware and limited applications) to midrange systems (with packaged software from third parties) to high-volume servers (hardware separated from operating systems separated from business applications). Mainframes have not gone away – but their role has certainly become a market niche. Mainframes have been attempting to evolve for years – to support more operating systems, more packaged applications, etc. This has slowed but not stopped a declining role for the mainframe in global computing.

Will Google and salesforce.com become the mainframes of the cloud? Will early market leadership translate into strategic viability even in a more componentized cloud services market? Will they invest strategically to avoid a vertically-integrated gridlock? Should Microsoft be building datacenters, or instead, directing datacenter standards for Microsoft software? Hmm…

I had a conversation with some folks at Intel today, and they referred to research from IDC on what Virtualization 2.0 looked like. This got me thinking. There is a tendency to take a trend like virtualization and wrap every other trend inside it. That creates a semantic nightmare, in my opinion. Virtualization does not equal cloud, cloud does not equal SOA, virtualization does not encompass management automation, etc. These are all separate trends that cross paths - they may be catalysts, they may overlap, they may actually all take us to the same place - but they are different trends, different legs of the stool. Applying service-level automation to virtualization, for example, is not a virtualization trend - it is an automation trend leveraging virtualization. The real question is - what does virtualization mean to users? What does virtualization enable? How does that change - and does it change in identifiable stages? I say it does.

Virtualization 1.0: Consolidation and cost savings. No question - the reason people first virtualize their storage, their servers, their network capacity is to save money. It’s all about being more efficient. Almost all of the early adopters I talk to about virtual machines are in it to reduce server hardware and power spending, possibly space. Often to introduce disaster recovery (because it is so much cheaper!). But, talk to these same people a year later, and they talk about…

Virtualization 2.0: Agility and speed. Saving money is great, but it often doesn’t impact the customers of IT directly - or, at least, it doesn’t help the business grow. Our clients tell us they can deploy virtual servers thirty times faster than physical. They also tell us that customer demand roughly doubles when they deliver faster - a lower barrier to entry leads to greater demand. Speed and agility also has significant impacts on management and operational processes. But after cost efficiency, and after speed, what’s next?

Virtualization 3.0: Alternate sourcing. I’d say the next big thing will be the ability to leverage the abstraction layer created by virtualization in its many forms to creatively source the function that was virtualized. In its earliest form, an example would be moving virtual machines between servers dynamically to meet demand. However, more interesting will be moving off-premise - dynamically sourcing based on cost, quality of service and agility needs. Maybe a workload is spiking dramatically. Move that workload to a cloud provider (for good, or temporarily).

Virtualization 3.0 is not cloud computing - but virtualization 3.0 is certainly one important enabler of cloud computing, among many enablers.

So what does Virtualization 4.0 look like? Have to think about that for a future post…

At VMworld today, VMware announced two strategic shifts that are as important as they are unsurprising. One pits VMware firmly against powerhouses IBM, HP and Microsoft in the competition for infrastructure control. The other extends VMware’s virtualization story into cloud computing. Are they overreaching?

The first, “Virtual Data Center Operating System”, is what Gartner defined as a meta operating system in 2004. A meta operating system is a virtualization layer between applications and distributed computing resources; it utilizes distributed computing resources to perform scheduling, loading, initiating, supervising applications and error handling. Essentially, an operating system that manages distributed resources. If you have hundreds or thousands of individual operating systems, take certain common functions and consolidate them for the entire pool of resources. Microsoft had a research project years ago that focused on just this – they called it BIG, for “billions of interconnected gizmos”. That led to the Dynamic IT strategy, but we haven’t seen Microsoft put much effort into redefining the operating system concept because of it – yet.

VMware includes in their concept what Gartner calls a service governor, which adds policy-based management on top of a meta OS. Combined, these two create what Gartner calls a real-time infrastructure. The service governor is the real challenge for VMware, which is one reason they haven’t called it out.

What is interesting is that VMware is finally describing a larger strategy that is completely competitive with IBM (remember the On Demand Operating Environment?), HP (Adaptive Infrastructure) and Microsoft (Dynamic IT). The strategy is credible, but there are many, many gaps that need to be filled. In particular, while VMware is strong in virtualization, they are very weak in service management. Regardless, it will be difficult for IBM and HP to miss the competitive threat (which, of course, they should have seen starting in 2001). This is the only natural evolution for VMware, but the road is littered with challenges.

The second strategic shift was the introduction of vCloud – essentially, services that make movement of virtual machine-based workloads in and out of the cloud easy. It takes programmers to leverage Amazon’s EC2. vCloud’s intention is to give infrastructure administrators the ability to make sourcing decisions not only within a data center, but to and from cloud providers who leverage VMware’s technologies. VMware also hopes to build a market of cloud computing providers that use VMware’s software to power their cloud computing architectures. While there will be a growing demand for software that enables cloud providers, VMware can only play if their pricing for service providers is much lower than VMware’s price today for enterprises.

There’s a lot more to discuss and analyze, but I’ll leave that for a future post.