It’s not often I take my competition to task, but when I do I always have a good time.
So the kids over at one of my larger competitors have added the concept of HTTP Call-Outs, something that has been a part of the NetScaler policy framework for years. Indeed, it is a powerful tool that can be used for a lot of interesting things. For example, one of our customers had a peculiar database layout that required them to load balance to a specific server for a specific user. Rather than using a hideously long policy map that would need to be constantly updated, they used a call-out to an API function that told them which server a user was on. The return value was used for content switching and the specific server could be load balanced to. If the server was unavailable for some reason, a “sorry server” would be used so that another server wouldn’t accidentally tell the user that their account was missing.
The key to making that work was the ease with which the team was able to piece the solution together. A quick example:
set policy httpCallOut getServerToUserMapping -vserver myApplication -httpMethod GET -urlStemExpr "/api/getServerToUserMapping" -returnType text -resultExpr "http.res.body(1000).length
I’m a bit of a CLI geek, so rest assured that there is an even an easier way with the GUI. Check out our Edocs section on call-outs for more information.
Now here is the cool part… anywhere you’re writing a policy, you can refer to this call-out to make it happen. Responses are cached so multiple calls in a single transaction don’t generate multiple calls to the server for data unless you explicitly ask for that behavior. This makes things much faster overall. Even neater is that you can tell NetScaler how to interpret this data — is it a number? Is it a true/false? Is it text? This is useful in the policy framework because let’s for example say that it is a number; you can now compare the number against other numbers the way that a human thinks about numbers. So an API response of “39” knows that is bigger than “009”.
Because the call-out mechanism takes care of the networking details for you, issues like the server needing to time out, or parsing the response and validating it, or even knowing much to expect on the response are completely abstracted away. You don’t need to be a programmer to use call-outs.
Now compare this to some other methods that our competition likes to boast about…
One approach we’ve recently seen is based on traditional Unix sockets programming. That’s great if you’re a traditional Unix sockets programmer, but for the sane folks that don’t keep Unix Network Programming Vol. 1 on their desks, learning how to create sockets, manage blocking vs. non-blocking connections, understand the nuance of parsing HTTP responses back from API calls, etc. is a huge hassle.
Take an example someone recently showed me:
set conn [connect -timeout 3000 -idle 30 -status conn_status vs_test] set conn_info [connect info -idle status -status $conn]
That just sets up a call-out. It doesn’t even issue an API call! And really, what the heck does it mean? With the NetScaler, there is a GUI that builds a call-out for you. With a programming approach, the system drops you into an editor and expects you to hammer this out.
A few lines later, the program gets even more entertaining…
set recv_data [recv -timeout 3000 -status recv__status 417 $conn]
Since I’m a little insane, I happen to have that Unix Network Programming book in my bookshelf (first edition no less). A little reading and I was able to figure it out… the system is going to wait for 417 bytes to be returned from the server before returning back. If less than 417 bytes come back, you‘re out of luck. If more than 417 bytes come back, you lose the rest of the response. Even better: if less than 417 bytes come back, you have to wait for the timeout to happen before the system will return control back to you.
Wouldn’t it be better if you could just say “tell me what comes back from an HTTP request” — you know, like the health checks we’ve used for ages and are already familiar with.
Parsing out an HTTP response is actually pretty complex. There are all kinds of exceptions. Like what happens when the response uses chunked vs. unchunked encoding (which can split the data you’re looking for), or the system kicks back a redirect that needs to be followed. These complexities make accessing API calls from a raw socket dreadfully complex and tedious. Most programmers stopped using raw sockets years ago and instead leverage higher level libraries to simplify the process. Why would someone come back with a “new” feature that leverages an approach someone dreamed up 30+ years ago?
Sorry, but this doesn’t sit well with me. I don’t ask my customers to learn how to program and from the countless I’ve spoken to over the years, they don’t want to be programmers. They have real jobs with real responsibilities. Being a programmer is usually not one of them. The idea that an IT manager has to learn how to cope with blocking vs. unblocking sockets, timeouts, partial reads, parsing raw HTTP responses, etc. is simply absurd.
I’ll leave you with a little lesson from history. The old Cisco CSS load balancer (aka, the ArrowPoint system) had a little used feature that let you use raw sockets to issue custom healthchecks. Much like the above description, you would open raw sockets and send binary strings over them. You then had to know the binary data to parse back. It was complete madness. I managed to take a lot of business away from Cisco when they would propose that as a solution because customers promptly pointed out that they weren’t programmers and didn’t have the know-how to manage a system like that. There was no simplifying it — sending and receiving binary strings was too much. The product eventually died in part because of its complexity.
Maybe my competition will take a page from that history book and pay attention.
Until then, if you aren’t interested in being a programmer but need a load balancer or application delivery controller, give my crew a call. They’ll show you how to get things done without becoming a programmer.
Want to know more? httpcallout is a simple document written by an engineer for a customer looking to distribute web traffic based on the client latitude using an API instead of GSLB. You can also see a great example in this blog about the technical details of the http call-out.
Image courtesy of stratic on flickr.