DevTalk Menu

Permalink:

20 – O mikroserwisach z Michałem Francem

(comments are closed)

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!


Zasubskrybuj podcast (e-mail, iTunes) lub ściągnij ten odcinek w mp3.

Linki:


Koniecznie zostaw komentarz: jak Ci się podoba odcinek?
Nie zapomnij też dołączyć do społeczności DevTalk na Facebooku i Twitterze :)!
Zapisz się również na Newsletter, aby nie przegapić żadnego odcinka!

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

  • pawelek

    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 ?

  • Pawel K

    Czuc moc w tym podcascie :)

  • dario

    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.

  • itosu

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

  • Michal Franc

    @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.

  • Łukasz Woźniczka

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

  • Filip

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

  • Maciej Aniserowicz

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

  • Maciej Aniserowicz

    @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”.

  • Maciej Aniserowicz

    @itosu,
    Mogli nazwać PBimber i nie byłoby problemu :)

  • Mariusz

    Myślę, że jako uzupełnienie wiedzy o microserwisach warto również obejrzeć prezentację Udi Dahana Business Logic, a different perspective.

  • Grzegorz

    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

  • WojtekS

    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.

  • dario

    @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?) :)

  • Bogusz

    Updated: DevTalk – Programistyczny głos w Twoim domu
    http://groopmark.com/link/details/181/devtalk-programistyczny-glos-w-twoim-domu?cid=11

  • Tomek

    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ę.

  • Maciej Aniserowicz

  • Michal Franc

    @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 😛 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.

  • baVGRBGARF

    czemu do poprzednich wpisow nie mozna dodawac komentarzy ?

  • Maciej Aniserowicz

    @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.

  • webMASTAH.weekly.003 | webMASTAH