We are excited to announce the release of Slight v0.3, the latest version of our WebAssembly runtime that utilizes SpiderLightning (also known as wasi-cloud) capabilities.
This new release includes an array of new features, such as
HTTP client which allows you to make outbound requests to a URL, A new messaging capability that combines message queue and pub/sub capabilities into one, A SQL capability that allows you to query databases with SQL.
Read More…
Things are moving so fast that often I get asked to host a quick list of the recent things people can read or try for WebAssembly (wasm) outside of the browser, specifically about the WebAssembly System Interface (WASI) and WebAssembly components. Here’s some of the best links to various parts of things that did not work so well and those that do. I am leaving out some links that we’re not pursuing, but at the bottom in the appendix I’ll drop a few of those.
Read More…
At DeisLabs, we are researching and developing various WebAssembly tools and infrastructure. We have been working on a new project called SpiderLightning, which is a set of distributed application interfaces intended to provide developers in the WebAssembly ecosystem a way to develop applications easily and quickly. These interfaces are written in an Interface Definition Language (IDL) called WIT, part of the WebAssembly Component Model work. SpiderLightning is paired with a CLI called slight, which we recently released “0.
Read More…
A year ago, we announced Akri, a Kubernetes operator that discovers and exposes IoT devices to clusters. With hard work and community support, we were officially accepted into the Cloud Native Computing Foundation (CNCF) as a Sandbox project! This milestone marks an opportunity to look back at the motivation behind Akri and forward at what the future holds for Akri.
Why Akri? Akri came from a question on how to incorporate constrained devices into Kubernetes clusters, when they may not have enough compute to be Nodes themselves.
Read More…
The Deislabs team is really excited about WebAssembly. In fact, we’ve been experimenting and sharing our knowledge by developing new technologies in the WebAssembly space, such as Krustlet, WAGI, bindle, yo-wasm, and wasi-experimental-http.
While experimenting with these new technologies, it became clear that we need to make it easy for developers to deploy and test out their new ideas. Today, we’re thrilled to announce a new project. We call it Hippo, an Open Source self-hosted Platform as a Service (PaaS).
Read More…
Over a year ago, we introduced Krustlet, a kubelet implementation that enables users to run both WebAssembly and traditional container workloads in the same Kubernetes cluster. If WebAssembly is new to you, check out this section below.
We started the project with two clear goals in mind:
make it easy to deploy WebAssembly (and WASI) workloads on Kubernetes contribute to the cloud native ecosystem by building core architectural pieces of Kubernetes in Rust, a memory-safe systems programming langauge.
Read More…
WASI NN is a proposal that allows WebAssembly guest modules running outside the browser to perform neural network inferencing by using host-provided implementations that can leverage CPU multi-threading, host optimizations, or hardware devices such as GPUs or TPUs. This article explores the goals of WASI NN, existing implementations, and details a new experimental implementation targeting ONNX, the Open Neural Network Exchange, which allows the usage of models built with PyTorch or TensorFlow from guest WebAssembly modules.
Read More…
WAGI, the WebAssembly Gateway Interface, is a simple way of writing and executing HTTP response handlers as WebAssembly modules. We recently added new features to WAGI, such as pulling modules from OCI registries and outbound HTTP connections from guest modules, which opened the possibility of using Azure services from Wasm modules, and in this article we explore building and running such modules.
WAGI provides a very simple application model for building server-side HTTP response handlers using WebAssembly.
Read More…
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…
Cloud Native Application Bundles (CNAB) is one of the projects that DeisLabs works on. Together with Docker, DataDog, and others, we have been defining a specification for cloud-based package management. This is different than something like Helm, which is Kubernetes-specific. CNAB allows you to work with any public cloud or cloud service provider, as well as on-premises/edge systems to provision and configure resources.
The CNAB project defines the standards that CNAB implementations use.
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.
A stack overflow We started off excited to finally get Krustlet building for Windows.
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…