Un vistazo de cerca: Azure Well-Architected Framework

Bienvenidos Acerca de… ¡Hola! Gracias por entrar en “Un vistazo de cerca a: Azure Well- Architected Framework”. Espero poder aportarte los conocimientos mínimos y necesarios con este workshop para que puedas ponerlo en práctica. Jose María Flores Zazo, autor

Presentación Introducción(1/9) Hoy en día las aplicaciones basadas en la nube son la norma y no la excepción. Azure, como bien es sabido, dispone de una gran cantidad de servicios con cobertura global y una amplia disponibilidad. WAF es una orientación sobre las mejores prácticas para guiar a los clientes a diseñar, construir, operar y administrar el ciclo de vida de las aplicaciones en la nube. WAF se basa en 5 pilares: • Coste de optimización • Excelencia operativa. • Eficiencia en el desempeño. • Fiabilidad. • Seguridad. A lo largo de las siguientes páginas vamos a profundizar sobre cada uno de estos pilares. Espero que las explicaciones sean simples y concisas. Aunque existe un magnifico sitio en Microsoft que nos habla de ella, aquí va mi aportación centrada en la experiencia de estos últimos años. Comencemos. Azure Well-Architected Framework – WAF

¿Qué y por qué? Introducción(2/9) Las aplicaciones de las organizaciones se están expandiendo más allá de las exceptivas iniciales. Ya sea por qué añaden big data, analíticas en tiempo real o IA, por poner un pequeño ejemplo. Esta transformación es un desafío constante para el equipo de arquitectura, existen muchos aspectos que se han de considerar, comenzado por el coste optimo de nuestra aplicación. Como ya he comentado antes WAF proporciona unas pautas para implementar tus workloads alineados con las mejores prácticas recomendadas por Microsoft basado en cinco pilares. La transformación digital, es decir, aprovechar lo último en tecnológicas para renovar la gestion de un negocio. Por ejemplo, mejorar la experiencia del cliente para que la aplicación sea más ágil. WAF la guía que nos permita acelerar la transformación digital de una forma robusta en los siguientes contextos: • Estrategia. Fosilizarse en la identificación comercial y motivaciones para adoptar la nube. ¿Cuáles son los puntos débiles?, ¿qué proyecto priorizar?, etc. • Plan. Tras definir la estrategia, necesitamos un plan de acción para la adopción. • Inicio. Aquí es donde WAF entra en acción y debemos alinearlos con las mejores prácticas. • Adoptar. Nuevamente WAF hace su aparición, ya que nos permite modernizar, innovar, etc. pero contemplando que todo lo que hacemos tenga sus beneficios comerciales. Azure WAF – Marco de trabajo para un correcto diseño en Azure (mi traducción)

¿Qué y por qué? Introducción(3/9) • Gobierno. Se trata del plan de trabajo de nuestro workloads que permite ir mejorando de forma iterativa. • Administrar. Definir parámetros para operaciones, centrándose en métricas de negocio, analizando telemetrías, etc. para asegurar la continuidad del negocio. WAF proporciona un acelerador para la transformación digital, pero a veces esto nos hace pasar por alto decisiones de arquitectura que deben mover las aplicaciones aun correcto uso de las tecnologias disponibles. Expongo un caso: nos vamos a la nube, y podemos proporcionar un lift-shift de un servicio web via IaaS, pero luego nos encontramos que debemos añadir paralelismos, si no se hace con cuidado volvemos a generar problemas, quiero decir, que, si paras un poco antes e inviertes también un poco, lo ideal en este ejemplo es generar un servicio web tipo PaaS, por ejemplo. Ir a IaaS introduce nuevos problemas a resolver en Azure, via más IaaS o finalmente vas a un PaaS y en estos momentos es cuando uno se acuerda que ampliar la inversión inicial habría sido mucho mejor. Por tanto, muchas preguntas y consideraciones que asaltaran al equipo de arquitectura será WAF quien intente ayudar a obtener respuestas. Aunque el ejemplo anterior ya te pone sobre un aviso, por ejemplo, aquí amplio un poco más para que puedas entender a donde quiero llegar: • ¿Tu aplicación tenga una demanda fluctuante de rendimiento?, la nube se adapta si se diseña correctamente. Por ejemplo, ayuda con las piezas que mejor pueden hacer un scale up o scale out.

¿Qué y por qué? Introducción(4/9) • ¿Necesitas monitorización continua?, ¿optimizar recursos?, ¿mejorar y evolucionar según crece tu aplicación?. Pues WAF te pondrá en la búsqueda para tener en cuenta el rendimiento a medida que tus bases de datos crecen, por ejemplo. • ¿Es necesario añadir DevOps en tu ciclo de vida?. WAF ayuda a enfocar su trabajo desde el inicio y no de forma tardía. • ¿Tus aplicaciones deben ser resilentes y con alta disponibilidad?, ¿qué tal va tu plan de recuperación ante desastres?, … • La seguridad. • Y por ultimo, la no menos importante pregunta, ¿costes?, la nube ayuda a centrarte en un aprovisionamiento optimo para optimizar la inversión. Aunque la nube es pago por uso, es necesario planificar para que no lleguen sorpresas. Esto responde al ¿por qué?, ya que WAF te pondrá en objetivo ante tus ojos, para que no lo olvides y se intente arreglar o pensar en una fase tardía. ¿Qué es WAF? Cuando las cargas de trabajo están en la nube, son diferentes en construcción, implementación y configuración a trabajar on-premise. Adoptar la arquitectura adecuada, es la clave para moverse a la nube y WFA ayuda en cada paso. Piensa que es un modelo para adoptar con éxito la nube que consta de cinco pilares, como hemos dicho antes. A continuación, pondré un breve resumen sobre ellos, pero más adelante desarrollaré con más exhaustividad cada pilar.

¿Qué y por qué? Introducción(5/9) Optimización del coste El principio básico es empezar por poco y escalar a medida que avanzamos. En lugar de hacer una inversión inicial, se recomienda seguir un enfoque Build-Mesaure-Learn (construir, medir, apender), que esté alineado con Azure Cloud Adoption Framework (CAF). Se enfoca en construir un MVP (producto mínimo viable), midiendo la retroalimentación y luego usando un enfoque fail fast (fallo rápido) para optimizar el coste. Usa la calculadora de costes de Azure, te ayudará para estimar costes iniciales y luego usar Azure Cost Management para revisar el coste operativo continuo. Excelencia operativa El éxito de una implementación en la nube depende de lo bien que esté engrasado tu motor de operaciones. Cuando más visibilidad, mucho mejor para mantener siempre encendido tu entorno productivo. El enfoque de seguimiento y registro debe ser coherente con los recursos adoptados. Los datos de monitorización deben ser analizados mediante las herramientas pertinentes, también han de ser visualizados adecuadamente para aprovechar y detectar tendencias, ya sea el uso de recurso o trafico inusual, esto alertará al equipo de operaciones.

¿Qué y por qué? Introducción(6/9) Eficiencia en el desempeño Los usuarios finales esperan una solución que funcione bien independientemente del trafico que manejes. Por eso una de las ventajas de la nube, es el escalado vertical (potencia y capacidad a tus recursos) u horizontal (agregar más instancias a tus recursos). El verdadero poder de la nube es el escalado horizontal, muchas veces es más economico que darles más potencia y capacidad a tus recursos. Fiabilidad Es decir, que han de poder funcionar y recuperarse inmediatamente con un mínimo daño. La confiabilidad es la función combinada de resilencia y disponibilidad. Debido al naturaleza distribuida de las implementaciones de la nube, cualquier fallo en uno puede afectar a otros componentes. Esto es un factor a tener en cuenta por arquitectura. Como regla general debes aprovechar las características inherentes al recurso del servicio de la nube, ya sean VM o bases de datos. No solo en tu capa de infraestructura, si no que debe ser un principio en que debes basarte para el desarrollo de la aplicación.

¿Qué y por qué? Introducción(7/9) Seguridad Tienes varios niveles y debes considerarlos todos. Van desde la infraestructura a la propia aplicación. Debes considerar este nuevo perímetro de seguridad como algo integral en la aplicación, que van desde: RBAC, Azure AD, cifrados de datos, TDE, gateways, etc. Hasta herramientas como Azure Defender que pone la IA a tu servicio. Optimización del coste Ofrecer el máximo valor a la inversión Excelencia operativa Mantener la luz verde con los sistemas de producción Eficiencia en el desempeño Agilidad para satisfacer las cambiantes demandas de rendimiento Fiabilidad Recuperación ante fallos con la mínima disrupción Seguridad Protección de extremo a extremo de la aplicación

Algunos casos de uso Introducción(8/9) Los escenarios del mundo real suelen ser casi siempre difíciles, es como el lema de los Navy Seals “el día facil fue ayer”, lo mismo ocurre aquí, “el proyecto facil fue el anterior”. El éxito de la implementación de WAF dependerá de lo fácil o lo dificil que sea adaptar WAF a los escenarios de la vida real. Estos 2 casos que explico ahora serán los hilos conductores para cada uno de los pilares que veremos más adelante y que casi seguro el 80% de los que estéis leyendo esto, habéis visto alguna vez en vuestra vida profesional. Retail El comercio electrónico es clave en el sector minorista. Es un campo muy competitivo. Los sitios web de comercio electrónico deben diseñarse para que la experiencia del cliente sea optima y garantice el negocio. Una WAF puede ayudar a identificar los componentes correctos para hospedar, escalar y proteger su solución de comercio electronico además de su sostenibilidad a largo plazo. Por ejemplo, estos son puntos clave en el negocio: • Actualizaciones periódicas de los catálogos, para añadir nuevos productos a la venta. • Transacciones de pago seguras y almacén de información personal. • Recuperación de información rápida de los productos. • Experiencia de búsqueda personalizada dependiendo del cliente y las compras anteriores. • Capacidad de gestionar tráfico en fechas críticas como navidades. Aproximándonos a la realidad – El éxito depende de la dificultad para adaptar WAF

Algunos casos de uso Introducción(9/9) Financiero La mayoría, bancos y aseguradoras, se enfrentan en estos momentos a una migración a la nube. Estas empresas tienen mucho legacy y es un gran desafío adaptarlas. Puede haber dependencias extritas (por ejemplo, los cajeros automáticos), pero la mayoría podrán ser solventadas gracias al uso correcto de WAF. A continuación, algunas consideraciones claves: • La gestión de la identidad debe ser perfecta, tanto para clientes como empleados. • Los tiempos de inoperancia no deberían existir, son inaceptables en soluciones bancarias. • Usa PaaS para modernizar algunos servicios legacy. • La seguridad de datos es crucial y aun más cuando se hace una migración o actualización. • Debe ser flexible para adoptar arquitecturas hibridas, algunos componentes han de permanecer en las instalaciones del cliente por razones de seguridad. Azure Arc es tu aliado. • La seguridad que además debería ser proactiva. Para concluir: en los anteriores caos de uso, el éxito de la transformación digital radica en establecer desde el principio el contexto, identificar las herramientas y servicios, así como el marco más adecuado para su implementación.

I Coste de Optimización

Retorno de Inversión Coste de Optimización(1/5) Poder estimar el Return Of Investment (ROI), saber que es Capital Expediture (CapEx) u Operational Expediture (OpEx), son términos que debes manejar: • ROI, es una razón financiera que compara el beneficio o utilidad obtenida en relación a la inversión realizada. • CapEx, es cuando un negocio invierte en la compra de un activo (un servidor on-premise) o para añadir valor a un activo para extender la vida útil (ampliar capacidad a tu servidor on-premise) • OpEx, capital que se invierte en servicios o productos y se factura al instante. Convertir CapEx a OpEx es una de las principales ventajas de la nube, pero debes tener un enfoque fino a la hora de optimizar los costes, incluso antes de implementar el primer recurso para asegurar el ROI optimo. Monitorizar el coste ayuda, pero solo es la punta del iceberg. ¿Cómo diseñar un ROI optimo? Es un proceso continuo y tendrás que revisarlo a lo largo de vida de la aplicación. Aquí van los principios de diseño: 1. Identificar el modelo de coste adecuado. Azure proporciona un modelo de pago por uso, pero existen distintas opciones donde elegir. Junto a los cargos de computación, el coste de software, el coste del SO, etc. están incluidos. Pero también tienes opciones donde puedes usar las licencias que ya dispones. Puedes aprovechar estas opciones para abaratar costes: Azure hybrid benefit, Azure sport virtual machines, reservations o Azure dev/test pricing. ROI, CapEx, OpEx – Palabras que debes manejar

Retorno de Inversión Coste de Optimización(2/5) 2. Escoger el tamaño adecuado para el recurso. Encontrar el recurso adecuado y dimensionarlo es importante para mantener un coste mínimo. Por ejemplo, tienes que estudiar la capacidad de calculo, de almacenamiento, trafico o transacciones. Otro punto es el nivel de control que deseas en tu recurso: usar un IaaS o un PaaS. Cada recurso tendrá sus peculiaridades. Un Azure Storage debes mirar si quieres LRS o GRS, en una VM si quieres tener potencia gráfica o por contrario mayor CPU y RAM, etc. 3. El presupuesto siempre a la vista. Las decisiones de diseño se basan en requisitos de la aplicación, sin embargo, los componentes han de tenerse en cuenta para el proceso. Ten en tu punto de mira cosa como la alta disponibilidad, resilencia, escalabilidad, seguridad, etc. Lo que quiero decir, que si estas pensando en implementar patrones de seguridad para proteger desastres en regiones, puede ser más economico un cambio en el diseño que comprar el recurso más caro de Azure. 4. Planifica el escalado. Escalar bajo demanda es un punto clave para recudir el gasto. Aprovisiona menos máquinas en horas valle y más en horas punta, o quita instancias los fines de semana o tras una campaña publicitaria. Siempre en vista de escalado horizontal o vertical; como comenté antes horizontal es el paradigma de la nube. 5. Implementa una monitorización continua. Como dije antes, optimizar es un continuo proceso de monitorización. Verifica periódicamente los costes, ya que las aplicaciones están vivas y crecen los requerimientos, por ejemplo. Dedícate a supervisar Metricas par posibles picos, etc. Por ejemplo, puede que un sistema de almacenaje aumenta el coste cuantos más datos tienes.

Retorno de Inversión Coste de Optimización(3/5) Caso de Uso: Retail Ya sabemos que es un entorno competitivo, que debe tener una buena experiencia de usuario para que el cliente vuelva comprar, etc. Vuelve a leer la exposición inicial ya que aquí muestro una lista de optimización de costes para este caso, no son todas y alguna podría sobrar, es para que enfoques lo que he contado anteriormente: • ¿Se desplegará en varias regiones (países o áreas)?, pues ten en cuenta el uso de regiones. • ¿Existen componentes que se han de usar entre regiones?, ten cuidado con los gastos de trafico. • ¿La aplicación necesita multi-factor para operar?, considera el uso de Azure AD. • ¿Debo pensar en un posible ataque continuo de DDoS o creo que no?, si vas a sufrir ataques continuos usa un recurso con la version estándar, por supuesto, te costará más. • ¿Qué debo implementar un borde de seguridad?, un Azure Firewall, un Azure Application Gateway o soluciones de tercero. • ¿Voy a crear más capacidad de venta?, pues piensa bien el escalado o simplemente controla las navidades o el Black Friday. • ¿Necesito ambientes diferentes de trabajo?, es decir, dev, test y producción. Ajusta los gastos en cada sitio, no es lo mismo poner un recurso barato en dev que en producción. • ¿Necesito una búsqueda inteligente en mi comercio?, busca una solución de terceros o usa Azure Cognitive Search, estima que necesitas e inclúyelo en tu plan.

Retorno de Inversión Coste de Optimización(4/5) • ¿Necesito IaaS o PaaS?, elegir una BBDD de SQL en IaaS con tu licencia es más recomendable económicamente hablando que un Azure SQL o quizá necesites procedimientos almacenados y debes ir a otro más caro. Ten en cuenta los requerimientos de la BBDD y estudia que pieza es la más conveniente. • ¿Tengo muchos archivos estáticos?, pues considera usar una CDN. • ¿Cómo voy a controlar los gatos?, usa Azure Cost Management. • ¿Queremos pasar a un modelo más automatizado?, integra DevOps por ejemplo para borrar entornos bajo demanda, esto ayuda a minimizar gastos, siempre es más eficiente un robot que un humano. • ¿Qué debo pensar en cuestión de backup?, revisa que has de incluir y que precios son los más adecuado, es un tema recurrente que debes revisar. • ¿Debo ser PCI?, Etc. Como puede observar es un trabajo tedioso, a modo de resumen podemos definir una estrategia que muestro en la siguiente página. Y aquí te dejo las herramientas que te ayudaran a optimizar costes en Azure: • TCO Calculator. • Azure Pricing Calculator. • Azure Cloud Cost Management. • Azure Advisor. • Y el uso de políticas de gobierno de Azure.

Retorno de Inversión Coste de Optimización(5/5) Control continuo Etiquetado de recursos. Facturas y alertas. Limites y cuotas. Políticas de Azure. Crea la estimación de costes inicial Azure Pricing Calculator. Azure Migrate. Azure TCO Calculator. Finaliza el modelo de costes Pago por consumo. Azure Hybrid Benefit. Azure reservations. Sport VMs. Dev/test Pricing. Recopilar requerimientos Alinearse con los objetivos de negocio. Cumplimiento. Seguridad. Alta disponibilidad. Recuperación ante desastres.

II Excelencia Operativa

¡Luz verde siempre! Excelencia Operativa(1/8) Cualquier aplicación se basa en codificarla, desplegarla y mantener el ciclo de vida de la misma. Implementar o migrar una aplicación a la nube es solo el principio, ya que lo más importante es que siempre este activa y trabaje de forma eficiente. ¿Cómo diseñamos la excelencia operativa? Con siguiente metodología: 1. Adoptando DevOps. Por tanto, adoptando un cambio de cultura, podéis leer más en: DevOps es Cultura. Podemos usar las métricas de DevOps DORA para medir de forma cuantitativa la madurez de su adopción de DevOps. • DF, deployment frecuency. Frecuencia de despliegue. Indica la frecuencia desde en la cual el codigo es liberado para que este en producción. • MLT, mean lead time for change. Tiempo medio que tarda el codigo desde que es liberado por un desarrollador hasta que llega a producción. • MTTR, mean time to recover. Como gestiona el tiempo de inactividad debido a interrupciones no planificadas. Un buen valor sería menos de 1 hora para sistemas grandes y críticos. • CFR, change failure rate. Indica el porcentaje de deployments a producción que pueden provocar inactividad o funcionalidades degradadas. Es decir, deploy que requieren una revisión o parches inmediatos. Como estandar general debería estar entre 0% y 15%, pero depende de los critico que sea tu sistema. Always On – Termino muy usado en recurso de Azure: ¡siempre encendido!

¡Luz verde siempre! Excelencia Operativa(2/8) 2. Optimiza las builds y reléase de los workloads. Es algo inherente a DevOps, pero quizá la IaC (infraestructura como codigo) no tanto. Inclúyela como proceso para que se pueda repetir con exactitud y simplificar el mantenimiento o documentación de la infraestructura subyacente. 3. Pon el foco en el seguimiento y mejora continua. Supervisa toda la infraestructura y la eficiencia de su construcción. El proceso de lanzamiento con una IaC es clave, puedes borrar un recurso inestable y en cuestión de segundos tener otro limpio y sin problemas. La telemetría nos permite retroalimentarnos y ofrece información valiosa para mejorar y garantizar la consistencia de un sistema. Así como previsiones a largo plazo. 4. Diseña aplicaciones poco acopladas. Es decir, intenta no usar mucho los monolitos y ve a arquitectas con microservicios, PaaS, FaaS, etc. Este enfoque ayuda en los deploys, pruebas e implementaciones, cosa que no pasa en los monolitos. 5. Aprende de los fallos e incidentes. A pesar de todos tus esfuerzos, los incidentes y fallos ocurrirán. Asegúrate y ten definido un plan para la gestión y respuesta. Un framework como ITIL puede ayudar.

¡Luz verde siempre! Excelencia Operativa(3/8) ¿Por donde empezamos? Logicamente por el diseño de la aplicación junto a un mecanismo de versiones y despliegues que pongan las funcionalidades lo antes posible al usuario. Esto se trata de: entorno de desarrollo, control del codigo, estrategia de ramificaciones, integración continua, gestión de pruebas y versiones, etc., seguro que me dejo muchos puntos más. El proceso debe definirse incluso antes de identificar el entorno de destino de nuestra implementación. El ciclo de vida y cada uno de los pasos deben estar muy bien definidos. Cada uno precisa de un buen analisis y una discusión detallada antes de tomar una decisión. Ten en cuenta que alguno también cambiará durante el ciclo de vida de la aplicación, el negocio evoluciona. Los principios de DevOps se aplican directa o indirectamente. Pero aquí dejo un resumen con los 5 puntos más importantes. Administración y control del codigo fuente Integración continua Estrategia de Testing Rendimiento de la release Despliegue y rollback

¡Luz verde siempre! Excelencia Operativa(4/8) 1. Administración y control del codigo fuente. • Traqueo, historia y modificación del codigo: Git, TFS, etc. • Almacenar el codigo en un sistema de administración: GitHub, Azure DevOps, GitLabs, … • Que tenga opciones para revertir a versiones anteriores. • Que tengas la opción de tener codigo en local tipo folks. • Que puedas enviar las copias via Pull Request para hacer el merge. • Que el software permita revisión de codigo. • Que pueda tener cosas como: boards de proyectos para implementar una metodologia Agile (si se puede y si no continua con tu waterfall), wikis, tracking, etc. 2. Integración continua. • Que el codigo se integre continuamente via Pull Request y te permita trabajar en paralelo con los colegas de trabajo. • Que tengas pipelines para poder ver la calidad de codigo cuando integras una rama o que lance test antes de integrar, que saque reports de todo esto. • Test continuo que pueda localizar cambios que rompen. • Capacidad de publicar reléase y poder documentar, para un posterior analisis.

¡Luz verde siempre! Excelencia Operativa(5/8) 3. Estrategia de Testing. • Automatizar los test al máximo nivel. • Crear test unitarios, que lleguen al 95% de la cobertura de codigo, el 100% me parece idílico. Revisión de sintaxis, code-smell, etc. Via herramientas como Sonar Cloud. • Test de integración. Smoke test. Test de aceptación. Test de stress y data recovery, para estudiar la resilencia, respuesta, etc. 4. Rendimiento de la releas. • Escoger los agentes de compilación adecuados: self-hosted o administrados por Azure DevOps. • Asegurarte que todos los componentes como NuGets, NPM, etc. Estan accesibles y bien configurados. • Escalado de servidores para poder albergar equipos crecientes de desarrolladores. • Ejecución en paralelo de Jobs, para no genera cuellos de botella o que los test de UI se lancen rápidamente. 5. Despliegue y Rollback. • Despliegue idempotente de la infraestructura y la aplicación. • Integrar la seguridad como codigo. • Escoger entornos de UAT, test, etc. Antes de salir a producción. • Elegir una estrategia blue-green, canary, etc. • Usar las características nativas del Cloud par hacer un rollback (por ejemplo, un swap).

¡Luz verde siempre! Excelencia Operativa(6/8) Adoptar el concepto: Todo como Codigo (Everything as Code) Para mi, la excelencia operativa, es lograr que todo se trate como codigo, es decir, no solo las fuentes de la aplicación, si no la infraestructura, seguridad, configuraciones, etc. Debe ser gestionado con un control de codigo fuente. Puedes seguir estas pautas para lograrlo: • Asegura la calidad de la IaC. Pon puntos de control y revisiones para actualizar y afinar la IaC. • Rompe lo silos entre el despliegue de infraestructura y las actualizaciones. Se trata de eliminar la dependencia, cualquiera puede desplegar. • Introduce integración continua con la seguridad en tu codigo. Esto implica que tendrás la seguridad desde el día 1 y no al final como suele pasar. • Te permite estar atento a las variaciones de IaC. • Lo mas importante: asegura la consistencia de los entornos. Puedes rehacer un entorno de desarrollo en cuestión e minutos o un entorno de producción para probar un error que solo sale en producción.

¡Luz verde siempre! Excelencia Operativa(7/8) Otros puntos que necesitan una atención especial: • Ajusta tu sistema a un rendimiento máximo. Nadie quiere sobrestimar y dejar recurso ocioso, generalmente es un gasto economico. Por tanto, estudia, redefine y focaliza esfuerzos en mantener el sistema lo más adecuado posible. • Usa el sistema “Shift Left” aplicado al Testing. Es decir, comenzando en desarrollo por Testing unitario y antes de producción revisar un test de rendimiento. • Monitorización. Medidas y más medias, que aseguran una mejora continua en tu ciclo de vida. Usa desde Azure Application Insight hasta Azure Monitor, pasando por Azure Logs y Security Center. Caso de Uso: Retail Repasa la propuesta de la primera sección. Y veamos como llegamos a esa excelencia operativa: • ¿Dónde piensa el cliente tener la solución?, nos ayuda para que los lags de las comunicaciones sean menores, también para cumplir con alguna ley propia como la GDPR en Alemania. • ¿Si necesito multi región?, la IaC debe contemplarla y con 1 definición cambiando los parámetros tenemos el mismo sistema… a veces no por qué en alguna región Azure no permite un tipo de VM, por ejemplo. • ¿Los requerimientos de escalado la Web App que aloja la tienda?, tenemos que proponer un escalado vertical (el facil) cuando lleguen las navidades. • ¿Qué diferencias existen en los entornos?, tener controlado que diferencias existen nos puede ayudar a adelantar problemas en Prod o arreglar algo que solo salen Prod y no vemos en dev.

¡Luz verde siempre! Excelencia Operativa(8/8) • ¿Cómo puedo implementar la monitorización desde el primer día?, pues añadiendo una app insight directamente en tu web app via IaC. • ¿Cómo se despliega la aplicación con Continuos Delivery o Deploy?, nos obliga a tener un buen sistema de QA y aseguramiento. • ¿Cuáles son las alarmas de problemas?, hablando con infra y dev, se ponen unos marcadores que serán los detonantes de problemas a detectar de forma proactiva. • ¿Cuál es el plan de rollback?, creamos un plan tanto para un despliegue fallido como para un problema de infra estropeada. Como veis, operaciones no se quedará ocioso, en momentos tempranos habremos metido poca cosa, iremos iterando y al llegar a producción tendremos un gran plan de operaciones. Lo que no tiene sentido es que antes, un mes o 4, por ejemplo, cuando esta apunto de salir a la luz la aplicación, comencemos a pensar en Operaciones. Esto se hace desde el minuto 0. Por desgracia la realidad en muchos proyectos es que arquitectos piensen que esto no es inherente al software, si no, un factor exógeno… y llegamos justos o mal para recopilar la información para generar un buen entorno de operaciones. Apuntalo bien: desde el minuto 0 debes pensar en operaciones.

III Eficiencia en el desempeño

Conoce los picos de demanda Eficiencia en el desempeño(1/14) Escalar hacia arriba o hacia abajo según cambia la demanda para cumplir con el desempeño de la aplicación, en un entorno cambiante es uno de los requisitos principales y uno de los detonantes del movimiento de una organización a la nube. Esto es un contraste en los entornos on-premise donde debe planificarse por adelantado y tener recursos ociosos hasta que llega ese pico. El sobre aprovisionamiento es un anti-patrón que debes evitar al llegar a la nube, estamos pensado en optimizar costes, por tanto, ¿cómo se logra un equilibrio entre demandas de rendimiento y optimización de costes?, pues en esta sección intentaré explorar los paradigmas para diseñar entorno que cumplan con un desempeño variable de demanda, mientras te aseguras que el presupuesto se mantiene en tu horquilla de gastos. ¿Cómo diseñamos la eficiencia operativa? El rendimiento de las aplicaciones se puede medir con tres métricas: rendimiento de las operaciones, latencia experimentada por los usuarios y disponibilidad de la aplicación. Tambien podrá existir SLOs (objetivos a nivel de servicio) que completarán esa medición. - La latencia, o tiempo que tardar el sistema en procesar solicitudes. - Rendimiento, o cantidad de solicitudes que puede gestionar en una unidad de tiempo. - Margen de error o percentil aceptable de excepciones. Scale up / Scale down – Según cambia la demanda

Conoce los picos de demanda Eficiencia en el desempeño(2/14) El diseño de tu entorno para mejorar la eficiencia puede basarse en los siguientes principios: 1. Identificar los parámetros de rendimiento correctos para los datos. • Nunca supongas en producción, siempre falla la suposición. • Reúne tantos requisitos de rendimiento de la aplicación como puedas. • Lanza aplicaciones de diagnostico y analisis de datos, tantas como puedas, recopila y prepara informes. 2. Cuando más lejos los antis-patrones de rendimiento mejor. • Es comprobado y re-comprobado, que lo que funciona on-premise, en Cloud no tiene por que ir bien. • Microsoft tiene una lista de anti-patrón relacionados con los datos (ver enlace), por ejemplo: - Demasiados hilos en segundo plano. - Varias solicitudes de I/O en vez 1 más grande. - Múltiples instancias de objetos y destruirlos tras usarlos, en vez de instanciar una vez y mantenerla. 3. Planifica la capacidad de rendimiento máximo mediante de pruebas. • Pruebas de carga. • Monitorización la aplicación durante el pico de rendimiento para ver el rendimiento durante el momento de escalado. • Identificar capacidades umbral de la aplicaicón, para activar el ajuste del escalado y gestionar los picos.

Conoce los picos de demanda Eficiencia en el desempeño(3/14) 4. Mantén un equilibro entre el rendimiento y los costes. • No compensen el rendimiento con un incremento del coste, equilibra el gasto. • Debes manejar muy bien el sistema de facturación de Azure y de los recursos implicados. Por ejemplo, un Storage Account tiene un medidor de I/O que es la tasa de transferencia que mucha gente se olvida, y es un factor de gasto muy importante. 5. Implementan la monitorización y mejora continua de la monitorización. • La gestión de la eficiencia del desempeño es un proceso que tiene lugar a lo largo de vida de la aplicación. • Esto no es negociable, ya que nos ayuda a identificar las partes relevantes de la aplicación, nos ayudará a focalizar los recursos en los puntos que realmente se usan de la aplicación. • Nos ayuda por tanto a reajustar los SKU y umbrales establecidos para el escalado.

Conoce los picos de demanda Eficiencia en el desempeño(4/14) Proceso Aplicación Datos Infraestructura Implementar Afinar Diseñar

Conoce los picos de demanda Eficiencia en el desempeño(5/14) Aplicación Escalabilidad • Diseña para que la aplicación escale • Adopta un enfoque tipo stateless • Escala todos los componentes que dependen entre si • Escala en momentos conocidos y define un autoescalado para picos no planificados. Cargas de trabajo • Descompone la arquitectura en partes más pequeñas • Que cada componente escale de forma independiente • Mira si los microservicios se adaptan a tus necesidades • Desacopla para reducir la dependencia Distribución de tareas • Las tareas intensivas que sean procesos independientes si no puedes hacerlas más pequeñas • Usa mecanismos como Jobs, tareas en background, serverless, etc. para bajar la intensidad de los procesos • Usa la computación distribuida para Jobs en background • Usa la misma filosofía para cargas de trabajo I/O intensivas Arquitectura Shared-Nothing • Evita un solo punto de entrada, es decir, evita usa shared-nothing (nada compartido) • Limita el uso de servicios compartidos, como por ejemplo en los storages • Mejora la escalabilidad y el rendimiento mediante la independencia de cada unidad de la aplicaicón

Conoce los picos de demanda Eficiencia en el desempeño(6/14) Datos Particionado • Escoge un tipo de datos adecuado para tu aplicación entre: tablas, colas, ficheros, etc. • Usa servicios que tengan particionados out-the-box • Elige servicios que tengan particionado horizontal, vertical o funcional en consonancia a los requerimientos de tu aplicación Consistencia • Usa la consistencia eventual siempre que sea posible • Procura el rendimiento máximo en las lecturas y ajusta las escrituras • La consistencia eventual evita el coste que supone sincronizar particiones Desnormalizar • Normalizar es importante, pero supone un gasto importante de computación y por tanto económico, además de latencia • La desnormalización como una prioridad permite lecturas mas rápidas • Ayuda a evitar complejas joins, pero como resultado duplicamos la información Cache & Optimizar • Incorpora cache estática, como CDNS, ficheros, datos de constante acceso, etc. • Identifica la estrategia de uso de la cache; privada, shared, client-side • Por ejemplo, en SQL, optimiza los procedimientos almacenados para mejorar el rendimiento de las consultas

Conoce los picos de demanda Eficiencia en el desempeño(7/14) Infraestructura Servicio de datos • Escoger la plataforma de datos adecuada entre Azure Blobs, Files. Queues, ... • Usa servicios de RDBS como Azure SQL, MySQL, etc. para una mayor consistencia • Usa NoSQL para datos que no precisen consistencia fuerte, pero demanden alto rendimiento Computación adecuada • Escoge entre VMS y diferentes SKUs sin sobrepasar lo necesario • Usa planes básicos para desarrollo y planes más caros para producción • Evalua la posibilidad de usar servicios serverless como Azure Functions para computación bajo demanda. Microservicios • Intenta adoptar arquitecturas de microservicios en vez de monolitos • Escoge bien la plataforma de orquestación, por ejemplo, AKS • Evalúa opciones como AKS para sistemas de producción de alto escalado Integración • Aprovecha los pools de conexiones para acceso a BBDD • Considera limitar el numero de conexiones concurrentes en VMs/App Services • Sopesa la entre seguridad y rendimiento

Conoce los picos de demanda Eficiencia en el desempeño(8/14) Aprovecha al máximo la escalabilidad de la nube La escalabilidad y rendimiento están estrechamente relacionados. Para aumentar el rendimiento bajo demanda, el diseño de su aplicación debe ser escalable. A medida que aumentan las unidades de computación, almacenamiento o red, el rendimiento debe aumentar proporcionalmente. En entorno dinámicos, el ajuste de escalado automático debe adaptarse para satisfacer las cambiantes demandas de rendimiento. Algunas consideraciones de diseño para escalar: 1. Ten en cuenta los requisitos de capacidad para el futuro. • Empieza con unas base-lines de cargas de trabajo, pero ten en cuenta el “a largo plazo”. • Comienza usando SKUs base. • Realiza pruebas de rendimiento para identificar los límites de capacidad. • Si estas en multi-región busca la capacidad y restricciones de cada una de ellas. 2. Elije entre escalar hacia arriba y hacia abajo. • Dependiendo de los objetivos tienes la opción de escalado vertical u horizontal, tanto ascendente como decreciente. • Ten en cuenta el tiempo que se toma en realizar estas acciones para tenerlo previsto en su aplicación.

Conoce los picos de demanda Eficiencia en el desempeño(9/14) 4. Determina la unidad de escalado. • Los componentes interdependientes a menudo escalan como una sola unidad. 5. Identifica métricas de autoescalado. • Debes tener activadores que aumenten o disminuyan según la situación de la demanda. • Establece un conjunto predefinido de métricas. • Realiza un uso intensivo de Azure Monitor, a que además de satisfacer la esperiencia de usuario, nos ayuda a mantener a ralla los gastos. Identifica cuellos de botella mediante pruebas de rendimiento Son aspectos no funcionales de la aplicación, pero que nos ayudan a saber los umbrales de respuesta de nuestra aplicación, entre otras cosas ayudan a que la aplicación garantice que no se verá interrumpido su servicio. Puedes usar herramientas como Jmeter, OpenSTA, LoadRunner, WebLOAD, etc.

Conoce los picos de demanda Eficiencia en el desempeño(10/14) Este pequeño plan puede ayudarte con los aspectos fundamentales a tener en cuenta cuando se planifican test de rendimiento. Responsabilidad del equipo Mantener un entorno aislado que simule producción Implicar a todos los roles: devs, DBAs, network admins, etc. Escoger un test adecuado Identifica que tipo de test de rendimiento necesitas: load, stress, etc. Shift left de las pruebas de rendimiento (no lo dejes para el final) Test de carga anticipado Define la capacidad máxima con test de stress Lanza test de spikes aleatoriamente Lanza test de rendimiento durante un error Optimizar el entorno Configura scale out-in Metricas base y escalamiento anticipado

Conoce los picos de demanda Eficiencia en el desempeño(11/14) Algunas consideraciones más: • Asegúrate que el equipo este alineado con los objetivos de Testing y que tengan el entorno de prueba preparado. • Según los definidos en DevOps, no hay separación de roles. Junto con el equipo de control de calidad, los desarrolladores, arquitectos e infraestructura tienen el papel de ejecutar las pruebas para que tengan éxito. • Asegura la cobertura de prueba para todos los elementos de la aplicación, desde el software hasta la IaC. • Comienza desde el inicio temprano de la aplicación con las pruebas y no antes de la implementación a producción. Decenas de veces me he visto involucrado en esta situación y la esperiencia dicta que el enfoque debe ser shift-left, iniciar las pruebas de rendimiento desde una etapa temprana del ciclo de vida de la aplicaicón permitirá identificar problemas y subsanarlos cuando aun son menos dolorosos o directamente cuando tienen solución. • Integra herramientas en los procesos de DevOps: JMeter, K6 y Selemiun, por ejemplo. Y a continuación un poco más de información con respecto a los test básicos que debería tener tu aplicación: Test de Carga • Testea la carga normal y pesada • Intenta ver que ocurre cuando excedes la capacidad de Azure • Metricas baseline para observar y monitorizar • Lanza los test en diferentes etapas del escalado para afinar los recursos Test de Stress • Sobrecarga la máxima capacidad soportada por la aplicación • Configura el autoescalado y observa el comportamiento • Reduce los recursos y prueba que ocurre en esos escenarios (un Chaos Testing) • Establece los limites de los SKUs que se alinean con los requerimientos Test Multiregión • Mide el trafico enrutado a regiones secundarias • Ejecuta casos de test para acciones planificadas y no planificadas • Mide el downtime o impacto de rendimiento durante los fallos • Testea todos los recursos desplegadados en todas las regiones

Conoce los picos de demanda Eficiencia en el desempeño(12/14) Monitoriza métricas Debe cubrir atributos que permita la escalabilidad y confianza, junto a los atributos que nos permitan realizar interpretaciones por correlación: • Aprovecha las Metricas multidimensionales de Azure Monitor, ayudan a dar un contexto adiciona los datos. • Cruza datos de diferentes fuentes, ayuda a contextualizar más la información, usa Application Insight. En resumen, estas fuentes permiten una visión holística de la aplicación. • Instrumenta la aplicación con herramientas tipo Application Insight cuando detectes cuellos de botella, la información adicional que puedas emitir ayudará a identificar el problema a nivel transaccional. • Junto a la monitorización de Application Insight, los demás recursos deberían tener habilitados los diagnósticos de las herramientas de análisis. • Define el estado saludable y no saludable de los componentes e incluye acciones que te permitan maniobrar, así como cuadernos de operaciones. • Usa el mapa de la aplicaicón que nos da Application Insight para identificar y estudiar el comportamiento de la aplicaicón. Esa herramienta de investigación ayuda a profundizar en el problema.

Conoce los picos de demanda Eficiencia en el desempeño(13/14) Caso de Uso: Retail Repasa la propuesta de la primera sección. Y veamos como llegamos tenemos eficiencia en el desempeño: https://docs.microsoft.com/es-es/azure/architecture/example-scenario/apps/ecommerce-scenario

Conoce los picos de demanda Eficiencia en el desempeño(14/14) Caso de Uso: Retail Repasa la propuesta de la primera sección. Y veamos como llegamos tenemos eficiencia en el desempeño: • ¿Dónde desplegará la solución?. Asegura la proximidad geográfica. • ¿Se necesita multirregión?. Identifica donde debe estar activa y donde debe estar pasiva ayudado de una herramienta de enrutamiento para eventualidades, como puede ser un traffic router. • ¿Tienes definido los objetivos?. Mide el rendimiento y los atributos que se deben cumplir. • ¿Qué necesidades de escalado tienes?. En un Retail claramente tienes las fiestas o campañas publicitarias. • ¿Un CDN mejora la experiencia de usuario?. Si tienes mucho contenido estático, un Retail, lo tiene, debes considerar su uso. • ¿En el backend te podrá venir bien un pago por uso?. Evalúalo, quizá te ahorres tener que tener reglas de escalado, pero en contra los gastos pueden fluctuar. • ¿Cuellos de botella?. Identifica si es preciso hacer muchas llamadas a bases de datos y el backend lo soporta, comienza con Metricas y observación con Application Insight, el futuro de tu Retail es en la retención de usuarios y compras recurrentes. • ¿Has lanzado test de carga?, comprueba que los SKUs de tus recursos cumplen las expectativas y sobre todo reevalúa continuamente. • ¿Cómo se comporta ante una degradación del servicio? Te quedas sin respuesta, tarda, enrutas, mira que haces y busca estrategias. Anticipa el problema.

IV Fiabilidad

Aplicaciones resilientes Fiabilidad(1/11) El enfoque práctico para garantizar resilencia en la nube es asumir que se producirán fallo y se deben planificar durante la fase de diseño. Muchos servicios de Azure tienen redundancia out-the-box. La redundancia si compromete otros pilares como la optimización de costes y excelencia operativa, no cumple su cometido. Adoptar una estrategia correcta que cumpla tus SLA (no confundir con las que nos dan los recursos de Azure, me refiero a las de tu aplicaicón, las que tu has definido) debe ser tu enfoque principal. Veamos como podemos construir aplicaciones resilientes y de alta disponibilidad en Azure. ¿Cómo diseñamos para ser resilientes? Agregar instancias como recurso para garantizar la resiliencia no es el enfoque. Debes asegurar que desde el día 1la aplicación cuente con los principios que vamos a enumerar. 1. Cuantifica los objetivos de disponibilidad. • No deben ser definiciones abstractas. Cuantifica usando SLA y SLO. • Los problemas ocurrirán, define un tiempo aceptable de inactividad, es decir el RPO (punto de recuperación) y el RTO (objetivo de tiempo de recuperación). • Ten en cuenta que habrá sanciones económicas por no cumplir el SLA y SLO (perdidas de clientes sería una de ellas si tienes un Retail, devolver dinero es lo que hace Azure cuando no cumple). Resilencia – Capacidad de recuperar su estado inicial ante una perturbación

Aplicaciones resilientes Fiabilidad(2/11) 2. Garantiza la confiabilidad en el desempeño. • Capitulo anteriormente tratado. Tratamos la escalabilidad, picos, etc. Para mantener el rendimiento optimo de la aplicación bajo el mayor abanico de circunstancias. 3. Garantiza la aplicación, datos e infraestructura. • Es obvio, pero recuerdo que no solo es la infra y la aplicación, se debe garantizar la conectividad, los datos, etc. Todos impactan en la experiencia de usuario. 4. Gestiona los riesgos de seguridad aplicados a la resilencia. • Se proactivo y aborda vulnerabilidades que puedan dejar el sistema inoperativo, así como el tiempo que necesitas para levantarlo. Un ataque de DDoS o un ransomware. 5. Gestiona un ciclo de vida altamente automatizado. • Capitulo anterior, pero configura todo lo que sea automatizable y que no deba intervenir un humano. Por supuesto esto también debe ser testeado.

Aplicaciones resilientes Fiabilidad(3/11) 6. Diseña una aplicaicón que se recupere de los fallos. • Implementa mecanismos de recuperación. Debes estar alineado con el SLA/SLO y RPO/RTO. Debes tener en cuenta que debería recuperarse de fallos en componentes, así como casos catastróficos (que se queme el centro de datos). A tipos diferentes de desastres deberás definir tiempos de recuperación acorde, no es lo mismo que un nodo se degrade y regenerarlo con IaC en 5 minutos, que se queme la región y debas ir a otra. 7. Implementan monitorización y mejora continua. • Ya hemos hablado de ello en varias ocasiones, incluso tengo un documento muy extenso sobre monitorización y observabilidad de aplicaciones Cloud Native. Estrategias más comunes para cumplir con los SLAs definidos Establece un objetivo de disponibilidad y recuperación, este será tu ancla, tu punto de partida. Hay dos aspectos principales que debes tener en cuenta: – Creación de aplicaciones resistentes que se puedan recuperar ante fallos. – Alta disponibilidad de todos los componentes de la aplicaicón para atender a todos los usuarios.

Aplicaciones resilientes Fiabilidad(4/11) Todo esto tiene un costo, por tanto, busca donde deben cumplir los SLAs y los SLO. Por ejemplo, el entorno de desarrollo no tiene por qué cumplirlos, sin embargo, producción sí. Consideraciones a la hora de definir un SLA de aplicaciones Los acuerdos de nivel de servicio definen los niveles aceptables de rendimiento y disponibilidad para una aplicación. Cuando se trata de sistemas complejos y distribuidos, habrá varias partes o recursos que contribuirán más a la robustez. – Asigna la dependencia SLA de la aplicación con todos los componentes y calcula el SLA compuesto. – Habilita la monitorización para medir el tiempo medio entre fallos (MTBF). Ayuda a ver si hemos cumplido con el SLA. – Define objetivos de disponibilidad cuando, por ejemplo, conmutes entre servicios de distintas regiones. – Define que es “fallo” en el plan de acción. Quizá solo necesites una instancia más ya que es una degradación y no un “fallo”. FMA El FMA (Failure Mode Analysis) ayuda a identificar los eslabones débiles. Adopta una estrategia shift-left para FMA. FMA tiene una serie de definiciones que deberías conocer:

Aplicaciones resilientes Fiabilidad(5/11) – Fault Point. Componentes de la aplicación que podrían fallar y afectar a la disponibilidad. – Fault Mode. Describre las diferentes posibilidades de fallo para el Fault Point. – Single Point of Failure. Componente que puede tirar a bajo la aplicación si falla. A continuación, los pasos de un proceso FMA: Y una pequeña lista de lo que debes ir considerando por cada recurso: Identificar un Fault Point • Identificar componentes que podrían fallar • Revisa dependencias Identificar un Fault Mode • Identifica las formas en las que podría fallar • Considera que los fallos podrán suceder de forma independiente Ratio de Riesgo • Probabilidad de fallo. Establece alto, medio y bajo • Cuantifica el impacto del fallo Crear un plan de recuperación • Plan de recuperación para cada punto • Ten en cuenta complejidad y costes

Aplicaciones resilientes Fiabilidad(6/11) Fault Point Fault Mode Recovery Plan App Service En inactividad se pone Idle Pon “Always On” en las settings del recurso Un operador baja el sistema Pon read only para ese grupo de operadores Miles de bad request por un usuario Bloque el usuario con APIM y estudiar el caso Cosmos DB Errores en escritura de datos 1) Reintentos de escritura 2) Incrementa el rendimiento de la colección 3) Replicación multiregión Azure VM VM error de conexión 1) Al menos pon 2 VMs en una zona/set tras un load balancer 2) Implementa un circuit breaker Azure Storages Errores de lectura 1) Configura reintentos 2) Usa RA-GRS Las acciones y los casos son muchísimos, espero que con esta pequeña tabla puedas hacerte a la idea del funcionamiento de un FMA.

Aplicaciones resilientes Fiabilidad(7/11) Estrategias de adopción Es insistir sobre el tema y me reitero. La confiabilidad de una aplicación es la suma de las fiabilidades de todas las partes. • Resilencia regional. Que los componentes estén en distintas regiones dentro de una zona o en varias regiones, aumenta la fiabilidad e incrementa el coste, y aquí es donde el cliente debe ver que no duplicamos, si no que invertimos en el negocio. • Gestión de fallos. Define que componentes debemos proteger a toda costa y cuales son efímeros, aquellos que podemos regenerar sin implicar perdida de fiabilidad. • Gestión de dependencias. Se refiere a la gestión tanto interna como externa de los componentes e incluso terceros. Debes evaluar por ejemplo si es posible que la aplicaicón sea capad de vivir en ausencia de un componente y documentarlo. Testeo de la aplicación Cualquier cambio, actualización o re-arquitecturización debe pasar un riguroso plan de pruebas. Existen diferentes tipos de pruebas.

Aplicaciones resilientes Fiabilidad(8/11) El porqué, para qué y cómo de las pruebas es imporante para garantizar la resilencia del sistema: • Comienza con un plan de pruebas definido que cubra todos los modos y punto de fallo. • Define una estrategia de recuperación ante desastres. Ejecuta aplicaciones con la mínima funcionalidad para ver como se gestionan el resto de las interrupciones. • Automatiza los pasos de conmutación por error y conmutación para recuperación, para reducir el tiempo de respuesta. • Que las pruebas se ajusten a los requisitos, obviamente. • Prueba periódicamente para medir umbrales y objetivos. • Crear entornos dedicados a pruebas, simulando lo más cerca la producción. Tambien puedes ejecutar subconjuntos de pruebas en producción en un ambiente controlado. Una aproximación interesante es la Ingeniera del Caos, que inyecta fallos en el sistema para luego monitorizar el impacto y así medir la resilencia de la aplicación. Esto va desde bajar nodos de una VM hasta restricciones de acceso, pasando por SKUs de baja respuesta en una base de datos. Otras son las pruebas de carga máxima, que nos indica hasta donde llega y es consistente la aplicación. Nos ayuda a ver como se comportan los componentes con picos efectivos de carga o cargas continuas, donde activan el escalado. Pruebas de backup y RD (recuperación ante desastres). Deben ser pruebas periódicas y verificar que los datos son correctos. Puedes llevarte más de una sorpresa: que el sistema de backup este parado, que los datos se borren por algun operador con derechos, etc.

Aplicaciones resilientes Fiabilidad(9/11) Monitorización y optimización Ayudan a dar visibilidad en tiempo real de la aplicación, a identificar incidentes que podrían afectar a la resilencia general, a ser proactivo, etc. Seguro que ya he tratado todo esto antes, pero aquí dejo un resumen de pautas para garantizar la resilencia mientras monitoriza: • Revisa si algun componente cruza el umbral o puede estar apunto de cruzar el umbral de SLA, y crea reglas de escalado. • Instrumentaliza la aplicación para detectar fallos. No dejes de observar las dependencias. • Ya hemos hablado de Application Insight, úsalo junto a Log Analytics. Aprovecha las recomendaciones de Azure Monitor. • Configura alertas basadas en Metricas y que le lleguen al equipo de operaciones. Si puedes automatiza las correcciones con runbooks o webhooks o Functions. No olvides de incluir alertas sobre degradaciones de SLA de Azure. • Configura umbrales para evitar falsos positivos, continuamente deberás hacerlo. • Configura paneles de ofrezcan una visión panorámica del estado de la aplicación adecuados al tipo de operador, que van desde alto nivel hasta el más bajo.

Aplicaciones resilientes Fiabilidad(10/11) Caso de Uso: Financiero Repasa la propuesta de la primera sección. Y veamos como dar fiabilidad para un sistema financiero: https://docs.microsoft.com/es-es/azure/architecture/example-scenario/multi-saas/multitenant-saas

Aplicaciones resilientes Fiabilidad(11/11) • ¿Has configurado Metricas de monitorización para disponibilidad?, sondea el estado de la aplicaicón y crea alertas ante un posible downtime. • ¿Cómo se gestiona las redundancias entre capas?, habilita replicación de datos en todas las regiones garantiza la coherencia de los datos y prioriza realizar operaciones de lecturas. • ¿Has incorporado escalabilidad en los componentes de la aplicación?, ejecuta simulaciones para estudiar el escalado de tus reglas en picos. • ¿Has definido la estrategia y cadencia de pruebas?, asegúrate de haber seguido el principio shift-lef • ¿Cómo tiene en cuenta la disponibilidad la logica de la aplicación?, incorpora métodos para gestionar errores, configura tiempos de espera entre componentes y habilitar instrumentación de aplicación. • ¿Cuáles son los servicios cruciales de la aplicación?, seleccionar los componentes AKS y Azure SQL con alta disponibilidad incorporada ayuda a gestionar este punto. • ¿Cómo se gestiona la disponibilidad en todas las regiones?, un Azure Front Door ayudará a redirigir el trafico a una región secundaría en caso de problemas.

V Seguridad

Tu nuevo mantra Seguridad(1/11) En la nube, los vectores de amenazas son mucho más avanzados por lo que su estrategia de seguridad también debe serlo. Como bien sabemos todos, las brechas de seguridad horadan la confianza con el cliente, y los ingresos. Por eso, la seguridad es un aspecto que NO SE NEGOCIA en cualquier arquitectura de una aplicación. Vamos a ver aspectos prácticos que garanticen un mínimo de seguridad. ¿Cuáles son esos vectores de amenazas en la nube? Es un tema del cual no soy experto, pero algo se. Si lo ves básico eso es bueno, ya que significa que este es un campo al que prestas atención y si es nuevo o te aporto algo, me alegra saber que he aportado un grano de área a tus conocimientos. La cuestión principal es que se trata de una responsabilidad compartida entre la plataforma de Microsoft y el usuario. No es lo mismo tratar un IaaS (que si dejas sin actualizar una VM, el problema es tuyo) que un SaaS (donde es Microsoft quien nos da la capa de protección principal). Los vectores de amenazas evolucionan constantemente y los expertos en seguridad siempre están un paso por detrás de las amenazas. Paradigmas diferentes – La seguridad en la nube es diferente a la tradicional

Tu nuevo mantra Seguridad(2/11) Antes de nada, apunta https://www.microsoft.com/es-es/security/business y ve a recursos para estar informado con blogs, eventos, etc. Como resumen, muy básico, los delincuentes tienen muchas formas de intentar acceder a tus aplicaciones en Azure: • Lo más básico es proteger el perímetro, presta atención a reglas mal definidas en Firewall, NVA, NGS que actúan como reclamo para la entrada de ataques. • Cuidado con el malware, por ejemplo, los troyanos para hacerse con credenciales o propagación de ransomware, etc. • Violaciones de identidad. Hoy en día es un nuevo perímetro de seguridad, ya que esta siendo el principal punto de entrada de un ciberataque. • Robo de datos. Los datos están protegidos en Azure de forma predeterminada mediante cifrado, pero si las claves no lo están, podrán llegar a ellos. • Vulnerabilidades conocidas. Si localizan que tienes una versión obsoleta de SQL pueden aprovechar cualquier documentación en internet que explica como atacar por esa puerta obsoleta. • Desviaciones de seguridad. Es decir, que, aunque sigas las mejores prácticas es normal que alguna vez tomes un atajo y accidentalmente dejes puertas abiertas por no se exhaustivo.

Tu nuevo mantra Seguridad(3/11) La seguridad debe adaptase a las nuevas amenazas Antes de hacer nada, piensa en el modelo de seguridad de tu aplicación de Azure:

Tu nuevo mantra Seguridad(4/11) Con este cuadro y los recurso que dispones, te orientarás a una aquitectura serverless o una IaaS, por ejemplo. Si no tengo suficiente personal de infraestructura y no saben casi nada de seguridad, vamos a intentar desarrollar con SaaS. Ese modelo de responsabilidad compartida proporciona claramente que vas a necesitar en con cada recurso. Téngalo muy presente. Criterios de diseño Microsoft recomienda una estrategia de seguridad en profundidad para garantizar de extremo a extremo la seguridad en sus workloads. Generalmente debes pensar como romper la seguridad y crear una capa de protección. A su vez debes probar las capas inferiores, es decir, en cada capa debes pensar como romperla y protegerla. Los tres pilares del esfuerzo en seguridad son: • Confidencialidad, asegúrate que el personal autorizado tenga acceso a los datos y aplicaciones manteniendo al mínimo los privilegios. • Integridad: los datos que se transfieren deben ser a prueba de manipulaciones para que no se comprometa la integridad en el transito. • Disponibilidad: además de los fallos de la aplicación debes prevenir ataques tipo DDoS que puede afectar a la disponibilidad. Por tanto debes prevenir este tipo de eventualidades de disponibilidad.

Tu nuevo mantra Seguridad(5/11) Interioriza los aspectos antes tratados, la llamada Triada CIA. Tambien debes conocer las capas de seguridad del modelo OSI: https://en.wikipedia.org/wiki/OSI_model Seguridad física Identidad y Acceso Perímetro Red Computo Aplicación Datos

Tu nuevo mantra Seguridad(6/11) Para habilitar el pilar de seguridad en WAF, puede seguir estas pautas: Anillo Descripción Principio Datos Proteger datos o en SaaS establecer mecanismo de seguridad propios al SaaS Integridad Aplicación Establece seguridad en el codigo desde el minuto 1, evitando rastreado de credenciales, por ejemplo Integridad Computo Proteger VM de vulnerabilidad, proteger red, endpoints, etc. Disponibilidad e Integridad Red Segmentación de trafico, restringir el trafico, … Confidencialidad e Integridad Perímetro Establece protección para DDoS, firewall, usa NVAs para prevenir brechas de seguridad, etc. Disponibilidad Identidad y acceso Protger mediante RBAC, multifactor, … Integridad Seguridad física Primera linea de defensa, implementada directamente por Microsoft en los datacenter físicos: control de personas, monitorización, etc. Confidencialidad

Tu nuevo mantra Seguridad(7/11) 1. Define una estrategia de seguridad • Personas, procesos y tecnología deberían ir juntos, es decir abarca los 3. • Desarrolla una cultura de seguridad en tu organización. 2. Diseña desde una perspectiva de un atacante • Deberías anticiparte a los ataques, al menos, a lo más conocido, como decía antes los ciberdelincuentes están siempre unos pasos por delante… pero no se lo pongamos facil. • Realiza muchas simulaciones y pon a prueba tu aplicación. 3. Aprovecha herramientas de configuración y las opciones nativas • Busca las herramientas que te ayuden como puede ser Azure Sentinel, AAD, etc. 4. Integra la resilencia en la estrategia de seguridad • Sobre los problemas de fallos o controles de la aplicaicón implementa una estrategia de seguridad. • Esto esta alineado con la practica de defense-in-Depth.

Tu nuevo mantra Seguridad(8/11) 5. Confianza 0 • No debe haber ningun acceso incondicional a cualquiera de los recursos. • Usa tokens, multifactor, privilegios al mimo, etc. • Cualquier problema de credenciales filtradas, etc. Debería ser atacado directamente con un plan que permita invalidar los valores filtrados. 6. Monitorizar y optimizar • En WAF es un proceso habitual, aquí ocurre lo mismo. Es una mejora continua. • Evolución a traves del aprendizaje y del conocimiento. • Simula para fortalecer la seguridad. Y aprovecha los recursos nativos de Azure: como Security Center, Monitor, Sentinel, etc. Que te ayudaran a detectar vulnerabilidades Seguridad en la infra estructura, los datos, la red y la aplicación La infraestructura es la base de todas tus implementaciones en la nube. Alinear los procesos, las herramientas y las estrategias de seguridad correctos es imporante para fortalecer esta base.

Tu nuevo mantra Seguridad(9/11) Segmentación de la infraestructura Estrategia alineada con negocio Administración de grupos Asignar roles y políticas Acceso administrativo con cuentas separadas Seguridad de red Perímetro Conexiones seguras Endpoint seguros Protección del trafico de datos Protección de datos Encriptación Azure RBAC Transferencia de datos Información sensible Aplicación Integración SDL (Secure Development Lifecycle) Seguridad operacional Protección de datos Administración de secretos

Tu nuevo mantra Seguridad(10/11) La identidad es el nuevo perímetro de seguridad A raíz del uso de la nube es cuando este nuevo perímetro aparece. En realidad, surge con el desarrollo de aplicaciones móviles. En resumen y por no extenderme, es el eslabón débil de la cadena, por eso aparecen cosa como el doble factor. Los atacantes saben que el robo de credenciales una forma limpia de acceder a sistemas sin ser detectados y es por eso que Microsoft gracias a Azure Sentinel es capada de darnos funcionalidades como el bloqueo de IPs via IA si sabe que el usuario siempre accede en una ciudad X y de repente aparece simultáneamente en la ciudad Y. Sin estas herramientas sería muy complejo para los roles de seguridad identificar este tipo de ataques o si los identifican serían tarde. Herramientas nativas de Azure para tu equipo SOC Nada que no comentara antes. Aprovecha todo lo que Azure te da: • Security Center. • Azure Sentinel. • Azure Defender.

Tu nuevo mantra Seguridad(11/11) Caso de Uso: Financiero • ¿Esta activado el doble factor para la aplicación? O bien lo implementas tu con SMS o bien si es interno alinealo con AAD y una cuenta al autenticador del telf. Movil. • ¿Los datos del API Rest están protegidos? Usa urls seguras y usan key vaul para las keys de los endpoints. • ¿El storage es de escritura? Pues no dejes una clave admi, modula el nivel de acceso. • ¿Se ven las keys en los ficheros de configuración? Usa un mecanismo como Azure KeyVaul para no ver ese valor en los deploys. • ¿Tu organización tiene alertas rojas con ciertas IPs? Pues filtar ese contenido con Security Center. • ¿Tienes activado RBAC en tus recursos? Es buena opción usar los grupos y usuarios para evitar problemas, • Podríamos estar escribiendo cientos de líneas cuando se trata de un uso financiero por que además es muy posible que se integre con terceros a la hora de comprar y aquí entra el ciclo de PCI del tercero y los datos que tienes en Azure.

¡Gracias! Puedes encontrarme buscando por jmfloreszazo en https://jmfloreszazo.com