Transforming a Global SaaS Platform
From architectural complexity to a platform that cost less to run every quarter.
The situation
CloudHealth helped enterprises understand and control what they spent across AWS, Azure and Google Cloud. To do that it had to ingest an enormous volume of billing and usage data from providers who each described the same concepts differently, normalize it, and give a customer an answer they could act on.
The platform worked. It had also grown the way successful platforms grow: a monolith with a batch pipeline, extended year after year to cover more providers and more customer questions.
By 2020 three things were true at once. Performance degraded as customer estates grew, so the largest accounts had the slowest experience. Data lineage was unclear enough that answering where did this number come from took engineering time rather than a lookup. And infrastructure cost scaled with the volume of data processed rather than with the value delivered, which meant growth made the economics worse instead of better.
None of those were separable problems. The cost problem was a data-architecture problem. The data-architecture problem was a team-shape problem, because a handful of engineers could not modernize a platform of that size. And all of it had to happen while the platform kept serving customers, because there was no window in which to stop.
The question underneath — what is this compute actually costing us, and what are we getting for it — was not new to me. I had been working on versions of it since the datacenter era, when enterprises paid for their infrastructure upfront and had no invoice to read. This was the same question with a bill attached.
What made it hard
Strategically. Every quarter spent on modernization was a quarter not spent on features, and the feature pressure was real. The investment case had to hold for two years, not one. I had to argue that a slower feature quarter now bought both cheaper operation and faster delivery later, and then be right about it.
Technically. Decomposing a monolith is tractable when you know who depends on what. Here, downstream consumers had grown up inside the same codebase and relied on internal assumptions nobody had written down. Every service we pulled out risked breaking something that had never been specified as an interface. The lineage problem and the decomposition problem turned out to be one problem: we could not safely separate what we could not trace.
Organizationally. There was no data platform organization. I had moved across from the team building our OCI support, from tech lead into the engineering manager role, which meant the product knowledge and the hiring both sat with me at the same time. Hiring into a moving target is harder than hiring onto a stable one, because the thing people are joining keeps changing shape while they onboard. I needed engineering managers and architects who could hold a piece of the target themselves, and I needed them before the work peaked rather than after.
What I did
I set the modernization strategy and its sequence: trace the data first, decompose around the traced paths, then move the pipeline from batch to event-driven so data arrived in minutes rather than at the end of a cycle. Normalizing multi-cloud data into one model was the spine of that work, and later support for an additional platform was the test of whether the spine held.
I made the call on the distributed SQL engine that became the analytics layer, and led its evaluation and adoption.
The data platform organization started with me. I hired four engineers as the first cohort, and it grew past forty. I built its leadership layer deliberately rather than by accretion, running readiness against a consistent set of questions for every person: ready now, ready in about a year, high potential, strong where they are, or performance concerns — and for anyone I thought was ready, what specific evidence supported the move. The framework mattered more than any individual call, because it meant promotion conversations were about evidence rather than about visibility.
The record is plain. Several engineers moved from junior to senior, a few from senior to staff, and one engineer I promoted into engineering management. The rest of the management layer I hired. Interns converted to full-time roles where the fit was right.
The managers and architects owned execution inside their tracks. I owned the target, the sequence, and the trade-offs between them. Working with finance, we built the cost model that made the economics case legible to people outside engineering — which is what turned modernization from an engineering preference into a funded plan.
The decisions
Rewrite or decompose
The fork. A clean rewrite against incremental decomposition around live traffic. A rewrite would have been faster to reason about and could have been designed correctly from the start.
The call. Incremental decomposition, service by service, with the monolith serving traffic throughout.
The cost. We ran in a hybrid state for a long stretch. A hybrid system is harder to reason about than either end state, and for that period engineers had to be fluent in both. Onboarding was slower, and debugging routinely crossed a boundary that would not have existed in either the old architecture or the new one.
Build the query layer or adopt one
The fork. Build a query layer tuned exactly to our data model, or adopt a distributed SQL engine built for this class of problem.
The call. I led the evaluation and we adopted Starburst. Query performance across large datasets improved substantially, and it gave the analytics platform a foundation we did not have to maintain ourselves.
The cost. We took on a specialized, higher-cost dependency whose economics assumed we would keep growing into it. That assumption was reasonable in 2020, and it was invisible as a cost for as long as it held.
One pool or specialist pods
The fork. A single generalist pool, flexible and simple to staff, against specialist pods each with an engineering manager and an architect.
The call. Pods.
The cost. Coordination overhead across pod boundaries, and it was paid by people rather than by the system. Some of the generalists who had been with the platform longest had to specialize or move on as the organization’s shape changed under them. That was a real cost to individuals, and treating it as an abstraction would be dishonest.
Sequence the work or run it in parallel
The fork. Modernize first and pursue cost reduction afterwards, in sequence — or run both at once.
The call. Both at once.
The cost. Quarters where we shipped fewer features than a pure-growth team would have tolerated, with the cost payoff arriving two to three quarters after the work that produced it. That is a long time to hold a position, and the team had to hold it on the strength of a model rather than a result.
What changed
| Before | After |
|---|---|
| Monolithic services | Independent services |
| Batch data generation | Event-driven pipeline |
| Opaque data lineage | Traceable end to end |
| Cost scaling with volume | Cost scaling with value |
| One engineer | A specialist organization with EM and architect layers |
Cloud infrastructure cost fell by approximately 80%. That reduction was within my organization’s platform spend, and it is the number I am most confident claiming directly. Performance improved by roughly 60–75%, which customers experienced as answers arriving in minutes where they had waited hours.
The business more than doubled over the modernization period. I would not claim the modernization caused that. What I will say is what we contributed: faster time to value, more features shipped per quarter once the decomposition matured, and a platform that could take on a new cloud provider without a bespoke effort each time.
What I carried forward
The thing I would do the same way is treating architecture, organization and economics as one decision rather than three. Every architectural choice here had an org-shape consequence and a cost consequence, and the choices that went well were the ones where I could see all three before committing. The ones that went less well were the ones where I saw two.
That became the default stance for everything after, and it was tested almost immediately, when the question changed from how to build to how to operate.