POIT #120: Automatyzacja i programowanie w świecie infrastruktury

Witam w sto dwudziestym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest automatyzacja i programowanie w świecie infrastruktury.

Dziś moim gościem jest Piotr Wojciechowski – konsultant IT, architekt rozwiązań sieciowych, programista, entuzjasta rozwiązań chmurowych. Partner w firmie inleo. Zajmuje się zagadnieniami z zakresu routingu, switchingu, IP/MPLS, SDN oraz cloud computing. Blogger. W wolnym czasie developer w projektach open-source (m.in. Ansible). Miłośnik kotów i muzyki elektronicznej.

W tym odcinku o automatyzacji i programowaniu w świecie infrastruktury rozmawiamy w następujących kontekstach:

  • czym jest infrastructure as a code?
  • czy można programować tradycyjną infrastrukturę nie będącą w chmurze?
  • co w tym temacie wprowadza filozofia DevOps?
  • dlaczego ludzie od infrastruktury muszą stać się programistami?
  • co dzięki programowaniu i automatyzacji zyskujemy jako firma i jako osoba, która infrastrukturą się zajmuje?
  • jakie narzędzia typu open-source i komercyjne są obecnie wykorzystywane do programowania i automatyzacji infrastruktury?
  • jakie języki programowanie się najczęściej wykorzystuje?
  • jakie inne praktyki z software developmentu są wykorzystywane w przypadku infrastruktury?
  • czy kod operujący na infrastrukturze również się testuje?
  • czym jest ścieżka certyfikacji DevNet?
  • na co zwracać uwagę planując swoją karierę w tym obszarze?
  • czy ten trend automatyzacji infrastruktury i jej programowania będzie się utrzymywał?

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, które wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)

Transkrypcja podcastu

To jest 120. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o automatyzacji i programowaniu w świecie infrastruktury.

Przypominam, że w poprzednim odcinku rozmawiałem o języku P4 i programowaniu urządzeń sieciowych. 

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/120.

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut.

 

Partnerem odcinka jest Apptension, firma specjalizująca się w budowie świetnie zaprojektowanych produktów cyfrowych. Apptension opakowuje dziwne pomysły w nowoczesne technologie, po czym doprawia je najlepszym na rynku designem. Zresztą zerknij na ich portfolio na behance.net/apptension.

 

Ja się nazywam Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi właśnie ten podcast. Zostając patronem na platformie Patronite, możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły. 

Jednocześnie bardzo dziękuję moim obecnym patronom.

A teraz życzę Ci już miłego słuchania.

Odpalamy!

 

Cześć! Mój dzisiejszy gość to konsultant IT, architekt rozwiązań sieciowych, programista, entuzjasta rozwiązań chmurowych, partner w firmie Inleo, zajmuje się zagadnieniami z zakresu routingu, switchingu, IP MPLS, SDN oraz cloud computingu. Bloger, w wolnym czasie deweloper w projektach open source, między innymi Ansible. Miłośnik kotów i muzyki elektronicznej. Moim i Waszym gościem jest Piotr Wojciechowski.

Cześć, Piotrze! Bardzo miło mi gościć Cię w podcaście.

 

Cześć! Dziękuję za zaproszenie, witam wszystkich słuchaczy.

 

Padło tu dużo pojęć, ale wszystko prowadzi nas do tematu tego odcinka, którym jest automatyzacja i programowanie w świecie infrastruktury. Ale zacznijmy od standardowego elementu każdego mojego podcastu, czyli od pytania do Ciebie, Piotrze. Czy słuchasz podcastów? Jeśli tak, to może masz swoje ulubione audycje?

 

Praktycznie cały czas w ciągu dnia leci jeden podcast, on się nazywa DnbRadio, dlatego że dla mnie muzyka jest tłem do wykonywania prawie wszystkich czynności, także tych zawodowych. Czasami nawet zapominam wyłączyć muzykę na czas jakichś calli. Muzyka z tych podcastów, bo to są sety didżejskie, które trwają po trzy godziny, jest dobrym motywatorem do tego, żeby się skupić na pracy, bo gadanie mnie trochę bardziej rozprasza.

Z bardziej gadających podcastów, to okazjonalnie tylko słucham Cyber, Cyber, jak się pojawiają dobre tematy, również niektórzy goście u Ciebie. Z takich nie informatycznych, powiedzmy, około informatycznych rzeczy lubię podcast Mała Wielka Firma. Inne rzeczy tylko punktowo, jak się pojawi jakiś temat, który chcę zgłębić i okazuje się, że jest to w formie podcastu, a nie tylko czytania, to ewentualnie wtedy szukam i odsłuchuję. Chociaż chyba wolę książki.

 

Jasne, ja też nie potrafię pracować i jednocześnie słuchać rozmów. To angażuje pewnie podobną część mózgu, więc bardzo ciężko jest mi się skupić na jednym albo na drugim, a takie przeskakiwanie też nie jest efektywne.

Chciałbym Cię zapytać o taką rzecz, o której coraz więcej się słyszy, która przybliża trochę świat infrastruktury i programowania, czyli definiowanie infrastruktury kodem. Infrastructure as a code – to pojęcie jest coraz modniejsze. Chciałbym Cię poprosić o to, żebyś trochę przybliżył, czym to podejście jest, czym się charakteryzuje, na jaki problem odpowiada?

 

Jeżeli spojrzymy na infrastrukturę historycznie, to mamy jednak hardware. Hardware, który kojarzy się wszystkim z niebieskim kablem konsolowym do portu Cisco i zaczynamy konfigurować to urządzenie. W naszym nowoczesnym świecie, gdzie budowa aplikacji to nie jest wypuszczanie produktu raz na pół roku, tylko to są bardzo dynamiczne zmiany, które muszą odzwierciedlać się w infrastrukturze, musimy zacząć programować infrastrukturę od samego budowania jej. 

Oczywiście chmura publiczna bardzo tutaj pomogła, tam nie mamy fizycznego sprzętu, do którego się dostajemy. Nawet ten tradycyjny sprzęt sieciowy, który jest wirtualizowany, można już nie konfigurować ręcznie, ale wpisać w cały proces budowania infrastruktury dla konkretnej aplikacji. Infrastruktura bez aplikacji nie ma sensu, jak i aplikacja bez infrastruktury nie ma sensu. 

Te dwa środowiska połączyły się ze sobą już bardziej ściśle. Używając konkretnych języków programowania, nazwijmy to tak szeroko, po prostu wpisujemy proces budowania zwirtualizowanej infrastruktury dla tej aplikacji. Niezależnie czy ta infrastruktura będzie na koniec na tak zwanym bare metalu, czy będzie rzeczywiście zwirtualizowana, czy całkowicie w chmurze, jest programowana po to, żeby spełniać wymogi tej aplikacji i reprogramowana wraz ze zmianą tej aplikacji bądź potrzeb, które się pojawiły w czasie jej eksploatowania. Jednak to biznes narzuca nam, co jako informatycy robimy.

 

Tak, dokładnie. Usłyszałem o tym po raz pierwszy kilka lat temu na konferencji. Oczywiście wtedy pokazywano przykład, jak mniej więcej użyć infrastructure as a code po to, by definiować taką infrastrukturę działającą w chmurze. Myślę, że wielu osobom to skojarzenie przychodzi na myśl jako pierwsze, kiedy słyszą infrastructure as a code, czyli chmura. Ale okazuje się, że z wykorzystaniem tego podejścia możemy też programować tradycyjną infrastrukturę, o której na początku powiedziałeś. Czy to faktycznie jest równie popularne i czy te dwa podejścia różnią się od siebie, czy też nie ma to żadnego znaczenia?

 

Efektem końcowym zawsze jest fizyczne czy wirtualne urządzenie sieciowe, które ma wgraną jakąś konfigurację. Patrząc na tradycyjne rozwiązania, które mamy, to nadal jednak to urządzenie gdzieś istnieje. To jest kwestia tego, w jaki sposób zarządzamy tym urządzeniem, jak szybko jesteśmy w stanie wprowadzić zmiany, zrekonfigurować bądź postawić nowe urządzenie od podstaw. I to rzeczywiście działa w ten sposób, że na koniec wynik, który otrzymujemy nie różni się dużo od tego, co robimy. Natomiast możemy szybciej reagować na pewne rzeczy.

Jeżeli używamy zaawansowanej telemetrii, możemy zautomatyzować proces rekonfiguracji infrastruktury po to, żeby szybko odpowiadać na pewne zdarzenia, które wykrywają systemy monitoringu. Jeżeli mówimy o wdrożeniu czy skalowalności pewnego systemu teleinformatycznego, to automatyzacja pozwala nam wykonać zmianę, na którą kiedyś potrzebowaliśmy dwa tygodnie w dwie godziny. Jeżeli potrzebujesz zwirtualizować liczbę firewalli, bo Twoja infrastruktura już nie jest w stanie wyrobić z ilością nachodzących pakietów z politykami, jesteśmy w stanie to szybko zrobić. Przenieść polityki – nie ma problemu, odwzorowujemy je, ponieważ one są gdzieś zaprogramowane, opisane. 

Jednocześnie mamy dodatkowy element bezpieczeństwa związany z tym, że gdzieś jest repozytorium tego, w jaki sposób ta infrastruktura jest programowana. W związku z tym możemy śledzić te zmiany wstecz, możemy wprowadzać poprawki, możemy testować na osobnych środowiskach poprawki, które są wprowadzane i wpisać je w cały model życia tej sławnej aplikacji, dla której to wszystko budujemy.

To też zależy, co robimy. Są systemy komercyjne, są systemy open source’owe. Systemy komercyjne próbują jeszcze bardziej zdjąć tę inżynierską część pracy dając, nie chcę powiedzieć: „pani sekretarce”, portal do wyklikiwania infrastruktury. Ale już od wielu lat, jak przychodzimy do jakiegokolwiek biura, mamy sieć guestową. To nie informatyk generuje nam dostęp do guestowego WiFi. Robi to recepcja, mimo że osiągnięcie tego wymaga pewnych czynności automatycznych. Wykreowanie konta, danie dostępu, przydzielenie odpowiednich uprawnień temu gościowi to czynności, które wykonywane są w sposób automatyczny na systemach IT.

Po części idea przejścia w automatyzację ma też przenieść ciężar budowania systemu IT czy wyklikiwania jego warunków brzegowych co najmniej z poziomu technicznego na poziom biznesowy. Nie widzę docelowo problemu, żeby to project manager powiedział na podstawie tabel – myślę, że każdy project manager powinien umieć zanalizować tabelkę – że początkowo potrzebujemy jakąś grupę wirtualnych urządzeń, na których to będzie działało. Potem możemy to dalej skalować oczywiście.

 

Rozumiem. Dotknąłeś tu dwóch obszarów, mianowicie infrastruktury i osób standardowo odpowiedzialnych za infrastrukturę oraz aplikacji tworzonych przez programistów. Czyli dwa światy, które do tej pory były może nie antagonizujące, ale bardzo często zrzucające odpowiedzialność za pewne niedoróbki na siebie nawzajem. Był rozdźwięk, rozstrzał pomiędzy programistami i osobami, które później uruchamiały to na przykład tworząc infrastrukturę. Jedni i drudzy za mało wiedzieli o swojej pracy, żeby zrozumieć z jakimi problemami na co dzień się mierzą. Oczywiście jakiś czas temu pojawiła się filozofia czy też podejście DevOps, które trochę zasypuje te różnice. Chciałbym Cię zapytać, jak Ty to widzisz ze swojej pracy. Czy te podziały są na tyle znaczące, że to widać? Czy wprowadzenie rozwiązań automatyzacji infrastructure as a code może przybliżyć jeden i drugi obóz do siebie?

 

Musi przybliżyć, bo jak tego nie przybliży, to nic nie osiągniemy, a zrobimy sobie nawzajem tylko krzywdę. Masz rację, że światy programistów i ludzi od infrastruktury były bardzo od siebie oddalone. Brak zrozumienia po części wynika moim zdaniem z błędów w nauczaniu. Na poziomie uniwersytetów czy politechnik jest za dużo matematyki, która się przydaje tylko naukowcom, a nie w praktycznych umiejętnościach zawodowych. Umiejętności programistycznych uczy się trochę w oderwaniu od technologii, z którymi programiści będą obcowali. Kończymy na tym, że programista pisząc aplikację sieciową w ogóle nie rozumie, jak działa sieć i mechanizmy. Skrajnym przypadkiem, wielokrotnie przeze mnie spotykanym jest to, że programiści próbują otwierać sesję TCP i trzymać ją w nieskończoność. A potem się dziwią, że włącza się firewall, aplikacja się rozjeżdża i winią infrastrukturę. Nie rozumieją tych podstawowych metod. Tego dialogu już od dawna brakowało.

 

Masz rację, że światy programistów i ludzi od infrastruktury były bardzo od siebie oddalone. Brak zrozumienia po części wynika moim zdaniem z błędów w nauczaniu. Na poziomie uniwersytetów czy politechnik jest za dużo matematyki, która się przydaje tylko naukowcom, a nie w praktycznych umiejętnościach zawodowych. Umiejętności programistycznych uczy się trochę w oderwaniu od technologii, z którymi programiści będą obcowali. Kończymy na tym, że programista pisząc aplikację sieciową w ogóle nie rozumie, jak działa sieć i mechanizmy. 

 

Rzeczywiście, wchodząc w automatyzację, świat infrastruktury musi przyjąć programistyczne podejście, czyli musi nauczyć się Gita, musi rozumieć, jak działają repozytoria, musi rozumieć mechanizmy automatyzacji oraz to, jak działają kontenery. Mimo że kontenery nie są częścią infrastruktury sieciowej, mogą być elementem w niektórych routerach, gdzie aplikacja może być wyniesiona. Mamy cały świat, który ludzie od infrastruktury muszą zrozumieć, ale jednocześnie deweloperzy muszą zacząć rozmawiać z ludźmi od infrastruktury na temat tego, jak można zrobić coś dobrze albo lepiej, w jaki sposób można wykorzystać infrastrukturę albo czego nie wolno robić.

DevOps, o którym wspomniałeś, rzeczywiście wymusza zderzenie tych dwóch światów. To zderzenie może być czasem bardzo bolesne, bo to są często ludzie, którzy rozmawiają zupełnie innymi językami. Obracamy się w jednym świecie IT, a korzystamy z innych słowników. W momencie kiedy zaczynamy zderzać te światy ze sobą, to rzeczywiście dochodzi do fajnego porozumienia. Programiści zaczynają rozumieć, że aplikacja nie działa w próżni. To, że te pakiety są przesyłane, jest wynikiem infrastruktury, która ma swoje konkretne ograniczenia. Być może aplikacja musi w jakiś sposób te ograniczenia monitorować, żeby zareagować na poziomie aplikacyjnym, a nie tylko  infrastrukturalnym. Pewne rzeczy, tak jak wspomniana wiecznie żyjąca sesja TCP, to nie jest dobre rozwiązanie. Jednocześnie ludzie, którzy zarządzają czy programują infrastrukturę są w stanie zrozumieć też pewne wymagania deweloperów, ograniczenia języków, bibliotek, które są używane. Czasami może nam się wydawać, że coś jest przecież proste, że to się da zrobić. To nie do końca tak działa.

Jest jeszcze oczywiście cała kwestia związana ze skalowalnością. Ludzie od infrastruktury często nie rozumieją problemów związanych z tym, że aplikacje nie skalują się tylko przez dokładanie kolejnych wątków czy kontenerów do całego rozwiązania. Skalowalność infrastruktury musi też być powiązana z tym, w jaki sposób działa sama aplikacja. Pole do kompromisu, do wzajemnego zrozumienia jest i na pewno wszyscy wyjdziemy z tego trochę mądrzejsi i bardziej poukładani jako świat IT. Zresztą nie wiem, czy zauważyłeś, bardzo często się mówi, że IT to programiści, programiści i ci drudzy, prawda?

 

Właśnie, cieszę się przede wszystkim, że tak optymistycznie do tego podchodzisz. Ja też mam wrażenie, że to idzie w dobrym kierunku, bo faktycznie musimy wrócić do czegoś, co było dosyć oczywiste, kiedy ja zaczynałem karierę w IT. Nazwałbym te osoby, które wówczas pracowały, takimi full stackami, ale przez cały stack technologiczny. To były najczęściej osoby, które nie tylko potrafiły uruchomić aplikację i ogarnąć infrastrukturę, ale również na przykład napisać trochę kodu. Miały takie szersze zrozumienie.

Oczywiście można dyskutować, czy rozwój technologii zablokował możliwość bycia ekspertem we wszystkim. Natomiast w pewnym momencie osiągnęliśmy dużą granulację specjalizacji IT, do tego stopnia, że jedna ręka nie wiedziała, co robi druga. Teraz powoli zaczyna się odwrotny trend, żeby jednak łączyć wiedzę z różnych dziedzin, bo to na skraju powstają zazwyczaj najfajniejsze rozwiązania. Mam wrażenie, że ruch DevOps sporo pomógł. Nie obrażanie się na siebie, ale wzajemne zrozumienie swoich ograniczeń i uwspólnienie języka to jest to, co może nas popchnąć dalej.

 

Ale też budowanie projektów w ten sposób, że jednak project managerowie nie traktują samej infrastruktury jako usługi, która musi być im świadczona, tylko jako element całego projektu. Podejście musi się też zmienić na levelu project managerskim.

 

Z pewnością. Powiedziałeś, że mamy podział na programistów i tych innych.

 

I bezpieczniki jeszcze.

 

Tak, na tych innych. Często słyszę taki zarzut, że przecież branża IT, to nie jest tylko programowanie. Tymczasem my znowu mówimy o programowaniu. Mówimy o infrastrukturze i mówimy o programowaniu, czyli znowu programowanie wdziera się w kolejną branżę. Chcę Cię zapytać, czy faktycznie jest tak, że ludzie od infrastruktury powinni znać programowanie, czy jest to pewien dodatek, który wnosi coś nowego, ale jeszcze nie jest niezbędny? Jak Ty patrzysz na połączenie tych dwóch dziedzin?

 

Powinni, co nie znaczy, że muszą. Oczywiście zawsze mogą, tak jak programiści COBOL-a, czekać bardzo długo, żeby teraz być niezbędnymi na rynku. Pytanie tylko, czy to jest właściwa ścieżka? Trzeba mieć świadomość tego, jakie są trendy i w którą stronę świat IT zmierza. Wystarczy spojrzeć na duże korporacje, które inwestują bardzo dużo pieniędzy w rozwiązania zautomatyzowane, w szerzenie tej wiedzy. Jeżeli nie tylko jedna firma idzie w tę stronę, to znaczy, że coś musi być na rzeczy. Po drugie biznes wymaga tego usprawnienia, ponieważ inaczej brak automatyzacji generuje zbyt duże koszty i firma przestaje być konkurencyjna.

Jako inżynierowie infrastruktury możemy nie wchodzić w automatyzację i próbować sobie znaleźć pewne wąskie działki, które nie zostaną albo w minimalnym stopniu zostaną zautomatyzowane i w tej działce grzecznie siedzieć. Wielu osobom to odpowiada, wiele osób boi się zmian, przyzwyczajeni są do konsoli i taka zmiana jest dla nich pewną rewolucją. Może tych osób nie należy wrzucać na głęboką wodę, tylko dać im czas na spokojną transformację i pozostanie ekspertem w pewnych bardzo wąskich dziedzinach, ale ze zrozumieniem, że ten świat obok istnieje.

Wszyscy musimy stać się programistami tej automatyzacji, ponieważ inaczej docelowo nie będziemy mieli pracy, taka jest prawda. Konfigurowanie przez konsolę przestaje być czymś powszechnym. W dużych systemach mamy zero-touch provisioning, czyli podłączenie i zautomatyzowanie nawet pierwszego etapu konfiguracji jest już czymś bardzo ważnym. Jak spojrzymy wstecz, z punktu widzenia inżynierskiego, to my ograniczamy trochę tę automatyzację do programowania.

Ale spójrzmy na większe projekty. Kiedyś w Excelu były generowane szablony konfiguracji wgrywane na komputery. Jak zaczniemy patrzeć na pewne rzeczy, które wcześniej przygotowywaliśmy, to też jest to jakaś forma automatyzacji naszych czynności. My z tą automatyzacją wbrew pozorom mamy już styczność, tylko my jej nie nazywaliśmy jeszcze nigdy w ten sposób. To teraz nazwijmy rzeczy po imieniu i dodajmy do tego tę aplikację, która zaczyna być ważna, z którą musimy jako infrastruktura współdziałać. 

 

Żeby jeszcze dobitniej zrozumieć to, dlaczego warto – bo tak jak powiedziałeś, może na ten moment jeszcze nie trzeba, ale z pewnością warto, zwłaszcza myśląc o przyszłości – spróbujmy zastanowić się, jakie korzyści daje programowanie i automatyzacja infrastruktury dla takiego inżyniera, który na co dzień zajmuje się infrastrukturą, jak również dla firmy, która ewentualnie w ten sposób będzie swoją infrastrukturę definiować i w ten sposób nią zarządzać.

 

Moim zdaniem, podstawowa zaleta z punktu widzenia inżyniera jest taka, że nauczymy się, jeśli jeszcze nie umiemy, albo udoskonalimy logiczne myślenie. Programowanie jest ściśle związane z algorytmiką, a mam takie wrażenie, że często osoby, które kończą jakieś punktowe kursy produktowe i przechodzą do zarządzania i budowania pewnych systemów, nie mają analitycznego podejścia do tego, co chcą osiągnąć. Jak powinien działać ten mechanizm? Jak powinno się go zaprojektować? Jakie mogą być tego wady i zalety? Takie algorytmiczne myślenie wdrażane już na wczesnych etapach nauki będzie dobre dla architektów, ale także dla ludzi, którzy pracują w centrach operacyjnych. Rozwiązywanie problemów bez sensownego algorytmicznego podejścia do zanalizowania tego problemu tak naprawdę nie ma sensu. To jest trochę rzucanie się w ciemno – może tu jest błąd, a może tu – a nie proces, który następuje. 

 

Programowanie jest ściśle związane z algorytmiką, a mam takie wrażenie, że często osoby, które kończą jakieś punktowe kursy produktowe i przechodzą do zarządzania i budowania pewnych systemów, nie mają analitycznego podejścia do tego, co chcą osiągnąć. Jak powinien działać ten mechanizm? Jak powinno się go zaprojektować? Jakie mogą być tego wady i zalety? Takie algorytmiczne myślenie wdrażane już na wczesnych etapach nauki będzie dobre dla architektów, ale także dla ludzi, którzy pracują w centrach operacyjnych.

 

Oprócz typowych skillów programistycznych, nauczenia się nowego języka, nowych produktów, mamy skille softowe związane z algorytmiką, analityką, które zawsze nam się przydają. Z punktu widzenia inżyniera poznawanie nowych produktów to jest coś, co powinno być elementem naszej codziennej pracy, nawet jeżeli pracujemy w centrum operacyjnym. Powinniśmy poszerzać swoje horyzonty, rozumieć co się dzieje na rynku, w jakikolwiek sposób próbować dotykać nowych produktów. Zresztą praktycznie każdy dostawca chmury publicznej zachęca nas do poznania tych usług oferując darmowy dostęp do wybranych podstawowych usług, dodatkowe pakiety dla studentów, licencje dla studentów.

Oczywiście to jest marketingowe zagranie „poznaj nasz produkt, może zostaniesz”. Ale student wchodzi i ma możliwość zobaczenia, jak się buduje sieć, maszyny wirtualne, systemy load balancingu, systemy bezpieczeństwa w trzech głównych chumrach od trzech głównych dostawców. Nie musi od razu robić certyfikatów w tym kierunku, choć oczywiście może. Natomiast wiedza i pojęcie o tym, jak działa infrastruktura czy właśnie te natywne chmurowe aplikacje, jak ja to nazywam, czyli coś, czego nie osiągniesz we własnym labie, daje naprawdę dużą wiedzę o tym, jakie narzędzia są wykorzystywane. Co za tym idzie, będzie można kreować swoją ścieżkę kariery, dostosowywać do tego, jakie są trendy, ale także lepiej rozumieć wymagania biznesu, który chce z pewnych narzędzi skorzystać bądź właśnie wymagania programistów, którzy będą próbowali z tych narzędzi korzystać. 

Uważam więc, że każdy inżynier powinien starać się codziennie poszerzać swoją wiedzę i wejście w automatyzację na pewno otwiera całe spektrum nowego świata. Oczywiście rozwiązania komercyjne też są rozwiązaniami związanymi z automatyzacją, choć tutaj może być trochę ciężej do wejścia. Prawdopodobnie firma musi kupić szkolenie, ale często vendorzy oferują różnego rodzaju warsztaty, żeby zachęcić do produktu. Ja zawsze mam taką maksymę, że jeżeli szef nie pozwala ci się rozwijać, to zmień pracę. Jeżeli nie pozwala nawet uczestniczyć w darmowych warsztatach, to jest to żółte światło, że może coś jest jednak nie tak.

Jeżeli firma nie będzie automatyzować czynności, to nie będzie redukować kosztów. Redukcję kosztów można oczywiście zrobić przez zwolnienia, ale zwolnienia są wtedy, kiedy brakuje zleceń. Zleceń brakuje dlatego, że firma jest za droga na rynku, nie jest konkurencyjna i koło się zamyka. Musimy automatyzować czynności, dlatego że inni to robią. Jeżeli nasz konkurent potrafi wykonać konfigurację w czasie o połowę krótszym od nas albo angażując połowę zespołu, to automatycznie będziemy drożsi. Musimy albo obniżać ceny, ciąć zatrudnienie i pensje, szukać oszczędności w innych działach, albo konkurować tym, że jesteśmy w stanie to wykonać lepiej, szybciej, taniej korzystając właśnie z różnego rodzaju narzędzi zautomatyzowanych.

Automatyzacja może być zarówno związana z operacjami, utrzymywaniem infrastruktury, sprawdzeniem, testami bezpieczeństwa, jak i z budowaniem czy obrabianiem danych, których potrzebujemy na końcu do wykonania ręcznej konfiguracji. Oczywiście rozmawiamy tutaj o automatyzacji w infrastrukturze, ale dane, które będziemy wykorzystywali, liczbę serwerów, numery VLAN-ów, sprawdzenie, czy się nie pokrywa adresacja, która została wstępnie nadana też można zautomatyzować. Są to akurat czynności, które potencjalnie można wykonać skończoną liczbą studentów, ale po co? Taniej jest jednak maszyną wirtualną, która za nas to wykona, a zatrudnionego studenta lepiej rozwijać w bardziej fachowych rzeczach niż analizowanie tabelek Excela.

 

Przyszło mi na myśl, że kolejnym benefitem może być pewna standaryzacja infrastruktury za pomocą kodu, dzięki czemu nowym osobom w zespole łatwiej jest zrozumieć, co się dzieje. Ograniczamy wiedzę plemienną polegającą na tym, że jest jeden super informatyk, super admin, który potrafi zaczarować w konsoli. Jest to bardziej przejrzyste, bardziej udokumentowane, bardziej jawne dla nowych osób. To kolejna przewaga, która może zmniejszyć na przykład ryzyko rotacji w firmie i utraty wiedzy. Nie wiem czy się ze mną zgodzisz?

 

Tak. Wspomniałeś o utrzymaniu infrastruktury, ja bym to nawet rozszerzył do budowania nowych projektów. Jeżeli mamy czynności powtarzalne, które są w większości projektów wdrażanych u klientów i będą one zautomatyzowane, to mamy ustandaryzowany produkt, z którym łatwiej pójść do klienta. Idziemy i pokazujemy, że wdrażamy bezpieczeństwo, mamy swoje template’y do wdrożenia i sprawdzenia reguł bezpieczeństwa na firewalla, skalowania tych firewalli czy wykonywania okresowych testów. To są nasze standardy, jest to fajnie opisane i mamy x zadowolonych klientów, którzy z tego korzystają. Na podstawie tych szablonów tworzymy ustandaryzowaną usługę, którą zawsze jest łatwiej sprzedać niż każdemu klientowi oferować coś bardzo unikalnego.

 

Jasne, oczywiście, że tak. Z programowaniem jest tak, że ta umiejętność wymaga czasu, zaangażowania i wielu ćwiczeń, żeby być sprawnym w posługiwaniu się językiem programowania, w zrozumieniu tych konceptów. Takie podejście, kiedy pewnego dnia szef decyduje, że teraz będziemy wszystko automatyzować za pomocą kodu, nie jest najlepsze. Dobrze by było, gdyby inżynierowie pracujący nad infrastrukturą mieli czas, żeby się nauczyć tej umiejętności, poznać ją trochę, poeksperymentować. Chcę Cię zapytać o to, jak zachęcić inżyniera, który zajmuje się infrastrukturą do tego, żeby zainwestował swój dodatkowy czas w to, żeby poznać narzędzia programowe pozwalające mu automatyzować? Jak przekonać taką osobę, żeby zrozumiała, że to jest inwestycja w przyszłość, w rozwój?

 

Opieram się tutaj w dużej mierze na swoich projektach, na produktach open source’owych. Przy produktach komercyjnych zazwyczaj jest tak, że firma odgórnie decyduje się na wdrożenie konkretnego produktu, ponieważ widzi w sprzedaży jakąś wartość biznesową, zostało tak sprzedane. W związku z tym dziś systemy automatyzacyjne dużych korporacji mogą być wdrażane i tutaj produkt jest trochę narzucony. Więc trzeba raczej przekonać inżyniera, żeby chciał korzystać z tego produktu niż przekonywać do własnej automatyzacji. 

Przekonanie do tego, że warto wejść i poszerzać swoje horyzonty jest wtedy, kiedy inżynier zaczyna widzieć wartość dodaną do pracy, zarówno w swojej karierze, jak i dla całej firmy. I nie może to być metoda straszenia, bo widziałem już takie przykłady pod tytułem: „Wszyscy się automatyzują, to my musimy, bo jak nie, to będą zwolnienia”. No nie, to jest już skrajna patologia, niestety takie rzeczy też się dzieją, że automatyzacja w firmie z jednej strony jest wprowadzana bez przemyślenia, a z drugiej strony jest siłą narzucana inżynierom. Inżynierowie muszą zrozumieć i poznać wartość. 

To jest proces, w którym pokazujemy, co można zrobić, dlaczego coś robimy, w jaki sposób to robimy, żeby oni potem przełożyli pewne, nie chcę powiedzieć hasła i slogany, ale pewne pokazy, bo ja lubię prezentować tego typu rzeczy na podstawie demo. Ty mi skonfiguruj pięćdziesiąt switchy, a ja Ci to zrobię skryptem – to jest namacalny dowód, który każdy jest w stanie poczuć, że jeżeli tego nie będzie robił, to zostaje gdzieś w tyle. I dalej składamy z takich klocków podejście do tego, co możemy zrobić. Szukamy benefitów dla firmy i dla konkretnego projektu. Czasem dla konkretnego projektu możemy zrobić coś szybciej, a czasami zrobimy to jednocześnie dla dziesięciu klientów, a nie dla dwóch w tym samym czasie. Szukamy tego typu benefitów. I szukamy w jaki sposób zachęcić ludzi, żeby te systemy automatyzacji tworzyli. 

W przypadku rozwiązań open source’owych jest to cykl, który dzieje się wewnątrz firmy, nie kupujemy produktu. Nawet jeśli weźmiemy przykładowo Ansible’a, mamy masę playbooków, z których możemy skorzystać, ale większość to są i tak opublikowane szablonowe rozwiązania, które na koniec musimy dostosować do swoich potrzeb. Jeżeli mamy projekt, w którym musimy zmienić description na wszystkich portach przełączników, a mamy ich w sieci tysiąc, to nawet jeśli mamy szablon nadal musimy dopracować cały skrypt, żeby spełniał nasze założenia, był bezpieczny, a najlepiej jeszcze, żebyśmy wiedzieli jak zautomatyzować bezpiecznie jego uruchamianie. Nawet jeśli mamy zautomatyzowany proces, to musimy mieć jeszcze infrastrukturę, która będzie tę automatyzację obsługiwała, a co ciekawe na tej infrastrukturze możemy się najlepiej uczyć automatyzacji. 

Uczmy się nowych produktów. Jeżeli potrzebujemy Ansible’a, to nauczmy się go postawić, jeżeli potrzebujemy Jenkinsa, nauczmy się go postawić, zobaczmy jak to się robi, a może zarządzajmy już od razu tym Jenkinsem w sposób zautomatyzowany. Ja pokazuję, i to pokazuję ludziom od sieci, mojego domowego laba, w którym Jenkins buduje się sam codziennie z repozytorium i aktualizuje się na moim serwerze, bo stwierdzam, że chcę mieć zawsze działającą najnowszą wersję. Budowa Jenkinsa odbywa się w samym Jenkinsie, więc jest pokazane, jak te narzędzia można ze sobą wykorzystywać, łączyć. Jest do tego oczywiście GitLab, gdzie jest repozytorium skryptu Jenkinsa, ale to już jest namacalny dowód, że coś się dzieje, że ja nie muszę wykonywać tych czynności. Budując ten system automatyzacji, buduję własną infrastrukturę, która już się na tej automatyzacji opiera w jakiś sposób. I to jest pierwsze wejście. Jeżeli coś zepsujemy w Labie, to spoko, to jest pole do nauki, przynajmniej powinno być pole do nauki. Gorzej jak Lab jest na infrastrukturze klienta, to już nie jest dobry pomysł. Ale mamy pole do nauki, w ramach którego możemy popełniać błędy i zobaczyć namacalnie, że automatyzacja infrastruktury działa, czy to u nas na serwerze czy w chmurze publicznej.

 

Budując ten system automatyzacji, buduję własną infrastrukturę, która już się na tej automatyzacji opiera w jakiś sposób. I to jest pierwsze wejście. Jeżeli coś zepsujemy w Labie, to spoko, to jest pole do nauki, przynajmniej powinno być pole do nauki. Gorzej jak Lab jest na infrastrukturze klienta, to już nie jest dobry pomysł. Ale mamy pole do nauki, w ramach którego możemy popełniać błędy i zobaczyć namacalnie, że automatyzacja infrastruktury działa, czy to u nas na serwerze czy w chmurze publicznej. 

 

Ta standaryzacja, o której wspomniałeś, jest także dodatkową wartością w przypadku, kiedy mamy środowiska, które są oparte po części na on-premie, po części na chmurach publicznych, takie typowo hybrydowe rozwiązania. Możemy zobaczyć, jak korzystając z jednej bazy wiedzy zapisanej na GitLabie, możemy wdrażać te same procesy bardzo szybko w różnych środowiskach. To jest do przetestowania najpierw w Labie, zanim pójdzie na produkcję do klienta, ale jest to świetne pole doświadczalne.

 

Tak, myślę, że to jest jeden z bardziej skutecznych sposobów nauki, czyli po prostu pobawienie się takim rozwiązaniem, być może trochę sparzenie się, zobaczenie co działa, co nie działa. Ale mam do Ciebie pytanie. O ile w przypadku tej mnie bliższej domeny, czyli programowania, jest to dość proste, o tyle zastanawiam się, jak to można zasymulować za pomocą chociażby tego Laba, o którym powiedziałeś. Nie każdy ma dostęp do takiego rozwiązania. Tak jak zaznaczyłeś, nie wykorzystujmy infrastruktury klienckiej do tego, żeby eksperymentować. Czy takie przybliżenie za pomocą chmury jest dobre, żeby eksperymentować z narzędziami z obszaru programowania i automatyzacji infrastruktury? Od czego byś tutaj zaczął?

 

Zależy, co chcemy osiągnąć. Jeżeli chcemy zautomatyzować konfigurację przykładowej wirtualnej ASY, niezależnie, czy postawimy ją docelowo w chmurze, czy będzie stała u klienta na on-premie, interesuje nas wprowadzenie konkretnej konfiguracji, zarządzanie Access-listami, cokolwiek. To gdzie będziemy to testowali, nie ma większego znaczenia. Z drugiej strony, jeżeli zaczynamy budować infrastrukturę w ten sposób, że powołujemy wirtualne switche, całym środowiskiem wirtualizacji, które mamy na naszych serwerach, nie przetestujemy tego w chmurze. Oczywiście istnieją już takie usługi, które ja nazywam bare metal in the cloud, ale to nadal nie jest usługa, w której mamy pełen dostęp do hypervisora, bo to jest rzecz as a service, w związku z czym pewnych rzeczy nie przetestujemy w chmurze. 

Musimy znaleźć złoty środek, co na czym trzymamy, co uruchamiamy. Chmura na pewno ma tę zaletę, że płacimy jedynie za zużycie, nie mamy overheadu związanego ze wstępną inwestycją w sprzęt do Laba. Ale w pewnym momencie gdzieś ten sprzęt do Laba trzeba wstawić, bo jeżeli chcemy przetestować Zero-touch provisioning, to albo musimy mieć fizyczne urządzenie, albo jakiś produkt, w którym możemy to urządzenie zwirtualizować. Nie wszystkie urządzenia sieciowe zwirtualizujemy w chmurze publicznej, w związku z tym czasami jest potrzeba postawienia własnego serwera, czy w jakikolwiek inny sposób odwzorowania tego środowiska. Nie ma jednej ścieżki, jednej odpowiedzi.

 

Jasne, to zależy. Ok, Piotrze, mniej więcej wiemy, że warto to robić. Skoro wiemy, że to może być dobra inwestycja w nasz rozwój, to może teraz podajmy konkrety w postaci narzędzi open source’owych i komercyjnych, które mogą być przydatne do automatyzacji programowania infrastruktury. Czy w Twojej opinii te płatne rozwiązania są warte tego, żeby za nie płacić?

 

To zależy – to jest taka prawnicza odpowiedź, która zawsze wpada, w informatyce też coraz częściej. Ja nie jestem przeciwnikiem komercyjnych rozwiązań. Co więcej, komercyjne rozwiązania bardzo się otworzyły na siebie. Jeszcze parę lat temu, jeżeli byśmy powiedzieli, że takie systemy spod stajni Cisco, Junipera będą miały interfejsy programowalne, i to jeszcze udokumentowane, żeby można je było łączyć z systemami konkurencji, to pewnie wielu architektów, inżynierów pukało by się ostro w głowę: „Nie, no co ty, no gdzie, przecież oni nie będą sprzedawali, udostępniali żadnych interfejsów dla swojej konkurencji, to nie ma sensu”. 

Świat się zmienił, choćby z tego powodu, że sieci mają wielu vendorów. Mało firm ma politykę jednego sprawdzonego vendora, używamy różnych urządzeń w różnych segmentach infrastruktury, co więcej, używamy nie tylko urządzeń wiodących dostawców, choćby ze względu na cenę. Tam, gdzie nie ma potrzeby zaawansowanych funkcjonalności, firmy stawiają, może nie mydelniczki, których nie można zaprogramować, ale urządzenia z niższej półki, bo tak się lepiej skalują koszty operacyjne. Łatwiej mieć kilka urządzeń na sparze niż drogie serwisy od wiodących producentów. Producenci też widzą, że jest konieczność integrowania ze sobą różnych systemów, także systemów open source’owych z systemami komercyjnymi. To nie jest tak, że te światy się w ogóle nie przeplatają. Tak naprawdę powstanie tych interfejsów spowodowało, że zaczynamy mieć dość duże pole manewru w tym, co i jak ze sobą łączymy. Pomijam już fakt, że oczywiście dużo produktów open source’owych działa gdzieś w tle tych produktów komercyjnych, z czym się vendorzy nie kryją.

Jeżeli chodzi o produkty open source’owe, mam oczywiście swój zestaw, który jest wejściowy. Zawsze musi być Git jako mózg całej operacji. Jeżeli nie możemy naszego kodu trzymać w chmurze, to uważam że GitLab ma najlepszą ofertę, bo jest darmowy w podstawowej wersji. Do CI/CD używam Jenkinsa, jak już wcześniej wspomniałem. Potem używam Ansible’a do programowania, czy to części takie bardziej software’owej, serwerów, czy urządzeń sieciowych. Do pisania zautomatyzowanych testów używam Robot Frameworka.

Oczywiście pisanie, generalnie kodowanie musi się opierać na dobrym środowisku programistycznym. To też jest ciekawe doświadczenie, że bardzo wielu inżynierów infrastruktury, którzy wchodzą w programowanie, nie chce używać środowisk IDE, tylko zaczyna pisać w notatniku. Zawsze było to dla mnie niepojęte, że można sobie utrudniać pracę. Jest też takie przeświadczenie, że środowiska programistyczne są raz, że drogie, dwa, są na tyle skomplikowane, że tylko programiści rozumieją, co tam się dzieje. Więc trzeba zderzyć te światy ze sobą. Ja mogę tylko powiedzieć, że od lat używam na przykład PyCharma, nawet jeśli nie chodzi o programowanie w Pythonie, tylko praktycznie do wszystkiego. Dużo osób używa na przykład Visual Code Studio i tutaj ukłon dla Microsoftu, że ten produkt został odchudzony i uwolniony.

 

Tak, sam używam VS Code’a do różnych języków i faktycznie muszę stwierdzić, że to morze plug-inów i wtyczek praktycznie do wszystkiego daje radę. Powiedziałeś o PyCharmie i powiem szczerze, że jak myślę o programowaniu infrastruktury, to od razu przychodzi mi na myśl Python. Domyślam się, że Ty też go pewnie stosujesz. Czy według Ciebie jest to obecnie najlepsze rozwiązanie, czy może po prostu najbardziej popularne?

 

Chyba najbardziej popularne. Ocena czy coś jest najlepsze czy najgorsze, to jest z jednej strony indywidualna ocena użytkownika, a z drugiej strony ocena przez pryzmat projektu. Generalnie ja się czuję bardziej jako programista back-endu, jeżeli chodzi o programowanie infrastruktury dla mnie Python jest najwygodniejszym narzędziem. Oczywiście wcześniej, lata temu, bardziej zautomatyzowane rzeczy zaczynałem pisać w Perlu, który bardziej się przewijał w moich studenckich czasach. Java Script nigdy nie był moim środowiskiem, ale wiem, że on też jest używany. Te wysokopoziomowe języki rzeczywiście się przewijają. 

Python jest moim zdaniem najlepiej udokumentowany, ma dużo bibliotek, które pomagają nam obrabiać dane, jak i zapewniają komunikację z różnymi urządzeniami. Zdejmuje to z nas konieczność programowania tych wszystkich metod, które są związane z API-em, ponieważ nie musimy myśleć, jak ta sesja i komunikacja ma wyglądać, chociaż oczywiście nieznajomość API może nam czasem zaszkodzić. Jak by nie patrzeć, trzeba rozumieć, jak pewna biblioteka działa i jakie potencjalne zagrożenia może nieść. Python wydaje mi się dobrym wejściem, to jest język prosty i lekki. Nikt nie musi konstruować od razu bardzo skomplikowanych struktur, czy używać najnowszych funkcjonalności, które są dodawane do języka, żeby napisać skrypty, które się w automatyzacji infrastruktury przydają.

 

Python jest moim zdaniem najlepiej udokumentowany, ma dużo bibliotek, które pomagają nam obrabiać dane, jak i zapewniają komunikację z różnymi urządzeniami. Zdejmuje to z nas konieczność programowania tych wszystkich metod, które są związane z API-em, ponieważ nie musimy myśleć, jak ta sesja i komunikacja ma wyglądać, chociaż oczywiście nieznajomość API może nam czasem zaszkodzić. 

 

Jakiś czas temu potrzebowałem biblioteki do obrabiania numerów telefonu, trzeba było je trochę konwertować. Przetestowałem chyba cztery zanim wybrałem jedną, której mi się najwygodniej używało. To jest bardzo duża zaleta języka programowania, że możemy próbować stosować wtyczki, rozszerzenia, biblioteki, które nam odpowiadają jako programistom. Oczywiście plus minus to, co korporacje działu bezpieczeństwa narzucają, bo jeżeli mamy dział bezpieczeństwa w firmie, to oni wchodzą na aplikacyjne sprawdzanie tego, czy nasz kod jest poprawny pod względem bezpieczeństwa, czy nie używamy bibliotek, których CVE są wydane w jakichś za starych wersjach. Jako inżynierowie musimy zaznajomić się z całym procesem code review, który wychodzi, często brać w nim udział, więc jest ta otoczka programistyczna, w którą wchodzimy. Natomiast tak, Python to byłby mój pierwszy wybór.

 

Rozumiem. Myślę, że stosunkowo niski próg wejścia jest jak najbardziej na plus i może ułatwić inżynierom infrastruktury wejście w programowanie, ponieważ, tak jak powiedziałeś, nie trzeba poznawać całego środowiska, całej tej wielkiej otoczki. Tak naprawdę po przeczytaniu paru tutoriali można już zacząć produkcyjnie w tym pisać. Nie musimy korzystać ze wszystkich najnowszych ficzerów danego języka, bo już stosując podstawowe struktury plus jakieś biblioteki jesteśmy w stanie zrealizować, czy też zaspokoić tę potrzebę, którą mamy w kontekście programowania.

 

Poza tym mamy też w Pythonie bardzo dużo tutoriali, bardzo dużo tradycyjnych podręczników. Co więcej, sami vendorzy w swoich materiałach szkoleniowych kładą nacisk na ten język, pokazując jak wykorzystać konkretne biblioteki, konkretne funkcjonalności języka. Proponują całe szablony rozwiązań po to, żeby łatwiej było wejść w ten próg programowania Bardzo dużo pytań choćby na Stack Overflow dotyczy wykorzystania konkretnych narzędzi dlatego, że vendor je rekomenduje do wykorzystania i czasami człowiek nie do końca wie, jak to ugryźć, tu brakuje mu wiedzy. Perl ma też oczywiście dużą bazę bibliotek, natomiast jest o wiele mniej udokumentowany, mniej jest tutoriali, mniej jest takich szkoleń, z których można skorzystać.

 

Mamy język programowania, ale to jest pierwszy krok. Żeby w pełni wejść w programowanie infrastruktury, trzeba jeszcze zrozumieć czy też poznać dobre praktyki z software developementu w ogóle. Chciałem Cię zapytać, jakie według Ciebie dobre praktyki wytwarzania oprogramowania warto by przenieść na grunt infrastruktury? Czy Ty je sam stosujesz i czy w Twojej opinii środowisko już używa tych praktyk?

 

Używa, przekonuje się do nich. Ja zawsze bardzo zachęcam do tego, żeby całe zespoły brały udział w technicznym code review. To jest największa wartość dodana w procesie całej nauki. Oczywiście muszą być liderzy zespołów, którzy będą pilnowali, żeby standardy, które zostały określone dla danego projektu były przestrzegane. Oni powinni być też liderami technicznymi, ale należy zachęcić ludzi, żeby sobie nawzajem robili peer review kodu, nie chodzi o wytykanie błędów, chodzi o wspólną naukę i poprawianie kodu. To jest taki element pracy zespołowej, którego uczy to podejście programistyczne. Ja Ci nie wytykam błędu, nie mówię Ci, że się nie nadajesz, tylko razem doskonalimy swój warsztat i to pozwala nam być lepszymi programistami, lepiej tworzyć wszystkie skrypty, które potem ujrzą światło dzienne. To jest jedna rzecz.

Po drugie wchodzimy we wszystkie programistyczne metody pracy nad projektami. My nie musimy ich nazywać tak jak programiści, nie musimy wchodzić w ten specyficzny język, ale rozumiemy, że są pewne czynności, które trzeba wykonać, żeby zgłosić jakąś poprawkę lub nowy ficzer. Rozumiemy, że to, że nasz ficzer nie trafi teraz czy nie dostaniemy polecenia z naszym pomysłem, że robimy teraz, może być uzależnione od tego, że potrzeba biznesowa ma gdzie indziej fokus, inne ficzery są bardziej potrzebne. Wchodzimy w taki model zarządzania, w którym trochę kształtujemy nasz projekt programistyczny, ponieważ zgłaszamy nasze propozycje, a nie tylko dostajemy zadania do wykonania. Więc czujemy się współodpowiedzialni za ten projekt, co daje nam możliwości awansowania na liderów, czy managerów przy kolejnych projektach. To jest niewątpliwie duża wartość, którą możemy wyjąć.

My jako ludzie od infrastruktury bardzo często nie rozumiemy rzeczy związanych z bezpieczeństwem aplikacji. A jednak teraz już piszemy aplikacje. Python jest też aplikacją. Musimy rozumieć, że jeżeli wystawiamy jakiś front-end, jakieś API na zewnątrz, to dajemy pewną furtkę do nas, do naszej infrastruktury. To musi być zabezpieczone od strony firewalla, który powinien pilnować API, ale wszystkie mechanizmy uwierzytelniania tego, w jaki sposób ktoś się łączy, czy chce wykonać operację, też powinny być zaprogramowane. Uczymy się o bezpieczeństwie aplikacji tworząc własną aplikację, a wiedzy z bezpieczeństwa akurat nigdy nie powinno nam brakować.

 

To prawda. Do tego wszystkiego dodałbym jeszcze rzecz, którą już wcześniej wspomniałeś, to znaczy używanie repozytorium kodu, żeby przechowywać ten kod, żeby to nie było gdzieś w plikach zapisywane na komputerze, ale faktycznie dzielone w taki sposób szeroko przyjęty w software developmencie.

 

Ale repozytorium nie musi być tylko kodu, to może być równie dobrze repozytorium stanu danej infrastruktury. To nie jest unikalna rzecz, że w momencie, kiedy wprowadzamy zmianę w ACLK czy w ilości replikacji, zapisujemy informacje o tej zmianie w GitLabie, w jakimś Gicie. Co więcej, ten Git w całym procesie CI/CD może powodować wykonanie odpowiednich skryptów automatyzacyjnych i kiedy zmienimy w Gicie ilość serwerów, to się potem replikuje na infrastrukturę, więc trzymanie stanów też jest bardzo fajną opcją.

 

Świetny pomysł. Myślę, że dobrą techniką, która jest już, zaryzykuję twierdzenie, dosyć powszechna w wytwarzaniu oprogramowania, jest testowanie swojego kodu w sposób automatyczny. Zastanawiam się, czy w przypadku infrastruktury i tego kodu, też takie praktyki się stosuje, czy w ogóle jest to możliwe do zrealizowania w sposób automatyczny, w sensie przetestowania kodu, który ma tak naprawdę tworzyć, zarządzać, automatyzować infrastrukturę?

 

Jest to możliwe. Oczywiście z jednej strony mamy typowe testy, które stosuje się w rozwiązaniach aplikacyjnych. Wiemy, co dana metoda ma zwrócić, jaką wartość i piszemy testy funkcjonalne, które tak naprawdę powinny być nieodłącznym elementem naszego programu. Tego typu rzeczy jak najbardziej powinno się robić, ale infrastrukturę zbudowaną też możemy przetestować. Mamy choćby wspomniany już przeze mnie Robot Framework, w którym możemy napisać testy. Przykładowo, jeżeli mamy zadanie wymienienia iluś tam certyfikatów SSL na profilach, na firewallu, to nic nie stoi na przeszkodzie, żeby napisać robota, który sprawdzi, czy te certyfikaty poprawnie się już zgłaszają i zaraportuje potencjalne błędy. Więc jak najbardziej jest to do zrobienia i powinno być robione.

 

W tym obszarze, o którym tutaj rozmawiamy, Cisco ma całą ścieżkę certyfikacji DevNet. Zastanawiam się, jak Ty na to patrzysz. Czy zarekomendowałbyś podchodzenie do tej certyfikacji? Jakie masz opinie na ten temat?

 

Ja zrobiłem DevNet Associate z ciekawości i dlatego, że siedzę w tym temacie po prostu. Tak jak od wielu lat mam bardzo dużo krytycznego podejścia do ścieżek certyfikacyjnych, o tyle certyfikat DevNetowy, ten Associate przynajmniej, był bardzo praktyczny i rzeczywiście wprowadzający do tego, jak ten świat powinien wyglądać. Oczywiście plus minus trzeba patrzeć na to, że to jest świat według Cisco. Natomiast ten świat według Cisco nie różni się drastycznie od tego, co robią inni vendorzy, czy jak to się robi całkowicie na produktach open source’owych. Zresztą nawet w tym świecie według Cisco jest nauka Pythona, jest informacja o tym, czym jest Jenkins, czym są te procesy, że jest API. Ten świat według Cisco był tylko bardziej ukierunkowany na to, co możemy zrobić na konkretnych grupach produktowych.

 

Tak jak od wielu lat mam bardzo dużo krytycznego podejścia do ścieżek certyfikacyjnych, o tyle certyfikat DevNetowy, ten Associate przynajmniej, był bardzo praktyczny i rzeczywiście wprowadzający do tego, jak ten świat powinien wyglądać. Oczywiście plus minus trzeba patrzeć na to, że to jest świat według Cisco. Natomiast ten świat według Cisco nie różni się drastycznie od tego, co robią inni vendorzy, czy jak to się robi całkowicie na produktach open source’owych. 

 

Jest to bardzo dobry certyfikat, żeby się w ogóle rozeznać, czy szkolenie, które można zakupić w formie książki czy szkolenia online’owego, to jest dobry punkt wejścia, żeby zobaczyć różne tematy, które trzeba zrozumieć w mniejszym lub większym stopniu, żeby powiedzieć, że się zajmujemy automatyzacją infrastruktury. Tam jest wszystko: od chmury, programowania, wszystkich aplikacji, procesów, zrozumienie jak działa API, w jaki sposób je wywołujemy, informacje produktowe, że nie wszystkie produkty muszą mieć API, że są to tylko inne biblioteki, że jednak to SSH, z którego korzystamy do pracy na konsoli możemy też zautomatyzować, bo jest biblioteka do tego, żeby automatyzować wydawanie poleceń i analizowanie tego, co ta konsola wypluwa z siebie. Jest bardzo dużo takich wejściowych informacji. Nie wiem jak jest dalej, może kiedyś zobaczę curriculum, które jest na core’owym egzaminie DevNet. Po drodze trzeba jeszcze chyba zdać egzaminy specjalistyczne z konkretnej gałęzi produktowej. Te egzaminy specjalistyczne wydają mi się dość ciekawym i sensownym podejściem, ponieważ trochę inaczej będziemy automatyzowali system Unified Communication i automatyzację na telefonie IP, który stoi przed tobą, a inaczej w obszarze security czy data center. Nawet jeżeli nie będziemy planować, taka wiedza z konkretnego obszaru inżynierowi infrastruktury się jak najbardziej przyda.

 

Zanim jednak podejdziemy do ścieżki certyfikacji, warto by się było zaczepić w  tym temacie i jakoś tę swoją przygodę rozpocząć. Na początku naszej rozmowy mówiłeś, że studenci nie do końca są kształceni z umiejętności praktycznych w tym obszarze. Od czego byś zaczął, jeśli chodzi o zdobywanie wiedzy z tego obszaru, o budowanie swojej kariery, jeśli chodzi o infrastrukturę i programowanie? Co byś polecił studentom, którzy są jeszcze przed wejściem do branży, zastanawiają się w którym kierunku pokierować swoją karierą, jak tę przygodę w obszarze programowania i automatyzacji infrastruktury rozpocząć?

 

Nie bać się, to jest taki pierwszy krok, dla wielu osób jest to wyjście ze strefy komfortu. Napisanie programu zaczyna być wyjściem ze strefy komfortu. Po drugie baby steps, nie rzucajmy się od razu na głęboką wodę, że zbudujemy całą infrastrukturę czy będziemy próbowali napisać skrypty, które zrobią wszystko. Myślę, że każdy student jest w stanie – wielu studentów pracuje, co powinno im trochę ułatwić – znaleźć małe obszary w ramach których mogą uzyskać namacalny efekt, coś co rzeczywiście zrobili, przyspieszyli, ulepszyli. Próbujmy z takich właśnie małych klocków uczyć się tego, w jaki sposób wykorzystywać narzędzia bądź języki programowania. Dopiero potem przyjdzie cała otoczka związana z budowaniem czy udziałem w dużych projektach.

Jeżeli już poczujemy ten zew natury ciągnący nas do programowania, nie bójmy się zderzać naszych umiejętności z projektami. Ja nie jestem programistą, ale wpisuję sobie w CV, że uczestniczyłem w projekcie Ansible’a, gdzie jest trochę moich kodów i gdzie jestem nawet opiekunem jednej gałęzi w Ansible Collection. Trochę moich linijek kodu jest w bibliotece Dockera Pythona od niedawna. Uważam, że to jest sukces, który zderzył moje pojęcie o tym, czy umiem programować, z tym co rzeczywiście ludzie, którzy zawodowo programują są w stanie ocenić i zaakceptować. Jeżeli tak zderzamy, możemy dostać bardzo dużego kopa. Fejm to jedno, to jest fajne, działa na mnie, ale z drugiej strony uwierzymy w siebie, w to że potrafimy coś robić, a to jest dobra siła napędowa do tego, żeby się dalej rozwijać, tworzyć coś nowego.

Po trzecie, trzeba wiedzieć, jeżeli szukamy ścieżek kariery, że inżynierowie od wszystkiego się skończyli. Musimy wiedzieć coś ze wszystkich obszarów IT, ale szukać swoich ścieżek, kilku niszy, w których będziemy próbowali się specjalizować. I rzeczywiście dla części osób może to być programowanie systemów Unified Communications, dla innych budowanie infrastruktury hybrydowej. Trzeba mieć trochę inne skille. Wchodząc w tego typu rzeczy patrzymy, czego potrzebuje rynek, bo głupio planować teraz swoją karierę ucząc się COBOL-a, ten COBOL też umrze jednak w pewnym momencie. Natomiast trzeba wiedzieć, czego rynek potrzebuje, jakie umiejętności w danych obszarach trzeba sobie wyrobić. Jeśli zrobimy krótką analizę porównawczą kierunku, w którym potrzebuję piętnastu rzeczy, z czego dziesięć mi odpowiada, z drugą ścieżką kariery, gdzie odpowiadają mi tylko dwie, bo nie lubię na przykład obrabiać danych dużych ilości, to już mamy podpowiedź, w którą stronę powinniśmy się rozwijać i które umiejętności zdobywać.

 

To bardzo dobre i rozsądne porady, dzięki za to. A co byś zalecił komuś, kto w sposób klasyczny, standardowy pracuje obecnie z infrastrukturą, czyli używa linii komend, co najwyżej parę linijek skryptu napisze w Bashu? Od czego zacząć poszerzanie swoich kompetencji, jakie umiejętności zdobyć, jakie narzędzia poznać w pierwszej kolejności?

 

Tu są dwie ścieżki, zaznaczyłeś je trochę. „Wejść coś zrobić” albo „jakich narzędzi użyć”. Jeżeli „wejść coś zrobić”, to ja bym zaproponował spróbować oskryptować to, co robisz z konsoli. Tak jak już wspomnieliśmy wcześniej, w Pythonie są biblioteki, które pozwalają na komunikację z urządzeniem sieciowym za pomocą SSH i interpretowania w sposób programowalny tego, co na tej konsoli jest zwracane. Spróbujmy przełożyć na początek swoją wiedzę. Wiemy jak coś zrobić z konsoli, zaprogramujmy to. Nagle się okaże, że odzyskaliśmy dwie godziny na stanie przy ekspresie z kawą. To już jest jakiś namacalny efekt, bez efektu przyjdzie szybkie zniechęcenie.

Natomiast jeżeli mówimy o narzędziach, to popatrzmy po prostu co się dzieje, co świat robi. Użyjmy Ansible’a, próbujmy w Jenkinsie. Ansible wydaje się pierwszym punktem wejścia, bo jest tu dużo rozszerzeń w ramach Ansible Collections do zarządzania serwerami, infrastrukturą zwirtualizowaną czy sieciowymi urządzeniami nawet od mniej popularnych vendorów. Nie korzystając z Pythona, możemy przenieść to na Ansible’a, żeby budować pełne scenariusze, które nam coś budują czy testują. Więc odwzorowywanie tego, co robimy z konsoli na wykorzystanie różnych produktów to jest moim zdaniem dobry punkt wejścia. Jak już poczujemy te produkty, to możemy myśleć, co możemy zrobić lepiej albo co możemy nowego zrobić.

 

Jasne, rozumiem. Teraz pytanie o przyszłości. Czy według Ciebie ten trend się będzie utrzymywał cały czas, czy to już jest stała zmiana? Chodzi mi automatyzację i programowe podejście do infrastruktury. Co ewentualnie w najbliższej przyszłości może nas w tym obszarze czekać?

 

Liczę na to, że coraz więcej produktów będzie miało interfejs API. Ja jestem miłośnikiem takiego podejścia, że mamy API, które jest wystawiane przez vendora. Choćby z tego powodu, że w momencie kiedy my martwimy się tylko o wywołanie konkretnej metody, to zrzucamy na vendora odpowiedzialność za jej poprawne wykonanie. Jeżeli programujemy w Pythonie i używamy jakiejś biblioteki do sczytywania z konsoli, to jednak my jesteśmy odpowiedzialni za to, że złapiemy to, że komuś na konsoli się nagle pojawia dodatkowa spacja. Więc liczę na to, że coraz więcej produktów zarówno tych software’owych jaki i firmware’u na samym hardwarze będzie miało możliwość korzystania z API, dobrze udokumentowanego API, to też warto podkreślić.

Wydaje mi się, że będziemy szli coraz bardziej w takim kierunku, że vendorzy nie będą się zamykali na komunikację pomiędzy rozwiązaniami. To już nie jest próba wygryzienia siebie nawzajem, to jednak klient decyduje, że chce mieć środowisko Multi-Vendor i skoro klient chce, to klient musi to dostać w jakiś sposób. To widać po ofertach pracy u różnych vendorów. Ludzie rozumiejący procesy automatyzacji są potrzebni firmie wewnętrznie do rozwiązywania produktów, do tworzenia ich, udoskonalania, ale z drugiej strony do świadczenia supportu klientom. Jeżeli już vendor potrzebuje świadczyć support systemów automatyzacji i jak je tworzyć, to znakiem tego firmy idą w tę stronę. 

Więc nie ma odwrotu, jest tylko pytanie, czy pojawi się coś nowego, co nas zaskoczy. Myślę, że pierwszą rewolucyjną zmianą było pojawienie się chmury publicznej. Nie widzę drugiej tak mocnej rewolucyjnej zmiany, która miałaby być. Poszliśmy w kierunku SDN-ów w sieciach, co jest jakąś zmiana w podejściu do zarządzania. Natomiast nie widzę na horyzoncie takiej mega rewolucyjnej zmiany, jak wejście chmury publicznej w tym momencie. Nie znaczy to, że ta ewolucja nie będzie postępowała wraz z rozproszonymi produktami. Wydaje mi się, że produkty od konkretnych vendorów, które same w sobie będą Multi-Vendor, będą pewnym krokiem naprzód, ale nadal przy wielu rozwiązaniach będziemy musieli programować rzeczy samodzielnie. To też jest dobre, bo mamy taką mnogość rozwiązań i potrzeb, że vendor nie zapewni wszystkich, a zamykanie się używaniem jedynie dwóch produktów komercyjnych jest ograniczeniem sobie dróg rozwoju biznesu czy własnej infrastruktury.

 

Natomiast nie widzę na horyzoncie takiej mega rewolucyjnej zmiany, jak wejście chmury publicznej w tym momencie. Nie znaczy to, że ta ewolucja nie będzie postępowała wraz z rozproszonymi produktami. Wydaje mi się, że produkty od konkretnych vendorów, które same w sobie będą Multi-Vendor, będą pewnym krokiem naprzód, ale nadal przy wielu rozwiązaniach będziemy musieli programować rzeczy samodzielnie. To też jest dobre, bo mamy taką mnogość rozwiązań i potrzeb, że vendor nie zapewni wszystkich, a zamykanie się używaniem jedynie dwóch produktów komercyjnych jest ograniczeniem sobie dróg rozwoju biznesu czy własnej infrastruktury.

 

Świetnie. Dobrze, Piotrze, bardzo Ci dziękuję za tę ciekawą rozmowę. Mam wrażenie, że to jest kolejny mały kroczek w kierunku przybliżenia programowania infrastruktury. Myślę, że teraz już nikt nie ma wątpliwości, że to z nami zostanie. Myślę też, że fajnie zachęciłeś wszystkich tych, którzy jeszcze nie zajmują się czy nie myślą o tym, żeby poszerzyć swoje kompetencje właśnie o programowanie. Zachęciłeś do tego, że warto, myśląc o swoim rozwoju, jak również myśląc o projektach, firmach, w których pracujemy. To może się wszystkim docelowo przysłużyć. Także z mojej strony bardzo Ci dziękuję za poświęcony czas. Powiedz, proszę, gdzie Cię można znaleźć w Internecie, jak się z Tobą skontaktować?

 

Tradycyjnie, LinkedIn żyje, chyba wszyscy specjaliści mają tu swoje profile.

 

Ma się dobrze, tak.

 

Tak, ma się dobrze i chyba nie umrze. Jestem też na Twitterze, gdzie wrzucam rzeczy bardziej lekkie. Rzeczy nie informatyczne trafiają na mojego Instagrama. Mam anglojęzyczny, choć przyznaję się, że ostatnio trochę zaniedbany blog, który mam nadzieję podlinkujesz. W kierunku automatyzacji sieciowej, jest szkoła DevNet, która ma za zadanie edukować, jak wejść w elementy programowania czy automatyzacji i tam rzeczywiście pojawiają się praktyczne rzeczy. Wrzucam rzeczy, z którymi spotykam się na co dzień w różnych projektach, z praktycznego wykorzystania Pythona, jak i z takich ogólno automatyzacyjnych rzeczy, więc serdecznie zapraszam.

 

Świetnie, oczywiście wszystkie linki będą w notatce do tego odcinka. Byłem na stronie Twojej szkoły, czytałem i muszę przyznać, że jest tam bardzo wiele artykułów obecnie. Jest spory content do przeczytania, myślę, że też mogę zachęcić słuchaczy do odwiedzenia jej. 

Z mojej strony jeszcze raz wielkie dzięki i do usłyszenia, cześć!

 

Dzięki za zaproszenie!

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Światy infrastruktury i programowania coraz bardziej się zbliżają. Automatyzacja i programowanie infrastruktury, to już nie przyszłość, ale teraźniejszość.

Jeśli ten odcinek był dla Ciebie interesujący i przydatny, odwdzięcz się proszę recenzją, oceną lub komentarzem w social mediach. Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl. Zapraszam też do moich mediów społecznościowych

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o automatyzacji i programowaniu w świecie infrastruktury.

Zapraszam do kolejnego odcinka już za tydzień.

Cześć!

 

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.