[numeryczny_mikolaj12]

Macie jakieś fajne źródła do ogarnięcia podstaw mikroserwisów, z czym to się je, jak działają etc. najlepiej na przykładzie jakiejś apki w .Net Core.

#aspnet #dotnet #csharp #programowanie

[Init0]

@numeryczny_mikolaj12: a to? https://dotnet.microsoft.com/learn/aspnet/microservices-architecture
microsoft ma bardzo rozwiniete te ich dokumentacje wiec nie wiem w czym problem ( ͡° ͜ʖ ͡°)

[mirasKo-Kalwario]

@numeryczny_mikolaj12: 12 factor app od tego możesz zacząć

[zibizz1]

@numeryczny_mikolaj12: spetz dnc-dshop w Googlach

[MQs]

@numeryczny_mikolaj12: Nie wiem czy w przypadku mikroserwisów w ogóle istnieje coś takiego jak podstawy (chyba, że chodzi ci o teoretyczne koncepcje). To jest skomplikowany system już z założenia, a zrobisz źle to będzie trudniej wyprostować niż źle zaprojektowany monolit.

Wszystkie ważne linki od @spetz (+fajna prezentacja) tutaj

[spetz]

@MQs: dzięki!
@numeryczny_mikolaj12: nasz darmowy kurs, przykładowe projekty (kurs bazuje na DShop, z najprostszych NPost, a z najnowszych i najładniejszych Pacco). Dodatkowo szykujemy bombę na polskim rynku - kurs online mikroserwisy.net bazując na doświadczeniu zdobytym podczas szkoleń stacjonarnych ale to w niedalekiej przyszłości ( ͡° ͜ʖ ͡°).

[Yahoo_]

@MQs skąd ja to znam :p. Większość projektów, które sprzedaje się na rekrutacji jako mikroserwisy to nic innego jak rozproszone monolity :p.

[spetz]

@Yahoo_: dlatego jak prowadzę szkolenia z mikroserwisów, to paradoksalnie w tym celu, aby uświadomić uczestników jak jest to złożone, i że najlepiej zostać przy modularnym monolicie :).
@zibizz1: thx!

[zibizz1]

@Yahoo_: no bo po co robić mikroserwisy? Chyba tylko po to żeby sobie wygenerować więcej pracy. Narzut na development jest zbyt duży.
@spetz jakie mamy zalety względem monolitu?

[spetz]

@zibizz1: jak zrobisz dobrze to przede wszystkim autonomiczność (dedykowane osoby per usługa, osobne repozytoria, CI & CD pipeline, łatwo usunąć/przepisać mikroserwisy na nowy), asymetryczna skalowalność (możesz najbardziej wykorzystywaną usługę skalować horyzontalnie niezależnie od reszty) oraz nie ma SPOF jak w przypadku monolitu (część systemu nadal działa, nawet gdy pewne mikroserwisy padły) - jak to faktycznie zrobić dobrze to już inna historia ( ͡° ͜ʖ ͡°).

[zibizz1]

@spetz:
autonomiczność - co za problem mieć osobny serwis/ zestaw kontrolerów w aplikacji którym może się zajmować dana osoba. Może to być w osobnym projekcie/repozytorium. Łatwo można cały taki moduł odłączyć, podmienić, usunąć. Wydzielając do osobnego projektu łatwiej utrzymać odpowiedni poziom separacji.

asymetryczna skalowalność- a co przeszkadza żeby skalować cała aplikację? Oszczędność zasobów na poziomie aplikacji jest niewielka w mikrosewisach a narzut na komunikację pomiędzy znaczący. Po stronie bazy taka asymetria

[spetz]

@zibizz1:

autonomiczność - wydzielając usługi do osobnych repozytoriów masz 100% pewność, że nikt przypadkiem nie doda referencji tam gdzie nie powinien, każdy projekt może mieć swój własny cykl życia, prościej zadbać o architekturę, a jesli jest potrzeba to i można go napisać w innej technologii. Zazwyczaj jest też go łatwiej zaorać i napisać od nowa.

asymetryczna skalowalność - niestety ale dużo przeszkadza - możesz sobie wyobrazić, że posiadasz np. obsługę żądania

[zibizz1]

@spetz: thx, tym razem dobrze wskazane przewagi i ostatnie zdanie dobrze wpasowuje się w moje poglądy na ten temat

[spetz]

@zibizz1 no i git, widzę, że jesteśmy podobnego zdania :).

[bacteria]

@spetz: @zibizz1: no i komunikacja miedzy mikroserwisami w wielu przypadkach bywa kluczowa. Na YB na kanale NDC Conferences jest godzinny filmik ktory opowiada historię jakiejs firmy, ktora zapomniala doliczyc koszt komunikacji przez zwykle API miedzy serwisami i w dniu kiedy zaczeli testowac okazalo sie ze maja jakis astronomiczny delay :p Gdyby kogos interesowal glebiej temat to warto obczaic temat protokołu GRPC zbudowanego na HTTP2.

[spetz]

@bacteria tak, gdziekolwiek wchodzi komunikacja sieciowa, topojawia się masa wyzwań, liczymy się z CAP mając zawsze na uwadze partycjonowanie sieci itd. Odnośnie gRPC to bardzo fajna sprawa, coraz większa popularność i w sumie cała komunikacja w ostatnio hypeowanym service mesh się na nim opiera :).