In my podcast with Ed Iacobucci about DayJet’s approach to reinventing air travel, Ed recalls the moment when he knew that the Eclipse VLJ (very light jet) represented the hardware component of a new platform. His contribution would be to create the operating system that would enable new travel applications.
Antonio Rodriguez, who joined me for another podcast about Tabblo, the online photo service he founded, enjoyed the Ed Iacobucci podcast but concluded:
I think I am beginning to develop an aversion to the term platform.
When I read that, I said to myself: “Yeah, me too.”
But we can’t help ourselves. On the very same day, Antonio responded to Marc Andreessen’s taxonomy of platforms. So did lots of others, including Joshua Allen.
Marc’s post defines three levels of platform:
- Flickr-style data-access APIs.
- Facebook-style containers of “Internet plug-ins.” While hosted by their container, these plug-in applications must also provide their own life support.
- Ning-, Salesforce-, and Second Life-style runtime environments that fully support their dependent applications.
As both Antonio and Joshua point out, Marc’s level 3 runtime leads to the sort of lock-in scenario that developers have learned to regard with suspicion. Antonio pushes back on Marc’s characterization of Amazon’s S3 and EC2 as “only sort of” a level 3 platform. Facebook alone may be a level 2 platform, he says, but in combination with Amazon’s neutral infrastructure it already reaches level 3. And of course Amazon’s services can recombine with other level 2 platforms to yield other level 3 platforms.
Joshua, meanwhile, questions the need for levels 2 and 3. He thinks that Marc’s base platform — the data flowing at level 1 — has potential we’ve scarcely begun to realize. I agree. Syndication-oriented architecture surely has limitations, but we haven’t run into them yet.
It’s also worth noting that Marc’s taxonomy is wholly cloud-centric:
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.
I’ll go along with that, but only if we can extend our definition of the cloud to encompass what the Internet originally was: a network of peers. With rare but notable exceptions (e.g. BitTorrent) it hasn’t been that for a long time. I think it will be that again. There’s a level 4 platform waiting in the wings. At level 4, the cloud of storage and computation is partly centralized in a handful of intergalactic clusters, and partly distributed across a network of humble peers. Microsoft’s forthcoming Internet service bus is one example of a level 4 platform. I hope, and expect, we’ll see others.
Jon, if the lowest of the low-level APIs (storage and computation) get re-formed as a set of P2P services, ‘Level 4’ is the wrong name for it, since it will (optionally) underlay the other levels. I think you’d have to call it ‘Level 0’. Other strands in this thread are server virtualization and ‘Hardware as a Service’ (HaaS).
But, given the premise (which I largely agree with), I think it is safe to assume that for these ideas to succeed in the current environment, the industry as a whole cannot tolerate re-proprietization of the lowest levels of the infrastructure stack (proprietary implementations of interoperable standards are still kosher, though).
Instead, we will need a P2P-service equivalent to POSIX, and I would be very surprised if it didn’t turn out to be RESTful (but possibly with one or more new non-http URI schemes).
“I think you’d have to call it ‘Level 0′.”
Great point!
“Instead, we will need a P2P-service equivalent to POSIX, and I would be very surprised if it didn’t turn out to be RESTful”
About 10 years ago I was working on something was calling distributed HTTP: http://jonudell.net/download/dhttp.html. I still like the idea.
I agree that MA’s viewpoint is exclusively cloud centric (shocking). And Michael Bernstein nails it with the P2P stack. What happens when people really do start to care about privacy in the cloud?
Which reminds me of your discussion of “lifebits.” Maybe the user will eventually want to retake full control and the only way to do that is to have the application and data run from my personal “datacenter” and get streamed/cached throughout the cloud in a non-persistent P2P way.
Sure the application code comes from the cloud (I subscribe to an app) and maybe there is some synchronization, syndication to the cloud, but more likely through the cloud(the cloud is an essential service in connecting your personal data center with mine, and promise some degree of resilience via caching (who’s TTL I control) but not all important). Unfortunately asymmetric internet connections and net neutrality issues may hold this back.
The internet is fundamentally about E2E. The cloud shouldn’t be an endpoint (unless necessary for backup purposes, or caching) rather the cloud is distribution, the cloud is what allows all that level 1 connectivity to occur. In this world Facebook is runs as a local app (cross platform one would hope) so that neither the Facebook corporation ownz my stuff nor my friends who subscribe to my stream which is a non-persistent and revokeable cache on their personal computer.
But I may be clouding the issue.