Andreessen on Platforms
More discussion of platforms. This post comes from Marc Andreessen, who is currently working on a platform for building and deploying social web apps called Ning. One of the apps that has been built in Ning is We Love Etsy, a social network for people who love Etsy. Very nice.
Marc describes three kinds of internet-based platforms
Level 1 – API access – Flickr, Delicious, Twitter, etc, etc
Level 2 – API plug-in – Facebook
Level 3 – Runtime environment – Ning, Salesforce.com, etc, etc
Marc asserts that Level 3 platforms are the best for the developer. And I am not going to argue with Marc on technical grounds. That would be like me trying to beat my son at his Xbox.
Marc’s argument is that Level 3 platforms provide all of the infrastructure to build, deploy, and scale a web application and therefore are more attractive to developers. He says:
What are some of those issues? To list a few: You have to provide a runtime environment that can execute arbitrary third-party application code. You have to build a system for accepting and managing that code. You have to build integrated development tools into your interface to let people develop that code. You have to provide an integrated database environment suitable for applications to store and process their data. You have to deal with security
in many different ways to prevent applications from stepping on one
another or on your system — for example, sandboxing. You have to
anticipate the consequences an application succeeding and needing to be
automatically scaled. And you have to build an automated system underneath all that to provide the servers, storage, and networking capabilities required to actually run all of the third-party applications.
So here’s my question. With providers like Amazon increasingly providing the infrastructure to host, deploy, and scale a web app, and with rapid development tools like Ruby, and with the web as your runtime environment, isn’t it possible to do much of what a Level 3 platform provides directly on the web?
And isn’t it also true that building apps on the web itself, instead of plugged into Facebook, or resident in Ning, is more attractive to developers because the app is less reliant on the owner of the environment to continue to act in good faith toward the developer and their app?
Marc notes that the idea of app running "off platform" is relatively new concept:
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.
I think that apps running "off platform" are one of the great things about the Internet. A truly distributed computing environment. With all the benefits and challenges.
But I am not a developer. And as Marc says, "lots of people have opinions about platforms, but the people whose opinions matter are programmers, and people who can make decisions about what programmers program"
I would like to hear what the developers think. I know there are a bunch that read this blog and comment actively. So bring it on.
Marc is making an argument that clearly favors Ning’s PHP based platform as the “web 3.0” / “excutable web” is coming up. I scanned his lengthy post fairly quickly, but as one a couple years ahead of the crowd on the “executable web” domain, I’m thinking he’s at least concerned that the PHP strategy — which favors an existing developer base — may be getting stale.But more philosophically, The Platform from my perspective is the front end with lots of end users as in iGoogle or Facebook. The grounds for a market space.
Fred…great question regarding distributed computing environment. Please share any valuable insights if they are not posted as a comment and the sender is agreeable. Thanks…/wrk
The issue is that despite how cool amazon AWS is, it is by no means plug and play. Marc is right to say that creating something in Ning or salesforce is *far* easier than creating something web scale using AWS. This may not always be the case, but it is now. For example ec2 does not allow you to “automagically scale”. What it allows you to do is call up a CPU instance within a few minutes from a command line. By the way, if the CPU crashes you loose all your data if you havent saved it to S3. And S3, though cool does not look to ec2 like a hard disk – its this alternate interface that is not really convenient to write to.So anyway, the fact that you can create infinite virtual CPUs quickly does not mean you have a scalable solution. All it means is that you can quickly provision somewhat limited CPUs (i.e. no local persistent storage). But you still have to write all of the software for managing scaling. This is not trivial. And depending on the app it may be far from trivial. If, for a given application space a developer can create an environment/platform where other developers can scale “for free” this is great.I agree that this will eventually come to the web at large as you suggest, but we are far from there now. When it does, your thesis will be correct. But in the mean time this is a little like the difference between writing in C++ vs a scripting language, or even a garbage collected language like Java. C++ is arguably more powerful, but ease of use will always win out with programmers, and most modern languages are *much* easier than C, or C++ where everything is painfully manual.The bottom line… in the long run you are right. In the short run Marc is right.
long time listener, first time caller. as a developer, I am not sure I agree with Marc that the level 3 approach is a huge advantage in an absolute sense. there is usually a lot of overhead (database architecture, framework, ORM layer, test case infrastructure, etc) involved in learning to code for level 3 systems. level 1 platforms are usually much more straightforward, i.e. I pass you X and you’re going to give me back Y. most of the overhead in a level 1 system is in server set up, deployment, etc. this is something that most individuals and organizations have done many times. they may have their own unique way of doing it, but most programmers know how to get a server running with some code that they wrote in fairly short order.this is a long way of saying I think there are more trade offs than he is acknowledging in his portrayal of level 3 development. in the end there is definitely room for both approaches, and he is definitely right that some truly innovative things are possible with level 3 that may not be with level 1. obviously both approaches as they relate to the web are still in their relative infancy.
Paul — I agree with your comment. Also, if hosting etc is such a huge challenge, and the platform is keen to encourage developers, it would seem as though the company behind the platform could offer some kind of help with hosting…
“most of the overhead in a level 1 system is in server set up, deployment, etc. this is something that most individuals and organizations have done many times.”This is not scaling, it is server setup. Scaling is entirely about software. And software does not scale itself. Having more hardware does not make your application scalable. Creating software that is truly scalable without the application writer having to think about it is a really big deal. A great example of this is all the facebook apps that have gotten hammered because they were not scalable. It turns out that from a software perspective scaling is hard. In fact I recently read an interview with or article about Digg where they said that the server team specifically nixes features that product management would like because the features are too hard to scale. That sucks.
true, but scalability from a development perspective is an issue in all levels, whereas server setup is the development org’s responsibility in level 1, and the service’s responsibility in level 3.
“scalability from a development perspective is an issue in all levels,”nope. You missed the point of what marc is saying. He is saying at level 3, the platform handles software scaling. To get specific, in both salesforce.com and ning (level 3 platforms), the application developer does not have to worry *at all* about how many users hit his application – (ok I guess if you tried really hard you could prove me wrong and break them, but generally this is unlikely). Therefore there are (generally) no scaling issues for an application developer in marc’s definition of a level 3 app. You may disgree that marc’s premise of a platform that handles scaling is possible, but if you accept his premise that this is what level 3 apps do then your analysis is inaccurate.
Marc makes some interesting points, as usual. There is a historical pattern in desktop apps worth looking at that he doesn’t exactly address: As a “platform” becomes more ubiquitous, the level of technical skill of the people interested in developing for the platform become broader. It is a common mistake in software dev to assume that the only really valuable kind of developer is the uber-brainiac who dreams up amazing code that’s never been seen before. In my experience, there is a TON of value in the kind of guy (or gal) that hacks something together that solves a simple need. The code may not be rocket science, but if it’s useful, I for one think it has as much value as really clever code.If you look at desktop 3D animation software (something I have a lot of experience with), developer options split into two groups, a full blown roll-out-your-C++-dev-kit API and a high level scripting language. Even a coding idiot, such as myself, could hack together useful functionality through the scripting interface, and it certainly wasn’t limited to simple macros. Some of these apps use their own scripting language and others use things like Python. But though the advanced API, a “real” developer has the option to jump in to the core of the application and work wonders.I agree that Level 3 makes a lot of sense if you are aiming for broad adoption of your platform. However, I think that assuming or ensuring that Level 3 requires a high level of coding skill is a mistake that limits the growth of your platform in the long term…
Actually, if the creators of level 3 have full control over the interface (code allowed/used, interface for uploading/creating, etc.) then they have full control over the level of coding skill that is needed.One of the primary goals for a level 3 platform would be ease of use – developers don’t understand this, and they don’t encounter it near often enough, so most development environments and platforms don’t have this as a priority. The popularity of things like Ruby on Rails demonstrates how important usability is.
“…isn’t it possible to do much of what a Level 3 platform provides directly on the web?”You hit the nail on the head. I think this is still what the core of Web 2.0 is about. If you define Web 2.0 as the migration of desktop apps (on Windows as a platform) to the web, this represents a transition from Level 3 to Level 2.I’m a developer. I’ve written apps & functionality that use Del.icio.us and the Facebook platform. I agree with most of what has been said above.One thing I’d like to point out is that while development platforms like Facebook are tremendously advantageous to scaled distribution, they don’t do much good when they don’t work. The Facebook platform, while powerful, has been plagued with issues since its release. It still throws random errors on several of the apps that I use.It will be interesting to see how Level 2 evolves as these more ‘beta’ platforms move to more stable releases.
The technical reasons to use a “Level 3 platform” are great, but I think the most compelling argument is a more strategic one. The reason to develop on a Level 3 platform is that, assuming users derive great value from the underlying platform (i.e. Salesforce.com), my application becomes much more valuable to users by association with the platform than it would be as an independent entity.If you’re trying to build the next Facebook, that might not be a huge issue, but if you are building smaller CRM widgets it most certainly is. Could I build them with Ruby and scale them with things like S3? Sure, probably. But then it would be just another application living in its own world, with all of the barriers/switching costs that come with trying to get users to adopt something new. If I build it on the Salesforce.com platform, my users get a familiar interface, all their accounts/groups/configuration, all their Salesforce CRM data, etc, which means if all else is equal, they are much more likely to use my application and will derive much more value from it. The tradeoff is as you mentioned: now I have to rely on Salesforce for my continued success. But depending on what you’re building and what the typical barriers to success are, that might not be such a bad thing.Same reason people should build social networks on Ning: you remove the largest barrier to adoption of a new social network app currently, which is that people are tired of constantly rediscovering their friends. All that extra Level 3 stuff just makes it run better.
Strategically, Level 3 is a poor choice. Developing for Level 3 locks you into their service and makes you beholden to another company for your entire existence–including functionality, users, scalability and uptime. It’s like developing for Windows, but worse.If I were to develop an online social service, I’d want to to interface or exist within with as many of the most widely-used sites as possible. I might make a Facebook app, a way to post to Flicker, a Twitter interface, a desktop app or widget, as well as a standalone public website. Level 2 and Level 1 platforms give you this option. while Level 3 doesn’t.
“Strategically, Level 3 is a poor choice.”This is of course true for some and not others. It depends on how many resources you have and what your strategic goals are. All platforms have advantages and disadvantages that must be analyzed, but it is rarely true that you can make such a broad statement as “x” is a poor choice. Clearly there are enough Ning and salesforce customers to suggest that for many, the tradeoffs are worthwhile.
This isn’t entirely true. A well designed level 3 can provide level 2 & level 1 functionality.If you, as a developer, write for a level 3 app, then the code you’re providing could in fact be a level 2 (plug-in) or level 1 (api) application, interfacting a piece of the platform – or your app on the platform – into other sites.Andreeson’s article even comments on this ‘superset’ feature, and my opensource view of level 3.
A real level 3 app would actually provide methods to implement level 2 & level 1 functionality.Andreeson’s article even mentions this supersetting feature/functionality explicitly, along with open ‘sourcing’ functionality of level 3, and several other things that just aren’t as feasible with level 2 or level 1, alone.The whole idea of level 3 is that you can expand on what’s provided, and your only limitation is your creativity.I do agree with the problem of being ‘tied in’ to the platform, but this is an old problem, and we’ve only been able to move away with it in full reality with the advent of the internet. Desktop apps are still programmed for specific platforms – OSX, Windows, Linux, or whatever else is out there. There are multi-platform products, but they aren’t as ubiquitous as people think, and they certainly aren’t easy to develop as such.Not to say platform-dependence should stay around… but developers are used to it, and until something better comes along, level 3 isn’t a bad thing at all.
Actually, from this developer’s viewpoint, Level 1 & Level 2 are different takes/methods on the same concept.If you view it from a perspective of ‘requester’ (api user, or facebook-like site) and ‘requestee’ (api provider, or facebook app), then Level 1/Level 2 are really the same thing, with the only difference being which piece of code is provided ‘off-site’.In Level 1, the requester writes their code off-server, and is really only *communicating* with the server… not actually impacting it. Anything the server does is a result of the communication, not of the external code.In Level 2, the requestee writes their code off-server, and is really only *communicating* with the server. In this case, providing requested content, or making changes based on the communications from the facebook-like, plugin site.Level 3 sounds more like a full development methodology to me, with people writing modules for a growing, community-based application. It certainly opens you to more malicious users and attacks, but is very akin to the opensource model for more ‘traditional’ apps. I think most everybody realizes the power of opensource in today’s market. One person could write a module for their application on the platform, and publish it for other people to use. Even something as ‘simple’ as a new search algorithm. And they publish it, so other people on the platform can use it in *their* app. Why reinvent the wheel?Implemented correctly, nothing says a Level 3 app has to be difficult for its end-developers to use. Creating the Level 3 platform is the hard part. The question isn’t whether people would use it… but will somebody actually make a usable implementation?
I took the point of Marc’s piece to be that on a “Level 3” the developer doesn’t have to pay for bandwidth or hosting or worry about scaling very very quickly when Facebook-style superviral adoption happens. Developers still need to pay for Amazon services, so even though it lets them scale very quickly they still need the checkbook to support it.He has a valid point- if you don’t have a revenue stream to support your traffic then an “all you can eat” Level 3 platform makes a lot of sense.OTOH, I suspect that people haven’t been building Level 3 platforms all along because it takes more work to convince developers to use them if they are going to be “locked in”.
Marc’s platform is proprietary, so building on his platform makes you a remora fish to his shark; the shark will always be the primary beneficiary, and remoras eating scraps. Microsoft has over 70,000 commercial software developers that promote and push Windows; with each new app for Windows, more Windows licenses are sold, so it’s good for the platform owner. With SalesForce, you are depending on their reliability and uptime (or lack thereof), and building on sand rather than a solid foundation. It might introduce you to new potential customers, but Benioff has a fit one day about uptime and reliability because their APIs fall apart or the platform failes to scale to the N, and good luck.A different platform is “common infrastructure”, like HTTP. HTTP is a platform that’s ubuiquitous and not dependent on any single company. Windows is now essentially ubuiqitous, that that’s fairly common, but it’s still proprietary and sports a nasty dependency,. The addition of new apps is largely useless to Microsoft at this point, unless they are hugely compelling such that someone leaves MAC or Linux to go to Windows (unlikely). Third parties suffer through Microsoft’s blunders and bugs because the customer base is huge, with MAC OS on less than 5% of computers worldwide.Facebook and other “platforms” are just web apps with a number of APIs in service. It doesn’t make them open, and doesn’t make them compelling. You’re playing in their sandbox, and if you build a dependency on them, you are beholden to them, their practices, their ups and downs. I would never invest in a company that bases its existence on a relatively new company’s “platform”. It’s simply too risky, even if it’s neat.What will be interesting is to see apps that are offered through Facebook that are also platform independent–no Facebook, no problem. No SalesForce, no problem. Just give me your data, and we’re off to the races. Serious companies, though, are not going to build primarily around these APIs, and smart investors will stick to true apps and not “remora” features dependent on the sharks.And Marc, you don’t need to provide a data store to be a successful platform. It can be helpful, but it’s cumbersome to developers to conform to your version of data storage and retrieval. People, keep in mind that while Ning is neat, remember LIveWire–not a compelling app server and full of bugs. If you based your app on LiveWire back in the 90s you suffered through a lot of highly unscalable hell–same with the Netscape server, which actually declined in performance on 4-proc servers. Just sayin.
Some good points here. My business partner and I are evaluating some ways to get our site ready for the masses. We’ve seen an offer from Sun where they’re offering a pretty decent deal for startups and their main message is scalability with their web 2.0 servers because of their hardware and Solaris software. Anyone had an experience with these guys?
make sure you get a free pair of ear plugs. Sun is known to have very load server
I disagree with Marc.I would like to have all 3 ways !!Some applications work just fine in Facebook the way it is designed, some others would clearly benefit from a L3 kind of platform/infrastructure.Also, if I were to design an application to run atop Ning, I would still want to have L1 capabilities.Those levels as presented by Marc are not necessarily mutually exclusive.But really, who am I to disagree with the billionaire programmer ?:-)
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.Regards & hoping not to sound too sarcastic! :-)Terry
I think this is the longest comment I have ever seen on a blog. I mean, really, this is long. And with all those block quotes, it’s a little nuts. Maybe you can do the bullet point summary version.
Yup longest comment ever! Please convert this to a post for easy reading and link it to me :). Anything that got you this fired up, must be interesting.
Hi Mark. I actually did go back and extract that comment into a posting. It’s at http://blogs.fluidinfo.com/…It’s long because I put a lot of thought into it – both in the years before Marc wrote his blog entry and while I was writing the comment – not (only) because I’m a gasbag. We’re building a platform too, and thinking about that is very important to me (I sold my own apartment in order to have the chance to build a platform).
Fantastic, I knew there was a good story behind this comment (especially since you dug it up and linked it from 2 years ago) 😀
Seeing as you’re into passion, you might enjoy http://blogs.fluidinfo.com/…And two related earlier posts (written the same night) that set the scene:http://blogs.fluidinfo.com/…http://blogs.fluidinfo.com/…Terry
Bloody Norahs Terry! Now I know why you need one of those fancy keyboards…
His sharing rate is WIDE BAND. Now to check if it’s groovy reading.
Awesome input Terry. It’s queued up for this mornings walk/reading, revving up my eyes with some TED videos and articles on optimal log SSD formats
Marc is totally right.Building information systems (especially enterprise ones) is not just a matter of implementing the functional requirements, i.e. designing a database (although this alone is often far from being trivial), drawing some forms, wiring GUI components with database tables and writing some glue code. The problem is rather about (list non exhaustive):* integrating into the system all the configuration and administration functions required by any business-grade solution (users management, access control, logging and auditing, data backup & recovery to name a few).* setting up a reliable IT infrastructure (hardware, operating system, DBMS, application server, RAID disk array, backup tape, etc.), deploying the implemented software, tuning the whole thing and keeping it up and running.* making the system learnable and usable by systematically applying user-interface design patterns (graphics and interaction mechanisms) across the whole system.* making the system maintainable and extendible in the long term by means of a pattern-oriented distributed architecture, and by ensuring that all the code is properly documented.* making the system scalable from one to dozens or hundreds of concurrent users by leveraging the distributed architecture with an appropriate and robust application-level locking system.And all this stuff is HARD, so… if a platform allows you to have substantial savings in those aspects, then it’s definitively worth its cost.Unfortunately for Ning, I don’t think that a tool allowing the user to assemble predefined mini-applications (agenda, wiki, chat, etc.) is any close to what I would define a development platform. I think Salesforce ApEx is way ahead with respect to Ning from a technical point of view (although the two platforms are clearly targeted at very different markets).
I wonder what he’d say about Metaplace.