In the rapidly evolving landscape of platform engineering, the shift from heavy virtual machines to containers was just the first step. Today, we are witnessing the next leap forward: WebAssembly (Wasm).
Cosmonic, built on the foundations of the CNCF incubating project wasmCloud, is leading the charge with Cosmonic Control. By integrating this with the vSphere Kubernetes Service (VKS) within VMware Cloud Foundation (VCF), enterprises can create a “Universal Golden Path” that blends the ironclad reliability of vSphere, the flexibility of Kubernetes, and the extreme efficiency of Wasm.
What is Cosmonic Control?
Cosmonic Control is an enterprise-grade control plane for wasmCloud. It allows developers to build applications as sandboxed WebAssembly binaries with explicitly enabled capabilities like HTTP or messaging.
Unlike containers, which package an entire OS user-space, Wasm components are platform-agnostic binaries that run in a tiny, secure sandbox.
Key Benefits
- Near-Instant Startup: Wasm components start in microseconds, eliminating the “cold start” problems common in serverless functions.
- Ultra-High Density: You can run thousands of Wasm components on the same hardware that might only support a dozen containers.
- Secure by Default: Wasm uses a “deny-by-default” capability model. A component cannot access the network, file system, or even the system clock unless explicitly granted permission at runtime.
- Extreme Portability: The same binary runs on your local laptop, a VMware VKS cluster, or a Raspberry Pi at the edge without recompilation.
Why Wasm + vSphere Kubernetes Service?
While many developers are familiar with running Kubernetes on vSphere, vSphere Kubernetes Service (VKS), lifecycle managing CNCF-certified Kubernetes clusters at scale, provides a unique, optimized environment for high-density workloads. According to Cosmonic’s platform engineering insights, traditional container scaling often leads to massive waste—sometimes up to 80% of spend on idle infrastructure.
By layering Cosmonic Control over VKS, you unlock:
- Hyper-Density on ESXi: VKS allows you to run Wasm components that start in microseconds. Because these components are platform-agnostic, you can pack thousands into a single VKS worker node, far exceeding traditional container limits.
- Scale-to-Zero without “Cold Starts”: Unlike Java or Python containers that take seconds to boot, Wasm components on VKS boot instantly. This allows platform engineers to scale workloads to zero when idle, saving massive compute costs without sacrificing performance.
- Decoupled Security: The Wasm component model separates application logic from common, reusable functionality like the HTTP service provider. On VKS, this means you can update a security patch for a database provider once and have it instantly apply to all running Wasm components across your vSphere clusters.
Use Cases: Cosmonic Control on VMware VCF
- Eliminating Cloud/On-Prem Waste: Use VCF as a high-density host for Wasm components to reduce the footprint of internal developer platforms.
- Polyglot Portability: Build components in any language that can compile to Wasm (C++, Rust, Go, Python, or JavaScript, etc.) and run the same binary on a vSphere cluster, an edge device, or a public cloud—no recompilation required.
- Resilient Distributed Systems: Leverage wasmCloud workloads to communicate across different VCF Workload Domains.
Installation: Deploying Cosmonic Control on VCF
To integrate Cosmonic with your VCF environment, you’ll utilize the vSphere Kubernetes Service (VKS). The following high-level steps outline how to bring Cosmonic Control to your VKS environment, as detailed in the vcf-cosmonic-control repository.
1. Prepare your VKS cluster
Ensure your cluster is equipped with the standard VKS Add-on repository and essential services such as cert-manager for secure communication and ingress using contour to manage external access routing required for Wasm workloads.
2. Deploy Cosmonic Control (Management Plane) via Helm
Cosmonic Control acts as the management plane for your Wasm workloads. Once the cluster is prepared, you deploy the core Cosmonic Control components via Helm.
3. Install Cosmonic Hostgroup (Runtime) via Helm
The Hostgroup is the set of resources that actually runs your WebAssembly (Wasm) workloads. It is installed via Helm after Cosmonic Control is deployed.
4. Configure Networking and Ingress
To access the Cosmonic UI and your Wasm workloads, you must configure Ingress resources:
● Console Ingress: Route traffic for the Cosmonic Console and Perses UI for an Open Telemetry dashboard, if desired.
● Wasm Workload Routing: Create additional ingress resources to route traffic to a Wasm workload by routing traffic from Contour to the Cosmonic Ingress service for xDS based routing.
5. Deploying WebAssembly Workloads
The Workload resource represents an application composed of one or more WebAssembly components and optional services. Workloads define the components, their configurations, volume mounts, and host interfaces they consume. WebAssembly workloads are deployed by creating an HTTPTrigger resource.
The Result: Maximum Resource Efficiency, Operational Simplicity, and Future-Proof Portability
Deploying Cosmonic Control on VKS represents a strategic convergence of enterprise-grade infrastructure and the next generation of cloud-native computing. By bringing Wasm into the VCF ecosystem, organizations can bridge the gap between traditional virtualization and ultra-high-density application execution.
Ready to start? Explore the Cosmonic and wasmCloud documentation or jump into the vcf-cosmonic-control GitHub for deep-dive technical examples.
Discover more from VMware Cloud Foundation (VCF) Blog
Subscribe to get the latest posts sent to your email.