Чи потрібні вам мікросервіси? - DOU DevOps Podcast #11

🗓 Приєднатися на вебінар "Магія GitLab: Розкриваємо потенціал автоматизованого DevOps" - eu1.hubs.ly/H085XhT0
💫 У новому випуску подкасту DOU для DevOps спеціалістів ми обговорили, що таке мікросервіси, яким компаніям вони необхідні та міфи навколо. Вйо дивитися!
🔔 Підписуйтесь на DOU і включіть дзвіночок, щоб першими дивитися нові випуски - / @dou_youtube
📲 А ще у нас є кльовий телеграм-канал DOU | DevOps - t.me/devops_dou
🎫 Купити квиток на DOU Day - dou.ua/goto/RtC3
Ведучі:
- Володимир Шинкар, CEO в AppRecode - dou.ua/users/volodymyr-shynkar/
- Валерія Іванова, DevOps Team Lead at Plarium - www.linkedin.com/in/valeriia-...
- Дмитро Стрілецький, Senior Software Engineer - dou.ua/users/dmytrostriletskyi/
- Денис Ювженко, System Architect в Intellias - dou.ua/users/ydivol/
⏩ Навігація:
00:00 Інтро
00:36 Партнерський блок
01:25 Про мікросервіси
24:42 Міф, про те, що мікросервіси - це класно
28:16 Чи можна вважати лямбди мікросервісами?
30:56 Всі мікросервіси мають бути маленькі?
34:20 Мікросервіси це гарантія стійкості?
40:16 Яким компаніям підходить використання мікросервісів?
46:16 Налаштування та оптимізація перформансу

[@TimurShemsedinov]

Як кажуть «Такий великий, а досі віриш у мікросервіси»

[@shchekavytsia]

Мед! Мед на мої вуха! Аааа! Дякую вам! Супер! Те, що треба👍 трохи б раніше, то я мав би більше волосся, але ж і так супер! ви прекрасні 👍

[@DOU_youtube]

нікнейм просто 🔥

[@dmytro-skh]

дуже цікава бесіда, робіть ще, дякую

[@anatolijd]

Якось все дуже максимально загально і абстрактно. "може бути добре а може не бути". Мікросервіси - це відповідь на зростання складності аплікацій (монолітних), головним чином на складність їх масштабування для hi-load i hi-availability. Було б чудово як би ви обговорили кілька різних прикладів з власного досвіду, типу

[@anatolijd]

- розробка нової аплікації на мікросервісах. Як поділили на мікросервіси, чи є відчуття недоцільної складності з точки зору operations. А з точи зору Dev ? І теж висновок - що є доцільно а що - ні. Що б тепер зробили по-ішому якби починали спочатку.

[@anatolijd]

В вас же всіх є купа такого досвіду, і в кожного свій специфічний і при цьому ви в одній студії. Архітектор (який вирішує бузнес-задачу) аргументує доцільність по-своєму, dev (який пише весь той код і дебажить його) - по-своєму, devops(відповідальний за deploy і support ) - по-своєму.

[@anatolijd]

Можна вас попросити дещо ? :) Мені, як глядачу, було б набагато цікавіше і зрозуміліше якби ви ілюстрували обговорення реальними прикладами. І вам теж було б простіше, бо обговорювати реальні кейси легше ніж загально-абстрактні.

[@ua-rik]

Плюсую

[@user-if4ts7dh5e]

Супер контент! Дайте ще

[@luckyboy4504]

Дякую за топовий і файний контент українською! Вподобайка та коментар в підтримку просування відео ❤

[@DOU_youtube]

ну ви💙

[@pavlosaikevych]

дуже файний випуск вийшов :)

[@DOU_youtube]

Дякуємо, це дуже приємно чути!

[@xineman648]

ви називаєте це відео подкастом, але на жодній платформі я його не знайшов

[@IMMORTALmen]

Срібної кулі нема, Everything is a tradeoff!

[@laxdna3030]

Срібна куля - це відсутність коду взагалі. Нема коду - нема багів.

[@YuriyYarosh]

0. Головним недоліком використання мікросервісів є Amlification - Request / Storage. Відповідно невеликі запити користувачів породжують купу доданого трафіку й затримки, що збільшує вартість володіння продуктом інколи й до 100 разів. 1. Будь який Комерційний Додаток використовує ААА сервіси, відповідні моделі вже були розроблені в усіляких телеком протоколах типу Diameter Tasacs тощо 2. Винос auth/authz в окремі сервіси - бредова ідея, бо вони Мають виконуватись як раз в Gateway API ... там Envoy WASM плагінами з якогось Ory чи OpenFGA, писати Authz - не треба... а RBAC частіш вже давно мертвий й давно замінений на ABAC типу Zanzibar. 3. Є проблема Bounded Context'у по DDD, й у випадку Aggregate Boundaries то як раз таки ще й Сonsistency Boundaries, де потрібно вірно обрати моделі консистентності 4. Насправді Розподілення Додатку на мікросервіси - оптимізаційна задача компіляції... яку люди не мають виконувати вручну.

[@hamsterua]

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

[@YuriyYarosh]

@@hamsteruaдля того щоб "зменьшити кодову базу" треба застосовувати будь які засоби кодогенерації та перетворення інтерфейсів, й мікросервіси до цього не мають ніякого відношення. Масштабування "окремих частинок" виконуються не за споживаною оперативною пам'яттю та процесорним часом, а за кількістю запитів в секунду (там Knative-serving / Keda тощо) й відповідні значення на залежить на скільки й як саме розділився той чи інший сервіc. А от узгодженість в кінцевому рахунку (eventual consistency) граничних кореневих сутностей (ID користувача тощо), з наявністю великої кількості сервісів, значно зменьшує їх доступність.

[@YuriyYarosh]

@@hamsteruaдля того щоб "зменьшити час компіляції" варто зробити її інкрементальною (bazel там якийсь, наприклад), й навчитись там в монорепозиторії (turborepo тощо)... залежить від цільової мови програмування та відповідного BuildOps/TestOps оточення.

[@keepmefromdecay]

Денис - сила :)

[@gambit6888]

32:55 це називається "Закон Конвея". Спеціалісти)

[@artmara9583]

interesting video, thanks

[@hamsterua]

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

[@gambit6888]

28:10 Якщо лямбди - це мікросервіси, то по тому ж принципу можна вважати що кожна хранима процедура в базі яка викликається тріггером та щось із даними робить - є мікровервісом)))

[@IMMORTALmen]

Наносервіс)!

[@b0dn4r_K]

Не пам'ятаю ніодного випадку щоб щось змінювалось при переїзді на мікросервіси, який би великий проект не був. Багато коду - проблеми пхп і інших. Багато бдшок - проблеми дж і інших(можливо). Бенефіт лише в швидкості деплоя бачу, все. Навіть мітингів не збільшувалось. Upd: мова програмування Ruby on Rails

[@determinism3221]

А звідки ви взяли, що при змінах в мікросервісі відпаде щось одне, а от у моноліті все одразу? Постійно чую цю думку. Ви знаєте про схеми БД? Створіть нову схему для свого додатку, вони повністю ізольовані. А видалити/зламати все можна і дистанційно і в мікросервісній архітектурі, це від коду залежить. Що складного в тому, щоб ізолювати ваш додаток у моноліті? Це робиться елементарно.

[@determinism3221]

Згоден із Денисом. Сказав приблизно те саме після.

[@dejevi]

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

[@IMMORTALmen]

Сіріуслі ображатись на ці слова? Не існує людини яка б все знала і яка б була експертом у всьому, завжди є чому вчитись і якщо в процесі навчання ображатись на конкретні слова( які навіть не є образливими ), то буде дуже важко.

[@hamsterua]

Тригером є архітектор що не зміг пояснити що таке мікросервіс, і зразу вправ в роздуми про базу і api gateway. Why? Вибачте, але як він це замовнику продає?

[@aldomoro9414]

Потрібні 🤌

[@maksimbilous4060]

Ех, чувак, якась в тебе однобока думка ))

[@DOU_youtube]

Чи ні? (байт на дискусію)

[@eq716]

@@DOU_youtubeгоризонтальне масштабування відміняється? будемо масшатувати прямо монолітами? або можна платити AWS, мати все на serverless і казати, шо у нас не має жодного мікросервісу.

[@neironus]

чим вам kubectl не вгодив). Чому б і не юзати pure manifest або kustomize? HELM дуже хороша штука, але у кожної тулзи завжди є свої слабкі сторони

[@apprecode]

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

[@hamsterua]

Можна використовувати helm як шаблонізатор тільки. На заміну уродського kustomize . А далі helm to file abd kubectl apply Але є проблема видалення сервісів. Дуже рідко але є

[@maxkovalchuk1396]

дивне ім'я - Всещеденис

[@amayahutsul]

serverless > microservices?

[@andriyloz7558]

Блін, коли ви рнр останній раз бачили, певно ще в минулому столітті?

[@apprecode]

Вчора, нажаль :(

[@andriyloz7558]

@@apprecode Цікавості заради, хотілося б дізнатись що з php, на Вашу думку, не так. Дуже часто доводиться чути що з пхп є повне г... , але нажаль предметну розмову можна зустріти дуже рідко.

[@hamsterua]

​​@@andriyloz7558усі пом'ятають оті часи коли код був змішаний із версткою і запитами у базу у рамках однієї сторінки. І php це промоутив як фічу. Хочя така дикуха буда у всіх: java - jsp, .net - aspx. Але там швидко зрозуміли що то хибний шлях. А php довго думав і заробив собі погану славу.

[@user-mk5vt5qz7s]

Насправда всі використвоєують SOA, але кажуть, що то мікросервіси.

[@hamsterua]

Мікросервіси то є правильний soa :)))

[@ua-rik]

Душнячий комент від мене: Новачок, про те що говорили автори геть нічого не зрозуміє. А інтермідіейт слухачеві - якось забавнально. Думаю варто визначитись з ЦА

[@hamsterua]

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