F5® iWorkflow™ accelerates the deployment of applications and services while reducing exposure to operational risk. The iWorkflow™ 101 series has been created to share common workflows for the purpose of accelerating your organizations journey towards integration, automation, and continuous deployment. In episode #1 of the iWorkflow™ 101 series we take a high-level look at the various themes and components of the iWorkflow™ platform to aid in understanding its operation.

Who’s it for?

iWorkflow™ is for anyone interested in:

• the rapid deployment of performance, high-availability, and security policy
• the simplification of policy execution through abstraction of complexity
• extending continuous deployment practices to include scalability and security
• reducing exposure to operational risk

Architectural Walkthrough

New theme’s introduced in this episode:

• Application Services
• Application Services Templates
• Services Template Catalogues
• Tenants
• Clouds
• Workflows

Application Services

If you are familiar with F5 BIG-IP’s then you already know about Application Services. If not, they are the Layer 4 – 7 features and functions delivered by the BIG-IP application delivery controller. Such application services include:

• High-availability monitoring and resilience
• Load-balancing
• DNS Services
• DDoS mitigation
• Application/Data security
• Access control
• Scaling and optimization
• Context switching / app routing
• and much more.

For more information on application delivery controllers and the services they both provide please visit: F5® BIG-IP

Application Services Templates

An application services template defines a configuration, while accepting deployment-specific information at the time of execution. At this stage its important to introduce the Declarative Model, and a simple way to explain this is to talk about McDonalds…

When you enter a McDonalds restaurant you are presented with a range of meal options. Lets say you were to choose a Big Mac meal, which includes fries and a soft drink. The “meal" itself is the template: you get a Big Mac, fries, and a soft drink. Sure, you can choose which soft drink you get (cola, lemonade, water), you can even select a dipping sauce (ketchup, honey mustard, sweet chili, etc), but you are not required to define the Big Mac, nor are you able to order items outside of the meal options–try asking for a Pizza instead of Fries! The declarative model provides an abstraction to the meal creation process alleviating the customer from much the complexity. 

In contrast to the declarative model we have the imperative model. Using the McDonalds scenario again, an imperative model would require that you order every single ingredient individually, in addition to explaining how they are prepared, and how they are put together to make the meal. 

Back to Services Templates, the declarative model allows for infrastructure administrators and architects to define sets of common deployment configurations and expose such templates to teams that may not be skilled in application delivery policy. Organizations can then realize the benefits of advanced functionality while avoiding lengthy deployment delays, as such an architecture eliminates the need for business units to become experts in every technology. Instead, approved, repeatable policies can be deployed directly by operations staff, or by 3rd party orchestration systems, at the time of application deployment.

In 2011, F5® released iApps (F5’s application services templates) to eliminate much of the manual process and repetition involved in configuring the BIG-IP application delivery controller.

For more information on the benefits of services templates, please read: “Why you need service templates”. For technical details on F5 iApps, navigate here.

Services Template Catalogue

A Services Template Catalogue presents the application services templates to the deployment staff. The deployment could be performed manually by an employee via the iWorkflow™ GUI, or by 3^rd party systems communicating with the iWorkflow™ iControl REST API. In either scenario, both the administrator and 3rd party system are interfacing with the Services Template Catalogue.

Connectors

The connectors provide the communication between iWorkflow and other systems. For example, the local BIG-IP connector provides a tenant with destination BIG-IP’s upon which to deploy policy. The Cisco APIC and VMware NSX connectors provide for the deployment of BIG-IP application services within Cisco ACI and VMware NSX environments. Lastly, the Integration SDK, allows organizations to build their own integrations and functionality.

Tenants

A services template catalogue, and the destination devices and environments, are presented through the iWorkflow™ Tenant feature. Consider a Tenant as a grouping of Application Services Templates, Connectors, Devices, and the Users and Groups with the appropriate permissions to deploy application services upon them. Such a grouping vastly simplifies the management of fine-grained access control, while limiting the user’s exposure to the complexity of the environment.

Workflows

In the context of iWorkflow™, workflows are the end-to-end execution of a system’s or operator’s intent to deploy policy. In the case of an iWorkflow Tenant, the execution starts directly with iWorkflow™, via the GUI or iWorkflow™ REST API. However, in the case of a 3rd party system the workflow starts from within that system which executes the application services template deployment through iWorkflow™.

Workflow walkthrough

Stitching these themes together, following is a step-by-step walkthrough of a simple workflow:

When talking about workflows we start with the intent, and work through to the executed policy. This intent could be that of a 3^rd party system, or of an iWorkflow Operator manually deploy an iApp. With that in mind, referring to the number diagram above, lets now walk through the various elements of a workflow:

1. To the administrators and 3^rd party systems from which iWorkflow™ takes instruction, there are two interfaces: a) the iWorkflow™ GUI, and b) the iWorkflow™ iControl REST API. The iControl REST API may be interfaced by 3rd party systems or by sys-admins using various scripting options or desktop REST API clients. Detailed examples of using each will be provided in future iWorkflow 101 episodes found here on DevCentral: iWorkflow Home
    
2. The “Service Template Catalogue” presents the local, administrator-defined services templates that have been permitted for the tenant. Exactly which options are configurable at the time of deployment, within each template, is predetermined by the iWorkflow™ administrator. Consequently, the simplicity, or complexity, of each template, and how they are implemented per iWorkflow tenant, is extensively configurable to match an organizations requirements.
    
3. The “Services Templates” themselves, the F5 iApps, that are presented via the “Service Template Catalogue”. How much of their functionality that is exposed via the Service Template Catalogue is configurable, and thus simplifying how administrators can accommodate the varying capabilities of the iWorkflow Operators: be they 3^rd party systems or sys-admins. 
    
4. The iWorkflow™ platform itself that hosts the Services Templates, the presentation of the Service Template Catalogue, and the iWorkflow™ Connectors, while also managing the multi-tenancy, role-based access control, and what elements of which templates should be exposed where and to whom. Its quite amazing, really!
    
5. iWorkflow™ communicates with the BIG-IP ADC’s via the BIG-IP iControl REST API.
    
6. The F5 BIG-IP Application Delivery Controllers (ADCs) themselves. These devices, physical or virtual, consume the performance, availability, and security policies that were defined by the services templates, and enforce that desired behavior.

The Provider / Tenant model

There are two distinct iWorkflow™ personas: the iWorkflow Administrator, and of the iWorkflow Tenant.

The iWorkflow™ administrator creates and manages the various objects of the iWorkflow™ platform that are required to execute a workflow. Once configured, these object are provided to the tenants. Such objects include:

• BIG-IP Devices
• Connectors
• Services Template Catalogues
• Users/Groups
• Tenants
• Licenses

The iWorkflow™ Administrator is not able to create, delete or modify these objects. The role of the Tenant is to execute the deployment of performance, high-availability, and security policies via the service template catalogue, as configured/permitted by the iWorkflow™ Administrator. This is typically referred to as a Provider/Tenant model.

iWorkflow Administrator

As shown in the diagram below (top right corner), the “admin” user is logged in and that user is an iWorkflow™ Administrator. An administrator has the ability to add BIG-IP Devices, create Connectors, add Catalogue entries, and more.

iWorkflow Tenant

In this example the user “user1” is logged in. Note that it no-longer states that an “Administrator” is logged in, as per the previous image (in the top right-hand corner). In this example, the iWorkflow Tenant has been configured with access to the “myConn1”, local Connector. “user1” does not have the ability to create, delete, or modify Connectors. Only to deploy pre-determined policy to BIG-IP Devices via the "myConn1” connector.

Summary

Using application services templates, organizations can eliminate repetitive effort during deployments. This enables them to accelerate time to market for new applications and services, reduce exposure to operational risk, and enable infrastructure consumers (the business) to self-serve: deliver performance, high-availability, and security policy at speed.

For more information, return to the DevCentral iWorkflow Home page.