Monitoring/Management

Golf ball or bowling ball?

Jeff Browning — Tue, 06 May 2008 19:47:42 GMT

While they're both round, I will probably prepare differently to catch either one if thrown at me. Wouldn't you? I might stand differently. I might even ponder, "do I need one hand or two?" I'll definitely consider what could happen if I fail to catch the ball and how it might bounce or even break something where it lands.

Mindless musings, you say? Maybe. But really? How is this any different from what most network teams deal with? Seriously.

Pretend you're the app guy and I'm the network guy. You know what you're going to throw. You've spent countless hours defining it, building it, making sure it makes the business folks happy, and even (I hope) testing it. You are closer to it - and know more about it - than anyone possibly could (or most would ever care to understand, frankly).

So - why won't you tell me about it? Really. Because I don't understand. It's not hard. It probably won't take much time. It certainly doesn't steal your thunder.

Here's the deal: I'm going to build for a bowling ball - guaranteed. It's safer. But, know this - I won't be as quick and nimble. It'll take two hands. And, the thought of that coming will certainly occupy more of my mind than a golfball might because I don't want to face the risk (and embarrassment not to mention damage) that dropping it might bring. So, I'll be pretty preoccupied. Forget those other things on my task list.

It eat more of IT's budget but be incredibly overbuilt when your golf ball comes my way. And, I won't have the time, budget, or option of help you optimize your app or provide additional security help. I spent it all preparing for a bowling ball (and I'm really quite stressed even about the thought of it.) So, you'll have to write that code. And test it. And update and maintain it. You have plenty of time, right?

It's not a pretty picture. But, it's all together too common. Just heard about it from someone - again - today.

When will IT groups learn that the good from sharing more information far outweighs any fear of bad that comes from sharing it?

Technorati Tags: application delivery, F5, IT management, Jeff Browning, bowling ball, golf ball

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

Must Read iRule Doc

Jeff Browning — Tue, 17 Jul 2007 21:56:25 GMT

I just ran across one of the most useful docs I've seen posted by the team on DevCentral. If you're new to iRules, possibly looking for ways to expand your knowledge, or just bored and looking for something cool to do, this document in the iRule wiki is a must-read. It breaks down some of the most common ways iRules are used and it provides some really useful building blocks for when you want to combine elements for that "double black diamond"-like challenge you're facing.

For example: how about an iRule that simply illustrates logging (a useful debugging technique in itself)? Or, trying to limit pesky client attempts to throttle your servers with excessive connections? Maybe you're interested in using Data Groups (class files) that allow you to abstract variables in a better, more organized, and efficient manner.

Check this out.

(btw - a special nod to Colin for this - great work!)

Technorati Tags: irule, connection limiting, event logging, data groups, class files

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...

Take a Couple Days Off

Jeff Browning — Wed, 11 Apr 2007 19:52:10 GMT

Seth Godin really hit home today with this post. Chances are, you'll hear from one of your web marketing managers soon asking you to fix your server error pages. Lucky for you, there are some great iRules contributed by the DevCentral community that can sove this problem in a matter of minutes (so that YOU can take a day off too!).

For instance, the most obvious is the "File Not Found Handler". Or, you could "Insert Content Into a Server Response". If problems are ocurring because of someone requesting an HTTP:// URL instead of an HTTPS:// URL, you could use the "HTTP to HTTPS redirect" (and avoid the error page altogether).

A cool solution could also take advantage of Harlan Richard's "Return_Status_404" iRule which enables one iRule to flexibly handle all 404s and other errors across multiple web properties.

Or, to get really elegant, you could start with Kevin Stewart's iRule - "OCSP Authentication error redirect" - and build an iRule that enables you to customize the error response based upon the user request and even provide suggestions on what to do next... Adding "breadcrumbs" like this not only help the user get where they're trying to go. It can even make helpdesk troubleshooting easier when the user calls for help.

Nothing like the flexibility to solve these problems quickly - and easily - thanks to community driven innovation and ideas.

Oh yeah - one nice benefit is that by running this as an iRule, you only have to do it in one place... Since you won't have to update every server in the data center with the same error handling code, I think you probable deserve another day off...