This is cool stuff. Tony Bourke of LBDigest blog, list, and fame has started a Wiki dedicated to load balancing, the heart of the application delivery network.
As Tony mentions in his blog post announcing the wiki, it’s a work in progress, but there are already some cool items out there, particularly the discussion/description of different load balancing architectures.
All I can say is where was this kind of technology/help back in the day when I was beating my head against walls trying to learn all this stuff.
Great stuff, Tony!
Yesterday KEMP Technologies announced an update to its LoadMaster application delivery solution. With the announcement and new support for application delivery focused features such as advanced caching, compression, and intrusion prevention, KEMP brings capabilities usually reserved for higher-end solutions such as those from F5, Citrix, and Radware to the SMB (small-medium businesses) market. KEMP has added these features to its platforms at no additional charge.
Yaphank, N.Y. – June 16, 2008 – KEMP Technologies, a leader in datacenter application delivery optimization for small-to-medium sized businesses (SMB), today announced new advanced caching, compression and intrusion prevention system (IPS) features for the complete line of LoadMaster Application Delivery Controllers (ADC) and Server Load Balancers.
The LoadMaster product family is highly affordable, yet feature-packed. As with all of KEMP’s products, the caching, compression and IPS features are built-in at no additional cost. These new features continue KEMP’s advancements into the ADC marketplace, adding to the already feature-rich capabilities that include Layers 4/7 load balancing, content switching, IP and Cookie persistence, integrated ASIC-based SSL acceleration, and full layer 7 support for Microsoft Windows Terminal Services. KEMP Technologies continues to offer all of these enterprise-class features at a price point tailored for SMB businesses.
The inclusion of an IPS in its LoadMaster product would appear to be squarely aimed at competing with other SMB focused application delivery networking products such as Barracuda’s Load Balancer, which includes a built-in IPS as well. The other well-known players in the SMB load balancing/application delivery market, Zeus Technologies and Coyote Point, have yet to jump on the integrated IPS bandwagon. Unsurprisingly, this type of consolidation is something larger competitors do not appear interested in, which may reflect the differences in size/skills sets - and budgets - of IT in the target markets.
The LoadMaster IPS architecture leverages the hardware-based SSL acceleration that is integrated with each appliance. This enables application-layer threats that arrive via HTTPS (SSL) to be quickly detected, with the same performance as applications that arrive via HTTP.
With a rule-based engine designed to import security rules in the industry-standard SNORT® database format, the LoadMaster IPS provides KEMP customers with complete flexibility and vendor independence in forming and maintaining their security policy. There is no recurring fee associated with the LoadMaster IPS engine. Prebuilt rulesets in the Snort® database format are available from SourceFire and other third-parties under a number of free and/or fee-based licensing schemes. These user-readable and user-editable rulesets can also be customized to extend the capabilities of the LoadMaster to mitigate threats specific to custom web applications.
The new features are available now.
It’s kind of sad, really. I remember the first time I saw what would become Juniper’s DX line in the Network Computing Lab in Green Bay. It was an interesting device, still evolving. It certainly wasn’t as feature-rich and mature as similar products from F5, Citrix, Radware, and Cisco that it would eventually compete with as part of Juniper’s product lines, but it was interesting nonetheless. The guys running Redline had passion for their product and the market, and you couldn’t help but feel excited around them. And then Juniper snatched them up, ditched most of their management and executives, and suddenly, poof! The product is being discontinued. And now it’s really gone. Partially subsumed into other products, partially left to die by the side of the information superhighway.
Juniper announced its intentions to leave the market, but had not given official direction to customers regarding load balancing/application delivery in the future. According to SOA Network Architect, Juniper has officially begun to certify what used to be competitors’ application delivery controllers as replacements as products of choice for its customers in need of load balancing/application delivery solutions.
Customers looking to replace Juniper DX load balancers/application accelerators after they are discontinued later this year will have to look to other qualified vendors, Juniper says.
The company announced end-of-life for the boxes earlier this year but didn’t issue formal notice about what customers should do if they want additional DXs in the future.
Now the head of Juniper’s enterprise gear says that the company is qualifying other vendors’ load balancers as replacements. "That means we tested it and we know it works," says Mark Bauhaus, executive vice president of the company’s service-layer technologies division that handles the DX.
Bauhaus says Radware and F5 gear has been qualified, as well as others he did not name. Other vendors, including Zeus Technology and Crescendo Networks, tried to lure DX customers away with special deals.
Juniper says it decided to get out of the load-balancer business because DX wasn’t the top seller in the market and that it would be tough to move up. "One of these things is just like the other," Bauhaus says.
The last days to buy a DX are June 30, July 1, July 7 and Sept. 15, depending on the model. Juniper says it will support the devices for five years after the date they are discontinued.
Bauhaus says other Juniper gear already has the capability to load balance built in, such as its secure access and WAN acceleration gear, and this will be added to other products.
Alistair Croll over at Gigaom had an interesting dissection of Amazon’s recent outage and an interesting deduction based on the facts regarding what went wrong. He mentions as part of that process that the load balancer’s "apology page" failed to be displayed.
No load balancer that I know of has a configurable “Apology page” when all real servers in the pool are unreachable. To the load balancer, the apology page would be seen as another active server and added to the rotation along with the normal httpd servers. Most of the time maintenance pages are manually brought up and down by the administrators.
Ahem. Excuse me, Mr. John Adams (the reader who left the referenced comment) but modern load balancers, which are now known as application delivery controllers, most certainly do have the means to provide "apology pages" when all real servers in the pool are unreachable. This technology has been available for many, many years now, and is not something new. Perhaps the load balancers you are familiar with do not have this capability, but organizations such as Amazon and others who have high volume and depend on availability of its web applications all employ application delivery controllers capable of displaying apology pages - and a whole lot more, including retrying servers, verification of responses, etc…
Now, whether Amazon had configured its devices (which do have the capability, by the way) to show an apology page or not is another matter. But the feature is available in all modern load balancers (application delivery controllers) and should certainly be used by any organization to ensure that total failure of all applications don’t result in a similar situation as Amazon just experienced.
It seems like such a waste, doesn’t it? You purchase a redundant pair of load-balancers and deploy them in a traditional active-standby configuration on the off chance that one of the primary might fail and you’ll need that secondary device.
So you decide to go with an active-active configuration instead. You’re getting the most out of your investment, both devices are humming along, load balancing requests. Good times for all. And if one fails, the other will take over, so no problem, right?
But as time goes on your traffic increases, pushing each of the boxes over 50% capacity. And then "it happens". One device fails, and the other is left trying to handle more than 100% capacity. Obviously, it doesn’t work and you’re left holding the trouble ticket and the phone, at the other end of which is an angry upper management type - or worse, an executive - who is adamant you fix the problem NOW or else.
In an environment in which we’re trying to conserve energy (green IT) and drain every last drop of capacity out of the equipment we have because our budgets are limited, we’re likely tempted to do things that we know might not be the best option. But we’re constrained by factors that lie outside our control so we often end up doing what we have to instead of what we know is best.
But while I am generally against an active-active configuration because of the potential for disaster, there may be an option that allows you to take advantage of active-active without sacrificing the insurance that comes from a redundant pair.
Buy "bigger" boxes.
Yes, that’s right. Anticipate that your traffic will grow beyond 50% per box and buy the next larger, higher capacity device. This preserves the protection in your investment intended by the purchase of a redundant pair in the first place, but lets you use both now in an active-active configuration without worrying too much that losing one will mean losing traffic - or customers.
A friend sent me this NYT article describing the difficulties women are still having in high tech.
First of all, the fact that it’s in the "Style and Fashion" section just blew me away. What’s up with that? It’s high-tech and women, not the politics inside American’s Next Top Model (do not say a word that I know about this show, I have a teenage daughter. nuff said)
This tidbit from the article stood out
My big question would be, "What is geek culture?" and why is it a problem for women? Or better yet, why is it "unsupportive" of women?
The answer might be found in the interactions of "geeks" and "girls" in high school. Attending a mandatory meeting on a club trip to Europe with my teenage daughter shed some insight into this problem. I was trying to pick out the one boy she claimed was "cute" and instead ended up focused on one, lonely teenage boy trying hard to fit in and failing miserably. The other boys ignored him completely, this sad young man with glasses, fairly neat clothing, and a leather jacket. It’s as if geeks have some kind of recognition program running because I knew he was "a geek" even though he certainly doesn’t fit the stereotype of the hygiene avoiding hacker some like to present. I have never met a geek that fits this description. When you find one, please point him out to me, I’d like to meet him, just to say I have. Kthx.
But just in case, I asked my daughter, who confirmed that yes, indeed, that boy was a geek. The way she said it indicated disdain and irrelevance, a dismissal of his very existence. After all, he’s just a geek, her tone of voice implied. As if we don’t, I mean he didn’t, have feelings.
Young men who grow up being ostracized by not only their peers, but young women, grow up with a chip on their shoulder toward both groups. They don’t know how to treat and interact with women because they’ve never been given the opportunity to do so. It’s like that every young woman they try to interact with treats them with disdain. It’s not surprising, then, that they would grow up into men who just aren’t comfortable with women and don’t understand the need to be "supportive" and treat them with consideration.
Now I’ve been in high-tech all my life. My mother was a COBOL programmer, I started out my career as a C/C++ developer and moved on to high-tech and the fast-paced world of application delivery a few years later. I have experienced sexual harassment, been offended by the men I work with at times, been excluded from team-outings because I was female. (No, thanks, I do not want to go to Hooters for a team lunch.) I feel I’ve had to work twice as hard and be twice as good as my male counterparts in order to succeed, and sometimes - only sometimes - that irritates me. But in general I’ve never considered leaving high-tech because one - ONE - guy was a jerk once in a while. Did it irritate me? Yes. Did I want to leave high-tech because of it? Heck no. Because most of the time I’m working with men, the percentage of those that are actually jerks is probably right on par with the percentage of jerks out in the general population. Jerks are everywhere, in case you hadn’t noticed, it’s not like high-tech is the only place they exist.
But if does cause other women to consider leaving, then I say we have to teach men how to act. And the best time to do that is when they are learning to interact with women and learning how to treat them. And that’s when they’re young, in high-school.
The only way these young men are going to learn how to interact with and treat women is to actually be around them! That means, girls, you’re going to have to participate.
That’s right. To change the culture that is allegedly pervasive in high-tech today you’re going to need to date a geek in high school. Give him the chance to interact and learn how to treat women. How to see them as equals and not as "that group of people who laughs at me, derides me, and treats me poorly."
You see, karma says that what goes around comes around. And it’s quite possible that the poor reception women get later in life from "geek" men is karmic justice for their treatment of young men earlier in life.
So change the culture of high-tech, date a geek.
During my many years at Network Computing Magazine, hanging out in the lab and evaluating application delivery controllers, among other things, I can definitely appreciate the difficulty and intense work that goes into trying to evaluate application delivery infrastructure in as real an environment as possible.
This Network World article has some good advice on how to get started stress testing application delivery devices. It isn’t very in depth, but it is a good place to start if you’re trying to figure out how to build a test to stress out your delivery infrastructure.
Based on my experiences, a few other things you should take into consideration when building out your plan…
1. Your clients are not going to be connecting over the LAN. Link speed, specifically the speed at which data can be slurped off the device, makes a difference in capacity of the device. Whatever tool you’re using (I’ve always been a huge Spirent WebAvalanche fan) make certain that you set your client for an appropriate speed and that you simulate a variety of network conditions that can affect the length of sessions such as packet loss and congestion.
2. Your servers, if they are simulated by a tool, shouldn’t serve content instantaneously. They take some time to process and spit out that content, so be sure to configure your simulated servers with an appropriate amount of latency to simulate a real environment.
3. Your simulated content should be as realistic as possible. You can’t properly simulate and from the results predict the capacity and performance of your entire infrastructure if your simulated content consists of 1 HTML page with 10 objects but your real content is much more complex.
Happy Testing!
This announcement at first left me speechless.
MAHWAH, New Jersey, May 13 /PRNewswire-FirstCall/ — Radware , the leading provider of integrated application delivery solutions for business-smart networking, today announced that it has joined the Juniper Networks J-Partner Solutions Alliance Program. The interoperability of Radware’s AppDirector application delivery controller and the Juniper Networks Secure Access SSL VPN appliances and Unified Access Control (UAC) solution provide customers with a more comprehensive application delivery solution.
Then I started thinking about it and realized that this partnership actually makes a great deal of sense.
Juniper has "left" the building in terms of application delivery, recently ditching its DX line of application delivery controllers. Radware, while strong in the European theatre, has always had a lackluster presence in North America in its marketing, sales, and channel.
This partnership gives Juniper a fairly strong portfolio of application delivery solutions to pitch, and gives Radware a strong partner in the North American theatre through which it can attempt to expand its market presence. Radware gets to fill out its application delivery network with Juniper’s Secure Access SSL VPN appliances and Unified Access Control (UAC) solutions while Juniper gets to replace its application delivery core functionality with Radware’s APSolute line of products.
Hmmmm….not so crazy after all.
The potential impact of Cisco AXP and Zeus’ ZXTM 5.0 Java extensions on the application delivery market
Consider this quote from Star Trek: TNG, when Gowron (leader of the High Council and, by extension, the Klingon Empire) is arguing with Captain Picard over Gowron’s desire to execute Kahless, the legendary (and believed mythical) ancient leader of the Klingon empire:
Have you ever fought an idea, Picard? It has no weapon to destroy, no body to kill. The idea of Kahless’ return must be stopped here. Now. Or it will travel through the Empire like a wave… and leave nothing but destruction behind.
Ideas, and therefore possibilites, are incredibly difficult to combat. That’s because they don’t exist in meat-space, they are merely potential products, waiting to happen. And when a vendor announces a product that is basically comprised of ideas, it’s problematic to combat. The emphasis necessarily shifts from comparing features and functionality to selling people on the possibilities; on the idea rather than anything in reality.
Application vendors understand the value of ideas, frameworks, and of possibilities. They understand that customers are willing to invest in the ability to bring their ideas to fruition. Because application vendors’ products are often extended, customized, and heavily modified to suit the unique needs of an organization, they understand the potential of ideas and how powerful they can be in terms of competitive advantage.
It would be easy to dismiss these offerings from Cisco and Zeus because nothing exists right now and therefore should have no real impact on the application delivery market.
That could not be further from the truth.
What Cisco and Zeus are offering are platforms for ideas, and the ability to take those ideas from possibility to reality. That’s what the most successful application vendors offer (IBM, Microsoft, Oracle, BEA), a mechanism for bringing to life ideas. If Microsoft or IBM announced a new application server platform, you can bet it would not be lightly dismissed by Oracle and BEA. Platforms for building out ideas are powerful tools. That’s what F5 has long offered with iRules and iControl, and what Citrix, Cisco, Juniper, and even Nortel now offer with their integration and management APIs. The ability to apply fine-grained control over application data in the network changed the rules of the game five years ago and upped the stakes dramatically. It’s no surprise that a recent startup in the space, A10, recognized that F5 had set the bar high in terms of this type of “idea enabling” technology and implemented similar technology.
Now it’s Cisco and Zeus upping the ante by opening up the idea of a platform to include a lot wider array of applications and integration opportunities. It’s the idea that’s a powerful catalyst for change in the market, the possibilities; a tangible, finished product is unnecessary because the mere idea can be much more powerful.
When Koroth created a clone of Kahless in his laboratory he understood this concept. He brought to life an idea and it immediately became a threat to the High Council. In the end, Kahless becomes the Emperor of the Klingon Empire, with all others bowing before him. A figurehead, but a powerful figurehead nonetheless.
It is important to note, however, that they did not bend knee to the man, but the idea of the man.
That’s what should make Cisco’s AXP and Zeus’ ZXTM 5.0 Java extensions a “disturbance in the force” of the application delivery market. (I can too mix my Star Trek and Star Wars metaphors, at least they’re the same genre!) These ideas certainly won’t leave behind them nothing but destruction, and they won’t take over the “empire” of application delivery. But they will be a catalyst for change and innovation in the market, as Kahless was for the Klingon Empire, and change can be A Very Good Thing.
[Developers, web and network admins are meeting to discuss the delivery of: The Application]
Elrond (CIO): The Application cannot be properly served Gimli, son of Gloin by any one sikill that we here possess. The Application was made to run on the Internet. Only there can its purpose be fulfilled. It must be delivered near and far and it must be made to be secure and fast.
The Application: Ash Nazg
Elrond (CIO): One of you must do this.
<Dead silence from all teams>
Boromir (Security): One does not simply serve applications on the Internet. Its routes are watched by more than just script kiddies! There is evil there that does not sleep. And the great keyloggers are ever watchful. It is a barren wasteland. Riddled with hackers and malware and malicious code! Peering points are as black holes. Not with ten thousand men could you do this. It is folly!
Legolas (Developer): Have you heard nothing Lord Elrond has said? The Application must be delivered!
Gimli (Network Admin): And I suppose you think you’re the one to do it?!
Boromir (Security): And if we fail, what then?! What happens when hackers take what is not theirs?!
Gimli (Network Admin): I will be dead before I see the network befouled by a developer!
<Commotion starts as arguments erupt amongst the team members>
Gimli (Network Admin): Never trust a developer!
Gandalf (Business Owner): Do you not understand that while we bicker amongst ourselves, our competitors’ advantage grows?!
<Frodo is reading marketing material from an application delivery network vendor>
The Application: Ash Nazg Durbatuluk! Ash Nazg Gimbatul! Ash Nazg Gimbatul! Ash Nazg Gimbatul!
<The intensity of the arguments increase. Slowly, understanding dawns on Frodo’s face. He stands and takes a few steps toward the arguing teams, trying to make his voice heard above the din>
Frodo (Application Delivery Architect): I will do it! I will deliver it!
<The argument dies down. Gandalf closes is eyes as he hears Frodo’s statement. The members of the teams slowly turn towards Frodo, astonished>
Frodo (Application Delivery Architect): I will deliver The Application and make it safe, fast, and available by building an application delivery network. Though– I will need some help from each of you to do so.
Gandalf: <walks towards Frodo> I will help you bear this burden, Frodo Baggins, so long as it is yours to bear.
Aragorn (Web Admin): If my experience can help you, you may have it. You have my web servers.
Legolas (Developer): And you have my application.
Gimli (Network Admin): And my network! <looks grimly at Legolas as he joins the group>
Boromir (Security): You carry the quarterly bonuses of us all on your shoulders. If this is indeed the will of the business, then security will see it done.
And thus was born the application delivery fellowship. A cross-functional team dedicated to delivering fast, secure, and available applications to users wherever they may be.
[Notice, ironically, that Gandalf – the business owner – offers nothing but words and direction to the effort. How apropos of reality. ]
Well, maybe it’s not that easy, but hopefully you get the point. Application delivery requires cooperation between a variety of teams, all with specific skills that, when combined, form the basis for complete application delivery. That’s why when we start stalking about application delivery networks we necessarily require multple functions and feature sets. While there are many application delivery controllers, the heart and soul of the application delivery network, there are very few complete application delivery network solutions out there. You either have to build them in a best-of-breed methodology, in much the same manner as the fellowship was built, or put your faith in one, single vendor to provide everything necessary.
Regardless of how you put together the actual application delivery network, you’re still going to need to get folks on the application, security, and network sides of IT to work together - or at least talk once awhile.
Hey, if an elf and a dwarf can learn to work together - and even enjoy doing so - then application and network and security folks can, too. After all, at least we’re all human beings.
Yes, that includes the business folks as well.
The inability to play is a sign of poor mental health.
– Hara Marano
