#v11 #iApp #devops Bring dev and ops closer together to enable IT as a Service and repeatable, consistent application deployments.
The overriding theme of BIG-IP v11 is its focus on applications. From security to availability to management to resiliency, this release is focused on applications. Its revolutionary approach to application services offer immediate and future operational benefits by taking another step toward a dynamic data center.
iApp is a feature name for what are fundamentally programmable application templates. These templates make simple user interfaces for complex system configurations. The minimal UI requirements are defined from the existing template wizard system within BIG-IP’s GUI. Unlike the template wizard system, however, after the user fills out the form they can return and edit the form again; iApps are reentrant. The system also keeps track of all the objects associated with a given application, creating a higher level view of the configuration. Finally, the application template specification is readable and editable by end users, so they can construct their own templates, or modify existing templates to better suit their needs.
IT REALLY is THAT EASY
The presentation, the GUI, is described using TCL. This describes the UI and the choices offered for configuration such as IP addresses of API and associated HTTP endpoints.
The result is a configuration GUI based on the template. This is displayed within the BIG-IP GUI and used to configure the application service for deployment.
The configuration options specified by the administrator are stored in the iApp as variables. Templates are reentrant, meaning administrators can modify the configuration at any time, unlike wizards which generally require a linear configuration process.
The variables are then available in the “implementation” section of the template. The implementation section can perform any action that can be performed via TCL – including CRUD configuration via the TMSH scripting interface
What this process provides is a repeatable application deployment pattern. It reduces the potential for misconfiguration by restricting input and providing the means to verify and validate that input. Being reentrant provides the capability to adapt to changing operational and business conditions through reconfiguration.
iApps are also capable of performing custom methods that can be used for a variety of interactive and non-interactive actions. For example, an interactive action might be to dynamically turn on a “sorry page” for users without persistent connections, disable all nodes, quiesce connections and then down the nodes. Another possibility is to interrogate switches via SNMP or invoking programmatic interfaces such as VMware vSphere API to determine where, topologically, a node (application instance) is located. This would be particularly useful in dynamic, virtualized environments such as cloud computing in which instances are volatile and provisioning occurs often as part of a larger, more network-inclusive provisioning process.
Non-interactive custom actions are event-based and thus could be triggered on events currently supported by TMOS (which are too lengthy to list but include options across security, access and general traffic management). For example, one might run a custom action periodically to collect and/or calculate a user-defined statistic and publish the value as part of the application. Another option might be to trigger an action based on average latency of responses: when it increases above X, deploy additional instances of the application via the server infrastructure framework.
Custom methods is a control plane framework similar to iRules in that they provide the means to manage infrastructure state within BIG-IP and programmatically codify specific operational processes that improve the efficiency of the provisioning and run-time environments.
GAP CHASM between DEV and OPS
The devops movement speaks often of the need to bridge the chasm that exists between developers and operations and they have begun the process of building that bridge by adopting development methodologies that better enable consistent, repeatable application deployments in terms of their supporting infrastructure. But they have not yet truly embraced the idea of bridging that chasm by making infrastructure services more accessible to developers. That requires a fundamental change in language and perspective, such as iApp offers. Operators are still required – the operational parameters required to configure BIG-IP and infrastructure in general requires a certain baseline knowledge of networking and infrastructure most developers do not hold. But just as developers are more than capable of configuring and creating the application deployment packages required by application server platforms, so too are they capable of configuring and creating the application delivery service packages required by infrastructure to successfully deploy applications into a production network if the information is presented in a more developer friendly way.
Certainly iApp is no panacea to the problem, but it is a huge leap forward toward closing the divide between developers and operations.
Consider checking out the iApp resources here on DevCentral for a more thorough view into iApp and its unique capabilities: