About
Nineteen years of platforms, from GIS code to cloud economics
I build platform products and the organizations that run them — at the junction of product, engineering and economics.
Iurii (Yuri) Trukhin is a cloud and AI platforms leader. His path runs from geospatial systems engineering in Java, through a public cloud provider, to running a cloud development center at MTS and the GPU service line built on it; then Developer Experience at JetBrains; now infrastructure reliability, FinOps and agent tooling at CloudLinux, remote from the Netherlands. The common thread: platforms as products, judged by unit economics and by whether engineers choose to stay.
This page is a verified chronology. Where a fact has a boundary, the boundary is stated with it — that is deliberate, and it is how I expect platforms (and their leaders) to report.
How I work
Three principles that survived every employer so far.
A platform is a product
It survives only if developers choose it, stay with it and pay for it. Roadmap, onboarding, docs and support are product surface, not overhead — and the tariff is a feature.
Economics sits on top of technology
Configurations, utilization and commitments are product decisions. The unit of platform design is cost per unit of delivered work: an hour of GPU, a gigabyte stored, a token generated.
Results must be provable
A number without a source is a liability. I state what a case proves and what it does not — on this site and in every review. Under-claiming beats decorating.
Verified chronology
Checked against primary documents: employment record, staffing plan, original work materials and public records. Periods are as verified; titles are as they were, not rebranded for a narrative.
| Period | Where | Role and what is verified |
|---|---|---|
| 2007–2012 | CNIP GIS, Russia | GIS engineer → senior developer. Geospatial information systems in Java on the Geo4Geo platform. My technical origin: real code, real data, real users. |
| 2013–2018 | Infobox — public cloud provider | Cloud platform expert. Platform and product work on the InfoboxCloud service built on Microsoft Azure Pack: SLA methodology (measurable IOPS), migration testing, backup product development. A series of technical publications and webinars — see Speaking. |
| 2018–2023 | MTS Cloud | Product manager → Head of Development Department → Head of Development Center from October 2021 (employment record); the center counted 139 positions, 128 filled, in the staffing plan. In 2019–2020 — the GPU cloud product: NVIDIA V100/vGPU configurations, tariffs, availability design, client training and inference scenarios. Public record: AI Journey 2020 talk. |
| 2023–2025 | JetBrains | Developer Experience: WSL, Docker, Dev Containers, Terminal, remote development environments. Team products; no sole authorship claimed, no unverified adoption metrics cited. |
| 2025–now | CloudLinux (US; remote, the Netherlands) | Platform infrastructure: reliability and infrastructure decisions, FinOps (AWS commitment process, projection-vs-measured separation), agent infrastructure. Current engineering in Projects. |
| Period | Where | What |
|---|---|---|
| 2010 | Tver State Technical University | Engineering degree (verified by document). |
| 2010–2014 | Postgraduate studies | Research program; no degree claimed. |
What I do not claim
- 139 positions at MTS is the center’s size in the staffing plan — not the number of direct reports, and not 139 people reporting to me personally.
- JetBrains work was team work. I do not cite adoption, NPS or growth figures from that period: I have not verified their original measurements.
- Forecasts made in the 2020 GPU talk are forecasts. They are not results and are not cited as such.
- The PostgreSQL migration at CloudLinux was executed by an engineer; my role was directing the change and accepting it. The consumer’s confirmation of stability is the outcome.
- FinOps: the commitment process and coverage checks are proven; realized savings are not claimed.
Away from work
I write poetry and make music — amateur, steadily, for years. Language under meter turns out to train the same muscle as engineering under constraints: there is always a budget, an interface and a deadline, and the piece either holds or it does not. It keeps my Russian and my instruments in tune while everything else compiles.