Docker i microserwisy na produkcji

Pijany Bombowiec napisał(a):

Ale nie zawsze widac dobrze domeny. Ale jesli biznes nie jest zdecydowany dokladnie to co chce latwo skonczyc z rozproszonym monolitem.

Jeśli to biznes miałby decydować o kształcie mikroserwisów, to faktycznie mogłoby tak się stać. Niemniej jednak, nie należy oddawać biznesowi decyzji architektonicznych, bo to się źle kończy w przypadku każdego systemu.

A to by nie zaczynac od mikroservisow to rozumiem, ze rzucasz wyzwanie miedzy innymi slowom Martina Fowlera i wielu innym?

Od początku tej dyskusji nie napisałem ani słowa o zaczynaniu, pisałem ogólnie o praktycznych zaletach mikroserwisów, które znam z autopsji.

I nie. Nie zbudowalem nic co napisales. A brak ACID trzeba zaakceptowac.

Naprawdę nie rozumiem, co ma ACID do mikroserwisów.

Wiele mikroserwisow wymaga przynajmniej czesci takich ficzerow :
http://blog-redhatdevelopers.rhcloud.com/wp-content/uploads/2016/12/screen-shot-2016-12-06-at-10-30-08.png

Wiele monolitów również. Infrastrukturę i narzędzia do niej po prostu trzeba sobie zbudować, tak czy siak. Teraz mamy o tyle łatwiej, że mamy chmury, narzędzia CI, analizatory logów, i wiele innych gotowców do rozwiązania tego typu problemów.

Pijany Bombowiec napisał(a):

Ja widzialem z kolei mkroserwisy bez discovery i bez dobrego zarzadzania konfigami oraz bez api gateway. A takze gdy niektore serwisy wyszly za duze. Sredniawka. Projekty Zaczynane jako mikro.

Nie mówię, że nie da się spieprzyć mikroserwisów. Pytanie, co w takiej sytuacji łatwiej naprawić - wielką monolityczną kobyłę, czy mikroserwisy jeden po drugim?

somekind napisał(a):

Jeśli to biznes miałby decydować o kształcie mikroserwisów, to faktycznie mogłoby tak się stać. Niemniej jednak, nie należy oddawać biznesowi decyzji architektonicznych, bo to się źle kończy w > > przypadku każdego systemu.

Nie o to chodzi. Jest projekt. Biznes ma tylko zarys co chce osiągnąć i co ma być w ogóle zawarte w projekcie, albo jakie ficzery mają być zawarte.
Wtedy trudno zrobić mikroserwisy bo nie wiadomo na co się przygotować. Mówię o przypadku zaczynania projektu od mikroserwisów.

Noto musiałem źle odczytać słowa :
"błędny wybór architektury i stosu technologicznego na początku projektu."

czescccc

A co myslicie o REST vs message broker w mikroserwisach?

Czarny Pijak napisał(a):

A co myslicie o REST vs message broker w mikroserwisach?

Ja się dołączę do pytania - po co message broker skoro w REST można robić asynchronicznie (HTTP 202)?
http://farazdagi.com/blog/2014/rest-long-running-jobs/
https://jersey.java.net/documentation/latest/async.html
http://allegro.tech/2014/10/async-rest.html
http://restcookbook.com/Resources/asynchroneous-operations/
https://www.adayinthelifeof.nl/2011/06/02/asynchronous-operations-in-rest/

Pewnie 'to zależy' ;)

Tutaj jest dość ciekawy artykuł:
http://nordicapis.com/asynchronous-apis-in-choreographed-microservices/ "Choreographed Microservices"
"Thinking about events instead of actions lets us effectively decouple our logic. "

Ostatnio spotkałem się z tekstem :
"Synchronous RESTful communication between Microservices is an anti-pattern" Jonas Bonér CTO Typesafe/Lightbend
Ale uważam to za przesadę.

Ja niestety nie mam za bardzo doświadczenia z CQRS czy Event sourcing ale zdaje się rowiązywać pewne problemy ;) (pewnie tworząć inne :P )

https://codurance.com/2015/07/18/cqrs-and-event-sourcing-for-dummies/
https://www.confluent.io/blog/event-sourcing-cqrs-stream-processing-apache-kafka-whats-connection/

To, że z mikroserwisami wiąże się 12345 tysięcy buzzwordów nie oznacza, że od razu musimy zaimplementować wszystko co się da. Mikroserwisy, a konkretnie wymagany przez nie podział monolitu ma dla mnie takie zalety:

• łatwiej jest ogarnąć jeden mikroserwis z wąskim API niż wielką kobyłę, gdzie jest sporo (nieoczywistych) zależności - w związku z tym jeśli mamy zadanie które wymaga porzeźbienia tylko w jednym mikroserwisie to jest łatwiej się wdrożyć w projekt i zacząć niż gdybyśmy wdrażali się w wielką kobyłę,
• tworzenie rozbudowanego API między serwisami jest upierdliwe, więc tworząc mikroserwisy trzeba dbać o to, by API było zwięzłe, ale funkcjonalne - jest to pewien początkowy koszt przy budowaniu mikroserwisu, ale potem to procentuje, bo mamy system łatwiejszy do stopniowego ogarnięcia,
• luźne powiązania między serwisami, np przez tekstowy protokół RESTowy sprawiają, że łatwo jest stopniowo wymieniać stos technologiczny - serwis po serwisie, w razie potrzeby,

Podział monolitu na moduły, przynajmniej w Javowym świecie, się nie sprawdza. Problemem jest głównie to, że jeśli moduł A zależy od modułu B, to oznacza to iż dowolna klasa z modułu A widzi dowolną publiczną klasę z modułu B. Inaczej mówiąc wszystkie publiczne klasy z modułu stają się jego publicznym API, a to jest zdecydowanie zbyt dużo. To jest prosta droga do tworzenia źle zrobionych zależności, a w konsekwencji przesuwania kodu do jakiegoś wielkiego centralnego modułu, gdzie wszystko jest poplątane, bo to jest łatwiejsze niż rozplątywanie zależności.

Zalety mikroserwisów niespecjalnie widać w przypadku prostych i młodych aplikacji, ale im większy system tym większe zyski daje podział na mikroserwisy.

@Wibowit Czy mi odpisujesz? A jak nie to w jakim kontekscie to piszesz bo nie rozumiem. Mikroserwisy maja wiele plusow jak i minusow.

A messaging to po prostu sposob komunikacji i tyle a nie zaden buzzword.

Docker na produkcji, runda druga
https://thehftguy.com/2017/02/23/docker-in-production-an-update/

Czy w mikroserwisach errory powinno się przekazywać z usługi do usługi po status codach ?

A jaką masz alternatywę?

A co w przypadku mikroserwisów i takich wymagań? https://en.wikipedia.org/wiki/Write_once_read_many

fgdrfr