by Joe Pruitt, F5 Principal Architect

When we started design and development of the iControl interfaces, our original goal was simple: To give remote entities full programmatic access to our devices with as simple a ramp-up time as possible.

Through this simple goal we've been able to provide the following to our customers:

  • Ability to automate error-prone, labor-intensive tasks.
  • Simplify management functions and reduce overhead.
  • Deliver new solutions to enhance business continuity and expand IT value.
  • And, gain greater long-term value from your investment.

 

We'll, it's been over 3 years since the first version of our SDK was published and we've listened to customers and end users about how we can enhance our offerings. In the early stages of our products, we heard that the performance needed improvements. In response to those requests, we optimized our code on the servers by lowering memory overhead requirements and reducing the session initiation times.

After the performance was addressed, we heard from more and more of our customers who were trying to build larger-scale applications to management many devices across multiple data centers. Our granular interfaces that were optimal for single-device management were now the source of too much network "chattiness". We responded with this by adding "bulk" versions of our interface methods enabling the controlling application to do "more" with each request. For these types of applications, we've found a reduction of above 75% in bandwidth consumption and execution time.

The current model of network management has been primarily polling-based. By this I mean it is the burden of the client to request the information that it needs. For the majority of monitoring and auditing applications out there, constant polling of our devices is overkill as they are primarily concerned "when" something happens. Why should the burden be put on the client to figure out when this is?

Enter Push...

We'll we didn't stop there. With version 9.0, we've taken another first in the network management space. Enter the new iControl Event Interfaces...

You may say: "Wait a minute! SNMP traps have been around forever." While this is true, what makes our offering unique is that it is fully Web Services based. No other network vendor provides a full web services based push notification service. Here's how it works...

 

  1. The Clients application implements the Management.EventNotification interfaces as defined in the iControl SDK v9.0. We've made it so simple, that we've included a reference ASP.Net Web Service. Just create a virtual directory under your IIS root and point it to the EventNotification directory of the SDK and you've got a fully functional endpoint to receive notifications. If ASP.Net is not your platform of choice, never fear! Since we are standards based, our interface can trivially be implemented in the language and on any platform you chose!

  2. Create a subscription. This is achieved by using the Management.EventSubscription interface. The current interface provides 46 different subscription types ranging from "Everything" to "All deletes" to "node address changes. The combinations are endless... We've included a windows application for this as well.

  3. Wait for a notification and process the Management::EventNotification::events_occurred() method. The sample endpoint in the SDK will log the results to a file in the TEMP directory.


    Once the endpoint has the data, it can be archived in a database and used for real-time alerting (cell phone, pager, etc) or longer-term trend reporting.

 

Conclusion

Just as our core interfaces have opened up brand new integration points between the applications and the network, the eventing interfaces will bring out many new possibilities in real-time alerting and notification.

References