|
If you're already using Nginx and its caching subsystem is working for your use case(s), then I wouldn't worry about it. A typical web stack is composed of load balancing, SSL termination, caching and compression, and static and dynamic content serving. Nginx is capable of all these things (including dynamic content serving using OpenResty). Once you start breaking your stack apart to 1) add redundancy, 2) isolate hardware for different workloads, and 3) scale the components independently of each other, the situation gets a little more interesting. Sure, you could run different clusters of Nginx for each of SSL termination, static content, cache and compress, etc. and have them reverse proxy to each other (and some people probably do this), but when you get to this evolution of your architecture, it's worth evaluating the different options for each layer of the stack. There's an argument to be made that e.g. HAProxy is a better load balancer, Nginx is a better static content server, Pound is a better SSL terminator, Varnish is a better caching and compressing reverse proxy, etc. (N.B. that I am not saying these things, I am just saying that they can be said.) If you're not serving static content at all—let's say you're presenting an API written in Elixir/Phoenix—it may not make sense to go with Nginx in the first place! Regarding Varnish, specifically, I've found that it offers unparalleled power and flexibility when it comes to caching and compression. Yes, that power and flexibility comes at the cost of more complexity, but it's there when you need it. It offers different storage backends, including a pure memory backend; the ability to serve gzipped content directly from cache (for supported clients); PURGE and BAN HTTP verbs; synthetic responses; query string sorting; the ability to serve stale content while updating; ESI; and probably a whole bunch of other stuff I'm forgetting and/or have never used. Nginx and Nginx Plus may support some or all of these things, built-in or as modules... I'm not sure. |