The post has been translated automatically. Original language: Russian
In recent years, the DevOps industry has been actively discussing whether Terraform has remained an indispensable tool or whether it's time to switch to something more modern. CDKs, Pulumi, OpenTofu, stacks, wrappers — it seems that infrastructure tools like code (IaC) are multiplying faster than we have time to master them. Let's try to figure out why Terraform is needed today, what its strengths and weaknesses are, and in which cases it makes sense to look towards alternatives.
Why is Terraform still the "king"?
Despite the emergence of competitors, Terraform remains the de facto standard in many companies. And there are reasons for that.:
- HCL's simple and intuitive syntax: easy to learn, easy to read.
- Strong documentation and a huge community.
- Support for all major clouds and a huge number of providers.
- Availability of state files: the key to consistent infrastructure management.
- Integration with CI/CD processes, GitOps, and teams of any maturity.
Even if you're not a Terraform fan, there's a good chance you'll have to support it—especially on projects with a history.
Terraform starts to “creak” when the infrastructure becomes really large and multilevel.:
- There is no built-in support for multiregionality and multienvironment.
- Managing dependencies between parts of the infrastructure is inconvenient.
- State files without an external backend (S3, GCS, etc.) are a pain.
- It is difficult to share resources between teams without Enterprise solutions.
In an attempt to circumvent these limitations, additional tools are emerging: terragrunt, OpenTofu, stacks, and even our own custom wrappers.
Perhaps the most popular vrapper. He:
- Allows you to divide the infrastructure into independent stack blocks.
- Provides dependency management between states.
- Parallels execution, if possible.
- Simplifies configuration work in multi-environment mode.
But it also has disadvantages — it adds a new YAML layer, requires training, and has its own debugging features.
They were initially positioned as the answer to Terragrunt, but…
- Implemented only in Terraform Cloud/Enterprise, and not available in open source.
- They support a limited number of cases, and are often incompatible with existing configs.
- They require a separate CLI utility for signing manifests.
Opinions in the industry are divided: some find them useful, while others consider them a “crude solution with a good idea.”
The Terraform fork that appeared after the HashiCorp license change. In practice:
- It's more a political project than a technical one.
- It is being developed by large companies whose business depends on an open-source solution.
- So far, there is not a single killer feature worth migrating from Terraform for.
These tools have their own philosophy: “infrastructure as code” means exactly the code, in a full—fledged language (TypeScript, Python, Go, etc.).
Positive:
- You can use familiar data structures, loops, and conditions.
- They are better suited for developers than DevOps engineers.
Minuses:
- Steep learning curve for ops teams.
- Difficulties with typing (especially in CDK).
- Not all clouds and resources are supported on par with Terraform.
Many teams, having tried the CDK, then return to Terraform due to the inability to easily delegate maintenance to DevOps engineers.
The tool is just a reflection of the processes. Even the most beautiful stack won't save you if:
- The infrastructure is not divided into logical modules.
- There is no version control or audit trails.
- Everyone writes to a single state file.
- There are no automated tests (for example, via terraform validate or tfsec).
Therefore, before choosing between Terraform, CDK or something else, ask yourself: What processes do we have?
Terraform is not perfect. But it's simple, powerful, and mature. It works great in 80% of cases, and the rest can be covered using Terragrunt or your own tooling. CDK and Pulumi are interesting, but not always practical. OpenTofu is still more of a philosophy than a tool.
In the end, the winner is not the one with the more fashionable tooling, but the one with the processes built, pipelines and infrastructure debugged — like code, not like chaos.
В последние годы DevOps-индустрия активно обсуждает, остался ли Terraform незаменимым инструментом или пора переходить на что-то более современное. CDK, Pulumi, OpenTofu, стеки, wrapper’ы — кажется, инструменты инфраструктуры как код (IaC) плодятся быстрее, чем мы успеваем их осваивать. Попробуем разобраться: зачем нужен Terraform сегодня, какие у него есть сильные и слабые стороны, и в каких случаях имеет смысл посмотреть в сторону альтернатив.
Почему Terraform по-прежнему "король"?
Несмотря на появление конкурентов, Terraform остаётся де-факто стандартом во многих компаниях. И на то есть причины:
- Простой и понятный синтаксис HCL: легко выучить, легко читать.
- Сильная документация и огромное комьюнити.
- Поддержка всех основных облаков и огромного количества провайдеров.
- Наличие state-файлов: ключ к консистентному управлению инфраструктурой.
- Интеграция с процессами CI/CD, GitOps и командами любой зрелости.
Даже если вы не фанат Terraform, велик шанс, что вам придётся его поддерживать — особенно на проектах с историей.
Terraform начинает “скрипеть”, когда инфраструктура становится действительно большой и многоуровневой:
- Нет встроенной поддержки многорегиональности и мультиэнвайронментов.
- Управление зависимостями между частями инфраструктуры неудобно.
- State-файлы без внешнего backend’а (S3, GCS, и т.д.) — боль.
- Сложно делить ресурсы между командами без Enterprise-решений.
В попытках обойти эти ограничения появляются дополнительные инструменты: terragrunt, OpenTofu, stacks и даже собственные кастомные врапперы.
Пожалуй, самый популярный враппер. Он:
- Позволяет делить инфраструктуру на независимые стековые блоки.
- Обеспечивает управление зависимостями между стейтами.
- Параллелит выполнение, если возможно.
- Упрощает работу с конфигурацией в мультиэнвайронмент-режиме.
Но у него есть и минусы — добавляет новый YAML-слой, требует обучения, имеет свои особенности дебага.
Изначально позиционировались как ответ Terragrunt’у, но…
- Реализованы только в Terraform Cloud / Enterprise, и не доступны в open source.
- Поддерживают ограниченное количество кейсов, часто несовместимы с существующими конфигами.
- Требуют отдельную CLI-утилиту для подписания манифестов.
Мнения в индустрии разделились: кто-то находит их полезными, а кто-то считает “сырым решением с хорошей идеей”.
Форк Terraform, появившийся после смены лицензии HashiCorp. На практике:
- Больше политический проект, чем технический.
- Развивается крупными компаниями, чей бизнес зависит от open-source-решения.
- Пока нет ни одной killer-фичи, ради которой стоит мигрировать с Terraform.
У этих инструментов есть своя философия: “инфраструктура как код” — значит именно код, на полноценном языке (TypeScript, Python, Go и др.).
Плюсы:
- Можно использовать привычные структуры данных, циклы, условия.
- Лучше подходят разработчикам, чем DevOps-инженерам.
Минусы:
- Крутая кривая обучения для ops-команд.
- Сложности с типизацией (особенно в CDK).
- Не все облака и ресурсы поддерживаются наравне с Terraform.
Многие команды, попробовав CDK, потом возвращаются на Terraform — из-за невозможности легко делегировать сопровождение DevOps-инженерам.
Инструмент — это лишь отражение процессов. Даже самый красивый стек не спасёт, если:
- Инфраструктура не разбита на логические модули.
- Нет контроля версий и аудит-трейлов.
- Все пишут в один стейт-файл.
- Нет автоматических тестов (например, через terraform validate или tfsec).
Поэтому перед тем как выбирать между Terraform, CDK или чем-то ещё — спросите себя: А какие у нас процессы?
Terraform — не идеален. Но он простой, мощный и зрелый. Он отлично работает в 80% кейсов, а остальные можно покрыть с помощью Terragrunt или собственного tooling’а. CDK и Pulumi интересны, но не всегда практичны. OpenTofu — пока скорее философия, чем инструмент.
В конечном счёте, выигрывает не тот, у кого моднее тулинг, а тот, у кого выстроены процессы, отлажены пайплайны и инфраструктура — как код, а не как хаос.
Share
