Lua vs WebAssembly

The Power of the Data Plane

Operators benefit from control planes because they provide much-needed element management. Data planes require control planes to apply service mesh-specific use cases to their fleet of service proxies. A control plane performs activities like configuration management, telemetry collecting, infrastructure-centric authorization, identity, etc. However, the service proxy is a massive source of power for them. Users frequently require customizing the chain of traffic filters (modules) that service proxies employ to perform much of their heavy lifting. Different technologies are used to provide data plane extensibility, and consequently, additional custom data plane intelligence, including:

• Lua - a scripting language for execution inside a Just-In-Time compiler, LuaJIT.
• WebAssembly (WASM) - a virtual stack machine as a compilation target for different languages to use as an execution environment.

Lua and WebAssembly

People are discussing the merits of using a WebAssembly runtime since the introduction of WASM into service meshes. A  Lua runtime can be as little as 4 kb, with LuaJIT being surprisingly fast, having a runtime of only ~200 kb.

The WebAssembly loader, not the runtime, is the source of complexity for the host software. When comparing the two, how do you weigh GCC or LLVM in terms of making optimized C or C++ faster or slower than LuaJIT?

The complexity of a WebAssembly runtime stems from the fact that it contains arch-specific optimizers as well as an Intermediate Representation to machine code translation stage that would usually be executed inside GCC or LLVM. Machine code can be created once and then cached on non-volatile storage until the input WASM file's hash changes (like the extracted contents of a Zip file). Since WASM has a similar approach to sandboxing (making the language/bytecode unable to describe accessing resources outside of what is granted), the result is lighter than Lua once the machine code is generated. However, WASM's compiled machine code does not require a garbage collector or JIT engine.

WebAssembly follows the same flat, garbage-collected memory model as malloc and free. Suppose you want a garbage collector in a WebAssembly application. In that case, you can either compile it to WebAssembly and run it inside the sandbox or wait for extensions currently developing, such as "opaque reference types," which allows WebAssembly applications to interact with objects managed by a Garbage Collector outside the sandbox.

NGINX and Lua

NGINX allows you to write dynamic modules that can be loaded at runtime based on configuration files. By modifying the configuration files and reloading NGINX, these modules can be unloaded. NGINX enables you to use Lua to embed custom logic into dynamic modules.

Lua is a lightweight, embeddable scripting language that supports procedural, functional, and object-oriented programming. Lua is dynamically typed, and runs by interpreting bytecode with a register-based virtual machine.

NGINX provides the ability to integrate dynamic Lua scripts using the ngx_lua module. Using NGINX with ngx_lua helps you offload logic from your services and hand their concerns off to an intelligent data plane. Leveraging NGINX's subrequests, the ngx_lua module allows the integration of Lua threads (or coroutines into the NGINX event model. Instead of passing logic to an upstream server, the Lua script can inspect and process service traffic. ngx_lua modules can be chained to be invoked at different phases of NGINX request processing.