Konfigurować, czy kodować?

Data: 2021-08-18
Autor: Sebastian Konkol
Konfigurować, czy kodować?

Jak podpowiada doświadczenie w każdej z dziedzin działalności człowieka, także rozwój w IT jest procesem cyklicznym. Co pewien czas następuje przewartościowanie – terminy i praktyki uznawane za obowiązujące muszą ustąpić z pierwszych miejsc, przy czym ustępują często miejsca terminom i praktykom uznawanym przez jakiś wcześniejszy czas za co najmniej passé. Wygląda na to, że konfigurowanie sucks, kodowanie rocks!

W sferze budowania i wdrażania rozwiązań informatycznych wiele się zmieniło w ostatniej dekadzie. Wszystkie te zmiany – jak choćby Agile, CI/CD, konteneryzacja, cloud, IaC, DevOps – skutkują zmniejszaniem jednostkowych kosztów rozwoju systemów informatycznych i zwiększaniem odporności na błędy. Umiemy (jako cywilizacja, choć nie powszechnie, niestety) tworzyć oprogramowanie wysokiej jakości, w małych przyrostach, często dostarczając mierzalnej wartości biznesowej oraz umiemy bezkosztowo wycofać zmianę posiadającą błędy. Współczesne czasy hiperskracania cykli biznesowych preferują szybkie rozwiązania punktowe i do takich działań dopasowana jest cała współczesna inżynieria IT – od chmury, przez procesy wytwórcze, po architekturę. Dla architekta to jest świat o rosnącym poziomie wyzwań, ale coraz częściej bardziej opłaca robić software na miarę, niż wdrażać gotowe „kombajny”. Okazuje się bowiem, że taniej jest zmieniać software, niż kupić rozwiązanie konfigurowalne i zmieniać konfigurację takiego rozwiązania.

Ekonomia konfigurowania jest bezwzględna: każda opcja konfiguracji to dodatkowy wymiar złożoności rozwiązania, za którą trzeba zapłacić już dziś bez względu na to, czy kiedykolwiek zostanie wykorzystana. Biorąc pod uwagę rozwiązania tworzone „pod wymagania” niewiele jest tak bezsensownych ekonomicznie funkcji w rozwiązaniu, jak złożona konfiguracja w systemie. Utrzymywanie jej oznacza bowiem także dodatkowy wymiar złożoności w każdej analizie, każdym teście, każdym wdrożeniu, a jak się o tym zapomni, to takie niedopatrzenie zemści się okrutnie… i kosztownie. Smutne jest to, że najczęstszym powodem powoływania mechanizmów konfiguracyjnych jest … brak zdecydowania w kwestii „to jak ma działać”, podbudowany niewiarą (niestety, często zasadną) w skuteczność działań wytwórczych IT. Zaskakująca jest tu jednak niekonsekwencja – skoro „lokalne IT” nie są w stanie sprawnie dostarczaj rozwiązań „niekonfigurowalnych” o wysokiej jakości, to co uzasadnia parcie ku rozwiązaniom „konfigurowalnym”, w których sam mechanizm konfiguracji jest dodatkowym wymiarem złożoności i źródłem błędów?…

Doświadczenia pokazują raczej jednoznacznie, że konfigurowanie – w każdym znanym mi projekcie – stało się z czasem sprawą złożoną, wymagającą dobrej znajomości konsekwencji tej konfiguracji na efekty działania i posiadającą ogromny, choć słabo rozpoznany, wpływ na podstawowe parametry rozwiązania jak szybkość działania, dostępność, czy wydajność. Mimo to, testowanie tego wpływu, w porównaniu do testowania wyników kodowania, po prostu nie jest realizowane – po pierwszej wpadce ustawianie wartości konfiguracji, pierwotnie realizowane pod sztandarem „biznes będzie zmieniał” staje się narzędziem IT. Wtedy okazuje się, że konfigurowanie to używanie specjalizowanego języka (wyklikania czy skryptu), bez powszechnego wsparcia (prawdopodobnie tylko twórcy poszczególnych elementów potrafią użyć ich bezpiecznie), wymagające działań manualnych a więc nie dających się włączyć w nowoczesne metody zapewnienia jakości i zwinności w rozwoju systemów informatycznych (CI/CD). Pierwotne parcie na konfigurowalność staje się największą kotwicą rzeczywistej zwinności.

Jeśli sięgniemy pamięcią do początków usług chmurowych, najważniejsze było to, że mogliśmy „wyklikać sobie” infrastrukturę, skonfigurować ją. Bardzo szybko jednak podstawowym trybem wdrażania rozwiązań w chmurze przestało być „konfigurowanie”, a stało się nim kodowanie (właśnie tym jest IaC, prawda?). Stało się tak właśnie dlatego, że nad kodem – jego wersjonowaniem, weryfikacją, wdrażaniem – umiemy panować w wymaganiach tempa XXI wieku, a konfiguracja nie dość, że jest źródłem błędów, to najczęściej wymyka się w realnych warunkach spod kontroli.

Naturalnie, nie chcę tu powiedzieć, że konfiguracja to samo zło i powinna być unikana za wszelką cenę. Warto bowiem dostrzegać ustawienia konfiguracyjne o dużej sile wpływu ale wolnozmienne lub szybkozmienne o niewielkiej sile wpływu, bo one powinny móc być wykonywane konfiguracyjnie, o ile takie możliwości są już dostępne w posiadanych rozwiązaniach. Wykorzystanie pierwszych z nich powinno być jednak realizowane w ściśle kontrolowanych warunkach (np. uwarunkowane wykonaniem pełnych testów regresyjnych), podczas gdy drugie powinny móc być wdrażane „na odpowiedzialność” biznesu (ta odpowiedzialność i tak skończy się wraz z wystąpieniem pierwszego poważniejszego problemu 😊).

Złożone mechanizmy konfiguracji należą do sfery rozwoju rozwiązań zintegrowanych koncepcyjnie klasyfikowanych jako systems of records i tamże wpasowują się całkiem dobrze. Pamiętając, że takie rozwiązania są dostarczane przez zewnętrznych dostawców, a więc zweryfikowane w boju w wielu miejscach (minimalizacja ryzyka siły wpływu) korzystanie z takich mechanizmów konfiguracyjnych jest po postu bezpieczniejsze. Im dalej jednak w kierunku systems of engagement, tym mniejszy jest sens budowania złożonych mechanizmów konfiguracyjnych. Biorąc jednak pod uwagę, że gatunek systems of records to raczej gatunek w odwrocie, zasięg sensownego stosowania mechanizmu konfiguracji kurczy się i będzie się kurczył coraz bardziej.

Wydaje się więc, że najwyższy już czas zrewidować stanowisko w sprawie „kodować czy konfigurować”. Znacznie szybciej i pewniej, a przede wszystkim skuteczniej i bezpieczniej robi się dzisiaj zmiany w kodzie oprogramowania, niż w konfiguracji. Umiejętność dostrzegania konieczności rewizji obowiązujących „lematów” wymaga dojrzałości architekta i wielu lat doświadczeń. Wszak gramy tu o połączenie zwinności (Agility) w tym oparcia zapewnienia jakości o praktyki tworzenia oprogramowania z odpornością (Resilience) egzekwującą testowanie konfigurowalności wszędzie tam, gdzie podpowiada to analiza ryzyka. Niech kieruje Tobą architektoniczny rozsądek.

Pozostaw komentarz