mmazur.7thguard.net

W robocie mam taką sytuację, że klienci domagają się znacznie większej skalowalności, niż obecne oprogramowanie jest w stanie dostarczyć. Rozwiązanie -- przepisać, biorąc pod uwagę to, co już wiemy o różnych bottleneckach w obecnym kodzie. Ale cała operacja zajmie z dwa miesiące co najmniej, a w międzyczasie klient może nas olać. Na szczęście szef po prostu dorzucił kilka maszyn i powiedział, żeby władować tam maksymalną ilość danych, jakie się da. Powinno na te dwa miesiące wystarczyć.

Gdy przez ostatnie lata raz na jakiś czas przyglądałem się infrastrukturze innych dystrybucji, to zazwyczaj jedną z pierwszych reakcji było -- to oprogramowanie jest dla nas nieprzydatne, bo nie przewiduje rozproszonej i podatnej na błędy natury systemów, których używamy (a maszyny PLD są/były rozsiane w sumie po całym globie). Za każdym razem wtedy myślałem, że niezależnie od różnych gwizdków i wodotrysków, jakie mają w swoim sofcie inne dystrybucje, nasz soft jest jednak na tym najbardziej podstawowym poziomie lepszy, ponieważ jest dostosowany do tego, czym może dysponować grupa ludzi bez sporego konta w jakimś banku. Czyli taki typowy projekt open source.

I rzeczywiście, na pewnym poziomie nasze oprogramowanie jest lepsze właśnie, dlatego, że ma takie założenia, a nie inne. Problem polega na tym, że pisanie infrastruktury dla projektu to jest tak naprawdę strata czasu, ponieważ w idealnym świecie nikt nie musiałby pisać owej infrastruktury, a narzędzia potrzebne do optymalnego wykonywania właściwej roboty (czyli robienia dystrybucji, a nie pisania skryptów w pythonie) byłyby już dostępne. Patrząc na różne problemy z obecną infrastrukturą builderową, z których część wynika na przykład z używania zwykłej poczty do komunikacji między builderami (co choćby wymaga zainstalowanego demona pocztowego na wszystkich maszynach hostujących buildery, co nie zawsze jest takie proste do wykonania), przed oczami mam różne potencjalne rozwiązania. To przepisać tak, tamto siak, tutaj dodać parę skryptów na taką ewentualność, etc.

Tyle, że każda taka sesja kodowania, to jest czas, w którym można by zrobić coś innego, coś przydatnego z punktu widzenia użytkowników (którymi deweloperzy są także). W kontekście ostatnich kilku lat, gdybyśmy mieli własną dedykowaną serwerownię, to ilość godzin zaoszczędzonych na klepaniu się z różnymi brakami w funkcjonalności, błędami, czy też zwykłymi awariami pewnie szłaby w setki.

Oczywiście prawda jest taka, że nie mamy i mieć nie będziemy takowej serwerowni, więc skazani jesteśmy na rozwiązania software'owe. I w pewnym sensie jest to też zaleta, bo w końcu dorobimy się porządnej infrastruktury, co pozwoli nam w pewnym stopniu konkurować z dystrybucjami posiadającymi jakiś kapitał, pomimo tego, że sami owego kapitału nie posiadamy (a jeśli kiedyś się dorobimy, to będziemy go mogli wydać na coś ciekawszego z punktu widzenia użytkowników, niż infrastruktura).

(Co nie zmienia faktu, że jest wybitnie irytujące, że tracimy czas na klepanie się z takimi rzeczami, podczas gdy inne dystrybucje zajmują się rzeczywistą robotą.)