JSP REST SPRING microservices - Czy warto?

0

Cześć
Znalazłem się w projekcie gdzie klient ma już prawie cały frontend w JSP, jest juz dosc duzo backendu w Springu, klasycznie z JPA.
Projekt zaczęli dawno, wyłożyli dużo kasy, po przerwie chcą go 'kończyć' jednak czy warto brnąć w JSP i monolit?
Nie chcą zmieniać front-endu, ewentualnie możemy zmienić back-end na microservisy, aby mieć większe możliwości skalowania.
Czy to ma sens?
Czy cisnąć ich w stronę np angular+microservices? Czy JSP nada się do współpracy z RESTApi i microservisami?
A może tak zostawić?
nie znam się na front-endzie, a będę musiał się nauczyć choć odrobinę, także wolałbym angulara ;)
Proszę o pomoc.

0

Czy firma płaci Ci za dostarczoną wartość czy za to żebyś się uczył tego czego chcesz?

Chyba, że potrafisz przepisać to na mikroserwisy w 3 miesiące? Przypominam, że mikroserwisy to najbardziej skomplikowana i czasochłonna architektura wymagająca między innymi zautomatyzowanych pipelinów CI/CD,

3

Czy warto? Warto, bo z opisu wynika, że masz problem, którego ilustrację można znaleźć tutaj. Jeżeli aplikacja monolityczna jest źle napisana, to przepisanie jej na mikroserwisy nic nie zmieni. Nadal będzie to tak samo nieutrzymywalne i nierozwijalne, a dodatkowo dojdą problemy z orkiestracją wszystkiego.

Zacznijmy od frontu. JSP obecnie można rozszyfrować jako Jest Świętej Pamięci. Jednak będzie to też najtrudniejszy fragment kodu do przepisania. Najprawdopodobniej jest tam dużo magii związanej z warunkowym wyświetlaniem elementów, bezpieczeństwem, ścieżkami dojścia do widoków itp. Zatem tu nic nie zwojujesz. Gorzej można najszybciej coś popsuć.

Następna warstwa to Spring i tu można już zaszaleć, bo najsensowniej jest spróbować podzielić kod na niezależne moduły, które będzie można budować osobno i na końcu składać do monolitu. Tyle tylko, że zapewne masz całość podzieloną „zadaniowo”, czyli serwisy, dao, kontrolery mają własne pakiety, a nie „funkcjonalnie”, czyli pakiet zamyka w sobie funkcjonalność biznesową. Krok pierwszy to poprzekładanie tego do innej struktury pakietów.

Na koniec warstwa dostępu do danych, czyli to nieszczęsne JPA. Tutaj pytanie czy to jest prosty CRUD, który nie zawiera jakiejś głębszej logiki, czy też zaszyte są tam tony NamedQueries i NativeQueries, które reprezentują jakąś wartościową logikę biznesową. Za dużo pytań za mało kontekstu by się odnieść.

@nie100sowny, architektura mikroserwisowa jest stosunkowo prosta i nie pochłania aż tyle czasu co się wydaje. Nie wymaga też jakiś magii CI/CD, bo w założeniu usługi powinny być niezależne i samodzielne.

3

Pytanie co to jest ten JSP ? jest tam jakiś framework (Spring MVC ?) .

JSP się zupełnie dobrze sprawdza jako jezyk templatów to robienia stronek pod SPA z angularem (czyli wpółpraca z REST potem):-)
Tylko, że nie używasz prawie żadnych własciwości JSP poza include ... ewentualnie możesz wykorzystac wyrażenia, żeby prerenderować strony na serwerze (normalna aplikacja jednakowoż tego nie potrzebuje- ma pewien sens pod SEO - e-sklepy/cmsy).

Właściwie decyzja zależy od tego jak te JSP wyglądają i co ten system ma robić.. i co to znaczy prawie. Prawie gotowy system to często znaczy, że jest zrobione 10%.

1
  1. Idę o zakład że nie JSP tylko templaty JSTL i renderowanie htmla po stronie serwera. To że masz plik .jsp nie znaczy że faktycznie są tam jakieś skryptlety
  2. Nic nie stoi na przeszkodzie żeby łączyć JSTL z Angularem, chociaż w praktyce ten JSTL zamieni sie w goły html
  3. Zacząłbym od próby podziału warstwy logiki na moduły. Bo mikroserwisy brzmią modnie, ale w wielu sytuacjach zwyczajnie nie da sie ich wprowadzić bo logika jest ze sobą powiązana.
0

Jeżeli aplikacja ma to JPA, aby mieć centralną bazę danych i są silne powiązania pomiędzy obszarami to jak dla mnie mikroserwisy tu nie pasują, bo pewnie chcesz mieć transakcje.

@koziolek: czy mikroserwisy nie zaczynają się dopiero wtedy gdy:

  • aplikacja jest bezstanowa: aby umożliwić auto-scaling
  • zalecane jest, aby aplikacja byla bezsesyjna (czyli trzeba jakiś serwer do tokenów)
  • mamy service discovery (bo bez tego ciężko zrobić auto scaling), dochodzi jeszcze centralna konfiguracja (+ szyna do powiadamiania o zmianie konfiguracji)
  • fajnie mieć opis infrastruktury jako kod: szybki deploy, można ubijać VM-ki jak przestają być potrzebne
  • robota, aby skonfigurować load balancer (reverse proxy, bez tego nie ma skalowania)

Jak dla mnie to jest całkiem sporo roboty na start i nie wszędzie będzie działać dobrze. Zawsze można tworzyć aplikacje monolityczne z pewnymi cechami mikroserwisów. Czyli dzielić modułowo tak jak:

  • niezależnie testujesz integracyjnie
  • wyspy możesz wydzielić jeśli zmniejsza to ilość pracy przy deploymencie (nie zawsze ma to sens). Jak dla mnie ma to sens, gdy pewne obszary aplikacji zmieniasz często, a inne rzadko. Wtedy też masz lepszą dostępność i bezawaryjność. Ale jak pewne aplikacje (części większego systemu) działają niezależnie od siebie i chcesz je oddzielnie deployować to fajnie mieć to w oddzielnej VM-ce (kontenerze)
  • czasem można mieć współdzieloną bazę pomiędzy aplikacjami (fragmentami większego systemu), ale w JPA masz cache, więc spodziewam się kupy w tym przypadku (nie jest to droga): w mikrousługach nie ma mowy o współdzieleniu bazy

Jak masz bezstanową aplikację i problemy ze skalowalnością to dzielenie monolitu jest naturalną drogą do praktycznych i skutecznych mikroserwisów. Inaczej zwykle kończy się to przerostem formy nad treścią, technologicznym onanizmem i ogólnie przekombinowaniem projektu, który mógł być prosty (czasem fajnie mieć wszystko w jednym EAR/WAR i prosty deployment).

Ogólnie co mi się podoba w mikroserwisach to że każdy zespół może niezależnie pracować nad modułem, który samodzielnie ma sens,

1 użytkowników online, w tym zalogowanych: 0, gości: 1