Referenceplatform

Hvad denne side er

#

Dette er den korte version af den målplatform, vi typisk hjælper kunder med at designe og levere. Det er ikke en standardskabelon, men den følger baseline i vores arkitekturnoter: en T Cloud konto som udgangspunkt, Enterprise projekter som hovedgrænse og et delt platformfundament, der kun udvides, når designet kræver det.

Kernestruktur

#

• Grænsemodel — En T Cloud konto som udgangspunkt, med Enterprise projekter som den primære grænse for rettigheder, ejerskab og omkostninger.
• Obligatoriske platformprojekter — platform-management til den delte platformdrift og platform-connectivity til delt routing, DNS, edge og perimeterkontroller.
• Betingede platformprojekter — platform-identity kun når et selvhostet identitetslag som Authentik faktisk er nødvendigt, og platform-security kun når sikkerhedsværktøjer eller retention-grænser retfærdiggør det.
• Leverancevej — Platform- og workload-ressourcer defineres gennem Git, OpenTofu, CI/CD og policy checks, så driftsmodellen forbliver deklarativ og reviewbar.

Delte platformtjenester

#

• Netværk og DNS — platform-connectivity ejer som udgangspunkt delt routing, delte DNS-zoner, hybrid forbindelse og perimeterkontroller.
• Ingress og edge-kontroller — Delt edge er til reelt delte platformtjenester. Offentligt eksponerede workloads ejer normalt deres egen offentlige edge i deres eget projekt, med WAF til offentlig HTTP- og HTTPS-ingress.
• Runtime-baseline — PaaS-first i platform-management med OBS, CES/LTS, SMN, CTS, FunctionGraph og SWR. Git og CI/CD forbruges fra Fremforge på frem.sh, så en delt containerplatform er ikke nødvendig ved bootstrap.
• Automatisering først — FunctionGraph-first til letvægtsautomatisering og eventdrevne jobs. Kubernetes, forvaltede tjenester eller virtuelle maskiner tilføjes, når workloaden eller tjenesten faktisk har brug for dem.

Sikkerheds- og kontrollag

#

• Politikker og governance — Guardrails, least-privilege adgang, tagging og compliance-orienterede checks bygges ind i baseline i stedet for at blive tilføjet senere.
• Identitet og adgang — Menneskelig adgang fødereres som udgangspunkt fra virksomhedens identitetsudbyder, med lokal break-glass-adgang bevaret og automation scoped gennem agencies.
• Nøgler, secrets og sporbarhed — Forvaltede nøgle- og secrets-tjenester er den primære kilde til nøgler og platformsecrets, mens revisionsspor på API-niveau giver sporbarhed og auditmulighed.
• Backup og recovery — Backupdækning, retention, restore-veje og rebuild-from-code-forventninger er defineret for delte tjenester og kritiske workloads.

Driftsmodel

#

• Overvågningsbaseline — Metrics, logs, alarmer, notifikationer og revisionsspor udgør baseline for overvågning og audit, med platformalarmer for ingress, Fremforge-tenantens tilgængelighed, backup og nøgleafhængigheder.
• Runbooks og overdragelse — Praktiske driftsprocedurer, så platformen kan ejes efter leverancen.
• Hybrid overgang — Plads til, at eksisterende identitet, netværk og forretningssystemer kan blive, hvor de er, mens målbilledet bygges ud.
• Kompetenceopbygning — Leverancen designes, så kundens team bliver mere kapabelt, i takt med at platformen modnes.

Hvad der typisk ændrer sig først

#

Det første nyttige skridt er sjældent “flyt alt”. Det er som regel en eller flere af disse:

• En tydeligere Enterprise Project- og governance-baseline
• En mere forsvarlig leverancevej for kildekode og CI/CD
• Bedre identitets- og adgangsgrænser
• En første suveræn workload-platform med overvågning, backup og perimeterkontroller bygget ind
• En migrationsvej for de workloads, der betyder mest

Hvor går man videre herfra

#

Hvis du først vil have svar på de praktiske køberspørgsmål, så læs FAQ.

Hvis du vil drøfte, hvordan det her passer til jeres nuværende landskab, så tag fat i os.