CDNs and Varnish Plus - Per Buer talks shop with Bizety

Bizety has just finished another Q&A session with Per Buer, founder of Varnish Software. Varnish Software is one of the leading, if not the leading open source caching platforms used globally, with millions of installations. Recently, Varnish has created a commercial side of the business, where it supports its own software, and has a product road map, releasing features on a regular basis. The Q&A is tailored around the CDN industry. Enough said, lets get started.

This article was originally posted by Bizety - CDN & CyberSecurity Insight

Per, thanks for your time. This is our second Q&A session. It seems like Varnish Software has been very busy lately working on new and exciting features. I can see on your website that you have broken out specific features, and are adding emphasize on their functionality. The features are very CDN centric, and include Mobile Device Detection, API Acceleration, Enhanced Cache Invalidation, and few others. This is great stuff, because you continue to innovate, and make incremental improvements to your CDN caching software. However, this doesn’t look good for Apache Traffic Server (ATS), and makes ATS looks stale by comparison.

You understand what your doing right? Comcast and Apple decided to use ATS to power their CDN. And as Varnish continues to build more features, the CDN teams at Apple and Comcast are regretting their decisions more and more. Varnish Software has a product roadmap, where you roll out new features regularly, and push the envelop as much as you can. I can’t say the same for ATS. I personally wouldn’t recommend ATS for a CDN, as their is no company backing it, no product road map, no one developing features regularly, and no throat to choke in case things start to break down.

Lets get started on the questions.

1. Where will Varnish be in 5-7 years? Think Star Wars. Will your platform be very intelligent, where it can do much more than caching, not only store, secure & deliver data, but have Splunk like capabilities where it can make decisions in real time when serving content?

The first thing I think of is edge-side content transformation. This is of particular interest for CDNs as retransmitting the same content in two different forms is obviously wasteful and has a clear cost associated to it. Today the most obvious waste we see is in video distribution. People might transmit the same video, encoded in the same format but wrapped in different transports. This is obviously wasteful and it is probably not rocket science to get Varnish to dynamically change from one container to the other.

Similarly we could see doing other transformations on the edge. Watermarking video, having session-specific DRM, optimizing HTML and Javascript are all relevant examples.

The next guess is I think Varnish will open more up. Having Varnish look up content in a database or request it directly from a Java application server will probably happen. On the client facing side I expect there will be some standardized way to do SSL. Hopefully the world has figured out SSL in the next 5 years. If the IT industry can’t figure out that I’m quitting the whole thing and going full time beer brewing.

2. What are some of the trends you are seeing CDN caching world?

Varnish is getting some pickup, that is obviously one which we’ve seen. We also see more and more multi-CDN strategies at our customers.

A lot of the CDNs we’ve talked to have also balked at the tight vertical integration that many of the CDN solutions vendors are offering. Of course we probably haven’t talked much to the ones that actually like tight vertical integration. These solutions tend to lock customers in quite a bit as migration from such a solution is pretty hard.

3. What does Varnish Mobile Device Detection do?

It looks up the device from which the request originated in the DeviceAtlas library. It will return a host of data about the device. Software and hardware capabilities.
The most basic use is to figure out whether we are talking to a phone or not. In a more advanced use case you could use it to detect the display density and the size of the device display and making sure the images are appropriately scaled. Combining this with functionality such as GeoIP you are able to do quite a bit of content customization on the edge.

4. What is Varnish API Acceleration?

The last couple of years APIs have exploded and they are facing the same scalability issues that websites had a few years ago. Most of them are solving their scalability issues by horizontally scaling their server farms. In a lot of situations one can deploy caching in order to speed up the API and improve scalability of the API.

Our Varnish API Acceleration toolkit provides a lot of tools to help scale APIs. It is mostly about authentication, authorization, metering and throttling. As with a lot of what else we do with Varnish it is about moving functionality to caching layer. Everything you move into this layer runs a couple of hundred times faster than on your application servers so the gain is obvious.

5. What is Varnish Enhanced Cache Invalidation?

Phil Karlton once said, “There are only two hard things in Computer Science: cache invalidation and naming things.”
Enhanced Cache Invalidation is our implementation of Surrogate Keys for Varnish. The idea is that you can use any arbitrary string for cache invalidation. You can then key your cache on product ID or article ID. So, when you update the price of a certain product the cache will know all the pages that reference this particular product and will evict all of them from cache.

6. Tell me the things you don’t like about Apache Traffic Server, and be brutally honest?

As a Varnish Software employee we don’t really get to work much with ATS. We are stuck with Varnish Cache for all our projects. The only time we have something to do with ATS is when a client is migrating. Usually this would be because they have had a less than optimal experience or that they are the kind of website where Varnish makes a lot more sense than ATS. So our experience is pretty limited but we have some.

As I said earlier there are lots of things to like about ATS but the thing that I think is somewhat of a turn-off is the configuration. A more or less clean debian installation of ATS has around 8500 lines of various stuff in it’s configuration directory. I understand that a lot of this is embedded documentation and that I shouldn’t take it all in at once but I believe there is a value in starting with something simple and add complexity as you need it.

The other thing I dislike is the absence of something like VCL. Once you get used to it it is hard to work with systems that won’t offer the same flexibility. I think the ATS team is working on something that would grant ATS something similar and I’ll be very curious to see what will come out of this effort.

Would you like to hear more from Per and Varnish Software? Leave a comment below or register for our upcoming summits.

This picture is (c) Esparta Palma 2008 and used under CC License