Vendor lock-in: jak rozpoznać, że migracja będzie boleć
Lock-in nie zaczyna się w dniu wypowiedzenia umowy. Powstaje wcześniej, gdy aplikacja coraz mocniej zależy od unikalnych interfejsów, formatów i usług jednego dostawcy.
Vendor lock-in jest często opisywany jak pułapka zastawiona przez dostawcę. W praktyce część zależności powstaje dlatego, że wygodne usługi zarządzane rzeczywiście oszczędzają czas. Problem pojawia się wtedy, gdy nikt nie sprawdza kosztu wyjścia.
Dane to tylko jedna warstwa
Możliwość pobrania plików nie oznacza, że aplikację łatwo przenieść. Trzeba uwzględnić format bazy danych, interfejsy API, system tożsamości, funkcje serverless, kolejki, sieć, logi, polityki dostępu i sposób wdrażania. Im więcej elementów jest specyficznych dla jednego środowiska, tym więcej pracy wymaga odtworzenie ich gdzie indziej.
ENISA od lat wskazuje lock-in jako ryzyko organizacyjne i finansowe. W przewodniku dla małych i średnich firm zaleca plan ciągłości obejmujący migrację, standardowe formaty oraz regularne sprawdzanie, czy dane można faktycznie przenieść.
Nie każdy lock-in jest zły
Czasem świadome wykorzystanie unikalnej usługi daje dużą przewagę i koszt ewentualnej migracji jest akceptowalny. Problemem nie jest sama zależność, lecz brak wiedzy o niej.
Warto więc dokumentować, które elementy są przenośne, które trzeba przepisać, jakie dane da się wyeksportować i jak długo trwałoby wyjście. Taki plan nie musi oznaczać utrzymywania drugiej chmury przez cały czas.
Test migracji jest lepszy niż deklaracja
Najłatwiej powiedzieć, że system jest przenośny, dopóki nikt go nie przenosił. Eksport próbki danych, odtworzenie infrastruktury z kodu i uruchomienie krytycznej części aplikacji poza głównym środowiskiem pokazują realny poziom zależności.
Lock-in jest cechą architektury i umowy. Można nim zarządzać, ale trzeba go widzieć zanim migracja stanie się pilna.
Lock-in może być techniczny, operacyjny i kontraktowy
Techniczny lock-in pojawia się, gdy aplikacja wykorzystuje funkcje trudne do odtworzenia gdzie indziej. Operacyjny rośnie wtedy, gdy cały zespół, monitoring i proces wdrażania są zbudowane wokół jednego środowiska. Kontraktowy może wynikać z długości umowy, kosztów zakończenia współpracy albo warunków eksportu danych.
Znaczenie ma też sama skala danych. Eksport kilku gigabajtów i przeniesienie setek terabajtów to zupełnie inne projekty. Dlatego plan wyjścia powinien uwzględniać nie tylko format, ale również czas transferu, przepustowość, kolejność migracji i okres, w którym dwa środowiska muszą działać równolegle.