Nine years of predicting cloud native, scored honestly

I started writing annual predictions in 2017 to find out whether I could read the industry. Nine years in, that's turned out to be one of the least interesting things the exercise has done. What it does instead is harder to say, or harder to predict. Something like: it surfaces the gap between what I think will happen and what I want to be true. Nine years of scoring myself has been nine years of watching that gap.

The discipline

Once you commit to publishing your score, the predictions themselves get sharper. You can't write "I think microservices will continue to be important." What would that even mean to score? You have to write something specific enough that you and a reader can both look at it twelve months later and agree on whether it happened. So I give specific marks. Some 100%. Some 80%. Some 50/50 when reality cut down the middle. A few 0%, which I'll get to.

Being wrong in public

Hits are easy to write about. You were right, you said the thing, the thing happened, congratulations. There isn't much there.

Open source has always been comfortable with being wrong in public. A broken commit, a pull request that doesn't pass review, a roadmap that didn't survive contact with users; these are part of how the work moves. A culture where nobody is ever wrong is a culture that isn't trying.

Predictions work the same way. A perfect hit rate is a bad sign, not a good one. It means everything called was safe enough to already be happening, the well-trodden, the obvious, the things any thoughtful reader had filed under "yes, that." The misses are evidence the predictions were doing some work.

The scoring matters because of where it cuts. A clean 0% is easy to admit; the prediction failed on its own terms. The harder kind is the one that can technically be claimed; the hit that quietly stretched the timeline, the call that landed on the third interpretation. Those are the ones nobody else would pull you up on. They're also the ones the scoring is for.

The arc

Stack the predictions next to each other and the genre shifts underneath them. The 2018 and 2020 posts were mostly about the stack forming around Kubernetes — Prometheus, Grafana, Fluentd, Istio, the multi-tenancy story, the operator pattern. By 2022 the question had moved to platform engineering and IDPs. By 2024 it was AI starting to surface in operations and the maturity gap between organisations. By now it's edge, AI infrastructure, and the second wave of developer experience.

The recurring blind spot

There's a pattern in what I keep getting wrong, and it isn't about which technologies matter.

The pattern is pace. I consistently underestimate how long structural change takes once a technology is in production. The thing I predicted will eventually happen. But slower, with more drag, against more inertia than the prediction allowed for. I'm not the only one who does this. It's the easiest mistake in the genre. The alternative is hedging: "this will happen in six years, give or take three." That doesn't read like a prediction.

Every engineer who has ever given a sprint estimate has lived a smaller version of this. You can guess the right direction of work, name the right tasks, anticipate the obvious problems, and still be off by a factor of two. The instinct is always toward optimism: you assume the version of the work without the integration headaches, the rebase that breaks tests, the new hire who needs onboarding. Annual predictions about an industry have the same failure mode, just measured in years instead of days.

We surveyed platform engineers at KubeCon three years apart. Same top priorities. Same structural constraints. The direction I'd called was right. The pace was wrong.

That pattern is what we eventually started calling the platform engineering assembly tax. Not as a slogan, but as a name for the compounding cost that explains why the change everyone keeps predicting keeps not arriving as fast as predicted.

The gap

Once you can name the recurring blind spot, you have to be honest about what's behind it. The mistake isn't analytical. It's emotional.

I predict from hope. Most people who write predictions do, even when they think they're being analytical. You want the future you want. The scoring exercise is useful because it surfaces the gap between what you believe will happen and what you want to be true. Most years I close that gap by a few percentage points. Some years I don't close it at all.

I didn't write predictions in 2021. The pandemic broke the rhythm, and I said so when I came back the following year. I've thought about backfilling but it would have been an obvious cheat. I'd be writing 2021 predictions knowing exactly what happened. The skip stays. It's a small thing, but it sits inside the same discipline as the 0%s.

What we're trying next

We're experimenting internally with ways to surface that kind of bias earlier, a thinking simulator, mostly, but I don't yet trust it more than the scoring. I'll write the next one in January. I already know I'll be too optimistic about something, it's nice to hope still. The exercise is figuring out what, and being honest about it twelve months later. That's the useful version of this.