Chcieliśmy stworzyć aplikacje jako mikro serwisy bądź też jako monolit. Aplikacja ma za zadanie obsłużyć jakieś 20-30 mniejszych aplikacji powiedzmy proste formularze z możliwością wprowadzeni, edytowania danych z ogromną ilością walidacji, generowanie tablic/zestawień do excela. Jednocześnie będzie mogło zalogować się okolo 250 osob Czy python + Django podolaja temu zadaniu? Czy może jakieś inne rozwiązanie ktoś poleci.
Podoła jak dobrze napiszesz aplikacje. wszystko można zepsuć. Ważne też jak zaprojektujesz bazę.
Co do zasady to nie jest jakaś nad wyraz potężna skala, te 250 równoczesnych użytkowników.
Pytanie, jakie jest uzasadnienie mikroserwisów przy takiej skali? Obecnie użeram się z projektem spełniającym mniej więcej te założenia (nisko-średnia skala, masa walidacji) i architektura mikroserwisów daje nam tylko tyle, że każde user story to nowy serwis, nowa infrastruktura do postawienia i trzeba się narobić, ale za to kwoty na rachunku za chmurę tylko rosną więc spoko.
Jak to są proste formularze to cudów pewnie tam nie ma. Generowanie Exceli też nie brzmi jak jakieś tytaniczne zadanie. Strzelałbym, że bardziej istotne od możliwości poradzenia sobie ze skalą będzie tu np. dostępność gotowców do eksportowania tych dokumentów, arkuszy kalkulacyjnych itd. Python, Java, NodeJS, .NET, nawet ten nieszczęsny PHP - wszystkie powinny mieć umiarkowanie bogate zaplecze w tej kwestii.
Ogólnie teraz mamy zrobioną taka aplikacje w C# i powiem że tak średnio to działa. Czyli ogólnie serwisy raczej nie polecacie przy takiej skali projektu. Ogólnie mamy na chwilę obecną do wyboru laravel, scala + vue, python Django, go? Czy jakieś rozwiązania można by było polecić? Głównie programowaliamy w c# + sql.
Czemu C# nie sprawdzał się?
Jeśli zespół z doświadczeniem w .NET miał problemy z postawieniem rozwiązania w .NET, to przerzucanie tego samego zespołu na nowy stos technologiczny prędzej przysporzy nowych problemów, niż rozwiąże istniejące.
Katrina Jarosz napisał(a):
Ogólnie teraz mamy zrobioną taka aplikacje w C# i powiem że tak średnio to działa. Czyli ogólnie serwisy raczej nie polecacie przy takiej skali projektu. Ogólnie mamy na chwilę obecną do wyboru laravel, scala + vue, python Django, go? Czy jakieś rozwiązania można by było polecić? Głównie programowaliamy w c# + sql.
C#, PHP, Scala, Go, Python... Toz to brzmi troche absurdalnie... Czy to jakis projekt studencki? Trudno mi sobie wyobrazic taka sytuacje wsrod doswiadczonych devow. W szczegolnosci, jaki senior C# dev by rozwazal babranie sie w PHP? :P
Anyway. Jesli znacie tylko C#, to piszcie w C#. A problemow nie szukajcie tutaj akurat w jezyku
Głównie programowaliamy w c#
To piszcie w C#, to bardzo wydajny język, w którym spokojnie można napisać każdą aplikację biznesową. Radzę zbadać dlaczego tak średnio to działa
.
mikro serwisy bądź też jako monolit
Mikro serwisy rozwiązują problemy spotykane w dużych aplikacja pisanych przez wiele osób. Ich wprowadzenie zawsze obniża performance i szybkość klepania, jeśli wasz team jest mały. Polecam nauczyć się dobrej modularyzacji, bo przy dobrym kodzie wydzielenie niezależnych od siebie modułów do osobnych serwisów to formalność
Czemu w C# nie działa tak jak powinno?! A no powód jest prosty. Inny zespół stworzył rdzeń aplikacji, a naszym zadaniem było napisanie do niego modułów (małe formularze) dostępu do ich bibliotek nie mamy no i w dodatku aplikacja jest jeszcze na wersji 4.0. dlatego takie małe rozeznanie robimy. Ogólnie jednym z głównych języków w który celujemy jest tytułowy.
Lepiej Python + FastAPI, ma fajną obsługę asyncio
.
Katrina Jarosz napisał(a):
Czemu w C# nie działa tak jak powinno?! A no powód jest prosty. Inny zespół stworzył rdzeń aplikacji, a naszym zadaniem było napisanie do niego modułów (małe formularze) dostępu do ich bibliotek nie mamy no i w dodatku aplikacja jest jeszcze na wersji 4.0. dlatego takie małe rozeznanie robimy. Ogólnie jednym z głównych języków w który celujemy jest tytułowy.
I w jaki sposob zmiana jezyka niby rozwiazuje problem?
W ogole jaki jest background? Jestescie zespolem programistycznym, czy moze to bardziej jakies "ogolne IT, infrastruktura, sieci itd." albo nawet "nie-IT, ale klepiemy makra do Excela bo nam prace ulatwiaja" w nie-IT-per-se firmie?
Tak z ciekawosci pytam, ale to tez moze odpowiedz zmienic, bo jesli teoretycznie pisaliscie tylko w C#, ale znacie go tylko po lebkach, bo nie jestescie programistami, to wtedy moze faktycznie whatever jaki jezyk wybierzecie.
Co nie zmienia faktu, ze Waszym problemem nie jest jezyk, tylko ludzie ktorzy napisali te apke. Jak sie napisze to samo, ale w innym jezyku, to efekt bedzie taki sam albo gorszy
Powiem nawet wiecej - Python co do zasady, to jest uznawany za jezyk duzo mniej wydajny od C# (bo jest dynamicznie typowany i interpretowany, a nie kompilowany). Jesli macie problemy z wydajnoscia, no to powodzenia z taka zmiana
Katrina Jarosz napisał(a):
Czemu w C# nie działa tak jak powinno?! A no powód jest prosty. Inny zespół stworzył rdzeń aplikacji, a naszym zadaniem było napisanie do niego modułów (małe formularze) dostępu do ich bibliotek nie mamy no i w dodatku aplikacja jest jeszcze na wersji 4.0. dlatego takie małe rozeznanie robimy. Ogólnie jednym z głównych języków w który celujemy jest tytułowy.
Czy przepisanie Waszego fragmentu aplikacji na inny język rozwiąże problemy komunikacyjne z innym zespołem?
Jak macie się z nimi zintegrować, nie mając dostępu do ich bibliotek, SDK, API, lub czegokolwiek, oraz jak zmiana języka na inny mogłaby rozwiązać ten problem?
Katrina Jarosz napisał(a):
dostępu do ich bibliotek nie mamy
A możecie mieć? Normalnym jest, że użytkownicy biblioteki mają dostęp do kodu, jeśli był pisany w tej samej firmie. Podaj więcej kontekstu:
- gdzie jest problem
- jakiej natury jest problem? Jak to polityka i np. nie możecie mieć dostępu albo komunikacja z teamem utrzymującym jest trudna to jest to kluczowa informacja
Katrina Jarosz napisał(a):
Jednocześnie będzie mogło zalogować się okolo 250 osob
Czy python + Django podolaja temu zadaniu? Czy może jakieś inne rozwiązanie ktoś poleci.
Wątpię. Pythona uczą głównie na uczelniach i większość sensownie go obsługujących to ludzie z Phd. Oni nie operują na takiej skali. Weź może Ruby.
loza_prowizoryczna napisał(a):
Wątpię. Pythona uczą głównie na uczelniach i większość sensownie go obsługujących to ludzie z Phd. Oni nie operują na takiej skali. Weź może Ruby.
Co za herezję słyszę. Mam projekt, gdzie okresowo(taka specyfika produktu) są skoki na parę tysięcy ludzi i bez problemu obsługujemy taki ruch. 250 osób to nic takiego.
Co do autorki. Jak kod jest kijowy, architektura skopana, to nie ważne w czym napiszecie, będzie to działać wolno.
Odpowiadając na pytanie, tak python da radę, ale z wątku wynika, że to nie język jest problemem.
Pythona uczą głównie na uczelniach i większość sensownie go obsługujących to ludzie z Phd
Sorry, ale to jest xD, zapytaj, np., w Instagramie:)
Jeśli nie umiesz nic innego to python jest jedyne co się nada.
Ale python jest dobry, jakieś krytyczne elementy można sobie w C++ napisać, a nawet można uruchomić kilka instancji tego samego serwera i load balancingiem rozrzucać zapotrzebowanie, zależy co tam knujecie, ale chyba nie zrobicie drugiego netflixa.
Czyli retoryczne pytanie, w ogóle głupio się tak nie technicznie odpowiada, co taka odpowiedź daje?
slsy napisał(a):
Katrina Jarosz napisał(a):
dostępu do ich bibliotek nie mamy
A możecie mieć? Normalnym jest, że użytkownicy biblioteki mają dostęp do kodu, jeśli był pisany w tej samej firmie. Podaj więcej kontekstu:
- gdzie jest problem
- jakiej natury jest problem? Jak to polityka i np. nie możecie mieć dostępu albo komunikacja z teamem utrzymującym jest trudna to jest to kluczowa informacja
No właśnie nie możemy mieć dostępu, dlatego myślimy nad swoim rozwiązaniem, żeby miec pełny dostęp. Tak jest polityka firmy, że z góry narzucają swoje rozwiązania wypracowane w jednej z placówek reszcie. Nie jest ważne w tym wypadku co nie gra w firmie. Proszę tylko o podpowiedzi co do technologi. Ktoś już z was na pewno miał styczność z różnymi problemami/aplikacjami i może coś doradzić.
Przy takiej "skali" to wszystko podoła. Radzę zrobić monolicik i nie bawić się w mikroserwisy (https://martinfowler.com/bliki/MicroservicePrerequisites.html).
Radzę wygenerować tak dużo jak się da przez AI i od tego zacząć. Oraz dodatkowo wynająć pentesterów przed wtoczeniem się na produkcje.
Podstawowy problem tutaj to eksport do Excela (CSV wystarczy?) - najlepiej brać język który ma dobrą i darmową bibliotekę do tego.
Co do znaczy duża ilość walidacji? Trzeba zaciągać dane z wielu baz/mikroserwisów?
Jak zawsze w tego typu pytaniach: garbage in -> garbage out...
99xmarcin napisał(a):
Przy takiej "skali" to wszystko podoła. Radzę zrobić monolicik i nie bawić się w mikroserwisy (https://martinfowler.com/bliki/MicroservicePrerequisites.html).
Radzę wygenerować tak dużo jak się da przez AI i od tego zacząć. Oraz dodatkowo wynająć pentesterów przed wtoczeniem się na produkcje.Podstawowy problem tutaj to eksport do Excela (CSV wystarczy?) - najlepiej brać język który ma dobrą i darmową bibliotekę do tego.
Co do znaczy duża ilość walidacji? Trzeba zaciągać dane z wielu baz/mikroserwisów?Jak zawsze w tego typu pytaniach: garbage in -> garbage out...
Co do excela to musi być. Jeśli chodzi o walidację to powiedzmy w jednym czasie w najgorszym scenariuszu 20tys walidacji. Z kilku tabeli ma zaciągać dane do walidacji
Katrina Jarosz napisał(a):
Ogólnie teraz mamy zrobioną taka aplikacje w C# i powiem że tak średnio to działa.
W którym C#, na którym dotnecie.
No bo jeśli to jakieś antyczne webformsy odpalone na thinkpadzie jeszcze produkcji IBM, to może faktycznie zadyszki dostawać.
Czyli ogólnie serwisy raczej nie polecacie przy takiej skali projektu.
Wy nie macie skali w tym projekcie. :D
Jeśli macie problem z wydajnością, to trzeba sprofilować, co powoduje problemy, i potem ewentualnie podejmować decyzje, a nie walić na oślep z wyborem zamiennej technologi.
A przyczyn problemów może być dużo - od braku indeksów w bazie, przez błędną konfigurację serwera, po Thread.Sleep(60000)
w celu synchronizacji wątków.
Technologia zastosowana to .net 4.0. tak jak był pisane wcześniej biblioteki zrobił inny zespół. Do tych bibliotek nie mamy dostępu i nie będziemy mieć. Dlatego wolimy zrobić swoja aplikacje. Oczywiście technologia będzie nowocześniejsza.
Katrina Jarosz napisał(a):
Technologia zastosowana to .net 4.0. tak jak był pisane wcześniej biblioteki zrobił inny zespół. Do tych bibliotek nie mamy dostępu i nie będziemy mieć.
Jeśli to biblioteki dotnetowe, to można je po prostu zdekompilować.
Dlatego wolimy zrobić swoja aplikacje. Oczywiście technologia będzie nowocześniejsza.
No tak, Django na pewno jest nowocześniejsze. ;)
Katrina Jarosz napisał(a):
Czyli ogólnie serwisy raczej nie polecacie przy takiej skali projektu.
Mikroserwisy poprawnie wdrożone rozwiązują szerek problemów takich jak:
- skalowanie
- izolacja błędów
- elastyczność technologiczna
- zwinność w rozwoju i wdrażaniu
- łatwiejsze utrzymanie i rozwój zespołu
ale dodają sporo nowych (komplikuje się infrastruktura, trzeba zaopiekować aspekty które w monolicie nie mają znaczenia, brak traksakcyjności w rozumieniu ACID itp) ponad to zrobienie mikroserwisów dobrze to bynajmniej nie deploy N aplikacji na jakimś kubernetesie.
Mam wrażenie, że nikt nie pokusił się o sporządzenie listy wymagań które ten system ma spełnić.
Bo czemu mikroserwisy? Bo czemu python?
I co znaczy, że aplikacja ma obsłużyć 20-30 mniejszych aplikacji?
Z Twojego opisu wynika mydło i powidło.
Skoro zespół ma kompetencje w C#, nie macie narzucone, że aplikacja ma być turbo szybka, ma mieć niską latencję czy ma się skalować do nie wiadomo jakich rozmiarów to zróbcie ją w technologii którą znacie zamiast zaciągać dług technologiczny już na samym starcie który zdaje się nie jest podyktowany żadnymi realnymi potrzebami (nowe technologie, architektura mikroserwisowa itp).