И как избежать неэффективных возражений.

В последних обменах опытом члены факультета тщетно пытались атаковать других специалистов по Computer Science, пренебрегая их работой. Откровенно говоря, я считаю, что результаты весьма неловкие вместо того, чтобы опустить противника вниз, многие из замечаний были смехотворно безобидны. Что-то должно было быть сделано, потому что посторонний человек, услышавший такую болтовню будет плохо думать о нашей кафедре: ни одна группа не может уважать другую, если ее члены не могут нанести сокрушительный удар в словесной перепалке.

Этот короткий очерк был сделан, чтобы помочь факультету делать замечания острее и помочь избежать малодушных мстителей. Он объясняет, как можно опустить CS исследования и показывает, где найти ахиллесову пяту в любом проекте, а также, чем можно уколоть исследователя.

Два основных типа исследований

Большинство паршивых оскорблений возникают просто из неверного впечатления, что все исследователи согласны на общие цели CS исследования. Нет. В частности, CS унаследовал два совершенно противоположных подхода от областей математики и инженерии.

Исследователи, которые следуют математической парадигме, называются теоретики, и включают в себя тех, кто работает в области, которая обязательно имеет анализ, оценки, алгоритмы или теорию в своем названии.

Исследователи, которые следуют инженерной парадигме, называются экспериментаторы и включают в себя большинство людей, работающих в областях, которые имеют экспериментальный, системы, компилятор, сети или базы данных в своем названии.

Комплексная теория и простые Системы

Знайте традиции, из которых исследователь создаёт основу для меткого оскорбления.

Теоретики предпочитают мудрёность
Как и математиков, теоретиков в области Computer Science берет наибольшая гордость, когда они знают и используют самую современную математику, чтобы решить проблемы. Например, теоретики загораются при рассказе вам, что они обнаружили как неясная теорема из геометрии может быть использована в анализе компьютерного алгоритма. Теоретики сосредоточились на математическом анализе и асимптотике вычислений; они гордятся красотой уравнений и не беспокоиться о постоянных. Хотя они, как правило, и отмечают, что их результаты имеют отношение к реальным компьютерам, втайне они мечтают о впечатляющих математиках.

Экспериментаторы предпочитают простоту

Как и инженеры, исследователи систем гордятся тем, что смогли придумать простейшую систему, которая предлагает данный уровень функциональности. Например, исследователи системы загораются, рассказывая вам, что они построили систему, которая в два раза быстрее, в два раза меньше и более мощная, чем её предшественница. Экспериментаторы сосредотачиваются на производительности реальных компьютерных систем; они гордятся красотой своего кода и беспокоятся о постоянных. Хотя, они, как правило, и отмечают, что их результаты могут выходить за пределы реальных компьютеров, они тайно мечтают о регистрации патентов, которые относятся к сохранившемуся оборудованию.

Оскорбление

Знание того, что CS могут быть разделены на две основные группы очень помогает, когда кто-то начинает свою критику. Есть два основных правила: определить тип исследователя и придумать оскорбление для этого типа. Избегайте говорить что-либо, что невольно дополняет их. Если всё будет сделано правильно, оскорбление не только оглушает исследователя (который будет в шоке, узнав, что не все согласны с его или её основной системой ценностей), но также запугает других в аудитории.

Идентифицируем Тип

Определить тип исследователя, как правило, легко, и это не требует особой технической подготовки или реального мышления. Это может быть сделано с помощью сопоставления ключевых слов в соответствии со следующими списками.

Обнаруживаем Теорию

Вы можете смело сказать, что кто-то является теоретиком, если он употребляет одно или более из следующих ключевых слов и фраз в лекциях и технических беседах: теорема, лемма, доказательство, аксиомы, за полиномиальное время, логарифмическая, семантика, численное, сложность, недетерминированный или недетерминизм и на достаточно большом N. Они пишут много уравнений, хвастаются сбиванием дополнительного лог фактора, и часто заканчивают свою лекцию заглавной О с последующим математическим выражением в круглых скобках. Вы также можете легко узнать теоретика, потому что они всегда берутся что-то доказать, что может показаться довольно очевидным. (Я когда-то сидел час на лекции, где кто-то доказал, что после выполнения компьютером оператор присваивания, которые ставят целое 1 в переменную х, значение х было 1.)

Обнаруживаем Системы

Экспериментатор будет употреблять одно или более из следующих ключевых слов и фраз в лекциях и технических беседах: архитектура память процессор (иногда аббревиатурами CISC или RISC ), I/O или автобус, сеть, интерфейс, виртуальная, компилировать или компилятор, ОС или система, распространяется, программа или код и двоичный. Они говорят о строительстве программы и запуске полученной системы на реальных компьютерных системах. Они отсылают вас к компании и продукции, а также используют аббревиатуры либерально. Их лекции часто заканчиваются графиком или диаграммом, измеряемой производительность системы. Вы также можете узнать экспериментатора, потому что он описывает в мельчайших деталях, как они поставили эксперимент для измерения определенного значения, даже если измерение производится именно по ожидаемым результатам. (Я когда-то сидел час на лекции, где кто-то тщательно объяснил, как они использовали три компьютерные системы для измерения сетевого трафика, когда их цель была просто показать, что сеть не была причиной проблемы, которую они расследуют.)

Придумываем Оскорбления

Ключ к хорошему оскорблению лежит в нападении на то, что все исследователи считают самым дорогим и сделают все, чтобы избежать волнения. Таким образом, оскорбление теоретика должно сосредоточиться на провале сложной математики, например:

• Несмотря на все уравнения, мне кажется, что ваша работа не требует какой-либо реальной математической изощренности. Разве я что-то упустил? (Это особенно хорошая уловка, если вы признаете, что это было легко, и вы понимаете весь разговор)
• Не является ли это простым прямым расширением старого результата Хартманис? (Даже Хартманис не помнит всех доказанных теорем Хартманиса, но все остальные решат, что вы помните, то, что они забыли.)
• Может я что-то упустил? Можете ли вы определить како-либо глубокое математическое содержание в этой работе? (Опять же, зрители, которые считают что разговор труднопонятным, не захотят в этом признаться.)

В отличие от этого, оскорбление экспериментаторов должно подразумевать, что методы были использованы в предыдущих системах, или что работа не является практичной, например:

• Не делалосьли это несколько лет назад в Xerox PARC? (Никто не помнит, что было на самом деле сделано в PARC, но все решат, что вы помните, то, что они забыли.)
• Вы проверили это на чипе, который Intel запустил на прошлой неделе в своей лаборатории? (Никто не знает, какой чип Intel получил для работы на прошлой неделе, но все решат, что вы знаете.)
• Я что-то упустил? Разве не очевидно, что есть узкое место в системе, которое предотвращает масштабирование для произвольного размера? (Это безопасное изречение, потому что в каждой системе есть узкое место, что предотвращает произвольное масштабирование).

Как избежать ответного оскорбления в свой адрес

Неуместное оскорбление может иметь неприятные последствия, превращаясь в смущение для нападающего и в победу для предполагаемой жертвы. Чтобы избежать подобных случаев, помните следующее:

• Никогда не пытайтесь атаковать теоретическую работу, которая не рассматривает констант как несвязаный с реальными компьютерными системами или как требующий слишком много сложной математики. (Предполагаемая жертва, скорее всего, улыбнется и скажет спасибо за лесть.)
• Никогда не пытайтесь атаковать систему, которая слишком мала, слишком проста, или в котиорой не хватает сложной математики (Опять же, предполагаемая жертва, скорее всего, улыбнется и скажет спасибо за лесть.)
• Никогда не пытайтесь атаковать системы, про которые говорят, что они работают так просто и очевидно, что вы могли бы сделать это и сами. (В течение многих лет люди говорили это о UNIX и протоколах TCP/IP). В самом деле, это всего лишь расширение уловки, которое используется детьми на детской площадке: О, да? Я мог бы сделать это если б захотел Не пытайтесь использовать это или кто-то скажет, что Вам нужно повзрослеть.

Атака на смешанную работу

Хотя и редко, но немногие исследователи включают как теоретическую, так и экспериментальную работу в один проект. Оскорбление такой комбинации может быть сложным, потому что исследователь может остаться невредимым, указывая в ответ то на одну часть своей работы, то на другую. Вы можете попробовать атаковать обе части одновременно:

• Хочу отметить, что аспект системы этого проекта кажется довольно сложным. Как Вы думаете, причину запутанной реализации можно отнести к более или менее упрощенному математическому анализу, который вы использовали?

Тем не менее, умное оскорбление может избежать разговора о работе, предлагая зловещие причины для смены парадигмы:

• Я заметил, что Вы сделали нечто необычное, сочетая теорию и практику. Вы решили испробовать второй подход, потому что получили недостаточные результаты от первого?
• Вы, кажется, объединили в один проект немного теории и немного практики. Не правда ли, что если бы вы внесли достаточно большой вклад и в одну и в другую часть, то вы бы вели лекции о них по отдельности?

Заключительное Слово

Я, конечно, надеюсь, что факультет примет эту статью близко к сердцу и будет оттачивать свои навыки в оскорблениях. В будущем, пожалуйста, рассчитывайте все ваши нападки.

Недавно я прочитал статью c критикой Rust. Хотя в ней было много правильных вещей, она мне не понравилось слишком многое там очень спорно. В целом, я вообще не могу рекомендовать к прочтению никакой статьи с критикой Rust. Это нехорошо, ведь важно обсуждать недостатки, а шельмование низкокачественной и неумелой критики, к сожалению, заставляет пропустить мимо внимания действительно хорошие аргументы.

Итак, попробую привести аргументы против Rust.

Не всё программирование является системным

Rust язык системного программирования. Он обеспечивает точный контроль над компоновкой данных и поведением кода во время выполнения, обеспечивая максимальную производительность и гибкость. В отличие от других языков системного программирования, он также обеспечивает безопасность памяти глючные программы завершаются чётко определенным образом, не допуская (потенциально опасное) неопределённого поведения.

Однако в большинстве случаев не требуется абсолютная производительность или контроль над аппаратными ресурсами. Для этих ситуаций современные управляемые языки, такие как Kotlin или Go, обеспечивают приличную скорость, завидную производительность и безопасность памяти благодаря использованию сборщика мусора с динамическим управлением памятью.

Сложность

Время программиста дорого стоит, а в случае Rust придётся потратить много времени на изучение самого языка. Сообщество приложило немало сил для создания высококачественных учебных материалов, но язык очень большой. Даже если вам выгодно переписать проект на Rust, само изучение языка может оказаться слишком дорогим.

Цена за улучшенный контроль это проклятие выбора:

struct Foo     { bar: Bar         }struct Foo<'a> { bar: &'a Bar     }struct Foo<'a> { bar: &'a mut Bar }struct Foo     { bar: Box<Bar>    }struct Foo     { bar: Rc<Bar>     }struct Foo     { bar: Arc<Bar>    }

В Kotlin вы пишете класс Foo(val bar: Bar) и приступаете к решению задачи. В Rust нужно сделать выбор, иногда достаточно важный, со специальным синтаксисом.

Вся эта сложность не просто так мы не знаем, как создать более простой и безопасный для памяти язык низкого уровня. Но не для каждой задачи нужен низкоуровневый язык.

См. также презентацию Почему C++ держится на плаву, когда корабль Ваза затонул.

Время компиляции

Время компиляции это универсальный фактор. Если программа на каком-то языке медленно запускается, но этот язык позволяет быструю компиляцию, то у программиста будет больше времени для оптимизации, чтобы ускорить запуск программы!

В дилемме дженериков Rust намеренно выбрал медленные компиляторы. В этом есть определённый смысл (рантайм действительно ускоряется), но вам придётся всеми силами бороться за разумное время сборки в более крупных проектах.

rustc реализует, вероятно, самый продвинутый алгоритм инкрементной компиляции в продакшн-компиляторах, но это немного похоже на борьбу с встроенной в язык моделью компиляции.

В отличие от C++, сборка Rust не распараллеливается до предела, количество параллельных процессов ограничено длиной критического пути в графе зависимостей. Разница будет заметна, если у вас больше 40 ядер для компиляции.

В Rust также нет аналогов для идиомы pimpl, так что изменение крейта требует перекомпиляции (а не просто перелинковки) всех его обратных зависимостей.

Зрелость

Пять лет это определённо малый срок, так что Rust молодой язык. Хотя будущее кажется блестящим, но всё-таки более вероятно, что через десять лет мы будем программировать на С, а не на Rust (см. эффект Линди). Если вы пишете софт на десятилетия, то должны серьёзно рассмотреть риски, связанные с выбором новых технологий (хотя выбор Java вместо Cobol для банковского программного обеспечения в 90-е годы ретроспективно оказался правильным выбором).

Есть только одна полная реализация Rust компилятор rustc. Наиболее продвинутая альтернативная реализация mrustc целенаправленно пропускает многие статические проверки безопасности. На данный момент rustc поддерживает только один продакшн-ready бэкенд LLVM. Следовательно, поддержка процессорных архитектур здесь более узкая, чем у C, у которого есть реализация GCC, а также поддержка ряда проприетарных компиляторов, специфичных для конкретных вендоров.

Наконец, у Rust нет официальной спецификации. Текущая спецификация не завершена и не документирует некоторые мелкие детали реализации.

Альтернативы

Кроме Rust, для системного программирования есть и другие языки, в том числе C, C++ и Ada.

Современный C++ предоставляет инструменты и рекомендации для повышения безопасности. Есть даже предложение о безопасности времени жизни объектов в стиле Rust! В отличие от Rust, использование этих инструментов не гарантирует отсутствие проблем с безопасностью памяти. Но если вы уже поддерживаете большой объём кода C++, имеет смысл проверить, возможно, следование рекомендациям и использование санитайзеров поможет в решении проблем безопасности. Это трудно, но явно легче, чем переписывать весь код на другом языке!

Если вы используете C, то можете применить формальные методы, чтобы доказать отсутствие неопределённого поведения, или просто тщательно всё протестировать.

Ada безопасна для памяти, если не использовать динамическую память (никогда не вызывайте free).

Rust интересный язык по соотношению затрат к безопасности, но далеко не единственный!

Набор инструментов

Инструменты Rust не назовёшь идеальными. Базовый инструментарий, компилятор и система сборки (cargo) часто называют лучшими в своём классе.

Но, например, некоторые инструменты, связанные со средой выполнения (в первую очередь, для профилирования кучи), просто отсутствуют трудно размышлять о рантайме, если инструмента просто нет! Кроме того, поддержка IDE тоже далеко не соответствует уровню надёжности Java. На Rust просто невозможен автоматизированный сложный рефакторинг программы с миллионами строк.

Интеграция

Что бы ни обещал Rust, но сегодняшний мир системного программирования говорит на C и C++. Rust намеренно не пытается имитировать эти языки он не использует классы в стиле C++ или C ABI.

Это означает, что между мирами нужно наводить мосты. Интеграция не будет бесшовной, она небезопасна, не всегда обойдётся без затрат и требует синхронизации между языками. В то время как местами интеграция работает и инструментарий сближается, на этом пути возникают случайные препятствия из-за общей сложности.

Одна из специфических проблем заключается в том, что самоуверенное мировоззрение Cargo (великолепное для чистых проектов Rust) может затруднить интеграцию с более крупными системами сборки.

Производительность

Использование LLVM не является универсальным решением всех проблем производительности. Хотя я не знаю бенчмарков, сравнивающих производительность C++ и Rust в целом, но нетрудно придумать задачи, где Rust уступает C++.

Вероятно, самая большая проблема в том, что семантика перемещения Rust основана на значениях (memcpy на уровне машинного кода). С другой стороны, семантика C++ использует специальные ссылки, из которых можно взять данные (указатели на уровне машинного кода). Теоретически, компилятор должен видеть цепочку копий, на практике это часто не так: #57077. Связанная с этим проблема заключается в отсутствии размещения новых данных Rust иногда нужно копировать байты в/из стека, в то время как C++ может создать объект на месте.

Несколько забавно, что в дефолтный Rust ABI (в котором пожертвовали стабильностью ради эффективности) иногда работает хуже, чем у C: #26494.

Наконец, хотя теоретически код Rust должен быть более эффективным из-за значительно более богатой информации об алиасах, включение оптимизации, связанной с алиасами, вызывает ошибки LLVM и некорректную компиляцию: #54878.

Но, повторюсь, это редкие примеры, иногда сравнение происходит в другую сторону. Например, в Box у Rust нет проблемы производительности, какая есть у std::unique_ptr.

Потенциально более серьёзная проблема заключается в том, что Rust с его определениями дженериков менее выразителен, чем C++. Таким образом, некоторые шаблонные трюки C++ для высокой производительности не могут быть выражены в Rust с помощью хорошего синтаксиса.

Значение unsafe

Возможно, идея unsafe даже более важна для Rust, чем владение и заимствование. Выделяя все опасные операции в блоки unsafe и функции и настаивая на предоставлении им безопасного интерфейса более высокого уровня, можно создать систему, которая одновременно:

1. надёжная (не отмеченный unsafe код не может вызвать неопределённое поведение),
   
2. модульная (различные небезопасные блоки можно проверить отдельно).

Вполне очевидно, что так оно и есть: фаззинг кода Rust находит панику, но не переполнения буфера.

Но теоретические перспективы не столь радужны.

Во-первых, нет определения модели памяти Rust, поэтому невозможно формально проверить, является ли данный небезопасный блок допустимым или нет. Существует неофициальное определение вещей, которые rustc делает или на которые может полагаться и продолжается работа над верификатором рантайма, но фактическая модель не ясна. Таким образом, где-то может быть какой-то небезопасный код, который сегодня работает нормально, а завтра будет объявлен недействительным и сломается в новой оптимизации компилятора через год.

Во-вторых, есть мнение, что блоки unsafe на самом деле не являются модульными. Достаточно мощные блоки unsafe могут, по сути, расширить язык. Два таких расширения не делают ничего плохого в изоляции друг от друга, но приводят к неопределённому поведению при одновременном использовании: см. статью Наблюдаемая эквивалентность и небезопасный код.

Наконец, в компиляторе есть явные ошибки.

Вот некоторые темы, которые я намеренно опустил:

• Экономика (труднее найти программистов на Rust) мне кажется, раздел Зрелость отражает суть этого вопроса, который не сводится к проблеме курицы и яйца.
  
  
• Зависимости (stdlib слишком мал / везде слишком много зависимостей) учитывая, насколько хорош Cargo и соответствующие части языка, я лично не вижу в этом проблемы.
  
• Динамическое связывание (в Rust должен быть стабильный ABI) не думаю, что это сильный аргумент. Мономорфизация фундаментально несовместима с динамическим связыванием, и если вам действительно нужно, то есть C ABI. Я действительно думаю, что здесь можно улучшить положение вещей, но вряд ли речь идёт о специфичных изменениях именно в Rust.

Обсуждение темы в /r/rust.

Идет 2020 год. Если вам нужно пояснение, что такое микросервисы лучше потратьте свое драгоценное время на что-то другое. Но если вы впечатлены историями успеха о микросервисах и хотите нырнуть в "панацею" с головой продолжайте читать. Прошу прощения, будет немного длинновато (не очень, прим. переводчика).

Хотя мысль об этом витала уже некоторое время, необходимость ее записать возникла недавно, после захватывающего разговора с парой человек. Меня пригласили для того, чтобы достичь кворума при решении одной весьма интересной проблемы: "что такое микросервисы и должны ли мы следовать этой архитектуре для нашего ПО?".

По первой части вопроса договорились легко, а вот вторая встала весьма остро. Через пару минут общения часть фактов была собрана:

• Есть желание использовать микросервисную архитектуру в будущем продукте, надо это как-то утвердить.
• Кворум был в большей степени нетехническим, чем больше он переходил в "техническую плоскость", тем более неуместным он становился.
• Длинные паузы и отсутствие вопросов подразумевали незнание функционала как веб-сервисов, так и микросервисов.

Я их не осуждал за отсутствие знаний о функциях веб-сервисов или о следствиях работы микросервисов. Собеседники, конечно же, весьма превосходили меня в работе в своей отрасли. Но они хотели запрыгнуть в микросервисы без оценки возможных последствий!

Впервые о микросервисах я узнал еще в 2013 году, это был ролик на YouTube, где пояснялась архитектура сервисов Netflix. Было весьма впечатляюще, но я пропустил все без сожаления, поскольку это было слишком сложно для меня, человека, который тогда только начал постигать принципы разработки. Скоро это стало навязчивой идеей, поскольку на новом проекте объявили о внедрении микросервисов. Разработка проекта была увлекательной, он до сих пор остается лучшим по кодовой базе из тех, что попадали ко мне.

Честно говоря, широкие возможности модульной разработки были где-то далеко от меня, и я просто добавил дополнительный уровень сложности, будучи невежественным разработчиком, скрывавшимся от DevOps. Спустя пять лет я уже работаю с совершенно новым продуктом и другими людьми. У меня куча проблем, возникших из-за плохо разработанных микросервисов, приправленных тактикой девопсов-любителей (девляпсов?, прим. переводчика). Пелена довольно скоро спала, обнажив хрупкость микросервисов. Также я начал смотреть на всю эту архитектуру более опытным взглядом. Было поздно, но лучше поздно, чем никогда.

Видя, что микросервисы играют роль как главного героя, так и главного злодея, я сознательно убедил себя стать "адвокатом дьявола". А если вы архитектор или разработчик, выбирающий микросервисную архитектуру по умолчанию придержите коней и задайте себе несколько вопросов.

Ваше приложение достаточно большое, чтобы дробить его на микросервисы?

Давайте признаем это. Не все приложения достаточно велики, чтобы их можно было разбить на более мелкие сервисы. Микросервисы, как следует из их названия, предоставляют набор небольших обособленных сервисов, каждый из которых выполняет некую роль. В идеальном мире ожидается, что каждый сервис будет сам по себе полноценным приложением.

На картинке выше представлено сравнение "стоимость строчки кода" между микросервисами и монолитным приложением. Микросервисы дороже, даже в простом случае, поскольку есть минимальная цена ресурсов, необходимых для работников и оборудования. Об этом должен думать каждый, а если вас это не заботит, возможно, вам вообще не стоит принимать такие решения.

Никто не спорит, что в будущем размер кодовой базы может вырасти, а это может добавить новый уровень сложности, но также не стоит забывать о том, что правильно разработанный код всегда можно перевести на микросервисы при приближении к пороговому значению.

Нужно ли на самом деле масштабировать отдельные компоненты приложения?

Предположим, что владелец продукта обратился к вам с идеей системы управления для автоматизации отдела кадров компании, в которой работает от 10.000 сотрудников. Технический энтузиаст внутри вас ответит мгновенно: микросервисная архитектура.

Конечно, это граничный случай, но общий смысл вы уже уловили! Одно из основных преимуществ использования этой архитектуры простота масштабирования отдельного компонента. Можно найти множество приложений, в которых этот принцип сработает, но нужно ли это вашему приложению?

Есть ли транзакции, распределенные между сервисами?

Возможно, это наиболее сложное и стратегическое решение, ведь транзакции, охватывающие несколько сервисов, отвечают за всю архитектуру. Обработка транзакций в разных сервисах означает совместную блокировку между сервисами, часть таких взаимоблокировок трудноотслеживаемы и создают состояние гонки. Эти плавающие ошибки причиняют вред сервисам, а иногда портят кровь и инженерам.

Cервисы REST не имеют состояния по определению, а также не должны участвовать в транзакциях, которые проходят по нескольким сервисам. В мире высокой производительности двухфазный коммит (2PC) ненужное зло. Шаблон SAGA добавляет еще один уровень сложности, к которому вы не будете готовы.

Микросервисы создают возможные проблемы целостности данных из-за того, что по своей сути настойчиво предлагают децентрализованное управление данными. В монолитном приложении можно обновить очень многие вещи в одной транзакции, а для обновления этих же данных в микросервисах требуется несколько заходов, в то время как распределенные транзакции не приветствуются (по уважительной причине). Поэтому разработчики должны знать о проблемах целостности, а также выяснять, как выявить отсутствие синхронизации, прежде чем писать код, о котором потом пожалеют. Martin Fowler

Возможно ли иметь распределенные по сервисам транзакции?

Да, конечно.

Стоит ли делать цепочку действий поверх сервисов без состояния (stateless)?

Возможно, не стоит!!

Есть ли нужда в частом общении между сервисами?

В обычном монолитном приложении каждый экземпляр микросервиса предоставляется в виде модуля системы. Связь между модулями работает в памяти с задержкой, близкой к нулю. Внедряя микросервисы не стоит забывать, что связь между сервисами перешла от транзакций в памяти к передаче по проводам.

Есть много проверенных и протестированных решений, но цена у них одна и та же задержка. При переходе к микросервисам задержка вырастает от наносекунд до микросекунд. Попробуйте представить, что есть три сервиса, передающие данные по сети. Предполагая, что каждый вызов сервиса занимает 100мс (не очень быстро под нагрузкой), вы потратите 300мс только на сеть.

Следует учесть, что некоторые приложения тесно связаны с компонентами и сервисами по своему устройству. Дополнительные издержки связи могут привести к катастрофическим последствиям в приложениях, обрабатывающих данные в реальном времени. Попробуйте представить задержку связи в хирургическом костюме или в системе управления воздушным движением!

Кое-что ещё

• Добавленная сложность конечно же, она не может быть определена в абсолютном значении, но ее можно сравнить относительно чего-либо. Несмотря на то, что микросервисы изначально разрабатывались для уменьшения сложности за счет разбиения приложения на более мелкие части их архитектура более сложная в развертывании и обслуживании.

Следует помнить, что усредненная организация в IT не обладает такими же навыками, как команды инженеров Netflix. mike_pfeiffer

• Цена распределенных систем. Микросервисы распределенные системы с молекулярностью. Но распределенность имеет свою цену. Монолит был бы развернут на большой виртуалке или в некотором предварительно сделанном контейнере. Но микросервисы должны разворачиваться независимо (в идеальном мире) на нескольких виртуалках или контейнерах. Конечно же, они бывают небольшими по размеру, но это стоит также учитывать, и помнить, что я еще не начал говорить о затратах на управление и обслуживание.

  
  

• Внедрение DevOps может быть как полезным, так и вредным. DevOps проверенное и широко распространенное решение, но если вы работаете в маленькой компании, создание команды DevOps может принести больше вреда, чем пользы. Но одно можно сказать точно нельзя поддерживать и управлять микросервисами без команды DevOps.

  
  

• Сильная связность некоторые приложения сильно связаны по своей природе. Разбиение на микросервисы, чтобы вписаться в архитектуру, будет катастрофическим.

  
  

• Отсутствие опыта. Отсутствие опыта имеет решающее значение для любой проблемы, и оно не ограничивается только SOA. Но когда дело доходит до микросервисов, это может стать решающим фактором. Если вы разворачиваете приложения в неправильном порядке или произойдет сбой и зависимый сервис упадет будет уже поздно.

  
  

• Сквозное тестирование. Типичное монолитное приложение позволяет запускать и запускать тест практически мгновенно. Наличие нескольких служб с взаимозависимостью задержит тестирование без жизнеспособной оркестровки.

  
  

• Хаотичные контракты на данные. Разработка и хранение контрактов на данные внутри команды сильно отличается от их распространения среди команд. А когда вы работаете с микросервисами, ваша команда может не находиться в одном регионе, не говоря уже об использовании одного и того же языка программирования. Выработка контрактов с данными для особых нужд будет стоить вам времени и места.

  
  

• Устаревшая кодовая база давайте будем честными. Для большинства из нас работа с устаревшей кодовой базой это повседневная деятельность. Это хлеб с маслом большинства организаций. Быстро меняющиеся технологические достижения ставят нас впереди всех, но и в то же время они изолируют нас от устаревшей кодовой базы. Вы уверены, что только что разработанный фреймворк, использующий RabbitMQ, хорошо работает с устаревшим приложением, работающим на AIX?

  
  

• Устранение неполадок каждый сервис будет иметь свой собственный набор файлов журналов для анализа. Больше сервисов = больше файлов.

  
  

Заключение

Я здесь, чтобы сказать "Не используйте микросервисы"?

Конечно же, нет!!

Микросервисы заслужили известность. Они решили проблемы, которые считались неразрешимыми. История Netflix по применению микросервисов вдохновила многих. И список определенно не останавливается на Netflix. Uber, SoundCloud и гигантский Amazon вот некоторые примеры, которые у всех на слуху. И не думайте, что истории успеха ограничиваются только потребительскими приложениями. Я имел непосредственный опыт работы с американским гигантом здравоохранения и был очарован возможностями дизайна, каждый раз, когда открывал исходный код.

Если бы вы доверились этой идее пять лет назад я бы не осуждал вашу доверчивость. Время было другое, но теперь все, что можно сделать быть честным. Сейчас 2020 год. Мы достаточно обожглись, и вокруг нас слишком много авгиевых конюшен. Внедряя бездумно архитектуру микросервисов, вы просто превращаете свой плохой код в плохую инфраструктуру.

Мне нравятся увлеченные программисты, я сам такой когда-то был таким, да и все еще есть. Они преданы тому, что делают, и переходят все границы, чтобы решить свою проблему. Но вы не можете так же энергично принимать решения, которые могут стоить вам и организации целое состояние, извините за резкость. Микросервисы не должны быть вашей архитектурой приложений по умолчанию. Это не серебряная пуля, которую вы искали. Сохраняйте равновесие с KISS и YAGNI.

Как сторонник технологии и энтузиаст, вы имеете право что-либо предпочитать. Однако то, что показывает вас с лучшей стороны способность выбирать прагматично, когда варианты находятся между правильным выбором и вашим любимым выбором.

Автор статьи: Елена Ленсу (Психотерапевт).
Специализации: организационное консультирование, долговременная терапия, работа с травмой, сексология.

---

Бизнес консультант, ex.HRD Pravo.Tech и Rocket10. Автор статей и преподаватель онлайн-курса IT-Recruiter в OTUS.

Почему важно думать и говорить об этой теме, работа состоит из взаимодействия с другими людьми, а это ведет к тому, что люди будут критиковать и выражать иногда недовольство. Важно понимать, почему так сложно принимать критику, почему даже развивающую обратную связь иногда слышим как критику, и как это в себе можно изменить.

Критика указание только на недостатки в том, что было сделано.

Не путаем критику с обратной связью, обратная связь в отличии от критики состоит из позитивных подкреплений, разбора негативных проявлений/действия и мотивации. Перечислим основные причины болезненной реакции на критику. Проявления не взаимоисключающие, и могут жить в вашей многогранной личности вместе.

1) Низкая самооценка.

Внутренний лозунг: Я недостаточно хорош!

Самооценка это то, как мы оцениваем и воспринимаем сами себя, возможности, место среди других людей.

Этимологически происходит от латинского aestimare, что значит возлагать ценность, т.е. какую ценность в себе видим. Когда присутствует концепт я хороший хорошо, что я есть, это устойчивая самооценка. Мысль в голове: Большинство из того, что делаю, более-менее хорошо.. При низкой самооценке, нет устойчивого концепта я.

Базовая мысль: Я не достаточно хорош, все что делаю плохо.

Реакция на критику: критика и замечание опускает человека еще ниже. Из-за выработанной привычки уничижать себя, невозможно вынести ситуацию и мысль о том, что может быть иначе, никак не может сформироваться позитивное мнение о себе. То есть даже, если человеку будут говорить: Ты молодец, Все круто, долгое время человек не будет в это верить и принимать.

Люди с низкой самооценкой склонны избегать признания собственной роли и ответственности в проблемах.

Эмоции: печаль, грусть, беспомощность.

2) Синдром самозванца.

Внутренний лозунг: Я недостаточно хорош? Все об этом узнают

Синдром самозванца достижения, результаты и вообще все, что окружает, ощущаются как незаслуженные, доставшиеся не благодаря личным усилиям и труду, а появившиеся только из-за сумасшедшего везения, случайных совпадений или сами собой.

Человек отрицает свою роль и влияние на ситуации. Синдрому самозванца постоянно сопутствуют тревога и страх: а вдруг разоблачат?

Синдром самозванца сильно связан с тревогой и ужасом неудачи. Когда человек старательно трудится, чтобы его не поймали, а это усиливает и парадоксально увеличивает уверенность в том, что он самозванец.

Реакция на критику: Критика заставляет сжиматься человека в ужасе, появляется постоянная тревога разоблачения.
Ненависть к любым замечаниям, даже корректным, потому что в этот момент проносится мысль, которая вызывает постоянную тревогу разоблачения: Сейчас они всё узнают Ну вроде не заметили, ладно тогда в следующий раз, точно узнают или Сейчас они увидят, что ты ничего не знаешь. В следующий раз тебе так не повезёт.

Критика интерпретируется только в одну сторону в ту, которая является по-настоящему важной, то есть только в негативную.

Эмоции: страх, ужас, тревога

3) Неумение выносить чужой дискомфорт.

Внутренний лозунг: Кому-то неприятно и это все из-за меня!

Удобные люди, это люди у которых нет личных границ и они стараются сделать так, как комфортно всем. Воспитание таких людей идет в парадигме нельзя доставлять дискомфорт, показывай результат. Такие люди почти полностью отказались от своих потребностей, чувств, желаний и планов, от себя.

Обычно реализуют желания мамы, папы, мужа, жены, детей, начальников, колле г- только не свои. Чтобы случайно не помешать кому-то или не стать виновником чей-то неудачи.

Реакция на критику: Я все испортил, из-за меня теперь человеку сложно и неприятно, он испытывает дискомфорт.

Фокус тут на других людях, на их стабильности и благополучии, на заботе о комфорте других, полное игнорирование себя. Ощущать себя виноватым бесконечно сложно, поэтому для таких людей это болезненно и неприятно.

Чувства: вина, страх, печаль, бессилие, беспомощность.

4) Нарциссизм

Внутренний лозунг: Сейчас объясню, почему не правы!

У каждого человека есть нарциссическая часть, она помогает поддерживать самоуважение.

Люди у которых есть перекос в нарциссическую часть, не чувствуют собственное я и строят восприятие себя из оценки других. Угроза подтверждению внешнему всегда равна угрозе внутреннему хорошему Я.

Реакция на критику: Вызывает ярость и бессилие, потому что это не негативная оценка, а удар по внутреннему Я. Появляется ощущение дефектности, и все могут ее увидеть и узнать.
Вместо замечаний, такой человек слышит, что он не полноценный.

Основные эмоции: ярость, которая прикрывает стыд (стержневое чувство при нарциссизме. Нарциссизм питается иллюзией об отсутствии неудач, что избегать стыд).

5) Перфекционизм

Внутренний лозунг: Как я мог об этом НЕ подумать?

Перфекционист это человек с ощущением того, что он достаточно хорош. Смысл жизни постоянная погоня за совершенством. Постоянное стремление к несуществующему идеалу. Существует обманчивое ощущение, что достигнув (несуществующего) идеала, все станет хорошо.

Реакция на критику: Перфекционист сталкивается со своим несовершенством, и в этот момент возникает ужас, тут пропадает возможность быть достаточно хорошим. Это невыносимо больно, жить без такой иллюзии невозможно. Внешняя критика для перфекциониста невыносима, а внутренней он сам себя постоянно изводит:КАК ошибка! Я не идеален. Если ошибка появилась, значит я недостаточно хорошо старался.

У нарцисса и синдрома самозванца внешний фокус все узнают, у перфекциониста он на себе: Я знаю, что есть ошибка и это невыносимо мучительно, все равно, что думают другие.

Эмоции: ужас, разочарование, беспомощность.

Психологическая травма

Нельзя не сказать, о психологической травме это эмоциональное потрясение, которое сопровождается сильнеишими переживаниями, эмоциями.

Структура нормальнои, непроизвольнои реакции психики на опасность которую нельзя избежать иммобилизация. Травматические симптомы являются результатом замораживания остаточнои энергии, которои не нашлось выхода и разрядки, это напряжение остается в психике.

Человек начинает неосознанно стремиться к такому же травматическому опыту, чтобы освободить и разрядить эту энергию.

Та часть психики, которая Я, становится очень хрупкой, либо перестает толком развиваться. Хрупкого и не ресурсного Я не хватает на обработку входящих негативных сигналов, и они снова наносят повреждения. Иногда сопоставимые по размерам с оригинальной травмой.

Есть много способов, как с этим работать и жить об этом мы расскажем в новых статьях.

---

А пока вы можете начать рефлексировать, задача рефлексии максимально точное определить свои феномены и взаимосвязи, а также найти опоры.
Лучший способ не включаться на критику это найти внутренние опоры. Опора то, что дает ощущение устойчивости, надежности, а значит безопасности.

Какие опоры бывают:

• контакт с собой (медитация, массаж, понимание эмоций, готовка, рисование, все что помогает вам не бежать и достигать, а понять, что нужно вам)
• люди
• дом
• тело
• ритуалы

Чек-лист для успокоения

• комфортно ли я сижу (устойчиво на стуле, ноги упираются в пол)
• спокойно ли я дышу
• что чувствую
• отделяю ли критику от своей личности
• критика НЕ ОЦЕНКА МЕНЯ
• неконструктивные слова отскакивают от меня
• подумай, что обидчику сейчас гораздо тяжелее, чем мне, посочувствуй и отпусти его с миром
• слышу ли я конкретные кейсы, или только обобщения
• я в позиции взрослого
• все свои мысли и описать все свои чувства на бумаге, прежде чем отвечать

Что вы чувствуете? Что вы думаете? Выплесните это на бумагу, а не на человека

2 самых важных вопроса:

1) Что происходит со мной в данный момент?

-что делаю?
-о чем думаю?
-что чувствую?
-как дышу?

2) А чего же я хочу?

---

Остались вопросы? Задайте их на бесплатном онлайн-вебинаре, в рамках которого наш преподаватель подробно расскажет о курсе.

---