Keynote: Sustaining Open Source Software by Justin Warren
Good talk. Advise you have a watch it on Video. Good thoughts on the economics of Open Source
Sandboxing untrusted code with WebAssembly by Katie Bell
- Works for MongoDB. Webscale!
- Untrusted Code
- Example Shopify
- Supports 3rd party apps
- What happens when 3rd-party apps goes offline and is used by a lot of stores
- What if slow and inserts itself into customer flow making experience bad
- Decided to hosted 3rd party apps in their cloud to provide better reliability
- Shopify decided to go with webassembly
- Some alternatives for sandboxing
- Small VM like firecracker – 4MB memory, 125ms startup
- Docker – Using Shared Kernel still
- V8 Isolates – Used to isolating processes within a chrome tab. Cloudflare runs many workers in a process, startip 5ms
- But not fair comparison. Lots of tradeoffs on how secure vs speed vs flexability
- Webassembly
- Designed to compile big apps to run in a browser (eg photoshop)
- Is a compile Target – .wasm binary
- Originally designed to usually be called from javascript ( in browser )
- Is a tiny simulated computer, very locked down, can’t interact with anything outside. Can just provide and call functions
- When you build compiler will usually create a javascript wrapper to make it easier to use so you don’t have to call wasm directly.
- WASI
- An API lets you run webassembly programs as regular programs
- wasmtime – program to run .wasm directly
- Keeps things sandboxed but can’t optionally provide with with a very limited set of stuff that must be explicitly provided
- Sandboxing Webassembly in the real world
- Shopify use this. See their docs and definitions
- Firefox and Graphite font shaping library
- Compiled from native code into wasm to ensure memory safety rather than audit or re-write in rust
- Is it secure?
- Sometimes. But WASI is built with holes intentionally so can have bugs
- Wasmtime has a lot of work put into sandboxing though
- Use multiple layers of security
- WASI standard is in progress ( webassembly itself is fairly stable )
80% faster, 70% less memory: building a new high-performance, low-cost Prometheus query engine by Joshua Hesketh, Charles Korn
- Works at Grafana Labs on Mimir database
- Explains time-series database. (Name+Labels)+time+number
- Talk covers the query app which turns promql requests into a result
- Memory used by the old software was bouncing, had to be over-provisioned which wastes money or sends back errror to use if runs out of memory.
- Prometheus Promql engine has little room for extensions
- Problem
- Prom promql engines loads the entire series into memory before processing it further
- Fix would require a new new rewrite.
- Which they did
- MQE engine
- Loads a bunch of samples and then streams to operator(s). Then repeats a bit at a time
- Will fallback to Prometheus engine of function is not yet implimented
- Very efficient on range queries
- He explained memory allocation strategy using pooling. I got a little lost
- “That was a very oversimplified example”
- query-tee
- Send queries to two different engines and ensure they return the same result for testing
- Has test group for data that can run this over as well as live queries. Might to fizzy query testing in future
- Engine is available and can be switched in via command line
- Does fall-back if things are not implemented
- Implements the most common queries (above 90% of actual request)
