October 08, 2013

The Wait for iOS7 Wasn’t Long Enough

September 18 was a much anticipated day for iPhone users.  Personally speaking, ever since I switched from an Android phone to the iPhone a few months back I’ve been missing certain features, such as a quicker way to toggle Bluetooth, Wi-Fi, etc (something that was promised in iOS7 ).  That’s why on September 18, around 2:00 PM Eastern time, I was eager and checking for the upgrade.   In fact if I can swing it, I may blog my running list of iPhone / Android advantages / disadvantages.   Different topic.

For many of the users who were ready and waiting the second it was released, the new OS download came with an unexpectedly long download time.  Thinking about it, my change in experience coming from Android made sense – with Android (for better or for worse) the OS updates are pretty sprawled across users based on what device they have and from which carrier.  With Apple, everyone suddenly has their first access within a very small window.  I started to think of how Apple might make this speedier for users in the future.  Or maybe the corporate network I was on had a policy to limit this traffic?  Realizing this was in the ‘first world problems’ category I carried on.

However for many corporate IT teams, there was another observation – a giant spike in network traffic.  Was it critical to the business that I get my iOS7 upgrade in that instant on September 18 instead of later the evening, or the next day, or even to get it at all?  I was pretty curious to check it out, but no, I suppose not.  And yet, we know I was not alone.  iPhone users across the world – yes many of which were using the corporate network, whatever the BYOD policy – were attempting to download iOS7.  What did that mean for the network?  Surely there was a traffic spike, but did that affect other applications?  How much of that spike actually consisted of iOS7 download traffic versus other critical applications that were running in parallel?  Did issues occur in parallel for other reasons, but then iOS7 used as a scapegoat, mistakenly blamed?  A solid QoS implementation handles spikes, doesn’t it?  Yes, but typically at Layers 3-4, not at the application layer, though this is slowly changing.

Then there’s the how – rather, how easy it is for the administrator to understand all this.  With the advent of Web 2.0 applications, the evolution of Graphical User Interfaces or GUIs has spiked, bringing a new level of engagement to users.  The presentation of content and user navigation has become simpler and simpler over time, and thus more effective – not only to users see what they want to see faster, but they understand what they’re looking at.  They’re absorbing it.  Many in the networking industry however have been slow to leverage this uptrend.  This is bad for the current network functions, but will be even worse as networks become more application centric, and thus need to present more data about traffic, and allow users ways to control it more elegantly.

As a new iPhone user, I waited longer than I expected for my new operating system.  I do though think that many enterprise users could have waited just a bit longer for the good of ensuring the delivery of traffic for the rest of the company.  If only there was a way to improve the way the network teams (not to mention server and security teams) can understand application activity on the network.  The purpose of the network is to deliver applications to users – it’s archaic to think that it can’t do so in an intelligent and application granular way.

On a separate but related note, Enterasys will be giving a webinar on how to leverage the rich set of enterprise features that came with iOS7 that are often overlooked – something my colleague Ali Kafel has also blogged about.  You can register here.

You can also follow me on Twitter: @JonathanMorin

About The Contributor:
Extreme Marketing Team

See My Other Posts