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.

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?

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...

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.

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.

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)

...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.

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.

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.

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