Skip to main content

Cloud Compuing and Web 2.0: Great article by Tim O'Reilly!

Update 1: Nick Carr apparently saw some flaws in Tim's analysis, see below.

Tim has been evangelizing this while we were still in our nappies. Listen to the man!

Types of Cloud Computing

Since "cloud" seems to mean a lot of different things, let me start with some definitions of what I see as three very distinct types of cloud computing:

  1. Utility computing. Amazon's success in providing virtual machine instances, storage, and computation at pay-as-you-go utility pricing was the breakthrough in this category, and now everyone wants to play. Developers, not end-users, are the target of this kind of cloud computing.

    This is the layer at which I don't presently see any strong network effect benefits (yet). Other than a rise in Amazon's commitment to the business, neither early adopter Smugmug nor any of its users get any benefit from the fact that thousands of other application developers have their work now hosted on AWS. If anything, they may be competing for the same resources.

    That being said, to the extent that developers become committed to the platform, there is the possibility of the kind of developer ecosystem advantages that once accrued to Microsoft. More developers have the skills to build AWS applications, so more talent is available. But take note: Microsoft took charge of this developer ecosystem by building tools that both created a revenue stream for Microsoft and made developers more reliant on them. In addition, they built a deep -- very deep -- well of complex APIs that bound developers ever-tighter to their platform.

    So far, most of the tools and higher level APIs for AWS are being developed by third-parties. In the offerings of companies like Heroku, Rightscale, and EngineYard (not based on AWS, but on their own hosting platform, while sharing the RoR approach to managing cloud infrastructure), we see the beginnings of one significant toolchain. And you can already see that many of these companies are building into their promise the idea of independence from any cloud infrastructure vendor.

    In short, if Amazon intends to gain lock-in and true competitive advantage (other than the aforementioned advantage of being the low-cost provider), expect to see them roll out their own more advanced APIs and developer tools, or acquire promising startups building such tools. Alternatively, if current trends continue, I expect to see Amazon as a kind of foundation for a Linux-like aggregation of applications, tools and services not controlled by Amazon, rather than for a Microsoft Windows-like API and tools play. There will be many providers of commodity infrastructure, and a constellation of competing, but largely compatible, tools vendors. Given the momentum towards open source and cloud computing, this is a likely future.

  2. Platform as a Service. One step up from pure utility computing are platforms like Google AppEngine and Salesforce's force.com, which hide machine instances behind higher-level APIs. Porting an application from one of these platforms to another is more like porting from Mac to Windows than from one Linux distribution to another.

    The key question at this level remains: are there advantages to developers in one of these platforms from other developers being on the same platform? force.com seems to me to have some ecosystem benefits, which means that the more developers are there, the better it is for both Salesforce and other application developers. I don't see that with AppEngine. What's more, many of the applications being deployed there seem trivial compared to the substantial applications being deployed on the Amazon and force.com platforms. One question is whether that's because developers are afraid of Google, or because the APIs that Google has provided don't give enough control and ownership for serious applications. I'd love your thoughts on this subject.

  3. Cloud-based end-user applications. Any web application is a cloud application in the sense that it resides in the cloud. Google, Amazon, Facebook, twitter, flickr, and virtually every other Web 2.0 application is a cloud application in this sense. However, it seems to me that people use the term "cloud" more specifically in describing web applications that were formerly delivered locally on a PC, like spreadsheets, word processing, databases, and even email. Thus even though they may reside on the same server farm, people tend to think of gmail or Google docs and spreadsheets as "cloud applications" in a way that they don't think of Google search or Google maps.

    This common usage points up a meaningful difference: people tend to think differently about cloud applications when they host individual user data. The prospect of "my" data disappearing or being unavailable is far more alarming than, for example, the disappearance of a service that merely hosts an aggregated view of data that is available elsewhere (say Yahoo! search or Microsoft live maps.) And that, of course, points us squarely back into the center of the Web 2.0 proposition: that users add value to the application by their use of it. Take that away, and you're a step back in the direction of commodity computing.

    Ideally, the user's data becomes more valuable because it is in the same space as other users' data. This is why a listing on craigslist or ebay is more powerful than a listing on an individual blog, why a listing on amazon is more powerful than a listing on Joe's bookstore, why a listing on the first results page of Google's search engine, or an ad placed into the Google ad auction, is more valuable than similar placement on Microsoft or Yahoo!. This is also why every social network is competing to build its own social graph rather than relying on a shared social graph utility.

    This top level of cloud computing definitely has network effects. If I had to place a bet, it would be that the application-level developer ecosystems eventually work their way back down the stack towards the infrastructure level, and the two meet in the middle. In fact, you can argue that that's what force.com has already done, and thus represents the shape of things. It's a platform I have a strong feeling I (and anyone else interested in the evolution of the cloud platform) ought to be paying more attention to.




O'Reilly Radar


Nick on Tim's post:

So why has Google's search engine been able to steadily accumulate more and more market share at the expense of competitors? There are surely many reasons. Let me list several possible ones, all of which are likely more important than the network effect:

1. Google delivers (or in the past has delivered) superior search results as judged by users, thanks to superior algorithms, superior spidering techniques, or other technical advantages.

2. Google delivers (or in the past has delivered) results more quickly than its competitors (an important criterion for users), thanks to superior data processing systems.

3. Google has succeeded in establishing a strong brand advantage, in effect making its name synonymous with web search.

4. Google has, through partnerships, through the distribution of the Google toolbar, and through other means, made its search engine the default search engine in many contexts (and we know that users rarely change default settings).

5. Google has steadily expanded into new web properties and services that, directly or indirectly, funnel users to its search engine.

Now it's true that, if you want to define market liquidity as a type of network effect, Google enjoys a strong network effect on the advertising side of its business (which is where it makes its money), but it would be a mistake to say that the advertising-side network effect has anything to do with Google's dominance of the searches of web users.

The Google example, far from providing support to O'Reilly's argument that the network effect is the main way to achieve dominance on the modern web - that it is the secret to the success of "all Web 2.0 superstar applications" - actually undercuts that argument. And there are other examples we might point to as well. Apple's iTunes online store and software system has achieved dominance in digital music distribution not through the network effect (the company only recently got around to introducing a music recommendation engine that derives value from aggregating data on users' choices) but rather through superior product and software design, superb marketing and branding, smart partnerships, and proprietary file standards that tend to lock in users. There are plenty of "social" online music services built on the network effect; none of them has dented Apple's dominance. (I would also take issue with O'Reilly's suggestion that Wikipedia's success derives mainly from the network effect; Wikipedia doesn't become any more valuable to me if my neighbor starts using it. Wikipedia's success is probably better explained in terms of scale and scope advantages, and perhaps even its nonprofit status, than in terms of the network effect.)

Nick's post

NOTE: If anyone else goes around pissing on anyone's take on what the real Cloud is, I promise not to do anymore updates. Promised!

Comments

Popular posts from this blog

Security: VMware Workstation 6 vulnerability

vulnerable software: VMware Workstation 6.0 for Windows, possible some other VMware products as well type of vulnerability: DoS, potential privilege escalation I found a vulnerability in VMware Workstation 6.0 which allows an unprivileged user in the host OS to crash the system and potentially run arbitrary code with kernel privileges. The issue is in the vmstor-60 driver, which is supposed to mount VMware images within the host OS. When sending the IOCTL code FsSetVoleInformation with subcode FsSetFileInformation with a large buffer and underreporting its size to at max 1024 bytes, it will underrun and potentially execute arbitrary code. Security focus

Splunk that!

Saw this advert on Slashdot and went on to look for it and found the tour pretty neat to look at. Check out the demo too! So why would I need it? WHY NOT? I'd say. As an organization grows , new services, new data comes by, new logs start accumulating on the servers and it becomes increasingly difficult to look at all those logs, leave alone that you'd have time to read them and who cares about analysis as the time to look for those log files already makes your day, isn't it? Well a solution like this is a cool option to have your sysadmins/operators look at ONE PLACE and thus you don't have your administrators lurking around in your physical servers and *accidentally* messing up things there. Go ahead and give it a shot by downloading it and testing it. I'll give it a shot myself! Ok so I went ahead and installed it. Do this... [root@tarrydev Software]# ./splunk-Server-1.0.1-linux-installer.bin to install and this (if you screw up) [root@tarrydev Software]# /op...