Cloud Engineer

Co trzeba wiedzieć, by zostać Cloud Engineerem? Wywiad z Jarkiem Śmiejczakiem

Czym dokładnie zajmuje się Cloud Engineer? Jakie powinien mieć skille? Jak rozwijać swoje kompetencje, będąc na tym stanowisku? Szeroko na ten temat opowiada nam Jarek Śmiejczak z Clearcode, „człowiek-orkiestra” w branży IT.

Zacznijmy od początku. Kiedy zacząłeś swoją przygodę z IT i od czego wszystko się zaczęło? Skąd pomysł na tę branżę?

Jarek Śmiejczak

Moja historia jest bardzo szablonowa 🙂 W wieku 7 lat zobaczyłem swój pierwszy w życiu komputer, którym była Amiga 600 wraz z monitorem i prześlicznym czarnym joystickiem. Jakby tego szczęścia było za mało, przy komputerze stało całe opakowanie dyskietek 3,5” pełnych gier. Wsiąkłem i zatraciłem się bez reszty. Zainteresowanie programowaniem przyszło dużo później. Zaczynałem jako nastolatek, tworzyłem pierwsze programy GUI w środowisku Borland Delphi, używając do tego obiektowego dialektu języka Turbo Pascal.

Zacząłeś programować zawodowo w wieku 19 lat. Gdzie najpierw trafiłeś? Pamiętasz swoją pierwszą rozmowę rekrutacyjną?

Programowanie stało się moim pełnoetatowym hobby, o ile tak można nazwać nastoletnie “spędzanie nocy przed komputerem”. Mając odrobinę szczęścia trafiłem do klasy o profilu informatycznym z fajną grupą uzdolnionych ludzi – zawdzięczam im naprawdę dużo. To były czasy pojawienia się trendu Web 2.0 – blogi, agregatory treści. W ramach koleżeńskiej rywalizacji zaczęliśmy uczyć się HTML, Javascript, CSS i języka PHP do tworzenia treści. Własnym sumptem wykupiliśmy hosting na platformach typu boo.pl i tworzyliśmy własne silniki blogowe. W zasadzie mimochodem, część z nas stworzyła sobie mniej lub bardziej rozbudowane portfolio. Dzięki temu miałem dużo łatwiej i w zasadzie krótko po skończeniu liceum stwierdziłem, że poświęcę się temu, co sprawia mi przyjemność.

Moją pierwszą poważną pracą było tworzenie stron w małej łódzkiej agencji interaktywnej. Sama rozmowa poszło dość prosto, ponieważ prezentowałem moje kawałki kodu z czasów licealnych. Jakość tego kodu postawiała sporo do życzenia, ale wystarczyła do tego, bym mógł wystartować na stanowisku programisty PHP i zacząć swoją przygodę w IT.

Czym zajmowałeś się na początku zawodowej ścieżki?

Moje początki były związane z “całościowym” podejściem do tworzenia stron internetowych. Praca nad kampaniami reklamowymi często wymagała szybkiego nabierania nowych umiejętności i adaptacji do często zmieniających się warunków i wymagań klientów. Można powiedzieć, że była to spora i długo trwająca lekcja pokory wobec wyników swojej pracy. Oczywiście, na początku nie była to taka w pełni samodzielna praca i na swojej drodze spotkałem wielu fajnych ludzi, którzy pomagali mi w tym procesie.

Mnogość problemów, które się pojawiały – od złego koloru tekstu na stronie poprzez nie ładującą się listę artykułów, kończąc na mrożącym krew w żyłach błędzie HTTP 500 – sprawiała, że musiałem douczać się wielu rzeczy: a to aspektów MySQL, a to zmian w najnowszej wersji PHP i tego, jak to wpływa na konfigurację Apache. Realia tego zakątka branży wymagały szerokiego (choć niekoniecznie głębokiego) wachlarza umiejętności oraz praktycznego rozwiązywania problemów. Wszystko wg zasady: “twórz kod tak, aby była zapłacona faktura” 🙂

ZOBACZ TEŻ:  Historia metodyki DevOps. Założenia i przełomy w jej rozwoju

Dość szybko zainteresowałeś się rolą DevOpsa – dlaczego akurat taki wybór?

DevOpsowanie jako dziedzina fascynuje mnie głównie dlatego, że skupia się na wielu aspektach i etapach wytwarzania oprogramowania. Wspieranie zespołu w dostarczaniu wyników pracy klientowi daje wyjątkowe uczucie satysfakcji. To jest coś, co przyszło z czasem, natomiast wydaje mi się, że z tej drogi już nie ma odwrotu 🙂

Tworzenie dowolnego większego potoku wdrożenia aplikacji wymaga znajomości języków programowania, ale i też umiejętności komunikacji – zarówno z osobami technicznymi (głównie programistami), jak i z osobami, które skupiają się na aspektach biznesowych. Ten obszar bardzo mnie interesuje – realny wpływ każdej linijki kodu na świat i ludzi wokół.

PHP, Python, cloud engineering. Mówią o Tobie “człowiek orkiestra” 🙂 Czy miałeś jakiś konkretny plan na rozwój swoich kompetencji i ścieżki zawodowej? Jak je budowałeś i rozwijałeś?

Przyznam szczerze, że zdobywanie wiedzy przychodziło organicznie i na początku nie posiadałem zbyt konkretnego planu, poza podążaniem za swoją pasją. Spotkałem wielu ludzi, którzy wyciągali pomocną dłoń wtedy, kiedy tego naprawdę potrzebowałem i inspirowali do tego, aby poświęcać się jeszcze bardziej.

Wraz z odpowiedzialnościami, które na mnie spadały, zaczynałem się interesować sposobami na organizację pracy, zaczynając od choćby getting things done. Praca z klientami sprawiała, że wraz z umiejętnościami twardymi musiały się – mniej lub bardziej – kształtować te miękkie.

Jak trafiłeś do Clearcode? Opowiedz proszę o początkach w firmie.

Pewnego lipcowego popołudnia zobaczyłem ofertę “małej” firmy z Wrocławia, która zajmowała się m.in. systemami do analityki stron webowych. Aplikowałem na pozycję programisty Python/Django, z którymi miałem już swoje doświadczenia i po miłej rozmowie rekrutacyjnej dostałem ofertę i przeprowadziłem się do Wrocławia.

Trafiłem do zespołu fajnych i mocno technicznych ludzi, którzy wraz ze mną uczyli się, jak reviewować, testować, a na samym końcu – deployować i monitorować aplikacje, często popełniając błędy i ucząc się na nich (np. wprowadzając spotkania post-mortem, tworząc kolejne warstwy testów i dodając kolejne metryki do aplikacji).

Pracując w Clearcode, dostrzegłeś AWS-a, który dopiero zdobywał popularność. Skąd taki wybór?

Zespoły, w których pracowałem, dość często były wrzucane na głęboką wodę. Zaczynaliśmy od tysięcy zapytań na sekundę, przechodzimy przez miliony, a przyszłość pokaże, czy się zatrzymamy. Stało się oczywiste, że przy takim ruchu i potrzebach musimy umieć dynamicznie adaptować się do potrzeb klientów. W jednym z moich pierwszych projektów klient przekazał nam kod, który był postawiony na AWS. I choć ten wybór nie był do końca świadomy, AWS jako platforma okazał się szczęśliwym strzałem dziesiątkę i otwierał nam drogę do skalowanie rozwiązań, na które firma bez własnej serwerowni nie mogłaby sobie pozwolić.

W Clearcode miałeś pierwszą profesjonalną okazję w pracy z serwisami AWS. Na czym ta praca polegała?

Miałem okazję uczestniczyć w pisaniu kodu Pythonowego w Fabricu, który deployował aplikację, potem wraz z zespołem migrować definicję infrastruktury z Puppeta na Ansible, a z czasem przyszła pora i na Terraforma. W tym samym projekcie zaczynaliśmy od 150 instancji EC2, które zajmowały się odpowiadaniem na tysiące zapytań przychodzących z platform, które w AdTechu nazywają się Exchanges. Interfejs API AWS pozwalał na automatyzację wielu aspektów zarządzania takim projektem.

Czym zajmuje się Cloud Engineer? Jakie powinien mieć skille?

Z bardzo podstawowych umiejętności, które otwierają drzwi do tego stanowiska, wymienię najważniejsze:

  • znajomość kluczowych usług chociaż jednego z dostawców rozwiązań chmurowych, pozwalająca na zdeployowanie aplikacji. Np. dla AWS jest to EC2/ECS/EKS,
  • umiejętność programowania w jednym z popularnych języków (Python, Golang, Ruby…), w stopniu pozwalającym na pisanie skryptów automatyzujących deployment,
  • umiejętność konfigurowania systemów i deployowania aplikacji (CI/CD),
  • znajomość wzorców związanych z architekturą chmurową/microservices i wiedza, gdzie i kiedy ich używać. W przypadku AWS istnieją ścieżki edukacyjne, które pozwalają się części z tych zagadnień nauczyć i zaaplikować za pomocą produktów AWS,
  • posiadanie dobrych umiejętności komunikacyjnych – pragmatyczne i analityczne podejście do napotkanych przeszkód,
  • wiedza nt. architektury tworzenia bezpiecznych rozwiązań, świadomość słabości protokołów, które aplikacja używa i umiejętność przestrzeni ataków (zachowując zdrowy balans),
  • optymalizowanie rozwiązań pod kątem ich wydajności – observability, distributed tracing,
  • głębokie zrozumienie, jak monitorowana aplikacja działa, jakich metryk używać i jak tworzyć czytelne dashboardy. Także te, które na pozwalają metryki biznesowe,
  • dokumentowanie decyzji infrastrukturowych/architektoniczych i umiejętność wyjaśnienia ich wpływu na projekt,
  • znajomość sposobów/wzorców na optymalizację kosztów zdeployowanych rozwiązań,
  • dzielenie się wiedzą z zespołem programistów.

Jak można dalej rozwijać się w tej dziedzinie?

Zależnie od progu i doświadczenia, na pewno dobrym wejściem jest:

  • przeczytanie książek Gene Kim-a np. “Projekt Feniks”,
  • przejście ścieżki  edukacyjnej przygotowanej przez Twojego aktualnego dostawcę rozwiązań chmurowych,
  • obserwowanie trendów i uczenie się nowych technologii i produktów swojego aktualnego cloud providera,
  • śledzenie na bieżąco wszystkiego, co wychodzi spod pióra ludzi takich, jak Gene Kim, Jez Humble, Martin Fowler czy Jeff Barr,
  • chodzenie na meetupy dla devopsów – wymiana wiedzy i doświadczeń jest bezcenna,
  • uczestniczenie/prowadzenie projektów open-source jest niesłychanym zastrzykiem doświadczenia i dodatkowo wspiera wymianę wiedzy oraz bycie “up-to-date”. Ma to znaczenie nawet wtedy, gdy jesteś początkujący – część projektów jest prowadzonych przez doświadczonych ludzi i większość z nich z chęcią mentoruje i wspiera ciekawe, przydatne pomysły. Mówię to na podstawie własnych doświadczeń z kontrybuowania dla Mozilli, jak i prób krzewienia tej kultury w ramach Clearcode. 
ZOBACZ TEŻ:  Data Lake na AWS-ie. Budowa, problemy i rozwiązania

Clearcode prowadzi obecnie rekrutację do roli Lead Cloud Engineera. Kogo dokładnie poszukujecie? Na jakie benefity może liczyć kandydat do tej roli?

Potrzebujemy doświadczonej i samodzielnej osoby, której nie przeszkadza dzielenie się wiedzą oraz która posiada dar do tłumaczenia chmur na ludzki język 🙂 Szczegóły technologiczne są spisane w ofercie.

Warto wspomnieć, że Clearcode daje wiele narzędzi rozwoju:

  • biblioteczka firmowa,
  • dostęp do serwisów z kursami, np. Udemy, Oreilly,
  • wyjazdy na konferencje,
  • wspieranie wewnętrznych inicjatyw poprzez np. konto AWS, na którym można zdeployować prototyp swojego pet-projectu,
  • self development day,
  • ferajny – wewnętrzne spotkania, podczas których ludzie z różnych zespołów dzielą się tym, co technologicznie u nich słychać,
  • refundacja kosztów za środowiska programistyczne firmy Jetbrains,
  • mega stymulująca atmosfera pełna otwartych na wyzwania ludzi – wielu z nas bardzo lubi chodzić na kawę po to, aby móc wymieniać się wiedzą. Pomimo wielu stanowisk, w firmie panuje poczucie równości i szacunku wobec siebie nawzajem i swoich umiejętności. Dotyczy to też ludzi, którzy nie uczestniczą bezpośrednio w wytwarzaniu tworzenia aplikacji.

Nie pracowałem w firmie z tak bardzo wyluzowanym i pozytywnym zarządem 🙂

Czym zajmujesz się obecnie? W jakich technologiach pracujesz?

Zajmuję się tworzeniem kodu w Terraformie. Ansible, Pythonie oraz automatyzacją procesów w Azure Pipelines. Do tego dochodzi całe portfolio usług AWS, od ECR po Redshifta kończąc.

Uczestniczę w rozwiązywaniu problemów, które pojawiają się podczas tworzenia aplikacji i używania usług chmurowych przez programistów (np. jak połączyć się z bazą danych, które informacje warto logować), biorę też udział w procesie tworzenia architektury aplikacji i dokumentowania podjętych decyzji.


Jarek Śmiejczak. Człowiek-orkiestra w branży IT, Cloud Engineer i programista z kilkunastoletnim doświadczeniem. Certyfikowany AWS Architect Associate i pasjonat rozwiązań chmurowych. Kontrybutor Mozilli. Obecnie pracuje w Clearcode przy zaawansowanych systemach z branży AdTech.

baner

Zdjęcie główne pochodzi z Pexels.

Joanna Pasterczyk
Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
24 dni wyzwania JavaScriptmas, czyli nauka JavaScript do Wigilii