Мнение ПК
Всем приходится переписывать и менять модули систем когда они перестают удовлетворять бизнес-требованиями. А что делать если систему нельзя оставить? Как принять разумный риск и прийти к успеху?
Про архитектуру
Доклад принят в программу конференции
Есть расхожая фраза: "Кто не рискует, тот не пьет шампанское!" Но вот в чем вопрос - где проходит та тонкая грань, за которой оправданный риск переходит в навязчивую идею, сметающую все на своем пути? Весной 21 года моя команда столкнулась с вызовом - уйти от старого процессинга во имя нового, который будет отвечать вызовам бизнеса - выше стабильность - SLA 99,99%, рост нагрузки в 5-10 раз, масштабируемость под новые бизнесы.
Конечно же был выбор между - рефакторить старое vs писать новое. А дальше: мы были молоды - верили в правило 80/20 и не учитывали, что просадка конверсии на 0,5% - блокер к переключению с одного компонента на другой.
Я хочу провести вместе с вами ретроспективный анализ и найти ответы на вопросы:
- Зачем вообще переписывать старое? Есть ли объективные причины?
- Как аккуратно подменить такой крупный, требовательный к доступности и нагруженный кусок системы как процессинг?
- На сколько можно недооценить ресурсы на такой проект и какие проблемы может принести в соседние команды разработки?
Цель моего доклада - не призыв к переписыванию и даже не демонстрация опыта, я хочу показать путь - цели и нюансы, которые могут вас сопровождать на маршруте: "Все сжечь и написать заново". Продемонстрировать на конкретном примере, почему "быстрый старт" != "быстрое внедрение". Доклад будет полезен всем, кто стоит на распутье по выбору технической стратегии развития архитектуры нагруженных и/или высокодоступных систем, а также тем, кто будет эти стратегии воплощать в жизнь.
Архитектор, более 15 лет стажа в IT, более 10 лет проектирования доменах: FinTech, GameDev, MedTech и транспорт.
Про архитектуру