Maybe it was because I was reading it on my new iPad, but really enjoyed this post by John Doerr and partners on TechCrunch last week.
Was struck by the phraseology 'beyond the browser' and that we're quickly moving " beyond web sites limited by browsers… to interactive, connected applications with incredible simplicity, speed, and fluidity.... that will transform everything."
Couldn't agree more, especially when we consider the next 5-10 billion devices sold (via Mary Meeker's amazing Web 2.0 deck below, slide 32) will not be PCs with browsers but connected devices - from the iPad to your Xbox or Tivo that don't use browsers but instead connect to content providers with APIs.
We are moving beyond the browser to the "API web", where much of your company’s web traffic will come from a non-browser source. Enabling the API web is our mission.
And the Wall Street Journal's Martin Peers asks if the iPad’s e-book store is the new model for the television industry, citing how Netflix is streaming to over 50 different devices to build new audience. Blockbuster is pursuing a similar strategy to deliver it’s movies to “nearly every connected device.”
So the rush is on… just like a decade ago when companies scrambled for a ‘www’ address, companies today are rushing to create APIs - making their data and services available to execute a multi-channel, multi-device strategy.
Next: what are some considerations for your API in supporting an ever-expanding number of devices?
Mobile application patterns are different from web application patterns. There are a consistent, discrete set of differences in how they access cloud services. There are consistent reasons why they’re favored over websites as well, primarily based on implicit intent and purposive computing experience, but that’s a subject for a future blog entry.
For now, let’s assume that like web applications, mobile applications use HTTP to access their services, but unlike old-school web applications, they use REST and SOAP as the basis of their service protocols.
Difference 1: Bandwidth is expensive
Bandwidth always costs two unique things in mobile applications – time and battery. Jeffrey Sharkey has a great talk about battery usage and good citizenship. In some areas and for some users, bandwidth also hits their data plan, which makes bandwidth cost real money as well
Difference 2: Bandwidth is inconsistent
Disconnections are part of everyday life when using the mobile internet to access websites or cloud services. When your local cell area becomes overloaded with requests or your service loses track of where you are between towers, when you are in even a momentary cell shadow, your connection is gone. If this is in the middle of a data connection, that connection is reset and has to start over.
Difference 3: Local processing matters
First, non-trivial requests for data from cloud services often results in large datasets being returned to the device. These chunks can not only be hard to process, but may be more information than the user will bother to access. A request that returns hundreds of row-equivalents worth of responses may be mostly wasted processing if the user is only going to glance at the first few displayed screens’ worth.
Second, local applications have differentiated access to devices – awareness of onboard camera, location, or other services. They also have differentiated preferences about data. For example, the iPhone operating system is fluent in XML processing, and many iPhone applications transmit XML dialects to their cloud services. However, XML is more expensive to the iPhone than PLISTs (a JSON-like simple data format) – roughly 4-5 times more expensive in compute cycles. Other mobile devices have their own variations based on operating system version and device services.
Difference 4: Welcome to the hit-driven app economy
Media has been a hit-driven economy for decades, with winners and losers being made and broken overnight based on the wisdom or madness of crowds. With the fantastic potential of mobile applications and the inconsistent actual experiences, collaborative filtering and editorial selection are producing a hit-driven “Top 25” economy for mobile applications – the equivalent of being “above the fold” in a website. It’s a steady climb to get in this elite area, but once your application gets to this point you might as well have been written up by Walt Mossberg or Slashdot – traffic, downloads, and usage of the cloud services backing your app will all surge dramatically.
Difference 5: Concurrent usage by millions of nomadic users
Just combining Difference 2 (inconsistent bandwidth) with the fact that most mobile connections use HTTP 1.0 means that many more connections are being made, dropped and suffer an expensive reset not just of application state but of the HTTP connection itself. Adding Difference 4 (the hit-driven app economy) to this means that concurrency – including “shadow concurrency”, the load of the dropped and restarted connections – has an even bigger role in mobile applications than traditional web computing.
Solving for mobile application patterns in cloud computing
There are probably ways to solve each of these problems individually. What we’ve seen with some of our key customers is that all of these can be solved by applying a cloud service controller to manage the connections between mobile applications and their cloud services.
With a cloud service controller in the middle of the application and cloud service interactions, they’ve done the following things:
Compressed service request and response data by 6-10x
Accelerated service response time 5-7x through intelligent caching
Carved large service responses into chunks likely to be used by the mobile user
Translated service responses into formats easily processed by the mobile device
Reduced total network airtime usage by 15-20x
Reduced battery drain on the mobile device
Reduced dropped connection experiences for the mobile application
Scaled caching and response capacity dynamically to match growth and spikes in usage
In one example, a customer took the network request/response time from 17 seconds to 1 second, and took local processing on the mobile device from 17 seconds to one second. This reduced total application response time from 34 seconds to 2 seconds – an acceptable, even exciting level of responsiveness for that application’s users. This was all achieved in a few weeks without rewriting either the mobile application or the cloud service upon which the application depended.
They did this by taking our core product (ServiceNet), writing policies that let it route, cache, accelerate, paginate, and format their cloud services. Since ServiceNet is available as an .ami (Amazon EC2’s virtual machine format) we've deployed it as a cloud service that expands and contracts its use of computing resources to match the load. This way they haven’t been caught unprepared when their app made the top 25 list on the iPhone App Store and their legions of new users had the same responsive application experience as the users who popularized it in the first place. Finally, future devices and application platforms will be easier to support from a single cloud service through construction of new formatting or pagination policies that match the needs of those device platforms.
Mobile acceleration may seem like a standalone thing for Sonoa, but really it’s an example of using policy to solve an application pattern challenge. More on that – and policy-oriented programming – in a future blog entry. There are many more domains of use for this approach in cloud computing.
Here's a video we posted today describing our Mobile App Acceleration service.
Mary Meeker’s Web 2.0 presentation made a strong case for the imminent boom on the mobile internet. Some statistics that caught my attention: · Mobile internet users will exceed 500M human beings in early 2010 · The mobile consumer device market will exceed 10B in the next 5 years · The current iPhone + iTouch user base is larger than Netscape’s base in 1999 · More than 20% of the world will be on 3G networks by the close of 2010
This is a serious change in how people are using the Internet. I don’t think of the Internet as synonymous with the Web; the Web is one pattern of applications, based on HTML and HTTP, that uses a common infrastructure – the Internet. Both the iPhone and Android phones have a much higher share of Web and Internet usage than previous generations of mobile devices. But are they really using the internet? Or are they using the Cloud?
From my point of view, the Cloud is another pattern of applications – like the Web – that use a common infrastructure – the internet. But just as Web application patterns are different from other Internet applications (like email, for example), Cloud application patterns have their own rich array of styles and requirements. And what we’re seeing with mobile consumer devices is an explosion of applications that reside on the device and use the Cloud for access to remote logic and data.
(I promise not to capitalize web, internet, or cloud from here on out.)
So the future of the mobile internet is not the mobile web – resized, limited web pages rendered by a WAP server and discovered via Google and Bing – but the cloud. What we’re seeing are the first generation of sites rebuilding their backends to be accessible via cloud APIs in order to give access to mobile applications that will drive business. Some sites are on their second and third generation, having rebuilt their web presence to rely on the same cloud APIs that their mobile applications do.
Apigee is a website that provides analytics, protection and control for APIs. If you offer an API you can use Apigee to understand usage, protect your app, and enforce API terms of use. If you are a developer using APIs in a mashup, mobile or social app, you can use Apigee to get visibility into the actual service levels of the APIs you consume.
Apigee is freemium and self-service. You can start using it in minutes and Apigee's Basic service is free for under 10,000 requests per hour. Apigee is built on the same Sonoa ServiceNet technology that our enterprise customers use for industrial-strength API management. You can think of it as a freemium, simplified subset of policy framework available in Sonoa technology.
Beginning today we are offering Apigee in a private, invitation-only preview. Anybody can sign up for an invitation here. More details are on the Apigee blog.
- a website that offers freemium, self-service API Management from Sonoa Systems
Mobile application patterns are different from web application patterns. There are a consistent, discrete set of differences in how they access cloud services. There are consistent reasons why they’re favored over websites as well, primarily based on implicit intent and purposive computing experience, but that’s a subject for a future blog entry. 
Today we are delighted to announce