Preparación
Agregará sus propias mejoras a una arquitectura existente que cumple los requisitos de alta confiabilidad de la organización. Aquí analizaremos el contexto de fondo necesario para tener éxito con los ejercicios.
Contexto del problema
Contoso Shoes debe estar listo para su próximo lanzamiento de productos de alta gama, que se espera aumente el tráfico de manera notable. En los dos últimos años ha habido varios incidentes que han provocado que el sitio web esté sin conexión la mitad de una jornada. El sistema no se comprobó de arriba a abajo en el entorno de desarrollo y pruebas, con lo cual algunos errores llegaron a la fase de producción. Tardaron mucho tiempo en solucionar estos problemas, porque los operadores no eran capaces de identificar las causas principales con rapidez.
Se han producido algunos desafíos cuando determinados componentes no están disponibles. Las operaciones de escalado horizontal en el proceso se vieron afectadas cuando Azure Key Vault estaba mal configurado. Además, no hay ninguna estrategia en vigor para abordar las interrupciones regionales. Hace poco, un incidente provocó que toda la región de Europa occidental quedara inactiva. Dado que la carga de trabajo solo se ejecutaba en esa región, tuvieron que asumir pérdidas financieras hasta que la región volvió a estar activa.
Arquitectura actual
Para completar este desafío, debe conocer a fondo la arquitectura actual de Contoso Shoe. El enfoque estará en la capa de API.
Componentes
Todos los componentes de esta arquitectura están implementados en una misma región.
El plan de Azure App Service Estándar S2 proporciona la plataforma de proceso que hospeda la aplicación. El escalado automático está habilitado. En el entorno de desarrollo se usa la SKU del plan Básico B1.
Azure App Service proporciona la plataforma de aplicaciones que ejecuta el código de API en un contenedor. La característica de autenticación de App Service está habilitada para la autorización.
Las ranuras de implementación permiten almacenar una implementación de forma provisional y, posteriormente, intercambiarla con la implementación de producción. Solo se usan en producción.
Azure Container Registry almacena el código de API contenedorizada y se inserta a través de canalizaciones de integración continua/entrega continua (CI/CD) creadas y administradas por el personal del equipo de carga de trabajo. Container Registry se usa tanto en el entorno de producción como en el de desarrollo y pruebas.
Azure Cosmos DB con API SQL** almacena todo el estado relacionado con la carga de trabajo. La cuenta de base de datos de Cosmos DB tiene una sola base de datos que contiene algunos contenedores en el modelo de rendimiento compartido. La cuenta de Azure Cosmos usa el modo de capacidad sin servidor. Hay una instancia de producción y otra de desarrollo y pruebas.
Azure Key Vault almacena los secretos necesarios para que la API realice una llamada HTTP POST a una API externa de terceros como parte de un flujo de solicitud. La aplicación accede a los secretos a través de una referencia de Key Vault en la configuración de la aplicación de Azure App Service. Hay una instancia de Key Vault de producción y otra de desarrollo y pruebas.
Azure Log Analytics se usa como receptor unificado donde almacenar los registros y las métricas de todas las configuraciones de Azure Diagnostics de todos los componentes usados en la solución. Hay un área de trabajo de producción y otra de desarrollo y pruebas.
Azure Application Insights se usa para capturar datos de telemetría y registros de la API. Application Insights usa el modo independiente, sin escribir en un área de trabajo de Log Analytics dedicada. Los entornos de producción y de desarrollo/pruebas no comparten una instancia común.
Azure Pipelines se usa para la canalización CI/CD que compila, prueba e implementa la carga de trabajo en entornos de preproducción y producción. El personal del equipo de carga de trabajo administra tanto las canalizaciones como toda la infraestructura de la solución. Bicep es la opción tecnológica para la infraestructura como código (IaC).
Opciones de diseño
En la lista de componentes, la marca de implementación se compone de los servicios que participan en el procesamiento de una solicitud. Estos servicios incluyen App Services, el código de API y Cosmos DB. La marca también incluye componentes no funcionales: Key Vault, Container Registry. La aplicación tiene una dependencia de terceros en un marco de rendimiento y resistencia. Las identidades administradas por el sistema se usan entre los componentes de la marca.
En la marca, App Services se configura para escalar automáticamente en función de la carga.
Se usan entornos independientes para producción y desarrollo/pruebas. En el entorno de producción se usa la SKU del plan Estándar de App Service. Esta elección se tomó para tener la posibilidad de preparar la aplicación en una ranura antes de implementarla en producción. En el entorno de desarrollo y pruebas, la SKU se reduce a la SKU básica para optimizar costes. Ambos entornos tienen sus propias instancias de servicios. Entre los entornos solo se comparte Container Registry.
El código de API contenedorizado se entrega en una sola imagen de contenedor que se ejecuta en App Service. La API tiene múltiples puntos de conexión HTTP que varios servidores front-end usan en operaciones de lectura y escritura. Los servidores front-end quedan fuera del ámbito de este módulo, pero sí se abordan en términos generales en relación con el estado crítico de esta solución. El código se instrumentó con Application Insights para capturar algunos datos de telemetría básicos. El equipo que desarrolló este código también administra la canalización de CI/CD de la imagen de contenedor de API y las canalizaciones de CI/CD.
Compromisos
Sin embargo, como con todo, la arquitectura actual plantea inconvenientes. Los requisitos empresariales priorizan la optimización de costes sobre la confiabilidad y las operaciones. Para mantener los costes a raya, la arquitectura no ha evolucionado. Los componentes se quedan cortos al aprovechar las funcionalidades de confiabilidad que la plataforma ofrece. Por ejemplo, la elección de la SKU de proceso impide que la carga de trabajo use zonas de disponibilidad. En el caso de la telemetría, se usa una versión anterior de Application Insights que no está integrada con Log Analytics.
Además, el acceso a la carga de trabajo está excesivamente generalizado. Por ejemplo, sin ninguna integración de red virtual, todos los servicios de Azure están accesibles directamente a través de la red pública de Internet.
Cuando se desarrolló la solución, el equipo de desarrollo de aplicaciones usó una sola suscripción de Azure, lo que colocaba los entornos de desarrollo/pruebas y de producción en la misma suscripción. Esto se decidió así para facilitar el acceso a las herramientas a los equipos de DevOps. Sin embargo, los recursos de producción y los recursos de desarrollo y pruebas no están completamente aislados, sino que algunos de ellos se comparten entre los dos entornos. Sí que se obtuvo una suscripción aislada del resto de las soluciones de Contoso Shoes.
Además, el entorno de desarrollo y pruebas es un solo entorno que comparten todos los miembros del equipo de desarrollo y de control de calidad. Esta elección se justifica por el tamaño de los equipos y porque la coordinación entre ellos no necesitaba un mayor grado de aislamiento. Mientras el equipo y la solución evolucionaban, el entorno de desarrollo y pruebas único dificultaba cada vez más la integración a medida que los ciclos de vida de flujo de trabajo iban entrando en conflicto. El abandono y su impacto en la confiabilidad han tenido costes muy elevados.
Especificación del proyecto
La empresa quiere agregar funcionalidades a su arquitectura de la solución para poder controlar el aumento de la carga previsto. Estos son los requisitos empresariales:
- Desarrollo de la capacidad de resistir errores regionales ampliando la arquitectura a varias regiones
- Mejora de la experiencia de cliente al atender a los clientes con mayor rapidez en una región geográficamente más cercana a ellos
- Mantenimiento de una sintonía con la hoja de ruta de Azure y uso de las características de confiabilidad más recientes que los servicios de Azure ofrecen
- Detección de problemas con prontitud e identificación de su impacto en cascada en el sistema creando un modelo de mantenimiento general
Estos requisitos son solo la lista prioritaria de los planes de mejora. El personal del equipo de aplicaciones es consciente de que se deben tener en cuenta todas las áreas de diseño para elevar la confiabilidad de esta solución a estándares críticos. Tenga la seguridad de que no dejarán de mejorar su solución y sus operaciones después de haberles ayudado con las cuestiones analizadas en los próximos ejercicios. Bienvenido al equipo. Contoso Shoes está deseando escuchar sus recomendaciones.
Configurar
En este proyecto de desafío, asumirá el rol de un arquitecto que ayudará a Contoso a lograr sus resultados de confiabilidad, empezando por los elementos priorizados anteriores.
- Se recomienda usar la herramienta de trazado de diagramas de arquitectura para visualizar la arquitectura.
- En este desafío no necesita una suscripción de Azure si está familiarizado con los servicios y sus características.