ioquatix
commented
3 years ago Well, this is a good question. Basically, there is nothing preventing you from having containers of containers. Containers are units of parallelism, be it multiple processes, threads, or in theory ractors. The goal is an interface which programs can say "I want you to run this scalable unit of work" and not worry about how it scales up, just that it does.
Hi, this is not really an issue, but I opened one since this project doesn't have github discussions yet.
I'm curious how to better understand the "container" concept from this gem.
My first association to "containers" is docker and the accompanying devops containers technology. I think the name of this gem was chosen intentionally to associate with these technologies, right?
When thinking about docker and "devops containers" the model I have in my head is:
With the model of "one container = one process" in mind, I was a little surprised to discover this gem actually runs and manages multiple processes by design. This actually makes sense (what's the use of running just a single process?) but it broke my model "one container = one process".
After this I started to think more "one async container = one service with multiple identical processes". All good so far.
What really surprised me was code from "falcon virtual" command:
https://github.com/socketry/falcon/blob/676475da61f2ad8534902c73208d5683e4180496/lib/falcon/controller/virtual.rb#L89-L112
Falcon virtual container spawns multiple processes with multiple responsibilities:
falcon hostcommands (which are async container processes themself)This broke my mental model of "one async container =~ one service". Now, I'm more inclined to think async container is like a supervisor, managing one or more services, each running a predefined number of processes.
What are your thoughts on this? What is the "official" way to think of the "container" concept? Thanks!