Dług technologiczny, jako pojęcie znane jest informatykom z programowania i projektowania systemów. Ale co oznacza dług technologiczny, określany także technicznym, w świecie baz danych? W niniejszym artykule prezentuję kilka typowych zadłużeń i ich wzajemnych relacji.

Czym jest dług?

Dług jest zobowiązaniem. Powstaje w momencie gdy dziś konsumujemy jutrzejsze przychody. Innymi słowy: dla bieżących korzyści godzimy się na przyszłe niedostatki. 

Wszyscy znamy to pojęcie ze świata kredytów. Zaciągamy je aby korzystać z przedmiotu już teraz. Zobowiązujemy się wobec wierzyciela, podmiotu pożyczającego, zazwyczaj banku, że spłacimy zobowiązanie. 

Bank nie jest instytucją charytatywną. Pożycza określoną kwotę, ale zwrócić musimy pożyczoną kwotę powiększoną o odsetki. 

Osoby prywatne, zazwyczaj, zaciągają dług aby spełnić swoje zachcianki. Zakupiony za kredyt przedmiot nie przyniesie zysku. Wygeneruje dodatkowe koszty. 

Firmy zazwyczaj inwestują. Czyli kredytowany przedmiot ma zwiększyć przychody firmy. Dobrze jeśli na tyle aby przekroczyć koszt odsetek. 

Czym dług technologiczny różni się od zwykłego?

Niczym. 

No, może jedynie tym, że zaciągnięcie długu technologicznego nie jest związane z aktywnym działaniem. 

Aby wziąć zwykły kredyt trzeba wykazać się inicjatywą. Wykonać szereg czynności wymaganych przez prawo i kredytodawcę. Wiąże się też z przypływem pożyczonych aktywów lub pojawieniem się kredytowanego przedmiotu. 

Odwrotnie dług technologiczny. Ten zaciąga się poprzez zaniechanie działania. Nie robimy nic, a rośnie nasze zadłużenie technologiczne. Naliczane są odsetki. 

Walutą podobnie jak w zwykłym kredycie są pieniądze. 

Dług technologiczny jest idealną ilustracją słów Goethe’go 

Kto nie idzie do przodu ten się cofa

Kim jest wierzyciel technologiczny?

Skoro jest dług technologiczny to musi być i wierzyciel, prawda? Komu trzeba spłacać dług technologiczny? 

Branży IT. 

Dług technologiczny zaciąga się w szeroko pojętej branży IT. Za dzisiejsze korzyści płynące z zaniechania wykorzystania nowszej technologii zapłacimy w przyszłości. Plus odsetki. 

Zapłacimy swoim pracownikom, firmie doradczej czy dostawcy oprogramowania. Tak czy inaczej poniesiemy ten koszt. 

Tempo zmian w świecie technologii nieustannie przyspiesza. Globalizacja jest faktem. Świat jednobiegunowy skupiony dookoła amerykańskiej dominacji zaczyna rozpękać się na dwa. Co generuje jeszcze większą potrzebę zmian. 

Biorąc to wszystko pod uwagę śmiem twierdzić, że odsetki od długu technologicznego rosną proporcjonalnie do tempa zmian w technologii. 

Jakie korzyści możemy chcieć osiągać dziś?

Żyjemy w świecie kapitalistycznym gdzie firmy działają mając na uwadze swój zysk. Korzyść finansowa jest celem. 

Korzyść finansowa może płynąć z zaniechania wydania większej ilości pieniędzy na programistów aby napisali lepszy kod lub wykorzystali nowszą technologię. 

Może to być zaniechanie wydania pieniędzy na nowocześniejszy lub bardziej wydajny sprzęt czy oprogramowanie. 

Może to być zaniechanie wydania pieniędzy na bardziej dokładne testy. 

Wszystko po to aby produkt szybciej trafił na rynek. Aby nowa funkcjonalność, naszej aplikacji, pojawiła się przed konkurencją. Aby uniknąć przestojów w działalności firmy. Lub wykonać Proof of Concept. 

Możemy robić to świadomie. Podobnie jak inwestować w firmę. Przygotować się finansowo na spłacenie długu razem z odsetkami. 

Jak zaciągamy dług technologiczny w świecie baz danych?

Bazy danych stanowią kręgosłup działalności firmy. Bez dostępnej bazy danych działalność firmy jest niemożliwa. Pisząc 'dostępnej’ mam na myśli również wydajnej. Baza danych nie jest postrzegana jako dostępna gdy wykonanie komendy SQL zajmuje wielokrotnie więcej czasu niż zazwyczaj. 

Firmy walczą, więc o jak najwyższą dostępność swoich baz danych. Czasem jest to kosztem instalacji poprawek, zmiany wersji motoru na nowocześniejszy czy wymiany sprzętu i systemu operacyjnego obsługującego instancję. 

Czasem firmy nie decydują się na wykup wsparcia od dostawcy motoru bazy danych. Oprócz oczywistych konsekwencji w postaci braku wsparcia mogą w ten sposób utracić prawo do instalacji nowszej wersji i poprawek. Dużo zależy od konstrukcji umowy licencyjnej. 

Przyczyny takiego postępowania mogą być różnorakie. Czasem jest to zwykła, krótkowzroczna oszczędność. Czasem jest to przypisanie własności bazy danych ludziom odpowiedzialnym za jej utrzymanie zamiast ludziom, którzy z niej korzystają. Czyli właścicielowi danych. 

Czasem jest to polityka firmy. Niektóre firmy mają bardzo ścisłe procedury instalacji poprawek i nowych wersji motorów baz danych. Są także firmy, który takich procedur nie posiadają. Decyzja o instalacji poprawek jest pozostawiona administratorom. 

Długiem technologicznym jest także brak kwalifikacji wśród pracowników. Być może nie są w stanie podjąć ryzyka podniesienia wersji motoru bazy danych.

Czy przejście na motor open-source to dług?

Obecnie modna jest tendencja odchodzenia od motorów komercyjnych, jak Oracle, do motorów darmowych. Jak PostgreSQL.

Czy takie przejście jest zaciąganiem długu? Czy jego spłatą?

Producenci motorów komercyjnych jak Oracle, SQL Server czy DB2, zapewniają cały wachlarz narzędzi wspierających dostępność danych. Na przykład zaawansowane narzędzia do wykonywania kopii zapasowych, zarządzania instancjami, monitorowania, replikowania czy klastrowienia. Są one świetnie zintegrowane z samym motorem.

Narzędzi takich, albo tak zaawansowanych, albo tak zintegrowanych, nie zapewniają producenci motorów open-source. Niemniej zazwyczaj istnieją produkty firm trzecich o podobnych funkcjonalnościach. Często również open-source.

Ze świetną ofertą wychodzą dostawcy chmurowych DBaaS. Opakowali oni dostępne darmowo oprogramowanie open-source w wysokomarżową usługę dostępną online. Swoją renomą gwarantują jej stabilność.

Z jednej strony DBaaS postrzegany jest jako oszczędność. O czym świadczy rosnąca sprzedaż usług chmurowych. Czyli dobrze – firma wydaje mniej. Bieżąca korzyść.

Z drugiej strony trzeba zadbać o kompetencje pracowników, którzy muszą przesiąść się na inny motor. Na dodatek często dostępny w chmurze, więc ze swoją specyfiką.

Kilkudniowe szkolenie nie zastąpi wieloletniego doświadczenia. Przyszłe koszty.

Postrzegam to jako zaciąganie długu.

Na fali hajpu motorów open-source w chmurze, część firm decyduje się migrować motory komercyjne on-premises do motorów open-source on-premises.

Firmy, które decydują się na ten krok muszą same szukać rozwiązań zapewniających wysoką dostępność. Same muszą je zgrywać i same muszą rozwiązywać powstałe problemy.

Czyli znów dla bieżących oszczędności liczonych w kosztach licencji firmy godzą się na przyszłe koszty w postaci zwiększonej pracochłonności i niedostępności bazy danych.

Dla przykładu: firma decyduje się na migrację Oracle do PostgreSQL. Traci funkcjonalność Data Guard pozwalającą na płynne i automatyczne przełączanie się pomiędzy bazą główną a replikami.

Oczywiście można PostgreSQL oskryptować i zapewnić podobną do Data Guard funkcjonalność. Problem polega na tym, że robienie tego na własną rękę powoduje zwiększony nakład pracy pracowników. Co rodzi więcej okazji do błędów.

Innymi słowy sprawdzoną, ale wysokopłatną automatykę Data Guard firma zamienia na niskopłatną pracę swoich pracowników.

Co, mimo pozornej oszczędności, może okazać się długiem. Trzeba będzie go spłacić w momencie awarii, która przeciągnie się w dziesiątki minut lub godziny. Bo zamiast szybkiej automatycznej reakcji Data Guard potrzebna będzie ręczna interwencja człowieka.

Dług może też być spłacany kropelkowo. W postaci wydłużonej niedostępności i pracochłonności z uwagi na podniesienie wersji motoru, aplikacji, testów DRC, migracji na nowy sprzęt, itp. Lub po prostu zwiększonego ryzyka gdy replika nie jest dostępna.

Odsetki w świecie baz danych

Zmiana wersji motoru bazy danych jest ryzykowna. Zazwyczaj wiąże się ze zmianami w jądrze motoru – optymalizatorze. Oczywiście producent obiecuje, że każda następna wersja generuje jeszcze lepsze plany wykonania, ma usunięte stare błędy i dysponuje większą ilością wspierających aplikację rozwiązań. 

Zmiana wersji na kolejną zazwyczaj jest dobrze przygotowana. Gdy nie ma problemów to idzie smukle. Szczególnie gdy na bieżącej mamy zainstalowane najnowsze poprawki. 

Schody zaczynają się gdy próbujemy przeskoczyć kilka wersji. Nie zawsze jest to możliwe w jednym kroku. 

To są właśnie odsetki od długu – wydłużony czas niedostępności bazy danych, wydłużony czas testów i większy nakład pracy pracowników IT. 

Czasem jest to powiązane z koniecznością wykupienia wsparcia i prawa do podniesienia wersji. Czasem trzeba zapłacić wstecz za lata gdy za to wsparcie nie płaciliśmy. 

Odsetkami są także blokady na podniesienie wersji systemu operacyjnego. Stare wersje motoru bazy danych certyfikowane są na stare wersje systemów operacyjnych. Brak podnoszenia wersji czy instalacji poprawek może skutkować brakiem wsparcia. 

Podobnie z bibliotekami klienckimi. Aplikacje używają ich aby podłączyć się do bazy danych. Zazwyczaj zachowują kompatybilność wsteczną. Niemniej mogą nie wykorzystywać pełni swojej funkcjonalności gdy współpracują z przestarzałym motorem. 

Nie mniej ważne są podatności na ataki. Im starsze oprogramowanie tym lepiej rozpoznane przez włamywaczy. 

Podsumowanie

Można spotkać się ze zdaniem: jeśli działa to nie ruszaj. Nie jest ono pozbawione podstaw. Przez to stwierdzenie przemawiają lata doświadczeń pracowników IT. 

Zaciągając dług technologiczny warto zwrócić uwagę na drobny druk. Warto także określić moment spłaty. 

Odraczanie spłaty długu może doprowadzić do sytuacji gdy nasz stos technologiczny przypomina węzeł gordyjski. Z bazą danych w samym sercu. Wzajemne powiązania oprogramowania i sprzętu, lata naleciałości w postaci własnych obejść problemów czy niedostatków. Nie bez znaczenia jest, również opór pracowników. Do rozwiązania tylko mocnym cięciem.

Wraz z rozwojem technologii potrzeba cięcia staje się coraz bardziej nagląca. Przestarzały stos technologiczny jest narażony na ataki. Często jest też po prostu zbyt mało wydajny aby sprostać aktualnym potrzebom firmy. 

Wtedy firmy mogą zdecydować się na jednorazowy duży krok. Wymianę sprzętu, systemu operacyjnego i motoru bazy danych. 

Osobnym tematem jest refaktoring kodu SQL, jego proceduralnego rozszerzenia oraz schematu. Razem z nowym motorem bazy danych przychodzi nowa funkcjonalność. 

Trzeba pamiętać, że język SQL jest żywy. Instytucje odpowiedzialne za jego standaryzację starają się nadążać za potrzebami rynku. Do tej pory pojawiło się 10 edycji standardu. Ostatnia w 2019.

Prowadzę szkolenia i kursy z podstaw SQL. Sprawdź ofertę moich kursów SQL.