After several months in development, AssemblyLift v0.3 has been released and made available via Cargo! 🥳
If you've never heard of it or just need a reminder, AssemblyLift is an open platform for developing cloud-native applications. At its core are the AssemblyLift Runtime and the AssemblyLift CLI. The runtime provides an environment for executing compiled WebAssembly (WASM) on infrastructure such as AWS Lambda, and is one of the more unique aspects of the platform which we'll dig into more below.
If you'd like to install the CLI and explore the things being discussed in this post, get started by running
cargo install assemblylift-cli
Note the CLI is currently supported on Linux and macOS only.
State of the World
There's an adage I can't remember the origin of, which states that something must be built three times in order to get it right. On the first pass you are learning what you wish to build. On the second, you are learning how to build it. Then on the third, you build it for real.
It's never quite that simple of course (the road to 1.0 is long), but much of the work that has gone into the v0.3 release is "beneath the surface", making this a rather foundational release so to speak. Lots of key areas were reworked or completely rewritten based on the lessons of v0.1 & v0.2, which make implementing new features easier now and in the future.
That said, there are also many user-facing improvements which make this the most "complete" offering of AssemblyLift to date!
Below we'll highlight the major changes between v0.2 and v0.3, and walk through each in more detail in the following sections. Towards the end, I'll discuss a little more about where the project is headed next. 🙂
Change List
- Support multiple infrastructure providers for services & functions
- Experimental Lambda runtime based on Alpine Linux
- New TOML->HCL transpiler pipeline
- Support for arbitrarily large data buffers which can be paged into WASM memory (function input and IOmod responses)
- Deployment of & support for the IO Module Registry
- Bump critical dependencies to latest versions! In particular, Tokio 1.x is now used throughout the Asml crate ecosystem.
Key Changes
Infrastructure Providers
I'll be honest; this is the change which took the most work and is easily the least visible 😂
But! That doesn't mean it wasn't important.
While AWS Lambda is still the de facto provider, a goal of the project has always been to support deployment to a variety of kinds of infrastructure.
To accomplish this, most of the code which translated your AssemblyLift TOML into Terraform HCL needed to be thrown away and rewritten. This resulted in the new transpiler mentioned above!
The new provider implementation was tested with an experimental provider for Lambda based on Alpine Linux. The original purpose for this provider was to support faster, LLVM-compiled WASM binaries which are incompatible with the default Lambda OS. Unfortunately, despite the tiny image size I discovered that cold-start time a for Docker-based Lambda is much too high to be worth it.
Buffers & Memory Management
A well-published feature of WebAssembly is its memory model, which is a sandboxed linear memory. This essentially means that WASM code has a large array of bytes to work with inside the sandbox, but there are no pointers or other means of escaping elsewhere. A side-effect of this is that to get new data into WebAssembly from the host, the host must write into a known region of the linear memory.
In previous versions, AssemblyLift did not buffer data on the host before passing it to the WASM guest. If the data could not all fit in the defined region within the guest, tough luck!
Clearly that's no good. So there are now host-side buffers which can reach arbitrary size, and then be paged into a location in WASM via ABI calls as needed. This change shows up both on function input, as well as in IOmod memory management as responses are buffered and handled by the guest.
IO Module Registry
Another biggin' that has been in-progress for an age.
IO Modules or IOmods are a unique feature of AssemblyLift which are used to provide the WASM guest with access to outside functionality.
As of v0.3 the CLI can fetch IOmod dependencies from the new public IOmod Registry, while IOmods themselves are now shipped in Zip-archived packages. As of writing, the modules available on the registry are limited, but more are planned (including modules for all remaining AWS services).
Upcoming Improvements
The next point release will focus on improving quality & error handling in a few areas of the code, as well as improving the DX* around the API Gateway/HTTP macros. At the moment for example, the http_ok! macro expects your response to be JSON. This suits API applications fine, but we would like to be more flexible and to support returning HTML from our functions. This opens us up to full-stack development with AssemblyLift in the future! 😎
In the longer term, we'll be expanding what can be managed by AssemblyLift directly. For example function permissions and/or IAM policies can not be set in the service TOML at the moment, which is a major usability issue that should be addressed.
We'll also be evaluating additional providers to support in addition to AWS Lambda.
* Developer eXperience
Learn More
The best way to learn about AssemblyLift right now is by visiting the official documentation.
You can also reach out to us on Twitter, via Element at #assemblylift:matrix.org, or in the comments below!
Oldest comments (0)