W jaki sposób przejście do mikrousług powoduje problem w czasie wykonywania?

Następujący komentator pisze :

Mikrousługi przenoszą dysfunkcję organizacyjną z problemu kompilacji na problem czasu wykonywania.

Ten komentator rozwija problem, mówiąc:

Funkcja nie jest błędem. Problem w czasie wykonywania => problemy z produkcją => silniejsze, szybsze informacje zwrotne na temat dysfunkcji dla osób odpowiedzialnych

Teraz rozumiem to dzięki mikrousługom :

• potencjalnie zwiększyć opóźnienie produkcji - co jest problemem związanym z produkcją i czasem pracy.
• zwiększ liczbę „interfejsów sieciowych” w kodzie, w których mogą wystąpić potencjalne błędy przetwarzania podczas przetwarzania.
• może potencjalnie wykonywać wdrożenia niebiesko-zielone. Mogą one zostać zatrzymane przez niedopasowanie interfejsu (patrz interfejsy sieciowe). Ale jeśli wdrożenia niebiesko-zielone działają, jest to bardziej problem w czasie wykonywania.

Moje pytanie brzmi: co to znaczy, że przejście do mikrousług powoduje problem w czasie wykonywania?

Mam problem. Użyjmy Microservices! Teraz mam 13 rozproszonych problemów.

Dobrym pomysłem jest podzielenie systemu na elementy zamknięte, spójne i odsprzęgnięte. Pozwala rozwiązać osobno różne problemy. Ale możesz to zrobić doskonale w monolitycznym wdrożeniu (patrz Fowler: Microservice Premium ). W końcu tego właśnie naucza OOP od wielu dziesięcioleci! Jeśli zdecydujesz się zamienić komponenty w mikrousługi, nie zyskasz żadnej przewagi architektonicznej. Zyskujesz pewną elastyczność w zakresie wyboru technologii i być może (ale niekoniecznie!) Pewną skalowalność. Ale masz gwarancję pewnego bólu głowy wynikającego z (a) rozproszonego charakteru systemu i (b) komunikacji między komponentami. Wybór mikrousług oznacza, że ​​masz inne problemy, które są tak naglące, że mimo tych problemów jesteś gotów korzystać z mikrousług.

Jeśli nie jesteś w stanie zaprojektować monolitu, który jest czysto podzielony na komponenty, nie będziesz w stanie zaprojektować systemu mikrousług. W bazie kodu monolitycznego ból będzie dość oczywisty. W idealnym przypadku kod po prostu nie skompiluje się, jeśli zostanie okropnie uszkodzony. Jednak w przypadku mikrousług każda usługa może być opracowywana osobno, być może nawet w różnych językach. Wszelkie problemy w interakcjach komponentów nie staną się widoczne, dopóki nie zintegrujesz komponentów, a w tym momencie jest już za późno, aby naprawić ogólną architekturę.

Źródłem błędów nr 1 jest niedopasowanie interfejsu. Mogą występować rażące błędy, takie jak brakujący parametr, lub bardziej subtelne przykłady, takie jak zapomnienie o sprawdzeniu kodu błędu lub zapomnienie o sprawdzeniu warunku wstępnego przed wywołaniem metody. Pisanie statyczne wykrywa takie problemy jak najwcześniej: w twoim IDE i kompilatorze, zanim kod zostanie uruchomiony. Dynamiczne systemy nie mają tego luksusu. Nie wybuchnie, dopóki ten błędny kod nie zostanie wykonany.

Implikacje dla mikrousług są przerażające. Mikrousługi są z natury dynamiczne. O ile nie przejdziesz do formalnego języka opisu usługi, nie możesz zweryfikować żadnej poprawności użycia interfejsu. musisz przetestować, przetestować, przetestować! Ale testy są drogie i zwykle nie wyczerpujące, co pozostawia możliwość, że problemy mogą nadal występować w produkcji. Kiedy ten problem stanie się widoczny? Tylko wtedy, gdy ta wadliwa ścieżka zostanie podjęta w czasie produkcji. Pojęcie, że problemy z produkcją doprowadziłyby do szybszej informacji zwrotnej, jestprzezabawnie niebezpiecznie źle, chyba że jesteś rozbawiony możliwością utraty danych.

Pierwszy tweet był mój, więc rozwinę go:

Załóżmy, że masz 100 programistów pracujących nad aplikacją monolityczną. To zbyt wiele osób, aby skutecznie komunikować się między sobą, dlatego firma musi ciężko pracować, aby podzielić ich na mniejsze zespoły i stworzyć dobre wzorce komunikacji między nimi. Kiedy organizacja jest „dysfunkcjonalna”, zespoły prawdopodobnie ze sobą nie rozmawiają, nie są dostosowane do większego celu, nie zgadzają się co do priorytetów itp. - w rezultacie potrzeba im wieczności, aby coś wysłać. Jest to „problem z czasem kompilacji” w tym sensie, że dysfunkcja jest oczywista przed wyprodukowaniem oprogramowania. Projekt jest prawdopodobnie marszem śmierci lub nigdy nie zostanie wysłany („kompilacja”).

Myślę, że wiele osób pociąga mikro usługi i przenoszą się do nich nie z powodu nieodłącznych korzyści technicznych / architektonicznych, ale dlatego, że pozwala im to zignorować dysfunkcję organizacyjną. Zamiast próbować wyrównać 100 programistów, mają nadzieję, że mogą mieć małe zespoły pracujące w silosach, z których każdy skoncentruje się na własnej małej usłudze mikro. Jeśli jesteś w tak dysfunkcyjnej organizacji, jest to tak atrakcyjne: daje ci znacznie większe pozwolenie na unikanie ludzi, których nie lubisz, na brak komunikacji.

Niestety staje się to „problemem w czasie wykonywania”, ponieważ gdy oprogramowanie działa w środowisku produkcyjnym, dobra komunikacja staje się równie ważna. Problemy z organizacją - zespoły oraz sposób, w jaki są dostosowane i komunikują się - ujawniają się w „czasie wykonywania”.

Celem mojego tweeta było: jeśli masz problem z ludźmi , nowa architektura nie pomoże. To tylko opóźni skutki problemu. Myślę, że atrakcyjność mikrousług dla wielu ludzi jest nadzieją, że magicznie rozwiąże te problemy.

Moje pytanie brzmi: co to znaczy, że przejście do mikrousług powoduje problem w czasie wykonywania?

To jest nie to, co te tweety mówią! Nie mówią nic o przejściu na mikrousługi , ani nie mówią o tworzeniu problemów. Mówią tylko o problemach ze zmianą biegów .

I nakładają kontekstowe ograniczenie na swoje twierdzenia, a mianowicie, że twoja organizacja jest dysfunkcyjna.

Tak więc to, co w zasadzie mówi pierwszy tweet, to dwie rzeczy:

• „jeśli Twoja organizacja nie jest w stanie teraz tworzyć złożonych systemów bez mikrousług, magicznie nie będzie w stanie zaprojektować złożonych systemów za pomocą mikrousług”
• „problemy spowodowane tą niezdolnością, które pojawiają się teraz podczas kompilacji, tj. podczas programowania, pojawią się w czasie wykonywania, tj. podczas produkcji” (technicznie rzecz biorąc, mogą się również pojawić podczas testowania, ale pamiętaj, że cytat ogranicza się organizacjom dysfunkcyjnym, które prawdopodobnie mają nietypowy system testów)

Sekund tweet mówi, że fakt, że problemy tylko objawiają się w produkcji, czyli gdzie klienci je zobaczyć, to cecha, a nie błąd, bo gdy klienci skarżą się, że ma tendencję do bycia wysłuchanym w różnych miejscach, niż wtedy, gdy przerwy budować, a mianowicie w miejscach, które są w stanie coś zrobić z dysfunkcją organizacyjną (np. zarządzanie na wysokim szczeblu). Ponieważ dysfunkcja organizacyjna zwykle jest porażką kierownictwa wysokiego poziomu, oznacza to, że niezadowoleni klienci źle odbijają się na tych, którzy są ostatecznie odpowiedzialni za to niezadowolenie, podczas gdy niska jakość kodu spowodowana awariami zarządzania wyższego poziomu zwykle odbija się źle na deweloperach, którzy są jednak nie jest to wina i nie można nic z tym zrobić.

Tak więc, pierwszy tweet mówi, że mikrousługi przenoszą problemy spowodowane złym zarządzaniem z czasu kompilacji, gdzie widzą je tylko programiści, do czasu wykonywania, w którym widzą je klienci. Drugi tweet mówi, że to dobra rzecz, ponieważ wtedy problemy boli tych, którzy są za nie odpowiedzialni.

Tworzy problem w czasie wykonywania, w przeciwieństwie do problemu w czasie kompilacji .

Monolityczna aplikacja jest trudna i kosztowna w kompilacji. Ale kiedy się skompiluje, możesz być całkiem pewny, że nie ma żadnych wyjątkowo głupich niezgodności między składnikami, ponieważ system typów może je złapać. Ten sam błąd w systemie mikrousług może się nie pojawić, dopóki dwa określone składniki nie będą oddziaływać w określony sposób.

Zarówno w systemach monolitycznych, jak i mikrousługach należy zdefiniować interfejsy między podsystemami. Interfejsy powinny być dobrze zaprojektowane, dobrze udokumentowane i możliwie stabilne. To jest tak samo jak w OOP.

Jeśli Twoja organizacja nie jest w stanie tego zrobić, mikrousługi również nie rozwiążą problemu. W mikrousługach masz publiczne interfejsy sieciowe. Musisz więc poświęcić więcej wysiłku na zaprojektowanie interfejsu.

Jeśli interfejs nie zostanie poprawnie zaprojektowany, pojawią się dwa rodzaje problemów w czasie wykonywania:

1. Jeśli interfejs nie jest używany poprawnie, pojawi się błąd w czasie wykonywania, a nie w czasie kompilacji.
2. Wywołanie interfejsu internetowego jest dość wolne, więc możesz mieć problemy z wydajnością.

Myślę, że tworzenie problemów w czasie wykonywania nie jest właściwym sposobem komunikowania problemów organizacyjnych tym, którzy są za nie odpowiedzialni.