12 posts tagged with "developer"

• Seamlessly operate WebAssembly across any K8s distribution via GitOps pipeline
• Orchestrate CNCF wasmCloud across K8s with Kubernetes Custom Resource Definition (CRD)
• Wadm supercharges Cosmonic Connect Kubernetes to create new Kubernetes controller

You've heard of the Grinch and the Cat in the Hat
But what about Wasm, did you hear about that?
Dive into this poem, take a quick look
The story of Wasm, in this neat little book

The Cosmonic wormhole exposes an HTTPS endpoint for your application that's accessible from outside of your constellation. Any actor with the HTTP Server capability can use a wormhole through Cosmonic's implementation of the HTTP Server provider. When you first create a wormhole, a randomly generated DNS name like fuzzy-lake-1234.cosmonic.app. These random DNS names are auto-generated; a couple of familiar words and numbers, designed to be unique but user-friendly, no long strings of random characters.

In our last post we built an deployed a service with Rust and deployed it to Cosmonic's free infrastructure. In this post we'll build a React frontend to interact with the service.

Earlier this year, alongside our friends at DevPost, we launched the Cosmonic Distributed WebAssembly Hackathon and encouraged you all to get creative with Wasm and the Cosmonic platform.

We asked you to take your ideas, whether something that would improve your daily work, something that could replace functionality in an existing application, or be the beginnings of a potential startup and implement them using WebAssembly, hosted on Cosmonic.

We saw hundreds turn out to build hacks, side hustles and creative ideas on Cosmonic, and to snag a share of our $4,500 prize pot -- and we weren't disappointed!

One of the many things that Cosmonic makes incredibly simple is building and deploying services. In this post, we'll show how easy it is to build a service from scratch, and how a service can shift from monolith to globally distributed function at runtime without rebuilding.

In our last post, we looked at some of the challenges inherent in running a highly distributed, microservices-centric infrastructure and how to overcome issues of networking and security in this novel environment.

In particular, we looked at some of the limitations Kubernetes has, especially at the edge, and why this was a key reason for selecting HashiCorp Nomad as our container orchestrator for WebAssembly and wasmCloud.

This post will outline the reasons why Nomad is an ideal container orchestrator for WebAssembly and wasmCloud, and how we created Netreap to run Cilium in our Nomad clusters alongside the rest of our infrastructure. In my next post, I'll walk you through how to run Cilium on a Nomad node, and how Netreap performs in practice.

At the Pasadena leg of Kubernetes Community Days (co-located with SCaLE 20x), I had the chance to talk to 100 or so Kubernetes enthusiasts, to give my perspective on WebAssembly, through the lens of a Kubernetes veteran.

There are several new standardization efforts happening within the WebAssembly (Wasm) space, including what we believe to be a new way to write software applications. By way of describing this new model, I would like to dive into some of the history of Wasm as a way to describe where we are heading.