Forum Discussion

Altocumulus

Mar 02, 2023

iControl vs AS3

I just started looking into F5 REST APIs. I've been told that iControl will be deprecated in favor of AS3. But, some reading about AS3 makes it look like it is used to configure F5 devices. I didn...

cloud

Matt_Mabis
Mar 08, 2023
Hey cbarlock - let me help you answer your question about AS3 vs Rest, i believe that the aim is more of AS3 should be considered the gold standard to delivering applications, for things like what you are talking about (querying and gathering data) to fill in blanks i think those will be around for a very long time, either that or will be adapated to something that will be more in-line with our Automation toolchain.

The automation toolchains are really aimed at deploying configurations in their endstate so in theory you wouldnt need to query an object as it would be configured to however the templates are designed, and any modifications would be done to the templates never within the GUI or CLI so the templates become the single source of truth.

There are 3 major parts of our Automation Tool Chain as per (https://www.f5.com/products/automation-and-orchestration). Ill try to explain to you how i define them.

Declarative Onboarding (DO) - This is where you are setting up the F5 think of Day 1 type operations, setting up the BIG-IP (IPs/DNS/NTP/Self IPs/VLANS/Modules deployed/Sync Groups/etc.). DO is really about configuring the device(s) if you would like to see a example declaration i do with ansible and vSphere deployments.
https://github.com/VDI-Tech-Guy/f5-bd-bigip-vmware-vSphere/blob/main/roles/F5-Roles/do_configure/templates/do_configure.j2

Applications Services 3 (AS3) - this is all about delivering applications within tenants, the idea of AS3 is to have 1 single declaration to deliver the "End State" of your deployment (for that tenant (partition)). Think of it as deploying all your vips/pools/nodes in their final configured state for the entire tenant (if thats 100s of vips or 10 vips) and the declaration contains the entire deployment for that tenant. The biggest thing to note here is that AS3 NEVER writes to the common partition and this is by design. the reason it wont write to common is becuase if think of common as ROOT and wrote its end state it would have to track every tenant within it or you could wipe out the entire root and partition set... so this is why its not allowed. AS3 is all about the Apps tho so when you think about delivering apps AS3 is what you aim for.
Here is an example of AS3 deployments that i do for deploying apps via our Ansible 101/201 courses where you are filling in variables in a template to deploy out tenants.
https://github.com/f5devcentral/f5-bd-ansible-labs/blob/main/201-F5-Advanced/AS3/01-Deploy-SSL-Enabled-App_Services-AS3/j2/https.j2

Telemetry Streaming (TS) - is all about monitoring applications delivered, and setting up that monitoring with either BIG-IQ or other montioring services like Prometheus, Elastic/Kibana, Splunk etc. If you want to start doing things like Event-Driven Automation setting up some sort of telemetry is going to be key to delivering that level of automation.
Here is an example of TS with Elastic -
https://github.com/F5Networks/f5-telemetry-streaming/blob/master/examples/declarations/elasticsearch.json

Hopefully this helps answer your questions (sorry if long winded), and if not please let me know

Zdenek

Cirrostratus

Hello, I see quite some answers in this topic, but no-one confirmed or denied this "iControl will be deprecated in favor of AS3."

We have built quite a massive automation using F5 Rest API (iControl Rest) where we directly go to F5 without any iWorkflow, BigIQ, AS3. I believe the RestAPI is going to be available for long time and no changes to that are planned, right?

Matt_Mabis

Employee

Dec 19, 2023

iControl will be utilized in BIG-IP Classic until its full end of life as far as i know, moving forward into our future product scopes i.e. (Next, XC) Product lines will heavily focus on our declaritive delivery so it is the recommendation of F5 to eventually migrate over to an AS3 format for your code so that you can have a proper migration strategy when the full end-of-life for BIG-IP Classic happens you have a path forward into our next generation of products.

in our public documentation it refers to in our NEXT Platform how iControl is transitioned to Declarative API.
https://www.f5.com/pdf/products/an-introduction-to-big-ip-next-f5s-next-generation-big-ip-software.pdf

BIG-IP Next completes the transition away from imperative APIs (iControl REST)—where
individual commands must be arduously sequenced together to automate simple tasks—to a
more powerful, flexible, and entirely declarative model where desired end-state declarations
centered around use cases are all that is required to automatically configure instances. This
shift makes deploying and configuring applications faster and also replaces the need for
extensive domain knowledge—making it easier for administrators to automate tasks. F5’s
Declarative API, Application Services 3 (AS3), is carried forward from BIG-IP and continues to
be the primary API for L4-L7 app services configuration, automating configurations required
for all application services in a single declarative API call. All the benefits of a declarative
configuration model can also be realized on BIG-IP Next through F5 App Services Templates
(FAST), which provide a fast and easy way to deploy applications with minor inputs and
minimal system knowledge. AS3 declarations and FAST templates used to configure BIG-IP
TMOS devices can be modified by the Journeys Migration Service to be compatible with BIGIP Next, allowing reuse of existing declarations and templates when migrating applications
to BIG-IP Next.
Both AS3 and FAST templates are fully integrated within BIG-IP Next software so that
extension installation is no longer required. Compatibility with leading automation and
orchestration tools, such as Ansible and Terraform is also maintained, allowing DevOps or
developer teams to integrate app services deployments as part of their CI/CD pipelines.
Additionally, F5’s declarative API supports multi-threading which enables tasks from multiple
orchestrators to be processed concurrently, benefiting multi-tenant deployments

Hopefully this answer helps.

Zdenek
Cirrostratus
Dec 19, 2023
Thanks for taking time to answer, appreciate it. Regarding "almost sacred" declarative model, well not sure how about others, but in our case it's not just about deploying stuff, but also about visibility. Over the years we built complex database where we keep VIPs<>irule/policy/pools/sslprofiles/sslcert/key/csr in the database and visualise it in our portal. We are able to show all mapped objects in well readable format and connect it with our automation etc. This is not about declarative vs imperative model, but about getting to the low-level data, if F5 decides to drop direct API access then it would loose one of its biggest benefits it brings us at the moment, simply said versatility and maturity of F5 API was a key factor for us when deciding about ADC vendor.
Another case is, for example, SSL certificate automation with ACME we built above the data we have, so it's fairly easy to onboard new service to the SSL cert order, we can map it easily and proceed with CSR signing and installing it to any LB/SSL profile where it's needed. Again, I cannot imagine what would be the approach with declartive model here.
I understand F5 needs to keep API attractive to non F5 "guru" users who need to publish service with minimal effort, then declarative model is perfectly fine, we do that as well with our declarative model 🙂 But imperative model has strong position and I think I am not alone here.
Sorry for longer post..
- Anesh
  Cirrostratus
  Feb 15, 2024
  I am in agreement with Zdenek The iControl REST API gives you a lower level control of all the individual properties of the TMOS, unlike AS3 , also to fact that we have to figure out how to manage state, if you are not using something like Terraform...etc so it looks like more of a forced decision from f5, rather than a community driven decision to transition away from imperative to declarative model..
- JRahm
  Admin
  Dec 19, 2023
  Hi Zdenek , ACME cert management will have no problem integrating into the BIG-IP Next way of doing things. Unclear to me if it's 100% today, but definitely on the roadmap if not. Even if not fully integrated today, you can manage your certificates for applications off-instance, and then send them in declarations as documents to CM, and then from CM those documents can be deployed as application services to instances and go from draft->active workload. It's a new way of thinking about things from a management perspective, but at the end of the workflow, it's still a configuration on an instance doing a job. That configuration is just going to be AS3 instead of a config file. It's just json, so that information can be grokked just as well from that format as the big-ip configuration file format. It's definitely going to take some work for customers who already have a lot of automation in place, we're sensitive to that and acknowledge the work ahead, it's why we're talking about it now to give everyone a few years to plan.
  
  Even though control plane access is shifting mostly (there will be some laggers, like cert management) to Central Manager, the APIs will not be problematic to pull the information you need, most of the logs/metrics will be retrievable directly from CM, and if you need that data elsewhere, you can set up otel directives on the instances to stream logs and/or metrics directly to 3rd party servers.
  
  I'm going to to a generic home labs office hours next week 9am-noon pacific on Dec 28th, happy to chat about that stuff live and understand your pain points so I can communicate them back to the team!
  - Zdenek
    Cirrostratus
    Dec 20, 2023
    We already are in production with our ACME solution, all the logic is at our end, only we need from F5 are iRules (for domain validation) and then few API calls to import and install certs, that's it. We are not in need to use any robust product because we made it "home-made" tailored to our needs.
    
    Anyway, I work for managed service provider, we are not some small/medium/large company focused to just our products, but we serve multiple different customers and customer environments are different, some are very special - historically. Standarization is ongoing but it's long run and we cannot make any hard cuts, because it means, in some cases, to loose a sales case. Trust me, I faced it already and had to sacrifice level of the standardization (and thus automation) to be able to adapt to the situation and have a deal.
    You mentioned:
    I'm going to to a generic home labs office hours next week 9am-noon pacific on Dec 28th, happy to chat about that stuff live and understand your pain points so I can communicate them back to the team!
    I would be happy if we can talk, 20 mins and you get an idea, of course, if you are interested. We are bit advanced, about 20 thousands line of code related to F5 orchestration, we started to use API since F5 leaved SOAP model. Please leave me a message if you'd like to meet up. Thanks
cbarlock
Altocumulus
Dec 19, 2023
The declarative model is fine for configuring the F5, but one of the things we do with iControl is query the F5 for information like its IP address, virtual servers, serial number, yada, yada. I haven't seen anything that addresses this in BIG-IP Next.
- JRahm
  Admin
  Dec 19, 2023
  cbarlock you'll be able to see that information in CM GUI or via the API as well, for example, the onboarding manifest details of an instance:
  
  https://clouddocs.f5.com/products/big-iq/mgmt-api/v0.0.1/ApiReferences/bigip_public_api_ref/r_openapi-next.html#operation/GetOnboardingManifest
  - JRahm
    Admin
    Dec 19, 2023
    and to both of you...I hear you on the imperative interface! I'm a fan as well, and like the precision of it But the APIs for CM are declarative in configuration management, but not every API call is a declaration. There's a blend, and I think as we all get comfortable with the new CM/Next Instance APIs we'll be able to breathe out a little.
    
    I'm saying that to myself as much as anyone else...I'm a creature of habit and get off my lawn already! 🙂