Traditionally Varnish have had the concept of active and inactive
loaded VCLs. Any loaded VCL lead to state being kept, and a separate
set of health checks (if configured) were being run against the backends.

To avoid the extra state and backend polling, a loaded VCL is now either
warm or cold. Runtime state (incl. backend counters) and health checks
are not present for cold VCLs.

A warm VCL will automatically be set to cold after vcl_cooldown seconds.

Before Varnish 4.1, backends could only be declared in native VCL. Varnish
4.0 moved directors from VCL to VMODs, and VMODs can now also create
backends. It is possible to both create the same backends than VCL but
dynamically, or create backends that don't necessarily speak HTTP/1 over
TCP to fetch resources. More details in the Writing a Director
documentation.

Backend connections will now be closed by Varnish after backend_idle_timeout
seconds of inactivity.

Previously they were kept around forever and the backend servers would close
the connection without Varnish noticing it. On the next traffic spike needing
these extra backend connections, the request would fail, perhaps multiple
times, before a working backend connection was found/created.

Varnish has an ecosystem for third-party modules (vmods). New since
the last release, these are worth knowing about:

libvmod-saintmode: Saint mode ("inferred health probes from traffic") was taken
out of Varnish core in 4.0, and is now back as a separate vmod. This is useful
for detecting failing backends before the health probes pick it up.

libvmod-xkey: Secondary hash keys for cache objects, based on the hashtwo vmod
written by Varnish Software. Allows for arbitrary grouping of objects to be
purged in one go, avoiding use of ban invalidation. Also known as Cache Keys or
Surrogate Key support.