Choosing to move to containers is somewhat similar to choosing to move to a service oriented architecture in the sense that it formalizes a division of labor. Y

Choosing to move to containers is somewhat similar to choosing to move to a service oriented architecture in the sense that it formalizes a division of labor. You will have to dedicate some of your people to making sure that anything works at all. Some people prefer this because it's easier to understand what people are spending their time on. Whereas the cracks and seams of sharing work as a team grows are harder to identify. There's lots of an hour or two lost here because of a merge conflict or a half day there because the django project won't start up unless it can find redis. The question for you is where are you in your product lifecycle? Are you in a place where you can take several people off of feature development and maintenance and dedicate them to, essentially, DevOps? Were you hiring with that in mind? Are people on your team interested in moving to that kind of work? I really don't think there should be that many cracks in a 12-person dev team that drive a technical need to use containers (or SOA, for that matter).