Опрошенные порталом The New Stack эксперты обсуждают целесообразность внедрения в компании собственной платформы разработки приложений.

Компьютерные тенденции часто похожи на игру типа «следуй за лидером». Если Google, Microsoft или другая гигантская технологическая компания делает что-то, не должны ли и мы делать это? Иногда эта логика работает. Инженерия надежности систем (SRE) возникла, например, из практики Google и одноименной книги. Впоследствии роль SRE получила широкое распространение в технических командах во всех отраслях.

Раз уж речь пошла о надежности, то хаос-инженерия началась как внутренний инструмент и практика в Netflix; сейчас это набор кодифицированных принципов, инструментов с открытым исходным кодом и коммерческих инструментов, используемых все более широким кругом предприятий.

Подобная картина сегодня наблюдается с внутренними платформами для разработчиков (internal developer platform, IDP). IDP, которые изначально были прерогативой веб-гигантов и других крупных компаний, предоставляющие разработчикам широкие возможности самообслуживания для быстрого создания различных сред и других необходимых им ресурсов, завоевывают популярность у все большего числа команд разработчиков ПО.

Это не просто тенденция следования за лидером. Скорее, IDP являются естественным попутным продуктом масштабного роста облака и экосистемы облачных сред, а также соответствующего развития DevOps и DevSecOps, конвейеров CI/CD и других современных инструментов и дисциплин. В отчете Puppet «Состояние DevOps в 2020 году» использование платформ самообслуживания даже названо общей характеристикой высокоэффективных команд.

«Современная разработка требует информации из множества различных областей, таких как качество, гигиена, безопасность, лицензирование не только вашего стороннего кода, но и кода сторонних разработчиков, — считает Брайан Фокс, главный технический директор Sonatype. — Единственный разумный способ увеличить масштаб — это систематический подход, который позволяет интегрировать соответствующий инструментарий в процесс разработки таким образом, чтобы добиться большего единообразия во всех проектах».

Затраты vs. выгоды

Для все большего числа организаций таким систематическим подходом является внутренняя платформа для разработчиков. IDP имеют различные другие названия, такие как платформа самообслуживания и платформа Kubernetes. При любом названии они, по сути, объединяют практически все, что нужно командам разработчиков организации, в одном месте.

Если вы создаете контейнерные приложения, угадайте, где разработчики найдут утвержденные реестры контейнеров? В IDP. То же самое касается новых сред. Нужна новая тестовая среда или песочница? Разработчики могут быстро создать ее для себя — никакой подготовки в течение нескольких дней, недель или, для некоторых особенно болезненных унаследованных процессов, месяцев. Платформенный подход позволяет сделать это и многое другое в рамках определенных параметров, обычно устанавливаемых с помощью экспертов в DevOps или Ops, безопасности и других областях.

«Рассматривая конвейеры разработки как платформу, вы добиваетесь согласованности и полноты анализа в масштабе», — говорит Фокс.

IDP обычно внедряются «там, где есть острая необходимость в повышении производительности и автономности разработчиков, что позволяет значительно сократить время разработки новых функций для услуг и продуктов», — отмечает Рагху Кишор Вемпати, директор по инновациям Capgemini Engineering.

Эти платформы, казалось бы, должны продаваться сами собой, учитывая нынешний бешеный темп разработки ПО. Но IDP не обязательно подходят для каждой команды или организации. Это может быть связано со значительными накладными расходами на запуск, а также с последующим развитием и обслуживанием платформы. В результате их, естественно, предпочитают крупные организации, особенно те, которые имеют сложные, гетерогенные среды.

Анализ затрат и выгод можно свести к простому вопросу: что IDP позволит нам сделать завтра, чего мы не можем сделать сегодня? Если ваш ответ стоит больше, чем начальные и текущие затраты на IDP, то вам, вероятно, следует серьезно задуматься.

Что касается накладных расходов, то они начинаются с самой платформы: вы должны ее построить.

Хотя это и спорно, но классическая дилемма «построить или купить» не обязательно применима в данном случае. Пурист может сказать вам, что «настоящая» IDP создается внутри компании, с нуля, даже если в ее конструкции, скорее всего, используются такие ключевые компоненты, как Kubernetes с открытым исходным кодом. Коммерческая PaaS — это именно то, что нужно, и это приемлемый вариант для многих команд, но в «коробочном» виде это еще не IDP.

Для создания собственной платформы требуется своя инженерная команда. Даже в самых небольших масштабах вам потребуется хотя бы один инженер по разработке платформы. По словам COO Weaveworks Стива Джорджа, модель IDP обычно подразумевает создание отдельной команды разработчиков платформы, в которую входят несколько инженеров не из команд разработчиков или DevOps. Она требует постоянных инвестиций в людей, а не только в технологии.

Подходит ли вашей организации IDP, должен определить анализ затрат и выгод. Для этого задайте следующие шесть вопросов. Чем чаще вы будете отвечать «да», «это мы» и т. п., тем больше вероятность того, что инвестиции окупятся.

1. Готова ли ваша инфраструктура?

IDP следует рассматривать не только в ракурсе «затраты-выгоды». Это также вопрос «телеги перед лошадью»: если вы работаете со «скрипучей» инфраструктурой и процессами, которые требуют обновления, то вы, вероятно, не готовы к внедрению IDP.

По словам Брайана Сатианатана, директора по технологиям компании Iterate.ai, вопрос инфраструктуры — это то, с чего следует начинать организациям при оценке целесообразности использования IDP.

«Первое: модернизирована ли ваша инфраструктура? Работаете ли вы с облачным стеком? Если у вас есть значительные устаревшие элементы в вашем конвейере развертывания, то вам придется проделать больше работы, чтобы добраться даже до стартовой линии IDP», — полагает он.

2. Достаточно ли много у вас разработчиков?

Это немного грубый вопрос, но он очень важен: как много в вашей организации разработчиков? В смысле: настолько много, что у вас есть несколько отдельных команд разработчиков или DevOps, каждая со своими потребностями, кодовыми базами, требованиями к инфраструктуре и т. д.?

По словам Сатьянатана, IDP имеет смысл, когда «в вашей организации достаточно большая база разработчиков, чтобы справиться с различными требованиями, разными языками, кодовыми базами и инфраструктурными потребностями».

Здесь нет магического порога, которого нужно достичь. Но по мере роста числа разработчиков и/или команд разработчиков в вашей организации, вероятность того, что они получат пользу от IDP, обычно также возрастает. Одна, относительно небольшая команда, которая может стандартизировать одни и те же языки, инструменты и т. д., может не воспользоваться преимуществами платформы.

3. Насколько хорошо работают ваши процессы сборки-развертывания?

Внедрение IDP должно быть эволюционным этапом для команды, которая уже работает на максимуме возможностей. В контексте DevOps или DevSecOps это иногда называют зрелостью.

По словам Сатьянатана, если у вас много известных и, возможно, неизвестных узких мест в конвейере доставки ПО, то лучше сначала их устранить и внести улучшения. IDP может на порядок повысить скорость и частоту развертывания, но сама по себе она не решит проблемы нарушенных процессов или культуры.

4. Насколько автономны ваши команды разработчиков?

Автономность разработчиков — одно из наиболее часто упоминаемых преимуществ подхода IDP. Природа самообслуживания заключается в том, чтобы облегчить и поощрить автономию, но с некоторыми ограничениями, чтобы обеспечить надежную и безопасную работу, а также не нарушить бюджет.

«Необходимо хорошо понимать, принесет ли самообслуживание значительные преимущества или лишь частные, и понимать, смогут ли преимущества перевесить затраты или нет», — говорит Сатианатан.

Другая версия этого вопроса звучит так: «Какую степень автономии мы хотим предоставить нашим командам разработчиков?» Если ответ не «большую!» или близок к этому, подумайте, почему вы рассматриваете IDP. Одна из причин, по которой она может хорошо подойти для команды DevOps, заключается в том, что доверие, необходимое для автономии, уже должно присутствовать.

5. Насколько хорошо работает ваше управление операционной деятельностью?

Это еще один вопрос о том, как не получить телегу перед лошадью. Если ваш ответ на этот вопрос звучит примерно так: «наше что?», то, возможно, вы еще не готовы к IDP.

Самообслуживание — это не синоним «делать все, что нам заблагорассудится». Где-то должны быть ограждения, и если ваша текущая модель управления ИТ похожа на город золотоискателей на Диком Западе, то, возможно, вам стоит приостановить проект IDP.

«У вас централизованная модель? Если нет, и разные части предприятия делают разные вещи, то такое управление необходимо исправить, прежде чем приступать к реализации стратегии IDP», — советует Сатианатан.

6. Насколько важны ваши SLA?

Допустим, большинство организаций могут ответить «они имеют большое значение». Но задавая этот вопрос о SLA, Вемпати имеет в виду компании, для которых высокая доступность и отказоустойчивость являются первоочередными задачами, или аналогичные высокие ставки, например, в сфере общественного здравоохранения или безопасности.

Если скорость также является фундаментальным вопросом, таким, где важны секунды, то IDP также может быть полезна. Вемпати приводит примеры более конкретных вариантов этого вопроса:

  • имеет ли наша компания дело с предоставлением услуг клиентам, внутренним или внешним, которые требуют быстрого времени выполнения?
  • является ли наша компания партнером нескольких крупных организаций, для которых время выполнения функций и устранения ошибок должно быть значительно меньше, чем у нас?
  • существуют ли SLA, требующие высокой доступности и отказоустойчивости?

«Чем на большее количество этих вопросов вы ответите утвердительно, — говорит Вемпати, — тем больше будет убедительных аргументов в пользу IDP».