Six Things About F5 BIGIP v11 iApps

F5 Networks’ Local Traffic Manager (LTM) is my load balancer – okay, Application Delivery Controller, if you insist – of choice. The LTM platform is as feature-rich and well-supported as they come, with all sorts of customizability as well as the iRule scripting language (a superset of TCL) that lets you do fancy transaction manipulation. F5’s development pace on the LTM platform is a bit maddening at times, as there’s always something new just around the corner that forces an IT staff to keep up with incremental software upgrades or risk a much harder upgrade somewhere down the road.

In BIGIP version 11, F5 introduced a significant new feature called iApps. iApps are a way of deploying a complex application by answering a set of questions, i.e. filling in a template. iApps also offer analytics, although I have not spent time with this feature as yet. From the standpoint of getting applications up and running through an F5 quickly, iApps are a good thing.

  1. Invoking an iApp is like running a provisioning script. Let’s say you’re going to deploy Microsoft Exchange 2010 using the supplied iApp template. To get the iApp set up, you answer a rather long series of questions about how you’re going to deploy Exchange, IPs of specific servers involved, key DNS names, etc. When it’s all said and done, the LTM churns away, and voilà! Pool members, virtual servers, health checks, etc. are all built for you. Like magic. Really then, one way to look at an iApp is as a glorified script.
  2. F5 sometimes releases newer versions of a given iApp template, which you can download from their site. Going back to the Exchange 2010 example, the newer iApp version of the official F5 iApp template fixes a number of timing and persistence issues that might bite you with the old iApp template, just depending on how you deployed Exchange. Also worth pointing out is that F5 offers many deployment guides on their site in PDF format that will recommend a specific iApp for you to use if appropriate.
  3. iApp reduces deployment errors that can be made when implementing a complex application through LTM (and companion F5 products). When you build a set of nodes, pools, monitors, virtual servers and iRules, there’s an myriad of ways to screw them up. As feature-rich as the LTM platform is, there’s a lot of options, pulldowns, and blanks to fill in if you’re using the GUI. If you’re using TMSH scripts (what I’ve moved to for almost all LTM provisioning to avoid the maddening clicky-clicky), there’s still a number of ways to make mistakes, but your exposure is less. With TMSH, you’re issuing commands that are going to get rejected if you try to do something crazy. But still, there’s plenty of opportunities to blow it. iApp takes a lot of that risk out of the equation, making it more likely you’re going to get a working configuration for an application right out of the gate.
  4. “Strict updates” locks you out of tweaking an iApp, but unchecking this feature lets you fiddle. The default iApp lifecycle is for you to answer the iApp’s questions, the F5 building out the app based on your answers, and then you not being allowed to change what the F5 built at all unless you go through the questionnaire again. This is “strict updating”, which makes it less likely you’re going to break F5’s (hopefully) finely tuned iApp build process. On the other hand, it might be handy to make a little tweak to some component of the iApp. Perhaps you want to introduce a more capable monitor. Or maybe a more or less aggressive timer would suit you better. Or an iRule customization would be just the thing. In that case, you can disable strict updates, and try your hand.
  5. An iApp offers enhanced application monitoring. Now, don’t mistake this for what a full-blown transactional application monitoring system would do for you (although you *can* do transactional monitoring with some F5 monitors), but once the iApp is built, you get a nice “components” screen to monitor your application status at a glance. This is arguably handier than trying to keep track of individual virtual server & pool member statuses yourself. I say “arguably” because with careful object naming and the “Network Map” feature, you could get a similar screen. But what the iApp components screen gives you is a hierarchical view of *all* key application components and their status, including things you can’t see on the “Network Map” like certificates and monitors attached to virtual servers and pool members.
  6. You can build your own iApp templates. I’m going to try my hand at this at some point, because a company I do a lot of work for tests various builds of their software using a cookie cutter approach. With the right iApp templates, I could delegate the creation of new virtual servers to other folks. “Oh, you need a new bank to test version X.Y of the software release? Use the iApp templates and go crazy.” That’s the theory, at least. Until I give it a shot, I’m not sure how it will work out practically speaking.

So, do I love iApps so much that I will hug them and squeeze them and name them George? As a hardened cynic, I have a hard time being overly enthusiastic about any technology, but I say that iApps are a useful, time-saving tool. In that sense, I like them. I have no great desire to agonize over an application’s architecture to figure out what is required of the LTM *if* there’s a ready-made iApp blessed by F5 and the application vendor. Any time saved doing provisioning work frees me up to perform other tasks, of which there’s an endless supply.

Will I actually try to build my own iApps? We’ll see. Sounds interesting. How hard can it be?


More on iApps (F5’s DevCentral community site, free account required to get to the useful content, no F5 relationship required)

BIG-IP iApps Developer’s Guide (F5’s support site, no account required)



  1. Oliver says

    Wish we could make more use of iApp’s in our environment. Unfortunately, very few things are cookie cutter here.

  2. Nuno says

    One downside of iApps is that if you make custom changes to the finished app outside of the iApp (e.g. customize the iRules, tweak the monitors, add/remove profiles, etc), when you reconfigure the iApp and save your changes the iApp script will wipe your custom changes and revert the app to the templatized version. This has bitten me a few times. With that in mind, you just have to remember/document any custom changes you make and fix them afterwards or just make changes outside of the iApp going forward. Other than that, iApps are great for vanilla apps.

  3. says

    Ethan, it’s great to see an article on an F5 feature, or any ADC related one for that matter; they are few and far between for some reason. I’d love to see more please. Regarding this article and F5 in particular, I’m surprised you don’t make any connection between iApps, iRules, iControl and SDN. Sure, it’s not the focus of your article and it’s more Greg’s drum to bang but don’t you see one?

    • says

      I make a point not to boil the ocean in blog posts. I had one topic to hit, and I hit it. Yes, F5 appliances obviously have capabilities that play nicely in an SDN ecosystem, something that SDN vendors are already taking advantage of. But that’s a topic for another day.

      Realize that the vast majority of the Packet Pushers community don’t care even a little bit about SDN at this point, and we’re criticized regularly for how much we cover it. Therefore, I personally don’t want to hammer on about SDN too much when I blog here.

      That said, you’re not an F5 employee that I can tell, although I’m aware of your book. If you’re interested in contributing ADC content here as a blogger (with or without an SDN focus ;-) ), that would be welcome. Send an e-mail to, and I’ll get you set up if you’re willing to contribute to the community in this way.

  4. says

    I hate to leave corrections in the comments section but there doesn’t seem to be a way to do so privately. It’s a constant area of confusion so to clarify: BIG-IP refers to F5’s hardware or virtual appliances, TMOS is the collection of multiple OS’s running on those appliances (Linux for management, TMM for ADC/traffic management functions plus others). LTM is called a TMOS ‘module’ but is in reality a TMM module as that’s where it runs. So, where LTM is concerned, the software heirachy goes like this: TMOS > TMM > LTM.

    • says

      I don’t mind when people leave corrections publicly. I updated the post already by removing one statement, but to complete your thought, v11 is v11 of what exactly, if not BIGIP?

      As you say, BIGIP refers to the hardware, then v11 must be v11 of something else. I can’t make an obvious determination from F5 documentation. The way F5 uses the terms “BIGIP,” “LTM,” and “TMOS” in conjunction with the version number in release notes, it’s hard to know exactly. Also, when requesting a software version number from the CLI, the response is “BIG-IP” followed by the version number.

      So, I get your point, but I’m not entirely sure how to respond.

      • says

        F5 Certainly tend to use (and document) the terms in an inconsistent way themselves and I suspect the marketing folk understand the differences between them the least. Working on the basis that a BIG-IP is a physical appliance, not software and the TMOS ‘collection’ of operating systems such as CentOS for the HMS, the EUD, the MOS, AOM etc. are certainly not at v11 and an upgrade updates those plus TMM and LTM (and/or other modules) all in one go, I’d say it’s TMOS v11.

        Of course, to muddy the waters further, the VE edition is called BIG-IP VE but I like to just think of this as the virtualisation/hypervisor ‘wrapper’ around TMOS and leave it at that.

  5. Eamon Walsh says

    For all the good press F5 started off which .. off late it seems Netscaler is truly beating it to the finishing line. bit. ly/ 1AthpoG

Leave a Reply

Your email address will not be published. Required fields are marked *