Sometimes you're already in the hard low-impact situation and you didn't choose it
Legacy systems put you there. Compliance requirements put you there. Architecture decisions made three years ago by people who are no longer at the company put you there
The bill is high. The fixes are painful. And the savings from any individual fix don't justify the effort on their own
This is a real situation and pretending it isn't helps nobody
Here's how I think about it when I'm in it
First: separate what's hard because of technical complexity from what's hard because of organizational complexity
Technical complexity can sometimes be reduced. A legacy service that's expensive to run might be replaceable with something simpler. Or it might be containerizable. Or its costs might be reducible with a configuration change that doesn't require a rewrite
Organizational complexity is different. Something is expensive to change because it touches too many teams, or because there's no clear owner, or because everyone is afraid of breaking something they don't fully understand. That's a people and process problem dressed as a technical problem. Solving it requires alignment before architecture
Second: look for the compound change
Sometimes one hard change removes several expensive constraints at once. A service migration that's painful to execute but that eliminates an entire category of infrastructure. Worth the pain if the savings stack across multiple problem areas
Third: accept that some things won't get fixed soon and make sure you're not paying more than necessary to run them as they are in the meantime
Rightsizing a legacy system you can't replace is still worth doing
Reserved instances on workloads you're stuck running are still worth buying
Being stuck in the hard low-impact quadrant doesn't mean doing nothing
It means being strategic about which parts of the problem you can actually move
And being honest about which parts you can't
Top comments (0)