Про поддержку: делала одна команда, для переезда мы делали автоматические скрипты, которые большинство рутинных задач переезда покрывали. Далее нужно было овнеру сервиса провалидировать, пройти тесты и перейти на новые рельсы.
Про ресурсоемкость: в разное время было разное количество, на старте было всего несколько инженеров, далее уже команда росла до десятков инженеров.
Backstage был на раннем этапе развития, совсем не популярен, поэтому тогда даже не рассматривали. Плюс мы недавно ресерчили его возможности и применимость: к сожалению всё еще очень базовый фреймворк, который сильного ускорения, на наш взгляд, не даёт. Что важно: не закладывает каких-то явных ограничений на построение платформы, скорее общий layout и component ownership система с возможностью писать свои плагины-экраны, вместе с этим еще решая проблемы производительности (пробовали туда наш набор сущностей загрузить).
Про метрики: по прокси метрикам: количеству релизов, времени на все фазы, которые идут вне машины разработчика. Базовые DORA метрики. Плюс смотрели, например, TTM подключения базы и подобных "выколотых" кейсов, где мы видели проблемы (например, неделя на настройку). Далее это просто масштабировали на компанию и value как метрика adoption.
Привет. По поводу production, там сейчас движемся в сторону внедрения своего решения, которое работает очень схожим образом с Istio, но работает значительно эффективнее из-за отсутствия многих возможностей и немного изменённой архитектуры (discovery по требованию). В следующей статье на эту тему поделимся этим решением и расскажем подробнее почему все же написали свое.
По нашим замерам он дает примерно 5 процентов оверхеда по cpu от потребления самого приложения. По оперативной памяти — каждый envoy потребляет объем, пропорциональный количеству endpoints в кластере. На больших кластерах в несколько тысяч endpoint'ов получается достаточно много, примерно 300МБ.
По latency запросов изменения минимальны, в пределах 5мс.
Про поддержку: делала одна команда, для переезда мы делали автоматические скрипты, которые большинство рутинных задач переезда покрывали. Далее нужно было овнеру сервиса провалидировать, пройти тесты и перейти на новые рельсы.
Про ресурсоемкость: в разное время было разное количество, на старте было всего несколько инженеров, далее уже команда росла до десятков инженеров.
Backstage был на раннем этапе развития, совсем не популярен, поэтому тогда даже не рассматривали. Плюс мы недавно ресерчили его возможности и применимость: к сожалению всё еще очень базовый фреймворк, который сильного ускорения, на наш взгляд, не даёт. Что важно: не закладывает каких-то явных ограничений на построение платформы, скорее общий layout и component ownership система с возможностью писать свои плагины-экраны, вместе с этим еще решая проблемы производительности (пробовали туда наш набор сущностей загрузить).
Про метрики: по прокси метрикам: количеству релизов, времени на все фазы, которые идут вне машины разработчика. Базовые DORA метрики. Плюс смотрели, например, TTM подключения базы и подобных "выколотых" кейсов, где мы видели проблемы (например, неделя на настройку). Далее это просто масштабировали на компанию и value как метрика adoption.
в течение месяца как раз выпустим новую статью на тему PaaS и там покроем в том числе тему внешнего развития
Привет. По поводу production, там сейчас движемся в сторону внедрения своего решения, которое работает очень схожим образом с Istio, но работает значительно эффективнее из-за отсутствия многих возможностей и немного изменённой архитектуры (discovery по требованию). В следующей статье на эту тему поделимся этим решением и расскажем подробнее почему все же написали свое.
По latency запросов изменения минимальны, в пределах 5мс.