Rozwój w "technikaliach" dookoła kodzenia

0

TLDR Jak Wy się uczyliście wszystkich technikaliów nie związanych typowo z samym pisaniem aplikacji, takich jak budowanie CICD, orkiestracja, operowanie w chmurze itd.?

Temat:
Zastanawia mnie jak to jest u innych osób z nauką w pracy różnych cuda-wianków nie związanych z samym przepisywaniem dokumentacji z języka naturalnego na język zrozumiały dla komputera, a bardziej z kwestiami infrastrukturalnymi.

Mój kontekst:
Jestem z nich totalną nogą i przyznam szczerze, że nawet nie bardzo wiem jak nieinwazyjnie dla portfela te tematy ugryźć. W pracy kodzę, ładnie odnajduję się w czyimś kodzie (przejęta aplikacja, utrzymanie, dodawanie funkcjonalności), ale w zasadzie gniję sobie w jednym języku i na spotkaniach, podczas gdy widzę że dookoła technologie sobie latają jak powalone i na dniach w zasadzie uderzyło mnie jak bardzo ubogim stackiem dysponuję.
W projekcie mamy scalę i trochę pythona. Komunikacja z Airflowem, cicd (cicd i repo na Azure DevOpsach), batchowe dane na ADLSie, obliczenia na k8sie albo Databricksach, mamy UI, pewnie o jakichś innych rzeczach zapomniałem. Teoretycznie aplikacja hula, mogę ją sobie zmieniać, rzeczy dowożę spoko i generalnie ogarniam całkiem spoko to co muszę ogarniać.

No ale właśnie o to chodzi, że ogarniam to, co muszę. Ta aplikacja już istnieje. Nie mam nawet pojęcia czy byłbym w stanie skonfigurować ją samemu, postawić całą architekturę. Umiem połączyć klocki, komponenty, ale co z tego na dłuższą metę? Nawet nie wiem czy jestem w stanie postawić wirtualną maszynkę, na której bym postawił instancję Airflowa. Może bym umiał lecąc z dokumentacją, może nie. Kod airflowowy? Ale jak on miałby na nią lądować? Jak miałoby wyglądać CICD? Nigdy sam nie robilem, odziedziczyłem. Połączenie z Databricksami i ADLSem? Chyba jestem w stanie połączyć, ale nie wiem. Databricks - jak skonfigurować klastry? To że jestem w ogóle w stanie dobić się do keyvaulta to w zasadzie przypadek, bo akurat kiedyś stworzyłem samemu sobie instancję Azure'a (i wygenerowałem koszty z czapy) i sobie ogarnąłem ot tak, rekreacyjnie. Moje konfigurowanie klastrów to robienie sobie ich analogicznie do już istniejących (podpatrując service principale z innych projektów i ogólnie konfigurację). Nawet nie wiem jak kod z samej .jarki łączy się dokładnie z ADLSem, bo funkcja juz była gotowa.

Generalnie nie jestem aż takim tępym trepem jak by po tym wstępie mogło się wydawać i rozumiem mniej więcej jak wyglądają zależności między poszczególnymi aplikacjami (skąd odbiera jakie credentiale kod zaszyty w .jarce, co się z czym łączy i tak dalej), bez tego nie byłbym w stanie w ogóle pracować natomiast gdybym miał zacząć projekt od zera to bym chyba osiwiał i na koniec projektu mógłbym ze stresu powiesić się na gumie od majtek (ale z chęcią taki projekt bym w sumie przygarnął).

Do sedna
W zasadzie nie wiem jak w tej sytuacji się rozwijać, bo na każdym kroku czuję, że brak swobody we wszystkim dookoła rdzenia moich obowiązków totalnie związuje mi ręce. Mnie nie wystarczy obejrzenie filmiku na yt czy przeczytanie dokumentacji, ja po prostu muszę zbudować coś produkcyjnego, patrzeć jak to wybucha i to łatać. Innej opcji nie widzę.
Dwa widziane przeze mnie rozwiązania problemu:

  1. postawić sobie samemu instancję Azure'a, narazić się na koszy z czapy (i nawet te bez czapy dalej są kosztami, a przecież można by było wydawać odpowiedzialnie pieniądze korporacyjne w zbożnym celu zamiast wydawać swoje bo "a nuż nauka się przyda"), ale ostatecznie to i tak nie rozwiąże to wszystkich moich problemów, bo rozwiązania treningowe to nie rozwiązania produkcyjne
  2. siedzieć dalej w projekcie i liczyć na to, że manna z nieba skapnie (i skapnie, ale tempo będzie dla mnie totalnie niesatysfakcjonujące, bo mi już odbija z frustracji). W zasadzie to chyba będę dalej siedział przy tej opcji
  3. zwolnić się i wpakować się w jakiś mobbingujący konsulting, gdzie może zostanę zmuszony do tego, by wszystko ogarnąć za hajs firmy (albo i nie ogarnę i zostanę wywalony na ryj). Ale to konsulting i nowa firma, więc nie wiem z czym przyjdzie mi się mierzyć. I albo się uda trafić, albo się nie uda i będę jeszcze bardziej sfrustrowany.

Jak u Was wyglądał proces nauki tego rodzaju technikaliów? Uczyliście się sami z tutoriali? Kolejno technologie dochodziły w projektach? W jakich projektach? Przejmowaliście projekty już istniejące czy greenfieldy?

4

Normalnie - bierzesz dokumentację i czytasz. Jak potrzebujesz praktyki to praktykujesz. Jeśli te dwie rzeczy nie wystarczą to znaczy że masz w czymś braki, wtedy je musisz zidentyfikować i uzupełnić wykonując te dwie czynności na zidentyfikowanym wycinku. Jak chcesz być innowacyjny to eksperymentujesz oraz czytasz jakieś publikacje naukowe zahaczające o temat.

2

Jeśli chodzi o mnie to miałem dużego fuksa - trafiłem przypadkowo do projektu, gdzie robiło się za konsultanta od infrastruktury i bezpieczeństwa i od odejścia z tamtego projektu po prostu "ogarniam" infrastrukturę. Problem był z k8s - tego nauczyłem się sam, ale jeśli rozumie się co te YAMLe mają opisywać, to nagle okazuje się, że nie jest jakoś specjalnie trudno je wyklepać.

Teraz w sumie najważniejsze pytanie - jak tego się uczyć? Nauka tych "okołotechnikaliów" różni się tym od nauki kodowania, że podejście typu "trial and error" jest raczej nieefektywne. W pierwszej kolejności sugeruję naukę kwestii sieci, tj. jak to w praktyce wygląda, następnie zaprojektować sobie jakieś API (z opcją blue-green deploymentu), a dopiero potem ogarnąć docker'a, następnie postawić sobie lokalnie jakiegoś minikube'a i spróbować stworzyć lokalnie cokolwiek. W firmie też to powinno tak działać - bez rozumienia co chcesz zrobić będziesz się chrzanił w kółko z dziesiątkami niezrozumiałych błędów.
Tak jak napisałeś, idealnie by było trafić do projektu, w którym byś musiał tego używać - tyle tylko, że nie wiadomo, czy się da.

Jeśli chodzi o chmury to tutaj też panuje dosyć wolna amerykanka. Tj. każda chmura ma swój własny zestaw produktów, a wspólna część to tylko coś a'la S3 i właśnie konteneryzacja. Przy chmurach staram się po prostu znać ogólne koncepcje i ich zastosowania (tj. czym jest format kolumnowy, czym są time-series DB itp.) + planuję zrobić certyfikat MSowy, żeby ogarniać jako tako Azure'a.

3

Kontenerami zainteresowałem się, gdy natrafiłem na jakiś bardzo ciężki do skompilowania program i stwierdziłem, że co mi szkodzi, zobaczę, jak to uruchamianie z kontenera działa - ku mojemu zaskoczeniu, całkiem zgrabnie. Jakiś czas potem zacząłem używać kontenerów do "eksperymentów" - czyli gdy robiłem jakiś research i nie ogarniałem do końca, co jest potrzebne, a co nie, to zamiast śmiecić sobie w systemie, odpalałem kontener w roli izolowanego środowiska, które mogłem potem bez problemu usunąć. Nauka budowania obrazów nie była trudna, bo to w zasadzie sprowadza się do automatyzacji takiego "ręcznego" doinstalowywania rzeczy do kontenera.

Naukę CI/CD zacząłem od dodania tego do własnych pet projects, potem parę razy nadarzyła się potrzeba dorzucenia czegoś do istniejącego CI w pracy, aż w końcu w trafiłem do greenfielda i tam miałem okazję postawić wszystko od zera.

Orkiestracji ani chmury póki co nie tykałem. We własnych projektach z tego nie korzystam, a w robocie wszystko stoi na jednej VMce, więc też nie ma potrzeby.

0

@Satanistyczny Awatar:
No właśnie o to chodzi, że na danym wycinku to ja sobie mogę pracować jeśli chodzi o klepanie zadanek algorytmicznych czy innych podstaw, ale tu chodzi raczej o łączenie szerszego spektrum.

Przykład - nie pisze się orkiestracji dla samego pisania orkiestracji. Ona wykorzystuje różne zależności. Trzeba ściągnąć jakoś dane z UI, skonfigurować połączenia z filesystemami, triggerować joby wykonujące obliczenia na jakiejś przestrzeni obliczeniowej, te połączenia muszą byc odpowiednio obsłużone (certyfikaty, rejestracja aplikacji i zarządzanie uprawnieniami przez np. wirtualnych użytkowników). Tutaj nie jest potrzebny wycinek tylko podejście całościowe. Ja nie mam problemu żeby dodać jakąś zmianę do istniejącego DAGa w Airflow, który zrobi co ja chcę żeby zrobił, zwłaszcza że jego nowa wersja pozwala dość swobodnie bawić się w puszczanie kodu na środowisku (sorki za taką odpowiedź opierając się o konkretną technologię, której możesz nie znać, inaczej nie potrafię i mogę tylko liczyć na to, że mnie zrozumiesz). Projekt domowy też mi nie pomoże, bo ja muszę umieć zmierzyć się z problemami typowo produkcyjnymi. Nie mogę też robić tego na odpowiednio ograniczonej przestrzeni produkcyjnej/preprodowej, bo ona jest od innych rzeczy (nie mogę na przykład bawić się w wysadzanie VMki, na której coś już stoi i leci w tle).

Po prostu mam wrażenie, że tech stack dla data engineera (innych devów pewnie też, tylko tego nie widzę) mimo że nie wymaga jakichś specjalnych zdolności to wymaga dość dużej wszechstronności i obycia w specyficznym środowisku, które jest trudne do odtworzenia w warunkach przeznaczonych do celów typowo edukacyjnych.

1

znaczy ja bym atakował na dwóch frontach.
1.Pracodawca może wysłać cię na szkolenie z azure, aws?
2. dodatkowa praca:

  • Szukasz czegoś pierdołatowatego za niski hajs co można robić po godzinach,

  • Poszukaj jakieś projektu opensource na pewno kogoś do pomocy szukają

    Ja miałem taki mały projekcik(za hajs) jakiś czas temu python + cpp + ml i mi się trochę przemyśleń nasunęło więc może nawet warto podjąć jakaś dodatkową robotę freelancera. O ile masz czas.

5

Nauka infrastruktury tak na poważnie to tylko jedynie pracując z tym. Inaczej jest to jak nauka pływania w wannie. Serio mówię, dopóki sam nie zacząłem robić za DevOpsa z innymi Devopsami to wydawało mi się to proste tak jak na tutorialach i dostałem lekcję pokory.

Zobacz jak się stawia infrastrukturę za pomocą Terraform + Kubernetes + wszelkiej maści operatory

1 użytkowników online, w tym zalogowanych: 0, gości: 1