Czy znajomość mikroserwisów wykracza poza poziom Juniora?

Czy kandydat na junior w swoich projektach do cv powinien mieć mikroserwisy czy ta wiedza wykracza po za ten poziom i wystarczy dobry monolit? I w ogóle czy od juniora można wymagać jakieś podstawowej wiedz w tym temacie?

Junior to bardzo nieprecyzyjne określenie, nie istnieje zakres wiedzy którą junior powinien posiadać i po przekroczeniu którego staje się już midem. Pewnie, że dobrze zorientowany junior może wiedzieć czym są mikroserwisy, natomiast umiejętność poprawnego zastosowania tego wzorca przypisałbym już raczej komuś z nieco większym doświadczeniem.

Junior nie potrrafi nawet w dobry monolit a co dopiero wymagać umiejętności pisania poprawnie mikroserwisów ;)

A ja odpowiem trochę nie na temat ale odniosę się do fragmentu

Czy kandydat na junior w swoich projektach do cv powinien mieć mikroserwisy

Na prawdę trudno w pojedynke napisać taką ilość kodu żeby uzasadniała podział kodu na mikroserwisy. Bo może tego w tutorialach nie widać, ale często pojedyncze mikroserwisy to naprawde spore klocki kodu i często jest tak że nad pojedynczym mikroserwisem pracuje cały zespół ludzi

I w ogóle czy od juniora można wymagać jakieś podstawowej wiedz w tym temacie?

Zasada jest prosta. Wymagać można wszystkiego:

• Idziesz na programistę Javy a oni pytają o kruczki w oraclu bo pół logiki mają w procedurach składowanych.
• Idziesz na Javę a oni pytają się czy nie chciałbyś pracować w C++ (zdażyło mi się bo mieli tylko jeden projekt w Javie i jakby go zaorali to dostaję możliwość pisania w C++).
• Idziesz na programistę Javy a oni pytają czy niechciałbyś się nauczyć Scali bo właśnie kupił ich niemiec i łączy zze swoją drugą firmą gdzie mają wszystko w Scali
• Idziesz na juniora i wrzucają cię do legacy projektu gdzie jesteś jedynym programistą.

UPDATE Swoją drogą wyobrażam sobie taki scenariusz w głowie:
rozmowa rekrutacyjna w firmie iź

• rekruter - prosze powiedzieć co pan wie o mikroserwisach
• OP - nic nie wiem
• r - i pan chce być programistą jak pan nic nie wie o mikroserwisach?
• op - ale KamilAdam pisał na 4p iż junior nie musi nic umieć o mikroservisach
• r - to niech teraz KamilAdam pana zatrudni, dziękujemy

Nofenak napisał(a):

Czy kandydat na junior w swoich projektach do cv powinien mieć mikroserwisy czy ta wiedza wykracza po za ten poziom i wystarczy dobry monolit? I w ogóle czy od juniora można wymagać jakieś podstawowej wiedz w tym temacie?

Ja jako Junior miałem na GitHubie jakieś CRUDy w formie mikroserwisów. Ile powinieneś o tym wiedzieć to nie wiadomo. Rekrutacja to często loteria. Czasem wymagają człowieka co wie wszystko za 50% stawki rynkowej a czasem mogą nie zadać żadnego pytania technicznego i można dostać przyzwoite pieniądze.

Nie doszukuj się logiki w rekrutacji bo to droga do nikąd.

PS. Zawsze warto wiedzieć przynajmniej coś, cokolwiek. Jak przynajmniej potrafisz opowiedzieć o mikroserwisach i jak działają to zawsze brzmi lepiej niż jak nawet nie potrafisz wydusić z siebie słowa na ten temat.

Nofenak napisał(a):

Czy kandydat na junior w swoich projektach do cv powinien mieć mikroserwisy

Nie, po co się ośmieszać? Język, framework i IDE już opanowałeś, żeby z palca i płynnie implementować nieskomplikowane wymagania biznesowe?

Nofenak napisał(a):

I w ogóle czy od juniora można wymagać jakieś podstawowej wiedz w tym temacie?

W podstawowym stopniu jak najbardziej niemniej dla mnie to nie jest warunek konieczny. Dla mnie liczą się podstawy. Co mi z juniora który nawija makaron na uszy o mikroserwisach, a nie potrafi poprawnie używać frameworka czy konstrukcji języka?

Nofenak napisał(a):

czy ta wiedza wykracza po za ten poziom i wystarczy dobry monolit?

Junior i dobry monolit - wybierz jedno ;)

Szado napisał(a):

Junior to bardzo nieprecyzyjne określenie,

Podobnie jak określenie "microservis"

Kodowanie w jednym mikroserwisie powinno być łatwiejsze niż w jebu...ym monolicie
A nikt zdrowy psychicznie nie każe juniorowi projektować strategicznie / dokonywać cięcia / projektować komunikacji czyli ogarniać wiele mikroserwisów

Uważam, że jak ktoś chce być dobry, to nie powinien w takich kategoriach w ogóle myśleć. Możesz być juniorem i zgłębiać tematy pokroju optymalizowania JVM GC itd. To nie jest tak ze jak osiągnąłem poziom mida/seniora, to nagle magicznie się otwiera jakieś drzewko umiejętności pisania mikroserwisów, które można skillować.
Raczej nie powinni takiej wiedzy wymagać. Co z drugiej strony, nie powinno być dla Ciebie usprawiedliwieniem żeby tematu nie drążyć.

Jeden rekruter powie tak, inny powie inaczej. Im więcej potrafisz, tym lepiej dla Ciebie.

Ja tylko przypomne, że np. Kuba Kubryński kiedyś wspominał, że mikroserwisy to najtrudniejsza architektura z jaką miał okazję pracować więc odpowiedź na pytanie "czy znajomość mikroserwisów wykracza poza poziom juniora" zdaje się oczywista.

MOim skromnym zdaniem mikroserwis jest prostszy do napisania, niż ten mityczny "monolit". Właściwie mikroserwis to taki monolicik.

piotrpo napisał(a):

MOim skromnym zdaniem mikroserwis jest prostszy do napisania, niż ten mityczny "monolit"

Heh, to w zasadzie stawia pytanie czym się różni mikroserwis od mitycznego monolitu i jeszcze bardziej mitycznego rozproszonego monolitu jak tu niektórzy uwielbiają obwieszczać Nie masz mikroserwisów tylko rozproszony monolit bo twoje mikroserwisy nie spełniają feature X gdzie pod X podstawiasz co tam lubisz, np replikację, albo jeszcze co innego

Właściwie mikroserwis to taki monolicik.

No tak, ale jak ma być ta sama ilość kodu to łatwiej to zrobić w jednym projekcie niż dzilić na dwa projekty. Bo łatwiej można refaktoryzować jak się człowiek pomyli

BTW to mi podsuwa myśł że podział na heksy czy subdomeny (jak zwał tak zwał Architektura Heksagonalna woli określenie heksy, a DDD woli okreslenie subdomeny ale IMHO to to samo) jest ważniejszą (i trudniejszą) umiejętnością niż podział ma mikroserwisy, bo jak ma się już podział na heksy to na osobne mikroserwisy przerobi to ogarniety junior, a dobrze wybrać linię podziału heksów żeby nie było głupot to już często zadanie nie takie proste

Takie luźne przemyślenia przy piątku

@KamilAdam: To będzie trochę dyskusja teologiczna o tym ile diabłów się mieści na czubku szpilki :) Najpierw spostrzeżenie - zarówno mikroserwis, jak i makroserwis (monolit) mają z grubsza taki sam rozkład wertykalny - jakiś tam warstwa interface'u (API), logika biznesowa, warstwa utrwalania danych. To co "intuicyjnie" mówi nam, że coś jest mikro, albo monolitem, to zakres ospowiedzialności (szerokość tych warstw). Moja hipoteza jest taka, że mając dostęp jedynie do kodu takiego mikro/makro serwisu, nie byłbym wstanie powiedzieć, czy to jeszcze mikro, czy monolit. O mikroserwisie, możemy mówić dopiero patrząc na cały system, bo dopiero w systemie można zaobserwować ten podział na mniejsze usługi.

O ile napisanie pojedynczego, małego serwisu jest czymś czego można od juniora oczekiwać, to raczej nie dawałbym mu do oganięcia systemu w architekturze mikroserwisowej (tak, żeby OP, też miał jakąś informację). Nie mieszałbym do tego ani DDD, ani Hexagonal Architecture, bo one mogą zaistnieć, ale wcale nie muszą. zarówno w monolicie, jak i w mikroserwisach. To co któryś z klasyków opisał, to "system małych, luźno powiązanych usług" - ni mniej, ni więcej, z całym złem i dobrodziejstwem szerokich możliwości interpretacji.

To co ja jeszcze zauważam jako charakterystykę dużej części systemów z mikrousługami, to robienie na piechotę tego co baza danych daje z marszu, czyli transakcyjności. Jak zerkniesz na bebechy bazy danych, to tam też masz dane, log transakcyjny, statusy zmian. Ale znowu, nie w każdym systemie takie transakcje muszą wystąpić.
No i podział na hexy to żaden problem, ale z podzieleniem "dobrze", czyli tak, żeby maksymalnie ograniczyć powiązania pomiędzy usługami będzie już trochę trudniej. No i jak sam napisałeś, refaktoryzacja systemu z wieloma usługami jest trudna, więc projekt robi ktoś bardziej doświadczony.

A już od strony rekrutacyjnej, gdybym pytał kandydata o mikroserwisy, to poruszyłbym takie tematy jak wzorce architektoniczne (saga, CQRS) i jakieś tematy techniczne. Propagowanie uprawnień, service discovery.

To wykracza poza poziom większości seniorów i architektów :)

Oczywiście, że można wymagać podstawowej wiedzy od juniora, szczególnie jak aplikujesz do firmy, której produkt składa się z takiej architektury