In my first weeks I started changing that: I introduced Atlantis for cloud infrastructure and migrated all of Kubernetes into ArgoCD, until every change became a reviewable pull request that applies itself. That created the safety to move fast.
Platform & Site Reliability Engineer
Oleksandr Ponomarov
I'm a Platform & Site Reliability Engineer with several years owning the foundation used by a few hundred engineers.
My focus is AWS, Kubernetes, delivery, and reliability: making the right thing the easy thing so changes stay visible and reversible.
01 — Four years at an industrial IoT company
Each layer made the next one possible
For four years, I owned the platform foundation of an industrial IoT company. I joined when infrastructure changes were still applied by hand; by the end, a few hundred engineers were shipping through systems designed to make changes visible, reviewable, and reversible.
The work did not arrive as isolated projects. Each layer unlocked the next: reviewable changes made faster feedback safe; automation turned maintenance into background work; rebuilt foundations made self-service possible; and those foundations supported the newest chapter in secure AI tooling and customer-facing platforms.
This is that four-year story in the order it happened. Each label opens the case study behind the step:
Then the feedback loop got fast: checks that run in milliseconds before you even commit, and fix your mistakes for you instead of just complaining.
With commits standardized, releases became automatic; with releases automatic, dependency updates became automatic; with updates automatic, staying current stopped being a project and became a background process.
On that foundation I could rebuild the hard things: the network (from a setup everyone feared into segments defined in code), and then entire environments that can be created and destroyed with one command.
The platform proved itself twice over: when the company made an acquisition, one engineer could move the acquired product onto it in a summer; when a vendor raised prices, we could leave in weeks.
And because all of that existed, the newest chapter — AI tooling for every developer, customer code running as self-service functions, and building new platforms in weeks instead of quarters — was possible at all. The backup system and the container platform below were each built in weeks, by one person, precisely because years of groundwork made weeks enough.
02
The biggest win
Environments you can create and destroy with one command
- Impact
- Entering a new region became an infrastructure change, not an infrastructure project.
- My role
- Led the architecture and implementation of the cell platform and its fail-closed teardown provider.
- Evidence
- One stack provisions the VPC, EKS, GitOps bridge, and network attachment; teardown verifies six ordered phases.
Each cell contains its own failure domain, joins the network by policy, and verifies teardown before infrastructure state can disappear.
reliabilitycostdelivery
03
All case studies
12 · featured
The fleet that patches itself (while engineers are watching)
- Impact
- A vendor announces a fix; the fleet is rotating onto it within hours.
- My role
- Wrote the architecture and rotation policy; co-built the event-driven image pipeline with two teammates.
- Evidence
- 07:00–20:00 weekday coverage, an 18:00 rotation cutoff, and pool-specific disruption budgets.
- Impact
- A list-indexed route mesh became stable resources and one reviewable network policy.
- My role
- Rebuilt the route model and led the no-change migration and Cloud WAN architecture.
- Evidence
- Stable route identities, a quarantine segment, and one policy document replaced about fifteen module copies.
- Impact
- Entering a new region became an infrastructure change, not an infrastructure project.
- My role
- Led the architecture and implementation of the cell platform and its fail-closed teardown provider.
- Evidence
- One stack provisions the VPC, EKS, GitOps bridge, and network attachment; teardown verifies six ordered phases.
- Impact
- A missing image is an inconvenience; a wrong image is a disaster.
- My role
- Designed and built the image factory, then turned the migration into a playbook teammates could run.
- Evidence
- 48 images migrated in four days; 35 releases in 20 days; 864 tests protected the publishing contract.
- Impact
- Every merge still crosses the same gates as human work.
- My role
- Defined repository guidance, safe-tool defaults, supervised skills, and merge controls for agent-assisted work.
- Evidence
- Repository-local maps and playbooks route every change through the same plans, diffs, CI, and human merge gate.
04
How I work
Decisions get written down.
I introduced architecture decision records to the organization and authored a large share of them — including the standard for how to write them. When we chose the tool that now manages all our infrastructure code, I didn't write an opinion piece: I built the same infrastructure three ways in working prototypes and let the comparison decide.
I teach what I build.
Standards arrived with a community channel, recorded walkthroughs, worked examples, and patient answers to beginner questions — because tooling without teaching just creates a new priesthood.
Honesty over optics.
Twice in this portfolio a fix of mine turned out wrong — an operator misdiagnosis and a network gate that broke cross-account — and both times the revert came from me, same week, with the real root cause following. That's the review culture I try to model.
Measure, don't assert.
Benchmarks before rewrites, no-op-plan proofs before risky migrations, restore drills before trusting backups, rehearsals before destroys.
Automation over heroics.
Large mechanical migrations run as scripted, repeatable campaigns — and in the last year, as supervised AI-agent campaigns with safety rules encoded in — turning fleet-wide changes from quarter-long projects into focused weeks.