Hacker News Reader

Comment by stefantalpalaru | Hacker News Reader

> Much of the VCL syntax has changed in Varnish 4.

Bullet, meet foot.

It's not a point release, such compatibility-breaking changes should be expected.

The semantics are completely different which has to be reflected in the VCL. I think keeping compatibility at the cost of sanity is pretty dangerous and disregarding compatibility has been one of the success factors for the Linux kernel.

> disregarding compatibility has been one of the success factors for the Linux kernel

It's actually the other way around. Linus Torvalds dixit[1]:

"One of the core kernel rules has always been that we never ever break any external interfaces. That rule has been there since day one, although it's gotten much more explicit only in the last few years. The fact that we break internal interfaces that are not visible to userland is totally irrelevant, and a total red herring."

[1]. https://plus.google.com/115250422803614415116/posts/hMT5kW8L... - second comment

Valid point and I clearly was under the misconception that Linux didn't care that much about the external interfaces.

However, VCL is more akin the the kernel modules, relying on the internal APIs which are much less stable. When the semantics on how Varnish operates (with 4.0, the backend threads are completely new) and so the VCL language _needs_ to change in order to reflect this.

The external API, made available through HTTP hasn't changed much.

Backwards compatibility is vastly overrated, especially when the changes are as modest as the ones that I can see for Varnish 4. Sweep away the cruft. Make things better.

How many development hours have been wasted because of Python 3, Perl 6, Lua 5.2, any new Django version, Ruby 1.9, Rails 4, jQuery 1.9, Bootstrap 3, etc. ?

Backwards compatibility is as simple as not wasting everybody's time. It should be high on the priority list, right under security and above performance. I like Linus' stance on the issue and I'm sure every developer dealing with syscalls appreciates it as well.

How much development time has been saved and codebase quality increased by making backwards-incompatible changes that improve things drastically? It's a balance, of course – I'm not suggesting old interfaces should be thrown under a bus at the earliest opportunity. But the super-conservative opposite does nothing for progress and ends up with excess technical debt. Varnish 4.0 is a major version release. 3.x still works and will be used by a lot of people for a long time. I really don't see the issue, certainly in this case.

Most of the changes seem to comes from a reorganization of the code, I think they were necessary.

For most users it is a 5-10 minute job, no sweat.

Take a look at the instructions: https://www.varnish-cache.org/docs/trunk/whats-new/upgrading...

Ok, 5-10 min reading it.

5 min writing vcl3to4.pl and 5 min testing it.

5-10 min playing with the new varnishstat.

In total a 30 min job.

;-)

See, it did not take that long:

https://github.com/fgsch/varnish3to4

The biggest impact of these sorts of changes are future users who are trying to get their first configuration going, following various web tutorials. Many of those tutorials are now misleading, but via the nature of accumulated web content it won't be changed any time soon.

Varnish is a nice project, but the lack of SSL significantly restricts its usefulness, especially in the "SSL everywhere" era. I've simply resorted to using nginx' proxy pass as the cache/load balancer.

A lot of the technical tutorials (that also get posted here) are frankly, absolutely terrible.

Tutorials that do not state the required levels of expertise?

Tutorials without version numbers of the components that are described in it?

Tutorials for absolute beginners that feature commands like

  echo 'something' | sudo ...

without explaining them?

Tutorials about using debian-installer without explaining whether locale=en_US will set the system locale during installation to en_US.UTF8 or simply en_US?

In the same vein, tutorials about the installation of Postgres that do not mention that your system locale will impact the encoding / locale of your databases?

Check, check, check, check and check.

Something like RapGenius for technical tutorials might be useful here.

The Varnish authors have specifically stated they didn't want to introduce SSL into their process because of the added attack surface that adds. [0]

If you want SSL for Varnish, use something like Pound [1], stunnel [2], or HAProxy [3] to do the SSL termination and pass it off to Varnish...

I'm partial to Pound because it is lightweight and doesn't try to do any caching, it simply terminates the SSL and passes the request on.

[0] https://www.varnish-cache.org/docs/trunk/phk/ssl.html

[1] http://www.apsis.ch/pound

[2] https://www.stunnel.org/index.html

[3] http://haproxy.1wt.eu

Re: HAProxy

from http://haproxy.1wt.eu : Update [2012/09/11] : native SSL support was implemented in 1.5-dev12. The points above about CPU usage are still valid though.

Wow, I've been out of the loop for a while then. Last time I used HAProxy I was using stud (https://github.com/bumptech/stud) to terminate.

Well, SSL is there, but it is still under development and has yet to hit a stable HAProxy release.

Stunnel has been around doing this job for quite some time as well

It's not either or.

We see lots of our users and customers adopt nginx for SSL termination and as their webserver, but still use Varnish for HTTP caching and/or routing.

The power and flexibility that VCL offers is pretty much unmatched. Specially with the ability to extend the language through Varnish Modules (VMODs). You can see the VMOD directory on our site: https://www.varnish-cache.org/vmods.

Even better, in Varnish 4.0 all Directors are VMODS and they can be nested, basically allowing for dynamic backends and all kind of Layer 7 load balancing you can dream of.

Reply on news.ycombinator.com