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.
- 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.
- 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.
- 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.
- “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.
- 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.
- 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?
Links
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)
About Ethan Banks
