Slashdot Mirror
F5 Fires Back On Open Source SSL Accelerator
Random Feature writes "In response to Build an Open Source SSL Accelerator, in which o3 magazine detailed how to build a solution comparable to an F5 BIG-IP 6900 on the cheap, F5 Fires Back claiming it's not as cheap as it appears and pointing out the potential performance implications of a 'cobbled together set of components designed to mimic similar functionality.' The discussion on the performance of the Open Source solution based on Opteron RSA operation processing capabilities brings into question the validity of the 'more SSL TPS for cheaper' argument presented by o3."
Try protobalance.com
Finally, someone who isn't a raisin sack aptly describes all of FOSS:
'cobbled together set of components designed to mimic similar functionality.'
The F5 load balancers we have (admittedly not the newest) are just standard ATX & PCI off the shelf products and BSD.
Shilling much?
If you cannot keep politics out of your moderation remove yourself from the Mod Lottery.. NOW!
Obviously any company selling "integrated solutions" will say otherwise.
Where is the total non-story tag?
Why would they actually respond to that article, from what it appeared to me the general mood on /. was that it was neat but would be more trouble than its worth.
At the risk of being flamed as a troll and getting modded to hell, I'd like to point out that F5's response is exactly the same kind of thing one hears when comparing special-purpose (or custom-written) software to the integration of COTS applications, libraries or frameworks. Sure, with the latter option you get something that works, eventually, but at what cost to maintainability and performance?
I say this after coming out of a meeting where a large Rube Goldberg system of Java tools was presented as the best solution to a high-volume ETL problem that has particular performance and distribution requirements. The resemblance is uncanny.
I'm all for not reinventing the wheel, but if that's what is required, then just do it.
Finally, someone who isn't a raisin sack aptly describes all of FOSS: 'cobbled together set of components designed to mimic similar functionality.'
Ah, FOSS may be cobbled together at times, and it also may be as polished and clean as many commercial apps, but it still does not erase the bottom line that F5 is still charging an asinine amount of money for their hardware. And in this economy, the financial bottom line tends to speak volumes over F5 coming out and trying to justify their price tag with a weak "yeah, but yours sucks" argument.
This reminds me of my first time opening up the lid on a $30,000 Nokia Firewall-1 rack-mount firewall "appliance". They wanted to sell me a $2000 "upgrade". When I slid the mobo out of the fancy chassis, I found I was staring at a generic Intel mobo with a slot-1 celeron proc and 64MB of SDRAM. I then found out that the $2000 "upgrade" was merely a Pentium Proc and 256MB SDRAM stick. Needless to say, I've been rather tainted with justification for commercial hardware.
You must be smart when buying stuff like this.
First off, if I'm handling 25k+ SSL TPS, point blank, I pay the money for an F5. A home built solution will only get you fired when something goes seriously wrong.
Secondly, if an F5 is out of your budge and you aren't handling 10s of thousands of SSL TPS, look elsewhere. Kemp Technologies makes a solution that support up to 10k SSL TPS for less than half the price and even cheaper if you handle even less. If you're not even handling a thousand of TPS, let your Apache servers handle SSL and be done with it.
I'm a huge fan of chaining proxies, one program doing one thing then passing it on to the next, for the security, compatibility & debugging (contrary to what TFA say's you can check the pieces of a chain, but with an integrated solution you can't) benefits. The article does however raise a good point, the integrated solutions will have better performance:
# TCP connection setup and teardown processing
# Inspection of application data (layer 7 inspection is rarely computationally inexpensive)
Which means you'd have to consider the options carefully when looking for an accelerator
IranAir Flight 655 never forget!
You must be smart when buying stuff like this. First off, if I'm handling 25k+ SSL TPS, point blank, I pay the money for an F5. A home built solution will only get you fired when something goes seriously wrong.
I agree you must be wise with your purchases. At times, commercial hardware is justified. That being said, the entire point of the original article was to prove that there's NOT THAT much magic behind F5 hardware to justify the price tag. Accelerating SSL isn't rocket science, nor is it some uber-secret. The main point here was an attempt to prove the FOSS can and will do exactly what commercial software and hardware does at a micro-fraction of the cost. As I've said before, in this economy and shrinking IT budgets, I'm finding it harder and harder to justify uber-elite solutions with obscene price tags.
Hi, Peter. What's happening? We need to talk about your SSL TPS reports.
Let me first state that I over see a large deployment of F5 systems and I have compared commercial offerings in this space many times over the years. I have a deep understanding of the tools available and see the work product every day.
Both articles are great for debate. Showing that FOSS and tools available could produce a solution that resembles a commercial product is wonderful in promoting the power and breadth of FOSS. F5's response is good but also a bit disappointing as I find they have much more than is covered in their response.
I'm honestly surprised that F5 responded at all as there's really no comparison between the solutions for real world work loads and support. First and foremost is the thought that these are only load-balancers. The term used most appropriately today is "ADC" (Application Delivery Controller). The reason is that they not only perform load-balancing but reverse proxy cache, compression, acceleration, tuning, and in-stream logic decisions.
F5's products allow you to create profiles for services that are reusable and easy to maintain. You can deliver new configurations in minutes. They also work with the major application vendors to produce proper configurations that you can use out of the box. iRules (TCL) is an awesome tool directly integrated into the product that as F5's tag line says, "With iRules you can". Even with all of the this power and robust tools you will see little or no impact on high performance applications.
F5 also offers the community DevCentral which, in my opinion, gives back to the community in a proper FOSS style.
I won't even go into the underlying architecture such as the TMM kernel and separate management kernel.
F5's article does state one thing very clear and I would want to emphasis it. Humans cost far more over time than capitol expenditures.
I believe that F5 has taken FOSS to proper pedestal in the industry. If anyone thought for one second that FOSS was toys and not to be considered for serious work loads then F5 proves them wrong. Cisco has been trying to chase F5 for years and are still nowhere near them. F5 systems are my swiss-army knife of networking and I'm proud to purchase and use them from my FOSS background but also know they save my butt every day.
Is there any reason you couldn't put an SSL accelerator on a USB device? Lots of servers have a ton of unused USB ports sitting around. If you could make it USB, you wouldn't have to rip open the web server/reverse proxy server to install it. Sure somebody might walk off with the device, but if you can mitigate that somehow, is there anything technically wrong with the idea?
First off, if I'm handling 25k+ SSL TPS, point blank, I pay the money for an F5. A home built solution will only get you fired when something goes seriously wrong.
An old boss has spent the last FOUR WEEKS with F5 and Cisco trying to figure out why their F5 load balancer starts dropping ACKS on the floor...at connection rates well under advertised capacity of the particular model in question, which has been in production use for months/year+. How the fuck about that- a load balancer that craps out...under load. How useful. The bug is triggered daily when this particular unnamed CA major internet company hits peak usage in the day.
At least with the open source community, you can hire someone to look at the code, or report the bug and try and get it fixed by the community. F5 has been completely useless, reportedly.
Please help metamoderate.
Oddly enough, F5's reply missed the one bit that is their strongest difference and the one bit I was disappointed to not see in the original article, namely offloading the SSL to the NIC. This really comes down to a scaling issue. It costs to service interrupts copy data up to user-land, do the ssl, block on write, copy it down, catch another interrupt, .... So what tends to give out first using 'plain old nics' is the kernel io and process swap times. Now you might say, "go scale it horizontally and keep the cheap hardware". But how are you doing that? Put it behind a load balancer? Well if the LB has SSL acceleration (and don't they all) then why not just do that. Now maybe you can dodge that a bit with some round robin DNS or similar. But in the end you want a single entry point that scales. Really you want a HA clustered entry point that looks like a single entry point, which would be the next issue I'd have with the solution proposed by o3.
I'm not saying that o3's idea doesn't have some merit on the low end. But its not an apples to apples comparison with a BigIP. And it would be possible to do an open source, home brew system that did hardware SSL acceleration and supported HA clustering, and is a fairer comparison. That a project like that would have been a heck of a lot more interesting. And that that's kind of what I expected from the term "Open Source SSL Acceleration."
Interesting. We use perl scripts and Pentaho to do VERY high volume ETL. One could argue it's a bit Rube Goldberg, but it also works without a hitch, and software cost us $0.
If you want to improve raw SSL performance, you can use a specialised SSL card. I had the opportunity to play with a card made by the company Dajeil ( http://www.dajeil.com/ ). They accelerate RSA, docs say it does "1,500 2048-bit (or 11,000 1024-bit)" RSA TPS. I tested it and the numbers were not inflated. I don't remember exactly how many 512-bit TPS it had but it was probably above 50kTPS. I tested it in a regular Dell desktop, I'm not even sure the CPU had more than one core. They provide a modified openssl library so it works fine with linux. It's been almost 2 years since I had it so maybe they use the newer openssl engine interface (I had problems getting it working with apps that were compiled against a different version of openssl). With a working openssl library, anything that is dynamically linked against it is automagically accelerated, which includes apache's mod_ssl and I assume nginx too.
As far as I remember it cost less than 2k EUR, which is next to nothing for that kind of performance.
> F5 is still charging an asinine amount of money for their hardware
Actually, you are paying for the software. Plus support. documentation, etc, that is generally OK. If your IT staff is an army of untrained contractors and support contract administrators it is probably worth it.
But then in a past job I had to stand at attention in front of the CEO and answer the question "WHY THE FUCK DO WE HAVE THESE F5 DEVICES?", and "Because our CIO likes them?" is not really a good answer in a situation like that. So - Am I biased? A tad!
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
[ I'm no f5 fan but they're right.. reposting my comment from the last thread: ]
Hmm, why no mention of nginx's thread limitations? By design, nginx does not use threads and as a result has performance issues scaling beyond one CPU or core. Those limitations will become apparent on certain real world workloads and with realistic tests. Those are important issues and this piece, like many nginx discussions, glosses over them. It also disingenuously tries to compare nginx to commercial solutions.
I like nginx a *lot* and have tested and deployed it in many different situations. But it is not always the best choice, and in some cases is a poor choice.
When I rolled out some new nginx services 6 months ago, nginx was only being developed by one person. Again, not a showstopper for everyone but it would be for some.. and Very worth mentioning in an article that compares nginx to commercial solutions. Nginx is great at some things but it is still maturing.
Everything made today is a "cobbled together set of components." The chips come from Taiwan or Korea or Germany, the plastic from China, the metal from the USA or pretty much anywhere else...you name it. That's why we have standards - so you can replace one part with another.
The difference is in the quality of the cobbling.
And the final proof is in dollars per something-or-other, engineering aside. In this case SSL throughput. Let's see some benchmarks and let's see some dollar signs. Then we'll decide what's useless and what isn't.
Weaselmancer
rediculous.
Why even bother with SSL? If your main audience is the web crowd, you can simply use something like aSSL [http://assl.sullof.com/]. Then transfer statically encrypted content via http. This does work for most but not all. I know I'll get flamed to death, but I just filed for a patent that addresses the Achilles heal of aSSL - man-in-the-middle attacks.
If a site is big enough that it really needs the performance/scale of such an F5 appliance, then the price tag is not that great and likely reflects .001% of the IT budget or less. Some shops will be better served with the cheap OSS solutions, and others would blow one up fairly quickly. If you blow it up fairly quickly and the $50k price tag is also hard to justify, then your cost of doing business is severely out of whack.
Simply enough, they're firing back because with the popularity of slashdot, now every time some manager goes to scope out Big-IP or their 6900 the slashdot discussion and the original project will rise to the top of the search results.
Big IP isn't worried about this home grown solution, because in the end, businesses buy warranties, maintenance and upgrade paths. Something the FOSS solution doesn't have prepackaged.
Enjoy o3's article; it's a great project. Have fun building it, but don't take offense at Big-IPs defense of their product; they're obligated.
The best thing to take away from all this, if you're in the market for SSL offloading, is to print out the article and slashdot discussion, pass it to the check-writer and let her use it as leverage to get an additional 5% savings off list.
is it just me or does this post sound like a bunch of corporate QQing?
Turnaround time for serious bugs is *incredibly* fast.
Uh huh. After being given pcap files/traffic graphs/response time graphs, F5 said it was a known bug and fixed in a certain release.
So they did an upgrade through change control, rolled it out. Absolutely no difference. That's when F5 started claiming that it wasn't their fault.
The interesting bit is that the bug very closely resembles a 1-2 year old FreeBSD bug...how about that, huh?
Please help metamoderate.
The guy from F5 is a jackass. He basically turned what was a reasonable article that did no bashing of their products into a big deal. He rehashed all the tired old arguments against open source software "Single vendor" "support" "Admin overhead" .... blah blah blah. We know! We've heard it all before..
F5 makes great devices but not everyone can afford them, so this article showed how you could achieve most of the same results with open source software. I've used the BigIP and I liked working with it. Very cool, very flexible devices. Unfortunately, only one out of the last 5 companies I've worked for were able to actually buy one.
SO, you can put together a solution that doesn't MIMIC the BigIP. It can actually do the same things. Might not be as pretty, but it will work.
There's going to be some people that think twice about F5 because of this nonsense. I mean, what kind of company lashes out like this for no reason? It makes them sound like crybabies.
Lower your prices or shut up about it. If you charge $50,000 for a server that can be had for $5000 minus the F5 software and people are buying, then they really don't have anything to complain about. The people the original article was targeted at were not likely to be potential F5 customers.
- It's not the Macs I hate. It's Digg users. -
That almost proves it's something else. Or is your hat tinfoil? (Cuz the nearest FreeBSD code is probably on a mac up in the marketing department ;)
cbreaker,
The 6900 does not have a white box hardware equivalent. You will just have to take my word for that.
Much more importantly that duct-taped baby is NOT actually doing the same things. The fact that seemingly intelligent people in the /. community don't grasp that might be why this person decided they needed to rebutt the article
Oh and btw you're so totally busted- we all know you didn't even read the blog or you would know that LORI isn't a GUY. :)
They used to use freebsd for the management console, before switching to linux. But they run some propritary os for the actual loadbalencing & what not. Wouldn't think it would be a freebsd problem, but who knows there might be some bsd code in the custom os as well.
I did read it. I didn't pay attention to who wrote it. Sue me.
I didn't have to read every detail because I'm already familiar with most of that software.
You obviously have a predisposition against open sourced software solutions because of your derogatory statements like "duct-taped baby."
It's semantics. Okay, so under the hood it works differently. But the net result is similar with a full solution (not just the SSL accelerator part) - load balancing, offloading, caching.. If you wanted to, you could even put together a DNS failover system in it too. (I always hated the 3DNS though..)
Personally, I'd go with a more simple solution based on Squid if I needed something to do many of these things and I couldn't afford a BigIP (which most organizations can not) but Squid won't do everything either.
Besides, what do you think F5 does? The operating system is Linux and they use a lot of open source code in their systems. They just "duct tape" things together better.
- It's not the Macs I hate. It's Digg users. -
I sort of understand your point they may have given mor ecredence to the critisism than if they had just ignored it. But seriously, you cannot create a device for $5000 that does everything a Big Ip does. Maybe, you don't need everything the Big Ip does. I do understand why people are protesting their protest, there are crappy solutions from vendors that can be replicted or bettered for a fraction of the cost ( see the KEMP boxes). F5's just happen to be a great solution that does pretty cool things. If you've ever been in a serious data center, then you'd see the F5's every where. People buy them because they are awesome. Are they over priced? Tough to say. It sort of reminds me of where software was in the early 2000's. When, Microsoft Office was the undisputed necessary solution, despite the cost. And Windows 2000 was the best desktop OS, despite the price. Maybe at some point OSS will be able to replicate the Big IP, but its not there yet. Check back in another 5- 10 years.
The writer of the article response to Lori's claims
http://o3magazine.blogspot.com/2009/04/ssl-accelerator-strikes-nerve-with-f5.html ...and nails her on a few I'd say.