If you just want to stick up for your "favorite" PHP
framework simply because it's the only f**king thing
that you know, then go f**k yourself with a hand grenade.
There are very good reasons I am advising you not to write
new things in this f**king completely broken piece of shit,
and security is only one of them.
My bullshit detector is going off so loudly, I think I best go lie down.
At my last company, we paid for a Zeus ZXTM license (which was an excellent product and very expensive for our little startup), and they didn't approach the level of arrogance here. The varnish guy is kind of opinionated, but he's got the chops to back it up, and you can, y'know, look at the source.
An obvious benefit of open source is also that if I take a large risk of running my business on your oddball web server and you get hit by a bus, I'm pretty much hosed. I'd rather buy 4 additional servers and run nginx than take that risk. Or, y'know, use a CDN.
Whatever, if the developers really are THAT much more skilled and their product is so far and away better than every other solution out there, then they should really hire someone who knows how to do marketing and PR properly, because they're not doing themselves any favors.
I like the way Zeus deals with their performance claims: you can test it, but you can not disclose the results. The same crap as Microsoft used to do. Although I did sign up for a trial, I didn't bother going further after reading the EULA. Long story short: nginx is powering our servers right now, without any need for changing the platform.
We needed load balancers and at the time, the choices were ZXTM, ServerIron (which I'd used subsequently, and am very grateful we didn't pick) or F5. We'd had a truly terrible experience with an F5 reseller so we decided to meet with the Zeus guys. One really attractive option at the time was that they would provide us a solaris build of their software (we were a Solaris 10 shop), and we could run it on our own hardware, which was much better provisioned than the comparable F5 hardware at the time.
All of that aside, the motivation was that by using a product, instead of rolling our own solution, would be more maintainable, and we'd have a support contract. Compared with the mod_rewrite mess we had, ZXTM was a huge improvement. Plus we got stats, graphs, IP failover that worked flawlessly, active/active configuration sync, and a webui that made it so people who weren't intimately familiar with the config syntax of a variety of disparate services could perform fairly complex tasks (like A-B builds).
I mean, we also paid for Cisco ASA 5550s as a firewall/VPN solution for many of the same reasons. It all came down to what we wanted to spend our time engineering and what we could get management to spend money on. :)
Seconded. Ruby has tons of syntax and is a much more complicated language to learn than Javascript.
Also Rails is non-trivial these days. I picked up rails back in pre-1.0, and followed it closely until around 2.3. It's way more nuanced than it used to be, and I'd imagine someone could find it very difficult to "pick up."
Ha! Fair point. I thought it was an interesting trial in that all updates to our user data wound up being published into MongoDB. All the other tools we'd tried for this purpose, CouchDB, MySQL with both MyISAM and InnoDB and even "thousands of .js files in a hashed directory structure" didn't perform as well. It allowed us to shift the load from our MySQL database to "something else" as during our spikes we were getting killed. It was a read-heavy workload in that case.
The thing that struck me about the original post was how it seemed some of the complaints were just normal things that people learn when dealing with clusters under load. "Adding a shard under heavy load is a nightmare." Well, I mean, duh. If you add a shard and the cluster has to rebalance, you're adding load. It's like how you're more likely to get a disk failure during a RAID rebuild. The correct time to add a shard is during the off hours.
