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