Vendor lock-in zaczyna się od braku języka do rozmowy o architekturze

1 godzina temu
Zdjęcie: vendor lock in, chmura


Vendor lock-in najczęściej nie jest skutkiem jednej złej decyzji. Powstaje stopniowo, gdy kolejne elementy środowiska technologicznego zaczynają zależeć od własnościowych interfejsów, usług zarządzanych, modeli danych i kompetencji związanych z jedną platformą, a koszt ich późniejszego rozdzielenia pozostaje poza rachunkiem ekonomicznym projektu.

Dane z brytyjskiego rynku chmurowego dobrze pokazują skalę tego mechanizmu. Competition and Markets Authority ustalił w 2025 r., iż mniej niż 1 proc. klientów zmienia dostawcę chmury w ciągu roku. Korzystanie z kilku platform jest częstsze, szczególnie wśród największych organizacji, ale choćby tam większość wydatków pozostaje skoncentrowana u jednego głównego dostawcy. CMA wskazuje zarówno na bariery komercyjne, jak i techniczne: różnice między funkcjami i interfejsami usług, problemy z integracją, braki kompetencyjne oraz koszty transferu danych.

Sama rzadkość migracji nie dowodzi oczywiście, iż każda z nich jest blokowana przez vendor lock-in. Klienci mogą po prostu nie mieć powodu do zmiany. Istotniejsze są dane pokazujące, co dzieje się wtedy, gdy taka potrzeba już się pojawia.

W badaniu przygotowanym dla Ofcom 43 proc. respondentów wskazało czas i koszt zmiany jako jedną z barier pełnego przejścia do innego dostawcy. Około 70 proc. wskazało co najmniej jeden problem techniczny: interoperacyjność, przenośność aplikacji, przenośność danych albo konieczność przekwalifikowania pracowników. 52 proc. badanych uznawało brak interoperacyjności między usługami IaaS i PaaS za istotny problem rynku.

To przesuwa dyskusję o lock-inie z kontraktów na architekturę.

Umowę można wypowiedzieć. Architektury nie da się wypowiedzieć

Dwa przedsiębiorstwa wydające podobną kwotę u tego samego dostawcy mogą znajdować się w zupełnie innej sytuacji. W jednym przypadku zmiana platformy będzie głównie projektem infrastrukturalnym. W drugim wymusi modyfikację aplikacji korzystających z własnościowych baz danych, API, usług bezpieczeństwa, systemów tożsamości, mechanizmów observability czy narzędzi AI.

Ofcom wskazuje wprost, iż stopień integracji z usługami własnościowymi jest jednym z podstawowych czynników określających techniczny wysiłek potrzebny do migracji. Jeden z badanych klientów, mimo stosowania otwartych standardów i API, deklarował konieczność przeprojektowania aplikacji przy zmianie dostawcy; opisywana migracja trwała już sześć miesięcy.

W takim środowisku nominalna możliwość odejścia kilka mówi o rzeczywistej swobodzie wyboru. najważniejszy staje się nie zapis o wypowiedzeniu umowy, ale liczba komponentów, które trzeba byłoby przepisać, zastąpić albo ponownie certyfikować.

W czerwcu 2026 r. Komisja Europejska, przedstawiając wstępne stanowisko dotyczące AWS i Azure na gruncie Digital Markets Act, wskazała właśnie na efekty lock-in, wysokie koszty zmiany oraz rozbudowane ekosystemy jako elementy wzmacniające pozycję obu platform na europejskim rynku cloud.

Neutralność również kosztuje

Odwrotna strategia nie jest darmowa. Projektowanie każdej aplikacji tak, aby mogła zostać przeniesiona między kilkoma chmurami, oznacza dodatkowe warstwy abstrakcji, narzędzia integracyjne i kompetencje. Ofcom zwraca uwagę, iż utrzymywanie architektury multi-cloud może samo zwiększać koszty właśnie przez konieczność obsługi adapterów i dodatkowej warstwy technologicznej.

Dlatego rozsądną miarą dojrzałości nie jest brak zależności od dostawców. Jest nią wiedza, gdzie te zależności występują i ile kosztowałoby ich przerwanie.

Przypadek 37signals pokazuje, iż różnica może być znaczna, choć jego wyniki należy traktować jako dane deklarowane przez samą firmę. Po wyprowadzeniu części infrastruktury z AWS spółka informowała o wielomilionowych oszczędnościach, ale późniejsza migracja storage wymagała kolejnej inwestycji około 1,5 mln dolarów w sprzęt Pure Storage. Jednocześnie 37signals podawało, iż samo przechowywanie danych w S3 kosztowało ją blisko 1,5 mln dolarów rocznie.

Nie jest to argument za własną serwerownią. Jest to raczej przykład wartości posiadania realnej opcji wyjścia.

Europa próbuje część kosztów takiego wyjścia obniżyć regulacyjnie. Data Act nakazuje dostawcom usuwać przeszkody w zmianie usług i poprawiać interoperacyjność, a od 12 stycznia 2027 r. zabroni pobierania opłat za sam proces zmiany dostawcy, obejmując tym pojęciem również opłaty za wyprowadzanie danych.

Regulacja może jednak zlikwidować opłatę. Nie zlikwiduje zależności zapisanej w kodzie.

Dlatego najbardziej użyteczne pytanie o vendor lock-in nie brzmi dziś: „czy jesteśmy zależni od dostawcy?”. Niemal każda nowoczesna infrastruktura jest zależna od wielu dostawców. Znacznie więcej mówi pytanie o to, które zależności są odwracalne w kilka tygodni, które wymagają wielomiesięcznej migracji, a które w praktyce stały się elementem długoterminowej strategii przedsiębiorstwa.

Dopiero taka perspektywa pozwala wycenić technologię nie tylko przez koszt jej zakupu, ale także przez cenę utraty możliwości wyboru.

Idź do oryginalnego materiału