Systems and infrastructure
Services in Docker containers on Vercel, Cloudflare or your own Ubuntu servers, with Postgres, MongoDB or ClickHouse underneath and Grafana dashboards on top, so a problem reaches you before a customer does.
Infrastructure is where a working application becomes a running service. The questions it answers are dull and they are the ones that decide the cost of an outage long before the outage happens: where does this run, what does it do when the machine reboots, who finds out when it stops, and how does the last known good version come back.
Containers, and how many
Services run in Docker containers because a container is the smallest honest description of what a service needs: its dependencies, its configuration and its ports, written in a file a second machine can reproduce. Compose is enough for most systems and stays readable at sixteen containers. Kubernetes is added when the scale genuinely calls for it, not because it looks better on a diagram.
Where it runs
Vercel for the front end and its preview deploys, Cloudflare for DNS, TLS and email routing, and Ubuntu servers set up and managed from the terminal when a workload does not belong in a serverless function, or when the data has to stay somewhere you can point at. The choice between them is usually about who has to be able to reach the machine at three in the morning, and about where the data may legally sit, rather than about the price list.
The part that has to survive
Postgres for most things, MongoDB where the shape of the data genuinely varies, ClickHouse when the question is analytical and the row count is large. Whichever it is, the things that matter are the same: a backup that has been restored at least once, migrations that only run forward, and a connection limit that was thought about rather than discovered on a busy afternoon.
Knowing before the customer does
Grafana dashboards on top, showing the handful of numbers that actually indicate trouble: queue depth, error rate, disk, and the latency of the request somebody is waiting on. A dashboard nobody looks at is not monitoring, so the numbers worth being woken for get an alert attached and the rest stay a dashboard.
What you get
- Containerised services with a compose file a second machine can reproduce.
- Postgres, MongoDB or ClickHouse, with a backup that has been restored at least once.
- Grafana dashboards on the numbers that indicate trouble, with alerts on the ones worth waking up for.
- A written runbook: how to deploy, how to roll back, and what to check first.
The trading platform in the work section runs sixteen containers under Compose with a Kubernetes variant alongside it, and it is linked below.
Common questions
- Do I need Kubernetes?
- Usually not. Docker Compose runs a sixteen-container system on one machine and stays readable while doing it. Kubernetes earns its complexity when you need several machines, rolling deploys without downtime, or automatic rescheduling. Below that it is a second system to operate.
- What monitoring do you set up?
- Grafana dashboards on the numbers that indicate trouble, with alerts on the ones worth being woken for. The point is that a problem reaches a person before a customer does, so an alert goes to somebody rather than to a screen nobody has open.
- Can you work on my own servers instead of a cloud?
- Yes. Ubuntu servers set up and managed from the terminal, with the services in containers so the setup is reproducible. This is often the answer when data has to stay in one place, or when a workload is too steady to be worth renting by the second.
- What about backups?
- A backup that has never been restored is not a backup. Restoring one is part of setting it up, and the restore procedure goes into the runbook together with how long it takes.