Preparación
Agregará sus propias mejoras a una arquitectura existente que cumpla los requisitos de alta confiabilidad de la organización. Aquí, analizaremos el contexto en segundo plano que debe 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 ha probado completamente en el entorno de desarrollo y pruebas y algunos errores se han convertido en producción. La solución de problemas y la corrección tardaron mucho tiempo, ya que los operadores no pudieron identificar las causas principales rápidamente.
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 estaba ejecutando en esa región, la empresa tenía que soportar pérdidas financieras hasta que se realizase una copia de seguridad de la región.
Arquitectura actual
Para completar este desafío, debe tener una buena comprensión de la arquitectura actual de Contoso Shoes. Vamos a centrarnos en su capa de API.
Componentes
Todos los componentes de esta arquitectura se implementan en una sola región.
El plan de Azure App Service S2 Standard SKU proporciona la plataforma de proceso que hospeda la aplicación. El escalado automático está habilitado. El entorno de desarrollo usa la SKU B1 básica.
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 en contenedor y se inserta a través de canalizaciones de integración continua/entrega continua (CI/CD) que el equipo de carga de trabajo crea y administra. Tanto la producción como el entorno de desarrollo y pruebas usan el registro de contenedor.
Azure Cosmos DB con SQL API 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 equipo de cargas de trabajo administra las canalizaciones, que también administran toda la infraestructura de su 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, el sello de implementación consta de servicios que participan en el procesamiento de una solicitud. Estos servicios incluyen App Services y el código de API y Cosmos DB. La marca también incluye componentes no funcionales: Key Vault y 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. El entorno de producción usa la SKU estándar del plan de App Service. La empresa tomó esta opción para poder pre procesar la aplicación en una ranura antes de implementarla en producción. El entorno de desarrollo y pruebas usa la SKU básica para la optimización de costos. Ambos entornos tienen sus propias instancias de servicios. Los entornos solo comparten 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 varios puntos de conexión HTTP que usan los distintos servidores front-end para lecturas y escrituras. Los front-end están fuera del ámbito de este módulo, pero están en el ámbito del panorama general para el estado crítico de esta situació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 ofrece la plataforma. 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, colocando desarrollo/pruebas y producción en la misma suscripción para facilitar las herramientas para los equipos de DevOps. Sin embargo, los recursos de producción y los recursos de desarrollo y pruebas no están completamente aislados. Algunos recursos se comparten entre los dos entornos, aunque obtenían una suscripción aislada del resto de las soluciones de Contoso Shoes.
Además, el entorno de desarrollo y pruebas es un único entorno que se comparte entre todos los miembros del equipo de desarrollo y 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. A medida que evolucionó el equipo y la solución, el único entorno de desarrollo y pruebas provocó cada vez más la complejidad de la integración a medida que los ciclos de vida de la secuencia de trabajo colisionaron. 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
- Alinee con la hoja de ruta de Azure y aproveche las últimas características de confiabilidad que ofrecen los servicios de Azure.
- 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 equipo de la aplicación tiene en cuenta que todas las áreas de diseño de deben considerarse para ofrecer 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á esperando escuchar sus recomendaciones.
Configurar
En este Proyecto de desafío, tomará el rol de un arquitecto que ayudará a Contoso Shoes a lograr sus resultados de confiabilidad, empezando por los elementos priorizados de la sección anterior.
- 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.