Infrastructure as Data IaaD
Infrastructure as Data (IaaD): ¿La Evolución del IaC?
¿Conoces el concepto de Infrastructure as Data (IaaD)?
Si tienes más de diez años de experiencia en TI o estás aprendiendo cómo funcionan las infraestructuras más recientes, probablemente ya usaste el formato de datos que propone. Pero ¿qué diferencia al IaaD de nuestro conocido Infrastructure as Code (IaC)?
La propuesta del IaaD es una nueva manera de crear y gestionar la infraestructura, describiendo un enfoque donde la configuración y el estado deseado de la infraestructura son tratados primariamente como datos, y no como código de aplicación tradicional.
Nota: Aunque el nombre del blog sea infraascode.com.br, es fundamental entender que el IaaD puede verse como una filosofía más restringida y poderosa dentro del dominio del IaC, buscando resolver algunas de sus complejidades. ¡Es un enfoque que vale mucho la pena conocer!
El Concepto IaaD: Separación de Lógica y Descripción
Para crear una infraestructura por medio del modelo IaaD, es necesario describir el entorno utilizando formatos de datos estructurados, como YAML o JSON.
Lo que realmente diferencia al IaaD del IaC tradicional es el foco: la idea principal es describir el estado final de la infraestructura (el “qué”) en un formato de datos simple, legible y puramente declarativo.
La complejidad y la lógica del aprovisionamiento no están en tu archivo de descripción. En cambio, un sistema de aprovisionamiento (el engine o controller) queda enteramente responsable de:
- Descubrir las etapas necesarias para alcanzar ese estado.
- Monitorear activamente la infraestructura.
- Garantizar que el estado real siempre corresponda al estado deseado (lo que llamamos reconciliación).
Este modelo propone una separación clara entre lo que es la descripción de la infraestructura (los datos) y la lógica para aprovisionarla (el mecanismo de aprovisionamiento).
El objetivo es minimizar la deuda técnica y la complejidad que surgen al tratar la infraestructura como un software complejo con Domain-Specific Languages (DSLs). La descripción en formato de datos tiende a ser más simple y enfocada en el resultado, facilitando el versionado y la trazabilidad.
IaaD vs. IaC: ¿Dónde Vive la Lógica?
El Infrastructure as Code (IaC) es el concepto más establecido, donde usamos prácticas de desarrollo de software (control de versiones, pruebas, CI/CD) para gestionar la infraestructura. El problema surge cuando el IaC evoluciona hacia un “DSL Complejo” lleno de loops, condicionales y lógica embebida, transformando tus archivos de infraestructura en código de software difícil de mantener.
El IaaD es una filosofía que argumenta que la lógica compleja de aprovisionamiento debe ser abstraída y gestionada por un engine dedicado.
Vamos a comparar los dos enfoques utilizando un ejemplo práctico: la creación de un bucket S3:
Infrastructure as Code (IaC) - Ejemplo: Terraform
En el IaC con Terraform, utilizas el HashiCorp Configuration Language (HCL). Aunque sea declarativo, el HCL es un lenguaje de dominio específico que combina la descripción del recurso con cierto nivel de lógica:
- Lenguaje Dedicado: Escribes en un lenguaje con sus propias reglas de sintaxis, bloques y expresiones.
- Lógica en el Código de Infraestructura: Si necesitas lógica compleja (como crear múltiples recursos con base en una lista, o condicionales), la embeberás en el HCL (con
for_each,count, o expresionesif/else). - El “Código” es la Infraestructura.
1resource "aws_s3_bucket" "meu_bucket" {
2 bucket = "meu-projeto-iac-bucket-s3"
3 acl = "private"
4
5 tags = {
6 Nome = "BucketIaC"
7 Ambiente = "Dev"
8 }
9}
Infrastructure as Data (IaaD) - Ejemplo: Crossplane
En el IaaD con Crossplane (que se integra al ecosistema Kubernetes), no estás escribiendo un DSL de infraestructura, sino un archivo de datos estructurados (YAML) que se conforma al esquema de una API de Kubernetes (CRD).
- Definición como Data: Rellenas un objeto de datos (YAML) en un formato API estándar.
- Lógica Separada (en el Engine): La lógica compleja (como gestionar dependencias, retry failures, y reconciliar continuamente el estado) está totalmente encapsulada y gestionada por el Controller (el “engine” de Crossplane), que es un software corriendo en segundo plano.
- El “Data” Describe la Infraestructura.
1apiVersion: s3.aws.crossplane.io/v1beta1
2kind: Bucket
3metadata:
4 name: meu-projeto-iaad-bucket
5spec:
6 forProvider:
7 region: us-east-1
8 acl: private
9 tags:
10 - key: Nome
11 value: BucketIaaD
12 - key: Ambiente
13 value: Dev
Comparativo Detallado
El punto clave es dónde reside la lógica y cómo se gestiona el drift del entorno:
| Característica | IaC - Terraform | IaaD - Crossplane |
|---|---|---|
| Foco Principal | Descripción del Estado + Lógica de Aprovisionamiento | Descripción puramente de Datos (Estado Final) |
| Lenguaje | DSL dedicado (HCL, Python/CDK, JSON/ARM) | Formato de datos estructurados (YAML/JSON) |
| Lógica | Embebida en el código de infraestructura (loops, condicionales) | Totalmente abstraída y gestionada por el Engine/Controller |
| Gestión de Drift | Ejecución puntual (apply en el CI/CD). Requiere monitoreo externo. |
Reconciliación Continua (Controller activo). El sistema repara el drift automáticamente. |
| Aplicaciones | Aprovisionamiento inicial, gestión de recursos complejos. | Gestión de estado continuo, Plataformas de Nube Interna (ICPs). |
Conclusión
IaC es el término más antiguo y abarcador, englobando casi todas las prácticas modernas de aprovisionamiento en la nube. Ofrece gran flexibilidad para crear lógica compleja y extensible, pero impone el costo de gestionar esa complejidad de código. IaaD es una filosofía poderosa dentro del IaC. Es un enfoque más simple y restrictivo que argumenta que la lógica de aprovisionamiento debe moverse hacia un mecanismo que interpreta los datos, manteniendo las definiciones de infraestructura como datos simples y legibles.
En resumen, mientras el IaC se trata de gestionar la infraestructura con código, el IaaD sugiere que la mejor forma de código para infraestructura es su descripción pura en formato de datos, delegando la complejidad del cómo a un engine dedicado. Este post no es para decir quién es mejor o peor, sino para decir que hay gente pensando en alternativas a las herramientas de IaC; eso me parece lo importante y creo que vale la pena estar atento a esto.
¡Un abrazo!
¡Larga y próspera vida a todos!
Referencias
- https://developer.hashicorp.com/terraform/docs
- https://aws.amazon.com/pt/cloudformation/
- https://docs.aws.amazon.com/pt_br/cloudformation/
- https://docs.crossplane.io/
- https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
Entre em contato:
NewsLetter - https://engineeringmanager.com.br/Linkdin - linkedin.com/in/leonardoml/
Twitter: @infraascode_br
Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!
|
|
