Microservice - Jak to ugryźć Opcje

[Pyton_000]

Temat nadaje się raczej do Pro (IMG:style_emoticons/default/wink.gif)

Do rzeczy. Mamy dość pokaźną aplikację która została napisana już wieki temu. Przyszedł czas aby zacząć ją migrować na nowe rozwiązania.
Aplikacja z biznesowego pkt. jest podzielona na modułu np. Wyszukiwarka, Klienci, Kontrakty, Firmy itd.

Ogólnie jest to aplikacja do zarządzania rekrutacjami.

Chcemy to zmigrować i postawić w oparciu o Microservices. Tylko jak to ugryźć.
Nie mam doświadczenia w tej materii więc może będzie ktoś kto udzieli jakichś wskazówek.

Założenia są takie że migrujemy na Laravel 5.1 (nie pytajcie dla czego (IMG:style_emoticons/default/tongue.gif) , hejt i tak nic nie wniesie (IMG:style_emoticons/default/smile.gif) ), PHP 5.6 (lub 7).
Jest to dość złożona struktura, dla tego musimy się "wpiąć" w stary system i robić przekierowanie do nowych elementów tak aby móc powoli wyłączać stare rzeczy.

Może ktoś ma jakieś ciekawe materiały na ten temat, jak to ładnie powinno wyglądać.
Wiem tyle że całość ma się opierać o REST i Events.

Czy każdy moduł stawiać jako w pełni działająca aplikacja na FW czy może jakieś inne rozwiązania.

[by_ikar]

Założenie mikrosewisów nie jest takie że wszystko działa zupełnie odrębnie i żaden nie wie nic o drugim. To jest tak jak w przypadku aplikacji MVC, gdzie poszczególne kontrolery nie są na sztywno powiązane z widokami czy modelami. Te same modele czy widoki możesz również wykorzystać w innej części swojej aplikacji. A taka baza danych to jest część wspólna tych mikroserwisów, bo w jakiś sposób trzeba uwierzytelniać requesty, a najlepiej byłoby tymi samymi danymi. Skoro w tym momencie jakoś już przydzielasz poszczególne bazy danych użytkownikom, to nie ma problemu aby powstało API dzięki któremu takie rzeczy będziesz mógł robić.

Kilka miesięcy temu w końcu w firmie w której pracuje została podjęta decyzja o przepisaniu aplikacji, właśnie z monolita, gdzie wszystko było w jednym repo, wszystko działało na jednym serwerze, rozbudowywanie było trudne, deployment jeszcze trudniejszy etc, przez co jak przyszedł większy ruch, aplikacji zwyczajnie nie dało się skalować, a po mimo moich (nie tylko) uporczywych niekiedy argumentach decyzja za każdym razem była ustala na termin może kiedyś, ja tylko czekałem na większy ruch który ubije aplikację. Kiedy tak się stało, nagle dział marketingu który twierdził że do czegoś takiego nie dojdzie, ocknął się z ręką w nocniku i aplikacje trzeba było przepisywać na wczoraj. Więc im szybciej małymi kroczkami, tym lepiej, a jak ktoś z działu marketingu twierdzi inaczej, to niech to napisze na papieru i się pod tym podpisze, że jeżeli będą problemy w przyszłości, to za nie wszystkie odpowiada właśnie on. Inaczej z tymi mendami się nie da czasami :/