Привет, Хабр! Мы только что получили из типографии топовую DevOps-новинку этого года — книгу Камиль Фурнье и Иэна Ноуленда «Инжиниринг платформ: техническое и управленческое руководство». Промокод для читателей Хабра (скидка 32%) - fournier. Она продолжает и конкретизирует тему облачного развёртывания и дальнейшей поддержки приложений любой сложности, на которую мы ранее перевели отличную книгу Кифа Морриса «Программирование инфраструктуры» и сейчас обновляем её до 3-го издания (готовый перевод ожидается до конца года, затем пойдёт редактура). Также у нас в работе есть для вас книга «Terraform Cookbook» — за сроками выхода следите в разделе «Скоро!» у нас на сайте. Под катом же предлагаем вам перевод статьи, которую Камиль Фурнье написала около года назад, подробно изложив в ней, зачем и о чём она пишет книгу «Инжиниринг платформ», и какое место эта книга займёт на полке умелого девопса.
Читатели некоторого возраста и с определённым бэкграундом, возможно, припоминают CFEngine — это была одна из первых популярных систем для управления конфигурацией (и она до сих пор в ходу!). Такая система — это мощный инструмент, при помощи которого админы могут управлять конфигурацией системы, охватывающей разнородные кластеры машин. С ней мы вкатились в новую эру автоматизированного управления конфигурацией, этот метод я считаю ключевым компонентом современных технологических экосистем. Мне доводилось как работать в командах, отвечавших за инфраструктуру cfengine, так и управлять ими, и я на собственном опыте убедилась, насколько ценно уметь справляться с такими системами, насколько это нетривиальная задача. Но я также знаю, с какими ограничениями приходится сталкиваться, если подходить к инжинирингу платформ с таких позиций.
Управление конфигурацией, предоставление инфраструктуры и её дальнейшая оркестрация — чертовски сложная проблема в любой организации. В эту сферу направлено много инноваций — от достижений в области программирования инфраструктуры, таких как Terraform, до платформ для оркестрации контейнеров – типичным примером такого рода является Kubernetes. Проблема поддержки неоднородных сред, в особенности по мере их усложнения сразу во многих измерениях — бесконечна. Представьте, например, что в облаке должны лежать наготове все те компоненты, которые понадобятся вам для развёртывания приложения с использованием множества сетевых сервисов. Пожалуй, мы уже переросли cfengine, но во многих современных командах, занимающихся инжинирингом платформ, акцент делается именно на этой части стека. Поэтому команде становится проще выбрать подходящий чертёж/архетип, чтобы предоставить именно те ресурсы, которые необходимы для выполнения конкретного приложения.
Я пришла к мысли, что эта практика ведёт нас куда-то не туда, особенно, когда на её реализации сосредоточены основные силы команды, которая занята поддержкой платформы. Предлагаю пойти другим путём, который кажется мне более логичным:
Terraform никуда не годится. Особенно в компании, которая занята миграцией из традиционного ЦОД в облако. В таком случае обычно первым делом поручают команде каждого приложения написать в Terraform файл, в котором будет указано всё, что необходимо предоставить. Вы увидите, как много, оказывается, времени тратит команда, чтобы очертить круг этих вещей. И самое интересное — у большинства команд этот список один и тот же! Почему же тогда не поступить немного рациональнее, не централизовать эту писанину в Terraform, не сформулировать паттерны, которыми могла бы воспользоваться каждая команда. Логично ведь, правда? Там мы быстро выходим на «день 0» (дата первичного развёртывания).
Затем начинаешь задумываться — в самом деле, а ведь можно сконфигурировать и много чего ещё! Например, наблюдаемость, для организации которой нужно настроить соответствующие процедуры журналирования и оповещения. Можно позволить команде указывать необходимый для работы уровень доступности, а также предоставлять команде множество зон или регионов. Всё это очень хорошо и полезно; команды, отвечающие за приложения, могут качественнее их развёртывать. Так почему бы не придерживаться этого пути?
(иногда) Пусть Terraform и никуда не годится, и его явно хочется централизовать, неправильно было бы и полностью скрывать его от команд, обслуживающих приложения — это слишком серьёзное ограничение. Так что не будем этого делать: код, генерируемый по нашим чертежам, прекрасно складывается в репозитории, к которому будет доступ у всех команд по поддержке приложений, и любая команда сможет откорректировать свою копию кода так, как сочтёт нужным. Мы хотим помогать, а не ограничивать.
Можно долго (если не сказать — вечно) выстраивать систему таким образом; действительно, попробуй поспевать за всеми изменениями предложений у облачных провайдеров и за потребностями команд, разрабатывающих приложения. Так почему бы не избрать такой подход? Это не так глупо, причём, многие команды в этом подходе заметно преуспели. Но он опирается на ряд допущений, которые иногда проговариваются, а иногда нет.
Допущение #1: Притом, что в затребованной разными командами инфраструктуре может прослеживаться достаточное сходство, чтобы мы могли создавать такие «чертежи» и эффективно ими пользоваться, отсутствуют какие-либо более качественные абстракции, при помощи которых можно было бы представить такие группы приложений по признаку их сходства. Мы (команда, отвечающая за эксплуатацию платформы) действительно не хотим иметь в продакшне много (да и вообще не хотим) такого софта, которым пользуются команды разработчиков приложений на любых этапах кроме, собственно, развёртывания. Такой подход вынуждает нас при работе двигаться по критическому пути, а мы не уверены, что его вывезем.
Допущение #2: Облачный провайдер управляет всеми базовыми системами платформы таким образом, что почти не вмешивается в работу команд по разработке приложений, и эти команды могут полагаться на себя или своих SRE, чтобы самостоятельно управлять всем, чем занимаются. Мы можем прийти на помощь, если потребуется отладка, но не хотим брать на себя часть ответственности по критической поддержке приложения в продакшне.
Допущение #3: самое серьёзное узкое место в зоне ответственности команд по разработке приложений, которое мы можем устранить — это обеспечить им доступ к стеку, который необходимо предоставить их приложению для нормальной эксплуатации в облаке. Когда только начинаешь переходить к работе с облаком, это кажется совершенно очевидным — ведь вся команда пытается разобраться, как и что тут делается. Лишь немногие занимаются, собственно, эксплуатацией полезных приложений в облаке.
Теперь, когда я экстраполировала эти допущения, вы понимаете, к чему я клоню. Если вы согласны со всем вышесказанным – желаю вам самого лучшего! Возможно, именно выбранный вами подход наиболее верен для вашей организации! Но есть ряд серьёзных ограничений, проистекающих из приведённых выше допущений.
Ограничение #1: мы не хотим постоянно быть на подхвате и участвовать в операционной работе, поэтому не хотим писать софт, который нам придётся эксплуатировать — особенно по пути, критически важном для продакшна.
Строго говоря, уклонение от операционной деятельности — не лучшая идея для инженеров, занимающихся поддержкой платформы. Важность этой команды зачастую соизмерима с тем, какую часть нагрузки она способна снять с плеч команд, разрабатывающих приложения. Если же вы от этого отмежёвываетесь, то подрываете собственную ценность. Когда режут бюджет, от команд, отвечающих за «развитие» избавляются гораздо раньше, чем от тех, кто занят обслуживанием критических систем. Первые воспринимаются как опциональные, а вторые — как незаменимые.
Понятно, что порой команды разработчиков приложений не желают, чтобы вы встревали в их налаженные процессы, особенно в случае, когда толку от вас при этом будет не много. Но очень сложно быть наполовину ответственным и наполовину безответственным за владение продуктом, когда именно вы — эксперты во всех аспектах конфигурирования и предоставления инфраструктуры. Это искусство сложно освоить, если глубоко не знать базовую инфраструктуру именно с эксплуатационной точки зрения. Таким образом, вы наверняка понадобитесь при инцидентах, чтобы быстро разобраться в том, что происходит, и выполнить отладку. Если же команда разработчиков приложений действительно разбирается в этих вещах настолько хорошо, что не нуждается в вас… то какая польза им будет от обращения к вашим чертежам? Может быть, вы помогли им поднять всю систему в самом начале работы, а теперь вы лишь осложняете их экспертам жизнь, вынуждая их переформулировать предложенные вами определения в свою систему понятий. Им удобнее самим чувствовать, что они контролируют всё происходящее.
Если команда разработчиков приложений желает всем владеть сама — пусть так и будет. Те, кто отвечает за работу, вынуждены делать её хорошо, а те, кто не обязан — хотя бы будут чётче взвешивать соотношение полезности и затрат на случай, если владение системы будет полностью поручено им.
Что касается всех прочих, скажу следующее: если вам удастся найти чертежи, достаточно напоминающие вашу систему, то можно подумать о том, удастся ли вам построить такую платформу, на которой ваши коллеги смогут развернуть свои приложения, так, чтобы вам не пришлось поддерживать за них всю конфигурацию. Честно говоря, это непросто. Существует соблазн просто попробовать написать «свой корпоративный Heroku» — и известно множество провальных попыток такого рода. В то же время, если целесообразно выполнить некий кусок работы, чтобы стали сочетаться ранее разрозненные части системы, и чтобы типичная группа приложений могла быть с лёгкостью развёрнута в облаке — то, пожалуй, это задача именно для моих читателей. Возможно, вам нужна тонкая прослойка софта, в которую укладывается Kubernetes, развёрнутый прямо в компании, плюс какие-то специфичные контроллеры, и всё это интегрировано с корпоративными разрешениями и FinOps. В такой конфигурации ваша команда разработчиков приложений может сформулировать гораздо более простое подмножество конфигурационных параметров и развёртывать свои приложения на этой платформе. Задайтесь вопросом: что вы могли бы такое написать и поддерживать, что результативно избавило команду разработчиков от необходимости самим иметь дело с большей частью инфраструктурного стека и изучать его?
Важно отметить, что всё это может не касаться маленькой компании, которой лучше подобрать несколько облачных платформ и использовать их напрямую, так как их провайдеры уже напрямую предоставляют всё, что этой компании нужно (такой набор может включать Heroku, Vercel, AppEngine, т.д.). На самом деле, я бы не советовала уделять много времени разработчиков на создание вашей собственной платформы, если уже есть готовые «из коробки» предложения от вендоров, обеспечивающие всё, что вам нужно! Но это может быть целесообразно в более крупных компаниях, достигших определённого уровня сложности и пишущих какое-то количество (не очень много) собственного софта, отвечающего именно специфичным нуждам компании и отчасти скрывающего от разработчиков приложений подлинную сложность голого облака.
Ограничение #2: в сущности, мы не хотим писать собственный софт
Наша заказная платформа с Kubernetes — как раз из тех попадавшихся мне реальных платформ, которые на моих глазах сначала строила, а затем эксплуатировала команда по инжинирингу платформ. Она работает, так как под Kubernetes можно писать собственный код, модифицирующий поведение платформы. Притом, что это нетривиальная работа, заниматься которой приходится не так часто, бывает очень полезно просто взять мощную универсальную систему и сосредоточить её на конкретных юзкейсах, которые вы затем сможете предлагать как услугу.
Можно рассуждать и так: определённо, если эта штука реально полезна — её успеет написать кто-то другой, либо облачный провайдер просто нам это предложит как сервис. Поэтому нам, в сущности, незачем писать такой софт самим. Но есть огромная разница между двумя ситуациями: 1) выстроить платформу, которая настолько всесторонне полезна, что её можно просто продавать компаниям самых разных типов, и она будет удовлетворять их очень несхожим юзкейсам (это очень, очень сложно) и 2) выстроить что-то полезное внутри очень специфического окружения. В частности, интеграция общеполезных компонентов с нюансами вашей компании (а такие нюансы могут касаться идентичности/уполномочивания, корпоративной иерархии/биллинговых кодов отделов, других подобных сугубо корпоративных деталей) — как раз тот уровень, на котором можно очень результативно сбалансировать аспекты «пишем ровно столько кода, сколько нужно» и «создаём ценную платформу».
Ограничение #3: мы не хотим становиться узким местом
Идея чертежей привлекательна тем, что в ней как бы есть аварийный люк: всё, что осуществимо в Terraform, можно хотя бы теоретически считать «корректным». Поэтому команда разработчиков приложений вправе разобраться в значительной части облачных аспектов самостоятельно, и вы не должны как-то ограничивать их в этом. Просто проложите им ровные дорожки, следуя по которым, им будет проще использовать определённые паттерны. Я очень за то, чтобы предоставлять командам право на осознанный подбор инструментов, так, чтобы вы не ограничивали инновационный потенциал компании тем, на что сейчас способны ваши платформы.
К сожалению, оставляя широкий спектр возможностей на выбор, мы вынуждены мириться и со всеми недостатками этого разнообразия. В начале работы возможность выбирать всегда привлекательна, и со временем начинает вас сковывать, поскольку каждый оговоренный выбор приходится неопределённо долго поддерживать. Если вы постоянно разрешаете вашей команде выбирать, что именно они хотят, то попадаете в так называемое «наше общее болото». На каждый конкретный выбор требуется писать свою долю склеивающего кода (отдельно для интеграции, автоматизации, конфигурации, т.д.). Притом, что такой клей пишется быстро, менять его непросто.
Подходить к платформе как к продукту — это не значит всем угодить и всегда выстраивать ровно то, что у вас попросили сделать. Важно уделить время и разобраться, из-за чего именно ваши команды по разработке приложений работают менее эффективно, чем хотелось бы, а также взять на себя ту тяжёлую работу, от которой вы реально можете их избавить. Иногда самое сложное — выступать в качестве куратора и выбирать, что будет поддерживаться, а что — нет, пусть даже каким-то нишевым группам это и не понравится. Любой продакт-менеджер вам подтвердит, что это большой стресс – нести бремя стратегического планирования и делать ставки, которые не всегда оправдываются.
Продукты, а не скрипты
В заключение скажу, что грамотно построенный инжиниринг платформ далеко не сводится к управлению конфигурацией и предоставлению инфраструктуры. Это сложная работа по выявлению, выстраиванию и использованию абстракций, позволяющих командам по разработке приложений тратить меньше времени на работу с технологической базой платформы, а на решение конкретных бизнес-задач — больше. Вместо того, чтобы размышлять, как бы обеспечить скриптами и автоматизировать бесконечные вариации, подумайте о создаваемых вами продуктах, которые вписываются в наиболее распространённые архетипы, а не просто закрывают потребности по предоставлению и развёртыванию инфраструктуры.