Представьте вы стартап. Но вы повелись на все баззворды и хотите сделать все хорошо на начальном этапе. Как вы будете двигаться? Пойдете по пути микросервисов сразу и будете двигатся как улитка, или же хуяк хуяк и монолит, а потом все распилите?
Микросервисы
или
Монолит
Публичный пост
19 июня 2020
1797
за «Микросервисы»
за «Монолит»
Все зависит от вашего продукта и нагрузки. Основной плюс микросервисной архитектуры — это ее масштабируемость.
Плюсы (если приготовили правильно):
Минусы микросервисной архитектуры:
— Это дорого. Рили, когда у вас 30+ микросервисов вам нужно 3-5 разработчиков не ниже уровня middle что бы все это дело развивать, так же нужен грамотный архитектор что бы все это не превратилось в систему которая живет сама по себе, и при которой изменив 1 сервис только сам Аллах будет знает как она будет работать дальше. Далее вам нужна инфраструктура под это все , докеры , кубернетисы, cicd, elk и еще куча народа которое умеет все это сопровождать и настраивать так что прибаьте к тем 3-5 разрабам еще 1-3 девопса, не забывайте что все это надо где то хостить , и вот тут вам уже нужен хороший такой сервак да подороже , а лучше два (отказоустойчивость вся херня), ну и да это для прода...но у нас же еще есть среда разработки, тестовая среда, прелайв среда и интеграция.....На все это вы конечно можете положить болт , сэкономив на средах например, ну или чо пусть разрабы будут еще и девопсерами итд итп. Но как правило все это ведет не к очень хорошим последствиям в долгосрочной перспективе.
— Это сложно готовить правильно. Я знаю только один проект у нас в банке, который можно считать относительно каноничным в плане микросервисной архитектуры, начинался он как монолит и в течении 2 лет стал микросервисным. Парни за эти 2 года минимум 2 раза меняли подходы к архитектуре, словили кучу нетривиальных проблем (например проблема логирования и сериализации десиреализации когда у вас по 10млн сообщений в минуту летит в шину). Если ваш проект подразумевает какую-либо транзакционность, вы весело проведете время думая, как реализовать откат транзакции если что-то пошло не так... Только сейчас у продукта перестала гореть жопа в связи с периодическими дефектами на бою (их стало намного меньше).
Теперь про монолиты.
Хорошо приготовленный (нормальная архитектура, нацеленная на безболезненное расширение функционала + минимум техдолга) монолит довольно просто поддерживать, можно годами обходится 1-2 разработчиками и при этом проект не будет скатываться в унылое легаси(какое то время).
Плюсы монолита:
Минусы монолита:
Фуф чет много уже написал.
А также, вначале проще видеть картину целиком, когда ещё много неизвестного, шишки не набиты, метрики не собраны, выводы не сделаны. Ну, и поддерживать дешевле.
Если у вас все в зайчатках и нет грандиозных планов, все пиления на микросервисы будут выглядеть как потуги. Проще сделать монолит.
Иначе можно дойти до обсурда и распиливать не по функционалу, а просто чтоб было. Это сильно замедлит разработку и не даст ничего полезного.
Выбрал сторону монолита потому, что на начальном этапе вас должны беспокоить в первую очередь продажи.
Техническое решение должно быть максимально дешёвым. Начать можно с говна и палок: NoCode, WordPress, etc.
Если девелопите сами - тоже максимально дешёво, поэтому - монолит.
На микросервисы ваш стартап распиливается по мере надобности, например, необходимости масштабирования под нагрузку или масштабирования процессов.
Микросервисы - это всегда дополнительная сложность, дополнительная latency, компромиссы в согласованности данных и прочие "прелести". Все это требует дополнительного внимания и времени, чтобы все правильно обработать.
Ну и аджайл же: зачем делать что-то, что ты даже не знаешь пригодится ли.
Но! Монолит не отменяет необходимость планирования и проектирования с учётом будущего перехода к микросервисам.
Пофантазирую. Если я один пилю продукт с целью его довести хотя бы до MVP, а не просто поиграться с технологиями — я буду использовать знакомый подход и стек технологий. Так будет больше шансов на выходе получить рабочий концепт, который уже можно использовать.
На этапе стартапа основная проблема - понять, что именно должно быть написано; причем это понимание постоянно дрейфует, а иногда и разворачивается на 180. Конпелировать чарты в "пятисотые" на этом этапе - удел идиотов.
Мне вот интересно: кто-нибудь пробовал применять микросервисный подход при лепке пельменей?..
Под микросервисами понимают много разного, я про API Gateway + кучу микросервисов за ним.
Начать можно с сервиса, скажем, про регистрацию профилей в системе. Далее - первая фича, собираете на коленке и бодро в прод. И вот за срок от нескольких часов до пары дней у вас какое-то MVP. Можно запускаться. Появились пользователи, вроде им всё нравится – прикручиваете точно так же платежи. По сервису на каждый стор или эквайринг. Вторая фича. Аналитика. Третья фича. Админка. Ещё аналитика. Ещё фичи. 🔁 Перегорел джавист? Продолжим на голанге.
Сложно уследить? Да камон, вообще не консёрн тут, я считаю. Сейчас, когда есть Docker, K8S, всякие infrastructure as code и serverless хуячить такие микросервиса не сложнее, а даже легче монолитов.
Из плюсов:
Из минусов:
Тем не менее, считаю, подход имеет право на жизнь и может с успехом использоваться в некоторых доменах. Например – разработка бекендов под низкоинтеллектуальные мобильные апплики.
Как то незаслужено заговнили микросервисы.
Ясно что при ограниченых ресурсах проще хуйнуть шаблонный сервер на ноде.
Но если уже есть опыт и команда, хорошая микросервисная архитектура будет работать стабильней и эффективней.
Можно написать авторизацию на питоне, аналитику на скале, а для апи взять готовый сервис типо хасуры.
Сложней сломать, проще поддерживать. Авторизационный микросервис может годами лежать и работать.
Можно масштабировать только узкие места.
Немного считерю и проигнорирую крайности за которые мы обычно боремся в батле.
Не надо делать микросервисы, делайте просто сервисы. Монолит добро, но дизайнить его надо так чтобы переезжать было не так же сложно, как отрезать себе ногу. Всегда, когда дизайним куски приложения, параноидально думаем что через месяц заставят переехать на микросервисы.
Не надо изначально делать кубер, но и не надо использовать автоинкремент в БД.
Не надо неделю дизайнить gRPC между модулями, но хотя бы просто модули и DI а не tight coupling - надо.
Реальная история из реальной жизни как можно просрать кучу времени на разработку стартапа с улиточной скоростью и потом всё выбросить: https://www.rozhkov.me/post/startup-swamp/
Нужна больше команда
Нужен отдельный человек который будет вязать инфраструктуру. Там выше сказали что "камон все просто" так вот нифига не просто, как только выходишь за пределы хелловорлда
Локально уже не подымешь свой зоопарк, потому что твой модный макбук имеет всего 8гб памяти и не потянет кучу контейнеров
Отдельная история это микрофронтенды и новомодное SPA-говно
Дороже инфраструктура
Отказоустойчивость системы меньше, потому что вместо одного сервера у тебя их десяток и между ними сложное взаимодействие
Мониторить это всё хозяйство тоже сложнее
Короче минусов вагон, при этом когда в профит пишут "масштабируемость" я ору, потому что друзья, ну это просто смешно, вы стартап делаете (скорее всего веб-чтототам), а не HFT систему. Ну серьезно, ну давайте будем трезво смотреть на ситуацию.
Уж если надо будет где-то числодробилку то поставите сбоку "аванпост" на джаве и все будет хорошо.
Короче, я за монолит, за Ruby on Rails, за рендеринг на сервере и минимум джаваскрипта на клиенте. Это проще, быстрее, надёжнее и намного приятнее в разработке.
Вот статья от DHH хорошая: The Majestic Monolith can become The Citadel
Если рассматривать вопрос с точки зрения дизайна, то... сюрприз! Разницы абсолютно никакой. Успех архитектуры всегда зависит исключительно от того, как качественно задача будет декомпозирована на абстракции, при этом принципы декомпозиции схожи везде - инвертируй зависимости, держи абстракции стабильными и ориентированными на бизнес цели. Монолит и микросервисы в этом отношении абсолютно идентичны.
А вот с технической и огранизационной точки зрения начинаются плюсы и минусы:
И самое главное. Всратые микросервисы саппортить в разы больнее всратого монолита. А на раннем этапе (стартап же) архитектура будет всрата гарантированно, инфа 100%, это закон. Если пойти путем хайпа с самого начала, до реальных плюшек от микросервисов можно и не дожить.
Любое изменения в системе тянет за собой вопрос
"а как это повлияет на работу других частей системы?".
В монолите запускаешь быстро тестики в репе и получаешь ответ на вопрос. Если что-то упало, все логи можно посмотреть и исправить. Почти не думаешь. БЫСТРО получаешь ответ (привет unit-тесты).
Разработчики довольны, голова не кипит.
В микросервисах в миллион раз больше moving parts: разные базы, разные API, разные сущности, разная степень херовости кода.
И одним запуском команды
run testsответ уже не получить.Даже если оно все протестировано локально, приходится думать об интеграционном тестировании.
А интеграции - это всегда про коммуникацию и договоренности.
Больше коммуникаций - больше потраченного времени.
Никакого ускорения разработки - только её замедление
В стартапе главное – скорость разработки. Если стартап трушный, с какими-нибудь нагруженнами штуками, можно выделить именно эти куски в сервисы на условном go/elixir/erlang чтобы совладать с этим, а все остальное засадить в монолит на языке, где скорость разработки максимальная и большое количество доступных кадров на рынке (типа Ruby/PHP).
«организации проектируют системы, которые копируют структуру коммуникаций в этой организации»
В стартапе, на начальном этапе, группа консолидируется в монолит. Потом разделяется на подгруппы, потом обменивается участниками подгрупп. Потом всё.
Чтобы построить хорошую распределенную систему, нужно построить много подсистем, которые будут обеспечивать устойчивость всей системы.
Всякие curcuit breaker'ы, dead letter queue, миллиард реплик, API Gateaway, трейсинг и многие другие паттерны придется применить, чтобы решить очередную проблему, возникшую из-за применения паттерна.
Цена ошибки проектирования в случае распределенной системы намного больше, так как менять абстракции/интерфейсы/процессы сложнее, чем править реализацию (весь SOLID про эту устойчивость абстракций).
К тому же чтобы построить правильные подсистемы, нужна огромная теоретическая и практическая экспертиза в команде, широта кругозора.
Без этой экспертизы (или с ошибочным представлением менеджера об опытности коллег) команда захлебнется в изучении всего того, с чем нужно бороться. Все сроки будут проебаны.
Разбивать всё на сервисы по бизнес доменам, конечно если бизнес домен один тогда и не стоит. Проще разрабатывать сервис, тестировать и эксплуатировать, сразу приходится думать об архитектуре, а эти размышления всегда на пользу. Сразу проектировать под High availability, т.е. так чтобы могло работать минимум два инстенса приложения одновременно.
Кажется, что много издержек на старте, но это первичные затраты, которые потом сэкономят денег и времени. Всегда стоит держать в уме, что нет ничего более постоянного чем временное.
Зачем добавлять в и так сложный программный комплекс еще и внутренний граф сетевых взаимодействий?
К тому-же большинство компаний не Яндекс и не Гугл и никто не будет еженедельные учения с проверкой "а что будет, если часть сервисов отвалится". Потом какой-то сервисок отвалится и весь кластер пойдет по звезде.
Микросервисы ( а на самом деле не очень-то микро-) становятся нужны в тот момент, когда достаточным и нелинейным образом возрастают нагрузки на систему.
В контексте стартапа, пока без построенных процессов выкладки люди навалят 100500 микросервисов на разном техе пройдет 100 лет. И эти 100 лет будут потрачены не на продукт, а на ненужное дрочево.
(Относительно) нормально запиленный монолит позволит двигаться куда быстрее в разработке, затем легче и понятнее масштабируется и появляется шина, сильно потом на части инстансов конфигом говорится "а вот тут у нас будет только проверка пользаков" и естественным образом появятся слои. Но до этого надо еще дожить.