Units: running more than one copy of your app
A Workload is your app on Zaroz. It runs as one or more units. A unit is one running copy of your app: its own process, its own CPU and memory, its own logs.
Most Workloads only ever need one unit, and that is the default. You can ignore everything on this page until you have a reason to want a second copy. This page explains those reasons from scratch, so you do not need any background in scaling.
One copy, and its limits
With one unit, everything your app does happens in one place. That is simple and cheap, and it has three limits:
- Capacity. One copy can only do so much work. When a web API gets more requests per second than one copy can answer, requests queue up and slow down, and past a point they fail.
- Availability. When the one copy restarts (a crash, an update, a node being maintained), your app is down until it is back. With one copy there is no one to cover for it.
- Uneven load. Traffic is not flat. If you size one copy for your busiest hour, you pay for idle capacity the rest of the day.
Running more than one copy of the same app is called scaling out, or scaling horizontally. Units are how Zaroz does it for you.
What more units give you
- More capacity. Four units can answer roughly four times the traffic of one, provided your app keeps no state that only one copy can hold (see "Before you add a unit" below).
- Cover while restarting. While one unit restarts, the others keep answering. Updates roll through the units one at a time instead of taking the whole app down.
- Paying for load, not for the peak. With an autoscaled policy, extra units exist only while there is load for them, and they are billed by the hour (see Billing).
When to use more than one unit
Good reasons:
- A web or API Workload whose CPU stays high at busy hours.
- A queue worker that cannot keep up with the backlog. Each unit takes jobs from the same queue, so more units drain it faster.
- A Workload that must stay up during restarts and updates.
- Load that follows a schedule (a game server network that fills up on weekend evenings).
Not good reasons:
- The app is slow because of a bug, or because it waits on a slow database. More copies of a slow thing is a more expensive slow thing.
- The app keeps something on its own disk that every request needs. See below.
Before you add a unit
Units are stateless copies. Each one starts from the same image and the same settings, and nothing one unit holds in memory or on its disk is visible to another. That works well when state lives somewhere shared: a database, a cache, an object store.
If the Workload has a shared volume, it is held to exactly one unit, and the API tells you so with volume_locked: true. Zaroz refuses to scale it out rather than let two copies write to the same disk.
Also worth knowing:
- All units run the same image with the same environment.
- Requests sent to the Workload's name inside your project are spread across all ready units (see Private names).
- A public port goes to one unit, and an HTTPS endpoint is spread across them (see Public ports).
The units you pay for
Every plan includes a number of units (usually one) in its price. Units above that are extra units and are billed per hour while they run. Nothing is charged for units you do not run. Read Billing for the arithmetic with worked numbers.
If you never scale out, you never see it
A Workload running one unit shows no unit machinery in the console. There is one line in the Workload's settings that says it runs one copy and offers to scale out. Everything on these pages appears once you opt in.
Where to go next
- Fixed and autoscaled policies: how the number of units is chosen.
- Public ports and private names: how traffic reaches your units.
- Billing: what extra units cost, with examples.
- Logs and metrics: 30 days of history, per unit or merged.
- Limits: the ceilings and what happens at them.
- Units that your code controls: creating and stopping units from your own program (coming).
- Hands-on: Deploy a Workload from a public image, scale it, open a public port, read its logs.