How is it different from Envoy?
I came to ask the same question. The landing page is terrible it says pretty much nothing.
Nginx Unit
81–90 of 236 posts
Re: Nginx Unit
#82Earlier quoted context omitted.
When was the last time you heard something about it?
I'm using it for a project now. It's a bit weird, but it does work. Cool thing: you can slot a file descriptor into the zmq provided poll ... point is that you can poll on both zmq and sockets in the one loop. Pro Tip: Use 'cbor' for serialising.
> you can poll on both zmq and sockets in the one loop
Which is magnificent. The ZMQ poller is tons of fun. (Although I think this doesn't work on Windows.)
Re: Nginx Unit
#83Confusing 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 se…
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 m…
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?
Re: Nginx Unit
#84Any use for that on small scale (of 1 instance)? If you'd need to run nginx in front of it anyway, does it provide any use in case where you'd normally use php-fpm and some proxy_pass?
Interesting for me since I run not just php. Depending on what you do, maybe the API is useful for you.
Re: Nginx Unit
#85How is it different from Envoy?
It seems like it is quite different, you actually change your code to listen with NGINX unit.
Re: Nginx Unit
#86Earlier quoted context omitted.
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 m…
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.
Re: Nginx Unit
#87Could anyone explain to me why I would want to use this? What exactly is the use case and benefits of it when I am for example running a go web application?
NGINX allows you to proxy a back-end applications giving you the ability to load balance, handle upstream failures with custom maintenance pages, employ server blocks (virtual hosts), and much more. However, you always need to do the leg work to get your specific application language up and running. This new unit system makes that job easier as you would no longer need to employ separate middleware, like PHP-FPM for PHP applications, or use a separate init system like systemd to run Go or Node applications. Now NGINX would assume those responsibilities and provide you with a consistent interface.
Here you can see the configuration of workers and user/group permissions for a Go application:
http://unit.nginx.org/docs-configuration.html#go-application
Re: Nginx Unit
#88Sounds like uWSGI based on the description. I wonder how it'll play along with certain environments like Kubernetes.
Same. I really want to like (and use) uWSGI, for many reasons, but I find it's lacking severely in the department of documentation (searching "uwsgi" on Amazon gives zero hits!). A properly edited book would be awesome. I would pay for it of course.
> I really want to like (and use) uWSGI, for many reasons, but I find it's lacking severely in the department of documentation (searching "uwsgi" on Amazon gives zero hits!).
uWSGI definitely needs more concise tutorials on how to accomplish some tasks (e.g. creating Hello World with python and uWSGI, or how the uWSGI emperor works).
However I disagree with "lacking severely in the department of documentation"
Sure, it's not as easy as some other projects to dive into (e.g. Django) but IMHO the documentation is not lacking, it's just not forthcoming.
If you sit down and read through the uWSGI documentation, you'll discover a lot of very useful functionality and a reasonable description of how to utilise it.
What's lacking is the tl;dr way to bash something out quick and dirty.
Re: Nginx Unit
#89Earlier quoted context omitted.
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.
So in what circumstances would you need the polyglot bit? (I guess I'm assuming a container/VM architecture here).
Re: Nginx Unit
#90This looks pretty cool, and makes me sad that Mongrel2 never became popular. In short: Mongrel2 solves the same problem, but does it by letting your application handle requests and websocket connections over ZeroMQ instead of eg FastCGI. I guess it lost momentum when ZeroMQ did. Anyone know why? Sounds like a dream solution in the current microservice hype. http://mongrel2.org/
Yeah, Mongrel2 looked like a good idea… but turns out it's kinda pointless. Why talk to your app via HTTP-reencoded-as-ZMQ when you can just talk straight up HTTP? Pretty much all languages have very fast and concurrent HTTP servers these days.