Learn more about WebAssembly's use within service mesh data planes inThe Enterprise Path to Service Mesh Archictures (2nd Edition) - free book and excellent resource for anyone looking to understand WASM filters, Lua scripts, and other options available for extending 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:
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 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.