Wakacje, 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!
Montaż odcinka: Krzysztof Śmigiel.Ważne adresy:
- zapisz się na newsletter
- zasubskrybuj w iTunes, Spotify lub przez RSS
- ściągnij odcinek w mp3
Linki:
- Martin Fowler:
- duży artykuł o mikroserwisach: http://martinfowler.com/articles/microservices.html
- Circuit Breaker: http://martinfowler.com/bliki/CircuitBreaker.html
- “Monolith First”: http://martinfowler.com/bliki/MonolithFirst.html
- Mój blog:
- “Architektura przyjazna rozwojowi programisty”: http://www.maciejaniserowicz.com/2014/09/22/architektura-przyjazna-rozwojowi-programisty
- “Programowanie przez eksplorację”: http://www.maciejaniserowicz.com/2010/07/08/programowanie-przez-eksploracje
- Narzędzia:
- Kibana: https://www.elastic.co/products/kibana
- Logstash: https://www.elastic.co/products/logstash
- video “Kibana with Logstash”: https://www.elastic.co/videos/kibana-logstash
- Raygun: https://raygun.io
- Chef: https://www.chef.io/chef/
- Docker: https://www.docker.com
- Puppet: https://puppetlabs.com
- Jenkins: https://jenkins-ci.org
- TeamCity: https://www.jetbrains.com/teamcity/
- Octopus Deploy: https://octopusdeploy.com
Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
O mikroserwisach z Michałem Francem
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl
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 ?
Czuc moc w tym podcascie :)
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.
“psake is pronounced sake – as in Japanese rice wine. It does NOT rhyme with make, bake, or rake.” ;)
@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.
Ja bym jeszcze dodał swaggera do dokumentowania usług restowych bardzo dobrze działa ze spring mvc oraz JAX-RS
@Michał, podczas rozmowy wspominaliście o dashboardzie. Czy udało Ci się już ustalić “na czym” został on zrobiony?
@pawelek,
U nas to była kwestia spełnienia wymagań biznesowych – mikroserwisy pomogły zrealizować scenariusz “niektóre zamówienia traktujemy inaczej” :)
@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”.
@itosu,
Mogli nazwać PBimber i nie byłoby problemu :)
Myślę, że jako uzupełnienie wiedzy o microserwisach warto również obejrzeć prezentację Udi Dahana Business Logic, a different perspective.
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
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.
@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?) :)
Updated: DevTalk – Programistyczny głos w Twoim domu
http://groopmark.com/link/details/181/devtalk-programistyczny-glos-w-twoim-domu?cid=11
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ę.
@Tomek,
PSake: https://github.com/psake/psake
@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.
czemu do poprzednich wpisow nie mozna dodawac komentarzy ?
@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.
[…] devtalk – programistyczny głos w twoim domu programowanie […]