Cześć, bracia i siostry z DevOps. Czytałem ostatni materiał o „PowerShell na poziomie eksperckim”. Muszę przyznać, że jest on napisany językiem tak profesjonalnym, że niemal zasługuje na doktorat. Autorka z pewnością spędziła tam zbyt wiele godzin na składaniu składni dla kogoś, kto tylko chce sprawdzić status usługi.
Zaczęło się od podstaw: "Jeżeli piszesz skrypty, które działają tylko w kontrolowanym środowisku i nad którymi pracujesz sam, to jest to wystarczające." Ten fragment trafił prosto do mojego archiwum „Krótkich Prawdy, Które Cię Oszczędzą Roku Nauki".
🧱 Kiedy modułowość staje się balastem
Tekst ten maluje obraz, w którym skrypt to jest niemal nielegalny artefakt, który należy natychmiast przemienić w moduł. Moduły! Bracie, czasem potrzebujesz tylko trzech linijek kodu, które sprawią, że wszystko działa. Zamiast tego muszę się uczyć życia w świecie modułów, API i idealnie zdefiniowanych granic działania, tylko po to, żeby sprawdzić adres IP serwera. Czy naprawdę tak działa administracja?
Następnie mamy Odporność na Błędy, i cudowny blok try/catch/finally. Czy wiesz, ile czasu można stracić na eleganckie wyłapywanie błędów, kiedy wystarczy > err_action czy po prostu założenie, że jeśli się nie wywaliło, to działa? W środowisku, gdzie prędkość jest królem, te wszystkie mechanizmy są jak wyśmienicie skonstruowany, ale niepotrzebny, pancerz.
📜 Powrót do prostoty (i czaru CMD)
Największym akademickim zgrzytem jest dla mnie Zasada Stanu Pożądanego (DSC). Automatyzacja. Upewnić się, że X jest tak, jak powinien. To brzmi pięknie na konferencji, ale w praktyce... to jest przesada. Po co nam framework, który ma nas zabezpieczyć przed tym, że zapomnimy sprawdzić parametr? Czasem najlepszą „infrastrukturą jako kodem” jest po prostu szybka linijka w batch, która wykonuje zadanie, o którym wiemy. Po co nam deklaracja stanu, skoro wystarczy polecenie, które to zadanie wykona w locie? CMD, mój drogi, pamięta czasy, gdy trzeba było tylko uderzyć w celu, nie budując do niego dziesięciu modułowych fundamentów.
A ten cały patos o CI/CD i GitOps... „Skrypt uruchamiany przez pipeline jest już częścią procesu 'GitOps'”. Tak, to jest piękne. To jest też bardzo... przewymiarowane. Żeby upewnić się, że mały, szybki, ale idealny poleceń zadziała, muszę przeszukiwać repozytorium, pisać testy jednostkowe dla pojedynczej kontroli i integrować to z platformą, która zajmie się zarządzaniem mojego zapomnianego napisu na konsoli. To nie jest optymalizacja, to jest biurokracja technologiczna.
🚀 Podsumowując (i zrzucając garnitur akademika)
Jeśli masz pewność, że Twoje zadanie jest proste, potrzebujesz szybkiego wyniku i nie chcesz spędzić trzech dni na architekturowaniu niezawodnego, modułowego kosmicznego systemu zarządzania pojedynczym adresem — nie uczy się tego na seminariach. Ucz się tego na cmd, który potrafi zrobić to zadanie szybciej i z mniejszą ilością błędów, niż próbujesz z niego zbudować skomplikowany Moduł czy manifest DSC. Debugowanie złożoności jest często bardziej czasochłonne niż samo wykonanie pierwotnego, prostego polecenia. Być może na poziomie „eksperckim” chodzi po prostu o spryt, a nie o liczbę warstw abstrakcji.