NGINX Plus Review

Extremely efficient in terms of the connection rate to the CPU cycles ratio


What is our primary use case?

In my architecture (which is a microservice architecture with some special advances), NGINX serves multiple purposes. Namely:

  • Application Gateway with an application-level firewall tool and load distributor & balancer (also serves for A/B testing).
  • Rate limiter and bandwidth limiter (session-based).
  • Source of real-time logs, consumed by intrusion detection system.
  • "Circuit breaker" for the whole complex of microservices.

No other tool can compare to it.

How has it helped my organization?

I have never seen a single case where programmatic tools can change an organization. Tools are not subjects. They are passive objects. Organizations and people are subjects. Tools are just reflections of the organisation and people. Tools mirror people's faces and habits, never vice versa.

What is most valuable?

NGINX is extremely efficient in terms of the connection rate to the CPU cycles ratio, and in terms of the bandwidth to CPU cycles. It is configurable enough so smart engineers (which team consists of) can configure virtually anything which a product manager (say "business") is able to imagine. Even more because business does not always know all the quirks of DevOps and operations.

What needs improvement?

I am not so happy with their pricing policy, but this is not the worse thing in my life. I can tolerate it.

For how long have I used the solution?

More than five years.

What do I think about the stability of the solution?

Stable as a rock. On the stable host OS and stable hardware, your connectivity channels will be saturated (and dead) long before NGINX will mention any difficulties.

What do I think about the scalability of the solution?

No scalability issues at all. Just add more horsepower to the VM. Horizontal scalability also works well, but you definitely need an engineer who knows how to do this and is ready to take his/her part of the responsibility. 

How are customer service and technical support?

I've never asked for anything. Everything was done in-house.

Which solution did I use previously and why did I switch?

Before NGINX, there was Squid. I have been using NGINX since its arrival on the market.

Squid is a tool of a different age, from a different (previous) generation. I started using Squid many years ago, from its pre-release beta. It was a good tool for its time and purpose: just caching proxy, which allows you to somehow save on traffic and bandwidth. At these times, the web was mostly static so it worked.

Later, both the capacities of the channels had grown 1,000-10,000 times from megabits to a 10th of gigabits per second. The web moved to mostly dynamic content, so caching proxies lost their appeal.

On the other hand, NGINX is mostly an application level gateway, not a proxy per se. It is a different tool for different tasks.

How was the initial setup?

Get a real good engineer who will do this for your business. I did, and I am happy with it.

What about the implementation team?

Only an in-house team was in the game for implementation. I doubt that the vendor has enough engineers of this level available for assigning them to the kind of customers that we are.

What was our ROI?

Who calculates "ROI" for every single component of a large system with more than 100 components in it? 

The whole system brought ROI even better than what was expected.

Which other solutions did I evaluate?

There were not any other real options. 

Squid is too heavy. Apache in reverse proxy mode is also over-bloated, resource hungry, and not suitable for the task.

What other advice do I have?

NGINX is the best available tool today for the tasks it covers.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Add a Comment
Guest
Sign Up with Email