My brother sent me an email the other day asking the above question. As I thought about my reply, I really did not know how to answer him. I think he was asking where I host my business web site, but I use the cloud for such a variety of things today and the offerings continue to grow each day. With that thought in mind, I am posting an updated version of a strategy paper I did a few years ago. This is expanded from an original post by Marc Andreessen. (I miss his excellent blog.)
He suggests that there are three different levels of web “Platforms.” Platforms are: “Any system that can be programmed and therefore customized by outside developers — users — and in that way, adapted to countless needs and niches that the platform’s original developers could not have possibly contemplated, much less had time to accommodate… If you can program it, then it’s a platform.”
I’ve modified his take on the levels to include from web offerings that do not quite meet the “platform” definition to those that go beyond his definition. I will discuss each in more detail:
- Level 0: Stand alone Applications – Applications that run on the web to provide functionality limited to what is coded by the application provider.
- Level 0.5: Mash-ups – Let developers gather web information for publishing to other applications without using a formal API.
- Level 1: Access API – Provide access to functionality using an access protocol such as SOAP. The developer’s application code lives outside the platform and calls into the platform via the API to draw on data and services.
- Level 2: Plug-in API – Lets developers build new functions that are injected, as a “plug in”, to the core system and its user interface. Again, the applications run elsewhere, but functionality displays on the platform via a plug-in API to their interface.
- Level 3: Runtime Platform – Provides a framework for developers to build and run applications on the web. A developer’s application runs online, inside the platform itself.
- Level 4: Infrastructure Services – Provides resources through the web to be used for computing power.
Over the last couple years, these levels have blended and many offerings have components that blur the lines. I think it is still useful for users, developers and platform providers to consider these levels and how they can push offerings to higher levels when appropriate.
0 – Stand Alone Applications:
I talk about this category to demonstrate what a platform is not. Stand alone or Software as a Service (Saas) applications do on the web what desktop apps did in the past. They are used to write a letter, calculate an equation, store files, track time and money, etc. They may have some configuration, but for the most part, they do what the developer told the application to do when it was created. Some of the popular stand alone applications I have used are shown below and there are many, many more.
The interesting thing about stand alone applications on the web is that most of them allow you to work not alone. While the desktop can be a tricky place to share and collaborate, the web naturally lends itself to sharing. So, these applications often allow for multiple users or the ability to invite others to look in or work along side of you. Some exist for the sole purpose of allowing collaboration.
- Access from anywhere
- Collaborate easily
- Can often upload and download data and docs
- No need to install or support software
- Limited configuration
- Customization & new features only through provider
- No integration capabilities
- If company dies, so does application & potentially data
0.5 – Mash-ups:
I added this category to allow for building platforms that interact without any formal API provided by the platform provider. The applications using this approach run outside the host environment and extract information from the platform application. I put REST and RSS in this category because they don’t require coding by the provider to expose and share information. Screen scraping is another technology widely used when formal API’s don’t allow information sharing. Applications and development environments to streamline creation of secondary applications using these approaches take advantage of these techniques.
more after the break> Pros:
- Creates access to web information without customized API’s
- Allow for data portability across the web
- Building the application structure is left to the developer
- Or, need a reader, other web platform or custom code to render and run
- Distribution largely left to developer
- Can be brittle
- Limited capabilities
1 – Access APIs:
Access API’s allow third party developers to call into a platform and request specific information or execute functionality on the platform. This was the first and is still the most common way to access platforms on the web. More and more applications are exposing API’s to share their functionality (often called web services.) The exposed functionality can be very rich. When third party sites use PayPal to settle payments, share shipping information from UPS, show custom data on a map, or share pictures from Flickr, an API is being used.
- Makes useful functionality available to 3rd parties
- Easy to access platform
- May provide coding assistance through Software Development Kits (SDKs)
- Building the application structure is left to the developer
- Running the application infrastructure is left entirely to the developer
- Burden of distribution with the developer
- Aside from the API structure, no standards for the developer
2 – Plug-in APIs:
Plug in API’s are Windows for the web. The display side is managed by the platform, but what runs behind those windows are run by the application. Facebook is perhaps the best know early example of this type platform. While Facebook makes some access API’s available to its developers to share social information, it has also gone a step further to provide the presentation for the applications that use those API’s so that they show alongside of native Facebook functionality. They also provide a distribution capability that aids with finding and installing the applications running on the platform. Beyond that, the applications are hosted and supported by the developer. Other examples are found on the recently released Ning apps (though they aspire to be a platform service themselves) and the numerous widget platforms across the web.
- Get common look and feel
- Assistance with distribution
- Some standards applied through SDKs
- Can create code sharing
- Building application structure is responsibility of the developer
- Running the application infrastructure is left to the developer
- Application is not available if platform dies
3 – Run-time Environments:
Run time environments are the most complex platform available on the web. Sometimes called Platform as a Service (PaaS) some run-time platforms offer extreme configuration flexibility focused on a specific horizontal. Others are coding environments with all the flexibility of desktop Application Frameworks. Perhaps the best know of this type platform is Salesforce.com’s. While their core offering focuses on Level 0 CRM application, the force.com platform is a complete runtime environment that extends that capability. Platforms, by their nature must offer all the levels shown below their Application Exchange:
The Application Exchange extends the platform by offering a distribution and revenue generating mechanism for the applications created on their platform. Other run-time platform examples are shown below. My favorite is 2nd Life – though it requires a fatter client, it meets are the requirements of a cloud runtime environment.
- Provides development tools and framework
- Provides infrastructure
- Provides runtime environment
- Can assist with distribution (marketplace/exchange)
- Can assist with code sharing/templates
- Difficult to build as a provider
- Difficult to run as a provider
- Standards are still young and changing
- Can be complex to learn
- Configuration and code control is challenging for developer
- If platform dies, so does application & potentially data
4 – Infrastructure Services:
Infrastructure offerings (Infrastructure as a Service or IaaS) provide only the back end computing power of a platform. Services provided includes CPU, load balancing, DNS, bandwidth, memory, file storage, and database. These offerings differ from managed services in that they typically use virtualization to easily scale the infrastructure capacity provided based on user needs. They typically service multiple clients from a single facility using a scalable cost structure. Coding stays locally managed in a client environment and then code is deployed to the cloud infrastructure to run. My web hosting provider is a mid-range provider of Infrastructure Services while Amazon was early to offer them on a enterprise scalable level. Other examples are shown below.
- Provides scalable infrastructure
- Can be configured for almost any use
- Cost effective to scale from small to large
- Code is typically independent of the provider (though some services now use special protocols)
- Can be complex to learn
- Configuration and code control are developer’s responsibility
- Can have hidden complexities to manage