I am Lino
30 de marzo de 2026

Infra as Code: por qué tu infraestructura merece versionado igual que tu código

Publicado el 30 de marzo de 2026  •  25 minutos  • 5206 palabras
Table of contents

Durante años hemos tratado infraestructura y software como si fueran dos religiones distintas con sus propios dioses, sus propios rituales y, sobre todo, sus propios culpables. El código estaba en Git, la infraestructura “en AWS”, como una cosa etérea que “ya se gestiona con scripts y con la consola”.

Pero la verdad es que tu infraestructura ya se comporta como software: tiene estados, dependencias, bugs, versiones y efectos secundarios cuando la cambias.

Infrastructure as Code no es tanto una moda como un ejercicio de coherencia: aceptar que, si tu producto vive en diez servicios cloud, docenas de recursos y tres entornos, seguir tratando la infraestructura como si fueran “tres servidores” es autoengañarse. Si se rompe, se rompe como se rompe el código: por cambios mal pensados.

La diferencia es que el código lo versionas y la infraestructura, si no haces nada, la toqueteas a pelo. Y eso, a estas alturas, roza lo suicida.

La escena del crimen: vida antes sin IaC

Son las 14:37 de un viernes. Alguien en el canal de incidencias escribe “producción caída”. El responsable de la infraestructura está de vacaciones en Lanzarote. El repositorio tiene un README.md que en la sección “Cómo levantar el entorno” pone “ver doc interna”, y la doc interna es un Google Doc editado por última vez en octubre de 2022 con el título (optimista) de “BORRADOR - infra v2 FINAL FINAL2”.

Nadie sabe exactamente qué hay en producción. Hay capturas de pantalla de la consola de AWS pegadas en Confluence que ya no corresponden a la realidad —las interfaces han cambiado dos veces desde entonces— y un script bash llamado setup_USAR_ESTE.sh que tiene un TODO: arreglar el tema de los puertos desde hace dieciséis meses. El firewall tiene puertos abiertos que nadie recuerda haber abierto. Hay tres instancias EC2 que nadie sabe para qué sirven pero nadie se atreve a apagar. Una de ellas se llama test2_def_FINAL y lleva facturando desde 2021.

Bienvenido al servidor copo de nieve (snowflake server), el anti-patrón que Martin Fowler describió hace ya más de una década y que sigue siendo la decoración habitual en incontables empresas: un servidor tan personalizado, tan lleno de configuraciones manuales, de parcheos ad hoc y de decisiones que “tenían sentido en su momento”, que se ha vuelto único e irreproducible. Como un copo de nieve, sí: precioso, irrepetible y condenado a derretirse en el momento más inoportuno. Nadie sabe qué hay dentro, y la verdad sobre “¿podríamos volver a montarlo si se cae?” es “en teoría, sí, pero tardaríamos días y rezaríamos mucho”.

Este patrón tiene un primo más moderno y aparentemente más sofisticado: el servidor fénix mal ejecutado. La teoría dice que un servidor fénix muere y renace desde cero con regularidad , por lo que nunca se estanca en un estado imposible de reproducir. La práctica en muchas organizaciones es: “tenemos un script que lo levanta, pero solo lo ha ejecutado Marcos, y Marcos ya no trabaja aquí”. El resultado es el mismo copo de nieve, pero creyéndose fénix.

No es que la gente sea descuidada o irresponsable. Es que hacer clic es lo más fácil, especialmente al principio. Consola abierta, recurso creado, problema resuelto, reunión en diez minutos. El coste no se paga hasta meses después, cuando hay que reproducir ese entorno en staging, o auditarlo, o recuperarlo tras un fallo. Y para entonces el conocimiento vive en la cabeza de una persona que puede estar de baja, en otro continente o simplemente haber olvidado qué hizo exactamente.

Amazon lo resume con la frialdad habitual de quien vende la solución: los procesos manuales son lentos, propensos a errores y no escalan. Pero el impacto real es más humano que técnico: el viernes a las 14:37, todos mirándose las caras, nadie con nada que desplegar, es el precio diferido de no haber escrito nada.

Qué es Infrastructure as Code (y qué problema viene a arreglar)

La Infraestructura como código (IaC) es la práctica de definir y gestionar recursos de infraestructura – máquinas virtuales, redes, balanceadores, bases de datos, roles de IAM, etc. – mediante ficheros de texto versionables, en lugar de hacer clic por la consola o lanzar comandos sueltos desde tu terminal.

En la práctica, IaC da respuesta a cuatro quebraderos de cabeza del equipo que gestiona infra:

Hay un concepto que distingue el IaC real de “un script bash con buena presentación”: la idempotencia .

Una operación idempotente produce el mismo resultado sin importar cuántas veces se ejecute.

Si ejecutas terraform apply y ya existe la infraestructura que describes, Terraform no crea otra igual por encima: comprueba el estado actual, lo compara con el código y solo actúa sobre las diferencias. Si no hay diferencias, no toca nada. Este comportamiento parece obvio hasta que lo contrastas con el mundo de los scripts imperativos, donde ejecutar create_server.sh dos veces puede terminar en dos servidores, una factura doble y una conversación incómoda con el equipo de finanzas.

Red Hat , AWS y otras llevan años con la misma cantinela: IaC reduce errores humanos, acelera despliegues y hace tu postureo de “DevOps” algo menos impostado.

¿Es IaC para ti? (sin anestesia)

Aquí es donde la mayoría de los artículos sobre IaC hacen trampa: te explican qué es, cuánto mola, y dan por sentado que la respuesta es “sí, adopta IaC ahora mismo”. Pero eso es hacerte trampas al solitario, y tú mereces una respuesta más útil.

Probablemente sí, si…

Tu equipo tiene más de una persona que toca la infraestructura. Con una sola persona que “sabe cómo está montado”, no tienes un problema de IaC, tienes un problema de bus factor —la pregunta incómoda de qué pasaría si esa persona se va o es atropellada por un autobús—. IaC no resuelve la rotación, pero sí hace que el conocimiento esté escrito en lugar de en la cabeza de alguien.

Gestionas más de un entorno (desarrollo, staging, producción, demo para el cliente, entorno de pruebas de seguridad…). A partir de dos entornos que quieres que se parezcan, el coste de mantenerlos sincronizados a mano empieza a comerse el tiempo de maneras poco habituales.

Trabajas en la nube y tus recursos cambian con frecuencia. Escalar, cambiar tipos de instancia, añadir regiones, ajustar permisos… cada una de esas operaciones manuales es una oportunidad de olvido o error. Si tu infraestructura en la práctica no cambia nunca, la ecuación cambia.

Tienes requisitos de cumplimiento normativo o auditoría. Si alguien puede pedirte demostrar quién cambió qué recurso y cuándo, un git log es infinitamente mejor que “bueno, creo que fue Pedro en algún momento de 2024”.

Probablemente no (todavía), si…

Es un proyecto personal, un experimento de fin de semana o algo que vas a tirar en tres meses. IaC tiene un coste de arranque real: escribir el código, aprender la herramienta, integrar el pipeline. Si el proyecto tiene más posibilidades de morir que de crecer, ese coste no se amortiza.

Tienes una sola instancia sencilla y no vas a añadir más. Una VM que no cambia, gestionada por una sola persona, en un entorno que no necesita reproducirse. En este caso, IaC es un martillo para un clavo que no existe.

Estás en plena fase de aprendizaje de cloud y todavía no entiendes bien qué recursos estás creando. Antes de automatizar, conviene entender qué estás automatizando. Pulsar botones en la consola al principio no es pecado: es exploración. El problema es quedarse ahí cuando ya sabes lo que necesitas.

La regla práctica que circula entre ingenieros veteranos es algo así: si vas a crear el mismo recurso más de dos veces, o si más de una persona necesita entender cómo está montada tu infraestructura, empieza a considerar IaC seriamente. Antes de eso, es optimización prematura.

Las familias: Terraform, OpenTofu, Pulumi, CDK y demás fauna

En el panorama de IaC hay tres herramientas que salen en todas las guías modernas : Terraform/OpenTofu, Pulumi y CDK.

Terraform fue durante mucho tiempo el rey del mambo: lenguaje declarativo propio (HCL), soporte para casi cualquier proveedor cloud, miles de módulos de la comunidad. Escribes “quiero una VPC, estas subredes, estos grupos de seguridad y una EC2” y Terraform habla con la API de AWS, calcula qué cambiar y lo aplica. Todo muy civilizado: plan para ver qué pasaría, apply para hacerlo realidad.

Hasta que llegó la cláusula de Netflix.

Bueno, no se llamaba así, pero casi.

En 2023 HashiCorp decidió cambiar la licencia de Terraform de MPL (open source de toda la vida) a Business Source License (BSL): el código se ve, pero hay limitaciones muy serias para que otras empresas monten servicios comerciales compatibles. El argumento oficial: “no queremos que los hyperscalers nos usen de base para ganar dinero sin contribuir”. El efecto colateral: cientos de equipos y proveedores que habían apostado por Terraform empezaron a oler a riesgo de lock-in y a decir “un momento”.

La respuesta fue OpenTofu : un fork de Terraform auspiciado por la Linux Foundation, con la misma sintaxis de HCL y la misma filosofía, pero bajo licencia realmente libre. El manifiesto de OpenTofu es básicamente una carta de amor al open source de siempre y una colleja elegante a HashiCorp: “gracias por todo, pero a partir de aquí seguimos por nuestra cuenta”. Hoy, muchas comparativas serias de IaC plantean directamente Terraform vs OpenTofu según cuánto te preocupen las implicaciones de la BSL.

En otro extremo está Pulumi, que dijo: “¿y si escribimos IaC en lenguajes normales?”. Nada de HCL ni YAML: usas TypeScript, Python, Go, C#, o lo que prefieras, con librerías que modelan recursos de AWS, Azure, GCP y compañía. Ventaja: puedes reutilizar ecosistema, tipado, librerías, tests… todo lo que ya conoces del lenguaje. Inconveniente: la comunidad y el catálogo aún son más pequeños que los de Terraform/OpenTofu, y tiendes a atarte más a la plataforma de Pulumi como tal.

Por último, AWS CDK (y sus primos en otros clouds) juegan la carta de “si ya estás en mi casa, quédate a vivir”: defines tu infraestructura AWS usando constructos de alto nivel en TypeScript, Python, Java, o algún otro oscuro lenguaje, que luego se traducen a CloudFormation por debajo. Es comodísimo si vives solo en AWS y te da igual el multi-cloud; menos útil si mañana quieres que el mismo stack funcione en Azure sin reescribir medio proyecto.

Las comparativas recientes vienen a decir: Terraform/OpenTofu si quieres multi-cloud y ecosistema masivo; CDK si eres fan de AWS y no piensas cambiarte; Pulumi si tu equipo dev quiere IaC en el mismo idioma que el backend y está dispuesto a tragarse más curva de aprendizaje.

Una última variable que no suele aparecer en los tutoriales es el dinero.

El CLI de Terraform y el de OpenTofu son gratuitos. La diferencia empieza cuando necesitas gestión de estado remoto en equipo, pipelines de CI/CD integrados o control de acceso fino: Terraform Cloud arranca gratis con uso limitado y pasa a unos 20 $/usuario/mes en el plan Team. OpenTofu, al ser open source puro, no tiene plan de pago propio: usas el backend remoto que quieras (S3, GitLab, etc.) y pagas por eso, no por la herramienta. Pulumi tiene un nivel gratuito con historial de estado limitado y pasa a unos 50 $/mes por el plan Team. AWS CDK es gratis como herramienta; pagas CloudFormation si superas el millón de llamadas al API al mes, lo que en proyectos normales no ocurre. La moraleja: para un equipo pequeño o mediano, el coste directo de la herramienta rara vez es el factor decisivo; el coste real está en el tiempo de aprendizaje y migración, del que hablaremos en la siguiente sección.

Por qué tu infraestructura merece git log igual que tu código

Imagina que tu código se mantuviera “a base de clics”: copiar/pegar desde Stack Overflow directamente en producción, cambios a mano en ficheros, sin control de versiones, sin pull requests. Te echarías a reír. O a llorar.

Eso es exactamente lo que sigue pasando en muchas infraestructuras.

Cuando describes tu infra como código, pasan varias cosas casi mágicas:

Tus servidores, redes y permisos dejan de ser “ese estado misterioso que hay ahora mismo en la consola” para convertirse en algo que se puede leer y discutir. Puedes hacer un git blame a un grupo de seguridad igual que a una función. Puedes ver, en un PR, que alguien propone abrir 0.0.0.0/0 al puerto 22 y devolverle un cariñoso “¿pero tú estás bien, chaval?”.

Tus entornos dejan de ser criaturas mutantes. Staging y producción se configuran con los mismos módulos, las mismas plantillas, cambiando variables (región, tamaños, cuentas) en lugar de repetir clics. No son gemelos idénticos – siempre hay particularidades–, pero dejan de ser primos lejanos.

Y, sobre todo, puedes volver atrás con cierto orden. Si aplicas un cambio que rompe medio chiringuito, tienes un commit concreto que revertir o corregir, no una sucesión de “creo que toqué esto y luego aquello” perpetrada desde un navegador.

Red Hat resumía los pros de IaC en tres palabras: velocidad, consistencia y control; los contras, sobre todo, en que ahora tus errores de diseño están codificados y pueden replicarse en todas partes. Pero, siendo sinceros, ya te equivocabas antes: al menos ahora dejas huellas.

El coste real de adoptar IaC

Que conste: IaC merece la pena. Pero hay una diferencia entre decirte “merece la pena” y ayudarte a entender lo que te vas a comer antes de que la inversión empiece a devolver algo.

La curva de aprendizaje inicial

Si vienes del mundo de “clic y funciona” o de shell scripts, las primeras semanas con Terraform o Pulumi serán… interesantes.

HCL no es difícil, pero tiene sus peculiaridades: los bloques de locals, la gestión de dependencias implícitas entre recursos, los ciclos que no son ciclos del todo, las funciones de interpolación. Estudios y encuestas en equipos que adoptaron IaC apuntan consistentemente a que la productividad baja durante las primeras dos a cuatro semanas mientras el equipo aprende la herramienta y los patrones. No es un fracaso; es el peaje de cualquier cambio de paradigma. Pero conviene planificarlo en lugar de descubrirlo el lunes que tienes que entregar.

El impuesto de la migración

Si ya tienes infraestructura funcionando, adoptar IaC no empieza con “crear recursos nuevos”: empieza con el tedioso proceso de describir en código lo que ya existe.

Antes de ver ningún beneficio, dedicas tiempo a escribir Terraform/OpenTofu para recursos que ya están ahí, importarlos al estado, verificar que el plan no destruye nada, y convencer a tu colega que lleva tres años con la consola abierta de que esto no es perder el tiempo. Este impuesto es real y la literatura técnica lo llama el “brownfield problem” : migrar infraestructura existente es siempre más lento y menos glamuroso que arrancar desde cero.

La resistencia humana

Hay un personaje en casi todos los equipos: la persona que “sabe cómo está montado todo”.

Esa persona ha acumulado años de conocimiento implícito, y la llegada de IaC significa externalizar ese conocimiento a un repositorio donde cualquiera puede verlo, cuestionarlo y cambiarlo. No siempre es bienvenida.

La adopción de IaC tiene tanto de proceso de gestión del cambio como de proceso técnico. Si el equipo no está alineado, el resultado frecuente es tener los dos mundos: el código IaC “oficial” y los cambios manuales que se siguen haciendo porque “era más rápido”.

Cuándo empieza a pagar

El momento que más se describe en retrospectivas de equipos que hicieron la transición es este: la primera vez que alguien del equipo con menos experiencia levanta un entorno nuevo completamente solo, sin preguntar a nadie, siguiendo solo el repositorio.

Ese momento —normalmente entre el mes uno y el mes tres— es cuando el ROI se vuelve tangible y los escépticos empiezan a callarse. HashiCorp lo documenta como el segundo estadio de adopción : pasar de “lo usa una persona” a “el equipo entero confía en ello como fuente de verdad”.

Los riesgos: automatizar también la cagada

IaC no es la panacea; es una forma distinta de equivocarse, pero dejando rastro.

Uno de los grandes miedos de la gente de seguridad es el fallo de configuración en cadena . Antes bastaba con que alguien abriera un puerto de más en un servidor: mal menor. Ahora, si tu componente “estándar” de seguridad tiene un fallo, lo vas a replicar en todas las cuentas, todas las regiones y todos los entornos con una elegancia que asusta.

CrowdStrike y otros llevan tiempo avisando: mover la infraestructura a código sin meter la seguridad en el mismo pipeline es receta para el desastre —aunque, viniendo de quien en julio de 2024 tumbó ocho millones y medio de máquinas Windows con una actualización defectuosa , es un poco como que el pirómano te explique cómo instalar extintores.

El caso es que si haces plan y apply sin pasar por escáneres de configuración, validación de políticas o revisiones mínimamente decentes, solo has conseguido equivocarte más rápido y en más sitios a la vez.

Otro clásico es la gestión de secretos como si fueran post-its. Contraseñas, claves de API, tokens de acceso… todo ello embutido en ficheros .tf o .ts y alegremente subido a repositorios. Los mismos artículos que te venden IaC te repiten como un mantra: secretos, siempre, en gestores dedicados (Vault, AWS Secrets Manager, SSM, etc.), nunca incrustados en el código de infraestructura.

Y luego está el monstruo de Frankenstein: el proyecto IaC inabarcable. Empiezas con un repositorio pequeño, añades bloques, metes condicionales para diez clientes, cinco clouds, tres continentes, y cuando quieres darte cuenta tienes un árbol de ficheros que parece el guion de una telenovela larga. Nadie sabe qué depende de qué, la gente tiene miedo de tocar nada, y has pasado de “infraestructura declarativa” a “puzzle declarativo del infierno”.

Las buenas prácticas insisten en lo aburrido pero eficaz: modularizar, separar por dominios (red, compute, datos…), no mezclar producción con entornos personales, y documentar patrones claros para que cada equipo no invente su propia religión de componentes.

Y hablando de dramas silenciosos: el fichero de estado de Terraform (terraform.tfstate) merece su propio párrafo de advertencia.

Ese fichero es el mapa entre tu código y los recursos reales que existen en el cloud. Sin él, Terraform no sabe qué ha creado, qué gestiona y qué debe dejar en paz.

El problema clásico ocurre cuando ese fichero vive en el portátil de alguien: si esa persona se va de la empresa, sufre un accidente de hardware o simplemente no conecta la VPN cuando hay una urgencia, tu capacidad de gestionar la infraestructura queda en el aire. El escenario más dramático —y más documentado en foros de Terraform— es el de las aplicaciones concurrentes : dos personas hacen apply al mismo tiempo sobre el mismo estado, el fichero se corrompe, y el resultado es una infraestructura parcialmente aplicada que ni Terraform ni la consola de AWS saben describir con coherencia.

La solución es usar un backend remoto con bloqueo de estado: S3 + DynamoDB en AWS, Terraform Cloud, GitLab-managed state, o cualquier otra opción que garantice que (a) el estado no vive en una máquina personal y (b) solo un ejecutor puede modificarlo a la vez. No es opcional cuando hay más de una persona en el equipo; es tan básico como no guardarse las credenciales en un post-it.

Tengo infra existente: ¿qué hago?

Si llegas a este artículo con infraestructura ya en marcha —servidores, redes, bases de datos, roles IAM— la pregunta inevitable es: “¿cómo encaja esto?”. La respuesta corta es: con paciencia y a pasitos.

El escenario de partir de cero (greenfield) es el más sencillo: empiezas escribiendo todo en IaC desde el primer día, no hay legado que gestionar y el coste de migración es cero. Es la situación ideal y la que describe casi todos los tutoriales de Internet, lo cual es ligeramente irritante cuando tienes tres años de infraestructura ya desplegada.

El escenario real para la mayoría es el brownfield: infraestructura existente, en producción, que no puedes tirar y volver a montar sin una conversación muy incómoda con tu equipo.

La estrategia que funciona tiene dos patas:

Que conste: Terraform import ha mejorado mucho desde Terraform 1.5, que introduce bloques import declarativos en el propio HCL en lugar de tener que lanzar el comando desde la CLI. OpenTofu ha adoptado la misma funcionalidad. Aun así, hay tipos de recursos complejos (IAM policies con muchas condiciones, configuraciones de RDS con decenas de parámetros, stacks de CloudFormation importados) donde la reconciliación manual sigue siendo laboriosa. Forma parte del precio de haber vivido en la consola durante años.

Un flujo razonable para no morir el primer mes

Cada empresa acaba encontrando su propia coreografía, pero hay un patrón que se suele repetir.

Lo primero es elegir herramienta sin dejarse arrastrar por modas: si ya tienes mucha inversión en Terraform y te preocupa la licencia, miras OpenTofu; si tu mundo es AWS y no tienes intención de salir de ahí, CDK te permite ir muy rápido; si tus devs son fans de TypeScript o Python y quieren IaC en ese idioma, consideras Pulumi.

En lugar de pasarlo todo a IaC como quien se apunta al gimnasio en enero, se empieza por una parte concreta: por ejemplo, la VPC base, o la parte de compute principal de un servicio. Se describe eso en IaC, se prueba en un entorno de laboratorio, se itera, se integra en CI/CD y, cuando funciona, se extiende al resto.

El flujo típico con Terraform/OpenTofu tiene algo de liturgia (de la buena):

Escribes o modificas código en una rama. Lanzas un plan que muestra qué va a cambiar (recursos a crear, modificar, destruir). Añades ese plan como comentario en un pull request, para que quienes revisen vean no solo el HCL, sino las consecuencias. Al aprobar y fusionar, un pipeline ejecuta el apply contra el entorno adecuado, con los permisos mínimos necesarios.

En paralelo, vas añadiendo guardarraíles: linters de IaC (para no repetir anti-patrones), escáneres de seguridad (para detectar S3 públicos, grupos 0.0.0.0/0, etc.), validación de normas internas (“toda instancia debe llevar estos tags”, “toda base de datos debe estar en subred privada”, etc.).

Y se establece el pacto de sangre: no tocar producción a mano salvo emergencia, y si se toca, se refleja luego en el código. Porque si no, tu IaC deja de ser la fuente de verdad y se convierte en fan fiction.

Mini-ejemplo: una EC2 con Terraform sin invocar a Satán

El movimiento se demuestra andando, así que vamos con un “hola mundo” de IaC tradicional: levantar una instancia EC2 en AWS con Terraform.

No es la infra de tu banco, pero sí lo justo para ver la mecánica.

Suponiendo que ya tienes Terraform instalado y tus credenciales de AWS configuradas (en ~/.aws/credentials o variables de entorno), puedes crear un archivo main.tf como este:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }

  required_version = ">= 1.6.0"
}

provider "aws" {
  region = "eu-west-1"
}

resource "aws_instance" "demo" {
  ami           = "ami-0c55b159cbfafe1f0" # Ejemplo: Amazon Linux 2 en eu-west-1
                                          # Busca la AMI actualizada en: https://console.aws.amazon.com/ec2/v2/home#AMICatalog
  instance_type = "t3.micro"

  tags = {
    Name = "demo-iac-article"
  }
}

En la línea de comandos, en esa carpeta:

terraform init

para que se descargue el proveedor de AWS y deje todo listo. Luego:

terraform plan

para ver qué tiene intención de hacer. Verás algo como “se va a crear aws_instance.demo con estas propiedades”. Si te parece bien:

terraform apply

aceptas cuando te lo pregunte, y Terraform crea la instancia en AWS.

Si mañana cambias el instance_type a t3.small y repites plan + apply, Terraform calculará que tiene que actualizar ese recurso, no recrearlo entero (salvo que ese cambio requiera reemplazo; lo indicará).

Si lo borras del código y haces apply, Terraform propondrá destruir la instancia.

El código manda, la consola obedece.

En un entorno profesional, harías varias cosas más:

Separarías variables (ami, instance_type, tags) en un variables.tf. Usarías un backend remoto (S3 + DynamoDB, Terraform Cloud o similar) para el estado, en vez de dejar terraform.tfstate en tu portátil. Ejecutarías plan y apply desde CI, no desde tu máquina personal. Y, posiblemente, migrarías a OpenTofu si quieres evitar líos de licencia a futuro y beneficiarte del ecosistema abierto.

Pero como ejemplo mínimo, ya ves la idea: tu servidor no “vive” en la consola de AWS, vive en un fichero de texto con historial, comentarios y capacidad de revertir si algo sale mal.

La moraleja es sencilla: tu infraestructura ya es software, te guste o no.

Tiene versiones, bugs, efectos secundarios y maneras creativas de fallar.

La infraestructura como código no garantiza que no la líes, pero al menos te permite que tus errores queden escritos, se puedan revisar y, con un poco de suerte, se puedan deshacer con un commit, no con una novena a San ChatGPT.

Glosario rápido

Porque apply sin entender primero el vocabulario es exactamente la clase de imprudencia de la que habla este artículo.

Fuentes y referencias

Todo lo que aparece aquí existe en un repositorio. A diferencia de la infra de tu primer trabajo.

Sígueme

Escribo y opino sobre tecnología, desarrollo de software y lo que se me pase por la cabeza.