When we think of the application lifecycle, we tend to focus on apps that are built to last. CRM, mobile banking, streaming video, or m-commerce apps are usually built for users to access for weeks, months, or years at a time. If performance problems arise after the app has been deployed, the issues can be discovered and solved through proper monitoring and remediation.
But what if your mission-critical app is not designed to last? What if your app is perishable with a shelf life of only a few hours or days? With these apps, traditional monitoring and remediation become irrelevant. The app will expire before it can be fixed. But, that doesn't mean that perishable apps are fated to be poor performing and unsatisfying. Proper planning, testing, and additional resources can keep your perishable apps from going bad.
One of the most egregious and public perishable app failures happened this past Election Day. The Romney campaign's voter turnout app, codenamed Orca, was supposed to organize, energize, and empower volunteers. Months of development and millions in budget were dedicated to a mission-critical app that would “live” for less than 24 hours.
From all accounts, the app did not help the campaign's voter turnout efforts. It performed so poorly that Comcast, the ISP monitoring the app's servers, temporarily shut off service because it thought the repeated attempts of the campaign users to access data came from a denial-of-service attack.
While the purpose of your perishable app might not be for something as important as winning a presidential election, the blowback to your business could be proportional if it fails.
Think About Performance from the Beginning
What the Romney campaign should have done, and what you can do, is to think about performance as a critical requirement from the beginning. One way to do that is to engage in detailed location-specific planning. If you know your app will be used primarily for a five-day conference in Vegas, ensure that your network data for testing is specific to that exact location. Through network virtualization and in-the-field discovery, the exact network conditions for a specific exhibition hall, or even a specific room, can be used in your performance testing.
Remember, however, that even if your app performs well on an “off day” connection, the network will hold a different profile at the height of your event. Orca worked when only a few people taxed the network from the field or inside the Boston Garden. At peak network usage, Orca was overwhelmed.
You avoid this issue if you load and performance test for both typical and worst case scenarios. Say you have 15 thousand conference registrations. What happens when seven thousand more register at the door? You expect most users to connect over the venue's Wi-Fi, but what if that goes down and they have to connect on a 3G or 4G mobile network?
By virtualizing these variable load and network conditions in your pre-deployment performance testing, you can test to a variety of typical and worst-case scenarios, better understand the breaking points for your app, and plan accordingly.
Worst case planning extends beyond development and testing. We've all suffered the frustration of a flight delay that could have been tempered if information was provided as to the cause of the delay and/or how long the delay would last. That way, we know if we had time to grab a burger and beer or needed to book a hotel room for the night.
If your app does go down, have fallback scenarios in place. Romney campaign volunteers could have manually reported poll results with an automated phone system. For events, caching is a useful option for providing information, such as a map or schedule, when connectivity is compromised.
Make sure your app fails gracefully. Build in an automated email alert when your app hits a certain performance threshold. This way, your users are informed about the issue and know you are doing all you can do to fix the problem. A little bit of common sense and courtesy goes a long way to keep users happy and reduce blowback to your organization in the event of an app failure.
Since the app is only usable for a fixed amount of time, putting it in the cloud makes sense for easy upload and termination. Hosting it in the cloud also makes it easy and cost effective to call up new servers to address peak usage requirements. But, you need to know when you should call up a new server. This can be accomplished in testing to see if you can scale your app. If so, you can see where bottlenecks are likely to occur. That data can then be used to automate the spin-up of additional servers.
There is no reason why performance for perishable apps should be an afterthought. If you are developing an app, it is for a specific reason and your users will expect it to meet their performance needs. Anything less reflects negatively on your company's reputation and, perhaps, bottom line. Through proper planning, testing, and by having additional resources at the ready, you can ensure your perishable app provides users with a satisfying, rather than rotten, experience.
ABOUT Dave Berg
Dave Berg is the Vice President of Product Strategy at Shunra Software, a Philadelphia-based company specializing in network virtualization to help firms worldwide ensure application performance and end user experience.
