A few months ago, our team introduced WAGI, or the WebAssembly Gateway Interface, a simple way of writing and executing HTTP response handlers as WebAssembly modules. Since we open sourced the project, the community has been adding critical features that make WAGI one of the easiest ways to build WebAssembly microservices, and in this article we explore some of the new features.
A primer on WAGI WAGI is for writing HTTP handlers.
Read More…
We at DeisLabs have long been excited about the prospects of WebAssembly for cloud native development. Today, the Bytecode Alliance (BCA) has officially launched as a foundation (with Microsoft as a founding member). And they are inviting you to join the foundation!
WebAssembly has much to offer to the cloud native world. It is highly portable. Binaries are small in size. It focuses on security. And the list of programming languages that compile to WebAssembly is growing by the day.
Read More…
Over the last year, our team has been experimenting with executing WebAssembly workloads on the server using the WebAssembly System Interface and Wasmtime. While more and more proposals get implemented, networking is one scenario that doesn’t have a stable API yet. This limits current applications compiled to WASI, and restricts the types of workloads that can be executed in WASI runtimes.
Today we are releasing a library which adds support for outgoing HTTP requests for WASI modules running in Wasmtime.
Read More…
Announcing Krator Last September the Krustlet project refactored our API to employ a state machine pattern for describing the lifecycle of Pods. The design of this API was covered in depth in my previous blog post. Since then we have made a number of refinements to this interface and extended our use of the pattern to individual containers within each Pod. These changes also served to simplify and make more generic our API, and were done in part as a stepping stone to the crate we are announcing today.
Read More…
DeisLabs has been experimenting with a variety of WebAssembly tools over the last few months. While it might not appear so at first glance, Bindle is another piece of our WebAssembly research. We were excited to discover applications in addition to WebAssembly.
And what is this Bindle thing? It is an aggregate object storage system. This article explains what we’re trying to do, how it works, and why we’re building it.
Read More…
It has been about a year since the DeisLabs team starting using Rust in a “serious” project. About this time last year, we started work on what became the Krustlet project. Since then, we have been using Rust extensively across our projects and have learned a ton more about the language’s strengths and weaknesses. As “Rust After the Honeymoon” posts currently seem to be all the rage, we thought we could contribute a little to the discussion with our experiences writing applications for the cloud world.
Read More…
WebAssembly (Wasm) is a portable standard for bytecode, allowing code to be compiled to an efficient representation that’s amenable to just-in-time optimisation, and to be run on the operating system and runtime environment of your choice. An ever-increasing number of languages offer compilation to Wasm, and Wasm runtimes are available in major browsers and as separate programs. The existence of runtimes outside the browser, such as wasmtime and waSCC, opens up the possibility of using WASM as a general-purpose bytecode format, similar to Java bytecode or .
Read More…
Over the last few months, our team has been experimenting with executing WebAssembly modules in various environments, and we released projects such as Krustlet (for executing Wasm modules in Kubernetes), and WAGI (for writing HTTP response handlers in WebAssembly). But while most of our experiments are built in Rust, we are also exploring ways to execute WebAssembly workloads in other environments, such as JavaScript runtimes.
Today, we are releasing a small experimental JavaScript library to help with instantiating WebAssembly modules by providing functionality to link JavaScript objects as module imports, and automatically perform name based resolution for linking entire modules and instances.
Read More…
A few months ago we released Krustlet, a Kubernetes Kubelet that executes WebAssembly payloads instead of Docker containers
Today, we are open sourcing another experimental WebAssembly effort: the WebAssembly Gateway Interface (WAGI). Pronounced “waggy” (and inspired by some of the puppies on our team), WAGI is the easiest way to build WebAssembly microservices.
WAGI is for writing HTTP response handlers. It uses the WASI POSIX-like system to expose an HTTP request to a WebAssembly module.
Read More…
Earlier this year, DeisLabs released Krustlet, a project to implement Kubelet in Rust. 1 2 Kubelet is the component of Kubernetes that runs on each node which is assigned Pods by the control plane and runs them on its node. Krustlet defines a flexible API in the kubelet crate, which allows developers to build Kubelets to run new types of workloads. The project includes two such examples, which can run Web Assembly workloads on WASI or waSCC runtimes.
Read More…
We recently landed support for Windows in Krustlet. Although the final PR was relatively small, there was a lot of learning behind it. While adding this support, we came across an oddity that forced us to learn a whole bunch about stack vs heap allocation in Rust and figured it would be good to share with the world. As with most learning opportunities, this one starts with a story.
Read More…
We are excited to announce the first release of a Docker mixin for Porter! 🐳
Mixins are critical building blocks for bundles, and we hope the Docker mixin will help ease the process of composing bundles. The Docker mixin installs Docker and provides the Docker CLI within bundles. Prior to the creation of this mixin, in order to use Docker within your bundle, you would have to create a custom Dockerfile and install Docker.
Read More…
Sometimes you need a hammer, and that hammer happens to be a whale 🐳. We all use containers as part of our pipeline: building images, running a one-off command in a utility container, spinning up a test environment to verify your application, or even more creative tasks that you have already containerized. Well now you can reuse all that hard work and logic from within your bundles!
Let’s walk through using my favorite container, docker/whalesay, in a bundle.
Read More…
A few days ago, we introduced Krustlet, a WebAssembly focused Kubelet implementation in Rust. If you are not familiar with Rust, it is a systems programming language focused on safety, speed, and security. We chose to use Rust for two main reasons: 1) Rust has some of the best support for WebAssembly compilation (more on this later) and 2) We wanted to demonstrate Rust and its strengths could be applied to the Kubernetes ecosystem.
Read More…
Hi everyone, hope you’re having a great day today.
At DeisLabs, our goal is to build open-source tools for cloud native developers. We developed a tool that we think Kubernetes users will enjoy, and the WebAssembly community will be thrilled to hear about.
Today, we’re excited to announce this new project’s first release: v0.1.0.
We call it Krustlet, a Kubernetes-rust-kubelet.
Goals of the project We built Krustlet to help prove out two things:
Read More…
Two of Porter’s great strengths lie in composability and extensibility. Mixins represent the building blocks for composing a bundle, offering functionality that can be utilized during the runtime of a bundle, and Plugins represent swappable backend storage solutions, enabling distributed, Day 2 bundle instance management. (Be sure to read Carolyn Van Slyck’s recent post around Plugins and Collaboration.)
The default installation of Porter includes a handful of useful mixins, including:
Read More…
One tenet of working on a great team, is that no one deploys alone. I may have originally deployed our application, but that doesn’t mean that I am responsible for patching it until the end of time, or until I run away screaming. I am excited to announce that Porter now fully supports teams managing a bundle collaboratively! 🙌
🔷 Sally deploys the application on Tuesday using secrets stored in the team’s Key Vault.
Read More…
Introduction In the previous entry, we discussed the CNAB Core specification, which does not dictate how bundles should be distributed. This is intentional, so organizations that need the bundle representation CNAB brings, but already have a way of distributing artifacts may continue to use it.
That being said, the CNAB Registries specification wants to propose a standard way of using OCI registries to distribute bundles, which we will explore in this article.
Read More…
What is CNAB? Late last year, the CNAB (Cloud Native Application Bundles) specification was announced - the news made it to TechCrunch and other tech publications, and partner organizations wrote about how they’re using CNAB (for example Docker, Pivotal, or Bitnami).
So what is CNAB? According to the official specification:
CNAB is a standard packaging format for multi-component distributed applications. It is not a platform-specific tool, and developers can bundle applications targeting environments spanning IaaS (like OpenStack or Azure), container orchestrators (like Kubernetes or Nomad), container runtimes (like local Docker or ACI), and cloud platform services (like object storage or Database as a Service).
Read More…
Deis Labs is a shoutout to Deis, the organization where many of us started our journey into Kubernetes and Open Source - creating and nuturing the Helm project and working to simplify the tooling around Container Native development and operations.
Over the past year and a half, we have been busy continuing that same mission; bolstered by new colleagues and resources within the Cloud Native Compute Team of Microsoft Azure. You may be familiar with some of our work:
Read More…