About
What CloudYukthi is, why it exists, the idea of "yukthi" behind the name, and the person writing it.
CloudYukthi joins “Cloud” with Yukthi (யுக்தி), a Tamil/Sanskrit word for logic, reasoning, and clever technique. The idea is simple. Cloud work done well isn’t about knowing the most services. It’s about reasoning clearly under real constraints. Cloud, with logic.
Most cloud content covers the “what”: the service, the config, the happy path. This site is about the “why”: the trade-offs, the constraints, and the thinking that decides whether a design holds up in the real world.
Yukthi is an old idea: the clever, reasoned move that achieves more than raw force. Two stories have always captured it for me.
When Rama’s army reached the sea, they didn’t try to fight the ocean. They built a bridge across it. The challenge wasn’t the enemy, it was the water, and the answer was to engineer a way through it. Good architecture is often the same. The hard part isn’t the adversary, it’s the constraint, and the win is a design that works with it.
When Alexander faced the Gordian Knot, told that whoever untied it would rule Asia, he didn’t pick at the strands. He cut it. Sometimes the clever move is to solve the problem at a different level: the difference between optimising a process and asking why the process exists at all.
Two traditions, one habit: understand the constraint before reaching for force.
Sources & further reading: retellings drawn from Valmiki’s Ramayana (the Setu bridge to Lanka) and classical accounts of Alexander and the Gordian Knot by Plutarch and Arrian.
The writing sits across two lenses:
- Technical: cloud architecture and design reviews, multi-cloud, AWS how-tos, migration case studies, cost optimisation, and AI / GenAI. The mechanics of building things that hold up in production.
- Leadership & Strategy: delivery, stakeholder alignment, technology strategy, and the organisational side of decisions that engineering docs often leave out.
There’s a story in the Mahabharata that captures why I take both seriously. Krishna never lifts a weapon. He guides the chariot and offers counsel, and that turns out to be the decisive contribution. The person who shapes the reasoning often matters as much as the one who acts. So the two lenses are really the same habit, reasoning carefully about constraints, applied at two altitudes: the architecture diagram, and the delivery plan around it.
The lenses are just how I group things. Posts are also tagged by topic (cloud architecture, multi-cloud, GenAI, cost, reviews, delivery, and more), and that list grows as I write. You can filter either lens on the blog.
The voice is practitioner-first: grounded in what actually works and why, not what sounds good in a slide. Much of it is written in the open, because I’d rather share the thinking as it develops than wait for a perfect conclusion. The occasional open-source project is where ideas become something you can run and build on.
Whitepapers sit separately from the two blog lenses. They are longer, versioned research publications for topics that benefit from a more structured framework and reference trail.
I’m Pushparaju Thangavel, a Cloud and AI architect who has spent well over a decade designing, delivering, and scaling enterprise platforms for large organisations. The title matters less than the habit behind it, and that habit is what this site is about.
Technical designs are easy to admire and harder to deliver. That gap, between the architecture everyone nods along to in a review and the system that actually runs in production, is the thing I keep coming back to. Most of what I write here lives in it.
I’ve spent enough time close to real delivery to know where designs tend to break. Rarely on the whiteboard, usually in the messy middle: the constraint nobody named, the trade-off that got deferred, the operational reality that only showed up under load. So I’ve learned to treat those as the main event, not the footnotes. The interesting part of the job is the reasoning that survives contact with production.
The way I work comes down to a few convictions:
- Start with the constraint, not the solution. The budget, the deadline, the team’s operating reality, the thing that can’t change. That’s what shapes a good design. The services are the easy part.
- Reasoning travels further than answers. A decision is only as good as the team’s ability to understand and evolve it. The best architecture pays off only when the people around it can confidently run it, so I care as much about making the thinking transferable as the design itself.
- Strategy and delivery are part of the engineering. Alignment, sequencing, the trade-offs nobody wrote in the design doc: they decide whether good technical work ever reaches production. I take that as seriously as the code.
- Simple beats clever, most of the time. The design a team can operate at 3am beats the elegant one they can’t. I’d rather ship something well understood than something impressive that only its author can reason about.
A good part of my work is about people as much as technology: enabling engineers and architects, mentoring teams toward independent delivery, and speaking at events on cloud, AI, and building things that last. The best outcomes I’ve been part of had less to do with a single clever design and more to do with the team around it knowing exactly why each decision was made. So much of what I do is making the reasoning visible, so that the people who inherit a system can carry it forward without me in the room.
Writing here is an extension of that. It’s how I think a problem through, and where I share the reasoning as it develops rather than waiting for a tidy conclusion. If a post saves someone an expensive detour, or gives them a sharper question to ask in their next review, it’s done its job.
Away from the keyboard, I’m curious about how good decisions get made in general, in engineering, in organisations, and in the old stories that gave this site its name. The through-line is the same one that runs across everything here: understand the problem before reaching for the tool.
If something here is useful, or you see it differently, I’d genuinely like to hear it. A good, thoughtful conversation is always welcome. The Contact page has all the ways to reach me, or connect on LinkedIn: