During her presentation at the inaugural edition of the InfoQ Dev Summit Munich, Danielle Lancashire, principal software engineer at Fermyon, hinted at WebAssembly containers as a greener alternative and a potential evolution from the current containerised approach to serverless computing.
Lancashire started her presentation by talking about the software’s carbon efficiency by referencing the Green Software Foundation’s software carbon intensity (SCI). This standard metric is based on a formula that allows the calculation of the carbon footprint of any software. It aggregates all the potential sources of carbon: the energy needed to run, the resources required to maintain the underlying computing power, and the minerals needed for developing the components they run on (e.g. CPUs or GPUs).
Even though the formula defined by the Green Software Foundation looks complicated:
SCI = ((E * I) + M) per R
- E = Energy consumed by software in kWh
- I = Carbon emitted per kWh of energy, gCO2/kWh
- M = Carbon emitted through the hardware that the software is running on
- R = Functional Unit; this is how software scales, for example, per user or device
She pointed out that, in an overly simplified manner, the SCI is just "the amount of compute over the usefulness of what if does."
The SCI index can never reach zero, but it should be as low as possible, and to achieve that, there are the following routes:
- Use less electricity while still performing the same amount of work
- Use fewer physical resources while still performing the same amount of work
- Schedule the computing that is not time-sensitive for those moments when cleaner energy sources are available
Lancashire pointed out that using very efficient programming languages ("rewriting everything in Rust or C would not have the impact you are hoping for!") "doesn’t tell the whole story", as few applications use the CPU at its maximum capacity.
More than that, "most servers use 30-60% of their maximum power during idle time". Since approximately 70% of the CPU is unused in containerised applications (primarily due to overprovisioning), using Kubernetes is insufficient. She hinted that improving compute density often matters more than the efficiency of a single application.
Regardless of the apparent evolution (from bare metal to virtual machines and now containers), Lancashire stated that "it still sucks", and there is place for improvement. Wasm’s initial target of replacing Flash in the browser in a safe manner generated interest also on the operational side, and WebAssembly System Interface’s implementation made it possible to use Wasm as deployable units on the server side as well. The addition of Wasi allowed Wasm to safely access the underlying computer (networking, port handling, the filesystem, etc.). So, WebAssembly deployable units are small (just a bit bigger than the code’s binary), portable, fast to start and stop, and safe as they are very isolated.
Lancashire believes that embracing serverless on top of WebAssembly units will allow organisations to have faster and cheaper infrastructure (financially and carbon-related). So, Wasm deployables might be a potential evolutionary step from containers.
