Мікросервіси — чи до смаку?
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Я тут зняв відео про мікросервіси зі всією правдою, тож камон дивитися і обговорювати :)
×
Олександр Соловйов, Podcaster в DOU/1-2-3 Techno
Facebook
Twitter
LinkedIn
Схожі топіки
Android
По умолчанию лучше монолит. Если у вас нет конкретных доказательств, почему именно вашему проекту нужны микросервисы, как именно этот проект на микросервисы разбить и почему надо разбивать именно так а не иначе — значит они вам не нужны. Начинаете дружно со stateless-монолита и плавно идёте к тому, что вам микросервисы так никогда и не понадобятся в 99% случаев. В остальном 1% случаев разбивка на микросервисы когда-то понадобится, но таким образом, который вы на старте проекта не могли даже предположить, и намного позже, чем вы думаете.
Volodymyr Pavlyshyn
Нелише про мікросервіси dou.ua/forums/topic/38805
Andriy Prokopiv
Все правильно автор розказав. Розробка програмної системи розпочинається з моделювання результатом якого є набір моделей причім останні на 90% стоять ногами в предметній області і на 10% в архітектурі майбутньої системи. На цьому рівні повинні вирішуватися питання масштабування і майбутньої еволюції, проробка архітектури (імплементації моделі) може щось додавати до можливостей масштабування і тільки. Проблеми гарантовано виникають коли питання масштабування починають зводити до архітектури і 100% коли до роботи девопсів (жодним чином не заперечую участь як архітекторів так і девопсів дотично питань масштабування). Далі сама постановка питання моноліт чи мікросервіси є в якомусь сенсі дивна — якщо в межах моделювання ми отримали якусь підсистему котра в термінах моделі може передбачати ізольовану роботу (і має сенс) — ну то ми отримали ізольовану підсистему ї її звязок — бінарний чи через http — не більше чим нюанс розгортання. Потрібно уникати ситуацій коли десь на рівні реалізації архітектури чи розробки хтось вирушує ізолювати якусь частину системи (бо йому так здається «масштабування» з точки зору побудови кодової бази...).
Взагалі моделювання, архітектура і тд це власне вибір варіанта декомпозиції, а вона є присутня завжди (по іншому люди не вміють вирішувати складні задачі). Декомпозиція є присутня і в тому, що називається «монолітом» і в тому, що називається «сервісами», якщо вона зроблена грамотно (а насправді талановито — це є в якійсь мірі творча праця) то прекрасно розвивається система, локальність зміни в вимогах з сторони предметної області відповідає локальності змін з сторони кодової бази, розробники отримують можливість інтуїтивно розуміти систему, а спеціалісти експлуатанти з боку предметної області починають розуміти суть ботлнеків, якщо такі виникають.
Сам перехід від «моноліта» до «сервісів» чи навпаки не повинен (якщо система грамотно побудована) становити значної складності.
І так, якщо на проекті 10 програмістів то в 99.9% випадків правильно задизайнований моноліт — саме те, що треба, особливо на початкових етапах створення системи.
Fedor
Есть хорошие эмпирические правила, соблюдая которые холивар не имеет смысла.
1) Одну бизнес фичу разрабатывает одна команда.
2) Каждая команда единолично владеет кодом и данными.
Если удалось так организовать работу в монолите не будет трудностей и при необходимости (независимое масштабирование, другой стек и т.д.) выделить часть приложения в микросервис.
Если нет, то микросервисы не спасут ситуацию, а могут даже усугубить проблемы плохого дизайна системы.
Sergiy Morenets
Загалом вибір архітектури — це прерогатива архітектора проекту (або цілого напряму). Хоч би що говорили розробники, саме він вибирає каркас для всього проекту, оскільки він несе за це відповідальність.
Alex Garagatyi
Ну це хєрня для компанії яка боїться ростити людей і має одних джунів. Не бачу проблеми в тому щоб пара сіньйорів задизайнили частину системи.
Також оці всі архітектори це все «аутсорсна» тема. В нормальній продуктовій компанії немає архітектора який розуміє всі проблеми всіх напрямкі а також система еволюціонує поступово, тож немає вотерфольного способу проектування всієї інфраструктури.
YG
та просто він трохи не в темі. процеси набагато ширші, ніж він пише.
Автор трохи не в темі, бо крім мікросервісів, зараз нові схожі тренди — міні-сервіси та макросервіси. Відповідно, вибір набагато ширший, ніж він пише.
Цікаво чого ви зробили висновок що автор не знає. І чого вирішили одразу опустити автора тим що він чогось не знає. Він же наче описав що в його кейсі моноліт працює норм і у них розмір команди не потребує розділення сервісів.
Ну і хочу зазначити що всі ці макросервіси і оце все це просто термінологічне прискіпування. Багато компаній які мають мікросрвіси не створюють по мікросервісу на кожен мікро домен який мають. Мікросервіс може рости доти доки це не болить. Потім його ділять на декілька.
Чи це означає що є якийсь новий паттерн? Та ні, просто мікросервісна архітектура об’єднана з «common sense». Треба пам’ятати що програмісти існують не для того щоб плодити сервіси чи розгрібати старе лайно моноліту. Вони існують щоб створювати користь користувачам. Все інше то оптимізації витрат часу і ризиків. Але автор і це зачепив у відео згадавши що інженер балансує час витрачений зараз і в майбутньому.
По умолчанию лучше монолит. Если у вас нет конкретных доказательств, почему именно вашему проекту нужны микросервисы, как именно этот проект на микросервисы разбить и почему надо разбивать именно так а не иначе — значит они вам не нужны. Начинаете дружно со stateless-монолита и плавно идёте к тому, что вам микросервисы так никогда и не понадобятся в 99% случаев. В остальном 1% случаев разбивка на микросервисы когда-то понадобится, но таким образом, который вы на старте проекта не могли даже предположить, и намного позже, чем вы думаете.
Fedor
Монолит монолиту рознь.
Если говорим о модульном монолите с изолированной логикой и данными по бизнес контекстам, то это правда. Монолит ферст лучшая практика.
Если говорим о комке грязи (что в 99% кейсах подразумевают люди, которые говорят что микросервисы не нужны), то этот монолит через пол года — год активной разработки уже не будет смысла на что-то разбивать.
Где физически будут выполняться разные части приложения в одном контейнере или нескольких тут второстепенное.
Если говорим о комке грязи (что в 99% кейсах подразумевают люди, которые говорят что микросервисы не нужны)
Це шо за булщіт?
Big Ball of mud. Наприклад тут
thedomaindrivendesign.io/big-ball-of-mud
exceptionnotfound.net/...ly-software-anti-pattern
Ти шо подумав шо я дівчинка і вирішив зайнятися mansplaining’ом чи шо? Я не питаю дефініції, я питаю нащо ти таке пишеш? Така тупа підміна тези — це якось ну дуже далеко від адекватної дискусії.
Я это и не тебе писал если что. А ответил на коментарий.
Ну то яка різниця? Яким це чином люди, які кажуть, що мікросервіси не потрібні, мають на увазі, що треба писати соплі?
Просто спостереження. А про 99% таке саме перебільшення як і
микросервисы так никогда и не понадобятся в 99% случаев.
.
Не приймай на свій рахунок. Можливо у вас нормальний модульний моноліт і мікросервіси дісно вам не потрібні.
Android
Если команда не в состоянии построить модульный монолит — мне страшно представить, что же там будет в микросервисах.
Принципиальная разница в том, что даже если это будет комок грязи, то этот комок грязи скорей всего уже будет в проде приносить деньги. А пока конкуренты будут пилить микросервсы — у них просто деньги закончатся и инвесторы уйдут.
Я уж молчу про то, что если команда пилит комок грязи из монолата — то и микросервсы в реализации такой команды станут просто распределенным комком грязи.
Не правда. Вернее частично правда.
Если команда без квалификации будет сама принимать решения в дизайне микросервисов, то получиться распределенный монолит это да.
Но при этом контролировать изолированость функционала и данных в монолите тяжелее. И отследить скатывание в комок грязи не так просто. В микросервисах с отдельными репами, базами и комуникацией только через согласованные контракты это получается более естественно.
И чем больше команд работает, тем более очевидными становяться преимущества микросервисов.
Вы, видимо, живете в мире, где на каждом проекте по 1000 бекендеров. Я пока видел только проекты типа «16 микросервисов на 3 разработчика». Это как доказывать, что на каждом корабле нужно минимум 1000 кают, приводя в пример авианосец, когда на 1 авианосец в мире 10 миллионов одноместных рыбацких лодок.
Но при этом контролировать изолированость функционала и данных в монолите тяжелее.
Это мне напоминает спор типа Java лучше NodeJS (JavaScript) потому, что статическая типизация помогает избежать ошибок. Я работал как бекендер на Java и NodeJS, а также работал как фронтендер на более чем 10 проектах, где бекенд были и на Java, и на NodeJS, и на .NET. Могу сказать только один вывод: статическая типизация ни от чего не спасает, тупые баги и ошибки на каждом шагу. Хорошо работает там, где грамотное тестрование (автоматизированное интеграционное) и архитектор толковый, независимо от платформы и типизированности языка.
По факту получается, что говно получается не от монолитности или микросервисности, а от (не)квалификации разработчиков. А «принуждение к изоляции» через микросервисы — штука такая, мягко говоря, очень дорогая. Микросервисы создавались как решение проблемы масштабируемости, когда у тебя десятки миллионов запросов в секунду и датацентр уже подгорает. Стоимость грамотных микросервисов очень высока, неграмотных — еще больше. Перед тем, как делать микросервисы, надо очень хорошо понимать зачем. Как показывает практика, в 99% проектов вообще никогда не наступает момент, когда приходится решать проблемы, для которых придумали микросервисы. Зато в каждом проекте, где есть микросервисы, возникают проблемы, связанные с самим фактом использованием микросервисов. ОЧЕНЬ МНОГО серьезных и муторных проблем, которые удорожают и замедляют разработку, тестирование, деплоймент и генерируют тонны дополнительных багов.
Именно поэтому почти никакой проект (есть очень редкие исключения) вообще не стоит начинать даже с мысли про микросервисы. Просто потому, что они никогда не понадобятся, скорей всего, а заплатите вы за них с первого дня по полной.
user-dou-220624
Если говорим о комке грязи (что в 99% кейсах подразумевают люди, которые говорят что микросервисы не нужны),
Я бы сформулировал иначе. Микросервисы (в 99% кейсов) пропагандируют те, кто не осилил в монолиты — и надеятся, что с микросервисами получится лучше.
Но не получится. Т.к. получится всё тот же «комок грязи» только распределённый (со всеми дополнительными проблемами).
Evgeniy Moroz
Питання безпеки не затронуто.
Теж свої pros and cons.
Але сходу — моноліт за замовчуванням буде мати доступ до всіх даних, тож простий sql injection в якійсь не дуже секьюрній частині монолітну дає доступ до всієї бази, в той час в якомусь не великому сервісі бласт ураження буде дорівнювати правам того сервіса.
Але я згоден що це може вірішати як і в моноліті так і напартиачити в серавсній архітектурі, але замовчування всеж на користь ізоляції. Та і вирішуваня на рівні монолітну поступово почне штовхати рівень складності монолітну до сервісів.
Если в голове дыра — то микросервисы не помогут. Реально, я был на проекте, где вся секьюрити развивалась об дуризм разработчиков, это как раз были микросервисы, и разработанная ими дыра экспоузила сразу вообще все в течении нескольких месяцев. Я работал с кодом Андроид-приложения и когда пришёл на проект — оно уже было реализованно и я просто долго не смотрел в код коммуникации с сервером. Дырища же лежала на самом верху и, когда я, в рамках какой-то задачи, таки полез туда — то моему офигению не было предела. Еще меня никто не хотел слушать, что «так нельзя делать». Мне пришлось идти к ПМ и ему объяснять в чем дело, и только он пнул команды все поыиксить. Конкретный смысл дыры объяснять не буду, мало ли, но главное в другом: люди не умеют в секьюрити по умолчанию. Решать это можно отдельным человеком, который будет делать аудит кода и писать секьюрити-тесты. А еще лучше — не один.
Владислав Фурдак
Почему столько споров про эту тему? Все ж очевидно — есть pros & cons такого подхода.Задачей архитектора есть просчет и проэктирования дизайна системы. Тут нет холивара какого-то. Можно просчитать нужна ли такая архитектура или нет.
Можно просчитать нужна ли такая архитектура или нет.
Ну от як-то так виходить, шо прорахувати важко, і люди обирають від своїх вподобань. І, власне, моди.
Владислав Фурдак
Да ладно. Я конечно не архитект, но вот сразу в голову пришло, причем все из NFR:
— Независимый скейлинг, по любой из причин, например автоскейлинг или любая другая стратегия скейлинга какой-то из частей системы по причине экономии ресурсов или из других соображений
— Разный тех. стек имплементации
— Избегание конфликта зависимостей в рамках одного проекта
— Параллельный деплоймент/разработка. cannary/bluegreen деплой
— Необходимость сделать систему более устойчивой, оркестрация системы по частям.
— Необходимость разворачивать части системы в каком-то специфичном регионе
— Обеспечить максимальный аптайм
Ну как бы и все.. просто подумать ответы на эти вопросы и решить, а стоит ли такую архитектуру строить или нет.
Ну то коли з голови видумуєш, і виходить, що прям на старті проекта треба конфлікти залежностей розрулювати, blue/green деплой з монолітом не виходить зробити, і розподілена система більш стійка.
Максимальний аптайм, угу, це саме про мікросервіси.
Ну как бы, этап дискавери и проектирования
Чтобы NRF собрать
Как можно в слепую делать
Насчёт аптайма- ну так а чего нет, если что-то ломаешь, то наработает что-то одно , а не все сразу
DNA Exp
то наработает что-то одно , а не все сразу
Сразу вспомнилась анатомия человека. Не работает что-то одно. Почки отказали. Сердце не стучит. Мозг перестал реагировать.
Vitalii Lagutin
ну це трохи притягнуто за вуха... наприклад, в Приват24 переказ зробити можна, а квітанцію іноді створити не виходить. чи вмер при цьому весь функціонал Приват24? ;)
і так дуже часто буває в Приват24...
Лол. Можно подумать монолит бы «умер» не распечатав чек. Там таких багов может быть миллион. Залогировал эксепшин, показал сообщение пользователю и поехал дальше.
нуууу такоє. а якщо це баг який призводить до OOM, то буде моноліт — всьо. в міксосервісах впаде один. моноліт ще потім зазвичай буде не швидко підійматись... тому все дуже мінливо в цьому світі =)
Andrii Zhuk
А якщо хтось пише на IL, він і мікросервісом зможе покласти IIS, наприклад )
Vadim Kopanev
На il писать достаточно просто, подчиняется он тем же правилам что и дотнет, просто нет ограничений языка, на котором пишешь... Основы дотнет...
Зависит от того как задизайнить монолит.
Например ОСь, тот самый монолит и ООМ процесса для ОСи совсем не все.
В менеджед языках (c# java) есть куча практик с app domain где OOM будет тоже далеко не все и имплементация (для параноиков, учитывая частоту ООМ на проде) будет стоить три копейки, в отличии от микросервисов.
Коли зламав чекаут, то товари все ще можна побачити? То в моноліті так само, немає ж магічного перемикача «у сусідньому треді був ексепшен, терміново вимикаємось!»
к примеру часть системы просто отвалилась по какой-то из причин. Ну аптайм то ладно. Может не самый удачный пример. Но блин, если в проекте нет особо критичных вещей, относящихся к тем пунктам что я описал, нафига все усложнять и лепить микросервисы.
blue/green деплой з монолітом не виходить зробити,
Можно.
Bohdan Shulha
Чого це?
Можна легесенько покласти базу кривими запитами. Тож, якщо у вас на чекауті якийсь рагуль писав калькуляцію кошика, або хтось десь запустив важкий репорт — поляже (або добряче просяде по перформансу) і все інше.
Можна вижерти всю памʼять/процесор неоптимальними алгоритмами в якійсь надважкій частинці моноліту, від чого буде важко усьому.
В міксросервісах, натомість, поламані шматки будуть ізольованими.
Звісно, якщо у мікросервісній архітектурі ніхто не замислювався про graceful degradation, то результати будуть такі самі. Це вже не враховуючи, якщо мікросервіси буде розробляти той самий рагуль, що й важкі SQL запити пише :)
Сам також притримуюсь думки, що у більшості проєктів моноліт це найкраще рішення.
Але є пам’ять що тече і кладе весь сервіс по ООМ. Є файлові дескриптори для тредів що течуть і не дозволяють обробляти нові запити.
Дійсно є багато ситуацій коли можна сервіс зламати повністю. І це не обов’язково якийсь простий баг який кидає виключення. Іноді на дослідження йдуть тижні, і важливо щоб продукт працював. З чекаутом це не дуже буде працювати оскільки без нього продукт не робочий. Але от аналітика, відгуки, список останніх замовлень можуть бути зламані пару тижнів не маючи непоправний ефект на продукт
В теорії так і є, але на практиці «мікросервіс авторизації впав» вкладає систему частіше за шось схоже в моноліті. А локальні помилки плюс мінус однаково впливають і там і там.
Дійсно 99.9% продуктів ніколи не досягнуть розміру нетфлікса Десятирічної давнини. Але саме про 0.1% пишуть у новинах. Мрію про часи коли в коментарях до статті того хто працював в нетфлікс чи Гугл будуть коментувати інженери з грамарлі про те що вони теж доросли до таких проблем і їм цей досвід допоможе.
Dmitry Bugay
то наработает что-то одно , а не все сразу
Казки.
Нащо вам тоді сервіс, який ні з чим не пов’язаний, якщо його падіння лишається непоміченим в системі?
Vitaliy Fedoriv
Так це ж давній підхід: быстро поднятое не считается упавшим © ))
Питання не в тому що всіх пофіг що він ляже. Питання в тому щоб бізнес продовжував функціонувати коли сервіс ляже. І тут вступають в гру обмеження: при цьому функціонал Х не буде працювати, а функціонал У буде на кеші і тому не можна реалізмом сервіс Z або функціонал У буде не оптимальним бо буде побудований на простих правилах на клієнті для fallback замість використання історичних даних і machine learning; для бізнеса це означає: втрата грошей на тому і на цьому, недоступність некритичного функціоналу.
Усі ці ризики можна зважувати і приймати рішення щодо критичності сервісу і вимогам до команди яка його овнить — чи потрібні там тільки сіньйори чи і сідали будуть ок, чи потрібен моніторинг системи 24/7 з ескалацією вночі якщо метрики просідають, тощо.
Я боюсь що всі ці розмови не продуктивні саме через те що мікросервіси підходять більше великим командам і складним продуктам, а от коментарі пишуть люди у команді до 20 бекендкрів яким вся ця фігня не потрібна.
Зверну увагу що є компанії яким це може бути потрібним навіть попри малу кількість розробників — ті хто свідомо намагається тримати невелику команду на продукті з десятками мільйонів користувачів (bootcamp, etc)
Ну тут історія в тому, що я у відео прямо кажу — коли в тебе 200 людей, то думай сам. А все відео в принципі про те, як потрібно будувати щось з нуля, а не коли ти вже кілька років над тим працюєш і зазвичай вже непогано знаєш, що тобі треба.
А Basecamp гарний приклад, диви: m.signalvnoise.com/the-majestic-monolith
Вот всегда когда читаешь такой длинный список приимуществ, понимаешь, что какая-то маркетинговая технология. Обычно самые клевые вещи, которые когда либо были изобретены человечеством, имеют буквально
Типові аргументи мікросервіс-євангелизму, які на практиці або спотворені або не потрібні, або не релевантні.
Значит микросервисы не нужны ))
Volodymyr Ostapiv
Разный тех. стек имплементации
Ну це плюс поки команда овнить свій сервіс або парочку. А потім команді джавістів передають сервіс на пайтоні в нагрузку і починається весело )))
Артем Перекресний
Коли в тебе в руці мікроскоп, то все навколо здається цвяхами.
Брукс давно вже писав, що потрібно щонайменше три проекта, аби девелуперу вправило мізки. На першому проекті він має відчути свою здатність робити справу. На другому він має зрозуміти, що підходи з першого проекту не працюють. На третьому він має усвідомити, що простір вибору рішень є безмежним, і не можна тупо тицяти вже засвоєні навички в кожну дірку. Але багато кому вдається і на десятому проекті не прочистити чакри і не осягнути дхарму. Ставтеся до того філософськи.
Gremlin
Почему столько споров про эту тему? Все ж очевидно — есть pros & cons такого подхода.Задачей архитектора есть просчет и проэктирования дизайна системы. Тут нет холивара какого-то. Можно просчитать нужна ли такая архитектура или нет.
Це якщо дали час та бюджет щоб зiбрати вимоги та задизйнити.
Але-ж зазвичай треба щоб швидко-дешево MVP яке потiм трiшки допиляти й в продакшен.
Oleksii Ostapov
Так! Сам давно про це кажу — не треба сприймати мікросервіси як єдину можливу архітектуру, тільки тому що вона популярна. Бо на кожний плюс мікросервісів є жирний мінус.
І простота реалізації кожного сервісу має пряму залежність до складності інтерфейсів + проблеми інтеграції
Да люди думать головой не хотят. Думают что если выбрать подход как более универсальный и натянуть его на свое ТЗ просто проще будет. А оно нифига не проще и требует девопс оверхедов и грамотного дизайна системы, чтобы не наступить потом на грабли.
Как показывает опыт, те кто выбрали микросервисы из-за «моды», чаще всего в них херни наделывают.
Beaver Green
А ось вам зустрічне питання про моноліт. Що, якщо це проект не на 20 осіб, а на 50 мінімум? І всі ці 50 людей працюють з одним репозиторієм моноліту та однією базою. Очевидно, що жодна людина не встигне навіть переглянути, що ці 50 людей пишуть за день. Тобто ні в кого в голові усього моноліту немає.
Швидше за все, ці 50 осіб розбиті на 5 команд по 10 осіб, у кожної свій тех-лід, можливо на проекті кілька ПМ або БА (скажімо
Як взагалі можна уникнути накладок, дергадації архітектури, дублювання коду тощо?
Herman
Як взагалі можна уникнути накладок, дергадації архітектури, дублювання коду тощо?
а як цього можна уникнути, використовуючи мікросервіси?
Є архітектурні контракти та кодстайл, він однаково відноситься як до монолітів, так і до мікросервісів.
Beaver Green
а як цього можна уникнути, використовуючи мікросервіси?
Кожен мікросервіс має свою команду, свій репозиторій, свою базу. Зрозуміло, що це не гарантує відсутності багів — але це грантовано дозволяє ізолювати та інкапсулювати код, сховавши його за інтерфейсом.
Алексей Алексей
Як варіант, структурований моноліт: Кожна команда працює (переважно) над своїми модулями/таблицями дб/репо (можливо навіть в різних репозиторіях). Але все цілком — моноліт.
Можна навіть на рівні сервісів фіксувати контракти.
АЛЕ головне: все буде працювати в одній JVM і на одній базі, що на порядок зменшує головняк від distributed app.
Доки воно не переросте одну ноду/базу, це набагато ефективніше.
А коли почне переростати — у вас вже проект майже готовий до відділення мікросервісів на рівні вже існуючих контрактних сервісів, які ВЖЕ викристалізувались в проекті і вірогідність змін кордонів компонентів мінімальний.
Ну немає у нас ідеального світу. По-факту багато фіч зачіпає більше ніж один мікросервіс, починаються проблеми з узгодженням версій сервісів при деплої, вкл./виключенні feature flag і т.д.
Так, ти сховав код за інтерфейсом (ти в принципі і в моноліті можеш це зробити), але треба хендлити версії даних які передаються. І т.д. В принципі, можна окреслити якісь крайні випадки, коли доречно юзати тільки моноліт або тільки мікросервіси, але в багатьох випадках відповіді однозначної немає і тоді все залежить від уподобань/моди.
P.S.
В мене на одному з проектів був замовник, якому ми мігрували стару апку на мікросервісну архітектуру. Все б нічого, але досвід у них попередній і більшість апок — моноліти. І от вони не розуміли, коли ми їм починали задавати питання як вони хочуть бачити деплой для клієнтів, який час нам виділити на таски по конфігурації інфраструктури і т.д. Ну тобто в їхньому розумінні там нема чого робити — ото клієнту на Оракл DDL скрипт накотив, в конфізі апки задав потрібні параметри, прислав файл ліцензії і воно все працює. Ну ще SSL сертифікат спеціально навчена людина згенерує. )) А треба буде нову версію — так вони просто зміни в код внесуть, апку перекомпілять і клієнту відправлять. Коротше впирались як могли і всю інтеграцію відкладали на потім. «Потім» вилилось в кластери zookeeper, vault, keycloak, kafka, oracle + mssql, кілька мікросервісів, плюс налаштуання секюріті між всім цим добром, на стейжі і умовному проді, в останні тижні переж умовним релізом. Це був просто пц... Я хз як потім їхні деви + девопси (точніше ті люди яких вони так називали — із знаннями які недотягували до сисадмінів) все це розгортали у клієнтів. На щастя цей етап вони вирішили робити самі: «наші фахівці це зроблять самостійно, ваші послуги не потрібні» — чому ми були дуже раді. ))
ото клієнту на Оракл DDL скрипт накотив, в конфізі апки задав потрібні параметри, прислав файл ліцензії і воно все працює.
Так це і повинно так бути.
вилилось в кластери zookeeper, vault, keycloak, kafka, oracle + mssql, кілька мікросервісів, плюс налаштуання секюріті між всім цим добром
А оце — ІТ курильщика. Але із точки зору євангелістів мікросервісів — це прекрасно.
Volodimir Nazarenko
Відповідь така сама, як і на все в розробці софту — залежить від бізнес кейсу. Наприклад умовний фотошоп найкраще робити плагінною архітектурою, а не мікросервісами. Бо коли має бути можливість використовувати сторонній код, то органічним буде використання якогось сандбоксу, який завантажує контрактно-прописані модулі. Якщо у вас тона незалежного коду, і ви володієте всім ним, то це можуть бути сікросервіси. Якщо сериалізація — десереалізація і пропихування даних через хттп (більшість мамкиних мікросервісів то сунути в джейсон і послати через хттп кудись і синхронно чекати відповіді) то для вас занадто довго — велкам ту моноліт. Немає червоної таблетки для команди в 50 осіб, все завжди залежить від бізнесу.
Pavlo Vasylchenko
По собственному опыту масштабировать монолит запустив 2 инстанса проблематично из за того что он чаще stateful.
Чого б це він частіше стейтфул? Сучасні фреймворки заважають таке робити — і тому по дефолту ніхто такого і не робить.
Pavlo Vasylchenko
Пара причин с которыми сталкивался:
1) Есть требование или техническое ограничение которое не позволяет вынести стейт для одного из компонентов.
2) Если сервис монолит часто нет причин выносить состояние в внешнее хранилище жертвуя при этом скоростью и почти не получая ничего взамен.
2) Если сервис монолит часто нет причин выносить состояние в внешнее хранилище
Причина робити це є завжди, і це — скалабіліті. А якщо цією причиною або свідомо знехтували, або взагалі не подумали — то це і означає проїбати :)
Нужно смотреть на реальные требования, а не абстрактно. Даже если возможность скейлить есть (это не всегда так) надо смотреть что ожидается от сервиса и не придумывать что то самому. Так что я пожалуй не соглашусь.
Ещё добавлю что люди делают все одними
сервисом чаще чтобы сэкономить время на развертывании. С чего бы вдруг они начали вводить новый компонент типа редиса который усложняет деплой просто так?
С чего бы вдруг они начали вводить новый компонент типа редиса который усложняет деплой просто так?
По собственному опыту масштабировать монолит запустив 2 инстанса проблематично
:)
Ви самі відповідаєте на своє питання.
Повертаючись до питання дизайну — стейтфул можна і потрібно абстрагувати із імплементаціями як ін-меморі, так і на розподіленому сховищі.
Не закладаєте ні це, ні «непотрібний компонент» — маєте «ой а щось воно не скейлиться».
Нужно смотреть на реальные требования, а не абстрактно.
Можливість скейлити повинна буьи завжди. По-перше, вона завжди знадобиться при збільшенні навантаження, а воно збільшиться. По-друге, це просто тест на правильність рішення. Рішення що не скейлиться — неповноцінне і недолуге. Можливість скейлитись — це лакмуслвий папірець якості. Це як при написанні коду можливість покрити його юніт тестами. Не можна протестувать — код поганий.
Чого б це він частіше стейтфул?
Та тому, що писали його 5+ років тому, коли саме архітектура стейтфул моноліту з єдиною базою була в моді!
Ми дивимося на моноліт з різних боків: Ви пишете, що на сучасних фреймвоках, при грамотній команді можна написати не кривий моноліт і буде швидше і краще, ніж мікросервіси. І тут я не заперечуватиму Вам!
Моє питання на що перетвориться цей моноліт через 5 років? І відповідь на нього перед очима у більшості галерних рабів, які займаються підтримкою цих старих, прогнилих ентерпрайз-монолітів.
Хрушівки свого часу були чудовим вирішенням житлової проблеми. Ось тільки ніхто не думав, що люди продовжуватимуть жити в них через 50 років!
Та тому, що писали його 5+ років тому, коли саме архітектура стейтфул моноліту з єдиною базою була в моді!
Слухай, ну це смішно, ти запізнився років на 30. Не були в моді стейтфул архітектури вже дуже давно! Я пам’ятаю срачі про це у
Це якісь фантомні спогади.
До переписування коду написаного на мікросервісах ще просто не дійшла черга. ))
Хоча у нас на одному проекті, де моноліт ще існував, але паралельно вже була версія на мікросервісах (хоча «мікро» в даному випадку їх назвати можна було тільки в порівнянні з монолітом), вже вилазили проблеми «моди» — Netflix похерив hystrix, RxJava похерила підтримку версії 1.х і т.д. Хочеш — мігруй всю інфараструктуру на новіший стек і розгрібай нові проблеми, хочеш — фіксь старі самостійно.
Ну вначале нужно убрать стейт. Либо в какой-нибудь редис-шаред-провайдер если это старые фреймворке по типу web forms ну и остальные штуки повыносить. И можно скейлить.
Я так и делал и в моем случае это работало. Но кейсы разные есть. Бывают ситуации когда совсем нельзя скейлить какую то часть (из за латенси например). В случае микросервисов будет проще выделить это в отдельный инстанс и не трогать.
Всего-то во время написания надо сделать его stateless и никаких проблем. Именно так мы сделали на текущем проекте и — о чудо — оно масштабируется на несколько инстансов.
Значить, ви просто пофейлели дизайн а) самого моноліту б) його стейтфулу.
Бо стейт можна зробити відокремленим і розподіленим.
Маю досвід побудови великого і повністю скалабільного стейтфул моноліту, політ чудовий. Тому всі твердження що моноліт погано скейлиться — брехня.
Все сильно зависит от готовности компании (команды) использовать ту или иную технологию. Это часто упускается в обзорах. Если это стартап с одной командой и она разрабатывает один монолит, он большой, у них больше новых фич, меньше поддержки — это приемлемо.
Если же это много команд работают над одним монолитом и в это уже зрелый продукт — это не удобно. Уходит много времени на координацию.
Про деплой тоже зависит от готовности компании. Нужно учитывать какая экспертиза и какие процессы налажены в компании и выбирать тот подход который не будет этому противоречить.
Интересно будет послушать про кейсы — что выбрали, кто работал и что в итоге получилось.
Я навіть кажу про це у відео, шо коли в тебе є окремі команди для роботи кожна над своїм мікросервісом — то це відео не для тебе.
А коли в тебе 15 людей і вони в моноліті постійно в конфліктах мерж реквестів — то це модульність паршива і це треба виправляти.
Тут уже вiрно написали, що у кожного своє розуміння, що таке мікро-сервіси, а що — моноліт або проміжне «моноліт з макро-сервісів».
Але все досить просто, банально і 100500 разів обсмоктано. Все це основи ООП та ООД — адже все це покликане вирішити одну головну проблему ІТ — складність системи, яку неможливо пам’ятати цілком!
І виходу іншого немає: слона можна з’їсти лише по-шматочкам. З цього все і починається — потрібно вміти розрізати на шматочки: вичленувати абстракції, провести кордони, підібрати інтерфейси, зробити слабку зв’язність. Інкапсулювати (ізолювати, зробити приватною) реалізацію та не дозволяти її змінювати — лише розширювати (Open-Closed).
У різні часи це називалося по-різному: спочатку просто бібліотеки, потім COM-поненти, потім SОА, нагети, біни, зараз мікро-сервіси.
У моєму розумінні моноліт — це сильна зв’язність і втрата кордонів. Я досі пам’ятаю великі проекти, де в коді практично немає інтерфейсів (відповідно немає ні інжекшина, ні юніт тестів). І команда з подивом запитує, навіщо на клас ще й інтерфейс чіпляти?
Це і є проблема: багато девелоперів просто не вміють в абстракції, ізоляцію, інкапсуляцію. Вони пишуть величезні проекти так само, як свій курсач із
Тому так — завдання тех-ліда не лише стежити, а й зробити максимально складним збільшення зв’язності. Нехай навіть ціною фізичного поділу коду за різними репозиторіями.
Мене бувало справедливо звинувачували в овер-інженірингу. Але я знаю, що навіть якщо спочатку перестаратися і наладити надмірно-розподілену архітектуру, то за роки розробки вона все одно деградує. А от якщо розпочинати проект як моноліт — то тоді потім уже ніколи не буде грошей на покращення. Це закон ентерпрайзу: він може витрачати величезні гроші на нові фічі, що потiм мало використовуються, але «підлатати фундамент» бюджету ніколи немає.
Mykola Kharechko
Щодо різних бд... воно більше про відмовостійкість... якщо від джоінів відмовитись... то зявляється інтеркомунікація між сервісами... і маєм дистрибутед моноліт. Але можна просто потрібні штуки дублювати в стореджах різних сервісів.. і маєм повну незалежність і відсутність інтеркомунікації. Тоді воно всьо стає мейнтейнебл :)
Також інші штуки там про підтримку легасі апі і одночасного делойменту... то всьо через комунікацію між сервісами... тобто то той самий моноліт... просто модулі мають інтерфейс через мережу, а не через виклики фунцій. Відмова (зменшення) від комунікації ці проблеми вирішує. Ну буде собі там максимум 3сервіса комунікувати.. то в житті не проблема. Вони всі 3 по 200рядків... нема проблем задеплоїти. Консістент деплой трьох звязаних сервісів робимо так: трафік йде на старі... збоку підняди 3 нових.. як тільки вони всі задеплоїні, трафік на нах переключаєм
Щодо ленвіджагностік.... так в інтернетах пишуть. В житті там нема різних мов... бо завжди в сервісах є якийь коммон код... навіть ті самі клієнти для інших сервісів, трейсинг, налаштування логера і тд. І то напряжно коммон лібу підтримувати на різних мовах... то просто подвійна робота
Тут концепции другие получаются. Если у вас есть что-то, что shared — либо ложите в distributed cache и тягайте отовсюду, либо реплицируйте по сервисам.
А эффект сложных выборок в распределенных системах достигается с помощью CQRS имплементаций, где в принципе, у вас всегда будет eventual-consistent read model, вместо выборок.
Но это имплементации на случай если это действительно нужно. А это вообще совсем не всегда действительно нужно. Часто это усложнение очень серьезное простых вещей может быть.
Відео більше про дистрібутед моноліт. Мікросервіси це коли є один фасад (для клієнту), всередині по можливості повністю незалежні маленькі апки(які по можливості не комунікують)... мікросервіс.... він бізнесорієнтед, а не тех. 1мікросервіс на себе бере повністю один бізнескейс(одну пейджу в апці чи на сайті, якщо утрирувати... або одну секцію).
а що ти маєш на увазі під «бізнес-кейс»? Визначення з проджект менеджменту чи ще щось?
Яке відношення «пейджа в апці» має до бізнесу???
Скажімо, «бронювання квитка через інтернет» підпадає під твоє визначення бізнес-кейсу чи ні?
Mykola Kharechko
Скажімо, «бронювання квитка через інтернет» підпадає під твоє визначення бізнес-кейсу чи ні?
Можливо. А може і ні... залежить від того, чи можна подробити ту штуку(а чи можна подробити залежить від деталей технічної реалізації).
що ти маєш на увазі під «бізнес-кейс»? Визначення з проджект менеджменту чи ще щось?
Яке відношення «пейджа в апці» має до бізнесу???
Не знаю визначення насправді... чисто інтуітивно написав. Якщо переформулювати... то я мав на увазі, що якщо в апки є кілька фунццій.. то з мікросервісами відвалиться тільки якийсь кусок(скажем реєстрація), а от бронювання буде працювати.. або навпаки :)
Dmitriy Mozgovoy
Мікросервіси це коли є один фасад (для клієнту)
Та как бы фасадов=API gateway/BFF может быть куча. Просто чаще он один. Можно плодить кучу версий, разнести мобильных клиентов отдельно от веб и т.д, но все юзают одно облако микросервисов.
(які по можливості не комунікують)
Коммуницируют, но сугубо через брокер, но никак не напрямую.
Рахіт Срінавасович Кумар
Аудиторія з відео більша це раз, тексту на 14 хвилин відео всім впадло читати це два... Ото й експериментую тепер.
Рахіт Срінавасович Кумар
Мені простіше прочитати ніж відео дивитися
Мені теж, але ми у меншинстві
Włodzimierz Rożkow
Знімай тік-токи, бо відос на 14 хв це забагато для програміста зараз.
YG
не ясно, чи це так тонко, чи це так товсто)
з мого досвіду, мікросервіси це ще часто можливість зменшити бласт радіус. одна штука що у вас щось на бім стеці, типу ерлангу, де вся ізоляція, по суті, з коробки. інше — якийсь сішарп, де зробити блокінг чи меморі лік, який убаюкає весь моноліт — 1LOC.
ну і відслідкувати перфоманс деградацію в моноліті важко. додалось 10 фіч — чому просідає? що саме ефектить? випілювати\виключати ван бай ван? при окремих мікро-\сервісах — це тривіальніше, імхо.
про деплої — ну хз. чому там має постійно репати в мікросервісах? частіше ж логіка змінюється, ніж якісь інфаструктурні речі. один раз засетапив — і живи\радуйся)
+мікросервіс банально швидше девелопити, не так просідає IDE (менше коду) і час білд — а підвантажувати частину моноліту чи скіп білдів при каскадних залежностях це просто відтермінування проблеми.
енівей, дякую за відео. надіюсь, нове буде скоро:)
один раз засетапив — і живи\радуйся)
Ага, один раз в кубер вклав
Слухай, ну я розумію твої аргументи. Якщо порівняти один маленький сервіс з одним великим (монолітом) — то менеджити маленький простіше (і з точки зору перформансу, IDE, білду). Але треба порівнювати увесь мікросервісний двіж з одним монолітом і раптом баланс зовсім інший.
А про відслідковування перформансу в моноліті... хз, може я звик до гарного моніторінгу, але не відчуваю проблеми. Додалось 10 фіч, а де просідає? Якийсь конкретний урл, чи одразу все? Якщо урл, то треба глянути, шо там в тому місці змінилося, як все — то thread dump + профайлер і зазвичай шось цікаве знаходиться.
Авжеж, бувають складні випадки, типу як коли драйвер FoundationDB тормозив на першому запиті при оновленні з 8 на 11 JVM, але, здається, мікросервісність особливо тут нічого не порішає.
енівей, дякую за відео. надіюсь, нове буде скоро:)
Збираюся особливо не зволікати, але, на жаль, таких контроверсійних тем в загашнику поки що більше нема. :)
Roman Gordiienko
Схоже Ви не працювали с великими монолітами. Зазвичай десяток строчок коду ламає кілька непердбачуваних місць, і знайти чи віддебажити це — тиждень роботи скілової людини.
Ну завжди є питання масштабу, але саме з таким ми наново поруч новий написали.
знайти чи віддебажити це — тиждень роботи скілової людини.
А отдебажить кластер микросервисов с распределенными транзакциями, это типа легче? :) Хотя, существенную роль в обеих случаях будет играть насколько там хорошо интегрированы инструменты логирования и трассировки.
Ну тут очень неплохо бы энв с UI-тестами. чтобы каждую ночь отрабатывал. В целом знакомая ситуация.Без автоматизации разрабатывать такую махину просто нереально. Но это не значит что махину сразу же надо пилить на части. Проще тестами обмазать.
Ага, один раз в кубер вклав3-4 людино-роки, і норм жити...
Мля, я от недавно спробував в Terraform трохи вникнути (ну що там того терраформа, що я конфігів не бачив чи що) — ні, ну нафік, чим далі в ліс тим більше невідомого... хай цим девопси займаються, їм за це гроші платять )))
anonymous
Микросервис — самодостаточный но НЕ независимый кусок системы. Отличие SOA от микросервисов в том, что для SOA норма когда сервис решает автономно какую-то из задач и имеет свой фронт-енд, например. Микросервис же как пчела роя, сам по себе бесполезен.
Мое понимание*
Схоже, автор не бачив справжніх ентерпрайз монолітів. Якщо потрібно скалабіліті запустити кілька монолітів?! Ну це порада з розряду: чи не тягне одна база даних? Скопіюйте та запустіть 10 серверів баз банних!
Поміняти один рядок у моноліті? Два дні пошуків ДЕ поміняти, день спроб налаштувати і запустити локально ВЕСЬ моноліт і ще день щоб набити тестових даних і добратися до того місця, де треба перевірити.
Зоопарк мов? Так він по-любому буде на великому ентерпрайзі. Різниця щойно в моноліті цей весь зоопарк в одній купі і тобі треба знати все.
Відсутність централізованої бази = відсутність моноліту! 90% проблем перфомансу — це реляційна база!
Головна проблема мікросервісів: я розбив свій код на мікро-сервіси, але в голові у мене, як і раніше, моноліт, тому мені тепер потрібно пам’ятати в якому мікро-сервісі що міняти.
Головна проблема моноліту: після
Основна ідея будь-якої правильної архітектури: розбити систему на максимально незалежні шматки такого розміру, щоб навіть джун був здатний тримати в голові один шматок! А називати можна як завгодно: бібліотеки, компоненти, біни, пакети, SOA, мікросервіси тощо. Важливо, щоб кожну частину можна було розробляти НЕЗАЛЕЖНО.
Автор каже що з миркосервісами розробка СКЛАДНІШЕ?! Та просто тому, що він намагається запхати всі ці мікросервіси в одну голову! Тобто спочатку ми хотіли «з’їсти» слона, розрізавши його на шматочки і роздавши голодним. Але ось ми розрізали слона... а жерти все одно дали одній людині! Ну і тепер кажемо: а навіщо було витрачати час різати? Цілком би і жерли!
P.S. Перефразовуючи одного професора: моноліти вони не в коді — вони в голові!
Схоже, автор не бачив справжніх ентерпрайз монолітів.
Блін, ну мене шось нудить від цього підходу висловлювати свої думки. Добре шо хоч не зупинився на цьому, як якийсь чувачок в коментах на ютубі, але реально, чи потрібно було це писати?
Головна проблема моноліту: після2-х років розробки жодна людина не здатна втримати моноліт у голові цілком! І він починає перетворюватися на лабіринт!
Слухай, ну ні. Ну от зовсім, прям зовсім не так. По-перше, базово архітектуру можна тримати в голові, особливо якщо її не поганити (і ніхто ж не змушує поганити). По-друге, коли ти в стані «а я відповідаю за оцей мікросервіс і все», то точно так само ти можеш бути в стані «я відповідаю за цю частину моноліту».
Моноліт це не про те шо у всіх лапки з дупки, це про те, що спільна кодова база для всієї системи. Роби нормально і буде нормально. :))
моноліти вони не в коді — вони в голові!
Чомусь в тебе моноліт — це коли п****ць, а мікросервіси — це коли все добре. Може коментатор не бачив справжніх ентерпрайз мікросервісів? Коли ніхто нічого не розуміє, є купа застарілих недостовірних діаграм, і деякі з мікросервісів ніхто не знає як задеплоїти? Тому помилки не виправляються?
Ну да ладно, мені здається, що ми свій досвід не засинхронізуємо в коментарях, бо в нас прямо протилежні уявлення про одне й те саме. В мене є негативний досвід з монолітом, негативний з мікросервісами та позитивний з монолітом. А от позитивний з мікросервісами, де все працює і розвивається, мені видається трошечки негативним у сенсі що на плюс-мінус однаковому рівні інжинірінгу розробка з монолітом була б стабільніша та швидша. Розумію, що є інші кейси, але тоді треба конкретно деталі обговорювати. :)
Андрей Осипов
Розумію, що є інші кейси, але тоді треба конкретно деталі обговорювати. :)
Любой инший кейс — это когда нужно нужно scalability, когда спрашиваешь бизнес об этом — они всегда скажут, что решение должно скейлиться на раз-два, потому что рост будет ого-го, независимо от природы приложения, даже там, где по элементарным оценкам числа возможных пользователей и нагрузки на систему, этого не надо. Будет выбран самый дорогой способ ( на микросервисах).
Ничего, стагнация мировой экономики порешает, сейчас начнут искать подешевле и придут к обычным сервисам 20й давности, колесо почти провернулось .
Моноліт це не про те шо у всіх лапки з дупки, це про те, що спільна кодова база для всієї системи. Роби нормально і буде нормально. :))
Я не дарма написав про ентерпрайз. На невеликому проекті з постійною командою, адекватним менеджментом можна робити розумно і працюватиме хоч моноліт, хоч сервіси, хоч сервер-лес.
Але ентерпрайз — це мінімум 3 роки. За ці 3 роки початковий автор архітектури вже піде будувати інший проект, половина команди зміниться, прийде менеджер — «достигатор», який все хоче на вчора, частину проекту віддадуть на сапорт індусам дешевше...
За 20 років я бачив багато таких ентерпрайзів монолітів. У тому числі бачив як те, що ми почали розумно через 5 років перетворилося на звалище. Тому що мало хто хоче занурюватись в чужий код та чужу архітектуру! Менеджер поставив девелоперу завдання: показати тут ці дані з бази. І девелопер зробив: викликав базу безпосередньо та показав. Йому начхати на всі сервicи, репозиторії, 3 рівня бізнес-логіки.
Прийде техлід і скаже все переробляти, але часу на це як завжди немає. Бізнес-нід зроблено, менеджер скаже: потім зарефачимо. І все — потім цей підхід розповзеться по інших місцях і вся первісна архітектура піде лісом.
Саме тому мені найбільше подобається в мікросерсісах, що код ізольований! Набагато менше можливостей його заплутати. Та й розплутати потім простіше буде — бо є межі, які у старому моноліті давно зруйновані та стерті і будь-яка зміна може вилізти будь-де!
Менеджер поставив девелоперу завдання: показати тут ці дані з бази. І девелопер зробив: викликав базу безпосередньо та показав. Йому начхати на всі сервicи, репозиторії, 3 рівня бізнес-логіки.
Ну здрастє. А хто йому цей пр апрувнув? От хто апрувнув, а не відправив переробляти — той і винен.
Я таку ж фігню бачив в мікросервісній архітектурі — людина робить виклик до бази із сервісу, який з базою напряму працювати не повинен (тому що це, умовно кажучи, зовнішній сервіс, які працюють тільки з внутрішніми сервісами і тільки ті мають доступ до бази). Це зупиняється на рівні пулл-реквесту, кількахвилинної лекції про структуру проекту (якщо не знав/забув чи забив) і проханні переробити «як треба».
Це зупиняється на рівні пулл-реквесту, кількахвилинної лекції про структуру проекту (якщо не знав/забув чи забив) і проханні переробити «як треба».
Прийде техлід і скаже все переробляти, але часу на це як завжди немає. Бізнес-нід зроблено, менеджер скаже: потім зарефачимо. І все — потім цей підхід розповзеться по інших місцях і вся первісна архітектура піде лісом.
А з мікросервісами менеджера-козла нема, всі виключно мудрі люди. Тому хоча можливостей накосячити більше, та архітектура завжди в ідеалі.
Vsevolod Solovyov
Головна проблема моноліту: після2-х років розробки жодна людина не здатна втримати моноліт у голові цілком! І він починає перетворюватися на лабіринт!
Я свій моноліт вже шість років пиляю, ніяких лабирінтів немає.
Я свій моноліт вже шість років пиляю, ніяких лабирінтів немає.
Скільки людей у команді?
До десятка
Artem Duk
Ой вей, знову мікросервіси. Це ж вже старе як світ, всі срачі вже в минулому =)
Зараз тренд це FaaS та актор бейсд системи. Ну і event sourcing, куди ж без нього, хоча він теж вже застарів ))
Пр темі так, monolit first approach виглядає більш привабливим для початку, особливо якщо це стартап, тому ще це банально простіше менеджити. Але моноліт має бути модульним щоб уникнути tight coupling і мати можливість виділяти якісь частини системи в окремі сервіси в майбутньому.
Але з великою вірогідністю модульність моноліта буде похєрєна якщо в проекті нема лідів або архітектів які за цим слідкуватимуть(а це більшість проектів).
Тому типічна доля моноліта який став успішним та розрісся — або підвищення складності внесення змін до точки коли будьяка зміна стає неможливою без появи критичних дефектів, або інвестиції в рефакторінг з метою спрощення залежностей, а це або модулі або мікросервіси або ще якийсь паттерн, який дозволить розділити систему на більш меньш незалежні підсистеми.
З іншого боку якщо на старті відомо що система планується велика — може і краще стартувати з мікросервісів, бо мікросервіси важче похєрити ніж похерити модульність в моноліті.
Ой вей, знову мікросервіси. Це ж вже старе як світ, всі срачі вже в минулому =)
Та шось останній час на мене зі всіх сторон лізуть вони. 😁
Принципово згоден зі всім окрім цього:
мікросервіси важче похєрити ніж похерити модульність в моноліті.
З оцим не згоден. :) Коли в команді немає людини з достатнім рівнем впевненості і знань, щоб втримати модульність/архітектуру, спагетті-мікросервіси на вихлопі дадуть ще гіршу систему, ніж заплутаний моноліт. Бо вона така сама із соплей, тільки ще й розподілена. :)
Artem Duk
От в цьому питання мушу виявити принципову незгоду! Згідно з моїм досвідом багато маленьких купок гівна значно краще ніж одна велика купа гівна ))
Тобто якщо система на початках була нормально спроектована а потім вже попливла по течії — мікросервіси похєряться не так сильно як моноліт і проблеми, які виникнуть, буде легше виправити =)
Згідно з моїм досвідом багато маленьких купок гівна значно краще ніж одна велика купа гівна ))
Якщо код лежить в одному репозиторії — ОБОВ’ЯЗКОВО хтось підключить його як залежність у неправильне місце! Був приватним — зроблять публічним, скопіюють нарешті.
Головний плюс мікро-сервісів: їх код живе та розробляється окремо! І тому якщо раптом мікро-сервіс не розростеться до макро-сервісу, то ймовірність його перетворення в спагетті-смітник (як моноліт) набагато нижча.
А навіть якщо перетвориться — це буде маленький спанетті смітник, або принайні меньший спагетті смітник ніж моноліт )
А прибрати декілька меньших смітників легше ніж один великий )
Чому окремо?! Це одна система! Увесь сенс мікросервісів в тому, що кожен окремо мікросервіс — він не самостійний, це частина системи. І коли вся система перетворилася в хлам (а з мікросервісами зазвичай вона ще й починається з хламу), то навіть якщо ти перетвориш на квіточку свій малесенький сервіс, вся система так і залишається заплутаним клубком.
Про це і намагаюся донести: мікросервіси це дивитися ширше ніж просто «та сама система, але зі шматочків».
Наприклад подивіться на хмарні послуги. Зараз можна зробити сервер-лес додаток просто використовуючи окремі хмарні сервіси. При цьому кожен сервіс виконує свою функцію і має цінність сам по собі і для багатьох систем, а не як частина однієї.
Намагатимуся придумати приклад простіше. У вас є сайт-магазин. У вас є сервіс, який сайт смикає щоб отримати товари з бази. Це все одна система: користувачі бачать лише сайт.
Але якщо ви виставите сервіс з товарами в публічний доступ — у вас уже це незалежні системи: є користувачі сервісу і є ваш сайт те саме як користувач цього сервісу.
Чим це добре? Ось наприклад, ви хочете зберігати в базі кількість переглядів товару на сайті. А розробники сервісу кажуть: ця інформація не потрібна нашому сервісу — у нас немає сайту!
І що? Вони ж мають рацію! Замість все пхати в одну базу вам доведеться зберігати інформацію, що безпосередньо не відноситься до продукту — окремо. А в моноліті не замислюючись, додали б поле, прокинули — і все. І так щоразу — через рік уже 100 500 полей.
Ну і в результаті задача на 4 години стає задачею на тиждень бо всім треба синхронізуватися і дочекатися поки хтось в мікросервіс аналітики шось додасть шоб можна було зберігати додаткову інфу про ще шось і так далі.
Коли терміни не хвилють і ми робимо архітектуру заради архітектури — тоді питань нема. А коли швидкість імплементації визначає чи буде компанія жити через 3 місяці — тоді розмова інша.
А коли в моноліті хтось сре в базу нонстоп і не думає — то тут я не розумію, чому альтернативою слугує кейс, коли в мікросервісах хтось шось думає? Чому не так само сруть у всі протоколи і таке інше? Техліда так само той менеджер нахер шле ж?
Коли терміни не хвилють і ми робимо архітектуру заради архітектури — тоді питань нема. А коли швидкість імплементації визначає чи буде компанія жити через 3 місяці — тоді розмова інша.
Проблема в тому, що більшість проектів, яким вже 5+ років починалися саме з того, що клієнт хоче швидко за 3 місяці. І, очікувано, галера ліпить йому моноліт із гівна та палиць. І перші роки все йде нормально: безперервний багфікс, додавання нових фіч. Але через 5 років приходить до того, що додавання будь-якої нової фічі гарантовано ламає щось інше. 90% бюджету витрачається на багфікс, а додати маленьку фічу займає місяці. На такий проект думаючого девелопера не заманити — тому всі питання команда джунів вирішує милицями.
Тут би логічно було зробити нову версію з новими фічами... ось тільки грошей на це у клієнта вже немає — все зжерла підтримка «мертвого коня».
На мій досвід все зазвичай закінчується продажем компанії-клієнта і новий господар викидає старий, збитковий моноліт і переводить клієнтів на свою нову систему.
У принципі, це бізнес — і немає нічого поганого. Крім одного: це означає, що всю роботу, яку я так старанно роблю через 5 років викинуть на смітник!
Адже хотілося б робити щось, про що можна було сказати, що воно працює «як швейцарський годинник» вже багато років і приносить людям користь. Хочеться будувати на віки, а не просто пилити бабло на «Сочинських сортирах».
Actor based вже ж давненько, старіші за мікросервіси. Останні кілька років я не бачив взагалі нових парадигм, які б використовувались в реальних проектах
Ну хз, може за actor based заговорили активніше, але бачу багато згадок про них останній час.
Стосовно нових парадигм — воно дуже боляче їх впроваджувати, бо там ще не набиті всі шишки, а ми і зі старими ще не впорались ))
Тому в цьому плані якоїсь революції не очікую.
Bot Bot
Зачейкайте ще пару трійку років і нові погромізди котрі писали одразу мікросервіси, вигадають моноліт. Це як усі почали писати СПА на ангулярі, а потім «вигадали» сервер рендерінг :-)
Нове — то забуте старе ))
Якщо це стартап то по іншому і не треба. Спочатку виявляємо чи цей піс оф щіт комусь потрібен а потім вже наводимо красу(або ні) =)
Actor-based, требуют специфичных навыков и понимания. Но я не вижу смысла делать на акторах все. Это же для перфоманса и реалтайма.Event Sourcing тоже специфичное средство, не везде оно нужно. А нужно довольно редко.
Але з великою вірогідністю модульність моноліта буде похєрєна якщо в проекті нема лідів або архітектів які за цим слідкуватимуть(а це більшість проектів).
😂😂😂 То есть ты хочешь сказать, что создать модульную систему тяжелей грамотно, чем задизайнить actor-based кластер ???
То есть ты хочешь сказать, что создать модульную систему тяжелей грамотно, чем задизайнить actor-based кластер ???
Я десь порівнював складність дизайну різних підходів у своєму дописі???
ну говоришь что Акторы тренд но не надо монолит
вот я сделал вывод
ну говоришь что Акторы тренд но не надо монолит
вот я сделал вывод
Я за актори казав що це зараз більш трендова тема ніж мікросервіси, яким вже 100500 років. А далі дискусія йшла моноліт вс мікросервіси, ніхто актори в це порівняння не вписував.
:O Да ладно ? Я один раз только на хай-лоаде работал с акторами, довольно редко видел , в том числе в опен сорсе.
:O Да ладно ? Я один раз только на хай-лоаде работал с акторами, довольно редко видел , в том числе в опен сорсе.
Я їх взагалі в проді ніколи не бачив, але останнім часом чомусь багато відосиків про них зустрічав, хз може це в моїй бульбашці вони в тренді ))
Найкращі коментарі пропустити