Ну вылетела железка и ладно. Просто берётся запасная.
Даже комментировать это не буду.
Речь про то, что потеря одной (и более) железок вообще не должна сказываться на работе сервиса. Либо время частичного простоя измеряется долями-единицами секунд. Речь про такую систему.
Если в ТЗ есть требования по производительности, то это 1-2 шаги (иначе задача как раз таки еще считается не сделанной корректно).
Например, код должен укладываться в 100мс на 99м перцентиле. Ок. И если он работает за 110мс — это не выполненное задание.
Но после первого релиза можно, при наличии времени, оптимизировать до 50мс, и тем самым немного поднять метрики продукта. (Пример из более-менее реальной жизни).
Закладывание возможности ускорения (как и будущие итерации) я воспринимаю как закладывание возможности дальнейшего развития и доработок. Если код уже написан так плохо, что его уже нельзя поддерживать уже на таких ранних этапах, то тут все плохо, как бы быстро/медленно решение не работало.
А возможность развития — это ведь вообще основополагающее требование к коду (если речь опять же не про «олимпиадное программирование»).
Тоже "по молодости" ставил на performance-first, это казалось крутым. Но это требовало очень точного и зафиксированного описания задачи ("мамой клянусь, не поменяется до релиза ничего").
Вот только в реальной жизни это не так.
Единственное место, где реально такой подход применять, если хочется, — это всякие соревновательные контесты, типа отечественного highload cup или всякие примеры олимпиадного программирования.
В реальной жизни все очень быстро меняется, либо остаётся недосказанность и отсутствие конкретики в неучтенных краевых случаях. А чем больше система (и задание на нее), тем выше шанс не заметить/не учесть что-то.
И, если сразу делать эффективное решение, то потом будет очень больно его переделывать.
Так что много лет уже следую принципу:
Сначала сделать по т.з.;
Потом сделать корректно (тесты, ручные тесты, выдача early bird, и любые другие способы проверить логику и реализацию с обратной связью. Тут может всплыть огромное количество нюансов, которые сразу и правятся);
// Тут может произойти релиз, если нужно минимизировать time-to-market;
Потом сделать быстро там, где есть проблема. А для этого нужны бенчмарки решения целиком, чтобы видеть бутылочные горлышки;
// Вот тут уже релизим, если ещё нет.
В конце 2019 тоже общался с Лавкой. Суммарно 5 часов общения за ~пару недель. 3-4 задачи из этого поста были и у меня Но ещё были встречи про архитектуру и Одна «Сложная» Задача С Тестами, но я бы ту встречу отнес скорее к категории поговорить за жизнь.
что весь функционал обязан опираться исключительно на «invented here» библиотеки
Это больше к используемым нами БД, а не к (K)PHP.
Решения на Go и C/C++ тоже используют в основном «invented here библиотеки», потому что они очень заточены под эффективное решение именно наших задач.
20 минут на тостере и 20 минут на кластере — абсолютно разные вещи (и деньги).
Во первых, речь про весь пайплайн коммита от машины разработчика до работающего сервера в проде, а не только сборка. Обычно, конечно, код выезжает по расписанию, а не вот так вот «побыстрее».
Во вторых, самое медленное тут звено — компилятор C++ (даже в инкрементальном режиме), а далеко не kphp2cpp. Так что это время и железо, на котором gcc будет компилировать N миллионов строк кода. Можно попробовать собрать какие-нибудь проекты типа Chromium на тостере.
Мягко говоря, странно, что против продакшон-билда даже тесты не запустить, и разработки ведутся под значительно отличающиеся среды
Это можно воспринимать как преимущество качества реализации всехз особенностей php внутри kphp. Все настолько хорошо поддержано (либо оперативно правятся найденные corner case), что разработка на обычном php вполне подходит.
А вот руками, или обязательно при пуше, уже гоняются всевозможные тесты.
Так мы получаем и возможность быстрой разработки на php (и минусы языка, конечно), и плюсы kphp в итоге.
Это прямо сейчас, а судя по статье, на протяжении многих лет это было не так.
Про последние годы и речь. Смысл обсуждать что-то старое?
Но суть не в том, а в том, что монолит — показательный продукт той самой культуры, о которой я говорю
Той, что позволила ВК максимально быстро развиваться?
Это очень старая и распространенная дилема: можно или все делать по уму (и с большой вероятностью загнуться до популярности), или быть растущим проектом, который часть ресурсов тратит на техдолг.
Сколько вам понадобится времени, чтобы переписать, допустим, 6-7 миллионов строк продуктовой логики с PHP на тот же Go? Причем этот код постоянно меняется десятками разработчиков, а останавливать проект никто на год-другой не даст.
Тут вариантов остается два: выносить части в отдельные сервисы на произвольном ЯП (и такие работы у нас ведутся, но это оооочень долгий процесс для такой кодовой базы), и замена рантайма используемого ЯП.
Силы небольшой команды, занимающейся KPHP, экономят просто море ресурсов компании, и позволяют идти обоими вышеприведеными путями.
Путем создания целого нового языка, которому нужно еще и обучать?
Говорилось же, что язык максимально похож на обычный PHP уровня 7.3 — 7.4. Разработка вообще сидит на локальных апачах для тестирования нового кода.
Какой у вас там CI/CD медленный и кошмарный я боюсь представить.
Ну да, сборка и деплой на все тысячи серверов может занимать минут 20. Плохо?
К нам приходят люди с очень разным опытом; а задачи, которые они будут решать, так же зависят от опыта. Далеко не все в компании пишут на PHP, есть же еще как-минимум C/C++ и Go.
Так что «выходец из ВК» — это скорее человек, который умеет решать сложные и нетривиальные по нагрузкам и шардированию задачи, а не используемый при этом ЯП.
Понятно, что в случае решения задач основного web'а проекта, это задачи в основном на (K)PHP.
Так что проблема тут скорее — это жесткая привязка к нашим внутренним БД, а не ЯП.
Читал эту книжку, но не возникло такой сильной антипатии к автору. Я воспринимал это скорее как «дорожный роман» про человека без профильного опыта, который решил пожить Там. Что бы он там ни творил (а описал он много ситуаций), это было довольно интересно почитать (кроме части про техпрессу и Ad:Tech), не пытаясь подкопаться к его логике.
Основной сложностью будет правильно классифицировать строки изменений и выявить все их зависимости, не замедлив алгоритм до уровня full diff с двойным обходом кодовой базы.
Речь про то, что потеря одной (и более) железок вообще не должна сказываться на работе сервиса. Либо время частичного простоя измеряется долями-единицами секунд. Речь про такую систему.
Например, код должен укладываться в 100мс на 99м перцентиле. Ок. И если он работает за 110мс — это не выполненное задание.
Но после первого релиза можно, при наличии времени, оптимизировать до 50мс, и тем самым немного поднять метрики продукта. (Пример из более-менее реальной жизни).
Закладывание возможности ускорения (как и будущие итерации) я воспринимаю как закладывание возможности дальнейшего развития и доработок. Если код уже написан так плохо, что его уже нельзя поддерживать уже на таких ранних этапах, то тут все плохо, как бы быстро/медленно решение не работало.
А возможность развития — это ведь вообще основополагающее требование к коду (если речь опять же не про «олимпиадное программирование»).
Тоже "по молодости" ставил на performance-first, это казалось крутым. Но это требовало очень точного и зафиксированного описания задачи ("мамой клянусь, не поменяется до релиза ничего").
Вот только в реальной жизни это не так.
Единственное место, где реально такой подход применять, если хочется, — это всякие соревновательные контесты, типа отечественного highload cup или всякие примеры олимпиадного программирования.
В реальной жизни все очень быстро меняется, либо остаётся недосказанность и отсутствие конкретики в неучтенных краевых случаях. А чем больше система (и задание на нее), тем выше шанс не заметить/не учесть что-то.
И, если сразу делать эффективное решение, то потом будет очень больно его переделывать.
Так что много лет уже следую принципу:
// Тут может произойти релиз, если нужно минимизировать time-to-market;
// Вот тут уже релизим, если ещё нет.
Тоже когда-то подобное делал (разве что в формате C extension): https://github.com/AterCattus/unifiedphp/blob/master/README_ru.me
Наверное, это такой своеобразный "hello world", который пишет многие, кто сталкивался с PHP.
С управлением телеком уже не так зашло.
С новой колонкой один вопрос: куда теперь девать старую :)
Это больше к используемым нами БД, а не к (K)PHP.
Решения на Go и C/C++ тоже используют в основном «invented here библиотеки», потому что они очень заточены под эффективное решение именно наших задач.
Во первых, речь про весь пайплайн коммита от машины разработчика до работающего сервера в проде, а не только сборка. Обычно, конечно, код выезжает по расписанию, а не вот так вот «побыстрее».
Во вторых, самое медленное тут звено — компилятор C++ (даже в инкрементальном режиме), а далеко не kphp2cpp. Так что это время и железо, на котором gcc будет компилировать N миллионов строк кода. Можно попробовать собрать какие-нибудь проекты типа Chromium на тостере.
Это можно воспринимать как преимущество качества реализации всехз особенностей php внутри kphp. Все настолько хорошо поддержано (либо оперативно правятся найденные corner case), что разработка на обычном php вполне подходит.
А вот руками, или обязательно при пуше, уже гоняются всевозможные тесты.
Так мы получаем и возможность быстрой разработки на php (и минусы языка, конечно), и плюсы kphp в итоге.
Про последние годы и речь. Смысл обсуждать что-то старое?
Той, что позволила ВК максимально быстро развиваться?
Это очень старая и распространенная дилема: можно или все делать по уму (и с большой вероятностью загнуться до популярности), или быть растущим проектом, который часть ресурсов тратит на техдолг.
Тут вариантов остается два: выносить части в отдельные сервисы на произвольном ЯП (и такие работы у нас ведутся, но это оооочень долгий процесс для такой кодовой базы), и замена рантайма используемого ЯП.
Силы небольшой команды, занимающейся KPHP, экономят просто море ресурсов компании, и позволяют идти обоими вышеприведеными путями.
Говорилось же, что язык максимально похож на обычный PHP уровня 7.3 — 7.4. Разработка вообще сидит на локальных апачах для тестирования нового кода.
Ну да, сборка и деплой на все тысячи серверов может занимать минут 20. Плохо?
Так что «выходец из ВК» — это скорее человек, который умеет решать сложные и нетривиальные по нагрузкам и шардированию задачи, а не используемый при этом ЯП.
Понятно, что в случае решения задач основного web'а проекта, это задачи в основном на (K)PHP.
Так что проблема тут скорее — это жесткая привязка к нашим внутренним БД, а не ЯП.
На самом интересном закончилось. Подробностей бы.
:)