The App Ascends

The transit app built in Unit 9 goes to production in this unit's territory — served over the web, packaged in containers, orchestrated on a platform, deployed across a hybrid cloud — every choice drawn from the catalog this unit taught.

The city's app ships. Riders reach it three ways (0549): a single-page application in any browser (0546) — one load, then small exchanges over the encrypted wire (0570's trace, now in production) — a native app for riders who want the phone's sensors, and the web version doubling as the budget-friendly reach play. Behind the URL, Unit 9's microservices (0069) arrive dressed for the cloud (0552): each service in a container (0554), the standardized box that runs anywhere a runtime exists, and the fleet under orchestration (0555) — launch-day scaling, failed containers replaced, no human paging. The team's deployment choices walk the unit's ladders deliberately. Service model (0559): platform as a service (0561) — the city's developers push code while the provider patches servers — with one image-processing function on serverless (0563), the far end of the burden spectrum. Deployment model (0564): hybrid (0565) — fare-payment records on the transit authority's private side under fuller management rights, the rider-facing services public, workloads flexing across the seam. All four cloud-native principles (0553) are now visible in one system: the microservices from last unit, the containers and orchestration from this one, continuous delivery through the DevOps pipeline that Unit 9's process strand set up. The app that began as Unit 1's half-second of magic, became Unit 9's managed build, and now runs the way modern apps run — distributed, elastic, rented by the layer, and legible from top to bottom.