Мені сподобалось розвіювання деяких міфів. Але на рахунок 11:52 Як скейлити моноліт, ми неможемо заскейлити самостійно модуль в моноліті, а, от сервіс самостійно заскейлити можна. Тут приходить тільки варіант винести модуль в сторонній сервіс, то уже не моноліт і трошечки може назадувати маленький костильочок такий
мікрооптимізація - так, а от врахування витрат на етапі проектування це взагалі основа, без якої все може закінчитися не почавшись. Не всі будують стартап на колінці, не знаючи що буде далі і з готовністю все викинути
В цілому підтримую. Моє імхо: якщо це стартап, то пилимо моноліт, розділяємо на модулі в межах проєкту на умовні notifications, statstics, billing, auth, you_logic, etc. Стараємося по максимуму не лізти напряму в сховище/таблиці/базу кожного ж модулів, а спілкуватися через сервісний рівень. Якщо виростаємо і розуміємо, щось стало дуже тісно, то виносимо найжирніші модулі у мікросервіси або в найкращому випадку заміняємося на який SaaS продукт (мається на увазі, що до того часу ваш стартап заробляє гроші). Таким чином можна ще довго прожити з жирним монолітом і мікросервісами сателітами. Прийде час розбивати й жирний моноліт, то вже тоді в компанії буде і експертиза, і інструменти, щоб працювати з монолітами.
@@hyzyla ох вже ці градації. Якщо відвйти від них до бінарної логіки - "зробили", чи "зафейлили" - чим більше в людей буде можливості схалтурити, десь не дотриматися принципів, десь "підставити костиль" тим більша буде вірогідність зафейлити проект так, що його редизайнити доведеться. І круто якщо редизайнити дадуть вам, когось донайнявши. Норм, якщо редизайнити дадуть вашим сусідам через дорогу. Але якщо Через чиїсь помилки проекти з країни можуть піти - тут вже біда. Не знаю хто як, але я бачив більше накостиляних монолітів, ніж мікросервісів з помилками в дизайні (хоча такі також були).
@@oleksandrsova4803 Як ізолювати один бодуль від іншого? Наприклад в мене є якийсь сет, який я можу зібрати за джоіном, як тут буту? Я тут прошу порад, бо в мене є модуль на моноліті, але там така звязаність що страшно
Колись мені старший товариш сказав думку, якої дотримуюсь і досі: - Починай з модультного моноліту завжди. Як прийде час просто витягуєш папку з модулем і з цього будеш мати мікросервіс. І я ще жодного разу не переходив до другого кроку :/
Шось мені так класно дивитись випуск Олександра... І то ж я не прогєр ні разу, але чомусь подобається дивитись випуск... Стрінно... Дякую за випуск, Олександр!
Антихайп в дії. Дякую за чудову аргументацію. Також кльово бачити оці нотки самоіронії під час тупняків 👍 Я оце послухав і дуже відгукнулось до теми Adobe Commerce і мікросервіси - як вони скікись там років говорять про те, що Magento моноліт - гівно, а з мікросервісами заживемо 🫠.
Мікросервіси взагалі працюють тільки в саасах/сервісах, бо коли ти шось продаєш (умовно, як мадженто), то давати на деплой і підтримку оті зоопарки - це жесть
Дякую за відео, повністю погоджуюсь із даними думками. Особливо гарно підмічено, що у ІТ багато на що впливає мода та хайп на певну технологію чи підхід при виборі. 👍
Зараз відвідую тренінг від xpinjection. Підтверджую, мікросервіси сильно підвищують складність аплікації. В більшості випадків, мікросервіси це просто карго культ)
Класний спецефект типу "помєхі на лінії", гиги) Ну а по-темі -- сьорбнув мікросервісів у далекому 2011 й з тих пір тримаюсь подалі. Не знаю чи хтось тут згадував про Convey's Law --- але концепція мікросервісів, то як раз одне з втілень того "закону". p.s. Conway's law is an adage that states organizations design systems that mirror their own communication structure
з мікросервісами біда, бо якось всі забули про здоровий ґлузд, типу - "починаєш з моноліту, а потім дивишся чи тобі треба мікросервіси", я вже мовчу про те, що в більшості випадків я бачив "розподілений моноліт", а не мікросервіси. І за відео подякував
Цілком підтримую. Ми зараз в процесі переробки одного моноліта в другий. Перший писали вісімь років, другий вже другий рік. Якійсь мікс з них працює в проді вже. Деплої кожен день.
Дякую за відос. Гарна тема для холі варів Мені здається, що тут як завжди "it depends". Немає сенсу захищати який-небудь з підходів. Треба дивитись на розмір і специфіку проекту, розмір і технічний рівень команди і т.д. Немає правильного підходу. Треба починати з того, що легше розумієш, а потім аналізувати куди йти далі. Здається, якщо моноліт запущений в декілька інстансів то то вже не моноліт. То вже товсті мікро-сервіси (чи макро-сервіси. Називайте як хочете) в моно-репозиторії. Моноліти скейлять вертикально і це їх мінус.
Чому не моноліт? Моноліт це ж не значить «один інстанс запускаємо», це спосіб організації кода. Зазвичай ті інстанси (у веб-сервіса якогось) між собою не комунікують, тому кожному з них плюс мінус пох, скільки їх запущено.
Ну мікро-сервіси можна також в одному репозиторії зберігати. Тому під способом організації коду я би розумів той факт, що дуже багато синхронного кода, який спирається саме на той факт, що система не розподілена і розташована но одному сервері. Тобто моноліт це один дуже великий сервіс, який важко розділити. Якщо таких сервісів два, то це вже питання чи можно це вважати монолітом Стосовно комунікацій: якщо твій сервіс використовує черги і http апішки - це моноліт чи вже ні?🤔 Взагалі моноліт це один процесс чи декілька? Якщо в моноліта є воркери - це моноліт чи це вже мікро-сервіси?
@@sviat_d > якщо твій сервіс використовує черги і http апішки - це моноліт чи вже ні? Це моноліт. > Взагалі моноліт це один процесс чи декілька? Хоч один, хоч декілька. > Якщо в моноліта є воркери - це моноліт чи це вже мікро-сервіси? Моноліт. Моноліт - це ж не значить stateful процес, який вважає, що всі файли і ресурси лежать на локалхості. Не знаю, звідки такі думки виникають. Так ніхто не робить. Може так писали якісь форуми на C++ із самописною БД років 20-25 тому?
Тоді важко зрозуміти в чому полягає "монолітність" моноліта і в чому відмінність моноліта від мікросервісів, якщо він спокійно ділиться на окремі процеси, дозволяє масштабування і, звісно ж, не буде проблем поділити такий моноліт на декілька команд? Типу мікросервіс = окрема БД і обов'язково окремий репозиторій? 😅
@@sviat_d з деякою кількістю людей в моноліті все ж почнуться проблеми з взаємодією людей. Мікросервіс - це окремий код, так. Там де ти не можеш просто взяти й викликати іншу частину систему викликом функції, а обов‘язково треба йти через апі, черги, тощо. Чи є у мікросервіса окрема БД - може так, може ні. Може у нього взагалі немає ніякої БД, він може тіки щось відповідати та обчислювати. Окремий код - окремий мікросервіс.
По-перше - дякую за гарний україномовний контент) А по-друге не дуже стикався зі складністю деплою, хоча на практиці працюю у компанії, де їх більше тисячі. Достатньо мати гарну систему Feature Toggle/ A/B tests, та після деплою жодних проблем :) Але дуже згоден с операційною складністю)
Так гарна система деплою - це і є складність, її ж побудувати треба, а це час… коли компанія вже зріла, то воно й ок, а коли тільки починається (або у період турбулентності), ото гемор і не хочеться часу витрачати на це)
@@asolovyov цілком згоден) Якщо будувати щось невеличке, то втрата часу на побудування космічного корабля з процессами деплою, сервіс діскавері, та усіма іншими сіай та сіді просто немає сенсу) Оскільки ті, хто не будуть цього робити раніше вийдуть на ринок та зароблять достатньо грошей, щоб потім все переробити))
Відео супер! Цікаво ще розібрати випадки використання мікросервісів в невеликих компаніях (порівняно із Netflix), які перед цим на них мігрували (не за покликом моди)
Я пробовал - не понравилось, и плюс я понял бенчмарки плохие. Лучше централизованная архитектура. Хороший канал, удивительно слышать технический украинский - приятно уху и все понятно
Колись робив доповідь про архітектуру й дуже схожі штуки розповідав th-cam.com/video/TjvIEgBCxZo/w-d-xo.html (3-12хв) Зараз мода на мікросервіси потрохи уходить й вони все частіше там, де реально потрібні. Про індустрію моди ти влучно)
Дякую з відео. Питання про скейлінг моноліту і використання окремих баз для певних областей. 1. Наприклад у вас в моноліті є функціонал по ресайзу картинок. У вас зростає обєм картинок які треба ресайзити. Коли ви піднімете +20 інстансів моноліту ви можете просто дарма використовувати ресурси. Для ресайзу картинок треба 200мб що б все працювало, а у вас будуть інші накладні витрати по ініціалізації класів і других підсистем які не використовуються (або треба буде робити моноліт який можна забутати так що б накладних витрат по різних процесах не було) - можливо я чогось не розумію. 2. Моноліт з 20ма базами. Уявіть у вас є 20 підсистем в моноліті і кожна потребує свою базу. Вам приходить реквест який мандрує 5ма підсистемами. Треба що б у вашому процесі було підключення до 5тьох баз. Ви ж не відключаєтесь від бази після обробки реквесту - відповідно підключення висить. І кожен інстанс моноліту буде зїдати конекшин + память. Наскілкьи я розумію підключення можуть висіти і не завжди використовуватись - ми ж не контролюємо шлях реквестів (в який інстанс його пушити). Можливо у вас є думки на рахунок цієї ситуації. Моноліти і мікросервіси це організаія коду і процесів яка має місце бути при певних умовах.
1) У нас для ресайзу картинок окремий сервіс. 😝 Бо догматичність - це гірше мікросервісів. :) А ще краще оффлоаднуть таку задачу на якийсь Cloudflare Images і все. 2) Є думка що це звучить вигаданою ситуацією, плюс висить собі конекшен і висить, в чому проблема? В тому шо умовний постгрес страждає? То для того є баунсери конекшенів.
@@asolovyov :D Олександр на відео: чи потрібні мікросервіси? Ні Олександра в коментарях: У нас для ресайзу картинок окремий сервіс. > А ще краще оффлоаднуть таку задачу на якийсь Cloudflare Images і все. 100% Є просто задачі які попадають під цей самий патерн і перекласти їх на зовнішні сервіси неможливо. Тому пишуть внутрішні. > плюс висить собі конекшен і висить, в чому проблема? Ви ж розумієте що база це одна штука а є ще редіси, кафки і другі штуки, це все множиться) Тобто з базами це може бути вигадана система але в загальному ізоляція даних і підсистем досить важлива коли у вас велика команда. Тобто якась підсистема в моноліті може лізти в дані які вона не має лізти - і за цим всім треба слідкувати і робити контроль.
Із всього відео сподобалося про те шо треба мати голову) Тоді і з монолітом і з мікросервісами проблем буде мінінмум. А ще треба пам'ятати шо треба вибирати технологію під задачі, а не навпаки
@@alotofall та ну, ніфіга, бейзлайн проблем з мікросервісами завжди вищий. Просто з дуже великою командою з монолітом через втрати на координацію розробка буде сповільнюватися, для того і розділяють продукт, щоб обмежити взаємодію команд. Але проблем з розподіленою системою завжди більше тупо by design, просто з великою командою є виділенні люди, які займаються їх вирішенням.
@@asolovyov > Але проблем з розподіленою системою завжди більше тупо by design, просто з великою командою є виділенні люди, які займаються їх вирішенням. ну технічно мікросервіси складніші поки система мала. Як тільки ви напишете 1лям рядків і наймете 100 інженерів у вас зміниться враження. Мені здається мікросервіси і моноліт це так само як рнр і джава. Вивчити пиху простіше. Написати простіше. Але як тільки зростає складність переваги рнр просто пропадають)))
Якщо вміти готувати, то виходить норм. Якщо не вмієте, то і не беріться. Працював на декількох проектах з мікросервісами, один навіть будували з нуля, стек Rast/Go/C++, враження лише позитивні. Можливо залежить від мови, наприклад для Go/C++ бінарь виходить 20..30mb і плюс Alpine контейнер 5mb - дуже гарно скейлиться. З Java та "micro" сервісами були одні страждання. Кейси бувають різні, знаю проект на С++, який технічно складно, майже неможливо, тримати монолітом, бо 120Gb RAM недостатньо щоб його збілдити.
Та я її в рсс колись читав, а зараз пошуком замахався - і не знайшов. Може ще один підхід зроблю, але це було кілька років тому і ключові слова вже не згадуються…
А можна відео про те як і чому переходили з django на clojure? Настільки сильно впиралися в performance python? Зазвичай же основні проблеми зі швидкістю веб-сервисів це ж бд та наявність/відсутність кешування. Цікаво про цей досвід, тобто чому саме вирішили перейти і де виграли з цього?
10:11 зараз працюю у великому проэкті над MFE в команді з 9 чол. З хорошим тімлідом всей йде чотко. Це дійсно так. Але ми могли могли би мати в Angular чітко свій модуль на не цілу mfe точно з таким самим успіхом.
Те саме з MFE, інтеграція цервісів це проблема. На стороні бекенду є 1000 варіантів інтеграції. Для швидкості розробки кожен мікросервіс має бути самодостатнім, тобто він + авторизаційний має бути достатньо але такі мікросервіси вже не зовсім мікро Для того щоб кожен мікросервіс міг окремо скейлитись потрібно для кожного окремо робити лоад баланс. Короче хороший архітектор має заморочитичь нереально щоб відчути ті міфічні переваги мікросервісів. На стороні фронденда є тільки одна перевага - мульти фреймворки і все.
якщо це мікробізнес, то він вкладається в один мікросервіс)) а взагалі, із будь яким підходом є одна загальна проблема. Це догматичнічність і культ карго. Декларуючи одне, ти відсікаєш все інше. Сидиш на моноліті і боїшся винести сервіс, бо його треба окремо моніторити, деплоїти і т.п. Більшість проблем сервісного підходу виникає із поганим проектуванням, яке направду майже неможливо зробити наперед, якщо ти до цього не робив таку саму систему. Тому, треба закладати платформу потенційно готову для розділення і об‘єднання на всіх шарах і рівнях - дані, логіка, інтерфейс, api, тощо.
Привіт чувак, слушні думки, яб ще додав, що іноді мікросервіси мають сенс якщо в тебе є якась спільна логіка, яка використовується кількома сервісами або аппками. Типу воркери, скрейпери, мапредюсери, аппи і таке інше. Плюс будь який продакшн проект живий і в нього є логіка розвитку розуміння бізнесу, тому починати з мікросервісів - реально складно і немає сенсу, бо ти реально не шариш на початку якіми термінами будеш оперувати через деякий час. Тож на мою думку треба завжди починати з моноліта, і дуже консервативно підходити до виділення сервісів, тільки у випадках якщо інших варіантів нема.
Точно-точно! А коли є якийсь сервіс спільний для кількох систем, то це і є сервіс. Бо імхо коли кажуть "мікросервісна архітектура" - це коли ти модулі своєї системи перетворюєш на процеси, пов'язані мережею. Типу одну систему/сервіс робиш розподіленою. Це ж зовсім не означає, що платформа компанії буде одним процесом запущена. :)
з приводу скейлінга не згоден. бо щоб зрозуміти як і куди скейліти чи в загалі які ліміти треба ставити, то треба по перш робити тест навантаження і дивитись на графічки)) бо без тестив та без моніторінга апп може жрати всі ресурси та ще гірку))) тож може мабуть треба дивитись ширше та далі кордонів апп)). далі (1:30 - 3:00) не слухав, бо чекаю відповіді
У Сашка десь є відос про те, що ти ьестуй чи не ьестуй все одно отримаєш XYZ. Бо тестувати навантаження також не в кубер задеплоїти. Гуд лак тестувати навантаження мікросрвісів без розуміння "що" і "нащо"
Навряд ти запускаєш новий продукт на трафік у мільйон користувачів. Ти ж вже десь є? І з інфраструктури що ти даєш своєму продукту ти бачиш що він їв сьогодні і що було тиждень тому.
По скейлінгу теж не підтримую, якщо норм розрізаний домен і з асинхонними запитами то все має бути ок. Виключення коли в тебе по сервісу на бек і фронт, там треба вже гратися але нічого складеого
Дякую за поради. Як щодо ситуації коли над монолітом працює більше 10 команд і деплоймент перетворюється на жах, де треба в загальний слек писати шось типа "I'm releasing %monolith%, please don't merge anything in master"? Або коли шоб задеплоїти маленьку зміну треба годину чекати поки всі тести та інші кроки в деплоймент пайплайні (більшість з яких нерелевантні) пройдуть зелененьки?
Проблему з «я реліжу не чіпайте мастер» не зовсім розумію. Звучить наче процес деплою вимагає покращення? Ідеальний деплой - помітив конкретний комміт, і пішов займатися справами, і він або вилетить на прод, або нотіфікашку пришле про готовність.
@@andriiplaysguitar ну реліз для мене - це конкретний комміт для мене. В нас є невеличкий скрипт в репі завжди, bin/release запускаєш, і він робить новий комміт, відрізає чейнджлог, генерує тег і лишається тільки пушнути все, щоби поїхав процес. :)
На одном из мест работы была следующая ситуация: монолит на старом и заброшеном фреймворке, куча дублей, ЯП апгрейднуть нельзя (тк фреймворк не совместим с новыми версиями), код писать там сложно и больно. В итоге самое удобное что придумали - относительно большие фичи инкапсулировать в сторонних сервисах (микросервисах), а основной монолит использовать в качестве гейтвея. Справедливости ради - этот кейс больше про: техдолг в монолите и как его решать при отсутствии ресурсов, чем про монолит vs микросервис.
@@asolovyov Uncle Bob колись казав: "Microservice is a deployment option." Як на мене - або недоговорював або розраховував на великий професіоналізм аудиторії, що не буде з "кишок" одного модуля лізти в "кишки" іншого. В мікросервісах то простіше контролювати. Дійсно, в базових умовах - ніхто не заважав. І дійсно, можна було почати з однієї малої частинки, а потім рухатись поступово докидуючи туди ж інші частинки. Але нащо наражатись на небезпеку незв'язних in-process communications якщо вже трапилась нагода дати justification по-компонентному деплою?
Чтобы подвести немного к общей черте. Монолиты требуют правильной архитектуры, микросервисы тоже требуют и правильной архитектуры и правильной организации работы. Пока больше людей которые лучше умеют в архитектуру монолитов. А тех кто умеет микросервисы их мало, а еще меньше тех кто может организовать работу команд. Если все же станет понятно, что надо распиливать монолит на микросервисы, то вот мой опыт th-cam.com/video/TraEhjYv6BQ/w-d-xo.html.
широке застосування мікросервісів привело до нової моди - серверлес. і тут коли ти маєш малий кодбейс то впринципі юзати лямбди як варіант мікросервісів
Угу і стаєш Senior YAML Developer’ом потім і єбешся з тим шо амазон залізо дає говняне, працює все повільно, лупить тебе по таймаутам, треба прогрівати і таке інше)
@@asolovyov підходиш такий до чувака з нетфлікс і кажеш йому моноліт рулить а мікросервіси хуйня, думаю відповідь буде з такого розряду як ваша мені. не у всіх проекти для бізнесу такої категорії як у вас де лямбди і близько не підходять
В нашій конторі упоролись, і ми для заказчіка кожну таблицю в монзі, виносимо в отдєльний мікросервіс зі своїм беком, а крім цього між фронтом і беком стоїть прослойка ,тіпа проксі, і по ходу її тоже треба дробити по аналогії з таблицями, і міняються ендпоінти на фронті, ну і звичайно фронт теж будемо крамсати на мікро)
@@vitalii7413 так і є), але я ніколи не міг би подумати що комусь треба буде настільки мікросервісну архітектуру), я думаю через рік два, кожну функцію будемо виносити на отдєльний порт)))
Arguably так, але по-перше уникнути цього дуже важко (дивись аргумент про факторінг), по-друге навіть з гарним факторінгом нормальні таски все одно будуть це робити. Моноліт теж може мати гарну модульність. І повинен.
Ой, дуже по наболілому. Вже наплодили мікросервісів більше десятка, а проблем тільки виросло. З цікавого, що мене вразило, як прикрутив New Relic, то те, що нові сервіси беруть на себе трафіку, часом, одиниці-десятки запитів на хвилину... Я в шокови. Хто має брати на себе відповідальність за такі архітектурні рішення, як планування тех сторони продукту? Є відчуття, що все на самоплині з культом мікросервісів. Як я розумію, то при зростанні в 3Х на рік, новий сервіс для модуля, який зараз має 10 запитів на хвилину знадобиться ще не скоро. Як ви міркуєте, якими критеріями варто користуватись для декомпозиції? (Про кількість людей в команді - це теж питання, можна комітити в різні модулі, та й є великі компанії з монолітом. В нас відчуття, що кількість команди залежить від бажання мати велику команду, а не кількості викликів від бізнесу)
Мені теж здається, що розмір команди часто не від потреб, а від бажання розміру. :) Де поділяти - дуже складне питання і треба кейс бай кейс. З монолітом і супутними сервісами це, здається, більше технічне питання. Типу коли ти хочеш в пам‘яті багато всього тримати для якогось конкретного апі і виділяєш це в окремий сервіс на мові, в якій управління пам‘яттю руками.
Таке враження ніби втор відео, переглянув як робити поганий мікросервіс, і від того відштовхувався. Ідея мікросервісів полягає у тому що зробити модулі абсолютно незалежними один від одного та щоб модулі відповідали суто за свою задачу. Абсолютно те ж можна зробити й моноліті, це правда, і у плані проектування те буде попроще. Но, якщо ти будуєш моноліт, то у тебе проблеми виникають на довгострокових перспективах, а з мікросерсвісами навпаки. П.С. Мікросерсвіс має дуже багато переваг. І таку архітектуру вибирають далеко не тому що 'модно'. П.П.С. Що до розміру команд та нетфлікс з твітером, так то великі мегакорпорації яких у світі не так багато. НО, це не значе що у командах має обов'язково бути 12 людей. У команді може бути просто один розробник, якому ставлять завдання, і він їх виконує. І він може суто відповідати за свій модуль, який він розробляє. У тому й красота. Ти можеш убезпечити дані, і відати модулі на умовний аутсорс.
Враження хибне) Незалежність мікросервісів - це дивна пісня, чесно, бо якщо вони прям друг з другом не спілкуються - це не дуже і одна система тоді. Питань нема, нашо це в одну кодову базу пхати. Про аутсорс аргумент непоганий, його я з виду випустив, дякую.
В розробку часто тягнуть безліч готового гімна, яке написане на чому попало, як попало і не може працювати в рамках однієї і тієї ж фізичної машини. Ну і так, зробили що все з усім пов’язане, то тікають в мікросервіси, бо думають буде по іншому. Зв’язність і звязанність чи як там його.
Ти не сказав про фейловерабіліті)) в частині локалізації шкоди. Часом в одному продукті насправді є різні і вони не залежать один від одного, ну хіба інфа про користувача ділиться. І от коли ти один з таких зламав, то інші працюють.
Ну це ж ніхто не заважає мати таке в моноліті. Типу те шо в тебе один урл фейлиться - не заважає іншим працювати. Авжеж, може ти шось дуже фундаментально поламав, але тоді ти або це помітив і не релізнув, або швидесенько відкатив. Загалом, режими збою в мікросервісів різноманітніші та цікавіші, ніж в моноліта, через розподіленість. :)
@@asolovyov ну звичайно що це про повний даунтайм, коли щось вцілому зламане, але і про перформанс деградацію, або тупо хтось накочує індекс на велику таблицю блокуючи її чи ще щось. Але ще можна ділити юзерсторі. Наприклад зареєстрований і не зареєстрований користувач. Першого можна відправити на якийсь лендос з блогом, та й взагалі на окремий сервер. А зареєстровані на кращому залізі) Інший приклад - окремий чекаут, щоб максимально ізолювати тих хто вже несе тобі гроші. Апгрейдити базу краще під часткою юзерів ніж для всіх одразу, особливо там де база не потрібна і юзерсторі окрема. PS. Весь час працюю з монолітом. І правда що основна перевага і мотивація для мікросервісів - це організаційна структура. Часто ти не хочеш щоб процеси і підходи іншої команди впливали на твої.
Чим далі в ліс - тим страшніше вовки :) Так, чим більша/старша система, тим більше цікавих деталей, але базово проблеми залишаються ті самі. Всі аргументи за мікросервіси не працюють, працює лише один - тисяча людей в одному проєкті працювати ефективно не можуть. А все інше - запустити окремі інстанси для незалогінених, мати більше баз, ніж одну, і так далі - можна й з монолітом. Ніхто не заважає в моноліті мати багато ентрі поінтів і менші артефакти для окремих частин. Типу спосіб організації кода і спосіб деплоя можна і не змішувати. :)
Ты забыл упомянуть об отказоустойчивости. Допустим у нас есть банк, в котором есть сервис, который отвечает за обработку транзакций, сервис обработки нотификаций, и сам сервис онлайн-банкинга. И, пока идет работа над обновлением сервиса банкинга, сервис уведомлений и обработки транзакций должны работать без отказов
@@danish_m1305 маю на увазі що така вимога є в будь-якому випадку, незалежно від архітектури. Більше того, я б сказав що при деплої жоден із сервісів не повинен відмовляти, неважливо, яка архітектура.
@@danish_m1305 ну якщо сервіс - http, то так, кілька інстансів і перед ними load balancer - наприклад, nginx/haproxy/caddy/traefik/etc. Якщо це сховище (типу постгрес, скажімо), то життя складніше і будуть пляски із реплікацією і баунсерами (по факту теж балансувальником навантаження).
2:40 У вас дуже багато "якщо". Як на мене ви розглядаєте виключно погані дизайни. Скейлити потрібно не сервіс. Скейлити потрібно юз-кейс. Бо це юз-кейс загибається, а не сервіс. І якщо ви не можете обчислити boundary кейсу, що треба скейлити - руки геть від мікросервісів та хутко до навчання, бо розбитий солюшн на сервіси ну дуже погано.
А як же бути в ситуації коли в тебе інтерпрайз на 1 мільйон рядків коду? Хочеться, щоб виклики до інших модулів були задокументовані та персистентні(event driven архітектура), щоб були якісь межі між модулями і щоб можна було деплоїти окремо лише те що потрібно. Мені здалося що ти порівнюєш розподілений монололіт і звичайний моноліт де твої поїнти валідні. Хоча ти ж сам розповідав що у вас є багато окремих сервісів які спілкуються між собою через кафку. Це хіба не мікросервіси у випадку маленької тіми де сервіси досить великі і мало людей? BTW кейс де ти пилиш нову фічу і треба транзитивно робити зміни в декількох сервісах можна вирішити в event driven мікросервісах де ти маєш дві версії евентів і просто вчиш свої мікросервіси по різному їх оброблювати.
Ну мікросервіси мають одну велику відмінність ідеологічну від сервісів. Типу ти принципово будуєш критично розподілену систему, вірно? В нашому випадку є кілька систем, які спілкуються через кафку - типу сайт для продажів, сайт для постачальників, ерп, доставка, але вони самі по собі окремі системи, це точно не мікросервіси. І в них можуть бути маленькі сервіси поруч (типу скріншотілка на puppeteer, наприклад). А мільйон рядків - думаю, що кейс бай кейс, але розумну модульність ніхто не відміняв. Якось воно доросло до мільйона? Тож якусь модульність там закладали на старті… важко сказати, не заглибившись в деталі, якщо чесно. Про івент сорсінг - згоден, це виглядає більш приємним способом організувати зворотню сумісність. :)
@@asolovyov ооо, ось тут я збагнув що ти маєш на увазі кажучи мікросервіси. Треба було б акцентувати на цьому. Хоча я сервіси називаю мікросервісами, але поділ мені імпонує саме по ізольованій поведінці, коли частина загальної системи самодостатня хоча б від частини інших систем.
Так-так, велике питання, як ділити систему! Це власне основне. Мій поінт такий: починати з будування розподіленої системи, поки ти ще навіть не усвідомлюєш, де в тебе будуть проблеми - не варто.
Чому всі оминають досить вдалу концепцію монорепи ? Автор контенту навіть не обмовився. Така організація кода допомогає із вирішенням питання взаємних залежностей. А можливість скейлінгу та підбір оптимальних конфігурацій для кожного із сервісів залишається. Також автор зовсім оминув тему що розвиток контейнеризаціі (можливо через моду, але це невдале ствердження), дав змогу додавати у свою платформу багато готових рішеннь, що треба сприймати саме як мікро сервіси , але написані іншими.
Бо монорепа це ортогонально мікросервісам/моноліту. Це просто коли багато кодових баз у одній репі лежить, і це якісь речі робить простішими, але кардинально не змінює ситуацію. Ніякої спеціальної можливості скейлінгу у мікросервісів нема.
@@asolovyov Можливо зробити контент про скейлінг в Касті? Я поки не бачу пітверджень того щоб скейлінг моноліта добре працював. Мене трохи дивує ситуація навколо продажу марок Укрпоштою, що жоден із маркетплейсів не може нормально витримати навантаження.
@@DmytroVorotyntsev в нас не клауд через багато різних причин. :) А щодо того що не може витримати навантаження - так це як раз цікаво, бо помирає першим KastaPay, який мікросервісний і в AWS. Автоскейлінг не відпрацьовує достатньо швидко.
Тільки бородаті діди топлять за моноліт. А скейлити моноліт зручно? Не дорого? Якщо 2 з 20 модулів перебувають під високим навантаженням, то скейлити доводиться весь моноліт чи нє? 1. Треба адекватно проектувати мікросервіси. Потрібен architect. 2. В голові все тримати не треба, а от документація має бути описана. 3. Є купа задач, де моноліт працює, але сучасний веб додаток на +5К юерів значно ефективніше робити на мікросервісах.
«Скейлити прийдеться весь моноліт»? Я не розумію що тут мається на увазі, але якщо в тебе 10 сервісів розкидано по 10 серверам кожен із потужністю х (загалом 10х), і тобі треба двом з них додати в два рази більше потужності, і ти отримуєш 12х (ну якщо якийсь далі сервіс не почне завалюватися від навантаження), то таке саме і з монолітом буде. Якщо тобі треба додати 20% потужності, то не треба додавати в два рази. В мене в житті було більше возні типу «через місяць у вас буде 10х навантаження, придумайте шось», і з мікросервісами це було б в рази більше возні тупо щоби зрозуміти де треба додавати потужностей. Всі твої пункти - якась догматична хрінь.
@@asolovyov ми возились зі скейлом моноліту 3 роки, поки це нам не набридло і ми не переписали систему на мікросервіси. Це зайняло не мало часу, але результат настільки порадував, що назад ми не повернемось.
12:00 гроші заважають скейлити моноліт. Знову ж таки тому що проскейливши моноліт ви проскейлити ще достобісу кейсів, що вам скейлити не потрібно було. А це все жере гроші як свиня помиї.
@@asolovyov "Тормозить" не завжди через скейлінг вирішується - це факт. Завжди через скейлінг вирішується якийсь shortage. Наприклад, коли активних конекшнів не вистачає для того щоб закрити поточний customer demand. І як ви **в моноліті** дасте більше facilities на обслуговування більшого числа **одночасних** запитів на список товарів не давши те саме на чекаут - то для мене загадка.
@@oleksandrsova4803 ну можна конекшен пулер всередині аплікейшена підрихтувати заради якихось або пріорітетів, або лімітів. Зовні, авжеж, такої можливості не буде. Інше питання, чи таке взагалі коли-небудь знадобиться.
@@asolovyov Розмір пулу не просто так на окремій залізяці не можна поставити unlimited. Тож і нарощувати його до нескінченості не можна. Він досить швидко виїдається. А щодо того чи треба - то так. І досить часто. Thread starvation частіше за все виникає там, де автоматичні скрипти (наприклад клієнтські інтеграції), що ви не контролюєте насідають на ваш API. Для бізнесу кожен той реквест надцінний. І, якщо з інтеграціями можна виявити паттерн і відскейлюватись за короткий час до inflow - то з людьми таке не вийде. Вони приходять коли хочуть. І тут лише elasticity додавати. А еластично відскейлити моноліт... Ні, воно то можна. Але скільки часу воно займе? Хвилину? Може всі п'ять? Скільки зумерів за цей час вкладку закриють? І який аналітик скаже яка з них частина, що могла виконати імпульсивну покупку на гайпі? Як на мене - ці питання мають складність на стільки високу, у порівнянні з чим всі складності, що ви приводили у відео просто нескінчено малі.
@@oleksandrsova4803 rate limit здається шо розумніше на вході робити, ніж на кількості конекшенів до бази. А коли приходять справжні люди, то ти теж не дуже хочеш на списку товарів працювати, а на чекауті тормозити. Про еластічний скейлінг я не розумію, про шо ми розмовляємо. Запустити більше процесів - проблем нема. Відскейлити базу? Це складніше, авжеж, але коли ми наколхозили мікросервісів з монгодб кожен, то ситуація в нас ще гірша. Я б сказав що дискусія про БД вимагає якогось більш вдалого майданчику, ніж коменти на ютубі. :(
![[Live] : ONE 169 วันนี้!! "อนาโตลี vs อูมาร์"](http://i.ytimg.com/vi/IK3YZVWuFJg/mqdefault.jpg)
Додатково обговорення на форумі DOU: dou.ua/forums/topic/38805/
Мені сподобалось розвіювання деяких міфів.
Але на рахунок 11:52 Як скейлити моноліт, ми неможемо заскейлити самостійно модуль в моноліті, а, от сервіс самостійно заскейлити можна. Тут приходить тільки варіант винести модуль в сторонній сервіс, то уже не моноліт і трошечки може назадувати маленький костильочок такий
@@СтасМацунич чому не можемо скейлити модуль? Не можемо докинути ресурсів? Не можемо покращити код? Яка саме проблема?
Дякую, дуже багато здорового глузду і все дуже добре сформульовано!
Передчасна оптимізація - корінь усього зла)
Дядько Ілон ще говорив
мікрооптимізація - так, а от врахування витрат на етапі проектування це взагалі основа, без якої все може закінчитися не почавшись. Не всі будують стартап на колінці, не знаючи що буде далі і з готовністю все викинути
@@dispute_charge_explainedти про той старий холодильник?
В цілому підтримую. Моє імхо: якщо це стартап, то пилимо моноліт, розділяємо на модулі в межах проєкту на умовні notifications, statstics, billing, auth, you_logic, etc. Стараємося по максимуму не лізти напряму в сховище/таблиці/базу кожного ж модулів, а спілкуватися через сервісний рівень. Якщо виростаємо і розуміємо, щось стало дуже тісно, то виносимо найжирніші модулі у мікросервіси або в найкращому випадку заміняємося на який SaaS продукт (мається на увазі, що до того часу ваш стартап заробляє гроші). Таким чином можна ще довго прожити з жирним монолітом і мікросервісами сателітами. Прийде час розбивати й жирний моноліт, то вже тоді в компанії буде і експертиза, і інструменти, щоб працювати з монолітами.
> Стараємося
Failure заклався ще на цьому слові.
@@oleksandrsova4803 штош, хоча би за старання можна поставити трієчку 😆
@@hyzyla ох вже ці градації. Якщо відвйти від них до бінарної логіки - "зробили", чи "зафейлили" - чим більше в людей буде можливості схалтурити, десь не дотриматися принципів, десь "підставити костиль" тим більша буде вірогідність зафейлити проект так, що його редизайнити доведеться. І круто якщо редизайнити дадуть вам, когось донайнявши. Норм, якщо редизайнити дадуть вашим сусідам через дорогу. Але якщо Через чиїсь помилки проекти з країни можуть піти - тут вже біда.
Не знаю хто як, але я бачив більше накостиляних монолітів, ніж мікросервісів з помилками в дизайні (хоча такі також були).
@@oleksandrsova4803 Як ізолювати один бодуль від іншого? Наприклад в мене є якийсь сет, який я можу зібрати за джоіном, як тут буту? Я тут прошу порад, бо в мене є модуль на моноліті, але там така звязаність що страшно
Колись мені старший товариш сказав думку, якої дотримуюсь і досі:
- Починай з модультного моноліту завжди. Як прийде час просто витягуєш папку з модулем і з цього будеш мати мікросервіс.
І я ще жодного разу не переходив до другого кроку :/
Контент топовий, спікер топовий, якість звуку топова, дикція топова, мова відео - топова
Короче, лайк і підписка)
Більше україномовного IT-контенту!!!!!
В точку. Маю точно таку ж думку про мікросервіси та основну причину їх використання
Комент підтримки і для просування відео
Шось мені так класно дивитись випуск Олександра... І то ж я не прогєр ні разу, але чомусь подобається дивитись випуск... Стрінно... Дякую за випуск, Олександр!
Мікросервіси, як ти правильно підмітив, це вирішення організаційних проблем, а зовсім не технічних :)
Як то кажуть "You Are Not Google".
Супер кльово, дякую, дуже класна думка стосовно мікросервісів/монолітів
дякую за контент!!
P.S. якщо хтось ще не знав, то синонім до слова "геморой" - це "когнітивне навантаження" )))
Антихайп в дії. Дякую за чудову аргументацію.
Також кльово бачити оці нотки самоіронії під час тупняків 👍
Я оце послухав і дуже відгукнулось до теми Adobe Commerce і мікросервіси - як вони скікись там років говорять про те, що Magento моноліт - гівно, а з мікросервісами заживемо 🫠.
Мікросервіси взагалі працюють тільки в саасах/сервісах, бо коли ти шось продаєш (умовно, як мадженто), то давати на деплой і підтримку оті зоопарки - це жесть
Дякую за працю. Цікавий матеріал і було приємно слухати.
Дякую за відео, повністю погоджуюсь із даними думками. Особливо гарно підмічено, що у ІТ багато на що впливає мода та хайп на певну технологію чи підхід при виборі. 👍
Зараз відвідую тренінг від xpinjection. Підтверджую, мікросервіси сильно підвищують складність аплікації. В більшості випадків, мікросервіси це просто карго культ)
Чітко і зрозуміло розкладено. Дякую!
Класний спецефект типу "помєхі на лінії", гиги) Ну а по-темі -- сьорбнув мікросервісів у далекому 2011 й з тих пір тримаюсь подалі. Не знаю чи хтось тут згадував про Convey's Law --- але концепція мікросервісів, то як раз одне з втілень того "закону".
p.s. Conway's law is an adage that states organizations design systems that mirror their own communication structure
Давай наступне про мікрофронтенди :)
Та я шось не готовий, у мене там взагалі немає розуміння нашо люди про це розмовляють))
Коротко - це піздець
По максимуму уникайте цього
@@MrHerych Якщо більш детально?
Дуже кльовий контент!
Відео яке ми заслужили. Тільки моноліт!
Not the one you deserve, but the one you need 🤣
До речі було би цікаво послухати чому ви перейшли з Джанго на кложуру. Маю на увазі окрім очевидних причин - performance і крутість)
з мікросервісами біда, бо якось всі забули про здоровий ґлузд, типу - "починаєш з моноліту, а потім дивишся чи тобі треба мікросервіси", я вже мовчу про те, що в більшості випадків я бачив "розподілений моноліт", а не мікросервіси. І за відео подякував
Цілком підтримую. Ми зараз в процесі переробки одного моноліта в другий. Перший писали вісімь років, другий вже другий рік. Якійсь мікс з них працює в проді вже. Деплої кожен день.
Цікава та актуальна тема, дякую!
Дякую! Цікаво почути вашу думку що до того як робити СУЧАСНІ моноліти :)
Відео вогонь! Подача інформації кльова!
Дякую за відос. Гарна тема для холі варів
Мені здається, що тут як завжди "it depends". Немає сенсу захищати який-небудь з підходів. Треба дивитись на розмір і специфіку проекту, розмір і технічний рівень команди і т.д. Немає правильного підходу. Треба починати з того, що легше розумієш, а потім аналізувати куди йти далі.
Здається, якщо моноліт запущений в декілька інстансів то то вже не моноліт. То вже товсті мікро-сервіси (чи макро-сервіси. Називайте як хочете) в моно-репозиторії. Моноліти скейлять вертикально і це їх мінус.
Чому не моноліт? Моноліт це ж не значить «один інстанс запускаємо», це спосіб організації кода. Зазвичай ті інстанси (у веб-сервіса якогось) між собою не комунікують, тому кожному з них плюс мінус пох, скільки їх запущено.
Ну мікро-сервіси можна також в одному репозиторії зберігати. Тому під способом організації коду я би розумів той факт, що дуже багато синхронного кода, який спирається саме на той факт, що система не розподілена і розташована но одному сервері. Тобто моноліт це один дуже великий сервіс, який важко розділити. Якщо таких сервісів два, то це вже питання чи можно це вважати монолітом
Стосовно комунікацій: якщо твій сервіс використовує черги і http апішки - це моноліт чи вже ні?🤔
Взагалі моноліт це один процесс чи декілька? Якщо в моноліта є воркери - це моноліт чи це вже мікро-сервіси?
@@sviat_d > якщо твій сервіс використовує черги і http апішки - це моноліт чи вже ні?
Це моноліт.
> Взагалі моноліт це один процесс чи декілька?
Хоч один, хоч декілька.
> Якщо в моноліта є воркери - це моноліт чи це вже мікро-сервіси?
Моноліт.
Моноліт - це ж не значить stateful процес, який вважає, що всі файли і ресурси лежать на локалхості. Не знаю, звідки такі думки виникають. Так ніхто не робить. Може так писали якісь форуми на C++ із самописною БД років 20-25 тому?
Тоді важко зрозуміти в чому полягає "монолітність" моноліта і в чому відмінність моноліта від мікросервісів, якщо він спокійно ділиться на окремі процеси, дозволяє масштабування і, звісно ж, не буде проблем поділити такий моноліт на декілька команд?
Типу мікросервіс = окрема БД і обов'язково окремий репозиторій? 😅
@@sviat_d з деякою кількістю людей в моноліті все ж почнуться проблеми з взаємодією людей.
Мікросервіс - це окремий код, так. Там де ти не можеш просто взяти й викликати іншу частину систему викликом функції, а обов‘язково треба йти через апі, черги, тощо.
Чи є у мікросервіса окрема БД - може так, може ні. Може у нього взагалі немає ніякої БД, він може тіки щось відповідати та обчислювати. Окремий код - окремий мікросервіс.
відео супер! однозначно лайк!!!
По-перше - дякую за гарний україномовний контент)
А по-друге не дуже стикався зі складністю деплою, хоча на практиці працюю у компанії, де їх більше тисячі.
Достатньо мати гарну систему Feature Toggle/ A/B tests, та після деплою жодних проблем :)
Але дуже згоден с операційною складністю)
Так гарна система деплою - це і є складність, її ж побудувати треба, а це час… коли компанія вже зріла, то воно й ок, а коли тільки починається (або у період турбулентності), ото гемор і не хочеться часу витрачати на це)
@@asolovyov цілком згоден) Якщо будувати щось невеличке, то втрата часу на побудування космічного корабля з процессами деплою, сервіс діскавері, та усіма іншими сіай та сіді просто немає сенсу) Оскільки ті, хто не будуть цього робити раніше вийдуть на ринок та зароблять достатньо грошей, щоб потім все переробити))
Відео супер!
Цікаво ще розібрати випадки використання мікросервісів в невеликих компаніях (порівняно із Netflix), які перед цим на них мігрували (не за покликом моди)
Я пробовал - не понравилось, и плюс я понял бенчмарки плохие. Лучше централизованная архитектура. Хороший канал, удивительно слышать технический украинский - приятно уху и все понятно
Гарний відос
Колись робив доповідь про архітектуру й дуже схожі штуки розповідав
th-cam.com/video/TjvIEgBCxZo/w-d-xo.html (3-12хв)
Зараз мода на мікросервіси потрохи уходить й вони все частіше там, де реально потрібні.
Про індустрію моди ти влучно)
Дякую з відео. Питання про скейлінг моноліту і використання окремих баз для певних областей.
1. Наприклад у вас в моноліті є функціонал по ресайзу картинок. У вас зростає обєм картинок які треба ресайзити. Коли ви піднімете +20 інстансів моноліту ви можете просто дарма використовувати ресурси. Для ресайзу картинок треба 200мб що б все працювало, а у вас будуть інші накладні витрати по ініціалізації класів і других підсистем які не використовуються (або треба буде робити моноліт який можна забутати так що б накладних витрат по різних процесах не було) - можливо я чогось не розумію.
2. Моноліт з 20ма базами. Уявіть у вас є 20 підсистем в моноліті і кожна потребує свою базу. Вам приходить реквест який мандрує 5ма підсистемами. Треба що б у вашому процесі було підключення до 5тьох баз. Ви ж не відключаєтесь від бази після обробки реквесту - відповідно підключення висить. І кожен інстанс моноліту буде зїдати конекшин + память. Наскілкьи я розумію підключення можуть висіти і не завжди використовуватись - ми ж не контролюємо шлях реквестів (в який інстанс його пушити). Можливо у вас є думки на рахунок цієї ситуації.
Моноліти і мікросервіси це організаія коду і процесів яка має місце бути при певних умовах.
1) У нас для ресайзу картинок окремий сервіс. 😝 Бо догматичність - це гірше мікросервісів. :) А ще краще оффлоаднуть таку задачу на якийсь Cloudflare Images і все.
2) Є думка що це звучить вигаданою ситуацією, плюс висить собі конекшен і висить, в чому проблема? В тому шо умовний постгрес страждає? То для того є баунсери конекшенів.
@@asolovyov :D
Олександр на відео: чи потрібні мікросервіси? Ні
Олександра в коментарях: У нас для ресайзу картинок окремий сервіс.
> А ще краще оффлоаднуть таку задачу на якийсь Cloudflare Images і все.
100% Є просто задачі які попадають під цей самий патерн і перекласти їх на зовнішні сервіси неможливо. Тому пишуть внутрішні.
> плюс висить собі конекшен і висить, в чому проблема?
Ви ж розумієте що база це одна штука а є ще редіси, кафки і другі штуки, це все множиться) Тобто з базами це може бути вигадана система але в загальному ізоляція даних і підсистем досить важлива коли у вас велика команда.
Тобто якась підсистема в моноліті може лізти в дані які вона не має лізти - і за цим всім треба слідкувати і робити контроль.
Ні чого не зрозумів, але дуже цікаво.
Ще яскравий приклад це GNU/Hurd
Дуже сумна історія насправді, Столман щиро хотів зробити сучасну, ефективну систему
Із всього відео сподобалося про те шо треба мати голову) Тоді і з монолітом і з мікросервісами проблем буде мінінмум. А ще треба пам'ятати шо треба вибирати технологію під задачі, а не навпаки
Так і є, але з мікросервісами бейзлайн проблем все одно вищий 😁
@@asolovyov це за умови що у вас мала команда. Якщо команда велика то все з точністю до навпаки. ;)
@@alotofall та ну, ніфіга, бейзлайн проблем з мікросервісами завжди вищий. Просто з дуже великою командою з монолітом через втрати на координацію розробка буде сповільнюватися, для того і розділяють продукт, щоб обмежити взаємодію команд.
Але проблем з розподіленою системою завжди більше тупо by design, просто з великою командою є виділенні люди, які займаються їх вирішенням.
@@asolovyov
> Але проблем з розподіленою системою завжди більше тупо by design, просто з великою командою є виділенні люди, які займаються їх вирішенням.
ну технічно мікросервіси складніші поки система мала. Як тільки ви напишете 1лям рядків і наймете 100 інженерів у вас зміниться враження.
Мені здається мікросервіси і моноліт це так само як рнр і джава. Вивчити пиху простіше. Написати простіше. Але як тільки зростає складність переваги рнр просто пропадають)))
Хоч хтось всю правду розказав!
Цікавий випуск, дякую за працю!
Якщо вміти готувати, то виходить норм. Якщо не вмієте, то і не беріться. Працював на декількох проектах з мікросервісами, один навіть будували з нуля, стек Rast/Go/C++, враження лише позитивні. Можливо залежить від мови, наприклад для Go/C++ бінарь виходить 20..30mb і плюс Alpine контейнер 5mb - дуже гарно скейлиться. З Java та "micro" сервісами були одні страждання. Кейси бувають різні, знаю проект на С++, який технічно складно, майже неможливо, тримати монолітом, бо 120Gb RAM недостатньо щоб його збілдити.
Про моду влучно 👏 Пошерте пліз лінк на статтю Twitter про розмір команд - цікаво) 10:01
Та я її в рсс колись читав, а зараз пошуком замахався - і не знайшов. Може ще один підхід зроблю, але це було кілька років тому і ключові слова вже не згадуються…
@@asolovyov от і я не знайшов)
А можна відео про те як і чому переходили з django на clojure? Настільки сильно впиралися в performance python? Зазвичай же основні проблеми зі швидкістю веб-сервисів це ж бд та наявність/відсутність кешування. Цікаво про цей досвід, тобто чому саме вирішили перейти і де виграли з цього?
th-cam.com/video/Xs6ED_v9TzY/w-d-xo.htmlsi=m_EZC1URf7_urC4b
І там після нього ще є 2 частина
Я ще мав досвід де був один мікросервіс на людину, в середньому. Казали що то дуже аджайл 😅
І перед тим як писати новий сервіс треба спочатку когось взяти на роботу?)
10:11 зараз працюю у великому проэкті над MFE в команді з 9 чол. З хорошим тімлідом всей йде чотко. Це дійсно так. Але ми могли могли би мати в Angular чітко свій модуль на не цілу mfe точно з таким самим успіхом.
не можна бути таким розумним, це незаконно!
піду дивитися твоє відео про closure
Загалом вагінь. 😍 Тільки ніхто до кінця не додивитися і мозок не ввімкне як результат. Доведіть що я неправий!
Те саме з MFE, інтеграція цервісів це проблема. На стороні бекенду є 1000 варіантів інтеграції.
Для швидкості розробки кожен мікросервіс має бути самодостатнім, тобто він + авторизаційний має бути достатньо але такі мікросервіси вже не зовсім мікро
Для того щоб кожен мікросервіс міг окремо скейлитись потрібно для кожного окремо робити лоад баланс.
Короче хороший архітектор має заморочитичь нереально щоб відчути ті міфічні переваги мікросервісів.
На стороні фронденда є тільки одна перевага - мульти фреймворки і все.
якщо це мікробізнес, то він вкладається в один мікросервіс)) а взагалі, із будь яким підходом є одна загальна проблема. Це догматичнічність і культ карго. Декларуючи одне, ти відсікаєш все інше. Сидиш на моноліті і боїшся винести сервіс, бо його треба окремо моніторити, деплоїти і т.п.
Більшість проблем сервісного підходу виникає із поганим проектуванням, яке направду майже неможливо зробити наперед, якщо ти до цього не робив таку саму систему. Тому, треба закладати платформу потенційно готову для розділення і об‘єднання на всіх шарах і рівнях - дані, логіка, інтерфейс, api, тощо.
Привіт чувак, слушні думки, яб ще додав, що іноді мікросервіси мають сенс якщо в тебе є якась спільна логіка, яка використовується кількома сервісами або аппками. Типу воркери, скрейпери, мапредюсери, аппи і таке інше. Плюс будь який продакшн проект живий і в нього є логіка розвитку розуміння бізнесу, тому починати з мікросервісів - реально складно і немає сенсу, бо ти реально не шариш на початку якіми термінами будеш оперувати через деякий час. Тож на мою думку треба завжди починати з моноліта, і дуже консервативно підходити до виділення сервісів, тільки у випадках якщо інших варіантів нема.
Точно-точно! А коли є якийсь сервіс спільний для кількох систем, то це і є сервіс. Бо імхо коли кажуть "мікросервісна архітектура" - це коли ти модулі своєї системи перетворюєш на процеси, пов'язані мережею. Типу одну систему/сервіс робиш розподіленою.
Це ж зовсім не означає, що платформа компанії буде одним процесом запущена. :)
з приводу скейлінга не згоден. бо щоб зрозуміти як і куди скейліти чи в загалі які ліміти треба ставити, то треба по перш робити тест навантаження і дивитись на графічки)) бо без тестив та без моніторінга апп може жрати всі ресурси та ще гірку))) тож може мабуть треба дивитись ширше та далі кордонів апп)). далі (1:30 - 3:00) не слухав, бо чекаю відповіді
Ну так і є, просто скейлити в базовому варіанті простіше моноліт все одно, і перероблювати теж :)
У Сашка десь є відос про те, що ти ьестуй чи не ьестуй все одно отримаєш XYZ. Бо тестувати навантаження також не в кубер задеплоїти. Гуд лак тестувати навантаження мікросрвісів без розуміння "що" і "нащо"
Навряд ти запускаєш новий продукт на трафік у мільйон користувачів.
Ти ж вже десь є?
І з інфраструктури що ти даєш своєму продукту ти бачиш що він їв сьогодні і що було тиждень тому.
По скейлінгу теж не підтримую, якщо норм розрізаний домен і з асинхонними запитами то все має бути ок. Виключення коли в тебе по сервісу на бек і фронт, там треба вже гратися але нічого складеого
Дякую за поради. Як щодо ситуації коли над монолітом працює більше 10 команд і деплоймент перетворюється на жах, де треба в загальний слек писати шось типа "I'm releasing %monolith%, please don't merge anything in master"? Або коли шоб задеплоїти маленьку зміну треба годину чекати поки всі тести та інші кроки в деплоймент пайплайні (більшість з яких нерелевантні) пройдуть зелененьки?
Проблему з «я реліжу не чіпайте мастер» не зовсім розумію. Звучить наче процес деплою вимагає покращення?
Ідеальний деплой - помітив конкретний комміт, і пішов займатися справами, і він або вилетить на прод, або нотіфікашку пришле про готовність.
@@asolovyov Я мабуть трохи застряг у минулому з усіма штуками типу gitflow з мастером, епік бранчами, фіча бранчами тощо. Дякую ще раз.
@@andriiplaysguitar ну реліз для мене - це конкретний комміт для мене. В нас є невеличкий скрипт в репі завжди, bin/release запускаєш, і він робить новий комміт, відрізає чейнджлог, генерує тег і лишається тільки пушнути все, щоби поїхав процес. :)
Моноліт на линукс контейнерах супер тема, ноль возни
На одном из мест работы была следующая ситуация: монолит на старом и заброшеном фреймворке, куча дублей, ЯП апгрейднуть нельзя (тк фреймворк не совместим с новыми версиями), код писать там сложно и больно. В итоге самое удобное что придумали - относительно большие фичи инкапсулировать в сторонних сервисах (микросервисах), а основной монолит использовать в качестве гейтвея.
Справедливости ради - этот кейс больше про: техдолг в монолите и как его решать при отсутствии ресурсов, чем про монолит vs микросервис.
Ага, ну ніхто не заважав зробити інший моноліт, а старий юзати як проксі так само. Ну короч купа підходів)
@@asolovyov Uncle Bob колись казав: "Microservice is a deployment option." Як на мене - або недоговорював або розраховував на великий професіоналізм аудиторії, що не буде з "кишок" одного модуля лізти в "кишки" іншого. В мікросервісах то простіше контролювати.
Дійсно, в базових умовах - ніхто не заважав. І дійсно, можна було почати з однієї малої частинки, а потім рухатись поступово докидуючи туди ж інші частинки. Але нащо наражатись на небезпеку незв'язних in-process communications якщо вже трапилась нагода дати justification по-компонентному деплою?
українською ❤ лайк
Чтобы подвести немного к общей черте. Монолиты требуют правильной архитектуры, микросервисы тоже требуют и правильной архитектуры и правильной организации работы. Пока больше людей которые лучше умеют в архитектуру монолитов. А тех кто умеет микросервисы их мало, а еще меньше тех кто может организовать работу команд.
Если все же станет понятно, что надо распиливать монолит на микросервисы, то вот мой опыт th-cam.com/video/TraEhjYv6BQ/w-d-xo.html.
Єдине, що в нейтральності аналізу підводить трохи - це те, що архітектура мікросервісів складніше by design (розподілене все і тп). А так все вірно.
@@asolovyov сложнее, еще больше проблем с правильным инструментарием, и как у всяких модных технологий куча васянов которые лишь бы воткнуть.
Тепер це дати подивитися всім мамкіним архітектам, які закочують очі і заламують руки коли ти їм кажеш, що їх мікросервіси непотрібні в 90% випадків.
Малеев, здається, гарно розповідав, чому не потрібні архітектори. Там просто тема з курицею та яйцем :)
Найс)
І так - виключити коменти в тг - гарний хід xD
Ггг))
широке застосування мікросервісів привело до нової моди - серверлес.
і тут коли ти маєш малий кодбейс то впринципі юзати лямбди як варіант мікросервісів
Угу і стаєш Senior YAML Developer’ом потім і єбешся з тим шо амазон залізо дає говняне, працює все повільно, лупить тебе по таймаутам, треба прогрівати і таке інше)
@@asolovyov підходиш такий до чувака з нетфлікс і кажеш йому моноліт рулить а мікросервіси хуйня, думаю відповідь буде з такого розряду як ваша мені. не у всіх проекти для бізнесу такої категорії як у вас де лямбди і близько не підходять
Ггг ну ок, є кейси для лямбд, авжеж:)
Це я з ними просто погрався і воно мене змусило нормально фруструвати 😁
До речі й черги повідомлень можна в моноліті зробити. Як спосіб зв’язків між модулями та якщо не вистачає екзотики)
PS дякую за відео
Ага походу різне HPC подібно працює через асинхронні методи MPI:)
В нашій конторі упоролись, і ми для заказчіка кожну таблицю в монзі, виносимо в отдєльний мікросервіс зі своїм беком, а крім цього між фронтом і беком стоїть прослойка ,тіпа проксі, і по ходу її тоже треба дробити по аналогії з таблицями, і міняються ендпоінти на фронті, ну і звичайно фронт теж будемо крамсати на мікро)
🤦♂
Якщо є заказчік то ваш менеджмент крутий!
В даному випадку це супер успішний кейс!)
@@vitalii7413 так і є), але я ніколи не міг би подумати що комусь треба буде настільки мікросервісну архітектуру), я думаю через рік два, кожну функцію будемо виносити на отдєльний порт)))
Якщо зміна одного мікросервіса тягне за собой зміни ще в десятку то ви зробили не мікросервіси а поганий моноліт
Саме так всі і роблять
Arguably так, але по-перше уникнути цього дуже важко (дивись аргумент про факторінг), по-друге навіть з гарним факторінгом нормальні таски все одно будуть це робити.
Моноліт теж може мати гарну модульність. І повинен.
Плюсую.
Ось оце «мікро» людей з розуму зводить, і вони ділять там де вже давно варто б зупинитися.
Ой, дуже по наболілому. Вже наплодили мікросервісів більше десятка, а проблем тільки виросло. З цікавого, що мене вразило, як прикрутив New Relic, то те, що нові сервіси беруть на себе трафіку, часом, одиниці-десятки запитів на хвилину... Я в шокови.
Хто має брати на себе відповідальність за такі архітектурні рішення, як планування тех сторони продукту? Є відчуття, що все на самоплині з культом мікросервісів.
Як я розумію, то при зростанні в 3Х на рік, новий сервіс для модуля, який зараз має 10 запитів на хвилину знадобиться ще не скоро. Як ви міркуєте, якими критеріями варто користуватись для декомпозиції? (Про кількість людей в команді - це теж питання, можна комітити в різні модулі, та й є великі компанії з монолітом. В нас відчуття, що кількість команди залежить від бажання мати велику команду, а не кількості викликів від бізнесу)
Мені теж здається, що розмір команди часто не від потреб, а від бажання розміру. :)
Де поділяти - дуже складне питання і треба кейс бай кейс. З монолітом і супутними сервісами це, здається, більше технічне питання. Типу коли ти хочеш в пам‘яті багато всього тримати для якогось конкретного апі і виділяєш це в окремий сервіс на мові, в якій управління пам‘яттю руками.
th-cam.com/video/jkKThsA1_JE/w-d-xo.html Тут про моноліти й мікросервіси пару копійок
Таке враження ніби втор відео, переглянув як робити поганий мікросервіс, і від того відштовхувався.
Ідея мікросервісів полягає у тому що зробити модулі абсолютно незалежними один від одного та щоб модулі відповідали суто за свою задачу.
Абсолютно те ж можна зробити й моноліті, це правда, і у плані проектування те буде попроще.
Но, якщо ти будуєш моноліт, то у тебе проблеми виникають на довгострокових перспективах, а з мікросерсвісами навпаки.
П.С.
Мікросерсвіс має дуже багато переваг. І таку архітектуру вибирають далеко не тому що 'модно'.
П.П.С.
Що до розміру команд та нетфлікс з твітером, так то великі мегакорпорації яких у світі не так багато. НО, це не значе що у командах має обов'язково бути 12 людей. У команді може бути просто один розробник, якому ставлять завдання, і він їх виконує. І він може суто відповідати за свій модуль, який він розробляє. У тому й красота. Ти можеш убезпечити дані, і відати модулі на умовний аутсорс.
Враження хибне)
Незалежність мікросервісів - це дивна пісня, чесно, бо якщо вони прям друг з другом не спілкуються - це не дуже і одна система тоді. Питань нема, нашо це в одну кодову базу пхати.
Про аутсорс аргумент непоганий, його я з виду випустив, дякую.
Пробач але не підтримую. Деякі переваги описані моноліта тут мають місто бути, деякі лише тому що не достатньо досвіду
Треба більше подробиць, а то нічого не ясно :)
В розробку часто тягнуть безліч готового гімна, яке написане на чому попало, як попало і не може працювати в рамках однієї і тієї ж фізичної машини.
Ну і так, зробили що все з усім пов’язане, то тікають в мікросервіси, бо думають буде по іншому. Зв’язність і звязанність чи як там його.
Ти не сказав про фейловерабіліті)) в частині локалізації шкоди. Часом в одному продукті насправді є різні і вони не залежать один від одного, ну хіба інфа про користувача ділиться. І от коли ти один з таких зламав, то інші працюють.
Ну це ж ніхто не заважає мати таке в моноліті. Типу те шо в тебе один урл фейлиться - не заважає іншим працювати. Авжеж, може ти шось дуже фундаментально поламав, але тоді ти або це помітив і не релізнув, або швидесенько відкатив.
Загалом, режими збою в мікросервісів різноманітніші та цікавіші, ніж в моноліта, через розподіленість. :)
@@asolovyov ну звичайно що це про повний даунтайм, коли щось вцілому зламане, але і про перформанс деградацію, або тупо хтось накочує індекс на велику таблицю блокуючи її чи ще щось.
Але ще можна ділити юзерсторі.
Наприклад зареєстрований і не зареєстрований користувач.
Першого можна відправити на якийсь лендос з блогом, та й взагалі на окремий сервер. А зареєстровані на кращому залізі)
Інший приклад - окремий чекаут, щоб максимально ізолювати
тих хто вже несе тобі гроші.
Апгрейдити базу краще під часткою юзерів ніж для всіх одразу, особливо там де база не потрібна і юзерсторі окрема.
PS.
Весь час працюю з монолітом.
І правда що основна перевага і мотивація для мікросервісів - це організаційна структура. Часто ти не хочеш щоб процеси і підходи іншої команди впливали на твої.
Чим далі в ліс - тим страшніше вовки :) Так, чим більша/старша система, тим більше цікавих деталей, але базово проблеми залишаються ті самі. Всі аргументи за мікросервіси не працюють, працює лише один - тисяча людей в одному проєкті працювати ефективно не можуть.
А все інше - запустити окремі інстанси для незалогінених, мати більше баз, ніж одну, і так далі - можна й з монолітом. Ніхто не заважає в моноліті мати багато ентрі поінтів і менші артефакти для окремих частин. Типу спосіб організації кода і спосіб деплоя можна і не змішувати. :)
Ты забыл упомянуть об отказоустойчивости. Допустим у нас есть банк, в котором есть сервис, который отвечает за обработку транзакций, сервис обработки нотификаций, и сам сервис онлайн-банкинга. И, пока идет работа над обновлением сервиса банкинга, сервис уведомлений и обработки транзакций должны работать без отказов
Повинні - і з мікросервісами, і з монолітом.
@@asolovyov Трішки не зрозумів, можете детальніше розказати що ви маєте на увазі?
@@danish_m1305 маю на увазі що така вимога є в будь-якому випадку, незалежно від архітектури. Більше того, я б сказав що при деплої жоден із сервісів не повинен відмовляти, неважливо, яка архітектура.
@@asolovyov А як це вирішується. Декількома інстансами сервера? Можете дати мені текст запиту, де про це можна почитати?
@@danish_m1305 ну якщо сервіс - http, то так, кілька інстансів і перед ними load balancer - наприклад, nginx/haproxy/caddy/traefik/etc. Якщо це сховище (типу постгрес, скажімо), то життя складніше і будуть пляски із реплікацією і баунсерами (по факту теж балансувальником навантаження).
ох і палає зараз у всіх хто продає мікросервісну архітектуру як пюшку
То девʼять чи десять?
2:40 У вас дуже багато "якщо". Як на мене ви розглядаєте виключно погані дизайни. Скейлити потрібно не сервіс. Скейлити потрібно юз-кейс. Бо це юз-кейс загибається, а не сервіс. І якщо ви не можете обчислити boundary кейсу, що треба скейлити - руки геть від мікросервісів та хутко до навчання, бо розбитий солюшн на сервіси ну дуже погано.
А як же бути в ситуації коли в тебе інтерпрайз на 1 мільйон рядків коду? Хочеться, щоб виклики до інших модулів були задокументовані та персистентні(event driven архітектура), щоб були якісь межі між модулями і щоб можна було деплоїти окремо лише те що потрібно. Мені здалося що ти порівнюєш розподілений монололіт і звичайний моноліт де твої поїнти валідні. Хоча ти ж сам розповідав що у вас є багато окремих сервісів які спілкуються між собою через кафку. Це хіба не мікросервіси у випадку маленької тіми де сервіси досить великі і мало людей?
BTW кейс де ти пилиш нову фічу і треба транзитивно робити зміни в декількох сервісах можна вирішити в event driven мікросервісах де ти маєш дві версії евентів і просто вчиш свої мікросервіси по різному їх оброблювати.
Ну мікросервіси мають одну велику відмінність ідеологічну від сервісів. Типу ти принципово будуєш критично розподілену систему, вірно?
В нашому випадку є кілька систем, які спілкуються через кафку - типу сайт для продажів, сайт для постачальників, ерп, доставка, але вони самі по собі окремі системи, це точно не мікросервіси. І в них можуть бути маленькі сервіси поруч (типу скріншотілка на puppeteer, наприклад).
А мільйон рядків - думаю, що кейс бай кейс, але розумну модульність ніхто не відміняв. Якось воно доросло до мільйона? Тож якусь модульність там закладали на старті… важко сказати, не заглибившись в деталі, якщо чесно.
Про івент сорсінг - згоден, це виглядає більш приємним способом організувати зворотню сумісність. :)
@@asolovyov ооо, ось тут я збагнув що ти маєш на увазі кажучи мікросервіси.
Треба було б акцентувати на цьому.
Хоча я сервіси називаю мікросервісами, але поділ мені імпонує саме по ізольованій поведінці, коли частина загальної системи самодостатня хоча б від частини інших систем.
Так-так, велике питання, як ділити систему! Це власне основне. Мій поінт такий: починати з будування розподіленої системи, поки ти ще навіть не усвідомлюєш, де в тебе будуть проблеми - не варто.
Чому всі оминають досить вдалу концепцію монорепи ? Автор контенту навіть не обмовився. Така організація кода допомогає із вирішенням питання взаємних залежностей. А можливість скейлінгу та підбір оптимальних конфігурацій для кожного із сервісів залишається. Також автор зовсім оминув тему що розвиток контейнеризаціі (можливо через моду, але це невдале ствердження), дав змогу додавати у свою платформу багато готових рішеннь, що треба сприймати саме як мікро сервіси , але написані іншими.
Бо монорепа це ортогонально мікросервісам/моноліту. Це просто коли багато кодових баз у одній репі лежить, і це якісь речі робить простішими, але кардинально не змінює ситуацію.
Ніякої спеціальної можливості скейлінгу у мікросервісів нема.
@@asolovyov Можливо зробити контент про скейлінг в Касті? Я поки не бачу пітверджень того щоб скейлінг моноліта добре працював. Мене трохи дивує ситуація навколо продажу марок Укрпоштою, що жоден із маркетплейсів не може нормально витримати навантаження.
@@DmytroVorotyntsev в нас не клауд через багато різних причин. :) А щодо того що не може витримати навантаження - так це як раз цікаво, бо помирає першим KastaPay, який мікросервісний і в AWS. Автоскейлінг не відпрацьовує достатньо швидко.
Тільки бородаті діди топлять за моноліт. А скейлити моноліт зручно? Не дорого? Якщо 2 з 20 модулів перебувають під високим навантаженням, то скейлити доводиться весь моноліт чи нє?
1. Треба адекватно проектувати мікросервіси. Потрібен architect.
2. В голові все тримати не треба, а от документація має бути описана.
3. Є купа задач, де моноліт працює, але сучасний веб додаток на +5К юерів значно ефективніше робити на мікросервісах.
«Скейлити прийдеться весь моноліт»? Я не розумію що тут мається на увазі, але якщо в тебе 10 сервісів розкидано по 10 серверам кожен із потужністю х (загалом 10х), і тобі треба двом з них додати в два рази більше потужності, і ти отримуєш 12х (ну якщо якийсь далі сервіс не почне завалюватися від навантаження), то таке саме і з монолітом буде. Якщо тобі треба додати 20% потужності, то не треба додавати в два рази.
В мене в житті було більше возні типу «через місяць у вас буде 10х навантаження, придумайте шось», і з мікросервісами це було б в рази більше возні тупо щоби зрозуміти де треба додавати потужностей.
Всі твої пункти - якась догматична хрінь.
@@asolovyov ми возились зі скейлом моноліту 3 роки, поки це нам не набридло і ми не переписали систему на мікросервіси. Це зайняло не мало часу, але результат настільки порадував, що назад ми не повернемось.
@@shchekavytsia ноу проблемос, але 1) моноліти різні бувають та 2) ви не стартували з мікросервісів, що прям сууупер-розумно
монолит - это тоже микросервисная архитектура с одним микросервисом. Вы еще просто не пришли к тому что ее надо разбить.
Занадто філософськи :)
@@asolovyov как и вся жизнь ))). И там и там есть плюсы и минусы.
12:00 гроші заважають скейлити моноліт. Знову ж таки тому що проскейливши моноліт ви проскейлити ще достобісу кейсів, що вам скейлити не потрібно було. А це все жере гроші як свиня помиї.
Не ясно, в чому проблема. Тормозить список товарів? Прекрасно, давайте займемось їм - і чекаут при тому чіпати не треба.
@@asolovyov "Тормозить" не завжди через скейлінг вирішується - це факт. Завжди через скейлінг вирішується якийсь shortage. Наприклад, коли активних конекшнів не вистачає для того щоб закрити поточний customer demand. І як ви **в моноліті** дасте більше facilities на обслуговування більшого числа **одночасних** запитів на список товарів не давши те саме на чекаут - то для мене загадка.
@@oleksandrsova4803 ну можна конекшен пулер всередині аплікейшена підрихтувати заради якихось або пріорітетів, або лімітів. Зовні, авжеж, такої можливості не буде. Інше питання, чи таке взагалі коли-небудь знадобиться.
@@asolovyov Розмір пулу не просто так на окремій залізяці не можна поставити unlimited. Тож і нарощувати його до нескінченості не можна. Він досить швидко виїдається.
А щодо того чи треба - то так. І досить часто. Thread starvation частіше за все виникає там, де автоматичні скрипти (наприклад клієнтські інтеграції), що ви не контролюєте насідають на ваш API. Для бізнесу кожен той реквест надцінний. І, якщо з інтеграціями можна виявити паттерн і відскейлюватись за короткий час до inflow - то з людьми таке не вийде. Вони приходять коли хочуть. І тут лише elasticity додавати. А еластично відскейлити моноліт... Ні, воно то можна. Але скільки часу воно займе? Хвилину? Може всі п'ять? Скільки зумерів за цей час вкладку закриють? І який аналітик скаже яка з них частина, що могла виконати імпульсивну покупку на гайпі?
Як на мене - ці питання мають складність на стільки високу, у порівнянні з чим всі складності, що ви приводили у відео просто нескінчено малі.
@@oleksandrsova4803 rate limit здається шо розумніше на вході робити, ніж на кількості конекшенів до бази. А коли приходять справжні люди, то ти теж не дуже хочеш на списку товарів працювати, а на чекауті тормозити.
Про еластічний скейлінг я не розумію, про шо ми розмовляємо. Запустити більше процесів - проблем нема. Відскейлити базу? Це складніше, авжеж, але коли ми наколхозили мікросервісів з монгодб кожен, то ситуація в нас ще гірша.
Я б сказав що дискусія про БД вимагає якогось більш вдалого майданчику, ніж коменти на ютубі. :(