Moving one service from plain machines to a container platform to an event-driven runtime - what changes about the unit you hand over?

## The packaging unit is the contract The **packaging unit** is the artifact you hand the platform and the shape the platform expects it in. It sounds like a build detail, and it is actually the clause that decides most of the rest: who starts the process, what listens for work, when the process may stop, what else can sit beside your code on the host, and who patches underneath it. Choose the unit and you have chosen the surrounding contract. ## What each tier takes | Tier | What you hand over | What the platform then decides | |---|---|---| | Plain machines | Nothing - you install the process on a machine you rented | Little above the hardware and its virtualization | | Managed container platform | A container image plus a declaration of how to run it | Placement, restart, instance replacement, and the networking around it | | Event-driven runtime | A handler with a defined entry point, plus its dependencies | The process itself: when it starts, how long it may run, when it goes away | | Fully managed application tier | Source or a build artifact plus a little configuration | The build, the start command, the routing in front, and the patching under | Read the table as one movement. The artifact gets smaller left to right, and the right-hand column gets longer by exactly what the artifact stopped carrying. ## What you stop deciding as the unit shrinks - **Process supervision** - what restarts the process, how quickly, and how many times before it gives up. - **What listens for work** - on the smaller rungs you no longer own a listening socket; the platform accepts the request or the event and calls your code. - **When a process starts and stops** - on the event-driven rung the platform decides both, and neither is tied to your deploy. - **What shares the host** - a smaller unit means denser packing with other tenants' work, on the provider's terms. - **How anything outside the artifact arrives** - a system library, a native tool, a font, a certificate. On a machine you install it; in an image you build it in; on the smaller rungs you have to fit it into the unit the runtime accepts, or do without. ## Why a move between tiers is a repackaging, not a redeploy 1. **The entry point changes.** A long-running server that binds a port and loops is a different program from a handler the platform calls per unit of work, even when the business logic between them is identical. 2. **The assumptions around the entry point change.** Anything the service did at start-up and then relied on for hours - a warmed cache, an open pool, a background timer - has to be re-thought when the process no longer belongs to you. 3. **Everything outside the artifact has to be re-supplied in the new unit's terms**, which is where migrations actually stall: a dependency that was simply present on a machine now has to be expressed as part of the unit. A useful test in a review: if the change is a configuration edit, it is a redeploy; if the change alters what the entry point *is*, it is a repackaging, and it should be estimated as one. ## The trade nobody states out loud A smaller unit is often sold as less work, and it is less *host* work: you stop patching, supervising and sizing a machine. But it is more *fit* work. The platform's contract is fixed, so any part of your service that does not match it has to change, and you inherit the platform's opinions - its build conventions, its idea of how an application starts, its lifecycle. A build convention that shifts can break a deploy in which your code did not change at all. That is a genuinely good trade for a small, well-shaped service and a poor one for a service with unusual host needs. There is also a direction-of-travel asymmetry worth naming. Moving *down* the list (larger unit to smaller) forces your service to satisfy more constraints. Moving *up* hands you back the constraints as responsibilities: nothing now supervises the process unless you arrange it. Neither direction is free, and teams routinely budget for the first and are surprised by the second. ## What an interviewer is listening for - Naming the actual artifact per rung, not describing the tiers by how modern they feel. - Connecting the unit to the consequence: what the platform now decides that you used to. - Recognising a tier move as a repackaging with an estimate attached. - Resisting the claim that the smallest unit is always the least work.