For me, as a developer, the big differentiator between a Load Balancer and an Application Delivery Controller (ADC) is the ability to use code to help manage how my application and the network interact. Some things you just can’t do from your application because by the time your application knows it should be doing something, it’s too late, some things are just easier done on a network device (yeah, or a VM pretending to be a network device if your name is Izzy ;-)).

Note that by far my experience is with F5 products, it’s my job to know what they’re capable of in the development space (I do write for F5’s DevCentral after all), but this series does its best to be vendor-neutral. So the compromise is that you’ll have to call your ADC vendor if you’re not an F5 customer and ask them how you can achieve the same thing with their gear, and I’ll do my best not to talk about all of the cool things that I think make F5 products better. Deal? Cool enough, let’s hit it.

Remember from previous posts that an ADC is designed to route, optimize, and secure traffic to your servers. But that 50,000 foot description fails to offer any information at all about what’s possible with an ADC, so we’ll start there. Today we’re going to review the different ways that ADCs can be interfaced with – which really isn’t many – and next time we’ll look at some sensible use cases. That’s probably what many of you are after, the use cases, but seriously knowing how things are done will help you truly understand the power of the use cases.

There are, in essence, three ways to programmatically interface with an ADC. They are through an API, utilizing on-box rules about routing and data handling (this is a huge space, read on), and the command line, which is utilized in a couple of ways. In all, the combination and permutations of the three make for a highly adaptable device, but highly adaptable can mean highly complex, hence the point of this series.

Most ADCs have an API of some sort that can be utilized to change the way the ADC interacts with the network, your application, and the data. This is great for dynamic infrastructures, as the API generally interfaces for configuration issues. Indeed, for some ADCs (though not the BIG-IP) the API is actually a thin wrapper that itself calls the command-line on the ADC itself, making the API a remote command line as much as a programmatic interface. But if that suits your needs, it’s certainly familiar to anyone that has manipulated the box from the command line. Other APIs are more granular, with the iControl interface for BIG-IP probably the most granular out there (note I said probably, I don’t play with each new release of competitors’ products, that’s a different team here at F5). Utilizing the API on a granular box, you can do things as subtle as turn on and off compression for a given protocol on a given application based upon load. Not that you’d necessarily want to do that, just showing how detailed it gets. Of course more granular means more steps to do anything, so vendors with more granular interfaces need to provide you with some way to ameliorate that pain. For example, F5 has several tools, samples, and libraries to help you put the APIs to actual use. No doubt your vendor does too, since an API without solutions is pretty lame.

Most ADCs also have a rule or profile engine of some kind that allows you to direct traffic in real time, acting on connections and/or streams to route and interact with the actual traffic. This can seem to be a bit of voodoo to developers, but if you focus on how to make use of it, the concept offers you ways to get the most out of your code. Consider this, we have a credit card scrubber that keeps CC info from leaving the network – it’s in the Wiki (there’s a lot out there, the one I’m referencing is named CreditCardScrubber) if you’re interested.  100% iRules code that just makes sure you’re not shipping CC info back from web apps that run through the BIG-IP. One place to maintain, all your webapps benefit. No copying of code or assemblies or anything, just implement and benefit. And the coolest thing? Lots of those samples are user-generated. Big win for you, they’re out there doing what you do every day, so they “get it”.

Policies and profiles allow you to group like functionality together. These are generally a mix of coding and networking bits, so you have to paw through them, but honestly, some products allow you to say “use this profile” and speed up app delivery without any other work. I’m a fan of code optimization, but if you can get better performance by a couple of mouse clicks? Sheesh, I’m also a fan of spending your time where the real pain points are… Click the profile, then go optimize your queries, double the optimizations in the same time-frame and hitting the two critical parts of the infrastructure – query return times and network bandwidth.

I could honestly go on forever, but I’m already eyeballing the length of this blog post and thinking better of it. So I’ll save some for next time. In fact, I’ve taken enough space here that shell coding will get a separate blog entry. Great for highlighting tmsh, and great for other vendors who rely on shell coding.

Until then,

Don.