Getting Started with iControl: History

tl;dr - iControl provides access to BIG-IP management plane services through SOAP and REST API interfaces.

The Early Days

iControl started back in early 2000.  F5 had 2 main products: BIG-IP and 3-DNS (later GTM, now BIG-IP DNS).  BIG-IP managed the local datacenter's traffic, while 3-DNS was the DNS orchestrator for all the BIG-IP's in numerous data centers.  The two products needed a way to communicate with each other to ensure they were making the right traffic management decisions respective to all of the products in the system.  At the time, the development team was focused on developing the fastest running code possible and that idea found it's way into the cross product communication feature that was developed.  The technology the team chose to use was the Common Object Request Broker Architecture (CORBA) as standardized by the Object Management Group (OMG).  Coming hot off the heels of F5's first management product SEE-IT (which was another one of my babies), the dev team coined this internal feature as "LINK-IT" since it "linked" the two products together. 

With the development of our management, monitoring, and visualization product SEE-IT, we needed a way to get the data off of the BIG-IP.  SEE-IT was written for Windows Server and we really didn't want to go down the route of integrating into the CORBA interface due to several factors.  So, we wrote a custom XML provider on BIG-IP and 3-DNS to allow for configuration and statistic data to be retrieved and consumed by SEE-IT. 

It was becoming clear to me that automation and customization of our products would be beneficial to our customers who had been previously relying on our SNMP offerings.  We now had 2 interfaces for managing and monitoring our devices: one purely internal (LINK-IT) and the other partially (XML provider). The XML provider was very specific to our SEE-IT products use case and we didn't see a benefit of trying to morph that so we looked back at LINK-IT to see what we could to do make that a publicly supported interface.  We began work on documenting and packaging it into F5's first public SDK.

About that time, a new standard was emerging for exchanging structured information.  The Simple Object Access Protocol (SOAP), which allows for structured information exchange, was being developed but not fully ratified until version 1.2 in 2003.  I had to choose to roll our own XML implementation or make use of this new proposed specification.  There was risk as the specification was not a standard yet but I made the choice to go the SOAP route as I felt that picking a standard format would give us the best 3rd party software compatibility down the road.  Our CORBA interface was built on a nice class model which I used as a basis for an SOAP/XML wrapper on top of that code.  I even had a great code name for the interface: X-LINK-IT!  For those who were around when I gave my "XML at F5" presentation to F5 Product Development, you may remember the snide comments going around afterwards about how XML was not a great technology and a big mistake supporting.  Good thing I didn't listen to them...

At this point in mid-2001, the LINK-IT SDK was ready to go and development of X-LINK-IT was well underway.  Well, let's just say that Marketing didn't agree with our ingenious product naming and jumped in to VETO our internal code names for our public release.  I'll give our Chief Marketer Jeff Pancottine credit for coining the term "iControl" which was explained to me as "Internet Control".  This was the start of F5's whole Internet Controlled Architecture messaging by the way.  So, LINK-IT and X-LINK-IT were dead and iControl CORBA and iControl SOAP were born.

The Death of CORBA, All Hail SOAP

The first version of the iControl SDK for CORBA was released on 5/25/2001 with the SOAP version trailing it by a few months.  This was around the BIG-IP version 3 time frame.  We chugged along for a few years through the BIG-IP version 4 life and then a big event occurred that was the demise for CORBA - well, it's actually 2 events.  The first event was the full rewrite of the BIG-IP data plane when TMOS was introduced in BIG-IP, version 9 (we skipped from version 4 to version 9 for some reason that slips my mind).  Since virtually the entire product was rewritten, the interfaces that were tied to the product features, would have to change drastically.  We used this as an opportunity to look at the next evolution of iControl.  Until this point, iControl SOAP was just a shim on top of CORBA and it had some performance issues so we worked at splitting them apart and having SOAP talk directly to our configuration engine.  Now we had 2 interface stacks side by side.  The second event was learning we only had 1 confirmed customer using the CORBA interface compared to the 100's using SOAP.  Given that knowledge and now that BIG-IP and 3-DNS no longer used iControl CORBA to talk to each other, the decision was made to End of Life iControl CORBA with Version 9.0.  But, iControl SOAP still used the CORBA IDL files for it's API definitions and documentation so fun trivia note: the same CORBA tools are still in place in today's iControl SOAP build tools that were there in version 3 of BIG-IP.  I'm fairly sure that is the longest running component in our build system.

The Birth of DevCentral

I can't speak about iControl without mentioning DevCentral.  We had our iControl SDK out but no where to directly support the developers using it.  At that time, F5 was a "hardware" company and product support wasn't ready to support application developers.  Not many know that DevCentral was created due to the popularity of iControl with our customer base and was born on a PC under my desk in 2003.  I continued to help with DevCentral part time for a few years but in 2007 I decided to work full time on building our community and focusing 100% on DevCentral.  It was about this time that we were pushing the idea of merging the application and infrastructure teams together - or at least getting them to talk more frequently.  This was a precursor to the whole DevOps mentality so I'd like to think we were a bit ahead of the curve on that.

Enter iControl REST

In 2013, iControl was reaching it's teenage years and starting to show it's age a bit.  While SOAP is still supported by all the major tool vendors, application development was shifting to richer browser-based apps.  And with that, Representational State Transfer (REST) was gaining steam.   REST defined a usage pattern for using browser based mechanisms with HTTP to access objects across the network with a JavaScript Object Notation (JSON) format for the content.  To keep up with current technologies, the PD team at F5 developed the first REST/JSON interface in BIG-IP version 11.5 as Early Access and was made Generally Available in version 11.6.  With the REST interface, more modern web paradigms could be supported and you could actually code to iControl directly from a browser! There were also additional interface based tools for developing and debugging built directly into the service to give service listings and schema definitions.
At the time of this writing, F5 supports both of the main iControl interfaces (SOAP and REST) but are focusing all new energy on our REST platform for the future.  For those who have developed SOAP integrations, have no fear as that interface is not going away.  It will just likely not get all the new feature support that will be added into the REST interfaces over time.

SDKs, Toolkits, and Libraries

Through the years, I've developed several client libraries (.Net, PowerShell, Java) for iControl SOAP to assist with ramp-up time for initial development.  There have also been numerous other language based libraries for languages like Ruby, PHP, and Python developed by the community and other development teams.  Most recently, F5 has published the iControl library for Python which is available as part of our OpenStack integration.  DevCentral is your place to for our API documentation where we update our wiki with API changes on each major release.  And as time rolls on, we are adding REST support for new and existing products such as iWorkflow, BIG-IQ, and other products yet to be released that will include SDKs and other reference material.

F5 has a strong commitment to our end users and their automation and integration projects with F5 technologies.  Coming full circle, my current role is overseeing APIs and SDKs for standards, consistency, and completeness in our Programmability and Orchestration (P&O) team so keep a look out for future articles from me on our efforts on that front.  And REST assured, we will continue to do all we can to help our customers move to new architectures and deployment models with programmability and automation with F5 technologies.