Является ли Pulumi таким волшебным по сравнению с использованием пакета SDK для Azure .NET?

У меня возникла дилемма относительно того, на каком сайте SE задать этот вопрос, поэтому, пожалуйста, помогите мне, если он должен быть где-то еще.

Я изучал решения «Инфраструктура как код».

Не слишком любил Terraform. Отсутствие intellisense делает обнаруживаемость труднее, чем привыкли программисты.

Я рассматривал шаблоны ARM. Мне нравится, что шаблоны становятся доступными по мере того, как мы создаем ресурсы на портале, но они кажутся менее читаемыми и их сложнее поддерживать в дальнейшем.

Потом я узнал о Pulumi и мне понравилась их идея по сравнению с Terraform. На мой взгляд, их подход также декларативен, как и вышеупомянутые варианты, но мы можем использовать достойные языки программирования для выполнения работы.

for петли - необходимость.

Круто, мне это нравится! Но поскольку нам нравится использовать C # (или другие альтернативы), почему бы нам не использовать SDK для управления нашей инфраструктурой как кодом?

Pulumi сравнил себя с облачными SKD, позиционируя свое решение как более безопасное, защищая что, если бы мы сами использовали облачный SDK, наше решение не было бы таким надежным.

Интересно, насколько это действительно так?

В прошлом году я написал несколько библиотек, которые использовали очереди / темы служебной шины Azure. Было несколько интеграционных тестов, которые выполнялись параллельно, и мне нужно было изолировать их, создав новые очереди / темы, и для этого использовал Microsoft.Azure.ServiceBus.Management.ManagementClient.

На самом деле мне вообще не нужно было чему-то учиться.

Теперь перейдем к делу. Не отказываясь от новаторства Пулуми, которое, на мой взгляд, здорово:

Действительно ли Pulumi добавит столько преимуществ по сравнению с использованием пакетов SDK для Azure?

Какой у вас был опыт с этим?


person Fabio Milheiro    schedule 04.06.2020    source источник


Ответы (1)


Разработчик Pulumi, так что я определенно предвзято. Я подозреваю, что сообщество SO может посчитать ваш вопрос нарушением некоторых рекомендаций, но я надеюсь, что мой ответ останется в живых :)

Одним из преимуществ использования Pulumi является то, что вы получаете доступ к нескольким поставщикам с постоянным опытом разработки. Возможно, вы используете исключительно Azure, но в какой-то момент вы можете начать комбинировать его с такими вещами, как создание и публикация образов Docker, развертывание приложений Kubernetes или информационных панелей Datadog. Все можно сделать с помощью одной и той же программы или решения.

Теперь самое большое отличие от императивных SDK - это понятие конфигурации с желаемым состоянием. Программа Pulumi описывает граф ресурсов и зависимости между ними (что), а не шаги по их предоставлению (как). Когда у вас есть среда, которая живет месяцами и годами, есть большая разница между развитием единого определения с помощью маленьких шагов и применением инкрементных изменений (Pulumi) и написанием набора скриптов / программ обновления для перевода каждой среды в новое состояние (SDK ).

Как поддерживать несколько сред, которые могут быть похожими, но все же разными? (производство против постановки против тестирования против разработки) Как вы убедитесь, что ваша недолговечная инфра, созданная для ночных тестов, отражает реальность производства? Что происходит, когда программа SDK выходит из строя посередине - можете ли вы снова запустить ее, или она создаст дублирующиеся ресурсы / выйдет из строя с другой ошибкой? Как получить простой обзор изменений в git с течением времени? Контроль параллелизма? Изменить историю?

Все вышеперечисленное встроено в Pulumi и требует ручного рассмотрения с помощью облачного SDK.

person Mikhail Shilkov    schedule 04.06.2020