Old servers: whether physical, virtual, or cloud-based; are a form of technical debt.
What that means is that by neglecting to invest in and maintain your infrastructure and applications
you are avoiding work or costs today, but storing up problems for later on. That debt needs to be repaid
eventually and it will have accrued interest. Most IT professionals will know this yet many find
themselves faced with a mountain of technical debt to be overcome due to decisions made by somebody
else. What's worse is that once a company starts down this path it rarely changes course until the
auditor arrives and forces their hand, or something breaks irreparably. At that point there's no time
to do things properly. The right solution goes out the window and the quick solution is chosen
instead. Thus the cycle continues... until today. Today we're going to try and break that cycle.
Welcome back to The Pro Tech Show. You know, it's funny. I think these days have problems with
technical debt are generally better understood, but yet the scale of the problem is if anything
getting worse. Back in the day when servers were physical they had a finite lifespan; because
at some point the hardware would simply break, or become more difficult to repair,
or you'd outgrow it. That meant you bought a new metal box, and chances are you'd get with it the
latest software version as well. These days you can keep upgrading the hardware or paying your cloud
subscription while your software happily floats around in an abstracted bubble somewhere on top
and never actually gets replaced. I'm borrowing the phrase "technical debt" from software development
because i think it applies equally well to an infrastructure perspective of legacy systems.
You'll most often hear this in the context of a piece of software being called "end of life" or
"out of support", so let's start with defining what that means. My experience has been that most IT
professionals know what it means, but a lot of IT or business leaders don't. I'll give you an example.
When I raised with a senior business leader that their systems were virtually all end of life they
told me that they were sick of IT people saying that, and they believed it to be nonsense. There
was some logic to their thinking. This was their conversation with their IT person. If they're end of
life have they stopped working? No. Will they stop working? No. What does it mean then? It means they're
unsupported. But I pay a company to support them. Have they stopped answering the phone?
No. Then what do you mean!? I can kind of understand this frustration. What we need to do is express the
risk in business terms. Apologies if this part of the video feels like it's teaching you to suck
eggs. If the message isn't getting through for you, though; feel free to use this to explain it to your
boss, or just link them to the video if you want. To me, end of life systems incur two main problems.
The first is compatibility. In business terms this means a risk to operations and a constraint
on business agility. Take Windows XP, for example. Everybody knows you shouldn't be using Windows
XP anymore, but the fact is you absolutely can. If you install XP now it will work just as well as it
did nearly 20 years ago. It's not food. It doesn't go off. If all of your other software is nearly
two decades old as well, then your experience would be largely the same as it was back then. Until you
tried to connect the internet or interact with anyone outside your little time bubble that is.
As soon as you did that you'd start having problems. If you're running end-of-life systems you
should expect compatibility problems to rear their head at some point. This might be annoying, or it
might bring things to a screeching halt, depending on severity and criticality. You'll also find it
increasingly difficult for your systems to adjust to new conditions or demands, which may cost you in
missed opportunities. That's the first problem. The second problem you get with end-of-life systems is
security... or lack thereof. "Unsupported" doesn't mean nobody can look after and fix problems related to
the application. It means nobody's maintaining the code. Just because nobody's maintaining it
doesn't mean the bad guys have stopped looking for vulnerabilities in it, though. This is the danger.
I'm sure you've heard of zero-day vulnerabilities. They're the worst kind because it means the bad
guys have found a vulnerability before the good guys, and are actively exploiting it. The reason
these are so bad is because there's often no defence against them and it's a race against time
for the vendor to figure it out and issue a patch before you get breached. You may even have to just
shut down your systems and wait to avoid getting breached. With an end of life system, every single
bug that gets discovered is a zero-day and there will never be a patch to fix it. You will always
be vulnerable to exploitation. This poses a serious risk to the security of your business, your ongoing
operations, and the integrity and privacy of your data. It should not be taken lightly.
OK. Now we're all on the same page. End-of-life systems, software that's out of support, technical debt,
however you want to phrase it... it's bad and you want to stay well away from it. Which may make the
sponsor of this video seem like a bit of an odd choice. This video is sponsored by TuxCare Extended
Lifecycle Support from CloudLinux. They help maintain the very systems I've just warned you
against, so why would I agree to talk about them? Yes, they will give me money for featuring them, but
I reject the vast majority of sponsorship offers that come my way so I promise you it's not that.
It's because whilst in an ideal world you would never have to deal with end-of-life systems...
we don't live in an ideal world. At some point you likely will have to deal with them and there
are good and bad ways of doing that. There are two scenarios that usually trigger this sort of
"deal with your legacy" exercise. One is a change of leadership, or leadership finally joining the dots.
This could be a new person in charge, a new team member speaking up, or existing leadership
commissioning an external assessment to lay bare the risks. That happens. I've been that external assessor
on more than a few occasions but this isn't usually how it plays out. Looking at what I've
personally seen happen in recent years I'd say that 90% of the time an IT department
finds themselves confronting their technical debt today it's because they've had or are expecting a
security audit. Here's how it plays out. Business requirement exists to attend certification.
End-of-life system cannot be protected against security vulnerabilities because nobody's
providing patches for them. Business cannot attain required certification. The person at the top with
the requirement goes mental because they're going to lose massive contract, blah, blah, blah.
IT have to fix it. One of my colleagues has a saying that if you take a rubbish process and digitise it
you get a rubbish digital process; and if you take a rubbish digital process and put it in the cloud
you get a rubbish and expensive digital process. It's another way of saying "garbage in, garbage out";
but it's also saying that if you're going to upgrade something you really ought to take a step
back, look at the options available to you, and plan a transition that allows you to take advantage of
modern technologies to improve things rather than simply regurgitating the same old thing
over and over again with the same old problems. Just because your legacy system made sense back
when it was first implemented doesn't mean it's the best way to do things today. For example,
let's say you have a legacy file server. It's a really simple scenario -
you just need to upgrade the operating system and you're done, right? Maybe... but then again maybe it's
a good time to restructure your data. Maybe you could move from a static to dynamic access control
paradigm. Maybe you should use modern tools to start classifying those files and implement data
loss prevention. Maybe you shouldn't be deploying a file server at all and you should be moving it to
a document management system. Or maybe you could collaborate better if you put it in the cloud.
This is how you should think about an upgrade. What is the best way to deliver tangible business
benefits? The problem is this takes time and you need that certification by the end of the week,
or (and believe me this happens) you can't actually get rid of that legacy
system because it's business critical and the vendor doesn't actually support anything newer.
I think we should all collectively join together and slap those vendors, hard, because in this day
and age that just isn't acceptable. In any case, instead of doing the right thing you're forced
to do the quick thing, and instead of paying off your technical debt you've just accrued
a bit more interest. This is where TuxCare's ELS can really help you out of a tough spot.
When you're stuck between that rock and that hard place where option one has you closing your eyes
while you upgrade old junk to new junk, and option two has you exposing the business to risk and
failing that certification; TuxCare ELS presents you with an option three. TuxCare's Extended
Lifecycle Support provides support beyond the platform's natural end-of-life. CloudLinux will
build the security patches for you so you can keep your legacy platform secured. If this was an arcade
game: the auditor's got you, you've run out of lives and you're staring at the game over screen.
Then the continue option pops up. You pop in your coin, you get Extended Lifecycle Support, and the
auditor approves your certification. You've dealt with the immediate problem. You've mitigated the
security risks that your business was exposed to. Now that you've removed the time pressure you can
get cracking on a proper upgrade plan that will deliver actual business benefits. Maintaining the
status quo isn't something that gets me excited. Making things better is much more interesting
and when you're stuck in that position this can buy you the breathing space you need to do it.
As a bonus, the business has been forced to acknowledge the need to do something,
so you'll find getting buy-in to do the upgrade easier. If it starts to slip their mind then the
ELS payments will act as a handy reminder that "Hey this continue wasn't free. We can't keep burning up
our extra lives. We have to fix the problem." This extended support thing isn't unique to TuxCare.
All of the big vendors of something in this area - even if they don't like to talk about it as
much because they'd rather have your money for the upgrade. Microsoft can pretty much
do what they want because they own the platform. Linux is much more interesting on that front.
Take Red Hat, for example. They contribute a lot to Linux, but they don't own Linux. Red Hat can't
hoard the code to themselves. It's there for anyone to see, which opens the door to third parties like
CloudLinux to provide their own alternative or to extend it further still. TuxCare Extended Lifecycle
Support is currently available for CentOS, Oracle, and Ubuntu; with extended support for Debian in the
works as well. Given Red Hat, Canonical and Oracle have their own extended support programs, though;
why recommend TuxCare? Well... here's the thing, guys. Spending lots of money to maintain legacy systems
isn't a good investment because it's not a strategic enabler. You shouldn't be planning
that in 10 years time you're going to let your new system run past end of life and start paying for
extended support. That's a dumb plan! You're buying extended support to address a risk and get you out
of a hole while you move to something better. You don't want to throw lots of your money into that hole -
you want to have it available to spend on the upgrade instead. Let's take CentOS 6, for example.
If you wanted the official Extended Lifecycle Support from Red Hat the first thing you'd need to
do is convert CentOS to Red Hat Enterprise Linux. That means you need a Red Hat subscription, and
a Self-Support subscription isn't going to cut it for this so you'll need Standard or Premium. There
are a few different ways to slice and dice this because there are different ways to license RHEL.
A single subscription can cover two virtual servers, or only part of one physical server. For the
purpose of this comparison I'm going to assume two virtual servers. That means your cheapest
licensing option is a single Standard edition subscription at $799 per year. If you only had
a single server you needed to cover then the per-server cost effectively doubles, so I'm trying to
be fair here and assuming that you're getting full use of the subscription's virtualisation rights.
This doesn't give you Red Hat extended support, though - it just makes you eligible to purchase it.
The extended support will set you back an additional $249 per server, per year;
so the total cost to cover two virtual instances of CentOS 6 for one year using Red Hat's own
program is $1,298. TuxCare ELS for the same two servers for one year would be $85. You
don't have to buy a full year either. TuxCare's ELS can be purchased on a monthly basis for
$4.25 cents per server. That's why I thought TuxCare was worth featuring. When you can
mitigate the security risks on a legacy server for the cost of a cup of coffee you don't need to rush
into a knee-jerk upgrade. You can afford the time to do better. "How does this work?" I hear you ask.
I'm glad you asked, because I recorded a demo; and if you didn't ask I'd have been wasting my time.
Here's a virtual machine running CentOS 6. this is CentOS 6.10 which was the last release, but
I've installed this in 2021 so as soon as I try to install any updates I'm going to have a problem.
Yup. The update servers have all been retired so although I've installed the latest point release
I haven't got all the updates that were ever released for it. My kernel version is 2.6.32-754.
I can get around this. If I point YUM at the CentOS Vault repos for 6.10 it will find some updates.
After installing those it brings my kernel version to 2.6.32-754.35.1. That's it, though.
There are no more updates available, but there are still vulnerabilities. We can address those
by switching over to TuxCare, which I can do by downloading a script and running it with
my license key added on the end. That was it. Now if I run "yum update" there are more patches available.
If I install those you'll see my kernel version has now jumped from
2.6.32-754.35.1 to 2.6.32-754.35.7. Easy-peasy and I'm good for another few years of security updates.
Of course the goal is not to just limp on for another few years and end up back in the
same position again. The goal is to address the security risks, get the auditor out of my hair,
and then go plan and upgrade to something better than this decade-old platform I've been using.
That's pretty much a wrap, but one caution I would through your way is to check the
list of packages that are covered by TuxCare. It covers the big hitters, but not absolutely everything;
and if you've installed software from outside the core repos then you're probably out of luck.
It's support for the core operating system, not anything you could possibly install on it.
This means you might still not pass your audit if you've got an unsupported
application on there as well. For example: Apache, PHP, OpenSSL? All covered. NGINX or NextCloud?
No. This isn't a TuxCare or even a Linux-specific issue. If you're in the Windows world and move a
Windows 2008 server into Azure for the extended updates, that still only covers the operating system and
does nothing for the legacy version of SharePoint or Exchange that you had installed on top of it.
Plan accordingly. If you have any questions about Extended Lifecycle Support then drop a message in
the comments and I'll pop it over to the team at TuxCare. Don't be shy! I'm also interested to
hear if you have any legacy end-of-life platforms in production. What's forcing you to keep them
around? Are you struggling with management, or is it a problematic vendor? Maybe someone else will
chime in and suggest something that helped them get rid of it. Alright; thanks for watching this
one to the end, guys. If you click that like button I would appreciate it, and if you're not subscribed...
what are you waiting for? Thanks for watching, guys. See you next time!