... but your 'network' can - and should. #webperf #mobile #IoT
Pop quiz: Your development team is developing a new mobile application. Should they optimize it for use over a mobile network or over WiFi?
Another way to ask that same question is, "Should they provide a great quality of experience for users over a mobile network or over WiFi?
And yet another way to ask that same question is, "Should I improve productivity for some of my users, but decrease productivity for others?"
This is one of those situations in which you find yourself that you simply can't win. No choice is optimal because no matter what you choose, someone is losing - and perhaps losing big. And no matter what choice you make, the business loses - whether in terms of the time and money associated with productivity or in sales associated with customers.
The reality is that Honey App Don't Care. And that's the way it should be. The application developer shouldn't be concerned about such things as TCP congestion or how FEC (Forward Error Correction) might impact the performance of their application. The developer shouldn't have to worry about that, because it's all network-related, and therefore relative to individual users at varying times.
The application, anyway, can't really do much to influence performance when the problem is deep inside the network stack, anyway. It can't reach down into the TCP stack and tune it for the network its currently connecting over - even if it could determine whether it's using WiFi or mobile networks.
The app don't are, and so someone has to because while the app doesn't care, the user does - about performance. According to a Compuware report, "Mobile Apps: What Consumers Really Need and Want": "Users expect mobile apps to launch not just quickly, but faster than mobile versions of websites. 78 percent expect mobile apps to load as fast as — or faster than — a mobile website."
Note that within that expectation there's no "over a WiFi connection" or "on a mobile network." They just expect a mobile app to load at least as well as, if not better, the mobile website. And mobile app performance, in general, is "somewhat or very important" to 84 percent of users.
Compuware, "Mobile Apps: What Consumers Really Need and Want"
Suffice to say that advice to remedy potentially poor performance and head off angry reviews and abandonment generally revolve around "optimize your app for the mobile device a user is using."
As we head into the Age of Things, this issue will become more problematic. Many "things" today already have options for connectivity based on where they may be at any given moment. WiFi or mobile network, tethered or roaming; the options are growing. And each thing that makes its way into the home is going to present those range of options. You can't assume my television is wired (one is, the other isn't) or that my wearable is using Bluetooth to a PAN to a mobile network or a WiFi connection. The application to which a "thing" is connecting and communicating can't make that assumptions because, well, you know what they say about "assume" ...
Additionally, a good deal (quite a lot, actually) of performance has nothing to do with the device and everything to do with the network over which the app is being delivered. Of the four factors impacting mobile performance, two (that's half) are related to the network and a third is tangentially related in that applications (as we just pointed out) can't impact the factors in the network.
You know who can impact the network? Yeah, services on the network in the data path. Services with the visibility and resources to be able to identify the type of network and application, and have both the resources and capability to do something about it. To be able to tweak TCP to optimize the connection for not only the device but the network over which its connecti....
One of the promises is SDN is the ability to adjust, in real-time, the way the network (that's inclusive, by the way, and means L2-7) handles traffic from end-to-end. That's something that requires services to be in the right location (in the data path) and have the right level of visibility (device, network and application) in addition to actually being able to change, on the fly, the way the network responds.
That's actually a pretty big ask, if you think about it. TCP stacks, for example, are generally tuned (algorithms enabled or disabled, congestion control algorithms used or not used, etc...) before the service is launched, based on an "application profile". The increasing mobility of consumers and employees is forcing the network to become more agile and that means, in part, able to tune itself in real-time.
Honey app can't differentiate between a WiFi or mobile network, and it shouldn't have to because tuning for one necessarily means ignoring the other. The network, which acts as a conduit for both and has the visibility required, is the best place to do that.