Why Databases Are Not for Docker Containers
&gt; But what about Configuration Management systems? They’re designed to solve this kind of routine by running one command.<p>The problem with this for most of the developers you see praising containers, is that with a containerized setup, you&#x27;ve already got the <i>rest</i> of your deployment process down to `docker service update --image myorg&#x2F;myservice:1.3.0 myservice`<p>(And, in fact, maybe you&#x27;re even running that code against immutable-infrastructure container-host OS like CoreOS.)<p>And <i>now</i>, you&#x27;re suggesting that these developers would have to add this whole other process just for managing the deployment of the DBMS package—and probably the OS it&#x27;s running on, too. (Maybe they would even have to add process to manage the <i>VM</i> it&#x27;s running on, if they were doing everything else until now using autoscaling + swarm auto-join.)<p>Developers put DBMSes in containers because they&#x27;re developers, not DBAs. If you <i>are</i> a DBA, then obviously this will seem wrong to you. A DBA wants to manage a DBMS using the DBMS&#x27;s tooling. Developers, meanwhile, essentially want to manage DBMSes as part of the same &quot;release&quot; as their apps—being able to &quot;pin a dependency&quot; to a specific DBMS version; update the DBMS as part of a commit and see the whole updated stack go through CI to integration-test it; etc. These are development-time concerns that—at small scale—usually override operation-time concerns.