One Size Fits None: How Platform Engineering Must Evolve

Platform Engineering is Not One-Size-Fits-All

Colin Griffin: Good afternoon, William.

William Rizzo: Hey Colin. How are you doing?

Colin Griffin: This is going to be fun. I don’t think we’ve done a recording or a webinar together like this before.

William Rizzo: No, not that I can remember. We’ve done panels though.

Colin Griffin: Where are you today?

William Rizzo: I’m in the Netherlands — Amsterdam.

Colin Griffin: Awesome. So you’re looking forward to KubeCon, then — you don’t have far to go.

William Rizzo: Absolutely. It’s practically my home turf.

Colin Griffin: It’s morning for me — I’m on the East Coast in the US, so I’m going to be drinking coffee.

William Rizzo: And it’s afternoon for me, so I’m drinking tea.

Colin Griffin: Today we’re going to jump in and do some real talk about platform engineering. You and I have been at it for a while. Right now I think we’re coming from a couple of different spaces — you’re a little bit more in the vendor space, and I’m a little bit more on the delivery and consultancy side. I’m almost like your consumer. Tell me about what you’re doing today.

William Rizzo: I like to see you more as a potential partner. I am in the vendor seat at the moment — I’m a strategy lead at Red Hat. I’m fortunate to work directly with customers and decision makers who are stakeholders in the platform engineering, AI and edge space. My focus is particularly strong on platform engineering and edge.

William Rizzo: What I see — and what surprised me over the last eleven months or so — is the differences between fintech, telco and automotive. When we talk about platform engineering, we are talking about the same general principles: accelerating developers, reducing cognitive load, and all these good things. But when it comes down to what happens in the field, they have very different problems and very different requirements. What we generally say about platform as a product needs to be tailored to those verticals. We need to build frameworks, but we need to be a little bit more specific and work with end user organisations, bring them to the table, and get them to help us tailor those frameworks to their own vertical. That’s what I’ve been seeing.

Colin Griffin: That’s like therapy for me to hear. On my side — doing the CNCF Platform Engineering TCG work and the work at Fromwhere — a lot of what we do comes from experience in the field. And that experience is similar to what you’re talking about. We go into a customer and they have this perception of the outcome they want to achieve, or this perception of where they are and what they can actually achieve, and those are often two very different things. There’s a way of doing work that is not only common in their industry but is still unique to that company — something that makes their organisation special — and we need to tap into that. But I think people are trying to be something they’re not. They look at artefacts out there and say “I should be that,” rather than taking it and applying it to themselves in their own way.

Colin Griffin: To me, that’s been one of the big communication challenges in platform engineering. A big target fixation in that space is the concept of the IDP — the internal developer platform. Everyone thinks that’s what platform engineering means, and it’s not really. It’s one instance, one capability, one key focus area — but it’s not right for everybody and it won’t be everybody’s starting point.

Colin Griffin: For me, it’s a matter of creating perspectives. The teams you’re working with have their own unique language. As a platform engineer, we need to learn their language. Then it’s our job to come back and build the additional language that works for other teams, and be that translation layer and that interconnect. That’s a big challenge — but does that ring true for you too? And how do you feel about the depth of investment these companies are willing to make in building that understanding?

Investment, Compliance, and Business Outcomes

William Rizzo: The depth of investment — that’s an interesting question. When a business makes an investment, that investment needs to tie to a desired outcome, to an expected business outcome. The problem is that we as platform practitioners have not been particularly strong at creating and defining what the tactical actions and strategic paths are towards that expected business outcome. That’s why we’ve had difficulty answering the question: what investment needs to be made?

William Rizzo: The rest of the answer depends very much on the vertical and the organisations I’m talking to. When I’m talking with fintech organisations, they have regulators, auditors, and depending on the country and where the business is, they may have regulations and compliance obligations they have to subscribe to. Making investments for them, while it might be easy from a monetary perspective, can be very complicated from a regulatory perspective — because that investment must not impact the platform or the delivery of business outcomes they are delivering.

William Rizzo: Let me give a practical example. Think of a fintech that is an investment firm. The systems that participate in the investment go through strict auditing. If one piece of software in the software delivery chain fails the audit, that system needs to be taken out of the investing workstreams. So an investment made into the platform to introduce a new capability has caused an auditing issue, and therefore a missed business outcome. While they have the monetary means, fintechs are more careful about making investments. Whereas if we look at industrial platforms, they are more keen on testing, experimenting, and running pilots for the longer term, because some of the systems involved in industrial production are not under the same strict auditing and compliance — though some are, of course, particularly in industrial IoT.

Colin Griffin: Is 2026 the year of “we need to get our compliance in order, so we need a platform to do that”? Or is it “we need AI capabilities and some way to operationalise those”? What do you see as the key driver this year?

William Rizzo: I’ve been fortunate to get involved in the work being done in the CNCF’s Financial Services User Group — specifically the work by Control Plane and the folks at Venus on the AI governance framework and the Common Cloud Controls initiative. I keep going back to fintech, but I’m working a lot with them at the moment and I love their problems. They don’t come saying “we need to do more with compliance” — they already live and breathe those problems. What they come with is: “we need to modernise certain systems or platforms, or solve this problem with modern solutions, and what we want is something that is not going to break our compliance. That’s the baseline — we need to be above it.”

William Rizzo: What I expect to happen is that we need AI to be in those pipelines and platforms, but we need to govern it and put guardrails around it. The AI governance framework is addressing this. I expect more conversations about how platform engineering is involved in the layers of these reference architectures. And I expect vendors to come together — not necessarily at the same table — to address those general reference architectures being built more by end users and architects in fintech organisations, and bring vendor-opinionated implementations to those. More security, more compliance, more regulation around the use of AI and reasoning.

William Rizzo: What I also expect is that we get better at orchestrating the metal. This is going to sound blunt, but in the hardware world it has been the Wild West. Hardware vendors need to standardise more so that we software vendors can create orchestration across GPUs and across metal, and bring models closer and faster to the end user. I expect to be talking about easier ways of doing this.

Connected Experiences, User Perspective, and the EU–North America Divide

Colin Griffin: You touched on something at the end there. You’re right that in North America there’s a slightly different drive. We see compliance on the horizon, but you’re already in the throes of it in the EU — because of the AI Act and everything that comes with it. A lot of people in North America don’t realise how much more complex the regulatory landscape is in Europe. It’s as if every single state had the authority of a country — that is literally what the EU is. There’s a massive complexity of regulation, and that requires technology to help deliver regulatory outcomes and shift responsibilities in whatever direction is needed. “Shift” is the trend of this year, whatever direction that ends up being. North America is on a lag for that particular thing, but we’re expecting it and trying to anticipate delivering solutions for it.

Colin Griffin: In the meantime, a lot of folks we speak with have a very shallow understanding of what’s required to run a tech organisation — or their own organisation and how it runs. That’s not an attack; it’s just an area where improvement can help companies achieve stronger, more well-defined outcomes. You might not be ready for regulatory requirements, you might not be ready for AI, you might not be ready for an IDP, you might not even be ready for the apps you already have — which is very common. So how do we work backwards and get you to a state of readiness? And are you willing to shore that up? There’s an interesting culture in North America — probably driven by the VC culture — of “just do it new.” And that’s not always the answer.

Colin Griffin: I’m thinking a lot this year about connected experiences, platform interoperability, and elevating individual components of the platform — the things we use to operate the platform, assemble and do things, but that are also available for reuse. How do we manage secrets, for example? We don’t need eight ways to do that. Sometimes we just need to expose how it works, market that capability, and provide it via other means. But a lot of this comes down to user experience at the end of the day. Understanding the way that the people consuming your tools do their jobs, the tools they need, the ways they can actually interact with you — and then it’s our job to protect them and make sure their work stays within those boundaries and achieves the required regulatory outcomes.

Colin Griffin: I was in an interesting call the other day, and the ingress NGINX problem is creating some interesting conversations. Platform engineering isn’t a new concept, it’s a new conversation — which makes it great, it makes it accessible. The question of “what ingress should I choose?” is a chance to talk about the rest of the networking stack and redefine it, because you likely already have tools in place. Maybe it’s time to move to Gateway API or a newer concept. With the connected experience and user experience angle, network engineers now have a potential seat at the table. You can go talk to your networking teams, involve them, and determine what your platform team can adopt for operating the platform — and also, now that we’re making this change, what tools can we provide to them?

Colin Griffin: Our regulatory folks need a seat at the table too. We need depth of understanding, but we also need to be able to draw a line and say: I don’t want to know any more about this regulatory stuff — what tools can I give you to tell me what we need to do? And get to that point.

AI, Infrastructure, and the GPU Reckoning

William Rizzo: The network folks were not away from the table — they just stepped a little into the second line, which is not necessarily a good thing. But with enterprise-class AI, they are definitely sitting back at the table as first-class citizens.

William Rizzo: In platform engineering, we like to talk about golden paths — how the pieces fit into the chain of events that leads to what the consumer asked for. If we take that concept and say, “now my platform should provide models as a service,” then from a platform engineering perspective, in addition to hardware, abstraction, networking and storage, all of this needs to be orchestrated from the software orchestration layer to serve that model in a seamless way — just like we serve the golden parts of Postgres, a vector DB, or MongoDB. Now we have to serve those models. So why are network folks back as first-class citizens? Throughout the golden path, the high-bandwidth, very-low-latency links need to be wired to those models so that the serving maximises the monetary expenditure being put on the GPU being accessed. Whether that GPU is sliced, shared, or using whatever Nvidia or AMD virtualisation technology — the end user doesn’t care. They’re selecting what they need to run the experiment or connect to the model that’s going to be served.

William Rizzo: What I saw at the beginning of the year — and am seeing less of now — is end users saying: “we’ve made a very expensive investment in hardware that’s not a GPU, and we want to run AI on it.” It doesn’t work that way. Your hardware and infrastructure needs to be designed for AI workloads. We cannot just throw an AI workload on any hardware anymore. We need that very particular switching, we need to rethink how we are doing infrastructure to leverage AI workloads. And we need hardware vendors to standardise more so that software vendors can create orchestration across GPUs and metal, and bring models closer and faster to the end user.

Colin Griffin: So people have bought this hardware, and now they’re trying to figure out how to maximise that investment.

William Rizzo: I see two patterns. First: people who invested in hardware that was not AI-ready and wanted it to be. Second, and more commonly: large investments in GPUs — millions of dollars or euros — from end user organisations, not from cloud service providers, who are now on the hook trying to understand how to orchestrate and maximise that investment and deliver to their internal customers. It feels like a gold rush, especially for CSPs trying to secure GPUs and then orchestrate them. Securing the GPU is apparently no longer the problem. Orchestrating it is.

Colin Griffin: That almost puts a new spin on the term “technical debt” — it’s actual, physical debt this time.

Wishes for the CNCF White Paper and Maturity Model

Colin Griffin: We’re currently in the throes of working on refreshes for the CNCF Platform Engineering Technical Community Group — the Platform Engineering White Paper and the Platform Maturity Model — both due for updates before KubeCon in March. Short timeline, but it’s happening. What’s on your wish list for the white paper refresh?

William Rizzo: What I said at the beginning of our chat: I would like to see verticalisation. I would like to see verticals addressed — what is specifically relevant for automotive, fintech, or telcos. I don’t know exactly how we’re going to do it, but it’s something I would like us to explore.

Colin Griffin: I’d love to see that too. There is a lot of crossover, especially at the infrastructure level. I think we’re going to see a lot of convergence this year and a lot of full-circle moments — a lot of activity around OS management to meet all of these needs. A lot of activity, but it’s got to become real. What about the maturity model?

William Rizzo: For the maturity model, I would like to see end users come to the table and tell us what they found missing. We came out with the maturity model, there’s been a lot of noise and a lot of work — the feedback has been extremely good. But now, after a year and a half: what was missing? What do we need to work on more? What no longer applies? I would like end users to tell us that.

Colin Griffin: One of the big resounding pieces of feedback was exactly that — verticalisation. So we have a clear common theme. The maturity model self-assessment is out now, along with a feedback form, and the best thing people can do is complete the self-assessment and provide their feedback. A lot of that work is coming full circle, and I’m excited to see it. I appreciate you hanging out with me today, William. Any last remarks for anyone watching?

William Rizzo: Since this episode is coming out just before KubeCon — come to KubeCon and tell us in person what you wish for and what you want to see.

Colin Griffin: We’ll see people in Amsterdam in a few weeks. Thanks so much, William.

William Rizzo: Thank you, Colin.