The Appification of Everything

#gluecon #mobile #fastapp Mobile applications still rely on "the web" under the covers.

On my phone I have, like most people I suspect, many "apps". The thing is, many of these "apps" are simply web sites that have been redesigned to fit the navigation and form-factor of a mobile phone or tablet. Most of them communicate with the same APIs (or HTTP service) that serves up content to browsers. And it's not just banking or social networking. One of my favorite "apps" is little more than a well-designed, easy to navigate interface to my favorite online shopping destination. I'm equally happy to browser via the mobile application and the web site.

Too often when we put the terms "mobile" and "enterprise" together we immediate start focusing on security and mobile device management and we forget that for many organizations out there, applications are targeting not employees but consumers. The same consumers who visit their web site and for whom MDM and MAM and other enterprisey concepts are not a concern.

The focus for organizations serving up mobile applications to consumers is of course the same focus they have for delivering web content: availability, application/data security, and performance. Most mobile applications are native presentation layers but the data delivery methods are still based on good old HTTP. A REST API is, after all, an HTTP-addressed (URI) and HTTP-delivered method.

Thus mobile applications - both consumer and enterprise-focused - are subject to many of the same availability and performance concerns that have haunted more traditional (I can't believe I'm saying that) web applications for over a decade.

There are differences, however, particularly when considering that mobile applications may be talking to remote APIs via at least two different networks. Sometimes in the span of hours - or minutes. Mobile networks perform very differently than wireless networks, and have very different performance profiles. Yet consumers are the same, and delays in delivery are simply not acceptable. A "loading" indicator in a mobile application is no more desirable than a "loading" indicator in a web application. Performance still matters, whether the client is on a phone or a PC.

Lorinda Brandon, Director of Solutions Strategy at SmartBear Software, recently touched on this notion in a ProgrammableWeb article summarizing her time at Glue (emphasis mine):

In his talk about the “API-ification” of the web [I attended this session and enjoyed it very much, by the way], Steven Willmott brought up the increasing focus on APIs and the need for APIs that work. Period. As we leverage each other’s APIs in our own application development, we are not only accessing data and functionality external to our own environment; we are basically tying together distributed systems across multiple cloud platforms and databases.

Now, more than ever there is a need for an increased scrutiny of our quality standards and service level agreements.

Indeed, there is such a need and rolled up into that "service level agreements" concept is the notion of performance, and how acceptable performance is maintained when we have even less control over the client than we have had in the past with browsers. Web acceleration concepts such as client-side caching and domain sharding are unlikely to be effective or even feasible solutions when a native mobile application is the target. They are, for the most part, developed using different platforms, different SDKs, different frameworks. Most application acceleration solutions have no visibility into the finished product and there's not really an accepted standard for how HTTP is used to deliver the APIs through which data is exchanged with these applications.

The challenge, then, is to optimize and accelerate delivery on the server-side where control can still be exerted. Content transformation and caching strategies, intelligent use of load balancing algorithms and scale, and network-appropriate optimizations are all potential means of improving and making optimal the performance of APIs delivering data to mobile applications.

But before we can address that challenge we really have to recognize that "mobile applications" means more than just MDM and MAM and security policies. We need to recognize that these web-backed front-ends are still using the same delivery mechanisms as traditional web applications - and are therefore subject to many of the same issues, especially with respect to performance.