Skip to content

As-Code как ДНК актуальной инженерной культуры

Недавно на митапе о стандарте разработки нам с Heads of Profession задали вопрос, который завис в воздухе, как нерешенный баг в коде. Пятый по популярности в сообществе, он звучал так:

“А что за потребность всё делать %-as-code? Какая от этого польза? Зачем число комитящих в код?”

Мы, как архитекторы инженерной культуры, внедряем лучшие практики и подходы: Infrastructure-as-Code, API-First, unit-тесты, компонентное тестирование, TBD (trunk based development), GitOps, Doc As Cod, ..as code. Хаос необходимо упорядочить. Мы дорабатываем пайплайн, как инженеры, собирающие сеть в подвале старого дата-центра. Мы создаем условия для Continuous Deployment с продуктовыми платформами, где blue-green deployment и canary deployment становятся порталами для перехода прода из одного состояние в другое..

Каждый коммит — это шаг в будущее, где код уже не просто текст, а нить в живой ткани новой реальности. Число комитящих — это не просто метрика, это сигнал, что система жива, что она дышит, что она развивается. As-code — это философия, где всё, от инфраструктуры до документации, становится частью единого цифрового сада.

Я провалился в момент осознания вопроса в другой слой реальности, задумался об истории ..as code и собрал этот текст из разбросанных по сети слепков.

И когда кто-то спрашивает: “Зачем?”, я отвечаю: “Потому что иначе мы останемся в прошлом, где ручные процессы, как старые провода, тянут нас назад в тишину, замедляя каждый шаг. ” Мы строим мир, где as code не просто слова, код - наша новая реальность. И каждый, кто коммитит, становится частью этой вселенной.

Концепт "as code" зародился как реакция на вызовы современной ИТ-индустрии: сложность, скорость изменений и необходимость автоматизации.
As code концепт стал естественным продолжением эволюции разработки, где код стал не только инструментом создания программ, но и способом управления инфраструктурой, документацией, архитектурой и политиками. Этот подход продолжает развиваться, интегрируя новые технологии, такие как AI, и становится стандартом для современных ИТ-компаний

"as code" глубоко корнями тонет в 1970-е годах. Ранние инструменты, такие как Unix "make" и PXE boot, заложили фундамент для автоматизации конфигураций, которые позже эволюционировали в современные подходы, такие как Infrastructure-as-Code, Documentation-as-Code и GitOps. Это подчеркивает, что "as code" — это не просто тренд, а естественное развитие технологий, направленное на упрощение управления сложными системами.

Если хотите глубже погрузиться в историю, рекомендую изучить материалы по эволюции конфигурационных инструментов, которые показывают, как идеи 1970-х годов повлияли на современные практики.

As Code - это актуальная реальность

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

Для начала давайте разберемся

Почему ИТ-сообщество стремится всё делать в Git?

Git — это не просто система контроля версий, это универсальный инструмент для управления изменениями. Вот ключевые причины, почему ИТ-сообщество стремится всё делать в Git:

  • История изменений: Git хранит всю историю изменений, что позволяет отслеживать, кто, когда и что сделал. Это критически важно для анализа и отката ошибок.
  • Коллаборация: Git позволяет нескольким людям работать над одним проектом одновременно, не мешая друг другу.
  • Прозрачность: Все изменения видны, их можно обсудить, проверить и улучшить через механизмы pull/merge requests.
  • Автоматизация: Git интегрируется с CI/CD (Continuous Integration/Continuous Deployment), что позволяет автоматизировать тестирование, сборку и деплой.
    Работа в git помогает “все иметь под рукой” и способствует упрощению в создании систем поддержки и контроля стандарта ИТ Производства.
  • Безопасность: Git позволяет контролировать доступ к коду и данным через ролевую модель и механизмы проверки изменений.

История возникновения гит.
Сначала был гит.

Короткая история рождения Git
Git появился в 2005 году как ответ на кризис в разработке ядра Linux. До этого разработчики использовали проприетарную систему контроля версий BitKeeper, но из-за юридических споров её использование стало невозможным. Линус Торвальдс, создатель Linux, решил создать собственную систему, которая бы отвечала потребностям крупных распределённых проектов. Прекрасный пример проактивной позиции: если тебя что-то не устраивает, ты разрабатываешь инструмент сам для решения задачи. Ты реагируешь на боли не нытьем, а делом оставляя боль позади.

Ключевые моменты:

  1. Проблема: Linux-сообщество осталось без инструмента для управления кодом. Существующие системы (например, CVS, Subversion) не подходили для масштабных проектов.
  2. Цель: Торвальдс хотел создать систему, которая бы:
  3. Была быстрой.
  4. Поддерживала распределённую разработку.
  5. Гарантировала целостность данных (через хеши SHA-1).
  6. Разработка: Git был создан всего за 10 дней. Первая версия была настолько проста, что Торвальдс называл её "игрушечной", но она уже решала ключевые задачи.
  7. Философия: Git был разработан с акцентом на децентрализацию. Каждый разработчик имеет полную копию репозитория, что делает процесс более гибким и устойчивым.

Эволюция:

  • 2005: Первый релиз Git.
  • 2008: Появление GitHub, который популяризировал Git среди разработчиков.
  • Сейчас: Git стал стандартом де-факто для контроля версий, используемым миллионами разработчиков по всему миру.

Git родился из необходимости и стал революцией в мире разработки. Его простота, скорость и распределённая природа сделали его незаменимым инструментом для команд любого масштаба.

Предпосылки появления "as code"

  • Автоматизация и стандартизация: В 1990-х годах с развитием DevOps и Agile-методологий возникла потребность в автоматизации процессов разработки и управления инфраструктурой. Это стало основой для появления подходов, где всё описывается в виде кода
  • Распространение систем контроля версий: Git, появившийся в 2005 году, стал ключевым инструментом для управления изменениями, что сделало возможным хранение и версионирование не только кода, но и документации, конфигураций и архитектуры

Infrastructure as Code (IaC)

  • Что это: Описание инфраструктуры (серверы, сети, базы данных) в виде кода (например, с помощью Terraform, Ansible, CloudFormation).
  • Зачем: Чтобы инфраструктура была воспроизводимой, предсказуемой и легко управляемой.
  • Пример: Вместо ручного создания серверов в облаке вы описываете их в коде и разворачиваете одной командой.

Когда мы слышим термин "Infrastructure-as-Code" (IaC), мы обычно думаем о современных инструментах, таких как Chef, Ansible или Terraform. Однако сама идея управления конфигурациями и инфраструктурой через код уходит корнями в 1970-е годы. Уже тогда инженеры сталкивались с необходимостью автоматизации управления парками машин, будь то физические серверы или виртуальные системы.

Ранние инструменты конфигурации

  1. Unix "make" (1976):
  2. Один из первых инструментов, который позволял автоматизировать сборку и настройку программного обеспечения.
  3. Хотя "make" не был полноценным инструментом управления инфраструктурой, он заложил основы для автоматизации задач конфигурации.
  4. PXE boot (1981):
  5. Позволял загружать и настраивать целые машины по сети, что стало прообразом современных подходов к управлению инфраструктурой.
  6. Это был важный шаг к автоматизации, хотя и не в том виде, к которому мы привыкли сегодня.

Эволюция к современным инструментам

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

  • 1990-е: Появление CFEngine (1993) стало следующим шагом в эволюции. Это был один из первых инструментов, который позволял управлять конфигурациями на множестве машин.
  • 2000-е: С развитием облачных технологий и DevOps появились более мощные инструменты, такие как Puppet (2005) и Chef (2009), которые сделали управление инфраструктурой через код стандартом.

  • 2010-е: Terraform (2014) и Ansible (2012) стали лидерами в области IaC, предлагая более гибкие и мощные решения для управления облачной инфраструктурой.

  • 2013: Docker

  • 2014: Kubernetes + Terraform
  • 2017: Pulumi
  • 2021: Brainboard

Хотя инфраструктура как код (IaC) может показаться современной концепцией, на самом деле она уходит корнями в историю зарождения машин. Со временем мы решали одни и те же проблемы с разных сторон, создавая слои абстракции для решения проблем, которые инженеры уже решили.

Documentation as Code (Docs as Code)

  • Что это: Документация пишется в формате, который легко версионировать (Markdown, AsciiDoc) и хранить в Git.
  • Зачем: Чтобы документация всегда была актуальной, доступной и синхронизированной с кодом.

  • Пример: Документация API или архитектуры хранится в репозитории рядом с кодом. Docs-as-Code гарантирует, что ваша документация останется актуальной, не замедляя разработку, а дополняя ее становясь частью процесса разработки и развиваясь в гит совместно с кодом. При таком подходе достижимо одно важное преимущество Docs-as-Code - актуальность документации в соответствии с кодом.

  • Ранние примеры: Ещё в 2000-х годах крупные компании, такие как Microsoft, начали использовать внутренние инструменты для генерации документации из исходного кода. Например, документация .NET Framework создавалась с помощью автоматизированных процессов.

  • Формализация концепции: Термин Docs as Code был популяризирован в 2010-х годах, когда такие инструменты, как Markdown, AsciiDoc и Sphinx, стали широко использоваться для создания и управления документацией в репозиториях Git.

Architecture as Code (AaC)

  • Что это: Описание архитектуры системы в виде кода (например, с помощью DSL — Domain Specific Language).
  • Зачем: Чтобы архитектура была понятной, проверяемой и легко изменяемой.

  • Пример: Использование инструментов вроде Structurizr или PlantUML для описания диаграмм и зависимостей.
    например https://c4model.co/m/

  • Появление: Подход Architecture as Code начал развиваться в 2010-х годах с появлением инструментов, таких как Structurizr (2014), которые позволяли описывать архитектурные схемы в виде кода и автоматически генерировать диаграммы.

  • Современное применение: Сегодня AaC используется для описания архитектуры систем в формате (например c4), который можно версионировать и тестировать, что делает его частью DevOps-практик.

C4-модель (https://c4model.com) — это популярный подход к визуализации архитектуры программного обеспечения, который помогает разработчикам и архитекторам лучше понимать сложные системы. В сочетании с подходом Architecture as Code (AaC) C4-модель становится мощным инструментом для описания архитектуры в виде кода, что позволяет автоматизировать создание диаграмм, документирование и анализ систем.

Хотя конкретные компании редко публично афишируют использование C4-модели или AaC, есть несколько примеров и индустрий, где эти подходы активно применяются:

1. Крупные технологические компании

  • Microsoft: Использует C4-модель для документирования архитектуры своих облачных сервисов, таких как Azure. Подход Architecture as Code помогает автоматизировать создание диаграмм и поддерживать документацию в актуальном состоянии.
  • Amazon (AWS): Внутренние команды AWS используют C4-модель для описания архитектуры своих сервисов, а инструменты AaC помогают интегрировать эти описания в CI/CD-процессы.

2. Финансовые организации

  • Banks and FinTech: Многие банки и финтех-компании используют C4-модель для документирования сложных распределённых систем. Например, ING и Goldman Sachs применяют AaC для автоматизации создания архитектурных диаграмм и проверки соответствия стандартам.

3. Консалтинговые и IT-компании

  • ThoughtWorks: Активно продвигает использование C4-модели и Architecture as Code в своих проектах. Они разрабатывают инструменты и практики для интеграции AaC в процессы разработки.
  • Red Hat: Использует C4-модель для документирования архитектуры своих решений, таких как OpenShift, и применяет AaC для автоматизации создания диаграмм.

ДокХаб
X5 активно использует и применяет C4-модель для документирования архитектуры.

Policy as Code

  • Что это: Описание правил и политик (например, безопасности или доступа) в виде кода.
  • Зачем: Чтобы автоматизировать проверку и обеспечение compliance (соответствия требованиям).

  • Пример: Использование Open Policy Agent (OPA) для описания политик безопасности.

  • Развитие: Подход Policy as Code стал популярным с появлением инструментов, таких как Open Policy Agent (OPA) и Hashicorp Sentinel, которые позволяют описывать политики безопасности и compliance в виде кода. Это стало особенно востребованным в облачных средах.

GitOps и GitSecOps

GitOps — это подход к управлению инфраструктурой и приложениями через Git.
Концепция GitOps была формализована в 2017 году компанией Weaveworks. Она предполагает использование Git как единого источника истины для управления инфраструктурой и приложениями.

  • Основная идея: Git становится единственным источником истины (single source of truth). Все изменения в инфраструктуре и приложениях вносятся через Git.
  • Как работает:
  • Инфраструктура и конфигурации описываются в коде (например, с помощью Kubernetes manifests).
  • Изменения в Git автоматически применяются с помощью CI/CD.
  • Преимущества:
  • Прозрачность: Все изменения видны в Git.
  • Автоматизация: Процессы деплоя и обновления автоматизированы.
  • Безопасность: Изменения проходят код-ревью и тестирование.

GitSecOps

Расширение GitOps с акцентом на безопасность стало развиваться в 2020-х годах, интегрируя проверки безопасности в CI/CD-процессы.

  • Основная идея: Безопасность интегрируется в процесс разработки и эксплуатации через Git.
  • Как работает:
  • Политики безопасности описываются в коде (Policy as Code).
  • Инструменты статического анализа кода (SAST) и анализа зависимостей (SCA) интегрируются в CI/CD.
  • Все изменения проверяются на соответствие требованиям безопасности.
  • Преимущества:
  • Раннее выявление уязвимостей.
  • Автоматизация проверок безопасности.
  • Соответствие стандартам (например, GDPR, HIPAA).

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

Полезные ссылки:

https://hackernoon.com/everything-as-code-explained-0ibg32a3

https://www.writethedocs.org/guide/docs-as-code/
https://medium.com/@EjiroOnose/understanding-docs-as-code-01b8c7644e23

https://medium.com/@mike_tyson_cloud/the-origins-of-infrastructure-as-code-a-brief-history-of-devops-a883d8877f19

https://cloud.google.com/deploy/docs/deployment-strategies/canary

https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html