Hi - zeroserve Caddy compat works by compiling Caddyfile to C. Technically I can keep the compiler in a separate binary/repository - but it just feels unnecessary.
zeroserve only understand eBPF at runtime. It's always the source-of-truth.
Hi, author here - a few critical pieces of this, like async-ebpf, were written long before those coding agents were released. I use AI assistance a lot when creating zeroserve itself, but I manually check AI output and take responsibility for it :)
> Firstly, can there be an easier way to stop a microVM mid execution in this single executable bottlefire format and then rerun that and it would start mid execution. (something akin to how criu does it?)
Not yet - Firecracker supports snapshotting so this should be doable though!
> if something like microvm could be run in normal cloud infrastructure?
Some cloud providers - like GCP and DigitalOcean - do support nested virtualization, and they work pretty well with Firecracker. Using VM migration to run stable workloads on spot instances sounds very interesting :)
Distributed consensus + fsync() determines the lower bound on commit latency. We have to wait for the data to be durable on a quorum of transaction logs before returning success for a transaction. That's usually 5-10ms, even within a single region.
A read-modify-write retry loop causes a high number of commit conflicts, e.g. for atomic increments on integers. Getting higher than 1/RTT per-key throughput requires the "backend" to understand the semantics of the operations - apply a function to the current value, instead of just checking whether timestamp(value) < timestamp(txn.start) and aborting commit if not.
I wrote a self-hostable control plane for Nebula (a Tailscale-like overlay networking tool), and have been using it for about a year: https://github.com/losfair/supernova
Built this because existing solutions like ZeroTier and Tailscale are trying to be too "smart" (auto-selecting relays, auto-allocating IPs, etc.) and do not work well for complex network topologies.
Data is always replicated to three of our "big" regions currently. Extending the list of storage regions and providing more flexible data distribution configuration is one of the next things we want to do.
> what about pricing?
During the closed beta it's free with a 1 GiB per project limit.
Engineer working on Deno KV here. Building on FDB is mostly a pleasant experience since it solves the hard part of the problem for us (concurrency control and persisting mutations).
We sometimes run into its limitations - the way we are using FDB is a bit beyond what it was originally designed for. But when it works, it works great.
Online DDL is now a WIP feature. This will allow to convert DB into read-only mode & run arbitrarily large schema migration concurrently (first stage), and eventually fully concurrent DDL by replaying logs.
What are you trying to achieve with WAL mode? Is it some kind of application compatibility issue?
The entire SQLite journaling mechanism is not used by mvSQLite (you can set journal_mode=off safely - although SQLite won't be happy to do explicit rollback in this case)
Shameless plug of my mvSQLite [1] project here! It's basically another distributed SQLite (that is API-compatible with libsqlite3), but with support for everything expected from a proper distributed database: synchronous replication, strictly serializable transactions, + scalable reads and writes w/ multiple concurrent writers.
This makes SQLite transactions no longer serializable (in regard to the schema), and breaks the safety of any kind of external concurrency (e.g. mvSQLite and Litestream).
TrueTime is an efficient primitive to ensure external consistency across multiple consensus groups, not within one group. The current DO infrastructure does not give the TrueTime guarantees for free: you cannot do transactions across two or more durable objects, and the max throughput within a transaction domain is limited to what a single V8 isolate can handle sequentially.
The one feature I miss the most on Cloudflare Workers/Durable Object is TrueTime.
Durable Objects are fundamentally replicated state machines with a nice JavaScript API. You can build an automatically sharded (yet correct) Kafka API implementation, or even an entire Spanner-style distributed database on Workers, given the right primitives (DO + TrueTime).
zeroserve only understand eBPF at runtime. It's always the source-of-truth.