Add to Technorati Favorites

On Andreessen on platforms

[This taken from my comment on Fred Wilson‘s posting Andreessen on Platforms, in which he discussed Marc Andreessen‘s posting The three kinds of platforms you meet on the Internet.]

I think Marc’s posting has two flaws. The first, which is serious, is that he didn’t put enough thought into it. The second, less of a problem, is that in several places it comes across as biased and a bit of a Level 3 sales pitch. I may be guilty of the former in what follows. Certainly my reply is a bit piecemeal – but there are only so many hours in the day.

In what follows, when I talk about “you”, I mean you the humble individual programmer.

Firstly, things become clearer if we categorize Marc’s Levels 1, 2 and 3 differently. Level 1 and 2 are two sides of the same coin:

  • Level 1: You write an app, and you call out to an API (a library of functions) that someone else has written.
  • Level 2: You write functions, and an app that someone else has written calls you (treats your code as a library function it can call).

To me these things are opposites. Within Level 2, there are two classes:

  • Level 2a: You write functions. An app that someone else has written calls your code, which runs on your server.
  • Level 2b: You write functions. An app that someone else has written calls your code, which runs on their server.

My Level 2b is what Marc calls Level 3. I’ll continue to use his terms.

Note that only in Level 1 are you really writing a full app. In level 2 and 3 you’re writing functions that are called from an existing application (like facebook or photoshop) that you almost certainly didn’t write. To make you feel better, they give your functions pleasing names like “plug in” (photoshop), “extension” (firefox), and even “app” (facebook).

To me that’s a more logical division of the 3 classes. I see no reason at all to call Level 1 a “platform”. You are writing an app. You’re calling someone else’s libraries – some of them will be local, some will be on the network. You’re not writing a platform. The only platform here is in the local OS of the machine your app is running on.

If we stop calling Level 1 a platform, it makes that word much less cloudy. That means that things like Photoshop, Firefox, and Facebook (Level 2), and Ning, Salesforce.com, and 2nd life (Level 3) all provide platforms for you. But Flickr, delicious, the Google maps API, etc., are not platforms and calling them that is just confusing. They’re just APIs or libraries that other apps can call (across the network, in these cases).

Next, virtually ALL applications in operation today are running in Level 3 platforms. Most of them run in the environment provided by operating systems.

Once you look at things that way, you see that the thing which is important is the runtime environment provided by the Level 3 platform you are already running on. Is it fast, secure, scalable, flexible, etc.? Can you write the kinds of things you want to write with it? Should you try something else?

I think Marc didn’t look at his Level 3 this way, or at least not clearly.

Now, traditionally in the field of computing, there has been a single main way of providing a platform. You provided a computer system — a mainframe, a PC operating system, a database, or even an ERP system or a game — that contained a programming environment that let people create and run code, plus an API that let them hook into the core system in various ways and do things.

The Internet — as a massive distributed system of many millions of internetworked computers running many different kinds of software — complicates things, and gives rise to three new models of platform that you see playing out in the Internet industry today.

I don’t think they’re all platforms, and I don’t think any of them are new :-)

But let me say up front — they’re all good. In no way to I intend to cast aspersions on what anyone I discuss is doing. Having a platform is always better than not having a platform, period. Platforms are good, period.

Hey, all platforms are great. But some are greater than others…

Level 1 is what I call an “Access API”.

This is undoubtedly a very useful thing and has now been proven effective on a widespread basis. However, the fact that this is also what most people think of when they think of “Internet platform” has been seriously confusing, as this is a sharply limited approach to the idea of providing a platform.

Do most people think of things like the Flickr API as being internet platforms? If it’s sharply limited (I agree), then please let’s not call it a platform.

What’s the problem? The entire burden of building and running the application itself is left entirely to the developer. The developer needs to provide her own runtime system, programming language, database, servers, storage, networking, bandwidth, and security, and needs to take responsibility for running all of the above — and then exposing the application to users. This is a very high bar in terms of both technical expertise and financial resources.

This is painting an overly bleak picture. Almost every application programmer on earth uses an off-the-shelf runtime system (e.g., an OS or a Java sandbox), off-the-shelf databases, servers, networking, etc. Yes they choose a programming language (as they do if they choose to use a Level 3 system). It’s work to pick these things out and combine them but that’s a very far cry from shouldering the _entire_ burden.

This is an example of what feels like salesmanship in Marc’s article. He’s right in general, but the way he puts it feels slanted.

As a consequence, you don’t see that many applications get built relative to what you’d think would be possible with these APIs — in fact, uptake of web services APIs has been nothing close to what you saw with previous widespread platforms such as Windows or the Mac.

And this isn’t a good comparison. It’s comparing use of a Level 1 API to use of what Marc later tells us is a Level 3 system (a traditional OS).

Because of this and because Level 1 platforms are still highly useful, notwithstanding their limitations, I believe we will see a lot more of them in the future — which is great. And in fact, as we will see, Level 2 and Level 3 platforms will typically all incorporate an Level 1-style access API as well.

Right. In fact Level 1 platforms (aka APIs) underpin all of Marc’s levels. Which is to say that even if he’s right, the Level 1 “platform” isn’t going away or lessening in importance – that’s because it’s not a platform at all. It’s a API, and libraries of functions exposed as APIs are useful things to have around. Likewise, APIs on the local OS aren’t about to go away either – in fact they’re crucial to the operation of the OS, just as they are to the operation of a level 3 platform (which is also running in a Level 3 OS).

So Level 1 isn’t going anywhere, or getting less important.

When you develop a Facebook app, you are not developing an app that simply draws on data or services from Facebook, as you would with a Level 1 platform. Instead, you are building an app that acts like a “plug-in” into Facebook — your app literally shows up within the Facebook user experience, often as a box in the middle of a page that Facebook otherwise defines, such as a user profile page.

Here (as with Photoshop or Firefox), your code is like a library function you write that is called by another app. In this case, your code runs on your server, and the calling app (usually on another server, if it’s a web app) takes your results and displays them (often to a web browser).

Level 3 is what I call a “Runtime Environment”.

In a Level 3 platform, the huge difference is that the third-party application code actually runs inside the platform — developer code is uploaded and runs online, inside the core system. For this reason, in casual conversation I refer to Level 3 platforms as “online platforms”.

And here, your code is like a library function you write that is called by another app. In this case, your code runs on the platform’s server, and the calling app (on their server) takes your results and displays them (often to a web browser).

Obviously this is a huge difference from Level 2. And this difference — and what makes it possible — is why I think Level 3 platforms are the future.

And the past.

There follow a number of breathless paragraphs that describe exactly why it’s hard to build an OS, and what the advantages are once you manage it.

Then it’s acknowledged that yes, this is all… just like having an OS!

So those long paragraphs feel like Marc is either completely blind to an _extremely_ obvious and almost perfect analogy, or, like he’s a salesman trying out a snow job on just how incredibly amazing these totally new Level 3 platforms will be. It’s impossible to think #1, so I’m left feeling #2.

The Level 3 Internet platform approach is ironically much more like the computer industry’s typical platform model than Levels 2 or 1.

Back to basics: with a traditional platform, you take a computer, say a PC, with an operating system like Windows. You create an application. The application code runs right there, on the computer. It doesn’t run elsewhere — off the platform somewhere — it just runs right there — technically, within a runtime environment provided by the platform. For example, an application written in C# runs within Microsoft’s Common Language Runtime, which is part of Windows, which is running on your computer.

At which point you note that basically all programs already run in a Level 3 platform:

I say this is ironic because I’m not entirely sure where the idea came from that an application built to run on an Internet platform would logically run off the platform, as with Level 1 (Flickr-style) or Level 2 (Facebook-style) Internet platforms. That is, I’m not sure why people haven’t been building Level 3 Internet platforms all along — apart from the technological complexity involved.

But nothing is running “off platform”. It’s all already Level 3. Yes, there are differences in environment… coming up.

So who’s building Level 3 Internet platforms now?

First, I am — Ning has been built from the start to be a Level 3 platform.

Second, in a completely different domain, Salesforce.com is also taking a Level 3 platform approach

Third, and again in a completely different domain, Second Life is a Level 3 platform.

Fourth, Amazon is — I would say — “sort of” building a Level 3 Internet platform with EC2 and S3. I say “sort of” because EC2 is more focused on providing a generic runtime environment for any kind of code than it is for building any specific kind of application — and because of that, there are no real APIs in EC2 that you wouldn’t just have on your own PC or server.

Ah, there’s a very interesting bias…

The generic traditional PC OS is a Level 3 platform, despite the fact that it’s not specifically geared towards any particular use. But EC2/S3 are somehow only sort of Level 3 precisely because they have the exact same property???

By this, I mean: Ning within our platform provides a whole suite of APIs for easily building social networking applications; Salesforce within its platform provides a whole suite of APIs for easily building enterprise applications; Second Life within its platform provides a whole suite of APIs for easy building objects that live and interact within Second Life. EC2, at least for now, has no such ambitions, and is content to be more of a generic hosting environment.

However, add S3 and some of Amazon’s other web services efforts to the mix, and you clearly have at least the foundation of a Level 3 Internet platform.

I might argue this the other way round. Things like Ning and 2nd life and Facebook are trying to be real Level 3 platforms to allow people to build a wide range of apps (i.e., 3rd party functions that they call), but they’re only “sort of” true Level 3 because they’re built for a specific purpose and so are only useful for that purpose – even if the purpose is broad, like “the” social network.

Things that are more generic, like EC2 and S3, are more like the generic computational environment provided by a traditional OS. And for that reason, one can expect them to be used for a wider range of applications (including standalone applications, not just code that lives within the Facebook or Ning world). For that reason you might expect that applications written against them will be longer-lived, as they will not die as fashion and coolness moves its fickle hand from MySpace to Facebook to Ning to…?

Would you buy a used Level 3 platform from this man?

Fifth and last, Akamai, coming from a completely different angle, is tackling a lot of the technical requirements of a Level 3 Internet platform in their “EdgeComputing” service — which lets their customers upload Java code into Akamai’s systems. The Java code then runs on the “edge” of the network on Akamai’s servers, and is distributed, managed, and secured so that it runs at scale and without stepping on other customers’ applications.

This is not a full Level 3 Internet platform, nor do I think Akamai would argue that it is, but there are significant similarities in the technical challenges, and it’s certainly worth watching what they do with their approach over time.

Why is it not a full Level 3 platform? Because it doesn’t have a particular focus?

I believe that in the long run, all credible large-scale Internet companies will provide Level 3 platforms. Those that don’t won’t be competitive with those that do, because those that do will give their users the ability to so easily customize and program as to unleash supernovas of creativity.

Oh my!

But having already said that Level 3 platforms will need underlying Level 2 and Level 1, it doesn’t seem like the Level 3 providers are driving the lesser levels out of the marketplace.

One might instead argue that it’s the Level 3 providers who are most likely to disappear. We’ve seen exactly that happen in the traditional Level 3 world (operating systems), while some applications and many great libraries hop happily from one Level 3 environment to the next.

I think there will also be a generational shift here. Level 3 platforms are “develop in the browser” — or, more properly, “develop in the cloud”. Just like Internet applications are “run in the browser” — or, more properly, “run in the cloud”. The cloud being large-scale Internet services run on behalf of users by large Internet companies and other entities. I think that kids coming out of college over the next several years are going to wonder why anyone ever built apps for anything other than “the cloud” — the Internet — and, ultimately, why they did so with anything other than the kinds of Level 3 platforms that we as an industry are going to build over the next several years — just like they already wonder why anyone runs any software that you can’t get to through a browser. Granted, I’m overstating the point but I’m doing so for clarity, and I’m quite confident the point will hold.

But everything _already_ runs “in the cloud” on a Level 3 platform. Your local OS has far more functionality, more speed, more libraries, more space, more flexibility, etc., for you to run your applications in. OK, I’m being a bit difficult, and understating the point. Maybe.

Now to the main point, which I think is valid, but which Marc doesn’t answer.

Before we had operating systems with all their benefits (see the long list of benefits Marc tells us will accrue from his Level 3 – ease of use! open source! buying and selling code that just runs!) a forward-looking person could have looked ahead and predicted the rise of the operating system. What sorts of programs, what supernovas of creativity might they have predicted?

Marc looks ahead…

A new platform typically enables a new set of applications that were not previously possible. Why else would there be a need for a new platform?

But: keep this in mind; look for the new applications that a new platform makes possible, as opposed to evaluating the new platform on the basis of whether or not you see older classes of applications show up on it right away.

But give us no examples at all.

I’m extremely interested in this. What will these applications be?

Is it true that what we can build with these future systems is not “possible” without them? Or just not feasible? Where does their extra power come from? I think it’s NOT principally from the great diversity of apps that can be written to run on these platforms, but from what you gain by having a large number of apps running in the _same environment_ – be it in an OS with a file system, a process subsystem and communicating processes, or a Level 3 internet platform with whatever it provides.

In the fullness of time, whenever that is, we may see the rise of truly open internet Level 3 platforms that will challenge the well-funded closed commercial ones. Meanwhile, I’m happy to _only_ be working away at Level 1.


You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

2 Responses to “On Andreessen on platforms”

  1. The levels are obfuscation to the inherent commonality of functional software.

    Code can reside in a library and be accessible via an API (my standard API is linking to my c++ libs, so I'm an old fuddy duddy).

    Code can run on remote machines and be accessed by a browser (my recent jaunts in php, lift/scala, and python have been slow but wildly educational).

    Code can run on my local host or on a remote host and display on my local host, or it can run on my local host and update data in a cloud that is accessed by a remote host.

    The core principle is that code represents machine entities that can perform functions on data, and user input. These entities can exist locally or remotely. The more powerful the default functionality becomes, the higher level access is granted to non programming users (I love the idea of domain experts building applications with modules even though they don't grock coding).

    Thanks for pointing me to this article Terry, I'm a subscriber now and about to read up your links on passion and creativity.

  2. The levels are obfuscation to the inherent commonality of functional software.

    Code can reside in a library and be accessible via an API (my standard API is linking to my c++ libs, so I'm an old fuddy duddy).

    Code can run on remote machines and be accessed by a browser (my recent jaunts in php, lift/scala, and python have been slow but wildly educational).

    Code can run on my local host or on a remote host and display on my local host, or it can run on my local host and update data in a cloud that is accessed by a remote host.

    The core principle is that code represents machine entities that can perform functions on data, and user input. These entities can exist locally or remotely. The more powerful the default functionality becomes, the higher level access is granted to non programming users (I love the idea of domain experts building applications with modules even though they don't grock coding).

    Thanks for pointing me to this article Terry, I'm a subscriber now and about to read up your links on passion and creativity.