DevOps desde Cero: Que Significa Realmente y Por Que Deberia Importarte

Introduccion

Este es el primer articulo de una serie de veinte partes llamada “DevOps desde Cero.” El objetivo es llevarte desde no saber nada sobre DevOps hasta sentirte comodo con las herramientas y practicas que los equipos modernos usan todos los dias. Vamos a usar TypeScript, AWS, Kubernetes y GitHub Actions a lo largo de la serie, construyendo cosas reales en el camino.

Pero antes de tocar cualquier herramienta, necesitamos entender que es realmente DevOps. Esta palabra se usa mucho. Las ofertas de trabajo piden “DevOps Engineers,” las empresas compran “herramientas DevOps,” y de alguna manera todos tienen una definicion diferente. En este articulo vamos a ir al grano y hablar de lo que DevOps realmente significa, de donde viene, como medirlo, y que definitivamente no es.

Vamos a meternos de lleno.

Que es DevOps?

DevOps no es una herramienta. No es un titulo de puesto. No es un equipo que creas para que los desarrolladores dejen de preocuparse por produccion. DevOps es una combinacion de practicas culturales, procesos y herramientas que aumenta la capacidad de una organizacion para entregar software mas rapido y de forma mas confiable.

La forma mas simple de pensarlo: DevOps se trata de eliminar las paredes entre las personas que escriben codigo y las personas que lo corren en produccion.

Hay tres pilares en DevOps:

• Cultura: Los equipos comparten la responsabilidad del ciclo de vida completo de su software, desde escribirlo hasta correrlo
• Practicas: Integracion continua, entrega continua, infraestructura como codigo, monitoreo y ciclos de feedback rapidos
• Herramientas: La automatizacion que hace posibles esas practicas a escala

Si solo adoptas las herramientas sin cambiar como trabajan tus equipos, no estas haciendo DevOps. Solo estas automatizando el mismo proceso roto. Este es un punto critico que muchas organizaciones no entienden.

Una breve historia: el muro de confusion

Para entender por que existe DevOps, necesitas saber que habia antes. Durante decadas, las organizaciones de software tenian dos grupos separados:

• Desarrollo (Dev): Escribe el codigo, entrega features, se mueve rapido, quiere deployar seguido
• Operaciones (Ops): Corre los servidores, mantiene las cosas estables, se mueve con cuidado, quiere no deployar nunca

Estos dos grupos tenian incentivos completamente diferentes. Dev queria cambios porque cambios significaban features nuevos. Ops queria estabilidad porque cambios significaban riesgo. La transferencia entre ellos se llamaba “el muro de confusion.” Dev tiraba el codigo por encima del muro, Ops intentaba averiguar como correrlo, y cuando las cosas se rompian, todos se culpaban mutuamente.

Esto creaba un ciclo doloroso:

• Los deploys eran raros (mensuales o trimestrales) porque eran riesgosos y estresantes
• Cada deploy era enorme porque todos los cambios se acumulaban
• Deploys enormes significaban mas cosas que podian salir mal
• Cuando algo salia mal, tardaba una eternidad encontrar cual cambio causo el problema
• Entonces los deploys se volvian aun mas raros, y el ciclo continuaba

En 2008 y 2009, algunas personas empezaron a hablar de romper este ciclo. Patrick Debois organizo la primera conferencia “DevOpsDays” en Ghent, Belgica en 2009. La idea era simple: que pasaria si Dev y Ops trabajaran juntos en lugar de enfrentados? Que pasaria si deployearamos cambios chicos frecuentemente en lugar de cambios grandes raramente? Que pasaria si automatizaramos todo lo que se pudiera automatizar?

Estas ideas no eran completamente nuevas. Google venia practicando algo similar internamente durante anios (despues lo publicaron como Site Reliability Engineering). Pero el movimiento DevOps le dio un nombre y lo hizo accesible para todos, no solo para empresas con los recursos de Google.

Las metricas DORA: midiendo el rendimiento DevOps

Una de las contribuciones mas importantes al movimiento DevOps vino del equipo DORA (DevOps Research and Assessment), liderado por la Dra. Nicole Forsgren, Jez Humble y Gene Kim. Pasaron anios investigando que separa a los equipos de alto rendimiento de los de bajo rendimiento. Sus hallazgos se publicaron en el libro “Accelerate” y en reportes anuales del State of DevOps.

Identificaron cuatro metricas clave que predicen el rendimiento en entrega de software:

• Frecuencia de Deploy: Que tan seguido tu equipo deploya a produccion. Los equipos elite deployean on demand, multiples veces por dia. Los de bajo rendimiento deployean mensualmente o menos.
• Lead Time para Cambios: Cuanto tiempo pasa desde un commit de codigo hasta que ese codigo esta corriendo en produccion. Los equipos elite miden esto en menos de una hora. Los de bajo rendimiento tardan entre uno y seis meses.
• Tasa de Fallo de Cambios: Que porcentaje de deploys causan una falla en produccion que requiere un fix (rollback, parche, etc.). Los equipos elite tienen una tasa del 0-15%. Los de bajo rendimiento llegan al 46-60%.
• Tiempo Medio de Recuperacion (MTTR): Cuando algo se rompe en produccion, cuanto tiempo toma restaurar el servicio? Los equipos elite se recuperan en menos de una hora. Los de bajo rendimiento tardan entre una semana y un mes.

Aca esta el insight clave de su investigacion: estas cuatro metricas estan correlacionadas. Los equipos que deployean mas frecuentemente tambien tienen tasas de fallo mas bajas y tiempos de recuperacion mas rapidos. Velocidad y estabilidad no son enemigos. Se refuerzan mutuamente.

Pensamiento tradicional:
  "Si deployeamos mas seguido, mas cosas se van a romper"

Lo que la investigacion de DORA realmente muestra:
  "Los equipos que deployean mas seguido rompen menos cosas Y se recuperan mas rapido"

Por que? Porque:
  - Cambios mas chicos son mas faciles de entender y debuggear
  - Deploys frecuentes significan ciclos de feedback mas rapidos
  - Ciclos de feedback rapidos significan que los problemas se detectan antes
  - Problemas detectados antes son mas baratos y simples de arreglar

Esto puede parecer contraintuitivo al principio. Pero pensalo de esta manera: preferis debuggear un deploy que contiene 3 commits o uno que contiene 300? La respuesta es obvia. Deployear frecuentemente te fuerza a mantener los cambios chicos, y los cambios chicos son inherentemente menos riesgosos.

DevOps vs SRE vs Platform Engineering

Vas a escuchar estos tres terminos usados de forma intercambiable, pero son disciplinas distintas (y complementarias). Entender como se relacionan te va a ahorrar mucha confusion.

DevOps es el movimiento cultural. Es la filosofia que dice que Dev y Ops deberian trabajar juntos, compartir responsabilidad, y usar automatizacion para entregar software mas rapido y de forma mas confiable. DevOps se trata de principios: sos duenio de lo que construis, automatizas todo lo que puedas, y medis resultados.

Site Reliability Engineering (SRE) es una forma de implementar los principios DevOps. Google lo creo a principios de los 2000 antes de que existiera el termino “DevOps.” SRE trata las operaciones como un problema de ingenieria de software. Los equipos SRE escriben codigo para automatizar el trabajo operativo, definen Service Level Objectives (SLOs) para medir la confiabilidad, y usan error budgets para balancear confiabilidad con velocidad de features.

Ben Treynor Sloss, el fundador del equipo SRE de Google, lo describio asi:

"SRE es lo que pasa cuando le pedis a un ingeniero de software que disenie una funcion de operaciones."

Si DevOps es el “que” (principios y cultura), SRE es una respuesta al “como” (practicas y frameworks especificos).

Platform Engineering es el mas nuevo de los tres. Surgio cuando las organizaciones se dieron cuenta de que pedirle a cada equipo de desarrollo que sea duenio completo de su infraestructura no escalaba. Los equipos de Platform Engineering construyen plataformas internas para desarrolladores (IDPs) que abstraen la complejidad de la infraestructura. En lugar de que cada equipo aprenda Kubernetes, Terraform y pipelines de CI/CD desde cero, el equipo de plataforma provee golden paths, templates y herramientas de autoservicio.

Pensalo asi:

DevOps dice:          "Lo construis, lo corres"
SRE dice:             "Aca estan las practicas y metricas para correrlo bien"
Platform Eng dice:    "Aca hay una plataforma que hace facil correrlo"

Estos tres enfoques no compiten entre si. En una organizacion madura, trabajan juntos. DevOps provee la cultura, SRE provee el framework de confiabilidad, y Platform Engineering provee la capa de experiencia de desarrollador encima de todo.

El toolchain de DevOps

Si bien DevOps no se trata solo de herramientas, las herramientas importan. Son lo que hace posibles las practicas a escala. Aca esta el toolchain tipico de DevOps, organizado por etapa:

Planificacion y seguimiento

• Issue trackers (GitHub Issues, Jira, Linear)
• Tableros de proyecto, wikis de documentacion

Control de versiones

• Git (GitHub, GitLab, Bitbucket)
• Estrategias de branching, pull requests, code review

Integracion Continua (CI)

• Compilar, testear y validar automaticamente cada cambio de codigo
• Herramientas: GitHub Actions, GitLab CI, Jenkins, CircleCI

Entrega/Deploy Continuo (CD)

• Deployear automaticamente los cambios validados a produccion
• Herramientas: ArgoCD, Flux, Spinnaker, GitHub Actions

Containers y orquestacion

• Empaquetar aplicaciones de forma consistente entre ambientes
• Herramientas: Docker, Kubernetes, ECS

Infraestructura como Codigo (IaC)

• Definir y gestionar infraestructura a traves de codigo, no clickeando en consolas
• Herramientas: Terraform, Pulumi, AWS CDK, CloudFormation

Monitoreo y observabilidad

• Saber que esta pasando en produccion antes de que tus usuarios te avisen
• Herramientas: Prometheus, Grafana, Datadog, OpenTelemetry

Seguridad

• Mover la seguridad a la izquierda, automatizar escaneos, gestionar secretos
• Herramientas: Trivy, Snyk, HashiCorp Vault, funcionalidades de seguridad de GitHub

En esta serie nos vamos a enfocar en un subconjunto especifico de estas herramientas: TypeScript para codigo de aplicacion, GitHub Actions para CI/CD, Docker para containers, Kubernetes para orquestacion, y AWS para infraestructura cloud. Este stack es ampliamente usado, esta bien documentado, y te da habilidades que se transfieren a casi cualquier organizacion.

Que va a cubrir esta serie

Aca esta el plan para los veinte articulos de esta serie:

• Articulo 1 (este): Que significa realmente DevOps
• Articulos 2-3: Control de versiones con Git y workflows de GitHub
• Articulos 4-5: Containers con Docker, desde lo basico hasta multi-stage builds
• Articulos 6-8: CI/CD con GitHub Actions, desde pipelines simples hasta workflows avanzados
• Articulos 9-11: Fundamentos de cloud con AWS (networking, compute, storage)
• Articulos 12-14: Kubernetes desde cero, deployeando y gestionando aplicaciones reales
• Articulos 15-16: Infraestructura como Codigo con Terraform
• Articulos 17-18: Monitoreo, logging y observabilidad
• Articulo 19: Practicas de seguridad y gestion de secretos
• Articulo 20: Juntando todo, un pipeline DevOps completo desde commit hasta produccion

Cada articulo construye sobre los anteriores. Al final de la serie, vas a haber construido un pipeline completo que lleva una aplicacion TypeScript desde un commit de git hasta un cluster de Kubernetes en produccion en AWS, con testing automatizado, escaneo de seguridad, monitoreo y alertas.

Para quien es esto?

• Desarrolladores que quieren entender que pasa con su codigo despues de pushearlo
• Ingenieros juniors o estudiantes que quieren aprender practicas DevOps modernas desde cero
• Gente de Ops que quiere adoptar un enfoque mas orientado a ingenieria
• Cualquiera que sigue escuchando “DevOps” en reuniones y quiere realmente entender que significa

No necesitas experiencia previa con ninguna de las herramientas que vamos a usar. Voy a explicar todo desde la base. Conocimiento basico de programacion y comodidad con la linea de comandos ayudan pero no son estrictamente necesarios.

Lo que DevOps NO es: anti-patrones comunes

Cerremos con algo igualmente importante: lo que DevOps no es. Estos son anti-patrones reales en los que las organizaciones caen constantemente.

Anti-patron 1: Renombrar tu equipo de Ops a “DevOps”

Si tomas tu equipo de operaciones existente, les cambias el titulo a “DevOps Engineer,” y nada mas cambia, no adoptaste DevOps. Renombraste un equipo. DevOps requiere cambio cultural, no solo cambio de titulo.

Anti-patron 2: Comprar herramientas y decir que haces DevOps

Comprar una plataforma de CI/CD, un orquestador de containers y una herramienta de monitoreo no te convierte en una organizacion DevOps. Herramientas sin las practicas y cultura correctas son simplemente shelfware caro. He visto organizaciones gastar millones en herramientas mientras sus equipos siguen deployeando manualmente cada dos semanas.

Anti-patron 3: Crear un silo de DevOps

La ironia de este es dolorosa. DevOps se creo para romper silos entre Dev y Ops. Algunas organizaciones respondieron creando un tercer silo llamado “el equipo de DevOps” que se sienta entre Dev y Ops. Ahora tenes tres muros de confusion en lugar de uno.

Anti-patron 4: Todas las herramientas, nada de cultura

Esto vale la pena repetirlo porque es el error mas comun. Si tus desarrolladores escriben codigo y despues se lo tiran a alguien mas para que lo deploye, no estas haciendo DevOps sin importar que herramientas uses. DevOps significa propiedad compartida. El equipo que construye el software es responsable de correrlo.

Anti-patron 5: DevOps significa “los desarrolladores hacen todo”

DevOps no significa echar a tu equipo de ops y hacer que los desarrolladores gestionen servidores. Significa que desarrollo y operaciones trabajan juntos, comparten conocimiento, y ambos contribuyen a la automatizacion. Los desarrolladores ganan conciencia operativa, y los ingenieros de ops ganan habilidades de desarrollo. El objetivo es colaboracion, no consolidacion.

Notas finales

DevOps es, en su esencia, una idea simple: las personas que construyen software y las personas que lo corren deberian trabajar juntos, compartir responsabilidad, y usar automatizacion para moverse mas rapido sin sacrificar estabilidad. Las metricas DORA prueban que este enfoque funciona. Velocidad y confiabilidad no son opuestos. Van de la mano.

En el proximo articulo, vamos a empezar con lo practico. Vamos a configurar un entorno de desarrollo, crear un proyecto TypeScript, inicializar un repositorio Git, y aprender los fundamentos de control de versiones sobre los que todo lo demas en esta serie se va a construir.

Espero que te haya resultado util y lo hayas disfrutado! Hasta la proxima!

Errata

Si encontras algun error o tenes alguna sugerencia, por favor mandame un mensaje para que se corrija.

Tambien podes revisar el codigo fuente y los cambios en las fuentes aca