Not really at small scale, but if you're building a large service there are several advantages.
For one thing, not having to copy response data between processes improves throughput. Since Varnish is so resistant to supporting SSL natively, you'll always have to place something in front of it to use it with the modern web. Whether it's haproxy, Apache or nginx, that's just one more thing to deal with.
I have some other beefs with Varnish, but the most annoying one is the absence of a persistent disk cache. If the Varnish process dies, there goes your disk cache. Even though cache data is written out to disk, Varnish punted on saving an index and re-using an old process's cache, so it writes the cache to an unlinked file.
Imagine a bad code push or new traffic pattern that causes core dumps across your entire service footprint -- and now it isn't just a problem of getting the process back up and stable, you have also lost hundreds of terabytes of cache data. Or something as simple as rolling out a new version. You can architect around the problem, but why should you even have to?
ATS also (recently) supports Lua for plugins, which is way more powerful than VCL. It is a finicky piece of software though, and there are a lot more sharp edges that you're likely to cut yourself on during the initial honeymoon period versus Varnish.
Varnish (just like Nginx) is putting key features behind a paywall. That's one of the reasons I personally want to consider Traffic Server. Plus, it's been around for ages, has a great architecture, and a great track record as well. All it needs is a little more awareness and that's why I keep posting it here. :)
I sympathize with the authors of Varnish and nginx; their software is used all over the place, and they want to make a living at it. I just don't want to support that kind of business model, and I'm never dealing with per-server license compliance again.
I wish more companies would model themselves after Percona: charge for support, custom engineering and on-call -- don't fork or paywall any code.
ATS suffers by comparison, since there is no "ATS Inc." to provide support and engineering work. There's OmniTI, but I don't have first hand experience with their service to say if it's worthwhile or not. They did get paid to write the current ATS docs, so presumably they know what they're doing.
I wish ATS got more attention, but it is after all a bit of a niche product hidden away in the Apache Foundation with a bunch of unrelated Java projects. It's too fiddly for small scale use, and once you hit large scale you're pretty much hiring someone from Yahoo or elsewhere that has experience running and developing it (for example: I'd like to hire ATS people). Doesn't give it a lot of opportunity to trickle into smaller shops and grow with their service.
There are right and wrong ways to monetize. Putting basic features behind a paywall and per-server licensing as you pointed out is not something I can live with. Even if I don't use these features, I feel I'm using a subpar product, and this makes me look for alternatives such as ATS and H2O [0].
I disagree that it is not expensive. If you're launching a single instance then yes, it's tolerable: $0.21/hr or $1839 per year (very similar to their non-AMI pricing). Anything is tolerable at a low scale.
Now think about services that use nginx on every machine as a general purpose URL API interface. It's not uncommon, why bother re-inventing the HTTP server wheel. At a previous company, a service I ran would have cost $3.6 million a year in nginx plus licensing fees. Almost none of the added 'plus' features would have been at all useful.
If you see nginx plus as a way to pay for the core software then sure, maybe that cost is appropriate. I will not support them with per-server licensing of gated off features. Oh and by the way, nginx plus is closed source and is only available on a small handful of platforms, and doesn't always maintain the same release schedule as the open source version, all as a way of supporting their licensing scheme.
I would support nginx via professional services and support fees, but only in conjunction with the open source release. So it's up to them if they want that money or not.
Let me ask you this, most of the "premium" Nginx Plus features are specific to load balancing. You shouldn't need more than 2 or 3 load balancers right? I.E. load balancer in each availability zone or multiple regions? Beyond that use Nginx open source. This is exactly what I do.
I get what you're saying, but now you have two divergent nginx releases to maintain. nginx plus isn't simply nginx with an extra module, it is closed source and on a separate release train.
For instance, the last nginx plus release (R8) is based on nginx 1.9.9 (plus was released 40 days later). The previous is based on nginx 1.9.4 (plus was released 25 days later). It isn't a matter of life and death, but it is an annoyance and unnecessary.
At least with Varnish Plus, it's still the same open source server with proprietary modules added in. I understand that nginx wants to go that route eventually, but they're hamstrung by the lack of dynamic module loading for the moment.
Apache Traffic Server has support for native C++ plugins which allow you to make transformations to the headers and the body as the request and response passes through it. ATS's power comes mainly from these plugins, I would say, rather than just a reverse caching proxy.
Huh. You could conceivably replace ISA/TMG (Microsoft Forefront) with ATS. There are still places using those products as load balancers / reverse proxies even though support is almost completely gone.
