Getting Started with iApps: A Conceptual Overview

tl;dr - iApps provide admins and service desks a template solution for application deployment and management services.

Deploying and managing applications require a lot of information across several disciplines.  Architects have their holistic view of the application ecosystem and relevant lifecycles.  Developers have their granular relationship with each application under their umbrella.  Networks admins make sure applications are behaving appropriately on the network instead of hijacking QoS classes or hijacking DNS.  Then there are those missing details that no one wants to own until something breaks (looking at you Java CA store).  Originally F5 introduced deployment guides to help administrators understand the requirements and configurations needed to deploy popular applications behind BIG-IP.  However, after the deployment was complete, those configurations were still managed through object types alone (e.g. virtual servers, pools, profiles, iRules, monitors).  That can get quite tedious when you have hundreds of applications on a single BIG-IP stack.  Someone somewhere said “Wouldn’t it be nice if we could have an application-based view of all the different objects that help us deploy, manage, and secure each application”?

Enter iApps

Introduced in BIG-IP 11.0, iApps are a customizable framework for deploying and managing application as a service.  Using out-of-the-box templates, administrators can deploy commonly-used applications such as Oracle, SAP, or Exchange by completing a series of questions that relate to their management and infrastructure needs.  Rather than create a bunch of virtual servers, followed by a handful of monitors, then a plethora of whatever, the responses to iApps questions create all of the BIG-IP objects needed to properly run your application.  The iApps application service becomes the responsible manager of all virtual servers, monitors, policies, profiles, and iRules required to run.  Consolidating these into a single view makes management and troubleshooting much easier to handle.

iApps Framework

iApps consist of two main elements, the template and application services created by publishing a template.  We’ll dive into this in our next article, Getting Started With iApps: Components.

• Templates: The base configuration object which contains the layout and scripting used to configure and publish application instances.  Some templates are prebuilt and included in BIG-IP, while others can be download from DevCentral (are not officially supported) or F5 support (certified and supported).  Developer-oriented teams can also build custom templates for frequently used configurations or services.
• Application Service:  An application service is the result of using an iApps template to drive the configuration process.  The Administrator uses the configuration utility to create a new application service from the selected iApps template.  Created objects are grouped into components of the application service and are managed accordingly.

The iApps Advantage

iApps are not for everyone.  If you like keeping tribal control over your BIG-IP ecosystem or if you like naming virtual servers after your pets, iApps may not be for you.  iApps do have an advantage if you want to templatize your deployment scenarios or wish to allow other administrators access to the services they manage.  iApps reduce a lot of the mystique and intimidation a lengthy set of profiles, policies, and pools can sometimes cause to the new or intermediate administrator. 

Above we show an example of building a highly available LDAP namespace for internal applications with the default built-in LDAP iApps template.  By providing a certificate and and answering a few questions, an LDAP environment is created for all of your internal directory authentication or lookup requirements.  From there, modifying the configuration is easy as selecting the Reconfigure tab in the existing application service.

Changing settings within iApps

Sometimes you just want a template to assist with application deployment and from there you’re perfectly fine managing the individual object types.  The Component view will show you all objects affected by the application service but if you try to apply a change, you’ll receive an error similar to:

This is by design because the iApps application service is the rightful owner of the system object and shouldn’t be edited directly.  However in certain cases you don’t the iApp anymore or want more granular control of some features the iApps my not have, there is an option.  Each application service published via iApps have a Properties tab which allow you to disable the Strict Updates method of management.  Unchecked, each object is configurable on it’s own but will deviate from the templates last known state.  Some administrators prefer to operate this way, only using the iApp as a deployment method, and that’s perfectly fine.  We’re leaving your application management style and method up to you.

As BIG-IP expands to cover more of the application landscape, people are increasingly taking advantage of more programmatic features and iApps is no exception.  Allowing our administrators to improve their ease of deployment and use is why iApps exist and we’ll continue to develop and improve these features.  Our next article Getting Started with iApps: Components will dive into more detail on the properties required to create and manage iApps.  Take the time to get to know iApps, they’re your ally for keeping your applications in order.