1. in a small scale (3 micro-services + 1 DB + 1 webapp), I think docker does an amazing job to ensure reproducible builds. But as the complexity grow, docker starts to shift from part of the solution to part of the problem. Just to throw out some questions: how to manage compatibility if a team uses Windows, Mac, Linux at the same time, even with different versions? How to ensure 237 of my engineers do not have a broken environment when I want to bump the docker version?
2. There are things should not be part of docker images and those things are more troublesome than the build itself sometimes. For example: credentials, env vars, and so on. I don't remember how many times I need to ask a bunch of people just to get the credentials right.
3. Even an amazing tool like Docker does not have 100% of the market. So we may be a good alternative for the teams who choose not to use Docker.
1. even though you are running a webapp with micro-services on the backend, the requirement for computing power can increase as the number of services grow. I see some teams are running 20 - 50 micro-services and it is just too much for a laptop.
2. In some regions, it is not so common that engineers get the high-end macbook pro for their daily work. Some has to work with 8GB ram machines for various reasons.
1. If you have two k8s clusters, you can easily run it on a Ubuntu VM and when you run into issues, it is easy for you to find answers support. But running two K8s clusters inside a docker container is much more challenging~ but yes doable.
2. There are some random issues I run into with containers, like port forwarding (management in general). Again I figured it out but more complex
3. Easier to integrate with users current configurations. Most users today still code on their laptop directly instead of creating a container and code inside that container. So most settings can be migrated to a VM-based environment directly.
4. As much as I love containers... still many engineers don't use containers for various reason.