Венкат Тирувенгадам, генеральный директор и основатель компании DuploCloud, проводит на портале The New Stack сравнение двух распространенных подходов к управлению облачной инфраструктурой.

Первый подход — это то, что мы в целом классифицируем как инфраструктура как код (IaC), когда инженеры используют языки программирования/скриптинга для создания набора скриптов для достижения желаемой топологии на облачной платформе. Terraform, Cloud Formation, Chef, Puppet и Ansible — вот некоторые из наиболее популярных инструментов.

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

Второй подход — это облачный оркестратор, или платформа. Обычно это тонкая абстракция над нативными облачными API, которая взаимодействует с пользователем как веб-сервис, а пользователь подключается к сервису (через UI или API) и строит топологию облака в самом веб-сервисе.

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

Для небольших сценариев использования платформа может оказаться слишком тяжелой. Но с ростом масштаба подход IaC имеет тенденцию превращаться во внутреннюю платформу. В этом случае лучшей стратегией является использование готовой платформы, которую можно усовершенствовать с помощью скриптов IaC, если требуется кастомизация. (Мегамасштабные дата-центры — это совсем другое дело, и в данном контексте они не рассматриваются.)

Долгосрочный контекст

Фундаментальная ценность, которую обеспечивает подход на основе платформы, — это то, что мы называем «долгосрочным контекстом». Люди также могут называть это «проектом» или «арендатором» («tenant»). Контекст может быть связан, например, с приложением или средой, например, демонстрационной, тестовой, производственной или песочницей разработчика. При внесении обновлений в топологию пользователь всегда действует в этом контексте. Платформа сохраняет обновления в собственной базе данных в этом контексте, прежде чем применить их в облаке. Короче говоря, вам всегда гарантировано, что то, что присутствует в этой базе, будет применено к облаку.

В подходе IaC такой контекст не предоставляется изначально и остается на усмотрение пользователя. Обычно это означает необходимость ответа на вопрос, «какие скрипты должны быть запущены для какого контекста?», или, возможно, папку в кодовой базе, которая содержит конфигурацию для данного арендатора или проекта. Определить контекст как набор кода сложнее, поскольку многие скрипты могут быть общими для всех арендаторов. Поэтому, скорее всего, все сводится к пониманию разработчиками кодовой базы.

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

Разница между кодовой базой и тем, что применяется в облаке

Второе фундаментальное различие между этими двумя подходами заключается в том, что IaC — это многошаговый процесс (написать скрипт, запустить его и слить в репозиторий), в то время как платформа — это одношаговый процесс (войти в контекст и внести изменения). При использовании IaC допускается, что пользователь может обновить сценарий, но при этом забыть или отложить его сохранение в репозитории. Тем временем другой инженер может внести изменения в кодовую базу для своей части топологии и объединить их. Тогда, поскольку многие части кода являются общими для двух сценариев использования, первый разработчик может оказаться в конфликтной ситуации, которая, даже если он разрешит ее путем слияния кода, приведет к тому, что запущенное в облаке не соответствует тому, что находится в репозитории. И разработчику придется заново запускать слитый код для проверки, несмотря на возможность возникновения регрессии. Чтобы избежать этого риска, необходимо протестировать скрипт в среде QA.

Все «другие» вещи

Инструменты IaC обеспечат развертывание, но для работы инфраструктуры для облачного ПО нужно еще очень многое. Нужен механизм предоставления приложений, способ сбора и разделения журналов и метрик для каждого приложения, мониторинга состояния и оповещения, создания аудиторского следа, а также система аутентификации для управления доступом пользователей к инфраструктуре. Для решения этих отдельных проблем существует несколько инструментов, но их необходимо сшить вместе и интегрировать в контекст приложения. Kubernetes, Splunk, CloudWatch, Signalfx, Sentry, Elk и Oauth — все это примеры таких инструментов. Но разработчику нужна целостная «платформа», чтобы объединить все это вместе, если он хочет работать в разумных масштабах. Это подводит нас к следующему пункту.

Во многом IaC — это, по сути, доморощенная облачная платформа

В разговоре со многими инженерами мы слышим аргумент, что IaC в сочетании с bash-скриптами даже с кодом обычных языков программирования, таких как Go, Java и Python, предоставляет все необходимые хуки для преодоления вышеуказанных проблем. Конечно, я с этим согласен. С кодом такого рода вы можете построить все, что угодно. Однако, возможно, вы будете строить такую же платформу, которая уже существует. Почему бы не начать с существующей платформы и не добавить кастомизацию с помощью скриптов?

Второй аргумент, который я слышу, заключается в том, что подход IаС более гибкий и позволяет глубокую кастомизацию, в то время как с платформой вам, возможно, придется ждать, пока ее поставщик обеспечит такую же поддержку. Я думаю, что раз уж мы достигли уровня развития технологий, когда автомобили стали самоуправляемыми (а ведь когда-то это считалось не более чем чистой фантазией!), платформы являются гораздо более продвинутыми, чем им приписывают, и имеют отличные технологии машинного генерирования, способные удовлетворить большинство, если не все, сценарии использования.

Кроме того, хорошая платформа не будет препятствовать пользователю кастомизировать ту часть, которая выходит за рамки ее собственных возможностей, с помощью скриптовых инструментов. Хорошо спроектированная платформа должна предоставлять правильные хуки для потребления скриптов, написанных за пределами самой платформы. Следовательно, этот аргумент не оправдывает создание кодовой базы для большинства стандартных задач.

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

Разнообразие аргументов

Несколько неожиданным аргументом в пользу создания собственных платформ является то, что это просто очень крутой проект для инженера — особенно если этот инженер имеет системное образование.

Зачастую инженеры по инфраструктуре демонстрируют сильнее стремление к созданию платформ внутри компании, и они совершенно уверены, что создают именно «платформы» для своих организаций, а не занимаются «скриптингом». Для таких компаний кастомизация является общим аргументом против готовых инструментов, в то время как гибридное облако и онпремис являются важными сценариями использования. Поскольку open source-компоненты, такие как Kubernetes, Consul и т. д., широко распространены, я часто слышу утверждение, что не нужно изобретать велосипед. Тем не менее, размер команды и время, выделяемое на решение, значительны. В некоторых случаях концентрация на создании платформы затмевает основной бизнес-продукт, который компания должна продавать.

Между тем, инженерный талант в компаниях, создающих ПО исключительно как сервисные приложения, охватывает полный стек. В их приложениях используется так много нативного облачного ПО — S3, Dynamo, Amazon Simple Queue Service (SQS), Amazon Simple Notification Service (SNS) — что трудно быть гибридным. Они с удовольствием отдают контейнер через API или UI для развертывания в Amazon Elastic Container Service (Amazon ECS). Они не находят удовольствия ни в развертывании, ни в изучении Kubernetes. Следовательно, тенденция и глубина внутренней кастомизации гораздо меньше.

Сколько раз и сколько людей будут писать один и тот же код для достижения одной и той же цели? Время выхода на рынок в конечном итоге поставит все на свои места.