Every engineer, vendor, tool (open-source or paid), and leadership team is always looking for one key thing - how to run workloads more efficiently. Maybe they’re looking for “easy” or “cross-architecture” or “get my pipeline to behave”.

In any case, everyone wants to run workloads more efficiently.

Wasm in general, but especially wasmCloud is a great step in that direction.

In this blog post, you’ll learn about what wasmCloud is and how to get started with Go (golang). However, if you’re using Rust or TypeScript, wasmCloud supports those languages as well.

What Is wasmCloud

Before diving into wasmCloud, let’s briefly talk about what Wasm is.

When thinking about Wasm, understand that the high level of is it’s a compilation target, much like a container. When you’re building a Dockerfile with your app stack, the container is the target. When you’re compiling an app stack into Wasm, the binary (the Wasm binary) is the target.

The great thing is with that Wasm binary, as long as a Wasm runtime exists on your target, you can use it across architectures, across programming languages, and because it’s smaller, it could be 20-160% faster than a standard container. There are also a lot of security best practices out of the box because its using Modules, Components, and WIT to specify exactly what the binary needs to run and nothing more.

If you’d like more info on Wasm, feel free to check out thisarticle.

Taking the benefits of Wasm, let’s tie that into wasmCloud.

The overall goal for wasmCloud is to build in one place and have the ability to run anywhere. The way that this occurs is by using transferable Components (created by a WIT file) and NATS (like a messaging bus specialized for microservices). With transferable/accessible Components, you can have a Wasm-based binary running in Azure and then transfer the traffic to the same Wasm-based binary running at the edge.

This leads us to a truly extendable, cross-architecture, multi-cloud scenario.

💡

I always talk about how networking is “sexy”, but it’s certainly the most important piece to any puzzle. Without proper networking, this wouldn’t be possible in the slightest.

Installation

Now that you know a bit about wasm, why you’d want to use wasmCloud, and the a few of the key benefits, let’s dive into the installation and configuration process.

💡

Keep in mind that this is a demo-based app. I have to create some content around taking an actual built app that isn’t a “hello world” and build a Component around it to showcase. That’ll be coming in the future.

First, you’ll want to install wasmCloud as that brings downwash, which is the CLI tool you’ll use to interact with wasmCloud.

💡

Despite the namecloud, just remember, this isn’t an actual cloud like Azure or AWS. It’s a portable method of using your compiled Wasm apps anywhere (in the cloud, on edge, k8s, etc.).

Because there are a few ways to do it, here’s how to install the CLI on Mac.

brewinstallwasmcloud/wasmcloud/wash

And here’s how on Linux.

curl-shttps://packagecloud.io/install/repositories/wasmcloud/core/script.deb.sh|sudobashsudoaptinstallwash

Other installations for different operating systems can be foundhere.

To test that wasmCloud is working, run the following:

wash--help

You should see an output similar to the below.

Now that wasmCloud is installed, let’s take a look at how to configure an app with it.

Configuration

For the overall configuration of a Wasm app running in wasmCloud, you’ll need a few tools and this will vary based on the language you’re using.

💡

The most support Wasm has right now is with Rust. Compiling an app for Wasm if it’s written in Rust feels significantly easier than in other languages, so if you seem to be having trouble with other languages, don’t worry, it’s not you.

Let’s talk a bit about this with a Kubernetes comparison. When you use Kubernetes, you have containers inside of Pods that run and scale. However, underneath the hood, Kubernetes doesn’t know how to run/start/stop containers. It doesn’t know how to “speak container”. That’s where plugins like the Container Runtime Interface (CRI) come into play. CRI is the “shim” between containers and Kubernetes. Now, thinking about it from a Wasm perspective, it’s the same thing. Wasm doesn’t know how to speak “this language” or “that library”. It’s a compilation target and because of that, it needs a “shim” of it’s own.

In the case of Go, that shim istinygo. Tinygo takes your Go code and compiles it down to targeted architecture that it may not be able to run on by default (like embedded systems). One of those compilation mechanisms is for Wasm. What Tinygo does is it transforms your code into code that Wasm can read because by default, Wasm is very low-level and doesn’t look at code in an abstracted sense like high-level programming languages. It’s a low-level Assembly language.

To install Tinygo, you can use Brew. If you’re not on a Mac,here are a few other installation options.

brewinstalltinygo-org/tools/tinygo

wasm-tools is for wasm Modules, where are like shared libraries. To use the Modules that are associated with wasmCloud, you’ll needwasm-tools. You can learn more aboutwasm-toolshere.

brewinstallwasm-tools

Now that all of the prerequisites are installed, you can deploy a demo template for Go. The good news about this template is you can use it for a starting point for production Go apps as well. You’ll just have to change the metadataTOML file and the Go code itself.

washnewcomponentnewGoApp--template-namehello-world-tinygo

Once you run the command above,cd into thenewGoDirectory.

cdnewGoApp

Thedev command below will run the Wasm app locally.

washdev

💡

wasmCloud useswasmtime, a popular Wasm runtime underneath the hood so you don’t have to worry about bringing down your own runtime.

You should now see the demo app running.

Congrats! You’ve successfully got a wasmCloud configuration up and running and learned a bit about why Wasm is important for the future of AppDev.