A Look Back at 2023, and a Look Forward to 2024
Matt Butcher
spin
webassembly
wasi
component model
kubernetes
cloud
There is something to be said for taking a moment at the end of the calendar year to look backward at all that has happened, and then anticipate what is coming in the future. In this post, I reflect on community, open source, innovation in Spin, language support, and where we’ll all be running Spin apps in 2024 (Spoiler: There will be Kubernetes!).
Connecting with Developers Around the World
If I were to summarize the year in a word, it’d be connected. Connection is why we prioritized going to conferences and meeting people and hanging out. We attended the inaugural Wasm IO conference and the first WasmCon. We were at both KubeCons (Amsterdam and Chicago), DockerCon, Civo Navigate, GlueCon, and WeAreDevelopers (to name a few) as well as the Open Source Summits on both sides of the pond. Most memorably for me, we took an 11 day trip through India doing multiple meetups before attending KCD Mumbai. And beyond conferences, we started live-streaming on the Fermyon YouTube channel regularly, as well as really devoting time and energy to Discord.
Diligent Open Source Stewards
Repeatedly, we at Fermyon have committed to being good stewards of open source. That means contributing code upstream, maintaining good licensing practices, participating in standards work, and reaching out to other open source communities.
Many developers at Fermyon are actively engaged in Bytecode Alliance (BA), Cloud Native Computing Foundation (CNCF), Linux Foundation (LF), and other orgs.
The Wasm Component Model is the most important piece of technology being developed for WebAssembly. The Bytecode Alliance has been working on it for at least three years. But in 2023, the tooling began to materialize first in Rust and C, then in Python, and now in JavaScript and Go. Folks at Fermyon have been deeply involved in the specification, the implementation, and writing the user documentation. Whether it’s the Wasmtime runtime itself or the guest-specific language tooling like componentize-py, Fermyon had a hand in building it.
Spin Leads the Way
As a group of developers, we are passionate about developer experience. Last year, our core user story for Spin was “as a developer, I can go from blinking cursor to deployed application in two minutes or less.” And we achieved that. But this year we stretched our vision. Could we keep that core developer experience, but also roll in services, AI, and even the nascent component model?
On the services side, we released Key Value Store, then Application Variables, then SQL Database. Each of these was designed to meet a core need of the developer, while not requiring the developer to set up more stuff locally. It should just work.
Over and over we heard people asking how to build AI-enabled applications. And on a plane flight to India, Radu took a first pass at integrating LLM-based inferencing into Spin. Several weeks later, Spin 1.5 was released with AI inferencing support.
Part of being good open source stewards is to implement the standards in our own software. Spin was the first framework to introduce WASI p2 support (in Spin 1.0), switch to the component model (Spin 1.5) and then provide developer tooling to use components (Spin 2.0). And we’re well on our way to supporting more of the WASI specifications at the opening of 2024.
Python, JavaScript, TypeScript, Go, and Rust
On a team the size of Fermyon’s we have to prioritize our work carefully. When it came to language support, we wanted to make sure to provide developers with meaningful choices. We wrote SDKs for scripting languages (Python and JS/TS) as well as compiled languages (Go and Rust).
Along with supporting Key Value Store, Configuration, AI inferencing, and SQLite-compatible databases, Spin SDKs also introduced external database driver support (Postgres and MySQL), Redis, and even HTTP routing.
In 2024 we plan on continuing to evolve these language SDKs. In fact, a big overhaul of the JavaScript engine is underway, and we’re looking forward to releasing that in the coming year. We also frequently look at what other languages we ought to support. If you have ideas, drop into Discord and let us know. (And this is one of those places where we’re eager for community contributions).
Fermyon Cloud
We’ve always wanted it to be easy for developers to deploy applications right away. And for free. In the past, I always found it frustrating when I built something new and exciting, and then had to spend hours configuring an environment to deploy it to, only to discover a month later that hosting my app was going to cost me a few lattes and a scone.
So when we introduced Fermyon Cloud we did so with the goal that anyone should be able to run their personal apps and small websites completely free.
When we added on Key Value Store, SQL Database, and other services, we allocated space on the free tier for those as well. The toughest was AI inferencing. As we all now know, AI-grade GPUs are really expensive. Yet to us, it is important that any developer be able to experiment with this technology and start integrating it into their tools and apps. And the rubber hit the road on this one, too. We’ve told people since our inception that WebAssembly is faster, denser, and cheaper than other environments. AI gave us a chance to prove it.
We’re particularly proud of our integration with Civo and Deep Green, which has resulted in Fermyon’s Serverless AI heating a swimming pool in the UK.
But we also wanted to make sure that developers, teams, and companies with bigger needs could purchase additional capabilities, resources, and storage. So we introduced two new tiers this year: The Growth and Enterprise tiers. It’s been exciting to see new projects on these new tiers, especially as AI projects make their way from the design room to implementation. I’m excited about where this is going to go.
The Future of Self-hosted Spin is Kubernetes
Spin makes it easy to work locally. Fermyon Cloud makes it easy to push your apps to a managed service. But what if you want to host your own environment? After trying a few things, we think we know the answer.
The ten of us that started Fermyon all came from a Kubernetes and cloud native background. We’d worked on projects like Open Service Mesh (OSM), Helm, Draft, Open Application Model (OAM), Brigade, and Porter.
We released an open source reference implementation called Fermyon Platform in 2022. This platform used Terraform, Consul, Vault, and Nomad — all HashiCorp projects. And we had tremendous success running a beefed-up version of this platform for Fermyon Cloud. We reached the point where we could run 2,500 Spin apps on a single AWS m5 2xlarge image. That same image, for comparison, is capped at 58 containers in Kubernetes (that’s a hard limit, and we’d be astonished to see anyone get that many containers running on one).
We’ve been piloting Kubernetes work with Microsoft on AKS. And in September, Civo also announced support for running Spin apps in their Kubernetes. Docker Desktop, of course, has been able to run Spin apps all year, but they improved support in October. And then in November, we announced support for WebAssembly on RedHat OpenShift via the Kwasm project.
As the year draws to a close and we set our eyes on 2024, it is clear to us that Kubernetes is the right scheduler for self-hosted Spin applications. So we expect to put more energy in that direction all of next year.
Components, Components, and More Components
Spin 2.0 shipped developer-facing support for the Wasm Component Model. But it wasn’t the first release to have component support. That would be Spin 1.5. But there’s even a little more backstory to components.
If you’ve written Spin apps, you know that since the first days of Spin in 2022, we’ve used the term component to refer to each Wasm receiver you declare in your spin.toml. We weren’t overloading the term. We were anticipating the longer-term design of the component model. We knew that the mechanics of Spin’s internals would move entirely to the component model.
In Spin 1.5, we moved our internals to components. So any app built with Spin is, in fact, a component-based app. But while all of this was happening behind the scenes, we didn’t initially expose the ability for developers to bring (and link) their own components. There were two reasons for this. The first is that Wasmtime’s internal implementation of components was not yet stable, and we didn’t want to subject developers to a litany of breaking changes. The second was that we didn’t feel like the tooling was ready yet. When I first tried to build my first component-based app this summer, I spent hours and hours frustrated over the fragility of the ecosystem tooling. It wasn’t ready.
But as we got to Spin 2.0, things had substantially stabilized and both Rust and Python had viable component tooling. Now it’s possible for you to use components as part of your apps.
There is much more to do on the component side. Most importantly, we as a community need to begin building components and componentizing our favorite libraries from our favorite programming languages. Looking to the year ahead, this will be a major theme across the Wasm ecosystem. And Fermyon will be right there in the middle of things.
Hello, 2024!
Startup life is fast, furious, and fun. At the beginning of 2023, I wrote an article for The New Stack in which I claimed that 2023 was going to be the “year of Wasm.” And almost all of my predictions came true (with the exception of JavaScript supplanting Rust).
But if there’s one thing I am looking forward to in 2024, it’s seeing WebAssembly solidify into that sort of rock-solid technology upon which we can build the biggest and most robust applications.