So.. the software team I work with still maintain Java 6 apps.. meanwhile management keep asking when we're "moving to the cloud".

DevRant posts are too small for me to describe our technical debt.... 🤦

Oh my God, hearing that makes me bleed. I am so happy to work at a company where we use Java 17 and will switch to 19 in the next year

Oh fuck...

@PonySlaystation yeah, it's a painful one.. most of it, I believe, is linked to the existence and usage of one particular internal `Utils` package? Basically, this "library" of functions effectively do what Java's own API methods do, but "better" (according to, well, someone..).

The way this is integrated into every one of our systems is scary.. basically, our jump from 6 to 7, will be about as much fun as the rest of the world experienced going from 7 to 8.. 🤦

I say fuck it: freeze the current repo in place, and rewrite in a current day JDK, **without** trying to override everything it exposes.

But hey, I don't "do Java" myself.. I'm just a web dev.. 🤷‍♂️

@ZaLiTHkA mgmt who asks "when are you moving to the cloud" is tech debt in on itself.
Frankly, be happy that they aren't asking you to "pivot to video" or some other stupid outdated, disproven buzzword.

@JsonBoa oh indeed.. fully agree with you there.

FWIW, I actually did a full cloud migration plan for these same people, like, 3 years ago? Meh.. who knows, at this rate I'll have a new job before that gets implemented.

Then tell the manager to buy an extremely expensive EC2 instance with a CentOS 6 image, deploy it the same way and that's it: We're in the cloud!!!!

This is a joke. Or not...

Cloud move without any reason to back it up, as in a goal in itself. Almost as stupid as sticking with a platform that gets no security updates (and it's not completely isolated from any arbitrary input)...

@hjk101 Crazy times when vendor lock-in became chic.

@codingfreedom in my experience cloud lock-in is extremely low.
The lock-in comes from none generic service dependencies. Sometimes this can happen with cloud services but mostly it's things like a CRM or book keeping service because actual business processes go in there and users are trained to use them; and we use their highly specific APIs for integration/automation.

In cloud infra/provider I've never felt the lock-in and migrated multiple times. For instance a cloud SQL or DNS have the same standard protocol and export/import formats. Even a storage service like S3 has an API that is supported by just about every cloud and on-site storage system.

A mail gateway usually has both SMTP and API support. If you use these kind of specific APIs/services you should abstract them in your code regardless of cloud or on site.
For example an e-mail for the business logic is template (id) and substitution variables. Now any system that supports templates can be used and you can even build your own layer with any template engine if you want that level of control.