DevCentral Top5 6/25/2010

Many happenings abound these days, enough that it's hard for even me to keep track of them all. Amongst them in the past couple weeks have been wicked cool iRules projects, video projects, and likely most importantly of all, the expansion of the DevCentral team. Some of it I can talk about, some of it is still secret squirrel status, but here's what I can tell you for sure: there is no shortage if hawesome stuff to be seen on DevCentral. Here are five things, as a matter of fact, that you definitely shouldn't miss. I give you this week's DC Top5:

 

DC Land Grows by One, A.k.a: Hello World!

http://devcentral.f5.com/s/weblogs/watkins/archive/2010/06/25/hello-world.aspx

It's my great pleasure to give a shout out to George Watkins, the newest addition to the DevCentral team. George may be tfng on our team, but he's no newbie when it comes to this crazy future techno-stuff we like to do around here. His roots are in tech covering the ground of Systems Administrator, coding fanboy, and more recently purveyor of all things good and sound in the world of LTM/GTM for the DevCentral team. As someone I've personally worked with since he started here at F5, I can say I'm quite glad to have scooped him up for the DC team as we'll all be benefiting from the geeky things he'll be brewing up in no time. He's also got a fair amount of knowledge about DC, what we do and how we do it since, well, he's been the guy turning the knobs and pulling the levers on our internal gear for a while now. Those nifty iRules we run on DevCentral to do the whiz-bang cool things? Yeah, he's the guy that's been putting those in place once they pass dev/test. Anyway, head on over to his blog, subscribe, and say hi. I have no doubt you'll be seeing a lot more goodness flowing forth from his neck of the woods quite soon. Welcome, George!

iRules 101 - #17 - Mapping Protocol Fields with the Binary Scan Command

http://devcentral.f5.com/s/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/1084381/iRules-101--17-ndash-Mapping-Protocol-Fields-with-the-Binary-Scan-Command.aspx

So you knew this one was going to be in the Top 5, right? Come on…iRules, obscure commands, in-depth protocol analysis, this has everything but a ribbon and a note saying "here's a gift, feature this in your weekly summary". Jason out-did himself with the research and effort put into this solution. Basically there was an obscure issue with trying to identify certain browser types based on the strength of cipher they allow, and route traffic accordingly to keep certain parts of a site secure. Jason did the leg-work necessary to do the iRule wizardry to make this happen. Of course, it turns out it wasn't needed, but I'll let you read the article to find out why. Regardless, it's a slick example of scanning info to map fields for inspection/decision purposes. All you iRuley types need to check this one out for sure.

Given Enough Standards, Define Anarchy

http://devcentral.f5.com/s/weblogs/dmacvittie/archive/2010/06/24/given-enough-standards-define-anarchy.aspx

I know, I know, standards should help prevent anarchy, the title threw me off too. But as expected, Don delivers as you read through the post and it starts to make more sense. He's referring to the anarchy created by too many conflicting standards trying to control the way your technology, in this case data storage, works. If you have too many people trying to tell you how to do things too many ways, eventually you're not getting anything done, at least not efficiently. I like his idea of starting over and looking at the real world needs and identifying a common mechanism to deliver them. Realistic? Who knows, but I'm hopeful that it will come to fruition at some point or another. Either way, this is definitely a good read to start thinking about some of the things that you might be facing that are sapping the potential efficiency from your operations. Slimming down on the number of control mechanisms in place and standards that must be adhered to because of them might just help you in the short term until the perfect solution presents itself to cure what ails us all.

Automated Gomez Performance Monitoring Part 2 - DataCenter Identification

http://devcentral.f5.com/s/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/1084379/Automated-Gomez-Performance-Monitoring-Part-2-ndash-DataCenter-Identification.aspx

In this post Joe expands upon his cool demonstration of getting Gomez reporting injected in-line via iRules with an example of how to further hone your reporting information if you happen to, like us, be running in a multi datacenter configuration. By using the group identifier, you're able to split out the request traffic in the reporting mechanism so that you can view the requests sent only to a given data center, rather than all requests sent to your application worldwide. This makes it easy to identify datacenter specific issues or, depending on your deployment, view the usage information from different parts of the world if you're splitting data regionally, etc. A relatively simple yet very cool expansion to an already powerful rule, this one deserved to be called out. Take a peek for yourself.

Data Center Feng Shui: SSL

http://devcentral.f5.com/s/weblogs/macvittie/archive/2010/06/24/data-center-feng-shui-ssl.aspx

Last but never least, Lori continues to steadily beat the drum of wicked-cool-awesome-geek topics, covering everything from cloud computing and virtualization to your grandma's home baked cookies and the inherent performance gains they can net you if deployed properly. In her Feng Shui SSL post, however, she talks about virtualization as it pertains to SSL performance. The cries of virtualization everywhere echoing from seemingly every rooftop these days are fantastic to hear, because that's part of what we here at F5 do, and I couldn't agree more that virtualizing things is a fantastic approach most times. That does not mean, however, that there is no longer a need for customized hardware in your deployment. As Lori quite clearly points out, the performance that custom built physical hardware can put out is simply superior in almost every case dealing with SSL. By giving yourself dedicated, additional resources to process cryptography you're taking the load off of the other CPU(s) and allowing them to do what they should be doing in the first place. Rather than tie up the CPU that should be processing your traffic with having it try to run the encryption/decryption algorithms that it isn't specifically designed for, having it run on a purpose built CPU can show dramatic improvements in overall performance. I'm not sure who wouldn't understand that, but if you know someone, show them this post and maybe Lori can help clear it up for them.

Well, those are my 5 picks for the week. Have a good one, and check back soon for more DC Top5 recommendations.

#Colin

Published Jun 25, 2010
Version 1.0

Was this article helpful?

No CommentsBe the first to comment