El mes pasado empezamos a contar el proceso de adopción de DevOps en Microsoft a través de los casos de varios equipos de la compañía. En el siguiente caso de esta serie, queremos hablar de la transición que llevó a cabo un equipo de un rol de operaciones clásico a un rol de ingeniería de confiabilidad de sitios (SRE). Es el caso del equipo de operaciones e ingeniería de confiabilidad de Xbox (xREO).

Esta transición no fue fácil y fue fruto de la necesidad cuando Microsoft decidió llevar los juegos de Xbox a los jugadores dondequiera que se encontraran mediante streaming de juegos en la nube (proyecto xCloud). Con el fin de ofrecer tecnología de vanguardia con una experiencia del cliente de alto nivel, el equipo tuvo que redefinir la forma en la que trabajaba; mejorar la colaboración con el equipo de desarrollo, invertir en automatización e involucrarse en las primeras fases del ciclo de vida de las aplicaciones. En este blog, revisaremos algunos de los conocimientos clave que el equipo aprendió a lo largo del proceso. Si desea leer el caso completo del equipo, vea el proceso del equipo xREO.

Requisitos coherentes de los juegos y necesidad de colaborar

Una experiencia coherente es fundamental para que funcione una sesión de streaming de juegos. Para asegurarse de que los jugadores experimentan un juego transmitido desde la nube, deben sentir como si se estuviera ejecutando en una consola cercana. Esto implica crear una solución en la nube distribuida globalmente que se ejecute en muchos centros de datos, cerca de los usuarios finales. La infraestructura global de Azure lo hace posible, pero el funcionamiento de un sistema que se ejecute en tantas regiones de Azure es un reto importante.

Los desarrolladores de Xbox que comenzaron a diseñar y crear esta tecnología comprendieron que no podían crear este sistema y pasárselo sin más al equipo de operaciones. Ambos equipos tenían que reunirse y colaborar en todo el ciclo de vida de la aplicación para que el sistema pudiera diseñarse desde el principio teniendo en cuenta cómo se utilizará en un entorno de producción.

Diseño de una solución en la nube teniendo en cuenta las operaciones

En muchas organizaciones de gran envergadura, es habitual ver a los equipos de desarrollo y operaciones trabajando en silos. Los desarrolladores no siempre tienen en cuenta las operaciones cuando planean y crean un sistema, mientras que los equipos de operaciones no están capacitados para tocar el código, aunque lo implementen y administren en producción. Con un enfoque SRE, la confiabilidad del sistema se crea a lo largo de todo el ciclo de vida de la aplicación y el equipo que administra el sistema en producción es un colaborador muy importante en la fase de planeamiento. En un enfoque nuevo, la involucración del equipo de xREO en la fase de diseño permitió un entorno de colaboración. Juntos eligieron la tecnología y diseñaron un sistema que podía funcionar con los requisitos necesarios para escalar los recursos.

Uso de contenedores para definir claramente la propiedad

Una de las primeras decisiones tecnológicas que tomaron conjuntamente los equipos de desarrollo y de xREO fue implementar una arquitectura de microservicios utilizando tecnologías de contenedor. Esto permitió a los equipos de desarrollo incluir microservicios de .NET Core en contenedores y eliminar la dependencia de la infraestructura de la nube que ejecutaba los contenedores y que era propiedad del equipo de xREO.

Otra decisión tecnológica que tomaron los dos equipos al principio fue el uso de Kubernetes como plataforma de orquestación de contenedores subyacente. Esto permitió al equipo de xREO aprovechar Azure Kubernetes Service (AKS), una plataforma en la nube de Kubernetes administrado que simplifica la implementación de clústeres de Kubernetes, lo que eliminó gran parte de la complejidad operativa que el equipo tendría que afrontar al ejecutar varios clústeres en varias regiones de Azure. Estas decisiones conjuntas dejaron clara la propiedad: los desarrolladores eran responsables de todo lo que había dentro de los contenedores, mientras que el equipo de xREO era responsable de los clústeres de AKS y otros servicios de Azure que constituyen la infraestructura en la nube que hospeda estos contenedores. Cada equipo es propietario de la implementación, la supervisión y el funcionamiento de sus respectivos componentes en producción.

Este tipo de enfoque define claramente las responsabilidades y permite una administración más sencilla de los incidentes en producción, algo que puede ser muy complejo en una arquitectura monolítica donde la lógica de la infraestructura y de la aplicación tienen dependencias de código que son difíciles de descubrir cuando las cosas se tuercen.

Escalado mediante la automatización de la infraestructura

Otro procedimiento recomendado en el que invirtió el equipo de xREO fue la automatización de la infraestructura. La implementación de varios servicios en la nube de forma manual en cada región de Azure no era una opción escalable y habría supuesto demasiado tiempo. Usando una práctica denominada “infraestructura como código” (IaC), el equipo utilizó plantillas de Azure Resource Manager para crear definiciones declarativas de entornos en la nube que permiten implementaciones en varias regiones de Azure con un esfuerzo mínimo.

La infraestructura administrada como código también se puede implementar usando integración y entrega continuas (CI/CD) para incorporar más automatización a los procesos de implementación de nuevos recursos de Azure en los centros de datos actuales, actualización de las definiciones de infraestructura y conexión de nuevas regiones de Azure cuando es necesario. La infraestructura como servicio y la integración y entrega continuas permitieron mantener la eficiencia del equipo, evitaron el trabajo rutinario repetitivo y eliminaron la mayor parte del riesgo de error humano que conllevan los pasos manuales. En lugar de dedicar tiempo al trabajo manual y a listas de comprobación, el equipo pudo centrarse en mejorar aún más la plataforma y su resistencia.

Ingeniería de confiabilidad de sitios en acción 

El proceso del equipo de xREO comenzó con la necesidad de aportar la mejor experiencia de cliente a los jugadores. Este es un buen ejemplo que muestra cómo los equipos que quieren satisfacer a los clientes con nuevas experiencias a través de una innovación vanguardista deben evolucionar y modificar la forma en la que diseñan, crean y utilizan el software. El cambio de enfoque hacia las operaciones y la colaboración más estrecha con los equipos de desarrollo fue la verdadera transformación que experimentó el equipo de xREO.

Con esta nueva mentalidad, el equipo se encuentra en posición de seguir creando más resistencia y escalar más el sistema y, de este modo, cumplir la promesa de ofrecer streaming de juegos en la nube a todos los jugadores.

Recursos

• Caso completo del equipo de xREO
• Otros casos: Proceso de adopción de DevOps en Microsoft
• Microsoft Game Stack