The Pervasive Data Center

At the conceptual level, there isn't a huge amount of disagreement among technologists about the fundamentals of cloud computing--its forms, its characteristics, its potential benefits, and its limitations.

That said, individual vendors come at cloud computing from particular perspectives that often reflect the character and needs of an existing customer base. Nowhere is this truer than in the case of IBM. I attended an IBM event at their new Littleton, Mass., location a couple of weeks ago, and I was struck by the degree to which its latest cloud computing announcements and the strategy of its cloud computing organization mirror the focus and strategy of IBM in other areas.

Several related threads collectively define IBM's primary approach to cloud computing.

The first is "private clouds."

By "private," IBM means one of three things: 1) infrastructure within a customer's data center, 2) infrastructure operated by IBM for a customer within an IBM data center, or 3) IBM infrastructure dedicated to the use of a single customer.

In other words, private pretty much covers the gamut of everything that is not a shared, multi-tenant public cloud.

However, that shouldn't be read as IBM just using the term "cloud" here as a marketing buzzword to cover just about all computing. It's easy to draw that conclusion given IBM's focus on dedicated infrastructure. But while IBM uses the term broadly and very pragmatically, it does associate it with certain specific characteristics.

For example, one IBM exec at the event spoke of an existing virtual desktop infrastructure (VDI) deployment and noted that it was not, yet, a cloud because it is the operations analysis, the service orchestration, and self-service that make a cloud. (In this context, operations analysis refers to identifying and modifying workflows and interactions between people--such as eliminating "ad hoc chatter" that duplicates effort or adds latency.)

A second thread is IBM's main target for this phase of its cloud rollout. That would be development and test--mostly for the reason that IBM sees this as the low-hanging fruit. It's an area of enterprise IT where change happens all the time and resources are often not easily reclaimed even when they're no longer being used.

If this sounds like a familiar storyline, it should. This is where virtualization got its start and for many of the same reasons. At the same time, what IBM is doing here goes beyond test/dev virtualization.

And this brings us to the third thread, the precise nature of the audience for these products.

What's different here from just loading up VMware on a blade server and even adding a VMware product like Lab Manager is the other IBM tooling in place. Rational development toolsets and Tivoli service management are integral parts of these integrated packages. (Tivoli plays a central role in IBM's approach to cloud in general.)

You might think that this is a heavyweight and heavy-duty enterprise-centric approach to cloud computing. You would be right. I made this observation to one of their senior cloud executives and he didn't disagree.

The exec's response: "Our natural constituencies are the enterprise developers and we have to cater to the enterprise developer and enterprise developer teams. Within them, we have the subset who write enterprise transactional software. These are the apps who decide over life or death of a CIO and we have to cater to them. They are also the majority still of the central development organization."

This is not to say that IBM isn't also doing things related to lighter-weight, such as RESTful, development approaches. There's an IBM Mashup Center, for example, and cloud resources on IBM developerWorks. However, this style of cloud computing is not at the forefront of Erich Clementi's cloud computing organization.

But IBM is putting the wood of the arrow behind cloud computing for the core mission-critical applications in an enterprise, its primary target outside of the cloud as well.

By now, most people involved with IT are familiar with at least the broad outlines of cloud computing--the idea that applications run somewhere out in the network. We just get back data streams or Web pages; the actual crunching, connecting, and correlating happens somewhere else.

Plenty of people, including myself, have taken cuts at defining cloud computing with a bit more rigor. I've come to believe that particular exercise can still be useful for thinking about different use cases and different market segments, but I don't expect we'll ever see a canonical definition. Too many people have too many different perspectives--and particular interests in having some aspects, say "private clouds," be viewed in a particular way.

However, specifics of the cloud-computing taxonomy aside, it's worth noting that the vision of cloud computing, as originally broached by its popularizers, wasn't just about more loosely coupled applications being delivered over networks in more standardized and interoperable ways--a sort of next-generation service-oriented architecture, if you would. Rather, that vision was about a fundamental change to the economics of computing.

As recounted by, among others, Nick Carr in his The Big Switch, cloud computing metaphorically mirrors the evolution of power generation and distribution. Industrial-revolution factories--such as those that once occupied many of the riverside brick buildings I overlook from my Nashua, N.H., office--built largely customized systems to run looms and other automated tools, powered by water and other sources.

These power generation and distribution systems were a competitive differentiator; the more power you had, the more machines you could run, and the more you could produce for sale. Today, by contrast, power (in the form of electricity) is just a commodity for most companies--something that they pull off the grid and pay for based on how much they use.

Some companies may indeed generate power in a small way--typically as backup in outages or as part of a co-generation setup--but you'll find little argument that mainstream power requirements are best met by the electric utility. The Big Switch argues that computing is on a similar trajectory.

And that posits cloud computing being a much more fundamentally disruptive economic model than a mostly gradual shift toward software being delivered as a service and IT being incrementally outsourced to larger IT organizations. It posits having the five "computers" (which is to say complexes of computers) in the world that Sun CTO Greg Papadopoulos hyperbolically referred to--or at least far, far fewer organizations doing computing than today.

Such an IT landscape would look very different--profoundly affecting, just for a start, any vendor competing in it. And that's without even discussing all the regulatory, privacy, and control of information issues that would assume great prominence.

It's an intriguing and big argument, and one well told. I've also come to think it's mostly wrong--at least for any time values that we care about as a practical manner.

I'm emphatically not arguing against cloud computing in the small-"c" sense. Computing is getting more network-centric. Check. Less tied to the physical infrastructure it was initially installed on. Check. More dynamic. Check. More modular. Check. And so forth. Check. Check. Check.

In fact, I even expect that we will see a pretty large-scale shift among small and medium businesses away from running their own e-mail systems and other applications. As we've already seen among consumers--Google search and applications and Web 2.0 sites are all aspects of cloud computing.

And there are economically interesting aspects to this change. No longer do you need to roll in (and finance) pallets of computers to jump-start a company; you go to the Web site for Amazon Web Services. One implication is lower barriers to entry for many types of businesses.

But that's not the sort of near-term economic shift that the electric grid brought about. Rather, it made both unnecessary and obsolete the homegrown systems of the enterprises of the day. And it did so relatively quickly.

And that is what I don't see happening any time soon, on a substantial scale with cloud computing. So far, there is scant evidence that, once you reach the size of industrialized data center operations (call it a couple of data centers to take care of redundancy), the operational economics associated with an order of magnitude greater scale are compelling.

Doubtless, megaservice providers have some scale advantages--especially if they get to choose a narrow slice of application types on which they choose to concentrate. But consider all the reasons enterprises might want or need to continue to run applications in-house: control and visibility, compliance, integration with legacy IT, and so forth. It will take a lot of financial incentive to overcome those countervailing factors.

I'm skeptical that incentive is there for core enterprise IT for organizations with at least modest scale points of their own.

The new world of computing has not been particularly kind thus far to the historical management vendors. It's not that virtulization and cloud computing in their various--and often ambiguous guises--have made past styles of computing irrelevant. COBOL programs still underlay lots of important business processes, after all.

(Credit: IBM)

But newer approaches to computing--often characterized by ground-up and tactical solutions to IT concerns--have tended to trump the sort of big, architected, expensive paths to nirvana that the likes of enterprise management have tended to take.

The fact is that the likes of CA Unicenter, HP OpenView, and IBM Tivoli may not have been a part of computing over the past five years or so--but they haven't exactly been on top of the exciting new action, either.

This is a context that makes IBM's Dynamic Infrastructure news, coming out of its Pulse conference in Las Vegas, worthy of more than passing mention.

Tivoli is, broadly, IBM's management software assets within its broader software group. IBM breaks Tivoli software into a variety of categories such as asset management; business application management; security management; server, network, and device management; service management; service provider solutions; and solutions for growing medium businesses.

The announcements IBM made at Pulse touch on a variety of areas--including storage. However, what I find most strategically notable are those related to service management. These include:

• IBM service management software and services from IBM Global Business Services, IBM Global Technology Services, and specialized IBM Business Partner capabilities. Together, they enable organizations to design and implement IT systems that centrally manage and monitor an entire industry infrastructure, enabling greater performance of both traditional assets, such as manufacturing robotic equipment, as well as emerging technologies like "smart meters" and RFID (radio frequency identification).
• A new governance-consulting practice. Through the practice, IBM works with clients to design governance systems to help mitigate risks related to business changes, changing market conditions, and regulatory requirements.
• New Tivoli Service Automation Manager software, which automates the design, deployment, and management of services such as middleware, applications, hardware, and networks, tasks that today are largely done manually and thus are subject to error, time constraints, and other human limitations.
• New Tivoli Key Lifecycle Manager software, which helps organizations simplify the life cycle of encryption keys by enabling them to centralize, automate, and strengthen security through key management processes, with an increasing number of IT infrastructure elements having built in encryption to protect them.

What most struck me about these announcements is the way that they intersect with other discussions that I've had with IBM of late related to System Z (i.e., IBM mainframes) and cloud computing.

On the System Z front, IBM's Karl Freund and Joe Castano recently walked me through a road map discussion that was fundamentally concerned with issues such as how to deal with "composite" applications that run across multiple platforms (including, but not limited to, System Z) and how to simplify hybrid transactions in such an environment. From my perspective, this sounds a lot like past System Z initiatives related to being the "hub" of the digital enterprise.

But this has a much more explicit management--which is to say Tivoli--focus.

More broadly, I also had the opportunity last week to hear Erich Clementi and Chris O'Connor walk me though IBM's new cloud-computing organization.

Clementi and O'Connor presented what my colleague Jonathan Eunice described as a "very heavyweight, enterprisey view of cloud." Put another way, my take was that this was really about how IBM will help the enterprise implement a version 2.0 of SOA (service-oriented architecture): lots of IBM Global Services (IGS) and lots of Tivoli management goodness.

There is nothing wrong with any of this. But it's a view of the cloud through the top-down lens of an enterprise-architected Tivoli and IGS approach, rather than the bottom-up, tactical, always-in-beta methodology that's been most associated with the consumer cloud.

If the license wars aren't over, they've certainly muted.

The adoption of the new version of the General Public License, used by Linux and many other open-source projects, was a long, loud, and contentious process. But after all the sturm und drang, it's not clear to me what real impact GPL 3 will have.

Depending on whom you ask, clauses concerning ideological sticking points such as digital rights management were either narrowed in scope or defanged almost completely. And it seems entirely possible that Linux, perhaps the best-known open-source project licensed under the GPL, may never move to the new license version.

More broadly, I just don't feel that there's a whole lot of interest, much less passion, out there in the various open-source communities for fighting license battles. That's not to say that everyone agrees that there is one perfect approach to licensing. Not all all! But there is, for the most part, a pragmatic understanding and a realization that the license for a given open-source project has to match up with its governance, collaboration, and even business model. It's just one piece of the puzzle.

In a similar vein, there are just so many accumulated examples of different approaches that have succeeded. Yes, Linux is successful, and it uses GPL 2. But the very popular Apache Web server uses a much more permissive license (in the sense that enhancements don't need to be contributed back to the commons). The Firefox Web browser uses a license that's somewhere in between.

We've also accumulated a lot of evidence that open source is simply a pretty effective development model that can bring a lot of benefits to those who use it. As a result, there's less of a sense that open source needs protection through a restrictive license.

None of this is to say that lawyers and license geeks don't sometimes get into squabbles over how various licenses interact, and so forth. But, in the grand scheme of things, these are micro issues, not macro ones.

I think the best evidence for the winding down of the license wars comes from what's happening around cloud computing, which I define generally as software and infrastructure accessed in the network.

As I've written about previously, the provisions in the GPL, and many other open-source licenses requiring that modifications and enhancements to source code be contributed back to the public, often don't apply in a cloud-computing world. That's because accessing software in the form of a service over the network isn't "distribution," the event that triggers the requirement to make source code available.

Some view this state of affairs as a loophole, one that a variant on the GPL 3--the Affero GPL (AGPL)--explicitly plugs by expanding the definition of distribution to encompass the delivery of services over the network. The AGPL effectively remaps the rules from the original Unix-like environment in which the GPL was born into a network computing one.

What's striking to me is how few people seem to really care about the AGPL and the supposed problem it's trying to solve. Yes, there are the zealots who go apoplectic at the thought of open source being used for profit-making purposes. And there's a fair bit of discussion about how to best protect portability, privacy, and so forth in a cloud-computing world.

There's also no small degree of what might be best called social or community pressure on large cloud vendors such as Google to make meaningful contributions to open-source projects. But forcing all this through licenses? Not so much.