Why would a team run a component itself on rented machines instead of using the provider's managed version?
answer
- portability is a property of the seam
- rent capacity, not the capability
- same software under any landlord
- a move becomes a restore, not a rewrite
- patching, backups and on-call come back
basics
~20 sRunning the component yourself keeps the software identical wherever the machines are rented, so a move becomes a reinstall and a restore rather than a rewrite. You pay for that with the patching, backups and on-call the managed tier was doing.
solid answer
~40 sA managed tier sells you the *capability*: the provider installs, patches, backs up and fails over the component, and you drive it through the provider's own control surface. Self-running sells you only machines. You install the same component yourself, so its configuration, its protocol, its on-disk format and its operational runbook are the same on anything that rents capacity. That is the portability argument - the seam sits **below** the platform, at the machine boundary, and a move means renting machines elsewhere and restoring the same software. The price is that everything the managed tier was doing silently - version upgrades, tested restores, failover, capacity headroom, security patching - returns to your team permanently, whether or not the move ever happens.
go deeper
Recall the two rungs: a managed tier sells you the running capability, while renting machines sells you only capacity. The portability argument is simply that software you installed yourself is the same software anywhere.
Explain where the seam sits. Self-running pushes the provider dependency down to machines, network and disks, so a move becomes a reinstall plus a restore instead of a rewrite of the surrounding integration.
Show what the seam costs continuously. Patching, version upgrades, tested restores, failover and capacity headroom return to your team every month, whether or not the move that justified them ever happens.
Frame it as buying an option and say what the option is worth. Fund the lower seam only where a plausible trigger exists and the team is already staffed to operate the component itself.
## Two ways to consume the same component A **managed tier** sells you a running capability. The provider installs the component, patches it, backs it up, replaces failed nodes and hands you an endpoint plus a **control surface** - a management API and a console - for creating, sizing, configuring and restoring it. What runs underneath may be a well-known component, the provider's own build of one, or an original design that merely looks familiar. You do not operate it, and mostly you cannot see it. **Self-running** the same component means renting only capacity. You take machines - the rung where the provider's responsibility stops at the hardware, the virtualisation layer, the physical network and the storage device - and you install, configure, monitor, patch and fail over the component yourself. The provider sells machines; the capability is yours to build and keep alive. ## Why the lower seam is the portable one Portability is a property of a **seam**: the line below which your system stops needing anything that only this provider has. Self-running drops that line to the machine boundary, and that has a specific, checkable consequence for a move. - The **configuration** is the component's own files or commands, not a provider console's fields, so it copies as-is. - The **protocol and client library** belong to the component, so application code is untouched by the move. - The **on-disk and backup format** is the component's own, so a move is a restore rather than an export, a transform and an import. - The **operational knowledge** - what its metrics mean, how failover behaves, which settings matter under load - travels with the team, because it was never knowledge about a provider. - What stays provider-specific is bounded: machine shapes and sizes, the private address range and its routing, the block storage attached to each machine, and the mechanism by which a machine obtains credentials. Compare the same move made from a managed tier. The component may be familiar, but everything built *around* it - how it is created, how it is sized, how it is backed up, who may call it, what it emits as telemetry, how it is upgraded - is the provider's design, and none of that design exists on the next platform. | What a move touches | Managed tier | Self-run on rented machines | |---|---|---| | Application code | rewritten where the interface is proprietary | unchanged: same component, same protocol | | Configuration | recreated in the new platform's control surface | the component's own files, copied | | Data | exported and imported through the platform's tooling | restored from the component's own backup format | | Operational knowledge | relearned for a new control surface | carried over intact | | Still provider-specific | essentially the whole surrounding design | machine shapes, network, disks, credential delivery | ## What the seam costs, continuously None of this is free, and the bill is not a one-off. Everything the managed tier was quietly doing comes back to you: 1. **Patching and version upgrades.** Security patches are routine; a major version upgrade of a component that owns data is a project, and it is now yours to plan, rehearse and run. 2. **Backups that have actually been restored.** Taking a backup is easy. A *tested* restore, with a known recovery point objective and recovery time objective, is the work. 3. **Failure handling.** Replacing a lost machine, promoting a standby and deciding when to fail over become decisions your on-call makes under pressure. 4. **Capacity.** Headroom, scaling steps and the storage growth curve are yours to watch, and running out is your outage. 5. **Security posture.** Network exposure, authentication settings, encryption configuration and audit output are configured by you rather than defaulted by the provider. That cost is charged every month whether or not you ever move. The honest framing is therefore that self-running **buys an option**, and the option carries a running premium. It is a good buy where the team is already staffed to operate that component, where a managed tier lacks a version, extension or setting you genuinely need, or where enough services depend on it that the alternative rewrite would be large. It is a poor buy where a small team adopts a data-owning component purely because a move is imaginable. ## What self-running does not do It does not remove the provider. The machines, the private network, the disks, the quotas that cap how many machines you may launch and the identity mechanism that hands those machines credentials are all still rented. The seam moved **down**, not away - which is exactly the point, because what remains above it is small, well understood and describable in a day rather than a quarter.
- Does self-running the component remove every provider-specific dependency?No. You still depend on machine shapes, the private address range, block storage, the quotas that cap how much you can launch, and the mechanism that gives a machine its credentials. The seam is lower, not absent. What changes is the size of the move: from rewriting an integration to re-creating a bounded set of infrastructure and restoring data.
- If the team never actually moves, was the self-run seam wasted?Not necessarily, but be honest about the accounting: you bought an option and paid an ongoing operations bill for it. That is a fair trade where the team is already staffed to run the component, or where the managed tier lacks a version or setting you need. Where neither holds, the managed tier is usually the better buy.
- Which parts of the operating burden do teams most often underestimate?Tested restores and major version upgrades. Both are rare, both were being done quietly by the managed tier, and both surface only when they fail. Running a healthy component day to day is usually easy; it is the upgrade path and the restore nobody has rehearsed that consume the engineer-months nobody budgeted.
saying these in an interview costs you the question
- Claims a managed tier is portable because the component underneath is a well-known one
- Thinks self-running removes the provider dependency entirely, forgetting machines, network and disks
- Assumes the portable seam is free once the component has been installed
- Treats a backup taken by the platform's own tooling as restorable onto another provider
- Says self-running is always cheaper because you only pay for machines