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?