Klient posiada monolityczną aplikację, która składa się z kilkuset rozmaitych funkcjonalności. Wpadł na pomysł aby sprzedawać pojedyncze moduły poprzez odpłatne udostępnianie API.
Np. pewna firma posiada aplikację do handlu elektronicznego a on chce im zaoferować moduł, który będzie tworzył raport sprzedaży (wystawienie api z bazą danych, moduł ma być w miarę uniwersalny i pasować do wielu klientów). Jaka jest techniczna możliwość rozwiązania tego problemu?
0
5
Przerabianie monolitu na mikroserwisy jest zadaniem dla samobójcy, potrwa 3 lata i będzie z tym tyle zachodu, co z napisaniem tego od nowa, do tego wyskoczy jeszcze 50 rzeczy, które są problematyczne w mikroserwisach i z którymi aktualnie nie musisz się mierzyć.
Zamiast tego po prostu bym to oIFował - dajesz jakiś serwer licencji (albo inny sposób weryfikacji, np. klucz HASP), który przekazuje informację, czy dany user/klient ma uprawnienia do korzystania z danego modułu. Jeśli tak - to się odpala, jeśli nie to albo w ogóle dany moduł jest niewidoczny, albo zostawiasz go w interface, ale podczas próby skorzystania z niego pojawi się informacja, że ten moduł jest nieaktywny, aby go odblokować należy wykupić stosowny moduł, proszę o kontakt z infolinią/wdrożeniowcem/cokolwiek innego.
Opcja numer 2 ma dwie znaczące zalety: interface zawsze wygląda tak samo, niezależnie od faktu posiadania lub braku poszczególnych modułów, a po drugie - jest to też jakaś forma reklamy/zachęcenia klienta to korzystania z dodatkowych opcji.
0
Jak skomplikowana pod kątem logiki biznesowej jest aplikacja? Ile macie czasu, pieniędzy i umiejętności?
2
Jeśli nie macie studni z pieniędzmi bez dna, ogromu czasu i ogarniających ludzi, którzy umieją w mikroserwisy, to moim zdaniem samobójstwo :) już abstrahując od wielkości i złożoności monolitu, przy założeniu, że monolit dalej ma być rozwijany obok przepisanej wersji na mikroserwisy
2
Można obudować te moduły jakimiś fasadami, które sprawdzałaby uprawnienia. Nie za bardzo rozumiem jaki problem miałyby tutaj rozwiązać mikroserwisy
1
A te kilkaset funkcjonalności ma jakies testy napisane?
Czy rozbijanie tego na mikroserwisy ma jakieś uzasadnienie?
Potencjalnie co można zrobić "na szybko", to dorobić w formie mikroserwisu tę nową funkcjonalność, jeżeli ma być tylko do odczytu, to możesz sobie replikować bazę w locie do "mikroserwisowej", w oparciu o nią budować usługę.
Lepiej - zbudować strukturę bazy danych pod kątem analityki napisać jakiegoś ETL, który będzie wyciągał dane z głównej bazy i wrzucał do analityki.
2
Mikroserwisy zapewniają separację logiki. To co chce klient to użycie istniejącej logiki w innym kontekście. Kompletnie nie widzę powiązania. Po prostu wystaw api do kodu, który robi daną logikę. Jak tego się nie da zrobić (bo burdel) to trzeba zacząć refactor co może być fajnym ćwiczeniem przez przenoszeniem się do mikroserwisów (jeśli się odbędzie), bo będziesz miał wiedzę jak kod działa, gdzie są problemy i co można zrobić
6
alianorem napisał(a):
Wpadł na pomysł aby sprzedawać pojedyncze moduły poprzez odpłatne udostępnianie API.
Ale tego się tak nie robi. Mikroserwisy to szczegół implementacyjny i potem przykrywa się je wpsólnym API. Taką wielką fasadą żeby z zewnątrz wyglądało to jak jedna aplikacja
Jeśli ta cała aplikacja jest zainstalowana u klienta któryc chce odpłatnie udostępniać API to to co ty potrzebujesz to zestaw uprawnień (czyli ify w kodzie) do sprawdzania czy dany użytkownik ma opłacony feature X
3
WUT?
Przecież modularyzacja nie oznacza mikroserwisów.