Can You Maintain 1000 Apps? WasmCloud & K8s: The Ultimate Golden Template - Liam Randall, Cosmonic

Can You Maintain 1000 Apps? WasmCloud & K8s: The Ultimate Golden Template

Speakers: Liam Randall, Founder & CEO, Cosmonic

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=HrO5KVMQfHs

Overview

In this insightful KubeCon EU talk, Liam Randall, founder and CEO of Cosmonic and co-creator of CNCF WASMCloud, addresses a critical challenge facing modern platform engineering teams: the unsustainable burden of maintaining thousands of applications deployed on container orchestrators like Kubernetes. While containers and Kubernetes have revolutionized application deployment, they introduce inherent security, performance, and maintenance complexities that scale poorly, often leading to what Randall terms "the original sin of platform engineering."

Randall argues that despite advancements in container technology and serverless platforms like Knative and AWS Lambda, fundamental design flaws persist. These issues manifest as security vulnerabilities due to over-privileged containers, significant performance penalties from "cold starts," and inefficient resource utilization leading to high cloud costs. His talk proposes WebAssembly (Wasm) as a transformative, next-generation abstraction that fundamentally rethinks application deployment to overcome these limitations, offering a path to secure, high-density, and easily maintainable platforms.

The core of Randall's presentation centers on the platform harness pattern implemented within CNCF WASMCloud. This approach leverages WebAssembly's unique properties—including a capability-based security model, near-instantaneous cold start times, and extreme portability—to empower platform engineers to manage shared services centrally while providing developers with minimal, secure components for their business logic. By shifting the paradigm from patching individual applications to maintaining shared platform capabilities, Randall illustrates how organizations can achieve unprecedented operational efficiency and security at scale.

Background

▶ Watch: Introduction, speaker background, and talk agenda (0:00)

The journey of computing has been marked by a continuous quest for greater density, multi-tenancy, and cost efficiency. From mapping single applications to full computers, through virtual machines (VMs) for CPU sharing, to containers and Kubernetes for operating system and orchestration sharing, each "epic of tech" has sought to "platformize" infrastructure. However, despite these advancements, significant challenges remain, particularly with containers as the prevailing abstraction layer for modern applications.

Randall identifies several fundamental weaknesses inherent in container-based platforms:

1. Inherent Insecurity and Open-by-Default Nature: Containers, by design, often bundle an entire operating system, including a vast array of POSIX system calls and libraries. This leads to a violation of the principle of least privilege, exposing a wide attack surface. As demonstrated with a simple web shell embedded in various container images (Fedora, Ubuntu, Alpine, scratch), a compromised container can allow an attacker to download tools like the AWS CLI and potentially pivot laterally within an infrastructure, abusing credentials like STS. Even highly optimized, "from scratch" containers still carry more overhead than necessary for many functions.
2. The Cold Start Problem: Technologies like Knative and AWS Lambda, while offering serverless paradigms, still rely on containers underneath. When a function scales to zero, restarting its container incurs a "cold start" penalty. Randall demonstrates this with a Knative Node.js function, showing a first request taking 1.2 seconds, while subsequent requests are in milliseconds. Even with years of optimization, AWS struggles to get cold start times below a network request (around 30 seconds for containers). This problem forces organizations to keep containers running idle to meet SLAs and SLOs, significantly increasing cloud costs.
3. Low Density and Bloat: Containers often contain many megabytes or even gigabytes of unnecessary dependencies (e.g., 2GB Java images). This bloat limits the number of containers that can run efficiently on a single Kubernetes node, leading to lower density per system and higher infrastructure costs. Randall notes that running "hundreds of containers on a Kubernetes node" is considered "pretty good," highlighting the typical limitations.
4. Anchored in Place (Lack of True Portability): While containers are theoretically portable, in practice, applications become anchored to specific control planes and cloud-native services. A Java Spring Boot application, for instance, often integrates deeply with a specific Kafka instance, Kubernetes cluster, or proprietary cloud services, making true multi-cloud or edge portability challenging.
5. The "Original Sin of Platform Engineering": Perhaps the most painful problem for platform engineers, according to Randall, is the golden template anti-pattern. Platform teams create comprehensive templates (e.g., Java Spring Boot with messaging, Kafka, logging, secrets management, tracing) to help developers. However, once a developer copies this template, they become responsible for its maintenance. This leads to a world where "5,000 teams patch the same vulnerability one time," instead of "one team patching 5,000 vulnerabilities at once." The lack of compatibility across application frameworks, languages, and control planes exacerbates this issue.

These fundamental flaws necessitate a new abstraction layer that addresses security, performance, and maintainability from first principles.

Key Findings

▶ Watch: Audience poll and setting up container security demo (2:00)

Liam Randall presents WebAssembly (Wasm) as the foundational technology poised to resolve the inherent limitations of container-based platforms. Wasm represents the next evolutionary step in compute abstraction, moving beyond VMs and containers to offer a more secure, performant, and portable execution environment.

The key findings and contributions highlighted in the talk are:

1. Wasm as a Universal, Open Bytecode Target: Wasm is an open W3C standard, on par with HTML, CSS, and JavaScript, ensuring broad adoption and vendor neutrality. It functions as a tiny, stack-based virtual machine, similar in concept to Java bytecode but designed with modern security and performance principles. Its adoption is unprecedented, already boasting billions of users through its integration in browsers (V8/Chrome, Safari, SpiderMonkey/Firefox) and applications like Google Docs and Zoom background filters. Crucially, Wasm is now extending beyond the browser to server-side and edge environments with projects like CNCF WASMCloud.
2. Capability-Based Security (Least Privilege by Default): Unlike containers which are "open by default," Wasm modules start with zero privileges. Access to system resources (like file I/O, network sockets, or even standard input/output) must be explicitly granted through declared interfaces. This capability-based security model drastically reduces the attack surface, ensuring that a module only has access to precisely what it needs, preventing lateral movement in case of compromise.
3. Near-Zero Cold Starts and High Density: Wasm modules are incredibly small and efficient. Randall demonstrates user components as tiny as 7 kilobytes (KB), composing into a complete application of only 265 KB. This minute size enables near-instantaneous cold starts, often in nanoseconds, significantly faster than even optimized network requests. This eliminates the need to keep idle instances running, leading to dramatic cost savings and enabling unprecedented application density (e.g., 10,000 components running on a laptop using less than 1GB of memory).
4. True Portability via Component Model: The WebAssembly Component Model provides a standardized way to define inputs and outputs, making Wasm modules highly portable across different operating systems, CPU architectures, clouds, and edge environments. This is not just theoretical portability; it's facilitated by structured, versioned interfaces that allow for seamless integration and deployment without re-compilation or re-packaging for different environments.
5. Language Interoperability and Composability: Wasm enables true language interoperability. Strings in Rust and Go, for example, are "lifted and lowered" to be compatible, allowing components written in different languages to compose seamlessly. This share-nothing linking occurs within a single process, with cross-process accesses happening in nanoseconds, offering performance far superior to traditional microservices communication over network boundaries (even localhost).
6. The Platform Harness Pattern: The central architectural innovation is the platform harness pattern. Platform engineers build and maintain reusable, language-interoperable platform harnesses that encapsulate common enterprise services (e.g., key-value stores, authentication, secrets management, messaging, HTTP). Developers then write only their core business logic as tiny Wasm components, which plug into these harnesses. This allows platform teams to centrally manage and update vulnerabilities or swap underlying services (e.g., from HashiCorp Vault to AWS Secrets Manager) without developers needing to re-code or even be aware of the change. This directly addresses the "original sin," enabling "one team to patch 5,000 applications at once."

These findings collectively point to Wasm and WasmCloud as a paradigm shift for enterprise application development, offering a robust solution to the scaling and maintenance challenges of contemporary cloud-native architectures.

Technical Deep Dive

▶ Watch: Live hacking demo: demonstrating container least privilege vulnerability (2:30)

The technical foundation of Liam Randall's proposed solution lies in WebAssembly (Wasm) and the CNCF WASMCloud project, which implements the platform harness pattern. Wasm is a low-level bytecode format designed for high-performance execution in a secure, sandboxed environment. Its core technical differentiators include:

1. Bytecode Target and Virtual Machine: Wasm modules are compiled from various source languages (Rust, C, C++, Go, TinyGo, with Python and Java ports in progress by Oracle) into a compact binary format. These modules execute within a stack-based virtual machine (VM), similar to Java's JVM, but with a focus on minimal overhead and maximum security. The Wasm VM is embedded in runtimes like V8 (Chrome), SpiderMonkey (Firefox), Safari, and server-side runtimes like WASMCloud.

1. WebAssembly Component Model: This crucial standard defines how Wasm modules can declare their inputs and outputs, essentially acting as tiny, self-contained virtual machines with explicit interfaces. These interfaces are versioned, allowing for independent evolution and maintenance. The component model enables language interoperability by defining how data types (like strings or complex objects) are "lifted" into the Wasm host environment and "lowered" back into the guest Wasm module, ensuring seamless communication between components written in different languages.

1. Share-Nothing Linking and Nanosecond Composition: When multiple Wasm components are composed, they leverage share-nothing linking. Each component runs in its own isolated, stack-based VM. Communication between these components is interface-driven, much like connecting Lego blocks. Crucially, this composition happens within a single process, meaning cross-component calls occur in nanoseconds, orders of magnitude faster than inter-process communication or network-bound microservices calls, even on localhost. This allows for highly granular, performant composition of services.

1. Capability-Based Security: Wasm modules are inherently secure because they start with no capabilities. Access to external resources (e.g., file system, network, environment variables) must be explicitly granted via capabilities. For instance, a Wasm module might only be granted std_in and std_out access, completely preventing it from opening network sockets or accessing arbitrary files. This drastically reduces the blast radius of a compromised component and enforces least privilege by default, a stark contrast to the broad permissions often found in containers.

1. The Platform Harness Pattern (WASMCloud Implementation):

• Platform Harness: This is a Wasm component or a collection of components, maintained by platform engineers, that provides common infrastructure capabilities. These harnesses expose standardized, pluggable interfaces for services like:
• Key-Value Stores: Abstracting underlying storage (e.g., Redis, S3, a custom database).
• Authentication & Secrets: Integrating with systems like HashiCorp Vault, AWS Secrets Manager, or Kubernetes secrets.
• Messaging: Connecting to Kafka, SQS, or other message brokers.
• HTTP: Handling web requests.
• Tracing & Observability: Integrating with OpenTelemetry or other systems.
• Developer Components: Developers write only their specific business logic in their language of choice (Rust, Go, etc.). These components are small, focused Wasm modules that import the necessary interfaces from the platform harness. They do not contain any of the platform-specific "goo" or boilerplate code.
• Plaform Agnostic Pluggability: The genius of this approach is that the underlying implementation of a platform capability can be hot-swapped at the platform layer without impacting the developer's business logic. For example, a key-value interface could switch from an on-prem Broadcom system to an AWS-managed service, and the developer's component, which only interacts with the generic key-value interface, remains unchanged. This provides true portability across any cloud, edge, or Kubernetes environment.
• CNCF WASMCloud Host and Operator: WASMCloud hosts are executables that run Wasm components. They can be deployed in containers themselves, managed by Kubernetes operators and CRDs, making them compatible with existing GitOps workflows (e.g., Argo CD). This allows WasmCloud to integrate seamlessly into existing cloud-native infrastructures while providing the benefits of Wasm.

1. WYvert (Wasm Virtualization): For scenarios where a Wasm component does need access to a resource like a file system, but the platform wants to control or virtualize that access, WYvert (WebAssembly Virtualization) can be used. This technique allows an interface (e.g., file system pre-opens) to be intercepted and virtualized. Developers might interact with a local disk during development, but in production, their file system calls could be routed to an object storage service or a secure, sandboxed virtual file system, completely transparently to the component. This offers another layer of security and flexibility.

In essence, WASMCloud and the platform harness pattern transform platform engineering from an integration challenge to a composition challenge. By leveraging Wasm's intrinsic security, performance, and modularity, it provides a robust framework for building scalable, maintainable, and truly portable applications.

Demo / Proof of Concept

▶ Watch: Explaining fundamental container flaws: least privilege and unnecessary access (4:20)

Liam Randall's talk incorporated several live and conceptual demonstrations to illustrate the fundamental problems with current approaches and the solutions offered by WebAssembly and WASMCloud.

1. Container Insecurity (Web Shell Demo):

• Problem Demonstrated: The inherent insecurity and over-privileging of typical container images.
• How it Worked: Randall created a simple web shell and embedded it into various container images: Fedora, Ubuntu, Alpine, and even a "from scratch" container. He simulated a threat actor gaining access to this web shell.
• Exploitation: From the web shell, he demonstrated how an attacker could execute commands, such as downloading the AWS CLI to the compromised container. While not completing the full lateral exploitation, he explained how this could lead to probing infrastructure, abusing STS (Security Token Service), and pivoting to other systems, highlighting the dangers of providing unnecessary operating system access (like TCP/UDP sockets, file system access) when only a simple web function is intended. The example mirrored real-world vulnerabilities like Log4j, where legitimate code can be abused due to a broad attack surface.

1. Knative Cold Start Problem:

• Problem Demonstrated: The performance penalty and associated cost of "cold starts" in container-based serverless functions.
• How it Worked: Randall used Knative, a Kubernetes-native serverless platform, running a Node.js function that was scaled to zero.
• Observation: The very first request to the scaled-to-zero function took 1.2 seconds to respond as the underlying container had to be started. Subsequent requests, while the container was warm, responded in milliseconds (e.g., 1 millisecond).
• Implication: This illustrated that even highly optimized serverless platforms suffer from the fundamental limitation that containers take longer than a network request to start, forcing users to run idle instances to meet performance SLAs, thereby increasing cloud costs.

1. WASMCloud Interbank Transfer Rules Engine (Platform Harness Demo):

• Solution Demonstrated: The power of the platform harness pattern, Wasm's small size, high density, and capability-based security.
• How it Worked: Randall showcased a sample application designed as a rules engine for interbank transfers. This application separates core business logic (rules validation) from platform concerns (authentication, tracing, messaging, HTTP).
• Code Structure: The demo highlighted a developer's Go code for the business logic, which was remarkably small because it merely imported platform harnesses for capabilities like HTTP, messaging, and authentication.
• Component Size: A key part of the demo involved showing the compiled size of the Wasm components. The user component (business logic) was a mere 7 KB. When composed with the necessary platform harness, the entire application was still only 265 KB. This is significantly smaller than even a "from scratch" container for a comparable Go application, which would still be several megabytes.
• High Density: Randall stated that he could run 10,000 of these tiny Wasm components locally on his laptop, consuming "less than a gig of memory," demonstrating Wasm's extreme density.
• Capability-Based Rules: The demo showed a rule in action: a transaction for $100 in USD would succeed, but a transaction for $100 in Great British Pounds (GBP) would fail with "transaction failed validation unsupported currency," illustrating the application of business logic within a secure, isolated component.
• Multi-Cloud Deployment: The demo also briefly touched upon running WASMCloud clusters across different environments (AWS, on-prem, Akamai), leveraging Wasm's pluggability for multi-tenancy and portability.

1. Virtualized File System (WYvert) Demo (Conceptual):

• Solution Demonstrated: How Wasm's component model and virtualization capabilities can address complex security scenarios.
• How it Worked (Conceptually): Randall described a scenario where a developer's Wasm component needed file system access (e.g., for uploading and changing files). Instead of granting direct file system access, the platform could use WYvert to virtualize the file system pre-opens interface.
• Benefit: This means the developer's code remains unchanged, but during development, it might interact with a local disk, while in production, the "file system" operations are transparently redirected to a secure, platform-managed storage backend (like object storage), preventing unchecked file input vulnerabilities. This demonstrated the flexibility and control Wasm offers at the interface level.

These demonstrations effectively showcased the practical advantages of adopting Wasm and WASMCloud, addressing core pain points in security, performance, and maintainability.

Defensive Implications

▶ Watch: Historical tech evolution: platformization, multi-tenancy, and cost saving (6:00)

The adoption of WebAssembly (Wasm) and the CNCF WASMCloud platform harness pattern presents profound defensive implications for platform engineers, fundamentally altering how security, performance, and operational overhead are managed in cloud-native environments.

1. Enhanced Security through Least Privilege and Reduced Attack Surface:

• Capability-Based Security: Wasm modules are secure by default, starting with zero privileges. Access to system resources (file system, network sockets, environment variables) must be explicitly granted as capabilities. This enforces the principle of least privilege at a granular level, far beyond what traditional containers offer. If a Wasm component only needs std_in and std_out, it will not have access to network or file system calls, severely limiting the blast radius of any compromise.
• Minimal Attack Surface: Wasm components are incredibly small (e.g., 7KB for business logic, 265KB combined), containing only the necessary functions. This eliminates the vast majority of operating system dependencies, libraries, and system calls typically bundled in container images (even "from scratch" ones). A smaller codebase and fewer dependencies mean a significantly reduced attack surface, making it harder for attackers to find and exploit vulnerabilities.
• No POSIX by Default: Unlike containers that expose a full POSIX-like environment, Wasm defaults to a much more restricted set of interfaces. This inherently prevents many common container exploits that rely on broad system call access.

1. Improved Performance and Cost Efficiency:

• Zero Cold Starts: Wasm's near-instantaneous cold start times (nanoseconds) eliminate the need to keep idle application instances running to meet performance SLAs. This directly translates to substantial cost savings in cloud environments, as resources are only consumed when actively processing requests.
• High Density: The extremely small footprint of Wasm modules allows for unprecedented application density on a single host or Kubernetes node. Running thousands of components on minimal hardware reduces infrastructure costs and optimizes resource utilization, contrasting sharply with the bloat and low density of many containerized applications.

1. Streamlined Maintenance and Vulnerability Management:

• Centralized Platform Harnesses: The platform harness pattern allows platform engineers to encapsulate common, potentially vulnerable, infrastructure components (like HTTP handlers, messaging integrations, secrets management) within centrally managed Wasm harnesses.
• "One Team Fixes 5,000 Apps": When a vulnerability (e.g., a new CVE in a messaging library) is discovered in a shared platform capability, the platform team can update and deploy a new version of the harness. All developer applications leveraging that harness automatically inherit the fix without requiring individual teams to re-code, re-test, or re-deploy their business logic. This eliminates the "original sin" of distributed, redundant patching efforts.
• Plaform-Agnostic Pluggability: The ability to hot-swap underlying service implementations (e.g., changing from HashiCorp Vault to AWS Secrets Manager for secrets) without impacting developer components means security best practices can be evolved and enforced at the platform level, ensuring consistent security posture across all applications.
• Versioned Interfaces: The use of versioned interfaces within the WebAssembly Component Model allows for controlled evolution and backward compatibility, simplifying upgrades and reducing the risk of introducing regressions during security updates.

1. Enhanced Portability and Future-Proofing:

• True Cloud and Edge Portability: Wasm's design ensures genuine portability across different clouds, edge devices, and even on-premise infrastructure. This reduces vendor lock-in and allows organizations to deploy applications closer to data or users for performance, compliance (e.g., GDPR data locality), or cost reasons, all while maintaining a consistent security posture through the platform harness.
• Virtualization for Sensitive Operations (WYvert): Techniques like WYvert allow platform engineers to virtualize sensitive resource access (e.g., file systems). This means even if a developer component requests file access, the platform can intercept and redirect it to a secure, controlled backend (e.g., object storage), preventing direct access to the host's file system and mitigating risks like unchecked file inputs.

In summary, Wasm and WASMCloud offer a paradigm shift towards a more secure-by-design, performant, and maintainable application ecosystem. By embracing least privilege, minimizing attack surface, and centralizing platform concerns, organizations can significantly strengthen their defensive posture and reduce operational burden.

Key Takeaways

• Containers have fundamental design flaws: Despite their utility, containers suffer from inherent insecurity (open by default, broad attack surface), the cold start problem (leading to high idle costs), low density, and practical lack of true portability, culminating in the "original sin of platform engineering" where many teams patch the same vulnerabilities.
• WebAssembly (Wasm) is the next computing epoch: Wasm is an open W3C standard, offering a secure, high-performance bytecode target that enables capability-based security (least privilege by default), near-zero cold starts, and extreme density.
• The platform harness pattern centralizes security and maintenance: CNCF WASMCloud implements this pattern, allowing platform engineers to manage shared infrastructure capabilities (e.g., secrets, messaging, HTTP) in reusable, language-interoperable Wasm harnesses, while developers focus solely on business logic.
• Achieve "one team patches 5,000 apps": By abstracting platform concerns into centrally maintained, versioned harnesses, organizations can fix vulnerabilities or update services across thousands of applications simultaneously, drastically reducing operational overhead and improving security posture.
• True portability and pluggability: Wasm components, combined with WASMCloud's pluggable interfaces, enable applications to run seamlessly across any cloud, edge, or Kubernetes environment, allowing for hot-swapping backend services without developer intervention.
• Significant cost savings and performance gains: Wasm's tiny footprint (e.g., 7KB user code, 265KB combined) and nanosecond cold starts lead to unprecedented application density and eliminate the need for costly idle infrastructure, offering substantial financial and performance benefits.

About the Speaker(s)

Liam Randall is a distinguished figure in the open-source and cloud-native communities, currently serving as the Founder and CEO of Cosmonic, a company dedicated to enterprise WebAssembly solutions. He is also a co-creator of CNCF WASMCloud, an incubating project within the Cloud Native Computing Foundation that aims to bring WebAssembly to the server and edge.

Randall has a rich history in building and innovating within the technology sector. He was formerly the VP of Innovation at Capital One, where he gained firsthand experience with the challenges of managing large-scale enterprise platforms. His entrepreneurial spirit is evident in his past achievements; he built the very first Kubernetes company in 2014, which was subsequently acquired by Capital One. Prior to that, he was involved with CoreOS, a company built on Project Atomic (often referred to as 'Broique' in the talk), which achieved unicorn status. Beyond his direct company building, Randall is an active investor in numerous open-source companies, including those built around OSQuery and Cloud Custodian. He identifies as incredibly passionate about open source and enjoys long-distance swimming, wine-making, and spending time with his three children in Washington D.C.