Azure cloud patterns and architecture

Editor's Notes

• #4: 1. Muchos servicios para lo mismo.
• #6: No precisamos una VM, ni pensar en parches ni temas de infraestructura. Puedo ejecutar distintas tecnologías. Escalar de manera horizontal. Equilibro de carga Reglas de escalado Depuración remota Logs Limitar acceso a blog y aplicar politicas de seguridad Contenido estatico No preciso actualizar sql, no me preocupo por el OS Automatizador para crear un grupo lógico Crear plantillas de los grupos logicos para realizar despliegues automaticos entre diferentes entornos Autenticar usuarios de manera local Almacenar en base de datos locales.
• #10: MULTI REGION DEPLOYMENT Segundo despligue en una región de otro continente. Podemos configurar el Traffic manager Enrute a la instancia con menos latencia. Enrute por cercanía geográfica Enrute a la instancia activa (seteamos una como default) Podemos chequear la salud de nuestra aplicación Se le configura la ip publica la traffic manager y el se encarga de enrutar los request Replicacion de datos por región Azure sql envía solicitudes a la base primaria, en caso de que esta falle podemos redirigir los request a la base de replica
• #12: API GETWAY . Escenario donde exponemos una api a nuestros clientes . Precisamos un portal donde exponer toda la info de nuestra api . Precisamos limitar acceso . Facturar por grupos Ofrecer planes de acceso a nuestra api
• #14: MOBILE APPLICATION Requisitos: Trabajar sin conexión Ofrece un SDK para trabajar sin conexión Utiliza un sql lite local Precisamos enviar notificaciones a otros usarios Trabaja con apple y Google notifications
• #16: MicroServices Un cliente mobile conectado, o cliente web, o millones de IOT conectados o un juego Pensado para aplicaciones distribuidas, pensado para aplicaciones confiables y altamente escalables Podemos configurar un cluster, con una o miles de VM Podemos configurar app services, con servicios que esten en nuestro datacenter Pensado para aplicaciones con gran demanda de request, y con necesidad de escalar Sistemas en tiempo real
• #18: IOT Prodriamos utilizar un app service Servicio especializado Event Hub Optimizado para millones de dispositivos por segundo Maneja diferentes protocolos además de HHTP, MQTT, AMQP  Puedo transformalos y almacenarlos en servicios especializados Servicio especializado para IOT, comunicación bidireccional, - Puede enviar mensaje a los dispositivos (soporta AMQP) Advanced Message Queuing Protocol Sream procesamiento en tiempo real Tener información sobre datos en tiempo real del comportamietno de nuestros dispositivos, como si se esta moviendo muy rápido o cosas de ese estilo Podemos tranformar los datos en un Data Lake Podemos alimentar otras herramientas como Haddop o Ml, para analizar datos ML podemos exponer algoritmos complejos a la web, y consumirlos desde otras app Podemos almacenar datos en SQL, para procesamiento de grandes volumens de información de manera paralela
• #20: Availability set: asegura que no todas las pc esten fuera de linea al mismo tiempo Actualizaciones, parches, o problemas Evitar problemas de red Configurar cuantas maquinas queremos que esten fuera de linea al mismo tiempo como máximo Virtual Network. Administrar entrada y salida de red. Conectar distintos maquinas en una red cerrada Inspeccionar trafico Puedo tener varias sub redes Puedo obligar las comunicaciones de red, mediante un balanceador Puedo tener mi negocio conectado a una VM con una Base De Datos JumpBox, administrar las tareas administrativas externas. Se conectan mediante jumpBox
• #21: Fallas: ataques, desconexión de red, desastre naturales, problemas de hardware, mantenimiento. Redundancia
• #22: Blob Storage Redundancia Local Geo Redundancia: Copia async VM Grupos de disponibilidad No comparten mismos cable de red ni mismo cable de electricidad Dominio de actualización SQL Geo replicación Hasta 4 bases de datos en el mismo centro de datos App Service Tenemos mas de una instancia arriba, la cual van a atender las cargas, en caso de que una se caiga
• #23: Muchos patrones para atacar los problemas de fallas de conexión Problemas generados por red saturada, conexión lenta, caída de conexión Si llamo a un servicio HTTP y obtengo un 503 es que temporalmente no disponible, pero si obtengo un 404 es distinto
• #24: Los sdk poseen lógica de reintento. Metodos de reintento, exponencial, lineal
• #25: Si falla un recurso, puedo tener otros recursos arriba, en caso de que falle la DB, tengo redis cache, si falla redis cache puedo tener una queque, donde encolar los mensajes y luego cuando la db este disponible poder meter update Escenario ideal para CQRS
• #26: Balanceador de carga puede ayudar a distribuir la carga, cuando un sistema falla, o cuando un sistema esta lento. A nivel de transporte. Puedo utilizar para distribuir la carga a travez de diferentes maquinas virtuales A nivel de aplicación. Entiene protcoolos como HTTP, HTTPS, Scokets. Proxy Reverso Enrutamiento basado en URL A nivel de DNS. A nivel de applicaiones de Azure. Podemos escalar nuestras aplicaciones en tod oel mundo.
• #27: Topics: muchos subscriptores al mismo tópico, permiso que varios worker reciban el mismo mensaje Relay: comunicación multidireccional, Colas comunes
• #31: Blob storage . Escala mediante particiones CQRS
• #34: Consistencia: Ver los valores en el acto. Por ejemplo una compra El sistema utiliza una base ACID Atomic, consistencia, aislamiento y durabilidad Disponibilidad Nunca podemos diseñar un sistema 100% disponible. Implementando algunos de los servicios y diseños que comentamos podemos logar 99,9% Tolerancia particiones Toda solicitud recibe respuesta aunque alguna subsitema este caido Nodo A y B se comunican y C y D pero no A y D Problemas de red, o ubicación Geo