- docs/guides/application-capabilities.md: the .with(...) menu, by-reference wiring, and a recipe for writing a capability; disambiguates the overloaded 'capability' (topology vs application) flagged in DX review; wired into the book. - Deprecate ApplicationScore, features::Monitoring, features::PackagingDeployment (+ doc-deprecate the ApplicationFeature trait) in favour of harmony_app + ComposeDeploy/.with(...) (ADR-026). Legacy examples now warn; harmony lib is warning-clean (internal self-refs allowed).
160 lines
8.2 KiB
Markdown
160 lines
8.2 KiB
Markdown
<!--
|
|
STATUS: PRIVATE DRAFT — not for publication.
|
|
This is a working articulation of motivation and differentiation, kept in the
|
|
working tree but uncommitted. The author controls if/when any of it is made
|
|
public. Companion to the essay "A Wonderful Future for Computers"
|
|
(nationtech.io/wonderful-future-for-computers), which makes the case for the
|
|
decentralized *hardware*; this makes the case for the *software* that makes it
|
|
humane and real.
|
|
-->
|
|
|
|
# Why Harmony
|
|
|
|
## A nagging feeling, continued
|
|
|
|
The first essay was about *where* computing should live: not in a handful of
|
|
enormous datacenters drinking water and land while sitting mostly idle, but
|
|
spread out — in homes, offices, clinics, community spaces — machines that heat
|
|
a room while they compute, infrastructure made to *sing*.
|
|
|
|
That's the body. This is about the nervous system.
|
|
|
|
Because decentralized hardware doesn't matter if the only people who can
|
|
operate it are the same large organizations that already run the centralized
|
|
kind. A micro-datacenter in a village is just expensive scrap if it takes a
|
|
platform team of ten and a year of glue to run a single service on it
|
|
reliably. The hardware vision is only liberating if the software to wield it
|
|
is within reach of ordinary people and small teams. **Infrastructure is the
|
|
root of nearly every software business, and right now the root is owned.** If
|
|
we want computing to serve people, we have to give people something that lets
|
|
them actually run it.
|
|
|
|
That something is Harmony.
|
|
|
|
## The motivation, plainly
|
|
|
|
I've spent a long career deploying distributed systems for some of the largest
|
|
companies in the world. The robustness those systems have — the ability to
|
|
survive a failed machine, a bad deploy, a 3 a.m. outage and keep serving — is
|
|
not magic. It's the product of expensive teams, hard-won patterns, and an
|
|
enormous amount of careful, repetitive work. It is real, and it is *rationed*.
|
|
Only the well-resourced get it.
|
|
|
|
I find that quietly unjust. Not because anyone is villainous — I don't think
|
|
the people at the top of the cloud are evil — but because the *system* is
|
|
shaped so that the value of computing flows, by default, upward and inward: to
|
|
whoever already owns the most infrastructure. Lock-in, pricing that rewards
|
|
scale, defaults that assume you're big — none of it is a conspiracy. It's just
|
|
an incline. Everything rolls toward the same few owners because the ground is
|
|
tilted.
|
|
|
|
This project comes from a simple, almost stubborn conviction: that I should
|
|
try to give the best of what I know back to the world, and that the best thing
|
|
I know is how to make infrastructure trustworthy. If that knowledge can be put
|
|
into code instead of into another consulting invoice, then the robustness that
|
|
today costs a platform team can become something every app simply *has* — for
|
|
free, by default, the way running water is supposed to be.
|
|
|
|
## What we believe
|
|
|
|
**Computing should serve people, not skew toward owners.** We are not against
|
|
the rich or the large — we will gladly serve a Fortune 100 and a rural clinic
|
|
with the same code. What we refuse is to *bake the skew in*. We remove the
|
|
tilt rather than tilt it the other way. The playing field, made actually
|
|
level, is already radical, because the ground today is sloped. So we serve
|
|
whoever comes, on their terms, rich or poor, and we let no one be the default.
|
|
|
|
**Robustness is a right, not a privilege.** The ability to deploy something and
|
|
have it actually keep working should not be reserved for organizations with an
|
|
SRE budget. It should come in the box.
|
|
|
|
**Freedom means you can leave.** If your infrastructure only runs on one
|
|
vendor's cloud, you don't own it; you rent your own existence. The same
|
|
definition should run on your laptop, a cluster in your office, bare metal in a
|
|
community space, or any cloud — and you should be able to move it whenever you
|
|
like, without a rewrite.
|
|
|
|
## What Harmony is
|
|
|
|
Harmony is one way to describe what you want running, and have it converge —
|
|
the same way — wherever you point it. You write your infrastructure as real
|
|
code, not as piles of YAML validated at runtime when it's already too late. A
|
|
*Score* says what should exist. A *Topology* is wherever you're putting it — a
|
|
laptop, a tenant cluster, bare metal — described by what it can actually *do*.
|
|
Ask a Topology for something it can't provide and the program doesn't compile;
|
|
the mistake is caught at your desk, not at 3 a.m. And a deploy isn't finished
|
|
when a command exits successfully — it's finished when the thing is actually
|
|
*working*, proven by a smoke test, the way a careful human would check before
|
|
walking away.
|
|
|
|
The same Score runs in all of those places. Only the Topology changes.
|
|
|
|
## How we differ — honestly, and without mysticism
|
|
|
|
There is no shortage of good infrastructure tools. We are not claiming to have
|
|
invented robustness or declarative systems; we stand on a generation of work
|
|
that did. What we've found is a *seam* that, as far as we can tell, no one is
|
|
standing in:
|
|
|
|
- Tools that turn bare metal into a running cluster stop at the cluster.
|
|
- Tools that deliver applications assume a cluster already exists.
|
|
- Tools that compose infrastructure live in the cloud and assume someone else
|
|
handled the metal.
|
|
- The one project closest to our "infrastructure and application in one real
|
|
language" idea targets only the big public clouds — and its company didn't
|
|
survive the attempt.
|
|
|
|
Nobody we can find spans the whole thing — **bare metal, to running
|
|
distributed service, to keeping it alive over time — in a single, coherent,
|
|
type-checked model that is honest about the physical machine.** That seam,
|
|
aimed first at *decentralized and sovereign* deployments rather than the
|
|
hyperscalers, is where Harmony lives.
|
|
|
|
The differences that make it possible aren't tricks; they're choices:
|
|
|
|
- **Capabilities are described as types**, so the compiler is a colleague that
|
|
catches whole classes of misconfiguration before anything runs.
|
|
- **One model from the metal to the service to day-two**, instead of four tools
|
|
with four mental models taped together.
|
|
- **Local equals production**, so "it worked on my machine" stops being a
|
|
confession and becomes a guarantee.
|
|
- **It's real code**, which means it's reviewable, testable, and yours — not a
|
|
configuration dialect you'll be fighting in two years.
|
|
|
|
## Where we honestly stand
|
|
|
|
We are early, and I want to be the first to say it. The incumbents are years
|
|
ahead of us on breadth — the sheer number of clouds and services they can talk
|
|
to is a real moat we have not crossed and may never fully cross. We're a small
|
|
project written in a language with a smaller pool of contributors than the
|
|
mainstream. Anyone who tells you a young tool has already won is selling
|
|
something.
|
|
|
|
So we don't intend to win by breadth. We intend to be *undeniably good* at one
|
|
thing first: running and operating real services on self-hosted and sovereign
|
|
clusters, with the robustness usually reserved for the big players, proven by
|
|
systems that actually work in the world. Our proof isn't a benchmark or a
|
|
funding round. It's a sovereign public-health data hub headed to a community in
|
|
Cameroon, with a university partner — a place where depending on a distant
|
|
hyperscaler isn't just expensive but a question of whose hands the data is in.
|
|
If Harmony can stand up *there*, robustly, owned locally, then the promise is
|
|
real. If it can't, no manifesto will save it.
|
|
|
|
## The ambition, kept humble
|
|
|
|
I don't think of this as building a company so much as removing a tax — the
|
|
quiet tax that infrastructure complexity levies on every person with an idea
|
|
and no platform team. If software is one of the great levers humans have for
|
|
helping each other, then the cost and lock-in of the ground it stands on is a
|
|
weight on that lever. Take the weight off, and you don't know in advance what
|
|
people will build — a greenhouse controller, a clinic's records, a town's own
|
|
small cloud — and that not-knowing is exactly the point. You don't pave a road
|
|
because you know who'll walk it. You pave it so they can.
|
|
|
|
That's all this is, really: an attempt to make the infrastructure sing — not
|
|
for a few, and not against them either, but for anyone who shows up — and to
|
|
leave behind a paved road to freedom for all software.
|
|
|
|
If we get it right, most people will never think about it. The water will just
|
|
run.
|