Облачные абстракции избавляют нас от необходимости снова и снова внедрять одни и те же шаблоны. Они смещают фокус нашего внимания с системы на продукт, пишет на портале The New Stack Рак Сива, вице-президент Nitric по инжинирингу.
Облачная разработка развивается стремительно, привнося все больше сервисов, конфигурационных файлов и сложностей. В ответ на это появилось новое поколение облачных абстракций, основанных на намерениях и ориентированных на разработчиков, чтобы упростить процесс создания облачных решений. Эти фреймворки позволяют вам на высоком уровне объявить, что вам нужно, и управляют обеспечением всего этого.
Тем не менее многие облачные разработчики и инженерные руководители не решаются использовать эти абстракции. Почему? Часто это связано со страхом потерять контроль и к прошлым опытом с «дырявыми» инструментами, проблемам с производительностью, стремлению придерживаться своей зоны комфорта или синдрому неприятия чужих разработок (Not Invented Here, NIH).
Осторожность — это естественно. В конце концов, мы потратили годы на освоение инструментов «инфраструктуры как кода» (Infrastructure as Code, IaC), таких как Terraform, CloudFormation низкоуровневые SDK и YAML, чтобы иметь полный контроль. Передача контроля уровню автоматизации может показаться рискованным шагом.
Часто мы обсуждаем преимущества абстракции, не признавая и не рассматривая страхи и риски. Давайте разберемся с некоторыми из наиболее распространенных страхов, связанных с облачной абстракцией.
1. Страх потерять контроль
«Если я не настраиваю каждый ресурс самостоятельно, то действительно ли я контролирую ситуацию?».
Это распространенное опасение при переходе от низкоуровневых Terraform или CloudFormation к инструментам более высокого уровня. Традиционная IaC дает вам контроль над (почти) каждой кнопкой, но вместе с этим приходит гора сложностей. Настоящий страх связан не с контролем, а с прозрачностью. Инженеры беспокоятся, что абстракция скроет важные детали, из-за чего инфраструктуре будет сложнее доверять или отлаживать.
Но хорошая абстракция не отнимает контроль; напротив, она переносит внимание на те вещи, которые имеют значение. Вместо того чтобы вручную разрабатывать каждую отдельную политику IAM, вы выражаете то, что нужно приложению, а фреймворк обрабатывает «клей».
Возьмем простой пример с использованием Nitric:
В этом небольшом фрагменте достаточно информации, чтобы мы знали, как настроить конечную точку API, ведро хранения, разрешения, маршрутизацию и вычисления. Хотя контроль скрыт, он все же есть, потому что вы можете переопределить Terraform, используемый для генерации результирующей IaC, не касаясь кода приложения.
Например, допустим, вы смотрите на этот код, и ваш первый вопрос: «Как настроить таймауты шлюза API?». Моим встречным вопросом будет: «Как часто вы меняете эту настройку в проекте?». Если ответ будет «часто», то абстракция должна быть способна поднять эту настройку до конфигурации приложения или конфигурации. Однако если ответ «редко/никогда», то более уместным будет использование этой настройки по умолчанию в модуле.
Именно так выглядит «настоящий» контроль: принятие важных решений, автоматизация шаблонов и возможность настраивать базовую инфраструктуру только в случае необходимости.
2. Прошлый опыт работы с негерметичными абстракциями
У многих из нас остались шрамы от прошлых попыток абстрагирования, которые прошли не так гладко. Возможно, вы пробовали PaaS или новый модный фреймворк, который обещал справиться со всем, но когда что-то пошло не так, вам все равно пришлось копаться в слоях сложности. Это классическая проблема «негерметичной абстракции».
«Все нетривиальные абстракции в той или иной степени негерметичны»,
— Джоэл Спольски, генеральный директор и соучредитель Stack Overflow.
Ни одна абстракция не является идеальной, и в конечном итоге при масштабировании и в крайних случаях некоторые из базовых деталей будут просачиваться сквозь нее. Для облачных разработчиков это проявляется в тех болезненных моментах, когда ваш высокоуровневый инструмент не поддерживает определенную конфигурацию или выдает непрозрачную ошибку, и вы вынуждены устранять неполадки в сырой инфраструктуре вслепую. Неудивительно, что люди относятся к этому настороженно.
Однако важно понимать, почему ранние абстракции давали сбои и как современные подходы решают эту проблему. Многие облачные абстракции первого поколения (вспомните ранние бессерверные фреймворки или слишком упрощенные конструкторы облаков с графическим интерфейсом) были, по сути, тонкими обертками для облачных API. Как только вы выходили за пределы счастливого пути, вы натыкались на стену.
Современные платформы, ориентированные на разработчиков, извлекли уроки. Они, как правило, имеют открытый исходный код и прозрачны. Как правило, вы можете проверить, что делает абстракция под капотом. Например, абстракция может сгенерировать конфигурацию Terraform (через Terraform CDK), которую вы можете экспортировать и просмотреть при необходимости. Это означает, что если что-то ведет себя не так, как ожидалось, вы не отлаживаете «черный ящик»; вы можете увидеть промежуточную IaC, созданную фреймворком. Это огромное улучшение доверия.
Хорошие абстракции обеспечивают аварийные люки и точки расширения (как мы видели выше с переопределением модулей). Цель состоит в том, чтобы, когда абстракция не поддерживает напрямую крайний случай, вы могли расширить ее, а не отказываться от нее. Иначе обстоит дело с негерметичной абстракцией, которая вынуждает вас полностью нарушать абстракцию (например, вручную исправлять что-то за пределами инструмента). Благодаря возможности расширения или внедрения пользовательской логики абстракция сама по себе не «ломается» новыми требованиями; она «изгибается», чтобы приспособиться к ним.
3. Синдром NIH
Синдром Not Invented Here — это не столько технический, сколько культурный страх. Инженерные команды, особенно очень способные, часто считают, что их потребности уникальны и что они могут создать превосходное решение своими силами, а не использовать внешнюю абстракцию или платформу. Вы можете услышать мнение вроде: «Зачем использовать этот фреймворк? Мы можем просто написать все это сами и идеально адаптировать к нашей среде». Или: «Мы не хотим зависеть от внешнего инструмента, давайте создадим собственную облегченную версию». Это инстинкт создания собственного инструмента, проистекающий из гордости, контроля или иногда скепсиса по поводу того, что общий инструмент может подойти для вашего особого случая.
«Многие компании страдают от синдрома NIH, придумывая собственные решения вместо того, чтобы выбрать инструмент стороннего производителя»,
— Никита Проценко, Netflix.
Хотя подход «сделай сам» может быть полезен в некоторых действительно уникальных сценариях, чаще всего он приводит к повторному изобретению колес и трате времени на решение решенных проблем. Такая тенденция может завести команды в ловушку бесконечного обслуживания внутренних инструментов, которые никогда не будут доработаны или документированы. Если ваши разработчики тратят месяцы на создание внутреннего фреймворка развертывания, то эти месяцы они не занимаются реализацией бизнес-функций.
«Перестаньте тратить деньги (и время) на недифференцирующую тяжелую работу»,
— Вернер Фогельс, Amazon.
Когда речь заходит об облачной инфраструктуре, подумайте о ключевых компетенциях вашей команды. Действительно ли написание и поддержка внутренней облачной платформы является отличительной чертой вашего бизнеса? Если вы являетесь облачным провайдером или продаете инструменты для разработчиков, то возможно. В противном случае, скорее всего, нет. Для большинства продуктовых компаний отличительной чертой является приложение или услуга, которую они предлагают, а не скрипты, написанные на заказ для ее развертывания.
Так зачем вкладывать в это большие усилия, если можно использовать существующий фреймворк и вернуться к созданию функций продукта? Использование абстракции, особенно с открытым исходным кодом, также означает, что вы получаете выгоду от сообщества пользователей. Ошибки находят и исправляют другие, новые функции добавляют участники, и вы можете нанять инженеров, которые уже знакомы с этим инструментом. В случае с собственным внутренним инструментом вы несете все бремя в одиночку.
Чтобы было понятно, NIH — это не значит слепое непринятие любого готового инструмента. Вы все равно должны оценить зрелость и сообщество решения. Если абстракция удовлетворяет
«Я предпочитаю, чтобы другие люди решали мои проблемы за меня»,
— Линус Торвальдс, создатель и ведущий разработчик ядра Linux.
Заключение: примите абстракцию, чтобы получить рычаги влияния
Думайте об абстракции как о рычаге воздействия. Как языки программирования высокого уровня и библиотеки позволяют нам добиваться большего с меньшим количеством строк кода, так и облачные абстракции позволяют нам добиваться большего с меньшим количеством YAML и скриптов. Они освобождают нас от необходимости снова и снова реализовывать одни и те же шаблоны. Они смещают фокус нашего внимания с системы на продукт.
Когда вам больше не нужно беспокоиться о том, какую ручку повернуть, чтобы включить интеграцию, или как отформатировать политику IAM, вы можете направить эту умственную энергию на инновации в своей области. В результате команды работают быстрее, внедряют более уверенно и испытывают меньше головной боли по поводу того, что «это работает только на моей машине», поскольку платформа заботится о согласованности в разных средах.
