The F5 and Cisco APIC integration based on the device package and iWorkflow is End Of Life.
The latest integration is based on the Cisco AppCenter named ‘F5 ACI ServiceCenter’.
Visit https://f5.com/cisco for updated information on the integration.
The latest integration is based on the Cisco AppCenter named ‘F5 ACI ServiceCenter’.
Visit https://f5.com/cisco for updated information on the integration.
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
These points hold true whether you’re a traditional infrastructure administrator managing F5 BIG-IP’s directly, a platform architect or engineer responsible for presenting resources to business units, or an application architect or developer looking to rapidly deploy new apps and services as part of the continuous deployment pipeline, while ensuring they remain fast, highly-available, and secure.
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 3rd 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 3rd 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:
- To the administrators and 3rd 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
- 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.
- 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 3rd party systems or sys-admins.
- 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!
- iWorkflow™ communicates with the BIG-IP ADC’s via the BIG-IP iControl REST API.
- 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.
