[igor0906]

Kiedy pracowałem w PKO to cały zespół pracował nad tym aby zamienić monolit na mikroserwisy.

Tam gdzie obecnie pracuje, koledzy właśnie skończyli robić coś dokładnie odwrotnego.

I tak się żyje na tej wsi. Ludzie podejmują decyzję nie w oparciu o fakty lecz o modę

nikt się nawet przez 10s nie zastanowił, czy takie mikroserwisy są nam potrzebne czy nie. jak się ma 30 milionów użytkowników to pewnie, ale myślę mieliśmy może 10k bo to aplikacja dla innych firm xD

#programowanie #programista15k

[NoName4891]

@igor0906: i każdy ma co robić na lata, źle ci?

[igor0906]

@NoName4891 i tak się kręcimy w tych korporacjach. może 20% pracy jest coś warta reszta to szkoda gadać ( ͡º ͜ʖ͡º)

[NoName4891]

@igor0906: i tak to życie upływa...bezsensownie, szybko

[Krolik]

@igor0906: łatwiej jest wziąć 50 studentów i zrobić nimi mikroserwisy pracujące na 100 serwerach zarządzanych przez kilku devopsów niż wziąć jednego specjalistę, który napisze oprogramowanie optymalnie które by działało na jednym serwerze (plus drugi jako failover) przez wiele lat bezawaryjnie.

[nad__czlowiek]

@igor0906: z przechodzeniem z monolitu na mikroserwisy to zawsze wychodzi tak, że z wielkiego monolitu zamiast mikroserwisów robi się makroserwisy czyli mirkoserwisy w formie małych monolitów komunikujących między sobą xD

Mikroserwisy przeważnie udają się tylko wtedy, gdy projekt startuje się od zera i poświęci trochę czasu na wymyślenie sensownej architektury. W przypadku przechodzenia z monolitu na mikroserwisy często to po prostu jedno olbrzymie spagetti zostaje podzielone na mniejsze spagetti ( ͡

[grzesio1912]

Uczestniczyłem kiedyś w takim przepisywaniu. Aplikacja mocno bazodanowa, dużo logiki na bazie.
Przyszła firma konsultingowa i zaczęli przepisywać. Pierwszym etapem mialobyc zostawienie starej bazy i pisanie na niej mikroserwisow. I tak powstawały mikroserwisow niby niezależne. Ale np takie filtry to czesały po całym systemie. Bo tak było w monolicie bo to było wygodne i użyteczne dla biznesu. O tak zostało w mikro tylko gorzej. Nikt nie pomyślał żeby zrobić od razu porządne

[WaveCreator]

@nad__czlowiek: Problem polega na tym, że aby taki proces przeszedł sprawnie i koszernie, to ktoś z biznesowych ludków na "górze" musiałby podjąć męską decyzję, że na X czasu zawieszamy rozwój nowych rzeczy i tylko utrzymujemy to co mamy dopóki core nie zostanie wyniesiony do mikroserwisów.

Oczywiście nikt tego nie zrobi, bo nikt nie ma ochoty iść do zarządu i powiedzieć "słuchajcie, przestajemy rozwijać produkt na pół roku bo programiści chcą cośtam

[cebulowy_krezus]

@Krolik: Możesz mieć X instancji jednego monolitu i też będziesz miał bezawaryjność. Możesz pójść dalej i pogrupować instancje monolitu wg zastosowań np:
10 podów będzie działało jako obsługa zadań z kolejki asynchronicznej
5 podów odpowiada za raporty
10 podów odpowiada za całą resztę aplikacji

Odpada wtedy przepisywanie spaghetti w kodzie na spaghetti wywołań endpointów. I w efekcie otrzymanie jeszcze gorszego spaghetti, którego nie dą się normalnie debugować, ale za to jest

[cebulowy_krezus]

Pierwszym etapem mialobyc zostawienie starej bazy i pisanie na niej mikroserwisow

@grzesio1912: Ale to już nie są mikroserwisy wtedy. Ja bym to nazwał SOA. Tylko wtedy już nie jest fajnie i modnie, bo SOA jest znane od dawna

[cebulowy_krezus]

I tak powstaje potwór Frankensteina - ale osobiście i tak wolę mikroserwisy niż monolit

@WaveCreator: Dzięki temu otrzymuje się wady monolitu, które za to w pełni kompensują wady mikroserwisów :)

[Saly]

ść. Możesz pójść dalej i pogrupować instancje monolitu wg zastosowań np:

@cebulowy_krezus: pracuję z czymś takim tj. mam serwisy korzystające z jednej bazy kodowej jak np. serwis do obsługi kolejek, główny serwis albo serwis na częśc kodu, która jest problematyczna. Generalnie jest ok, ale potrzeba dużego ogarnięcia, żeby nie zrobić syfu np. nieskordynowane pisanie po tej samej bazie. Z drugiej strony nawet najgorszy monolit jest lepszy, bo przynajmniej da się go

[Krolik]

@cebulowy_krezus: oczywiście. Ale piję do tego, że w większości przypadków, jeśli nie jesteś googlem ani FB, jeden serwer jest w stanie fizycznie ogarnąć cały ruch z dużym zapasem i w ogóle nie potrzebujesz skalowania. Firmy idą często w skalowanie bo swoją nieudolnością zabijają 99% wydajności sprzętu i przez to wydaje im się że potrzebują więcej serwerów zamiast zoptymalizować oprogramowanie, co zwykle jest o wiele tańsze niż utrzymywanie przerośniętej architektury na mikroserwisach.

[j.....2]

@igor0906: ważne że płacą 15k, everything else is secondary