The very moment you start running a service of what kind ever, you will face yourself being exposed to the concepts and release cycles of the software underlying your service. In the case of Linux, among other issues this results in the question of what type of Linux distribution you deploy on your servers. The question is not whether it is Debian, Red Hat, Suse or Ubuntu — the question is: do you go the “enterprise” road or stay with community-backed products.
An Enterprise Linux distribution does not distinguish itself by carrying a price tag where the community-based distribution comes without licensing costs. The main difference merely stems from the fact that Enterprise customers call for long-term support where community members usually prefer to run the greatest and latest software. In the case of SUSE, this means you can either buy a SUSE Linux Enterprise Server License and have the calming illusion of 5 years between major upgrades. Which is not true, since you usually want to go for the in-between service packs as well. Or you can stick to SUSE Linux, but then you’ll encounter end-of-life announcements cutting you off from packages updates after roughly two years, meaning you will have to upgrade to a newer base version in order to maintain support by the distributor.
Add to this the common practise that one often does not rely on the distribution’s upgrade path, for it could open up problems believed to be hardly debugable. And it also sounds like a good thing to effectively re-build the system by re-installing from scratch and performing system and services configuration once again, so that you don’t forget how one configures Apache, deals with OpenSSL etc. — and people DO forget things a lot.
But what this adds up to is the exact lock-in that brings frustration to large groups of IT people and is the very opposite of any Agileness manifesto: the fear of an unpredictable “complete reinstall” makes you start becoming comfortable with taking risks of missing security updates, following the credo “well, it has been running all the time, didn’t it”. In SMB environments, which is the area I am often concerned with, there isn’t even a real understanding WHY updates are important, so there is even less understanding for server downtime, which translates into services downtime which translated into interruption of regular business. There is also few motivation to invest in a more sophisticated setup involving multiple servers or virtualizing services so they can simply be migrated around.
You might be tempted to bring in automatic installation and configuration tools, but is it worth to develop, test and re-adapt such procedures when they apply to a single or just a few servers only? Autoyast/Kickstart, Puppet et al. pay off the more machines you have, but they do not really seem as the perfect solution for “n < 5". Also, any automatisms need development and maintenance time as well, incurring costs which again are hard to explain to your average SMB customer. Now in my case, seeing that I run a webserver myself, I was my own customer. And I have been delaying a necessary system update for like a year now. This sucks big time. And the net result of this situation is not to be underestimated. The point here is NOT to whine about Linux distribution lifecycles. The point here is NOT to excuse yourself. The point is to keep breathing. And in some situations the air may get thin, so the breathing may become harder, BUT - it's not like you really have a choice. You MUST proceed. In my opinion, it is much more a question of character than of tools or lifecycles. You MUST persist. Do not refrain, on the contrary, be AGGRESSIVE. Embrace change (and a reinstallation IS a change, even if the end result looks identical on a binary level). Do not delay but rather do it often. Because the key point is: the pain you're trying to save yourself from will come anyway later on and with a much larger amplitude. You do NOT gain anything. Face it. Doing this job is much about practise. And practise requires routine. Routine does not come from delaying possibly painful steps, rather from mastering them. And: this is not really news. This is called staying agile.