Микросервисы без иллюзий. Арифметика архитектурного решения
Отсюда не следует, что ошибся DDD. Это ценный инструмент моделирования, и его ценность от этой ошибки не зависит: общий язык со знатоками предметной области и явные границы моделей нужны и монолиту. Контексты прекрасно живут модулями внутри одного процесса, каждый со своей моделью, своим интерфейсом и при необходимости своей схемой в общей базе. Такой модуль с явным интерфейсом не закрывает дорогу к сервису: если у контекста однажды появится своя команда, его можно будет вынести за сетевую границу.
У сетевой границы есть сильный довод: её нельзя пересечь незаметно, а границу модуля держат только дисциплина команды и проверка зависимостей при сборке. По сути это довод Тилкова о том, что части монолита неизбежно срастаются, и он реален. Но он о том, чем удобнее охранять границу модели, а не о том, где она проходит. Kubernetes здесь тоже ни при чём: монолит в нём живёт не хуже, и оркестратор не требует дробить приложение.
Четыре границы могут совпасть, и иногда это верное решение. Там, где работают сотни команд и каждой нужна независимость, граница модели, граница команды, граница процесса и сетевая граница нередко проходят в одном месте. Но такое совпадение следует из числа команд; определение bounded context его не требует. Ошибка была не в DDD и не в сервисах, а в знаке равенства между bounded context и сетевым адресом.
2.5. Как исчезают оговорки
Статья Льюиса и Фаулера в нынешней редакции на сайте Фаулера занимает больше шести тысяч слов — это около получаса чтения. Многие оговорки в ней стоят в тех же абзацах, что и выводы, а главная — что судить о будущем стиля рано — отдана заключительному разделу. Кто дочитал статью до конца, знал, при каких обстоятельствах получены её выводы. Заметки, вышедшие следом, добавили к описанию ещё три обстоятельства — предпосылки, цену и очерёдность. Вместе эти тексты и есть первое звено цепочки, по которой описание дошло до команд, никогда не открывавших исходного текста. Звеньев в ней по меньшей мере семь, и на каждом текст становится короче.
Второе звено — доклад. Докладчик рассказывает о системе своей компании и рассказывает правду: как делили, что ломалось, какие инструменты пришлось написать самим. Число инженеров, зрелость платформы, годы жизни системы до разделения для него не оговорка, а обстановка. Опускает он то, что считает само собой разумеющимся. Для слушателя из другой компании именно эта обстановка и была условием.
Вернуть его у доклада есть одна возможность — вопросы из зала. Но в оставшиеся несколько минут спрашивают о том, ради чего пришли: каким инструментом делили данные, как переключали трафик, как обходились без общих транзакций. Вопрос о численности компании звучит как вопрос не по теме. Слушатель пришёл узнать, как это делается, а не выяснять, похож ли он на того, кто стоит на сцене. Даже если такой вопрос прозвучит, ответ на него останется в зале: в пересказ выступления попадёт только схема.
Третье звено — пост в блоге с заголовком вроде «10 преимуществ микросервисов». Такой текст обычно пишет тот, кто слышал несколько выступлений и читал статью, и пишет добросовестно: каждый пункт можно найти у источников. Типичные пункты — независимое развёртывание, масштабирование отдельных частей, свобода выбора технологий, изоляция отказов. У перечня преимуществ нет строки для обстоятельств: пункт «при тысяче инженеров» не похож на преимущество и в список не попадает. Ссылки в таком посте ведут на выступления и на другие посты, то есть на предыдущее звено, а не на первое. Следующий автор, который возьмёт этот пост за источник, получит перечень, у которого уже нет происхождения.
Четвёртое звено — обзорный документ поставщика инфраструктуры, то, что по-английски называют whitepaper. Он опирается уже не на опыт одной компании, а на практику отрасли, и типичная его фраза звучит как «ведущие компании перешли на микросервисы». Конкретная организация со своим числом инженеров становится «ведущими компаниями», а у них нет численности, с которой можно сверить свою. Истории отдельных компаний в нём сжаты до коротких справок с названием и результатом: перешли, ускорили выпуск, выдержали пиковую нагрузку. Сколько лет занял переход и сколько людей его делали, в такую справку не помещается. Решение о переходе в самом документе принято до первой страницы: дальше описаны этапы пути, а вопрос о его начале вынесен за скобки.
В объявлении о вакансии, пятом звене, от тезиса остаётся одно имя — строка «опыт микросервисной архитектуры». В строке нет ни компании, ни масштаба, ни глагола. Архитектура, которую несколько организаций выбрали для себя, становится навыком, который человек переносит из компании в компанию. Список требований устроен как список преимуществ: место для умения в нём есть, а для обстоятельств, в которых это умение нужно, нет.
Шестое звено — собеседование по проектированию систем (system design). Кандидату предлагают за час спроектировать что-нибудь знакомое, например ленту новостей или сервис коротких ссылок. У хорошего ответа есть узнаваемый шаблон: шлюз на входе, сервисы по сущностям, у каждого своя база, очередь между ними. В типичной формулировке задачи задана нагрузка — миллионы пользователей, тысячи запросов в секунду, — а размера команды, которая будет систему писать и сопровождать, в ней нет. Из двух величин, от которых зависит ответ, в условии остаётся одна: про машины, а не про людей. Сам шаблон передаётся так же, как всё в этой цепочке: разборы типовых задач пересказывают удачные ответы, а удачные ответы пересказывают выступления крупных компаний.
Седьмое звено — архитектура стартапа из восьми человек. Её рисует инженер, который читал такие посты и проходил такие собеседования, и рисует так, как его учили отвечать у доски. На такой схеме легко может оказаться больше сервисов, чем людей в команде. Из трёх умений, которые Фаулер в 2014 году назвал предпосылками, у восьми человек может не оказаться ни одного. Ни на одном звене вопрос о том, для кого всё это окупается, не был опровергнут. Он перестал звучать между первым звеном и вторым, и дальше его не было в тексте, который передавали.
Налог распределённости при этом начисляется полностью: его размер не зависит от того, дошло ли условие до того, кто платит. А дохода, ради которого налог когда-то платили, — независимости многих команд друг от друга — у восьми человек нет, потому что команда у них одна.
Цепочка работала не один год. Если судить по Google Trends, интерес к слову «микросервисы» рос с 2014 года и продолжал расти до конца десятилетия. Это иллюстрация, а не доказательство: кривая поисковых запросов показывает любопытство, а не число систем, построенных по рецепту, и не говорит, где искавшие встретили слово. Можно предположить, что большинство встретило его после статьи 2014 года, на одном из следующих звеньев. Каждый новый читатель входил в цепочку ниже предыдущего и получал текст ещё короче.
Вывод и условие переносят пересказ по-разному. Вывод говорит о предмете — о сервисах, базах, развёртывании — и остаётся верным, кто бы его ни повторял. Условие говорит о том, кто говорит: «у нас тысяча инженеров» верно только в устах докладчика, и уже следующий пересказчик не может сказать «у нас». Ему остаётся назвать чужое число или опустить его, и опустить проще. Поэтому с каждым звеном из текста уходит то, что держалось на положении предыдущего рассказчика: его численность, его платформа, годы его системы.
Есть и вторая причина, связанная с адресатом. От звена к звену аудитория шире: от зала, который слушает доклад, до каждого, кто готовится к собеседованию. Оговорка о том, для каких организаций это верно, делит такую аудиторию на тех, к кому текст относится, и тех, к кому нет. Для большинства читателей она означала бы, что текст не про них. Без неё сказанное годится для любого читателя и именно в таком виде расходится дальше.
Сокращение само по себе не порок. Эта цепочка — обобщение, а не история одного текста: звенья могли меняться местами или выпадать, но направление у неё одно, от описания к требованию. Без пересказа знание не выходит за пределы одной организации, и та же цепочка разнесла по отрасли то, что пригодилось почти всем: автоматизацию развёртывания, мониторинг, привычку проектировать в расчёте на отказ. Краткость и не обязана губить оговорку. Мысль Ньюмана о том, что чем меньше команда, тем заметнее цена микросервисов, укладывается в несколько слов и вся состоит из условия. Значит, дело не в длине текста, а в том, какую часть фразы при сокращении считают необязательной.
В статье тезис о микросервисах звучал так: опыт положительный, но судить рано, а в заметке о премии добавлялось, что, если система не слишком сложна для монолита, микросервисы не стоит и рассматривать. В докладе от него остаётся «мы перешли на микросервисы, и наши команды выпускают изменения, не дожидаясь друг друга». Это правда, и в ней ещё есть «мы» и «наши команды», за которыми стоит тысяча инженеров, но число не произнесено. Фразы из статьи и из доклада друг другу не противоречат, и каждый из авторов мог бы подписаться под обеими.
Условия первого звена, сведённые в одну фразу, звучали бы примерно так: «если система сложна, платформа зрела, а инженеров тысячи, микросервисы окупаются». Целиком эту фразу никто не произносил: в статье и заметках её первая половина выражалась через сложность задачи и умения команды, в докладе стояла за словами «мы» и «наши команды». До вакансии дошла только вторая половина, и от неё осталось название навыка — «опыт микросервисной архитектуры». На каждом шаге теряются условия и сохраняются выводы. Никто не лжёт: каждый честно пересказывает предыдущий шаг, просто короче.
Рецепт, которым закончилась эта история, — не искажённый текст, а верный текст без условия. Каждый его вывод можно найти в первоисточнике, и там он верен — при обстоятельствах, которые первоисточник называет. Выпало одно «если» — та часть фразы, которая говорила, для кого выводы сделаны. Поэтому опровергать в рецепте нечего, а искать тех, кто его исказил, бесполезно: их не было. Вернуть можно только выпавшую переменную — число инженеров. Стоит поставить рядом с любым выводом рецепта численность своей организации, и он снова становится утверждением, которое можно проверить.
Летом 2015 года эта оговорка лежала на виду: о том, с чего начинать и во что обходится распределённость, два инженера спорили на сайте самого Фаулера, открыто, под своими именами. В 45-минутный доклад она не поместилась: её никто не вычёркивал, для неё просто не нашлось минуты. Не дошла она и дальше — ни до строки в объявлении о вакансии, ни до схемы, которую рисует для своей системы стартап из восьми человек. У этих восьми есть все выводы, сделанные когда-то о компаниях с тысячами инженеров, и нет числа, ради которого их делали.
Рецепт существует как текст без автора и без даты: его передают дальше, не называя источника. Цепочка честного пересказа объясняет, как из него выпало условие. Она не объясняет, почему условие никто не вернул, хотя исходные тексты все эти годы оставались на месте и подняться к ним по цепочке мог любой. Пересказ потерянного не возвращает: возвращают те, кому это нужно. А рецепт без условия продержался годы. Сами по себе рецепты так долго не живут — долго живут только те, что кому-то выгодны.
Глава 3. Почему это прижилось
В 2020 году исследователи из Штутгартского университета опросили 591 человека о том, как нанимают разработчиков. Девяносто семь из них ответили дважды: как те, кто нанимает, и как те, кого нанимают. Один и тот же человек пишет текст вакансии и обновляет собственное резюме. В системе, которая сделала рецепт нормой, нет наблюдателей со стороны.
Устойчивость рецепта проще всего объяснить чьей-то ошибкой суждения. Точнее другое объяснение: каждый участник вёл себя разумно на своём месте, и из суммы таких решений сложился результат, которого никто не выбирал. Ошибку закрепили не отдельные инженеры: её закрепила система, в которой они работали.
Инженеру сложный проект приносил строку в резюме и довод при повышении. Руководителю следование норме давало защиту при любом исходе, и слово «монолит» к тому времени звучало как оценка, а не как описание. Рынку каждый новый сервис приносил выручку, причём выручку за решения реальных проблем. К концу десятилетия появились первые публичные откаты, но спор о них так и остался спором предпочтений.
У простого решения на всех этих уровнях одно общее свойство: его не видно. Сложное оставляет следы на каждом шагу: диаграммы, доклады, вакансии, счета. Простое не оставляет ни строки в резюме, ни пункта в годовом отчёте, ни позиции в чьём-либо счёте.
3.1. Карьерные стимулы
Две строки из двух резюме. В первой перечислено: микросервисы, Kubernetes, Kafka, Istio. Во второй сказано скромнее: монолит на Rails, один сервер. Первая строка совпадает с ключевыми словами вакансии и проходит первичный отбор. Вторая не совпадает ни с одним из них, хотя за ней может стоять система, которая годами приносит компании выручку, выдерживает сезонные пики и не требует ночных дежурств.
Автор второй строки может знать о нагрузке и отказах не меньше, чем автор первой. Разница в том, что его знание ушло в решение не усложнять: он понимает, почему в его системе не понадобились очереди и почему одной базы хватает. Это знание нельзя перечислить через запятую. Первичный отбор ведёт человек, который сверяет резюме со списком из вакансии, или программа, которая делает то же самое быстрее. Ни тот ни другая этой разницы не видят: они сравнивают слова, а не системы.
Инженер, который читает вакансии, делает из этого разумный вывод. Следующий проект стоит выбирать так, чтобы через пару лет в резюме оказалась первая строка. У такого поведения есть имя в литературе — resume-driven development, разработка ради резюме: выбор технологий по их ценности для резюме, а не для продукта. Название звучит как упрёк, будто инженер жертвует продуктом ради собственной карьеры. Эмпирическое исследование явления рисует картину, в которой упрёк адресовать некому.
Опрос 2020 года провели Йонас Фрич, Марвин Вирих, Юстус Богнер и Штефан Вагнер; результаты вышли в 2021 году. Среди участников 130 ответили как специалисты по найму, 558 — как разработчики и другие технические специалисты. Почти 60% нанимающих согласились, что на тексты их вакансий влияет то, какие технологии сейчас на подъёме. Но когда их спросили, кого из двух кандидатов они предпочтут, опыт с новейшими популярными технологиями выбрали только 20%, а опыт с устоявшимися — около 39%. Знание устоявшихся технологий назвали важным около 85% нанимающих, популярных — около 59%.
Разработчики видят ту же картину с другой стороны. Из них 82% согласились, что работа с популярными технологиями делает их привлекательнее для будущих работодателей. Около 63% считали, что чем больше таких технологий они освоят, тем привлекательнее станут. Каждый пятый подтвердил, что его команда хотя бы раз брала популярную технологию, зная, что для задачи она не лучший выбор.
Главный результат исследования — расхождение. Нанимающие пишут популярные технологии в вакансии, но при выборе чаще ценят устоявшиеся, а девять из них в свободных ответах назвали третье: готовность учиться, умение работать с людьми, понимание фундаментальных принципов. Разработчики выносят популярные технологии в резюме, потому что считают, что их оценивают именно по ним. Авторы определяют явление как взаимодействие специалистов по найму и разработчиков, при котором и вакансии, и резюме перегружены популярными технологиями, хотя обе стороны на деле ценят опыт с ними меньше. Среди возможных последствий они называют снижение качества программ и текучку, которая возникает из ложных ожиданий обеих сторон.
Каждая сторона здесь отвечает на то, что показывает другая, а не на то, что та ценит. Авторы осторожно добавляют, что у такого взаимодействия есть потенциал стать самоподдерживающимся: соискатели могут откликаться на акцент вакансий ещё сильнее, выдвигая те же технологии в резюме, и тем самым его подкреплять. Сигнал держится на самом устройстве обмена, и поэтому переживает любое отдельное собеседование и любого отдельного интервьюера. Тот, кто хотя бы раз поднимал Kubernetes повыше в списке навыков, делал ровно то, чего от него, по всем видимым признакам, ждали. Тщеславия в этом нет: это верный ответ на вопрос, который задаёт рынок, пусть сам вопрос задан неточно.
У этих чисел есть границы. Выборка самоотобранная: участников набирали в мае—июле 2020 года через немецкий журнал для разработчиков, профессиональные и социальные сети, около 90% из них — из Германии. Зато опрос прошёл в самом конце подъёма микросервисов и даёт снимок рынка труда по свежим следам. Он касается технологий вообще и отдельно микросервисы не измеряет, хотя в определении популярной технологии, которое видели участники, они стоят первым примером. Большая часть чисел описывает убеждения, а не поступки: о том, что их команда сознательно брала не лучшую для задачи технологию, сообщила примерно пятая часть, то есть это поведение меньшинства. Но стимулу не нужно большинство: достаточно, чтобы в спорных случаях, когда защитимы оба варианта, выбор раз за разом смещался в одну сторону.
Внутри компании действует та же логика, только вместо вакансии — оценка работы. Строка «мигрировал на микросервисы» описывает проект с началом, концом и диаграммой: было одно приложение, стало двенадцать сервисов, вот схема до, вот схема после. У проекта есть сроки, команда, документ с обоснованием и день, когда последний модуль переехал. Строка «выбрал простое решение, и оно три года работает без инцидентов» описывает то, чего не произошло. У предотвращённой проблемы нет презентации: нечего вывести на слайд, некого поблагодарить в рассылке, нет даты, которую можно отметить.
Дело не в том, что руководители любят сложность. Любая процедура, которая оценивает работу по предъявленным результатам, вознаграждает то, что можно предъявить. Миграция производит предъявляемое в избытке. Отсутствие инцидентов не производит ничего, и со стороны его легко принять за везение или за простоту задачи. Руководитель, который оценивает, сам отчитывается выше, и ему тоже нужно показать, что его команда сделала за год. Размах проекта к тому же читается как размах ответственности, а ответственность — привычный довод в разговоре о повышении.
Невидимость легко проверить на своей компании. Достаточно найти в её документах хотя бы одно решение не делать чего-то сложного, за которое автор получил признание. Руководитель группы, который за квартал убедил команду не выделять платёжный модуль в отдельный сервис, сделал работу: собрал доводы, посчитал нагрузку, выдержал спор. Результат этой работы — сервис, которого нет. В форме самооценки для него нет поля, а в рассказе о нём нет ни одной диаграммы.
В этой асимметрии есть и сдвиг во времени. Налог за каждую новую сетевую границу компания платит годами: в эксплуатации, в дежурствах, в разборах отказов. Награду за её создание автор получает один раз и сразу, при ближайшей оценке. Ни резюме, ни документ на повышение не показывают, окупилась ли граница. Когда приходит счёт, автор решения может работать уже над следующим проектом или в другой компании.
Бывают миграции, которые действительно нужны, и тогда награда заслужена. Сотни инженеров, которые блокируют друг друга в одном приложении, — реальная проблема, и тот, кто её решил, сделал для компании много. Слабость процедуры оценки в другом: у неё нет способа отличить нужную миграцию от ненужной, потому что в отчёте о сделанном обе выглядят одинаково. Автора простого решения никто не наказывает. Его просто не видно.
На входе в компанию действует третий механизм — собеседование по проектированию систем (system design). Кандидату дают задачу вроде сервиса коротких ссылок или ленты новостей и час у доски. Шаблон ответа известен заранее: балансировщик, кеш, очередь, несколько сервисов, реплики базы. Для сервиса коротких ссылок на доске появляются парк серверов приложений, кеш перед хранилищем, очередь для сбора статистики и хранилище ключей, разнесённое по нескольким машинам, — там, где работу могла бы сделать одна таблица с индексом по короткому ключу. Интервью проверяет знание распределённых паттернов и поэтому вознаграждает их применение. Чем больше приёмов кандидат уместно назвал, тем больше он показал.
Ответ «монолит на PostgreSQL» для большинства компаний правильный. На собеседовании он проигрывает, потому что не демонстрирует тех знаний, ради проверки которых собеседование устроено. Кандидат, который скажет, что при заявленной нагрузке хватит одного сервера и хорошо настроенной базы, даст верный ответ и оставит интервьюера без материала для оценки. Естественное продолжение такого разговора — вопрос, что будет при нагрузке в сто раз больше: формат ищет место, где понадобятся паттерны, и находит его. Кандидаты быстро это понимают и учатся рисовать распределённую схему уверенно и подробно.
Вины интервьюера здесь тоже нет. Инженеру, который будет проектировать системы, знание распределённых паттернов нужно, и за час убедиться в нём иначе трудно. Ограничение заложено в самом формате: он хорошо проверяет, знает ли кандидат приёмы, и плохо проверяет суждение о том, когда они не нужны. Кроме того, формат легко воспроизводит себя: интервьюеры сами когда-то проходили такие собеседования и знают, как выглядит хороший ответ. Суждение «здесь это лишнее» трудно показать на доске. У него нет схемы.
Резюме, оценка и собеседование устроены по-разному, но поощряют одно и то же. Разработчик, который выносит Kafka в первую строку, верно читает вакансии. Руководитель, который вписывает Kafka в вакансию, отражает рынок; комиссия, которая повышает автора миграции, оценивает то, что ей показали; интервьюер проверяет то, что умеет проверить. Ни один из этих шагов не требует ни тщеславия, ни глупости. И всё же их сумма складывается в архитектуры, которые вряд ли выбрал бы человек, отвечающий за компанию целиком и на годы вперёд.
Выйти из этой системы в одиночку дорого, и в этом её устойчивость. Тот, кто выбирает простое, платит сам: строкой в резюме, доводом при повышении, баллами на собеседовании. Выгоду от его выбора получает компания, причём незаметно для всех, включая её саму. Тот, кто выбирает сложное, получает награду лично, а расплачивается за его выбор вся компания — вразбивку, по разным бюджетам, так что ни в одной отдельной статье расходов эта плата не видна. При таком раскладе простое решение обходится инженеру личной жертвой, и требовать её от каждого было бы странно.
Эту систему не придумал ни один человек. Её собрали мы — те, кто писал вакансии, сидел в комиссиях, проводил собеседования и обновлял собственные резюме. Индивидуально рациональное поведение даёт коллективно иррациональный результат. Индустрия создала систему, которая вознаграждает сложность.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
Приобретайте полный текст книги у нашего партнера: