Przekwalifikowanie się z Dev na DevOps

Chciałbym przekwalifikować się z Developera na DevOps. Czy to ma znaczenie że mam 16 lat expa w java z punktu widzenia pracodawcy? Czy któryś tu z przystojnych kawalerów przeprowadzał kiedyś taką operację? Jak to zrobić i od czego zacząć? Nie wiem czy ma znaczenie ale od zawsze bardziej lubiłem sprawdzać jak coś działa niż tworzyć coś nowego. W sumie z tego powodu to nie musi być rola akurat DevOpsa. Ale myślę że to jest najłatwiejsze ze względu na moje doświaczenie w Java.
Będę wdzięczny za wskazówki i opinie
Pozdrawiam

Skoro jesteś javowcem to zbuduj sobie pipeline, który Ci zbuduje apkę mavenem albo gradlem, odpali testy, zawersjonuje, opublikuje z dockerem i ją wdroży na produkcję. Później zainterwsuj się roznymi setupami jak wdrożyć tę apkę w cloudzie, np. na ec2, ecs, aws lambdzie albo aks i już będziesz w połowie drogi.

czirman napisał(a):

od zawsze bardziej lubiłem sprawdzać jak coś działa niż tworzyć coś nowego. W sumie z tego powodu to nie musi być rola akurat DevOpsa. Ale myślę że to jest najłatwiejsze ze względu na moje doświaczenie w Java.

A nie podobałoby ci się na utrzymaniówce, gdzie ficzerów prawie nie ma?

czirman napisał(a):

Chciałbym przekwalifikować się z Developera na DevOps. Czy to ma znaczenie że mam 16 lat expa w java z punktu widzenia pracodawcy? Czy któryś tu z przystojnych kawalerów przeprowadzał kiedyś taką operację? Jak to zrobić i od czego zacząć?

Najlepiej to w ramach projektu, w którym pracujesz zacząć robić DevOps'owe zadania. Z czasem będziesz mógł powiedzieć, że jesteś DevOps. No chyba, że jesteś w jakimś dużym korpo, gdzie możesz zmieniać projekty albo udzielać się w kilku projektach.

Nie wiem czy ma znaczenie ale od zawsze bardziej lubiłem sprawdzać jak coś działa niż tworzyć coś nowego.

To może support aplikacji na L3 i bugfixing?

W sumie z tego powodu to nie musi być rola akurat DevOpsa. Ale myślę że to jest najłatwiejsze ze względu na moje doświaczenie w Java.

https://roadmap.sh/devops

Czytasz mapę i robisz jak napisał @twoj_stary_pijany

Będę wdzięczny za wskazówki i opinie
Pozdrawiam

Sam rozważam podobny zwrot. DevOps, Middleware. Najlepiej tam gdzie jest mniej frameworkozy i nie ma Scurma xD

@czirman z punktu widzenia pracodawcy 16 lat doświadczenia oznacza, że masz wyższe oczekiwania finansowe niż junior DevOps.
Zmiana specjalizacji może oznaczać chwilową (tj. 6-12 miesięcy) obniżke w wynagrodzeniu.
Szczególnie jeśli zmiany uda Ci się dokonać wew. aktualnej organizacji.

Mówię to z własnego doświadczenia. Pozwalałem ludziom u siebie w firmie na przebranżowienie, ale zawsze wiązało się to z chwilową obniżką pensji.

Najlatwiej ? Zacznij robic rzeczy zwiazane z opsowaniem w swojej firmie. Jesli takich nie ma ? Zmien firme najelepiej na korpo uzywajace Clouda, Gitlaba (pipeliney w Gitlabie sa o wiele fajniejsze niz Jenkins), K8S i tam zawsze znajda sie zadania zwiazane z opsowaniem. Zazwyczaj nikt nie chce tego robic. Nabierasz doswiadczenia, a pozniej cyk przeskakujesz do innego zespolu, zmieniasz nazwe stanowiska, grindujesz skillla przez jakis czas i rynek stoi otworem.

Ja tak skakalem w karierze miedzy QE - DEV - Performance Testing/optimisation - SRE - Infra - Devops. Haczyk? Jak pojdziesz w nowy obszar wiedza z poprzednich sie deaktualizuje. Np. Jave znam calkiem niezle ale na poziomie 11 bo pozniej ogarnialem clouda, k8s, helma, terraforma, wszelkie Kafki i Cassandry itp. Nie jestes w stanie byc na czasie z wszystkim.

Dwa razy się zastanów.

Firmy bardzo lubią szufladkować. Fullstack Engineer to jedna z niewielu hybrydowych ról, gdzie posiadanie kwalifikacji w kilku obszarach pomaga, a nie szkodzi. W przypadku łączenia backendu z infrastrukturą / platformą / DevOps, takie połączenie jest wprost zaskakująco uciążliwe, gdy przychodzi do poszukiwania pracy - co jak dla mnie jest to o tyle zdumiewające, że to chyba nie świadczy dobrze o kwalifikacjach backendowca, jeśli potrafi napisać aplikację, ale nie umie już jej wdrażać, zbudować pipeline'u którym zautomatyzuje proces weryfikacji czy wdrożenia, a w środowiskach chmurowych przynajmniej skonfigurować manifesty, by aplikacja mogła działać na klastrze lub wirtualnej maszynie. To według mnie takie rozsądne minimum dla Backend Engineera, które jednak według tego modelu szufladkowania powoduje, że jesteś jedną nogą Devem, a drugą DevOpsem, czyli nikim.

A gdyby przyszło Ci do głowy, żeby iść o krok dalej i nie tylko umieć zautomatyzować sobie weryfikację czy wdrożenia, ale jeszcze samowolnie stawiał sobie swoją infrastrukturę i ją utrzymywał, nauczył się korzystać z narzędzi IaC, zaczął się bawić w ogarnianie sieci, security, governance w chmurze, budowanie stosu observability, wdrażanie alertów itd. to robi się naprawdę wesoło.

IMO taki pivot można robić jak jest dobra sytuacja na rynku i pracodawcy są skłonni brać każdego "z ulicy". Wtedy to, że posiadasz doświadczenie z kilku obszarów nawet punktuje i pozwala zdobyć posadę. W sytuacji gdy mamy przesyt jak teraz, to zwrot w stronę DevOpsa uczyni Cię niezatrudnialnym w ciągu roku-dwóch. Przez tę tendencję do szufladkowania kandydatów w bardzo wąskie kategorie, okaże się że Twoje kwalifikacje jako Backend Engineer są już nieaktualne, bo zajmowałeś się DevOps, ale jako DevOps także będzie słabo, jako że robiłbyś to od relatywnie niedawna. Kilka lat próbowałem zrobić taki zwrot w stronę DevOps i kiedy już się udało, wpadłem właśnie w taką pułapkę

Dziękuję wszystkim za rady. Jak zwykle te formy okazało się dla mnie bardzo pomocne. Również dziękuje @superdurszlak za wskazanie zagrożeń.
Biorę się wiec do roboty
Pozdrawiam

pradoslaw napisał(a):

@czirman z punktu widzenia pracodawcy 16 lat doświadczenia oznacza, że masz wyższe oczekiwania finansowe niż junior DevOps.
Zmiana specjalizacji może oznaczać chwilową (tj. 6-12 miesięcy) obniżke w wynagrodzeniu.
Szczególnie jeśli zmiany uda Ci się dokonać wew. aktualnej organizacji.

Faktycznie może tak być. Dlatego może zamiast przekwalifikować się oficjalnie na DevOps czyli zmiana stanowiska, lepiej jest w ramach własnego projektu pozostać na aktualnym stanowisku ale dogadać się by robić zadania DevOps'owe jako coś dodatkowego do aktualnych obowiązków. Z początku brać prostsze mniejsze zadania a z biegiem czasu (ile czasu to już kwestia indywidualna) brać bardziej złożone zadania.

A jak już będziesz czuć się w miarę pewnie to w CV wpisz, że byłeś DevOps a nie Dev i aplikuj otwarcie na stanowiska DevOps.
Pójdziesz na kilka rozmów, odpytają Cię i się dowiesz czy już jesteś wystarczająco dobry.

Jak będziesz mieć wpisane w CV Dev to pewnie będą Cię z automatu odrzucać na stanowiskach DevOpsowych.
A jak wpiszesz DevOps w CV to jest szansa, że się dopchasz na rozmowę. Wtedy albo się obronisz albo nie.
Jeśli się obronisz to jesteś już oficjalnie DevOps :-)

PS. Jeśli jesteś w stanie obronić się na rozmowie technicznej to wszystko jedno co wpiszesz w CV. Gdy uznają na rekrutacji, że się nadajesz do roboty to Cię wezmą i tyle.

Co do tego doswiadczenia, z jedenj strony zgoda. Z drugiej zeby byc naprawde dobrym opsem warto przejsc najpierw przez bycie devem.

Ciężko stworzyć infrastrukturę symulującą prawdziwe warunki, bo co firma, to inny syf.
O ile możesz, to spróbuj w aktualnej firmie.
A o ile nie możesz - naucz się technicznie. Tak czy inaczej rozmowy przechodzisz ustnie i najczęściej w oderwanych od prawdziwej pracy warunków. :)

Najważniejszy skill to integracja rzeczy. Tak jak wcześniej poprzednik pisał polecam pipeliny i postawienie community Gitlab. Robisz sobie repo i robisz pipeline automatyczny np. do testów. Stawiasz SonarQube i dorzucasz quality check przy mergu.

Dalej idąc możesz postawić repo Dockerowe internalowe, zobaczyć co się z czym je. Dalej możesz pójść z k3s. Dalej pójść z utworzeniem Helm chartów. Utworzyć Dockerfile w apce. Utworzyć wersjonowanie aplikacji, release. Pomyśl sobie jak będziesz wypuszczał np. fixy i łatki, jaki proces na to zrobić. I tak dalej integrować i tak dalej.

WhiteLightning napisał(a):

Co do tego doswiadczenia, z jedenj strony zgoda. Z drugiej zeby byc naprawde dobrym opsem warto przejsc najpierw przez bycie devem.

Na tą chwilę nie mam ambicji zostać ani najlepszym devopsem anie developerem

Majksu napisał(a):

Ciężko stworzyć infrastrukturę symulującą prawdziwe warunki, bo co firma, to inny syf.
O ile możesz, to spróbuj w aktualnej firmie.
A o ile nie możesz - naucz się technicznie. Tak czy inaczej rozmowy przechodzisz ustnie i najczęściej w oderwanych od prawdziwej pracy warunków. :)

Najważniejszy skill to integracja rzeczy. Tak jak wcześniej poprzednik pisał polecam pipeliny i postawienie community Gitlab. Robisz sobie repo i robisz pipeline automatyczny np. do testów. Stawiasz SonarQube i dorzucasz quality check przy mergu.

Dalej idąc możesz postawić repo Dockerowe internalowe, zobaczyć co się z czym je. Dalej możesz pójść z k3s. Dalej pójść z utworzeniem Helm chartów. Utworzyć Dockerfile w apce. Utworzyć wersjonowanie aplikacji, release. Pomyśl sobie jak będziesz wypuszczał np. fixy i łatki, jaki proces na to zrobić. I tak dalej integrować i tak dalej.

To to akurat rozumiem że studencki świat to inna bajka od produkcyjnego. W sumie u mnie w firmie jest chyba syf. Nie potrafię ocenić jakości tego. Ale non stop słyszę jakieś dziwne problemy, a to terraform się nie buduje albo jakieś problemy a credentialami itp. Problem w tym że u nas jest parcie na dostarczanie ficzerów, ignorując fakt że jakość i szybkość developmentu zależy w dużej mierze od infry. Więc nie ma takich zadań wprost devopsowych.W sumie mogę się w to wgłęmbić poza godzinami pracy.