Loving nginx - but still loving apache

I am now running nginx on my production servers.

Having written a book which features the Apache webserver heavily, a lot of people seem surprised when I tell them I am migrating my work environments onto nginx.

Of course the truth is not nearly as black and white as one product always being better than another; nginx is simply a better fit for what I, and the organization I work for need for the foreseeable future. I believe and practice the philosophy of strong opinions weakly held

We are constrained by computing resource. A lot of this arises from bad choices made by the previous admin and lack of governance. There is no way to sugar-coat or justify the practices which were the norm for a very long time. One of several undesirable outcomes is that the systems are not nearly as efficient as they should be. I still believe you can do more with Apache, but that comes at a slightly higher cost in terms of CPU and memory. Certainly if you don't track what resources are assigned for what purpose, you will never achieve any operational efficiency, regardless what tech you use.

Another major consideration is the availability of skills. I am not the only systems admin in the company, I would rather the systems were maintained by people with strong skills in one product than a competency in lots. Maybe one day tech will be as simple as the sales guy like to pretend, but it looks to me that skills will continue to trump tech for a very long time. But the choice of product does have an impact. While Apache can be used as a forward or reverse proxy, this is not its metier - if I had decided to run Apache httpd as the origin webserver I would have been looking at Apache Traffic Server, nginx or even pound at the front end. Being able to use the same product in both places means less cognitive load.

Nginx (along with haproxy for client side and non-HTTP traffic) provides a powerful toolset for distributing traffic around your infrastructure.

If I'm being completely honest, nginx's lack of functionality also looks like a benefit. The Apache config files for the legacy servers were humungous. And more than half of what they contained should never have been there in the first place: thousands of redirect rules for content which had moved, retired or simply put in the wrong place to begin with. Different ssl configurations for every browser released in the last 20 years. Servers writing the same request to four different log files in different formats which nobody ever read. Despite all this config, it was alarming what was missing - no content caching, no keepalives, no process limits!

That's not to say nginx is easy or minimal in its capabilities. With a syntax which looks very much like C or PHP: blocks bounded with curly brackets: statements ending in semi colons: it is easy to assume that the syntax is procedural. That is not the case. It is, as one would expect without looking at the syntax, declarative. Failing to understand this can lead to problems and frustration.

Another misdirection arising from the syntax is an assumption that the hierarchy of the configuration is merely structural - again not true. Many of the directives are very contextual.

But I do miss Apache's server-status page. Running php-fpm means you still need to worry about concurrent connections but nginx's server status metrics don't show the number of back end connections / where they are connected. Creeping up my todo list is to write something to present useful information about these connections and other metrics on the servers.