{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/paas","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/paas/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/paas/"},"term":{"en":"Platform as a service (PaaS)","da":"Platform as a service (PaaS)"},"aka":{"en":[],"da":[]},"domain":["platform"],"cluster":"cloud","layer":"infrastructure","status":"current","era":2008,"summary":{"en":"The cloud model where the provider runs the machines and operating system, and you only bring your own program and its data.","da":"Cloudmodellen, hvor udbyderen driver maskiner og styresystem, og du kun leverer dit eget program og dets data."},"body":{"formal":{"en":"A cloud service model in which the customer places its own programs on a platform the provider manages, without control over the underlying servers, operating system or storage, but with control over the programs and their settings.","da":"En cloud-servicemodel, hvor kunden lægger sine egne programmer på en platform, som udbyderen driver, uden kontrol over de underliggende servere, styresystem eller lager, men med kontrol over programmerne og deres indstillinger."},"plain":{"en":"Like renting a fully equipped restaurant kitchen - ovens, gas and cleaning are handled, and you just bring your recipes and ingredients.","da":"Som at leje et fuldt udstyret restaurantkøkken - ovne, gas og rengøring er klaret, og du kommer bare med dine opskrifter og ingredienser."},"inPractice":{"en":"A developer at a municipality puts the booking site for its sports halls on a managed platform; the provider keeps the servers patched, but the developer still decides who can log in and what the site shows the public.","da":"En udvikler i en kommune lægger bookingsiden til kommunens idrætshaller på en færdig platform hos en cloududbyder; udbyderen holder serverne patchede, men udvikleren bestemmer stadig, hvem der kan logge ind, og hvad siden viser offentligt."},"whyItMatters":{"en":"It moves the patching of servers to the provider, but flaws in your own program and its settings remain yours to fix.","da":"Den flytter patching af servere over til udbyderen, men fejl i dit eget program og dets indstillinger er stadig dine at rette."}},"deepDive":{"en":"NIST SP 800-145 describes PaaS as the capability to deploy consumer-created or acquired applications built with languages, libraries, services and tools supported by the provider, without managing the network, servers, operating systems or storage, but with control over the deployed applications and possibly the configuration of the hosting environment. The model took shape with Heroku (2007), Google App Engine (2008), the original Windows Azure (2010) and the open-source Cloud Foundry (2011). The twelve-factor app methodology, written at Heroku around 2011, codified the contract between application and platform: configuration in environment variables, stateless disposable processes, backing services as attached resources, logs as event streams.\n\nMechanically, source code is turned into a runnable artefact by buildpacks (today standardised as Cloud Native Buildpacks, a CNCF project) or by a container image supplied by the customer. The platform schedules instances, routes HTTP through its own load balancer, terminates TLS, scales horizontally on request rate or CPU and restarts crashed processes. Local file systems are ephemeral, so any state must live in a managed database, cache or object store. Managed data services (DBaaS, queues) are PaaS too, and serverless functions (AWS Lambda from 2014, Azure Functions, Google Cloud Functions) and serverless containers (Cloud Run) extend the model with scale-to-zero, per-invocation billing and cold-start latency.\n\nThe provider patches the OS and the language runtime, but only within supported runtime versions; when a runtime reaches end of support, the upgrade becomes a customer task. Everything bundled with the application remains the customer's: third-party dependencies from npm, NuGet or Maven, authentication and authorisation logic, input handling and secrets. Secrets placed in environment variables are readable by anyone with rights to read the app's configuration and leak easily through debug pages and crash dumps; references to a key vault via a managed identity are safer. Many PaaS offerings are internet-facing by default, with private endpoints and virtual-network integration as opt-in features, and an SSRF flaw can reach the platform's local identity endpoint (for example IDENTITY_ENDPOINT in Azure App Service) and obtain tokens for the app's managed identity.\n\nThe trade-offs are lock-in through proprietary runtimes and APIs, hard platform limits (request timeouts, memory caps, no custom kernel modules) and reduced audit visibility: host-level agents cannot be installed, so assurance for the lower layers comes from the provider's SOC 2 or ISO/IEC 27001 attestations. PaaS differs from IaaS in that the customer no longer owns the OS, and from SaaS in that the customer still owns the application code.","da":"NIST SP 800-145 beskriver PaaS som muligheden for at udrulle applikationer, som kunden selv har udviklet eller anskaffet, bygget med sprog, biblioteker, tjenester og værktøjer, som udbyderen understøtter, uden at drive netværk, servere, styresystemer eller lager, men med kontrol over de udrullede applikationer og eventuelt over konfigurationen af driftsmiljøet. Modellen tog form med Heroku (2007), Google App Engine (2008), det oprindelige Windows Azure (2010) og open source-projektet Cloud Foundry (2011). Twelve-factor app-metoden, skrevet hos Heroku omkring 2011, formaliserede kontrakten mellem applikation og platform: konfiguration i miljøvariabler, tilstandsløse processer, der kan smides væk, eksterne tjenester som tilkoblede ressourcer og logs som hændelsesstrømme.\n\nMekanisk bliver kildekoden omdannet til en kørbar artefakt af buildpacks (i dag standardiseret som Cloud Native Buildpacks, et CNCF-projekt) eller af et container-image, som kunden leverer. Platformen placerer instanser, router HTTP gennem sin egen load balancer, terminerer TLS, skalerer horisontalt efter antal forespørgsler eller CPU og genstarter processer, der går ned. Lokale filsystemer er flygtige, så al tilstand skal ligge i en managed database, cache eller objektlager. Managed datatjenester (DBaaS, køer) er også PaaS, og serverless-funktioner (AWS Lambda fra 2014, Azure Functions, Google Cloud Functions) og serverless containere (Cloud Run) udvider modellen med skalering til nul, afregning pr. kald og forsinkelse ved kolde starter.\n\nUdbyderen patcher styresystem og sprog-runtime, men kun inden for understøttede runtime-versioner; når en runtime når end of support, bliver opgraderingen kundens opgave. Alt, hvad der følger med applikationen, forbliver kundens: tredjepartsafhængigheder fra npm, NuGet eller Maven, logik for autentificering og autorisation, håndtering af input samt hemmeligheder. Hemmeligheder i miljøvariabler kan læses af alle med ret til at se appens konfiguration og lækker let via debug-sider og crash dumps; referencer til en key vault via en managed identity er sikrere. Mange PaaS-tjenester vender som standard ud mod internettet, med private endpoints og integration i virtuelle netværk som tilvalg, og en SSRF-fejl kan nå platformens lokale identitets-endpoint (fx IDENTITY_ENDPOINT i Azure App Service) og hente tokens til appens managed identity.\n\nPrisen er lock-in via proprietære runtimes og API'er, faste platformsgrænser (timeouts på forespørgsler, loft over hukommelse, ingen egne kernemoduler) og mindre indsigt ved revision: agenter kan ikke installeres på værten, så sikkerheden i de nederste lag må dokumenteres via udbyderens SOC 2- eller ISO/IEC 27001-erklæringer. PaaS adskiller sig fra IaaS ved, at kunden ikke længere ejer styresystemet, og fra SaaS ved, at kunden stadig ejer applikationskoden."},"edges":[{"type":"kind-of","to":"platform/cloud-computing","confidence":"high","strength":"normal"},{"type":"contrasts-with","to":"platform/saas","why":{"en":"With PaaS you run your own program on the provider's platform; with SaaS you only use the provider's finished program.","da":"Med PaaS kører du dit eget program på udbyderens platform; med SaaS bruger du kun udbyderens færdige program."},"confidence":"high","strength":"normal"}],"depth":0,"sources":[{"title":"NIST SP 800-145 - The NIST Definition of Cloud Computing","tier":"standard","publisher":"NIST"}],"draft":true}