Om noget mangler hos en europæisk udbyder, afhænger af, hvad I bruger i dag, og svaret findes ved at holde jeres egen liste over tjenester op mod udbyderens katalog, kategori for kategori. Når noget mangler, har I tre muligheder: driv det selv, køb det hos en tredjepart, eller lad systemet blive, hvor det er.
Der findes ingen kilde, vi kender, der sammenligner tjenesterne hos de store og de europæiske udbydere én til én, og vi har ikke selv undersøgt, om to tjenester med samme formål kan det samme. Derfor er dette en metode og ikke en tabel over mangler.
Hvorfor katalogernes størrelse ikke siger det
Udbyderne opgiver selv deres kataloger, og de tæller forskelligt. Én skriver over 40 tjenester, en anden over 100 produkter og tjenester, en tredje over 80 løsninger. Nogle tæller hver databasemotor for sig, andre samler dem. Et stort katalog fortæller ikke, om netop jeres tjenester er med. Et lille katalog kan dække alt, hvad et miljø med virtuelle servere og containere har brug for.
Begynd derfor i den anden ende, med det, I faktisk bruger.
Trin 1: Lav jeres egen liste
Træk forbruget ud af jeres nuværende konti eller abonnementer, og skriv hver tjeneste op med navn, hvad den bruges til, og hvilke systemer der afhænger af den. Fakturaen er et godt sted at begynde, fordi den viser alt, der koster noget. Driftsfolkene ved, hvad der ikke står på fakturaen, fx indbyggede funktioner, der følger med andre tjenester.
Søger I et europæisk alternativ til AWS Lambda eller et Azure-alternativ til S3-lager, er det den samme øvelse. Navnet på den tjeneste, I bruger i dag, er udgangspunktet, og formålet er det, I leder efter.
Trin 2: Sorter efter seks kategorier
Beregning. Virtuelle maskiner, dedikerede servere, GPU og funktioner, hvor udbyderen kører jeres kode, og I ikke har nogen server at passe. Virtuelle maskiner findes i alle de europæiske kataloger, vi har læst. Funktioner uden server er sjældnere og skal slås op særskilt.
Lager. Blok-, fil- og objektlager. Objektlager med en S3-kompatibel grænseflade er udbredt, og en kompatibel grænseflade kan stadig opføre sig anderledes. Læs S3-kompatibel.
Database. Administrerede databaser med åbne motorer som PostgreSQL og MariaDB findes hos flere af de europæiske udbydere. Udbydernes egne databaser uden en åben motor har sjældent et modstykke, der kan læse samme data direkte.
Identitet. Hvem der logger ind, og med hvilke rettigheder. Jeres brugerkatalog, adgangen til platformen og adgangen for systemer imellem er tre ting og skal ses hver for sig.
Nøgler og hemmeligheder. Nøglehåndtering, hemmelighedslager og certifikater. Hvem der har nøglerne, er også et suverænitetsspørgsmål.
Overvågning. Målinger, logs, sporing og alarmer. Mange miljøer bruger udbyderens indbyggede overvågning uden at tænke over det, og den forsvinder ved et skifte.
Trin 3: Marker hver tjeneste
For hver tjeneste på jeres liste skriver I et af fire mærker ud for den udbyder, I ser på:
- Findes. Udbyderen har en tjeneste med samme formål og en kompatibel grænseflade eller åben motor.
- Findes med forskelle. Formålet er det samme, men grænseflade, grænser eller funktioner er anderledes og skal prøves.
- Mangler. Udbyderen nævner ikke en tjeneste med det formål.
- Uafklaret. Kataloget siger ikke nok. Spørg.
Brug udbyderens egen produktoversigt og dokumentation med dato. Udbyderartiklerne på udbydersiden giver et udvalg, men ikke hele kataloget.
Trin 4: Hvad I gør, når noget mangler
Driv det selv. Mange tjenester kan erstattes af åben software, I driver på virtuelle servere eller i Kubernetes. Det giver frihed og flytbarhed, men det koster driftstimer hver måned, og nogen skal have vagten.
Køb det hos en tredjepart. En specialiseret leverandør kan levere fx overvågning, identitet eller backup ved siden af infrastrukturen. Det giver en kontrakt mere og et led mere, der også skal vurderes på ejer og placering.
Lad systemet blive. Hvis et system bygger tungt på en tjeneste uden modstykke, kan det rigtige være at lade det blive og flytte resten. Læs delvis flytning og det, der ikke skal flyttes.
Den fjerde mulighed er at bygge systemet om, så det ikke længere har brug for tjenesten. Det er et udviklingsprojekt og hører til i flyt, tilpas eller byg om.
Hvad det kræver, og hvad det koster at lade være
Listen over jeres tjenester tager en til tre dage for en arkitekt med adgang til fakturaer og konti, afhængigt af miljøets størrelse. Markeringen mod én udbyder tager en dag. Hver tjeneste, der står som mangler, skal have en beslutning med et overslag i driftstimer pr. måned eller i projektuger.
Uden listen bliver valget af udbyder truffet på en fornemmelse af katalogets bredde. Mangler opdages under flytningen, hvor de koster mest, fordi systemet allerede er halvt flyttet, og det gamle miljø skal køre videre.
Det skal I lade være med
- At sammenligne antallet af tjenester · tallene tælles forskelligt og siger intet om jeres behov.
- At markere en tjeneste som fundet ud fra navnet alene · samme navn kan dække forskellige grænser.
- At glemme de tjenester, der ikke står på fakturaen · overvågning og identitet følger ofte med andre tjenester.
Det skal valget kunne vise
- ☐ En liste over alle tjenester, I bruger i dag, med systemerne, der afhænger af dem.
- ☐ Et mærke pr. tjeneste og udbyder, med dato for opslaget.
- ☐ En beslutning for hver manglende tjeneste: selv, tredjepart, bliv eller byg om.
- ☐ Driftstimer pr. måned for det, I selv overtager.
Senest gennemgået: november 2026.
Næste skridt
Træk jeres seneste faktura fra cloududbyderen, og lav listen ud fra den.
Læs også: Applikationer bygget på udbyderens egne tjenester · Europæisk public cloud
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
