It's about offloading blame. If a server nukes, it's on infra to get a guy to unscrew it. If a service nukes, infra guy says "welp it's down", keeps on clicking.
It doesn't matter what happens 6m-2y down the road, your odds of being laid off or job hopping are high in the current regime so this all makes sense. You pay some amount of your budget to make your life "easier" in the now.
The trouble comes 2-5y down the line when the service is bought out by <insert MEGACORP here>, and you have to scramble to replace it or hold your nose and pay up.
(tbh, migration is not that hard, but the org will act like it is)
The matrix of authentications, compliances, and intranets will only go up as your company grows and often are enforced by people who do not suffer them daily.
Not your problem under the hot potato model. It's not impossible and here's the other thing: it often doesn't matter if things get broken to your megacorp as long as you keep up appearances with clients.
Sorry if this sounds really grim / cynical, I've simply seen enough of these kinds of migrations to know that it is fundamentally opposite of my perception of engineering philosophy. It often becomes more of a question of business rather than correctness. (Can we simply fire the smaller customers? -> yes.)
It doesn't matter what happens 6m-2y down the road, your odds of being laid off or job hopping are high in the current regime so this all makes sense. You pay some amount of your budget to make your life "easier" in the now.
The trouble comes 2-5y down the line when the service is bought out by <insert MEGACORP here>, and you have to scramble to replace it or hold your nose and pay up.
(tbh, migration is not that hard, but the org will act like it is)
The matrix of authentications, compliances, and intranets will only go up as your company grows and often are enforced by people who do not suffer them daily.