Чи потрібні вам мікросервіси? - DOU DevOps Podcast #11
Вставка
- Опубліковано 14 тра 2024
- 🗓 Приєднатися на вебінар "Магія 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 Налаштування та оптимізація перформансу
Як кажуть «Такий великий, а досі віриш у мікросервіси»
дуже цікава бесіда, робіть ще, дякую
Мед! Мед на мої вуха! Аааа! Дякую вам! Супер! Те, що треба👍 трохи б раніше, то я мав би більше волосся, але ж і так супер! ви прекрасні 👍
нікнейм просто 🔥
Якось все дуже максимально загально і абстрактно. "може бути добре а може не бути".
Мікросервіси - це відповідь на зростання складності аплікацій (монолітних), головним чином на складність їх масштабування для hi-load i hi-availability.
Було б чудово як би ви обговорили кілька різних прикладів з власного досвіду, типу
- розробка нової аплікації на мікросервісах. Як поділили на мікросервіси, чи є відчуття недоцільної складності з точки зору operations. А з точи зору Dev ?
І теж висновок - що є доцільно а що - ні. Що б тепер зробили по-ішому якби починали спочатку.
В вас же всіх є купа такого досвіду, і в кожного свій специфічний і при цьому ви в одній студії.
Архітектор (який вирішує бузнес-задачу) аргументує доцільність по-своєму, dev (який пише весь той код і дебажить його) - по-своєму, devops(відповідальний за deploy і support ) - по-своєму.
Можна вас попросити дещо ? :)
Мені, як глядачу, було б набагато цікавіше і зрозуміліше якби ви ілюстрували обговорення реальними прикладами.
І вам теж було б простіше, бо обговорювати реальні кейси легше ніж загально-абстрактні.
Плюсую
Супер контент! Дайте ще
дуже файний випуск вийшов :)
Дякуємо, це дуже приємно чути!
Дякую за топовий і файний контент українською! Вподобайка та коментар в підтримку просування відео ❤
ну ви💙
ви називаєте це відео подкастом, але на жодній платформі я його не знайшов
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для того щоб "зменьшити кодову базу" треба застосовувати будь які засоби кодогенерації та перетворення інтерфейсів, й мікросервіси до цього не мають ніякого відношення. Масштабування "окремих частинок" виконуються не за споживаною оперативною пам'яттю та процесорним часом, а за кількістю запитів в секунду (там Knative-serving / Keda тощо) й відповідні значення на залежить на скільки й як саме розділився той чи інший сервіc. А от узгодженість в кінцевому рахунку (eventual consistency) граничних кореневих сутностей (ID користувача тощо), з наявністю великої кількості сервісів, значно зменьшує їх доступність.
@@hamsteruaдля того щоб "зменьшити час компіляції" варто зробити її інкрементальною (bazel там якийсь, наприклад), й навчитись там в монорепозиторії (turborepo тощо)... залежить від цільової мови програмування та відповідного BuildOps/TestOps оточення.
Денис - сила :)
Срібної кулі нема, Everything is a tradeoff!
Срібна куля - це відсутність коду взагалі. Нема коду - нема багів.
32:55 це називається "Закон Конвея". Спеціалісти)
interesting video, thanks
Потрібні 🤌
Ех, чувак, якась в тебе однобока думка ))
Чи ні? (байт на дискусію)
@@DOU_youtubeгоризонтальне масштабування відміняється? будемо масшатувати прямо монолітами? або можна платити AWS, мати все на serverless і казати, шо у нас не має жодного мікросервісу.
Якісь питання про логування, якщо ми у кубері чи не відповідальність це кубера закинути мої логи куди треба?
Так, можна і апликейшен левел логування зробити(і ми так робемо) але здається краще через кубер.
Ну і це відповідальність архітектор/ліда написати реквайрементм по логуванню, якщо деви не того
чим вам kubectl не вгодив). Чому б і не юзати pure manifest або kustomize? HELM дуже хороша штука, але у кожної тулзи завжди є свої слабкі сторони
Pure наніфест має проблему перевикористання та кастомізації. Так можна кастомайз, але він на виході робить той же простий великий ямл файл. Також є проблема з видаленням ресурсів. Потрібно вручну видаляти після того як видалили в себе в ямл файлі і також нема версійності та ролберу. Так це можна частково виправити з гітопс, але для цього його треба онборднути в кластер та й самому з ним розібратися.
Можна використовувати helm як шаблонізатор тільки. На заміну уродського kustomize .
А далі helm to file abd kubectl apply
Але є проблема видалення сервісів. Дуже рідко але є
Образливий вислів від архітектора - для тих хто вперше зайшов в інтернет, типу всі такі розумні і з народження знають усі ті розумні слова що він видав ротом
Сіріуслі ображатись на ці слова?
Не існує людини яка б все знала і яка б була експертом у всьому, завжди є чому вчитись і якщо в процесі навчання ображатись на конкретні слова( які навіть не є образливими ), то буде дуже важко.
Тригером є архітектор що не зміг пояснити що таке мікросервіс, і зразу вправ в роздуми про базу і api gateway. Why?
Вибачте, але як він це замовнику продає?
28:10 Якщо лямбди - це мікросервіси, то по тому ж принципу можна вважати що кожна хранима процедура в базі яка викликається тріггером та щось із даними робить - є мікровервісом)))
Наносервіс)!
Не пам'ятаю ніодного випадку щоб щось змінювалось при переїзді на мікросервіси, який би великий проект не був. Багато коду - проблеми пхп і інших. Багато бдшок - проблеми дж і інших(можливо). Бенефіт лише в швидкості деплоя бачу, все. Навіть мітингів не збільшувалось.
Upd: мова програмування Ruby on Rails
А звідки ви взяли, що при змінах в мікросервісі відпаде щось одне, а от у моноліті все одразу? Постійно чую цю думку.
Ви знаєте про схеми БД? Створіть нову схему для свого додатку, вони повністю ізольовані. А видалити/зламати все можна і дистанційно і в мікросервісній архітектурі, це від коду залежить. Що складного в тому, щоб ізолювати ваш додаток у моноліті? Це робиться елементарно.
Згоден із Денисом. Сказав приблизно те саме після.
дивне ім'я - Всещеденис
serverless > microservices?
Блін, коли ви рнр останній раз бачили, певно ще в минулому столітті?
Вчора, нажаль :(
@@apprecode Цікавості заради, хотілося б дізнатись що з php, на Вашу думку, не так. Дуже часто доводиться чути що з пхп є повне г... , але нажаль предметну розмову можна зустріти дуже рідко.
@@andriyloz7558усі пом'ятають оті часи коли код був змішаний із версткою і запитами у базу у рамках однієї сторінки.
І php це промоутив як фічу.
Хочя така дикуха буда у всіх: java - jsp, .net - aspx. Але там швидко зрозуміли що то хибний шлях. А php довго думав і заробив собі погану славу.
Душнячий комент від мене:
Новачок, про те що говорили автори геть нічого не зрозуміє. А інтермідіейт слухачеві - якось забавнально.
Думаю варто визначитись з ЦА
Насправда всі використвоєують SOA, але кажуть, що то мікросервіси.
Мікросервіси то є правильний soa :)))
Вибачте, але роздуми девопсів про архітектуру - таке собі.
Ну і девопс має бути частиною команди, а не просто виділеним адміном, чи не так? А то виходить що це просто адмін який вміє скриптувати тероформ?
Я і сам можу його скриптувати.