Arquitectura nativa de la nube y de infraestructura

Te damos la bienvenida al Capítulo 10: Arquitectura nativa de la nube y de infraestructura. Durante la mayor parte de la historia del software, la infraestructura llegaba después de la arquitectura: un equipo de operaciones recibía una aplicación terminada y buscaba servidores donde ejecutarla. Esa separación ha desaparecido. Hoy, la elección entre máquinas virtuales, contenedores, plataformas y funciones decide buena parte del costo. El número de zonas de disponibilidad y de regiones decide la disponibilidad. Y el pipeline de despliegue decide con qué rapidez y seguridad puede un equipo cambiar cualquier cosa.

Este capítulo es para desarrolladores y arquitectos que quieren elegir, justificar y operar las plataformas de las que dependen sus sistemas, sin que nadie les venda una pila tecnológica. Se apoya en el Capítulo 0, que presentó los servidores, las máquinas virtuales, los contenedores, los modelos de servicio en la nube, las regiones y las zonas de disponibilidad, y en el Capítulo 9, que explicó cómo hacer que los sistemas escalen, se degraden de forma elegante y sigan siendo observables. Aquí esas ideas se encuentran con las plataformas en las que hoy se ejecutan la mayoría de los sistemas. Las decisiones sobre dónde y cómo se ejecuta el software son costosas de revertir, atraviesan a todos los equipos y fijan los atributos de calidad que el Capítulo 2 te pidió especificar. Y le sigue el Capítulo 11, con cómo juzgar una arquitectura, incluida su infraestructura, y cómo cambiarla de forma segura a lo largo del tiempo.

El ejemplo recurrente es la plataforma de reparto de comida que se usa a lo largo de todo el curso: las apps de clientes y de restaurantes, un servicio de pedidos, las cartas, los pagos, el despacho de repartidores y una intensa hora punta de la cena. Las cuatro primeras secciones tratan de los fundamentos. La sección diez punto uno expone quién gestiona qué, desde la infraestructura como servicio, o IaaS, pasando por PaaS y las funciones, hasta SaaS. Según el modelo de responsabilidad compartida, tus datos, tus identidades y tu configuración son siempre responsabilidad tuya. La sección diez punto dos explica las imágenes de contenedor, el plano de control y los nodos de Kubernetes, y el bucle de reconciliación que está en su núcleo. También es honesta sobre cuándo Kubernetes es excesivo. La sección diez punto tres recorre los doce factores de la aplicación de doce factores, con las salvedades actuales, y muestra cómo auditar un servicio existente frente a ellos. La sección diez punto cuatro trata la infraestructura como código: herramientas declarativas, estado y deriva, módulos, infraestructura inmutable, GitOps, política como código y pruebas.

La idea más importante de este capítulo es el estado deseado declarado, reconciliado continuamente por la automatización. Este diagrama de la sección diez punto dos muestra cómo lo hace Kubernetes. Declaras el estado deseado. Aquí, tres réplicas de la versión dos punto cuatro del servicio de pedidos. Un controlador observa el estado real del clúster y encuentra solo dos pods en ejecución. Compara lo que ve con lo que se declaró y descubre que falta un pod. Así que actúa y solicita un pod nuevo. El bucle se repite con cada evento de cambio, y también periódicamente. Como actúa sobre la diferencia actual y no sobre una secuencia de eventos recordada, los eventos perdidos y los reinicios no causan daños duraderos. La misma idea recorre el código de infraestructura, GitOps, los pipelines de despliegue y la infraestructura inmutable. Una persona cambia una descripción, que se revisa, se versiona y es auditable, y las máquinas hacen el resto.

Las cuatro secciones siguientes tratan del cambio, la escala, las personas y el dinero. La sección diez punto cinco sigue un cambio desde el commit hasta producción a través de un pipeline de CI/CD, compara los despliegues gradual, azul-verde, canario y en sombra, y separa el despliegue del lanzamiento con feature flags. La sección diez punto seis compara las estrategias de recuperación ante desastres, explica qué le hace a la consistencia replicar datos entre regiones, y trata la arquitectura basada en células y las funciones en el borde. La sección diez punto siete trata la plataforma interna para desarrolladores como un producto, con caminos dorados y salvaguardas, y muestra cómo medir si ayuda. Y la sección diez punto ocho convierte el costo en una cualidad arquitectónica, medida por pedido, y trata la dependencia del proveedor como un compromiso al que hay que poner precio y no como un pecado que haya que evitar.

La segunda idea es que cada opción de este capítulo es un compromiso. Este diagrama de la sección diez punto seis muestra cuatro estrategias de recuperación ante desastres una al lado de otra. Cada una se juzga por dos cifras que vienen del negocio: el objetivo de tiempo de recuperación, o RTO, cuánto tiempo puedes estar caído, y el objetivo de punto de recuperación, o RPO, cuántos datos puedes perder. Con copia de seguridad y restauración, las copias se guardan en una región de recuperación en la que no se ejecuta nada. La recuperación lleva horas, y pierdes todo lo ocurrido desde la última copia de seguridad. Con un pilot light, los datos se replican pero los servidores de aplicaciones están apagados. Con un warm standby, ya se ejecuta una pequeña copia operativa que escala cuando hace falta. El tiempo de recuperación baja a decenas de minutos, y después a minutos. Con activo-activo, una segunda región completa ya está atendiendo tráfico, y ambas cifras son casi cero. Cada paso hacia la derecha compra una recuperación más rápida y menos pérdida de datos, a cambio de un costo continuo y una complejidad mayores. La elección correcta depende de la carga de trabajo y de la organización.

Al final del capítulo, podrás comparar los modelos de servicio y de despliegue en la nube, y asignar las obligaciones de una carga de trabajo según el modelo de responsabilidad compartida. Entenderás cómo mantiene Kubernetes un estado deseado declarado, y sabrás juzgar cuándo es excesivo. Podrás elegir entre los despliegues gradual, azul-verde, canario y en sombra, y usar feature flags para separar el despliegue del lanzamiento. Y podrás calcular costos unitarios, como el costo por pedido, y evaluar la dependencia del proveedor como un compromiso con precio.

Cada sección puede leerse por separado, pero el orden es deliberado. No se puede razonar sobre las estrategias de despliegue sin saber qué hace Kubernetes durante un despliegue progresivo. Si eres nuevo en las operaciones, lee primero los recuadros para principiantes y la sección del Capítulo 0 sobre servidores y la nube. No te preocupes por memorizar nombres de herramientas. Los productos cambian cada pocos años, mientras que los mecanismos perduran. Los proveedores se mencionan como ejemplos, no como recomendaciones. Al final de cada sección hay preguntas de autoevaluación. Respóndelas mentalmente antes de mirar las respuestas. Calcula unas tres horas para leer el capítulo entero. Cuando estés listo, hay una prueba opcional del capítulo de unos cuarenta y cinco minutos, con veinte preguntas de opción múltiple y dos respuestas escritas. La nota de aprobado es el ochenta por ciento.

Esa es la forma del capítulo. Empieza por la sección diez punto uno, sobre los modelos de servicio y de despliegue en la nube, y quién es responsable de qué. Nos vemos allí.