We're currently on Debian Squeeze so we need to move to something as Squeeze is approaching end-of-life.
If we stick with Debian, we'll find ourselves back in this situation fairly soon, since Debian's security team only supports oldstable for one year after a new stable is released (approximately — there isn't a set timeline available).
Ubuntu LTS releases, on the other hand, give us predictability and five years of support. That makes me very happy from an infrastructure standpoint. And the more up-to-date packages in Ubuntu repos make our feature devs happier, versus having to maintain backports for modern software.
I'm going in the opposite direction - we're an Ubuntu shop, but I'm considering transitioning to Debian. Ubuntu is too much of a moving target, it seems, and seems to want to go its own way a little too much. It's focus is less on the server and more on the desktop and mobile, though I don't know how much that would affect future work.
One of our coders had to figure out something to fix a problem in his ubuntu desktop, and reported that he'd found a guide that showed it was done a different way in each of the four previous releases. I think they're doing fine for their original target audience - naive users - but I'm cautious about their constant change and go-it-aloneness.
Will those packages always be up to date even on the LTS Ubuntus?
Will you be able to support Postgres 12 and Nginx 3 on those machines?
I find it useful to deploy the application on the same OS it was dev'd on, but in a decoupled manner. The thing I despise the most is needless upgrades of infrastructure pieces of working apps (redis,python runtime,etc). Each should get there own static version.
A couple jobs back, I would package my own JVM along with the application (in an rpm) as ops was being really slow to upgrade machines. The only thing I depend on for a box is libc.
And how did you, or how do they now, handle security updates for this bundled JVM?
Sure - Ops being slow to upgrade is annoying, Ops patching a security hole and you leaving it open could be devastating.
There is a really good reason Debian forbids embedded copies of other packages, and why I despise "solutions" like Chef's OmniBus. These things are live grenades moments away from taking the whole ship down.
We would rebuild the rpm with a new JVM and redeploy the app after testing the fix.
Ha! How many copies of Lua are living in applications that Debian doesn't have control over? There are probably package maintainers excising those as we speak.
I don't want to get into a packaging philosophy war, not enough fun over text, needs to be face to face.
I had to bundle in my JVM because ops wouldn't allow more than ONE on a machine. I wanted
/opt/jvm/1.6.22
/opt/jvm/1.7.10
And I could symlink my apps to the one I needed. New apps could get new JVMs, old apps would continue to run just fine. But they wouldn't do this because it _broke_ Red Hat file system guidelines, for whatever definition of broke.
Reuse can absolutely cause over coupling. I prefer to have tractable dependency graphs.
CentOS + collections would be my answer to those problems (with, presumably, the unstated "we don't want to pay a lot of money for support" as a third). But I'm happy with yum/rpm.
Ubuntu LTS tend to backport a good number of packages. For example, if you wanted a fairly recent nginx, you will find 1.4.x built for 12.04 LTS https://launchpad.net/~nginx/+archive/stable
The particular packages you need might be obtainable from Launchpad PPAs, which Debian doesn't really have an equivalent of unless you're willing to maintain your own.
If you don't want to phase-in updates rather than depend directly on a third-party PPA, you can also setup your own PPA and copy packages to it as you wish.
