The intrinsic asymmetric division of BIG-IQ
The intrinsic what?
In cell division, when intrinsic asymmetric division occurs (a parent cell divides), the two new daughter cells are not equal and exhibit different properties. [https://en.wikipedia.org/wiki/Asymmetric_cell_division]
So, what I’m saying here is, BIG-IQ has changed; it was one, but now is two, and that each is different.
What did we do?
Until November, we delivered a single BIG-IQ product, available as both physical and virtual form factors. On this device we provided a series of modules:
- BIG-IQ Device
- BIG-IQ ADC
- BIG-IQ Security
- BIG-IQ Cloud
In mid-November we divided the product and now, separately deliver BIG-IQ Centralized Management and BIG-IQ Cloud (or “BIG-IQ Cloud and Orchestration”, as its been labelled on our support and downloads sites to help distinguish from the older BIG-IQ Cloud 4.5 solution.)
BIG-IQ Centralized Management v4.6 provides device lifecycle management for physical and virtual BIG-IPs through its BIG-IQ Device, ADC, and Security modules. BIG-IQ Centralized Management manages the BIG-IP LTM, ASM, and AFM modules.
BIG-IQ Cloud v1.0 is an orchestration and template configuration assistant for facilitating the delivery of F5 BIG-IP application services into cloud and software defined networking environments. This first release provides connectors for both Cisco ACI and VMware NSX environments, in addition to a REST API for integration into 3rd party management and orchestration systems. BIG-IQ Cloud 1.0 also functions as an iControl proxy for accessing the BIG-IP management REST API’s and enabling iApp lifecycle management.
For more detail about the benefits and capabilities of each refer to the new data sheet found here: “Simplify Management and Orchestration in an Application-Centric World” – https://www.f5.com/pdf/products/big-iq-datasheet.pdf
Why did we do this?
Well, I did say “intrinsic”, so why was it essential? When there’s a clear division in the use cases, and the administrative personas, of a product or service it’s often best that these functions are served separately. The operations staff that look after device backups, and software updates are often not the same employees responsible for application deployments.
Device management: software updates, config backups, SSL certificate management… device specific functions.
Orchestration Services: providing an abstraction layer for simplified deployment, faster time to market, reduced operational risk.
The former, a product/solution of its own right. The latter, presenting services to larger 3rd party systems.
When do I use which product?
That depends on what you are trying to achieve. This is important for the simple fact that with any given Management and Orchestration system (often referred to as MANO) there can be only one “source of truth”. This is not a new phenomenon, and it is not specific to F5. Consider the following scenario, a child asks one parent for permission to attend a party, and that parent says no but the child then asks the other parent, who says yes. Multiple sources of truth cause conflict and confusion.
It is for the same reason that two different SDN controllers cannot manage the same network, as at no point will they share the same view of the topology.
The source of truth for device management is the devices themselves. The device manager collects device-specific information that can then be manipulated by the device management tool, BIG-IQ Centralized Management. In the case of software updates, the device manager knows what versions of code it has available in its repository, and what version is running on the devices it is managing. Consequently, the code update process is simple. However, when it comes to orchestration, the source of truth is typically a 3rd party system, which is also managing other devices and technologies within the data center. Such 3rd party systems might include HP Operations Orchestration, VMware vRO, Chef, Puppet, Ansible, or Salt, to name just a few.
To remain accurate, and to avoid deployment/management failure, that 3rd party system must be the authoritative "source of truth" for all of the devices and software under its management. Should changes be made without its knowledge, the result could be disastrous. Hence, the running configuration of the devices and software under its management must be known to it at all times.
So, back to the original question. Do you want to manage devices specific functions, or integration BIG-IP app services into your management and deployment orchestration?
The role of BIG-IQ Cloud v1.0 is to provide a point of simplification, an abstraction, from the many features and functions of the BIG-IP traffic management platform. Directly managing BIG-IP devices with a third party system would take years of development to ‘teach’ the 3rd party system all of the options, variables and dependencies of each and every function. However, through the concept of services templates (F5 iApps) BIG-IQ Cloud 1.0 can very quickly present a catalogue to a 3rd party system. Thus enabling application services deployments without sacrificing any of the rich functionality our customers enjoy from the BIG-IP. Service templates are the secret sauce to rapid integration with reduced risk!
Next steps?
Take a look at the official doc introducing the two new offerings:
SOL05211126: Introducing new BIG-IQ Cloud and Orchestration and BIG-IQ Centralized Management product offerings
https://support.f5.com/kb/en-us/solutions/public/k/05/sol05211126.html
