I've said this in various forms. Let's make it official...

Paul's law: All new build tools are better than what came before. Until they are able to solve all of the problems of the thing they replaced and then they're at least as bad. A new tool will then replace them

Gradle never really replaced maven. Contrast that to pip which “just doesn’t work” for complex projects.

True... maven has some real staying power! Which must prove that wishing doesn't work

> considering the benefits of moving to cloud (which are real!) but not the costs

I was being very tongue in cheek :)

> if by moving to the cloud you get someone else to take on that aspect of it, but otherwise keep your job, then aren't you always going to prefer cloud?

Quite possibly, yes. Paraphrasing Dan North: "Infrastructure is like surgery. If you need surgery, you really want to have surgery. But you always want to have the smallest amount of surgery possible."

Having a rack in a basement or co-lo might be "cheaper" for you. It might end up being a pain. The BMC infrastructure was relatively simple. We were early adopters of EC2 (so the financials _might_ have changed since then), we saved about 60% in explicit cost by shifting from co-lo to EC2. And my time was freed up because I didn't have to plan for or handle anywhere near as much infrastructure work.

We didn't make money directly from infrastructure so it always made sense to reduce the amount of infra I had to do because it increased the time I could spend closer to revenue generation

In a small organisation without enough staff to cover revenue generating roles I'd expect the cloud almost always makes sense. The opportunity cost of giving up revenue generation to save on infra costs is unlikely to work out. Sadly I suspect that in a large organization the people who look after hardware get laid off rather than moved closer to revenue generation!

Since folk like DHH and Ahrefs are posting their savings from running workloads outside of the cloud, I thought I'd join in

Where did DHH post his?

I really don't miss running my own kit (colocated or directly owned)

I don't miss cycling around Manchester on a Bank Holiday weekend because I'd miscalculated how much network cabling I'd need for an upgrade.

I don't miss keeping a spreadsheet of storage so I knew when to order disks, negotiating with suppliers for cost of new disks because I was buying a slightly smaller bulk than AWS

I don't miss having to explain to folk in datacenter support that they could take the disks out of my failed server and put them in a new server if they had one available

I don't miss the day the single point of failure in the rack failed and everything was offline while I waited for a new doohicky to be shipped to me because it didn't make sense to keep spares of everything on hand

I don't miss trying to figure out if some new generation of server hardware would work for or would fit in my rack as manufacturers stopped making the kit we did use

I'm not going to say every workload should run in the cloud (cliche nod to StackOverflow) but it certainly isn't free to get all of the benefits

> terms like "familiar", "comfortable", "confident" to indicate the amount I've used a particular language

I'd be honest about what you've done

* wrote Hello World in Rust * built a simple API with NodeJS * completed TDD kata in C#

or whatever it might be.

Bonus points for linking to git repos so the recruiter can see what the code looks like

If you are entry-level the recruiter should be looking at things like your history of learning to see how you'll grow in the role much more than they're looking at your exact experience.

"team is 3 people" and "this code generates more than 20 million dollars a year of revenue"

Whatever else you do, I hope you and the organization figure out how to celebrate that those three people are generating 20 million dollars of revenue (or at least keeping part of the machinery that does that running.

"I know a full rewrite is necessary, but how to balance it?"

Well, maybe...

How much code is it? How much traffic does it receive?

----

I would be looking at https://martinfowler.com/bliki/BranchByAbstraction.html or https://martinfowler.com/bliki/StranglerFigApplication.html

that's far too considerate an opinion to put on the internet :)

A bit like introducing immutability removes bugs you don't understand... each time I see us replace some `useState` `useEffect` orchestration with a kea logic things get less buggy