Operations

Once pipelines are running, operating BARRY is mostly watching, occasionally scaling, and rarely upgrading. All three live in the same place, and the day-to-day is meant to be quiet.

The Monitor page brings every run together — status, duration, throughput, and the rows and bytes moved — alongside how fresh each dataset is against its expected cadence, which clients are online, and a live feed of what is in flight. A freshness signal turns a dataset amber before anyone downstream notices, so problems surface early rather than in a support ticket.

BARRY is built to be modest by default. The server runs comfortably on a small footprint and overlaps its encoding so a single instance keeps a fast destination busy; in practice the limiting factor is usually the client's uplink out of your network rather than the server. Optional components scale independently — the PII sidecars, for example, can scale to zero when no transport needs them and warm up again before a run.

Upgrades are undramatic. The Windows client updates itself by pulling a new binary from the server on its next poll, so there is no fleet to patch by hand, while a container client is simply a new image tag. The server is a new container release, and its version and the UI's are kept in lockstep so what you see in the sidebar matches what is actually deployed.

When something does go wrong, you diagnose from facts. Each run keeps its own log and error message, and the runtime also records the times it refused to launch a run and why — a client offline, a connection disabled, a firewall rule in the way. The goal of all of it is boring: green runs, fresh data, and a client fleet that keeps itself current with very little of your attention.

← All documentation