The Exit Interview: JP Phillips

Summary

JP Phillips leaves after four years at Fly.io, saying the company’s increasing focus on Managed Postgres and LLMs does not match the direction he hoped to see: a move toward cloud provision and larger established customers. He says his original goal—building Fly Machines to replace HashiCorp Nomad—has been accomplished, with the platform now capable of supporting the next iteration of products. His central engineering contribution was the Fly Machines API and flyd, an independently running orchestrator whose finite-state-machine invocations use deterministic, durable execution and log each step in BoltDB. He also discusses corrosion2, a Rust service that uses SWIM gossip and a CRDT-structured SQLite database to distribute near-real-time machine state. Phillips criticizes GraphQL, Elixir, inconsistent communication and shifting priorities, while defending BoltDB and praising Rust’s productivity.

Takeaways

1. 1

   flyd runs independently across thousands of worker servers and uses finite-state-machine invocations for operations such as creating, starting and cordoning Fly Machines.

2. 2

   Phillips says BoltDB was preferable to SQLite for flyd because its narrower storage interface reduced the scope of possible state changes and avoided SQL updates across a host or fleet.

3. 3

   corrosion2 uses SWIM gossip and a CRDT-structured SQLite database to make near-real-time information about Fly Machines available to platform components.