Monolity i trochę programistycznej egzotyki: popołudnie z Sesją Linuksową

Pokaźny zbiór możliwości nierzadko czai się pod spodem skomplikowanych stosów i nie inaczej jest w przypadku cudownego (i cudacznego) serwera nginx, czyli wszechstronnego oprogramowania o ciekawych zastosowaniach, jak cache lub reverse proxy. Nginx okazuje się być programowalny z wykorzystaniem języka Lua, który nie jest być może szczególnie popularny, ale to zależy wyłącznie od tego, w jakich kręgach go szukamy :) Marcin Stożek pokazywał mało wymagające implementacje wstrzykiwania programowalnych elementów do ruchu HTTP oraz zaawansowane metody filtrowania i dynamicznej modyfikacji RESTowego API, w ramach tzw. Web App Firewall. Takie rozwiązania słusznie budzą skojarzenia z atakiem typu man-in-the-middle, ale tym razem odbywają się przy błogosławieństwie programisty.

Język Haskell jest już nieco popularniejszy niż Lua, ale wystarczy zestawić go z jakimś kosmicznie odległym obszarem, jak REST, by ponownie wylądować w krainie programistycznej egzotyki. Głównym przedmiotem kolejnej prelekcji jest programowanie funkcyjne, ale przedtem padają bardzo istotne słowa na temat klasyfikacji czystości kodu. To sensowny obszar rozważań, ponieważ (z lekką dozą przesady) czasem bardziej opłacałoby się zatrudnić 100 osób bardzo szybko odpowiadających na żądania JSON, niż utrzymywać dotychczasowy serwer „enterprise grade”. Działałoby to lepiej, szybciej i prawdopodobnie taniej.

Sobotnia sesja „O bezpieczeństwie kontenerów linuksowych” słusznie [url=]postawiła tezę[/url] stanowiącą, że kontenery, a szczególnie konkretna ich implementacja z wykorzystaniem Dockera, nie są lekiem na wszystko. Mimo ich niewątpliwej popularności w branży i masowej konwersji wielu projektów właśnie na dostarczanie kontenerowe. Mentalność tę słusznie opisał w 2017 roku Ozan Onay, dowodząc jak zgubne jest myślenie, by robić wszystko tak jak inni, jeżeli tylko owi „inni” odnieśli sukces.

Bartłomiej Kuczyński na swojej prelekcji dowodzi, że ten sam mechanizm działa nie tylko w kwestii kontenerów, ale i mikroserwisów. Uchodzą one w pewnych kręgach za magiczny lek na wszystko i czasami w ramach „postępu za wszelką cenę” są wprowadzane jako jedyna słuszna architektura, bo przecież monolityczne systemy są archaiczne i złe.

Przedefiniowanie rozwiązania na mechanizm mikroserwisowy powinno być zawsze odpowiedzią na konkretny problem, a nie owczym pędem. Branża IT jest jednak podatna na trendy od samego początku komercyjnej informatyki. Aby lepiej zrozumieć to zjawisko, przytaczane są praktyczne przykłady.