3 ms·
It's a good product for what it does -- I've rescued more than one site using it -- but the politics behind it have always been a little weird. Some of it is su
by tacos 12y ago
It's a good product for what it does -- I've rescued more than one site using it -- but the politics behind it have always been a little weird. Some of it is subtleties of Danish culture and humor not coming through.
But if you're actually running Varnish the way he'd like you to, chances are something isn't quite right with your architecture. Poul-Henning has strong opinions on everything from virtual memory to life on Mars and I really don't need that stuff to be part of my web stack.
A little personal maturity to match the product maturity would help both advance.
- phkamp 12y agoI have opinions on life on Mars ?
- stephenr 12y agoHow is TLS Termination/load balancing > caching proxy > Apache/nginx/whatever "something wrong with your architecture"?
- tacos 12y agoObviously depends on the "apache/nginx/whatever" side, especially if "nginx" can do everything varnish does in your scenario and moreso when "whatever" includes in-app caching and load balancing strategies. Varnish grew legs as part of saving the clusterfuck that is WordPress. Custom cache rules up a layer from a broken old code base is AWESOME. Maybe also a red flag.
- simonw 12y agoRefusing to use a piece of software because the author has "strong opinions" seems very strange to me. Most of the best software I use is "opinionated" in some way. The trick is to pick software whose opinions best match your own.
- tacos 12y agoActually the trick is to pick software that meets the needs of the technical problem at hand. Getting a read on where the product is headed -- by being aware of corporate motives or by reading developer's ranty blog posts -- can be part of the strategy. Percival, Torvalds, Fried -- I kinda know what to expect from them moving forward. This guy is playing a similar game but not doing it right.
- stephenr 12y agoI agree with what you said about picking the right tool for the job, but I don't see how he's "not doing it right" I 100% agree with the view that caching and tls termination/load balancing are two different tasks, suited to two different tools. The stated reason for this approach is keeping the existing excellent solution, from becoming worse without any real gain. Yes the author has stated views about the use of tls "everywhere" - specifically because varnish doesn't handle tls, those opinions don't affect the tool at all. Edit: s/told/tls/ damn you autocorrect!
- tacos 12y agoI'm all for reducing complexity but ignoring the bigger problem so you can focus on a smaller one isn't necessarily the path. Customers are trying to solve a pretty basic, common problem here. I don't see how a ranty, opinionated position paper moves anyone closer to the finish line. All it did was further influence my opinion of where Varnish would likely be in five years. While I appreciate the candor I'm not sure he did himself any favors.
- phkamp 12y agoI have a really hard time following your argumentation, because it seems to have very little to do with both reality and what I wrote. What I did WRT moving people closer to the finish line was to implement the PROXY protocol, so that using a(ny) preexisting and well-tested SSL-termination solution works seamlessly with Varnish. IMO, that is a far superior solution to adding a lot of security critical code to Varnish which, at the end of that huge effort, doesn't work any better. As I wrote in my piece: "the world really don't need another piece of code that does an half-assed job at cryptography" And doing a full-assed job only makes sense if you have the resources, competence (important with crypto!) and the result makes a positive contribution, one way or another, which offsets the cost of its production. Nobody has yet been able to point out what the positive contribution would be, compared to a solution where SSL termination is its own layer. Do you know something about that which I don't ? If so, please share...