Understanding the "container" concept
bruno- opened this issue · 1 comments
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:
- One "container image" = one service.
- One container = one process = one running instance of "container image".
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:
Falcon virtual container spawns multiple processes with multiple responsibilities:
- redirect process
- proxy process
- a number of
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!
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.