The continuum¶
Self-hosters and enterprises want the same application, at very different sizes. Myxo aims to give them one path: an installation starts as one process on a laptop and grows to replicas on PostgreSQL, by configuration alone.
| Step | What changes | What you learn |
|---|---|---|
| 0. Develop | services and a layout: one process, SQLite | the layout file; myxo migrate and serve |
| 1. One box | a layout with two processes on one machine | several processes; a process's url; myxo up |
| 2. A real database | DATABASE_URL |
that variable |
| 3. Process types on a platform | the platform's files, from myxo export |
the image; the secret; the migration job; the public port and its ingress |
| 4. Replicas | an instance count, on PostgreSQL | instance counts |
The tutorial walks through all five on a guestbook.
What the run measured¶
Experiment E14 took one installation of a larger testbed through the five steps, three times, on three Kubernetes nodes from step 3:
- Code: no step changed it. A hash of the application's and the framework's sources stayed the same throughout.
- Replicas: adding them interrupted nothing, with no failed probe out of 360 across the runs.
- A lost node: stopping the node where the scheduler's leader ran left the application whole. Another leader took over. Each period still got one report. Some probes failed for 42 to 58 s, 7% to 9% of those sent in that window.
- Learning: steps 1 and 3 add more than one concept. Step 3 is the steep one, at 12 commands against 5 and 6 on either side, and Kubernetes brings most of them.
The steps that stop and start processes interrupt the application for a few seconds: about 2 s at step 1, 3 to 4 s at step 2, and 3 to 8 s at step 3.
Where each step stops¶
Myxo refuses a layout that asks too much of its step, in a message that names the next step:
$ WEB_INSTANCES=3 myxo check layouts/app.toml
layouts/app.toml: process web cannot run 3 instances on SQLite, which book and the layout's database use: move it to PostgreSQL first (step 2 of the continuum: a postgresql:// URL)
SQLite serves one host, with one writer at a time. A layout that runs a process using it as replicas, or shares it between processes on several hosts, is refused. So is a Kubernetes export on SQLite, since pods share no files.
The rate that says it is time to move: on a server whose drive flushes each commit, the SQLite queue kept up with 25 jobs per second beside 10 of the application's writes per second, or 10 jobs beside 50 writes. Past that, jobs wait for seconds, and some puts and writes fail. On the same server, PostgreSQL holds about 1,000 jobs per second. The jobs guide gives the details.
myxo up runs one instance of each process, and refuses a layout that asks for more. Replicas need a platform.
What the continuum does not move¶
Nothing moves an installation's data from SQLite to PostgreSQL. An installation that changes database starts empty. What SQLite holds stays in the file.