Formación escrita en DevOps

¿Cómo realizar despliegues de código de bajo riesgo en producción con DevOps?

En muchas organizaciones de TI, los despliegues en producción son complicados y estresantes. Para evitar problemas, se intenta reducir al mínimo su frecuencia. Eso lleva inevitablemente a desplegar lotes más grandes, que causan problemas aún mayores. Este círculo vicioso se agrava y, por desgracia, describe la situación de muchas de las mayores organizaciones, incluidas algunas cuyo negocio principal es el software y la tecnología.

Su equipo de DevOps tiene mecanismos integrados de control y mitigación de riesgos

En una organización de TI típica, desarrollo construye el software y operaciones lo despliega. Con DevOps, su propio equipo autosuficiente y competente asume los controles y la mitigación de riesgos que antes dependían de otros equipos independientes. Los despliegues automatizados y las revisiones entre pares también se hacen dentro del equipo.

Como los entornos de producción y los demás son activos tan importantes como el software que produce, su equipo de DevOps adopta tres principios:

1. Garantizar que todos los entornos sean coherentes en sistemas operativos, componentes, interfaces, niveles de parches y demás dependencias, así como en su software y sus configuraciones.
2. Dar la máxima prioridad a corregir cualquier impedimento que rompa la coherencia de los entornos.
3. Usar las mismas técnicas de despliegue en todos los entornos para que ensayar despliegues en producción sea parte de su trabajo habitual.

Su mecanismo integrado de despliegue de autoservicio

El mecanismo automatizado de despliegue de autoservicio sigue estos pasos.

1. Programar y registrar el código en el tronco.
2. Construir paquetes que se puedan desplegar.
3. Validar los paquetes, las dependencias y la preparación de la configuración.
4. Validar que el entorno esté preparado.
5. Ejecutar pruebas automatizadas.
6. Registrar los resultados de todas las validaciones y pruebas automatizadas para auditorías y cumplimiento normativo.
7. Desplegar los paquetes en el entorno de destino.
8. Ejecutar pruebas automatizadas en el entorno de destino para validar el despliegue.
9. Monitorizar las métricas de sistema, rendimiento y actividad del entorno de destino.
10. Dar información rápida y corregir o revertir el despliegue si algo sale mal.

Los despliegues y las publicaciones son cosas distintas

Con el mecanismo automatizado de autoservicio para desplegar código en producción y otros entornos, su equipo de DevOps puede hacer despliegues diarios. Como no todos los despliegues suponen ofrecer una funcionalidad o ventaja a sus clientes, el equipo debe diseñar las aplicaciones, los entornos o ambos de modo que publicar no exija modificar código ni hacer despliegues adicionales.

Patrón de despliegue azul-verde

Uno de los retos al automatizar el despliegue es el cambio en sí, que lleva el software desde las pruebas finales hasta producción. Suele hacerse rápido para reducir el tiempo de inactividad. El enfoque azul-verde utiliza dos entornos de producción tan idénticos como sea posible. En cualquier momento hay uno activo, por ejemplo, el azul. Mientras prepara una versión nueva, hace las pruebas finales en el entorno verde. Cuando el software funciona allí, cambia el enrutador para dirigir todas las solicitudes entrantes al entorno verde. El azul queda inactivo.

Patrón de despliegue canario
(también llamado lanzamiento en la sombra)

Antes era habitual usar canarios en minas de carbón como alerta temprana. Gases tóxicos de la mina, como el metano o el dióxido de carbono, mataban al ave antes de afectar a los mineros. Las señales de malestar del canario avisaban de que las condiciones no eran seguras.

Inspirado en los canarios de las minas, el patrón canario despliega versiones en un subconjunto de usuarios o servidores. La idea es desplegar primero el cambio en unos pocos servidores, probarlo y después extenderlo al resto. Así se obtiene una alerta temprana y se reduce el impacto en el tiempo de inactividad. Si el despliegue canario falla, los demás servidores siguen funcionando.

Facebook y Google, entre otros gigantes tecnológicos, usan un patrón de despliegue canario llamado «lanzamiento en la sombra». Publican y prueban gradualmente las funcionalidades nuevas con un grupo reducido de usuarios antes de ofrecerlas a todos. Así pueden ver si gustan o no y evaluar su efecto en el rendimiento. Facebook llama «Gatekeeper» a su herramienta de lanzamiento en la sombra porque controla el acceso de los usuarios a cada funcionalidad nueva.

Se llama lanzamiento en la sombra porque estas funcionalidades no suelen anunciarse. Se despliegan discretamente al 1 % de los usuarios, luego al 5 %, después al 30 % y así sucesivamente. A veces, una funcionalidad se prueba de este modo durante unos días y no vuelve a verse. Probablemente no dio buenos resultados o la empresa solo buscaba información inicial para orientar el desarrollo.

Patrón de publicación con sistema inmunitario de clúster

Este patrón amplía el despliegue canario. Requiere que la monitorización del rendimiento y de la actividad del software esté estrechamente integrada con el proceso de publicación.

En el patrón canario de la ilustración anterior, tras el despliegue inicial en el servidor naranja, la monitorización registra todas las métricas del sistema, de rendimiento y de actividad del software y genera alertas tempranas si los problemas superan ciertos umbrales. Esto revierte automáticamente el código instalado en el servidor naranja.

Si las pruebas automatizadas del servidor naranja y la monitorización dan buenos resultados, el equipo de DevOps puede desplegar el código en los demás clústeres azules con mucha más confianza. En resumen, el patrón de publicación con sistema inmunitario de clúster ofrece a su equipo:

• Protección adicional frente a problemas que podrían pasar inadvertidos en las pruebas automatizadas.
• Información rápida y reversión automatizada en caso de problemas en producción.

Conmutadores de funcionalidades

Los conmutadores permiten activar y desactivar funcionalidades de una aplicación. Una vez desplegado en producción todo el código de una funcionalidad, basta con activar su conmutador para publicarla. Los conmutadores suelen ser ajustes en archivos de configuración del entorno de ejecución o en bases de datos de configuración del sistema.

Con estos conmutadores, el equipo de DevOps puede desactivar una funcionalidad si el despliegue canario provoca errores o una experiencia de usuario deficiente. También puede desactivar funcionalidades que consumen muchos recursos y son relativamente poco importantes si el sistema tiene problemas para escalar. Así, aunque el sistema no pueda escalar con todas sus funcionalidades, los clientes pueden seguir aprovechando el máximo rendimiento de las funciones críticas. Por ejemplo, en una tienda en línea puede desactivar temporalmente la consulta de facturas para dejar más CPU y memoria al proceso de compra.

En una arquitectura orientada a servicios, los equipos de DevOps pueden desplegar distintas versiones de un servicio sin activarlas. Una vez desplegadas todas las versiones nuevas necesarias para una funcionalidad o flujo de servicio, active sus conmutadores para poner en funcionamiento el flujo nuevo.

Diseñe la arquitectura para publicar con más seguridad

No existe una arquitectura perfecta que sirva para todos los productos y servicios de software y a cualquier escala.

Al construir la primera plataforma de TI de una empresa emergente, normalmente se elige una arquitectura monolítica para llegar al mercado de la forma más rápida y económica y validar el caso de negocio. El problema es que los aspectos que se distinguen por su función (funciones principales y complementarias, interfaces de usuario y de sistema e integraciones) se entrelazan en vez de constituir componentes separados. Muchas organizaciones grandes, entre ellas Amazon, Google, Facebook y Ebay, tuvieron que abandonar sus arquitecturas monolíticas para escalar rápidamente y poder publicar y ampliar funcionalidades con bajo riesgo. Pasaron a arquitecturas orientadas a servicios o microservicios mediante el patrón Strangler Application.

Patrón Strangler Application para migrar a microservicios con poco riesgo

Sustituir por completo un sistema complejo puede exigir un esfuerzo enorme. A menudo hace falta migrar gradualmente a un sistema nuevo y mantener el antiguo para las funcionalidades pendientes de migrar. Sin embargo, al ejecutar dos versiones separadas de una aplicación, los clientes deben saber dónde se encuentra cada funcionalidad. Cada vez que se migra una funcionalidad o servicio, hay que actualizar los clientes para dirigirlos a la ubicación nueva.

El patrón Strangler Application sustituye de forma gradual ciertas funcionalidades por aplicaciones y servicios nuevos. Cree una fachada que intercepte las solicitudes dirigidas al sistema heredado del backend. La fachada las envía a la aplicación heredada o a los servicios nuevos. Las funcionalidades existentes se pueden migrar gradualmente al sistema nuevo y sus consumidores pueden seguir usando la misma interfaz sin darse cuenta de la migración.

Ebay fue una de las primeras organizaciones en usar el patrón Strangler Application para migrar su arquitectura monolítica heredada a microservicios. Empezó por situar las aplicaciones detrás de API universales bien definidas en su ecosistema, de modo que no tuvo que reescribir todo el código de una sola vez. Reorganizó sus grupos de ingeniería en equipos pequeños de 6 a 10 personas. Ahora un equipo de hasta 10 personas puede gestionar la API universal de la plataforma de subastas, que es la API de subastas más utilizada del mundo.

CONCLUSIÓN

En la mayoría de los departamentos de TI, los equipos no tienen la responsabilidad de crear patrones de despliegue y arquitecturas escalables, preparados para el futuro y más seguros. Sin embargo, diseñar arquitecturas y funcionalidades que permitan desplegar de forma más rápida y segura es un requisito fundamental para tener éxito con DevOps.

Los despliegues diarios, más rápidos y de bajo riesgo permiten que sus equipos y usted aprovechen las ventajas del despliegue continuo y publiquen versiones sin problemas.