I build cloud platformsgoverned by default,resilient by design,and cost-aware from day one.
I’ve spent more than ten years on cloud platforms across Azure, AWS, and OpenStack. Today I design policy-as-code guardrails, run controlled failure experiments, and make cloud and AI spend visible, so teams can ship fast without trading away compliance or reliability.
Senior Engineer, Cloud Infrastructure and Solutions
Enterprise cloud platform
2017 – 2019
M.S. Computer Science, and teaching assistant for C
University of Texas at Arlington
Open source
Outreachy intern and OpenStack contributor
Qinling, Zaqar, Nova, Tempest
2014 – 2017
Software Engineer, built an OpenStack private cloud
L&T Technology Services
Selected work
Rules teams follow. Failures we rehearse. Costs we can see.
Three stories. Each one covers the problem, what I did, the trade-offs I made, and what I learned.
Cloud governance · Azure & AWS
Securing multi-cloud environments at scale
I built and maintained governance controls across Azure and AWS, and shaped how we rolled them out so teams could adopt them without surprises.
Policy-as-code
Azure
AWS
Just-in-time access
How a policy reaches production
Write policy as code
Review and version
Run in audit mode
Handle exceptions in the open
Enforce
Read the full storyClose the story→
The problem
Policy only works when teams can live with it. Controls that appear overnight break deployments, and people start looking for workarounds. We needed better policy coverage and compliance across two clouds, without slowing teams down.
What I did
Developed and maintained governance controls across Azure and AWS.
Set up policy-as-code workflows and infrastructure automation, so policies are reviewed and versioned like any other code.
Evaluated just-in-time access practices and helped adopt them to improve identity governance.
Decisions and trade-offs
Roll out in stages, starting in audit mode.
Full enforcement takes longer, but teams see the impact before anything blocks them.
Treat exceptions as part of the design.
There is more process to manage, but every exception stays visible and auditable.
Manage policy as code.
It takes more setup than a portal, and in return we get review, history, and repeatable rollouts.
Team outcome
Policy coverage and compliance improved across both clouds, through staged, auditable rollouts and clear exception practices.
What I learned: Adoption is a design problem. The rollout plan matters as much as the policy itself.
PlaceholderScreenshot or diagram: a policy rollout view or compliance dashboard, with sensitive details removed.
Draft: decisions and lessons to confirm
Resilience engineering · Azure Chaos Studio
Building resilient data-intensive systems
I designed and led resilience testing for enterprise applications, using Azure Chaos Studio to run controlled failures and see how systems recover.
Azure Chaos Studio
Fault injection
Recovery planning
One resilience experiment
Form a hypothesis
Inject a controlled fault
Observe
Recover
Update the plan
Read the full storyClose the story→
The problem
Most applications had a recovery plan. Far fewer had tested it. An untested plan is an assumption, and an outage is an expensive way to learn it was wrong.
What I did
Designed the resilience testing approach for enterprise applications.
Led the testing with application teams, using Azure Chaos Studio to inject controlled faults.
Shared lessons on cloud resilience engineering through talks and guild sessions.
Decisions and trade-offs
Start with small, controlled experiments.
Coverage grows more slowly, but teams stay confident in the process.
Measure recovery, not just failure.
Each test needs more preparation, and the findings feed straight into recovery plans.
Keep detailed results with the teams.
This story stays high level, and teams can share findings openly with us.
Team outcome
Application teams identified opportunities to strengthen their recovery planning and reliability.
What I learned: Resilience is a habit, not a project. The second experiment is always easier than the first.
PlaceholderDiagram or screenshot: an experiment outline from Chaos Studio, with application names and results removed.
Detailed test configurations, application results, and internal findings are intentionally left out.
Draft: decisions and lessons to confirm
AI tooling · Personal projects
Making policy and AI costs easier to understand
On my own time, I built two AI tools: an assistant that helps engineers navigate governance requirements, and a project that makes AI token costs visible.
LLMs
AI agents
AI tokenomics
Two small tools, one goal
Governance guidance
Policy assistant
A clear answer for engineers
Model usage
Token cost view
Read the full storyClose the story→
The problem
Governance guidance is spread across many documents, and engineers mostly want to know what applies to them. Meanwhile AI usage keeps growing, and token costs are hard to see until the bill arrives.
What I did
Designed and built both projects myself.
Policy Governance Assistant: an AI assistant that helps engineers navigate cloud governance requirements.
AI Tokenomics: a project that makes AI model usage and token-related costs easier to understand.
Decisions and trade-offs
Answer from approved guidance only.
Answers are narrower, but they are easier to trust and check.
Show costs per model and per use.
More data to collect, and a much clearer picture of where money goes.
Personal project
Both tools are personal projects I built end to end.
Add usage, feedback, or a demo link
What I learned: Most AI value comes from narrowing the question, not from a bigger model.
PlaceholderScreenshots: the Policy Governance Assistant answering a question, and the AI Tokenomics cost view.
Draft: decisions and lessons to confirm
Writing
Field notes from running cloud platforms.
Practical write-ups from Azure platform work and OpenStack open source. I publish them on Substack.