Wątek przeniesiony 2019-03-14 11:11 z przez somekind.

Mikroszaleństwo?

Odpowiedz Nowy wątek
2019-03-07 21:33
6

Czy też spotykacie się z sytuacjami, że deweloperzy zamiast pisać kod i rozwiązywać problemy biznesowe zaczynają pracę od d**y strony i wszystko ładują w mikroserwis?
Przeciwnikiem mikroserwisów nie jestem, pracowałem nad rozproszoną aplikację na produkcji, ale już któryś raz widzę fanatyczne podejście do tematu, zachwyt jak to będzie super działać, skalować.
Parę tygodni później okazuje się, że do sklejenia czegokolwiek w jeden kawałek trzeba mnóstwo ticketów, pozwoleń, dostępów a nawet prosty hello world nie działa :)
Może jestem stary i po prostu nieogarniam tematu, a może architekci są zbyt słabi w te klocki i w miare biegły programista bez trudu przerzuci go w dyskusji argumentami?

w jakie klocki? marketingowe chyba ;) - Miang 2019-03-07 22:05
Tak jestes stary - Arek00 2019-03-07 22:20

Pozostało 580 znaków

2019-03-07 21:45
0

Mi się jeszcze nie zdarzyło pracować przy projekcie, w którym wykorzystane byłyby mikroserwisy, więc chyba nie jestem tró programistą. Rozważane owszem, były, ale i to raczej z myślą o ominięciu jakichś problemów projektowych, choć i tak koniec końców znalazły się prostsze i bardziej eleganckie rozwiązania, niż pakowanie czegoś w osobny serwis by uciec od problemu.

Ale to może dlatego, że jeszcze nie zdarzyło mi się robić czegoś, co docelowo miałoby używać więcej niż kilka osób naraz, więc skalowalność jest tak potrzebna, jak lewarek i koło zapasowe w samolocie.


Prosząc o pomoc w wiadomości prywatnej odbierasz sobie szansę na otrzymanie pomocy od kogoś bardziej kompetentnego :)
edytowany 2x, ostatnio: superdurszlak, 2019-03-07 21:46

Pozostało 580 znaków

2019-03-07 22:08
1

To jest często problem widzimisia architektów, którzy to twierdzą, że coś będzie super hiper a potem problem bo zamiast napisać coś w 100h trzeba na to poświęcić 300h i się okazuje, że budżet się nie spina. Miałem przykład gdzie mój pomysł zakładał zrobienie pewnej rzeczy w 2 tygodnie, pomysł architekta zakładał przerobienie 1/3 aplikacji by wdrożyć tę samą funkcję, efekt taki, że całość zajęła 3 miesiące 2 osobom, zamiast 2 tygodni jednej :D A szefostwo wkurzone oczywiście na programistów, "czemu tak długo".

Pozostało 580 znaków

2019-03-07 22:27
4

title

Pracowałem w firmie, w której było kilkaset naprawdę mikroserwisów, na jakieś ~400 developerów podzielonych na kilkadziesiąt zespołów. Działało to nadzwyczaj sprawnie. Była to już 4'rta iteracja ich platformy na przestrzeni dwóch dekad, gdzie pierwsze 2 były monolitami, a 3'cia SOA, ale niekoniecznie micro.

Ale jak mamy team kilku-kilkunasto osobowy i projekt który nigdy jeszcze produkcji i klienta nie widział to co my wiemy o jego prawidłowej architekturze i skalowaniu.

edytowany 1x, ostatnio: Lukxxx, 2019-03-07 22:31

Pozostało 580 znaków

2019-03-07 22:27
5

Pracuję obecnie przy dużym systemie, napisaliśmy go od zera. System oparty o mikroserwisy i event sourcing, stosujemy również DDD. Czy warto? Warto. Czy takie rozwiązanie ma duże korzyści? Jak najbardziej. Czy ma wady? Oczywiście.

Fakt, w dzisiejszych czasach mikroserwisy to nowy buzzword. Jest sporo osób dla których mikroserwisy to jakiś złoty środek- również tutaj na forum. Z jakim problemem architektonicznym się nie zderzyć to zaproponują mikroserwisy. Dla takich osób słowo monolit jest synonimem wielkiego molocha, kodu spaghetti itp. Jest to również stereotyp, ale jak każdy stereotyp skądś się wziął. Dla mnie to bzdura. Niestety nadal jest dużo naprawdę złych monolitów, szczególnie w starych aplikacjach które stale trzeba utrzymywać. Jednakże monolit może być dobrze napisany, stosować odpowiednią architekturę i świetnie się sprawdzać. Nie należy traktować mikroserwisów jako jedynego słusznego czy też lepszego rozwiązania. Powinno się je stosować tam gdzie mają sens, a więc należy rozważyć wszelkie za i przeciw. To nie jest naturalny etap rozwoju monolitów, a opcjonalna droga rozwoju systemu.

Tak więc mikroserwisy faktycznie są dziś nadmiernie proponowane/używane, ale nie zmienia to faktu że tam gdzie naprawdę warto je stosować są świetnym rozwiązaniem.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
edytowany 2x, ostatnio: Aventus, 2019-03-08 08:02
Dzięki, poprawione :) - Aventus 2019-03-08 08:02

Pozostało 580 znaków

2019-03-07 23:40
14

Pracuję w firmie gdzie panuje kult mikroserwisów. Sporo też rozmawiam na różnych meetup-ach i konferencjach.

Moje doświadczenia na szybko:

Na plus:

  • rozwiązują problem wielkiej skali. Jak jesteś Netflixem, Amazonem to jedyna droga.
  • rozwiązują problem wielkich i bolesnych wdrożeń

Na minus:

  • Ludzie myślą, że mikroserwis powinien być mały, gdzie tak na prawdę, to zwykle gruba i bogata aplikacja zarządzająca jedną domeną biznesową,
  • Ludzie źle wydzielają granice pomiędzy mikroserwisami np. tnąc je ze względu technicznego. (tutaj mikroserwis do pdfów, a tutaj do resta). Błędem jest też ciąć niepodzielne domeny, gdzie mamy dużo zalezności i komunikacji. Wówczas, cała ta komunikacja jest po reście i kolejkach co jest wolne, czasochłonne i generuje błędy.
  • Ludzie wdrażają mikroserwisy tam gdzie nie ma odpowiedniej kultury organizacyjnej / DevOps (Słynne "you must be this tall to use microservices"). Tzn. trzeba mieć niezależne zespoły zorientowane produktowo. Zautomatyzowane pipeline CI/CD, infrastructure as a code etc.
  • Ludzie w architekturze mikroserwisów zapominają o transakcjach i spójności danych. Myśląc, że mikroserwisy są łatwe, zapominają o błędach sieci etc.
  • Mikroserwisy spowalniają development na wczesnym etapie, wtedy gdy potrzebujemy szybkiego feedbacku i nie wiemy czy projekt wypali, oraz gdy biznes oczekuje szybkiej wartości dodanej.

Uważam, że mikroserwisy powinny być efektem podziału udanego i działającego systemu na mniejsze, a nie architekturą od początku.


"Gdy się nie wie, co się robi, to się dzieją takie rzeczy, że się nie wie, co się dzieje"


edytowany 7x, ostatnio: nie100sowny, 2019-03-07 23:50
Ostatnie zdanie jak dla mnie, samo sedno. Większość nie zauważa że udane wdrożenia mikroserwisów, przebiegały poprzez skruszenie istniejących poprawnych rozwiązań. Problem siedzi w przepaści między wiedzą domeny biznesowej oraz infrastrukturalnej. Jeśli tu są (a nie doświadczyłem by nie było) "niedoskonałości", mikroserwis będzie strzałem w stopę. - Mokrowski 2019-03-08 09:48

Pozostało 580 znaków

2019-03-07 23:47
0
Aventus napisał(a):

Pracuję obecnie przy dużym systemie, napisaliśmy go od zera. System oparty o mikroserwisy i event sourcing, stosujemy również DDD. Czy warto? Warto. Czy takie rozwiązanie ma duże korzyści? Jak najbardziej. Czy ma wady? Oczywiście.

Fakt, w dzisiejszych czasach mikroserwisy to nowy buzzword. Jest sporo osób dla których mikroserwisy to jakiś złoty środek- również tutaj na forum. Z jakim problemem architektonicznym się nie zdeżyć to zaproponują mikroserwisy. Dla takich osób słowo monolit jest synonimem wielkiego molocha, kodu spaghetti itp. Jest to również stereotyp, ale jak każdy stereotyp skądś się wziął. Dla mnie to bzdura. Niestety nadal jest dużo naprawdę złych monolitów, szczególnie w starych aplikacjach które stale trzeba utrzymywać. Jednakże monolit może być dobrze napisany, stosować odpowiednią architekturę i świetnie się sprawdzać. Nie należy traktować mikroserwisów jako jedynego słusznego czy też lepszego rozwiązania. Powinno się je stosować tam gdzie mają sens, a więc należy rozważyć wszelkie za i przeciw. To nie jest naturalny etap rozwoju monolitów, a opcjonalna droga rozwoju systemu.

Tak więc mikroserwisy faktycznie są dziś nadmiernie proponowane/używane, ale nie zmienia to faktu że tam gdzie naprawdę warto je stosować są świetnym rozwiązaniem.

@Aventus Z ciekawości. Używacie w tym waszym systemie opartym o event sourcing dat lub UUIDów?


"Gdy się nie wie, co się robi, to się dzieją takie rzeczy, że się nie wie, co się dzieje"


edytowany 2x, ostatnio: nie100sowny, 2019-03-07 23:50
Używamy, jak najbardziej. Skąd takie pytanie? - Aventus 2019-03-08 08:14
Ok źle się wyraziłem. Inaczej. Jak sobie radzicie z re obliczaniem stanu eventów, gdy np. korzystasz za API, które zwraca coś ulotnego typu pogodę. oraz jak sobie radzicie z odgrywaniem eventów, gdy połowa eventów w bazie tyczy się aplikacji w wersji 1.0.0, a obecna wersja to 3.0.0. Czy w ogóle wasz event sourcing pozwala wam re obliczyć stan od początku? - nie100sowny 2019-03-08 12:05
Nie rozumiem pierwszej części pytania. Co do drugiego to oczywiście, cały sens event sourcingu polega na tym żeby móc odbudować stan na podstawie eventów. W przeciwnym razie to nie event sourcing ;) Co do innych wersji eventów, to bardzo uważamy z wprowadzaniem zmian do istniejących eventów (w sensie klas). na razie jeszcze nie musieliśmy wprowadzać żadnych "breaking changes", ale zdajemy sobie sprawę że kiedyś ten dzień może nadejść i będzie trzeba opracować jakąś strategię. - Aventus 2019-03-08 12:34
Ogólnie trzeba pamiętać że klasy reprezentujące eventy są kluczowymi elementami systemu i do jakichkolwiek zmian trzeba podchodzić uważnie. Zamiast dodawać nowa właściwość "bo potrzebuję" warto się zastanowić czy nie da się tej informacji wyciągnąć skądś indziej, czy np. poprzedzajacy event skorelowany w jednym procesie biznesowym nie posiada już tych informacji itp. Eventy staramy się mieć na tyle małe na ile się da, przesyłając tylko absolutne minimum wymaganych informacji. - Aventus 2019-03-08 12:42

Pozostało 580 znaków

2019-03-08 01:04
1

To co @nie100sowny napisal, nazwa jest fatalna i mylaca i mikroserwisy nie powinny byc takie mikro jak sie wydaje. Rozmawialem dzisiaj o tym z ludzmi po meetupie. Dzielenie transakcji to tez zlo w czystej postaci, chyba ze naprawde sie nie da inaczej.

Moze jakby to makroserwisami nazwac ?

Z drugiej strony pod katem pracy, jak mamy jakas automatyzacje Devops to czy to taka wielka roznica czy dodajemy nowe Dockery czy np. nowe VM na AWS? (poza roznica w rachunku)

Edge robil i Jarek Palka opowiadal o pakiecie concurrency z Javy. - WhiteLightning 2019-03-08 02:18
Są już tacy co proponują używanie nanoserwisów ;) - Aventus 2019-03-08 08:05

Pozostało 580 znaków

2019-03-08 08:23
1

Czy też spotykacie się z sytuacjami, że deweloperzy zamiast pisać kod i rozwiązywać problemy biznesowe zaczynają pracę od d**y strony i wszystko ładują w mikroserwis?

Wersja frontendowa:
"Akcja na twarz i pchasz"
Czyli pakowanie w Reduxa wszystkiego, łącznie z jakimiś lokalnymi stanami GUI, których pakowanie do Reduxa spowalnia tylko i komplikuje aplikację.

Na dodatek, żeby upakować wszystko do Reduxa, okazuje się, że jeden ficzer przestaje być całością, a zaczyna być niepotrzebniony rozdrobniony po 5 różnych plikach (z naciskiem na niepotrzebnie. Czasem podział ficzera na wiele plików ma oczywiście sens, ale w przypadku używania Reduxa to taki overengineering, który nic nie daje - gdzie coś, co reprezentuje w sumie jedną wartość liczbową czy jednego stringa, musi mieć własną akcję, własnego actiona creatora, reducera, selektora...).

Obstawiam, że kult Reduxa na froncie to taki odpowiednik kultu mikroserwisów na backendzie.


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 2x, ostatnio: LukeJL, 2019-03-08 08:25
W sumie racja :) lubię ten wzorzec, ale ciężko jest pisać zwięźle, zwłaszcza gdy chcemy mieć "standardy" nazwnictwa, przez które okazuje się, że aby trzymać stan checkbox-a potrzebujemy reducer.js, actions.js, actionTypes.js, selectors.js i może jeszcze testy do tego :P - kelog 2019-03-08 18:14

Pozostało 580 znaków

2019-03-08 08:38
1

@nie100sowny:

Ludzie myślą, że mikroserwis powinien być mały, gdzie tak na prawdę, to zwykle gruba i bogata aplikacja zarządzająca jedną domeną biznesową.

Nie chcę się wdawać w dywagacje, ale to zdanie jest trochę błędne. Tobie chyba chodzi o to że mikroserwis z definicji nie powinien być taki "mikro". Ludzie akurat słusznie myślą że mikroserwis powinien być mały, bo taka jest ogólno przyjęta definicja takiego serwisu. Jeśli każdy "mikroserwis" ma być duża aplikacją samą w sobie, to mamy architekturę opartą o serwisy (SOA), czyli to czym mikroserwisy w założeniu mają nie być.

No chyba że mamy różne definicje "grubej i bogatej" aplikacji. Ale słowo "gruba" w tym kontekście jednak sugeruje coś znacznie większego niż mikroserwis w ogólnie przyjętej definicji powinien być.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
"Service-oriented architecture composed of loosely coupled elements that have bounded contexts" oraz "Microservices are a loosely coupled Service-Oriented Architecture (SOA) with bounded contexts." - tego samego autora - Adrian Cockcroft . Nie widze problemu z duża aplikacją dopoki jest bounded context i spojna domena biznesowa. Wielkosc serwisu nie jest istotna. - karsa 2019-03-10 13:34
Przeczytaj dalszą dyskusję. Owszem, mikroserwisy to jest SOA ale konkretnie odświeżona forma. To nie jest SOA w zrozumieniu- kilka dużych serwisów komunikujących się ze sobą. - Aventus 2019-03-10 15:37

Pozostało 580 znaków

2019-03-08 09:04
1

@Aventus. Świetnie to zobrazował kiedyś Jakub Kubryński, pytając publiczność ile mikroserwis powinien mieć orientacyjnie linii kodu. Większość twierdziła, że 1000 lub 10000.

To teraz przeciętny system enterprise to około 500 000 linii kodu. Jeśli go podzielimy na 50 serwisów, a takich systemów firma ma kilka to trzeba armii inżynierów.

Znam zespoły co mają nowy produkt, ledwo weszli na prod i już mają 40 serwisów. To jest bardzo popularne niestety.

EDIT1: I tak, wiem że LOC to dziadowska miara czegokolwiek. Ale na potrzeby rozmowy o wielkości ujdzie.


"Gdy się nie wie, co się robi, to się dzieją takie rzeczy, że się nie wie, co się dzieje"


edytowany 1x, ostatnio: nie100sowny, 2019-03-08 11:24

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0