Fresh from Paris: Platform engineering wisdom from KubeCon

Last week in Paris, at KubeCon EU 2024, platform engineering was the talk of the event. The topic had a full-day co-located event and also a dedicated track during KubeCon itself. Here’s what I’ve learned from sitting in keynote rooms and then standing at the Spot and NetApp booth till my knees hurt. (Spoiler: It was well worth it.)

Many of you platform engineers stopped by our booth. Here’s what I learned about you, from you.

Most platform engineers at KubeCon EU 2024 were at the earliest maturity stage called “provisional”: they had some self-service Dev workflows in place.

Now they’re looking to level up to the “operational” phase: They were researching which additional workflows are necessary for their development body. Some mentioned a desire to adopt Canary deployment and sought a way to safely automate it, so developers can own it.

As part of the efforts to become “operational,” they also intended to “productize” their workflows under a GUI. They roughly divided 50-50 between building their own and experimenting with open-source tooling like Backstage or Crossplane. None mentioned managed solutions built on top of those, like Roadie or Upbound. This “managed” category might be a tad ahead of its time. For a solid reason to be optimistic, keep reading.

Your IDP is a microcosm of your cloud estate

Every tech org has an internal developer platform in some way. But not all engineer their platforms. It’s already agreed that an “engineered” IDP means treating it as a software product: conducting due research to attain preliminary platform-market fit, having a dedicated team, a roadmap, and clear success metrics.

The platform should be engineered to solve existing Dev problems. It should respond to explicit, acute needs: “What do Devs spend too much time doing? That’s what I want to abstract and automate for them.”

The IDP’s desired architectural traits, and the challenges of getting there, greatly overlap with general CloudOps concepts. For instance:

• A good IDP should be operationally scalable, i.e., adaptable to growing user demand (e.g., with templates, provisioning policies, and key capabilities as a service)
• A good IDP should also be scalable from a business perspective, adaptable to evolving business needs, (e.g., running on cost-effective resources)
• Microservices, containers and CI/CD automation are desired architectural technologies to implement in your IDP product
• Inefficient resource utilization is an IDP’s recognized anti-architectural pattern, among others
• Efficient provisioning is THE way in which IDPs can live up to the org’s sustainability promises

Now replace each instance of IDP above with “cloud infrastructure.” Is it a coincidence that it still makes sense?

Enterprises will be early adopters of (managed) platform engineering

You would think that an emerging idea like platform engineering is still exclusive to companies with “.io” or “.ai” domains. In fact, engineering-led enterprises were quick to understand its potential to scale their cloud center of excellence (CCoE). This should allow them to, for example:

• Onboard many developers quickly as they expand their offering into the cloud-native realm
• Encourage innovation and consolidate Dev tools to make them accessible and approachable so people can start experimenting more easily
• Scale compliance by enabling the IDP to enforce organizational policies for secure coding, resource usage, and more

But CNCF tooling or practices are not easy for enterprises to adopt. Pure open-source demands high engineering investment. Emerging frameworks are often too vague, or too fast to evolve, for enterprise CCoEs to safely follow.

In my opinion, this means that enterprises will be first to identify the benefits of managed platform solutions. Therefore, even if this category is a tad ahead of its time, it’s not for long.

But for that to happen, two paradigms must be shattered:

#1: CCoE as a cost center

This paradigm naturally reflects on IDP initiatives. Both require large financial investment but fall short in presenting tangible financial impact in return.

If the C-suite is perpetually troubled and challenged by costs, this may put a halt to an org’s platform motion. An emerging solution for this would be baked-in optimization, designed into the platform’s resource plane. Which leads us to…

#2: Resource optimization as a day-2 capability

Optimizing cloud resource utilization and cost in IDPs are currently somewhere between day-2 and an afterthought. But the panels I sat in on at KubeCon agreed this should be changed: Once an IDP from its day-1 enables running the same workloads on fewer nodes, smaller nodes, cheaper nodes, or all of the above, it can essentially repay itself by reducing cloud costs. This provides a success metric that anyone in your management can understand.

Wrap-up: KubeCon EU 2024 highlighted some unexpected platform engineering imperatives

Experts at KubeCon agreed that optimized provisioning can make your IDP happen by nudging management buy-in. It also helps your engineering body live up to sustainability agendas, without Devs having to change how they work. It was nice to see this idea striking a chord with so many seasoned engineers on stage and on the floor.

There’s also great momentum for managed solutions, be it for the IDP’s portal or its integrated capabilities. Until Platform Engineering Day 2025, I expect many SaaS vendors in the product lifecycle ecosystem will launch plugins, providers, drivers, and modules for open-source and managed IDP solutions. Of course, this requires profound internal discussion and engineering investment. Personally, I’m glad to say that at Spot by NetApp, this ship is out of the port.