Hacker News Reader

Comment by FooBarWidget | Hacker News Reader

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?

View on HN

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

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

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

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.

Reply on news.ycombinator.com