- Long-running processes where they don't want to destroy and redeploy every single time a fix or change gets deployed
- One is where they try to reduce the configuration sprawl by making configuration changes at runtime using something like ansible
- One is straight-up bigco stupidity (we must have a way to change the running configuration of a system because the audit team says so)
- separation of responsibilities - we have one team that builds "approved" docker images, and then dev teams can make changes based on that - it might be easier to deploy changes at launch time
Again, I'm not saying all of these make sense, but back when I was workign on docker strategy and interviewing really big companies, these are the types of concerns they had about implementing docker at scale.
- Long-running processes where they don't want to destroy and redeploy every single time a fix or change gets deployed
- One is where they try to reduce the configuration sprawl by making configuration changes at runtime using something like ansible
- One is straight-up bigco stupidity (we must have a way to change the running configuration of a system because the audit team says so)
- separation of responsibilities - we have one team that builds "approved" docker images, and then dev teams can make changes based on that - it might be easier to deploy changes at launch time
Again, I'm not saying all of these make sense, but back when I was workign on docker strategy and interviewing really big companies, these are the types of concerns they had about implementing docker at scale.