Glosario de DevOps: 80 términos esenciales explicados sin tecnicismos

DevOps es probablemente el área del desarrollo de software con peor relación entre cantidad de jerga y claridad conceptual. Cada nuevo año trae nuevas siglas, nuevas herramientas con nombres opacos, nuevos términos que asumen conocimiento previo que solo está disponible si llevas años en el sector. Para un developer que se encuentra con una conversación sobre Helm charts, sidecars, mTLS y eventual consistency en una reunión técnica, el coste cognitivo de seguir el hilo puede ser considerable.

Este glosario está pensado para ser referencia práctica. No para sustituir documentación técnica profunda, sino para que cuando aparezca un término en una conversación, en un PR, o en una arquitectura propuesta, puedas situarte rápidamente y participar con criterio. Las definiciones son deliberadamente cortas y centradas en lo que el término significa en la práctica cotidiana, no en su precisión académica.

Los términos están organizados por área temática para facilitar la navegación, pero también pueden leerse en orden si es la primera incursión seria en el vocabulario DevOps.

Conceptos fundamentales#

1. DevOps

Cultura y conjunto de prácticas que buscan integrar el desarrollo de software (Dev) con las operaciones de infraestructura (Ops). En la práctica, significa que los developers se involucran activamente en cómo se despliega y opera su código, y los operadores se involucran activamente en cómo se diseña y construye.

2. SRE (Site Reliability Engineering)

Disciplina creada por Google que aplica principios de ingeniería de software a operaciones de infraestructura. Su filosofía central: tratar problemas de operación como problemas de software, automatizar todo lo automatizable, y definir explícitamente cuánta indisponibilidad es aceptable.

3. Infrastructure as Code (IaC)

Práctica de describir infraestructura (servidores, redes, configuración) mediante código declarativo en lugar de configurar manualmente. El código se versiona en Git como cualquier otro código, lo que permite revisar cambios, hacer rollback, y replicar entornos de forma consistente.

4. Pipeline

Secuencia automatizada de pasos que el código atraviesa desde commit hasta producción. Típicamente incluye build, tests, security scans, deployment a staging, tests de integración, y deployment a producción.

5. Continuous Integration (CI)

Práctica de integrar cambios de código en una rama principal frecuentemente (varias veces al día) y verificarlos automáticamente con tests. El objetivo es detectar problemas de integración temprano, cuando son baratos de arreglar.

6. Continuous Deployment (CD)

Práctica de desplegar automáticamente cada cambio que pasa los tests a producción, sin intervención manual. Diferente de Continuous Delivery, que también es automatizado pero requiere aprobación humana para el deployment final.

7. Continuous Delivery (CD ambiguo)

Práctica similar a Continuous Deployment pero donde el último paso (despliegue a producción) requiere aprobación manual. El código está siempre listo para ser desplegado, pero el momento exacto lo decide un humano.

8. GitOps

Filosofía donde el estado deseado de la infraestructura y aplicaciones se describe en repositorios Git, y un agente automatizado (típicamente ArgoCD o Flux) se encarga de hacer que la realidad coincida con lo descrito en Git. Si quieres cambiar producción, haces un PR.

9. Shift Left

Filosofía de mover actividades tradicionalmente realizadas tarde en el ciclo de desarrollo (testing, security, performance) hacia fases más tempranas. La idea: detectar problemas cuando son baratos de arreglar.

10. DORA Metrics

Cuatro métricas definidas por el equipo de investigación DevOps Research and Assessment para medir performance de equipos de desarrollo: deployment frequency, lead time for changes, change failure rate, time to restore service.

Contenedores y orquestación#

11. Container

Unidad de software que empaqueta código, runtime, librerías del sistema y configuración necesarios para ejecutar la aplicación. Conceptualmente similar a una máquina virtual pero radicalmente más ligero porque comparte el kernel del sistema operativo del host.

12. Docker

Plataforma original que popularizó los contenedores. En la práctica, “Docker” suele usarse como sinónimo de “contenedor” aunque técnicamente hay otras tecnologías de contenedores (Podman, containerd).

13. Image

Plantilla inmutable que describe el contenido de un contenedor antes de ejecutarse. Las imágenes se construyen una vez y se ejecutan muchas veces como contenedores diferentes.

14. Dockerfile

Archivo de texto con instrucciones que describen cómo construir una imagen Docker. Cada instrucción crea una capa nueva en la imagen, lo que permite caché eficiente durante builds.

15. Registry

Servicio donde se almacenan imágenes Docker. Docker Hub es el registry público más conocido. Empresas suelen tener registries privados (GitHub Container Registry, AWS ECR, Google Container Registry).

16. Kubernetes (K8s)

Orquestador de contenedores que gestiona despliegue, escalado, actualizaciones y healing de aplicaciones containerizadas a través de múltiples máquinas. Originalmente creado por Google, ahora estándar de facto para infraestructura cloud-native.

17. Pod

Unidad básica de ejecución en Kubernetes. Un pod contiene uno o más contenedores que comparten red y storage. La mayoría de pods contienen un único contenedor principal.

18. Node

Máquina (física o virtual) donde corren los pods de Kubernetes. Un cluster de Kubernetes consiste en múltiples nodes.

19. Cluster

Conjunto de nodes coordinados que ejecutan workloads de Kubernetes. Un cluster tiene un control plane (que toma decisiones) y nodes worker (que ejecutan trabajo).

20. Deployment

Recurso de Kubernetes que describe el estado deseado para un conjunto de pods: cuántas réplicas, qué imagen, qué configuración. Kubernetes se encarga de mantener la realidad acorde con el deployment.

21. Service

Abstracción que expone pods al exterior mediante una dirección IP estable y balanceo de carga. Los pods cambian (mueren, se crean), pero el service ofrece un endpoint estable.

22. Ingress

Recurso que gestiona acceso HTTP/HTTPS desde fuera del cluster a services dentro. Típicamente implementa SSL termination, routing por host y path, y balanceo.

23. ConfigMap

Recurso para almacenar configuración no sensible (URLs, valores de feature flags) separada del código del contenedor. Permite cambiar configuración sin rebuild de imagen.

24. Secret

Como ConfigMap pero para información sensible (passwords, API keys, certificates). En Kubernetes nativo, los secrets están encodados base64 pero no encriptados — para encriptación real se usan herramientas como Sealed Secrets o integración con vaults externos.

25. Helm

Gestor de paquetes para Kubernetes. Permite empaquetar aplicaciones Kubernetes complejas (Deployments, Services, ConfigMaps, etc.) en “charts” reutilizables que se instalan con un comando.

26. Sidecar

Contenedor secundario dentro de un pod que añade funcionalidad al contenedor principal. Patrones comunes: sidecar de logging, sidecar de service mesh (Envoy), sidecar de monitoring.

27. DaemonSet

Recurso de Kubernetes que asegura que un pod específico corre en cada node del cluster. Útil para agents de logging, monitoring o seguridad.

28. StatefulSet

Como Deployment pero para aplicaciones con estado (bases de datos, sistemas de almacenamiento). Garantiza nombres y orden de creación predecibles.

29. Operator

Software que extiende Kubernetes para gestionar aplicaciones complejas con conocimiento del dominio. Ejemplo: el operator de PostgreSQL sabe cómo hacer backups, failover, upgrades de la base de datos.

30. Service Mesh

Capa de infraestructura que gestiona comunicación entre microservicios: encryption, routing, observability, retry policies. Istio y Linkerd son los más conocidos.

Cloud y plataformas#

31. IaaS (Infrastructure as a Service)

Cloud computing donde alquilas infraestructura cruda: máquinas virtuales, almacenamiento, red. Tú gestionas todo lo de arriba (OS, runtime, aplicación). AWS EC2, Azure VMs, Google Compute Engine son ejemplos.

32. PaaS (Platform as a Service)

Cloud computing donde el provider gestiona OS, runtime e infraestructura. Tú solo despliegas tu código. Heroku, Vercel, Cloudflare Pages son ejemplos.

33. SaaS (Software as a Service)

Software entregado como servicio sobre internet, sin instalación local. GitHub, Slack, Notion son SaaS.

34. Serverless

Modelo donde despliegas código que se ejecuta on-demand sin gestionar servidores. El nombre es engañoso — hay servidores, pero no son tu responsabilidad. AWS Lambda, Cloudflare Workers, Vercel Functions son serverless.

35. FaaS (Function as a Service)

Subset de serverless donde despliegas funciones individuales que se ejecutan en respuesta a eventos. Lambda es FaaS.

36. Edge Computing

Ejecutar código geográficamente cerca de los usuarios finales en lugar de en datacenters centralizados. Reduce latencia. Cloudflare Workers y Vercel Edge Functions son edge computing.

37. Multi-cloud

Estrategia de usar múltiples cloud providers simultáneamente. Reduce dependencia de un único provider pero añade complejidad operativa significativa.

38. Hybrid cloud

Combinación de infraestructura on-premise (en tus propios datacenters) con cloud público. Común en empresas grandes con sistemas legacy.

39. CDN (Content Delivery Network)

Red de servidores distribuidos geográficamente que sirven contenido estático desde el servidor más cercano al usuario. Cloudflare, Akamai, Fastly son CDNs.

40. VPC (Virtual Private Cloud)

Sección aislada de cloud público donde despliegas recursos que pueden comunicarse entre sí pero están aislados del resto de la nube pública.

Observabilidad#

41. Observability

Capacidad de entender el estado interno de un sistema basándose en su comportamiento externo. Sus tres pilares clásicos son métricas, logs y traces.

42. Metrics

Mediciones numéricas agregadas a lo largo del tiempo: requests por segundo, latencia P99, uso de memoria. Eficientes para almacenar y consultar pero pierden granularidad de eventos individuales.

43. Logs

Registros de eventos individuales que ocurren en el sistema, con timestamp y contexto. Almacenan detalle pero son caros de procesar y consultar a escala.

44. Traces

Registro del path de una request individual a través de múltiples servicios. Crítico para debugging en arquitecturas de microservicios.

45. Distributed Tracing

Capacidad de trackear una request a través de múltiples servicios distribuidos. OpenTelemetry es el estándar emergente.

46. SLI (Service Level Indicator)

Métrica específica que mide aspectos del servicio: disponibilidad, latencia, tasa de error.

47. SLO (Service Level Objective)

Objetivo cuantificado para un SLI. Ejemplo: “99.9% de requests deben completarse en menos de 200ms”.

48. SLA (Service Level Agreement)

Acuerdo contractual con consecuencias si no se cumplen los SLOs. Típicamente menos estricto que el SLO interno.

49. Error Budget

Cantidad de error permitido dado un SLO. Si tu SLO es 99.9% de uptime, tienes un error budget de 0.1% de downtime al mes. Si lo agotas, se pausa el deployment de nuevas features.

50. APM (Application Performance Monitoring)

Categoría de herramientas que combinan métricas, logs y traces para monitorizar aplicaciones. New Relic, Datadog, Dynatrace son ejemplos.

51. Prometheus

Sistema open source de monitoreo y alerting, estándar de facto en el ecosistema Kubernetes. Almacena métricas en una base de datos de series temporales.

52. Grafana

Plataforma de visualización para métricas, logs y traces. Típicamente usada en conjunto con Prometheus.

53. Alerting

Sistema de notificaciones cuando métricas o logs cruzan umbrales definidos. La pesadilla operativa: balancear alertas demasiado sensibles (alert fatigue) con alertas demasiado permisivas (missed incidents).

54. Runbook

Documentación step-by-step de cómo responder a un incidente específico. Buena práctica: cada alerta enlaza a su runbook.

Seguridad#

55. Zero Trust

Modelo de seguridad que asume que ninguna red, dispositivo o usuario es de confianza por defecto. Cada acceso requiere verificación explícita.

56. mTLS (mutual TLS)

TLS donde no solo el cliente verifica al servidor (TLS normal) sino que el servidor también verifica al cliente. Estándar en service meshes para comunicación intra-cluster.

57. RBAC (Role-Based Access Control)

Modelo de permisos basado en roles. Los usuarios tienen roles, los roles tienen permisos, simplifica gestión a escala.

58. Secrets Management

Práctica de almacenar y rotar credenciales (passwords, API keys, certificates) de forma segura. HashiCorp Vault, AWS Secrets Manager son herramientas comunes.

59. SBOM (Software Bill of Materials)

Lista detallada de todos los componentes de software de un sistema, incluyendo dependencias transitivas. Crítico para detectar vulnerabilidades.

60. Supply Chain Attack

Ataque que compromete un proveedor o dependencia upstream para llegar al objetivo final. Los ataques a paquetes npm comprometidos en 2025 son ejemplos.

61. Container Scanning

Análisis automático de imágenes de contenedores para detectar vulnerabilidades conocidas. Trivy, Snyk, Clair son herramientas comunes.

Bases de datos y storage#

62. CAP Theorem

Principio que afirma que en un sistema distribuido solo puedes garantizar dos de tres propiedades: Consistency, Availability, Partition tolerance. Trade-off fundamental en diseño de sistemas distribuidos.

63. Eventual Consistency

Modelo donde el sistema garantiza que eventualmente todas las réplicas tendrán los mismos datos, pero no inmediatamente. Trade-off para conseguir mayor disponibilidad y performance.

64. Sharding

Partición horizontal de datos a través de múltiples bases de datos para escalar más allá de lo que una sola puede manejar.

65. Replication

Mantener copias de datos en múltiples servidores. Mejora disponibilidad y read performance, pero requiere gestionar consistencia.

66. Read Replica

Réplica de solo lectura de una base de datos primaria. Permite distribuir carga de lectura sin afectar a la escritura.

67. Connection Pooling

Reutilización de conexiones a base de datos para evitar el coste de abrir conexiones nuevas. PgBouncer es la herramienta clásica para PostgreSQL.

68. Object Storage

Storage diseñado para archivos sin estructura: imágenes, videos, backups. AWS S3 es el estándar. Económico pero con latencia mayor que block storage.

Herramientas y prácticas comunes#

69. Terraform

Herramienta de Infrastructure as Code más usada. Describes infraestructura en lenguaje declarativo (HCL) y Terraform se encarga de crear/modificar/eliminar recursos.

70. Ansible

Herramienta de configuration management que usa YAML para describir cómo configurar servidores existentes. Diferente de Terraform que crea infraestructura.

71. Jenkins

Servidor de CI/CD veterano. Versátil pero con UX y mantenimiento complicados. Aún muy usado en empresas grandes con pipelines complejos.

72. GitHub Actions

Plataforma de CI/CD integrada en GitHub. Workflows definidos en YAML, se ejecutan en respuesta a eventos del repo. Estándar de facto para proyectos open source.

73. ArgoCD

Herramienta de GitOps para Kubernetes. Sincroniza el estado del cluster con lo descrito en un repo Git.

74. Backup vs Snapshot

Snapshot es estado de un volumen en un momento; backup es copia que se puede restaurar. Snapshots son baratos pero dependen de la infraestructura subyacente; backups son más portables.

75. RTO (Recovery Time Objective)

Tiempo máximo aceptable para recuperar un servicio después de un fallo.

76. RPO (Recovery Point Objective)

Cantidad máxima de datos que se está dispuesto a perder en caso de fallo. RPO de 1 hora significa: si hay un desastre, podemos perder hasta una hora de datos.

77. Blue-Green Deployment

Estrategia de despliegue con dos entornos idénticos (blue y green). Solo uno sirve tráfico de producción. Para hacer un release, se prepara el otro entorno y se cambia el routing.

78. Canary Deployment

Estrategia donde una nueva versión se despliega gradualmente a un pequeño porcentaje de usuarios para verificar que funciona antes de ir al 100%.

79. Feature Flag

Mecanismo para activar/desactivar funcionalidades en producción sin desplegar código nuevo. Permite separar deployment de release.

80. Chaos Engineering

Práctica de inyectar fallos deliberados en sistemas de producción para verificar resiliencia. Netflix popularizó esto con Chaos Monkey.

Cómo usar este glosario#

La forma realista de absorber 80 términos no es leer este artículo una vez. Es marcarlo, volver cuando aparezca un término en una conversación o documentación, y consultar la definición específica. Después de unas semanas de uso ocasional, el vocabulario empieza a ser orgánico — no porque lo hayas memorizado, sino porque cada término aparece en contexto suficientes veces como para que se asiente.

La taxonomía del DevOps moderno está construida sobre conceptos interconectados. Entender qué es un pod ayuda a entender qué es un sidecar. Entender qué es eventual consistency ayuda a entender el CAP theorem. Entender qué es zero trust ayuda a entender por qué mTLS es relevante. La inversión en vocabulario produce retornos compuestos.

Para developers que están empezando a involucrarse con infraestructura — porque su empresa se ha movido a microservicios, porque necesitan hacer ownership de su despliegue, porque están preparándose para entrevistas senior — este glosario cubre el 80% del vocabulario que aparece en conversaciones técnicas habituales en 2026. El 20% restante son herramientas y conceptos específicos que se aprenden mejor cuando aparecen en contexto.