Ile devopsu powinien umiec zwykly dev?

Rozumiem, ze dockera teraz wypada dobrze ogarniac, tworzyc wlasne obrazy laczyc ze soba deployowac etc.
Rozumiem, ze pisanie basic pipelinow w wybranym CI/CD - przydaje sie, cos sie powinno umiec.
Ale czy dev powinien dobrze ogarniac kubernetesa? Ogarniac przyzwoicie terraform i wiedziec jak go uzywac do szybkiego tworzenia potrzebnych zasobow w cloudzie? Czy powinien umiec into gitops?
Czy to w ogole mu sie przyda skoro w wielu firmach bedzie mial bardzo ograniczone uprawnienia do np clouda i i tak bedzie sie pewnie musial o nie prosic do wprowadzania swoich zmian? Czy to w ogole mozliwe robic lata jako dev a potem znalezc prace jako dev/devops hybryda gdzie sie ta wiedza przydaje?
Czy takie pozycje sa tylko w malych startupach, gdzie jest potrzeba miec takiego "czlowieka orkiestre"?

W niektórych firmach wymagają tego a w niektórych nie.

Powinien umieć co najmniej tyle ile w pracy potrzebne.

Dev powinien:

• Umieć przeczytać ze zrozumieniem yamle
• Znać kontakt do kogoś z teamu devopsowego

Ja nawet nie mam terraforma. Ani kubernetesa. Ale już pisałem w swoim życiu yamla dla kubernetesa o 3 w nocy bo jednak produkcja minimalnie się różniła od środowiska testowego (chyba testowe było jednonodowe, już nie pamiętam)

Jak pisali wyżej jest różnie w różnych firmach. Ale zwykle jak jest ta legendarna kultura devops to i tak jest jeden szaleniec co bardziej lubi klepać te yamle i bierze kubernetesa na siebie, a reszta może w spokoju programować. Gorzej jak się zwolni XD

Osobiście uważam, że od DevOpsa powinni być osobni DevOpsi. Zanim przyszedł DevOps też przecież byli programiści i osobno administratorzy. Nie jestem zwolennikiem "one man army", czy inaczej, ludzi którzy są fulstack-dev-cloud-sec-data-ops-mobile-testerami :-D

Pracowałem w projektach gdzie od programistów Javy wymagano robienia DevOps i co najlepsze estymowania. Gdy mówiłem że się boje wyceniać to mnie do tego lekko zmuszano. Gdy coś wyceniłem to wtedy brałem to na Sprint i byłem w pułapce. Bo pasowało to dowieźć do końca Sprintu. Jak nie dowoziłem to mówili że nie spełniam Sprint Commitment.

Bardzo mnie to stresowało wtedy i sporo robiłem darmowych nadgodzin.

Gdybym robił w stacku jak typowy Java Developer to byłoby okej.

@MarioBros33: jak sie na czyms nie znasz, to estymujesz z zapasem. Jak zostanie czas, to sobie doczytasz o opsowaniu.

@lambdadziara: tak, ja skakalem midzy QE <-> Dev a pozniej przeskoczylem na SRE.

Jeśli infra w twojej firmie stoi na k8s, to powinieneś znać "kontrakt" twojej aplikacji z Kubernetesem. Czyli rzeczy typu:

• że są jakieś zmienne środowiskowe, sekrety, wolumeny i aplikacja musi potrafić z tego korzystać
• że CPU i RAM nie są nieskończone, a nawet jeśli tak się wydaje to jest to łatwo weryfikowalne złudzenie :)
• że fajnie jakby aplikacja była bezstanowa, dawała się skalować, ładnie się wyłączała jak dostanie SIGTERM
• że są (liveness/readiness/startup)Probe i od nich bardzo zależy czy ta aplikacja będzie stabilnie działać, a jak przestanie to pozwoli się zrestartować

Natomiast (przynajmniej z mojego doświadczenia w większej firmie) jako zwykły programista nigdy w życiu nie dostaniesz dostępu nawet readonly do klastra. Więc nie przejmuj się niczym ponadto :)

EDIT: teraz widzę że pytanie było szersze, ale zamysł jest taki sam. Pytasz o pisanie pipelinów - warto wiedzieć jak z CLI odpalić testy i gdzie są ich wyniki, ale np. jak dodać nową maszynkę do Jenkinsa to co cię to obchodzi :)

@kelog: "że fajnie jakby aplikacja była bezstanowa, dawała się skalować, ładnie się wyłączała jak dostanie SIGTERM" -> gdyby wszystkie apki byly takie, zycie byloby piekne.

Co do dostepu -> duzo zalezy od skomplikowania i wielksosci, jednak zupelnie inaczej wyglada zabawa jak mamy 4 serwerki na krzyz, a inaczej gdy liczby ida w setki lub tysiace.

Ja dzieki temu ze dlubalem w jenkinsie to dostalem oferte +50%, zeby przejsc z deva na devopsa :D Takze imho warto jezeli Cie to interesuje.

PaulGilbert napisał(a):

Zanim przyszedł DevOps też przecież byli programiści i osobno administratorzy.

Tak, byli. I to było słabe, bo programiści nie umieli pisać kodu, który da się łatwo wdrożyć i utrzymać, a administratorzy nie potrafili zajmować się softem, którego nie pisali.
Stąd słuszny pomysł na łączenie kompetencji w ramach poszczególnych zespołów.
A, że korpo zaczęły nazywać administratorów devopsami, bo podobnie jak 2/3 programistów nie rozumieją o co chodzi w wytwarzaniu oprogramowania ani po co się to robi, to już inna kwestia.

Ja postrzegam to trochę inaczej, szerzej. Dla mnie w DevOpsie nie chodzi o to, żeby każdy umiał wszystko, tylko aby zespoły były tak budowane, że zespół jako całość jest samodzielny. Zresztą był nawet taki film krótki o tym na przykładzie spotify, który świetnie to obrazuje.

Tyle żeby postawić aplikacje na serverze i pokazac klientowi.

Riddle napisał(a):

Tyle żeby postawić aplikacje na serverze i pokazac klientowi.

Developerzy nie powinni się bawić serwerami, a co więcej, to nie developerzy powinni się zajmować prowadzeniem biznesu z klientem, takie jest moje zdanie.

PaulGilbert napisał(a):

Riddle napisał(a):

Tyle żeby postawić aplikacje na serverze i pokazac klientowi.

Developerzy nie powinni się bawić serwerami, a co więcej, to nie developerzy powinni się zajmować prowadzeniem biznesu z klientem, takie jest moje zdanie.

:D

jasne.

Robienie wszelkiego rodzaju silosów (typu Maciek kodzi, a heniek robi aws) nic dobrego nie przynosi. Dobre projekty powstają kiedy zespół składa się z ludzi o szerokim zasięgu.

Przez to, że kultura DevOps jest źle implementowana, przynajmniej z tego co się u nas słyszy - nie wiem jak to na świecie przeważnie wygląda, to teraz te narzekania słychać, że DevOps się nie sprawdza, że Developerzy go nie chcą, że nie specjalnie spełnia oczekiwania, że nie ma ludzi, którzy by chcieli Kubernetesa ogarniać itd itp.
I ja się nie dziwię - są ludzie których jara programowanie a zupełnie nie kręci opsowanie i odwrotnie. Wiadomo, że jak musisz, to będziesz robił, ale jak nie masz z tego satysfakcji, to się wypalisz szybko.
Ukierunkowanie się na to, żeby każdy był od wszystkiego to nie jest to o co w tym chodziło.

Terraforma nie miałem przyjemności poznać. W pierwszej pracy nawet Docker był mi obcy - charakter projektu i produktu był taki, że nie było to potrzebne. W obecnej firmie od razu zaskoczyła mnie mnogość rzeczy związanych z cloudem, k8s, docker, które muszę przyswoić. Z biegiem czasu jednak to się stało dla mnie naturalne, że jako developer potrafię ogarnąć jakiś problem w klastrze, zdeployować aplikację, napisać yamla, czy skrypt gitlab ci. Wydaje mi się to nie tyle smutną koniecznością, co przydatnym atrybutem.

Ja z DevOps umiem dość sporo jako Java Developer, stawiałem całe środowiska na AWS/Azure. Mam także certy z Terraforma i z k8s CKAD i AWS Solutions Architect Associate + Profesional.

Miałem epizody ze Devopsom w firmie mówiłem jak coś ma być zrobione bo nie ogarniali czasem (brak wiedzy z sieci, networkingu).

Na rozmowach rekrutacyjnych nigdy mnie nie pytali z tej wiedzy i to zależy od projektu czy się ona przydaje. Jedno jest pewne, jak się nie używa to się zapomina.

PaulGilbert napisał(a):

Ja postrzegam to trochę inaczej, szerzej. Dla mnie w DevOpsie nie chodzi o to, żeby każdy umiał wszystko, tylko aby zespoły były tak budowane, że zespół jako całość jest samodzielny.

Dokładnie o to od początku chodziło. To jest nazwa metody pracy, nie stanowiska.
Tylko nadal pozostaje ten niuans, że programista oprócz pisania kodu powinien też umieć uruchomić swój program, i go ewentualnie naprawić.

Nawet nie czytam reszty odpowiedzi bo obawiam się, że przeczytam że to normalne, że teraz dev ma być fullstackiem, devopsem i testerem w jednym i jeszcze rozumieć biznes xD

Ja osobiście uważam, że każdy powinien skupić się na tym na czym się zna i robić to dobrze. Idealnie gdyby programista wiedział, gdzie jego soft będzie działał, jak się skalował i umiał to wziąć pod uwagę, natomiast uważam za zbędną rzecz robienie z programisty admina/ devopsa. Prawda jest taka, że grzebać w kubernetesie/ terraform itp. może każdy, nawet coś tam się da postawić, natomiast grzebanie na produkcji kiedy są jakieś problemy z cloudem/ infrastrukturą itp. zostawiłbym ludziom, którzy się na tym dobrze znają. Powiem szczerze, że mi najlepiej się pracowało w firmie, gdzie był "wymiatacz" od devopsu, wtedy jakiekolwiek problemy rozwiązywało się świetnie- ja siedziałem w kodzie, szukałem sposobów optymalizacji itd., a równolegle devops grzebał w infrze i też zwykle coś mu się udało poprawić/ zoptymalizować. Sam na pewno bym tego nie zrobił (a przynajmniej nie w tak krótkim czasie).

micheangelo napisał(a):

Ja osobiście uważam, że każdy powinien skupić się na tym na czym się zna i robić to dobrze. Idealnie gdyby programista wiedział, gdzie jego soft będzie działał, jak się skalował i umiał to wziąć pod uwagę

Będzie umiał to wziąć pod uwagę, jeśli nie będzie rozumiał jak ten soft ma działać, ile mieć komponentów, ile każdy instancji, w jaki sposób się skalować?
Będzie umiał w ogóle napisać taki soft, jeśli np. nie będzie wiedział, jakie są możliwości skalowania?

Myśle, że warto znać na tyle devopsu, żeby być w stanie kompleksowo stworzyć, wdrożyć, utrzymywać i monitorować aplikację / serwis czy co tam kto robi. Trzeba też rozumieć jak to wszystko działa żeby jak @somekind napisał wiedzieć jakie są np. możliwości skalowania albo kiedy aplikacja klęknie. Jeśli chodzi o jakiś tuning, optymalizacje, security infry to już rzeczywiście warto zostawić to komuś kto się w tym specjalizuje. Ostatnie pare lat sporo pracuje z ludkami z usa i tam właśnie takie podejście kompleksowego rozwoju produktu jest chyba bardziej cenione niż skupienie tylko na kodzie i jakości kodu (tutaj czasem aż za bardzo w drugą strone) nie wiem czy to dobra droga ale patrząc po tym jakie projekty i pieniądze są po ich stronie a jakie u nas to chyba coś w tym jest.

Ja napiszę może konkrety ile DevOpsu powinien umieć dev:

1. Postawić za pomocą Terraform cluster K8S na dowolnej chmurze, czy to AWS/Azure/GCP
2. Ogarnąć postawienie Jenkinsa (lub innego toola np. Tekton) na K8S w celu budowy pipeline, budowanie aplikacji i pushowanie docker image, robienie git commit do repo z wersjami.
3. Następnie postawienie ArgoCD na K8S w celu Continous Deployment.

Wszystko ma być za pomocą IaaC, konfiguracja Jenkinsa także.

Konfiguracja secretów tylko w chmurze i skorzystanie z pluginu CSI K8S.

Robiłem takie powyższe rzeczy w dwóch firmach jako Java Developer.

Gdy mamy powyższe rzeczy zrobione wtedy możemy się zająć zbieraniem logów i monitoringiem aplikacji tutaj mam na myśli toole jak FluentD + ELK.

Kolejna sprawa jest taka, że powyższe czynności w porówaniu do programowania są śmiesznie proste, w sensie mam na myśli że tam nie trzeba zbytnio myśleć tylko po prostu czytać dokumentację i konfigurować. Gdybym miał to porównać z pisaniem kodu to dla mnie jest to odskocznia którą sobie na luzie robię.

To już się nie dziwię, że tyle firm płaci potem haracze hakerom, skoro budowanie infry powierza developerom, żeby sobie dla odskoczni coś innego porobili :-D
Takie robienie na zasadzie - podpatrzę sobie coś tam w dokumentacji, jakoś się to skleci, byle wstało.

Pewnie o firmach, które zatrudniają DevOpsów, CloudOpsów, SecOpsów itp. myślisz sobie "a na ch... im to" skoro developerzy sobie dla rozrywki to mogą robić w przerwach w programowaniu.

O matko... ręce opadają. Moim skromnym zdaniem takie podejście firm to patologia, czy też patodeveloperka.

Swoją drogą skoro chmury i DevOps takie proste, to skąd takie wysokie zarobki ludzi tym się zajmujących.

PaulGilbert napisał(a):

Takie robienie na zasadzie - podpatrzę sobie coś tam w dokumentacji, jakoś się to skleci, byle wstało.

Ej, ale w programowaniu często to działa. Kopiujesz sampla z dokumentacji. Zmieniasz w paru miejscach i działa XD W moim hobbystycznym projekcie w Haskellu dopiero po roku zrozumiałem "czemu tak" XD

Ja bym jeszcze rozumiał gdybyśmy gadali tu o jakichś turboseniorach, absolutnych wymiataczach którzy niosą firmę na plecach i od nich wszystko zależy.
Ale czytając wypowiedzi mam wrażenie, że te wymagania dotyczą chyba już nawet juniorów.

Może jestem leserem, może jestem upośledzony i bez skilla, ale żeby spełniać te wszystkie obecne wymagania w stopniu profesjonalnym (czyli mamy pewność, że wszystko śmiga) to trzeba nie mieć życia poza pracą albo 10 lat expa. Naprawdę oczekujemy od zwykłych midów by ogarniali front, backend, devops, testy i jeszcze inne "niezbędne" duperele? To, że firmy na to cisną to wiadomo, lepiej zapłacić jednemu frajerowi niż 3 oddzielnym stanowiskom, ale bawi mnie, że chyba jako społeczność się powoli na to godzimy i wręcz uważamy to za normalne.

Zwykły dev prywatnie może wymiatać w devops, natomiast przy pracy powinien wykorzystywać z tego minimum potrzebne na odpalenie projektu na localu. No chyba że ma devopsowanie wpisane w umowę i uwzględnione w stawce.