One thing is that I don’t know for sure if it is containerized or not. The topic was migration, and that facet would be not relevant to the core. When I’m doing a write up of things like this, I tend to omit details like that unless it is core to the subject at hand. Including replacing a funky ingress situation with a more universally recognizable nginx example. The users of a container setup would understand how to translate to their scenario.

For another, I’ll say that I’ve probably seen more people getting screwed up because they didn’t understand how to use containers and used them anyway. Most notably they make their networking needlessly convoluted and can’t understand it. Also when they kind of mindlessly divide a flow for “microseconds”, they get lost in the debug.

They are useful, but I think people might do a lot better if they:

• More carefully considered how they split things up
• Go ahead and use host networking, it’s pretty good
• unix domain sockets can be your friend instead of binding to tcp for everything. I much favor reverse proxy to unix domain instead of handling IP/ports, which is what the container networks buy most people but the flow is too gnarly
• Be wary of random dockerhub “appliances”, they tend to be poorly maintained.

If you are writing in rust or golang, containers might not really buy you much other than a headache, so long as you distinct users for security isolation. For something like python, it might be a more thorough approach that virtalenv, though I wouldn’t like to keep a python stack maintained with how fickle the ecosysyem is. Node is pretty much always “virtualenv” like, but even worse for fickle dependencies.