Давно хотел написать на тему инфраструктурных платформ, но не доходили руки. Практически во всех компаниях, которые являются моими клиентами или где у меня есть знакомые, строят в том или ином виде внутреннюю платформу для разработки. И часто допускают одни и те же ошибки, о которых мы сегодня поговорим. Но сначала давайте разберемся, почему возникает потребность в этих самых платформах. С развитием DevOps культуры, появилось множество инструментов, позволяющих работать с инфраструктурой как кодом, а также разворачивать свои приложения и сервисы с помощью изменений ресурсов в git репозитории. И казалось, что достаточно просто настроить все эти инструменты, а дальше разработчики будут ими радостно и эффективно пользоваться. Но на практике оказалось, что все не так просто. Во-первых, разработчики не сильно захотели глубоко погружаться в мир Terraform и K8S, у них хватает пробелов и по своим основным инструментам разработки. Есть конечно исключения, но в целом среди разработчиков знания в этой области либо на нулевом либо на начальном уровне. Во-вторых, мир инфраструктурных инструментов развивается очень стремительно и разработчикам следить за ним параллельно со своим основным стеком очень сложно. Только ты научился использовать Helm с GitLab CI пайплайнами, как уже пора внедрять Argo CD или Flux CD. :) В-третьих, обучение в масштабе больших компаний - это очень медленно и дорого. А при большой текучке кадров, еще и постоянная нагрузка, которую нереально закрыть дополнительными активностями во время процедуры онбординга. Поэтому большая часть компаний приходит к идее создания внутренней инфраструктурной платформы, которая бы предоставляла командам разработки близкий к PaaS (platform as a service) или FaaS (function as a service) опыт. А отдельные платформенные команды занимались бы ее разработкой и развитием. Тогда от разработчика требовалось бы куда меньше знаний и усилий для решения типовых задач. На этом этапе появляются типовые ошибки. Первая из них в том, что инфраструктурная платформа не рассматривается как полноценный продукт с внешними стейкхолдерами в лице команд разработки. Цели, бэклог задач и приоритеты поступают не от команд разработки. Вместо этого, она развивается на усмотрение платформенных команд, в отрыве от реальных потребностей разработчиков. Получается для конечных пользователей криво и неудобно, но зато внутри "модно и молодёжно". Вторая ошибка в том, что платформа часто не проектируется изначально как self-service и оставляет в ежедневных активностях зависимость на платформенную команду. А это приводит к тому, что при росте использования платформы, растет нагрузка на ее поддержку в платформенной команде. Причем, зачастую растет нелинейно, так как уже совершена первая ошибка и для многих решений приходится вставлять костыли на ходу. Ну а дальше прямая дорога к конфронтации в стиле "мы-вы" между командами разработки и платформенными командами. Третья ошибка в том, что для платформы не продумываются метрики эффективности применения. В результате, разные люди видят разные цели существования платформы. Одни уверены, что она для экономичного использования ресурсов. А другие параллельно считают, что главная цель - это сокращение релизного цикла. Зачастую эти цели вступают в противоречие, а это дает очень плодородную почву для бюрократии и игры чье видение победит. Я недавно наткнулся на интересный тред в Twitter, который очень сильно совпадает с моим видением и опытом в данной области. В комментариях можно найти много полезных ссылок и мнений. Надеюсь, в вашей компании не повторят описанных ошибок и инфраструктурная платформа получится действительно полезной и эффективной!