Rented Platform Shape

## Both shapes are bounded, by different things The tempting model is that a fleet you run is limited and a rented fleet is not. That is wrong, and it leads to bad design conversations. **Both are bounded.** What differs is what the bound is made of: - A fleet you run is bounded by **the machines and operating systems you can own, license and administer**. - A rented fleet is bounded by **the machines and operating systems somebody else has racked**, and by **what your own network is willing to expose to them**. Neither bound is a configuration setting, which is why neither one can be argued away in a design review. ## Why a Linux container grid stops where it does A container shares the kernel of the host it runs on. A Linux host runs Linux containers, and a Linux container runs software built for Linux. Within that, a container grid is excellent: - Chromium-family browsers, headless or driven inside a virtual display. - Firefox builds, the same way. - Whatever else the image carries — fonts, locales, a window manager, a recorder beside the browser. And it stops, hard, at anything that is not Linux software: - **Apple's Safari** runs on Apple's operating systems, which are licensed to run on Apple hardware. Note the precision, because this is where people overstate: a *WebKit-based browser build* is not the same thing as Safari, and such builds exist on other platforms. Safari itself — the browser your users actually open — needs an Apple machine. - **A browser that ships only for Microsoft Windows** needs a Windows machine, licensed and administered as such, whether physical or virtualised. - **A real handset** is hardware: a battery, a radio, a screen, a physical object somebody keeps charged in a rack. None of those becomes reachable by editing configuration on a Linux host. That is the entire content of "what a shape can physically reach", and it is a platform fact rather than a tooling one. ## What renting changes about the bound Operating the machine estate is the provider's business, so that estate can be broader than any customer would build for itself — Apple machines, Windows machines, racked hardware, and the people who keep them running. Renting therefore moves the bound outward. The honest statement stops there. **What a specific provider actually offers, on what hardware, and for how long, is a property of that provider** — something to establish by asking and by trying, never to assume from the category. A suite that quietly depends on a target remaining available has taken an undocumented dependency, and those surface at the worst possible moment. ## The bound that runs the other way Renting also introduces a limit a self-run grid does not have. A grid inside your network sits where your applications sit; a rented browser does not. A build of the seat-reservation site deployed only where your own network can resolve and route to it is not reachable from a browser on somebody else's estate, and no setting or request fixes that — it needs a mechanism connecting the two sides, a topic in its own right. So the comparison is not "limited versus unlimited". It is a swap: you trade a limit made of hardware you would have to own for a limit made of hardware someone else owns plus a reachability problem you did not previously have. | Target for the seat-reservation suite | Self-run Linux container grid | Rented fleet | |---|---|---| | A Chromium-family build | natural fit | ordinarily available | | A Firefox build | natural fit | ordinarily available | | Apple's Safari | needs Apple machines you own and run | needs the provider to have racked them | | A real handset | needs hardware you rack and charge | needs the provider to rack and charge it | | A build deployed only inside your network | reachable, the grid is already inside | not reachable without connecting the sides | ## How this shows up in a real decision The railway's seat-reservation suite covers a booking flow customers reach from desktop browsers and phones. Walk the targets: 1. The Chromium-family and Firefox coverage runs on either shape, so it does not discriminate between them. 2. Apple's Safari decides the question, because a Linux container grid cannot host it at all. Either the organisation buys and administers Apple machines, or the browsers come from somewhere that already has them. 3. Real handsets decide it more sharply still, because hardware does not virtualise into existence. 4. The environment under test decides the direction back: if the build is only ever deployed somewhere publicly resolvable, the rented browser reaches it directly; if it lives inside the corporate network, something has to bridge that gap before any rented browser sees a page at all. None of those is an argument about cost, vendor quality or contract terms. They are statements about what can physically run where, which is why they belong at the front: they narrow the field before the judgement questions get asked. ## The answer to give Say that both shapes have a wall; name what each wall is made of; give the example that decides most real cases: that Apple's Safari and real hardware cannot be hosted on Linux by configuration; then add the reverse limit, that a rented browser stands outside your network and cannot see what only your network can resolve. That is a complete answer, and every part of it is checkable without assuming anything about a particular supplier.