Apache, nginx and HAProxy are by no means the only solutions we could use. There are many projects available and making a choice is harder than ever.
One of the open source projects worth trying out is lighttpd¹²⁸(pron. lighty). Just like nginx and HAProxy, it was designed for security, speed, compliance, flexibility and high performance. It features a small memory footprint and efficient management of the CPU-load.
If JavaScript is your language of preference, [node-http-proxy] could be a worthy candidate. Unlike other products we explored, node-http-proxy uses JavaScript code to define proxies and load balancing.
VulcanD¹²⁹is a project to keep an eye on. It is programmable proxy and load balancer backed by etcd. A similar process that we did with Consul Template and nginx/HAProxy is incorporated inside VulcanD. It can be combined withSidekick¹³⁰to provide functionality similar to check arguments in nginx and HAProxy.
¹²⁸http://www.lighttpd.net/
¹²⁹https://github.com/mailgun/vulcand
¹³⁰https://github.com/lokalebasen/sidekick
There are many similar projects available, and it is certain that new and existing ones are into making. We can expect more “unconventional” projects to appear that will combine proxy, load balancing, and service discovery in many different ways.
However, my choice, for now, stays with nginx or HAProxy. None of the other products we spoke about has anything to add and, in turn, each of them, at least, one deficiency.
Apache is process based, making its performance when faced with a massive traffic less than desirable. At the same time, its resource usage skyrockets easily. If you need a server that will serve dynamic content, Apache is a great option, but should not be used as a proxy.
Lighttpd was promising when it appeared but faced many obstacles (memory leaks, CPU usage, and so on) that made part of its users switch to alternatives. The community maintaining it is much smaller than the one working on nginx and HAProxy. While it had its moment and many had high expectations from it, today it is not the recommended solution.
What can be said about node-http-proxy? Even though it does not outperform nginx and HAProxy, it is very close. The major obstacle would be its programmable configuration that is not well suited for continuously changing proxies. If your language of choice is JavaScript and proxies should be relatively static, node-http-proxy is a valid option. However, it still doesn’t provide any benefit over nginx and HAProxy.
VulcanD, in conjunction with Sidekick, is a project to keep an eye on, but it is not yet production ready (at least, not at the time this text was written). It is very unlikely that it will manage to outperform main players. The potential problem with VulcanD is that it is bundled with etcd. If that’s what you’re already using, great. On the other hand, if your choice fell to some other type of Registry (for example Consul or Zookeeper), there is nothing VulcanD can offer. I prefer keeping proxy and service discovery separated and put the glue between them myself. Real value VulcanD provides is in a new way of thinking that combines proxy service with service discovery, and it will probably be considered as one of the pioneers that opened the door for new types of proxy services.
That leaves us with nginx and HAProxy. If you spend some more time investigating opinions, you’ll see that both camps have an enormous number of users defending one over the other. There are areas where nginx outperforms HAProxy and others where it underperforms. There are some features that HAProxy doesn’t have and other missing in nginx. But, the truth is that both are battle-tested, both are an excellen solution, both have a huge number of users, and both are successfully used in companies that have colossal traffic. If what you’re looking for is a proxy service with load balancing, you cannot go wrong with either of them.
I am slightly more inclined towards nginx due to its better (official) Docker container (for example, it allows configuration reloads with a HUP signal), option to log to stdout and the ability to include configuration files. Excluding Docker container, HAProxy made the conscious decision not to support those features due to possible performance issues they can create. However, I prefer having the ability to choose when it’s appropriate to use them and when it isn’t. All those are truly preferences of no great importance and, in many cases, the choice is made depending on a particular use case one is trying to accomplish. However, there is one critical nginx feature that HAProxy does not support. HAProxy can drop traffic during reloads. If microservices architecture, continuous
deployment, and blue-green processes are adopted, configuration reloads are very common. We can have several or even hundreds of reloads each day. No matter the reload frequency, with HAProxy there is a possibility of downtime.
We have to make a choice, and it falls to nginx. It will be out proxy of choice throughout the rest of the book.
With that being said, let us destroy the VMs we used in this chapter and finish the implementation of the deployment pipeline. With service discovery and the proxy, we have everything we need.
1 exit 2
3 vagrant destroy -f