The cloud-native landscape brings incredible advantages, but it also introduces new security challenges, making safeguarding a top priority. In the traditional policy enforcement model, manual management leaves organizations vulnerable to inevitable breaches due to human error – a matter of 'when,' not 'if.' Enter Policy-as-Code (PaC), a game-changing approach that leverages code to define and manage policies, transforming rules and conditions into actionable directives. By keeping policy definitions in source code control, whenever a change is made, it can be tested, validated, and then executed. The goal of PaC is not to detect policy violations but to prevent them. In this session we delve into the practical implementation of a Policy-as-Code strategy for your organization using Rönd and Open Policy Agent, two powerful open-source projects that could help you to redefine your security paradigm.

Practical Policy-as-Code with OPA and a Managed Sidecar Container

The increasing complexity of software development presents significant risks and inefficiencies, especially for large enterprises. That’s why companies require a structured approach to streamline software delivery, with a focus on platform engineering and internal developer platforms. While existing literature often discusses platform engineering in terms of DevOps tool integration and infrastructure provisioning, its scope extends far beyond these aspects. To truly enhance service scalability and quality, platforms must prioritize data encapsulation and composability. This means addressing not just the IT infrastructure, but the entire organizational framework. Infrastructure management represents only the tip of the iceberg; to drive a successful platform engineering initiative, factors like data management and composability are equally crucial. Let’s delve into the unspoken truths of platform engineering by examining the fundamental principles necessary for a successful platform initiative.

Platform Engineering Untold Truths: Is It Just an Infrastructure Matter?

In a context where the ICT sector alone produces around the 1.4% of global CO2 emissions, adopting mindful resource usage is of paramount importance. One of the most challenging aspects about green software is understanding where to start. Before delving into more complex things, a good starting point is to raise awareness of the hidden ‘zombies’ within our infrastructure and then proceed to eliminate them. In this session, we’ll explore what green software is, its environmental and economic implications and how kube-green (an open source project listed in the CNCF landscape) immediately help us make our cloud infrastructures more sustainable.

An Open-Source First Step to Greenify Your Cloud Environments

The cloud-native landscape brings incredible advantages, but it also introduces new security challenges, making safeguarding a top priority. In the traditional policy enforcement model, manual management leaves organizations vulnerable to inevitable breaches due to human error – a matter of ‘when,’ not ‘if.’ Enter Policy-as-Code (PaC), a game-changing approach that leverages code to define and manage policies, transforming rules and conditions into actionable directives. By keeping policy definitions in source code control, whenever a change is made, it can be tested, validated, and then executed. The goal of PaC is not to detect policy violations but to prevent them. In this session we delve into the practical implementation of a Policy-as-Code strategy for your organization using Rönd and Open Policy Agent, two powerful open-source projects that could help you to redefine your security paradigm implementing an RBAC authorization mechanism over your APIs.

A Policy-as-Code Approach to RBAC Authorization

Platform engineering, digital platforms, platform maturity, platform-as-product… When we hear these terms, we often focus on the ‘what’: understanding what platform engineering is, what we mean by digital platforms, and what it means to apply a product mindset to platforms. However, mere knowledge of the ‘what’ is often not enough; the most curious among us have often asked about the ‘how’: how do I begin my journey into the world of digital platforms? Well, if you have ever found yourself hitting a wall when trying to understand how to start your journey in adopting a digital platform, you have found the workshop that suits you! In this interactive workshop, using a Platform Journey Map, we will play the role of a Solution Architect who has to guide real companies through their platform adoption journey. Yes, you heard that right, we will be playing, because the journey is presented as a board game where the players, our fantastic Solution Architects, must conquer spaces to mature their platform. In this workshop, we won’t just talk about digital platforms as mere orchestrators of infrastructure, but there will also be room to discuss software lifecycle, architecture modernization, business composability, and market use cases.

WORKSHOP | The Game of Platforms: A Guided Journey into the World of Digital Platforms

In today’s technological landscape, the synergy between Cloud Native technologies and Artificial Intelligence (AI) opens the stage to a myriad of unexplored challenges and opportunities. Dynamic, always-on and highly scalable infrastructures, typical of the Cloud Native paradigm, seamlessly integrate with AI’s need to rapidly prototype solutions and access vast computational resources. The convergence of these two worlds has exposed some gaps in the Cloud Native ecosystem that need to be addressed. At the same time, AI opens numerous opportunities for innovation that are yet to be explored. This talk will delve into the Cloud Native Artificial Intelligence (CNAI) paradigm as a holistic approach to unlocking the full potential of the cloud in managing AI workloads and aim to anticipate the growth opportunities that lie ahead for the Cloud Native world.

Challenges and Takeaways of Managing AI Workloads on Cloud

In rapidly expanding cloud-native ecosystem, managing distributed architectures feels like navigating stormy seas with waves of telemetry data. Yet this data can offer vital insights to sail smoothly. This session will explore strategies to avoid drowning, improving DevEx, and more. The cloud-native ecosystem has grown exponentially in the last few years, as has the complexity of the distributed architectures being built. In a context where keeping up with technology requires a substantial amount of computational power and data, monitoring our cloud-native applications has become a constant struggle against the storm. The ever-increasing volume of traces, metrics, events, and logs generated by our systems is a double-edged sword: on one hand, if not managed correctly, becoming a distraction from needed insights. On the other hand, if approached with care and thought, providing organizations the chance to sail calm cloud-native seas. In this session, we will discover how to avoid drowning in the sea of monitoring data, instead understanding how to provide insights while using only what is needed. We will explore the emerging scenarios on the horizon, abandoning the oars and testing the waters of artificial intelligence as it applies to our observability use cases. We will discuss how to leverage monitoring data, conversational DevEx, and anomaly prediction, among other topics, in this talk.

Finding Observability and DevEx Tranquility Sailing the Monitoring Data Seas

As a crucial part of a platform adoption journey, it’s essential to choose the right metrics to gain a clear, comprehensive view and drive success. While DORA metrics are valuable for platform teams, assessing platform adoption solely based on deployment frequency doesn’t make sense. Reflecting on our expertise, we’ve learned that measuring platform success involves two types of KPIs: progress metrics and outcome metrics. In this talk, we’ll explore how measuring both allows us to identify patterns and correlations between technical improvements and business success. By combining these two sets of KPIs, we gain a comprehensive view of the platform’s value. This approach helps stakeholders quantify the platform’s technical contributions while also understanding its influence on key business objectives. Ultimately, it enables us to set meaningful milestones for future improvements and effectively communicate the platform’s value across the organization.

From DORA to the SPACE and Beyond: Metrics to Drive Platform Engineering Initiatives

Monitoring the behavior of a system is essential to ensuring its long-term effectiveness. However, managing an end-to-end observability stack can feel like stepping into quicksand, without a clear plan you’re risking sinking deeper into system complexities. In this talk, we’ll explore how combining two worlds—developer platforms and observability—can help tackle the feeling of being off the beaten cloud native path. We’ll discuss how to build paved paths, ensuring that  adopting new developer tooling feels as seamless as possible. Further, we’ll show how to avoid getting lost in the sea of telemetry data generated by our systems. Implementing the right strategies and centralizing data on a platform ensures both developers and SREs stay on top of things. Practical examples are used to map out creating your very own Internal Developer Platform (IDP) with observability integrated from day 1.

When Platform Engineers Meet SREs: The Birth of Observability-as-a-Service Superpowers

Observability-as-a-Service: When Platform Engineers and SREs Join Forces

As the technology landscape evolves and the need for adaptability to solve modern problems grows, Function-as-a-Service (FaaS) has emerged as a pivotal strategy to meet the elasticity demands of today’s systems. However, a pressing question remains: how can we make our functions truly portable, with minimal overhead, while achieving the high level of dynamism promised by FaaS? The answer already exists, and you don’t need the Infinity Gems to make it happen. All you need is wasmCloud, a CNCF incubating project, and a few tips to take the right path in building your own FaaS platform using WebAssembly (WASM). In this talk, we will dive into the world of Functions-as-a-Service, sharing insights on building a FaaS platform from the ground up with WASM and wasmCloud. We’ll provide practical examples and demonstrate how to create paved paths that empower developers to build high-performance functions—effortlessly, as if snapping their fingers.

Platform Engineers Assemble! Create Your FaaS Platform Using WASM

As the world shifts toward renewable energy, the need to align computing workloads with the availability of green resources has never been more critical. In this talk, we’ll explore how Kubernetes can serve as a “compass”, guiding workloads across space and time to optimize energy efficiency. By leveraging temporal shifting to align workloads with periods of peak renewable energy generation and spatial shifting to dynamically move workloads to regions with surplus green energy, we’ll demonstrate strategies that not only reduce carbon footprints but also enhance cost-efficiency. Through real-world examples and practical insights, this session will showcase how temporal and spatial scheduling innovations can transform Kubernetes into a powerful tool for sustainable cloud operations. Join us to discover how to navigate the intersection of technology and sustainability, paving the way for a greener, smarter future.

The Kubernetes Compass: Navigating Space and Time for Energy Efficiency

In this session, we’ll explore how platform engineering enables the seamless delivery of an AI-powered agentic architecture—from deploying open-source models to building and releasing a simple agent that interacts with real-world applications. Through a joint demo by Mia-Platform and ConfidentialMind, we’ll demonstrate how a GPU-powered cluster hosts both the ConfidentialMind Control Plane and the AI models, while the Mia-Platform Console serves as the unified entry point for developers. We’ll walk through the creation of a multi-tool agent built from templates available on the Mia-Platform Marketplace and powered by models deployed using the ConfidentialMind Control Plane. This agent interacts with our data to act as a shopping assistant for customers, providing product recommendations, stock availability, and suggestions for the nearest store based on the user’s location. Attendees will gain a clear understanding of how platform engineering practices simplify the complexities of AI model deployment, application development, and runtime management in a production-grade, scalable environment.

How Platform Engineering Streamlines the End-to-End Delivery of a Self-Hosted Agentic Architecture

Monitoring the behavior of a system is essential to ensuring its long-term effectiveness. However, managing an end-to-end observability stack can feel like stepping into quicksand. In this talk, we’ll explore how combining two worlds, developer platforms and observability, can help tackle the feeling of being off the beaten cloud native path. We’ll discuss how to build paved paths, ensuring that adopting new developer tooling feels as seamless as possible.

ROUNDTABLE | When Platform Engineers Meet SREs: The Birth of Observability-as-a-Service Superpowers

APIs are more than just tools; they are the foundation for building scalable and sustainable digital products. This talk explores how circular design principles can improve the way APIs are developed and used, enhancing the developer experience and delivering long-term value. Through real-world examples, we’ll explore how to leverage platforms designed to enable a circular API economy that emphasizes reusability, modularity, and interoperability to drive innovation, reduce technical waste, and foster collaboration. If you’re looking to build products that not only scale but also evolve gracefully and efficiently, this talk is for you. In API we trust!

In API We Trust: Circular Design for Scalable Platforms

Why keep your cluster alive when you’re not using it? Let it bite the dust, every night, and that’s just fine. With Crossplane and kube-green, you can unlock ephemeral environments that spin up when you code and shut down when you rest. Imagine a development setup that dynamically provisions complex infrastructure for testing, then automatically scales down during off-hours – like nights and weekends. In this talk, we’ll show you how Platform Engineering can orchestrate this smart, on-demand model, so developers can focus on building applications, not babysitting clusters. You’ll see the integration in action, explore the impact on cost, efficiency, and sustainability, and discover how to shift from static uptime to dynamic, eco-friendly infrastructure. Save money, reduce emissions, and let your clusters rest – because we will rock you, but not all night long.

Another Cluster Bites the Dust... and That's Just Fine!

Perché mantenere acceso il tuo cluster quando non lo stai usando? Fai in modo che si spenga ogni notte! Con Crossplane e kube-green, puoi creare ephemeral environments che si attivano quando lavori e si spengono quando ti riposi. Immagina una configurazione che faccia il provisioning dinamico di un’infrastruttura complessa per i test, per poi spegnersi automaticamente durante le ore non lavorative come durante la notte o nei fine settimana. In questo talk, ti mostreremo come un IDP (Internal Developer Platform) può aiutare ad orchestrare in modo intelligente e on-demand la tua infrastruttura, in modo che gli sviluppatori possano concentrarsi sul creare applicazioni e non sul fare da babysitter ai cluster. Vedrai come funziona l’integrazione, esplorerai l’impatto su costi, efficienza e sostenibilità e scoprirai come passare da un infrastruttura statica a una dinamica ed eco-friendly. Risparmia denaro, riduci le emissioni e lascia riposare i tuoi cluster. Perché we will rock you, ma non per tutta la notte.

Another Cluster Bites the Dust… E Va Bene Così!

Get ready for a provocative and engaging session that challenges the very notion of who, or what, can deliver a compelling presentation! In this talk, an AI agent will be built right before your eyes. Using the Google ADK framework and Gemini, this agent will scour the internet, prepare a presentation, and then deliver it. But here's where it gets really interesting: by the end of the session, you, the audience, will choose the topic the AI agent has to talk about. This raises some fascinating questions: Can the information it presents be trusted? What does this mean for the future of knowledge and communication when an AI can 'speak' with authority? Join us to find out if an AI can truly become the speaker in the room!

Can an AI Agent Give a Talk? Let's Find the Speaker in the Room!

Generative AI is rapidly changing how we build software. With powerful language models (LLMs) and the growing availability of smaller, more accessible models (SLMs), we are entering a new phase of development where intelligent agents play a central role. Just like we once moved from procedural programming to object-oriented programming, we are now moving toward a model where software is built around interactions between AI agents. In this new approach, APIs are essential. They are how agents connect to the outside world, talk to each other, and work with existing systems. In this talk, we’ll look at how to design software based on agent interactions, with a special focus on how APIs make this possible. We’ll explore how generative models can power agents that use APIs, expose APIs, and coordinate tasks through APIs. You’ll also learn practical patterns for building systems where multiple agents collaborate effectively using clear and well-defined interfaces.

SLMs and the Agents Revolution: Rethinking How Software Is Built

Explore how to efficiently serve Large Language Models on Kubernetes clusters, covering resource optimization, scaling strategies, and best practices for platform engineers managing AI workloads in production environments.

Serving LLMs on Kubernetes: A Golden Path for Platform Engineers

Learn advanced techniques for optimizing Kubernetes clusters for energy efficiency, including intelligent scheduling, resource management, and sustainable cloud-native practices that reduce environmental impact while maintaining performance.

Join industry leaders in a panel discussion about the evolution of developer portals, exploring trends in developer experience, platform engineering, and the tools that will shape the future of software development workflows.

PANEL | The Future of Developer Portals

Similar to previous Kubernetes releases, v1.35 introduces new stable, beta, and alpha features, consisting of 60 enhancements. Of those, 17 have graduated to Stable, 19 have graduated to Beta, and 22 are entering Alpha. Tune in to see the latest and greatest from the Kubernetes v1.35 Release Team!

Cloud Native Live: Kubernetes v1.35 Release

We love ArgoCD, but it creates a classic 'map vs. territory' problem. We treat Git as our 'map', our single source of truth. But the cluster is the 'territory', and it's often more complex than the map shows. This becomes a crisis with the 3 AM hotfix: an SRE fixes production, changing the territory. ArgoCD, loyal to the map, sees this as drift and helpfully overwrites the fix, re-breaking the cluster. The problem is that Git isn't our Truth, it's our Intention. This talk introduces a pragmatic solution: Cluster-Scoped Snapshotting. We’ll show a simple pattern that dumps the entire live cluster state (the 'territory') into its own 'reality' Git repo. To automate this, we wrote a small open-source tool called Kalco, but the pattern is the real takeaway. This 'reality' repo gives us a powerful 'pre-flight diff' in our CI pipeline, comparing our 'intention' (the app repo) against the 'truth' (the snapshot repo). This simple check lets us bootstrap existing clusters, create a complete audit log, and stop our pipeline before it merges a change that conflicts with a critical live fix.

Your Cluster is Lying to ArgoCD (And How to Catch It)

We have spent the last five years building 'Golden Paths' to help developers deploy faster. But the moment the application hits production, the path ends. We leave developers alone with a dashboard of squiggly lines and ask them to 'fix the performance'. This is not Platform Engineering; this is just fancy provisioning. The next evolution of the Internal Developer Platform (IDP) isn't about deploying code, it's about optimizing it. In this talk, we will explore how to build a Continuous Optimization Layer directly into your platform. We will see how to pipe Prometheus telemetry back into the deployment manifest, creating a closed loop where the platform automatically suggests runtime tuning, from Kubernetes limits to application runtime flags, without the developer ever touching a YAML file.

The Self-Improving Platform: Closing the Loop Between Telemetry and Tuning

Beyond Deployment: Mapping the Reality of Day 2 Operations in Platform Engineering

Observability gets tricky when you take Kubernetes to the Edge. Sending full traces and metrics upstream doesn’t scale when every byte and millisecond count. This talk introduces an ultra-optimized OpenTelemetry Micro-Collector strategy built for Edge environments. It demonstrates how to minimize overhead without losing visibility by applying smart data reduction techniques like Tail-Based Sampling and Lossless Batching directly on the device, ensuring that only high-value telemetry such as errors and slow requests leave the Edge. The session covers how to deploy a lightweight DaemonSet tuned for K3s or MicroK8s using the OpenTelemetry Collector Contrib, integrate Fluent Bit for unified log ingestion, and maintain data integrity during disconnections. It shows what it takes to make observability truly sustainable in constrained Edge environments.

Making Observability Work at the Edge

As CNCF efforts evolve beyond infrastructure, improving the developer experience has become a central focus. The rebooted CNCF Technical Advisory Groups introduced TAG Developer Experience (TAG DevEx) to drive concrete, impactful outcomes across projects and their communities. This panel will showcase how TAG DevEx reduces friction in developer workflows, advances best practices, and delivers resources that benefit contributors and end users alike. We’ll highlight key initiatives and how TAG DevEx helps maintainers adopt a developer-first mindset. We’ll also discuss our ongoing efforts, including research around success stories and pain points from adopting secure coding practices, the emerging role of agentic AI in development, and a working group defining a specification for declaring application integration dependencies. Join us to learn how TAG DevEx is shaping the next generation of cloud native developer experience—and how you can get involved.

The Next Chapter of Developer Experience: TAG DevEx in Action

Mettere in piedi un’infrastruttura solida è solo l’inizio. La vera sfida è scalarla senza che i costi o la complessità gestionale vadano fuori controllo. In questo talk vedremo perché il Platform Engineering e l’Autonomous Optimization sono le due facce della stessa medaglia. Scopriremo come una moderna Internal Developer Platform (IDP) permetta di costruire i 'binari' (un’infrastruttura standardizzata e sicura) e come l'integrazione di sistemi di ottimizzazione autonoma agisca da 'pilota automatico', usando l'IA per decidere i parametri migliori in tempo reale. Smetti di combattere con i file YAML: impara a progettare un sistema che non solo funziona, ma impara a dare il massimo spendendo il minimo.

Da Zero a Cento: Costruire un’Infrastruttura che si Auto-Ottimizza

There is a silent war happening in your organization. The Finance team demands lower cloud bills, Product demands faster features, and Reliability demands zero downtime. Only a platform that helps you build efficient service by design could solve it.

Making Efficiency a Platform Capability

Modern runtimes like Java, Go, and Node.js face a critical 'resource gap'. They require a massive CPU burst for JIT compilation or dependency loading, only to settle into a much leaner steady state seconds later. Historically, we had to over-provision Pods for this peak, wasting thousands of cores across clusters. With In-Place Pod Resize in Kubernetes v1.35, we can finally implement a startup boost strategy. This session moves beyond the theory to show the technical 'how-to' where we will demonstrate how to build a reactive workflow that provisions high initial resources and then 'shrinks' the footprint silently via the resize sub-resource. Beyond the 'how-to', we must address the 'shrinkage trap' and explain how to time the resource reclamation to avoid aggressive CPU throttling immediately after boot. We will compare different implementation patterns including sidecar-driven patches, a dedicated boost-operator, and the native Vertical Pod Autoscaler, ensuring your applications don't just start fast but stay stable. Stop paying for peak startup power during hours of steady-state operation.

Stop Overprovisioning for Application Startup

Horizontal scaling is often the default response to increased load on Kubernetes, but it can mask deeper inefficiencies within the single pod. At EssilorLuxottica, we discovered that adding more replicas often just scales the waste. If a single pod isn't optimized, you aren't scaling, you are just over-spending until you hit the HPA maxReplicas limit and the system eventually fails. In this interactive 'choose your own adventure' session, we will re-live our optimization journey. The audience will decide the configuration: should we tweak the runtime heap or the K8s resource limits? Using data from our actual experiments, we’ll see the impact on throughput and costs, explaining the technical 'why' behind each result. We’ll show that true efficiency comes from the synergy between runtime settings and pod configurations. You’ll learn how to integrate automated experimentation into your delivery process to replace guesswork with data. This approach allowed us to reduce memory by 56% and costs by 30% while ensuring the system remains stable under load.

Stop Hiding Kubernetes Pod Inefficiencies With Horizontal Scaling

Modern platforms are no longer just infrastructure; they are the interface through which developers consume security, data, and operational services. In this panel we explore how platform engineering integrates AI/ML workloads, supply-chain security frameworks like SLSA, observability, performance optimization, and FinOps directly into platform primitives. Join us to discuss how shifting everything left enables secure, scalable platforms while keeping developer experience simple and productive.

PANEL | When Domains Collide: AI, Security & FinOps Inside the Platform Engineering Stack

OpenTelemetry is becoming standard—but running it well is still hard. This roundtable is led by OpenTelemetry maintainers and focuses on real-world challenges with observability pipelines, from scaling the Collector to managing cost, performance, and data volume. We’ll share what’s working in production, where teams struggle, and how the project is evolving—bring your questions and experiences.

ROUNDTABLE | OpenTelemetry in Production

Most Java applications on Kubernetes are 'silent money burners'. They are over-provisioned because developers fear the OOMKill, leading to massive cloud waste. But what if you could cut your resource usage by 40% without affecting stability? In this interactive 'Choose Your Own Adventure' session, you are an efficiency expert tasked with 'right-sizing' a bloated Java workload. Together, we will look at real-world production metrics and vote on how to optimize them. Should we switch the Garbage Collector? Should we lower the CPU requests? Or should we tweak the JVM ergonomics? Every choice has a cost and a risk. We will explore the hidden heuristics of the JVM and learn how to find the 'sweet spot' where performance meets cost-efficiency. Join us for a gamified deep dive into making Java a first-class, cost-friendly citizen of the cloud.

The Efficiency Mission: Shrinking Java Pods without the Drama


[Published by Akamas](https://akamas.io/resources/gpu-utilization-llm-inference-optimization/)

AI is reshaping every industry, and agents are at the center of that shift. Many companies are racing to put them to work building assistants that handle customer requests around the clock, pipelines that classify and route data without human input or systems that reason across tools and act on their own. The appeal is obvious. What’s easy to miss in all the excitement is that every one of those agents, no matter how capable it looks from the outside, runs on a model, and that model runs on a GPU that is the engine keeping the whole thing moving.

Enterprises are pouring billions into GPUs to run LLMs and AI agents. For the first time in computing history, we are seeing data-center build-outs at a scale never witnessed before, where the GPU portion alone can account for as much as [70% of total investment](https://www.innovationendeavors.com/insights/future-data-centers), according to recent industry estimates.

Then the first real utilization reports come in. The number is hard to ignore: GPU usage as low as 5%. You might be spending millions on accelerators while [95% of that capacity sits idle](https://akamas.io/resources/gpu-utilization-llm-inference-optimization/#:~:text=AI%20is%20reshaping,the%20same%20hardware.) and yet almost every platform and engineering leader we talk to is trying to do the same thing: buy more GPUs to support the GenAI use cases moving into production this year. **The bottleneck, as it turns out, is usually not capacity but configuration.** On a stack as deep as the GenAI one, the gap between a default setup and a properly tuned one can easily reach 2x throughput or more on the same hardware.

![](https://akamas.io/wp-content/uploads/2026/06/AI-factory-ROI-equals-GPU-utilization.png)

This is the central tension we explored in our recent [webinar](https://akamas.io/events/webinar-genai-optimization-kubernetes/) with Daniele Zonca and Roland Huß from Red Hat, who quite literally wrote the book on running generative AI on Kubernetes.

## We’ve Already Seen This Pattern with CPUs

Here’s a number that should worry anyone treating GPUs the way they treated CPUs. Across one of our customers, with several dozen Kubernetes clusters and around 60,000 CPUs, average utilization over a full day was **5%**. At cloud prices, that adds up to roughly $15 million a year spent on resources that are almost entirely idle.

Those are CPUs. Now apply the same operational habits (over-provisioning, ignoring efficiency, assuming the answer to every capacity question is “add more”) to hardware that costs roughly 40x more per unit and is genuinely scarce. In much of Europe you simply can’t procure H100s on demand, no matter how big your budget is. If 5% utilization on cheap, abundant CPUs costs **$15 million a year**, the equivalent waste on GPUs is an order of magnitude worse. It can quietly block the ROI of an entire GenAI initiative.

## Why GPUs Are So Easy to Waste

GPUs are nothing like CPUs, and that difference is exactly why they’re hard to keep busy.

A **CPU is built for latency**: most of its silicon is dedicated to control logic and caches that predict what comes next, so that a handful of threads can execute general-purpose work as fast as possible otherwise a **GPU is built for throughput**: almost the entire chip is devoted to computation, with thousands of cores optimized for the matrix multiplications that LLM serving depends on. Think of a CPU as a fast motorbike and a GPU as a cargo ship.

The catch is feeding that cargo ship. Every computation requires data to move from high-bandwidth memory (HBM) into the cores, and that transfer frequently becomes the real bottleneck, which is the first reason GPU utilization ends up so low.

This gets sharper once you look at how inference actually runs, across two very different phases:

1. **Prefill** processes the entire input prompt in parallel to produce the first token. It is compute-bound and drives your time to first token (TTFT), which is the waiting time your user feels before anything appears on screen.
2. **Decode** generates tokens one at a time, each step reusing the KV cache built from all previous tokens. It is memory-bound and drives your time per output token (TPOT), which measures how fast the response streams out.

Because the same hardware handles two completely different access patterns, optimizing for one does not automatically improve the other. That mismatch is a core source of complexity in the whole stack.

## The Trade-off You’re Probably Losing On

NVIDIA’s Jensen Huang has popularized a chart worth understanding. When you plot total token throughput (your revenue proxy, since AI services are priced per token) against per-user interactivity (latency), you don’t get a single best point. You get a **Pareto front**: a curve of configurations where improving one dimension always costs you something on the other.

![](https://akamas.io/wp-content/uploads/2026/06/Extracting-2x-throughput-from-the-same-GPUs.png)

Push for maximum throughput and single-user latency suffers. Push for fast responses and you sacrifice a large share of GPU capacity.

Your use case fixes one constraint on that curve. A chatbot needs to emit tokens faster than human reading speed (around 200ms per token) or it feels sluggish and users leave. That means you have a fixed latency limit you cannot cross.

But along that line sit hundreds of possible configurations, and most teams are unknowingly sitting on a suboptimal one. A single misconfiguration can cut effective throughput in half, leading teams to conclude they’re maxed out and order more GPUs, when in reality they’re using only half of what they already paid for.

With proper tuning, doubling the throughput from existing hardware is not unusual. That is the real opportunity.

## The Playbook: Getting 2x from the GPUs You Already Have

The GenAI stack has hundreds of tuning knobs, from the model down to the kernel and Kubernetes itself. That depth is the real challenge. The skills needed to navigate it effectively are genuinely hard to find, which means most teams end up working with defaults that no one has had the time or expertise to question. Here are the levers with the highest payoff.

![](https://akamas.io/wp-content/uploads/2026/06/The-full-stack-LLM-inference-optimization-layers.png)

1. **Right-size the model, then quantize it**

Defaulting to the biggest model for every request is rarely the right call. Smaller and reasoning-tuned models can match quality on the right tasks, and a well-designed agent framework can maintain accuracy while running a smaller model. Quantization can compress a model to as little as 25–30% of its original size while preserving most of its accuracy, which is a significant reduction in resource use for almost no quality cost.

2. **Route intelligently and exploit cache locality**

Pick the right model per request, but also send follow-up messages to the replica that already holds the relevant KV cache. Multi-turn chat and agentic flows send the whole growing conversation back and forth, so cache-aware routing is critical to avoid recomputing work you’ve already done.

3. **Tune the inference engine and the parallelism strategy**

The engine layer around vLLM (or any other inference server) is evolving fast. It pays to match the parallelism strategy to your model:

- *Data parallelism* (replicas behind a load balancer) scales concurrency but not single-request latency.
- *Pipeline parallelism* splits a too-big model across nodes by layers.
- *Tensor parallelism* splits within a node using NVLink/NVSwitch to actually improve latency.

You can combine pipeline and tensor parallelism to get the best of both, but neither is free of trade-offs. Pipeline parallelism is constrained by inter-node network latency, which can be 25–50x slower than staying on a single node. Tensor parallelism introduces its own synchronization overhead across the NVLink fabric inside the node. The right combination always needs to be validated against your specific setup rather than assumed to work out of the box.

4. **Match hardware to the bottleneck**

If your constraint is in the decode phase, the real problem is memory bandwidth. Buying the GPU with the most teraflops will not help. Disaggregated serving (separating prefill and decode pools, as projects like llm-d enable) lets you scale each phase independently and route large inputs to dedicated prefill instances. As inference scales out, expect training-grade networking such as RDMA and InfiniBand to start mattering for inference as well.

5. **Partition GPUs with care**

If a GPU is allocated but underused, you may be able to host a second model on it, but GPUs have both a compute side and a bandwidth side. Partitioning can create a noisy-neighbor effect: spare capacity on paper does not guarantee you can add load without degrading both workloads. Always validate the impact before packing more onto a single card.

6. **Measure what you optimize**

None of these changes are safe to make without proper visibility. Track LLM-specific metrics (TTFT, TPOT), lean on the OpenTelemetry semantic conventions emerging for GenAI, and use tracing tools like MLflow to follow non-deterministic, multi-hop agentic requests. This also gives you the data for internal cost allocation across teams.

GPU-level metrics deserve special attention because they are significantly harder to interpret than application-level ones. Tools like NVIDIA’s DCGM give you utilization numbers, but those numbers are often too coarse to identify whether your actual bottleneck is compute, memory bandwidth, or something else. GPU memory bandwidth, for instance, cannot be directly measured from DCGM at all: vLLM can expose an estimation through the –enable-mfu-metrics flag, but it remains an approximation. To make things more confusing, “GPU utilization” means very different things depending on which layer of the stack you’re looking at (allocation, kernel execution, or model FLOP/s), and conflating them leads to wrong conclusions.

7. **Load test with your own traffic, not a vendor benchmark**

Traditional tools like k6, JMeter, and Locust work at the application level, but purpose-built tools like GuideLLM (part of the vLLM project) let you build realistic, record-and-replay workloads that reflect how your system is actually used. The most important point here is to always build your test dataset from real traffic, because a vendor’s benchmark on a foundation model says nothing about how the system will behave under your specific workload. The optimization space for GenAI is too workload-dependent for generic results to transfer.

## Too Many Knobs for a Human to Tune

With hundreds of knobs spread across three fundamentally different layers (the model, the inference server, and the GPU itself), millions of possible combinations, and a target that shifts with every new use case and every new model release, this is not a one-off exercise you do at launch. It is a continuous practice.

Each layer also requires different expertise. The people who understand model selection and quantization are rarely the same people who can tune vLLM internals or reason about GPU memory bandwidth, and finding someone who spans all three is genuinely uncommon. That makes this well beyond what any team can manage by hand.

The emerging answer is to use AI to optimize AI systems: autonomous tuning that explores the configuration space and finds the settings that maximize throughput while staying within your latency and cost targets. This is exactly the problem [Akamas](https://akamas.io/akamas-ai-infrastructure-optimization-launch/) was built to solve, first for traditional Kubernetes workloads and now for GenAI inference, and we have something significant coming on that front that we will be sharing very soon.

## The Bottom Line

As enterprises move AI agents into production and pour significant capital into the GPU infrastructure to support them, the pressure to show returns on that investment is growing fast. But utilization tells a different story, and the 5% figure is not a hardware problem. It is what happens when a genuinely complex stack gets deployed with default settings and no one has the time to tune it properly.

The good news is that the same depth that makes the GenAI stack hard to configure also creates real headroom. The difference between where most teams are parked today and what their existing hardware can actually deliver is large enough to change the ROI equation entirely.

You do not need more GPUs to get there. You need visibility into your actual bottleneck, a realistic picture of your workload, and a systematic way to explore the configuration space. Everything else in this article follows from those three things.







[Published by PlatformEngineering](https://platformengineering.org/blog/transforming-optimization-into-an-invisible-platform-capability)

In the high-stakes world of cloud-native delivery, organizations are frequently paralyzed by an "invisible wall" that fundamentally separates FinOps professionals, Site Reliability Engineers, and Developers. 

This structural friction strongly resembles a dysfunctional michelin-starred kitchen where the night’s success depends on characters who rarely see eye-to-eye on the operational priorities required to serve a flawless meal. 

![](https://cdn.prod.website-files.com/6489e23dd070ba71d41a33b2/6a0c8288c5dd8bfc13916685_Screenshot%202026-05-19%20at%2017.32.11.png)

Because these highly specialized teams speak entirely different languages regarding risk and reward, this dynamic creates a zero-sum game where the organization must continuously trade off cost for reliability or speed for efficiency. 

When a FinOps spreadsheet indicates that a Kubernetes pod is mostly idle, the SRE immediately perceives a threat to their carefully calculated reliability buffer, while the developers simply lack the contextual data to know how much compute space their specific application actually requires under realistic load. 

This operational paralysis is further exacerbated by the shared ownership model prevalent in many modern enterprises, where a lack of singular accountability means that reactive cost-cutting and conservative over-provisioning remain the default strategies.

## The day 2 operational gap

To break this destructive cycle, we must stop treating operational efficiency as a manual "spring cleaning" task and start recognizing it as an essential requirement that must be embedded deeply within modern platform architecture. 

While the platform engineering community has excelled at creating golden paths to streamline the initial developer experience and deployment pipelines, the lifecycle of applications reaching production has been largely neglected. Currently, our primary method of assisting developers with post-deployment optimization relies on providing access to passive monitoring dashboards rather than delivering automated, actionable intelligence. 

Organizations are striving to run highly performant applications while simultaneously maintaining strict cost controls and ensuring absolute reliability, but static golden paths are simply insufficient for managing this delicate trade-off. 

When building deployment pipelines, everyone shares the single goal of releasing software, which allows for strict and opinionated automation. However, production optimization requires a highly configurable approach because different applications inherently require dynamic tuning strategies tailored to their specific risk profiles and performance needs. For these reasons, static deployment pipelines inevitably fall short during Day 2 operations and lead to systemic resource waste.

## The full-stack optimization puzzle

True optimization represents a complex multi-layered puzzle that extends far beyond simply resizing Kubernetes pods or shutting down idle development environments after business hours. 

Deep efficiency must begin at the application runtime level by tuning elements like the Java Virtual Machine heap size or garbage collection settings to ensure the core workload operates at peak health. Once the runtime is properly configured and understood, engineers can accurately size the container requests and limits to perfectly encase that specific application without causing artificial throttling or fatal memory errors. 

This layered approach must also carefully incorporate how you scale horizontally and the underlying node groups to ensure the entire system remains stable when infrastructure density increases. Without looking at this vertical stack of dependencies, scaling policies might rely on superficial metrics that do not align with the newly established pod boundaries.

![](https://cdn.prod.website-files.com/6489e23dd070ba71d41a33b2/6a0c82b03624c5b2b527b085_Screenshot%202026-05-19%20at%2017.32.51.png)

This inevitably causes the system to fluctuate unpredictably and degrade the performance of your applications. You cannot effectively optimize a system if you treat the container as an opaque black box, yet industry data shows that very few companies actually attempt to tune the container and the runtime in tandem.

### Resolving the kitchen conflict

To solve this puzzle, we must address the conflicting motivations of the specialized roles mentioned earlier. The "invisible wall" persists because each player in the kitchen has a different definition of success:

- The **FinOps** team acts as the restaurant owner who scrutinizes every cloud expenditure and demands higher utilization rates to justify the infrastructure investments.
- The **Site Reliability Engineers** operate as the executive chefs who prioritize absolute uptime and system stability, often demanding massive resource buffers to absorb unexpected traffic spikes.
- The **platform team** serves as the overwhelmed manager attempting to standardize infrastructure while keeping the peace.
- The **developers** act as line cooks who desperately try to innovate without clear guidance on the resource constraints they must operate within.

## Integrating efficiency into the GitOps workflow

By integrating performance gates directly into the continuous integration and continuous deployment pipeline, the platform team establishes a controlled environment where efficiency becomes a core component of the software release lifecycle. 

These purpose-built platform capabilities can continuously analyze historical observability data to generate intelligent recommendations based on predefined tuning profiles that strictly respect the safety limits established by the SRE team.

![](https://cdn.prod.website-files.com/6489e23dd070ba71d41a33b2/6a0c82cefc9e4e1f6cdac159_Screenshot%202026-05-19%20at%2017.33.24.png)

The most effective way to implement these data-driven recommendations involves establishing a human-in-the-loop workflow driven entirely through established GitOps principles. Whenever the platform identifies a more efficient configuration that satisfies both cost constraints and performance requirements, it seamlessly opens a pull request directly in the developer's repository containing the evidence-based sizing adjustments. 

Developers can easily review these insights within their existing tools and approve the new configuration with absolute confidence, knowing that the proposed changes have been mathematically validated against the organizational reliability standards. 

By embedding these automated right-sizing mechanisms directly into the golden path, the platform truly becomes a unified bridge that eliminates the historical friction between engineering departments. This approach moves the organization beyond simple infrastructure provisioning to create a self-improving ecosystem where cost-awareness and performance are continuously balanced without requiring constant human intervention.

By transforming optimization from a manual chore into an invisible platform capability, we solve the "Michelin kitchen" dilemma. This shift allows developers to focus entirely on innovation and feature delivery while the underlying system ensures the organizational menu is always perfectly optimized for both the business and the end user. When efficiency is automated, the invisible wall disappears, replaced by a seamless path toward sustainable, high-performance delivery.


[Published by CNCF co-authored with Hélia Barroso, Alessandro Pomponio, Sonali Srivastava](https://www.cncf.io/blog/2026/04/29/the-state-of-ai-in-cncf-projects-a-first-look-at-the-data/)

At **CNCF TAG Developer Experience**, we recently set out to understand how Artificial Intelligence is shaping open-source development. The response from the community has been impressive in its scale, with nearly half of our initial responses arriving within the first week alone. This immediate engagement highlights the urgency of the topic and the community’s desire for shared guidelines for AI-assisted development.

The data collected from 133 respondents so far represents **nearly 100 unique projects**, giving us confidence that these findings reflect the cloud-native ecosystem at large rather than a narrow subset of projects. This article serves as a sneak peek into our initial findings; a more comprehensive analysis will follow as we process further data.

### Who is answering?

The feedback primarily reflects the perspectives of those on the front lines. The vast majority of participants are code-centric contributors focusing on submission, CI/CD, and infrastructure, while approximately 20% combine engineering with critical roles like release management and documentation.

### How maintainers use AI: Tools and workflows

Modern AI tools have moved beyond simple web chatbots and are now deeply integrated into daily routines. Nearly half of respondents actively use AI assistants directly within their IDEs or command-line interfaces.

![A blue bar graph showing the levels of basic, advanced, other and intermediate. ](https://www.cncf.io/wp-content/uploads/2026/04/image-14.png)

A blue bar graph showing the levels of basic, advanced, other and intermediate.

When it comes to tooling, Claude Code and Github Copilot emerge as clear leaders in the space. Interestingly, only a small fraction (roughly 10%) of contributors still rely on basic chatbots via manual copy-pasting. Meanwhile, a similar percentage of advanced users has already moved toward “high-level integration,” where AI is built directly into project automation for PR reviews and issue triaging.

### Where AI helps the most

Contributors are seeing the most significant boosts in productivity within a few specific areas:

- Writing and refactoring code.
- Improving documentation and debugging.
- Understanding unfamiliar codebases.
- Analyzing Pull Requests.

The high ranking of “understanding the codebase” suggests that AI is acting as a knowledgeable guide, helping developers navigate the inherent complexity of large-scale projects.

### The gap between AI use and official policies

One of our most striking findings is the disconnect between individual AI usage and formal project governance. While local AI use is widespread, the adoption of official policies has lagged behind.

Roughly two-thirds of respondents are either unaware of any specific AI guidelines or confirmed that no official policies exist in their main repositories. Furthermore, the vast majority of projects make no mention of AI usage in their public-facing documentation or contributing guides. While a few pioneering projects are setting the pace with clear policies, the ecosystem is largely operating in an environment that is still figuring out how to govern automated code generation.

![An orange bar graph showing levels of clear policies, informal acceptance and unaware/no policy ](https://www.cncf.io/wp-content/uploads/2026/04/image-15.png)

An orange bar graph showing levels of clear policies, informal acceptance and unaware/no policy

### Community sentiment and code reviews

Despite the lack of formal rules, the general “vibe” toward AI is open and accepting. Roughly one-third of contributors noted that AI usage is generally allowed. Conversely, only a tiny minority (less than 4%) reported that AI usage is explicitly prohibited in their environments.

![A green bar graph showing levels of 'unsure', 'not required', 'specific cases only' and 'always require disclosure.' ](https://www.cncf.io/wp-content/uploads/2026/04/image-16.png)

A green bar graph showing levels of 'unsure', 'not required', 'specific cases only' and 'always require disclosure.'

This pragmatic approach extends to how maintainers handle AI-generated contributions:

- A solid majority follow their standard review process without applying special filters.
- Over a quarter of maintainers prefer a collaborative approach, asking contributors to refine AI-generated code to meet quality standards rather than rejecting it.
- Only a nominal percentage automatically reject suspected AI PRs.

### Top concerns and the call for transparency

While the community is optimistic, several valid concerns remain. Maintainers are particularly worried about:

1. Security vulnerabilities
2. License compliance.
3. The burden on reviewers, caused by **a potential flood of low-effort PRs**.

To mitigate these risks, there is a strong collective desire for visibility. Over half of respondents believe that AI-assisted contributions should always require formal disclosure (such as an “AI-authored” tag). An additional 20% feel disclosure should be required in specific cases. This suggests that while maintainers are willing to accept AI-generated code, they want the transparency necessary to adjust their review efforts accordingly.

### Wrapping up

This first batch of data confirms that AI integration is no longer a trend, it is a core part of the modern workflow. As we move forward, the challenge for the cloud-native community will be balancing this new productivity with the high standards of security and manual oversight that enterprise-grade open source requires.

We aren’t finished yet! To ensure our final report truly reflects the diverse cloud-native landscape, we need your voice. The survey will remain open until Monday, May 18 (End of Day, Anywhere on Earth).If you haven’t shared your experience yet, we invite you to [**contribute to the survey**](https://forms.gle/tBjQp9sFnBF3CXE17) and help us build a more accurate and comprehensive picture of AI’s role in our community.


[Published by Akamas](https://akamas.io/resources/bridging-finops-sre-platform-teams-kubernetes/)

In the world of fine dining, the tension in the kitchen is palpable long before the first guest arrives. Imagine a prestigious Michelin-starred restaurant where the night’s success depends on **four formidable characters who rarely see eye-to-eye**. There is the Owner, who meticulously tracks the cost of every truffle and the electricity bill of the walk-in freezer; there is the Executive Chef, who would rather throw away ten gallons of perfectly good consommé than risk serving a single plate that is less than transcendent; there is the restaurant manager, who struggles to coordinate the chaotic flow between the ovens and tables using a reservation system that feels increasingly outdated; and finally, there are the Line Cooks, the ones actually preparing the dishes.  
  
If the Owner cuts the budget too thin, the quality of the food collapses. If the Chef over-prepares to ensure they never run out of ingredients, the restaurant bleeds money through food waste. If the Manager fails to sync the two, the entire experience becomes a slow-motion disaster. The Line Cooks are caught in the middle: they want to innovate and serve great food, but they lack the data to know if they are using too many expensive ingredients or if their “stove” is set to the right temperature.

In the digital landscape of cloud-native enterprises, our Kubernetes clusters are the kitchens, and our microservices are the delicate dishes being served to millions of hungry users. The **FinOps** team acts as the Owner, scrutinizing the cloud bill and demanding that we stop paying for “tables” that sit empty during off-peak hours. The **Site Reliability Engineers (SREs)** are our Chefs, their reputation is built on uptime and performance, and for them, an over-provisioned cluster is not waste: it is the extra pantry stock that prevents a catastrophic “sold out” sign during a traffic surge. Meanwhile, the Platform Team is the Manager, trying to build a standardized infrastructure that keeps the peace while the tickets pile up. In this scenario, the Developers are the Line Cooks creating the recipes: without clear guidance, they end up requesting more fridge space than necessary, fearing that the Chef (SRE) or the Owner (FinOps) will take away the “heat” they need to finish the service.

## The Invisible Wall

This structural gap is what we call the ***Invisible Wall***. It is a byproduct of specialization where everyone is doing their job perfectly, yet the organization as a whole is failing to achieve true efficiency. According to the [2026 FinOps Foundation’s State of FinOps](https://data.finops.org/#priorities) report, the primary challenge for organizations has shifted toward reducing waste and over-provisioning while still struggling with “empowering engineers to take action”.  
  
This isn’t because engineers are lazy; it is because the Merchant, the Chef and the Line Cooks speak different languages. When a FinOps spreadsheet says a pod is 80% idle, the SRE hears a threat to their reliability buffer while Developers simply lack the data to know how much space their specific application actually requires. Without a shared source of truth that translates “dollars saved” into “risk managed”, these teams remain locked in a cycle of conservative over-provisioning and reactive cost-cutting.

![Diagram showing how FinOps, SRE, Developers and Platform teams' conflicting priorities lead to over-provisioning and friction in Kubernetes environments](https://akamas.io/wp-content/uploads/2026/04/invisible-wall-finops-sre-devs-platform-kubernetes.png.png)

Diagram showing how FinOps, SRE, Developers and Platform teams' conflicting priorities lead to over-provisioning and friction in Kubernetes environments

The tragedy of this friction is that it treats optimization as a zero-sum game, a world where you must choose between a healthy bottom line and a reliable service. Ironically, this defensive over-provisioning doesn’t just inflate the bill; it often results in suboptimal performance and reliability issues, such as unexpected Out-Of-Memory (OOM) errors, as teams lack the precision to balance resources correctly. However, the reality of modern cloud-native architecture is far more nuanced. True efficiency is not about buying cheaper ingredients: it is about the fit of the resource to the task. That is the very principle on which [Akamas Insights](https://akamas.io/insights/) was born. To achieve adequate **fit** for purpose, [Akamas Insights](https://akamas.io/insights/) introduces the concept of the ***Tuning Profiles***. Think of it as the “House Rules” or the “Recipe Standard” for the kitchen. A Tuning Profile allows the Platform Team and the SREs to define the boundaries of optimization specifying which objective matters most (such as cost reduction or latency improvement) and which constraints must be respected (such as minimum replicas or memory headroom). By establishing these profiles, the Chef (SRE) can trust that the “Owner’s” demands will never violate the fundamental safety limits of the service.

![Diagram showing how Akamas Insights aligns FinOps, SRE, and Platform teams around a shared view to achieve high reliability and low waste in Kubernetes](https://akamas.io/wp-content/uploads/2026/04/akamas-insights-shared-truth-finops-sre-platform.png-2048x685.png)

Diagram showing how Akamas Insights aligns FinOps, SRE, and Platform teams around a shared view to achieve high reliability and low waste in Kubernetes

## The Full-Stack Recipe

Instead of looking at a Kubernetes cluster as a collection of static boxes, Akamas Insights treats the environment as a living, breathing organism. By bridging the gap between infrastructure metrics and application runtime behavior, it allows the Owner, the Chef, the Manager and the Line Cooks to finally look at the same dashboard and see the same truth.

When we talk about deep, **full-stack optimization**, we are looking at the vertical stack of dependencies. Optimization is a multi-layered puzzle that starts at the Application Runtime (tuning JVM heap or Go GC) to ensure the engine is healthy. Only then do we move to the Pods, sizing requests and limits to perfectly encase that runtime. Crucially, this is where we also align the Horizontal Pod Autoscaler (HPA). If an HPA is scaling based on a metric that doesn’t align with the Pod’s new limits, the system will “flap” and become unstable. Akamas Insights coordinates these layers to ensure that when we increase density, the contents still have room to breathe.

Finally, we size the Node Group accordingly, ensuring the underlying hardware is the right vessel for these optimized and correctly-scaled containers**.** By following this sequence, the infrastructure becomes a direct reflection of the application’s actual needs, rather than a collection of oversized safety nets.

![Three-layer model showing how full-stack Kubernetes optimization spans App Runtime (JVM, concurrency), Pods and HPA (CPU, memory, scaling), and Node Groups to achieve optimal density](https://akamas.io/wp-content/uploads/2026/04/full-stack-kubernetes-optimization-layers-jvm-pods-nodes.png-2048x545.png)

Three-layer model showing how full-stack Kubernetes optimization spans App Runtime (JVM, concurrency), Pods and HPA (CPU, memory, scaling), and Node Groups to achieve optimal density

## Action over Analysis

This level of insight transforms the conversation from one of ***cutting*** to one of ***tuning***. In our restaurant metaphor, this is the equivalent of a smart inventory system that knows exactly how many guests are coming, their dietary preferences, and the precise temperature each oven needs to be to minimize energy without losing a degree of heat. When the Platform Team can present an optimization plan **backed by a verified Tuning Profile** that accounts for JVM heap settings, CPU cores, and node affinity, the SRE no longer feels the need to hoard resources “just in case”. They can see, through data-driven and historical analysis, that the new configuration is actually more stable than the old, bloated one.

Furthermore, the industry is beginning to realize that the “Spring Cleaning” approach to cloud costs is fundamentally broken. You cannot achieve a Michelin star by cleaning your kitchen once a year: it requires constant, meticulous attention to detail. Yet, many organizations still treat FinOps as a quarterly audit and a reactive “Crawl” stage behavior. According to the [FinOps Foundation’s Workload Optimization](https://www.finops.org/framework/capabilities/workload-optimization/) capability, true maturity (the “Run” stage) is defined by a shift toward **Continuous Optimization**.

However, the path to this maturity is not about handing the keys of the kitchen over to an unpredictable autonomous agent. In a world where reliability is paramount, a “black-box” real-time approach can introduce more instability and “flapping” than it solves. True excellence requires a **Human-in-the-Loop** model where the Developers (the Line Cooks) are the essential piece. Instead of chasing every micro-fluctuation, the most effective optimization happens in lockstep with the **release cycle**.

![Workflow diagram showing the continuous optimization cycle with Akamas Insights: deploy, analyze telemetry, generate AI-powered recommendations, human review, and apply to next release](https://akamas.io/wp-content/uploads/2026/04/akamas-insights-release-analyze-recommend-apply-loop.png-2048x336.png)

Workflow diagram showing the continuous optimization cycle with Akamas Insights: deploy, analyze telemetry, generate AI-powered recommendations, human review, and apply to next release

Every time a new version of the “menu” is released, Akamas Insight performs a deep analysis of the previous cycle’s telemetry. It then generates intelligent, evidence-based recommendations tailored to the Tuning Profile. These recommendations are presented to the Developers for review. This is the “aha!” moment: the developer sees exactly how their code performs and can approve the new configuration with one click, knowing it aligns with the safety standards set by the SRE. This ensures that resource efficiency is balanced against performance and reliability within a controlled, predictable workflow: **Release, Analyze, Recommend, and Apply**. By connecting directly to the telemetry data teams already have, Akamas Insights turns the release cycle into a self-improving loop of continuous harmony.

## The Michelin Standard of Engineering

This transition allows the Platform Team to fulfill its true potential. Instead of being the “Manager” who spends all night mediating between the “Owner” and the “Chef”, they become the architects of a system that empowers Developers to be efficient by default. This creates a culture of “Unit Economics”, where the cost of a transaction is as much a part of the performance metric as latency or error rate. When everyone understands that a 10-millisecond improvement in code efficiency translates directly to a specific reduction in the cloud bill, the silos finally begin to crumble.

The beauty of this harmony is that it liberates the human talent within the organization. Engineers who used to spend their weeks manually tweaking YAML files and arguing over resource limits are suddenly free to innovate. The FinOps team moves from being the “budget police” to being strategic advisors who can predict how a new product launch will impact the bottom line with surgical precision. The SREs can sleep through the night, knowing their clusters are not just “big enough”, but “accurate enough”.

As we look toward the future of cloud-native technology, the goal is no longer just “getting to the cloud”. We are already there. The goal is to live in the cloud with grace and precision. We must move beyond the blunt instruments of the past and embrace a more sophisticated way of managing our digital kitchens. The “Michelin Star” of engineering is awarded to those who can deliver a flawless user experience with the elegance of a perfectly managed budget. By using intelligent, full-stack insights to bridge the gap between our teams, we stop guessing, stop wasting, and finally start cooking with fire.

Personal website of Graziano Casto, DevRel Engineer at Akamas, CNCF TAG DevEx Tech Lead, Kubernetes Blog Maintainer.

Graziano Casto — DevRel Engineer

Graziano Casto

Senior DevRel Engineer at Akamas, Tech Lead at CNCF TAG Developer Experience, Kubernetes Blog Maintainer, and Open Source advocate specializing in Cloud Native technologies.

Graziano Casto

Featured Articles

Upcoming Talks