W pierwszej części mojej rozmowy z Przemkiem Rogalą, twórcą bloga TTL255, rozmawialiśmy o egzaminie DEVASC i certyfikacji Cisco DevNet. Certyfikaty byłby jednak zbędne, gdyby nie rzeczywiste projekty, w których wiedzę i doświadczenie zamienia się na konkretne rozwiązania. Zarówno Przemek jak i ja realizujemy tego typu projekty, choć na innych rynkach. W drugiej części mojej rozmowy skupimy się właśnie na rzeczywistym wykorzystaniu automatyzacji, projektach, programowaniu i narzędziach, które wykorzystujemy.
Świat automatyzacji i niezbędne narzędzia - spojrzenie sieciowca
Odejdźmy od samego egzaminu. Widzę na łamach TTL255 wiele wpisów poruszających tematy i produkty jedynie "liźnięte" w curriculum DevNet takie jak Ansible, Jinja2 czy konteneryzacja. Jak postrzegasz role narzędzi bardziej kojarzonych z programistami czy zarzadzaniem systemami i aplikacjami z automatyzacja infrastruktury sieciowej?
To jest bardzo dobre pytanie, bo wpisuje się w ogólny trend próby zdefiniowania roli osoby zajmującej się automatyzacją sieci. Z jednej strony mamy tych, którzy zawodowo są programistami i teraz specjalizują się w automatyzacji sieci, dla nich te narzędzia to oczywistość. Pośrodku mamy ludzi, którzy dość dobrze znają oba światy, większość z nich zaczęli, jako sieciowcy. Oni starają się poduczyć procesów i pożyczyć narzędzia, które sysadmini i programiści używają od dawna. Trzecia grupa to sieciowcy, którzy chcą sobie ułatwić życie, czasem polepszyć pozycję zawodową, głównie konsumując narzędzia stworzone przez poprzednie grupy, ale także próbujący pisać proste skrypty, odpytywać APIs i uczyć się narzędzi jak Git.
To bardzo ogólny podział i omija rosnącą grupę tych, którzy wchodzą w świat infrastruktury już używającą automatyzację, dla nich to tak naturalne jak CLI było w świecie sieci parę lat temu.
Bez narzędzi tradycyjnie używanych przez programistów byłoby trudno tworzyć sensowne rozwiązania automatyzujące sieci. Jak wyjdziemy poza 100-200 linii kodu Pythona, rzeczy zaczynają się komplikować bardzo szybko. Dodaj do tego kilku inżynierów dzielących bazę kodu i nagle się okazuje, że bez Dockera, Gita, CI/CD, Ansible, linterów i wielu innych narzędzi, się po prostu nie da pracować.
Jeśli chodzi o DEVASC, to moim zdaniem jest on stworzony z myślą o drugiej i trzeciej grupie inżynierów. Druga może przetestować swoją wiedzę i poduczyć Cisco APIs, jeśli ich jeszcze nie zna. Dla trzeciej grupy wyznaczona jest ścieżka, która pozwoli im się przybliżyć do grupy drugiej.
Natomiast powód, dla którego tematy, o których ja piszę nie są zbytnio poruszone w DEVASC wynikają w moim odczuciu z tego, że egzamin jest nastawiony na konsumowanie API i umiejętność rozpoznania, co jest co w świecie automatyzacji. Mamy wiedzieć jak formaty danych wyglądają, jak wysłać zapytania i tworzyć obiekty przez API, I ogólnie mieć rozeznanie w dostępnych technologiach i narzędziach.
W tym kontekście „liźnięcie” jest wystarczające. Jeśli umiem uruchomić kontener z gotowego obrazu, odpytać API i napisać prosty Ansible Playbook to i tak umiem zrobić więcej niż większość tradycyjnych sieciowców.
Na pocieszenie widzę w curriculum do egzaminów DEVCOR, i zwłaszcza DEVOPS, jest większy nacisk na narzędzia i techniki deweloperskie.
Zagłosuj na blog Przemka
Blog Przemka, TTL255, znalazł się w finale konkursu 2020 IT Blog Awards organizowanego przez Cisco. Możecie zagłosować na jego kandydaturę - kliknijcie na ikonę by przejść do strony głosowania.
Czy sieciowiec musi umieć programować?
4 lata temu na PLNOG17 Robert Ślaski wygłosił bardzo fajną sesje "Jak nie zostać bezrobotnym sieciowcem" i pokazał jak stajemy się programistami. Pól roku później z Robertem zrobiliśmy sesje o tym jak wejść w świat programowania. Czy czujesz, ze programowanie stało się ważną i niezbędną umiejętnością sieciowca? Czy czujesz się w jakiś sposób programistą?
Czy ważną? Zdecydowanie. Czy niezbędną? Będę trochę przekorny i powiem, że zależy. Zależy, bo czy Ansible oparty na YAML i JINJA2 może być uznany za język programowania? Moim zdaniem nie, ale znając sam Ansible można naprawdę sporo zrobić. Dorzućmy do tego AWX/Tower i mamy narzędzie, które może nam zautomatyzować sieć i zintegrować się z resztą naszych systemów.
Natomiast nawet podstawowa znajomość programowania pomoże nam być bardziej efektywnym w pracy i otworzy nowe ścieżki kariery. Jest coraz trudniej być specjalistą w tylko jednej dziedzinie, gdy technologie zmieniają się jak w kalejdoskopie. Umiejętność szybkiej adaptacji i poszerzania naszego zestawu narzędzi pracy będzie miała coraz większe znaczenie. Wpisuje się to w trend „T-shaped skills”, szeroka podstawa wiedzy z wielu technologii i głębsza znajomość jednej.
Mówiąc o mnie, gdy zaczynałem dłubać pisząc proste skrypty nie czułem się programistą. Po kilku latach programowania i nauki narzędzi ze świata deweloperskiego nie boję się już mówić o sobie, że jestem programistą automatyzującym sieci.
Ta linia, po której przekroczeniu zostajemy programista jest arbitralna, wiele osób, które weszły w automatyzację zmaga się z syndromem oszusta. Prawda jest taka, że jak czujesz się programistą to nim jesteś. Na koniec dnia twoje projekty powiedzą o tobie więcej niż etykiety i nazwa stanowiska
Jaka była twoja przygoda z programowaniem? Bardzo dużo osób się boi programować bądź wynosi, moim zdaniem często uzasadniony, uraz do programowania ze szkoły i studiów.
Spotkałem się z tą obawą, wręcz alergią do programowania. Rozmawiałem z absolwentami tutejszych uniwersytetów i coś w tym jest. Moja teoria, oparta na małej próbce, to to, że programowanie jest często nauczane bez kontekstu. Suche fakty i przykłady pętli od 1 do 10 dodającej produkty sklepowe do listy. Tudzież programowanie obiektowe oparte na implementacji hierarchi zwierzaków w ZOO. A tutaj mamy ludzi, którzy poszli studiować sieci, robią CCNA-CCNP w ramach zajęć, i oni nie widzą jak ma się jedno do drugiego.
Część z tych problemów wynika ze sztywno narzuconego programu, niezależnie od kierunku uczy się Pythona tak samo. Trudno też nauczyć coś sensownego w dedykowanym wymiarze godzin. Generalizuję tutaj oczywiście i mówię tylko o moich doświadczeniach.
Moja przygoda zaczęła się w liceum. Pisałem sobie małe programy w Pascalu, potem były proste gry w C. Nie było w tym czasie takiego dostępu do materiałów i niedługo potem przeprowadziłem się do UK, więc zawiesiłem swoje przygody na wiele lat. Po drodze miałem kurs z Javy na uniwersytecie, ale o tym zapomniałem zaraz po egzaminie, Java nie była mi pisana.
Z tych przygód natomiast została mi świadomość, że programowanie pozwala nam skodyfikować ręcznie wykonywane procedury. Gdy wszedłem w świat sieci szybko zdałem sobie sprawę, że nie muszę ręcznie logować się do urządzeń, żeby sprawdzić element konfiguracji, bo mam przecież kopię na serwerze. Tak pojawia się grep, find, awk, sed. bash. Niedługo potem odkryłem Pythona i nie mogłem uwierzyć jak dużo można zrobić z podstawową wersją bibliotek. I tak wstąpiłem na ścieżkę, na której jestem do dziś, bezustannego uczenia się programowania, narzędzi i technik deweloperskich.
Dodam też, że chyba utarło się przekonanie, że programowanie to ciemna magia porównywalna do fizyki teoretycznej, która wymaga 5-letnich studiów i IQ 130+. I tutaj programy jak Cisco DevNet, NRE Labs od Junipera, i duża społeczność na Twitterze, naprawdę pomagają w pokazaniu, że to wcale tak nie jest, każdy może nauczyć się podstaw. Nauczyłeś się CLI i protokołów, które przecież są oparte na algorytmach, to możesz nauczyć się Python, Ansible i YAML/JSON. I to działa, coraz więcej osób próbuje swoich sił i dzielą się wrażeniami na mediach społecznościowych.
Automatyzacja w IT - czy Polskę do Europy zachodniej dzieli przepaść?
Przyznałeś mi się jakiś czas temu, że nigdy nie pracowałeś na rynku polskim. Jak wygląda wdrażanie automatyzacji szeroko pojętej infrastruktury sieciowej tam gdzie pracujesz? Czy dużo jest tego typu projektów? Jakiego typu są to projekty i o jakiej skali?
W UK na chwilę obecną praktycznie większość średnich i dużych firm albo ma jakąś formę automatyzacji sieci, albo jest w trakcie wdrażania. Podejść jest dużo, ale z rozmów z kolegami i ogólnych trendów widać, że Ansible wychodzi na przód stawki, często z Tower w tandemie. Jest bardzo dużo Pythona, często, jako warstwa pośrednia, która pozwala różnym systemom komunikować się ze sobą.
Firmy mające więcej pieniędzy czasami idą drogą gotowych produktów jak Cisco NSO, Cisco ACI, czy też Apstra którą właśnie przejął Juniper. Problem pojawia się, gdy mamy urządzenia od różnych producentów, co jest trudne do uniknięcia z SD-WAN, firewallami i wysypem różnego rodzaju rozwiązań softwarowych. Do tego dorzućmy świat serwerów i chmury i wiele firm odkrywa, że nie ma gotowego produktu, który im to może wszystko kontrolować. W tym momencie wkraczają ludzie dobrze znający Python i od niedawna także Go, i zaczynają dodawać kod, który łączy różne systemy.
Jeśli chodzi o skalę to mamy tu wszystko od generowania raportów i konfiguracji przez aplikowanie konfiguracji na urządzeniach do „closed-loop automation”. To ostatnie to święty Graal automatyzacji, ale bardzo mały procent firm to ma na chwilę obecną.
Większość projektów też skupia się na automatyzacji projektów greenfield, i tutaj jest dużo sukcesów i dostępne gotowe produkty. Próba wdrożenia automatyzacji istniejącej infrastruktury to wieloletnie projekty gdzie dużo czasu idzie na spisywaniu procedur i inwentaryzacji. W tych projektach także się okazuje, że automatyzacja nie ma żadnych szans powodzenia bez przeszkolenia i przekonania czynników ludzkich. Wszystkie warstwy biznesu muszą zrozumieć, dlaczego to jest ważne i brać udział w procesie.
Na jakie aspekty automatyzacji zwraca się szczególna uwagę w projektach, które realizujesz, lub z którymi miałeś styczność?
W miejscach, które zaczynają automatyzację nacisk jest na szybkie wyniki. Nazywamy to „small wins”, odpytanie 300 urządzeń i zwrócenie wersji systemu i numeru seryjnego, zmiana serwera SNMP na następnych 500 pudełek. Chodzi o to, by pokazać członkom zespołu i biznesowi, że od początku możemy usprawnić proces i uzyskać pożyteczne dane.
Następny krok w wielu firmach to stworzenie „źródła prawdy”, bazy danych z pełnym inwentarzem urządzeń, adresów, lokacji itd. Tutaj open sourcowy NetBox robi furorę i staje się centralnym punktem automatyzacji dla wielu.
Inne ważne elementy to integracja z systemami używanymi przez rożne departamenty naszego biznesu. Nasz system automatyzacji musi komunikować się z aplikacjami takimi jak ServiceNow, Slack, Splunk, Nagios, Prometheus/Grafana, Jenkins, ActiveDirectory i całą rzeszą innych programów. Bez tego dość szybko przestaną się nam te systemy zgadzać, co do stanu naszej infrastruktury.
Z punktu widzenia użytkownika ważny jest interfejs. Spójny interfejs, głównie webowy, z większością funkcjonalności dostępną w jednym miejscu. Końcowy użytkownik powinien być w stanie szybko opanować system i być produktywnym. Nacisk jest na zminimalizowanie możliwości pomyłek o które łatwo gdy się używa skryptów.
Ze strony implementacyjnej. Logowanie, weryfikacja przed i po aplikowaniu zmian, rollback, CI/CD, są także bardzo ważne.
Dziekuje Ci bardzo za rozmowę.
Cała przyjemność po mojej stronie.
E-BOOK
Zaczynasz swój pierwszy projekt związany z automatyzacją?
Ten e-book jest dla Ciebie! Zawiera sprawdzone podejście, które realizowałem w wielu projektach. Sprawdź co możesz zrobić, by odnieść sukces!
