To use an iRule or to NOT use an iRule? It seems like a simple question when first asked doesn’t it? Yet when you reflect upon what you are really saying when you answer that question, you will realize a lot of thought should go into the answer.

TMOS is gaining a wealth of new functionality with each release and word of what you can achieve through using iRules is spreading even to those unfamiliar with the BIG-IP product line. I have personally seen this discussion pop up more than once and we even grappled with it at the MVP Summit in Chicago.

I can’t help but reflect back on the book “The Art of War” by Sun Tzu when thinking about this subject. During the summit I realized that we were pretty much attempting to do the same thing that Sun Tzu did. To come up with tactics and lay out truths that could be relied upon to come to a logical decision about how to proceed.

With Sun Tzu, his end goal was to win the battle or war that he was fighting. He wrote roughly 80 pages of tactics and guidelines for fighting war. I think the same thing could be done simply to answer the question to use an iRule or to not. The problem is that for those of us in the F5 community, is that generally speaking, we all have our own goals.

That makes setting guidelines to follow a little harder unless you first define two very important aspects. I think the first question you should ask yourself is what is your role in your organization? Secondly, what is the role of the F5 BIG-IP device(s) in your organization?

Something that I know without a doubt is that we all fill different roles in our respective companies and so do our BIG-IP devices. There is no one size fits all answer to this unfortunately. For those of you who are new to working the BIG-IP product line and those of you who have yet to set any real company policies regarding your use of iRules I have one small word of advice. I urge you to sit down with your boss and talk about what you stance will be regarding iRules moving forward. If you ARE the boss then I suggest thinking about this matter in depth and reflect not just on how it effects you but also your team. I have no doubt that doing this in advance will save you a lot of trouble.

What are the topics you should think about? What are all the possible gotchas that might come up? It is again different for us all. After having pondered this question myself, here are a few things I think one should keep in mind and discuss with their peers/boss:

1. K.I.S.S. – That’s right, keep it simple stupid. It’s a best practice that we should all follow. The question though is this, will using an iRule make something simpler for you or more complex? If it makes something simple it’s a no-brainer right? It it makes things more complex? Where do you draw the line?

2. If you do use an iRule and you decide to do some complex logic in it, are you legally required to keep track of that code in an application code repository? Different regulatory items will obviously apply depending on the nature of your business. I know that in a lot of places that if one were to write complex iRules that changed the data that a customer see’s, then they would most certainly have to keep track of that. Sometimes though, it is not external regulatory compliance but INTERNAL regulatory compliance that you have to think about.

3. Who will support it? If you write a really complex iRule who will support it in the future? Are you prepared to redo an iRule at two o’clock in the morning because of a production update that a developer pushed out changed the code that your iRule relies upon?

4. Let’s say that an opportunity to use an iRule has already presented itself. Is it more cost productive for the business for the iRule writer to craft an iRule to fix the problem or to have the application programmers fix the problem in the code?

5. What about your physical environment variables? Can you implement this new iRule code without slowing down everyone else’s application traffic (provided you delivering multiple apps through it of course)?

6. Perhaps it will come down to your boss looking at you and saying, “How comfortable are you writing an iRule to try to do this?”. If that is the case and you are uncertain, then by all means head on over to the DevCentral forums and create a post about it! You would be AMAZED at the things that people have done with iRules and AMAZED at how simple some of those things are to pull off! iRules, it slices, it dices, it… well you get the idea. Use the community to bounce ideas around because it can definitely help make that decision much easier for you to make.

7. What approach should you take in general to iRule or not to iRule? Should you take the look before you leap approach, always say yes or always say no? I am sure that most will pick the look before you leap approach just to make certain they can do what they need to do using an iRule programmatically, that they can do it efficiently and that doing so meets their other preset criteria. It also may be that your role in the company and the role of your F5 BIG-IP device is strictly that of a networking device and iRules are not to be used or developed. If that is the case, I would urge you to reconsider that stance and at least consider using some of the simpler iRules… please see comment #6 above.

I am sure there are a million more questions you can think of to ask that might be relevant to your current working conditions, this post is by no means a definitive guide. Please feel free to add a comment to this post regarding things that may have helped you and your organization define your policy towards using or not using iRules. I really would love to hear them.

It is wise to remember what Sun Tzu said of laying plans, “The general who wins a battle makes many calculations in his temple before the battle is fought. The general who loses a battle makes but few calculations beforehand. Thus do many calculations lead to victory, and few calculations to defeat; how much more no calculation at all.”