A tak poza tym microservices to najbardziej nadużywany pattern, przydatny jedynie w duzych i skomplikowanych projektach nad którymi pracuja setki devow
@zarev: skąd wziąłes "setka devów". Masz jakieś uzasadnienie na to? Dlaczego przy 20-tu developerach się już to nie sprawdzi? - pytam bez ironii. Chce zrozumieć.
Wydaje mi sie, ze Twoja wypowiedz jest niespojna. Z jednej strony sugerujesz, ze mikroserwisy sa jedynie dla wielkich projektow. Z drugiej natomiast, ze wybrałbyś pythona
@zarev: No i dobrze, że zadałem pytanie bo tak czułem, że poruszamy się w tej dyskusji w obszarze raczej domysłów i niestety nie jest poparte w pełni doświadczeniem.
Python wymaga mniej kodu zeby napisac identyczna funkcjonalnosc, ot programista jest w stanie dowiezc wiecej rezultatow w tej samej jednostce czasu.
Nie. Argument totalnie z czapy. Są inne problemy związane ze Scalą, z którymi można się zgodzić ale akurat z tym nie trafiłeś.
Albo potrzebuję tego patternu ze względu na prostsze utrzymywanie skomplikowanej logiki oraz mamy bardzo wyraźnie wydzielone domeny.
@inny_89: Ja bym w takim razie wydzielił domeny do osobnych niezależnych modułów w monolitycznie deployowanej appce.
Ale nawet jak się uprzeszna mikroserwisy, to wybór języka jest prosty - wybierz ten który do danego mikroserwisu będzie lepiej pasował i/lub w którym team czuje się mocniej. Nie musisz przecież pisać wszystkich w tej samej technologi.
@m_bielawski nareszcie głos rozsądku w sprawie wybranego języka! Chodzi przecież o to, żeby mikroserwis był niezależny - należałoby więc dążyć do sytuacji gdzie można go niezależnie "wyjąć" i przepisać np z Pythona na JSa (pomijam zasadność takiej akcji).
Nie mogę się jednak zgodzić co do monolitu z wydzielonymi modułami. Tracisz wtedy pulsy mikroserwisow i zyskujesz poziom skomplikowania podobny do nich. Za to podatność na błędy i złożoność może być nawet większa. Możesz
Kupione w ciemno za jakieś grosze rok temu, psiknięte dwa razy. Nie mogę znieść tego zapachu, więc robię #rozdajo #perfumy nie wiem tylko czy ten syf można określić mianem perfum
Przesyłkę InPost opłaca wygrywający.
Losowanie dzisiaj o 21.
Udziału nie biorą: zielonki, użytkownicy z tagów pato mma gal
#microservices #scala #python #programowanie
Jeżeli już #microservices to:
Komentarz usunięty przez autora
@zarev: skąd wziąłes "setka devów". Masz jakieś uzasadnienie na to? Dlaczego przy 20-tu developerach się już to nie sprawdzi? - pytam bez ironii. Chce zrozumieć.
Wydaje mi sie, ze Twoja wypowiedz jest niespojna. Z jednej strony sugerujesz, ze mikroserwisy sa jedynie dla wielkich projektow. Z drugiej natomiast, ze wybrałbyś pythona
Komentarz usunięty przez autora
Nie. Argument totalnie z czapy.
Są inne problemy związane ze Scalą, z którymi można się zgodzić ale akurat z tym nie trafiłeś.
@inny_89: Ja bym w takim razie wydzielił domeny do osobnych niezależnych modułów w monolitycznie deployowanej appce.
Ale nawet jak się uprzeszna mikroserwisy, to wybór języka jest prosty - wybierz ten który do danego mikroserwisu będzie lepiej pasował i/lub w którym team czuje się mocniej. Nie musisz przecież pisać wszystkich w tej samej technologi.
Chodzi przecież o to, żeby mikroserwis był niezależny - należałoby więc dążyć do sytuacji gdzie można go niezależnie "wyjąć" i przepisać np z Pythona na JSa (pomijam zasadność takiej akcji).
Nie mogę się jednak zgodzić co do monolitu z wydzielonymi modułami. Tracisz wtedy pulsy mikroserwisow i zyskujesz poziom skomplikowania podobny do nich.
Za to podatność na błędy i złożoność może być nawet większa.
Możesz
Komentarz usunięty przez autora
ad.1 Jaki przypadek w mikroserwisach uzasadni użycie Scali a jaki Pythona?
Programisci Scali sa drozsi i trudniej dostepni