Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Un vistazo de cerca Azure Well-Architected Framework

Un vistazo de cerca Azure Well-Architected Framework

El marco de buenas practicas para Azure, es también extensible para otras nubes. En ellos vemos una guía de principios que ayudan a mejorar la calidad de un Workload en Azure. El marco consta de 5 pilares fundamentales que veremos ampliamente desarrollados en un documento PDF que podrá ayudarte a profundizar en el tema.

Como podrás observar en el enlace ofician de Microsoft ya lo tienen muy bien desarrollado en español. Pero cuando yo me puse hacerlo solo existía la versión en ingles y no por ello deja de ser útil.

En el doy una visión desde la esperiencia en este tipo de proyectos.

Espero que os sea de utilidad.

Jose María Flores Zazo

October 15, 2021
Tweet

More Decks by Jose María Flores Zazo

Other Decks in Technology

Transcript

  1. Un vistazo de cerca:
    Azure Well-Architected Framework

    View full-size slide

  2. 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

    View full-size slide

  3. 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

    View full-size slide

  4. ¿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)

    View full-size slide

  5. ¿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.

    View full-size slide

  6. ¿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.

    View full-size slide

  7. ¿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.

    View full-size slide

  8. ¿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.

    View full-size slide

  9. ¿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

    View full-size slide

  10. 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

    View full-size slide

  11. 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.

    View full-size slide

  12. I
    Coste de Optimización

    View full-size slide

  13. 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

    View full-size slide

  14. 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.

    View full-size slide

  15. 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.

    View full-size slide

  16. 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.

    View full-size slide

  17. 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.

    View full-size slide

  18. II
    Excelencia Operativa

    View full-size slide

  19. ¡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!

    View full-size slide

  20. ¡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.

    View full-size slide

  21. ¡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

    View full-size slide

  22. ¡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.

    View full-size slide

  23. ¡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).

    View full-size slide

  24. ¡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.

    View full-size slide

  25. ¡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.

    View full-size slide

  26. ¡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.

    View full-size slide

  27. III
    Eficiencia en el
    desempeño

    View full-size slide

  28. 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

    View full-size slide

  29. 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.

    View full-size slide

  30. 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.

    View full-size slide

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

    View full-size slide

  32. 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

    View full-size slide

  33. 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

    View full-size slide

  34. 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

    View full-size slide

  35. 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.

    View full-size slide

  36. 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.

    View full-size slide

  37. 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

    View full-size slide

  38. 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

    View full-size slide

  39. 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.

    View full-size slide

  40. 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

    View full-size slide

  41. 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.

    View full-size slide

  42. IV
    Fiabilidad

    View full-size slide

  43. 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

    View full-size slide

  44. 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.

    View full-size slide

  45. 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.

    View full-size slide

  46. 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:

    View full-size slide

  47. 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

    View full-size slide

  48. 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.

    View full-size slide

  49. 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.

    View full-size slide

  50. 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.

    View full-size slide

  51. 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.

    View full-size slide

  52. 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

    View full-size slide

  53. 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.

    View full-size slide

  54. 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

    View full-size slide

  55. 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.

    View full-size slide

  56. 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:

    View full-size slide

  57. 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.

    View full-size slide

  58. 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

    View full-size slide

  59. 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

    View full-size slide

  60. 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.

    View full-size slide

  61. 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.

    View full-size slide

  62. 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

    View full-size slide

  63. 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.

    View full-size slide

  64. 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.

    View full-size slide

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

    View full-size slide