Dziennik zdarzeń w IT

Od programisty Java do Cloud Engineera. Jak zmienić swoją karierę i na tym nie stracić?

Od kilku lat coraz większą popularnością cieszy się rekrutacja na stanowiska DevOps lub Cloud Engineer, zarówno wśród mniejszych pracodawców, jak i globalnych gigantów IT. „DevOps” to kultura, którą powinny przyjmować organizacje, by przyśpieszyć swój wzrost i jakość wykonywanej pracy, a programista DevOps stanowi pomost między wszystkimi zespołami technicznymi zaangażowanymi w proces wytwarzania danego produktu. Umiejętności wymagane na to stanowisko są podobne do oczekiwanych od roli Cloud Engineera. W tym artykule skupię się właśnie na tej roli związanej z obsługą rozwiązań cloudowych. 

Z Backendu w stronę Cloud Engineera

Możliwe, że zastanawiasz się, jakie obowiązki wiążą się z takim stanowiskiem oraz jakie umiejętności trzeba posiadać, by sprawdzić się w tej roli. Ja również się zastanawiałem, gdy dołączałem do zespołu zajmującego się cloudem, po blisko 5 latach pracy przy Backendzie. Musiałem przebrnąć przez ogrom materiału, zrozumieć i zastosować nowe narzędzia oraz praktyki, by stać się „pełnoprawnym” Cloud Engineerem.

Chciałbym podzielić się subiektywnymi radami i przemyśleniami związanymi ze zmianą stanowiska z programisty backendu (Java) na Cloud Engineera. Powinny one rozwiać wiele wątpliwości i nakierować Cię na odpowiednie zasoby w Internecie, które skrócą czas adaptacji do nowej roli.

Dlaczego porzuciłem Javę?

Moją główną motywacją do zmiany stanowiska było poczucie stagnacji, chęć nauki czegoś nowego oraz rozszerzenia swoich umiejętności. Praca z cloudem to sporo wyzwań, nie tylko programistycznych, ale i z zakresu bezpieczeństwa, projektowania architektur, monitoringu czy sieci komputerowych.

Obecne trendy wskazują, że cloud zaczyna być dominującym obszarem w branży IT. Według Cloud Native Landscape kapitalizacja tego rynku to $14.43T, a finansowanie na poziomie $16.55B. Duże zainteresowanie cloudem powoduje, że tego typu rozwiązania stają się strategicznym elementem transformacji technologicznej.

Jedną z bardziej znaczących organizacji wyznaczającej trendy w świecie cloud-native jest Cloud Native Computing Foundation. Według raportu, w którym CNCF opisuje swoje działania po 2020 r., liczba członków tej organizacji wyniosła ponad 600. Trudno tutaj wymienić wszystkich, ale do największych należą Amazon, Google czy Microsoft. 

Potrzeba szybkiego dostarczania rozwiązań

Trendy to nie wszystko. Również czas ma ogromne znaczenie. Produkcja oprogramowania mocno przyspieszyła, a organizacje, nawet te duże, muszą produkować rozwiązania najszybciej jak to możliwe, aby utrzymać się na rynku. Same systemy również muszą się skalować w bardzo szybkim tempie. W jednym i drugim przypadku automatyzacja jest kluczowa. 

Jest na to sposób. Infrastructure as a code pozwala zautomatyzować tworzenie nowych środowisk i instancji maszyn wirtualnych, co z kolei ma wpływ na skrócenie czasu wejścia systemów na produkcję. Dzięki temu organizacje mają lepszy time-to-market, co szczególnie widać, gdy mamy do czynienia z wieloma zespołami. 

W tym procesie rola cloud providerów jest znacząca. Dostarczają oni rozwiązania, które pomagają osiągnąć wysoką dostępność aplikacji, większe bezpieczeństwo na wielu poziomach, oferując przy tym możliwość pełnej automatyzacji tych procesów. Co jest bardzo ciekawym wyzwaniem.

Niskie ceny, wspomniany proces oraz model pay-as-you-go to powody, dla których firmy m.in. decydują się na cyfrową transformację.

Odrobina backgroundu, czyli od czego zaczęła się moja kariera Java Developera

Pierwsze pięć lat mojej kariery to przede wszystkim Java. Byłem odpowiedzialny m.in. za integracje między systemami third-party, pisanie middleware’ów i wystawianie ich w postaci Rest API. Typowa backendowa rola. 🙂

Następnie trafiłem do VirtusLab i kontynuowałem swoją przygodę z backendem. W życiu każdego nadchodzi jednak taki moment, w którym dochodzimy do ściany i stwierdzamy, że czas zmienić kierunek podróży. Ja natrafiłem na tę metaforyczną ścianę, gdy moje codzienne obowiązki stały się bardzo rutynowe, a ekosystem JVM-owy przestał być dla mnie ekscytujący. 

I tak postanowiłem pójść w stronę clouda. Dołączając do zespołu, który się tym zajmuje, nie straciłem swojego doświadczenia, a dodatkowo poszerzyłem horyzonty o nowe technologie i koncepty. 🙂 Nie żałuję swojej decyzji!

Czym zajmuje się Cloud Engineer na co dzień?

W VirtusLabie wyznajemy kulturę DevOps, a co za tym idzie – nie tylko tworzymy (część dev) software, ale i go obsługujemy (część ops). 

Dołączyłem do zespołu w trakcie tworzenia platformy opartej o ekosystem Kubernetes w Azure. Taka platforma ma na celu zminimalizowanie progu wejścia oprogramowania na produkcję i ujednolicenie stacku technologicznego w organizacji. 

Poza zadaniami architektonicznymi i programistycznymi, których efektem były nowe „klocki” infrastruktury, pojawiły się obowiązki związane z szeroko pojętym onboardingiem zespołów oraz wsparciem ich w przypadku problemów. Co oznacza, że moja praca koncentrowała się głównie na końcowych użytkownikach rozwiązania, nad którym pracowaliśmy.

Wiedza backendowa w pracy Cloud Engineera

Niezależnie, czy zajmujesz się backendem czy infrastrukturą cloudową, dalej obowiązują Cię dobre praktyki związane z inżynierią oprogramowania:

  • SOLID – rozumienie, czym jest SOLID bardzo mi się przydało. Reguły SOLID (w szczególności niezawodne SRP) upraszczały kod w trakcie dodawania nowych „ficzerów” i poprawiały czytelność. 
  • Testy automatyczne – dobrze napisane testy dawały gwarancję operacyjności platformy i szybkie wychwytywanie błędów.
  • Dokumentacja – pisanie dokumentacji nie omija żadnego programisty. 🙂 Trzeba o nią zadbać. Infrastruktura również ma swój interfejs, który warto udokumentować, żeby użytkownicy wiedzieli, jak wykorzystać efekt naszej pracy.
  • Integracja systemów – doświadczenie w integrowaniu systemów okazało się bardzo pomocne. Dostawcy rozwiązań chmurowych wystawiają API programistyczne, które można wykorzystać w swojej pracy. W moim wypadku było to „Azure SDK for Go”, z którego korzystałem w asercjach testów infrastruktury pisanych przy użyciu Go i Terratest.
  • Projektowanie architektur – projektowanie rozwiązań jest nieodłączną częścią każdego projektu. W przypadku clouda architektura najczęściej jest na poziomie usług, jakie daje dostawca clouda i sieci.

Wyzwania związane ze zmianą ścieżki kariery

Jednym z największych wyzwań, z jakimi przyszło mi się zmierzyć podczas zmiany kierunku rozwoju, było zrozumienie, czym są aplikacje „cloud native”, a także działania usług Azure’a, których używaliśmy.

Do tej pory korzystałem z Kubernetesa tylko jako użytkownik platformy. Po zmianie stanowiska musiałem nauczyć się, jak wygląda proces uruchomienia i skonfigurowania klastra Kubernetesa w Azurze (Azure Kubernetes Service), który jest dość złożony. Gdy dodamy do tego integrację z Azure Active Directory, by dodatkowo zabezpieczyć klaster, proces staje się jeszcze trudniejszy. 

Na tym jednak nie koniec. Potrzebowałem głębszego i szerszego  zrozumienia modelu sieciowego ISO. Sama wiedza, że coś takiego istnieje, niestety nie wystarcza. Opiera się na tym choćby idea Load Balancerów, które mogą działać na warstwie 4 lub 7. Przykładem Load Balancera, który działa na warstwie aplikacji (7), jest Azure Application Gateway, z którego korzystamy do tej pory.

Język programowania Go okazał się łatwiejszy, niż przypuszczałem. Prawdą jest, że nauka każdego kolejnego języka przychodzi łatwiej. Więcej uwagi natomiast wymagał ode mnie Terraform. Musiałem zrozumieć, jak działa faza planowania i aplikowania infrastruktury, w jaki sposób warunkowo tworzyć zasoby, i jak wersjonować taką infrastrukturę.

Źródła, które pomogły mi zaadaptować się do roli Cloud Engineera

Jak wiadomo, najlepiej po wiedzę udać się do źródła. 

Dokumentacja Microsoftu jest na naprawdę dobrym poziomie i polecam ją w kontekście nauki. To samo mogę powiedzieć o dokumentacji Terraforma. 

Dokumentacja Kubernetesa jest w porządku, jednak początkujący mogą mieć problem z wystartowaniem ze względu na dużą liczbę zagadnień tam opisywanych. Aby lepiej zrozumieć istotę Kubernetesa, warto zapoznać się z blog postami i kursami na platformie Udemy autorstwa Mumshada Mannambetha. Mumshad nie tylko świetnie tłumaczy skomplikowane zagadnienia, ale również określa na początku kolejność ich przyswojenia.

Poza wymienionymi zasobami poniżej podaję dodatkowe źródła wiedzy, z których korzystam, by być na bieżąco:

VirtusLab wspiera proces przebranżowienia

W moim przypadku przejście do roli Cloud Engineera nastąpiło w wyniku naturalnej chęci poszerzenia swojego doświadczenia. Była to dobra decyzja, dzięki której na nowo polubiłem programowanie. Jeśli zastanawiasz się, czy sprawdzisz się w nowej roli, mam nadzieję, że chociaż część Twoich wątpliwości udało mi się rozwiać. W VirtusLab pomagamy w zmianie ścieżki kariery. W razie dodatkowych pytań służę także pomocą na LinkedIn.

Oceń artykuł
(0 / 5)
Subscribe
Powiadom o
guest
0 komentarzy
Informacje zwrotne w tekście
Wyświetl wszystkie komentarze
This site is registered on wpml.org as a development site.
123