Architecture bends around what you won't change
Designing around components you can't control means picking which side holds the workaround. The one you refuse to change shapes everything else.
Friction doesn't disappear when you design around it. It moves.
Every system has components you govern and components you don't. When they disagree, one side has to carry the extra work. Try to make the ungoverned side comply, and the work comes back as a config pushed to another device, a workaround shipped for another partner, due again on the other side's schedule.
The design decision is which component absorbs the friction. Once you decide one component costs too much to change, every other component has to bend around it.
The side you don't govern sets the rate
The other side can add the workaround. You can't require it or check that it survived the last update. The only fix you can rely on is the one you maintain.
The device that settles this is the one with no mechanism to comply at all. Not a setting buried somewhere, not a policy you could push. The capability is absent, and every plan whose last step is "roll it out everywhere" dies on that one device.
When every instance requires a workaround, the bill grows with three factors: the cost of each change, the size of the population, and how quickly that population turns over. You control the first. The other side sets the population and the churn, which is why the total can grow even while every individual fix stays small.
A self-signed certificate can secure a connection with the same keys and ciphers as a publicly trusted one. The client rejects the identity, not the encryption. The refusal is correct, and it doesn't bend for a private network. To fight it, you distribute a custom root to every device, and again to every device that arrives after. The alternative is a wildcard certificate from a public authority the clients already trust. One certificate covered 20 to 30 internal services with no client configuration, and renewals were managed from a single governed point.
When the workaround is smoother than the intended path, the friction sits on a side that can't absorb it. A warning that gets clicked through every day has already lost the argument. Whoever clicks through overrules the design one instance at a time, and nothing records the verdict.
Put the fix where one owner can keep it working
Put the workaround behind one control point, and the population stops multiplying it. The certificate still expires, and the proxy still needs monitoring, but you can keep both on your schedule and monitor them in one place. In a homelab built this way, the public DNS provider that the renewal proves ownership with matters only during the renewal window, and every other hour the names resolve locally.
The component that hurts and the one that can fix it are usually different. Warnings appear on clients while the fix lives on the proxy.
Scatter the workaround, and stale copies fail one by one, each discovered by the person whose device it breaks on. Put it behind a single control point, and the whole system can fail at once. That trade only works when someone owns the logs and the uptime target.
Someone has to operate the control point. It becomes infrastructure the moment the first client depends on it. The maintenance once scattered across the population lands on one team. In return, failures appear alongside the logs, and one fix reaches every client.
The control point keeps one supplier on the ungoverned side, though. The public authority sets how long the certificate is valid, and a shorter lifetime resets the renewal cadence at the proxy to a schedule its owner never chose.
The boundary doesn't need to be one you can touch. If a partner controls the export format, keep the adapter on your side. Their format can change on their schedule without forcing every consumer to change with it.
"Can't change" usually means "costs too much to change"
A few components are immovable: another company's systems, a protocol frozen by everyone who already speaks it. The rest are movable at a price, and the price is usually distribution. The change is one line, and that line has to apply to every instance of a population that churns. Even where a custom certificate authority is technically available, its root still has to reach every device, forever. The component you "can't change" is usually the component you've priced and declined to pay for.
You can control it and still leave it alone
You can control both components and still have only one worth changing. Control answers what you may change. Price answers what you should.
A workload that needs a fast-moving kernel can't run a backup agent built for a stable one. A small container exposes the data through read-only mounts over an interface the backup system already speaks, so no backup agent runs on the host. The kernel can move while the backup interface stays put.
When the same fix keeps coming back, redo the math
First try to delete the mismatch. When both sides can adopt the same standard, or when the requirement that created the conflict can be dropped, the friction disappears, and that is the cheapest it will ever be. Absorb what survives that attempt.
The same fix keeps coming back: one more device configured, one more exception added, one more warning clicked through. The bill scales with whichever side carries it. Whoever made the first estimate may have counted one fix even though the system keeps buying it for every device. Run the numbers again. Count how many places carry the workaround and how often those places change. Keeping it there may still be cheaper. The decision no longer rests on the old price.
The warning appears on the client. The architecture decision lives at the proxy.
