Давид Хейнемейер Ханссон - основатель Basecamp, создатель Ruby on Rails и автор книги “Remote. Офис не обязателен” опубликовал статью, где “прет против” микросервисной архитектуры и восхваляет монолитный подход.
Если бы не все его регалии и мелькнувшая статья “Даже Amazon не может разобраться в serverless и микросервисах” можно было пропустить такое “мимо ушей”. Но, все чаще звучащие мнения о сложности, ненужности, опасности, дороговизне микросервисного подхода заставляют, как минимум обратить на них внимание и посмотреть - а в чем же на самом деле там проблема?
Далее привожу перевод статьи Давид Хейнемейер Ханссона.
Как уйти от микросервисов?
Я не буду отрицать, что вполне могут быть случаи, когда архитектура, ориентированная на микросервисы, имеет смысл, но я думаю, что их немного и эти случаи далеки друг от друга. Подавляющее большинство систем гораздо лучше обслуживаются, если их архитектура изначально была основана на монолите и продолжает оставаться такой. Тематическое исследование Prime Video, которое взорвало Интернет — очередная иллюстрация этому.
Возможно, как только вы достигнете масштаба Netflix или Amazon, появятся области, в которых это станет иметь смысл. Но помните, что даже такие монстры, как GitHub и Shopify запускают свои основные приложения как монолиты с миллионами строк кода, над которыми работают тысячи программистов. У вас есть миллионы строк кода или тысячи программистов, работающих над одним и тем же кодом? Если нет, то проявляйте крайнюю осторожность, прежде чем даже думать о микросервисах.
Это совет для тех, кто сегодня запускает новые системы. Что делать, если вы уже и преждевременно перешли на архитектуру микросервисов? Как вернуться? Вот несколько советов:
1) Прекратите копать. Вы не можете навести порядок, пока не перестанете делать беспорядок. Это означает, что не нужно разрабатывать новые микросервисы. Вместо этого, нужно выбрать один из существующих микросервисов и сделать его новым центром, который будет нести новые функции. Этот новый центр должен в конечном итоге включить в себя и большую часть остальных микросервисов. Самое главное - не ухудшить ситуацию.
2) Сначала консолидируйте критические зависимые пути. Худшая форма безумия микросервисов - это когда вы разбиваете единый, согласованный поток на несколько систем. Это может быть регистрация, оформление заказа, либо отображение отдельного фрагмента контента. Именно здесь микросервисы наносят наибольший вред, делая обновление всего потока громоздким и подверженным ошибкам. Внесение изменений означает координацию между несколькими системами, решение проблем с синхронизацией и многое другое. Ваше преобразование микросервисов в макросервисы на обратном пути к монолиту должно начаться здесь.
3) Оставьте изолированные точки производительности напоследок. Когда микросервисы написаны правильно, они фокусируются на узком, изолированном и обычно критически важном к производительности сегменте системы, который можно улучшить, переписав его на более сложный, но быстрый язык программирования. Возможно, ваше веб-приложения написано на Ruby on Rails, но есть одна часть, которая подвержена резким скачкам нагрузки и по некоторым причинам ее нельзя кэшировать. Поэтому вы используете Rust или Go, чтобы максимально выжать производительность из вашего процессора. Поздравляю, вы справились с микросервисом на отлично! (Просто не забудьте провести сравнительный анализ и доказать, что результат стоил потраченных усилий).
4) Расставьте приоритеты в отказе от наиболее эзотерических реализаций. Одним из ужасных побочных эффектов безумия микросервисов является тенденция использовать миллион различных языков программирования, фреймворков и экосистем. Подобно сладкоголосым сиренам из сказок, песня микросервисов поет небылицы об изоляции, которые пробуждают мечты ИТ-директоров о «лучшем в своем роде» языке, фреймворке и т.п. и подстегивает естественную склонность программистов экспериментировать с чем-то новым и необычным, настолько насколько это возможно.
Конечным результатом вполне может быть система, состоящая из 3-5-7 разных языков программирования, еще более разнообразных фреймворков и множества зависимостей. Это убивает понимание концепции и приводит к общему симптому микросервисов: «никто не понимает и не может работать со всей системой».
Таким образом, вам необходимо приступить к обрезке кода. В большинстве систем следует использовать не более двух языков программирования одновременно: язык общего назначения для повышения производительности программистов, который можно использовать в 99% ситуаций, и высокопроизводительный язык для обращения к оставшемуся 1% наиболее горячих точек в случае необходимости.
5) Научитесь разделять большие системы с помощью модулей, а не сетей. Большая часть мотивации для разработки микросервисов основывалась на заблуждении, что, если вы не умеете правильно проектировать большие системы, используя модули и пространства имён, то можно решить проблему, разделив её сетевыми границами. Но нет, нет, нет.
Создать большую, отказоустойчивую и производительную систему сложно. Попытка разработать его для нового проблемного пространства в первый же день невозможна. Прислушайтесь к вечному совету Джона Галла:
Сложная система, которая работает, всегда оказывается развившейся из простой системы, которая работает. Обратное утверждение также кажется верным: сложная система, созданная с нуля, никогда не работает и ее нельзя заставить работать.
Простота требует, чтобы вы не приглашали на первый танец распределенную систему чудовищной сложности. Вполне возможно, что в один прекрасный день вам придется работать с распределенными системами, использующими микросервисы. Но это произойдет только с чистой совестью и только, если вы начнете с простой монолитной конструкции.
Ключевым томом для изучения того, как разбивать большие проблемные области на красивые модели предметной области, является «Дизайн, управляемый предметной областью» Эрика Эвана . Но вы должны перейти на этот уровень стратегических, архитектурных устремлений только после того, как освоите основы тактического программирования с помощью таких книг, как « Лучшие практики Smalltalk» Кента Бека (если вы работаете с объектно-ориентированными языками) и Мартина Фаулера.Шаблоны архитектуры корпоративных приложений .
Наша отрасль полна ярких, увлеченных людей. Многие из них хотят победить гонку Iron Man, даже не пробежав 5 км. Как бы я ни восхищался сообразительностью и уверенностью в себе и не верил в общее правило ограничения скорости обучения , я также думаю, что мы оказали многим из них медвежью услугу, не прояснив ранее опасности микросервисов.
Самое замечательное в обучении - вы всегда можете начать! И если изучение чего-то нового заставляет вас иначе размышлять о сделанном ранее выборе, то вы можете изменить свой подход с этого дня.
Да, микросервисы - это инструмент, как и любые шаблоны программирования. Но, мы не должны давать никаких рекомендаций, чтобы разработать более совершенную систему, просто сказав "это зависит от…". Мы должны быть готовы объяснить, ОТ ЧЕГО ЗАВИСИТ РЕШЕНИЕ. Простое заявление "это зависит…", не помогает людям принимать лучшие решения.
Итак, давайте проясним. Использование микросервисов обычно зависит от:
а) Наличия большой сложной системы, которая успешно развилась из небольшой простой системы.
б) Возможности идентифицировать часть модульной конструкции, которая имеет четкие границы и не имеет критических зависимостей, в качестве кандидата для извлечения. Затем приступайте только в том случае, если есть значительный прирост производительности за счет изменения подхода к внедрению или есть организационные преимущества от размещения модуля целой командой, которая не может легко сотрудничать с остальными разработчиками системы.
Вы вполне можете найти другие оправдания в вашей системе или организации, но они должны быть четко сформулированы, тщательно изучены и подвергнуты критическому анализу, прежде чем приступать к микросервисам.
Или, вы знаете, вы можете просто весело провести время, разбивая архитектуру вашей системы на десятки частей, а затем вернуться к этому руководству, когда похмелье будет достаточно болезненным. Величественный монолит всегда будет рядом, когда вы будете готовы насладиться его простотой и мудростью. Выбери свое собственное приключение!
