One container per plugin is NOT a good idea. But that's something we have been discussing in the past. We have discussed how to mitigate it too [1] and running multiple plugins in one container is currently possible [2].
Anyway I think that what Thomas is trying to challenge is the choice to use a sidecar approach rather than a VM like approach for development environments.
Is it the right moment to discuss it? Probably not. We are suuuuper busy with our tight release schedules.
But will we ever have a "right moment" to discuss? Probably not so....
So why aren't we using a VM-like dev machine with a predefined set of tools and runtimes? A machine where a user could even install his favorite tool or a different version of one of the runtimes available there. UX would be similar to local machines and developers would feel at home right?
Right. But this approach has some issues too and here is a list:
The VM approach augment the divergence between dev and production (works on my machine)
The VM approach leads to snowflakes, non repeatable environments (new dev on boarding takes time)
The VM approach moves away devs from ops (they do not share a clear contract)
The VM approach doesn't scale (it takes time to switch between multiple dev environments)
The VM approach makes it harder to deploy the target app on modern cloud platforms (kubernetes)
These aren't new arguments. The twelve factors app methodology and the ultimate success of containers are based on principles that address the VM approach. But dev tools haven't been fully adapted (yet) to this new paradigm and Thomas has mentioned a list of downsides of the sidecar approach.
Should we go back to the mainstream model then? I don't think so. Addressing the downsides of the VM approach is our key differentiator and we have a great opportunity to win. Is our sidecar model mature? I don't think so. We still have some important issues to address but we have made an amazing job exploring unknown lands and we should keep up the good work.
