Un vistazo de cerca Azure Well-Architected Framework

Un vistazo de cerca:
Azure Well-Architected Framework

View Slide

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 Slide

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 Slide

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

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

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

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

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

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

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 Slide

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 Slide

I
Coste de Optimización

View Slide

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 Slide

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 Slide

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 Slide

• ¿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 Slide

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 Slide

II
Excelencia Operativa

View Slide

¡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 Slide

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 Slide

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

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 Slide

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 Slide

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 Slide

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 Slide

• ¿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 Slide

III
Eficiencia en el
desempeño

View Slide

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 Slide

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 Slide

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 Slide

Proceso
Aplicación
Datos
Infraestructura
Implementar Afinar
Diseñar

View Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

IV
Fiabilidad

View Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

V
Seguridad

View Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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

View Slide

Un vistazo de cerca Azure Well-Architected Framework

Un vistazo de cerca Azure Well-Architected Framework

Jose María Flores Zazo

More Decks by Jose María Flores Zazo

Other Decks in Technology

Featured

Transcript