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

104

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?

Sokole Oko
źródło
13
Jeśli A rozmawia z B w monolicie, przynajmniej rzeczywisty interfejs można udowodnić, że jest kompatybilny (przez typowanie statyczne), co zwiększa prawdopodobieństwo, że jest również poprawny. Zwykle mikrousługi komunikują się przez coś bez takich kontroli czasu kompilacji
Richard Tingle
Jeśli badasz problemy związane z korzystaniem z mikrousług, koniecznie przeczytaj artykuł Fowlera. martinfowler.com/articles/microservices.html Uważam, że nie jest to tylko przypadek kompilacji czasu vs środowiska uruchomieniowego, jak powiedział @Richard Tingle. I tak naprawdę nie zgadzam się, że problem z produkcją jest lepszy niż w fazie rozwoju. Ale mikrousługi mogą pomóc w skalowaniu dużych projektów na inne sposoby. (I są przesadą w przypadku większości małych projektów)
Borjab
2
Ten komentator jest krótkowzroczny. Problem w czasie wykonywania => problemy z produkcją => niezadowoleni użytkownicy => stracone pieniądze.
Philipp
@Philipp: Właśnie o to chodzi. Problemy z czasem kompilacji spowodowane zaburzeniami organizacyjnymi => nikogo to nie obchodzi. Utrata pieniędzy spowodowana dysfunkcją organizacyjną => boli dokładnie tych, którzy są odpowiedzialni za wspomnianą dysfunkcję organizacyjną. Nadzieja: dysfunkcja organizacyjna zostaje naprawiona szybciej.
Jörg W Mittag,

Odpowiedzi:

194

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.

amon
źródło
13
@JacquesB Jestem przekonany, że „dysfunkcja organizacyjna” odnosi się do niemożności opracowania systemu. Większość mojej odpowiedzi to kontekst ilustrujący, w jaki sposób można dojść do takiego wniosku, ale to moja profesjonalna opinia, która nie została zaczerpnięta z tweeta.
amon
10
„monolit, który jest czysto podzielony na części” - co to do diabła znaczy?
10
Nie mówiąc już o wersjonowaniu interfejsów (interfejsy zmieniają się z czasem).
Peter Mortensen
12
@mobileink Monolith nie jest tu idealnym terminem, ponieważ sugeruje „brak architektury”. Ale to, co próbuję przekazać, to system opracowany i wdrożony jako pojedynczy system, w przeciwieństwie do architektury zorientowanej na usługi, w której części systemu mogą być wdrażane niezależnie. Proszę edytować post, jeśli znasz lepszy termin ...
Amon
7
@amon Słysząc słowo Monolith, nie od razu przywołuje pojęcie „bez architektury”. Większość budynków to Monolity, podobnie jak Wielkie Piramidy w Egipcie i wiele innych przedmiotów. Najwyraźniej zostały one zaprojektowane i dostarczone jako całość. Wiele systemów oprogramowania nie ma dobrej architektury; ale brak dobrej architektury wydaje się być niezależny od sposobu ich rozmieszczenia. Możesz pożyczyć część rusztowania innego projektu i nazwać go architekturą (3-poziomowa, 2-poziomowa, n-poziomowa, mikrousługowa itp.), Ale robienie tego nie gwarantuje, że zrobiłeś to dobrze.
Edwin Buck
215

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.

Paul Stovell
źródło
67
+1. Jest to o wiele lepsze jako odpowiedź Stack Exchange niż jako tweet. :-)
ruakh
3
To samo dotyczy wszystkich systemów dynamicznych. Pisanie dynamiczne jest bardzo przydatne, ale tylko wtedy, gdy masz odpowiednie osoby. „Dowolne bazy danych” są bardzo przydatne, ale tylko wtedy, gdy masz odpowiednie osoby. Jeśli nie masz odpowiednich ludzi, po prostu delegujesz problemy, a nie je rozwiązujesz.
Luaan
2
Myślę, że to tautologia. Gdy ludzie stanowią problem, problemy mogą objawiać się wszędzie. Nie wyobrażam sobie dostarczenia rozwiązania działającego jako zestaw mikrousług bez odpowiednich testów integracji. W takim przypadku nie ma możliwości wysyłki rozwiązania z obsługiwanym przepływem roboczym. Jeśli ktoś przejdzie do mikrousług bez testowania przepływu, zwłaszcza w celu ukrycia problemów, są one problemem. Równie dobrze może wysyłać niesprawdzone / uszkodzone pliki binarne. Podnosi problem od programistów na poziomie żołnierzy wyżej, do których należy.
luk32
10
@ luk32 Częściowo tak, ale istotą mikrousług, które sprawiają, że jest atrakcyjna dla złych drużyn, jest to, że sprawiasz, że twój deficyt umiejętności i komunikacji pozostaje niezauważony przez dłuższy okres czasu. Nie chodzi o to, czy masz problemy, czy nie, chodzi o to, kiedy się pojawią
T. Sar,
18
Bardzo miła odpowiedź. Dzięki za potwierdzenie mojej opinii o Twitterze jako całkowicie bezużytecznej do niczego poza podburzaniem ludzi.
Robert Harvey
43

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.

Jörg W Mittag
źródło
6
@Michael Jeśli nie widzisz, jak wpływają one na jakość kodu, być może zastanów się, jaki wpływ - jeśli w ogóle - ma zarząd na jakąkolwiek część jakości produktów, które tworzy ich firma.
wjl
30
@Michael: Wszystko jest ostatecznie spowodowane zarządzaniem wyższego poziomu. Czy niska jakość kodu jest spowodowana niemożliwymi terminami? Kto wyznacza te terminy? Kto mówi tym, którzy wyznaczają te terminy, aby wyznaczyli te terminy? Czy niska jakość kodu jest powodowana przez niekompetentnych programistów? Kto zatrudnił tych niekompetentnych programistów? Kto zatrudnił tych, którzy zatrudniali niekompetentnych programistów? Czy jest to spowodowane nieodpowiednim oprzyrządowaniem? Kto kupuje te narzędzia? Kto zatwierdza budżet na zakup tych narzędzi? Jest to spowodowane głupią architekturą? Kto zatrudnił architekta? Kto postawił go na czele? Tweety te były szczególnie w kontekście ...
Jörg W Mittag
13
… Dysfunkcja organizacyjna. Cóż, dzięki funkcji organizacji jest dość dużo zadanie zarządzania wyższego poziomu. Tym właśnie jest zarządzanie .
Jörg W Mittag
4
Chociaż prawdopodobnie będzie to działało w perspektywie długoterminowej, pomysł rozwiązania problemów Twojej firmy poprzez wywarcie wpływu na klientów wydaje się niewłaściwy.
Stijn de Witt
1
@ JörgWMittag Nie sądzę, aby uzasadnione było twierdzenie, że zły kod napisany przez złych programistów jest winą ludzi, którzy wynajęli tych złych programistów, a nie samych złych programistów. Ostatecznie może to być odpowiedzialność zarządzania, ale jest to spowodowane przez programistów.
Miles Rout
9

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.

Kilian Foth
źródło
9
Wydaje się, że zakłada się, że aplikacje „monolityczne” są zawsze typowane statycznie. Co z dynamicznie pisanymi językami? A co ze statycznie wpisanymi interfejsami serwisowymi?
JacquesB
1
@JacquesB OTOH, mogę wymyślić dokładnie zero dynamicznie typowanych skompilowanych języków.
immibis
2
@JacquesB JavaScript i Python nie są kompilowane. Chyba że weźmiesz pod uwagę struktury interpretera wewnętrznego jako cel kompilacji, w którym to przypadku kompilowany jest każdy język .
immibis
3
@immibis: każda obecnie istniejąca implementacja ECMAScript ma co najmniej jeden kompilator. Na przykład V8 ma dwa kompilatory i dokładnie zero interpretatorów, nigdy nie interpretuje, zawsze kompiluje do binarnego natywnego kodu maszynowego. SpiderMonkey ma cztery kompilatory, jak sądzę, i jeden tłumacz, ale ten tłumacz nie interpretuje ECMAScript. SpiderMonkey nigdy nie interpretuje ECMAScript, zawsze najpierw kompiluje go do kodu bajtowego SpiderMonkey, który następnie może skompilować do binarnego natywnego kodu maszynowego. Wszystkie obecnie istniejące implementacje Python, Ruby i PHP mają kompilatory.
Jörg W Mittag
12
@LieRyan Jesteś poważnie zdezorientowany, jeśli uważasz, że wnioskowanie jest takie samo jak pisanie dynamiczne i / lub że Haskell jest dynamicznie wpisywany.
Derek Elkins
2

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.

bernie
źródło