Головна проблема мікросервісів, яку часто недооцінюють

Мікросервіси чи моноліт? Я бачив не одну команду, яка намагалася побудувати мікросервісну архітектуру, але провалила це. В відео я ділюся головною проблемою мікросервісів, яку часто недооцінюють
Посилання до відео:
* Доповідь Роберта Мартіна про архітектуру - • The Principles of Clea...
* Як Medium переїзджав на мікросервіси - medium.engineering/microservi...
Станьте спонсором цього каналу: / @aboutprogramming
Допоможіть каналу розвиватися й отримуйте доступ до ексклюзивного контенту.
Зміст відео:
0:00 - Вступ
🏠 Мої соцмережі:
Жабаскрипт в телеграмі - t.me/jabascript
Я в Твітер - / viktorturskyi
Мій Linkedin - / turskyi
#programming #javascript #програмування #українською #microservices #monolith

[@sergiig9336]

Гарно проговорені основні складнощі мікросервісів, дякую за чудове відео.

[@kogaro8762]

Хотілося б почути про роботу з таймзонами і найпоширеніші підходи при роботі з ними

[@user-bj6wn6bl2l]

ніяк з ними працювати не треба) Взагалі де тельки можна зберігай їх як цілочислені UTC тіки. А лише при відображенні (або фактичному використанні) форматуй під таймзону. нічого кращого не придумаєш)

[@vkucherenko]

Корисний відос. Шкода, що багато розробників женуться за резюме-дрівен девелопментом і роблять все microservice-first.

[@dimitro.cardellini]

Люблю то висловлювання Роберта Мартіна ;) У нас є простий аналог: "не можна за собою спалювати мости". Тобто рішення прийняте сьогодне, має якомога меньше обмежувати свободу рішень у майбутньому. Просто рішення приймати все одно доводиться тут і зараз -- бо рухатися ж треба ;)

[@TheCAJLO]

крутий контент. Дякую.

[@PhotographerRoman]

Дякую за лаконічне відео

[@user-bj6wn6bl2l]

"якість архітектури залежить від якості розуміння предметної області" -абсолютно золоті слова! з досвіду, якшо на проекті окремий бізнес аналітик,та окремий архітектор - то проект можна і не починати та не витрачати гроші... нажаль архітектор ЗОБОВ'ЯЗАНИЙ бути крутим бізнес-аналітиком сам по собі. А потім взяти окрему людину на цю посаду, просто заради делегування документації проджект артифактів.

[@user-bj6wn6bl2l]

Не можна просто взяти, та прийняти рішення пізныше) Для того шоб прийняти рішення пізніше, треба мати передумови для того рішення, які повинні бути закладені заздалегідь (на початку). Не можна розробляти квадратну коробку, а потім прикрутити туди пропеллер! Бо тобі ще знадобиться купа вільного місця для двигуна, кабіни, паливної системи, тощо. І якщо ти не в змозі то всьо продумати на старті та правильно закласти в дизайн... То ти ні мікросервісну, ні монолітну, ні гексагональну, ні філософськокаменеву архітектуру не побудуєш. Мікросервіс-first - спокійно будується. я це особисто робив багато разів, роблю і буду робити)

[@AboutProgramming]

Якщо перефразувати ідею Роберта Мартіна, то задача така, щоб будувати архітектуру так, щоб не блокувати зміни в майбутньому. Тобто зараз ми не приймаємо рішення про конкретний двигун, але залишаємо місце під нього й в майбутньому, коли знатимемо вимоги краще, то вже поставимо двигун. Звісно щоб не зав'язатися зараз на щось конкретне, то доведеться подумати, як це зробити більш абстрактним (або проектувати абстракції так, щоб можна було при необхідності змінити реалізацію). Й Роберт Мартін якраз про це каже, що задача архітектора не в тому, щоб зараз вирішити, що в найкраще, але не можна поміняти, а те щоб будувати систему так, щоб мати можливість прийняти рішення пізніше. Це може стосуватися багатьох рішень. Наприклад чи робити певне API публічними чи ні? Якщо зробити зайве публічним, то потім складно змінити. У мене були випадки у житті, коли команда вирішила, що має по особливому дуже гнучко працювати система конфігів, а потім коли прийшли реальні вимоги, то виявилося, що ці гнучкі конфігі не дозволяли додати реально потрібну поведінку бо було занадто рано прийнято рішення про специфічну їх реалізацію. Були й гарні приклади, коли команду попросив зарання не мати залежності на веб-сокети по коду для комунікації мікросервісів й через пару місяців проект переїхав на MQTT комунікацію. Були приклади з переїздом з клауда в клауд й коли не маєш достатньо вхідних даних, то краще не зав'язуватися на дуже специфічні технології, а вілкадати це рішення поки точно не стане зрозуміло, в якому клауді житиме продукт. Й такого багато. Тобто, так, не можна взяти й прийняти рішення пізніше, для цього треба подумати зараз й дуже добре подумати про те, яким шляхом може піти продукт завтра й будувати архітектуру так, щоб не закрити для себе ці потенційні шляхи розвитку продукту (й чим більше шляхів відкрито й вибір залишено на потім, тим краще)

[@user-bj6wn6bl2l]

@@AboutProgramming абсолютно згоден) Найбільша проблема білшості девелоперів - саме сприймати задачу буквально, та недостатня рефлексія)

[@user-ix6og2ev1i]

Дякую

[@igor-6930]

Погоджуюсь зі всіма пунктами. Організація повинна бути готова до використання мікросервісної архітектури.

[@serhiibaranovskyi9131]

Було б цікаво почути ваше бачення як працю механізм автентифікації/авторизації зі сторони бекенду

[@AdminAdmin-sl2qf]

❤❤❤❤❤❤❤❤

[@sunseeker_ua]

Було б гарно почути про етапи виводу функціональності з моноліту в мікросервіс.

[@AndrewMatasov]

модульність.

[@artemtrush]

Пишіть, про що цікаво почути: ти згадав про рефакторинг, можна про рефакторинг) Рекомендації, чи навпаки шкідливі підходи. Рефакторинг на ходу, та окремими задачами.

[@user-lc7cz2ks6i]

👍👍👍👍

[@drewpolt5716]

цитата про неприйняті рішення прямо топ, особливо коли міддл в ревʼю його PR тебе майже переконав(ла): "та нашо ця абстракція, най буде так"

[@bohdan4677]

Можна робити макросервіси або мікромоноліти

[@user-se1mr9qs3y]

Переїджати з моноліту неймовірно складно, якщо є нагальна бізнес потреба в розробці нових фічей, а вона скоріш за все є.

[@AboutProgramming]

Так, будь-яка міграція складна й ризикова. Навіть просто великий рефакторинг моноліту. А потреба в фічах є завжди

[@pavlopotapenko2686]

було б цікаво розібратись більш детально про мікросервіси, може з прикладами, в яких випадках краще підходять, в яких ні і тп...

[@RomanApostol]

Ох скільки ми інтерв'ювили сіньйорів, які казали "мікросервіси тому що це стільно-модно-молодьожно" але не розуміли що вони їм не потрібні. Дякую за відео!

[@AboutProgramming]

Колись я робив доповідь на конфі й до мене підходить слухач після доповіді й питає: Слухач: Як переконати керівництво, що треба переїхати на мікросервіси? Я: А яку проблему ти хочеш вирішити? Слухач: Ні, зараз все працює нормально, але хочу в резюме досвід роботи з мікросервісами Такий собі Resume Driven Development - коли тягнеш технології в проект, щоб додати це в резюме :)

[@mykolagrynkiv7793]

Ну так, получається завжди треба задавати собі питання, щоб що? 😂

[@DemiGoodUA]

@@AboutProgramming иногда встречаю вакансии популярный язык(джава, нода) + го, раст, эрланг и тд. Когда узнаешь подробней оказывается что решили написать новый сервис модно молодежно, получилось плохо, человек который писал ушел а поддерживать надо)

[@ArchonLicht]

Якщо моноліт модульний, і кожен модуль звичайно ж пише окрема команда (бо розробку то треба розпаралелити щоб швидше заделіверати - time to market поважливіше буде за якісь абстрактні клінкоди) - то виходить приблизно те саме, такі ж проблеми при інтеграції модулів в моноліті, як і мікросервісів у загальній архітектурі рішення.

[@AboutProgramming]

Чому? Ніби багато проблем не буде існувати: 1. Буде виклик методів іншого модуля, а не RPC до інших мікросервісів. Й немає обробки ситуацій, коли інший сервіс лежить 2. Немає проблем з сумісністю версій мікросервісів між собою. 3. Менше проблем з інфраструктурою й деплойментом. 4. Немає проблем сервіс діскавері 5. Легше підтримка транзакцій 6. Легше рефакторинг Якщо я правильно зрозумів питання

[@v.ilchenko]

Ох я люблю оцей підхід «зараз мікросервіси зробимо і все буде добре» 😂 а добре не стає 🌚 Доречі, та ж лямбда на aws - це вже щось вроді мікросервіса. Ми такий підхід використовуємо для незалежних асинхронних задач: - перевірити код студента - синхронізувати базу з CRM - відправити нотіфікашку - пошукати вакансії etc Це добре працює і не треба плодити джоби в моноліті і переживати чи вони робляться Але виносити якусь аутентифікацію окремо поки не бачу сенсу Про відкладені рішення дядько Боб навіть в своїй «чистій архітектурі» пише і це було дуже неочевидно для мене в перший раз

[@AboutProgramming]

Так, часто треба просто пару воркерів для асинхроних задач) У мене був слайд з описом, як зазвичай виглядає моноліт, але не показав його на відео - на ньому бекенд й набір воркерів для асинхроних задач (відправка пошти, генерація звітів й тд) й набір періодичних задач (щось перегенерувати, перевірити баланси й тд). Цього часто вистачає. Відносно AWS Lambda, то в них можна запускати й асинхроні задачі, але в лямбду можна запихнути й основний бекенд. Тобто AWS Lambda не стільки мікросервіс, скільки serverless середовище для запуску програми. А от воркер це вже те, що схоже на мікросервіс (незалежно, де він запускається). Але повністю згоден, що AWS Lambda це те, що добре підходить для асинхроних задач

[@user-bj6wn6bl2l]

"та ж лямбда на aws - це вже щось вроді мікросервіса." - та точно! Схожа як свиня на коня, тільки грива не така =)

[@sunseeker_ua]

Ще десь в 2007 році викатував рішення з розподіленими транзакціями на базі MSDTC + Mssql, працювало як годинник. Тоді за мікросервіси ніхто ще і не думав говорити 😃

[@AboutProgramming]

Ох, ти небезпечний 😄 Так, були часи)) Я пам'ятаю, як в 2007 писали свою файлову систему через fuse й систему деплойменту з іміджамі, скейлінгом, балансерами й тд й все без клаудів й докера - вставляєш порожній сервер в стойку, а далі все автоматом підхоплюється 🙈 А відносно транзакцій в мікросервісах, то так, можна додати координатор, який контролюватиме 2 phase commit, але треба дуже зважувати за й проти перед тим як імплементувати таке рішення. Частіше все вирішується івентами й готовністю жити з evental consistency

[@sunseeker_ua]

@@AboutProgramming eventual consistency теж цікавий топік. За декілька років геймдеву я вже підзабув як це писати систему що зберігає консистентні дані. У цьому випадку якщо 97% користувачів будуть консистентні то й добре, зато все швидко працює 😅, дуже незвично було так працювати перший час після фінансової сфери, де кожна доля копійки має бути збережена.

[@AboutProgramming]

@@sunseeker_ua якраз гарний приклад того, як в архітектура залежить від предметної області 🙂

[@user-fd3ot7rq4v]

Архитектура это концепция, платформа для возможностей инвариативности решений

[@angrygingerbread1077]

Вітання! Підскажіть, будь-ласка, чи є сенс тестувати всю мікросервісну систему вцілому? Допустимо покривати тими же е2е тестами. Чи є інші підходи, які гарантують надійність її роботи?

[@AboutProgramming]

E2e тести зазвичай потрібні, але вони повільні, постійно ломаються й їх складно дебажити, але вони працюють. Тобто e2e тести потрібні, але їх можна комбінувати з інтеграційними, які тестують інтеграцію не e2e, а лише різних підсистем між собою. Також є підхід consumer driven contract testing й різні механізми на базі статичного аналізу для забезпечення контракту між підсистема

[@zencrazycat]

Можна використовувати такий компроміс - проганяти е2е тести лише на фінальній стадії релізу. Умовно, після мержу з dev в stage, перед мержем в main, ну чи в залежності від того, як у вас побудований ci/cd процес. Це вирішує проблеми коштовності і тривалості, і при цьому зазвичай не спповільнює реліз, бо якщо юніт і інтеграційні тести пройшли, то е2е доволі рідко падають. Принаймні, з мого досвіду воно так.

[@cdelano_ua]

Цікавий відос! Прошу, якщо буде можливість більше розповідати про архітектуру сучасних додатків. Дякую!

[@AboutProgramming]

Планую багато відео на цю тему

[@ArchonLicht]

Бомж Вася біля смітників - ідеальний архітектор. Ще жодного рішення по архітектурі не прийняв! :D

[@AboutProgramming]

А завдяки цьому програма працює й розвивається, то можна наймати)

[@zencrazycat]

А скільки він відхилив?) Суть то саме в цьому.

[@user-ju1kr2ow4c]

Віктор, цікаво як ти поєднуєш ІТ і звукозапис чи продакшн? Бо бачу на фоні студійний сетап )

[@AboutProgramming]

Це хромакей)

[@user-ju1kr2ow4c]

@@AboutProgramming тоді ясно. Спеціально такий обирав?

[@AboutProgramming]

@@user-ju1kr2ow4cтак, шукав варіант, щоб був більше схожий на студію

[@pavloburyanov5842]

Як сіль на рану

[@pavel7930]

Скільки людей, стільки думок!....

[@artemzabolotnyi3838]

Якщо на самому початку правильно засетапити моноліт, його потім дуже легко порізати на окремі програми. Прикладом цьому є монорепи.

[@AboutProgramming]

Не зовсім розумію, чому це є прикладом. Наскільки розумую, то монорепа зазвичай це, коли ми всі проекти/підсистеми в одну репу, замість окремих репозиторіїв для кожної. У Гугла, наприклад, монорепа, але це ж не як не повʼязано з тим чи моноліт, чи мікросервіси на проекті

[@artemzabolotnyi3838]

@@AboutProgramming Ну тіпа спочатку це один маленький монолітний проект над яким працює одна тіма. Кожен робить свій модуль. Модуль може бути все ще просто папка в репі зі своїм маніфестом, або навіть без. Потім, нп., бачимо що треба скалірувати, що модуль можна заранити, як окрему прогу, до нього пишеться міст. Щоб не перенавантажувати кількістю гілок і комітів, виносимо модуль і його міст) в інші репи, міст підрубаємо субмодулем. Та й юзаєм. Єдине шо, дрочь з тими ревью різних реп. З плюсів: тіма, яка юзає підлеглий модуль зразу отримує готовий клієнт з доками. А? девопс? Лінива срака най шось тоже робить за🤡бав. Сидить, поробив ті баші, создає відімость роботи 🫠

[@AboutProgramming]

@@artemzabolotnyi3838 зрозумів думку :) Згадав приклад, коли у нас був проект, коли монолітна програма має багато модулів (плагінів) й у кожного модуля своя репа. Й може бути навпаки, щоб щось ранити, як окрему прогу, то можна й не виносити в окрему репу (як в тому самому Гуглі). Але в цілому так, якщо у чогось є структура, то його легше ділити на шматки (й велику репу, й великий моноліт)

[@maksymtsiupko3692]

Проєкти бувають різні і сфери де вони застосовуються. Проблема в тому, що люди намагаються впхати щось куди не слід. Що моноліт, що мікросервіси це дуже гарні інструменти лише при правильному використанні. Це можна порівняти з авто, всім подобаються спортивні авто/великі рамні позашляховики, але їх задачі на 90%+ закриває пасат в універсалі (моноліт). Я теж люблю мікросервіси і написав їх багато, але усі вони були жорсткою необхідністю

[@AboutProgramming]

Гарна аналогія з авто

[@ukrainian333]

Мажики на Геліках і Крузерах які ганяють по асфальту не дуже з тобою погодяться =))) Мікросервіси рулять!!!! ХАХАХХА (сарказм)

[@maksymtsiupko3692]

@@ukrainian333 мікросервіси крутяться, лаве мутяться))

[@user-oi9yf8ve3i]

Моноліт чудово працює як 1 апп І так само чудово падає разом з усім функціоналом який в нього запхали :)

[@AboutProgramming]

Але й моніторинг моноліту зазвичай сильно простіше ніж у випадку з мікросервісами

[@user-oi9yf8ve3i]

Ну я маю на увазі, що якщо у тебе велика система, банківська наприклад І якщо в тебе якась біда в реєстрації наприклад,а улыбнитесь не можуть родили платежи через це, перше про що попросить бізнес - це зробити незалежність А цього неможливо досягти без мікросервісів Моноліт це прикольно поки твій проект невеликий Ще один приклад - ресурси Багато маленьких аппів простіше забезпечити ресурсами ніж 1 великий Хоч і дорожче Але потреба мікросервісів зʼявляється в першу чергу з боку бізнесу а не розробників, бо бізнес платить людям гроші )

[@AboutProgramming]

@@user-oi9yf8ve3i Гарний коментар, дякую. Пару думок з цього приводу. Так, разні апи в один апп немає сенсу паковати, але нормально мати багато монолітів замість дуже дуже багато мікросервісів. Тобто, припустимо, що пишу інтернет магазин й це один моноліт й тут треба ще менеджемент товарів, то має сенс стоврити окриму PIM (product information management) систему. Потім треба суппорт клієнтів й я створюю систему для суппорту. Потім треба CRM, облій й тд й це все окремі системи. Й це далеко не банк, в банку цих систем може бути на порядок більше. Але це не значить, що у мене був інтернет магазин моноліт, а коли я поряд поставив PIM й CRM, то це раптом стало мікросервісами. Це так само моноліти, просто при їх з часом стає більше й більше. Окрім того класичний моноліт це основний бекенд й набір воркерів для відправки пошти, генерації звітів й тд. Дуже багато платіжних систем є такими монолітами. Відносно ресурсів, то тут цікаво. Якщо ми говоримо саме про мікросервіси, то мікросервіси завжди менш ефективні ніж моноліт за рахунок більш дорогої комунікації. Але якщо ми говоримо про окремі повноцінні апи (коли один апп може повністю обробити запит клієнта й повернути результат), то це вже інша історія. Відносно потреби в мікросервісах з точки зору бізнесу - згоден на 100%. Мікросервіси мають бути рішенням якоїсь конкретної проблеми й найчастіше це не про масштабування в проді, а про незалежний деплоймент різних частин. Бо коли моноліт стає великим й працює багато команд над ним, то релізити складніше, тести довго проходять, пайплайни падають й реліз доводиться відкладати, щось не так й ролбек всієї системи.

[@user-zg3vt6zh6y]

пишіть моноліт, а там по ходу розберетесь 😄

[@LyubomyrSemkiv]

Щоб архітектура вдалася, краще всього зробити якийсь ПОК який вирішує задачу в максимально неприйнятній для продакшена формі, щоб не було шкода викидати. Друга версія продукту в хороших програмістів виходить сильно краща за першу тож варто зразу планувати дві.

[@AboutProgramming]

Краще робити в прийнятній формі, тоді хоч є користь від розуміння, що там було не так. А якщо й так відразу зрозуміло, що форма максимально неприйнятна, то нової інформації це особливо не дасть 🙂

[@LyubomyrSemkiv]

@@AboutProgramming основна цінність цього кроку -- зрозуміти вимоги. Я люблю це робити в одному файлі взагалі без ніякого дизайну. Це відкриває можливість потім задизайнити знизу вверх.

[@LyubomyrSemkiv]

@@AboutProgramming це десь відповідає "Make it work" з XP, що дозволяє потім зробити Make it Right.

[@AboutProgramming]

@@LyubomyrSemkiv так, згоден. У мене POC часто як один з кроків проектування. Тобто воно не уходить в продакшен (але часом й таке буває), але це вже робоча реалізація для перевірки гіпотез

[@caffeinejavacode1475]

Не зрозумів фразу що у вас не буде транзакцій які працюють на декілька мікросервісів. Чому не буде?

[@AboutProgramming]

В більшості випадків це проблема, оскільки стандартний підхід це власна база для кожного мікросервісу. Й тут або two phase commit (який вимагає координатора), або saga pattern (де ми маємо eventual consistency). В результаті часто просто забивають на розподілені транзакції. Тобто в теорії це можливо, але на практиці реалізовують рідко (особливо, якщо різні типи бази в різних сервісах)

[@caffeinejavacode1475]

@@AboutProgramming Чи мождиво замість розподілений транзакція, використовувати Event Carier State Trasfer, якось тягати весь стейт головного об'єкту по всім сервісам?

[@AboutProgramming]

Не розумію, як це вирішує проблему атомарності апдейтів. Так ми можемо використати saga pattern й чи у нас state transfer, чи івенти без додаткового стейту - не особливо змінює ситуацію. Й часто так й роблять, але це не гарантує нам strong consistency. Але з практичної точки зору часто цього достатньо, але не завжди. Ну й треба додаткові зусилля на реалізацію ролбеків й тд

[@mr.hornet6003]

Великий недолік моноліту, це те що в почавши його 10 років назад, в актуальний час він уже може бути не на модному стеку. А переписувати усе на щось новіше грошей і часу нема. Тому сам себе лочиш на той стек, який вибрав дуже давно. Відповідно і розробників буде важче найти які захочуть кодити на цьому. А в мікросервісах, я бачу проблему, навіть якщо це не пов'язані аплікейшни, то якщо не контролювати їх популяцію, можуть розростися на десятки окремих бекенд сервісів, і відповідно купу енваірментів. Це все підтримувати, або робити якісь масові оновлення, тяжко, особливо якщо команда не велика.

[@AboutProgramming]

Часто стек для всіх мікросервісів обирають один й потім є теж ризик застарівання стеку. Але так, моноліт складніше мігрувати на новий стек, ніж мікросервіси

[@AndriiShumada]

Тут питання саме по собі намальовується - як прийняти рішення про відокремлення сервісу від моноліту

[@AboutProgramming]

Зазвичай мікросервіси це рішення якоїсь проблеми. Й треба зрозуміти, яку проблему ми вирішуємо й чи є ще інші варіанти вирішення цієї проблеми й чи буде відокремлення мікросервісу найкращим рішенням (враховуючи бізнесові наслідки)

[@ukrainian333]

Якщо у вас ще немає проблеми, яку б вирішили мікросервіси - значить вам вони поки що не потрібні. Всі інші випадки - погоня за хайпом, або погане розуміння призначення мікросервісів, і вся купа проблем пов'язаних з цим.

[@DemiGoodUA]

Мне кажется микросервисы идут к тому что бы перелаживать сложность с программиста на архитектора. Чем больше кодовая база тем сложнее в нее писать код. А микросервисы позволяют делать много маленьких приложений, с которыми справиться не сложно, а решения на их создание, комуникацию и тд перенести на архетектора. Получается вместо 20 хороших девов, хватит 20-30 средних, что намного стабильней

[@AboutProgramming]

Тобто від архітектура вимагається вирішити всі проблеми міжсервісних комунікацій, щоб комунікація була абстрагована від розробників й все виглядало ніби вони пишуть модуль в моноліті й просто викликають функції іншого модуля? Якщо все має виглядати для розробників, як моноліт, то в модульному моноліті це й вирішувати не треба. Але звісно його треба спроектувати модульним й той самий архітектор потрібен теж

[@DemiGoodUA]

@@AboutProgramming Тут вопрос насколько реальность позволит сделать модульный монолит. Большинство проектов вырастают с маленьких в большие. Для стартапа ревьюить каждую строчку, что бы модульность не сломали, нереально. А потом легче переехать на микросервисы чем рефакторить весь проект

[@AboutProgramming]

@@DemiGoodUA В момент, коли буде прийматися рішення про переїзд на мікросервіси буде вже більше інформації, оскільки передбачається, що до цього вже був робочий проект й вимогі будуть краще зрозумілі. Й коли вже краще зрозумілі вимоги, бізнес-логіка, потенційни проблеми, то спланувати наступну архітектуру простіше. Й тут вже треба просто обирати архітектуру, яка вирішуватиме ті, проблеми, які зараз не дають проекту розвиватися. Ну й одночасно треба розуміти, які інші проблеми принесе нова архітектура. Й тут може бути й просто рефакторинг, можуть бути мікросервіси, може бути щось гібридне й тд. Й в ситуаціях, коли мікросервіси вирішують основні проблеми проекта, то переїзд на них може бути правильним рішенням

[@Alexex2353]

Так яка головна проблема?)

[@AboutProgramming]

Вже було десь в коментах)

[@frostmaind]

Не обязательно все должно быть монолит или микросервис. Часто в микросервисы выносят модули которым нужен HPA.

[@AboutProgramming]

Що таке HPA?

[@frostmaind]

@@AboutProgramming Horizontal Pod Autoscaler

[@AboutProgramming]

@@frostmaind спочатку подумав про нього, але не зрозуміло чому саме HPA. Але так, часто можна винести лише окремі частини в мікросервіси по мірі необхідності

[@frostmaind]

@@AboutProgramming просто привычка работы с k8s. Касается любого горизонтального масштабирования. С монолитом всегда есть потолок в плане мощностей.

[@mykolagrynkiv7793]

Ну так, але треба розуміти що база всерівно одна, і вузьке місце буде там, а як не там, то в розприділених транзакціях 😂

[@kamurashev]

Я бы еще упомянул одну важную вещь микросервисы в 99% случаях будут медленнее монолита. Скорее всего, в большинстве случаев, это не будет критично но это неоспоримый факт. Потому что нетворк лейтенси. Я за модульный монолит. Я в свое время перевозил один относительно хайлоад апликейшин из датацентра в авс. Вот тогда то я и узнал главное зло клаудов.

[@AboutProgramming]

Так, гарне доповненя. Нетворк лейтенсі додає лейтенсі в час обробки, але ще є затрати на серіалізацію й десеріалізацію запиту. Навіть, якщо в рамках однієї машини поміряти, то виклик просто функції в пам'яті й виклик функції через rest/rpc - це буде зовсім різний перформанс

[@dimashtef7077]

Наспупний відос про плюси мікросервісів? :)

[@AboutProgramming]

Скоріше про недоліки моноліту))

[@rostik18]

Ех, стільки болі в цьому відео...

[@codihuntsinger3698]

З усією повагою, так і не почув поінтів чому і коли мікросервіси це погано. Тільки вирвані цитати прихильників монолітної архітектури.

[@AboutProgramming]

Мікросервіси це не погано, скоріше ризиково й дорого. Й про ці ризики відео. Й питання про те, коли мікросервіси себе виправдовують? Щоб зрозуміти це, треба чітко відповісти на питання, яку проблему ми хочемо вирішити мікросервісами. Й дуже часто мікросервіси тягнуть бо "перформанс й масштабувння", хоча для цього не обов'язково переходити на мікросервіси. Окрім того мікросервіси це може бути (й зазвичай є) гірше по перформансу ніж моноліт. Ну й ключовий ризик починати відразу з мікросервісів - це вилика ймовірність неправильно поділити відповідальнось мікросервісів. Це стається й а моноліті майже завжди, але рефакторинг там менша проблема, ніж рухати код між мікросервісами й міняти їх інтерфейс й імплементацію. У зв'язку з цим говорять про "monolith first"

[@AboutProgramming]

На моїй практиці мікросервіси в першу чергу були корисні для незалежного деплойменту. Наприклад, коли моноліт вже не дозволяє швидко деплоїти, бо падають тести то однієї команди, то іншої. Інший приклад, коли хочемо мати кращу ізоляцію. Була IoT платформа й треба дозволити стороні компонети з маркетплейсу й це були докер іміджі (тут й ізоляція й деплоймент). Ну й найчастіший кейс це просто воркери під різні задачі, але це не можу назвати мікросервісами навіть, бо ядро системи це моноліт й такий підхід популярний ще з 90х. Також важливо розуміти, що система може мати багато монолітів. Наприклад, є інтернет магазин й це моноліт, а потім виникає потреба в функції менеджменту товарів й це може бути окрема PIM система, а потім система обліку, а потім BI. Й таких різних систем може бути багато, але це далеко не мікросервісна архітектура

[@alexroberto8499]

Щось такого намолов. Так в чому концептуальна проблема то? Оркестрацiя це погано? Описувати iнфраструтуру як код, жах. Rollup це погано? На рiзних мовах пишуть мiкросервiси по твоiй логiцi просто по приколу? Монолiти легко розбивать на мiкросервiси, а якщо важко то це самi винуватi, це що також прикол? У мінуси приводить те що мікросервіс може бути недоступний, це вже точно можна назвати клінікою, коли мікросервіси навпаки вирішують проблему доступності, відмовостійкості, гнучкого масштабування.

[@AboutProgramming]

Ваш коментар схожий на той мультик "Mongo DB is Web Scale", вибачте :) Звісно у мікросервісів є свої переваги, а не тільки недоліки. Відео в першу чергу про ризики. Відносно питання про концептуальну проблему. Концептуальна проблема в тому, що ми зазвичай на початку проекту ми не знаємо достатньо про предметну область, щоб порізати на мікросервіси правильно (BoundedContext). З монолітами така сама проблема й тому є рефакторинг, який в моноліті значно легше зробити (але звісно це вимагає вкладень в його архітектуру теж). Тому часто підхід MonolithFirst є гарним рішенням - martinfowler.com/bliki/MonolithFirst.html . Якщо компанія написала моноліт й потім вирішила переїхати на мікросервіси, то ймовірність успіху вища, ніж почати з мікросервісів. Й такий переїзд це свідоме рішення, яке дає якусь бізнес цінність. Про оркестрацію й "Infrastructure as Code" я й не кажу, що це погано. Я кажу, що "Infrastructure as Code" й оркестрація для мікросервісів значно складніша ніж для моноліту. Й чи доцільні ці затрати й всі інші складнощі на початку Відносно доступності мікросервісів, то як кажуть "Distributed Systems Are Hard" й каскадні падіння сервісів часта ситуація, яка траплається навіть у самих крупних вендорів - www.infoq.com/articles/anatomy-cascading-failure/. Й не просто так виникли усілякі паттерни типу circuit breaker й тд. Відносно гнучкого масштабування, не зовсім розумію, що вам заважає масштабувати моноліт, як це робить Facebook, Instagram, Reddit, Gitlab, Shopify та багато інших компаній. Той самий моніторинг, e2e тестування, дебаг, деплоймент моноліту зазвичай значно легше. Так, мікросервіси мають сенс й переваги (наприклад, незалежний деплоймент й зрозумілий овнершип), але це має бути рішення конкретної бізнес проблеми

[@alexroberto8499]

@@AboutProgramming Кумедне вiдео про MongoDB, але час показав, що той самий зрілий MySQL тепер активно додає підтримку NoSQL, а не MongoDB перейшла на реляційні таблиці і згинула. Щось не мiг зрозумiти, кому ці розповіді про очевидні речі, що з мікросервісами складно починати? В назвi вiдео такого нема, в описi також, в основном у вiдео про хейт мікросервісів, а виявилось що це в контекстi "почати новий проект з мікросервісами" :D Мікросервіси можуть заощадити купу грошей на інфраструктурі в певний період проекту, якщо адмініструвати мікросервіси ви вважаєте обійдеться дорожче, то звiстно про які мікросервіси може йтись

[@DeyviDJONS]

Як на мене, деякі «проблеми» трошки «роздуті», це скоріше «необхідність», а не проблеми, але те що вони озвучені дуже добре. Посперечаюсь на рахунок оркестрації, не вважаю це проблемою, це складність, проте в подальшому це допоможе спростити підтримку застосунку. БД у різних мікросервісах - це мабуть відноситься до якогось ну дуже великого і різноманітного застосунку і якщо це необхідно, то так, з цим можуть бути проблеми, але одного мікросевісу для роботи з БД цілком достатньо в більшості випадків. Окрема вподобайка за цитати і приклади, дуже повчально. Дуже класно, що залізли в тему DevOps і організацію розробки.

[@RT-nc1dn]

Як на мене, люди забувають що ідея мікросервісів була розвинена гігантами ринку для продуктів з мільйонами користувачів і командами у декілька сотен людей. Тому, забуваючи це, починають писати "нетранзакційно цілісний калькулятор" з сотнею мікросервісів розробка якого перетворюється у пекло на землі.

[@artemzabolotnyi3838]

Іноді дійсно немає вибору, щоб AI нормально заюзати, краще зразу використати пітон де все є і всі фічі провідні, а не використовувати якийсь порт ліби на твою мову.

[@AboutProgramming]

Гарний приклад. Навіть більше можна сказати - тут вони не ділять між собою домену модель. Це як окрема програма зі своєю відповідальністю. Наприклад, так само може бути воркер, який просто відправляю емайли або ресайзить картинки. Тому тут має сенс зробити окремий сервіс, навіть якщо мова та сама навіть

[@leok975]

Дякую

[@dmytroshmidt5981]

Дякую