The landscape of cloud computing is undergoing a significant transformation, driven by the increasing adoption of Arm-based processors. At KubeCon Europe in Amsterdam, The New Stack sat down with Jago Macleod and Abdel Sghiouar from Google Cloud to discuss the impact of their Arm-based Axion processors on Kubernetes users, nearly a year after their production deployment. Their central argument is compelling: the era of complex migrations to Arm for containerized workloads is largely over, with the necessary infrastructure and tools now readily available for widespread adoption.
The conversation, captured in a recent podcast episode, delved into the strategic positioning of Google’s custom Arm CPU within Google Kubernetes Engine (GKE), the growing importance of compute classes over specific chip architectures, and the overarching constraint of energy efficiency in modern computing. Macleod succinctly summarized the future of processor economics: "It’s essentially going to boil down to tokens per watt. And I think we will end up selling watts, not CPUs." This sentiment underscores a shift in how computing resources are valued, with energy efficiency becoming a paramount concern, particularly in the context of burgeoning AI workloads.
The Genesis and Evolution of Google’s Axion Processors
Axion represents Google’s inaugural custom Arm CPU, a significant milestone in its silicon development strategy. Built upon Arm’s robust Neoverse platform, the Axion processor was officially announced in April 2024. The initial general availability (GA) for the C4A series, the first Axion virtual machine instance family, commenced in October 2024. This was swiftly followed by the N4A series in January 2026, a configuration meticulously optimized to deliver a balanced price-performance ratio.
Google’s performance claims for Axion are substantial, asserting a 50% improvement in performance and a 60% enhancement in energy efficiency when compared to comparable x86 instances. The N4A variant, in particular, is reported to offer a remarkable 2x price-performance advantage for general-purpose workloads. These figures are not merely theoretical; they reflect real-world improvements that can translate into significant cost savings and increased operational capacity for businesses leveraging Google Cloud.
The strategic decision to develop custom Arm silicon aligns with a broader industry trend. For years, the x86 architecture has dominated the server market. However, the inherent power efficiency and scalability of Arm processors have made them increasingly attractive, especially for data-intensive and cloud-native applications. Google’s investment in Axion signals a strong commitment to this architectural shift and aims to provide its customers with a competitive edge.
Simplifying the Transition: Arm as a Deployment Target
A recurring theme in discussions with potential adopters of Arm-based infrastructure is the perceived complexity of migrating from established x86 environments. Jago Macleod addressed this concern directly, stating, "One thing I hear a lot is customers perceive it to be a big migration from x86 to Arm. That’s not the experience that I hear and see. It’s more about you just compile to a different deployment target." This perspective reframes the transition from a daunting overhaul to a manageable adjustment in the development and deployment pipeline.
The practical implementation of this simplified transition on Google Kubernetes Engine (GKE) involves a straightforward process. Macleod elaborated that adding an Axion node pool to an existing GKE cluster is relatively easy. The primary requirement is to rebuild container images to be multi-architecture, meaning they can run on both x86 and Arm processors. Once the images are prepared, pods can be tagged with a node selector to direct them to the appropriate Arm-based nodes.
Abdel Sghiouar highlighted the flexibility of this approach, emphasizing the possibility of gradual adoption: "You could do that gradually. You don’t have to do that all or nothing. You could do a canary deployment – 5%, 10% – and monitor your baseline for errors, for performance." This incremental strategy allows organizations to test the waters, validate performance and stability, and mitigate risks before committing to a full-scale migration.
While the vast majority of containerized workloads can seamlessly transition to Arm, the Google Cloud team acknowledged that certain edge cases might present challenges. These are typically found in highly specialized applications that rely on intricate floating-point mathematics that may exhibit minor discrepancies across architectures, or in low-level databases and caches where developers meticulously fine-tune performance for every last percentage point. However, Macleod’s observation offers reassurance: "The ones that work all work in the same way. The ones that don’t, all don’t work in different ways." This suggests that when issues do arise, they tend to be predictable and manageable.
Compute Classes: The Gateway to Axion and Beyond
Perhaps a more significant development underpinning the Axion narrative is the evolution of Kubernetes itself, particularly through features like GKE’s compute classes. This innovative feature empowers workloads to declare a prioritized list of virtual machine configurations. For instance, a workload might specify Axion as its first choice, with a fallback to a newer generation of x86 instances, and then to spot capacity as a final option. The GKE scheduler then intelligently resolves these preferences, abstracting away the underlying hardware complexities.
This mechanism transforms the decision to adopt Axion from a procurement challenge into a scheduling preference. A workload simply articulates its requirements, and the GKE control plane orchestrates the deployment to the most suitable available resource. Sghiouar noted the increasing sophistication of these configurations: "We have actually seen customers doing a compute class with eight, nine, ten priorities in the list. And during spikes, they can spike all the way up to the lowest priority virtual machine they want." This dynamic allocation capability ensures both cost optimization and the ability to scale seamlessly during periods of high demand.
The compute class paradigm extends beyond CPUs to encompass other critical resources, such as GPUs. The availability of accelerators has long been a bottleneck for many organizations. Compute classes, coupled with dynamic resource allocation (a newer Kubernetes API that treats accelerators similarly to storage classes for disks), enable workloads to declare their needs without being rigidly tied to specific hardware SKUs. This abstraction layer provides much-needed flexibility and simplifies resource management in complex cloud environments.
However, Macleod offered a pragmatic caveat: the effectiveness of these advanced scheduling features relies on a certain level of architectural maturity within an organization. Enterprises that still manage Kubernetes clusters with legacy VM fleet practices, including rigid firewall rules and the concept of "pet nodes" (nodes treated as unique individuals rather than disposable resources), might find the canary rollout pitch more challenging to implement. Google’s ongoing efforts with compute classes and enhanced scheduling primitives are precisely aimed at bridging this gap and fostering more modern, agile Kubernetes deployments.
The Looming Constraint: Energy Efficiency and "Tokens per Watt"
A consistent thread throughout the discussion was the growing importance of energy efficiency, a concern amplified by the insatiable demands of artificial intelligence workloads. Macleod’s prescient statement, "It’s essentially going to boil down to tokens per watt. And I think we will end up selling watts, not CPUs. We will be constrained by energy for the foreseeable future," encapsulates this critical shift. The exponential growth in AI model training and inference is placing unprecedented strain on data center power consumption.
For the Axion team, this focus on energy efficiency presents a strategic advantage. The cost savings realized by utilizing Axion processors, which are inherently more power-efficient than their x86 counterparts, can be directly reinvested. This allows organizations to allocate more budget towards compute resources, effectively enabling them to acquire more "tokens" of processing power within their existing energy constraints. This economic model is particularly attractive in an era where energy costs are rising and environmental sustainability is becoming a key consideration for businesses.
The implications of this "tokens per watt" paradigm are far-reaching. It suggests that the future of cloud computing infrastructure will be heavily influenced by the ability to deliver high computational output with minimal energy expenditure. Companies that can master this balance will be best positioned to scale their AI initiatives and other compute-intensive applications responsibly and economically. Google Cloud’s investment in Axion is a clear indication of their belief in this future, offering a solution that addresses both performance demands and the critical need for energy efficiency.
The broader impact of Axion’s successful integration into GKE is the democratization of Arm-based computing for mainstream enterprise workloads. What was once a niche architecture, primarily confined to mobile devices and embedded systems, is now a viable and often superior option for a wide array of cloud-native applications. The seamless integration with Kubernetes, coupled with features like compute classes, lowers the barrier to entry and empowers a greater number of organizations to harness the benefits of Arm’s performance and efficiency. This technological evolution is not just about hardware; it’s about redefining the economics and sustainability of cloud computing for years to come.