Comments 94
Спасибо за такой нешуточный интерес!
Google потому вам так и переводит это предложение, что оно вот ровно так и переводится.
От себя по данному предложению: имеется в виду ситуация, когда в такой крупной компании как Amazon куда проще коду разных бизнес-подразделений разговаривать между собой через API, чем их сотрудникам организовывать координационные совещания друг с другом.
Можно удариться в такого рода переформулирование, но тогда от почерка Дэвида мало что останется. От эмоций его тоже не избавлялся.
Кстати, раз уж на то пошло, переводил для скорости Яндексом и потом пробегался со своей лёгкой очеловечивающей редактурой.
оно вот ровно так и переводится
Ну не может же так быть?
Оригинал:
What makes this story unique is that Amazon was the original poster child for service-oriented architectures. The far more reasonable prior to microservices. An organizational pattern for dealing with intra-company communication at crazy scale when API calls beat scheduling coordination meetings.
Ваш перевод:
Что делает эту историю уникальной, так это то, что Amazon был оригинальным примером сервис-ориентированных архитектур. Гораздо более разумный вариант до появления микросервисов. Организационный шаблон для решения внутрикорпоративных задач в сумасшедшем масштабе, когда вызовы API превосходят планирование координационных совещаний.
Один из более лучших переводов:
Что делает это историю уникальной, так это то, что Amazon был изначальным образцом сервис-ориентированной архитектуры. Куда более разумной предтечи микросервисов. Организационного паттерна, который позволял наладить внутрикорпоративные коммуникации в том безумном масштабе, когда вызывать API становится удобнее, чем пытаться созвать координационное совещание.
Спасибо! Прекрасный вариант. Но я в итоге чуть лаконичнее проредачил, чтобы не отходить от формы Дэвида.
Что делает эту историю уникальной, так это то, что Amazon был архетипичным примером сервис-ориентированных архитектур. Гораздо более целесообразных до появления микросервисов. Организационный шаблон для внутрикорпоративного взаимодействия на безумном масштабе, когда вызовы API побеждают планирование координационных совещаний.
Вообще он из тех довольно бравурных авторов, которого лучше читать в оригинале, т.к. там много фишечек исходного языка, которые сложновато переложить в переводе. Например, вот этот самый "original poster child", являющийся ежом-с-ужом от двух идиом — "original poster" и "poster child".
вот за poster child'а обидно! Утерян при переводе...
Может "был тем самым эталонным милым ребенком с рекламного плаката SOA". Ну жалко такую жемчужину терять
"Был архетипичным примером" вполне удачный перевод, но если хочется ближе к оригиналу, то можно "был застрельщиком и олицетворением"
может быть, "original poster child" - "незаурядный пример для подражения"?
Раз пошла такая малина, то и я встряну:
Примечательно в этой истории то, что Амазон был первейшим примером для подражания для сервис-ориентированных архитектур. Куда более разумных, ранних микросервисов. Это организационный подход для коммуникации безумных масштабов внутри компании, где вызовы API превосходят согласование координационных встреч.
Для меня это - различие между переводом и локализацией. @electroshamanя понимаю тягу быть близким к тому, что писал автор (сам с того начинал), и пытаться донести краску оригинала... но не получится. И это еще хорошо, что англ. и русский относительно близкие языки, где можно без переосмысления при переводе донести смысл, чего бы с фигуративным китайским не получилось. Надо стараться усвоить позицию и состояние автора из текста, и именно это донести на целевом языке. Может быть он тоже не смог точь-в-точь передать свои эмоции через свой словарный запас и английский текст? А знай он русский, понравились бы обороты из другого языка (типичная смесь языков, когда люди общаются меж собою на нескольких). Так что "организационный паттерн" выше - недопонятый исходный текст. (К критике готов :))
А про переводы на Хабре и т. п. скажу... ну уж очень выродился русский язык из-за того, что люди читают абы как написанные тексты, которые, на самом деле, непонятно откуда взятые и переведенные. С медиа, в особенности фильмами - та же история: на скорую руку, подешевле, сроки жмут. А считают это что нинаесть обычным языком. Начав обращать на это внимание, заметите больше ляпов и улучшите свой язык. На этой провокативной ноте: пока!
Вопрос в камертоне для того, что считать в каком случае удачной формой передачи языка автора. Допустим, идём по предложенной схеме эмпатичного перевода со всеми эквивалентными русскими прибаутками, и вот наш Дэвид Ханссон уже вылитый Козьма Прутков. Нужно ли нам это?
Для технической публицистики роль формы речи не существенна. Можно переводить сухо, опуская весь речевой выпендрёж. Лишь бы предельно конкретно смысл доносился. Но Дэвид Ханссон довольно одиозный персонаж, и сложно пойти на то, чтобы жертвовать его подачей ради некой академичности текста. Плюс там ещё прямая речь Келси Хайтауэра со своими особенностями, которые тоже не хочется опреснять или приукрашивать вприсядку.
Бывает, мы беспокоимся, как им там, бедолагам, за океаном читать наших Достоевского с Чеховым в переводе, ведь мистериос рашн соул гетс комплитли лост ин транслейшн. Загадочная амерканско-датская душа и характер мистера Ханссена также испаряется при избыточном рвении в олитературивании его высказываний. Речевой американский английский имеет свою характерную расплывчатость. И да сохранение этой особенности на русском порождает несколько непривычный текст. Вне зависимости от того, использовался машинный перевод или нет. Вопрос ожиданий и толерантности к такому.
И ещё имеет смысл обратить внимание, что даже у наших классиков прямая речь иностранных персонажей на русском наделяется должной иностранинкой той или иной степени для полноты образа.
Для тех, кому хотелось бы читать такие тексты на языке Достоевского, я в переводе оставил небольшую пасхалочку.
В сухом остатке вопрос исключительно в том, важно ли в тексте сохранить персонажа, от лица которого он излагается. Не претендую на то, что мне это удалось, но пытался.
В целом согласен. Только "Загадочная амерканско-датская душа и характер мистера Ханссена" мне неизвестны, не слежу за персонажем :)
У дядьки немало заслуг, но в плане почитать он хорошо самовыразился в культовой книжице Rework доинфоцыганской эпохи. И тем самым возможно стал одним из её родоначальников 😜
То, что я опубликовал здесь его пост, не означает, что я на 100% разделяю его мнение, но очень было интересно, что народ думает по этому поводу.
Не понял, что такого одиозного по ссылке.
Google потому вам так и переводит это предложение, что оно вот ровно так и переводится
Гугл его так переводит, потому что если переводить каждое слово по отдельности, то оно ровно так и переводится
Мне гораздо больше нравится процесс перевода в Яндекс Переводчике, и я основной костяк перевожу им. Бывают смысловые дребезги, но в целом он достаточно хорош. И вряд ли это можно назвать переводом по словам. Вполне связный текст. Нередко более качественный, чем у Гугла. Дальше просто вопрос усидчивости с полировкой результата.
Разумеется нет. Вам самому не стыдно публиковать текст, который не имеет смысла? Ведь ради смысла текст и переводят, а не просто ради русских слов.
Пожалуй, это слишком категоричная оценка для этого текста.
Три момента от себя, которые скорее всего аналогично могут иметь отношение к любой такой дискуссии, когда кто-то воспользовался машинным переводом:
1. В авторских текстах бывают моменты разной степени неоднозначности, и возникает вопрос, насколько надо от неё избавляться, выбирая свою субъективную однозначность, хотя и исходный машинный перевод какую-то свою тоже предлагает.
2. Для публикаций из жанра мнений и реплик резонно стараться передать авторскую подачу без полного олитературивания. У фигурирующего здесь Дэвида Ханссона своеобразный живой язык, не лишённый той самой непереводимой игры слов и крайне близкий к разговорной речи. Местами в оригинале читается почти как стенограмма стэндапа. Вкупе это лишает ощущения привычной естественности для большинства публикаций здесь, и да, может резать глаз. Можно укатать это всё полностью литературным переводом, но нужно ли?
3. Не думаю, что должно быть стыдно использовать машинный перевод. Это просто хороший инструмент, которым есть смысл пользоваться. Ибо порой он очень хорошие варианты даёт, и не настолько тупой, как принято считать. Хоть это всё и не благославляется многими на Хабре. Боюсь, в перспективе нам придётся столкнуться с тем, что скорее наш язык в некоторой степени деформируется под машинный, чем машины окончательно мимикрируют под нас. И мы просто перестанем замечать разницу, привыкнув. Похожее уже случалось на разных этапах культурной эволюции.
Google потому так и переводит это предложение, потому что вы его так перевели, а Google умный, он просто воспользовался найденным в сети переводом. То есть вашим.
Я это заметил, когда переводил свою статью на английский. Сначала Google переводил некоторые фразы по своему, а когда я выложил статью, то он стал выдавать мой перевод.
Какое замечательное открытие, мы нашли ещё один <something> hell. Оказывается, если фанатично впихивать DLL/XML/microservices/something, даже туда, где оно совершенно избыточно или ненужно, получается плохо. Как хорошо когда мир чёрно-белый. Теперь нужно просто развернуть диван на 180 градусов и снова воевать :) Теперь собираем все разобранные монолиты на микросервисы снова в монолиты. Счастье-то какое!
Речь шла в статье не о том что сам подход микросервисов такой плохой и убыточный, етественно они полностью не избвавятся от сервисных технологий, просто лишний жирок уберут. А тут про то что микросервис ради микросервиса и использование его всюду также добавление куча предпосылок в виде функционала для создание еще более глубоких уровней микросервисов избыточно так как нет пока такого спроса на рынке. Можно это сравнить со старой статьей на хабре про ООП головного мозга когда этот ООП везде пихали куда не попадя, потому что модно и тд...
О том и речь. Вчера в корпорациях гудели "переходим на микросервисы!", а завтра начнут хайпить "долой микросервисы, все на монолиты!". Я хочу обратить внимание на эффект от такого рода статей, с громкими заголовками.
В данном случае хороший пример рассмотрения одного и того же события с двух разных сторон.
Модульные монолиты, пацаны! Надо пилить модульные монолиты!!
Просто читать надо не только заголовок. А оригинал поста и обсуждение.
Речь не о монолите, а об отказе от serverless и переходе к контейнерам.
Факт: гонять между сервисами кадры видео в json-чиках и хранить их в s3 корзинах, оказалось не таким эффективным, как делать все это в памяти.
Выводы статьи в виде тегов: ааааа/закат микросервисов/пшик/марш в стойло рядом с nosql
Там есть еще: использовать лямбду и с3 как промежуточный слой - дорого даже для самого амазона :)
Это, пожалуй, наиболее потешный момент — если даже Амазону дорого, то кому это по карману-то, саудовским принцам что ли.
AWS никогда не позиционировался как самый бюджетный хостинг, справедливости ради, но тем не менее.
Я разрабатываю софт под AWS/Serverless уже больше 4 лет и могу сказать, что у амазона низкие цены, если правильно ими пользоваться. Лямбды не для кодирования видео предназначены.
Это не секрет что серверлес дороже чем сервер. Фишка серверлес в том что ты платишь за вызов, это выгоднее в итоге, если процент занятости невысокий.
Можно привести аналогию со своей машиной и такси, если сегодня машина очень нужна а потом неделю не нужна, такси выгоднее чем содержать свою машину за которую платишь в независимости ездишь ты на ней или она пыль собирает.
Это да, я понимаю. Но вместе с тем какой юзкейс у лямбды, запускаемой дважды в день? Домашнюю страничку с мемуарами хостить разве что, или скрипт для бекапов.
Да. Небольший сайты для мелкого бизнеса, организаций и отдельных частных лиц. Даже небольший онлайн магазины. Это очень немаленький рынок. Например оборот Squaraspace $867 млн в 2021 году.
Во-первых у лмябды бесплатный вроде бы первый миллион запусков в месяц-то есть это не про скрипт раз в день,а в она бесплатна до 30 тысяч запусков в день.
Во-вторых да, таких оперций реально много-старт чего-нибудь, нотификации, оркестрация и т.д.
Да и в целом лмябда не особо дорогая если это не хайлоад-по сравнению с например базами данных, апи гейвтеями она практически бесплатная.
Прошел год назад, когда перестраивал софт на монолит тк нужна была скорость обработки в наносекундах. Честно, я очень боялся, но когда все сделал - мир заиграл новыми красками. Нет тонн софта обслуги, упростилось проектирование api…пропали тонны протоколов для взаимодействия. Сократилось количество виртуалок…пропали ситуации когда какой-то там микросервис начинал жрать память, который делался при царе горохе. Потом сидишь и пытаешься вспомнить как он вообще работает.
Один минус - перезапуск монолита сложная задача, это надо проектировать при разработке.
а про эффективность вообще молчу, лично у меня нагрузка упала на 70% общая по серверам.
А на тему рациональности использования, хорошо звучит и правильно…дескать мяса много жрать тоже вредно. Но предполагаю что везде температура по больнице будет +- одна, просто рост в геометрической прогрессии и уследить за этим очень сложно
Есть опыт, когда неудачное размещение большой задачи в монолите, а не отдельным сервисом привело в итоге к боли, страданиям, и ощутимым потерям бизнеса. Но также есть опыт, когда неоправданное разделение по микросервисам принесло только убытки, завышенные требования к ресурсам, и никакой пользы. Ни в коем случае нельзя рассуждать что лучше, без контекста конкретных задач и конкретных условий.
А можете поделиться таким опытом с неудачным размещением большой задачи в монолите?
Навскидку пару примеров.
Когда-то монолите была размещена интеграция с крупной легаси системой с помощью предоставленной библиотеки (DLL). Спустя 3-4 года, это стало серьёзным препятствием для апгрейда технологического стека, так как данная библиотека не обновлялась и обновляться не собиралась. Если бы изначально интеграцию вынесли в отдельный сервис, проблем бы никаких не было.
В монолите реализовали функцию для электронного подписания документов, на беке и фронте. Позже выяснилось, что данная функция нужна разным клиентам на разных витринах, да и другим проектам компании. Так как релизная политика монолита довольно громоздкая, функционал критичен для организации, это напрямую повлияло на разработку функции подписания. Запросы на развитие, исправление багов порой висели месяцами. Вынос данной функции в отдельный микросервис решил это проблему. Если сразу так сделали, то сэкономили бы сотни человекочасов, нервотрёпки и ожиданий.
Конечно, это далеко не все примеры из практики. Последствия неудачных решений в архитектуре приводят к весьма ощутимым потерям бизнеса. И к ненужной нагрузке на разработчиков.
Я не очень понимаю выражение "предварительный распил" :) Это что за распил такой и ради чего? Монолит не располагает разработчика к написанию кода, который вот прям выпиливается в отдельный сервис за 5 минут. Обычно это не так. Я бы сказал, обычно это никогда не так. Функционал ложится на существующие слои, архитектуру, зависимости, компоненты -- это одна из самых привлекательных сторон монолита. Иначе зачем делать абсолютно независимый и самостоятельный модуль в монолите, если они ничего из этого монолита не использует?
Моя мысль простая. Распил ради распила также плох, как и впихивать всё в монолит, не думая о задаче. Оба варианты одинаково плохи.
Такая ситуация могла возникнуть с любой сторонней библиотекой.
+много!
Одна из моих любимых фраз - "it depends" (после KISS).
Вся статья откровенное кликушество и "ученый изнасиловал журналиста". Одна из сотни команд Амазона совершила, признала и исправила ошибку. Рядовая в общем ситуация, которая для меня лишь является подтверждением идеи "сначала - монолит". А кликуша-автор уже "окончательно решает вопрос" микросервисов.
Замена вызовов методов и разделения модулей сетевыми вызовами и разделением служб в рамках единой, согласованной команды и приложения является безумием почти во всех случаях.
Прям вот ни капли не сомневаюсь, что у автора есть опыт поддержания монолитного сервиса, скажем так, с 60 разработчиками и 3кк строками кода в состоянии "согласованной команды и приложения".
Я счастлив, что мы отбили натиск зомби этой ужасной идеи
"Мы пахали"© - классика.
Прям вот ни капли не сомневаюсь, что у автора есть опыт поддержания монолитного сервиса, скажем так, с 60 разработчиками и 3кк строками кода в состоянии "согласованной команды и приложения".
Правильно делаете, ведь автор - создатель Ruby on Rails, basecamp.com и hey.com. Опыта работы с монолитами и командами для их создания у него больше, чем чуть менее чем у всех комментаторов на хабре
За RoR ничего не скажу, потому как вопрос "микросервисы или монолит" к веб-фреймворку как-то слабо применим. А вот за Basecamp спасибо за наводку. Читаю пост https://m.signalvnoise.com/the-majestic-monolith/:
Basecamp is a small team. As I mentioned, we have just 12 programmers, and many of those are busy keeping the systems we’ve been creating over the last decade operational.
Ну знаете, когда на моем прошлом проекте было 4 разраба, мы тоже монолит спокойно пилили. А давайте для контраста Сбер возьмем, где разрабов никак не меньше тысячи?
Количество разрабов не говорит ни о чём. Они же не один продукт делают все вместе. Вполне может быть так, что есть какой-нибудь большой монолит на десятки или сотни человек, а рядом команды по два-три человека, которые делают крохотные приложения со специфичными задачами. Вот это хорошее приложение для микросервисов. В конце концов, микросервисы - это скорее про организацию работы, а не про архитектуру. Т.е. это в большей степени административная вещь.
За RoR ничего не скажу, потому как вопрос "микросервисы или монолит" к веб-фреймворку как-то слабо применим.
Фреймворк часто диктует архитектуру. Для PoC или MVP монолиты идеальны. Да, потом их можно разобрать на кусочки или даже в рамках того же монолита всё переделать так, что от изначального стиля фреймворка ничего не останется. Но изначально рельсы поощряют именно монолит.
Basecamp is a small team. As I mentioned, we have just 12 programmers
Хороший пример того, чего можно добиться, когда люди занимаются делом, а не жонглируют микросервисами в kubernetes :)
Basecamp действительно не показатель. Есть другие примеры рельсовых монолитов: github, spree, shopify. Кто-то потом ушёл в SOA, кто-то вообще в другие языки, а кто-то остался на рельсах и монолите. Яркий пример сейчас - gitlab: https://about.gitlab.com/company/history/.
@Boomburumв причины минуса к посту пора добавлять "машинный перевод". За последние недели таковые прямо зачастили. Причины "много ошибок, плохое оформление" явно не про то.
Так и не понял, в чем беда микросервисов и выгода монолита?
Вот собрал я свои глупые микросервисы(ввод данных, обработка, вывод) в один сияющий монолит, хорошо. Как его скейлить? микросервисы я мог скейлить независимо друг от друга, а монолит? ради увеличения мощности одного компонента, например ввода данных, мне нужно скейлить весь монолит, оставляя обработчик данных и вывод работать вхолостую? что делать, когда данных много и в один монолит не вмещается? увеличивать количество монолитов(ой, не это же первый шаг к микросервисам) или раздувать саму машину? как этот монолит перезапускать без потери качества и данных? что делать если он упадет?
иихо самое глупое - это обвинять в ошибках проектирования архитектурный паттерн.
Мне кажется у вас не очень правильные вопросы :)
На них легко дать ответ.
Но на мой взгляд основная проблема масштабирования монолита это:
Разные части монолита требуют разного подхода к масштабированию (пример: часть api stateless, но часть - statefull). Тут приходится выкручиваться хитро-вывернутыми правилами роутинга на GW.
Проблема раскатки обновлений
Если сервис лежит, то лежит 100% функционала
Хорошо, мои неправильные вопросы вы перефразировали в постулаты известных проблем монолита, на которых нет ответа.
Может, давайте начнем сперва с моих "легких вопросов"? Пусть и неправильных
Если сервис лежит, то лежит 100% функционала
Если что-то лежит, то налицо другая проблема, не связанная с архитектурой. Отказоустойчивость, высокая доступность, балансировка нагрузки - это отдельная дисциплина, в которую умеют сисадмины, но часто, увы, не умеют разработчики (хотя концепция DevOps и стремится обучить разработчиков самих поддерживать свои продукты)
Вдобавок, пользователи обычно привередливы, им не нужен продукт, работающий на 99%. Им нужен продукт, просто работающий. Если работает 9 микросервисов из 10, но лежит отвечающий за аутентификацию - продукт бесполезен, ибо пользователь просто не залогинится. Если лежит отвечающий за кеширование - продукт бесполезен, ибо пользователю надоест долго ждать ответа от сервиса, он плюнет и уйдёт. И т.д.
Продукт - это система, она должна работать вся целиком, чтобы приносить пользу.
Так и не понял, в чем беда микросервисов и выгода монолита?
В статье не рассматриваются плюсы и минусы микросервисов. Её мысль: хватит пихать микросервисы куда ни попадя, где надо и где не надо. Это не панацея, это инструмент для решения специфичных проблем в специфичных условиях. Как и любой другой инструмент.
Беда не в микросервисах как таковых, а в хайпе вокруг них. Так происходит с каждой технологией, до которой добираются маркетологи и начинают её продавать с пеной у рта, обещая решить все проблемы бизнеса, а заодно накормить голодающих в Африке и вылечить рак. Так было с микросервисами, так было с GraphQL, с NoSQL, с Elixir и так далее.
Как видели микросервисы опытные люди ещё в самом начале хайпа, можно почитать вот здесь, например: https://martinfowler.com/articles/microservices.html. Разумеется, прошедшие 10 лет дали больше пищи для размышления, но выводы верны до сих пор:
One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem.
иихо самое глупое - это обвинять в ошибках проектирования архитектурный паттерн.
Если разработчик (а ещё лучше - тот, кто ставит ему задачи, вплоть до владельца бизнеса) понимает, что продукт нужно проектировать, то такой проблемы и не возникнет.
Тогда я не очень понимаю, о чем статья?
О том, что не надо везде пихать микросервисы? Так это известно с начала их появления.
Что надо начинать с монолита? Спорно, зависит от задач и связности команд, но допустим среднестатистический проект принято начинать с монолита, хорошо.
Если разработкой архитектуры занимаются маркетологи, то и результат будет соответствующий.
У меня на проекте есть и NoSQL и GraphQL и микросервисы и все это еще и в кубе, прости господи. И все хорошо и довольно дешево работает. Я пытался представить себе весь наш проект из 30 микросервисов в монолите, представил сборку и тестирование этого монстра, (не считая деплоя и инцидентов) и проснулся в холодном поту.
Я даже не знаю, что лучше уже — хайп или хейт, можно я просто буду выбирать архитектуру по задаче, а не по отзывам "самого Амазона".
Как видели микросервисы опытные люди ещё в самом начале хайпа, можно почитать вот здесь, например: https://martinfowler.com/articles/microservices.html. Разумеется, прошедшие 10 лет дали больше пищи для размышления, но выводы верны до сих пор:
Вы же в курсе что тот же фаулер в книге POEAA 2000 года ругал архитектуру основанную на децентрализации данных и business-capabilities?
иихо самое глупое - это обвинять в ошибках проектирования архитектурный паттерн.
Этот самый паттерн доведён нынче до абсурда. Оттуда и критика.
Золотая середина должна быть. Кто мешает разные роли на разных узлах реализовывать? Горизонтальное масштабирование нормально работает и без микросервисов. И это не шаг к микросервисам, а нормальное рациональное проектирование.
А то нычне появилась мода всё сразу только серверлесс делать, даже там, где это даром не сдалось. А многие ещё и элементарно НЕ УМЕЮТ по-другому. Отсюда и яростная защита подхода микросервисной архитектуры, как единственного правильного пути.
В этом конкретном случае: стоимость передачи данных между микросервисами оказалась слишком высока, что увеличивало стоимость решения до неприемлемого уровня.
Вот собрал я свои глупые микросервисы(ввод данных, обработка, вывод) в один сияющий монолит, хорошо.
Как его скейлить?
Также как микросервисы - увеличивать количество инстансов. Вообще горизонтально масштабирование придумали сильно раньше, чем микросервисы.
микросервисы я мог скейлить независимо друг от друга, а монолит?
Вместо 10 экземпляров каждого сервиса ты поднимаешь 10 экземпляров монолитного приложения. Это мало того что меньше сожрет ресурсов, но быстрее работать будет.
мне нужно скейлить весь монолит, оставляя обработчик данных и вывод работать вхолостую?
При правильной архитектуре у тебя не создаются объекты если нет запросов. Поэтому простаивающие части приложений будут жрать ничего. В отличие от простаивающих микросервисов.
что делать, когда данных много и в один монолит не вмещается?
Это как? Масштабирование хранилища в монолите и микросервисах никак не отличается. Масштабирование вычислений в микросервисах делается также как в монолите - вы просто увеличиваете количество узлов. Монолит в свою очередь экономит вычислительные ресурсы, так как не занимается перекладыванием данных через хранилище. (пример из статьи amazon prime)
увеличивать количество монолитов(ой, не это же первый шаг к микросервисам) или раздувать саму машину?
Сначала scale up, потом scale out. Это все делалось задолго до изобретения микросервисов.
как этот монолит перезапускать без потери качества и данных?
Как обычно one node at a time.
что делать если он упадет?
Поднимать. Опять-таки задолго до изобретения микросервисов изобрели feature flags, VIP switch и другие технологии zero-downtime деплоймента.
иихо самое глупое - это обвинять в ошибках проектирования архитектурный паттерн.
В данном случае вполне оправдано.
В этом конкретном случае: стоимость передачи данных между микросервисами оказалась слишком высока, что увеличивало стоимость решения до неприемлемого уровня.
Это как? За счет чего? Бакет убрали из архитектуры? Так его и из микросервисов можно было убрать
Как его скейлить?
Также как микросервисы — увеличивать количество инстансов. Вообще горизонтально масштабирование придумали сильно раньше, чем микросервисы.
Отлично, а по какой метрике? Вот представьте себе сферическое приложение — качает данные из сети, принимает запросы от пользователей в очередь, при этом еще делает выгрузку в БД периодически и отдает ее по запросу. При микросервисах это отдельные компоненты и скейлятся по разному — кач из сети скейлится по памяти, обработчик очереди скейлится по цпу, выгрузка в БД скейлится по коннектам а отдача по кастомной метрике например количеству юзеров. А монолит вы по чему скейлить будете?
мне нужно скейлить весь монолит, оставляя обработчик данных и вывод работать вхолостую?
При правильной архитектуре у тебя не создаются объекты если нет запросов. Поэтому простаивающие части приложений будут жрать ничего. В отличие от простаивающих микросервисов.
Из предыдущего примера — я правильно понимаю, что мне нужно будет скейлить целый монолит просто потому, что выросло количество пользователей, а все остально не выросло, но у нас же монолит?
Это как? Масштабирование хранилища в монолите и микросервисах никак не отличается. Масштабирование вычислений в микросервисах делается также как в монолите — вы просто увеличиваете количество узлов. Монолит в свою очередь экономит вычислительные ресурсы, так как не занимается перекладыванием данных через хранилище. (пример из статьи amazon prime)
Опят же, из примера — мне нужно много памяти для закачки данных, в микросервисах мне нужно увеличить память именно для него, но я в монолите скейлю вообще все и остальные компоненты тоже, в том числе ненужные и это даст мне экономию? Может проще с бакетом было решить проблему, см первый пункт
Сначала scale up, потом scale out. Это все делалось задолго до изобретения микросервисов
Что делать, если в монолите выгрузка в БД, причем 2 часа в сутки, а остальное время не работает — зажимать выгрузку, чтобы не держать монолит вхолостую или наоборот? Может есть какой-то фреймворк или библиотека, о которой я не знаю и которая делает вышеуказанное вами из коробки и правильно?
как этот монолит перезапускать без потери качества и данных?
Как обычно one node at a time.
Ухх, ну давайте. У нас 10 монолитов, мы неспеша раскатываем релиз по вашему алгоритму. Кстати, почему по одной ноде, а не по две или не по пять? Ну ок, мы по одной их раскатываем, раскатывается долго, это же монолит. Приходит разраб и говорит — у меня хотфикс, надо срочно накатить. Но пусть подождет окончания раскатки, там миграция и все такое, хотя хотфикс с миграцией не связан, но у нас монолит. Окончив релиз, начинаем раскатывать хотфикс, по одному, на все 10 нод(при микросервисах было бы 2 инстанса). И тут прибегает еще один разраб и говорит — у нас память течет после релиза в месте, не связанном с БД, надо откат делать всего для регрессии. А мы не можем, у нас деплой идет да и миграция уже была, в общем, подождут пусть пользователи, пока мы тут все раскатаем, зато монолит!
что делать если он упадет?
Поднимать. Опять-таки задолго до изобретения микросервисов изобрели feature flags, VIP switch и другие технологии zero-downtime деплоймента.
Не очень понятно, как относится фича флаги и прочее что вы указали к zero-time deployment, но допустим — у вас в монолите в обработчике очереди паника, сервисы валятся и лежит весь монолит. Микросервис можно было бы изолированно чинить, а так приходится дергать весь монолит, и боюсь тут ни фича-флаги ни VIP switch, ни каким-то боком приплетенный zero-time deployment не помогут.
имхо самое глупое — это обвинять в ошибках проектирования архитектурный паттерн.В данном случае вполне оправдано.
Лично мне неочевидно, имхо тут просто избавились от бакета как промежуточного хранилища и это дало буст по стоимости и скорости. У меня тут недавно случай был — бакет s3 смонтировали как nfs диск и при количестве данных в смешные 10Гб счет выходил за $1к, потому что стоимость операций с бакетом при работе как с диском на порядки больше стоимости самого хранилища.
Так что я пока не увидел преимущества монолита перед микросервисом, по крайней мере с эксплуатационной точки зрения
Вы с таким пафосом пишете "скейлить целый монолит"...
У нас "монолит" весит 120МБ (вместе с ресурсами, в общем всё что деплоится). Сколько весят образы ваших микросервисов суммарно без учёта дублирования слоёв?
У нас развёртывание от момента нажатия на кнопочку билда до того что пользователи (2.5млн в сутки, 25млн в месяц) видят новую версию делается меньше чем за 5 минут (blue/green deployment, основное время занимает сборка и доставка артефактов на целевые машины). Ваши микросервисы развёртываются быстрее? Не понимаю с чего монолит должен долго раскатываться. Ну если допустим квалификация его разработчиков невысока -- будет, но они и микросервисы точно такие же паршивые сделают.
Дополнительный бонус -- всё можно запустить на своём рабочем ноутбуке, без прыжков с Docker compose или недо-куберами типа k3s. Просто из среды разработки. Тестовая БД доступна через VPN, при желании и достаточной смелости можно подключиться и к продовой.
Миграции в их традиционном понимании (выполнить DML/DDL запрос на несколько минут/часов) в always-on системах делать нельзя, так как у нас такая система, то я это даже комментировать не буду, совместимость схем данных обеспечивается правильными практиками разработки и feature-флагами.
Ошибки -- опциональный откат на предыдущую версию (делается минуту), исключение проблемного коммита или коммитов, новый деплой. Можно уточнить кстати про пример с утечкой памяти? Это абстрактный или конкретный был пример, можно детали?
Про "изолированно чинить микросервис" и "скейлить монолит", я бы хотел послушать не абстрактные измышления, а конкретные примеры. Монолит, если его развёртывание автоматизировано, прекрасно масштабируется в обе стороны. Если вам нужна ETL-задача (2 часа в сутки), её можно назначить на отдельную группу экземпляров монолитов, которая масштабируется по другим правилам.
Вместо того чтобы делать RPC между каждым из компонентов с кучей "клея" в виде кубера, service mesh и т.д., на содержание которого нужен целый отдел. Не вопрос, этим всем может быть интересно заниматься, опять же за "микросервисный девопс" хорошо платят. С умным видом рассказывать что ты не JSON-ы из БД в HTTP перекладываешь, а настраиваешь Cilium и оркестрируешь контейнеры =)
Вы с таким пафосом пишете "скейлить целый монолит"…
У нас "монолит" весит 120МБ (вместе с ресурсами, в общем всё что деплоится). Сколько весят образы ваших микросервисов суммарно без учёта дублирования слоёв?
Где вы пафос нашли — ума не приложу. Вы же скейлите монолит на инстанс и не пихаете кучу монолитов в одно место, верно? То есть для скейла монолита нужна целая машина, иначе смысла нет — оверхед на переключение контекста будет такой же как и на микросервисах, если не больше.
У нас монорепо, в один образ кладутся 20 бинарников, вес образа 100Мб, так как образ один, то и общий объем такой же.
У нас развёртывание от момента нажатия на кнопочку билда до того что пользователи (2.5млн в сутки, 25млн в месяц) видят новую версию делается меньше чем за 5 минут (blue/green deployment, основное время занимает сборка и доставка артефактов на целевые машины).
У нас пользователей от 700к до 3кк в день, сезонное. Примерно сравнимо. Раскатка всех микроосервисов (аналогично раскатке монолита, но не blue/green, обычный роллаут + канареечный деплой для вещей которые сложно проверить в тестах) — 3-4 минуты от пуша в репу до деплоя, сам роллаут занимает минут 10 на всю площадку этоо если все передоеплоивать, ибо мы делаем graceful shutdown. А вам для blue/green приходится поднимать копию прода, как я понимаю? И как по стоимости по сравнению с роллаутом, сравнимо? ) Про кваклификацию опущу пассаж — я придерживаюсь мнения, что девелоперы люди и могут ошибаться, поэтому я лучше с этим что-то буду делать для нивелирования ошибки а не вершать ярлыки
Дополнительный бонус — всё можно запустить на своём рабочем ноутбуке, без прыжков с Docker compose или недо-куберами типа k3s. Просто из среды разработки. Тестовая БД доступна через VPN, при желании и достаточной смелости можно подключиться и к продовой.
То же самое — можно запустить локально хоть часть, хоть все, БД, очереди и кеши доступны через впн. Компоуз файл написан один раз и используется всеми простой командой docker compose up, поднимая заодно и некоторые локальные зависимости. Что с этим не так?
Ошибки — опциональный откат на предыдущую версию (делается минуту), исключение проблемного коммита или коммитов, новый деплой. Можно уточнить кстати про пример с утечкой памяти? Это абстрактный или конкретный был пример, можно детали?
Учитывая, что у вас голубосиний деплой, вы все это время держите две продовые площадки, пока ищете ошибку, собираете и накатываете по новой, верно? Не очень выгодно. Пример не абстрактный, а вполне реальный — апдейт одной из гошных либ привела к утечке памяти под нагрузкой, просто откатили версию назад одного из микросервисов и разбирались с причиной, другие микросервисы и пользователей это не затронуло вообще. А в вашем варианте будет даунтайм, как думаете? Вы же уже переключите на, положим, блю, и течь будет везде по всему монолиту, верно?
Про "изолированно чинить микросервис" и "скейлить монолит", я бы хотел послушать не абстрактные измышления, а конкретные примеры.
Я в предыдущем комменте привел более чем конкретные примеры с разными типами задач для разных микросервисов, с разными типами нагрузок (burst load/spikes/plain). И выше привел пример как чинить микросервис(в кавычки взяли вы потому, что у вас как-то по другому это называется)? Эти разные типы задач скейлятся сильно по разному, и требуют даже иногда разных инстансов для оптимальной работы — некоторые жрут ЦПУ, некоторые память, некоторые коннекты, некоторые другие ограниченные ресурсы, например API ключи. А еще у нас декстоп клиенты под 60к в пике со своими фокусами, и под них тоже нужны свои прцедуры скейла.
Жизнь становится сильно интереснее, если у тебя не просто сайт с блогами и картинками, даже если это drive2.ru
Монолит, если его развёртывание автоматизировано, прекрасно масштабируется в обе стороны.
Я когда-то скейлил ворпресс, там да, хорошо мастабируется в обе стороны. Но далеко не кажды сайт или приложение в инете это простой вордпресс.
Если вам нужна ETL-задача (2 часа в сутки), её можно назначить на отдельную группу экземпляров монолитов, которая масштабируется по другим правилам.
Конечно можно. А можно на каждую задачу по своей группе экземпляров монолита со своими скейл-правилами, хотя постойте, чем это будет отличаться от микросервисов, ну кроме межсервисного взаимодействия?
Вместо того чтобы делать RPC между каждым из компонентов с кучей "клея" в виде кубера, service mesh и т.д., на содержание которого нужен целый отдел. Не вопрос, этим всем может быть интересно заниматься, опять же за "микросервисный девопс" хорошо платят.
http вызовы это RPС, как думаете? Кубер это не клей, это оркестратор, я им и монолиты успешно скейлил простые, а вы чем их скейлите, руками или скриптом?
service mesh отдельный разговор, он не всегда нужен, но там где нужен — в сложных распределенных системах, там он очень помогает в плане visibility & management. Нам на всю нашу платформу хватает трех человек, которые занимаются всеми инфрастуктурными вещами. Зачем вам отдел под "клей" — ума не приложу.
Микросевисного девопса не бывает, девопс это методология и она включает разные варианты — от простейшего веб-сайта, до ML/AI. Вообще за девопс неплохо платят, да, думаете зря? )
С умным видом рассказывать что ты не JSON-ы из БД в HTTP перекладываешь, а настраиваешь Cilium и оркестрируешь контейнеры =)
Перекладыванием json занимаются разработчики, я им предоставляю платформу для максимально удобной работы. Контейнеры у меня оркестрирует кубер, а у вас? что касается CNI, я уж не помню, когда последний раз в его настройки залазил, последние 5 лет все работает из коробки.
В общем, я думаю у нас просто разные подходы к devops, поэтому вам кажется что я придумываю проблемы на пустом месте, а мне кажется, что ваш специфический опыт подходит далеко не всем.
пс. было бы любопытно встретиться на собеседовании, я бы поспрашивал вас по нюансам скейлинга монолитов =)
Вроде как очевидно, что скейлить 95% функционала ради 1-5% попахивает. Скейлинг он тоже разный бывает. Вычислительный, сетевой, сложный, с оганичениями, ретраями, динамической балансировкой, балансировкой по предписанию. А если окажется, что для повышения эффективности нужно вообще сменить технологию? Или это такой супер-мультиязычный монолит? :) Что делать, если потребуется выделить независимую команду на развитие функции, которая сидит в монолите? Много вопросов, но при этом до сих пор не смотрели на задачу.
Тут как обсуждение коня в вакууме. Что лучше, и любой адепт молотка скажет любому адепту отвёртки, что он любой шуруп сможет в лёгкую забить молотком, и в чём преимущество отвёртки? В отрыве от конкретных задач и условий все рассуждения что там скейлится-нескейлится, просто бессмысленная трата времени.
Самое печальное, что я наблюдал в практике, это то, что выбор монолита зачастую обусловлен одной единственной причиной: так разработчику удобнее, так разработчик привык. Не взирая больше ни на что. И он будет до посинения доказывать свою правоту. И в то же время, другой разработчик, поймавший хайп будет стремиться во что бы то ни стало, всё распихать по микросервисам. И тоже будет до посинения защищать свою позицию.
И оба категорически будут не правы. Независимо от приводимых аргументов. Они не смотрят на конкретную задачу.
Это я вам ещё про SOA не напоминал, а то мы, получается, живём в чёрно-белом мире, где либо монолит, либо микросервисы (или, прости Ктулху, облачные функции).
Видимо в вашем понимании в мире микросервисов все происходит легко, а если приложение монолитное, то все становится резко сложнее.
По факту, с точки зрения развертывания, монолит это один микросервис. Докеру и куберу абсолютно без разницы что у вас в образе. Все техники devops применяются для монолитов точно также, как для микросервисов. Только меньше сервисов надо деплоить\обновлять.
Монолиты очевидно жрут меньше ресурсов. Оверхед приложений\контейнеров\виртуальных машин меньше, так как просто меньше инстансов поднимать. Экономия на объеме данных, IO и трафика для очередей и синхронизации. Не нужны системы сбора и анализа распределенных логов.
Скейлится монолит очень лего. Не хватает ресурсов - добавляем. Как я уже писал выше - сначала scale up, потом scale out. Да, вы будете скейлить одновременно и память и процессоры, потому что программа упрется во что-то одно. Так и хосты для кубера вы также будете скейлить одновременно и по памяти и по процессорам.
У микросервисов есть одно неоспоримое преимущество перед монолитом - высокий темп релизов при больших командах, и то надо соблюдать немало условий чтобы он был достижим. В остальном недостатки.
у вас в монолите в обработчике очереди паника, сервисы валятся и лежит весь монолит
Во-первых это красивая байка, но во всех современных системах исключения перехватываются и логируются, а фронт продолжает отвечать на запросы, даже если какая-то фоновая задача падает.
Во-вторых в монолитах самих очередей будет меньше, так как они просто не нужны. передача управления делается вызовом функции.
Так что я пока не увидел преимущества монолита перед микросервисом
Ну да, снижение затрат в 10 это не преимущество, а фигня какая-то.
Если факты противоречат моей теории — тем хуже для фактов (с) Гегель
Блин забавно видеть, что несмотря на очевидную и простую как 2x2 мысль: решение нужно выбирать исходя из конкретной задачи и конкретных условий, всё равно, вот прям настойчиво пытаются сравнивать монолит и микросервисы. Чем объяснить наличие адептов одной и другой архитектуры? Они ведь не противопоставляются другу другу, а дополняют.
>> У микросервисов есть одно неоспоримое преимущество перед монолитом - высокий темп релизов при больших командах, и то надо соблюдать немало условий чтобы он был достижим. В остальном недостатки.
Ох, как же грустно наблюдать такие выводы. Нет, никаких преимуществ у монолита перед микросервисами и нет преимуществ у микросервиса перед монолитом. Вообще, ни по какому направлению. Всё исключительно зависит от конкретной задачи и конкретных условий.
Даже одну и туже задачу в одних условиях эффективней впихивать в монолит, а в других так делать ни в коем случае не надо.
Видимо в вашем понимании в мире микросервисов все происходит легко, а если приложение монолитное, то все становится резко сложнее.
Слушайте, я занимаюсь "миром микросервисов и монолитов" уже более 8 лет, я сам пытался писать окрестратор на Ansible как раз для монолита, потому что руками его было раскатывать нереально в то время и я ленив. Так вот — там никогда не было легко, но сложность микросервисов компенсируется с лихвой их гибкостью, если вам это не надо, пользуйтесь монолитом, это не грех. Одно другого не исключает, даже гибриды есть, но это не значит, что монолит или микросервисы это плохо, они каждый для своего для своей архитектуры.
По факту, с точки зрения развертывания, монолит это один микросервис.
Точно? А не набор сильно связанных сервисов? Там немного другие техники развертывания, микросервисы я могу обновить покомпонентно, а монолит мне придется делать хотя бы green/blue чтобы не пятисотить пользователям. И это если у вас относительно простое приложение, а если там много частей и монолит монструозен?
Монолиты очевидно жрут меньше ресурсов.
Вообще ни в каком месте не очевидно. Для оптимальной работы монолита его наверное надо запускать с определенными лимитами/реквестами, если монолиты вы хостите на одном инстансе, либо монолит на инстанс. То есть вы заранее выделяете какое-то количество ресурсов, для того чтобы запустить все компоненты монолита (а представьте что у вас он при старте качает 1Gb инфы просто чтобы начать работать, например текущие схемы обсчета данных). И по итогу, если мне надо скейлить другой функционал, не связанный с данными, я вынужден буду держать часть ресурсов монолита вхолостую.
Скейлится монолит очень лего. Не хватает ресурсов — добавляем. Как я уже писал выше — сначала scale up, потом scale out. Да, вы будете скейлить одновременно и память и процессоры, потому что программа упрется во что-то одно. Так и хосты для кубера вы также будете скейлить одновременно и по памяти и по процессорам.
Я выше расписал, почему это не легко, если система относительно сложная и разные профили нагрузок. Вы будете скейлить монолит одновременно по всем метрикам, верно, в случае микросервисов вы можете задачам с высоким потреблением цпу дать машины с много цпу мало памяти, в случае с скейлингом по памяти дать memory-type машины, в результате вы не тратите лишние ресурсы там, где не надо.
У микросервисов есть одно неоспоримое преимущество перед монолитом — высокий темп релизов при больших командах, и то надо соблюдать немало условий чтобы он был достижим. В остальном недостатки.
А в маленьких все будет плохо? Возможность выкатывать изменения не ломая соседу жисть это только на больших объемах работает?
Во-первых это красивая байка, но во всех современных системах исключения перехватываются и логируются, а фронт продолжает отвечать на запросы, даже если какая-то фоновая задача падает.
Вообще ничего не понял, с каких пор "современные системы" стали свободны от ошибок реализации и логики? Утечка памяти тоже логируется? А логи кто вставляет в приложение? А исключений перехват и обработка? Не разработчик? Фронт отвечает — бэк нет, из-за паники в горутине. Вполне стандартная ситуация.
Во-вторых в монолитах самих очередей будет меньше, так как они просто не нужны. передача управления делается вызовом функции.
Простите, что? Для чего, по вашему, нужна очередь сообщений? Как вам передача управления посредством функции решит проблему доставки и хранения запросов? Давайте тогда через очередь пример — вы, например, чуть сложнее блога и у вас очередь запросов, ну например вы таки ее догадались внедрить после падений монолита и потери запросов, несмотря на красивую идею делать все через вызовы функций(кстати, а вы в монолите мгновенно все запросы обрабатываете, в отличие от микросервисов и запросы не копятся? а если копятся то где, в монолите?). Вы делаете в монолите изменения в части, не связанной с очередью и выкатываете на прод. Прод падает, с ним и обработка очереди. Вполне реальный пример. Что делать будете?
Ну да, снижение затрат в 10 это не преимущество, а фигня какая-то.
Слушайте, я верю, что они там снизили затраты в 10 раз, это не фигня, вопрос был — точно ли снижение затрат это следствие перехода с богомерзких микросервисов в православный монолит, или это результат переработки архитектуры и отказа от хранилища в качестве медиатора данных. Вот я это и пытаюсь выяснить, но пока что не удается
Если у вас каждый день возникают такие вопросы, то монолит не для вас. Но крудошлепам, которые гоняют json от фронта в бд через три слоя микровервисов (встречал такое на практике - архитектор повторил MVC в масштабе микросервисов и страшно гордился этим), микросервисы не нужны, им хватит и монолита.
Вот собрал я свои глупые микросервисы(ввод данных, обработка, вывод) в один сияющий монолит, хорошо. Как его скейлить?
Использовать более производительный сервер, очевидно. 99% онлайн-софта никогда не встретится с проблемами масштабирования, которые бы не решались таким способом.
ради увеличения мощности одного компонента, например ввода данных, мне нужно скейлить весь монолит, оставляя обработчик данных и вывод работать вхолостую?
Это теория, а на практике обычно будет ровно одна критичная в смысле производительности подсистема, которую и нужно будет оптимизировать, а остальным можно будет пренебречь.
Наиболее критикуемый аспект микросервисной архитектуры - это резко возрастающая сложность инфраструктуры проектов, применяющих данный подход. Об этом говорится и в статье, и в комментариях под ней. Подозреваю, что у большинства (если не всех) остальных проблем, приписываемых МСА, ноги растут именно оттуда.
В свою очередь, фундаментальной причиной сложности инфраструктуры является необходимость организовать взаимодействие между микросервисами, которых будет, очевидно, много. А по скольку каждый еще ради ha и масштабирования будет запущен на куче инстансов, итоговое число легко перешагивает за 1к. И все это на фоне того, что микросервис на то и микро, что за значительной частью данных он обращается к множеству других микросервисов.
При этом в большинстве МСА архитектур, развитием которых я занимался, микросервисы для взаимодействия использовали классические подходы, заточенные под p2p модель: REST/HTTP, SOAP, gRPC, тысячи их. Я хочу высказать (очень спорное) предположение, что эти классические решения не годятся для МСА, т.к. они и делают инфраструктуру микросервисного проекта очень сложной, добавляя как минимум такие обязательные компоненты, как:
1 - балансеры, чтобы нагружать кучу инстансов одного сервиса равномерно
2 - service discovery, чтобы вообще найти, куда слать запрос
3 - какие-нибудь аутентифицирующие/авторизующие прокси, которые проверят, что сервисам можно общаться друг с другом
И все это надо поддерживать, своевременно обновлять, и не забываем про безопасность.
В одном из своих старых проектов я попытался побороть эту сложность с помощью организации межсервисного взаимодействия не в p2p формате, а через посредника, в качестве которого использовалась очередь сообщений. Этот формат избавил меня от необходимости тащить какой-то service discovery, т.к. каждый микросервис коннектился только к одному компоненту - очереди сообщений. Балансировка также осуществлялась очередью. Решение получилось не без проблем, конечно: проприетарное и с костылями (т.к. очереди сообщений - это больше про pub/sub, а не request/reply). Но я задумался, что могло бы получится, если бы условный гугл или яндекс предложили что-то вроде grpc через очередь сообщений, со всеми плюшки первого (кодогенерация, code as documentation...) и второго (балансировка, масштабируемость, слабая связность, pub/sub и т.д.).
Я когда-то тоже "сломался" под влиянием хайпа и провел оценку перевода одного проекта монолита на микросервисы. И тоже пришел к выводу, что надо пытаться использовать очередь. Требования к быстродействию никак не вписывались в ограничения rest http и ему подобному.
В свою очередь, фундаментальной причиной сложности инфраструктуры является необходимость организовать взаимодействие между микросервисами, которых будет, очевидно, много. А по скольку каждый еще ради ha и масштабирования будет запущен на куче инстансов, итоговое число легко перешагивает за 1к.
Их может быть пять, микросервисов, и они могут работать как в одном экземпляре, так и в 1000. Для абстрактного HA достаточно двух. То есть конфигурация может быть сколь угодно разной, не обязательно это куча инстансов-сервисов.
1 — балансеры, чтобы нагружать кучу инстансов одного сервиса равномерно
2 — service discovery, чтобы вообще найти, куда слать запрос
3 — какие-нибудь аутентифицирующие/авторизующие прокси, которые проверят, что сервисам можно общаться друг с другом
Если вы используете микросервисы, то вы наверняка будете использовать оркестратор для них. А в кубе или openshift это уже все есть из коробки, ну может кроме аутентификации, хотя это решается mTLS, наверное.
И все это надо поддерживать, своевременно обновлять, и не забываем про безопасность.
все нужно обновлять и поддерживать, и микросервисы и монолит и оркестратор и инстансы. Жиза. На автопилоте работают только очень простые вещи, а проблема безопасности вообще отдельная тема.
В одном из своих старых проектов я попытался побороть эту сложность с помощью организации межсервисного взаимодействия не в p2p формате, а через посредника, в качестве которого использовалась очередь сообщений.
Я посмотрел вашу статью, любопытно. Мне кажется, что решение service discovery проблемы немного в стороне от проблемы непосредственно взаимодействия — шины. Кстати как по мне, шина и очередь отличаются, очередь хранит сообщения, а шина лишь для связи, но это детали уже. А вот идея запихивать gRPC в очередь это оригинально ) Единственное, что смущает это критическая зависимость такой архитектуры от очереди и ее состояния.
Кстати, рекомендую посмотреть в сторону ZeroMQ/nanomsg и прочих распределенных фреймворков, там балансеры делаются очень хорошо. Может и брокер не понадобиться.
Спасибо за отзыв) Вообще я смотрел zeromq, но не помню уж по какой причине не стал его использовать. Возможно, не придумал, как мне там реал-тайм мониторинг и моканье АПИ реализовать более-менее тривиально (а для меня эти возможности критически важными были) и в сжатые сроки, т.к. всю архитектуру: клиентские либы, инфраструктурные инстурменты для разработки и документирования и т.д., я один делал. Ну и конечно не хватало альтернативных мнений)
Про зависимость всей системы от очереди - вы совершенно правы, так и есть) Но я признаться на практике за 15+ лет работы не встречал архитектур, в которых не было хотя бы 1го компонента, при падении которого вся система превращалась в тыкву. Поэтому на первый план выходит то, как быстро вы сможете обнаруживать и реанимировать такие компоненты. Именно по этой причине я топлю в статье за nats, который подкупает максимальной простотой конфигурирования и в хорошем смысле "тупостью" - легко перезапускать. Сравните с каким-нибудь реббитом, который может попасть в сплит-брейн.. Ну и вообще, за 3 года у меня ни разу натс не упал. Не готов рекомендовать свое решение всем подряд, но в моем случае для средней системы с 200к онлайном и 3-4k rps было хорошо, и запас сверху точно был (правда не успел поисследовать, какой в точности).
Не хватает фактологии в части того, сколько эксплуатационных расходов они могли бы сэкономить, перейдя с json на ProtoBuf, или хотя бы на http 3. Также непонятно какой вклад в рачходы вносит докеризация и виртуализация. Также сомнительно про 90%, потому что тогда сколько нагрузки на серваках субд, которые так просто не сократишь. Допустим, у них было условно 90 серверов бэка и 10 базы, тогда сокращения на 90% достичь практически невозможно.
Я разрабатываю финтех-платформу с командой уже 6 лет. Изначально было около 7 главных микросервисов, потом мы штамповали не глядя еще и дошли до 30, но теперь постепенно схлопываем. Не в рамках отдельного процесса, а между делом. И да, понятно, что парсинг json может занимать 50% нагрузки, но у нас нет миллионов пользователей, у нас их несколько десятков тысяч, и мы умещаемся на десятке серверов в хецнере по 40-50 долларов. И даже если их станет на треть меньше - это не будет существенным фактором для проекта. Возможно даже будет в минус, потому что при отказе железа больше компонентов будет отключено и меньше будет запас под скачки трафика.
Из 10 серверов у нас 4 под два кластера базы, три для бэка, и три специфических для других нужд. По сути даже и сокращать некуда.
Для повышения производительности мы чаще используем денормализацию базы или другой вид кэширования, хотя делаем это максимально осторожно, потому что увеличивается количество кода, ответственного за поддержание консистентности.
В статье отсутствуют какие либо аргументы - только набор ничем не подкрепленных эмоциональных заявлений, суть которых сводится к "мы попробовали X, у нас ничего не получилось, стало быть X - говно"
Это основная проблема сегодняшних разработчиков в подвёрнутых штанишках. Они как белки неврастенички, бегающие с очередным орехом.
"Индустрия" сначала сказала, что софт скиллы преобладают над хард скиллами. Просто поставили все процессы в такое ракообразное состояние, что таки да - главное, чтоб бы человек был не токсичный.
Сейчас "индустрия" дошла уже в своей шизофрении до того, что говорит, что хард скиллы вообще не нужны. И да, как работает бигтех - они действительно не нужны.
Вот и получаются у этих замечательных "специалистов" с преобладающими софт скиллами и без знаний в предметной области всякие забавные решения и при эксплуатации своих решений, эти замечательные люди делают такие же замечательные выводы.
П.С. Всегда относитесь к поляризованным мнениям, идеям, выводам с настороженностью. Правда - она всегда серая.
Если читать оригинальную статью с которой все началось, то там кажется основная соль не в микросервисах а вообще в преждевременной оптимизации.
Whereas running media conversion once and caching its outcome might be considered to be a cheaper option, we found this not be a cost-effective approach.
То есть воткнули некое подобие кэша (со стейтом и всеми сопутствующими приключениями) там где он невыгоден. Ну, ок, бывает.
Микросервисы-то тут причём?
Мнение бьет радикализмом по радикализму, парни кодировали видео гоняя через внешнюю шину огромные обьемы данных, по факту их «монолит» это архитектурно один микросервис и они просто выяснили, что не стоило было его пилить на дополнительные гранулы. То что они обернули это в громкие заявления, возможно, пытаясь оправдать затраты на рефакторинг изначально ошибочной архитектуры компонента не делает им чести. Вся эта история говорит лишь о том, что не стоит увлекаться гранулированием компонентов сверх необходимого и о том, что нужна коммуникация между проектами сверх ссылок на апи, потому что от этого уходит на задний план понимание того, что команда пилит компонент большой системы, а не black box - отдельную и независимую систему, и архитектуру ее нужно рассматривать в рамках архитектуры общей системы.
Все беда в том, что многие думают, что микросервисы - это ответ на решение технических проблем.
Нет. Микросервисы - это ответ на проблемы масштабирования команд разработки. И основной критерий микросервисности - за один микросервис отвечает ровно одна команда. И соответственно, каждая команда пилит свой сервис без оглядки на другие команды, ответственность только на уровне контракта по API.
Если одна команда может пилить большой сервис, aka монолит, и бизнес устраивает скорость поставки - все замечательно, пилим монолит.
Даже Amazon не может разобраться в serverless и микросервисах