Eficiència i resiliència: com la IaC revoluciona el desplegament d'infraestructura

Fa cinc anys, desplegar infraestructura cloud requeria setmanes de feina manual: configurar servidors un per un, crear xarxes, definir permisos, instal·lar dependències. Avui, amb Infraestructura com a Codi (IaC), aquest mateix procés es redueix a minuts —amb més fiabilitat i zero errors humans.

La pregunta ja no és si adoptar la IaC, sinó quants diners i quant de temps estàs perdent per no fer-ho. En aquest article explorem com la IaC s'ha convertit en pràctica estàndard per als equips que necessiten escalar sense sacrificar l'estabilitat.

Què és la Infraestructura com a Codi?

La IaC és la pràctica de definir tota la teva infraestructura —servidors, xarxes, bases de dades, permisos, serveis— en fitxers de text versionables (YAML, JSON, HCL). En lloc de configurar manualment des de consoles web o SSH, descrius el que necessites en codi, i eines com Terraform, AWS CloudFormation o Ansible ho despleguen automàticament.

És la diferència entre construir una casa col·locant cada maó a mà versus imprimir la casa sencera des d'un plànol digital precís.

Els beneficis que transformen les operacions

1. Velocitat: de dies a minuts

Configurar manualment un entorn de producció a AWS (VPC, subnets, load balancers, auto-scaling groups, RDS, permisos IAM) pot trigar 3-5 dies si tens experiència. Amb IaC, executes una comanda i en 20 minuts ho tens tot funcionant.

Cas real: un equip de 12 desenvolupadors a Madrid necessitava replicar el seu entorn de staging per a testing. Manualment: 2 dies. Amb Terraform ja configurat: 18 minuts.

2. Versionat i auditoria: Git per a la infraestructura

Si la teva infraestructura és en fitxers Git, pots:

• Veure qui va canviar què, quan i per què (commits amb missatges)
• Tornar enrere si alguna cosa falla (rollback instantani)
• Revisar els canvis abans d'aplicar-los (pull requests)
• Complir auditories de seguretat sense documentació manual

Això és especialment crític en sectors regulats (fintech, healthtech) on cada canvi ha de ser traçable.

3. Eliminació d'errors humans

La configuració manual és propensa a errors: oblidar obrir un port, equivocar-se en els permisos, fer servir configuracions inconsistents entre entorns. Amb IaC, defineixes una vegada i repliques infinites vegades sense desviacions.

"Abans perdíem mig dia depurant diferències subtils entre staging i producció. Ara staging ÉS producció, només que amb menys recursos. El codi és idèntic."

4. Escalabilitat sense fricció

Necessites crear 5 entorns idèntics per a diferents clients? Vols provar una arquitectura alternativa sense arriscar producció? Amb IaC, clones, modifiques paràmetres i despleguis. Sense tocar consoles web. Sense tiquets de suport.

5. Recuperació davant de desastres accelerada

Si la teva regió d'AWS falla o necessites migrar a un altre cloud (multi-cloud), amb IaC reconstrueixes tota la teva infraestructura en una altra regió/proveïdor executant el mateix codi. L'RTO (Recovery Time Objective) baixa de dies a hores.

Cas pràctic: desplegant un backend a AWS amb IaC

Vegem un exemple real que hem implementat desenes de vegades:

Requeriment: desplegar un backend NestJS a AWS amb:

• Auto-scaling basat en CPU
• Base de dades PostgreSQL gestionada (RDS)
• Load balancer amb certificat SSL
• Autenticació amb Cognito
• Logs centralitzats a CloudWatch
• Backups automàtics

Enfocament manual (antic)

1. Dia 1: crear VPC, subnets públiques/privades, internet gateway, route tables
2. Dia 2: configurar security groups, instàncies EC2, instal·lar dependències
3. Dia 3: setup d'RDS, configurar backups, connectar amb el backend
4. Dia 4: configurar ALB, certificat SSL, health checks
5. Dia 5: configurar auto-scaling, Cognito, proves

Total: 5 dies + risc de configuració inconsistent

Enfocament IaC amb Terraform (modern)

terraform init
terraform plan    # Revisar canvis
terraform apply   # Desplegar-ho tot

Total: 20 minuts + infraestructura idèntica cada vegada

Bones pràctiques per implementar IaC

De les nostres 12 transformacions DevSecOps, aquestes són les lliçons clau:

1. Comença modular des de l'inici

No escriguis un fitxer de 2000 línies. Crea mòduls reutilitzables (networking, compute, databases). Et permet composició flexible i testing independent.

2. El state management és crític

Si fas servir Terraform, el fitxer d'estat (.tfstate) és la teva font de veritat. Guarda'l en un backend remot (S3 + DynamoDB lock) per al treball en equip. Perdre l'estat = desastre.

3. Integra amb CI/CD des del dia 1

El teu pipeline hauria de:

• Executar terraform plan a cada pull request
• Requerir aprovació manual abans de l'apply
• Validar polítiques de seguretat (Checkov, tfsec)
• Notificar canvis a Slack/Teams

4. Variables i secrets separats

No facis mai hardcode de credencials al codi. Fes servir AWS Secrets Manager, HashiCorp Vault o variables d'entorn injectades des de CI/CD. Tot el que és a Git ha de ser públic-safe.

5. Documenta el "per què", no el "què"

El codi ja mostra què estàs desplegant. Els comentaris han d'explicar per què vas prendre decisions arquitectòniques (p. ex.: "subnet pública perquè l'ALB necessita IPs públiques").

Eines: Terraform, CloudFormation o Ansible?

No hi ha una resposta única, però aquestes són les nostres recomanacions segons el context:

• Terraform: multi-cloud, comunitat enorme, HCL més llegible que JSON. Default per a la majoria de casos.
• AWS CloudFormation: si estàs 100% a AWS i valores la integració nativa (StackSets, drift detection).
• Pulumi: si el teu equip prefereix TypeScript/Python en lloc de DSL. Més flexible però menys madur.
• Ansible: millor per a la configuració de programari post-desplegament, no tant per aprovisionar infraestructura cloud.

El cost real de no adoptar la IaC

Més enllà de la velocitat, el cost de no tenir IaC és brutal:

• Bus factor = 1: només una persona sap com funciona la infra. Si marxa, estàs bloquejat.
• Drift incontrolable: producció divergeix de staging sense que ningú sàpiga quan ni per què.
• Desastres sense recovery plan: no pots reconstruir la infra ràpidament perquè no està codificada.
• Onboarding lent: els nous devs triguen setmanes a entendre l'arquitectura perquè no hi ha documentació viva (el codi ho és).
• Compliance impossible: les auditories de seguretat requereixen captures i documentació manual desactualitzada.

Propers passos: de manual a automatitzat

Si encara gestiones la infraestructura manualment, el camí cap a la IaC no ha de ser disruptiu:

1. Auditoria de l'estat actual (1-2 setmanes): documenta la teva infraestructura existent
2. Codificar primer els entorns no-prod (2-3 setmanes): comença amb dev/staging, no amb producció
3. Implementar CI/CD per a la infra (1 setmana): pipeline que valida i desplega canvis
4. Migració progressiva de prod (2-4 setmanes): importa recursos existents a IaC sense downtime
5. Optimització contínua (ongoing): refactoritzar mòduls, millorar polítiques

Total: 6-10 setmanes de transformació per a un deute tècnic que t'estava costant mesos de feina manual a l'any.

El teu equip està preparat per a la IaC?

Si et trobes en alguna d'aquestes situacions, la IaC hauria de ser prioritat ara:

• Crear nous entorns et costa més d'1 dia
• Has tingut incidents per configuració manual incorrecta
• No pots explicar exactament com està configurada la teva infra de producció
• L'onboarding de nous devs/devops triga >2 setmanes només a comprendre l'arquitectura
• Necessites complir SOC2, ISO27001 o similar

A onext hem implementat transformacions DevSecOps completes —incloent-hi IaC, CI/CD, observabilitat i seguretat— en 6-10 setmanes. Sense paralitzar els teus lliuraments actuals.