Mikroserwisy - do czego?

Zaczynam nową pracę, póki co z wiadomych przyczyn są problemy z załatwieniem dostępów, wprowadzenia w projekt, itp, itd, więc dostaliśmy liste technologii jakie będziemy wykorzystywać i które dobrze żebysmy, póki co we własnym zakresie poznali.

No a jako, że najlepiej idzie mi nauka przez praktykę, to chciałbym wyklepać coś więcej niż hello world, ale nie bardzo wiem co konkretnie :D Więc pytanie do Was, podajcie proszę kilka tematów na projekt oparty o mikroserwisy. Wiem, że teoretycznie mogę zwykłego cruda rozbić na kilka serwisów, ale wolałbym jednak by ten mini projekt miał jakiekolwiek argumenty za tym by być napisanym w taki a nie inny sposób.

Ciężko będzie znaleźć argumenty na uS w małym kontekście. Może najwyżej "polyglot", czyli w różnych językach (Java/ C#/ Python)
A już co firma ma, to nie wiemy.

Hmmm ... może tak dla CRUDP
Main CRUD
Autentication & authorization (zyskujesz elastyczność zamiany na inny)
Printing

Kiedyś takie repo poczyniliśmy, może Cię zainspiruje https://github.com/spring-petclinic/spring-petclinic-microservices

Generalnie mikroserwisy nigdy nie są celem samym w sobie, ale rozumiem, że chciałbyś to sobie przećwiczyć. Spróbuj napisać np kawałek systemu, w którym można dodawać oferty, a potem je wyszukiwać pełnotekstowo. Taki uproszczony OLX. Podziel to ładnie na konteksty i zaimplementuj jako zestaw mikrousług.

Kalkulator, każde działanie w oddzielnym serwisie.

Są różne technologie microserwisów. Jaka dokładnie technologia jest preferowana przez tech leada?

Mam póki co bardzo mało informacji, na dniach się to powinno rozjaśnic. Generalnie język to Java, do samych mikroserwisów używany jest Spring Cloud + Kafka / REST do komunikacji.

Może więc warto na początek zaprzyjaźnić się z Kafką? :)

Nad tym też pracuję ;) jednak również brakuje mi pomysłów, o ile z synchronicznym podejściem do tematu jakoś sobie radzę, to nie bardzo wiem gdzie/po co użyć kolejek, co mi przychodzi do głowy to:
-serwis do wysyłki maili, mam zaimplementowaną rejestracje użytkownika, która kończy się wysyłką maila, mogę to wynieść do osobnego mikroserwisu i zrealizować komunikację przez Kafkę
-zapis do bazy danych, mam prostą apkę czatu która każdą wiadomość zapisuje do bazy danych by potem mieć dostęp do historii rozmowy, sytuacja jak wyżej
-równoległe pobieranie danych z kilku stron, tutaj mam akurat scrapper który przeszukuje kilka serwisów i agreguje wyniki. Mogę z każdego takiego scrappera zrobić osobny mikroserwis i wyniki wrzucać na kolejkę

Poza tym, zapewne niebawem wrócę z płaczem na forum że coś mi nie działa, ale na prostym przykładzie Spring Cloud Streams + Kafka wygląda bardzo przyjemnie :D

Znam wiele zespołów które poszły w mikroserwisy ze względu na mode a potem miały problemy bo co chwile jenkins się wywalał, jak były zmiany to też kubernetesa i dockera trzeba było stawiać, wiecej czasu poświęcali na infrastrukturę niż programowanie. Zespół 6 osobowy. Mikroserwisy powstały w innym celu. Np. jak jeden zespół pracuj w PL a drugi gdzie indziej, lub innym piętrze i pracują nad dwoma niezależnymi modułami od siebie. Poza tym w Javie 9 masz moduły ale gro osób nie umie z nich korzystać, nie mówiąc już o braku podstawowej znajomości architektury.

Posłuchaj sobie tego Pana

Nie no ja to rozumiem, nie zawsze mikroserwisy mają zastosowanie, ale to nie jest sytuacja typu "słyszałem, że to fajne, od teraz tylko tak piszę kod". Zacząłem pracę w nowej firmie, w której korzystają z takiego stosu technologicznego i mam czas na sucho się nauczyć / przypomnieć sobie technologię które dostałem od TLa, wśród nich jest między innymi Kafka + mikroserwisy Przecież nie napiszę teraz "słuchaj, nie mam jeszcze nawet wjazdu do repozytorium kodu, ale zobacz ten filmik bo mikroserwisy to nie są jednak takie fajne, może przerobimy wszystko na monolit?".

AngryProgrammer napisał(a):

Mam póki co bardzo mało informacji, na dniach się to powinno rozjaśnic. Generalnie język to Java, do samych mikroserwisów używany jest Spring Cloud + Kafka / REST do komunikacji.

Podoba mi się takie podejście. Nie do końca wiadomo co robimy, ale będzie Java, Spring, Cloung, Kafka i mikroserwisy. Po prostu czysta architektura - nieskażona wymaganiami. Zawsze wiedziałem, że Wujek Bob źle zrozumiał tą koncepcję.

Jak jest was 100 lub więcej to w zasadzie mikroswerisy mają sens, wtedy część zajmie się infrastrukturą:
https://martinfowler.com/bliki/MicroservicePrerequisites.html

W innym przypadku najlepiej nie przejmujcie się terminem i tylko mówcie, że robicie mikroswerisy - będzie dobrze.

Mam wrażenie, że niektórzy nie do końca zrozumieli sedno problemu, tylko na siłę próbują wbić szpile, że ktoś korzysta z technologii bo jest modna, a nie dlatego że potrzebuje. Postaram się więc w punktach, w miarę prosto.

1. Mamy pandemie koronawirusa, kto może to pracuje zdalnie
2. Powoduje to problem dla większych korporacji (mowa o firmie która ma na świecie dziesiątki tysięcy pracowników), żeby nagle wszystkim umożliwić pracę zdalną
3. W efekcie, nowo zatrudniony pracownik jest najmniej priorytetowy by dostać konto, dostęp do repo, jiry, itp, bo się okazuje że zdalny dostęp potrzebują ludzie którzy pracują w firmie x lat (a firma to nie tylko dział IT).
4. Dodatkowo temat wdrożenia nowych online nie jest dopięty na ostatni guzik, jak z resztą wiele rzeczy w obecnym czasie. Tak więc taki pracownik dostaję tymczasowe zadanie - odśwież we własnym zakresie wiedzę z technologi X, Y, Z, na dniach dostaniesz więcej konkretów
5. Ów pracownik siada, pisze na 4programmers z prośbą o radę, że chciałby poćwiczyć technologię X bo będzie to robić w pracy
6. Dostaję odpowiedź, ze jego organizacja nie jest gotowa na technologię X i w ogóle nie powinien się za to zabierać bo to mu przyniesie więcej szkody niż pożytku

Logiczne.

@jarekr000000 zauważ ze OP napisał że ON ma mało informacji o projekcie, bo dopiero zaczął, a nie że generalnie nic nie wiadomo. Myśle że reszta zespołu wie co i jak chca robić i stąd lista wybranych technologii ;)

Jeśli chodzi o mikroserwisy to warto korzystać w takich sytuacjach jak:

• częste zmiany/continuous delivery, deploye różnych elementów wiele razy dziennie
• potrzeba skalowania
• wyciąganie jakiejś funkcjonalności, która jest wspólna dla wielu innych (pod)systemów
• duży rozmiar systemu

Jeśli chodzi o Kafkę i asynchroniczne przetwarzanie, to może np. napisz jakiś centralny system logowania zdarzeń? Zrób serwis służący do zbierania eventów i wrzucania ich na Kafke i zrób drugi który z tej Kafki czyta i gdzieśtam indeksuje/zapisuje. Oba można wygodnie przeskalować horyzontalnie w razie potrzeby, Kafka załatwia problem z jakimś nagłym dużym obciążeniem, po prostu zrobi się backlog który z czasem się rozładuje.

Jak znam życie to reszta zespołu ma swoje ulubione technologie, zobaczyła jakąś prezentację, potrzebuje wpisów do CV.

Z mojej perspektywy najważniejszym powodem do mikroserwisów jest: dużo ludzi (dużo zespołów).

Ale o co te całe halo? Zazdrościcie koledze stacku technologicznego, czy o co chodzi? xD skąd wiecie, dlaczego taki wybór technologii? Brzmi jak „jeździ Audi?? Na pewno ukradł!”

mike335 napisał(a):

Mikroserwisy powstały w innym celu. Np. jak jeden zespół pracuj w PL a drugi gdzie indziej, lub innym piętrze i pracują nad dwoma niezależnymi modułami od siebie.

Rozmiar ani lokalizacja zespołów nie mają żadnego związku z mikroserwisami.

Mikroserwisy = rozproszony system, z okazji epidemii kurs Udi Dahana - Advanced Distributed Systems Design jest dostępny do obejrzenia za darmo do końca kwietnia. Także zacząłbym od tego, bo problemy z którymi trzeba się zmierzyć są takie same bez względu na używaną technologię.

Co sądzicie o takiej książce, ktoś czytał?

spis treści: https://www.oreilly.com/library/view/java-ee-8/9781788475143/

Julian_ napisał(a):

Co sądzicie o takiej książce, ktoś czytał?

spis treści: https://www.oreilly.com/library/view/java-ee-8/9781788475143/

Jak Java EE to znaczy że jest tam wszystko co najgorsze