Download to read offline
Uploaded byFwdays
"Disposable-First Architecture: Build Fast, Kill Faster", Oleksandr Khomenko.pptx
How to design architecture for a product that already has a successful production environment, but where you still want to launch startup-like initiatives inside it? How do you avoid breaking a stable system, keep user trust, and at the same time give the business room for experiments?
"Disposable-First Architecture: Build Fast, Kill Faster", Oleksandr Khomenko.pptx
- 3.
- 4. План - Болючі кейси"важких фіч", що не прижились - Як перетворили бажання бізнесу "більше й швидше" на архітектуру - Успішний кейс швидких фіч: Таємні бокси в Expirenza - Проблеми після успіху "тимчасової" фічі - Зміна майндсету команди розробки
- 5. Expirenza - COREArchitecture
- 6. Expirenza - MoreEDGE features added
- 7. Expirenza - MoreEDGE features removed
- 9. На що впливаєстарий код - Його треба обслуговувати при подальших оновлень бібліотек - Збірки/CI довшають, тести ганяють зайвий код - Новачки його вчать - росте когнітивне навантаження
- 10. Чому б невидалити його тоді - Вдруг колись знадобиться - полежить на полочці - Розробників що то робили вже не знайти (а в історію гіта немає віри) - Висока зв язність - невідомо на що вплине ʼ
- 11. Та ми всезнаєм - Там оті мікросервіси треба заюзать - Метрик прикрутить щоб все бачить - Та флаги юзать щоб то виключать
- 12. Наскільки проблема відомасвіту by pendo.io
- 13. Наскільки проблема відомасвіту - 80% - фіч рідко/ніколи не юзають https://www.pendo.io/resources/the-2019-feature-adoption-report/ - 64% - історичний бенчмарк (спірний) https://www.mountaingoatsoftware.com/blog/are-64-of-features-really-rarely-or-never-used - ~⅓ - ідей дають приріст (Microsoft) https://exp-platform.com/Documents/2017-05-17EmetricsControlledExperimentsPitfallsKohaviNR.pdf
- 14. Disposable-First ● Core ≠Edge: експерименти живуть поза core; спілкування лише через контракти. ● Loose coupling: Edge знає про Core, Core знає про Edge мінімум. ● Метрики: time to learn, time to sunset, blast radius. ‑ ‑ ‑ ‑ ‑ ● Kill switch & фічефлаги ‑ ● MVP => MVE
- 15. Core ≠ Edge ●Ізоляція реалізації ● Односторонні залежності ● Різні SLO/SLA і процеси змін ● Життєвий цикл і дані
- 16. Loose coupling ● Односторонніконтракти ● Event Sourcing / Outbox ● Асинхронні інтеграції ● Нуль умов у Core про Edge
- 17. Метрики ● OEC: головнийкритерій (impact) ● Time-to-learn (TtL) ● Time-to-sunset (TtS) ● Дашборди
- 18. Kill-switch & фічефлаги ●Різне призначення ● Власники та SLA ● Безпечні дефолти й роздільні прапорці ● Телеметрія та clean-up
- 19. Kill-switch & фічефлаги ●Різне призначення ● Власники та SLA ● Безпечні дефолти й роздільні прапорці ● Телеметрія та clean-up
- 20. MVP => MVE ●Одна гіпотеза -> один OEC ● Ізоляція на Edge, без змін у Core ● Чітка одиниця рандомізації ● Два прапорці й kill-path
- 21.
- 22. Таємні бокси -Домовленість ● Мінімальна архітектура, не чіпаємо CORE фічі ● 1 спринт на реалізацію, 1 спринт на стабілізацію ● Можливість включення по містам ● Критерій успіху - 1000 продажів за 1 місяць в 1 місті ● Можливість швидко вбити фічу
- 23. Таємні бокси -EDGE Архітектура
- 24. Таємні бокси -Успіх ● 10 000 продажів за 25 днів ● > 30ти підключених закладів на старті ● Медіа привід
- 25. Таємні бокси -Де боліло ● Внутрішнє адміністрування ● Упущені едж кейзи ● Підтримка
- 26. Таємні бокси -Що робили після успіху ● Масштабування на інші міста (продуктово) ● Hardening інфри ● Нові фічі
- 27. Таємні бокси -Підсумки
- 28. питання є? 🤗 🎶Все, що я роблю, найфірмовіша фірма 😸
Editor's Notes
- #15 Ізоляція реалізації Edge — окремий мікросервіс/модуль із власною БД/схемою та деплоєм; жодних прямих джоїнів у core. Взаємодія — тільки через контракти (OpenAPI/AsyncAPI) або події. Односторонні залежності Core експонує стабільні інтерфейси, Edge споживає їх через ACL/BFF. Заборонено, щоб core залежав від edge; для edge обов’язковий kill-switch. Різні SLO/SLA і процеси змін Core: жорсткі SLO, контроль змін, мінімум релізного ризику. Edge: експерименти, фічефлаги/рамп-ап/TTL, швидкі релізи; помилка edge не ламає core. Життєвий цикл і дані Edge проєктується як тимчасовий: має EOL-план (deactivate → archive → delete), маркування даних source_feature, ретеншн. Core зберігає довгоживучі моделі та інваріанти.
- #16 Односторонні контракти Core публікує стабільні API + доменні події, Edge їх споживає через ACL/BFF. Жодних зворотних залежностей: contract-tests і версіонування схем гарантують сумісність. Event Sourcing / Outbox → проєкції на Edge Core фіксує істину як immutable події (event store або хоча б outbox). Edge будує свої read-model/projection й оновлюється асинхронно та ідемпотентно (eventual consistency). Асинхронні інтеграції, мінімум синхронщини Pub/Sub-топіки замість прямих викликів; DLQ, retries, backpressure на боці Edge. Якщо синхронно — то через фасад і з circuit breaker, щоб core не «знав» про конкретний Edge. Нуль умов у Core про Edge + легке EOL У Core нема if (edge_X); лише загальні точки розширення (події/вебхуки). Edge має kill-switch, власні дані/схему та EOL-план — його видалення не вимагає змін у Core.
- #17 OEC: головний критерій (impact) - Overall Evaluation Criteria Обираємо одну бізнес-метрику, за якою приймаємо рішення (решта — допоміжні). Варіанти Інкрементальний валовий прибуток / 1 000 експозицій (iGP/1k exp) Завершені замовлення / активний користувач (Orders/AU) — інкремент до контролю. Конверсія цільової дії (у%): view→add→pay — інкремент до контролю. Time-to-learn (TtL) — швидкість сигналу Визначення: час від старту експерименту до довіреного рішення (Scale / Iterate / Kill). Як міряти: дата_start_experiment → дата_decision_ready (MDE + power виконані, SRM зелений). Ціль: висока-трафік фічі — ≤ 7–14 днів, low-traffic — з варіанс-редукцією (CUPED) щоб не тягнутися місяцями. Time-to-sunset (TtS) — швидкість вимкнення Визначення: час від рішення «вимкнути» до повної зупинки трафіку й дренінгу черг. Як міряти: timestamp_decision → traffic==0 & queues==0 & alerts==green. SLA: Kill-switch ≤ 60 с (зупинка виконання), T+1h — черги/крони, T+14d — архів/clean-up коду. Blast-radius — контроль впливу Визначення: частка користувачів/транзакцій, яких може торкнутись помилка/відкат. Як міряти: частка активованого трафіку за варіантом/кільцем/гео + частка деградації (error/p95). Правило: стартувати 1–5%, далі 5→25→50%, поки guardrails стабільні; для edge-фіч ніколи не чіпати core-інваріанти. Операційка метрик — дашборди й алерти Обов’язково: панель TtL / TtS по кожній фічі, SRM-віджет, OEC + guardrails, графік blast-radius по колах rollout. Політика: рішення без готових TtL/TtS/blast-radius-даних — не приймаємо; OKR: знизити median TtL/TtS на X%, тримати стартовий blast-radius ≤ Y%.
- #18 Різне призначення Фічефлаги — керовані зміни (release/experiment/permission). Kill-switch — миттєва ізоляція ризику без деплою. Власники та SLA Фічефлаги: продакт/команда, поетапний rollout. Kill-switch: SRE/on-call, SLA вимкнення ≤ 60 с (код + інфра: endpoint/queues/WAF). Безпечні дефолти й роздільні прапорці Фічефлаги: таргетинг, аудит, TTL. Kill-switch: fail-closed (за замовчуванням вимкнено), локальні оверрайди. Одна платформа, різні ключі: release/experiment ≠ ops/kill. Телеметрія та clean-up Фічефлаги: exposure/конверсії. Kill-switch: traffic→0, errors↓, queues drained. Після EOL: прибрати флаги, архів даних, видалення коду.
- #19 Різне призначення Фічефлаги — керовані зміни (release/experiment/permission). Kill-switch — миттєва ізоляція ризику без деплою. Власники та SLA Фічефлаги: продакт/команда, поетапний rollout. Kill-switch: SRE/on-call, SLA вимкнення ≤ 60 с (код + інфра: endpoint/queues/WAF). Безпечні дефолти й роздільні прапорці Фічефлаги: таргетинг, аудит, TTL. Kill-switch: fail-closed (за замовчуванням вимкнено), локальні оверрайди. Одна платформа, різні ключі: release/experiment ≠ ops/kill. Телеметрія та clean-up Фічефлаги: exposure/конверсії. Kill-switch: traffic→0, errors↓, queues drained. Після EOL: прибрати флаги, архів даних, видалення коду.
- #20 minimum viable experiment (MVE) Одна гіпотеза → один OEC Формулюємо 1 перевірюване припущення і 1 головну метрику з порогом для рішення (Scale / Iterate / Kill). Усі інші метрики — діагностичні. Ізоляція на Edge, без змін у Core Фіча як окремий модуль/сервіс із власною БД/схемою; взаємодія тільки через контракти/події; жодних прямих джоїнів із Core до валідації. Чітка одиниця рандомізації Вибираємо рівень (user/account/store/geo), робимо sticky-призначення, фіксуємо момент exposure і логуємо його. Два прапорці й kill-path exp.<feature> — для експерименту (таргетинг/рамп-ап); ops.kill.<feature> — для миттєвого вимкнення (SLA ≤ 60 с). Шлях вимкнення: deactivate → drain queues → archive → cleanup. A minimum viable experiment (MVE) is an experiment designed to test the central premise of your business idea. The “minimal” part of MVE means it should test one (and only one) idea. A great MVE should… require minimal set-up, require minimal cost and materials, and ultimately help you determine whether you’ve got an idea worth pursuing further, or not.
- #27 Чи будемо далі? Так, із guardrails: OEC, SRM, kill-SLA Що сподобалось: TtL↓, ізоляція, blast-radius контроль Що змінюємо: сильніші контракти, auto-TTL флагам/даним Не всюди: core-інваріанти, low-traffic, високий рег-ризик Нотатка: підсумуй переваги (швидкість навчання, низький борг, керовані ризики) і чесно окресли межі застосування: коли потрібен класичний продукт-айтірейшн замість Disposable-First (критичні інваріанти, мало трафіку, жорсткі регуляції). Опиши наступні кроки: шаблон MVE, політика фічефлагів, регулярні deletion-sprints.