So $work did java app deployment with Tomcat and puppet at scale (>100 services). Sweet. Mostly. 3 problems, 1 is that in the unlikely event you had an externa

So $work did java app deployment with Tomcat and puppet at scale (>100 services). Sweet. Mostly. 3 problems, 1 is that in the unlikely event you had an external system dependency, (say, shudder, imagemagick or really, any non java binary) you were totally hosed, because lots of systems work needed to be done to provide it (say, make rhel packages in corp repo plus puppet guff) and also keep it up to date. 2 was, since it was outside the supported path, actually, you couldn’t ship anything that wasn’t Java in Tomcat, Java invoked binaries were hard, but non Java services, even judiciously and with a super good reason were basically impossible. 3. Your stuff might be coupled to the base operating system in some way... which meant that the operating system patches needed to be tested against all possible application deployments and thus patching (including kernel) became the de-facto responsibility of the team owning the application, which lead to major delays in patch application. Containers mostly shift these problems around (and create new and different problems too) rather than solving them, but my experience is that they do genuinely shift them around in a useful way.