The Pervasive Data Center

There was legitimate debate at one point whether the style of cloud computing often called Platform-as-a-Service (PaaS) was really going to take off in a big way.

The aim of PaaS is to supply developers with a set of services that they can use to build scalable applications without doing all the underlying grunt work themselves.

Such a platform might automatically add additional capacity in response to increased load. Or it could offer various middleware services, such as databases and application servers. (The National Institute of Standards and Technology has a definition document that I and many others use to help make sure we're all on the same page when it comes to the types and characteristics of cloud computing.)

As is always the case with such things, the lines between what is a platform and what is just infrastructure and what is end-user hosted software blur a bit. But, in the main, platforms are a higher level of abstraction than infrastructure but don't offer something that's directly useful for end-users out of the box.

The questions about PaaS were at least two-fold.

For one thing, while cloud infrastructure has a fairly clean correspondence to physical and virtual infrastructure in a data center and Software-as-a-Service is just hosted software in many respects, PaaS doesn't map especially well to familiar concepts. It's partially related to middleware but also includes forms of background automation that haven't historically existed.

There's also the lock-in concern. Cloud infrastructure services like Amazon EC2 and S3 aren't standardized in a formal way. But their interfaces are straightforward enough that a third-party like RightScale can map them across different providers. Alternatively, others can treat them as effectively a de facto standard and mimic them for their own implementations as Eucalyptus is doing.

But PaaS is more vendor specific and the more layers of specialized function, the more specific it becomes. But this doesn't concern everyone. For example, Tobias Klauder of digital advertising agency Razorfish told me that he generally endorsed the idea of vendors competing on the basis of unique differentiation that users need. As he put it: "I don't see benefit to getting the exact thing from three different providers; then you're just competing on price, not features." And the reality is that moving from one vendor's middleware and other supporting application infrastructure to another's has never been an easy and transparent process.

However, upon reading a recent post by fellow CNET Blog Network writer James Urquhart, it's becoming clear to me that PaaS is an important component of cloud computing.

Microsoft's commercial launch of Azure at its Professional Developer Conference was, by all appearances, a big hit. I've personally viewed Azure as a major bellwether for PaaS, given the large Microsoft development community. If Azure clicks with .Net developers, it bodes well for the PaaS concept.

James also notes that "Ruby on Rails platform service vendor Heroku reportedly hosts more than 40,000 applications now. At its Dreamforce conference in San Francisco, Salesforce.com mentioned it had approximately 135,000 applications running on its Force.com platform" and that "anecdotal evidence suggests there is a large body of Web application developers running on both the Java and Python instances" of Google App Engine.

Google App Engine's relatively low profile was one reason to be somewhat skeptical of PaaS a year ago. Today, I'm still unconvinced App Engine is living up to some of the early expectations that surrounded it. Nonetheless, in the context of clear PaaS advances elsewhere, it's another data point for an at least moderately popular offering.

To these, I'd add that cloud infrastructure is expanding and morphing into something that looks more like a platform. Newer Amazon services such as Elastic MapReduce and Relational Database Service blur the line between what is infrastructure and what is something more. Arguably, Simple Queue Service already did this from the early days but the new services can increasingly handle the mechanics of scaling an application transparently to a developer.

In fact, given such this apparent demand for more abstraction and higher-level services, I wonder if we're starting to see cloud infrastructure essentially morph into a platform.

More and more of our computing happens through applications and Web sites out in the network. It's in the "cloud" to use the current trendy lingo.

One consequence is that we're starting to look at our clients differently. That's because they're increasingly a sort of window into the cloud rather than devices that run a lot of application-specific code and store a lot of application-specific data locally. Clients can therefore be "thinner," which is to say loaded with less software and less tailored to the needs and wants of a given user. Resources and customization live out in the network instead.

Even with more conventional operating systems such as Windows, Linux, or OS X, running applications in the network reduces the time spent installing and upgrading applications on our proliferating collection of clients. Google's Chrome OS takes the concept to the next level and essentially reimagines the client OS for a cloud world.

However, the real world is messier and more complicated than "Just run everything in a browser." That's true today and will almost certainly be true to at least some degree next month and next year. Ultimately, this question of how thin clients can become as a practical matter is going to play a big role in how accepted certain models of computing will become.

To illustrate, consider a PC that is today mostly used to go online. There's more than just an OS and a basic browser involved.

There are plug-ins and extensions for the browser. There's probably an IM client; Meebo is a Web-based alternative but most people run a local client. If you use Twitter, there's a good chance you run an application like TweetDeck or Seesmic, which may in turn require Adobe's AIR runtime. Third-party media applications such as Apples iTunes are commonplace. Google Earth, Windows Live Writer...This list goes on--and will vary by user--of the applications and components that have to be installed and updated for even a rather bare-bones PC configuration.

And that's before we even broach device drivers or other software that may be required to connect a camera, a microphone, or some other peripheral.

My overarching point here is not that a thinner client model is uninteresting. I strongly believe that it is meant not to replace traditional fat clients but to augment them. Today, I have a notebook that is essentially used only to go online yet I still have all the administration associated with a full-blown PC.

However, the challenge for Google and others is to steer a course that creates an "Internet computer" that is legitimately better in that role than a full-fledged PC while retaining sufficient customization. Application stores may be part of the answer. HTML 5 will likely also help by making browsers more capable of running applications.

Whatever the specific technical solutions though, the answer will involve a lot of careful thought about balancing simplification and flexibility.

I had planned to leave the Google Chrome OS discussion to others. It's not that I don't have strong opinions about it but with a commentariat noise level approaching the Michael Jackson ruckus of Tuesday, I figured I'd try to wrap up a client project instead. I did so and I've been getting questions all day, so I thought it would be useful to put down my thoughts in a systematic way rather than answering every query ad hoc.

Let me start out by making what is probably a controversial statement. I don't see this as a big deal. Microsoft is not now radioactive. The Force has not been disrupted. The computer industry does not look different than it did yesterday.

Look. Just about everyone has been assuming that Google was going to bring the Google Android operating system that it developed primarily for smartphones to low-end notebooks. While Chrome OS is different from Android, it's conceptually pretty much the same thing--an open-source operating system built atop a Linux kernel.

So now Google has pre-announced that it's going to do basically what everyone figured it was going to do. Sorry, but that doesn't make me want to run through the streets shouting and hollering.

This is, in many respects, just another Linux distribution. And Linux has (speaking charitably) not had the impact on the general-purpose PC market that its supporters once hoped it would. Sure, enthusiasts load Linux onto PCs and it can work quite well, but even at an open-source developer conference you'll often see far more Macs than PCs running Linux. I can't say that I understand why Chrome OS would succeed where Ubuntu has, if not failed, largely played to a niche.

It's Google we're talking about here to be sure. To which I say that Google has had plenty of failures: Orkut, Google Video, Knol, and Google Base anyone?

Fundamentally, I'm skeptical that anyone is in a position to seriously displace Microsoft and Apple from effective ownership of the general-purpose desktop and notebook space. There's so much ecosystem, most of all software ecosystem, in place that a new entrant would have to offer just overwhelming advantage. Which Linux didn't and doesn't.

There's a story here but it's not about displacing Microsoft.

Rather, I see Chrome OS as reflecting a change in the client and the way we access applications. To the degree that Chrome OS further illuminates and, by doing so, accelerates such change it may indeed be important in its own right. However, this is largely a change that's happening with or without Google--and certainly with or without anything Google does with respect to client operating systems.

And it's this macro-trend that's the real threat to Microsoft, not Chrome OS. Microsoft's franchise is built in no small part on having become the de facto standard API for programs running on another de facto standard that we colloquially call the PC. That franchise may be hard to crack (although Apple has had a degree of success) but that franchise doesn't necessarily carry over to new areas where far less software is locally installed and therefore a "standard API" becomes much less important.

The Linux desktop (whether Chrome OS, Ubuntu, or whatever) won't be your father's PC and it may not even look like a PC at all. That's the far bigger threat to Microsoft. Not that it won't be able to defend its existing franchise but that it will be cut off from extending that franchise into computing that happens over the Net rather than locally.

In his post, "What Tim O'Reilly gets wrong about the cloud," Nick Carr takes Tim to task for describing Google as an example of a business that has grown to dominance because of network effects. The basic idea behind network effects is that something gets more valuable as more people use it. The canonical example is the telephone system. With one telephone it would be pretty uninteresting. With limited penetration, only mildly interesting. With near-universal connectivity, extremely powerful. There's a lot of debate about the details, but few dispute the basic concept.

But Nick argues that network effects don't underpin Google's success. Google determines the best search results using algorithms, not the "wisdom of the crowd." If I were the only person using Google, it might be hard for Google to continue making hardware and software investments. But, money aside, it doesn't inherently depend on having lots of users to deliver quality results. By contrast, social networks or a many-to-many selling site like eBay (especially in its earlier days) are network effect businesses. (In fairness, the myriad creators of Web content make Google's PageRank possible but I see this as a weak form of network effect compared to the other examples.)

However, network effects aren't the only reason why a given industry may end up with just a few--or even one--large players. Nick lists a few that may well be relevant to Google and other "cloud computing" suppliers:

1. Capital intensity. Building a large utility computing system requires lots of capital, which itself presents a big barrier to entry.

2. Scale advantages. As O'Reilly himself notes, big players reap important scale economies in equipment, labor, real estate, electricity, and other inputs.

3. Diversity factor. One of the big advantages that accrue to utilities is their ability to make demand flatter and more predictable (by serving a diverse group of customers with varying demand patterns), which in turn allows them to use their capital more efficiently. As your customer base expands, so does your diversity factor and hence your efficiency advantage and your ability to undercut your less-efficient competitors' prices.

4. Expertise advantages. Brilliant computer scientists and engineers are scarce.

5. Brand and marketing advantages. They still matter - a lot - and they probably matter most of all when it comes to the purchasing decisions of large, conservative companies.

6. Proprietary systems that create some form of lock-in. Don't assume that "open" systems are attractive to mainstream buyers simply because of their openness. In fact, proprietary systems often better fulfill buyer requirements, particularly in the early stages of a market's development. As IT analyst James Governor writes in a comment on Macleod's post, "customers always vote with their feet, and they tend vote for something somewhat proprietary - see Salesforce APEX and iPhone apps for example. Experience always comes before open. Even supposed open standards dorks these days are rushing headlong into the walled garden of gorgeousness we like to call Apple Computers."

The reason this question is of more than academic "nature of the firm"-type interest is that the question of scale in a world where more and more computing happens out in the network has implications that go beyond the cloud computing suppliers themselves. (For our purposes here, cloud computing refers to Internet-based computing generally, whether Software as a Service,SaaS, or some more direct use of computing resources over the network.)

A world with many different cloud computing suppliers, operating at different levels of abstraction--SaaS, Amazon Web Services-style virtual machines, Google Apps-style developer platform, and so forth--looks very different from the world hyperbolically described by Sun CTO Greg Papadopolous as having five "computers." (Computers in the sense of cloud computing providers with distributed worldwide datacenters.)

The computer industry in the first world would look much like today's. Independent Software Vendors (ISV) might deliver applications in the form of Web services rather than programs to be locally installed.  But they'd still be ISVs. And systems vendors would be selling more to those ISVs and other cloud computing suppliers than they would be the ultimate end users. But the sales model wouldn't be all that different from current enterprise sales.

In the second case, things would be much different, however. As I discussed in "The New Systems Companies," if computing were to become something largely consumed by a relative handful of mega-scale service providers, that would fundamentally alter the dynamic between system supplier and system customer that exists today. In the extreme case, the biggest service providers could become the new systems companies, as Google has already done to at least a partial degree.

Understanding to what degree size matters in a cloud computing world is therefore a very important question.

Over at The Register, Ashlee Vance notes that "Sources have told Digitimes that Google plans to test out SSD [Solid State Disk] storage in an effort to lower power consumption at its vast data centers." He goes on to write that his sources dispute the report. ("Flat out wrong" to be exact.) It does strain credibility more than a tad given the current price premium of SSD over conventional hard disks--although it's certainly fair comment that it may get more interesting over time or that it may make sense for some particularly performance-sensitive part of the storage hierarchy. However, my point in bringing this up isn't to discuss the Google and SSD specifically.

Rather, Ashlee makes another point that is worth remembering and emphasizing when he writes:

Given the secretive nature of Google, it's rather hard for outsiders to tell what the company is up to. It's also damn hard to tell if the company's supposed data center magic really lives up to its billing or if the company just blows tons of cash and time designing its own systems.

Because the company is so prominent and successful, it's often tempting to point to Google as an exemplar and model for how computing will be done in a network-centric world. And, by extension, how the leading providers of this new-style computing will design, source, and operate their datacenters. There are certainly aspects of what Google does that are widely applicable. For example, no one disputes that software delivered in the form of services from scale-out infrastructures is (at the minimum) one of the major ways that people will consume computing.

It is important to at least consider the possibility that, when Google buys custom-designed motherboards from Intel, it's not providing some key insight into best practices for mega-service providers of the future. But, rather, it's just Google being Google.

This distinction matters. A lot. Google is heading down a path that is making it start to look like a vertically-integrated systems company from days of yore. (Think IBM mainframes.) If one furthermore assumes that "incredibly big" is the optimal scale point for such service providers (another important question), then isn't Google and its ilk the future of the systems company? (See this prior post for some more fleshing out of this thought.)

If, on the other hand, it's just Google burning $100 bills by the dump truck load because they've run out of space to paper the walls with them, that's a whole different animal with entirely different implications for system vendor and service provider strategy.

My guess? It's probably a bit of each. (No one said this industry was simple.)

As I've written about previously, we're starting to move beyond the familiar keyboard  and mouse/touchpad, and two-handed game controller as ways of interacting with our computer systems. In the gaming world, the motion-sensing Nintendo Wii remote is the most obvious innovation. Elsewhere, multi-touch screens, either on the large scale (Microsoft Surface) or small scale (Apple iPhone) have been garnering a lot of attention.

(Credit: 3Dconnexion)

Another interesting category is the six-degrees-of-freedom (6DOF) controller. These aren't particularly new but, until recently, they've been targeted primarily at 3D CAD professionals and have been priced in line with relatively expensive engineering software. If you're spending thousands of dollars for a CAD package, spending a few hundred for a piece of hardware that lets you use it more easily is pretty much a no-brainer. (Devices of this type are also a good match for controlling robotics.)

However, more recently, 3Dconnexion, a wholly owned subsidiary of Logitech, has pushed down the price point considerably with its SpaceNavigator line. The SpaceNavigator PE is $59 (MSRP) for a non-commercial use license with online support and the SpaceNavigator SE is $99 (MSRP) for a commercial use license with full support. (The two differ only in licensing and support; they're otherwise physically identical and support the same software.) The company has now updated its lineup with the SpaceNavigator for Notebooks, priced at $129. It's a bit smaller than the standard SpaceNavigator and, at .55 pounds, weighs about half as much. It also includes a small case.

I've been a fan of the original SpaceNavigator for a while now. It makes a huge difference to navigating through Google Earth or Microsoft Virtual Earth. I tried out the new SpaceNavigator for Notebooks with these applications. All other things being equal, I marginally prefer the larger size and greater heft of the desktop model. However, if I were regularly using a 3D application on my notebook while traveling, the new device's design strikes me as a reasonable tradeoff for the weight and bulk savings.

The company calls the SpaceNavigator a "3D mouse" but that's a misnomer. It's only a mouse in the sense that it's roughly the same size as a mouse and you operate it with one hand. If anything, it's closer to a trackball. However, it's really its own class of input device and does not, in any case, replace a mouse except for navigation (specifically) within about 120 supported 3D applications. But it's understandable that "6DOF controller" might have been a wee too geeky for the general population.

6DOF refers to the fact that you can use the controller to generate six different motions. Pressing it front/back and left/right are the two motions that correspond to moving a mouse around the desktop. Pressing down and pulling up translate you vertically ("z" dimension for the mathematically inclined); this corresponds to altitude or zooming in Google Earth. The other three motions are those familiar to joystick users: rotation around the three perpendicular axes, i.e. yaw, pitch, and roll (or spin, tilt, and roll as 3Dconnexion calls them).

At least for me, actually using the controller feels intuitive even if it's a bit hard to explain how it works. It's a fun toy even if you don't have a serious need for one. (One hint. For Google Earth, I prefer to turn off tilt in the controller's customization panel. The tilt rotation is the one that lets you look at the surface of the earth from an angle. I typically prefer to keep the view from straight over head and, if tilt is on, it's hard not to shift it a bit while you're moving around the surface of the globe.)

For all the company's overall success, some of its individual entrants sometimes seem not just lagging and wanting, but sometimes just plain... off.

I'm not so much talking here about sites like Orkut and Google Video that were more-or-less representative of and competitive with social media and video sharing sites (respectively) at the time they came on the scene. They simply didn't rise to the top of the pile for complicated and somewhat elusive reasons that would make for another long discussion.

However, other examples from Google just seem oddly out of tune.

Take Google Browser Sync for example. Social bookmarking may be the red-headed stepchild of social media, as I've written about previously. But that's an opportunity for Google. So what do they do? They come up with some relatively lame mechanism to share bookmarks among multiple computers. I might have found this useful five years ago. However, for many people (especially those who worry about coordinating multiple computers), bookmarks have become something to be stored in the network rather than locally. At least if you aren't storing the content as well as the URL, it's not like they're much use if you're disconnected from the network cloud anyway.

And then there's the peculiar case of Picasa. At the end of the day, Picasa is much more about a simple image cataloging and editing program for the PC than it is a vibrant online photo site. Strip away the client component and it feels awfully first generation--a place to store some snapshots for a few friends and family than a place to participate in an online community. Think Snapfish, not Flickr. Nor does it have any of the more sophisticated tools that sites like SmugMug and PhotoShelter offer to better cater to more serious amateurs and pros.

Indeed, if one were to look at these two examples in isolation, one might be inclined to think that Google doesn't even get social media, Web 2.0, all that good stuff. After all, the counterexamples like the Google Earth community are rather sparse.

But it's worse that that. It can be useful to have a client-side application--that's the reality and, in any case, Picasa has one for reasons of history as much as strategy. But Picasa so often feels like its design center is that offline component rather than the online one. Does Google even have a truly coherent vision of computing in the Cloud?

Google has a decidedly mixed record with its acquisitions (including Picasa). But it's too bad that it's probably not practical at this point just to snap up the Flickr photo site and del.icio.us social bookmarking. Their owner, Yahoo, has certainly never known what to do with them. But Yahoo is a competitor and the tumult around Microsoft's attempted acquisition likely makes any such move impossible. Too bad.

The idea of the "long tail," a concept popularized by Wired's Chris Anderson, permeates much of what is going on with the evolution of IT.

After all, it's the mass participation of almost everyone in creating content of various types that's driving an enormous amount of IT build out--which, in turn, may well change even how and who builds computers in the future. Simply put, the long-tail premise is that bestsellers aren't in the majority when one tallies up the sales at Amazon.com or the page views on blogs. Rather, it's the total of the far more numerous other 80 or 90 percent of content.

Less abstractly, Anderson's argument is about business. Namely, he argues companies can make money selling to the long tail as shown in the data that I discuss in this 2005 post. I thought and think that it's a powerful concept--although I also think it fair to ponder how many companies are truly well-positioned to make money from the long tail.

When Amazon, Netflix, and Google make their appearance as exemplars for the umpteenth time, one starts to wonder. (In all fairness, Anderson has additional examples; Amazon and Netflix just make particularly rich, data-heavy case studies.)

However, as well noted by Alex Iskold over at Read/Write Web this morning, there's a slightly subtle, but very important, distinction to be made when we're discussing making money on the long tail. It's about making money on the long tail, not making money in it.

I've previously speculated whether those running the mega-datacenters that deliver more and more of our applications--especially in the consumer space--might not also increasingly write their own platform software and construct their own hardware. In the general case, the jury is still out. And there are some counterexamples. For instance, Yahoo has largely shifted from running a FreeBSD variant that it supported internally to the commercial Red Hat Enterprise Linux distribution.

But, however the general trend plays out, it's clear that Google is increasingly going its own way. It already extensively customizes Linux and other open-source software for its internal use. Eben Moglen of the Software Freedom Law Center, among others, has been critical of what he sees as Google's relatively stingy contributions back to open-source projects in general. And although Google doesn't design its own processors, it does source custom motherboards from Intel that it uses to build many of its own servers.

Over the past couple of weeks, we've seen two more stories--one in hardware, one in software--that further highlight Google's increasingly vertical integration.

First is the story from Andrew Schmitt  of Nyquist Capital who posts that:

It is our opinion that Google (GOOG) has designed and deployed home-grown 10GbE switches as part of a secret internal initiative that was launched when it realized commercial options couldn't meet the cost and power consumption targets required for their data centers...

What is interesting about Google's approach is that it has eschewed traditional 10GBASE optical standards and instead adopted off-standard solutions that better suit its needs for time-to-market, power and port density, and cost. While Google makes use of the SFP+ cage format, it does not use the receive dispersion compensation (EDC) function typically associated with SFP+. Instead Google is looking to employ a combination of twinax cabling for short reach (<10m) intra-rack cabling and a motley 850nm SR-like standard. Off the shelf SR optical modules appear to work well up to 100m over without receive equalization. Ironically, Finisar (FNSR) proposed such a solution several years ago.

If true, that's two major components of datacenter infrastructure--servers and switches--that Google will be primarily buying rather than building.

The latest announcement concerns Android, Google's mobile phone software platform. As Nancy Gohring of the IDG News Service writes:

Instead of using the standards-based Java Micro Edition (JME) as an engine to run Java applications, Google wrote its own virtual machine for Android, calling it Dalvik. There are technical advantages and disadvantages to using Dalvik, developers say, but technology may not have been the driver for Google.

Google most likely built Dalvik as a way to get around licensing issues with Sun that would have come with using JME, said Stefano Mazzocchi, a developer and board member at Apache Labs.

CNET.com's Stephen Shankland provides further background. The details are messy in both their technology implications and their politics. However, the bottom line is that, in yet another case, Google appears to be voting for bespoke in-house development of some part of the hardware and software stack.

Google is, to be sure, Google. It's unique in many respects--both in its market position and in many of its attitudes. As such, I take what Google is doing as an interesting data point but hardly rock-solid evidence of where the industry is headed.

That said, if these are truly smart moves for Google...If they bring it unique cost or function advantages--and aren't merely reflections of a mostly harmless Google corporate personality quirk--then how can companies like Microsoft and Yahoo not head down a similar path?