Interview

Schrems II-frygt får Danmarks største pensionsselskab til at træde på cloud-bremsen

9. september 2022 kl. 04:009
PFA hovedkvarter
Illustration: Kasper Palsnov/Ritzau Scanpix.
Usikkerhed om brug af amerikanske cloud-platforme får PFA til at træde på bremsen for nye projekter. »Vi har kun meget begrænsede løsninger i drift på nuværende tidspunkt.«
Jakob Schjoldager
Jakob Schjoldager
Journalist
Artiklen er ældre end 30 dage
Jakob Schjoldager
Jakob Schjoldager
Journalist

I mere end to år har én bestemt afgørelse fra EU-domstolen skabt rystelser i it-afdelinger over hele landet.

Det handler naturligvis om Schrems II-afgørelsen, der har sat alvorlige spørgsmålstegn ved brugen af amerikanske cloud-giganter.

Kommuner, regioner og andre offentlige myndigheder har selvsagt store problemer med afgørelsen, men den skaber også benspænd for det private erhvervsliv.

Log ind og læs videre
Du kan læse indholdet og deltage i debatten ved at logge ind eller oprette dig som ny bruger, helt gratis.
Opret brugerLog ind
9 kommentarer.  Hop til debatten

Jobs

Dine job
Vis alle

Fortsæt din læsning

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
8
Johnny Lüchau
12. september 2022 kl. 18:15

Hvorfor skriver journalisten "...den uafklarede situation omkring Schrems II"?

Der er mig bekendt ikke noget der er uafklaret vedr. Schrems II.

Hvis vi skal til at betale for at læse Version2, slipper vi så for den slags vildledning?

  • more_vert
    • insert_linkKopier link
7
Dennis Benneballe Arnold-Grade
12. september 2022 kl. 14:54

Kom til at tænke på NIS-II direktivets definition på Cloud Computing Services: "digital services that enable on-demand administration and broad remote access to a scalable and elastic pool of shareable and distributed computing resources"

Med den definition er det i hvert fald ikke kun Google, AWS og Azure, som er clouds...

  • more_vert
    • insert_linkKopier link
1
Klavs Klavsen
9. september 2022 kl. 11:46

Suk. Som om Cloud KUN er Azure, Google og Amazon.. :( Der er tonsvis af gode europæiske leverandører og hvis man havde lidt fornuft baserede man sig på Kubernetes som fælles platform - både on-premise og i cloud - på den måde kan man frit køre præcis samme setup flere steder, efter behov.

Scaleway og Hetzner f.ex. er 2 store cloud udbydere.. Scaleway har også managed Kubernetes, hvis man ikke selv vil stå for det

  • more_vert
    • insert_linkKopier link
6
Nicolai Birkmose Oksen
12. september 2022 kl. 07:46

Tror ofte det kommer ned til det komplette valg af muligheder. F.eks. har Azure deres CosmosDB, det er ikke lige til at genskabe selv. Men er helt enig i at det er en skam at Cloud oftes forbindes med de 3 store amerikanske virksomheder.

  • more_vert
    • insert_linkKopier link
2
Palle Simonsen
9. september 2022 kl. 16:44

Uden at kende PFA's Use Cases er Cloud andet og langt mere end standardiseret compute (k8s) eller 1:1 datacenter erstatning og selv hvis man bruger standardiserede IAC løsninger (Terraform) kan man ikke 'bare lige' flytte en veldesignet Azure løsning til fx. AWS eller tilbage til on-prem for den sags skyld. Når det er sagt kan man meget på k8s - bevares - men ikke alt.

  • more_vert
    • insert_linkKopier link
4
Rune Hansen
11. september 2022 kl. 00:07

Helt enig med Maciej Szeliga her.

Vendorlocking på så foretningskritisk et område, svare jo til at man i driften besluttede sig for at singlepoint of failure var en efterstræbelsesværdig ting.

I min optik er det uvidenhed og en naiv tilgang til IT, som noget man ikke ser som en inhouse opgave. Det er noget der sker når gamle mænd, bilder sig ind at deres konkurrenceevne og kernekompetance ikke skal ligge i IT afdelingen. (Naturligvis skal den det, når vi snakker large CAP)

  • more_vert
    • insert_linkKopier link
5
Palle Simonsen
11. september 2022 kl. 21:35

Jeg vil sige det er naivt at tro man kan undgå lock-in. Alle IT arkitekter ved dette og balancerer derfor forskellige former for lock-in's i arkitekturvalg og veldesignede, balancerede arkitekturer.

Lad os da kort se på Lock-in med genbrug af Gregor Hophe's klassifikation:

  • Vendor lock-in, Den kender vi alle. Afhængighed til (et udvalg af) en bestemt leverandørs produkter. Ofte det eneste der nævnes, når talen falder på lock-in.
  • Product lock-in, Fx. afhængighed af store closed-sorce suiter men også Open Source produkter som fx. k8s, cassandra, kafka, linux - herunder bestemte distributioner af disse.
  • Version lock-in, Fx. svært at flytte fra Flutter 1.2 til 2.x, Fra Angular 1.x til 2,3,4, ... etc. Fra Windows xx til yy. Ofte breder den slags sig så der er større dele af IT der ikke lige kan opgraderes.
  • Arkitektur lock-in, Fx. microservices måske baseret på k8s. Man koder ikke lige sit compute om til serverless, selvom det måske i bagklogskabens klare lys havde været et bedre valg.
  • Platform lock-in, Og nu er vi ved Cloud diskutionen. Man kan prøve at reducerer afhængighederne til en bestemt Cloud platform for at minimerer eller undgå login, men man risikerer at beskære mulighederne så meget, at man reelt ikke får tilstrækkelig værdi af investeringen og/eller anvendelsen bliver unødig besværlig.
  • Skills lock-in, Man træner ikke bare sine udviklere eller driftsfolk om fra xxx til yyy - altså en afhængighed af eksisterende 'skills'.
  • Legal lock-in, Fx. compliance. Bestemte løsninger, produkter etc. kan ikke anvendes af compliance årsager - uanset hvor meget man måtte sympatiserer med begrundelserne for compliance er det også et lock-in.
  • Mental lock-in, Den har de fleste: 'sådan har vi altid gjort', 'det plejer at gå galt', 'xxx er bare ny vin på gamle flasker', 'yyy kommer aldrig til at virke'

En velgennemtænkt arkitektur vil bestå af en række gode arkitekturvalg herunder også en bevidst stillingtagen til lock-in. Man kan forholde sig til hvilke lock-in's man har eller vælger at have men som sagt er det naivt at tro at en arkitektur kan være uden lock-ins.

  • more_vert
    • insert_linkKopier link
9
Rune Hansen
12. september 2022 kl. 22:02

Jeg er da dybest set enig med dig i, at afhængighed af diverse leverandører og produkter er et relativt begreb. Jeg har nok bare den filosofi at en virksomheds overlevelse ikke må være afhængig af én enkelt underleverandør. eks. vis at ens betalingsløsning ikke hurtigt kan udskiftes til en anden, osv., det samme med ens hosting provider og MSP'ere.

Ikke nødvendigvis pga. fejl, konkurs osv., men for at være konkurrencedygtig og have mulighed for at udsætte leverandøren for konkurrence. Med de priser de tager for en server hos Azure, så nyder de tydeligvis godt af at folk ikke kan slippe væk.

  • more_vert
    • insert_linkKopier link
3
Maciej Szeliga
10. september 2022 kl. 11:56

...er Cloud andet og langt mere end standardiseret compute (k8s) eller 1:1 datacenter erstatning og selv hvis man bruger standardiserede IAC løsninger (Terraform) kan man ikke 'bare lige' flytte en veldesignet Azure løsning til fx. AWS eller tilbage til on-prem for den sags skyld. Når det er sagt kan man meget på k8s - bevares - men ikke alt.

Hvilket så gør at clouden ikke er brugbar til kritiske opgaver.

For mig lyder din "veldesignet" til fejldesignet hvis det betyder den kun kan køre i Azure - en del af veldesignet betyder nemlig at den er flytbar og ikke har vendor lock-in.

Alle er lige nu ved at få grå hår i hovedet over den detalje.

  • more_vert
    • insert_linkKopier link