Today’s post is brought to you by the logical fallacy “Special Pleading”

thoughtful_thumb[1]_thumb_thumb_thumb_thumbGenerally speaking we don't respond to competitive commentary that's purposefully antagonistic. The reasons for that vary from corporate culture to the annoying reality that responding confers upon the claims some measure of veracity that it generally does not deserve.

But even technical agitprop can raise points that need to be addressed with respect to the underlying premises upon which the arguments are made. Of late, certain claims coming from Citrix has brought these premises to the fore, and those premises deserve to be addressed.

Issue: Policy Flexibility and Complexity

“Complexity and programming often lead to errors, and just one mistake can often lead to security vulnerabilities, performance issues and downtime.”  (Citrix)

We grant this premise. We agree with this premise. We happily embrace this premise. We’d like to further point out the use of the conjunction “and” between complexity and programming. 

Now, that said, NetScaler claims it “takes a far simpler approach with declarative policy expression.” This statement is contradictory, because the implementation of NetScaler’s policies requires programming, it’s merely of a different programmatic paradigm. 

quote-badgeIn computer science, declarative programming is a programming paradigm that expresses the logic of a computation without describing its control flow.[1] Many languages applying this style attempt to minimize or eliminate side effects by describing what the program should accomplish, rather than describing how to go about accomplishing it.[2] This is in contrast with imperative programming, which requires an explicitly provided algorithm.

-- Wikipedia, Declarative programming

An example commonly cited for a declarative paradigm is SQL and XSLT (and often HTML and XML, as well, though this is often disputed by purists), where individual statements describe what is wanted, but not how. Similarly, NetScaler policy expressions are line by line constructs (code) explaining what is wanted – add a redirect, bind a policy, etc… These policies are comprised of one or more lines of code (normally regex) that are evaluated during individually. If something matches one of these lines, that policy is matched and the action associated with the policy is taken. Because each line is evaluated individually, each line must contain all the information needed to correctly generate a match. Due to this, policies are more complex to implement and maintain.

COMPLEXITY, THY NAME is CODE

In both cases, there is code involved. Whether that “code” is imperative or declarative or functional is somewhat irrelevant, as all code is subject to the introduction of errors and complexity. Whenever typing is involved, there is a chance for errors – otherwise we wouldn’t use spell-checkers. The more code, the more change of an error being introduced. Consider that according to Steve McConnell in “Code Complete”, he notes a study at IBM that found “the most error-prone routines were those that were larger than 500 lines of code.” He also noted a study by Lind and Vairavan that “code needed to be changed least when routines averaged 100 to 150 lines of code.”

That makes sense, smaller is generally better. The big difference between NetScaler’s “declarative policy expressions” and iRules (in terms of complexity and error proneness) is in cyclomatic complexity. iRules contains more decisions and thus its path complexity is higher, even though in most cases its smaller size is far less complex than that of a NetScaler policy.

Consider the following examples, both of which perform a simple redirect:

F5 iRule:

when HTTP_REQUEST {
 
     set redirect_url [findclass ]HTTP::host[ Redirects " "]
 
     if { $redirect_url equals "" } {
 
         HTTP::redirect "http://www.company.com/"
 
    } else {
 
         HTTP::redirect $redirect_url
 
    }
 
}

 

Netscaler equivalent:

add rewrite action act_replace_url replace 'HTTP.REQ.URL.PATH_AND_QUERY' '"/products/page.htm"'
 
add rewrite action act_replace_host replace 'HTTP.REQ.HOSTNAME' '"www.newcompany.com"‘
 
add rewrite policy pol_replace_pol1 '!HTTP.REQ.HOSTNAME.SERVER.EQ("www.purchasedcompany.com")' NOREWRITE
 
add rewrite policy pol_replace_pol2 'HTTP.REQ.HOSTNAME.SERVER.EQ("www.purchasedcompany.com")' act_replace_host
 
add rewrite policy pol_replace_pol3 'HTTP.REQ.IS_VALID' act_replace_url
 
bind rewrite global pol_replace_pol1 100 END
 
bind rewrite global pol_replace_pol2 200 300
 
bind rewrite global pol_replace_pol3 300 END

Now, it is rare that a single redirect will be implemented. For each redirect needed the NetScaler “expressions” must be duplicated. The F5 iRule requires only that its dependent data group – a simple, easily readable list of host names – be updated. Both the BIG-IP and NetScaler will inform an admin if there is a basic syntactical error in either an iRule or a policy expression. What they cannot detect are errors in the strings representing the host names. For a single redirect F5 requires one strong, NetScaler requires 4 – which means 3 additional opportunities to introduce an error. Its complexity grows right along with size, which NetScaler acknowledges when it claims that “the mandated use of iRules forces administrators to write custom TCL-based scripts that can quickly become complex and unwieldy to manage.”

It also somewhat oddly claimed that “F5 compels BIG-IP and VIPRION customers to develop script-based iRules for even commonly used content switching and load balancing policies.” We’re fairly certain that an HTTP redirect is a common content-switching policy, and note that Citrix’s solution is not only unwieldy, but hardly intuitive with its declarative language. Now *I* know (having reviewed NetScaler in the past) what that means, but I’m guessing not everyone does. An interesting thing about using a scripting language is that even though a network or devops admin might not know TCL, they most likely do know shell script or other imperative scripting (programming) tools. Which means even without knowing TCL or the iRules API, they are likely able to understand what the iRule above is doing. Using declarative policy commands that may or may not be intuitive without specialized product knowledge is, well, not as intuitive as claimed.

Citrix here is pointing out the speck of sawdust in iRules eye but paying no attention to the plank in its own. This particularly logical incongruity is known as a “Special Pleading” or more commonly, the “double standard.” 

FLEXIBILITY

In our view, flexibility means enabling administrators and devops to implement a solution regardless of whether we’ve productized it or not. Many iRules have become so popular and in demand that we have productized them into simple checkbox configuration options within BIG-IP. But much of the time an iRule is used to solve a unique integration or networking problem that can only be solved by having the ability to dig into L2/3, inspect data at L7 and identify the user – at the same time. What an admin might want to do with that information shouldn’t be limited by what F5 determines can be done.

Consider the previous example of iRules versus NetScaler code for a simple redirect. Say you wanted to Limit Connections From a Client. Assuming you could achieve this using policies, the resulting configuration would be much more complex and prone to errors than any structured language-based customization. Two-Factor Authentication With Google Authenticator and LDAP. Transparent Web Application Bot Protection. It is generally the case that what you want to do has already been done, debugged, and published on DevCentral where it can be had for the taking, modified or not, and used.

(And if you really don’t want to write the code for a redirect, you can always grab the iRule Redirection Generator

The iRules CodeShare on DevCentral is full of solutions to both unique and common problems. ranging from those involving the network (layer 2/3) to the application (Exchange 2010). iRules allows you to extract and inspect virtually any protocol, which offers far more flexibility compared to the limited set of protocols understood by Netscaler Policies (VLAN ID, IP, port, HTTP, TCP, DNS, a little RADIUS). iRules offers support for all those and more - SIP, LDAP, DIAMETER, FTP, SMTP. If it’s a protocol, iRules is likely able to support it.

Additional Resources:


Connect with F5:
o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1] rss[8]google
     

Latest F5 Information