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