Platform engineer · Dublin

I build the layerunderneath theproduct.

Infrastructure, automation, developer platforms, and the AI systems that sit on top of them.

Dublin

01 · Skills

Four ways I approach a problem

What I can do

  • Infrastructure as something engineers consume rather than assemble. The measure is how little of it anyone else has to think about.

    • Cloud infrastructure
    • Internal developer platforms
    • Infrastructure automation
    • CI/CD
    • Environment & deployment design

02 · Work

Client work · A consumer social platform in India

Social platformon AWS

I built and support the production infrastructure behind a social app with more than 80,000 users: containers, databases, deployments and monitoring, all defined as code.

Users
80,000+
Region
AWS Mumbai, 2 zones
Services
5 container services
Built as
4 AWS CDK stacks

Typical API response time

0.03s

Baseline

  1. 01 · Baseline

    Fast, until it wasn't

    Every service runs as a container on Fargate behind a load balancer, deployed by GitHub Actions through short-lived OIDC credentials. Typical API response time: 0.03s.

  2. 02 · Problem

    Ten times slower, with nothing on fire

    Users reported the app had felt slow for two or three days. Response time had risen tenfold while the API's own servers sat at 7–18% CPU, so autoscaling never reacted.

  3. 03 · Diagnosis

    Four workers doing one job

    The background worker service had scaled itself from one copy to as many as four. Its scheduled jobs were never designed to run more than once at a time, so each copy repeated the same work against the cache.

  4. 04 · Diagnosis

    A cache out of credits

    The cache ran on a burstable instance. The duplicated work spent its CPU credits over three weeks until AWS throttled it to 20% of a core, and every request that touched the cache queued behind it.

  5. 05 · Diagnosis

    Alarms that stayed green

    A throttled machine shows low CPU, and an average hides a slow tail. The existing alarms watched exactly those two things.

  6. 06 · Fix

    Remove the cause, then the blind spot

    Pinned the worker to one copy. Moved the cache to a fixed-performance instance. Added alarms on CPU credit balance and 90th-percentile latency, about two days of warning. Handed the team the code change needed before the worker can safely scale again.

  7. 07 · Result

    Back to 0.03s

    Typical API response time returned to 0.03s, and the next time credits start draining, someone gets told.

Stack

  • ECS Fargate
  • RDS PostgreSQL
  • ElastiCache Redis
  • Amazon Keyspaces
  • CloudFront
  • AWS WAF
  • CloudWatch
  • AWS CDK
  • GitHub Actions

03 · Earlier work

How I got here

  1. Dayananda Sagar University

    AR Weather

    Putting data where the weather actually is

    A weather app you pointed at the sky. The interesting problem was anchoring remote data to the place you were standing.

  2. Dayananda Sagar University

    Facial Recognition Attendance

    Removing a ritual nobody defended

    What happens when a model meets a workflow that real people have to live inside.

  3. Dayananda Sagar University

    Music on a Distributed Ledger

    Learning a technology by arguing with it

    A music app on blockchain, mostly to learn where the model stops making sense.

  4. HCL

    Windfarm Digital Twin

    Software that has to agree with reality

    A live software model of physical machines. Correctness measured against the world rather than a spec.

  5. ANKO

    Test Automation for SuccessFactors & UKG

    Making a repetitive process into an asset

    Automated testing across two enterprise HR platforms, reliable enough that people stopped re-checking by hand.

  6. Copilot × Jira

    Closing the gap between the ticket and the branch

    AI assistance during development that knows which work item it's actually serving.

  7. Supply Chain Operations Agent

    Where an agent may decide, and where it may not

    An agent in a domain of exceptions and partial information. The question was where its authority should end.

  8. Self-Service Developer Platform

    Building the floor other people build on

    Paved paths for provisioning, deploying and running services. Where my interest moved to the layer underneath.

  9. NowSee the current work.

04 · Learning

Practice, not mastery

What I'mlearning

  • In progress

    MSc Computer Science

    University College Dublin · Negotiated Learning

    Formalising the parts I picked up by building, and aiming the coursework at the areas I already work in.

  • Completed

    BTech Computer Science and Technology

    Dayananda Sagar University, Bengaluru

    Where the first experiments came from, and where I found out the unfamiliar technology is rarely the hard part.

How far in

Filter by depth. Three squares is where most of the work is; one is just opening up.

  • Platform engineeringThe centre of the work right now.
  • AI engineeringBuilding with models rather than around them.
  • Agentic systemsSpecifically: bounding what they're allowed to do.
  • Cloud infrastructure
  • Developer platforms
  • Infrastructure automation
  • AI-assisted development
  • System architecture
  • Developer experience
  • Modern web developmentThis site is part of that.
  • Design systemsSo is the brand it's built on.
  • Building productsThe longer-term direction.

Questions I don't have answers to yet

Where should an agent's authority end, and who decides: the platform or the team using it?

05 · Off the clock

Based in Dublin

Kevin Henry outdoors, wearing glasses and a patterned blue shirt, half-smiling.

The personbehind it

Now
An MSc at UCD, alongside the work: infrastructure, automation and the AI systems on top of them.
Before
Experiments in AR, computer vision and distributed ledgers at university. Then enterprise work: a windfarm digital twin at HCL and test automation at ANKO.
Curious about
Where agents belong in operational workflows, and what developer tooling looks like when AI is assumed rather than added.

What isn't the job

06 · Contact

Dublin

Have something thatdoesn't have anobvious answer?

I'm most useful early, when the problem is still being described, the architecture is undecided, and it isn't obvious whether the thing should be built at all.