Чи не ускладнюємо ми розробку? Чи був шлях простіше? / Federated, Replicated, Microservices

Подробнее о видео

#devjungles #dotnet #QUARK
Federated, Replicated, Microservices


Telegram канал Dev Jungles -

Підтримати канал можливо за допомогою:
- Підписки на Patreon: patreon.com/user?u=79336362
- Спонсорства на YouTube
- Прямим переказом на карту монобанку
Dev Jungles YouTube Channel Fund


Номер карти банки:
5375 4112 0230 1466

- Або криптою:
BTC - 18C3jsFYwviN5FvzpAt4uMWRfUeVKvdWxy
ETH - 0x2903f63ba9009732272e91a299053b9d7b623216

USDT on ERC20 - 0x2903f63ba9009732272e91a299053b9d7b623216
USDT on TRC20 - TSmS5RzQKbWdxZkoM2oRo9HK8FYBaq744T

LTC - LN3CkrnvZLZTXDUhqTy1gUKMVpLjEPA4G2

DOGE - DPwon439jf3axVSBwyuXso6z7CivuJF655
AAVE - 0x2903f63ba9009732272e91a299053b9d7b623216
Waves - 3P8D57Zw7CrqW2o7dHpvZR2UzAzQRFA2kZd

На днях я готував лекцію про еволюцію архітектури програмного забезпечення.
Ну там де все починається зі звичайного додатку де і данні і рантайм і бізнес логіка в одному процесі живуть, а закінчив мікросервісною архітектурою з мікрофронтендами зі сторони клієнту, лоад балансером, бо всі сервіси підняті в багатьох інстансах. База данних реплікується, перед базою стоїть модний редіс, сервіси взаємодіють за допомогою gRPC, коли потрібна синхронна відповідь і за допомогою EventBus, коли потрібна асинхронна комунікація і слаба зв'язаність.
Досить нефігова така складність в решті решт виходить?
Для чого усе це було і чи був інший шлях? Чи є інший шлях?

Всім привіт. Мене звати Андрій Подколзін. Я автор каналу Dev Jungles, що сповнений величезних хардкорних мандрів скрізь технічні нюанси, але це рубрика Кварк, де я у більш розмовній манері ділюся думками на різні теми.

Отже. Зараз ми будуємо складні величезні системи, що тримають купу трафіку і потребують аптайму в 5, або навіть 6 дев'яток.

Тайм-коди:
00:00 - Про що відео
01:00 - Як ми до цього прийшли?
06:56 - Мережевий ефект
07:51 - Масштабування