Потери при недоработках планирования. Часть 1. В этой сек | noTieinIT - Об IT без галстуков
Потери при недоработках планирования. Часть 1.
В этой секции у меня речь о технической стороне пойдет. Потери при подобных недоработках или неверном векторе влияют меньше чем фундаментальные ошибки в требованиях.
Как-то мне достался продукт, который должен был работать с live видео: принимать потоки, транскодировать их в несколько качеств, отдавать пользователям. Одним словом - была работа с realtime. Ответственные лица приняли решение разрабатывать эту часть платформы на базе PHP и успешно полтора года пилили проект. Ну как пилили… Первые 9 месяцев что-то напилили, а остальные 9 месяцев пытались перемотать изолентой весь продукт дабы он не рассыпался. Product Manager хотел двигаться быстрее, перейти к следующим этапам, но все время команды только и выжирал технических долг. Так до меня дошел запрос вмешаться в процесс и разобраться что там творится, принять меры.
После плотной интеграции в продукт, пришли к выводу, что вообще выбран некорректно весь технологический стек и PHP плохо подходит по ряду причин:
Этот язык через пень-колоду поддерживает работу с асинхронностью, а система должна была обслуживать live видео, где множество процессинга и асинхронных событий. PHP обеспечивает меньшую пропускную способность и провоцирует большое количество затрат времени.
Он ориентирован на работу со stateless запросами: запрос поступил, скрипты обработки запустились, запрос выполнился и скрипты умерли. Сохранение состояния потоков между стартом-смертью скриптов возможно лишь посредством постоянной сериализации/десериализации данных и сохранения в базы данных или кэши. Это тоже перетрата.
Запустить процесс другой программы и его контролировать попросту невозможно без запуска сотен процессов, которые еще и блокируются ожидая input/output. Про phpDaemon и т.п. можете не писать, это та еще дрянь если с ней работать плотно.
При выполнении каждого запроса тратится 50-100ms только на бутстратпинг скрипта, ну и фреймворков заодно, если они есть.
После анализа приняли решение переписывать на другом языке.
Какие затраты? Команда из 6-8 человек полтора года двигалась не туда и это $300-400k слитых в унитаз и потеря как конкурентного преимущества за это время, так и потенциальной прибыли.
А теперь представьте, что у вас на проекте кто-то так факапнулся концептуально и все эти сражения с архитектурой, недоспанные ночи, постоянные баги и их латания - это всего лишь следствия халатности на проработке и потенциально весь отдел могут уволить не из-за их результатов, а ошибки лица принимавшего решение писать на этом стеке?
Welcome to real life, bro.
