[wargi-sromowe-mniejsze]

Jako #programista30k z 16-letnim stażem, głównie w projektach związanych z szerokim web-devem ale też integracją produktu z urządzeniami mobilnymi, zewnętrznymi serwisami, internet of things pragnę podzielić się listą największych wg mnie błędów jakie popełniają firmy technologiczne na którymś z etapów swojego istnienia.

1. Migracja monolitu do SOA.
W większości przypadków przynosi więcej szkody i niepotrzebnych kosztów niż utrzymanie solidnie zaimplementowanego monolitu. Zazwyczaj inicjowana na pewnym etapie życia produktu przez grupę doświadczonych inżynierów znudzonych codzienną pracą z monolitem i szukających wyzwań pozwalających im zdobyć nowe doświadczenie. Potrzeba tej zmiany jest argumentowana zazwyczaj lepszą w teorii skalowalnością systemu, łatwiejszym deploymentem i utrzymaniem wszystkich serwisów. W praktyce podobną skalowalność dużo łatwiej osiągalną przez dołożenie zasobów można uzyskać zostając przy monolicie. Zazwyczaj taka migracja dokłada tylko problemów z architekturą sieciową i integracją wszystkiego w jedną całość, dochodzi konieczność utrzymania brokera eventów i asynchronicznej komunikacji, etc. Przy braku odpowiednich nakładów świetnych inżynierów: zarówno programistów i devopsów firmy dokładają sobie tylko niepotrzebnego skomplikowania całości, nie wspominając o kosztach przepisania całości z monolitu na SOA co samo nie przekłada się na zysk firmy.

Z mojego doświadczenia w 99% przypadków dobrze napisany monolit, najlepiej napisany w podejściu: Loosely Coupled Monolith będzie o wiele korzystniejszym, prostszym i tańszym zarówno w implementacji jak i utrzymaniu rozwiązaniem.

Pokuszę się nawet o stwierdzenie, że przepisywanie monolitu na SOA w zasadzie nigdy nie może wyjść dobrze a pozwolić sobie na używanie tej architektury mogą sobie tylko wielcy gracze, dysponujący nieograniczonymi zasobami zarówno finansowymi jak i ludzkimi, pozwalającymi na napisanie a nie przepisanie wszystkiego od nowa przez wiele niezależnych teamów, każdy odpowiedzialnych tylko i wyłącznie za jeden serwis. Firma powinna również posaiadać dedykowany, doświadczony team devopsów to stworzenia i utrzymania architektury sieciowej dla SOA (niezależnie czy w cloudzie czy na serwerach dedykowanych)

2. Wdrażanie modnych rozwiązań na siłę - szlagierowy przykład to używanie GQL zamiast REST do API
Wdrażane z pobudek podobnych do migracji do SOA - chęć użycia i nauczenia się nowej technologii.
Problemy w zasadzie te same. W przypadku GQL jest to komplikowanie prostych rzeczy, problemy z optymalizacją zapytań i eliminacją problemu N+1, które w GQL rozwiązuje się w sposób nietrywialny jak ma to miejsce w api REST.
Często śmieję się z firm, które na siłę wrzucają GQL mając tylko jednego i to swojego klienta tego API, API które do tego nie zmienia się często. GQL ma w zasadzie sens tylko w projektach, które udostępniają różnorakie podzbiory API różnym klientom, co nie przeszkadza programistom wdrażać tego rozwiązania w prostych projektach tym samym robiąc klasyczny "strzał z potężnej armaty jaką jest GQL do muchy, jaką jest ich prosty w założeniach projekt"

3. Naiwne myślenie, że wytwarzanie oprogramowania skaluje się liniowo względem ilości inżynierów.
W przybliżeniu jest tak faktycznie do pewnego rozmiaru firmy. Słowem 2 programistów wykona pracę 2x szybciej niż 1, czy nawet 6 wykona ją 2x szybciej niż 3, ale od powiedzmy 5 programistów przestaje się to tak prosto skalować ponieważ dochodzi znacząca praca polegająca na po pierwsze podziale pracy między zespoły a po drugie komunikacji między nimi czy wreszcie po 3 scaleniu tej pracy. Najgorsze, że nawet doświadczeni managerowie czy tech-leadzi często zakładają że mając zespół 50 osób, dobiorą kolejne 50 osób i zrobią pracę 2x szybciej. Otóż często zrobią tę pracę nawet trochę wolniej.

#programowanie #pracbaza #pracait #it

[sobol86]

@wargi-sromowe-mniejsze zaraz ktoś z tego zrobi branżowy artykuł

[RapIArbuzy]

@sotilas: Ty, leszczu, a kiedy przestaniesz ból dupić o czyjeś zarobki? Teraz za mało, a jak ktoś ma sporą kasę i jest młodszy, to ból dupisz mówiąc, że to niemożliwe. xD

[jestem_tunowy]

Jako #programista30k

@wargi-sromowe-mniejsze: przestałem czytać

[beethoven]

@wargi-sromowe-mniejsze: jest dobry monolit i jest zły monolit. Jest dobra ekstrakcja do mikroserwisów i jest zła ekstrakcja. Dużo zależy od konkretnego przypadku, ale jak napisałeś ważne jest, żeby zacząć modularyzować monolit i wtedy się okazuje czy faktycznie warto czy nie.

W tym wideo jest bardzo ładnie podsumowane.

2. i 3. zgoda.

[DJ_QBC]

@wargi-sromowe-mniejsze: punkt drugi, jak ja tego nienawidzę!!!!!

[Grubogruby]

@Pit1337: mam tak samo. Może nie tyle, że dopadło mnie wypalenie ale na pewno spadł poziom zainteresowania i motywacji do samokształcenia się w zawodzie.
Ja świra do motoryzacji zamieniłem rok temu na świra w budowanie i latanie dronami FPV. Mniejsze koszta niż motoryzacja, bezpieczniejsze (szczególnie z perspektywy głowy i żywiciela rodzinki) a zarazem fajny mix elektroniki, IT i obróbki wideo, gdzie można się ciągle uczyć nowych fajnych rzeczy.

[filozof900]

@wargi-sromowe-mniejsze: 10+ lat i mam podobne doświadczenia.

idea przepisywania projektu z monolitu na serwisy dla zasady nie ma kompletnie sensu i w moim rozumieniu jest wynikiem braku zrozumienia idei mirkserwisów. funkcjonalność można przenieść do osobnego serwisu kiedy jest ku temu dobry powód, z reguły nie tyle logiczny co finansowy. w firmach zwykle takie rozwiązania proponują ludzie, którzy jedynie czytali o tym na blogach i podoba im się koncepcja, nie myśląc w

[filozof900]

@Pit1337: motywacją są rachunki do opłacenia ;-)

[Roxerood]

Na początku wpisu myślałem, że jakieś kolejne gówno i zarzutka, ale po przeczytaniu stwierzdam, że się zgadzam, mam podbne przemyślenia. Pozdrawiam i czekam na kolejne

[stary_kasztan]

@wargi-sromowe-mniejsze: z twojego posta da się głównie wychwycić że możesz być osobą która jest jeszcze na tym etapie że wydaje się jej że wszystko już wie, bądź po prostu nie pracowałeś w odpowiednio dużych projektach. Pokazujesz też jeden z większych problemów w zarządzaniu architekturą projektów, wybierasz sobie argumenty jakie pasują ci pod tezę i pewnie się przy niej później upierasz. Wmówiłeś sobie że monolit ma więcej zalet niż mikroserwisy, jakieś tam

[s.....y]

@jestem_tunowy ale musiałeś skomentować p0laku xD

[plasq]

@wargi-sromowe-mniejsze no co do mikroserwisów to ta moda już trochę lat trwa, i jak u mnie w korpochłozie powoli migrujemy to szczerze dostrzegam więcej zalet niż wad, także SOA na propsie.

Co do graphqla to się w pełni zgadzam. Kurła, przeforsowali u nas i odnoszę non stop takie wrażenie, że zamiast nas to przyśpieszać to tylko hamuje

[Jacek12]

@Pit1337: Ja pracuję komercyjnie parę lat dłużej i powiem ci że duża robotę robią ciekawe projekty. Czasami robię jakieś gówno to szukam sobie na siłę co innego do roboty, ale często jest tak że żona musi mnie siła z kompa ściągać ( ͡° ͜ʖ ͡°)

[Vite]

@wargi-sromowe-mniejsze: Coraz czesciej widze tematy o "Modular Monolith Architecture", w pracy wszyskie moje nowe projekty sa tak pisane, tylko jeden executable code, prosty debugging, in memory communication, wiec nie musze sie martwic o problemach wynikajacych z obsluga siecia jak w przypadku microservices, software tez jest dostarczany szybciej.

[air_waves]

Ad 1. Te problemy wynikają z prawa Conwaya. Organizacja i architektura się rozjeżdżają, a są ze sobą ściśle powiązane jak czas i przestrzeń.

Ad 2 i 3 pełna zgoda

[dplus2]

@wargi-sromowe-mniejsze: Dodam jeszcze wpychanie przez Javowców Sparka bo nie lubią się ze starym dobrym SQL-em i rozwiązaniami bazodanowymi. Widziałem tyle fail-stories z Glue/Sparkiem siłowo przepychanym przez Javowców, że kosmos.

[wooster]

@damianooo8 co do tego, że Mirko jest takim miejscem, gdzie ludzie z IT się chwalą, to coś w tym jest. nie widziałem za bardzo osób z branży np medycznej, żeby chwaliły się swoimi zarobkami. a tam też są duże pieniądze

[Yahoo_]

Z mojego doświadczenia w 99% przypadków dobrze napisany monolit, najlepiej napisany w podejściu: Loosely Coupled Monolith będzie o wiele korzystniejszym, prostszym i tańszym zarówno w implementacji jak i utrzymaniu rozwiązaniem.

@wargi-sromowe-mniejsze: Z tym się zgodzę do pewnego stopnia. Na pewno bym uznał, że to powinien być default od którego projekt zaczynasz, kiedy jeszcze nie wiesz na ile się rozrośnie itp. Ale to też wymaga duże dyscypliny u programistów, żeby nie łamali

[AdminNeumann]

W kontekście monolitu to podrzucę głośny ostatnio artykuł od PrimeVideo jeśli ktoś jeszcze nie widział https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90 o tym jak udało im się zredukować koszty migrując swój serwis właśnie na monolit

[Ogniste_Jezyki_Sprawiedliwosci]

@wykopowy_brukselek jak najlepiej byłoby zacząć pracę jako tester? obecnie myślę nad kursami jakimiś aby wyrwać się z obecnej pracy