Fermyon Could Revolutionize Microservices

Newly launched Fermyon has created a PaaS for WebAssembly microservices, and I want to explain why it's very cool.

I had a briefing from co-founder and CEO Matt Butcher and I'm sold on the promise. Yet PaaS for WebAssembly microservices is a lot of jargon to pack into a single sentence. Unfortunately, there isn't really a simpler way to explain what Fermyon is. Not that I can think of yet, anyway.

To understand Fermyon and the ecosystem it's building you need to know a bit about a couple of different technologies. I'll walk through them and join the dots for you so you can hopefully see why I think Fermyon is important and why I think this will end up being big.

What is WebAssembly?

The definition is:

Think machine code but instead of compiling programs to run on Intel or ARM chips, they run on a virtual chip that lives in a browser. The benefit of using Wasm is that your program can run on any major browser, which is very handy.

But there are also servers, and browser-based programs aren't as much use on servers… or are they?

There's another thing that runs in basically every browser: Javascript. And if you take the Javascript execution engine from the browser and turn it into a thing that runs in a server as a process you get: Node.

Now all the programmers who build frontend webapps in Javascript can also write backend code in the same language they already know. Handy! That's why there's heaps of Node around the place.

But there are languages other than Javascript. Wild, huh? Some are scripting languages (like Perl, Python, Bash, and Powershell) and others compile to machine-code (like C, C++, C#, .Net, Go, Rust, etc., etc.). People have their favourites for various reasons. Having to learn Javascript to get your code to run in a browser is a pain, and if you already know Python or Rust you might prefer to use it for writing server code.

But what if you could write code in your preferred language and have it run in browsers and on servers? And not just run, but run fast and in a secure and isolated virtual machine environment?

What if we took a WebAssembly runtime and put it on a server, just like Node did for Javascript?

That would be Wasmtime. Fermyon has a project called Spin that makes it easier to build and run code on Wasmtime.

What if Powershell for Unix only Wasm

Fermyon's Spin project helps you compile and package your code into a deployable Wasm program. It could be a completely standalone monolithic program. Or, you could embrace the modern world of loosely-coupled modularity and build WebAssembly component.

These components can talk to each other using the WebAssembly component model. This means you can assemble a working application from a range of components, each of which could have been written in a different source language.

Imagine combining the power of Unix pipes with Powershell's object interface.

With Unix pipes, you can write programs (components) in any language you like and there's a standard way to communicate between different programs: lines of text. Each module can specialise in one thing, like uniq, cut, grep or even awk and you can send output from one to the input of any other. It's very flexible.

But plain text has its limits. Objects are better, because they combine data and metadata in a more readily accessible format. Changing the order of fields in csv formatted lines of text can break your code, but using things like jq to give you an object-like interface (via JSON encoding) gives you a hint of how much better things could be.

Powershell's object model lets Powershell scripts interact with the operating system, and each other, using a rich object-based interface. It's a lot easier to build complex programs using this approach, but the downside is that you have to learn and use Powershell to do it. You can't easily interact with a Powershell script from Python or Rust.

But if we compiled them to Wasm components, that would all change.

And that's what I see WebAssembly's component model turning into: a way to interface with other programs using a Powershell-like object interface, but the components could be written in any source language that can be compiled to WebAssembly. We'd get the power of chaining stuff together with Unix pipes but with a modern object interface so there'd be less cut -d ',' -f 2 | awk '{print $3}' shenanigans.

You could even have multiple components implementing the same API but with different source languages because developers have different preferences.

And these components run everywhere that runs WebAssembly, which is a lot of places. Browsers, servers, IoT devices, embedded systems, you name it! We might finally get close to the write once, run anywhere promise of Java!

Fermyon Makes It Easier

Back to the promise of Fermyon and why they've built a PaaS.

Fermyon's PaaS takes Spin and adds all the other modern code deployment things you need to ship code to production. Think the Continuous Deployment parts of a CI/CD process. Rather than building one yourself, Fermyon has one for you, ready to go, with a bunch of sensible defaults baked in so you don't have to worry about it.

Combining all this really new stuff into something that actually functions would be complex and hard. If you're trying to write applications, futzing about with all this low-level infrastructure stuff isn't really something you want to have to deal with, let alone support. Ferymon have already done it so you don't have to, basically.

Interestingly, Fermyon have chosen HashiCorp's Nomad as the workload scheduler and not Kubernetes. This is because Kubernetes is very much container-specific, while Nomad is a bit more generic and supports VMs, containers, and WebAssembly runtimes. You can run VMs, containers and Wasm services side-by-side instead of figuring out some way to get Kubernetes to talk to a Wasm environment and then look after the operations of both.

I reckon we'll see a bunch of other takes on the Wasm delivery side of things over time, and that Fermyon won't be the only option. This is a good thing, both for us and also for Fermyon, because it means there will be a much larger market overall. Fermyon can be a decent sized fish in a very large pond instead of a big fish in a tiny pond. And we get to see competition urging everyone to build better things to the benefit of all customers in the market.

It's still extremely early, even though I've been keeping an eye on WebAssembly for some time. I think Fermyon is onto a good thing here and I can hardly way to see what comes next.