Skocz do zawartości

Temat został przeniesiony do archiwum

Ten temat przebywa obecnie w archiwum. Dodawanie nowych odpowiedzi zostało zablokowane.

RobertVox

Ile DevOps powinien znac Java Developer, ktory specjalizuje sie w microserevices

Rekomendowane odpowiedzi

witam,

 

jakich narzedzi z DevOpsa i jak gleboko powinien znac programista Java, ktory implementuje microservice.

Na pewno powinien znac Docker ale jak gleboko. Czy wystarcza na poziomie DOCKERFILE i podstawowych polecen czy powinien miec szersza wiesze (np. na poziomie klastrowania, docker compose, docker swarm, pacemaker)? Czy powinien znac Kubernetes? Jak dobrze?

 

Czy powinien on uczyc sie np. ansible albo puppet itp? Czy tym zajmuje sie juz tylko DevOps Engineer (Dawny Admin :) )

 

Innymi slowy jaka czesc DevOps powinien znac Microservices Developer aby dobrze wykonywac swoja prace.

 

I jeszcze jedno pytanie. Do Microservicow najlepiej uzyc Spring Boot i Spring Cloud.

 

A co myslicie o MicroProfi czy Payara, czy Wildfly Swarm. Czy nadaja sie to na produkcje, czy jest wystarczajaco stabilne.... Jakos nie mam do tego przekonania i mam odczucie ze JEE8 jeszcze nie weszla w microservices i ze poza Spring Boot i Cloud to raczej nie ma rownie dobrych alternatyw. Czy zgadzacie sie?

 

Czy waszym zdaniem Java EE 8 ma obecnie jakiekolwiek warte uwagi a co wiecej zastosowania frameworki do microserviceow czy bralibyscie tylko Spring Boot pod uwage?

 

Pytam bo chce specjalizowac sie w programowaniu Microservices i nie wiem czy jest sens obecnie pozostac przy Spring Boot/Cloud czy wglebiac sie w jakies nowosci, ktore pojawily sie w JEE8 od czasow JEE7. Z tego co wiem to nie ma tam prawie nic o Microservicach.

 

Z gory dzieki !

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Nie potrafię udzielić poprawnej i pełnej odpowiedzi na Twoje pytanie, ale jeśli pracujesz z dockerem to zaraz obok powinno się znać docker-compose. To narzędzie nie jest trudne, a bardzo ułatwia pracę jeśli w stack całej aplikacji wchodzi kilka kontenerów (ręczne linkowanie przez docker run --link fuj)

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Programista powinien znać tyle, ile jest mu potrzebne do sprawnej pracy. Podstawy basha i podstawowe narzędzia linuxowe pewnie się przydadzą. Infrastruktura to i tak co firma to obyczaj, więc w ogóle na tym bym się nie skupiał. O wiele istotniejsze jest, czy ten Java developer zna się swojej robocie. Dzielenie systemu na komponenty, architektura, sensowne testy, znajomość dobrych praktyk. Do tego umiejętność standardowych zagadnień typu autoryzacja, dostęp do bazy, modelowanie danych, JMS, REST. W przypadku systemów w chmurze pojęcie o wątkach, wyścigach, sychronizacji zadań.

 

O frameworki bym się nie spinał. Do Javy jest ich miliard. Jak umie coś zrobić w dwóch, to w trzecim też zrobi, jeśli rozumie ogólną ideę. Java na stałe już jest przybita do Springa, więc znajomość jego najpopularniejszych modułów (core, MVC, data, security, boot) nie zaszkodzi. Goła Java EE to już chyba tylko w bankach przetrwała.

 

Od seniora wymagałbym jeszcze nacisku na cały ekosystem usprawniający pracę zespołu: CI/CD, profile/konfigurowalność aplikacji, monitoring. W przypadku mikroserwisów dodatkowo kwestie typu backpressure, circuit breaker, request tracking, itp.

 

Programista ma programować i takich umiejętności bym od niego oczekiwał. Ma umieć stworzyć aplikację czy mikroserwis tak, aby obronił się przed upływem czasu, dawał się łatwo utrzymywać i jasno raportował, jak działa. Jeśli programista zna się na świecie infrastruktury i deploymentów to fajnie, ale na pewno to nie jest kluczowa umiejętność. W dużych firmach zazwyczaj są zespoły od infrastruktury i dostarczają jakieś narzędzia.

 

Co do Dockera, to jest to rewelacyjne narzędzie. Doker-compose podnosi poziom pracy o dwa poziomy. Ale też bym się tym nie kierował przy wyborze kandydata do zespołu, bo Dockera nauczy się w kilka dni. A jak ma kiczowate podejście do kodu, to nic tego nie uratuje.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Czy tym zajmuje sie juz tylko DevOps Engineer (Dawny Admin :) )

 

 

DevOps to DevOps, Admin to Admin. Nie myl tych dwoch pojec

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

  • Ostatnio przeglądający   0 użytkowników

    Brak zarejestrowanych użytkowników przeglądających tę stronę.

×
×
  • Dodaj nową pozycję...