DEV Community: Ryan Levick

64 Cores on Fire: Supercharging My Development Experience

Ryan Levick — Wed, 08 May 2019 14:57:46 +0000

I recently started contributing to the Rust standard library to start fleshing out networking support for the WebAssembly system interface (WASI). The issue is that building rustc and its component parts like LLVM takes two and a half hours on my 2015 MacBook Pro.

If I was to be able to be productive, I needed a different solution!

Moar Cores!

The easiest answer when your machine isn't running something fast enough is to try throw more cores at it and see if it helps. Luckily a large part of building rustc is building llvm which massively speeds up when it has access to more cores.

So my co-worker, Duncan and I spun up a F64s_v2 virtual machine on Azure which has 64 total cores. The Fsv2 series of VMs on Azure are compute optimized making them the right VMs for the job.

With this machine, the build times went down dramatically to a total of around 17 minutes!

Wondering what would happen with less cores, we ran the same setup on a F32s_v2 with 32 cores and a F16s_v2 with 16 cores. These builds ran in 21 and 30 minutes respectively - not too bad!

Estimated Cost

Azure VMs are usually a bit cheaper in the U.S. so we hosted them there. I'm located in Europe, but in my experience latency isn't really an issue as the dev tools I use (ssh and VS Code remote extension) handle the latency fine.

The cost for the 64 core machine at the time of this writing $2.73 per hour, while the 32 core machine is $1.38 per hour and the 16 core machine is $0.71 per hour.

Given that the smaller machines are much cheaper, I opted for doing an initial build on a 32 core machine and then for incremental builds transferring the disk to a B8MS virtual machine. B8MS is an 8 core machine that is optimized for "burst" workloads (i.e. high CPU usage that happens every once in a while - like compiling). It only costs $0.36 per hour. Of course, you should still remember to shut down the machine when you're not using it.

You'll also have to pay for storage. Using a standard SSD with 64GB of RAM, only costs $5 per month.

If we put all this together, I estimate it costs around $2.00 for typical dev session of around 4 or 5 hours. Not too bad if it means I spend almost all that time coding instead of waiting for the thing to compile.

Dev Experience

Obviously getting a machine setup takes a bit of time, but with simple shell scripts using the Azure CLI, I now can easily reproduce the setup of both machines and the swapping the disk between them.

As for, writing actual code, I've been really enjoying VS Code's Remote Development Extensions. Most of the time I don't notice, I'm not working on my machine. I've had similar experiences as a vim user in the past, but this is next level, even making file transfer to the remote machine, super simple.

Hope this was an interesting look into remote dev on a big project like Rust. Let me know what you think by commenting below or reaching out on Twitter

Giving TodoMVC the API It Deserves: Part 1 - Todo Creation

Ryan Levick — Tue, 30 Apr 2019 15:35:50 +0000

Todo MVC is a great way to compare different JavaScript frameworks and get a feel for how to build an app that's slightly more complex than what can easily fit in a README.

In this series, we'll start where Todo MVC left off, and build a backend for the app that allows syncing your todos across devices. We'll take a look at the different possibilities inside one particular cloud provider, Azure, but the hope is that eventually others can add similar tutorials for other cloud providers.

Let's get started!

The Frontend

We'll start with a completed front end TodoMVC application. If you have a favorite framework already feel free to use the TodoMVC apps found on todomvc.com. We'll use a slightly trimmed down version of the Vue.js version for our example. You can find the code here. Feel free to clone the repo down and run the app locally following the instructions in the README.

If you're unfamiliar with Vue.js, you can learn more about it from the awesome resources on the official website. We won't need to modify the app too much to make it work with our API so don't worry if you've not used Vue before.

Creating an API

The very first thing we'll do is create an extremely simple API for creating todos. To keep things simple, we'll use the same language used in Todo MVC, JavaScript, for the backend. We have several options for how to build our API, all of which have their pros and cons. We could, for instance, use some framework like Express, run the app on a virtual machine (VM) that we have to manage ourselves. Or we could let Azure do a bit more work for us and run the API on Azure App Service which handles provisioning and even scaling our APP out when it sees lots of traffic.

But as we're just starting out, we want to keep things simple - the less work we have to do the better. For this reason we'll use Azure's Functions as a Service (FaaS) offering called Azure Functions. With Functions we can write code for handling an HTTP request and deploy it to the cloud without worrying about how many servers we want to run, if they have the right dependencies installed, etc. We just write the code and the service will make sure it runs properly.

FaaS is also commonly known as serverless, but this name is a bit misleading. There are still servers, we just don't have to worry about managing them; we just write code and the rest is taken care of for is.

We'll start by creating a function for creating todos.

Creating a Functions App

The first thing we'll need to do is to create a "Functions App". Various functions are always grouped together under an "app". At first, we'll have one function (one for creating a todo), but eventually we'll have many more. This allows for us group this functions into a logical group.

There's lots of ways to create an Azure Function app and to populate this app with various functions including from the Azure Portal, VS Code and the command line. I've written about this before, if you want to learn more.

My preferred way for creating an Azure Function is by using the Azure Functions command line tool (which we can easily install on macOS with brew brew tap azure/functions; brew install azure-functions-core-tools and on Windows with npm npm i -g azure-functions-core-tools --unsafe-perm true).

To create a new Azure Functions app run the following and choose node as the runtime and JavaScript as the language:

$ func init

And then create an Azure Function by running the following and choosing HTTP trigger and naming the function CreateTodo.

$ func new

We now have our function living in a CreateTodo directory. We can run it locally by running the following command:

# make sure you have an LTS version of node like node 10.15.3
func start

If you visit the http://localhost:7071/api/CreateTodo?name=World in your browser, you should see "Hello World".

Storage

Before we can start writing our function, we'll need to make a decision about where we want to store our data. Again, we want to choose something simple that allows us to efficiently read or write data without much fuss. While we could use a SQL database or some other more robust option, the best option for now would be a simple key/value store that allows us write data to it without having to define the structure beforehand.

For this, we'll be choosing Azure Table Storage which like other key/value stores (e.g., Redis) provides us with a simple way to write data that will be partitioned on some key allowing for efficient lookup. In the case of a todo app where each user has one list of todos, the most straightforward answer is to use an identifier for the user as the key. In our case, since we don't yet care about authentication, we'll just require the user to provide us an email address which we'll use as the key to partition the data. That way when we want to fetch all the user's todos, we just need to provide Table Storage with their email address and it will be able to fetch the todos extremely quickly.

Alright, enough talking, let's actually get this working.

Adding Table Storage Access to the Function

We first need to configure our function to be able to talk to Table Storage. This requires extending the Azure Functions runtime since it only supports HTTP request handling by default.

We can do this with the Azure Functions CLI tool. To set up the boiler plate around the extensions system run the following:

$ func extensions install

Among other things, this creates an extensions.csproj file. If you've never done dotnet development before, a csproj file is just a project definition file for a dotnet project written in xml. The functions runtime is written in dotnet, so it makes sense that in order to extend it we'll need to edit a csproj file.

In the extensions.csproj file we need to add the following line to the ItemGroup list:

<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.Storage" Version="3.0.4" />

This indicates we want to use the storage extension which allows us to use Table Storage among other types of storage services like blobs and files.

We need to run func extensions install again to install any dependencies for this particular extension.

Configuring Our Function to Use Table Storage

Ok, now that we can use the storage extension in our functions app, we need to configure our CreateTodo function to actually use table storage.

In the CreateTodo directory, there is the function.json file which is a configuration for this particular function. It should contain the following:

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    },
  ]
}

The bindings value lets our function know how its bound to the outside world. In this case, we're letting the function know it will be triggered by an http POST request we'll call req and it will return an http response we'll call res. Our function can be triggered by other things like timers and events, but this one is configured for http.

We need to add an additional binding for Table Storage. Add the following to the "bindings" array:

{
  "type": "table",
  "tableName": "Todos",
  "direction": "out",
  "name": "todosTable",
  "connection": "STORAGE_CONNECTION"
}

The type field indicates we're creating a binding for a table, tableName indicates we're interacting with a table named Todos (which we'll create soon), direction indicates we're writing out to the table and not reading in from it, name is the name we'll use to refer to our table in the function's code, and connection is the environment variable where we'll store our info on how to connect to our storage account like the account name and account key.

Talking to Table Storage

Now that we've configured our function to use table storage we need to actually use it. In the CreateTodo directory, there is an index.js file which contains the code for our Function. Replace its contents with the follow:

module.exports = async function (context, req) {
  // check for an email inside of the Authorization header
  const email = req.headers["authorization"]
  if (!req.body || !email) {
    // there was no body or no Authorization header
    // setting context.res will make our function return the specified response
    context.res = {
        status: 400,
        body: "missing body or authorization header"
    }
  }

  const todo = {
    id: generateId(),
    title: req.body.title
  }

  if (!validTodo(todo)) {
    context.res = {
      status: 400,
      body: "invalid todo"
    }
    return 
  }

  // the todo is valid
  // write to the todosTable
  context.bindings.todosTable = [{
    PartitionKey: email,
    RowKey: todo.id,
    title: todo.title
  }]

  context.res = {
    // the response is a 200 by default
    body: todo
  }
}

function validTodo(todo) {
  return todo && todo.title
}

// https://stackoverflow.com/questions/105034/create-guid-uuid-in-javascript
function generateId() {
  return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, c => {
    const r = Math.random() * 16 | 0
    const v = c == 'x' ? r : (r & 0x3 | 0x8)
    return v.toString(16)
  })
}

Functions require that we export an async function that takes two arguments: a context object that represents the context of our function and a req object that represents the current http request.

Our function simply checks that we have an Authorization header (which we access using all lowercase letters and that we assume is an email address) and a request body. If not, we return a http 400 response.

We then create a todo object with a generated id and a title passed to us in the request body. We then check to make sure that the todo is valid (by checking that title is truthy).

Once we know we have a valid todo we can set context.bindings.todosTable to an array of objects that will be stored in our table. Remember that we set todosTable to be the name of our table binding in the functions.json file.

The object we put in the array assigned to todosTable has three keys:

PartitionKey is how our table will be partitioned. Table Storage can do very fast lookups on partitions, so it makes sense for us to partition by email so that when we want to look up the todo by email, Table Storage can quickly return us all todos associated with that email.
RowKey is a unique identifier within a partition. We'll use the id we've generated. These ids are globally unique, which is even more unique than RowKeys need to be.
title is just the title of our todo. Table Storage requires us to provide PartitionKey and RowKey and we can add as many additional fields as we want. For now, we're just storing the title.

Creating our Table Storage

In order for us to successfully run this Function, we need to actually create an Azure Storage account so we can use Table Storage. To do this, we'll use the Azure CLI which you can install with the directions here.

First you'll need to make sure you're logged in to Azure which you can do by running az login.

Then we'll create a resource group where all of our Todo Cloud resources will live. Resource groups are just a way of grouping resources so you can handle them all together. Run the following:

az group create \
    --name TodoCloud \
    --location eastus

Feel free to choose a location that's closer to you. You can also see all locations by running az account list-locations --query "[].name".

Next we'll create the account:

$ az storage account create \
    --name todocloud \
    --resource-group TodoCloud \
    --location eastus \
    --sku Standard_LRS \
    --encryption blob

You can change --location to a location near to you. The rest is fine to leave the same.

We're getting so close! We now have a storage account, and we can create our Todos table using the following command:

$ az storage table create --account-name todocloud --name Todos

We now have everything in place for our function to work. The last thing we need is to make sure the STORAGE_CONNECTION environment variable we're using in our functions.json config file is properly populated. We can do this by setting it in the Values key found in the local.settings.json file of our Functions app. These values get automatically set as environment variables our Functions App can use.

In the Values array of your local.settings.json file add the following key and value:

"STORAGE_CONNECTION": "DefaultEndpointsProtocol=https;AccountName=todocloud;AccountKey=$SOME_LONG_KEY"

Make sure that you replace $SOME_LONG_KEY with a proper account key. You can find a storage account key with the following command:

$ az storage account keys list \
    --account-name todocloud \
    --resource-group TodoCloud
    --query "[0].value"

With this all in place we should now be able to run our Function App locally again with the following command:

$ func start

To create a todo we can just use cURL:

curl -XPOST http://localhost:7071/api/CreateTodo -d '{"title": "Buy milk"}' -i -H "Authorization: ryan.levick@example.com"

If you get a 200 back you can be sure that your todo has been stored in table storage.

You can use the Azure Storage Explorer app to view the data inside your table.

Change our TodoMVC app

In our client's code in app.js, we'll want to replace the addTodo method (which is what gets called when the user hits the enter key after typing a todo to create it).
Replace the existing body of addTodo with the following:

const value = this.newTodo && this.newTodo.trim()
if (!value) {
  return
}
fetch(API + "/CreateTodo", {
  headers: {
    'Accept': 'application/json',
    'Content-Type': 'application/json',
    "Authorization": "ryan.levick@example.com"
  },
  method: "POST",
  body: JSON.stringify({ title: value })
}).then(res => {
  if (res.status < 500) {
    this.todos.push({ id: this.todos.length + 1, title: value, completed: false })
    this.newTodo = ''
  }
})

This code is pretty naive and not the best user experience, but it does the trick. Just as before, we get the todo from this.newTodo and clean it up a bit. But not we make an http POST request to our the API we have running locally. If the response's status is less than 500, we do what we did before and save the todo to our local state and reset the newTodo input field.

If we open up the index.html file at the route of our client, and add a todo, we'll get a CORS error. To enable CORS calls for our app, we'll have to make one last change. We need to add the a Host key to the JSON object in the local.settings.json file with the value {"CORS": "*"}.

If we restart our locally running function, and try to create a todo, it should work.

Hooray! 🎉

Conclusion

We've done a lot in this post, we created an Azure Function and hooked it up with a newly created Table living in a Storage Account on Azure.

In the next post we'll create a "GetTodos" endpoint for fetching our todos, and we'll deploy our function to Azure so we don't need to run it locally.

I'd love to see others takes on how to create a backend for TodoMVC both on Azure and on other cloud providers. Feel free to contribute a PR to the repo, write a blog post about your experience or reach out to me on Twitter.

The Most Minimal Serverless Function

Ryan Levick — Thu, 18 Apr 2019 08:59:23 +0000

I've been having fun creating some APIs using Azure Functions. Functions as a Service (FaaS) is a category of 'serverless' products that allow me to write code and easily deploy it without having to worry about anything beyond whether the code itself works - provisioning servers, installing dependencies, and paying for idle servers are all a thing of the past.

Unfortunately, first getting started with Azure Functions wasn't as smooth as I would have hoped because I didn't fully grasp all the parts that make up the Azure Functions development flow.

In this post, we'll get a better understanding of how Azure Functions works by creating the simplest function we can by hand. We'll then discuss the various tools available to us that create this boilerplate for us so we don't have to. By the end, you should have a good idea of what's actually happening when you use these tools to help create Azure Functions.

Creating a Project

First thing we'll want to do is to create an Azure Function project on our local dev machine that contains all the functions for whatever project we're working on. This will have all the code for functions that we can check into source control and some configuration we can use for local testing of our functions.

At a minimum, a project simply has a host.json file which specifies which version of the runtime we want to use. This looks like this:

{ "version": "2.0" }

With this one file we have a working Azure Functions project! Of course, we have no functions, so it doesn't do too much. Let's create a function.

Creating a Function

Our function will be a node function. In the case of node, at a bare minimum we need to create a directory with whatever name we want for our function (e.g., "MyHttpFunction") that has a JavaScript file named index.js that has one exported function we'll look at below and a function.json file that describes the function.

To inform the functions runtime that we're expecting an incoming request and we want to provide an outgoing response we need to create a function.json describing these bindings (MyHttpFunction/function.json):

{
  "bindings": [
    {
      "type": "httpTrigger",
      "direction": "in",
      "authLevel": "anonymous",
      "methods": [ "get" ],
      "name": "req"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    }
  ]
}

The first object in our bindings array says we want this function to be triggered by an http request (specified by "type" being set to "httpTrigger"), it will require anonymous authorization (a.k.a no authorization), and it will only be triggered on http GET requests. We also have to provide a "name" although we could call it whatever we want since it we access it as a parameter to our function. By specifying the "direction" as "in" we're saying that this is an incoming http request that's triggering our function.

The second object says we want to create a binding of type "http" that we'll set in our function on a key named "res" on our context object. By specifying the "direction" as "out", we're saying our function will return or output an http response.

Next, let's create the JavaScript file MyHttpFunction/index.js:

module.exports = async function (context, req) { // req is the request that triggered this function
  context.res = { body: "Hello" } // we specified res as our response object in our bindings
}

This function will simply ignore the incoming request and set the body of the response to "Hello".

While we're using node in this case, Functions work with many other languages as well. For some other languages like C#, just the code file is enough since these languages use attributes in the code to specify the information - no directory or function.json file is needed. If we were to create a minimal C# function it would probably look like this:

using System;
using System.IO;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;

namespace MyFunctions
{
    public static class HttpTrigger
    {
        [FunctionName("MyHttpFunction")]
        public static async Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)] HttpRequest req,
            ILogger log)
        {
            return (ActionResult)new OkObjectResult("Hello");
        }
    }
}

We can test our functions locally by installing the Azure Functions CLI tool (which we can easily install on macOs with brew brew tap azure/functions; brew install azure-functions-core-tools and on Windows with npm npm i -g azure-functions-core-tools --unsafe-perm true) and running the following:

func host start

Function Apps

So now we have a project and a function inside of it. We can run this function locally, but obviously we'd like to deploy this to the cloud.

All functions in Azure are contained within Function Apps. Function Apps are a way to group different functions to together into logical groups. If you're creating an API for instance, you'll probably have one function per endpoint and group all of those functions into one Function App.

Function apps require you to make decisions about a few things:

Where will your functions live? The obvious choice here is to pick a place nearest to your users.
Which OS the function is running on? Because code you're writing for functions is generally cross platform and you're not having to manage the infrastructure yourself, it shouldn't matter too much which platform you choose. You can edit Windows functions but not Linux ones from the portal (which we'll discuss later), but this isn't a huge advantage.
Which hosting plan should we use?: consumption plan means you'll only pay for whatever you use. If you have a large spike in demand though, your app may temporarily slow down as the Azure automatically provisions more capacity for your function.
Which runtime stack will we run on?: This needs to match whatever language runtime you've developed your function against. In our case, we'll want to select node.

Creating a Function App

There are several ways to create an Azure Function App, but perhaps the simplest way for now to create one is to use the Azure Portal.

We can create an Azure Function App by clicking on the "Create a resource" button in the top right of the portal, searching for "Azure Function" and following the wizard.

Publishing our Functions

Once our Function App is created, it's waiting for us to publish functions to it. We can do this using the Azure CLI tool and the Azure Functions CLI tool we used to test our functions locally. You can do this by running:

az login # logs you into Azure
func azure functionapp publish $NAME_OF_THE_FUNCTION_APP_YOU_CREATED

It's important to realize that this tool replaces the contents of the Azure Functions App with the content of your local Functions project. If you've already deployed functions to that Functions App, those will be overwritten. But the first time we run this, it will simply replace the empty contents of the Functions App with the contents of our local project.

Once this is done, you will have a running Azure Function!

Reducing the Boiler Plate

While we were easily able to create very simple functions manually, there are tools that will help us with all these steps so that we don't have to write out all the boilerplate ourselves.

Creating an Azure Function Project

Using the Azure Functions CLI tool, we can run func init to initialize a project. This will take you through some questions about which language runtime (e.g. node, dotnet, etc.) you want to use, and eventually it will create the necessary files for a project like the host.json file we've already seen and some other files that help you customize the functions environment.

If you prefer Visual Studio Code, you can use the Azure Functions extension. With that installed, you can open the command palette (cmd/ctrl+shift+p) and search for "Azure Functions: Create New Project" to create a new project. This will also take you through a wizard experience for creating a function similar to what you will find with func init. This command also allows you to create the first function (but if you want you can choose Skip for now...).

Creating an Azure Function

Using the Azure Functions CLI tool, you can run func new to take you through a wizard process for creating a function. You just need to think about what kind of trigger for your function you want.

For Visual Studio Code users who have the Azure Functions extension, you can use the command palette (cmd/ctrl+shift+p), search for "Azure Functions: Create Function". This will take you through a wizard experience similar to the one from the func CLI tool.

Additionally, you can create a function from the Azure Portal from the Functions App screen (there's a big plus button next to the list of functions). An issue with this is that you won't have any local copy of your function that you can save in version control. You'll want to eventually download the functions app your function is a part of to your local machine so you can add it to your version control system. This typically requires merging functions that exist locally with the one that was just created on Azure which can be a real headache...

You can also make edits to running functions, but you'll need to repeat those changes in your local project if you want it to be reflected in version control. My recommendation is to try to avoid creating or editing functions from the portal.

Creating a Function App in Azure

If you have the Azure CLI tool installed, you can run az functionapp create along with the required options. Pro tip: you can use the Azure CLI tool from the portal by using the Cloud Shell feature which gives you a bash or powershell command line with the tool already installed.

From Visual Studio Code, using the command palette (cmd/ctrl+shift+p), you can search for "Azure Functions: Create Function App in Azure". This will take you through a Wizard experience similar to the Azure CLI experience.

Conclusion

Overall, it's important to remember that functions don't require very much setup to run. You'll need to make sure you've created an Functions App and the minimal pieces for a local project. Each function requires at most 2 small files to run.

By now you should have an understanding of at a minimum what is required to run an Azure Function and the many ways that you can create those pieces. If you want to keep going, I recommend checking out the MS Learn learning path on Functions! If you want to learn more, please feel free to reach out to me on Twitter!

The Promise of WebAssembly

Ryan Levick — Thu, 11 Apr 2019 08:25:06 +0000

WebAssembly (wasm) is a assembly binary format made for the web. Originally meant as a way to run native code in web browsers, wasm has recently expanded to be able to run outside of the browser.

In this post we'll take a closer look at what WebAssembly is and the related technologies around it, and we'll explore what this might mean for one particular use case - functions as a service (FaaS) a.k.a serverless.

Defining Terms

WebAssembly is assembly for a virtual machine. I mean 'virtual machine' here in the original sense - a conceptual machine - a machine that only theoretically exists. You can write code for that conceptual machine and a compiler can then compile it to assembly that runs on a real host machine.

The WebAssembly System Interface (WASI) is a specification that allows WebAssembly binaries to talk to the host machine's OS through a well-defined and cross platform interface. This allows WebAssembly binaries to do useful things like write files and open TCP sockets.

Fastly's Lucet, Mozilla's Wasmtime, and wasmer are all compilers that perform ahead-of-time (AOT) compilation through a library called Cranelift to turn the WebAssembly code into native assembly. Lucet and Wasmtime are also runtimes that implement the WASI specification allowing these binaries to talk to the host machine in a uniform, cross-platform way.

Advantages Over Existing Technologies

So what makes this different from existing technologies?

Sanboxing with Fine-grained Permissions

WebAssembly binaries are completely sandboxed, meaning that they only have access to the host machine's resources through WASI.

There are other systems that are also sandboxed at the application level - for instance, node through v8. The difference here is the level of control you have. On one side of the spectrum, v8 is completely sandboxed and does not offer a way to talk to host systems. Node is a way to open up v8 to allow it to take to the host system. Unfortunately, node completely opens up the host system to the application in an uncontrolled and unmanaged way.

WASI and the various runtimes allow for more fine-grained permission. For example, instead of allowing access to the host system's entire file system, a user can grant permissions to only a certain directory. Similar controls exist for networking and other system resources.

This provides a way to run programs where you can control exactly what resources the program is allowed to access.

Lightweight

In addition to this fine-grained sandboxing, the WebAssembly/WASI runtime is very lightweight in terms of overhead. Unlike Docker which also provides fine grained sandboxing, WebAssembly operates at the application level not the OS userland level. This means WebAssembly programs can be started much more quickly and will consume much less resources both on the host system and also when being transported over the wire.

What This Means For FaaS

A completely sandboxed and lightweight environment can allow for more tightly packing serverless applications on the same machine - allowing for serverless providers to lower costs. Additionally, startup times should be much lower (theoretically on the order of 1-2 ms).

Also, WebAssembly is meant to be completely language agnostic so in the future, you should be able to run whatever languages are capable of running in a WebAssembly environment, which could be every language.

This also makes local testing much easier as all the user needs to install is a WebAssembly runtime (a single binary).

What Next?

Hopefully this gives you a decent overview of what WebAssembly is about at least in the context of helping push FaaS forward.

If you enjoyed this article reach out to me on Twitter and let me know if you'd like me to write more about WebAssembly.