Decyzja o wyborze technologii, platformy czy dostawcy SaaS to jeden z kluczowych momentów w rozwoju każdej firmy. Jednak co się stanie, jeśli wybrane rozwiązanie stanie się przestarzałe, jego koszty wzrosną, a migracja okaże się niemożliwa? Mówimy wtedy o vendor lock-in, czyli uzależnieniu od jednego dostawcy technologii.
Vendor lock-in — cicha pułapka, która ujawnia się przy pierwszej próbie zmiany
Uzależnienie od jednego dostawcy technologii rzadko jest świadomą decyzją. Zwykle dzieje się stopniowo: firma wybiera platformę chmurową, integruje się z jej natywnym API, buduje procesy wokół jej narzędzi — a po dwóch latach odkrywa, że migracja oznacza przepisanie połowy systemu. Według raportu Flexera State of the Cloud (2023) 74% firm wskazuje vendor lock-in jako „istotne lub bardzo istotne ryzyko" przy korzystaniu z chmury publicznej.
W tym artykule opisuję konkretne obszary, w których vendor lock-in się materializuje, i strategie, które pozwalają zachować elastyczność.
Chmura — wygoda kosztem przenośności
AWS, Azure, Google Cloud — każdy oferuje usługi zarządzane (managed services), które przyspieszają development: Lambda (AWS), Cloud Functions (GCP), Cosmos DB (Azure). Problem w tym, że te usługi mają autorskie API, autorskie SDK i autorskie modele cenowe. Przeniesienie aplikacji z AWS Lambda na Azure Functions to nie zmiana konfiguracji — to przepisanie warstwy integracyjnej.
Jak ograniczyć ryzyko
- Warstwa abstrakcji — infrastruktura ukryta za interfejsem. Zamiast wywoływać AWS S3 SDK bezpośrednio, tworzysz
FileStorageinterface z implementacjąS3FileStorage. Zmiana dostawcy = nowa implementacja, nie przepisanie aplikacji. Wzorzec Ports & Adapters (hexagonal architecture) formalizuje to podejście. - Kontenery zamiast managed services — Docker + Kubernetes działają identycznie na AWS (EKS), Azure (AKS), GCP (GKE) i on-premise. Koszt wejścia wyższy, ale przenośność wielokrotnie lepsza.
- Terraform / OpenTofu — Infrastructure as Code niezależny od dostawcy. Definicje infrastruktury w jednym formacie, nawet przy multi-cloud.
Multi-cloud nie oznacza, że musisz korzystać z dwóch chmur jednocześnie. Oznacza, że Twoja architektura pozwala na migrację, gdy będzie potrzebna — bez zatrzymywania biznesu.
Frameworki i biblioteki — popularność to nie gwarancja
AngularJS, Backbone.js, jQuery Mobile, Adobe Flash — lista technologii, które dominowały, a potem straciły wsparcie, jest długa. Firma, która postawiła frontend wyłącznie na AngularJS w 2014 roku, w 2018 musiała przepisywać go na Angulara 2+ lub Reacta — bo Google zakończył rozwój AngularJS.
- Aktywność społeczności — sprawdzaj nie liczbę gwiazdek na GitHubie, a częstotliwość commitów, czas reakcji na issues i datę ostatniego releasu. Martwe repozytorium z 50 000 gwiazdek to wciąż martwe repozytorium.
- Izoluj framework od logiki biznesowej — React, Vue, Angular powinny być warstwą prezentacji, nie miejscem, gdzie żyje logika domenowa. Jeśli wymiana frameworka UI oznacza przepisanie reguł biznesowych — to sygnał problemu architektonicznego.
- Standardowy SQL zamiast dialektów — BigQuery, Snowflake, Redshift mają rozszerzenia SQL, które nie działają nigdzie indziej. Trzymaj się ANSI SQL tam, gdzie to możliwe.
SaaS — zamknięty ekosystem z wygodnym wejściem
Narzędzia SaaS rozwiązują problemy szybko: Slack do komunikacji, Jira do zarządania projektami, Salesforce do CRM. Ale szybkość wdrożenia ma swoją cenę — dane żyją na serwerach dostawcy, w jego formacie, z jego ograniczeniami eksportu.
Atlassian w 2023 roku podniósł ceny licencji Cloud o 5–15% i zakończył sprzedaż licencji Server. Firmy, które nie miały planu alternatywnego, stanęły przed wyborem: płacić więcej lub migrować — a migracja z Jiry z zachowaniem historii projektów to projekt na tygodnie.
Zabezpieczenia
- Przed wyborem SaaS sprawdź eksport — czy możesz wyciągnąć swoje dane w formacie otwartym (JSON, CSV, SQL dump)? Jeśli jedyna opcja to „skontaktuj się z supportem" — to sygnał ostrzegawczy.
- Rozważ self-hosted open-source — Mattermost zamiast Slacka, Plane lub Linear zamiast Jiry, Odoo zamiast Salesforce'a. Nie zawsze to 1:1 zamiennik, ale daje pełną kontrolę nad danymi.
- Eksportuj regularnie — nawet jeśli nie planujesz migracji. Backup danych z SaaS to element ciągłości biznesowej, nie paranoja.
Infrastruktura — prekonfigurowane serwery to wygoda na kredyt
Managed hosting (Heroku, Platform.sh, Railway) pozwala wdrożyć aplikację w minuty. Ale po dwóch latach, gdy miesięczny rachunek rośnie z 200 do 2000 dolarów, okazuje się, że migracja na VPS wymaga przebudowy procesu wdrażania, konfiguracji serwera i monitoringu.
- Docker od początku — konteneryzacja sprawia, że aplikacja jest przenośna. Dockerfile opisuje środowisko niezależnie od tego, czy kontener uruchomisz na Heroku, AWS, Hetznerze czy własnym serwerze.
- Konfiguracja jako kod — Ansible, Terraform, Pulumi. Odtworzenie środowiska na nowym dostawcy powinno być kwestią godzin, nie tygodni.
Checklist przed wyborem dostawcy
- Eksport danych — czy dane można wyeksportować w standardowym formacie?
- Przenośność kodu — czy aplikacja korzysta ze standardowych API (REST, SQL, SMTP), czy z autorskich?
- Alternatywy — czy istnieją co najmniej dwa porównywalne rozwiązania na rynku?
- Historia dostawcy — czy w ostatnich 3 latach zmienił cennik, zakończył wsparcie produktu, wymusił migrację?
- Warstwa abstrakcji — czy architektura systemu pozwala podmienić dostawcę bez przepisywania logiki?
Vendor lock-in nie jest problemem, który rozwiązujesz w dniu migracji — to problem, który rozwiązujesz w dniu projektowania architektury. Jeśli budujesz system dedykowany i chcesz mieć pewność, że nie uzależniasz się od jednego dostawcy — porozmawiajmy o architekturze, która daje Ci wybór.
Źródła
- Flexera — State of the Cloud Report — coroczne badanie o zarządzaniu chmurą i ryzykach vendor lock-in.
- Martin Fowler — How to break a Monolith — strategie dekompozycji systemów i unikania zależności od jednej platformy.
- Open Source Initiative — definicja otwartego oprogramowania i zasoby dotyczące licencji open-source.
- Cloud Native Computing Foundation (CNCF) — projekty open-source (Kubernetes, Envoy, Prometheus) wspierające przenośność między chmurami.
- The Twelve-Factor App — metodologia budowania aplikacji przenośnych i niezależnych od infrastruktury.
LinkedIn/desi9n-pl 
FB/desi9npl 
@desi9n.pl