The Problem

Parser's cloud bill had been climbing steadily for over a year. The growth tracked loosely with their user base, which made it easy to accept as a natural consequence of scaling. But when the team looked more closely, the correlation was not as clean as it seemed. Spend was growing faster than usage in several areas, and nobody had a clear explanation for why.

The root issue was that Parser had no accurate picture of which services were driving which costs. Their infrastructure had been built incrementally, and over time a number of services had accumulated resource allocations that no longer reflected how they were actually being used. Some services that had been critical at an earlier stage of the product were still running at full capacity even though the workloads they supported had been absorbed by newer components. Others had grown dependent relationships with services that no longer needed to exist at the scale they were provisioned for, and because those dependencies were not clearly documented, nobody had felt confident decommissioning or downsizing them.

Every conversation about reducing cloud spend hit the same wall. Engineers were reluctant to touch resource allocations for services they did not fully understand, because they could not be certain what would break downstream if they did. The safer option was always to leave things as they were. The result was a cloud environment that had been optimized for caution rather than efficiency, and a bill that reflected it.

How Parser Used STRAND

Parser deployed STRAND to get a complete, accurate map of their service dependencies before attempting any infrastructure optimization work. The rationale was straightforward: you cannot safely reduce or decommission anything if you do not know what depends on it. The dependency graph gave Parser's team the foundation they needed to make infrastructure decisions with confidence instead of caution.

The map surfaced several things immediately. A number of services that engineers had assumed were still actively used turned out to have no live downstream consumers. Others were running at resource allocations set during an earlier period of much higher load, with no mechanism in place to flag that the load profile had changed. The dependency graph made these situations visible in a way that manual audits and cloud cost dashboards alone had not been able to.

With the full service graph available, Parser's engineering team ran a systematic review of every service flagged as either orphaned or over-provisioned. For each one, STRAND's dependency map confirmed whether any live consumers existed and what the downstream impact of a change would be. Services with no active dependencies were decommissioned. Services with outdated resource allocations were right-sized. Changes that would previously have required a lengthy investigation just to determine whether they were safe to make were completed in a fraction of the time.

Parser also adopted STRAND's change impact analysis as a standing requirement before any infrastructure change, which gave the team ongoing confidence that optimization work would not produce unexpected downstream failures. The combination of accurate dependency visibility and pre-change impact analysis removed the hesitation that had been keeping unnecessary infrastructure running.

The Results

Parser reduced their monthly cloud spend by 60 percent. The savings came from two places: decommissioning services that had no live consumers and right-sizing services that were provisioned well beyond their actual load. Neither of those actions was technically complex. What had made them difficult before STRAND was the absence of a reliable way to verify that making them was safe. The dependency map removed that obstacle.

Seventeen services were decommissioned during the optimization period. Each one was confirmed orphaned through STRAND before any action was taken. No downstream failures resulted from any decommission. The confidence to make those calls decisively, rather than hedging with reduced allocations or leaving services running indefinitely, came directly from having a live, accurate picture of the dependency graph to work from.

The full optimization process, from initial audit to completed right-sizing and decommissions, took eight weeks. For an infrastructure review of that scope, that timeline reflected how much faster the work moved once the dependency questions were answerable without manual investigation. Parser's engineering team described the process as the first infrastructure audit they had run that did not feel like guesswork.

Looking Ahead

Parser now runs ongoing infrastructure reviews using STRAND as the primary reference. Services that drift toward over-provisioning are caught earlier, and the dependency map makes it straightforward to evaluate whether any proposed change is safe to make before it is made. The cloud spend reduction achieved during the initial optimization has held, and the conditions that produced the problem in the first place have been addressed at the structural level rather than patched over.

"We knew we were overspending. What we did not know was why, or what was safe to change. Every time someone proposed cutting a service, the conversation stalled because nobody could say with confidence what depended on it. STRAND answered that question for every service in our stack, and the optimization work that had been stuck for months was done in eight weeks." Head of Infrastructure, Parser