Time is one of those things we all take for granted. Time marches on and does a dozen other things described by pithy sayings on T-shirts and motivational posters. When it comes to software, however, time is often our worst enemy. In this blog post, I talk about some patterns for dealing with the passage of time in event sourced applications.
Recently I had the opportunity to pick the brain of someone who has more experience and exposure to large scale, event-sourced systems than I do. We talked about event sourcing, specifically command processing, the subject of this blog post. It was an enlightening conversation that reminded me that insight is information tempered with experience. No amount of book reading is a substitute for learning from watching things go horribly wrong in production 😃.
One of the most formidable barriers in adopting and building event-sourced systems is learning to live with, and even embrace, the restrictions on component behavior. As it turns out, the same restrictions that make WebAssembly so powerful line up perfectly with event sourcing requirements.
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.
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.
An examination of how wasifills—a component adapter pattern like polyfills, but for
components—can help bridge the gap between today's rapidly changing standards landscape and the
future of interoperable components facilitated with
wit and wit
worlds. It's an amazing time to
be on the bleeding edge of the WebAssembly adoption curve, but it's not without risk.
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.
An engineer begins her Monday, sitting down at her desk with a cup of coffee. She's feeling productive, inspired, and ready to write some good code. She opens her GitHub inbox to find 42 notifications on her projects, like this one:
⚠️ CRITICAL VULNERABILITY: Upgrade
garbodep from 1.1.12 to 1.1.13
garbodep? I don't even directly depend on that, why am I getting notified for this?" And
so, her day begins.
Keep up to date
Subscribe to Cosmonic for occasional communication straight to your inbox.