After many requests, we've just launched a new discussion area for folks that want to talk about the F5 Application Security Module (ASM). This is a new opportunity for the community - existing users or those just curious about ASM - to post questions, share ideas, and generally discuss the possibilities and solutions available with ASM.

To learn more about ASM, you can go here. When you combine ASM with other technologies from folks like our friends at White Hat Security, there are some interesting applications and scenarios that will surely spark some interesting dialog.

You know what I like most about this new Forum? Some of the most enthusiastic supporters were actually our own ASM team. They're already active in the other forums, passionate about this technology, and are excited to discuss ASM with the DevCentral community and you.

So, have at it and enjoy.

Filed under the "not necessarily new but cool" category for those that don't know it, you can keep tabs on DevCentral by following us on Twitter. If you're a Twitter fan, you know what to do. Follow us here.

As I was pleasantly reminded by this article, they sold some pretty funny t-shirts back in the day including one featuring "Loser" on the front and back as well as another boldly stating, "Going Out of Business Since 1988". Priceless.

Back to my first point - why I thought this was cool. Something I've always found fascinating about Seattle culture is that it is this blend of driven yet casual people focused on substance (over style, in many cases. See: plaid flannel shirts) and an understated sense of self. Musically, the grunge era was very contrarian, all about the music, not at all about glam, and produced some remarkable work that will withstand the test of time (IMO).  This small label that took a chance turned the music business on it's ear and it actually has a flag flying on the Spaceneedle!

Interestingly, this can-do, contrarian attitude permeates other business and industry here. Starbucks upended the coffee biz. No matter what you think about Microsoft, there's no disputing their role in our world today. Expedia broke new ground in travel. A new round of companies are serving the disintermediation papers to their respective markets - particularly folks like Zillow and Redfin. Waiting in the wings are some compelling startups like Blist and Wetpaint.

(Obviously, I like to include F5 in this mix but I'm pretty biased. We DID, however, pioneer things like load-balancing, Application Delivery Networking, and other patented technologies like cookie persistence. And, there's this thing called DevCentral that was a "first" in our market as well.)

Huh. Nirvana. Starbucks. Microsoft. DevCentral. All in the same blog post... wow. And I didn't even mean to do that.

At any rate, I'll try to get back to my original sentiment. Congrats Sub Pop. Thanks for blowing apart the industry and saving us from further nausea driven by big hair and glam-rock (sorry Don). Your contributions - including your continued inspiration - create the fabric that makes your community unique and impact global.

OK - here's the fun part: who was your favorite "grunge band" of all time? (share your comments below)

Gotta love it! A special shout out to our pal Adrian for sharing this. Thanks mate!

Listening to: "Staple it Together" / Jack Johnson

Today's Flips: My OluKai Kumus.

There was a nice little acronym we used around F5 a few years back (probably more than a few...). However, I was reminded of it today (thanks Annie and Joe!) while walking through the halls. It's simple. And, it's powerful. And, it deserves a "refresh" because there's no hiding from reality: there are more protocols, app flows, user distribution, and complexity challenging IT, not to mention shorter development cycles and performance demands challenging app teams.

The move to TMOS ushered in the opportunity to do this and well. Here's what it means (updated for 2008):

I = Intercept (as in intercept any part of the IP application stream... header, payload, etc.)

I = Inspect (look for cookies, values, variables... anything you want that designates the session)

T = Transform (rewrite to perform proxy functions or other things that fix bugs, simplify design, etc.)

D = Direct (route requests or responses to the best resource, under either LB or persistence, etc.)

Now, in today's world, more applies:

S = Secure (from the endpoint to core, using client checking to encryption and beyond...)

A = Accelerate (making sure that wherever the user is, however unique the application is, or other characteristics that compromise performance - apply intelligently for the best application experience)

Of course, all of these are done to optimize the user experience, server, storage, and application resources so that IT staff and application teams spend on flexible solutions that offer the right fit for today with graceful adaptation and scale as their needs change.

Seems pretty damn prudent and practical to me.

We're lucky. It's rare to find such a team of people like those on the DevCentral team (and F5, for that matter) that are very bright, like to work hard together, and genuinely care about making people's lives better. I've worked with enough people to know that this is special. For me, it's inspiring and I'm proud to be a part of such a dynamic group of people.

However, on a completely different level (and hopefully just a little inspired by the team), our community has become something incredibly special. We continue to be amazed (and frankly, humbled) by the daily contributions of others to the community. Whether it's helpful forum responses, interesting sample posts, or great comments that add perspective to technical articles, it's really very incredible how much the community at large gives back to it's peers.

So, it only makes sense to acknowledge and applaud individuals that make such contributions. Take a moment to check out our "DevCentral Contributors" page. If your name is listed amongst the top-50 - THANK YOU. (If not, don't worry. You can get there too! Read the FAQ to learn how).

Over the coming months, we'll be doing more to highlight the top contributors. We will also provide special opportunities for those that contribute as a humble "thank you" for your ongoing help to others.

A final note: to us, community has always been about you. While we may help keep the site running, provide answers and assistance , and continually innovate in the ways we publish new and interesting info, in the end, it's your community. Without you, there is no community. Thank you and don't be shy about letting us know what you want.

Keep your eyes open for more coming re: contributors...

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?

During an interesting conversation yesterday, Jim Metzler made a very clear and insightful comment. There are [or should be] two distinct roles in IT: application development and application delivery. Pure and simple. In challenging times (or any time, really...), this clarity could be a powerful rallying point as well as a basis for collaboration and focus on results. Good advice. His recently released 2008 Handbook of Application Delivery also offers some excellent advice.

[Update: Kiwi Paul was kind enough to remind me that the handbook link above requires a free registration here. Thanks mate!]

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.

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!)

That unmistakeable sound of Vegas. Combine that with long taxi lines and it must be Interop time again. I'm here in town for a couple days to talk with people, see what's new, and hopefully meet up with any DevCentral members here and shoot some video questions for Joe's DevCentral Daily. I'm on Twitter (JeffBrowning) so send a tweet if you want to meet up. More to come over the next 48 hrs.

I've said foolish things before and I'm 100% certain I'll say them again (anyone that opens their mouth will). And, "foolish" probably comes down to a matter of perspective in many cases.  However, after having our entire team (not to mention our respective families) hit with some nasty cold and flu bugs over the past month or two, this comment sort of strikes me as... well... from a perspective that I can't understand.

"Unfortunately, people have not been getting sick at a rate that we would all like yet." - A.G. Lafley, CEO, Proctor and Gamble (from the 5-Apr Business section of the Seattle Times. It's actually from this article in the Wall Street Journal last week.)

That's unnerving enough. However, change the context of Mr. Lafley's comment a bit and replace "people" with "applications" and "getting sick" with "crashing".

Wow. Either way, I can't fathom it.

Our job, unequivocally in mind, is to help you AVOID problems. We do our best to provide resources to reduce pain, accelerate how quickly you can respond to and heal problems, and most importantly - build a more resilient (and dare I say "resistant"?) infrastructure - to avoid the "nasties" that can sneak up on you when you least expect them.

I feel confident saying this from an IT perspective. I'm no expert on healthcare issues but shouldn't THAT be their perspective, not to mention objective, as well?

Interested in iRules but reluctant to get started? Concerned that your scripting skills are a little dusty... that maybe it might be more work than you're willing to undertake? Never fear. Your community is here.

Don't forget that - thanks to the experts at-large in the community - there are over 80 iRule samples available to help jumpstart your project.

I would be willing to bet significant sums that there is at least ONE iRule sample that may address a challenge you've had on your "fix it" list for some time. And, while the sample may not fit perfectly, it will probably get you... 50%... 60%... maybe even 80-90% of the way to a very workable solution.

Take a peek - the iRule Codeshare is growing quickly. And, be sure to share your favorites as well. The more everyone shares, the more everyone benefits.

BTW - we're working in the "Discovery" conference room in F5's Technology Center today. This cool space is available for you to use to evaluate and test F5 gear, design deployments, and more if you choose to take advantage of it.

However, a few funny things came up:

• "Butter burgers" - According to Don, these are the latest fast food craze in Wisconsin... Wow.
• Ninjas - Apparently this is a popular search term
• You - aside from being the primary reason we do what we do, Colin *may* just add "...and you" in every Tech Tip title he writes moving forward...

More to come...