KubeCon is the largest cloud-native conference, and its value for enterprise architects is not primarily in the product announcements or the keynote stages. It is in the practitioner presentations and the working group sessions that reveal where the cloud-native community is solving problems at production scale, which is typically twelve to eighteen months ahead of where enterprise adoption sits.<\/p>\n
KubeCon London in April 2025 produced three themes with high consistency across the enterprise practitioner talks. Each has architectural implications for the twelve to twenty-four months ahead that are more specific than the general “AI and cloud are converging” narrative that has been the industry consensus for the past two years.<\/p>\n
At KubeCon Paris in 2024, the question being asked about AI inference on Kubernetes was “can we do this?” At KubeCon London 2025, the question being asked is “how do we do this at production scale with predictable latency and cost?”<\/p>\n
The shift reflects maturity. The organisations presenting AI inference workloads on Kubernetes at London were not early adopters experimenting with GPU node pools. They were enterprises that had been running AI inference in production for twelve to eighteen months and were dealing with the operational problems that production scale reveals.<\/p>\n
Three operational challenges dominated the AI inference presentations. The first is scheduling latency for heterogeneous workloads: GPU nodes that must serve both batch inference workloads (low latency requirement, high throughput priority) and interactive inference workloads (latency-critical, throughput secondary) are hard to schedule efficiently without custom schedulers or resource partitioning that the default Kubernetes scheduler does not provide. The second is model loading time as an availability factor: large language models with parameter counts in the tens of billions take minutes to load from storage to GPU memory, which makes pod scheduling decisions for interactive inference much more consequential than for conventional application workloads. The third is cost allocation for shared GPU compute, which has the same cultural and technical challenges as cloud cost allocation generally but is amplified by the significantly higher cost per unit of GPU compute compared to CPU compute.<\/p>\n
The enterprise architecture implication is specific: the platform engineering investment required to support AI inference workloads at scale requires extensions that most platform teams have not yet built, and the organisations that build them in 2025 will have a meaningful lead over those that defer the work to 2026. The specific extensions: GPU-aware scheduling configurations, model caching infrastructure, and GPU cost allocation tooling integrated with the FinOps platform.<\/p>\n
The security theme at KubeCon London 2025 was a continuation of the theme that appeared at KubeCon Paris 2024, but with more specific evidence of the problem scale. At Paris, the concern about AI-assisted development creating security posture degradation was observable in early adopter data. At London, it was documented across multiple enterprise deployments with quantitative evidence.<\/p>\n
The pattern that emerged with consistency: organisations that deployed AI coding assistants in 2023 and early 2024 are now completing their first post-deployment security posture assessments, and the findings are unflattering. The vulnerability density in AI-assisted code is not higher per line of code than in human-written code. But the volume of code being written has increased significantly, the developer review intensity has decreased, and the net effect is a larger volume of vulnerable code reaching the deployment pipeline. The static analysis tooling that was calibrated for human-authored code throughput is being overwhelmed by AI-augmented throughput.<\/p>\n
The architectural response that practitioners at London are implementing is threefold: increasing the automation of security checks in the CI\/CD pipeline to match the increased development throughput, retraining static analysis models on AI-generated code patterns to reduce the false positive rate that is degrading developer engagement with security feedback, and implementing code provenance tracking that identifies AI-generated code segments for enhanced review.<\/p>\n
For enterprise architects, the signal is: the DevSecOps pipeline that was designed for human development throughput needs capacity and tooling upgrades before AI-augmented throughput is scaled across the engineering organisation. Deploying AI coding tools without these upgrades is creating security debt that will surface in post-deployment assessments.<\/p>\n
The third signal from London was more positive than the first two, and it has a specific implication for the investment prioritisation conversation that enterprise architects are having with their technology leaders.<\/p>\n
The enterprises at London with the most successful AI deployment stories had a consistent structural characteristic: mature platform engineering capability that had been built before the AI deployment programme began. The connection is not coincidental. The internal developer platform that provides self-service compute provisioning, standardised deployment pipelines, and integrated observability is the same infrastructure that AI workload deployment requires. Enterprises that had invested in platform engineering for conventional application delivery had a deployment infrastructure for AI workloads that organisations without platform maturity did not have.<\/p>\n
The organisations without platform maturity that are deploying AI are dealing with the same infrastructure provisioning and operational consistency problems that platform engineering was developed to address, but dealing with them in the context of AI workloads that are more operationally complex than conventional application workloads. The combination is producing AI deployment programmes that are slower, more expensive, and more operationally fragile than they need to be.<\/p>\n
The investment implication for enterprise CTOs is direct: if your organisation is planning a significant AI deployment programme and your platform engineering maturity is below level three on the CNCF maturity scale, the platform engineering investment is a prerequisite for the AI programme, not a parallel track. The AI programme that is built on an immature platform will encounter the platform’s limitations as the primary constraint on AI deployment success.<\/p>\n
Read together, the three signals from KubeCon London 2025 tell a consistent story. AI deployment at enterprise scale requires platform infrastructure that most enterprises have not yet built to the required maturity. The security posture management for AI-augmented development requires pipeline and tooling investment that most enterprises have not yet made. And the AI inference scheduling challenges that production scale reveals require platform extensions that most enterprises have not yet prioritised.<\/p>\n
The enterprises that address all three will be in a substantially different position for AI deployment in 2026 than those that address none. The investment case for addressing them is not future-oriented speculation; it is based on what the leading enterprise practitioners at London 2025 are solving right now in production.<\/p>\n","protected":false},"excerpt":{"rendered":"
KubeCon London 2025 produced clear signals about where enterprise cloud-native architecture is heading. Three themes have specific architectural and investment implications that go beyond the conference floor.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-152","post","type-post","status-publish","format-standard","hentry","category-architecture-observability"],"_links":{"self":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/152","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=152"}],"version-history":[{"count":0,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/152\/revisions"}],"wp:attachment":[{"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=152"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=152"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=152"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}