📊 А что с классическим Jenkins?
Несмотря на всё вышесказанное, Jenkins всё ещё жив и активно используется. Взглянем на цифры за 2024 год (stats.jenkins.io):
📌 Активные jobs: 82 000 000+
📌 Подключенные nodes: 1 000 000+
📌 Коммиты: 51 000+
📌 Релизы: 13 LTS, 50 Weekly
📌 Pull Requests: 6000+
📌 GitHub Stars: 23 000+
📌 Контрибьюторы: 3000+
📌 Компании-использователи: 39 000+
Как видите, Jenkins по-прежнему используется в крупных компаниях, включая FAANG по следующим причинам:
🔹 Гибкость и мощность — он остаётся универсальным инструментом для действительно сложных пайплайнов. Кастомизировать можно все, что угодно.
🔹 Легаси-инфраструктура — многие проекты исторически зависят от Jenkins, и миграция может быть очень затратной.
🔹 Расширяемость — тысячи плагинов позволяют адаптировать Jenkins под любые нужды.
Несмотря на всё вышесказанное, Jenkins всё ещё жив и активно используется. Взглянем на цифры за 2024 год (stats.jenkins.io):
📌 Активные jobs: 82 000 000+
📌 Подключенные nodes: 1 000 000+
📌 Коммиты: 51 000+
📌 Релизы: 13 LTS, 50 Weekly
📌 Pull Requests: 6000+
📌 GitHub Stars: 23 000+
📌 Контрибьюторы: 3000+
📌 Компании-использователи: 39 000+
Как видите, Jenkins по-прежнему используется в крупных компаниях, включая FAANG по следующим причинам:
🔹 Гибкость и мощность — он остаётся универсальным инструментом для действительно сложных пайплайнов. Кастомизировать можно все, что угодно.
🔹 Легаси-инфраструктура — многие проекты исторически зависят от Jenkins, и миграция может быть очень затратной.
🔹 Расширяемость — тысячи плагинов позволяют адаптировать Jenkins под любые нужды.
👍3
💡 Итоги
Jenkins — это легенда, но мир движется вперёд. Современные инструменты предлагают простоту, скорость и безопасность, которые Jenkins уже не может обеспечить в полной мере. Однако он всё ещё остаётся мощным решением для сложных сценариев и легаси-проектов.
Стоит ли выбирать Jenkins? Скорее всего, нет. Сейчас есть более простые, удобные и масштабируемые альтернативы, которые позволяют быстрее достигать результата.
А как у вас? Вы до сих пор на Jenkins или уже перешли на что-то более удобное? Делитесь опытом в комментариях! 🤔👇
PS: В качестве бонуса можете посмотреть выступление с последнего DevOpsConf, на котором снова заговорили про Jenkins: https://www.youtube.com/watch?v=OlD25Cbig_U
PSS: Две недавние статьи, где авторы придерживаются примерно тех же мыслей:
- https://medium.com/@osomudeyazudonu/stop-using-jenkins-4dcb7e4f0e53
- https://habr.com/ru/articles/902300/
Jenkins — это легенда, но мир движется вперёд. Современные инструменты предлагают простоту, скорость и безопасность, которые Jenkins уже не может обеспечить в полной мере. Однако он всё ещё остаётся мощным решением для сложных сценариев и легаси-проектов.
Стоит ли выбирать Jenkins? Скорее всего, нет. Сейчас есть более простые, удобные и масштабируемые альтернативы, которые позволяют быстрее достигать результата.
А как у вас? Вы до сих пор на Jenkins или уже перешли на что-то более удобное? Делитесь опытом в комментариях! 🤔👇
PS: В качестве бонуса можете посмотреть выступление с последнего DevOpsConf, на котором снова заговорили про Jenkins: https://www.youtube.com/watch?v=OlD25Cbig_U
PSS: Две недавние статьи, где авторы придерживаются примерно тех же мыслей:
- https://medium.com/@osomudeyazudonu/stop-using-jenkins-4dcb7e4f0e53
- https://habr.com/ru/articles/902300/
🔥5
Последний пост про Jenkins на сегодня. Страшно представить, но когда-то, в 2017 или 2018 году, я сам пытался построить свой IAC-фреймворк для создания Jenkins Jobs — на тогда ещё новомодном JobDSL. Сейчас это выглядит перегруженно и дико, но тогда казалось настоящим прорывом: автоматизация в виде кода вместо ручного накликивания джоб.
Если вам интересна археология, вот те самые репозитории:
🔗Сам фреймворк: https://github.com/kvendingoldo/JDCL
🔗Пример описания Jenkins Jobs: https://github.com/kvendingoldo/udc-jobdsl
А раз уж сегодня говорили о важности программирования для DevOps, вот вам фрагмент «страшного» кода того времени — для автоматизированного создания Jenkins Jobs:
Если вам интересна археология, вот те самые репозитории:
🔗Сам фреймворк: https://github.com/kvendingoldo/JDCL
🔗Пример описания Jenkins Jobs: https://github.com/kvendingoldo/udc-jobdsl
А раз уж сегодня говорили о важности программирования для DevOps, вот вам фрагмент «страшного» кода того времени — для автоматизированного создания Jenkins Jobs:
def processConfig(String jcPath) {
def jc
if (this.type == 'LOCAL') {
jc = new Yaml().load(new File(jcPath).getText('UTF-8'))
} else if (this.type == 'JENKINS') {
jc = new Yaml().load(this.dslFactory.readFileFromWorkspace(jcPath))
}
if (jc.containsKey('imports')) {
def jcChild = jc.findAll { key, _ -> !(key in ['imports']) }
(jc.imports).each { jcImport ->
def jcParent = processConfig("${this.importDirectory}/${jcImport}")
if (jcChild.job!=null) {
jcChild = merge(jcChild, jcParent)
} else {
jcChild.findAll { key, _ -> !(key in ['job']) }.each { key, value ->
jcChild."${key}" = merge(jcChild."${key}", jcParent)
}
}
}
return jcChild
} else {
return jc
}
}
private def merge(def config, def object) {
object?.each { key, value ->
if (config."${key}" == null || (!config.containsKey(key))) {
config."${key}" = value
} else {
if (!(config."${key}" instanceof String)) {
config."${key}" = merge(config."${key}", value)
}
}
}
return config
}
👍1🔥1
И сам пример Jenkins Job описанной на Groovy в ту эпоху:
package jobdsl.build.jobs
import com.kvendingoldo.jdcl.core.Functions
class UdcPreCommit {
static job(dslFactory, jobConfig) {
dslFactory.job(Functions.generateJobName(jobConfig)) {
denoscription(jobConfig.job.denoscription)
label(jobConfig.job.label)
concurrentBuild()
logRotator(jobConfig.job.daysToKeepBuilds, jobConfig.job.maxOfBuildsToKeep)
environmentVariables {
env('GENERATED_VERSION_TYPE', jobConfig.job.generatedVersionType)
overrideBuildParameters(true)
}
wrappers {
colorizeOutput()
timestamps()
preBuildCleanup()
}
scm {
git {
remote {
credentials(jobConfig.job.credentials.github)
github(jobConfig.job.repository, 'ssh')
refspec('+refs/pull/*:refs/remotes/origin/pr/*')
}
branch('${sha1}')
extensions {
wipeOutWorkspace()
submoduleOptions {
recursive()
}
}
}
}
triggers {
githubPullRequest {
cron('*/1 * * * *')
permitAll()
}
}
steps {
gitHubSetCommitStatusBuilder {
statusMessage {
content('building...')
}
}
shell(dslFactory.readFileFromWorkspace('jobdsl/common/bash/emailValidator.sh'))
shell('gcloud docker -a')
shell(dslFactory.readFileFromWorkspace(jobConfig.job.variablesGeneratorScript))
shell(dslFactory.readFileFromWorkspace(jobConfig.job.versionGeneratorScript))
envInjectBuilder {
propertiesFilePath('variables.txt')
propertiesContent('')
}
buildNameUpdater {
fromFile(false)
buildName('${VERSION}')
fromMacro(true)
macroTemplate('${VERSION}')
macroFirst(false)
}
maven {
goals('clean install')
goals('-B')
goals('-C')
goals('-q')
goals(' -Pimage')
goals('-Ddocker.registry.host=gcr.io')
}
}
publishers {
gitHubCommitNotifier {
resultOnFailure('fail')
statusMessage {
content('build is completed')
}
}
}
}
}
}
😱4
Kubernetes уже у всех, верно? 🤔 Кажется, что так.
Иногда разработчики удивляются, когда я не предлагаю K8S для нового проекта. В последнее время у многих сложился майндсет: «Поставил куб — и дальше оно как-нибудь само», вплоть до выписывания TLS сертификатов и автоматического создания DNS-записей.
Ну, в целом, конечно, можно накидать YAML'ов и посмотреть, что будет. Но ни одно коробочное решение (вроде CozeStack, DeckHouse или OpenShift) не сделает всё за вас. Kubernetes — это не волшебная таблетка, а сложный инструмент, который требует глубокого понимания.
🚀 Давайте посмотрим, что вам нужно понимать с технической точки зрения , когда вы онбордите Kubernetes.
🔹 Базовый уровень (уровень сертификации CKAD)
Это минимум, без которого лучше вообще не лезть в Kubernetes:
✅ Управление подами. Как создавать, удалять и масштабировать поды.
✅ Sidecars и init-контейнеры
✅ PVC/PV. Как хранить данные в Kubernetes и не потерять их при пересоздании подов.
✅ Service / Ingress. Как прокинуть трафик из кластера наружу
✅ Helm / Kustomize. Как управлять конфигурациями через темплейты.
🔹 Средний уровень (уровень сертификации CKA)
✅ Что такое SMI/CNI/etc. Как сети работают в Kubernetes и почему это важно.
✅ Траблшутинг кластера. Как читать логи, смотреть события через kubectl get events и находить корень проблемы.
✅ Разные CNI-плагины и их особенности. Calico, Flannel, Cilium — чем они отличаются и какой выбрать.
✅ Архитектура Kubernetes (правда ли, что куб это всего 5 бинарей?). Как работают kubelet, API-сервер, etcd и другие компоненты.
✅ Service Mesh. Зачем он нужен и как выбрать между Istio, Linkerd и другими.
✅ Автоматизация сертификатов. Как использовать cert-manager или встроенные возможности Istio.
✅ Тюнинг системных компонентов. Например, как оптимизировать etcd для высокой нагрузки.
✅ Генерация YAML'ов через kubectl. Как не писать их вручную и не допускать ошибок.
✅ Работа с секретами. Как безопасно их хранить и управлять ими.
✅ Логирование и мониторинг. Настройка Prometheus, Loki, OpenTelemetry в Kubernetes.
✅ GitOps. Внедрение ArgoCD или FluxCD для управления конфигурациями.
✅ kubernetes-the-hard-way. Если вы прошли этот гайд, то уже понимаете, как всё устроено под капотом.
🔹 Высокий уровень (beyond CKA/CKS)
✅ Kubernetes и eBPF. Как они связаны и что можно сделать с помощью eBPF для улучшения производительности и безопасности.
✅ Кастомные контроллеры. Создание CRD (Custom Resource Definitions) и разработка операторов.
✅ Мультикластерные решения. Как управлять несколькими кластерами и синхронизировать их. Как собрать федерацию.
✅ Безопасность. Использование OPA, Kyverno, Falco для защиты кластера.
✅ Производительность. Как понять, что API-сервер или etcd не справляются с нагрузкой, и что с этим делать.
Иногда разработчики удивляются, когда я не предлагаю K8S для нового проекта. В последнее время у многих сложился майндсет: «Поставил куб — и дальше оно как-нибудь само», вплоть до выписывания TLS сертификатов и автоматического создания DNS-записей.
Ну, в целом, конечно, можно накидать YAML'ов и посмотреть, что будет. Но ни одно коробочное решение (вроде CozeStack, DeckHouse или OpenShift) не сделает всё за вас. Kubernetes — это не волшебная таблетка, а сложный инструмент, который требует глубокого понимания.
🚀 Давайте посмотрим, что вам нужно понимать с технической точки зрения , когда вы онбордите Kubernetes.
🔹 Базовый уровень (уровень сертификации CKAD)
Это минимум, без которого лучше вообще не лезть в Kubernetes:
✅ Управление подами. Как создавать, удалять и масштабировать поды.
✅ Sidecars и init-контейнеры
✅ PVC/PV. Как хранить данные в Kubernetes и не потерять их при пересоздании подов.
✅ Service / Ingress. Как прокинуть трафик из кластера наружу
✅ Helm / Kustomize. Как управлять конфигурациями через темплейты.
🔹 Средний уровень (уровень сертификации CKA)
✅ Что такое SMI/CNI/etc. Как сети работают в Kubernetes и почему это важно.
✅ Траблшутинг кластера. Как читать логи, смотреть события через kubectl get events и находить корень проблемы.
✅ Разные CNI-плагины и их особенности. Calico, Flannel, Cilium — чем они отличаются и какой выбрать.
✅ Архитектура Kubernetes (правда ли, что куб это всего 5 бинарей?). Как работают kubelet, API-сервер, etcd и другие компоненты.
✅ Service Mesh. Зачем он нужен и как выбрать между Istio, Linkerd и другими.
✅ Автоматизация сертификатов. Как использовать cert-manager или встроенные возможности Istio.
✅ Тюнинг системных компонентов. Например, как оптимизировать etcd для высокой нагрузки.
✅ Генерация YAML'ов через kubectl. Как не писать их вручную и не допускать ошибок.
✅ Работа с секретами. Как безопасно их хранить и управлять ими.
✅ Логирование и мониторинг. Настройка Prometheus, Loki, OpenTelemetry в Kubernetes.
✅ GitOps. Внедрение ArgoCD или FluxCD для управления конфигурациями.
✅ kubernetes-the-hard-way. Если вы прошли этот гайд, то уже понимаете, как всё устроено под капотом.
🔹 Высокий уровень (beyond CKA/CKS)
✅ Kubernetes и eBPF. Как они связаны и что можно сделать с помощью eBPF для улучшения производительности и безопасности.
✅ Кастомные контроллеры. Создание CRD (Custom Resource Definitions) и разработка операторов.
✅ Мультикластерные решения. Как управлять несколькими кластерами и синхронизировать их. Как собрать федерацию.
✅ Безопасность. Использование OPA, Kyverno, Falco для защиты кластера.
✅ Производительность. Как понять, что API-сервер или etcd не справляются с нагрузкой, и что с этим делать.
👍1
📌 И напоследок…
Kubernetes — это не просто инструмент, это целая экосистема, которая требует глубокого понимания. Если вы думаете, что можно просто «поставить куб и забыть», то вы сильно ошибаетесь.
В приложении к посту есть картинка от компании Flant (из доклада «Как правильно сделать Kubernetes» Дмитрия Столярова), которая показывает, насколько глубоким является айсберг Kubernetes.
А как вы оцениваете свой уровень владения K8S? Не бесит ли вас, когда кто-то говорит, что умеет с ним работать, но по факту не разбирается дальше создания Deployment? 😅🚀
PS: Как бонус - отличная статья про куб на хабре https://habr.com/ru/companies/h3llo_cloud/articles/902188/
Kubernetes — это не просто инструмент, это целая экосистема, которая требует глубокого понимания. Если вы думаете, что можно просто «поставить куб и забыть», то вы сильно ошибаетесь.
В приложении к посту есть картинка от компании Flant (из доклада «Как правильно сделать Kubernetes» Дмитрия Столярова), которая показывает, насколько глубоким является айсберг Kubernetes.
А как вы оцениваете свой уровень владения K8S? Не бесит ли вас, когда кто-то говорит, что умеет с ним работать, но по факту не разбирается дальше создания Deployment? 😅🚀
PS: Как бонус - отличная статья про куб на хабре https://habr.com/ru/companies/h3llo_cloud/articles/902188/
❤2
1️⃣ Навигация по первому дню андерхуда
— DevOps: философия, а не просто набор инструментов
— Почему DevOps обязан уметь программировать
— Jenkins: жив или мёртв?
— Актуальные инструменты CI/CD
— Kubernetes повсюду
— DevOps: философия, а не просто набор инструментов
— Почему DevOps обязан уметь программировать
— Jenkins: жив или мёртв?
— Актуальные инструменты CI/CD
— Kubernetes повсюду
❤5
🚀 Kubernetes — новый язык для разработки инфраструктуры?
Раньше инфраструктура была просто средой для запуска приложений. Сегодня Kubernetes (K8S) изменил правила игры: теперь инфраструктура — это код, который нужно писать, версионировать и управлять как программным продуктом.
Почему Kubernetes стал де-факто "языком инфраструктуры"?
🔹 Декларативный подход — манифесты YAML описывают желаемое состояние системы, а K8s сам обеспечивает его выполнение. Это как сказать системе: «Хочу, чтобы было вот так» — и она сделает всё за вас.
🔹 Композиция — как код состоит из модулей и функций, так и инфраструктура в Kubernetes собирается из Deployments, Services, Ingress и других объектов. Это как LEGO для взрослых — собирай, что нужно, и не изобретай велосипед.
🔹 Абстракции — Разработчикам больше не нужно заботиться о физических серверах, балансировке и автошкаллировании. Всё это управляется на уровне кластера. Вы просто говорите: «Мне нужно 10 подов» — и Kubernetes делает это (но помните, только в случае managed решения).
🔹 Расширяемость — С помощью Custom Resource Definitions (CRD) и Custom API servers можно создавать собственные объекты и управлять ими как встроенными ресурсами. Это как добавить в язык программирования свои ключевые слова.
Инфраструктурные инженеры → DevOps-разработчики
Если раньше инфраструктура настраивалась вручную или с помощью bash-скриптов, то теперь:
✅ Helm-чарты = пакетные менеджеры
✅ Kustomize = управление конфигурациями без дублирования кода
✅ Operators и CRD = объектно-ориентированное программирование в инфраструктуре
✅ GitOps (ArgoCD, FluxCD) = версионирование и автоматизация развертывания
К чему мы идем?
Мы движемся к тому, чтобы заранее, на понятном языке, декларировать, что мы хотим от системы. Это понимание должно быть одинаково глубоко на уровне DevOps инженеров и разработчиков.
Но почему мы говорим только про K8S?
Terraform и подобные инструменты хороши, но они, в первую очередь, описывают облачные ресурсы, что ближе к инфраструктурным инженерам, чем к разработчикам. Kubernetes, напротив, представляет собой более высокоуровневую абстракцию, которая позволяет сосредоточиться на архитектуре приложения и его управлении, без глубокой привязки к конкретным облачным провайдерам и их ресурсам.
💡 Вывод
Kubernetes — это не просто оркестратор контейнеров, а новый язык разработки инфраструктуры, который требует от инженеров понимания концепций, аналогичных программированию.
А как у вас?
Kubernetes — удобный инструмент или сложный барьер для входа? Используете ли вы GitOps, Operators или другие продвинутые практики? Считаете ли вы, что K8S действительно стал «языком инфраструктуры»?
PS: Если вам интересно послушать про мой опыт разработки операторов, кастомных планировщиков или подготовку к CKA/CKAD, пишите в комментариях 👇 Сделаю отдельный пост с лайфхаками и советами!
Раньше инфраструктура была просто средой для запуска приложений. Сегодня Kubernetes (K8S) изменил правила игры: теперь инфраструктура — это код, который нужно писать, версионировать и управлять как программным продуктом.
Почему Kubernetes стал де-факто "языком инфраструктуры"?
🔹 Декларативный подход — манифесты YAML описывают желаемое состояние системы, а K8s сам обеспечивает его выполнение. Это как сказать системе: «Хочу, чтобы было вот так» — и она сделает всё за вас.
🔹 Композиция — как код состоит из модулей и функций, так и инфраструктура в Kubernetes собирается из Deployments, Services, Ingress и других объектов. Это как LEGO для взрослых — собирай, что нужно, и не изобретай велосипед.
🔹 Абстракции — Разработчикам больше не нужно заботиться о физических серверах, балансировке и автошкаллировании. Всё это управляется на уровне кластера. Вы просто говорите: «Мне нужно 10 подов» — и Kubernetes делает это (но помните, только в случае managed решения).
🔹 Расширяемость — С помощью Custom Resource Definitions (CRD) и Custom API servers можно создавать собственные объекты и управлять ими как встроенными ресурсами. Это как добавить в язык программирования свои ключевые слова.
Инфраструктурные инженеры → DevOps-разработчики
Если раньше инфраструктура настраивалась вручную или с помощью bash-скриптов, то теперь:
✅ Helm-чарты = пакетные менеджеры
✅ Kustomize = управление конфигурациями без дублирования кода
✅ Operators и CRD = объектно-ориентированное программирование в инфраструктуре
✅ GitOps (ArgoCD, FluxCD) = версионирование и автоматизация развертывания
К чему мы идем?
Мы движемся к тому, чтобы заранее, на понятном языке, декларировать, что мы хотим от системы. Это понимание должно быть одинаково глубоко на уровне DevOps инженеров и разработчиков.
Но почему мы говорим только про K8S?
Terraform и подобные инструменты хороши, но они, в первую очередь, описывают облачные ресурсы, что ближе к инфраструктурным инженерам, чем к разработчикам. Kubernetes, напротив, представляет собой более высокоуровневую абстракцию, которая позволяет сосредоточиться на архитектуре приложения и его управлении, без глубокой привязки к конкретным облачным провайдерам и их ресурсам.
💡 Вывод
Kubernetes — это не просто оркестратор контейнеров, а новый язык разработки инфраструктуры, который требует от инженеров понимания концепций, аналогичных программированию.
А как у вас?
Kubernetes — удобный инструмент или сложный барьер для входа? Используете ли вы GitOps, Operators или другие продвинутые практики? Считаете ли вы, что K8S действительно стал «языком инфраструктуры»?
PS: Если вам интересно послушать про мой опыт разработки операторов, кастомных планировщиков или подготовку к CKA/CKAD, пишите в комментариях 👇 Сделаю отдельный пост с лайфхаками и советами!
🔥3
Давайте немного поговорим о главном холиваре в мире IaC: OpenTofu vs Terraform. Ну и что использовать в 2025 для описания инфраструктуры.
Почему все так сложно? Контекст драмы
- 2023: HashiCorp перевел Terraform на BSL-лицензию, запретив коммерческое использование в конкурентных продуктах. Сообщество взорвалось — так родился OpenTofu (форк Terraform под MPL 2.0).
- 2024: OpenTofu набрал хайп, но… внезапно заблокировал доступ для пользователей из России и удалил российские облака из реестра. Теперь оба инструмента стали проблемными для многих команд и проектов.
👉 Если коротко имеем следующую картину:
Terraform = стабильность, но BSL и зависимость от HashiCorp/IBM.
OpenTofu = open-source, но без российских провайдеров и с политическими ограничениями.
К сожалению, подобное происходит не только с Terraform, и подробнее об этом можно прочитать здесь. Ну а пока мы с вами разберемся, что же выбрать для нового проекта в 2025 году.
🔥 Ключевые различия:
1️⃣ Лицензия и открытость
🔹 OpenTofu — полностью open-source (MPL 2.0), управляется сообществом, решения принимаются коллективно, без полного контроля одной компании.
🔹 Terraform — изначально open-source, но теперь использует BSL, что вводит ограничения на коммерческое использование. Развивается HashiCorp (а теперь и IBM).
2️⃣ Функциональность
🔹 Оба инструмента работают по декларативному принципу: вы описываете желаемое состояние инфраструктуры, а система сама приводит её в нужное состояние.
🔹 OpenTofu уже предлагает дополнительные возможности, например:
- Шифрование state-файлов из коробки
- Ранняя обработка переменных
- Улучшения в планировании изменений
🔹Terraform выигрывает в стабильности, интеграциях и зрелости экосистемы.
3️⃣ Экосистема и сообщество
🔹 Terraform существует дольше (7+ лет развития), у него зрелая экосистема, HashiCorp активно поддерживает экосистему плагинов и Terraform Cloud. Помимо этого, Terraform обладает огромной базой пользователей.
🔹 OpenTofu растёт быстрыми темпами, за ним стоят крупные игроки, но его сообщество пока не такое зрелое и сформированное
4️⃣ Ограничения для российских пользователей
🔹Terraform заблокировал доступ к реестру провайдеров ещё в 2022 году, но не удалял существующие провайдеры.
🔹 OpenTofu полностью заблокировал пользователей из России и удалил российских облачных провайдеров вызвал этим длительную дискуссию в сообществе. На данный момент, отсуствие провайдеров в официальном реестре делает его непригодным для работы с российскими облаками.
В любом случае, для обхода блокировки реества вам в обоих случаях понадобятся зеркала. Для Terraform их существует достаточно много, а вот для OpenTofu пока ни одного. Про настройку зеркалов вы можете прочитать здесь.
Почему все так сложно? Контекст драмы
- 2023: HashiCorp перевел Terraform на BSL-лицензию, запретив коммерческое использование в конкурентных продуктах. Сообщество взорвалось — так родился OpenTofu (форк Terraform под MPL 2.0).
- 2024: OpenTofu набрал хайп, но… внезапно заблокировал доступ для пользователей из России и удалил российские облака из реестра. Теперь оба инструмента стали проблемными для многих команд и проектов.
👉 Если коротко имеем следующую картину:
Terraform = стабильность, но BSL и зависимость от HashiCorp/IBM.
OpenTofu = open-source, но без российских провайдеров и с политическими ограничениями.
К сожалению, подобное происходит не только с Terraform, и подробнее об этом можно прочитать здесь. Ну а пока мы с вами разберемся, что же выбрать для нового проекта в 2025 году.
🔥 Ключевые различия:
1️⃣ Лицензия и открытость
🔹 OpenTofu — полностью open-source (MPL 2.0), управляется сообществом, решения принимаются коллективно, без полного контроля одной компании.
🔹 Terraform — изначально open-source, но теперь использует BSL, что вводит ограничения на коммерческое использование. Развивается HashiCorp (а теперь и IBM).
2️⃣ Функциональность
🔹 Оба инструмента работают по декларативному принципу: вы описываете желаемое состояние инфраструктуры, а система сама приводит её в нужное состояние.
🔹 OpenTofu уже предлагает дополнительные возможности, например:
- Шифрование state-файлов из коробки
- Ранняя обработка переменных
- Улучшения в планировании изменений
🔹Terraform выигрывает в стабильности, интеграциях и зрелости экосистемы.
3️⃣ Экосистема и сообщество
🔹 Terraform существует дольше (7+ лет развития), у него зрелая экосистема, HashiCorp активно поддерживает экосистему плагинов и Terraform Cloud. Помимо этого, Terraform обладает огромной базой пользователей.
🔹 OpenTofu растёт быстрыми темпами, за ним стоят крупные игроки, но его сообщество пока не такое зрелое и сформированное
4️⃣ Ограничения для российских пользователей
🔹Terraform заблокировал доступ к реестру провайдеров ещё в 2022 году, но не удалял существующие провайдеры.
🔹 OpenTofu полностью заблокировал пользователей из России и удалил российских облачных провайдеров вызвал этим длительную дискуссию в сообществе. На данный момент, отсуствие провайдеров в официальном реестре делает его непригодным для работы с российскими облаками.
В любом случае, для обхода блокировки реества вам в обоих случаях понадобятся зеркала. Для Terraform их существует достаточно много, а вот для OpenTofu пока ни одного. Про настройку зеркалов вы можете прочитать здесь.
👍2
❓ Что же мне выбрать?
✅ Terraform стоит выбрать, если:
✔ Вам нужна зрелая экосистема и стабильность.
✔ Вы не создаёте конкурента Terraform Cloud или другие продукты, которые могут нарушать BSL.
✔ Вам не критично, что код частично закрыт, и вы доверяете HashiCorp/IBM.
✅ OpenTofu подходит, если:
✔ Вам нужен полностью open-source инструмент без ограничений BSL.
✔ Вы видите риски в использовании Terraform и хотите обезопасить себя от частично закрытых лицензий.
✔ Вы не работаете с российскими облачными платформами.
✔ Вам не нужно поддерживать большое количество legacy кода на Terraform
🚀 А стоит ли обновляться с Terraform 1.5.7? Он же все еще работает, и он MPL-2.0
Да, однозначно! В обоих проектах появилось множество новых фич.
Следить за актуальностью возможностей можно здесь 👉 cani.tf
🔍 Вывод:
🔹 OpenTofu
✔ Отличный выбор для новых проектов, где не используются российские облака.
✔ Подходит для тех, кто хочет участвовать в развитии сообщества и продвигать новые фичи.
✔ Рекомендуется, если ваш продукт потенциально конфликтует с лицензией BSL и Terraform Cloud.
🔹 Terraform
✔ Оптимален для типичных DevOps-проектов и CI/CD-инфраструктуры под AWS, GCP, Azure.
✔ Выбор для тех, кому важны стабильность, зрелая экосистема и поддержка HashiCorp.
✔ Подходит, если BSL-лицензия не критична, а доверие к HashiCorp выше благодаря опыту и корпоративному уровню решений.
🚀 Ну а если вам нужно быстро переключаться между версиями Terraform и OpenTofu, попробуйте 👉 tofuutils/tenv
🤔 А что используете вы? Terraform или OpenTofu? Делитесь мнением в комментариях!
✅ Terraform стоит выбрать, если:
✔ Вам нужна зрелая экосистема и стабильность.
✔ Вы не создаёте конкурента Terraform Cloud или другие продукты, которые могут нарушать BSL.
✔ Вам не критично, что код частично закрыт, и вы доверяете HashiCorp/IBM.
✅ OpenTofu подходит, если:
✔ Вам нужен полностью open-source инструмент без ограничений BSL.
✔ Вы видите риски в использовании Terraform и хотите обезопасить себя от частично закрытых лицензий.
✔ Вы не работаете с российскими облачными платформами.
✔ Вам не нужно поддерживать большое количество legacy кода на Terraform
🚀 А стоит ли обновляться с Terraform 1.5.7? Он же все еще работает, и он MPL-2.0
Да, однозначно! В обоих проектах появилось множество новых фич.
Следить за актуальностью возможностей можно здесь 👉 cani.tf
🔍 Вывод:
🔹 OpenTofu
✔ Отличный выбор для новых проектов, где не используются российские облака.
✔ Подходит для тех, кто хочет участвовать в развитии сообщества и продвигать новые фичи.
✔ Рекомендуется, если ваш продукт потенциально конфликтует с лицензией BSL и Terraform Cloud.
🔹 Terraform
✔ Оптимален для типичных DevOps-проектов и CI/CD-инфраструктуры под AWS, GCP, Azure.
✔ Выбор для тех, кому важны стабильность, зрелая экосистема и поддержка HashiCorp.
✔ Подходит, если BSL-лицензия не критична, а доверие к HashiCorp выше благодаря опыту и корпоративному уровню решений.
🚀 Ну а если вам нужно быстро переключаться между версиями Terraform и OpenTofu, попробуйте 👉 tofuutils/tenv
🤔 А что используете вы? Terraform или OpenTofu? Делитесь мнением в комментариях!
👍3
Лучшие инструменты для Terraform и OpenTofu в 2025 году 🚀
Infrastructure-as-Code (IaC) продолжает активно развиваться, а вместе с ним растёт и экосистема инструментов, облегчающих управление инфраструктурой. Многие из них изначально создавались для Terraform, но теперь полностью поддерживают и OpenTofu, что делает их универсальными помощниками для DevOps-инженеров и облачных архитекторов.
Этот пост - подборка самых полезных инструментов, которые сделают вашу работу с IaC быстрее, удобнее и безопаснее.
🛠 Управление версиями
🔹 tenv – лёгкий и быстрый менеджер версий для Terraform, OpenTofu, Terragrunt и Atmos. Поддерживает автоматический парсинг версий из конфигурационных файлов, проверку подписей (cosign, PGP), доступен как Go-пакет, а еще во всех популярных пакетных менеджерах и ОС (включая Windows). В отличие от asdf, не требует зависимостей, работает быстрее и оптимизирован для Terraform/OpenTofu-экосистемы. (🔗 GitHub)
🤖 Автоматизация и генерация IaC
🔹 Aiac – AI-инструмент для генерации Terraform-кода, CI/CD пайплайнов, OPA-политик и других IaC-конфигураций. Поддерживает OpenAI, Amazon Bedrock и Ollama. (🔗 aiac.dev)
🔹 Atmos – мощный фреймворк для структурирования инфраструктуры в Terraform/OpenTofu с YAML-конфигурациями. Упрощает управление модулями и окружениями. (🔗 GitHub)
🔹 Terramate – инструмент для автоматизации IaC-оркестрации, code generation и работы со стэками. (🔗 GitHub)
🏗 Улучшение работы с Terraform/OpenTofu
🔹 Terragrunt – обёртка над Terraform, сокращающая дублирование кода и упрощающая управление состоянием, зависимостями и окружениями. (🔗 terragrunt.io)
🔹 Atlantis – автоматизация Terraform в pull request'ах. Идеален для командной работы и интеграции с CI/CD. (🔗 runatlantis.io)
🔹 Burrito – Kubernetes-оператор для автоматизации Terraform, аналог ArgoCD для IaC. (🔗 GitHub)
🔍 Безопасность и анализ кода
🔹 Checkov – мощный инструмент статического анализа IaC, выявляющий уязвимости и ошибки конфигурации в Terraform/OpenTofu, Kubernetes, Docker и других платформах. (🔗 GitHub)
🔹 Trivy – универсальный сканер, находящий уязвимости в контейнерах, IaC, артефактах и облачных сервисах. (🔗 trivy.dev)
🔹 TFLint – продвинутый линтер для Terraform, предотвращающий ошибки в коде и проверяющий соответствие best practices. (🔗 GitHub)
💰 Контроль затрат и управление ресурсами
🔹 Infracost – оценка стоимости облачных ресурсов в Terraform/OpenTofu до их развертывания. Интеграция с CI/CD и GitHub PR. (🔗 GitHub)
🔹 Terratag – автоматическое добавление тегов в Terraform/OpenTofu-код, обеспечивающее лучшее управление ресурсами в AWS, GCP и Azure. (🔗 GitHub)
⚙️ Управление состоянием и миграции
🔹 Tfmigrate – инструмент для безопасных миграций Terraform/OpenTofu state с возможностью dry-run. (🔗 GitHub)
🔹 Tfmv – CLI-инструмент для автоматического переименования ресурсов Terraform/OpenTofu без потери состояния. (🔗 GitHub)
А какие инструменты используете вы? Делитесь опытом в комментариях! 🚀
Infrastructure-as-Code (IaC) продолжает активно развиваться, а вместе с ним растёт и экосистема инструментов, облегчающих управление инфраструктурой. Многие из них изначально создавались для Terraform, но теперь полностью поддерживают и OpenTofu, что делает их универсальными помощниками для DevOps-инженеров и облачных архитекторов.
Этот пост - подборка самых полезных инструментов, которые сделают вашу работу с IaC быстрее, удобнее и безопаснее.
🛠 Управление версиями
🔹 tenv – лёгкий и быстрый менеджер версий для Terraform, OpenTofu, Terragrunt и Atmos. Поддерживает автоматический парсинг версий из конфигурационных файлов, проверку подписей (cosign, PGP), доступен как Go-пакет, а еще во всех популярных пакетных менеджерах и ОС (включая Windows). В отличие от asdf, не требует зависимостей, работает быстрее и оптимизирован для Terraform/OpenTofu-экосистемы. (🔗 GitHub)
🤖 Автоматизация и генерация IaC
🔹 Aiac – AI-инструмент для генерации Terraform-кода, CI/CD пайплайнов, OPA-политик и других IaC-конфигураций. Поддерживает OpenAI, Amazon Bedrock и Ollama. (🔗 aiac.dev)
🔹 Atmos – мощный фреймворк для структурирования инфраструктуры в Terraform/OpenTofu с YAML-конфигурациями. Упрощает управление модулями и окружениями. (🔗 GitHub)
🔹 Terramate – инструмент для автоматизации IaC-оркестрации, code generation и работы со стэками. (🔗 GitHub)
🏗 Улучшение работы с Terraform/OpenTofu
🔹 Terragrunt – обёртка над Terraform, сокращающая дублирование кода и упрощающая управление состоянием, зависимостями и окружениями. (🔗 terragrunt.io)
🔹 Atlantis – автоматизация Terraform в pull request'ах. Идеален для командной работы и интеграции с CI/CD. (🔗 runatlantis.io)
🔹 Burrito – Kubernetes-оператор для автоматизации Terraform, аналог ArgoCD для IaC. (🔗 GitHub)
🔍 Безопасность и анализ кода
🔹 Checkov – мощный инструмент статического анализа IaC, выявляющий уязвимости и ошибки конфигурации в Terraform/OpenTofu, Kubernetes, Docker и других платформах. (🔗 GitHub)
🔹 Trivy – универсальный сканер, находящий уязвимости в контейнерах, IaC, артефактах и облачных сервисах. (🔗 trivy.dev)
🔹 TFLint – продвинутый линтер для Terraform, предотвращающий ошибки в коде и проверяющий соответствие best practices. (🔗 GitHub)
💰 Контроль затрат и управление ресурсами
🔹 Infracost – оценка стоимости облачных ресурсов в Terraform/OpenTofu до их развертывания. Интеграция с CI/CD и GitHub PR. (🔗 GitHub)
🔹 Terratag – автоматическое добавление тегов в Terraform/OpenTofu-код, обеспечивающее лучшее управление ресурсами в AWS, GCP и Azure. (🔗 GitHub)
⚙️ Управление состоянием и миграции
🔹 Tfmigrate – инструмент для безопасных миграций Terraform/OpenTofu state с возможностью dry-run. (🔗 GitHub)
🔹 Tfmv – CLI-инструмент для автоматического переименования ресурсов Terraform/OpenTofu без потери состояния. (🔗 GitHub)
А какие инструменты используете вы? Делитесь опытом в комментариях! 🚀
👍4❤1
🚀 *Ops — в чём разница?
Современный IT-мир давно вышел за рамки простой разработки. Сегодня инженеры отвечают не только за код, но и за его тестирование, развертывание, безопасность, мониторинг и оптимизацию затрат. Пока все привыкали к DevOps, новые «ops» начали появляться повсюду, словно грибы после дождя. Давайте разберёмся, какие бывают «ops»-методологии и чем они отличаются между собой.
DevOps (Development + Operations)
Что это?
DevOps объединяет процессы непрерывной разработки, интеграции, тестирования, развертывания и мониторинга, способствуя инновациям, гибкости и масштабируемости.
Ключевые моменты:
🎯 Цель: ускорение релизов через тесное взаимодействие разработчиков и администраторов.
🛠 Инструменты: CI/CD (GitHub Actions, GitLab CI, Jenkins), Kubernetes, Terraform, Ansible, Go.
💡 Идея: Автоматизация и инфраструктура как код (IaC) позволяют обеспечивать быстрые и надёжные обновления без даунтайма.
DevSecOps (Development + Security + Operations)
Что это?
DevSecOps — это DevOps с интегрированной безопасностью. В отличие от традиционного подхода, где безопасность добавляется в конце разработки, здесь она встроена в каждый этап разработки, превращая её в общую ответственность команды.
Ключевые моменты:
🎯 Цель: встроить безопасность на всех этапах CI/CD процесса.
🛠 Инструменты: SAST/DAST (SonarQube, Snyk, OWASP ZAP), системы управления секретами (Vault, Sealed Secrets).
💡 Идея: Безопасность — это не отдельная проверка перед релизом, а часть всего процесса разработки.
MLOps (Machine Learning + Operations)
Что это?
MLOps — это DevOps для машинного обучения, обеспечивающий автоматизированное развертывание и управление ML-моделями в продакшене.
Ключевые моменты:
🎯 Цель: обеспечить непрерывную интеграцию, тестирование, развертывание и мониторинг ML-моделей.
🛠 Инструменты: MLflow, Kubeflow, TensorFlow Extended (TFX), Apache Airflow.
💡 Идея: Автоматизация и контроль качества жизненного цикла моделей критичны для успешного внедрения. ML — это не только тренировка модели, но и её продакшен.
Современный IT-мир давно вышел за рамки простой разработки. Сегодня инженеры отвечают не только за код, но и за его тестирование, развертывание, безопасность, мониторинг и оптимизацию затрат. Пока все привыкали к DevOps, новые «ops» начали появляться повсюду, словно грибы после дождя. Давайте разберёмся, какие бывают «ops»-методологии и чем они отличаются между собой.
DevOps (Development + Operations)
Что это?
DevOps объединяет процессы непрерывной разработки, интеграции, тестирования, развертывания и мониторинга, способствуя инновациям, гибкости и масштабируемости.
Ключевые моменты:
🎯 Цель: ускорение релизов через тесное взаимодействие разработчиков и администраторов.
🛠 Инструменты: CI/CD (GitHub Actions, GitLab CI, Jenkins), Kubernetes, Terraform, Ansible, Go.
💡 Идея: Автоматизация и инфраструктура как код (IaC) позволяют обеспечивать быстрые и надёжные обновления без даунтайма.
DevSecOps (Development + Security + Operations)
Что это?
DevSecOps — это DevOps с интегрированной безопасностью. В отличие от традиционного подхода, где безопасность добавляется в конце разработки, здесь она встроена в каждый этап разработки, превращая её в общую ответственность команды.
Ключевые моменты:
🎯 Цель: встроить безопасность на всех этапах CI/CD процесса.
🛠 Инструменты: SAST/DAST (SonarQube, Snyk, OWASP ZAP), системы управления секретами (Vault, Sealed Secrets).
💡 Идея: Безопасность — это не отдельная проверка перед релизом, а часть всего процесса разработки.
MLOps (Machine Learning + Operations)
Что это?
MLOps — это DevOps для машинного обучения, обеспечивающий автоматизированное развертывание и управление ML-моделями в продакшене.
Ключевые моменты:
🎯 Цель: обеспечить непрерывную интеграцию, тестирование, развертывание и мониторинг ML-моделей.
🛠 Инструменты: MLflow, Kubeflow, TensorFlow Extended (TFX), Apache Airflow.
💡 Идея: Автоматизация и контроль качества жизненного цикла моделей критичны для успешного внедрения. ML — это не только тренировка модели, но и её продакшен.
SecOps (Security Operations)
Что это?
SecOps интегрирует безопасность в повседневные IT-операции, снижая риски кибератак.
Ключевые моменты:
🎯 Цель: автоматизировать критически важные задачи по безопасности и быстро реагировать на угрозы.
💡 Идея: Безопасность должна быть встроенной в процессы
SaaSOps (SaaS Operations)
Что это?
SaaSOps занимается управлением и оптимизацией облачных приложений, предоставляемых по модели Software-as-a-Service.
Ключевые моменты:
🎯 Цель: улучшить управление доступом, обеспечить безопасность и повысить эффективность поддержки SaaS-приложений.
💡 Идея: Автоматизация процессов управления SaaS помогает повысить удовлетворённость пользователей и эффективность команд.
Что это?
SecOps интегрирует безопасность в повседневные IT-операции, снижая риски кибератак.
Ключевые моменты:
🎯 Цель: автоматизировать критически важные задачи по безопасности и быстро реагировать на угрозы.
💡 Идея: Безопасность должна быть встроенной в процессы
SaaSOps (SaaS Operations)
Что это?
SaaSOps занимается управлением и оптимизацией облачных приложений, предоставляемых по модели Software-as-a-Service.
Ключевые моменты:
🎯 Цель: улучшить управление доступом, обеспечить безопасность и повысить эффективность поддержки SaaS-приложений.
💡 Идея: Автоматизация процессов управления SaaS помогает повысить удовлетворённость пользователей и эффективность команд.
❤1
SRE (Site Reliability Engineering)
Что это?
SRE фокусируется на обеспечении стабильности и отказоустойчивости сервисов, объединяя инженерные подходы разработки и эксплуатации. SRE это в первую очередь про продакшен и мониторинг.
Ключевые моменты:
🎯 Цель: минимизация сбоев, повышение доступности и эффективное управление инцидентами.
🛠 Инструменты: Мониторинг (Prometheus, Grafana), хаос-тестирование (Chaos Monkey), метрики SLA/SLO/SLI.
💡 Идея: SRE — это DevOps с акцентом на надежность и управляемость продакшен систем.
GitOps
Что это?
GitOps - методология, котоаря использует Git как единственный источник правды для управления инфраструктурой.
Ключевые моменты:
🎯 Цель: стандартизировать процессы развертывания и обеспечить прозрачность изменений.
🛠 Инструменты: ArgoCD, Flux, Jenkins X
💡 Идея: Версионный контроль помогает быстро откатывать изменения и повышает безопасность обновлений.
AIOps (Artificial Intelligence for IT Operations)
Что это?
AIOps применяет машинное обучение и аналитику больших данных для автоматизации мониторинга и управления инцидентами.
Ключевые моменты:
🎯 Цель: автоматическое обнаружение и устранение проблем в реальном времени. Поиск аномалий.
💡Идея: AI помогает командам быстрее реагировать на сбои и снижать нагрузку на инженеров.
NoOps (No Operations)
Что это?
NoOps — концепция, при которой традиционные операционные команды становятся ненужными благодаря полной автоматизации в облаке.
Ключевые моменты:
🎯 Цель: максимальная автоматизация инфраструктуры. Минимизация операционных затрат.
🕒 Когда используется: в облачных средах (AWS Lambda, Google Cloud Run, FaaS)
💡Идея: Если всё управляется облаком, зачем нужны Ops-инженеры?
ChatOps
Что это?
ChatOps позволяет управлять процессами через чат-платформы, интегрируя DevOps-инструменты в мессенджеры.
Ключевые моменты:
🎯 Цель: автоматизация команд и управление через Slack, Microsoft Teams, Discord.
💡Идея: Рабочие процессы и мониторинг в одном месте делают командную работу эффективнее.
FinOps (Finance + Operations)
Что это?
FinOps помогает компаниям управлять облачными расходами, объединяя финансовые и инженерные команды.
Ключевые моменты:
🏗Фазы: Inform (осведомлённость и распределение затрат), Optimize (оптимизация расходов) и Operate (управление ROI).
💡 Идея: Совместное управление бюджетом и ресурсами повышает экономическую эффективность и прозрачность расходов.
DataOps (Data Operations)
Что это?
DataOps автоматизирует обработку данных, улучшая их качество и ускоряя аналитические процессы.
Ключевые моменты:
🎯 Цель: наладить работу между дата-инженерами и командами разработки.
💡 Идея: Автоматизация процессов обработки данных позволяет устранить повторяющиеся задачи и повысить точность результатов.
ContentOps (Content Operations)
Что это?
ContentOps отвечает за весь жизненный цикл цифрового контента: от создания и редактирования до публикации и архивирования.
Ключевые моменты:
🎯 Цель: обеспечить координацию между отделами и своевременность публикаций
💡 Идея: Автоматизация контент-процессов помогает быстрее создавать и публиковать материалы без дублирования и ошибок
ITOps (IT Operations)
Что это?
ITOps охватывает классические IT-операции, включая поддержку пользователей и администрирование инфраструктуры.
Ключевые моменты:
🎯 Цель: бесперебойная работа IT-сервисов.
💡 Идея: Классическое администрирование IT-инфраструктуры.
Что это?
SRE фокусируется на обеспечении стабильности и отказоустойчивости сервисов, объединяя инженерные подходы разработки и эксплуатации. SRE это в первую очередь про продакшен и мониторинг.
Ключевые моменты:
🎯 Цель: минимизация сбоев, повышение доступности и эффективное управление инцидентами.
🛠 Инструменты: Мониторинг (Prometheus, Grafana), хаос-тестирование (Chaos Monkey), метрики SLA/SLO/SLI.
💡 Идея: SRE — это DevOps с акцентом на надежность и управляемость продакшен систем.
GitOps
Что это?
GitOps - методология, котоаря использует Git как единственный источник правды для управления инфраструктурой.
Ключевые моменты:
🎯 Цель: стандартизировать процессы развертывания и обеспечить прозрачность изменений.
🛠 Инструменты: ArgoCD, Flux, Jenkins X
💡 Идея: Версионный контроль помогает быстро откатывать изменения и повышает безопасность обновлений.
AIOps (Artificial Intelligence for IT Operations)
Что это?
AIOps применяет машинное обучение и аналитику больших данных для автоматизации мониторинга и управления инцидентами.
Ключевые моменты:
🎯 Цель: автоматическое обнаружение и устранение проблем в реальном времени. Поиск аномалий.
💡Идея: AI помогает командам быстрее реагировать на сбои и снижать нагрузку на инженеров.
NoOps (No Operations)
Что это?
NoOps — концепция, при которой традиционные операционные команды становятся ненужными благодаря полной автоматизации в облаке.
Ключевые моменты:
🎯 Цель: максимальная автоматизация инфраструктуры. Минимизация операционных затрат.
🕒 Когда используется: в облачных средах (AWS Lambda, Google Cloud Run, FaaS)
💡Идея: Если всё управляется облаком, зачем нужны Ops-инженеры?
ChatOps
Что это?
ChatOps позволяет управлять процессами через чат-платформы, интегрируя DevOps-инструменты в мессенджеры.
Ключевые моменты:
🎯 Цель: автоматизация команд и управление через Slack, Microsoft Teams, Discord.
💡Идея: Рабочие процессы и мониторинг в одном месте делают командную работу эффективнее.
FinOps (Finance + Operations)
Что это?
FinOps помогает компаниям управлять облачными расходами, объединяя финансовые и инженерные команды.
Ключевые моменты:
🏗Фазы: Inform (осведомлённость и распределение затрат), Optimize (оптимизация расходов) и Operate (управление ROI).
💡 Идея: Совместное управление бюджетом и ресурсами повышает экономическую эффективность и прозрачность расходов.
DataOps (Data Operations)
Что это?
DataOps автоматизирует обработку данных, улучшая их качество и ускоряя аналитические процессы.
Ключевые моменты:
🎯 Цель: наладить работу между дата-инженерами и командами разработки.
💡 Идея: Автоматизация процессов обработки данных позволяет устранить повторяющиеся задачи и повысить точность результатов.
ContentOps (Content Operations)
Что это?
ContentOps отвечает за весь жизненный цикл цифрового контента: от создания и редактирования до публикации и архивирования.
Ключевые моменты:
🎯 Цель: обеспечить координацию между отделами и своевременность публикаций
💡 Идея: Автоматизация контент-процессов помогает быстрее создавать и публиковать материалы без дублирования и ошибок
ITOps (IT Operations)
Что это?
ITOps охватывает классические IT-операции, включая поддержку пользователей и администрирование инфраструктуры.
Ключевые моменты:
🎯 Цель: бесперебойная работа IT-сервисов.
💡 Идея: Классическое администрирование IT-инфраструктуры.
❤1👍1
Вывод
IT-мир развивается, и «ops»-методологии адаптируются к новым вызовам:
✅ DevOps, NoOps, MLOps, DevSecOps, SRE ускоряют разработку и обеспечивают стабильность.
✅ FinOps, DataOps, GitOps, AIOps, ContentOps, ChatOps, ITOps, SecOps, SaaSOps помогают оптимизировать процессы, затраты и безопасность.
Вопрос не в том, какой подход выбрать, а как их комбинировать для максимальной эффективности. А какие «ops» знаете вы? 🤔👇
PS: Отличный доклад про это с DevOpsConf 2021: https://www.youtube.com/watch?v=Am84iPcVZlc
IT-мир развивается, и «ops»-методологии адаптируются к новым вызовам:
✅ DevOps, NoOps, MLOps, DevSecOps, SRE ускоряют разработку и обеспечивают стабильность.
✅ FinOps, DataOps, GitOps, AIOps, ContentOps, ChatOps, ITOps, SecOps, SaaSOps помогают оптимизировать процессы, затраты и безопасность.
Вопрос не в том, какой подход выбрать, а как их комбинировать для максимальной эффективности. А какие «ops» знаете вы? 🤔👇
PS: Отличный доклад про это с DevOpsConf 2021: https://www.youtube.com/watch?v=Am84iPcVZlc
YouTube
Несуществующие твари и где они обитают. Виды DevOps-инженеров / Кирилл Демченко, Владимир Утратенко
Приглашаем на DevOpsConf 2025, которая пройдет 7 и 8 апреля 2025 в Сколково в Москве.
Программа, подробности и билеты по ссылке: https://devopsconf.io/moscow/2025
---------
DevOpsConf 2021
Профессиональная конференция по интеграции процессов разработки…
Программа, подробности и билеты по ссылке: https://devopsconf.io/moscow/2025
---------
DevOpsConf 2021
Профессиональная конференция по интеграции процессов разработки…
❤1
2️⃣ Навигация по второму дню андерхуда
— Kubernetes — новый язык для разработки инфраструктуры?
— OpenTofu vs Terraform. Что использовать в 2025
— Лучшие инструменты для Terraform и OpenTofu в 2025 году
— *Ops — в чём разница?
— Kubernetes — новый язык для разработки инфраструктуры?
— OpenTofu vs Terraform. Что использовать в 2025
— Лучшие инструменты для Terraform и OpenTofu в 2025 году
— *Ops — в чём разница?
🔥2👍1
📜 Software Architecture Document: Что это такое и почему это необходимость для энтерпрайза и зло для стартапа
В IT архитектурная документация (Software Architecture Document, SAD) играет важную роль. Но в зависимости от контекста она может как помогать, так и тормозить процесс.
🔹 Что такое SAD?
SAD (грустная дока — это не только шутка, но и правда жизни) — это Software Architecture Document, документ, в котором описывается high-level архитектура системы. Обычно он разбит на разделы, каждый из которых охватывает одно ключевое архитектурное решение, связывающее бизнес-требования и техническую реализацию.
Альтернативные подходы к этим решениям часто выносятся в отдельный документ. В итоге SAD становится своего рода blueprint’ом проекта, с которого начинается имплементация.
Но всё не так радужно. Иногда такие документы раздуваются до 200–300 страниц, особенно если включают в себя C4-диаграммы, data flow, и прочие артефакты. Тут я могу только посоветовать учиться читать такие документы, а если на вашем проекте их нет — предложить архитектору или лиду заняться их написанием.
В IT архитектурная документация (Software Architecture Document, SAD) играет важную роль. Но в зависимости от контекста она может как помогать, так и тормозить процесс.
🔹 Что такое SAD?
SAD (грустная дока — это не только шутка, но и правда жизни) — это Software Architecture Document, документ, в котором описывается high-level архитектура системы. Обычно он разбит на разделы, каждый из которых охватывает одно ключевое архитектурное решение, связывающее бизнес-требования и техническую реализацию.
Альтернативные подходы к этим решениям часто выносятся в отдельный документ. В итоге SAD становится своего рода blueprint’ом проекта, с которого начинается имплементация.
Но всё не так радужно. Иногда такие документы раздуваются до 200–300 страниц, особенно если включают в себя C4-диаграммы, data flow, и прочие артефакты. Тут я могу только посоветовать учиться читать такие документы, а если на вашем проекте их нет — предложить архитектору или лиду заняться их написанием.
❤2
🔹 Почему энтерпрайзу нужен SAD?
✅ Сложные системы — нужна прозрачность
В корпоративных (enterprise) системах много команд, легаси-код, сложные интеграции. Без архитектурной документации разработчики просто не поймут, как всё работает.
✅ Безопасность и соответствие требованиям
Для банков, финтеха и госкомпаний документирование архитектуры необходимо для аудитов и сертификаций (SOC2, ISO 27001, PCI DSS, ГОСТ).
✅ Контроль и масштабируемость
В больших компаниях архитектурные решения принимаются годами. Документация фиксирует прошлые решения, чтобы не наступать на те же грабли.
🔹 Почему стартапам SAD вреден?
❌ Медленный процесс
На стартапах нельзя тратить время на бумажную работу. На этапе разработки MVP важнее быстро проверять гипотезы и выпускать продукт. Пока стартап пишет архитектуру, конкуренты уже пивотят свой продукт.
❌ Архитектура меняется слишком быстро
В стартапах архитектура и код переписываются каждые несколько месяцев. Писать документацию в таких условиях — значит тратить время на создание заранее устаревающего артефакта.
❌ Фокус должен быть на продукте
Вместо того чтобы писать длинные SAD, стартапу лучше фиксировать архитектурные решения в коротких ADR (Architecture Decision Records). Это более гибкий и быстрый формат. Многие ребята это делают прямо в Notion без особого формализма.
🔹 А что насчёт Open Source проектов?
Для Open Source проектов нет строгих стандартов, аналогичных SAD. Конечно, в больших проектах есть roadmap и подробное обсуждения фич, но общего документа, как правило, нет. Однако есть похожий формат — EP (Enhancement Proposal). EP - подробное описание одной фичи, часто схожее с SAD по духу. Хорошим примером являются KEP (Kubernetes Enhancement Proposals), которые могут быть полезными для изучения.
🔹 Что использую я?
Когда стартует новый проект или появляется большая фича, я предпочитаю писать документы в духе SAD — пусть и без фанатизма, но с описанием ключевых решений и архитектурных идей.
А вот для небольших проектов или на этапе раннего старта мне вполне хватает ADR-ов, зафиксированных в вики. Главное — чтобы команда всё это обсудила и была на одной волне.
А у вас на проекте есть SAD, или хватает быстрых записей и ADR? 🤔👇
✅ Сложные системы — нужна прозрачность
В корпоративных (enterprise) системах много команд, легаси-код, сложные интеграции. Без архитектурной документации разработчики просто не поймут, как всё работает.
✅ Безопасность и соответствие требованиям
Для банков, финтеха и госкомпаний документирование архитектуры необходимо для аудитов и сертификаций (SOC2, ISO 27001, PCI DSS, ГОСТ).
✅ Контроль и масштабируемость
В больших компаниях архитектурные решения принимаются годами. Документация фиксирует прошлые решения, чтобы не наступать на те же грабли.
🔹 Почему стартапам SAD вреден?
❌ Медленный процесс
На стартапах нельзя тратить время на бумажную работу. На этапе разработки MVP важнее быстро проверять гипотезы и выпускать продукт. Пока стартап пишет архитектуру, конкуренты уже пивотят свой продукт.
❌ Архитектура меняется слишком быстро
В стартапах архитектура и код переписываются каждые несколько месяцев. Писать документацию в таких условиях — значит тратить время на создание заранее устаревающего артефакта.
❌ Фокус должен быть на продукте
Вместо того чтобы писать длинные SAD, стартапу лучше фиксировать архитектурные решения в коротких ADR (Architecture Decision Records). Это более гибкий и быстрый формат. Многие ребята это делают прямо в Notion без особого формализма.
🔹 А что насчёт Open Source проектов?
Для Open Source проектов нет строгих стандартов, аналогичных SAD. Конечно, в больших проектах есть roadmap и подробное обсуждения фич, но общего документа, как правило, нет. Однако есть похожий формат — EP (Enhancement Proposal). EP - подробное описание одной фичи, часто схожее с SAD по духу. Хорошим примером являются KEP (Kubernetes Enhancement Proposals), которые могут быть полезными для изучения.
🔹 Что использую я?
Когда стартует новый проект или появляется большая фича, я предпочитаю писать документы в духе SAD — пусть и без фанатизма, но с описанием ключевых решений и архитектурных идей.
А вот для небольших проектов или на этапе раннего старта мне вполне хватает ADR-ов, зафиксированных в вики. Главное — чтобы команда всё это обсудила и была на одной волне.
А у вас на проекте есть SAD, или хватает быстрых записей и ADR? 🤔👇
👍2🔥1