F. Latini - IT Engineer

The Platform Team's Second Year

Thu, 03 Sep 2026 08:00:00 +0000

TL;DR - Year one of a platform team is a construction project and everybody plans it as one. Year two is a running service and almost nobody re-plans for it, so the team keeps writing year-one quarters into a calendar that no longer has room for them. The denominator changed: maintenance, support and migrations now take somewhere between a third and two thirds of the team’s capacity, and because nobody wrote that down, every quarter ends late and the org’s honest read is that the platform team slowed down. There are two failure modes and they are opposites. One is drowning in a run cost you never budgeted. The other is refusing to admit the build phase is over and inventing a project to justify the headcount. The cure for both is the same: put the run cost in the plan as a number, defend it in public, measure support-per-user rather than support-total, and be willing to say out loud what a smaller version of your team would look like.

How to Retire a Golden Path

Thu, 27 Aug 2026 08:00:00 +0000

TL;DR - Platform teams write down how to build a paved road and never write down how to close one, so closing one is improvised, and it stalls. The failure mode is specific and almost universal: you announce the deprecation, sixty percent of the estate moves in the first two months, the tail does not move at all, and you now operate two roads forever. That is strictly worse than never having announced, because you pay double maintenance and your successor road stops being the obvious default. A retirement is a product launch in reverse and needs the same apparatus: a destination that already works for the workload class you are evicting, a migration you wrote and tested yourself, an inventory of who is actually on the old road, a named person funded to move the last twenty percent, an escalating date with a brownout before it, and an ending you delete rather than archive. Design path one so it can be closed, and most of this gets much cheaper.

Platform Adoption Without a Mandate

Thu, 20 Aug 2026 08:00:00 +0000

TL;DR - The paved road works, one team loves it, and three other teams built their own thing anyway. The reflex at that point is to ask leadership to make the road mandatory, and it is the single most expensive mistake available to a platform team, because a mandate does not produce adoption. It produces compliance, which looks identical on a dashboard and is worth almost nothing, and it destroys the only honest signal you had about whether your platform is any good. Every team that routes around you is doing it for one of four reasons - they never knew, it does not fit, switching costs more than it saves, or they tried it once and got burned - and each reason has a completely different cure. None of the cures is a policy. Win the moment of creation, pay the switching cost yourself, treat breakage as your bug rather than their problem, and measure repeat use rather than teams onboarded. Then, if you still need a mandate, use it only where a road already exists and a date is genuinely non-negotiable.

The Platform Team's First 90 Days

Thu, 13 Aug 2026 08:00:00 +0000

TL;DR - A new platform team’s first ninety days almost never fail on technology. They fail because the team, feeling illegitimate, reaches for the fastest available cure and builds something. Ninety days later there is infrastructure, a demo, a roadmap, and no customer, no evidence, and no answer to the only question that will be asked in month nine: what did we get for this? The first quarter has four deliverables and none of them is a platform. A mandate in writing, including what you will refuse. The baseline numbers you can only measure before you have touched anything. The inherited ticket queue read as a requirements document rather than a burden. And one small, painful, unglamorous thing fixed by week six, to buy the credibility that funds the rest. Build path one in the second ninety days, on evidence, with a named partner.

Your Cloud Bill Is Not a Finance Problem

Thu, 06 Aug 2026 08:00:00 +0000

TL;DR - Your cloud bill is not a finance problem. It is a feedback problem, and finance cannot repair a feedback loop they are not standing in. The invoice arrives monthly, aggregated, six weeks after the decision that caused it, addressed to somebody who cannot change a single line of it. The people who can change it - the ones who picked the instance size, the log retention, the always-on staging environment, the chatty cross-zone call between two services - never see a number at all. So the organisation does the only thing left available to it: an annual panic sprint that rightsizes everything, claws back twenty percent, and gives it all back within two quarters, because nothing structural changed. The alternative is to treat cost the way you treat every other platform capability. Attribution as a default of the paved road, not a tagging campaign. Unit cost, not total spend. The number shown where the work happens. Defaults that are cheap by construction. Showback before chargeback. Cost is a property the platform ships, not a spreadsheet somebody emails around in Q4.

Your Security Policy Needs a Paved Road

Thu, 30 Jul 2026 08:00:00 +0000

TL;DR - Almost every security control I meet in the wild was shipped as a rule and never as a road. The policy exists, the scanner runs, the build fails, and there is still a long-lived API key in a .env file, because nobody ever built the thing a developer is supposed to do instead. A rule without a road is a tax you levy on developers, and taxes get evaded, creatively and quietly. Treat secrets and policy the way you’d treat any other platform capability: distribute identity instead of secret values so the credential is short-lived and nobody handles it; ship every new control with a default that already satisfies it, an error message that names the fix, and a migration for what already exists; roll it out observe, then warn, then enforce; and make exceptions a first-class artefact that expires. The security team writes the rule. The platform team owes the road. Ship them in the same change or don’t ship the rule.

Build vs Buy Is the Wrong Question

Fri, 24 Jul 2026 08:00:00 +0000

TL;DR - “Should we build our own platform or buy one?” is the wrong question, and the spreadsheet that answers it is lying to you. It lies by comparing the annual license of the thing you’d buy against a one-time construction estimate for the thing you’d build - as if software you build is a purchase rather than a perpetual staffing commitment. Every platform is already part-built and part-bought; the only decision that matters is where you draw the line. Draw it in one place: buy the undifferentiated substrate, because it is a commodity someone else operates better than you, and build only the thin layer of opinion that is actually yours - the paved roads, the defaults, the glue that encodes how your teams ship. Then fund the built part like a product, forever, not like a project you finish. The teams that get this wrong build the commodity and buy the differentiation, which is exactly backwards.

The Error Budget Nobody Spends

Thu, 23 Jul 2026 08:00:00 +0000

TL;DR - An SLO without an error budget you actually spend is a number on a wiki, not a reliability practice. The error budget is the whole point: it is a pre-agreed trade between reliability and velocity, decided while everyone is calm, so that when the budget runs out the answer - stop shipping features, fix reliability - is already made. Almost nobody spends it. Teams set a target from ambition instead of user need (often a heroic 100%), measure the wrong thing (host uptime, not the user’s journey), page themselves at 3am on the raw threshold, and then blow through the budget without changing a single plan. This is the four moves that turn an SLO from decoration back into a decision, and the honest cases where you don’t need one at all.

The Real Project Was Never the App

Thu, 16 Jul 2026 09:00:00 +0000

TL;DR - NutriFinder is the friendly face, but the real project sits one layer down: OSDb, the Open Supplements Database - an open, structured, trustworthy reference for sports-nutrition and supplement data. IMDb for movies, Open Food Facts for groceries, OSDb for the stuff in your race vest. It already powers every comparison on NutriFinder; what’s next is a public API, wider coverage, and more apps on the same data layer. This is the story of why it exists and where it’s going.

Golden Paths, Part 2: The Second and Third Path

Thu, 16 Jul 2026 08:00:00 +0000

TL;DR - The first golden path is an adoption project; the second and third are a portfolio problem, and the dangers invert. You stop worrying that nobody will come and start drowning because everyone did. The rules that got the first road shipped will sink the second: saying yes to every request produces paved-road sprawl, forking the template per team produces ten half-roads instead of three excellent ones, and every path you ship is a product you maintain forever. The second path should reuse most of the first one’s guts, the long tail of requests gets the escape hatch rather than a road, and you keep a boring list of what exists. Success at path one buys you demand. What you do with that demand decides whether you end up with a platform or a junkyard of templates.

The Product I Wish Existed When I Started Racing

Wed, 15 Jul 2026 08:00:00 +0000

TL;DR - I built NutriFinder, a neutral place to browse and compare endurance-sports nutrition - gels, drinks, electrolytes, bars, chews - on the numbers that actually matter when you’re moving fast: carbs per serving, sodium, caffeine, price per portion. Not on brand marketing. It has a race-day fuelling planner, a brand-facing portal, and an LLM-powered Playwright pipeline that refreshes the data weekly. It’s early, indie, and live. This is the story of what it is, why it exists, and where it’s going - including the bigger idea underneath: an open data layer for sports nutrition, Open Food Facts for the stuff you put in your race vest.

Team Topologies in Practice

Fri, 10 Jul 2026 08:00:00 +0000

TL;DR - Team Topologies gives you four team types and three interaction modes. Almost everyone adopts the four boxes - rename the ops team “platform team”, call the senior engineers an “enabling team” - and quietly ignores the three interaction modes, which is where the entire value lives. The book’s real payload is a single idea: organise teams to minimise cognitive load, and make the way teams interact both explicit and temporary by design. Here is how that plays out for a real platform group, and the failure modes I see most.

The Comparison That Refuses to Compare

Thu, 02 Jul 2026 08:00:00 +0000

TL;DR - I added a “compare two athletes” feature to a side project. The chart was an afternoon. The honesty took the rest of the week. A rank only means something relative to who else was in the field - 1st out of 8 is not 1st out of 30 - so a naive overlay of two athletes’ placings is a confident lie. The feature I shipped refuses to declare a winner unless the two actually competed in the same event and the same category, and when they never met it says so, in a box, on purpose. This is the same discipline I keep writing about for platforms: a number out of context is dashboard theatre, and the honest move is to surface your own uncertainty instead of hiding it behind a clean line.

DORA Metrics Without the Dashboard Theatre

Fri, 26 Jun 2026 08:00:00 +0000

TL;DR - The four DORA metrics are good. What most teams do with them is theatre: a dashboard that trends up and to the right while nothing about how software actually ships changes. The metrics are a thermometer, not a treatment. Measuring deployment frequency doesn’t make you deploy more often any more than weighing yourself makes you thinner. This post is the four metrics read honestly, the four ways teams quietly game them, and the single question that separates a real DORA practice from a screenshot in the quarterly review: what did this number cause us to change?

Your Developer Portal Is a Trap (Until It Isn't)

Mon, 22 Jun 2026 08:00:00 +0000

TL;DR - A developer portal is the index of your paved roads, and almost nobody should build the index before they have the book. Standing up Backstage as your first platform move gives you an empty catalogue, a maintenance burden, and a demo that impresses leadership while helping zero developers. You earn a portal once discovery is a real problem - roughly the ~30-services mark the pillar names, several paved roads worth cataloguing, and ownership data someone actually maintains. Before that, a boring markdown catalogue does the same job for a thousandth of the cost. This is the post-script to building your first golden path: what comes after the road, and why it isn’t the portal.

Learn Terraform Fluently

Wed, 10 Jun 2026 08:00:00 +0000

TL;DR - Most people who “know Terraform” have memorised plan and apply and treat the rest as weather. Fluency is a mental model, not a command list. Internalise five things - state as the source of truth, the plan as a diff you actually read, modules as functions, drift as a signal, and code organised by blast radius - and Terraform stops being a slot machine you pull and start being a tool you steer. This is the post I wish someone had handed me before my first terraform destroy on the wrong workspace.

Building Your First Golden Path

Wed, 03 Jun 2026 08:00:00 +0000

TL;DR - A platform stays a slide deck until the first golden path ships. Don’t start with a developer portal, a service mesh, or a roadmap. Start with the single most-repeated request your developers make, turn it into a paved road that takes them from nothing to production in a day, and get one team to actually use it. The technology is the easy part. Adoption is the whole job.

Your LLM Platform Is Repeating Your ML Platform's Mistakes

Mon, 25 May 2026 08:00:00 +0000

Every team I talk to is building an LLM platform right now. Some call it that. Some call it “the AI gateway”, “the prompt service”, “the agent stack”. The shape is the same: a layer between application teams and a handful of model providers, plus retrieval, plus evals, plus a slowly growing pile of glue.

I have seen this movie. We made it five years ago and called it the ML platform. Most of the mistakes that made those platforms painful between 2018 and 2022 are quietly being reintroduced now, with bigger bills, more vendors, and less institutional memory.

The Postmortem That Changed Nothing

Thu, 21 May 2026 08:00:00 +0000

Every team I work with does postmortems. Most of them are written, filed, linked in a Confluence index, and never opened again. Then, eighteen months later, the same incident happens. Different on-call engineer, same root cause, same surprised faces in the retro.

We did not fail to write the document. We failed to change the system. That gap is the most expensive habit in incident response, and almost nobody talks about it honestly.

Your Staging Environment Is Lying To You

Mon, 18 May 2026 08:00:00 +0000

Every team I have ever worked with has a staging environment. Every team I have ever worked with also has a story about the thing that worked in staging and broke in production. Usually told in the postmortem. Usually with a slide titled “How did we miss this?”

We didn’t miss it. Staging missed it. That is the job staging cannot do, and pretending otherwise is the most expensive habit in modern infrastructure.

The Boring Stack Manifesto

Fri, 15 May 2026 08:00:00 +0000

I run Kubernetes for a living. The websites I actually ship for myself run on Flask, SQLite, and HTMX.

That isn’t a betrayal of the day job. It’s the most consistent thing about it. The reason I’m useful to companies running serious infrastructure is that I have a clear sense of what complexity costs - and I refuse to pay it when nothing requires me to.

This is the manifesto for the boring stack: when it wins, why it wins, and the case where you should put it down and pick up something heavier.

Are You Really Monitoring Your Infrastructure?

Mon, 11 May 2026 11:00:00 +0000

Every engineering team I work with answers “yes, we have monitoring” before I’ve finished asking the question. Then I ask the follow-up: the last time a customer hit a bug before you did, why?

If you can’t answer that quickly, you don’t have monitoring. You have dashboards.

This is the distinction worth getting right, because it determines whether you find out about problems on Tuesday afternoon or from a customer email at 2 a.m. on Saturday.

Is Kubernetes the Right Tool for You?

Mon, 11 May 2026 10:00:00 +0000

I run Kubernetes for a living. I think you should probably not use it.

That’s not a contradiction. Kubernetes is the right answer for a specific class of problem - multi-tenant, polyglot, heterogeneous workloads at meaningful scale. For most teams I meet, it’s a tax: a complex distributed system bolted onto a stack that didn’t need one, paid for in hiring, security, and “why is my Pod CrashLoopBackOff” Slack threads at 11 p.m.

DDDD - Domain Driven Design for Dummies

Mon, 11 May 2026 09:00:00 +0000

DDDD - Domain Driven Design for Dummies. One extra D, because by the time you finish Eric Evans’ original 560-page book, you’ll feel like a dummy regardless. This is the shorter version, the one I wish I’d read before trying to apply DDD on a real project for the first time.

What DDD actually is

Strip away the jargon and DDD is about one stubborn idea: the structure of your code should reflect the structure of the business it serves. Not the database. Not the framework’s defaults. The business.

What Is Platform Engineering? A Beginner's Guide

Thu, 16 Jan 2025 21:06:34 +0000

TL;DR - Platform Engineering is about building an internal product for your developers: paved roads, golden paths, and self-service workflows that reduce the cognitive load of getting code into production. It’s not DevOps with a new logo. It’s not SRE with extra steps. It’s a specific discipline with its own measurable goals.

Why this term exists

A decade of “DevOps” produced two outcomes. In the best companies, it built a real culture of shared ownership between development and operations. In most companies, it produced a small team of overworked specialists called “DevOps engineers” who became a human bottleneck - ticket queues, YAML on demand, “can you give me access to…” Slack messages at all hours.

gnome-control-center keeps crashing on Fedora 35

Tue, 08 Feb 2022 19:11:46 +0000

This morning gnome-control-center refused to open. Clicking the icon did nothing - no error, no window, just silence. Here’s the trail of breadcrumbs that led to the fix, in case someone else hits the same thing.

Step 0 - the oldest trick in the book

I tried the oldest debugging method on the planet first: the reboot.

The new website is alive

Fri, 07 Jan 2022 13:40:09 +0000

At last, the site is live. This is the home for my work as a freelance Platform Engineer - and an excuse to start writing more in public.

The setup is deliberately boring: a Hugo static site deployed to a DigitalOcean droplet in Germany, fronted by Nginx. Nothing fancy, nothing to maintain, fast to load.

Why start writing? Two reasons:

I want to get better at it. Technical writing is a skill, and like every skill it improves with reps. My own site is the lowest-stakes place to practise - I’d rather make mistakes here than in a client deliverable.
To build the habit. A blog with no posts is just a domain. Forcing myself to publish, even short pieces, is the only way to find out what I actually have to say.

Future posts will focus on what I work on day-to-day: platform engineering, site reliability, Kubernetes, Terraform, and the bits of cloud infrastructure that are easy to get wrong and hard to fix. There will probably also be the occasional debugging war story, because those are fun to write.

About

Mon, 01 Jan 0001 00:00:00 +0000

I started out as a PHP developer, switched to sysadmin work out of a *nix passion, and have spent the last 14 years in DevOps, SRE and platform engineering - for startups and large companies alike. Today I build the cloud infrastructure and developer platform behind AxonIQ’s distributed, event-driven products: multi-cloud on GCP and AWS, everything as code in Terraform. I help engineering teams ship faster and sleep better.

Services

Mon, 01 Jan 0001 00:00:00 +0000

I help engineering teams ship faster and sleep better. Most of my work falls into four buckets. If you’re not sure which one fits, get in touch - half my engagements start as a 30-minute conversation about what’s actually broken.

1. Production readiness for distributed systems

You have a service heading to production - or already there - and someone has to answer hard questions: what’s the error budget? what wakes someone up at 3 a.m.? what happens if a region fails? I help you answer them before a customer does.

Work With Me

Mon, 01 Jan 0001 00:00:00 +0000

Looking for a Platform / SRE consultant who’ll tell you the truth about your infrastructure? Let’s talk.

How engagements typically work

1. A 30-minute call (free)

Tell me what’s hurting. I’ll ask a lot of questions and probably challenge a few assumptions. By the end you’ll know whether I can help, and if not, who probably can. No pitch deck. No “discovery phase” billed at consultant rates.