4 ms·
because you can work with individual microservices across clusters without a ton of overhead (or use a monolithic app server), aiding in deployment, rollback, d
by flachsechs 9y ago
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.
- dithering 9y agoSo in what circumstances would you need the polyglot bit? (I guess I'm assuming a container/VM architecture here).
- FooBarWidget 9y agoHow 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?
- MadcapJake 9y agoAt 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.
- zzzcpan 9y agoNo, this thing is more like inetd, while kubernetes is more like an OS for containers and docker is a package manager.
- flachsechs 9y agohaving 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).
- korzun 9y agoYou 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.