You can't create "technical debt" if you don't change anything in the first place.
> You can’t create “technical debt” if you don’t change anything in the first place.
Rubbish. The bits really do rot, and if you don’t do _something_ on occasion you end up with an entire data center no one wants to touch because the dust in the servers might be structural at this point.
I’m not saying go rewrite your apps against the Kafka instance your junior devs are fucking with, but you have to do something to fight the entropy.
The counter-story to yours is running that database on MongoDB in the cloud on a cluster. Instead you'd be having crazy MongoDB issues, data inconsistencies, connectivity issues when the cloud is down, etc etc.
The solution is somewhere in the middle. You can have modern, supported hardware running a LTS Linux and that counts as boring.
Stuff breaks. So you fix it. Boring old stuff needs fixing too sometimes. Problem is, old stuff gets obsolete, can't get replacement parts, because of progress. (or something). It's the same story since the first looms were made centuries ago.
What you can't fix you can't really depend on. Our time scales are just compressed to ridiculousness because the pace of change is off the charts these days. So basically, you can't really depend on anything working more than a few months before falling over. Sucks.
Important things go onto clusters, or at least have a (hot or cold) standby server.
Or it may simply not meet the needs of users anymore.
I would hardly hold the air traffic control system up as a model to aspire to, for example. The only reason we run the old one is that the upgrade attempts all failed.
Tell that to your security team.
Don't screw with it and it will have security issues after a few months?
