We’ve been seeing hundreds of users trying out the Fermyon Cloud, and we’ve been busy playing around with a variety of use cases ourselves. This blog post showcases using Spin and Fermyon Cloud to host a Slack bot.
Last month’s KubeCon/CloudNativeCon and Wasm Day events in Detroit, Michigan, were wildly successful. Our genuine belief that WebAssembly (Wasm) is the next wave of cloud computing drove us to officially introduce the open beta of the Fermyon Cloud on the first day we were there (during the keynote on Wasm Day). For your convenience, this article provides an overview of our conference talks, contains the official videos (embedded) and also offers valuable links to various resources on this topic.
Hello Fermyon Friends!
One year ago, eleven of us started our first day of work at a new job—and a new company. We each signed some paperwork, and then dove into our first project. Project One was both mundane and ambitious. The goal: Get our website up and running. The catch: It had to be running on our own WebAssembly-based technology. And not all of that technology had been created yet.
In a recent interview, David Flanagan sat down with Matt Butcher and Radu Matei to learn more about where Fermyon came from, what we’re trying to do, and why we’re passionate about WebAssembly.
In March of this year we introduced Spin, our tool for building WebAssembly applications for the cloud. We were pleasantly surprised at how quickly Spin gained your interest. Three days after its release, it had already garnered over 500 GitHub stars. A few weeks ago we passed 6,000 Spin installations. Today, we’re excited to release one of the earliest requested features: You can now deploy apps directly from Spin to our Fermyon Cloud platform. All it takes is a
spin deploy. (And yes, it’s free.)
This article is about implementing persistent storage in WebAssembly applications. More specifically, how Fermyon’s Spin framework provides a mechanism that allows WebAssembly executables to access different levels of on-disk persistence. WebAssembly is the next wave of cloud computing and persistent storage is arguably the cornerstone of any useful application, so let’s take a look at how we can implement both.
I am troubled by a few loud voices recently claiming that Platform as a Service (PaaS) is a failure. I am not bothered so much by the idea that PaaS might not have lived up to expectations. What frustrates me is that people are claiming this as if it were fact, but without evidence.
PaaS, it turns out, is not dead. We’ll look at a few ideas of what failure is, apply them to PaaS, and then evaluate whether PaaS has failed. The conclusion is resoundingly clear: PaaS is a highly successful endeavor, alive and well, and likely to be so for quite some time.
This blog post shows you how to install Fermyon’s Spin framework and quickly build applications from templates. Once you have Spin on your system you can build and run fast, secure, and composable microservices with WebAssembly. We hope to get you up and running with Spin in just a few minutes. Did you know Fermyon is attending the Open Source Summit Europe 2022, from the 13th to the 16th of September, in Dublin Ireland? We are in booth S5. We would love you to stop by to ask questions and share your experiences using Spin. Also please note, that you can scan your badge at our booth for your chance to win an Xbox Series X. Good luck, let’s get started.
.NET is a free, cross-platform, open source, developer platform for building applications. With over 5 million developers worldwide, it’s an established, proven technology with a wide audience. WebAssembly, a relatively newer technology, is rapidly progressing and offers many benefits including efficiency, safety and portability; which can translate into improved performance and potential cost savings. With WebAssembly for .NET developers, old meets new: developers familiar with a high-productivity platform gain the option of deploying to the low-overhead Wasm environment.
In this post, we introduce a new Spin SDK for .NET developers, run through how to build a Wasm application in C#, and peek a little behind the curtain into how the SDK is built. Read on to discover the intriguing synergy between WebAssembly and .NET.
Here at Fermyon, we are enthusiastic (to say the least) about WebAssembly. But we also value openness, thoughtfulness, and caution. Intellectual honesty is the practice of examining available evidence in a way that includes not just confirming information (see the Confirmation Bias), but also information that may run counter to the thesis. Following this practice helps us all see the potholes in the road before we run over them.
When it comes to WebAssembly, we at Fermyon are well-informed. Our own roadmap is informed by the risks of Wasm. We figured it was high time to get these things out in the open, and also talk about how we plan to mitigate these risks.
In this post, I cover the following risks:
- Slow-moving standards
- Language support
- Growth of the ecosystem and community
- Destructive technical fragmentation
While the risks certainly exist, there are clear ways to move beyond each risk. WebAssembly is no longer niche, and it’s no longer a browser-centric technology. But it is still up to us, the early ecosystem, to get it up to full velocity.
This blog post outlines a conversation, in an interview, where Matt Butcher walks through his experience of the evolution of cloud computing. The narrative is bountiful in knowledge thanks to Matt’s vast experiences and involvement with many open-source software products and projects over the years.
We will now be holding monthly community meetings, on an ongoing basis. These community meetings are primarily a Q&A; we will be spending most of the time answering questions from the community. These are excellent opportunities, for you, to watch live demonstrations and meet some of our team. The first in this new series (our September community meeting) has an exciting new SDK announcement so don’t miss out! Please read on for more information.
Repository templates allow you to generate your new repository with the same structure and files as the original. This blog post introduces you to the repository template for Fermyon’s Content Management System (CMS), Bartholomew. In this blog post, we show you how to build and run your own customizable CMS, quickly and easily.
Implementing rich results in a content management system will make your listings stand out from other listings for a given search engine’s results page (SERP). Not to be confused with rich media, rich results don’t just refer to organizing non-text content such as videos & images. Other text-based contents such as events, job listings and even COVID-19 announcements all qualify to use rich results (a structured data markup approach to content). Whilst rich results can make your content more visually appealing, implementing rich results can also help search engines to crawl and rank your content which may result in higher rankings.
The WebAssembly (Wasm) Content Management System (CMS) and Search Engine Optimization (SEO): A Short Story
Meet Charlie. Charlie is in the process of growing a thriving online business and is elated about the possibility of writing and publishing new content almost every day. Charlie already knows a little bit about tech i.e. the Linux, Apache, MySQL and PHP (LAMP) stack, but does not want to personally put a lot of time and effort into installing, configuring and maintaining servers, databases, security, networking and so forth. Charlie is aware of the concept of ever-changing technology. Specifically, how Virtual Machines (VMs), containers and cloud-computing services are ubiquitous nowadays. In a nutshell, Charlie needs the most frictionless Content Management System (CMS) with optimal Search Engine Optimization (SEO) compliance.
Earlier this year, Matt Butcher joined Robby and Tim on the Open Source Startup Podcast. The session begins with the story about why we started Fermyon and why we’re so enthusiastic about WebAssembly. From there the discussion delves into how to focus a startup’s energy when building a specific thing or things. And then we go on into the burgeoning WebAssembly ecosystem. Somehow, we veer into French post-structuralist philosophy as a way to understand ecosystems and community emergence in open source. Finally, we talk about company building and what it’s like to build a team.
We are building something new
Fermyon is pioneering the next-wave in cloud computing and harnessing the many benefits of WebAssembly. Join some of our amazing Fermyon team members at the Open Source Summit Europe 2022, from the 13th to the 16th of September, in Dublin Ireland.
Our very own Michelle Dhanani delivered a face-to-face presentation (Streamed live on Aug 1, 2022) at the devopsday conference event in Minneapolis, Minnesota. During her talk, Michelle shared Finicky Whiskers, a small game (that we designed at Fermyon) which gives a glimpse into what our vision of the future of WebAssembly in the cloud may look like.
At this year’s Open Source Summit NA, Fermyon released our open source platform, hosted our first booth, gave away hundreds of Finicky Whiskers t-shirts, and hosted a pizza party. Fermyon’s Matt Butcher delivered a keynote about Rethinking Microservices with WebAssembly.
Back when I was at Azure, we had a running joke that paying for cloud services is just “paying for someone else’s electricity at a markup.” If that’s the case, then it’s time to talk about the utility bill.
As a matter of routine business, we have gotten comfortable with overprovisioning our cloud services. We might be tempted to think that the best solution is to come up with a better way of right-sizing our provisioning. But the best solution might just be underprovisioning. That is, we might be able to cut a sizeable chunk off of our cloud expenses (without taking any risks) by allocating fewer resources to running our apps than our apps actually claim to need.
There have been some claims that WebAssembly is a replacement for Docker containers. While these two technologies do overlap a little, we at Fermyon don’t think about them as conflicting technologies. Rather, we believe they are complimentary. And this belief is not baseless. We actually use the technologies together in our own applications.
At DockerCon, Matt Butcher introduced Finicky Whiskers for the first time, and explained how our favorite persnickety pet is powered by Wasm and containers. (And check out this article from the Docker blog on WebAssembly, containers, and Spin.)
Radu Matei recently presented at Rust Linz. His talk, “Building Microservices with WebAssembly, Rust, and Spin” begins with an introduction to WebAssembly. Then Radu talks about the Wasm component model before he dives into using Spin to create a new application.
This August, NGINX Sprint happens entirely online. From the 23rd to the 25th, tune in a few hours a day to hear about the latest trends in open source, cloud native, and (of course) NGINX.
On the 23rd, Fermyon’s Matt Butcher will be joining Dave McAllister (F5), Robert Sirchia (SUSE), and Stephen Chin (JFrog) on a panel discussing the importance of an ecosystem. They’ll be chatting about the evolution of open source, the importance of foundations, and what upcoming ecosystems are exciting.
Registration for NGINX Sprint is free.
Today Fermyon jointly published an article with Cosmonic and Suborbital. Together, we articulate our vision for why WebAssembly is an excellent technology for a new generation of cloud development. We talk about the features of WebAssembly that made it such a compelling browser technology, and how those same features make it the perfect fit for compute workloads in the cloud.
To us at Fermyon, WebAssembly represents the next wave of cloud computing–a natural fit alongside virtual machines and containers. And our friends at Suborbital and Cosmonic agree. For this reason, we are happy to have the opportunity to jointly express this view.
Check out the article on Wasm.Builders: Why WebAssembly Belongs Outside the Browser.
Swift is a great language for creating Spin applications. This tutorial walks through the process of installing SwiftWasm, building a simple Wagi app, and then running it in Spin. The Swift community has been working on a WebAssembly compiler with full WASI support. And here at Fermyon, we’re big fans of this community-led project. We’ll show you how easy it is to work with Swift and Spin.
At this year’s HashiConf, we talked Finicky Whiskers, Nomad, and Spin. Our friends at HashiCorp also put together a MineCraft version of Finicky Whiskers, adding a fun new front end onto the world’s most adorable manual load generator. On June 20-22, HasiConf EU 2022 took place both virtually and in Amsterdam. Fermyon participated virtually. Several of us got up in the pre-dawn hours in the central US and had a coffee-fueled watch party. On Tuesday, Fermyon’s Matt Butcher gave a talk on the virtual track entitled “WebAssembly and Nomad for Next Wave Microservices.” You can watch the entire session here or on YouTube.
The WebAssembly Component Model is a proposal to build upon the core WebAssembly standard by defining how modules may be composed within an application or library. The repository where it is being developed includes an informal specification and related documents, but that level of detail can be a bit overwhelming at first glance.
In this article, we’ll begin by briefly explaining the motivation bethind the Component Model. From there, we’ll build an intuition for how it works, comparing it to how native code is linked and run on popular operating systems like Windows, macOS, and Linux. The intended audience is developers who are already familiar with natively compiled languages such as C, Rust, and Go, and with concepts such as dynamic linking and inter-process communication.
Last week we introduced the first preview of Fermyon, the frictionless platform for writing microservices and web applications with WebAssembly. Spin is a foundational piece of the platform, and we are excited to announce the new Spin release, v0.3.0.
Today we are excited to announce the preview release of Fermyon, the frictionless WebAssembly platform for writing microservices and web apps. To get you started, we’ve got an installer GitHub repo to provide a couple of ways to get Fermyon installed.
We’ve been talking for a long time about how WebAssembly enables the next wave of cloud computing. And we’d like to show you why. Finicky Whiskers, our DockerCon presentation, and our WasmDay talk about running a WebAssembly CMS have all covered various aspects of how we run multiple WebAssembly microservices in production (often alongside containers). Now you can install our platform on your own system.
For the last few months, we’ve been quietly at work assembling the tools necessary for you to install Fermyon into your own environment. And today, we’ve released an installable version along with a complete set of documentation. Let’s take a look at what is included with Fermyon.
One of the first efforts we undertook when starting Fermyon was setting for ourselves a core set of values. Values function for us as a critical component of company culture. We want our values to be meaningful virtues that we genuinely aspire to enact. This post talks about how we decided on our values, why we picked the ones we did, and how we use our values in day-to-day life.
Finicky Whiskers is a fast-paced game about feeding a picky kitty. It’s also the world’s most adorable manual load generator. It showcases how WebAssembly modules can be started, executed, and shut down in the blink of an eye. In a typical game of Finicky whiskers, where a player scores 100 points, 260+ WebAssembly modules are started, run, and terminated. Contrast that with current container technology, and you’ll quickly understand why we believe WebAssembly is critical for the next wave of cloud computing.
This is the fourth and final part of our Finicky Whiskers series. We started our series with an overview of the world’s most adorable manual load generator. Next, we looked at how Finicky Whiskers serves static files quickly and easily. From there, we dove into code, taking a look at the five microservices that drive Finicky Whiskers. In this post, we’re going to dive into the Finicky Whiskers infrastructure.
Webhooks provide a simple tool for integrating with services like GitHub, Trello, Slack, and Discord. The system is a simple way of linking a service event (a new issue being opened, a card being moved…) with an action on a remote URL. In this article, we’ll create a Spin application that uses webhooks to link two services together:
- Trello sends an event when a card is moved
- Spin accepts the event, and then sends a message to a Slack channel
- Slack receives and displays the message
We’ll be building a simple Spin app called “Bookhook” to track a reading list. Bookhook will receive a notification from Trello any time I change my reading list, and then will send a notification to Slack to keep my friends updated on what I am reading. In the process, we’ll see an example of an inbound webhook (where we write the listener) and an outbound webhook (where we call someone else’s endpoint). While we’ll be writing some simple Rust code, the principles are the same in any programming language.
Before diving into this tutorial, you may prefer to check out this short video that shows the code in action. Then read on for the details of how we built the “Bookhook” webhook application.
In the first part of this series, we introduced Finicky Whiskers, the world’s most adorable manual load generator. In this game, you must click as fast as you can to feed Slats the Cat whatever food that she currently desires. The problem is, she keeps changing her mind. Can you feed this fickle feline before the timer runs out?
In the second part, we looked at the Spin Fileserver microservice and got a better understanding for how the Spin Framework executes microservices. We also looked at how generic microservices like Spin Fileserver can be re-used within other applications.
For the third part, we now focus on a few of the microservices that manage the gameplay of Finicky Whiskers.
We recently introduced Finicky Whiskers. Finicky Whiskers is a browser-based game in which the player attempts to feed the fickle feline Slats the Cat. One moment Slats wants fish. A moment later, it’s chicken. She’s always changing her mind. Can you satisfy Slats’ hunger before the timer expires?
In this second installment in the series, we’ll look at one of the microservices that Finicky Whiskers uses. This microservice is not specific to Finicky Whiskers, though. We also use it on Fermyon.com and it powers part of Spin’s documentation site as well.
This microservice is the Spin Fileserver.
At this Year’s WasmDay, a co-located event that is part of CNCF’s KubeCon, Matt Butcher and Radu Matei dove into Bartholomew, the CMS that powers this website. They discuss why Fermyon decided to write a new CMS, how we use it, and how it runs on top of Spin.
Slats the cat is hungry. But the thing is, she can never decide on just one food. At one moment, she craves fish. A moment later, only fresh veggies will do. Then chicken alone can satisfy her discerning palette… nevermind. She’s back to fish. That is the premise behind Finicky Whiskers, Fermyon’s fast-paced game of feline fickleness.
But behind this adorable feline is an architecture designed to showcase why Fermyon is excited about WebAssembly as the next wave of cloud compute.
DigitalOcean is known for making it easy for developers to create and manage cloud computing. And we at Fermyon love them for it. We’ll start by creating a DigitalOcean Droplet. We’ll use VS Code to attach our development environment directly to the Droplet. Then we’ll install Spin and Rust. In a few more minutes, we’ll have a simple app coded up, compiled, and running on a public IP address.
HashiConf EU is both virtual and in-person in Amsterdam this June 20-22. Matt Butcher is presenting (virtually) on “WebAssembly and Nomad for Next Wave Microservices.” Finicky Whiskers will make its return, as we look at how the world’s most adorable manual load generator runs atop Nomad and Spin. See how we use service discovery, secret storage, and Nomad task drivers to run a huge number of next-wave microservices on a surprisingly small Nomad cluster.
Here is the description of Matt’s talk.
First came virtual machines. Then containers. Now WebAssembly is poised to be the next wave of cloud computing. With blazing fast speeds, tiny binaries, and security by default, Wasm is the foundation for a new generation of microservices. When we began building our open source Wasm platform, we chose to build it on Nomad, Consul, and Vault. Attendees will leave understanding WebAssembly, its potential on the cloud, and why Nomad is the ideal orchestrator for Wasm.
As always, we’re excited about HashiCorp’s amazing set of tools, and we’re proud to participate in HashiConf EU.
A year ago, Andreessen Horowitz (a16z) published one of my favorite articles on cloud. The Cost of Cloud: A Trillion Dollar Paradox tells a tale all too familiar for those of us who have lived the cloud revolution: Public cloud starts cheap, becomes merely “cost-effective,” then is tolerated because of its utility. And then one day you realize that cloud hosting is consuming massive amounts of your budget.
A16z has absolutely nailed their diagnosis: cloud cost can spiral out of control. But their primary proposal seems to be that the solution is to return from the cloud to the data centers of yore. We think that there is a better way, and we’re eagerly building part of the solution.
Join us in Austin, TX this June 21-24 at Open Source Summit where we will be hanging out, talking about WebAssembly, and giving away some awesome schwag. The Fermyon team will have a booth where you can come and discuss the next generation of microservices and get stickers and other goodies.
On top of this, you won’t want to miss Matt Butcher’s keynote session on “WebAssembly and the Next Generation of Microservices.” He will be talking about how Fermyon is leveraging cloud-side WebAssembly to address common developer problems. Here’s his abstract:
Microservices are serving us well in many ways. But in some ways, we can do better. Having learned a bit from Functions as a Service, containers, and now WebAssembly, we can rethink some of our assumptions and perhaps devise a better way for creating microservices.
In this session, Matt introduces cloud-side WebAssembly and shows how it addresses common developer problems. From maintainability of code to security to operational simplicity, WebAssembly is the technology that lets us build better microservices faster.
We’re looking forward to seeing you there!
A little over a month ago, we introduced Spin, a foundational piece of the Fermyon platform built on top of the WebAssembly component model for building web applications, microservices, and event-driven, function-based applications. Today, we are really excited to announce a new release of Spin, v0.2.0, which is packed with new features and improvements to the developer experience!
Since we first released Spin, it has been executing hundreds of thousands of WebAssembly instances in production powering fermyon.com and spin.fermyon.dev, made its first appearance in a conference talk demo (you have to try out Finicky Whiskers, the world’s most adorable manual load generator), and had its first external contributions from the community and public developer meeting. At Fermyon, we are really excited about the momentum of the Spin project and about all the ways we can make it easier for developers to build and deploy WebAssembly components at scale!
Let’s highlight some of the new features of Spin v0.2, starting with the new experience for creating an application.
With WebAssembly, small binary sizes are good. We at Fermyon like the idea of small microservices for the cloud, but even if you are building for the browser, shaving off a few kilobytes of data can speed up your app.
In this post, we cover a few ways to shrink down those Go binaries when compiling to WebAssembly with TinyGo.
Spin provides an extension that makes it simple to work with REST services. In this blog post, we’re going to show you how to make use of outbound HTTP calls to access external APIs using the
wasi-experimental-http crate in Rust.
Adding networking to WASI
At it’s core, WebAssembly relies on the idea of an isolated and sandboxed environment that is separate from the host environment. WASI expands upon this by providing a modular interface that enables a set of systems APIs specific to WebAssembly. There is currently a proposed networking API that is under consideration, but until it is agreed upon and implemented, WASI does not have the ability to open outbound network sockets.
The growing trend of server-side WebAssembly has a very bright future in the cloud-native ecosystem. Because of WebAssembly’s low footprint binary, organizations have the ability to deploy high-performance applications in a secure sandboxed environment with startup speeds that are 1000x that of traditional containers.
This May 16th, Matt Butcher and Radu Matei will be speaking at WasmDay EU in Valencia, Spain about “Why (and How) We Wrote a WebAssembly CMS”. In this exciting presentation, you’ll be introduced to the methodology behind Bartholomew, our blazing-fast CMS that compiles to WebAssembly.
Throughout the talk, Matt and Radu will discuss how the power of Wasm enables this cloud-side CMS to enable better performance, SEO optimization, and a low resource footprint while being easier to use than modern static site generators.
Here’s the abstract:
Our website, Fermyon.com, is powered by a cloud-side CMS written specifically to be compiled to WebAssembly. Bartholomew (our CMS) is blazingly fast, SEO-optimized, and consumes minimal system resources. It is easier to use than the popular static site generators and has all the benefits of a dynamic CMS. Best of all, it shows the promise of WebAssembly on the cloud side. In this talk, we share the design of this CMS and talk about how it’s running. We’ll talk about the limitations we encountered (and overcame) with WebAssembly, as well as our early performance and optimization work. Along the way, we will talk about why we chose HashiCorp Nomad as our clustering technology. And we’ll introduce Wagi (WebAssembly Gateway Interface), the HTTP engine that powers our CMS.
Outside of the presentation, Matt and Radu will also be around for the rest of KubeCon at the Krustlet and Helm booths in the Open Source Pavilion.
More details can be found here.
This May 10th, Matt Butcher will be virtually presenting “Containers and WebAssembly” at DockerCon 2022. In this interactive session, Matt will discuss how WebAssembly and containers have the potential to act in unison despite the common rhetoric that Wasm is trying to be a replacement for containers.
Here’s the abstract:
WebAssembly (Wasm) has generated buzz as the next cloud technology. But as frequently happens, rhetoric overstepped facts. WebAssembly is not the “Docker replacement.” We focus on Wasm’s promise, and where it fits into the cloud. We conclude with examples of Docker and Wasm complementing each other.
The presentation will be held at 11am PDT. Here is the DockerCon 2022 schedule.
It’s common to describe C# as an object-oriented language for big Microsoft shops. But nowadays that sells it short. C# has increasingly moved away from its conservative roots, thoughtfully bringing on features from functional and research languages, and gradually shedding ceremony to compete with leaner languages. Today, C# is estimated to be the fifth most popular programming language in the world.
C# targets the .NET runtime, a language-neutral execution environment that runs a low-level bytecode. Other .NET languages include F#, a functional-object hybrid with a vibrant open source and data science community, and Microsoft’s Visual Basic, a .NET dialect of an old enterprise favourite. Traditionally, the .NET runtime has been a native executable. But recently we’ve seen .NET starting to arrive on WebAssembly. And with it comes C# - and every other .NET language.
In this post, we’ll look at how to write and build a server-side WebAssembly app in C#.
Any new technology comes with a litany of new terminology. WebAssembly is no different. In this post, we take a look at how Wasm (short for WebAssembly), WASI (the WebAssembly System Interface) and Wagi (WebAssembly Gateway Interface) work together. The Fermyon Spin framework makes use of all three of these.
WebAssembly has been steadily gaining momentum over the last few years. It should come as no surprise that a batch of new programming languages are specifically targeting WebAssembly. In this article, we consider a few of those, including Grain and AssemblyScript.
AssemblyScript and Grain are both supported on the Fermyon Platform using Spin’s Wagi executor.
Small is beautiful. In this post we create a tiny Spin service using the TinyGo compiler for the Go programming language.
On could fill a library with the “Hello World” examples in circulation today. When I set out to write this post, I decided to base it on a production service instead of a contrived example. In this blog post, we’ll look at a server for
favicon.ico files. As simple as this little bit of code is, we actually run it at Fermyon.com, and have since the day we launched our website.
Bindle is a package repository system designed with WebAssembly in mind. Unlike “monolithic” package managers that focus on distributing large individual binaries, Bindle provides an intelligent system for distributing groups of related objects. As WebAssembly moves toward a component-based model, Bindle makes it possible for clients to pull only the pieces they need.
Or, to think of it in a completely different way, Bindle is the silverware drawer for WebAssembly.
The WebAssembly ecosystem is growing at a remarkable pace and even beginning to break free of its origins in the browser. Today, there are quite a few exciting Wasm projects making waves in the community with a varied range of use cases. From CMSs to low-resource runtimes for the edge, we’re going to explore a few of these tools in this post.
In an effort to better connect with the Fermyon community, we have created a Discord server where you can hang out with friends and talk about the next wave in cloud computing. If you’re unfamiliar with Discord, it is a real-time chat application that allows users to communicate via channel-based communities. Here’s a really good intro video:
As for our specific server, we offer a variety of different activities outside the general chat channel. At the moment, we have four channels related to Fermyon specific projects where you can ask questions and get support. In the future, we hope to add more channels and activities such as live streams, virtual meet and greets, and Q & A sessions with WebAssembly experts. Come join the fun today!
Cloud is expensive. One reason for this is that a typical application instance sits idly waiting for inbound requests. Yet even though it is idle, it is incurring cloud charges. What if there was a way to scale down your application when it was not being used? What if it could be scaled to the point where no instance were even running? This is the idea behind “scale-to-zero” designs. In the Kubernetes ecosystem, a number of projects attempted to implement scale-to-zero. When we built our WebAssembly project, we built it to scale to zero by default.
In the early stages of any technical innovation, projects are often heavily fragmented and lack a clearly defined body of standards that organizes proposals and navigates the larger discussion. In the growing WebAssembly world, a non-profit organization called the Bytecode Alliance is attempting to address this concern by providing a cross-industry standardization body for the Wasm ecosystem.
We are pleased to announce our new WebAssembly framework, Spin. Spin is a foundational piece of the Fermyon Platform. It is also a great way to get started writing WebAssembly for the cloud.
What is a WebAssembly Framework?
We think of WebAssembly primarily as a compile target. Pick a language, write your code, and compile it to Wasm. But what kinds of code does one write in WebAssembly?
The original way to run a WebAssembly module was in the browser. For that reason, early WebAssembly effort was focused on optimizing performance-intensive code to be executed on a web page or client-side web app.
WebAssembly has now moved beyond the browser. Some platforms, like the Envoy proxy, allow you to write plugins in Wasm. Command line runtimes like Wasmtime and WAMR run Wasm binaries on the command line, allowing developers to write a single CLI application that can run on Windows, macOS, and Linux (regardless of the underlying architecture).
Here at Fermyon, we are most excited about the prospect of writing microservices and server-side web applications in WebAssembly. We gave a preview of this when we built Wagi. But with Spin, we’re taking things to a new level. Most specifically, Spin offers a framework for building apps.
What do we mean when we talk about a “framework”? A framework provides a set of features and conventions that assist a developer in reaching their desired goal faster and with less work. Ruby on Rails and Python Django are two good examples.
Spin is a framework for web apps, microservices, and other server-like applications. It provides the interfaces for writing WebAssembly modules that can do things like answer HTTP requests. One unique thing about Spin is that it is a multi-language framework. Rust and Go both have robust support in Spin, but you can also write Python, Ruby, AssemblyScript, Grain, C/C++, and other languages.
We are excited to already be using Spin in production. The Spin docs are (appropriately enough) running on Spin. That website is powered by the Bartholomew CMS system and is running on an HA Nomad cluster.
Spin is a foundational new technology that sets the pace for what we at Fermyon are building.
Serverless is long overdue for a reckoning. For a few years, companies have waved the “serverless” banner. Serverless was supposed to be the next big thing. It promised freedom from one of the core concepts of computing: The server. But in big ways, the solution never fully materialized. Serverless held a great deal of promise. Only a small part of that promise was realized, though.
There are two reasons serverless did not seem to deliver.
- The concept of “serverless” was never clearly articulated
- The core technologies simply were not there
What serverless needed wasn’t bigger signs and more laptop stickers. It needed conceptual clarity. It needed grounding in a more adaptable compute layer. VMs and containers were not enough of a basis to build serverless. It needed a third wave of cloud compute. And this is why WebAssembly revives the ideas behind serverless and makes the vision not only compelling, but achievable.
Python is the second most popular programming language. Thanks to a few different efforts, it is now possible to compile the Python interpreter to WebAssembly. It is now possible to run Python inside of a WebAssembly runtime.
This post illustrates how to write a server-side WebAssembly app in Python.
The first question everyone asks us when we start talking about WebAssembly is “So, does this run in the browser?”
This is a logical question. After all, the name WebAssembly (abbreviated as Wasm) implies that it is a web technology, and the original purpose of WebAssembly was to serve as a runtime inside of web browsers. In fact, all major browsers already support executing WebAssembly inside.
But that’s not really how we at Fermyon are using WebAssembly. Our interest is in running cloud services that can accomplish a few special goals:
- Speed. We want very fast startup time. VMs take minutes. Containers take seconds. We want to start up our cloud-side apps in milliseconds… or even microseconds.
- Security. We want security by default. More specifically, we want to be able to run code in a cloud service without running a risk that the code can breakout of its sandbox and cause problems for other applications in that cloud service. This is a core feature of both VMs and containers. And we think any compute service needs it.
- Cross-platform. One of the things that has frustrated us about containers is that you need to build a version of your container for each operating system and architecture that you want to support. But we’d like a way to compile once, and have it run on Windows, Linux, Mac, or even other OS. And we also want it to run on Intel, ARM, or whatever other architecture.
- Language agnostic. We want all of this PLUS we want to allow developers to write their applications in whatever language they prefer.
Expect to see the rise of cloud native WASM in 2022
An invaluable part of any ecosystem is a community hub where newcomers can learn and regulars can stay up to date on the latest developments. That is why Fermyon joined forces with (in alphabetical order) Forem, Microsoft, Profian, Suborbital, and WasmCloud to create the Wasm.Builders WebAssembly community.
Wasm.Builders is a great source of tutorials, how-tos, developer news, and training. You’ll find guides on using different languages (C, Go, Rust, AssemblyScript) on topics ranging from browser-based WebAssembly to serverless, trusted computing, cloud, and security.
Stay up-to-date with the latest Wasm.Builders news by following @WasmBuilders on Twitter.
WebAssembly runs in a language virtual machine that is similar in many respects to the JVM (Java’s runtime) or the CLR (.NET’s runtime). But a key difference in WebAssembly’s architecture (built, as it was, for the browser) is that by default the runtime does not trust the code that it executes.
Late last year, a hack against a prominent open source Java library rocked the software world. A vulnerability in a logging system allowed attackers to execute arbitrary commands on the host. The recent Log4j attack provides an opportunity to talk about that characteristic and see why WebAssembly is resistant to this kind of attack. But I end with a warning that WebAssembly’s security model is only as good as its runtime security, and a troubling tendency to insecurely expose underlying host facilities to WebAssembly modules could undermine WebAssembly’s security model.
In the last few years, Docker Containers have been the most popular technology on the cloud side. Now, WebAssembly is arising as a new cloud technology. How does it compare to Docker Containers? Previously, we covered what WebAssembly is, and briefly touched on Docker. In this article, we explore the similarities and differences in more detail. We conclude that each has its place, but that WebAssembly opens some enticing possibilities.
Microservices are serving us well in many ways. But in some ways, we can do better. Having learned a bit from Functions as a Service, containers, and now WebAssembly, we can rethink some of our assumptions and perhaps devise a better way for creating microservices.
In our first blog post, we talked about how we envision a new iteration of microservices. Then we introduced our CMS system, which in many ways exemplifies our approach to microservices. Last week we answered the question, How should we think about WebAssembly?, discussing why WebAssembly is a promising cloud technology. Here, we spell out the problems with microservices v1, and pave the way for a microsevices v2.
All those things are, to some degree, sensible ways of looking at WebAssembly. However, it might help to take a bird’s eye view of the technology and understand its essential properties. And from there, these other assessments will begin to make sense. Once we’ve covered the essential characteristics of WebAssembly, we’ll circle back to Fermyon’s stance that WebAssembly is the enabling technology behind the next wave of cloud compute.
Earlier this week, demos began to circulate of LibreOffice (using the QT graphical toolkit) compiled to WebAssembly and running in the browser. This comes after Thorsten Behrens of Allotropia gave an interview announcing WebAssembly support in LibreOffice . The stories trended to the top of Hacker News. And this came hot on the heels of the Fosdem session explaining WebAssembly for LibreOffice. Why all the fuss?
Fermyon is proud to introduce our new lightweight WebAssembly (Wasm) content management system (CMS): Bartholomew. As we mentioned in our first blog post, the entire Fermyon.com website is served from WebAssembly modules. In this post, we talk about Bartholomew, our CMS system.
Bartholomew offers a feature set that should be familiar to users of popular static site generators like Hugo. However, Bartholomew is not a static site generator. Built into a lightweight WebAssembly module, it processes page requests individually on demand.
Hello World! We’re Fermyon Technologies, and we are building the third wave of cloud compute with WebAssembly.
Take a look at the cloud compute landscape. Virtual Machines (VMs) are the heavyweight contender, the first big entrants into the field. But cloud compute did not stop there. Along came containers. Those of us on board in the early days believed that containers would unseat VMs and become the way compute was done in the cloud. Happily, we were wrong and not wrong. Containers were wildly successful, but they did not replace VMs. In fact, VM consumption has gone up alongside container usage.
For several years, we worked on container technologies. As part of Deis, and then DeisLabs at Microsoft, we explored the container landscape. And we are proud of the things we built and the community with whom we built them: Helm, Brigade, the Kubernetes VS Code extension, Open Service Mesh, CNAB, and others. But along the journey we discovered some of the limitations of containers. And that got us asking a new question.
Along with VMs and containers, is there a third wave of cloud compute?
Justin Pflueger is a solution engineer for Fermyon Technologies. He is devoted to helping developers and businesses realize their ideas through the use of cutting-edge technologies like WebAssembly. Before Fermyon, he worked as part of the Commercial Software Engineering team at Microsoft, where he worked with Azure customers to design and implement customized solutions and contributed to open source projects like Azure Service Operator and Exposure Notifications Server. Outside of work, he is perpetually working on his golf swing and playing with his dogs. Justin currently resides in Fort Collins, CO.