I started my career in a windowless server room in Pune, racking servers for CLSA’s trading platforms. The room was loud, cold, and unforgiving. If a server went down during trading hours, people lost money. Not theoretically — measurably.
Fifteen years later, I work with enterprise customers designing Kubernetes platforms. The technology has changed completely. The fundamentals have not.
Here is what I have learned about what actually matters in infrastructure.
Reliability thinking starts with fear
The financial services environment where I started taught me something that no certification or training ever could: reliability is not a technical property. It is a mindset.
When you are responsible for systems that process live financial transactions, you think differently about every change. You test more. You plan more. You imagine failure modes that seem paranoid until they happen.
This mindset — obsessive reliability thinking — is the most valuable thing I took from those years. It is not about knowing how to configure a redundant pair of load balancers. It is about asking, before every change: “What is my rollback plan? How will I know if this fails? Who will notice before I do?”
The best engineers I have worked with all have this orientation. They are not the ones who know every Kubernetes flag. They are the ones who cannot sleep after a production change until they have verified it worked.
Containerization changed deployment, not operations
When Docker arrived, the industry acted as if operations would become irrelevant. Containers would solve environment inconsistency. Orchestration would eliminate manual deployment. Infrastructure would become code, and code would be perfect.
This was wrong. Not because containers are not useful — they are transformative — but because they change deployment, not operations.
Operations is what happens after deployment. It is incident response. It is capacity planning. It is backup validation. It is certificate renewal. It is the thousands of small, undramatic tasks that keep systems running. Containers did not eliminate any of these tasks. They changed the tools you use to perform them.
The organizations that understood this succeeded with containers. They invested in operational tooling. They built runbooks before they built clusters. They trained their operations teams, not just their developers.
The organizations that treated containers as a “set it and forget it” technology failed. Their clusters became unmanageable within months. Their incident response times increased. Their engineers burned out.
The lesson: technology changes the tools. Operations remains the discipline.
Communication skills are not optional
This is the most uncomfortable lesson for technical people, including my younger self.
For the first half of my career, I believed that technical competence was sufficient. If I could solve the problem, I did not need to explain it. If the architecture was correct, I did not need to justify it.
I was wrong. Technical competence is table stakes. The ability to communicate — to explain why an architecture decision matters, to convince a stakeholder to invest in operational maturity, to translate infrastructure risk into business language — is what separates effective engineers from technically brilliant but ineffective ones.
I have seen technically mediocre solutions succeed because the team communicated well. I have seen technically excellent solutions fail because the team could not explain why they mattered.
This is not about being extroverted or charismatic. It is about being clear. It is about understanding your audience and framing your message in terms they care about. The CFO does not care about etcd performance. They care about cost and risk. Your job is to connect the two.
Keeping systems running versus making them evolvable
Early in my career, I measured success by uptime. Was the system available? Were incidents resolved quickly? Were backups successful?
These are important questions. They are not sufficient.
Somewhere in the middle of my career — probably during the Docker years — I realized that keeping systems running is not the same as making them evolvable. A system that is stable but cannot change is a liability. It constrains your organization. It prevents you from adopting new technologies, responding to market changes, or improving your operational posture.
Making systems evolvable requires different thinking. It means building abstraction layers that allow components to be replaced. It means investing in automation that makes change safe, not just slow. It means designing systems that can be understood and modified by people who did not build them.
This is why I moved from operations to architecture. Operations keeps things running. Architecture makes things changeable. Both are necessary. But the organizations that survive and thrive over the long term are the ones that prioritize evolvability — not just stability.
What I would tell my younger self
If I could go back to that server room in Pune and give myself one piece of advice, it would be this: infrastructure is not about servers. It is about outcomes.
The server room taught me to care deeply about uptime, performance, and reliability. Those matter. But they are means, not ends. The end is: can your organization deliver value to its customers reliably and sustainably?
That question requires more than technical knowledge. It requires understanding your business, your users, and your team. It requires communication, empathy, and strategic thinking.
I did not understand this at the start. I understand it better now. And I am still learning.