This is indeed something my opinion shifted in the last 2 years. Some of my superiors hate it, but they are kinda getting it after some patience.
The thing is: Slowly deprecating a service doesn't work. At least on my patience level, which is measured in years. I don't have decade level patience available.
If you announce that a service is being decommissioned, the good teams leave across some time. This time can be a month, a year but they leave. It will take longer than expected, but the good teams move and scurry and make it work. Those are the good teams, they cooperate constructively and the migrations work.
But the other teams just don't.
And there is nothing else to say about it. They don't. And you can't take it away because there's C-Level support behind those bad teams. So you can't take it away, or else high management comes around asking questions and being pushy.
To me it seems like you either invest the necessary amount of energy to maintain a service, or you invest energy to actively kill that service. There is no tolerating, there is no "low-effort maintenance". Tell the next CVE > 8 in that service it's "low effort maintenance" and kindly ask the attackers to not attack that service because it's "maintenance".
Either this is a service we offer, or we actively work on migrating things off of it.
I talked with a few infra-ish people at Facebook once upon a time, and they described effectively a "Service Assassination Team". ImageResizer1.0, ImageResizer9000, they were an actual funded team to hunt down and destroy (and presumably help migrate) people using ImageResizer1.0 (or whatever).
It seemed that was a very forward-thinking way of looking at things to prevent an eventual "big-ball-of-mud" pile of services.
Either that, or Bezos's insight that internal teams should have an API-charge, and each team had a budget for requests between systems. If you're on ImageResizer1.0, and the costs go up 10x or 1000x, you're instantly motivated to go and search for the recommended new alternative, or eat the increased API cost (which can then be directed to the "Service Assassination Team...")
The thing is: Slowly deprecating a service doesn't work. At least on my patience level, which is measured in years. I don't have decade level patience available.
If you announce that a service is being decommissioned, the good teams leave across some time. This time can be a month, a year but they leave. It will take longer than expected, but the good teams move and scurry and make it work. Those are the good teams, they cooperate constructively and the migrations work.
But the other teams just don't.
And there is nothing else to say about it. They don't. And you can't take it away because there's C-Level support behind those bad teams. So you can't take it away, or else high management comes around asking questions and being pushy.
To me it seems like you either invest the necessary amount of energy to maintain a service, or you invest energy to actively kill that service. There is no tolerating, there is no "low-effort maintenance". Tell the next CVE > 8 in that service it's "low effort maintenance" and kindly ask the attackers to not attack that service because it's "maintenance".
Either this is a service we offer, or we actively work on migrating things off of it.