Está en la página 1de 335

Azure para arquitectos

De Ritesh Modi
Azure para arquitectos
Azure para arquitectos lo guiará por todos lo
aspectos importantes y difíciles de la toma de
decisiones involucrados en diseñar la nube
y estructura de la nube. También incluirá
una breve descripción de diferentes tipos
de servicios proporcionados por Azure,
Azure para
arquitectos
pública de Azure para su organización. El libro como Azure Functions y Azure Analytics,
comienza con una extensa introducción a que pueden resultar beneficiosos para
todas las categorías de diseño disponibles con una organización. Este libro abordará cada
Azure. Estos patrones de diseño se centran aspecto y función necesarios para desarrollar
en diferentes aspectos de la nube, tales como una nube de Azure en función de los
la gran disponibilidad y la administración de requisitos organizativos.
datos, entre otros.
Al final de este libro, estará en condiciones de
Poco a poco, avanzamos hacia diversos desarrollar una nube de Azure completa.
aspectos como la creación de su arquitectura

Lo qué aprenderá:
Implementación del diseño de nube, DevOps, IoT y soluciones sin servidor
• A familiarizarse con los componentes de la • A diseñar e implementar soluciones sin
plataforma Azure Cloud servidor en la nube pública
• A comprender los patrones de diseño en • A ver la arquitectura de la nube y el proceso
la nube de implementación
• A utilizar las pautas de seguridad empresarial • A comprender la administración de costos
para su implementación de Azure para las soluciones de Azure

www.packt.com www.packt.com
De Ritesh Modi
Azure para arquitectos

Implementación del diseño de nube, DevOps,


IoT y soluciones sin servidor en la nube pública

Ritesh Modi

BIRMINGHAM - BOMBAY
Azure para arquitectos

Copyright © 2017 Packt Publishing

Todos los derechos reservados. No está permitida la reproducción, el almacenamiento


en un sistema de recuperación ni la transmisión en cualquier formato o por cualquier
medio de una parte de este libro sin la autorización previa y por escrito del editor,
salvo en el caso de citas breves introducidas en artículos o revistas de opinión crítica.

Durante la preparación de este libro, se hizo todo lo posible por asegurar la exactitud
de la información presentada. Sin embargo, los datos que contiene este libro se
venden sin garantía, ya sea expresa o implícita. Ni el autor ni Packt Publishing,
sus concesionarios y distribuidores, se considerarán responsables de cualquier daño
causado o presuntamente causado de manera directa o indirecta por el contenido
de este libro.

PACKT Publishing intentó proporcionar información de marca de todas las


empresas y los productos mencionados en este libro mediante el uso adecuado
de mayúsculas. Sin embargo, Packt Publishing no garantiza la exactitud de esta
información.

Primera publicación: octubre de 2017

Referencia de producción: 1181017

Publicado por Packt Publishing Ltd.


Livery Place
35 Livery Street
Birmingham B3 2PB, Reino Unido.

ISBN 978-1-78839-739-1
www.packtpub.com
Créditos

Autor Correctores de estilo


Ritesh Modi Safis Editing
Juliana Nair
Revisores
Paul Glavich Coordinador de proyecto
Vikram Pendse Judie Jose
Rubén Oliva Ramos
Revisor
Editor a cargo Safis Editing
Gebin George
Indexador
Directora editorial Tejal Daruwale Soni
Shrilekha Inani
Gráficos
Editor de desarrollo Kirk D'Penha
de contenido
Abhishek Jadhav Coordinador
de producción
Editor técnico Arvindkumar Gupta
Aditya Khadye
Acerca del autor

Ritesh Modi es un exempleado de Microsoft que trabajó como experto principal


en tecnología y actualmente trabaja como consultor principal de Infront Consulting
Group. Se desempeña como arquitecto, experto principal, arquitecto de la nube,
autor de publicaciones, disertante y director conocido por sus contribuciones
relacionadas con centros de datos, Azure, bots, blockchain, servicios cognitivos,
DevOps, inteligencia artificial y automatización. Es autor de varios libros. Desarrollo
de bots con Bot Framework y DevOps con Windows Server 2016 son algunas de sus
últimas obras. Además, fue coautor de otro libro, Introducción a una vista previa
técnica de Windows Server 2016, junto con el equipo de Windows Server.

Disertó en más de 15 conferencias, entre ellas TechEd y la Conferencia de Asia


de PowerShell, y publica artículos de su autoría en la revista MSDN. Tiene más
de una década de experiencia en el desarrollo y la implementación de soluciones
empresariales para clientes y más de 25 certificaciones técnicas. Sus intereses y
pasatiempos incluyen escribir libros, jugar con su hija, ver películas y continuar
el aprendizaje de nuevas tecnologías. Su cuenta de Twitter es @automationnext.

En este momento, Ritesh vive en Hyderabad, India.


Agradecimientos
Escribir este libro ha sido una experiencia fantástica. Personalmente, crecí como
persona porque ahora tengo más paciencia, perseverancia y tenacidad. Le debo
mucho a las personas que me alentaron con su estímulo y motivación. Me gustaría
agradecer a tanta gente que hizo posible la concreción de este libro.

Debo empezar por aquellas que tienen mucha importancia para mí, que me inspiran
para avanzar y que, en última instancia, hacen que todo valga la pena. Me refiero
a mi madre, Bimla Modi, mi esposa, Sangeeta Modi, y mi hija, Avni Modi, las tres
mujeres maravillosas de mi vida. También me gustaría agradecer a mi padre por su
apoyo constante para que permaneciera enfocado en el libro.

Obviamente, debo extender el agradecimiento al equipo de Packt. Me gustaría


agradecer a mi editor de desarrollo de contenido, Abhishek Jadhav, por su
acompañamiento y ayuda en el recorrido de este proyecto. Mi agradecimiento
a la directora editorial, Shrilekha Inani, por buscarme para este libro. Además,
me gustaría dar las gracias a mi editor técnico, Aditya Khadye, que me acompañó
muchas veces en el proceso de este libro y me ofreció sus comentarios de
muchísima utilidad.

Por último, me gustaría pedir disculpas a mi familia, amigos y allegados por no


haber podido estar mucho tiempo con ellos durante el último año. Voy a compensar
esos momentos.
Acerca de los revisores

Paul Glavich se desempeña como profesional más valioso (MVP) de ASP.NET


desde hace 13 años y actualmente trabaja como consultor principal para Readify.
Sus trabajos anteriores fueron director general de tecnología (CTO) en Saasu,
arquitecto de soluciones en Datacom, luego fue consultor principal en Readify y,
antes de ese cargo, se desempeñó como arquitecto técnico para EDS Australia. Tiene
más de 20 años de experiencia en el sector, que abarcan desde PICK, C, C++, Delphi
y Visual Basic 3/4/5/6 hasta su especialidad actual en .NET con C#, ASP.NET,
Azure, nube y DevOps.

Paul se ha dedicado al desarrollo de tecnologías .NET desde que .NET estaba en


etapa beta y fue arquitecto técnico de una de las primeras soluciones bancarias de
Internet del mundo en usar tecnología .NET.

Participa en varios grupos de discusión relacionados con .NET, realizó presentaciones


en el grupo de usuarios Sydney .NET y en TechEd, y también es miembro de
ASPInsiders. Además, escribió algunos artículos técnicos, que pueden verse en sitios
de comunidad, como ASP Alliance. Paul es autor de tres libros, Inicio de AJAX en
ASP.NET, Inicio de Microsoft ASP.NET AJAX y el más reciente, Pruebas y optimización
del rendimiento de .NET. Actualmente, está enfocado en arquitectura general, diseño
de soluciones y soluciones de Microsoft Cloud.

En cuanto a su vida privada, Paul está casado y tiene tres hijos, tres nietos y es quinto
dan de cinturón negro en Budo Jitsu; también practica Wing Chun Kung fu.

Hay muchas personas que me ayudaron a llegar donde estoy


hoy, pero tendría que escribir otro libro para nombrarlas. Por lo
tanto, para no ser tan extenso, me gustaría agradecer a mis tres
hijos, Kristy, Marc y Elizabeth, por ser seres increíbles; a mis
padres, por comprarme esa primera computadora; a mis amigos
empedernidos de la informática por compartir esta pasión; pero
sobre todo me gustaría agradecer a mi esposa, Michele, por ser
un sostén en mi vida y profesión, y soportar las conversaciones
interminables de tecnología y las bromas de papá.
Vikram Pendse se desempeña como profesional más valioso (MVP) de Microsoft
para Azure y, en los últimos 10 años, participó como disertante distinguido en
varios eventos de Microsoft. Es un miembro muy activo de varias comunidades
de Microsoft en la India. Es arquitecto de soluciones en la nube y en este momento
trabaja con uno de los socios principales de Microsoft en Pune, donde es responsable
de desarrollar la estrategia para trasladar las cargas de trabajo de Amazon AWS
a Azure, proporcionar soluciones centradas en la nube, arquitectura, apoyo de RFP
y entregas mundiales. Su cuenta en Twitter es @VikramPendse.

Anteriormente, se desempeñó como revisor técnico en Packt de los siguientes libros:

• Microsoft SharePoint 2010 Enterprise Applications on Windows Phone 7


• Microsoft Silverlight 4 Data and Services Cookbook

Me gustaría agradecer a mi esposa, Aarti, y mi hijo, Aditya, por su


estímulo y apoyo durante todo el proceso.

Ruben Oliva Ramos es ingeniero en sistemas informáticos egresado del Instituto


Tecnológico de León y tiene un título de maestría en ingeniería de sistemas
de informáticos y electrónicos, teleinformática y especialización en redes de la
Universidad de Salle Bajío de León, en Guanajuato, México. Tiene más de cinco años
de experiencia en el desarrollo de aplicaciones web para dispositivos de control
y supervisión conectados a Arduino y Raspberry Pi con marcos web y servicios en
la nube para crear aplicaciones de Internet de las cosas.

Es profesor de mecatrónica en la Universidad de Salle Bajío y enseña diseño


e ingeniería de sistemas mecatrónicos en la carrera de maestría. Además, trabaja
en el Centro de Bachillerato Tecnológico Industrial 225 de León, en Guanajuato,
México, donde enseña materias como electrónica, robótica y control, automatización
y microcontroladores en la carrera de técnico en mecatrónica; es consultor
y desarrollador de proyectos que incluyen áreas tales como supervisión de sistemas
y registrador de datos mediante tecnologías como Android, iOS, Windows Phone,
HTML5, PHP, CSS, Ajax, JavaScript, Angular, bases de datos .NET de ASP: SQLite,
MongoDB, MySQL, servidores WEB: Node.js, IIS, programación de hardware:
Arduino, Raspberry Pi, Ethernet Shield, GPS y GSM/GPRS, ESP8266 y sistemas de
control y supervisión de adquisición de datos y programación.
Escribió un libro para Packt titulado Programación de Internet de las cosas con JavaScript.
También escribió Supervisión, control y adquisición de datos con Arduino y Visual Basic
.NET para Alfaomega.

Me gustaría agradecer a Jesucristo, mi dios y salvador, por darme


la fuerza y el coraje para continuar este proyecto. Agradezco a mi
querida esposa, Mayte, nuestros dos hijos encantadores, Ruben y
Dario, a mi padre, Ruben; mi querida mamá, Rosalia, mi hermano,
Juan Tomas; y mi hermana, Rosalia, a quienes amo, por todo su
apoyo mientras revisaba este libro, por permitirme alcanzar mi
sueño y tolerar mi ausencia después de mis días de mucho trabajo.

Un agradecimiento especial a Packt por darme la oportunidad de


colaborar como autor y revisor, y pertenecer a este equipo sincero
y profesional.
www.PacktPub.com
Para obtener archivos de soporte y descargas relacionadas con el libro, visite
www.PacktPub.com.

¿Sabía que Packt ofrece versiones de eBook de cada libro publicado, con archivos PDF
e ePub disponibles? Puede actualizar a la versión de eBook en www.PacktPub.com
y como es cliente de la versión impresa del libro, tiene derecho a un descuento en
la copia del eBook. Para obtener más información, comuníquese con nosotros a la
dirección customercare@packtpub.com.

En www.PacktPub.com, también puede leer una colección de artículos técnicos


gratuitos, registrarse para recibir una variedad de boletines informativos sin cargo
y recibir descuentos y ofertas exclusivas en libros e eBooks de Packt.

https://www.packtpub.com/mapt

Obtenga las habilidades de software más solicitadas con Mapt. Mapt le da acceso
completo a todos los libros y cursos en video de Packt, así como también a las
herramientas líderes de la industria para ayudarle a planificar su desarrollo personal
y avanzar en su profesión.

¿Por qué suscribirse?


• Capacidad de búsqueda total en cada libro publicado por Packt
• Contenido que se puede copiar y pegar, imprimir y marcar como favorito
• A pedido y accesible mediante un navegador web
Comentarios de clientes
Gracias por adquirir este libro de Packt. En Packt, la calidad es lo más importante de
nuestro proceso editorial. Para ayudarnos a mejorar, déjenos una opinión sincera en
la página de Amazon de este libro en https://www.amazon.com/dp/1788397398.

Si desea participar en nuestro equipo de revisores habituales, envíe un mensaje


de correo electrónico a customerreviews@packtpub.com. Premiamos a nuestros
revisores habituales con eBooks y videos gratuitos a cambio de sus valiosos
comentarios. Ayúdenos a ser incansables en la mejora de nuestros productos.
Contenido
Prólogo xi
Capítulo 1: Introducción 1
Infraestructura como servicio 3
Plataforma como servicio 4
Software como servicio 4
¿Qué es Azure? 5
Azure como nube inteligente 7
Azure Resource Manager 8
Arquitectura de Azure Resource Manager 8
ARM y ASM 9
Ventajas de ARM 10
Conceptos de ARM 10
Proveedores de recursos 11
Tipos de recursos 11
Grupos de recursos 11
Recurso e instancias de recursos 12
Funciones de Azure Resource Manager 12
Virtualización 14
Contenedores 15
Docker 17
Interacción con la nube inteligente 17
Portal de Azure 17
PowerShell 18
Interfaz de línea de comandos (CLI) de Azure 18
API REST de Azure 19
Plantillas de Azure Resource Manager 19
Implementaciones 20
Resumen 20

[i]
Contenido

Capítulo 2: Patrones de diseño de Azure 21


Zonas y regiones de Azure 21
La disponibilidad de recursos 22
Los datos y el cumplimiento de la privacidad 22
El rendimiento de las aplicaciones 22
El costo de ejecutar las aplicaciones 23
Red virtual 23
Consideraciones arquitectónicas para las redes virtuales 24
Beneficios de las redes virtuales 27
Diseño de la red virtual 27
Conexión a los recursos dentro de la misma región y suscripción 28
Conexión a los recursos dentro de la misma región en otra suscripción 28
Conexión a los recursos en diferentes regiones en otra suscripción 29
Conexión a centros de datos locales 29
Almacenamiento 32
Categorías de almacenamiento 33
Tipos de almacenamiento 33
Características de almacenamiento 34
Consideraciones arquitectónicas para las cuentas de almacenamiento 35
Patrones de diseño 36
Patrones de mensajería 37
Consumidores que compiten 38
Cola de prioridad 39
Patrón de nivelación de carga basado en colas 40
Patrones de rendimiento y escalabilidad 41
El patrón de Segregación de responsabilidad de consultas y comandos 41
Patrón de limitación 42
Otros patrones 43
Patrón de reintento 43
Patrón de interruptor 45
Resumen 47
Capítulo 3: Diseñar alta disponibilidad 49
Alta disponibilidad 50
SLA 50
Factores que afectan la alta disponibilidad 51
Mantenimiento planificado 51
Mantenimiento no planificado 51
Arquitectura de implementación de aplicaciones 51
Alta disponibilidad en comparación con escalabilidad 52
Alta disponibilidad en comparación con recuperación ante desastres 52
Alta disponibilidad de Azure 52
Conceptos 53
Conjuntos de disponibilidad 53

[ ii ]
Contenido

Dominio de error 53
Dominio de actualización 54
Zonas de disponibilidad 54
Equilibrio de carga 54
Alta disponibilidad de máquinas virtuales 55
Alta disponibilidad informática 55
Alta disponibilidad en almacenamiento 57
Alta disponibilidad de PaaS 58
Alta disponibilidad de aplicaciones 59
Equilibrio de carga 59
Equilibradores de carga de Azure 60
Equilibrio de carga público 61
Equilibrador de carga interno 62
Redireccionamiento de puertos 64
Gateways de aplicaciones de Azure 64
Azure Traffic Manager 65
Consideraciones arquitectónicas para una alta disponibilidad 66
Alta disponibilidad dentro de las regiones de Azure 67
Alta disponibilidad en todas las regiones de Azure 68
Procedimientos recomendados 69
Alta disponibilidad de aplicaciones 69
Implementación 69
Administración de datos 70
Supervisión 70
Resumen 71
Capítulo 4: Implementar la escalabilidad 73
Escalabilidad 74
Escalabilidad frente a rendimiento 75
Escalabilidad de Azure 75
Conceptos 75
Escalado 75
Escalado vertical hacia arriba 76
Escalado vertical hacia abajo 76
Escalado horizontal de crecimiento 76
Escalado horizontal de reducción 77
Escalado automático 77
Escalabilidad de PaaS 77
Escalado vertical de PaaS 79
Escalado horizontal de PaaS 79
Escalabilidad de IaaS 81
Conjuntos de escalado de máquinas virtuales 81
Arquitectura de VMSS 83
Escalado de VMSS 83
Escalado horizontal frente a escalado vertical 84

[ iii ]
Contenido

Capacidad 84
Escalado automático 84
Actualizaciones 87
Actualizaciones de aplicación 89
Actualizaciones de invitado 89
Actualizaciones de imagen 89
Procedimientos recomendados de escalado 90
Preferencia de escalado de crecimiento 90
Instancias sin sistema operativo frente a instancias inactivas 90
Configuración adecuada de la cantidad máxima y mínima de instancias 90
Simultaneidad 91
Sin estado 91
Almacenamiento en caché y CDN 91
Diseño N+1 91
Resumen 92
Capítulo 5: Seguridad de la nube 93
Seguridad 94
Ciclo de vida de la seguridad 95
Seguridad de Azure 97
Seguridad de IaaS 98
Grupos de seguridad de red 98
Firewalls 100
Reducir la superficie de ataque 102
Implementar servidores de salto 103
Seguridad de PaaS 103
Operations Management Suite (OMS) 103
Almacenamiento 105
Azure SQL 108
Azure Key Vaults 111
Auditoría y supervisión de seguridad 111
Supervisor de Azure 111
Azure Security Center 112
Resumen 114
Capítulo 6: Diseñar soluciones de IoT 115
IoT 115
Arquitectura de IoT 117
Conectividad 118
Identidad 120
Captura 120
Ingesta 121
Almacenamiento 121
Transformación 121

[ iv ]
Contenido

Análisis 122
Presentación 123
Azure IoT 123
Identidad 124
Captura 124
Ingesta 125
Almacenamiento 125
Transformación y análisis 126
Presentación 127
Hubs de IoT 127
Protocolos 128
Registro de dispositivos 128
Administración de mensajes 130
Mensajería del dispositivo a la nube 130
Mensajería de la nube al dispositivo 131
Seguridad 132
Seguridad en IoT 132
Escalabilidad 133
Edición de SKU 133
Unidades 135
Alta disponibilidad 135
Resumen 136
Capítulo 7: Diseñar e implementar soluciones de datos 137
Azure SQL 138
Disponibilidad de Azure SQL 140
Seguridad de Azure SQL 141
Grupos elásticos 142
Escalado de crecimiento de Azure SQL 142
Stream Analytics 144
Orígenes de datos 146
Integración de datos 146
Transformación de datos 146
Motor Stream Analytics 146
Almacenamiento y presentación 147
Arquitectura 147
Azure Data Factory 148
Orígenes de datos 149
Transformación de datos 151
Publicación y presentación 151
Usar la fábrica de datos 151

[v]
Contenido

Azure Data Lake 162


Azure Data Lake Store 162
Azure Data Lake y la seguridad 164
Azure Data Lake y el rendimiento 164
Azure Data Lake Analytics 165
Azure SQL Data Warehouse 165
Almacenamiento de tablas 169
Resumen 170
Capítulo 8: Diseñar e implementar soluciones sin servidor 171
Una historia breve de la informática sin servidor 172
Informática sin servidor 174
Principios de la tecnología sin servidor 175
Menor costo 175
Basada en eventos 175
Responsabilidad única 175
Rápida ejecución 175
Funciones de Azure o funciones como un servicio: FaaS 175
Desencadenadores, enlaces y tiempo de ejecución de las funciones de Azure 176
Tiempo de ejecución de las funciones de Azure 176
Enlaces y desencadenadores de las funciones de Azure 176
Proxies de función de Azure 179
Supervisión 180
Autenticación y autorización 180
Configuración de las funciones de Azure 182
Configuración de la plataforma 183
Configuración de funciones de los servicios de la aplicación 184
Planes de costos de la función de Azure 184
Ventajas de las funciones de Azure 185
Casos de uso de las funciones de Azure 188
Implementación de microservicios 189
Integración entre múltiples puntos de conexión 189
Procesamiento de datos 189
Integrar aplicaciones heredadas 189
Tareas programadas 190
Gateways de comunicación 190
Tipos de funciones de Azure 190
Crear su primera función de Azure 190
Crear una función dirigida por eventos 196
Crear una arquitectura conectada con funciones 200
Resumen 204

[ vi ]
Contenido

Capítulo 9: Diseñar políticas, bloqueos y etiquetas 205


Etiquetas de Azure 206
Etiquetas con PowerShell 208
Etiquetas con la plantilla de ARM 208
Grupos de recursos frente a recursos 209
Políticas de Azure 209
Políticas integradas 210
Lenguaje de políticas 210
Campos permitidos 212
Bloqueos de Azure 213
Azure RBAC 215
Roles personalizados 217
¿En qué difiere de RBAC? 218
Ejemplos de la implementación de características de gobernanza de Azure 218
Antecedentes 218
Control de acceso basado en roles 219
Resumen 219
Capítulo 10: DevOps en Azure 221
¿Qué es DevOps? 222
Prácticas de DevOps 225
Administración de configuración 226
Configuración de estado deseada 228
Chef, Puppet y Ansible 228
Plantillas de Azure Resource Manager 228
Integración continua 229
Automatización de la compilación 230
Automatización de pruebas 231
Embalaje 231
Implementación continua 231
Implementación del entorno de prueba 233
Automatización de pruebas 233
Implementación del entorno de almacenamiento provisional 233
Pruebas de aceptación 233
Implementación para producción 233
Entrega continua 234
Aprendizaje continuo 234
Visual Studio Team Services 235
Team Foundation Version Control 237
GIT 238
Preparación para DevOps 238
Aprovisionamiento de cuenta de VSTS 240
Aprovisionamiento del almacén de claves de Azure 241

[ vii ]
Contenido

Aprovisionar un servidor de administración de configuración 241


Aprovisionamiento de análisis de registro 241
Cuenta de almacenamiento de Azure 242
Imágenes 242
Herramientas de supervisión 242
Herramientas de administración 242
DevOps para soluciones PaaS 243
Servicios de aplicación de Azure 244
Ranuras de implementación 245
Azure SQL 245
Canalización de compilación y versión 245
DevOps para soluciones basadas en máquinas virtuales (IaaS) 246
Máquina virtual de Azure 246
Equilibrador de carga pública de Azure 247
Canalización de compilación 247
Canalización de versiones 248
DevOps para soluciones basadas en contenedor (IaaS) 249
Contenedores 250
Docker 250
DockerFile 250
Canalización de compilación 251
Canalización de versiones 251
Azure Automation 252
Aprovisionar la cuenta de Azure Automation 253
Redactar configuración de DSC 254
Importar la configuración de DSC 255
Compilar la configuración de DSC 256
Asignar configuración a los nodos 256
Navegar por el servidor 257
Azure para DevOps 258
Resumen 260
Capítulo 11: Administrar costos 261
Comprensión de la facturación 262
Facturas 266
Clientes del Contrato Enterprise 267
Uso y cuotas 267
Proveedores de recursos 268
API de facturación y uso 269
Modelos de precios de Azure 269
Beneficio híbrido de Azure 270

[ viii ]
Contenido

Instancias reservadas de VM de Azure 270


Cuentas de pago según el uso 270
Contratos Enterprise 271
Proveedor de soluciones en la nube 271
Calculadora de precios de Azure 271
Procedimientos recomendados 273
Procedimientos recomendados de procesamientos 274
Procedimientos recomendados de almacenamiento 275
Procedimientos recomendados de PaaS 275
Procedimientos recomendados generales 276
Resumen 276
Capítulo 12: Supervisión y auditoría 277
Supervisión 278
Supervisión de Azure 279
Registros de actividades de Azure 279
Registros de diagnóstico de Azure 279
Registros de aplicaciones de Azure 280
Registros de sistema operativo invitado y host 280
Supervisor de Azure 281
Azure Application Insights 281
Azure Log Analytics 281
Application insights 281
Aprovisionamiento 282
Análisis de registros 286
Aprovisionamiento 286
Agentes OMS 289
Búsqueda 290
Soluciones 291
Alertas 292
La ejecución de runbooks en alertas 296
Integración de Power BI 303
Resumen 305

[ ix ]
Prólogo
Azure, la nube de la cuadrilla de Microsoft, es una plataforma en la nube
consolidada y en crecimiento continuo. Tiene cada vez más empuje, aceptación y
popularidad, y sigue siendo la plataforma en la nube preferida de muchas personas.
Azure es una plataforma grande, pero detrás de esta plataforma hay cientos de
recursos y servicios de Azure que hacen que la magia suceda. Todos estos recursos
y servicios se proporcionan a los usuarios de manera uniforme con Azure Resource
Manager. Una plataforma en la nube tiene que respetar a los usuarios y las reglas
soberanas de cada país en cuanto a la seguridad y los datos. Azure tiene más de
35 centros de datos en todo el mundo y esta cantidad aumenta cada año. Cuenta
con la mayoría de las certificaciones de seguridad que están disponibles hoy en
la industria. Proporciona diferentes niveles de control en la implementación con
distintos modelos, como infraestructura como servicio, plataforma como servicio
y software como servicio. Además, ofrece muchos recursos y funciones para
implementar la nube hibrida. En realidad, debido al lanzamiento de Azure Stack,
Azure es una de las plataformas más consolidadas y con más funciones para
las implementaciones híbridas. Azure es una nube abierta que admite cualquier
sistema operativo, lenguaje de programación y tiempo de ejecución. Es flexible y
ofrece múltiples recursos y opciones para implementar funcionalidades similares,
aunque tengan algunas diferencias. Tiene disponible múltiples costos y modelos
de uso, y abarca a casi todos los tipos de cliente, ya sea en modo de pago por uso,
acuerdos de empresa o un modelo de proveedor de solución en la nube. Como
si esto fuera poco, tiene múltiples opciones, como instancias de VM reservadas y
beneficios híbridos de Azure para reducir el costo general de las implementaciones.
Azure proporciona muchas herramientas para asegurar que los clientes puedan
automatizar sus implementaciones y también iniciar su recorrido en DevOps.
DevOps es un paradigma emergente, y Azure proporciona todas las funciones para
implementarlo.

[ xi ]
Prólogo

Ya que tiene tantas opciones, recursos y modelos de implementación diferentes,


es importante que los usuarios de Azure entiendan el propósito, la importancia
y la utilidad de cada recurso a nivel arquitectónico, y cómo se comparan con sus
recursos similares. Según sean los requisitos, es necesario implementar los recursos
apropiados. Una arquitectura para una solución en la nube abarca varios recursos.
La elección de los recursos, su configuración y la interacción tienen que diseñarse
meticulosamente y de manera adecuada. Azure proporciona plataformas de avance,
como IoT, sin servidor y big data. Estas son tecnologías emergentes y en este libro se
analiza cada una de ellas.
Azure ofrece casi todo tipo de servicios para satisfacer las necesidades informáticas
de cualquier organización y es importante tratarlas con la estrategia y la arquitectura
correctas. Este libro es un intento en esa dirección, para proporcionar a sus usuarios
los elementos suficientes para diseñar y construir sus soluciones, que abarcan
patrones de diseño, alta disponibilidad, seguridad, escalabilidad, administración
de costos, supervisión y auditoría. Los temas de todos los capítulos de este libro
requieren de un libro completo en sí mismos. Fue muy difícil resumir las inquietudes
arquitectónicas, los procedimientos recomendados y el uso de las funciones de
Azure en un solo capítulo. Insisto para que todos los lectores lean cada capítulo y la
documentación en línea de Microsoft relacionada con cada uno de ellos para ampliar
su conocimiento.

Qué se analiza en este libro


El Capítulo 1, Introducción, presenta la informática en la nube como una estrategia y
un paradigma nuevo. Este libro trata sobre Azure y comienza con su presentación.
Proporciona detalles sobre IaaS, PaaS y una introducción a algunas de las funciones
importantes que ayudan en el diseño de soluciones. Presentará el Azure Resource
Manager y los grupos de recursos. También introducirá los recursos importantes de
Azure, como procesos, redes, almacenamiento, funciones, IoT, servicios de datos y
herramientas de automatización y lenguajes.
El Capítulo 2, Patrones de diseño de Azure, se refiere a los patrones en la nube de Azure
relacionados con redes virtuales, cuentas de almacenamiento, regiones y conjuntos
de disponibilidad. Además, analiza en forma breve los patrones de nubes que
ayudan en la implementación de la escalabilidad y el rendimiento. Los patrones de
mensajería ayudan en la construcción de soluciones confiables. Este tema también se
analizará en este capítulo.
El Capítulo 3, Diseñar alta disponibilidad, se centra en describir las funciones de alta
disponibilidad que tiene Azure. Las empresas necesitan alta disponibilidad para sus
implementaciones. Este capítulo desarrollará una base sólida en los conceptos de alta
disponibilidad y ayudará al usuario a tomar decisiones con la información necesaria
relacionada con estrategias de implementación de IaaS y PaaS.

[ xii ]
Prólogo

El Capítulo 4, Implementar la escalabilidad, se refiere al diseño de soluciones que


automáticamente puedan aumentar y disminuir los recursos disponibles según
su consumo actual para mantener sus niveles de rendimiento. Azure proporciona
conjuntos de escala de máquina virtual (VMSS) para implementar soluciones
altamente escalables. Este capítulo se centra en la implementación y la arquitectura
de VMSS. Además, describe la escalabilidad basada en PaaS y sus estrategias.
El Capítulo 5, Seguridad en la nube, introduce conceptos importantes desde el
punto de vista de la seguridad. La seguridad tiene una importancia superior en
cualquier implementación en la nube. Azure proporciona grupos de seguridad de
red, firewalls, NAT, centro de seguridad y funciones de almacenes de clave para
implementar aplicaciones de seguridad cibernética. Este capítulo proporcionará
detalles acerca de estas funciones y diseñará una solución con ellas.
El Capítulo 6, Diseñar soluciones de IoT, presenta información detallada sobre la
implementación de una solución de IoT con la nube de Azure. La nube Azure
proporciona una completa plataforma de IoT para el desarrollo de soluciones
basadas en dispositivo. Este capítulo mostrará cómo diseñar soluciones basadas
en IoT con la nube de Azure. También describirá inquietudes arquitectónicas
que cada arquitecto tiene que tener en cuenta al crear una solución. Este capítulo
analizará temas relacionados con los centros de IoT, centros de eventos, registro
de dispositivos, una conversación de dispositivo a plataforma y el registro y
enrutamiento a destinos apropiados.
El Capítulo 7, Diseñar e implementar soluciones de datos, se dedica a los servicios
y el almacenamiento de datos. Azure proporciona múltiples funcionalidades
relacionadas con los servicios de datos. Este capítulo se enfocará en proporcionar
aportes acerca de qué funciones y recursos se tienen que usar en diferentes tipos
de soluciones y sus beneficios, ventajas y desventajas. En este capítulo, se hará
referencia a una arquitectura completa para asimilar, limpiar, filtrar y almacenar
datos en almacenes de datos apropiados, tales como Data Lake y Cosmos DB,
y luego insertar datos en Power BI para visualizar.
El Capítulo 8, Diseñar e implementar soluciones sin servidor, se centra en la informática
sin servidor. Las funciones de Azure son una plataforma versátil para alojar
funcionalidades de pequeñas empresas como funciones y ayudar a combinar
soluciones entre sí. Este capítulo se enfocará en entender el paradigma sin
servidor, las funciones de Azure, sus capacidades, la creación de soluciones
mediante la combinación de múltiples funciones, el entendimiento de elementos
desencadenantes y parámetros, y las diferentes fuentes de entradas y salidas.

[ xiii ]
Prólogo

El Capítulo 9, Diseñar políticas, bloqueos y etiquetas, se centra en el uso de las


funciones de administración proporcionadas por Azure para instalar mejores
implementaciones de administración. Las etiquetas ayudan mediante el agregado
de información de metadatos adicionales a los recursos de Azure. Además, colaboran
mediante la provisión de arquitectura de información sobre los recursos de Azure.
Este capítulo ofrece pautas de diseño para definir etiquetas de implementación.
También proporciona detalles sobre las políticas y los bloqueos para restringir
y controlar los recursos de Azure relacionados con su ubicación, uso, tamaño,
accesibilidad, permisos, etc. Es un concepto importante que permite el control de
la administración de los recursos de Azure.
El Capítulo 10, DevOps en Azure, trata sobre DevOps. La nube de Azure proporciona
muchas herramientas, utilidades y compatibilidad de scripting para permitir la
automatización de DevOps. Azure admite plantillas de Azure Resource Manager,
configuración de estado deseado, PowerShell, API Rest y tecnologías de open source,
como Chef, Python y Linux para idear la automatización de extremo a extremo de
integración, entrega e implementación continuas. La infraestructura como código
y la administración de configuración también son compatibles de manera inherente
con las funciones de Azure, como por ejemplo la automatización de Azure. Este
capítulo se centrará en el desarrollo de la canalización de CI/CD y la administración
de configuración para los recursos de Azure con VSTS.
El Capítulo 11, Administrar costos, abarca un ángulo un poco diferente, en comparación
con los otros capítulos de este libro. No es un capítulo técnico, pero analiza diversas
formas de medios para reducir el costo de las implementaciones en Azure.
Este capítulo se centrará en calcular el costo de implementación en Azure con la
calculadora de costos de Azure. Además, mostrará cómo cambiar la ubicación,
el tamaño y el tipo de recursos puede afectar el costo de la solución, y también
proporcionará las mejores prácticas para reducir el costo general de implementaciones
de Azure.
El Capítulo 12, Supervisión y auditoría, se centra en entender cómo los servicios de
Azure, por ejemplo las perspectivas operativas y de aplicación, ofrecen capacidades
de supervisión y auditoría. Este capítulo mostrará cómo configurarlas y utilizarlas
para supervisar los recursos de Azure y tomar acciones basadas en ellos. También
se centrará en diseñar soluciones de supervisión para las implementaciones en la
nube de Azure.

Qué necesita para este libro


Este libro supone un nivel básico de conocimiento sobre informática en la nube y
Azure. Para usar este libro, todo lo que necesita es una conexión a Internet y una
suscripción de Azure válida. Un sistema operativo Windows 10 con 4 GB de RAM es
suficiente para usar PowerShell y ejecutar las plantillas de ARM.

[ xiv ]
Prólogo

Quiénes son los destinatarios de este libro


Para usar el contenido de este libro, se espera que el lector tenga un conocimiento
previo básico de la nube y Azure. Si cree que no posee ese conocimiento, siempre
es posible alcanzar los requisitos básicos si lee rápidamente sobre los componentes
principales en la documentación de Azure que está en https://docs.microsoft.
com/es-es/. Este libro está destinado esencialmente a arquitectos, desarrolladores y
consultores de la nube e ingenieros de DevOps que utilizan Azure para prestar sus
servicios a clientes finales y empleadores. Si también está dispuesto a diseñar soluciones
completas en Azure, este libro es ideal para usted. Si ya tiene alguna experiencia con la
arquitectura de Azure, este libro puede ayudarle a avanzar de una manera acelerada.

Convenciones
En este libro, encontrará una cantidad de estilos de texto que distinguen distintos tipos de
información. Estos son algunos ejemplos de estos estilos y una explicación de su significado.
Las palabras de código en texto, los nombres de tabla de base de datos, los nombres
de las carpetas, los nombres de archivo, las extensiones de archivo, los nombres de
rutas de acceso, las URL ficticias, los comentarios de usuario y los alias de Twitter se
muestran de la siguiente manera: “Podemos incluir otros contextos mediante el uso
de la directiva incluir”.
Un bloque de código se establece de la siguiente manera:
Import-DscResource -ModuleName 'PSDesiredStateConfiguration'
Node WebServer {
WindowsFeature IIS
{
Name = "Web-Server"
Ensure = "Present"
}

Los nuevos términos y las palabras importantes se muestran en negrita.


Las palabras que ve en la pantalla, por ejemplo, en menús o cuadros de diálogo,
aparecen en el texto como: “El primer paso es crear un recurso de fábrica de datos.
Después de la creación, haga clic en el botón Copiar datos”.

Las advertencias o notas importantes aparecen en un


cuadro como este.

Los consejos y trucos aparecen de esta manera.

[ xv ]
Prólogo

Comentarios del lector


Siempre estamos dispuestos a recibir comentarios de nuestros lectores. Esperamos
su opinión sobre este libro, lo que le gustó y lo que no fue de su agrado.
Los comentarios de los lectores son importantes para nosotros porque nos ayudan
a desarrollar títulos que podrá aprovechar al máximo.
Para enviarnos comentarios generales, puede hacerlo por correo electrónico
a feedback@packtpub.com; mencione el título del libro en el asunto del mensaje.
Si hay un tema en el que tiene experiencia y está interesado en escribir o como aporte
para un libro, consulte nuestra guía de autores en www.packtpub.com/authors.

Soporte al cliente
Ahora que es el orgulloso propietario de un libro de Packt, tenemos una serie de
cosas para ayudarle a aprovechar al máximo su compra.

Descarga de las imágenes de color de este libro


También le ofrecemos un archivo PDF que tiene imágenes de color de las
capturas de pantalla o los diagramas usados en este libro. Las imágenes de color
le ayudarán a entender mejor los cambios en el resultado. Puede descargar este
archivo en https://www.packtpub.com/sites/default/files/downloads/
AzureforArchitects_ColorImages.pdf.

Fe de erratas
Si bien hemos hecho todo lo posible por asegurar la exactitud de nuestro contenido,
los errores ocurren. Si encuentra uno en alguno de nuestros libros, puede ser un error
en el texto o el código, le agradeceremos que nos informe al respecto. Al hacerlo,
puede evitar que otros lectores se sientan frustrados y nos ayuda a mejorar las
versiones posteriores de este libro. Si encuentra algún error impreso, infórmelo en
http://www.packtpub.com/submit-errata, seleccione el libro, haga clic en el
enlace del Formulario de presentación de errores de impresión e ingrese los detalles
del error. Una vez que se verifique, se aceptará su envío y se cargará la fe de erratas
en nuestro sitio web o se agregará en alguna lista de erratas existentes en la sección
Fe de erratas de dicho título.
Para ver las erratas presentadas previamente, vaya a https://www.packtpub.com/
books/content/support y escriba el nombre del libro en el campo de búsqueda.
La información requerida aparecerá en la sección Fe de erratas.

[ xvi ]
Prólogo

Piratería
La piratería de material con derechos de autor en Internet es un problema constante
en todos los medios de comunicación. En Packt, la protección de los derechos de
autor y las licencias es una cuestión que tratamos con mucha seriedad. Si encuentra
copias ilegales de nuestros trabajos en cualquier formato en Internet, le pedimos que
nos proporcione la dirección de ubicación o el nombre del sitio web de inmediato
para que podamos buscar una solución.
Comuníquese con nosotros a copyright@packtpub.com e incluya un enlace del
presunto material pirata.
Apreciamos su ayuda en la protección de nuestros autores y nuestra capacidad de
ofrecerle contenido valioso.

Preguntas
Si tiene algún problema con cualquier aspecto de este libro, puede comunicarse con
nosotros a questions@packtpub.com y haremos todo lo posible por solucionarlo.

[ xvii ]
Introducción
Cada algunos años, hay innovaciones tecnológicas que cambian todo el panorama
y el ecosistema que las rodea. Si nos remontamos en el tiempo, las décadas de
los 70 y los 80 fueron una época de sistemas centrales. Eran enormes, prácticamente
ocupaban grandes habitaciones y realizaban casi todo el trabajo informático. Eran
difíciles de adquirir y pasaba mucho tiempo hasta que estuvieran funcionando.
Las empresas solían realizar el pedido meses antes de poder tener configurado un
sistema central operativo.

La primera parte de la década de los 90 fue la era de la informática personal y de


Internet. Los equipos se volvieron mucho más pequeños y eran relativamente fáciles
de adquirir. La informática personal y la innovación de Internet cambiaron toda la
industria informática. Las personas tenían un escritorio mediante el cual podían
ejecutar múltiples programas y conectarse a Internet. El auge de Internet también
propagó el auge de las implementaciones cliente-servidor. Ahora bien, podría haber
servidores centralizados que hospedaran aplicaciones y servicios a los que podría
acceder cualquier persona con conexión a Internet a nivel mundial. Fue en ese
entonces también cuando la tecnología de servidores tuvo un gran protagonismo.
En ese periodo se lanzaron Windows NT, Windows 2000 y Windows 2003.

La innovación más notable de la década del 2000 fue el auge y la adopción de


dispositivos, especialmente los smartphones, y con ellos surgieron una gran cantidad
de aplicaciones. Las aplicaciones podían conectarse a servidores centralizados
en Internet y realizar las tareas normalmente. Los usuarios ya no dependían de
los navegadores para hacer este trabajo. Por lo general, todos los servidores eran
autohospedados o se hospedaban con un proveedor de servicios, como un Proveedor
de servicios de Internet (ISP).

Los usuarios no tenían mucho control sobre los servidores. Diversos clientes y sus
implementaciones eran parte del mismo servidor, incluso sin saberlo.

[1]
Introducción

Sin embargo, esto no era todo lo que sucedía hacia mitad y fines del 2000. Fue el
auge de la informática en la nube, y esto, una vez más, cambió todo el panorama de
la industria de la TI. Aunque, inicialmente, la adopción fue lenta y las personas la
abordaron con precaución, ya sea porque la nube estaba en su fase inicial y todavía
debía madurar o porque tenían varias ideas diferentes al respecto.

Sin embargo, hoy en día, la informática en la nube es una de las tecnologías


e iniciativas más prometedoras y aún emergentes. Independientemente de su tamaño,
cada empresa/organización la ha adoptado como parte de su estrategia de TI. En la
actualidad, es difícil tener una conversación significativa sin incluir la informática en la
nube en los debates generales sobre soluciones.

La informática en la nube, o simplemente la nube en términos generales, se refiere


a la disponibilidad de recursos en Internet. Estos recursos están disponibles para los
usuarios de Internet como servicios. Por ejemplo, el almacenamiento está disponible
a petición a través de Internet para que los usuarios almacenen sus archivos,
documentos, etc. Aquí, el almacenamiento es un servicio proporcionado por un
proveedor de nube.

Un proveedor de nube es una empresa o un consorcio de empresas que brinda


servicios en la nube a otras empresas y consumidores. Hospedan y administran
los servicios en nombre del usuario. Son responsables de facilitar los servicios
y de mantener su estado. Por lo general, existen grandes centros de datos en todo el
mundo que abrieron los proveedores de nube para atender a las demandas de TI de
los usuarios.

Los recursos de nube podrían ser una entrega de servicios de hosting


o infraestructuras a petición, como un equipo, una red e instalaciones de
almacenamiento para el consumo de los usuarios. Este tipo de nube también es
conocido como Infraestructura como servicio.

Existen tres tipos de servicios proporcionados por la nube según su nivel de


abstracción y grado de control sobre estos servicios por parte de los usuarios y los
proveedores de nube:

• Infraestructura como servicio (comúnmente conocido como IaaS)


• Plataforma como servicio (comúnmente conocido como PaaS)
• Software como servicio (comúnmente conocido como SaaS)

IaaS, PaaS y SaaS difieren según el nivel de control entre un consumidor de nube y un
proveedor de nube. Con SaaS, un proveedor de nube tiene control casi total de los servicios,
y el consumidor tiene control solo de sus datos y aplicaciones. Asimismo, un proveedor de
nube tiene mayor control con IaaS en comparación con el consumidor de nube.

[2]
Capítulo 1

Servicios en la nube: IaaS, PaaS, SaaS

El diagrama anterior muestra las tres categorías de servicios disponibles a través


de los proveedores de nube y las capas de las que se compone cada servicio. Estas
capas se apilan verticalmente unas sobra otras, y cada capa en la pila tiene un
color diferente según quién la administra, el cliente o el proveedor. En la figura,
vemos que para IaaS, un proveedor de nube es responsable de proporcionar,
controlar y administrar las capas desde la capa de red hacia arriba hasta la capa
de virtualización. Del mismo modo, para PaaS, un proveedor de nube controla
y administra desde la capa de hardware hacia arriba hasta la capa de ejecución,
mientras que el consumidor controla solo las capas de aplicación y datos.

Infraestructura como servicio


Como el nombre lo indica, IaaS son servicios de infraestructura proporcionados por
un proveedor de nube. Este servicio incluye el hardware físico y su configuración,
el hardware de red y su configuración, el hardware de almacenamiento y su
configuración, equilibradores de carga, informática y virtualización. Cualquier capa
superior a la de virtualización es responsabilidad del consumidor. El consumidor
puede decidir utilizar la infraestructura subyacente proporcionada de la manera que
mejor se adapte a sus necesidades. Por ejemplo, los consumidores pueden utilizar
el almacenamiento, la red y la virtualización para aprovisionar máquinas virtuales.
Entonces, es responsabilidad del consumidor administrar y controlar las máquinas
virtuales y el software implementado en ellas.

[3]
Introducción

Plataforma como servicio


PaaS permite a los consumidores implementar sus aplicaciones y servicios en la
plataforma proporcionada y utilizar el tiempo de ejecución subyacente, middleware
y servicios. El proveedor de nube ofrece los servicios desde la infraestructura hasta la
ejecución. Los consumidores no pueden aprovisionar máquinas virtuales ya que no
pueden acceder a ellas ni controlarlas. En cambio, solo pueden controlar y administrar
sus aplicaciones. Es un método relativamente más rápido de desarrollo e implementación
porque ahora el consumidor puede centrarse en la implementación y el desarrollo
de aplicaciones. Algunos ejemplos de plataformas como servicio incluyen Azure
Automation, Azure SQL y servicios de aplicaciones de Azure.

Software como servicio


Software como servicio proporciona un control completo del servicio al proveedor
de nube. El proveedor de nube aprovisiona, configura y administra todo desde la
infraestructura hasta la aplicación. Incluye el aprovisionamiento de la infraestructura,
la implementación y la configuración de aplicaciones, y ofrece al consumidor acceso
a las aplicaciones. El consumidor no controla ni administra la aplicación y puede
utilizar y configurar solo partes de ella. Solo controla sus datos y configuración.
En general, diversos consumidores utilizan las aplicaciones multiinquilino, como
Office 365 y Visual Studio Team Services, que son ejemplos de SaaS.

En los últimos años, se ha observado un crecimiento exponencial de la adopción


de la nube. Mientras que la mayor parte del crecimiento inicial era de pequeñas
y medianas empresas, la adopción actual proviene de las grandes empresas.
Esto ocurre principalmente debido a los motivos mencionados a continuación:

• Rentabilidad: la nube ayuda en la eliminación de gastos de capital y, en


su lugar, solo incurre en costos operativos. Los usuarios pueden dejar de
comprar hardware físico y licencias de software costosas, y de montar
grandes centros de datos. Todo esto se encuentra disponible en la nube sin
que el usuario deba gastar dinero para comprarlos.
• Escala y capacidad ilimitadas: la nube brinda la idea de disponibilidad
ilimitada de recursos. Esto alienta a las organizaciones a implementar sus
cargas de trabajo en ella dado que no se ven restringidas por las limitaciones
de disponibilidad de hardware.
• Elasticidad: la informática en la nube es elástica por naturaleza. Los clientes
pueden reducir o aumentar su presencia en la nube en función de sus
necesidades con una interfaz de usuario fácil de usar. No existe un costo por
adelantado, limitaciones de la disponibilidad de recursos ni desfase temporal.

[4]
Capítulo 1

• Pago por uso: utilizar la nube elimina los gastos de capital y las organizaciones
solo pagan por lo que usan, así se proporciona el máximo retorno de la
inversión. Las organizaciones no necesitan crear una infraestructura adicional
para hospedar su aplicación para los momentos de máxima demanda.
• Más rápido y mejor: la nube proporciona aplicaciones listas para usar y un
aprovisionamiento e implementación de entornos más rápidos. Además, las
organizaciones obtienen servicios mejor administrados de su proveedor de
nube con acuerdos de nivel de servicio superiores.

¿Qué es Azure?
Según Wikipedia:

“Azure es un servicio de informática en la nube creado por Microsoft para crear,


implementar y administrar aplicaciones y servicios a través de una red global
de centros de datos administrados por Microsoft. Ofrece software como servicio,
plataforma como servicio e infraestructura como servicio, y admite muchos
lenguajes de programación, herramientas y marcos diferentes, incluidos los
sistemas y software específicos de Microsoft y de terceros”.

Obviamente, Azure ofrece todos los beneficios de la nube, pero también es una nube
abierta y flexible. La nube de Azure admite diversos sistemas operativos, idiomas,
herramientas, plataformas, utilidades y marcos. Admite Linux y Windows, SQL Server,
MySQL, Postgres y más, C#, Python, Java, Node.js, Bash y más idiomas, bases de
datos NoSQL MongoDB y DocumentDB, y de Jenkins a VSTS como herramientas de
integración continua. La idea detrás de este ecosistema es permitir que los usuarios
tengan la opción y libertad de elegir lenguaje, plataforma, sistema operativo, base de
datos, almacenamiento, herramientas y utilidades. Los usuarios no tienen que verse
limitados desde la perspectiva tecnológica; en cambio, tienen que poder crear
y centrarse en su solución de negocios, y Azure les ofrece una pila tecnológica de nivel
mundial. Azure es compatible con la elección del usuario de la pila tecnológica.

Por ejemplo, Azure ofrece disponibilidad de todos los entornos de bases de datos
populares (open source o comerciales). Azure ofrece el servicio de PaaS Azure SQL,
MySQL y Postgres. Proporciona un ecosistema de Hadoop y ofrece HDInsight, un
servicio PaaS 100 % basado en Apache Hadoop. También proporciona Hadoop
en la implementación de VM en Linux para clientes que prefieren el enfoque de
IaaS. Azure también ofrece un servicio de caché de Redis y admite otros entornos
populares de bases de datos, como MongoDB, Couchbase, Oracle y muchos otros
como una implementación de IaaS.

[5]
Introducción

La cantidad de servicios aumenta día a día, y en la siguiente figura se muestra el


abundante conjunto de servicios de Azure. No todos los servicios se muestran aquí,
y siguen agregándose.

Servicios de Azure

Azure también ofrece un paradigma único de informática en la nube: la nube híbrida.


Nube híbrida se refiere a una estrategia de implementación en la que se implementa
un subconjunto de servicios en una nube pública, mientras que otros servicios se
implementan en una nube privada o centro de datos local. Existe una conexión de
red privada virtual (VPN) entre la nube pública y la privada. Azure proporciona a
los usuarios la flexibilidad para dividir e implementar su carga de trabajo en la nube
pública y en un centro de datos local.

Azure tiene centros de datos en todo el mundo. Y agrupa estos centros de datos
en regiones. Cada región cuenta con múltiples centros de datos para garantizar
que la recuperación ante desastres sea rápida y eficiente. En el momento en el
que se escribió este documento, había 38 regiones en todo el mundo. Esto ofrece
a los usuarios la flexibilidad para implementar sus servicios según su elección de
ubicación y regiones. También pueden combinar estas regiones para implementar
una solución que sea resistente a los desastres y que se implemente cerca de su base
de clientes.

[6]
Capítulo 1

Regiones y ubicaciones de Azure

Azure también tiene nubes independientes para China,


Alemania y los gobiernos.

Azure como nube inteligente


Azure no es solo una nube; es una nube inteligente. Ahora bien, es posible que
se pregunte qué es una nube inteligente. La gente consume potencia informática
principalmente debido a dos razones: buscan algo y, luego de encontrar lo que
buscaban, actúan en función de eso. Las potencias informáticas completas están
asociadas a estos dos propósitos. Azure proporciona infraestructura y servicios para
invertir miles de millones de registros con procesamiento de hiperescala. Proporciona
varios petabytes de almacenamiento de datos. Proporciona un host de servicios
interconectados que pueden pasarse datos entre sí. Con tales capacidades, pueden
procesarse datos para generar información y conocimiento significativos. Existen
varios tipos de información que puede generarse a través del análisis de datos:

• Descriptivo: este tipo de análisis proporciona información detallada sobre lo


que está sucediendo o sucedió en el pasado
• Predictivo: este tipo de análisis proporciona información detallada sobre lo
que va a suceder próximamente o en el futuro

[7]
Introducción

• Preceptivo: este tipo de análisis proporciona información detallada sobre lo


que tiene que hacerse para mejorar o prevenir el acontecimiento actual o futuro
• Cognitivo: ejecuta las acciones determinadas por el análisis prescriptivo de
forma automatizada

Si bien la información es buena para ellos, también es importante reaccionar ante


estos de forma reactiva o proactiva. Azure ofrece una plataforma enriquecida
para tomar grandes datos, procesar y aumentar datos a través de sus abundantes
servicios, almacenarlos en sus grandes sistemas de almacenamiento de datos,
realizar análisis de ellos, generar información y paneles, y luego ejecutar acciones en
función de ello. Estos servicios están disponibles para todos los usuarios de Azure
y proporcionan un abundante ecosistema para crear soluciones. Las empresas están
creando aplicaciones y servicios que transforman completamente a las industrias
debido a la fácil disponibilidad de estos servicios inteligentes de Azure que pueden
combinarse de manera sencilla para generar un valor significativo para los clientes
finales. Azure se aseguró de que aquellos servicios que eran comercialmente
imposibles de implementar por parte de las pequeñas y medianas empresas ahora
pudieran utilizarse e implementarse fácilmente en pocos minutos.

Azure Resource Manager


Azure Resource Manager es la plataforma de tecnología y el servicio de organización
de Microsoft que vincula todos los componentes mencionados anteriormente. Reúne
los proveedores de recursos, los recursos y los grupos de recursos de Azure para
formar una plataforma de nube coherente. Ayuda en el registro de los proveedores
de recursos en las suscripciones y las regiones, hace que los tipos de recursos estén
disponibles para los grupos de recursos, hace que los recursos y las API de recursos
estén accesibles para otros clientes y el portal, y autentica el acceso a los recursos.
También admite características, como el etiquetado, la autenticación, el control
de acceso basado en roles (RBAC), el bloqueo de recursos y el cumplimiento de
directivas para las suscripciones y sus grupos de recursos. Ofrece la misma experiencia
de implementación y administración, ya sea a través de un portal o de herramientas
basadas en el cliente como PowerShell o una interfaz de línea de comandos.

Arquitectura de Azure Resource Manager


La arquitectura de Azure Resource Manager y sus componentes son como se muestran
en la siguiente figura. Como podemos ver, la suscripción a Azure se compone de
varios grupos de recursos. Cada grupo de recursos contiene instancias de recursos que
se crean a partir de tipos de recursos disponibles en el proveedor de recursos.

[8]
Capítulo 1

Arquitectura de Azure Resource Manager

ARM y ASM
ASM tiene restricciones inherentes y aquí se analizan algunas de las principales:
las implementaciones de ASM son lentas y provocan bloqueos. Las operaciones se
bloquean si una operación anterior ya está en marcha:

• Paralelismo: el paralelismo es un desafío en ASM. No es posible ejecutar


correctamente varias transacciones en paralelo. Las operaciones en ASM son
lineales y se ejecutan una tras otra. Se producen errores de funcionamiento
paralelo o se bloquearán las operaciones.
• Recursos: los recursos en ASM se aprovisionan y administran
independientemente unos de otros, no hay ninguna relación entre ellos.
No es posible agrupar los servicios y recursos o configurarlos juntos.
• Servicios en la nube: los servicios en la nube son la unidad de
implementación en ASM. Dependen de grupos de afinidad y no son
escalables debido a su diseño y arquitectura.

No pueden asignarse roles y permisos granulares y discretos a los recursos en ASM. Los
usuarios son administradores de servicios o coadministradores en la suscripción. O bien
tienen control total sobre los recursos, o bien no tienen acceso a ellos en absoluto. ASM
no proporciona soporte de implementación. Las implementaciones pueden ser manuales
o tendrá que recurrir a la escritura de scripts de procedimientos en PowerShell o .NET.

Las API de ASM no guardaban coherencia entre los recursos.

[9]
Introducción

Ventajas de ARM
ARM ofrece ventajas y beneficios claros en comparación con ASM.

• Agrupación: ARM admite la agrupación de recursos en un contenedor


lógico. Estos recursos pueden administrarse juntos y se someten a un ciclo
de vida en común como grupo. Esto facilita la identificación de recursos
relacionados y dependientes.
• Ciclo de vida en común: los recursos de un grupo tienen el mismo ciclo de vida.
Estos recursos pueden evolucionar y administrarse juntos como una unidad.
• Control de acceso basado en roles: se pueden asignar roles y permisos
granulares a recursos, brindando acceso discreto a los usuarios. Los usuarios
pueden tener solo aquellos derechos que se les asignan.
• Soporte de implementación: ARM brinda soporte de implementación en
cuanto a plantillas, habilitando DevOps e infraestructura como código
(IAC). Las implementaciones son más rápidas, coherentes y predecibles.
• Tecnología superior: el costo y la facturación de los recursos se pueden
administrar como una unidad. Cada grupo de recursos puede proporcionar
su propia información de uso y costo.
• Capacidad de administración: ARM ofrece funciones avanzadas, como
por ejemplo, seguridad, monitoreo, auditoría y etiquetado para una mejor
capacidad de administración de recursos. Los recursos se pueden consultar
en función de etiquetas. Además, las etiquetas proporcionan información de
costo y facturación sobre recursos con etiquetas similares.
• Migración: migración y actualización simplificadas de recursos dentro de un
grupo o entre varios.

Conceptos de ARM
Con ARM, todo lo que incluye Azure constituye un recurso. Algunos ejemplos de
recursos son una máquina virtual, interfaces de red, dirección IP pública, cuentas
de almacenamiento y redes virtuales. ARM se basa en conceptos relacionados con
proveedores y consumidores de recursos. Azure ofrece recursos y servicios, a través
de múltiples proveedores de recursos, que se consumen e implementan en grupos.

[ 10 ]
Capítulo 1

Proveedores de recursos
Son servicios encargados de suministrar tipos de recursos a través de Azure Resource
Manager. El concepto más importante de ARM es el de proveedores de recursos. Estos
proveedores son contenedores de tipos de recursos. Los tipos de recursos se agrupan
en proveedores de recursos. Se encargan de implementar y administrar los recursos.
Por ejemplo, un proveedor de recursos llamado Microsoft.Compute Namespace
suministra un recurso del tipo máquina virtual. Se generan versiones de las
operaciones de API REST para distinguirlas entre sí. La designación de las versiones
se basa en las fechas de lanzamiento por parte de Microsoft. Para implementar un
recurso, tiene que haber un proveedor de recursos relacionado disponible para
suscripción. No todos los proveedores de recursos están disponibles para suscripción
desde el primer momento. Si un recurso no está disponible en suscripción, se tiene que
verificar si el proveedor de recursos requerido está disponible en cada región. Si lo
está, el usuario puede registrarse explícitamente en la suscripción.

Tipos de recursos
Constituyen una especificación real del recurso que define que es una interfaz API
pública y su implementación. Implementa el trabajo y las operaciones que admite
el recurso. Al igual que los proveedores de recursos, los tipos de recursos también
evolucionan con el tiempo con respecto a su implementación interna y tienen varias
versiones de su esquema e interfaz API pública. Las denominaciones de las versiones
se basan en sus respectivas fechas de lanzamiento por parte de Microsoft, como versión
preliminar o disponibilidad general (GA). Los tipos de recursos se vuelven disponibles
para suscripción cuando un proveedor de recursos se registra a él. Además, no todos los
tipos de recursos están disponibles en todas las regiones de Azure. La disponibilidad de
un recurso depende de que haya un proveedor de recursos disponible y registrado en una
región de Azure, que tiene que admitir la versión de API necesaria para aprovisionarlo.

Grupos de recursos
Los grupos de recursos son una unidad de implementación en ARM. Son contenedores
que agrupan varias instancias de recursos en una zona de seguridad y gestión demarcada.
A un grupo de recursos se le asigna un nombre exclusivo en una suscripción. Los recursos
se pueden aprovisionar en distintas regiones de Azure y aun así pertenecer al mismo grupo.
Presta servicios adicionales a todos los recursos que contiene. Los grupos de recursos prestan
servicios de metadatos, como por ejemplo, etiquetado, que habilita la categorización de
recursos, la gestión de recursos basada en políticas, RBAC, la protección de recursos contra
eliminación o actualizaciones accidentales, entre otros. Como se mencionó anteriormente,
tienen una zona de seguridad demarcada, y los usuarios que no tienen acceso a un grupo de
recursos no pueden acceder a los recursos incluidos en él. Todas las instancias de recursos
tienen que ser parte de un grupo de recursos, de lo contrario, no pueden implementarse.
[ 11 ]
Introducción

Recurso e instancias de recursos


Los recursos se crean a partir de tipos de recursos y tienen que ser únicos dentro
de un grupo. Su singularidad se define mediante la combinación del nombre y el
tipo de recurso. En lenguaje de programación orientada a objetos, las instancias de
recursos pueden denominarse “objetos”, mientras que los tipos de recursos pueden
denominarse “clase”. Los servicios se consumen a través de las operaciones que
admiten e implementan las instancias de recursos. Definen propiedades que tienen
que configurarse antes de su uso. Algunas propiedades son obligatorias, mientras que
otras son opcionales. Heredan la configuración de seguridad y acceso de su respectivo
grupo principal de recursos. Estas asignaciones heredadas de roles y permisos pueden
sustituirse para cada recurso. Un recurso se puede bloquear de modo que algunas de sus
operaciones no estén disponibles para roles, usuarios y grupos aunque tengan acceso
a él. Pueden etiquetarse para simplificar su detección y capacidad de administración.

Funciones de Azure Resource Manager


A continuación se mencionan algunas de las funciones más importantes que ofrece
Azure Resource Manager:

• Control de acceso basado en roles: Azure Active Directory (AAD) autentica


a los usuarios para brindarles acceso a suscripciones, grupos de recursos
y recursos. ARM implementa OAuth y RBAC dentro de la plataforma, lo
que permite el control de autorizaciones y del acceso a recursos, grupos de
recursos y suscripciones con base en los roles asignados a un usuario o grupo.
Un permiso define el acceso a operaciones sobre un recurso. Estos permisos
podrían permitir o denegar el acceso al recurso. Una definición de rol es una
colección de estos permisos. Los roles asignan a usuarios y grupos de AAD
a los permisos. Los roles posteriormente se asignan a un alcance, que puede
ser individual, colección de recursos, grupo de recursos o suscripción. Las
identidades del AAD (usuarios, grupos y principios de servicios) agregadas
a un rol obtienen acceso al recurso conforme a los permisos definidos en el
rol. ARM brinda varios roles listos para usar. Ofrece roles del sistema, como
por ejemplo, titular, colaborador, lector, etc. Además, brinda roles basados en
recursos, como por ejemplo, colaborador de base de datos de SQL, colaborador
de máquinas virtuales, etc. ARM permite crear roles personalizados.

[ 12 ]
Capítulo 1

• Etiquetas: las etiquetas son pares de nombre-valor que agregan más


información y metadatos a los recursos. Tanto los recursos como los grupos
de recursos pueden contener múltiples etiquetas. Las etiquetas ayudan
a categorizar los recursos para poder mejorar su detección y capacidad de
administración. Los recursos se pueden buscar e identificar rápida y fácilmente.
Se puede buscar información de facturación y costo de recursos que tienen las
mismas etiquetas. Si bien esta función la ofrece ARM, es un administrador de
TI quien define el uso y la taxonomía con respecto a los recursos y grupos de
recursos. Por ejemplo, la taxonomía y las etiquetas se pueden definir en función
de departamentos, uso de recursos, ubicación, proyectos o cualquier otro
criterio que se considere adecuado desde el punto de vista de uso, facturación
o búsqueda. Estas etiquetas posteriormente se pueden aplicar a recursos. Los
recursos no heredan las etiquetas definidas en el nivel de grupo de recursos.
• Políticas: las políticas son otra función de seguridad que ofrece ARM. Se
pueden crear políticas personalizadas para controlar el acceso a los recursos.
Las políticas son convenciones y reglas definidas, y tienen que respetarse al
interactuar con recursos y grupos de recursos. La definición de la política
contiene una denegación explícita de acciones sobre los recursos o el acceso
a estos. De manera predeterminada, se permite todo acceso a menos que
se mencione en la definición de la política. Estas definiciones de políticas
se asignan al alcance de recursos, grupos de recursos y suscripciones. Es
importante tener en cuenta que estas políticas no reemplazan ni sustituyen al
RBAC. De hecho, lo complementan y trabajan en conjunto con él. Las políticas
se evalúan luego de que el AAD autentica al usuario y el servicio de RBAC lo
autoriza. ARM ofrece lenguaje de definición de políticas basado en JSON para
la definición de políticas. Algunos de los ejemplos de definición de políticas
son que tiene que etiquetar a todos los recursos suministrados o que los
recursos solo se pueden suministrar a regiones específicas de Azure.
• Bloqueos: las suscripciones, los grupos de recursos y los recursos se pueden
bloquear para evitar la eliminación y actualizaciones accidentales por parte de un
usuario autenticado. Los bloqueos aplicados a niveles más altos también rigen para
recursos de niveles más bajos. Los bloqueos aplicados en el nivel de suscripción
bloquean a todos los grupos de recursos y a los recursos que contienen.
• Varias regiones: Azure ofrece varias regiones para el aprovisionamiento
y alojamiento de recursos. ARM permite que los recursos se aprovisionen en
distintas ubicaciones y que residan en el mismo grupo de recursos. Un grupo
de recursos puede contener recursos de distintas regiones.

[ 13 ]
Introducción

• Idempotente: esta función garantiza previsibilidad, estandarización y


coherencia en cuanto a la implementación de recursos asegurándose de que
todas las implementaciones generen el mismo estado de recursos con su
respectiva configuración, independientemente de la cantidad de veces que se
ejecuten.
• Extensible: la arquitectura de ARM es extensible para permitir crear y
conectar nuevos proveedores y tipos de recursos en la plataforma.

Virtualización
La virtualización fue una innovación que cambió por completo la forma de ver a los
servidores físicos. Se refiere a la abstracción de un objeto físico en un objeto lógico.

La virtualización de los servidores físicos habilitó la creación de múltiples servidores


virtuales, más conocidos como máquinas virtuales. Estas máquinas virtuales
consumen y comparten el mismo CPU físico, memoria, almacenamiento y otro
hardware con el servidor físico en el que se alojan. Esto permite el aprovisionamiento
más rápido y sencillo de entornos de aplicaciones a petición, ofreciendo alta
disponibilidad y escalabilidad a bajo costo. Un solo servidor físico fue suficiente para
alojar a múltiples máquinas virtuales, cada una con su propio sistema operativo y
servicios de hosting.

Ya no fue necesario adquirir más servidores físicos para el desarrollo de aplicaciones


y servicios nuevos. Los servidores físicos existentes fueron suficientes para alojar más
máquinas virtuales. Además, como parte de la racionalización, muchos servidores
físicos se consolidaron en unos pocos gracias a la virtualización.

Cada máquina virtual contiene el sistema operativo completo y está totalmente


aislada de otras máquinas virtuales, incluso de los hosts físicos. Si bien una máquina
virtual utiliza el hardware provisto por el servidor físico host, tiene pleno control
sobre los recursos que se le asignaron y su entorno. Estas máquinas virtuales
se pueden alojar en una red, como por ejemplo un servidor físico con su propia
identidad.

Azure ayuda a crear máquinas virtuales Linux y Windows en cuestión de minutos.


Microsoft brinda sus propias imágenes junto con imágenes de socios y de la
comunidad. Los usuarios pueden incluir sus propias imágenes. Las máquinas
virtuales se crean utilizando estas imágenes.

[ 14 ]
Capítulo 1

Contenedores
Los contenedores también constituyen una tecnología de virtualización; sin embargo,
no virtualizan a un servidor físico. En cambio, son una virtualización a nivel del
sistema operativo. Esto significa que los contenedores comparten entre sí y con el
host el kernel del sistema operativo que proporciona el host. Los varios contenedores
que se ejecutan en un host (físico o virtual) comparten el kernel del sistema operativo
del host. Los contenedores garantizan la reutilización del kernel del host en lugar de
tener un núcleo dedicado para cada uno.

Además, están totalmente aislados del host y de otros contenedores, como por
ejemplo, una máquina virtual. Los contenedores utilizan controladores de filtros
de almacenamiento de Windows y aislamiento de sesión de servicios del sistema
operativo, como por ejemplo, sistema de archivos, registro, procesos y redes. Cada
contenedor obtiene su propia copia de recursos del sistema operativo.

El contenedor tiene la percepción de que posee un sistema operativo y recursos


totalmente nuevos e intactos. Esta configuración ofrece muchos beneficios, que se
indican a continuación:

• Los contenedores aceleran el aprovisionamiento. No necesitan proporcionar


el sistema operativo ni sus servicios de kernel. Están disponibles desde el
sistema operativo del host.
• Son livianos y requieren menos recursos informáticos en comparación con las
máquinas virtuales. En los contenedores, ya no se requiere la sobrecarga de
recursos del sistema operativo.
• Los contenedores son mucho más pequeños que las máquinas virtuales.
• Ayudan a resolver problemas relacionados con la administración de múltiples
dependencias de la aplicación de manera intuitiva, automatizada y simple.
• Los contenedores brindan infraestructura para definir todas las dependencias
de la aplicación en un solo lugar.

Si bien son una parte y una función fundamental de Windows Server 2016


y Windows 10, su administración y acceso se realiza utilizando un Cliente Docker
y un Demonio Docker. En Azure, los contenedores se pueden crear con la SKU de
Windows Server 2016 como imagen.

[ 15 ]
Introducción

Cada contenedor cuenta con un proceso principal único que se tiene que ejecutar para
que el contenedor exista. El contenedor se detendrá al finalizar este proceso. Además, un
contenedor se puede ejecutar en modo interactivo o en modo independiente como servicio.

Arquitectura de los contenedores

La figura muestra todas las capas técnicas que habilitan contenedores. La capa inferior
brinda la infraestructura central en términos de red, almacenamiento, equilibradores
de carga y tarjetas de red. El nivel más alto de la infraestructura es la capa del equipo,
formada ya sea por un servidor físico o por un servidor físico y uno virtual sobre
un servidor físico. Esta capa contiene el sistema operativo con capacidad de alojar
contenedores. El sistema operativo proporciona el controlador de ejecución que las
capas superiores utilizan para solicitar el código del kernel y los objetos para ejecutar
los contenedores. Microsoft ha creado Host Container System Shim (HCSShim) para
administrar y crear contenedores, y utiliza controladores de filtros de almacenamiento
de Windows para la administración de imágenes y archivos.

Se le proporciona la capacidad de aislar el entorno del contenedor a la sesión de


Windows. Windows Server 2016 y Nano Server brindan el sistema operativo, habilitan
las funciones del contenedor y ejecutan el Cliente Docker y Motor Docker a nivel del
usuario. El Motor Docker utiliza los servicios de HCSShim, los controladores de filtros
de almacenamiento y las sesiones para generar varios contenedores en el servidor,
cada uno con su propio servicio, aplicación o base de datos.

[ 16 ]
Capítulo 1

Docker
El Docker brinda funciones de administración a los contenedores de Windows.
Contiene dos ejecutables:

• Demonio Docker
• Cliente Docker

El Demonio Docker es el caballo de batalla para la administración de contenedores.


Es un servicio de Windows que se encarga de administrar todas las actividades
relacionadas con los contenedores en el host. El Cliente Docker interactúa con el
Demonio Docker y se encarga de capturar entradas y enviarlas hacia el Demonio
Docker. El Demonio Docker brinda el tiempo de ejecución, las bibliotecas, los
controladores gráficos y el motor para crear, administrar y monitorear contenedores
e imágenes en el servidor host. Además, ofrece funciones para crear imágenes
personalizadas que se utilizan para construir y entregar aplicaciones a varios
entornos.

Interacción con la nube inteligente


Azure ofrece varias formas de conectarse a la nube, automatizarla e interactuar
con ella. Todos los métodos exigen la autenticación de usuarios y códigos con
credenciales válidas para poder utilizarlos.

• Portal de Azure
• PowerShell
• Interfaz de línea de comandos (CLI) de Azure
• API REST de Azure

Portal de Azure
El portal de Azure es un buen lugar para comenzar. En el portal de Azure, los usuarios
pueden iniciar sesión y comenzar a crear y administrar recursos de Azure de forma
manual. Brinda una interfaz de usuario intuitiva y fácil de usar a través del navegador.
El portal de Azure ofrece una manera sencilla de navegar hasta los recursos utilizando
hojas. Las hojas muestran todas las propiedades de un recurso, los registros, los costos,
su relación con otros recursos, las etiquetas, las opciones de seguridad, etc. Toda la
implementación de la nube se puede administrar a través del portal.

[ 17 ]
Introducción

PowerShell
PowerShell es un lenguaje de scripts y shell de línea de comandos basado en objetos
que se utiliza para la administración, configuración y gestión de la infraestructura
y los entornos. Se construye por sobre .NET Framework y brinda funciones de
automatización. PowerShell realmente se ha convertido en un elemento de primera
clase entre los administradores de TI y los desarrolladores de automatización para
administrar y controlar el entorno de Windows. En la actualidad, PowerShell puede
administrar prácticamente todos los entornos de Windows y Linux. De hecho,
PowerShell también puede administrar prácticamente todos los aspectos de Azure.
Azure ofrece una buena compatibilidad con PowerShell. Brinda un módulo de
PowerShell para cada proveedor de recursos con cientos de cmdlets. Los usuarios
pueden utilizar estos cmdlets en sus scripts para automatizar la interacción con
Azure. El módulo PowerShell de Azure está disponible a través del instalador de
plataforma web y de la Galería de PowerShell. Windows Server 2016 y Windows 10
ofrecen administración de paquetes y módulos PowerShellGet que permiten
descargar e instalar los módulos de PowerShell de forma rápida y sencilla desde la
galería de PowerShell. El módulo PowerShellGet proporciona el cmdlet del Módulo
de instalación para la descarga e instalación de módulos en el sistema. Para
instalar un módulo, simplemente es necesario copiar los archivos del módulo en
ubicaciones del módulo bien definidas:
Módulo de importación PowerShellGet
Módulo de instalación-nombre AzureRM-detallado

Interfaz de línea de comandos (CLI) de Azure


Azure también proporciona Azure CLI 2.0 que se puede implementar en sistemas
operativos Linux, Windows y Mac. Azure CLI 2.0 es la nueva utilidad de línea
de comandos de Azure para administrar recursos de Azure. Azure CLI 2.0 se ha
optimizado para gestionar y administrar los recursos de Azure desde la línea de
comandos y para crear scripts de automatización que funcionan con Azure Resource
Manager. La interfaz de línea de comandos puede utilizarse para ejecutar comandos
usando Bash Shell o la línea de comandos de Windows. Azure CLI es un usuario
muy famoso que no es de Windows, ya que nos permite comunicarnos con Azure en
Linux y Mac. Los pasos para instalar Azure CLI 2 se encuentran en https://docs.
microsoft.com/es-es/cli/azure/install-azure-cli?view=azure-cli-latest.

[ 18 ]
Capítulo 1

API REST de Azure


Todos los recursos de Azure están expuestos a los usuarios a través de los puntos
de conexión REST. Las API Transferencia de Estado Representacional (REST) son
puntos de conexión de servicio que implementan operaciones HTTP (métodos),
proporcionando acceso del tipo crear, obtener, actualizar o eliminar (CRUD) a los
recursos del servicio. Los usuarios pueden utilizar estas API para crear y administrar
recursos. De hecho, el mecanismo de CLI y PowerShell utiliza estas API REST
internamente para interactuar con recursos de Azure.

Plantillas de Azure Resource Manager


En una sección anterior, abordamos funciones de implementación, tales como
multiservicio, varias regiones, extensible e idempotente, que ofrece ARM. Las
plantillas de ARM son el medio principal de aprovisionamiento de recursos en ARM.
Brindan soporte para la aplicación de funciones de implementación de ARM.

Proporcionan un modelo declarativo mediante el cual se especifican los recursos,


su configuración, los scripts y las extensiones. Las plantillas de ARM se basan en
el formato JavaScript Object Notation (JSON). Utilizan la sintaxis y convenciones
JSON para declarar y configurar recursos. Los archivos JSON están basados en texto,
son intuitivos y fáciles de leer.

Se pueden guardar en un repositorio de código fuente y cuentan con control de


versiones. Además, constituyen un medio para representar la IAC que se puede
utilizar para suministrar recursos en un grupo de recursos de Azure una y otra
vez, de manera previsible, coherente y uniforme. Una plantilla necesita un grupo
de recursos para la implementación. Solo se puede implementar en un grupo de
recursos, el cual tiene que existir antes de ejecutar la implementación de la plantilla.
Una plantilla no puede crear un grupo de recursos.

Las plantillas ofrecen la flexibilidad de diseño e implementación genéricos y modulares.


Brindan la capacidad de aceptar parámetros de los usuarios, declarar variables internas,
ayudar a definir dependencias entre recursos, vincular recursos dentro del mismo grupo
o de distintos grupos y ejecutar otras plantillas. Además, brindan expresiones del tipo
de lenguaje de scripting y funciones que las hacen dinámicas y personalizables en el
momento de ejecución.

[ 19 ]
Introducción

Implementaciones
PowerShell admite dos modos de implementación de plantillas:

• Gradual
• Completa

La implementación gradual agrega recursos declarados en la plantilla que no existen


en un grupo de recursos, no modifica recursos en un grupo de recursos que no forma
parte de la definición de una plantilla ni los que existen tanto en la plantilla como en
el grupo de recursos con el mismo estado de configuración.

La implementación completa, por otra parte, agrega recursos declarados en una


plantilla al grupo de recursos, elimina recursos del grupo que no existen en la
plantilla y no modifica recursos que existen tanto en el grupo de recursos como en la
plantilla con el mismo estado de configuración.

Resumen
La nube no tiene más de 10 años de antigüedad. Es un paradigma nuevo que aún se
encuentra en su etapa inicial. Con el tiempo, se incorporarán muchísimas innovaciones
y funciones. En la actualidad, Azure es uno de los principales proveedores de nube y brinda
innumerables funciones a través de IaaS, PaaS, SaaS e implementaciones híbridas. De hecho,
pronto se lanzará Azure Stack, que es una implementación de nube privada de Microsoft.
Ofrecerá las mismas funciones disponibles de una nube pública en una privada. De hecho,
las dos se conectarán y funcionarán conjuntamente de manera fluida y transparente. Si bien
es muy sencillo comenzar a utilizar Azure, los desarrolladores y los arquitectos pueden
caer en una trampa si no diseñan y planifican bien sus soluciones. La intención de este libro
es brindar orientación e instrucciones que apunten al diseño correcto de soluciones con
servicios y recursos apropiados. Todos los servicios de Azure constituyen un recurso. Es
importante comprender el modo en el que estos recursos se organizan y se administran en
Azure. Este capítulo brinda contexto sobre Azure Resource Manager y los grupos, el marco
fundamental que aporta los elementos básicos para los recursos. Proporciona un conjunto
de servicios a los recursos que ayuda a aportar uniformidad, estandarización y coherencia
respecto a su administración. Los servicios, como por ejemplo RBAC, etiquetas, políticas,
bloqueos, etc., están disponibles para todos los recursos y proveedores de recursos. Además,
Azure ofrece innumerables funciones de automatización para automatizar los recursos e
interactuar con ellos. Herramientas tales como PowerShell, plantillas de ARM y Azure CLI
se pueden incorporar como parte de los canales de lanzamiento y de implementación y
entrega continua. Los usuarios se pueden conectar a Azure desde entornos heterogéneos
utilizando estas herramientas de automatización.

En el próximo capítulo se abordarán algunos de los patrones importantes que ayudan


a resolver problemas comunes de implementaciones basadas en la nube y a garantizar la
seguridad, disponibilidad, escalabilidad y mantenimiento de la aplicación a largo plazo.
[ 20 ]
Patrones de diseño de Azure
En el capítulo anterior, vimos un resumen de la nube de Azure y explicamos algunos
de los conceptos importantes relacionados con ella. En este capítulo se abarcan
los patrones de la nube de Azure relacionados con las redes virtuales, las cuentas
de almacenamiento, las regiones y los conjuntos de disponibilidad. Estas son
construcciones importantes que afectan la arquitectura final que se ofrece a los
clientes en términos de costo, eficiencia y productividad general. En este capítulo
también se analizarán brevemente patrones de nube que ayudan a implementar la
escalabilidad y el rendimiento dentro de la estructura general.

En este capítulo, trataremos los siguientes temas:

• Diseño de la red virtual de Azure


• Diseño de almacenamiento de Azure
• Conjuntos de disponibilidad, zonas y regiones de Azure
• Patrones de diseño de Azure relacionados con lo siguiente:

°° Envío de mensajes
°° Rendimiento
°° Escalabilidad

Zonas y regiones de Azure


La nube de Azure está respaldada por grandes centros de datos interconectados en
una única gran red. Los centros de datos se agrupan en función de su proximidad
física a las regiones de Azure. Por ejemplo, un par de centros de datos en Europa
occidental están disponibles en conjunto para los usuarios de Azure como la región
de Europa occidental. Los usuarios no pueden controlar cuál es el centro de datos
exacto para su implementación. Pueden informar a Azure sobre la región y Azure
elegirá un centro de datos adecuado.

[ 21 ]
Patrones de diseño de Azure

Elegir una región adecuada es una decisión arquitectónica importante que afecta lo
siguiente:

• La disponibilidad de recursos
• Los datos y el cumplimiento de la privacidad
• El rendimiento de las aplicaciones
• El costo de ejecutar las aplicaciones

La disponibilidad de recursos
No todos los recursos están disponibles en todas las regiones de Azure. Si la
arquitectura de aplicaciones exige un recurso y no está disponible en una región,
elegir esa región no ayudará. En cambio, es necesario elegir una región en función de
la disponibilidad de todos los recursos requeridos por la aplicación. Podría suceder
que el recurso no esté disponible mientras se desarrolla la arquitectura de aplicación
y que sí figure en la hoja de ruta de Azure para estar disponible posteriormente.

Por ejemplo, los análisis de registro no están disponibles en todas las regiones.
La transferencia de datos a los análisis de registro incurriría en costos de red de
salida si se implementa la aplicación en una región que no tiene análisis de registro
(anteriormente conocido como conjunto de administración operativa). Del mismo
modo, Azure Key Vault proporciona servicios solo a los recursos que se encuentran
colocalizados en la misma región. Otro ejemplo es que una red virtual Azure puede
hospedar máquinas virtuales y equilibradores de carga de las mismas regiones. Las
máquinas virtuales de diferentes regiones no pueden ser parte de la misma red virtual.

Los datos y el cumplimiento de la privacidad


Cada país tiene sus propias reglas para el cumplimiento de la privacidad y los datos.
Algunos países son muy específicos y sus datos y los de sus ciudadanos no pueden
almacenarse en ningún otro país. Estos son requisitos legales y tienen que tomarse
en cuenta arquitectónicamente para una aplicación.

El rendimiento de las aplicaciones


El rendimiento de una aplicación depende de la ruta de la red que tomaron las
solicitudes y respuestas de los usuarios. Si una región de Azure está cerca de los
usuarios de la aplicación, estos tendrán un mejor rendimiento de la aplicación
en comparación con los usuarios lejos de la región de Azure. Una aplicación
implementada en Europa occidental para los usuarios en el sudeste asiático no
tendrá un rendimiento tan bueno como una aplicación para estos mismos usuarios
implementada en el este de Asia.
[ 22 ]
Capítulo 2

El costo de ejecutar las aplicaciones


El costo de los servicios de Azure difiere de una región a otra. Es necesario elegir una
región con un costo total más barato. En este libro, hay un capítulo completo sobre
la administración de costos que tiene que consultar para obtener más información
detallada desde la perspectiva de costos.

Red virtual
Una red virtual tiene que considerarse como una red LAN física en su oficina
u hogar. Conceptualmente, ambas son lo mismo, aunque la red virtual Azure se
implementa como una red definida por software, respaldada por una enorme
infraestructura de red física.

Se necesita una red virtual para hospedar una máquina virtual. Proporcionan un
mecanismo de comunicación seguro entre los recursos de Azure para conectarse
entre sí. Proporcionan una dirección IP interna, acceso y conectividad a otros
recursos como máquinas virtuales en la misma red virtual, enrutamiento de
solicitudes y conectividad a otras redes.

Una red virtual está contenida dentro de un grupo de recursos y está hospedada
dentro de una región, por ejemplo, Europa occidental. Una red virtual no puede
abarcar varias regiones, pero puede incluir todos los centros de datos en una región.
Para tener conectividad en todas las regiones, las redes virtuales pueden conectarse
mediante la conectividad de VNET a VNET. La red virtual también ayuda a conectar
centros de datos locales, lo que habilita la nube híbrida. Hay varios tipos de
tecnologías VPN disponibles para conectarse a centros de datos locales como VPN de
sitio a sitio y VPN de punto a sitio. Existe también una conexión exclusiva disponible
entre la red virtual de Azure y la red local con ExpressRoute.

Una red virtual es gratuita. Cada suscripción puede crear hasta 50 redes virtuales en
todas las regiones. Sin embargo, es posible contactarse con el soporte de Azure para
aumentar este número. La transferencia de datos dentro de una VNET no tendrá
costo.

La información sobre límites de red se encuentra disponible en


https://docs.microsoft.com/es-es/azure/azure-
subscription-service-limits#networkhttps://docs.

[ 23 ]
Patrones de diseño de Azure

Consideraciones arquitectónicas para las


redes virtuales
Como cualquier otro recurso, las redes virtuales pueden aprovisionarse con plantillas
de ARM, API REST, PowerShell y CLI. Es muy importante planificar la topología
de red en la etapa inicial para evitar problemas posteriores en el ciclo de vida de
desarrollo. Esto sucede porque una vez que se aprovisiona la red y los recursos
comienzan a utilizarla, es difícil realizar cambios sin provocar tiempo de inactividad.
Por ejemplo, trasladar una máquina virtual de una red a otra requerirá apagar la
máquina virtual.

• Regiones: la red virtual es un recurso de Azure y se aprovisiona dentro


de una región como Europa occidental. Las aplicaciones que abarcan
varias regiones necesitarán redes virtuales separadas, una por cada región,
y también tienen que estar conectadas mediante la conectividad de VNET
a VNET. Hay un costo asociado con la conectividad de VNET a VNET para
tráfico entrante y saliente. Sin embargo, en una red sin conectividad de
VNET a VNET, no hay cargos para los datos entrantes (ingreso): los cargos
están asociados con los datos salientes únicamente. Asimismo, no hay ningún
cargo por los datos transferidos dentro de la red virtual.
• DNS dedicado: de forma predeterminada, las redes virtuales utilizan el
DNS proporcionado por Azure para resolver los nombres dentro de una
red virtual. Este también permite la resolución de nombres en Internet. Si la
aplicación quiere un servicio de resolución de nombres dedicado o conectarse
a los centros de datos locales, tiene que proporcionar su propio servidor
DNS, y los centros de datos locales tienen que configurarse dentro de la red
virtual para una correcta resolución de nombres.
• Rendimiento de la red: cada red virtual tiene un rendimiento definido.
Es recomendable crear una red virtual independiente para tener un
rendimiento constante en vez de colocar todos recursos relacionados con
la red en una única red. Esto podría obstruir la red.
• Cantidad de redes virtuales: la cantidad de redes virtuales se ve afectada por
la cantidad de regiones, el uso del ancho de banda por parte de los servicios,
la conectividad entre regiones y la seguridad.
• Cantidad de subredes en cada red virtual: las subredes proporcionan
aislamiento dentro de una red virtual. También es un límite de seguridad.
Los grupos de seguridad de red pueden estar asociados con subredes y, de
ese modo, restringir o permitir el acceso específico a puertos y direcciones IP.
Los componentes de las aplicaciones con requisitos de seguridad y
accesibilidad independientes tienen que colocarse en subredes separadas.

[ 24 ]
Capítulo 2

• Intervalos IP para redes y subredes: cada subred tiene un rango IP. El rango


IP no tiene que ser demasiado grande como para ser subutilizado mientras
que otras subredes se ven desbordadas por la falta de direcciones IP. Tiene
que tener suficientes direcciones IP para cumplir con los requisitos actuales
y futuros. Es necesario evaluar esto luego de comprender las necesidades
futuras de direcciones IP de la implementación.
°° Es necesario planificar la asignación de direcciones y rangos IP para
las redes, subredes y centros de datos locales de Azure. No tiene que
haber una superposición para una conectividad y accesibilidad sin
inconvenientes.
• Supervisión: la supervisión es una faceta arquitectónica importante y un
elemento imprescindible que resulta necesario incluir en la arquitectura de
implementación general. Azure Network Watcher ofrece capacidades de
registro y diagnóstico con conocimientos del estado y el rendimiento de la
red. Ofrece capacidades para ver paquetes entrantes o salientes hacia y desde
las máquinas virtuales, ya sean permitidos o denegados, el flujo de siguiente
salto para validar la configuración de las rutas definidas por el usuario,
una auditoría de seguridad de red, la captura de paquetes junto con los
límites de suscripción. También proporciona registros de diagnóstico para
todos los recursos de red en un grupo de recursos.
El rendimiento de la red puede supervisarse a través de los análisis de
registro. La solución de administración de la supervisión del rendimiento de
red proporciona una capacidad de supervisión de la red. Supervisa el estado,
la disponibilidad y la accesibilidad de las redes. También se utiliza para
supervisar la conectividad entre las nubes pública y local y las subredes que
hospedan varios niveles de una aplicación de varios niveles.
• Consideraciones de seguridad: las redes virtuales son uno de los primeros
componentes a los que accede cualquier recurso en Azure. La seguridad
desempeña un papel importante en permitir o denegar el acceso al recurso.
Los grupos de seguridad de red (NSG) son el medio principal para habilitar
la seguridad en las redes virtuales. Pueden adjuntarse a subredes de redes
virtuales, en cuyo caso se restringe, se filtra y se habilita cada flujo entrante
y saliente de estas.
El enrutamiento definido por el usuario (UDR) y el reenvío IP también
ayudan a filtrar y enrutar solicitudes a los recursos en Azure.

Puede obtener más información sobre el UDR y la tunelización forzada


en https://docs.microsoft.com/es-es/azure/virtual-
network/virtual-networks-udr-overview..

[ 25 ]
Patrones de diseño de Azure

Los recursos también pueden asegurarse y protegerse mediante la implementación


de dispositivos de red como barracuda, F5 y otros componentes de terceros.

Puede obtener más información sobre ellos en https://azure.


microsoft.com/es-es/solutions/network-appliances/.

• Implementación: las redes virtuales tienen que implementarse en sus


propios grupos de recursos dedicados. Los administradores de red
necesitan permiso de propietario en este grupo de recursos, mientras
que los desarrolladores o los miembros del equipo necesitan permisos
de colaborador para poder crear otro recurso de Azure en otros grupos
de recursos que utilizan servicios de la red virtual.

También es recomendable implementar recursos con direcciones IP estáticas en una


subred dedicada, mientras que los recursos relacionados con dirección IP dinámica
pueden estar en otra subred.

Las políticas tienen que crearse de modo que solo los administradores de red puedan
eliminar la red virtual, y esta también tiene que estar etiquetada a los fines de
facturación.

• Conectividad: los recursos de una región en una red virtual pueden


comunicarse sin inconvenientes. Incluso los recursos en otras subredes
dentro de una red virtual pueden comunicarse entre sí sin necesidad de
ninguna configuración explícita. Los recursos en varias regiones no pueden
utilizar la misma red virtual. El límite de una red virtual se encuentra
dentro de una región. Para que los recursos estén disponibles entre regiones,
comuníquese con cada gateway dedicado, lo cual es necesario en cada
extremo para facilitar la conversación. Las redes en cada extremo están
conectadas a otras redes a través de estos gateways.

Sin embargo, los recursos en Azure a veces también tienen necesidades de


conectividad con los centros de datos locales. Las redes virtuales de Azure pueden
conectarse a centros de datos locales con la tecnología VPN y ExpressRoute. De
hecho, una red virtual puede conectarse a varios centros de datos locales y otras
regiones de Azure en paralelo. Como procedimiento recomendado, cada una de estas
conexiones tiene que estar en sus subredes dedicadas dentro de una red virtual.

[ 26 ]
Capítulo 2

Beneficios de las redes virtuales


Las redes virtuales son un elemento indispensable para implementar cualquier
solución IaaS significativa. No se puede aprovisionar máquinas virtuales sin redes
virtuales. Además de ser casi un componente obligatorio en las soluciones, ofrece
grandes ventajas arquitectónicas, entre las que se destacan las siguientes:

• Aislamiento: la mayoría de los componentes de la aplicación tienen distintos


requisitos de seguridad y ancho de banda, y una administración diferente del
ciclo de vida. Las redes virtuales ayudan en la creación de sectores aislados
para estos componentes que pueden administrarse independientemente de
otros componentes con la ayuda de las redes y subredes virtuales.
• Seguridad: filtrar y realizar un seguimiento de quién accede a los recursos
es una característica importante que proporcionan las redes virtuales. Estas
pueden detener el acceso a un puerto y una dirección IP maliciosos.
• Extensibilidad: las redes virtuales actúan como una red LAN privada en la
nube. También puede extenderse a WAM conectando otras redes virtuales en
todo el mundo y puede extenderse a los centros de datos locales como una
extensión.

Diseño de la red virtual


En esta sección, evaluaremos algunos de los diseños populares y el uso de redes
virtuales.

Puede haber varios usos de las redes virtuales. Un gateway puede implementarse en
cada extremo de la red virtual para permitir la seguridad y transmitir paquetes con
integridad y confidencialidad. Un gateway es imprescindible al conectarse a redes
locales; sin embargo, es opcional al usar el emparejamiento de red virtual.

[ 27 ]
Patrones de diseño de Azure

Conexión a los recursos dentro de la misma región


y suscripción
Es posible conectar entre sí varias redes virtuales dentro de la misma región
y suscripción. Con la ayuda del emparejamiento de red virtual, ambas redes pueden
conectarse y utilizar la red troncal privada de Azure para la transmisión de paquetes
entre sí. Las máquinas virtuales y los servicios en estas redes pueden comunicarse
entre sí, sujetos a las limitaciones del tráfico de red:

Conexión a los recursos dentro de la misma región


en otra suscripción
Este uso es muy parecido al anterior; sin embargo, la complejidad adicional es que
la otra red se encuentra en otra suscripción. Si ambas suscripciones pertenecen al
mismo inquilino, entonces pueden conectarse mediante el emparejamiento de red
virtual analizado anteriormente. También utilizaría la red troncal privada de Azure
para la transmisión de paquetes entre sí:

[ 28 ]
Capítulo 2

Conexión a los recursos en diferentes regiones en


otra suscripción
En este escenario, el tráfico pasará a través de la red pública y el emparejamiento de red
virtual tiene que implementarse junto con los gateways para cifrar el tráfico con VPN:

Conexión a centros de datos locales


Las redes virtuales pueden conectarse a centros de datos locales de modo que tanto
Azure como un centro de datos local se conviertan en una sola red de área extensa
(WAN). La conexión de una red local requiere de la implementación en gateways
y redes privadas virtuales en ambos lados de la red.

[ 29 ]
Patrones de diseño de Azure

Existen tres tecnologías diferentes disponibles para este propósito:

• VPN de sitio a sitio: tiene que utilizarse cuando la red Azure y la local
necesitan conectarse para formar una WAN en la que cualquier recurso en
ambas redes pueda acceder a cualquier otro recurso independientemente
de Azure o un centro de datos local. Es necesario que los gateways de VPN
estén disponibles en ambos lados de las redes por motivos de seguridad.
Asimismo, los gateways de Azure tienen que implementarse en sus propias
subredes en la red virtual que se conecta a los centros de datos locales.
Las direcciones IP públicas tienen que asignarse a gateways locales para
que Azure se conecte mediante la red pública.

• VPN de punto a sitio: es similar a conectividad VPN de sitio a sitio;


no obstante, hay un único servidor o equipo conectado al centro de datos
local. Tiene que utilizarse cuando haya muy pocos usuarios o clientes que
se conectan a Azure de manera segura desde ubicaciones remotas. Además,
no se requiere un gateway o IP pública en la parte local en este caso:

[ 30 ]
Capítulo 2

• ExpressRoute: las VPN de sitio a sitio y de punto a sitio funcionan con la


Internet pública. Cifran el tráfico entre la red mediante el uso de VPN y la
tecnología de certificados. Sin embargo, hay aplicaciones que se implementan
de modo híbrido. Algunos de sus recursos están hospedados en Azure
y otros en el centro de datos local. Aunque los recursos estén hospedados
en Azure, no tienen que utilizar la Internet pública para la conectividad a un
centro de datos local. Azure ExpressRoute es la mejor solución para ellos,
aunque una opción costosa en comparación con la conectividad VPN de
sitio a sitio y de punto a sitio. Es una conectividad muy segura y confiable
que ofrece una velocidad mucho mayor y menor latencia en comparación
con otras tecnologías VPN. Esto sucede porque el tráfico nunca utiliza la
Internet pública, sino más bien utiliza conexiones dedicadas con proveedores
de servicios. Azure ExpressRoute ayuda a ampliar las redes locales a Azure
mediante una conexión privada dedicada que facilita un proveedor de
conectividad:

[ 31 ]
Patrones de diseño de Azure

En la siguiente figura, se muestran los tres tipos de redes híbridas:

Se recomienda que las redes virtuales tengan subredes independientes para cada
componente lógico que tenga implementaciones independientes desde la perspectiva
de seguridad y aislamiento.

Almacenamiento
Azure proporciona soluciones de almacenamiento duraderas, altamente disponibles
y escalables a través de los servicios de almacenamiento.
El almacenamiento se utiliza para conservar datos para necesidades a largo plazo.
El almacenamiento de Azure está disponible a través de Internet desde casi cualquier
lenguaje de programación.
[ 32 ]
Capítulo 2

Categorías de almacenamiento
El almacenamiento tiene dos categorías de las cuentas de almacenamiento:
• Un nivel estándar de rendimiento del almacenamiento que le permite
almacenar tablas, colas, archivos, blobs y discos de máquina virtual de Azure.
• Un nivel premium de rendimiento del almacenamiento que admite discos de máquina
virtual de Azure en el momento de la escritura. Un almacenamiento prémium
proporciona un mayor rendimiento e IOPS en comparación con el almacenamiento
general estándar. El almacenamiento premium está disponible actualmente como
discos de datos, dado que las máquinas virtuales están respaldadas por SSD.

Tipos de almacenamiento
Azure proporciona cuatro tipos de servicios de almacenamiento general como se
muestra en el siguiente diagrama:

• Almacenamiento de blobs: este tipo de almacenamiento es más apropiado


para datos no estructurados, como documentos, imágenes y otros tipos de
archivos. El almacenamiento de blobs puede ser activo o inactivo. “Activo”
significa que se accede con frecuencia al contenido en el almacenamiento de
blobs en comparación con el nivel inactivo.
• Almacenamiento de tablas: es un almacén de datos de atributo de claves NoSQL.
Tiene que usarse para datos estructurados. Los datos se almacenan como entidades.
• Almacenamiento de colas: proporciona un almacenamiento de mensajes confiable.
• Almacenamiento de archivos: es almacenamiento compartido basado en el
protocolo SMB. Se utiliza normalmente para almacenar y compartir archivos.
Esto también almacena datos no estructurados, pero la diferencia principal
es que puede compartirse en el protocolo SMB. Estos cuatro tipos de
almacenamiento satisfacen distintos requisitos arquitectónicos y cubren casi
todos los tipos de instalaciones de almacenamiento de datos.

[ 33 ]
Patrones de diseño de Azure

Características de almacenamiento
El almacenamiento de Azure es elástico. Esto significa que puede almacenar tan
poco como algunos megabytes o tanto como petabytes de datos. No necesita
bloquear previamente la capacidad, aumentará y se reducirá automáticamente.
Los consumidores solo tienen que pagar por el uso real de almacenamiento.
El almacenamiento de Azure es seguro. Solo se puede acceder mediante el protocolo SSL.
Por otra parte, es necesario autenticar el acceso. El almacenamiento de Azure proporciona
la facilidad de generar un token de firma de acceso seguro (SAS) en el nivel de la cuenta
que pueden utilizar los clientes de almacenamiento para autentificarse. También es
posible generar tokens de SAS individuales de nivel de servicio para blobs, colas, tablas
y archivos. Pueden cifrarse los datos almacenados en el almacenamiento de Azure. Esto
se conoce como proteger los datos en reposo. El cifrado de discos de Azure se utiliza para
cifrar el SO y los discos de datos en máquinas virtuales de IaaS. Cifrado de clientes (CSE)
y cifrado de servicio de almacenamiento (SSE): ambos se utilizan para cifrar los datos
en el almacenamiento de Azure. El SSE es un ajuste de toda la cuenta de almacenamiento
que garantiza que el motor de almacenamiento cifra los datos al escribirlos en el
almacenamiento y los descifra al leerlos. Esto asegura que no se requieran cambios en la
aplicación para activar el SSE. En el CSE, las aplicaciones cliente pueden utilizar el SDK de
almacenamiento para cifrar los datos antes de enviarlos y escribirlos en el almacenamiento
de Azure. La aplicación cliente puede descifrarlo más adelante durante la lectura. Esto
ofrece protección tanto para los datos en tránsito como para aquellos en reposo. El CSE
depende de los secretos de Azure Key Vault. Existe otro servicio que el cifrado de discos
de Azure utilizó para cifrar el SO y los discos de datos en máquinas virtuales de IaaS.
El almacenamiento de Azure tiene disponibilidad alta y es muy duradero.
Esto significa que Azure siempre mantiene varias copias de las cuentas de Azure.
La ubicación y la cantidad de copias dependen de la configuración de replicación.
Azure ofrece cuatro ajustes de replicación. Estos ajustes tienen implicancias en el costo,
así como en la disponibilidad durante el desastre. El almacenamiento redundante en el
nivel local es el más económico y proporciona la menor disponibilidad en comparación
con otros, mientras que el almacenamiento con redundancia geográfica con acceso de
lectura es el más costoso y ofrece una gran disponibilidad.
• Almacenamiento redundante en el nivel local: el almacenamiento redundante
en el nivel local (LRS) se replica y mantiene tres copias del almacenamiento
en el mismo centro de datos de una región. Esto significa que los datos están
altamente disponibles dentro de un centro de datos únicamente. Se perderá el
almacenamiento o no estará disponible si por alguna razón este centro de datos
queda inactivo. Sigue el patrón sincrónico para operaciones de escritura, lo que
significa que escribir a todas las réplicas se considera un éxito. Una solicitud de
escritura se completa correctamente solo después de escribirse en las tres réplicas.
Sin embargo, Azure garantiza la tolerancia a errores desde la perspectiva de
disco y de rack de almacenamiento. Lo hace mediante la colocación de las tres
réplicas en diferentes dominios de error y actualización. Los dominios de error
y actualización se analizarán en detalle en el capítulo siguiente.

[ 34 ]
Capítulo 2

• Almacenamiento redundante en el nivel regional: el almacenamiento


redundante en el nivel regional (ZRS) es más costoso que el almacenamiento
redundante en el nivel local porque aparte de las tres copias en el mismo centro
de datos, también almacena los datos en otro centro de datos dentro de una
región. Dado que están involucrados varios centros de datos, para mantener
el rendimiento y la latencia, SLA escribe en todos los almacenamientos de
forma asincrónica.
• Almacenamiento con redundancia geográfica: el almacenamiento con
redundancia geográfica (GRS) ofrece una mejor durabilidad y disponibilidad
en comparación con el almacenamiento redundante en el nivel regional al
replicar el almacenamiento a otra región además de la redundancia local.
También es una de las opciones más costosas, pero ofrece recuperación ante
desastres en el nivel regional.
• Almacenamiento con redundancia geográfica con acceso de lectura:
el almacenamiento con redundancia geográfica con acceso de lectura
(RAGRS) es similar a la redundancia geográfica, pero además brinda acceso
de solo lectura a las réplicas.

Consideraciones arquitectónicas para las


cuentas de almacenamiento
La cuenta de almacenamiento tiene que aprovisionarse dentro de la misma región
que la de otros componentes de la aplicación. Esto ayudaría en la utilización de
la misma red troncal del centro de datos sin incurrir en cargos de red.
Cada uno de los servicios de almacenamiento de Azure tiene objetivos de escalabilidad
para la capacidad (GB), velocidad de transacciones y ancho de banda. Una cuenta
de almacenamiento general permite el almacenamiento de 500 TB de datos. Si es
necesario almacenar más de 500 TB de datos, entonces es necesario crear varias
cuentas de almacenamiento o utilizar el almacenamiento premium. El almacenamiento
general tiene un rendimiento máximo de 20 000 IOPS o 60 MB de datos por segundo.
Se regulará cualquier requisito de más IOPS o datos administrados por segundo.
Si esto no es suficiente para las aplicaciones desde la perspectiva del rendimiento, será
necesario utilizar el almacenamiento premium o varias cuentas de almacenamiento.
El tamaño de una máquina virtual determina el tamaño y la capacidad de los
discos de datos disponibles. Mientras que las máquinas virtuales de mayor tamaño
tienen discos de datos con mayor capacidad de IOPS, la capacidad máxima seguirá
estando limitada a 20 000 IOPS y 60 MB por segundo. Estas son cantidades máximas,
por lo que, en general, será necesario tener en cuenta niveles inferiores al finalizar
la arquitectura de almacenamiento.
Las cuentas de almacenamiento Azure tienen que habilitarse para la autenticación
mediante tokens de SAS. No tienen que permitirse para el acceso anónimo. Por otra
parte, para el almacenamiento de blobs, es necesario crear diferentes contenedores con
tokens de SAS independientes generados en función de los diferentes tipos y categorías
de clientes que acceden a los contenedores. Estos tokens de SAS tienen que regenerarse
periódicamente para garantizar que nadie pueda adivinar o descifrar las claves.

[ 35 ]
Patrones de diseño de Azure

En general, los blobs que se recuperan para las cuentas de almacenamiento de blobs
tienen que almacenarse en la memoria caché, y puede determinarse que los datos en
una memoria caché están obsoletos al comparar la última propiedad modificada del
blob para volver a recuperar el blob más reciente.

La cuenta de almacenamiento de Azure ofrece características de concurrencia para


garantizar que varios usuarios no modifiquen simultáneamente los mismos archivos
y datos. Ofrece lo siguiente:
• Concurrencia optimista: permite que varios usuarios modifiquen datos
simultáneamente, pero durante la escritura verifica si han cambiado el
archivo o los datos. Si lo han hecho, se notifica a los usuarios que vuelvan
a recuperar los datos y realicen la actualización nuevamente. Esta es la
concurrencia predeterminada para el servicio de tablas.
• Concurrencia pesimista: cuando una aplicación intenta actualizar
un archivo, coloca un bloqueo que rechaza explícitamente cualquier
actualización de otros usuarios. Esta es la concurrencia predeterminada para
los servicios de archivos cuando se accede mediante el protocolo SMB.
• El último en escribir gana: en este caso, las actualizaciones no están
limitadas, y el último usuario actualiza el archivo independientemente de la
lectura inicial. Esta es la concurrencia predeterminada para los servicios de
colas, blobs y archivos (cuando se accede mediante REST).

Patrones de diseño
Los patrones de diseño son soluciones comprobadas a problemas de diseño conocidos.
Son soluciones reutilizables que se pueden aplicar a los problemas. No son códigos
o diseños reutilizables que pueden incorporarse, como están, dentro de una solución.
Son descripciones documentadas y orientación para resolver un problema. El problema
podría manifestarse en un contexto diferente, y los patrones de diseño pueden ayudar
a resolverlo. Azure ofrece numerosos servicios, y cada servicio ofrece una característica
y capacidad específica. Utilizar estos servicios es sencillo, pero crear soluciones
reuniendo varios servicios puede ser un desafío. Por otra parte, lograr una alta
disponibilidad, superescalabilidad, fiabilidad, rendimiento y seguridad para una
solución no es una tarea menor. Los patrones de diseño de Azure ofrecen soluciones
listas a estos problemas y otras que pueden hacerse a medida de las soluciones
individuales. Ayudan a buscar soluciones altamente disponibles, escalables, confiables
y centradas en el rendimiento en Azure. Aunque hay muchos patrones y algunos de ellos
se tratan en detalle en los siguientes capítulos, en este capítulo se mencionan algunos de
los patrones de mensajería, rendimiento y escalabilidad. Además, se proporcionan
enlaces para obtener una descripción detallada de estos patrones. Estos patrones de
diseño merecen un libro completo por sí mismos. Se mencionan aquí para que los
lectores los conozcan y se proporcionan enlaces para obtener información más detallada.

[ 36 ]
Capítulo 2

Patrones de mensajería
Los patrones de mensajería ayudan a conectar los servicios con un acoplamiento
flexible. Lo que significa es que los servicios nunca se comunican entre sí
directamente. En cambio, un servicio genera y envía un mensaje a un agente
(generalmente, una cola), y cualquier otro servicio interesado en ese mensaje puede
recogerlo y procesarlo. No hay ninguna comunicación directa entre los servicios del
remitente y del receptor. Este desacoplamiento no solo hace que los servicios y la
aplicación en general sean más confiables, sino también más fuertes y tolerantes
a errores. Los receptores pueden recibir y leer mensajes a su propia velocidad.

La mensajería ayuda a crear patrones asincrónicos. Implica el envío de mensajes


desde una entidad a otra. Estos mensajes los crea y envía un remitente, se almacenan
en un almacenamiento duradero y, por último, los utilizan los destinatarios.

Las principales preocupaciones arquitectónicas abordadas por la mensajería son las


siguientes:

• Durabilidad: los mensajes se almacenan en un almacenamiento duradero,


y la aplicación puede leerlos luego de que aparezcan en caso de un error previo
• Confiabilidad: los mensajes ayudan a aplicar la confianza mediante el
diseño, ya que los mensajes no se pierden porque persisten en disco
• Disponibilidad de mensajes: los mensajes están disponibles para su uso por
parte de las aplicaciones luego de la restauración de la conectividad y antes
del tiempo de inactividad

Azure proporciona colas de Service Bus y temas para aplicar los patrones de
mensajería en las aplicaciones. La cola de almacenamiento también puede utilizarse
para el mismo propósito.

Elegir entre la cola de Service Bus y la cola de almacenamiento de Azure es decidir


entre cuánto tiempo tiene que almacenarse un mensaje, el tamaño del mensaje,
la latencia y el costo.

Service Bus de Azure brinda soporte para mensajes de un tamaño de 256 KB, mientras
que las colas de almacenamiento brindan soporte para mensajes de 64 KB. Service Bus
de Azure puede almacenar mensajes por un período de tiempo ilimitado, mientras
que la cola de almacenamiento puede almacenar mensajes durante siete días.

El costo y la latencia son superiores en el caso de las colas de Service Bus.

Según las necesidades y los requisitos de las aplicaciones, es necesario emplear los
factores anteriores antes de decidir la mejor cola.

[ 37 ]
Patrones de diseño de Azure

Consumidores que compiten


Un solo consumidor de mensajes trabaja de manera sincrónica, salvo que la
aplicación en sí implemente la lógica de lectura de mensajes de forma asincrónica.
El patrón de los consumidores que compiten ayuda a implementar una solución
en la que los diversos consumidores están listos para procesar el mensaje entrante
y competir para procesarlo. Esto ayuda a diseñar soluciones altamente disponibles
y escalables. Es escalable porque con diversos consumidores es posible procesar una
mayor cantidad de mensajes en el menor período posible. Es altamente disponible
porque podría haber al menos uno o más consumidores para procesar los mensajes
aun cuando algunos consumidores se bloqueen.

Es necesario usar este patrón cuando cada mensaje es independiente de otros


mensajes. Los mensajes por sí mismos contienen la información completa para
que un consumidor complete una tarea. No tendría que usarse este patrón si
existe alguna dependencia entre mensajes. Los consumidores tendrían que poder
completar las tareas de manera aislada. Además, este patrón es aplicable si hay
una demanda variable de servicios. Pueden agregarse o eliminarse consumidores
adicionales a petición.

Se requiere una cola de mensajes para la implementación del patrón de


consumidores que compiten. En este patrón, patrones de varias fuentes pasan
a través de una sola cola que está conectada a varios consumidores en el otro
extremo. Estos consumidores tienen que eliminar el mensaje luego de leerlo para
que no vuelva a procesarse.

Puede leer más información sobre este patrón en https://docs.


microsoft.com/es-es/azure/architecture/patterns/
competing-consumers.

[ 38 ]
Capítulo 2

Cola de prioridad
A menudo, es necesario darle prioridad en el procesamiento a mensajes con una
mayor importancia en comparación con los mensajes generales con menor prioridad.
Este patrón es importante para las aplicaciones que proporcionan diferentes
acuerdos de nivel de servicio (SLA) a los consumidores, que brindan servicios
basados en diferentes planes y suscripciones.

Las colas siguen patrones de primero en entrar, primero en salir. Los mensajes se
procesan en secuencia. Sin embargo, con la ayuda de este patrón, es posible acelerar
el procesamiento de ciertos mensajes debido a su mayor prioridad. Existen varias
maneras de implementarlo. Si la cola ofrece la capacidad de asignar prioridad y,
en función de la prioridad, reordenar los mensajes, entonces incluso una única cola
es suficiente para implementar este patrón.

Sin embargo, si la cola no tiene la capacidad de reordenar los mensajes, entonces


pueden crearse colas separadas para diferentes prioridades y cada una puede tener
asociados consumidores independientes:

De hecho, este patrón puede reutilizar los patrones de consumidores que compiten
si es necesario para acelerar el procesamiento de mensajes de cada cola que utilice
varios consumidores.

Puede leer más información sobre este patrón en https://docs.microsoft.


com/es-es/azure/architecture/patterns/priority-queue.

[ 39 ]
Patrones de diseño de Azure

Patrón de nivelación de carga basado en colas


A veces, no puede determinarse la carga en una aplicación en todo momento.
Aunque haya una demanda constante y predecible de la aplicación la mayoría de las
veces, en ocasiones esta carga puede llegar muy alto y llevar a una la falla de servicio
u ofrecer un rendimiento menor o falta de disponibilidad. El patrón de nivelación de
carga basado en colas puede ayudar en tales situaciones. En este patrón, se mantiene
una cola y todas las solicitudes de servicio se almacenan como mensajes en esta
cola. La cola funciona como un almacenamiento temporal altamente disponible
y duradero que, luego, envía mensajes al servicio a una velocidad controlada y,
así, reduce la interrupción en el extremo del servicio. Lo mismo se muestra en la
siguiente imagen. Existen varias tareas que envían mensajes a la cola de mensajes.
La cola almacena los mensajes y garantiza que el servicio los reciba a una velocidad
uniforme con los recursos disponibles en el extremo del servicio:

Este patrón garantiza que los recursos no escalen vertical y horizontalmente de


manera innecesaria mediante el aprovisionamiento de más instancias para satisfacer
una mayor demanda de servicio. También tiene un impacto directo en los costos
debido al uso previsible y a las instancias de recursos.

Una mejor escalabilidad y alta disponibilidad son otras de las ventajas derivadas de
la implementación de este patrón.

[ 40 ]
Capítulo 2

Patrones de rendimiento y escalabilidad


El rendimiento y la escalabilidad van de la mano. “Rendimiento” se refiere a la
capacidad de respuesta de un sistema de ejecutar cualquier acción dentro de un
intervalo de tiempo determinado, mientras que “escalabilidad” es la capacidad de
un sistema de controlar los aumentos en la carga sin afectar el rendimiento. En esta
sección, se describen algunos patrones de diseño relacionados con el rendimiento
y la escalabilidad.

El patrón de Segregación de responsabilidad


de consultas y comandos
Segregación de responsabilidad de consultas y comandos (CQRS) es un patrón
genérico que tiene aplicabilidad en cualquier escenario con datos almacenados
en un almacén de datos, y tiene que accederse a este de modo tal que aumente
el rendimiento general y la capacidad de respuesta de la aplicación.

Las operaciones de datos pueden clasificarse, a grandes rasgos, en operaciones de


lectura y de escritura. Existen varias maneras de leer y escribir en el almacén de
datos y, a menudo, hay un componente y capa de acceso de datos responsable de
realizar estas operaciones. Este componente de acceso de datos contiene información
acerca de la conexión del almacén de datos y realiza tanto operaciones de lectura
como de escritura. Realizar ambas operaciones desde una única interfaz puede ser
un desafío desde una perspectiva de rendimiento especialmente si los datos son
muchos y la relación de lectura y escritura está sesgada.

Segregación de responsabilidad de consultas y comandos (CQRS) es un patrón


que ayuda a implementar las operaciones de lectura y escritura mediante el uso
de diferentes interfaces. Significa que los componentes que implementan las
operaciones de lectura son distintos de aquellos de las operaciones de escritura
y pueden utilizarse individualmente en una instancia independiente. Esto ayuda
a proporcionarles capacidad de recursos dedicados. Este patrón también ayuda
en escenarios donde el tiempo de ejecución de las operaciones de lectura y escritura
es significativamente grande y consume más recursos.

[ 41 ]
Patrones de diseño de Azure

CQRS no solo ayuda a mejorar el rendimiento de la aplicación, sino que también


ayuda en el diseño y la implementación entre varios equipos. Esto es gracias
a su naturaleza de utilizar modelos diferentes. El patrón de CQRS no es el mejor
si usa herramientas de generación de modelos y andamiaje:

Puede leer más información sobre este patrón en https://docs.


microsoft.com/es-es/azure/architecture/patterns/cqrs.

Patrón de limitación
A veces, hay aplicaciones que tienen requerimientos muy estrictos de SLA desde una
perspectiva de rendimiento y escalabilidad independientemente de la cantidad de usuarios
que consuman el servicio. En tales circunstancias, es importante implementar patrones de
limitación debido a que ayudan a limitar la cantidad de solicitudes que se permite ejecutar.
La carga en las aplicaciones no se puede predecir con precisión en todas las circunstancias.
Cuando la carga en la aplicación experimenta picos, la limitación ayuda a reducir la
presión en los servidores y servicios mediante el control del consumo de recursos.

Es necesario utilizar este patrón cuando el cumplimiento del SLA es una prioridad
para las aplicaciones, para evitar que algunos usuarios consuman más recursos que
los asignados, para optimizar los picos y sobresaltos en la demanda, y también para
optimizar los costos del consumo de recursos. Estos son escenarios válidos para las
aplicaciones creadas con la intención de implementarse en la nube.

[ 42 ]
Capítulo 2

Puede haber varias estrategias para limitar una aplicación. La estrategia de limitación
puede rechazar solicitudes más nuevas una vez que se supera el límite o puede
notificar al usuario que la solicitud está en la cola y tendrá la oportunidad de
ejecutarse una vez que se reduzca la cantidad de solicitudes.

El siguiente diagrama muestra la implementación del límite en un sistema


multiinquilino en el que a cada inquilino se le asigna un límite de uso de recurso
fijo. Una vez que superan este límite, se restringe cualquier demanda adicional de
recursos y, por ende, se mantienen los recursos suficientes para otros inquilinos:

Puede leer más información sobre este patrón en https://docs.


microsoft.com/es-es/azure/architecture/patterns/
throttling.

Otros patrones
En esta sección, se describen algunos de los otros patrones importantes.

Patrón de reintento
El patrón de reintento es sumamente importante para hacer que las aplicaciones y los
servicios sean más resistentes a errores temporales. Piense en una situación en la que intenta
conectarse al servicio y utilizarlo, y el servicio no está disponible por algún motivo. Si el
servicio va a conectarse en un período de corta duración, tiene sentido continuar intentando
obtener una conexión exitosa. Esto hará que la aplicación sea más sólida y tolerante a los
errores, y generará inestabilidad. En Azure, la mayoría de los componentes se ejecuta en
Internet, y esa conexión a Internet puede producir errores temporales de forma intermitente.
Debido a estos errores que se corrigen en segundos, una aplicación no tendría que bloquearse.
La aplicación tendría que diseñarse de manera tal que pueda volver a intentar utilizar el
servicio repetidamente cuando ocurren errores. También tendría que dejar de intentarlo
si a pesar de cierta cantidad de reintentos, el servicio sigue sin estar disponible.
[ 43 ]
Patrones de diseño de Azure

Este modelo tendría que implementarse cuando una aplicación podría experimentar
errores temporales mientras interactúa con un servidor remoto o tiene acceso a un
recurso remoto. Se espera que estos errores sean de corta duración, y la repetición de
una solicitud que falló previamente podría tener éxito en un intento posterior.

El patrón de reintentos puede adoptar diferentes estrategias de reintentos basadas en


la naturaleza de los errores y la aplicación:

• Reintentar una cantidad establecida de veces: significa que la aplicación


intentará comunicarse con el servicio una cantidad fija de veces antes de que
pueda determinar un error y plantear una excepción. Por ejemplo, intentar
conectarse a otro servicio tres veces. Si la conexión se establece correctamente
en alguno de estos tres intentos, toda la operación es exitosa. De lo contrario,
al cuarto intento fallido, planteará una excepción.
• Reintentar en función del cronograma: indica que la aplicación intentará
comunicarse con el servicio repetidamente durante una cantidad establecida
de segundos o minutos y también esperará una cantidad determinada
de segundos o minutos antes de volver a intentarlo. Por ejemplo, volver
a intentar conectarse a otro servicio cada tres segundos durante 60 segundos.
Si la conexión se establece correctamente en alguno de estos intentos, toda
la operación es exitosa. De lo contrario, una vez finalizados los 60 segundos,
planteará una excepción.
• Deslizar y retrasar el reintento: significa que la aplicación intentará
comunicarse con el servicio repetidamente en función del cronograma
y continuará agregando una demora incremental en los intentos posteriores.
Por ejemplo, reintentar durante un total de 60 segundos en los que el primer
reintento ocurre luego de un segundo, el segundo intento tiene lugar después
de dos segundos a partir del anterior, el tercer reintento se da luego de cuatro
segundos a partir del anterior y así sucesivamente. Esto ayuda a reducir
la cantidad general de reintentos.

El patrón de reintento se representa por medio de una imagen en la que la primera


solicitud obtiene 500 de HTTP como un mensaje de respuesta, el segundo reintento
obtiene nuevamente 500 de HTTP como respuesta y, por último, la solicitud es
exitosa y obtiene 200 de HTTP como un mensaje de respuesta:

[ 44 ]
Capítulo 2

Puede leer más información sobre este patrón en https://docs.


microsoft.com/en-us/azure/architecture/patterns/retry.

Patrón de interruptor
Se trata de un patrón sumamente útil. Piense nuevamente en una situación en la
que intenta conectarse al servicio y utilizarlo, y el servicio no está disponible por
algún motivo. Si el servicio no va a conectarse en un período de corta duración, no
tiene sentido continuar intentando obtener una conexión exitosa. Además, mantener
a otros recursos ocupados mientras reintenta conectarse desperdicia muchos de los
recursos que potencialmente se podrían utilizar en otros lugares.

[ 45 ]
Patrones de diseño de Azure

El patrón de interruptor ayuda a eliminar dicho desperdicio de recursos. Puede


evitar que las aplicaciones intenten conectarse y usar repetidamente un servicio que
no está disponible. También ayuda a las aplicaciones a detectar si el servicio está en
funcionamiento otra vez y, finalmente, les permite que se conecten a él.

Para implementar el patrón de interruptor, todas las solicitudes de servicio tienen


que pasar por otro servicio. Este servicio actúa como un proxy para el servicio
original. El propósito de este servicio de proxy es mantener una máquina de estado
y actuar como gateway del servicio original. Hay tres estados que mantiene. Puede
haber más estados que se podrían incluir según los requerimientos de aplicación.

Los estados mínimos que se necesitan para implementar este patrón son los siguientes:

• Abierto: indica que el servicio no funciona e inmediatamente se presenta


una excepción en la aplicación en lugar de permitir que vuelva a intentar
conectarse o esperar el límite de tiempo. Cuando el servicio vuelve
a funcionar, el estado pasa a Medio abierto.
• Cerrado: este estado indica que el servicio está en excelentes condiciones
y que la aplicación puede continuar y conectarse a él. Por lo general,
se conserva un contador para mantener la cantidad de errores antes de que
pase al estado Abierto.
• Medio abierto: en un determinado momento, cuando el servicio ya funciona, este
estado permite que una cantidad limitada de solicitudes pase por él. Este estado
es una prueba de fuego que verifica si la solicitud que pasa a través de este tiene
éxito o no. Si es exitosa, el estado pasa de Medio abierto a Cerrado. Este estado
también puede implementar un contador para permitir que una determinada
cantidad de solicitudes tenga éxito antes de que puedan pasar al estado Cerrado.

Los estados mencionados anteriormente y el paso de uno a otro se muestran aquí:

[ 46 ]
Capítulo 2

Puede leer más información sobre este patrón en https://docs.


microsoft.com/es-es/azure/architecture/patterns/
circuit-breaker.

Resumen
Existen numerosos servicios disponibles en Azure, y la mayoría puede combinarse para
crear soluciones reales. Es difícil escribir sobre patrones de diseño en 20 páginas cuando
existen cientos de servicios y múltiples maneras de combinarlos. En este capítulo
se explicaron los tres servicios más importantes de Azure: regiones, almacenamiento
y redes. Prácticamente, forman la columna vertebral de cada solución implementada
en cualquier nube. En este capítulo se proporcionan detalles acerca de dichos servicios
y de cómo su configuración y aprovisionamiento pueden afectar las decisiones de diseño.
También se detallaron aquí las consideraciones importantes para el almacenamiento y las
redes. Tanto las redes como el almacenamiento ofrecen muchas opciones y es importante
elegir una configuración adecuada según lo requerido. Por último, se describieron
algunos de los patrones de diseño importantes relacionados con la mensajería, como los
consumidores que compiten, las colas de prioridad y la nivelación de carga. Se ilustraron
patrones relacionados con CQRS y la limitación. Además se comentaron otros patrones
como el de reintento y el de interruptor.

El próximo será un capítulo interesante que trata sobre las opciones de alta
disponibilidad en Azure para implementar cargas de trabajo.

[ 47 ]
Diseñar alta disponibilidad
Ejecutar aplicaciones y sistemas disponibles para que los usuarios los usen cada
vez que los necesitan es una de las principales prioridades para los directores de
informática. Desean que sus aplicaciones sean operativas, funcionales y continúen
estando disponibles para los clientes incluso ante eventos adversos, tema que
abordaremos en este capítulo: alta disponibilidad. “Mantener las luces encendidas”
es la metáfora que siempre se utiliza para la alta disponibilidad. Lograr una alta
disponibilidad en cuanto a aplicaciones no es tarea fácil, y las organizaciones tienen
que invertir mucho tiempo, energía, recursos y dinero para hacerlo. Incluso cuando
se estén utilizando, todavía existen posibilidades y riesgos de que su implementación
no produzca los resultados deseados. Azure ofrece muchas características de alta
disponibilidad para máquinas virtuales (VM) y servicios PaaS. En este capítulo,
repasaremos las funciones arquitectónicas y de diseño que ofrece Azure para
garantizar una alta disponibilidad en términos de aplicaciones y servicios.

En este capítulo, trataremos los siguientes temas:

• Conjuntos de disponibilidad de Azure


°° Dominio de error
°° Dominio de actualización

• Equilibrador de carga de Azure


• Gateways de aplicaciones de Azure

[ 49 ]
Diseñar alta disponibilidad

Alta disponibilidad
La alta disponibilidad es una de las principales preocupaciones para cualquier
arquitecto. Constituye uno de los principales requisitos técnicos no funcionales para
cualquier servicio serio y su implementación. “Alta disponibilidad” se refiere a la
característica de un servicio o una aplicación que lo mantiene continuamente operativo,
y que cumple con el acuerdo de nivel de servicio (SLA) definido y prometido, o lo
supera. Se les promete a los usuarios un determinado SLA en cuanto a la disponibilidad
de un servicio. El servicio tiene que estar disponible para su uso en función del SLA. Por
ejemplo, un SLA puede tener un 99 % de disponibilidad para una aplicación para todo
el año (suponiendo 365 días). Esto significa que tiene que estar disponible para su uso
por parte de los usuarios durante 361,35 días. Si la disponibilidad es menor, se incurre
en un incumplimiento del SLA. La mayoría de las aplicaciones esenciales definen su
SLA de disponibilidad alta con cinco nueves para un año. Significa que la aplicación
tiene que estar activa, funcionando y disponible durante todo el año, y que solo puede
dejar de funcionar y no estar disponible durante 5,2 horas.

Es importante señalar que la alta disponibilidad se define en términos de tiempo, que


puede ser anual, mensual, semanal, etc., e incluso podría ser una combinación de estos.

Los servicios o las aplicaciones están formados por varios componentes que se
implementan en diferentes niveles y capas. Además, se implementan en un sistema
operativo y se alojan en una máquina física o virtual. Utilizan servicios de red
y almacenamiento para varios fines. Incluso podrían depender de sistemas externos.
Para que estos servicios o aplicaciones tengan alta disponibilidad, es importante
diseñar las redes, el almacenamiento, el sistema operativo, las máquinas virtuales
o físicas y cada componente de la aplicación teniendo en cuenta el SLA y la alta
disponibilidad. Es necesario contar con un proceso definido de ciclo de vida de la
aplicación a fin de garantizar que la alta disponibilidad se geste desde que se empieza
a planificar la aplicación hasta que se introduce en operaciones. También implica
diseñar la arquitectura de redundancia. Es necesario que haya recursos redundantes
en la arquitectura de implementación de aplicaciones general a fin de garantizar que, si
uno deja de funcionar, el otro lo reemplace y atienda las peticiones del cliente.

SLA
En Wikipedia, SLA se define como:

“Un acuerdo de nivel de servicio es un acuerdo entre dos o más partes, donde uno
es el cliente y los demás son proveedores de servicios. El proveedor y el usuario
del servicio llegan a un acuerdo sobre aspectos tales como calidad, disponibilidad
y responsabilidades, entre otros. El componente más común del SLA es que los
servicios tienen que prestarse al cliente tal como se acordaron en el contrato”.

[ 50 ]
Capítulo 3

Factores que afectan la alta disponibilidad


La arquitectura de implementación de aplicaciones, el mantenimiento planificado
y el mantenimiento no planificado son los principales factores que influyen sobre la
alta disponibilidad de una aplicación.

Mantenimiento planificado
Mantenimiento planificado se refiere al proceso mediante el cual la aplicación
y el ecosistema circundante que consta de plataformas, marcos, software, sistema
operativo y controladores host y cliente se mantienen al día, con las versiones
estables más recientes. Es importante que al software, los controladores y los
sistemas operativos se le apliquen los parches con las últimas actualizaciones, ya
que esto ayuda a mantener un entorno en buenas condiciones en lo que respecta
a seguridad, rendimiento y preparación para el futuro. No actualizar un entorno no
es una opción, pero suele suceder. Incluso las aplicaciones se tienen que actualizar
con funcionalidades mejoradas, correcciones de errores y revisiones. Todas las
organizaciones planifican actualizaciones de entornos y aplicaciones que, por lo
general, implican cerrar y reiniciar la aplicación y el sistema operativo. También
podrían implicar que se inicie el sistema operativo del host físico que, a su vez,
reiniciará todas las máquinas virtuales cliente que funcionan sobre él.

Mantenimiento no planificado
Como su nombre lo indica, mantenimiento no planificado se refiere al mantenimiento
que no puede planificarse y es de carácter ad hoc. Se refiere a errores de hardware,
tales como corrupción del almacenamiento, falla de red o del enrutador, falla eléctrica
y una serie de otras fallas de hardware y software. La solución de problemas en la
plataforma subyacente que hacen que la aplicación deje de funcionar también forma
parte del mantenimiento no planificado.

Arquitectura de implementación de aplicaciones


La arquitectura de la aplicación es fundamental para garantizar la alta disponibilidad de
una aplicación. Una aplicación cuyos componentes se implementan en una sola máquina
no tiene alta disponibilidad. Cuando la máquina se reinicia, la aplicación no está disponible
para los usuarios. Del mismo modo, depender de una única instancia de un recurso puede
convertirse en un punto único de falla desde el punto de vista de la alta disponibilidad.
Cada componente de la aplicación tiene que estar diseñado de manera que se pueda
implementar en múltiples equipos, y la redundancia no tiene que generar un cuello de
botella. Algunos programas ofrecen características relacionadas con la alta disponibilidad
que no dependen de sistemas operativos host ni de otras herramientas de terceros. Los
grupos de disponibilidad de SQL Server son un ejemplo de estas características.

[ 51 ]
Diseñar alta disponibilidad

Alta disponibilidad en comparación con


escalabilidad
La alta disponibilidad no es lo mismo que la escalabilidad, aunque ambas constituyen
cuestiones arquitectónicas serias. Escalabilidad se refiere a la flexibilidad y elasticidad para
aumentar o reducir la cantidad de recursos en la implementación existente a fin de aceptar
más usuarios de lo normal sin comprometer el rendimiento de la aplicación. La escalabilidad
ayuda indirectamente a lograr que una aplicación tenga alta disponibilidad. Sin embargo, no
significa que la escalabilidad finalmente lleva a la alta disponibilidad. La alta disponibilidad
es una cuestión arquitectónica que no depende de la cantidad de usuarios, mientras que las
reglas de escalabilidad están determinadas por la cantidad de usuarios que utilizan el servicio.
La alta disponibilidad podría ser un requisito incluso si hubiera muy pocos usuarios. La alta
disponibilidad tiene que ver con el hecho de que los servicios estén presentes y funcionen del
modo y en el momento en el que los usuarios necesiten utilizarlos. Es una función de uso basado
en el SLA. El tema de la escalabilidad lo abordaremos en más detalle en el próximo capítulo.

Alta disponibilidad en comparación con


recuperación ante desastres
La alta disponibilidad tampoco es lo mismo que la recuperación ante desastres. Sin
embargo, la diferencia puede ser muy sutil. La alta disponibilidad consiste en que la
aplicación se encuentre en un estado en que se pueda utilizar del modo y en el momento en
el que el usuario lo solicite. Por lo tanto, está diseñada para operaciones que se desarrollan
antes de un desastre, mientras que la recuperación ante desastres entra en juego después.
La recuperación ante desastres consiste en la implementación de la arquitectura a través
de la cual los servicios están activos y se ejecutan después de un desastre, mientras que la
alta disponibilidad se ocupa de la disponibilidad antes de que este ocurra. La recuperación
ante desastres incluye servidores para copias de seguridad y archivo de datos, y servidores
inactivos en todos los continentes; mientras que la alta disponibilidad consiste en
equilibradores de carga, distribución de carga y redundancia activa-pasiva y activa-activa.

Alta disponibilidad de Azure


Lograr una alta disponibilidad que cumpla con altos requerimientos de SLA es
un requisito exigente. Azure ofrece muchas características que permiten una alta
disponibilidad de aplicaciones del sistema operativo del host y el cliente a las aplicaciones
que utilizan su PaaS. Los arquitectos pueden utilizar estas características para lograr una
alta disponibilidad de sus aplicaciones mediante tareas de configuración, sin tener que
crearlas desde cero ni depender de herramientas de terceros.
En esta sección, abordaremos características y funciones que ofrece Azure para lograr
que las aplicaciones tengan alta disponibilidad. Antes de comenzar con los detalles
de arquitectura y configuración, es importante entender los conceptos relacionados
con la alta disponibilidad de Azure.

[ 52 ]
Capítulo 3

Conceptos
Azure proporciona las siguientes construcciones fundamentales para lograr una alta
disponibilidad:

• Conjuntos de disponibilidad
• Dominio de error
• Dominio de actualización
• Zonas de disponibilidad

Conjuntos de disponibilidad
En Azure, la alta disponibilidad se logra principalmente a través de la redundancia.
Redundancia significa que hay más de una instancia de recurso, de modo que si uno
falla, el otro lo reemplaza. Pero el simple hecho de contar con más recursos similares no
genera alta disponibilidad. Por ejemplo, contar con más de una máquina virtual no hace
que estas máquinas tengan alta disponibilidad. Azure ofrece recursos de conjuntos de
disponibilidad para etiquetar y los agrupa. Todas las máquinas virtuales del conjunto
de disponibilidad adquieren alta disponibilidad porque se colocan en bastidores físicos
separados en el centro de datos de Azure, y las máquinas virtuales se actualizan de
a una por vez, en lugar de todas al mismo tiempo. Los conjuntos de disponibilidad
ofrecen dominio de error y de actualización para lograrlo, tema que abordaremos en la
próxima sección. En síntesis, los conjuntos de disponibilidad ofrecen redundancia en el
nivel de centro de datos similar al almacenamiento local redundante.

Dominio de error
Cuando se aprovisiona una máquina virtual y se asigna a un conjunto de
disponibilidad, esta se asigna a un dominio de error. Con Azure Resource Manager
(ARM), cada conjunto de disponibilidad cuenta, de manera predeterminada, con dos
o tres dominios de error, según las regiones de Azure. Algunas regiones ofrecen dos
dominios de error, mientras que otras ofrecen tres en un conjunto de disponibilidad.
Los dominios de error no pueden ser configurados por los usuarios. Cuando se
crean varias máquinas virtuales, se colocan en dominios de error separados. Si se
proporcionan más de cinco máquinas virtuales en un conjunto de disponibilidad,
se distribuyen equitativamente en los cinco dominios de error. Los dominios de
error están relacionados con bastidores físicos en el centro de datos de Azure.
Los dominios de error ofrecen alta disponibilidad a partir del mantenimiento no
programado por errores de hardware, fallas eléctricas y errores de red. Dado que
cada máquina virtual se coloca solo en un bastidor, las otras máquinas virtuales
continúan funcionando en el caso de que el bastidor en cuestión se rompa.

[ 53 ]
Diseñar alta disponibilidad

Dominio de actualización
El dominio de error se encarga del mantenimiento no planificado, y el dominio de
actualización, del mantenimiento planificado. Cada máquina virtual se asigna también
a un dominio de actualización. Puede haber hasta 20 dominios de actualización en
un solo conjunto de disponibilidad. Los dominios de actualización no pueden ser
configurados por los usuarios. Cuando se crean varias máquinas virtuales, se colocan
en dominios de actualización separados. Si se aprovisionan más de 20 máquinas
virtuales en un conjunto de disponibilidad, se distribuyen equitativamente en
estos dominios de actualización. Los dominios de actualización se encargan del
mantenimiento planificado.

Zonas de disponibilidad
Este concepto se introdujo hace relativamente poco en Azure y es muy similar a la
redundancia de zona que vimos para las cuentas de almacenamiento. Ofrece alta
disponibilidad dentro de una región colocando las máquinas virtuales en centros de datos
separados dentro de una región. Se pueden aplicar zonas de disponibilidad a máquinas
virtuales, discos gestionados, conjuntos de escala de máquinas virtuales y equilibradores
de carga. Durante mucho tiempo, esto generó una brecha en Azure, pero recientemente
se la eliminó desde el punto de vista de la alta disponibilidad en materia de informática.
Puede encontrar más información sobre Zonas de disponibilidad en avaihttps://docs.
microsoft.com/es-es/azure/ availability-zones/az-overview .

Equilibrio de carga
El equilibrio de carga se refiere, como su nombre indica, al proceso de equilibrar la
carga entre máquinas virtuales y aplicaciones. Con una sola máquina virtual, no es
necesario contar con un equilibrador de carga porque toda la carga recae sobre una
sola máquina y no existe ninguna otra para compartirla. Sin embargo, si hay varias
máquinas virtuales con la misma aplicación y servicio, la carga se puede distribuir
entre ellas mediante el equilibrio de carga. Azure proporciona un par de recursos
para habilitar la función de equilibrio de carga:

• Equilibradores de carga: el equilibrador de carga de Azure ayuda a diseñar


la arquitectura de soluciones con alta disponibilidad. Dentro de la pila TCP,
es un equilibrador de carga de nivel 4 que funciona en la capa de transporte.
Es un equilibrador de carga de nivel 4 que distribuye el tráfico entrante entre
instancias de servicios en buen estado definidas en un conjunto de carga
equilibrada. Los equilibradores de carga de nivel 4 funcionan en el nivel de
transporte y tienen información del nivel de red, como por ejemplo, dirección IP
y puerto, para decidir el destino de la petición entrante. Más adelante en este
capítulo, abordaremos en detalle el tema del equilibrio de la carga.

[ 54 ]
Capítulo 3

• Gateways de aplicación: los gateways de aplicación de Azure ofrecen alta


disponibilidad a sus aplicaciones. Es un equilibrador de carga de nivel 7 que
distribuye el tráfico entrante entre instancias de servicios en buen estado. Los
equilibradores de carga de nivel 7 pueden trabajar en el nivel de la aplicación
y tienen información del nivel de la aplicación, como por ejemplo, cookies,
HTTP, HTTPS y sesiones correspondientes a la solicitud entrante. Más adelante
en este capítulo, abordaremos en detalle el tema de los gateways de aplicación.

Alta disponibilidad de máquinas virtuales


Las máquinas virtuales ofrecen capacidades informáticas. Proporcionan potencia de
procesamiento y hosting para aplicaciones y servicios. Si la aplicación se implementa
en una sola máquina virtual y esa máquina deja de funcionar, entonces la aplicación
no estará disponible. Si la aplicación está formada por varios niveles y cada nivel
se implementa en una instancia exclusiva propia de una máquina virtual, incluso
el tiempo de inactividad de una sola máquina virtual puede hacer que la aplicación
no esté disponible. Si bien Azure intenta incluso brindar alta disponibilidad para
implementaciones en máquinas virtuales individuales colocándolas en diferentes
bastidores apenas las detecta, Azure no asegura ni garantiza ningún SLA respecto a ellas.
Azure ofrece un SLA para aquellas máquinas virtuales que se agrupan dentro de un
conjunto de disponibilidad. Ofrece un SLA de cinco nueves (99,999 %) en lo que respecta
a la disponibilidad de máquinas virtuales siempre que formen parte de un conjunto de
disponibilidad y que haya más de dos máquinas virtuales en dicho conjunto.

Alta disponibilidad informática


Las aplicaciones que exigen alta disponibilidad se tienen que implementar en
varias máquinas virtuales del mismo conjunto de disponibilidad. Si las aplicaciones
están formadas por varios niveles, entonces cada nivel tiene que tener un grupo de
máquinas virtuales en su conjunto de disponibilidad dedicado. En síntesis, si una
aplicación tiene tres niveles, tendrá que haber tres conjuntos de disponibilidad y seis
máquinas virtuales como mínimo (dos en cada conjunto de disponibilidad) para que
toda la aplicación tenga alta disponibilidad.

¿Cómo brinda Azure un SLA y alta disponibilidad a máquinas virtuales dentro de


un conjunto de disponibilidad con varias máquinas en cada uno? Esa es la pregunta
que se podría plantear.

Aquí es donde aparecen los conceptos de los que hablábamos antes: dominio de
error y de actualización.

[ 55 ]
Diseñar alta disponibilidad

Cuando Azure ve varias máquinas virtuales en un conjunto de disponibilidad, las coloca


en dominios de error separados. En otras palabras, estas máquinas virtuales se colocan
en bastidores físicos separados, no en el mismo. Esto garantiza que por lo menos una
máquina virtual continúe disponible incluso en caso de falla eléctrica, error de hardware
o de bastidor. Hay dos o tres dominios de error en un conjunto de disponibilidad
y, dependiendo de la cantidad de máquinas virtuales que haya en un conjunto, las
máquinas se colocan en dominios de error separados o repetidos equitativamente. Esto
garantiza que la alta disponibilidad no se vea afectada por un error del bastidor.

Además, Azure coloca estas máquinas en un dominio de actualización separado.


En otras palabras, Azure etiqueta estas máquinas internamente de modo tal que los
parches y las actualizaciones se apliquen uno después del otro para que el reinicio
en un dominio de actualización no afecte la disponibilidad de la aplicación. Esto
garantiza que la alta disponibilidad no se vea afectada por el mantenimiento de la
máquina virtual y del host.

Al colocar las máquinas virtuales en dominios de error y de actualización separados,


Azure garantiza que no dejen de funcionar todas al mismo tiempo y que estén
activas y disponibles para atender peticiones, incluso cuando durante tareas de
mantenimiento o problemas físicos que generan inactividad.

[ 56 ]
Capítulo 3

La imagen anterior muestra cuatro máquinas virtuales (2 relacionadas con IIS y 2 con
SQL). Tanto las máquinas virtuales IIS como las SQL forman parte de su conjunto
de disponibilidad. Las máquinas virtuales IIS y las SQL están en dominios de error
separados y en bastidores diferentes en el centro de datos. También estarían en
dominios de actualización separados.

Alta disponibilidad en almacenamiento


Las máquinas virtuales están respaldadas por cuentas de almacenamiento donde se
almacenan sus archivos VHD. Si bien los conjuntos de disponibilidad brindan alta
disponibilidad a la instancia informática, no garantizan la alta disponibilidad de los
archivos VHD de las máquinas virtuales que se guardan en cuentas de almacenamiento.
Los archivos VHD de todas las máquinas virtuales se podrían colocar en el mismo clúster de
almacenamiento, en cuyo caso cualquier error del clúster podría hacer que no haya ninguna
máquina virtual disponible o que la disponibilidad sea más limitada que la necesaria. En
síntesis, no solo los servicios informáticos necesitan contar con alta disponibilidad, también
las cuentas de almacenamiento donde se guardan los archivos VHD tendrían que colocarse
en clústeres separados de modo que, en caso de error, una o algunas máquinas virtuales
continúen disponibles tanto desde el punto de vista informático como de almacenamiento.
Azure ofrece discos administrados como concepto que brinda servicios de administración
de discos. Los discos administrados ofrecen mayor confiabilidad para los conjuntos de
disponibilidad, ya que garantizan que los discos de las máquinas virtuales de un conjunto
estén lo suficientemente aislados entre sí como para evitar puntos únicos de falla. Esto se
realiza automáticamente colocando los discos en distintos clústeres de almacenamiento.
Si un clúster de almacenamiento falla por un error de hardware o de software, solo
falla la máquina virtual con discos en esas marcas. Los VHD de las máquinas virtuales
de un conjunto de disponibilidad se tienen que colocar en cuentas de almacenamiento
separadas. No obstante, se pueden colocar máquinas virtuales de diferentes conjuntos de
disponibilidad en una misma cuenta de almacenamiento.
[ 57 ]
Diseñar alta disponibilidad

Alta disponibilidad de PaaS


Azure ofrece servicios de aplicaciones y de nube para plataformas administradas
por hosting. Pueden implementarse servicios y aplicaciones sobre ellas. Brindan
flexibilidad, elasticidad y economía para crear e implementar aplicaciones. Azure
administra estas plataformas, y los usuarios no interactúan con la infraestructura
base sobre la que se implementan. Aportan un mayor nivel de abstracción en
comparación con IaaS, ya que le permiten a los desarrolladores concentrarse en sus
problemas comerciales y utilizar la plataforma para rastrear rápidamente su proceso
de desarrollo e implementación. Esto les quita el peso de tener que administrar,
operar y supervisar la infraestructura base. Cuando una aplicación se implementa
con servicios de aplicación o en nube, Azure proporciona máquinas virtuales
que no son visibles para los usuarios. Las aplicaciones se implementan en estas
máquinas virtuales y el controlador de tejido de Azure se encarga de aprovisionarlas,
administrarlas y supervisarlas. El controlador de tejido supervisa el estado del
hardware y del software de las instancias de máquinas host y cliente. Cuando detecta
un error, mantiene los SLA reubicando automáticamente las máquinas virtuales.
Cuando se implementan varios roles de servicios en la nube, Azure los implementa
en distintos dominios de error y actualización.

[ 58 ]
Capítulo 3

El diagrama anterior muestra que los servicios PaaS con varias instancias de
máquinas virtuales implementan estos roles de web y de trabajo en dominios de
error independientes. La implementación en dominios de error independientes
significa la implementación en distintos bastidores dentro de un centro de datos.
También significa que estos servicios tienen interruptores de red y fuentes de
alimentación independientes, lo que garantiza la existencia de otras instancias
disponibles para cumplir con los requisitos del cliente, incluso si uno de los
bastidores se somete a mantenimiento, hay una interrupción del suministro de
energía al bastidor o una falla del interruptor de red.

Alta disponibilidad de aplicaciones


La alta disponibilidad puede estar incorporada en el software utilizado para
las aplicaciones o puede desarrollarse desde cero en estas. Un ejemplo de la
característica de alta disponibilidad proporcionada por el software es SQL Server
siempre en grupos de disponibilidad. Ayudan a mantener las bases de datos
altamente disponibles.
Los servicios de Azure también tienen un mecanismo de alta disponibilidad
incorporado. En Azure SQL, los datos se replican sincrónicamente dentro de la
región. La replicación geográfica activa permite hasta cuatro copias adicionales de
la base de datos en la misma región o en regiones diferentes. El almacenamiento de
Azure tiene su propio mecanismo para poner los datos a disposición mediante la
replicación a múltiples centros de datos y regiones.

Equilibrio de carga
Azure proporciona dos construcciones para aprovisionar a los equilibradores
de carga. Ofrece un equilibrador de carga de nivel 4 que funciona en la capa de
transporte en la pila de OSI TCP y un equilibrador de carga de nivel 7 que funciona
en el nivel de la aplicación y la sesión.
Aunque tanto los gateways de aplicación como el equilibrador de carga ofrecen
características básicas para equilibrar la carga, sirven a diversos propósitos. Hay
casos en los que tiene más sentido implementar el gateway de aplicación en
comparación con el equilibrador de carga.
El gateway de aplicación ofrece las siguientes características que no están disponibles
en los equilibradores de carga de Azure:
• Firewall de aplicaciones web: es un firewall adicional además del firewall
del sistema operativo y tiene la capacidad de echar un vistazo a los mensajes
entrantes. Esto ayuda en la identificación y protección de ataques comunes
basados en la web, como la inyección SQL, ataques de scripts entre sitios
y secuestros de sesión.

[ 59 ]
Diseñar alta disponibilidad

• Afinidad de sesión basada en cookies: los equilibradores de carga distribuyen


el tráfico entrante en las instancias de servicios en buen estado y relativamente
libres. Cualquier instancia puede atender una solicitud. Algunas aplicaciones
necesitan características avanzadas en las que todas las solicitudes posteriores
a la primera tienen que ser procesadas por la misma instancia de servicio. Esto
se conoce como afinidad de sesión basada en cookies. El gateway de aplicación
ofrece afinidad de sesión basada en cookies para mantener una sesión de
usuario en la misma instancia de servicio mediante cookies.
• Descarga de capa de sockets seguros (SSL): el cifrado y descifrado de datos de
solicitud y respuesta se realiza mediante SSL y es generalmente una operación
costosa. Lo ideal sería que los servidores web inviertan sus recursos en procesar
y servir solicitudes, más que en el cifrado y descifrado del tráfico. La descarga
de SSL ayuda en la transferencia de este proceso de criptografía desde el
servidor web hasta el equilibrador de carga y así proporciona más recursos a los
servidores web al servicio de los usuarios. La solicitud del usuario está cifrada
pero se descifra en el gateway de aplicación en lugar de en el servidor web. La
solicitud del gateway de aplicación al servidor web no está cifrada.
• SSL de extremo a extremo: mientras que la descarga de SSL es una buena
característica para una aplicación determinada, hay ciertas aplicaciones críticas
seguras que necesitan un cifrado y descifrado completos de SSL, incluso si el
tráfico pasa a través de los equilibradores de carga. El gateway de aplicación
también puede configurarse para una criptografía SSL de extremo a extremo.
• Enrutamiento de contenido basado en URL: el gateway de aplicación
también es útil para redirigir el tráfico a diferentes servidores basados en
el contenido de la URL de las solicitudes entrantes. Esto ayuda a hospedar
varios servicios junto con otras aplicaciones.

Equilibradores de carga de Azure


El equilibrador de carga de Azure distribuye el tráfico entrante en función de la
información de nivel de transporte que tiene disponible. Se basa en lo siguiente:

• Dirección IP de origen
• Dirección IP de destino
• Número de puerto de origen
• Número de puerto destino
• Tipo de protocolo: TCP o HTTP

[ 60 ]
Capítulo 3

Equilibrio de carga público


En esta configuración, se asigna una dirección IP pública a los equilibradores de
carga. Asignar una dirección IP pública garantiza que el equilibrador de carga pueda
aceptar las solicitudes de Internet. Sin una dirección IP pública, no es posible acceder
al recurso desde Internet. El equilibrador de carga puede configurarse con las reglas
de equilibrio de carga. Estas reglas funcionan en el nivel de puerto. Acepta que los
puertos de origen y destino los asignen de modo tal que cuando un equilibrador de
carga recibe una solicitud del puerto de origen, la solicitud se reenvía a una máquina
virtual de un grupo de máquinas virtuales vinculada al equilibrador de carga en el
puerto de destino. Esto se muestra en el siguiente diagrama:

[ 61 ]
Diseñar alta disponibilidad

Pero, ¿cómo funciona todo esto? ¿Cómo se asigna una dirección IP pública a un
equilibrador de carga? ¿Qué contiene el equilibrador de carga? ¿Cómo se configura con las
reglas de equilibrador de carga? ¿Cómo envía el equilibrador de carga las solicitudes a las
máquinas virtuales? ¿Cómo sabe la máquina virtual que está vinculada al equilibrador de
carga y demás? La respuesta a todas estas preguntas puede verse en el siguiente diagrama.

En esta configuración, al equilibrador de carga se le asigna una dirección IP pública.


Puede accederse al equilibrador de carga desde Internet y este puede aceptar solicitudes
de clientes. El equilibrador de carga puede configurarse con las reglas de equilibrio de
carga y NAT. Las reglas de NAT y de equilibrio de carga forman parte de la configuración
de frontend. La configuración de frontend envía las solicitudes del cliente a una de las
direcciones IP disponibles en el grupo de backend. Estas direcciones IP se asocian con la
tarjeta de interfaz de red, que a su vez está vinculada a las máquinas virtuales.

Equilibrador de carga interno


El siguiente diagrama muestra el funcionamiento de un equilibrador de carga interno.
Se puede ver que la solicitud proviene de recursos de Azure mismo dado que no
es accesible en Internet. En esta configuración, al equilibrador de carga se le asigna
una dirección IP privada. El equilibrador de carga solo es accesible dentro de la red
virtual a la cual está conectado. No puede accederse a través de Internet. El resto de su
configuración es como la del equilibrador de carga público. El equilibrador de carga
puede configurarse con las reglas de equilibrio de carga y NAT.

[ 62 ]
Capítulo 3

El siguiente diagrama muestra cómo pueden implementarse varios equilibradores


de carga para crear soluciones. En él, hay un equilibrador de carga público que
acepta solicitudes de clientes y un equilibrador de carga interno para el nivel de
base de datos. Las máquinas virtuales del nivel de base de datos no son accesibles en
Internet, sino únicamente mediante el equilibrador de carga en el puerto 1433.

[ 63 ]
Diseñar alta disponibilidad

Redireccionamiento de puertos
A veces, existe la necesidad de que una solicitud siempre tenga que redirigirse a
una máquina virtual. El equilibrador de carga de Azure nos ayuda a lograrlo con
las reglas de NAT. Se evalúan las reglas de NAT una vez que se hayan evaluado las
reglas de equilibrio de carga y que se haya determinado que no se cumple ninguna
de sus reglas. Las reglas de NAT se evalúan para cada solicitud entrante, y una vez
que el equilibrador las encuentra, envía la solicitud a esa máquina virtual a través
de un grupo de backend. Es necesario tener en cuenta que una máquina virtual
no puede registrar el mismo puerto para ambos redireccionamientos de puertos
mediante las reglas de NAT y de equilibrio de carga.

Gateways de aplicaciones de Azure


El equilibrador de carga de Azure nos ayuda a habilitar soluciones en el nivel de
la infraestructura. Sin embargo, existen ocasiones en las que se requieren servicios
y características avanzados desde el equilibrador de carga en sí mismo. Estos servicios
avanzados incluyen la terminación de SSL, afinidad de sesión, seguridad avanzada
y mucho más. Los gateways de aplicación de Azure se crean sobre equilibradores de
carga de Azure para proporcionar estas funciones adicionales. El gateway de aplicación
de Azure es un equilibrador de carga de nivel 7 que funciona con la carga de sesión
y aplicación en una pila OSI TCP. Los gateways de aplicación tienen más información,
en comparación con el equilibrador de carga de Azure, para tomar decisiones sobre el
enrutamiento de solicitudes y el equilibrio de carga entre servidores. Azure administra
los gateways de aplicación, y estos tienen alta disponibilidad.

Un gateway de aplicación se encuentra entre los usuarios y las máquinas virtuales,


como se muestra en la figura siguiente:

[ 64 ]
Capítulo 3

Los gateways de aplicación se implementan internamente mediante máquinas virtuales.


Internet Information Service (IIS) está instalado y configurado con Application Request
Routing (ARR) en estas máquinas virtuales. Estos gateways pueden instalarse en varias
máquinas virtuales, lo que proporciona una alta disponibilidad para los gateways en sí.
Aunque no es visible, los equilibradores de carga de Azure distribuyen las cargas entre
varios servidores de gateway de aplicación. La creación de un gateway de aplicación
necesita una dirección IP interna o pública, la cual los usuarios usan para enviar
solicitudes. Esta IP pública o IP interna la proporciona el equilibrador de carga de Azure
que funciona en el nivel de transporte (TCP/UDP) y que equilibra la carga de todo el
tráfico de red entrante a las instancias de trabajo del gateway de aplicación. El gateway de
aplicación redirige entonces el tráfico HTTP/HTTPS en función de su configuración, sea
una máquina virtual, un servicio en la nube, una dirección IP interna o externa.

Un gateway de aplicación es similar al equilibrador de carga de Azure desde la


perspectiva de la configuración, con características y construcciones adicionales.
Ofrece configuración de puertos, IP de frontend, protocolos y certificados,
configuración de grupos de backend, puertos, afinidad de sesión y protocolos.

Azure Traffic Manager


Después de comprender bien el equilibrador de carga de Azure y el gateway de
aplicación, es momento de entrar en detalles sobre Traffic Manager. Los equilibradores
de carga de Azure y los gateways de aplicación son recursos indispensables para una
alta disponibilidad en un centro de datos y región; sin embargo, para lograr una alta
disponibilidad a través de regiones y centros de datos, se necesita otro recurso: Traffic
Manager. Traffic Manager nos ayuda a crear soluciones de alta disponibilidad que
abarcan múltiples geografías, regiones y centros de datos. Traffic Manager no es similar
a los equilibradores de carga. Utiliza DNS para redirigir las solicitudes a un punto
de conexión apropiado determinado por su estado y configuración. Traffic Manager
no es un proxy o un gateway. No ve el tráfico que pasa entre el cliente y el servicio.
Simplemente redirige la solicitud en función de los puntos de conexión más apropiados.

Azure Traffic Manager le permite controlar la distribución del tráfico en los puntos de
conexión de su aplicación. Un punto de conexión es cualquier servicio orientado a Internet
hospedado dentro o fuera de Azure.

Los puntos de conexión son URL públicas accesibles y orientadas a Internet.


Las aplicaciones se aprovisionan en varias geografías y regiones de Azure. Las
aplicaciones implementadas en cada región tienen un único punto de conexión
denominado DNS CNAME. Estos puntos de conexión se asignan al punto de
conexión de Traffic Manager. Cuando se aprovisiona Traffic Manager, obtiene un
punto de conexión por defecto con una extensión URL .trafficmanager.net.

[ 65 ]
Diseñar alta disponibilidad

Cuando llega una solicitud a la URL de Traffic Manager, encuentra el punto de


conexión más adecuado de la lista y le redirige la solicitud. En resumen, Traffic
Manager actúa como un DNS global para identificar la región que atenderá la solicitud.

Sin embargo, ¿cómo sabe Traffic Manager qué puntos de conexión utilizar y a cuál
redirigir la solicitud del cliente? Hay dos aspectos que Traffic Manager aplica para
determinar la región y el punto de conexión más apropiado.

En primer lugar, Traffic Manager supervisa activamente el estado de todos los


puntos de conexión. Puede supervisar el estado de las máquinas virtuales, los
servicios en la nube y los servicios de aplicación. Si determina que el estado de una
aplicación implementada en una región no es adecuado para redireccionar el tráfico,
redirige las solicitudes a un punto de conexión en buen estado.

En segundo lugar, Traffic Manager puede configurarse con información de


enrutamiento. Existen cuatro métodos de enrutamiento de tráfico disponibles en
Traffic Manager:

• Prioridad: es necesario utilizar este método cuando todo el tráfico tiene que ir
a un punto de conexión predeterminado y hay copias de seguridad disponibles
en caso de que los puntos de conexión primarios no estén disponibles.
• Ponderado: es necesario utilizarlo para distribuir el tráfico en puntos de
conexión de manera uniforme o según los pesos definidos.
• Rendimiento: es necesario utilizarlo para puntos de conexión en diferentes
regiones, y es necesario redirigir a los usuarios al punto de conexión más cercano
según su ubicación. Esto tiene un impacto directo sobre la latencia de la red.
• Geográfico: es necesario utilizarlo para redirigir a los usuarios de una
geografía específica a un punto de conexión (de Azure, externo o anidado)
disponible en dicha geografía, o el más cercano a esta. Los ejemplos incluyen
cumplir con mandatos de soberanía de datos, localización de contenido y
experiencia del usuario, y medir el tráfico de diferentes regiones.

Cabe destacar que después de que Traffic Manager determina un punto de conexión
válido en buen estado, los clientes se conectan directamente a la aplicación.

Consideraciones arquitectónicas para


una alta disponibilidad
En esta sección, analizaremos algunas de las arquitecturas de alta disponibilidad.

[ 66 ]
Capítulo 3

Alta disponibilidad dentro de las regiones de Azure


La arquitectura a continuación muestra la implementación de la alta disponibilidad dentro
de una única región de Azure. La alta disponibilidad se diseña en el nivel del recurso
individual. En esta arquitectura, hay varias máquinas virtuales en cada nivel conectadas
a través de cualquier gateway de aplicación o equilibrador de carga y son parte de un
conjunto de disponibilidad. Cada nivel está asociado con un conjunto de disponibilidad.
Estas máquinas virtuales se colocan en dominios independientes de errores y actualización.
Mientras que los servidores web se conectan a gateways de aplicación, el resto de los
niveles, como los de aplicación y base de datos, tienen equilibradores de carga internos.

[ 67 ]
Diseñar alta disponibilidad

Alta disponibilidad en todas las regiones de Azure


La arquitectura a continuación muestra implementaciones similares en dos regiones
diferentes de Azure. Ambas regiones tienen los mismos recursos implementados. La
alta disponibilidad se diseña en el nivel del recurso individual dentro de estas regiones.
Existen varias máquinas virtuales en cada nivel conectadas a través del equilibrador de
carga y son parte del conjunto de disponibilidad. Estas máquinas virtuales se colocan en
dominios independientes de errores y actualización. Mientras que los servidores web se
conectan a equilibradores de carga externos, el resto de los niveles, como los de aplicación
y base de datos, tienen equilibradores de carga internos. Cabe destacar que podrían haberse
utilizado equilibradores de carga de aplicaciones para niveles de aplicación y servidores
web en lugar del equilibrador de carga de Azure, si se necesitan servicios avanzados tales
como la afinidad de sesión, terminación de SSL, seguridad avanzada mediante WAF
y enrutamiento basado en ruta. Las bases de datos en ambas regiones están conectadas
entre sí mediante el emparejamiento de VNET y gateways. Esto es útil en la configuración
del trasvase de registros, SQL Server AlwaysOn y otras técnicas de sincronización de datos.
Los puntos de conexión de los equilibradores de carga de ambas regiones se utilizan
para configurar los puntos de conexión de Traffic Manager, y el tráfico se redirige
según el método de equilibrio de carga de prioridad. Traffic Manager ayuda en el
enrutamiento de todas las solicitudes al este de EE. UU. y en la conmutación por
error a Europa occidental, en caso de no disponibilidad de la primera región.

[ 68 ]
Capítulo 3

Procedimientos recomendados
En esta sección se describen los procedimientos recomendados de alta disponibilidad.
Están clasificados en aplicación, implementación, administración de datos y supervisión.

Alta disponibilidad de aplicaciones


Una aplicación tiene que crearse manteniendo la alta disponibilidad como una de las
cuestiones arquitectónicas importantes. A continuación se mencionan algunas de las
prácticas de alta disponibilidad importantes relacionadas con las aplicaciones:

• Una aplicación tiene que implementar un control de excepciones adecuado para


recuperarse fácilmente e informar a las partes interesadas sobre el problema.
• Una aplicación tiene que intentar realizar la misma operación otra vez en el intervalo
determinado cierta cantidad de veces antes de salir en caso de error o excepción.
• Una aplicación tiene que tener capacidad de tiempo de espera incorporada
para decidir que no puede recuperarse de una excepción.
• Es necesario adoptar el mantenimiento y la escritura de registros para todos
los errores, excepciones y ejecuciones dentro de la aplicación.
• Es necesario generar un perfil de las aplicaciones para encontrar los
requisitos de los recursos reales en términos de informática, memoria y
ancho de banda de red de diferentes usuarios.

Consulte https://docs.microsoft.com/es-es/azure/
architecture/checklist/availability para conocer más sobre la
aplicación y el resto de los procedimientos recomendados de alta disponibilidad.

Implementación
La estrategia de implementación en gran parte afecta la disponibilidad de aplicaciones y el
entorno general. Algunos de los elementos importantes a tener en cuenta son los siguientes:

• Implementar varias instancias de los recursos de Azure, incluidas varias


instancias de máquinas virtuales, servicios en la nube y otros recursos.
• Implementar máquinas virtuales en los conjuntos o zonas de disponibilidad.
No pueden usarse en conjunto.
• Implementar varias instancias de máquinas virtuales en diversas regiones.
• Crear varios entornos y mantener al menos uno en modo de espera.

[ 69 ]
Diseñar alta disponibilidad

Administración de datos
Algunos de los procedimientos recomendados importantes de alta disponibilidad
relacionados con los datos son los siguientes:

• Si es posible, almacenar los datos en los servicios proporcionados por Azure,


como Azure SQL, Cosmos DB y el almacenamiento de tablas
• Utilizar cuentas de almacenamiento basadas en el tipo de redundancia geográfica
• Asegurarse de que los datos se repliquen en varias regiones y no solamente
dentro de la zona o el centro de datos
• Realizar copias de seguridad periódicas y pruebas de restauración con frecuencia
• Si se almacenan los datos en máquinas virtuales, asegurarse de que haya
varias máquinas virtuales y que estén en conjuntos o zonas de disponibilidad
• Utilizar claves y secretos para los almacenes de datos en Azure Key Vault

Supervisión
Algunos de los procedimientos recomendados importantes de alta disponibilidad
relacionados con la supervisión son los siguientes:

• Utilizar OMS (análisis de registro) para supervisar el entorno y habilitar la


auditoría de registro
• Utilizar información de la aplicación para capturar los datos de telemetría
de la aplicación personalizada y el entorno relacionado con el cálculo, el
almacenamiento, la red y otra información de registro
• Garantizar que las alertas estén configuradas en OMS para problemas
relacionados con la disponibilidad del entorno y la aplicación
• Visitar el supervisor de Azure con frecuencia para obtener recomendaciones
relacionadas con la alta disponibilidad

[ 70 ]
Capítulo 3

Resumen
La alta disponibilidad es una cuestión arquitectónica importante y crucial. Casi
todas las aplicaciones y arquitectos intentan implementar la alta disponibilidad.
Tradicionalmente, la alta disponibilidad se implementaba desde cero, sin ninguna
ayuda de las plataformas. Azure es una plataforma madura que comprende la
necesidad de la alta disponibilidad de aplicaciones y, en este intento, proporciona
recursos para implementar la alta disponibilidad desde el nivel granular hasta el
nivel de centro de datos. La alta disponibilidad no es un aspecto secundario y tiene
que ser parte del desarrollo del ciclo de vida de las aplicaciones desde la fase de
planificación. Azure ofrece conjuntos de disponibilidad que garantizan que las
máquinas virtuales se coloquen en dominios independientes de error y actualización.
Los dominios de error garantizan que la interrupción imprevista en el nivel del
rack no cambie la disponibilidad de una aplicación, mientras que los dominios
de actualización se encargan del mantenimiento planificado. Incluso los servicios
PaaS de Azure utilizan dominios de error y actualización en segundo plano para
mantener la aplicación en funcionamiento. El equilibrador de carga interno y externo
de Azure es una construcción en el nivel de transporte del nivel 4 proporcionado
por Azure para distribuir la carga entre varias instancias de la aplicación. Asimismo,
los gateways de aplicación son equilibradores de carga de nivel 7 en el nivel de la
aplicación y la sesión que ofrecen funcionalidades avanzadas tales como la afinidad
de sesiones y la terminación de SSL. Los Traffic Manager son construcciones de
alta disponibilidad en el nivel de DNS global para que las aplicaciones tengan una
alta disponibilidad en todas las geografías. El próximo capítulo se centrará en la
escalabilidad, que es otra faceta importante para la arquitectura general en Azure.

[ 71 ]
Implementar la escalabilidad
La ejecución de aplicaciones y sistemas que están disponibles para el consumo
de los usuarios es una consideración importante para los arquitectos en cualquier
aplicación seria. Sin embargo, hay otra característica de las aplicaciones igualmente
importante, que es una de las principales prioridades para los arquitectos:
la escalabilidad de las aplicaciones. Imagine situaciones en las cuales se implementan
las aplicaciones y se obtiene gran rendimiento y disponibilidad con pocos usuarios,
pero en las cuales la disponibilidad y el rendimiento se degradan cuando crece
el número de usuarios. En ocasiones, una aplicación bajo carga normal funciona
bien, pero su rendimiento disminuye con el aumento de la cantidad de usuarios.
Esto sucede especialmente si el número de usuarios se incrementa repentinamente
y el entorno no está diseñado para tantos usuarios. Para adaptarse a estos picos
de demanda, podría tener aprovisionados hardware y ancho de banda. El desafío
yace en que la capacidad adicional no se usa la mayor parte del año y no ofrece
ningún retorno de la inversión. Están aprovisionados para usarse solo durante
algunos festivales u ofertas. Espero que esté entendiendo los problemas que los
arquitectos intentan resolver. Todos están relacionados con el dimensionamiento de
la capacidad y la escalabilidad de una aplicación. El foco de este capítulo está puesto
en comprender la escalabilidad como una cuestión arquitectónica y consultar los
servicios que proporciona Azure para la implementación de la escalabilidad.

En este capítulo, trataremos los siguientes temas:

• Escalabilidad
• Escalabilidad en las soluciones de IaaS y PaaS
• Aspectos básicos de los conjuntos de escala de las máquinas virtuales
• Arquitectura de VMSS
• Escalado automático en VMSS

[ 73 ]
Implementar la escalabilidad

• Reglas de escalado automático


• Escalado vertical (arriba y abajo)
• Escalado horizontal (crecimiento y reducción)
• Automatización relacionada con VMSS

Escalabilidad
El dimensionamiento y la planificación de la capacidad son unas de las principales
prioridades de los arquitectos en sus aplicaciones y servicios. Los arquitectos deben
encontrar un equilibrio entre comprar y aprovisionar demasiados recursos frente
a menos recursos. Contar con menos recursos puede llevar a no poder prestar
servicio a todos los usuarios, cediéndoselos a la competencia, mientras que contar
con más recursos puede dañar los presupuestos y el retorno de las inversiones, dado
que la mayoría de estos recursos permanecerán inactivos la mayor parte del tiempo.
Por otra parte, el problema se agrava con el variado nivel de demanda durante
diferentes épocas. Es casi imposible predecir el número de usuarios de la aplicación
durante el día y el año. Sin embargo, es posible encontrar un número aproximado
con información pasada y monitoreo continuo.

Según Wikipedia (https://en.wikipedia.org/wiki/Scalability),


escalabilidad se refiere a lo siguiente:

“La escalabilidad es la capacidad de un sistema, una red o un proceso de manejar


una cantidad creciente de trabajo, o su potencial de ampliación para dar lugar
a dicho crecimiento. Por ejemplo, un sistema se considera escalable si es capaz de
aumentar su capacidad total con una carga mayor cuando se agregan recursos
(generalmente, hardware)”.

La escalabilidad se refiere a la capacidad en el proceso de implementación de


las aplicaciones y a la tecnología para manejar un creciente número de usuarios
y proporcionarles el mismo nivel de rendimiento que cuando hay menos usuarios.
La escalabilidad puede referirse a atender más solicitudes sin degradación del
rendimiento o puede referirse a manejar un trabajo más grande y que requiere de
más tiempo sin pérdida de rendimiento en ambos casos.
Los arquitectos deben realizar ejercicios de dimensionamiento y planificación de la
capacidad al inicio del proyecto, durante la fase de planificación, para proporcionar
escalabilidad a las aplicaciones.
Algunas aplicaciones tienen patrones de demanda estable, mientras que es difícil
predecir otros. Los requisitos de escalabilidad son conocidos para aplicaciones de
demanda estable, pero es un proceso de mayor implicancia para aplicaciones de
demanda variable. El escalado automático, un concepto que revisaremos en la siguiente
sección, debe usarse para las aplicaciones cuya demanda no se puede predecir.
[ 74 ]
Capítulo 4

Escalabilidad frente a rendimiento


Es muy fácil confundir cuestiones arquitectónicas de escalabilidad y rendimiento,
porque la escalabilidad se trata de asegurar que, independientemente de la
cantidad de usuarios que consuman la aplicación, todos obtendrán el mismo nivel
predeterminado de rendimiento.
El rendimiento se refiere a las características de las aplicaciones que garantizan
que la aplicación satisfaga un resultado y un tiempo de respuesta predefinidos,
y la escalabilidad se refiere a tener aprovisionamiento de más recursos según sea
necesario a fin de adaptarse a más usuarios sin sacrificar el rendimiento.
Tal vez sea más fácil de entender a través de una analogía. La velocidad de un tren
se refiere al rendimiento de los sistemas ferroviarios; sin embargo, la capacidad
para que más trenes se desplacen en paralelo a la misma o a una mayor velocidad
se denomina escalabilidad de la red ferroviaria.

Escalabilidad de Azure
En esta sección, abordaremos características y funciones que ofrece Azure para lograr
que las aplicaciones tengan alta disponibilidad. Antes de adentrarnos en los detalles
de arquitectura y configuración, es importante entender los conceptos relacionados
con la alta disponibilidad de Azure.

Conceptos
Azure proporciona las siguientes construcciones fundamentales para lograr una alta
disponibilidad:
• Escalado
• Escalado vertical (arriba y abajo)
• Escalado horizontal (crecimiento y reducción)
• Escalado automático
• Actualizaciones graduales

Escalado
El escalado se refiere a la transformación que aumenta o disminuye las unidades de
recursos que se utilizan para responder a las solicitudes de los usuarios. El escalado
puede ser automático o manual. El escalado manual requiere que un administrador
inicie manualmente el proceso de escalado, mientras que el escalado automático se
refiere a un aumento o una disminución automáticos de recursos en función de los
acontecimientos disponibles en el entorno y el ecosistema, como la disponibilidad
de la CPU y la memoria. El escalado puede ser vertical, hacia arriba o hacia abajo,
y horizontal, crecimiento o reducción, como se explica más adelante en esta sección.
[ 75 ]
Implementar la escalabilidad

Escalado vertical hacia arriba


El escalado vertical hacia arriba de una máquina virtual o servicio se refiere a agregar
recursos adicionales a los servidores existentes, tales como CPU, memoria y discos.
Es para aumentar la capacidad de recursos y hardware físicos existentes.

Escalado vertical hacia abajo


El escalado vertical hacia abajo de una máquina virtual o servicio se refiere a quitar
recursos de los servidores existentes, tales como CPU, memoria y discos. Es para
disminuir la capacidad de recursos y hardware virtuales y físicos existentes.

Escalado horizontal de crecimiento


El escalado horizontal de crecimiento se refiere al proceso de agregar hardware
adicional en términos de capacidad y servidores adicionales. Por lo general, se trata
de agregar nuevos servidores, asignarles direcciones IP, implementar aplicaciones
en estos y hacerlos parte de los equilibradores de carga existentes, tales como el
tráfico que se puede enrutar a ellos. El escalado horizontal de crecimiento puede ser
automático o manual. Sin embargo, debe utilizarse la automatización para obtener
mejores resultados.

[ 76 ]
Capítulo 4

Escalado horizontal de reducción


El escalado horizontal de reducción se refiere al proceso de eliminación del hardware
existente en cuanto a capacidad y servidores existentes. Normalmente se trata de quitar
los servidores existentes, anular la asignación de sus direcciones IP y eliminarlos de la
configuración del equilibrador de carga existente de manera tal que no se pueda dirigir
tráfico a estos. Al igual que el escalado horizontal de crecimiento, el de reducción puede
ser automático o manual.

Escalado automático
El escalado automático se refiere al proceso de cualquier escalado vertical u horizontal
establecido de forma dinámica en función de la demanda de la aplicación y que
ocurre mediante automatización. El escalado automático es útil porque asegura que
la implementación siempre consista en una cantidad de instancias de servidor correcta
e ideal. El escalado automático ayuda a diseñar aplicaciones tolerantes a errores.
No solo ayuda a la escalabilidad, sino que también facilita una alta disponibilidad de
las aplicaciones. Por último, ofrece la mejor administración de los costos. El escalado
automático ayuda a obtener la configuración óptima en las instancias de servidor
en función de la demanda. Contribuye a evitar el aprovisionamiento excesivo de
servidores que están subutilizados o elimina servidores que ya no son necesarios
después del escalado horizontal de crecimiento.

Escalabilidad de PaaS
Azure proporciona servicios de aplicación para el alojamiento de aplicaciones
administradas. Los servicios de aplicación son una oferta de PaaS de Azure.
Esta incluye la plataforma web y móvil. Detrás de estas plataformas web y móviles
hay una infraestructura administrada que Azure gestiona en nombre de sus usuarios.
Los usuarios no ven ni administran la infraestructura; sin embargo, tienen la capacidad
para ampliar la plataforma e implementar sus aplicaciones en esta. De este modo,
los desarrolladores y arquitectos pueden concentrarse en sus problemas de negocio
en lugar de preocuparse por el aprovisionamiento de la plataforma de base y la
infraestructura, la configuración y la solución de problemas.
[ 77 ]
Implementar la escalabilidad

Los desarrolladores cuentan con la flexibilidad para elegir cualquier idioma, sistema
operativo y marcos con los cuales desarrollar sus aplicaciones. Los servicios de
aplicación proporcionan diferentes planes y, conforme a los planes seleccionados,
hay disponibles funciones de escalabilidad. Los servicios de aplicación ofrecen cinco
planes. Son los siguientes:

• Gratis: utiliza infraestructura compartida. Significa que varias aplicaciones se


implementarán en la misma infraestructura desde el mismo inquilino o desde
varios inquilinos. Brinda 1 GB de almacenamiento sin costo. No hay ninguna
posibilidad de escalado disponible en este plan.
• Compartido: también utiliza infraestructura compartida y brinda 1 GB de
almacenamiento sin costo. Además, también se proporcionan dominios
personalizados como una característica adicional. No hay ninguna
posibilidad de escalado disponible en este plan.
• Básico: tiene tres referencias de almacén (SKU) diferentes, B1, B2 y B3. Estas
poseen más unidades de recursos disponibles en términos de CPU y memoria.
En definitiva, proporcionan una mayor configuración de las máquinas virtuales
que respaldan estos servicios. Además, proporcionan almacenamiento, dominios
personalizados y soporte SSL. El plan básico proporciona características básicas
para el escalado manual. No hay ningún escalado automático disponible en este
plan. Se puede utilizar un máximo de tres instancias para el escalado horizontal
de crecimiento de la aplicación.
• Estándar: también tiene tres SKU diferentes: S1, S2 y S3. Estas poseen más
unidades de recursos disponibles en términos de CPU y memoria. En definitiva,
proporcionan una mayor configuración de las máquinas virtuales que respaldan
estos servicios. Además, proporcionan almacenamiento, dominios personalizados
y soporte SSL similar a los del plan básico. También ofrece un administrador
de tráfico, ranuras de transición y una copia de seguridad diaria como una
característica adicional a las del plan básico. El plan estándar proporciona
características para el escalado automático. Se puede utilizar un máximo de
10 instancias para el escalado horizontal de crecimiento de la aplicación.
• Premium: también tiene tres SKU diferentes: P1, P2 y P3. Estas poseen más
unidades de recursos disponibles en términos de CPU y memoria. En definitiva,
proporcionan una mayor configuración de las máquinas virtuales que respaldan
estos servicios. Además, proporcionan almacenamiento, dominios personalizados
y soporte SSL similar a los del plan básico. También ofrece un administrador
de tráfico, ranuras de transición y 50 copias de seguridad diarias como una
característica adicional a las del plan básico. El plan estándar proporciona
características para el escalado automático. Se puede utilizar un máximo de
20 instancias para el escalado horizontal de crecimiento de la aplicación.

[ 78 ]
Capítulo 4

Escalado vertical de PaaS


El escalado vertical de los servicios alojados en los servicios de aplicación es bastante
simple. Los elementos del menú de los servicios de la aplicación de Azure para escalado
hacia arriba abren una nueva hoja con todos los planes y sus SKU enumeradas.
La elección de un plan y una SKU escalará el servicio hacia arriba o hacia abajo.

Escalado horizontal de PaaS


El escalado horizontal de los servicios alojados en los servicios de la aplicación es
también bastante simple. Los elementos del menú de los servicios de la aplicación de
Azure para escalado horizontal de crecimiento abren una nueva hoja con opciones de
configuración del escalado.

[ 79 ]
Implementar la escalabilidad

De manera predeterminada, el escalado automático se encuentra desactivado para


planes estándar y premium. Puede activarse utilizando el elemento del menú Escalar
y haciendo clic en el botón Activar escalado automático.

El escalado manual no necesita configuración, pero el escalado automático ayuda


a realizar la configuración mediante las propiedades siguientes.

• Modo de escalado: se establece sobre la base de algunas métricas, tales como


uso de CPU o memoria, o solo escala para especificar la cantidad de instancias.
• Cuándo escalar: se pueden agregar varias reglas que determinan cuándo
realizar un escalado horizontal. Cada regla puede determinar los criterios
tales como el consumo de CPU o memoria, el aumento o la disminución de
instancias, y la cantidad de instancias que se tienen que aumentar o disminuir
por vez. Es necesario configurar al menos una regla de escalado horizontal
de crecimiento y una de reducción. La definición del umbral ayuda a definir
el cruce de los límites superior e inferior que activan el escalado automático,
ya sea con el aumento o la disminución de la cantidad de instancias.
• Cómo escalar: especifica cuántas instancias es necesario crear o a cuántas
anular el aprovisionamiento en cada escalado horizontal.

[ 80 ]
Capítulo 4

Escalabilidad de IaaS
Hay usuarios que quieren tener un control total sobre la infraestructura de base,
la plataforma y la aplicación. Prefieren consumir soluciones de IaaS en lugar de
soluciones de PaaS. Cuando estos clientes crean máquinas virtuales, también son
responsables de determinar el tamaño y el escalado de la capacidad. No hay una
configuración lista para usar para el escalado manual o automático de las máquinas
virtuales. Estos clientes tendrán que escribir sus propios scripts, desencadenantes
y reglas de automatización para lograr el escalado automático. Las máquinas virtuales
traen aparejadas la responsabilidad de su mantenimiento. Los parches, las mejoras
y las actualizaciones de las máquinas virtuales son responsabilidad de los propietarios.
Los arquitectos deben pensar en el mantenimiento tanto planificado como no
planificado. Para asegurarse de no comprometer la escalabilidad y disponibilidad
de una aplicación, es necesario considerar factores como los parches, el orden y la
agrupación de las máquinas virtuales, entre otros. Para ayudar a aliviar estos problemas,
Azure proporciona conjuntos de escalado de máquinas virtuales como una solución.

Conjuntos de escalado de máquinas


virtuales
Los conjuntos de escalado de máquinas virtuales (VMSS) son un recurso
informático de Azure que puede utilizar para implementar y administrar un
conjunto de máquinas virtuales idénticas. Con todas las máquinas virtuales
configuradas de la misma manera, los conjuntos de escalado están diseñados para
admitir un verdadero escalado automático, sin necesidad de un aprovisionamiento
de máquinas virtuales previo. Ayuda en el aprovisionamiento de varias máquinas
virtuales idénticas conectadas entre sí a través de una red y subred virtual.

[ 81 ]
Implementar la escalabilidad

VMSS crea un conjunto que se puede crear, configurar y administrar como una
unidad. Todas las máquinas virtuales son parte de esta unidad y los cambios
realizados se aplican a la unidad que, a su vez, los aplica a las máquinas virtuales
mediante un algoritmo predeterminado.

Permite la carga equilibrada de estas máquinas virtuales mediante el equilibrador de


carga o gateways de aplicación de Azure. El sistema operativo de todas las máquinas
virtuales puede ser Windows o Linux. Pueden ejecutar scripts automatizados
utilizando una extensión de PowerShell y se pueden administrar centralmente
mediante la configuración de estado deseada. También se pueden supervisar como
una unidad e individualmente mediante análisis de registro.

El aprovisionamiento de VMSS se puede realizar desde el portal de Azure, la interfaz


de línea de comandos de Azure, las plantillas del administrador de recursos de Azure,
las API REST y los cmdlet de PowerShell. Es posible invocar las API REST y la CLI de
Azure desde cualquier plataforma, entorno, sistema operativo e idioma.

Ya muchos de los servicios de Azure usan VMSS como arquitectura subyacente.


Entre estos, los principales son Azure Batch, Azure Service Fabric y los servicios de
contenedor de Azure. Los servicios de contenedor de Azure, a su vez, aprovisionan
Kubernetes y DC/OS en los conjuntos de escalado de máquina virtual.

[ 82 ]
Capítulo 4

Arquitectura de VMSS
VMSS permite la creación de hasta 1000 máquinas virtuales en un conjunto de escalado
cuando se utiliza una imagen de plataforma y 100 máquinas virtuales cuando se utiliza
una imagen personalizada. Si el número de máquinas virtuales es menos de 100 en un
conjunto de escalado, se colocan en un conjunto único de disponibilidad; sin embargo,
si son más de 100, se crean varios conjuntos de disponibilidad, conocidos como grupos
de colocación, y las máquinas virtuales se distribuyen entre ellos. Sabemos, por el
capítulo anterior, que las máquinas virtuales en un conjunto de disponibilidad se
colocan en dominios separados de error y actualización. De forma predeterminada,
los conjuntos de disponibilidad relacionados con VMSS poseen cinco dominios de
error y actualización. VMSS proporciona un modelo que contiene información de
metadatos para el todo el conjunto. Cambiar este modelo y aplicar cambios influye
en todas las instancias de las máquinas virtuales. Esta información incluye la cantidad
máxima y mínima de instancias de máquinas virtuales, versión y SKU del sistema
operativo, cantidad actual de máquinas virtuales, dominios de error y actualización, etc.

Escalado de VMSS
El escalado se refiere al aumento o la disminución de recursos informáticos y de
almacenamiento. VMSS es un recurso rico en características que hace que el escalado
sea simple y eficiente. Ofrece escalado automático que ayuda en el escalado vertical
en función de datos y acontecimientos externos, tales como uso de CPU y memoria.

[ 83 ]
Implementar la escalabilidad

Escalado horizontal frente a escalado vertical


El escalado puede ser horizontal o vertical, o ambos. El escalado horizontal es
otro nombre para referirse al escalado de crecimiento y reducción, mientras que el
escalado vertical se refiere al escalado hacia arriba y hacia abajo.

Capacidad
VMSS tiene una propiedad de capacidad que determina la cantidad de máquinas
virtuales de un conjunto de escala. VMSS puede implementarse con un valor de cero
para esta propiedad. No creará una sola máquina virtual; sin embargo, si aprovisiona
VMSS mediante un número para la propiedad de capacidad, se crea esa cantidad de
máquinas virtuales.

Escalado automático
El escalado automático de máquinas virtuales en VMSS se refiere al agregado o
la eliminación de instancias de máquina virtual según los entornos configurados
para satisfacer las demandas de rendimiento y escalabilidad de una aplicación.
En general, en ausencia de VMSS, esto se logra con runbooks y scripts de
automatización.

VMSS colabora en este proceso de automatización con ayuda de la configuración.


En lugar de escribir scripts, VMSS puede configurarse para escalado automático
hacia arriba y hacia abajo.

El escalado automático consiste de varios componentes integrados para lograr


su objetivo final. Supervisa en forma continua las máquinas virtuales y recopila
datos de telemetría. Almacena estos datos y los combina para evaluarlos con
respecto a un conjunto de reglas que determinan si es necesario activar el escalado
automático. El elemento desencadenante podría ser para un escalado de crecimiento
o reducción. También podría ser para un escalado hacia arriba o hacia abajo.

El escalado automático utiliza registros de diagnóstico para la recopilar datos


de telemetría de máquinas virtuales. Estos registros se almacenan en cuentas de
almacenamiento como métricas de diagnóstico. El escalado automático también
utiliza el servicio de supervisión de información que lee estas métricas, las combina
y las guarda en su cuenta de almacenamiento propia.

En forma continua, en segundo plano, se ejecutan trabajos de escalado automático


para leer los datos de almacenamiento de información y evaluarlos según todas las
reglas configuradas para escalado automático, y se ejecuta el proceso de escalado
automático, si algunas de las reglas o una combinación de ellas devuelve un
resultado positivo. Las reglas pueden tener en cuenta métricas de una máquina
virtual invitada y también del servidor host.
[ 84 ]
Capítulo 4

Las reglas se definen mediante las siguientes propiedades. Estas descripciones de


propiedades están disponibles en https://docs.microsoft.com/es-es/azure/
virtual-machine-scale-sets/virtual-machine-scale-sets-autoscale-
overview.

Regla Descripción
metricName Este valor es el mismo que el del contador de rendimiento
que definió en la variable wadperfcounter para la extensión
del diagnóstico. En el ejemplo anterior, se usa el contador cantidad
de subprocesos.
metricResourceUri Este valor es el identificador de recursos de VMSS. Este
identificador contiene el nombre del grupo de recursos,
el nombre del proveedor de recursos y el nombre del
conjunto de escala que se escalará.
timeGrain Este valor es la granularidad de las métricas que se
recopilan. En el ejemplo anterior, los datos se recopilan
en un intervalo de un minuto. Este valor se utiliza con
timeWindow.
statistic Este valor determina cómo se combinan las métricas para
adaptar la acción de escalado automático. Los valores
posibles son: average, min y max.
timeWindow Este valor es el intervalo de tiempo en el que se recopilan
datos de instancia. Tiene que ser de entre 5 minutos
y 12 horas.
timeAggregation Este valor determina cómo tienen que combinarse los datos
que se recopilan en el tiempo. El valor predeterminado es
promedio. Los valores posibles son: average, minimum,
maximum, last, total y count.
operator Este valor es el operador que se utiliza para comparar los
datos de las métricas y el umbral. Los valores posibles son:
Equals,NotEquals,GreaterThan,GreaterThanOrEqual,LessThany
LessThanOrEqual.
threshold Este valor es el valor que desencadena la acción de
escalado. Asegúrese de proporcionar una diferencia
suficiente entre los valores de umbral para las acciones
de escalado de crecimiento y reducción. Si establece los
mismos valores para ambas acciones, el sistema anticipa
un cambio constante, que le impide implementar una
acción de escalado. Es decir, en el ejemplo anterior,
configurar ambos en 600 subprocesos no funciona.

[ 85 ]
Implementar la escalabilidad

Regla Descripción
direction Este valor determina la acción que se toma cuando se
alcanza el valor de umbral. Los valores posibles son
increase o decrease.
type Este valor es el tipo de acción que tendría que ocurrir y
tiene que configurarse como ChangeCount.
value Este valor es la cantidad de máquinas virtuales que se
agrega o se elimina del conjunto de escala. Este valor tiene
que ser 1 o superior.
cooldown Este valor es la cantidad de tiempo de espera para la última
acción de escalado antes de que ocurra la próxima acción.
Este valor tiene que ser de entre un minuto y una semana.

La arquitectura de escalado automático se muestra en el siguiente diagrama:

[ 86 ]
Capítulo 4

El escalado automático puede configurarse para situaciones que son más complejas
que las métricas generales disponibles desde los entornos. Por ejemplo, el escalado
podría basarse en cualquiera de los siguientes eventos:

• Escalado de un día específico


• Escalado de calendario recurrente, como los fines de semana
• Escalado diferente los días de semana y fines de semana
• Escalado durante los feriados, uno de los eventos
• Escalado de múltiples métricas de recursos

Estos pueden configurarse con la propiedad de calendario de los recursos de


información que sirven para registrar las reglas.

Los arquitectos tienen que garantizar que al menos dos acciones se configuren juntas,
escalado de crecimiento y de reducción. La configuración de escalado de reducción
o de crecimiento no ayudará a lograr beneficios de escalado provistos por VMSS.

Actualizaciones
Después de que se implementan VMSS y las aplicaciones, es necesario un
mantenimiento activo. El mantenimiento planificado tiene que realizarse
periódicamente para asegurar que el entorno y la aplicación estén actualizados
con lo más reciente y que el entorno esté actualizado desde el punto de vista de
la seguridad y la resistencia.

Las actualizaciones pueden estar asociadas a las aplicaciones, la instancia de


máquina virtual invitada o la propia imagen. Las actualizaciones pueden ser bastante
complejas porque tienen que ocurrir sin afectar la disponibilidad, la escalabilidad
y el rendimiento de los entornos y las aplicaciones. Para asegurarse de que las
actualizaciones sucedan de una instancia por vez con los métodos de actualización
gradual, es importante que VMSS admita y proporcione capacidades para estas
situaciones avanzadas.

[ 87 ]
Implementar la escalabilidad

Existe una utilidad proporcionada por el equipo de Azure para administrar las
actualizaciones de VMSS. Es una utilidad basada en Python que puede descargarse
de https://github.com/gbowerman/vmssdashboard. Realiza llamadas API REST
a Azure para administrar los conjuntos de escala. Esta utilidad puede usarse para
comenzar, detener, actualizar y restablecer la imagen de máquinas virtuales en un
dominio de error o grupo de máquinas virtuales.

[ 88 ]
Capítulo 4

Actualizaciones de aplicación
Las actualizaciones de aplicación en VMSS no tienen que ejecutarse manualmente.
Tienen que ejecutarse como parte de la administración y canalización de lanzamiento
mediante automatización. Por otra parte, la actualización tiene que suceder en una
instancia de aplicación a la vez y no afectar la disponibilidad y la escalabilidad
generales de la aplicación. Las herramientas de administración de configuración, como
la configuración de estado deseado, tienen que implementarse para administrar las
actualizaciones de la aplicación. El servidor de extracción DSC puede configurarse con
la última versión de las partes y tiene que aplicarse en forma gradual a cada instancia.

Actualizaciones de invitado
Las actualizaciones de la máquina virtual son responsabilidad del administrador.
Azure no es responsable de aplicar parches a máquinas virtuales invitadas. Las
actualizaciones de invitado están en modo de vista previa, y los usuarios tienen que
controlar los parches manualmente o usar la automatización personalizada, como
runbooks y scripts. Sin embargo, las actualizaciones de parche graduales están
en vista previa y pueden configurarse en la plantilla de ARM con la directiva de
actualización, como se muestra aquí:
"upgradePolicy": {
"mode": "Rolling",
"automaticOSUpgrade": "true" or "false",
"rollingUpgradePolicy": {
"batchInstancePercent": 20,
"maxUnhealthyUpgradedInstanceCount": 0,
"pauseTimeBetweenBatches": "PT0S"
}
}sssssssssssss

Actualizaciones de imagen
VMSS puede actualizar la versión del sistema operativo sin ningún tiempo de
inactividad. La actualización del sistema operativo implica cambiar la versión o SKU
del sistema operativo o cambiar la URI de una imagen personalizada. La actualización
sin tiempo de inactividad implica actualizar máquinas virtuales de a una por vez o en
grupos (por ejemplo, un dominio de error a la vez) en lugar de todas al mismo tiempo.
Al hacerlo de esta manera, cualquier máquina virtual que no se esté actualizando
puede seguir funcionando.

[ 89 ]
Implementar la escalabilidad

Procedimientos recomendados de
escalado
En esta sección, analizaremos algunos de los procedimientos recomendados
que tienen que implementar las aplicaciones para aprovechar la capacidad de
escalabilidad de VMSS.

Preferencia de escalado de crecimiento


El escalado de crecimiento es una mejor solución de escalado, comparada con el
escalado hacia arriba. El escalado hacia arriba o abajo implica volver a dimensionar
las instancias de máquinas virtuales. Cuando se vuelve a dimensionar una máquina
virtual, generalmente necesita reiniciarse, y eso tiene sus propias desventajas.
En primer lugar, hay un tiempo de inactividad de la máquina. Además, si hay usuarios
activos conectados a la aplicación en esa instancia, podrían enfrentar una falta de
disponibilidad de la aplicación o incluso una pérdida de transacciones. El escalado de
crecimiento no afecta las máquinas virtuales existentes. Aprovisiona máquinas nuevas
y las agrega al grupo.

Instancias sin sistema operativo frente


a instancias inactivas
El escalado de instancias nuevas puede implicar dos enfoques amplios. Ya sea crear
la nueva instancia desde cero, que significa instalar aplicaciones, configurar y probar,
mientras que por otro lado, puede haber instancias inactivas latentes que pueden
iniciarse si fuera necesario debido a la presión de escalabilidad en otros servidores.

Configuración adecuada de la cantidad


máxima y mínima de instancias
Si se establece un valor de dos para ambos recuentos de instancia mínima y máxima
con el recuento de la instancia actual de dos, no puede ocurrir ninguna acción de
escalado. Es necesario un margen suficiente entre los recuentos de instancia máxima
y mínima, que son inclusivos. El escalado automático siempre escala entre estos límites.

[ 90 ]
Capítulo 4

Simultaneidad
Las aplicaciones están diseñadas para que la escalabilidad se centre en la simultaneidad.
La aplicación tiene que usar patrones asincrónicos para garantizar que las solicitudes
de cliente no esperen de manera indefinida la adquisición de recursos si estos están
ocupados con otras solicitudes. La implementación de patrones asincrónicos en código
garantiza que los subprocesos no esperen recursos y que los sistemas se agoten de todos
los subprocesos disponibles. Las aplicaciones tienen que implementar el concepto de
tiempo de espera si se esperan fallas intermitentes.

Sin estado
Las aplicaciones y los servicios tienen que diseñarse para no tener estado.
La escalabilidad puede convertirse en un desafío con servicios con estado y, por el
contrario, es muy fácil escalar servicios sin estado. El estado supone el requisito de
otros componentes e implementación, como replicación, repositorio centralizado
o descentralizado, mantenimiento y sesiones de afinidad. Todos estos son obstáculos
en el camino de la escalabilidad. Imagine un servicio que mantenga un estado activo
en un servidor local. Independientemente de la cantidad de solicitudes en una
aplicación general o en un servidor individual, el mismo servidor tiene que encargarse
de las solicitudes posteriores. Otros servidores no pueden procesar las solicitudes
posteriores. Esto hace que la implementación de la escalabilidad sea un desafío.

Almacenamiento en caché y CDN


Las aplicaciones y los servicios tienen que aprovechar el almacenamiento en
caché. El almacenamiento en caché ayuda a eliminar varias llamadas posteriores
a cualquier base de datos del sistema de archivos. Esto ayuda a que los recursos
estén disponibles y listos para más solicitudes. La red de distribución de contenido
(CDN) es otro mecanismo para almacenar en caché archivos estáticos, como
imágenes y bibliotecas de JavaScript. Están disponibles en los servidores de todo
el mundo. También permiten que los recursos estén disponibles y listos para otras
solicitudes de cliente. Esto hace que las aplicaciones sean altamente escalables.

Diseño N+1
El diseño N+1 se refiere a desarrollar redundancia dentro de la implementación
general para cada componente. Eso significa planificar cierta redundancia, incluso
cuando no es necesaria. Podría implicar máquinas virtuales, almacenamiento
y tarjeta de interfaz de red adicionales.

[ 91 ]
Implementar la escalabilidad

Resumen
La escalabilidad es una cuestión arquitectónica importante y crucial. Casi todas
las aplicaciones y cada arquitecto intentan implementar escalabilidad junto con
la disponibilidad y el rendimiento. Azure es una plataforma consolidada que
entiende la necesidad de escalabilidad para las aplicaciones y ofrece opciones de
escalabilidad para soluciones de PaaS e IaaS. Los servicios de aplicación de PaaS
pueden configurarse para escalado automático, y las máquinas virtuales pueden
implementarse en un conjunto de escala para aprovechar el escalado. El escalado
puede ser hacia arriba, hacia abajo, de crecimiento o de reducción. Al igual que la
alta disponibilidad, la escalabilidad no es un aspecto secundario y tiene que ser parte
del desarrollo del ciclo de vida de la aplicación desde la fase de planificación misma.
El escalado puede ser vertical, si aumenta el tamaño de la instancia de máquina virtual,
u horizontal, en el que los servidores adicionales se agregan al conjunto existente.
VMSS proporciona un modelo que contiene información de metadatos para el todo el
conjunto. Cambiar este modelo y aplicar cambios influye en todas las instancias de las
máquinas virtuales. Esto permite actualizar, redimensionar, detener e iniciar máquinas
virtuales de forma gradual. Por último, en este capítulo se analizaron algunos de los
procesos recomendados importantes relacionados con la escalabilidad.

En el próximo capítulo se abarca la seguridad, que es la preocupación más importante


de la arquitectura para las implementaciones en la nube.

[ 92 ]
Seguridad de la nube
La seguridad es, sin dudas, el requisito no funcional más importante que tienen que
implementar los arquitectos. Las empresas priorizan que su estrategia de seguridad
se implemente correctamente y prestan especial atención para conseguirlo. De
hecho, la seguridad es una de las preocupaciones principales de casi todas las
partes interesadas en cualquier desarrollo, implementación y administración de
aplicaciones. E incluso esto adquiere más importancia cuando la misma aplicación se
diseña para la implementación en la nube.

La ejecución de aplicaciones y sistemas que están disponibles para el consumo


de los usuarios es una consideración importante para los arquitectos en cualquier
aplicación seria. Sin embargo, hay otra característica de las aplicaciones igualmente
importante, que es una de las principales prioridades para los arquitectos: la
escalabilidad de las aplicaciones. Imagine situaciones en las cuales se implementan
las aplicaciones y se obtiene gran rendimiento y disponibilidad con pocos usuarios,
pero en las cuales la disponibilidad y el rendimiento se resienten cuando crece la
cantidad de usuarios. Otra situación se da cuando si bien la aplicación es de alto
rendimiento y está disponible cuando hay gran cantidad de usuarios, en cierto
momento del día o la semana, o con determinados eventos especiales, hay picos de
usuarios y usted no puede medir o predecir la cantidad de usuarios. Ampliando
la situación anterior, usted podría haber aprovisionado el hardware y el ancho de
banda para lidiar con los usuarios durante estas ocasiones y en picos de usuarios;
sin embargo, la mayor parte del tiempo, el hardware adicional no se usa y no ofrece
ningún retorno de la inversión. Se aprovisionan para utilizarlos solo en unos pocos
festivales y ofertas. Espero que esté entendiendo los problemas que los arquitectos
intentan resolver. Todos están relacionados con el dimensionamiento de la capacidad
y la escalabilidad de una aplicación. En enfoque de este capítulo está puesto en
comprender la escalabilidad como un problema arquitectónico y en detallar las
características de Azure para tratar estos problemas.

[ 93 ]
Seguridad de la nube

En este capítulo, trataremos los siguientes temas:

• Principios de seguridad
• Seguridad de Azure
• Cumplimiento y certificación
• Directorio:
°° Identidad y autenticación
°° Autorización
°° oAuth y Open Connect
• Seguridad de IaaS:
°° Seguridad de red
°° Seguridad informática
°° Seguridad de almacenamiento
• Seguridad de PaaS:
°° SQL Server
°° Key Vault
• Servicios de seguridad
• Azure Security Center
• OMS, supervisión y auditoría
• Centro de confianza de Azure

Seguridad
Asegurar una aplicación significa no permitir que entidades desconocidas y no
autorizadas accedan a la aplicación. También significa que la comunicación con la
aplicación es segura y no está comprometida.

Esto incluye lo siguiente:

• Autenticación: se refiere a establecer la identidad de un usuario y garantizar


que la identidad dada puede acceder a la aplicación o el servicio. La
autenticación se realiza en Azure mediante Open Connect, lo que también se
conoce como ConnectID.
• Autorización: se refiere a permitir y establecer permisos que una identidad
pueda desempeñarse dentro de la aplicación o el servicio. La autorización se
lleva a cabo en Azure mediante tecnología de oAuth.

[ 94 ]
Capítulo 5

• Confidencialidad: se refiere a que la comunicación entre el usuario y la aplicación


es segura. El intercambio de carga entre entidades se cifra de manera que solo
tenga sentido para el remitente y el receptor. La confidencialidad de los mensajes
se lleva a cabo mediante cifrado simétrico y asimétrico. Los certificados se usan
para implementar la criptografía: el cifrado y descifrado de los mensajes.
• Integridad: la integridad garantiza que el intercambio de capacidad de carga
y mensajes entre el remitente y el receptor no está comprometido. El receptor
recibe el mensaje tal como lo envió el remitente. Los hashes y las firmas
digitales son el mecanismo de implementación para comprobar la integridad
de los mensajes entrantes.

La seguridad es una asociación entre el proveedor y el consumidor del servicio. Ambas


partes tienen diferentes niveles de control sobre las pilas de implementación completas,
y cada una tiene que implementar los procedimientos recomendados de seguridad
para garantizar que se identifiquen y mitiguen todas las amenazas. Ya vimos en el
Capítulo 1, Introducción, que la nube ofrece tres grandes paradigmas a grandes rasgos:
IaaS, PaaS y SaaS, cada uno con diferentes niveles de control colaborativo sobre la pila
de implementación. Cada parte tiene que implementar prácticas de seguridad para los
componentes bajo su control y ámbito. La falta de implementación de seguridad en
cualquier capa de la pila o por cualquiera de las partes volvería vulnerables a ataques a la
implementación y la aplicación en su conjunto.

Ciclo de vida de la seguridad


La seguridad generalmente se considera un requisito no funcional para una solución.
Sin embargo, con el crecimiento de los ataques cibernéticos, actualmente se considera
un requisito funcional.

Cada organización sigue algún tipo de administración del ciclo de vida de sus
aplicaciones. Cuando la seguridad se trata como un requisito funcional, esta tiene que
seguir el mismo proceso de desarrollo de la aplicación. La seguridad no tiene que dejarse
para después, más bien tiene que ser parte de la aplicación desde el principio. Dentro
de la fase de planificación general de una aplicación, también es necesario planificar la
seguridad. Según la naturaleza de la aplicación, es necesario identificar diferentes tipos
y categorías de amenazas y, en función de esto, documentar su enfoque y alcance para
mitigarlas. Se recomienda realizar un ejercicio de modelado de amenazas para ilustrar
la amenaza de la que cada componente puede ser objeto. Esto conducirá al diseño de
políticas y estándares de seguridad para la aplicación. Por lo general, es la fase de diseño
de la seguridad. A la siguiente fase se la denomina Mitigación de amenazas o fase de
Diseño. En esta fase, se ejecuta la implementación de la seguridad en términos de código
y configuración para mitigar los riesgos y las amenazas a la seguridad.

[ 95 ]
Seguridad de la nube

Un sistema no puede ser seguro hasta que se prueba. Es necesario realizar pruebas
de penetración adecuadas y otras pruebas de seguridad para identificar potenciales
mitigaciones que no están implementadas, que faltan o que se han pasado por alto.
Se corrigen los errores de las pruebas y el ciclo continúa hasta el fin de la vida de la
aplicación. Este es el proceso de administración del ciclo de vida de la aplicación que
tiene que seguirse por cuestiones de seguridad.

El modelado, la identificación, la mitigación, la prueba y la corrección de las amenazas


son procesos iterativos que continúan incluso cuando una aplicación o un servicio está en
funcionamiento. Es necesaria una supervisión activa de todos los entornos y las aplicaciones
para identificar las amenazas y mitigarlas de manera proactiva. La supervisión también
tiene que activar las alertas y los registros de auditoría para ayudar en los diagnósticos
reactivos, la solución de problemas y la eliminación de amenazas y vulnerabilidades.

El ciclo de vida de la seguridad de cualquier aplicación comienza con la fase de


planificación, que conduce finalmente a la fase de diseño. En la fase de diseño, la
arquitectura de la aplicación se descompone en componentes granulares con límites
de alojamiento y comunicación discreta. Las amenazas se identifican en función de
su interacción con otros componentes dentro los límites de alojamiento, y entre estos.
Las amenazas identificadas se mitigan mediante la aplicación de las características de
seguridad adecuadas dentro de la estructura general y se prueban para determinar si
esta vulnerabilidad sigue existiendo. Después de que se implementa la aplicación en
la producción y esta se vuelve operativa, se supervisa para detectar las infracciones de
seguridad y la vulnerabilidad, y se lleva a cabo una corrección de reacción o proactiva.

[ 96 ]
Capítulo 5

Seguridad de Azure
Azure ofrece todos sus servicios a través de centros de datos en varias regiones. Estos
centros de datos están interconectados dentro de las regiones, así como entre ellas. Azure
entiende que aloja aplicaciones, servicios y datos importantes y esenciales de sus clientes.
Tiene que garantizar que la seguridad sea de suma importancia para las regiones y sus
centros de datos. Los clientes implementan aplicaciones en la nube sobre la base de la
confianza en que Azure protegerá sus aplicaciones y datos contra vulnerabilidades e
infracciones. Los clientes no se trasladarán a la nube si se rompe esta confianza y, por
lo tanto, Azure implementa seguridad en todas las capas, desde el perímetro físico del
centro de datos hasta los componentes de software lógico. Cada capa está protegida,
e incluso el equipo del centro de datos de Azure no tiene acceso a ellas.

La seguridad es de primordial importancia para Microsoft y Azure. Azure es una


plataforma en la nube alojada por Microsoft. Microsoft asegura que se construya la
confianza con sus clientes y lo hace garantizando que la implementación, las soluciones
y los datos de sus clientes están totalmente seguros, física y virtualmente. La gente
no utilizará ninguna plataforma en la nube si no es segura física y digitalmente. Para
garantizar que los clientes tengan confianza en Azure, cada actividad de desarrollo de
Azure se planea, documenta, audita y supervisa desde una perspectiva de seguridad.
Los centros de datos físicos de Azure están protegidos contra cualquier intrusión
y acceso no autorizado. De hecho, ni el equipo de operaciones ni el personal de
Microsoft tienen acceso a los datos y la solución del cliente.
• Acceso seguro del usuario: solo el cliente puede acceder a su implementación,
solución y datos. Incluso el personal del centro de datos de Azure no tiene
acceso a ningún artefacto del cliente. Los clientes pueden brindar acceso a más
personas; sin embargo, eso es a discreción del cliente.

[ 97 ]
Seguridad de la nube

• Cifrado en reposo: Azure cifra todos sus datos administrados de manera que
nadie pueda leerlos. También proporciona esta funcionalidad a sus clientes,
así como a quienes pueden cifrar sus datos en reposo.
• Cifrado en tránsito: Azure cifra todos los datos que salen de su red. También
garantiza que su red troncal esté protegida contra cualquier acceso no autorizado.
• Supervisión y auditoría activas: Azure supervisa todos sus centros de datos
activamente de forma continua. Identifica activamente cualquier infracción,
amenaza y riesgo, y los mitiga.

Azure cumple tanto con los estándares de cumplimiento internacionales y locales


específicos de cada país como con los específicos de cada sector. Una vez más, estos
se pueden encontrar en https://www.microsoft.com/en-us/trustcenter/
compliance/complianceofferings.

Seguridad de IaaS
Azure es una plataforma madura para implementar soluciones de IaaS. Muchos usuarios
de Azure quieren tener el control total sobre sus implementaciones y normalmente usan
IaaS para sus soluciones. Es importante que estas implementaciones y soluciones sean
seguras desde su diseño y de forma predeterminada. Azure proporciona características
de seguridad enriquecidas para asegurar las soluciones de IaaS. En esta sección se
tratarán algunas de las características principales.

Grupos de seguridad de red


La implementación mínima de IaaS consta de máquinas virtuales y redes virtuales. Las
máquinas virtuales pueden estar expuestas a Internet mediante la aplicación de una IP
pública a su interfaz de red o pueden estar disponibles a recursos internos únicamente.
Los recursos internos, a su vez, pueden estar expuestos a Internet. En cualquier caso, es
necesario asegurar las máquinas virtuales de manera que las solicitudes no autorizadas
ni siquiera lleguen a ellas. Es necesario asegurar las máquinas virtuales mediante
instalaciones que puedan filtrar las solicitudes en la propia red, en lugar de permitir
que lleguen a la máquina virtual antes de tomar medidas. Esto es como crear un cerco
alrededor de las máquinas virtuales. Este cerco puede permitir o denegar solicitudes
en función de su protocolo, IP de origen, IP de destino, puerto de origen y puerto de
destino. Esta característica se implementa mediante el recurso de grupos de seguridad
de red (NSG) de Azure. El NSG está compuesto por reglas que se evalúan en las
solicitudes entrantes y salientes. Según la ejecución y evaluación de estas reglas, se
determina si se tiene que permitir o denegar el acceso a las solicitudes.

[ 98 ]
Capítulo 5

Los NSG son flexibles y pueden aplicarse a una subred de red virtual o a interfaces de red
individuales. Cuando se aplican a una subred, las reglas de seguridad aplican a cualquier
recurso, es decir, a máquinas virtuales o equilibradores de carga de esta subred; mientras
que, cuando se aplican a una interfaz de red, esto solo afecta las solicitudes de dicha interfaz.
También es posible aplicar NSG a interfaces de red y subredes de la red al mismo tiempo. Por
lo general, es necesario usar este diseño para la aplicación de reglas de seguridad comunes en
el nivel de subred de la red y reglas de seguridad únicas y diferentes en el nivel de la interfaz
de red. Ayuda en el diseño de las aplicaciones y las reglas de seguridad modular.
El flujo de evaluación del NSG se muestra en la siguiente figura:

Azure proporciona algunas reglas predeterminadas listas para usar. Son muy
importantes y prácticas cuando las implementaciones desean utilizar reglas relacionadas
con solicitudes desde/hacia Internet, redes virtuales y equilibradores de carga. Por lo
general, las direcciones IP son siempre cambiantes para estos recursos, y el uso de estas
reglas proporciona una abstracción para usar estas direcciones IP directamente.

Diseño del grupo de seguridad de red


El primer paso en el diseño es determinar los requisitos de seguridad del recurso.
Es necesario responder a lo siguiente:
• ¿Solo se puede acceder al recurso desde Internet?
• ¿Se puede acceder al recurso tanto desde Internet como desde los recursos internos?
• ¿Solo se puede acceder al recurso desde los recursos internos?
• Determine el equilibrador de carga, los gateways y las máquinas virtuales del
recurso utilizados.
• Configuración de una red virtual y su subred.

[ 99 ]
Seguridad de la nube

En función de las respuestas a estas preguntas, se tiene que crear el diseño aceptable del NSG.

Idealmente, tiene que haber varias subredes de red para cada carga de trabajo y
tipo de recurso. No se recomienda implementar equilibradores de carga y máquinas
virtuales en la misma subred.

Según los requisitos, tienen que determinarse las reglas que son comunes para las
subredes y las cargas de trabajo de las distintas máquinas virtuales. Por ejemplo, para una
implementación de SharePoint, la aplicación de frontend y los SQL Server se implementan
en subredes independientes. Es necesario determinar las reglas para cada subred.

Después de identificar las reglas comunes en el nivel de la subred, es necesario


identificar las reglas de los recursos individuales y estas tienen que aplicarse en el
nivel de interfaz de red.

Es importante entender que si una regla permite una solicitud entrante en un puerto,
ese puerto también puede emplearse para las solicitudes salientes sin necesidad de
ninguna configuración.

Si se accede a los recursos desde Internet, las reglas tienen que crearse con
determinados puertos e intervalos de IP en la medida de lo posible.

Es necesario ejecutar pruebas funcionales y de seguridad cuidadosamente para


garantizar que se abran y cierren reglas de NSG suficientes y óptimas.

Firewalls
Los NSG ofrecen perímetros de seguridad externos para las solicitudes. Sin
embargo, esto no significa que las máquinas virtuales no necesitan implementar
medidas adicionales de seguridad. Siempre es mejor implementar la seguridad tanto
interna como externamente. Las máquinas virtuales, ya sea en Linux o Windows,
proporcionan un mecanismo para filtrar las solicitudes en el nivel del sistema
operativo. Esto se conoce como firewall tanto en Windows como en Linux.

Es recomendable implementar firewalls para sistemas operativos. Contribuyen a la


construcción de un muro de seguridad virtual que ayuda a permitir solo aquellas
solicitudes que se consideran de confianza. A las solicitudes no confiables se les
niega el acceso. También hay dispositivos de firewall físicos, pero en el software de la
nube se utilizan firewalls de sistema operativo.

[ 100 ]
Capítulo 5

Los firewalls ayudan a filtrar paquetes de red y a identificar puertos entrantes


y direcciones IP. En función de la información de estos paquetes, el firewall evalúa
las reglas y determina si se tiene que permitir el acceso o negarlo.

Diseño del firewall


Es recomendable evaluar los firewalls para sistemas operativos individuales.
Cada máquina virtual tiene una responsabilidad distinta dentro de la solución e
implementación en general. Para estas responsabilidades individuales, es necesario
identificar las reglas y abrir y cerrar los firewalls de forma acorde.

En la evaluación de las reglas del firewall, es importante considerar las reglas de los
grupos de seguridad de red tanto de los niveles de interfaz de red individual como de
subred. Si esto no se hace correctamente, es posible que se denieguen las reglas en el nivel
del NSG, pero que se dejen abiertas en el nivel del firewall, y viceversa. Si una solicitud se
permite en el nivel de las reglas del NSG y se deniega en el nivel del firewall, la aplicación
no funcionará según lo previsto, mientras que los riesgos de seguridad aumentan si la
solicitud se deniega en el nivel de las reglas del NSG y se permite en el nivel del firewall.

Un firewall ayuda en la construcción de varias redes aisladas por sus reglas de seguridad.

Es necesario ejecutar pruebas funcionales y de seguridad cuidadosamente para


garantizar que se abran y cierren reglas del firewall suficientes y óptimas.

[ 101 ]
Seguridad de la nube

Reducir la superficie de ataque


Los NSG y el firewall ayudan en la administración de solicitudes autorizadas en
el entorno. Sin embargo, no tiene que exponerse abiertamente el entorno a ataques
de seguridad. La superficie del sistema tiene que estar activada de manera óptima
para poder lograr su funcionalidad, pero lo suficientemente desactivada para que
los atacantes no puedan encontrar lagunas y áreas de acceso abiertas sin ningún uso
previsto o abiertas sin una seguridad suficiente. La seguridad tiene que tener una
fortaleza adecuada como para dificultar que cualquier atacante irrumpa en el sistema.

Las siguientes son algunas de las áreas que es necesario configurar:

• Eliminar todos los usuarios y grupos innecesarios del SO.


• Identificar la pertenencia a grupos de todos los usuarios.
• Implementar políticas de grupo mediante servicios de directorio.
• Bloquear la ejecución del script a menos que la hayan firmado autoridades de
confianza.
• Registrar y auditar todas las actividades.
• Instalar software antivirus y malware, programar análisis y actualizar
definiciones con frecuencia.
• Desactivar o cerrar servicios que no son necesarios.
• Bloquear el sistema de archivos solo para acceso autorizado.
• Bloquear cambios en el registro.
• Configurar el firewall según las necesidades de la solución.
• Establecer la ejecución del script PowerShell como restringida o RemoteSigned.
• Activar protección mejorada a través de Internet Explorer.
• Restringir la capacidad de crear nuevos usuarios y grupos.
• Eliminar el acceso a Internet e implementar los servidores de salto para RDP.
• No permitir el inicio de sesión en servidores que utilizan RDP a través de
Internet. En su lugar, utilizar VPN de sitio a sitio, VPN de punto a sitio o
ExpressRoute a RDP en máquinas remotas desde dentro de la red.
• Implementar regularmente todas las actualizaciones de seguridad.
• Ejecutar la herramienta del administrador de cumplimiento de normas de
seguridad en el entorno y poner en práctica todas sus recomendaciones.
• Supervisar activamente el entorno mediante un centro de seguridad y un
conjunto de administración de operaciones.
• Implementar dispositivos virtuales de red para redirigir el tráfico al proxy
interno y proxy inverso.
• Cifrar todos los datos confidenciales tales como los de configuración, cadenas
de conexión, credenciales, entre otros.
[ 102 ]
Capítulo 5

Implementar servidores de salto


Se recomienda eliminar el acceso a Internet desde máquinas virtuales. Además de
quitar accesibilidad a los servicios de escritorio remoto desde Internet. Pero, entonces,
¿cómo acceder a las máquinas virtuales? Una buena manera de hacerlo es permitir solo
recursos internos de RDP en las máquinas virtuales que utilizan las opciones de VPN de
Azure. Sin embargo, también hay otra manera: mediante el uso de servidores de salto.
Los servidores de salto son servidores implementados en la zona desmilitarizada (DMZ). Esto
significa que está en una red diferente y no en el hosting de red de las aplicaciones y soluciones
principales. En cambio, está en una red o subred independiente. El propósito principal del
servidor de salto es aceptar las solicitudes de RDP de los usuarios y ayudarlos a iniciar sesión.
Desde este servidor de salto, los usuarios pueden navegar incluso a otras máquinas virtuales
mediante RDP. Tiene acceso a dos o más redes: una que tiene conectividad con el mundo
exterior y otra interna de la solución. El servidor de salto implementa todas las restricciones de
seguridad y proporciona un cliente seguro para conectarse a otros servidores. Normalmente,
el acceso a Internet y correos electrónicos en los servidores de salto está desactivado.

Hay un ejemplo de implementación de un servidor de salto con los conjuntos de


escala de máquina virtual (VMSS) disponible en https://azure.microsoft.
com/es-es/resources/templates/201-vmss-windows-jumpbox/ mediante las
plantillas del administrador de recursos de Azure.

Seguridad de PaaS
Azure proporciona numerosos servicios de PaaS, y cada uno posee sus propias
características de seguridad. En general, puede accederse a los servicios de PaaS
mediante credenciales, certificados y tokens. Los servicios de PaaS permiten la
generación de tokens de acceso de seguridad de corta duración. Las aplicaciones
cliente pueden enviar este token de acceso de seguridad para representar a usuarios
de confianza. En esta sección, abordaremos algunos de los servicios de PaaS más
importantes que se utilizan en casi todas las soluciones.

Operations Management Suite (OMS)


Microsoft Management Suite, también conocido como análisis de registro, es una
nueva plataforma para administrar implementaciones de nube, centros de datos
locales y soluciones híbridas.
OMS ofrece varias soluciones modulares: funcionalidad específica que ayuda a implementar
una función. Por ejemplo, las soluciones de seguridad y auditoría ayudan a determinar
una visión completa de la seguridad para la implementación en organizaciones. Del mismo
modo, hay muchas más soluciones como la automatización y el control de cambios, entre
otras, que es necesario implementar desde una perspectiva de seguridad.

[ 103 ]
Seguridad de la nube

La auditoría y seguridad de OMS ofrece información en cuatro categorías:

• Dominios de seguridad: ofrece la funcionalidad de ver registros de


seguridad, evaluación de malware, evaluación de actualizaciones, seguridad
de red, información de identidad y acceso, y equipos con eventos de
seguridad, y brinda acceso al panel del centro de seguridad de Azure.
• Evaluación antimalware: ayuda en la identificación de servidores que no
están protegidos contra malware y tienen problemas de seguridad. Ayuda
a ofrecer una exposición general a posibles problemas de seguridad y su
criticidad. Los usuarios pueden adoptar medidas proactivas en función de
estas recomendaciones. La subcategoría del centro de seguridad de Azure
ofrece información recopilada por el centro de seguridad de Azure.
• Problemas considerables: ayuda a identificar rápidamente los problemas
activos y su gravedad.
• Detecciones: esta categoría está en el modo de vista previa. Permite la identificación
de patrones de ataque mediante la visualización de las alertas de seguridad.
• Inteligencia de amenazas: ayuda a identificar patrones de ataque mediante la
visualización de la cantidad total de servidores con tráfico IP malintencionado
de salida, el tipo de amenaza malintencionada y un mapa que muestra de
dónde vienen estas IP.

[ 104 ]
Capítulo 5

Almacenamiento
La cuenta de almacenamiento es un componente importante en la arquitectura de
la solución general. Las cuentas de almacenamiento pueden almacenar información
importante, como datos de identificación personal del usuario, transacciones, datos y más.
Es de suma importancia que las cuentas de almacenamiento sean seguras y permitan
solo acceso restringido a usuarios autorizados. Los datos almacenados se codifican
y transmiten mediante canales seguros. No solo las aplicaciones de almacenamiento, sino
también de usuarios y clientes que utilizan cuentas de almacenamiento y sus datos tienen
que desempeñar un papel fundamental en la seguridad general de los datos. También es
necesario que mantengan los datos cifrados en todo momento. Esto también incluye las
credenciales y cadenas de conexión que se conectan a almacenes de datos.
Azure proporciona control RBAC sobre quién puede administrar las cuentas de
almacenamiento de Azure. Se habilitan estos permisos de RBAC para usuarios y grupos
en Active Directory (AD) de Azure. Sin embargo, cuando se crea una aplicación que va a
implementarse en Azure, tendrá usuarios y clientes que no están disponibles en AD de Azure.
Para permitir a los usuarios el acceso a la cuenta de almacenamiento, el almacenamiento de
Azure ofrece claves de acceso al almacenamiento. Existen dos tipos de claves de acceso en
el nivel de la cuenta de almacenamiento: primaria y secundaria. Los usuarios que poseen
estas claves pueden conectarse a la cuenta de almacenamiento. Estas claves se utilizan en la
autenticación para acceder a la cuenta de almacenamiento. Las aplicaciones pueden acceder a
cuentas de almacenamiento con las claves primarias o secundarias. Se proporcionan dos claves
de modo que, si se incluye la clave principal, las aplicaciones pueden actualizarse para utilizar
la clave secundaria, mientras que la clave primaria se regenera. Esto ayuda a minimizar
el tiempo de inactividad de las aplicaciones. Además, proporciona y mejora la seguridad
mediante la eliminación de la clave incluida sin afectar las aplicaciones.

El almacenamiento de Azure brinda cuatro servicios: blobs, archivos, colas y tablas en


una cuenta. Cada uno de estos servicios también ofrece infraestructura para protegerse
mediante tokens de acceso seguro. Una firma de acceso compartido (SAS) es un identificador
uniforme de recursos (URI) que otorga derechos de acceso restringido a los servicios de
almacenamiento de Azure: blobs, archivos, colas y tablas. Estas firmas de acceso compartido
pueden compartirse con los clientes a quienes no tiene que confiarse la clave completa de
la cuenta de almacenamiento, sino que solo tiene que limitarse el acceso a determinados
recursos de la cuenta de almacenamiento. Al distribuir un URI de firma de acceso compartido
a estos clientes, se concede el acceso a los recursos durante un período determinado.
[ 105 ]
Seguridad de la nube

La firma de acceso compartido existe tanto en el nivel de la cuenta de


almacenamiento como en el de blobs, archivos, tablas y colas. La firma en el nivel
de la cuenta de almacenamiento es más potente y tiene los derechos para permitir
y denegar permisos en el nivel del servicio individual. También puede utilizarse en
lugar de los niveles de servicio de recursos individuales.

Es preferible generar y compartir firmas de acceso compartido a compartir claves de la


cuenta de almacenamiento. Las firmas de acceso compartido brindan acceso granular a los
recursos y también pueden combinarse. Incluyen leer, escribir, eliminar, enumerar, agregar,
crear, actualizar y procesar. Además, incluso se puede determinar el acceso a los recursos
mientras se generan firmas de acceso compartido. Podría ser para blobs, tablas, colas
y archivos individualmente o en combinación. Las claves de la cuenta de almacenamiento
son para toda la cuenta y no pueden estar limitadas a servicios individuales. Tampoco
pueden estar limitadas desde la perspectiva de los permisos. Es muy fácil crear y revocar
firmas de acceso compartido en comparación con las claves de acceso de almacenamiento.
Las firmas de acceso compartido pueden crearse para utilizarse durante un período
determinado luego del cual dejan de ser válidas automáticamente.
[ 106 ]
Capítulo 5

Es necesario tener en cuenta que si se regeneran las claves de cuentas de almacenamiento,


entonces se invalidará la firma de acceso compartido basada en ellos y será necesario
crear nuevas firmas de acceso compartido y compartirlas con los clientes.
El robo de cookies, la inyección de scripts y los ataques de denegación de servicio son
medios comunes que utilizan los atacantes para irrumpir en un entorno y robar datos.
Los navegadores y el protocolo HTTP implementan un mecanismo incorporado que
garantiza que no se puedan realizar estas actividades malintencionadas. Generalmente,
tanto HTTP como los navegadores no permiten nada entre dominios. Un script que se
ejecuta en un dominio no puede pedir recursos de otro dominio. Sin embargo, existen
casos de uso válidos donde es necesario permitir dichas solicitudes. El protocolo HTTP
implementa el uso compartido de recursos entre orígenes (CORS). Con la ayuda
de CORS, es posible acceder a recursos entre dominios y hacerlos funcionar. El
almacenamiento de Azure ayuda en la configuración de las reglas de CORS para
recursos de blobs, archivos, colas y tablas. El almacenamiento de Azure permite la
creación de reglas que se evalúan para cada solicitud autenticada. Si se cumplen las
reglas, se permite el acceso de la solicitud al recurso.

Los datos no solo tienen que estar protegidos mientras están en tránsito, también
es necesario que lo estén cuando están en reposo. Si los datos en reposo no están
cifrados, cualquiera puede leerlos y tener acceso a la unidad física en el centro de
datos. Aunque la posibilidad es casi insignificante, aun así, se recomienda a los
clientes cifrar sus datos. El cifrado del servicio de almacenamiento también ayuda
a proteger los datos en reposo. Este servicio funciona de forma transparente y se
inserta sin que los usuarios lo sepan. Cifra los datos cuando se guardan en una
cuenta de almacenamiento y los descifra automáticamente cuando se leen. Todo este
proceso sucede sin que los usuarios realicen ninguna actividad adicional.
Las claves de la cuenta de Azure tienen que rotarse periódicamente. Esto garantizará
que un atacante no pueda vulnerar el acceso a las cuentas de almacenamiento.
También se recomienda regenerar las claves; sin embargo, esto tiene que ser
evaluado respecto a su uso en aplicaciones existentes. Si se infringe la aplicación
existente, estas aplicaciones tienen que tener prioridad para la administración de
cambios y los cambios tienen que aplicarse gradualmente.

[ 107 ]
Seguridad de la nube

Dentro de lo posible, es necesario generar tokens de SAS individuales de nivel de


servicio con un plazo limitado y proporcionarlos a los usuarios con acceso a ellos. Es
necesario evaluar los permisos y proporcionar permisos óptimos.
Las claves de SAS y las claves de cuenta de almacenamiento tienen que almacenarse
en Azure Key Vault. Proporciona almacenamiento de seguridad y acceso. Las
aplicaciones pueden leer estas claves en la ejecución desde el almacén de claves, en
vez de almacenarlas en archivos de configuración.

Azure SQL
SQL Server ayuda a almacenar los datos relacionales en Azure. Es un servicio
SaaS que ofrece una plataforma altamente disponible, escalable, centrada en el
rendimiento y segura para almacenar datos. Es accesible desde cualquier lugar,
lenguaje de programación y plataforma. Los clientes necesitan una cadena de
conexión con información de servidor, base de datos y seguridad para conectarse.
SQL Server proporciona una configuración de firewall que no permite, por defecto, el
acceso a cualquier persona. Los intervalos y las direcciones IP tienen que estar en la
lista de permitidos para acceder a SQL Server. Solo tienen que colocarse en la lista de
permitidos aquellas direcciones IP que los arquitectos están seguros que pertenecen al
cliente o socios. Hay implementaciones en Azure para las que hay una gran cantidad
de direcciones IP o las direcciones IP no son conocidas. Por ejemplo, las aplicaciones
implementadas en las funciones o aplicaciones lógicas de Azure. Para que dichas
aplicaciones accedan a Azure SQL, Azure SQL proporciona listas de permitidos de
todas las direcciones IP a los servicios de Azure en todas las suscripciones.
Es necesario tener en cuenta que la configuración del firewall está en el nivel del
servidor y no de la base de datos. Esto significa que cualquier cambio aquí afecta las
bases de datos en un servidor.

[ 108 ]
Capítulo 5

Azure SQL también proporciona mayor seguridad mediante el cifrado de los datos en


reposo. Esto garantiza que nadie, incluidos los administradores del centro de datos de
Azure, pueda ver los datos almacenados en SQL Server. La tecnología utilizada por
SQL Server para cifrar los datos en reposo se conoce como cifrado de datos transparente
(TDE). No hay cambios necesarios al nivel de la aplicación para implementar el TDE.
SQL Server cifra y descifra datos de manera transparente cuando el usuario guarda y lee
los datos. Esta función está disponible en el nivel de la base de datos.

SQL Server también ofrece el enmascaramiento dinámico de datos (DDM) que es


especialmente útil para enmascarar determinados tipos de datos, como datos de
tarjetas de crédito o de identificación personal del usuario. Enmascaramiento no
es lo mismo que cifrado. El enmascaramiento no cifra los datos, sino que solo los
enmascara, lo que garantiza que las personas no puedan leerlos.

Los usuarios tienen que ocultar y cifrar los datos confidenciales en Azure SQL Server.

SQL Server también ofrece servicios de auditoría y detección de amenazas para todos los
servidores. Además de estas bases de datos, se ejecutan servicios avanzados de inteligencia
y recopilación de datos para detectar amenazas y vulnerabilidades, y advertir a los usuarios
según estas. Azure conserva los registros de auditoría en cuentas de almacenamiento, y los
administradores pueden verlos para realizar acciones. Los subprocesos como la inyección
de SQL y los inicios de sesión de clientes anónimos pueden generar alertas sobre las que
puede informarse a los administradores por correo electrónico.

[ 109 ]
Seguridad de la nube

Los datos pueden enmascararse en Azure SQL. Esto ayuda a almacenar datos en un


formato que no se comprenda fácilmente.

Azure SQL también ofrece el cifrado de datos transparente para cifrar los datos en reposo.

[ 110 ]
Capítulo 5

Azure Key Vaults


Proteger los recursos mediante contraseñas, claves, credenciales, certificados e
identificadores únicos es un elemento importante para cualquier entorno y aplicación. Son
elementos importantes desde la perspectiva de seguridad. Tienen que estar protegidos, y es
necesario garantizar que estos recursos permanezcan seguros y no se vean comprometidos,
ya que constituyen un pilar importante de la arquitectura de seguridad. Un aspecto
importante que no puede pasarse por alto es la administración y las operaciones que
protegen los secretos y las claves, y los ponen a disposición cuando resultan necesarios.

Por lo general, estos secretos se utilizan en todas partes: dentro del código fuente, el
archivo de configuración, en papel y en otros formatos digitales. Para superar estos
desafíos y almacenar todos los secretos de manera uniforme en un almacenamiento
seguro centralizado, es necesario crear almacenes de claves de Azure.
Azure Key Vault está bien integrado con otros servicios de Azure. Por ejemplo,
fácilmente puede utilizarse un certificado almacenado en Azure Key Vault e
implementarse en el almacén de certificados de las máquinas virtuales de Azure. En
Azure Key Vault, pueden almacenarse como secretos todo tipo de claves, incluidas
las claves de almacenamiento, claves de IoT y eventos, y cadenas de conexión.
Pueden recuperarse y utilizarse de manera transparente sin que nadie las vea ni las
almacene temporalmente en ningún lugar. Las credenciales de SQL Server y otros
servicios también pueden almacenarse en Azure Key Vault.

Azure Key Vault funciona por región. Esto significa que un recurso de Azure Key
Vault tiene que aprovisionarse en la misma región donde se implementa la aplicación
y el servicio. Si una implementación consta de más de una región y necesita servicios
de Azure Key Vault, se tienen que aprovisionar varias instancias de Azure Key Vault.

Auditoría y supervisión de seguridad


Azure ofrece dos recursos importantes de seguridad para administrar todos los aspectos
de seguridad de la suscripción, los grupos de recursos y los recursos de Azure:

• Supervisor de Azure
• Azure Security Center

Supervisor de Azure
El supervisor de Azure es un punto centralizado para supervisar los recursos de
Azure. Brinda información sobre los recursos de Azure y su estado. Proporciona una
interfaz enriquecida de consultas mediante la cual puede analizarse la información
utilizando los datos en los niveles de suscripción, grupo de recursos, recursos
individuales, tipo de recurso e intervalo de tiempo.

[ 111 ]
Seguridad de la nube

El supervisor de Azure puede utilizarse a través del portal de Azure, PowerShell,


CLI y API REST.

• El registro de actividades ofrece todas las operaciones del nivel de


administración que se llevaron a cabo en los recursos. Brinda detalles sobre el
momento de la creación, el creador, el tipo de recurso y el estado.
• El registro de operaciones (clásico) ofrece información detallada de todas
las operaciones realizadas sobre los recursos dentro de un grupo de recursos
y suscripción.
• Las métricas ayudan a obtener información del nivel de rendimiento sobre
los recursos individuales y configuran alertas en ellos.
• Las configuraciones de diagnóstico ayudan a configurar los registros
de efectos mediante la configuración del almacenamiento de Azure para
almacenar registros, transmitir registros en tiempo real hacia los centros de
eventos de Azure y enviar al análisis de registros (anteriormente conocido
como Operational Management Suite).
• La búsqueda de registros ayuda a integrar los análisis de estos con el
supervisor de Azure.
El supervisor de Azure puede ayudar a identificar incidentes relacionados con la
seguridad y adoptar las medidas apropiadas basadas en ellos. Es importante que
solo se les permita a las personas autorizadas acceder al supervisor de Azure, ya que
puede contener información confidencial.

Azure Security Center


Azure Security Center, como su nombre lo indica, es un punto centralizado para satisfacer
todas las necesidades de seguridad. Generalmente, hay dos actividades relacionadas
con la seguridad: la implementación de seguridad y la supervisión para evitar cualquier
amenaza o vulneración. Security Center se construyó principalmente para ayudar en
ambas actividades. Azure Security Center les permite a los usuarios definir sus políticas
de seguridad e implementarlas en los recursos de Azure. Según el estado actual de los
recursos de Azure, Azure Security Center proporciona recomendaciones de seguridad
para consolidar la solución y los recursos individuales de Azure.

[ 112 ]
Capítulo 5

Las sugerencias incluyen casi todos los procedimientos recomendados de seguridad de


los recursos de Azure, como el cifrado de datos, los discos, la protección de red y puntos
de conexión, las listas de control de acceso, las listas blancas de solicitudes entrantes, el
bloqueo de solicitudes no autorizadas y más. Los recursos van desde componentes de
infraestructura como los equilibradores de carga, los grupos de seguridad de red y la red
virtual hasta recursos de PaaS como SQL de Azure, almacenamiento y otros.

[ 113 ]
Seguridad de la nube

Azure Security Center es una plataforma enriquecida y puede proporcionar


recomendaciones para varios servicios.

Resumen
La seguridad siempre fue un aspecto importante para cualquier implementación y
solución. Se ha vuelto mucho más importante y relevante debido a las implementaciones
en la nube. Además, los eventos y las amenazas de ataques a la ciberseguridad están en
aumento. En tales circunstancias, la seguridad se ha convertido en el objetivo principal
de las organizaciones. Independientemente del tipo de implementación y solución, ya
sea IaaS, PaaS o SaaS, la seguridad es necesaria en todos. Los centros de datos de Azure
están totalmente protegidos y tienen una docena de certificaciones internacionales
de seguridad. Son seguros por defecto. Proporcionan recursos de seguridad de IaaS
como NSG, traducción de direcciones de red, puntos de conexión seguros, certificados,
almacenes de claves, cifrado de almacenamiento y máquina virtual, y características de
seguridad de PaaS para recursos individuales de PaaS. La seguridad tiene su propio
ciclo de vida completo y tiene que planearse, diseñarse, implementarse y probarse
adecuadamente, al igual que cualquier otra funcionalidad de la aplicación.
A partir del próximo capítulo, el foco del libro estará puesto en algunas de las
soluciones y arquitecturas específicas de la tecnología. En el siguiente capítulo se
trata la Internet de las Cosas (IoT) en Azure.
[ 114 ]
Diseñar soluciones de IoT
Hasta ahora, hemos tratado las cuestiones arquitectónicas y sus soluciones en Azure
en general. Este capítulo no se basa en la arquitectura generalizada. Se trata de una
de las tecnologías más disruptivas de este siglo. En este capítulo entraremos en
detalles de la arquitectura de IoT en Azure

Este capítulo abarcará específicamente los siguientes temas:

• Azure y la IoT
• Resumen de la IoT de Azure
• Administración de dispositivos
°° Registro de dispositivos
°° Comunicación entre dispositivo e IoT Hub

• Escalado de soluciones de IoT


• Alta disponibilidad de soluciones de IoT
• Protocolos de IoT
• Uso de las propiedades del mensaje para el enrutamiento de mensajes

IoT
IoT es una abreviatura, expandida es Internet de las Cosas. Hay dos palabras
clave importantes en esta frase: Internet y Cosas. Para comprenderlo mejor, vamos
a retroceder algunos siglos en la historia para relatar cómo surgió esta tecnología.

[ 115 ]
Diseñar soluciones de IoT

Internet se inventó en la década de los noventa y estuvo disponible para todo el


mundo, aunque la penetración fue menor. Durante este tiempo, casi todo el mundo
pasó a tener una presencia en Internet y comenzó a crear páginas web estáticas. Estas
páginas web estáticas mostraban detalles sobre diversos aspectos. Finalmente, el
contenido estático se volvió dinámico y se generaba sobre la marcha en función del
contexto. En casi todos los casos, se necesitaba un navegador para acceder a Internet.
Había una gran cantidad de navegadores, pero era un desafío utilizar Internet sin ellos.

Durante la primera década de este siglo, ocurrió un interesante desarrollo:


el incremento de dispositivos portátiles en forma de tabletas y teléfonos móviles.
Los teléfonos móviles eran más económicos día a día y estaban disponibles en todas
partes. Las capacidades de hardware y software de estos dispositivos portátiles
mejoraban considerablemente. Tanto es así que la gente comenzó a utilizar
navegadores en los dispositivos móviles en lugar de en los equipos de escritorio.
Pero hubo un cambio sutil y notable: el aumento de las aplicaciones móviles.
Las aplicaciones móviles se descargaban de alguna tienda y se conectaban a Internet
para comunicarse con los sistemas backend. Hacia fines de la última década, había
millones de aplicaciones disponibles con casi todas las funcionalidades imaginables
incorporadas. El sistema backend para estas aplicaciones se creó en la nube, de modo
que pudiera escalarse rápidamente. Esta fue la época de conexión de aplicaciones
y servidores.

Pero, ¿esta fue la cima de la innovación? ¿Cuál era la próxima evolución para hacerlo
mejor para todos en general? Si mira con atención, había otro paradigma que estaba
tomando protagonismo. Se trataba de la IoT. Cuando las aplicaciones se conectaban
a sistemas backend, era básicamente un dispositivo que tenía informática,
almacenamiento y que estaba conectado a Internet realizando solicitudes. ¿Y si
se conectan todos los dispositivos conectados a Internet? En vez de solo móviles
y tabletas conectados a Internet, puede haber otros dispositivos que pueden
conectarse. Estos dispositivos estaban disponibles en mercados exclusivos, eran
costosos, no estaban disponibles para el público general y tenían capacidades
limitadas de hardware y software. Sin embargo, durante la primera parte de la
década actual, la comercialización de estos dispositivos comenzó a ser a gran escala.
Estos dispositivos se estaban volviendo cada vez más pequeños, más capaces desde
la perspectiva de hardware y software, tenían más capacidad informática y de
almacenamiento, podían conectarse a Internet en diversos protocolos y podían
conectarse a casi cualquier cosa. Esta es la era de conectar dispositivos a servidores,
aplicaciones y otros dispositivos.

[ 116 ]
Capítulo 6

Esto condujo a la creación de la idea y de las aplicaciones que pudieran cambiar la


forma en la que operaban las industrias. Soluciones nuevas que antes se ignoraban
comenzaron a hacerse realidad. Ahora estos dispositivos podrían conectarse
a cualquier cosa y podrían obtener información y enviarla a un sistema de backend
que podría asimilar esa información desde todos los dispositivos y tomar medidas
proactivas o informar los acontecimientos.

Ejemplos de IoT son los sistemas de seguimiento de vehículos que realizan un


seguimiento de todos los parámetros fundamentales de un vehículo y envían los
detalles al almacén de datos centralizado para su análisis, los servicios de la ciudad
inteligente, como el seguimiento de los niveles de contaminación, la temperatura,
los embotellamientos, etc., y las actividades relacionadas con la agricultura ligadas
a la fertilidad del suelo, la humedad, etc.

Arquitectura de IoT
Antes de comenzar con Azure y sus características y servicios relacionados con
IoT, es importante comprender los diversos componentes necesarios para crear
soluciones integrales de IoT.

Imagine que dispositivos de IoT en todo el mundo envían millones de mensajes


por segundo a una base de datos centralizada. ¿Por qué se recopilan estos datos?
Estos datos se recopilan para extraer información valiosa acerca de eventos,
anomalías, valores atípicos y acontecimientos dentro de los dispositivos y objetos
a los que están conectados.

Veamos esto en más detalle.

La arquitectura de la IoT puede dividirse en distintas fases:

• Conectividad
• Identidad
• Captura
• Ingesta
• Almacenamiento
• Transformación
• Análisis
• Presentación

[ 117 ]
Diseñar soluciones de IoT

Las siguientes imágenes muestran una arquitectura genérica basada en IoT.


Los dispositivos generan o recopilan los datos y los envían a gateways de nube.
El gateway de nube, a su vez, envía los datos a varios servicios backend para su
procesamiento. Los gateways de nube son un componente opcional. Es necesario
utilizarlos cuando los dispositivos en sí mismos no son capaces de enviar solicitudes
a los servicios backend debido a sus limitaciones de recursos o a la falta de una red
confiable. Estos gateways de nube pueden recopilar datos de múltiples dispositivos
y enviarlos a servicios backend. Los procesos de datos realizados por los servicios
backend luego se muestran como información o paneles a los usuarios.

Conectividad
Los dispositivos de IoT tienen que comunicarse. Existen varios tipos de conectividad.
Podría ser entre dispositivos en una región, entre dispositivos y un gateway
centralizado, entre dispositivos y una plataforma de IoT, etc.

En todos los casos mencionados, los dispositivos de IoT necesitan capacidad


de conexión. Esta capacidad podría ser en términos de conectividad a Internet,
Bluetooth, infrarrojo o cualquier otra comunicación de dispositivos cercanos.

[ 118 ]
Capítulo 6

Es posible que algunos dispositivos no tengan la capacidad de conectarse a Internet.


En esos casos, pueden conectarse a través de otros medios a un gateway, que a su
vez tiene conexión a Internet.

Los dispositivos de IoT utilizan protocolos para enviar mensajes. Los protocolos
más importantes entre estos son Advanced Message Queuing Protocol (AMQP)
y Message Queue Telemetry Transport (MQTT).

Los datos de los dispositivos tienen que enviarse a la infraestructura de TI. El protocolo
MQTT es un protocolo de dispositivo a servidor que pueden utilizar los dispositivos
para enviar datos de telemetría y otra información a los servidores. Una vez que el
servidor recibe el mensaje a través del protocolo MQTT, tiene que transportar los
mensajes a otros servidores mediante una tecnología confiable basada en mensajes
y colas. AMPQ es el protocolo preferido para mover mensajes entre servidores en la
infraestructura de TI de una manera confiable y predecible.

Los servidores que reciben mensajes iniciales de los dispositivos de IoT tienen que
enviar mensajes a otros servidores para el procesamiento, que incluye guardarlos con
fines de registro, evaluarlos, analizarlos y presentarlos.

Algunos dispositivos no tienen capacidad para conectarse a Internet o no admiten


los protocolos que entienden los protocolos de TI. Como se mencionó anteriormente,
los dispositivos de IoT tienen diversas capacidades y algunas de las características
que afectan sus capacidades se mencionan a continuación. Para habilitar estos
dispositivos para trabajar con la plataforma de IoT y la nube, gateways intermedios
ayudan a adaptarlos para el envío de información a la nube. Los gateways ayudan en
la incorporación de dispositivos en los que la conectividad y las redes son lentas y no
coherentes, dispositivos que utilizan protocolos que no son estándar y dispositivos
con capacidades limitadas en términos de recursos y potencia.

[ 119 ]
Diseñar soluciones de IoT

En tales circunstancias, cuando los dispositivos necesitan infraestructura adicional


para participar y conectarse a servicios backend, se pueden implementar gateways
cliente. Estos gateways reciben mensajes desde dispositivos cercanos y los envían
e insertan en la infraestructura de TI y la plataforma de IoT para un mayor uso.
Tienen capacidad de traslación de protocolo si es necesario.

Identidad
Los dispositivos de IoT tienen que registrarse en la plataforma de nube. No tiene
que permitirse que todos los dispositivos se conecten a la plataforma de nube.
Los dispositivos tienen que registrarse y se les tiene que asignar una identidad.
El dispositivo tiene que enviar la información de identidad a la vez que se conecta
y envía la información a la nube. En caso de que el dispositivo no envíe esta
información de identidad, la conectividad produce un error. Más adelante en
este capítulo, veremos cómo generar la identidad de un dispositivo mediante
la aplicación de la simulación.

Captura
Los dispositivos de IoT tienen que poder capturar la información desde sí mismos
y el ecosistema a su alrededor. Por ejemplo, tienen que tener la capacidad de leer
el contenido de humedad en el aire o en el suelo. La información puede capturarse
en función de la frecuencia, que podría ser tan baja como por segundo. Una vez
capturada la información, tiene que poder enviarla a la plataforma de IoT para su
procesamiento. Si un dispositivo no tiene la capacidad de conectarse directamente
a la plataforma de IoT, se puede conectar a un intermediario y a gateways de
nube para insertar la información capturada. El tamaño de los datos capturados
y la frecuencia son los aspectos más importantes para el dispositivo. Otro aspecto
importante a tener en cuenta es si el dispositivo cuenta con almacenamiento local
y almacena temporalmente los datos capturados. El dispositivo puede funcionar en
modo sin conexión si se dispone de un almacenamiento local. Incluso los dispositivos
móviles a veces actúan como dispositivos de IoT conectados a diversos instrumentos
y tienen la capacidad de almacenar datos.

[ 120 ]
Capítulo 6

Ingesta
Los datos capturados y generados por los dispositivos tienen que enviarse a una
plataforma de IoT capaz de ingerir y usar esos datos para extraer información e ideas
significativas. El servicio de ingesta es un servicio importante y crucial debido a que
su disponibilidad y escalabilidad afectan el rendimiento de los datos entrantes.
Si comienzan a regularse los datos debido a los problemas de escalabilidad o los
datos no pueden ingerirse debido a problemas de disponibilidad, se perderían los
datos y podrían ser parciales o sesgados.

Almacenamiento
Las soluciones de IoT generalmente se ocupan de millones y miles de millones de
registros que abarcan terabytes y petabytes de datos. Se trata de datos valiosos que
pueden proporcionar información sobre las operaciones y su estado. Estos datos
tienen que almacenarse de modo que puedan analizarse. El almacenamiento tiene
que estar fácilmente disponible para que los servicios y las aplicaciones analíticas
lo utilicen. Tienen que proporcionar un rendimiento y una latencia suficientes desde
una perspectiva de rendimiento, tener gran disponibilidad y capacidad de escalada,
y ser seguros por naturaleza.

Transformación
Las soluciones de IoT generalmente constan de datos y tienen un volumen
considerable alto. Imagine que cada automóvil tiene un dispositivo, y cada uno
envía mensajes cada cinco segundos. Si hay un millón de automóviles que envían
mensajes, serían 288 millones de mensajes al día y 8000 millones de mensajes al
mes. Estos datos tienen un montón de información oculta; sin embargo, es bastante
difícil comprender este tipo de datos con solo observarlos. Los datos capturados
y almacenados pueden utilizarse para resolver problemas comerciales. Según
la naturaleza del problema, no todos los datos capturados son de importancia.
Podría haber un subconjunto de datos que tendrían que utilizarse para resolver
un problema. Además, los datos capturados y almacenados podrían no ser
coherentes. Para garantizar que los datos sean coherentes, no parciales ni sesgados,
es necesario llevar a cabo una transformación apropiada para que puedan utilizarse
inmediatamente. Este proceso normalmente se conoce como transformación. Aquí,
se filtran, ordenan, eliminan, enriquecen y transforman los datos en una estructura;
los componentes y las aplicaciones posteriores pueden utilizarlos inmediatamente.

[ 121 ]
Diseñar soluciones de IoT

Análisis
Los datos transformados en el paso anterior se convierten en la entrada y la fuente
de datos para los análisis. Según la naturaleza del negocio y el problema en cuestión,
existen varios tipos diferentes de análisis que pueden realizarse en los datos
transformados.

La figura anterior fue tomada de Gartner y representa muy bien los diferentes tipos
de análisis que pueden realizarse:

• Análisis descriptivo: este tipo de análisis ayuda en la búsqueda de patrones


y detalles acerca de estados de dispositivos de IoT y del estado en general.
Normalmente, esta es la primera etapa de análisis que identifica y resume los
datos para su uso en análisis más avanzados. Esto ayudará en la búsqueda de
información como resúmenes, estadísticas relacionadas con la probabilidad,
diferencias y otros conceptos estadísticos simples.
• Análisis de diagnóstico: este tipo de análisis es más avanzado que el análisis
descriptivo. Se crea a partir del análisis descriptivo e intenta responder
a las preguntas acerca de por qué sucedieron las cosas. Intenta encontrar la
causa principal de los acontecimientos que ocurrieron. Intenta encontrar las
respuestas utilizando conceptos avanzados, como hipótesis y correlación.

[ 122 ]
Capítulo 6

• Análisis predictivo: este tipo de análisis intenta predecir cosas que tienen
una alta probabilidad de ocurrir en el futuro. Se trata de la predicción basada
en datos anteriores. La regresión es uno de los ejemplos basados en datos
anteriores; podría, por ejemplo, predecir el precio de un automóvil, acciones en
el mercado de valores, cuando se reventará el próximo neumático, entre otros.
• Análisis prescriptivo/cognitivo: este análisis se da en los niveles más altos
de madurez y ayuda a tomar medidas automáticamente. Ayuda en la
identificación de las acciones más adecuadas que tienen que llevarse a cabo
para garantizar que el estado de los dispositivos y la solución no se degraden
y que puedan tomarse medidas proactivas. Esto ayuda a evitar y eliminar los
problemas de raíz.

Presentación
Los análisis ayudan en la identificación de respuestas, patrones y conocimientos en
función de los datos disponibles del pasado. Estas ideas también tienen que estar
disponibles para todos los interesados en diferentes formas y en un formato que puedan
comprender. Tienen que ser de uso inmediato y estar disponibles en múltiples formatos.
Pueden generarse informes y paneles adecuados, estadística o dinámicamente, y luego
pueden presentarse a las partes interesadas. Los interesados pueden utilizar estos
informes para tomar más medidas y mejorar continuamente su solución.

Azure IoT
Luego de conocer los detalles sobre las distintas etapas que ayudan a crear
soluciones de IoT integrales. Cada una de estas etapas son cruciales y su aplicación
es imprescindible para el éxito. Azure proporciona una gran cantidad de servicios
para cada una de estas etapas. Aparte de estos servicios, Azure proporciona hubs de
IoT: el servicio y plataforma de IoT principal capaz de hospedar soluciones de IoT
complejas, con una alta disponibilidad y escalables. Profundizaremos en los hubs de
IoT luego de analizar otros servicios.

[ 123 ]
Diseñar soluciones de IoT

En esta sección se detallará brevemente cada uno de estos servicios.

Identidad
Los hubs de IoT de Azure también ofrecen servicios para la autenticación de dispositivos.
Los hubs de IoT proporcionan una interfaz para generar hashes de identidad única para
cada dispositivo. Cuando los dispositivos envían sus mensajes que contienen este hash,
el hub de IoT puede identificarlos luego de la verificación de su propia base de datos para
la existencia de tales hashes.

Captura
Azure proporciona gateways de IoT que permiten que los dispositivos no compatibles
con hubs de IoT se adapten y permitan la inserción de datos. Hay gateways locales
o intermediarios implementados cerca de los dispositivos de modo que varios
dispositivos puedan conectarse a un único gateway para enviar su información.
Del mismo modo, se pueden implementar varios de esos grupos de dispositivos con
un gateway local. Puede haber un gateway de nube implementado en la nube en sí,
capaz de aceptar datos de múltiples fuentes y de ingerirlos para los hubs de IoT.

[ 124 ]
Capítulo 6

Ingesta
Azure proporciona un hub de IoT que se convierte en un punto único de contacto
para que los dispositivos y otras aplicaciones envíen datos. En otras palabras,
la ingesta de los mensajes de IoT es responsabilidad del servicio de hub de IoT.
Hay otros servicios, como la infraestructura de centros de eventos y mensajes de
service bus que pueden ofrecer la ingesta de los mensajes entrantes; sin embargo,
los beneficios y ventajas de los hubs de IoT para la ingesta de datos dura mucho más
en comparación con los centros de eventos y los mensajes de service bus. De hecho,
los hubs de IoT se crearon específicamente con el propósito de ingerir mensajes
de IoT dentro del ecosistema de Azure de modo que el resto de los componentes
y servicios puedan actuar ante esto.

Almacenamiento
Azure proporciona diversos tipos de almacenamiento para los mensajes de los
dispositivos de IoT. Estas cuentas de almacenamiento incluyen almacenamiento
de datos relacionales, datos NoSQL sin esquema y blobs:

• Base de datos SQL: la base de datos SQL ofrece almacenamiento de


documentos de datos relacionales, JSON y XML. Proporciona un lenguaje
de consulta SQL enriquecido y utiliza un servidor SQL completo como un
servicio. Los datos de los dispositivos pueden almacenarse en bases de datos
SQL si los datos están bien definidos y la expectativa es que el esquema no
sufrirá cambios con frecuencia.
• Almacenamiento de Azure: el almacenamiento de Azure proporciona
almacenamiento en tablas y blobs. El almacenamiento en tablas ayuda
a almacenar datos como entidades cuando el esquema no es importante.
Es una implementación de bases de datos NoSQL. Los blobs ayudan
a almacenar archivos en contenedores como blobs.
• CosmosDB/DocumentDB: DocumentDB es una base de datos NoSQL
completa, de escala empresarial, disponible como un servicio capaz de
almacenar datos sin esquema. Es una base de datos verdaderamente
distribuida que puede abarcar continentes, y ofrecer alta disponibilidad
y escalabilidad de los datos.
• Orígenes de datos externos: aparte de los servicios de Azure, los clientes
pueden aportar sus propios almacenes de datos, como un servidor SQL en
las máquinas virtuales de Azure, y pueden utilizarlos para almacenar datos
en formato relacional.

[ 125 ]
Diseñar soluciones de IoT

Transformación y análisis
• Fábrica de datos: Azure Data Factory es un servicio de integración de datos
alojado en la nube que nos permite crear flujos de trabajo basados en datos en
la nube para organizar y automatizar el movimiento y la transformación de
datos. Azure Data Factory ayuda a crear y programar flujos de trabajo basados
en datos (llamados canalizaciones) que pueden ingerir datos de almacenes de
datos dispares, procesar o transformar los datos mediante el uso de servicios
de procesos tales como Azure HDInsight Hadoop, Spark, Azure Data Lake
Analytics y Azure Machine Learning, y publicar los datos de salida en
almacenes de datos, como el almacén de datos Azure SQL, para el consumo de
las aplicaciones de inteligencia empresarial (BI). Es más bien una plataforma
de extracción y carga (EL) y luego de transformación y carga (TL) que una
plataforma tradicional de extracción, transformación y carga (ETL).
• Azure HDInsight: Microsoft y Hortonworks se unieron para ayudar a las
empresas mediante la oferta de la plataforma de análisis de big data en el
servicio de nube de Azure. HDInsight es un entorno de servicio en la nube
de alta potencia, totalmente gestionado por Apache Hadoop y Apache Spark
mediante Microsoft Azure HDInsight. Ayuda a acelerar las cargas de trabajo
sin problemas con el servicio en la nube para big data líder del sector de
Microsoft y Hortonworks.
• Azure Stream Analytics: este servicio totalmente gestionado de análisis de
datos en tiempo real ayuda a realizar los cálculos y la transformación de los
datos de transmisión. Stream Analytics puede examinar grandes volúmenes
de datos que fluyen de dispositivos o procesos, extraer información de la
secuencia de datos y buscar patrones, tendencias y relaciones.
• Machine learning: machine learning es una técnica de la ciencia de datos
que permite a los equipos utilizar los datos existentes para pronosticar
comportamientos, resultados y tendencias futuros. Con machine learning,
los equipos aprenden sin necesidad de una programación explícita. Azure
Machine Learning es un servicio de análisis predictivo basado en la nube
que permite crear e implementar rápidamente modelos predictivos como
soluciones de análisis.

Proporciona una biblioteca de algoritmos lista para usar que permite crear modelos
en un equipo conectado a Internet e implementar rápidamente soluciones predictivas.

[ 126 ]
Capítulo 6

Presentación
Después de la realización de los análisis apropiados sobre los datos, estos tienen
que presentarse a los interesados en un formato que pueda ser utilizado por ellos.
Hay numerosas maneras de presentar la información de los datos. Esto incluye la
presentación de datos mediante aplicaciones web implementadas con los servicios
de aplicación de Azure, el envío de datos a los centros de notificaciones que luego
pueden notificar a las aplicaciones móviles, y mucho más. Sin embargo, el enfoque
ideal para presentar y utilizar la información es mediante el uso de informes
y paneles de Power BI. Power BI es una herramienta de visualización de Microsoft
para la representación de informes y paneles dinámicos en Internet accesibles desde
cualquier lugar de la red.

Hubs de IoT
Los proyectos de IoT suelen ser de una naturaleza compleja. La complejidad surge
debido a la gran cantidad de dispositivos y datos, los dispositivos integrados en
todo el mundo, la supervisión y la auditoría de dispositivos, el almacenamiento de
datos, la transformación y el análisis de petabytes de datos y finalmente, las acciones
basadas en la información. Por otra parte, estos proyectos son de larga duración,
tienen extensos períodos de gestación y sus requisitos cambian constantemente
debido a las líneas de tiempo.

Si una empresa desea embarcarse en proyectos de IoT, pronto descubrirá que estos
no son problemas fáciles de resolver. Los proyectos necesitan grandes equipos de
hardware en términos de cálculo y almacenamiento, y servicios que puedan trabajar
con estos grandes volúmenes de datos.

Azure IoT Hub es una plataforma creada para facilitar y posibilitar los proyectos
de IoT para entregas mejores y más rápidas y sencillas. Proporciona todas las
características y los servicios necesarios para lo siguiente:

• Registro de dispositivos
• Conectividad de dispositivos
• Gateways de campo
• Gateways de nube

[ 127 ]
Diseñar soluciones de IoT

• Implementación de protocolos del sector, como AMQP y MQTT


• Centro para almacenamiento de mensajes entrantes
• Enrutamiento de mensajes basado en el contenido y las propiedades de los
mensajes
• Varios puntos de conexión para diferentes tipos de procesamiento
• Conectividad con otros servicios en Azure para análisis y análisis en tiempo
real, entre otros

Protocolos
Azure IoT Hub admite nativamente la comunicación mediante los protocolos MQTT,
AMQP y HTTP. En algunos casos, los dispositivos o gateways de campo podrían no
ser capaces de utilizar uno de estos protocolos estándares y requerirán la adaptación
del protocolo. En tales casos, se puede implementar un gateway personalizado. Un
gateway personalizado puede permitir la adaptación del protocolo para los puntos
de conexión de IoT Hub mediante el tendido de puentes para el tráfico hacia y desde
IoT Hub.

Registro de dispositivos
Los dispositivos tendrían que registrarse antes del envío de mensajes a IoT Hub.
El registro de los dispositivos se puede hacer manualmente desde el portal de
Azure o se puede automatizar mediante el SDK del IoT Hub. Azure proporciona
aplicaciones de simulación de muestra, con la ayuda de las cuales se pueden registrar
fácilmente los dispositivos virtuales para desarrollo y prueba. También hay un
simulador en línea, Raspberry Pi, que se puede utilizar como un dispositivo virtual,
y existen otros dispositivos físicos que se pueden configurar para conectarse al IoT Hub.

Para simular un dispositivo desde un equipo local que se utiliza generalmente para
desarrollo o pruebas, hay tutoriales disponibles sobre documentos de Azure para
varios idiomas. Están disponibles en https://docs.microsoft.com/en-us/azure/
iot-hub/iot-hub-get-started-simulated.

El simulador en línea de Raspberry Pi está disponible en https://docs.microsoft.


com/en-us/azure/iot-hub/iot-hub-raspberry -pi-web-simulator-get-
started, y para usar los dispositivos físicos que requieren registro en Azure IoT
Hub, es necesario seguir los pasos que se mencionan en https://docs.microsoft.
com/es-es/azure/iot-hub/iot-hub-get-started-physical.

Para agregar manualmente un dispositivo mediante el portal de Azure, IoT Hub


ofrece un menú de exploración de dispositivos que se puede utilizar para configurar
un dispositivo nuevo.

[ 128 ]
Capítulo 6

Una vez que se crea la identidad del dispositivo, es necesario utilizar la cadena de
conexión de clave primaria para IoT Hub en cada dispositivo para conectarse a él.

[ 129 ]
Diseñar soluciones de IoT

Administración de mensajes
Una vez que los dispositivos se registran en IoT Hub, pueden comenzar a interactuar
con este. La interacción puede ser del dispositivo a la nube o de la nube al dispositivo.

Mensajería del dispositivo a la nube


Uno de los procedimientos recomendados que tienen que seguirse en esta
comunicación es que, aunque el dispositivo capture una gran cantidad de
información, solo los datos importantes tienen que transmitirse a la nube. El tamaño
del mensaje es muy importante en las soluciones de IoT debido a la naturaleza
intrínseca de las soluciones de IoT, que suelen ser de gran volumen. Incluso 1 KB de
datos adicionales puede resultar en un gigabyte de almacenamiento y procesamiento
desperdiciados. Cada mensaje tiene propiedades y una carga real. Las propiedades
definen los metadatos del mensaje. Estos metadatos contienen datos sobre el
dispositivo, la identificación, las etiquetas y otras propiedades que son útiles para
enrutar e identificar los mensajes.

Los dispositivos o los gateways de nube tienen que conectarse a los IoT Hub para
transferir datos. Los IoT Hub proporcionan puntos de conexión públicos que
pueden ser utilizados por los dispositivos para conectarse y enviar datos. El IoT Hub
tiene que ser considerado como el primer punto de contacto, ya que el IoT Hub de
procesamiento de backend es capaz de transmitir y enrutar estos mensajes a diversos
servicios. De manera predeterminada, los mensajes se almacenan en Event Hub.
Se pueden crear distintos Event Hub para diversas clases y tipos de mensajes.

[ 130 ]
Capítulo 6

Los mensajes se pueden enrutar a diferentes puntos de conexión en función de las


propiedades del encabezado y cuerpo del mensaje, y esto se muestra en la imagen
siguiente.

El mensaje en IoT Hub se conserva durante siete días de manera predeterminada.


Su tamaño puede ser de hasta 256 KB.

Hay una acción de muestra que actúa como un simulador para el envío de mensajes
a la nube. Está disponible en varios idiomas, y la versión C# está en https://docs.
microsoft.com/es-es/azure/iot-hub/iot-hub-csharp-csharp-c2d.

Mensajería de la nube al dispositivo


Azure IoT Hub es un servicio administrado que proporciona una infraestructura
de mensajería bidireccional. Los mensajes se pueden enviar desde la nube a los
dispositivos, y los dispositivos pueden actuar sobre los mensajes en función de estos.

Existen tres tipos de patrones de mensajería de la nube al dispositivo:

• Los métodos directos requieren una confirmación inmediata del resultado.


Los métodos directos se suelen utilizar para el control interactivo de los
dispositivos, como la apertura y el cierre de persianas de garaje. Siguen el
patrón de solicitud-respuesta.

[ 131 ]
Diseñar soluciones de IoT

• Las propiedades deseadas de los gemelos para los comandos de ejecución


prolongada tienen la intención de colocar el dispositivo en un estado deseado.
Por ejemplo, establecer el intervalo de envío de telemetría en 30 minutos.
Los gemelos de dispositivo son documentos JSON que almacenan información
de estado del dispositivo (metadatos, configuraciones y condiciones). El IoT
Hub mantiene un gemelo de dispositivo para cada dispositivo del IoT Hub.
• Mensajes de la nube al dispositivo para notificaciones unidireccionales a la
aplicación del dispositivo. Este tipo de mensajería sigue un patrón que no
requiere supervisión.

Seguridad
La seguridad es un aspecto importante en las aplicaciones basadas en IoT.
Las aplicaciones basadas en IoT constan de dispositivos que utilizan la Internet
pública para la conectividad a las aplicaciones de backend. La protección de los
dispositivos, las aplicaciones de backend y la conectividad contra los usuarios
maliciosos y hackers tendría que considerarse una prioridad para el éxito de estas
aplicaciones.

Seguridad en IoT
Las aplicaciones de IoT se construyen principalmente en torno a la Internet,
y la seguridad tendría que desempeñar un papel importante para garantizar
que la solución no se vea comprometida desde el punto de vista de la identidad,
la confidencialidad y la integridad. Algunas de las decisiones de seguridad
importantes que afectan la arquitectura de IoT son las siguientes:
• Dispositivos que utilizan puntos de conexión REST HTTP frente a HTTPS.
Los puntos de conexión REST protegidos por certificados garantizan que
los mensajes transferidos del dispositivo a la nube y viceversa están bien
cifrados y firmados. Los mensajes no tendrían que tener sentido para un
intruso y tendrían que ser muy difíciles de descifrar.
• Si los dispositivos están conectados a un gateway local, este tendría que
conectarse a la nube mediante un protocolo HTTP seguro.
• Los dispositivos se tienen que registrar en los IoT Hub de la nube para poder
enviar mensajes.
• La información pasada a la nube se tiene que conservar en un
almacenamiento bien protegido desde una perspectiva de confidencialidad,
integridad e identidad. Para la conexión se tienen que utilizar los tokens de
SAS o las cadenas de conexión almacenados en Azure Key Vault.
• Azure Key Vault tiene que utilizarse para almacenar todos los secretos, las
contraseñas y las credenciales, incluidos los certificados.
[ 132 ]
Capítulo 6

Escalabilidad
La escalabilidad para el IoT Hub es un poco diferente de otros servicios. En Azure
IoT Hub, existen dos tipos de mensajería:

• Entrante: mensajes del dispositivo a la nube


• Saliente: mensajes de la nube al dispositivo

Y ambos se tienen que tener en cuenta en términos de escalabilidad.

El IoT Hub ofrece un par de opciones de configuración durante el tiempo de


aprovisionamiento para establecer la escalabilidad. Estas opciones también están
disponibles luego del aprovisionamiento y se pueden actualizar para adaptarse
mejor a los requisitos de la solución en términos de escalabilidad.

Las opciones de escalabilidad disponibles para el IoT Hub son las siguientes:

• La edición de SKU que tiene el tamaño del IoT Hub


• La cantidad de unidades

Edición de SKU
La SKU del IoT Hub determina la cantidad de mensajes que puede manejar por
unidad/día, y esto incluye tanto los mensajes entrantes como los salientes. Existen
cuatro SKU definidas. Son las siguientes:

• Libre: permite 8000 mensajes por unidad/día y admite tanto mensajes


entrantes como salientes. Se puede aprovisionar una unidad como máximo.
Esta edición es conveniente para familiarizarse y probar las capacidades del
servicio Azure IoT Hub.
• Estándar (S1): permite 400.000 mensajes por unidad/día y admite tanto
mensajes entrantes como salientes. Se pueden aprovisionar 200 unidades como
máximo. Esta edición es conveniente para una pequeña cantidad de mensajes.
• Estándar (S2): permite seis millones de mensajes por unidad/día y
admite tanto mensajes entrantes como salientes. Se pueden aprovisionar
200 unidades como máximo. Esta edición es conveniente para una gran
cantidad de mensajes.

[ 133 ]
Diseñar soluciones de IoT

• Estándar (S3): permite 300 millones de mensajes por unidad/día y admite


tanto mensajes entrantes como salientes. Se pueden aprovisionar 10 unidades
como máximo. Esta edición es conveniente para una cantidad de mensajes
muy grande.

[ 134 ]
Capítulo 6

Un lector sagaz habría notado que la SKU Estándar S3 permite un máximo de


10 unidades solamente frente a otras unidades estándares que permiten un máximo
de 200 unidades. Esto está directamente relacionado con el tamaño de las máquinas
que las ejecutan. El tamaño y la capacidad de las máquinas virtuales para una SKU
Estándar S3 son significativamente mayores comparados con otras SKU en las que el
tamaño sigue siendo el mismo.

Unidades
Las unidades definen la cantidad de instancias de cada SKU que se ejecuta detrás del
servicio. Por ejemplo, dos unidades de SKU Estándar S1 significará que el IoT Hub es
capaz de manipular 400 K * 2 = 800 K de mensajes por día.
Las unidades aumentan la escalabilidad de la aplicación.

Alta disponibilidad
IoT Hub es un servicio PaaS de Azure. Los clientes y usuarios no interactúan
directamente con el número y el tamaño subyacentes de máquinas virtuales en las
que se ejecuta el servicio Azure IoT Hub. Los usuarios deciden la región, la SKU del
IoT Hub y la cantidad de unidades para la aplicación. El resto de la configuración
es determinado y ejecutado por Azure en segundo plano. Azure garantiza que
cada servicio PaaS tenga disponibilidad alta de manera predeterminada. Para esto,
se asegura de que haya varias máquinas virtuales aprovisionadas para el servicio
en bastidores separados del centro de datos. Esto se logra mediante la colocación
de las máquinas virtuales en un conjunto de disponibilidad y en un dominio
independiente de error y actualización. Esto contribuye a una alta disponibilidad
para el mantenimiento, tanto planificado como no planificado. Los conjuntos de
disponibilidad controlan la alta disponibilidad a nivel del centro de datos.
[ 135 ]
Diseñar soluciones de IoT

Para lograr una alta disponibilidad en diversos centros de datos de una o varias
regiones, los clientes tienen que tomar medidas adicionales para proveer servicios
adicionales de IoT Hub en diferentes regiones, y asegurarse de que los dispositivos
estén registrados en todos los servicios del IoT Hub y de que cada uno tenga el
mismo identificador. También tienen que crear una aplicación de supervisión
independiente en cada región, como una aplicación web, vinculada mediante un
administrador de tráfico que supervise continuamente el punto de conexión del
administrador de tráfico a fin de detectar la falta de disponibilidad de la ubicación
actual para redirigir el tráfico a otros IoT Hub, y escribir la lógica para enrutar los
mensajes del dispositivo hacia el IoT Hub nuevo.

Resumen
La IoT es una de las tecnologías futuras más importantes de esta década y ya está
transformando el sector con el tipo de soluciones que puede crear. Cosas que
parecían imposibles no lo son y ahora permiten rastrear, supervisar y tomar acciones
de manera remota. Azure IoT Hub actúa como una plataforma que facilita la
creación y entrega de soluciones de IoT al cliente de una manera más rápida, mejor
y económica. Proporciona la implementación de todos los protocolos del sector,
como MQTT y AMQP, junto con los gateways de campo que pueden adaptar los
dispositivos no estándares. Ofrece características de alta disponibilidad, escalabilidad
y seguridad para los mensajes y la solución en general. Brinda conectividad para
una gran cantidad de servicios de Azure y ayuda a enrutar los mensajes a puntos de
conexión diferentes, todos capaces de procesar los mensajes. La IoT puede acelerar
el ciclo de desarrollo completo y ayudar a diseñar estrategias de comercialización
más rápidas para las empresas.

Azure proporciona numerosas opciones de servicios y almacenamiento de datos.


El próximo capítulo será una introducción al almacenamiento de datos y los servicios
en Azure.

[ 136 ]
Diseñar e implementar
soluciones de datos
Que los datos son la nueva moneda se está volviendo realidad en estos días. Cualquier
organización que tenga muchos datos cuenta con una inteligencia y un conocimiento
enormes que pueden cambiar el futuro. Durante la última década, hubo innovaciones que
contribuyeron enormemente a la explosión de los datos. La primera fue la popularidad de
las plataformas sociales. Hay plataformas, como Facebook, LinkedIn y Twitter, que tienen
millones, si no miles de millones, de usuarios en todo el mundo, generalmente esto significa
millones de contenidos cada día. Hay una gran sabiduría y conocimiento en este contenido
de redes sociales. Otro paradigma de cambio de big data es la IoT. Los dispositivos de IoT
generan miles de millones de mensajes por día para una gran cantidad de industrias. El
hardware es cada vez más económico; esto alimenta aún más su uso en escenarios de IoT.
También queda bastante claro que los métodos y las herramientas tradicionales no son
apropiados para cargar grandes volúmenes de datos y generar conocimiento a partir de ellos.
No están hechos para el análisis de la big data. La disponibilidad de estos grandes volúmenes
de datos condujo a la innovación en el almacenamiento de datos de gran tamaño. Los sistemas
de big data, tales como Hadoop, se han vuelto muy populares para almacenar grandes
volúmenes de datos, análisis avanzados, y luego transmitir sistemas de datos en tiempo
real se convirtió en el foco de la innovación. Machine learning, la inteligencia artificial y el
aprendizaje profundo han tomado un rol protagónico para encontrar información de big data.

Los datos se caracterizan por el volumen, la velocidad y el formato variado.


Existe una necesidad de una variedad de servicios que puedan unirse para crear
soluciones completas para datos de gran volumen, alta velocidad y disponibles
en múltiples formatos. Estos servicios tienen que ser de clase y escala empresarial
con alta disponibilidad, centrados en el rendimiento y seguros. Azure es una
plataforma madura para manejar el ciclo de vida completo de los datos, desde el
almacenamiento hasta los análisis y la visualización; todos están disponibles con
varias opciones para cada etapa del ciclo de vida.

[ 137 ]
Diseñar e implementar soluciones de datos

En este capítulo, analizaremos en detalle lo siguiente:

• Azure SQL
• Extensión y particionamiento de Azure SQL
• Azure NoSQL Cosmos DB
• Azure SQL frente a Cosmos DB
• Azure Data Factory
• Azure Stream Analytics
• Data Lake
• Almacenamiento de tablas
• Almacenamiento de datos de SQL

Azure SQL
Azure SQL es una base de datos en la nube como un servicio disponible en Azure.
La principal tecnología de bases de datos de Microsoft, SQL Server, está disponible
desde hace más de 20 años, y Microsoft la proporciona en la nube y ofrece instancias
de base de datos completas a sus usuarios. Azure SQL es un servicio de base de
datos completamente administrada y relacional que ofrece alternativas de mayor
productividad, aprovisionamiento más rápido y fácil, y más económicas. Proporciona
casi todas las características de SQL Server completo sin necesidad de administrar
infraestructura y licencias.

Azure SQL se basa en un motor de base de datos de SQL Server y proporciona una
base de datos relacional como su característica principal. Los datos se almacenan en
formato tabular, en filas y columnas. Una combinación de columnas forma el esquema
de la tabla, y las filas se almacenan en forma tabular. Azure SQL es uno de los destinos
de datos más populares en Azure. Casi todas las aplicaciones necesitan que los datos
se conserven en el tiempo y Azure SQL ofrece los almacenes de datos para estas
aplicaciones.

Azure SQL es una base de datos basada en transacciones. Esto significa que brinda
soporte para las transacciones. Hay cuatro grandes principios de transacciones,
también conocidos como propiedades ACID. Son los siguientes:

• Atomicidad
• Coherencia
• Aislado
• Duradero

[ 138 ]
Capítulo 7

Azure SQL consta de dos componentes importantes:


• Servidor lógico de Azure SQL: esto es equivalente a una instancia de
SQL Server en el centro de datos local o las máquinas virtuales de Azure.
Un servidor es un límite físico y lógico que consta de varias bases de datos.
Proporciona un límite de seguridad con su propio conjunto de usuarios,
grupos y permisos. Los usuarios tienen que autenticarse con el servidor para
poder acceder a bases de datos. El servidor proporciona todas las funciones
y características de administración para gestionar y mantener Azure SQL.
• Bases de datos de Azure SQL: este es el componente principal de Azure SQL
porque es aquí donde se almacenan los datos. Cada base de datos consta de varias
tablas, cada tabla consta de columnas, y las columnas juntas contienen filas.
Las columnas de Azure SQL ofrecen varios tipos de datos para admitir diversos
tipos de datos. Incluye tipos de datos generales, tales como char, varchar, integer,
entre otros, y otros más avanzados, como JSON, XML y espaciales. Las tablas pueden
normalizarse de modo que la escritura y la lectura de datos pueda ser extremadamente
rápida, sin embargo, agrega redundancia de datos. También permite la creación de
varios tipos de índices en las columnas: agrupados, no agrupado, de cobertura, único
y así sucesivamente, para mejorar el rendimiento de las consultas.
Ofrece Transact-SQL como lenguaje para emitir instrucciones de manipulación de
datos y definición de datos. El motor de datos SQL hace el trabajo pesado de análisis,
convierte en tokens, almacena, encuentra un plan de ejecución óptimo y ejecuta
verdaderamente las consultas. También interactúa con el motor de almacenamiento
para recuperar datos del almacenamiento a la memoria y viceversa. Proporciona
e implementa las capacidades transaccionales y ofrece funciones de administración,
como registros, tareas, agentes, copia de seguridad, restauración y Always On.
El rendimiento de Azure SQL se mide en unidades de transacción de bases de
datos (DTU). Para que Azure garantice un acuerdo de nivel de servicio (SLA) de
rendimiento mínimo, se calculan de forma conjunta una combinación de recursos
informáticos, memoria y almacenamiento para constituir una DTU. Cada DTU
confirma y garantiza ciertos niveles de rendimiento.

[ 139 ]
Diseñar e implementar soluciones de datos

Azure SQL proporciona cuatro niveles de rendimiento. Son los siguientes:

• Básico: es para las cargas de trabajo menos exigentes que ofrecen 5 DTU
de rendimiento
• Estándar: es para cargas de trabajo de producción general y proporciona
entre 10 y 3000 DTU
• Premium: es para cargas de trabajo intensivas de I/O y ofrece entre 125 y 4000 DTU
• PremiumRS: una vez más, es para cargas de trabajo intensivas de I/O pero
con disponibilidad y durabilidad reducidas, y ofrece entre 125 y 1000 DTU

Los usuarios tienen que decidir las mejores necesidades de DTU en función de los
requisitos de su aplicación. Pueden comenzar con DTU bajas y, finalmente, escalar
hacia arriba con la mayor demanda de su aplicación. El escalado de las DTU agrega
más recursos informáticos, de IOPS y memoria sin detener la base de datos. El
escalado hacia arriba o hacia abajo ocurre de manera transparente sin afectar la
disponibilidad de la base de datos. El almacenamiento también puede ampliarse
o reducirse en función de los requisitos.

Disponibilidad de Azure SQL


Azure garantiza que los datos tengan una alta disponibilidad. Incluso en caso
de desastre o falla en el hardware, los datos están disponibles y proporcionan
capacidades múltiples para garantizar una alta disponibilidad.
Azure SQL realiza copias de seguridad automáticas de la base de datos del usuario. Se
realiza una copia de seguridad de estas bases de datos de manera tal de minimizar el tiempo
de recuperación en caso de desastre. Realiza una copia de seguridad completa por semana,
copias de seguridad diferenciales por hora y copias de seguridad de registros de transacciones
cada cinco minutos. Estas copias de seguridad se almacenan en un almacenamiento con
redundancia geográfica que mantiene varias copias en todo el mundo. En caso de desastre, el
soporte de Azure puede ayudar a conseguir estas copias de seguridad y restaurarlas.

[ 140 ]
Capítulo 7

Azure SQL también ofrece la replicación geográfica de bases de datos con hasta
cuatro bases de datos secundarias legibles en diferentes regiones. Todas estas
bases de datos primarias y secundarias se sincronizan continuamente mediante
la replicación asincrónica. También ofrece capacidad de la conmutación por error
automática a otra base de datos en otra región.

Azure SQL ofrece la recuperación a un momento dado y también restaura las bases de datos.

Seguridad de Azure SQL


Azure ofrece características de seguridad avanzadas para garantizar que nunca se
vean comprometidos los datos.

Azure SQL cifra y descifra de manera transparente todos los datos, copias de
seguridad y archivos de registro mediante el cifrado de datos transparente (TDE)
automáticamente. Las aplicaciones no son conscientes de este cifrado y descifrado
en segundo plano. Utilizan los datos como lo hacen normalmente; sin embargo, los
datos en reposo en un SQL Server no pueden ser comprendidos por nadie que tenga
acceso a ellos usando herramientas de base de datos. Las claves de cifrado pueden
administrarse y almacenarse en Azure Key Vault.

Azure SQL también se encarga de proteger los datos sobre la marcha que se transmiten
a través de una red. Ofrece una función Siempre cifrado que mantiene los datos
cifrados incluso durante el almacenamiento en reposo, durante el procesamiento de
consultas y en red.

Otra gran característica de seguridad que proporciona Azure SQL es


el enmascaramiento de datos dinámicos. Ayuda a exponer datos a usuarios sin
privilegios ocultando datos confidenciales en los resultados de consulta. Esto
también funciona de manera transparente sin cambiar la aplicación.

Los usuarios y grupos de Azure SQL pueden administrarse utilizando Azure Active


Directory (AD). Los usuarios de Azure Active Directory pueden brindar acceso al
servidor y la base de datos, y esto simplifica la administración general de identidades
mediante la centralización y externalización.

La seguridad de Azure SQL pasa desde el servidor hasta las filas en las tablas.
Proporciona seguridad en el nivel de filas en donde los usuarios pueden acceder solo
a aquellas filas a las que tienen autorización.

También permite el acceso a las direcciones IP que el administrador explícitamente


especificó en la lista de permitidos. Además, proporciona auditoría avanzada en
términos de quién accede al servidor y al registro de bases de datos de cada actividad
de escritura y lectura de datos.

[ 141 ]
Diseñar e implementar soluciones de datos

Grupos elásticos
Las DTU de Azure son excelentes para garantizar un nivel mínimo de rendimiento y uso
de recursos; sin embargo, Azure SQL dedica los recursos de una determinada DTU para
una base de datos de SQL y permanece igual incluso si los recursos se utilizan poco. En
caso de que haya una gran cantidad de bases de datos, cada una tendrá su propia DTU
exclusiva, aunque es posible que algunas de las bases de datos no se utilicen en absoluto
o se utilicen poco. Azure proporciona una mejor alternativa para estas situaciones en
las que hay una gran cantidad de bases de datos. Azure ofrece grupos elásticos que
ayudan a hospedar múltiples bases de datos en el mismo SQL Server y los coloca en
el mismo grupo. Cada grupo tiene asignadas DTU exclusivas conocidas como eDTU.
Dentro de este grupo, es posible que haya bases de datos que utilizan más recursos que
los previstos, mientras que otros no utilizan muchos recursos. Un grupo elástico ayuda a
agregar al grupo las DTU utilizadas por cada una de estas bases de datos y garantiza que
no se regulen las bases de datos que se utilizan en exceso y que no se sobrecarguen las
bases de datos que se utilizan poco. El costo de la eDTU se amortiza en varias bases de
datos, a pesar de que algunas bases de datos tengan un salto repentino en la demanda.
Los grupos elásticos ayudan a reducir el costo general de varias bases de datos y
garantizan que las bases de datos exigentes obtengan más recursos cuando los necesiten.

Escalado de crecimiento de Azure SQL


Azure SQL es una plataforma versátil y proporciona características para satisfacer diferentes
necesidades. El escalado de crecimiento de Azure es una de esas características, también
conocida como particionamiento. Imagine una situación en la que tiene una gran base de
datos que contiene millones de filas. El rendimiento de las consultas se degrada debido a que
una gran cantidad de escrituras y lecturas tienen que recorrer grandes conjuntos de registros.
Resulta mejor, desde el punto de vista del diseño, dividir esta gran base de datos en varias
más pequeñas y distribuir los datos en ellas.

[ 142 ]
Capítulo 7

Sin embargo, escribir tal controlador o administrador es una tarea difícil y titánica.
Azure proporciona características de escalado de crecimiento para satisfacer esta
necesidad de partición horizontal de datos entre varias bases de datos. Las aplicaciones
cliente se conectan a la base de datos principal de Azure, responsable de consultar datos
de bases de datos apropiadas, recopilar la información y enviarla a la aplicación cliente.
También se sigue el mismo proceso para las operaciones de escritura. Azure SQL también
proporciona la facilidad de combinar nuevamente estas particiones en una base de datos.

Es necesario particionar la tabla horizontalmente en función de claves predeterminadas,


y la base de datos principal tiene que mantener información sobre la gama de claves
con cada base de datos. Hay tareas de administración adicionales que también realiza
esta base de datos principal. La imagen a continuación muestra una estrategia típica
de particionamiento. Cada color muestra una base de datos que se ha particionado.
Mientras que algunos son grupos elásticos, el resto utilizan sus DTU exclusivas.

El portal de Azure no proporciona la interfaz de usuario necesaria para particionar


bases de datos. El escalado de crecimiento y el particionamiento se realizan con API
REST, PowerShell o cualquier lenguaje de programación que utilice el SDK de Azure
SQL y la biblioteca de clientes de la base de datos elástica.

[ 143 ]
Diseñar e implementar soluciones de datos

Las herramientas para administrar el particionamiento están


disponibles en https://docs.microsoft.com/es-es/azure/
sql-database/sql-database-elastic-scale-get-started.

Estas herramientas utilizan las bibliotecas de clientes de la base de datos elástica


y el SDK de Azure SQL para proporcionar diferentes opciones para administrar
el proceso de particionamiento y fusión.

Proporciona opciones para dividir y combinar bases de datos, crear una nueva
partición, agregar bases de datos a las particiones, ejecutar consultas en todas las
particiones y eliminar la partición. La anterior imagen muestra estas aplicaciones
cliente interactuando con Azure SQL.

Stream Analytics
Stream Analytics es un motor de procesamiento de eventos y datos completamente
administrado que ayuda a proporcionar análisis en tiempo real sobre los datos que
se transmiten. Mientras que Cosmos DB y Azure SQL proporcionan datos que ya
está disponibles en su almacenamiento, Stream Analytics ofrece análisis informático
de los datos que se transmiten en tiempo real a medida que se ingieren. No son
consultas sobre los datos almacenados en el almacenamiento permanente. Esta es
una capacidad muy potente que permite obtener información en tiempo real, en
lugar de encontrar información mucho después de ocurrido el evento.

La particularidad de Stream Analytics yace en el hecho de que los datos pueden


venir de cualquier parte: aplicaciones, dispositivos de IoT, otros servicios de Azure,
como centros de eventos o cualquier otro sistema.

El otro principio base fundamental de Stream Analytics es el procesamiento de un


gran volumen de datos. Se creó para procesar una gran cantidad de datos y extraer
conocimientos e información en tiempo real.

También permite la integración necesaria con otros sistemas y servicios para actuar
sobre el conocimiento extraído, como el envío de notificaciones, la activación de
alertas, el inicio de sesión en varios servicios de análisis de registro y la generación
informes mediante las herramientas de visualización.

La clave de Stream Analytics radica en el hecho de que datos de gran volumen,


velocidad y formato múltiple pueden ser procesados por un único servicio en tiempo
real; esto significa que se pueden tomar medidas en este.

[ 144 ]
Capítulo 7

En el siguiente diagrama, se muestra la arquitectura de Stream Analytics:

Stream Analytics brinda la funcionalidad de extracción, transformación y carga (ETL)


para procesos en tiempo real. Define una tarea configurada con los datos de entrada
junto con la fuente de datos, las transformaciones y el registro de datos de salida con
los destinos.

Hay muchos casos de uso para implementar Stream Analytics. Son los siguientes:

• Muchas industrias necesitan soluciones de análisis en tiempo real, como


sistemas de estacionamiento, sistemas de peaje en autopistas, venta de
entradas de cine, etc.
• Análisis de opiniones en las redes sociales
• Análisis de tráfico web
• Análisis de registro para infracciones de seguridad y de otro tipo, entre otros
• Supervisión de la infraestructura

Existen diversos componentes que forman parte del servicio Azure Stream Analytics.

[ 145 ]
Diseñar e implementar soluciones de datos

Orígenes de datos
Stream Analytics trabaja sobre los datos. Se extraen los datos de la ubicación de
origen y, después de la transformación, los datos se cargan en la ubicación de
destino. Tanto la ubicación de origen como la de destino se denominan origen de
datos en el lenguaje de análisis de Azure. Hay orígenes de datos, como los centros de
eventos de Azure y los IoT Hub, que pueden proporcionar datos para los análisis de
Azure. Puede haber otros orígenes de datos, como dispositivos de IoT que pueden
enviar datos directamente a Stream Analytics y otros locales o que se encuentran
en diferentes plataformas de nube. Los orígenes de datos podrían ser un lugar
donde se genera el evento o los datos, o bien podría ser un almacenamiento, como el
almacenamiento de Azure, IoT Hub, etc.

Integración de datos
Los orígenes de datos son los proveedores y receptores de datos. Sin embargo, lo
que ayuda a conectar Azure Stream Analytics con ellos es la integración de datos.
Azure Stream Analytics ofrece integración de orígenes de datos tanto de origen
como de destino. Esta integración consulta los datos dentro del intervalo de tiempo
especificado y los proporciona al motor de Stream Analytics para su procesamiento.

Transformación de datos
Los datos entrantes se procesan para obtener información. Este proceso de transformación
implica el filtrado, aumento y enriquecimiento de los datos. No todos los datos que
ingresan son de interés. Podría haber datos incorrectos o faltantes. Para asegurarse de
que la información no sea parcial y sesgada, los datos se tienen que integrar en una
etapa que proporcionará resultados precisos. Este es el trabajo de transformación. Azure
Stream Analytics proporciona un lenguaje de consultas de tipo SQL que ayuda a agrupar,
incorporar, unir y filtrar los datos según los requisitos empresariales.

Motor Stream Analytics


Este es el componente principal del análisis de transmisiones. Aquí es donde se
ejecutan las tareas de análisis de transmisiones e interactúan los componentes para la
extracción, transformación y carga (ETL) de los datos. Este motor sigue funcionando
y ejecuta continuamente tareas en ventanas de serie cronológica para garantizar la
recopilación de información en tiempo real.

[ 146 ]
Capítulo 7

Almacenamiento y presentación
El motor de análisis también puede ayudar a abordar la información recopilada.
Puede enviar los datos a un almacenamiento duradero, como Azure Blob Storage,
presentar los datos mediante herramientas de visualización, como Power BI,
o utilizarlos para enviar notificaciones.

Arquitectura
Azure Stream Analytics es una plataforma madura y un servicio de análisis en
tiempo real. Ofrece características para diversas entradas y salidas. En la imagen que
se muestra a continuación, hay diversas instancias de Event Hub, IoT Hub y Blob
Storage como orígenes de datos de entrada. Estos se pueden unir, agrupar
e incorporar en la misma tarea de Stream Analytics y generar información.

Existe el costo de egreso de datos (salientes) en Azure, sin embargo, el costo no se


aplica dentro de una región. Si la transferencia de datos sucede dentro de una región,
el costo de egreso no se aplica. Se aplica cuando la transferencia de datos se produce
entre regiones. Es por esta razón que se recomienda ubicar los orígenes de datos en
Azure dentro de la misma región que Azure Stream Analytics.

[ 147 ]
Diseñar e implementar soluciones de datos

En el portal de Azure, el panel de Azure Stream Analytics proporciona el número de


entradas y salidas.

Azure Data Factory


Por lo general, los datos se almacenan en archivos planos, bases de datos relacionales,
bases de datos NoSQL y otras ubicaciones en diversos formatos, como JSON, XML, CSV,
archivos de texto y binarios. Además, cada almacén de datos define su propio modelo para
almacenar los datos. El ID de un empleado de un almacén de datos se llama EMPIDID
en otro almacén de datos y EID en el tercer almacén de datos, dentro de la misma
organización. Existen varias facetas de los mismos datos en los diferentes almacenes
de datos. Azure Data Factory es un servicio de integración de datos que ayuda a crear
escenarios de organización y flujo de trabajo para la ETL de los datos. Azure Data Factory
trabaja con datos desde cualquier ubicación de nube, en las instalaciones, y trabaja a la
escala de la nube. Admite grandes volúmenes de datos con formatos variados.
Los flujos de trabajo de Azure Data Factory se conocen como canalizaciones de datos,
y Azure Data Factory ayuda a crear, implementar, supervisar y programar fácilmente estas
canalizaciones de datos. Azure Data Factory es un servicio PaaS administrado que proporciona
alta disponibilidad, escalabilidad y tolerancia a errores para las canalizaciones de datos.
Azure Data Factory puede ingerir datos desde distintas ubicaciones y cargar los
datos transformados finales en ubicaciones de tipos y destinos diferentes. En el inicio,
la fábrica de datos se parece a un servicio de ETL, pero hay una gran diferencia. La
principal diferencia entre la fábrica de datos y otras herramientas de ETL se basa en
la transformación. La transformación ejecutada por la fábrica de datos se relaciona con
servicios de procesos, como HDInsight Hadoop, Azure Data Lake Analytics, Spark y
Azure Machine Learning, mientras que la transformación ejecutada por otras herramientas
de ETL está relacionada con la transformación de filas y columnas, el filtrado y la
incorporación de filas y columnas, y el enriquecimiento de datos. Azure Data Factory
prepara los datos mediante el filtrado, la incorporación, la agrupación, la unión y el
enriquecimiento de los datos, y luego aplica la transformación mediante los servicios de
procesos. El resultado de esta transformación es información que puede ser utilizada por
las herramientas de visualización, como Power BI y otras aplicaciones personalizadas.
[ 148 ]
Capítulo 7

Azure Data Factory proporciona conectores para casi todos los almacenes de datos
importantes, incluidos SAP, Oracle, MongoDB y Cassandra, y admite diversos tipos
de protocolos y controladores para la conectividad con estos almacenes de datos,
como ODBC, OLEDB, ODATA y HTTP.

Las canalizaciones de la fábrica de datos se pueden programar para funcionar de


forma diaria, cada hora y semanalmente.

La principal diferencia entre Azure Data Factory y Azure Stream Analytics es que,
mientras que Azure Data Factory trabaja en una instantánea de los datos que están
disponibles en el almacenamiento duradero, Azure Stream Analytics trabaja con
datos en tiempo real transitorios que se procesan cuando se generan.

Existen dos versiones de Azure Data Factory: V1 y V2. V2 es una versión preliminar
y solo está disponible en las regiones Este de EE. UU. y Este de EE. UU. 2. V1 se
encuentra disponible de forma generalizada en Este de EE. UU., Oeste de EE. UU.,
Centro-oeste de EE. UU. y Norte de Europa. Se recomienda ubicar los orígenes de
datos de Azure en la misma región que los de Azure Data Factory.

La arquitectura de Azure Data Factory se muestra en la siguiente imagen:

Existen diversos componentes que forman parte del servicio de fábrica de datos.

Orígenes de datos
Primero, los datos tienen que ser ingeridos en la fábrica de datos. Estos pueden estar
en la nube o en las instalaciones. Luego, tienen que moverse en Azure Data Factory.
Azure Data Factory proporciona servicios vinculados y construcciones de conjuntos
de datos para conectar y recuperar datos en la fábrica de datos.

[ 149 ]
Diseñar e implementar soluciones de datos

Los conjuntos de datos se refieren a los datos reales almacenados en el origen o la


ubicación de los datos. Podría ser un archivo de valores separados por comas en el
servidor local o un archivo en un contenedor en la cuenta de almacenamiento de Azure,
como un blob, o en Azure SQL. Las posibilidades son infinitas. Los servicios vinculados
hacen referencia al proceso de conexión al origen de datos mediante una cadena de
conexión específica de origen de datos que permite buscar conjuntos de datos en la
fábrica de datos. Por ejemplo, para copiar datos del archivo blob de Azure a Azure SQL,
se necesitan dos conjuntos de datos y dos servicios vinculados. Un servicio vinculado
consistiría en la cadena de conexión a la cuenta de almacenamiento de Azure, mientras
que el otro podría contener la cadena de conexión para Azure SQL. El conjunto de datos
relacionado con el blob de Azure consistiría en archivos que contienen los datos, y el
conjunto de datos relacionado con Azure SQL consistiría en las tablas donde se escriben
los datos. La canalización de datos utiliza actividades (por ejemplo, la actividad de
copia) para conectarse a los orígenes de datos mediante servicios vinculados y copiar
los conjuntos de datos de la ubicación de origen a la fábrica de datos.

La fábrica de datos consta de diversas canalizaciones, y cada canalización consta de


actividades. Las canalizaciones se componen de diversas actividades donde cada
actividad es responsable de ejecutar una responsabilidad individual. Por ejemplo, la
actividad de copia se encarga de copiar datos de una ubicación de datos que utiliza
servicios vinculados y conjuntos de datos a otra ubicación de datos que utiliza
servicios vinculados y conjuntos de datos de destino.

A continuación, se muestra la relación entre actividades, canalización, servicios


vinculados y conjunto de datos.

Los tipos de conjuntos de datos disponibles en la fábrica de


datos están en https://docs.microsoft.com/es-es/
azure/data-factory/v1/data-factory-create-
datasets#Type.

Las canalizaciones de Azure Data Factory se pueden ejecutar manualmente o


programar para una ejecución periódica.

[ 150 ]
Capítulo 7

Transformación de datos
Ahora que los datos están disponibles en el almacén de datos, se pueden procesar
con los servicios de procesos, como Azure HDInsight Hadoop, Spark, Data Lake
Analytics y Machine Learning. Los resultados de los datos de las transformaciones se
pueden publicar para su uso.

Publicación y presentación
El resultado de la transformación se puede guardar en un almacenamiento duradero,
como Cosmos DB, Azure SQL, Azure Data Warehouse o cualquier herramienta de
análisis personalizado. Además, Power BI se puede conectar al almacenamiento
duradero para la creación de informes y paneles, y para la visualización.

Usar la fábrica de datos


En esta sección se mostrarán los detalles paso a paso sobre cómo usar Azure Data
Factory para crear conjuntos de datos, servicios vinculados y canalizaciones, y para
transferir datos de una cuenta de almacenamiento a otra.

La fábrica de datos proporciona numerosos almacenes de datos para la lectura y


transferencia de los datos. La fábrica de datos brinda una gran flexibilidad en cuanto
a la elección de un almacén de datos de origen y de destino. En la captura de pantalla
siguiente se muestran la cantidad y el tipo de almacenes de datos disponibles en la
fábrica de datos. Puede elegir cualquiera de ellos como origen y destino.

[ 151 ]
Diseñar e implementar soluciones de datos

Azure Data Factory también proporciona una interfaz de asistente para la


identificación de un almacén de datos de origen y sus datos, junto con el almacén de
datos de destino y sus datos. Esto se muestra en la siguiente captura de pantalla:

[ 152 ]
Capítulo 7

1. El primer paso es crear un recurso de fábrica de datos. Después de la


creación, haga clic en el botón Copiar datos:

[ 153 ]
Diseñar e implementar soluciones de datos

2. Se abrirá una ventana del explorador. Vaya a https://datafactory.azure.


com/. Esta URL proporciona una interfaz de usuario basada en asistente para
configurar la fábrica de datos:

3. Complete todos los detalles, como el nombre de la tarea, la información de


programación, el patrón recurrente, la fecha de inicio y la fecha de fin. Haga
clic en Siguiente.
4. Seleccione Azure Blob Storage como el almacén de datos de origen. Esto
podría ser cualquier origen de datos, y el siguiente paso que le solicitará
el asistente es el valor para la construcción de la cadena de conexión y el
servicio vinculado para conectarlo a esta. Esto se muestra en la siguiente
captura de pantalla. Haga clic en el botón Siguiente:

[ 154 ]
Capítulo 7

5. El siguiente paso le solicita al usuario que seleccione el archivo en el almacén


de datos de origen. Esta actividad crea un conjunto de datos para la fábrica
de los datos:

6. El archivo users.csv es un archivo sencillo que contiene algunos datos


representativos, sin embargo, en un escenario real, podrían estar disponibles
miles de millones de registros con terabytes de datos.

[ 155 ]
Diseñar e implementar soluciones de datos

7. El archivo users.csv se ve como muestra a continuación. Tiene un


encabezado en la primera fila y el resto de las filas contienen datos separados
por comas. Seleccione el tipo de compresión si el archivo ya está comprimido.

8. Haga clic en Siguiente para identificar el formato de archivo y mostrarlo


al usuario. Es aquí donde el usuario puede cambiar la configuración del
formato de archivo. Esto se muestra en la siguiente captura de pantalla:

[ 156 ]
Capítulo 7

9. Cuando haga clic en Siguiente, el sistema solicitará la configuración


de Almacén de datos de destino. Esto es similar al almacén de datos de
origen. Seleccione un almacén de datos de destino apropiado como se
muestra a continuación:

10. En nuestro ejemplo, seleccionamos Azure Blob Storage, pero se recomienda


a los usuarios probar todos los tipos de almacenes de datos, como Azure
Data Lake Store, Azure DocumentDB, Azure SQL Data Warehouse, Azure
Table Storage, Azure Search, Oracle y SQL Server.
11. Especifique los detalles de la cadena de conexión para el almacén de datos de
destino como se muestra a continuación y luego haga clic en Siguiente.

[ 157 ]
Diseñar e implementar soluciones de datos

12. Proporcione los detalles apropiados para el conjunto de datos de destino,


como el nombre de contenedor y el nombre de archivo, como se muestra en
la siguiente captura de pantalla y haga clic en Siguiente:

[ 158 ]
Capítulo 7

13. Configure el Formato de archivo para el almacén de datos de destino como


se muestra en la siguiente captura de pantalla y haga clic en Siguiente:

[ 159 ]
Diseñar e implementar soluciones de datos

14. Configure la tolerancia y el rendimiento (mediante escrituras paralelas) como


se muestra a continuación y haga clic en Siguiente:

15. Valide todos los detalles como se muestra en la ventana Resumen. Esto se


muestra en la siguiente captura de pantalla, luego haga clic en Siguiente:

[ 160 ]
Capítulo 7

16. Se iniciará el proceso de implementación. En la captura de pantalla siguiente


se muestra que la implementación se realizó correctamente y que los datos
se transfirieron del Centro-oeste de EE. UU. al Centro-sur de EE. UU., de
un Azure Blob Storage a otro.

[ 161 ]
Diseñar e implementar soluciones de datos

17. Esta será una actividad programada si la programación se configuró previamente.

Azure Data Lake


Azure Data Lake es un servicio alojado en Azure que proporciona servicios integrales
para el almacenamiento de big data y sus posteriores transformación y análisis. Abarca
diferentes servicios:

• Azure Data Lake Store


• Azure Data Lake Analytics

Ofrece escalabilidad, rendimiento y seguridad de nivel empresarial para el


almacenamiento y procesamiento de datos. Ayuda en la ejecución masiva de cargas de
trabajo paralelas y es un servicio muy solicitado por los científicos y analistas de datos.

Azure Data Lake Store


Azure Data Lake Store ofrece almacenamiento para big data. Proporciona un
almacenamiento a escala de petabytes y está altamente optimizado para el almacenamiento
de datos de gran volumen, alta velocidad y diferentes tipos y formatos. Los datos de
diferentes formato y tamaño se pueden almacenar conjuntamente en el mismo Data Lake.

El almacenamiento tradicional, como los sistemas de archivos, las bases de datos


relacionales y otros tipos de almacenamiento, son cuentas de almacenamiento de
propósito general y no son adecuadas para el almacenamiento de big data de acceso
para fines de análisis. Es necesario optimizar el repositorio para la realización más
rápida y eficaz de consultas, y tiene que ser capaz de almacenar datos procesados
y sin procesar. Azure Data Lake se creó específicamente con este propósito.

[ 162 ]
Capítulo 7

Azure Data Lake es compatible con una variedad de herramientas y servicios,


incluidos HDInsight Hadoop, Azure Machine Learning, Azure Stream Analytics,
Azure Data Factory, Azure Event Hubs, entre otros.

Los datos provienen de una variedad de orígenes y dispositivos, como las redes
sociales, los dispositivos de IoT, las aplicaciones de línea de negocio, las bases de datos
relacionales y no relacionales, la extracción de datos de sitios web, y muchos más.

Actualmente, solo está disponible en tres ubicaciones de Azure: Este de EE. UU. 2,


Norte de Europa y Centro de EE. UU.

Finalmente, Azure Data Lake es un almacenamiento jerárquico basado en archivos


similar a un sistema de archivos de Windows, Linux o Hadoop que se optimizó para
las consultas y el almacenamiento eficientes de cargas de trabajo de big data.

Los datos de Azure Data Lake son de alta disponibilidad, ya que se obtienen diversas
réplicas y se almacenan en diferentes centros de datos.

[ 163 ]
Diseñar e implementar soluciones de datos

Azure Data Lake y la seguridad


La seguridad es sumamente importante cuando se trabaja con datos. Azure Data Lake
es un repositorio seguro, cuyo acceso es administrado por Azure AD. Los usuarios,
grupos y aplicaciones de servicio que se suministran y habilitan en Azure AD pueden
acceder a Azure Data Lake Store. Por otra parte, después de la autenticación, la
identidad tiene que tener los permisos suficientes para realizar actividades en Azure
Data Lake Store. El Control de acceso basado en roles (RBAC) de Azure Resource
Manager (ARM) es responsable de hacer cumplir la comprobación del permiso y
la autorización de una identidad. Existe una seguridad de autorización adicional
en términos de Listas de control de acceso (ACL). Las ACL se pueden aplicar con
permisos de lectura, escritura y ejecución de carpetas, subcarpetas y archivos.

Al igual que con Azure SQL, a Data Lake Store solo pueden acceder las
direcciones IP que están explícitamente permitidas en las listas blancas en la
configuración de Data Lake Store. Dado que los servicios de Azure acceden con
frecuencia a Azure Data Lake, está disponible una configuración adicional para
proporcionarles acceso sin conocer sus direcciones IP.

Los datos almacenados en Azure Data Lake Store se pueden cifrar. Los datos en
reposo pueden estar cifrados, de modo que no puedan ser leídos por cualquier
persona que tenga acceso a ellos. De manera similar a SQL Azure TDE, los datos
de Data Lake Store se pueden cifrar antes del almacenamiento y descifrar después
de la recuperación de forma transparente, sin que la aplicación se vea afectada. Se
recomienda guardar cifrados los datos en reposo. Las claves de cifrado y descifrado
se pueden almacenar en Azure Key Vault.

Azure Data Lake y el rendimiento


El rendimiento es otro aspecto muy importante para las soluciones basadas en
Data Lake Store. Dado que Data Lake Store es un repositorio, tiene que ofrecer un
almacenamiento intensivo con un alto rendimiento en términos de más IOPS para
lecturas y escrituras. El almacenamiento tradicional no consume todo el rendimiento
disponible del almacenamiento y el hardware. En cambio, Azure Data Lake Store
ofrece un mayor rendimiento mediante la paralelización del acceso a los datos y el
consumo del ancho de banda disponible del hardware.

Es necesario tener en cuenta que, para las soluciones integrales, lo importante no es


solo el rendimiento de Azure Data Lake Store. De hecho, el rendimiento de todos los
orígenes de datos de los que se ingieren los datos en Azure Data Lake Store también
es importante, junto con los servicios que acceden a los datos con fines analíticos.

[ 164 ]
Capítulo 7

Azure Data Lake Analytics


Azure Data Lake Analytics es uno de los servicios más representativos de Azure para
llevar a cabo tareas de análisis. Azure Data Lake Stores se encarga de guardar big data de
una manera optimizada. Sin embargo, en una situación integral, los datos almacenados
son útiles si un servicio los lee y ese servicio puede realizar análisis a partir de dichos
datos y obtener perspectivas significativas. Por naturaleza, el servicio de análisis requiere
de una gran cantidad de procesos debido al procesamiento exhaustivo de muchos datos.
Configurar un entorno para tal servicio implica el aprovisionamiento y la configuración
de máquinas virtuales, su adaptación para rendimiento y su mantenimiento. Azure
Data Lake Analytics proporciona una plataforma como una capacidad del servicio para
llevar a cabo tareas de análisis. Eso significa que los usuarios ya no necesitan pensar en el
aprovisionamiento y la configuración de la infraestructura y el hardware; por el contrario,
pueden concentrarse en la elaboración de los análisis y en el problema empresarial.
Azure Data Lake Analytics proporciona su propio lenguaje U-SQL estilo SQL con
la capacidad de integrar un código que, por lo general, se escribe con lenguajes de
programación, como C#. Es un lenguaje versátil que puede consultar varios tipos de bases
de datos, como SQL de Azure, SQL Server de IaaS y almacén de datos de SQL Azure.
Otro beneficio importante, además del bajo mantenimiento, es que proporciona
el modelo de pago por uso desde una perspectiva de costo. Los usuarios pagan
solamente cuando se llevan a cabo las tareas de análisis y no por otra cosa. No hay
ningún cargo por aprovisionar Azure Data Lake si no se ejecuta.
Azure Data Lake Analytics es un servicio escalable. Eso significa que cuando se ejecuta una
tarea en Azure Data Lake Analytics, aprovisiona recursos de procesos y de memoria en
segundo plano y, de manera dinámica, continúa con el escalado de crecimiento a medida que
se incrementa la demanda de recursos. Una vez finalizada la tarea, los recursos se reducen
automáticamente. Todo esto sucede de forma transparente sin que el usuario se entere.
Azure Data Lake Analytics, al igual que Azure Date Lake Store, está integrado con
Azure AD con fines de autenticación. Los usuarios, los grupos y las aplicaciones
de servicio disponibles en Azure AD pueden acceder Azure Date Lake Analytics.
El RBAC de ARM también se utiliza desde una perspectiva de autorización para
determinar los permisos que rigen para los usuarios y Azure Date Lake Analytics.

Azure SQL Data Warehouse


Azure SQL es un servicio de gran escalabilidad, duradero, centrado en el rendimiento y de
mucha disponibilidad para datos de transacción. Tradicionalmente, esto se denominaba
aplicaciones de procesamiento de transacciones en línea (OLTP). Existe otro conjunto de
aplicaciones comúnmente conocido como procesamiento de análisis en línea (OLAP).
Por lo general, las aplicaciones de OLAP se basan en almacenes de datos que guardan
una cantidad enorme de información en un formato que está listo para ser usado por los
motores de análisis, como los SQL Server Analysis Services (SSAS). El almacén de datos
guarda información que se desnormaliza para realizar consultas de manera eficiente.

[ 165 ]
Diseñar e implementar soluciones de datos

Los almacenes de datos se clasifican en almacenes de datos de lectura importantes.


La escritura en este almacén de datos sucede en forma periódica, contrariamente a lo
que sucede con las aplicaciones de OLTP en las que se puede comparar la escritura
y la lectura. En general, las aplicaciones que proporcionan informes, visualización
y servicios de análisis se conectan a un almacén de datos para cargar y generar
perspectivas de análisis a partir de dicho almacén.

Los almacenes de datos también se caracterizan por su enorme necesidad de


almacenamiento y potencia de proceso. Usualmente, consisten en terabytes y petabytes
de datos, y realizan el agregado y el agrupamiento de millones y millones de registros.

Azure proporciona el almacén de datos SQL como un servicio en la nube que tiene una
escalabilidad masiva, un alto rendimiento ajustable y gran disponibilidad y seguridad. Está
desarrollado a partir de Azure SQL Server y bases de datos, y de esa manera obtiene todos
sus beneficios y características. Además, almacena datos en los servicios de almacenamiento
blob de Azure, que pueden almacenar una cantidad prácticamente ilimitada de datos.

A continuación, se muestra la arquitectura del almacén de datos de Azure SQL. El


almacén de datos de Azure SQL se compone de dos tipos de nodos:

• Nodo de control: este nodo es responsable de toda interacción con los usuarios
y las aplicaciones que interactúan con el almacén de datos de Azure SQL. Es
el cerebro principal y el motor detrás de la ejecución del almacén de datos de
Azure SQL. Es responsable de coordinar las necesidades informáticas y de
almacenamiento con todos los nodos de trabajo o proceso. También ayuda en
la distribución de la carga entre ellos.
• Nodos de proceso: estos nodos son los caballos de batalla reales del
almacén de datos de Azure SQL. Son los que almacenan y recuperan datos
del almacenamiento blob de Azure y proporcionan potencia de proceso
mediante la ejecución de sentencias de SQL contra los datos. Implementan
una tecnología llamada PolyBase que ayuda en la ejecución de sentencias
de SQL contra los datos almacenados en las tiendas no relacionales, como el
servicio de almacenamiento blob de Azure.

Tanto el nodo de control como el nodo de proceso dependen de la base de datos de


Azure SQL y se alojan en el SQL Server lógico de Azure.

Existe otro componente importante denominado servicio de movimiento de datos (DMS)


que está disponible en todos los nodos del almacén de datos de Azure SQL,
independientemente de que sean nodos de control o proceso. Esto es lo que en
realidad ayuda en la circulación de datos, porque combina y agrega datos de varios
nodos de proceso, y presenta datos uniformes al solicitante.

[ 166 ]
Capítulo 7

Las siguientes son algunas características importantes del almacén de datos de Azure SQL:

• Sistema de procesamiento paralelo en forma masiva (MPP) que proporciona


características para implementar el almacenamiento de datos en paralelo.
• La interacción se basa en Transact-SQL. Capacidad para conectar con
herramientas y controladores de SQL.
• Disponible prácticamente en todas las ubicaciones de Azure para ayudar a la
gobernanza y la soberanía de los datos.
• Elasticidad absoluta desde la perspectiva de almacenamiento. Disponibilidad
de almacenamiento prácticamente ilimitada.
• La capa informática es diferente de la capa de almacenamiento. Esto ayuda
a poder escalarlas de manera independiente.
• Proporciona la capacidad y la potencia de consulta de un SQL Server.

[ 167 ]
Diseñar e implementar soluciones de datos

• Proporciona todos los beneficios de Azure SQL:


°° Lista de control de acceso de firewall basada en FIP
°° Escalabilidad y disponibilidad siempre activas
°° Particionamiento horizontal
°° Agrupación para la optimización de costos
°° Seguridad
Un aspecto importante del almacén de datos de Azure SQL es la configuración de
rendimiento ajustable. El rendimiento se define mediante una unidad de almacén
de datos (DWU). Cada DWU proporciona SLA sobre procesos, IOPS y memoria. El
costo del almacén de datos de Azure SQL aumenta con una configuración superior
de la DWU. Esto es similar a las DTU proporcionadas por Azure SQL. Los usuarios
pueden decidir cuáles son los mejores requisitos de rendimiento para su aplicación
y modificar la escala de rendimiento en consecuencia. Existen dos formas diferentes
en que puede modificarse el rendimiento. Son los siguientes:
• Optimizado para elasticidad: según Azure, esto separa el proceso y el
almacenamiento para un cálculo de tamaño independiente y flexible de
los recursos. Está diseñado para operaciones de escalado habituales que
administran el gasto informático y las situaciones de irrupción en la nube.
Ofrece el punto de escala inicial más bajo.
• Optimizado para proceso (adelanto): muy pronto.

El almacén de datos de Azure SQL puede integrarse a un host de servicios en Azure


de la siguiente manera:
• Machine learning
• Power BI
• Stream Analytics
• Data Factory
[ 168 ]
Capítulo 7

Almacenamiento de tablas
El servicio de almacenamiento de tablas de Azure está disponible como parte de la
cuenta de almacenamiento de Azure. El almacenamiento de Azure ofrece varios tipos
de almacenamiento, y el servicio de tablas es uno de ellos. El servicio de tablas de Azure
es un servicio de almacenamiento a escala de petabyte totalmente administrado, seguro,
escalable y de gran disponibilidad que ayuda a almacenar datos en el formato de NoSQL.
Como sabemos, NoSQL ayuda en la construcción de un diseño sin esquema; el servicio de
tablas de Azure también es sin esquema. Colabora en el almacenamiento de documentos
con pares de atributos de clave. Esto significa que el servicio de tablas no impone ningún
esquema en las entidades. Las entidades pueden tener diferentes propiedades para cada
entidad a la vez sin modificación.

Los datos de las tablas de Azure se almacenan como entidades. Los datos se almacenan
en formato tabular, donde las entidades forman filas y las propiedades forman columnas
individuales. Una entidad es muy similar a una fila en una base de datos relacional,
y cada servicio de tablas consta de varias entidades y cada entidad consiste en un par
de claves que ayudan a identificar en forma exclusiva a la entidad. A continuación, se
muestra la relación entre el servicio de tablas, las entidades y el almacén de claves/
valores. Se hace referencia a las entidades con claves de partición y fila. Los valores para
las claves de partición y fila tienen que provenir de los datos mismos.

Las particiones tienen que pensarse como una división de la tabla en una estructura
lógica separada para una consulta rápida y simple. Una partición se identifica de manera
exclusiva con el nombre de la cuenta de almacenamiento, el nombre de tabla y el nombre
de la partición. Es muy importante que las claves de partición y fila se decidan en forma
adecuada. Pueden tener un tamaño máximo de 1 KB cada una. Su combinación tiene que
ser única en la tabla para que cualquier entidad pueda identificarse de manera exclusiva y
también indexarse. Las particiones ayudan a escalar las tablas en terabytes sin sacrificar el
rendimiento de las consultas. Es muy similar al particionamiento en Azure SQL.

[ 169 ]
Diseñar e implementar soluciones de datos

Los detalles sobre el diseño de tablas en Azure están disponibles


en https://docs.microsoft.com/es-es/azure/cosmos-db/
table-storage-design-guide.

Es necesario tener en cuenta que los servicios de tablas son parte de la cuenta de
almacenamiento. Cada cuenta general de almacenamiento tiene un límite máximo
de 20.000 operaciones por segundo. Según los requisitos de las operaciones, esto
podría ser una exageración o insuficiente. Si estos números de operaciones no
son suficientes, es necesario considerar Cosmos DB. Otro aspecto es el límite de
almacenamiento en el servicio de tablas, que tiene un máximo de 500 TB. Para un
almacenamiento superior a los 500 TB, es necesario considerar Cosmos DB.

Otra limitación de los servicios de tablas es que permiten indexar solamente en las
claves de partición y fila. Esto los hace menos eficientes cuando se consulta con
respecto a otras columnas del servicio de tablas. La redacción de consultas complejas
con combinaciones es difícil con el servicio de tablas.

Los servicios de tablas almacenan datos como propiedades en formato tabular,


mientras que Cosmos DB almacena datos como objetos de documento JSON y el
objeto entero puede indexarse en lugar de algunas columnas seleccionadas.

Resumen
Los datos son uno de los elementos más importantes en una solución. Son valiosos y
necesitan estar protegidos y seguros. Durante los últimos años, cambió la naturaleza de
los datos. Los datos crecieron de manera exponencial en lo que respecta al volumen, y
también se incrementó mucho la velocidad de generación de datos. Además, los datos
se almacenan a nivel local y en la nube, en servicios PaaS y IaaS, y hay un montón de
controladores y protocolos para acceder a ellos. Los datos pueden estar en cualquier
formato; en consecuencia, analizarlos y comprenderlos en todos los formatos es un
desafío en sí mismo. Azure proporciona una gran cantidad de servicios para manejar
todas estas nuevas formas de datos. Azure ofrece Azure SQL, SQL en IaaS, grupos
flexibles, particionamiento, fábrica de datos, análisis de flujo, almacén y análisis de Data
Lake, almacén de datos, machine learning y Power BI para diseñar soluciones de datos
integrales desde la recopilación hasta el procesamiento, la transformación, la carga y el
análisis de los datos. Este capítulo fue una introducción a estos servicios en Azure, y es
necesario profundizar de manera más exhaustiva con la documentación de Azure.

En el próximo capítulo se analizará uno de los patrones de implementación más


emergentes en la nube conocido como sin servidor.

[ 170 ]
Diseñar e implementar
soluciones sin servidor
“Sin servidor” es uno de los conceptos en boga hoy en día en el sector de tecnología,
y todo el mundo quiere subirse a este tren. La arquitectura sin servidor aporta
muchas ventajas a la informática en general, los procesos de desarrollo de software,
la infraestructura y la implementación técnica. Están pasando muchas cosas en el
sector: en un extremo del espectro está la infraestructura como un servicio, mientras
que la informática sin servidor está en el otro extremo. En el medio están PaaS y
los contenedores. He conocido a muchos desarrolladores y me parece que existe
cierto nivel de confusión entre ellos sobre IaaS, PaaS, contenedores e informática sin
servidor. También hay mucha confusión acerca de los casos de uso, la aplicabilidad,
la arquitectura y la implementación del paradigma sin servidor. La informática sin
servidor es un nuevo paradigma que está cambiando no solo la tecnología, sino
también la cultura y los procesos dentro de las organizaciones.
En este capítulo el foco está puesto en los siguientes temas relacionados con las
soluciones sin servidor:
• ¿Qué es la arquitectura sin servidor?
• ¿Cuáles son las funciones de Azure?
• Crear su primera función de Azure
• Tipos de funciones de Azure
• Crear una función conectada
• Crear una función dirigida por eventos
• Crear una solución que consta de varias funciones

[ 171 ]
Diseñar e implementar soluciones sin servidor

En este capítulo, analizaremos en detalle lo siguiente:


• Facturación de Azure
• Facturas
• Uso y cuotas
• API de facturación y uso
• Calculadora de precios de Azure
• Procedimientos recomendados

Una historia breve de la informática


sin servidor
Para comprender la informática sin servidor, su arquitectura y su implementación,
primero es importante entender su historia y cómo evolucionó.
Al principio, existían servidores físicos. Aunque los usuarios tenían un control total
sobre los servidores físicos, las desventajas eran muchas:
• Un largo período de gestación entre el pedido y la implementación real del
servidor
• Uso intensivo de capital
• Desperdicio de recursos
• Bajo retorno de la inversión
• Difícil de realizar un escalado de crecimiento y hacia arriba
Una evolución natural de los servidores físicos fue la virtualización. La virtualización
se refiere a la creación de máquinas virtuales sobre los servidores físicos y a la
implementación de aplicaciones dentro de ellos. Las máquinas virtuales proporcionan
las siguientes ventajas:
• No hay necesidad de adquirir hardware físico
• La creación de máquinas virtuales nuevas es comparativamente más fácil
• Aislamiento total de los entornos
• Menores costos en comparación con los servidores físicos
Sin embargo, la virtualización tenía su propio conjunto de desventajas. Entre ellas:
• Todavía dependía de la adquisición física del servidor para el escalado de
crecimiento después de cierta cantidad de instancias de máquinas virtuales.
• Continuaba siendo costosa por su dependencia humana y de hardware.
• Desperdicio de recursos informáticos. Cada máquina virtual ejecuta un
sistema operativo completo.
• Gran dependencia y costos de mantenimiento.

[ 172 ]
Capítulo 8

La siguiente evolución fue IaaS de los proveedores de nube. En lugar de la


adquisición y administración de centros de datos e infraestructuras, la estrategia
consistía en crear máquinas virtuales, almacenamientos y redes en la nube. La nube
proporciona servicios de infraestructura definidos por software y oculta todos
los detalles relacionados con los servidores físicos, las redes y el almacenamiento.
Esto tenía algunas ventajas:
• Sin gastos de capital. Solo gastos operativos.
• Sin tiempo de gestación para crear máquinas virtuales nuevas. Las máquinas
virtuales nuevas se pueden aprovisionar en cuestión de minutos, en lugar de
horas.
• Tamaño flexible de las máquinas virtuales.
• Mayor facilidad de escalado hacia arriba y de crecimiento de las máquinas
virtuales.
• Seguridad total.
Las desventajas de las máquinas virtuales en la nube son las siguientes:
• Requieren supervisión y auditoría activas.
• Requieren mantenimiento activo de las máquinas virtuales.
• La escalabilidad, la alta disponibilidad y el rendimiento de las máquinas
virtuales deben ser administrados por los usuarios. Cualquier degradación
y la mejora subsiguiente son responsabilidad del usuario.
• Opción costosa porque los usuarios pagan por toda la máquina,
independientemente de si se usa o no.
La nube también ofrece otro patrón para la implementación de aplicaciones,
popularmente conocido como PaaS. PaaS brinda una abstracción de la infraestructura
subyacente en términos de máquinas virtuales, redes virtuales y almacenamiento
en la nube. Proporciona una plataforma y un ecosistema donde los usuarios no
necesitan saber nada acerca de la infraestructura, y pueden introducir e implementar
sus aplicaciones en estas plataformas. Existen ventajas bien definidas del uso de PaaS
en comparación con IaaS, pero aún puede haber opciones mejores. Las principales
desventajas de PaaS son las siguientes:
• Las aplicaciones PaaS se implementan en máquinas virtuales en segundo
plano y el modelo de pago no es granular. Aún están en el nivel de
implementación.
• Todavía requieren supervisión para el escalado horizontal.
• Los usuarios todavía necesitan identificar los requisitos de la plataforma.
Las opciones disponibles para los diferentes tipos de plataforma son
limitadas. Durante mucho tiempo, Azure proporcionó el entorno de Windows
y hace poco comenzó a estar disponible la opción de Linux. Además, la
instalación de paquetes, utilidades y software es responsabilidad de los
usuarios.

[ 173 ]
Diseñar e implementar soluciones sin servidor

Además, emergió un nuevo paradigma, los contenedores, que fue popularizado


principalmente por Docker. Los contenedores ofrecen un entorno ligero, aislado
y seguro que tiene todas las ventajas de las máquinas virtuales y ninguna de sus
desventajas. No poseen un sistema operativo dedicado y, en cambio, se basan en un
sistema operativo de servidor de base. Los contenedores vienen en patrones IaaS
y PaaS. Los contenedores ofrecen un gran número de ventajas:
• Brindan un aprovisionamiento rápido de entornos.
• Ofrecen una creación coherente y predecible de entornos.
• Ayudan a crear arquitecturas de microservicios
• Proporcionan un rico ecosistema con servicios avanzados de Kubernetes,
Swarm y DC/OS.
Las desventajas de los contenedores son las siguientes:
• Requieren supervisión y auditoría activas.
• Requieren mantenimiento activo.
• La escalabilidad, la alta disponibilidad y el rendimiento de las máquinas
virtuales deben ser administrados por los usuarios o herramientas avanzadas,
como Kubernetes. Cualquier degradación y la mejora subsiguiente son
responsabilidad del usuario.
Y esto nos conduce a la informática sin servidor como el estado actual de evolución
para la implementación y el consumo de aplicaciones.

Informática sin servidor


La informática sin servidor hace referencia a un modelo de implementación en el
que los usuarios solo son responsables del código y la configuración de la aplicación.
Los clientes de la informática sin servidor no tienen que preocuparse acerca de la
plataforma y la infraestructura subyacentes, y pueden concentrarse en la solución
de sus problemas de negocio mediante la escritura de código.
La informática sin servidor no significa que no existe ningún servidor. El código y la
configuración necesitan un servidor para la ejecución. La informática sin servidor
es desde la perspectiva de los clientes. Desde esta perspectiva, la informática sin
servidor significa que los clientes no ven el servidor en ningún momento. Tampoco
se preocupan por la plataforma y la infraestructura subyacentes. No necesitan
administrarlas y controlarlas. La informática sin servidor proporciona un entorno
que se puede escalar vertical y horizontalmente, de manera automática, sin que los
clientes se den cuenta. Todas las operaciones relacionadas con las plataformas y las
infraestructuras suceden en segundo plano, de manera transparente, sin que los
usuarios las perciban. Los clientes cuentan con acuerdos de nivel de servicio (SLA)
de rendimiento y Azure garantiza el cumplimiento de los SLA independientemente
del número o tamaño de los servidores necesarios.
Los clientes solo necesitan introducir el código, y el proveedor de la nube es el
responsable del resto de los artefactos necesarios para ejecutarlo.
[ 174 ]
Capítulo 8

Principios de la tecnología sin servidor


La tecnología sin servidor se basa en los principios siguientes.

Menor costo
El costo se basa en el consumo real de la potencia y los recursos informáticos. Si no
hay consumo, el costo es cero.

Basada en eventos
Las funciones de la arquitectura sin servidor tienen que ser capaces de ejecutarse
cuando se producen determinados eventos. El evento tiene que desencadenar la
ejecución de la función. En otras palabras, la arquitectura sin servidor tiene que
permitir que las funciones se desvinculen de otras funciones y, en cambio, dependan
de determinados eventos que las atañen.

Responsabilidad única
La arquitectura sin servidor tiene que implementar una funcionalidad
y responsabilidad únicas, y tiene que hacerlo bien. No se tienen que codificar
o implementar varias responsabilidades dentro de una misma función.

Rápida ejecución
Las funciones de la arquitectura sin servidor no tienen que tomar mucho tiempo
para completar una tarea. Tienen que ser capaces de ejecutarlo rápidamente y volver
a estar disponibles.

Funciones de Azure o funciones como un


servicio: FaaS
Azure proporciona funciones como un recurso. Se trata de implementaciones sin
servidor de Azure. Con las funciones de Azure, el código se puede escribir en el
idioma que le resulte más cómodo al usuario, y la función de Azure proporcionará un
tiempo de ejecución para ejecutarlo. En función del idioma elegido, se proporciona
a los usuarios una plataforma adecuada para que introduzcan su propio código.
Se trata de una unidad de implementación que se activa y desactiva automáticamente.
Cuando los usuarios utilizan las funciones, no pueden ver las máquinas virtuales y
las plataformas subyacentes, pero las funciones de Azure proporcionan una pequeña
ventana para verlas en la consola Kudu.

[ 175 ]
Diseñar e implementar soluciones sin servidor

Desencadenadores, enlaces y tiempo de


ejecución de las funciones de Azure
Existen dos componentes principales de las funciones de Azure.

Tiempo de ejecución de las funciones de Azure


El centro y el cerebro de las funciones de Azure es el tiempo de ejecución de
Azure. El precursor de las funciones de Azure es Azure WebJobs. El código de
Azure WebJobs también es una parte central de las funciones de Azure. Existen
características y extensiones adicionales que se agregaron a Azure WebJobs para crear
las funciones de Azure. El tiempo de ejecución de la función es la magia que la hace
realidad. Las funciones de Azure están alojadas en Azure App Service. Azure App
Service carga el tiempo de ejecución de Azure y aguarda un evento externo o una
solicitud de HTTP. Cuando recibe una solicitud o un desencadenador, carga la carga
entrante, lee el archivo function.json de la función para encontrar los enlaces y el
desencadenador de la función, asigna los datos entrantes a los parámetros entrantes
e invoca la función con los valores de los parámetros. Cuando la función finaliza su
ejecución, el valor se devuelve al tiempo de ejecución de la función de Azure a través
de un parámetro de salida definido como un enlace en el archivo function.json.
El tiempo de ejecución de la función devuelve los valores al llamador. El tiempo
de ejecución de la función de Azure actúa como un aglutinante que permite el
funcionamiento total de las funciones.

Enlaces y desencadenadores de las funciones de


Azure
Si el tiempo de ejecución es el cerebro de las funciones de Azure, entonces los enlaces
y desencadenadores son el corazón de las funciones de Azure. Las funciones de Azure
promueven la conexión flexible y la alta cohesión entre los servicios mediante el uso
de desencadenadores y enlaces. Por lo general, la aplicación implementa el código
con una sintaxis imperativa para los parámetros de entrada y salida, y los valores de
retorno. Esto suele dar como resultado la codificación de los parámetros de entrada.
Puesto que las funciones de Azure tienen que ser capaces de invocar cualquier
función definida, implementan un mecanismo genérico para invocar las funciones
mediante desencadenadores y enlaces.
Los enlaces son el proceso de creación de una conexión entre los datos entrantes
y la función de Azure, que asigna los tipos de datos. La conexión puede ser de una
dirección única del tiempo de ejecución a la función de Azure, de la función de Azure
al tiempo de ejecución para los valores de retorno o de varias direcciones, en que
el mismo enlace puede transmitir datos entre el tiempo de ejecución de Azure y las
funciones de Azure. Las funciones de Azure utilizan una forma declarativa para
definir los enlaces.

[ 176 ]
Capítulo 8

Los desencadenadores son un tipo especial de enlaces a través de los cuales se pueden
invocar las funciones en función de eventos externos. Aparte de invocar la función,
también se pasan los datos entrantes, la carga y los metadatos a la función.
Los enlaces están definidos en el archivo function.json:
{
"bindings": [
{
"name": "checkOut",
"type": "queueTrigger",
"direction": "in",
"queueName": "checkout-items",
"connection": "AzureWebJobsDashboard"
},
{
"name": "Orders",
"type": "table",
"direction": "out",
"tableName": "OrderDetails",
"connection": "<<Connection to table storage account>>"
}
],
"disabled": false
}

En este ejemplo, se declara un desencadenador que invoca la función cada vez


que hay un elemento nuevo en la cola de almacenamiento. El valor de type
es queueTrigger, el valor de direction es in y el valor de queueName es
checkout-items. También se muestran los detalles de la conexión de la cuenta
de almacenamiento de destino y el nombre de la tabla. Todos estos valores son
importantes para el funcionamiento de este enlace. El nombre checkOut se puede
utilizar dentro de las funciones como una variable.
Asimismo, se declara un enlace para los valores de retorno. Aquí el valor de retorno
se denomina Orders y los datos son el resultado de la función de Azure. Los datos de
retorno se escriben en el almacenamiento de la tabla de Azure mediante la cadena de
conexión proporcionada.

[ 177 ]
Diseñar e implementar soluciones sin servidor

Tanto los enlaces como los desencadenadores se pueden modificar y crear con la
pestaña Integrar de las funciones de Azure. En segundo plano, se actualiza el archivo
function.json. Se declara el desencadenador checkOut, como se muestra aquí:

Y a continuación se muestra el resultado Orders:

Los autores de las funciones de Azure no necesitan escribir código de “plomería”


para obtener datos de diversos orígenes. Solo tienen que decidir el tipo de datos que
esperan del tiempo de ejecución de Azure. Esto se muestra en el segmento de código
siguiente. Observe que el desencadenador checkout está disponible como una cadena
de la función. Las funciones proporcionan tipos diferentes para poder realizar el envío
a una función. Por ejemplo, un enlace de cola puede proporcionar lo siguiente:
• Plain old simple object (POCO)
• String
• Byte[]
• CloudQueueMessage

[ 178 ]
Capítulo 8

El autor de la función puede utilizar cualquiera de estos tipos de datos y el tiempo


de ejecución de la función de Azure garantizará el envío a la función de un objeto
adecuado, como parámetro:
using System;
public static void Run(string checkOut, TraceWriter log)
{
log.Info($"C# Queue trigger function processed: { checkOut }");
}

También es importante saber que en las imágenes anteriores, los nombres de las
cuentas de almacenamiento son AzureWebJobsStorage y AzureWebJobsDashboard.
Estas claves se definen dentro del parámetro appSettings de las funciones de Azure.
Para obtener más información sobre los enlaces y desencadenadores de Azure,
consulte el siguiente enlace: https://docs.microsoft.com/es-es/azure/azure-
functions/functions-bindings-storage-queue.

Proxies de función de Azure


Los proxies de función son unas de las características adicionales más recientes de las
funciones de Azure. Después de comenzar a utilizar las funciones de Azure, durante
un tiempo podría haber una gran cantidad de implementaciones de funciones y a los
clientes les resultará difícil integrarlas a todas en un flujo de trabajo. En lugar de dejar
que los clientes entretejan estas funciones, se pueden utilizar los proxies de Azure.
Los proxies ayudan a proporcionar a los clientes una URL de función única y luego
invocan diversas funciones de Azure en segundo plano para completar los flujos de
trabajo. Es importante entender que los proxies son aplicables en aquellos casos en
los que las funciones aceptan solicitudes a petición en vez de ser determinadas por
eventos. Estas funciones internas conectadas a un proxy pueden estar dentro de una
aplicación de función única o en varias aplicaciones independientes. Los proxies
pueden recibir solicitudes de los clientes, convertir, anular y aumentar la carga,
y enviarlas a las funciones internas de backend. Una vez que obtienen una respuesta
de estas funciones, otra vez pueden convertir, anular y aumentar la respuesta, y
enviarla nuevamente al cliente.
Puede obtener más información sobre las funciones de Azure en https://docs.
microsoft.com/es-es/azure/azure-functions/functions-proxies.

[ 179 ]
Diseñar e implementar soluciones sin servidor

Supervisión
Obtenga información de registro completa para cada solicitud o desencadenador en
la pestaña Supervisar de las funciones de Azure. Esto ayuda a identificar problemas
y a realizar auditorías de riesgos, errores o excepción en las funciones de Azure.

Autenticación y autorización
Las funciones de Azure dependen de Azure App Service para sus necesidades de
autenticación. Azure App Service posee ricas características de autenticación en
las que los clientes pueden utilizar OpenConnectID y OAuth para la autenticación.
Los usuarios se pueden autenticar mediante las cuentas de Azure AD, Facebook,
Google, Twitter o Microsoft.

[ 180 ]
Capítulo 8

[ 181 ]
Diseñar e implementar soluciones sin servidor

Las funciones de Azure que se basan en HTTP también pueden incorporar el uso de
claves que se tienen que enviar junto con las solicitudes de HTTP. Estas claves están
disponibles en la pestaña Administrar de las funciones.

Las claves de función permiten la autorización de funciones individuales. Es necesario


enviar estas claves como parte del encabezado de solicitud de HTTP.
Las claves de host también permiten la autorización de todas las funciones de una
aplicación de función. Es necesario enviar estas claves como parte del encabezado de
solicitud de HTTP.
Las claves predeterminadas se emplean cuando se utilizan las claves de función
y host. Hay una clave de host adicional llamada _master que facilita el acceso
administrativo a la API de tiempo de ejecución de las funciones de Azure.

Configuración de las funciones de Azure


Las funciones de Azure ofrecen opciones de configuración en distintos niveles.
Proporcionan la configuración para los elementos siguientes:
• La plataforma propiamente dicha
• Los servicios de la aplicación de la función
Estas configuraciones afectan a cada función contenida por ellas. Obtenga más
información sobre estas configuraciones en https://docs.microsoft.com/
es-es/azure/azure-functions/functions-how-to-use-azure-function-
app-settings.

[ 182 ]
Capítulo 8

Configuración de la plataforma
Las funciones de Azure están alojadas en Azure App Service, por lo que obtienen
todas sus características. Los registros de diagnóstico y supervisión se pueden
configurar fácilmente con las características de la plataforma. Además, proporciona
opciones para la asignación de certificados SSL, el uso de un dominio personalizado,
autenticación y autorización (mediante Azure AD, Facebook y otros protocolos de
OAuth y OpenConnectID) como parte de las características de red.
Aunque los clientes no están preocupados por la infraestructura, el sistema operativo,
el sistema de archivos o la plataforma en la que realmente se ejecutan las funciones,
la función de Azure proporciona las herramientas necesarias para echar un vistazo
dentro del sistema subyacente para cambiarlos y ajustarlos. La consola y la consola de
Kudu son herramientas que se utilizan con este fin. Proporcionan un editor completo
para crear funciones de Azure y editar su configuración.
Las funciones de Azure, al igual que los servicios de la aplicación, permiten almacenar
información de configuración dentro de la sección de configuración de aplicaciones
web.config, que puede leerse a petición.

[ 183 ]
Diseñar e implementar soluciones sin servidor

Configuración de funciones de los servicios de la


aplicación
Esta configuración afecta a todas las funciones. Aquí puede administrarse la
configuración de la aplicación. Los proxies de función de Azure pueden habilitarse
y deshabilitarse. Analizaremos los proxies más adelante en este capítulo.
También ayudan a cambiar el modo de edición de una aplicación de función y la
implementación en las ranuras.

Planes de costos de la función de Azure


Las funciones de Azure se basan en los servicios de aplicación de Azure
y proporcionan un mejor modelo de cálculo de costos para los usuarios.
Hay dos modelos de costos:
• Plan de consumo: se basa en el consumo real y la ejecución de funciones.
Este plan calcula el costo en función del uso de procesos durante el consumo
real y la ejecución de la función. Si una función no se ejecuta, no hay ningún
costo asociado. Sin embargo, esto no significa que el rendimiento se vea
comprometido en este plan. Las funciones de Azure automáticamente
escalarán horizontalmente en función de la demanda para garantizar que
se mantengan los niveles básicos de rendimiento mínimo. Se permiten
10 minutos a la ejecución de una función para su finalización.

[ 184 ]
Capítulo 8

• Plan del servicio de aplicaciones: este plan ofrece máquinas virtuales


dedicadas completas en segundo plano para las funciones y, por lo tanto,
el costo es directamente proporcional al costo de la máquina virtual y a su
tamaño. Hay un costo asociado a este plan incluso si las funciones no se
ejecutan en absoluto. El código de función puede ejecutarse durante el tiempo
que sea necesario para finalizar. No hay límite de tiempo. Dentro del plan
del servicio de aplicaciones, el tiempo de ejecución de la función queda
inactivo si no se utiliza en pocos minutos y puede activarse solo mediante un
desencadenador HTTP. La configuración Siempre activo puede utilizarse para
no permitir que el tiempo de ejecución de la función quede inactivo. El escalado
es manual, o bien basado en una configuración de escalado automático.

Ventajas de las funciones de Azure


La informática sin servidores es un paradigma relativamente nuevo en la tecnología
de servidores y ayuda a las organizaciones a convertir grandes funcionalidades en
funciones discretas menores a petición que pueden invocarse y ejecutarse a través
de desencadenadores automáticos y tareas programadas. También son conocidas
como FaaS, en las cuales las organizaciones pueden concentrarse en sus problemas de
dominio en lugar de la infraestructura y la plataforma subyacentes. Además, ayudan
a democratizar la arquitectura de la solución en pequeñas funciones reutilizables, lo
que se deriva en un mayor valor para sus inversiones.
Hay una gran cantidad de plataformas informáticas sin servidor disponibles en
Internet. Algunas de las más importantes son las siguientes:
• Azure Functions
• AWS Lambda
• IBM OpenWhisk
• Iron.io
• Las funciones en Google Cloud
De hecho, cada pocos días se presenta un nuevo marco y se hace cada vez más difícil
para las empresas decidir y elegir el marco que les funcione mejor.
Azure proporciona un entorno enriquecido sin servidor conocido como Azure
Functions, y me gustaría señalar algunas características que admite para hacerlas
listas para la empresa:
• Gran variedad de desencadenadores: los desencadenadores actúan como
eventos y ejecutan automáticamente funciones informáticas sin servidor.
Estos desencadenadores pasan los datos sin procesar, la acción y el evento
importante a las funciones. La plataforma informática sin servidor tiene que
proporcionar diferentes tipos de desencadenadores, y esto habilita empresas
con múltiples opciones para su arquitectura de la solución. También tendría
que proporcionar facilidades para ejecutar las funciones periódicamente como
una tarea programada.
[ 185 ]
Diseñar e implementar soluciones sin servidor

• Webhooks: un webhook ayuda en la integración avanzada con servicios de


terceros. Coloca enlaces para que cualquier cambio en un servicio de terceros
comience a ejecutar las funciones informáticas sin servidor. Proporciona una
infraestructura enriquecida que puede colaborar con servicios importantes
como los sistemas de control de versiones y las plataformas de redes sociales.
• Ejecución a petición: las funciones no solo pueden ejecutarse en función de
los desencadenadores, sino que también tienen un mecanismo para ejecutarse
manualmente. Esto aporta flexibilidad durante el desarrollo y la prueba de las
funciones.
• Escalabilidad ilimitada: una plataforma informática sin servidor tiene que
escalar horizontalmente las funciones de forma dinámica según la demanda.
Generalmente, las funciones informáticas sin servidor son accesibles a través
de Internet, y es difícil predecir la cantidad de usuarios que potencialmente
podrían conectarse a ellas. Es muy importante que escalen automáticamente
hacia arriba con más instancias durante la alta demanda y hacia abajo cuando
se reduce la demanda. Esto ayudaría a las empresas a reducir el gasto de
capital en una infraestructura que permanece inactiva durante gran parte del
año.
• Alta disponibilidad: esto es una obviedad. Las funciones sin servidor tienen
que tener una alta disponibilidad. A las empresas no les agrada el tiempo de
inactividad no planificado y es muy importante que las funciones sin servidor
estén disponibles todo el tiempo (las 24 horas del día, los 7 días de la semana,
los 365 días del año). Si una plataforma informática sin servidor no garantiza
más de cinco nueves en términos de disponibilidad (99,999 %), las empresas
tienen que buscar otra plataforma.
• Seguridad: la plataforma tiene que proporcionar una infraestructura
adecuada para brindar seguridad a las funciones sin servidor. Tiene que haber
aprovisionamiento para autenticar, autorizar y mantener la confidencialidad
y la identidad de los usuarios. Por otra parte, es necesario que la plataforma
proporcione medidas para autenticar utilizando los protocolos de
autorización basados en OAuth de nueva era. La plataforma también tiene
que permitir el uso compartido de recursos entre orígenes (CORS). CORS
permite que el código JavaScript se ejecute en un explorador en un host
externo para interactuar con funciones sin servidor para que las funciones
sean accesibles a través de Internet.
• Estándares de la industria: la plataforma tiene que utilizar los estándares de
la industria en lugar de la tecnología patentada. JSON se está convirtiendo
en el estándar concreto para el intercambio de carga de mensajes en puntos
de conexión REST. Tendría que admitir los protocolos HTTP y HTTPS.
Esto permite que las aplicaciones multiplataforma invoquen y utilicen estos
servicios.

[ 186 ]
Capítulo 8

• Monitoreo, registro y auditoría: cualquier plataforma sin servidor tiene


que proporcionar una infraestructura para monitorear funciones a nivel
operativo, generar alertas e informar a los equipos para tomar medidas
correctivas sobre ellos. La plataforma tiene que proporcionar un mecanismo
de registro enriquecido para reflejar las actividades en las funciones y
proporcionar mediciones de telemetría a su propietario. Esto tiene que incluir
la disponibilidad, la escalabilidad y los detalles de rendimiento entre otros.
Los registros tienen que ser de fácil acceso en forma de paneles y facilitar
la auditoría para los administradores. Las empresas desean optimizar el
tiempo, esfuerzo y dinero invertidos en mantener operativas las funciones sin
servidor. Es necesario que elijan una plataforma sin servidor que proporcione
abundante información operativa a través de las capacidades de seguimiento,
registro y auditoría.
• Admite DevOps: las empresas recuperaron mucho terreno con DevOps. Las
grandes empresas ya adoptaron DevOps; las pequeñas y medianas empresas
no se quedan atrás. Todas las empresas desean implementar tecnologías en
su panorama y ecosistema que son automatizables desde los procesos de
integración continua, implementación y entrega. La plataforma no solo tiene
que proporcionar puntos de conexión y utilidades de automatización, sino que
también tiene que ser fácil para los desarrolladores configurar las prácticas
relacionadas con DevOps para el desarrollo de la función.
• Soporte de lenguaje: una plataforma sin servidor tiene que ofrecer múltiples
opciones de lenguajes para el desarrollo de funciones. Atrás quedaron los
días en que las empresas utilizaban un único lenguaje popular para todas
sus actividades de desarrollo. Hoy en día, las empresas implementan
lenguajes muy conocidos para los desarrolladores. También utilizan lenguajes
heterogéneos en su panorama para obtener una mayor productividad y
afinidad con el tipo de aplicación que se desarrolla. Podrían ser C#, JavaScript,
Bash, PowerShell o una combinación de cualquiera de estas tecnologías.
• Herramientas avanzadas para crear, probar e implementar: las herramientas
tienen que hacer que el desarrollo, la prueba y la depuración resulten
fáciles para el desarrollador de la función. Además de ofrecer asistentes de
inicio rápido, las herramientas tienen que aumentar la productividad del
desarrollador a través de un entorno integrado para desarrollar y depurar,
de la ejecución de pruebas de unidades e integración, de la capacidad de
simular objetos y de la ayuda en implementaciones automatizadas. El editor
de creación tiene que proporcionar las plantillas y el código de andamiaje para
acelerar el desarrollo. También tiene que proveer emuladores que ayuden a
poner a prueba la función sin hospedaje en el entorno real.
• Tolerancia a errores: las funciones sin servidor no tienen que bloquearse
ni desaparecer debido a errores o excepciones en el código de usuario o la
infraestructura de servidor. Tienen que registrar las excepciones, informar al
usuario y continuar ejecutando elegantemente la solicitud siguiente.

[ 187 ]
Diseñar e implementar soluciones sin servidor

• Actividades de larga duración: una plataforma sin servidor tiene que


proporcionar flexibilidad para ejecutar actividades de larga duración. Luego
de que las actividades de larga duración finalizan su ejecución, la plataforma
sin servidor tiene que recoger la ejecución y regresar al usuario.
• Capacidad de configurar: aunque un cálculo sin servidor significa no tener
acceso a la plataforma subyacente, tiene que haber suficientes puntos de
contacto a través de los cuales los administradores puedan ver y cambiar
la configuración de la plataforma subyacente. Esto ayudará a las empresas
a solucionar problemas, realizar implementaciones avanzadas y adaptar la
plataforma a sus necesidades.
• Configuración de cuotas: la plataforma de cálculo sin servidor tiene que tener
flexibilidad para determinar las cuotas para su ejecución. Esto ayudaría a
restringir el uso irracional de un proceso sin servidor.
• Múltiples planes de hospedaje: la plataforma tiene que ofrecer opciones para
varios planes de uso en función del consumo y las ejecuciones de recursos.
Las empresas pueden elegir el plan que mejor se adapte a sus necesidades
y optimizar los gastos, al tiempo que garantizan ventajas económicas.
• Integraciones enriquecidas: la plataforma de cálculo sin servidor tiene que
ser capaz de integrarse con otros servicios, como los cognitivos, de análisis,
de comunicación y demás basados en transacciones, para proporcionar
servicios enriquecidos y contextuales a sus clientes. Esto ayudará a las
empresas a crear soluciones innovadoras y pertinentes para la industria.
• Paralelismo masivo: la plataforma sin servidor tiene que ser capaz de
ejecutar solicitudes de manera sincrónica y asincrónica. Esto finalmente
facilita la escritura de patrones que pueden ayudar en la escalabilidad masiva
utilizando de manera óptima los recursos de la plataforma.
• Configuraciones de niveles múltiples: la plataforma tiene que proporcionar
opciones de configuración en el nivel de función individual, de agrupación
de funciones y de plataforma. Esto ayudará a las empresas a cambiar el
comportamiento general de sus funciones, incluido el comportamiento de la
plataforma, con un mínimo esfuerzo.

Casos de uso de las funciones de Azure


Existen muchos casos de uso válidos para usar e implementar las funciones de Azure.

[ 188 ]
Capítulo 8

Implementación de microservicios
Las funciones de Azure ayudan a dividir aplicaciones grandes en unidades de código
funcionales y discretas más pequeñas. Cada unidad se trata de forma independiente
con respecto a las otras y evoluciona en su propio ciclo de vida. Cada una de esas
unidades de código tiene su propio proceso, hardware y requisitos de supervisión.
Cada función puede conectarse a todas las demás funciones. Los orquestadores
entrelazan estas unidades para crear una funcionalidad completa. Por ejemplo, en una
aplicación de comercio electrónico, puede haber funciones individuales (unidades
de código), cada una responsable de realizar listas de catálogos, recomendaciones,
categorías, subcategorías, carros de compras, pagos, formas de pago, gateways de
pago, direcciones de envío, direcciones de facturación, impuestos, gastos de envío,
cancelaciones, devoluciones, correos electrónicos, mensajes de texto, etc. Algunas de
estas funciones se integran con el propósito de crear casos de uso para aplicaciones de
comercio electrónico como la exploración de productos, el flujo de pagos, entre otras.

Integración entre múltiples puntos de conexión


Las funciones de Azure pueden crear una funcionalidad de aplicación general
mediante la integración de varias funciones. La integración puede realizarse sobre
la base de activación de eventos o de inserción. Ayuda a descomponer grandes
aplicaciones monolíticas en pequeños componentes.

Procesamiento de datos
Las funciones de Azure se pueden usar para procesar los datos entrantes en lotes.
Pueden ayudar a procesar datos que vienen en varios formatos como XML, CSV,
JSON, texto, etc. También pueden ejecutar algoritmos de conversión, enriquecimiento,
limpieza y filtrado. De hecho, se pueden utilizar funciones múltiples. Cada función
puede o bien convertir o enriquecer, o bien limpiar o filtrar. Las funciones de Azure
pueden utilizarse también para incorporar servicios cognitivos avanzados como el
reconocimiento óptico de caracteres (OCR), la visión informática, la manipulación de
imágenes y la conversión.

Integrar aplicaciones heredadas


Las funciones de Azure pueden ayudar a integrar aplicaciones heredadas con
protocolos más nuevos y aplicaciones modernas. Las aplicaciones heredadas pueden
no estar utilizando los formatos y protocolos estándares de la industria. Las funciones
de Azure pueden actuar como un proxy para estas aplicaciones heredadas, aceptar
solicitudes de los usuarios o de otras aplicaciones, convertir los datos en un formato
que una aplicación heredada pueda comprender y comunicarse con una aplicación
heredada mediante protocolos que entienda. Esto abre un mundo de oportunidades
para integrar y poner las aplicaciones antiguas y heredadas en el portfolio estándar.

[ 189 ]
Diseñar e implementar soluciones sin servidor

Tareas programadas
Las funciones de Azure se pueden utilizar con el propósito de realizar ejecuciones
continuas y periódicas para ciertas funciones de aplicaciones. Estas últimas pueden
tratarse de actividades periódicas muy variadas, como realizar copias de seguridad,
restaurar, ejecutar trabajos por lotes, exportar e importar datos, utilizar correos
electrónicos masivos, etc.

Gateways de comunicación
Las funciones de Azure pueden utilizarse en gateways de comunicación, como el uso
de centros de notificaciones, servicio de mensajes cortos (SMS) y correo electrónico.

Tipos de funciones de Azure


Las funciones de Azure se pueden categorizar en tres tipos:
• Funciones a petición: estas son funciones que se ejecutan cuando se llaman
o invocan de manera explícita. Algunos ejemplos incluyen las funciones
basadas en HTTP y webhooks.
• Funciones programadas: estas funciones trabajan como un temporizador
y ejecutan funciones en intervalos establecidos.
• Funciones basadas en eventos: estas funciones se ejecutan sobre la base de
eventos externos. Por ejemplo, subir un archivo nuevo al almacenamiento
blob de Azure genera un evento que puede iniciar la ejecución de la función
de Azure.

Crear su primera función de Azure


Las funciones de Azure pueden crearse a través del portal de Azure, PowerShell,
Azure CLI y API REST. Los pasos para crear una función utilizando la plantilla
de ARM ya se encuentran detallados en https://docs.microsoft.com/es-es/
azure/azure-functions/functions-infrastructure-as-code. En esta sección,
se aprovisionarán las funciones de Azure a través del portal.
Las funciones de Azure están alojadas en Azure App Service. Los usuarios crean una
nueva aplicación de funciones que a su vez crea un plan de servicio de aplicaciones
y un servicio de aplicaciones. El plan de servicio de aplicaciones se configura en
función de lo siguiente:
• Nombre: nombre del servicio de aplicaciones. El nombre tiene que ser único
en el dominio .azurewebsites.net.
• Ubicación: ubicación para hospedar al servicio de aplicaciones de las funciones
de Azure.

[ 190 ]
Capítulo 8

• Plan de hospedaje: es también conocido como el plan de precios. Aquí,


hay dos opciones disponibles, como comentamos anteriormente: el plan por
consumo y el plan de servicios de aplicaciones.
• Nombre del grupo de recursos: nombre del grupo de recursos que contiene el
plan de servicio de aplicaciones y el servicio de aplicaciones.
• Cuenta de almacenamiento: las funciones de Azure necesitan una cuenta de
almacenamiento de Azure para guardar los datos y registros.
• Habilitación de la información de aplicaciones: para capturar la información
de telemetría de las funciones de Azure.

[ 191 ]
Diseñar e implementar soluciones sin servidor

Crear una aplicación de funciones de Azure proporcionará un panel de control


después del aprovisionamiento.

Si hace clic en el botón “más” al lado de las funciones, aparecerá un asistente


para crear una nueva función. Este asistente muestra plantillas rápidas para crear
Webhook + API, temporizador y funciones de procesamiento de datos. Generará
el código de andamiaje y la estructura necesarios para comenzar. Este código de
andamiaje también se genera para los enlaces y desencadenadores predeterminados.
Además permite la selección de un lenguaje para implementar la función.
Las funciones de Azure permiten los siguientes:
• C#
• JavaScript
• F#
• PowerShell
• Bash
• Lenguajes de Python

[ 192 ]
Capítulo 8

Este asistente también permite la creación de funciones personalizadas desde cero.

Existen muchas más opciones para crear una función personalizada.

[ 193 ]
Diseñar e implementar soluciones sin servidor

En esta sección, se creará una función personalizada de Azure utilizando el lenguaje


de PowerShell, que se puede ejecutar cada vez que recibe una solicitud HTTP.
Proporcione un nombre apropiado, en este caso FirstFunction y seleccione
Anónimo como el nivel de autorización. Los niveles de autorización se verán más
adelante en este capítulo.

Crear esta función proporciona un entorno integrado de creación de funciones


completo junto con un código determinado. Este código obtiene el contenido sin
procesar del parámetro req entrante, que el tiempo de ejecución de Azure llena con
datos entrantes (cadena de consulta, valores del formulario, etc.) y lo convierte en el
objeto de PowerShell. Puede haber varios tipos de datos en este parámetro de entrada,
y se extraerá de este un solo valor de nombre. El tiempo de ejecución de las funciones
de Azure también crea una variable nueva para cada querystring entrante con una
solicitud de HTTP y la anexa con $req_query_. Por lo tanto, enviar el nombre como
querystring proporcionará una variable lista para usar, $req_query_name, que
contiene el valor para el nombre querystring y se consumirá dentro de la función.
La respuesta para esta función se escribe en un archivo que el tiempo de ejecución de
la función de Azure lee y regresa al explorador.

[ 194 ]
Capítulo 8

Esta función puede invocarse mediante una solicitud HTTP desde el explorador.
La URL para esta función está disponible desde el entorno y se compone del
nombre de la aplicación de funciones y el nombre de la función. El formato es
https://<<function app name>>.azurewebsites.net/api/<<function name>>.
En este caso, la URL será https://azureforarchitects.azurewebsites.net/api/
FirstFunction.
Para enviar parámetros a esta función, los otros parámetros de la cadena de consultas
pueden añadirse al final de la URL. Por ejemplo, para el envío de parámetros de
nombre de esta función, puede usarse la URL https://azureforarchitects.
azurewebsites.net/api/FirstFunction?name=ritesh. El resultado de la función
se muestra en la siguiente figura:

[ 195 ]
Diseñar e implementar soluciones sin servidor

Para funciones basadas en HTTP, la función de Azure ya proporciona elementos


desencadenantes y enlaces dentro del archivo function.json. Este archivo se utiliza
para definir todos los elementos desencadenantes y enlaces a nivel de la función, y
hay uno asociado a cada función.

La plantilla de HTTP crea un elemento desencadenante para todas las solicitudes


entrantes. El elemento desencadenante invoca la función de Azure y pasa todos los
datos entrantes y la carga como un parámetro denominado req. Este parámetro está
disponible dentro de la función de Azure. La respuesta de la función es un enlace que
toma la salida de la variable res de la función de Azure y la envía de vuelta al canal
HTTP como respuesta.

Crear una función dirigida por eventos


En este ejemplo, una función de Azure se conectará mediante escritura a la cuenta
de almacenamiento de Azure. La cuenta de almacenamiento tiene un contenedor
para alojar todos los archivos blob. El nombre de la cuenta de almacenamiento es
incomingfiles, y el del contenedor es orders:

[ 196 ]
Capítulo 8

Cree una función de Azure nueva desde el portal.

[ 197 ]
Diseñar e implementar soluciones sin servidor

A partir de ahora, esta función de Azure no tiene información de conectividad para la


cuenta de almacenamiento. Las funciones de Azure necesitan información de conexión
para la cuenta de almacenamiento, y esta se encuentra disponible en la pestaña claves
de acceso de la cuenta de almacenamiento. La misma información puede obtenerse
con el entorno del editor de función de Azure. De hecho, permite la creación de una
nueva cuenta de almacenamiento desde el mismo entorno del editor.
Puede agregarse con el botón nuevo al lado del tipo de Entrada de conexión de cuenta
de almacenamiento. Permite seleccionar una cuenta de almacenamiento existente
o crear una nueva. Debido a que ya tengo un par de cuentas de almacenamiento,
las vuelvo a usar. Los lectores tienen que crear una cuenta de almacenamiento de
Azure separada. Al seleccionar una cuenta de almacenamiento, se actualizará la
configuración en la sección appsettings y se le agregará la cadena de conexión.
Asegúrese de que ya exista un contenedor en el servicio de blob de la cuenta de
almacenamiento de Azure de destino. La entrada de la ruta se refiere a la ruta
al contenedor. En este caso, el contenedor de órdenes ya existe en la cuenta de
almacenamiento. El botón Crear aprovisionará la función nueva para supervisar el
contenedor de la cuenta de almacenamiento.

El código de la función de Azure es el siguiente:


public static void Run(Stream myBlob, TraceWriter log)
{
log.Info($"C# Blob trigger function Processed blob\n \n Size
{myBlob.Length} Bytes");
}

A continuación, se muestran los enlaces:


{
"bindings": [
{
"name": "myBlob",
"type": "blobTrigger",

[ 198 ]
Capítulo 8

"direction": "in",
"path": "orders",
"connection": "azureforarchitead2b_STORAGE"
}
],
"disabled": false
}

Ahora, al cargar cualquier archivo blob en el contenedor de órdenes se activará la


función:

[ 199 ]
Diseñar e implementar soluciones sin servidor

Crear una arquitectura conectada con


funciones
Una arquitectura conectada con funciones se refiere a la creación de múltiples
funciones, por lo que el resultado de una función activa otra función y proporciona
datos para que la siguiente función ejecute su lógica. En esta sección, continuaremos
con la situación anterior de la cuenta de almacenamiento. En este caso, el resultado de
la función que se activa con los archivos blob de almacenamiento de Azure escribirá el
tamaño del archivo en Cosmos DB de Azure.
A continuación, se muestra la configuración de Cosmos DB. De manera
predeterminada, no hay colecciones creadas en Cosmos DB. En forma automática, se
creará una colección mientras se crea una función que se activará cuando Cosmos DB
obtenga algún dato.

[ 200 ]
Capítulo 8

Cree una base de datos nueva testdb en Cosmos DB y una recolección nueva
denominada testcollection en ella. Mientras configura las funciones de Azure,
necesita tanto la base de datos como el nombre de la colección.

[ 201 ]
Diseñar e implementar soluciones sin servidor

Es momento de revisar la función storagerelatedfunctions y cambiar su enlace


para que el tamaño de los datos vuelva para el archivo cargado. Este valor devuelto
se escribirá en Cosmos DB. Esto exigirá un cambio en los enlaces y también con otro
que sea responsable de captar los valores de salida. En última instancia, este enlace
escribirá en la colección de Cosmos DB. Vaya a la pestaña Integrar y haga clic en el
botón Nueva salida después de la etiqueta Salidas y seleccione Azure Cosmos DB.

Proporcione los nombres apropiados para la base de datos y la colección (marque la


casilla de verificación para crear la colección si no existe), haga clic en el botón Nueva
para seleccionar la Azure Cosmos DB creada recientemente y deje el nombre del
parámetro como outputDocument.

[ 202 ]
Capítulo 8

Modifique la función como se muestra a continuación.

Ahora, la carga de un nuevo archivo a la colección de órdenes en la cuenta de


almacenamiento de Azure ejecutará una función que escribirá en la colección de
Azure Cosmos DB. Puede escribirse otra función con la Azure Cosmos DB creada
recientemente como un enlace de activación. Proporcionará el tamaño de archivos,
y la función podrá actuar en consecuencia. Esto se muestra a continuación:

[ 203 ]
Diseñar e implementar soluciones sin servidor

Resumen
“Sin servidor” es una nueva unidad de implementación en el mundo de hoy.
La evolución de las funciones con respecto a los métodos tradicionales motivó el
diseño de una arquitectura combinada de manera libre, con evolución independiente
y autosuficiente que en un principio era solo un concepto. Las funciones son una
unidad de implementación y proporcionan un entorno donde los usuarios no
necesitan para nada administrarlo. Su única preocupación tendría que ser el código
escrito para la funcionalidad. Azure ofrece una plataforma consolidada para alojar
funciones e integrarlas sin problemas según los eventos o la demanda. Casi todos los
recursos de Azure pueden participar en una arquitectura compuesta por funciones de
Azure. El futuro está en las funciones, porque cada vez más organizaciones quieren
alejarse de la administración de infraestructuras y plataformas. Quieren delegar esto
a los proveedores de la nube. Es una característica esencial que todos los arquitectos
que trabajan con Azure tienen que dominar.
El próximo capítulo es interesante ya que trata conceptos de Azure Resource
Manager, como directivas, bloqueos y etiquetas en detalle.

[ 204 ]
Diseñar políticas,
bloqueos y etiquetas
Azure es una plataforma de nube versátil. Los clientes no solo pueden crear
e implementar su aplicación, sino que también pueden administrar y regular sus
entornos de manera activa. Las nubes generalmente siguen un paradigma de pago por
consumo donde un cliente se suscribe a Azure y prácticamente puede implementar
cualquier cosa allí. Podría implementar desde una pequeña máquina virtual básica
hasta miles de máquinas virtuales con mayor cantidad de Sku. Azure no evitará
que ningún cliente aprovisione recursos ni los restringirá en cuanto a cantidad. En
una organización podría haber un gran número de personas que tengan acceso a la
suscripción de Azure. Es necesario tener un modelo de gobernanza preparado para
que las personas con derecho a crear recursos aprovisionen solo los necesarios y
suficientes. Azure proporciona características de administración de recursos, como el
control de acceso basado en roles (RBAC) de Azure y las políticas y los bloqueos para
administrar y proporcionar la gobernanza de recursos.
Otro aspecto importante de la gobernanza es el costo, el uso y la administración de
la información. La administración de las organizaciones siempre querrá mantenerse
actualizada sobre su consumo y el costo de la nube. Desearía identificar qué equipo,
departamento o unidad utiliza qué porcentaje de su costo total. En pocas palabras,
quiere tener informes basados en varias dimensiones sobre el consumo y el costo.
Azure ofrece una característica de etiquetado que puede ayudar a proporcionar este
tipo de información a la administración sobre la marcha.
En este capítulo, trataremos los siguientes temas:
• Azure RBAC
• Políticas de Azure
• Bloqueos de Azure
• Etiquetas de Azure

[ 205 ]
Diseñar políticas, bloqueos y etiquetas

Etiquetas de Azure
En un diccionario, se define “etiqueta” como una denominación asignada a alguien o algo
con el propósito de identificar o brindar otra información. Azure permite el etiquetado de
los grupos de recursos y recursos con pares de nombre y valor. El etiquetado ayuda
en la organización lógica y la categorización de los recursos. Azure también permite
etiquetar 15 pares de nombre/valor para los grupos de recursos y sus recursos.
Aunque el grupo de recursos sea un contenedor para recursos, etiquetarlo no
significa etiquetar sus recursos constitutivos. Los grupos de recursos y los recursos
tienen que etiquetarse según su uso, que se explicará más adelante en esta sección.
Las etiquetas funcionan en el nivel de la suscripción. Azure acepta cualquier par de
nombre/valor, y por ello es importante para una organización definir los nombres
y sus posibles valores.
Pero, ¿por qué es importante el etiquetado? En otras palabras, qué problemas se
pueden resolver mediante el uso de etiquetas. El etiquetado tiene los siguientes
beneficios:
• Categorización de los recursos: varios departamentos y roles dentro de
una organización utilizan una suscripción de Azure. Es importante para la
administración identificar a los propietarios de estos recursos. El etiquetado
ayuda a asignar identificadores a los recursos que pueden representar
a departamentos o roles.
• Administración de la información de los recursos de Azure: nuevamente,
cualquiera que tenga acceso puede aprovisionar recursos en una suscripción
de Azure. A las organizaciones le gustaría tener una categorización adecuada
de los recursos en términos de sus políticas de administración de la
información. Las políticas se pueden basar en la administración del ciclo de
vida de aplicaciones, como los entornos de desarrollo, prueba y producción.
Se podrían basar en el uso: parámetro interno o externo. Se podrían basar en
sus prioridades y más. Cada organización tiene su propia forma de definir las
categorías de la información y, para ellas, Azure no es diferente. Las etiquetas
ayudan a organizar los recursos de manera lógica.
• Administración de costos: el etiquetado en Azure puede ayudar a identificar
los recursos según su categorización. Se pueden ejecutar las consultas en
Azure para identificar el costo por categoría según las categorías definidas
en la administración de la información. Por ejemplo, se puede evaluar
fácilmente el costo de los recursos en Azure para el desarrollo de un entorno
para los departamentos de finanzas y marketing. Además, Azure también
proporciona información de facturación según las etiquetas. Esto ayuda a
identificar cuáles son los equipos, departamentos o grupos que consumen.
Las etiquetas tienen ciertas limitaciones en Azure.
Azure permite un máximo de 15 pares de nombre/valor de etiquetas para asociar
a recursos o grupos de recursos.

[ 206 ]
Capítulo 9

Las etiquetas no son hereditarias. Las etiquetas que se aplican a un grupo de recursos
no se aplican a los recursos individuales dentro de este. Sin embargo, es muy fácil
olvidarse de etiquetar a los recursos mientras los aprovisiona. Las políticas de
Azure son el mecanismo para garantizar que se coloquen las etiquetas con el valor
apropiado durante el tiempo de aprovisionamiento. Veremos los detalles de las
políticas más adelante en este capítulo. Se les dedica una sección completa.
Las etiquetas se pueden asignar a recursos y grupos de recursos mediante
PowerShell, Azure CLI 2.0, las plantillas de administración de recursos de Azure,
el portal de Azure y API REST del administrador de recursos de Azure.
Aquí se muestra un ejemplo de categorización de administración de la información
mediante las etiquetas de Azure que pueden reutilizarse. En este ejemplo, los pares
de nombre/valor de departamento, proyecto, entorno, propietario, aprobador,
encargado, fecha de inicio, fecha de retiro y fecha de reparación se utilizan para
etiquetar un recurso o grupo de recursos. Resulta extremadamente fácil encontrar
todos los recursos para una etiqueta determinada o una combinación de etiquetas
si se usa PowerShell, Azure CLI o API REST.

[ 207 ]
Diseñar políticas, bloqueos y etiquetas

Etiquetas con PowerShell


Las etiquetas se pueden administrar mediante PowerShell, las plantillas de Azure
Resource Manager , el portal y API REST. En esta sección, se utilizará PowerShell
para crear y aplicar etiquetas. PowerShell proporciona un cmdlet para recuperar
etiquetas y asignarlas a los recursos y grupos de recursos.
• Para recuperar etiquetas asociadas a un recurso a través de PowerShell,
se puede utilizar el cmdlet Find-AzureRMResource:
(Find-AzureRmResource -TagName Dept -TagValue Finance).Name

• Para recuperar etiquetas asociadas con un grupo de recursos a través de


PowerShell, se puede utilizar el siguiente comando:
(Find-AzureRmResourceGroup -Tag @{ Dept="Finance" }).Name

• Para asignar etiquetas a un grupo de recursos, se puede utilizar el cmdlet


Set-AzureRmResourceGroup:
Set-AzureRmResourceGroup -Name examplegroup -Tag @{ Dept="IT";
Environment="Test" }

• Para asignar etiquetas a un recurso, se puede utilizar el cmdlet Set-


AzureRmResource:

Set-AzureRmResource -Tag @{ Dept="IT"; Environment="Test" }


-ResourceName examplevnet -ResourceGroupName examplegroup

Etiquetas con la plantilla de ARM


La plantilla del administrador de recursos de Azure también brinda ayuda para
definir las etiquetas para cada recurso. Puede utilizarse para asignar varias etiquetas
a cada recurso. Esto se muestra a continuación:
{
"$schema": "https://schema.management.azure.com/
schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [
{
"apiVersion": "2016-01-01",
"type": "Microsoft.Storage/storageAccounts",
"name": "[concat('storage', uniqueString(resourceGroup().id))]",
"location": "[resourceGroup().location]",
"tags": {
"Dept": "Finance",
"Environment": "Production"
},

[ 208 ]
Capítulo 9

"sku": {
"name": "Standard_LRS"
},
"kind": "Storage",
"properties": { }
}
]
}

En el ejemplo anterior, a un par de etiquetas, Dpto. y Entorno, se les agrega un


recurso de cuenta de almacenamiento mediante las plantillas del administrador
de recursos de Azure.

Grupos de recursos frente a recursos


Resulta imprescindible que los arquitectos decidan la arquitectura de la
taxonomía e información para los recursos y grupos de recursos de Azure.
Tienen que identificar las categorías en las que se clasificarán los recursos según
los requerimientos de consulta. Sin embargo, también tienen que identificar si las
etiquetas tendrían que asignarse a recursos individuales o grupos de recursos.
Si todos los recursos dentro de un grupo necesitan las mismas etiquetas, entonces
es mejor etiquetar el grupo en lugar de etiquetar cada recurso. Es importante tener
en cuenta las consultas sobre etiquetas antes de definir si estas tienen que aplicarse
en el nivel de recursos o de grupo de recursos. Si las consultas se refieren a tipos de
recursos individuales a través de la suscripción y los grupos de recursos, entonces
tiene más sentido asignar etiquetas a los recursos. Sin embargo, si se identifican
suficientes grupos de recursos en las consultas, entonces se tienen que aplicar las
etiquetas a los grupos de recursos.

Políticas de Azure
En la última sección se trató el tema de la aplicación de etiquetas para las
implementaciones de Azure. Las etiquetas son ideales para organizar los recursos;
sin embargo, hay un factor y una pregunta más que aún no se mencionaron.
¿Cómo hacen cumplir las organizaciones que las etiquetas se apliquen para cada
implementación? Tiene que haber una aplicación automatizada de las etiquetas
de Azure a los recursos y los grupos de recursos. Azure no realiza ninguna
comprobación para asegurarse de que se aplicarán las etiquetas apropiadas a los
recursos y grupos de recursos. Ahora bien, esto no está solo relacionado con
etiquetas, podría estar relacionado con cualquier configuración de cualquier recurso
en Azure. Por ejemplo, es necesario implementar todos los recursos solo en la costa
este de los EE. UU. y no en ninguna otra parte.

[ 209 ]
Diseñar políticas, bloqueos y etiquetas

Es posible que ya haya adivinado que toda esta sección trata acerca de formular
un modelo de gobernanza en Azure. La gobernanza es un elemento importante
para Azure porque ayuda a tener la disciplina y los costos bajo control. También
garantiza que todo el que accede al entorno de Azure sea consciente de los
procesos y las prioridades de la organización. Facilita la definición de los convenios
organizacionales que ayudan a administrar los recursos.
Cada política se puede crear mediante múltiples reglas, y se pueden aplicar las
políticas a la suscripción y a los grupos de recursos. Después de que se ejecuten estas
reglas y cuando estén satisfechas, ejecuta una acción. La acción podría ser negar la
transacción en curso, auditarla, lo que significa escribir en los registros y permitir
que se complete, y agregar metadatos a la transacción si hace falta.
Los ejemplos de políticas podrían relacionarse con la convención de nomenclatura de
recursos, el etiquetado de recursos, los tipos de recursos que se pueden aprovisionar,
la ubicación de recursos o cualquier combinación de estas reglas.

Políticas integradas
Azure proporciona infraestructura para crear políticas personalizadas, sin embargo,
también proporciona algunas políticas listas para usar que a menudo se necesitan
y utilizan para la gobernanza. Estas políticas se refieren a la ubicación permitida,
los tipos de recursos permitidos y las etiquetas. Obtenga más información sobre
estas políticas integradas en https://docs.microsoft.com/en-us/azure/azure-
resource-manager/resource-manager-policy.

Lenguaje de políticas
Las políticas de Azure utilizan el lenguaje JSON para definir y describir políticas.
Hay dos pasos en la adopción de políticas. Se tienen que definir, y luego aplicarse
y asignarse. Las políticas tienen un ámbito y se pueden aplicar en el nivel de la
suscripción y del grupo de recursos.
Las políticas se definen mediante el uso de bloques if... then, que son similares
a cualquier lenguaje de programación popular. El bloque if se ejecuta para evaluar
las condiciones y, de acuerdo con el resultado de esas condiciones, se ejecuta el
bloque then:
{
"if": {
<condition> | <logical operator>
},
"then": {
"effect": "deny | audit | append"
}
}

[ 210 ]
Capítulo 9

Las políticas de Azure no solo permiten las condiciones simples if, sino que también
permiten agrupar múltiples condiciones if de manera lógica para crear reglas
complejas. Estas condiciones se pueden agrupar utilizando los operadores AND,
OR y NOT.
• La sintaxis AND requiere que todas las condiciones sean verdaderas.
• La sintaxis OR requiere que una de las condiciones sea verdadera.
• La sintaxis NOT invierte el resultado de la condición.
La sintaxis AND se muestra a continuación. Está representada por la palabra clave
allOf:
"if": {
"allOf": [
{
"field": "tags",
"containsKey": "application"
},
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
}
]
},

La sintaxis OR se muestra a continuación. Está representada por la palabra clave anyOf:


"if": {
"anyOf": [
{
"field": "tags",
"containsKey": "application"
},
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
}
]
},

La sintaxis NOT se muestra a continuación. Está representada por la palabra clave not:
"if": {
"not": [
{
"field": "tags",
"containsKey": "application"

[ 211 ]
Diseñar políticas, bloqueos y etiquetas

},
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
}
]
},

De hecho, estos operadores lógicos pueden combinarse juntos de la siguiente manera:


"if": {
"allOf": [
{
"not": {
"field": "tags",
"containsKey": "application"
}
},
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
}
]
},

Esto es muy similar a las condiciones if en lenguajes de programación populares


como C# y Node.js
If ("type" == "Microsoft.Storage/storageAccounts") {
Deny
}

Cabe destacar que no hay una acción permitir, pero sí hay una acción Negar.
Esto significa que las reglas de las políticas se tienen que escribir teniendo en cuenta
la acción de negar. Las reglas tienen que evaluar las condiciones y devolver Negar si
son verdaderas.

Campos permitidos
Los campos que se permiten en las políticas son los siguientes:
• Nombre
• Clase
• Tipo
• Ubicación

[ 212 ]
Capítulo 9

• Etiquetas
• Etiquetas.*
• Alias de propiedad

Bloqueos de Azure
Los bloqueos son un mecanismo para detener ciertas actividades de los recursos.
RBAC proporciona derechos a usuarios/grupos/aplicaciones en un determinado
ámbito. Hay roles RBAC listos para usar, como el de propietario, colaborador y
lector. Con el rol de colaborador, es posible eliminar o modificar un recurso. ¿Cómo
pueden prevenirse estos tipos de actividades a pesar de que el usuario tenga un rol
de colaborador? Aquí aparecen los bloqueos de Azure.
Los bloqueos de Azure pueden ayudar de dos maneras:
• Pueden bloquear los recursos de tal forma que no se puedan eliminar incluso
con acceso de propietario.
• Pueden bloquear los recursos de tal forma que no se puedan eliminar ni
modificar su configuración.
Esto es por lo general muy útil para los recursos en el entorno de producción donde
estos no tienen que modificarse ni eliminarse accidentalmente.
Los bloqueos se pueden aplicar en el nivel de suscripción, de grupo de recursos
y de recursos individuales. Los bloqueos utilizan el mecanismo de herencia en la
suscripción, el grupo de recursos y los recursos. Aplicar un bloqueo en el nivel
principal garantizará que aquellos en el nivel secundario lo obtengan por herencia.
Incluso los recursos que agregue más tarde heredarán el bloqueo del nivel principal.
El bloqueo más restrictivo en la herencia tiene prioridad. Aplicar un bloqueo en el
nivel de recursos tampoco permitirá eliminar un grupo de recursos que los contenga.
Los bloqueos se aplican solo a las operaciones que ayudan a administrar el recurso
y no a las operaciones que son internas a este. Los usuarios necesitan los permisos
de RBAC de Microsoft.Authorization/* o Microsoft.Authorization/locks/*
para crear y modificar los bloqueos.
Los bloqueos se pueden crear y aplicar a través del portal de Azure, Azure
PowerShell, Azure CLI, las plantillas de ARM y API REST.
Crear un bloqueo utilizando la plantilla de ARM se ve de la siguiente manera:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/
deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {

[ 213 ]
Diseñar políticas, bloqueos y etiquetas

"lockedResource": {
"type": "string"
}
}
"resources": [
{
"name": "[concat(parameters('lockedResource'), '/Microsoft.
Authorization/myLock')]",
"type": "Microsoft.Storage/storageAccounts/providers/locks",
"apiVersion": "2015-01-01",
"properties": {
"level": "CannotDelete"
}
}
]
}

Crear y aplicar un bloqueo al recurso usando PowerShell se ve de la siguiente


manera:
New-AzureRmResourceLock -LockLevel CanNotDelete -LockName LockSite `
-ResourceName examplesite -ResourceType Microsoft.Web/sites `
-ResourceGroupName exampleresourcegroup

Crear y aplicar un bloqueo al grupo de recursos usando PowerShell se ve de la


siguiente manera:
New-AzureRmResourceLock -LockName LockGroup -LockLevel CanNotDelete `
-ResourceGroupName exampleresourcegroup

Crear y aplicar un bloqueo al recurso usando Azure CLI se ve de la siguiente


manera:
az lock create --name LockSite --lock-type CanNotDelete \
--resource-group exampleresourcegroup --resource-name examplesite \
--resource-type Microsoft.Web/sites

Crear y aplicar un bloqueo al grupo de recursos usando Azure CLI se ve de la


siguiente manera:
az lock create --name LockGroup --lock-type CanNotDelete \
--resource-group exampleresourcegroup

[ 214 ]
Capítulo 9

Azure RBAC
Azure proporciona autenticación mediante el uso de Azure AD para sus recursos.
Una vez autenticado el recurso, se tiene que evaluar y decidir cuándo se le tiene que
otorgar permiso a la identidad para no acceder a ningún recurso, acceder a todos
los recursos o solo al recurso seleccionado para ese usuario. Esta actividad es
tradicionalmente conocida como autorización. La autorización evalúa si la identidad
dada tiene los permisos necesarios para acceder al recurso y si puede realizar la
operación deseada. Cualquiera que tenga acceso a una suscripción de Azure tendría
que recibir los permisos suficientes para que el trabajo se pueda realizar. No tiene
que haber más permisos que los necesarios asignados a identidades para garantizar
que la superficie de asignación se mantenga al mínimo.
La autorización también se conoce popularmente como el control de acceso basado
en roles. RBAC en Azure se refiere a la asignación de permisos a identidades
(usuarios/grupos/aplicaciones) en un ámbito. El ámbito podría ser una suscripción,
un grupo de recursos o un recurso individual.
RBAC ayuda a crear y asignar distintos permisos a diferentes identidades.
Esto ayuda a dividir las tareas dentro de los equipos en lugar de que todo el mundo
tenga todos los permisos. Ayuda a hacer responsable a la gente por su trabajo,
porque otros ni siquiera podrían tener acceso a realizarlo. Cabe destacar que dar
acceso en un ámbito más alto asegura automáticamente que los recursos secundarios
hereden esos permisos. Por ejemplo, proporcionar acceso de lectura a un grupo de
recursos garantiza que todos los recursos dentro de este tendrán los permisos de
lectura para la identidad dada.
Azure ofrece tres roles de propósitos generales integrados. Son los siguientes:
• Rol de propietario con acceso completo a todos los recursos.
• Rol de colaborador con acceso a leer y escribir recursos.
• Rol de lector únicamente con permisos de lectura de recursos.
Hay más roles que ofrece Azure, pero son específicos de los recursos. Los ejemplos
incluyen colaborador de red y administrador de seguridad.
Para obtener todos los roles que ofrece Azure para todos los recursos, ejecute el
comando Get-AzureRmRoleDefinition en la consola de PowerShell.

[ 215 ]
Diseñar políticas, bloqueos y etiquetas

Cada definición de rol tiene ciertas acciones permitidas y no permitidas. Por ejemplo,
el rol de propietario tiene todas las acciones permitidas y ninguna prohibida. Las
acciones prohibidas tienen prioridad sobre todas las acciones:
PS C:\Users\rimodi> Get-AzureRmRoleDefinition -Name "owner"

Name : Owner
Id : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
IsCustom : False
Description : Lets you manage everything, including access to
resources.
Actions : {*}
NotActions : {}
AssignableScopes : {/}

Cada rol consta de varios permisos. Cada recurso proporciona una lista de las
operaciones. La operación que respalda un recurso puede obtenerse si se usa
el cmdlet Get-AzureRmProviderOperation. Este cmdlet toma el nombre del
proveedor y del recurso para recuperar las operaciones:
Get-AzureRmProviderOperation -OperationSearchString "Microsoft.
Insights/*"

Esto dará lugar al siguiente resultado:


PS C:\Users\rimodi> get-AzureRmProviderOperation -OperationSearchString
"Microsoft.Insights/*" | select operation

Operation
---------
Microsoft.Insights/Register/Action
Microsoft.Insights/AlertRules/Write
Microsoft.Insights/AlertRules/Delete
Microsoft.Insights/AlertRules/Read
Microsoft.Insights/AlertRules/Activated/Action
Microsoft.Insights/AlertRules/Resolved/Action
Microsoft.Insights/AlertRules/Throttled/Action
Microsoft.Insights/AlertRules/Incidents/Read
Microsoft.Insights/MetricDefinitions/Read
Microsoft.Insights/eventtypes/values/Read
Microsoft.Insights/eventtypes/digestevents/Read

[ 216 ]
Capítulo 9

Microsoft.Insights/Metrics/Read
Microsoft.Insights/LogProfiles/Write
Microsoft.Insights/LogProfiles/Delete
Microsoft.Insights/LogProfiles/Read
Microsoft.Insights/Components/Write
Microsoft.Insights/Components/Delete
Microsoft.Insights/Components/Read
Microsoft.Insights/AutoscaleSettings/Write
Microsoft.Insights/AutoscaleSettings/Delete
Microsoft.Insights/AutoscaleSettings/Read
Microsoft.Insights/AutoscaleSettings/Scaleup/Action
Microsoft.Insights/AutoscaleSettings/Scaledown/Action
Microsoft.Insights/AutoscaleSettings/providers/Microsoft.Insights/
MetricDefinitions/Read
Microsoft.Insights/ActivityLogAlerts/Activated/Action
Microsoft.Insights/DiagnosticSettings/Write
Microsoft.Insights/DiagnosticSettings/Delete
Microsoft.Insights/DiagnosticSettings/Read
Microsoft.Insights/LogDefinitions/Read
Microsoft.Insights/Webtests/Write
Microsoft.Insights/Webtests/Delete
Microsoft.Insights/Webtests/Read
Microsoft.Insights/ExtendedDiagnosticSettings/Write
Microsoft.Insights/ExtendedDiagnosticSettings/Delete
Microsoft.Insights/ExtendedDiagnosticSettings/Read

Roles personalizados
Los roles se crean al combinar varios permisos. Por ejemplo, un rol personalizado
puede consistir en operaciones de múltiples recursos como se muestra a continuación:
$role = Get-AzureRmRoleDefinition "Virtual Machine Contributor"
$role.Id = $null
$role.Name = "Virtual Machine Operator"
$role.Description = "Can monitor and restart virtual machines."
$role.Actions.Clear()
$role.Actions.Add("Microsoft.Storage/*/read")

[ 217 ]
Diseñar políticas, bloqueos y etiquetas

$role.Actions.Add("Microsoft.Network/*/read")
$role.Actions.Add("Microsoft.Compute/*/read")
$role.Actions.Add("Microsoft.Compute/virtualMachines/start/action")
$role.Actions.Add("Microsoft.Compute/virtualMachines/restart/action")
$role.Actions.Add("Microsoft.Authorization/*/read")
$role.Actions.Add("Microsoft.Resources/subscriptions/resourceGroups/
read")
$role.Actions.Add("Microsoft.Insights/alertRules/*")
$role.Actions.Add("Microsoft.Support/*")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/c276fc76-9cd4-44c9-99a7-
4fd71546436e")
$role.AssignableScopes.Add("/subscriptions/e91d47c4-76f3-4271-a796-
21b4ecfe3624")
New-AzureRmRoleDefinition -Role $role

¿En qué difiere de RBAC?


Los bloqueos no son lo mismo que RBAC. RBAC ayuda a permitir o denegar
permisos sobre los recursos que son intrínsecos a estos. Estos permisos se refieren
a realizar operaciones tales como leer, escribir y actualizar recursos. Los bloqueos,
en cambio, se refieren a invalidar permisos para configurar o eliminar el recurso.

Ejemplos de la implementación de
características de gobernanza de Azure
En esta sección, veremos una implementación de arquitectura de muestra para
una organización ficticia que quiere implementar la gobernanza de Azure y las
características de administración de costos.

Antecedentes
Company Inc es una empresa mundial que está implementando una solución
de redes sociales en Azure IaaS. Utiliza servidores web y de aplicaciones
implementados en las máquinas virtuales y redes de Azure. El servidor de Azure
SQL actúa como base de datos de backend.

[ 218 ]
Capítulo 9

Control de acceso basado en roles


La primera tarea es garantizar que los equipos apropiados y los dueños de la
aplicación puedan acceder a sus recursos. Se reconoce que cada equipo tiene
requerimientos diferentes. En aras de la comprensión, se implementa Azure SQL
en un grupo de recursos independiente en comparación con los artefactos de IaaS
de Azure.
El administrador asigna las siguientes funciones para la suscripción:

Papel Asignado a Descripción


Administra todos los grupos
Propietario El administrador
de recursos y la suscripción.
Esta función permite a los usuarios
Administrador de Administradores
ver el centro de seguridad de Azure
seguridad de seguridad
y el estado de los recursos.
Administración Administra máquinas virtuales
Colaborador
de infraestructura y otros recursos.
Puede ver los recursos, pero no los
puede modificar. Se espera que
Lector Desarrolladores
los desarrolladores trabajen en sus
entornos de desarrollo y pruebas.

Resumen
La administración de gobernanza y costos es una de las principales prioridades para
las empresas que se trasladan a la nube. Tener una suscripción de Azure con pago
por uso puede dañar el presupuesto de la empresa porque cualquiera que tenga
acceso a la suscripción puede aprovisionar tantos recursos como desee. Algunos
recursos son gratuitos mientras que otros son costosos. Es importante para las
organizaciones mantener el control sobre los costos de la nube. Las etiquetas ayudan
a generar informes de facturación. Estos informes se podrían basar en proyectos,
departamentos, dueños o cualquier otro criterio que considere adecuado. Si bien el
costo es importante, la gobernanza lo es en igual medida. Azure ofrece bloqueos,
políticas y RBAC para formular la gobernanza. Las políticas garantizan que las
operaciones de recursos puedan ser negadas o auditadas, los bloqueos aseguran
que los recursos no puedan ser modificados o eliminados, y RBAC asegura que los
empleados tengan los permisos óptimos para realizar el trabajo. Con estas cuatro
características, las empresas pueden tener una gobernanza sólida y control de costos
en las implementaciones de Azure.
DevOps en Azure será el foco en el próximo capítulo, en el que veremos algunos de
sus conceptos importantes y técnicas de implementación.

[ 219 ]
DevOps en Azure
El desarrollo de software es un proyecto complejo que consta de múltiples procesos,
herramientas y personas de diferentes departamentos. Todos tienen que unirse
y trabajar de manera conjunta. Debido a la existencia de tantas variables, los riesgos
son altos mientras se provee a los clientes finales. Una pequeña omisión o error de
configuración y la aplicación puede colapsar. En este capítulo se tratan la adopción
e implementación de prácticas que reducen este riesgo de manera considerable
y aseguran que el software de alta calidad pueda entregarse al cliente en forma
reiterada.
Antes de analizar DevOps de manera más detallada, entendamos los problemas que
enfrentan las compañías de software de las que se ocupa DevOps.
• Las organizaciones son rígidas y no aceptan cambios.
• Los procesos son rígidos y lentos.
• Los equipos están aislados y trabajan en silos.
• El diseño es monolítico y las implementaciones tienen un gran impacto
• La ejecución es manual.
• Hay una falta de innovación.
En este capítulo, analizaremos lo siguiente en detalle:
• DevOps
• Prácticas de DevOps
• Administración de configuración
• Integración continua
• Implementación continua
• Entrega continua
• Visual Studio Team Services

[ 221 ]
DevOps en Azure

• Preparación de DevOps
• DevOps para solución PaaS
• DevOps para soluciones basadas en máquinas virtuales (IaaS)
• DevOps para soluciones basadas en contenedor (IaaS)
• Azure Automation
• Herramientas de Azure para DevOps

¿Qué es DevOps?
En la actualidad, no existe consenso en la industria con respecto a la definición de
DevOps. Cada organización formuló su propia definición de DevOps e intentó
implementarla. Tienen su propia perspectiva y creen que implementaron DevOps
si cuentan con automatización y tienen activada la administración de configuración
mediante procesos ágiles o cualquier otra combinación.
DevOps se trata del mecanismo de entrega de sistemas de software. Se refiere a reunir
personas, hacer posible que colaboren y se comuniquen, trabajar en forma conjunta
hacia una meta y una visión en común. Tiene que ver con asumir una responsabilidad
y propiedad entre todos. Está relacionado con la implementación de procesos que
fomentan la colaboración y una actitud de servicio. Permite mecanismos de entrega
que aportan agilidad y flexibilidad dentro de la organización. Contrariamente a la
creencia popular, DevOps no se trata de herramientas, tecnología y automatización.
Estos son facilitadores que ayudan en la colaboración, la implementación de procesos
ágiles y la entrega más rápida y mejor al cliente.
En Internet, podemos encontrar varias definiciones de DevOps, y ninguna es
imprecisa ni incorrecta. DevOps no proporciona un marco ni una metodología.
Es un conjunto de principios y prácticas que, cuando se utilizan en una organización,
compromiso o proyecto, logra el objetivo y la visión para DevOps y la organización.
Estos principios y prácticas no exigen ningún proceso, herramienta, tecnología ni
entorno específico. DevOps proporciona la orientación que puede implementarse
mediante cualquier herramienta, tecnología y proceso, aunque algunos procesos
y tecnologías podrían ser más aptos para alcanzar la visión de los principios y las
prácticas de DevOps.
Aunque las prácticas de DevOps pueden aplicarse en cualquier organización
que proporciona productos y servicios a los clientes, más adelante en este
libro, analizaremos DevOps desde la perspectiva de desarrollo de software
y el departamento de operaciones de cualquier organización.

[ 222 ]
Capítulo 10

Entonces, ¿qué es DevOps? DevOps se define de la siguiente manera:


Es un conjunto de principios y prácticas que reúne a equipos de operaciones
y desarrolladores desde el inicio del sistema de software para una entrega completa
más rápida, acelerada y eficiente del sistema de software al cliente final, en forma
repetitiva y de una manera coherente y predecible que reduce el tiempo de
comercialización y, de esa manera, se obtiene una ventaja competitiva.
Lea en voz alta la definición anterior de DevOps y, si presta atención, observará
que no indica ni hace referencia a procesos, herramientas ni tecnología específicos.
No prescribe ninguna metodología ni entorno en particular.
El objetivo de implementar los principios y las prácticas de DevOps en cualquier
organización es asegurar el cumplimiento de las demandas y las expectativas de las
partes interesadas (que incluye a clientes) de manera eficiente y eficaz.
Las demandas y las expectativas del cliente se cumplen cuando sucede lo siguiente:
• El cliente obtiene las funciones que desea.
• El cliente obtiene las funciones cuando lo desea.
• El cliente obtiene actualizaciones más rápidas de las funciones.
• La calidad de la entrega es alta.
Si una organización puede satisfacer las expectativas antes mencionadas, los clientes
están conformes y demuestran lealtad con la organización. Esto, a su vez, aumenta
la competitividad de la organización en el mercado, que se traduce en una mayor
valoración de la marca y del mercado. Tiene un impacto directo en los ingresos y los
resultados de la organización. La organización puede invertir más en innovación y en
los comentarios de los clientes, lo que provoca cambios continuos en el sistema y los
servicios para mantener la relevancia.
La implementación de los principios y las prácticas de DevOps en cualquier
organización está guiada por su ecosistema circundante. Este ecosistema está
compuesto por la industria y los dominios a los que pertenece la organización.
DevOps se basa en un conjunto de principios y prácticas. Más adelante en este
capítulo, analizaremos en detalle estos principios y prácticas. Los principios básicos
de DevOps son los siguientes:
• Agilidad
• Automatización
• Colaboración
• Comentarios

[ 223 ]
DevOps en Azure

Las prácticas básicas de DevOps son las siguientes:


• Integración continua
• Administración de configuración
• Implementación continua
• Entrega continua
• Aprendizaje continuo
DevOps no es un nuevo paradigma, pero en los últimos tiempos, ganó mucha
popularidad y confianza. Su adopción está en su nivel más alto y cada vez más
empresas se suman a este recorrido. Mencioné intencionalmente que DevOps es como
un recorrido porque hay diferentes niveles de madurez dentro de DevOps. Si bien la
aplicación con éxito de la implementación y la entrega continuas se considera como el
nivel más alto de madurez en este recorrido, la adopción del control del código fuente
y el desarrollo ágil de software se considera como el comienzo.
Uno de los primeros aspectos a los que hace referencia DevOps es derribar los
obstáculos entre los desarrolladores y el equipo de operaciones. Plantea la cuestión de la
colaboración estrecha entre varios equipos. Se refiere a abandonar la mentalidad
de que el desarrollador es responsable solo de escribir el código y pasarlo al
departamento de operaciones para que se implemente una vez que se haya probado.
También se trata de dejar de creer que el departamento de operaciones no cumple
ninguna función en las actividades de desarrollo. El departamento de operaciones
tendría que tener influencia en la planificación del producto y conocer las funciones
que se lanzan como versión. Además, tendría que proporcionar comentarios en forma
continua a los desarrolladores sobre cuestiones operativas que puedan resolverse en
las versiones posteriores. Tendría que influir en el diseño del sistema para un mejor
funcionamiento operativo del sistema. Del mismo modo, los desarrolladores tienen
que ayudar a las operaciones de implementación del sistema y resolver incidentes
cuando se presenten.
La definición habla de una entrega completa más rápida, acelerada y eficiente de los sistemas
a las partes interesadas. No menciona qué nivel de rapidez, aceleración ni eficiencia
tendría que tener la entrega. Tendría que ser lo suficientemente rápida o acelerada,
según el dominio, la industria, la segmentación de clientes y otros aspectos propios
de la organización. Para algunas organizaciones, lo suficientemente rápida puede ser
trimestral, mientras que para otras podría ser semanal. Ambos tipos son válidos para
el punto de vista de DevOps y pueden implementar procesos y tecnologías relevantes
para lograr lo mismo. DevOps no obliga a nada. Las organizaciones tienen que
identificar la mejor implementación de los principios y las prácticas de DevOps según
su visión general del proyecto, la participación y la organización.

[ 224 ]
Capítulo 10

La definición también se refiere a una entrega completa. Eso significa que desde la
planificación y la entrega del sistema hasta los servicios y las operaciones tienen que
ser parte de la implementación de DevOps. Los procesos tienen que ser aquellos
que permitan una mayor flexibilidad, modularidad y agilidad en el ciclo de vida de
desarrollo de aplicaciones. Si bien las organizaciones tiene libertad para usar el mejor
proceso de adaptación, como Waterfall, Agile, Kanban, etc., por lo general, tienden
a fomentar los procesos ágiles con entrega basada en iteraciones. Esto permite una
entrega más rápida en unidades más pequeñas con una capacidad mayor de prueba
y administración en comparación con la entrega grande.
DevOps se refiere a los clientes finales en forma reiterada y de manera coherente y predecible.
Esto significa que las organizaciones tienen que entregar a los clientes en forma
continua funciones más nuevas y mejoradas mediante el uso de la automatización.
No podemos lograr coherencia y previsibilidad sin el uso de la automatización.
El trabajo manual tiene que reducirse al mínimo para asegurar un alto nivel de
coherencia y la previsibilidad. Además, la automatización tiene que ser integral para
evitar fallas. Esto también indica que el diseño del sistema tiene que ser modular
para permitir una entrega más rápida, ya que es confiable, tiene disponibilidad y es
escalable. Las pruebas cumplen una función muy importante en la entrega coherente
y predecible.
El resultado final de la aplicación de los principios y las prácticas antes mencionados
es que la organización es capaz de satisfacer las expectativas y demandas de los
clientes. La organización puede crecer más rápido que la competencia y aumentar aún
más la calidad y la capacidad de sus productos y servicios mediante la innovación y la
mejora continuas.

Prácticas de DevOps
DevOps consiste en varias prácticas, y cada una proporciona una funcionalidad
distinta al proceso general. La siguiente figura muestra la relación entre ellas.
La administración de configuración y la integración e implementación continuas
conforman las prácticas centrales que hacen posible DevOps. Cuando entregamos
servicios de software que combinan estos tres servicios, logramos una entrega
continua. La entrega continua es una capacidad y refleja la madurez de una
organización en cuanto a la administración de configuración y la integración
e implementación continuas. Los comentarios ininterrumpidos en todas las etapas
forman el circuito de comentarios que ayudan en la prestación de servicios de calidad
superior a los clientes. Se aplica a todas las prácticas de DevOps.

[ 225 ]
DevOps en Azure

Analicemos con más profundidad cada una de estas capacidades y las prácticas de
DevOps:

Administración de configuración
Las aplicaciones y los servicios empresariales necesitan un entorno en el que puedan
implementarse. Por lo general, el entorno es una infraestructura que comprende
múltiples servidores y servicios informáticos, de red, almacenamiento, contenedores
y muchos otros más que trabajan en forma conjunta para que las aplicaciones
puedan implementarse encima de ellos. Las aplicaciones empresariales se dividen en
múltiples servicios que se ejecutan en varios servidores, ya sea en las instalaciones
o en las nubes, y cada servicio tiene su propia configuración junto con requisitos
relacionados con la configuración de la infraestructura. En definitiva, se necesita
infraestructura y aplicación para proporcionar sistemas a los clientes, y ambas tienen
su propia configuración. Si hubiera alguna desviación de la configuración, es probable
que la aplicación no funcione como se esperaba y se generen tiempos de inactividad
y fallas. Por otra parte, ya que el proceso de ALM exige el uso de múltiples etapas
y entornos, una aplicación puede implementarse en varios entornos con diferentes
configuraciones. La aplicación se implementará en el entorno de desarrollo para que
los desarrolladores vean el resultado de su trabajo. Además, se instalará en múltiples
entornos de pruebas con diferentes configuraciones para pruebas funcionales, de
carga y estrés, rendimiento, integración, etc.; también se implementará en el entorno
de preproducción para llevar a cabo pruebas de aceptación del usuario y, finalmente,
en el entorno de producción. Es importante que una aplicación pueda implementarse
en varios entornos sin que sea necesario incorporar cambios manuales en su
configuración.

[ 226 ]
Capítulo 10

La administración de configuración proporciona un conjunto de procesos


y herramientas que ayudan a garantizar que cada entorno y aplicación obtenga su
propia configuración. La administración de configuración realiza un seguimiento
de los elementos de configuración, y cualquier cosa que cambie de un entorno
a otro tiene que tratarse como un elemento de configuración. La administración de
configuración define también las relaciones entre los elementos de configuración
y qué impacto tendrán los cambios en un elemento de configuración en el otro
elemento de configuración.
La administración de configuración ayuda en lo siguiente:
• Infraestructura como código: cuando el proceso de provisión de
infraestructura y su configuración está representado mediante un código
y el mismo código pasa por el proceso de ciclo de vida de la aplicación,
se conoce con el nombre de infraestructura como código. La infraestructura
como código ayuda en la automatización de la provisión y configuración
de infraestructura. Además, representa toda la infraestructura en un código
que puede almacenarse en un repositorio y controlarse con la versión. Esto
permite a los usuarios utilizar las configuraciones de entorno anteriores
cuando sea necesario. Además, hace posible la provisión de un entorno varias
veces de una manera coherente y predecible. Todos los entornos provistos de
esta manera son coherentes e iguales en todas las etapas de ALM.
• Implementación y configuración de la aplicación: la implementación de una
aplicación y su configuración es el siguiente paso después de la provisión
de infraestructura. Algunos ejemplos de implementación y configuración
de aplicaciones son implementar un paquete webdeploy en un servidor,
implementar esquemas y datos (bacpac) de un servidor SQL en otro servidor,
cambiar la cadena de conexión de SQL en el servidor web para representar
el servidor SQL apropiado. La administración de configuración almacena
valores para la configuración de la aplicación de cada entorno en el que se
implementa.
Además, tendría que controlarse la configuración aplicada. La configuración esperada
y deseada necesita un mantenimiento constante. Cualquier desviación respecto de
esta configuración esperada y deseada haría que la aplicación no esté disponible.
La administración de configuración también es capaz de encontrar la desviación
y volver a configurar la aplicación y el entorno a su estado deseado.
Gracias a la administración de configuración automatizada, nadie en el equipo tiene
que implementar ni configurar entornos y aplicaciones en producción. El equipo
de operaciones no depende del equipo de desarrollo ni de la documentación de
implementaciones prolongadas.

[ 227 ]
DevOps en Azure

Otro aspecto de la administración de configuración es el control de código fuente.


Los servicios y las aplicaciones empresariales comprenden el código y otros artefactos.
Varios miembros del equipo trabajan en los mismos archivos. El código fuente tiene
que estar actualizado en todo momento, y solo los miembros del equipo autenticados
pueden tener acceso. El código y otros artefactos por sí mismos son elementos de
configuración. El control del código fuente ayuda en la colaboración y comunicación
dentro del equipo, ya que todo el mundo sabe qué está haciendo la otra persona y los
conflictos se resuelven en una etapa inicial.
La administración de configuración puede dividirse ampliamente en dos categorías:
• Dentro de la máquina virtual
• Fuera de la máquina virtual
A continuación, se analizan las herramientas disponibles para la administración de
configuración dentro de la máquina virtual.

Configuración de estado deseada


La configuración de estado deseada (DSC) es una nueva plataforma de
administración de configuración a partir de una compilación de Microsoft como una
extensión de PowerShell. La DSC fue lanzada originalmente como parte de WMF 4.0.
Está disponible como parte de Windows Management Framework (WMF) 4.0 y
5.0 para todos los sistemas operativos de servidor Windows anteriores a Windows
2008 R2. WMF 5.1 está disponible para su uso inmediato en Windows Server 2016 y
Windows 10.

Chef, Puppet y Ansible


Además de DSC, hay una gran cantidad de herramientas de administración de
configuración , como Chef, Puppet y Ansible, que son compatibles con Azure. En este
libro no se analizan detalles sobre estas herramientas.
Las herramientas disponibles para la administración de configuración fuera de la
máquina virtual son las siguientes:

Plantillas de Azure Resource Manager


Las plantillas de ARM son los medios principales de aprovisionamiento de recursos
en ARM. Brindan un modelo declarativo mediante el cual se especifican los recursos,
su configuración, los scripts y las extensiones. Las plantillas de ARM se basan en el
formato JavaScript Object Notation (JSON). Utilizan la sintaxis y convenciones JSON
para declarar y configurar recursos. Los archivos JSON están basados en texto, son
intuitivos y fáciles de leer. Se pueden guardar en un repositorio de código fuente y
cuentan con control de versiones. Además, constituyen un medio para representar la
infraestructura como código que se puede utilizar para suministrar recursos en grupos
de recursos de Azure una y otra vez, de manera previsible, coherente y uniforme.
[ 228 ]
Capítulo 10

Una plantilla necesita un grupo de recursos para la implementación. Solo se puede


implementar en un grupo de recursos, el cual tiene que existir antes de ejecutar la
implementación de la plantilla. Una plantilla no puede crear un grupo de recursos.
Las plantillas brindan la flexibilidad de diseño e implementación genéricos
y modulares. Brindan la capacidad de aceptar parámetros de los usuarios, declarar
variables internas, ayudar a definir dependencias entre recursos, vincular recursos
dentro del mismo grupo o de distintos grupos y también ejecutar otras plantillas.
Además, brindan expresiones del tipo de lenguaje de scripting y funciones que las
hacen dinámicas y personalizables en el momento de ejecución.

Integración continua
Varios desarrolladores escriben el código que finalmente se almacena en un
repositorio común. Por lo general, el código se comprueba o inserta en el repositorio
cuando el desarrollador terminó de desarrollar su función. Esto puede suceder en un
día o puede demorar días o semanas. Algunos desarrolladores podrían trabajar en la
misma función y seguir las mismas prácticas de inserción y comprobación de código
en días o semanas. Esto puede causar problemas en la calidad del código. Uno de los
principios de DevOps es fallar rápido. Los desarrolladores tendrían que comprobar
o insertar su código en el repositorio a menudo y compilarlo para comprobar que no
haya introducido algún error y que sea compatible con el código escrito por su colega.
Si el desarrollador no sigue esta práctica, el código en su máquina crecerá hasta ser
muy grande y será difícil de integrar con otro código. Por otra parte, si la compilación
falla, será difícil y lento solucionar los problemas que surjan a partir de esta situación.
La integración continua soluciona estos tipos de complicaciones. Ayuda en la
compilación y validación del código insertado o comprobado por un desarrollador
mediante un recorrido por una serie de pasos de validación. Crea un flujo de proceso
que consta de varios pasos. Se compone de compilación automatizada y pruebas
automatizadas continuas. Normalmente, el primer paso es la compilación del código.
Después de la compilación exitosa, cada paso es responsable de validar el código
desde una perspectiva específica. Por ejemplo, pueden ejecutarse pruebas unitarias
en el código compilado y la cobertura de código puede ejecutarse para comprobar
qué rutas de código ejecutan las pruebas unitarias. Estos podrían revelar si se escriben
pruebas unitarias completas o si hay posibilidades de agregar otras pruebas unitarias.
El resultado final de la integración continua son paquetes de implementación
que pueden ser utilizados por la implementación continua para instalarlos en
varios entornos.

[ 229 ]
DevOps en Azure

Alentamos a los desarrolladores a comprobar su código varias veces en un día en


lugar de hacerlo después de días o semanas. La integración continua iniciará la
ejecución de todo el proceso de inmediato, ni bien el código se compruebe o inserte.
Si la compilación se realiza sin problemas, las pruebas de código y otras actividades
que forman parte del proceso se ejecutan sin errores, el código se implementa en un
entorno de prueba y las pruebas de integración se ejecutan en dicho entorno. Aunque
cada sistema requiere su propia configuración de integración continua, en la siguiente
figura se muestra una integración continua de ejemplo.
La integración continua aumenta la productividad de los desarrolladores. No tienen
que compilar manualmente su código, ejecutar varios tipos de pruebas en forma
consecutiva y, a continuación, crear paquetes a partir de eso. También reduce el
riesgo de que se introduzcan errores en el código y que el código se vuelva obsoleto.
Proporciona comentarios anticipados a los desarrolladores sobre la calidad de su
código. En general, la calidad de los productos es alta y los resultados se entregan más
rápido mediante la adopción de la práctica de integración continua:

Automatización de la compilación
La automatización de la compilación se compone de múltiples tareas en secuencia.
Por lo general, la primera tarea es responsable de traer el último código fuente desde
el repositorio. El código fuente podría comprender múltiples proyectos y archivos.
Se compilan para generar artefactos, como archivos ejecutables, bibliotecas de
vínculos dinámicos, ensamblados, etc. La automatización de la compilación exitosa
refleja que no hay errores de tiempo de compilación en el código.
Podría haber más pasos en la automatización de la compilación, según sea la
naturaleza y el tipo de proyecto.

[ 230 ]
Capítulo 10

Automatización de pruebas
La automatización de pruebas consiste en las tareas que se encargan de validar
distintos aspectos del código. Estas tareas están relacionadas con pruebas de código
desde otra perspectiva y se ejecutan en secuencia. En general, el primer paso es
ejecutar una serie de pruebas unitarias en el código. Las pruebas unitarias se refieren
al proceso de pruebas de la denominación más pequeña de una función que valida su
comportamiento en forma aislada de otras funciones. Puede automatizarse o realizarse
en forma manual, pero la preferencia se inclina por las pruebas unitarias automatizadas.
La cobertura de código es otro tipo de prueba automatizada que puede ejecutarse en
el código para saber la cantidad de código que se ejecuta durante la ejecución de las
pruebas unitarias. Generalmente, se representa como un porcentaje y se refiere a la
cantidad de código que se comprueba con las pruebas unitarias. Si la cobertura de
código no es cercana al 100 %, puede ser porque el desarrollador no escribió pruebas
unitarias para ese comportamiento o el código no cubierto no es para nada necesario.
La ejecución exitosa de la automatización de pruebas de la que no se obtiene una falla
de código significativa tiene que comenzar a ejecutarse en las tareas de embalaje. Podría
haber más pasos en la automatización de pruebas, según sea la naturaleza y el tipo de
proyecto.

Embalaje
El embalaje se refiere al proceso de generar artefactos que se pueden implementar,
como los paquetes de MSI, NuGet y webdeploy, paquetes de base de datos, versiones
de dichos paquetes y su almacenamiento en un lugar que les permite ser usados por
otros procesos y procedimientos.

Implementación continua
Cuando el proceso alcanza la implementación continua, la integración continua
garantiza que tenemos bits en pleno funcionamiento de una aplicación que
ahora pueden llevarse a diferentes actividades de implementación continua.
La implementación continua se refiere a la capacidad de implementar servicios y
aplicaciones empresariales en entornos de preproducción y producción mediante
la automatización. Por ejemplo, la implementación continua podría aprovisionar y
configurar el entorno de preproducción, implementar la aplicación en el entorno y
configurarlo. Después de realizar varias validaciones, como pruebas funcionales y
pruebas de funcionamiento en el entorno de preproducción, se aprovisiona y configura
el entorno de producción, y la aplicación se implementa en entornos de producción
mediante la automatización. No hay pasos manuales en el proceso de implementación.
Cada tarea de implementación está automatizada. La implementación continua puede
aprovisionar al entorno e instalar la aplicación para una implementación sin sistema
operativo y podría reutilizar el entorno existente y llevar a cabo solo la implementación
de la aplicación si ya existe el entorno. Siempre es mejor realizar implementaciones
totalmente nuevas sin sistema operativo, pero la justificación empresarial puede
generar la demanda de implementaciones preexistentes.
[ 231 ]
DevOps en Azure

Todos los entornos se aprovisionan mediante automatización con la infraestructura


como código. Esto asegura que todos los entornos, ya sean de desarrollo, pruebas,
preproducción, producción y de cualquier otro tipo, sean lo mismo. En ese sentido,
la aplicación se implementa mediante automatización, y eso garantiza que sea
uniforme en todos los entornos. La configuración en estos entornos podría ser
diferente para la aplicación.
En general, la implementación continua se asimila con la integración continua. Luego
de que la integración continua haya completado su trabajo mediante la generación
de paquetes finales que pueden implementarse, comienza su tarea e inicia su propio
proceso. Este proceso se denomina canalización de versiones. Una canalización
de versiones consiste en múltiples entornos, y cada entorno está compuesto por
tareas responsables de aprovisionar al entorno, la configuración del entorno, la
implementación de aplicaciones, la configuración de aplicaciones, la ejecución de
la validación operativa en los entornos y las pruebas de la aplicación en múltiples
entornos. En el próximo capítulo, analizaremos la canalización de versiones de
manera más exhaustiva, y también en el capítulo sobre implementación continua.
La utilización de la implementación continua proporciona beneficios enormes.
Hay un alto nivel de confianza en el proceso general de implementación que ayuda
en las versiones más rápidas y sin riesgos en la producción. Las posibilidades de
complicaciones descienden drásticamente. El equipo tendrá niveles más bajos de
estrés, y es posible restaurar el entorno de trabajo anterior si hay problemas en la
versión actual:

Aunque cada sistema requiere su propia configuración de canalización de versiones,


la imagen anterior muestra un ejemplo mínimo de implementación continua.
Es importante tener en cuenta que, por lo general, el aprovisionamiento y la
configuración de múltiples entornos forman parte de la canalización de versiones,
y es necesario obtener aprobaciones antes de pasar el siguiente entorno. El proceso de
aprobación puede ser manual o automático, según la madurez de la organización.

[ 232 ]
Capítulo 10

Implementación del entorno de prueba


La canalización de versiones comienza una vez que está disponible la entrega de la
integración continua, y el primer paso que se tiene que realizar es conseguir todos
los artefactos de la entrega. Después de eso, puede crear un entorno de prueba sin
sistema operativo y completamente nuevo o reutilizar uno existente. De nuevo,
esto depende del tipo de proyecto y la naturaleza de las pruebas previstas que se
ejecutarán en este entorno. El entorno se aprovisiona y configura. Los artefactos de la
aplicación se implementan y configuran.

Automatización de pruebas
Después de implementar una aplicación, puede realizarse una serie de pruebas en
el entorno. Una de las pruebas que se ejecutan aquí son las pruebas funcionales.
Las pruebas funcionales tienen como objetivo principal validar la característica
de integridad y funcionalidad de la aplicación. Estas pruebas se escriben a partir
de requerimientos recopilados del cliente. Otro conjunto de pruebas que pueden
ejecutarse está relacionado con la escalabilidad y la disponibilidad de la aplicación.
Normalmente, esto incluye pruebas de carga, estrés y rendimiento. También tendría
que incluir la validación operativa del entorno de infraestructura.

Implementación del entorno de almacenamiento


provisional
Esto es muy similar a la implementación del entorno de prueba, aunque la única
diferencia es que los valores de configuración para el entorno y la aplicación serían
distintos.

Pruebas de aceptación
En general, las pruebas de aceptación son realizadas por las partes interesadas en la
aplicación, y esto puede hacerse en forma manual o automatizada. Este paso es una
validación desde el punto de vista del cliente sobre la exactitud e integridad de la
funcionalidad de la aplicación.

Implementación para producción


Una vez que el cliente proporciona su aprobación, se ejecutan los mismos pasos que
en la implementación del entorno de prueba y ensayo , con la única diferencia de que
los valores de configuración para el entorno y la aplicación son específicos para el
entorno de producción. Después de la implementación se lleva a cabo una validación
para asegurar que la aplicación se ejecute según lo esperado.

[ 233 ]
DevOps en Azure

Entrega continua
Es probable que para muchos lectores, la entrega y la implementación continua
parezcan lo mismo, pero no lo son. Si bien la implementación continua se refiere
a la implementación en varios entornos y, por último, en el entorno de producción
mediante la automatización, las prácticas de entrega continua están relacionadas con
la capacidad de generar paquetes de aplicación de manera que puedan implementarse
fácilmente en cualquier entorno. Para la generación de artefactos que pueden
implementarse de inmediato, es necesario usar la integración continua para generar
artefactos de aplicación y es necesario contar con un entorno nuevo o ya existente
para la implementación de estos artefactos, la realización de pruebas funcionales,
de rendimiento y aceptación de usuario mediante automatización. Una vez que estas
actividades se ejecutaron correctamente y sin errores, el paquete de aplicación se
considera como de implementación inmediata. La entrega continua comprende la
integración continua junto con la implementación en un entorno para la validación
final. Ayuda a recibir comentarios más rápido tanto del departamento de operaciones
como del usuario final. Estos comentarios pueden usarse después para implementar
iteraciones posteriores.

Aprendizaje continuo
Ya que se mencionaron todas las prácticas de DevOps, ahora sabemos que es posible
crear aplicaciones excelentes e implementarlas de manera automática en el entorno
de producción; sin embargo, los beneficios de DevOps no duran mucho tiempo, si
no se cuenta con los principios de mejora continua y comentarios. Es sumamente
importante que se transmitan en tiempo real los comentarios sobre el comportamiento
de la aplicación al equipo de desarrollo, tanto de los usuarios finales como del equipo
de operaciones.
Los comentarios tienen que transmitirse a los equipos con información relevante
acerca de los aspectos positivos y, lo más importante, de aquello que no funciona bien.
Las aplicaciones tendrían que desarrollarse teniendo en cuenta el control, la auditoría
y la telemetría. La arquitectura y el diseño tienen que respaldar estos aspectos.
El equipo de operaciones tiene que recopilar la información de telemetría del entorno
de producción, registrar cualquier problema y error, y comunicarlos al equipo de
desarrollo para que puedan resolverlos en las próximas versiones. En la siguiente
figura se muestra lo mismo.

[ 234 ]
Capítulo 10

El aprendizaje continuo ayuda a que la aplicación sea más sólida y resistente


a las fallas. Ayuda a garantizar que la aplicación cumpla con los requisitos de los
consumidores:

Visual Studio Team Services


Ahora, es momento de centrarse en otro servicio en línea revolucionario, Visual
Studio Team Services (VSTS), que permite la integración, la implementación y la
entrega continuas sin problemas. De hecho, sería más apropiado llamarlo un conjunto
de servicios disponibles con un solo nombre. VSTS es una PaaS proporcionada por
Microsoft y que está alojada en la nube. El mismo servicio está disponible como
Team Foundation Services (TFS) a nivel local. Todos los ejemplos que se usan en este
libro utilizan VSTS.
Según Microsoft, VSTS es una plataforma de colaboración en la nube que ayuda a los
equipos a compartir códigos, realizar el seguimiento del trabajo y enviar software.
VSTS es el nuevo nombre; antes se conocía como visual studio online (VSO).
VSTS es un servicio y una herramienta de desarrollo de software empresarial que
permite a las organizaciones proporcionar servicios de automatización a su proceso
completo de administración de ciclo de vida de la aplicación, desde la planificación
hasta la implementación de la aplicación, y recibir comentarios en tiempo real de los
sistemas de software. Esto aumenta la madurez y la capacidad de una organización
de ofrecer en forma reiterada sistemas de software de alta calidad a sus clientes.

[ 235 ]
DevOps en Azure

La entrega exitosa de software implica reunir numerosos procesos y actividades de


manera eficiente. Estos incluyen la ejecución e implementación de varios procesos
ágiles, el aumento de la colaboración entre equipos, la transición automática
y constante de artefactos de una fase de la ALM a otra fase y las implementaciones
para múltiples entornos. Es importante realizar el seguimiento de estas actividades
e informarlas para evaluar y adoptar las medidas necesarias a fin de mejorar los
procesos de entrega. VSTS permite que sea simple y fácil. Proporciona un conjunto
completo de servicios que hacen posible lo siguiente:
• La colaboración entre cada miembro del equipo mediante la provisión de
una interfaz única para la administración completa del ciclo de vida de la
aplicación.
• La colaboración entre los equipos de desarrollo mediante el uso de servicios
de administración de código fuente
• La colaboración entre los equipos de prueba por medio de servicios de
administración de pruebas
• La validación de la automatización del código y el embalaje mediante la
integración continua con el uso de servicios de administración de compilación
• La validación de la automatización de la funcionalidad de la aplicación,
la implementación y configuración de múltiples entornos mediante la entrega
y la implementación continua con servicios de administración de versión
• El seguimiento y la administración de elementos de trabajo con servicios de
administración
La siguiente figura muestra todos los servicios disponibles en la barra de navegación
superior de VSTS:

Un proyecto de VSTS es un límite de seguridad y contenedor lógico que proporciona


todos los servicios que mencionamos en la sección anterior. VSTS permite la creación
de múltiples proyectos en una sola cuenta. De forma predeterminada, se crea un
repositorio con la creación de un proyecto; sin embargo, VSTS permite la creación de
otros repositorios dentro de un proyecto individual. En la siguiente figura se muestra
la relación entre el proyecto y el repositorio y la cuenta de VSTS:

[ 236 ]
Capítulo 10

Relación entre proyectos, repositorios y la cuenta de VSTS


VSTS ofrece dos tipos de repositorios:
• GIT
• Team Foundation Version Control (TFVC)
También proporciona la flexibilidad de elegir entre los repositorios de control de
código fuente GIT o TFVC. Puede haber una combinación de repositorios TFS y TFVC
disponible dentro de un proyecto individual.

Team Foundation Version Control


TFVC es la manera tradicional y centralizada de implementar el control de versiones
en que hay un repositorio central y los desarrolladores trabajan de manera directa en
dicho repositorio y en modo conectado para registrar sus cambios. Si el repositorio
central no tiene conexión o no está disponible, los desarrolladores no pueden registrar
su código y tienen que esperar a que esté en línea y disponible. Otros desarrolladores
pueden ver solo el código registrado. Los desarrolladores pueden agrupar múltiples
cambios en un único conjunto de cambios para registrar los cambios de código que
se agrupan de manera lógica para formar un solo cambio. TFVC bloquea los archivos
de código que son sometidos a modificaciones. Otros desarrolladores pueden leer
el archivo bloqueado, pero no pueden editarlo. Tienen que esperar la edición previa
para completar y liberar el bloqueo antes de poder editar. El historial de registros y
cambios se guarda en el repositorio central y los desarrolladores tienen la copia de
trabajo de los archivos, pero no cuentan con el historial.
TFVC funciona muy bien con equipos grandes que trabajan en los mismos proyectos.
Esto permite el control sobre el código fuente en un lugar central. También funciona
mejor cuando el proyecto es prolongado porque el historial se administra en una
ubicación central. TFVC no tiene inconvenientes con archivos grandes ni binarios.
[ 237 ]
DevOps en Azure

GIT
Por otra parte, GIT es una manera distribuida y moderna de implementar el control
de versiones donde los desarrolladores pueden trabajar en sus copias locales del
código y el historial en modo sin conexión. Los desarrolladores pueden trabajar sin
conexión en su clon local del código. Cada desarrollador tiene una copia local del
código y todo el historial, y trabaja en sus cambios con este repositorio local. Puede
confirmar su código en el repositorio local. Tiene la posibilidad de conectarse al
repositorio central para la sincronización de su repositorio local, según sea necesario.
Esto permite que cada desarrollador trabaje en cualquier archivo ya que trabajaría
en su copia local. La bifurcación en GIT no crea otra copia del código original y es
extremadamente rápida de crear.
GIT funciona bien con un equipo más pequeño. En los equipos más grandes,
hay una sobrecarga substancial para administrar múltiples solicitudes de inserción
y combinar el código en un repositorio central. También funciona mejor en proyectos
breves, de esta forma el tamaño del historial no aumenta demasiado como para
ser descargado y administrado en el repositorio local de cada desarrollador.
La ramificación y la fusión son cuestiones muy sencillas con las opciones de avance.
GIT es la forma recomendada de utilizar el control de código fuente debido a la gran
cantidad de funcionalidades que proporciona. En este libro, usaremos GIT como el
repositorio para nuestra aplicación de ejemplo.

Preparación para DevOps


A partir de este capítulo, el eje central estará en la automatización del proceso
y la implementación mediante diversos patrones de Azure. Entre ellos se incluyen
los siguientes:
• DevOps para soluciones IaaS
• DevOps para soluciones PaaS
• DevOps para soluciones basadas en contenedor
Generalmente, hay servicios comunes compartidos que no son exclusivos de alguna
aplicación en particular. Varias aplicaciones de diferentes entornos usan sus servicios,
como desarrollo, pruebas y producción. El ciclo de vida de estos servicios comunes
compartidos es diferente de otras aplicaciones. Por lo tanto, tienen cuentas de control
de versión diferentes y una administración distinta de código de base, compilación
y versión. Tienen su ciclo propio de plan, diseño, compilación, pruebas y lanzamiento.

[ 238 ]
Capítulo 10

Los recursos que forman parte de este grupo se aprovisionan con plantillas de ARM
y configuraciones de PowerShell y DSC.
A continuación, se muestra el flujo general para la construcción de estos componentes
comunes:

[ 239 ]
DevOps en Azure

El proceso de lanzamiento se muestra en el siguiente diagrama:

Para iniciar el recorrido de DevOps, es importante comprender los servicios y


componentes comunes, y aprovisionarse de ellos antes de comenzar cualquier
contratación de software, producto o servicio.

Aprovisionamiento de cuenta de VSTS


Para colaborar en el nivel de código, se necesita un sistema de control de versión.
VSTS ayuda a proporcionar versiones centralizadas y descentralizadas de los sistemas
de control. VSTS también proporciona servicios de orquestación para la construcción
y ejecución de procesos de compilación y lanzamiento. Es una plataforma madura
para organizar todo el control de versión, la compilación, el lanzamiento y los
artefactos relacionados con elementos de trabajo de DevOps. Después de que se
aprovisiona la cuenta, es necesario crear un proyecto de VSTS para mantener todos
los artefactos relacionados con el proyecto.
Puede aprovisionarse una cuenta de VSTS visitando el sitio
https://www.visualstudio.com.

[ 240 ]
Capítulo 10

Aprovisionamiento del almacén de claves


de Azure
No es recomendable guardar información confidencial, certificados, credenciales
y otros datos delicados de archivos de configuración de código en archivos, bases de
datos o cualquier otro sistema de almacenamiento general. Se recomienda guardar
estos datos importantes en un almacén diseñado específicamente para guardar
información confidencial y credenciales. Azure Key Vault ofrece dicho servicio.
Está disponible como un recurso y un servicio de Azure.

Aprovisionar un servidor de administración


de configuración
Un servidor de administración de configuración que proporciona almacenamiento
para configuraciones y el uso de esas configuraciones en diferentes entornos siempre
es una estrategia adecuada para la implementación de la automatización. DSC en
máquinas virtuales personalizadas, DSC a partir de la automatización de Azure,
Chef, Puppet y Ansible son algunas de las opciones y pueden usarse en Azure sin
problemas, para entornos de Windows y Linux. Este libro utiliza DSC como una
herramienta de administración de configuración para todo fin y proporciona un
servidor de extracción que contiene todos los documentos de configuración (archivos
MOF) para la aplicación de ejemplo. Además, mantiene la base de datos de todas las
máquinas virtuales y contenedores que son configurados y registrados en el servidor
de extracción para obtener de ahí los documentos de configuración. El administrador
de configuración local en estos contenedores y máquinas virtuales de destino
verifica periódicamente la disponibilidad de nuevas configuraciones y también de
desviaciones en la configuración actual e informa lo mismo al servidor de extracción.
También tiene capacidades de informes incorporadas que proporcionan información
sobre los nodos que cumplen con los requisitos, así como de aquellos que no los
cumplen en una máquina virtual. Un servidor de extracción es una aplicación web
general que aloja el punto de conexión del servidor de extracción DSC.

Aprovisionamiento de análisis de registro


El análisis de registro es un servicio de auditoría y control de Azure para obtener
información en tiempo real sobre todos los cambios, desviaciones y eventos que se
producen dentro de las máquinas virtuales y los contenedores. Proporciona un panel
y un espacio de trabajo centralizado para los administradores de TI que les permite
ver, buscar y realizar búsquedas de análisis en todos los cambios, desviaciones
y eventos que ocurren en estas máquinas virtuales. También ofrece agentes
que se implementan en máquinas virtuales y contenedores de destino. Una vez
implementados, estos agentes comienzan a enviar todos los cambios, los eventos
y las desviaciones al espacio de trabajo centralizado.

[ 241 ]
DevOps en Azure

Cuenta de almacenamiento de Azure


El almacenamiento de Azure es un servicio de Azure para almacenar archivos
como blobs. Todos los scripts y códigos para automatizar el aprovisionamiento,
la implementación y la configuración de la infraestructura y la aplicación de muestra
se almacenan en un repositorio de git de VSTS y se empaquetan e implementan en
una cuenta de almacenamiento de Azure. Azure proporciona recursos de extensión
de script PowerShell que pueden descargar scripts de DSC y PowerShell, y ejecutarlos
en máquinas virtuales durante la ejecución de plantillas del administrador de recursos
de Azure. Este almacenamiento actúa como un almacenamiento común en todas las
implementaciones de múltiples aplicaciones.

Imágenes
Las imágenes tanto de máquina virtual como de contenedor tendrían que construirse
como parte de la compilación y el proceso de lanzamiento de servicios comunes. Las
herramientas, como la compilación de Packer o Docker, pueden usarse para generar
estas imágenes.

Herramientas de supervisión
Todas herramientas de supervisión, como Azure Monitor, las perspectivas de la
aplicación, los análisis de registro, OMS y el administrador de operaciones del
sistema, tienen que ser aprovisionadas y configuradas en el proceso de lanzamiento
de los servicios comunes.

Herramientas de administración
Toda las herramientas de administración, como Kubernetes, DC/OS, Docker Swarm,
ITIL tienen que ser aprovisionadas en esta etapa.

[ 242 ]
Capítulo 10

DevOps para soluciones PaaS


La arquitectura típica de los servicios de aplicación de Azure PaaS se basa en
la solución que se muestra a continuación:

[ 243 ]
DevOps en Azure

La arquitectura muestra algunos de los componentes importantes, tales como Azure


SQL, cuentas de almacenamiento, sistema de control de versiones, etc., que participan
en los servicios de aplicación de Azure, según la arquitectura de la solución en la
nube. Estos artefactos tienen que crearse mediante plantillas del administrador de
recursos de Azure. Estas plantillas de ARM tienen que ser parte de la estrategia
general de administración de configuración. Puede tener sus propias canalizaciones
de compilación y administración de lanzamiento que sean parecidas a las que se
muestran en la sección anterior:

La plantilla de ARM también tiene que configurar la implementación continua


mediante la configuración de las opciones de implementación.

Servicios de aplicación de Azure


El servicio de aplicación de Azure proporciona servicios de hosting administrados
para soluciones en la nube. Es una plataforma totalmente administrada para
aprovisionar e implementar soluciones en la nube. Los servicios de aplicación
eliminan la complicación de crear y administrar infraestructura y proporcionan
acuerdos de nivel de servicio (SLA) mínimos para alojar las soluciones en la nube.
Son abiertos y permiten que los usuarios decidan sobre la opción de idioma que
desean utilizar para el desarrollo de sus soluciones en la nube, y son flexibles para
alojar la solución en la nube en cualquier sistema operativo, Windows o Linux.
La creación de un servicio de aplicación y el hosting de soluciones en la nube
aprovisionan a las máquinas virtuales en segundo plano que son administradas
en forma total por Azure, y los usuarios no lo detectan en lo absoluto. Varios tipos
diferentes de soluciones en la nube, como aplicaciones web, API de backend móviles,
puntos de conexión de API y contenedores, pueden alojarse sin problemas en
servicios de aplicación de Azure.
[ 244 ]
Capítulo 10

Ranuras de implementación
El servicio de aplicación de Azure proporciona ranuras de implementación que
permiten una instalación sin inconvenientes y fácil en ellas. Hay una ranura de
producción y staging, y permite a los usuarios intercambiarlas en forma simple.
Esto ayuda a implementar primero la solución en la nube personalizada en staging
y, después de todas las pruebas y los controles, pueden intercambiarse a producción
si no se presentan problemas. Sin embargo, en caso de cualquier inconveniente en la
producción después del intercambio, los valores anteriores aceptables del entorno de
producción pueden reintegrarse mediante un nuevo intercambio.

Azure SQL
Azure SQL es un servicio PaaS de SQL proporcionado por Azure para bases de datos
de host. Azure ofrece una plataforma segura para alojar bases de datos y asume la
propiedad total para administrar la disponibilidad, la confiabilidad y la escalabilidad
del servicio. Gracias a Azure SQL, no es necesario aprovisionar las máquinas virtuales
personalizadas, implementar un servidor SQL y configurarlo. En cambio, el equipo de
Azure lo hace en segundo plano y lo administra por nosotros. También proporciona
un servicio de firewall que permite seguridad, y solo una dirección IP habilitada por
el firewall puede conectarse al servidor y acceder a la base de datos. Las máquinas
virtuales aprovisionadas para alojar aplicaciones web tienen distintas direcciones IP
públicas asignadas y se agregan a las reglas del firewall de Azure SQL en forma
dinámica. El servidor Azure SQL y su base de datos se crean mientras se ejecuta la
plantilla de administrador de recursos de Azure. Es necesario tener en cuenta que,
en general, la administración de máquinas virtuales tiene que ejecutar dichas tareas.

Canalización de compilación y versión


Los servicios de aplicación de Azure proporcionan servicios listos para usar en la
implementación continua y tienen que utilizarse para implementar soluciones en la
nube personalizadas, como se muestra a continuación. Es necesario proporcionar
información sobre la cuenta, el repositorio y la rama. Los servicios de aplicación
de Azure se conectan al repositorio y obtienen el último código fuente de la rama
provista y ejecutan los pasos de compilación de la compilación y generación de
artefactos que pueden implementarse. Además, se implementará de manera
automática en las ranuras de implementación de staging.
En el extremo del desarrollador, es necesario configurar Visual Studio para conectarse
al sistema de control de versión. Los servicios de aplicación de Azure tienen que
comenzar el proceso de compilación cada vez que un desarrollador verifique o inserte
su código en la rama del repositorio.

[ 245 ]
DevOps en Azure

DevOps para soluciones basadas en


máquinas virtuales (IaaS)
A continuación, se muestra la arquitectura típica de la solución basada en máquinas
virtuales de IaaS:

Máquina virtual de Azure


Las máquinas virtuales de Azure que alojan aplicaciones web, servidores de
aplicaciones, base de datos y otros servicios se aprovisionan con plantillas de ARM.
Cada máquina virtual tiene una tarjeta de red individual con una IP pública asignada.
Están conectadas a una red virtual y tienen una dirección IP privada de la misma red.
La IP pública para las máquinas virtuales es opcional, dado que están conectadas a un
equilibrador de carga pública. Estas máquinas virtuales se basan en una imagen de
servidor de Windows 2016. Los agentes de conocimientos operativos se instalan en
las máquinas virtuales para supervisarlas. En estas máquinas virtuales también se
ejecutan scripts de PowerShell que se descargan de una cuenta de almacenamiento
disponible en otro grupo de recursos para abrir los puertos de firewall pertinentes,
descargar los paquetes correspondientes e instalar los certificados locales para
asegurar el acceso seguro a través de PowerShell. La aplicación web está configurada
para ejecutarse en el puerto suministrado en estas máquinas virtuales. El número
de puerto para la aplicación web y toda su configuración se obtiene del servidor de
extracción DSC y se asigna en forma dinámica.

[ 246 ]
Capítulo 10

Equilibrador de carga pública de Azure


Un equilibrador de carga pública se conecta a algunas de las máquinas virtuales
para enviarles peticiones con una modalidad round robin. Por lo general, esto es
necesario para aplicaciones web frontend y API. Una dirección IP pública y un
nombre DNS pueden asignarse al equilibrador de carga de manera que pueda atender
las peticiones de Internet. Acepta solicitudes web de HTTP en un puerto diferente
y enruta lo mismo hacia las máquinas virtuales. También sondea en ciertos puertos
en protocolos HTTP con algunas rutas de aplicación proporcionadas. Las reglas de
Traducción de dirección de red (NAT) también pueden aplicarse de manera que
puedan usarse para iniciar sesión en las máquinas virtuales mediante escritorios
remotos.
Un recurso alternativo para el equilibrador de carga público de Azure es el gateway
de aplicación Azure y, según sea la situación, puede usarse e implementarse.

Canalización de compilación
A continuación, se muestra una canalización de compilación típica para una solución
basada en máquinas virtuales de IaaS. Una canalización de compilación comienza
cuando un desarrollador inserta su código en el repositorio. La canalización de
compilación se inicia de manera automática como parte de la integración continua.
Compila y genera el código, ejecuta las pruebas unitarias en el código, verifica la
calidad del código y genera documentación a partir de los comentarios del código.
Implementa los archivos binarios en el entorno de desarrollo (tenga en cuenta
que el entorno de desarrollo no se creó recientemente), cambia la configuración y
ejecuta las pruebas de integración y las etiquetas de compilación generadas para una
identificación fácil. Luego, suelta los artefactos generados en una ubicación accesible
a la que puede acceder la canalización de versión. Si hay problemas durante la
ejecución de cualquier paso en este proceso, se comunica al desarrollador como parte
de los comentarios de canalización de compilación de manera que se puedan volver
a procesar y los cambios se envíen de nuevo.

[ 247 ]
DevOps en Azure

La canalización de compilación tiene que generar errores o funcionar sin problemas


según la gravedad de los inconvenientes, y eso varía de acuerdo con cada organización:

Canalización de versiones
A continuación, se muestra una canalización de versión típica para una
implementación basada en máquinas virtuales de IaaS. Una canalización de versión
comienza luego de que se completa la canalización de compilación. El primer
paso para la canalización de versión es recopilar los artefactos generados por
la canalización de compilación. Por lo general, son ensamblados que pueden
implementarse, archivos binarios y documentos de configuración. La canalización
de versión se ejecuta y crea o actualiza el primer entorno que, casi siempre, es un
entorno de prueba. Utiliza plantillas del administrador de recursos de Azure para
aprovisionar todos los servicios y recursos de IaaS y PaaS en Azure y también los
configura. Además, ayuda a ejecutar scripts y la configuración de DSC después de
que se crean las máquinas virtuales como pasos posteriores a la creación. Esto ayuda
a configurar el entorno en la máquina virtual y en el sistema operativo. En esta etapa,
se implementan y configuran los archivos binarios de la aplicación de canalización
de compilación. Se realizan diferentes pruebas automatizadas para comprobar el
funcionamiento en la solución y, si no se detectan problemas, la canalización avanza
a la implementación en el próximo entorno después de obtener las aprobaciones
necesarias. Otra vez se ejecutan los mismos pasos en el entorno siguiente, que incluye
el entorno de producción. Por último, se ejecutan pruebas de validación operativas
en la producción para asegurar que la aplicación funcione como se esperaba y no
haya desviaciones. En esta etapa, si hay problemas o errores, tienen que rectificarse
y es necesario repetir todo el ciclo; sin embargo, si no se realiza dentro de un plazo
estipulado, será necesario restaurar la instantánea anterior conocida en el entorno de
producción para minimizar el tiempo de inactividad:
[ 248 ]
Capítulo 10

DevOps para soluciones basadas en


contenedor (IaaS)
A continuación, se muestra la arquitectura típica de la solución basada en contenedor
de IaaS:

[ 249 ]
DevOps en Azure

Contenedores
Los contenedores también constituyen una tecnología de virtualización; sin embargo,
no virtualizan servidores físicos. En su lugar, los contenedores son una virtualización
en el nivel del sistema operativo. Esto significa que los contenedores comparten entre
sí y con el host el kernel del sistema operativo que proporciona su host. La ejecución
de varios contenedores en un host (físico o virtual) comparte el kernel del sistema
operativo del host. Hay un solo kernel de sistema operativo proporcionado por el host
y utilizado por todos los contenedores que se ejecutan sobre dicho kernel.
Además, están totalmente aislados del host y de otros contenedores, como
una máquina virtual. Los contenedores utilizan controladores de filtros de
almacenamiento de Windows y el aislamiento de sesiones de servicios del sistema
operativo, como por ejemplo, sistemas de archivos, registro, procesos y redes.
Cada contenedor obtiene su propia copia de recursos del sistema operativo.

Docker
El Docker brinda funciones de administración a los contenedores de Windows.
Contiene dos ejecutables:
• Demonio Docker
• Cliente Docker
El Demonio Docker es el caballo de batalla para la administración de contenedores.
Es un servicio de Windows que se encarga de administrar todas las actividades
relacionadas con los contenedores en el host. El Cliente Docker interactúa con el
Demonio Docker y se encarga de capturar entradas y enviarlas al Demonio Docker.
El Demonio Docker brinda el tiempo de ejecución, las bibliotecas, los controladores
gráficos y los motores para crear, administrar y supervisar contenedores e imágenes
en el servidor host. Además, ofrece funciones para crear imágenes personalizadas que
se utilizan para construir y entregar aplicaciones a varios entornos.

DockerFile
DockerFile es un bloque de creación principal para la generación de imágenes de
contenedor de Windows. Es un archivo con capacidad de lectura humana basado en
un texto simple sin ninguna extensión y lleva el nombre de DockerFile. Si bien existe
un mecanismo para nombrarlo de otra manera, por lo general, se usa DockerFile.
DockerFile contiene las instrucciones para crear una imagen de contenedor
personalizada a partir de la imagen de base. El Demonio Docker, que es el motor que
está detrás de todas las actividades relacionadas con los contenedores de Windows,
ejecuta estas instrucciones en forma secuencial, de arriba hacia abajo. Las instrucciones
se refieren al comando y sus parámetros entendidos por el Demonio Docker. DockerFile
permite las prácticas de infraestructura como código mediante la conversión de la
implementación de aplicaciones y la configuración en las instrucciones que pueden ser
versionadas y almacenadas en un repositorio de código fuente.
[ 250 ]
Capítulo 10

Canalización de compilación
Desde el punto de vista de la compilación, no hay diferencia entre el contenedor y
una solución basada en una máquina virtual. El paso de compilación sigue siendo
el mismo. Consulte la sección anterior para obtener información detallada sobre
canalización de compilación.

Canalización de versiones
A continuación se muestra una canalización típica de versiones para una
implementación de IaaS basada en contenedor. La única diferencia entre esto y la
canalización de versiones es la administración de imagen de contenedor y la creación
de contenedor utilizando DockerFile y composición de Docker. Además, se pueden
implementar funciones avanzadas de administración de contenedores, como Docker
Swarm, DC/OS y Kubernetes, y configurarlas como parte de la administración
de versiones. No obstante, cabe señalar que, como se dijo anteriormente, estas
herramientas de administración de contenedores tienen que ser parte de la
canalización de versiones de servicios compartidos:

[ 251 ]
DevOps en Azure

Azure Automation
Azure Automation es la plataforma de Microsoft que se utiliza para toda
implementación de automatización con respecto a implementaciones en la nube,
locales e híbridas. Azure Automation es una plataforma de automatización
desarrollada que proporciona un amplio abanico de funciones en términos de lo
siguiente:
• Definición de activos, tales como variables, conexiones, credenciales,
certificados y módulos
• Implementación de runbooks con flujos de trabajo de Python, scripts y
PowerShell
• Provisión de interfaces de usuario para crear runbooks
• Administración del ciclo de vida completo de los runbooks, que incluye
compilación, prueba y publicación
• Programación de runbooks
• Capacidad para ejecutar runbooks en cualquier parte (en la nube o
localmente)
• DSC como plataforma de administración de configuración
• Administración y configuración de entornos, equipos (Windows y Linux),
aplicaciones e implementaciones
• Capacidad de ampliar Azure Automation mediante importación de módulos
personalizados
Azure Automation proporciona un servidor de extracción DSC que ayuda a crear un
servidor de administración de configuración centralizada con configuraciones para
nodos/máquinas virtuales y sus componentes.
Implementa el patrón de concentrador y radio en el que los nodos se pueden
conectar al servidor de extracción DSC, descargar configuraciones asignadas a ellos
y volver a configurarse para reflejar el estado deseado. El agente de DSC corrige
automáticamente las modificaciones y desviaciones dentro de estos nodos la próxima
vez que se ejecutan. Esto garantiza que los administradores no necesiten continuar
supervisando activamente el entorno para detectar desviaciones.
DSC ofrece un lenguaje declarativo en el que se definen la intención y la
configuración, pero no el modo en el que se ejecutan y aplican esas configuraciones.
Estas configuraciones se basan en el lenguaje de PowerShell y facilitan el proceso de
administración de configuración.
En esta sección, analizaremos una implementación simple en la que se utiliza DSC de
Azure Automation para configurar una máquina virtual para instalar y configurar un
servidor web (IIS), y para crear un archivo index.htm que informa a los usuarios que
el sitio web está en mantenimiento.
[ 252 ]
Capítulo 10

Aprovisionar la cuenta de Azure Automation


Cree una cuenta nueva de Azure Automation desde el portal de Azure o PowerShell
dentro de un grupo de recursos existente o uno nuevo. En la imagen que se incluye
a continuación, los lectores sagaces detectarán que Azure Automation brinda
elementos de menú para DSC. Ofrece lo siguiente:
• Nodos de DSC: enumera todas las máquinas virtuales y contenedores que
se registraron en el servidor de extracción DSC actual de Azure Automation.
Estas máquinas virtuales y contenedores se administran utilizando
configuraciones desde el servidor de extracción DSC actual en cuestión.
• Configuraciones de DSC: enumera todas las configuraciones PowerShell
brutas que se importaron y se cargaron al servidor de extracción DSC. Están
en formato legible para humanos y no en estado compilado.
• Configuraciones de DSC para nodos: enumera y compila todas las
configuraciones de DSC disponibles en el servidor de extracción a asignar
a los nodos (contenedores y máquinas virtuales). Una configuración de DSC
genera archivos MOF después de realizar compilaciones, que finalmente se
utilizan para configurar nodos.

[ 253 ]
DevOps en Azure

Redactar configuración de DSC


El próximo paso consiste en redactar una configuración de DSC usando cualquier
editor de PowerShell para reflejar la intención de configuración. Para este ejemplo,
se crea una sola configuración ConfigureSiteOnIIS. Importa el módulo DSC
base PSDesiredStateConfiguration que contiene los recursos utilizados en la
configuración. Además, declara a un nodo servidor web. Una vez que se carga
y se compila esta configuración, se genera un DSCConfigurationNodes llamado
ConfigureSiteOnIISwebserver. Esta configuración puede posteriormente aplicarse
a los nodos.
La configuración consta de pocos recursos. Estos recursos configuran el nodo de
destino. Los recursos instalan un servidor web, ASP.NET y la estructura, y se crea un
archivo index.htm dentro del directorio inetpub\wwwroot con contenido que indica
que el sitio está en mantenimiento. Para obtener más información sobre la redacción
de la configuración de DSC, consulte https://docs.microsoft.com/es-es/
PowerShell/dsc/configurations.

Configuration ConfigureSiteOnIIS {
Import-DscResource -ModuleName 'PSDesiredStateConfiguration'
Node WebServer {
WindowsFeature IIS
{
Name = "Web-Server"
Ensure = "Present"
}
WindowsFeature AspDotNet
{
Name = "net-framework-45-Core"
Ensure = "Present"
DependsOn = "[WindowsFeature]IIS"
}
WindowsFeature AspNet45
{
Ensure = "Present"
Name = "Web-Asp-Net45"
DependsOn = "[WindowsFeature]AspDotNet"
}
File IndexFile
{
DestinationPath = "C:\inetpub\wwwroot\index.htm"
Ensure = "Present"
Type = "File"
Force = $true

[ 254 ]
Capítulo 10

Contents = "<HTML><HEAD><Title> Website under


construction.</Title></HEAD><BODY> `
<h1>If you are seeing this page, it means the website is
under maintenance and DSC Rocks !!!!!</h1></BODY></HTML>"
}
}
}

Importar la configuración de DSC


Azure Automation todavía no conoce la configuración de DSC. Está disponible en
algunas máquinas locales. Se tiene que cargar a Configuraciones de DSC de Azure
Automation. Azure Automation proporciona el cmdlet Import-AzureRMAutomationD
scConfiguration para importar la configuración a Azure Automation.

Import-AzureRmAutomationDscConfiguration -SourcePath "C:\DSC\


AA\DSCfiles\ConfigureSiteOnIIS.ps1" -ResourceGroupName "omsauto"
-AutomationAccountName "datacenterautomation" -Published -Verbose

Una vez aplicada la configuración al nodo, la configuración de DSC en Azure tendría


que aparecer como se muestra a continuación:

[ 255 ]
DevOps en Azure

Compilar la configuración de DSC


Una vez que la configuración de DSC está disponible en Azure Automation, es
posible que se le solicite que se compile. Azure Automation proporciona otro cmdlet
para lo mismo. Utilice el cmdlet Start-AzureRmAutomationDscCompilationJob
para compilar la configuración importada. El nombre de configuración tiene que
coincidir exactamente con el nombre de la configuración cargada. La compilación crea
un archivo MOF con el mismo nombre de la configuración y el nodo, que en este caso
es ConfigureSiteOnIIS. webserver.
Start-AzureRmAutomationDscCompilationJob -ConfigurationName
ConfigureSiteOnIIS -ResourceGroupName "omsauto" -AutomationAccountName
"datacenterautomation" -Verbose

Una vez aplicada la configuración al nodo, la configuración de DSC para nodos en


Azure tendría que aparecer como se muestra a continuación:

Asignar configuración a los nodos


Ahora, las configuraciones de DSC compiladas se pueden aplicar a los nodos.
Utilice Register-AzureRmAutomationDscNode para asignar la configuración a un
nodo. El parámetro NodeConfigurationName identifica el nombre de la configuración
que se tiene que aplicar al nodo. Es un cmdlet de gran alcance que también puede
configurar al agente de DSC que es localconfigurationmanager en los nodos antes
de que puedan descargar configuraciones y aplicarlas.

[ 256 ]
Capítulo 10

Hay múltiples parámetros localconfigurationmanager que se pueden configurar,


cuyos detalles se pueden encontrar en https://docs.microsoft.com/es-es/
PowerShell/dsc/metaconfig.

Register-AzureRmAutomationDscNode -ResourceGroupName "omsauto"


-AutomationAccountName "datacenterautomation" -AzureVMName
testtwo -ConfigurationMode ApplyAndAutocorrect -ActionAfterReboot
ContinueConfiguration -AllowModuleOverwrite $true -AzureVMResourceGroup
testone -AzureVMLocation "West Central US" -NodeConfigurationName
"ConfigureSiteOnIIS.WebServer" -Verbose

Una vez aplicada la configuración al nodo, los nodos de DSC en Azure tendrían que
aparecer como se muestra a continuación:

Navegar por el servidor


Si corresponde, se abren y se activan grupos de seguridad de red y firewalls para
el puerto 80, y se le asigna una IP pública a la máquina virtual, que se utiliza para
poder navegar el sitio web predeterminado. De lo contrario, inicie sesión en la
máquina virtual que se utiliza para aplicar la configuración de DSC y vaya a http://
localhost.

[ 257 ]
DevOps en Azure

Tiene que aparecer una página como la que se muestra a continuación:

Esto lo permite la administración de configuración que, sin escribir ningún código


significativo y redactando una vez una configuración, se puede aplicar varias veces al
mismo servidor, y a varios, con la certeza de que funcionarán en el estado deseado sin
ninguna intervención manual.

Azure para DevOps


Como se mencionó anteriormente, Azure es una plataforma sofisticada y desarrollada
que ofrece lo siguiente:
• Varias opciones de idiomas
• Varias opciones de sistema operativo
• Varias opciones de herramientas y utilidades
• Varios patrones para implementar soluciones (máquinas virtuales, servicios
de aplicación, contenedores, microservicios)
Con tantas opciones, Azure es lo siguiente:
• Nube abierta: está abierto para servicios, herramientas y productos de open
source tanto de Microsoft como no de Microsoft
• Nube flexible: brinda flexibilidad a usuarios y desarrolladores para que
se sientan cómodos al utilizar lo que sustenta sus actuales habilidades y
conocimientos
• Administración unificada: brinda características integradas de supervisión
y administración

[ 258 ]
Capítulo 10

Todas las características anteriormente citadas son importantes para la implementación


exitosa de DevOps para cualquier proyecto o interacción. La imagen que aparece a
continuación muestra las herramientas y utilidades open source que se pueden utilizar
para diferentes fases de la administración del ciclo de vida de las aplicaciones y de
DevOps en general. Esto es solo una pequeña representación de todas las herramientas
y utilidades, y hay más opciones disponibles.
• Herramientas Jenkins, Hudson, Grunt y Gradle para la construcción de
canalización de compilación
• Selenium para pruebas
• Chef, Puppet, Jenkins, Hudson, Grunt, Gradle y otras para la administración
de implementación o configuración
• Nagios para alertas y supervisión
• Jira y Redmine para la administración de procesos

La imagen que aparece a continuación muestra las herramientas y utilidades de


Microsoft que se pueden utilizar para diferentes fases de la administración del ciclo
de vida de las aplicaciones y de DevOps en general. Nuevamente, esto es solo una
pequeña representación de todas las herramientas y utilidades, y hay más opciones
disponibles.
• Instrumentación para creaciones VSTS para la construcción de una
canalización de compilación
• Microsoft Test Manager, Pester para pruebas
• Desired State Configuration, PowerShell, plantillas de ARM y otras para la
administración de implementación o configuración
[ 259 ]
DevOps en Azure

• Análisis de registros, información de la aplicación y System Center Operations


Manager (SCOM) para alertas y supervisión
• VSTS y System Center Service Manager para la administración de procesos

Resumen
DevOps está adquiriendo mucha fuerza e ímpetu en la industria. La mayoría de las
organizaciones han aprovechado sus beneficios y están esperando ansiosamente
implementar DevOps. Esto sucede mientras que la mayoría de ellos se pasa a la nube.
Como modelo de nube, Azure es sofisticada y está desarrollada para prestar servicios
de DevOps, facilitando la implementación de DevOps por parte de las organizaciones.
En este capítulo, abordamos pormenorizadamente el tema de DevOps junto con sus
prácticas centrales, tales como administración de configuración, integración continua,
entrega continua e implementación. Además, abordamos distintas soluciones en la
nube basadas en PaaS, IaaS de máquinas virtuales e IaaS de contenedores junto con
los respectivos recursos y canalizaciones de compilación y de versiones de Azure.
La administración de configuración constituyó el tema central de este capítulo
y abordamos los servicios DSC de Azure Automation y el uso de servidores de
extracción para configurar máquinas virtuales automáticamente. Por último, vimos
la apertura y flexibilidad de Azure respecto a las variadas opciones de open source
en cuanto a idiomas, herramientas y sistema operativo.
El costo es uno de los factores más importantes para pasar a la nube y existen
oportunidades de ahorrar y administrar costos incluso en la nube. En el próximo
capítulo sobre gestión de costos, se aborda en detalle el tema de administración y
minimización de costos en Azure.
[ 260 ]
Administrar costos
La razón principal por la que las empresas se están trasladando a la nube es el
ahorro de costos. No hay costos iniciales por tener una suscripción de Azure. Azure
proporciona un mecanismo de pago según el uso lo que significa que, basándose en
el consumo, comienza a medir el uso y proporciona facturas mensuales. No hay
ningún límite máximo para el consumo de Azure. Esta plataforma ofrece recursos
ilimitados y cualquiera que tenga acceso a ella puede continuar creando tantos
recursos como quiera. En tales circunstancias, es importante para las empresas
vigilar atentamente el consumo de Azure y su uso. Aunque pueden crear políticas
para establecer convenios y normas organizacionales, también existe la necesidad
de obtener la información de facturación y consumo de Azure fácilmente. Además,
quieren implementar los procedimientos recomendados para el consumo de recursos
de Azure para maximizar la rentabilidad. Para ello, los arquitectos necesitan
tener conocimiento sobre los recursos y las características de Azure, sus costos
correspondientes y la comparación costo-beneficio entre las características y la
demanda de soluciones.
En este capítulo, trataremos lo siguiente:
• Facturación de Azure
• Facturas
• Uso y cuotas
• API de facturación y uso
• Calculadora de precios de Azure
• Procedimientos recomendados

[ 261 ]
Administrar costos

Comprensión de la facturación
Azure es una herramienta de servicio que tiene las siguientes ventajas:
• Sin costos iniciales
• Sin tarifas de cancelación
• Facturación por minuto
• Pago basado en el consumo según el uso
En tales circunstancias, resulta muy difícil calcular el costo por adelantado del
consumo de recursos de Azure. Cada recurso en Azure tiene su propio modelo de
costo y cargo basado en el almacenamiento, uso y duración. Es muy importante para
la gestión, la administración y el departamento de finanzas hacer un seguimiento del
uso y los costos. Azure proporciona los informes de uso y facturación necesarios para
que los gerentes y administradores de las organizaciones puedan generar un informe
de costo y uso basado en varios criterios.
El portal de Azure brinda la información detallada de la facturación y el uso a través
de la característica de facturación, a la que se puede acceder desde la hoja de
navegación principal.

[ 262 ]
Capítulo 11

Proporciona un submenú para generar informes sobre los costos y la facturación:

Si hace clic en el menú Suscripciones de esta hoja, aparecerá una lista con todas las
suscripciones a las que el usuario tiene acceso para generar informes:

[ 263 ]
Administrar costos

Haga clic en el nombre de la suscripción en esta lista para obtener un panel de control
a través del cual puede encontrar la facturación completa, la factura, el uso, el consumo,
las políticas, los grupos de recursos y los recursos. El gráfico en esta sección de resumen
proporciona un porcentaje de costo por recurso y también la tasa de consumo:

Si hace clic en el gráfico, le mostrará los detalles de costo basados en cada recurso.
Aquí hay varias cuentas de almacenamiento aprovisionadas en Azure y su costo.
Si utiliza esta pantalla, podrá generar varios tipos de informes estableciendo
diferentes criterios y combinaciones de estos para lo siguiente:
• Tipos de recursos
• Grupo de recursos
• Duración
• Etiqueta
Las etiquetas tienen una naturaleza especialmente interesante. Se pueden utilizar las
consultas basadas en etiquetas como departamento, proyecto, propietario, centro de
costos o cualquier otro par de nombre/valor para mostrar el costo correspondiente.
También puede descargar el informe de costos como un archivo CSV si hace clic en
el botón Descargar:

[ 264 ]
Capítulo 11

Si hace clic sobre un recurso individual obtendrá el consumo de costo diario para
el recurso:

[ 265 ]
Administrar costos

Facturas
La característica de facturación de Azure también proporciona información sobre las
facturas que se generan mensualmente.
Si hace clic en el botón Facturas aparecerá una lista de todas las facturas generadas:

Para obtener detalles de una factura determinada, haga clic sobre ella:

También existe una forma alternativa para descargar los detalles de las facturas.
Estos están disponibles si inicia sesión en https://azure.microsoft.com/es-es/
y los descarga:

[ 266 ]
Capítulo 11

Clientes del Contrato Enterprise


Los clientes que tienen un Contrato Enterprise pueden utilizar
https://ea.azure.com para descargar los informes de uso y facturación.
Hay también un nuevo paquete de contenido de Power BI que se lanzó
recientemente y que se puede utilizar para ver el uso y los costos de Azure
a través de informes y un panel de control en Power BI.

Encontrará más información sobre este tema disponible en


https://azure.microsoft.com/en-us/blog/new-power-bi-
content-pack-for-azure-enterprise-users/.

Uso y cuotas
Cada suscripción tiene un cupo limitado para cada tipo de recurso. Por ejemplo,
podría haber un máximo de 60 direcciones IP públicas aprovisionadas con una
cuenta de Microsoft de MSDN. Del mismo modo, todos los recursos tienen un
límite máximo predeterminado para cada tipo de recurso. Puede incrementar estas
cantidades de tipo de recursos para una suscripción poniéndose en contacto con el
soporte de Azure o haciendo clic en el botón Solicitar aumento.

[ 267 ]
Administrar costos

La información de uso y cupo está disponible en el submenú uso + cupo del menú
de Suscripción:

Esta hoja muestra todos los tipos de recursos aprovisionados en la suscripción junto
con su ubicación y cuentas. Aquí el cupo para las cuentas de almacenamiento clásico
es 100 y, actualmente, se han consumido tres cuentas de este tipo.
Hay criterios de filtro disponibles según la ubicación, los proveedores, el uso y
el cupo. Se pueden generar informes personalizados en función de estos criterios
de filtro.

Proveedores de recursos
Los recursos se basan en tipos de recursos y están disponibles en los proveedores
de recursos. Hay numerosos proveedores disponibles en Azure y proporcionan los
tipos de recursos necesarios que los usuarios necesitan para crear sus instancias.
Por ejemplo, el proveedor de recursos Microsoft.Compute ofrece tipos de recursos
de máquinas virtuales. Si estos se usan, pueden crearse instancias de máquinas
virtuales.
Los proveedores de recursos son obligatorios para estar registrado en las
suscripciones de Azure. Los tipos de recursos no estarán disponibles en una
suscripción si los proveedores de recursos no están registrados. Se puede utilizar
el siguiente panel de control para obtener una lista de proveedores disponibles,
registrados y no registrados, y para registrar a los proveedores no registrados
o eliminar del registro a los registrados:

[ 268 ]
Capítulo 11

API de facturación y uso


Aunque el portal es una gran forma de encontrar información sobre el uso,
la facturación y las facturas manualmente, Azure también proporciona lo siguiente:
• API de descarga de facturas: utilice esta API para descargar facturas.
• API de uso de recursos: utilice la API de uso de recursos de Azure para
obtener los datos de consumo estimados de Azure.
• API de RateCard: utilice la API de Azure Resource RateCard para obtener la
lista de recursos disponibles de Azure y la información sobre los precios para
cada uno de ellos.
Estas API se pueden usar para recuperar datos mediante programación y crear
paneles de control e informes personalizados. Cualquier lenguaje de programación
o script puede utilizar estas API y crear una solución de facturación completa.

Modelos de precios de Azure


Azure tiene varios modelos de precios. Prácticamente, tiene un modelo para casi
todo tipo de cliente. Desde cuentas gratuitas para estudiantes y desarrolladores hasta
cuentas de pago según el uso, y desde Contratos Enterprise hasta modelos de socios
proveedores de soluciones en la nube. Además de estos tipos de cuentas, hay precios
y descuentos adicionales como las instancias reservadas de VM y los beneficios
híbridos de Azure.

[ 269 ]
Administrar costos

Beneficio híbrido de Azure


Cuando una máquina virtual se aprovisiona en Azure, hay dos tipos de costos
involucrados. Estos son el costo de recursos para ejecutar la máquina virtual y el costo
de licencia del sistema operativo. Si bien los clientes del Contrato Enterprise obtienen
algunos descuentos, en comparación con otras cuentas desde la perspectiva de precios,
Azure les brinda otra oferta. Se conoce como beneficios híbridos de Azure. En este
esquema, los clientes existentes del Contrato Enterprise pueden traer sus licencias
locales para el sistema operativo a fin de crear una máquina virtual en Azure, y Azure
no le cobrará ningún costo de licencia. El ahorro de costos puede ser tan alto como
el 40 por ciento al utilizar este esquema. Los clientes del Contrato Enterprise también
tienen que tener Software Assurance para aprovechar este beneficio y su aplicación
para Windows estándar y Datacenter Edition. Cada licencia de 2 procesadores o cada
conjunto de licencias de 16 núcleos tiene derecho a dos instancias de hasta 8 núcleos
o una instancia de hasta 16 núcleos. El beneficio híbrido de Azure para licencias de
edición estándar se puede utilizar solo una vez, ya sea de manera local o en Azure.
Los beneficios de Datacenter Edition permiten el uso simultáneo de manera local
y en Azure.

Instancias reservadas de VM de Azure


Los clientes pueden reservar un número establecido de máquinas virtuales por
adelantado durante el plazo de uno a tres años al asignarlas a Azure para los
sistemas operativos Windows y Linux. Azure ofrece hasta el 72 por ciento de
descuento en estas máquinas virtuales de acuerdo con el modelo de precios de pago
según el uso. Aunque hay una asignación inicial, no es obligatorio usarlas. Estas
instancias reservadas pueden cancelarse en cualquier momento. Incluso pueden ser
apaleadas con los beneficios híbridos de Azure que ofrecen reducir aún más el costo
de la licencia para estas máquinas virtuales.

Cuentas de pago según el uso


Estas son cuentas generales de Azure que se facturan mensualmente a los clientes.
Los clientes no asignan ningún uso y son libres de utilizar cualquier recurso en
función de sus necesidades. Los costos de recursos se calculan sobre la base del
uso de sus recursos y tiempo de actividad. Esto, sin embargo, depende del tipo
de recurso. Cada recurso tiene su propio modelo de costo. Tampoco hay costos
iniciales asociados a estas cuentas. Por lo general, no hay descuentos disponibles
en este esquema.

[ 270 ]
Capítulo 11

Contratos Enterprise
Los clientes que ya tienen contratos con Microsoft pueden agregar a su inquilino
de Azure como parte de Contratos Enterprise. Los clientes pueden aprovechar
grandes descuentos si son parte de Contratos Enterprise. Solo necesitan asignar un
compromiso monetario inicial anual y se pueden agregar a este esquema. Los clientes
son libres de consumir este compromiso de la manera que consideren mejor para
ellos. Consulte https://azure.microsoft.com/en-in/pricing/enterprise-
agreement/ para obtener más información.

Proveedor de soluciones en la nube


El proveedor de soluciones en la nube (CSP) es un modelo para los socios de
Microsoft. CSP permite a los socios tener la propiedad completa del ciclo de vida
y la relación del cliente para Azure de Microsoft. Los socios pueden implementar las
soluciones en la nube y cobrar a los clientes que utilicen este esquema.
Consulte https://azure.microsoft.com/es-es/offers/ms-azr-0145p/ para
obtener más información.

Calculadora de precios de Azure


Azure ofrece una calculadora de costos destinada a usuarios y clientes para que
calculen sus costos y usos. Esta calculadora está disponible en https://azure.
microsoft.com/es-es/pricing/calculator/:

[ 271 ]
Administrar costos

Los usuarios pueden seleccionar varios recursos desde el menú de la izquierda, y se


agregarán a la calculadora. En el ejemplo siguiente, se agrega una máquina virtual.
Para calcular el costo, se proporcionan más configuraciones con respecto a la región
de máquina virtual, el sistema operativo, el tipo, el nivel, el tamaño de la instancia, el
número de horas y el recuento:

Del mismo modo, el costo para las funciones de Azure para el tamaño de la
memoria, el tiempo de ejecución y la ejecución por segundos de la máquina virtual
se muestra a continuación:

[ 272 ]
Capítulo 11

Azure ofrece diferentes niveles y planes de soporte que se describen a continuación:


• Soporte por defecto: es gratis.
• Soporte para desarrolladores: 29 dólares al mes.
• Soporte estándar: 300 dólares al mes.
• Dirección de profesiones: 1000 dólares al mes.
Finalmente, se muestra el costo total estimado:

Es importante que los arquitectos comprendan cada característica de Azure que se


utiliza en la solución y la arquitectura general. El éxito de la calculadora de Azure
depende de cuáles son los recursos seleccionados y su configuración. Cualquier
tergiversación daría lugar a estimaciones sesgadas y erróneas y sería diferente de la
facturación real.

Procedimientos recomendados
Los arquitectos tienen que hacer un esfuerzo adicional para entender la arquitectura
y los componentes de Azure que se utilizan. Sobre la base de la vigilancia activa,
las auditorías y el uso, tienen que determinar la oferta de Microsoft en términos de
Sku, tamaño y características. Esta sección detallará algunos de los procedimientos
recomendados que tienen que adoptarse desde una perspectiva de optimización
de costos.

[ 273 ]
Administrar costos

Procedimientos recomendados de
procesamientos
Los procesamientos se refieren a servicios que ayudan a ejecutar servicios. Algunos
de los procedimientos recomendados relacionados con los procesamientos son los
siguientes:
• Elegir la mejor ubicación para los servicios de procesamientos como máquinas
virtuales. Elegir una ubicación donde las características y los recursos de
Azure se encuentren todos disponibles en la misma región. Esto evitará el
tráfico de egreso. 
• Elegir el tamaño óptimo para las máquinas virtuales. Una máquina virtual
de mayor tamaño cuesta más que una de menor tamaño e incluso podría no
necesitarse en absoluto.
• Cambiar el tamaño de las máquinas virtuales durante las épocas de demanda
y reducir el tamaño cuando esta última disminuye. Azure lanza tamaños de
VM más nuevos como una actividad continua de manera frecuente. Si un
nuevo tamaño disponible se adapta mejor, entonces se tiene que utilizar.
• Detener los servicios de procesamiento fuera de horario o cuando no son
necesarios. Esto es para entornos que no son de producción.
• Desasignar máquinas virtuales en lugar de apagarlas. Esto liberará todos los
recursos y medidores ya que su consumo se detendrá.
• Utilizar laboratorios de desarrollo y prueba para trabajar con los objetivos.
Estos laboratorios proporcionan políticas y características de apagado y
encendido automáticos.
• Con conjuntos de escala de máquina virtual, el encendido reducirá el número
de máquinas virtuales y escalará de forma horizontal cuando la demanda
aumente.
• Elegir el tamaño correcto (pequeño, mediano o grande) para gateways de
aplicaciones. Están respaldados por máquinas virtuales y pueden ayudar
a reducir los costos con un tamaño óptimo. Además, se tiene que elegir
el gateway de aplicaciones de nivel básico si no se necesita un firewall de
aplicaciones web.
• Elegir los niveles correctos para los gateways de VPN (VPN básica, estándar,
de alto rendimiento o ultra rendimiento).
• Minimizar el tráfico de red entre regiones de Azure al ubicar en forma
conjunta los recursos en la misma región. 
• Utilizar el equilibrador de carga con IP pública para acceder a múltiples
máquinas virtuales en lugar de asignar una IP pública a cada máquina virtual.
• Supervisar las máquinas virtuales y hallar las métricas de rendimiento y
uso. De acuerdo con esto, se tiene que determinar si es preferible escalar la
máquina virtual de forma vertical u horizontal. También podría resultar en la
disminución del tamaño y la reducción de las máquinas virtuales.

[ 274 ]
Capítulo 11

Procedimientos recomendados de
almacenamiento
El almacenamiento también tiene un impacto importante desde una perspectiva del
costo general:
• Elegir el tipo de redundancia (GRS, LRS, RA-GRS) de almacenamiento
apropiado. GRS es más costoso que LRS.
• Archivar los datos de almacenamiento para inactivar o archivar el nivel de
acceso. Mantener los datos en el nivel de acceso frecuente.
• Eliminar los blobs que no se necesiten.
• Eliminar explícitamente los discos del sistema operativo de la máquina
virtual después de eliminar la máquina virtual, si no se necesitan.
• Medir las cuentas de almacenamiento de acuerdo con el tamaño, la escritura,
la lectura, la lista y las operaciones de contenedores.
• Preferir discos estándares antes que discos premium. Utilizar discos
premium solo si el negocio lo exige.
• Utilizar la red CDN y el almacenamiento en caché para los archivos estáticos
en el lugar de obtenerlos del almacenamiento cada vez.

Procedimientos recomendados de PaaS


Algunos de los procedimientos recomendados, si el modelo de implementación
preferido es PaaS, son los siguientes:
• Elegir los niveles apropiados de rendimiento y de SQL de Azure (básico,
estándar, premium RS o premium).
• Elegir apropiadamente entre bases de datos individuales y elásticas. Si hay
una gran cantidad de bases de datos, es más rentable utilizar bases de datos
elásticas en comparación con las individuales.
• Rediseñar las soluciones para usar PaaS (sin servidor, con microservicios
en contenedores) en lugar de las soluciones de IaaS. Estas soluciones de
PaaS quitan los costos de mantenimiento y están disponibles en una base de
consumo por minuto. Si no se consumen estos servicios, no hay ningún costo
a pesar de que su código y servicios estén disponibles a toda hora.
• Existen optimizaciones de costos específicas de recursos, pero no es posible
cubrir todas en un solo capítulo. Se recomienda a los lectores consultar la
documentación relacionada con el costo y uso de cada característica.

[ 275 ]
Administrar costos

Procedimientos recomendados generales


Algunos de los procedimientos recomendados generales desde la perspectiva del
costo son los siguientes:
• El costo de los recursos es diferente en todas las regiones. Se tiene que
intentar utilizar una región de costo mínimo. Esto depende, obviamente,
de la justificación empresarial.
• Los Contratos Enterprise ofrecen descuentos máximos. Si no se cuenta con un
Contrato Enterprise (EA), es recomendable participar en uno por las ventajas
económicas.
• Si los costos de Azure se pueden pagar por adelantado, entonces esta
plataforma ofrece descuentos para todo tipo de suscripción.
• Eliminar o sacar los recursos sin usar. Descubrir los recursos que son
subutilizados y reducir su tamaño o Sku. Si no son necesarios, entonces se
tienen que eliminar.
• Utilizar el asesor de Azure y tomar en serio sus recomendaciones.

Resumen
La administración y gestión de costos es una actividad importante cuando se trata
con la nube. Esto se debe principalmente a que, si bien el gasto mensual puede ser
muy bajo, también puede ser muy alto si no se le proporciona la atención correcta.
Los arquitectos tienen que diseñar su aplicación de manera tal que minimice
el costo. Tienen que usar los recursos de Azure, la Sku, el nivel y el tamaño
apropiados. Asimismo, tienen que saber cuándo iniciar, detener, escalar vertical
u horizontalmente, transferir datos y más. La administración apropiada de costos
garantizará que los gastos reales cumplan con los presupuestarios.
El próximo y último capítulo de este libro trata sobre las capacidades de supervisión
y auditoría en Azure.

[ 276 ]
Supervisión y auditoría
“Si no puede medirlo, no puede mejorarlo”.
- Lord Kelvin
Imagine una situación donde ha diseñado una solución que se implementó en la
nube, así como en un centro de datos local, que consta de varios servicios como IaaS
y PaaS, y componentes de aplicaciones de varios niveles y capas. Se basa en una
arquitectura altamente optimizada en términos de disponibilidad, escalabilidad,
seguridad, rendimiento y más. Ya está en producción. Ahora, imagine que no hay
ninguna instalación de supervisión integrada en la solución.
Existen algunos desafíos aquí y son los siguientes:
• Se desconoce la disponibilidad, escalabilidad, seguridad y fiabilidad de la
solución en todo momento.
• El equipo de operaciones no sabe si la solución funciona como se esperaba
hasta que los usuarios y clientes comienzan a llamarlos.
• El rendimiento de la solución disminuye con el tiempo, pero el equipo no
tiene las métricas actuales de rendimiento para comparar con nada.
• Los equipos de soluciones y operaciones no tienen mucha información para
diagnosticar o solucionar problemas.
• No se pueden realizar las revisiones de seguridad.
• Los equipos de soluciones y operaciones no saben qué puede mejorarse
y perfeccionarse para el cliente. Hay una falta de innovación.
Los problemas mencionados anteriormente son suficientes para empezar a pensar en
incorporar supervisión en las soluciones, independientemente de dónde y cómo se
implementen o diseñen.

[ 277 ]
Supervisión y auditoría

En este capítulo, veremos la supervisión desde los siguientes puntos:


• Perspectiva arquitectónica
• Recursos importantes de Azure para la supervisión
• Información de aplicaciones
• Análisis de registros
• Alertas
• Automatización de alertas para ejecutar runbooks
• Integración de Power BI

Supervisión
La supervisión es una preocupación arquitectónica importante que tiene que ser
parte de cualquier solución, ya sea grande o pequeña, crítica o no, de nube o no.
No tiene que evitarse a cualquier costo.
La supervisión se refiere al acto de hacer el seguimiento de soluciones y capturar
diferente información de telemetría, procesarla, identificar la que califica para alertas
de acuerdo con las reglas y generarla. Generalmente, un agente se implementa
dentro del entorno que lo continúa supervisando y enviando la información de
telemetría a un servidor centralizado donde ocurre el resto del proceso de generar
alertas y notificar a las partes interesadas.
La supervisión ayuda en la toma de medidas y acciones tanto proactivas como
reactivas en la solución. También es el primer paso hacia la capacidad de auditoría
de la solución. Sin la disponibilidad de registros de supervisión, resulta difícil
auditar el sistema desde varias perspectivas como la seguridad, el rendimiento,
la disponibilidad y más.
La supervisión ayuda a identificar los problemas de disponibilidad, rendimiento
y escalabilidad antes de que sucedan. Se pueden detectar los errores de hardware
o software y los problemas de actualizaciones de parches mucho antes de que afecten
a los usuarios gracias a la supervisión. La disminución del rendimiento puede
corregirse antes de que ocurra.
Reactivamente, los registros ayudan a encontrar las áreas y ubicaciones que causan
problemas, ayudan a identificar los problemas y permiten una corrección más rápida
y mejor.
Los equipos pueden identificar patrones de problemas mediante información
telemétrica de supervisión y ayudar a eliminar dichos patrones al innovar soluciones
y características más nuevas.
Azure es un entorno de nube enriquecido que proporciona múltiples y abundantes
características y recursos para supervisar tanto la implementación basada en la nube
como también la implementación local junto con otros proveedores de nube.
[ 278 ]
Capítulo 12

Supervisión de Azure
La primera pregunta que hay que responder es “¿qué tenemos que supervisar?”.
Esta pregunta se vuelve más importante para las soluciones que se implementan
en la nube debido al limitado control sobre esta.
Hay algunos componentes importantes que se tendrían que supervisar. Entre ellos:
• Las aplicaciones personalizadas
• Los recursos de Azure
• El sistema operativo invitado (máquinas virtuales)
• El sistema operativo host (servidores físicos de Azure)
• La infraestructura de Azure
Existen diferentes registros y supervisiones de Azure para los componentes
mencionados.

Registros de actividades de Azure


Anteriormente conocidos como registros de auditoría y operacionales, estos son
eventos de plano de control en la suscripción de Azure. Proporcionan información
de telemetría y de otro tipo en el nivel de la suscripción en lugar de en el nivel
de recursos individuales. Realizan el seguimiento de la información sobre todos
los cambios que suceden en el nivel de suscripción como la creación, eliminación
y actualización de recursos mediante Azure Resource Manager (ARM). Ayudan
a conocer la identidad (entidad de servicio, usuarios, grupos) y realizar una acción
(escribir, actualizar) sobre los recursos (por ejemplo, almacenamiento, máquinas
virtuales, SQL) en un momento dado. Proporcionan información sobre los recursos
que se modifican en su configuración, pero no en su trabajo interno y ejecución.

Registros de diagnóstico de Azure


La información que se origina en el trabajo interno de los recursos de Azure se
captura y se la conoce como registros de diagnóstico. Proporcionan información
de telemetría sobre las operaciones de recursos que es inherente a estos últimos.
No todo recurso proporciona registros de diagnóstico, y cualquiera que proporcione
registros en su propio contenido es completamente diferente de otros recursos.
Los registros de diagnóstico se configuran individualmente para cada recurso. Los
ejemplos de registros de diagnóstico incluyen el almacenamiento de un archivo en
un contenedor en un servicio blob en una cuenta de almacenamiento.

[ 279 ]
Supervisión y auditoría

Registros de aplicaciones de Azure


Los registros de aplicaciones se pueden capturar mediante recursos de
información de aplicaciones y se pueden administrar centralmente. Ayudan
a obtener más información sobre el funcionamiento interno de aplicaciones
personalizadas, como sus métricas de rendimiento, disponibilidad y más. Además,
se obtiene información de ellas para su mejor capacidad de administración.

Registros de sistema operativo invitado y host


Los registros del sistema operativo invitado y host se presentan a los usuarios
mediante los recursos de supervisión de Azure. Proporcionan información sobre el
trabajo, el estado del host y el sistema operativo invitado:

Los recursos importantes de Azure relacionados con la supervisión son los siguientes:
• Supervisor de Azure
• Azure Application Insights
• El análisis de registros anteriormente conocido como conocimientos
operacionales

[ 280 ]
Capítulo 12

Hay otras herramientas como System Center Operations Manager (SCOM) que


no son parte de la característica de la nube, pero que pueden implementarse en las
máquinas virtuales basadas en IaaS para supervisar cualquier carga de trabajo en
Azure o en un centro de datos local.

Supervisor de Azure
El supervisor de Azure es una herramienta central y un recurso que ofrece
características de administración completas para establecer la supervisión en
una suscripción de Azure. Proporciona características de administración para los
registros de actividad o de diagnóstico, las métricas, la información de aplicaciones
y el análisis de registro. Se lo tiene que tratar como un recurso de panel de control
y de administración para todas las demás capacidades de supervisión.

Azure Application Insights


Azure Application Insights ayuda a incorporar capacidades de supervisión,
de registros y de métricas centralizadas y de escalamiento de Azure a las aplicaciones
personalizadas. Estas aplicaciones pueden empezar a enviar métricas, registros y otra
información de telemetría a Azure Application Insights. También ofrece capacidades
enriquecidas de informes, paneles de control y análisis para obtener información de
datos entrantes y actuar sobre ellos.

Azure Log Analytics


Azure Log Analytics ofrece el procesamiento centralizado de registros y la
generación de información y alertas a partir de estos. Los registros de actividad,
de diagnóstico, de aplicaciones, de eventos e incluso personalizados pueden
enviar información a Log Analytics, que además puede proporcionar capacidades
enriquecidas de informes, paneles de control y análisis para obtener información de
datos entrantes y actuar sobre ellos.

Application insights
Tal como su nombre lo sugiere, Azure Application Insights proporciona información
sobre el funcionamiento de una aplicación. La información pertinente para una
aplicación web incluiría la cantidad entrante de solicitudes por segundo y de
solicitudes con errores por segundo, el empleo de hardware en cuanto al uso de
CPU, la disponibilidad de memoria y más. Application Insights proporciona un
panel de control, informes y gráficos para ver diferentes métricas relacionadas con
la aplicación. Esto ayuda a ver y comprender las tendencias en términos de uso de la
aplicación, su disponibilidad, cantidad de solicitudes y más con el fin de actuar tanto
preventiva como reactivamente en la aplicación. La información de las tendencias se
puede utilizar para descubrir cosas que no funcionen a favor de la aplicación y cosas
que funcionen bien durante un período.
[ 281 ]
Supervisión y auditoría

El primer paso para trabajar con la información de aplicaciones es aprovisionar este


servicio en Azure en un grupo de recursos que tenga todos los servicios generales
y de administración consumidos por todas las aplicaciones. Si recordamos, habíamos
creado un grupo de recursos similares llamado Win2016devOps que hospeda
a todos los servicios comunes como Azure Key Vault, la información de aplicaciones
u operativa y la cuenta de almacenamiento para tener scripts y plantillas que se usan
en todos los entornos y las aplicaciones.

Aprovisionamiento
Como se mencionó anteriormente, el primer paso para consumir servicios de
información de aplicaciones es aprovisionar esa información en Azure.
La información de aplicaciones se puede aprovisionar manualmente a través del
portal de Azure, API REST de Azure, PowerShell y las plantillas de ARM:
1. Inicie sesión en el portal de Azure, suscríbase con las credenciales adecuadas
y navegue hasta un grupo de recursos existente o cree uno nuevo. Haga clic
en el botón Agregar:

[ 282 ]
Capítulo 12

2. Escriba Application Insights en el cuadro de búsqueda de la hoja


resultante. El primer enlace tendría que referirse a la información de
aplicaciones, haga clic en él para crear una nueva instancia de servicio de
información de aplicaciones. Haga clic en el botón Crear para comenzar:

[ 283 ]
Supervisión y auditoría

3. La hoja resultante solicitará el nombre de la instancia de servicio de la


información de aplicaciones, el tipo de aplicación, el nombre de la suscripción,
el nombre del grupo de recursos y la ubicación del servicio. Proporcione los
datos adecuados y haga clic en el botón Crear. Esto aprovisionará el servicio:

[ 284 ]
Capítulo 12

4. Ahora, vaya al servicio que muestra las propiedades esenciales, tales como


su clave de instrumentación resaltada en la siguiente figura. La clave será
diferente en cada caso y generalmente copiada y utilizada en Visual Studio.
Tenga en cuenta que se ocultó parte de la información por razones de
seguridad:

[ 285 ]
Supervisión y auditoría

Análisis de registros
Application Insights se utiliza para supervisar la aplicación, sin embargo,
es igualmente importante supervisar el entorno donde esta se aloja y ejecuta.
Esto incluye la infraestructura como las máquinas virtuales, el contenedor Docker
y los componentes correspondientes.

Aprovisionamiento
El análisis de registros, también conocido como Operational Management Suite
(OMS), tiene que aprovisionarse en Azure antes de que pueda utilizarse para
supervisar las máquinas virtuales y los contenedores. Nuevamente, de forma similar
a la información de aplicaciones, la información operativa puede aprovisionarse
a través del portal de Azure, PowerShell, API REST y las plantillas del administrador
de grupo de recursos. Un espacio de trabajo de información operativa es un límite
de seguridad al que puede permitir que ciertos usuarios accedan. Tienen que crearse
varios espacios de trabajo para el aislamiento de los usuarios y su correspondiente
acceso a los datos de telemetría del entorno.
Se muestra a continuación el script JSON utilizado para el aprovisionamiento de un
espacio de trabajo de información operativa:
{
"apiVersion": "2015-11-01-preview",
"type": "Microsoft.OperationalInsights/workspaces",
"name": "[parameters('workspaceName')]",
"location": "[parameters('deployLocation')]",
"properties": {
"sku": {
"Name": "[parameters('serviceTier')]"
}
}
}

La información sobre el nombre, la ubicación y la SKU es necesaria para


aprovisionar un espacio de trabajo. Los valores para estas variables se proporcionan
a través del uso de parámetros.

[ 286 ]
Capítulo 12

El espacio de trabajo después del aprovisionamiento se muestra en la figura


siguiente:

Haga clic en la sección del Portal de OMS para abrir el portal del área de trabajo.
Este portal se utiliza para ver toda la información de telemetría capturada por
la información operativa, la configuración de esta última y el ofrecimiento de
funcionalidades y características del panel de control.

[ 287 ]
Supervisión y auditoría

La pantalla de inicio de la información operativa se muestra a continuación:

La sección de Configuraciones muestra que cuatro fuentes de datos están


conectadas. Estas son cuatro máquinas virtuales conectadas al espacio de trabajo de
OMS del entorno de prueba y producción. Se puede adoptar una estrategia diferente
que consiste en tener un espacio de trabajo separado para cada entorno y dejar que
los lectores decidan lo mejor para sus aplicaciones y soluciones. La información
operativa se puede configurar mediante el ícono de configuración:

[ 288 ]
Capítulo 12

Agentes OMS
Quizás haya notado que no se realiza ningún cambio de ensamblaje o código en la
aplicación para consumir información operativa. La información operativa depende
de la instalación de un agente en máquinas virtuales. Dichos agentes continúan
recopilando datos de telemetría provenientes de estos hosts y siguen enviándolos
al espacio de trabajo de información operativa de Azure donde se almacenan
durante un período determinado de tiempo según la sku seleccionada. Estos
agentes se pueden instalar manualmente en máquinas virtuales. Las extensiones
de máquinas virtuales de administración de recursos de Azure instalan agentes de
forma automática, inmediatamente después de aprovisionar las máquinas virtuales.
El código JSON para el aprovisionamiento de un agente en una máquina virtual
se muestra en el siguiente código:
{
"apiVersion": "2015-06-15",
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(variables('vmName'),copyIndex(1),'/
omsscript')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/',variables('vmNam
e'),copyIndex(1))]",
"[resourceId('Microsoft.Compute/virtualMachines/extensions',
concat(variables('vmName'),copyIndex(1)),'powershellscript')]"
],
"copy": {
"count": "[parameters('countVMs')]",
"name": "omsloop"
},
"properties": {
"publisher": "Microsoft.EnterpriseCloud.Monitoring",
"type": "MicrosoftMonitoringAgent",
"typeHandlerVersion": "1.0",
"settings": {
"workspaceId": "[parameters('WorkspaceID')]"
},
"protectedSettings": {
"workspaceKey": "[listKeys(variables('accountid'),'2015-11-
01-preview').primarySharedKey]"
}
}
}

[ 289 ]
Supervisión y auditoría

El ID del espacio de trabajo y de la cuenta están disponibles desde el ícono de


configuración del espacio de trabajo de OMS, y el elemento de copia se utiliza para
implementarlos en varias máquinas virtuales. Este es un recurso secundario del
recurso de máquina virtual lo que asegura que esta extensión se ejecute cada vez que
una máquina virtual se aprovisiona o actualizada.
La configuración relacionada con el ID del espacio de trabajo y de la cuenta se
muestra a continuación. La clave principal se utiliza como el ID de la cuenta para
configurar los agentes mediante el uso de plantillas de ARM:

Búsqueda
El espacio de trabajo de OMS ofrece capacidades de búsqueda para rastrear entradas
del registro específicas, exportar todos los datos de telemetría a Excel o Power BI
y buscar el lenguaje específico de OMS.

[ 290 ]
Capítulo 12

Una pantalla de búsqueda de registros se muestra a continuación:

Soluciones
Las soluciones de OMS son capacidades adicionales que pueden agregarse al espacio
de trabajo y, así, capturar los datos de telemetría adicionales que no se capturan por
defecto. Cuando estas soluciones se agregan al espacio de trabajo, los paquetes de
administración correspondientes se envían a todos los agentes conectados al espacio
de trabajo en el contexto de su propia configuración para capturar datos específicos
de solución provenientes de máquinas virtuales y contenedores, y luego comenzar
a enviar esos datos al espacio de trabajo OMS.

[ 291 ]
Supervisión y auditoría

La captura de pantalla a continuación muestra la galería de soluciones, y las


soluciones de capacidad y rendimiento en el espacio de trabajo de OMS. Si hace
clic en cualquier solución y luego en el botón Agregar, se agregará la solución en
contexto para el espacio de trabajo:

Azure proporciona muchas soluciones de OMS para realizar el seguimiento


y supervisar diferentes aspectos de entornos y aplicaciones. Como mínimo, se tiene
que agregar al espacio de trabajo un conjunto de soluciones que sean genéricas
y aplicables a casi cualquier entorno. 
• Capacidad y rendimiento
• Estado del agente
• Seguimiento de cambios
• Contenedores
• Seguridad y auditorías
• Administración de actualizaciones
• Supervisión de rendimiento de red

Alertas
El análisis de registros aprovisiona para generar alertas sobre los datos consumidos.
Lo hace mediante la ejecución de una consulta predefinida formada por condiciones
sobre los datos entrantes. Si encuentra algún registro o grupo de registros que está
dentro del ámbito de dicha consulta, genera una alerta. El análisis de registros
ofrece un entorno altamente configurable para determinar las condiciones para la
generación de alertas, las ventanas de tiempo desde donde la consulta tendría que
devolver los registros, las ventanas de tiempo cuando tendría que ejecutarse la
consulta y la acción que se realizará cuando la consulta devuelva los resultados como
alertas:

[ 292 ]
Capítulo 12

El primer paso para configurar una alerta es crear una búsqueda guardada.
Una búsqueda guardada es simplemente una consulta de búsqueda contra el
análisis del registro:

[ 293 ]
Supervisión y auditoría

Nombre la consulta para guardarla. Una vez guardada, haga clic en el botón


de alerta del menú de búsqueda de registros. Proporciona al usuario una interfaz
para definir y agregar una regla de alerta nueva:

Dentro de la pantalla individual, se pueden realizar todas las configuraciones


relacionadas con una regla de alerta. Proporciónele un nombre, una descripción,
una severidad y una consulta para que se ejecute como parte de la evaluación de
la regla dentro de su respectivo campo.
La ventana de tiempo ayuda a especificar el intervalo de datos en el que se tiene que
ejecutar la consulta. A partir de la captura de pantalla dada, siempre que la regla se
ejecuta, procesa los datos de los últimos 15 minutos. 
La sección de programación ayuda a configurar la frecuencia de ejecución
de la regla. Ayuda a contestar la pregunta “¿con qué frecuencia se tiene que
ejecutar la consulta?”. A partir de la captura de pantalla dada, la regla se ejecuta
cada 15 minutos. La ventana de tiempo tiene que ser superior a la frecuencia
de alerta. Las alertas pueden configurarse más según el número de resultados
encontrados. No es necesario que se genere una alarma para cada instancia de datos
encontrados según la consulta.

[ 294 ]
Capítulo 12

Puede cuantificarse aún más para acumular una determinada cantidad de resultados
antes de presentar las solicitudes. Las alertas se pueden generar también según
medidas métricas. Se puede llevar a cabo una configuración adicional para eliminar
las alertas. Ayuda a crear un intervalo de tiempo que tiene que transcurrir antes
de ejecutar la acción. En este caso, se generan alertas pero solo se realiza la acción
después del intervalo transcurrido y configurado.
La sección de acciones ayuda en el aspecto de la configuración de las cosas que
tienen que seguir una alerta. Generalmente, tiene que haber una acción correctiva
o de notificación. El análisis de registros ofrece cuatro maneras diferentes de crear
una acción nueva. Se pueden combinar de cualquier forma. Una alerta ejecutará
todas las acciones configuradas:
• Notificación de correo electrónico: este es el más simple y envía un correo
electrónico a los destinatarios configurados:

[ 295 ]
Supervisión y auditoría

• Webhook: Webhook ayuda en la ejecución de cualquier proceso externo


arbitrario mediante un mecanismo de HTTP POST. Por ejemplo, se puede
ejecutar API REST o se puede recurrir a las API del administrador de
servicios/ServiceNow para crear un ticket:

• Runbooks: esta acción ejecuta los runbooks de automatización de Azure.


En la siguiente sección, veremos todo el proceso de ejecución de un runbook
de automatización de Azure.
• Acciones de la integración de administración de servicios de TI (ITSM):
las soluciones de ITSM tienen que aprovisionarse antes de usar esta opción.
Ayuda a conectar y enviar información a los sistemas de ITSM.

La ejecución de runbooks en alertas


Una de las acciones proporcionadas por una alerta de análisis de registros es ejecutar
el runbook de automatización de Azure. Esta facilidad de ejecución de runbooks en
una alerta proporciona un inmenso poder para actuar sobre esta a fin de repararla
y también informar a las partes interesadas pertinentes mediante notificaciones.

[ 296 ]
Capítulo 12

1. El primer paso en la ejecución de un runbook en respuesta a una alerta,


es crear una cuenta de Azure Automation:

[ 297 ]
Supervisión y auditoría

2. Después de aprovisionar la cuenta, cree un runbook solo para demostrar


que se puede ejecutar en el marco de generación de alertas. En este caso,
el runbook envía un correo electrónico como parte de la notificación.
Utiliza las credenciales de automatización de Azure para enviar un correo
electrónico mediante el servidor SMTP de Office 365. Los usuarios tienen que
tener una cuenta válida de Office 365 antes de enviar el correo electrónico
que utiliza la automatización de Azure:

3. Es necesario tener en cuenta que se trata solo de una demostración.


El runbook también puede aceptar alertas de parámetros y análisis de
registros, y enviar un único parámetro del tipo de objeto. Este parámetro
contiene todos los datos correspondientes a la fuente de la alerta, los detalles
sobre la alerta y la información disponible con el análisis de registros:

[ 298 ]
Capítulo 12

4. Los datos están en formato JSON, y se puede utilizar un cmdlet


ConvertFrom-JSON para crear objetos de PowerShell.
5. El siguiente paso es configurar el análisis de registros de forma tal que pueda
conectarse a la cuenta de automatización de Azure. Para ello, se tiene que
activar e implementar una solución Automation & Control:

[ 299 ]
Supervisión y auditoría

6. La ventana de la  Galería de soluciones: hacer clic en este ícono lo llevará a


la ventana de configuración. Haga clic en Configurar espacio de trabajo para
implementar la solución:

[ 300 ]
Capítulo 12

7. Seleccione la cuenta de Azure Automation que acaba de crear como parte de


la implementación de la solución:

[ 301 ]
Supervisión y auditoría

8. Luego de implementar la solución, diríjase a la ventana de configuración


dentro del espacio de trabajo del análisis de registros y asegúrese de que las
configuraciones de automatización de Azure muestren los detalles sobre la
cuenta de Azure Automation. Esto garantiza que el espacio de trabajo del
análisis de registros esté conectado a la cuenta de Azure Automation:

9. Ahora el runbook tendría que estar disponible mientras configura el runbook


de acción de alerta:

[ 302 ]
Capítulo 12

Integración de Power BI
Recopilar datos y almacenarlos en un repositorio central es un aspecto importante.
Sin embargo, tendría que haber herramientas y utilidades para procesar los datos
y generar información a partir de ellos. Power BI es un servicio que brinda Microsoft,
destinado específicamente a visualizar y generar información a partir de datos sin
procesar.
Power BI puede activarse mediante el menú de Configuraciones del mismo modo
que la configuración para la automatización de Azure. La conexión a Power BI
tiene que hacerse desde el menú de Configuraciones. Una vez que se realiza esta
conexión, se puede utilizar para enviar los datos del análisis de registros a Power BI.
El análisis de registros proporciona dos maneras diferentes de interactuar con
Power BI. Primero, tiene que activarse desde el menú de Configuraciones.
Al igual que con las alertas, la opción del menú de Power BI se encuentra disponible
desde el menú de nivel superior de búsqueda de registros. Hacer clic en este menú
ayuda a configurar la conectividad de Power BI. Se ejecuta un programador
periódicamente para realizar consultas de búsqueda y enviar los datos resultantes
a Power BI. Los datos se almacenan como conjuntos de datos en Power BI y se
pueden usar para generar gráficos, informes y paneles de control:

Otra forma de pasar datos a Power BI desde el análisis de registros es utilizar el


lenguaje de Power Query que se encuentra en Power BI. Esto se muestra aquí. Esto es
construir un andamiaje para el código proporcionado por el análisis de registros.
El lenguaje de fórmulas de Power Query (lenguaje M) exportado puede
utilizarse con Power Query en Excel de Microsoft y Power BI Desktop.

[ 303 ]
Supervisión y auditoría

Para Power BI Desktop siga las instrucciones a continuación:


1. Descargue Power BI Desktop desde https://powerbi.microsoft.com/es-
es/desktop/.
2. En Power BI Desktop, seleccione Obtener datos | Consulta vacía |
Edición avanzada de consultas.
3. Pegue el script del lenguaje M en la Edición avanzada de consultas
y seleccione Listo. Esto causará que se ejecute la consulta y traerá los datos
de OMS a Power BI. Proporcione un nombre y agregue un conjunto de
datos nuevo haciendo clic en Aplicar y en el botón Cerrar en la edición de
consultas de Power BI:
let AnalyticsQuery =
let Source = Json.Document(Web.Contents("https://management.
azure.com/subscriptions/9755ffce-e94b-4332-9be8-1ade15e78909/
resourceGroups/omsauto/providers/Microsoft.OperationalInsights/
workspaces/data centermonitoring/api/query?api-version=2017-01-01-
preview",
[Query=[#"query"="search * | where ( Type == ""Event"" )
",#"x-ms-app"="OmsAnalyticsPBI",#"timespan"="PT24H",#"prefer"="ai.
response-thinning=true"],Timeout=#duration(0,0,4,0)])),
TypeMap = #table(
{ "AnalyticsTypes", "Type" },
{
{ "string", Text.Type },
{ "int", Int32.Type },
{ "long", Int64.Type },
{ "real", Double.Type },
{ "timespan", Duration.Type },
{ "datetime", DateTimeZone.Type },
{ "bool", Logical.Type },
{ "guid", Text.Type }
}),
DataTable = Source[tables]{0},
Columns = Table.FromRecords(DataTable[columns]),
ColumnsWithType = Table.Join(Columns, {"type"}, TypeMap ,
{"AnalyticsTypes"}),
Rows = Table.FromRows(DataTable[rows], Columns[name]),
Table = Table.TransformColumnTypes(Rows, Table.
ToList(ColumnsWithType, (c => { c{0}, c{3}}))
in
Table
in AnalyticsQuery

[ 304 ]
Capítulo 12

Resumen
La supervisión es un aspecto importante de la arquitectura para cualquier solución.
También es el primer paso hacia la capacidad de auditoría. Permite a las operaciones
administrar la solución reactiva y proactivamente. Ayuda a proporcionar los
registros necesarios para la solución de problemas y la resolución de inconvenientes
que puedan surgir en las plataformas y aplicaciones. Existen muchos recursos en
Azure para implementar específicamente la supervisión de Azure, otras nubes
y centros de datos locales. La información de aplicaciones, OMS y el análisis de
registros son algunos de los recursos importantes en este contexto. Evidentemente,
son indispensables para mejorar sus soluciones y productos mediante la innovación
basada en la información obtenida en la supervisión de datos.

[ 305 ]