AxisOps Harbour
Labs

Insights

Since this was written: Asked and answered. Andromeda became Microcelium; the framework held, became the platform layer the control plane now manages, and the follow-up is the 2025 entry "Zero to ping, and the decade of doing it by hand".

Galaxy-scale engineering, and why we named it Andromeda

We have built the platform layer from scratch for every client we have taken on. Ingress, TLS, database, queue, object store, the thing that watches the other things. Different names each time, the same shapes.

It runs somewhere between three and six weeks per engagement before anybody writes a line of software the client asked for. Multiply that across a client list and the number stops being a rounding error and starts being most of a year.

This year we stopped doing it. The internal name for the thing we are building instead is Andromeda, and the name carries the argument.

Why a galaxy

A galaxy applies the same handful of physical laws as a solar system, at a scale where different structure emerges: spiral arms, a bar, a halo. Nobody designs the arms. They fall out of gravity operating on a lot of mass over a long time.

That is the bet. The structure that holds four machines together and the structure that holds four hundred should be the same structure, operated at a different scale, rather than two different systems with a migration project between them. If the small version is a toy and the large version is the real thing, the small version teaches nothing and the migration is where the year goes.

Most platform tooling fails this test. It is either a laptop convenience that falls over at ten nodes, or a distributed system with a minimum viable size of five machines and a full-time operator. The gap between them is where small teams are forced to choose badly.

What a component framework actually means

Three commitments, and none of them is a new technology.

One description, every environment. A service is declared once. Laptop, staging and production differ in values, not in structure. The moment the production description is its own artefact, maintained separately, it drifts and the drift is only discovered during an incident.

Composition over configuration. A client stack is an assembly of components with declared relationships. Adding search is adding a component, not editing six files and hoping. Ansible made the single-machine version of this argument for us three years ago in Why We Never Repeat Ourselves; this is the same argument raised to a whole stack.

The generated artefacts are disposable. The compose file, the ingress config, the environment files are output. They are never edited and never the source of truth. An operator who hand-edits generated output has broken the model, and the model should make that difficult rather than merely discouraged.

None of this is novel. It is what every competent team ends up building privately, badly, under deadline, and then cannot reuse because it is tangled into one client's particulars.

What it costs

A framework is a bet that the shapes repeat. Where they do, the saving is large. Where they do not, you have added indirection between an engineer and the thing they are debugging, and that indirection is expensive at three in the morning.

The specific risk is the client who needs something genuinely unlike the others. If the answer is "the framework cannot express that", the framework has started dictating architecture, which is the failure mode of every internal platform ever built. The escape hatch, dropping to plain compose for one service, has to stay open and has to stay unembarrassing to use.

The second cost is that we now maintain a product nobody is paying for directly. It competes for attention with billable work, and the first time it gets starved during a busy quarter is the moment it starts rotting.

What it makes possible

The time saved is the dull half of this. The interesting half is what becomes affordable once the platform layer is nearly free.

A four-person company gets the same platform layer as a forty-person one: the same ingress, the same TLS renewal, the same reproducible rebuild. That is the layer and not the posture. Review depth, on-call coverage, security testing and how much of the system lives in one person's head are all still functions of headcount, and nothing here touches them.

But small teams run worse infrastructure mostly because the setup cost is roughly fixed and they amortise it over far less, not for want of engineering skill. Drive that one cost towards zero and the floor comes up.

Rebuilding stops being frightening. If the whole stack is described, you can destroy it and bring it back. That changes the posture of everything else: you patch aggressively because rollback is cheap, you test restores because restoring is normal and ransomware becomes an afternoon rather than a company-ending event. We expect that to matter more each year.

And the small operator can stay small. A clinic, a school, a council can run their own systems on their own hardware with a realistic maintenance burden, instead of concluding that the only sane option is somebody else's cloud. The technical argument for centralising was always partly an argument about operational cost. Lower the cost and the argument weakens.

Who ends up owning the shapes

The uncomfortable part. A framework that describes your entire estate is also the thing that decides what your estate can be, and whoever defines the components holds that.

That is fine while it is us, for us. It stops being fine the moment it is a product and the components are defined by a vendor whose interest is that you keep paying. The large platform vendors have already worked this out: the free tier teaches your engineers a vocabulary, the vocabulary is proprietary and the migration cost away is measured in years. That is lock-in by habit rather than by contract, and it outlasts any contract.

The defence is specific and we are committing to it now, before there is a product to be tempted about. The descriptions are plain YAML. The output is ordinary compose and ordinary config files that run without any of our tooling present. If Andromeda vanished tomorrow, every stack it has rendered keeps running, and an engineer who has never heard of us can read what it produced. A framework you cannot leave is a tenancy agreement.

The part we cannot defend against is us: the pressure, later, to make the convenient path the proprietary one. Writing that down here is the cheapest guard available.

Where this breaks

Whether the shapes really do repeat enough. We have a strong sample of clients that look alike, and a weak sense of whether that is a fact about infrastructure or about our client list. The real test is the first engagement that does not fit, and we have not had it yet.

Ask us again in two years. Either this is the foundation everything else sits on, or it is an elaborate way of having built the same platform layer one more time.