iCall, Dynamic Rate Limits, and You

This iCall thing is pretty darn powerful. If you haven't heard about it yet, you should really go check it out. Fortunately, on DevCentral, there is a plethora of info to get you started. Might I recommend:

iCall Introduction
iCall Q &A
iCall CodeShare

So now that you've got the basics of what iCall is (for those non link followers, think programmability for the configuration layer), let's talk a little bit about why it's awesome. It is, in fact, awesome, in case you somehow weren't entirely convinced already. Don't just take my word for it, though. Jessica Scarpati over at at techtarget.com talked to our own Alan Murphy a bit after we were announced as the winner of their monthly "Network Innovation Award". What did she want to talk about? Well, iCall, of course. That is after all the reason we won.

As the article discusses, iCall is one of the things that allows us to have such a detailed and complete programmability story. This means that we can offer an infrastructure that is entirely flexible and programmable by the device owner, administrator, or interested DevOps or AppDev teams. This allows us to, as Alan says, "manage and adjust and deliver applications throughout the entire lifecycle.". Well said, Alan, and quite true. iCall is absolutely a part of the programmability story that allows for finite control, management, automation and tuning of your applications. Whether it is data to and from an app being modified in real time, automation of configuration deployment or modifications, real-time security threat assessment and prevention or a myriad of other things, we have the programmability tools to help out. iCall, along with iRules, iControl, iControl REST, BIG-IQ, tmsh and, well, you get the picture; we take programmability pretty seriously around these parts.

iCall being a relative newbie to that distinguished bunch has had a fair amount of proving itself to do, and done it it has. If winning awards isn't enough to turn your head and make you curious about what iCall can do for you, then perhaps you should take a look at a recent customer's success, largely thanks to iCall and their F5 solutions. While it's not my place to name names, I can say that a rather large E-Commerce site was looking for a way to mitigate the risk of their site being taken offline during heavy traffic use. This is a pretty common problem, actually, in the e-commerce world. You offer some super bargain or sale in an attempt to draw in more customers and the only thing worse than it not working is it working too well. In these cases companies can easily find their applications slow to near unresponsive or even worse, offline entirely.

This scenario is only exacerbated in today's highly virtualized, shared environments. The likelihood of having more than one site operating off of a given set of shared hardware is extremely high, and if one site goes hogging all the resources and impacting server performance, it can have broad reaching effects, which isn't good for anyone, least of all the admins getting phone calls to help solve the problem. To help combat this, the customer was looking for a way to rate limit a given site's traffic in the event of a large influx due to a sale, an attack or otherwise.

The trick here is in the details. They didn't want to rate limit all the sites, all the time, as they wanted to retain limited bursting capabilities for each as necessary. And they didn't want to allow a single site to detrimentally imp act performance for even itself by being request flooded, let alone other sites that may be using shared resources. As a cherry on top, they didn't want to be forced to schedule rate limits along with sales, meaning they were hoping to avoid having to manually put in place a rate limit for Site A every time it has a sale going on, just to avoid impacting Site B. Not only is that a fair amount of manual labor, but what if it's not necessary?

So, the solution looked pretty obvious. Dynamically install a rate limit for the site in question if a traffic burst outside of acceptable limits is detected, to avoid negatively impacting server resources, and therefore performance. I said obvious, not easy, right? This means each site will need to be consistently monitored for current traffic and, should things pick up more than desired, a rate limit will need to be slapped into place automatically, only to be removed when traffic has died back down.

Does anyone else think that's starting to sound decidedly like business logic that is directly part of the application flow, affecting end users? I certainly do. Fortunately for this customer iCall was up to the task. Based on real-time CPU usage, a clever little iCall script was able to keep an eye on the sites in question, trigger on limits being surpassed, install rate limits as necessary to bring things back into line, and then remove them when they were no longer needed. All without touching the app code, dealing with multiple boxes, or causing servers to break a sweat.

Interested yet? If so, now is a great time to dig deeper, browse DevCentral, and see just what else iCall can do. And if you like that, there's a whole world of network enabled programmability offered by F5 just waiting to be leveraged to better applications everywhere.