Compare text

Find the difference between two text files

Real-time diff

Unified diff

Collapse lines

Highlight change

Syntax highlighting

Tools

Смерть от тысячи микросервисов

Created 5 months agoDiff never expires

129 removals

143 lines

97 additions

127 lines

Смерть от тысячи микросервисов

Индустрия программного обеспечения еще раз осознает, что сложность убивает.

Церковь сложности

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

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

Триггерное предупреждение: некоторые люди, по понятным причинам, рассердились, когда я назвал JavaScript и NodeJS источником проблемы, но на самом деле моя точка зрения была больше об опасностях герметично закрытых программных экосистем, которые, кажется, одержимы повторным изучением уроков, которые мы только что закончил учиться. Раньше мы столкнулись со стеной сложности и выполнили сброс — иначе мы бы все равно использовали CORBA и SOAP. Эти герметичные пузыри разработчиков представляют собой разрушительный шар для всей отрасли, и на то, чтобы их развернуть, требуется около десяти лет.

Идеальный шторм

В недавней истории есть несколько событий, которые, возможно, способствовали нынешнему положению вещей. Во-первых, целая армия разработчиков, пишущих JavaScript для браузера, начала идентифицировать себя как «full-stack», погрузившись в серверную разработку и асинхронный код. JavaScript — это JavaScript, верно? Какая разница, что вы создадите с его помощью — пользовательские интерфейсы, серверы, игры или встроенные системы. Верно? Node все еще был своего рода учебным проектом одного человека, а ранний JavaScript был крайне проблематичным выбором для разработки серверов. Указание на это еще зеленым разработчикам серверной части обычно приводило к большому раздражению и пыхтению. В конце концов, это все, что они знали. Мира за пределами Node фактически не существовало, путь Node был единственным путем, и это послужило источником упрямого, догматического мышления, с которым мы имеем дело по сей день.

В недавней истории есть несколько вещей, которые, возможно, способствовали нынешнему положению. Во-первых, целая армия разработчиков, пишущих JavaScript для браузера, начала идентифицировать себя как «full-stack», погружаясь в серверную разработку и асинхронный код. JavaScript — это JavaScript, верно? Какая разница, что вы создадите с его помощью — пользовательские интерфейсы, серверы, игры или встроенные системы. Верно? Node все еще был своего рода учебным проектом одного человека, а JavaScript тогда был крайне проблематичным выбором для разработки серверов. Указание на это, еще зеленым разработчикам серверной части, обычно приводило к большому раздражению и пыхтению. В конце концов, это все, что они знали. Мира за пределами Node фактически не существовало, путь Node был единственным известным путем, и это послужило источником упрямого, догматического мышления, с которым мы имеем дело по сей день.

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

А затем постоянный поток ветеранов FAANG начал сливаться с рекой стартапов, обучая новоявленных и очень впечатлительных молодых серверных инженеров JavaScript. Апостолы Церкви Сложности настойчиво заявляли, что «то, как они поступили в Google», было неоспоримо и правильно – даже если это не имело смысла в данном контексте и размере. Что значит, что у вас нет отдельной службы пользовательских настроек? Это просто не масштабируется, братан!

А затем постоянный поток ветеранов FAANG начал сливаться с рекой стартапов, обучая новоиспеченных и очень впечатлительных молодых серверных инженеров JavaScript. Апостолы Церкви Сложности настойчиво заявляли, что «то, как они действовали в Google», было неоспоримым и правильным, даже если это не имело смысла в нынешнем контексте и размере. Что значит, что у вас нет отдельной службы пользовательских настроек? Это просто не масштабируется, братан!

Но во всем этом легко обвинить ветеранов и новичков. Что еще происходило? Ах да, легкие деньги.

Что вы делаете, когда у вас полно венчурного капитала? Конечно, вы не гонитесь за прибылью! Я не раз получал электронные письма от руководства, в которых просил всех быть в офисе, навести порядок на своих столах и выглядеть занятыми, поскольку по помещению собирались промаршировать облачком с жилетами Patagonia. Инвесторам нужно было увидеть взрывной рост, но не прибыльность, нет. Им просто нужно было посмотреть, как быстро компания сможет нанять сверхдорогих инженеров-программистов, чтобы сделать… что-нибудь.

Что вы делаете, когда у вас полно венчурного капитала? Конечно, вы не гонитесь за прибылью! Я не раз получал электронные письма от руководства, в которых просили всех быть в офисе, наводить порядок на своих столах и выглядеть занятыми, поскольку по офису собирались пройти парадом жилеты Patagonia. Инвесторам нужно было увидеть взрывной рост, но не прибыльность, нет. Им просто нужно было посмотреть, как быстро компания сможет нанять сверхдорогих инженеров-программистов, чтобы сделать… что-нибудь.

Renegade Otter — разработчик Friendly Fire — умного запроса на включение для GitHub:

Подключите пользователей GitHub к Slack и уведомляйте напрямую

И теперь, когда у вас есть эти разработчики, что вы с ними делаете? Они могли бы создать более простую систему, которую легче развивать и поддерживать, или они могли бы создать чудовищное созвездие «микросервисов», которое никто толком не понимает. Микросервисы — новый способ написания масштабируемого программного обеспечения! Собираемся ли мы просто притвориться, что понятия «распределенные системы» никогда не существовало? (Опустим весь разбор нюансов о том, что микросервисы не являются настоящими распределенными системами).

Пропустить рецензентов, которые недоступны

Сопоставление шаблонов файлов

Индивидуальные напоминания о проверке кода

Доступ к вашей кодовой базе не требуется

И теперь, когда у вас есть эти разработчики, что вы с ними делаете? Что ж, они могли бы построить более простую систему, которую легче развивать и поддерживать, или они могли бы создать чудовищное созвездие «микросервисов», которое никто толком не понимает. Микросервисы — новый способ написания масштабируемого программного обеспечения! Собираемся ли мы просто притвориться, что понятия «распределенные системы» никогда не существовало? (Давайте опустим весь разбор нюансов о том, что микросервисы не являются настоящими распределенными системами).

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

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

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

Мне нравится ссылаться на этот отчет о 5-летнем аудите стартапов, поскольку он наполнен здравыми выводами:

Мне нравится ссылаться на этот отчет о 5-летнем аудите стартапов, поскольку он наполнен здравыми выводами, основанными на веских доказательствах (и платных идеях):

…Проверенные нами стартапы, которые сейчас преуспевают лучше всего, обычно придерживаются почти наглого подхода к проектированию «сохраняйте простоту». Ум ради ума ненавидели. С другой стороны, компании, в которых мы говорили: «Ого, эти люди чертовски умные», по большей части исчезли.

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

Буквально – «сложность убивает».

Аудит выявил интересную закономерность: многие стартапы испытывали своего рода синдром коллективного самозванца, создавая понятные, простые и производительные системы. Не начинать работу с микросервисами с первого же дня — это клеймо, независимо от проблемы. «Все занимаются микросервисами, а у нас есть единый монолит Django, поддерживаемый всего несколькими инженерами, и экземпляр MySQL — что мы делаем не так?». Ответ почти всегда «ничего».

Аудит выявил интересную закономерность: многие стартапы испытывали своего рода синдром коллективного самозванца, создавая понятные, простые и производительные системы. Существует догма, запрещающая начинать работу с микросервисами с первого дня, независимо от проблемы. «Все занимаются микросервисами, а у нас есть единый монолит Django, поддерживаемый всего несколькими инженерами, и экземпляр MySQL — что мы делаем не так?». Ответ был почти всегда: «ничего».

Точно так же в современном мире технологий опытные инженеры очень часто испытывают колебания и неадекватность, и хорошая новость в том, что нет, скорее всего, это не вы. Команды часто делают вид, что занимаются «веб-масштабированием», прячась за библиотеками, ORM и кешем — будучи уверенными в своих знаниях (они разгромили этот Leetcode!), но они могут даже не знать об основах индексации баз данных. Вы действуете в море неоправданной самоуверенности, расточительства и Даннинга-Крюгера, так кто же здесь на самом деле самозванец?

Точно так же опытные инженеры часто испытывают колебания и неадекватность в современном мире технологий, и хорошая новость в том, что нет, вероятно, это не вы. Команды часто притворяются, будто занимаются «веб-масштабированием», прячась за библиотеками, ORM и кешем — будучи уверенными в своих знаниях (они разгромили этот Leetcode!), но они могут даже не знать об основах индексации баз данных. Вы действуете в море неоправданной самоуверенности, расточительства и Даннинга-Крюгера, так кто же здесь на самом деле самозванец?

В монолите нет ничего плохого.

В монолите нет ничего плохого

Идея о том, что невозможно расти без системы, напоминающей печально известный провал военной стратегии в Афганистане, является мифом.

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

Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify, StackOverflow — эти и другие компании начинали как монолитные базы кода. Многие по сей день имеют в своей основе монолит. StackOverflow гордится тем, как мало оборудования им нужно для работы огромного сайта. Shopify по-прежнему остается монолитом Rails, использующим проверенный и надежный Resque для обработки миллиардов задач.

Dropbox, Twitter/X, Facebook, Instagram, Shopify, Stack Overflow — эти и другие компании начинали как монолитные базы кода. Многие по сей день имеют в своей основе монолит. Stack Overflow вызывает гордость за то, как мало оборудования им нужно для работы огромного сайта. Shopify по-прежнему остается монолитом Rails, использующим проверенный и надежный Resque для обработки миллиардов задач.

WhatsApp стал сверхновой благодаря своему монолиту Erlang и относительно небольшой команде. Как?

WhatsApp стал сверхновой благодаря монолиту Erlang и 50 инженерам. Как?

WhatsApp сознательно сохраняет небольшой штат инженеров — всего около 50 инженеров.

Отдельные инженерные группы также невелики и состоят из 1–3 инженеров, и каждая группа обладает значительной автономией.

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

Instagram был приобретен за миллиарды — с командой из 12 человек.

И вы представляете себе Threads как проект, охватывающий весь Мета-кампус? Неа. Они следовали модели Instagram, а это вся команда Threads:

И вы представляете себе Threads как проект, охватывающий весь Мета-кампус? Неа. Они следовали модели Instagram. Вот их команда:

Кредит: Substack — Инженер-прагматик

Возможно, утверждение, что ваша конкретная проблемная область требует чрезвычайно сложной распределенной системы и открытого офиса, доверху набитого турбо-гениями, просто переходит в высокомерие, а не в гениальность?

Не решайте проблемы, которых у вас нет

Простой вопрос – какую проблему вы решаете? Это масштаб? Откуда вы знаете, как разбить все это на масштаб и производительность? Достаточно ли у вас данных, чтобы показать, какая услуга должна быть отдельной и почему? Распределенные системы созданы с учетом размера и устойчивости. Может ли ваша система масштабироваться и быть устойчивой одновременно? Что произойдет, если одна из служб выйдет из строя или выйдет из строя? Просто увеличить масштаб? А как насчет других сервисов, которые столкнутся с трафиком? Вы участвовали в бесконечных перестановках вещей, которые могут и могут пойти не так? Есть ли противодавление? Автоматические выключатели? Очереди? Джиттер? Разумные тайм-ауты на каждой конечной точке? Существуют ли надежные средства защиты от простого изменения, которые не приведут к сбою всего? Ручки, о которых вам нужно знать и которые нужно настраивать, бесконечны, и все они зависят от особенностей использования и нагрузки вашей системы.

Простой вопрос – какую проблему вы решаете? Это масштаб? Откуда вы знаете, как разбить так, чтобы это масштабировалось и имело хорошую производительность? Достаточно ли у вас данных, чтобы показать, какой сервис должен быть отдельным и почему? Распределенные системы созданы с учетом размера и устойчивости. Может ли ваша система масштабироваться и быть устойчивой одновременно? Что произойдет, если один из сервисов выйдет из строя или начнёт ползти? Просто увеличьте масштаб, да? А как насчет других сервисов, которые столкнутся с трафиком? Вы участвовали в бесконечных перестановках вещей, которые могут и могут пойти не так? Есть ли обратное давление? Автоматические выключатели? Очереди? Джиттер? Разумные тайм-ауты на каждой конечной точке? Существуют ли надежные средства защиты от простого изменения, которые не приведут к сбою всего? Ручки, о которых вам нужно знать и настраивать, бесконечны, и все они зависят от особенностей использования и трафика вашей системы.

Правда в том, что большинство компаний никогда не достигнут огромных размеров, которые фактически потребуют создания настоящей распределенной системы. Ваш косплей на Amazon и Google – без их масштаба, опыта и бесконечных ресурсов – скорее всего, просто вопиющая трата денег и времени. Неукоснительное следование всем шагам из статьи «Десять утренних привычек очень успешных людей» не сделает вас миллиардером.

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

Единственная вещь сложнее распределенной системы — это ПЛОХАЯ распределенная система.

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

«Но каждая команда… но отдельная… но API»

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

Теория приятна и элегантна: каждый микросервис строго поддерживается специальной командой, окруженной красивым API с обратной совместимостью и версионированием. На самом деле, это настолько надежно, что вам даже редко приходится общаться с этой командой — как если бы микросервис обслуживался сторонним поставщиком. Это просто!

Теория приятна и элегантна: каждый микросервис строго поддерживается специальной командой, окруженной красивым API с обратной совместимостью и версионированием. На самом деле, все настолько жестко, что вам даже редко приходится общаться с этой командой — как если бы микросервис обслуживался сторонним поставщиком. Это просто!

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

Чтобы выиграть гонку, мы не строим одну хорошую гоночную машину — мы строим парк дерьмовых гольф-каров.

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

Что ты теряешь

Что вы теряете

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

Попрощайтесь с DRY

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

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

Есть общая библиотека?

Как обновляется общая библиотека? Хранить везде разные версии?

Регулярно устанавливать обновления, создавая десятки запросов на включение во все репозитории?

Хранить все это в монорепозитории? Это сопряжено со своими проблемами.

Разрешить некоторое дублирование кода?

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

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

Эргономика разработчиков ухудшится

«Эргономика разработчика» — это трение, количество усилий, которые должен приложить разработчик, чтобы что-то сделать, будь то работа над новой функцией или устранение ошибки.

При использовании микросервисов инженер должен иметь мысленную карту всей системы, чтобы знать, какие сервисы использовать для выполнения той или иной конкретной задачи, с какими командами общаться, с кем разговаривать и о чем. Принцип «надо все знать, прежде чем что-то делать». Как вам удается оставаться на высоте? Spotify, компания с оборотом в несколько миллиардов долларов, потратила, вероятно, немало внутренних ресурсов на создание Backstage, программного обеспечения для каталогизации своих бесконечных систем и сервисов.

Это должно, по крайней мере, дать вам понять, что эта игра не для всех, и цена поездки высока. Так что насчет инструментов? Не-Spotify мира остаются с MacGyvering своими собственными решениями, о надежности и портативности которых вы, вероятно, можете догадаться.

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

А сколько команд реально упрощают процесс запуска YASS — «еще одного дурацкого сервиса»? Это включает в себя:

Права разработчика в GitHub/GitLab

Переменные среды и конфигурация по умолчанию

CI/CD

Проверка качества кода

Настройки проверки кода

Код ревью

Правила филиала и защита

Правила работы с ветками и защита

Мониторинг и наблюдаемость

Тестовый жгут

Тестирование

Инфраструктура как код

IoT

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

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

Интеграционные тесты - лол

Интеграционные тесты - LOL

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

Сервисные тесты

Интеграционное тестирование распределенной системы — практически неразрешимая задача, поэтому мы практически отказались от нее и заменили ее другой — Observability. Точно так же, как «микросервисы» — это новые «распределенные системы», «наблюдаемость» — это новая «отладка в производстве». Конечно, вы не напишете настоящее программное обеспечение, если не сделаете…. наблюдательность!

Наблюдение стало отдельным сектором, и за него вы заплатите как немалые деньги, так и время разработчика. Это также не предполагает «подключи и плати» — вам нужно понимать и внедрять канареечные выпуски, флаги функций и т. д. Кто этим занимается? Один уже перегруженный инженер?

Наблюдаемость стала отдельным сектором, и за него вы заплатите, как немалыми деньгами, так и временем разработчика. Это также не предполагает «подключи и плати» — вам нужно понимать и внедрять канареечные выпуски, флаги функций и т. д. Кто этим занимается? Один уже перегруженный инженер?

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

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

А как насчет просто «услуг»?

А как насчет просто «сервисов»?

Почему ваши услуги должны быть «микро»? Что плохого в просто услугах? Некоторые стартапы дошли до того, что создали сервис для каждой функции, и да, «разве это не похоже на Lambda» — это правильный вопрос. Это дает вам представление о том, как далеко зашел этот неконтролируемый карго-культ.

Почему ваши сервисы должны быть «микро»? Что плохого в обычных сервисах? Некоторые стартапы дошли до того, что создали сервис для каждой функции, и да, «разве это не похоже на Lambda» будет справедливым вопросом. Это дает вам представление о том, как далеко зашел этот неконтролируемый карго-культ.

Так что же нам делать? Начать с монолита — один из очевидных вариантов. Во многих случаях также может работать шаблон «ствол и филиалы», где основному монолиту «мяса и картофеля» помогают сервисы «филиалов». Служба филиала может быть службой, которая заботится о четко идентифицируемой и отдельно масштабируемой нагрузке. Служба изменения размера изображений, требовательная к процессору, имеет гораздо больше смысла, чем служба регистрации пользователей. Или у вас столько регистраций в секунду, что это требует независимого горизонтального масштабирования?

Так что же нам делать? Начать с монолита — один из очевидных вариантов. Во многих случаях также может работать шаблон «trunk and branches», где основному монолиту «meat and potatoes» помогают branch-сервисы. Branch-сервис может быть сервисом, который заботится о четко идентифицируемой и отдельно масштабируемой нагрузке. Сервис изменения размера изображений, требовательный к процессору, имеет гораздо больше смысла, чем сервис регистрации пользователей. Или у вас столько регистраций в секунду, что это требует независимого горизонтального масштабирования?

Вертикальный

Примечание: во времена CVS и Subversion в системе контроля версий мы редко использовали «главные» ветки. У нас был «ствол и ветки», потому что, знаете ли, *деревья*. «Главные» ветки появились где-то по пути, и когда GitHub решил покончить с довольно неудачным соглашением об именах, средний инженер был слишком молод, чтобы помнить о «магистрали» - и поэтому появилось общее «основное» значение по умолчанию.

Примечание: во времена CVS и Subversion в системе контроля версий мы редко использовали «master» ветки. У нас был «trunk and branches», потому что, знаете ли, деревья. «Master» ветки появились где-то по пути, и когда GitHub решил покончить с довольно неудачным соглашением об именах, среднестатистический инженер был слишком молод, чтобы запомнить шаблон «trunk/branches», и поэтому появилось общее «main» значение по умолчанию.

Убер

Маятник качнулся назад

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

Вертикальный

АВС

Убер

В конечном счете, когда вам необходимо поехать из Нью-Йорка в Филадельфию, у вас есть два варианта. Вы можете либо попытаться построить очень сложный космический корабль для спуска по орбите к месту назначения, либо просто купить билет на поезд Amtrak и совершить 90-минутную поездку. Вот в чем проблема.

Saved diffs

Original text

Open file

Смерть от тысячи микросервисов

Церковь сложности

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

Как мы здесь оказались? Как наша цель заключалась не в решении поставленной задачи, а в поджоге кучи денег путем решения проблем, которых у нас нет?
Триггерное предупреждение: некоторые люди, по понятным причинам, рассердились, когда я назвал JavaScript и NodeJS источником проблемы, но на самом деле моя точка зрения была больше об опасностях герметично закрытых программных экосистем, которые, кажется, одержимы повторным изучением уроков, которые мы только что закончил учиться. Раньше мы столкнулись со стеной сложности и выполнили сброс — иначе мы бы все равно использовали CORBA и SOAP. Эти герметичные пузыри разработчиков представляют собой разрушительный шар для всей отрасли, и на то, чтобы их развернуть, требуется около десяти лет.
Идеальный шторм

В недавней истории есть несколько событий, которые, возможно, способствовали нынешнему положению вещей. Во-первых, целая армия разработчиков, пишущих JavaScript для браузера, начала идентифицировать себя как «full-stack», погрузившись в серверную разработку и асинхронный код. JavaScript — это JavaScript, верно? Какая разница, что вы создадите с его помощью — пользовательские интерфейсы, серверы, игры или встроенные системы. Верно? Node все еще был своего рода учебным проектом одного человека, а ранний JavaScript был крайне проблематичным выбором для разработки серверов. Указание на это еще зеленым разработчикам серверной части обычно приводило к большому раздражению и пыхтению. В конце концов, это все, что они знали. Мира за пределами Node фактически не существовало, путь Node был единственным путем, и это послужило источником упрямого, догматического мышления, с которым мы имеем дело по сей день.
Производительность

А затем постоянный поток ветеранов FAANG начал сливаться с рекой стартапов, обучая новоявленных и очень впечатлительных молодых серверных инженеров JavaScript. Апостолы Церкви Сложности настойчиво заявляли, что «то, как они поступили в Google», было неоспоримо и правильно – даже если это не имело смысла в данном контексте и размере. Что значит, что у вас нет отдельной службы пользовательских настроек? Это просто не масштабируется, братан!

Но во всем этом легко обвинить ветеранов и новичков. Что еще происходило? Ах да, легкие деньги.

Что вы делаете, когда у вас полно венчурного капитала? Конечно, вы не гонитесь за прибылью! Я не раз получал электронные письма от руководства, в которых просил всех быть в офисе, навести порядок на своих столах и выглядеть занятыми, поскольку по помещению собирались промаршировать облачком с жилетами Patagonia. Инвесторам нужно было увидеть взрывной рост, но не прибыльность, нет. Им просто нужно было посмотреть, как быстро компания сможет нанять сверхдорогих инженеров-программистов, чтобы сделать… что-нибудь.
Renegade Otter — разработчик Friendly Fire — умного запроса на включение для GitHub:

     Подключите пользователей GitHub к Slack и уведомляйте напрямую
     Пропустить рецензентов, которые недоступны
     Сопоставление шаблонов файлов
     Индивидуальные напоминания о проверке кода
     Доступ к вашей кодовой базе не требуется

И теперь, когда у вас есть эти разработчики, что вы с ними делаете? Что ж, они могли бы построить более простую систему, которую легче развивать и поддерживать, или они могли бы создать чудовищное созвездие «микросервисов», которое никто толком не понимает. Микросервисы — новый способ написания масштабируемого программного обеспечения! Собираемся ли мы просто притвориться, что понятия «распределенные системы» никогда не существовало? (Давайте опустим весь разбор нюансов о том, что микросервисы не являются настоящими распределенными системами).

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

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

Мне нравится ссылаться на этот отчет о 5-летнем аудите стартапов, поскольку он наполнен здравыми выводами:

…Проверенные нами стартапы, которые сейчас преуспевают лучше всего, обычно придерживаются почти наглого подхода к проектированию «сохраняйте простоту». Ум ради ума ненавидели. С другой стороны, компании, в которых мы говорили: «Ого, эти люди чертовски умные», по большей части исчезли.

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

Буквально – «сложность убивает».

Аудит выявил интересную закономерность: многие стартапы испытывали своего рода синдром коллективного самозванца, создавая понятные, простые и производительные системы. Не начинать работу с микросервисами с первого же дня — это клеймо, независимо от проблемы. «Все занимаются микросервисами, а у нас есть единый монолит Django, поддерживаемый всего несколькими инженерами, и экземпляр MySQL — что мы делаем не так?». Ответ почти всегда «ничего».

Точно так же в современном мире технологий опытные инженеры очень часто испытывают колебания и неадекватность, и хорошая новость в том, что нет, скорее всего, это не вы. Команды часто делают вид, что занимаются «веб-масштабированием», прячась за библиотеками, ORM и кешем — будучи уверенными в своих знаниях (они разгромили этот Leetcode!), но они могут даже не знать об основах индексации баз данных. Вы действуете в море неоправданной самоуверенности, расточительства и Даннинга-Крюгера, так кто же здесь на самом деле самозванец?
В монолите нет ничего плохого.

Идея о том, что невозможно расти без системы, напоминающей печально известный провал военной стратегии в Афганистане, является мифом.

Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify, StackOverflow — эти и другие компании начинали как монолитные базы кода. Многие по сей день имеют в своей основе монолит. StackOverflow гордится тем, как мало оборудования им нужно для работы огромного сайта. Shopify по-прежнему остается монолитом Rails, использующим проверенный и надежный Resque для обработки миллиардов задач.

WhatsApp стал сверхновой благодаря своему монолиту Erlang и относительно небольшой команде. Как?

     WhatsApp сознательно сохраняет небольшой штат инженеров — всего около 50 инженеров.

     Отдельные инженерные группы также невелики и состоят из 1–3 инженеров, и каждая группа обладает значительной автономией.

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

Instagram был приобретен за миллиарды — с командой из 12 человек.

И вы представляете себе Threads как проект, охватывающий весь Мета-кампус? Неа. Они следовали модели Instagram, а это вся команда Threads:
Кредит: Substack — Инженер-прагматик

Возможно, утверждение, что ваша конкретная проблемная область требует чрезвычайно сложной распределенной системы и открытого офиса, доверху набитого турбо-гениями, просто переходит в высокомерие, а не в гениальность?
Не решайте проблемы, которых у вас нет

Простой вопрос – какую проблему вы решаете? Это масштаб? Откуда вы знаете, как разбить все это на масштаб и производительность? Достаточно ли у вас данных, чтобы показать, какая услуга должна быть отдельной и почему? Распределенные системы созданы с учетом размера и устойчивости. Может ли ваша система масштабироваться и быть устойчивой одновременно? Что произойдет, если одна из служб выйдет из строя или выйдет из строя? Просто увеличить масштаб? А как насчет других сервисов, которые столкнутся с трафиком? Вы участвовали в бесконечных перестановках вещей, которые могут и могут пойти не так? Есть ли противодавление? Автоматические выключатели? Очереди? Джиттер? Разумные тайм-ауты на каждой конечной точке? Существуют ли надежные средства защиты от простого изменения, которые не приведут к сбою всего? Ручки, о которых вам нужно знать и которые нужно настраивать, бесконечны, и все они зависят от особенностей использования и нагрузки вашей системы.

Правда в том, что большинство компаний никогда не достигнут огромных размеров, которые фактически потребуют создания настоящей распределенной системы. Ваш косплей на Amazon и Google – без их масштаба, опыта и бесконечных ресурсов – скорее всего, просто вопиющая трата денег и времени. Неукоснительное следование всем шагам из статьи «Десять утренних привычек очень успешных людей» не сделает вас миллиардером.

Единственная вещь сложнее распределенной системы — это ПЛОХАЯ распределенная система.
Производительность
«Но каждая команда… но отдельная… но API»

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

Теория приятна и элегантна: каждый микросервис строго поддерживается специальной командой, окруженной красивым API с обратной совместимостью и версионированием. На самом деле, это настолько надежно, что вам даже редко приходится общаться с этой командой — как если бы микросервис обслуживался сторонним поставщиком. Это просто!

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

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

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

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

     Есть общая библиотека?
     Как обновляется общая библиотека? Хранить везде разные версии?
     Регулярно устанавливать обновления, создавая десятки запросов на включение во все репозитории?
     Хранить все это в монорепозитории? Это сопряжено со своими проблемами.
     Разрешить некоторое дублирование кода?
     Забудьте об этом, каждая команда каждый раз изобретает велосипед.

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

«Эргономика разработчика» — это трение, количество усилий, которые должен приложить разработчик, чтобы что-то сделать, будь то работа над новой функцией или устранение ошибки.

При использовании микросервисов инженер должен иметь мысленную карту всей системы, чтобы знать, какие сервисы использовать для выполнения той или иной конкретной задачи, с какими командами общаться, с кем разговаривать и о чем. Принцип «надо все знать, прежде чем что-то делать». Как вам удается оставаться на высоте? Spotify, компания с оборотом в несколько миллиардов долларов, потратила, вероятно, немало внутренних ресурсов на создание Backstage, программного обеспечения для каталогизации своих бесконечных систем и сервисов.

Это должно, по крайней мере, дать вам понять, что эта игра не для всех, и цена поездки высока. Так что насчет инструментов? Не-Spotify мира остаются с MacGyvering своими собственными решениями, о надежности и портативности которых вы, вероятно, можете догадаться.

А сколько команд реально упрощают процесс запуска YASS — «еще одного дурацкого сервиса»? Это включает в себя:

     Права разработчика в GitHub/GitLab
     Переменные среды и конфигурация по умолчанию
     CI/CD
     Проверка качества кода
     Настройки проверки кода
     Правила филиала и защита
     Мониторинг и наблюдаемость
     Тестовый жгут
     Инфраструктура как код

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

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

Интеграционное тестирование распределенной системы — практически неразрешимая задача, поэтому мы практически отказались от нее и заменили ее другой — Observability. Точно так же, как «микросервисы» — это новые «распределенные системы», «наблюдаемость» — это новая «отладка в производстве». Конечно, вы не напишете настоящее программное обеспечение, если не сделаете…. наблюдательность!

Наблюдение стало отдельным сектором, и за него вы заплатите как немалые деньги, так и время разработчика. Это также не предполагает «подключи и плати» — вам нужно понимать и внедрять канареечные выпуски, флаги функций и т. д. Кто этим занимается? Один уже перегруженный инженер?

Как видите, дробление проблемы не облегчает ее решение: вы получаете лишь еще один набор еще более сложных проблем.
А как насчет просто «услуг»?

Почему ваши услуги должны быть «микро»? Что плохого в просто услугах? Некоторые стартапы дошли до того, что создали сервис для каждой функции, и да, «разве это не похоже на Lambda» — это правильный вопрос. Это дает вам представление о том, как далеко зашел этот неконтролируемый карго-культ.

Так что же нам делать? Начать с монолита — один из очевидных вариантов. Во многих случаях также может работать шаблон «ствол и филиалы», где основному монолиту «мяса и картофеля» помогают сервисы «филиалов». Служба филиала может быть службой, которая заботится о четко идентифицируемой и отдельно масштабируемой нагрузке. Служба изменения размера изображений, требовательная к процессору, имеет гораздо больше смысла, чем служба регистрации пользователей. Или у вас столько регистраций в секунду, что это требует независимого горизонтального масштабирования?
Вертикальный
Примечание: во времена CVS и Subversion в системе контроля версий мы редко использовали «главные» ветки. У нас был «ствол и ветки», потому что, знаете ли, *деревья*. «Главные» ветки появились где-то по пути, и когда GitHub решил покончить с довольно неудачным соглашением об именах, средний инженер был слишком молод, чтобы помнить о «магистрали» - и поэтому появилось общее «основное» значение по умолчанию.
Убер
Маятник качнулся назад

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

В конечном счете, когда вам необходимо поехать из Нью-Йорка в Филадельфию, у вас есть два варианта. Вы можете либо попытаться построить очень сложный космический корабль для спуска по орбите к месту назначения, либо просто купить билет на поезд Amtrak и совершить 90-минутную поездку. Вот в чем проблема.

Changed text

Open file

Смерть от тысячи микросервисов

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

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

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

В недавней истории есть несколько вещей, которые, возможно, способствовали нынешнему положению. Во-первых, целая армия разработчиков, пишущих JavaScript для браузера, начала идентифицировать себя как «full-stack», погружаясь в серверную разработку и асинхронный код. JavaScript — это JavaScript, верно? Какая разница, что вы создадите с его помощью — пользовательские интерфейсы, серверы, игры или встроенные системы. Верно? Node все еще был своего рода учебным проектом одного человека, а JavaScript тогда был крайне проблематичным выбором для разработки серверов. Указание на это, еще зеленым разработчикам серверной части, обычно приводило к большому раздражению и пыхтению. В конце концов, это все, что они знали. Мира за пределами Node фактически не существовало, путь Node был единственным известным путем, и это послужило источником упрямого, догматического мышления, с которым мы имеем дело по сей день.

А затем постоянный поток ветеранов FAANG начал сливаться с рекой стартапов, обучая новоиспеченных и очень впечатлительных молодых серверных инженеров JavaScript. Апостолы Церкви Сложности настойчиво заявляли, что «то, как они действовали в Google», было неоспоримым и правильным, даже если это не имело смысла в нынешнем контексте и размере. Что значит, что у вас нет отдельной службы пользовательских настроек? Это просто не масштабируется, братан!

Но во всем этом легко обвинить ветеранов и новичков. Что еще происходило? Ах да, легкие деньги.

Что вы делаете, когда у вас полно венчурного капитала? Конечно, вы не гонитесь за прибылью! Я не раз получал электронные письма от руководства, в которых просили всех быть в офисе, наводить порядок на своих столах и выглядеть занятыми, поскольку по офису собирались пройти парадом жилеты Patagonia. Инвесторам нужно было увидеть взрывной рост, но не прибыльность, нет. Им просто нужно было посмотреть, как быстро компания сможет нанять сверхдорогих инженеров-программистов, чтобы сделать… что-нибудь.

И теперь, когда у вас есть эти разработчики, что вы с ними делаете? Они могли бы создать более простую систему, которую легче развивать и поддерживать, или они могли бы создать чудовищное созвездие «микросервисов», которое никто толком не понимает. Микросервисы — новый способ написания масштабируемого программного обеспечения! Собираемся ли мы просто притвориться, что понятия «распределенные системы» никогда не существовало? (Опустим весь разбор нюансов о том, что микросервисы не являются настоящими распределенными системами).

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

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

Мне нравится ссылаться на этот отчет о 5-летнем аудите стартапов, поскольку он наполнен здравыми выводами, основанными на веских доказательствах (и платных идеях):

…Проверенные нами стартапы, которые сейчас преуспевают лучше всего, обычно придерживаются почти наглого подхода к проектированию «сохраняйте простоту». Ум ради ума ненавидели. С другой стороны, компании, в которых мы говорили: «Ого, эти люди чертовски умные», по большей части исчезли.

Буквально – «сложность убивает».

Аудит выявил интересную закономерность: многие стартапы испытывали своего рода синдром коллективного самозванца, создавая понятные, простые и производительные системы. Существует догма, запрещающая начинать работу с микросервисами с первого дня, независимо от проблемы. «Все занимаются микросервисами, а у нас есть единый монолит Django, поддерживаемый всего несколькими инженерами, и экземпляр MySQL — что мы делаем не так?». Ответ был почти всегда: «ничего».

Точно так же опытные инженеры часто испытывают колебания и неадекватность в современном мире технологий, и хорошая новость в том, что нет, вероятно, это не вы. Команды часто притворяются, будто занимаются «веб-масштабированием», прячась за библиотеками, ORM и кешем — будучи уверенными в своих знаниях (они разгромили этот Leetcode!), но они могут даже не знать об основах индексации баз данных. Вы действуете в море неоправданной самоуверенности, расточительства и Даннинга-Крюгера, так кто же здесь на самом деле самозванец?
В монолите нет ничего плохого

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

Dropbox, Twitter/X, Facebook, Instagram, Shopify, Stack Overflow — эти и другие компании начинали как монолитные базы кода. Многие по сей день имеют в своей основе монолит. Stack Overflow вызывает гордость за то, как мало оборудования им нужно для работы огромного сайта. Shopify по-прежнему остается монолитом Rails, использующим проверенный и надежный Resque для обработки миллиардов задач.

WhatsApp стал сверхновой благодаря монолиту Erlang и 50 инженерам. Как?

WhatsApp сознательно сохраняет небольшой штат инженеров — всего около 50 инженеров.

Отдельные инженерные группы также невелики и состоят из 1–3 инженеров, и каждая группа обладает значительной автономией.

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

Instagram был приобретен за миллиарды — с командой из 12 человек.

И вы представляете себе Threads как проект, охватывающий весь Мета-кампус? Неа. Они следовали модели Instagram. Вот их команда:

Возможно, утверждение, что ваша конкретная проблемная область требует чрезвычайно сложной распределенной системы и открытого офиса, доверху набитого турбо-гениями, просто переходит в высокомерие, а не в гениальность?
Не решайте проблемы, которых у вас нет

Простой вопрос – какую проблему вы решаете? Это масштаб? Откуда вы знаете, как разбить так, чтобы это масштабировалось и имело хорошую производительность? Достаточно ли у вас данных, чтобы показать, какой сервис должен быть отдельным и почему? Распределенные системы созданы с учетом размера и устойчивости. Может ли ваша система масштабироваться и быть устойчивой одновременно? Что произойдет, если один из сервисов выйдет из строя или начнёт ползти? Просто увеличьте масштаб, да? А как насчет других сервисов, которые столкнутся с трафиком? Вы участвовали в бесконечных перестановках вещей, которые могут и могут пойти не так? Есть ли обратное давление? Автоматические выключатели? Очереди? Джиттер? Разумные тайм-ауты на каждой конечной точке? Существуют ли надежные средства защиты от простого изменения, которые не приведут к сбою всего? Ручки, о которых вам нужно знать и настраивать, бесконечны, и все они зависят от особенностей использования и трафика вашей системы.

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

Единственная вещь сложнее распределенной системы — это ПЛОХАЯ распределенная система.

«Но каждая команда… но отдельная… но API»

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

Теория приятна и элегантна: каждый микросервис строго поддерживается специальной командой, окруженной красивым API с обратной совместимостью и версионированием. На самом деле, все настолько жестко, что вам даже редко приходится общаться с этой командой — как если бы микросервис обслуживался сторонним поставщиком. Это просто!

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

Чтобы выиграть гонку, мы не строим одну хорошую гоночную машину — мы строим парк дерьмовых гольф-каров.

Что вы теряете

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

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

    Есть общая библиотека?
    Как обновляется общая библиотека? Хранить везде разные версии?
    Регулярно устанавливать обновления, создавая десятки запросов на включение во все репозитории?
    Хранить все это в монорепозитории? Это сопряжено со своими проблемами.
    Разрешить некоторое дублирование кода?
    Забудьте об этом, каждая команда каждый раз изобретает велосипед.

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

«Эргономика разработчика» — это трение, количество усилий, которые должен приложить разработчик, чтобы что-то сделать, будь то работа над новой функцией или устранение ошибки.

При использовании микросервисов инженер должен иметь мысленную карту всей системы, чтобы знать, какие сервисы использовать для выполнения той или иной конкретной задачи, с какими командами общаться, с кем разговаривать и о чем. Принцип «надо все знать, прежде чем что-то делать». Как вам удается оставаться на высоте? Spotify, компания с оборотом в несколько миллиардов долларов, потратила, вероятно, немало внутренних ресурсов на создание Backstage, программного обеспечения для каталогизации своих бесконечных систем и сервисов.

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

А сколько команд реально упрощают процесс запуска YASS — «еще одного дурацкого сервиса»? Это включает в себя:

    Права разработчика в GitHub/GitLab
    Переменные среды и конфигурация по умолчанию
    CI/CD
    Проверка качества кода
    Код ревью
    Правила работы с ветками и защита
    Мониторинг и наблюдаемость
    Тестирование
    IoT

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

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

Интеграционное тестирование распределенной системы — практически неразрешимая задача, поэтому мы практически отказались от нее и заменили ее другой — Observability. Точно так же, как «микросервисы» — это новые «распределенные системы», «наблюдаемость» — это новая «отладка в производстве». Конечно, вы не напишете настоящее программное обеспечение, если не сделаете…. наблюдаемость!

Наблюдаемость стала отдельным сектором, и за него вы заплатите, как немалыми деньгами, так и временем разработчика. Это также не предполагает «подключи и плати» — вам нужно понимать и внедрять канареечные выпуски, флаги функций и т. д. Кто этим занимается? Один уже перегруженный инженер?

Как видите, дробление проблемы не облегчает ее решение: вы получаете другой набор еще более сложных проблем.
А как насчет просто «сервисов»?

Почему ваши сервисы должны быть «микро»? Что плохого в обычных сервисах? Некоторые стартапы дошли до того, что создали сервис для каждой функции, и да, «разве это не похоже на Lambda» будет справедливым вопросом. Это дает вам представление о том, как далеко зашел этот неконтролируемый карго-культ.

Так что же нам делать? Начать с монолита — один из очевидных вариантов. Во многих случаях также может работать шаблон «trunk and branches», где основному монолиту «meat and potatoes» помогают branch-сервисы. Branch-сервис может быть сервисом, который заботится о четко идентифицируемой и отдельно масштабируемой нагрузке. Сервис изменения размера изображений, требовательный к процессору, имеет гораздо больше смысла, чем сервис регистрации пользователей. Или у вас столько регистраций в секунду, что это требует независимого горизонтального масштабирования?

Примечание: во времена CVS и Subversion в системе контроля версий мы редко использовали «master» ветки. У нас был «trunk and branches», потому что, знаете ли, деревья. «Master» ветки появились где-то по пути, и когда GitHub решил покончить с довольно неудачным соглашением об именах, среднестатистический инженер был слишком молод, чтобы запомнить шаблон «trunk/branches», и поэтому появилось общее «main» значение по умолчанию.

Маятник качнулся назад

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

В конечном счете, когда вам необходимо поехать из Нью-Йорка в Филадельфию, у вас есть два варианта. Вы можете либо попытаться построить очень сложный космический корабль для спуска по орбите к месту назначения, либо просто купить билет на поезд Amtrak и совершить 90-минутную поездку. Вот и всё!