Hacker News new | ask | show | jobs
by mmahemoff 3212 days ago
Confusing description. After seeing the Github README (https://github.com/nginx/unit#integration-with-nginx), it looks to be Nginx's alternative to low-level, language-specific, app servers, e.g. PHP-FPM or Rack, with the benefit that a single Unit process can support multiple languages via its dynamic module architecture, similar to Nginx web server's dynamic modules.

It's still intended to run behind Nginx web server (or some other web server), much like you'd run something like PHP-FPM behind a web server.

2 comments

It's a polyglot app server with microservice orchestration. It's definitely needed.

Some things to look for, such as registration/discovery of services, intra-cluster load balancing (where it started, no doubt), identity propagation & authn/z

The biggest issue to my mind though is distributed transactions and logging/debug/development. My biggest stumbling blocks with this sort of thing.. stepping through code over microservices is such a PITA.

You seem to be very experienced in this area. Can you explain a bit about why you think an "app server with microservice orchestration" is needed?
because you can work with individual microservices across clusters without a ton of overhead (or use a monolithic app server), aiding in deployment, rollback, debugging, development.
How exactly does having an app server reduce overhead, compared to running each service directly without app server? And how does having an app server compare to putting each microservice in its own Docker container and orchestrating them in Kubernetes, which is what more and more companies seem to be doing?
having to deal with e.g. php-fpm, fcgi, tomcat, and unicorn separately in the same stack is a nightmare. even if they run in separate locations/clusters/nodes/machines, it's still several different configuration and deployment paradigms you have to deal with.

some people simply don't like containers or aren't tooled for it.

there's more than one way to do it (TMTOWTDI).

You would be able to merge your services under a single server and have them talk to each other internally sans latency overhead. It also allows you to easily scale up and down and segment things on demand.
At a glance, I think this is an alternative to docker/kubernetes. The general idea seems to be to cut the middleman/topman out and let the bottom man (app server) be the "unit" of configuration. Like a sort of integrated docker/<YourLang>-runtime.
No, this thing is more like inetd, while kubernetes is more like an OS for containers and docker is a package manager.
So in what circumstances would you need the polyglot bit? (I guess I'm assuming a container/VM architecture here).
From the description it sounds a lot like the Passenger Nginx module. https://www.phusionpassenger.com