The Transformation Diaries Week 3: The Cloud Estate Nobody Really Understands
Week 3 of The Transformation Diaries is here. Westbridge has hundreds of workloads, applications and services across its cloud estate, but does anyone really understand what is running, why it exists, who owns it, and what is actually needed? This week, Narayan starts connecting the dots across architecture, dependencies, ownership, inconsistent tagging and cost while learning that sometimes transformation starts by questioning the things we've always believed were essential.
Series: The Transformation Diaries - 52 Weeks Journey (10 articles)
- …
- 3The Transformation Diaries Week 3: The Cloud Estate Nobody Really Understands This article
By Monday morning, Narayan had recovered from the previous week.
Mostly...
The difficult conversations were still somewhere in his head. Everyone at Westbridge wanted transformation, but everyone seemed to be looking at it from a slightly different angle.
Narayan had spent enough time over the weekend thinking about all of it.
By Monday morning, he had decided on a simpler approach.
One problem at a time.
Unfortunately, Finance already had one waiting for him.
A simple question from Finance
Monday hadn't been going particularly badly when Narayan received a message from Daniel Foster, Westbridge's CFO.
Daniel wanted a quick conversation.
Narayan had met him briefly during his first week, but they hadn't spent much time together. Daniel wasn't particularly interested in whether an application should run on EC2, containers or a managed AWS service.
He was interested in what all of it meant for the business.
Over the years, Westbridge's AWS footprint had continued to grow. More applications had moved to the cloud, new platforms had been built, and AWS had become an important part of how the organisation operated.
Daniel understood that moving to AWS didn't automatically mean spending less. But he had also been told that optimisation was happening. Instances had been rightsized. Teams had made efforts to remove unused resources. Some workloads had moved towards more efficient AWS-native services. Commercial commitments and other optimisation opportunities had been reviewed. The expectation wasn't that the AWS bill would suddenly collapse. But over time, those improvements were supposed to create efficiencies.
From where Daniel sat, however, he wasn't seeing them.
“I keep hearing about optimisation and the efficiencies we're creating. But when I look at the numbers, our AWS cost isn't going down. It's going the other way.”
Narayan didn't answer immediately.
Daniel continued.
“I'm not expecting cloud to magically become cheaper every year. I just want to understand something. If we're becoming more efficient, why isn't that showing up in the bill?”
That was a much better question.
There were plenty of possible explanations.
Westbridge might genuinely be consuming more technology. Business growth could be absorbing the savings. New applications might be arriving faster than old infrastructure was being removed. Individual optimisation initiatives might be working while the overall estate continued to expand.
Or perhaps some of the efficiencies Westbridge believed it had created weren't as significant as everyone thought.
Narayan could speculate all afternoon.
Instead, he gave Daniel the only answer he could defend.
“I don't know yet.”
Daniel looked at him.
“I can give you ten possible reasons,” Narayan continued. “But that isn't the same as giving you the right one.”
Before Narayan could explain why Westbridge's AWS cost continued to grow, he needed to understand what Westbridge was actually running, why it was running, who owned it and what the business genuinely needed.
That turned out to be considerably harder than expected.
There wasn't one architecture to understand
Narayan started looking across Westbridge's AWS environment with Raghu. It quickly became obvious that talking about the Westbridge architecture was almost misleading.
There wasn't one architecture to understand. There was an entire cloud estate.
Westbridge had multiple business divisions, each supported by different applications, platforms and infrastructure that had grown over years. Some applications lived entirely in AWS. Others still depended on systems running on-premises. Some were relatively new. Others had been moved to AWS years ago and had barely been reconsidered since.And then there were the 500+ EC2 instances Narayan had started questioning the previous week. The number was beginning to make more sense.
Those instances weren't supporting one giant architecture. They were spread across applications, environments, platforms, operational systems and supporting infrastructure across Westbridge.
There were architecture diagrams too. Lots of them. Application diagrams. Network diagrams. Security diagrams. Migration diagrams. Confluence pages. Design documents from old projects. Some were detailed. Some were useful. Some were several years old.
And some described an environment that had changed so much that Narayan found himself switching between the diagram and AWS trying to work out whether he was looking at the same system.
At one point, after going through yet another document that no longer quite matched reality, a thought crossed his mind.
“I can already see a few use cases for AI here. Keeping architecture diagrams and documentation aligned with what's actually deployed would be one of them.”
He made a note and moved on. There were more immediate problems to understand first.
The issue wasn't that Westbridge had no documentation. It was that no single diagram or document could explain the technology landscape Westbridge had become.
Architecture by accumulation
As Narayan and Raghu continued through the environment, a pattern started appearing.
Nobody had sat down one day and designed the Westbridge architecture exactly as it existed today. It had accumulated.
A migration programme had added one set of patterns.
A new business application had introduced another.
An acquisition had brought its own systems.
A security requirement had added another layer.
A deadline had created an exception.
A temporary workaround had quietly become permanent.
Different teams had solved similar problems in different ways. And AWS itself had evolved significantly while all of this was happening. Narayan found two applications doing broadly similar things but running on very different infrastructure. His first reaction was predictable.
“Why did we build this one like that?”
Raghu knew the history.
At the time, there had been different constraints. Different skills. Different AWS capabilities. And, most importantly, a deadline that didn't particularly care about architectural elegance.
Narayan smiled.
It reminded him of something Raghu had said the previous week.
“The answer wasn't necessarily wrong. The question had changed.”
That sentence was starting to make more sense.
Westbridge's architecture hadn't been designed once. It had been designed hundreds of times, one project, one deadline and one decision at a time.
The challenge wasn't judging those decisions with today's knowledge.
It was working out which of them still made sense today.
The diagram was only one view
Narayan and Raghu picked a few applications and started following them properly. Not just through the diagrams. Through the actual environment.
An application that looked relatively straightforward on paper could depend on EC2 instances, load balancers, databases, storage, DNS, networking, security services, monitoring and perhaps an integration back to something still running on-premises.
That was the infrastructure view.
Then there was the application view.
What business capability did it provide?
Who used it?
How important was it?
What other applications depended on it?
And then came the operational view.
How was it deployed?
How was it patched?
Who monitored it?
How was it backed up?
What happened when it failed?
Could its infrastructure still be recreated from code, or had years of changes left the running environment looking quite different from the code that originally created it?
An architecture diagram could show a perfectly sensible collection of boxes and arrows.
It couldn't necessarily tell Narayan how difficult those boxes were to operate.
The more he looked, the less useful one question became:
What does the architecture look like?
A better question was emerging.
“How does this actually work?”
And that was proving much harder to answer.
Need, want... or simply what we've always done?
There was another word Narayan kept hearing during the week.
Need.
“We need those servers running all the time.”
“We need dedicated infrastructure for this application.”
“We need separate environments.”
“We need that much capacity.”
“We need to keep this architecture.”
Narayan wasn't interested in challenging every statement simply for the sake of challenging it.
Some of those requirements were completely legitimate.
Business criticality.
Regulatory requirements.
Technical limitations.
Resilience.
Recovery requirements.
Isolation.
Sometimes the answer was obvious.
But there was an important difference between something being required, something being preferred, and something simply being inherited.
So Narayan started asking a very simple follow-up.
“Why do we need it?”
Sometimes there was an immediate answer.
He moved on. Other times there was a pause.
Then came a phrase Narayan had heard in many organisations over the years.
“That's how we've always done it.”
Those were the ones he wrote down.
The question from the previous week had been:
Why does Westbridge have more than 500 EC2 instances?
Narayan was beginning to think that wasn't quite the right question.
The better questions were:
What are they supporting?
Why are they there?
And which of them does Westbridge genuinely need?
Then they tried to find the owners
Understanding what existed was difficult enough.
Working out who owned it was sometimes harder.
Narayan and Raghu started following resources back through applications, teams and business divisions. Some were easy. Others weren't.
Tagging across Westbridge had evolved much like the architecture itself.
Inconsistently.
Some teams had good application, environment, owner and cost-centre tags. Others had some of them. Some had outdated values. And some resources had almost nothing useful at all.
Raghu looked at one of the resources they had been trying to trace.
“Apparently everything in AWS has an owner. Finding them is the optional feature.”
Narayan laughed. Then he looked back at the screen.
It was funny until you thought about the consequences. Because ownership wasn't just about knowing who to call when something broke.
If Westbridge couldn't reliably connect:
Infrastructure → Application → Owner → Business Unit
then there was another connection it would struggle to make:
Business Unit → AWS Consumption → Cost
And that brought them straight back to Finance. Westbridge wanted better visibility of what different parts of the organisation were consuming. Perhaps eventually that would mean showback, where teams could clearly see the technology costs associated with what they consumed.
Perhaps it would become chargeback, where those costs were allocated back to the relevant business units.
But Narayan could already see the problem. If the underlying ownership and tagging weren't reliable, the numbers wouldn't be either. You couldn't build a credible chargeback model on top of:
We think this belongs to them.
Suddenly, the CFO's question from Monday looked very different.
“Why isn't our AWS cost going down?”
Narayan could see the bill.
What he couldn't yet see clearly enough was the story behind the bill.
By Friday, the architecture looked worse
Which, strangely, Narayan considered progress. On Monday, Westbridge's AWS estate had looked like hundreds of resources spread across accounts, applications and teams.
By Friday, some of those resources were beginning to have context. The infrastructure was becoming applications. The applications were becoming dependencies. The dependencies were becoming operational responsibilities. And those responsibilities were slowly connecting back to owners, business units and cost.
There was still a lot they didn't understand.
But Narayan was starting to see Westbridge less as a collection of AWS resources and more as an interconnected technology landscape. And perhaps that was the first step.
Before you optimise something, you have to understand why it exists.
And before you transform it, you have to be willing to question whether it still needs to exist in the same form.
The secret ingredient
That evening, Narayan wanted something that required considerably less thinking than AWS architecture.
He ended up watching Kung Fu Panda, yup you heard that right !!!
He'd seen the movie before, but this time a conversation between Po and his adoptive father, Mr. Ping, caught his attention.
Po had spent so much time wondering about the secret ingredient in his father's famous soup, only for Mr. Ping to finally reveal the truth:
There was no secret ingredient.
The soup was just soup. There wasn't a special sauce or some hidden ingredient that made it different.
Mr. Ping's lesson was much simpler
To make something special, you first had to believe it was special.
Narayan smiled.
Apparently, after a week of AWS architecture workshops, he was now taking transformation advice from an animated goose.
But the idea stayed with him.
He had spent much of the week hearing about things Westbridge needed. Servers that needed to run 24×7. Applications that needed dedicated infrastructure. Environments that needed to remain separate. Architectural patterns that couldn't change.
Some of those requirements were absolutely genuine.
But how many were still considered essential because Westbridge had spent years believing they were essential?
Maybe there wasn't always a secret architectural ingredient.
Maybe there wasn't a special technology, a new AWS service or a clever transformation framework that would suddenly make everything better.
Sometimes the first step was much simpler.
Transformation isn't always about finding the secret ingredient. Sometimes it's about questioning the ingredients you've always believed were essential.
Narayan liked that thought.
Perhaps the challenge at Westbridge wasn't simply deciding what new technology to introduce.
It was also having the courage to question what was already there.
Narayan closed the laptop.
Daniel's question from Monday was still waiting.
If Westbridge was becoming more efficient, why wasn't that showing up in the bill?
They had spent the week beginning to understand what Westbridge had, why it existed and what it genuinely needed.
Next, they needed to understand what all of it was costing them — and why.
Next week in The Transformation Diaries
Week 4 — The Cloud Bill Nobody Wants to Talk About
Series: The Transformation Diaries - 52 Weeks Journey (10 articles)
- …
- 3The Transformation Diaries Week 3: The Cloud Estate Nobody Really Understands This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article