DevTalk#20 – O mikroserwisach z Michałem Francem

22

michal-francWakacje, wakacje i po wakacjach. I bardzo dobrze, ile można, c’nie?

Po wakacyjnej przerwie powracamy, zamaszyście, pomału i usłużnie. Ale suchy rebus! Mału -> mikru -> mikro. Usłużnie -> serwisowo -> service. Czyli: po wakacyjnej przerwie powracamy, zamaszyście, z mikroserwisami! Towarzyszy mi Michał Franc, który z dalekiego jUKeja wskoczył mi na Skype’a. Michał bloguje na http://www.mfranc.com, przemawia oraz jest jednym z organizatorów konferencji dotnetconf.pl. Na Twitterze możecie go stalkować pod @francmichal.

Zarówno Michał jak i ja tworzymy/utrzymujemy systemy oparte o “architekturę mikroserwisów”. Dzisiejsza rozmowa to wymiana doświadczeń i próba zebrania zarówno zalet jak i wad tego rozwiązania. Jeżeli nie wiesz co to są mikroserwisy – z tego odcinka się dowiesz. Jeśli wiesz co to jest, ale nie było okazji do wypróbowania w praktyce – otrzymasz “mikroserwisy w pigułce”. A jeśli tworzysz mikroserwisy: być może dowiesz się czegoś nowego? W każdym razie: daj nam znać w komentarzach!


Ważne adresy:

Linki:


Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

22 Comments

  1. Pingback: dotnetomaniak.pl

  2. Fajny odcinek na trendy temat. Faktycznie widać, że microservisy pomagają w utrzymaniu appki, powodują, że musisz podejść do niej zdrowo (automatyzacja, patterny, messaging no i wypadałoby clean code).
    Fajnie pokazany podział u Michała, ja robię to, to i to, a reszta musi spełniac jakiś interfejs, z drugiej strony mnie bardziej się podoba podejście jak u Macieja – wszyscy wiedzą wszystko (nie do ogarnięcia w ogromnym środowisku).

    Rozumiem, że w obu przypadkach była to mądra przemyślana i słuszna zapewne bardziej lub mniej decyzja (niektórzy wtapiają z microserwisami :) ). Czy jakieś były problemy od strony biznesu, czy nie mili nic do powiedzenia ?

  3. O microserwisach obejrzałem chyba wszystkie możliwe video na sieci. Wiele osób mówi o zespołach pracujących nad projektem rzędu kilku/kilkunastu osób. Ja cały czas zachodzę w głowę czy rozbicie dużego monolita na microserwisy w zespole 2 (może 3) osobowym ma szanse na powodzenie.

  4. “psake is pronounced sake – as in Japanese rice wine. It does NOT rhyme with make, bake, or rake.” ;)

  5. @pawelek
    Biznes zawsze ma do powiedzenia i to kwestie biznesowe sa zawsze najwazniejsze przy podejmowaniu decyzji tego typu. Nim ruszylismy pelna para w microserwisy to jeden zespol eksperymentowal z nimi i badal czy nam sie to oplaci. Z punktu widzenia biznesu widza plusy i minusy. Plus release ktory kiedys byl ogromny i trzeba bylo na niego czekac 2 tyg robimy teraz w 1-2h. ( do tego samego mozna bylo dojsc teoretycznie bez mikroserwisow ale jest to dobry argument :) ) Time to market jest duzym zyskiem i mozna szybko iterowac i testowac rozne zmiany. Minusem glownym dla bizesu byl lekki letarg i zmniejszona wydajnosc ( przez pare miesiecy ) + koszty AWS ktorych nie mozna ‘pominac’ :) U mnie caly proces nadzorowany byl przez CTO i 2 architektow, sponsorowany byl przez CIO. Bez tego wsparcia i wiary ze to sie uda oraz przyniesie zyski, nic by z tego nie wyszlo.

    @dario
    U mnie sa zespoly wlasnie 2-3 osobowe a niektore microserwisy nie maja jasno okreslonego wlasciciela i kilka zespolow go utrzymuje.. Inwestycja jest spora jest masa problemow ale z tego co obserwuje to zwrocila sie. Mysle ze warto zaczac od sprobowania i napisania czegos nowego w takim podejsciu, nie trzeba tez rzucac sie od razu na gleboka wode.

  6. Łukasz Woźniczka on

    Ja bym jeszcze dodał swaggera do dokumentowania usług restowych bardzo dobrze działa ze spring mvc oraz JAX-RS

  7. @Michał, podczas rozmowy wspominaliście o dashboardzie. Czy udało Ci się już ustalić “na czym” został on zrobiony?

  8. @pawelek,
    U nas to była kwestia spełnienia wymagań biznesowych – mikroserwisy pomogły zrealizować scenariusz “niektóre zamówienia traktujemy inaczej” :)

  9. @dario,
    My rozpoczęliśmy projekt w mikroserwisach w dwie osoby, teraz pracują nad nim trzy. Każdy wie co się gdzie dzieje. W większym projekcie byłoby to jeszcze ciekawsze bo wtedy trzeba by było zrealizować całość tak jak mówił Michał – uznawać kontrakt/API za święte nawet mimo tego, że jest to aplikacja wewnętrzna. Ciekawe doświadczenie.
    Kluczem jest “dojrzałość” organizacyjna. Bez automatyzacji nie da się tego zrobić nie mając dedykowanego działu “wdrożeniowego”.

  10. Grzegorz on

    No ciekawy podcast.
    Mam frajde brac udzial w projekcie ktory oparty jest na mikroserwisach i nie ukrywam ze umiejetnosc wydzeielenia domeny dla serwisu jest czyms waznym, gdyz ma wplyw na dlszy rozwoj. W naszym projekcie kierujemy sie zasada eliminowania zaleznosci, wiec staramy sie aby serwisy nie musialy miec dostep do bazy.
    Dzieki za pomysl o bezpieczniku – jest to fajna sprawa i mysle ze szybko wejdzie do naszego kodu!
    Pozdrawiam
    Grzegorz

  11. Przemawia do mnie podejście MFowlera MonolithFirst. Zauważyłem, że jak pracuję nad nową domeną (najlepiej na suporcie) to dopiero po 2-3 latach przychodzi “oświecenie” jak poszczególne fragmenty “pasują” do siebie i co mówi klient jest prawdą a co tylko półprawdą, albo g..prawdą. Klient to zwykle u mnie grupa osób, kóra każda z innej perspektywy widzi system. Więc zrozumienie nie przychodzi od razu. Wtedy jestem gotowy dopiero przeprojektować właściwie domenę i mieć właściwe bound context i dopiero wtedy mogę podzielić serwis na microserwisy. Tak jest po prostu taniej.
    Dam znać jak znajdę sposób, aby od razu mieć zawsze dobrze utworzoną domenę i żeby nie trzeba było robić refactoring-u.

  12. @Maciek/@Michał Dzięki za wskazanie kierunku. Chyba czas pójść tym śladem. Wychodzi na to, że właśnie jestem w takim momencie o jakim pisze @WojtekS. Oświecenie przyszło i faktycznie minęło 2,5 roku (czy to jakaś reguła, są o tym jakieś naukowe artykuły?) :)

  13. Maciej jak się nazwy to narzędzie które używacie do automatyzując, bo w nagraniu usłyszałem PowerShell Make, ale nic o tym znaleźć nie mogę.

  14. @Filip
    Logtash + Elastic Serach + Kibana – a narzedzie o ktorym nie wspomnialem to chyba ‘Graphite’, dopytam sie dokladnie jak wroce z urlopu

    @dario
    @WojtekS
    Monolith First wlasnie ma to do siebie ze daje ci czas na poznanie dokladnie tego co budujesz i pozwala odkryc bounded contexty etc tylko ze monolith ciezej rozbic i ciezej z nim pracowac. Mysle ze idealne miejsce to gdzies po srodku, tylko teraz jak wyczuc ten moment ze to juz teraz ? Jak w calej naszej branzy nie ma co liczyc na jakies naukowe poparte statystyka obliczenia i trzeba po prostu isc za intuicja i doswiadczeniem, czasem trzeba zaryzykowac albo wprowadzac tak duze zmiany metoda malych krokow.

    Domeny chyba nie da sie tak odrazu zaprojektowac :P Software Development to nie tylko rozwiazywanie problemow ale tez wlasnie odkrywanie problemow i tego co chce klient, to jest caly proces :) Na pewno dzieki doswiadczeniu mozna ulatwic wiele problemow i uniknac wielu wpadek oraz slepych zaulkow. Nie bez powodu placi sie u nas za doswiadczenie. Temat rzeka, moze sami kiedys odnajdziemy jakis sprawdzony sposob i napiszemy jakas rewolucyjna ksiazke ktora wyrowci wszystko do gory nogami. Fajnie by bylo.

  15. baVGRBGARF on

    czemu do poprzednich wpisow nie mozna dodawac komentarzy ?

  16. @baVGRBGARF,
    To najskuteczniejsza metoda walki botami komentującymi. Komentarze są automatycznie wyłączane po 60 dniach. Po takim czasie i tak dyskusja by się nie kleiła.

  17. Pingback: webMASTAH.weekly.003 | webMASTAH