Ken Salchow

iPhone 3Gs: Multitasking is as Multitasking does . . .

Ken (KJ) Salchow, Jr. — Mon, 15 Jun 2009 18:44:58 GMT

As many of you might know, I am a big fan of the iPhone. As a long time proponent of unified application access and delivery, dynamic infrastructure and the idea of context-based networking, the iPhone has given me a rich set of use cases for why we need to change the way we deploy our applications. I am often referring to the iPhone’s dynamic roaming from Edge/3G to Wi-Fi as a prime example of the need for application delivery infrastructure to understand the full context of a users application session in order to provide optimal delivery at all times to all users. In addition, the need for this dynamic and intelligent system is exacerbated by the fact that the iPhone was the first significantly advanced smart mobile device that appealed to and was usable by non-technical people; meaning that we could no longer rely on the users of these sophisticated devices to manage their own application performance issues. No offense intended to any of the other devices before or since the introduction of the iPhone, but I think it will stand as the mobile device to break the camel’s back. It’s release signaled the beginning of the truly mobile workforce, customers and partners.

That being said—this is not a blog about the iPhone’s impact on the future of unified application delivery network. It’s about the iPhone itself and the recent release of the iPhone 3Gs; or more to the point some of the web chatter concerning the new features and how they compare to other devices. Specifically, let’s talk about the lack of multi-tasking on the iPhone; or more the inability of third-party apps to run in the background. For example, here is one comment on engadget

Matt @ Jun 8th 2009 3:44PM

Guess I'm going with the Palm Pre then. Same old iPhone GUI is boring me. Only one app open at a time feels outdated and confusing on such as powerful phone. Palm will release an update soon to fix the hiccups and the app store will follow in a month [emphasis mine]

As a previous user of another common mobile platform that multitasks applications, I for one am glad that the iPhone doesn’t; do you know why? Because, never have I hit the ‘answer’ button on my iPhone and had it either crash or simply be too busy servicing other applications to answer the call. I’ve already espoused my love of the iPhone for pushing application boundaries, but in the end, it is a phone. A phone should, at it’s very least, be able to make and receive phone calls. The iPhone is the ONLY device of its class that I have NOT had problems simply answering the phone when someone calls.

What is and isn’t multitasking?

Let’s look at this closer. We all know that a single processor only runs one application at a time. Multi-Tasking is a trick that allows us to share processor time across multiple applications to make them look like they are running at the same time. In order to make this happen, the processor saves the state of the currently running applications, loads the next application, processes something then saves its state and goes on to the next. The iPhone application handling isn’t much different with two exceptions: the reliance on the developer to save state; and background servicing.

The first one, is that, unlike multi-tasking operating systems that dynamically save application state while servicing other applications—the iPhone OS doesn’t. If you quit one app (by pressing the home button) to use another one, the first app simply stops. This however, can be easily rectified—and in fact is by most developers. Since the OS isn’t doing it, the application developer must write their application to maintain its own state information so that when a user exists the application and later returns, their previous state can be restored. This provides the exact ‘switching between multiple applications’ that multi-tasking does—but puts the onus on the developer.

Now, I know what everyone is saying—sure, but multi-tasking systems use things like schedulers and pre-emptive interrupt processing to allow those back-end applications to maintain functionality; the iPhone doesn’t do that (at least for third-party application). You’re right—but this is exactly what causes applications to freeze and operating systems to respond slowly; because the application you WANT to run is still sharing processors with the others that you ‘don’t want right now’. If you think about it, with the iPhone YOU are the pre-emptive interrupt every time you press the home button you are telling the processor that it is time to work on some other application. Until you tell the iPhone to do this, the entire system (most of it anyway) is focused on doing the task at hand without interruptions. Because Apple has significantly restricted what processes can run in the background, they have complete control to make sure that when you are playing that video game—some other process doesn’t cause you to get sniped because of delay. When you are running an app—it has the full attention of you AND your iPhone.

The biggest complaint with the lack of background processing—time slicing the processor to allow other tasks to be serviced—has to do with Instant Messaging applications and other social media messaging systems. Because they cannot be serviced in the background, they have limited use on the iPhone unless you do nothing but run that application. If you leave it, you get logged out of the systems and no longer get updates/messages/notifications. This should be finally solved with push notification capability in the v3.0 release of the iPhone operating system. In essence, Apple is finally providing a universal notifications bus that can run in the background and interact with all of these applications to provide updates without having to have the application running constantly on the iPhone. So, even if I’m not currently running my Twitter application, the twitter system could push a notification to tell me that there are new tweets/messages/updates that I haven’t seen—which is all most people were looking for. Granted, this will require some component changes on the server side or the use of desktop redirection (full-client changes), but it can easily be done.

As long as developers build their iPhone applications to maintain their state when they exit and push notifications are implemented to enable some kind of background ‘status update’, many of the issues people are concerned with will be solved. It is just solved in a new and unique way with the application essentially running in the background—somewhere else. OMG—maybe in . . . the cloud?

The Real Issue

This real issue here is not much different from the reasons some people (like me) loved the Palm Pilot and others didn’t. I liked the Pilot because it did what it said it would and it did it extremely well. No, it didn’t run a mobile version of Word—but did anyone every really create decent documents on a palm device (or a smart phone)? People seem to want a smart phone to do everything their desktop does and in the exact same way except that it should also be a phone, SMS, and MMS device with universal connectivity—not to mention a full-fledged iPod with music, full-length HD quality movies, a camera, video recorder and everything else. Oh, and the battery needs to run forever on a single charge.

Even if the storage, memory and processor capacity of these devices makes many of my old home desktops look like Pong, doesn’t mean that we have to keep doing things the same way and keep throwing compute resources at the problem. Maybe, just maybe, having mobile devices with lightweight components that simply interact with more robust server-side application is the way things should be. Maybe not being able to launch 37 application simultaneously on your mobile device isn’t a limitation, but a reasonable concern. I do realize there are other use cases for background processing, but maybe, just maybe, if your app is that important and needs that much attention, it deserves its own standalone device or the user should run it and keep it in the foreground (know you can ALWAYS still get your music).

Assuming push notifications work as expected, I'm perfectly happy with the state of multi-tasking on the iPhone and really think that anyone who is hung up on it is missing the point. Assuming I get my MMS and tethering, I’ll be even happier as then, if I really need to have the big guns to do something (like write a word document to post) I can fire-up the MacBook and do that too.

Hey, wait! That would be a good reason for a dynamic infrastructure that adapts to changes in a user’s context, wouldn’t it?

Shame on GSLB? Shame on Me?

Ken (KJ) Salchow, Jr. — Wed, 03 Jun 2009 21:59:55 GMT

Recently, on the venerable Vegan Load-Balancing List of which I’ve been a member of over a decade now, the question about the viability of Global Server Load Balancing and DNS-based GSLB Solutions like F5’s own Global Traffic Manager (GTM) was questioned. As has want to happen, for over the past half-decade, Pete Tenereillo’s infamous GSLB Page of SHAME was summoned as a reason why no one would want to spend money on a GSLB solution as it, supposedly, offers no value over simple networking tricks—or just using plain old DNS. In my usual fashion, I responded. Maybe I was a bit hasty, maybe I was a little less than clear. In any event, it appears that I need to clarify my position about this particular article from a much less emotional place. So, here it goes:

First off, a more detailed explanation of my comments. My first suggestion was that Pete’s paper is over 5 years old. Think about that. How many other things in technology are that old and are still the same? In fact, someone responded with “everything in Pete’s article is 100% true”. Well, when it was written, sure. But, even Pete acknowledged shortly thereafter that some things were already changing in regards to Windows XP and how it treated DNS caches and lookups. A lot of things have happened in the last 5 years including the fact that most modern browsers and OSs accept low and even zero TTL values. Many of the mega-proxy servers are no longer and the ones that remain are much more sensitive to DNS cache values than ever before. 5 years is a lifetime in technology—let’s be a little more realistic.

The second suggestion I made was that the paper’s premise had been ripped to shreds thousands of times since its last update in 2004 on numerous sites, including the Vegan LB List. You can check the archives—very few people argued that Pete had his technical details wrong—but questioned his premise—that they held no value, certainly not what people were charging for them. His entire argument was based on providing real-time HA between multiple datacenters flipping users back at forth at will; and his only criteria for success was 100% at all times. I know of very few people who have the back-end synchronization capabilities to make this viable even if you could guarantee every single client would be instantaneously moved. This was one use case of the technology and not the most prevalent one at that. Probably the MOST prevalent use case was in Business Continuity and Disaster Recovery. By using a GSLB solution, a complete loss of the primary datacenter could be acted upon—automatically—in seconds if necessary. In this scenario—maintaining state and/or dynamically routing people mid-session to the backup site was not the requirement as that state didn’t exist. The main requirement—that people could access the application again—even if they had to close their browser or reboot their system. Not only that, but GSLB solutions allowed us to do that on an application by application basis—something BGP route injection has no clue about, nor does generic DNS. I’ve personally seen hundreds of customers that use the intelligence of GSLB to provide immense value to their solution from maintenance to contextual routing to simple traffic overflow scenarios using cloud bursting. If these solutions really had NO value outside the lab and were simply the marketing sham Pete intimates, they wouldn’t still be selling a decade after their introduction—I think the world would have learned by now.

The last comment I made was that I have difficulty listening/reading someone detail how a solution WON’T work without suggesting a solution that does, or at least provides more value than the one being discussed. I have no problem with someone pointing out the shortcomings of solutions or the inability of a solution to address certain aspects of the problem. I do have a problem if you do that without offering any viable alternatives. The conclusion of the paper was basically, GSLB can’t solve this use case perfectly and therefore is no better than using normal DNS thus—you can’t do what GSLB intended to do. I’m sorry, but that’s not a solution; that’s not very helpful. It also dismisses all the things it CAN do much easier and more automatically than standard DNS. I just don’t think that was appropriate.

Don’t get me wrong

I don’t want anyone to think that I’m personally attacking Pete. His paper, at the time, really generated a lot of attention and many, many conversations. I would even go so far as to suggest that his paper helped raise the visibility of the issues which led to many of the changes that make the solution many times better than it was for that use case. For that, I applaud Pete; I really do. His well written document provided a road map to manufacturers, vendors, service providers and enterprise about the things they did that limited the success of these solutions and what they could do to make them work better. He was certainly a shining and outspoken leader in our field and I’m thrilled I had the pleasure of chatting with him numerous times over the years.

What this is REALLY about, is the need to be a little more discerning when taking information and resources off the Internet. Sure, Pete’s document contains a wealth of information, but maybe it shouldn’t be the end-all, be-all of the research effort based on the date which is plainly posted. As I said, even a quick search of the vegan-lb list showed that within a year, some of the issues were being mitigated.

So, Shame on GSLB? I don’t think so. It has been providing value for years and because of people like Pete Tenereillo and their courage to make a stand—the solution has only gotten better and better over time.

Shame on ME? Yeah—probably. I should have devoted the effort right up front and I didn’t. So, Pete—no hard feelings—right? I sure hope someone references something I wrote in 5 years. It wasn’t you, or even your document that riled me—it was the way it appeared to be being used.

NetBooks, eBooks and Cars, Oh My!

Ken (KJ) Salchow, Jr. — Fri, 20 Feb 2009 19:11:24 GMT

In the last week or so, there have been a lot of ‘client’ announcements: from Asus’s new Eee PCs, Amazon’s new Kindle to this pronouncement that our cars are one step closer to being network nodes. Interestingly, the Eee PC’s and Kindle both incorporate integrated 3G services in addition to or instead of simple WiFi. Add to that the myriad of new mobile devices spurred by the iPhone (Android phones, new Blackberry phones, etc.) and it’s increasingly clear that what was once a unifying technology (i.e. the world wide web) is now becoming increasingly splintered as the number of devices—and their myriad capabilities and unique functions—is making it harder and harder to provide the rich user experience with a single batch of uniform content. Originally, one of the great things about HTML was that we could all share the same information, the same experience, regardless of our personal choice of computer or OS; now, we are actively trying to make the content dynamically morph to fit the numerous clients and connectivity, providing unique experiences instead of the same one.

A great example would be my online banking experience. I was thrilled when my bank started offering online banking (as I’m sure many of us were), but was even more thrilled when they enabled their ‘mobile’ version of online banking. My daughter was even more thrilled—as it was that much easier for me to transfer money into her account when she came up a little short. Imagine my thrill, however, when I logged into my mobile banking application the other day and noticed that they now had an iPhone specific online banking application that looked and acted much like a local app instead of a web-based one. NFL.com also has a similar iPhone specific experience that makes it very easy for me to navigate game day statistics of other games whilst watching my MN Vikings. So, I get nearly the same functionality, but a more device personalized version depending on how I access the application OR if you us the same bank or nfl.com, but don’t use an iPhone, you get the same functionality I do—but personalized to the device *you* are using.

There’s been a lot of talk about the death of “load balancers”, but this is just one more example of—maybe not how load-balancers have evolved to become application delivery controllers, but just maybe, how load balancer have almost ALWAYS been more than just load balancers; maybe they were application delivery controllers all along but we are just finally getting to the point where we actually need them to be. This notion of ‘application switching’ isn’t all that complicated, nor is it all that new. The mechanism used to determine what device I’m using (HTTP User Agent) is almost identical to the mechanism (HTTP Accept Language) that we used many years ago for auto-determining a users preferred language and redirecting them to the appropriate site. For example, in Canada, I once did an install where we used the HTTP Accept Language to automatically deliver users to either a French or English website based solely on the users preference. This allowed the client to properly offer both French and English versions but automatically selecting the correct site that the individual wanted. Two users, same site, different preferences—each server exactly what the content they wanted without any knowledge about what was going on to make it happen. Just like using the User Agent to deliver an iPhone experience when I use my phone and a desktop experience when I use my browser.

Isn’t that what application delivery is all about? The user just wants an application—heck, they may not even realize that you automatically formatted the content to make it more usable on their device du jour, or that they are getting Spanish content instead of English without even doing anything. It’s rarely been about ‘load’ distribution, but more about uptime, availability, performance (why would you want more than one application server if not for improved performance); for at least a decade it’s been about server offload of SSL, compression, rate-shaping AND dynamic, intelligent application switching to deliver the right application, for the right device, to the right user.

Maybe load-balancers aren’t dead—they were just a figment of our imagination; and now it’s time we woke up. The web might be getting easier for the users—but it’s getting more complicated for those of us who have to build the ecosystem that holds the clouds.