Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nginx Unit

nginx.com

Post reply on HN
Print view View original

111–120 of 236 posts

Re: Nginx Unit

#111

Post by ishtu »

LeonidBugaev wrote: post #109
ishtu wrote: post #104

I am surprised noone mentioned Kong [1] yet. It seems to implement most of stuff promised by Unit and it was around for a few years. [1] https://getkong.org/

Not sure how it is related. Unit is an app server, it runs app processes and manages them, handles graceful restarts and etc. Kong is just an API gateway: you run your own infrastructure as usually and put a gateway on top of it.

>Build the foundation of your service mesh.

Not directly related as Unit seems to be advertised as app server primarily, but you can see quoted text on main page.

Re: Nginx Unit

#112

Post by agentgt »

I'm still not sure I understand "Unit".

I can't speak for the other languages (PHP, Go, Python) but I have some reservations about it helping Java (as well as Erlang and other (J)VM languages) as FastCGI like stuff has been attempted for Java in the past with not very good success with the exception of Resin.

I guess it would be interesting though if they did a native Servlet 3.0+ implementation like Resin but I doubt that is is what will happen. Regardless Netty, Undertow and even Jetty have caught up speed wise to Resin (well at least according to techempower).

Re: Nginx Unit

#113

Post by anentropic »

justonepost wrote: post #54
oelmekki wrote: post #50

I initially thought it would allow to dynamically handle upstreams list (and other configuration) like hipache is doing [1], which would be awesome for dokku or other container management systems which rely on system nginx. But after seeing languages mentioned, I'm confused. Is it supposed to replace language specific servers, like unicorn and puma for rails (but then, I'm confused about what such kind of support wou…

it's like swarm - https://docs.docker.com/engine/swarm/#feature-highlights but much more lightweight.

and nothing to do with docker containers

in fact nothing like it really AFAICT

Re: Nginx Unit

#116

Post by zzzcpan »

MadcapJake wrote: post #108
FooBarWidget wrote: post #97

Earlier quoted context omitted.

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?

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/ -runtime.

No, this thing is more like inetd, while kubernetes is more like an OS for containers and docker is a package manager.

Re: Nginx Unit

#117

Post by flachsechs »

FooBarWidget wrote: post #97
flachsechs wrote: post #86

Earlier quoted context omitted.

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).

Re: Nginx Unit

#118

Post by falcolas »

Xoros wrote: post #105
msimpson wrote: post #87

Earlier quoted context omitted.

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…

I'm sorry but I'm not sure I get it. Is it like the apache mod_php for php for example ? Thanks in advance for your answer

That's how my reading of it goes. You provide an "endpoint" for the library to call, configure the Unit framework, and their Manager connects the nginx frontend to that Unit framework.

No real idea if it does so using fcgi or some other socket-based proxying, or if the unit is spun up as a separate process and handed the raw socket and some shared memory after the headers are parsed (closer to how mod_php works).

Re: Nginx Unit

#119

Post by agentgt »

foo4u wrote: post #110
justonepost wrote: post #56

Earlier quoted context omitted.

microservices on their face seem cool, but in reality not so much. really, it's just SOA taken to an unnecessary extreme.

It's really SOA without the XML based service bus.

Oh the "service bus" xml json is coming back... its called lambda architecture.

And again nothing new except someone else takes care of some server software for you with the promise of reduced price and maintenance but the reality eventually becomes tight proprietary coupling and eventual price gauging.

Post reply on HN