Virtualization Technology News and Information
VMblog Expert Interview: Exploring All Things Fiberplane with Micha Hernandez van Leuffen


Developer tools have been lagging behind. And Fiberplane wants to change that, starting with incident resolution. They are on a mission to enable DevOps and Site Reliability engineers to deeply collaborate on hard technical problems.

To find out more about the company and what they are up to, VMblog spoke with Micha Hernandez van Leuffen, the founder and CEO at Fiberplane.

VMblog:  To kick things off, can you explain what Fiberplane does for VMblog readers?

Micha Hernandez van Leuffen:  Fiberplane is a developer tool that provides collaborative notebooks for debugging infrastructure. It allows users to integrate data sources from their observability stack to get to the heart of problems quickly and collaboratively.

VMblog:  What problem does Fiberplane solve?

Micha Hernandez van Leuffen:  Enterprise infrastructure over the last decade has become incredibly complex to manage, leaving developers and DevOps teams to mitigate bugs with tools that were slapped together or designed for a different time. Until now, developers have been getting by with dashboards that they set up in advance and require that they know what they're looking for. But as unknown unknowns rise, this approach no longer works.

Furthermore, the rise of distributed and remote teams, which has grown substantially due to the pandemic, more aggressive recruitment and retention strategies and the distributed nature of computing, requires collaboration-first tools, which we haven't traditionally seen in the SRE/DevOps space.

Modern CI/CD workflow, microservices and distributed teams and systems all require a new explorative form factor for infrastructure debugging, one that works real-time and takes into account the changing nature of teams.

Fiberplane solves this problem of infrastructure debugging in massive distributed systems and among distributed teams.

VMblog:  Congratulations on the recent public beta announcement.  Can you tell us more about it?

Micha Hernandez van Leuffen:  Thank you. We've been hard at work building the first real-time collaboration notebook specifically designed for developers and DevOps teams to debug their infrastructure, and it's great to open up the product via this public beta release.

VMblog:  What observability stacks are supported with Fiberplane?

Micha Hernandez van Leuffen:  We currently support Prometheus (self-hosted and Promscale), Elasticsearch, and Loki. We also have a Webhook integration with PagerDuty which allows users to jump straight from an incident alert to a Fiberplane Notebook.

VMblog:  Why did you choose to build Fiberplane's technology in Rust and WebAssembly (Wasm)?

Micha Hernandez van Leuffen:  Fiberplane's technology is built in Rust and WebAssembly (Wasm).  

We picked Rust because of its memory safety attributes making it a great choice for systems and infrastructure programming. It is also closely tied to the WASM ecosystem and tooling, which we use for our provider (plugin) model and the conflict resolution for the real-time editor. Providers empower enterprises to integrate Fiberplane with their infrastructure, enabling them to query, explore and visualize their observability data. Rust compiles to WASM, which allows our providers to run both inside the browser as well as server-side.

We use WASM in three key areas:

  • To power the collaborative editing and conflict resolution (multiple people typing at the same time in a Fiberplane notebook and adding graphs, tables with data etc) we use the Operational Transform algorithm (same that Google Docs leverages). As multiple people might be collaborating inside of a notebook, the state of the notebook might diverge. The logic to deal with these conflicts in operation lives both on the server as well as the client. As such, it makes sense to implement Operational Transforms once, using the same codebase, instead of duplicating it across the client and server (probably using different programming languages). As such, we chose WASM, (written in Rust, as our API is also Rust) as the way to implement this functionality, saving quite some development time and reducing the risk of inconsistencies. It's a great fit for WASM.
  • We are pulling data from different sources (think your observability stack [monitoring, tracing, logging]). This data might come from the server but could also be reachable from a user's browser. To solve this, we implemented Fiberplane Providers (our plugin model) that can live both in the browser as well as inside the user's network. This allows the plugins to be implemented in any language that target WASM, increasing overall performance, plus that WASM sandboxing model increases security.
  • Finally, we wrote some tooling that specifically helps us with running WASM in various environments. We created and open sourced fp-bindgen; a bindings generator that can be used to write plugins in Rust and that can be run both in the browser as well as a Rust environment, increasing the interoperability between Rust and Typescript.

GitHub repo:

VMblog:  And finally, what's next for Fiberplane over the coming 12-18 months?

Micha Hernandez van Leuffen:  In keeping with Fiberplane's constant drive towards extensibility we will continue to expand our catalog of Providers, and are also planning to open source them so the community can build out Providers that they find useful. But overall we just want to build a product SREs and Devs love, so right after this Public Beta release we'll be looking to understand our users' feedback and improve the Fiberplane experience based on that.


Published Tuesday, November 15, 2022 8:01 AM by David Marshall
Filed under: ,
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
<November 2022>