Programmability in the Network: Making up for lost time with user bribes

90% of your users want your site to perform well during peak periods, like the last month or so. That's according to a study by Compuware, in which they also found that most dissatisfied users will throw you under a bus if your app or site performs poorly while they're desperately trying to buy the right gift for their very demanding loved ones.

In an application world driven by impatient and very vocal users, performance is king. Every year before Christmas we hear at least one horror story of a site that didn't perform up to expectations and is promptly made an example by, well, everyone. I could probably fill this post with examples, but that's not really the point. The point is maybe there's a way to counteract that, in real time, thanks to the power of programmability in the network.

Most apps are adept at offering up discounts and promotions in real-time. These are generally powered by the application in question and based on a variety of user identifiable data. It would seem like the thing to do would be to apply those kinds of discounts - in real time - to users that may be experiencing poor performance at that moment. As incentive to see it through and remain engaged. As proof you care about the quality of their user experience.

The problem is that the app itself - the one instance in that giant cluster of instances - with which the user is interacting has no visibility into the overall performance being experienced by the user. It may know the database was a bit slower than normal, but it can't measure it's own response time because, well, that has to happen after it responds and by that time, it's too late to inject a coupon or discount into the stream.

What's needed is an external entity, something between the user and the app, that can identify in real-time that the app is taking longer than the typical holiday shopper will tolerate. Something, oh, I don't know, that maybe sits upstream and virtualizes the app in its role providing availability and security for the app and the user. Like an app proxy.

Only it's not enough to be just an app proxy, it has to be a programmable app proxy because it's going to have to do some fast talking to the services that offer up coupons and promotions so it can inject it into the response along with a "sorry we're a bit slow today, here's a little something for your patience."

The basic premise is that the proxy is (1) programmable and (2) has the ability to track response time against an expected result. So you might base a discount on a response time range, say if the app took 2 seconds to respond you're going to offer a 5% coupon. If the app took 2-4 seconds, 10%, and more than 4 seconds? 20%. Cause you're awesome like that.

The proxy, upon noting the response time, determines whether or not it should insert a promotional code. If so, it reaches out to the database in charge of tracking these things and notes that "Bob" got a "5% discount" for poor performance. Not only does this attempt to make up for a less than stellar user experience, but it also provides an accounting of how many times performance was an issue, at what times of the day, on what days and how much money was spent to keep the business of users that, based on most studies, were almost certainly going to bad mouth you and give their money to your competitors.

After the proxy does that thing it does, it inserts the appropriate code into the response and sends it on its way. A little customization here based on user name (if you've got that info) would be nice, by the way.

Given this basic pattern, you can probably start imagining all sorts of interesting ways to interact with (reward or compensate) users based on a variety of variables like performance. The key is that some of those variables just aren't available to the app itself - only an intermediary might have that data readily available.

The thing is that programmability in the network - particularly programmability based on something like node.js and its very robust set of packages - can be used to implement just about any kind of innovative service that enhances existing or offers new capabilities to the business.

While certainly some vendor could bake this capability into a proxy and let you just configure a few data fields and voila! Except it's never that easy. You might want to offer discounts based on a range of performance while someone else just has a hard line above and below on which they want to provide such an incentive. Someone else might want to offer free shipping, instead or who knows what? That's kind of the point behind programmability; it lets organizations design, deliver and tailor services based on their business objectives and priorities, and their particular situation. Programmability imbues the network with the capability to innovate new services that directly result in business value; that have a real impact on the bottom line.

The question is no longer what can the network do for you, but what can you do with the network.