To my surprise earlier today Lori Macvittie a Senior Marketing Employee of F5 Networks decided to resort to personal attacks. The effort appears to be an attempt to pull into question the authenticity of the Building an SSL Accelerator article I wrote last week. See I wrote a technical article that was designed to help make the technology accessible to anyone who needed it. My take on it was look, a high priced device such as those F5 sell could be the difference between some poor IT employee getting laid-off or the network not having the resources it needs to function. So why not offer a solution that the IT employee can implement themselves?
Seems Lori had a problem with a PR announcement made yesterday from an Open Source Startup company that I co-founded called Carbon Mountain. See that company announced yesterday a solution that obsoletes Application Delivery Controllers by moving the network intelligence to the hypervisors. However the solution is very powerful enabling load balancing between physically separate hypervisors using industry proven technology. So now F5 are attempting to pull my integrity into question.
Lori makes a few comments on her site that are borderline slanderous and without basis. She claims that the SSL Accelerator solution I wrote about is in the product announced by Carbon Mountain. She has no knowledge of the product, as those details are kept very securely within the company. The SSL Accelerator solution I wrote about is *not* in the product at all, in fact the product works by eliminating the need for a box in front of the server farm in the first place, we do something far more clever.
Whats very interesting is that after I pointed this out to Lori, my comments were deleted / never posted to her blog, and she has yet to retract her false statements. What Lori doesn't want her customer and potential customer base to find out is that the published results are the maximum possible results for her product, real-world network environments, with varying packet sizes, fragmentation and other aspects, will actually drag down the performance. You can see this from some of the comments posted to both slashdot posts from real F5 customers!
Now I have nothing against F5, I couldn't care less if they sold a million more boxes or one more box. Its very obvious to me now that I struck a never, and potential F5 investors and customers may want to rethink doing business with a company that cannot hold a technical argument against a small FOSS project, and has to resort to personal attacks, and even then ones based on false accusations.
Thursday, April 23, 2009
Saturday, April 18, 2009
SSL Accelerator strikes nerve with F5..
Earlier in the week, I released an article on how to build an SSL Accelerator using Open Source components. Now SSL Accelerators are expensive network devices, so there is a price-barrier to deploying the technology that I felt could be eliminated by using Open Source. I'd like to thank everyone for the great comments, and especially the folks that suggested using VIA hardware as an option to do cheap line-rate encryption. I'll be placing an order for some VIA hardware next week, and once we get a chance to do the testing, we'll post the results.
Now I compared the solution to a mid-range solution, thats quite pricey from F5 Networks, one of the leaders in the field. Now I compared the performance of one of their products to the Open Source solution running on hardware that costs less than 10%, just as a comparsion. I had assumed that most professionals would have figured out I was comparing it as a reference point, but I guess it struck a nerve with some folks at F5, and sent their media / blogging engine into overdrive.
You can find their response here.
The response was posted by Lori MacVittie, who is a technical marketing employee at F5. Lori is pretty new to the game of Application Delivery / Layer 4-7 switching, she has only been at it according to her Linked-In profile since October 2006. On the other hand, I've got over 11 years experience in this particular area, not to mention I've racked up quite a few wins against F5 over the years, so the usual marketing stuff just won't fly with me like it does with some unsuspecting customers! :)
So the solution I mentioned in the article is just Nginx, had she read the article, should would have realized that I suggested HAproxy and Varnish as ways to enhance high availability, but Nginx can do this very well on its on. It makes no sense to utilize Apache in the mix, as Apache and Nginx do the same thing. So the first point she made was that chaining proxies would introduce so much latency that the performance gains from using Nginx to offload SSL would "almost immediately (be) lost" when multiple proxies are chained together. This is an assumption she made, not something she tested. So we tested it! :)
Nginx -> Varnish -> HAproxy introduced a small amount of latency per transaction, but that is to be expected. The enhanced I/O capabilities of Nginx, along with the benefits of caching the objects intelligently with Varnish would result in many requests simply never reaching HAproxy as Varnish returns the requesed object. The latency you would experience with the egress of the packet from the F5 device to the server to retrieve the object is far greater than the latency you would obtain from bouncing the packet internally within the Linux networking stack.
The F5 solution does not have the capability to cache objects on the device, so based on a typical production site the F5 solution suffers from far greater latency, as not only does it have to manipulate the packet, ditch it onto the wire, have the TCP setup / tear down done on the server, the server to pull the object from local storage, and then sent back to the F5 device.
She claims that L7 is expensive, sure it takes extra processing, but if you read the article, you'd see that I drop hints that Nginx has a very superior way of handling I/O. L7 inspection is expensive, but no more so than on the F5 box. She even admits that transfer of data between proxies is minimized when running on the same device (which is the way I suggested you do it). As for the multiple log files argument, please, have you not heard for rsyslog or splunk? :)
Her compression argument is a joke, while I didn't spell it out in the article, Nginx supports ways to support context-awareness, via mime-type, extension, you name it, if you can regex it, Nginx can process it! Thus you can make decisions on what to compress and what not to compress. In fact, Varnish does an excellent job of deciding what to cache and what not to cache. I suggest she does a little more research next time! :)
Her security points are a joke, and clearly she does not have an understanding of what you can do with Linux. Without getting into it too much, you can easily utilize tc for a start to prevent SYN Floods and basic DDoS attack protection. Nginx can be configured with a variety of security options to protect your data, I don't see F5 having the capability to restrict access to objects when the referrer isn't your own site! There are a wide variety of strategies you can use to protect against ARP poisoning and cookie tampering as well. As for hardened security platforms, I would be willing to bet the platform the o3 website is running on uses less space and is more secure than the Linux platform F5 is running. No sign of the source code being offered by F5, are they in violation of the GPL here???
My personal favourite is that she quotes a 3 year old article to try to claim that the Opteron can handle "around 1500" 1024-bit RSA operations per second, I don't think she understands what is written in that report, as she has mis-quoted it, and picked a report thats over 3 years old. Lets play far shall we, I know marketing people are used to trying to skew reports, but you try that with me, I'm going to call you on it. Yet we have a running test that shows that machine is handling requests on-par with the F5 solution.
The solution that the article provided was intended to make the technology more accessible to companies that couldn't afford solutions such as what F5 has to offer. It was never intended to pitch a like for like comparison. The fact that F5 appear to be somewhat defensive about the solution, and the fact that the only arguments they could come up against it were weak and full of holes, suggests that we struck a little close to home for them.
Polishing the solution suggested in the article may take a few days to a few weeks, depending on how good your IT team is, but Nginx is a solid platform, I'm an experienced Senior Software Engineer in this space, and I can tell you the Nginx code is not just robust, but some of the decisions they've made are very impressive. As I said in the article, the solution doesn't provide all the bells and whistles, but if you are looking for the core technology in a robust and cost-effective solution, it makes sense to give it a try before handing over cash to companies like F5.
Ironically, her closing arguments talk about application performance, maintaining the solution and troubleshooting. The funny thing is, that its often easier to find configuration errors by diffing what you've changed in the configuration file, instead of something you might have accidently clicked on through a GUI. The multiple log files, actually give you a frame of reference for which component might be experiencing a problem. Plus if there is a code problem, with the open source solution, you are not dependent on a product manager at F5 to determine how important your problem is, or if it will even make it into an upcoming release. You are in control. Either way, the long-term cost savings, assuming your network scales up, grows exponentially with your open source investment. You don't have to sacrifice project roll outs because you cannot afford the additional F5 box or license key this quarter!
If you need to get from A to B, sometimes the kit-car solution you've built yourself is not only cheaper, but you know how it works, and you don't have to shell out to the mechanic every time something goes wrong. So while it might not have the status-symbol of a $50k car, you've tweaked and modded it so you can beat that $50k car off the line. As you watch the $50k car from your rear view mirror, and smile, imagine how the guy who doesn't know as much but just can afford the $50k so doesn't know any better feels as his heart sinks watching you peel away! :)
I'm sure thats a feeling several F5 customers might be having right about now! :)
Now I compared the solution to a mid-range solution, thats quite pricey from F5 Networks, one of the leaders in the field. Now I compared the performance of one of their products to the Open Source solution running on hardware that costs less than 10%, just as a comparsion. I had assumed that most professionals would have figured out I was comparing it as a reference point, but I guess it struck a nerve with some folks at F5, and sent their media / blogging engine into overdrive.
You can find their response here.
The response was posted by Lori MacVittie, who is a technical marketing employee at F5. Lori is pretty new to the game of Application Delivery / Layer 4-7 switching, she has only been at it according to her Linked-In profile since October 2006. On the other hand, I've got over 11 years experience in this particular area, not to mention I've racked up quite a few wins against F5 over the years, so the usual marketing stuff just won't fly with me like it does with some unsuspecting customers! :)
So the solution I mentioned in the article is just Nginx, had she read the article, should would have realized that I suggested HAproxy and Varnish as ways to enhance high availability, but Nginx can do this very well on its on. It makes no sense to utilize Apache in the mix, as Apache and Nginx do the same thing. So the first point she made was that chaining proxies would introduce so much latency that the performance gains from using Nginx to offload SSL would "almost immediately (be) lost" when multiple proxies are chained together. This is an assumption she made, not something she tested. So we tested it! :)
Nginx -> Varnish -> HAproxy introduced a small amount of latency per transaction, but that is to be expected. The enhanced I/O capabilities of Nginx, along with the benefits of caching the objects intelligently with Varnish would result in many requests simply never reaching HAproxy as Varnish returns the requesed object. The latency you would experience with the egress of the packet from the F5 device to the server to retrieve the object is far greater than the latency you would obtain from bouncing the packet internally within the Linux networking stack.
The F5 solution does not have the capability to cache objects on the device, so based on a typical production site the F5 solution suffers from far greater latency, as not only does it have to manipulate the packet, ditch it onto the wire, have the TCP setup / tear down done on the server, the server to pull the object from local storage, and then sent back to the F5 device.
She claims that L7 is expensive, sure it takes extra processing, but if you read the article, you'd see that I drop hints that Nginx has a very superior way of handling I/O. L7 inspection is expensive, but no more so than on the F5 box. She even admits that transfer of data between proxies is minimized when running on the same device (which is the way I suggested you do it). As for the multiple log files argument, please, have you not heard for rsyslog or splunk? :)
Her compression argument is a joke, while I didn't spell it out in the article, Nginx supports ways to support context-awareness, via mime-type, extension, you name it, if you can regex it, Nginx can process it! Thus you can make decisions on what to compress and what not to compress. In fact, Varnish does an excellent job of deciding what to cache and what not to cache. I suggest she does a little more research next time! :)
Her security points are a joke, and clearly she does not have an understanding of what you can do with Linux. Without getting into it too much, you can easily utilize tc for a start to prevent SYN Floods and basic DDoS attack protection. Nginx can be configured with a variety of security options to protect your data, I don't see F5 having the capability to restrict access to objects when the referrer isn't your own site! There are a wide variety of strategies you can use to protect against ARP poisoning and cookie tampering as well. As for hardened security platforms, I would be willing to bet the platform the o3 website is running on uses less space and is more secure than the Linux platform F5 is running. No sign of the source code being offered by F5, are they in violation of the GPL here???
My personal favourite is that she quotes a 3 year old article to try to claim that the Opteron can handle "around 1500" 1024-bit RSA operations per second, I don't think she understands what is written in that report, as she has mis-quoted it, and picked a report thats over 3 years old. Lets play far shall we, I know marketing people are used to trying to skew reports, but you try that with me, I'm going to call you on it. Yet we have a running test that shows that machine is handling requests on-par with the F5 solution.
The solution that the article provided was intended to make the technology more accessible to companies that couldn't afford solutions such as what F5 has to offer. It was never intended to pitch a like for like comparison. The fact that F5 appear to be somewhat defensive about the solution, and the fact that the only arguments they could come up against it were weak and full of holes, suggests that we struck a little close to home for them.
Polishing the solution suggested in the article may take a few days to a few weeks, depending on how good your IT team is, but Nginx is a solid platform, I'm an experienced Senior Software Engineer in this space, and I can tell you the Nginx code is not just robust, but some of the decisions they've made are very impressive. As I said in the article, the solution doesn't provide all the bells and whistles, but if you are looking for the core technology in a robust and cost-effective solution, it makes sense to give it a try before handing over cash to companies like F5.
Ironically, her closing arguments talk about application performance, maintaining the solution and troubleshooting. The funny thing is, that its often easier to find configuration errors by diffing what you've changed in the configuration file, instead of something you might have accidently clicked on through a GUI. The multiple log files, actually give you a frame of reference for which component might be experiencing a problem. Plus if there is a code problem, with the open source solution, you are not dependent on a product manager at F5 to determine how important your problem is, or if it will even make it into an upcoming release. You are in control. Either way, the long-term cost savings, assuming your network scales up, grows exponentially with your open source investment. You don't have to sacrifice project roll outs because you cannot afford the additional F5 box or license key this quarter!
If you need to get from A to B, sometimes the kit-car solution you've built yourself is not only cheaper, but you know how it works, and you don't have to shell out to the mechanic every time something goes wrong. So while it might not have the status-symbol of a $50k car, you've tweaked and modded it so you can beat that $50k car off the line. As you watch the $50k car from your rear view mirror, and smile, imagine how the guy who doesn't know as much but just can afford the $50k so doesn't know any better feels as his heart sinks watching you peel away! :)
I'm sure thats a feeling several F5 customers might be having right about now! :)
Wednesday, April 15, 2009
New Article: Open Source SSL Accelerators
There is a new article available now on Open Source SSL Accelerators. SSL Accelerators are typically pretty pricey devices requiring complex embedded hardware that off-load the SSL public key encryption. o3 has been using an Open Source solution for SSL Acceleration since 2007, so we felt it was about time that we shared the wealth of knowledge. Testing shows with the right Intel or AMD hardware, this solution with about $5k worth of hardware can out-perform F5 Networks Big-IP 6900 which carries a price tag in excess of $50k. While not as polished as the commercial options, the Open Source SSL Accelerator does get the job done!
Sunday, March 29, 2009
Slashdot strikes, o3 doesn't even flinch
Last week we kicked off our o3 magazine relaunch with article mentions in LXer.com (our Intro to Open Source article) and in Slashdot (our URL Length article). It was interesting to see how much of a debate something pretty simple actually caused. One of the goals (aside from getting the word out about the return of o3, and to spark some interesting debate) was to actually test our infrastructure against a good slashdotting, especially with our upcoming article series on Zero Day Attack Protection in Linux. I was very impressed that our entire infrastructure didn't even flinch at what Slashdot through at us. I spoke with Ryan over at Pro OnCall, and he was expecting to see a spike in bandwidth utilization, but our site is so well optimized, he merely saw a slight increase in bandwidth! Nginx performed extremely well, so all in all, it was a good test, our infrastructure didn't sweat it, and we're ready for primetime!
Thursday, March 26, 2009
o3cast.tv goes live
Very pleased to announce that o3cast.tv is now live. The site adds video to our portfolio of sites at o3. The idea behind o3cast.tv is to provide a mix of interesting Open Source related video, as well as video screencasts that extend our articles at o3magazine.com. I eventually decided to roll with a YouTube integrated solution, you can check out the site over at www.o3cast.tv and our YouTube page over at http://www.youtube.com/user/o3magazine. I opted for YouTube instead of trying to integrate video from multiple sites, as YouTube provided a fairly useful management interface. As you can see from the main page, we've got the o3cast.tv videos split into four categories. On the top left, we have Interviews, on the top right we have Presentations, on the bottom left we have Screencasts and finally on the bottom right we have Tutorials.
Tuesday, March 24, 2009
o3 status
I have been working hard on getting o3 ready for launch. The new web-based version of the magazine is now on-line, the o3 news service has been going well for over a month now, and the o3 wire service is picking up traction. The o3 events service I have started pushing this week, and we hope to sign up as many Open Source events as we can over the next two weeks. Tonight we will be polishing o3cast.tv and getting it ready for launch. We have some interesting things in the works, including some additional services for business, integrating Google Translate and more. So stay tuned. Later next month, this blog will start to be used for editorial pieces. So stay tuned!
Sunday, February 22, 2009
Integration of greybox
Just wrapped up the integration of greybox into the new o3 site design. Greybox (smart window) is an open source javascript project that provides a very slick way of displaying content without navigating away from the site. The idea is based on the popular technique used by Lightbox, Thickbox and many other interesting projects. Greybox goes a little further, providing a rich and elegant user experience, in a lightweight javascript package.
For o3, it solved a number of problems, it enables us to allow the user to view external links without navigating away from the site itself. This enabled us to put external links for news headlines and the news wire, while minimizing the risk that we could drive traffic away from the site. It enabled us to improve the rich user experience for o3 news, and is the backbone of our o3cast.tv site, enabling users to quickly browse through different videos without having to browse to and from the site.
I'd like to personally thank Amir Salihefendic, for such an awesome LGPL'd project! To find out more about Greybox visit http://orangoo.com/labs/GreyBox/.
Subscribe to:
Posts (Atom)
