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

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

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

@DOU_youtube

Ай бұрын

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

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

@anatolijd

Ай бұрын

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

@anatolijd

Ай бұрын

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

@anatolijd

Ай бұрын

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

@ua-rik

28 күн бұрын

Плюсую

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

@DOU_youtube

Ай бұрын

ну ви💙

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

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

@DOU_youtube

Ай бұрын

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

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

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

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

29 күн бұрын

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

@YuriyYarosh

29 күн бұрын

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

@YuriyYarosh

29 күн бұрын

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

interesting video, thanks

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

@laxdna3030

Ай бұрын

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

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

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

Потрібні 🤌

@maksimbilous4060

Ай бұрын

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

@DOU_youtube

Ай бұрын

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

@eq716

Ай бұрын

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

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

@apprecode

Ай бұрын

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

@hamsterua

29 күн бұрын

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

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

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

@IMMORTALmen

27 күн бұрын

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

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

@determinism3221

Ай бұрын

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

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

@IMMORTALmen

Ай бұрын

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

@hamsterua

29 күн бұрын

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

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

@apprecode

Ай бұрын

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

@andriyloz7558

29 күн бұрын

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

@hamsterua

29 күн бұрын

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

serverless > microservices?

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

@hamsterua

29 күн бұрын

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

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

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