iControl

Managing Traffic (for baggage claim)

Jeff Browning — Wed, 12 Nov 2008 20:54:14 GMT

Sometimes, you see things that you just need to capture on... err... SD memory. While waiting for my bag yesterday at the Las Vegas Airport, Joe Pruitt found himself a nice little Java console app that probably wasn't supposed to be visible. If you've been through the baggage claim here, you've no doubt seen the HUGE banners advertising every new show in town. It's complete sensory overload (hey - it's Vegas, right?) However, this caught Joe's attention. Honestly, I doubt many people even saw it but Joe spun on a dime and started dissecting the database calls and methods scrolling across the screen. Something about "switching to next to claim 6...stopping claim 5", etc.

In you're in Vegas attending the DevConnections event at the Mandalay Bay Convention Center, look for us at booth #625. I'll also be presenting at OpenForce08 this afternoon about the role network infrastructure plays in successfully delivering DNN-based applications.

Technorati Tags: f5, devcentral, devconnections, openforce2008, java, jeff browning

Support, Social Technology, and Trust

Jeff Browning — Thu, 11 Sep 2008 23:35:19 GMT

As Don mentioned earlier this week, we took the plunge and entered Forrester's Groundswell contest. To me, I believe this is the ultimate testament to what you, the community, are doing on DevCentral everyday (check out this page - it's pretty cool). Back when we started this thing, it was simply to help folks learn how to tap into F5's groundbreaking iControl API. After asking users, we learned that folks needed some assistance getting started. Surprise, surprise - understanding terms like WSDL, SOAP, and related things were a bit new to F5's traditional users! With backgrounds in software, where forums have been around a while, we thought this would be a good tool to enable us to assist and support users as they played with this cool technology.

Honestly? Selling management on un-moderated forums was not a slam-dunk. There were (reasonably) concerns that someone might say something nasty. That said, we made a philosophical choice... to trust our users. We wanted them be as involved and invested in this community as F5 is. So - trust matters. Along the way, something interesting happened: the community even started to protect it's own turf!

The same thing happened when we weighed the pros and cons of moving ALL of our technical documentation to a wiki. (what? let ANYONE edit it? seriously...?). Yes - like the forums, there was plenty of debate. Once again, the notions of trust and enablement - all with the desire of supporting users through more free-flowing, 24x7, worldwide contributions - won out. The result? Well - just one example is the over 100 iRule samples posted in the Codeshare today - the vast majority contributed by real users working on solving real challenges everyday.

When looking at this whole contest thing, I'm sure some of the other categories could have applied. But, the "supporting" category is the most obvious choice. However, it's not exactly why most might think... When I step back and look at what everyone is doing in the community, what strikes me most is how - in significant part because of the social media technologies we've embraced - users are supporting each other. Without a free-flowing community, ideas and solutions created in Auckland may have never been seen by users in Munich. Or, a cool iRule trick from someone in London may have never reached someone in Tokyo.

Further, I'll be the first to admit this: there are some protocols or technologies that we'll NEVER know as well as some of you. You're work, day in and day out, with a specific protocol or application server - and specifically it's subtle quirks that come from working with it daily - help you bring a completely different dimension to other users wrestling with a similar problem. Sure - we can research and understand something academically. However, members' tribal, hands-on knowledge makes all of the difference when providing real, useful solutions.

Candidly, there are times when I ask myself this: how do vendors that DON'T enable this free-flow of ideas survive? With the growth of cloud, SOA, virtualization, etc., the technology hairball and the knowledge required cannot be owned by one all-knowing company, right?

I go back to the beginning; it's this notion of trust, free-flowing ideas and dialog, that makes this community all about support. Not just F5 supporting our technology (as it should). But, helping end users help each other to just get more... value... ideas... inspiration... support. All from others working to solve similar problems.

BTW - some serious props go out to F5 leadership for trusting and embracing the community as partners and co-collaborators on this journey. If not for that trust, I don't think we would see the dynamic interaction that happens each day on DevCentral.

So, if you've read this far, thank you for your participation in and involvement with DevCentral. If you feel like it, maybe make a visit to our entry page and make a comment and vote for DevCentral. Also - we've set up a Forum here on DevCentral as well for you to post your comments, thoughts, likes, etc. about DevCentral.

Technorati Tags: forrester, groundswell, devcentral, f5, icontrol, wsdl, social technology, community, protocol, cloud computing, SOA, virtualization, Jeff Browning

What's the difference between a CLI and API, really?

Jeff Browning — Tue, 29 Apr 2008 21:58:15 GMT

Here at Interop, I had an interesting conversation on the show floor about integration. We were talking about how another company can remotely invoke change against infrastructure "via the CLI". When I asked why, the reasoning was that it's just how the infrastructure can be integrated - kind of because, "that's what's available". Sadly - that's pretty true in the networking world. To date, there is no API like iControl that offers a comprehensive API with broad tool support and functionality.

So - when writing integration via the CLI, what happens when the hardware versions change? Maybe an upgrade patch? Or, what if some smart engineers add some new features that require existing CLI commands to be deprecated?

How does the integration work after that? In many cases - it doesn't. And, that's the difference between a CLI and API. CLIs are hardwired scripts that work well in the short term but don't evolve as gracefully as true integration. Now - they have their place - no question about it. But, for smart, dynamic integration?

APIs provide a more dynamic, fluid integration and binding between software and infrastructure. To do this, the work on the infrastructure side is not trivial. However, it makes a HUGE difference for the end-user trying to write and maintain integration as the underlying infrastructure evolves.

API = nimble and flexible. CLI = brittle and difficult to manage. Big differences.

Technorati Tags: api, cli, iControl, f5, devcentral, Jeff Browning

Virtualizing VMware?

Jeff Browning — Tue, 29 Apr 2008 21:22:11 GMT

Wow - that sounds kind of bizarre. Like load balancing a load balancer? Or, maybe launching a rocket launcher?

OK - I kid. However, when you think about the ease with which companies can spin up instances of virtual servers, it's pretty easy to understand how a bit of intelligent load balancing could be useful. Useful from not just an optimization perspective but especially a management simplification perspective.

So, that's where Steve Duplessie's recent post comes into play. Honestly, sometimes it takes someone a few steps removed to explain things most eloquently. Here on DevCentral, we can get pretty deep in the technical weeds. So, it's always refreshing to see such a well articulated assessment of things.

Plus, any analyst that gets excited enough about technology to say "killer" is cool by me. Here's the part I thought really cut to the chase:

"VMware can make one physical server look like 98. F5 can apparently make 98 physical servers look like 1. That's killer."

You should take a look. Steve really nails it.

However - there's another aspect of this that is worth mentioning. Spinning up that many virtual servers is cool. But, managing how they are virtualized by F5 BIG-IP (when you're talking about 98 of 'em) can be a bit overwhelming. It's no secret that virtual server sprawl is quickly becoming a hot issue for IT departments.

So, what's an IT pro to do? Type in a huge batch of CLI commands? Surprisingly, some do. It hurts my head to think of it.

There ARE better options though that really begin to show why we invested in the iControl API years ago.

Example 1: what if you could automagically add new virtual servers to your BIG-IP collection of nodes when they start up? Pretty cool. Here's the sample code.
Example 2: to get even more elegant, what if - based upon increases in connections/requests - you could AUTOMATICALLY spawn new virtual servers in VMware? Wicked. Check out the article (with screenshots) here and get the sample code here.

[Updated @ 6:30pm 4/29: Nicolas, our DevCentral/iControl/iRule rockstar in France, wanted me to mention that there's more coming soon on this front... stay tuned - you'll get the details here as soon as we have them! Also - working on updating the sample code... hope to have the right stuff there ASAP. -Jeff]

So, there you have it. Virtualization of VMware. And, integration code, ready-to-go, to help you automate the way they work together. That, to me, is "killer".

(Special shout out to Matt, Mohamed, and Nicolas - some of F5's best and brightest - for making these possible!)

Technorati Tags: vmware, virtualization, f5, big-ip, code samples, Jeff Browning, devcentral

Job-Hacking

Jeff Browning — Mon, 27 Aug 2007 18:01:07 GMT

I recently had a fascinating conversation with Rob Whiteley of Forrester. We were chatting about how life is changing for the network professional. How more and more automation is driving the frontline network ops folks to look for new areas in which to build skills, offer innovative solutions, etc. I was surprised by the lengths at which companies are going to automate otherwise "human" tasks today to reduce cost and risk and increase efficiency.

Since then, I haven't been able to get a term (created by my friend Dave) out of my head: "job-hacking".

(courtesy of www.hardwickrecruiting.com)

I can't help but believe - simply from the real stories I've heard from the community - that rolling up sleeves and learning how iRules and iControl work is the fast track to getting closer to the application teams. Maybe scoring some points with the folks in the security group. Using these "job-hacking" tools, maybe you can write an iRule that saves a developer a few weeks of work. Or, maybe YOU can architect how the automation of the data center takes shape with an iControl app that orchestrates application or patch updates. Last time I checked, zero downtime during patches for the business units and no more 2am Saturday maintenance windows (for you?!) is a good thing.

Each day is a choice. Each day is an opportunity to move forward, to add a new tool to you toolbox, that puts you in control of your destiny. Trust me - I've spoken with countless users out there that say, "iRules are cool but... I'm swamped. I can't afford to make time to learn how to use them with everything else I have to do."

To anyone that thinks that... I would argue you can't afford to delay embracing tools and technology that will help you evolve before trends in the industry catch up with you. Your most valued job-hacking tools could be the iRules... or iControl apps... you keep pushing to the bottom of your task list.

Thoughts? Chime in with your opinions...

Technorati Tags: irules, icontrol, security, automation

The Forgotten Network Tier?

Jeff Browning — Thu, 09 Aug 2007 19:58:48 GMT

An interesting article has been published on www.devx.com by Ty Anderson, a consultant at Cogent Company. Check it out - he does a great job of pointing out how application developers can take advantage of the network (and specifically - iRules and iControl) when writing apps. Here's a snippet...

"The reality is developers can build better, more effective applications by utilizing Application Delivery Controller (ADC). These devices are deployed in your network and track all network traffic. This includes in-coming, out-going, and internal traffic. Once installed and configured, these devices know everything that occurs in your network. This means they also know everything about the information sent and received by your applications."

For more, go here: http://www.devx.com/vstudioextensibility/Article/35158

Technorati Tags: icontrol, irule, visual studio, ADC

The eye can be deceiving

Jeff Browning — Fri, 13 Apr 2007 21:43:44 GMT

As a baseball fan, it's mindblowing to me that it took this long to actually read "Moneyball" by Micheal Lewis. If you're a fan of the game and like the stats side of baseball, it's an intriging read. I won't cover it too much here except to say that it highlights how one team - the Oakland A's - eschewed traditional approaches to evaluating talent and took a completely different approach to drafting players. It's incredibly eye-opening.

While reading it, a number of concepts stood out as transferable to technology and IT. One was this: that when evaluating things (talent in the book), the human eye, or the way we see things based upon "how we've always done it", can be deceptive. In many cases, stats can paint a very different - and more objective - picture of what's going on.

It reminded me of a regular question I ask datacenter staff (and related, moderately scientific study I've conducted) over the past 5 years. It goes something like this:

Jeff: "How many hours do you think you spend each week doing CLI work to accomodate either server updates or new application rollouts for other teams?"

IT Admin: "Well, it's hard to say. Maybe 5-10 hours."

Jeff: "Ever mistype something... say an IP address... and have to fix something using the CLI?"

IT Admin: "Sure - sometimes."

Jeff: "You know - you could probably automate some of that and reduce all typos... like fat-fingering of a .10 into a .100..."

IT Admin: "Yeah - but - that might take me a few days to build and this is working alright."

This seems reasonable. However, in reality, that 5-10 hrs is usually more (I've had people track this and realize it's closer to 25 hrs). And, based upon accumulated examples from a wide range of customers, CLI-work has roughly a 30% error rate. Acceptable? Maybe. Ideal? No so much.

The deception comes in here... Add up that 10 hrs (conservative for many) for a typical work year at we're talking about 12.5 weeks of effort. That's more than a month! What if you could build an app using iControl to automate some of these routines? Say it takes 2 weeks of effort...

Wouldn't you trade 2 weeks to get another 10 back to do other things on the list that never get any attention? (and - reduce those CLI errors to virtually zero in the process... and get fewer, screaming calls from application owners?...)

The point is this: doing it the same way it's always been done conveniently deceives us. We lose track of the time we spend... we don't evaluate it for what it is vs. what we think it is...

Assembly

Jeff Browning — Tue, 10 Apr 2007 23:12:00 GMT

If you spend much time with kids, you learn that assembling things - trains, toys, etc. - is part of the program. You also learn that kids themselves really like assembling things. Train cars switching places in-line behind the locomotive. Tracks sections in various configurations. Of course all of this is done to get the desired result (which can change daily or even hourly!)

Some of the most interesting kids don't stop with the order of the cars or train track. Some actually take the cars apart, reassemble them in new ways (sometimes missing certain parts), and arrive at completely new and cool variants of the original.

Fast forward a few years and it's easy to see why "pimping a ride" via extensive mods and customization is such a major trend among adults (big kids). Assembling new variations on a theme, for either expression or purpose is a powerful and exciting process with amazing results.

The ability to assemble pieces flexibly is to me what feeds ingenuity and makes it possible to achieve great things. If locked into a fixed environment, it's hard to assemble and let the mind run to it's most creative (and dare I say "productive"?!) result. For example, have you ever seen a wizardized HTML editor or web development tool that can completely wizardize building a website that solves any unique need? It's not only impossible - you would likely chuckle at anyone suggesting it. Even simpler, I can't imagine how MS-Excel would work if it only had a wizard. In fact, other than charting, it's actually the un-wizard (and BTW - statiscally the Microsoft product featuring the highest customer satisfaction rating for years...)

Going back to kids (or cars... or bicyles... or music... or virtually anything engaging or innovative), the toys that stop getting used are the ones with the least flexibility to be used in new and interesting ways. Alternatively, toys (or cars... or bicyles... or music... or virtually anything engaging or innovative) that afford infinite possibilities to assemble new combinations are the most engaging and frankly, most interesting. (heck - some even keep parents engaged for hours...)

Everytime I launch the iRule Editor, I kind of smile (thanks Joe!). To have the ability to quickly build highly useful iRules yet be able to tweak them and tune them to infinite degrees, it's the perfect technology and tool for solving real problems. I can use Codeshare to find building blocks that both accelerate the process and help me learn simultaneously.

My creativity is my only limitation. And, that's pretty cool.

I think that's an important part of why we are seeing so many cool things going on amongst the DevCentral community. You (the members) are finding new ways daily to assemble new combinations or collections of technology to solve things that in some cases have not been able to be solved before.

Codeshare = jb2kewl

Jeff Browning — Tue, 03 Apr 2007 23:53:00 GMT

With DC4, we really wanted to make it easier to share samples beyond iRules. Why? Well, samples provide useful building blocks from which the community can both learn and get a jumpstart on a project. So, we (ahem - Colin, actually... ;-) did some masterful work that makes it much easier than ever to post samples as attachments. If you have a cool Perl script, some PHP, or even VB code that helps you, consider sharing it with the community. The more everyone shares, the more everyone benefits.

As a special nod to member "jb2kewl", check out the PHP scripts he posted today to manipulate node states. What's cool about this? It can be easily tweaked to do virtually any node manipulation exposed via iControl. Awesome. Thanks jb2kewl!

BTW - if you want to keep current with the latest samples posted to Codeshare, you can always look here.