Configuration Drift Issues

“Production Twitter on one machine? 100Gbps NICs and NVMe are fast &gt; When it comes to Java, everything could be used as a directory installation. Like you need JDK, maven and tomcat? Download and extract it somewhere. Modify your current PATH to include java and that&#x27;s about it. You can build big tar.gz instead of OCI container which will work just fine.<p>I&#x27;ve seen something similar in projects previously, it never worked all that well.<p>While the idea of shipping one archive with <i>everything</i> is pretty good, people don&#x27;t want to include the full JDK and Tomcat installs with each software delivery, unlike with containers, where you get <i>some</i> benefit out of layer re-use when they haven&#x27;t changed, while having the confidence that what you tested is what you&#x27;ll ship. Shipping 100 app versions with the same JDK + Tomcat version will mean reused layers instead of 100 copies in the archives. And if you <i>don&#x27;t</i> ship everything together, but merely suggest that release X should run on JDK version Y, the possibility of someone not following those instructions at least once approaches 100% with every next release.<p>Furthermore, Tomcat typically will need custom configuration for the app server, as well as configuration for the actual apps. This means that you&#x27;d need to store the configuration in a bunch of separate files and then apply (copy) it on top of the newly delivered version. But you can&#x27;t really do that directly, so you&#x27;d need to use something like Meld to compare whether the newly shipped default configuration doesn&#x27;t include something that your old custom configuration doesn&#x27;t (e.g. something new in web.xml or server.xml). The same applies to something like cacerts within your JDK install, if you haven&#x27;t bothered to set up custom files separately.<p>Worse yet, if people aren&#x27;t really disciplined about all of this, you&#x27;ll end up with configuration drift over time - where your dev environment will have configuration A, your test environment will have configuration B (which will <i>sort of</i> be like A), and staging or prod will have something else. You&#x27;ll be able to ignore some of those differences until everything will go horribly wrong one day, or maybe you&#x27;ll get degraded performance but without a clear reason for it.<p>&gt; So IMO it&#x27;s perfectly possible to run Java applications without containers. You would need to think about network ports, about resource limits, but those are not hard things.<p>This is only viable&#x2F;easy&#x2F;not brittle when you have self-contained .jar files, which admittedly are pretty nice! Though if shipping JDK with each delivery isn&#x27;t in the cards (for example, because of the space considerations), that&#x27;s not safe either - I&#x27;ve seen performance degrade 10x because of a JDK patch release was different between two environments, all because of JDK being managed through the system packages.<p>Resource limits are generally doable, though Xms and Xmx lie to you, you&#x27;d need systemd slices or an equivalent for hard resource limits, which I haven&#x27;t seen anyone seriously bother with, although they&#x27;re at a risk of the entire server&#x2F;VM becoming unresponsive should their process go rogue for whatever reason (e.g. CPU at 100%, which is arguably worse than OOM because of bad memory limits).<p>Ports are okay when you are actually in control of the software and nothing is hardcoded. Then again, another aspect is being able to run multiple versions of software at the same time (e.g. different MySQL&#x2F;MariaDB releases for different services&#x2F;projects on the same node), which most nix distributions are pretty bad at.<p>&gt; And tomcat even provides zero-downtime upgrades, although it&#x27;s not that easy to set up, but when it works, it does work.<p>I&#x27;ve seen this attempted, but it never worked properly - the codebases might not have been good, but those redeplo”