Читать книгу Mikroserwisy. Wzorce z przykładami w języku Java - Chris Richardson - Страница 46
1.6.1. Architektura mikroserwisowa nie jest złotym środkiem
ОглавлениеW 1986 r. Fred Brooks, autor The Mythical Man-Month (Addison-Wesley Professional, 1995), powiedział, że w inżynierii oprogramowania nie ma złotych środków. Oznacza to, że nie ma żadnych technik ani technologii, które zwiększyłyby, gdyby zostały zastosowane, wielokrotnie wydajność. Jednak kilkadziesiąt lat później programiści wciąż kłócą się o swoje ulubione złote środki, będąc absolutnie przekonani, że ich ulubiona technologia zapewni im znaczny wzrost wydajności.
Wiele argumentacji jest związanych z dwudzielnością do bani/czadowe (http://nealford.com/memeagora/2009/08/05/suck-rock-dichotomy.html), terminem ukutym przez Neala Forda, który opisuje, jak wszystko w świecie oprogramowania jest albo do bani, albo czadowe, bez żadnych kompromisów. Argumenty te mają następującą strukturę: jeśli wykonasz X, to wtedy twój pupil zdechnie, więc musisz zrobić Y. Na przykład programowanie synchroniczne kontra reaktywne, obiektowe kontra funkcjonalne, Java kontra JavaScript, REST kontra komunikaty. Oczywiście w rzeczywistości jest znacznie więcej niuansów. Każda technologia ma wady i ograniczenia, które są często pomijane przez jej zwolenników. W rezultacie przyjęcie technologii zwykle przebiega zgodnie z cyklem szumu Gartnera (https://en.wikipedia.org/wiki/Hype_cycle), w którym powstająca technologia przechodzi przez pięć faz, w tym szczyt zawyżonych oczekiwań (czadowe), następnie małe rozczarowanie (to jest do bani) i kończące się płaskowyżem produktywności (teraz rozumiemy kompromisy i wiemy, kiedy z nich korzystać).
Mikroserwisy nie są odporne na zjawisko złotego środka. To, czy ta architektura jest odpowiednia dla naszej aplikacji, zależy od wielu czynników. W związku z tym doradzanie, aby zawsze korzystać z architektury mikroserwisowej, jest złe, ale równie złe jest doradzanie, aby nigdy jej nie używać. Tak jak w przypadku wielu rzeczy, to zależy.
Podstawowym powodem tych spolaryzowanych i przesadzonych argumentów na temat technologii jest to, że ludzie kierują się przede wszystkim swoimi emocjami. Jonathan Haidt w swojej doskonałej książce The Righteous Mind: Why Good People Divided by Politics and Religion (Vintage, 2013) posługuje się metaforą słonia i jego jeźdźca, aby opisać, jak działa ludzki umysł. Słoń reprezentuje część emocjonalną ludzkiego mózgu. Podejmuje większość decyzji. Jeździec reprezentuje racjonalną część mózgu. Czasami może wpływać na słonia, ale przede wszystkim zapewnia uzasadnienie decyzji słonia.
My, społeczność programistów, musimy przezwyciężyć naszą emocjonalną naturę i znaleźć lepszy sposób na dyskutowanie i stosowanie technologii. Świetnym sposobem na dyskutowanie i opisywanie technologii jest użycie formatu wzorca, ponieważ jest on obiektywny. Opisując technologię w postaci wzorca, należy na przykład opisać wady. Rzućmy okiem na postać wzorca.