In this module we will explore how to use F5’s iWorkflow platform to
further abstract Application Services and deliver those services, with
a Declarative interface to Consumers.
When moving to an iWorkflow based toolchain it’s important to understand
that automation in L1-3 (Device Onboarding, Networking, etc) and L4-7
(Deployment of Virtual Servers, Pools, etc) is separated and delivered
by different features.
Layer 1-3 Networking and Device Onboarding
L1-3 Networking and Device Onboarding are highly specific to the particular
environment the BIG-IP instances are deployed on. The onboarding process for
various platforms and ecosystems is very different due to differences in the
L1-3 capabilities and APIs of each platform. As a result F5 publishes specific
documentation and guidance for each of these environments:
- Public Cloud:
- Private Cloud:
iWorkflow enables generic functionality in all of these environments by using
a BIG-IP Cloud Connector. This connector allows iWorkflow to utilize
BIG-IP devices running on any of these environments.
Note
F5 BIG-IP also supports integration with Container Ecosystems.
However, in these environments iWorkflow may not be required. For more
information you can refer to:
Layer 4-7 Application Service Delivery
L4-7 Application Service Delivery is accomplished by:
- Consuming F5 iApp templates on BIG-IP devices and
creating a Service Catalog (Declarative).
- Consuming the iWorkflow REST Proxy to drive API calls to
BIG-IP devices (Imperative).
The labs in the module will focus on the high level features in place to
achieve full L4-7 automation. As mentioned above, iApp Templates are a key
component of the chain of linked tools (toolchain) we are building.
In this Module we will focus on building a Service Catalog using the App
Services iApp template you learned about in Module 2. The focus in Module 2
was to show how to deploy advanced configurations. However, a large amount of F5
Domain Specific Knowledge was still required to build each deployment.
From a conceptual point of view, iApp templates alone do not fully satisfy the requirement
for a fully Declarative interface because while the iApp template simplifies
the underlying Imperative actions, it does not allow the administrator to
build an Interface that minimizes or eliminates the need for Domain
Specific Knowledge.
For example, we deployed a service that enabled HTTP Traffic Management with
an iRule attached and Profile Customizations. To the F5 administrator these
are all very familiar terms, however, to a consumer, such as an Application
Owner, the terms Virtual Server, iRule, Profile, etc. are foreign
concepts.
To solve this problem iWorkflow allows the administrator to create a
Service Template that is an Abstraction of the iApp templates
input fields. By doing this the F5 administrator can create an interface
tailored to the use case and knowledge level of the CONSUMER rather than the
ADMINSTRATOR, enabling full featured and complex Layer 4-7 Application
and Security services that are tailored to business need and use case rather
than the technical implementation. Additionally, the Service Abstraction
achieved when creating the Service Catalog enables the easy integration of
F5 services with third-party tools and methodologies such as DevOps.
