Немного про монолит vs микросервисы, начитавшись архитектурных трендов (InfoQ, "Architecture trends 2023")

Немного про монолит vs микросервисы, начитавшись архитектурных трендов (InfoQ, "Architecture trends 2023"). Из самых горячих инноваций, которые уже вошли в ИТ, прежде всего, конечно AI в формате LLM. Уже здесь также HTTP/3, GraphQL Federation (общий шлюз для сервисов с разными схемами БД, генерирующий единый API для всех) и всяческая децентрализация и блокчейны.

Начинают активно применяться, хотя и не так массово,

WebAssembly не только на клиенте, но и на сервере;

проектирование с глубинным акцентом на безопасности, стойкости и экологичности (в буквальном смысле — потреблять поменьше энергии);

микрофронтенд (попытка уйти от монолита к подобию сервисной архитектуры уже на фронте, VK Tech на днях кстати рассказывал).

Более старшие архитектурные темки: Data-driven architecture, всевозможные асинхронные API, lowcode/nocode (все они однако в этом статусе early adopters наверное уже не один десяток лет),

архитектура как спорт — используем ADR (architecture decision records, выжимки из обсуждений) для организации социалистического соревновании между инженерами,

модульные монолиты (хорошее), модель акторов, функциональное программирование, безсерверные подходы, микросервисы, CQRS (и вот это традиционно сильная вещь, очень одобряю), Event-driven architecture, DDD...

Предыдущий пост про это всё:

https://vk.com/wall-152484379_3583

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

=

Ну например, такая хайповая темка как микросервисы. В каждой второй вакансии они упоминаются, и статей немало гуглится, где взахлёб рассказывают, как успешно перешли от монолита к микросервисам (правда, спустя 2-3 года подчас втихомолку возвращаются обратно, но это уже другие истории). А у скольки такой переход не получился? Об этом уже никто не расскажет.

Если уж на то пошло, огромная ошибка, которую в последние годы совершил мэйнстрим (впрочем, а что ещё от него ожидать? движение на дно — это его неотъемлемая характеристика, как для бобра естественно хорошо плавать, а для гепарда быстро бегать) — это массовый и бездумный переход на микросервисы.

Как правильно? Ну сперва надо от монолита перейти к распределённой системе, затем к нормальной промышленной сервисной модели, проверенной десятилетиями, и только потом естественным шагом будет движ к микросервисам. Идеальная форма последних — это буквально несколько сотен строк кода на каждый сервис, которые могут/должны быть скомпонованы в библиотеку или SDK.

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

В теории это прекрасно. И если это делается в масштабе единичных сервисов, то всё в порядке. Но когда дело доходит до десятков, а то и сотен микросервисов... это становится не столько технической, сколько организационной проблемой, хотя это и выглядит ложной дихотомией. На практике в 98% случаев получается так, что раньше было 15 разработчиков на весь монолит, а теперь требуется по 5 человек на каждый из 15 микросервисных "монолитиков".

=

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

Например, есть такая канадская Wave Financial, которая стоит 1,7 млрд. долл. — финтех для малого бизнеса, онлайн-бухгалтерия и пр. Сам сервис, по большому счёту, чистый CRUD, занимающийся сложением чиселок. В Wave работает считанные десятки разработчиков, которые пилят прозаический монолит на Python поверх Postgresql.

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

Почти за такую же цену был куплен в своё время и StackOverflow, который так же успешно масштабировал свой монолит.

...У нас были 4 Microsoft SQL Servers, 11 IIS Web Servers, 2 Redis Servers, 3 Tag Engine servers, 3 Elasticsearch servers, 4 HAProxy Load Balancers и 4 циски.

Ну совсем скромная архитектурка, да ещё и под виндой :)

Тут же в тему и Shopify, и GitHub... А в Gusto например (2 тысячи сотрудников) прекрасно масштабируется Ruby/Rails монолит (2.5 миллиона строк кода). Понятно, что внутри него и аккуратные модули, и продуманные API. А собирается этот здоровенный монолит всего за 10 минут!

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

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

=

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

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

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

— Чем больше микросервисов, которые делают разные разработчики/команды, тем больше инструментов для работы ними придётся внедрять.

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

— Каждый конкретный микросервис — это крайняя версия технического долга.

— Вам потребуется необычайно умный технический директор :)

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

=

Я обычно рекомендую следующее:

— держаться монолита как можно дольше;

— сервисы естественно прорастают в системе, как правило, по инфраструктурным причинам, а не по прикладным (см. предыдущий пост);

— если вы уходите от монолита, переходите на крупные распределённые приложения, а не на маленькие сервисы;

— помните, что каждый новый сервис — это виртуальная стена в вашей организации;

— предпочитайте библиотеки и sdk микросервисам всегда, когда это только возможно.

=

— Но, Сергей Игоревич, а как же Amazon, Uber..?

— Если вы компания масштаба и успешности Amazon, ну, тогда сходите с ума.

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

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

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

В подавляющем большинстве проектов база данных загнётся гораздо раньше, нежели сама система исчерпает свои ресурсы в плане масштабирования... У нас всегда будет гораздо больше способов настроить масштабирование приложений, нежели масштабирование базы данных. Пройдите мои курсы по highload-системам... Внезапно окажется, что делать всё распределённым по умолчанию — не всегда лучшая идея!

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

Ну и конечно, напомню из computer science, что распредёленным функциональным программам не нужно обеспечивать каузальную согласованность, им присущи все четыре session guarantees (это вам очень веская причина, почему распределённые/сервисные системы должны быть настолько функциональными, насколько это только возможно).

=

Чему и как я учу, и как попасть на мои курсы =>

https://vk.com/wall-152484379_3563

https://vk.com/wall-152484379_3579

Источник: vk.com

Комментарии: