01 Documentación de Microsoft Cloud Adoption Framework para Azure

Contents
Cloud Adoption Framework para Azure

Acerca del marco
Novedades
Recorridos de adopción
Introducción
Información general
Alineación operativa
Documentación de las decisiones de alineación operativa
¿Cómo funciona Azure?
Conceptos básicos de Azure
Jerarquía de la cartera
Respaldo de la jerarquía de Azure
Agilización de la adopción
Aceleración de la migración
Creación de productos y servicios
Desbloqueo del diseño y la configuración del entorno
Mejora de los controles
Permitir el éxito de los clientes
Entrega en la excelencia operacional
Administración de los costos de la nube
Protección del entorno empresarial
Mejora de la confiabilidad
Garantía de rendimiento coherente
Establecimiento de equipos
Alineación de la organización
Creación de un equipo de estrategia de la nube
Creación de un equipo de adopción de la nube
Creación de un equipo de gobernanza de la nube
Creación de un equipo de operaciones de la nube
Escenarios de adopción
Híbrido y multinube
Contenedores modernos
SAP
Antipatrones que se deben evitar
Estrategia
Motivaciones
Resultados empresariales
Innovación en los datos
Democratización de datos
Resultados fiscales
Resultados de agilidad
Resultados de cobertura global
Resultados de la involucración del usuario
Resultados de rendimiento
Resultados de sostenibilidad
Plantilla de resultados empresariales
Alineación de esfuerzos en las métricas de aprendizaje
Objetivos y resultados clave
Justificación comercial
Creación de una justificación comercial
Creación de un modelo financiero
Descripción de la contabilidad en la nube
Alineación de la estrategia de asociados
Primer proyecto de adopción de la nube
Consideraciones adicionales
Equilibrio de prioridades en la competencia
Conciliar la cartera
Mercados globales
Definición de la estrategia de seguridad
Definición de la estrategia de supervisión
Inteligencia artificial responsable
Aceleración de la adopción de la nube con GitHub
Aptitudes pertinentes para la estrategia
Antipatrones de estrategia
Plan
Patrimonio digital
Las cinco "R" de la racionalización
¿Qué es un patrimonio digital?
Planificación del patrimonio digital
Recopilación de datos de inventario
Racionalización del patrimonio digital
Alineación de los modelos de costo para predecir los costos
Medición de resultados empresariales con AppDynamics
Alineación inicial de la organización
Plan de preparación de las aptitudes
Creación de un plan de preparación
Asignación de roles y aptitudes
Plan de adopción de la nube
Requisitos previos
Implementación de la plantilla en Azure DevOps
Definición y clasificación de las cargas de trabajo
Adaptación de los recursos a las cargas de trabajo
Revisión de las decisiones de racionalización
Establecimiento de iteraciones y planes de versiones
Estimación de escalas de tiempo
Procedimientos recomendados
Evaluación del patrimonio digital en Azure
Planeamiento de una migración de almacén de datos
Planeamiento de antipatrones
Ready
Guía de instalación de Azure
Introducción a la guía de instalación
Organización de recursos
Administración del acceso
Administración de los costos y la facturación
Planeación de la gobernanza, seguridad y cumplimiento
Establecimiento de la supervisión y los informes
Mantenerse al día con Azure
Modelo operativo
Definición de un modelo operativo
Comparación de los modelos operativos en la nube más habituales
Términos comunes de los modelos operativos
Zonas de aterrizaje de Azure
¿Qué es una zona de aterrizaje?
Área de diseño
Elección de una opción de zona de aterrizaje
Opciones de implementación
Inicio a escala empresarial
Implementación de zonas de aterrizaje de escala empresarial
Architecture
Principios de diseño
Guías de diseño
Áreas de diseño críticas
Inscripción empresarial e inquilinos de Azure AD
Administración de identidades y acceso
Organización de grupos de administración y suscripciones
Topología de red y conectividad
Planeamiento del direccionamiento IP
DNS para recursos locales y de Azure
Integración de Private Link y DNS a gran escala
Definición de una topología de red de Azure
Topología de red de Virtual WAN (administrada por Microsoft)
Topología tradicional de redes de Azure
Conectividad a Azure
Conectividad con servicios PaaS de Azure
Planeamiento de la conectividad de Internet entrante y saliente
Planeamiento de la entrega de aplicaciones
Planeamiento de la segmentación de la red de zona de aterrizaje
Definición de los requisitos de cifrado de red
Planeamiento de la inspección del tráfico
Conectividad con otros proveedores de nube
Administración y supervisión
Continuidad empresarial y recuperación ante desastres
Seguridad, gobernanza y cumplimiento
Automatización de la plataforma y DevOps
Guías de implementación
Módulo de Terraform para la escala empresarial de CAF
Transición a escala empresarial (Brownfield)
Inicio a pequeña escala y expansión
Plano técnico de la zona de aterrizaje de la migración de CAF
Plano técnico de Fundación CAF
Zonas de aterrizaje de Terraform
Expansión de una zona de aterrizaje
Consideraciones básicas sobre la zona de aterrizaje
Revisión de opciones de proceso
Revisión de opciones de redes
Revisión de opciones de almacenamiento
Revisión de opciones de datos
Control de acceso basado en roles de Azure
Creación de coherencia en la nube híbrida
Mejora de las operaciones en la zona de aterrizaje
Mejora de la gobernanza de la zona de aterrizaje
Mejora de la seguridad en la zona de aterrizaje
Incorporación de una suscripción a Azure Security Center
Incorporación de Azure Sentinel
Implementación de una arquitectura de red híbrida segura en Azure
Procedimientos recomendados de seguridad para la administración de
identidades y el control de acceso en Azure
Procedimientos recomendados de Azure Network Security
Procedimientos recomendados de seguridad operativa de Azure
Zonas de aterrizaje de asociado
Teoría de infraestructura como código
Refactorización de zonas de aterrizaje
Desarrollo controlado por pruebas (TDD) de las zonas de aterrizaje
Desarrollo controlado por pruebas de zonas de aterrizaje en Azure
Creación de las suscripciones iniciales
Escalado con varias suscripciones
Organización de las suscripciones
Nomenclatura y etiquetado
Definición de su convención de nomenclatura
Abreviaturas de los tipos de recursos
Definición de la estrategia de etiquetado
Traslado de recursos
Redes
Seguridad en los límites de la red
Planear redes virtuales
Procedimientos recomendados de seguridad de la red
Redes perimetrales
Topología de red en estrella tipo hub-and-spoke
Controles de identidades y de acceso
Procedimientos recomendados de administración de identidades
Protección del acceso con privilegios
Elección de un método de autenticación
Storage
Guía de seguridad de Storage
Bases de datos
Procedimientos recomendados sobre la seguridad de las bases de datos
Elección de una opción de implementación en Azure SQL
AI + Aprendizaje automático
Organización y configuración de entornos de Azure Machine Learning
Administración de costos
Seguimiento de costos
Optimización de la inversión en la nube
Creación y administración de presupuestos
Exportación de datos de costos
Optimización de los costos a partir de las recomendaciones
Supervisión del uso y del gasto
Aptitudes pertinentes para las zonas de aterrizaje y preparación
Antipatrones preparados
Adoptar
Migrar
Guía de migración a Azure
Introducción a la guía de migración
Evaluación de cargas de trabajo
Implementación de cargas de trabajo
Lanzamiento de cargas de trabajo
Mecanismos de control de costos centrados en la migración
Obtención de ayuda
Escenarios de migración
Información general de Contoso
Cargas de trabajo de Windows Server
Rehospedaje de una aplicación Windows en máquinas virtuales de Azure
Cargas de trabajo de SQL Server
Migración de bases de datos de SQL Server en Azure
Rehospedaje de una aplicación en las máquinas virtuales de Azure y en Azure
SQL Managed Instance
Rehospedaje de una aplicación en VM de Azure y en los Grupos de
disponibilidad Always On de SQL Server
Migración de almacenamiento
Información general sobre la migración del almacenamiento
Herramientas para la migración de almacenamiento no estructurado
Bases de datos Linux y de código abierto
Migración de bases de datos de código abierto a Azure
Migración de MySQL a Azure
Migración de PostgreSQL a Azure
Migración de MariaDB a Azure
rehospedaje de una aplicación Linux en máquinas virtuales de Azure
Rehospedaje de una aplicación de Linux en VM de Azure y Azure Database for
MySQL
Plataformas de código abierto
Migración de Moodle
Preparación para la migración de Moodle
Arquitectura y plantilla
Recursos de migración de Moodle
Pasos de migración
Configuración de nodos de trabajo de Moodle
Seguimiento de la migración de Moodle
Cargas de trabajo de desarrollo/pruebas
Migración de entornos de desarrollo/pruebas a IaaS de Azure
Migración a Azure DevTest Labs
Aplicaciones web de ASP.NET y PHP
Refactorización de una aplicación de Windows en App Service y Azure
SQL Database
Refactorización de una aplicación de Windows en App Service y SQL Managed
Instance
Refactorización de una aplicación de Linux en App Service y MySQL
Recompilar una aplicación en Azure
Refactorización de TFS a Azure DevOps Services
Aplicaciones de Java
Información general sobre la migración
Spring Boot a Azure App Service
Spring Boot a AKS
Spring Boot a Azure Spring Cloud
Spring Cloud a Azure Spring Cloud
Tomcat a Azure App Service
Tomcat a contenedores en AKS
Tomcat a Azure Spring Cloud
WebLogic a Azure
WebLogic a Azure Virtual Machines
WebLogic con AAD a través de LDAP
WebLogic con App Gateway
WildFly a WildFly en AKS
WebLogic a WildFly en AKS
WebSphere a WildFly en AKS
JBoss EAP a WildFly en AKS
SAP
Guía de migración de SAP
Migración de aplicaciones de SAP a Azure
Metodologías de migración para SAP en Azure
Cargas de trabajo especializadas
Traslado de la infraestructura de VMware local a Azure
Azure NetApp Files
Oracle en Azure
Cray en Azure
VDI
Hosts de VMware
Consideraciones al volver a hospedar VMware
Requisitos previos
Protección del entorno
Administración de la nube privada
Redes de la nube privada
Plataforma de VMware
Integración del núcleo de Azure
Opciones de rehospedaje y recuperación ante desastres
Rehospedaje de las máquinas virtuales de la carga de trabajo en vCenter de la
nube privada
Rehospedaje de datos mediante Azure Data Box
Copia de seguridad de las máquinas virtuales de la carga de trabajo
Configuración de la nube privada de CloudSimple como sitio de recuperación
ante desastres mediante Zerto
Configuración de la nube privada de CloudSimple como sitio de recuperación
ante desastres mediante SRM de VMware
Windows Virtual Desktop
Planificación
Revisión de una zona de aterrizaje de Azure
Prueba de concepto
Evaluar
Migración (o implementación)
Release
Plataformas de datos
Guía de Azure Database Migration
Refactorización de SQL Server a Azure SQL Database
Refactorización de SQL Server en Azure SQL Managed Instance
Refactorización de SQL Server a SQL Server en máquinas virtuales de Azure
Refactorización de SQL Server a Azure SQL Data Warehouse
MySQL
PostgreSQL
MariaDB
MongoDB
Cassandra
Oracle
DB2
ASE de SAP
Acceso
Tutoriales de Azure Database Migration Service (DMS)
Introducción a Azure Database Migration Service
Migración de SQL Server a Azure SQL Database sin conexión
Migración de SQL Server a Azure SQL Database en línea
Migración de SQL Server a Azure SQL Managed Instance sin conexión
Migración de SQL Server a Azure SQL Managed Instance en línea
Migración de Amazon RDS SQL Server a Azure SQL Database o a Azure SQL
Managed Instance en línea
Migración de MySQL a Azure Database for MySQL en línea
Migración de Amazon RDS MySQL a Azure Database for MySQL en línea
Migración de PostgreSQL a Azure Database for PostgreSQL en línea
Migración de Amazon RDS PostgreSQL a Azure Database for PostgreSQL en
línea
Migración de MongoDB a la API de Azure Cosmos DB para MongoDB sin
conexión
Migración de MongoDB a la API de Azure Cosmos DB para MongoDB en línea
Migración de Oracle a Azure Database for PostgreSQL en línea
Azure Stack
Planificación
Revisión de una zona de aterrizaje de Azure
Evaluar
Migración (o implementación)
Control
Administrar
Soluciones de análisis
Teradata
Netezza
Exadata
Migración multiinquilino
Azure Lighthouse para la migración a escala
Sistemas centrales
Mitos y verdades
Cambio de sistemas centrales a Azure
Migración de aplicaciones del sistema central
Migración de cargas de trabajo seguras
Proteger y administrar cargas de trabajo después de la migración
Procedimientos recomendados para la seguridad de las bases de datos de Azure
Procedimientos recomendados de cifrado y seguridad de datos en Azure
Procedimientos recomendados para PaaS de Azure
Procedimientos recomendados de seguridad de Azure Service Fabric
Procedimientos recomendados de seguridad para las máquinas virtuales de
Azure
Procedimientos recomendados para la seguridad de IoT
Protección de bases de datos de PaaS en Azure
Protección de aplicaciones web y móviles PaaS con Azure App Service
Protección de aplicaciones web y móviles PaaS con Azure Storage
Procedimientos de seguridad recomendados para cargas de trabajo de IaaS de
Azure
Varios centros de datos
Varias regiones
Los requisitos de datos superan la capacidad de la red
Configurar redes para las cargas de trabajo migradas
Implementación de una infraestructura de migración
Optimización del costo de las cargas de trabajo migradas
Escalar una migración
Lenguajes de definición de datos para migración de esquemas
Alta disponibilidad para Azure Synapse
Gobernanza o cumplimiento
Migración de antipatrones
Mejora de procesos
Requisitos previos
Decisiones que afectan a la migración
Lista de comprobación de planeación del entorno
Alinear roles y responsabilidades
Administración de cambios ágil
Revisión del trabajo pendiente de migración
Evaluación de cargas de trabajo
Validación de las suposiciones de evaluación antes de la migración
Clasificación de cargas de trabajo
Mantener las prioridades alineadas
Evaluación de la disponibilidad de las cargas de trabajo
Diseño de cargas de trabajo
Actualización y perfeccionamiento de las estimaciones iniciales de la nube
Descripción de las opciones de colaboración
Administración de cambios
Aprobación de cambios arquitectónicos
Modelos promocionales
Corrección de recursos
Replicación de recursos
Replicación de opciones
Agregar al "stage" cargas de trabajo
Plan de cambio de negocio
Pruebas empresariales
Pruebas comparativas y ajuste de tamaño de recursos
Preparación para la promoción
Promoción a producción
Retirar activos retirados
Realización de retrospectivas
Aptitudes pertinentes para una migración
Innovación
Guía de innovación de Azure
Introducción a la guía de innovación
Preparación para los comentarios de los clientes
Democratización de los datos
Interacción con los clientes mediante aplicaciones
Capacitación para la adopción
Interacción a través de dispositivos
Innovación con IA
Escenarios de innovación
Kubernetes
Innovación con Kubernetes
Desarrollo e implementación de aplicaciones
Diseño y operaciones de clústeres
Seguridad de clústeres y aplicaciones
Inteligencia artificial
Innovación con IA
Machine Learning
Aplicaciones y agentes de inteligencia artificial
Minería de conocimientos
Introducción y cadena de herramientas de Azure
Uso compartido de datos con expertos
Generación rápida de conclusiones a partir de datos
Uso compartido de datos con compañeros de trabajo y asociados
Inserción de informes en un sitio web o portal
Creación de nuevas áreas de trabajo en Power BI
Gobernanza de los datos
Clasificación de los datos
Protección de datos
Anotación de datos con Data Catalog
Orígenes de datos de documentos con Data Catalog
Centralización de los datos
Creación y consulta de un grupo de SQL de Azure Synapse Analytics
Procedimientos recomendados para la carga de datos en almacenamientos de
datos
Visualización de los datos del almacén con Power BI
Arquitectura de referencia para BI empresarial con Azure Synapse Analytics
Administración de macrodatos empresariales con Azure Data Lake Storage
¿Qué es un lago de datos?
Recopilación de datos
Migración de datos locales a Azure desde las plataformas SQL, Oracle o
NoSQL
Integración de orígenes de datos en la nube con un almacenamiento de datos
de SQL Analytics
Carga de datos locales en Azure Synapse Analytics
Integración de datos: Azure Data Factory con OLAP
Uso de Azure Stream Analytics con Azure Synapse Analytics
Arquitectura de referencia para la ingesta y el análisis de nuevas fuentes
Carga de datos en un grupo de SQL de Azure Synapse Analytics
Participación mediante aplicaciones
Desarrolladores cívicos
Introducción a Power Apps
Creación de aplicaciones en Power Apps
Creación del primer flujo de trabajo con Power Automate
Uso de AI Builder
Cumplimiento y privacidad de datos para soluciones de desarrolladores cívicos
Directivas de prevención de pérdida de datos para soluciones de
desarrolladores cívicos
Experiencias inteligentes
Aplicaciones web modernas
Incorporación de inteligencia
Bots de chat
Aplicaciones nativas de la nube
Arquitectura de microservicios
Contenedores
Microservicios de Spring Boot
Aplicaciones controladas por eventos
Solución compartida
Introducción a un repositorio compartido: GitHub y Git
Introducción a un trabajo pendiente compartido
Sincronización de Power Apps con Azure DevOps
Bucles de comentarios
Administración de comentarios con Azure DevOps
Integración continua
Integración continua con Azure Pipelines y GitHub
MLOps con Azure Machine Learning
Pruebas confiables
Administración y seguimiento de los planes de pruebas
Implementación de la solución
Implementación continua con Azure Pipelines y GitHub
Métricas integradas
Supervisión de aplicaciones ASP.NET
Supervisión de aplicaciones web de ASP.NET Core
Supervisión de aplicaciones Node.js
Supervisión de aplicaciones móviles
Supervisión de aplicaciones web
Supervisión de máquinas virtuales que hospedan aplicaciones tradicionales
Interacción con dispositivos
Experiencia móvil
Extensión de una aplicación de procesamiento de notificaciones heredada con
una experiencia web y móvil
Optimización de informes para compartir datos en una aplicación móvil
Extensión de la aplicación de lienzo de PowerApps a una experiencia móvil
Extensión de Power Automate para agregar una experiencia móvil
Protección de experiencias móviles
Realidad mixta
Desarrollo de experiencias de realidad mixta con Unity
Guías de inicio rápido para agregar Azure Spatial Anchors a una solución de
realidad mixta
Realidad integrada e IoT
Visualización de datos de sensor con Azure IoT en Power BI
Visualización de datos de sensor con Azure IoT Hub en una solución web
Protección de una solución de IoT
Introducción a Azure Sphere
Creación de una implementación con Azure Sphere
Introducción a Azure Kinect DK
Creación de la primera aplicación de Azure Kinect DK
Realidad ajustada
Azure Digital Twins + HoloLens: ajuste de la realidad virtual
Introducción a Azure Digital Twins
Supervisión de un edificio con Azure Digital Twins
Guía de Azure IoT para comunicaciones de la nube al dispositivo
Configuración de Azure IoT para comunicaciones de la nube al dispositivo
Innovación con IA
Machine Learning
¿Qué es el aprendizaje automático?
Procedimientos de enfocar las operaciones de aprendizaje automático
El proceso de las operaciones de aprendizaje automático
Seguridad de Machine Learning
Inferencia e implementación de Machine Learning
Determinar las instancias de proceso de un modelo
Configuración de las áreas de trabajo de Machine Learning
Inteligencia artificial de confianza y responsable
¿Qué son las aplicaciones de inteligencia artificial?
¿Qué son los agentes de inteligencia artificial?
¿Qué es Azure Cognitive Search?
Mejora de procesos
Consenso del valor empresarial
Adopción del cliente
Creación con la empatía de los clientes
Medida del impacto en los clientes
Aprendizaje con los clientes
Desafíos y factores de bloqueo de los clientes
Invención digital
Desarrollo de invenciones digitales
Desarrollo de aplicaciones innovadoras
Predicción e influencia
Control
Metodología
Prueba comparativa
Base de gobernanza inicial
Mejoras de la base de gobernanza
Guías de gobernanza
Guía de gobernanza para empresas estándar
Narración
Directiva corporativa inicial
Guías prescriptivas
Mejora de la materia de base de referencia de la seguridad
Mejora de la materia de coherencia de los recursos
Mejora de la materia de Cost Management
Escenarios de nube múltiple
Guía de gobernanza para empresas complejas
Narración
Directiva corporativa inicial
Guías prescriptivas
Mejora de la materia de línea de base de identidad
Varias capas de gobernanza
Consideraciones de gobernanza
Evaluación de la directiva corporativa
Directiva y cumplimiento normativo corporativos preparados para la nube
Preparar la directiva corporativa para la nube
Descripción de los riesgos empresariales
Evaluación de la tolerancia al riesgo
Definición de la directiva corporativa
Alineación del diseño con las directivas
Establecimiento de procesos de adhesión a directivas
Implementación de controles del servicio en la nube
Cumplimiento de normativas
Preparación de la seguridad en la nube
Revisión de la directiva en la nube
Clasificación de datos
Materias de gobernanza en la nube
Implementación de materias de la gobernanza en la nube
Introducción a la administración de costos
Descarga de la plantilla
Métricas e indicadores de tolerancia al riesgo
Directivas de Cost Management de ejemplo
Procesos de cumplimiento de directivas
Mejora de la administración de costos
Herramientas de administración de costos de Azure
Línea de base de seguridad
Introducción a la línea de base de seguridad
Directivas de base de referencia de seguridad de ejemplo
Introducción a la línea de base de seguridad
Línea de base de seguridad nativa en la nube
Guía de seguridad adicional de Azure
Herramientas de línea base de seguridad de Azure
Línea de base de identidad
Introducción a la línea de base de identidad
Directivas de base de referencia de identidad de ejemplo
Mejora de la línea de base de identidad
Herramientas de línea base de identidad de Azure
Coherencia de recursos
Introducción a la coherencia de recursos
Directivas de coherencia de recursos de ejemplo
Mejora de la coherencia de recursos
Herramientas de coherencia de recursos de Azure
Administración del acceso a recursos
Diseño de gobernanza para una carga de trabajo sencilla
Diseño de gobernanza para varios equipos
Aceleración de la implementación
Introducción a la aceleración de la implementación
Directivas de aceleración de la implementación de ejemplo
Mejora de la aceleración de la implementación
Herramientas de aceleración de la implementación de Azure
Gobernanza de antipatrones
Administración
Guía de administración de Azure
Antes de comenzar
Inventario y visibilidad
Cumplimiento operativo
Protección y recuperación
Línea de base mejorada
Especialización de la plataforma
Especialización de la carga de trabajo
Servicios de administración de servidores de Azure
Introducción sobre los servicios de administración de servidores de Azure
Preparación para las operaciones en la nube
Introducción a las operaciones de la nube
Configuración del servicio para una sola máquina virtual
Configuración del servicio para una suscripción completa
Configuración a escala con automatización
Configuración de alertas básicas
Operaciones en la nube en curso
Habilitar directiva de configuración de invitados
Cambios críticos (seguimiento y alertas)
Actualización de programaciones
Directivas habituales en Azure
Revisión de herramientas y servicios
Supervisión
Supervisión de modelos en la nube
Observabilidad
datos, recopilación
Alertas
Introducción a las plataformas de supervisión
Aptitudes pertinentes para la supervisión
Centralización de operaciones de administración
Establecimiento de una revisión de adecuación operativa
Mejora de la confiabilidad de plataforma o carga de trabajo
Lista de comprobación de confiabilidad para servicios de Azure
Análisis del modo de error
Recuperación de una interrupción del servicio en toda la región
Recuperación de daños o eliminación accidental de los datos
Consideraciones de administración
Alineación empresarial
Definición de la importancia crítica
Descripción del impacto empresarial
Establecimiento de compromisos empresariales
Disciplinas de administración
Inventario y visibilidad
Cumplimiento operativo
Operaciones de la plataforma
Operaciones con cargas de trabajo
Administración avanzada y diseño del sistema
Administración de antipatrones
Organizar
Administración de la alineación de la organización
Funciones de nube necesarias
Funciones de estrategia de la nube
Funciones de adopción de la nube
Funciones de gobernanza de la nube
Funciones de TI central
Operaciones y funciones de la nube
Funciones del centro de excelencia de la nube
Funciones de la plataforma de nube
Funciones de automatización de la nube
Funciones de datos en la nube
Funciones de seguridad en la nube
Funciones del equipo de seguridad de la nube
Directiva y estándares
Centro de operaciones de seguridad (SOC)
Arquitectura de seguridad
Administración del cumplimiento de la seguridad
Seguridad de las personas
Seguridad de las aplicaciones y DevSecOps
Seguridad de los datos
Infraestructura y seguridad de los puntos de conexión
Identidad y claves
Información sobre amenazas
Administración de la posición
Preparación para incidentes
Maduración de la estructura de los equipos
Alineación de la matriz RACI
Desarrollo de aptitudes técnicas
Creación de una organización con control de costos
Organización de antipatrones
Antipatrones de la organización
Feudos y silos de TI
Recursos
Herramientas y plantillas
Procedimientos recomendados de seguridad de Azure
Guías de decisión
Suscripciones
Identidad
Aplicación de directivas
Etiquetado de recursos
Cifrado
Redes definidas por software
solo PaaS
Nativo de la nube
Red perimetral en la nube
Híbrido
Modelo en estrella tipo hub-and-spoke
Registro e informes
Herramientas de migración
Recursos adicionales
Centro de arquitectura de Azure para la arquitectura de la solución
Marco de buena arquitectura de Microsoft Azure para la arquitectura de las cargas
de trabajo
Documentos para la implementación de productos
Aprendizaje para el desarrollo de habilidades
Valoraciones para una guía personalizada
Recursos archivados
Modelo de funcionamiento en la nube
Scaffold de Azure Enterprise
Centro de datos virtual (VDC)
¿Qué es Microsoft Cloud Adoption Framework para
Azure?
06/03/2021 • 8 minutes to read • Edit Online
Microsoft Cloud Adoption Framework para Azure es una guía probada que está diseñada para ayudarle a crear
e implementar las estrategias empresariales y tecnológicas necesarias para el éxito de su organización en la
nube. Proporciona procedimiento recomendado, documentación y herramientas que los arquitectos de la nube,
los profesionales de TI y los responsables de la toma de decisiones empresariales necesitan para lograr
objetivos a corto y largo plazo.
Al usar los procedimientos recomendados de Microsoft Cloud Adoption Framework para Azure, las
organizaciones pueden alinear mejor sus estrategias empresariales y técnicas para garantizar el éxito. Vea el
siguiente vídeo para obtener más información.
Cloud Adoption Framework reúne los procedimientos recomendados de adopción de la nube de los empleados,
asociados y clientes de Microsoft. Proporciona a los clientes un conjunto de herramientas, orientaciones y
documentos que ayudan a modelar la tecnología, el negocio y las estrategias de los usuarios para lograr los
resultados empresariales deseados durante su esfuerzo de adopción de la nube. Revise las instrucciones de cada
metodología a continuación, lo que le proporcionará un acceso sencillo a la guía adecuada en el momento
adecuado.
Estrategia: define la justifica Planeamiento: alinea los

ción empresarial y los planes de adopción viables
resultados que se esperan con los resultados
como resultado de la empresariales.
adopción.
Listo: Prepare el entorno en Migración: Migre y

la nube para los cambios modernice las cargas de
planeados. trabajo existentes.
Innovación: Desarrolle Control: Controle el

nuevas soluciones híbridas entorno y las cargas de
o nativas en la nube. trabajo.
Administración: Organizar: Alinee los

Administración de equipos y los roles que
operaciones para soluciones apoyan los esfuerzos de
en la nube e híbridas. adopción de la nube de la
organización.
Descripción del ciclo de vida

Cada metodología anterior forma parte de un amplio ciclo de vida de adopción de la nube. Cloud Adoption
Framework es el marco completo del ciclo de vida que presta apoyo a los clientes a lo largo de cada fase de la
adopción proporcionando metodologías como enfoques específicos para superar los bloqueos habituales, como
aquí se muestra.
Intención
La nube cambia fundamentalmente el modo en que las empresas adquieren, usan y protegen los recursos
tecnológicos. Tradicionalmente, las empresas asumían la propiedad y la responsabilidad de todos los aspectos
de la tecnología, desde la infraestructura al software. Al cambiar a la nube, las empresas pueden aprovisionar y
consumir recursos solo cuando es necesario. Aunque la nube ofrece una gran flexibilidad en términos de
opciones de diseño, las empresas necesitan una metodología probada y coherente para la adopción de
tecnologías en la nube. Microsoft Cloud Adoption Framework para Azure cumple con esa necesidad, ayudando a
la guía de decisiones a lo largo de la adopción de la nube.
Sin embargo, la adopción de la nube es solo un medio para lograr un fin. La correcta adopción de la nube
comienza mucho antes de que se seleccione un proveedor de plataforma en la nube. Comienza cuando los
responsables de la toma de decisiones en TI y del negocio se dan cuenta de que la nube puede acelerar un
objetivo específico de transformación del negocio. Cloud Adoption Framework ayuda a alinear las estrategias
del negocio, la cultura y el cambio técnico para lograr los resultados de negocio deseados.
Cloud Adoption Framework proporciona orientaciones técnicas para Microsoft Azure. Dado que existe la
posibilidad de que los clientes empresariales no hayan completado el proceso de elección de un proveedor de la
nube o que tengan una estrategia con varias nubes, el marco proporciona una guía independiente de la nube
para la toma de decisiones estratégicas, siempre que sea posible.
Destinatarios
Esta guía afecta al negocio, a la tecnología y a la cultura de las empresas. Los roles afectados incluyen los
responsables de línea de negocio, tomadores de decisiones de negocio, tomadores de decisiones de TI, finanzas,
administradores de empresa, operaciones de TI, seguridad y cumplimiento de TI, gobernanza de TI, propietarios
de desarrollo de cargas de trabajo y propietarios de operaciones de carga de trabajo. Cada rol usa su propio
vocabulario y cada uno tiene distintos objetivos e indicadores clave de rendimiento. Un único conjunto de
contenido no puede llegar a todas las audiencias eficazmente.
Arquitecto de la nube. El arquitecto de la nube sirve como líder de pensamiento y facilitador para reunir a estas
audiencias. Esta colección de guías está diseñada para ayudar a los arquitectos de la nube a facilitar las
conversaciones correctas, con la audiencia adecuada, y a impulsar la toma de decisiones. La transformación del
negocio potenciada por la nube depende del rol del arquitecto de la nube para ayudar a guiar las decisiones en
todo el negocio y en TI.
Cada una de las secciones de Cloud Adoption Framework representa una especialización o variante diferentes
del rol de arquitecto de la nube. Estas secciones también crean oportunidades para compartir las
responsabilidades del arquitecto de la nube entre un equipo de arquitectos de la nube. Por ejemplo, la sección
de gobernanza está diseñada para arquitectos de la nube con pasión por mitigar riesgos técnicos. Algunos
proveedores de servicios en la nube se refieren a estos especialistas como administradores de la nube, nosotros
preferimos el término protectores de la nube o, colectivamente, el equipo de gobernanza de la nube.
Uso de la Plataforma de adopción de la nube de Microsoft para Azure

Si su empresa es nueva en Azure, comience por comprender y documentar las decisiones de la alineación
básica. Cuando en la transformación digital de su empresa se ve involucrada la nube, comprender estos
conceptos fundamentales le ayudará durante cada paso del proceso.
Introducción
Novedades en Microsoft Cloud Adoption
Framework para Azure
Esta es una lista de los cambios recientes realizados en Cloud Adoption Framework.
Este marco de trabajo se ha creado de forma colaborativa con clientes, asociados y equipos internos de
Microsoft. Se publica contenido nuevo y actualizado cuando está disponible. Estas versiones le permiten probar,
validar y refinar la guía junto con nosotros. Le recomendamos que se asocie con nosotros en la creación del
Cloud Adoption Framework.
Marzo de 2021
Esta versión es la mayor actualización del marco de trabajo hecha hasta ahora y agrega una serie de nuevas
colecciones de guías de amplio alcance que abarcan todo el marco de trabajo.
Recorridos de adopción
Lo más destacado de esta versión es la incorporación de recorridos de adopción, que proporcionan una breve
superposición o lupa consumible que se sitúa por encima del marco más profundo para acelerar la interacción.
Estas guías más reducidas muestran cómo aplicar las guías de Cloud Adoption Framework, Microsoft Azure
Well-Architected Framework, el Centro de arquitectura de Azure, Microsoft Learn y otra documentación de
Microsoft para la adopción de plataformas tecnológicas específicas. En la tabla siguiente se proporcionan
vínculos a la página de información general de cada uno de estos nuevos recorridos:
JO URN EY DESC RIP C IÓ N
Escenarios híbridos y multinube Guía del ciclo de vida para integrar las operaciones híbridas,
multinube y unificadas en el recorrido de adopción de la
nube.
Contenedores modernos La modernización de los contenedores permite conseguir

una innovación rápida y la portabilidad de la carga de
trabajo. Aprenda a integrar los contenedores en el recorrido
de adopción de la nube.
SAP en Azure Como parte de nuestro compromiso OneMigrate

(escenarios de migración), este recorrido sirve de puente
entre el proceso de migración de SAP y otros procesos de
migración principales para ofrecer una adopción a escala
global de SAP en Azure.
Economía de la nube
Basándonos en los comentarios recibidos y las lecciones que hemos aprendido, este es el primer paso para
actualizar la metodología de estrategia mediante la integración del programa de economía de la nube de
Microsoft.
Hemos actualizado la introducción en cada categoría de resultados empresariales con referencias a casos
prácticos sobre la economía de la nube, en los que se muestra cómo las organizaciones logran el objetivo
empresarial relacionado. Las introducciones actualizadas con casos prácticos ilustrativos incluyen:
Resultados fiscales
Resultados de cobertura global
Objetivos de sostenibilidad
Actualizaciones a escala empresarial
El área de diseño fundamental de la topología y la conectividad de red incluye nuevos artículos que simplifican
la explicación de los componentes individuales del diseño de red. Estos aspectos del diseño incluyen ahora
instrucciones sobre cómo conectarse a proveedores multinube como Oracle Cloud Infrastructure. También
hemos lanzado el nuevo módulo Terraform a escala empresarial para mostrar el continuo interés de Microsoft
por los enfoques de código abierto para la configuración de zonas de aterrizaje de Azure. Por último, hemos
actualizado las instrucciones sobre cómo las empresas pueden [optimizar los grupos de administración y
organizar las suscripciones](../ready/enterprise-scale/management-group-and-subscription-organization] en
Azure para cumplir los requisitos de gobernanza de la nube.
Antipatrones
A menudo, las empresas se dejan atrás pasos importantes en su recorrido de adopción de la nube. La nueva
guía de antipatrones de adopción de la nube destaca los puntos problemáticos comunes de los clientes, qué
paso omitido ha generado ese problema y la ruta más rápida para la recuperación. Los antipatrones se
distribuyen a lo largo de cada metodología, pero en la sección de introducción del marco de trabajo se
encuentra disponible una lista con los 10 principales.
Enero de 2021
Para ayudarle a acelerar la adopción y la innovación, hemos agregado información nueva sobre el uso de
GitHub y hemos actualizado las prácticas recomendadas para el aprendizaje automático. Hemos publicado un
nuevo artículo y un vídeo para ayudarle a elegir la mejor zona de aterrizaje.
A RT ÍC ULO DESC RIP C IÓ N
De qué forma acelera GitHub la adopción de la nube En este artículo se describen las ventajas de usar GitHub
para acelerar la adopción de la nube aprovechando las
características de seguridad, la automatización, los entornos
de desarrollo colaborativo y los recursos de código abierto.
¿Qué es el aprendizaje automático? Hemos actualizado y ampliado la guía de procedimientos

recomendados para el aprendizaje automático. En los
procedimientos recomendados se incluye lo siguiente:
Procedimientos para enfocar las operaciones de

aprendizaje automático y Proceso de las operaciones de
aprendizaje automático
Seguridad del aprendizaje automático
Inferencia e implementación de Machine Learning
Determinar las instancias de proceso de un modelo
Configuración de las áreas de trabajo de Machine
Learning
Selección de una opción de zona de aterrizaje Microsoft ofrece dos opciones de implementación para
zonas de aterrizaje: Inicio a pequeña escala y expansión y
Escala empresarial. Use este nuevo artículo para revisar
ambas opciones y elegir el enfoque adecuado para la
organización.
Diciembre de 2020
Hemos revisado las instrucciones de la estrategia de nomenclatura y etiquetado y agregado instrucciones para
escenarios de migración de Moodle.
Desarrollo de la estrategia de nomenclatura y etiquetado de Hemos adaptado las instrucciones para definir la estrategia
los recursos de Azure de nomenclatura y etiquetado. Además de la introducción,
hemos separado esta guía en varios artículos en los que se
tratan estos temas:

Abreviaturas recomendadas para diversos tipos de
recursos de Azure
Migración de una implementación de Moodle a Azure Aprenda a migrar una implementación del sistema de
administración de aprendizaje de código abierto de Moodle
desde un entorno local a Azure. Se proporcionan los pasos
para usar Azure Portal o la CLI de Azure para la
implementación.
Octubre de 2020
Las actualizaciones de este mes incluyen mejoras incrementales en Cloud Adoption Framework y los recursos
web complementarios.
Nuestras mayores inversiones se han centrado en la creación de módulos de Microsoft Learn para acelerar la
aplicación de Cloud Adoption Framework. Este mes se publican los módulos que se enumeran a continuación.
Tenga en cuenta que el módulo Introducción proporciona la primera guía alineada con un mercado vertical del
sector. Presenta a un cliente minorista, Tailwind Traders, que se utilizará en todos los módulos de metodología
principales que se van a seguir.
M Ó DULO DESC RIP T IO N
Módulo Información general Introducción básica del marco de trabajo.
Módulo Introducción Presentación de las guías de introducción para acelerar la

aplicación de las metodologías adecuadas para superar
bloqueadores específicos.
Zonas de aterrizaje de Azure Antes de compilar el entorno de nube, comprenda los

requisitos operativos y elija el producto de zona de aterrizaje
de Azure más adecuado para empezar.
Creación de una arquitectura de escala empresarial Cree zonas de aterrizaje a escala a partir de un conjunto de
principios de diseño, arquitecturas de referencia e
implementaciones de referencia de escala empresarial.
Cuatro módulos para crear una única ruta de aprendizaje
para triunfar.
También hemos ampliado los resultados empresariales para compartir una serie de enfoques y motivaciones
empresariales comunes que continúan surgiendo en el marketplace posterior a la COVID.
Ejemplos de resultados de sostenibilidad Obtenga información sobre cómo la informática en la nube

puede ayudarle a reducir las emisiones de carbono, a usar
los recursos de un modo más eficiente y a reducir la huella
medioambiental.
Medición de los resultados empresariales con objetivos y Aprenda a usar los OKR para medir los resultados
resultados clave (OKR) empresariales.
Medición de resultados empresariales con AppDynamics Comprender la experiencia del usuario y el rendimiento de
una aplicación es fundamental para medir los resultados
empresariales. Vea cómo AppDynamics puede proporcionar
información empresarial para la mayoría de los casos de uso.
Actualización de Cost Management: VM de acceso puntual El uso de VM de acceso puntual en entornos que no son de
producción es una práctica que se está implementando
rápidamente para reducir aún más los costos en esos
entornos existentes. "Ya tengo un entorno de trabajo.
¿Cómo puedo aplicar los principios de diseño de escala
empresarial?" El nuevo artículo sobre la transición a escala
empresarial puede resultarle útil.
Transición de entornos existentes de Azure a escala Este artículo ayuda a las organizaciones a recorrer el camino
empresarial correcto según un entorno de Azure existente que realiza la
transición a la escala empresarial.
Arquitectura de la zona de aterrizaje a escala empresarial de Este artículo se actualizó para incluir un diagrama de alto
Cloud Adoption Framework nivel para una arquitectura de zona de aterrizaje de escala
empresarial basada en la topología de red de concentrador y
radio, así como actualizaciones para describir y remitir las
áreas de diseño críticas de una arquitectura de zona de
aterrizaje de escala empresarial.
25 de agosto de 2020
Esta versión proporciona mejores criterios de definición y decisión con respecto a las implementaciones de zona
de aterrizaje.
Modelo operativo
Una de las consideraciones más importantes en el diseño y la implementación de la zona de aterrizaje es el
modelo operativo. La forma en la que desea trabajar en la nube tendrá un impacto directo en la arquitectura y
los controles que se van a implementar. Los siguientes artículos le ayudarán a alinear el modelo operativo de
destino con algunos modelos comunes en la nube. A continuación, asígnelos a la implementación más adecuada
para comenzar.
Comparación de los modelos operativos más habituales Este artículo es la guía principal para comparar los modelos
operativos y elegir una línea de actuación.
Descripción de los modelos operativos en la nube Manual para tomar decisiones de importación relacionadas
con el modelo operativo.
Definición del modelo operativo con CAF Cloud Adoption Framework es una guía incremental para la
creación del entorno y la adopción de la nube dentro del
modelo operativo elegido. En este artículo se crea un marco
de referencia para conocer la forma en que varias
metodologías dan soporte técnico al desarrollo de su
modelo operativo.
Términos Términos que es probable que aparezcan al hablar del

modelo operativo con sus colegas de la empresa. Estos
términos no son tan utilizados por los arquitectos o los
especialistas técnicos, pero resultarán importantes en esas
conversaciones.
Zonas de aterrizaje de Azure: Opciones de implementación adicionales

El concepto y las opciones de las implementaciones subyacentes a las zonas de aterrizaje de Azure se crearon
junto con los principales asociados de Microsoft. Esta versión reconoce la propiedad intelectual existente (IP)
que usan esos asociados para acelerar la adopción de la nube.
Zonas de aterrizaje de asociado Revise y compare las ofertas de zona de aterrizaje de Azure
de su asociado.
Opciones de implementación Se ha actualizado para agregar las opciones de zona de

aterrizaje de los asociados a las opciones de implementación
de zona de aterrizaje de Azure existentes.
Implementaciones de referencia de escala empresarial Se ha actualizado para agregar una implementación de

referencia de tipo hub-and-spoke a las implementaciones de
referencia de escala empresarial.
NOTE
Los artículos nuevos de la zona de aterrizaje de asociados no especifican la forma en la que un asociado debe definir o
implementar una zona de aterrizaje. En su lugar, se han diseñado para aportar una estructura a una conversación
compleja, para que pueda comprender mejor la oferta del asociado. Esta lista de preguntas y criterios de evaluación
mínimos también se puede usar para comparar las ofertas de posibles asociados. También la usan algunos asociados para
comunicar más claramente el valor de sus opciones de implementación de zonas de aterrizaje de Azure.
17 de julio de 2020
En esta versión se agrega una serie de escenarios nuevos para que la adopción de la nube sea más útil.
Escenarios de migración:
La nueva página de introducción a los escenarios de migración se basa en la metodología de migración para
demostrar cómo Azure proporciona cumple con la promesa de "#OneMigrate". Proporciona métodos para
migrar varios escenarios de migración propios y de terceros a Azure. Esto incluye nuevos escenarios de
migración:

Windows Virtual Desktop Este escenario permite potenciar la productividad y acelerar

la migración de diversas cargas de trabajo para mejorar la
experiencia del usuario final.
Azure Stack Aprenda a implementar Azure en el centro de datos

mediante Azure Stack Hub.
Análisis en Cloud Adoption Framework :

Las soluciones de análisis ya están incluidas en Cloud Adoption Framework. Estos nuevos temas destacan los
procedimientos recomendados para habilitar las soluciones de análisis durante el recorrido de adopción de la
nube.
Soluciones de análisis para Teradata, Netezza, Exadata Obtenga información sobre cómo migrar entornos locales
heredados como Teradata, Netezza y Exadata a soluciones de
análisis modernas.
Alta disponibilidad para Azure Synapse Obtenga información sobre una de las principales ventajas
de una moderna infraestructura basada en la nube, alta
disponibilidad integrada y recuperación ante desastres.
Lenguajes de definición de datos (DDL) para la migración de Obtenga información sobre los objetos de base de datos y
esquemas los procesos asociados al preparar la migración de los datos
existentes.
Inteligencia ar tificial en Cloud Adoption Framework :

Las soluciones de inteligencia artificial y los procedimientos recomendados ahora se integran en Microsoft
Cloud Adoption Framework. Estas soluciones de inteligencia artificial pueden ayudar a acelerar la innovación
mediante predicciones sobre las necesidades del cliente, la automatización de los procesos empresariales, la
detección de información, la búsqueda de nuevas formas de interactuar con los clientes y el ofrecimiento de
mejores experiencias durante el recorrido de adopción de la nube.
Inteligencia artificial responsable Obtenga información sobre los principios de inteligencia

artificial que debe tener en cuenta al implementar soluciones
de inteligencia artificial y aprenda a establecer una estrategia
de inteligencia artificial responsable.
Guía de innovación de Azure: Innovación con inteligencia Obtenga información sobre cómo puede innovar con
artificial inteligencia artificial y encuentre la mejor solución en función
de sus necesidades de implementación.
Inteligencia artificial en Cloud Adoption Framework Revise un marco normativo que incluye herramientas,
programas y contenido (procedimientos recomendados,
plantillas de configuración e instrucciones de arquitectura)
que simplifican la adopción tanto de la inteligencia artificial
como de procedimientos nativos de la nube a escala.
MLOps con Azure Machine Learning Más información sobre los procedimientos recomendados
para operaciones de aprendizaje automático (MLOps).
Innovación con inteligencia artificial Obtenga información sobre las soluciones de inteligencia
artificial (aprendizaje automático, aplicaciones y agentes de
inteligencia artificial, minería de conocimientos) y sobre los
procedimientos recomendados que pueden acelerar la
invención digital.
15 de junio de 2020
La configuración adecuada del entorno en la nube suele ser el primer y más habitual obstáculo técnico en la
adopción de la nube. Esta versión se centra en gran medida en las instrucciones que agilizan la implementación
de entornos en la nube. Para superar este obstáculo habitual, Cloud Adoption Framework presenta las zonas de
aterrizaje de Azure .
Zonas de aterrizaje de Azure Las zonas de aterrizaje de Azure crean un conjunto común
de áreas de diseño y opciones de implementación para
agilizar la creación de entornos coordinados con el plan de
adopción de la nube y el modelo de funcionamiento en la
nube. En este nuevo artículo se definen de forma más clara
las zonas de aterrizaje de Azure.
Zonas de aterrizaje de Azure: Áreas de diseño Todas las zonas de aterrizaje de Azure comparten un
conjunto común de ocho áreas de diseño. Antes de
implementar cualquiera de las zonas de aterrizaje de Azure,
los clientes deben tener en cuenta cada uno de estos
diseños para tomar decisiones críticas.
Zonas de aterrizaje de Azure: Opciones de implementación Elija la mejor opción de implementación de la zona de
aterrizaje de Azure, en función del plan de adopción de la
nube y el modelo de operación en la nube.
Las definiciones de plano técnico de CAF y los módulos de CAF Terraform existentes proporcionan un punto de
partida para la implementación de la zona de aterrizaje de Azure. No obstante, algunos clientes necesitan una
opción de implementación más enriquecida que pueda satisfacer las demandas de los planes de adopción de la
nube a escala empresarial. Esta versión agrega escala empresarial de CAF a las opciones de implementación
de zona de aterrizaje de Azure para satisfacer esa necesidad. A continuación se enumeran algunos de los
artículos que le ayudarán a usar las implementaciones de arquitectura y referencia de escala empresarial de
CAF.
Introducción a la escala empresarial Información general sobre la escala empresarial
Implementación de zonas de aterrizaje de escala empresarial Opciones de implementación rápida y ejemplos de GitHub
de CAF
Arquitectura de escala empresarial Descripción de la arquitectura subyacente de la escala

empresarial
Principios del diseño a escala empresarial Obtenga información sobre los principios de diseño
arquitectónicos que guían las decisiones durante la
implementación, a fin de evaluar si este enfoque se ajusta al
modelo operativo de la nube.
Guía de diseño a escala empresarial Evalúe las directrices de escala empresarial para cumplir las
áreas de diseño habituales de las zonas de aterrizaje de
Azure
Guías de implementación Revise las actividades requeridas para una implementación

de escala empresarial antes de la implementación
Los asociados son un aspecto importante de la adopción correcta de la nube. A lo largo de la guía sobre Cloud
Adoption Framework, hemos agregado referencias para mostrar la importancia del papel que juegan los
asociados y de qué manera los clientes pueden interactuar mejor con estos. Para obtener una lista de los
asociados de CAF validados, consulte las ofertas de asociados que están en línea con CAF, de los proveedores
cualificados de servicios administrados de Azure o de los asociados especialistas avanzados.
15 de mayo de 2020
Basándonos en los comentarios, hemos creado contenido nuevo para que pueda empezar a usar Cloud
Adoption Framework. Las nuevas guías de introducción le ayudarán a navegar por la plataforma según lo que
desee realizar. También se ha creado una nueva página de aterrizaje para que sea más fácil encontrar la guía, las
herramientas, los módulos de aprendizaje y los programas que facilitan un recorrido de adopción de la nube
correcto.
Cloud Adoption Framework para Azure La página de aterrizaje de Cloud Adoption Framework se ha
rediseñado para que sea más fácil encontrar la guía, las
herramientas, los módulos de aprendizaje y los programas
que facilitan un recorrido de adopción de la nube correcto.
Introducción a Cloud Adoption Framework Elija una guía de introducción que sea adecuada para sus
objetivos de adopción de la nube. Estos escenarios comunes
proporcionan un plan de desarrollo de Microsoft Cloud
Adoption Framework para Azure
Comprensión y documentación de decisiones de alineación Obtenga más información sobre las decisiones iniciales que
fundamentales deben comprender todos los equipos implicados en la
adopción de la nube.
Comprensión y alineación de la jerarquía de la cartera Obtenga más información sobre cómo muestra una
jerarquía de cartera la adaptación de las cargas de trabajo y
los servicios auxiliares unos a otros.
¿Cómo respaldan los productos de Azure la jerarquía de la Obtenga información sobre cómo respaldan las
cartera? herramientas y soluciones de Azure la jerarquía de cartera.
Administración de la alineación de la organización Establezca estructuras organizativas bien dotadas de

personal que sean un modelo operativo eficaz para la nube.
14 de abril de 2020
Hemos reunido todas las herramientas y plantillas de adopción de la nube en un solo lugar para que sean más
fáciles de encontrar.
Herramientas y plantillas Encuentre las herramientas, plantillas y evaluaciones que

pueden ayudarle a acelerar el recorrido de adopción de la
nube.
4 de abril de 2020
Iteración continua de refinamiento en las metodologías de migración y preparación para mejorar la alineación
con los comentarios de clientes, asociados de Microsoft y programas internos de Microsoft.
Actualizaciones de la metodología de migración:
Metodología de migración Estos cambios simplifican las fases del trabajo de migración
(evaluación, implementación y liberación de las cargas de
trabajo). Los cambios también quitan los detalles
relacionados con el trabajo pendiente de migración. La
eliminación de estos detalles y la referencia a las
metodologías de planeamiento, preparación y adopción en
su lugar proporciona flexibilidad para los distintos programas
de adopción de la nube a fin de mejorar la alineación con la
metodología.
Actualizaciones de la metodología de preparación:
Refactorización de zonas de aterrizaje Nuevo ar tículo: extraído de los talleres de metodología de

preparación, este artículo muestra la teoría del inicio con una
plantilla inicial, el uso de árboles de decisión y la
refactorización para expandir la zona de aterrizaje, así como
el cambio a un estado futuro de preparación empresarial.
Expansión de la zona de aterrizaje Nuevo ar tículo: se basa en la sección iteraciones paralelas

del artículo de refactorización para mostrar cómo varios
tipos de expansiones de zona de aterrizaje insertarían los
principios compartidos en la plataforma compatible. El
contenido original de esta introducción se ha trasladado al
nodo Consideraciones básicas de la zona de aterrizaje de la
tabla de contenido.
Desarrollo controlado por pruebas (TDD) de las zonas de Nuevo ar tículo: el enfoque de refactorización ha mejorado
aterrizaje considerablemente a través de la adopción de un ciclo de
desarrollo controlado por pruebas para guiar el desarrollo y
la refactorización de las zonas de aterrizaje.
Desarrollo controlado por pruebas de zonas de aterrizaje en Nuevo ar tículo: las herramientas de Gobernanza en Azure
Azure proporcionan una completa plataforma para los ciclos de
desarrollo controlado por pruebas o pruebas rojo-verde.
Mejora de la seguridad en la zona de aterrizaje Nuevo ar tículo: información general sobre los
procedimientos recomendados de esta sección, en relación
con el ciclo de desarrollo controlado por pruebas.
Mejora de las operaciones en la zona de aterrizaje Nuevo ar tículo: lista de procedimientos recomendados de
la metodología de administración, con una transición a ese
enfoque modular para mejorar las operaciones, la
confiabilidad y el rendimiento.
Mejora de la gobernanza de la zona de aterrizaje Nuevo ar tículo: lista de procedimientos recomendados en

relación con la metodología de gobierno, con una transición
a ese enfoque modular para mejorar la gobernanza, la
administración de costos y la escala.
Inicio a escala empresarial Nuevo ar tículo: Demostración de un enfoque que muestra

las diferencias en el proceso cuando un cliente comienza con
las plantillas de zona de aterrizaje de escala empresarial de
CAF. Este artículo ayuda a los clientes a comprender los
calificadores que respaldarían esta decisión.
27 de marzo de 2020
Se han agregado instrucciones sobre las suscripciones iniciales que se deben crear al adoptar Azure.
Actualización de las instrucciones sobre suscripciones:
Creación de las suscripciones de Azure iniciales Nuevo ar tículo: cree las suscripciones de producción y de
no producción iniciales, y decida si desea crear suscripciones
de espacio aislado, así como una suscripción para que
contenga servicios compartidos.
Creación de suscripciones adicionales para escalar el entorno Más información acerca de las razones para crear
de Azure suscripciones adicionales, trasladar recursos entre
suscripciones y sugerencias para crear nuevas suscripciones.
Organización y administración de varias suscripciones de Cree una jerarquía de grupos de administración que le ayude
Azure a organizar, administrar y gobernar las suscripciones de
Azure.
20 de marzo de 2020
Hemos agregado instrucciones prescriptivas que incluyen las herramientas, los programas y el contenido
clasificados por rol para impulsar la implementación correcta de aplicaciones en Kubernetes, desde la prueba de
concepto a producción, seguida del escalado y la optimización.
Kubernetes:
Desarrollo e implementación de aplicaciones Nuevo ar tículo: proporciona listas de comprobación,

recursos y procedimientos recomendados para planear el
desarrollo de aplicaciones, configurar canalizaciones de
CI/CD e implementar la ingeniería de confiabilidad de sitios
para Kubernetes.
Diseño y operaciones de clústeres Nuevo ar tículo : proporciona listas de comprobación,

recursos y procedimientos recomendados para la
configuración de clústeres, el diseño de red, la escalabilidad
en el futuro, la continuidad empresarial y la recuperación
ante desastres para Kubernetes.
Seguridad de clústeres y aplicaciones Nuevo ar tículo: proporciona listas de comprobación,

recursos y procedimientos recomendados para el
planeamiento de la seguridad, la producción y el escalado.
2 de marzo de 2020
En respuesta a los comentarios sobre la continuidad en el enfoque de migración en varias secciones de Cloud
Adoption Framework entre las que se incluyen las fases de estrategia, planeamiento, preparación y migración,
hemos realizado las siguientes actualizaciones. Estas actualizaciones están diseñadas para facilitar la
comprensión de los ajustes de planeamiento y adopción a medida que continúa con el recorrido de migración.
Actualizaciones de la metodología de estrategia:
Equilibrio de la cartera Se ha hecho que este artículo aparezca antes en la

metodología de estrategia. Esto le ofrece visibilidad sobre el
proceso de reflexión anterior al ciclo de vida.
Equilibrio entre prioridades contrapuestas Nuevo ar tículo: describe el equilibrio de prioridades entre
metodologías para ayudar a tomar decisiones con
fundamento sobre su estrategia.
Actualizaciones de la metodología de planeamiento:
Procedimiento recomendado de evaluación Este artículo se ha trasladado a la nueva sección

"Procedimientos recomendados" de la metodología de
planeamiento. Esto le proporciona visibilidad sobre el
procedimiento de evaluación de entornos locales en una fase
más temprana del ciclo de vida.
Actualizaciones de la metodología de preparación:
¿Qué es una zona de aterrizaje? Nuevo ar tículo: define el término zona de aterrizaje.
Primera zona de aterrizaje Nuevo ar tículo: trata la comparación de diversas zonas de

aterrizaje.
Zona de aterrizaje de la migración de CAF Se ha separado la definición del plano técnico de la selección
de la primera zona de aterrizaje.
Módulos de CAF Terraform Se ha trasladado a la nueva sección "Zona de aterrizaje" de la

metodología de preparación para elevar Terraform en el
debate sobre la zona de aterrizaje.
Actualizaciones de la metodología de migración:
Información general Se ha actualizado con una descripción más clara de la guía y

con menos pasos.
Evaluar Se ha agregado la sección "Cuestionamiento de

suposiciones", para demostrar cómo funciona este nivel de
evaluación con el enfoque de evaluación incremental
mencionado en la metodología de planeamiento.
Clasificación durante los procesos de evaluación Nuevo ar tículo: describe la importancia de clasificar cada
recurso y carga de trabajo antes de la migración.
Migrar Se ha agregado una referencia a UnifyCloud en las opciones

de herramientas de terceros en respuesta a los comentarios
en las conferencias de nivel 1.
Prueba, optimización y promoción Se ha alineado el título de este artículo con otras sugerencias
de mejora de procesos.
Introducción a la evaluación Se ha actualizado para mostrar que la evaluación en esta

fase se centra en la evaluación de la idoneidad técnica de
una carga de trabajo específica y de los recursos
relacionados.
Lista de comprobación de planeamiento Se ha actualizado para aclarar la importancia de la alineación

de las operaciones durante el planeamiento de los esfuerzos
de migración y para garantizar una carga de trabajo bien
administrada, posterior a la migración.
Introducción a Cloud Adoption Framework
Cloud Adoption Framework puede ayudarle a dar sus primeros con distintas guías de introducción. En este
artículo se agrupan las guías que le ayudarán a encontrar la que mejor se ajuste a los desafíos a los que se
enfrenta actualmente.
Cada uno de los siguientes vínculos le lleva a preguntas que se suelen plantear cuando una organización intenta
lograr un objetivo determinado durante su recorrido de adopción de la nube.
Elija el escenario de adopción de la nube que mejor se adapte a su estrategia
Examen de los antipatrones entre metodologías y sus soluciones
Alinear conceptos básicos para incorporar una persona, un proyecto o un equipo
Adopción en la nube para ofrecer resultados técnicos y empresariales más rápidamente
Mejorar los controles para garantizar operaciones correctas en la nube
Establecer equipos para respaldar la adopción y las operaciones
Escenarios de adopción de la nube

El trabajo de adopción de la nube de su organización tenderá a adaptarse a los requisitos de los objetivos
estratégicos a largo plazo de su recorrido en la nube. En función de si se plantea la posibilidad de un exhaustivo
trabajo híbrido con varias nubes o se prepara la integración de Kubernetes y contenedores en la estrategia de la
nube, se han actualizado las instrucciones para un escenario de adopción híbrido con varias nubes y un
moderno escenario de adopción de contenedores.
Antipatrones de adopción de la nube

Puede encontrar errores de diseño, planeamiento o implementación al migrar a la nube. Se han actualizado la
guía detallada de los antipatrones que pueden bloquear la innovación e impedir que las empresas adopten e
impongan objetivos.
Alineación de conceptos básicos

El recorrido de adopción de la nube de su empresa se suele guiar con decisiones fundamentales que afectarán a
los resultados del viaje de la adopción de la nube. La siguiente información puede ayudarle a tomar decisiones
importantes y a registrarlas como referencia para usarlas durante el ciclo de vida de la adopción de la nube.
Introducción a la alineación de decisiones fundamentales
Conceptos básicos
Respaldo de la jerarquía de Azure
Agilización de la adopción
La adopción de la nube requiere cambios técnicos, pero la transformación digital con la nube requiere algo más
que TI. Use estas guías para empezar a alinear varios equipos para agilizar los trabajos de migración e
innovación.
GUÍA DESC RIP C IÓ N
Queremos migrar las cargas de trabajo existentes a la nube. Esta guía es un excelente punto de partida si se va a centrar
principalmente en migrar cargas de trabajo locales a la nube.
Queremos crear productos y servicios en la nube. Esta guía puede ayudarle a preparar la implementación de
soluciones innovadoras en la nube.
Nos bloquea el diseño y la configuración del entorno. Esta guía proporciona un método rápido para diseñar y
configurar el entorno.
Mejora de los controles

A medida que progresa el recorrido de la adopción de la nube, un modelo operativo sólido puede ayudar a
garantizar que se toman decisiones inteligentes. También puede tener en cuenta los cambios en la organización.
Estas guía pueden ayudarle a alinear al personal y mejorar las operaciones para desarrollar el modelo operativo
en la nube.
¿Cómo se proporciona excelencia operativa durante la Los pasos de esta guía pueden ayudar al equipo de
transformación de la nube? estrategia a llevar a cabo la administración de cambios
organizacionales necesaria para garantizar sistemáticamente
la excelencia operativa.
¿Cómo se administran los costos empresariales? Esta guía puede ayudarle a optimizar los costos
empresariales y administrar los costos en todo el entorno.
¿Cómo se protege de forma sistemática el entorno de nube Esta guía puede ayudarle a garantizar que los requisitos de
empresarial? seguridad se aplican en toda la empresa para reducir el
riesgo de vulneraciones y acelerar la recuperación cuando
estas se produzcan.
¿Cómo se aplican los controles adecuados para mejorar la Esta guía ayuda a minimizar las interrupciones relacionadas
confiabilidad? con las incoherencias en la configuración, la organización de
recursos, las bases de referencia seguridad o las directivas de
protección de recursos.
¿Cómo se garantiza el rendimiento en toda la empresa? Esta guía puede ayudarle a establecer procesos para
mantener el rendimiento en toda la empresa.
Establecimiento de equipos
En función de su estrategia de adopción y modelo operativo, puede que deba establecer algunos equipos. Esta
sección proporciona ayuda para poner en marcha esos nuevos equipos.
¿Cómo se alinea nuestra organización? Esta guía le ayuda a establecer una estructura organizativa
con el personal adecuado.
¿Es necesario un equipo de estrategia en la nube? Este equipo garantiza que el trabajo de adopción de la nube
progresa en paralelo a los resultados empresariales.
¿Qué función desempeña el equipo de adopción de la nube? Este equipo implementa las soluciones técnicas que se
describen en el plan, de acuerdo con los requisitos de
gobernanza.
¿Cómo se crea un equipo de gobernanza de la nube? Este equipo se asegura de que los riesgos y la tolerancia a
estos se evalúen y administren correctamente.
¿Cómo funciona un equipo de operaciones en la nube? Este equipo se centra en la supervisión, la reparación y la
corrección de problemas relacionados con operaciones y
recursos de TI tradicionales.
Primeros pasos: Comprensión y documentación de
decisiones de alineación fundamentales
El recorrido de adopción de la nube puede aportar una gran cantidad de ventajas empresariales, técnicas y
organizativas. Independientemente de lo que se quiera conseguir, si el recorrido incluye la nube, existen una
serie de decisiones iniciales que todos los equipos implicados deben comprender.
NOTE
La selección de cualquiera de los siguientes vínculos puede conducirte al índice de contenidos de Microsoft Cloud
Adoption Framework para Azure para buscar conceptos fundamentales que utilizará posteriormente para ayudar al
equipo a implementar las instrucciones asociadas. Marque esta página para volver a esta lista de comprobación con
frecuencia.
Antes de empezar
A medida que avance en esta guía, registre esas decisiones fundamentales mediante la plantilla de decisiones
iniciales. La plantilla puede ayudarle a incorporar rápidamente a los miembros del equipo que participan en el
ciclo de vida de la adopción de la nube clarificando cómo se configura el entorno en la nube y por qué.
Si ya tiene un entorno que se ejecuta en Azure, Azure Governance Visualizer puede ayudarle a agilizar la
documentación. Obtenga información sobre las directivas, el control de acceso basado en rol de Azure (RBAC de
Azure), Azure Blueprints, las suscripciones, etc. A partir de los datos recopilados, la herramienta proporciona
visibilidad sobre el mapa de jerarquía, crea un resumen de inquilino y crea información detallada sobre los
grupos de administración y las suscripciones.
Paso 1: comprender el funcionamiento de Azure

Si ha elegido Azure como proveedor de servicios en la nube para respaldar su recorrido de adopción de la nube,
es importante comprender cómo funciona Azure.
Equipos implicados, resultados esperados e instrucciones complementarias:
Todos los implicados en el ciclo de adopción de la nube deben tener un conocimiento básico de cómo funciona
Azure.
Paso 2: comprender los conceptos iniciales de Azure

Azure se basa en un conjunto de conceptos básicos que son necesarios para tener una conversación en
profundidad sobre la estrategia técnica necesaria para las implementaciones de Azure.
Equipos implicados, resultados esperados e instrucciones complementarias:
Todos los implicados en la implementación de Azure de la estrategia tecnológica deben comprender los
términos y las definiciones de los conceptos básicos.
Paso 3: revisar la cartera

Independientemente del proveedor de nube elegido, el primer paso para tomar todas las decisiones sobre el
hospedaje en la nube y sobre el entorno es conocer la cartera de cargas de trabajo. Cloud Adoption Framework
incluye varias herramientas para comprender y evaluar esta cartera.
Resultados esperados:
Registre la ubicación, el estado y la persona responsable de la documentación de la cartera en la plantilla de
decisiones iniciales.
Guía para la consecución de los resultados esperados:
Los conceptos fundamentales ayudan a comprender temas clave de Azure antes de comenzar la adopción de
la nube.
El libro de administración de operaciones y la estrategia de adecuación empresarial le ayudarán a
comprender las cargas de trabajo y los recursos que se han transferido a un equipo de operaciones en la
nube.
El plan de adopción de la nube proporciona un trabajo pendiente de las cargas de trabajo y los recursos que
están programados para su adopción en la nube.
El análisis del patrimonio digital es una estrategia para documentar las cargas de trabajo y los recursos
existentes que están programados para su adopción en la nube. En Azure, el patrimonio digital se representa
mejor en una herramienta llamada Azure Migrate.
EQ UIP O EN C A RGA DO EQ UIP O S RESP O N SA B L ES Y DE A P O Y O
El equipo de estrategia en la nube es responsable de Varios equipos usarán las siguientes instrucciones para
definir una manera de ver la cartera. crear esas vistas. Todas las personas implicadas en la
adopción de la nube deben saber dónde consultar la vista de
la cartera para respaldar las decisiones que se tomarán más
adelante en el proceso.
Paso 4: definir la profundidad de la jerarquía de la cartera para alinear

la cartera
El hospedaje de recursos y cargas de trabajo en la nube puede ser simple, con una única carga de trabajo y sus
recursos de apoyo. Para otros clientes, la estrategia de adopción de la nube podría incluir miles de cargas de
trabajo y muchos más recursos de apoyo. La jerarquía de la cartera proporciona los nombres comunes de cada
uno de los niveles de la jerarquía para ayudar a crear un lenguaje común para la organización,
independientemente del proveedor de la nube.
Registre las necesidades de jerarquía pertinentes en la plantilla de decisiones iniciales.
Comprenda los niveles de la jerarquía de cartera para alinear los términos fundamentales.
El equipo de gobernanza de la nube es responsable de Todas las personas implicadas en la estrategia técnica para
definir, aplicar y automatizar la jerarquía de la cartera para la adopción de la nube deben estar familiarizadas con la
conformar la directiva corporativa en la nube. jerarquía de la cartera y los niveles de la jerarquía que se
usan actualmente.
Paso 5: establecer un estándar de nomenclatura y etiquetado en toda
la cartera
Todas las cargas de trabajo y los recursos existentes deben tener un nombre y una etiqueta adecuados de
acuerdo con un estándar de nomenclatura y etiquetado. Esos estándares deben documentarse y estar
disponibles como referencia para todos los miembros del equipo. Cuando sea posible, también se deben aplicar
automáticamente para garantizar que se cumplan los requisitos mínimos de etiquetado.
Registre la ubicación, el estado y la parte responsable del libro de convenciones de nomenclatura y
etiquetado de la plantilla de decisiones iniciales.
Cree un estándar de nomenclatura y etiquetado.
Rellene la plantilla de seguimiento de convenciones de nomenclatura y etiquetado para realizar un
seguimiento de las decisiones.
Revise y actualice las etiquetas existentes en Azure.
Aplique directivas de etiquetado en Azure.
definir, aplicar y automatizar los estándares de nomenclatura la adopción de la nube deben estar familiarizadas con los
y etiquetado para garantizar la coherencia en toda la cartera. estándares de nomenclatura y etiquetado antes de la
implementación en la nube.
Paso 6: crear un diseño de organización de recursos para

implementar la jerarquía de la cartera
Para garantizar una alineación coherente con las decisiones de jerarquía de cartera, es importante crear un
diseño para la organización de recursos. Este tipo de diseño permite alinear las herramientas organizativas del
proveedor de nube con la jerarquía de la cartera necesaria para respaldar el plan de adopción de la nube. Este
diseño guiará la implementación al aclarar qué recursos se pueden implementar dentro de límites concretos en
los entornos de la nube.
Asigne productos de Azure al nivel alineado de la jerarquía de la cartera en la plantilla de decisiones iniciales.
Comprenda cómo respaldan los productos de Azure la jerarquía de la cartera.
Revise las suscripciones existentes para alinearlas con la jerarquía de cartera elegida.
Creación de una estrategia de suscripción:
Comenzará con dos suscripciones de forma intencionada. Agregue diseños de suscripción básicos para
atender necesidades empresariales comunes, como servicios compartidos o suscripciones de espacio
aislado.
Administre varias suscripciones, ya que se requieren suscripciones adicionales para respaldar el plan de
Establezca límites bien definidos basados en la jerarquía de la cartera.
Cuando sea necesario, mueva recursos y grupos de recursos entre suscripciones para cumplir la estrategia
de la organización.
definir, implementar y automatizar el diseño de la la adopción de la nube deben estar familiarizadas con el
organización de recursos en toda la cartera. diseño de la organización de recursos antes de la
Paso 7: asignar funcionalidades, equipos y RACI a conceptos

fundamentales
La complejidad de la jerarquía de la cartera proporcionará información a las estructuras y metodologías de la
organización para orientar las actividades cotidianas de varios equipos.
Complete las guías de introducción para la alineación de la organización basada en estos conceptos.
Use los pasos anteriores como guía para evaluar la guía de responsabilidad de la jerarquía de cartera.
Determine qué funcionalidades puede que tengan que ofrecer las organizaciones dedicadas o equipos
virtuales.
Use Introducción: Alineación de la organización para aplicar la guía de responsabilidad de la jerarquía de la
cartera al diagrama RACI (siglas en inglés de entidades responsables, encargadas, consultas e informadas).
El equipo de estrategia en la nube es responsable de Todas las personas implicadas en el ciclo de adopción de la
alinear las estructuras organizativas virtuales o dedicadas nube deben estar familiarizadas con la alineación de
para garantizar el éxito del ciclo de adopción de la nube. personas y niveles de responsabilidad.
Pasos siguientes
Tenga en cuenta este conjunto de conceptos fundamentales a través de la serie de guías de introducción de esta
sección de Cloud Adoption Framework.
Aplicar conceptos fundamentales a otras guías de introducción
Azure es la plataforma pública en la nube de Microsoft. Azure ofrece una amplia gama de servicios entre los que
se incluyen las funcionalidades de plataforma como servicio (PaaS), infraestructura como servicio (IaaS) y
servicio de base de datos administrado. Pero, ¿qué es exactamente Azure y cómo funciona?
Azure, al igual que otras plataformas en la nube, se basa en una tecnología conocida como virtualización. La
mayor parte del hardware de equipo puede emularse en el software porque es simplemente un conjunto de
instrucciones codificadas de forma permanente o semipermanente en silicio. Mediante una capa de emulación
que asigna instrucciones de software a instrucciones de hardware, el hardware virtualizado puede ejecutarse en
el software como si fuera el propio hardware.
Básicamente, la nube es un conjunto de servidores físicos en uno o varios centros de datos que ejecutan
hardware virtualizado en nombre de los clientes. Entonces, ¿cómo crea, inicia, detiene y elimina la nube millones
de instancias de hardware virtualizado para millones de clientes a la vez?
Para comprenderlo, vamos a echar un vistazo a la arquitectura del hardware del centro de datos. En cada centro
de datos hay una colección de servidores colocados en bastidores de servidores. Cada bastidor de servidor
contiene muchas hojas de servidor, así como un conmutador de red que proporciona conectividad de red y una
unidad de distribución de energía (PDU) que suministra la alimentación. A veces, los bastidores se agrupan
conjuntamente en unidades más grandes que se conocen como clústeres.
En cada bastidor o clúster, la mayoría de los servidores están designados para ejecutar estas instancias de
hardware virtualizado en nombre del usuario. No obstante, algunos de los servidores ejecutan software de
administración en la nube conocido como controlador de tejido. El controlador de tejido es una aplicación
distribuida con muchas responsabilidades. Asigna servicios, supervisa el mantenimiento del servidor y los
servicios que se ejecutan en él, y recupera los servidores cuando se produce un error.
Cada instancia del controlador de tejido se conecta a otro conjunto de servidores que ejecutan software de
orquestación en la nube, conocido normalmente como front-end. El front-end hospeda los servicios web, las API
RESTful y las bases de datos internas de Azure utilizadas para todas las funciones que realiza la nube.
Por ejemplo, el front-end hospeda los servicios que controlan las solicitudes de cliente para asignar recursos de
Azure como máquinas virtuales y servicios como Cosmos DB. En un primer tiempo, el front-end valida el
usuario y comprueba que esté autorizado para asignar los recursos solicitados. Si es así, el front-end consulta
una base de datos para buscar un bastidor de servidores con capacidad suficiente y, luego, indica al controlador
de tejido de ese bastidor que asigne el recurso.
Así que, básicamente, Azure es una inmensa colección de servidores y hardware de red que ejecuta un complejo
conjunto de aplicaciones distribuidas para orquestar la configuración y el funcionamiento del hardware y el
software virtualizado de esos servidores. Es esta orquestación la que hace que Azure sea tan eficaz, dado que los
usuarios ya no son responsables de mantener y actualizar el hardware, ya que de todo esto se encarga Azure en
segundo plano.
Pasos siguientes
Más información sobre la adopción de la nube en Microsoft Cloud Adoption Framework para Azure.
Más información sobre Microsoft Cloud Adoption Framework para Azure
Conceptos básicos de Azure
Conozca los conceptos y términos fundamentales que se usan en Azure y cómo esos conceptos se relacionan
entre sí.
Terminología de Azure
Al comenzar las labores de adopción de la nube de Azure, resulta útil conocer las siguientes definiciones:
Recurso: entidad administrada por Azure. Algunos ejemplos son máquinas virtuales, redes virtuales y
cuentas de almacenamiento de Azure.
Subscription (Suscripción): contenedor lógico para los recursos. Cada recurso de Azure está asociado a una
sola suscripción. La creación de una suscripción es el primer paso en la adopción de Azure.
Cuenta de Azure: la dirección de correo electrónico que proporciona al crear una suscripción a Azure es la
cuenta de Azure de la suscripción. La entidad que está asociada a la cuenta de correo electrónico es
responsable de los costos mensuales que generan los recursos de la suscripción. Cuando se crea una cuenta
de Azure, se proporciona información de contacto y detalles de facturación, como una tarjeta de crédito.
Puede usar la misma cuenta de Azure (dirección de correo electrónico) con varias suscripciones. Cada
suscripción está asociada solo a una cuenta de Azure.
Administrador de cuenta: la entidad asociada a la dirección de correo electrónico que se usa para crear
una suscripción a Azure. El administrador de la cuenta es responsable del pago de todos los costos que
generan los recursos de la suscripción.
Azure Active Director y (Azure AD): el servicio de administración de acceso e identidades de Microsoft,
basado en la nube. Azure AD ayuda a sus empleados a iniciar sesión y a acceder a los recursos.
Inquilino de Azure AD: instancia dedicada y de confianza de Azure AD. Se crea automáticamente cuando
su organización se suscribe por primera vez a un servicio en la nube de Microsoft, como Microsoft Azure,
Intune o Microsoft 365. Un inquilino de Azure representa una organización individual.
Directorio de Azure AD: todos los inquilinos de Azure AD tienen un directorio dedicado y de confianza. El
directorio incluye los usuarios, los grupos y las aplicaciones del inquilino. Se usa para realizar funciones de
administración de identidades y acceso para los recursos del inquilino. Un directorio puede asociarse a varias
suscripciones, pero cada suscripción solo está asociada a un directorio.
Grupos de recursos: contenedores lógicos que se usan para agrupar los recursos relacionados de una
suscripción. Cada recurso solo puede existir en un grupo de recursos. Los grupos de recursos permiten una
agrupación más detallada dentro de una suscripción y se usan normalmente para representar una colección
de los recursos necesarios para respaldar una carga de trabajo, una aplicación o una función específica
dentro de una suscripción.
Grupos de administración: contenedores lógicos que se usan para una o varias suscripciones. Puede
definir una jerarquía de grupos de administración, suscripciones, grupos de recursos y recursos para
administrar de forma eficaz el acceso, las directivas y el cumplimiento a través de la herencia.
Región: conjunto de centros de datos de Azure que se implementan dentro de un perímetro definido por la
latencia. Los centros de datos se conectan a través de una red dedicada, regional y de baja latencia. La
mayoría de los recursos de Azure se ejecutan en una región específica de Azure.
Objetivos de la suscripción a Azure

Una suscripción a Azure sirve a varios fines. Una suscripción de Azure es:
Un contrato legal. Cada suscripción está asociada a una oferta de Azure, como evaluación gratuita o pago
por uso. Cada oferta tiene un plan de tarifa, unas ventajas y unos términos y condiciones asociados
específicos. Puede elegir una oferta de Azure al crear una suscripción.
Un acuerdo de pago. Al crear una suscripción, se proporciona la información de pago de esa suscripción,
como un número de tarjeta de crédito. Cada mes, los costos que generan los recursos implementados en esa
suscripción se calculan y facturan mediante ese método de pago.
Un límite de escala. Se definen límites de escala para una suscripción. Los recursos de la suscripción no
pueden superar los límites de escala establecidos. Por ejemplo, hay un límite en el número de máquinas
virtuales que puede crear en una sola suscripción.
Un límite administrativo. Una suscripción puede actuar como límite de administración, seguridad y
directiva. Azure también proporciona otros mecanismos para satisfacer estas necesidades, como los grupos
de administración, los grupos de recursos y el control de acceso basado en rol de Azure.
Consideraciones sobre las suscripciones a Azure

Al crear una suscripción a Azure, puede elegir varias opciones clave sobre ella:
¿Quién es el responsable de pagar la suscripción? La entidad asociada a la dirección de correo
electrónico que proporcione al crear una suscripción es, de forma predeterminada, el administrador de la
cuenta de la suscripción. La entidad asociada a esta dirección de correo electrónico es responsable de pagar
todos los costos que generen los recursos de la suscripción.
¿Qué ofer ta de Azure me interesa? Cada suscripción está asociada a una oferta de Azure específica.
Puede elegir la oferta de Azure que mejor se adapta a sus necesidades. Por ejemplo, si piensa usar una
suscripción para ejecutar cargas de trabajo de no producción, puede elegir la oferta Desarrollo/pruebas -
Pago por uso o la oferta Desarrollo/pruebas - Enterprise.
NOTE
Al suscribirse a Azure, es posible que vea la frase creación de una cuenta de Azure. Puede crear una cuenta de Azure al
crear una suscripción a Azure y asociar la suscripción a una cuenta de correo electrónico.
Roles administrativos de Azure

Azure define tres tipos de roles para administrar suscripciones, identidades y recursos:
Roles de administrador de suscripciones clásicas
Roles de Azure
Roles de Azure Active Directory (Azure AD)
El rol de administrador de cuenta de una suscripción a Azure se asigna a la cuenta de correo electrónico que se
usa para crear dicha suscripción. El administrador de cuenta es el propietario de la facturación de la suscripción.
El administrador de cuenta puede administrar los administradores de la suscripción mediante Azure Portal.
De forma predeterminada, el rol Administrador de servicios de una suscripción también se asigna a la cuenta de
correo electrónico que se usa para crear la suscripción a Azure. El administrador de servicios tiene unos
permisos para la suscripción equivalentes a los del rol de propietario basado en RBAC de Azure. El
administrador de servicios tiene acceso completo a Azure Portal. El administrador de cuenta puede cambiar el
administrador de servicios a una cuenta de correo electrónico diferente.
Al crear una suscripción a Azure, puede asociarla a un inquilino de Azure AD existente. De lo contrario, se crea
un inquilino de Azure AD con un directorio asociado. El rol de administrador global en el directorio Azure AD se
asigna a la cuenta de correo electrónico que se usó para crear la suscripción a Azure AD.
Una cuenta de correo electrónico puede asociarse a varias suscripciones de Azure. El administrador de cuenta
puede transferir una suscripción a otra cuenta.
Para ver una descripción detallada de los roles definidos en Azure, consulte Roles de administrador de la
suscripción clásica, roles de Azure y roles de Azure AD.
Suscripciones y regiones
Cada recurso de Azure está asociado lógicamente a una sola suscripción. Al crear un recurso, puede elegir la
suscripción a Azure en la que se va a implementar ese recurso. Posteriormente, puede mover un recurso a otra
suscripción.
Mientras que una suscripción no está asociada a una región específica de Azure, cada recurso de Azure se
implementa en una sola región. Puede tener recursos en varias regiones que estén asociadas a la misma
suscripción.
NOTE
La mayoría de los recursos de Azure se implementan en una región específica. Determinados tipos de recursos se
consideran recursos globales, como las directivas que se establecen mediante los servicios de Azure Policy.
Recursos relacionados
Los siguientes recursos proporcionan información detallada sobre los conceptos descritos en este artículo:
Administración del acceso a recursos de Azure
Información general sobre Azure Resource Manager
Control de acceso basado en roles de Azure (Azure RBAC)
¿Qué es Azure Active Directory?
Asociación o incorporación de una suscripción de Azure al inquilino de Azure Active Directory
Topologías de Azure AD Connect
Suscripciones, licencias, cuentas e inquilinos para ofertas de nube de Microsoft
Pasos siguientes
Ahora que comprende los conceptos fundamentales de Azure, aprenda a escalar con varias suscripciones de
Azure.
Escalado con varias suscripciones de Azure
Comprensión y alineación de la jerarquía de la
cartera
Las necesidades empresariales se suelen atender, mejorar o acelerar a través de la tecnología de la información.
Una colección de tecnologías que proporciona un valor empresarial definido se denomina carga de trabajo. Esa
colección puede incluir aplicaciones, servidores o máquinas virtuales, datos, dispositivos y otros recursos
agrupados de forma similar.
Normalmente, un responsable de la empresa y un líder técnico se reparten el apoyo continuo de cada carga de
trabajo. En algunas fases del ciclo de vida de la carga de trabajo, estos roles están claramente definidos. En otras
fases operativas del ciclo de vida de una carga de trabajo, esos roles se pueden transferir a un equipo de
administración de operaciones común o a un equipo de operaciones en la nube. A medida que aumenta el
número de cargas de trabajo, los roles (indicados o implícitos) son más complejos o están más estructurados en
matrices.
La mayoría de las empresas recurren a varias cargas de trabajo para proporcionar funciones empresariales
esenciales. La colección de cargas de trabajo, recursos y factores de apoyo (proyectos, personas, procesos e
inversiones) se denominan cartera. La matriz de personal de negocios, desarrollo y operaciones requiere una
jerarquía de cartera para mostrar cómo se combinan todas las cargas de trabajo y los servicios de apoyo.
En este artículo se proporcionan definiciones claras para los niveles de la jerarquía de la cartera. En el artículo se
alinean varios equipos con la responsabilidad correspondiente en cada capa, y se explicita además la mejor
fuente para obtener orientaciones a fin de que ese equipo cumpla con las expectativas de ese nivel. En este
artículo, cada nivel de la jerarquía también se conoce como ámbito.
Cargas de trabajo
Las cargas de trabajo y sus recursos de apoyo se sitúan en el centro de cualquier cartera. Los ámbitos o niveles
adicionales que se indican a continuación definen cómo se ven esas cargas de trabajo y hasta qué punto se ven
afectadas por la matriz de los posibles equipos de apoyo.
Aunque los términos pueden variar, todas las soluciones de TI incluyen recursos y cargas de trabajo:
Recurso: la unidad más pequeña de función técnica que respalda una carga de trabajo o solución.
Carga de trabajo: la unidad más pequeña de soporte de TI para la empresa. Una carga de trabajo es una
colección de recursos (infraestructura, aplicaciones y datos) que respaldan un objetivo empresarial común o
la ejecución de un proceso de negocio común.
Al implementar la primera carga de trabajo, esta y sus recursos pueden ser el único ámbito definido. El resto de
niveles se pueden definir explícitamente a medida que se implementan más cargas de trabajo.
Cartera de TI
Cuando las empresas admiten cargas de trabajo mediante enfoques con matrices o enfoques centralizados, es
probable que exista una jerarquía más amplia para admitir estas cargas de trabajo:
Zonas de aterrizaje: las zonas de aterrizaje ofrecen a las cargas de trabajo las utilidades fundamentales (o
la infraestructura compartida) necesarias que se proporcionan a partir de una base de plataforma que se
requiere para admitir una o varias cargas de trabajo. Las zonas de aterrizaje son un componente esencial en
la nube; tanto, que toda la metodología de preparación de Cloud Adoption Framework se centra en las zonas
de aterrizaje. Para obtener una definición más detallada, consulte ¿Qué es una zona de aterrizaje?
Utilidades fundamentales: estos servicios de TI compartidos son necesarios para que las cargas de
trabajo funcionen dentro de la tecnología y la cartera empresarial.
Base de plataforma: esta construcción de la organización centraliza las soluciones fundamentales y ayuda
a garantizar que esos controles se aplican a todas las zonas de aterrizaje.
Plataformas en la nube: en función de la estrategia global para apoyar toda la cartera, es posible que los
clientes necesiten varias plataformas en la nube con implementaciones distintas de la base de plataforma
para controlar varias regiones, soluciones híbridas o incluso soluciones de varias nubes.
Car tera: desde un punto de vista tecnológico, la cartera es una colección de cargas de trabajo y recursos de
apoyo que abarca todas las plataformas en la nube. Desde un punto de vista empresarial, la cartera es la
colección de proyectos, personas, procesos e inversiones que respaldan y administran la cartera tecnológica
para promover los resultados empresariales. Juntos, los dos puntos de vista permiten capturar la esencia de
la cartera.
Instrucciones y responsabilidad de la jerarquía
Un equipo responsable se encarga de administrar cada nivel de la jerarquía de la cartera. En el diagrama
siguiente se muestra la correlación entre el equipo responsable y las instrucciones para respaldar sus decisiones
técnicas y empresariales, y su consiguiente implementación técnica.
NOTE
Los equipos que se mencionan en la lista siguiente podrían ser equipos virtuales o personas individuales. En ciertas
variantes de esta jerarquía, algunos de los equipos responsables se pueden reducir tal y como se describe en las variantes
de responsabilidad que se indican a continuación.
Car tera: el equipo de estrategia en la nube y el centro de excelencia en la nube (CCoE) usan las
metodologías de estrategia y planeamiento para fundamentar las decisiones que afectan a la cartera de
forma global. El equipo de estrategia en la nube es responsable del nivel empresarial de la jerarquía de la
cartera de la nube. También se debe informar a este equipo sobre las decisiones relacionadas con el entorno,
las zonas de aterrizaje y las cargas de trabajo de prioridad alta.
Plataformas en la nube: el equipo de gobernanza de la nube es responsable de las disciplinas que
garantizan la coherencia en cada entorno en consonancia con la metodología de gobernanza. El equipo de
gobernanza de la nube es responsable de la gobernanza de todos los recursos en todos los entornos. Hay
que consultar al equipo de gobernanza de la nube en relación con aquellos cambios que puedan requerir
una excepción o un cambio en las directivas de gobierno. El equipo de gobernanza de la nube también debe
estar informado del progreso con respecto a la carga de trabajo y a la adopción de recursos.
Zonas de aterrizaje y base de la nube: el equipo de plataforma en la nube es responsable de desarrollar
las zonas de aterrizaje y las utilidades de plataforma que respaldan la adopción. El equipo de automatización
en la nube es responsable de automatizar el desarrollo y el apoyo continuo a esas zonas de aterrizaje y
utilidades de la plataforma. Ambos equipos usan la metodología de preparación para guiar la
implementación. Ambos equipos deben estar informados del progreso con la adopción de la carga de
trabajo y cualquier cambio en la empresa o el entorno.
Cargas de trabajo : la adopción se produce en el nivel de carga de trabajo. Los equipos de adopción de la
nube usan las metodologías de migración e innovación para establecer procesos escalables con el fin de
acelerar la adopción. Una vez completada la adopción, es probable que la propiedad de las cargas de trabajo
se transfiera a un equipo de operaciones en la nube que use la metodología de administración para dirigir la
administración de las operaciones. Ambos equipos deben estar familiarizados con el Marco de buena
arquitectura de Microsoft Azure para tomar decisiones arquitectónicas detalladas que afecten a las cargas de
trabajo que admiten. Ambos equipos deben estar informados de los cambios en los entornos y las zonas de
aterrizaje. Ambos equipos pueden colaborar ocasionalmente en las características de la zona de aterrizaje.
Recursos: los recursos suelen ser responsabilidad del equipo de operaciones en la nube. Ese equipo usa la
línea de base de administración de la metodología de administración para guiar las decisiones de
administración de operaciones. También debe usar Azure Advisor y el Marco de buena arquitectura de Azure
para realizar los cambios detallados en los recursos y la arquitectura necesarios para cumplir con los
requisitos de las operaciones.
Variantes de responsabilidad
Entorno único: cuando una empresa solo necesita un entorno, normalmente no es necesario un CCoE.
Zona de aterrizaje única: si un entorno tiene una sola zona de aterrizaje, es probable que las
funcionalidades de gobernanza y plataforma se puedan combinar en un solo equipo.
Carga de trabajo única: algunas empresas solo necesitan una carga de trabajo, o algunas cargas de
trabajo, en una única zona de aterrizaje y un único entorno. En estos casos, no es necesario separar las tareas
entre los equipos de gobernanza, plataforma y operaciones.
Ejemplos comunes de carga de trabajo y responsabilidad

En los siguientes ejemplos se muestra la jerarquía de la cartera.
Cargas de trabajo de soluciones de software comerciales
Tradicionalmente, las empresas han favorecido soluciones de software comerciales (COTS) para potenciar los
procesos empresariales. Estas soluciones se instalan, se configuran y, luego, se utilizan. Hay pocos cambios en la
arquitectura de soluciones después de la configuración.
En estos casos, cualquier adopción en la nube de soluciones de software comerciales termina con una transición
a un equipo de operaciones en la nube. Entonces, el equipo de operaciones en la nube se convierte en el
propietario técnico de ese software y asume la responsabilidad de administrar la configuración, el costo, los
ciclos de revisión y otras necesidades operativas.
Estas cargas de trabajo incluyen paquetes de contabilidad, software de logística o soluciones específicas del
sector. En la terminología de Microsoft, los proveedores de estos paquetes se denominan proveedores de
software independientes (ISV). Muchos ISV ofrecen un servicio para implementar y mantener una instancia de
su paquete de software en las suscripciones. También pueden ofrecer una versión del paquete de software que
se ejecuta en su propio entorno hospedado en la nube, lo que proporciona una alternativa de plataforma como
servicio (PaaS) a la carga de trabajo.
A excepción de las ofertas de PaaS, los equipos de operaciones en la nube son responsables de garantizar los
requisitos operativos de cumplimiento básicos de las cargas de trabajo. Un equipo de operaciones en la nube
debe trabajar con el equipo de gobernanza de la nube para acordar los costos, el rendimiento y el resto de
pilares de la arquitectura.
En desarrollo con revisiones activas
Cuando una solución de COTS o una oferta de PaaS no está en sintonía con la necesidad empresarial, o no existe
ninguna solución, las empresas crean cargas de trabajo desarrolladas a nivel personalizado. Normalmente, un
pequeño porcentaje de la cartera de TI utiliza este enfoque de carga de trabajo. Sin embargo, estas cargas de
trabajo tienden a impulsar un porcentaje desproporcionadamente elevado de la contribución de TI a los
resultados empresariales, especialmente los resultados relacionados con nuevos flujos de ingresos. Estas cargas
de trabajo tienden a asignarse bien a nuevas ideas de innovación.
Dados los diversos movimientos que se basan en metodologías ágiles y prácticas de DevOps, estas cargas de
trabajo priorizan una alineación empresarial/DevOps sobre la administración de TI tradicional. En el caso de
estas cargas de trabajo, puede que no haya una transferencia al equipo de operaciones en la nube durante
varios años. En estos casos, el equipo de desarrollo actúa como el propietario técnico de la carga de trabajo.
Como consecuencia del tiempo prolongado y las limitaciones de capital asociadas, las opciones de desarrollo
personalizado a menudo se limitan a oportunidades de valor elevado. Algunos ejemplos típicos son las
innovaciones de aplicaciones, el análisis profundo de los datos o las funciones empresariales críticas.
Resolución de problemas o desarrollo de ocaso
Una vez que una carga de trabajo con desarrollo personalizado alcanza el punto máximo de madurez, el equipo
de desarrollo se puede reasignar a otros proyectos. En estos casos, la propiedad técnica normalmente se
transfiere a un equipo de operaciones en la nube. Cuando se necesiten pequeñas correcciones, el equipo de
operaciones asignará a los desarrolladores la resolución de tales errores.
En algunos casos, el equipo de desarrollo pasa a trabajar en un proyecto que más adelante reemplazará la carga
de trabajo actual. También es posible que el cambio del equipo se deba a que la oportunidad empresarial
respaldada por la carga de trabajo se esté eliminando gradualmente. Estos son ejemplos de escenarios "de
ocaso", en los que el equipo de operaciones en la nube actúa como propietario técnico hasta que la carga de
trabajo ya no se necesita.
En ambos escenarios, el equipo de operaciones en la nube suele ejercer como propietario técnico a largo plazo y
responsable de la toma de decisiones. Ese equipo recurrirá probablemente a desarrolladores de aplicaciones
cuando los cambios operativos requieran cambios en la arquitectura significativos.
Cargas de trabajo críticas
En todas las organizaciones, hay algunas cargas de trabajo que por su gran importancia empresarial no pueden
sufrir ningún error. Con estas cargas de trabajo críticas, normalmente hay operaciones y propietarios de
desarrollo con varios niveles de responsabilidad. Esos equipos deben armonizar los cambios operativos y los
cambios arquitectónicos para minimizar las interrupciones en la solución de producción.
Estos escenarios requieren que se preste especial atención a la separación de obligaciones. Para lograr esta
separación, el equipo de operaciones normalmente mantendrá la responsabilidad de los cambios operativos
cotidianos en el entorno de producción. Si esos cambios operativos requieren un cambio en la arquitectura, el
equipo de desarrollo o adopción lo completará en un entorno de no producción para que a continuación el
equipo de operaciones aplique los cambios en producción.
Entre los ejemplos de cargas de trabajo críticas con una separación obligatoria de tareas se incluyen las cargas
de trabajo como SAP, Oracle u otras soluciones de planeación de recursos empresariales (ERP), que abarcan
varias unidades de negocio de la empresa.
Alineación de la cartera de estrategias

Es importante comprender los objetivos estratégicos del esfuerzo de adopción de la nube y la adaptación de la
cartera para respaldar esa transformación. Algunos tipos comunes de alineación estratégica de la cartera
ayudan a moldear la estructura de la jerarquía de cartera. En las secciones siguientes se proporcionan ejemplos
de la alineación de la cartera y su repercusión en la jerarquía de esta.
Cartera orientada a la innovación o el desarrollo
Algunas empresas, especialmente las startups de rápido crecimiento, tienen un porcentaje superior al promedio
de proyectos de desarrollo personalizados. En las carteras con importantes cargas de desarrollo, el entorno, la
zona de aterrizaje y las cargas de trabajo se suelen comprimir; por lo que puede haber entornos específicos (ya
sea de producción o de no producción) para cargas de trabajo específicas. Esto da como resultado una relación
1:1 entre el entorno, la zona de aterrizaje y la carga de trabajo.
Como el entorno hospeda soluciones personalizadas, la canalización DevOps y los informes en el nivel de
aplicación podrían sustituir la necesidad de funciones operativas y de gobernanza. En el caso de este cliente, es
probable que se preste menor atención a las operaciones, la gobernanza u otros roles de respaldo. También se
suele hacer mayor hincapié en las responsabilidades de la adopción de la nube y de los equipos de
automatización de la nube.
Alineación de car tera: la cartera de TI probablemente se centrará en las cargas de trabajo y los propietarios
de cargas de trabajo para impulsar decisiones de arquitectura críticas. Es probable que estos equipos
encuentren más valor en las instrucciones del Marco de buena arquitectura de Azure durante las actividades de
adopción y operaciones.
Definiciones de límite: los límites lógicos, incluso en un nivel empresarial, se centrarán probablemente en la
segmentación de entornos de producción y de no producción. También puede haber una segmentación clara
entre productos de la cartera de software de la empresa. En ocasiones, también puede haber segmentación
entre el desarrollo y las instancias de clientes hospedadas.
Cartera orientada a operaciones
Las organizaciones empresariales multinacionales con equipos de operaciones de TI más establecidos
generalmente se centran en mayor medida en la gobernanza y las operaciones que en el desarrollo. En estas
organizaciones, un porcentaje mayor de cargas de trabajo se alinea normalmente con las categorías de COTS o
resolución de problemas, mantenidas por los propietarios técnicos dentro del equipo de operaciones en la nube.
Alineación de car tera: la cartera de TI se alineará con la carga de trabajo, pero estas cargas de trabajo se
alinearán con unidades operativas o unidades de negocio. También se puede organizar en torno a los modelos
de financiación, industria o según otros requisitos de segmentación empresarial.
Definiciones de límite: las zonas de aterrizaje probablemente agruparán las aplicaciones en arquetipos de
aplicaciones para mantener operaciones similares en una segmentación similar. Es probable que los entornos se
refieran a construcciones físicas como el centro de datos, la nación, la región de proveedores de la nube u otros
estándares de organización operativa.
Cartera orientada a la migración
De forma similar a las carteras orientadas a operaciones, una cartera que se cree en gran medida a través de la
migración se basará en controladores empresariales específicos que lleven a la migración de los recursos
existentes. Normalmente, el centro de datos es el factor más importante en esos controladores.
Alineación de car tera: la cartera de TI se puede adaptar a la carga de trabajo, pero es más probable que se
adapte a los recursos. Si se han producido transiciones a las operaciones de TI en el historial de la empresa, es
posible que muchos recursos de uso activo no se asignen fácilmente a una carga de trabajo financiada. En estos
casos, muchos recursos podrían no tener una carga de trabajo definida o un propietario de la carga de trabajo
claro hasta el final del proceso de migración.
Definiciones de límite: las zonas de aterrizaje probablemente agruparán las aplicaciones en límites que
reflejan la segmentación local. Aunque no es un procedimiento recomendado, los entornos a menudo coinciden
con el nombre del centro de datos local y las zonas de aterrizaje que representan las prácticas de segmentación
de la red. Es recomendable adherirse a una segmentación que se adapte mejor con una cartera orientada hacia
las operaciones.
Cartera orientada a gobernanza
La alineación con los equipos de gobernanza debe llevarse a cabo lo antes posible. Con el uso de
procedimientos y herramientas de gobernanza en la nube, carteras y límites para los entornos puede equilibrar
mejor las necesidades de innovación, operaciones y esfuerzos de migración.
Alineación de car tera: las carteras orientadas a la gobernanza tienden a incluir puntos de datos que capturan
los detalles de la innovación y las operaciones, como la carga de trabajo, el propietario de las operaciones, la
clasificación de datos y la importancia operativa. Estos puntos de datos crean una vista completa de la cartera.
Definiciones de límite: los límites de una cartera orientada a la gobernanza tienden a favorecer las
operaciones sobre la innovación al usar una jerarquía impulsada por un grupo de administración que se asigna
a los criterios de las unidades de negocio y los entornos de desarrollo. En cada nivel de la jerarquía, un límite de
gobernanza en la nube puede tener diferentes grados de aplicación de directivas para permitir el desarrollo y la
flexibilidad creativa. Al mismo tiempo, se pueden aplicar requisitos en el nivel de producción a las suscripciones
de producción para garantizar la separación de las tareas y la coherencia de las operaciones.
¿Cómo respaldan los productos de Azure la
jerarquía de la cartera?
En Descripción y armonización de la jerarquía de la cartera, un conjunto de definiciones para la jerarquía de

cartera y la asignación de roles establecieron una jerarquía de ámbito para la mayoría de los enfoques de
cartera. Tal y como se indica en ese artículo, es posible que no necesite cada uno de los niveles o ámbitos
descritos. Minimizar el número de niveles reduce la complejidad, por lo que estos niveles no se deben ver como
algo obligatorio.
En este artículo se muestra cómo se respalda cada nivel o ámbito de la jerarquía en Azure mediante
herramientas organizativas, de implementación y gobernanza, y algunas soluciones de Microsoft Cloud
Adoption Framework para Azure.
Organización de la jerarquía en Azure

Azure Resource Manager incluye varios enfoques organizativos que ayudan a organizar los recursos en cada
nivel de la jerarquía de la nube.
Las barras de desplazamiento del diagrama siguiente muestran algunas variantes comunes de esta alineación.
Las partes en gris de las barras de desplazamiento son comunes pero solo se deben utilizar para requisitos
empresariales específicos. Los puntos después de la imagen describen un procedimiento recomendado.
Car tera: la unidad de negocio o empresa probablemente no contendrá ningún recurso técnico, pero puede
incidir en las decisiones de costos. Las unidades de negocio y empresa deben representarse en los nodos raíz
de la jerarquía de grupos de administración.
Plataformas en la nube: cada entorno debe tener su propio nodo en la jerarquía de grupos de
administración.
Zonas de aterrizaje y base de la nube : cada zona de aterrizaje se representa como una suscripción. Del
mismo modo, las bases de la plataforma estan contenidas en sus propias suscripciones. Algunos diseños de
suscripción podrían requerir una suscripción por nube o por carga de trabajo, lo que cambiaría la
herramienta de organización para cada uno de ellos.
Cargas de trabajo : cada carga de trabajo se representa como un grupo de recursos. Los grupos de
recursos también se usan normalmente para representar soluciones, implementaciones u otra agrupación
técnica de activos.
Recursos: cada recurso se representa de forma inherente como tal en Azure.
Organización con etiquetas

Las desviaciones del procedimiento recomendado son comunes. Puede registrarlas etiquetando todos los
recursos. Use una etiqueta para representar cada uno de los niveles pertinentes de la jerarquía. Para más
información, consulte las Convenciones recomendadas de nomenclatura y etiquetado.
Primeros pasos: Aceleración de la migración
La correcta alineación de las partes interesadas de la empresa y de TI ayuda a superar los obstáculos de la
migración y a acelerar los trabajos asociados a ella. En este artículo se proporcionan los pasos recomendados
para:
La alineación de las partes interesadas
El planeamiento de la migración
La implementación de una zona de aterrizaje
La migración de las diez primeras cargas de trabajo
También le ayuda a implementar procesos de administración y gobernanza adecuados.
Use esta guía para simplificar los procesos y materiales necesarios para adaptar un trabajo de migración global.
La guía usa las metodologías de Cloud Adoption Framework que se resaltan en esta ilustración.
Si el escenario de migración es atípico, puede obtener una valoración personalizada de la preparación de la

organización para la migración mediante la valoración estratégica de la herramienta de migración y preparación
(SMART). Úsela para identificar las instrucciones que mejor se adaptan a sus necesidades actuales.
Introducción
El trabajo y el proceso de carácter técnico necesarios para migrar las cargas de trabajo son relativamente
sencillos. Es importante completar el proceso de migración de forma eficaz. La preparación estratégica de la
migración tiene una repercusión incluso mayor en las escalas de tiempo y la finalización correcta de la
migración global.
Para acelerar la adopción, debe dar los pasos necesarios para apoyar al equipo de adopción de la nube durante
la migración. En esta guía se describen estas tareas iterativas para ayudar a los clientes a empezar con buen pie
cualquier migración a la nube. Para mostrar la importancia de estos pasos de apoyo, la migración aparece como
el paso 10 de este artículo. En la práctica, es probable que el equipo de adopción de la nube comience su
primera migración piloto en paralelo con los pasos 4 o 5.
Paso 1: Vinculación de las partes interesadas

Para evitar los impedimentos comunes de la migración, cree una estrategia de negocio clara y concisa para esta
operación. El acuerdo entre las partes interesadas sobre las motivaciones y los resultados empresariales
esperados conforma las decisiones que toma el equipo de adopción de la nube.
Motivaciones: el primer paso hacia un acuerdo estratégico es lograr el consenso sobre las motivaciones que
deben impulsar el trabajo de migración. Para empezar, conozca y clasifique tanto las motivaciones como los
temas comunes de las diversas partes interesadas en la empresa y en TI.
Resultados empresariales: Una vez que se alcanza un acuerdo sobre las motivaciones, será más fácil diseñar
los resultados empresariales deseados. Esta información proporciona métricas claras que se pueden usar
para medir la transformación global.
Use la plantilla de estrategia y plan para registrar las motivaciones y los resultados empresariales deseados.
Equipo de estrategia de la nube Equipo de adopción de la nube

Equipo de centro de excelencia de la nube o TI
centralizado
Paso 2: Vinculación del apoyo de los asociados

Durante el proceso de migración, dispondrá de la ayuda de los asociados, de los servicios de Microsoft y de
diversos programas de Microsoft.
Comprenda las opciones de asociación para encontrar el nivel adecuado de asociación y apoyo.
Establezca los términos y condiciones, u otras disposiciones contractuales, antes de contratar a un asociado
auxiliar.
Identifique los asociados aprobados en la plantilla de estrategia y plan.

centralizado
Paso 3: Recopilación de datos y análisis de recursos y cargas de

trabajo
Use la detección y la valoración para mejorar la alineación técnica, y cree un plan de acción para ejecutar su
estrategia. En este paso, determine cuál es el caso empresarial mediante el uso de datos sobre el entorno actual.
Luego, realice un análisis cuantitativo y una detallada evaluación cualitativa de las cargas de trabajo con mayor
prioridad.
Inventario de sistemas existentes: Use un enfoque controlado por datos de programación para conocer el
estado actual. Detecte y recopile datos para permitir todas las actividades de valoración.
Racionalización incremental: optimice los trabajos de valoración para que se centren en un análisis
cualitativo de todos los recursos (posiblemente incluso para respaldar el caso empresarial). A continuación,
agregue un profundo análisis cualitativo de las diez primeras cargas de trabajo que se van a migrar.
Datos sin procesar sobre el inventario existente
Análisis cuantitativo del inventario existente para refinar la justificación comercial
Análisis cualitativo de las 10 primeras cargas de trabajo
Justificación comercial documentada en la plantilla del plan y la estrategia.
Equipo de adopción de la nube Equipo de estrategia de la nube
Paso 4: Creación de un caso empresarial

La creación de un caso empresarial para la migración será probablemente una conversación que se repita entre
las partes interesadas. En este primer paso de generación del caso empresarial, evalúe la rentabilidad inicial
general de una posible migración a la nube. El objetivo de este paso es asegurarse de que todas las partes
interesadas se alineen en torno a una pregunta sencilla: en función de los datos disponibles, ¿la adopción global
de la nube es una decisión empresarial acertada?
La creación de un caso empresarial para la migración a la nube es un buen punto de partida. La claridad de
las fórmulas y herramientas puede ayudar en la justificación comercial.
Use la plantilla de estrategia y plan para registrar la justificación comercial.
Paso 5: Creación de un plan de migración

Un plan de adopción de la nube ofrece un enfoque acelerado para desarrollar un trabajo pendiente del proyecto,
que luego se puede modificar para que refleje los resultados de la detección, racionalización, desarrollo de las
aptitudes necesarias y contratación de asociados.
Plan de adopción de la nube: defina el plan de adopción de la nube mediante la plantilla básica.
Vinculación de las cargas de trabajo: Defina las cargas de trabajo en el trabajo pendiente.
Vinculación de los trabajos: vincule los recursos y las cargas de trabajo en el trabajo pendiente para definir
con claridad el trabajo para las cargas de trabajo con prioridad.
Vinculación de personas y tiempos: establezca la iteración, la velocidad (el tiempo de las personas) y las
versiones de las cargas de trabajo migradas.
Implemente la plantilla de trabajo pendiente.
Actualice la plantilla para que refleje las 10 primeras cargas de trabajo que se van a migrar.
Actualizar las personas y el progreso para calcular el plazo de lanzamiento.
Riesgos para los plazos:
La falta de familiaridad con Azure DevOps puede ralentizar el proceso de implementación.
La complejidad y los datos disponibles para cada carga de trabajo también pueden afectar a los
plazos.
Paso 6: Creación de un plan de preparación de aptitudes

Los empleados que hay actualmente pueden desempeñar un rol práctico en el trabajo de migración pero es
posible que se requieran aptitudes adicionales. En este paso, se buscan distintas formas de desarrollar esas
aptitudes o se recurre a asociados que puedan aportar dichas aptitudes.
Creación de un plan de preparación de aptitudes. Evalúe rápidamente las aptitudes actuales para identificar
qué otras aptitudes debe desarrollar el equipo.
Agregue un plan de preparación de aptitudes a la plantilla de estrategia y planeación.
Paso 7: Implementación y vinculación de una zona de aterrizaje

Todos los recursos migrados se implementan en una zona de aterrizaje. La zona de aterrizaje empieza de
manera sencilla para admitir cargas de trabajo más pequeñas y luego se escala para afrontar cargas de trabajo
más complejas con el paso del tiempo.
Elección de una zona de aterrizaje: encuentre el enfoque adecuado para implementar una zona de aterrizaje
basada en su patrón de adopción. A continuación, implemente esa base de código normalizada.
Expansión de la zona de aterrizaje: independientemente de cuál sea el punto de partida, identifique las
carencias de la zona de aterrizaje implementada y agregue los componentes necesarios para la organización
de los recursos, la seguridad, la gobernanza, el cumplimiento y las operaciones.
Implementación de una primera zona de aterrizaje para las migraciones iniciales de bajo riesgo.
Desarrollo de un plan de refactorización con el equipo del Centro de excelencia en la nube o el de TI central.
Los requisitos de gobernanza, operaciones y seguridad de las diez primeras cargas de trabajo pueden
ralentizar este proceso.
La refactorización de la primera zona de aterrizaje y de las zonas de aterrizaje sucesivas tarda más
tiempo, pero debe producirse en paralelo a los trabajos de migración.
Equipo de plataforma de la nube Equipo de adopción de la nube

centralizado
Paso 8: Migración de las primeras 10 cargas de trabajo
El trabajo técnico necesario para migrar las 10 primeras cargas de trabajo es relativamente sencillo. También es
un proceso iterativo que se repetirá a medida que se migran más recursos. En este proceso, se evalúan las
cargas de trabajo, se implementan y, después, se publican en un entorno de producción.
Las herramientas de migración a la nube permiten migrar todas las máquinas virtuales de un centro de datos en
un paso o iteración. Es más habitual migrar un número menor de cargas de trabajo durante cada iteración. La
división de la migración en etapas más pequeñas requiere un mayor planeamiento, pero reduce los riesgos
técnicos y el efecto de la administración de los cambios de la organización.
Con cada iteración, el equipo de adopción de la nube mejora la migración de las cargas de trabajo. Estos pasos
ayudan al equipo técnico a consolidar sus capacidades:
1. Migre sus primeras cargas de trabajo en un enfoque IaaS puro con las herramientas descritas en la guía de
migración de Azure.
2. Amplíe las opciones de las herramientas para usar la migración y la modernización mediante los ejemplos de
migración.
3. Desarrolle su estrategia técnica mediante los enfoques más amplios que se describen en los procedimientos
recomendados de migración de la nube de Azure.
4. Mejore la coherencia, confiabilidad y rendimiento mediante un enfoque de fábrica de migración eficaz, como
se describe en las mejoras del proceso de migración.
Mejora continua de la capacidad del equipo de adopción de migrar cargas de trabajo.

centralizado
Paso 9: Entrega de cargas de trabajo de producción a la gobernanza

de la nube
La gobernanza es un factor clave para el éxito a largo plazo de los trabajos de migración. La velocidad de la
migración y la repercusión empresarial son factores importantes. Sin embargo, la velocidad sin gobernanza
puede ser peligrosa. La organización debe tomar decisiones sobre la gobernanza que estén de acuerdo con los
patrones de adopción y las necesidades de gobernanza y cumplimiento.
Enfoque de gobernanza: Esta metodología describe un proceso para reflexionar sobre las directivas y los
procesos corporativos. Después de determinar el enfoque puede crear las materias necesarias para permitir
la gobernanza en los trabajos de adopción de la nube empresarial.
Base de gobernanza inicial: conozca las materias necesarias para crear un producto mínimo viable de
gobernanza que sirva de base para toda la adopción.
Prueba comparativa de gobernanzas: identifique brechas en el estado actual de gobernanza de la
organización. Obtenga un informe comparativo personalizado e instrucciones seleccionadas sobre cómo
empezar.
Implemente una base de gobernanza inicial.
Realice una prueba comparativa de las gobernanzas para planear futuras mejoras.
Riesgo de la línea de tiempo:
La mejora de la implementación de las directivas y la gobernanza puede suponer entre 1 y 4 semanas
más por materia.
Equipo de gobernanza de la nube Equipo de estrategia de la nube

centralizado
Paso 10: Entrega de cargas de trabajo de producción a operaciones

en la nube
La administración de las operaciones es otro requisito para alcanzar el éxito de la migración. La migración de
cargas de trabajo individuales a la nube sin conocer las operaciones empresariales en curso es una decisión
arriesgada. De forma paralela a la migración, debe empezar a planear operaciones a largo plazo.
Establecimiento de una base de referencia de administración
Definición de los compromisos empresariales
Expansión de la base de referencia de administración
Detalle de las operaciones avanzadas:
Implemente una base de referencia de administración.
Complete el libro de administración de operaciones.
Identifique cualquier carga de trabajo que requiera una valoración de la revisión de buena arquitectura de
Microsoft Azure.
Revise el libro: calcule una hora por propietario de la aplicación.
Complete la valoración de la revisión de buena arquitectura de Microsoft Azure: calcule una hora por
aplicación.
Equipo de operaciones en la nube Equipo de estrategia de la nube

centralizado
Declaración de valor
Estos pasos ayudan a los equipos a acelerar sus trabajos de migración gracias a una mejor administración de los
cambios y el acuerdo entre las partes interesadas. Con ellos también se eliminan los obstáculos habituales y se
obtiene un valor empresarial más rápidamente.
Pasos siguientes
Cloud Adoption Framework es una solución para todo un ciclo de vida que le ayuda a iniciar un recorrido de
migración. También le ayuda a consolidar los equipos que deben prestar asistencia a los trabajos de migración.
Los siguientes equipos pueden seguir estos pasos para seguir consolidando sus capacidades. Estos procesos
paralelos no son lineales y no se deben considerar obstáculos. Por el contrario, cada uno es un flujo de valor
paralelo que ayuda a mejorar la preparación general de la organización para la nube.
T EA M SIGUIEN T E IT ERA C IÓ N
Equipo de adopción de la nube Use el modelo de migración para pasar a una factoría de
migración que proporcione funcionalidades eficaces de
migración continuas.
Equipo de estrategia de la nube Mejore de forma continuada la metodología de estrategia y

la metodología de planeamiento, junto con el plan de
adopción. Lea estas introducciones y siga realizando
iteraciones en sus estrategias empresariales y técnicas.
Equipo de plataforma de la nube Vuelva a consultar la metodología de preparación para

seguir avanzando en la plataforma global de nube que
admite la migración u otros trabajos de adopción.
Equipo de gobernanza de la nube Use la metodología de gobernanza para continuar

mejorando los procesos, las directivas y las materias de
gobernanza.
Equipo de operaciones en la nube Avance en la metodología de administración para

proporcionar operaciones enriquecidas en Azure.
Si el escenario de migración es atípico, puede obtener una valoración personalizada de la preparación de la

organización para la migración mediante la valoración estratégica de la herramienta de migración y preparación
(SMART). Las respuestas que dé ayudan a identificar qué guía es la que más se ajusta a sus necesidades actuales.
Primeros pasos: Aceleración de la innovación en
productos y servicios en la nube
La creación de nuevos productos y servicios en la nube requiere un enfoque diferente al de la migración. La

metodología de innovación de Cloud Adoption Framework establece un enfoque que sirve de orientación para
el desarrollo de nuevos productos y servicios.
En esta guía se usan las secciones de Cloud Adoption Framework que se destacan en la siguiente ilustración. La
innovación es menos predecible que una migración estándar, pero aún encaja en el contexto de un plan de
adopción más amplio de la nube. Esta guía ayuda a la empresa a proporcionar el soporte técnico necesario para
innovar y ofrecer una estructura para crear una cartera equilibrada durante la adopción de la nube.
Figura 1: Metodologías de Cloud Adoption Framework, incluida la metodología de innovación.
Paso 1: Documentación de la estrategia empresarial

Para evitar los obstáculos comunes, cree una estrategia de negocio clara y concisa para la innovación. El acuerdo
entre las partes interesadas sobre las motivaciones y los resultados empresariales esperados conforma las
decisiones que toma el equipo de adopción de la nube.
Usar la plantilla de estrategia y plan para registrar las motivaciones y los resultados empresariales deseados.
Motivaciones: el primer paso hacia un acuerdo estratégico es lograr el consenso sobre las motivaciones que
deben impulsar el trabajo de innovación. Para empezar, conozca y clasifique tanto las motivaciones como los
temas comunes de las partes interesadas en la empresa y en TI.
Resultados empresariales: Una vez que se alcanza un acuerdo sobre las motivaciones, será más fácil diseñar
los resultados empresariales deseados. Esta información proporciona métricas claras que se pueden usar
para medir la transformación global.
Equilibrio de la cartera: La innovación no es el método de adopción adecuado para todas las cargas de
trabajo. Este enfoque de adopción es más pertinente para las nuevas aplicaciones o cargas de trabajo
creadas de forma personalizada que requieren cambios en la arquitectura o recompilaciones completas.
Cuando las motivaciones favorecen en gran medida la innovación de todas las cargas de trabajo, es
importante evaluar la cartera para asegurarse de que estas inversiones pueden producir la rentabilidad de la
inversión deseada. La modernización de recursos específicos y los esfuerzos de recompilación a pequeña
escala pueden ser innovadores, pero podrían atenderse mejor si se sigue Primeros pasos: Aceleración de la
migración.

centralizado
Paso 2: Evaluación de la justificación comercial

En este primer paso de generación de un motivo comercial, evalúe la rentabilidad inicial general de un posible
esfuerzo de adopción de la nube. El objetivo de este paso es que todas las partes interesadas se alineen en torno
a una pregunta sencilla: en función de los datos disponibles, ¿la adopción global de la nube es una decisión
empresarial acertada? A partir de esa pregunta, el equipo puede unificar mejor los criterios sobre cómo este
proyecto de innovación ayuda a satisfacer las necesidades previstas de los usuarios dentro del objetivo de
Use la plantilla de estrategia y planeamiento para registrar la justificación comercial.
Guía para apoyar la finalización de los resultados:
Justificación empresarial: antes de evaluar cada oportunidad de innovación en la nube, complete una
justificación comercial general para establecer la alineación de las partes interesadas para el plan de
adopción global.
Consenso del valor empresarial: Cuantificar el valor de una innovación puede ser difícil durante una etapa
temprana del proceso. El ejercicio de este artículo puede ayudar a evaluar la alineación de un esfuerzo de
innovación específico con respecto al valor empresarial.
Paso 3: Recopilación de datos y análisis de recursos y cargas de

trabajo
En la mayoría de las empresas, la innovación se puede acelerar mediante los recursos existentes, como
aplicaciones, máquinas virtuales y datos. Al planear la innovación, es importante comprender cómo y cuándo se
migrarán esos recursos a la nube.
Obtenga los datos sin procesar del inventario existente, como las aplicaciones, las máquinas virtuales y los
datos.
Si la innovación propuesta tiene dependencias en el inventario existente, complete los siguientes resultados
esperados:
Análisis cuantitativo de cualquier inventario auxiliar necesario para apoyar la innovación planeada.
Análisis cualitativo de cualquier carga de trabajo auxiliar necesaria para lograr la innovación.
Calcule el costo del nuevo inventario necesario para apoyar el esfuerzo de innovación.
Actualice la justificación comercial en la plantilla de estrategia y planeamiento con cálculos refinados.
Guía para completar las entregas:
La detección y la evaluación proporcionan un nivel más profundo de alineación técnica. Después, puede crear un
plan de acción para migrar las cargas de trabajo dependientes que requiera la innovación planeada. Este
escenario es habitual cuando las empresas tienen orígenes de datos existentes, aplicaciones centralizadas o
capas de servicio necesarias para lograr la innovación en el contexto del resto de la empresa.
En el caso de sistemas dependientes, los artículos siguientes pueden ofrecer orientación sobre la detección y la
evaluación:
Inventario de sistemas existentes: el primer paso es comprender el estado actual a partir de un enfoque
controlado por datos mediante programación. Detecte y recopile datos para permitir todas las actividades de
valoración.
agregue un análisis cualitativo profundo para las 10 primeras cargas de trabajo.
Paso 4: Planeamiento de la migración de recursos dependientes

Cuando la innovación depende de las cargas de trabajo o los recursos existentes, un plan de adopción de la
nube proporciona un enfoque acelerado para desarrollar un trabajo pendiente del proyecto. luego se puede
modificar para que refleje los resultados de la detección, racionalización, desarrollo de las aptitudes necesarias y
contratación de asociados.
Actualice las personas y el progreso (tiempo de las personas) para calcular el plazo de lanzamiento.
plazos.
Plan de adopción de la nube: defina el plan mediante la plantilla básica.
Alineación del trabajo: alinee los recursos y las cargas de trabajo en el trabajo pendiente para definir con
claridad el esfuerzo para las cargas de trabajo con prioridad.
Vinculación de personas y tiempos: establezca la iteración, el progreso y las versiones de las cargas de
trabajo.
Paso 5: Alineación de los requisitos de gobernanza con el plan de

adopción
Conversar sobre las innovaciones planeadas con el equipo de gobernanza le ayuda a evitar muchos obstáculos
antes de que surjan. A veces, las soluciones innovadoras podrían exigir prácticas que no se recomiendan en las
prácticas de gobernanza sólidas. Es posible que las herramientas de cumplimiento de gobernanza
automatizadas bloqueen algunas de esas características necesarias.
Generar transparencia y comprensión entre las necesidades de innovación y las restricciones de gobernanza.
Cuando sea necesario, actualizar las directivas y los procesos para que reflejen cualquier cambio o excepción
en las restricciones de gobernanza existentes.
Estos vínculos ayudan al equipo de adopción a comprender el enfoque adoptado por el equipo de gobernanza
de la nube:
Enfoque de gobernanza: esta metodología describe un proceso para pensar en las directivas y los procesos
corporativos, a fin de que pueda crear posteriormente las materias necesarias para proporcionar gobernanza
a los trabajos empresariales de la nube.
Definición de la directiva corporativa: Identifique y mitigue los riesgos empresariales.

Equipo de adopción de la nube Equipo de centro de excelencia de la nube o TI
centralizado
Paso 6: Definición de las necesidades operativas y los compromisos

empresariales
Defina el plan de responsabilidades operativas a largo plazo para la innovación planeada. La base de referencia
de administración establecida, ¿satisface sus necesidades operativas? Si no es así, evalúe las opciones de las
operaciones de financiamiento que sean específicas de la tecnología que admite esta innovación.
Complete la Revisión de la arquitectura de Microsoft Azure para evaluar varias decisiones sobre arquitectura
y operaciones.
Ajustar el libro de administración de operaciones para reflejar las operaciones avanzadas necesarias.
Expansión de la base de referencia de administración: Esta sección de Cloud Adoption Framework le guía por
diversas transiciones hasta la administración operativa de la nube.
Detalle de las operaciones avanzadas: Descubra formas de ir más allá de la base de referencia de
administración.
Si se necesita operaciones avanzadas para satisfacer sus necesidades de operaciones, evalúe los
compromisos empresariales para establecer las responsabilidades operativas de ambos equipos.

centralizado
Paso 7: Implementación de una zona de aterrizaje alineada

Todos los recursos hospedados en la nube residen en una zona de aterrizaje. Esa zona de aterrizaje puede tener
requisitos explícitos de gobernanza, seguridad y operación. O bien, podría tratarse de una nueva suscripción, sin
asistencia de otros equipos. En cualquiera de estos escenarios, es importante empezar con una zona de
aterrizaje que se alinee con los requisitos de gobernanza y operación desde el principio.
Comenzar con una zona de aterrizaje aprobada ayudará al equipo a detectar infracciones de las directivas en
una etapa temprana del desarrollo, en lugar de hacerlo una vez enviada la solución a producción. La detección
temprana ayuda al equipo a eliminar obstáculos y concede a los equipos de adopción y gobernanza el tiempo
suficiente para realizar cambios.
Implementar una primera zona de aterrizaje para la experimentación inicial y de bajo riesgo durante la
innovación temprana.
Desarrollar un plan de refactorización con el centro de excelencia en la nube o el equipo de TI central para
garantizar la alineación de la gobernanza, la seguridad y las operaciones.
ralentizar este proceso. La refactorización tanto de la primera zona de aterrizaje como de las zonas
sucesivas tarda más tiempo, pero debe producirse en paralelo con los trabajos de migración.
Elección de una zona de aterrizaje: siga esta sección para encontrar el enfoque adecuado para implementar
una zona de aterrizaje basada en el patrón de adopción. A continuación, implemente esa base de código
normalizada.
Expansión de la zona de aterrizaje: con independencia del punto de partida, identifique las brechas en la zona
de aterrizaje implementada para agregar los componentes necesarios para la organización de recursos, la
seguridad, la gobernanza, el cumplimiento y las operaciones.

centralizado
Paso 8: Innovación en la nube

La metodología de innovación brinda una guía sobre las herramientas y los enfoques de administración de
productos que se usan con más frecuencia para innovar en la nube. Los pasos siguientes le ayudarán a empezar
a trabajar con este enfoque.
Soluciones basadas en tecnología que mejoran la vida de sus clientes e impulsan el valor de la empresa.
Procesos y herramientas para iterar esas soluciones más rápidamente y añadir más valor mediante la nube:
Enfoques de desarrollo iterativo.
Aplicaciones personalizadas.
Experiencias basadas en tecnología.
Integración de productos físicos y tecnología mediante IoT.
Inteligencia ambiental: Integración de tecnología no intrusiva en un entorno.
Azure Cognitive Services: soluciones de macrodatos, IA, aprendizaje automático y predicción.
Consenso del valor empresarial: si transcurrieron más de tres meses desde el último consenso sobre el valor
empresarial, o si nunca se completó ninguno, empiece aquí.
Guía de innovación de Azure: use la guía de innovación de Azure para acelerar la implementación de
soluciones innovadoras mediante la comprensión de las herramientas y los procesos que pueden ayudarle a
crear un producto viable mínimo (MVP).
Procedimientos recomendados de innovación: combine los servicios de Azure para crear una cadena de
herramientas para la invención digital.
Bucles de comentarios: Desarrolle bucles de comentarios mejorados para proporcionar rápidamente
innovaciones eficaces a los clientes.
Paso 9: Evaluación de la madurez en innovación de su organización

Para apoyar el desarrollo de su estrategia de innovación, la herramienta de evaluación de la preparación de IA es
un recurso gratuito que ayuda a las organizaciones a evaluar su capacidad de crear y poseer sistemas basados
en IA. Hay cuatro niveles de madurez: básico, aproximado, aspiracional y maduro. Cada uno de ellos incluye un
conjunto específico de características que ayudan a determinar la capacidad de la organización de adoptar tipos
específicos de soluciones de inteligencia artificial, mitigar los riesgos asociados e implementar estrategias.
La evaluación tarda de 5 a 10 minutos y mide la capacidad de su organización en cuatro categorías: estrategia,
cultura, características organizativas y funcionalidades. La medición de estas categorías permite a la herramienta
de evaluación de la preparación de IA calcular la puntuación de la organización y proporcionar una estimación
de la madurez de la innovación en inteligencia artificial en una curva.
Use el modelo de madurez para la IA de Gartner para evaluar la madurez de IA de su organización con el fin
crear sistemas basados en IA.
Una vez completada la evaluación, la salida de la herramienta proporcionará una puntuación con una
estimación del estado de madurez para la innovación en inteligencia artificial.

Equipo de adopción de la nube Centro de excelencia de la nube

centralizado
Los pasos descritos en esta guía pueden ayudar a usted y a sus equipos a crear soluciones innovadoras en la
nube que creen valor empresarial, se rijan adecuadamente y estén bien diseñadas.
Pasos siguientes
Cloud Adoption Framework es una solución de ciclo de vida. Puede ayudarle a iniciar un recorrido de
innovación. Puede ayudar a su organización a emprender un recorrido de innovación, pero también a avanzar
en la madurez de los equipos que respaldan los esfuerzos de innovación.
Los siguientes equipos pueden seguir estos pasos para seguir avanzando en la madurez de sus trabajos. Estos
procesos paralelos no son lineales y no se deben ver como impedimentos. Por el contrario, cada uno es un flujo
de valor paralelo que contribuye a la madurez de la preparación general de la empresa para la nube.
T EA M SIGUIEN T E IT ERA C IÓ N
Equipo de adopción de la nube Las mejoras de procesos ofrecen conclusiones sobre los
métodos para lograr innovaciones que afecten a los clientes
y provoquen la adopción recurrente.
Equipo de estrategia de nube La metodología de estrategia y la metodología del plan son

procesos iterativos que evolucionan con el plan de adopción.
Vuelva a estas páginas de información general y siga
iterando sus estrategias empresariales y técnicas.
Equipo de plataforma de nube Vuelva a consultar la metodología de preparación para

seguir avanzando en la plataforma global de nube que
admite la migración u otros trabajos de adopción.
Equipo de gobernanza de la nube Use la metodología de gobernanza para continuar

mejorando los procesos, las directivas y las materias de
gobernanza.
Equipo de operaciones de la nube Avance en la metodología de administración para

proporcionar operaciones enriquecidas en Azure.
Primeros pasos: Diseño y configuración del entorno
El diseño y la configuración del entorno son los obstáculos más frecuentes para los trabajos de adopción
centrados en la migración o innovación. La rápida implementación de un diseño que admita un plan de
adopción a largo plazo a veces puede resultar complicado. En este artículo se establece un enfoque y una serie
de pasos que ayudan a superar los obstáculos más habituales y a acelerar los trabajos de adopción.
La iniciativa técnica necesaria para crear un diseño y una configuración de entorno eficaces puede resultar
compleja. Puede administrar el ámbito para mejorar las probabilidades de éxito del equipo de plataforma en la
nube. El mayor desafío es la coordinación de varias partes interesadas. Algunas de estas partes interesadas
tienen la autoridad para detener o ralentizar las iniciativas de adopción. En estos pasos se describen las distintas
formas de cumplir rápidamente los objetivos a corto plazo, así como de establecer el éxito a largo plazo.
Paso 1: Documentación de la estrategia empresarial

Para evitar los obstáculos comunes de la migración, asegúrese de tener una estrategia de negocio clara y
concisa. La alineación de las partes interesadas en las motivaciones, los resultados empresariales esperados y la
justificación empresarial es importante a lo largo de todo el proceso de adopción y configuración del entorno.
Una estrategia empresarial clara y concisa ayuda al equipo de plataforma en la nube a saber lo que es
importante y a lo que se debe dar prioridad cuando se toman decisiones de configuración del entorno. En
concreto, ayuda a los equipos a tomar decisiones cuando tienen que elegir entre la velocidad de innovación o el
cumplimiento de los controles.
Use la plantilla de estrategia y planeamiento para registrar las motivaciones, los resultados empresariales
deseados y la justificación comercial de alto nivel.
Descripción de las motivaciones empresariales: el primer paso hacia un acuerdo estratégico es estar de
acuerdo sobre las motivaciones que deben impulsar el trabajo de migración. Para empezar, conozca y
clasifique tanto las motivaciones como los temas comunes de las diversas partes interesadas en la empresa y
en TI.
Documentación de los resultados empresariales: Una vez que se alcanza un acuerdo sobre las motivaciones,
se pueden fijar los resultados empresariales deseados. Esta información proporciona métricas claras que se
pueden usar para medir la transformación global.
Creación de un caso empresarial de migración a la nube: empiece a desarrollar un caso empresarial para la
migración que incluya directrices claras sobre las fórmulas y herramientas que ayuden a determinar la
justificación comercial.
EQ UIP O EN C A RGA DO EQ UIP O S RESP O N SA B L ES Y DE A P O Y O EQ UIP O S A LO S Q UE SE IN F O RM A
Equipo de estrategia de la nube Equipo de adopción de la nube Equipo de plataforma de la nube

Equipo de centro de excelencia de la
nube o TI centralizado
Paso 2: Evaluación del patrimonio digital

La detección y valoración proporcionan un nivel más profundo de adecuación técnica lo que le ayuda a crear un
plan viable que se puede emplear para poner en práctica la estrategia. Durante este paso, se valora el caso
empresarial mediante el uso de datos sobre el estado actual del entorno. A continuación, se realiza un análisis
cuantitativo de esos datos y una evaluación cualitativa detallada de las cargas de trabajo con mayor prioridad.
La salida de la valoración del patrimonio digital proporciona al equipo de la plataforma en la nube una vista
clara del entorno del estado final y los requisitos que son necesarios para dar soporte al plan de adopción.
Datos sin procesar del inventario existente.
Análisis cuantitativo del inventario existente para refinar la justificación comercial.
Análisis cualitativo de las diez primeras cargas de trabajo.
Justificación comercial actualizada en la plantilla de estrategia y planeamiento.
Inventario de sistemas existentes: El primer paso es conocer el estado actual a partir de un enfoque
controlado por datos mediante programación. Busque y recopile datos para habilitar todas las actividades de
valoración.
agregue un profundo análisis cualitativo de las diez primeras cargas de trabajo que se van a migrar.
Equipo de adopción de la nube Equipo de estrategia de la nube Equipo de plataforma de la nube
Paso 3: Creación de un plan de adopción de la nube

El plan de adopción de la nube ofrece un enfoque acelerado para desarrollar un trabajo pendiente del proyecto,
que luego se puede modificar para que refleje los resultados de la valoración, racionalización, desarrollo de las
aptitudes necesarias y contratación de asociados.
Un examen tanto del plan de adopción de la nube a corto plazo como del trabajo pendiente ayuda al equipo de
plataforma en la nube a conocer las necesidades del entorno en los próximos meses. Este antecedente ayuda a
ajustar la "definición de finalización" en las primeras zonas de aterrizaje.
Actualice las personas y el progreso (tiempo de las personas) para calcular el plazo de lanzamiento.
plazos.
Plan de adopción de la nube: defina el plan mediante la plantilla básica.
Alineación del trabajo: Alinee los recursos y las cargas de trabajo del trabajo pendiente para definir con
claridad los trabajos de las cargas de trabajo clasificadas por orden de prioridad.
Vinculación de personas y tiempos: establezca la iteración, el progreso y las versiones de las cargas de
trabajo que se migrarán.
Equipo de adopción de la nube Equipo de estrategia de la nube Equipo de plataforma de la nube

Equipo de plataforma de la nube
Paso 4: Implementación de la primera zona de aterrizaje

Inicialmente, el equipo de adopción de la nube necesita una zona de aterrizaje que pueda admitir los requisitos
de la primera ola de cargas de trabajo. Con el tiempo, la zona de aterrizaje se escala para hacer frente a cargas
de trabajo más complejas. Por el momento, comience con una zona de aterrizaje que permita la primera fase del
aprendizaje del equipo de plataforma en la nube y el equipo de adopción de la nube.
Implemente una primera zona de aterrizaje para migraciones iniciales de bajo riesgo.
Desarrolle un plan de refactorización con el centro de excelencia en la nube o el equipo de TI central.
ralentizar este proceso. La refactorización real de la primera zona de aterrizaje y de las zonas de
aterrizaje sucesivas tarda más tiempo, pero debe producirse en paralelo a los trabajos de migración.
Elección de una zona de aterrizaje: siga esta sección para encontrar el enfoque adecuado para implementar
una zona de aterrizaje basada en el plan de adopción a corto plazo. A continuación, implemente esa base de
código normalizada.
Expansión de la zona de aterrizaje: No intente cumplir las restricciones de gobernanza, seguridad u operación
a largo plazo aún, a menos que sean necesarias para dar soporte al plan de adopción a corto plazo.

centralizado
Paso 5: Implementación de una base de gobernanza inicial
La gobernanza es un factor clave para el éxito a largo plazo de los trabajos de migración. La velocidad de la
migración y la repercusión empresarial son factores importantes. Sin embargo, la velocidad sin gobernanza
puede ser peligrosa. La organización debe tomar decisiones sobre la gobernanza que estén de acuerdo con los
patrones de adopción y las necesidades de gobernanza y cumplimiento.
A medida que se toman esas decisiones, se incluyen en los trabajos del equipo de la plataforma en la nube.
Implemente una base de gobernanza inicial.
Realice una prueba comparativa de las gobernanzas para planear futuras mejoras.
La mejora de la implementación de las directivas y la gobernanza puede suponer entre 1 y 4 semanas
más por materia.
Enfoque de gobernanza: esta metodología describe un proceso para pensar en las directivas y los procesos
corporativos, a fin de crear posteriormente las materias necesarias para proporcionar gobernanza a los
trabajos de adopción empresarial de la nube.
Herramienta de prueba comparativa de gobernanzas: busque huecos en su estado actual para poder planear
el futuro.
Base de gobernanza inicial: conozca las materias de gobernanza que se necesitan para crear un producto
mínimo viable (MVP) que sirva de base para toda la adopción.
EQ UIP O EN C A RGA DO EQ UIP O S RESP O N SA B L ES Y DE A P O Y O EQ UIP O S DE C O N SULTA
Equipo de gobernanza de la nube Equipo de estrategia de la nube Equipo de plataforma de la nube

Paso 6: Implementación de una base de referencia de operaciones

Resulta arriesgado realizar la migración a la nube sin conocer las operaciones en curso. En paralelo a la
migración, empiece a planear las operaciones a largo plazo. Incluya esos planes de nuevo en los trabajos en
paralelo del equipo de la plataforma de nube.
Implemente una base de referencia de administración.
Complete el libro de administración de operaciones.
Identifique cualquier carga de trabajo que requiera una valoración de la revisión de buena arquitectura de
Microsoft Azure.
Revise el libro: calcule una hora por propietario de la aplicación.
Complete la evaluación de la revisión de buena arquitectura de Microsoft Azure: calcule una hora por
aplicación.
Establecimiento de una base de referencia de administración
Definición de los compromisos empresariales
Expansión de la base de referencia de administración
Detalle de las operaciones avanzadas
EQ UIP O EN C A RGA DO EQ UIP O S RESP O N SA B L ES Y DE A P O Y O EQ UIP O S DE C O N SULTA
Equipo de operaciones en la nube Equipo de estrategia de la nube Equipo de plataforma de la nube

Paso 7: Expansión de la zona de aterrizaje

En cuanto el equipo de adopción de la nube comienza sus primeras migraciones, el equipo de la plataforma en
la nube puede empezar con la configuración del entorno del estado final, con el soporte de los equipos de
gobernanza de la nube y operaciones en la nube. Según el ritmo del plan de adopción de la nube, este proceso
quizá deba realizarse en lanzamientos iterativos. Las funcionalidades se puede agregar con anticipación a los
requisitos del plan de adopción.
Adopte un método de desarrollo controlado por pruebas para refactorizar las zonas de aterrizaje.
Mejore la gobernanza de la zona de aterrizaje.
Expanda las operaciones en la zona de aterrizaje.
Implemente la seguridad en la zona de aterrizaje.
Desarrollo controlado por pruebas de las zonas de aterrizaje
Expansión de las operaciones en la zona de aterrizaje
Expansión de la seguridad de la zona de aterrizaje

centralizado
Los pasos que se describen en esta guía pueden ayudarle tanto a usted como a sus equipos a acelerar la
consecución de un entorno de nube listo para la empresa que esté configurado correctamente.
Pasos siguientes
Tenga en cuenta los siguientes pasos en una iteración futura que se base en sus trabajos iniciales:
Rutas de aprendizaje de la preparación técnica del entorno
Lista de comprobación del planeamiento del entorno de migración
Conseguir el éxito de los clientes con un modelo
operativo sólido y la alineación organizacional
El éxito de los clientes en los trabajos de adopción de la nube suele tener poco que ver con las aptitudes técnicas
o los proyectos relacionados con la adopción. El modelo operativo crea oportunidades para permitir la adopción
o impedimentos que podrían ralentizar la adopción de la nube.
Alignment
Al impulsar la innovación, la alineación entre los equipos de negocios y técnicos es fundamental para el éxito de
la solución.
En el caso de las partes interesadas de negocios, se ha creado Microsoft AI Business School para apoyar el
desarrollo de la estrategia empresarial y ofrecer procedimientos recomendados de ejemplo.
En el caso de las partes interesadas técnicas, las rutas de aprendizaje de IA de Microsoft están disponibles
para ayudarle a crear nuevas aptitudes de AA.
Impedimentos
Cuando la adopción de la nube se ralentiza o se estanca, puede ser aconsejable evaluar el modelo operativo
para que todo vaya siempre bien. Cuando algo falla en alguna carga de trabajo a otra o algún proyecto, podría
deberse a una falta de alineación en el modelo operativo. Si hay más de un proyecto estancado debido a
directivas que los bloquean, procesos obsoletos o falta de vinculación entre las personas, es probable que
también sea culpa del modelo operativo.
Oportunidades
Además de comprobar los impedimentos comunes, se pueden implementar en la cartera mejoras incrementales
de algunas oportunidades clave en el modelo operativo. En concreto, los clientes suelen querer aumentar la
excelencia operativa, la optimización de costos, la seguridad, la confiabilidad, el rendimiento o la administración
de personas. Elevar estas conversaciones al nivel de cartera puede ayudar a llevar los procedimientos
recomendados de los equipos centrados en cargas de trabajo específicas a todos los demás proyectos y cargas
de trabajo.
Guías de introducción a los modelos operativos para los equipos

Las guías siguientes le ayudarán a empezar a alinear el modelo operativo y a mejorarlo con el tiempo.
¿Cómo se proporciona excelencia operativa durante la Los pasos de esta guía pueden ayudar al equipo de
transformación de la nube? estrategia a llevar a cabo la administración de los cambios
organizacionales necesarios para garantizar
sistemáticamente la excelencia operativa.
¿Cómo se administran los costos empresariales? Comience por optimizar los costos empresariales y
administrar los costos en todo el entorno.
¿Cómo se protege de forma sistemática el entorno de nube Esta guía de introducción ayuda a garantizar que se han
empresarial? aplicado los requisitos de seguridad adecuados en toda la
empresa, con el fin de reducir el riesgo de infracciones y
acelerar la recuperación cuando estas se produzcan.
¿Cómo se aplican los controles adecuados para mejorar la Esta guía de introducción ayuda a reducir las interrupciones
confiabilidad? relacionadas con las incoherencias en la configuración, la
organización de recursos, las bases de referencia de
seguridad o las directivas de protección de recursos.
¿Cómo se garantiza el rendimiento en toda la empresa? Esta guía de introducción puede ayudarle a establecer
procesos para garantizar el rendimiento en toda la empresa.
¿Cómo alineamos nuestra organización? Esta guía de introducción puede ayudarle a establecer una
estructura organizativa con el personal adecuado.
Principios arquitectónicos compartidos

Los principios básicos de un modelo operativo bien administrado se basan en un conjunto de principios de
arquitectura comunes. La guía de introducción de esta serie de artículos ayudará a los equipos de apoyo en la
medida en que extiendan estos principios a la plataforma de nube y a toda la cartera de cargas de trabajo.
Figura 1: Principios de la arquitectura compartida.

Estos principios se comparten entre Azure Advisor, el Marco de buena arquitectura de Microsoft Azure y las
soluciones del Centro de arquitectura de Azure:
Azure Advisor evalúa los principios de los recursos individuales entre soluciones, cargas de trabajo y la
cartera completa.
El Centro de arquitectura de Azure aplica estos principios para desarrollar y administrar soluciones técnicas
específicas.
Además, el Marco de buena arquitectura de Microsoft Azure ayuda a equilibrar estos principios en una carga
de trabajo para guiar las decisiones sobre la arquitectura.
Cloud Adoption Framework garantiza que los principios se adaptan a toda la cartera para permitir equipos
de adopción en un entorno bien administrado.
Primeros pasos: Entrega en la excelencia operativa
durante la transformación digital
¿Cómo puede garantizar la excelencia operativa durante la transformación digital? La excelencia operativa es
una función empresarial que afecta directamente a las decisiones de TI. Para lograr la excelencia operativa se
centra, debe centrarse en el valor para clientes y partes interesadas, con una visión constante de los ingresos, el
riesgo y el impacto en los costos.
Este enfoque de administración de cambios organizativos requiere lo siguiente:
Una estrategia definida.
Resultados empresariales claros.
Planeación de la administración de cambios.
Desde la perspectiva de la nube, puede administrar el impacto del riesgo y el costo realizando cambios
posteriores a la adopción y refinando continuamente los procesos operativos. Las áreas que se deben
supervisar incluyen la automatización de sistemas, las prácticas de administración de operaciones de TI y la
materia de coherencia de los recursos a lo largo del ciclo de vida de adopción de la nube.
Los pasos de este artículo pueden ayudar al equipo de estrategia a llevar a cabo la administración de cambios
en la organización necesaria para garantizar de forma sistemática la excelencia operativa.
La excelencia operativa en toda la empresa y la cartera comienza con procesos del mismo nivel relativos a la
estrategia y planificación para alinear e informar de las expectativas de la administración de cambios
organizacionales. Los pasos siguientes ayudan a los equipos técnicos a ofrecer las disciplinas necesarias para
lograr la excelencia operativa.
Paso 1: Definición de una estrategia para guiar las expectativas de

transformación digital y excelencia operativa
Una estrategia de negocios clara es la base para toda transformación digital y todo trabajo de excelencia
operativa. TI puede reducir los costos y agilizar los procesos de TI. Sin una estrategia clara, es difícil comprender
cómo esos cambios pueden afectar a los resultados empresariales identificados en el marco del trabajo general
de transformación.
Registrar las motivaciones, los resultados y la justificación comercial en la plantilla de estrategia y plan.
Asegurarse de que las métricas de aprendizaje se han comprendido con claridad e incluido en la sección de
resultados empresariales. Esas métricas guían las actividades de excelencia operativa y los informes de TI.
Descripción de las motivaciones: Los eventos empresariales críticos y algunas motivaciones de migración
tienden a ser sensibles a los costos. Estas áreas pueden aumentar la importancia del control de costos en
todos los trabajos posteriores. Otras motivaciones futuras relacionadas con la innovación o el crecimiento a
través de la migración se pueden centrar más en los ingresos brutos. El conocimiento de estás motivaciones
ayuda a clasificar la administración de costos.
Resultados empresariales: Algunos resultados fiscales suelen verse sumamente afectados por los costos.
Cuando los resultados deseados se corresponden con las métricas fiscales, es necesario invertir pronto en la
materia de gobernanza Cost Management.
Justificación empresarial: La justificación comercial funciona como una vista general del plan financiero
global en relación con la adopción de la nube. Puede ser una buena forma de abordar las labores iniciales de
presupuestación.
Métricas de aprendizaje: Con el fin de mantener la alineación entre la estrategia empresarial general y los
planes más tácticos de administración de cambios, establezca métricas de aprendizaje. Estas métricas deben
diseñarse para mostrar el progreso iterativo e incremental del plan.

Equipo de gobernanza de la nube
Equipo de operaciones en la nube
centralizado
Paso 2: Desarrollo de un plan de administración de cambios

organizacionales para abarcar la adopción de la nube
La administración de cambios organizacionales es un enfoque iterativo para la realineación sutil de personas,
procesos y tecnologías para respaldar una estrategia empresarial holística. En el caso de la excelencia operativa
para la transformación digital, este enfoque suele centrarse en un plan de adopción de la nube centrado en TI.
Actualizar la plantilla de estrategia y plan para reflejar los cambios necesarios para llevar a cabo la
estrategia deseada. Los cambios registrados pueden incluir lo siguiente:
Una evaluación del patrimonio digital existente.
Un plan de adopción de la nube que refleje los cambios necesarios y el trabajo que conlleva.
Los cambios organizacionales necesarios para cumplir con el plan.
Un plan para abordar las aptitudes necesarias para permitir que el equipo existente complete
correctamente el trabajo necesario.
Recopilación de inventario: establezca un origen de datos para analizar el patrimonio digital antes de la
adopción.
Procedimiento recomendado: Azure Migrate: utilice Azure Migrate para recopilar el inventario.
Racionalización incremental: durante la racionalización incremental, un análisis cuantitativo identifica a
candidatos en la nube con fines de presupuestación.
Alineación de los modelos de costo y los modelos de previsión: Utilice Azure Cost Management + Billing
para alinear los modelos de costo y de previsión mediante la creación de presupuestos.
Creación del plan de adopción de la nube: cree un plan con detalles sobre las cargas de trabajo, recursos y
escalas de tiempo accionables.

centralizado
Paso 3: Administración de los cambios entre los esfuerzos de

adopción de la nube
El logro de resultados empresariales es consecuencia de la entrega continua de olas de adopción. Estas olas
podrían incluir ciclos de migración e innovación. En todo caso, la entrega en la excelencia operativa comienza
con ciclos regulares de administración de cambios.
Cada ola (o entrega, en terminología ágil) entrega un conjunto de cargas de trabajo a la nube. A medida que se
complete cada ola de adopción, el equipo de estrategia de la nube informa sobre el progreso de las métricas de
aprendizaje, los resultados empresariales y la estrategia global. Del mismo modo, a medida que se completa
cada ola de adopción, los equipos de adopción necesitan actualizaciones de trabajo pendiente que reflejen las
cargas de trabajo priorizadas en el plan. Estas actualizaciones se basan en cualquier cambio en los planes
empresariales y las necesidades de los clientes.
Pruebas continuas y mejoras en la estrategia y el plan de administración de cambios en función de las
condiciones de mercado cambiantes y la finalización de la ola de cambios técnicos más reciente.
Planeamiento de la versión: Enfoques para la administración de cambios a través del planeamiento de la
versión.
Racionalización incremental: enfoque iterativo para la administración de cambios. Este enfoque se centra en
la administración del trabajo pendiente de la versión para admitir olas de cambios administrables.
Enfoque de la potencia de 10: limita el plan de administración de cambios. El enfoque se centra en el análisis
detallado y el planeamiento de una base continua de 10 cargas de trabajo para equilibrar los trabajos de
cambios incrementales y de adopción iterativa.
Alineación de las rutas de iteración: actualice y agregue detalles en cada versión para garantizar las rutas de
iteración actuales.
Evaluación de cargas de trabajo: Los esfuerzos del equipo de adopción de la nube para evaluar y actuar sobre
el conjunto más reciente de prioridades de migración.
Consenso del valor empresarial: Los esfuerzos del equipo de adopción de la nube para garantizar la
alineación del valor empresarial en cada versión de la nueva innovación.
En los pasos anteriores se describe un enfoque orientado a la empresa para establecer los requisitos de
excelencia operativa a lo largo de la transformación digital. Este enfoque ofrece una base coherente que se
mantiene en otras funciones del modelo operativo.
Pasos siguientes para lograr la excelencia operativa en toda la cartera

La excelencia operativa requiere un enfoque disciplinado en relación con la confiabilidad, el rendimiento, la
seguridad y la optimización de los costos. Use el resto de instrucciones de esta serie para implementar estos
principios a través de enfoques coherentes para la automatización.
Optimización de costos: optimice los costos operativos de forma continua con la guía de introducción
sobre administración de los costos empresariales.
Seguridad: para reducir el riesgo, integre la seguridad empresarial en toda la cartera con la guía de
introducción sobre implementación de la seguridad en toda la cartera.
Administración del rendimiento: asegúrese de que el rendimiento de los recursos de TI admite los
procesos empresariales con la guía de introducción sobre administración del rendimiento en toda la
empresa.
Confiabilidad: mejore la confiabilidad y reduzca las interrupciones empresariales con la guía de
introducción sobre implementación de controles para mejorar la confiabilidad.
Primeros pasos: Administración de los costos de la
nube
La materia Cost Management de gobernanza en la nube se centra en crear presupuestos, supervisar los
patrones de asignación de costos e implementar controles para mejorar los comportamientos de gasto en la
nube en toda la cartera de TI. La optimización de costos empresariales afecta a muchos otros roles y funciones
con el fin de poder minimizar el costo y equilibrar las necesidades en términos de escalabilidad, rendimiento,
seguridad y confiabilidad. Este artículo correlaciona las distintas funciones de apoyo en una guía de
introducción que facilita la alineación entre los equipos involucrados.
Sin embargo, la optimización de costos empresariales afecta a muchos otros roles y funciones con el fin de
poder minimizar el costo y equilibrar las necesidades en términos de escalabilidad, rendimiento, seguridad y
confiabilidad. En este artículo, se asignan las distintas funciones de apoyo para facilitar la alineación entre los
equipos involucrados.
La gobernanza es la piedra angular de la optimización de costos en cualquier empresa de gran tamaño. En la
siguiente sección, se ofrece una guía sobre la optimización de costos en el contexto de la gobernanza. Los pasos
posteriores permitirán a los equipos adoptar medidas dirigidas a la optimización de costos como parte de su
rol. En conjunto, estos pasos ayudarán a su organización a empezar a trabajar en un recorrido de optimización
de costos.
Paso 1: Optimizar los costos empresariales

El equipo de gobernanza de la nube está bien preparado para evaluar y actuar en el caso de que haya gastos
excesivos o imprevistos, por medio de acciones combinadas de supervisión del rendimiento, reducción del
tamaño de los recursos y terminación segura de los recursos no utilizados. La optimización de costos
empresariales empieza por el conocimiento compartido del equipo en cuanto a las herramientas, los procesos y
las dependencias que se necesitan para actuar de forma inteligente en relación con los costos a nivel del
entorno.
Implementar cambios adecuados en las directivas de administración de costos en toda la empresa.
Documentar las directivas, los procesos y la guía de diseño de administración de costos en la plantilla de la
materia de Cost Management.
Estos resultados son consecuencia de algunas tareas periódicas:
Garantizar la alineación estratégica con el equipo de estrategia en la nube (que incluye a las partes
interesadas de las cargas de trabajo en toda la cartera).
Optimizar los costos en todo el entorno:
Apagar manualmente o automáticamente las VM sin usar.
Eliminar o desasignar las máquinas virtuales que se hayan detenido.
Garantizar un tamaño adecuado de los recursos.
Alinear el gasto con las expectativas de presupuesto.
Validar cualquier cambio de arquitectura mediante la reseña de buena arquitectura de Microsoft Azure para
facilitar la conversación con los propietarios técnicos de las cargas de trabajo.
Asegúrese de que todas las cargas de trabajo y los recursos siguen convenciones de nomenclatura y
etiquetado adecuadas. Aplique convenciones de etiquetado mediante Azure Policy, con un énfasis
específico en las etiquetas de "centro de coste" y "propietario técnico".
Revisar y aplicar de forma periódica los procedimientos recomendados de la materia de administración
de costos para guiar el análisis y las mejoras en toda la empresa. Entre los procedimientos importantes
de gobernanza se incluyen:
Adoptar los procedimientos recomendados de costos generales para reducir los costos y la necesidad
de ajustar el tamaño y para detener las máquinas sin usar.
Aplicar las ventajas de uso híbrido para reducir los costos de las licencias.
Alinear las instancias reservadas para reducir los costos de recursos.
Supervisar el uso de recursos para minimizar los efectos sobre el rendimiento de los recursos.
Reducir los costos que no son de producción mediante directivas para regular los entornos que no
son de producción.
Adoptar las recomendaciones de optimización de costos.
Es posible que sea necesario hacer concesiones en el nivel de carga de trabajo para implementar cambios
efectivos en términos de optimización de costos. El marco de buena arquitectura de Microsoft Azure y la
reseña de buena arquitectura de Microsoft Azure pueden ayudar a guiar esas conversaciones con el
propietario técnico de una carga de trabajo específica.
Si no está familiarizado con la gobernanza de la nube, establezca directivas, procesos y materias de
gobernanza mediante la metodología de gobernanza.
Si no está familiarizado con la materia Cost Management, consulte el artículo sobre las mejoras de la
materia Cost Management y preste especial atención a la sección sobre implementación.

Equipo de adopción de la nube
centralizado
El equipo de gobernanza puede identificar e impulsar importantes oportunidades de optimización de costos en

la mayoría de las empresas. Hacer ajustes básicos en el tamaño de los recursos controlados por datos puede
tener un efecto inmediato y cuantificable sobre los costos.
Tal y como se explica en Crear una organización con control de costos, la adopción de un enfoque empresarial
de administración y optimización de costos puede ofrecer mucho más valor. En los pasos siguientes, se muestra
cómo los distintos equipos pueden ayudar a crear una organización que sea consciente de los costos.
Paso 2: Definir una estrategia
Las decisiones estratégicas afectan directamente al control de costos e influyen durante el ciclo de vida de
adopción y en las operaciones a largo plazo. La claridad estratégica mejorará los trabajos de optimización de
costos, respaldados por el equipo de gobierno.
Crear su primer presupuesto con Azure Cost Management + Billing.
Conocimiento de las motivaciones. Los eventos empresariales críticos y algunas motivaciones de migración
suelen tener implicaciones en los costos, lo que aumenta la importancia del control de costos para trabajos
posteriores. Otras motivaciones futuras relacionadas con la innovación o el crecimiento a través de la
migración pueden estar más orientadas a los grandes ingresos. Conocer las motivaciones puede ayudarle a
decidir cuál debería ser el grado de prioridad de la administración de costos.
Resultados empresariales. Algunos resultados fiscales dependen en gran medida de los costos. Cuando los
resultados deseados se corresponden con las métricas fiscales, es necesario invertir muy pronto en la
Justificación comercial. La justificación comercial funciona como una vista general del plan financiero para la
adopción de la nube. Esta pueda ser una buena forma de abordar las labores iniciales de presupuestación.
Equipo de estrategia de la nube Equipo de gobernanza de la nube

centralizado
Paso 3: Desarrollo de un plan de adopción de la nube

El plan de adopción aporta claridad en cuanto a la escala de tiempo de las actividades durante la adopción.
Alinear el plan y el análisis del patrimonio digital le permite pronosticar el aumento mensual del gasto. También
ayuda al equipo de gobernanza de la nube a alinear los procesos y a identificar los patrones de gasto.
Completar los pasos 1 a 6 para la creación de un plan de adopción de la nube.
Trabajar con el equipo de gobernanza de la nube para perfeccionar los presupuestos y crear previsiones de
gastos realistas.
Recopilación de inventario. Establezca un origen de datos para analizar el patrimonio digital antes de la
adopción.
Procedimiento recomendado: Azure Migrate. utilice Azure Migrate para recopilar el inventario.
Racionalización incremental. Durante la racionalización incremental y el análisis cuantitativo, identifique a los
candidatos en la nube con fines de presupuestación.
Alineación de los modelos de costo y los modelos de previsión. Utilice Azure Cost Management + Billing
Creación del plan de adopción de la nube. cree un plan con detalles sobre las cargas de trabajo, recursos y
escalas de tiempo accionables. Este plan sirve de base para el gasto a lo largo del tiempo (o la previsión de
costos). El gasto a lo largo del tiempo es la base de referencia inicial de todo el análisis de optimización
accionable de la materia de gobernanza Cost Management.

centralizado
Paso 4: Implementar los procedimientos recomendados para las

zonas de aterrizaje
La metodología de preparación de Microsoft Cloud Adoption Framework para Azure hace mucho hincapié en
desarrollar zonas de aterrizaje para hospedar las cargas de trabajo en la nube. Durante la implementación de
zonas de aterrizaje, una organización debe tener en cuenta varias decisiones para la optimización de costos.
Implementar una o más zonas de aterrizaje que puedan hospedar cargas de trabajo en el plan de adopción a
corto plazo.
Asegurarse de que todas las zonas de aterrizaje cumplan las decisiones en cuanto a la optimización de costos
y los requisitos de administración de costos.
Seguimiento de costos. Establezca una jerarquía de entorno bien administrado, proporcione el nivel
adecuado de acceso a los costos y utilice recursos adicionales de administración de costos en cada zona de
aterrizaje.
Optimización de la inversión en la nube. Conozca los procedimientos recomendados para optimizar las
inversiones.
Creación y administración de presupuestos. Conozca los procedimientos recomendados para crear y
administrar presupuestos.
Optimización de los costos a partir de las recomendaciones. Conozca los procedimientos recomendados a fin
de optimizar los costos.
Supervisión del uso y del gasto. Conozca los procedimientos recomendados para supervisar el uso y el gasto
dentro de una zona de aterrizaje.

centralizado
Paso 5: Finalizar etapas asociadas al trabajo de migración

La migración es un proceso repetible que lleva a cabo el equipo de adopción de la nube. A lo largo de este
proceso, hay numerosas oportunidades de optimizar los costos en toda la cartera. Muchas de estas decisiones
sobre la marcha afectan a un pequeño grupo de cargas de trabajo en cada iteración o etapa de migración.
Aportar pruebas comparativas, hacer comprobaciones, ajustar el tamaño e implementar una colección de
cargas de trabajo totalmente optimizadas.
En Mecanismos de control de costos centrados en la migración, se ofrece información sobre los controles de
optimización de costos nativos de la nube que sirven de ayuda durante la migración.
En Procedimientos recomendados para optimizar el costo de las cargas de trabajo migradas, se incluye una
lista de comprobación de 14 procedimientos recomendados que se deben seguir antes y después de la
migración para maximizar la optimización de costos de cada versión de carga de trabajo.
Los costos operativos a largo plazo son un tema común en las áreas de mejora del proceso de migración. Esta
lista de mejoras del proceso está estructurada con arreglo a la fase del proceso de migración:
Los requisitos previos proporcionan información sobre la administración de cambios y el trabajo pendiente,
ya que esto influye en los costos presupuestados y reales de la nube.
La evaluación ofrece seis procedimientos específicos, desde validar suposiciones hasta comprender las
opciones de los asociados. Cada proceso influye en las oportunidades de optimización en la nube.
La migración contiene una sugerencia de proceso sobre la corrección de recursos. Esta sugerencia
proporciona una oportunidad para optimizar el estado definido por la configuración, en favor de una
solución optimizada.
La promoción se centra principalmente en las pruebas, el ajuste de tamaño, la validación y la liberación de
los recursos migrados, junto con la retirada de recursos. Este es el primer aspecto claro sobre el que hay que
revisar las previsiones y los presupuestos en relación con el rendimiento y la configuración reales.

centralizado
Paso 6: Impulsar la innovación centrada en el cliente

La innovación y el desarrollo de nuevos productos requiere examinar la arquitectura en mucha más
profundidad. Cloud Adoption Framework proporciona detalles sobre el proceso de innovación y el
planteamiento de administración de productos. Las decisiones de optimización de costos con respecto a las
innovaciones quedan en gran parte fuera del ámbito de esta guía.
Tomar decisiones clave sobre la arquitectura en relación con las innovaciones a fin de equilibrar el costo y
otras consideraciones importantes de diseño.
Utilizar la reseña de buena arquitectura de Microsoft Azure para comprender el equilibrio de las decisiones
de arquitectura.
Revisar el marco de buena arquitectura de Microsoft Azure para obtener una guía más detallada sobre la
optimización de costos durante la innovación.

centralizado
Paso 7: Implementar operaciones sólidas

Establecer una base de referencia de administración sólida le ayudará a recopilar datos y a crear alertas
operativas. Este trabajo puede ayudar a detectar oportunidades para optimizar los costos. Creará un equilibrio
entre la resistencia y la optimización de costos.
Supervisar el entorno de su empresa para obtener recomendaciones continuas de optimización de costos, en
consonancia con la clasificación de importancia y resistencia de cada carga de trabajo.
Alinear la empresa para obtener claridad con respecto a la importancia y a la necesidad de hacer inversiones
duraderas.

centralizado
Estos pasos pueden le ayudan a crear una organización consciente de los costos. Para simplificar la optimización
de costos, use la propiedad compartida y fomente la colaboración con los equipos adecuados en los momentos
adecuados.
Primeros pasos: Implementación de la seguridad en
todo el entorno empresarial
La seguridad ayuda a generar garantías de confidencialidad, integridad y disponibilidad para una empresa. Las
iniciativas de seguridad se enfocan de forma crítica en la protección contra el posible impacto en las
operaciones que ocasionarían las acciones malintencionadas e involuntarias, tanto internas como externas.
En esta guía de introducción se describen los pasos principales que mitigarán o evitarán el riesgo empresarial
frente a ataques de ciberseguridad. Puede ayudarle a establecer rápidamente prácticas de seguridad esenciales
en la nube, así como a integrar la seguridad en el proceso de adopción de la nube.
Los pasos de esta guía están dirigidos a todos los roles que participan en las garantías de seguridad para los
entornos de nube y las zonas de aterrizaje. Entre las tareas se incluyen prioridades de mitigación de riesgos
inmediatos, instrucciones sobre la creación de una estrategia de seguridad moderna, la puesta en marcha de la
estrategia y su ejecución.
En esta guía se incluyen los elementos de Microsoft Cloud Adoption Framework para Azure:
Si sigue los pasos de esta guía, podrá integrar la seguridad en los puntos críticos del proceso. El objetivo es
evitar obstáculos en la adopción de la nube y reducir las interrupciones innecesarias en las operaciones o el
negocio.
Microsoft ha generado funcionalidades y recursos para ayudar a acelerar la implementación de esta guía de
seguridad en Microsoft Azure. Se hará referencia a dichos recursos en esta guía. Están diseñados para ayudarle
a establecer, supervisar y aplicar la seguridad, y se actualizan y revisan con frecuencia.
En el siguiente diagrama se muestra el enfoque holístico para usar la guía de seguridad y las herramientas de
plataforma para establecer la visibilidad y el control de la seguridad de los recursos en la nube en Azure. Se
recomienda esta estrategia.
Siga estos pasos para planear y ejecutar la estrategia para proteger los recursos en la nube y usar la nube para
modernizar las operaciones de seguridad.
Paso 1: Establecimiento de procedimientos de seguridad esenciales

La seguridad en la nube comienza con la aplicación de los procedimientos de seguridad más importantes para
las personas, los procesos y los elementos tecnológicos del sistema. Además, algunas decisiones arquitectónicas
son fundamentales y muy difíciles de cambiar más adelante, por lo que deben aplicarse con cuidado.
Tanto si ya trabaja en la nube como si planea la adopción futura, se recomienda seguir estos 11 procedimientos
de seguridad esenciales (además de cumplir con los requisitos de cumplimiento normativo explícitos).
Personas:
1. Formación del equipo sobre el recorrido de seguridad de la nube
2. Formación de equipos en tecnología de seguridad de la nube
Proceso:
3. Asignación de responsabilidades para las decisiones de seguridad en la nube
4. Actualización de los procesos de respuesta a incidentes para la nube
5. Establecimiento de la administración de la posición de seguridad en la nube
Tecnología:
6. Exigencia de autenticación sin contraseña o multifactor
7. Integración del firewall nativo y seguridad de red
8. Integración de la detección de amenazas nativa
Decisiones sobre la arquitectura fundamental:
9. Unificación en un único directorio e identidad
10. Uso del control de acceso basado en identidades (en lugar de claves)
11. Establecimiento de una estrategia de seguridad unificada
NOTE
Cada organización debe definir sus propias normas mínimas, dado que la postura ante el riesgo y la tolerancia
subsiguiente a ese riesgo pueden variar considerablemente en función del sector, la cultura y otros factores. Por ejemplo,
es posible que un banco no tolere ningún daño potencial a su reputación, ni siquiera un ataque menor en un sistema de
prueba. Algunas organizaciones aceptarían el mismo riesgo si significara la aceleración de la transformación digital en tres
o seis meses.
Paso 2: Modernización de la estrategia de seguridad

La seguridad efectiva en la nube requiere una estrategia que refleje el entorno de amenazas actual y la
naturaleza de la plataforma en la nube que hospeda los recursos empresariales. Una estrategia clara mejora los
esfuerzos de todos los equipos para proporcionar un entorno de nube empresarial seguro y sostenible. La
estrategia de seguridad debe permitir alcanzar resultados empresariales definidos, reducir el riesgo hasta un
nivel aceptable y permitir que los empleados sean productivos.
Una estrategia de seguridad en la nube aporta instrucciones a todos los equipos que trabajan en tecnologías,
procesos y preparación de las personas para esta adopción. La estrategia debe informar la arquitectura de la
nube y las funcionalidades técnicas, guiar la arquitectura y las funcionalidades de seguridad, e influir en el
entrenamiento y la educación de los equipos.
El paso de la estrategia debe dar lugar a un documento que se pueda comunicar fácilmente a muchas partes
interesadas de la organización. Entre estas podrían incluirse los ejecutivos del equipo de liderazgo de la
organización.
Se recomienda capturar la estrategia en una presentación con el fin de facilitar el análisis y la actualización. Esta
se puede apoyar en un documento, en función de la cultura y las preferencias.
Presentación de la estrategia: Puede tener una sola presentación de la estrategia, o bien puede optar
por crear también resúmenes para los encargados del liderazgo.
Presentación completa: Debe incluir el conjunto completo de elementos de la estrategia de
seguridad en la presentación principal o en las diapositivas de referencia opcionales.
Resúmenes ejecutivos: Versiones que se van a usar con ejecutivos sénior y miembros del consejo,
que podría contener solo elementos críticos pertinentes para su rol, como el apetito por el riesgo, las
prioridades principales o los riesgos aceptados.
También puede registrar las motivaciones, los resultados y las justificaciones comerciales en la plantilla
de estrategia y plan.
Procedimientos recomendados para la creación de la estrategia de seguridad:
Los programas adecuados incorporan estos elementos en el proceso de su estrategia de seguridad:
Alineación estrecha con la estrategia empresarial: El contrato de seguridad busca proteger el valor
empresarial. Es fundamental alinear todos los esfuerzos de seguridad con ese propósito y minimizar el
conflicto interno.
Genere un conocimiento compar tido sobre requisitos empresariales, TI y seguridad.
Integre la seguridad pronto en la adopción de la nube para evitar las crisis de última hora
ocasionadas por riesgos evitables.
Use un enfoque ágil para establecer inmediatamente los requisitos mínimos de seguridad y
mejorar continuamente las garantías de seguridad con el tiempo.
Promueva el cambio de cultura de seguridad a través de acciones de liderazgo proactivas el
intencionadas.
Para obtener más información, consulte Transformaciones, actitudes y expectativas.
Modernización de la estrategia de seguridad: La estrategia de seguridad debe incluir
consideraciones para todos los aspectos del entorno de tecnología moderno, el panorama de amenazas
actual y los recursos de la comunidad de seguridad.
Adapte al modelo de responsabilidad compartida de la nube.
Incluya todos los tipos de implementación de nube y multinube.
Prefiera los controles de nube nativa para evitar una fricción innecesaria y dañina.
Integre la comunidad de seguridad para seguirle el ritmo al progreso de los atacantes.
Recursos relacionados para el contexto adicional:
Evolución del entorno de amenazas, los roles y las estrategias digitales.
Transformación de la seguridad, las estrategias, las herramientas y las amenazas.
Consideraciones sobre la estrategia para Cloud Adoption Framework:
Modernización de la estrategia de seguridad
Resistencia de ciberseguridad
De qué manera la nube está cambiando las relaciones y responsabilidades de seguridad
EQ UIP O EN C A RGA DO EQ UIP O S RESP O N SA B L ES Y A UXIL IA RES
Equipo de liderazgo de seguridad (director de seguridad Equipo de estrategia de la nube

de la información (CISO) o equivalente) Equipo de seguridad de la nube
centralizado
Aprobación de la estrategia:
Los ejecutivos y los líderes empresariales responsables de los resultados o riesgos de las líneas de negocio
dentro de la organización deben aprobar esta estrategia. Este grupo puede incluir a la junta directiva, en función
de la organización.
Paso 3: Desarrollo de un plan de seguridad

La planeación pone en acción la estrategia de seguridad mediante la definición de resultados, hitos, escalas de
tiempo y propietarios de las tareas. Este plan también describe los roles y responsabilidades de los equipos.
El planeamiento de la seguridad y el planeamiento de la adopción de la nube no deben realizarse aisladamente.
Es fundamental invitar al equipo de seguridad de la nube a los ciclos de planeamiento desde un principio con el
fin de evitar la interrupción del trabajo o el aumento del riesgo debido a que los problemas de seguridad se
detecten demasiado tarde. El planeamiento de la seguridad funciona mejor con un conocimiento profundo y
conciencia sobre el patrimonio digital y la cartera de TI existente, lo que es posible al estar totalmente
integrados en el proceso de planeamiento de la nube.
Plan de seguridad: Un plan de seguridad debe formar parte de la documentación principal de la
planeación para la nube. Puede tratarse de un documento que use la estrategia y la plantilla de plan, un
juego de diapositivas detalladas o un archivo de proyecto. O bien puede ser una combinación de estos
formatos, en función del tamaño, la cultura y los procedimientos estándar de la organización.
El plan de seguridad debe incluir todos los elementos siguientes:
Plan de funciones organizativas , para que los equipos sepan cómo cambiarán los roles y
responsabilidades de seguridad actuales con la migración a la nube.
Plan de aptitudes de seguridad: Para apoyar a los miembros del equipo cuando naveguen por
los cambios significativos en la tecnología, los roles y las responsabilidades.
Arquitectura de seguridad y hoja de ruta de funcionalidades técnicas para guiar a los
equipos técnicos.
Microsoft ofrece arquitecturas y funcionalidades tecnológicas de referencia que le ayudarán a
medida que cree su arquitectura y el mapa de ruta, entre otras:
Los componentes y el modelo de referencia de Azure para acelerar el planeamiento y el
diseño de los roles de seguridad de Azure.
La arquitectura de referencia de ciberseguridad de Microsoft para crear una arquitectura de

ciberseguridad para una empresa híbrida, que abarca recursos locales y en la nube.
La arquitectura de referencia del Centro de operaciones de seguridad (SOC) para
modernizar la detección, la respuesta y la recuperación de seguridad.
Arquitectura de referencia de acceso de usuarios de confianza cero para modernizar la
arquitectura de control de acceso para la generación en la nube.
Azure Security Center y Microsoft Cloud App Security para ayudarle a proteger los recursos
de la nube.
Plan de aprendizaje y conciencia sobre seguridad , para que todos los equipos tengan
conocimientos básicos de seguridad esenciales.
Marcado de confidencialidad de los recursos para designar recursos confidenciales
mediante una taxonomía alineada con el impacto en la empresa. Las partes interesadas del
negocio, los equipos de seguridad y otras partes interesadas crean conjuntamente la taxonomía.
Cambios de seguridad en el plan de nube: Actualice otras secciones del plan de adopción de
la nube para reflejar los cambios desencadenados por el plan de seguridad.
Procedimientos recomendados para el planeamiento de la seguridad:
Es probable que el plan de seguridad sea más satisfactorio si su planeamiento adopta el enfoque siguiente:
Supuesto de un entorno híbrido: Esto incluye aplicaciones de software como servicio (SaaS) y
entornos locales. También incluye varios proveedores de infraestructura en la nube como servicio (IaaS) y
plataforma en la nube como servicio (PaaS), si procede.
Adopción de la seguridad ágil: Establezca primero los requisitos mínimos de seguridad y mueva
todos los elementos no críticos a una lista de prioridades de pasos siguientes. No debe ser un plan
tradicional y detallado de 3 a 5 años. La nube y el entorno de las amenazas cambian demasiado rápido
como para que este tipo de plan resulte útil. El plan debe centrarse en el desarrollo de los pasos iniciales
y del estado final:
Logros rápidos para el futuro inmediato que proporcione un gran impacto antes de que comiencen
las iniciativas a largo plazo. Los períodos de tiempo pueden ir de 3 a 12 meses, según la cultura de la
organización, las prácticas estándar y otros factores.
Una visión clara del estado final deseado para guiar el proceso de planeamiento de cada equipo
(que puede tardar varios años en lograrse).
Intercambio a grandes rasgos del plan: Aumente la conciencia de las partes interesadas, sus
comentarios y su aceptación.
Cumplimiento de los resultados estratégicos: Asegúrese de que el plan se alinee y cumpla los
resultados estratégicos descritos en la estrategia de seguridad.
Establezca la propiedad, responsabilidad y plazos: Asegúrese de que los propietarios de cada tarea
estén identificados y se comprometan a completar esa tarea en un período de tiempo específico.
Conexión con el lado humano de la seguridad: Involucre a la gente durante este período de
transformación y hacia las nuevas expectativas; para ello:
Apoye activamente la transformación de los miembros del equipo una con comunicación
clara y preparación sobre lo siguiente:
Qué habilidades tienen que aprender.
Por qué tienen que aprenderlas (y las ventajas de hacerlo).
Cómo obtendrán este conocimiento (y proporcionar recursos para ayudarles a aprender).
Puede documentar el plan mediante la estrategia y la plantilla de plan. Puede usar el
entrenamiento de seguridad de Microsoft en línea para ayudar a educar a los miembros de los
equipos.
Hacer atractivo el aprendizaje sobre seguridad para ayudar a las personas a conectarse de
forma auténtica con su parte de la protección de la organización.
Revisión de las guías y aprendizajes de Microsoft: Microsoft ha publicado información y
perspectivas para ayudar a las organizaciones a planificar su transformación a la nube, así como una
estrategia de seguridad moderna. El material incluye aprendizaje grabado y documentación, así como
procedimientos y estándares recomendados de seguridad.
Para obtener una guía técnica que le ayude a crear el plan y la arquitectura, consulte la documentación de
seguridad de Microsoft.
Equipo de seguridad de la nube Equipo de estrategia de la nube

Cualquier equipo de riesgo de su organización
centralizado
Aprobación del plan de seguridad:

El equipo de liderazgo de seguridad (CISO o equivalente) debe aprobar el plan.
Paso 4: Protección de las nuevas cargas de trabajo

Es mucho más fácil empezar en un estado seguro que incluir la seguridad en su entorno más adelante. Se
recomienda encarecidamente comenzar con una configuración segura para asegurarse de que las cargas de
trabajo se migren, desarrollen y prueben en un entorno seguro.
Durante la implementación de la zona de aterrizaje, muchas decisiones pueden afectar a los perfiles de
seguridad y riesgo. El equipo de seguridad de la nube debe revisar la configuración de la zona de aterrizaje para
asegurarse de que cumple los estándares y requisitos de seguridad de las bases de referencia de seguridad de
su organización.
Asegúrese de que las nuevas zonas de aterrizaje cumplan los requisitos de seguridad y cumplimiento de la
organización.
Combinación de los requisitos existentes y las recomendaciones de la nube: Comience por la
guía recomendada y, después, adáptela a sus propios requisitos de seguridad. Hemos visto dificultades
en los intentos de aplicar directivas y estándares locales existentes, ya que a menudo hacen referencia a
los enfoques de seguridad o tecnología obsoletos.
Microsoft ha publicado una guía para ayudarle a crear las bases de referencia de seguridad:
Estándares de seguridad de Azure para la estrategia y la arquitectura: Recomendaciones de
arquitectura y estrategia para dar forma a la postura de seguridad de su entorno.
Pruebas comparativas de seguridad de Azure: Recomendaciones de configuración específicas para la
protección de entornos de Azure.
Aprendizaje de la base de referencia de seguridad de Azure.
Límites de protección: Entre las medidas de seguridad se debe incluir la auditoría y cumplimiento de
directivas automatizados. En estos nuevos entornos, los equipos deben esforzarse por auditar y aplicar
las bases de referencia de seguridad de la organización. Estas iniciativas pueden ayudar a minimizar las
sorpresas de seguridad durante el desarrollo de las cargas de trabajo, así como la integración continua y
la implementación continua (CI/CD) de las cargas de trabajo.
Microsoft proporciona varias funcionalidades nativas de Azure para permitir esto:
Puntuación de seguridad: Use una evaluación puntuada de la posición de seguridad de Azure para
realizar un seguimiento de las iniciativas y proyectos de seguridad de su organización.
Azure Blueprints. Los arquitectos de nube y los grupos de TI centralizado pueden definir un conjunto
repetible de recursos de Azure que implemente y cumpla los estándares, patrones y requisitos de la
organización.
Azure Policy: Esta es la base de las funcionalidades de visibilidad y control que usan los otros servicios.
Azure Policy está integrado en Azure Resource Manager, por lo que puede auditar los cambios y
aplicar las directivas en cualquier recurso de Azure antes, durante o después de su creación.
Mejora de las operaciones en la zona de aterrizaje: Aproveche los procedimientos recomendados para
mejorar la seguridad dentro de una zona de aterrizaje.
Equipo de seguridad de la nube Equipo de adopción de la nube

Equipo de plataforma de la nube
Equipo de estrategia de la nube
centralizado
Paso 5: Protección de las cargas de trabajo en la nube existentes

Muchas organizaciones ya han implementado recursos en entornos de nube empresarial sin aplicar los
procedimientos recomendados de seguridad, lo que genera un mayor riesgo empresarial.
Después de asegurarse de que las nuevas aplicaciones y zonas de aterrizaje sigan los procedimientos
recomendados de seguridad, debe centrarse en llevar los mismos estándares a los entornos existentes.
Asegurarse de que todos los entornos de nube y zonas de aterrizaje cumplan los requisitos de seguridad y
cumplimiento de la organización.
Probar el grado de preparación operativa de las implementaciones de producción mediante las directivas
para la base de referencia de seguridad.
Validar el cumplimiento de la guía de diseño y los requisitos de seguridad para la base de referencia de
seguridad.
Utilice las mismas bases de referencia de seguridad que ha creado en el paso 4 como estado ideal. Quizá
deba ajustar algunos valores de la configuración de directiva para que realizar solo la auditoría, en lugar de
aplicar los requisitos.
Equilibre el riesgo operativo y de seguridad. Ya que estos entornos pueden hospedar sistemas de producción
que habilitan procesos empresariales críticos, puede que necesite implementar mejoras de seguridad de
manera incremental para evitar el riesgo de padecer un tiempo de inactividad operativo.
Clasifique por orden de prioridad la detección y corrección del riesgo de seguridad según su importancia
empresarial. Comience con las cargas de trabajo que tienen un gran impacto en la empresa si están en
peligro, así como las que tienen una alta exposición a riesgos.
Para obtener más información, consulte Identificar y clasificar aplicaciones críticas para la empresa.
Equipo de adopción de la nube Equipo de adopción de la nube

Equipo de seguridad de la nube
centralizado
Paso 6: Control para administrar y mejorar la postura de seguridad

Al igual que todas las disciplinas modernas, la seguridad es un proceso iterativo que debe centrarse en la
mejora continua. La postura de seguridad también puede decaer si las organizaciones no mantienen su atención
en ella a lo largo del tiempo.
La aplicación uniforme de los requisitos de seguridad proviene de disciplinas de gobernanza y soluciones
automatizadas. Después de que el equipo de seguridad en la nube defina las bases de referencia de seguridad,
estos requisitos deberán auditarse para asegurarse de que se apliquen de forma coherente a todos los entornos
de nube (y se apliquen cuando corresponda).
Asegurarse de que las bases de referencia de seguridad de la organización se aplican a todos los sistemas
pertinentes. Audite las anomalías mediante una puntuación de seguridad o un mecanismo similar.
Documentar las directivas de base de referencia de seguridad, los procesos y la guía de diseño en la plantilla
de la materia de base de referencia de seguridad.
Use las mismas bases de referencia de seguridad y mecanismos de auditoría que creó en el Paso 4 como
componentes técnicos de la supervisión de las bases de referencia. Complemente dichas bases de referencia
con personas y controles de procesos para garantizar la coherencia.
etiquetado adecuadas. Aplique convenciones de etiquetado mediante Azure Policy, con un énfasis específico
en las "etiquetas de confidencialidad".

Equipo de seguridad de la nube
centralizado
Pasos siguientes
Los pasos de esta guía le ayudaron a implementar la estrategia, los controles, los procesos, las aptitudes y la
cultura necesarios para administrar de forma coherente los riesgos de seguridad en toda la empresa.
A medida que avance en el modo de operaciones de seguridad en la nube, tenga en cuenta los siguientes pasos:
Revise la documentación de Microsoft acerca de la seguridad. Incluye instrucciones técnicas para ayudar a los
profesionales de seguridad a crear y mejorar la estrategia de ciberseguridad, la arquitectura y las hojas de
ruta de prioridades.
Revise la información de seguridad en los controles de seguridad integrados para los servicios de Azure.
Revise los servicios y herramientas de seguridad de Azure, consulte Servicios y tecnologías de seguridad
disponibles en Azure.
Revise el Centro de confianza de Microsoft. Contiene una orientación amplia, informes y documentación
relacionada que pueden ayudarle a realizar evaluaciones de riesgos como parte de los procesos de
cumplimiento normativo.
Revise las herramientas de terceros disponibles para facilitar el cumplimiento de los requisitos de seguridad.
Para obtener más información, consulte Integración de soluciones de seguridad en Azure Security Center.
Primeros pasos: Mejora de la confiabilidad con los
controles adecuados
¿Cómo se aplican los controles adecuados para mejorar la confiabilidad? Este artículo le ayuda a minimizar las
interrupciones relacionadas con:
Incoherencias en la configuración.
Organización de recursos.
Bases de referencia de seguridad.
Protección de recursos.
Los pasos que se describen en este artículo ayudan al equipo de operaciones a equilibrar la confiabilidad y el
costo en toda la cartera de TI. Este artículo también ayuda al equipo de gobernanza a garantizar que el equilibrio
se aplica de forma coherente. La confiabilidad también depende de otros roles y funciones. En este artículo, se
asignan funciones de apoyo para ayudarle a crear la alineación de los equipos involucrados.
La administración y gobernanza de las operaciones son socias inseparables para la confiabilidad empresarial.
Las decisiones que se toman con respecto a los procedimientos operativos establecen la base de referencia para
la confiabilidad. Los enfoques usados para controlar el entorno general garantizan la coherencia entre todos los
recursos.
Los dos primeros pasos de este artículo ayudan a ambos equipos a empezar. Aparecen de forma secuencial,
pero se pueden realizar en paralelo. Los pasos posteriores le permiten que toda su empresa inicie un recorrido
compartido hacia soluciones más confiables para la empresa en su conjunto.
Paso 1: Establecimiento de los requisitos de la administración de

operaciones
No todas las cargas de trabajo se crean iguales. En cualquier entorno, existen cargas de trabajo que tienen un
impacto directo y constante en el negocio. Existen también procesos y cargas de trabajo empresariales auxiliares
que tienen un impacto menor en el negocio en general. En este paso, el equipo de operaciones en la nube
identifica e implementa los requisitos iniciales para admitir la cartera global de TI.
Implementar una base de referencia de administración para definir las operaciones estándar necesarias para
todas las cargas de trabajo de producción.
Negociar los compromisos empresariales con el equipo de estrategia en la nube para elaborar un plan de
operaciones avanzadas y requisitos de resistencia.
Ampliar la base de referencia de administración, si se requieren operaciones adicionales para la mayoría de
las cargas de trabajo.
Aplicar requisitos de operaciones avanzadas a zonas de aterrizaje y recursos que admitan las cargas de
trabajo de mayor importancia.
Documentar las decisiones sobre las operaciones en la cartera de TI en el libro de administración de
operaciones.
Línea de base de administración:
Inventario y visibilidad: Las herramientas nativas de nube pueden ayudarle a recopilar datos y
configurar alertas. Las herramientas también pueden ayudarle a implementar la plataforma de
supervisión que mejor se adapte a su modelo operativo.
Cumplimiento operativo: Los porcentajes más altos de interrupciones tienden a provenir de cambios
en la configuración de los recursos o de prácticas de mantenimiento deficientes. Siga las guía de
administración de servidores de Azure para implementar herramientas nativas de nube para
administrar la aplicación de revisiones y los cambios en la configuración de los recursos.
Protección y recuperación: Las interrupciones son inevitables en cualquier plataforma. Cuando se
produzca una interrupción, prepárese con soluciones de copia de seguridad y recuperación para
minimizar su duración.
Operaciones avanzadas: Use la base de referencia de administración como base para las conversaciones
de alineación empresarial. Le ayuda a analizar claramente la criticidad, el impacto empresarial y los
compromisos de operaciones. La alineación empresarial ayuda a cuantificar y validar las solicitudes de
una base de referencia mejorada, la administración de plataformas tecnológicas específicas o las
operaciones específicas de las cargas de trabajo.
Guía de una revisión de la arquitectura: Es posible que se necesiten cambios en la arquitectura a
nivel de las cargas de trabajo para cumplir los requisitos de las operaciones. El marco de buena
arquitectura de Microsoft Azure y la reseña de buena arquitectura de Microsoft Azure pueden ayudar a
guiar esas conversaciones con el propietario técnico de una carga de trabajo específica.

centralizado
Paso 2: Aplicación coherente de la base de referencia de

administración
La confiabilidad empresarial requiere una aplicación uniforme de la base de referencia de administración. Esa
coherencia proviene de la elección adecuada de la directiva corporativa, los procesos de TI y las herramientas
automatizadas. Estos recursos rigen la implementación de la base de referencia de administración de todos los
recursos afectados.
Garantizar la correcta aplicación de la base de referencia de administración para todos los sistemas
afectados.
Documentar las directivas de coherencia de recursos, los procesos y la guía de diseño en la plantilla de
coherencia de los recursos.
en las etiquetas de criticidad.
Si no está familiarizado con la materia de administración de costos, siga las instrucciones del artículo
Mejoras en la administración de costos. Céntrese en la sección Implementación.
NOTE
Pasos para iniciar las asociaciones de confiabilidad con otros equipos: Son varias las decisiones que a lo largo
del ciclo de vida de adopción de la nube pueden tener un impacto directo en la confiabilidad. Los pasos siguientes
describen las asociaciones y los esfuerzos auxiliares necesarios para ofrecer una confiabilidad uniforme en toda la cartera
de TI.

centralizado
Paso 3: Definición de la estrategia

Las decisiones estratégicas afectan directamente a la confiabilidad. Se propagan en el ciclo de vida de adopción
y las operaciones a largo plazo. La claridad estratégica mejora los esfuerzos de confiabilidad.
Garantizar que la base de referencia de administración proporcione un apoyo operativo en consonancia con
la dirección estratégica de la adopción de la nube.
tienden a ser sensibles a los costos. Estas áreas pueden aumentar la importancia del control de costos en
todos los trabajos posteriores. Otras motivaciones futuras relacionadas con la innovación o el crecimiento a
través de la migración se pueden centrar más en los ingresos brutos. El conocimiento de estás motivaciones
ayuda a clasificar la administración de costos.
Justificación empresarial: La justificación comercial funciona como una vista general del plan financiero
global en relación con la adopción de la nube. Puede ser una buena forma de abordar las labores iniciales de
presupuestación.

centralizado
Paso 4: Desarrollo de un plan de adopción de la nube

El patrimonio digital (o el análisis de la cartera de TI existente) puede ayudarle a validar la justificación
empresarial. Puede proporcionar una vista refinada de la cartera global de TI. El plan de adopción aporta
claridad en cuanto a la escala de tiempo de las actividades durante la adopción.
Al alinear el plan de adopción con el análisis del patrimonio digital, puede planear futuras dependencias de
administración de operaciones. La descripción del plan de adopción también invita al equipo de operaciones en
la nube a los ciclos de desarrollo. El equipo puede evaluar y planear cualquier cambio en la base de referencia
de administración que sea necesario para proporcionar operaciones de carga de trabajo.
Actualizar la plantilla de estrategia y plan para reflejar los cambios necesarios para llevar a cabo la
estrategia deseada. Los cambios registrados pueden incluir lo siguiente:
Una evaluación del patrimonio digital existente.
Un plan de adopción de la nube que refleje los cambios necesarios y el trabajo que conlleva.
El cambio organizacional necesario para cumplir con el plan.
Un plan para abordar las aptitudes necesarias para permitir que el equipo existente complete
correctamente el trabajo necesario.
Trabaje con el equipo de gobernanza para alinear modelos de costos y modelos de previsión. Este
proceso incluye trabajos para empezar a optimizar el gasto a través del análisis cuantitativo.
adopción.
Racionalización incremental: durante la racionalización incremental, un el análisis cuantitativo puede
identificar a candidatos en la nube con fines de presupuestación.
Creación del plan de adopción de la nube: cree un plan con detalles sobre las cargas de trabajo, recursos y
escalas de tiempo accionables.

centralizado
Paso 5: Implementar procedimientos recomendados acerca de las
zonas de aterrizaje
La metodología de preparación de Cloud Adoption Framework se centra principalmente en el desarrollo de
zonas de aterrizaje para hospedar cargas de trabajo en la nube. Durante la implementación de las zonas de
aterrizaje, varias decisiones podrían afectar a las operaciones. Consulte al equipo de operaciones en la nube
para ayudar a revisar la zona de aterrizaje y mejorar las operaciones. Además, consulte al equipo de gobernanza
de la nube para conocer las directivas de coherencia de los recursos y la guía de diseño que pueden afectar al
diseño de las zonas de aterrizaje.
corto plazo.
Asegurarse de que todas las zonas de aterrizaje cumplan las decisiones relativas a las operaciones y los
requisitos de coherencia de recursos.
Mejora de las operaciones en la zona de aterrizaje: Procedimientos recomendados para mejorar las
operaciones dentro de una zona de aterrizaje específica.
Equipo de adopción de la nube Equipo de operaciones en la nube

centralizado
Paso 6: Finalización de las olas de esfuerzo de adopción y cambio

Las operaciones a largo plazo pueden verse afectadas por las decisiones tomadas durante los esfuerzos de
migración e innovación. Mantener una alineación coherente de forma temprana en los procesos de adopción
ayuda a eliminar obstáculos para las versiones de producción. También reduce el trabajo necesario para
introducir nuevas soluciones en las prácticas de administración de operaciones.
Poner a prueba el grado de preparación operativa de las implementaciones de producción mediante
directivas de coherencia de recursos.
Validar el cumplimiento de la guía de diseño en cuanto a la coherencia de los recursos y los requisitos de
operaciones.
Documentar posibles requisitos de operaciones avanzadas en el libro de administración de operaciones.
Lista de comprobación de preparación del entorno
Lista de comprobación previa a la promoción
Lista de comprobación de las versiones de producción

centralizado
Los pasos anteriores le ayudan a implementar los controles adecuados y los procesos necesarios para
garantizar la confiabilidad en toda la empresa y en todos los recursos hospedados.
Primeros pasos: Garantizar un rendimiento
coherente en una cartera
¿Cómo se garantiza el rendimiento adecuado en una cartera de cargas de trabajo? Los pasos de esta guía puede
ayudarle a establecer procesos para mantener ese nivel de rendimiento.
El rendimiento también depende de otros roles y funciones. En este artículo, se asignan las distintas funciones
de apoyo para ayudarle a crear la alineación de los equipos involucrados.
La administración de operaciones centralizadas es el enfoque más común para lograr que el rendimiento sea
coherente en toda la cartera. Las decisiones relativas a las prácticas operativas definen la base de referencia de
las operaciones, junto con cualquier mejora integral.
El primer paso de esta guía ayudará al equipo de operaciones a ponerse en marcha. Los pasos posteriores
ayudan a toda la empresa a iniciar un recorrido compartido hacia el rendimiento empresarial para toda la
cartera de cargas de trabajo.
Paso 1: Establecimiento de los requisitos de la administración de

operaciones
La base de referencia de la administración de operaciones, descrita en Microsoft Cloud Adoption Framework
para Azure, proporciona un conjunto de controles y herramientas de operaciones nativas de la nube para
garantizar unas operaciones coherentes. La expansión de esa base de referencia mediante herramientas de
automatización proporciona los niveles de automatización y supervisión del rendimiento para cumplir los
requisitos de rendimiento coherente en toda la cartera.
Mejorar la base de referencia de administración para incluir tareas de corrección automatizada relativas a
desviaciones con respecto a las expectativas de rendimiento.
Si se necesitan patrones de datos o cambios de arquitectura específicos de la carga de trabajo para cumplir
los requisitos de rendimiento, usar operaciones específicas de la carga de trabajo para proporcionar
controles de rendimiento más amplios.
Documentar las decisiones sobre las operaciones en la cartera de TI en el libro de administración de
operaciones. Centrarse en incluir decisiones sobre la automatización del rendimiento en la sección
Operational Compliance de la pestaña Baseline .

En el artículo sobre la base de referencia de administración mejorada, se incluyen ejemplos del uso de
herramientas como Azure Automation para agregar mejoras relativas al rendimiento. Este enfoque puede
ayudar a mantener un rendimiento coherente por medio de modificaciones básicas en cuanto al tamaño y la
escala de los recursos de apoyo.
Las operaciones específicas de la carga de trabajo utilizan la reseña de buena arquitectura de Microsoft Azure
para proporcionar instrucciones sobre la automatización de una carga de trabajo específica. Este enfoque de
la administración del rendimiento es especialmente útil cuando las acciones operativas deben estar basadas
en datos específicos de la carga de trabajo.
La guía anterior presupone que una implementación existente de una base de referencia de administración
proporciona soporte para toda la cartera de cargas de trabajo.
NOTE
Son varias las decisiones que pueden influir directamente en el rendimiento a lo largo del ciclo de vida de adopción de la
nube. Los pasos siguientes ayudan a describir las relaciones y los trabajos de apoyo necesarios para garantizar el
rendimiento en toda la cartera de TI.

centralizado
Paso 2: Aplicación coherente de la base de referencia de

administración
A medida que se mejora la base de referencia de administración, es importante asegurarse de que esas mejoras
se lleven a cabo en la materia de gobernanza de la coherencia de recursos. De este modo, se garantiza la
aplicación de la base de referencia mejorada en todos los entornos administrados.
Garantizar la correcta aplicación de la base de referencia de administración mejorada para todos los sistemas
afectados.
Documentar las directivas, los procesos y la guía de diseño para la coherencia de los recursos en la plantilla
de la materia de coherencia de recursos.
en las etiquetas de "criticidad".
Si no está familiarizado con Cost Management, vea el artículo sobre las mejoras de Cost Management
prestando especial atención a la sección Implementación.

centralizado
Paso 3: Definir la estrategia

Las decisiones estratégicas afectan directamente al rendimiento e influyen durante el ciclo de vida de adopción y
en las operaciones a largo plazo. La claridad estratégica mejora el trabajo de rendimiento en toda la cartera. Esa
claridad también ayuda al equipo de operaciones a comprender qué cargas de trabajo requieren cierto grado de
especialización y operaciones avanzadas.
Garantizar que la base de referencia de administración proporcione un apoyo operativo en consonancia con
la dirección estratégica de la adopción de la nube.
suelen tener implicaciones en los costos, lo que aumenta la importancia del control de costos en relación con
los trabajos posteriores. Otras motivaciones futuras relacionadas con la innovación o el crecimiento a través
de la migración se pueden centrar más en los ingresos brutos. Conocer las motivaciones puede ayudarle a
decidir cuál debería ser el grado de prioridad de la administración de costos.
Justificación empresarial: La justificación comercial funciona como una vista general del plan financiero para
la adopción de la nube. Esta puede ser una buena forma de abordar las labores iniciales de presupuestación.

centralizado
Paso 4: Evaluar y planear la adopción de cargas de trabajo

El patrimonio digital (o el análisis de la cartera de TI existente) puede ayudar a validar la justificación comercial y
a proporcionar una vista mejorada de la cartera de TI. El plan de adopción aporta claridad en cuanto a la escala
de tiempo de las actividades durante la adopción. Alinear ese plan con el análisis del patrimonio digital permite
planear las futuras dependencias en cuanto a la administración de las operaciones.
La descripción del plan también invita al equipo de operaciones en la nube al ciclo de desarrollo. A continuación,
el equipo puede evaluar y planear cualquier cambio en la base de referencia de administración que sea
necesario para proporcionar operaciones de carga de trabajo.
Actualizar la plantilla de estrategia y plan para reflejar los cambios motivados por el análisis del patrimonio
digital.
Trabajar con el equipo de operaciones en la nube para definir claramente el grado de importancia y el
impacto empresarial de cada carga de trabajo en el plan de adopción a corto y a largo plazo.
Trabajar con el equipo de operaciones en la nube para establecer una escala de tiempo en relación con el
grado de preparación de las operaciones.
adopción.
Racionalización incremental: durante la racionalización incremental, utilice un análisis cuantitativo para
identificar a candidatos en la nube con fines de presupuestación.
Creación del plan de adopción de la nube: cree un plan con detalles sobre las cargas de trabajo, los recursos
y las escalas de tiempo accionables.

centralizado
Paso 5: Expandir las zonas de aterrizaje

La metodología de preparación de Cloud Adoption Framework hace mucho hincapié en desarrollar zonas de
aterrizaje para hospedar las cargas de trabajo en la nube. Durante la implementación de zonas de aterrizaje,
varias decisiones podrían afectar a las operaciones.
Consulte al equipo de operaciones en la nube para ayudar a revisar la zona de aterrizaje y mejorar las
operaciones. Consulte también al equipo de gobernanza de la nube para conocer las directivas de "coherencia
de recursos" y la guía de diseño, ya que pueden afectar al diseño de las zonas de aterrizaje.
corto plazo.
Asegurarse de que todas las zonas de aterrizaje cumplan las decisiones relativas a las operaciones y los
requisitos de coherencia de recursos.
Mejora de las operaciones en la zona de aterrizaje: procedimientos recomendados para mejorar las
operaciones dentro de una zona de aterrizaje.

Equipo de adopción de la nube Equipo de operaciones en la nube

centralizado
Paso 6: Adoptar
Las operaciones a largo plazo pueden verse afectadas por las decisiones que se tomen durante los trabajos de
migración e innovación. Mantener una alineación coherente de forma temprana en los procesos de adopción
ayuda a eliminar obstáculos para la versión de producción. También reduce el trabajo necesario para incorporar
nuevas soluciones a las prácticas de administración de operaciones.
Poner a prueba el grado de preparación operativa de las implementaciones de producción mediante
directivas de coherencia de recursos.
Validar el cumplimiento de la guía de diseño en la coherencia de los recursos y los requisitos de operaciones.
Documentar posibles requisitos de operaciones avanzadas en el libro de administración de operaciones.
Lista de comprobación de preparación del entorno
Lista de comprobación previa a la promoción
Lista de comprobación de las versiones de producción

centralizado
Los pasos anteriores le ayudarán a implementar los controles y los procesos para garantizar el rendimiento en
toda la empresa y en todos los recursos hospedados.
Primeros pasos: Vinculación de la organización
La adopción correcta de la nube es el resultado de un equipo de personas debidamente cualificadas, que realiza
los tipos de trabajo adecuados, en consonancia con objetivos empresariales claramente definidos y en un
entorno bien administrado. Para ofrecer un modelo de funcionamiento en la nube eficaz, es importante
establecer estructuras organizativas con el personal adecuado. En este artículo se describe un enfoque de este
tipo.
Paso 1: Conocimiento de las funciones necesarias para el

establecimiento correcto de los equipos de la nube
Esta es una lista que describe la funcionalidad mínima que necesita la organización para realizar con éxito la
adopción de la nube y las operaciones a largo plazo. Una vez que esté familiarizado con los equipos de la nube y
su función, puede alinearlos con la estructura de la organización que mejor se adapte a su personal y nivel de
madurez con respecto a la nube.
Las funciones de adopción de la nube ofrecen soluciones técnicas.
Las funciones de estrategia de la nube permiten adaptar los cambios técnicos a las necesidades
empresariales.
Las funciones de operaciones en la nube respaldan y utilizan las soluciones adoptadas.
Las funciones del Centro de excelencia de la nube (CCoE) mejoran la calidad, velocidad y resistencia de la
adopción.
Las funciones de gobernanza de la nube administran el riesgo.
Las funciones de la plataforma de nube hacen funcionar y madurar la plataforma.
Las funciones de automatización de la nube aceleran la adopción y la innovación.
Las funciones de seguridad de la nube administran los riesgos de seguridad.
Paso 2: Asignación de personas a las funciones necesarias

El siguiente paso consiste en asignar personas específicas a las funciones necesarias. Para ello, responda a las
siguientes preguntas:
¿Qué persona o grupo será responsable de realizar las tareas técnicas del plan de adopción de la nube?
¿Qué persona será responsable de la capacidad del equipo para entregar cambios técnicos?
¿Qué persona o grupo será responsable de la implementación de los mecanismos de gobernanza de
protección?
¿Qué persona será responsable de la definición de esos controles de gobernanza?
¿Existen otras funciones o personas que tengan responsabilidad en el plan de adopción de la nube?
Una vez que haya documentado las respuestas a estas preguntas, consulte los planes de preparación de las
aptitudes para ayudar a definir los planes de preparación de estas personas para el futuro trabajo.
Paso 3: Determinación de cómo se vinculan los equipos dentro de la

organización
Las siguientes estructuras organizativas no tienen por qué asignarse a un organigrama. Normalmente, los
organigramas reflejan estructuras de administración de mando y control. Por el contrario, las siguientes
estructuras organizativas están diseñadas para capturar la alineación de los roles y las responsabilidades.
En una organización matricial ágil, estas estructuras se pueden representar mejor como equipos virtuales. No
hay nada que sugiera que los equipos virtuales no puedan tener representación en un organigrama, pero
tampoco es necesario un organigrama formal para generar un modelo de funcionamiento eficaz.
Determine cómo encajan los siguientes modelos en las estructuras organizativas:
Alineación del organigrama: Las jerarquías de administración, las responsabilidades del administrador y
la alineación del personal se adaptarán a las estructuras organizativas.
Equipos vir tuales: Las estructuras de administración y los organigramas permanecen sin cambios. En su
lugar, se crearán equipos virtuales que se encargarán de las funcionalidades necesarias.
Modelo mixto: Es más habitual que se necesite una combinación de alineación de organigrama y equipo
virtual para conseguir los objetivos de transformación en la nube.
Paso 4: Establecimiento de estructuras de equipo

Durante cada trabajo de adopción de la nube hay ciertas funciones que debe proporcionar al menos una
persona. Estas asignaciones y estructuras de equipo se pueden desarrollar de forma orgánica o diseñarse de
manera intencionada para ajustarse a una estructura de equipo definida.
Se recomienda comenzar con dos equipos como mínimo para equilibrar los trabajos de adopción de la nube.
Los dos equipos siguientes son responsables de diversas funciones a lo largo del trabajo de adopción:
Equipo de adopción de la nube: responsable de las soluciones técnicas, la alineación del negocio, la
administración de proyectos y el funcionamiento de las soluciones adoptadas.
Equipo de gobernanza de la nube: para equilibrar el equipo de adopción de la nube, un equipo de
gobernanza de la nube se dedica a garantizar la excelencia en las soluciones adoptadas. El equipo de
gobernanza de la nube es responsable de la madurez de la plataforma, las operaciones de esta, la
gobernanza y la automatización.
Este enfoque probado se considera un producto viable mínimo porque podría no ser sostenible. Cada equipo se
ocupa de muchas tareas, como se explica en los gráficos RACI (siglas en inglés para entidades responsables,
encargadas, consultadas e informadas).
A medida que aumentan las necesidades de adopción, aumenta la necesidad de contar con un equilibrio y una
estructura. Para satisfacer estas necesidades, las empresas a menudo siguen un proceso de madurez de sus
estructuras organizativas.
Vea este vídeo para obtener una introducción sobre las estructuras de equipos comunes en varias fases de la
madurez de la organización.
Paso 5: Alineación de gráficos de RACI

En cada nivel de madurez, la responsabilidad de las diversas funciones de la nube cambia a nuevos equipos. Este
cambio de responsabilidad permite ciclos de migración e innovación más rápidos al eliminar y automatizar las
barreras a los cambios. Para alinear las asignaciones correctamente, el artículo sobre alineación de RACI
muestra un gráfico de RACI para cada una de las estructuras organizativas.
Información adicional
Adaptación de los roles, las aptitudes y los procesos existentes de la nube
Antipatrones de la organización: Islas y feudos
Descarga de la plantilla de RACI
Primeros pasos: Formación de un equipo de
estrategia de la nube
Para que se lleve a cabo correctamente, cada recorrido de adopción de la nube debe implicar cierto nivel de
planeación estratégica. Esta guía de introducción está diseñada para ayudarle a establecer un equipo dedicado o
un equipo virtual que pueda crear y entregar una estrategia en la nube sólida.
El primer paso del recorrido es decidir si necesita un equipo de estrategia o si los miembros del equipo existente
pueden entregar una estrategia de nube como una responsabilidad distribuida.
Independientemente del enfoque que elija, puede crear un equipo de estrategia de la nube que defina las
motivaciones y los resultados empresariales, y que valide y mantenga la alineación entre las prioridades
empresariales y los trabajos de adopción de la nube. Cuando los resultados empresariales afectan a las
funciones empresariales, el equipo de estrategia debe incluir a los líderes empresariales de toda la organización.
El objetivo del equipo de estrategia de la nube es generar resultados empresariales tangibles habilitados
mediante las tecnologías en la nube. En general, este equipo garantiza que el trabajo de adopción de la nube
progresa según los resultados empresariales. Siempre que sea posible, se deben definir los resultados
empresariales y los trabajos del equipo de estrategia de la nube en una fase temprana del proceso.
NOTE
En este artículo se describe un facilitador de la estrategia, un componente clave del proceso de adopción de la nube. El rol
lo suelen tener un administrador de programas, un arquitecto o un consultor. A medida que el equipo de estrategia en la
nube se crea e inicia, el facilitador de la estrategia es responsable temporalmente de crear la alineación y mantener el
equipo alineado con los objetivos empresariales. El facilitador de la estrategia suele ser la persona más responsable del
éxito del recorrido de adopción de la nube.
Paso 1: Determinar si es necesario un equipo de estrategia de la nube

Un equipo de estrategia de la nube entrega una funcionalidad necesaria en la nube, que se conoce como la
funcionalidad de la estrategia de la nube. Formar un equipo de estrategia de la nube requiere un grupo definido
de líderes empresariales dedicados, partes interesadas y administradores de programas que se reúna de
manera recurrente y periódica para avanzar en la estrategia que impulsa la adopción de la nube.
Determinar si la empresa requiere un equipo de estrategia en la nube.
La creación de un equipo de estrategia en la nube suele ser necesaria por los siguientes motivos:
M OT IVO C O N SIDERA C IO N ES
La adopción de la nube es impor tante para la El trabajo de adopción de la nube tiene visibilidad de nivel
empresa. ejecutivo.
El éxito del trabajo de adopción de la nube mejorará el
posicionamiento en el mercado, la retención de clientes o los
ingresos.
Los programas de la cartera de adopción se asignan
directamente a los resultados empresariales estratégicos.
La cartera de cargas de trabajo de este trabajo de
adopción es estratégica, crítica y puede afectar a varias
unidades de negocio.
La adopción de la nube requiere sopor te ejecutivo El trabajo de adopción de la nube afectará a tu manera de
continuo. administrar el cambio organizativo.
El trabajo requerirá el entrenamiento adicional de varios
usuarios empresariales y podría interrumpir determinadas
funciones empresariales.
El equipo o proveedor de operaciones de TI existente está
motivado a permanecer en un centro de datos existentes.
El equipo de TI existente no está totalmente convencido
del trabajo.
La adopción de la nube presenta un riesgo para la Si no se completa la migración dentro del período de
empresa. tiempo especificado, se producirá un impacto negativo en el
mercado o aumentarán los costos de hospedaje.
Las cargas de trabajo programadas para su adopción
deben protegerse frente a pérdidas de datos que podrían
afectar al éxito empresarial o a la seguridad del cliente.
Las métricas que se usan para medir el trabajo de la nube
están alineadas con el negocio, lo que supone una
dependencia y un riesgo para el éxito técnico.
Si alguno o todos los motivos anteriores representan sus consideraciones empresariales actuales, la
información del resto del artículo le ayudará a establecer su equipo de estrategia de la nube.
Persona o equipo responsable:
El facilitador de la estrategia es responsable de determinar si es necesario un equipo de estrategia de la nube.
¿Qué sucede si no necesito un equipo de estrategia de la nube?

Revise las funciones de estrategia de la nube necesarias para satisfacer las necesidades de dicha estrategia. No
todas las organizaciones requieren un equipo dedicado o un equipo virtual para ayudar a satisfacer sus
necesidades estratégicas. En la plantilla de RACI (responsable, aprobador, consultado e informado), enumere las
principales responsabilidades de la estrategia e identifique a la persona de su equipo que será responsable de
cada una de ellas. Si una persona va a asumir todas esas responsabilidades, reemplace "cloud strategy"
(estrategia de la nube) por el nombre de esa persona en la plantilla de RACI.
Paso 2: Establecer un equipo de estrategia de la nube

El equipo de estrategia de la nube actúa como punto de alineación recurrente entre los líderes de la empresa y
los líderes de TI. En función de los niveles de importancia, riesgo y soporte ejecutivo que impulsan la necesidad
de un equipo de estrategia, la participación y la composición del equipo pueden variar.
Identifique a las organizaciones o personas adecuadas que estén dispuestas a compartir la responsabilidad
de dirigir la estrategia de adopción de la nube.
Documente y comparta su razonamiento del paso 1 para identificar a las partes interesadas que se
beneficiarán de la implicación habitual y podrán ayudar a dirigir la estrategia.
Para obtener ideas sobre quién podría ser una buena opción, vea las funciones de la estrategia de nube.
Para validar la alineación y el ancho de banda de cada participante potencial, revise el ámbito mínimo y la
entrega de esta funcionalidad.
Para establecer el gráfico de RACI adecuado en función de las estructuras del equipo actual, revise los
distintos ejemplos de configuración de RACI o seleccione una de las pestañas de ejemplo de la parte inferior
de la plantilla de RACI.
Documente los resultados en la plantilla de RACI en la hoja de cálculo Org Alignment .

El facilitador de la estrategia es responsable de determinar si es necesario un equipo de estrategia de la nube.
Paso 3: Establecer una cadencia

En las primeras fases del recorrido de adopción de la nube, su equipo requerirá una interacción frecuente y
revisiones reiteradas de la estrategia. A medida que se inicie la adopción, esa frecuencia se reducirá, pasando a
centrarse en el estado y en la validación o el ajuste de las prioridades del trabajo pendiente.
Los pasos 4, 5 y 6 se deben completar en un plazo de cuatro a seis semanas. Los pasos restantes se completarán
en reuniones posteriores. Las reuniones más frecuentes deben mantenerse hasta que el equipo comience el
paso 7.
Revise las cadencias de reuniones sugeridas y programe reuniones con todos los participantes del equipo de
estrategia.
Revise las cadencias de reuniones sugeridas a corto y largo plazo para alinear a todos los participantes
documentados.
El facilitador de la estrategia es responsable de establecer la cadencia adecuada del equipo de estrategia de la
nube.
Paso 4: Establecer una estrategia basada en la motivación

Los recorridos de adopción de la nube incluyen enfoques de migración e innovación. Cuando los equipos
técnicos definen la estrategia, es habitual que la estrategia se base en las aptitudes y las virtudes actuales de los
miembros del equipo. Es probable que esta estrategia sea un éxito técnico, pero corre el riesgo de producir un
impacto empresarial limitado.
El primer objetivo del equipo de estrategia de la nube es definir una estrategia de alto nivel basada en las
motivaciones empresariales. Por lo general, esto se puede realizar en un taller de una hora con todos los
miembros del equipo de estrategia de la nube. También se requiere un mínimo de una hora adicional para
revisar las motivaciones empresariales con los diferentes equipos técnicos y las partes interesadas afectadas.
Durante el primer taller, cada miembro del equipo debe priorizar sus motivaciones del artículo de explicación de
las motivaciones y compartir sus prioridades principales. El facilitador de la estrategia ayuda a guiar una o
varias rondas de conversaciones hasta que surge un tema en la dirección de la migración o la innovación.
Probablemente habrá motivaciones en las tres primeras posiciones de las listas de ambas categorías, lo que
puede exigir que el equipo profundice en su lista hasta que un patrón claro lleve a una u otra dirección.
En este ejercicio se mostrarán conversaciones que pueden ayudar a crear la alineación entre los miembros del
equipo. La entrega le ayudará a guiar el resto de la estrategia y el plan resultante.
Registre las motivaciones en la plantilla de estrategia y plan.
Conocimiento de las motivaciones: Los eventos empresariales críticos y algunas motivaciones de migración
suelen tener implicaciones en los costos, lo que aumenta la importancia del control de costos en relación con
los trabajos posteriores. Otras motivaciones futuras relacionadas con la innovación o el crecimiento a través
de la migración se pueden centrar más en los ingresos brutos. Conocer las motivaciones puede ayudar a los
miembros del equipo a decidir cuál debería ser el grado de prioridad de la administración de costos.

centralizado
Paso 5: Establecer resultados empresariales

Cada miembro del equipo de estrategia de la nube debe definir uno o más resultados empresariales mediante la
aplicación de métricas específicas para medir el éxito empresarial. Si una métrica determinada se puede mejorar
como resultado directo del trabajo de adopción de la nube, se pide a un miembro del equipo que comparta el
impacto esperado. Si el esfuerzo de adopción de la nube no afecta a la métrica, pero permite a la empresa
controlarla mejor, también se debe documentar.
Muchos líderes del equipo de estrategia de la nube podrían tener que descomponer sus métricas principales
para identificar un resultado que pueda verse afectado por el trabajo de adopción de la nube. Si los resultados
de los miembros del equipo no se pueden ver afectados por este recorrido, es posible que les resulte difícil
mantener su nivel de interés en el programa. El facilitador debe trabajar con cada líder para desarrollar una
métrica alineada y volver a evaluar si ese miembro del equipo es la persona adecuada para participar en el
equipo de estrategia.
Los impactos en los resultados empresariales pueden llevar tiempo. Estos tipos de cambios suelen realizarse
más lentamente que los cambios técnicos. Para mantener la transparencia, el equipo de estrategia debe estar de
acuerdo en las métricas de aprendizaje a corto plazo. Estas métricas pueden incluir cambios técnicos y de otro
tipo que se pueden revisar en cada reunión de equipo para demostrar el progreso hacia los objetivos técnicos y
los resultados empresariales.
Identifique al menos un resultado empresarial esperado por miembro del equipo de estrategia de la nube.
Refine la lista de miembros para alinear los compromisos de tiempo esperados con los resultados esperados.
Acuerde un conjunto de métricas a corto y medio plazo para respaldar los informes de progreso en curso.
Registre los resultados empresariales en la plantilla de estrategia y plan.
Cuando los resultados deseados se corresponden con las métricas fiscales, es ideal invertir muy pronto en la
Las métricas de aprendizaje ayudan a salvar la diferencia entre los resultados empresariales y los trabajos de
adopción técnica.
Equipo encargado:
El equipo de estrategia de la nube es responsable de definir los resultados empresariales. El equipo puede usar
métricas específicas para medir el éxito de los resultados empresariales.
Paso 6: Decidir si se debe continuar o cancelar en función de la

justificación empresarial
La justificación empresarial puede ayudar con la planeación, las expectativas de devolución a largo plazo y las
expectativas de costo total de propiedad (TCO). En este paso, el equipo de estrategia de la nube debe estar de
acuerdo en la cantidad mínima de análisis necesaria para ayudar al equipo de estrategia a alinearse en una
decisión para avanzar. La alineación estratégica puede requerir un planeamiento profundo y análisis del TCO. La
mayoría de los equipos de estrategia de la nube encontrarán que un análisis de costos sencillo es suficiente para
alinearse en la dirección.
Cada miembro del equipo de la estrategia debe revisar los mitos y enfoques comunes a la justificación
empresarial. Esto puede ayudar al equipo a comunicar el análisis específico que se espera de los equipos de
soporte técnico. Una vez que el equipo haya comunicado sus expectativas, puede reducir su inversión de tiempo
y su frecuencia de reunión. El equipo seguirá siendo responsable de completar la estrategia hasta que se hayan
acordado la justificación empresarial y el análisis del patrimonio digital.
Inicie el trabajo de justificación empresarial con sus equipos de soporte técnico.
Reúnase con los equipos de soporte técnico mensualmente (o según sea necesario) hasta que el equipo de
estrategia pueda alinearse en la decisión de continuar con la adopción de la nube o cancelarla.
La justificación empresarial funciona como una vista general del plan financiero global en relación con la
adopción de la nube. Esta puede ser una buena forma de abordar las labores iniciales de presupuestación.

centralizado
Paso 7: Respaldar la adopción con una cadencia normal

Una vez acordada la decisión de avanzar con el equipo de estrategia de la nube, el equipo puede cambiar a una
cadencia de reunión menos intensiva y menos frecuente. Las expectativas del equipo también cambian en este
punto. Una vez que el recorrido pasa de la definición estratégica a los trabajos de adopción (planeamiento,
preparación y adopción), se espera que el equipo de estrategia se centre en la priorización y el soporte
estratégico.
Priorización: Cuando se racionaliza patrimonio digital existente, el equipo de estrategia ayuda a establecer
olas de prioridades de migración o innovación. Esto ayuda a los equipos de implementación técnica a
centrarse en las acciones que impulsan el mayor valor empresarial.
Evaluar riesgos: A medida que crece la adopción de la nube, las nuevas formas de adopción exponen
nuevos riesgos. El equipo de estrategia es responsable de ayudar a evaluar esos nuevos riesgos. La
expectativa del equipo de estrategia es evaluar los nuevos riesgos y determinar si la empresa puede tolerar
el riesgo o si necesita directivas que lo eviten.
Revisar el presupuesto y el gasto: A medida que aumente la adopción de la nube, también crecerán los
presupuestos de las distintas cargas de trabajo de la cartera. Mensualmente, el equipo de estrategia de la
nube debe revisar el gasto real contra el presupuesto para identificar problemas que deban resolverse. La
detección y gestión tempranas de cambios presupuestarios ayudarán a evitar sorpresas con los costos más
adelante en el ciclo de vida de la adopción.
Planeación empresarial: Cuando los equipos de adopción completen sus trabajos de migración o
innovación, se requerirá más planeamiento empresarial para maximizar el retorno de las nuevas soluciones
tecnológicas. Esta planeación podría incluir entrenamiento de usuarios finales, modificaciones de procesos
empresariales u otras actividades posteriores a la adopción.
Sopor te ejecutivo: La adopción de la nube tendrá como resultado un cambio organizativo. Este es más
visible en la organización de TI. A veces, es posible que varios equipos o miembros del equipo necesiten
soporte adicional del equipo de estrategia para comprender los cambios, desarrollar nuevas aptitudes y
comprender cómo funcionan mejor en los nuevos modelos.
Racionalización incremental: Considere la posibilidad de usar un enfoque ágil para la racionalización, que
alinee correctamente las decisiones técnicas enlazadas en tiempo de ejecución.
Las cinco R de la racionalización: Comprender las diversas opciones de racionalización.

centralizado
Pasos siguientes
La estrategia y el planeamiento son importantes. No se puede realizar ninguna acción hasta que se identifican
las funciones de adopción de la nube necesarias en el equipo. Es importante comprender estas funcionalidades
clave antes de comenzar con los trabajos de adopción.
Para alinear su estrategia con las funciones de adopción de la nube, trabaje con el equipo de adopción o los
individuos responsables de estas funciones.
Aprenda a alinear las responsabilidades de los equipos mediante el desarrollo de una matriz entre equipos que
identifique las entidades RACI. Descargue la plantilla RACI y modifíquela.
adopción de la nube
Los equipos de adopción de la nube son el equivalente moderno de los equipos de implementación técnica o los
equipos de proyecto. La naturaleza de la nube puede requerir estructuras de equipo más fluidas.
Algunos equipos de adopción de la nube se centran exclusivamente en la migración a la nube y otros se centran
en las innovaciones que aprovechan las tecnologías en la nube. Algunos equipos cuentan con los amplios
conocimientos técnicos necesarios para completar grandes trabajos de adopción, como una migración completa
del centro de datos, y otros tienen un enfoque técnico más estricto.
Un equipo más pequeño puede moverse entre proyectos para lograr objetivos específicos. Por ejemplo, un
equipo de especialistas de plataforma de datos se puede centrar en ayudar a convertir máquinas virtuales (VM)
de SQL Database en instancias de PaaS de SQL.
A medida que se amplía la adopción de la nube, los clientes se benefician de un equipo que está dedicado a la
función de plataforma en la nube. Ese equipo usa la implementación automatizada y la reutilización de código
para acelerar una correcta adopción. Las personas centradas en una función de plataforma en la nube pueden
implementar infraestructuras, patrones de aplicaciones, gobernanza y otros recursos de soporte técnico para
impulsar más eficiencias y coherencia, y para inculcar los principios de la nube en la organización. Las
organizaciones pequeñas y los equipos pequeños de adopción no tienen el lujo de un equipo con plena
dedicación para la plataforma en la nube. Le recomendamos que establezca una funcionalidad de
automatización en el equipo de adopción para empezar a ejercitar esta importante función de la nube.
Paso 1: Determinación del tipo de equipo de adopción que necesita

Los equipos de adopción de la nube tienden a realizar uno o varios de los siguientes tipos de adopción:
Migración de las cargas de trabajo existentes
Modernización de las cargas de trabajo y los recursos existentes
Cambio arquitectónico en las cargas de trabajo y los recursos existentes
Desarrollo de nuevas cargas de trabajo
La adopción de cualquier cartera de TI probablemente requerirá una combinación de estos tipos de trabajos.
Desafortunadamente, cada tipo requiere aptitudes y actitudes diferentes. Cuanto más especializado sea un
equipo, más eficaz y eficiente será ese equipo a la hora de realizar ese tipo de trabajo. Por el contrario, el
dominio de todas las opciones de implementación de la adopción de la nube puede ser un trabajo abrumador
para estos equipos más especializados.
Al formar por primera vez un equipo de adopción de la nube, la alineación de una de las metodologías de
adopción le ayudará a acelerar el desarrollo de las aptitudes colectivas del equipo.
Determine si el equipo se alinea mejor con la metodología de migración o la metodología de innovación.
Cada metodología tiene una experiencia de incorporación de cuatro pasos que ayuda al equipo a
comprender las herramientas y los procesos necesarios para conseguir un buen rendimiento. Invierta tiempo
como un equipo durante los primeros pasos para entender qué herramientas y escenarios es más probable
que necesite en las primeras iteraciones.
Alinee las responsabilidades de los equipos mediante la creación de una matriz que identifique a las
personas encargadas, responsables, consultadas e informadas (RACI, por sus siglas en inglés) . Actualice la
plantilla RACI de la empresa para ayudar a otros usuarios a comprender quién está en el equipo y qué
metodología utilizará el equipo para la entrega.
La introducción a la metodología de migración describe el proceso, las herramientas y los enfoques para
migrar y modernizar una cartera de cargas de trabajo.
La introducción a la metodología de innovación describe el proceso, las herramientas y los enfoques para
agregar cargas de trabajo nativas de nube a la cartera.
Comprenda las motivaciones que subyacen a este trabajo para ver si están mejor alineadas con los trabajos
de migración o innovación.
Paso 2: Alineación del equipo con otros equipos de apoyo

Si el trabajo de adopción de la nube de la empresa es lo suficientemente maduro como para tener equipos de
apoyo, es posible que pueda encontrar una lista de los equipos y expertos en la materia en la versión de la
empresa de la plantilla RACI, incluidos la gobernanza en la nube, las operaciones en la nube, un centro de
excelencia en la nube u otros equipos similares.
Revise la guía de diseño, las base de referencia operativas, las directivas y los procesos de los distintos
equipos de apoyo para comprender las protecciones que se han establecido para guiar la adopción de la
nube.
Revise la guía con otros equipos de adopción de la nube para conocer las limitaciones que podría encontrar
como resultado de dichas protecciones.
La evaluación de la directiva corporativa describe los pasos para definir la directiva corporativa, que podría
limitar las decisiones que el equipo puede tomar con seguridad en el entorno de nube de la empresa.
Las materias de gobernanza describen los tipos de controles o procesos de materias que es probable que el
equipo de gobernanza haya implementado para permitir la adopción segura y compatible de la nube.
La metodología de administración describe las consideraciones que entran en una base de referencia de
operaciones en la nube para proporcionar la administración de operaciones básicas.

El equipo de estrategia en la nube está encargado de Revise la guía y los requisitos en:
mantener una estructura RACI clara en todo el ciclo de vida Equipo de gobernanza de la nube
de adopción de la nube. Equipo de operaciones en la nube
centralizado
Otros equipos o usuarios de adopción de la nube que se
enumeran en RACI
Paso 3: Comienzo del viaje de adopción

En función del tipo de equipo de adopción del que sea miembro, comenzará con una de estas guías:
Primeros pasos: Migración de cargas de trabajo a la nube
Primeros pasos: Formación de nuevos productos o servicios
Estas guías ofrecen instrucciones para los diferentes equipos que se muestran junto con distintos grados de
cumplimiento y responsabilidad. Utilice estas guías para comprender cómo encaja su equipo en el resto del
recorrido. Úselas también para comprender los niveles de soporte técnico que puede esperar de la empresa.
Al final, el equipo de adopción de la nube es responsable de los resultados esperados de los trabajos de
migración asignados o del desarrollo del nuevo producto. Aunque los equipos de apoyo se encargan de
garantizar que se completen todos los pasos, es responsabilidad de cada equipo de adopción de la nube
asegurarse de que el equipo de apoyo está recibiendo el soporte técnico que necesita para tener éxito. Si el
equipo responsable todavía no existe o necesita más soporte técnico para completar los pasos encargados, se
recomienda al equipo de adopción asociarse con otros equipos para lograr los resultados.
Ser cada vez mejor en ofrecer la metodología asociada a su enfoque de adopción.
Ayudar a otros equipos a finalizar los pasos encargados, aunque dichos pasos sean bloqueadores de los
trabajos de adopción.
En la guía de introducción para la migración, el equipo de adopción se encarga de la entrega del paso 10:
Migración de la primera carga de trabajo.
En la guía de introducción para nuevos productos, el equipo de adopción se encarga de la entrega del paso 8:
Innovación en la nube.
El resto de los pasos de las listas de comprobación están pensados para que el trabajo sea más fácil de
administrar.
Equipo de adopción de la nube Equipo de gobernanza de la nube

centralizado
Paso 4: Ampliación de aptitudes con escenarios y procedimientos

recomendados
Después de una o dos iteraciones, el equipo de adopción de la nube comprenderá los aspectos básicos de su
metodología principal. A partir de ahí, es probable que el equipo esté preparado para asumir escenarios
adicionales y comenzar a implementar algunos procedimientos recomendados adicionales.
Aumente las aptitudes y la experiencia para abordar escenarios de adopción más complejos.
El equipo puede revisar y ampliar sus aptitudes mediante la revisión de las siguientes instrucciones:
Migre nuevos tipos de cargas de trabajo o resuelva los problemas de migración más complejos mediante
escenarios y procedimientos recomendados.
Innove con nuevas soluciones nativas en la nube o resuelva los desafíos de innovación más complejos
mediante escenarios y procedimientos recomendados.
Equipo encargado:
El equipo de adopción de la nube se encarga de expandir sus aptitudes.
Paso 5: Creación de una factoría de adopción de la nube

A medida que el equipo se familiarice con los distintos escenarios de adopción, podrá hacerlo más rápido. Esta
sección de la guía llevará las capacidades de adopción del equipo al siguiente nivel.
El enfoque de la factoría de adopción de la nube examina los procesos que subyacen en los trabajos de
adopción. Debido a la falta de reconocimiento y transparencia, la mayor parte de la carga de tiempo relacionada
con la migración y la innovación proviene del elevado volumen de reuniones. Definir claramente los procesos e
interacciones en las diversas fases del recorrido de adopción de la nube eliminará los bloqueadores culturales y
políticos.
Mejore los procesos de entrega para crear una factoría de adopción muy optimizado.
La guía de procesos para ayudar con los trabajos de migración puede encontrarse en la sección de mejoras
de procesos de la metodología de migración.
En la metodología de innovación, la guía se centra en los procesos de innovación que reducen la cantidad de
tecnología y facilitan un desarrollo de productos más eficaz.
Equipo encargado:
El equipo de adopción de la nube se encarga de crear los procesos que llevan la adopción al siguiente nivel.
Pasos siguientes
La adopción de la nube es un gran objetivo, pero si se realiza sin control puede producir resultados inesperados.
Para acelerar la adopción y los procedimientos recomendados, a la vez que se reducen los riesgos empresariales
y técnicos, alinee la adopción de la nube con las funciones de gobernanza de la nube.
La alineación con el equipo de gobernanza de la nube crea un equilibrio entre los trabajos de adopción de la
nube, pero se considera un producto viable mínimo (MVP), ya que podría no ser sostenible. Cada equipo se
ocupa de muchas tareas, tal y como se describe en los gráficos de RACI.
Más información sobre la superación de antipatrones de la organización: islas y feudos.
gobernanza de la nube
El equipo de gobernanza de la nube garantiza la evaluación y la administración correctas de los riesgos y la

tolerancia a estos. El equipo identifica los riesgos que no puede tolerar la empresa y los convierte en directivas
corporativas de regulación.
Paso 1: Determinar si es necesario un equipo de gobernanza de la

nube
La guía oficial para Cloud Adoption Framework consiste en crear siempre un equipo de gobernanza de la nube.
Al principio, el equipo puede ser muy pequeño. Independientemente de su tamaño, su rol es importante. Si un
equipo no es necesario, un grupo o un individuo del equipo de adopción existente debe aceptar las
responsabilidades asociadas a las funciones de gobernanza de la nube.
Determine si es necesario un equipo de gobernanza de la nube.
personas encargadas, responsables, consultadas e informadas (RACI, por sus siglas en inglés) . Documente
en la plantilla de RACI de la hoja de cálculo Org Alignment quiénes son las personas responsables y las que
toman las decisiones.
Las funciones de gobernanza de la nube pueden estar repartidas entre varios individuos o equipos. No es
importante tener un equipo denominado "equipo de gobernanza de la nube", pero las funcionalidades
necesarias deben permanecer en una entidad o un equipo responsable.
Si la estrategia de adopción de la nube a largo plazo de la empresa se puede entregar desde una zona de
aterrizaje a un entorno de nube, la cantidad de trabajos de gobernanza y operaciones podría ser lo
suficientemente pequeña para que se encargue una persona o un equipo. No es probable que ese equipo se
denomine de gobernanza de la nube, ya que atiende a muchas funciones más allá de la gobernanza de la
nube. Incluso para ese equipo, esta guía de introducción puede ayudarle a garantizar que puede desempeñar
esta importante función de gobernanza.
Paso 2: Alinearse con otros equipos

El equipo de gobernanza garantiza la coherencia y el cumplimiento de un conjunto de directivas comunes. Estas
directivas proceden de una alineación continua con otros equipos.
Antes de establecer las directivas o la gobernanza de la nube automatizada, el equipo de gobernanza de la nube
debe reunirse con otros equipos identificados en la plantilla de RACI. Esto ayudará a garantizar la alineación en
temas críticos, como la seguridad, el costo, el rendimiento, las operaciones y la implementación. Los pasos 4 y 5
pueden ayudar a facilitar la alineación.
Analice la implementación de estado actual y los planes de adopción en curso con cada equipo.
Revise la plantilla de estrategia y plan de su empresa con los miembros del equipo de estrategia de la nube
para comprender las motivaciones, las métricas y la estrategia.
Para comprender las escalas de tiempo y la priorización, revise el plan de adopción de la nube de su empresa
con los miembros del equipo de adopción de la nube.
Revise el libro de administración de operaciones del equipo de operaciones para comprender los requisitos
operativos y los compromisos que se han establecido con la empresa.

centralizado
Paso 3: Establecer una cadencia con otros equipos

Generalmente, la adopción de la nube se produce por oleadas o versiones. Una cadencia regular alineada con
esas versiones permite que el equipo de gobernanza de la nube anticipe y comprenda los riesgos que se
producirán en la oleada siguiente. Mantener el compromiso con la estrategia, la adopción y los equipos de
operaciones durante el planeamiento y la revisión también ayuda al equipo de gobernanza a anticipar futuros
riesgos.
Establezca una cadencia con los equipos de apoyo. Si es posible, alinee esa cadencia con los ciclos de
versiones y planeamiento.
Establezca una cadencia independiente directamente con el equipo de estrategia de la nube (o varios
miembros del equipo) para revisar los riesgos asociados a la siguiente oleada de adopción y calibrar el nivel
de tolerancia de dichos riesgos del equipo.
Para obtener más orientación sobre las cadencias de las reuniones, consulte las funciones de gobernanza de
la nube.

Paso 4: Revisar la metodología

Para ayudar a establecer una visión futura de gobernanza y un enfoque de trabajo para esa visión, revise la
metodología de gobernanza de Cloud Adoption Framework.
Comprenda la metodología, el enfoque y la implementación que admite la metodología de gobierno.
Revise la Metodología de gobierno.
Equipo encargado:
El equipo de gobernanza de la nube es responsable de establecer una visión y un enfoque para la
gobernanza.
Paso 5: Completar las pruebas comparativas de gobernanza

La gobernanza es un tema amplio. Esta breve evaluación puede ayudar al equipo a comprender cómo empezar.
Complete la evaluación de las pruebas comparativas de gobernanza basadas en conversaciones con distintas
partes interesadas. O bien, pida a otros equipos que completen la evaluación por su cuenta.
Use la prueba comparativa de gobernanza para evaluar sus necesidades y prioridades de gobernanza.
Equipo encargado:
El equipo de gobernanza de la nube debe comprender las diferencias identificadas en la prueba comparativa
de gobernanza y, a continuación, proporcionar instrucciones de gobernanza para corregir esas diferencias.
Paso 6: Implementar el procedimiento recomendado y la

configuración de gobernanza iniciales
La metodología de gobierno incluye dos enfoques para una base de gobernanza inicial. Revise cada uno de
estos enfoques e implemente el que mejor se ajuste a sus necesidades.
Implemente las herramientas básicas de gobernanza y las configuraciones de la organización necesarias para
la gobernanza del entorno durante las siguientes oleadas de trabajos de adopción.
Para obtener instrucciones sobre la configuración y la implementación, revise Establecimiento de una base
de gobernanza de la nube inicial.
Equipo encargado:
El equipo de gobernanza de la nube es responsable de la revisión y la implementación de los procedimientos
recomendados de gobernanza y de la base de gobernanza inicial.
Paso 7: Mejorar la madurez de la gobernanza continuamente

Los requisitos de gobernanza aumentan a medida que se completan los trabajos de adopción de la nube
adicionales. Manténgase alineado con el plan de adopción continuo para garantizar que el enfoque de
gobernanza pueda mantener los niveles adecuados de gobernanza y control.
Implemente mejoras de gobernanza para protegerse frente a riesgos y requisitos de gobernanza variables.
Para ayudar a mejorar la base de gobernanza inicial, implemente escenarios de gobernanza ampliados.
Equipo encargado:
El equipo de gobernanza de la nube es responsable de la alineación con los planes de adopción continua.
Paso 8: Evaluación de los cambios de la zona de aterrizaje

A medida que se implementan y expanden zonas de aterrizaje, pueden surgir nuevos riesgos o infracciones de
gobernanza. Revise periódicamente las configuraciones de la zona de aterrizaje para identificar cualquier
desviación de la directiva que las herramientas de gobernanza nativas de la nube no hayan capturado.
Asegúrese de que cada implementación de zona de aterrizaje cumpla las directrices de gobernanza de la zona
de aterrizaje.
Ayude al equipo de plataforma en la nube a desarrollar mejoras para la zona de aterrizaje, que deben
cumplir con las directivas de gobernanza.
Mejore la gobernanza de la zona de aterrizaje.
Equipo encargado:
El equipo de gobernanza de la nube debe asegurarse de que cada implementación de zona de aterrizaje
cumpla con las directrices de gobernanza.
Paso 9: Entregas de adopción

A medida que se completan nuevos trabajos de adopción, el equipo de adopción de la nube transfiere
responsabilidades operativas a los equipos de operaciones en la nube y de gobernanza de la nube. Manténgase
alineado con las cadencias de las versiones de adopción para garantizar la correcta alineación de la
documentación y las directivas, así como para ayudar al equipo a asumir la responsabilidad de las cargas de
trabajo.
Revise y acepte periódicamente las entregas de otros equipos de adopción de la nube.
Establezca un proceso de incorporación de nuevos recursos y cargas de trabajo.
Equipos de adopción de la nube Equipo de gobernanza de la nube

Pasos siguientes
Todas las empresas son únicas y, por lo tanto, también lo son sus necesidades de gobernanza. Elija el nivel de
madurez que mejor se adapte a su organización y use Cloud Adoption Framework para que guíe las prácticas,
los procesos y las herramientas que pueden ayudarle a conseguirlo.
A medida que la gobernanza de la nube madure, los equipos estarán capacitados para adoptar la nube a un
ritmo mayor. Los continuos trabajos de adopción de la nube tienden a desencadenar la madurez en las
operaciones de TI. Para asegurarse de que la gobernanza forme parte del desarrollo de las operaciones,
desarrolle un equipo de operaciones de la nube o bien permanezca sincronizado con su equipo de operaciones
de la nube.
operaciones de la nube
Un equipo de operaciones se centra en la supervisión, la reparación y la corrección de problemas relacionados

con operaciones y recursos de TI tradicionales. En la nube, muchos de los costos de capital y actividades de
operaciones se transfieren al proveedor de la nube, lo que proporciona a las operaciones de TI la oportunidad
de mejorar y agregar valor importante.
Paso 1: Determinar si es necesario un equipo de operaciones en la

nube
Antes de pasar cualquier carga de trabajo a producción, se debe alcanzar un acuerdo sobre la responsabilidad
de la entrega de las funciones de operaciones en la nube. En el caso de algunas carteras, las responsabilidades
operativas pueden pertenecer a los equipos de adopción de DevOps y de la nube. En otros casos, un proveedor
de servicios administrado con la experiencia de operaciones en la nube puede asumir obligaciones operativas
en curso.
Si no hay ningún acuerdo de operaciones de proveedor de servicios o DevOps, es seguro suponer que alguien
de TI deberá asumir las obligaciones operativas en curso con respecto a la administración de las cargas de
trabajo de producción.
Determine si es necesario un equipo de operaciones en la nube.
personas encargadas, responsables, consultadas e informadas (RACI, por sus siglas en inglés) . Documente
en la plantilla de RACI de la hoja de cálculo Org Alignment quiénes son las personas responsables y las que
toman las decisiones.
Las funciones de operaciones en la nube pueden estar repartidas entre varios usuarios o equipos. Decida si
es necesario un equipo de operaciones en la nube. Siempre se necesita algún nivel de operaciones para las
cargas de trabajo de producción.
Si la estrategia de adopción de la nube a largo plazo de la empresa se puede entregar desde una zona de
aterrizaje a un entorno de nube, los trabajos de gobernanza y de operaciones podrían ser lo suficientemente
pequeños como para que responsabilice una persona o un equipo. No es probable que ese equipo se
denomine de operaciones en la nube, ya que se ocupará de muchas funciones. Las instrucciones siguientes
pueden ayudar a esa persona o ese equipo a garantizar que puede desempeñar esta importante función de
las operaciones.

Paso 2: Alinearse con otros equipos

El equipo de operaciones en la nube hereda las responsabilidades operativas de todas las cargas de trabajo de la
cartera de producción. Estas responsabilidades pueden variar entre cargas de trabajo, en función de las
expectativas y los compromisos que el equipo ha contraído con las partes interesadas de la empresa. Las
decisiones arquitectónicas tomadas por los equipos de adopción de la nube centrados en la migración y la
innovación también influyen en los compromisos operativos del equipo.
Antes de que el equipo de operaciones en la nube implemente cualquier práctica de operaciones en curso, es
importante que se alinee con otros equipos. El equipo debe reunirse con otros equipos identificados en la
plantilla de RACI para garantizar la alineación sobre temas críticos, como la seguridad, el costo, el rendimiento,
la gobernanza, la adopción y la implementación. Los pasos 4 y 5 pueden ayudar a facilitar esta alineación.
Analice la implementación de estado actual y los planes de adopción en curso con cada equipo.
Para comprender las motivaciones, las métricas y la estrategia del equipo, revise la plantilla de estrategia y
plan de su empresa con los miembros del equipo de estrategia de la nube.
Para comprender las escalas de tiempo y la priorización, revise el plan de adopción de la nube de su empresa
con los miembros del equipo de adopción de la nube.
Para comprender los requisitos operativos y los compromisos que el equipo ha establecido con la empresa,
comience el desarrollo del libro de administración de operaciones.

centralizado
Paso 3: Establecer una cadencia con otros equipos

Generalmente, la adopción de la nube se produce por oleadas o versiones. Una cadencia regular alineada con
esas versiones permitirá que el equipo de operaciones en la nube se prepare para las entregas al final de la
siguiente oleada. Mantener el compromiso con la estrategia, la adopción y los equipos de gobernanza durante el
planeamiento y la revisión ayuda al equipo de operaciones a anticiparse a futuras demandas operativas.
Establezca una cadencia con los equipos de apoyo. Si es posible, alinee esa cadencia con los ciclos de
versiones y planeamiento.
Establezca una cadencia independiente directamente con el equipo de estrategia de la nube o sus distintos
miembros del equipo para revisar los requisitos operativos asociados a la siguiente oleada de adopción.
Para obtener orientación adicional sobre las cadencias de las reuniones, consulte la sección "entregas" de
funciones de operaciones en la nube.

Paso 4: Revisar la metodología

Para ayudar a establecer una visión futura de administración de operaciones y un enfoque de trabajo para llegar
a esa visión, revise la metodología de administración de Cloud Adoption Framework.
Comprenda la metodología, el enfoque y la implementación que respaldan la metodología de
administración.
Revise la metodología de administración de Cloud Adoption Framework.
Equipo encargado:
El equipo de operaciones en la nube es responsable de la visión y el enfoque de administración de
operaciones.
Paso 5: Implementar la base de referencia de operaciones

Si las prácticas de operaciones no están implementadas en sus entornos de nube, empiece con la base de
referencia de operaciones. Esa base de referencia implementará prácticas nativas de la nube, no operativas y con
pocas operaciones para proporcionar un nivel básico de protección operativa.
Implemente las configuraciones básicas de administración de servidor de Azure necesarias para operar el
entorno durante las siguientes oleadas de trabajos de adopción.
Implemente la configuración de base de referencia de operaciones.
Equipo encargado:
El equipo de operaciones en la nube es responsable de implementar la base de referencia de operaciones.
Paso 6: Alinear los compromisos empresariales

Revise los compromisos de la base de referencia de operaciones del equipo con las partes interesadas de la
empresa. Esta base de referencia le ayuda a evaluar los requisitos generales de la mayoría de las cargas de
trabajo. El proceso también ayuda a identificar las partes interesadas para varias cargas de trabajo y le permite
documentar sus expectativas operativas continuas.
Documente las expectativas de las partes interesadas de la empresa.
Determine si se requieren operaciones avanzadas para determinadas cargas de trabajo o plataformas.
Cree la alineación empresarial en la nube.
Documente las expectativas de la cartera y las operaciones en el libro de administración de operaciones.
Equipo encargado:
El equipo de operaciones en la nube debe comprender las expectativas empresariales y es responsable de la
alineación continua con esas expectativas.
Paso 7: Madurez de las operaciones

Al llevar a cabo mejoras operativas continuamente, el equipo puede:
Mejorar la base de referencia de operaciones.
Mejorar las operaciones de la plataforma.
Implementar operaciones específicas de la carga de trabajo.
A medida que las cargas de trabajo adicionales pasan a las operaciones en la nube, la necesidad de mejoras en
las operaciones se vuelve más clara.
Mejore la madurez de las operaciones para respaldar los compromisos con las partes interesadas de la
empresa.
Evalúe las mejores opciones de administración de operaciones avanzada.
Equipo encargado:
El equipo de operaciones en la nube es responsable de las mejoras operativas y la madurez con el tiempo.
Paso 8: Escalar la coherencia de las operaciones a través de la

gobernanza
A medida que la planeación de las operaciones sigue madurando, el equipo se debe coordinar con el equipo de
gobernanza de la nube periódicamente para aplicar los requisitos de operaciones en toda la cartera.
Ayude al equipo de gobernanza de la nube a implementar nuevos requisitos de coherencia de los recursos.
Revise la guía de gobernanza para mejorar la coherencia de los recursos.
Equipo de gobernanza de la nube Equipo de operaciones en la nube
Paso 9: Entregas de adopción

A medida que se completan nuevos trabajos de adopción, el equipo de adopción de la nube transfiere
responsabilidades operativas a los equipos de operaciones en la nube y de gobernanza de la nube. Para
garantizar la correcta alineación de la documentación y las directivas, así como para asumir la responsabilidad
de las cargas de trabajo, manténgase alineado con las versiones de adopción.
Revise y acepte periódicamente las entregas de los equipos de adopción de la nube.
Establezca un proceso de incorporación de nuevos recursos y cargas de trabajo.
Equipos de adopción de la nube Equipo de gobernanza de la nube

Pasos siguientes
A medida que se escalan las operaciones y la adopción, es importante definir y automatizar los procedimientos
recomendados de gobernanza que amplían los requisitos de TI existentes. La formación de un equipo de centro
de excelencia de la nube (CCoE) es un paso importante para escalar los trabajos de adopción de la nube,
operaciones en la nube y gobernanza de la nube.
Más información sobre:
Antipatrones de la organización: islas y feudos.
Alinee las responsabilidades de los equipos mediante el desarrollo de una matriz entre equipos que identifique
a las entidades RACI. Descargue la plantilla RACI y modifíquela.
Introducción a los escenarios híbridos y multinube
Microsoft Azure proporciona todos los productos y características necesarios para ayudarle a crear y usar sus
soluciones tecnológicas en la nube. También entendemos que hay razones empresariales sólidas que pueden
impulsar la necesidad de usar varias nubes privadas o públicas. Como primer paso en su recorrido por los
escenarios de nubes híbridas y multinube, en este artículo se describe y se trata la perspectiva que aporta
Microsoft sobre los términos importantes de informática en la nube.
Definición de nube híbrida y multinube

Una nube híbrida es un tipo de informática en la nube que combina una nube privada (infraestructura local) con
una nube pública (servicios informáticos ofrecidos por proveedores de terceros a través de la red pública de
Internet). Las nubes híbridas permiten que los datos y las aplicaciones se muevan de forma uniforme entre los
dos entornos de nube. Muchas organizaciones eligen una estrategia de nube híbrida debido a los requisitos
empresariales, como satisfacer los requisitos de cumplimiento normativo y soberanía de los datos, maximizar
las inversiones en tecnología local o abordar problemas de latencia.
La nube híbrida está evolucionando para incluir cargas de trabajo perimetrales. Los dispositivos informáticos
perimetrales administrados en la nube aportan la capacidad informática de la nube pública a la nube privada,
más cerca de dónde residen los dispositivos IoT, incluidos los datos que residen en aplicaciones, dispositivos
conectados y servicios móviles para el consumidor. Al reducir la latencia gracias al desplazamiento de las cargas
de trabajo al perímetro, los dispositivos dedican menos tiempo a comunicarse con la nube y pueden funcionar
de manera confiable durante periodos más prolongados de tiempo sin conexión. La disponibilidad ampliada de
proceso, almacenamiento y servicio proporciona recursos basados en la experiencia que están más cerca de sus
clientes.
La informática multinube hace referencia al uso de varios servicios de informática en la nube de más de un
proveedor de nube (incluidas nubes públicas y privadas), en un entorno heterogéneo. Una estrategia multinube
ofrece mayor flexibilidad y mitiga el riesgo. Puede elegir los servicios de diferentes proveedores de nube más
adecuados para una tarea específica o bien aprovechar los servicios que ofrece un proveedor de nube
determinado en una ubicación específica.
Narrativa híbrida y multinube

En este escenario se sigue una narración híbrida común y multinube, y se proporcionan instrucciones sobre qué
se puede hacer de manera diferente para que la tarea de adopción de la nube en la organización se culmine con
éxito. Esta descripción general no está restringida a una única metodología de adopción de la nube, sino que
ofrece un panorama del recorrido completo de la adopción de la nube.
Una plataforma de nube híbrida ofrece a su organización muchas ventajas: mayor flexibilidad, control y
escalabilidad, con más opciones de implementación, escala global, seguridad multiplataforma integrada,
cumplimiento unificado y rentabilidades mejoradas de carga de trabajo, funcionamiento y costo en toda la
empresa, lo que supone mayor valor de la infraestructura existente . Cuando la demanda informática y de
procesamiento fluctúa, la informática en la nube híbrida permite escalar verticalmente de forma fluida la
infraestructura local a la nube pública para controlar cualquier desbordamiento, sin necesidad de dar a los
centros de datos de terceros acceso a todos los datos. Al ejecutar determinadas cargas de trabajo en la nube, la
organización disfruta de la flexibilidad y la innovación que proporciona la nube pública, a la vez que conserva
los datos altamente confidenciales en su propio centro de datos para satisfacer las necesidades de los clientes, o
mantener el cumplimiento de los requisitos normativos.
Esto permite escalar los recursos informáticos, al tiempo que se modernizan y protegen las aplicaciones y los
datos críticos. Ya no hay que hacer frente a gastos ingentes de capital para satisfacer los picos a corto plazo en la
demanda ni se necesita forzar la liberación de recursos locales para almacenar más datos confidenciales. Con
los modelos de facturación en la nube, su organización solo pagará por los recursos que use temporalmente, en
lugar de tener que comprar, programar y mantener recursos y equipos adicionales que pueden permanecer
inactivos durante largos períodos.
Otro gasto de capital que se podría eliminar son las inversiones en la infraestructura de copia de seguridad y
recuperación ante desastres fuera del sitio. La nube pública para las estrategias de BCDR es una opción atractiva
para las cargas de trabajo locales y los datos asociados que no tienen ninguna restricción para alojarse en una
nube pública. Mediante el uso de la nube pública para BCDR, los clientes pueden aprovechar las principales
inversiones en privacidad y seguridad, escalar a petición, y facilitar y acelerar la recuperación.
Las compañías están ampliando sus recursos en el entorno local, en varias nubes y en el perímetro. Por lo
general, advertimos que los clientes tienen cuatro necesidades comunes:
1. Visibilidad del estado de todas las aplicaciones y la infraestructura existentes y futuras en un único panel.
2. Dificultad en la integración de las directivas y actualizaciones locales con la infraestructura de la nube. Las
organizaciones entienden la necesidad de implementar un estándar de gobernanza.
3. Una amplia gama de aptitudes en el entorno local y en la nube, ya que a menudo hay distintos equipos de
desarrollo de aplicaciones en la organización. Los clientes buscan una interoperabilidad coherente entre
ambos entornos, para que puedan unificar las prácticas de desarrollo.
4. Deseo de administrar la posición de seguridad, sin modificar considerablemente las operaciones actuales.
Los entornos de nube y multinube agravan este desafío, lo que puede disminuir la confianza y aumentar la
preocupación.
Considere la implementación de servicios nativos de nube en un entorno híbrido y multinube. A menudo, los
servicios en la nube se contextualizan estrictamente como "mover datos y aplicaciones a la nube pública". Una
estrategia híbrida es totalmente compatible con las operaciones del cliente que impiden el uso de la nube
pública para algunas cargas de trabajo, como es el caso de los sectores altamente reguladas, como la
infraestructura de la administración pública, la atención sanitaria y los servicios financieros. Dependiendo de la
geografía y de las regulaciones de soberanía de datos, es posible que sea necesario que los datos internos y de
clientes permanezcan dentro de los límites de los centros de datos locales. La sensibilidad de la latencia de datos
requiere que el proceso esté cerca de los datos de origen en centros de datos locales, y se esperan
interrupciones de conectividad a Internet, o tienen graves implicaciones. En estos casos, se pueden implementar
en los centros de datos locales soluciones híbridas que aportan servicios en la nube, menor sobrecarga de
administración (ya que mantienen estos servicios en el entorno local) y un modelo de facturación de la nube de
pago por uso.
Motivaciones de la nube híbrida y la multinube

Como verdadero proveedor de servicios en la nube de nivel empresarial, Azure cubre sus objetivos
empresariales en entornos públicos, híbridos y multinube. En esta serie se explican los procedimientos
recomendados que pueden facilitar diversas combinaciones de nube, que van desde los entornos 100 % Azure
hasta los entornos que tienen poca o ninguna infraestructura de Azure.
Reconocemos que hay muchas razones válidas para que los clientes opten por distribuir su patrimonio digital
en entornos híbridos y multinube. Estos son algunos de los impulsores empresariales habituales:
Minimizar o evitar la dependencia de un único proveedor de nube
Las unidades de negocio, las subsidiarias o las compañías adquiridas ya han adoptado distintas plataformas
en la nube
Diferentes proveedores de nube pueden tener requisitos de soberanía y de datos en diferentes países
Mejorar la continuidad empresarial y la recuperación ante desastres mediante la duplicación de cargas de
trabajo entre dos proveedores de nube
Maximizar el rendimiento mediante una ejecución de aplicaciones próxima a las ubicaciones de usuario, lo
que puede requerir una adopción híbrida o multinube
Permitir una migración sencilla en algunas plataformas de datos o aplicaciones específicas del sector
mediante la adopción de estrategias multinube
Preocupaciones del enfoque híbrido y multinube

Algunas de las motivaciones descritas anteriormente pueden convertirse en transformaciones empresariales
con una estrategia meditada de adopción híbrida y multinube.
Otras requieren esfuerzos importantes de implementación y tras la implementación para alcanzar estas ventajas
en la innovación. Es posible, por ejemplo, que se produzca dependencia del proveedor de nube. Para evitarlo, las
organizaciones deben limitar su visión sobre la adopción de la nube. Muchos de los productos y características
más ventajosos de un proveedor de servicios en la nube no se pueden portar a otros proveedores de nube. Para
lograr portabilidad y minimizar la dependencia, a menudo es necesario que las organizaciones limiten la
adopción de la nube a las funcionalidades básicas de infraestructura como servicio (IaaS), o bien que realicen
una gran inversión en el uso de tecnologías nativas de la nube como contenedores o Kubernetes.
Una vez que las cargas de trabajo se publican y están en producción, otra preocupación habitual asociada a las
superficies de adopción de nubes híbridas y multinube tiene que ver con las organizaciones que intentan
proporcionar asistencia de administración de operaciones a las cargas de trabajo en nuevos entornos y que a
menudo tienen que replantear rápidamente sus prácticas. Las plataformas de administración de operaciones
existentes (incluidas las directivas y los procesos de administración de operaciones existentes) no se crearon
para estos tipos de entornos. Para tener en cuenta las desviaciones en los entornos en la nube, las empresas a
menudo terminan con distintas herramientas de operaciones y prácticas de operaciones, lo que multiplica el
costo de las operaciones por el número de entornos en la nube que se admiten.
Siguiente paso: minimizar las preocupaciones que supone el enfoque

híbrido o multinube con operaciones unificadas
Debe comprender el concepto de operaciones unificadas antes de comenzar su recorrido híbrido y multinube;
las prácticas de operaciones coherentes en todos los entornos de nube con un plano de control común pueden
ayudar a abordar muchos aspectos relacionados con las estrategias híbridas y multinube.
Determine si necesita duplicar operaciones para cada proveedor de nube o implementar un enfoque de
operaciones unificadas para la administración en la nube antes de continuar con la adopción de la nube híbrida
y multinube a gran escala.
Introducción al escenario de adopción de
contenedores modernos
A medida que los clientes abordan formas más grandes y sofisticadas de adopción de la nube, su viaje a la nube
se vuelve más complejo. En esta serie de artículos se combinan las consideraciones técnicas y no técnicas
necesarias para preparar la integración de Kubernetes y los contenedores en su estrategia en la nube.
Este escenario se centra en dos resultados de destino:
Soluciones en contenedores: los contenedores crean una capa de abstracción entre los recursos técnicos
y la infraestructura subyacente. Las organizaciones incluyen contenedores en su estrategia general para
reducir la dependencia del proveedor y hacer que las cargas de trabajo sean más portátiles.
Administración de contenedores con Kubernetes: Kubernetes proporciona un plano de control para
administrar e implementar aplicaciones en contenedores, administrar la densidad de proceso y describir las
necesidades de alta disponibilidad de las cargas de trabajo.
En esta serie de artículos se describe cómo se pueden integrar los contenedores y la administración de
contenedores en las fases de estrategia, planeamiento, adopción y operaciones de su recorrido en la nube.
Componentes del escenario

Este escenario está diseñado para guiar el recorrido del cliente de un extremo a otro a lo largo del ciclo de vida
de la adopción de la nube. Para completar el recorrido se requieren algunos conjuntos de instrucciones
principales:
Cloud Adoption Framework : estos artículos le guiarán por el conjunto más pequeño de consideraciones e
implementaciones de cada metodología de CAF. Use estos artículos para preparar a los responsables de la
toma de decisiones, TI central y el centro de excelencia de la nube para la adopción de contenedores y la
administración de contenedores como parte central de su estrategia tecnológica.
Marco de buena arquitectura de Microsoft Azure: en estos artículos se describen las consideraciones
que debe tomar cada propietario de la carga de trabajo cuando es necesario implementar sus cargas de
trabajo con contenedores o soluciones de administración de contenedores como Kubernetes.
Arquitecturas de referencia: estas soluciones de referencia ayudan a acelerar la implementación de
soluciones de contenedores mediante Azure Kubernetes Service (AKS).
Productos de Azure destacados: más información sobre los productos que posibilitan su estrategia de
contenedores y administración de contenedores en Azure.
Módulos de Microsoft Learn: adquiera los conocimientos prácticos necesarios para implementar,
mantener y admitir soluciones de contenedores y AKS.
Recorridos comunes de clientes

Arquitecturas de referencia de AKS: las arquitecturas de referencia que se muestran en el panel izquierdo
demuestran cómo implementar diversas arquitecturas probadas para administrar las plataformas de
contenedores y Kubernetes con la ayuda de Azure Kubernetes Service (AKS). Estas arquitecturas son el punto de
partida sugerido para Kubernetes en Azure.
Migración de las cargas de trabajo existentes a AKS: un caso de uso común de AKS en Azure es
modernizar las cargas de trabajo basadas en web existentes directamente en una solución basada en
contenedores o nativa de nube, en lugar de los esfuerzos de migración tradicionales. En el artículo sobre la
migración a contenedores se muestra cómo puede acelerar Azure Migrate la migración de contenedores dentro
de los procesos de migración estándar.
Centralizar la implementación y administración de contenedores: en el primer conjunto de artículos del
panel izquierdo se proporcionan instrucciones completas sobre la centralización de la estrategia de
contenedores. Esta serie de artículos está pensada para ayudar a los equipos de TI central o del centro de
excelencia de la nube a comprender cómo los contenedores afectan a su estrategia en la nube y cómo
proporcionar soporte centralizado coherente.
Preparación para la gobernanza y operación de contenedores a gran escala: el conjunto de
construcción a escala empresarial demuestra cómo se pueden usar las zonas de aterrizaje a escala empresarial
para garantizar una gobernanza, seguridad y operaciones coherentes en varias zonas de aterrizaje para la
administración centralizada de contenedores a gran escala.
Implementación de productos específicos de Azure: acelere y mejore las funcionalidades de los
contenedores y de Kubernetes con diferentes tipos de productos de Azure descritos en la sección de productos
destacados.
Paso siguiente: Integración de contenedores modernos en el

recorrido de adopción de la nube
La siguiente lista de artículos le proporcionará orientación en puntos específicos del proceso de adopción de la
nube para ayudarle a tener éxito en el escenario de adopción de la nube.
Impacto estratégico de los contenedores modernos
Planeamiento de contenedores modernos
Revisión del entorno o las zonas de aterrizaje de Azure
Migración de cargas de trabajo a contenedores modernos
Innovación mediante soluciones de contenedores modernos
Gobernanza de soluciones de contenedores modernos
Administración de soluciones de contenedores modernos
Introducción a un escenario de adopción de SAP
En esta serie de artículos se describe el proceso de integración de una plataforma SAP en los esfuerzos de
Resumen ejecutivo de SAP en Azure

En estos artículos se describe cómo afectan las cargas de trabajo de SAP a una estrategia general, el plan de
adopción de la nube y los trabajos de preparación del entorno, con una guía detallada del desfase común de
cada trabajo. Una vez que se establece un entorno, en la serie no solo se explica los procesos necesarios para
migrar una plataforma SAP, sino también cómo usar las tecnologías en la nube para innovar en esa plataforma.
Para cubrir las necesidades de adopción de la nube, en la serie también se describen las consideraciones y los
procedimientos recomendados para administrar la gobernanza y las operaciones mediante una implementación
de SAP.
Para acelerar estos trabajos, los artículos también incluyen recursos técnicos detallados que describen cómo
crear una zona de aterrizaje de escala empresarial que pueda cubrir sus necesidades de SAP críticas.
Procedimientos para realizar la alineación con el marco de migración

de SAP
El equipo de SAP en Azure ha creado un exhaustivo marco para la migración e innovación con SAP en Azure.
Dicho marco es la guía principal para las organizaciones que se centran en ofrecer la mejor migración de SAP a
Azure. Si su máxima prioridad es migrar correctamente SAP a la nube, utilice esa guía.
En esta serie de artículos se describe un escenario de SAP para Cloud Adoption Framework y se complementa el
marco de migración de SAP actual. Estos artículos también están pensados para un público ligeramente
diferente con objetivos ligeramente diferentes y pueden resultar de ayuda a su organización si va a integrar la
migración de SAP en el plan general de adopción de la nube. Cuando las organizaciones migran a la nube, lo
habitual es que necesiten migrar, innovar y administrar varias cargas de trabajo y plataformas tecnológicas para
lograr sus objetivos empresariales. Esos trabajos se alinean con las metodologías de Cloud Adoption
Framework para los procesos y los enfoques coherentes de distintas cargas de trabajo y plataformas
tecnológicas.
Si su equipo sigue las instrucciones de ambos marcos, verá unas directrices muy similares en cuanto al
empaquetado que se alinea mejor con el público y sus objetivos. A continuación encontrará una lista de los
términos de las metodologías que pueden ayudar a ambos públicos a tener una conversación similar:
Descubra Cuando la adopción en la nube abarca varias plataformas

tecnológicas, resulta útil separar el proceso de detección en
dos conversaciones: Strategy , para atraer a los ejecutivos
empresariales durante la alineación estratégica, y Plan ,
para preparar el plan en función de los datos de estado
actual y futuro.
Preparación La metodología de preparación prepara tanto su equipo

como el entorno para el trabajo en ciernes. En este escenario
también se integran las zonas de aterrizaje de Azure para
proporcionar enfoques fundamentados y desarrollados
previamente que ayudan a su equipo a implementar
rápidamente entornos que pueden admitir diversas
plataformas tecnológicas.
Migrar La metodología de migración muestra la forma en que una

migración de SAP puede integrarse con otros procesos de
migración repetibles.
Ejecutar La metodología de administración muestra la forma en que

una línea base operaciones común no solo puede abordar
muchos de los problemas de estado de ejecución que se
abordan en la migración, sino también satisfacer las
necesidades operativas de otras plataformas tecnológicas.
Innovación La metodología de innovación describe la forma en que

puede llevar una plataforma SAP al siguiente nivel e integrar
soluciones nativas en la nube en sus cargas de trabajo.
Las directrices alinean estos orígenes para ayudar a los equipos de TI central y de SAP a trabajar conjuntamente
durante todas las fases de adopción de la nube.
El proceso de adopción de SAP

La adopción de cargas de trabajo de SAP en la nube incorpora y aborda la mayoría de las metodologías y fases
dentro de Cloud Adoption Framework. Las restricciones distintivas dentro de cada fase requerirán la realización
de acciones específicas en SAP y esta serie de artículos asigna procesos estándar a tareas específicas de SAP.
Pasos siguientes
En los artículos siguientes se proporcionan instrucciones específicas para puntos concretos del proceso de
adopción de la nube que le ayudarán a adoptar SAP en Azure.
Impacto estratégico de SAP en la nube
Planeación de la adopción de SAP Cloud en Azure
Migración de una plataforma SAP a Azure
Innovación con SAP
Administración de SAP
Antipatrones de adopción de la nube
Los clientes suelen experimentar antipatrones de adopción de la nube. Estos pasos en falso suelen producirse en
el diseño, el planeamiento o la implementación al realizar la migración a la nube. Los antipatrones pueden
bloquear la innovación e impedir que las empresas la adopción o el logro de sus objetivos.
En la tabla siguiente se enumeran los antipatrones y las metodologías, o las fases de adopción de la nube, en las
que se producen estos patrones. Los artículos vinculados proporcionan ejemplos de cada antipatrón y posibles
soluciones.
M ETO DO LO GÍA A N T IPAT RÓ N REF EREN C IA
Estrategia Motivación inadecuada Antipatrón: adoptar la nube sin

establecer los objetivos
Estrategia Motivación mal alineada Antipatrón: omitir la comunicación de

las motivaciones
Plan Modelo operativo de nube incorrecto Antipatrón: elegir el modelo operativo

de nube equivocado
Plan Modelo de servicio incorrecto Antipatrón: elegir el modelo de servicio

equivocado
Plan Reemplazo en lugar de modernización Antipatrón: arquitectura de reemplazo
Ready Versión preliminar de los servicios en Antipatrón: suponer que los servicios
producción publicados están preparados para
producción
Ready Suposiciones de disponibilidad y Antipatrón: suponer una mayor

resistencia inexactas resistencia y disponibilidad
Ready TI como proveedor de nube Antipatrón: convertirse en proveedor

de nube
Adoptar Falta de límites de protección Antipatrón: migración, modernización

o innovación sin límites de protección
Adoptar Falta de evaluaciones Antipatrón: migración, modernización

o innovación sin valoración
Adoptar Arquitectura forzada Antipatrón: dictar una arquitectura
Adoptar Suscripción única Antipatrón: usar una suscripción única
Administración Desatención de los resultados Antipatrón: centrarse en las

empresariales herramientas, no en los resultados
empresariales
M ETO DO LO GÍA A N T IPAT RÓ N REF EREN C IA
Control Responsabilidades compartidas mal Antipatrón: malinterpretar las

alineadas responsabilidades compartidas
Control Suposiciones de seguridad integrada Antipatrón: suponer que las soluciones

inexactas integradas proporcionan seguridad
Control Marcos de cumplimiento o gobernanza Antipatrón: usar un marco de

personalizados cumplimiento o gobernanza
personalizado
Organizar Centros de costos de TI Antipatrón: tratar el departamento de

TI como un centro de costos
Organizar Desarrollo de plataforma sin Antipatrón: invertir en nuevas

aprobación empresarial tecnologías sin la intervención de la
empresa
Organizar Subcontratación de funciones Antipatrón: subcontratar las principales

empresariales principales funciones empresariales
Organizar Responsables de la toma de decisiones Antipatrón: contratación de

técnicas en lugar de ingenieros de responsables de la toma de decisiones
nube técnicas en lugar de desarrollar
ingenieros de nube
Pasos siguientes
Antipatrones de estrategia de nube
Antipatrones del plan de adopción de la nube
Desarrollo de una estrategia de adopción de la
nube
La nube ofrece ventajas tecnológicas fundamentales que pueden ayudar a la empresa a ejecutar varias
estrategias de negocios. El uso de enfoques basados en la nube puede mejorar la agilidad empresarial, reducir
los costos, acelerar el tiempo de comercialización e, incluso, permitir la expansión a nuevos mercados. Para
aprovechar este gran potencial, es importante empezar por el proceso de documentación de la estrategia de
negocios, algo que se debe hacer de forma que sea comprensible para los técnicos de la nube y que resulte
atractiva para las partes interesadas del negocio.
Los siguientes pasos pueden ayudar a documentar la estrategia empresarial de manera eficaz. Este enfoque
ayuda a impulsar los trabajos de adopción que capturan los valores empresariales que se pretenden en un
modelo interdisciplinario. Así, puede asignar la estrategia de adopción de la nube a funcionalidades y estrategias
empresariales específicas de la nube con el fin de alcanzar el estado de transformación deseado.
Definición y documentación de las motivaciones: Reúnase

con las partes interesadas clave y la dirección para
documentar la motivación que hay detrás de la adopción de
la nube.
Documentación de los resultados empresariales: Implique a

las partes interesadas y a los ejecutivos motivados para que
documenten resultados empresariales concretos.
Desarrollo de un caso empresarial: Desarrolle un caso de

negocio para validar el modelo financiero que sea compatible
con las motivaciones y los resultados.
Elección adecuada del primer proyecto: El primer proyecto de

adopción de la nube le ayudará a alinear las motivaciones
con los esfuerzos técnicos. Este artículo puede ayudarle a
elegir el primer proyecto de un modo prudente.
Use la plantilla de planeamiento y estrategia para crear su estrategia de adopción de la nube y para hacer un
seguimiento de la salida de cada uno de los pasos que se han descrito anteriormente.
Motivaciones: ¿por qué se realiza el traslado a la
nube?
"¿Por qué se realiza el traslado a la nube?" Es una pregunta habitual que interesa por igual a los técnicos y los
comerciales. Si la respuesta es "La dirección (o el CIO o los ejecutivos de nivel C) nos ha ordenado migrar a la
nube", es poco probable que la empresa logre los resultados deseados.
En este artículo se tratan algunas motivaciones tras la migración a la nube que pueden ayudar a lograr
resultados empresariales más satisfactorios. Estas opciones ayudan a facilitar una conversación sobre las
motivaciones y, en última instancia, los resultados empresariales.
Motivaciones
Las transformaciones empresariales sustentadas por la adopción de la nube pueden impulsarse mediante varios
motivos. Es probable que se apliquen varias motivaciones al mismo tiempo. El objetivo de las listas de la tabla
siguiente es ayudar a generar ideas sobre qué motivaciones son pertinentes. A partir de ahí, puede clasificar por
orden de prioridad y evaluar el posible impacto de las motivaciones. En este artículo, el equipo de adopción de
la nube se debe reunir con varios ejecutivos y líderes empresariales con la lista siguiente para comprender
cuáles de estas motivaciones se ven afectadas por el esfuerzo de adopción de la nube.
EVEN TO S EM P RESA RIA L ES C RÍT IC O S M IGRA C IÓ N IN N O VA C IÓ N
Salida del centro de datos Ahorros en costos Preparación para nuevas

funcionalidades técnicas
Fusión, adquisición o desinversión Reducción de la complejidad técnica o
de proveedores Creación de nuevas funcionalidades
Reducción de gastos de capital técnicas
Optimización de las operaciones
Finalización del soporte técnico de internas Escalado para satisfacer demandas del
tecnologías críticas mercado
Aumento de agilidad empresarial
Respuesta a los cambios de Escalado para satisfacer demandas
cumplimiento normativo Preparación para nuevas geográficas
funcionalidades técnicas
Nuevos requisitos de soberanía de Experiencias de los clientes mejoradas
datos Escalado para satisfacer demandas del e involucración
mercado
Reducción de interrupciones y mejora Transformación de productos o
de la estabilidad de TI Escalado para satisfacer demandas servicios
geográficas
Reducción de la huella de carbono Perturbación del mercado con nuevos
Integración de una cartera de TI productos o servicios
compleja
Democratización y/o entornos de
autoservicio
Clasificación de las motivaciones

Las motivaciones para la adopción de la nube probablemente se incluyan en varias categorías. Cuando cree la
lista de motivaciones, es probable que emerjan tendencias. Las motivaciones tienden a asociarse más con una
clasificación que con otras. Use la clasificación predominante para ayudar a guiar el desarrollo de la estrategia
Cuando la prioridad más alta es dar respuesta a eventos empresariales críticos, es importante empezar con la
migración pronto, a menudo en paralelo con los esfuerzos de estrategia y planeamiento. Este enfoque requiere
una mentalidad de crecimiento y una disposición a mejorar de forma repetida los procesos en función de las
lecciones directas aprendidas.
Si la migración es la prioridad más alta, la estrategia y el planeamiento desempeñan un rol fundamental en una
fase temprana del proceso. Se recomienda implementar la primera carga de trabajo en paralelo con los
esfuerzos de planeamiento para ayudar al equipo a comprender y prever las curvas de aprendizaje asociadas a
la adopción de la nube.
Si la innovación es la prioridad más alta, la estrategia y el planeamiento requieren inversiones adicionales al
principio del proceso para garantizar el equilibrio de la cartera y una alineación sensata de la inversión realizada
durante la adopción de la nube. Para obtener más información y orientación, vea Descripción del recorrido de
innovación.
Para garantizar una toma de decisiones sensata, todos los participantes en el proceso de migración deben tener
un conocimiento claro de sus motivaciones. En la siguiente sección se explica cómo los clientes pueden guiar y
aplicar decisiones más sensatas a través de metodologías estratégicas coherentes.
Estrategias basadas en motivación y resultados empresariales

En esta sección se resaltan las motivaciones de migración e innovación y sus estrategias correspondientes.
Migración
Las motivaciones de migración que aparecen cerca de la parte superior de la tabla Motivaciones son las razones
más comunes, pero no necesariamente las más significativas, para adoptar la nube. El logro de estos resultados
es importante, pero se usan de forma más eficaz para realizar la transición a otros conceptos más útiles. Este
importante primer paso para la adopción de la nube a menudo se denomina migración a la nube. La
metodología de migración en Cloud Adoption Framework describe la estrategia para ejecutar una migración a
la nube.
Algunos motivos se alinean bien con una estrategia de migración. Las motivaciones de la parte superior de esta
lista probablemente tienen un impacto empresarial considerablemente menor que los de la parte inferior. Las
estrategias basadas en la motivación de la migración han ayudado a generar resultados empresariales
satisfactorios, como:
Aumento del ahorro de costos. Lea la historia del cliente.
Reducción de la complejidad técnica o de proveedores.
Optimización de las operaciones internas.
Aumento de la agilidad comercial. Lea la historia del cliente.
Preparación para nuevas funcionalidades técnicas.
Escalado según la demanda del mercado.
Escalado según la demanda geográfica. Lea la historia del cliente.
Innovación
Los datos son el nuevo producto básico y las aplicaciones modernas son la cadena de suministro que impulsa
esos datos hacia diversas experiencias. En el mercado empresarial de hoy en día, es difícil encontrar un producto
o servicio transformador que no se base en los datos, la información y las experiencias de los clientes. La
metodología de innovación en Cloud Adoption Framework incluye motivaciones alineadas con una estrategia
tecnológica que aparecen en una posición inferior en la columna Innovación de la lista de motivaciones anterior.
Las motivaciones que se enumeran a continuación centran una organización de TI más en una estrategia de
innovación que una estrategia de migración. Las estrategias basadas en la motivación de la innovación
han ayudado a generar resultados empresariales satisfactorios.
Aumento de la agilidad comercial.
Preparación para nuevas funcionalidades técnicas.
Creación de nuevas funcionalidades técnicas. Lea la historia del cliente.
Escalado según la demanda del mercado.
Escalado según la demanda geográfica.
Mejora de la experiencia e involucración de los clientes. Lea la historia del cliente.
Transformación de productos o servicios.
Pasos siguientes
La comprensión de los resultados empresariales previstos ayuda a facilitar las conversaciones que deben
mantenerse a hora de documentar las motivaciones y las métricas de respaldo, en alineación con la estrategia
empresarial. A continuación, lea información general sobre los resultados empresariales que suelen asociarse a
un traslado a la nube.
Información general sobre los resultados empresariales
¿Qué resultados empresariales se asocian con
procesos de transformación?
Los procesos de transformación con más éxito comienzan con un resultado empresarial en mente. Adopción de
la nube puede ser un esfuerzo en el que hay que invertir mucho tiempo y dinero. Fomentar el nivel adecuado de
soporte técnico de TI y otras áreas de la empresa es fundamental para el éxito. Esta serie de artículos está
diseñada para ayudar a los clientes a identificar resultados empresariales que son concisos, están definidos y
fomentan resultados observables o cambios en el rendimiento de la empresa, además de contar con el apoyo
de una medida concreta.
Durante todas las transformaciones en la nube la capacidad para hablar en términos de resultados soporta la
transparencia y las asociaciones interfuncionales. El marco de resultados empresariales comienza con una
plantilla sencilla que ayuda a los usuarios con mentalidad técnica a documentarse y conseguir un consenso.
Dicha plantilla se puede usar con varias de las partes interesadas del negocio para recopilar los distintos
resultados empresariales que podrían verse influidos por el proceso de transformación de una empresa. Dicha
plantilla se puede usar de forma electrónica, o mejor aún, se puede dibujar en una pizarra para que los líderes
empresariales y las partes interesadas puedan participar en debates acerca de dichos resultados.
Para más información sobre los resultados empresariales y la plantilla de resultados empresariales, vea cómo
documentar los resultados empresariales o descargue la plantilla de resultados empresariales.
Optimización de la inversión en la nube mediante la economía de la

nube
¿Cuáles son los aspectos básicos de la economía en la nube en Azure? Tanto si está ejecutando cargas de trabajo
existentes como si está diseñando nuevas soluciones en Azure, obtenga información sobre las prácticas
recomendadas para navegar por la economía de la nube de su organización y optimizar los costos operativos en
Azure en función de las cargas de trabajo específicas. Comience con la creación correcta de su caso de negocio
en la nube con orientación técnica y financiera clave, y maximice el beneficio total de su inversión en la nube.
Aprenda más sobre cómo funciona la economía de la nube.
Preparación para las conversaciones con distintos roles

A continuación encontrará algunos resultados empresariales que tienden a desencadenar conversaciones con
distintos roles:
Liderazgo financiero: : aumentar la rentabilidad sin perder de vista el cumplimiento.
Marketing: lograr nuevos clientes, conservar los conseguidos y crear una reputación.
Ventas: acelerar las ventas, mejorar el valor de los clientes.
Recursos humanos : conservar, contratar y capacitar a los empleados.
Liderazgo ejecutivo: cumplir los requisitos de crecimiento del mercado y las métricas de sostenibilidad
medioambiental.
Resultados de ejemplo por categoría

Hablar acerca de los resultados empresariales puede ser como hablar un idioma extranjero para muchas
personas con mente técnica. Para facilitar la traducción, mantenemos un conjunto de ejemplos de resultados
empresariales. Los siguientes ejemplos se pueden usar para inspirarse y mostrar los resultados empresariales
basados en procesos de transformación reales.
Para ayudarle a encontrar resultados empresariales más fácilmente, los hemos separado en las siguientes
categorías. Este enfoque tiende a impulsar conversaciones para alcanzar un consenso entre unidades de
negocio.
Resultados fiscales
El rendimiento financiero o fiscal es el resultado empresarial más limpio para muchos líderes de negocios, pero
no es el único.
Vea ejemplos de resultados fiscales.
El entorno empresarial actual cambia a velocidad de vértigo, por lo que el tiempo tiene especial importancia. La
capacidad de impulsar cambios en el mercado, o de dar una respuesta a tales cambios de forma rápida, es la
medida fundamental de la agilidad empresarial.
Vea ejemplos de resultados de agilidad.
Resultados de cobertura
En un mercado en constante reducción, la cobertura global (capacidad para dar soporte técnico a clientes y
usuarios globales) se puede medir por el cumplimiento en ubicaciones geográficas que son relevantes para la
empresa.
Vea resultados relacionados con la cobertura global.
Los mercados sociales están redefiniendo a los ganadores y perdedores a un ritmo inaudito. La respuesta a las
necesidades del usuario es una medida de clave del compromiso del usuario.
Más información acerca de los resultados de la involucración del usuario.
Tanto el rendimiento como la confiabilidad se dan por hecho. Su alguno de los dos flaquea, el daño en la
reputación puede ser doloroso y duradero.
Más información acerca de los resultados del rendimiento.
Objetivos de sostenibilidad
Las organizaciones cada vez debaten más sobre los objetivos medioambientales y de sostenibilidad.
Más información sobre los objetivos de sostenibilidad.
Todos y cada uno de los resultados empresariales que se enumeran en las categorías anteriores pueden ayudar
a facilitar una conversación centrada entre los miembros del equipo comercial y técnico. Sin embargo, no se
deben limitar las conversaciones a estos ejemplos genéricos. El conocimiento de las necesidades exclusivas de la
empresa y la generación de resultados coincidentes, maximizan el valor de una transformación en la nube.
Pasos siguientes
Obtenga más información sobre resultados fiscales.
Resultados fiscales
Innovaciones relacionadas con los datos
Muchas empresas quieren migrar su almacenamiento de datos existente a la nube. Sus motivos incluyen una
serie de factores, entre los que cabe destacar:
No hay que comprar hardware ni hay costos de mantenimiento.
No hay que administrar ninguna infraestructura.
La posibilidad de cambiar a una solución en la nube segura, escalable y de bajo costo.
Por ejemplo, el servicio de pago por uso nativo de nube de Azure denominado Azure Synapse Analytics
proporciona un sistema de administración de bases de datos analítico para las organizaciones. Las tecnologías
de Azure no solo ayudan a modernizar el almacenamiento de datos tras su migración, sino que también
amplían las funcionalidades analíticas y aportan más valor a su empresa.
Un proyecto de migración de almacenamiento de datos incluye muchos componentes. Entre estos elementos se
incluyen el esquema, los datos, las canalizaciones de extracción, transformación y carga de datos (ETL), los
privilegios de autorización, los usuarios, las capas de acceso semántico de herramientas de inteligencia
empresarial y las aplicaciones analíticas.
Una vez que el almacenamiento de datos se haya migrado a Azure Synapse Analytics, puede sacar provecho de
otras tecnologías del ecosistema de análisis de Microsoft, ya que ello le permite no solo modernizar el
almacenamiento de datos, sino también reunir la información sobre Azure generada en otros almacenes de
datos analíticos.
Puede ampliar el procesamiento ETL para que ingiera datos de cualquier tipo en Azure Data Lake Storage. Puede
prepararlo e integrarlo a escala mediante Azure Data Factory. Este produce recursos de datos de confianza y de
fácil manejo, que puede consumir el almacenamiento de datos y a los que también acceden los científicos de
datos y otras aplicaciones. Puede crear canalizaciones analíticas en tiempo real y orientadas a procesos por
lotes. También puede crear modelos de Machine Learning que se pueden implementar para ejecutarse en lotes,
en tiempo real, en datos de streaming y a petición.
Además, puede usar PolyBase para ir más allá del almacenamiento de datos. Esto simplifica el acceso a la
información que se produce en varias plataformas analíticas subyacentes en Azure. Puede crear vistas holísticas
integradas en un almacenamiento de datos lógico para acceder fácilmente al streaming, a los macrodatos y a la
información del almacenamiento de datos tradicional mediante herramientas y aplicaciones de BI.
En muchas empresas los almacenamientos de datos se han ejecutado durante años en sus centros de datos para
que los usuarios puedan producir inteligencia empresarial. Los almacenamientos de datos extraen datos de
sistemas de transacciones conocidos, los almacenan temporalmente y los limpian, transforman e integran para
rellenar almacenamientos de datos.
Los casos de uso, los casos de negocio y los avances tecnológicos permiten que Azure Synapse Analytics pueda
ayudarle con la migración del almacenamiento de datos. En las secciones siguientes se muestran muchos de
estos ejemplos.
Casos de uso
Innovación de productos conectados
Fábrica del futuro
Análisis clínico
Análisis de cumplimiento
Análisis basado en costos
Optimización omnicanal
Personalización
Cadena de suministro inteligente
Precios dinámicos
Análisis de adquisiciones
Torre de control digital
Administración de riesgos
Análisis de clientes
Detección de fraudes
Análisis de notificaciones
Casos empresariales
Cree soluciones de análisis completas con un único servicio de análisis.
Use Azure Synapse Analytics, que proporciona un área de trabajo unificada para la preparación,
administración y almacenamiento de datos, así como para los macrodatos y las tareas de inteligencia
artificial.
Cree y administre la canalización con un entorno visual sin código, automatice la optimización de consultas,
cree pruebas de concepto y use Power BI desde el mismo servicio de análisis.
Ofrezca información de los datos a los sistemas de almacenamiento de datos y a los de análisis de
macrodatos.
En el caso de las cargas de trabajo críticas, optimice el rendimiento de todas las consultas gracias a la
administración de las cargas de trabajo inteligentes, al aislamiento de las mismas y a una simultaneidad
ilimitada.
Edite y cree paneles de Power BI directamente desde Azure Synapse Analytics.
Reduzca el tiempo de desarrollo de proyectos de BI y de aprendizaje automático.
Comparta fácilmente los datos con unos pocos clics mediante la integración de Azure Data Share en Azure
Synapse Analytics.
Implemente un control de acceso pormenorizado con seguridad de nivel de columna y seguridad de nivel de
fila nativo.
Proteja automáticamente datos confidenciales en tiempo real con el enmascaramiento de datos dinámico.
Seguridad líder del sector con características de seguridad integradas, como la detección automática de
amenazas y el cifrado de datos siempre activo.
Avances tecnológicos
No es preciso adquirir hardware ni hay costos de mantenimiento, así que solo se paga por lo que se usa.
No hay que administrar ninguna infraestructura, por lo que se puede centrar en la información competitiva.
Procesamiento en paralelo masivo de consultas SQL con escalabilidad dinámica cuando lo necesita, pero que
se puede detener o apagar cuando no sea necesario.
Capacidad para escalar automáticamente el almacenamiento a partir del proceso.
Puede evitar actualizaciones innecesarias debido a que el tamaño de las áreas de almacenamiento
provisional del almacenamiento de datos empieza a ser excesivo, se está alcanzando el límite máximo de la
capacidad de almacenamiento y se hace imprescindible una actualización. Por ejemplo, mueva el área de
almacenamiento provisional a Azure Data Lake Storage y procésela con una herramienta de extracción,
transformación y carga de datos como Azure Data Factory u otra herramienta existente que se ejecute en
Azure a un menor costo.
Evite tener que realizar caras actualizaciones de hardware procesando cargas de trabajo de ETL en Azure
mediante Azure Data Lake Storage y Azure Data Factory. A menudo, esta solución es mejor que la ejecución
en el administrador de base de datos de almacenamiento de datos existente si el procesamiento de consultas
SQL realiza el trabajo. A medida que los volúmenes de datos del almacenamiento provisional aumentan, el
proceso de ELT consume un mayor almacenamiento y potencia de proceso en el almacenamiento de datos
local subyacente. Esto, a su vez, afecta al rendimiento de las cargas de trabajo de consulta, generación de
informes y análisis.
Evite crear grandes data marts que usen licencias de software de almacenamiento y bases de datos en
hardware local. En su lugar, puede crearlos en Azure Synapse Analytics. Esto sucede sobre todo si el
almacenamiento de datos es un diseño de Data Vault, ya que este tipo de diseños a menudo provoca una
mayor demanda de data marts.
Evite el costo de analizar y almacenar un volumen de datos grande, a gran velocidad y en hardware local. Por
ejemplo, si necesita analizar datos generados por la máquina en tiempo real, como las secuencias de clics y el
streaming de datos de IoT en el almacenamiento de datos, puede usar Azure Synapse Analytics.
Puede evitar pagar una cantidad extra por el almacenamiento de datos en hardware de almacenamiento
costoso en el centro de datos a medida que crezca el almacenamiento de datos. Azure Synapse Analytics
puede almacenar los datos en el almacenamiento en la nube con un costo menor.
Pasos siguientes
Muchas empresas mantienen almacenamientos de datos en los centros de datos para ayudar a los diferentes
departamentos a analizar los datos y tomar decisiones. Los departamentos de ventas, marketing y finanzas
confían en gran medida en estos sistemas a la hora de generar informes y paneles estándar. Las compañías
también emplean analistas de negocios para realizar consultas y análisis ad hoc en los datos de los data marts.
Estos data marts usan herramientas de inteligencia empresarial con características de autoservicio para realizar
análisis multidimensionales.
Una empresa puede, con la ayuda de la innovación y un moderno patrimonio de datos, capacitar a una amplia
gama de colaboradores, desde partes interesadas de TI a profesionales de datos, etc. Pueden tomar medidas en
este repositorio de datos centralizado que a menudo se conoce como "única fuente de información veraz".
Azure Synapse Analytics es un servicio único para una colaboración íntegra y con un menor tiempo de análisis.
Para comprender con más detalle este servicio, tenga en cuenta en primer lugar los distintos roles y habilidades
implicados en un patrimonio de datos típico:
Almacenamiento de datos : los administradores de bases de datos ayudan con la administración de lagos de
datos y almacenamientos de datos, al tiempo que optimizan las cargas de trabajo de forma inteligente y
protegen los datos automáticamente.
Integración de datos : los ingenieros de datos usan un entorno sin código para conectar fácilmente varios
orígenes y tipos de datos.
Macrodatos y aprendizaje automático : los científicos de datos crean pruebas de concepto rápidamente y
aprovisionan recursos, a la vez que trabajan en el lenguaje de su elección (por ejemplo, T-SQL, Python, Scala,
.NET o Spark SQL).
Administración y seguridad : los profesionales de TI protegen y administran los datos de forma más eficaz,
aplican los requisitos de privacidad y protegen el acceso a configuraciones híbridas y en la nube.
Inteligencia empresarial : los analistas de negocios acceden de forma segura a los conjuntos de datos, crean
paneles y comparten datos dentro y fuera de su organización.
Información general sobre la arquitectura clásica de almacenamiento

de datos
En el diagrama siguiente se muestra un ejemplo de arquitectura de almacenamiento de datos clásica.
Figura 1: Arquitectura clásica de almacenamiento de datos.

Los datos estructurados conocidos se extraen de los sistemas de procesamiento de transacciones principales y
se copian en un área de almacenamiento provisional. Desde allí, se limpian, transforman e integran en las tablas
de producción de un almacenamiento de datos. Es habitual que se generen aquí varios años de datos de
transacciones históricos. Esto proporciona los datos necesarios para comprender los cambios en las ventas, el
comportamiento de compra de los clientes y la segmentación de clientes a lo largo del tiempo. También
proporciona informes y análisis financieros año a año para ayudar con la toma de decisiones.
A partir de ahí, los subconjuntos de datos se extraen en data marts para analizar la actividad asociada a un
proceso comercial específico. Esto permite apoyar la toma de decisiones en un departamento específico de la
empresa.
Para que una empresa funcione de forma eficaz, se necesitan todos los tipos de datos para las distintas aptitudes
y roles descritos anteriormente. Se necesitan datos sin procesar que se hayan limpiado para que los científicos
de datos creen modelos de Machine Learning. Se necesitan datos limpios y estructurados para que un
almacenamiento de datos ofrezca un rendimiento confiable a los paneles y aplicaciones empresariales. Lo más
importante es que debe poder pasar de datos sin procesar a conclusiones en minutos, no en días.
Azure Synapse Analytics tiene una herramienta de inteligencia empresarial nativa integrada con
Microsoft Power BI. En este caso, un servicio dentro de una interfaz le ayuda a transformar rápidamente los
datos sin procesar en un panel que muestra conclusiones.
Pasos siguientes
Innovaciones relacionadas con los datos
Ejemplos de resultados fiscales
En el nivel superior, las conversaciones fiscales constan de tres conceptos básicos:

Ingresos: ¿entrará más dinero en la empresa como resultado de las ventas de bienes o servicios?
Costo: ¿se dedicará menos dinero a la creación, el marketing, las ventas o la entrega de bienes o servicios?
Beneficio: aunque es poco habitual, algunas transformaciones pueden aumentar los ingresos y reducir los
costos. Este es un resultado de beneficios.
En el resto de este artículo se explican estos resultados fiscales en el contexto de una transformación a la nube.
Sentara Healthcare trasladó sus datos a Azure, lo cual proporcionó a sus miembros una mejor experiencia con
aplicaciones móviles, un acceso más rápido de los médicos a los datos críticos para conseguir diagnósticos más
rápidos, costos reducidos para el equipo de TI y mejora de la atención al paciente con una organización más ágil
y preparada para los cambios.
NOTE
Los ejemplos siguientes son hipotéticos y no se deben considerar como una garantía de rendimientos al adoptar cualquier
estrategia de nube.
Resultados de ingresos
Nuevos flujos de ingresos
La nube ayuda a crear oportunidades de entrega de nuevos productos a los clientes o de entrega de productos
ya existentes de nuevas maneras. Los nuevos canales de ingresos son innovadores, emprendedores y
emocionantes para muchas personas del mundo empresarial. Pero también son propensos a errores y en
muchas compañías se consideran de alto riesgo. Cuando el equipo de TI propone resultados relacionados con
los ingresos, es probable que haya resistencia. Para dar mayor credibilidad a estos resultados, colabore con
líderes empresariales que hayan demostrado ser innovadores. La validación de la fuente de ingresos al principio
del proceso le ayudará a evitar los escollos del negocio.
Ejemplo : Una compañía lleva más de 100 años vendiendo libros. Un empleado de la empresa se da cuenta
de que el contenido se puede enviar electrónicamente. Este empleado crea un dispositivo que se puede
vender en la librería, que permite descargar los mismos libros directamente. Esto supone un aumento de
x USD en la venta de libros nuevos.
Aumento de ingresos
Gracias a la escala global y a la presencia digital, la nube ayuda a las empresas a aumentar los ingresos
procedentes de los canales de ingresos existentes. Con frecuencia, este tipo de resultado procede de una
alineación con la dirección de marketing o ventas.
Ejemplo : Una compañía que vende widgets podría vender más si los vendedores pudieran acceder de forma
segura al catálogo digital y los niveles de existencias de la compañía. Por desgracia, esos datos solo se
encuentran en el sistema ERP de la compañía, al que solo se puede acceder mediante un dispositivo
conectado a la red. La creación de una fachada de servicio que sirva de interfaz con ERP, de forma que se
exponga el catálogo y los niveles de existencias no confidenciales en una aplicación en la nube, permitiría al
personal de ventas acceder a los datos que necesitan mientras se encuentran en las instalaciones de un
cliente. La extensión de Active Directory con Azure Active Directory (Azure AD) y la integración del acceso
basado en rol en la aplicación permitirían a la compañía garantizar la seguridad de los datos. Este sencillo
proyecto podría afectar un X % a los ingresos de una línea de productos existente.
Aumento de beneficios
Raro es que un único esfuerzo aumente los ingresos y reduzca los costos simultáneamente. Sin embargo,
cuando lo haga, alinee los informes de resultados de uno o varios resultados de ingresos con uno o varios de
los resultados de costos para comunicar el resultado deseado.
Resultados de costos
Reducción de costos
La informática en la nube puede reducir los gastos de capital del hardware y el software, la configuración de
centros de datos, el funcionamiento de centros de datos locales in situ, etc. Los costos de los bastidores de
servidores, el suministro eléctrico ininterrumpido para alimentación y refrigeración y los expertos de TI que
administran la infraestructura los aumentan rápidamente. Apagar un centro de datos puede reducir los gastos
de capital. A esto se le conoce normalmente como "salir del negocio del centro de datos". La reducción de los
costos se mide normalmente en dólares en el presupuesto actual, que puede abarcar de 1 a 5 años, según cómo
administre las finanzas el director financiero (CFO).
Ejemplo 1: El centro de datos de una compañía gasta un gran porcentaje del presupuesto de TI anual. El
departamento de TI decide ejecutar una migración a la nube y traslada los recursos del centro de datos a
soluciones de infraestructura como servicio (IaaS), de forma que se crea una reducción de costos de 3 años.
Ejemplo 2: Una sociedad de cartera ha adquirido recientemente una nueva compañía. En la adquisición, los
términos dictaminan que la nueva entidad se debe retirar de los centros de datos actuales en un plazo de 6
meses. Si no lo hace, deberá pagar una multa de 1 millón USD al mes a la sociedad de cartera. Mover los
recursos digitales a la nube mediante una migración podría permitir una rápida retirada de los recursos
antiguos.
Ejemplo 3: Una compañía de impuestos de renta que atiende a consumidores obtiene un 70 % de sus
ingresos anuales durante los tres primeros meses del año. El resto del año, su enorme inversión en TI
permanece relativamente inactiva. Una migración a la nube permitiría al equipo de TI implementar la
capacidad de proceso y hospedaje necesaria para esos tres meses. Durante los nueve meses restantes, se
podrían rebajar considerablemente los costos de IaaS mediante la reducción de la superficie de proceso.
Ejemplo: Coverdell
Coverdell moderniza su infraestructura para impulsar el ahorro en los costos de registro con Azure. La decisión
de Coverdell de invertir en Azure y de unir su red de sitios web, aplicaciones, datos e infraestructura dentro de
este entorno, les generó unos ahorros en los costos mayores de lo que jamás habrían esperado. La migración a
un entorno solo de Azure eliminó 54 000 USD en costos mensuales por servicios de ubicación. Solo con la
nueva infraestructura unida de la compañía, Coverdell espera ahorrar casi 1 millón USD durante los próximos 2
o 3 años.
"Tener acceso a la pila de tecnología de Azure abre la puerta a soluciones escalables, fáciles de implementar
y con una gran disponibilidad que son rentables. Así nuestros arquitectos pueden ser mucho más creativos
con las soluciones que proporcionan".
Ryan Sorensen
Director de desarrollo de aplicaciones y arquitectura empresarial
Coverdell
Prevención de costos
La terminación de los centros de datos también proporciona prevención de costos al impedir futuros ciclos de
actualizaciones. Un ciclo de actualización es el proceso de comprar nuevo hardware y software para reemplazar
los sistemas antiguos locales. En Azure, el hardware y el sistema operativo reciben habitualmente
mantenimiento, revisiones y actualizaciones sin costo adicional para los clientes. De esta manera, el director
financiero puede eliminar los gastos futuros planeados de las previsiones financieras a largo plazo. La
prevención de costos se mide en dólares. Se diferencia de la reducción de costos en que normalmente se centra
en un presupuesto futuro que aún no se ha aprobado completamente.
Ejemplo : El centro de datos de una compañía está pendiente de una renovación del alquiler en 6 meses. El
centro de datos ha estado en servicio durante ocho años. Hace 4 años, todos los servidores se actualizaron y
virtualizaron, lo que supuso un costo para la compañía de millones de dólares. El próximo año, la compañía
planea actualizar de nuevo el hardware y el software. La migración de los recursos de ese centro de datos,
como parte de una migración a la nube, permitiría prevenir costos al eliminar la actualización planeada del
presupuesto previsto para el próximo año. También podría generar una reducción de los costos, ya que se
reducen o eliminan los costos de arrendamiento de bienes inmuebles.
Gastos de capital y gastos operativos
Antes de analizar los resultados de costos, es importante comprender las dos opciones de costo principales:
gastos de capital y gastos operativos.
Los siguientes términos le ayudarán a comprender las diferencias entre los gastos de capital y los gastos
operativos durante los debates empresariales sobre un proceso de transformación.
Capital es el dinero o los activos que pertenecen a una empresa y que contribuyen a un propósito en
particular, como aumentar la capacidad del servidor o crear una aplicación.
Los gastos de capital generan beneficios durante un largo período. Estos gastos no son recurrentes por lo
general y dan lugar a la adquisición de activos permanentes. La creación de una aplicación podría calificarse
como gasto de capital.
Los gastos operativos son los costos continuos que resultan de la actividad de la empresa. El consumo de
servicios en la nube en un modelo de pago por uso se podría considerar como gasto operativo.
Los activos son recursos económicos que se pueden tener o controlar para generar valor. Los servidores,
lagos de datos y aplicaciones podrían considerarse activos.
La depreciación es una reducción del valor de un activo con el paso del tiempo. Más importante para el
debate entre gastos de capital y gastos operativos, es ver cómo los costos de un activo se asignan en los
períodos en los que se usan. Por ejemplo, si crea una aplicación este año, pero se espera que tenga una vida
útil de 5 años (como la mayoría de las aplicaciones comerciales), el costo del equipo de desarrollo y de las
herramientas necesarias para crear e implementar la base de código se depreciaría uniformemente durante
cinco años.
Valoración es el proceso de estimar qué valía tiene una compañía. En la mayoría de los sectores, la
valoración se basa en la capacidad de la compañía para generar ingresos y beneficios, y respetar al mismo
tiempo los costos operativos necesarios para crear los bienes que proporcionan ese ingreso. En otros
sectores, como el del comercio minorista, o en algunos tipos de transacción como el capital privado, los
activos y la depreciación pueden jugar un papel muy importante en la valoración de la compañía.
A menudo resulta una apuesta segura que distintos ejecutivos, incluido el jefe de inversiones (CIO), analicen el
mejor uso del capital para hacer crecer la compañía en la dirección deseada. Dar al jefe de inversiones los
medios para convertir conversaciones polémicas sobre gastos de capital en una clara rendición de cuentas de
gastos operativos podría ser un atractivo resultado en sí mismo. En muchos sectores, los directores financieros
buscan activamente formas de asociar mejor la responsabilidad fiscal con el costo de los bienes vendidos.
Sin embargo, antes de asociar cualquier proceso de transformación con este tipo de conversión de gastos de
capital a gastos operativos, es aconsejable reunirse con los miembros de los equipos de CFO o CIO para ver qué
estructura de costos prefiere la empresa. En algunas organizaciones, la reducción de los gastos de capital en
favor de los gastos operativos es un resultado no deseado. Como se mencionó anteriormente, este enfoque se
observa a veces en el comercio minorista, las sociedades de cartera y las compañías de capital privado que
otorgan un gran valor a los modelos tradicionales de contabilidad de activos fijos y muy poco al protocolo de
Internet. También se observa en organizaciones que han tenido experiencias negativas al subcontratar personal
de TI u otras funciones en el pasado.
Si el modelo de gastos operativos es deseable, el ejemplo siguiente podría ser un resultado empresarial viable:
Ejemplo : El centro de datos de la empresa se deprecia actualmente a x USD al año durante los próximos
3 años. Se espera que se necesiten y USD adicionales para actualizar el hardware el próximo año. Se pueden
convertir todos esos gastos de capital en un modelo de gastos operativos con un índice constante de z USD
al mes, lo que permite una mejor administración y contabilidad de los costos de funcionamiento de la
tecnología.
Pasos siguientes
Obtenga más información sobre resultados de agilidad.
Ejemplos de resultados de agilidad
Como se ha tratado en la información general sobre resultados empresariales, varios resultados empresariales
potenciales pueden servir como base para cualquier conversación de recorrido de transformación con la
empresa. Este artículo se centra en la medida empresarial más oportuna: la agilidad empresarial. Comprender la
posición en el mercado y el panorama competitivo de su empresa puede ayudarle a articular los resultados
empresariales que son el objetivo del recorrido de transformación de la empresa.
Tradicionalmente, los directores de inversiones y los equipos de TI eran considerados como una fuente de
estabilidad en procesos críticos principales. Esto sigue siendo cierto. Pocas empresas pueden funcionar bien si
su plataforma de TI es inestable. Sin embargo, en el mundo empresarial de hoy en día, se espera mucho más. El
equipo de TI puede expandirse para convertirse en algo más que un simple centro de costo al asociarse con la
empresa para proporcionar ventajas competitivas. Muchos directores de inversiones y ejecutivos entienden que
la estabilidad es simplemente la base de referencia para el equipo de TI. Para estos líderes, la agilidad
empresarial es la medida de la contribución de TI a la empresa.
La Academia de las Artes y las Ciencias Cinematográficas migró sus aplicaciones web heredadas a la nube,
proporcionando nuevas aplicaciones de streaming a los miembros en una experiencia enriquecida, con
capacidad de respuesta y multiplataforma.
¿Por qué es tan importante la agilidad?

Hoy en día, los mercados cambian a un ritmo más rápido que nunca. En 2015, solo 57 empresas permanecían
en la lista Fortune 500 después de 61 años, una tasa de rotación del 88,6 %. Esto representa un cambio en el
mercado a un ritmo nunca visto hasta la fecha. Es poco probable que la agilidad de TI o incluso las agilidades
empresariales afecten a una organización incluida en la lista Fortune 500, pero estas cifras nos ayudan a
comprender el ritmo al que los mercados continúan cambiando.
Tanto en las organizaciones ya establecidas como en las compañías noveles, la agilidad empresarial puede
marcar la diferencia entre el éxito o el fracaso de una iniciativa empresarial. La adaptación rápida a los cambios
del mercado puede ayudar a conservar los clientes existentes o a arrebatar cuota de mercado a la competencia.
Los resultados relacionados con la agilidad en las secciones siguientes pueden ayudarle a comunicar el valor de
la nube durante una transformación.
Resultado del tiempo de comercialización

En el marco de los esfuerzos de innovación compatibles con la nube, el tiempo de comercialización es una
medida clave de la capacidad de TI de abordar cambios en el mercado. En muchos casos, es posible que un líder
empresarial tenga un presupuesto existente para la creación de una aplicación o el lanzamiento de un nuevo
producto. Comunicar claramente las ventajas del tiempo de comercialización puede motivar a ese líder a
reorientar el presupuesto al recorrido de transformación de TI.
Ejemplo 1: La división europea de una empresa con sede en Estados Unidos debe cumplir las normas
del reglamento general de protección de datos mediante la protección de los datos de los clientes de una
base de datos que admita operaciones en el Reino Unido. La versión existente de SQL Server no admite la
seguridad de nivel de fila necesaria. Una actualización local provocaría demasiadas interrupciones. Con
Azure SQL Database para replicar y actualizar la base de datos, el cliente agrega la medida de
cumplimiento necesaria en cuestión de semanas.
Ejemplo 2: Una empresa de logística ha descubierto un segmento sin explotar del mercado, pero
necesita una nueva versión de su aplicación estrella para captar esa cuota de mercado. Su principal
competidor también ha detectado esta situación. Mediante la ejecución de un esfuerzo de innovación de
la aplicación compatible con la nube, la compañía adoptó una estrategia de obsesión por el cliente y un
enfoque de desarrollo basado en DevOps para adelantarse x meses a su competidor más lento y
obsoleto. Este impulso de entrada en el mercado le permitió lograr la base de clientes.
Aurora Health Care
Un sistema sanitario transforma los servicios en línea en una sencilla experiencia digital. Para transformar sus
servicios digitales, Aurora Health Care migró sus sitios web a la plataforma de Microsoft Azure y adoptó una
estrategia de innovación continua.
"Como equipo, nos centramos en soluciones de alta calidad y en la rapidez. Elegir Azure fue un punto de
inflexión para nosotros".
Jamey Shiels
Vicepresidente de Experiencia digital
Aurora Health Care
Tiempo de aprovisionamiento
Cuando el negocio exige nuevos servicios de TI o escalar a servicios existentes, la adquisición y el
aprovisionamiento de nuevos recursos virtuales o de hardware pueden tardar semanas. Después de la
migración a la nube, TI puede habilitar el autoservicio de aprovisionamiento más fácilmente, lo que permite a la
empresa escalar sus servicios en horas.
Ejemplo : Una empresa de bienes de consumo envasados requiere la creación y anulación de cientos de
clústeres de bases de datos cada año para satisfacer las demandas operativas de la empresa. Los hosts
virtuales locales se pueden aprovisionar rápidamente, pero el proceso de recuperación de los recursos
virtuales es lento y ocupa un tiempo significativo del equipo. Por lo tanto, el entorno local heredado se ve
sobrecargado y apenas puede mantener el ritmo de la demanda. Después de la migración a la nube, TI puede
proporcionar más fácilmente aprovisionamiento automático de recursos con scripts, con un enfoque de
anulación para la facturación. En conjunto, esto permite a la empresa moverse tan rápidamente como sea
necesario, al tiempo que sigue asumiendo la responsabilidad del costo de los recursos que se demandan. Al
hacer esto en la nube, se limitan las implementaciones exclusivamente al presupuesto de la empresa.
Pasos siguientes
Más información sobre resultados de cobertura.
Ejemplos de resultados de alcance global
Como ya se ha tratado en los resultados empresariales, varios posibles resultados empresariales pueden servir
como base en las conversaciones con la empresa acerca del recorrido de transformación. Este artículo se centra
en una medida empresarial común: el alcance. El alcance es un término conciso que, este caso, se refiere a la
estrategia de globalización de una empresa. Conocer la estrategia de globalización de la empresa le ayudará a
articular mejor los resultados empresariales que son el objetivo del recorrido de transformación de una
empresa.
Las empresas de la lista Fortune 500 y las empresas más pequeñas se han centrado en la globalización de los
servicios y en los clientes durante más de tres décadas, y es probable que la mayoría de las empresas participen
en operaciones de comercio mundial, ya que esta globalización sigue constituyendo el foco de atención. El
hospedaje de centros de datos por todo el mundo puede consumir más del 80 por ciento de un presupuesto
anual de TI, y las redes de área extensa que usan líneas privadas para conectar esos centros de datos pueden
costar millones de dólares al año. Por lo tanto, poder realizar operaciones globales resulta complejo y costoso.
Las soluciones en la nube trasladan el costo de la globalización al proveedor de la nube. En Azure, los clientes
pueden implementar rápidamente los recursos en la misma región en la que se encuentran los clientes o las
operaciones, sin tener que comprar ni aprovisionar un centro de datos. Microsoft es propietario de una de las
redes de área extensa más grandes del mundo, que conecta centros de datos en todo el mundo. Los clientes de
todos el mundo pueden contar con conectividad y capacidad operativa global a medida que la necesiten.
Walgreens Boots Alliance (WBA) trasladó las aplicaciones locales y los recursos de TI en un entorno de Windows
y Linux heterogéneo a la nube, aprovechando el rendimiento mejorado y la centralización de los datos, y
ayudando a la empresa a ofrecer un mejor servicio al cliente.
Acceso global
Expandirse en un nuevo mercado puede ser uno de los resultados empresariales más valiosos durante una
transformación. La capacidad para implementar rápidamente los recursos en el mercado sin un compromiso a
largo plazo permite a los responsables de ventas y operaciones explorar opciones que no habrían considerado
en el pasado.
Ejemplo de fabricación
Un fabricante de cosméticos ha identificado una tendencia. Se están enviando algunos productos a la región de
Asia Pacífico, aunque no hay ningún equipo de ventas que opere en esa región. Los sistemas mínimos
requeridos por un equipo de ventas remoto son pequeños, pero la latencia impide una solución de acceso
remoto. Para aprovechar esta tendencia, el vicepresidente de ventas quiere probar con equipos de ventas en
Japón y Corea del Sur. Como la empresa ha realizado una migración a la nube, ha podido implementar los
sistemas necesarios en Japón y Corea del Sur en tan solo unos días. Esto ha permitido al vicepresidente de
ventas aumentar los ingresos de la región en un plazo de tres meses. Estos dos mercados continúan superando
a otras partes del mundo y generando operaciones de ventas en toda la región.
Ejemplo de comercio
Un distribuidor en línea que distribuya productos globalmente puede interactuar con sus clientes en distintas
zonas horarias e idiomas. El distribuidor utiliza Azure Bot Service y diversas características de Azure Cognitive
Services, como Traductor, Language Understanding (LUIS), QnA Maker y Text Analytics. Esto garantiza que sus
clientes puedan obtener la información que necesitan cuando la necesiten y en su idioma. El minorista utiliza el
servicio Personalizer para personalizar aún más la experiencia y las ofertas del catálogo para sus clientes, lo que
garantiza que se vean reflejados los gustos, las preferencias y las disponibilidades según los datos geográficos.
Soberanía de los datos

Operar en nuevos mercados presenta algunas restricciones adicionales de gobernanza. Las ofertas de Azure
cumplen las normas, lo que ayuda a los clientes a satisfacer sus obligaciones de cumplimiento en los sectores
regulados y en los mercados internacionales. Para más información, consulte Introducción al cumplimiento de
Microsoft Azure.
Ejemplo
Un proveedor de servicios públicos con sede en Estados Unidos ganó un contrato para prestar servicios
públicos en Canadá. La ley de soberanía de datos canadiense requiere que los datos canadienses permanezcan
en Canadá. Esta compañía había realizado durante años un esfuerzo de innovación en aplicaciones habilitadas
para la nube. Como resultado, su software se implementó mediante procesos de DevOps totalmente
automatizados con scripts. Con unos cambios menores en el código, pudieron implementar una copia funcional
del código en un centro de datos de Azure en Canadá, con lo que se cumplían los requisitos de soberanía de
datos y se pudo conservar el cliente.
Pasos siguientes
Más información acerca de los resultados de la involucración del usuario.
Ejemplos de resultados de la involucración del
cliente
Como se ha tratado en la información general sobre resultados empresariales, varios resultados empresariales
potenciales pueden servir como base para cualquier conversación de recorrido de transformación con la
empresa. Este artículo se centra en una medida empresarial común: la involucración del cliente. Comprender las
necesidades de los clientes y el ecosistema en torno a estos ayuda a articular los resultados empresariales que
constituyen el objetivo del recorrido de transformación de una empresa.
Durante los esfuerzos de innovación de datos habilitados para la nube, se daba por supuesta la involucración
del cliente. Las siguientes funciones son potencialmente perjudiciales y requieren un alto grado de compromiso
del cliente:
Agregación de datos
Comprobación de teorías
Avance de información
Información sobre cambio cultural
Los resultados de la involucración del cliente están todos relacionados con la satisfacción o superación de las
expectativas del cliente. Como base de la involucración, los clientes dan por supuesto que los productos y
servicios son eficientes y confiables. Si no lo son, es fácil que un ejecutivo comprenda el valor empresarial de los
resultados de rendimiento y confiabilidad. En el caso de empresas más avanzadas, la velocidad de integración
de los aprendizajes y observaciones de este proceso es un resultado empresarial fundamental.
Descartes eligió Microsoft Azure como su plataforma preferida y migró correctamente su solución Descartes
MacroPoint a Azure SQL Database para proporcionar mayor flexibilidad a los clientes y centrar los recursos
internos en la extensión del valor del producto.
Tiempo de ciclo
Durante las transformaciones que se centran en los clientes como, por ejemplo, en un esfuerzo de innovación de
aplicaciones habilitadas para la nube, los clientes responden ante una involucración directa. También aprecian la
posibilidad de ver sus necesidades rápidamente satisfechas por parte del equipo de desarrollo. El tiempo de
ciclo es un término de Six Sigma que hace referencia a la duración desde el principio hasta el final de una
función. Para los directivos de la empresa, que invierten en mejorar la involucración de los clientes, el tiempo de
ciclo puede ser un resultado empresarial muy deseable.
Ejemplo :
Una empresa de servicios que proporciona servicios de negocio a negocio está intentando mantener la cuota de
mercado en un mercado competitivo. Los clientes que han abandonado la empresa por un proveedor de
servicios de la competencia han afirmado que su solución técnica es demasiado compleja e interfiere con sus
procesos empresariales y este es el principal motivo de su marcha. En este caso, el tiempo de ciclo es
fundamental.
En la actualidad, una característica tarda 12 meses en pasar de ser una solicitud a su lanzamiento. Si el equipo
directivo le da prioridad, ese ciclo se puede reducir a seis o nueve meses. Mediante un esfuerzo de innovación
de aplicaciones habilitadas para la nube, modelos de aplicaciones nativas en la nube y la integración de Azure
DevOps, el equipo puede reducir el tiempo de ciclo a un mes. Esto permite a los equipos empresariales y de
desarrollo de aplicaciones interactuar más directamente con los clientes.
Centro de contacto inteligente

La satisfacción y la experiencia del cliente son el núcleo de las organizaciones con éxito. Desocupar a los
empleados para que se concentren en mejorar el servicio de atención al cliente puede influir en gran medida a
la hora de fidelizar a los clientes. Con la tecnología de la inteligencia artificial disponible hoy en día, muchos de
los pasos durante una llamada de un cliente se pueden automatizar, lo que permite que el agente del centro de
contacto tenga más tiempo para centrarse en ofrecer un servicio de atención al cliente superior.
Ejemplo :
Una compañía de seguros ha implementado agentes digitales para responder rápidamente a las solicitudes de
los clientes. Estos agentes digitales están disponibles en el sitio web y la aplicación móvil de la empresa
mediante la creación de una solución Azure Bot Service. Al llevar la experiencia de un servicio de atención al
cliente mejorado a su centro de contacto, la compañía de seguros implementó la transcripción de llamadas en
directo, el análisis de sentimiento y la detección de frases clave. Todo esto ayuda al agente del centro de contacto
con los pasos recomendados y el procesamiento de formularios. Esto llevó a la reducción de la repetición de
llamadas del cliente al centro de contacto y permitió que el agente se centrara más en proporcionar una
experiencia excelente al cliente.
Pasos siguientes
Más información acerca de los resultados del rendimiento.
Ejemplos de resultados de rendimiento
Como ya se ha tratado en los resultados empresariales, varios posibles resultados empresariales pueden servir
como base en las conversaciones con la empresa acerca del recorrido de transformación. Este artículo se centra
en una medida empresarial común: el rendimiento.
En la sociedad tecnológica de hoy en día, los clientes asumen que las aplicaciones van a funcionar bien y
siempre van a estar disponibles. Cuando no se cumple esta expectativa, se produce un daño en la reputación
que puede ser costoso y duradero.
GE Aviation's Digital Group implementó Microsoft Azure Digital Twins y otros recursos de Azure para ingerir y
modelar los datos de varios orígenes, lo que permitió crear una vista de aeronaves digital completa con
trazabilidad digital integrada de componentes individuales que ayuda a los clientes a fomentar una mayor
eficiencia del combustible, reducir los costos de mantenimiento e impulsar la preparación de vuelos de sus
flotas.
Rendimiento
Los mayores servicios informáticos en la nube se ejecutan en una red mundial de centros de datos seguros que
se actualizan periódicamente a la última generación de hardware informático rápido y eficiente. Esto
proporciona varias ventajas en comparación con un único centro de datos corporativo, como una latencia de red
menor para las aplicaciones y mayores economías de escala.
Transforme el negocio y reduzca costos con una infraestructura de bajo consumo que abarca más de 100
instalaciones de alta seguridad en todo el mundo unidas por una de las mayores redes del planeta. Azure cuenta
con más regiones globales que cualquier otro proveedor de nube. Esto se traduce en la escala necesaria para
acercar las aplicaciones a usuarios de todo el mundo, mantener la residencia de los datos y ofrecer a los clientes
opciones completas de cumplimiento normativo y resistencia.
Ejemplo 1: una empresa de servicios trabajaba con un proveedor de hospedaje que hospedaba varios
recursos de infraestructura operativa. Esos sistemas experimentaban interrupciones frecuentes y un
rendimiento deficiente. La empresa migró sus recursos a Azure para aprovechar el contrato de nivel de
servicio y los controles de rendimiento de la nube. Cualquier tiempo de inactividad costaría a la empresa
unos 15 000 USD por minuto de interrupción. Con una interrupción de entre cuatro y ocho horas al mes,
resultó fácil justificar esta transformación organizativa.
Ejemplo 2: una empresa de inversión de consumo se encontraba en las primeras fases de un esfuerzo
de innovación de aplicaciones habilitadas para la nube. Los procesos de Agile y DevOps estaban
madurando correctamente, pero el rendimiento de las aplicaciones tenía picos. Como una transformación
más madura, la empresa inició un programa para supervisar y automatizar el tamaño en función de las
demandas de uso. La empresa eliminó los problemas de tamaño mediante las herramientas de
administración del rendimiento de Azure, lo que dio lugar a un sorprendente aumento del 5 % en las
transacciones.
Confiabilidad
La informática en la nube facilita y abarata la creación de copias de seguridad de los datos, la recuperación ante
desastres y la continuidad empresarial, ya que los datos se pueden reflejar en varios sitios redundantes en la red
del proveedor de nube.
Una de las funciones vitales de TI es garantizar que los datos corporativos nunca se pierdan y que las
aplicaciones estén disponibles a pesar de los bloqueos de servidor, las interrupciones del suministro eléctrico o
los desastres naturales. Puede mantener los datos seguros y recuperables si realiza copias de seguridad de ellos
en Azure.
Azure Backup es una solución sencilla que reduce los costos de infraestructura a la vez que proporciona
mecanismos de seguridad mejorados para proteger los datos frente al ransomware. Con una solución, puede
proteger las cargas de trabajo que se ejecutan en Azure y el entorno local en Linux, Windows, VMware e Hyper-
V. Puede garantizar la continuidad empresarial al mantener las aplicaciones en ejecución en Azure.
Azure Site Recovery facilita la prueba de la recuperación ante desastres mediante la replicación de aplicaciones
entre regiones de Azure. También puede replicar máquinas virtuales locales de VMware e Hyper-V y servidores
físicos en Azure para que estén disponibles si el sitio principal deja de funcionar. Además, puede recuperar las
cargas de trabajo en el sitio principal una vez que vuelva a estar en funcionamiento.
Ejemplo : una empresa petrolífera usaba tecnologías de Azure para implementar una recuperación del sitio
completa. La empresa decidió no adoptar totalmente la nube para las operaciones cotidianas, pero las
características de recuperación ante desastres y continuidad empresarial (BCDR) de la nube seguían
protegiendo el centro de datos. Cuando se formó un huracán a cientos de kilómetros de distancia, su
asociado de implementación comenzó a recuperar el sitio en Azure. Antes de que el huracán tocara tierra,
todos los recursos críticos se ejecutaron en Azure, lo que evitó el tiempo de inactividad.
Pasos siguientes
Aprenda a usar la plantilla de resultados empresariales.
Usar la plantilla de resultados empresariales
Resultados de sostenibilidad y ventajas para
empresas
Aunque el impacto y las ventajas de la nube se han medido tradicionalmente con métricas financieras y de
eficiencia, es más común para los clientes buscar información sobre cómo la nube puede ayudarlos a lograr sus
objetivos medioambientales y de sostenibilidad. La informática en la nube puede ayudar a su organización a
reducir las emisiones de carbono, a usar los recursos de manera más eficiente y a reducir la huella
medioambiental.
Vea el siguiente vídeo para más información sobre sostenibilidad y cómo la migración a la nube abre la puerta a
soluciones sostenibles que son buenas para el planeta y para su empresa.
Microsoft ha sido líder en muchas de estas áreas. La compañía lleva a cabo sus operaciones con una emisión de
carbono neutra desde 2012. Para 2030 se ha comprometido a tener huella de carbono negativa. The carbon
benefits of cloud computing (Beneficios para las emisiones de carbono de la informática en la nube) es un
estudio sobre la nube de Microsoft en colaboración con WSP, que apoya la investigación sobre la reducción
potencial de las huellas de carbono que puede suponer el traslado de los centros de trabajo locales a la nube de
Microsoft.
La plataforma de IoT de Bühler Group, conocida como Bühler Insights y con la tecnología de Azure IoT Hub,
genera datos esenciales para que los clientes puedan supervisar el rendimiento de la máquina y generar
registros precisos para cada lote de productos, ayudando a los productores de alimentos a optimizar la
seguridad, la sostenibilidad y la transparencia en la cadena de suministro.
Recorrido de sostenibilidad de Microsoft

El recorrido de Microsoft comenzó hace más de una década, cuando la compañía empezó a aplicar nuevas
prácticas empresariales y a adoptar tecnología de nube. En 2009, sus emisiones de carbono se habían reducido
un 30 %. Desde entonces, Microsoft ha realizado grandes progresos con nuevas inversiones para reducir la
huella de carbono de la compañía. Microsoft se ha centrado en estas cuatro áreas:
Carbono: reducir el consumo de energía en las oficinas corporativas, cobrar impuestos por emisiones de
carbono a las divisiones empresariales y utilizar tecnología basada en la nube para reducir las emisiones.
Ecosistema: adquirir un compromiso con los centros de trabajo ecológicos y adquirir 1100 millones de
kilovatios/hora de energía verde.
Agua: reducir la intensidad del consumo e invertir en tecnología de gestión del agua.
Residuos: practicar el aprovisionamiento, el reciclaje y la eliminación responsables; usar software y
tecnología para que los edificios sean más eficientes.
Obtenga más información sobre cómo el compromiso con un desafío a la medida del planeta de Microsoft nos
ha ayudado a planear y alcanzar los objetivos de sostenibilidad.
Ejemplos de resultados de sostenibilidad

Centrarse en la sostenibilidad y proteger los recursos medioambientales limitados es clave para nuestro futuro,
y este enfoque también se beneficia a la empresa. En la actualidad, las empresas pueden utilizar una amplia
gama de activos y recursos, que pueden facilitar su expansión a nuevas áreas geográficas y ayudarlas a
desarrollar soluciones de administración de recursos innovadoras.
AGL, una de las principales compañías energéticas integradas de Australia, ha creado una solución en Azure que
administra de forma remota las baterías solares en red. Descubra sobre cómo la compañía está desarrollando
una innovadora asociación energética en Australia para ayudar a los clientes locales a enviar energía a la red
eléctrica.
Bee'ah es una compañía pionera en sostenibilidad en Oriente Medio, que cree en la tecnología y la
sostenibilidad para crear soluciones para el futuro. Sus servicios incluyen gestión de residuos, consultoría
medioambiental, energía renovable y transporte sostenible. Azure ha ayudado a la compañía a lanzar la primera
plataforma de inteligencia artificial para digitalizar el conjunto de operaciones y servicios. Obtenga más
información sobre cómo la nube impulsa la gestión sostenible y la innovación digital a lo largo del recorrido de
sostenibilidad de la compañía.
Las historias de estos clientes demuestran que priorizar las soluciones de sostenibilidad y medioambientales
puede ayudar a las organizaciones a crear nuevas oportunidades de negocio.
Pasos siguientes
Un enfoque intencional puede ayudar a las organizaciones a seguir su recorrido de sostenibilidad. Estos cuatro
pasos pueden influir en los resultados de su compañía:
Paso 1: Registre y comprenda las emisiones de carbono de su compañía. Empiece por categorizar las
emisiones, lo que le ayudará a elaborar una lista de las áreas en las que debe centrarse. La calculadora de
sostenibilidad de Microsoft puede ayudarlo con esta tarea.
Paso 2: Evalúe si los distribuidores, asociados y proveedores están llevando a cabo pasos para reducir sus
emisiones, y si estos pasos se alinean con los suyos.
Paso 3: Cree un incentivo para que los equipos reduzcan las emisiones de carbono. La guía The Microsoft
carbon fee: theory and practice (Tarifa de carbono de Microsoft: teoría y práctica) pueden ayudar a su
organización a impulsar la alineación y responsabilidad en los equipos.
Paso 4: Busque equipos en nuestra empresa para contratar su soporte técnico y generar ideas sobre áreas de
mejora. Cree una cultura de innovación en la que los usuarios sean participantes con un sentido de propiedad.
Obtenga más información sobre cómo su organización puede medir y alcanzar resultados de sostenibilidad con
la nube.
Como se ha visto en la información general sobre resultados empresariales, puede ser difícil salvar la brecha
entre las conversaciones empresariales y técnicas. Esta sencilla plantilla está diseñada para ayudar a los equipos
a capturar de manera uniforme los resultados empresariales que se van a usar más adelante en el desarrollo de
estrategias del recorrido de transformación del cliente.
Descargue la plantilla de resultados empresariales para comenzar con la lluvia de ideas y el seguimiento de los
resultados empresariales. Siga leyendo para obtener información sobre el empleo de la plantilla. Revise la
sección de resultados empresariales para obtener ideas sobre posibles resultados empresariales que podrían
surgir en las conversaciones ejecutivas.

En esta plantilla, los resultados empresariales se centran en tres temas:
Alineación con las partes interesadas o los responsables de la toma de decisiones empresariales
Descripción de los impulsores y los objetivos empresariales
Asignación de resultados a soluciones específicas y funcionalidad técnica
Figura 1: Resultados empresariales visualizados como una casa con las partes interesadas, sobre los resultados
empresariales y sobre las capacidades técnicas.
La plantilla de resultados empresariales se centra en conversaciones simplificadas que pueden entablar
rápidamente las partes interesadas sin profundizar demasiado en la solución técnica. Al comprender y alinear
rápidamente los indicadores clave de rendimiento (KPI) y los impulsores del negocio que son importantes para
las partes interesadas, el equipo puede pensar en enfoques y transformaciones generales antes de profundizar
en los detalles de implementación.
Puede encontrar un ejemplo en la pestaña "Example Outcome" de la hoja de cálculo, como se muestra a
continuación. Para realizar el seguimiento de varios resultados, agréguelos a la pestaña "Collective Outcomes".
Figura 2: Ejemplo de una plantilla de resultados empresariales.
¿Por qué es relevante esta plantilla?

La detección es un principio fundamental de la arquitectura empresarial. Si la detección se limita a la detección
técnica, es probable que la solución pierda muchas oportunidades de mejorar el negocio. Los arquitectos
empresariales, los arquitectos de soluciones y otros líderes técnicos pueden dominar el proceso de detección
mediante esta plantilla. En los procesos de detección eficaces, estos líderes consideran cinco aspectos clave del
resultado empresarial antes de comenzar un recorrido de transformación, como se muestra en la siguiente
imagen:
Figura 3: Cinco áreas de interés en la detección: las partes interesadas, los resultados, los controladores, los KPI y
las capacidades.
Par tes interesadas: qué personas de la organización es probable que obtengan el máximo valor de un
resultado empresarial específico. Qué personas es más probable que apoyen esta transformación, sobre todo
cuando las cosas se pongan difíciles o lleven mucho tiempo. A qué personas se atribuye el éxito de esta
transformación. Estas personas son partes interesadas potenciales.
Resultados empresariales: un resultado empresarial es un resultado conciso, definido y perceptible o un
cambio en el rendimiento empresarial respaldado por una medida específica. ¿Cómo quiere la parte interesada
cambiar la empresa? ¿Cómo se va a ver afectada la empresa? ¿Cuál es el valor de esta transformación?
Impulsores del negocio: los impulsores del negocio capturan el desafío actual que evita que la empresa logre
los resultados deseados. También pueden captar nuevas oportunidades que la empresa puede aprovechar con
la solución adecuada. ¿Cómo describiría los desafíos actuales o el estado futuro de la empresa? ¿Qué funciones
empresariales cambiaría para lograr los resultados deseados?
KPI: ¿cómo se va a medir este cambio? ¿Cómo sabe la empresa si son correctos? ¿Con qué frecuencia se va a
observar este KPI? La comprensión de cada KPI ayuda a habilitar el cambio incremental y la experimentación.
Funcionalidades: al definir un recorrido de transformación, ¿cómo van a acelerar las funcionalidades técnicas
la consecución del resultado empresarial? ¿Qué aplicaciones deben incluirse en la transformación para lograr
objetivos empresariales? ¿Cómo se clasifican por orden de prioridad las distintas aplicaciones o cargas de
trabajo para ofrecer funcionalidades? ¿Cómo deben expandirse o rediseñarse las partes de la solución para
lograr cada uno de los resultados? ¿Se pueden reorganizar los enfoques de ejecución (o las escalas de tiempo)
para clasificar los resultados empresariales de alto impacto?
Pasos siguientes
Aprenda a alinear el esfuerzo técnico con métricas de aprendizaje significativas.
Alinear el esfuerzo técnico con métricas de aprendizaje
¿Cómo podemos alinear el trabajo con métricas de
aprendizaje significativas?
En la información general sobre resultados empresariales se analizaron formas de medir y comunicar cómo
afectará una transformación a la empresa. Desafortunadamente, pueden pasar años antes de que algunos de
esos resultados produzcan resultados mensurables. La junta y los ejecutivos de máximo rango están
descontentos con los informes que muestran una diferencia del 0 % durante largos períodos de tiempo.
Las métricas de aprendizaje son métricas provisionales a más corto plazo que se pueden asociar a resultados
empresariales a largo plazo. Estas métricas se alinean bien con una mentalidad de crecimiento y contribuyen a
posicionar la cultura para que sea más resistente. En lugar de destacar la falta de progreso prevista para la
consecución de un objetivo empresarial a largo plazo, las métricas de aprendizaje resaltan los primeros
indicadores de éxito. Las métricas también resaltan los indicadores iniciales de error, que probablemente
proporcionen la mejor oportunidad de aprender y ajustar el plan.
Como en muchos de los materiales de este marco, se supone que está familiarizado con el recorrido de
transformación que mejor se adapta a los resultados empresariales esperados. En este artículo se describen
algunas métricas de aprendizaje para cada recorrido de transformación a fin de ilustrar el concepto.
Migración a la nube
Esta transformación se centra en el costo, la complejidad y la eficacia, con énfasis en las operaciones de TI. Los
datos más fáciles de medir detrás de esta transformación son los del traslado de recursos a la nube. En este tipo
de transformación, el patrimonio digital se mide en máquinas virtuales (VM), bastidores o clústeres que
hospedan esas máquinas virtuales, costos operativos del centro de datos, gastos de capital necesarios para
mantener los sistemas y amortización de dichos recursos a lo largo del tiempo.
A medida que las máquinas virtuales se trasladan a la nube, se reduce la dependencia de los recursos heredados
locales. También se reduce el costo del mantenimiento de recursos. Desafortunadamente, las empresas no
pueden materializar la reducción de costos hasta que los clústeres se desaprovisionan y las concesiones de
centros de datos expiran. En muchos casos, el valor completo del trabajo no se materializa hasta que se
completan los ciclos de amortización.
Póngase siempre de acuerdo con el director financiero o el departamento de finanzas antes de crear informes
financieros. Aunque los equipos de TI generalmente pueden calcular los valores de costo monetario actual y de
costo monetario futuro para cada máquina virtual en función del consumo de CPU, memoria y almacenamiento.
Luego puede aplicarse ese valor a cada máquina virtual migrada para estimar el ahorro de costos inmediato y el
valor monetario futuro del trabajo.
Innovación en las aplicaciones

La innovación en las aplicaciones habilitadas para la nube se centra en gran medida en la experiencia del cliente
y en su disposición para consumir productos y servicios ofrecidos por la empresa. Se tarda cierto tiempo para
que los incrementos de cambio afecten a los comportamientos de compra del consumidor o del cliente. Pero los
ciclos de innovación de las aplicaciones suelen ser mucho más cortos que en otras formas de transformación. El
consejo tradicional es que se debe empezar por la comprensión de los comportamientos específicos en los que
quiere influir y usar esos comportamientos como métricas de aprendizaje. Por ejemplo, en una aplicación de
comercio electrónico, las compras totales o las compras de complementos podrían ser el comportamiento de
destino. En el caso de una empresa de vídeo, el tiempo durante el que se ven las secuencias de vídeo podría ser
el objetivo.
Las métricas de comportamiento del cliente pueden verse afectadas fácilmente por las variables externas, por lo
que a menudo es importante incluir estadísticas relacionadas con las métricas de aprendizaje. Entre las
estadísticas relacionadas se puede incluir la cadencia de las versiones, los errores resueltos por versión, la
cobertura de código de pruebas unitarias, el número de vistas de página, el rendimiento de páginas, el tiempo
de carga de página y otras métricas de rendimiento de aplicaciones. Cada una de ellas puede mostrar diferentes
actividades y cambios en la base de código y la experiencia del cliente que se correlacionan con patrones de
comportamiento del cliente de nivel superior.
Innovación en los datos

Puede tardarse años en cambiar un sector, transformar radicalmente los mercados o transformar productos o
servicios. En un trabajo de innovación de datos habilitado para la nube, la experimentación es la clave para
medir el éxito. Sea transparente compartiendo métricas de predicción, como la probabilidad porcentual, el
número de experimentos con errores y la cantidad de modelos entrenados. Los errores se acumularán con
mayor rapidez que los éxitos. Estas mediciones pueden ser desalentadoras y es importante que el equipo
ejecutivo comprenda el tiempo y la inversión que se requieren para utilizar los datos adecuadamente.
Por otro lado, algunos indicadores positivos suelen estar asociados al aprendizaje controlado por datos:
centralización de conjuntos de datos heterogéneos, entrada de datos y democratización de los datos. Mientras el
equipo aprende sobre el cliente del mañana, se pueden generar resultados reales hoy mismo. Entre las métricas
de aprendizaje de apoyo se podrían incluir:
Número de modelos disponibles.
Número de orígenes de datos de asociados consumidos.
Dispositivos que producen datos de entrada.
Volumen de datos de entrada.
Tipos de datos.
Una métrica aún más valiosa es el número de paneles creados a partir de orígenes de datos combinados. Este
número refleja los procesos empresariales de estado actual que se ven afectados por los nuevos orígenes de
datos. Al compartir nuevos orígenes de datos abiertamente, su empresa puede aprovechar los datos mediante
herramientas de informes como Power BI para generar información incremental e impulsar el cambio
empresarial.
Pasos siguientes
Una vez alineadas las métricas de aprendizaje, está listo para empezar a crear la justificación económica que
debe proporcionar para hacer frente a esas métricas.
Creación de la justificación económica de la nube
Medición de los resultados empresariales mediante
objetivos y resultados clave (OKR)
Las operaciones modernas requieren maneras modernas de medir los resultados empresariales, y la tecnología
de la nube puede ayudar a aumentar la velocidad de una empresa. La plataforma de medición de una
organización debe respaldar los resultados y el plan de crecimiento de una empresa mediante las acciones
siguientes:
Proporcionar información a los grupos y miembros del equipo.
Respaldar la dinamización rápida del personal cuando los resultados no se alinean con la estrategia y las
expectativas.
Ofrecer un formato estructurado, plantillas, secuencias y herramientas para ayudar a los equipos a planear y
visualizar un aumento de la velocidad.
Información general de los objetivos y los resultados clave (OKR)

Muchas organizaciones han empezado a adoptar objetivos y resultados clave (OKR). Se ha demostrado que los
OKR impulsan la alineación en entornos de trabajo complejos, fomentan la innovación y ayudan a los usuarios a
centrarse en lo que importa. Los dos componentes que comprenden los OKR son un objetivo y los resultados
clave de ese objetivo. Un objetivo es la declaración de intenciones: ¿Qué intenta conseguir el equipo y por qué
es importante? Los resultados clave son resultados específicos que realizan un seguimiento del impacto en el
objetivo.
Objetivo: claridad y intención.
Resultados clave: medidas de éxito dentro de un trimestre.
Es importante comprender que los OKR son útiles para medir los resultados del equipo frente al rendimiento
individual. Dado que las fechas límite a menudo motivan el rendimiento del equipo, los resultados clave se
establecen trimestralmente. Los OKR ayudan a los equipos a centrarse en las tareas más importantes en lugar
de en el volumen del trabajo que tienen entre manos.
Para ello, céntrese en lo que ocurre en un mes, un trimestre y otros intervalos a corto plazo. Puede tener OKR
que duren más tiempo, pero los intervalos más cortos resaltan la necesidad de OKR que realicen un
seguimiento del impacto a corto plazo.
Principios fundamentales de los OKR

WorkBoard es una empresa que se centra únicamente en los OKR y que ofrece soluciones de software para
ayudar a los clientes a adoptarlos. Según la empresa, los principios fundamentales de los OKR son los
siguientes:
Aspirar e inspirar : los equipos establecen los mejores resultados posibles de un trimestre
determinado, centran los esfuerzos en obtener unos excelentes resultados y usan las retrospectivas para
el aprendizaje y la iteración.
Enfoque de los resultados: los resultados clave trimestrales proporcionan claridad sobre dónde se
crea el valor. Esto ayuda a los equipos y a la organización a impulsar los impactos empresariales con
mayor rapidez.
Enfoque global y local: los equipos localizan los OKR en sus nombres, verbos y números, que
enriquecen los OKR con la experiencia e información del equipo.
Transparencia: Los OKR, la alienación y el progreso son visibles para todos los usuarios con software
OKR, lo que simplifica la colaboración y permite tomar buenas decisiones con mayor rapidez.
Cómo aportan valor los OKR a una organización

Los OKR ayudan a impulsar la alineación y la responsabilidad en las organizaciones.
Figura 1: Cómo mejoran la alineación y la responsabilidad los OKR en las organizaciones para ayudarlas a
cumplir los objetivos con mayor rapidez.
Obtenga más información sobre cómo su equipo puede alinear la estrategia y la ejecución durante las fases de
planeación y ejecución.
Ejemplos de OKR
Los principios definidos por WorkBoard pueden ayudar a su organización a comprender la utilidad los OKR. Los
objetivos deben inspirar a su empresa y a sus equipos para comprender completamente su misión. Los
resultados clave deben ser específicos y medibles dentro del trimestre.
A continuación, se incluyen algunos ejemplos de OKR:
Objetivo 1: ser el principal proveedor estadounidense de plataformas de aprendizaje para escuelas.
Resultados clave:
1. Un 45 % de las escuelas de primaria y secundaria utilizan nuestra plataforma.
2. Un aumento del 12 % en la participación de los alumnos, medido a través de sistemas internos.
3. Una tasa de satisfacción del 95 % en las encuestas de padres trimestrales.
Objetivo 2: crear una plataforma tecnológica que ayude a todas las personas de nuestra empresa a innovar y
crear.
Resultados clave:
1. Cinco aplicaciones nuevas desarrolladas y adoptadas en toda la organización.
2. Cada equipo con al menos dos miembros que usan Microsoft Power Platform.
3. Incluye nuevas tecnologías de nube, como las de análisis de datos y aprendizaje automático, en todas las
aplicaciones orientadas al cliente.
Objetivo 3: Transformar el enfoque de orientado a ventas a orientado a datos.
Resultados clave:
1. Aumento de la cobertura de la canalización del 50 % al 200 %.
2. Aumento de un 5 % de las tasas de cierre de contratos de ventas.
3. Reducción de un 8 % del tiempo de cierre de ofertas.
Pasos siguientes
Cinco pasos pueden ayudar a su organización a adoptar los OKR:
Paso 1: Aprendizaje. Empiece a explorar lo que los OKR pueden hacer para su negocio, y póngase en contacto
con colegas y líderes del sector para averiguar los beneficios que los OKR han proporcionado a sus
organizaciones.
Paso 2: Planeamiento. Cuando empiece a elaborar el borrador de su OKR, asegúrese de que los
patrocinadores participen y se impliquen en el proceso. Trabaje con un asesor de OKR para ajustar sus OKR.
Paso 3: Lanzamiento. Cada organización lanza las iniciativas de manera diferente. Mantenga un plan de
comunicación sólido, e integre el proceso de calibración y celebración de OKR en su modelo operativo.
Paso 4: Impulso. Para mantener el rigor y el enfoque, asegúrese de compartir los resultados en toda la
organización. Esto ayudará a los equipos a adoptar el hábito de usar los OKR.
Paso 5: Mejora. Siga mejorando, vuelva a realizar consultas y vuelva a plantearse cómo expandir la conexión a
toda la organización. Los OKR en hojas de cálculo pueden ser útiles, pero una organización puede obtener los
máximos beneficios de la participación de todos los usuarios para cumplir los objetivos y obtener información
de los datos alineados.
Póngase en contacto con WorkBoard para empezar.
Alinear esfuerzos con métricas de aprendizaje
Compilación de una justificación comercial para la
migración a la nube
Las migraciones a la nube pueden generar una rápida rentabilidad de la inversión (ROI) por los esfuerzos de
transformación en la nube. Sin embargo, desarrollar una justificación empresarial clara con costos y
rendimientos pertinentes y tangibles puede ser un proceso complejo. Este artículo le ayudará a pensar en qué
datos son necesarios para crear un modelo financiero que se alinee con los resultados de la migración a la nube.
En primer lugar, vamos a destruir unos cuantos mitos sobre la migración a la nube, de forma que su
organización pueda evitar cometer algunos errores comunes.
Acabar con los mitos de la migración a la nube

Mito: la nube es siempre más barata
Es una creencia común que tener un centro de datos en la nube es más barato que operarlo en el entorno local.
Aunque generalmente esta suposición puede ser cierta, no siempre es el caso. A veces, los costos operativos en
la nube son superiores. Estos costos más altos suelen deberse a un deficiente control de los costos, a
arquitecturas de sistema desajustadas, a la duplicación de procesos, a configuraciones de sistema atípicas o a
costos de personal más elevados. Afortunadamente, puede mitigar muchos de estos problemas para crear una
rentabilidad de la inversión temprana. Siga las instrucciones que se indican en Crear la justificación empresarial,
que le ayudarán a detectar y evitar estos desajustes. También puede ayudarle la información que aquí se
describe sobre cómo acabar con los otros mitos.
Mito: todo debe introducirse en la nube
De hecho, es posible que algunos impulsores del negocio le lleven a elegir una solución híbrida. Antes de
finalizar un modelo de negocio, es aconsejable realizar una primera ronda de análisis cuantitativo, como se
describe en los artículos sobre el patrimonio digital. Para más información sobre los factores cuantitativos
individuales implicados en la racionalización, consulte Las cinco "R" de la racionalización. En cualquiera de los
enfoques se usarán datos de inventario obtenidos fácilmente y un breve análisis cuantitativo para identificar
cargas de trabajo o aplicaciones que podrían dar lugar a costos más elevados en la nube. Estos enfoques
podrían identificar también dependencias o patrones de tráfico que necesitarían una solución híbrida.
Mito: crear un reflejo de mi entorno local me ayuda a ahorrar dinero en la nube
Durante el planeamiento del patrimonio digital, no es algo insólito que los clientes detecten capacidad sin usar
por encima del 50 % del entorno aprovisionado. Si se aprovisionan recursos en la nube para que coincidan con
el aprovisionamiento actual, será difícil que haya ahorros en los costos. Considere la posibilidad de reducir el
tamaño de los recursos implementados para que se alineen con los patrones de uso, en lugar de con los
patrones de aprovisionamiento.
Mito: en la migración a la nube, los costos del servidor controlan los casos empresariales
A veces, esta suposición es verdadera. Para algunas compañías, es importante reducir los gastos de capital
constantes relacionados con los servidores. Sin embargo, esto depende de varios factores. No es probable que
las compañías con un ciclo de actualización de hardware de entre cinco y ocho años encuentren rendimientos
rápidos en su migración a la nube. Las compañías con ciclos de actualización estandarizados o impuestos
pueden puedan llegar a un umbral de rentabilidad rápidamente. En cualquier caso, otros gastos pueden ser los
desencadenadores financieros que justifiquen la migración. Aquí se incluyen algunos ejemplos de los costos que
normalmente se pasan por alto cuando las compañías adoptan una visión de los costos basada únicamente en
el servidor o en la máquina virtual:
Los costos de software de virtualización, servidores y middleware pueden ser amplios. Los proveedores de
nube eliminan algunos de estos costos. Dos ejemplos de un proveedor de nube que reduce los costos de
virtualización son los programas Ventaja híbrida de Azure y Azure Reservations.
Las pérdidas empresariales debidas a interrupciones pueden superar rápidamente los costos de hardware o
software. Si su centro de datos actual es inestable, trabaje con la empresa para cuantificar el impacto de las
interrupciones en términos de costos de oportunidad o costos empresariales reales.
Los costos del entorno también pueden ser considerables. Para una familia estadounidense media, su casa es
la inversión más grande y el costo más alto en su presupuesto. Con frecuencia, lo mismo puede decirse de
los centros de datos. Los costos de bienes inmuebles, instalaciones y servicios públicos representan una
buena parte de los costos locales. Cuando se retiran los centros de datos, se pueden reutilizar esas
instalaciones, o la empresa podría quedar liberada de los costos completamente.
Mito: el modelo de gastos operativos es mejor que el modelo de gastos de capital
Como se explica en el artículo sobre los resultados fiscales, el modelo de gastos operativos puede ser una buena
opción. No obstante, algunos sectores ven los gastos operativos de forma negativa. Los siguientes son algunos
ejemplos que desencadenarían una integración más fuerte con las unidades de contabilidad y negocio respecto
al debate de gastos operativos:
Cuando una empresa considera los activos fijos como un factor para la valoración del negocio, las
reducciones de gastos de capital podrían ser un resultado negativo. Aunque no es un estándar universal, esta
opinión se observa con más frecuencia en los sectores del comercio minorista, fabricación y construcción.
Las empresas propiedad de capital privado o que buscan una afluencia de capitales podrían considerar los
aumentos de gastos operativos como un resultado negativo.
Si una empresa se centra principalmente en mejorar los márgenes de ventas o reducir el costo de bienes
vendidos (COGS), los gastos operativos podrían ser un resultado negativo.
Es más probable que las empresas consideren los gastos operativos como más favorables que los gastos de
capital. Por ejemplo, este enfoque pueden adoptarlo también las empresas que intentan mejorar el flujo de
efectivo, reducir las inversiones de capital o disminuir las tenencias de activos.
Antes de proporcionar una justificación empresarial centrada en una conversión de gastos de capital a gastos
operativos, sepa qué es lo mejor para su empresa. Contabilidad y compras pueden con frecuencia ayudar a
alinear el mensaje con los objetivos financieros.
Mito: pasar a la nube es como darle a un botón
Las migraciones son una transformación técnica manualmente intensa. Al desarrollar una justificación
empresarial, en especial justificaciones que dependen del tiempo, tenga en cuenta los siguientes aspectos que
podrían aumentar el tiempo necesario para migrar los recursos:
Limitaciones de ancho de banda: la cantidad de ancho de banda entre el centro de datos actual y el
proveedor de nube determinará las escalas de tiempo durante la migración.
Plazos de pruebas: probar las aplicaciones con la empresa para garantizar la preparación y el rendimiento
puede llevar mucho tiempo. Es fundamental alinear los usuarios avanzados y los procesos de prueba.
Plazos de migración: la cantidad de tiempo y esfuerzo necesarios para implementar la migración puede
aumentar los costos y provocar retrasos. La asignación de empleados o partes contratantes también puede
retrasar el proceso. El plan debe tener en cuenta estas asignaciones.
Impedimentos técnicos y culturales pueden ralentizar la adopción de la nube. Cuando el tiempo es un aspecto
importante de la justificación empresarial, la mejor solución de mitigación es el planeamiento adecuado.
Durante el planeamiento, dos enfoques pueden ayudar a mitigar los riesgos para los plazos:
Invierta tiempo y energía en comprender las restricciones de la adopción técnica. Aunque la presión para
realizar la transición rápidamente puede ser alta, es importante considerar plazos realistas.
Si surgen impedimentos culturales o relacionados con las personas, su efecto será más grave que las
restricciones técnicas. La adopción de la nube crea cambios, que producen la transformación deseada. Por
desgracia, a veces las personas temen el cambio y pueden necesitar apoyo adicional para alinearse con el
plan. Identifique las personas claves del equipo que se oponen al cambio y consiga su adhesión desde el
principio.
Para aumentar la buena disposición y reducir los riesgos para los plazos, prepare a las partes interesadas para
conseguir una fuerte alineación del valor y los resultados empresariales. Ayude a esas partes interesadas a
comprender los cambios que acompañan a la transformación. Sea claro y establezca expectativas realistas desde
el principio. Cuando las personas o las tecnologías ralenticen el proceso, será más fácil conseguir el apoyo
ejecutivo.
Crear la justificación empresarial

El proceso siguiente define un enfoque para desarrollar la justificación empresarial para las migraciones a la
nube. Para más información sobre los cálculos y los términos financieros, consulte el artículo sobre modelos
financieros.
En términos generales, la fórmula de justificación empresarial es sencilla. Sin embargo, los puntos de datos
sutiles necesarios para rellenar la fórmula pueden ser difíciles de alinear. En general, la justificación empresarial
se centra en la rentabilidad de la inversión (ROI) asociada con el cambio técnico propuesto. La fórmula genérica
de la ROI es:
Podemos desempaquetar esta ecuación para obtener una vista de las fórmulas específica de la migración para
las variables de entrada por el lado adecuado de esta ecuación. En el resto de las secciones de este artículo se
ofrecen algunos aspectos que se deben tener en cuenta.
Inversión inicial específica de la migración

Los proveedores de nube ofrecen calculadoras para estimar las inversiones en la nube. Microsoft
proporciona la calculadora de precios de Azure.
Algunos proveedores de nube también ofrecen calculadoras de costo diferencial. Microsoft proporciona la
calculadora de costo total de propiedad (TCO) de Azure.
Para estructuras de costo más refinadas, considere un ejercicio de planeamiento del patrimonio digital.
Estime el costo de la migración.
Estime el costo de las oportunidades de aprendizaje esperadas. Microsoft Learn puede ayudarle a reducir
esos costos.
En algunas compañías, puede ser necesario incluir en los costos iniciales el tiempo invertido por los
miembros del personal existentes. Para más información, consulte con la administración de hacienda.
Valide con ellos los costos adicionales o costos de cargas.
Ingresos diferenciales específicos de la migración

Con frecuencia, los estrategas pasan este aspecto por alto al crear una justificación empresarial para la
migración. En algunas áreas, la nube puede reducir los costos. Sin embargo, el objetivo final de cualquier
transformación es producir mejores resultados con el tiempo. Para comprender las mejoras de los ingresos a
largo plazo, considere los efectos de bajada. ¿Qué tecnologías nuevas estarán disponibles para la empresa tras
la migración que no se puedan utilizar actualmente? ¿Qué proyectos u objetivos de negocio están bloqueados
por las dependencias de tecnologías heredadas? ¿Qué programas están en espera, pendientes de gastos de
capital elevados en tecnología?
Después de considerar las oportunidades que crea la nube, trabaje con la empresa para calcular el aumento de
los ingresos que podría provenir de esas oportunidades.
Costos diferenciales específicos de la migración

Calcule los cambios en los costos como resultado de la migración propuesta. Consulte el artículo sobre modelos
financieros para más información sobre los tipos de costos diferenciales. Los proveedores de nube con
frecuencia proporcionan herramientas para el cálculo de los costos diferenciales. La calculadora de costo total
de propiedad (TCO) de Azure es un ejemplo.
Otros ejemplos de costos que pueden reducirse con una migración a la nube:
Terminación o reducción del centro de datos (costos de entorno)
Reducción en la energía consumida (costos de entorno)
Terminación del bastidor (recuperación de recursos físicos)
Prevención de actualizaciones de hardware (prevención de costos)
Prevención de renovación de software (reducción de costos operativos o prevención de costos)
Consolidación del proveedor (reducción de costos operativos y posible reducción de costos indirectos)
Cuando los resultados de la ROI son sorprendentes

Si la ROI de una migración a la nube no está en consonancia con las expectativas, puede ser útil revisar los mitos
comunes enumerados al principio de este artículo.
Sin embargo, es importante entender que un ahorro en los costos no siempre es posible. Hay aplicaciones que
cuesta más tener en la nube que en el entorno local. Estas aplicaciones pueden sesgar considerablemente los
resultados en un análisis.
Cuando el ROI sea inferior al 20 %, podría realizar un ejercicio de planeamiento del patrimonio digital, con una
atención específica a la racionalización. Durante el análisis cuantitativo, revise cada aplicación para encontrar las
cargas de trabajo que sesgan los resultados. Podría ser aconsejable quitar esas cargas de trabajo del plan. Si
existen datos de uso, considere la posibilidad de reducir el tamaño de las máquinas virtuales para que coincidan
con el uso.
Si aún no está alineado el ROI, solicite la ayuda de un representante de ventas de Microsoft o hable con un
asociado experimentado.
Pasos siguientes
Creación de un modelo financiero para la transformación en la nube
Creación de un modelo financiero para la
transformación en la nube
Crear un modelo financiero que represente con precisión el valor empresarial completo de cualquier
transformación en la nube puede ser complicado. Los modelos financieros y las justificaciones empresariales
tienden a variar entre distintas organizaciones. En este artículo se establecen algunas fórmulas y se señalan
algunas cosas que normalmente faltan cuando los estrategas crean modelos financieros.
Rentabilidad de la inversión
La rentabilidad de la inversión (ROI) suele ser un criterio importante para los ejecutivos de máximo rango o la
junta. ROI se usa para comparar diferentes formas de invertir recursos limitados de capital. La fórmula de ROI
es bastante sencilla. Sin embargo, los datos necesarios para crear cada entrada de la fórmula pueden no ser tan
simples. Básicamente, ROI es la cantidad de rentabilidad generada por una inversión inicial. Normalmente se
representa como un porcentaje:
En las secciones siguientes, se le guía por los datos necesarios para calcular la inversión inicial y la ganancia de
la inversión (beneficios).
Cálculo de la inversión inicial

La inversión inicial es el gasto de capital y el gasto operativo necesarios para llevar a cabo una transformación.
La clasificación de los costos puede variar según los modelos de contabilidad y las preferencias del CFO. En esta
categoría se incluirían elementos como servicios profesionales para transformar, licencias de software que se
usan únicamente durante la transformación, costo de los servicios en la nube durante la transformación y,
posiblemente, el costo de los empleados asalariados durante la transformación.
Sume estos costos para crear una estimación de la inversión inicial.
Cálculo de la ganancia de la inversión

El cálculo de la ganancia de la inversión requiere con frecuencia una segunda fórmula, que es específica de los
resultados empresariales y los cambios técnicos asociados. Calcular los beneficios es más difícil que calcular las
reducciones de costos.
Para calcular los beneficios, se requieren dos variables:
Estas variables se describen en las secciones siguientes.
Ingresos diferenciales
Los ingresos diferenciales se deben prever en colaboración con las partes interesadas de la empresa. Una vez
que las partes interesadas acuerdan un impacto sobre los ingresos, se puede usar para mejorar la posición de
los beneficios.
Costos diferenciales
Los costos diferenciales son la cantidad de aumento o disminución que generará la transformación. Los costos
diferenciales pueden verse afectados por variables independientes. Los beneficios se basan en gran medida en
los costos directos como la reducción de gastos de capital, la prevención de costos, las reducciones de costos
operativos y las reducciones de amortización. En las secciones siguientes se describen algunos costos
diferenciales que se deben tener en cuenta.
Reducción o aceleración de la depreciación
Para más información sobre la depreciación, hable con el CFO o el equipo financiero. La siguiente información
sirve de referencia general sobre al tema de la depreciación.
Cuando se invierte capital en la adquisición de un recurso, esa inversión podría usarse con fines fiscales o
financieros para producir beneficios continuados durante la vida útil del recurso. Algunas compañías consideran
que la depreciación es una ventaja fiscal positiva. Otras la consideran un gasto que se realiza constantemente,
de forma parecida a otros gastos recurrentes atribuidos al presupuesto anual de TI.
Hable con la administración de hacienda para determinar si es posible eliminar la depreciación y si contribuiría
de forma positiva a los costos diferenciales.
Recuperación de los recursos físicos
En algunos casos, se pueden vender recursos retirados como una fuente de ingresos. Estos ingresos se suelen
agrupar dentro de la reducción de costos por motivos de simplicidad. Sin embargo, realmente es un aumento
de los ingresos y puede tributarse como tal. Hable con la administración de hacienda para conocer la viabilidad
de esta opción y cómo justificar los ingresos resultantes.
Reducciones de costos operativos
Los gastos recurrentes necesarios para operar un negocio a menudo se denominan gastos operativos. Esta es
una categoría amplia. En la mayoría de los modelos de contabilidad, incluye:
Licencias de software.
Gastos de hospedaje.
Facturas de electricidad.
Alquileres de bienes inmuebles.
Gastos de refrigeración.
Personal temporal necesario para las operaciones.
Alquiler de equipos.
Piezas de recambio.
Contratos de mantenimiento.
Servicios de reparación.
Servicios de continuidad del negocio y recuperación ante desastres (BC/DR).
Otros gastos que no requieren la aprobación de gastos de capital.
Esta categoría proporciona uno de los costos diferenciales más elevados. Si está considerando la posibilidad de
realizar una migración a la nube, el tiempo invertido en la creación de esta lista estará bien empleado. Formule
preguntas al CIO y al equipo financiero para asegurarse de que se justifican todos los costos operativos.
Prevención de costos
Cuando se espera un gasto operativo, pero no se encuentra aún en un presupuesto aprobado, no se puede
incluir en una categoría de reducción de costos. Por ejemplo, si las licencias de Microsoft y VMware se deben
volver a negociar y pagarse el próximo año, no son aún costos completos. Las reducciones en esos costos
esperados se tratan como costos operativos solo para el cálculo de los costos diferenciales. Sin embargo, de
manera informal, se deben considerar "prevención de costos" hasta que finalice la negociación y aprobación del
presupuesto.
Reducciones de costos indirectos
En algunas compañías también se podrían incluir los costos indirectos, como las reducciones en la complejidad
operativa o la reducción del personal a jornada completa para operar un centro de datos, en los costos
diferenciales. No obstante, incluir costos indirectos puede no ser una buena idea. Al incluir reducciones de
costos indirectos, se introduce un supuesto sin documentar de que la reducción creará un ahorro de costos
tangible. Los proyectos de tecnología rara vez dan lugar a una recuperación real de los costos indirectos.
Reducciones de plantilla
Los ahorros de tiempo para el personal se incluyen a menudo en la reducción de costos indirectos. Cuando esos
ahorros de tiempo se asignan a la reducción real de salario o personal de TI, se podrían calcular por separado
como una reducción de plantilla.
Dicho esto, las aptitudes necesarias en el entorno local se asignan generalmente a un conjunto de aptitudes
parecidas (o de nivel superior) necesarias en la nube. Esto significa que, por lo general, no se despide a la gente
tras una migración a la nube.
Ocurre una excepción cuando un tercero o un proveedor de servicios administrados (MSP) proporcionan
capacidad operativa. Si los sistemas de TI están administrados por un tercero, los costos operativos podrían
reemplazarse por una solución o un MSP nativos de la nube. Es probable que un MSP nativo de la nube trabaje
de manera más eficiente y posiblemente a un menor costo. Si es así, las reducciones de costos operativos
pertenecen a los cálculos de costos directos.
Reducción o prevención de gasto de capital
Los gastos de capital son ligeramente diferentes a los gastos operativos. Por lo general, esta categoría está
controlada por los ciclos de actualización o la expansión del centro de datos. Un ejemplo de una expansión del
centro de datos sería un nuevo clúster de alto rendimiento para hospedar una solución de macrodatos o
almacenamiento de datos. Esto normalmente se incluiría en una categoría de gastos de capital. Más comunes
son los ciclos de actualización básicos. Algunas compañías tienen ciclos de actualización de hardware rígidos, lo
que significa que los recursos se retiran y se sustituyen en ciclos regulares (normalmente cada 3, 5 u 8 años). A
menudo, estos ciclos coinciden con los ciclos de concesión de recursos o la duración prevista de los equipos.
Cuando se alcanza un ciclo de actualización, TI extrae el gasto de capital para adquirir nuevos equipos.
Si se aprueba y se presupuesta un ciclo de actualización, la transformación a la nube podría ayudar a eliminar
ese costo. Si un ciclo de actualización está planeado, pero aún no se ha aprobado, la transformación a la nube
podría prevenir un gasto de capital. Ambas reducciones se agregarían al costo diferencial.
Pasos siguientes
Más información sobre los modelos de contabilidad en la nube.
Contabilidad en la nube
¿En qué consiste la contabilidad en la nube?
La nube cambia el modo en que TI justifica los costos, como se describe en Creación de un modelo financiero
para la transformación a la nube. Es mucho más fácil admitir varios modelos de contabilidad de TI debido al
modo en que la nube asigna los costos. Por lo tanto, es importante comprender cómo justificar los costos de la
nube antes de comenzar el recorrido de transformación hacia esta nueva plataforma. En este artículo se
describen los modelos de contabilidad de la nube más comunes para TI.
Contabilidad de TI tradicional (modelo de centro de costos)

A menudo es preciso considerar la TI un centro de costos. En el modelo tradicional de contabilidad de TI, el
departamento de TI consolida la capacidad adquisitiva para todos los activos de TI. Como se señaló en el
artículo de modelos financieros, dicha consolidación de la capacidad adquisitiva puede incluir licencias de
software, cargos periódicos de licencias de CRM, compra de equipos de escritorio para los empleados y otros
costos de gran envergadura.
Cuando la TI funciona como centro de costos, su valor percibido se ve en gran medida a través de un objetivo de
administración de adquisiciones. Esta percepción dificulta que la Junta u otros ejecutivos comprendan el
verdadero valor que proporciona la TI. Los costos de adquisición tienden a sesgar la visión de la TI al sopesar
cualquier otro valor agregado por la organización. Esta vista explica por qué se suele agrupar TI en las
responsabilidades del director financiero o del director de operaciones. Esta percepción de la TI es limitada y
puede llevar a un planteamiento con poca visión del futuro.
Contabilidad de TI central (modelo de centro de beneficios)

Para superar la visión de la TI como un centro de costos, algunos CIO han optado por un modelo de contabilidad
de TI central. En este tipo de modelo, la TI se trata como una unidad de negocio competitiva que se encuentra al
mismo nivel que las unidades de negocio de generación de ingresos. En algunos casos, este modelo puede ser
completamente lógico. Por ejemplo, algunas organizaciones disponen de una división profesional de servicios
de TI que genera un flujo de ingresos. Con frecuencia, los modelos de TI centralizada no generan ingresos
significativos, lo que dificulta la justificación del modelo.
Con independencia del modelo de ingresos, los modelos de contabilidad de TI central son únicos debido a la
manera en que la unidad de TI justifica los costos. En un modelo de TI tradicional, el equipo de TI registra los
costos y paga esos costos de los fondos compartidos, como operaciones y mantenimiento (O&M) o una cuenta
de pérdidas y ganancias (P&G) dedicada.
En un modelo de contabilidad de TI central, el equipo de TI incrementa el precio de los servicios proporcionados
para justificar los gastos generales, de administración y de otro tipo estimados. Luego, se facturan a las
unidades de negocio competidoras los servicios de precio incrementado. En este modelo, se espera que el CIO
administre las ganancias y pérdidas asociadas con la venta de esos servicios. Esta situación puede llevar a inflar
los costos de TI y a la discordia entre TI central y las unidades de negocio, en especial cuando es necesario
reducir los costos de TI o no se están cumpliendo los Acuerdos de Nivel de Servicio acordados. Durante los
períodos de cambios tecnológicos o del mercado, cualquier tecnología nueva provocará una interrupción en el
balance de ingresos de TI central, lo que dificultará la transformación.
Contracargo
Uno de los primeros pasos habituales que hay que seguir para cambiar la reputación de la TI como centro de
costos es implementar un modelo de contabilidad de contracargo. Este modelo es especialmente común en
empresas más pequeñas o en organizaciones de TI con una elevada eficiencia. En el modelo de contracargo, los
costos de TI asociados a una unidad de negocio específica se tratan como gastos operativos en el presupuesto
de esa unidad de negocio. Esta práctica reduce los efectos de costos acumulados sobre la TI, lo que permite que
los valores empresariales se muestren con mayor claridad.
En un modelo local heredado, el contracargo es difícil de lograr porque todavía alguien tiene que arrastrar los
grandes gastos de capital y la amortización. La conversión continua de gastos de capital en gastos operativos
asociados al uso es un ejercicio de contabilidad difícil. Esta dificultad es una de las razones principales para la
creación del modelo de contabilidad de TI tradicional y el modelo de contabilidad de TI central. El modelo de
gastos operativos de contabilidad de costos de la nube es casi obligatorio si quiere proporcionar eficazmente un
modelo de contracargo.
Pero no debe implementar este modelo sin considerar las implicaciones. Estas son algunas de las consecuencias
que son específicas de un modelo de contracargo:
El contracargo produce una reducción masiva del presupuesto general de TI. En el caso de organizaciones de
TI que no son eficaces o que requieren extensas habilidades técnicas complejas en operaciones o
mantenimiento, este modelo puede exponer esos gastos de forma poco saludable.
Una de las consecuencias comunes es la pérdida de control. En entornos con un gran componente político, el
contracargo puede dar lugar a la pérdida de control y a la reasignación de personal a la empresa. Esta
situación podría crear importantes ineficiencias y reducir la capacidad de TI para cumplir sistemáticamente
los Acuerdos de Nivel de Servicio o los requisitos del proyecto.
Otra consecuencia común es la dificultad para justificar los servicios compartidos. Si la organización ha
crecido mediante adquisiciones y, como resultado, arrastra la deuda técnica, es probable que se deba
mantener un alto porcentaje de servicios compartidos para que todos los sistemas funcionen juntos de
manera efectiva.
Las transformaciones hacia la nube incluyen soluciones a estas y otras consecuencias asociadas a un modelo de
contracargo. Pero cada una de esas soluciones incluye gastos operativos y de implementación. El CIO y el
director financiero (CFO) deben sopesar detenidamente las ventajas y desventajas de un modelo de contracargo
antes de considerar uno.
Visualización de costos o reconocimiento de costos

En el caso de empresas más grandes, un modelo de visualización de costos o reconocimiento de costos es un
primer paso más seguro en la transición desde el centro de costos hasta el centro de valores. Este modelo no
afecta a la contabilidad financiera. De hecho, las pérdidas y ganancias de cada organización no cambian. El
mayor cambio está en la mentalidad y el reconocimiento. En un modelo de visualización de costos o
reconocimiento de costos, TI administra la capacidad adquisitiva consolidada centralizada como un agente para
la empresa. En la presentación de informes a la empresa, el departamento de TI atribuye los costos directos a la
unidad de negocio correspondiente, lo que reduce el presupuesto percibido que consume directamente la TI. El
departamento de TI también planea los presupuestos en función de las necesidades de las unidades de negocio
asociadas, lo que le permite justificar con mayor precisión los costos asociados a las iniciativas exclusivamente
de TI.
Este modelo proporciona un equilibrio entre un modelo verdaderamente de contracargo y modelos de
contabilidad de TI más tradicionales.
Efecto de los modelos de contabilidad de la nube

La elección de los modelos de contabilidad es fundamental en el diseño del sistema. Puede afectar a las
estrategias de suscripción, los estándares de nomenclatura, los estándares de etiquetado y los diseños de
directivas y planos técnicos.
Después de haber trabajado con la empresa para tomar decisiones sobre un modelo de contabilidad de la nube
y los mercados globales, dispone de suficiente información para elegir el primer proyecto de adopción de la
nube.
Elección del primer proyecto de adopción de la nube
Estrategia para la alineación de asociados
Cloud Adoption Framework aborda la adopción de la nube como una actividad de autoservicio. El objetivo es
capacitar a cada uno de los equipos que apoyan la adopción a través de enfoques estandarizados. En la práctica,
no se puede suponer que un enfoque de autoservicio será suficiente para todas las actividades de la adopción.
Los programas de adopción de la nube bien implantados suelen incluir al menos un nivel de apoyo. Algunos
esfuerzos de adopción de la nube pueden requerir apoyo de varios asociados que trabajan juntos en un objetivo
común.
Pasos para armonizar la estrategia de asociación

Durante las fase de creación de estrategia de la adopción, es importante empezar a alinear la estrategia de
asociación. Los siguientes pasos pueden ayudar a evitar obstáculos en fases posteriores del ciclo de vida de
adopción.
1. Empiece por comprender las necesidades de apoyos.
2. Considere las opciones de asociación que se adaptan a su cultura y sus necesidades.
3. Evalúe una preselección de opciones de asociados.
4. Empiece las revisiones de contratos y documentación de los asociados seleccionados.
La realización de estos pasos con antelación garantizará el éxito del equipo cuando comiencen los esfuerzos
técnicos. En las siguientes secciones de este artículo se proporcionan instrucciones para cada uno de estos
pasos.
Descripción de las necesidades de apoyo

A lo largo del ciclo de vida de la adopción de la nube, es posible que los distintos equipos necesiten apoyo para
completar su tarea con éxito. A continuación se muestran algunos ejemplos de los tipos de ayuda que se
requieren normalmente.
Estrategia: apoyo con la definición de la estrategia empresarial y la estrategia tecnológica de respaldo.
Planeamiento: apoyo con la detección de la cartera, la evaluación cuantitativa del patrimonio digital, el
desarrollo de un plan de adopción de la nube y la creación de un plan de capacitación.
Listo: apoyo con la implementación de una zona de aterrizaje o un entorno de nube completo capaz de
respaldar el plan de adopción de la nube.
Migración: apoyo para migrar cargas de trabajo o crear un generador de migración para garantizar
procesos de migración sin problemas.
Innovación: asistencia para desarrollar nuevas soluciones o recompilar o rediseñar soluciones existentes
para impulsar la innovación.
Gobernanza: apoyo o servicios administrados continuos para proporcionar gobernanza y controles en todo
el entorno de la nube.
Administración: apoyo o servicios administrados continuos para operar con la plataforma en la nube y las
cargas de trabajo hospedadas en la nube.
Pocas empresas tienen la diversidad de conocimientos necesarios para respaldar la estrategia, el planeamiento,
la preparación, la adopción, la gobernanza y la administración. El hecho de recurrir a asociados, u otros modelos
de apoyo, a menudo es necesario para llenar los vacíos en cuanto a aptitudes y responsabilidades del equipo.
Varias opciones de asociación pueden ayudarle a desarrollar las aptitudes necesarias, aumentar los requisitos de
personal o descargar completamente procesos específicos.
Opciones de asociación
No está solo en su viaje hacia la nube. Existen varias opciones en las que su equipo se puede apoyar en su
tránsito hacia la adopción de la nube.
Proveedores de soluciones de Azure (asociados): conecte con proveedores de servicios administrados
(MSP) expertos de Azure y otros asociados de Microsoft que tengan ofertas de servicio alineadas con las
metodologías de Cloud Adoption Framework.
FastTrack for Azure: Use el programa Microsoft FastTrack for Azure para acelerar la migración.
Programa de migración de Azure (AMP) : el programa AMP armoniza una combinación de asociados y
empleados de Microsoft para acelerar la migración y brindarle apoyo.
Proveedores de soluciones de Azure
Los proveedores de soluciones certificados de Microsoft se especializan en ofrecer modernas soluciones de
cliente basadas en tecnologías de Microsoft en todo el mundo. Optimice su negocio en la nube con la ayuda de
un asociado experimentado.
Busque un proveedor de soluciones en la nube (CSP) . Un CSP certificado puede ayudarle a sacar el
máximo provecho de la nube mediante la evaluación de los objetivos empresariales para la adopción de la nube,
la identificación de la solución en la nube adecuada que satisface las necesidades empresariales y ayuda a la
empresa a ser más ágil y eficaz.
Los proveedores de servicios administrados (MSP) expertos de Azure se han sometido a una auditoría de
terceros para validar un nivel superior de capacidad, demostrado mediante personal certificado, referencias de
clientes, consumo anual de Azure a gran escala y otros criterios.
Busque un asociado de ser vicios administrados . Un asociado de servicios administrados (MSP) de Azure
ayuda a una empresa a hacer la transición a Azure y guía todos los aspectos del recorrido en la nube. Desde la
consultoría hasta la administración de operaciones y migraciones, estos asociados muestran a los clientes todas
las ventajas que aporta la adopción de la nube. También actúan como un lugar único donde ofrecer soporte
técnico común, aprovisionamiento y la experiencia de facturación, todo ello con un modelo empresarial de pago
por uso flexible.
En paralelo al desarrollo de la estrategia de adopción de la nube, el equipo de estrategia en la nube debe
empezar a detectar a los proveedores de soluciones con los que puede resultar útil la asociación para la
consecución de los objetivos empresariales.
FastTrack for Azure
FastTrack for Azure ofrece asistencia directa por parte de los ingenieros de Azure, en estrecha colaboración con
los asociados, para ayudar a los clientes a compilar las soluciones de Azure con rapidez y confianza. FastTrack
aporta procedimientos recomendados y herramientas de experiencias reales del cliente para guiar a los clientes
desde la instalación, la configuración y el desarrollo hasta la producción de soluciones de Azure, lo que incluye:
Durante una interacción típica de FastTrack for Azure, Microsoft ayuda a definir la visión empresarial para
planear y desarrollar correctamente soluciones de Azure. El equipo evalúa las necesidades de diseño y
proporciona instrucciones, principios de diseño, herramientas y recursos para ayudar a compilar, implementar y
administrar soluciones de Azure. El equipo empareja asociados cualificados para los servicios de
implementación a petición y se registran periódicamente para asegurarse de que la implementación está en
buen pie y para ayudar a quitar los bloqueadores.
Programa de migración de Azure (AMP)
El Programa de migración de Azure (AMP) proporciona una combinación de creación de conocimientos
técnicos, instrucciones paso a paso, herramientas de migración gratuitas y posibles ofertas para reducir los
costos de migración.
El programa usa FastTrack for Azure y los proveedores de soluciones de Azure para mejorar el éxito de los
clientes durante la migración.
Consulte este breve vídeo para una visión general de cómo puede ayudarle el Programa de migración de Azure.
Soporte técnico de Azure

Si tiene alguna pregunta o necesita ayuda, cree una solicitud de soporte técnico. Si su solicitud de soporte
técnico requiere una guía técnica profunda, visite los planes de soporte técnico de Azure para alinear el mejor
plan según sus necesidades.
Preselección de las opciones de asociados

Durante el desarrollo de la estrategia, resulta difícil definir las necesidades de asociación específicas. Durante el
desarrollo del plan de adopción de la nube y del plan de aptitudes, será necesario determinar esas necesidades.
Sin embargo, en función de la cultura y madurez de su equipo, es posible que pueda decidirse por una opción
de asociación que esté más alineada con las necesidades esperadas.
Elija una o varias de las opciones de asociación anteriores para reducir el número de ellas que va a investigar en
primer lugar.
Comienzo de las revisiones de contratos y documentos

Cuando se ponga a revisar la lista preseleccionada de opciones, es probable que uno o varios asociados
empiecen a destacar. Si hay un claro líder entre los asociados, empiece el proceso de revisión de contratos y
documentos con el asociado.
El proceso de contratación puede llevar tiempo. La revisión de los términos legales con anticipación puede
suprimir una barrera a la contratación en un momento en que los equipos necesitan más ayuda.
Esto ocurre especialmente si su empresa requiere que se agreguen proveedores a una lista de proveedores
aprobados.
Pasos siguientes
Después de que se haya iniciado su estrategia de alineación de socios, es posible que desee diseñar su
estrategia de seguridad a continuación.
Definición de la estrategia de seguridad
Primer proyecto de adopción de la nube
El planeamiento de adopción de la nube conlleva una curva de aprendizaje y un compromiso de tiempo

asociados. Incluso para los equipos experimentados, un planeamiento adecuado lleva tiempo: tiempo para
alinear a las partes interesadas, tiempo para recopilar y analizar datos, tiempo para validar decisiones a largo
plazo y tiempo para alinear a las personas, los procesos y la tecnología. En los esfuerzos de adopción más
productivos, el planeamiento crece en paralelo con la adopción, mejorando con cada versión y con cada
migración de la carga de trabajo a la nube. Es importante comprender la diferencia entre un plan de adopción
de la nube y una estrategia de adopción de la nube. Se necesita una estrategia bien definida para facilitar y guiar
la implementación de un plan de adopción de la nube.
En Cloud Adoption Framework para Azure se describen los procesos para la adopción de la nube y el
funcionamiento de las cargas de trabajo hospedadas en la nube. Cada uno de los procesos de las fases de
estrategia, planeamiento, preparación, adopción y administración requiere ampliar ligeramente las aptitudes
técnicas, empresariales y operativas. Algunos de estos conocimientos pueden provenir de aprendizaje dirigido.
No obstante, muchos de ellos se obtienen de forma más eficaz a través de la experiencia práctica.
Emprender un proceso de primera adopción en paralelo con el desarrollo del plan proporciona algunas
ventajas:
Establece una mentalidad de crecimiento que fomenta el aprendizaje y la exploración.
Da al equipo la oportunidad de desarrollar los conocimientos necesarios.
Crea situaciones que fomentan nuevos enfoques para la colaboración.
Identifica carencias de conocimientos y posibles necesidades de asociación.
Proporciona entradas tangibles al plan.
Criterios del primer proyecto

Su primer proyecto de adopción debe estar en línea con sus motivaciones para la adopción de la nube. Siempre
que sea posible, el primer proyecto también debe demostrar el progreso hacia un resultado empresarial
definido.
Expectativas del primer proyecto

Lo más probable es que el proyecto de primera adopción del equipo dé lugar a una implementación de
producción de algún tipo. Sin embargo, esto no siempre es así. Establezca las expectativas adecuadas cuanto
antes. Estas son algunas de las expectativas que se recomienda establecer:
Este proyecto es una fuente de aprendizaje.
Este proyecto puede dar lugar a implementaciones de producción, pero probablemente requerirá un
esfuerzo adicional antes.
El resultado de este proyecto es un conjunto de requisitos claros para proporcionar una solución de
producción a largo plazo.
Ejemplos de primer proyecto

Para respaldar los criterios anteriores, esta lista proporciona un ejemplo de un primer proyecto para cada
categoría de motivación:
Eventos empresariales críticos: cuando un evento empresarial crítico es la motivación principal, la
implementación de una herramienta como Azure Site Recovery podría ser un buen primer proyecto.
Durante la migración, usará una herramienta como Azure Migrate para migrar rápidamente los recursos
del centro de datos. Pero durante el primer proyecto, podrá usar primero Azure Site Recovery como
herramienta de recuperación ante desastres. Reduzca las dependencias en los recursos de recuperación
ante desastres del centro de datos antes de planear pragmáticamente la migración.
Motivaciones de migración: cuando la migración es la motivación principal, es aconsejable empezar
con la migración de una carga de trabajo no crítica. En la guía de configuración de Azure y la guía de
migración a Azure se proporcionan instrucciones para la migración de la primera carga de trabajo.
Motivaciones de innovación: cuando la innovación es la motivación principal, la creación de un
entorno de desarrollo y pruebas de destino puede ser un excelente primer proyecto.
A continuación se incluyen otros ejemplos de proyectos de primera adopción:
Continuidad empresarial y recuperación ante desastres (BCDR): además de Azure Site Recovery,
puede implementar varias estrategias de recuperación ante desastres y continuidad empresarial como
primer proyecto.
No producción: implemente una instancia de no producción de una carga de trabajo.
Archivo: el almacenamiento en frío puede suponer una carga excesiva para los recursos de los centros de
datos. Trasladar los datos a la nube es una solución eficaz rápida.
Finalización del sopor te técnico: la migración de los recursos que han alcanzado la finalización del
soporte técnico es otra ventaja rápida que genera conocimientos técnicos. También puede prevenir algunos
costos de licencias o de contratos de soporte técnico costosos.
Interfaz de escritorio vir tual (VDI): la creación de escritorios virtuales para empleados remotos puede
proporcionar una ventaja rápida. En algunos casos, este proyecto de primera adopción también podría
reducir la dependencia de redes privadas costosas en favor de la conectividad de Internet público de los
productos.
Desarrollo y pruebas: quite operaciones de desarrollo y pruebas de entornos locales para ofrecer a los
desarrolladores control, agilidad y capacidad de autoservicio.
Aplicaciones sencillas (menos de cinco): modernice y migre una aplicación sencilla para obtener
rápidamente experiencia de desarrollo y operaciones.
Laboratorios de rendimiento: cuando necesite un rendimiento a gran escala en un entorno de
laboratorio, utilice la nube para aprovisionar de forma rápida y rentable esos laboratorios durante un breve
período de tiempo.
Plataforma de datos: cree un lago de datos con proceso escalable para análisis, informes o cargas de
trabajo de aprendizaje automático y migre a bases de datos administradas mediante los métodos
dump/restore o los servicios de migración de datos.
Pasos siguientes
Obtenga más información sobre las estrategias para equilibrar prioridades contrapuestas.
Equilibrio de prioridades contrapuestas
Equilibrio de prioridades en la competencia
Embarcarse en una experiencia de transformación digital sirve de impulso para las partes interesadas en los
equipos empresariales y tecnológicos. El camino hacia el éxito se basa principalmente en la capacidad de la
organización para equilibrar prioridades contrapuestas.
Al igual que sucede con otras transformaciones digitales, la adopción de la nube sacará a la luz prioridades
contrapuestas a lo largo del ciclo de vida de la adopción. De forma similar a otras formas de transformación, la
capacidad de encontrar el equilibrio en esas prioridades tendrá un impacto significativo en la consecución del
valor empresarial. Equilibrar estas prioridades contrapuestas requerirá conversaciones francas, y a veces
complicadas, entre las partes interesadas, y, en ocasiones, con los colaboradores individuales.
En este artículo se describen algunas de las prioridades contrapuestas que se tratan normalmente durante la
ejecución de cada metodología. Esperamos que este conocimiento avanzado le ayude a prepararse mejor para
esas conversaciones cuando desarrolle la estrategia de adopción de la nube.
Las secciones siguientes están en línea con el gráfico anterior del ciclo de vida de adopción de la nube. Sin
embargo, es importante reconocer que la adopción de la nube es iterativa (no es un proceso secuencial). Estas
prioridades contrapuestas surgirán, y, a veces, volverán a reaparecer, en varios puntos del recorrido de adopción
de la nube.
Tema general del enfoque de Cloud Adoption Framework

Las soluciones homogéneas y el planeamiento avanzado se basan en una serie de suposiciones que pueden
resultar (o no) adecuadas a lo largo del tiempo. La adopción de la nube a menudo es una experiencia novedosa
para los equipos técnicos y empresariales. Al igual que sucede con la mayoría de las nuevas experiencias u
oportunidades de aprendizaje, hay muchas probabilidades de que esas suposiciones resulten falsas.
Los siguientes principios ágiles de decisiones técnicas diferidas constituyen el enfoque preferido en la mayoría
de instrucciones de este marco. Este enfoque sigue un patrón coherente: permite establecer un estado final
general, pasar rápidamente a la implementación inicial, probar y validar suposiciones, refactorizar pronto para
dar respuesta a las suposiciones. Este tipo de mentalidad de crecimiento maximiza el aprendizaje y minimiza los
riesgos para el valor empresarial, pero requiere un cierto grado de aceptación de la ambigüedad.
En ocasiones, la ambigüedad puede ser peor (o más peligrosa) que las suposiciones falsas. Aunque este marco
de trabajo se basa en el aprendizaje y en dar respuesta a la ambigüedad durante la ejecución, hay muchas
situaciones que requieren que el equipo opte por enfoques basados en análisis o en suposiciones. En las
secciones siguientes se intentará ilustrar al menos un "ejemplo de ámbito ampliado" en cada sección para
ilustrar aquellas ocasiones en las que una segunda iteración más profunda sería valiosa.
Equilibrio durante la fase de creación de estrategia

El objetivo principal de la metodología de estrategia es desarrollar la alineación entre las partes interesadas. Una
vez definida, esa posición estratégica alineada controlará los comportamientos en cada una de las metodologías
para garantizar que las decisiones técnicas estén alineadas con los resultados de negocio deseados. Promover la
alineación entre las partes interesadas crea un conjunto común de prioridades contrapuestas: profundidad de
la justificación frente a impacto del tiempo necesario para la comercialización .
Prioridades contrapuestas:
Impor tancia de la justificación : las partes interesadas suelen querer un análisis financiero en
profundidad y una justificación comercial completa para que acepten alinearse con una dirección estratégica.
Lamentablemente, ese nivel de análisis puede requerir un período prolongado de tiempo que permita la
recopilación y el análisis de datos.
Tiempo para que se produzca el efecto en el negocio: por el contrario, las partes interesadas suelen
ser responsables de tener que entregar resultados empresariales dentro de los plazos de tiempo definidos.
Un análisis y evaluación prolongados pueden poner en riesgo esos resultados antes incluso de que se inicie
el trabajo técnico.
Ámbito mínimo: la búsqueda de este equilibrio requiere debates entre las partes interesadas al principio del
proceso. La metodología de estrategia sugiere limitar el ámbito de la alineación durante este esfuerzo inicial. En
el enfoque sugerido, las partes interesadas se centran en alinearse en torno a un conjunto de motivaciones
principales, resultados medibles y una justificación comercial de alto nivel. A continuación, las partes interesadas
deben confirmar rápidamente un pequeño número de proyectos iniciales o piloto para impulsar las
oportunidades de aprendizaje necesarias.
Ejemplo de ámbito ampliado: si el análisis empresarial inicial indica un alto riesgo de un efecto negativo en
la empresa, es posible que las partes interesadas tengan que detenerse y evaluar con mayor precaución un
análisis más profundo durante la justificación comercial.
Equilibrio durante la fase de planeamiento

De forma similar a las prioridades de la fase de creación de estrategia, durante la fase de planeamiento es
necesario equilibrar la profundidad del planeamiento inicial frente a las decisiones técnicas diferidas.
La profundidad del planeamiento inicial con respecto a la implementación técnica en la nube a menudo
contiene un gran número de suposiciones. Especialmente cuando el equipo tiene lagunas de aptitudes, el
entorno se ve afectado por brechas de detección, o las cargas de trabajo no tienen los estados finales de
arquitectura claramente definidos. Todas estas suposiciones son habituales en los planes detallados de
adopción de la nube. Para eliminar estas suposiciones, se necesita experimentación, proyectos pilotos y
análisis cualitativos.
En las decisiones técnicas diferidas se supone que cuanto más se tarda en tomar una decisión técnica,
más precisa es esa decisión. Los siguientes principios de planeamiento de productos ágiles le ayudarán a
retrasar las decisiones técnicas, lo cual permitirá que se realicen en el momento adecuado con información
suficiente. Sin embargo, este enfoque da como resultado un grado mucho más alto de ambigüedad en el
plan inicial.
Ámbito mínimo: los enfoques de desarrollo de productos ágiles se recomiendan para impulsar una rápida
actuación en los planes administrables. La metodología de planeamiento recomienda los siguientes pasos para
lograr este equilibrio. Realice un inventario completo del patrimonio digital mediante herramientas de detección
automática, pero utilice la racionalización incremental para planear los próximos 1 a 3 meses de trabajo.
Asegúrese de que la alineación de la organización sea adecuada para avanzar rápidamente. Cree un plan de
preparación de aptitudes para el equipo asignado. Utilice la estrategia y la plantilla del plan de adopción de la
nube para implementar rápidamente un trabajo pendiente inicial.
Ejemplo de ámbito ampliado: en ocasiones, la entrega de un plan de adopción de la nube puede estar
respondiendo a un evento empresarial con límite de tiempo o de gran impacto. Cuando el éxito requiere el
traslado de un gran número de recursos en un período de tiempo fijo, los pasos anteriores se suelen seguir con
un esfuerzo de planeación más profundo. La clave del éxito en estos escenarios es planear lo suficiente para
empezar a trabajar y, a continuación, planear la involucración plena. Este enfoque reduce la probabilidad de que
el planeamiento bloquee los resultados empresariales.
Equilibrio durante la fase de preparación

Cuando los equipos de adopción están preparando los primeros pasos en la nube, a menudo hay prioridades
contrapuestas entre el tiempo para la adopción y las operaciones a largo plazo. Puede que el equipo tenga
dificultades a la hora de decidir entre estar bien preparado para entregar la tarea en cuestión o estar bien
administrado. Este esfuerzo es necesario en los entornos de TI tradicionales, en los que el hecho de desarrollar
una plataforma requiere recursos físicos y ciclos de adquisición. Sin embargo, cuando se define toda la
plataforma de TI en código, las tácticas de desarrollo tradicionales (como la refactorización) reducen la
necesidad de estar bien administrado desde el principio.
Operaciones a largo plazo: a menudo, los clientes se bloquean por el deseo de tener un entorno de nube
que cumpla la paridad de características con los sistemas actuales de administración de operaciones,
gobernanza y seguridad. En un estudio actual de clientes, más del 90 % de estos necesitaron apoyo para
superar esta mentalidad. Este elemento de bloqueo supone meses de retraso lo cual ralentiza o impide el
impacto en la empresa.
Tiempo para la adopción: las herramientas basadas en la nube como Azure Policy, Azure Blueprints y los
grupos de administración permiten facilitar la refactorización en la plataforma de TI. Además, las zonas de
aterrizaje predefinidas proporcionan posiciones bien fundamentadas para acelerar la implementación en un
entorno que ya cumple muchos de los requisitos de paridad de características. Gracias a todo esto, existen
oportunidades de acelerar el tiempo de comercialización, con un impacto mínimo en las operaciones a largo
plazo.
Ámbito mínimo: la metodología de preparación describe una ruta directa desde la adopción rápida a las
operaciones a largo plazo. Este enfoque comienza con una introducción básica a las herramientas que permiten
la refactorización del entorno. En función de esas herramientas y de los requisitos del entorno, se guiará a los
clientes a una selección de zonas de aterrizaje predefinidas (cada una de ellas proporcionada mediante modelos
de infraestructura como código). Después, ese código puede refactorizarse durante el transcurso de la adopción
de la nube para mejorar las operaciones, la seguridad y las posiciones de administración.
Ejemplo de ámbito ampliado: en el caso de los equipos en los que el plan de adopción establece un objetivo
a medio plazo (menos de 24 meses) para hospedar más de 1000 recursos (aplicaciones, infraestructura
o recursos de datos) en la nube , se recomienda un enfoque más sólido de las zonas de aterrizaje. En estas
situaciones, las metodologías de gobernanza y administración se deben tener en cuenta durante las
conversaciones iniciales sobre zonas de aterrizaje. Sin embargo, esta consideración más profunda suele agregar
semanas o meses a un plan de adopción de la nube. Para minimizar el impacto en los resultados de la empresa,
el equipo de adopción debe probar cargas de trabajo reales en la nube en paralelo con la creación de una zona
de aterrizaje más consolidada y una solución de arquitectura central.
Equilibrio durante la fase de migración

Durante los esfuerzos de migración, es habitual que los equipos de adopción asuman que las cargas de trabajo
se rehospedarán en la nube con su configuración actual. Esto se contrapone directamente con un enfoque de
previsión con el que rediseñar cada carga de trabajo y aprovechar mejor las capacidades de la nube. No
obstante, los dos enfoques no son mutuamente excluyentes y pueden ser complementarios cuando se
administran mediante un proceso común.
Rehospedaje: a menudo, los clientes equiparan la migración a un movimiento lift-and-shift de replicación
de todos los recursos en la nube en su configuración de estado actual. Esto da lugar a un pequeño desfase en
la cartera de TI. Este enfoque también es la manera más rápida de retirar recursos de un centro de datos
existente.
Rediseño: la modernización de la arquitectura de cada carga de trabajo maximiza el valor de la nube en
relación con el costo, el rendimiento y las operaciones. Sin embargo, este enfoque es mucho más lento y a
menudo requiere acceso al código fuente de cada aplicación.
Ámbito mínimo: durante el planeamiento de la fase temprana, use la opción de rehospedaje para el
planeamiento, teniendo presente que esta opción es una suposición empresarial inicial y no una decisión
técnica. En la metodología de migración, el equipo de adopción de la nube comprobaría posteriormente esta
suposición para cada carga de trabajo migrada. Esta metodología sigue el enfoque de evaluación, migración y
promoción para cada carga de trabajo o grupo de cargas de trabajo mediante la creación de una factoría de
migración. Durante la fase de evaluación, el equipo de adopción evalúa la adecuación técnica y la arquitectura
de cada carga de trabajo. Ese esfuerzo de evaluación rara vez da como resultado un enfoque puro de lift-and-
shift, ya que muchos de los componentes de la arquitectura tienden a seleccionarse para su refactorización y
modernización.
Ejemplo de ámbito ampliado: en el caso de cargas de trabajo críticas o de alta confidencialidad como, por
ejemplo, un sistema central o una aplicación de microservicios de varios niveles, puede que se necesite una
evaluación más profunda de la carga de trabajo durante la fase de evaluación. En estas situaciones de rediseño,
los clientes deben utilizar la reseña de buena arquitectura de Microsoft Azure y el marco de buena arquitectura
de Microsoft Azure para refinar los requisitos de las cargas de trabajo durante la evaluación.
Equilibrio durante la fase de innovación

Una verdadera innovación orientada hacia el cliente crea prioridades comunes contrapuestas entre la necesidad
de ofrecer un conjunto de características planeadas y un proceso de desarrollo de empatía con el cliente.
Centrado en las características : los planes iniciales de innovación se basan en el patrimonio digital
existente y en las funcionalidades de la nube para ofrecer un conjunto de características que satisfagan las
necesidades de un cliente. Es fácil permitir que el plan impulse la implementación técnica, lo cual conduce a
un esfuerzo de desarrollo centrado en las características. A menudo, este enfoque conduce a la satisfacción
temporal de las partes interesadas, pero reduce la probabilidad de impulsar una innovación que surta efecto
en los comportamientos de los clientes.
Empatía con el cliente : los planes iniciales son una parte importante del aspecto empresarial del
desarrollo y deben incluirse en los informes normales. Sin embargo, el aprendizaje, medición y creación con
la empatía del cliente es una medida más adecuada de éxito en un esfuerzo de innovación. Centrarse en el
cliente en lugar de en las características tiene más probabilidades de dar lugar a una satisfacción de los
clientes a corto y largo plazo, y a un impacto empresarial.
Ámbito mínimo: la metodología de innovación muestra cómo integrar la estrategia y los planes mediante el
consenso sobre el valor empresarial. En la guía se presentan, a continuación, las herramientas nativas de la nube
que pueden acelerar cada materia de innovación, junto con los procedimientos recomendados para su
implementación. Por último, en la sección de mejoras de procesos se muestran enfoques para la creación de
empatía con el cliente al tiempo que se respetan los planes y estrategias del recorrido de adopción de la nube.
Este enfoque se centra en ofrecer innovación con el uso de la menor tecnología posible.
Ejemplo de ámbito ampliado: en ocasiones, una innovación puede depender de cargas de trabajo críticas o
de alta confidencialidad. Cuando el "cliente" es un usuario interno, el esfuerzo de desarrollo puede ser crítico o
de alta confidencialidad durante las primeras iteraciones. En estos casos, los equipos de adopción deben utilizar
la reseña de buena arquitectura de Microsoft Azure y el marco de buena arquitectura de Microsoft Azure para
evaluar el diseño avanzado de la arquitectura en una fase temprana del proceso.
Equilibrio durante la fase de gobernanza

La práctica de la gobernanza en la nube es un equilibrio constante entre dos prioridades contrapuestas:
velocidad y agilidad frente a un entorno bien gobernado. El equipo de gobernanza en la nube se centra en
evaluar y minimizar los riesgos para la empresa mediante controles uniformes y la reducción de los cambios. El
equipo de adopción se centra en impulsar resultados empresariales, los cuales requieren nuevos riesgos y
generan cambios de forma inherente.
Bien gobernado : cada control diseñado para minimizar el riesgo bloquea algún aspecto de cambio o limita
las opciones de diseño. El control es esencial para un entorno bien gobernado. Sin embargo, cuando los
controles se diseñan e implementan de manera aislada, pueden ser tan perjudiciales como los riesgos que
pretenden evitar.
Velocidad y agilidad : la velocidad y la agilidad son requisitos empresariales fundamentales en la economía
digital. Ambos requieren la posibilidad de impulsar el cambio con elementos de bloqueo mínimos para la
innovación o la adopción. Si se impulsa el cambio de manera aislada con respecto a la gobernanza, se
generan nuevos riesgos que podrían perjudicar a la empresa de maneras no deseadas.
Ámbito mínimo: la metodología de gobierno recomienda que ni la gobernanza ni la adopción deben darse de
manera aislada. Esta metodología comienza con una comprensión de las materias de gobernanza y una
conversación en torno al riesgo empresarial, las directivas y el proceso de negocio. Como miembro activo a lo
largo del recorrido de adopción de la nube, el equipo de gobernanza puede implementar un conjunto mínimo
de límites de protección para afrontar los riesgos tangibles en el plan de adopción de la nube. Con el tiempo, el
equipo de gobernanza puede refactorizar y expandir esos límites para afrontar nuevos riesgos. Este enfoque
maximiza el aprendizaje y la innovación, al tiempo que reduce al mínimo el riesgo.
Ejemplo de ámbito ampliado: cuando el riesgo empresarial es alto, especialmente al principio del proceso de
adopción, es posible que el equipo de gobernanza en la nube necesite acelerar la expansión de las
implementaciones de gobernanza. Se pueden usar las mismas instrucciones y ejercicios para agregar este nivel
de gobernanza más elevado, pero puede que sea necesario acelerar la programación temporal. En algunos
escenarios, incluso puede ser necesario un estado avanzado de gobernanza durante la implementación de las
primeras zonas de aterrizaje.
Equilibrio durante la fase de administración

El modelo empresarial de TI con respecto a la administración de operaciones ha evolucionado continuamente
durante la última década. A medida que el mantenimiento del hardware se aleja de la principal propuesta de
valor de TI, la perspectiva sobre la administración de operaciones también cambia. A medida que TI aumenta su
interés en proporcionar valor empresarial, los equipos de administración de operaciones entran en conflicto a la
hora de alcanzar un equilibrio entre realizar inversiones para entornos con pocas operaciones, o sin ellas, frente
a grandes inversiones.
Grandes inversiones: invertir por igual en la prevención de interrupciones, la recuperación rápida y la
supervisión en todo el entorno es el enfoque tradicional en la administración de operaciones. Este enfoque
puede ser costoso y, a veces, duplica los productos de soporte que pone a disposición el proveedor de la
nube.
Pocas operaciones o ninguna : utilice las herramientas operativas nativas en la nube para reducir al
mínimo las tareas repetitivas y recurrentes que ya entregaron previamente los empleados a tiempo
completo. La reducción de estas dependencias operativas en el modelo de administración de operaciones
permite a esos empleados generar más valor. Por sí solo, este enfoque puede conducir a un soporte de las
operaciones de poca calidad.
Ámbito mínimo: la metodología de administración sugiere el establecimiento de una base de referencia nativa
en la nube, sin operaciones. El reconocimiento de que la base de referencia sin operaciones no satisface todas
las necesidades empresariales impulsa a la empresa a definir los compromisos y adecuar mejor las inversiones.
Amplíe la línea de base para satisfacer las necesidades comunes de todas las cargas de trabajo. A continuación,
cree equipos de plataforma o de cargas de trabajo específicas para mantener soluciones bien administradas en
un entorno bien administrado.
Ejemplo de ámbito ampliado: en la mayoría de los entornos, hay un pequeño porcentaje de cargas de
trabajo cuyo valor empresarial justifica grandes inversiones en operaciones por parte de TI. En estos casos, el
equipo de TI puede utilizar la reseña de buena arquitectura de Microsoft Azure y el marco de buena arquitectura
de Microsoft Azure para guiar las operaciones más complejas.
Equilibrio durante la fase de organización

Las prioridades contrapuestas que aparecen a lo largo de este artículo son reflejo del intento por parte de TI de
satisfacer las demandas empresariales para ganar velocidad y agilidad. Este mismo cambio aparece en los
cambios realizados en los organigramas (o estructuras del equipo virtual) para proporcionar un respaldo mayor
y lograr resultados empresariales. A medida que los directivos de TI influyen en las estructuras de equipo,
normalmente se abordan dos prioridades contrapuestas: control centralizado frente a control delegado.
Control centralizado : este modelo operativo se centra en la centralización de todos los controles
necesarios para aplicar directivas rígidas. En este modelo, el departamento de TI actúa como un elemento de
bloqueo de la innovación, la velocidad y la agilidad. En cambio, TI puede garantizar un mayor grado de
estabilidad, cumplimiento y seguridad.
Control delegado : en este modelo operativo distribuido, se supone que cada equipo de DevOps, o equipo
de aplicaciones empresariales, proporcionará su propio conjunto de controles en función de las soluciones
necesarias para lograr los objetivos empresariales. Según este modelo, TI proporciona límites de protección
para ayudar a mantener los equipos en la dirección adecuada, pero minimiza el número de restricciones
técnicas forzadas siempre que es posible.
Ámbito mínimo: la mayoría de las organizaciones experimentarán un conjunto natural de evoluciones a lo
largo del tiempo. La metodología de organización describe la serie de evoluciones más habitual. La
recomendación para los equipos es intentar pasar a una estructura de Centro de excelencia en la nube (CCoE)
que proporcione enfoques de control delegado.
Ejemplo de ámbito ampliado: hay muchas situaciones que podrían desencadenar la necesidad de un control
centralizado. Dos ejemplos de desencadenadores del control centralizado podrían ser los requisitos de
cumplimiento de terceros o los riesgos de seguridad temporales. En estas situaciones, normalmente es
necesario establecer directivas de limitación y controles fijos y rígidos. Sin embargo, para permitir que la
innovación y la adopción continúen, se recomienda que los equipos de TI centrales proporcionen esos controles
en función de la importancia y la confidencialidad de cada carga de trabajo. Proporcionar entornos con menor
control, pero con un ámbito o perfil de riesgos reducido, permite una mayor flexibilidad incluso cuando se
necesita control.
Pasos siguientes
Aprenda a equilibrar migración, innovación y experimentación para maximizar el valor de los esfuerzos de
migración a la nube.
Equilibrio de la cartera
Conciliar la cartera
La adopción de la nube es un esfuerzo de administración de carteras, disfrazado de manera inteligente como

una implementación técnica. Al igual que cualquier ejercicio de administración de carteras, el equilibrio de una
cartera es crítico. En un nivel estratégico, esto significa equilibrar la migración, innovación y experimentación
para aprovechar la nube al máximo. Cuando el esfuerzo de adopción de la nube se inclina demasiado en una
dirección, la complejidad se abre camino en los esfuerzos de adopción. En este artículo se le guiará al lector a
través de los enfoques para alcanzar el equilibrio de la cartera.
Ampliación del ámbito general

El equilibrio de la cartera es estratégico por naturaleza. De ese modo, el enfoque que se lleva a cabo en este
artículo es igualmente estratégico. Para basar la estrategia en decisiones controladas por datos, en este artículo
se presupone que el lector ha evaluado el patrimonio digital existente o que ha empezado dicho proceso. El
objetivo de este enfoque es ayudar a evaluar las cargas de trabajo para garantizar un equilibrio adecuado en
toda la cartera a través de preguntas cualitativas y el perfeccionamiento de la cartera.
Documentar resultados empresariales
Antes de equilibrar la cartera, es importante documentar y compartir los resultados empresariales que
impulsan el esfuerzo de migración a la nube. La tabla siguiente puede ayudar a documentar y compartir los
resultados empresariales deseados. Es importante tener en cuenta que la mayoría de las empresas buscan
obtener varios resultados a la vez. La importancia de este ejercicio es aclarar los resultados que están
relacionados de manera más directa con el esfuerzo de migración a la nube:
P RIO RIDA D DE EST E

RESULTA DO M EDIDO P O R O B JET IVO P ERÍO DO DE T IEM P O ESF UERZ O
Reducción de los Presupuesto del Reducción en 12 meses N.° 1

costos de TI centro de datos 2 millones USD
Salida del centro de Salida de los centros 2 centros de datos 6 meses N.° 2
datos de datos
Aumento de la Mejor tiempo de Disminuir el tiempo 2 años N.° 3

agilidad comercial comercialización de implementación
en seis meses
Mejor experiencia del Satisfacción del 10 % de mejora 12 meses N.° 4

cliente cliente (CSAT)
IMPORTANT
La tabla anterior es un ejemplo ficticio y no se debe usar para establecer las prioridades. En muchos casos, esta tabla se
podría considerar como un antipatrón, ya que sitúa los ahorros de costos por encima de las experiencias de los usuarios.
La tabla anterior podría representar de manera precisa las prioridades de los equipos de estrategia de la nube y
de adopción de la nube. Debido a restricciones a corto plazo, este equipo pone un mayor énfasis en la reducción
de costos de TI y en establecer la prioridad de una salida de datos como medio para lograr las reducciones de
costos de TI deseadas. Sin embargo, al documentar las prioridades contrapuestas en esta tabla, el equipo de
adopción de la nube está capacitado para ayudar al equipo de estrategia en la nube a identificar oportunidades
para alinear mejor la implementación de la estrategia de cartera general.
Traslado rápido mientras se mantiene el equilibrio
Las instrucciones relacionadas con la racionalización incremental del patrimonio digital sugieren un enfoque en
el que la racionalización comienza con una posición no equilibrada. El equipo de estrategia en la nube debe
evaluar cada carga de trabajo para ver si es compatible con un enfoque de rehospedaje. Se sugiere este tipo de
enfoque porque permite realizar una evaluación rápida de un patrimonio digital complejo en función de datos
cuantitativos. Una suposición inicial así permite que el equipo de adopción de la nube participe rápidamente,
con lo que disminuirá el tiempo para obtener resultados empresariales. Sin embargo, tal como se indica en este
artículo, las preguntas cualitativas proporcionarán el equilibrio necesario en la cartera. En este artículo se
documenta el proceso de creación del equilibrio prometido.
Importancia de las decisiones sobre expiración y retirada
En la tabla que aparece en la sección de documentación de los resultados empresariales falta un resultado clave
que podría permitir el objetivo número uno de reducir los costos de TI. Cuando las reducciones de los costos de
TI están en cualquier parte de la lista de resultados empresariales, resulta importante considerar el potencial
para expirar o retirar cargas de trabajo. En algunos escenarios, el ahorro de costos puede provenir de no migrar
las cargas de trabajo que no garantizan una inversión a corto plazo. Algunos clientes han informado ahorros de
costos superiores al 20 % de las reducciones de costos totales al retirar las cargas de trabajo infrautilizadas.
Para equilibrar la cartera, lo que mejor refleja las decisiones sobre expiración y retirada, se recomienda que los
equipos de estrategia en la nube y de adopción de la nube hagan las preguntas siguientes sobre cada carga de
trabajo durante las fases de evaluación y migración:
¿Los usuarios finales han usado la carga de trabajo en los últimos seis meses?
¿El tráfico de usuario final es coherente o va en aumento?
¿La empresa necesitará esta carga de trabajo en 12 meses más?
Si la respuesta a cualquiera de estas preguntas es "No", la carga de trabajo podría ser candidata a la retirada. Si
se confirma el potencial de retirada con el propietario de la aplicación, puede que migrar la carga de trabajo no
tenga sentido. Esto implica algunas preguntas de calificación:
¿Se puede establecer un plan de retirada o un plan de expiración para esta carga de trabajo?
¿Esta carga de trabajo se puede retirar antes de la salida del centro de datos?
Si la respuesta a ambas preguntas es "Sí", sería recomendable no migrar la carga de trabajo. Este enfoque
ayudaría a cumplir los objetivos de disminuir costos y salir del centro de datos.
Si al respuesta a cualquier pregunta es "No", podría ser aconsejable establecer un plan para hospedar la carga
de trabajo hasta que se pueda retirar. Este plan podría incluir el traslado de los recursos a un centro datos de
menor costo o a uno alternativo, lo que también lograría los objetivos de reducir los costos y salir de un centro
de datos.
Cambios en el proceso de adopción

El equilibrio de la cartera requiere un análisis cualitativo adicional durante la fase de adopción, que ayudará a
impulsar una racionalización de cartera sencilla.
En función de los datos de la tabla que aparece en la sección Documentación de los resultados empresariales
anterior, hay un riesgo probable de que la cartera se incline demasiado hacia un modelo de ejecución centrado
en la migración. Si la experiencia del cliente fuese una prioridad principal, sería más probable una cartera
inclinada a la innovación. Ninguno de estos enfoques es correcto ni equivocado, pero inclinarse demasiado en
una sola dirección habitualmente generá una disminución en las devoluciones, agrega complejidad innecesaria
y aumenta el tiempo de ejecución relacionado con los esfuerzos de adopción de la nube.
Para disminuir la complejidad, debe seguir un enfoque tradicional con respecto a la racionalización de la cartera,
pero en un modelo iterativo. Los pasos siguientes describen un modelo cualitativo para dicho tipo de enfoque:
El equipo de estrategia en la nube mantiene un trabajo pendiente priorizados de las cargas de trabajo que se
van a migrar.
Los equipos de estrategia en la nube y de adopción de la nube realizan una reunión de planeamiento de
liberación antes de completar cada liberación.
En la reunión de planeamiento de liberación, los equipos llegan a un acuerdo sobre las principales 5 a 10
cargas de trabajo en el trabajo pendiente con prioridad.
Fuera de la reunión de planeamiento de liberación, el equipo de adopción de la nube formular estas
preguntas a los propietarios de la aplicación y a los expertos en la materia:
¿Esta aplicación se podría reemplazar por un equivalente de plataforma como servicio (PaaS)?
¿Es una aplicación de terceros?
¿Se aprobó presupuesto para invertir en el desarrollo en curso de la aplicación durante los próximos
12 meses?
¿El desarrollo adicional de esta aplicación mejoraría la experiencia del cliente? ¿Crearía un
diferenciador competitivo? ¿Generaría ingresos adicionales para la empresa?
¿Los datos dentro de esta carga de trabajo contribuirán a una innovación de nivel inferior relacionada
con inteligencia empresarial, aprendizaje automático, IoT u otras tecnologías relacionadas?
¿La carga de trabajo es compatible con plataformas de aplicaciones modernas como
Azure App Service?
Las respuestas a las preguntas anteriores y cualquier otro análisis cualitativo necesarios podrían influir en los
ajustes en el trabajo pendiente con prioridad. Estos ajustes pueden incluir:
Si una carga de trabajo se pudiera reemplazar por una solución de PaaS, se puede quitar totalmente
del trabajo pendiente de migración. Como mínimo, la diligencia requerida adicional para decidir entre
rehospedaje y reemplazo se podría agregar como tarea, lo que reduciría de manera temporal la
prioridad de esa carga de trabajo del trabajo pendiente de migración.
Si una carga de trabajo está en proceso de desarrollo (o debería estarlo), es posible que se ajuste
mejor a un modelo de refactorización/rediseño/recompilación. Como la innovación y la migración
requieren aptitudes técnicas distintas, las aplicaciones que se alinean con un enfoque de
refactorización/rediseño/recompilación se deben administrar mediante un trabajo pendiente de
innovación en lugar de un trabajo pendiente de migración.
Si una carga de trabajo forma parte de una innovación de nivel inferior, es posible que tenga sentido
refactorizar la plataforma de datos, pero dejar los niveles de aplicación como candidatos a
rehospedaje. A menudo, la refactorización secundaria de la plataforma de datos de una carga de
trabajo se puede abordar en un trabajo pendiente de innovación o migración. Este resultado de la
racionalización puede generar elementos de trabajo más detallados en el trabajo pendiente, pero
ningún otro cambio en las prioridades.
Si una carga de trabajo no es estratégica pero es compatible con plataformas de hospedaje de
aplicaciones modernas basadas en la nube, puede ser aconsejable realizar una refactorización
secundaria en la aplicación para implementarla como una aplicación moderna. Esto puede contribuir
al ahorro general al disminuir los requisitos de licencias del SO y de IaaS generales de la migración a
la nube.
Si una carga de trabajo es una aplicación de terceros y no hay planes de usar los datos de esa carga de
trabajo en una innovación de nivel inferior, puede ser mejor dejarla como una opción de rehospedaje
en el trabajo pendiente.
Estas preguntas no deben ser una extensión del análisis cualitativo realizado para cada carga de trabajo, sino
que están diseñadas para guiar una conversación que ayude a abordar la complejidad de una cartera no
equilibrada.
Cambios del proceso de migración
Durante la migración, las actividades de equilibrio de cartera pueden tener un impacto negativo en la velocidad
de migración (la velocidad a la que se migran los recursos). Las instrucciones siguientes expandirán el motivo y
la manera de alinear el trabajo para impedir que se produzcan interrupciones en el esfuerzo de migración.
La racionalización de la cartera requiere diversos esfuerzos técnicos. Para los equipos de adopción en la nube, es
tentador hacer coincidir esa diversidad de la cartera dentro de los esfuerzos de migración. Las partes
interesadas de la empresa piden que un solo equipo de adopción de la nube aborde todo el trabajo pendiente
de la migración. Este rara vez es un enfoque aconsejable y, en muchos casos, puede ser contraproducente.
Estos distintos esfuerzos se deben dividir entre dos o más equipos de adopción de la nube. Cuando se usa un
modelo de dos equipos como modo de ejecución de ejemplo, el Equipo 1 es el equipo de migración y el Equipo
2, el de innovación. En el caso de esfuerzos de mayor tamaño, estos equipos se podrían segmentar aún más
para abordar otros enfoques como los esfuerzos de reemplazo/PaaS o refactorización secundaria. A
continuación, se describen las aptitudes y los roles que se necesitan para rehospedaje, refactorización o
refactorización secundaria:
Rehospedaje: el rehospedaje requiere que los miembros del equipo implementen cambios centrados en la
infraestructura. Por lo general, se usa una herramienta como Azure Site Recovery para migrar máquinas
virtuales u otros recursos a Azure. Este trabajo se alinea correctamente con los implementadores de TI o los
administradores de centros de datos. El equipo de migración a la nube está bien estructurado para entregar este
trabajo a gran escala. Este es el enfoque más rápido para migrar los recursos existentes en la mayoría de los
escenarios.
Refactorización: la refactorización requiere que los miembros del equipo modifiquen el código fuente,
cambien la arquitectura de una aplicación o adopten servicios en la nube nuevos. Por lo general, este esfuerzo
usaría herramientas de desarrollo, como Visual Studio, y herramientas de canalización de implementación,
como Azure DevOps, para volver a implementar aplicaciones modernizadas en Azure. Este trabajo se alinea
correctamente con los roles de desarrollo de aplicaciones o con los roles de desarrollo de canalizaciones de
DevOps. El equipo de innovación en la nube está mejor estructurado para entregar este trabajo. Este enfoque
podría tardar más en reemplazar los recursos existentes por los recursos en la nube, pero las aplicaciones
pueden aprovechar las características nativas de la nube.
Refactorización secundaria: algunas aplicaciones se pueden modernizar con la refactorización secundaria en
el nivel de datos o el de aplicación. Este trabajo requiere que los miembros del equipo implementen datos en las
plataformas de datos basadas en la nube o hagan cambios de configuración menores en la aplicación. Esto
puede requerir un respaldo limitado de los expertos en el desarrollo de aplicaciones o datos. Sin embargo, este
trabajo es similar al que realizan los implementadores de TI al implementar aplicaciones de terceros. Este
trabajo se puede alinear fácilmente con el equipo de migración a la nube o con el de estrategia en la nube. Si
bien este esfuerzo no es tan rápido como una migración de rehospedaje, demora menos en ejecutarse que los
esfuerzos de refactorización.
Durante la migración, los esfuerzos se deben segmentar de las tres maneras mencionadas y debe ejecutarlos el
equipo adecuado en la iteración correspondiente. Aunque debe diversificar la cartera, asegúrese también de que
los esfuerzos estén bien dirigidos y segregados.
Pasos siguientes
Comprenda cómo las decisiones de mercados globales pueden afectar a su recorrido de transformación.
Descripción de los mercados globales
¿Cómo afectarán las decisiones de mercados
globales al recorrido de transformación?
La nube abre nuevas oportunidades para operar a escala global. Las barreras para las operaciones globales se
reducen significativamente al permitir a las empresas implementar activos en el mercado sin necesidad de
realizar fuertes inversiones en nuevos centros de datos. Desafortunadamente, esto también agrega una gran
complejidad desde una perspectiva técnica y legal.
Soberanía de los datos

Muchas regiones geopolíticas han establecido leyes de soberanía de datos. Estas regulaciones restringen dónde
se pueden almacenar los datos, qué datos pueden abandonar el país de origen y qué datos se pueden recopilar
sobre los ciudadanos de esa región. Antes de trabajar con cualquier solución basada en la nube en una zona
geográfica extranjera, debe saber cómo administra la soberanía de los datos el proveedor de nube. Para más
información sobre el enfoque de Azure para cada zona geográfica, consulte las zonas geográficas de Azure. Para
más información sobre el cumplimiento en Azure, consulte Privacidad en Microsoft en el centro de confianza de
Microsoft.
En el resto de este artículo, se da por supuesto que el asesor legal ha revisado y aprobado las operaciones en un
país extranjero.
Unidades de negocio
Es importante conocer qué unidades de negocio operan en países extranjeros y qué países se ven afectados.
Esta información se usará para diseñar soluciones para el hospedaje, la facturación y las implementaciones en el
proveedor de la nube.
Patrones de uso de empleados

Es importante conocer cómo los usuarios globales acceden a las aplicaciones que no están hospedadas en el
mismo país que el usuario. Las redes de área extensa (WAN) globales enrutan a los usuarios según los contratos
de red existentes. En los entornos locales tradicionales, algunas restricciones limitan el diseño de WAN. Estas
restricciones pueden dar lugar a experiencias de usuario deficientes si no se comprenden correctamente antes
de la adopción de la nube.
En un modelo en la nube, el Internet de los productos también abre muchas opciones nuevas. La comunicación
de la distribución de los empleados en varias zonas geográficas puede ayudar al equipo de adopción de la nube
a diseñar soluciones WAN que crean experiencias de usuario positivas y a reducir potencialmente los costos de
red.
Patrones de uso de usuarios externos

Es igualmente importante comprender los patrones de uso de los usuarios externos, como los clientes o
asociados. De forma muy similar a los patrones de uso de los empleados, los patrones de uso de usuarios
externos pueden afectar negativamente al rendimiento de las implementaciones en la nube. Si una base de
usuarios grande o crítica reside en un país extranjero, podría ser aconsejable incluir una estrategia de
implementación global en el diseño de la solución global.
Pasos siguientes
Obtenga información sobre las aptitudes necesarias durante la fase de creación de estrategia del recorrido de
Aptitudes necesarias durante la fase de creación de estrategia
Definición de una estrategia de seguridad
Los objetivos principales de una organización de seguridad no cambian con la adopción de servicios en la nube,
pero el modo en que se logran esos objetivos sí lo hará. Los equipos de seguridad deben seguir centrándose en
reducir el riesgo empresarial de los ataques y trabajar para obtener las garantías de disponibilidad, integridad y
confidencialidad integradas en todos los datos y sistemas de información.
Modernización de la estrategia de seguridad

Los equipos de seguridad deberán modernizar las estrategias, las arquitecturas y la tecnología a medida que la
organización adopte la nube y la administre con el tiempo. Aunque el tamaño y el número de cambios pueden
parecer desalentadores inicialmente, la modernización del programa de seguridad permite a la seguridad
perder algunas cargas desagradables asociadas a los enfoques heredados. Una organización puede trabajar
temporalmente con la estrategia heredada y las herramientas, pero este enfoque es difícil de mantener con el
ritmo de cambio en la nube y el entorno de amenazas:
Es probable que los equipos de seguridad dejen de tomar decisiones sobre la adopción de la nube si adoptan
una actitud heredada de seguridad "distante" donde la respuesta comienza siempre por "no" (en lugar de
trabajar junto con los equipos de TI y empresariales para reducir el riesgo al habilitar la empresa).
Los equipos de seguridad tendrán dificultades a la hora de detectar ataques en la nube y defenderse contra
ellos si solo usan herramientas locales heredadas y se adhieren exclusivamente a la única doctrina del
perímetro de red para todas las defensas y la supervisión. La defensa en el escalado en la nube exige el uso
de funcionalidades de automatización y detección nativas de la nube y la presentación de un perímetro de
identidad para ayudar a supervisar y proteger recursos móviles y en la nube.
Dado que esta transformación puede ser significativa, se recomienda que los equipos de seguridad adopten un
enfoque ágil para la modernización de la seguridad que ponga al día rápidamente los aspectos más críticos de
la estrategia y posteriormente vaya mejorando de forma continua e incremental.
Seguridad de la nube y desde la nube
A medida que la organización adopte servicios en la nube, los equipos de seguridad trabajarán en pro de dos
objetivos principales:
Seguridad *de* la nube (protección de recursos en la nube): la seguridad se debe integrar en el
planeamiento y funcionamiento de los servicios en la nube para asegurarse de que esas garantías de
seguridad básica se aplican de forma coherente en todos los recursos.
Seguridad *desde* la nube (uso de la nube para transformar la seguridad): la seguridad debe
empezar inmediatamente a planear y pensar en cómo usar las tecnologías en la nube para modernizar los
procesos y las herramientas de seguridad, especialmente las herramientas de seguridad integradas de forma
nativa. Cada vez son más las herramientas de seguridad que se hospedan en la nube y proporcionan
funcionalidades que son complejas o imposibles de llevar a cabo en un entorno local.
Muchas organizaciones empiezan a tratar los recursos en la nube como otro centro de datos virtual, un punto
de partida eficaz para la seguridad de la nube. A medida que las organizaciones se modernizan con la seguridad
de la nube, la mayoría superarán rápidamente este modelo de pensamiento. La protección de un centro de
datos definido por software mediante herramientas hospedadas en la nube habilita funcionalidades más allá de
lo que pueden ofrecer los modelos locales:
Habilitación y escalado rápidos de funcionalidades de seguridad.
Detección de higiene de configuración de seguridad e inventario de recursos altamente eficaz.
Evaluación continua de la posición y los controles de seguridad de la organización.
Detección de amenazas ampliamente mejorada que utiliza grandes repositorios de inteligencia sobre
amenazas y las funcionalidades de procesamiento y almacenamiento prácticamente ilimitadas de la nube.
El nivel adecuado de fricción de seguridad
La seguridad crea fricción de forma natural que ralentiza los procesos. Es fundamental identificar qué elementos
son correctos en sus procesos de TI y DevOps y cuáles no:
Fricción sin problemas: al igual que la resistencia en el ejercicio fortalece un músculo, la integración del
nivel adecuado de fricción de seguridad fortalece el sistema o la aplicación forzando el pensamiento crítico
en el momento adecuado. Normalmente, esto se traduce en que se tiene en cuenta cómo y por qué un
atacante podría intentar poner en peligro una aplicación o un sistema durante el diseño, y se revisan,
identifican y corrigen de forma ideal posibles vulnerabilidades que puede explotar un atacante en el código
de software, las configuraciones o las prácticas operativas.
Fricción con problemas: afecta negativamente a una parte del valor mayor que la parte que protege. Esto
suele ocurrir cuando los errores de seguridad generados por las herramientas tienen una alta tasa de falsos
positivos (como falsas alarmas) o cuando el esfuerzo por detectar o corregir las incidencias de seguridad
supera con creces el posible impacto de un ataque.
Responsabilidades independientes e integradas
Proporcionar garantías de disponibilidad, integridad y confidencialidad requiere que los expertos en seguridad
usen funciones de seguridad dedicadas y trabajen estrechamente con otros equipos de la organización:
Funciones de seguridad únicas: los equipos de seguridad realizan funciones independientes que no se
encuentran en ningún otro lugar de la organización, como operaciones de seguridad, administración de
vulnerabilidades y otras funciones.
Integración de la seguridad en otras funciones: los equipos de seguridad también sirven como
expertos en la materia en otros equipos y funciones de la organización que impulsan iniciativas
empresariales, evalúan el riesgo, diseñan o desarrollan aplicaciones y usan sistemas de TI. Los equipos de
seguridad dan consejos a estos equipos mediante experiencia y contexto sobre los atacantes, los métodos de
ataque y las tendencias, las vulnerabilidades que podrían permitir el acceso no autorizado y las opciones de
pasos de mitigación o soluciones alternativas y sus posibles ventajas o riesgos. Esta función de seguridad es
similar a la de una función de calidad, ya que se entrelazará en muchos lugares grandes y pequeños a favor
de un solo resultado.
La ejecución de estas responsabilidades mientras se está al tanto del rápido ritmo de cambio en la nube y la
transformación de la empresa requiere que los equipos de seguridad modernicen sus herramientas, tecnologías
y procesos.
Transformaciones, actitudes y expectativas

Muchas organizaciones administran una cadena de varias transformaciones simultáneas. Estas
transformaciones internas se inician normalmente porque casi todos los mercados externos se transforman
para satisfacer nuevas preferencias de los clientes para tecnologías móviles y en la nube. Las organizaciones
suelen hacer frente a la amenaza competitiva de nuevas startups y la transformación digital de los competidores
tradicionales que pueden sorprender al mercado.
El proceso de transformación interna suele incluir lo siguiente:
Transformación digital de la empresa para capturar nuevas oportunidades y mantenerse competitiva
frente a las startups nativas digitales.
Transformación tecnológica de la organización de TI para apoyar la iniciativa con servicios en la nube,
prácticas de desarrollo modernizadas y cambios relacionados.
Transformación de seguridad para adaptarse a la nube y abordar simultáneamente un entorno de
amenazas cada vez más sofisticado.
El conflicto interno puede ser costoso
El cambio crea estrés y conflictos, lo que puede paralizar la toma de decisiones. Esto es especialmente cierto en
lo que respecta a la seguridad, donde la responsabilidad del riesgo de seguridad suele recaer erróneamente en
los expertos en la materia (equipos de seguridad), en lugar de en los propietarios de los recursos (propietarios
empresariales) que se encargan de los resultados empresariales y todos los demás tipos de riesgo. Esta
responsabilidad de destinatario incorrecto suele deberse a que todas las partes interesadas ven erróneamente la
seguridad como un problema técnico o absoluto que se debe resolver, en lugar de un riesgo continuo dinámico
como el espionaje corporativo y otras actividades criminales tradicionales.
Durante este tiempo de transformación, los responsables de todos los equipos deben trabajar activamente para
reducir los conflictos que pueden ser perjudiciales para los proyectos críticos e incentivar a los equipos para que
omitan la mitigación de riesgos de seguridad. Un conflicto interno entre los equipos puede dar lugar a:
Mayor riesgo de seguridad como incidentes de seguridad evitables o mayores daños empresariales
derivados de ataques (especialmente cuando los equipos se sienten frustrados por la seguridad y omiten los
procesos normales, o cuando los atacantes omiten fácilmente los enfoques de seguridad obsoletos).
Impacto negativo en la empresa o misión , como cuando los procesos empresariales no se habilitan o
actualizan lo suficientemente rápido para satisfacer las necesidades del mercado (normalmente, cuando los
procesos de seguridad contienen iniciativas empresariales clave).
Es fundamental estar al corriente del estado de la relación dentro de los equipos y entre ellos para ayudarles a
navegar por el panorama cambiante que podría dejar inseguros e inquietos a los miembros valiosos. Paciencia,
empatía y educación sobre estas actitudes, y el potencial positivo del futuro ayudará a sus equipos a navegar
mejor por este período, promoviendo resultados de seguridad buenos para la organización.
Los responsables pueden ayudar a impulsar un cambio cultural con pasos proactivos concretos como:
Modelar públicamente el comportamiento que esperan de sus equipos.
Ser transparente con respecto a los desafíos de los cambios, incluido el resaltado de sus propias dificultades
para adaptarse.
Recordar periódicamente a los equipos la urgencia e importancia de modernizar e integrar la seguridad.
Resistencia de ciberseguridad
Muchas estrategias de seguridad clásicas se han centrado únicamente en la prevención de ataques, un enfoque
que es insuficiente para las amenazas modernas. Los equipos de seguridad deben asegurarse de que su
estrategia va más allá de esto y también permite una rápida detección de ataques, respuesta y recuperación
para aumentar la resistencia. Las organizaciones deben suponer que los atacantes pondrán en peligro algunos
recursos (en ocasiones, esto se conoce como supuesto de infracción) y trabajar para asegurarse de que los
recursos y diseños técnicos se equilibran entre la prevención y la administración de ataques (en lugar del
enfoque predeterminado típico consistente en intentar solamente prevenir ataques).
Muchas organizaciones ya se encuentran en este recorrido, puesto que han estado administrando el aumento
constante del volumen y la sofisticación de los ataques en los últimos años. Este recorrido suele iniciarse con el
primer incidente importante, que puede ser un evento emocional en el que los usuarios pierden su anterior
sensación de invulnerabilidad y seguridad. Aunque no es tan grave como la pérdida de una vida, este evento
puede desencadenar emociones similares empezando por la negación y finalizando en última instancia con la
aceptación. Para algunas personas, esta suposición de "error" puede ser difícil de aceptar al principio, pero tiene
claros paralelismos con el principio de ingeniería "a prueba de errores", y la suposición permite que los equipos
se centren en una mejor definición de éxito: resistencia.
Las funciones del marco de ciberseguridad de NIST sirven como guía útil sobre cómo equilibrar las inversiones
entre las actividades complementarias de identificación, protección, detección, respuesta y recuperación en una
estrategia resistente.
Más información sobre la resistencia de ciberseguridad y los objetivos principales de los controles de
ciberseguridad se explica en Cómo mantener el riesgo de su organización inactivo.
Cómo cambia la nube la seguridad
Desplazarse a la nube en aras de la seguridad es algo más que un simple cambio tecnológico, es un cambio
tecnológico generacional similar al cambio de sistemas centrales a escritorios y a servidores empresariales.
Navegar correctamente por este cambio requiere cambios fundamentales en las expectativas y la actitud de los
equipos de seguridad. Adoptar las actitudes y expectativas adecuadas reducirá el conflicto dentro de la
organización y aumentará la eficacia de los equipos de seguridad.
Aunque podrían formar parte de cualquier plan de modernización de la seguridad, el rápido ritmo de cambio en
la nube hace que adoptarlas sea una prioridad urgente.
Asociación con objetivos compar tidos. En esta época de decisiones rápidas y evolución de procesos
constante, la seguridad ya no puede adoptar un enfoque "distante" para la aprobación o la denegación de
cambios en el entorno. Los equipos de seguridad deben colaborar estrechamente con los equipos de TI y
empresariales para establecer objetivos compartidos en torno a la productividad, la confiabilidad y la
seguridad, y trabajar colectivamente con esos asociados para lograrlos.
Esta asociación es la forma definitiva de "desplazamiento a la izquierda"—el principio de integración de la
seguridad anteriormente en los procesos para que la corrección de las incidencias de seguridad resulte
más sencilla y eficaz. Esto requiere un cambio cultural por parte de todos los implicados (seguridad,
empresa y TI), lo que a su vez requiere que cada uno de ellos aprenda la cultura y las normas de otros
grupos, al mismo tiempo que enseña las suyas a otras personas.
Los equipos de seguridad deben:
Aprender los objetivos empresariales y de TI, por qué es importante cada uno de ellos y cómo
piensan lograrlos a medida que se transforman.
Compar tir por qué la seguridad es importante en el contexto de esos objetivos y riesgos
empresariales, qué pueden hacer otros equipos para cumplir los objetivos de seguridad y cómo deben
hacerlo.
Aunque no es una tarea sencilla, es fundamental para proteger la organización y sus recursos de forma
sostenible. Es probable que esta asociación dé lugar a compromisos correctos donde inicialmente solo se
puedan cumplir los objetivos mínimos empresariales, de seguridad y de confiabilidad, pero mejoren sin
cesar y de forma incremental con el tiempo.
La seguridad es un riesgo continuo, no un problema. No puede "resolver" el delito. En esencia, la
seguridad es simplemente una disciplina de administración de riesgos que se centra en las acciones
malintencionadas de los seres humanos en lugar de los eventos naturales. Al igual que todos los riesgos,
la seguridad no es un problema que se pueda corregir mediante una solución, es una combinación de la
probabilidad y el impacto de los daños de un evento negativo, un ataque. Es más similar a las actividades
criminales y de espionaje corporativo tradicionales donde las organizaciones se enfrentan a atacantes
humanos motivados que tienen incentivos financieros para atacar con éxito la organización.
El éxito en la productividad o la seguridad requiere ambas. Una organización debe centrarse en
la seguridad y la productividad en el entorno actual de "innovar o morir". Si la organización no es
productiva ni impulsa nuevas innovaciones, es posible que pierda competitividad en Marketplace,
haciendo que se debilite financieramente o se produzca un error en él en última instancia. Si la
organización no es segura y pierde el control de sus recursos frente a los atacantes, es posible que pierda
competitividad en Marketplace, haciendo que se debilite financieramente y se produzca un error en él en
última instancia.
Nadie es perfecto. Ninguna organización es perfecta al adoptar la nube, ni siquiera Microsoft. Los
equipos de TI y de seguridad de Microsoft se enfrentan a muchos de los mismos desafíos que nuestros
clientes, como, por ejemplo, averiguar cómo estructurar los programas correctamente, equilibrar el
software heredado complementario con la innovación vanguardista complementaria, e incluso las
brechas tecnológicas de los servicios en la nube. A medida que estos equipos aprenden a usar y proteger
mejor la nube, comparten activamente sus lecciones aprendidas a través de documentos como este,
junto con otros del sitio de presentación de TI, a la vez que proporcionan comentarios continuamente a
nuestros equipos de ingeniería y proveedores externos para mejorar sus ofertas.
En función de nuestra experiencia, se recomienda que los equipos se mantengan en un estándar de
aprendizaje y mejora continuos en lugar de un estándar de perfección.
Opor tunidad en la transformación. Es importante ver la transformación digital como una
oportunidad positiva de seguridad. Aunque es fácil ver los posibles inconvenientes y el riesgo de este
cambio, es fácil perder la oportunidad masiva de reinventar el rol de seguridad y ganar un puesto en la
tabla donde se toman las decisiones. La asociación con la empresa puede dar lugar a una mayor
financiación de la seguridad, reducir los esfuerzos repetitivos innecesarios en pro de la seguridad y hacer
que el trabajo en seguridad sea más agradable, ya que se estará más conectado a la misión de la
organización.
Adopción del modelo de responsabilidad compartida

El hospedaje de servicios de TI en la nube divide las responsabilidades operativas y de seguridad de las cargas
de trabajo entre el proveedor de nube y el inquilino del cliente, lo que crea una asociación de facto con
responsabilidades compartidas. Todos los equipos de seguridad deben estudiar y comprender este modelo de
responsabilidad compartida para adaptar sus procesos, herramientas y conjuntos de aptitudes al nuevo mundo.
Esto ayudará a evitar la creación accidental de brechas o superposiciones en su posición de seguridad, dando
lugar a riesgos de seguridad o recursos desperdiciados.
En este diagrama se muestra cómo se distribuirán las responsabilidades de seguridad entre los proveedores de
nube y las organizaciones de clientes en la nube en una asociación de facto:
Puesto que hay diversos modelos de servicios en la nube, las responsabilidades de cada carga de trabajo
variarán en función de si la carga de trabajo está hospedada en una implementación de software como servicio
(SaaS), plataforma como servicio (PaaS), infraestructura como servicio (IaaS) o bien en un centro de datos local.
Creación de iniciativas de seguridad

En este diagrama se muestran las tres iniciativas de seguridad principales que deben seguir la mayoría de los
programas de seguridad para ajustar su estrategia de seguridad y sus objetivos para la nube:
La creación de una posición de seguridad resistente en la nube requiere varios enfoques complementarios
paralelos:
Confiar pero verificar : en el caso de las responsabilidades llevadas a cabo por el proveedor de nube,
las organizaciones deben adoptar un enfoque de "confiar pero verificar". Las organizaciones deben
evaluar las prácticas de seguridad de sus proveedores de nube y los controles de seguridad que ofrecen
para asegurarse de que el proveedor de nube satisface las necesidades de seguridad de la organización.
Modernización de la seguridad de la infraestructura y aplicaciones: en el caso de los elementos
técnicos bajo el control de la organización, dé prioridad a la modernización de las herramientas de
seguridad y los conjuntos de aptitudes asociados para minimizar las brechas de la cobertura para
proteger los recursos de la nube. Esto consta de dos esfuerzos complementarios diferentes:
Seguridad de la infraestructura: las organizaciones deben usar la nube para modernizar su
estrategia de protección y supervisión de los componentes comunes que usan muchas
aplicaciones; como, por ejemplo, sistemas operativos, redes e infraestructura de contenedores.
Estas funcionalidades de la nube a menudo pueden incluir la administración de componentes de
infraestructura en entornos locales y de IaaS. La optimización de esta estrategia es importante, ya
que esta infraestructura es una dependencia de las aplicaciones y los datos que se ejecutan en ella,
que a menudo habilitan procesos empresariales críticos y almacenan datos empresariales críticos.
Seguridad de la aplicación: las organizaciones también deben modernizar la manera en que
protegen las aplicaciones únicas y la tecnología desarrollada por o para su organización. Esta
disciplina cambia rápidamente con la adopción de procesos de DevOps ágiles, el aumento del uso
de componentes de código abierto y la incorporación de API y servicios en la nube para
reemplazar componentes de aplicaciones o interconectar aplicaciones.
Obtener este derecho es fundamental, ya que estas aplicaciones a menudo habilitan procesos
empresariales críticos y almacenan datos empresariales críticos.
Perímetro moderno: las organizaciones deben tener un enfoque completo para la protección de
datos en todas las cargas de trabajo. Asimismo, deben establecer un perímetro moderno de
controles de identidad coherentes administrados centralmente para proteger sus datos,
dispositivos y cuentas. Esto se ve notablemente influenciado por una estrategia de confianza cero
que se explica con detalle en Módulo 3 del taller para CISO.
Seguridad y confianza
El uso de la palabra confianza en material de seguridad puede ser confuso. En esta documentación se hace
referencia a ella de dos maneras que ilustran las aplicaciones útiles de este concepto:
Confianza cero es un término común del sector para un enfoque estratégico de seguridad que supone que
una red corporativa o de intranet es hostil (digna de confianza cero) y diseña la seguridad en consecuencia.
Confiar pero verificar es una expresión que captura la esencia de dos organizaciones diferentes que trabajan
juntas por un objetivo común a pesar de tener otros intereses potencialmente divergentes. Esto captura de
manera concisa muchos de los matices de las primeras fases de la asociación con un proveedor de nube
comercial para organizaciones.
Un proveedor de nube y sus prácticas y procesos pueden ser responsables de cumplir los requisitos
contractuales y normativos, y podrían ganar o perder confianza. Una red es una conexión no dinámica que no
puede hacer frente a las consecuencias si la usan los atacantes (al igual que no se puede hacer responsable a
una carretera o un automóvil de los delincuentes que hacen uso de ellos).
De qué manera la nube está cambiando las relaciones y

responsabilidades de seguridad
Al igual que sucede con transiciones anteriores a una nueva generación de tecnología, como, por ejemplo, la
informática de escritorio y la informática de servidores empresariales, el cambio a la informática en la nube está
interrumpiendo relaciones, roles, responsabilidades y conjuntos de aptitudes consolidados. Las descripciones de
los trabajos a las que nos hemos acostumbrado en las últimas décadas no se asignan correctamente a una
empresa que ahora incluye funcionalidades de la nube. A medida que el sector trabaja colectivamente para
normalizar un nuevo modelo, las organizaciones tendrán que centrarse en proporcionar tanta clarificación como
sea posible para ayudar a administrar la incertidumbre de la ambigüedad durante este período de cambio.
Los equipos de seguridad se ven afectados por estos cambios en la empresa y en la tecnología que admiten, así
como por sus propios esfuerzos de modernización interna para centrarse mejor en los actores de amenazas. Los
atacantes evolucionan activamente para buscar de forma constante los puntos débiles más sencillos de las
personas, los procesos y la tecnología de la organización con el fin de aprovecharlos, y la seguridad debe
desarrollar funcionalidades y aptitudes para abordar estos ángulos.
En esta sección se describen las relaciones clave que cambian con frecuencia en el recorrido a la nube, incluidas
las lecciones aprendidas para minimizar el riesgo y adoptar las oportunidades de mejora:
Entre las par tes interesadas del negocio y la seguridad: los líderes de seguridad deberán
asociarse cada vez más con los líderes empresariales para que las organizaciones puedan reducir el
riesgo. Los líderes de seguridad deben apoyar la toma de decisiones empresariales como expertos en la
materia de seguridad (SME) y deben procurar convertirse en asesores de confianza para estos líderes
empresariales. Esta relación ayudará a asegurarse de que los líderes empresariales tienen en cuenta los
riesgos de seguridad a la hora de tomar decisiones empresariales, informar sobre la seguridad de las
prioridades empresariales y ayudar a garantizar que se dé prioridad a las inversiones en seguridad
adecuadamente junto con otras inversiones.
Entre los miembros de los equipos y los líderes de seguridad: los líderes de seguridad deben
recuperar esta información de los líderes empresariales y ponerla a disposición de sus equipos para
orientar sus prioridades de inversión.
Al establecer un tono de cooperación con los líderes empresariales y sus equipos en lugar de una
relación "distante" clásica, los líderes de seguridad pueden evitar una dinámica conflictiva que obstaculice
los objetivos de seguridad y productividad.
Los líderes de seguridad deben procurar proporcionar claridad a su equipo sobre cómo administrar sus
decisiones diarias acerca de los compromisos de seguridad y productividad, ya que esto puede ser nuevo
para muchos de los miembros de sus equipos.
Entre los equipos de infraestructura y de la aplicación (y los proveedores de nube): esta
relación está experimentando cambios significativos debido a varias tendencias en el sector de seguridad
y de TI destinadas a aumentar la velocidad de innovación y la productividad de los desarrolladores.
Las normas y funciones organizativas anteriores se han interrumpido, pero siguen emergiendo nuevas
normas y funciones, por lo que se recomienda aceptar la ambigüedad, mantenerse al tanto de las
opiniones actuales y experimentar con lo que funciona para las organizaciones hasta conseguirlo. No se
recomienda adoptar una estrategia de permanecer a la expectativa en este espacio, ya que podría colocar
a la organización en una situación de desventaja competitiva importante.
Estas tendencias desafían las normas tradicionales para los roles y las relaciones de las aplicaciones y la
infraestructura:
Disciplinas de fusión de DevOps: en su estado ideal, esto crea eficazmente un solo equipo
altamente funcional que combina ambos conjuntos de experiencia en la materia para innovar, publicar
actualizaciones y resolver incidencias (de seguridad y de otra índole) con rapidez. Aunque este estado
ideal tardará un tiempo en lograrse y las responsabilidades que implica siguen siendo ambiguas, las
organizaciones ya han disfrutado de algunas ventajas de las versiones rápidas debido a este enfoque
cooperativo. Microsoft recomienda integrar la seguridad en este ciclo para ayudar a aprender esas
referencias culturales, compartir aprendizajes de seguridad y trabajar por un objetivo común de
lanzamiento rápido de aplicaciones seguras y confiables.
Conversión de la creación de contenedores en un componente de infraestructura común:
tecnologías como Docker, Kubernetes y similares hospedan y organizan cada vez más las aplicaciones.
Estas tecnologías simplifican el desarrollo y las versiones al abstraer muchos elementos de la
instalación y configuración del sistema operativo subyacente.
Aunque los contenedores comenzaron como una tecnología de desarrollo de aplicaciones administrada
por los equipos de desarrollo, se está convirtiendo en un componente de infraestructura común cada vez
más centrado en los equipos de infraestructura. Esta transición sigue en curso en muchas organizaciones,
pero es una dirección natural y positiva. Muchos de los desafíos actuales se resolverán mejor con
conjuntos de aptitudes de infraestructura tradicionales como la administración de la capacidad,
almacenamiento y redes.
Los equipos de infraestructura y los miembros de los equipos de seguridad que los apoyan deben recibir
entrenamiento, procesos y herramientas para ayudar a administrar, supervisar y proteger esta tecnología.
Ser vicios de aplicación en la nube y sin ser vidor : una de las tendencias dominantes del
sector actualmente es reducir la cantidad de tiempo y el trabajo de desarrollo necesarios para
compilar o actualizar aplicaciones.
Los desarrolladores también usan cada vez más servicios en la nube para:
Ejecutar código en lugar de hospedar aplicaciones en máquinas virtuales (VM) y servidores.
Proporcionar funciones de aplicación en lugar de desarrollar sus propios componentes. Esto ha
dado lugar a un modelo sin servidor que usa los servicios en la nube existentes para las
funciones comunes. El número y la variedad de servicios en la nube (y su ritmo de innovación)
también ha superado la capacidad de los equipos de seguridad de evaluar y aprobar el uso de
esos servicios, lo que les permite elegir entre permitir a los desarrolladores usar cualquier
servicio, intentar evitar que los equipos de desarrollo usen servicios no aprobados o intentar
encontrar una mejor manera.
Aplicaciones sin código y Power Apps: otra tendencia emergente es el uso de tecnologías
sin código como Microsoft Power Apps. Esta tecnología permite a los usuarios sin
conocimientos de codificación crear aplicaciones que logren resultados empresariales. Debido
a este potencial de alto valor y baja fricción, esta tendencia tiene el potencial de aumentar la
popularidad rápidamente y sería aconsejable que los profesionales de seguridad
comprendieran sus implicaciones con rapidez. Los esfuerzos de seguridad deben centrarse en
las áreas en las que un usuario podría cometer un error en la aplicación, concretamente en el
diseño de los permisos de aplicación y recurso a través del modelado de amenazas, los
componentes de aplicaciones, las interacciones y relaciones, y los permisos del rol.
Entre los desarrolladores y los autores de componentes de código abier to: los desarrolladores
también están aumentando la eficacia mediante el uso de bibliotecas y componentes de código abierto
en lugar de desarrollar sus propios componentes. Esto aporta valor a través de la eficacia, pero también
presenta riesgos de seguridad creando una dependencia externa y un requisito para mantener y aplicar
revisiones correctamente a esos componentes. Los desarrolladores asumen eficazmente el riesgo de
seguridad y otros errores cuando usan estos componentes y deben asegurarse de que hay un plan para
mitigarlos en los mismos estándares que el código que desarrollarían.
Entre las aplicaciones y los datos: la línea entre la seguridad de los datos y las aplicaciones no está
siempre tan clara, y las nuevas regulaciones están creando una necesidad de cooperación más estrecha
entre los equipos de privacidad y datos, y los equipos de seguridad:
Algoritmos de aprendizaje automático (Machine Learning): los algoritmos de aprendizaje
automático son similares a las aplicaciones en que están diseñados para procesar datos a fin de
crear un resultado. Las principales diferencias son:
Aprendizaje automático de alto valor : el aprendizaje automático a menudo confiere
una ventaja competitiva importante y a menudo se considera una propiedad intelectual
confidencial y un secreto comercial.
Marca de sensibilidad: el aprendizaje automático supervisado se ajusta mediante
conjuntos de datos, imprimiéndose las características del conjunto de datos en el algoritmo.
Debido a esto, el algoritmo ajustado se puede considerar confidencial debido al conjunto de
datos usado para entrenarlo. Por ejemplo, el entrenamiento de un algoritmo de aprendizaje
automático para buscar bases militares secretas en un mapa con un conjunto de datos de
bases militares secretas lo convertirían en un recurso confidencial.
NOTE
No todos los ejemplos son obvios, por lo que es fundamental reunir a un equipo con las partes
interesadas adecuadas de los equipos de ciencia de datos, las partes interesadas del negocio, los equipos
de seguridad, los equipos de privacidad, etc. Estos equipos deben tener la responsabilidad de cumplir los
objetivos comunes de innovación y responsabilidad. Deben resolver incidencias habituales como, por
ejemplo, cómo y dónde almacenar copias de datos en configuraciones no seguras, cómo clasificar
algoritmos, así como cualquier preocupación de sus organizaciones.
Microsoft ha publicado nuestros principios de inteligencia artificial responsable para orientar a nuestros
propios equipos y a nuestros clientes.
Propiedad y privacidad de los datos: normativas como RGPD han aumentado la visibilidad
de las incidencias de datos y las aplicaciones. Los equipos de la aplicación ahora pueden
controlar, proteger y realizar un seguimiento de los datos confidenciales en un nivel
comparable al seguimiento de los datos financieros realizado por los bancos y las instituciones
financieras. Los propietarios de los datos y los equipos de la aplicación deben generar una idea
completa de qué almacenan las aplicaciones de datos y qué controles son necesarios.
Entre las organizaciones y los proveedores de nube: a medida que las organizaciones hospedan
cargas de trabajo en la nube, están estableciendo una relación empresarial con cada uno de esos
proveedores de nube. El uso de servicios en la nube suele aportar valor empresarial, como, por ejemplo:
Aceleración de las iniciativas de transformación digital reduciendo el tiempo de
comercialización de las nuevas funcionalidades.
Aumento del valor de las actividades de seguridad y de TI al liberar a los equipos para que
se centren en actividades de valor superior (alineadas con la empresa) en lugar de tareas estándar
de nivel inferior que proporcionan los servicios en la nube de forma más eficaz en su nombre.
Mayores confiabilidad y capacidad de respuesta: la mayoría de las nubes modernas
también tienen un tiempo de actividad alto en comparación con los centros de datos locales
tradicionales y han demostrado que pueden escalarse rápidamente (como, por ejemplo, durante la
pandemia de la COVID-19) y proporcionar resistencia tras eventos naturales como rayos (que
habrían mantenido muchos equivalentes locales durante mucho más tiempo).
Aunque resulta beneficioso, este cambio en la nube no está exento de riesgo. A medida que las
organizaciones adoptan servicios en la nube, deben tener en cuenta posibles áreas de riesgo, entre
las que se incluyen las siguientes:
Continuidad empresarial y recuperación ante desastres: ¿se encuentra el proveedor de
nube en una buena situación financiera con un modelo de negocio con probabilidades de
sobrevivir y prosperar durante el uso del servicio por parte de la organización?, ¿ha establecido el
proveedor de nube aprovisionamientos para permitir la continuidad del cliente si el proveedor
experimenta algún error financiero o de otra índole, como, por ejemplo, proporcionar su código
fuente a los clientes o hacerlo de código abierto?
Para obtener más información y documentos sobre el estado financiero de Microsoft, consulte
Microsoft Investor Relations.
Seguridad: ¿sigue el proveedor de nube los procedimientos recomendados de seguridad del
sector?, ¿han validado esto organismos reguladores independientes?
Microsoft Cloud App Security permite detectar el uso de más de 16 000 aplicaciones en la nube
que se clasifican y puntúan en función de más de 70 factores de riesgo para proporcionar
visibilidad continua del uso de la nube, IT en la sombra y el riesgo que IT en la sombra
representa para la organización.
El portal de confianza del servicio de Microsoft pone las certificaciones de cumplimiento
normativo, los informes de auditoría, las pruebas de lápiz, etc., a disposición de los clientes.
Estos documentos incluyen muchos detalles de las prácticas de seguridad interna (en particular,
el informe SOC 2 tipo 2 y el plan de seguridad del sistema FedRAMP Moderate).
Competidor empresarial: ¿es el proveedor de nube un competidor empresarial importante en
su sector?, ¿cuenta con suficientes protecciones en el contrato de servicios en la nube u otros
medios para proteger su negocio frente a acciones potencialmente hostiles?
Revise este artículo para ver los comentarios sobre cómo evita Microsoft competir con los clientes
de la nube.
Nube múltiple: muchas organizaciones tienen una estrategia de nube múltiple intencional o de
facto. Podría ser un objetivo intencionado para reducir la dependencia de un solo proveedor o
tener acceso a las mejores funcionalidades exclusivas, pero también puede deberse a que los
desarrolladores eligieron sus servicios en la nube preferidos o servicios familiares, o bien a que la
organización adquirió otro negocio. Independientemente del motivo, esta estrategia puede
presentar riesgos y costos potenciales que se deben administrar, entre los que se incluyen:
Tiempo de inactividad de varias dependencias: los sistemas diseñados para confiar en
varias nubes se exponen a más orígenes de riesgo de tiempo de inactividad, ya que las
interrupciones en los proveedores de nube (o el uso que hace el equipo de ellos) podrían
provocar una interrupción de su negocio. Esta mayor complejidad del sistema también
aumentaría la probabilidad de que se produzcan eventos de interrupción, ya que es menos
probable que los miembros del equipo comprendan totalmente un sistema más complejo.
Poder de negociación: las organizaciones de mayor tamaño también deben considerar si
una estrategia de nube única (asociación/compromiso mutuo) o de nube múltiple (capacidad
para cambiar de negocio) logrará una mayor influencia sobre sus proveedores de nube para
que se dé prioridad a las solicitudes de característica de la organización.
Mayor sobrecarga de mantenimiento: los recursos de seguridad y de TI ya están
sobrecargados gracias a sus cargas de trabajo existentes y están al tanto de los cambios de una
plataforma de nube única. Cada plataforma adicional aumenta aún más esta sobrecarga y aleja
a los miembros del equipo de actividades de valor superior tales como la optimización del
proceso técnico para acelerar la innovación empresarial, la consulta con grupos empresariales
sobre un uso más eficaz de las tecnologías, etc.
Personal y entrenamiento: a menudo, las organizaciones no tienen en cuenta los requisitos
de personal necesarios para apoyar varias plataformas y el entrenamiento necesario para
mantener el conocimiento y la popularidad de las nuevas características que se publican con
rapidez.
Guía sobre la supervisión en la nube: Formulación
de una estrategia de supervisión
A medida que vaya realizando su transformación digital a la nube, es importante que planee y desarrolle una
estrategia de supervisión en la nube efectiva, en la cual participen desarrolladores, el personal de operaciones y
los ingenieros de infraestructura. La estrategia debe estar orientada al crecimiento, definirse mínimamente,
refinarse de forma iterativa y siempre debe alinearse con las necesidades de la empresa. Su resultado ofrece
una forma de operaciones ágiles centrada en torno a la capacidad de la organización de supervisar de forma
proactiva las complejas aplicaciones distribuidas de las que depende la empresa.
¿Por dónde empezar?

Para facilitar su recorrido hasta la nube, use las fases de creación de estrategia y planeamiento de Cloud
Adoption Framework. La supervisión influye y justifica las motivaciones, los resultados empresariales y las
iniciativas. Incluya la supervisión en las fases de creación de estrategia y planeamiento, las iniciativas y los
proyectos. Por ejemplo, examine la forma en la que el primer proyecto de adopción establece la administración
temprana de operaciones en Azure. Imagínese el aspecto que debe tener el modelo de funcionamiento en la
nube, incluido el rol de supervisión. La supervisión se ofrece mejor con un enfoque basado en el servicio, como
una función de operaciones, donde la supervisión es un servicio de consultoría y un proveedor de
conocimientos para los consumidores empresariales y de TI.
A continuación se muestran áreas importantes que influyen en gran medida en una estrategia de supervisión de
sonido:
Supervise el estado de las aplicaciones, en función de sus componentes y su relación con otras
dependencias. Comience con la plataforma de servicios en la nube, los recursos, la red y, por último, la
aplicación; para ello, recopile métricas y registros cuando proceda. En el modelo de nube híbrida, incluya
la infraestructura local y otros sistemas en los que se basa la aplicación.
Incluya la medición de la experiencia del usuario final en el plan de supervisión de rendimiento de las
aplicaciones; para ello, imite las interacciones típicas del cliente con la aplicación.
Asegúrese de que los requisitos de seguridad se corresponden con la directiva de cumplimiento de
seguridad de la organización.
Alinee las alertas con lo que se considera un incidente relevante y práctico (como advertencias y
excepciones) y alinee la gravedad con su significado después de la prioridad del incidente y la matriz de
escalado de urgencia.
Recopile solo las métricas y los registros que sean útiles, mensurables e identificables para la empresa y
la organización de TI.
Defina un plan de integración con las soluciones ITSM existentes, como Remedy o ServiceNow, para la
generación de incidentes o la supervisión ascendente. Determine qué alertas deben reenviarse, si se
requiere enriquecimiento de alertas para admitir requisitos de filtrado específicos, y cómo configurarlas.
Sepa quién necesita visibilidad, qué necesita ver y la forma de visualizar los elementos en función de sus
roles y responsabilidades.
En el centro de Operations Management, su organización de TI deberá establecer una gobernanza centralizada y
una delegación estricta sobre los enfoques necesarios para compilar, operar y administrar los servicios de TI.
Objetivos de la estrategia inicial
Como arquitecto o planificador de la estrategia, puede que tenga que formular una estrategia temprana para
Operations Management, en la que la supervisión desempeña un papel importante. Tenga en cuenta estos
cuatro resultados:
1. Administre los servicios de producción en la nube cuando se encuentran en producción, como redes,
aplicaciones, seguridad e infraestructura virtual.
2. Aplique recursos limitados para racionalizar el uso de las herramientas de supervisión, las aptitudes y la
experiencia que ya tiene, y use la supervisión en la nube para reducir la complejidad.
3. Haga que los procesos de la solución de supervisión sean más eficaces, trabaje a escala más rápido y de
forma más fluida y realice los cambios que necesite rápidamente.
4. Tenga en cuenta el modo en que su organización planeará y hospedará la supervisión según los modelos
en la nube. Trabaje con el objetivo de reducir los requisitos a medida que la organización pasa de IaaS a
PaaS y, a continuación, a SaaS.
Determine lo que tiene

Como experto en manejabilidad, es posible que esté trabajando en estrecha colaboración con un comité
directivo, un arquitecto y planificadores estratégicos. Es posible que esté trabajando para formular su estrategia
de supervisión mediante la evaluación del estado actual de la administración de sistemas además de las
personas, los socios, la contratación externa, las herramientas, la complejidad, las brechas y los riesgos. Si es así,
una valoración le ayudará a priorizar el conjunto de problemas encontrados y a seleccionar las principales
oportunidades que mejoren la situación actual. Asimismo, puede determinar también los servicios, los sistemas
y los datos que puedan permanecer en el entorno local como un solo resultado importante. Idealmente, la
administración debe tener un plan de desarrollo de iniciativas, pero en proporción directa al horizonte de
planeación conocido. Hablar de elementos desconocidos es también importante.
Modelado de alto nivel

A medida que el negocio determina qué servicios se deben trasladar, debe invertir con cuidado los recursos. En
el entorno local, recuerde que usted es el responsable de la supervisión de estos recursos y que están realmente
invertidos. Los movimientos que realice en los servicios de SaaS, por ejemplo, no eliminarán la responsabilidad
de supervisión. Decidirá quién necesita acceso, quién recibe alertas y quién necesita acceso a los análisis como
mínimo. Azure Monitor y Azure Arc son servicios de Azure que tiene la flexibilidad de abordar escenarios de
supervisión en los cuatro modelos en la nube, no solo en los recursos de Azure. Debe ir más allá de los modelos
de nube comunes, tal como se muestra a continuación. Si usa aplicaciones de Microsoft Office que ofrecen los
servicios de Microsoft 365 de su organización, además de Azure Security Center, deberá incluir la supervisión
de seguridad y cumplimiento con Microsoft 365. Esto incluye las identidades, la administración de puntos de
conexión y la supervisión de dispositivos fuera de la red corporativa.
Estrategia de supervisión de informes
Considere la posibilidad de que la funcionalidad de supervisión temprana informe de la estrategia. Muchas
decisiones dependen de los datos de supervisión tempranos para crear un plan de desarrollo de
funcionalidades que guíe los recursos limitados y agregue confianza. Las estrategias también necesitan
información del mundo real a partir de la supervisión de la habilitación del servicio.
Tenga en cuenta que la supervisión de roles se realiza en las estrategias para proteger incrementalmente el
patrimonio digital:
Los registros de actividad y la supervisión de la seguridad son necesarios para medir el uso del directorio
y el intercambio externo de contenido confidencial, para informar en un enfoque incremental, para
implementar capas en las características de protección y para lograr el equilibrio adecuado con la
supervisión de privacidad.
Las directivas y las líneas de base comunicarán el objetivo de racionalización (migración, lift-and-shift,
cambio de diseño) y mejorarán la confianza a la hora de migrar los datos y la información de los
servicios locales a los servicios en la nube.
Más adelante en esta guía, descubrirá algunos escenarios de supervisión comunes o usará casos que le
ayudarán a acelerar la adopción de este proceso.
Formulación de una arquitectura de supervisión

Defina la arquitectura actual y futura para la administración de sistemas que incluya la supervisión para realizar
lo siguiente:
Aplique recursos limitados para consolidar su inversión en la supervisión.
Decida de qué manera le ayudará la supervisión a habilitar los servicios que su negocio necesite en el
futuro: supervisión en la nube de servicios en la nube muy escalables, resistentes y globales.
Alinee la supervisión con los servicios y recursos que supervisará en la nube en un futuro.
Identifique las deficiencias de supervisión en las tres dimensiones: profundidad, amplitud y totalidad del
modelo de estado.
Modele los aspectos financieros, los costos y los factores de soporte que respaldan un análisis de costos
y beneficios.
Indique las decisiones híbridas que necesita tomar.
Un principio de supervisión es la visibilidad del servicio. Para que un servicio, recurso o componente sea
totalmente visible, debe equilibrar los tres lados de este principio, que son:
1. Supervisión en profundidad mediante la recopilación de señales significativas y relevantes.
2. Supervisión de un extremo a otro o de la amplitud desde la capa más baja de la pila hasta la aplicación.
3. De principio a fin, centrándose en los aspectos de mantenimiento (disponibilidad, rendimiento, seguridad y
continuidad).
Algunas preguntas clave incluyen:

¿Cómo formará los registros de seguridad y volverá a proteger el acceso a los nuevos controles de
privacidad y seguridad?
¿Qué servicios estarán disponibles globalmente? Y, como tales, ¿se pueden supervisar globalmente en el
perímetro del servicio?
¿Qué sucede con los puntos de red entre la infraestructura de red y la conectividad de red con los puntos
de conexión del servicio y de la aplicación que nos indican si somos nosotros o un proveedor de nube?
¿Cuáles son los límites de las operaciones de seguridad frente al mantenimiento y el rendimiento?
¿Cómo podemos proporcionar resúmenes de mantenimiento y estado para las operaciones de seguridad
y, por otro lado, hacerlos llegar a los propietarios de servicios?
Para ensamblar esta arquitectura, aquí hay que tener en cuenta lo siguiente:
Un enfoque de flujo de datos que parta de los recursos de servicio y suba por la pila: métricas y datos de
registro emitidos por la infraestructura, dispositivos IoT, dispositivos móviles y otros. ¿Se contemplan
todos los elementos en las herramientas de administración y supervisión (nivel medio)? Muévalos hacia
arriba y hacia afuera (herramientas de ITSM, supervisión global, administración de eventos e información
de seguridad [SIEM], enriquecimiento de alertas personalizadas, etc.).
Y se puede continuar con Systems Center Operations Manager o con otras herramientas de supervisión.
El costo económico.
Cómo usará la empresa los registros y las métricas. Azure Monitor aporta un volumen significativo de
datos de la serie temporal y del registro al rendimiento y el estado de la supervisión, algo similar a las
experiencias de las operaciones de seguridad. Los registros y las métricas son dos importantes
componentes de datos de la arquitectura de Azure Monitor. Estos son los motivos por lo que esto es
importante:
1. Puesto que puede crear servicios en la nube complejos a gran escala, se reducen los costos de
administración de problemas para analizar, correlacionar y determinar las causas de esos
problemas en un solo lugar, lo que reduce la necesidad de tener acceso a los recursos
directamente, mejorando así la seguridad.
2. Igual que sucede con SIEM, Azure Monitor consolida los datos de la máquina directamente desde
los recursos locales y los recursos de Azure (incluidos los registros de actividades, los datos de
inquilinos y suscripciones y los datos de registro de un cliente de REST); asimismo, proporciona un
lenguaje de consulta simple para obtener análisis de datos mucho mejores de lo que era posible
antes.
Tenga en cuenta los flujos de datos y las herramientas:
Orígenes y tipos (telemétrico, seguimientos, con estado, series temporales).
Herramientas y conjuntos (filas): (Columnas: disponibilidad, capacidad, seguridad, continuidad y
cumplimiento).
El rol de la supervisión global o del nivel superior.
El rol de la integración de la Administración de servicios de TI (ITSM) para desencadenar eventos
importantes.
Considere la posibilidad de usar en toda la empresa una única directiva en el plan de gobernanza para la
importancia de los eventos, y así poder crear alertas y notificaciones. Esta es una de las directivas clave de la
estrategia de supervisión. La tabla siguiente es un ejemplo del modelo de prioridad de administración de
incidentes para estandarizar los eventos, la importancia y las alertas que se usan para las notificaciones.
Formule iniciativas
Como experto en supervisión o administrador de sistemas, ha descubierto que la supervisión en la nube es más
rápida y fácil de establecer, lo que permite realizar demostraciones o pruebas de valor realmente económicas.
Para superar la tendencia a permanecer en el modo de demostración, debe permanecer en contacto constante
con la estrategia y ser capaz de ejecutar planes de supervisión centrados en la producción. Dado que la
estrategia provoca una gran incertidumbre y elementos desconocidos, no sabrá de antemano todos los
requisitos de supervisión necesarios. Por lo tanto, decida en el primer conjunto de planes de adopción y tenga
en cuenta los mínimos viables para el negocio y la administración de TI. Puede hacer referencia a esta capacidad
como aquella que necesita para comenzar el recorrido. A continuación se muestran dos iniciativas de ejemplo
que le permitirán avanzar:
Iniciativa 1: para reducir la diversidad y la complejidad de nuestra inversión de supervisión actual,
invertiremos en el establecimiento de una funcionalidad principal que usará Azure Monitor en primer
lugar, dado que las mismas aptitudes y preparación se aplican a otras áreas de supervisión en la nube.
Iniciativa 2: para decidir cómo aprovechamos nuestros planes de licencias para la identidad, el acceso y
la protección general de la información, ayudaremos a las oficinas de seguridad y privacidad a establecer
un sistema de supervisión temprana de la actividad de los usuarios y el contenido a medida que migran a
la nube, para así poder aclarar las preguntas sobre las etiquetas de clasificación, la prevención de pérdida
de datos, el cifrado y las directivas de retención.
Considere la posibilidad de realizar un escalado
Considere la posibilidad de realizar un escalado de la estrategia y de definir y normalizar la supervisión como
código. Asimismo, la organización debe planear la compilación de soluciones estandarizadas mediante una
combinación de herramientas como:
Plantillas de Azure Resource Manager.
Directivas y definiciones de la iniciativa de supervisión de Azure Policy
GitHub para establecer un control de código fuente para los scripts, el código y la documentación
Tenga en cuenta la seguridad y privacidad de los datos
En Azure, necesitará proteger determinados datos de supervisión que emiten los recursos y las acciones del
plano de control y que se registran en Azure; estos se conocen como registros de actividad. Además, los
registros especializados que registran la actividad de los usuarios, como el inicio de sesión de
Azure Active Directory y los registros de auditoría y, si están integrados, el registro de auditoría unificado de
Microsoft 365, ya que contienen datos confidenciales que es posible que deban protegerse en virtud de las leyes
de privacidad.
La estrategia de supervisión debe incluir estos componentes:
Separación de los datos sin supervisión de datos de supervisión.
Restricción del acceso a los recursos.
Tenga en cuenta la continuidad empresarial
Azure Monitor recopila, indexa y analiza los datos de máquinas en tiempo real y aquellos que generen los
recursos para respaldar sus operaciones y así ayudarle a impulsar decisiones empresariales. En raras ocasiones
es posible que no se pueda acceder a las instalaciones de toda una región debido, por ejemplo, a errores en la
red. O las instalaciones pueden perderse por completo debido, por ejemplo, a un desastre natural. Al confiar en
estos servicios en la nube, su planificación no se centra en torno a la resistencia de la infraestructura y la alta
disponibilidad, por lo que en su lugar, se planifica en torno a lo siguiente:
La disponibilidad para la ingesta de datos de todos los servicios y recursos dependientes en Azure, los
recursos en otras nubes y desde el entorno local.
La disponibilidad de los datos para los detalles, las soluciones, los libros y otras visualizaciones, las alertas, la
integración con ITSM y otros servicios de plano de control en Azure que admitan los requisitos operativos.
Cree un plan de recuperación y asegúrese de que este incluye restauración de datos, interrupciones de red,
errores de servicios dependientes e interrupciones de servicio regionales.
Tenga en cuenta la madurez
La madurez es una consideración muy importante en la estrategia de supervisión. Se recomienda empezar de
forma mínima, recopilar datos y, con esta información, determinar la estrategia. Las primeras soluciones de
supervisión que le interesa tener en cuenta son aquellas que garantizan la observación, para así poder incluir
procesos dinámicos, como la administración de incidentes y problemas. Aquí podrá:
Crear una o más áreas de trabajo de Log Analytics
Habilitar agentes
Habilitar la configuración de diagnóstico de recursos
Habilitar las reglas de alerta iniciales
Con el tiempo, ganará confianza en las funcionalidades de Azure Monitor con la necesidad de medir los
indicadores de estado, así que deberá ampliar el enfoque en la recopilación de registros, habilitar y usar la
información detallada y las métricas, y definir consultas de búsqueda de registros que impulsen la medición y el
cálculo de lo que es correcto o incorrecto.
Los ciclos de aprendizaje incluyen la opción de proporcionar datos de supervisión e información a los
administradores y la garantía de que los consumidores adecuados obtendrán los datos de supervisión que
necesitan. Los ciclos de aprendizaje incluyen el ajuste continuo y la optimización de los planes de supervisión
iniciales para adaptarse, mejorar el servicio e informar de los planes de adopción.
1 El modelo DIKW (por sus siglas en inglés) es un método que tiene sus raíces en la administración del
conocimiento y que se usa a menudo para explicar las maneras en que nos podemos mover de los datos a la
información, el conocimiento y la sabiduría con un componente de acciones y decisiones.
La supervisión es fundamental para los servicios que se compilan en Azure. La estrategia que adopte podrá
abordar estas cuatro disciplinas de la supervisión moderna, y así ayudarle a definir la supervisión mínima viable
y obtener confianza en los pasos. Conseguir cambiar su capacidad reactiva para que sea proactiva y escalar su
alcance a los usuarios finales es un objetivo que debe plantearse.
Obser var : en primer lugar, debe centrarse en establecer la supervisión para observar el estado de los
servicios y recursos de Azure. Configure la supervisión básica y, a continuación, automatícela con las
plantillas de Azure Policy y Azure Resource Manager para establecer la visibilidad inicial de los servicios y
su garantía: disponibilidad, rendimiento o capacidad, seguridad y cumplimiento de la configuración. Por
ejemplo, en función de la configuración mínima viable de Azure Monitor, configure los recursos para la
supervisión y el diagnóstico, la configuración de alertas y la información. Incluya el conocimiento y la
preparación para supervisar a los consumidores y definir y desencadenar eventos para trabajos de
servicio como incidentes y problemas. Un indicador de madurez es la cantidad que se puede automatizar
para reducir los costos humanos innecesarios al observar manualmente el estado. Saber qué servicios
son correctos es tan importante como recibir alertas sobre los servicios que están en mal estado.
Medir : configure la recopilación de métricas y registros de todos los recursos que se van a supervisar
para detectar síntomas y condiciones que supongan un problema; esto indica que existe un impacto
potencial o real en la disponibilidad del servicio o un impacto de los consumidores del servicio o la
aplicación. Por ejemplo:
Cuando se usa una característica de la aplicación, ¿muestra la latencia del tiempo de respuesta,
devuelve un error cuando se selecciona algo o no responde?
Asegúrese de que los servicios cumplen los acuerdos de servicio midiendo la utilidad del servicio
o la aplicación.
Responder : en función del contexto de los problemas conocidos que se observan y se miden, se evalúa
lo que se considera un error, una corrección automática o se requiere una respuesta manual basada en
aquello que se clasifica como incidente, problema o cambio.
Aprender y mejorar : los proveedores y consumidores que participan en los ciclos de aprendizaje
consumen datos de supervisión reales a través de información, informes y libros, para mejorar
continuamente el servicio de destino y para llevar a cabo la optimización de la configuración de
supervisión. El cambio también es importante, ya que los cambios de la configuración de supervisión se
complementan con los cambios en el servicio (por ejemplo: nuevo, modificado, retirado, etc.) y sigue
coincidiendo con la garantía de servicio real.
Para que pueda alinear los planes de supervisión con la estrategia, utilice la tabla siguiente para clasificar los
distintos escenarios de supervisión que se producen con más detalle. Este método funciona con las cinco R de la
racionalización introducidas anteriormente durante la fase de planeamiento. Si usa System Center Operations
Manager, dispone de opciones híbridas y de nube para racionalizar su inversión.
T IP O O B JET IVO DE SUP ERVISIÓ N O B JET IVO DE E JEM P LO
1 Solo en entornos locales System Center Operations Manager.

Continúe con la supervisión de
servicios, infraestructura y redes en la
capa de aplicación de los centros de
seguridad de su propiedad que no
tengan en cuenta la nube.
2 Del entorno local a la nube Siga usando System Center Operations

Manager y aplique los módulos de
administración de Microsoft 365 y
Azure.
3 Del entorno local a la nube o con ella Establezca la supervisión inicial con
(cooperativo), en la que los servicios se Azure Monitor. Conecte Azure Monitor
ejecutan tanto en la nube como en el a System Center Operations Manager
entorno local y los orígenes de alertas, como Zabbix
o Nagios. Implemente los agentes de
supervisión de Azure Monitor, que se
hospedan en conjunto con System
Center Operations Manager, donde
realizan la supervisión de forma
cooperativa.
4 Migración híbrida Supervise la migración, por ejemplo,

Microsoft Exchange Server para
Microsoft 365 Exchange Online.
Service Health de Exchange Online y
uso, seguridad y cumplimientodel
servicio: todo desde Microsoft 365.
Retire gradualmente la supervisión de
la versión local de Exchange con
System Center Operations Manager
hasta que finalice la migración.
5 Siempre híbrido System Center Operations Manager,

Azure AD, Azure Monitor, Azure
Security Center, Intune, etc.; una serie
de herramientas para una combinación
de recursos digitales.
T IP O O B JET IVO DE SUP ERVISIÓ N O B JET IVO DE E JEM P LO
6 Nativo en la nube Azure Monitor, Azure Policy, Azure

Security Center, Microsoft 365, Azure
Service Health, Azure Resource Health,
etc.
7 Inquilinos propiedad de varias nubes Centralice la supervisión de varios

(consolidación) inquilinos. Azure Lighthouse, Azure
Policy, Azure Monitor y Azure Sentinel.
8 Ecosistema multinube Centralice la supervisión de diferentes

proveedores de nube: Microsoft,
Amazon, Google y otros.
9 Proveedor > Consumidor Soluciones de supervisión y servicios

como proveedor de nube.
Formulación de requisitos de supervisión

A medida que avanza en este proceso, su estrategia revela que aún puede haber mucho que hacer. En última
instancia, sus ideas se expanden fuera de la red corporativa hacia el lugar de trabajo, los dispositivos y los
puntos de conexión, y más allá del límite de identidad como seguridad. El nuevo perímetro definido con la
supervisión en la nube es un incentivo seguro, a diferencia de tener en mente el centro de datos y el área de
trabajo.
Puede usar Azure ahora para empezar a administrar gradualmente todos o algunos aspectos de los recursos
locales, incluso para los servicios que mantendrá de forma local. También quiere que la estrategia defina los
límites de responsabilidad de supervisión en consonancia con la estrategia de adopción de la nube de la
empresa, basada en el modelo de servicio en la nube que esta adopte. Incluso en el caso de los servicios
basados en IaaS, obtendrá métricas, registros, vistas y funcionalidades de alerta a través de Azure Service Health
y, aquí, configurará alertas de supervisión de disponibilidad de los recursos de Azure con Resource Health. Ya se
proporcionan muchos elementos con servicios de SaaS tales como Microsoft 365, y debe configurar el acceso
adecuado a los portales, paneles, análisis y alertas. Desde el punto de vista del servicio, un servicio de gran
tamaño con componentes distribuidos como Microsoft 365 Exchange Online tiene varios objetivos, no solo la
necesidad de observar su estado y mantenimiento.
O B JET IVO P RIN C IPA L O B JET IVO Y RESULTA DO
Supervisión del estado Observe, mida, aprenda y mejore de forma holística la

garantía a largo plazo del servicio o componente, incluidos
los niveles de servicio, en estos aspectos: disponibilidad,
capacidad, rendimiento, seguridad y cumplimiento. Un
sistema, servicio o componente en buen estado estará en
línea, funcionará bien y será seguro y compatible. La
supervisión del estado de mantenimiento incluye registros y
estados, con estados y métricas de mantenimiento en
tiempo real. También incluye informes de tendencias,
información detallada y tendencias centradas en el uso del
servicio.
Supervisión de la utilidad Observe, mida, aprenda y mejore la calidad o los aspectos

cualitativos de la forma en que un sistema aporta valor. La
experiencia del usuario es un tipo de caso de uso de
supervisión.
O B JET IVO P RIN C IPA L O B JET IVO Y RESULTA DO
Supervisión de la seguridad Observe, mida, aprenda y mejore la protección como ayuda

para la estrategia de ciberseguridad y funciones tales como
operaciones de seguridad, identidad y acceso, protección de
la información, privacidad, administración de amenazas y
cumplimiento. Supervise el uso de Azure Security Center,
Azure Sentinel y de Microsoft 365.
Supervisión de costos Supervise el uso y calcule los costos mediante Azure Monitor
y Azure Cost Management + Billing como nuevo objetivo
principal. Las API de Azure Cost Management + Billing le
permiten explorar datos de uso y costos mediante análisis
multidimensional.
O B JET IVO S T ERC IA RIO S O B JET IVO Y RESULTA DO
Supervisión de la actividad Observe, mida, aprenda y mejore el uso, la seguridad y el

cumplimiento de orígenes tales los como registros de
actividad de Azure, registros de auditoría y el registro de
auditoría unificado de Microsoft 365 para eventos del nivel
de suscripción, acciones en los recursos, actividades del
usuario y el administrador, contenido, datos y para sus
necesidades de seguridad y cumplimiento en Azure y
Microsoft 365.
Uso de servicios Propietarios de servicios que quieren análisis e información

para medir, aprender y mejorar el uso de los servicios de
Azure y Microsoft 365 (IaaS, PaaS, SaaS) con informes,
análisis e información sobre el uso de los servicios.
Asegúrese de que los planes incluyan quién obtendrá acceso
a los portales de administración, los paneles, la información y
los informes.
Estado de los recursos y servicios Observe el estado de los recursos en la nube, así como las
interrupciones del servicio y los avisos de Microsoft, para
mantenerse informado sobre los incidentes y el
mantenimiento. Incluya Resource Health en la supervisión de
la disponibilidad de los recursos y alertas sobre los cambios
de disponibilidad.
Supervisión de rendimiento y capacidad Para poder apoyar la supervisión de estado, sus necesidades
pueden requerir más detalles y especialización.
Supervisión del cumplimiento y los cambios Observe, mida, aprenda y mejore la administración de la
configuración de los recursos, que ahora debe incluir la
seguridad en la formulación, en la cual influye el buen uso de
Azure Policy para normalizar las configuraciones de
supervisión y hacer cumplir la seguridad. Datos de registro
para filtrar los cambios clave que se realizan en los recursos.
Supervisión de la identidad y el acceso Observe, mida, aprenda y mejore el uso y la seguridad de

Active Directory, Azure Active Directory y la administración
de identidades que integra usuarios, aplicaciones,
dispositivos y otros recursos independientemente de dónde
se encuentren.
O B JET IVO S T ERC IA RIO S O B JET IVO Y RESULTA DO
Protección de la información Tanto Azure Monitor como Azure Information Protection (en
función del plan) incluyen el análisis de uso crítico para el
desarrollo de una estrategia sólida de Information Protection
en Azure y Microsoft.
Supervisión de la privacidad Las organizaciones se enfrentan a necesidades crecientes de

privacidad en las que se incluya la protección de la
información del patrimonio digital, la clasificación de datos y
la prevención de pérdida de datos para mitigar los riesgos de
infracciones de privacidad. Microsoft 365 Information
Protection incluye capacidades de supervisión que también
se pueden integrar con Azure Monitor.
Administración de amenazas y protección contra amenazas La nube reúne los roles independientes y tradicionales de
integrada supervisión de la seguridad con el seguimiento de estado. La
protección contra amenazas integrada, por ejemplo, implica
la opción de supervisión para acelerar un estado óptimo de
confianza cero. La integración de Azure Advanced Threat
Protection permite que una migración use System Center
Operations Manager para supervisar Active Directory e
integrar las señales relacionadas con la seguridad de AD para
detectar ataques avanzados en entornos híbridos.
Versiones de soluciones ágiles

En última instancia, proporcionará configuraciones o soluciones de supervisión a la producción. Como
responsable de operaciones o del equipo de supervisión de TI, considere la posibilidad de usar una taxonomía
estándar y sencilla para mejorar la comunicación con los consumidores, los administradores y las operaciones
de TI. Un enfoque DevOps ágil garantiza que la supervisión se inserte en los equipos que van a crear y operar
los servicios en la nube. Aunque la administración de proyectos tradicional funcione, no es lo suficientemente
rápida ni suele aceptarse como práctica estándar de los equipos de operaciones.
Incluya en su estrategia y modelo operativo la forma de comunicar los planes de supervisión, los objetivos y las
configuraciones (las soluciones). Por ejemplo, cómo podría usar Azure Boards:
T ÉRM IN O Á GIL Q UÉ SE VA A IN C L UIR E JEM P LO S
Epopeyas Supervisión amplia Consolidación de la supervisión de la

Iniciativas de la estrategia de nube de Azure
supervisión Supervisión de la nube híbrida
Supervisión de la nube privada
Establecer el servicio de supervisión
principal
Características Supervisión individual Requisitos de supervisión

Planes y proyectos Supervisión de consumidores y
proveedores
Objetivos
Herramientas
Programación
T ÉRM IN O Á GIL Q UÉ SE VA A IN C L UIR E JEM P LO S
Casos y tareas de usuario El resultado final es una solución o Supervisión de red (por ejemplo,
configuración de supervisión ExpressRoute)
Supervisión normalizada de máquinas
virtuales de IaaS (por ejemplo Azure
Monitor para VM, Application Insights,
Azure Policy, configuración, directivas,
informes, áreas de trabajo).
Establecer la gobernanza mínima

Tan pronto como sea posible, establezca la manera de administrar la inversión de supervisión en la nube.
Recuerde que Azure Monitor es un servicio de inquilinos con visibilidad en las suscripciones y los grupos de
administración; además, el ámbito de los usuarios se puede definir para limitar sus acciones con el control de
acceso basado en roles de Azure.
Defina quién tendrá el nivel de acceso de Azure para admitir su rol y responsabilidad. Le recomendamos que
establezca el acceso del rol Reader para la supervisión de los consumidores lo antes posible y que
posteriormente empiece a controlar a quién se le concede el rol Contributor .
En primer lugar, identifique los roles que poseerán y administrarán los grupos de recursos en Azure como parte
de su marco de gobernanza:
Si un equipo de supervisión o uno o más administradores de recursos y grupos de recursos tendrán
acceso con privilegios al rol Monitoring Contributor .
Los consumidores a los que se debe conceder el rol Monitoring Reader , que permite el acceso a las
características de Azure Monitor e investigar los problemas de la sección de supervisión que se incluye
con cada recurso de Azure.
Qué administradores requieren acceso a otros roles de Azure Reader, como Reports Reader .
En resumen, los roles de consumidor de supervisión probablemente necesiten accesos más amplios frente a los
accesos de desarrolladores y administradores del sistema, ya que estos solo necesitan acceso basado en roles a
determinados recursos de Azure. Como limitación adicional, asegúrese de eximir a los lectores del acceso a
datos de supervisión confidenciales como la seguridad, el inicio de sesión y los registros de actividad del
usuario.
Establecimiento de la preparación
En una fase temprana, formule un plan de preparación para que su personal de TI tenga la oportunidad de
obtener nuevas aptitudes, prácticas y técnicas para la supervisión en la nube en Azure. Tenga en cuenta la guía
de preparación de aptitudes para realizar la supervisión, ya que incluye necesidades fundamentales y específicas
de la supervisión.
Pasos siguientes
Observabilidad
Inteligencia artificial responsable
Microsoft está comprometido con el avance de la inteligencia artificial, pero controlada por ciertos principios
éticos que pongan a las personas en primer lugar. Queremos asociarnos con usted para respaldar este esfuerzo.
Principios de la inteligencia artificial responsable

Cuando se implementan soluciones de inteligencia artificial, tenga en cuenta los siguientes principios de
inteligencia artificial en la solución:
Equidad: los sistemas de inteligencia artificial deben tratar a todas las personas de la misma forma.
Confiabilidad y seguridad: los sistemas de inteligencia artificial deben funcionar de forma confiable y
segura.
Privacidad y seguridad: los sistemas de inteligencia artificial deben ser seguros y respetar la privacidad.
Inclusión: los sistemas de inteligencia artificial deben capacitar a todo el mundo e involucrar a las personas.
Transparencia: los sistemas de inteligencia artificial deben ser comprensibles.
Responsabilidad : las personas deben ser responsables de los sistemas de inteligencia artificial.
Establecimiento de una estrategia de IA responsable

Aprenda a desarrollar sus propios principios y estrategia de IA responsable en función de los valores de su
organización.
Introducción a AI Business School
Instrucciones para el desarrollo de la inteligencia artificial de manera

responsable
Ponga en práctica la inteligencia artificial responsable con estas directrices diseñadas para ayudarle a prever y
abordar posibles problemas que puedan aparecer a lo largo del ciclo de vida de desarrollo de software.
Directrices para la interacción entre la inteligencia artificial y los humanos
Directrices para la IA conversacional
Directrices para el diseño inclusivo
Lista de comprobación de la equidad de la inteligencia artificial
Hojas de datos de la plantilla de conjuntos de datos
Guía para la ingeniería de seguridad de IA
Herramientas para una inteligencia artificial responsable

Hay herramientas disponibles que pueden ayudar a los desarrolladores y científicos de datos a entender,
proteger y controlar los sistemas de inteligencia artificial. Estas herramientas pueden proceder de diversos
orígenes, como Azure Machine Learning, proyectos de código abierto e investigación.
Conocer : los sistemas de inteligencia artificial se pueden comportar de forma inesperada por varios
motivos. Las herramientas de software pueden ayudarle a conocer el comportamiento de los sistemas de
inteligencia artificial, con el fin de que pueda adaptarlos mejor a sus necesidades. Entre los ejemplos de este
tipo de herramienta se incluyen InterpretML y Fairlearn.
Proteger : los sistemas de AI se basan en los datos. Las herramientas de software pueden ayudarle a
proteger esos datos, ya que mantienen la privacidad y garantizan la confidencialidad. Algunos ejemplos de
este tipo de herramienta incluyen la informática confidencial para el aprendizaje automático, la privacidad
diferencial de WhiteNoise, el cifrado homomórfico de SEAL y Presidio.
Control: La inteligencia artificial responsable necesita gobierno y control a lo largo de todo el ciclo de
desarrollo. Azure Machine Learning habilita un registro de auditoría para mejorar la rastreabilidad, el linaje y
el control, con el fin de cumplir los requisitos legales. Entre los ejemplos se incluyen el registro de auditoría y
la trazabilidad.
Pasos siguientes
Para más información sobre el desarrollo de soluciones responsable, visite:
Introducción a la inteligencia artificial responsable
Recursos de inteligencia artificial responsables
Bots responsables: diez instrucciones para los desarrolladores de AI de conversación
De qué forma acelera GitHub la adopción de la
nube
La innovación es la nueva moneda del actual paisaje de la competitividad. El uso compartido del vehículo, el
contenido del streaming, los automóviles autónomos y otros servicios han cambiado radicalmente el ritmo de
vida diario de las personas, han dado un giro de 180 grados a los mercados y han mostrado a las claras que el
panorama de la competitividad ha pasado de los recursos físicos a experiencias digitales.
Estos tipos de experiencia digital superior están provocando una brecha, ya que las empresas consolidadas se
enfrentan a la feroz competencia de las empresas que pueden innovar y proporcionar valor a sus clientes más
rápidamente. Para competir y evitar dicha brecha, las empresas necesitan crear una cultura de innovación y usar
las herramientas y los servicios en la nube mejores y más apropiados.
GitHub proporciona una variedad de características que pueden ayudar a las empresas a:
Sacar provecho de las funcionalidades y los servicios de Azure.
Modernizar sus prácticas.
Ser más ágiles e innovadoras durante este cambio de cultura.
Las empresas pueden aprovechar las ventajas de la conectividad de GitHub con la comunidad de código abierto
y encontrar miles de ejemplos de soluciones en la nube reiterados, mejorados y listos para implementar de
organizaciones que han adoptado correctamente los servicios de Azure. Pueden tomar prestadas fácilmente
estas soluciones y seguir usando estas soluciones para adaptarlas a sus necesidades empresariales.
GitHub facilita que las organizaciones pongan en práctica la cultura del uso compartido dentro de sus equipos,
lo que agiliza la modernización e implementación de aplicaciones o cargas de trabajo. Las empresas pueden
girar sus ojos hacia la metodología InnerSource, que es un principio clave de la innovación, para tomar
prestados de la comunidad de código abierto procedimientos recomendados como el uso compartido y la
reutilización, la colaboración y comunicación, entre otros, y aplicarlos en su organización.
Desde la protección de los paquetes de código abierto hasta la propiedad intelectual que se escribe diariamente,
la protección de toda la cadena de suministro de software debe ser una prioridad principal para todas las
empresas. Este objetivo requiere una tecnología de seguridad avanzada que se puede incorporar y automatizar
durante todo el ciclo de vida, y varias funcionalidades nativas de GitHub, como GitHub Advanced Security y
Acciones de GitHub, ofrecen este tipo de flexibilidad.
Aprovechamiento de los recursos de código abierto

Las organizaciones muy eficaces reconocen el software de código abierto (OSS) como esencial, no opcional,
para el desarrollo de software moderno. Participan en las comunidades de desarrolladores de las que dependen
y usan una plataforma segura para invertir estratégicamente en software de código abierto. El resultado de
estas acciones es que estas organizaciones disfrutan de las innovaciones rápidamente, superan a sus
competidores y reducir los costos, al mismo tiempo que minimizan los riesgos.
Aunque el software de código abierto podría interpretarse como los paquetes, bibliotecas, scripts y
dependencias que se incorporan en las aplicaciones, hay miles de recursos de código abierto, que adoptan la
forma de infraestructura como código (IaC), documentación, guía y planos técnicos para arquitecturas de Azure
bien definidas. Los asociados, proveedores y usuarios de Microsoft han contribuido con estos planos técnicos a
la comunidad de software de código abierto y están disponibles en GitHub. Además, resultan fáciles de
modificar, reutilizar e implementar en un entorno específico de Azure.
Infraestructura como código
Infraestructura como código (IaC) es la administración de la infraestructura (redes, máquinas virtuales,
equilibradores de carga y topología de conexión) en un modelo descriptivo y usa el mismo sistema de control
de versiones que utiliza el equipo de DevOps para el código fuente. Al igual que el principio de que el mismo
código fuente genera el mismo archivo binario, los modelos de IaC genera el mismo entorno cada vez que se
aplica. IaC es una práctica clave de DevOps que se usa con la entrega continua (CD).
IaC ha evolucionado para resolver el problema de desfase del entorno en la canalización de versión. Sin él, los
equipos deben mantener la configuración de los entornos de implementación individuales, y las incoherencias
entre los entornos generan problemas durante las implementaciones. En último término, cada entorno se
convierte en un copo de nieve, una configuración única que no se puede reproducir automáticamente. Con los
copos de nieve, la administración y el mantenimiento de la infraestructura implican procesos manuales que
facilitan la aparición de errores y cuyo seguimiento es difícil de realizar. Las implementaciones de
infraestructuras con IaC se pueden repetir y evitan los problemas en tiempo de ejecución que provocan el
desfase en la configuración o las dependencias que faltan.
Con IaC, los equipos realizan cambios tanto en la descripción del entorno como en el modelo de configuración,
que habitualmente está en formatos de código bien documentados como JSON; para más información, consulte
las plantillas de Azure Resource Manager. Para simplificar sus flujos de trabajo, los desarrolladores pueden
hospedar el código IaC en el mismo repositorio de GitHub en el que se encuentra el código fuente de su
aplicación y adoptar las mismas prácticas de CI/CD de integración para IaC con la tecnología de Acciones de
GitHub.
En la acción de GitHub AzOps encontrará un ejemplo de cómo implementar plantillas de Resource Manager
personalizadas en varios ámbitos de Azure. Si no está familiarizado con las plantillas de Resource Manager o
con IaC, también puede examinar el repositorio azure-quickstart-templates en GitHub, buscar la plantilla que
desea implementar y seleccionar el botón Deploy to Azure (Implementar en Azure) para probar su
funcionamiento.
Componentes y procedimientos recomendados del patrón en la nube

El siguiente diagrama de arquitectura resalta las comprobaciones de seguridad que se ejecutan en los
componentes de GitHub y Azure en un entorno DevSecOps de GitHub:
GitHub proporciona una plataforma de hospedaje de código que los desarrolladores pueden usar para
colaborar en proyectos tanto de código abierto como de origen interno.
Codespaces es un entorno de desarrollo en línea. Esta herramienta está hospedada en GitHub y tiene la
tecnología de Visual Studio Code, y proporciona una solución de desarrollo completa en la nube.
La seguridad de GitHub sirve para eliminar amenazas de varias maneras. Los agentes y servicios
identifican las vulnerabilidades de los repositorios y los paquetes dependientes. También actualizan las
dependencias a las versiones seguras actualizadas.
Las Acciones de GitHub son flujos de trabajo personalizados que proporcionan las funcionalidades de
CI/CD directamente en los repositorios. Los equipos denominados ejecutores hospedan estos trabajos de
CI/CD.
Azure Active Directory es un servicio multiinquilino de identidad basado en la nube que controla el
acceso a Azure y a otras aplicaciones en la nube, como Microsoft 365 y GitHub.
Azure App Service proporciona un marco para compilar, implementar y escalar aplicaciones web. Esta
plataforma ofrece mantenimiento de infraestructura integrado, revisiones de seguridad y escalado.
Azure Policy le ayuda a administrar y evitar problemas de TI mediante definiciones de directivas que
pueden aplicar reglas a los recursos en la red. Por ejemplo, si un proyecto está a punto de implementar
una máquina virtual con una SKU no reconocida, Azure Policy envía alertas del problema y detiene la
implementación.
Azure Security Center proporciona administración unificada de la seguridad y protección avanzada
contra amenazas para cargas de trabajo en la nube híbrida.
Azure Monitor recopila y analiza métricas de rendimiento, registros de actividad y otros datos de
telemetría de la aplicación. Si este servicio identifica condiciones irregulares, alerta a las aplicaciones y al
personal.
Metodología InnerSource
Introducción a la metodología InnerSource
Muchas empresas usan el término metodología InnerSource para describir la forma en que sus equipos de
ingeniería trabajan juntos en el código. InnerSource es una metodología de desarrollo en la que los ingenieros
crean software propietario con procedimientos recomendados de proyectos de código abierto a gran escala,
como Kubernetes o Visual Studio Code.
Los proyectos de código abierto a gran escala requieren coordinación y trabajo en equipo entre miles de
colaboradores. Los que más éxito cosechan son los movidos por una visión tanto de su futuro como de las
necesidades diarias de los usuario: velocidad, confiabilidad y funcionalidad. La escala en que funcionan estos
proyectos pueden servir de enseñanza y puede ayudar a las empresas a crear mejor software más rápidamente
con InnerSource.
Con las solicitudes de incorporación de cambios y los problemas de GitHub, la colaboración y la revisión de
código se integran en el proceso de desarrollo. Los equipos internos y externos pueden compartir su trabajo,
debatir los cambios y obtener comentarios, y todo ello en un solo lugar, lo que ayuda a las organizaciones a
compartir la experiencia internamente y evitar tener que reinventar soluciones probadas en el campo
desarrolladas para otros proyectos.
Anatomía de un proyecto de InnerSource
La combinación correcta de personas, equipos y recursos puede garantizar el éxito de un proyecto. Muchos
proyectos de código abierto siguen una estructura organizativa similar que puede ayudar a las organizaciones a
configurar equipos interfuncionales para administrar proyectos de InnerSource. Los proyectos de código abierto
más frecuentes tiene los siguientes tipos de personas:
Mantenedores: colaboradores que son responsables de impulsar la visión y de administrar los aspectos
de organizativos del proyecto. Es posible que no sean los propietarios o creadores originales del código.
Colaboradores: todos los que han contribuido en algo al proyecto.
Miembros de la comunidad: las personas que usan el proyecto. Pueden estar activas en
conversaciones o expresar su opinión en la dirección del proyecto.
Los proyectos más grandes también pueden tener subcomités o grupos de trabajo centrados en tareas
diferentes, como la creación de herramientas, la evaluación de prioridades y la moderación de la comunidad. Es
probable que los proyectos InnerSource sigan una estructura similar. Muchas organizaciones de ingeniería
organizan a los desarrolladores en equipos, como ingeniería de aplicaciones, ingeniería de plataformas y
desarrollo web. En las organizaciones, este tipo de estructuración puede excluir a personas calificadas. La
organización de un grupo de toma de decisiones principal que tenga el apoyo de los equipos de toda la
organización puede ayudar a obtener rápidamente la experiencia necesaria para solucionar los problemas con
mayor rapidez.
En las empresas, los colaboradores son sus desarrolladores y los mantenedores son los jefes de proyecto y los
responsables de la toma de decisiones clave.
Mantenedores: los desarrolladores, jefes de producto y otros responsables de la toma de decisiones
clave en la empresa cuya misión es impulsar la visión de los proyectos y administrar las contribuciones
cotidianas.
Colaboradores: los desarrolladores, científicos de datos, administradores de producto, vendedores y
otros roles de la empresa que ayudan a impulsar el software. Es posible que los colaboradores no formen
parte del equipo directo del proyecto, sino que ayuden a compilar el software, mediante la creación de
código, el envío de correcciones de errores, etc.
Para más información al respecto, consulte el artículo de introducción a InnerSource.
Automatización
Acciones de GitHub permite a los usuarios crear flujos de trabajo personalizados directamente en sus
repositorios de GitHub. Los usuarios pueden detectar, crear y compartir acciones para realizar cualquier trabajo,
entre los que se incluyen CI/CD, así como combinar acciones en un flujo de trabajo completamente
personalizado. También pueden crear flujos de trabajo de CI que compilan y prueban proyectos escritos en
diferentes lenguajes de programación. En las guías de las acciones de GitHub, encontrá varios ejemplos.
Las Acciones de GitHub se pueden usar para combinar conceptos de IaC y prácticas de CI/CD, con el fin de
automatizar todo el ciclo de vida de la implementación de un extremo a otro, incluidos el aprovisionamiento o la
actualización del entorno de destino de forma repetible y el empaquetado e implementación de la propia
aplicación.
Ejemplo
Las Acciones de GitHub para Azure se compilan para simplificar la forma de automatizar los procesos de
implementación en los servicios de Azure de destino, como Azure App Service, Azure Kubernetes Service, Azure
Functions, etc. El repositorio de flujos de trabajo de acciones para comenzar a trabajar con Azure incluye flujos
de trabajo de un extremo a otro para crear e implementar aplicaciones web de cualquier lenguaje y ecosistema
en Azure. Para ver todas las acciones disponibles, visite GitHub Marketplace.
Seguridad
Características de seguridad del desplazamiento a la izquierda de GitHub
Desde los primeros pasos de desarrollo, DevSecOps se adhiere a los procedimientos de seguridad
recomendados. Mediante el uso de una estrategia de desplazamiento a la izquierda, DevSecOps redirige el foco
de seguridad. En lugar de apuntar a la auditoría, al final, se desplaza al principio del desarrollo. Además de
generar un código sólido, este enfoque de respuesta rápida a errores ayuda a resolver los problemas al
principio, cuando son fáciles de corregir.
GitHub dispone de muchas funcionalidades de seguridad y ofrece herramientas que admiten todas las partes de
un flujo de trabajo de DevSecOps:
IDE basados en explorador con extensiones de seguridad integradas.
Agentes que supervisan continuamente los avisos de seguridad y reemplazan las dependencias vulnerables
y desactualizadas.
Funcionalidades de búsqueda que buscan vulnerabilidades en el código fuente.
Flujos de trabajo basados en acciones que automatizan todos los pasos de desarrollo, prueba e
implementación.
Espacios que proporcionan una manera de analizar y resolver amenazas de seguridad de forma privada, así
como de publicar la información.
Junto con la capacidad de supervisión y evaluación de Azure, estas características proporcionan un servicio
excelente para crear soluciones seguras en la nube.
Ejemplo
Las instalaciones de DevSecOps de GitHub cubren muchos escenarios de seguridad. Entre las posibilidades se
incluyen los siguientes casos:
Desarrolladores que desean aprovechar las ventajas de los entornos preconfigurados que ofrecen
funcionalidades de seguridad.
Administradores que confían en tener informes de seguridad actualizados y con prioridad a su alcance, junto
con los detalles sobre el código afectado y las correcciones sugeridas.
Organizaciones optimizadas que necesitan sistemas para adquirir automáticamente dispositivos de
seguridad nuevos y que no corran peligro, cuando los secretos quedan expuestos en el código.
Equipos de desarrollo que pueden beneficiarse de las actualizaciones automáticas, cuando estén disponibles
versiones más recientes o más seguras de los paquetes externos.
Lecturas adicionales:
DevSecOps en GitHub: ideas de soluciones de Azure | Microsoft Docs
Análisis del código de un repositorio de GitHub mediante GitHub Advanced Security en una canalización
Azure DevOps
Aplicación de DevSecOps a una cadena de suministro de software
Pasos siguientes
Elija el equipo de implementación (normalmente, un administrador de desarrolladores y algunos
desarrolladores definidos como administradores) e implemente GitHub.
Obtenga información sobre los flujos de trabajo de Git comunes y avanzados para mejorar su forma de usar
GitHub.
Los siguientes vínculos proporcionan más información acerca de GitHub.
Módulos de GitHub en Microsoft Learn
Laboratorio de aprendizaje de GitHub
Documentación de GitHub
Sugerencias para empezar a trabajar con DevSecOps de GitHub
Ruta de preparación de aptitudes durante la fase de
planeamiento de un recorrido de migración
Durante la fase de planeamiento de un recorrido de migración, el objetivo es desarrollar los planes necesarios
para guiar la implementación de la migración. Para esta fase se necesitan algunas habilidades críticas, como por
ejemplo:
Establecer la visión
Racionalizar el patrimonio digital
Crear un trabajo pendiente de migración (plan técnico)
En las secciones siguientes se proporcionan rutas de aprendizaje para desarrollar cada uno de estos
conocimientos.
Establecer la visión
La visión de negocio define el éxito de cualquier esfuerzo de adopción de la nube. Cuando el equipo técnico no
comprende los motivos y los resultados que se quieren obtener, resulta difícil guiar sus esfuerzos para lograr el
éxito empresarial. Lea estos artículos para obtener información sobre cómo documentar y articular la visión
empresarial del equipo técnico:
Motivaciones de la adopción. Documente y articule los motivos del esfuerzo técnico.
Resultados empresariales. Articule claramente lo que se espera del equipo técnico en lo que respecta a los
cambios empresariales.
Métricas de aprendizaje. Establezca métricas a corto plazo que puedan mostrar el progreso hacia los
resultados empresariales a largo plazo.

Para justificar la inversión para adoptar la nube puede ser necesario un análisis más profundo y una
comprensión de las prácticas de contabilidad de su organización. Los artículos sobre justificación empresarial
pueden ayudarle a desarrollar estas habilidades:
Creación de un caso empresarial de migración a la nube. Establezca un caso empresarial para la migración a
la nube.

Para refinar su caso empresarial, puede alinear el caso de negocio que quiera con el inventario del patrimonio
digital actual y futuro. Estos artículos le guiarán en el desarrollo de una racionalización del patrimonio digital:
Racionalización incremental: Un enfoque ágil para la racionalización que alinea correctamente las decisiones
técnicas enlazadas en tiempo de ejecución.
Las cinco "R" de la racionalización: Comprender las diversas opciones de racionalización.
Crear un trabajo pendiente de migración (plan técnico)

Convierta el caso de negocio y la información digital racionalizada en un plan de migración accionable para
guiar las actividades técnicas necesarias para lograr los resultados empresariales que espera.
Habilidades de planeación empresarial

Durante la fase de preparación, el personal técnico crea una zona de aterrizaje de la migración capaz de
hospedar, operar y gobernar las cargas de trabajo que se han migrado a la nube. Estas rutas de aprendizaje
pueden ayudarle a desarrollar los conocimientos necesarios:
Creación de una cuenta de Azure. El primer paso para usar Azure es crear una cuenta. La cuenta contiene los
servicios de Azure que aprovisiona y controla su configuración personal como identidad, facturación y
preferencias.
Azure Portal. Pasee por las características y servicios de Azure Portal, y personalice el portal.
Introducción a Azure. Para empezar a usar Azure, cree y configure su primera máquina virtual en la nube.
Introducción a la seguridad en Azure. Conozca los conceptos básicos para proteger la infraestructura y los
datos cuando trabaje en la nube. Comprenda qué responsabilidades son suyas y de cuáles se encarga de
Azure.
Administración de recursos en Azure. Aprenda a trabajar con la línea de comandos de Azure y el portal web
para crear, administrar y controlar los recursos basados en la nube.
Creación de una máquina virtual. Cree una máquina virtual con Azure Portal.
Redes de Azure. Conozca los aspectos básicos de las redes de Azure y descubra cómo mejorar la resistencia y
reducir la latencia con la red de Azure.
Opciones de proceso de Azure. Conozca los servicios de proceso de Azure.
Proteja los recursos con RBAC de Azure. Use RBAC de Azure para proteger los recursos.
Opciones de almacenamiento de datos. conozca las ventajas del almacenamiento de datos de Azure.
Aptitudes de organización
En función de las motivaciones y los resultados empresariales de un esfuerzo de adopción de la nube, es posible
que los responsables tengan que establecer nuevas estructuras organizativas o equipos virtuales para facilitar
las diversas funciones. Estos artículos le ayudarán a desarrollar las habilidades necesarias para estructurar estos
equipos y lograr los resultados que busca:
Alineación inicial de la organización. Información general sobre la alineación de la organización y diversas
estructuras de equipo para facilitar objetivos específicos.
Desglose en silos y feudos. Comprenda los dos antipatrones de organización comunes, así como formas de
guiar al equipo a la colaboración productiva.
Exploración en profundidad de las aptitudes

Hay disponibles varias opciones de aprendizaje además de estas opciones iniciales para desarrollar habilidades.
Asignaciones típicas de roles de TI en la nube
Microsoft y sus asociados ofrecen diversas opciones para todo tipo de público con el fin de desarrollar las
aptitudes con los servicios de Azure.
Asignación de roles y aptitudes: Un recurso para asignar su trayectoria profesional en la nube. Más
información sobre su rol de nube y las aptitudes sugeridas. Siga un plan de estudios de aprendizaje a su
propio ritmo para desarrollar las aptitudes fundamentales para mantenerse al día.
Explore los exámenes y el entrenamiento de la certificación de Azure para obtener un reconocimiento
oficial de sus conocimientos de Azure.
Microsoft Learn
Microsoft Learn es un enfoque nuevo al aprendizaje. La preparación para las nuevas aptitudes y
responsabilidades que acompañan a la adopción de la nube no es fácil. Microsoft Learn proporciona un enfoque
más gratificante para el aprendizaje práctico que le ayuda a lograr sus objetivos con más rapidez. Gane puntos y
niveles y consiga más.
Este es un ejemplo de ruta de aprendizaje adaptada que se alinea con la metodología de estrategia de Cloud
Adoption Framework.
Descubra el valor empresarial de Microsoft Azure: esta experiencia de aprendizaje le guiará en un proceso que
comenzará mostrándole cómo la transformación digital y la eficacia de la nube pueden transformar su negocio.
Veremos cómo Microsoft Azure Cloud Services puede potenciar la organización en una plataforma en la nube
de confianza. Por último, se explicará cómo convertir este proceso en realidad para su organización.
Más información
Para descubrir más rutas de aprendizaje, eche un vistazo al catálogo de Microsoft Learn. Use el filtro Roles para
alinear las rutas de aprendizaje con su rol.
Antipatrones de estrategia de nube
A menudo, los clientes experimentan antipatrones durante la fase de estrategia de la adopción de la nube. Estos
antipatrones pueden dificultar la alineación de TI y las estrategias empresariales. También hacen que sea difícil
medir el éxito de los proyectos de la nube.
Antipatrón: adoptar la nube sin establecer los objetivos

Muchas empresas anuncian estrategias primero en la nube o solo en la nube. Sin embargo, no definen
claramente qué quieren lograr con esas estrategias. Algunos proyectos de la nube pueden tener éxito sin KPI ni
objetivos concretos. Es imposible medir el rendimiento del proyecto sin especificar los indicadores o los
objetivos.
Ejemplo: migración a la nube sin definir los objetivos
El competidor más cercano de una corporación lanza una estrategia solo en la nube. El objetivo del competidor
es agilizar la empresa mediante la inclusión de todos los sistemas en la nube en un plazo de un año. La
corporación no desea quedarse detrás. Los directores de la corporación comienzan los debates estratégicos
sobre cómo adoptar la nube rápidamente. Sin embargo, no definen ningún criterio de éxito concreto, como
reducir costos o mejorar el rendimiento del sistema.
El primer sistema de la corporación se migra a la nube. Los directores no pueden comprobar si su estrategia de
nube es correcta porque nunca definieron qué querían lograr.
Resultado preferido: definición de los objetivos y los KPI
Defina indicadores KPI concretos al hablar de sus motivos para adoptar la nube. Posteriormente, podrá medir el
éxito de su estrategia. También sabrá si puede usar la misma estrategia para otros proyectos. Consulte ¿por qué
se realiza el traslado a la nube? para obtener más información sobre las motivaciones para la adopción de la
nube.
Antipatrón: omitir la comunicación de las motivaciones

Se puede producir un error en los recorridos de adopción de la nube cuando las motivaciones o los
desencadenadores de adopción de la nube no están alineados en una empresa. Una empresa podría ver
ventajas importantes en la adopción de la nube, pero no comunicar estos desencadenadores de adopción a TI.
Este problema se produce incluso cuando estas motivaciones influyen en la estrategia de TI de la empresa, no
solo en su estrategia empresarial. Sin una alineación o sin motivaciones documentadas, los recorridos de la
nube suelen producir errores.
Ejemplo: error al comunicar las ventajas
Una corporación comienza a usar la nube cuando su junta directiva anuncia una estrategia de TI primero en la
nube. Sin embargo, la junta no explica las ventajas de la estrategia para la empresa. Los departamentos de TI y
de empresa no están seguros de los motivos por los que adoptan la nube. Esta incertidumbre conduce a una
falta de enfoque, lo que significa que los departamentos no trabajarán para lograr este objetivo común. La
indecisión sobre la adopción de la nube aumenta, especialmente en el departamento de TI. Dado que la
estrategia de TI no tiene los objetivos bien definidos, esa estrategia se somete a examen, lo que da lugar a más
preguntas que respuestas.
Resultado preferido: definición y comunicación de los motivos para la adopción de la nube
Decida por qué quiere adoptar la nube. A continuación, defina claramente sus motivos y comuníquelos en toda
la empresa. Los departamentos de TI y de empresa aceptarán la adopción de la nube sin tantos reparos.
También puede usar estas motivaciones para influir en las decisiones técnicas en las fases posteriores del
recorrido de adopción de la nube. Antes de justificar el traslado a la nube, revise los mitos de la migración a la
nube.
Pasos siguientes
¿Por qué queremos realizar el traslado a la nube?
Compilación de una justificación comercial para la migración a la nube
Desarrollo de un plan de adopción de la nube
Los planes de adopción de la nube convierten los objetivos a los que se aspira en un plan viable. Los equipos
colectivos de la nube pueden usar el plan de adopción de la nube para guiar los esfuerzos técnicos y alinearlos
con la estrategia empresarial.
Los siguientes ejercicios le ayudarán a documentar la estrategia tecnológica. Este enfoque captura tareas
prioritarias que impulsan los esfuerzos de adopción. El plan de adopción de la nube se asigna, a continuación, a
las métricas y motivaciones definidas en la estrategia de adopción de la nube.
Patrimonio digital: Realice el inventario y racionalización del

patrimonio digital según supuestos que se alinean con las
motivaciones y resultados empresariales.
Alineación inicial de la organización: Establezca un plan para

la alineación inicial de la organización que admita el plan de
adopción.
Plan de preparación de las aptitudes: Cree un plan para

afrontar las carencias en la preparación de las aptitudes.
Plan de adopción de la nube: Desarrolle un plan de adopción

de la nube para administrar los cambios en el patrimonio
digital, las aptitudes y la organización.
Descargue la plantilla de estrategia y planeamiento para hacer un seguimiento de las salidas de cada ejercicio a
medida que crea su estrategia de adopción de la nube. Además, conozca las cinco RS de la racionalización de la
nube para ayudar a crear el plan de adopción de la nube.
Racionalización de la nube
La racionalización de la nube es el proceso de evaluar los recursos para determinar la mejor manera de migrar o
modernizar cada activo en la nube. Para más información sobre el proceso de racionalización, vea ¿Qué es un
patrimonio digital?.
Contexto de racionalización
Las cinco "R" de la racionalización que se mencionan en este artículo son una excelente manera de etiquetar un
posible estado futuro para cualquier carga de trabajo que se esté considerando como candidato para la nube.
Este proceso de etiquetado debe colocarse en el contexto correcto antes de intentar racionalizar un entorno.
Eche un vistazo a estos mitos para proporcionar ese contexto:
Mito: Es fácil tomar decisiones de racionalización en las primeras etapas del proceso.
Para que la racionalización sea precisa, se necesita un amplio conocimiento de la carga de trabajo y de los
recursos asociados (aplicaciones, infraestructura y datos). Lo más importante es que las decisiones de
racionalización precisas tardan tiempo. Se recomienda usar un proceso de racionalización incremental.
Mito: La adopción de la nube tiene que esperar a que se racionalicen todas las cargas de trabajo.
La racionalización de una cartera de TI completa o incluso un único centro de datos puede retrasar la realización
del valor empresarial en meses o incluso años. La racionalización completa debe evitarse siempre que sea
posible. Es preferible usar el enfoque de la potencia de 10 para el planeamiento de la liberación, para tomar
decisiones acertadas sobre las 10 próximas cargas de trabajo que están programadas para la adopción de la
nube.
Mito: La justificación empresarial tiene que esperar a que se racionalicen todas las cargas de trabajo.
Para desarrollar una justificación comercial para un esfuerzo de adopción en la nube, realice algunas
suposiciones básicas en el nivel de cartera. Cuando las motivaciones están en la misma línea que la innovación,
habrá que repetir la arquitectura. Cuando las motivaciones están en la misma línea que la migración, habrá que
realizar un rehospedaje. Estas suposiciones pueden acelerar el proceso de justificación empresarial. Después, se
cuestionan las suposiciones y se refinan los presupuestos durante la fase de evaluación de los ciclos de
adopción de cada carga de trabajo.
Ahora eche un vistazo a las cinco "R" de la racionalización para familiarizarse con el proceso a largo plazo. Al
desarrollar el plan de adopción de la nube, elija la opción que mejor se adapte a sus motivaciones, resultados
empresariales y el entorno de estado actual. El objetivo de la racionalización del patrimonio digital es establecer
una base de referencia, en lugar de racionalizar cada carga de trabajo.
Las cinco "R" de la racionalización

Las cinco "R" de la racionalización que se enumeran aquí describen las opciones más comunes para la
racionalización.
Rehospedaje
También conocido como una migración lift and shift, el rehospedaje cambia la ubicación del recurso de estado
actual al proveedor de nube elegido, con un cambio mínimo en la arquitectura general.
Estos son los principales motivos para hacer un rehospedaje:
Reducir los gastos de capital
Liberar espacio en el centro de datos
Conseguir una rápida rentabilidad de la inversión en la nube
Factores de análisis cuantitativo:
Tamaño de máquina virtual (CPU, memoria, almacenamiento)
Dependencias (tráfico de red)
Compatibilidad de recursos
Factores de análisis cualitativo:
Tolerancia al cambio
Prioridades empresariales
Eventos empresariales críticos
Dependencias de procesos
Refactorización
Las opciones de plataforma como servicio (PaaS) pueden reducir los costos operativos asociados a muchas
aplicaciones. Se aconseja refactorizar ligeramente una aplicación para ajustarla a un modelo basado en PaaS.
"Refactorizar" también hace referencia al proceso de desarrollo de aplicaciones de refactorizar el código para
permitir que una aplicación satisfaga nuevas oportunidades de negocio.
Actualizaciones más rápidas y cortas
Portabilidad del código.
Mayor eficiencia en la nube (recursos, velocidad, costo, operaciones administradas)
Tamaño de los recursos de la aplicación (CPU, memoria, almacenamiento)
Tráfico de usuarios (vistas de página, tiempo en la página, tiempo de carga)
Plataforma de desarrollo (idiomas, plataforma de datos, servicios de nivel intermedio)
Base de datos (CPU, memoria, almacenamiento, versión)
Inversiones empresariales continuadas
Ampliación de opciones y plazos
Dependencias de procesos de negocio
Rediseño
Algunas aplicaciones antiguas no son compatibles con los proveedores de nube debido a las decisiones de
arquitectura que se tomaron cuando se creó la aplicación. En estos casos, puede ser necesario rediseñar la
aplicación antes de la transformación.
En otros casos, las aplicaciones que son compatibles con la nube, pero que no son nativas de la nube, podrían
ser eficientes en cuanto a costos y operaciones si se rediseñara la solución para convertirla en una aplicación
nativa de nube.
Agilidad y escalabilidad de la aplicación
Adopción más fácil de nuevas funcionalidades de nube
Mezcla de pilas de tecnología
Crecientes inversiones empresariales
Costos operativos
Posibles bucles de comentarios e inversiones en DevOps.
Volver a generar
En algunos casos, los obstáculos que deben salvarse para llevar adelante una aplicación pueden ser demasiado
grandes como para justificar la inversión. Esto ocurre especialmente en el caso de las aplicaciones que antes
eran útiles para una empresa, pero que ya no son compatibles o no están en línea con los procesos
empresariales actuales. En este caso, se crea una nueva base de código para alinearla con un enfoque nativo de
nube.
Acelerar la innovación
Crear aplicaciones más rápido.
Reducir los costos operativos
Rechazar la satisfacción del usuario final
Procesos de negocio limitados por funcionalidad
Posibles ganancias de costo, experiencia o ingresos
Replace
Las soluciones suelen implementarse usando la mejor tecnología y el enfoque que haya disponible en ese
momento. A veces, las aplicaciones de software como servicio (SaaS) pueden proporcionar todas las funciones
necesarias para la aplicación hospedada. En estos casos, se puede programar una carga de trabajo para
reemplazarla en el futuro y eliminarla de manera eficaz del esfuerzo de transformación.
Estandarizar en torno a procedimientos recomendados del sector
Acelerar la adopción de enfoques basados en procesos de negocio
Reasignar inversiones en el desarrollo de aplicaciones que crean diferenciación o ventaja competitivas
Reducciones generales de costos operativos
Tamaño de máquina virtual (CPU, memoria, almacenamiento)
Recursos que se van a retirar
Análisis de costo-beneficio de la arquitectura actual frente a la solución SaaS
Asignaciones de procesos de negocio
Esquemas de datos
Procesos automatizados o personalizados
Pasos siguientes
En conjunto, puede aplicar estos cinco puntos esenciales de la racionalización a un patrimonio digital para que
sea más fácil tomar decisiones de racionalización sobre el estado futuro de cada aplicación.
Todas las compañías modernas tienen algún tipo de patrimonio digital. Un patrimonio digital es muy parecido a
un patrimonio físico, es una referencia abstracta a una colección de recursos tangibles que tienen un propietario.
En un patrimonio digital, esos recursos incluyen máquinas virtuales (VM), servidores, aplicaciones, datos, etc.
Básicamente, un patrimonio digital es la colección de recursos de TI que alimenta los procesos de negocio y las
operaciones complementarias.
La importancia de un patrimonio digital se hace más evidente durante la planeación y ejecución de los esfuerzos
de transformación digital. Durante los recorridos de transformación, los equipos de estrategias de nube usan el
patrimonio digital para asignar los resultados empresariales a planes de lanzamiento y esfuerzos técnicos. Todo
comienza con un inventario y la medición de los recursos digitales que posee la organización actualmente.
¿Cómo se puede medir un patrimonio digital?

La medición de un patrimonio digital cambia según los resultados empresariales deseados.
Migraciones de infraestructura: cuando una organización mira hacia el interior y busca optimizar los
costos, los procesos operativos, la agilidad u otros aspectos de las operaciones, el patrimonio digital se
centra en máquinas virtuales, servidores y cargas de trabajo.
Innovación en las aplicaciones: en las transformaciones que se centran en el cliente, el objetivo es
algo diferente. El foco debe situarse en las aplicaciones, las API y los datos transaccionales que admiten
los clientes. Las máquinas virtuales y los dispositivos de red reciben, a menudo, menos atención.
Innovación controlada por datos: en el mercado actual controlado digitalmente, es difícil lanzar un
nuevo producto o servicio sin una sólida base de datos. Durante los esfuerzos de innovación de datos
habilitados para la nube, el centro de atención recae en los silos de datos de la organización.
Estabilidad operativa: para funcionar de forma eficaz las empresas dependen de tecnologías estables.
En los mercados actuales, donde prima la competitividad, es crucial que el tiempo de inactividad esté
próximo a cero y que los servicios sean confiables. Cuando la estabilidad operativa es una prioridad, el
patrimonio digital debe medirse con respecto al impacto positivo o negativo en las operaciones estables.
La continuidad empresarial, la recuperación ante desastres y la confiabilidad tanto de las cargas de
trabajo como de todos y cada uno de los recursos son medidas obligatorias que deben adoptarse cuando
la estabilidad operativo es una prioridad.
Una vez que una organización comprende la forma de transformación más importante, el planeamiento del
patrimonio digital se hace mucho más fácil de administrar.
Cada tipo de transformación se puede medir con cualquiera de las vistas anteriores. Las empresas suelen
completar todas estas transformaciones en paralelo. Es muy recomendable que la directiva de la empresa y
el equipo de estrategia en la nube alcancen un acuerdo sobre qué tipo de transformación es la más
importante para conseguir el éxito empresarial. Esto sirve como base para encontrar un lenguaje y una
métrica comunes en varias iniciativas.
¿Cómo se puede actualizar un modelo financiero para reflejar el

patrimonio digital?
Un análisis del patrimonio digital impulsa las actividades de adopción de la nube. También informa de los
modelos financieros, para lo que proporciona modelos de costos de la nube, lo que, a su vez, impulsa la
rentabilidad de la inversión (ROI).
Para completar el análisis del patrimonio digital, realice los pasos siguientes:
1. Determine el enfoque de análisis.
2. Recopile el inventario del estado actual.
3. Racionalice los recursos del patrimonio digital.
4. Alinee los recursos con las ofertas de la nube para calcular los precios.
Los modelos financieros y trabajos pendientes de la migración se pueden modificar para que reflejen el
patrimonio racionalizado y tasado.
Pasos siguientes
Antes de comenzar el planeamiento del patrimonio digital, determine qué enfoque usar.
Enfoques de planeamiento del patrimonio digital
Enfoques de planeamiento del patrimonio digital
El planeamiento del patrimonio digital puede adoptar varias formas, según los resultados deseados y el tamaño
del patrimonio existente. Hay varios enfoques que se pueden adoptar. Es importante establecer expectativas
respecto al enfoque al principio de los ciclos de planeamiento. Unas expectativas poco claras suelen dar lugar a
retrasos asociados con ejercicios adicionales de recopilación de inventario. En este artículo se describen tres
enfoques de análisis.
Enfoque basado en la carga de trabajo

El enfoque de evaluación de arriba a abajo evalúa aspectos de seguridad. La seguridad incluye requisitos de
clasificación de los datos (impacto empresarial alto, medio o bajo), cumplimiento, soberanía y riesgo de
seguridad. Este enfoque evalúa la complejidad general de la arquitectura. Evalúa aspectos como la autenticación,
la estructura de datos, los requisitos de latencia, las dependencias y la esperanza de vida de las aplicaciones.
El enfoque de arriba a abajo también mide los requisitos operativos de la aplicación, como los niveles de
servicio, la integración, las ventanas de mantenimiento, la supervisión y la información. Cuando todos estos
aspectos se han analizado y tenido en cuenta, la puntuación resultante refleja la dificultad relativa de migrar esta
aplicación a cada una de las plataformas en la nube: IaaS, PaaS y SaaS.
Además, la valoración de arriba a abajo evalúa las ventajas financieras de la aplicación, como las eficiencias
operativas, el TCO, la rentabilidad de la inversión y otras métricas financieras adecuadas. La valoración también
examina la estacionalidad de la aplicación (por ejemplo, si existen picos de demanda en algunos momentos del
año) y la carga de proceso general.
Además, examina los tipos de usuarios que admite (ocasional/experto, conectado siempre/ocasionalmente) y la
escalabilidad y elasticidad necesarias. Por último, la valoración examina los requisitos de continuidad
empresarial y resistencia, así como las dependencias para ejecutarla en caso de que se produzca una
interrupción del servicio.
TIP
Para llevar a cabo este enfoque se requieren entrevistas y comentarios anecdóticos de las partes interesadas
empresariales y técnicas. El principal riesgo para el tiempo es la disponibilidad de los individuos clave. La naturaleza
anecdótica de los orígenes de datos hace que sea más difícil realizar estimaciones precisas de costo y tiempo. Planee de
antemano el calendario y valide todos los datos recopilados.
Enfoque basado en los recursos

El enfoque basado en los recursos proporciona un plan basado en los recursos que admiten una aplicación que
se va a migrar. En este enfoque, se extraen datos de uso estadísticos de una base de datos de administración de
configuración (CMDB) u otras herramientas de valoración de la infraestructura.
Normalmente, en este enfoque se da por hecho un modelo IaaS de implementación como base de referencia. En
este proceso, el análisis evalúa los atributos de cada recurso: memoria, número de procesadores (núcleos de
CPU), espacio de almacenamiento del sistema operativo, unidades de datos, tarjetas de interfaz de red (NIC),
IPv6, equilibrio de carga de red, agrupación en clústeres, versión del sistema operativo, versión de la base de
datos (si fuese necesario), dominios admitidos y componentes o paquetes de software de terceros, entre otros.
Los recursos inventariados en este enfoque luego se alinean con las cargas de trabajo o las aplicaciones con
fines de agrupación y asignación de dependencias.
TIP
Para llevar a cabo este enfoque se requiere un origen abundante de datos de uso estadísticos. El tiempo necesario para
examinar el inventario y recopilar datos es el principal riesgo para el cumplimiento de los plazos. Los orígenes de datos de
bajo nivel pueden perder las dependencias entre recursos o aplicaciones. Planee el examen del inventario durante un mes
por lo menos. Valide las dependencias antes de la implementación.
Enfoque incremental
Se recomienda encarecidamente un enfoque incremental, como para muchos procesos del Marco de adopción
de la nube. En el caso del planeamiento del patrimonio digital, eso equivale a un proceso de varias fases:
Análisis de costos inicial: si se requiere validación financiera, comience con un enfoque basado en los
recursos, descrito anteriormente, a fin de obtener un cálculo de costos inicial de todo el patrimonio
digital, sin racionalización. Esto establece una referencia de escenario del peor caso.
Planear la migración: una vez formado un equipo de estrategia de la nube, cree un trabajo pendiente
de migración inicial mediante un enfoque basado en la carga de trabajo que se base en su conocimiento
colectivo y algunas entrevistas con las partes interesadas. Este enfoque crea rápidamente una valoración
de la carga de trabajo ligera para fomentar la colaboración.
Planeamiento de versiones: en cada versión, el trabajo pendiente de migración se elimina y se vuelve
a clasificar por orden de prioridad para centrarse en el impacto empresarial más relevante. Durante este
proceso, se seleccionan entre cinco y diez de las cargas de trabajo siguientes como versiones con
prioridad. En este punto, el equipo de estrategia de la nube dedica tiempo a realizar un enfoque
exhaustivo basado en la carga de trabajo. El hecho de retrasar esta valoración hasta que haya una versión
alineada respeta mejor el tiempo de las partes interesadas. También retrasa la inversión en un análisis
completo hasta que la empresa comience a ver resultados de los esfuerzos anteriores.
Análisis de ejecución: antes de migrar, modernizar o replicar cualquier recurso, evalúelo de forma
individual y como parte de una versión colectiva. En este momento, se pueden escrutar los datos del
enfoque anterior basado en los recursos para garantizar el tamaño preciso y las restricciones
operacionales.
TIP
Este enfoque incremental permite un planeamiento simplificado y unos resultados acelerados. Es importante que todas las
partes implicadas entiendan el enfoque de toma de decisiones diferida. Es igualmente importante que se documenten los
supuestos realizados en cada fase para evitar la pérdida de detalles.
Pasos siguientes
Una vez seleccionado un enfoque, se puede recopilar el inventario.
Recopilación de datos de inventario
Recopilación de datos de inventario de un
patrimonio digital
El desarrollo de un inventario es el primer paso del planeamiento del patrimonio digital. En este proceso, se
recopila una lista de los recursos de TI que posibilitan funciones de negocio específicas para su posterior análisis
y racionalización. En este artículo se da por supuesto que un análisis de abajo hacia arriba es el más adecuado
para el planeamiento de las necesidades. Para más información, consulte Enfoques para el planeamiento del
patrimonio digital.
Realizar un inventario de un patrimonio digital

El inventario que posibilita un patrimonio digital cambia en función de la transformación digital deseada y el
recorrido de transformación correspondiente.
Migración a la nube. Suele ser recomendable que, durante una migración a la nube, recopile el
inventario con herramientas de análisis que crean una lista centralizada de todas las máquinas virtuales y
los servidores. Algunas herramientas también pueden crear mapas de red y dependencias, lo que ayuda
a definir la alineación de la carga de trabajo.
Innovación en las aplicaciones. Durante un esfuerzo de innovación en aplicaciones habilitadas para la
nube, el inventario comienza con el usuario. Un buen lugar para comenzar es la asignación de la
experiencia del cliente de principio a fin. La alineación de dicha asignación con las aplicaciones, API, datos
y otros recursos produce un inventario detallado para el análisis.
Innovación en los datos. Los esfuerzos de innovación en datos habilitados para la nube se centran en
el producto o servicio. Un inventario incluye también una asignación de las oportunidades para romper
el mercado, así como las funcionalidades necesarias.
Seguridad: El inventario proporciona seguridad para ayudar a evaluar, proteger y supervisar los
recursos de la organización.
Precisión e exhaustividad de un inventario

Un inventario rara vez se completa totalmente en su primera iteración. Es muy recomendable que el equipo de
estrategia de la nube coordine a las partes interesadas y los usuarios avanzados para validar el inventario.
Cuando sea posible, use herramientas adicionales, como el análisis de la red y las dependencias, para identificar
los recursos a los que se está enviando tráfico, pero no están en el inventario.
Pasos siguientes
Una vez que se recopila y valida un inventario, se puede racionalizar. La racionalización del inventario es el
siguiente paso en el planeamiento del patrimonio digital.
La racionalización de la nube es el proceso de evaluación de los recursos para determinar el mejor enfoque para
hospedarlos en la nube. Una vez que haya determinado el enfoque y que haya agregado un inventario, puede
comenzar la racionalización de la nube. En Racionalización de la nube se describen las opciones de
racionalización más comunes.
Vista tradicional de la racionalización

La racionalización es fácil de entender cuando el proceso tradicional de racionalización se visualiza como un
árbol de decisión complejo. Cada recurso del patrimonio digital se introduce mediante un proceso que da como
resultado una de las cinco respuestas (las cinco "R" de la racionalización). Para pequeños patrimonios, este
proceso funciona bien. Para patrimonios mayores, no es eficaz y puede dar lugar a retrasos importantes. Vamos
a examinar el proceso para comprender el motivo. Después, presentaremos un modelo más eficiente.
Inventario. Se requiere un inventario completo de los recursos, incluidas aplicaciones, software, hardware,
sistemas operativos y métricas de rendimiento del sistema para completar una racionalización completa
mediante modelos tradicionales.
Análisis cuantitativo. En el árbol de decisión, las preguntas cuantitativas conducen a la primera capa de
decisiones. Estas son algunas de las preguntas más habituales:
¿Está el recurso en uso hoy en día?
Si es así, ¿está optimizado y dimensionado correctamente?
¿Qué dependencias existen entre los recursos? Estas preguntas son fundamentales para la clasificación del
inventario.
Análisis cualitativo. El siguiente conjunto de decisiones requiere inteligencia humana en forma de análisis
cualitativo. A menudo, estas preguntas son exclusivas de la solución y solo las partes interesadas de la empresa
y los usuarios avanzados pueden responderlas. Estas decisiones son las que generalmente retrasan el proceso y
ralentizan todo considerablemente. Este análisis generalmente consume de 40 a 80 horas de empleados a
tiempo completo por aplicación.
Para ver una guía sobre la elaboración de una lista de preguntas de análisis cualitativo, consulte Enfoques de
planeamiento del patrimonio digital.
Decisión de racionalización. En manos de un equipo de racionalización experimentado, los datos cualitativos
y cuantitativos crean decisiones claras. Desafortunadamente, los equipos con un alto grado de experiencia en
racionalización son caros de contratar o tardan meses en entrenarse.
Racionalización a escala empresarial

Si este esfuerzo consume mucho tiempo y es desalentador para un patrimonio digital de 50 máquinas virtuales,
nos podemos imaginar el esfuerzo necesario para impulsar la transformación del negocio en un entorno con
miles de máquinas virtuales y cientos de aplicaciones. El esfuerzo humano requerido puede fácilmente exceder
las 1500 horas de empleados a tiempo completo y 9 meses de planeamiento.
Si bien la racionalización completa es el objetivo final y un gran camino a seguir, rara vez produce una elevada
rentabilidad de la inversión con relación al tiempo y la energía requeridos.
Cuando la racionalización es esencial para las decisiones financieras, vale la pena considerar la posibilidad de
usar una organización de servicios profesionales especializada en la racionalización de la nube para acelerar el
proceso. Incluso así, la racionalización completa puede resultar un esfuerzo costoso y lento que retrase la
transformación o los resultados del negocio.
En el resto de este artículo se describe un enfoque alternativo, conocido como racionalización incremental.
Racionalización incremental
La racionalización completa de un gran patrimonio digital es propensa al riesgo y puede sufrir retrasos debido a
su complejidad. El supuesto que subyace tras el enfoque incremental es que la demora en la toma de decisiones
escalona la carga sobre el negocio y reduce el riesgo de obstáculos. Con el tiempo, este enfoque crea un modelo
orgánico para desarrollar los procesos y la experiencia necesarios para tomar decisiones de racionalización
cualificadas de manera más eficiente.
Inventario: Reducción de los puntos de datos de detección
Pocas organizaciones invierten el tiempo, la energía y los gastos necesarios para mantener un inventario preciso
y en tiempo real de todo el patrimonio digital. La pérdida, el robo, los ciclos de actualización y la incorporación
de empleados a menudo justifican el seguimiento detallado de los recursos de los dispositivos de los usuarios
finales. La rentabilidad de la inversión que supone mantener un inventario preciso de los servidores y las
aplicaciones en un centro de datos local tradicional suele ser baja. La mayoría de las organizaciones de TI tienen
problemas más urgentes que resolver que el seguimiento del uso de los recursos en un centro de datos.
En una transformación a la nube, el inventario está directamente relacionado con los costos operativos. Se
requieren datos de inventario precisos para un planeamiento adecuado. Lamentablemente, las opciones
actuales de análisis del entorno pueden retrasar las decisiones durante semanas o meses. Afortunadamente, hay
algunos trucos que pueden acelerar la recopilación de los datos.
El análisis basado en agente es el retraso citado con más frecuencia. Los datos sólidos que se requieren para una
racionalización tradicional a menudo solo pueden recopilarse con un agente que se ejecuta en cada recurso. Esta
dependencia de los agentes ralentiza el progreso porque puede requerir comentarios de las funciones de
seguridad, operaciones y administración.
En un proceso de racionalización incremental, se podría utilizar una solución sin agentes para una detección
inicial a fin de acelerar las decisiones tempranas. Dependiendo del nivel de complejidad del entorno, se puede
necesitar una solución basada en agentes, pero puede eliminarse de la ruta crítica al cambio de negocio.
Análisis cuantitativo: Optimización de las decisiones
Con independencia del enfoque de la detección de inventario, el análisis cuantitativo puede conducir a una serie
de decisiones y supuestos iniciales. Esto es especialmente cierto cuando se trata de identificar la primera carga
de trabajo o cuando el objetivo de la racionalización es una comparación de costos de alto nivel. En un proceso
de racionalización incremental, los equipos de adopción y estrategia de la nube limitan las 5 R de la
racionalización a dos decisiones concisas y solo aplican esos factores cuantitativos. Esto simplifica el análisis y
reduce la cantidad de datos iniciales necesarios para impulsar el cambio.
Por ejemplo, si una organización se encuentra en medio de una migración de IaaS a la nube, se puede suponer
que la mayoría de las cargas de trabajo se retirarán o se volverán a hospedar.
Análisis cualitativo: Supuestos temporales
Al reducir el número de resultados potenciales, es más fácil tomar una decisión inicial sobre el estado futuro de
un recurso. Cuando se reducen las opciones, también se reduce el número de preguntas que se formulan a la
empresa en esta fase inicial.
Por ejemplo, si las opciones se limitan a rehospedar o retirar, la empresa solo debe responder a una pregunta
durante la racionalización inicial, que es si se va a retirar el recurso.
"El análisis sugiere que ningún usuario está utilizando activamente este recurso. ¿Es eso correcto o se nos ha
pasado algo por alto?" Una pregunta binaria de este tipo es generalmente mucho más fácil de ejecutar mediante
un análisis cualitativo.
Este enfoque simplificado produce líneas de base, planes financieros, estrategia y dirección. En actividades
posteriores, cada recurso pasa por una mayor racionalización y un análisis cualitativo para evaluar otras
opciones. Todas las suposiciones que realice en esta racionalización inicial se prueban antes de migrar cargas de
trabajo individuales.
Supuestos desafiantes
El resultado de la sección anterior es una racionalización aproximada cargada de supuestos. A continuación, es
hora de cuestionar algunos de estos supuestos.
Retirar recursos
En un entorno local tradicional, hospedar recursos pequeños no utilizados rara vez tiene un impacto
significativo en los costos anuales. Con algunas excepciones, el ahorro de costos derivado de la limpieza y
retirada de estos recursos se compensa por el tiempo de empleados a tiempo completo requerido para analizar
y retirar el recurso.
Cuando se pasa a un modelo de contabilidad en la nube, la retirada de recursos puede generar ahorros
significativos en los costos operativos anuales y en los esfuerzos iniciales de migración.
No es raro que las organizaciones retiren el 20 % o más de su patrimonio digital después de completar un
análisis cuantitativo. Es recomendable realizar un análisis cualitativo adicional antes de pasar a la acción. Una
vez confirmada, la retirada de esos recursos puede producir la primera victoria de la migración a la nube en
cuanto a la rentabilidad de la inversión. A menudo, este es uno de los mayores factores de ahorro de costos. Por
lo tanto, el equipo de estrategia de la nube debe supervisar la validación y la retirada de recursos, en paralelo a
la ejecución de la metodología de migración, para lograr una ganancia financiera temprana.
Ajustes del programa
Una empresa rara vez se embarca en un único viaje de transformación. La elección entre reducción de costos,
crecimiento del mercado y nuevas fuentes de ingresos rara vez es una decisión binaria. Por lo tanto, es
recomendable que el equipo de estrategia de la nube trabaje con el departamento de TI para identificar los
recursos que haya en esfuerzos de transformación paralelos y que estén fuera del alcance del recorrido de
transformación principal.
En el ejemplo de migración de IaaS que se utiliza en este artículo:
Pida al equipo de DevOps que identifique los recursos que ya forman parte de una automatización de la
implementación y los quite del plan de migración principal.
Pida a los equipos de datos e I+D que identifiquen los recursos que impulsan nuevas fuentes de ingresos
y que los quiten del plan de migración principal.
Este análisis cualitativo enfocado en el programa se puede ejecutar rápidamente y producirá la alineación de los
diferentes trabajos pendientes de migración.
Tal vez tenga que considerar algunos recursos para rehospedaje durante un tiempo. Puede realizar una
racionalización posterior después de la migración inicial.
Seleccionar la primera carga de trabajo

Implementar la primera carga de trabajo es clave para realizar pruebas y aprender. Es la primera oportunidad
para demostrar y crear una mentalidad de crecimiento.
Criterios de negocio
Para garantizar la transparencia del negocio, identifique una carga de trabajo admitida por un miembro de la
unidad de negocio del equipo de estrategia de la nube. Preferiblemente, elija una en la que el equipo tenga un
interés personal y una fuerte motivación para pasarla a la nube.
Criterios técnicos
Seleccione una carga de trabajo que tenga dependencias mínimas y que se pueda desplazar como un pequeño
grupo de recursos. Se recomienda seleccionar una carga de trabajo con una ruta de pruebas definida para
facilitar la validación.
La primera carga de trabajo se implementa a menudo en un entorno experimental sin capacidad operativa ni de
gobernanza. Es muy importante seleccionar una carga de trabajo que no interactúe con datos seguros.
Análisis cualitativo
Los equipos de adopción y estrategia de la nube pueden trabajar juntos para analizar esta pequeña carga de
trabajo. Esta colaboración ofrece una oportunidad controlada de crear y probar criterios de análisis cualitativo.
La población más pequeña ofrece la oportunidad de encuestar a los usuarios afectados para realizar un análisis
cualitativo detallado en una semana o menos. Para conocer los factores comunes de análisis cualitativo, consulte
el objetivo de racionalización específico en las cinco "R" de la racionalización.
Migración
Paralelamente a la racionalización continua, el equipo de adopción de la nube puede comenzar a migrar la
pequeña carga de trabajo para ampliar el aprendizaje en las siguientes áreas clave:
Reforzar las habilidades con la plataforma del proveedor de nube.
Definir los servicios básicos y estándares de Azure necesarios para ajustarse a la visión a largo plazo.
Comprender mejor cómo las operaciones pueden necesitar cambiar más adelante en la transformación.
Comprender los riesgos inherentes al negocio y la tolerancia del negocio a esos riesgos.
Establecer un producto mínimamente viable (MVP) o de referencia para la gobernanza basado en la
tolerancia al riesgo del negocio.
Planeamiento de la versión
Mientras el equipo de adopción de la nube ejecuta la migración o implementación de la primera carga de
trabajo, el equipo de estrategia de la nube puede empezar a priorizar las aplicaciones o cargas de trabajo
restantes.
La potencia de 10
En el enfoque tradicional de la racionalización, se intentan abordar todas las necesidades previsibles.
Afortunadamente, a menudo no se requiere un plan para cada aplicación para iniciar un viaje de
transformación. En un modelo incremental, el enfoque de la potencia de 10 proporciona un buen punto inicial.
En este modelo, el equipo de estrategia de la nube selecciona las primeras diez aplicaciones que se van a migrar.
Esas diez cargas de trabajo deben contener una mezcla de cargas de trabajo simples y complejas.
Creación de los primeros trabajos pendientes
Los equipos de adopción y estrategia de la nube pueden trabajar juntos en el análisis cualitativo de las diez
primeras cargas de trabajo. Este esfuerzo crea el primer trabajo pendiente de migración con prioridad y el
primer trabajo pendiente de versión con prioridad. Este enfoque permite a los equipos iterar sobre el enfoque y
proporciona tiempo suficiente para crear un proceso adecuado para el análisis cualitativo.
Maduración del proceso
Cuando los dos equipos se ponen de acuerdo sobre los criterios de análisis cualitativo, la evaluación puede
convertirse en una tarea dentro de cada iteración. Alcanzar el consenso sobre los criterios de evaluación suele
requerir dos o tres versiones.
Una vez que la evaluación se traslada a los procesos de ejecución incremental de la migración, el equipo de
adopción de la nube puede iterar más rápidamente en la evaluación y arquitectura. En esta etapa, el equipo de
estrategia de nube también se abstrae, lo que reduce el consumo de tiempo. Esto también permite que el equipo
de estrategia de la nube se centre en priorizar las aplicaciones que aún no tienen una versión específica, lo que
asegura una alineación ajustada con las condiciones cambiantes del mercado.
No todas las aplicaciones con prioridad estarán listas para la migración. Es probable que la secuencia cambie, ya
que el equipo realiza un análisis cualitativo más profundo y descubre eventos y dependencias que podrían dar
lugar a una nueva priorización de los trabajos pendientes. Algunas versiones pueden agrupar un pequeño
número de cargas de trabajo. Otras podrían contener una única carga de trabajo.
Es probable que el equipo de adopción de la nube ejecute iteraciones que no produzcan una migración
completa de la carga de trabajo. Cuanto menor sea la carga de trabajo y menor sea el número de dependencias,
mayor será la probabilidad de que una carga de trabajo se adapte a un solo sprint o iteración. Por este motivo,
es recomendable que las primeras aplicaciones de la lista de trabajos pendientes sean pequeñas y contengan
pocas dependencias externas.
Finalización del estado

Con el tiempo, los equipos de adopción y estrategia de la nube realizarán juntos una racionalización completa
del inventario. Este enfoque incremental permite a los equipos ser más ágiles en el proceso de racionalización.
También permite que el recorrido de transformación produzca resultados de negocio tangibles antes, sin un
esfuerzo de análisis inicial tan grande.
En algunos casos, el modelo financiero puede ser demasiado estricto para tomar una decisión sin una
racionalización adicional. En estos casos, quizás sea necesario un enfoque más tradicional de la racionalización.
Pasos siguientes
El resultado de un esfuerzo de racionalización es un trabajo pendiente priorizado de todos los recursos
afectados por la transformación elegida. Este trabajo pendiente ya está listo para servir de base para los
modelos de cálculo de costos de los servicios en la nube.
Alineación de los modelos de costos con el patrimonio digital
Alineación de los modelos de costos con el
patrimonio digital para prever los costos en la nube
Una vez que se ha racionalizado un patrimonio digital, se puede alinear con modelos de costos equivalentes con
el proveedor de nube elegido. Es difícil hablar de los modelos de costos sin centrarse en un proveedor en la
nube específico. Para proporcionar ejemplos tangibles en este artículo, se asume que Azure es el proveedor en
la nube.
Las herramientas de precios de Azure ayudan a administrar el gasto en la nube con transparencia y precisión,
para obtener el máximo provecho de Azure y otras nubes. Le proporciona las herramientas necesarias para
supervisar, asignar y optimizar los costos de la nube para que pueda impulsar las inversiones en el futuro con
confianza.
Azure Migrate: Azure Migrate es quizás el enfoque más rentable para la alineación del modelo de costos.
Esta herramienta permite el inventario del patrimonio digital, una racionalización limitada y los cálculos
de costos en una herramienta.
Calculadora del costo total de propiedad (TCO): Reduzca el costo total de propiedad de la infraestructura
local con la plataforma en la nube de Azure. Utilice la calculadora de TCO de Azure para calcular el ahorro
de costos que puede lograr al migrar las cargas de trabajo de aplicación a Azure. Proporcione una breve
descripción del entorno local para obtener un informe instantáneo.
Calculadora de precios de Azure: estime la factura mensual prevista con la calculadora de precios. Realice
un seguimiento del uso y facturación reales de la cuenta en cualquier momento mediante el portal de
facturación. Configure alertas de facturación automáticas por correo electrónico para recibir una
notificación si el gasto sobrepasa una cantidad especificada.
Azure Cost Management y facturación: Azure Cost Management + Billing es una solución de
administración de costos que le ayuda a usar y administrar Azure y otros recursos en la nube de manera
eficaz. Recopile datos de uso y facturación de recursos en la nube con interfaces de programación de
aplicaciones (API) de Azure, Amazon Web Services y Google Cloud Platform. Con esos datos, se obtiene
visibilidad total del consumo de recursos y de los costos de todas las plataformas en la nube en una única
vista unificada. Supervise de forma constante el consumo de recursos en la nube y las tendencias de los
costos. Realice un seguimiento del gasto real en la nube respecto al presupuesto para evitar los
sobrecostos. Detecte anomalías en el gasto y deficiencias en el uso. Utilice los datos históricos para
mejorar la exactitud de las previsiones de uso de recursos en la nube y los gastos correspondientes.
Medición de resultados empresariales con
AppDynamics
La correcta medición y cuantificación de los resultados empresariales es una parte fundamental de cualquier
estrategia de adopción de la nube. Comprender la experiencia del usuario y el rendimiento de una aplicación es
fundamental para medir esos resultados empresariales. Sin embargo, medir con exactitud la correlación entre el
rendimiento de la aplicación, la experiencia del usuario y su efecto en la empresa suele ser difícil, poco preciso y
lento.
AppDynamics puede proporcionar información empresarial para la mayoría de los casos y muchas
organizaciones que inician una estrategia completa de adopción de la nube lo hacen por los siguientes motivos:
Una comparación entre la situación anterior y posterior a una migración
Estado de la empresa
Validación de un lanzamiento
Estado del segmento
Recorridos de usuario
Recorridos empresariales
Embudos de conversión
Esta guía se centrará en cómo medir los resultados empresariales en una comparación entre la situación
anterior y posterior a una migración, y en cómo acelerar y reducir el riesgo de una migración durante el
recorrido de adopción de la nube.
Funcionamiento de AppDynamics
Antes de la migración, se implementa un pequeño agente ligero junto con sus aplicaciones. Los agentes se
compilan específicamente para varios lenguajes como .NET, Java y Node.js. El agente recopila datos de
rendimiento y diagnóstico durante la migración y los envía a un controlador para que los correlacione y analice
la información. Los controladores pueden residir en un entorno de AppDynamics totalmente administrado, o el
cliente puede elegir administrarlos en Azure. Las experiencias de usuario claves se identifican como
transacciones comerciales, lo que le ayuda a detectar la línea de base del rendimiento normal de la aplicación o
la empresa. Tanto si se trata de una infraestructura tradicional de servidores, bases de datos, componentes de
middleware, un entorno local o en la nube, todos los componentes y dependencias de la aplicación se identifican
en tiempo real para toda la aplicación y para cada transacción empresarial.
Figura 1: Mapa de flujo de AppDynamics.
AppDynamics identifica las métricas empresariales

AppDynamics ayuda a definir el valor empresarial de las aplicaciones, identificar las métricas clave que se deben
alcanzar para mantener su valor y comprobar si están logrando sus objetivos de resultados empresariales. Los
agentes de AppDynamics recopilan estos puntos de datos y las métricas de rendimiento tradicionales de las
aplicaciones, como el tiempo de respuesta y el uso de memoria en tiempo real, directamente de la aplicación y
sin realizar cambios en el código.
Las métricas empresariales están estrechamente relacionadas con los resultados empresariales. Muchas
organizaciones tienen métricas complejas que miden resultados empresariales exclusivos, y estos resultados
pueden abarcar desde resultados fiscales y de agilidad a objetivos de rendimiento y de involucración del cliente.
AppDynamics recopila las métricas que son específicas y que resultan útiles para su organización. Esas métricas
pueden contribuir a las operaciones empresariales actuales antes y después de mirar las cargas de trabajo a
Azure.
Ejemplo :
Una empresa que vende widgets en un marketplace en línea ha identificado las siguientes transacciones
comerciales clave en su aplicación web:
Página de aterrizaje
Agregar al carro
Envío
Facturación
Confirmación de pedidos
Estos tipos de transacciones comerciales son comunes a las aplicaciones de comercio electrónico. Un embudo
de conversión es el recorrido que un usuario realiza a través de estas páginas y que conduce directamente a los
ingresos por ventas en la plataforma de la empresa. Si los usuarios abandonan el recorrido debido a un
rendimiento deficiente de la página o a errores, esto afectará directamente a los beneficios subyacentes de la
empresa.
Además, la compañía ha identificado las siguientes métricas empresariales clave:
Artículos totales en el carrito
Segmentos de cliente
Ubicaciones del cliente
La combinación de las métricas de rendimiento empresarial y de la aplicación ayuda a demostrar claramente
cómo se relaciona el rendimiento de la aplicación con sus beneficios subyacentes. Este nivel de visibilidad y los
tipos de información serán esenciales durante las migraciones.
Los paneles configurables son una de las muchas herramientas de AppDynamics que permiten visualizar esta
información. En este ejemplo en tiempo real, vemos el embudo de conversión general y el impacto en el
rendimiento de cada una de las páginas en relación con el número de usuarios que abandona la página, junto
con los artículos totales del carrito, el segmento del cliente, la ubicación y la información general de ingresos.
Figura 2: Panel de impacto empresarial de AppDynamics.
Recursos para ayudar a identificar las métricas empresariales

Las secciones sobre estrategia y resultados empresariales de Cloud Adoption Framework proporcionan las
instrucciones y estrategias que le ayudarán a identificar los resultados empresariales de su organización.
Comparación entre la situación anterior y posterior a una migración

La nube ofrece grandes ventajas y posibilidades, pero los primeros pasos de una migración a menudo son
confusos y bastante arriesgados. Se deben emplear más criterios para evaluar una migración satisfactoria que
para evaluar la capacidad de una implementación correcta. Comprender la experiencia del usuario y el
rendimiento empresarial antes y después de la migración a la nube le ayudará a ajustar y estabilizar ambos
criterios cuando sea necesario, lo que puede ayudarle a generar unos resultados empresariales satisfactorios a
la vez que a aumentar el valor que proporciona Azure durante el recorrido de la migración.
Para basarse en la comprensión de cómo AppDynamics proporciona métricas empresariales y de aplicaciones,
compare esas métricas antes y después de una migración para evaluar su grado de éxito y si se consiguen los
resultados empresariales de destino.
Ejemplo :
Movie Tickets Online, una empresa en línea ficticia de venta de entradas, está trabajando para retirar sus centros
de recursos existentes y trasladar sus cargas de trabajo a Azure. Sus problemas de capacidad han dado lugar a
un rendimiento deficiente de las transacciones empresariales y confían en las optimizaciones de rendimiento y
en la capacidad que les ofrece Azure.
Además de mejorar el rendimiento, quieren asegurarse de que se consiguen los resultados empresariales de
mejora del embudo de ventas y aumento de los ingresos. Como parte de su migración, han implementado
AppDynamics en sus entornos locales existentes para comprender con claridad su rendimiento actual. Como
parte de la implementación de la nube, Movie Tickets Online puede usar la integración nativa de AppDynamics
con Azure para comprender el rendimiento y los resultados empresariales en la etapa posterior a la migración.
En este caso, pudieron ver un aumento en las tasas de conversión del 48 al 79 por ciento y mejoras en el
rendimiento subyacente, el tiempo de respuesta y el volumen de ventas de entradas.
Figura 3: Comparación de migraciones de AppDynamics.
Pasos siguientes
AppDynamics ofrece a las organizaciones la capacidad única de medir los resultados empresariales durante la
estrategia de adopción de la nube. Visite AppDynamics para más información sobre AppDynamics con Azure.
Alineación inicial de la organización
El aspecto más importante de cualquier plan de adopción de la nube es la alineación de las personas que harán
realidad el plan. Ningún plan está completo hasta que comprenda los aspectos relacionados con las personas.
La verdadera alineación de la organización lleva tiempo. Será importante para establecer la alineación
organizacional a largo plazo, especialmente a medida que la adopción de la nube se escala en la cultura del
negocio y de TI. La alineación es tan importante que se ha dedicado a ella una sección completa en metodología
de organización de Cloud Adoption Framework.
La alineación total de la organización no es un componente obligatorio del plan de adopción de la nube. Sin
embargo, es necesaria cierta alineación inicial de la organización. En este artículo se describe un punto de
partida del procedimiento recomendado para la alineación de la organización. Las instrucciones siguientes
pueden ayudarle a completar el plan y preparar a sus equipos para la adopción de la nube. Cuando esté listo,
puede usar la sección alineación de la organización para personalizar esta guía para ajustarla a su organización.
Estructura inicial del procedimiento recomendado

Para crear un equilibrio entre velocidad y control, se recomienda que durante la adopción de la nube, como
mínimo, tenga personas responsables de la adopción de la nube y de la gobernanza de la nube. Puede tratarse
de un equipo de personas que compartan responsabilidades para cada una de estas áreas o funcionalidades.
También puede tratarse de personas individuales que son responsables de los resultados y del trabajo. En
ambos escenarios, la adopción de la nube y la gobernanza de la nube son dos funcionalidades que implican una
fricción natural entre el movimiento rápido y la reducción de riesgos. Así se podrían ajustar los dos equipos:
Es bastante intuitivo que las tareas de adopción de la nube requieren personas que ejecuten dichas tareas. Por lo
tanto, a pocas personas les sorprende que el equipo de adopción de la nube sea un requisito. Sin embargo, es
posible que las personas que no estén familiarizadas con la nube no aprecien totalmente la importancia de un
equipo de gobernanza de la nube. Este desafío suele producirse en las primeras etapas de los ciclos de
adopción. El equipo de gobernanza de la nube proporciona las comprobaciones y los equilibrios necesarios para
garantizar que la adopción de la nube no expone el negocio a nuevos riesgos. Cuando se deban tomar riesgos,
este equipo garantiza que se implementan los procesos y controles adecuados para mitigar o controlar esos
riesgos.
Para obtener más información sobre la adopción de la nube, la gobernanza de la nube y otras funcionalidades
de este tipo, consulte la breve sección sobre la descripción de las funcionalidades necesarias en la nube.
Asignación de personas a funcionalidades

Suponiendo que la estructura sugerida se alinea con el plan de adopción de la nube, el siguiente paso consiste
en asignar personas específicas a las funcionalidades necesarias. Para ello, responda a las siguientes preguntas:
¿Qué persona (o grupo de personas) será responsable de completar las tareas técnicas del plan de adopción
de la nube?
¿Qué persona será responsable de la capacidad del equipo para entregar cambios técnicos?
¿Qué persona (o grupo de personas) será responsable de la implementación de mecanismos de gobernanza
de protección?
¿Qué persona será responsable de la definición de esos controles de gobernanza?
¿Existen otras funcionalidades o personas que tengan responsabilidad en el plan de adopción de la nube?
Una vez que haya documentado las respuestas a estas preguntas, puede establecer planes de preparación de las
aptitudes para definir planes para preparar a estas personas para el futuro trabajo.
Pasos siguientes
Información sobre el plan para la adopción de la nube.
Plan para la adopción de la nube
Adaptación de los roles, las aptitudes y los procesos
existentes a la nube
En cada fase de la historia del sector de TI, los cambios más importantes vienen a menudo marcados por
cambios en los roles del personal. Un ejemplo es la transición de la informática de grandes sistemas a la
informática cliente/servidor. El rol del operador de equipos desapareció en gran medida, reemplazado por el rol
de administrador del sistema. Cuando llegó la virtualización, disminuye el número de personas que trabajan con
servidores físicos, reemplazado por una necesidad de especialistas en virtualización.
A medida que las instituciones se desplacen a la informática en la nube, los roles probablemente cambiarán. Por
ejemplo, los especialistas en centros de datos podrían reemplazarse por administradores de la nube o
arquitectos de la nube. En algunos casos, aunque los nombres de los puestos de trabajo de TI no hayan
cambiado, el trabajo diario de estos roles ha cambiado significativamente.
Los miembros del personal de TI pueden sentirse preocupados por sus roles y puestos porque se dan cuenta de
que se necesita un conjunto diferente de aptitudes para el trabajo con soluciones en la nube. Pero los empleados
ágiles que exploran y aprenden las nuevas tecnologías en la nube no tienen por qué preocuparse. Pueden dirigir
la adopción de los servicios en la nube y ayudar a la organización a aprender y adoptar los cambios asociados.
Para instrucciones sobre la creación de un nuevo conjunto de aptitudes, consulte Ruta de preparación de
aptitudes.
Detección de preocupaciones
A medida que la organización se prepara para un trabajo de adopción de la nube, cada equipo debe documentar
las preocupaciones del personal a medida que se producen mediante la identificación de:
Tipo de preocupación. Por ejemplo, es posible que los trabajadores sean resistentes a los cambios en las
tareas que acompañan al trabajo de adopción.
El impacto si no se trata la preocupación. Por ejemplo, la resistencia a la adopción podría dar lugar a que los
trabajadores sean lentos en la ejecución de los cambios necesarios.
El área preparada para solucionar el problema. Por ejemplo, si los empleados del departamento de TI son
reacios a adquirir nuevas habilidades, el área de responsables de TI está mejor preparada para solucionar
este problema. La identificación del área puede ser clara en el caso de algunas preocupaciones. En estos
casos, es posible que se necesite escalar al liderazgo ejecutivo.
Los miembros del personal de TI normalmente tienen preocupaciones sobre la adquisición del entrenamiento
necesario para desarrollar funciones ampliadas y nuevas tareas. Conocer las preferencias de entrenamiento del
equipo le ayudará a preparar un plan. También permite abordar estas preocupaciones.
Identificación de brechas
La identificación de brechas es otro aspecto importante de la preparación de la organización. Una brecha es un
rol, aptitud o proceso necesario para la transformación digital que no existe actualmente en la empresa.
1. Enumere las responsabilidades que acompañan a la transformación digital. Resalte las nuevas
responsabilidades y las responsabilidades existentes que se van a retirar.
2. Identifique el área que se alinea con cada responsabilidad. Para cada nueva responsabilidad, compruebe
cómo se alinea con el área. Algunas responsabilidades pueden abarcar varias áreas. Esta transversalidad
representa una oportunidad para una mejor alineación que se debe documentar como una preocupación. En
el caso de que ningún área se pueda identificar como responsable, se debe documentar como una brecha.
3. Identifique las aptitudes necesarias para desarrollar cada responsabilidad y compruebe si la empresa tiene
recursos existentes con esas aptitudes. Si no hay recursos existentes, determine los programas de
entrenamiento o la adquisición de talentos necesarios para rellenar las brechas. También puede determinar la
fecha límite en la que se debe desarrollar cada responsabilidad para mantener la transformación digital
dentro de la programación.
4. Identifique los roles que ejecutarán estas aptitudes. Algunos de los empleados existentes asumirán partes de
los roles. En otros casos, es posible que se necesiten roles completamente nuevos.
Trabajo entre equipos

Las aptitudes necesarias para llenar las brechas de la transformación digital de la organización normalmente no
estarán limitadas a un solo rol o incluso a un único departamento. Las aptitudes tendrán relaciones y
dependencias que pueden abarcar un único rol o varios roles. Esos roles pueden existir en varios
departamentos. Por ejemplo, un propietario de la carga de trabajo puede requerir una persona de un rol de TI
para aprovisionar recursos básicos como las suscripciones y los grupos de recursos.
Estas dependencias representan nuevos procesos que la organización implementa para administrar el flujo de
trabajo entre los roles. El ejemplo anterior muestra varios tipos de procesos que pueden posibilitar la relación
entre el propietario de la carga de trabajo y el rol de TI. Por ejemplo, puede crear una herramienta de flujo de
trabajo para administrar el proceso o usar una plantilla de correo electrónico.
Realice un seguimiento de estas dependencias y tome nota de los procesos que las posibilitarán. Anote también
si los procesos existen actualmente. Para aquellos procesos que precisen de herramientas, asegúrese de que la
escala de tiempo para la implementación de las herramientas se alinea con la programación de la
transformación digital en general.
Pasos siguientes
El aseguramiento del soporte técnico adecuado para los roles traducidos es un trabajo en equipo. Para actuar
según esta guía, revise la información general sobre la preparación de la organización para identificar los
participantes y las estructuras de equipo correctos.
Identificación de las estructuras de equipo correctas
Introducción a la ruta de preparación de las
aptitudes
Los miembros del personal de TI pueden sentirse preocupados por sus roles y puestos a medida que se dan
cuenta de que se necesita un conjunto diferente de aptitudes para el trabajo con soluciones en la nube. Los
empleados ágiles que exploran y aprenden las nuevas tecnologías en la nube no tienen por qué preocuparse.
Pueden dirigir la adopción de los servicios en la nube y ayudar a la organización a comprender y adoptar los
cambios asociados.
Figura 1: Asignación de aptitudes a roles de TI en un entorno hospedado en la nube.

Cloud Adoption Framework guía a los lectores a lo largo de todo el ciclo de vida de la adopción. A lo largo de
este marco, se proporcionan a los lectores oportunidades para crear las aptitudes necesarias. Para ayudarle a
comenzar en este recorrido, se incluyen artículos sobre la preparación de las aptitudes según el siguiente
esquema para facilitar el acceso. Cada uno de los vínculos siguientes se corresponde a las aptitudes necesarias
para el éxito en cada una de esas fases de adopción.
Estrategia : desarrolle las aptitudes necesarias para preparar un plan de migración accionable. Esto
incluye la justificación empresarial y otras aptitudes necesarias de planeamiento empresarial.
Planeamiento : desarrolle las aptitudes necesarias para preparar un plan de migración accionable. Esto
incluye la justificación empresarial y otras aptitudes necesarias de planeamiento empresarial.
Listo : desarrolle las aptitudes necesarias para preparar la empresa, la cultura, las personas y el entorno
para los cambios venideros.
Adopción: las aptitudes de adopción se alinean con varios trabajos técnicos:
Migración : adquiera las aptitudes necesarias para implementar el plan de migración a la nube.
Innovación: adquiera las aptitudes necesarias para entregar soluciones nuevas e innovadoras.
Operaciones: las aptitudes relacionadas con el modelo operativo para la adopción de la nube se alinean
con varias oportunidades para adquirir aptitudes:
Gobernanza: adquiera las aptitudes necesarias para regir el entorno en la nube.
Administración: adquiera las aptitudes necesarias para administrar un entorno en la nube.
Super visión : adquiera las aptitudes necesarias para supervisar un entorno en la nube.
Cada una de las rutas de aprendizaje anteriores comparte oportunidades de varios tipos de medios para
maximizar la adquisición de conocimiento. A medida que evolucione las rutas de aprendizaje, eche un vistazo a
cómo los empleados y las personas en formación querrán obtener la certificación. El recurso siguiente le
ayudará a diseñar las rutas de certificación para comprender la cartera disponible para la información general
de la certificación, los pasos sugeridos y el entrenamiento recomendado necesario para la certificación.
Formación y certificaciones de Microsoft Azure.
Microsoft Learn
Entre los ejemplos de rutas de aprendizaje personalizadas en Microsoft Learn que se alinean con la metodología
de planeamiento de Cloud Adoption Framework se incluyen:
Logre que sus procedimientos de DevOps evolucionen: DevOps es la unión de personas, procesos y productos
para hacer posible la entrega continua de valor a los usuarios finales. Azure DevOps es un conjunto de servicios
que le ofrece las herramientas que necesita para hacerlo. Con Azure DevOps, puede compilar, probar e
implementar cualquier aplicación, ya sea en la nube o de forma local.
Azure para el ingeniero de datos: Explore cómo ha evolucionado el mundo de los datos y cómo la llegada de las
tecnologías de nube está ofreciendo nuevas oportunidades para que las empresas las exploren. Conocerá las
diversas tecnologías de plataforma de datos que están disponibles y cómo un ingeniero de datos puede
aprovechar de esta tecnología en beneficio de una organización.
Más información
Para descubrir más rutas de aprendizaje, eche un vistazo al catálogo de Microsoft Learn. Use el filtro de roles
para alinear las rutas de aprendizaje con su rol.
Plan para la adopción de la nube
Un plan es un requisito esencial para una adopción de la nube correcta. Un plan de adopción de la nube es un
plan de proyecto iterativo que ayuda a la transición de una empresa desde los enfoques de TI tradicionales a la
transformación a enfoques modernos y ágiles. En esta serie de artículos se describe cómo ayuda un plan de
adopción de la nube a que las empresas equilibren su cartera de TI y a administrar las transiciones a lo largo del
tiempo. Mediante este proceso, los objetivos empresariales se pueden traducir claramente en trabajos técnicos
tangibles. Estos trabajos se pueden administrar y comunicar de forma que tengan sentido para las partes
interesadas de la empresa. Sin embargo, la adopción de este tipo de proceso puede requerir algunos cambios
en los enfoques de administración de proyectos tradicionales.
Alineación de estrategia y planeamiento

Los planes de adopción de la nube comienzan con una estrategia bien definida. Como mínimo, la estrategia
debe describir las motivaciones, los resultados empresariales y las justificaciones empresariales para la
adopción de la nube. A continuación, esos retornos positivos se equilibran con el trabajo necesario para su
realización.
El trabajo comienza con el patrimonio digital (propuesto o existente), lo que traduce la estrategia en cargas de
trabajo y recursos más tangibles. A continuación, puede asignar estos elementos tangibles al trabajo técnico. A
partir de ahí, las personas cualificadas de una estructura organizativa adecuada pueden ejecutar el trabajo
técnico. El plan de adopción de la nube combina estos temas en un plan que se puede predecir, presupuestar,
implementar y administrar mediante prácticas de administración de proyectos ágiles. Esta serie de artículos le
ayuda a crear el plan y proporciona algunas plantillas para facilitar el trabajo.
Transición del planeamiento secuencial al planeamiento iterativo

El planeamiento de la adopción de la nube puede ser un cambio importante para algunas organizaciones. Las
organizaciones de TI han dedicado mucho tiempo a la aplicación de modelos lineales o secuenciales de
administración de proyectos, como el modelo en cascada. En las TI tradicionales, este enfoque era
completamente lógico. La mayoría de los proyectos de TI de gran tamaño empezaban con una solicitud de
adquisición para adquirir recursos de hardware costosos. Las solicitudes de gastos de capital, las asignaciones
de presupuestos y la adquisición de equipos a menudo representaban un gran porcentaje de la ejecución del
proyecto. Y, una vez adquirido, el propio hardware se convertía en una restricción sobre lo que se puede
entregar.
Los modelos de adquisición de la nube cambian las dependencias principales que hicieron necesario un modelo
secuencial. El reemplazo de los ciclos de adquisición por un enfoque de gastos operativos ayuda a las empresas
a moverse más rápidamente y con compromisos financieros menores. Este enfoque ayuda a los equipos a
participar en los proyectos antes de que todos los requisitos sean conocidos. También crea espacio para una
mentalidad de crecimiento, que libera al equipo para experimentar, aprender y entregar sin restricciones
artificiales. Por todas estas razones, entre otras, recomendamos encarecidamente que los equipos usen
enfoques ágiles o iterativos para el planeamiento de la adopción de la nube.
Creación del plan de adopción de la nube

En esta serie de artículos se describe cada paso de la conversión de estrategias y trabajos en un plan de
adopción de la nube accionable:
1. Requisitos previos: confirme que se han completado todos los pasos de requisitos previos antes de crear
el plan.
2. Definición y clasificación por prioridades de las cargas de trabajo: clasifique por prioridades las 10
primeras cargas de trabajo para establecer un trabajo pendiente de adopción inicial.
3. Adaptación de los recursos a las cargas de trabajo: identifique qué recursos (propuestos o existentes)
son necesarios para posibilitar las cargas de trabajo clasificadas por prioridades.
4. Revisión de las decisiones de racionalización: revise las decisiones de racionalización para refinar las
decisiones de la ruta de adopción: migrar o innovar.
5. Establecimiento de iteraciones y planes de versiones: las iteraciones son los bloques de tiempo
asignados para realizar el trabajo. Las versiones son la definición del trabajo que se debe realizar antes de
desencadenar un cambio en los procesos de producción.
6. Estimación de escalas de tiempo : establezca escalas de tiempo aproximadas para fines de planeamiento
de versiones, en función de las estimaciones iniciales.
Pasos siguientes
Antes de crear el plan de adopción de la nube, asegúrese de que se cumplen todos los requisitos previos
necesarios.
Revisión de los requisitos previos
Requisitos previos para un plan de adopción de la
nube efectivo
Un plan solo es tan efectivo como los datos que se incluyen en él. Para que un plan de adopción de la nube sea
efectivo, hay dos categorías de entrada: estratégica y táctica. En las secciones siguientes se describen los puntos
de datos mínimos necesarios en cada categoría.
Entradas estratégicas
Las entradas estratégicas precisas garantizan que el trabajo que se realiza contribuye a la consecución de los
resultados empresariales. La sección de estrategia de Cloud Adoption Framework proporciona una serie de
ejercicios para desarrollar una estrategia clara. Las salidas de estos ejercicios alimentan el plan de adopción de
la nube. Antes de desarrollar el plan, asegúrese de que los siguientes elementos están bien definidos como un
resultado de los ejercicios:
Motivaciones claras: ¿por qué se va a realizar la adopción de la nube?
Resultados empresariales definidos: ¿qué resultados se esperan ver de la adopción de la nube?
Justificación empresarial: ¿cómo medirá el éxito el negocio?
Cada miembro del equipo que implementa el plan de adopción de la nube debe ser capaz de responder a estas
tres preguntas estratégicas. Los administradores y líderes que son responsables de la implementación del plan
deben comprender las métricas de cada pregunta y cualquier progreso hacia la realización de esas métricas.
Entradas tácticas
Las entradas tácticas precisas garantizan que el trabajo se puede planear con precisión y se puede administrar
de manera eficaz. La sección de planeamiento de Cloud Adoption Framework proporciona una serie de
ejercicios para desarrollar artefactos de planeamiento antes de desarrollar el plan. Estos artefactos
proporcionan respuestas a las siguientes preguntas:
Racionalización del patrimonio digital: ¿Cuáles son las 10 cargas de trabajo de prioridad principales del
plan de adopción? ¿Cuántas cargas de trabajo adicionales es probable que haya en el plan? ¿Cuántos
recursos se consideran candidatos para la adopción de la nube? ¿Los trabajos iniciales se centran más en
actividades de migración o de innovación?
Alineación de la organización: ¿Quién realizará el trabajo técnico del plan de adopción? ¿Quién es
responsable de la adherencia a los requisitos de gobernanza y cumplimiento?
Preparación de las aptitudes: ¿Cuántas personas están asignadas para realizar las tareas necesarias? ¿En
qué medida se alinean sus aptitudes con los trabajos de adopción de la nube? ¿Los asociados están alineados
para dar soporte técnico a la implementación técnica?
Estas preguntas son esenciales para la precisión del plan de adopción de la nube. Como mínimo, se debe
responder a las preguntas sobre la racionalización del patrimonio digital para crear un plan. Para proporcionar
escalas de tiempo precisas, también son importantes las preguntas acerca de la organización y las aptitudes.
Pasos siguientes
Implemente la plantilla en Azure DevOps Services para definir el plan de adopción de la nube.
Definición del plan de adopción de la nube mediante la plantilla
Plan de adopción de la nube y Azure DevOps
Azure DevOps es el conjunto de herramientas basadas en la nube para los clientes de Azure que administran
proyectos iterativos. También incluye herramientas para administrar canalizaciones de implementación y otros
aspectos importantes de DevOps.
En este artículo aprenderá a implementar rápidamente un trabajo pendiente en Azure DevOps mediante una
plantilla. Esta plantilla alinea los trabajos de adopción de la nube con un proceso normalizado según la guía de
Creación del plan de adopción de la nube

Para implementar el plan de adopción de la nube, abra el generador de demostraciones de Azure DevOps. Esta
herramienta implementará la plantilla en el inquilino de Azure DevOps. El uso de la herramienta requiere los
pasos siguientes:
1. Compruebe que el campo Plantilla seleccionada está establecido en Plan de adopción de la nube . Si
no es así, seleccione Elegir plantilla para elegir la plantilla correcta.
2. Seleccione la organización de Azure DevOps en el cuadro de lista desplegable Seleccionar organización .
3. Escriba un nombre para el nuevo proyecto. El plan de adopción de la nube tendrá este nombre cuando se
implemente en el inquilino de Azure DevOps.
4. Seleccione Crear proyecto para crear un proyecto en el inquilino basado en la estrategia y en la plantilla del
plan. Una barra de progreso muestra el progreso hacia la implementación del proyecto.
5. Una vez finalizada la implementación, seleccione Ir al proyecto para ver el nuevo proyecto.
Una vez creado el proyecto, continúe con esta serie de artículos para aprender a modificar la plantilla para
alinearla con el plan de adopción de la nube.
Para ayuda adicional e instrucciones sobre esta herramienta, consulte Generador de demostraciones de Azure
DevOps Services.
Edición en masa del plan de adopción de la nube

Una vez implementado el proyecto del plan, puede usar Microsoft Excel para modificarlo. Es mucho más fácil
crear cargas de trabajo o recursos en el plan mediante Microsoft Excel que con la experiencia del explorador de
Azure DevOps.
Para preparar la estación de trabajo para la edición en masa, consulte Adición o modificación en masa de
elementos de trabajo con Excel.
Puede que algunos usuarios quieran usar Microsoft Project para realizar un seguimiento de sus tareas, crear
trabajos pendientes y asignar recursos. Estos son los pasos para conectar Microsoft Project a Azure DevOps.
Uso del plan de adopción de la nube

El plan de adopción de la nube organiza las actividades por tipo de actividad:
Epopeyas: una epopeya representa una fase general del ciclo de vida de la adopción de la nube.
Características las características se usan para organizar objetivos específicos dentro de cada fase. Por
ejemplo, la migración de una carga de trabajo específica sería una característica.
Casos de usuario: los casos de usuario agrupan el trabajo en colecciones lógicas de actividades en función
de un objetivo específico.
Tareas: las tareas son el trabajo real que se va a realizar.
En cada nivel, las actividades se ordenan en función de las dependencias. Las actividades se vinculan a los
artículos de Cloud Adoption Framework para aclarar el objetivo o la tarea.
La vista más clara del plan de adopción de la nube procede de la vista de trabajos pendientes de Epopeyas .
Para obtener ayuda con el cambio a la vista de trabajos pendientes de Epopeyas , consulte el artículo
Visualización de un trabajo pendiente. Desde esta vista, es fácil planear y administrar el trabajo necesario para
completar la fase actual del ciclo de vida de la adopción.
NOTE
El estado actual del plan de adopción de la nube se centra principalmente en los trabajos de migración. Las tareas
relacionadas con la gobernanza, la innovación o las operaciones se deben rellenar manualmente.
Alineación del plan de adopción de la nube

Las páginas de información general de la metodología de estrategia y la metodología de planeamiento hacen
referencia cada una a las plantillas de estrategia y de planeamiento. Esa plantilla organiza las decisiones y los
puntos de datos que alinearán la plantilla del plan de adopción de la nube con los planes específicos para la
adopción. Considere la posibilidad de completar los ejercicios de la metodología de estrategia y la metodología
de planeamiento antes de alinear el nuevo proyecto.
En los artículos siguientes se trata la alineación del plan de adopción de la nube:
Cargas de trabajo: alinee las características de la epopeya de migración a nube para capturar cada carga de
trabajo que se va a migrar o modernizar. Agregue y modifique esas características para capturar el trabajo
necesario para migrar las 10 cargas de trabajo principales.
Recursos: cada recurso (máquina virtual, aplicación o datos) se representa mediante los casos de usuario de
cada carga de trabajo. Agregue y modifique los casos de usuario para alinearlos con el patrimonio digital.
Racionalización: a medida que se define cada carga de trabajo, puede significar un desafío para las
suposiciones iniciales sobre esa carga de trabajo. Esto puede dar lugar a cambios en las tareas de cada
recurso.
Creación de planes de versiones: las rutas de iteración establecen planes de versiones mediante la alineación
de los trabajos con las distintas versiones e iteraciones.
Establecimiento de escalas de tiempo: la definición de las fechas de inicio y finalización de cada iteración crea
una escala de tiempo para administrar el proyecto global.
Estos cinco artículos le ayudarán con cada una de las tareas de alineación necesarias para empezar a
administrar los trabajos de adopción. El siguiente paso le ayuda a iniciarse en el ejercicio de la alineación.
Pasos siguientes
Empiece a alinear el proyecto del plan mediante la definición y clasificación por prioridades de las cargas de
trabajo.
Definición y clasificación por prioridades de las cargas de trabajo
Definición y clasificación por orden de prioridad de
las cargas de trabajo para un plan de adopción de
la nube
El establecimiento de prioridades claras y accionables es uno de los secretos para la adopción correcta de la
nube. La tentación natural es invertir tiempo en la definición de todas las cargas de trabajo que podrían verse
afectadas durante la adopción de la nube. Pero eso es contraproducente, especialmente al principio del proceso
de adopción.
En su lugar, se recomienda que el equipo se centre en clasificar por orden de prioridad y documentar las 10
primeras cargas de trabajo. Después de comenzar la implementación del plan de adopción, el equipo puede
mantener una lista de las siguientes 10 cargas de trabajo de prioridad más alta. Este enfoque proporciona
información suficiente para planear las siguientes iteraciones.
Limitar el plan a 10 cargas de trabajo fomenta la agilidad y la alineación de las prioridades a medida que
cambian los criterios de negocio. Este enfoque también posibilita que el equipo de adopción de la nube aprenda
y refine las estimaciones. Lo más importante es que elimina el planeamiento extensivo como una barrera para
un cambio empresarial efectivo.
¿Qué es una carga de trabajo?

En el contexto de una adopción de la nube, una carga de trabajo es una colección de recursos de TI (servidores,
máquinas virtuales, aplicaciones, datos o dispositivos) que posibilitan colectivamente un proceso definido. Las
cargas de trabajo pueden posibilitar más de un proceso. Las cargas de trabajo también pueden depender de
otros activos compartidos o plataformas más grandes. Sin embargo, una carga de trabajo debe tener límites
definidos con respecto a los recursos dependientes y los procesos que dependen de la carga de trabajo. A
menudo, las cargas de trabajo se pueden visualizar mediante la supervisión del tráfico de red entre los recursos
de TI.
Prerrequisitos
Las entradas estratégicas de la lista de requisitos previos hacen que las siguientes tareas sean mucho más
fáciles de realizar. Para obtener ayuda con la recopilación de los datos que se describen en este artículo, consulte
los requisitos previos.
Clasificación por prioridades de la carga de trabajo inicial

Durante el proceso de racionalización incremental, el equipo debe consensuar un enfoque de "potencia de 10",
que consta de 10 cargas de trabajo prioritarias. Estas cargas de trabajo sirven como límite inicial para el
planeamiento de la adopción.
Si decide que no se necesita una racionalización del patrimonio digital, se recomienda que los equipos de
adopción y estrategia de la nube acuerden una lista de 10 aplicaciones que sirvan como foco inicial de la
migración. Se recomienda que estas 10 cargas de trabajo contengan una combinación de cargas de trabajo
sencillas (menos de 10 activos en una implementación autocontenida) y cargas de trabajo más complejas. Esas
10 cargas de trabajo iniciarán el proceso de clasificación por prioridades de las cargas de trabajo.
NOTE
El enfoque de la potencia de 10 sirve como límite inicial para el planeamiento, para centrar la energía y la inversión en el
análisis en una fase temprana. Sin embargo, es probable que el acto de analizar y definir las cargas de trabajo cause
cambios en la lista de cargas de trabajo prioritarias.
Adición de cargas de trabajo al plan de adopción de la nube

En el artículo anterior, Plan de adopción de la nube y Azure DevOps, creó un plan de adopción de la nube en
Azure DevOps.
Ahora puede representar las cargas de trabajo en la lista de potencia de 10 en el plan de adopción de la nube. La
forma más fácil de hacerlo es mediante la edición en masa en Microsoft Excel. Para preparar la estación de
trabajo para la edición en masa, consulte Adición o modificación en masa de elementos de trabajo con Excel.
En el paso 5 de este artículo se indica cómo seleccionar la Lista de entradas . En su lugar, seleccione Lista de
consultas . A continuación, en la lista desplegable Seleccionar una consulta , seleccione la consulta Plantilla
de carga de trabajo . Dicha consulta carga todos los trabajos relacionados con la migración de una sola carga
de trabajo en la hoja de cálculo.
Una vez cargados los elementos de trabajo de la plantilla de carga de trabajo, siga estos pasos para empezar a
agregar nuevas cargas de trabajo:
1. Copie todos los elementos que tengan la etiqueta Plantilla de carga de trabajo en la columna situada
más a la derecha.
2. Pegue las filas copiadas debajo del último elemento de línea de la tabla.
3. Cambie la celda de título de la nueva característica de Plantilla de carga de trabajo al nombre de la nueva
carga de trabajo.
4. Pegue la nueva celda del nombre de la carga de trabajo en la columna de etiqueta para todas las filas
situadas debajo de la nueva característica. Tenga cuidado de no cambiar las etiquetas o el nombre de las filas
relacionadas con la característica Plantilla de carga de trabajo real. Necesitará esos elementos de trabajo
cuando agregue la siguiente carga de trabajo al plan de adopción de la nube.
5. Vaya al paso 8 de las instrucciones de edición por lotes para publicar la hoja de cálculo. En este paso se crean
todos los elementos de trabajo necesarios para migrar la carga de trabajo.
Repita los pasos del 1 al 5 para cada una de las cargas de trabajo de la lista Potencia de 10.
Definición de cargas de trabajo

Una vez que se han definido las prioridades iniciales y se han agregado cargas de trabajo al plan, se puede
definir cada una de las cargas de trabajo mediante un análisis cualitativo más profundo. Antes de incluir
cualquier carga de trabajo en el plan de adopción de la nube, intente proporcionar los siguientes puntos de
datos para cada carga de trabajo.
Entradas de negocio
P UN TO DE DATO S DESC RIP C IÓ N EN T RA DA
Nombre de la carga de trabajo ¿Cómo se llama esta carga de trabajo?
Descripción de la carga de trabajo En una sola frase, ¿qué hace esta carga
de trabajo?
Motivaciones para la adopción ¿Cuáles de las motivaciones para la

adopción de la nube se ven afectadas
por esta carga de trabajo?
Patrocinador principal De las partes interesadas afectadas,

¿quién es el patrocinador principal que
solicita las motivaciones anteriores?
Impacto empresarial ¿Cuál es el impacto empresarial de esta

carga de trabajo?
Impacto de la aplicación ¿Qué impacto tiene esta aplicación en

los procesos empresariales?
Impacto de los datos ¿Qué impacto tienen los datos en la

empresa?
Unidad de negocio ¿Qué unidad de negocio es

responsable del costo de esta carga de
trabajo?
Procesos empresariales ¿Qué procesos empresariales se verán

afectados por los cambios en la carga
de trabajo?
Equipos empresariales ¿Qué equipos empresariales se verán

afectados por los cambios?
Partes interesadas del negocio ¿Hay algún ejecutivo cuyo negocio se

verá afectado por los cambios?
Resultados empresariales ¿Cómo medirá el negocio el éxito de

este trabajo?
Métricas ¿Qué métricas se usarán para realizar

un seguimiento del éxito?
Cumplimiento normativo ¿Hay algún requisito de cumplimiento

de terceros para esta carga de trabajo?
Propietarios de la aplicación ¿Quién es responsable del impacto

empresarial de las aplicaciones
asociadas a esta carga de trabajo?
Períodos de inmovilización empresarial ¿Hay algún momento en el que la

empresa no permita el cambio?
Zonas geográficas ¿Hay zonas geográficas que se ven

afectadas por esta carga de trabajo?
Entradas técnicas
Enfoque de la adopción ¿Esta adopción es candidata para la

migración o la innovación?
Responsable de operaciones de la Enumere las partes responsables del

aplicación rendimiento y la disponibilidad de esta
carga de trabajo.
SLA Enumere los contratos de nivel de

servicio (requisitos de RTO y RPO).
Grado de importancia Enumere la importancia crítica actual

de la aplicación.
Clasificación de datos Enumere la clasificación de la

confidencialidad de los datos.
Zonas geográficas en funcionamiento Enumere las zonas geográficas en las

que la carga de trabajo está o debe
hospedarse.
APLICACIONES Especifique una lista o un recuento

inicial de las aplicaciones incluidas en
esta carga de trabajo.
Máquinas virtuales Especifique una lista o un recuento

inicial de las máquinas virtuales o
servidores incluidos en la carga de
trabajo.
Orígenes de datos Especifique una lista o un recuento

inicial de los orígenes de datos
incluidos en la carga de trabajo.
Dependencias enumere las dependencias de recursos

no incluidas en la carga de trabajo.
Zonas geográficas de tráfico de Enumere las zonas geográficas que

usuario tienen una colección significativa de
tráfico de usuario.
Confirmación de prioridades
En función de los datos recopilados, el equipo de estrategia de la nube y el equipo de adopción de la nube
deben reunirse para volver a evaluar las prioridades. La clarificación de los puntos de datos empresariales
podría llevar a cambios en las prioridades. La complejidad técnica o las dependencias pueden dar lugar a
cambios relacionados con las asignaciones de personal, las escalas de tiempo o la secuenciación de los trabajos
técnicos.
Después de una revisión, ambos equipos deberían estar de acuerdo con la confirmación de las prioridades
resultantes. Este conjunto de prioridades documentadas, validadas y confirmadas es el trabajo pendiente de
adopción de la nube con prioridades.
Pasos siguientes
El equipo ahora está listo para alinear los recursos de cualquier carga de trabajo del trabajo pendiente de
adopción de la nube con prioridades.
Alineación de recursos para cargas de trabajo prioritarias
Alineación de los recursos con las cargas de trabajo
prioritarias
Una carga de trabajo es una descripción conceptual de una colección de recursos: máquinas virtuales,
aplicaciones y orígenes de datos. En el artículo anterior, Definición y clasificación por orden de prioridad, se
proporciona una guía para recopilar los datos que van a definir la carga de trabajo. Antes de la migración,
algunas de las entradas técnicas de esa lista requieren una validación adicional. Este artículo ayuda con la
validación de las siguientes entradas:
Aplicaciones: enumere las aplicaciones incluidas en esta carga de trabajo.
VM y ser vidores: enumere las máquinas virtuales o los servidores incluidos en la carga de trabajo.
Orígenes de datos: enumere los orígenes de datos incluidos en la carga de trabajo.
Dependencias: enumere las dependencias de recursos no incluidas en la carga de trabajo.
Hay varias opciones para ensamblar estos datos. Estos son algunos de los enfoques más comunes.
Entradas alternativas: Migración, modernización e innovación

El objetivo de los puntos de datos anteriores es capturar el trabajo técnico relativo y las dependencias como
ayuda para la clasificación por prioridades. En función de la transición que desee, puede que necesite recopilar
puntos de datos alternativos para posibilitar una clasificación por prioridades correcta.
Migración: en el caso de los trabajos de migración puros, el inventario y las dependencias de recursos
existentes sirven como medida equitativa de la complejidad relativa.
Modernización: cuando el objetivo de una carga de trabajo es modernizar aplicaciones u otros recursos, estos
puntos de datos siguen siendo medidas sólidas de la complejidad. Sin embargo, podría ser aconsejable agregar
una entrada para las oportunidades de modernización a la documentación de la carga de trabajo.
Innovación: cuando se lleva a cabo un cambio material en los datos o la lógica del negocio durante un trabajo
de adopción de la nube, se considera un tipo de innovación de transformación. Lo mismo ocurre cuando se
crean nuevos datos o una nueva lógica del negocio. En el caso de los escenarios de innovación, la migración de
los recursos probablemente representará la menor cantidad de trabajo necesaria. En estos casos, el equipo debe
diseñar un conjunto de entradas de datos técnicos para medir la complejidad relativa.
Azure Migrate
Azure Migrate proporciona un conjunto de funciones de agrupación que pueden acelerar la agregación de
aplicaciones, máquinas virtuales, orígenes de datos y dependencias. Una vez definidas conceptualmente las
cargas de trabajo, se pueden usar como base para agrupar los recursos en función de la asignación de
dependencias.
En la documentación de Azure Migrate se proporciona guía sobre cómo agrupar máquinas en función de las
dependencias.
Base de datos de administración de configuración

Algunas organizaciones tienen una base de datos de administración de configuración (CMDB) bien mantenida
en sus herramientas de administración de operaciones existentes. Podrían usar la CMDB alternativamente para
proporcionar los puntos de datos de entrada que se han explicado anteriormente.
Pasos siguientes
Revise las decisiones de racionalización en función de la alineación de recursos y las definiciones de las cargas
de trabajo.
Durante las fases de estrategia y planeamiento inicial, se recomienda aplicar un enfoque de racionalización
incremental al patrimonio digital. Pero este enfoque inserta algunas suposiciones en las decisiones resultantes.
Se recomienda que los equipos de adopción y estrategia de la nube revisen esas decisiones en función de la
documentación de la carga de trabajo ampliada. Esta revisión también es un buen momento para involucrar a
las partes interesadas del negocio y al patrocinador ejecutivo en futuras decisiones sobre el patrimonio.
IMPORTANT
Se realizará una validación adicional de las decisiones de racionalización durante la fase de evaluación de la migración. Esta
validación se centra en la revisión empresarial de la racionalización para alinear los recursos de forma adecuada.
Para validar las decisiones de racionalización, utilice las siguientes preguntas para facilitar una conversación con
el negocio. Las preguntas se agrupan por la alineación de racionalización probable.
Indicadores de innovación
Si la revisión conjunta de las siguientes preguntas da como resultado una respuesta afirmativa, una carga de
trabajo podría ser una buena candidata para la innovación. Este tipo de carga de trabajo no se migrará con un
modelo de tipo lift-and-shift o de modernización. En su lugar, las estructuras de datos o la lógica del negocio se
volverán a crear como una aplicación nueva o rediseñada. Este enfoque puede ser más intensivo y requiere
mucho tiempo. Pero para una carga de trabajo que representa retornos empresariales significativos, se justifica
la inversión.
¿Las aplicaciones de esta carga de trabajo crean diferenciación en el mercado?
¿Hay una inversión propuesta o aprobada destinada a mejorar las experiencias asociadas a las aplicaciones
de esta carga de trabajo?
¿Los datos de esta carga de trabajo hacen posibles nuevas ofertas de productos o servicios?
¿Hay una inversión propuesta o aprobada destinada a aprovechar los datos asociados a esta carga de
trabajo?
¿Se puede cuantificar el efecto de la diferenciación en el mercado o de las nuevas ofertas? En caso afirmativo,
¿el retorno justifica el aumento del costo de la innovación durante la adopción de la nube?
Las dos preguntas siguientes pueden ayudarle a incluir escenarios técnicos generales en la revisión de la
racionalización. Una respuesta afirmativa a una de ellas puede identificar formas de contabilizar o reducir el
costo asociado con la innovación.
¿Cambiarán las estructuras de datos o la lógica del negocio durante el transcurso de la adopción de la nube?
¿Se usa una canalización de implementación existente para implementar esta carga de trabajo en
producción?
Si la respuesta a cualquiera de las preguntas es afirmativa, el equipo debería considerar incluir esta carga de
trabajo como candidata para la innovación. Como mínimo, el equipo debe marcar esta carga de trabajo para la
revisión de la arquitectura con el fin de identificar oportunidades de modernización.
Indicadores de migración
La migración es una forma rápida y económica de adoptar la nube. Pero no aprovecha las oportunidades de
innovación. Antes de invertir en innovación, responda a las siguientes preguntas. Pueden ayudarle a determinar
si un modelo de migración es más aplicable para una carga de trabajo.
¿El código fuente de esta aplicación es estable? ¿Espera que permanezca estable y sin cambios durante el
período de tiempo de este ciclo de versión?
¿Esta carga de trabajo es compatible actualmente con los procesos empresariales de producción? ¿Lo será a
lo largo del curso de este ciclo de versión?
¿Es una prioridad que este trabajo de adopción de la nube mejore la estabilidad y el rendimiento de esta
carga de trabajo?
¿La reducción de costos asociada a esta carga de trabajo es un objetivo durante este trabajo?
¿La reducción de la complejidad operativa de esta carga de trabajo es un objetivo durante este trabajo?
¿La innovación está limitada por la arquitectura actual o los procesos de operación de TI?
Si la respuesta a alguna de estas preguntas es afirmativa, debe considerar un modelo de migración para esta
carga de trabajo. Esta recomendación se mantiene incluso si la carga de trabajo es candidata para la innovación.
Los desafíos de la complejidad operativa, los costos, el rendimiento o la estabilidad pueden afectar a los
retornos del negocio. Puede usar la nube para generar rápidamente mejoras relacionadas con estos desafíos.
Cuando sea aplicable, se recomienda usar el enfoque de migración para estabilizar primero la carga de trabajo.
A continuación, amplíe oportunidades de innovación en el entorno estable y ágil de la nube. Este enfoque
proporciona retornos a corto plazo y reduce el costo necesario para impulsar el cambio a largo plazo.
IMPORTANT
Los modelos de migración incluyen la modernización incremental. El uso de arquitecturas de plataforma como servicio
(PaaS) es un aspecto común de las actividades de migración. También hay cambios de configuración menores que usan
esos servicios de plataforma. El límite de la migración se define como un cambio material en la lógica del negocio o en las
estructuras empresariales de apoyo. Dicho cambio se considera un trabajo de innovación.
Actualización del plan del proyecto

Las aptitudes necesarias para un trabajo de migración son diferentes de las aptitudes necesarias para un trabajo
de innovación. Durante la implementación de un plan de adopción de la nube, se recomienda asignar los
trabajos de migración e innovación a distintos equipos. Cada equipo tiene su propio ritmo de iteración,
versiones y planeamiento. La asignación de equipos independientes proporciona la flexibilidad del proceso de
mantenimiento de un plan de adopción de la nube, además de la contabilización de los trabajos de innovación y
migración.
Cuando administra el plan de adopción de la nube en Azure DevOps, esa administración se refleja mediante el
cambio del elemento de trabajo primario (o epopeya) desde la migración a la nube a la innovación en la nube.
Este cambio sutil ayuda a garantizar que todos los participantes en el plan de adopción de la nube puedan
realizar rápidamente el seguimiento del trabajo necesario y de los cambios en los trabajos de corrección. Este
seguimiento también ayuda a alinear las asignaciones adecuadas al equipo de adopción de la nube
correspondiente.
En el caso de planes de adopción complejos y de gran tamaño con varios proyectos distintos, considere la
posibilidad de actualizar la ruta de iteración. Cambiar la ruta de área hace que la carga de trabajo sea visible solo
para el equipo asignado a esa ruta de área. Este cambio puede facilitar el trabajo al equipo de adopción de la
nube al reducir el número de tareas visibles. Pero agrega complejidad a los procesos de administración del
proyecto.
Pasos siguientes
Establezca iteraciones y planes de versiones para empezar a planear el trabajo.
Establezca iteraciones y planes de versiones para empezar a planear el trabajo.
Establecimiento de iteraciones y planes de versiones
Agile y otras metodologías iterativas se basan en los conceptos de iteraciones y versiones. En este artículo se
describe la asignación de iteraciones y versiones durante el planeamiento. Dichas asignaciones impulsan la
visibilidad de la escala de tiempo para facilitar las conversaciones entre los miembros del equipo de estrategia
de la nube. Las asignaciones también alinean las tareas técnicas de una manera que el equipo de adopción de la
nube puede administrar durante la implementación.
Establecimiento de iteraciones
En un enfoque iterativo de la implementación técnica, los trabajos técnicos se planean en torno a bloques de
tiempo recurrentes. Las iteraciones tienden a ser bloques de tiempo de entre una y seis semanas. El consenso
sugiere que la duración media de la iteración es de dos semanas para la mayoría de los equipos de adopción de
la nube. Pero la elección de la duración de la iteración depende del tipo de trabajo técnico, la sobrecarga
administrativa y las preferencias del equipo.
Para empezar a alinear los trabajos con una escala de tiempo, se recomienda definir un conjunto de iteraciones
que dure entre 6 y 12 meses.
Descripción de la velocidad
La alineación de trabajos con iteraciones y versiones requiere un conocimiento de la velocidad. La velocidad es
la cantidad de trabajo que se puede completar en una iteración determinada. Durante el planeamiento
temprano, la velocidad es una estimación. Después de varias iteraciones, la velocidad se convierte en un
indicador muy valioso de los compromisos que el equipo puede llevar a cabo con confianza.
Puede medir la velocidad en términos abstractos como el grado de dificultad del caso. También puede medirla
en términos más tangibles; por ejemplo, horas. En la mayoría de los marcos iterativos, se recomienda usar
medidas abstractas para evitar desafíos en la precisión y la percepción. Los ejemplos de este artículo
representan la velocidad en horas por sprint. Esta representación hace que el tema se entienda más
universalmente.
Ejemplo: un equipo de adopción de la nube de cinco personas se ha comprometido a realizar sprints de dos
semanas. Dadas las obligaciones actuales, como las reuniones y el soporte técnico de otros procesos, cada
miembro del equipo puede colaborar de forma coherente 20 horas por semana con el trabajo de adopción. Para
este equipo, la estimación de velocidad inicial es de 100 horas por sprint.
Planeamiento de las iteraciones

Inicialmente, las iteraciones se planean mediante la evaluación de las tareas técnicas basadas en el trabajo
pendiente con prioridades. Los equipos de adopción de la nube estiman el trabajo necesario para realizar varias
tareas. A continuación, esas tareas se asignan a la primera iteración disponible.
Durante el planeamiento de las iteraciones, los equipos de adopción de la nube validan y refinan las
estimaciones. Lo hacen hasta que hayan alineado toda la velocidad disponible a tareas específicas. Este proceso
continúa para cada carga de trabajo con prioridades hasta que todos los trabajos se alinean con una iteración
prevista.
En este proceso, el equipo valida las tareas asignadas al siguiente sprint. El equipo actualiza sus estimaciones en
función de las conversaciones del equipo sobre cada tarea. A continuación, el equipo agrega cada tarea
estimada al siguiente sprint hasta que se alcanza la velocidad disponible. Por último, el equipo calcula las tareas
adicionales y las agrega a la siguiente iteración. El equipo realiza estos pasos hasta que se agota también la
velocidad de dicha iteración.
El proceso anterior continúa hasta que todas las tareas se asignan a una iteración.
Ejemplo: sigamos a partir del ejemplo anterior. Supongamos que cada migración de carga de trabajo requiere
40 tareas. Supongamos también que calcula que cada tarea tardará un promedio de una hora. La estimación
combinada es de aproximadamente 40 horas por cada migración de carga de trabajo. Si estas estimaciones se
mantienen coherentes para las 10 cargas de trabajo prioritarias, esas cargas de trabajo tardarán 400 horas.
La velocidad definida en el ejemplo anterior sugiere que la migración de las 10 primeras cargas de trabajo
llevará cuatro iteraciones, lo que significa dos meses de tiempo de calendario. La primera iteración constará de
100 tareas que dan como resultado la migración de dos cargas de trabajo. En la siguiente iteración, una
colección similar de 100 tareas dará como resultado la migración de tres cargas de trabajo.
WARNING
El número de tareas anterior y las estimaciones se usan estrictamente como ejemplo. Las tareas técnicas rara vez son tan
coherentes. No debería ver este ejemplo como un reflejo de la cantidad de tiempo necesaria para migrar una carga de
trabajo.
Planeamiento de la versión
En el contexto de la adopción de la nube, una versión se define como una colección de entregas que generan un
valor empresarial suficiente para justificar el riesgo de interrupción de los procesos empresariales.
El lanzamiento de una versión de cualquier cambio relacionado con la carga de trabajo en un entorno de
producción crea algunos cambios en los procesos empresariales. Idealmente, estos cambios no serán
problemáticos y el negocio verá el valor de los cambios sin interrupciones significativas en el servicio. Pero el
riesgo de interrupción del negocio está presente en cualquier cambio y no se debe tomar a la ligera.
Para asegurarse de que un cambio está justificado por su retorno potencial, el equipo de estrategia de la nube
debe participar en el planeamiento de la versión. Una vez que las tareas están alineadas con los sprints, el
equipo puede determinar una escala de tiempo aproximada de cuándo estará preparada para la versión de
producción cada carga de trabajo. El equipo de estrategia de la nube revisaría la temporización de cada versión.
El equipo identificaría entonces el punto de inflexión entre el riesgo y el valor empresarial.
Ejemplo: siguiendo con el ejemplo anterior, el equipo de estrategia de la nube ha revisado el plan de iteración.
La revisión identificó dos puntos de versión. Durante la segunda iteración, estarán listas para la migración un
total de cinco cargas de trabajo. Esas cinco cargas de trabajo proporcionarán un valor empresarial significativo y
desencadenarán la primera versión. La siguiente versión vendrá dos iteraciones más adelante, cuando las cinco
cargas de trabajo siguientes estén listas para su lanzamiento.
Asignación de rutas de iteración y etiquetas

Para los clientes que administran los planes de adopción de la nube en Azure DevOps, los procesos anteriores se
reflejan mediante la asignación de una ruta de iteración a cada tarea y caso de usuario. También se recomienda
etiquetar cada carga de trabajo con una versión específica. El etiquetado y la asignación alimentan el rellenado
automático de informes temporales.
Pasos siguientes
Realice una estimación de las escalas de tiempo para comunicar correctamente las expectativas.
Escalas de tiempo de un plan de adopción de la
nube
En el artículo anterior de esta serie, las cargas de trabajo y las tareas se asignaron a versiones e iteraciones.
Estas asignaciones alimentan las estimaciones de la escala de tiempo en este artículo.
Las estructuras de descomposición del trabajo se usan normalmente en herramientas de administración de
proyectos secuenciales. Representan cómo se completarán las tareas dependientes con el tiempo. Estas
estructuras funcionan bien cuando las tareas son secuenciales por naturaleza. Las interdependencias de las
tareas que se encuentran en la adopción de la nube hacen que estas estructuras sean difíciles de administrar.
Para rellenar esta brecha, puede hacer una estimación de las escalas de tiempo en función de las asignaciones
de rutas de iteración ocultando la complejidad.

Para desarrollar una escala de tiempo, empiece con las versiones. Estos objetivos de versión crean una fecha
objetivo para cualquier impacto empresarial. Las iteraciones ayudan a alinear esas versiones con períodos de
tiempo específicos.
Si se necesitan hitos más granulares en la escala de tiempo, utilice la asignación de iteraciones para indicar los
hitos. Para realizar esta asignación, supongamos que la última instancia de una tarea relacionada con la carga de
trabajo puede servir como el hito final. Los equipos también etiquetan normalmente la tarea final como un hito.
Para cualquier nivel de granularidad, use el último día de la iteración como la fecha de cada hito. Esto vincula la
finalización de la adopción de la carga de trabajo a una fecha específica. Puede realizar un seguimiento de la
fecha en una hoja de cálculo o una herramienta de administración de proyectos secuenciales como Microsoft
Project.
Planes de entrega en Azure DevOps

Si usa Azure DevOps para administrar el plan de adopción de la nube, considere la posibilidad de usar la
extensión Microsoft Delivery Plans. Esta extensión puede crear rápidamente una representación visual de la
escala de tiempo en función de las asignaciones de versiones y de iteraciones.
Valoración de cargas de trabajo locales para
migrarlas a Azure
En este artículo se muestra cómo la empresa ficticia Contoso valora una aplicación local para la migración a
Azure. En el escenario de ejemplo, la aplicación SmartHotel360 local de Contoso se ejecuta actualmente en
VMware. Contoso evalúa las máquinas virtuales de la aplicación mediante el servicio Azure Migrate, y la base de
datos de aplicación de SQL Server con Data Migration Assistant.
Al plantearse la migración a Azure, la empresa Contoso necesita realizar una valoración técnica y financiera para
determinar si sus cargas de trabajo locales son buenas candidatas para la migración a la nube. En concreto, el
equipo de Contoso quiere valorar la compatibilidad de las máquinas y bases de datos para la migración. Desea
calcular la capacidad y los costos de ejecutar los recursos de Contoso en Azure.
Para empezar y comprender mejor las tecnologías implicadas, Contoso valorará dos de sus aplicaciones locales,
que se resumen en la tabla siguiente. La compañía valora los escenarios de migración de rehospedaje y
refactorización de las aplicaciones para la migración. Obtenga más información sobre el rehospedaje y la
refactorización en la información general sobre los ejemplos de migración.
N O M B RE DE L A
A P L IC A C IÓ N P L ATA F O RM A C A PA S DE A P L IC A C IÓ N DETA L L ES
Smar tHotel360 Se ejecuta en Windows con Aplicación de dos niveles. El Las máquinas virtuales se
una base de datos de SQL sitio web ASP.NET de front- ejecutan en un host de
(administra los requisitos de Server end se ejecuta en una VMware ESXi administrado
viajes de Contoso) máquina virtual ( WEBVM ) y por vCenter Server.
el servidor SQL Server se
ejecuta en otra máquina Puede descargar la
virtual ( SQLVM ). aplicación de ejemplo de
GitHub.
osTicket Se ejecuta en una pila Aplicación de dos niveles. El La aplicación la usan las
LAMP. sitio web PHP front-end se aplicaciones de servicio de
(Aplicación del servicio de ejecuta en una máquina atención al cliente con el fin
atención al cliente de virtual ( OSTICKETWEB ) y la de hacer un seguimiento de
Contoso) base de datos MySQL se problemas para los
ejecuta en otra máquina empleados internos y
virtual ( OSTICKETMYSQL ). clientes externos.
Puede descargar el ejemplo

de GitHub.
Arquitectura actual
En este diagrama se muestra la infraestructura local actual de Contoso:
Contoso tiene un centro de datos principal. El centro de datos está situado en la ciudad de Nueva York, al este
de los Estados Unidos.
Contoso tiene tres sucursales locales más en los Estados Unidos.
El centro de datos principal está conectado a Internet con una conexión Metro Ethernet de fibra óptica
(500 Mbps).
Cada una de las sucursales está conectada localmente a Internet mediante conexiones de categoría
empresarial, y con túneles VPN con IPSec hacia el centro de datos principal. Esta configuración permite que
la red entera de Contoso esté conectada de forma permanente, y además optimiza la conectividad a Internet.
El centro de datos principal está completamente virtualizado con VMware. Contoso tiene dos hosts de
virtualización ESXi 6.5 que están administrados por vCenter Server 6.5.
Contoso usa Active Directory para la administración de identidades. Contoso usa servidores DNS en la red
interna.
Los controladores de dominio del centro de datos se ejecutan en VM de VMware. Los controladores de
dominio de las sucursales locales se ejecutan en servidores físicos.
Impulsores del negocio

El equipo directivo de TI de Contoso ha trabajado estrechamente con sus asociados comerciales para
comprender lo que quiere lograr la empresa con esta migración:
Abordar el crecimiento del negocio. Contoso está creciendo. Como resultado, ha aumentado la presión
sobre los sistemas locales y la infraestructura de la empresa.
Aumentar la eficacia. Contoso debe quitar procedimientos innecesarios y optimizar los procesos para sus
desarrolladores y usuarios. La empresa necesita que el departamento de TI sea rápido y no malgaste tiempo
ni dinero a fin de satisfacer más rápidamente los requisitos del cliente.
Aumentar la agilidad. el equipo de TI de Contoso necesita más capacidad de respuesta a las necesidades
de la empresa. Debe ser capaz de anticiparse a los cambios que se producen en el mercado para que la
empresa tenga éxito en una economía global. No debe ser un obstáculo ni convertirse en un inhibidor del
negocio.
Escala. a medida que el negocio crece satisfactoriamente, el equipo de TI de Contoso debe proporcionar
sistemas que puedan crecer al mismo ritmo.
Objetivos de la valoración
El equipo de la nube de Contoso ha establecido los objetivos de estas valoraciones de la migración:
Tras la migración, la aplicación de Azure debe tener las mismas funcionalidades de rendimiento que las que
tiene actualmente en el entorno de VMware local de Contoso. Pasar a la nube no significa que el rendimiento
de la aplicación sea menos crítico.
Contoso debe comprender la compatibilidad de sus aplicaciones y bases de datos con los requisitos de
Azure. Contoso debe comprender también las opciones de hospedaje en Azure.
La administración de las bases de datos de Contoso debe minimizarse después de trasladar las aplicaciones a
la nube.
Contoso quiere comprender no solo las opciones de migración, sino también los costos asociados con la
infraestructura una vez trasladada a la nube.
Herramientas de valoración
Contoso usa las herramientas de Microsoft para su valoración de la migración. Estas herramientas se alinean
con los objetivos de la compañía y ofrecen a Contoso toda la información que necesita.
T EC H N O LO GY DESC RIP C IÓ N C O ST E
Data Migration Assistant Contoso usa Data Migration Assistant Data Migration Assistant es una
para valorar y detectar problemas de herramienta gratuita y descargable.
compatibilidad que podrían afectar a la
funcionalidad de su base de datos en
Azure. Data Migration Assistant valora
la paridad de características entre los
orígenes y los destinos SQL.
Recomienda mejoras de rendimiento y
confiabilidad.
Azure Migrate Contoso usa el servicio Azure Migrate Azure Migrate está disponible sin
para valorar sus máquinas virtuales de costo adicional. Sin embargo, puede
VMware. Azure Migrate valora la incurrir en cargos según las
idoneidad de las máquinas para la herramientas (propias o de otros ISV)
migración. Proporciona estimaciones que decida usar para la evaluación y
de tamaño y costos para su ejecución migración. Más información sobre los
en Azure. precios de Azure Migrate.
Mapa de servicio Azure Migrate usa Service Map para Service Map forma parte de los
mostrar las dependencias entre las registros de Azure Monitor.
máquinas que la compañía desea Actualmente, Contoso puede usar
migrar. Service Map durante 180 días sin
ningún costo.
En este escenario, Contoso descarga y ejecuta Data Migration Assistant para valorar la base de datos de SQL
Server local de su aplicación de viajes. Contoso usa Azure Migrate con asignación de dependencias para valorar
las máquinas virtuales de la aplicación antes de migrarlas a Azure.
Arquitectura de valoración
Contoso es un nombre ficticio que representa una organización empresarial típica.
Contoso tiene un centro de datos local ( contoso-datacenter ) y controladores de dominio locales (
CONTOSODC1 y CONTOSODC2 ).
Las máquinas virtuales de VMware se encuentran en hosts VMware ESXi que ejecutan la versión 6.5 (
contosohost1 y contosohost2 ).
El entorno de VMware lo administra vCenter Server 6.5 ( vcenter.contoso.com , que se ejecuta en una
máquina virtual).
La aplicación de viajes SmartHotel360 tiene estas características:
La aplicación se divide en niveles entre dos máquinas virtuales de VMware ( WEBVM y SQLVM ).
Las máquinas virtuales se encuentran en el host de VMware ESXi contosohost1.contoso.com .
Las máquinas virtuales ejecutan Windows Server 2008 R2 Datacenter con SP1.
El entorno de VMware lo administra vCenter Server ( vcenter.contoso.com ) que se ejecuta en una máquina
virtual.
Aplicación del departamento de atención al cliente oSTicket:
La aplicación se divide en niveles entre dos máquinas virtuales ( OSTICKETWEB y OSTICKETMYSQL ).
Las máquinas virtuales se ejecutan en Ubuntu Linux Server 16.04-LTS.
OSTICKETWEB ejecuta Apache 2 y PHP 7.0.
OSTICKETMYSQL ejecuta MySQL 5.7.22.
Requisitos previos
Contoso y otros usuarios deben cumplir los siguientes requisitos previos para la valoración:
Permisos de propietario o colaborador para la suscripción de Azure, o para un grupo de recursos en la
suscripción de Azure.
Una instancia local de vCenter Server que ejecute las versiones 6.5, 6.0 o 5.5.
Una cuenta de solo lectura de vCenter Server, o permisos para crearla.
Permisos para crear una máquina virtual en la instancia de vCenter Server mediante una plantilla .ova.
Al menos un host ESXi en el que se ejecute la versión 5.5 o versiones posteriores.
Al menos dos máquinas virtuales VMware locales, y en una de ellas debe ejecutarse una base de datos de
SQL Server.
Permisos para instalar agentes de Azure Migrate en todas las máquinas virtuales.
Las máquinas virtuales deben tener conectividad directa a Internet.
Puede restringir el acceso a Internet a las direcciones URL necesarias.
Si las máquinas virtuales no tienen conexión a Internet, la puerta de enlace de Azure Log Analytics
debe estar instalada en ellas y se debe dirigir el tráfico a través de esta.
El nombre de dominio completo de la máquina virtual que ejecuta la instancia de SQL Server, para la
evaluación de la base de datos.
La instancia de Firewall de Windows que se ejecuta en la máquina virtual de SQL Server debe permitir
conexiones externas en el puerto TCP 1433 (valor predeterminado). Esta configuración permite que Data
Migration Assistant se conecte.
Introducción a la valoración
Le mostramos cómo realiza Contoso la valoración:
Paso 1: Descarga e instalación de Data Migration Assistant. Contoso prepara Data Migration
Assistant para la valoración de la base de datos de SQL Server local.
Paso 2: Valoración de la base de datos mediante Data Migration Assistant. Contoso ejecuta y
analiza la valoración de la base de datos.
Paso 3: Preparación de la valoración de las máquinas vir tuales con Azure Migrate. Contoso
configura las cuentas locales y ajusta la configuración de VMware.
Paso 4: Detección de máquinas vir tuales locales con Azure Migrate. Contoso crea una máquina
virtual de Azure Migrate Collector. Después, ejecuta el recopilador para detectar las máquinas virtuales que
se valorarán.
Paso 5: Preparación del análisis de dependencias con Azure Migrate. Contoso instala los agentes de
Azure Migrate en las máquinas virtuales para que la compañía pueda ver la asignación de dependencias
entre las máquinas virtuales.
Paso 6: Valoración de las máquinas vir tuales con Azure Migrate. Contoso comprueba las
dependencias, agrupa las máquinas virtuales y ejecuta la valoración. Una vez lista la valoración, Contoso la
analiza para preparar la migración.
NOTE
Las valoraciones no deben limitarse a usar herramientas para descubrir información sobre su entorno. También debe
programar el tiempo necesario para hablar con los propietarios de la empresa, los usuarios finales y otros miembros del
departamento de TI para comprender completamente lo que ocurre en el entorno y entender los factores que las
herramientas no pueden indicar.
Paso 1: Descarga e instalación de Data Migration Assistant

1. Contoso descarga Data Migration Assistant del Centro de descargas de Microsoft.
Data Migration Assistant se puede instalar en cualquier máquina que pueda conectarse a la instancia
de SQL Server. Contoso no necesita ejecutarlo en la máquina de SQL Server.
Data Migration Assistant no debe ejecutarse en el equipo host de SQL Server.
2. Para iniciar la instalación, Contoso ejecuta el archivo de instalación descargado
(DownloadMigrationAssistant.msi).
3. En la página Finalizar , Contoso selecciona Launch Microsoft Data Migration Assistant (Iniciar
Microsoft Data Migration Assistant) antes de finalizar el asistente.
Paso 2: Ejecución y análisis de la valoración de la base de datos de

SmartHotel360
Ahora, Contoso puede ejecutar una valoración para analizar su base de datos de SQL Server local para la
aplicación SmartHotel360.
1. En Data Migration Assistant, Contoso selecciona Nuevo > Evaluación y, a continuación, asigna a la
valoración un nombre de proyecto.
2. En Tipo de ser vidor de origen , Contoso selecciona SQL Ser ver y en Tipo de ser vidor de destino ,
selecciona SQL Ser ver en Azure Vir tual Machines
NOTE
Actualmente, Data Migration Assistant no permite realizar valoraciones para migrar a Azure SQL Managed
Instance. Como alternativa, Contoso usa SQL Server en una máquina virtual de Azure como supuesto objetivo de
la valoración.
3. En Seleccionar versión de destino , Contoso selecciona SQL Server 2017 como versión de destino.
Contoso debe seleccionar esta versión, porque es la versión que usa SQL Managed Instance.
4. Contoso selecciona los informes para detectar información sobre la compatibilidad y nuevas
características:
Los problemas de compatibilidad indican los cambios que pueden interrumpir la migración o que
requieren un ajuste menor antes de la migración. Este informe mantiene informado a Contoso sobre
las características actualmente en uso que han quedado en desuso. Los problemas se organizan por
nivel de compatibilidad.
Las nuevas recomendaciones de características indican las nuevas características de la
plataforma de SQL Server de destino que se pueden usar para la base de datos después de la
migración. Las recomendaciones de características nuevas se organiza en los encabezados
Rendimiento , Seguridad y Almacenamiento .
5. En Conectar a un ser vidor , Contoso escribe el nombre de la máquina virtual que ejecuta la base de
datos y las credenciales para acceder a ella. Contoso selecciona Confiar en el cer tificado del ser vidor
para asegurarse de que la máquina virtual puede acceder a SQL Server. A continuación, Contoso
selecciona Conectar .
6. En Agregar origen , Contoso agrega la base de datos que quiere valorar y, después, selecciona
Siguiente para iniciar la valoración.
7. Se crea la valoración.
8. En Revisar los resultados , Contoso puede ver los resultados de la valoración.
Análisis de la evaluación de la base de datos
Los resultados se muestran en cuanto están disponibles. Si Contoso corrige los problemas, debe seleccionar
Reiniciar valoración para volver a ejecutar la valoración.
1. En el informe Problemas de compatibilidad , Contoso comprueba si existen problemas en cada nivel
de compatibilidad. Los niveles de compatibilidad se asignan a las versiones de SQL Server como sigue:
100: SQL Server 2008/Azure SQL Database
2. En el informe Recomendaciones de características , Contoso puede ver las características de

rendimiento, seguridad y almacenamiento que la valoración recomienda después de la migración. Se
recomiendan varias características, entre las que se incluyen OLTP en memoria, índices de almacén de
columnas, Stretch Database, Always Encrypted, enmascaramiento dinámico de datos y cifrado de datos
transparente.
NOTE
Contoso debe habilitar el cifrado de datos transparente para todas las bases de datos de SQL Server. Esto es
incluso más importante cuando una base de datos está en la nube que cuando está hospedada en el entorno
local. El cifrado de datos transparente debe habilitarse solo después de la migración. Si el cifrado de datos
transparente ya está habilitado, Contoso debe trasladar el certificado o la clave asimétrica a la base de datos
master del servidor de destino. Vea cómo mover una base de datos protegida por cifrado de datos transparente
a otra instancia de SQL Server.
3. Contoso puede exportar la valoración en formato JSON o CSV.
NOTE
Para valoraciones a gran escala:
Ejecute varias valoraciones de manera simultánea y vea su estado en la página Todas las valoraciones .
Consolide las valoraciones en una base de datos de SQL Server.
Consolide las valoraciones en un informe de Power BI.
Paso 3: Preparación de la valoración de las máquinas virtuales con

Azure Migrate
Contoso debe crear una cuenta de VMware que Azure Migrate usará para detectar automáticamente las
máquinas virtuales que se van a valorar, comprobar que dispone de permisos para crear una máquina virtual,
anotar los puertos que deben estar abiertos y establecer el nivel de configuración de las estadísticas.
Configuración de una cuenta de VMware
La detección de máquinas virtuales requiere una cuenta de solo lectura en vCenter Server, con las siguientes
propiedades:
Tipo de usuario: Al menos un usuario de solo lectura.
Permisos: para el objeto de centro de datos, seleccione la casilla Propagate to Child Objects (Propagar a
objetos secundarios). En Role (Rol), seleccione Read-only (Solo lectura).
Detalles: el usuario se asigna en el nivel de centro de datos con acceso a todos los objetos de dicho centro
de datos.
Para restringir el acceso, asigne el rol Sin acceso con Propagar a objetos secundarios a los objetos
secundarios (hosts de vSphere, almacenes de datos, máquinas virtuales y redes).
Comprobación de los permisos para crear una máquina virtual
Para comprobar que tiene permisos para crear una máquina virtual, Contoso importa un archivo en formato
.OVA. Vea cómo crear y asignar un rol con privilegios.
Comprobación de puertos
La valoración de Contoso usa la asignación de dependencia. La asignación de dependencias requiere que haya
un agente instalado en las máquinas virtuales que se valorarán. El agente debe poder conectarse a Azure desde
el puerto TCP 443 de todas las máquinas virtuales. Más información acerca de los requisitos de la conexión.
Paso 4: Detectar máquinas virtuales

Para detectar las VM, Contoso crea un proyecto de Azure Migrate. Contoso descarga y configura la máquina
virtual del recopilador. Después, Contoso ejecuta el recopilador para detectar las máquinas virtuales locales.
Crear un proyecto
Para configurar un proyecto nuevo de Azure Migrate, siga los pasos que se indican a continuación.
1. En Azure Portal > Todos los ser vicios , busque Azure Migrate .
2. En Ser vicios , seleccione Azure Migrate .
3. En Información general , en Detectar, evaluar y migrar ser vidores , seleccione Evaluar y migrar
ser vidores .
4. En Introducción , seleccione Agregar herramientas .

5. En Migrar proyecto , seleccione la suscripción a Azure y cree un grupo de recursos, en caso de que no lo
tenga.
6. En Detalles del proyecto , especifique el nombre del proyecto y la geografía en que desea crearlo. Se
admiten Estados Unidos, Asia, Europa, Australia, Reino Unido, Canadá, India y Japón.
La geografía del proyecto solo se utiliza para almacenar los metadatos que se recopilan de las
máquinas virtuales locales.
Al realizar una migración se puede seleccionar cualquier región de destino.
7. Seleccione Next (Siguiente).
8. En Seleccione una herramienta de evaluación , seleccione Azure Migrate: Ser ver Assessment >
Siguiente .
9. En Seleccione una herramienta de migración , seleccione Omitir por ahora la adición de una
herramienta de migración > Siguiente .
10. En Revisar y agregar herramientas , revise la configuración y seleccione Agregar herramientas .
11. Espere unos minutos para que se implemente el proyecto de Azure Migrate. Se le dirigirá a la página del
proyecto. Si no ve el proyecto, puede acceder a él desde Ser vidores en el panel de Azure Migrate.
Descarga del dispositivo de recopilador
1. En Objetivos de migración > Ser vidores > Azure Migrate: Ser ver Assessment , seleccione
Detectar .
2. En Detectar máquinas > ¿Las máquinas están vir tualizadas? , haga clic en Sí, con VMware
vSphere Hyper visor .
3. Seleccione Descargar para descargar el archivo de plantilla OVA.
Comprobación del dispositivo de recopilador
Antes de implementar la máquina virtual, Contoso comprueba que el archivo OVA sea seguro:
1. En el equipo en el que se descargó el archivo, Contoso abre una ventana del símbolo del sistema con
permisos de administrador.
2. Contoso ejecuta el siguiente comando para generar el código hash del archivo OVA:
C:\> CertUtil -HashFile <file_location> [Hashing Algorithm]
Ejemplo :
C:\> CertUtil -HashFile C:\AzureMigrate\AzureMigrate.ova SHA256
3. El hash generado debe coincidir con los valores hash que se enumeran en la sección Comprobación de la
seguridad del tutorial Evaluación de las máquinas virtuales de VMware para la migración.
Creación del dispositivo de recopilador
Ahora, Contoso puede importar el archivo descargado en la instancia de vCenter Server y aprovisionar la
máquina virtual del dispositivo recopilador:
1. En la consola de vSphere Client, Contoso selecciona File (Archivo) > Deploy OVF Template
(Implementar plantilla de OVF).
2. En Deploy OVF Template Wizard (Asistente para implementar la plantilla de OVF), Contoso selecciona
Source (Origen) y especifica la ubicación del archivo OVA.
3. En Name and Location (Nombre y ubicación), Contoso especifica un nombre para mostrar para la
máquina virtual del recopilador. A continuación, selecciona la ubicación del inventario en el que se va a
hospedar la máquina virtual. Contoso también especifica el host o clúster donde se ejecutará el
dispositivo recopilador.
4. En Storage (Almacenamiento), Contoso especifica la ubicación de almacenamiento. En Disk Format
(Formato de disco), Contoso selecciona cómo quiere aprovisionar el almacenamiento.
5. En Network Mapping (Asignación de red), Contoso especifica la red a la que se va a conectar la
máquina virtual del recopilador. La red necesita conectividad a Internet, para enviar metadatos a Azure.
6. Contoso revisa la configuración y selecciona Power on after deployment > Finish (Encender después
de la implementación > Finalizar). Una vez creado el dispositivo, aparece un mensaje que confirma la
finalización correcta.
Ejecución del recopilador para detectar VM
Ahora, Contoso ejecuta el recopilador para detectar las máquinas virtuales. Tenga en cuenta que, actualmente, el
recopilador solo admite Inglés (Estados Unidos) como idioma del sistema operativo e idioma de la interfaz
del recopilador.
1. En la consola de vSphere Client, Contoso selecciona Open Console (Abrir consola). Contoso especifica
las preferencias aceptación de los términos de licencia y de contraseña para la máquina virtual del
recopilador.
2. En el escritorio, Contoso selecciona el acceso directo Microsoft Azure Appliance Configuration
Manager .
3. En Azure Migrate Collector, Contoso selecciona Set Up Prerequisites (Configurar los requisitos
previos). Contoso acepta los términos de licencia y lee la información de terceros.
4. El recopilador comprueba que la máquina virtual tiene acceso a Internet, que la hora está sincronizada y
que el servicio de recopilador se está ejecuando. (El recopilador se instala de forma predeterminada en la
máquina virtual). Contoso también instala el kit de desarrollo VMware vSphere Virtual Disk.
NOTE
Se da por hecho que la máquina virtual tiene acceso directo a Internet, sin un proxy.
5. Inicie sesión en su cuenta de Azure, seleccione la suscripción y migre el proyecto que creó anteriormente.
Escriba un nombre para el dispositivo para poder identificarlo en Azure Portal.
6. En Especificar los detalles de vCenter Ser ver , Contoso especifica el nombre completo (FQDN) o la
dirección IP de la instancia de vCenter Server y las credenciales de solo lectura que se usan para la
detección.
7. Contoso selecciona un ámbito para la detección de máquinas virtuales. El recopilador solo puede detectar
máquinas virtuales dentro del ámbito especificado. El ámbito se puede establecer en una carpeta, un
centro de datos o un clúster específicos.
8. El recopilador comenzará a detectar y recopilar la información sobre el entorno de Contoso.

Comprobación de VM en el portal
Una vez completada la recopilación, Contoso comprueba que las máquinas virtuales aparecen en el portal.
1. En el proyecto de Azure Migrate, Contoso selecciona **Servidores****. Contoso comprueba que se
muestran las máquinas virtuales que desea detectar.
2. Las máquinas actualmente no tienen instalados los agentes de Azure Migrate. Contoso debe instalar los
agentes para ver las dependencias.
Paso 5: Preparación del análisis de dependencias

Para ver las dependencias existentes entre las máquinas virtuales que Contoso quiere evaluar, este descarga e
instala los agentes en las máquinas virtuales de la aplicación. Contoso instala los agentes en todas las máquinas
virtuales para sus aplicaciones, tanto para Windows como para Linux.
Realización de una instantánea
Para conservar una copia de las máquinas virtuales antes de modificarlas, Contoso crea una instantánea antes
de instalar los agentes.
Descarga e instalación de los agentes en máquinas virtuales

1. En Máquinas , Contoso selecciona la máquina. En la columna Dependencias , Contoso selecciona
Requiere instalación .
2. En el panel Detectar máquinas , Contoso:
Descarga Microsoft Monitoring Agent y Microsoft Dependency Agent para cada máquina virtual
Windows.
Descarga Microsoft Monitoring Agent y Microsoft Dependency Agent para cada máquina virtual
Linux.
3. Contoso copia la clave y el identificador de área de trabajo. Necesita el identificador de área de trabajo y
la clave cuando instala Microsoft Monitoring Agent.
Instalar los agentes en máquinas virtuales de Windows

Contoso ejecuta la instalación en cada máquina virtual.
Instalar el MMA en máquinas virtuales de Windows
1. Contoso hace doble clic en el agente descargado.
2. En la página Carpeta de destino cambie o mantenga la carpeta de instalación predeterminada y
seleccione Siguiente .
3. En Agent Setup Options (Opciones de instalación del agente), Contoso selecciona Connect the agent
to Azure Log Analytics (Conectar el agente a Azure Log Analytics) > Next (Siguiente).
4. En Azure Log Analytics , Contoso pega la clave y el identificador del área de trabajo que copió del
portal.
5. En Ready to Install (Listo para instalar), Contoso instala el agente MMA.

Instalación de Microsoft Dependency Agent en máquinas virtuales Windows
1. Contoso hace doble clic en el agente descargado.
2. Contoso acepta los términos de licencia y espera a que finalice la instalación.
Instalar los agentes en VM Linux
Contoso ejecuta la instalación en cada máquina virtual.
Instalar el MMA en VM Linux
1. Contoso instala la biblioteca ctypes de Python en cada máquina virtual con el comando siguiente:
sudo apt-get install python-ctypeslib
2. Contoso debe ejecutar el comando para instalar al agente MMA como usuario raíz. Para ser usuario raíz,
se debe ejecutar el siguiente comando y escribir la contraseña raíz:
sudo -i
3. Contoso instala el agente MMA:

Contoso especifica el identificador y la clave del área de trabajo en el comando.
Los comandos son para 64 bits.
El identificador y la clave principal del área de trabajo se encuentran en el área de trabajo de Log
Analytics en Azure Portal. Seleccione Configuración y, después, Orígenes conectados .
Ejecute los siguientes comandos para descargar el agente de Log Analytics, validar la suma de
comprobación e instalar e incorporar el agente:
wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-
Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w 6b7fcaff-7efb-4356-
ae06-516cacf5e25d -s
k7gAMAw5Bk8pFVUTZKmk2lG4eUciswzWfYLDTxGcD8pcyc4oT8c6ZRgsMy3MmsQSHuSOcmBUsCjoRiG2x9A8Mg==
Instalación de Microsoft Dependency Agent en máquinas virtuales Linux

Después de instalar Microsoft Monitoring Agent, Contoso puede instalar Microsoft Dependency Agent en las
máquinas virtuales Linux:
1. Microsoft Dependency Agent se instala en equipos Linux con InstallDependencyAgent-Linux64.bin , un
script de shell que tiene un archivo binario autoextraíble. Contoso ejecuta el archivo con sh o agrega los
permisos de ejecución al archivo mismo.
2. Contoso instala Dependency Agent para Linux como raíz:
wget --content-disposition https://aka.ms/dependencyagentlinux -O InstallDependencyAgent-Linux64.bin
&& sudo sh InstallDependencyAgent-Linux64.bin -s
Paso 6: Ejecución y análisis de la valoración de la máquina virtual

Ahora, Contoso puede comprobar las dependencias de la máquina y crear un grupo. A continuación, ejecuta la
valoración para el grupo.
Comprobar las dependencias y crear un grupo
1. Para determinar qué máquinas se analizarán, Contoso selecciona Ver dependencias .
2. Para SQLVM, el mapa de dependencias muestra los siguientes detalles:

Los procesos o grupos de procesos que tienen conexiones de red activas en ejecución en SQLVM,
durante el período especificado (una hora de forma predeterminada).
Conexiones TCP de entrada (cliente) y de salida (servidor) a y desde todas las máquinas dependientes.
Las máquinas dependientes que tienen instalados los agentes de Azure Migrate se muestran como
cuadros independientes.
Las máquinas que no tienen instalados los agentes muestran la información del puerto y la dirección
IP.
3. En el caso de las máquinas que tienen instalado el agente ( WEBVM ), Contoso activa la casilla de la
máquina para ver más información. La información incluye el nombre de dominio completo, el sistema
operativo y la dirección MAC.
4. Contoso selecciona las máquinas virtuales para agregar al grupo ( SQLVM y WEBVM ). Contoso mantiene
presionada la tecla Ctrl mientras selecciona varias máquinas virtuales.
5. Contoso selecciona Crear grupo y escribe un nombre ( smarthotelapp ).
NOTE
Para ver dependencias más pormenorizadas, puede expandir el intervalo de tiempo. Puede seleccionar una
duración concreta o las fechas de inicio y finalización.
Ejecución de una evaluación

1. En Grupos , Contoso abre el grupo ( smarthotelapp ) y, después, selecciona Crear evaluación .
2. Para ver la evaluación, Contoso selecciona Administrar > Evaluaciones .

Contoso usa la configuración de valoración predeterminada, pero es posible personalizar la configuración.
Análisis de la evaluación de la máquina virtual
En la valoración de Azure Migrate se incluye información sobre la compatibilidad del entorno local con Azure,
una sugerencia para el tamaño correcto de la máquina virtual de Azure y los costos mensuales estimados de
Azure.
Examen de la clasificación de confianza
La valoración obtiene una clasificación de confianza de 1 a 5 estrellas (siendo 1 estrella la menor confianza y 5,
la mayor).
La clasificación de la confianza se asigna a una valoración en función de la disponibilidad de los puntos
de datos necesarios para calcular dicha valoración.
Esta clasificación le ayuda a calcular la confiabilidad de las recomendaciones de tamaño que proporciona
Azure Migrate.
La clasificación de confianza es útil cuando se realiza un ajuste de tamaño basado en el rendimiento.
Azure Migrate podría no tener suficientes puntos de datos para ajustar el tamaño en función del uso. Para
el ajuste de tamaño como local, la clasificación de confianza siempre es de 5 estrellas, puesto que Azure
Migrate tiene todos los datos que necesita para ajustar el tamaño de la máquina virtual.
Según el porcentaje de puntos de datos disponibles, se proporciona la clasificación de confianza para la
valoración:
DISP O N IB IL IDA D DE P UN TO S DE DATO S C L A SIF IC A C IÓ N DE C O N F IA N Z A
0 % - 20 % 1 estrella
DISP O N IB IL IDA D DE P UN TO S DE DATO S C L A SIF IC A C IÓ N DE C O N F IA N Z A
21 % - 40 % 2 estrellas
41 % - 60 % 3 estrellas
61 % - 80 % 4 estrellas
81 % - 100 % 5 estrellas
Comprobación de la preparación para Azure
El informe de la valoración muestra la información que se resume en la tabla. Para mostrar el ajuste de tamaño
basado en el rendimiento, Azure Migrate necesita la siguiente información. Si dicha información no se pueden
recopilar, es posible que la valoración del tamaño no sea precisa.
Datos de uso de la CPU y la memoria.
IOPS de lectura o escritura, y capacidad de proceso de cada disco conectado a la máquina virtual.
Información de entrada y salida de la red de todos y cada uno de los adaptadores de red conectados a la
máquina virtual.
C O N F IGURA C IÓ N IN DIC A C IÓ N DETA L L ES
Preparación para VM de Azure Indica si la máquina virtual está Los posibles estados son:
preparada para la migración. Preparada para Azure
Preparada con condiciones
No está preparada para Azure
Preparación desconocida
Si alguna máquina virtual no está lista,

Azure Migrate muestra varios pasos
para solucionarlo.
Tamaño de la máquina vir tual de Para las máquinas virtuales que están El tamaño recomendado depende de
Azure listas, Azure Migrate ofrece una las propiedades de la evaluación:
recomendación de tamaño de máquina Si usó un tamaño basado en el
virtual de Azure. rendimiento, entonces dicho tamaño
tiene en cuenta el historial de
rendimiento de las máquinas virtuales.
Si usó el tamaño como entorno
local, este se basará en el tamaño de la
máquina virtual local y su uso.
No se utilizan datos.
C O N F IGURA C IÓ N IN DIC A C IÓ N DETA L L ES
Herramienta sugerida Como las máquinas de Azure ejecutan

los agentes, Azure Migrate examina los
procesos que se ejecutan dentro de la
máquina. Identifica si la máquina es
una máquina de base de datos.
Información de máquina vir tual El informe muestra la configuración de

la máquina virtual local, lo que incluye
información acerca del sistema
operativo, el tipo de arranque, los
discos y el almacenamiento.
Examen de cálculos del costo mensual

Esta vista muestra el costo total de los recursos de proceso y almacenamiento para ejecutar las máquinas
virtuales en Azure. También muestra información detallada para cada máquina.
Las estimaciones de los costos se calculan con las recomendaciones de tamaño de una máquina.
Los costos mensuales estimados para el proceso y almacenamiento se agregan para todas las VM del grupo.
Limpiar después de la valoración

Una vez finalizada la valoración, Contoso conserva el dispositivo de Azure Migrate para valoraciones futuras.
Contoso apaga la máquina virtual de VMware. La usará otra vez cuando valore otras máquinas virtuales
adicionales.
Contoso conserva el proyecto Contoso Migration en Azure. Actualmente, el proyecto está implementado en
el grupo de recursos ContosoFailoverRG , en la región Este de EE. UU de Azure.
La máquina virtual del recopilador tiene una licencia de evaluación de 180 días. Si este límite expira, Contoso
deberá descargar y volver a configurar el recopilador.
Conclusión
En este escenario, Contoso valora la base de datos de la aplicación SmartHotel360 con la herramienta Data
Migration Assistant. Valora las máquinas virtuales locales con el servicio Azure Migrate. Contoso revisa las
valoraciones para asegurarse de que los recursos locales están listos para la migración a Azure.
Pasos siguientes
Una vez que Contoso valore esta carga de trabajo como posible candidata para la migración, puede empezar a
preparar su infraestructura local y su infraestructura de Azure para la migración. Consulte el artículo sobre la
implementación de la infraestructura de Azure en la sección de procedimientos recomendados para la
migración de la Plataforma de adopción de la nube para ver un ejemplo de cómo Contoso realiza estos
procesos.
Planeamiento de una migración de almacén de
datos
La migración del almacenamiento de datos es un desafío para cualquier empresa. Para llevarla a cabo
correctamente y evitar sorpresas imprevistas y costos no planeados, debe investigar minuciosamente las
dificultades, mitigar los riesgos y planear la migración para asegurarse de que está lo más preparado posible. A
nivel general, el plan debe cubrir los pasos principales del proceso de migración del almacenamiento de datos y
las tareas incluidas en ellos. Los pasos principales del proceso son:
Preparación antes de la migración
Estrategia de migración y ejecución
Después de la migración
La preparación incluye, por ejemplo, aspectos como la puesta a punto del equipo de migración del
almacenamiento de datos en términos de las habilidades necesarias y la familiarización con la tecnología.
También conlleva configurar un laboratorio de prueba de concepto, saber cómo se administrarán los entornos
de prueba y producción, conseguir la autorización adecuada para migrar los datos y un sistema de producción
fuera del firewall corporativo y configurar el software de migración en el centro de datos para que la migración
pueda continuar.
Para que la migración de un almacenamiento de datos se lleve a cabo sin problemas, el plan debe incluir una
comprensión clara de los siguientes aspectos:
El caso empresarial: los factores determinantes, las ventajas para el negocio y los riesgos.
Los roles y las responsabilidades del equipo de migración.
El conjunto de aptitudes y el entrenamiento necesarios para permitir una migración correcta.
El presupuesto asignado para finalizar la migración.
La estrategia de migración.
El modo de combatir los riesgos del proyecto de migración con el fin de evitar retrasos o reprocesamientos.
El sistema de almacenamiento de datos existente, su arquitectura, esquema, volúmenes de datos, flujos de
datos, seguridad y dependencias operativas.
Las diferencias entre el DBMS de almacenamiento de datos local existente y Azure Synapse, como los tipos
de datos, las funciones SQL, la lógica y otras consideraciones.
Qué se debe migrar y las prioridades.
Las tareas, los enfoques, el orden y las fechas límite de la migración.
Cómo controlar la migración.
Cómo evitar la interrupción del usuario mientras se lleva a cabo la migración.
Lo que necesita hacer de forma local para evitar retrasos y que se lleve a cabo la migración.
Las herramientas para permitir la migración segura de esquemas, datos y procesamiento ETL a Azure.
Los cambios en el diseño del modelo de datos que son necesarios durante y después de la migración.
Los cambios de tecnología antes o después de la migración y cómo reducir el reprocesamiento.
La degradación de la tecnología después de la migración.
Cómo implementar las pruebas y el control de calidad para demostrar el éxito.
Los puntos de control para evaluar el progreso y permitir la toma de decisiones.
El plan de contingencia y los puntos de reversión en caso de que se produzcan errores.
Para comprender todo esto, es necesario preparar y comenzar actividades específicas antes de que se inicie la
migración. Echemos un vistazo a lo que eso conlleva con más detalle.
Preparación antes de la migración

Hay varias cosas que deben solucionarse antes de iniciar una migración del almacenamiento de datos.
Los roles principales de un equipo de migración del almacenamiento de datos
Entre los roles principales de un proyecto de migración se incluyen los siguientes:
Propietario de la empresa
Jefe de proyecto (con experiencia en una metodología ágil, como Scrum)
Coordinador del proyecto
Ingeniero de la nube
Administrador de base de datos (DBMS de almacenamiento de datos existente y Azure Synapse)
Modeladores de datos
Desarrolladores de ETL
Especialista en virtualización de datos (posiblemente un administrador de bases de datos)
Ingeniero de pruebas
Analistas de negocio (para ayudar a probar las consultas, los informes y los análisis de las herramientas de
BI)
Además, el equipo necesita el respaldo del equipo de infraestructura local.
Aptitudes y aprendizaje para preparar el equipo para la migración
En lo que respecta a las aptitudes, es importante contar con experiencia en la migración de un almacenamiento
de datos. Por lo tanto, asegúrese de que los miembros adecuados del equipo de migración estén entrenados en
aspectos básicos de la nube de Azure, Azure Blob Storage, Azure Data Lake Storage, Azure Data Box,
ExpressRoute, administración de identidades de Azure, Azure Data Factory y Azure Synapse. Lo más probable es
que los modeladores de datos deban ajustar los modelos de datos de Microsoft Azure Synapse una vez que se
haya producido la migración del almacenamiento de datos existente.
Evaluación del almacenamiento de datos existente
Otra parte de la preparación para la migración es la necesidad de una evaluación completa del almacenamiento
de datos existente para comprender totalmente la arquitectura, los almacenes de datos, el esquema, la lógica de
negocios, los flujos de datos, la funcionalidad de DBMS utilizada, la operación de almacenamiento y las
dependencias. Cuanta más comprensión obtenga aquí, mejor. El conocimiento detallado de cómo funciona el
sistema ayuda a comunicarse y a cubrir todas las bases.
La evaluación tiene como fin no solo garantizar la comprensión detallada de la disposición actual del equipo de
migración, sino también conocer los puntos fuertes y débiles de la disposición actual. Por lo tanto, el resultado
de la evaluación del almacenamiento de datos actual puede afectar a la estrategia de migración: migración
mediante lift-and-shift frente a una solución más amplia. Por ejemplo, si el resultado de una evaluación es que el
almacenamiento de datos está al final del ciclo de vida, es evidente que la estrategia sería más la de una
migración de datos a un almacenamiento de datos recién diseñado en Azure Synapse frente a un enfoque lift-
and-shift.
Preparación local de la migración de datos
Además de preparar y poner a punto el equipo de migración en el entorno de destino y evaluar la disposición
actual, es importante igualmente definir el movimiento local, ya que los almacenamientos de datos de
producción tienden a estar controlados en gran medida por los procedimientos y los procesos de aprobación de
TI. Para evitar retrasos, asegúrese de que los equipos de operaciones e infraestructura del centro de datos están
listos para migrar los datos, el esquema, los trabajos ETL, etc., a la nube de Azure. La migración de datos se
puede realizar por estos medios:
AzCopy en Azure Blob Storage.
Microsoft Azure ExpressRoute para transferir los datos comprimidos directamente a Azure.
Exportación de archivos a Azure Data Box.
Los principales factores que influyen en la selección de estas opciones son el tamaño del volumen de datos (en
terabytes) y la velocidad de la red (en Mbps). Es necesario calcular cuánto tiempo se tardaría en migrar los datos
a través de la red, teniendo en cuenta que los datos podrían comprimirse en el almacenamiento de datos y
descomprimirse al exportarlos. Esta situación puede ralentizar la transferencia de datos. Vuelva a comprimir los
datos mediante Gzip al moverlos por cualquiera de los métodos anteriores. PolyBase puede procesar los datos
comprimidos en Gzip directamente. Es probable que los volúmenes de datos de gran tamaño se migren a través
de Azure Data Box si los datos tardan demasiado tiempo en migrarse.
Además, para que Azure Data Factory controle la ejecución de las exportaciones de los datos del
almacenamiento de datos existente desde Azure, se debe instalar el software de IR autohospedado en el centro
de datos para permitir que continúe la migración. A la vista de estos requisitos, si se necesita una aprobación
formal para que esto sea posible, el inicio de los procesos de aprobación adecuados en una fase temprana para
que esto suceda le ayudará a evitar retrasos más tarde.
Preparación de Azure para la migración de datos y esquemas
En lo relativo a la preparación por parte de Azure, la importación de datos debe administrarse a través de
Microsoft Azure ExpressRoute o Microsoft Azure Data Box. Las canalizaciones de Azure Data Factory son una
buena manera de cargar los datos en Azure Blob Storage y, después, cargarlos desde ahí a Azure Synapse
mediante PolyBase. Por lo tanto, se necesita preparación por parte de Azure para desarrollar este tipo de
canalización.
La alternativa es usar la herramienta ETL existente en Azure si es compatible con Azure Synapse, lo que significa
configurar la herramienta en Azure desde Azure Marketplace y preparar una canalización para importar los
datos y cargarlos en Azure Blob Storage.
Definición de una estrategia de migración

Objetivos de la migración
En cualquier estrategia, debe haber un conjunto de finalidades o metas que definan el éxito de una operación.
Luego, se pueden establecer objetivos para lograr estas metas y asignar responsabilidades a las personas para
alcanzarlos. En la tabla siguiente se muestran ejemplos de metas de la migración y las métricas
correspondientes para establecer los objetivos de un proyecto de migración del almacenamiento de datos en la
nube:
Ejemplos de tipos de metas y métricas:
Mejorar el rendimiento general
Rendimiento de la migración de datos
Rendimiento de ETL
Rendimiento de la carga de datos
Rendimiento de consultas complejas
Número de usuarios simultáneos
Operaciones a un costo más bajo
Costo de proceso por carga de trabajo, por ejemplo, el número de horas de proceso x el costo por hora de:
Informes estándar
Consultas ad hoc
Procesamiento ELT por lotes
Costo de almacenamiento (almacenamiento provisional, tablas de producción, índices, espacio temporal)
Funcionamiento con mejores niveles de servicio y disponibilidad
Contratos de nivel de servicio
Alta disponibilidad
Mejorar la productividad
Automatización de tareas, menor personal administrativo
Por lo tanto, una migración del almacenamiento de datos realizada con éxito se puede interpretar como un
almacenamiento de datos que se ejecuta tan rápido, o más rápido, y a un costo más bajo, que el sistema
heredado del que parte la migración. La asignación de propietarios de estas metas crea el sentido de la
responsabilidad para alcanzarlas. También garantiza que las pruebas en un laboratorio de prueba de concepto
(como se define en la sección de reducción del riesgo de esta guía) se considerarán correctas siempre y cuando
identifiquen formas de conseguir las metas.
Enfoque de migración
Hay varias opciones estratégicas para migrar el almacenamiento de datos existente a Azure Synapse:
Usar el enfoque lift-and-shift con el almacenamiento de datos existente tal cual.
Simplificar el almacenamiento de datos existente para, posteriormente, migrarlo.
Rediseñar completamente el almacenamiento de datos en Azure Synapse y migrar los datos.
Los resultados de la evaluación del almacenamiento de datos existente deberían influir en gran medida en la
estrategia que se va a adoptar. Si el resultado de la evaluación es bueno, podría recomendarse una estrategia
lift-and-shift. Si el resultado es mediocre debido a una clasificación de agilidad baja, podría ser necesario realizar
una simplificación antes de la migración. Si el resultado es deficiente, podría ser necesario un rediseño
completo.
La estrategia lift-and-shift deja la arquitectura como está; lo que intenta es minimizar el trabajo de mover el
sistema existente. Si la herramienta ETL existente ya es compatible con Azure Synapse, es posible que pueda
cambiar el objetivo sin apenas hacer nada. No obstante, habrá diferencias en los tipos de tablas, tipos de datos,
funciones SQL, vistas, lógica de negocios de los procedimientos almacenados, etc. Estas diferencias, y el modo
de compensarlas, se detallan en los documentos de nivel inferior de esta serie de migraciones.
La simplificación del almacenamiento de datos existente antes de la migración tiene como fin reducir la
complejidad para facilitar esta operación. Esta simplificación podría incluir algunas de estas tareas:
Quitar o archivar las tablas no utilizadas antes de la migración para evitar la migración de datos que no se
usan.
Convertir los data marts físicos en data marts virtuales mediante software de virtualización de datos para
reducir lo que se debe migrar. La conversión también mejora la agilidad y reduce el costo total de propiedad,
así que podría considerarse como una modernización durante la migración.
También puede simplificar primero y, luego, aplicar la estrategia lift-and-shift a lo que quede.
Ámbito de la migración
Sea cual sea la estrategia que elija, debe definir claramente el ámbito de la migración, lo que se migrará y si se
hará de forma gradual o todo a la vez. Un ejemplo de migración gradual es migrar primero los data marts, y
luego el almacenamiento de datos. Este enfoque le permitirá centrarse en las áreas empresariales de mayor
prioridad, y dejará que su equipo vaya adquiriendo experiencia, ya que cada data mart se migra de forma
individual antes de migrar el almacenamiento de datos propiamente dicho.
Definición de lo que se debe migrar
Realice un inventario de todo lo que necesite migrar. Entre estos elementos se incluyen el esquema, los datos,
los procesos ETL (canalizaciones), los privilegios de autorización, los usuarios, las capas de acceso semántico de
herramientas de inteligencia empresarial y las aplicaciones analíticas. En cada uno de los artículos de migración
de nivel inferior de esta serie se proporciona una descripción detallada de lo que conlleva la migración del
inventario. A continuación, se muestran los vínculos a estos artículos.
Consideraciones sobre la migración, el diseño y el rendimiento de los esquemas.
Migración de datos, procesamiento ETL y carga.
Acceso a las operaciones de almacenamiento de datos y seguridad.
Migración de visualizaciones e informes.
Minimización del efecto de los problemas de SQL.
Herramientas de terceros que le ayudarán en la migración del almacenamiento de datos.
Si no está seguro de cuál es la mejor estrategia, realice pruebas en un laboratorio de prueba de concepto para
identificar las técnicas más óptimas. Para más información, consulte la sección sobre la reducción de riesgos del
proyecto de migración del almacenamiento de datos.
Control de la migración
La migración del almacenamiento de datos a Azure Synapse conlleva la realización de varias tareas:
Locales, como la exportación de datos.
En la red, como la transferencia de datos.
En la nube de Azure, como la transformación, la integración y la carga de datos.
El problema es que administrar estas tareas puede ser complicado si los scripts y las utilidades se desarrollan,
prueban y ejecutan de forma independiente en los entornos locales y de Azure. La complejidad es mayor si el
control de versiones, la administración de pruebas y la ejecución de la migración no están coordinados.
Estas complejidades se deben evitar y se deben controlar desde un lugar común mediante un repositorio de
control de código fuente para administrar los cambios en los entornos de desarrollo, pruebas y producción. La
ejecución de la migración abarca tareas que deben realizarse de forma local, en la red y en Azure. Dado que
Azure Synapse es el entorno de destino, el control de la ejecución de la migración desde Azure simplifica la
administración. Utilice Azure Data Factory para crear una canalización de control de la migración a fin de regular
la ejecución tanto en el entorno local como en Azure. Esta canalización introduce la automatización y minimiza
los errores. Data Factory se convierte en una herramienta de orquestación de la migración, no solo en una
herramienta de integración de datos empresariales.
Otras opciones para controlar la migración que se encuentran disponibles de la mano de asociados de Microsoft
y que se ejecutan en Azure incluyen herramientas de automatización del almacenamiento de datos para intentar
automatizar la migración. Por ejemplo, proveedores como WhereScape y Attunity. La mayoría de estas
herramientas de automatización van destinadas a un enfoque lift-and-shift de la migración. Incluso en este caso,
puede que haya elementos que no admitan tales herramientas, por ejemplo, los procedimientos almacenados.
Estos productos y otros se detallan en otra guía dedicada a herramientas de terceros que le ayudarán a migrar a
Azure Synapse.
Pruebas de migración
Lo primero que debe hacer es definir una serie de pruebas y un conjunto de resultados de las pruebas que se
deben ejecutar para comprobar que la operación se ha realizado correctamente. Es importante asegurarse de
que todos los aspectos se prueban y se comparan en los sistemas existentes y migrados, como por ejemplo:
Schema
Tipos de datos convertidos cuando sea necesario
Uso de esquemas definidos por el usuario en Azure Synapse para distinguir entre almacenamiento de datos
y tablas de data mart
Usuarios
Roles y asignaciones de estos roles a los usuarios
Privilegios de seguridad de acceso a datos
Privacidad y cumplimiento de los datos
Privilegios que regulan las funcionalidades de administración
Calidad e integridad de los datos
Procesamiento ETL que rellena Azure Synapse tanto hacia el almacenamiento de datos como desde este
hacia cualquier data mart, incluidas las pruebas
Todas las filas de todas las tablas son correctas, incluido el historial
Procesamiento de dimensiones que cambian lentamente
Procesamiento de captura de datos modificados
Cálculos y agregaciones que utilizan funciones que podrían variar entre sistemas
Resultados de todas las consultas, informes y paneles conocidos
Rendimiento y escalabilidad
Funcionalidad analítica
Costos en el nuevo entorno de pago por uso
Automatice las pruebas lo máximo posible, de forma que cada prueba sea repetible y permita un enfoque
coherente en la evaluación de los resultados. Si los informes y los paneles son incoherentes, contar con la
posibilidad de comparar el linaje de los metadatos en los sistemas originales y migrados es útil durante las
pruebas de migración, ya que puede resaltar las diferencias y determinar dónde se produjeron cuando no son
fáciles de detectar.
La mejor manera de hacerlo de forma segura es crear roles, asignarles privilegios de acceso y, luego, asociar
usuarios a roles. Para acceder al almacenamiento de datos recién migrado, configure un proceso automatizado
para crear usuarios y asignar roles. Haga lo mismo para quitar roles a los usuarios.
Comunique la transición a todos los usuarios para que sepan qué está cambiando y qué cabe esperar.
Reducción del riesgo en el proyecto de migración del

almacenamiento de datos
Otro factor importante en la migración del almacenamiento de datos es el de la reducción del riesgo del
proyecto con el fin de maximizar la probabilidad de éxito. Hay varias cosas que se pueden hacer para reducir el
riesgo de la migración de un almacenamiento de datos. Incluyen:
Establecer un laboratorio de prueba de concepto para permitir que su equipo pruebe las cosas, lleve a cabo
pruebas, comprenda los problemas e identifique soluciones y optimizaciones que ayuden a validar los
enfoques de migración, mejorar el rendimiento y reducir los costos. También contribuye a establecer
maneras de automatizar las tareas, usar las herramientas integradas y crear plantillas para capturar
procedimientos recomendados, aprender de la experiencia y realizar un seguimiento de todo lo aprendido.
Constituye una forma valiosa de mitigar el riesgo y aumentar las oportunidades de éxito. Además, puede
asignar propietarios a las pruebas, quienes serán responsables de alcanzar las metas y los objetivos de la
migración definidos en la estrategia de migración.
Incorpore la virtualización de los datos entre las herramientas de inteligencia empresarial y el
almacenamiento de datos y los data marts. Incorpore la transparencia para el usuario con la virtualización de
los datos a fin de reducir el riesgo en la migración de un almacenamiento de datos, y oculte la migración a
los usuarios mediante herramientas de inteligencia empresarial de virtualización de datos, tal como se
muestra en el diagrama siguiente.
Esto tiene como fin romper la dependencia entre los usuarios empresariales que usan herramientas de
inteligencia empresarial de autoservicio y el esquema físico del almacenamiento de datos y los data marts
subyacentes que se van a migrar. Al introducir la virtualización de los datos, cualquier alternancia de esquema
realizada durante la migración del almacenamiento de datos y los data marts a Azure Synapse (por ejemplo,
para optimizar el rendimiento) se puede ocultar a los usuarios empresariales porque solo tienen acceso a las
tablas virtuales de la capa de virtualización de datos. Si se necesita un cambio estructural, solo se deberán
cambiar las asignaciones entre el almacenamiento de datos o los data marts y las tablas virtuales para que esos
cambios y la migración pasen desapercibidos para los usuarios.
Considere el archivado de las tablas existentes identificadas como de uso poco frecuente antes de la
migración del almacenamiento de datos, ya que no tiene mucho sentido migrar tablas que no se usan. Por
ejemplo, se podrían archivar los datos no usados en Azure Blob Storage o en Azure Data Lake Storage y crear
tablas externas en Azure Synapse para los datos que sigan estando en línea.
También podría introducir una máquina virtual (VM) en Azure con una versión de desarrollo (normalmente
gratuita) del DBMS del almacenamiento de datos heredado existente que se ejecuta en ella. De esta forma,
puede mover rápidamente el esquema de almacenamiento de datos existente a la máquina virtual y
trasladarlo luego a Azure Synapse mientras trabaja completamente en la nube de Azure.
Defina el orden y las dependencias de la migración.
Asegúrese de que los equipos de operaciones e infraestructura estén preparados para la migración de los
datos lo antes posible en el proyecto de migración.
Identifique las diferencias en la funcionalidad de DBMS y el momento en que la lógica de negocios
propietaria podría convertirse en un problema. Por ejemplo, no es probable que el uso de procedimientos
almacenados para el procesamiento ELT se migre fácilmente, ni que contenga linaje de metadatos dado que
las transformaciones están enterradas en el código.
Considerar una estrategia para migrar primero los data marts y luego el almacenamiento de datos que es el
origen de estos. Esta estrategia permite la migración gradual, resulta más manejable y es posible clasificar
por orden de prioridad la migración en función de las necesidades empresariales.
Considere la posibilidad de usar la virtualización de los datos para simplificar la arquitectura actual de
almacenamiento de datos antes de la migración; por ejemplo, para reemplazar los data marts por otros
virtuales de forma que pueda eliminar antes de la migración los almacenes de datos físicos y los trabajos ETL
de los data marts sin perder funcionalidades. De esta forma, se reduce el número de almacenes de datos que
se van a migrar, las copias de datos y el costo total de propiedad, y se mejora la agilidad. Esta solución
requiere cambiar de data marts físicos a virtuales antes de migrar el almacenamiento de datos. En muchos
sentidos, puede considerarse un paso de modernización del almacenamiento de datos antes de la migración.
Pasos siguientes
Para más información sobre las migraciones del almacenamiento de datos, asista a un taller de modernización
del almacenamiento de datos en la nube virtual en Azure que ofrece Informatica.
Antipatrones del plan de adopción de la nube
A menudo, los clientes experimentan antipatrones mientras planean una adopción de la nube por muchos
motivos:
Los modelos operativos mal alineados pueden dar lugar a un mayor tiempo de comercialización, a
malentendidos y a mayor presión sobre los departamentos de TI.
A veces, las empresas eligen el modelo de servicio equivocado cuando suponen que el enfoque de
plataforma como servicio (PaaS) reduce los costos.
El cambio de la arquitectura de una organización puede dar lugar a proyectos de reemplazo importantes. La
administración de estos proyectos suele ser compleja e implicar unos altos costos.
Antipatrón: elegir el modelo operativo de nube equivocado

Las prioridades estratégicas de una empresa y el ámbito de su cartera determinan el modelo operativo en la
nube. Los modelos pueden tener distintos tipos de responsabilidad, zonas de aterrizaje y foco. Cuando los
modelos no se alinean con los objetivos de la empresa, pueden producirse problemas:
Mayor tiempo de comercialización
Malentendidos
Mayor presión sobre los departamentos de TI
Ejemplo: asignación de demasiada responsabilidad a un equipo pequeño
Una corporación introduce un modelo operativo que hace que el departamento de TI sea responsable de todo lo
que se ejecuta en la nube. El equipo responsable de la nube está formado por tres personas. Esta configuración
conduce a un recorrido de adopción lento por los siguientes motivos:
El equipo solo aprueba medidas después de comprender completamente su impacto en la empresa, las
operaciones y la seguridad.
Estos problemas no son el área de experiencia principal del equipo.
Los expertos en la materia desearán usar el servicio en la nube, por lo que las unidades de negocio aumentan la
presión. Probablemente, shadow IT emergerá a medida que las unidades de negocio usen tarjetas de crédito de
la empresa para crear entornos para sí mismos.
Resultado preferido: comparación de modelos y creación de un plan de preparación
Revise las prioridades estratégicas, el ámbito de la cartera, los requisitos y las restricciones. Explore las opciones
del modelo operativo comparando los cuatro patrones de operaciones en la nube más comunes con el modelo
operativo de la nube actual. Identifique uno o más modelos operativos de la nube que se adapten a su
organización. A continuación, decídase por un modo. Dado que los roles cambian con los modelos operativos,
cree un plan de preparación de aptitudes antes de pasar a la nube.
Antipatrón: elegir el modelo de servicio equivocado

A veces, las empresas suponen que las soluciones PaaS cuestan menos que las soluciones de infraestructura
como servicio (IaaS). Esta suposición puede conducir a una elección equivocada del modelo de servicio. A
menudo, las empresas preocupadas por los costos cometen este error cuando su principal razón para pasar a la
nube es ahorrar costos. Estas empresas olvidan que también necesitan cambiar los procesos cuando adoptan
PaaS, especialmente cuando trasladan determinadas responsabilidades a los proveedores de nube. El cambio a
PaaS presenta cambios fundamentales en los trabajos de coordinación, las prácticas de ingeniería y las
canalizaciones de entrega. Los costos inesperados aumentan y pueden producirse retrasos.
Ejemplo: elección de PaaS frente a IaaS
Un publicador inicia un programa para migrar sus centros de datos a la nube. Los ejecutivos desean modernizar
la arquitectura de la aplicación y las herramientas actuales, todo a la vez. Algunos de sus motivos son los
siguientes:
Maximizar la rentabilidad.
Desarrollar una cartera de aplicaciones más moderna.
Para su estrategia de adopción, eligen PaaS frente a IaaS. Tras un año en el recorrido de adopción de la nube,
tienen una tasa de adopción lenta. Han tenido que cambiar numerosos procesos, prácticas y herramientas para
adoptar PaaS completamente. La junta no ve los impactos y ventajas habituales asociados con PaaS. Además, los
procesos de TI son más lentos que nunca, mientras que los costos del centro de datos siguen siendo los mismos.
Resultado preferido: minimización de la interrupción para la empresa
Para reducir los trabajos de coordinación, comience con IaaS para los proyectos iniciales de adopción de la nube.
La adopción de nuevos procesos y prácticas es más fácil de administrar cuando se pasa a la nube más adelante
en lugar de hacerlo al principio. Adopte primero IaaS, especialmente en escenarios de transformación del centro
de datos. Al mismo tiempo, ponga en marcha una iniciativa de aptitudes de la nube.
Modernice su arquitectura gradualmente y adopte PaaS más adelante, cuando la carga de trabajo ya esté en la
nube. La experiencia que ha obtenido le ayudará a adoptar PaaS con mayor rapidez. Tendrá que obtener menos
aptitudes y procesos nuevos para la modernización. Tampoco interrumpirá significativamente sus procesos
empresariales.
Evalúe los recursos digitales según la racionalización de la nube. En este artículo se describen las rutas de
migración y modernización más comunes, o las cinco R:
Rehospedaje
Refactorización
Rediseño
Recompilación
Replace
Antipatrón: arquitectura de reemplazo

Las aplicaciones basadas en PaaS y en software como servicio (SaaS) son relativamente fáciles de mantener.
Normalmente requieren poco trabajo de administración. Como resultado, muchas empresas rediseñan entornos
de arquitectura complejos y antiguos. Para ello, los reemplazan por conceptos nativos de nube y SaaS. Este
cambio de arquitectura normalmente conduce a proyectos de reemplazo importantes. Administrar y ejecutar
estos proyectos es una tarea compleja con unos costos elevados. Cambiar los procesos y el modelo operativo
también implica otros riesgos sustanciales.
Ejemplo: elección del reemplazo frente a la modernización
Una corporación tiene un entorno SAP de gran tamaño. El departamento de TI desea reemplazar este entorno,
que está causando varios problemas de rendimiento y estabilidad. Una vez que TI inicia un proyecto de
reemplazo, la lista de diligencias debida para reemplazar todo el entorno es más larga cada día.
Resultado preferido: racionalización del patrimonio digital
Antes de reemplazar un entorno de aplicaciones grande o complejo, considere la posibilidad de modernizar el
entorno en su lugar para mejorarlo de manera incremental. Los cambios relativamente pequeños en el entorno
de aplicaciones pueden tener un gran impacto en el rendimiento y la confiabilidad. Por ejemplo, el cambio de la
plataforma de hospedaje a Azure puede proporcionar estabilidad y resultados rápidos. En consecuencia, el
rendimiento y la confiabilidad mejoran con una fracción del costo de reemplazo estimado.
A la hora de decidirse por una estrategia de innovación, explore diferentes opciones de modernización. Evalúe
estas opciones en una prueba de concepto (POC).
Comprenda el patrimonio digital de su empresa. Determine cuál de las cinco R de la racionalización funciona
mejor para modernizar o migrar los recursos:
Rehospedaje
Refactorización
Rediseño
Recompilación
Replace
Pasos siguientes
Creación de un plan de preparación de aptitudes
Racionalización de la nube
Asegúrese de que el entorno está preparado para el
plan de adopción de la nube.
Antes de empezar la adopción, debe crear una zona de aterrizaje para hospedar las cargas de trabajo que planea
integrar o migrar a la nube. Esta sección del marco le guía por el proceso de creación de una zona de aterrizaje.
Los ejercicios siguientes le ayudarán a guiar el proceso de creación de una zona de aterrizaje que admita la
Guía de instalación de Azure: Revise la guía de instalación de

Azure para familiarizarse con las herramientas y los enfoques
necesarios para crear una zona de aterrizaje.
Zonas de aterrizaje de Azure: Elija la opción de zona de

aterrizaje más adecuada para establecer un punto de partida
basado en código para su entorno.
Expansión de la zona de aterrizaje: Amplíe la primera zona de

aterrizaje para cumplir los requisitos de plataforma del plan
Procedimientos recomendados: Utilice los procedimientos

recomendados para validar las modificaciones de la zona de
aterrizaje, con el fin de garantizar la correcta configuración
de las zonas de aterrizaje actuales y futuras.
Como mínimo, para prepararse para la adopción de la nube, consulte la guía de instalación de Azure.
Introducción a la guía de configuración de Azure
NOTE
Esta guía ofrece un punto de partida inicial para obtener instrucciones de preparación de Cloud Adoption Framework y
también está disponible en Azure Quickstart Center. En la sugerencia del artículo encontrará un vínculo.
Antes de empezar a compilar e implementar soluciones mediante servicios de Azure es preciso preparar el
entorno. En esta guía, se presentan varias características que le ayudarán a organizar los recursos, a controlar
los costos y a proteger y administrar su organización. Para más información, procedimientos recomendados y
consideraciones relacionadas con la preparación del entorno en la nube, consulte la sección de preparación de
Aprenderá a:
Organizar recursos : configure una jerarquía de administración para aplicar de forma coherente el control
de acceso, las directivas y el cumplimiento a grupos de recursos y utilice el etiquetado para realizar el
seguimiento de los recursos relacionados.
Administrar el acceso : utilice el control de acceso basado en rol de Azure para asegurarse de que los
usuarios solo tienen los permisos que realmente necesitan.
Administrar costos y facturación : identifique el tipo de suscripción, comprenda cómo funciona la
facturación y aprenda a controlar los costos.
Planear la gobernanza, seguridad y cumplimiento : aplique y automatice las directivas y la
configuración de seguridad que le ayudarán a seguir los requisitos legales aplicables.
Usar la super visión y los informes : obtenga visibilidad a través de los recursos para buscar y solucionar
problemas, optimizar el rendimiento y obtener información sobre el comportamiento de los clientes.
Mantenerse al día con Azure : realice un seguimiento de las actualizaciones de productos para permitir un
enfoque proactivo de la administración de cambios.
TIP
Para disfrutar de una experiencia interactiva, consulte esta guía en Azure Portal. Vaya al Centro de inicio rápido de Azure
en Azure Portal, seleccione Guía de configuración de Azure y siga las instrucciones paso a paso.
Pasos siguientes:
Organización de los recursos para simplificar cómo se aplica la configuración
Esta guía incluye pasos interactivos que permiten probar las características a medida que se introducen. Para
volver a donde lo dejó, utilice la ruta de navegación para la navegación.
Organización de los recursos de Azure de forma
eficaz
La organización de los recursos basados en la nube es fundamental para proteger, administrar y realizar un
seguimiento de los costos relacionados con las cargas de trabajo. Para organizar los recursos, defina una
jerarquía de grupos de administración, siga una convención de nomenclatura bien considerada y aplique el
etiquetado de recursos.
Jerarquía y grupos de administración de Azure
Estándares de nomenclatura
Etiquetas del recurso
Azure proporciona cuatro niveles de ámbito administración: grupo de administración, suscripciones, grupos de
recursos y recursos. La imagen siguiente muestra la relación de estos niveles.
Ilustración 1: Cómo los cuatro niveles de

ámbitos de administración se relacionan entre sí.
Grupos de administración: estos grupos son contenedores que ayudan a administrar el acceso, las
directivas y el cumplimiento de varias suscripciones. Todas las suscripciones de un grupo de administración
heredan automáticamente las condiciones que se aplican al grupo de administración.
Suscripciones: una suscripción asocia de manera lógica las cuentas de usuario y los recursos creados por
esas cuentas de usuario. Cada suscripción tiene límites o cuotas con respecto a la cantidad de recursos que
se pueden crear y usar. Las organizaciones pueden usar las suscripciones para administrar los costos y los
recursos creados por los usuarios, equipos o proyectos.
Grupos de recursos: Un grupo de recursos es un contenedor lógico en el que se implementan y se
administran recursos de Azure como aplicaciones web, bases de datos y cuentas de almacenamiento.
Recursos: Los recursos son instancias de servicios que se crean como máquinas virtuales, almacenamiento
o bases de datos SQL.
Ámbito de configuración de administración
Puede aplicar la configuración de administración, como las directivas y el control de acceso basado en rol de
Azure, en cualquiera de los niveles de administración. El nivel que seleccione determina el grado de amplitud
con que se aplica la configuración. Los niveles inferiores heredan la configuración de los niveles superiores. Por
ejemplo, al aplicar una directiva a una suscripción, esta directiva se aplica también a todos los grupos de
recursos y a los recursos de la suscripción.
Normalmente, tiene sentido aplicar la configuración crítica en niveles superiores y los requisitos específicos del
proyecto en niveles inferiores. Por ejemplo, quizás quiera asegurarse de que todos los recursos de su
organización se implementan en determinadas regiones. Para hacerlo, aplique una directiva a la suscripción que
especifique las ubicaciones permitidas. Cuando otros usuarios de su organización agreguen nuevos grupos de
recursos y recursos, se aplicarán automáticamente las ubicaciones permitidas. Más información acerca de las
directivas en la sección de gobernanza, seguridad y cumplimiento de esta guía.
Si solo tiene algunas suscripciones, es relativamente sencillo administrarlas de forma independiente. Si el
número de suscripciones que usa aumenta, considere la posibilidad de crear una jerarquía de grupos de
administración para simplificar la administración de las suscripciones y los recursos. Para más información,
consulte Organización y administración de las suscripciones de Azure.
Al planear la estrategia de cumplimiento, trabaje con personas de su organización que desempeñen estos roles:
seguridad y cumplimiento, administración de TI, arquitectura empresarial, redes, finanzas y adquisiciones.
Creación de un nivel de administración
Puede crear un grupo de administración, suscripciones adicionales o grupos de recursos.
Creación de un grupo de administración
Cree un grupo de administración que le ayude a administrar el acceso, las directivas y el cumplimiento de varias
suscripciones.
1. Vaya a Grupos de administración.
2. Seleccione Agregar grupo de administración .
una suscripción
Use suscripciones para administrar los costos y los recursos creados por los usuarios, equipos o proyectos.
1. Vaya a Suscripciones.
2. Seleccione Agregar .
NOTE
Las suscripciones también se pueden crear mediante programación. Para más información, consulte Creación de
suscripciones a Azure Enterprise mediante programación.
Crear un grupo de recursos

Cree un grupo de recursos para contener recursos como aplicaciones web, bases de datos y cuentas de
almacenamiento que comparten el mismo ciclo de vida, permisos y directivas.
1. Vaya a Grupos de recursos.
3. Seleccione la suscripción en la que desea que se cree el grupo de recursos.
4. Escriba un nombre para el grupo de recursos .
5. Seleccione una región como ubicación del grupo de recursos.
Más información
Para obtener más información, consulte:
Aspectos básicos de Azure
Creación de las suscripciones iniciales
Creación de suscripciones adicionales para escalar el entorno de Azure
Organización y administración de las suscripciones de Azure
Organización de los recursos con grupos de administración de Azure
Descripción de la administración del acceso a los recursos en Azure
Límites del servicio de suscripción
Acciones
Crear un grupo de administración:
Cree un grupo de administración que le ayude a administrar el acceso, las directivas y el cumplimiento de varias
suscripciones.
1. Vaya a Grupos de administración .
2. Seleccione Agregar grupo de administración .
G O TO M A N A G E M E N T
G R O U PS
Crear una suscripción adicional:

Use suscripciones para administrar los costos y los recursos creados por los usuarios, equipos o proyectos.
1. Vaya a Suscripciones .
G O TO
S U B S C R I P TI O N S
Crear un grupo de recursos:

Cree un grupo de recursos para contener recursos como aplicaciones web, bases de datos y cuentas de
almacenamiento que comparten el mismo ciclo de vida, permisos y directivas.
1. Vaya a Grupos de recursos .
3. Seleccione la suscripción en la que desea que se cree el grupo de recursos.
4. Escriba un nombre para el grupo de recursos .
5. Seleccione una región como ubicación del grupo de recursos.
C R E ATE A R E S O U R C E
GROUP
Administración del acceso al entorno de Azure con
el control de acceso basado en rol de Azure
Administrar quién puede acceder a los recursos y suscripciones de Azure constituye una parte importante de la
estrategia de gobernanza de Azure, y asignar privilegios y derechos de acceso basados en grupos es una buena
práctica. Lidiar con grupos en lugar de con usuarios individuales simplifica el mantenimiento de las directivas de
acceso, proporciona la administración de acceso coherente entre equipos y reduce los errores de configuración.
El control de acceso basado en rol de Azure (RBAC de Azure) es el principal método para administrar el acceso
en Azure.
RBAC de Azure ofrece una administración de acceso detallada para los recursos de Azure. Ayuda a administrar
quién tiene acceso a los recursos de Azure, qué pueden hacer con esos recursos y a qué ámbitos pueden
acceder.
Al planear su estrategia de control de acceso, conceda a los usuarios los privilegios mínimos necesarios para
que realicen su trabajo. La siguiente imagen muestra un patrón sugerido para la asignación de RBAC de Azure.
Figura 1: roles de
Azure.
Al planear la metodología de control de acceso, le recomendamos que trabaje con personas de las
organizaciones que desempeñen los roles siguientes: seguridad y cumplimiento, administración de TI y
arquitecto empresarial.
Cloud Adoption Framework ofrece instrucciones adicionales sobre cómo usar el control de acceso basado en rol
de Azure como parte de sus trabajos de adopción de la nube.
Acciones
Concesión de acceso al grupo de recursos:
Para otorgar a un usuario acceso a un grupo de recursos:
1. Vaya a Grupos de recursos .
2. Seleccione un grupo de recursos.
3. Seleccione Access Control (IAM) .
4. Seleccione Agregar > Agregar asignación de roles .
5. Seleccione un rol y, después, asigne acceso a un usuario, grupo o entidad de servicio.
G O TO R E S O U R C E
G R O U PS
Concesión de acceso a la suscripción:

Para otorgar a un usuario acceso a una suscripción:
1. Vaya a Suscripciones .
2. Seleccione una suscripción.
G O TO
Concesión de acceso al grupo de recursos

Para otorgar a un usuario acceso a un grupo de recursos:
1. Vaya a Grupos de recursos.
2. Seleccione un grupo de recursos.
Concesión de acceso a la suscripción

Para otorgar a un usuario acceso a una suscripción:
1. Vaya a Suscripciones.
2. Seleccione una suscripción.
Más información
¿Qué es el control de acceso basado en rol de Azure (RBAC)?
Plataforma de adopción de la nube: uso del control de acceso basado en rol de Azure
Administración de costos y facturación de los
recursos de Azure
La administración de costos es el proceso en el que se planifican y controlan eficazmente los costos implicados
en su negocio. Normalmente, los equipos de finanzas, administración y aplicación realizan las tareas de
administración de costos. Azure Cost Management + Billing puede ayudarle con el planeamiento sin perder de
vista los costos. También le ayuda a analizar eficazmente los costos y a tomar medidas para optimizar el gasto
en la nube.
Para más información sobre cómo integrar los procesos de administración de costos en la nube en toda la
organización, consulte el artículo de Cloud Adoption Framework sobre cómo realizar un seguimiento de los
costos entre unidades de negocio, entornos o proyectos.
Administración de los costos con Azure Cost Management + Billing

Azure Cost Management + Billing ofrecen varias maneras de ayudarle a predecir y administrar los costos:
El análisis de los costos de la nube le permite explorar y analizar los costos. Puede ver el costo agregado
de su cuenta o ver los costos acumulados a lo largo del tiempo.
Super visión mediante presupuestos le permite crear un presupuesto y, posteriormente, configurar
alertas que le avisen cuando esté próximo a superarlo.
Optimización con recomendaciones le ayuda a identificar los recursos inactivos e infrautilizados para
poder tomar medidas para reducir los gastos innecesarios.
Administración de facturas y pagos le ofrece visibilidad sobre su inversión en la nube.
Predicción y administración de costos
1. Vaya a Administración de costos + facturación.
2. Seleccione Cost Management .
3. Explore las características que ayudan a analizar y optimizar los costos en la nube.
Administración de facturas y métodos de pago
1. Vaya a Administración de costos + facturación.
2. Seleccione Facturas o Métodos de pago en la sección Facturación en el panel izquierdo.
Soporte técnico sobre facturación y suscripciones

Se ofrece un acceso ininterrumpido todos los días al soporte técnico sobre facturación y suscripciones para los
clientes de Azure. Si necesita ayuda para entender el uso de Azure, cree una solicitud de soporte técnico.
Crear una solicitud de soporte
Para enviar una solicitud de soporte técnico:
1. Vaya a Ayuda y soporte técnico.
2. Seleccione Nueva solicitud de sopor te técnico .
Ver una solicitud de soporte técnico
Para ver las solicitudes de soporte técnico y su estado:
1. Vaya a Ayuda y soporte técnico.
2. Seleccione Todas las solicitudes de sopor te técnico .
Más información
Documentación sobre Administración de costos + facturación
Plataforma de adopción de la nube: Seguimiento de los costos en unidades de negocio, entornos o proyectos
Plataforma de adopción de la nube: Materia de administración de costos
Acciones
Predicción y administración de costos:
1. Vaya a Administración de costos + facturación .
2. Seleccione Cost Management .
Administración de facturas y métodos de pago:
1. Vaya a Administración de costos + facturación .
2. Seleccione Facturas o Métodos de pago en la sección Facturación en el panel izquierdo.
G O TO C O S T M A N A G E M E N T +
B ILLING
Sopor te técnico para facturación y suscripciones:

Se ofrece un acceso ininterrumpido todos los días al soporte técnico sobre facturación y suscripciones para los
clientes de Azure. Si necesita ayuda para entender el uso de Azure, cree una solicitud de soporte técnico.
Creación de una solicitud de sopor te técnico:
Para enviar una solicitud de soporte técnico:
1. Vaya a Ayuda y sopor te técnico .
2. Seleccione Nueva solicitud de sopor te técnico .
Visualización de una solicitud de sopor te técnico: Para ver las solicitudes de soporte técnico y su estado:
1. Vaya a Ayuda y sopor te técnico .
2. Seleccione Todas las solicitudes de sopor te técnico .
G O TO H E L P +
SU PPO R T
Gobernanza, seguridad y cumplimiento en Azure
A medida que se establece la directiva corporativa y se planean las estrategias de gobierno, se pueden usar
herramientas y servicios como Azure Policy, Azure Blueprints y Azure Security Center para aplicar y automatizar
las decisiones de gobierno de su organización. Antes de empezar a planear la gobernanza, use la herramienta de
banco de pruebas comparativas de gobernanza para identificar posibles brechas en el enfoque de gobernanza
de la nube de su organización. Para más información sobre el desarrollo de procesos de gobernanza, consulte la
metodología de gobernanza.
Azure Blueprints
Azure Policy
Azure Security Center
Azure Blueprints permite a los arquitectos de nube y grupos de TI central definir un conjunto repetible de
recursos de Azure que implementa y cumple los estándares, patrones y requisitos de la organización. Azure
Blueprints permite a los equipos de desarrollo aprovisionar y crear rápidamente nuevos entornos sabiendo que
se crean cumpliendo los estándares organizativos y que contienen un conjunto de componentes integrados,
como las redes, para acelerar el desarrollo y la entrega.
Los planos técnicos son una manera declarativa de organizar la implementación de varias plantillas de recursos
y de otros artefactos, como son:
Asignaciones de roles.
Asignaciones de directivas.
Grupos de recursos.
Creación de un plano técnico
Para crear un plano técnico, realice el siguiente procedimiento:
1. Vaya a Planos técnicos: Introducción .
2. En la sección Crear un plano técnico , seleccione Crear .
3. Filtre la lista Planos técnicos para seleccionar el plano técnico adecuado.
4. Escriba el Nombre del plano técnico y, a continuación, seleccione la Ubicación de definición adecuada.
5. Seleccione Siguiente: Ar tefactos , después revise los artefactos incluidos en el plano técnico.
6. Seleccione Guardar borrador .
C R E ATE A
B LU E PR INT
1. En Azure Portal, vaya a Instancias de Blueprint: Introducción.

2. En la sección Crear un plano técnico , seleccione Crear .
4. Escriba el Nombre del plano técnico y, a continuación, seleccione la Ubicación de definición adecuada.
5. Seleccione Siguiente: Ar tefactos , después revise los artefactos incluidos en el plano técnico.
Publicación de un plano técnico
Para publicar artefactos de un plano técnico en su suscripción:
1. Vaya a Planos técnicos: Definiciones del plano técnico .
2. Seleccione el plano técnico que creó en los pasos anteriores.
3. Revise la definición del plano técnico y, a continuación, seleccione Publicar plano técnico .
4. Proporcione una versión (por ejemplo, 1.0 ) y notas de cambios y, después, seleccione Publicar .
B LU E PR INT
D E F I N I TI O N S
1. En Azure Portal, vaya a Instancias de Blueprint: Definiciones del plano técnico.

2. Seleccione la definición del plano técnico que creó en los pasos anteriores.
4. Proporcione una versión (por ejemplo, 1.0 ) y notas de cambios y, después, seleccione Publicar .
Más información
Azure Blueprints
Plataforma de adopción de la nube: Guía de decisiones de la coherencia de recursos
Ejemplos de planos técnicos basados en estándares
Supervisión e informes en Azure
Azure proporciona muchos servicios que ofrecen una solución completa para recopilar, analizar y actuar en la
telemetría de la aplicación y los recursos de Azure que las admiten. Además, estos recursos se pueden ampliar
para que incluyan la supervisión de recursos locales críticos para proporcionar un entorno de supervisión
híbrido.
Azure Monitor
Azure Service Health
Azure Advisor
Azure Monitor proporciona un único centro unificado para todos los datos de supervisión y diagnóstico en
Azure. Puede usarlo para obtener visibilidad sobre los recursos. Con Azure Monitor, puede buscar y corregir
problemas y optimizar el rendimiento. También puede comprender el comportamiento de los clientes.
Super vise y visualice las métricas: las métricas son valores numéricos que están disponibles en los
recursos de Azure que le ayudan a comprender el estado de los sistemas. Personalice los gráficos de los
paneles y use los libros para los informes.
Consulte y analice los registros: los registros incluyen los registros de actividad y los registros de
diagnóstico de Azure. Recopile registros adicionales de otras soluciones de supervisión y administración
para los recursos de nube o locales. Log Analytics proporciona un repositorio central para agregar todos
estos datos. Desde allí, puede ejecutar consultas para ayudar a solucionar problemas o para visualizar los
datos.
Configure aler tas y acciones: las alertas le notifican proactivamente de las condiciones críticas. Las
acciones correctivas se pueden tomar basándose en los desencadenadores de las métricas, los registros o
los problemas de estado del servicio. Puede configurar diferentes notificaciones y acciones, y enviar
datos a las herramientas de administración de servicios de TI.
Comience a supervisar lo siguiente:
Aplicaciones
Contenedores
Máquinas virtuales
Redes
Para supervisar otros recursos, busque soluciones adicionales en Azure Marketplace.
Para explorar Azure Monitor, vaya a Azure Portal.
Más información
Para más información, consulte Documentación sobre Azure Monitor.
Acción
E XP L O R E A Z U R E
M O N I TO R
Mantenerse al día con Azure
Las plataformas en la nube como Azure cambian a más velocidad de lo que muchas organizaciones están
acostumbradas. Esto significa que las organizaciones tienen que adaptar las personas y los procesos a una
nueva cadencia. Si es responsable de ayudar a su organización a mantenerse al día con el cambio, puede que, en
ocasiones, se sienta abrumado. Los recursos enumerados en esta sección pueden ayudarle a mantenerse al día.
Principales recursos
Los recursos siguientes pueden ayudarle a mantenerse al día con Azure:

Azure Ser vice Health: Las alertas de Service Health proporcionan notificaciones oportunas sobre los
problemas del servicio en curso, el mantenimiento planeado y los avisos de estado. Estas alertas también
incluyen información sobre las características de Azure cuya retirada ya está programada.
Actualizaciones de Azure: examine la actualizaciones de Azure para ver anuncios sobre actualizaciones de
productos. Los resúmenes breves están vinculados a detalles adicionales, lo que hace que las actualizaciones
sean fáciles de seguir. Suscríbase a través de la fuente RSS de actualizaciones de Azure.
Blog de Azure: en el blog de Azure se comunican los anuncios más importantes de la plataforma Azure.
Siga este blog para mantenerse al día con la información más importante. Suscríbase a través de la fuente
RSS del blog de Azure.
Blogs específicos de los distintos ser vicios: muchos de los servicios de Azure individuales publican
blogs que se pueden seguir si se usan esos servicios. Encuentre los que le interesen mediante una búsqueda
web.
Azure Info Hub: Azure Info Hub no es oficial, pero ahí se pueden encontrar la mayoría de los recursos
enumerados aquí. Siga los vínculos a servicios individuales para obtener información detallada y buscar
blogs específicos de servicios. Suscríbase a través de la fuente RSS de Azure Info Hub. *
Descripción de los modelos operativos en la nube
La adopción de la nube permite revisar cómo se utilizan los sistemas tecnológicos. En esta serie de artículos se
clarificarán los modelos operativos en la nube y las consideraciones que afectan a la estrategia de adopción de
la nube. Pero en primer lugar, vamos a aclarar el término modelo operativo en la nube.
Definición de un modelo operativo

Antes de implementar una arquitectura en la nube, es importante saber cómo se desea trabajar en la nube. El
conocimiento de la dirección estratégica, la organización de personas y las necesidades de gobierno, riesgo y
cumplimiento (GRC) ayuda a definir el modelo operativo en la nube para el futuro. Después, las zonas de
aterrizaje de Azure pueden aportar varias de opciones de arquitectura e implementación que den soporte al
modelo operativo. En los siguientes artículos se compartirán algunos términos básicos y se proporcionarán
ejemplos de modelos operativos comunes basados en experiencias de clientes reales. Ambos elementos, en
conjunto, pueden ayudarle a tomar la decisión sobre cuál es la zona de aterrizaje de Azure más adecuada para
implementar.
¿Qué es un modelo de funcionamiento?

Antes de que existieran las tecnologías en la nube, los equipos tecnológicos establecían modelos operativos
para definir la forma en que la tecnología iba a dar soporte a la empresa. El modelo operativo de TI de cualquier
empresa tiene varios factores, pero unos pocos son comunes a todas las empresas: la alineación con la
estrategia empresarial, la organización de las personas, la administración de cambios (o los procesos de
adopción), la administración de las operaciones, la gobernanza/cumplimiento y la seguridad. Todos estos
factores son esenciales para las operaciones tecnológicas a largo plazo.
Cuando las operaciones tecnológicas se desplazan a la nube, estos procesos vitales siguen siendo pertinentes,
pero es probable que sufran cierto cambio. Los actuales modelos operativos se centran considerablemente en
recursos físicos que se encuentran en ubicaciones físicas que se financias en gran medida a través de ciclos de
inversiones en bienes de capital. Estos recursos se usan para dar soporte a las cargas de trabajo que la empresa
necesita para mantener las operaciones empresariales. La misión de la mayoría de los modelos operativos es
dar prioridad a la estabilidad de las cargas de trabajo, para lo que invierte en la estabilidad de los recursos
físicos subyacentes.
¿En qué se diferencian los modelos operativos en la nube?

La redundancia en la pila de hardware es un ciclo interminable. El hardware físico se avería. El rendimiento
empeora. La degradación del hardware rara vez se alinea con los ciclos presupuestarios predecibles de los ciclos
de planificación de inversiones en bienes de capital de una organización. El funcionamiento en la nube rompe la
rutina de las actualizaciones de hardware y las revisiones a medianoche, ya que desplaza el foco hacia arriba, a
los recursos digitales: sistemas operativos, aplicaciones y datos. Este desplazamiento de lo físico a lo digital
también desplaza el modelo operativo de la tecnología.
Aunque el modelo operativo se desplace a la nube, sigue necesitando las mismas personas y procesos, pero
también se centra en un nivel más alto de operaciones. Si los usuarios dejan de centrarse en el tiempo de
actividad del servidor, sus métricas de éxito cambiarán. Si la seguridad deja de estar protegida por las cuatro
paredes de un centro de datos, el perfil de amenazas cambia. Cuando las adquisiciones dejan de ser un
elemento que bloquea la innovación, el ritmo al que se administran los cambios también cambia.
Un modelo operativo en la nube es la colección de procesos y procedimientos que definen cómo se desea
trabajar con la tecnología en la nube.
Objetivo de un modelo operativo en la nube

Cuando el hardware deja de ser la unidad de operaciones más común, el foco se desplaza hacia los recursos
digitales y las cargas de trabajo que admiten. Como tal, el fin del modelo operativo se desplaza de mantener lo
más básico a garantizar unas operaciones de forma consistente.
El Marco de buena arquitectura de Microsoft Azure realiza un gran trabajo, descomponer las consideraciones de
la carga de trabajo en un conjunto de principios arquitectónicos comunes: optimización de costos, excelencia
operativa, eficiencia de rendimiento, confiabilidad y seguridad.
Al pasar a un nivel superior de operaciones, estos principios arquitectónicos comunes ayudan a reformular el
propósito del modelo operativo en la nube. ¿Cómo nos aseguramos de que todos los recursos y las cargas de
trabajo de la cartera equilibran estos principios arquitectónicos? ¿Qué procesos se necesitan para escalar la
aplicación de esos principios?
Vuelva a pensar en su modelo operativo

Si ha actualizado el modelo operativo para quitar todas las referencias a la adquisición, cambio, operaciones o
protección de los recursos físicos, ¿qué queda? En algunas organizaciones, su modelo operativo ahora una hoja
en blanco. En la mayoría de las organizaciones, las restricciones que se han desarrollado a lo largo de los años
se están reduciendo. En cualquier caso, siempre existe la posibilidad de pensar en cómo le gustaría trabajar en la
nube.
Para ayudarle a imaginar su futuro modelo operativo, en estos artículos se tratan los siguientes temas:
Definición de un modelo operativo en la nube
Implementación de un modelo operativo con zonas de aterrizaje de Azure
Pasos siguientes
Obtenga información sobre cómo la forma en que Cloud Adoption Framework ayuda a definir un modelo
operativo.
Definición del modelo operativo de la nube
Los modelos operativos de la nube son complejos. Hay pequeños detalles que pueden bloquear a numerosos
clientes durante la definición del modelo operativo de la nube. Es fácil entrar en una serie de referencias
circulares. Para evitar esto, Cloud Adoption Framework proporciona una serie de metodologías
complementarias e incrementales que descomponen el conjunto de decisiones en ejercicios más pequeños.
Alineación con Cloud Adoption Framework

Para ayudarle a definir el modelo operativo de la nube para su empresa, Cloud Adoption Framework divide cada
aspecto del modelo operativo en metodologías. Cada metodología y los ejercicios prácticos asociados están
diseñados para ayudarle a definir las operaciones de estado futuras.
Soporte técnico para desarrollar el modelo operativo

Las siguientes áreas de Cloud Adoption Framework son metodologías incrementales diseñadas para hacer
crecer las áreas del modelo operativo.
Administración: Adapta los procesos en curso para la administración operativa de la tecnología para
maximizar la obtención de valor y la reducción al mínimo de las interrupciones.
Control: Garantiza la coherencia entre los esfuerzos de adopción. Se adapta a los requisitos de gobernanza o
cumplimiento para mantener un entorno entre nubes.
Estrategia de seguridad: ayuda para definir la estrategia de seguridad general.
Organizar: indica las funciones necesarias en la nube. También define maneras de organizar las personas y
alinear las responsabilidades.
Salida colectiva del modelo operativo
Su entorno debe representar cómo desea trabajar. A medida que se define el modelo operativo, la preparación
del entorno debe coincidir con las operaciones, la gobernanza, la seguridad y los requisitos de la organización.
Listo: las zonas de aterrizaje de Azure proporcionan instrucciones de implementación e implementaciones de
referencia para tomar decisiones sobre el modelo operativo en forma de configuración del entorno.
NOTE
La metodología de preparación proporciona varias opciones de implementación en las zonas de aterrizaje de Azure:
Inicio a pequeña escala y expansión: opción diseñada para crear su plataforma en la nube a medida que define
cada aspecto del modelo operativo.
Escala empresarial: cree una arquitectura preparada para la empresa basada en un conjunto de decisiones definidas
del modelo operativo.
Dependencias y entradas de las decisiones sobre el modelo operativo

La estrategia empresarial y los planes de adopción de la nube colectivos son entradas que deben tenerse en
cuenta a la hora de definir el modelo operativo.
Estrategia: instrucciones para obtener estrategias empresariales y asignarlas a los esfuerzos que se pueden
habilitar mediante una estrategia de adopción de la nube.
Planeamiento: instrucciones de administración de cambios basadas en Agile para establecer trabajos
pendientes y alinear el cambio continuo.
Pasos siguientes
Antes de emplear cualquiera de las metodologías anteriores, use el siguiente artículo para comparar los
modelos operativos de nube comunes y encontrar un modelo que se ajuste a sus requisitos. Este artículo le
ayudará a establecer el punto de partida y el conjunto de ejercicios más práctico que le lleve al modelo
operativo deseado en su plataforma en la nube.
Comparación de los modelos operativos en la nube
más habituales
Los modelos operativos son exclusivos y específicos de la empresa para la que se crean, y se basan en los
requisitos y las restricciones actuales. Sin embargo, esta exclusividad no debe sugerir que los modelos
operativos son como copos de nieve. Existen algunos patrones comunes en los modelos operativos de los
clientes. En este artículo se describen los cuatro patrones más habituales.
Comparación de modelos operativos

En la imagen siguiente se asignan modelos operativos comunes según el rango de complejidad, desde el menos
complejo (descentralizado) al más complejo (operaciones globales). En las tablas siguientes se comparan los
mismos modelos operativos en función del valor relativo de algunos otros atributos.
Prioridades o ámbito
Un modelo operativo en la nube se rige principalmente por dos factores:
Prioridades y motivaciones estratégicas.
El ámbito de la cartera que se va a administrar.
O P ERA C IO N ES O P ERA C IO N ES O P ERA C IO N ES O P ERA C IO N ES

DESC EN T RA L IZ A DA S C EN T RA L IZ A DA S EM P RESA RIA L ES DIST RIB UIDA S
Prioridad Innovación Control Democratización Integración

estratégica
Ámbito de la Carga de trabajo Zona de aterrizaje Plataforma de nube Cartera completa

car tera
Entorno de la Gran complejidad Baja complejidad Complejidad Complejidad

carga de trabajo intermedia intermedia o variable
Zona de aterrizaje N/D Gran complejidad Complejidad Baja complejidad

intermedia a baja
Utilidades N/D N/D o escaso Centralizado y con Respaldo máximo

fundamentales respaldo mayor respaldo
Fundamentos de N/D N/D Fundamentos Distribuidos y

nube híbridos, específicos sincronizados
del proveedor o
regionales
Prioridades o motivaciones estratégicas: Cada uno de los modelos operativos puede ofrecer las
motivaciones estratégicas típicas para la adopción de la nube. Sin embargo, algunos modelos operativos
simplifican la comprensión de motivaciones más específicas.
Ámbito de la car tera : La fila del ámbito de la cartera siguiente identifica el ámbito más grande para el
que se ha diseñado un modelo operativo específico. Por ejemplo, las operaciones centralizadas están
diseñadas para un número reducido de zonas de aterrizaje. Pero esa decisión sobre el modelo operativo
podría suponer riesgos operativos para una organización que intenta administrar una cartera grande y
compleja que podría requerir muchas zonas de aterrizaje, o de una complejidad variable en el diseño de
zonas de aterrizaje.
IMPORTANT
La adopción de la nube a menudo desencadena una reflexión sobre el modelo operativo actual y puede dar lugar a un
cambio de uno de los modelos operativos habituales a otro. Pero la adopción de la nube no es el único factor
desencadenante. A medida que las prioridades empresariales y el ámbito de la adopción de la nube cambian la manera en
que es necesario dar soporte técnico a la cartera, puede que se necesiten otros cambios en el modelo operativo que
mejor se adapta. Cuando la junta directiva u otros equipos directivos desarrollan planes empresariales a 5 o 10 años, esos
planes a menudo incluyen un requisito (explícito o implícito) para ajustar el modelo operativo. Aunque estos modelos
comunes son una buena referencia para ayudarle a tomar decisiones, tenga en cuenta que el modelo operativo podría
cambiar, o puede que tenga que personalizar uno de estos modelos para que cumpla con sus requisitos y restricciones.
Asignación de responsabilidades
Aunque muchos equipos y personas son responsables de colaborar en funciones diferentes, cada uno de los
modelos operativos comunes asigna la responsabilidad final de las decisiones y sus resultados a un equipo o a
una persona. Este enfoque afecta al modo en que se financia el modelo operativo y al nivel de colaboración que
se proporciona para cada función.

Alineación Equipo de carga de Estrategia CCoE Variable:

empresarial trabajo centralizada de la ¿Constituyen un
nube amplio equipo de
estrategia de la
nube?
Operaciones de la Equipo de carga de TI central CCoE Basado en el análisis

nube trabajo de la cartera:
consulte Alineación
empresarial y
Compromisos
empresariales
Gobernanza de la Equipo de carga de TI central CCoE Varias capas de

nube trabajo gobernanza
Seguridad en la Equipo de carga de Centro de CCoE + SOC Mixto: consulte

nube trabajo operaciones de Definición de una
seguridad (SOC) estrategia de
seguridad
Automatización de Equipo de carga de TI central o N/D CCoE Basado en el análisis

la nube y DevOps trabajo de la cartera:
consulte Alineación
empresarial y
Compromisos
empresariales
Aceleración de la implementación del modelo operativo en Azure

Como se describe en Definición de un modelo operativo, cada metodología de Cloud Adoption Framework
proporciona una ruta de acceso estructurada para desarrollar de forma iterativa cada aspecto del modelo
operativo. La metodología más adecuada le ayudará a superar los bloqueos que impiden la adopción y que
proceden de las brechas en el modelo operativo de la nube.
Pero hay maneras de acelerar la implementación del modelo operativo, como se indica en la tabla siguiente.

Punto de par tida Marco de buena Zonas de aterrizaje Zonas de aterrizaje Alineación
arquitectura de Azure de Azure: opciones de Azure: CAF a empresarial
(WAF) de inicio a pequeña escala empresarial
escala o de inicio
empresarial
Iteraciones Poner el foco en las La opción de inicio a Como se muestra en Revise las opciones
cargas de trabajo pequeña escala o de las implementaciones de implementación
permite que el inicio empresarial de referencia, las de zonas de aterrizaje
equipo itere dentro requiere una futuras iteraciones se de Azure para
del WAF. iteración adicional en centran normalmente empezar con la
cada metodología, en adiciones de opción que mejor se
pero esto se puede configuración adapte a su base de
hacer a medida que secundarias. referencia de
se consolidan los operaciones. Siga la
esfuerzos de ruta de iteración
adopción en la nube. definida en los
principios de diseño
de esa opción.
Operaciones descentralizadas
Las operaciones siempre son complejas. Al limitar el ámbito de las operaciones a una carga de trabajo o a una
pequeña colección de ellas, se puede controlar esa complejidad. Por ello, las operaciones descentralizadas son el
menos complejo de los modelos operativos comunes. En este tipo de operaciones, hay equipos dedicados de
cargas de trabajo que se encargan de operar de manera independiente todas las cargas de trabajo.
Prioridades: la innovación tiene prioridad sobre el control centralizado o la normalización en varias cargas
de trabajo.
Ventaja única: maximiza la velocidad de innovación otorgando a los equipos de cargas de trabajo y de la
empresa un control total del diseño, la compilación y las operaciones.
Inconveniente único: reducción de la normalización entre cargas de trabajo, ahorros de escalado a través
de servicios compartidos y esfuerzos de cumplimiento centralizados de gobernanza coherente.
Riesgo: este enfoque presenta riesgos cuando se administra una cartera de cargas de trabajo. Dado que es
menos probable que el equipo de cargas de trabajo tenga equipos especializados dedicados a funciones de
TI centralizadas, este modelo operativo se ve como una opción de alto riesgo por parte de algunas
organizaciones, especialmente aquellas compañías que deben seguir los requisitos de cumplimiento de
terceros.
Guía: Las operaciones descentralizadas se limitan a decisiones en el nivel de cargas de trabajo. El marco de
buena arquitectura de Microsoft Azure está diseñado para respaldar las decisiones tomadas dentro de ese
ámbito. Es probable que los procesos y las instrucciones de Cloud Adoption Framework agreguen una
sobrecarga que no es necesaria en el caso de las operaciones descentralizadas.
Ventajas de las operaciones descentralizadas
Administración de costos : el costo de las operaciones se puede asignar fácilmente a una sola unidad de
negocio. las operaciones específicas de la carga de trabajo permiten una mayor optimización de esta.
Responsabilidades: normalmente, esta forma de operaciones depende en gran medida de la
automatización para minimizar la sobrecarga. Las responsabilidades tienden a centrarse en los procesos de
DevOps y las canalizaciones en la administración de versiones. Esto permite unas implementaciones más
rápidas y unos ciclos de comentarios más cortos durante el desarrollo.
Normalización: el código fuente y la canalización de implementación deben usarse para normalizar el
entorno en función de las versiones.
Respaldo a las operaciones: las decisiones que afectan a las operaciones solo se ocupan de las
necesidades de esa carga de trabajo, lo que simplifica las decisiones sobre operaciones. Muchos miembros
de la comunidad de DevOps argumentarían que se trata de la forma más pura de operaciones debido al
ámbito operativo más estricto.
Experiencia: los equipos de DevOps y de desarrollo están más capacitados para este enfoque y
experimentan una menor resistencia a realizar cambios en el mercado.
Diseño de la zona de aterrizaje: no hay ninguna ventaja operativa específica.
Utilidades fundamentales: no hay ninguna ventaja operativa específica.
Separación de obligaciones: no hay ninguna ventaja operativa específica.
Inconvenientes de las operaciones descentralizadas
Administración de costos : los costos empresariales son más difíciles de calcular. La falta de equipos de
gobernanza centralizados dificulta la implementación de controles u optimización de costos uniformes. A
escala, este modelo puede ser costoso, ya que es probable que cada carga de trabajo presente duplicaciones
en los recursos implementados y las asignaciones de personal.
Responsabilidades: la falta de equipos de soporte técnico centralizados significa que el equipo de la carga
de trabajo es totalmente responsable de la gobernanza, seguridad, operaciones y administración de cambios.
Esto es un inconveniente cuando esas tareas no se han automatizado en las canalizaciones de versión y
revisión del código.
Normalización: la estandarización en una cartera de cargas de trabajo puede convertirse en variable e
incoherente.
Respaldo a las operaciones: a menudo se pierden las eficiencias del escalado. Como nuestros
procedimientos recomendados uniformes en varias cargas de trabajo.
Experiencia: los miembros del equipo tienen mayor responsabilidad para tomar decisiones acertadas y
éticas con respecto a las decisiones de gobernanza, seguridad, operaciones y administración de cambios en
el diseño y la configuración de la aplicación. La revisión de la buena arquitectura de Microsoft Azure y el
marco de buena arquitectura de Azure se deben consultar con frecuencia para mejorar la experiencia
requerida.
Diseño de la zona de aterrizaje: las zonas de aterrizaje no son específicas de la carga de trabajo y no se
tienen en cuenta en este enfoque.
Utilidades fundamentales: pocos servicios fundamentales (si los hay) se comparten entre cargas de
trabajo, lo que reduce la eficiencia del escalado.
Separación de obligaciones: unos requisitos más altos de los equipos de DevOps y de desarrollo
aumentan el uso de privilegios elevados de esos equipos. Si se requiere la separación de obligaciones, se
necesitará una gran inversión en la consolidación de DevOps para que funcione con este enfoque.
Operaciones centralizadas
Es posible que los entornos de estado estable no requieran tanta concentración en la arquitectura o en los
requisitos operativos únicos de las cargas de trabajo individuales. Las operaciones centralizadas tienden a ser la
norma para entornos de tecnología que se componen principalmente de cargas de trabajo de estado estable.
Entre los ejemplos de un estado estable de las operaciones se incluyen elementos como aplicaciones
comerciales (COTS) o aplicaciones personalizadas bien establecidas que tengan una cadencia de versiones lenta.
Si la tasa de cambio viene determinada por un ritmo regular de actualizaciones y revisiones (por encima de la
elevada tasa de cambio de la innovación), la centralización de las operaciones constituye un medio eficaz para
administrar la cartera.
Prioridades: se prioriza el control central sobre la innovación. También se prioriza la continuación de los
procesos operativos existentes sobre el cambio cultural a opciones más modernas de operaciones en la
nube.
Ventaja única: la centralización presenta ahorros de escalado, los mejores controles y operaciones
normalizadas. Este enfoque funciona mejor con las configuraciones específicas para las necesidades del
entorno en la nube que integran las operaciones en la nube en las operaciones y procesos ya existentes. Este
enfoque es más ventajoso para los equipos centralizados con una cartera de varios cientos de cargas de
trabajo con requisitos de cumplimiento y complejidad arquitectónica modestos.
Inconveniente único: El escalado para satisfacer las demandas de una gran cartera de cargas de trabajo
puede suponer una tensión significativa sobre un equipo centralizado que toma decisiones operativas para
cargas de trabajo de producción. Si se espera que los recursos técnicos se escalen por encima de 1000 o más
máquinas virtuales, aplicaciones u orígenes de datos en la nube en los próximos 18-24 meses, se debería
considerar la posibilidad de utilizar un modelo empresarial.
Riesgo: este enfoque limita la centralización a un número menor de suscripciones (a menudo una
suscripción de producción). Existe el riesgo de una refactorización significativa más adelante en el recorrido
en la nube que podría interferir con los planes de adopción. En concreto, se debe prestar atención a la
segmentación, los límites del entorno, las herramientas de identidad y otros elementos fundamentales para
evitar tener que rehacer muchas operaciones en el futuro.
Guía: las opciones de implementación de zona de aterrizaje de Azure que se alinean con la velocidad de
desarrollo del modelo "inicio pequeño y expansión" pueden crear un sólido punto de inicio. Se pueden usar
para acelerar los esfuerzos de adopción. Para que se realice correctamente, se deben establecer directivas
claras para guiar los esfuerzos de adopción iniciales con unas tolerancias al riesgo aceptables. Las
metodologías de gobernanza y administración crean procesos que consolidan las operaciones en paralelo.
Estos pasos sirven como etapas intermedias que se deben completar antes de permitir un mayor riesgo a
medida que las operaciones se van consolidando.
Ventajas de las operaciones centralizadas
Administración de costos : la centralización de servicios compartidos en varias cargas de trabajo crea
ahorros de escalado y elimina las tareas duplicadas. Los equipos centrales pueden implementar con mayor
rapidez reducciones de costos mediante el dimensionamiento empresarial y las optimizaciones de escalado.
Responsabilidades: una experiencia y normalización centralizadas probablemente conducirán a una mayor
estabilidad, un mejor rendimiento operativo y un menor riesgo de interrupciones relacionadas con los
cambios. Esto reduce las grandes presiones de aptitudes de los equipos centrados en las cargas de trabajo.
Normalización: en general, la normalización y el costo de las operaciones son más bajos con un modelo
centralizado porque existen menos sistemas o tareas duplicados.
Respaldo a las operaciones: la reducción de la complejidad y la centralización de las operaciones facilita
que los equipos de TI más pequeños puedan respaldar las operaciones.
Experiencia: la centralización de los equipos de soporte técnico permite a expertos de los campos de
seguridad, riesgo, gobernanza y operaciones promover decisiones críticas para la empresa.
Diseño de la zona de aterrizaje: un departamento de TI centralizado tiende a minimizar el número de
zonas de aterrizaje y suscripciones para reducir la complejidad. Los diseños de zona de aterrizaje tienden a
imitar los diseños de los centros de datos anteriores, lo que reduce el tiempo de transición. A medida que
avanza la adopción, los recursos compartidos se pueden trasladar a una suscripción o base de plataforma
independiente.
Utilidades fundamentales: trasladar los diseños existentes del centro de datos a la nube da lugar a unos
servicios fundamentales y compartidos que imitan las herramientas y operaciones del entorno local. Si las
operaciones locales son el modelo operativo principal, eso puede constituir una ventaja (pero tenga en
cuenta las siguientes desventajas). Esto reduce el tiempo de transición, aprovecha los ahorros del escalado y
permite procesos operativos coherentes entre las cargas de trabajo locales y las hospedadas en la nube. Este
enfoque puede reducir la complejidad y el esfuerzo a corto plazo, y permitir que los equipos más pequeños
respalden las operaciones en la nube con curvas de aprendizaje reducidas.
Separación de obligaciones: la separación de obligaciones es clara en las operaciones centralizadas. El
departamento de TI central mantiene el control de los entornos de producción, lo que reduce la necesidad de
tener permisos elevados de otros equipos. Esto reduce el área expuesta a infracciones al reducir el número
de cuentas con privilegios elevados.
Inconvenientes de las operaciones centralizadas
Administración de costos : los equipos centralizados no suelen tener conocimientos suficientes de las
arquitecturas de carga de trabajo para generar optimizaciones de gran impacto en el nivel de cargas de
trabajo. Esto limita el ahorro de costos que puede proceder de operaciones de carga de trabajo bien
ajustadas. Además, la falta de conocimiento de la arquitectura de cargas de trabajo puede provocar que las
optimizaciones de costos centralizadas tengan un impacto directo en el rendimiento, el escalado u otros
pilares de una carga de trabajo bien diseñada. Antes de aplicar cambios de costos que afecten a toda la
empresa a cargas de trabajo de perfil elevado, el equipo de TI central debe realizar y tener en cuenta la
revisión de buena arquitectura de Microsoft Azure.
Responsabilidades: la centralización del soporte técnico y el acceso a la producción supone una mayor
carga operativa sobre un menor número de personas. También impone mayor presión a esas personas para
realizar revisiones más profundas de las cargas de trabajo implementadas con el fin de validar el
cumplimiento de los requisitos de seguridad, gobernanza y cumplimiento detallados.
Normalización: los enfoques de TI centralizados dificultan el escalado de la normalización sin un escalado
lineal del personal del equipo de TI central.
Respaldo a las operaciones: tenga en cuenta los inconvenientes y los riesgos enumerados anteriormente.
Las mayores desventajas de este enfoque están asociadas a un escalado significativo y a tendencias que dan
prioridad a la innovación.
Experiencia: los desarrolladores y los expertos en DevOps corren el riesgo de ser infravalorados o de estar
demasiado limitados en este tipo de entorno.
Diseño de la zona de aterrizaje: los diseños de los centros de datos se basan en las restricciones de los
enfoques anteriores, los cuales no siempre son pertinentes para la nube. Seguir este enfoque reduce las
oportunidades de reconsiderar la segmentación del entorno y aprovechar las oportunidades de innovación.
La falta de segmentación de la zona de aterrizaje también aumenta el posible impacto ante vulneraciones,
aumenta la complejidad de la gobernanza y el cumplimiento, y puede producir bloqueos en la adopción más
adelante en el recorrido hacia la nube. Consulte la sección anterior sobre riesgos.
Utilidades fundamentales: durante la transformación digital, la nube podría convertirse en el modelo
operativo principal. La conservación de herramientas centralizadas creadas para las operaciones locales
reduce las oportunidades de modernizar las operaciones y de generar mayores eficiencias operativas. La
decisión de no modernizar las operaciones en una etapa temprana del proceso de adopción puede
subsanarse mediante la creación de una suscripción a las bases de la plataforma más adelante en el
recorrido de adopción de la nube, pero ese esfuerzo puede ser complejo, costoso y prolongado sin un
planeamiento por anticipado.
Separación de obligaciones: en general, las operaciones centralizadas siguen una de estas dos opciones,
y ambas pueden entorpecer la innovación.
Opción 1: a los equipos que no pertenecen al departamento de TI central se les concede acceso
limitado a los entornos de desarrollo que imitan la producción. Esta opción obstaculiza la
experimentación.
Opción 2: los equipos desarrollan y realizan pruebas en entornos sin soporte técnico. Esta opción
obstaculiza los procesos de implementación y ralentiza las pruebas de integración posteriores a la
implementación.
Operaciones empresariales
Las operaciones empresariales representan el estado de destino sugerido para todas las operaciones en la nube.
Las operaciones empresariales equilibran la necesidad de control e innovación mediante la democratización de
decisiones y responsabilidades. El equipo de TI centralizado se sustituye por un centro de excelencia en la nube
o equipo de CCoE más facilitador, que admite equipos de cargas de trabajo y les hace responsables de las
decisiones, en lugar de controlar o limitar sus acciones. A los equipos de cargas de trabajo se les concede más
poder y más responsabilidad a la hora de impulsar la innovación, dentro de barreras bien definidas.
Prioridades: prioriza la democratización de decisiones técnicas. La democratización de las decisiones
técnicas traslada a los equipos de cargas de trabajo las responsabilidades que tenía anteriormente el
departamento de TI centralizado. Para llevar a cabo este cambio en las prioridades, las decisiones se vuelven
menos dependientes de los procesos de revisión de ejecución humana y más dependientes de los procesos
de revisión, gobernanza y cumplimiento automatizados mediante herramientas nativas de la nube.
Ventaja única: la segmentación de entornos y la separación de obligaciones permiten el equilibrio entre el
control y la innovación. Las operaciones centralizadas pueden mantener este tipo de operaciones para cargas
de trabajo que requieren un aumento del cumplimiento, operaciones de estado estable o que representan
mayores riesgos de seguridad. Por el contrario, este enfoque permite la reducción del control centralizado de
las cargas de trabajo y entornos que requieren una mayor innovación. Dado que las carteras más grandes
tienen más probabilidades de lidiar con el equilibrio entre control e innovación, esta flexibilidad facilita el
escalado a miles de cargas de trabajo con un menor número de problemas operativos.
Inconveniente único: aquello que funcionaba bien en el entorno local podría no funcionar bien en las
operaciones en la nube de la empresa. Este enfoque con respecto a las operaciones requiere cambios en
muchos frentes. Los cambios culturales en el control y la responsabilidad suelen ser el mayor desafío. Los
cambios operativos que implican los cambios culturales llevan tiempo y un compromiso de esfuerzo por
implementar, consolidar y estabilizar. A veces se requieren cambios en la arquitectura en cargas de trabajo
que, por lo demás, son estables. Se requieren cambios en las herramientas para aprovechar y respaldar los
cambios culturales, operativos y de la arquitectura, lo cual podría requerir compromisos para el proveedor
de nube principal. Los esfuerzos de adopción realizados antes de estos cambios podrían requerir un esfuerzo
de reelaboración significativo que va más allá de los esfuerzos típicos de refactorización.
Riesgo: este enfoque requiere el compromiso del equipo directivo con la estrategia de cambio. También
requiere el compromiso de los equipos técnicos para superar las curvas de aprendizaje y proporcionar los
cambios necesarios. La cooperación a largo plazo entre la empresa, el equipo de CCoE o equipo de TI
centralizado, y los equipos de cargas de trabajo es necesaria para ver las ventajas a largo plazo.
Guía: las opciones de implementación de zonas de aterrizaje de Azure definidas como de "escala
empresarial" proporcionan implementaciones de referencia que muestran cómo los cambios técnicos se
generan mediante herramientas nativas de la nube en Azure. El enfoque de escala empresarial guía a los
equipos a través de los cambios operativos y culturales necesarios para sacar el máximo partido a esas
implementaciones. Este mismo enfoque se puede usar para personalizar la arquitectura de referencia a fin de
configurar el entorno para satisfacer su estrategia de adopción y las restricciones de cumplimiento. Una vez
implementada la escala empresarial, se pueden usar las metodologías de gobernanza y administración para
definir procesos y ampliar las funcionalidades operativas y de cumplimiento para que satisfagan sus
necesidades operativas específicas.
Ventajas de las operaciones empresariales
Administración de costos : los equipos centrales actúan en las optimizaciones entre carteras y hacen
responsables a los equipos de cargas de trabajo individuales de una mayor optimización de la carga de
trabajo. Los equipos centrados en cargas de trabajo están capacitados para tomar decisiones y proporcionar
una explicación cuando dichas decisiones tienen un impacto negativo en los costos. Los equipos centrales y
de cargas de trabajo comparten la responsabilidad de las decisiones relacionadas con el costo en el nivel
adecuado.
Responsabilidades: los equipos centrales usan herramientas nativas de la nube para definir, aplicar y
automatizar límites de protección. Los esfuerzos de los equipos de cargas de trabajo se aceleran mediante la
automatización y los procedimientos de CCoE. Posteriormente, los equipos de cargas de trabajo pueden
impulsar la innovación y tomar decisiones dentro de esos límites.
Normalización: Los límites de protección centralizados y los servicios fundamentales crean coherencia
entre todos los entornos, independientemente de la escala.
Respaldo a las operaciones: las cargas de trabajo que requieren el respaldo de operaciones centralizadas
se segmentan en entornos con controles de estado estable. La segmentación y la separación de las
obligaciones permiten a los equipos de cargas de trabajo adoptar la responsabilidad del respaldo operativo
en sus propios entornos dedicados. Las herramientas automatizadas, nativas de la nube, garantizan una base
de referencia mínima de operaciones para todos los entornos con respaldo operativo centralizado para la
oferta de base de referencia.
Experiencia: la centralización de los servicios principales, como la seguridad, el riesgo, la gobernanza y las
operaciones, garantiza una adecuada experiencia centralizada. Unos procesos y límites claros capacitan a
todos los miembros de los equipos de cargas de trabajo para tomar decisiones más específicas que amplían
el impacto de los expertos centralizados sin necesidad de escalar el personal linealmente con la escala
tecnológica.
Diseño de la zona de aterrizaje: El diseño de la zona de aterrizaje replica las necesidades de la cartera,
creando límites claros de seguridad, gobernanza y responsabilidad que son necesarios para manejar cargas
de trabajo en la nube. No es probable que los procedimientos de segmentación se asemejen a las
restricciones creadas por los diseños de los centros de datos anteriores. En las operaciones empresariales, el
diseño de la zona de aterrizaje es menos complejo, lo que permite un escalado más rápido y la reducción de
barreras a la demanda de autoservicio.
Utilidades fundamentales: las utilidades fundamentales se hospedan en suscripciones controladas
centralmente que se conocen como base de la plataforma. Las herramientas centrales se "canalizan" en cada
zona de aterrizaje como servicios auxiliares. La separación de las utilidades fundamentales de las zonas de
aterrizaje maximiza la coherencia, el ahorro de escalado y crea distinciones claras entre las responsabilidades
administradas centralmente y las responsabilidades en el nivel de carga de trabajo.
Separación de obligaciones: la separación clara de las obligaciones entre las utilidades fundamentales y
las zonas de aterrizaje es una de las mayores ventajas de este enfoque para las operaciones. Las
herramientas nativas de la nube y unos procesos sólidos permiten el acceso Just-in-Time y el equilibrio de
control adecuado entre equipos centralizados y equipos de cargas de trabajo, en función de los requisitos de
las zonas de aterrizaje individuales y las cargas de trabajo hospedadas en esos segmentos de las zonas de
aterrizaje.
Inconvenientes de las operaciones empresariales
Administración de costos : los equipos centrales dependen más de los equipos de cargas de trabajo para
realizar cambios de producción en las zonas de aterrizaje. Este cambio genera el riesgo de un posible
rebasamiento del presupuesto y un ajuste adecuado más lento del gasto real. Debe haber procesos de
control de costos, presupuestos claros, controles automatizados y revisiones regulares en vigor para evitar
sorpresas relacionadas con los costos.
Responsabilidades: Las operaciones empresariales requieren mayores requisitos culturales y operativos en
los equipos centrales y de cargas de trabajo para garantizar la claridad en las responsabilidades y la
responsabilidad entre los equipos.
Es menos probable que los procesos de administración de cambios tradicionales o los comités de evaluación
de cambios mantengan el ritmo y el equilibrio necesarios en este modelo operativo. Esos procesos deben
reflejarse en la automatización de procesos y procedimientos para escalar la adopción de la nube de forma
segura.
La falta de compromiso con los cambios se materializará primero en la negociación y la alineación de las
responsabilidades. La incapacidad de alinear los cambios en las responsabilidades es una indicación de que
los modelos operativos de TI centrales podrían ser necesarios durante los esfuerzos de adopción de la nube a
corto plazo.
Normalización: la falta de inversión en límites de protección centralizados o en la automatización genera
riesgos para la normalización que son más difíciles de superar mediante procesos de revisión manuales.
Además, las dependencias operativas entre cargas de trabajo en las zonas de aterrizaje y los servicios
compartidos de la base de la plataforma generan un mayor riesgo para la normalización durante los ciclos
de actualización o de versiones futuras de las utilidades fundamentales. Durante las revisiones de la base de
la plataforma, se necesitan pruebas mejoradas o incluso automatizadas de todas las zonas de aterrizaje
compatibles y las cargas de trabajo que hospedan.
Respaldo a las operaciones: la base de referencia de las operaciones que se proporciona mediante la
automatización y las operaciones centralizadas puede ser suficiente para cargas de trabajo de bajo impacto o
poca importancia. Sin embargo, es probable que se requieran equipos de carga de trabajo u otros formatos
de operaciones dedicadas para las cargas de trabajo complejas o de gran importancia. Esto podría necesitar
un cambio en los presupuestos operativos, el cual a su vez requeriría que las unidades de negocio asignaran
los gastos operativos a esos formatos de operaciones avanzados. Si se requiere que un departamento de TI
central sea el único responsable del costo de las operaciones, las operaciones empresariales serán difíciles de
implementar.
Experiencia: los miembros del equipo de TI central deberán desarrollar conocimientos relativos a la
automatización de los controles centrales que se ofrecían previamente mediante procesos manuales. Esos
equipos también podrían necesitar desarrollar un dominio de los enfoques de infraestructura como código
para definir el entorno, junto con un elevado grado de comprensión de las canalizaciones de ramificación,
combinación e implementación. Como mínimo, un equipo de automatización de la plataforma necesitará
estas aptitudes para dar curso a las decisiones tomadas por los equipos del centro de excelencia de la nube o
los equipos de operaciones centrales. Los equipos de cargas de trabajo deberán desarrollar conocimientos
adicionales relacionados con los controles y los procesos que regirán sus decisiones.
Diseño de la zona de aterrizaje: el diseño de la zona de aterrizaje depende de las utilidades
fundamentales. Para evitar la duplicación del esfuerzo (o errores o conflictos con la gobernanza
automatizada), cada equipo centrado en una carga de trabajo debe comprender qué se puede incluir en el
diseño y qué está prohibido. Los procesos de excepción también se deben factorizar en los diseños de zonas
de aterrizaje para crear flexibilidad.
Utilidades fundamentales: la centralización de las utilidades fundamentales conlleva un tiempo para
considerar las opciones y desarrollar una solución que se escalará para cumplir con diversos planes de
adopción. Esto puede retrasar los esfuerzos de adopción temprana, pero la compensación llegará de la mano
de las aceleraciones a largo plazo y la evitación de bloqueos más adelante en el proceso.
Separación de obligaciones: garantizar una separación clara de las obligaciones requiere procesos de
administración de identidades consolidados. Puede haber un mantenimiento adicional asociado a la
alineación adecuada de usuarios, grupos y actividades de incorporación o de baja. Es probable que se
necesiten nuevos procesos para acomodar el acceso Just-in-Time a través de privilegios elevados.
Operaciones distribuidas
Es posible que el modelo operativo existente esté demasiado instaurado para que toda la organización cambie a
un nuevo modelo operativo. En otros casos, las operaciones globales y los distintos requisitos de cumplimiento
podrían impedir que las unidades de negocio específicas realizaran un cambio. Para esas empresas, podría ser
necesario un enfoque de operaciones de distribución. Este es, con mucho, el enfoque más complejo, ya que
requiere la integración de uno o varios de los modelos operativos mencionados anteriormente.
Aunque es muy poco recomendable, puede que este enfoque operativo sea necesario para algunas
organizaciones que se componen de un conjunto disperso de unidades de negocio dispares. Especialmente
cuando esas unidades de negocio abarcan una base diversa de segmentos de clientes o de operaciones
regionales.
Prioridades: integración de varios modelos operativos existentes.
Estado de transición con especial atención al cambio de toda la organización a uno de los modelos
operativos mencionados anteriormente con el tiempo.
Enfoque operativo a largo plazo cuando la organización es demasiado grande o compleja para alinearse con
un único modelo operativo.
Ventaja única: integración de elementos comunes del modelo operativo de cada unidad de negocio. Crea
un vehículo para agrupar las unidades operativas en una jerarquía y les ayuda a consolidar las operaciones
mediante procesos repetibles coherentes.
Inconveniente único: es difícil mantener la coherencia y la normalización entre varios modelos operativos
durante períodos prolongados. Este enfoque operativo requiere un conocimiento profundo de la cartera y de
cómo funcionan los distintos segmentos de la cartera tecnológica.
Riesgo: la falta de compromiso con un modelo operativo principal podría llevar a confusión entre los
equipos. Este modelo operativo solo se debe usar si no hay ninguna manera de adoptar un único modelo
operativo.
Guía: comience con una revisión exhaustiva de la cartera con el enfoque que se describe en los artículos
sobre alineación empresarial. Tenga cuidado de agrupar la cartera por el modelo de funcionamiento con el
estado deseado (descentralizado, centralizado o empresarial).
Desarrolle una jerarquía de grupos de administración que refleje las agrupaciones del modelo operativo,
seguido de otros patrones organizativos para la región o la unidad de negocio, u otros criterios que asignen
los clústeres de carga de trabajo de los cubos menos comunes a los más comunes.
Evalúe la alineación de las cargas de trabajo con los modelos operativos para encontrar el clúster de modelo
operativo más adecuado con el que empezar. Siga las instrucciones que se asignan a ese modelo operativo
para todas las cargas de trabajo de ese nodo de la jerarquía de grupos de administración.
Use las metodologías de gobernanza y administración para buscar las directivas corporativas comunes y los
procedimientos de administración operativa necesarios en varios puntos de la jerarquía. Aplique las
directivas comunes de Azure para automatizar las directivas corporativas compartidas.
Dado que esas directivas de Azure se prueban con varias implementaciones, intente moverlas más arriba en
la jerarquía del grupo de administración aplicando esas directivas a un mayor número de cargas de trabajo
para encontrar puntos en común y necesidades operativas únicas.
Con el tiempo, este enfoque ayudará a definir un modelo operativo que se puede escalar en los distintos
modelos operativos y que unifica los equipos mediante un conjunto de directivas y procedimientos comunes.
Las ventajas e inconvenientes de este enfoque se han dejado deliberadamente en blanco. Después de completar
la alineación empresarial de su cartera, consulte la sección sobre el modelo operativo predominante más arriba
para más información sobre las ventajas e inconvenientes.
Pasos siguientes
Conozca la terminología asociada a los modelos operativos. La terminología le ayuda a comprender cómo
encaja un modelo operativo en el ámbito mayor del planeamiento corporativo.
Terminología del modelo operativo
Conozca cómo una zona de aterrizaje proporciona el bloque de creación básico de cualquier entorno de
Terminología del modelo operativo
El término modelo operativo tiene muchas definiciones. En este artículo de introducción se define la
terminología asociada a los modelos operativos. Para entender un modelo operativo en relación con la nube,
primero tenemos que comprender cómo encaja un modelo operativo en el ámbito mayor de la planeación
corporativa.
Términos
Modelo de negocio: los modelos de negocio suelen definir el valor corporativo (qué hace el negocio para
proporcionar valor) y la misión o la visión (por qué el negocio ha elegido agregar valor de este modo). Como
mínimo, los modelos de negocio deben ser capaces de representar qué y por qué en forma de proyecciones
financieras. Hay muchas escuelas de pensamiento distintas en lo que respecta a en qué medida un modelo de
negocio va más allá de estos principios básicos de liderazgo. Pero para crear un modelo operativo sólido, los
modelos de negocio deben incluir declaraciones generales para establecer objetivos direccionales. Es aún más
eficaz si esos objetivos se pueden representar mediante métricas o KPI para realizar un seguimiento del
progreso.
Experiencia del cliente: todos los buenos modelos de negocio basan el por qué de la estrategia de una
empresa en la experiencia de sus clientes. Este proceso podría abarcar aquellos clientes que adquieren un
producto o servicio. También podría incluir interacciones entre una empresa y sus clientes empresariales. Otro
ejemplo podría centrarse en la administración a largo plazo de las necesidades financieras o de mantenimiento
de un cliente, en lugar de en una sola transacción o proceso. Independientemente del tipo de experiencia, la
mayoría de las empresas de éxito saben que existen para operar y mejorar las experiencias que impulsan su por
qué.
Transformación digital: La transformación digital se ha convertido en un término de moda en el sector. Sin
embargo, es un componente fundamental en la consecución de modelos empresariales modernos. Desde la
llegada del smartphone y otros factores de forma informáticos portátiles, las experiencias de los clientes se han
vuelto cada vez más digitales. Este cambio es más que obvio en algunos sectores, como el alquiler de DVD, los
medios de impresión, los automóviles o el comercio minorista. En cada caso, las experiencias digitalizadas han
tenido un impacto considerable en la experiencia del cliente. En algunos casos, los medios digitales han
reemplazado por completo a los medios físicos, y están cambiando por completo la vertical del sector. En otros,
las experiencias digitales se consideran un aumento estándar de la experiencia. Para ofrecer valor empresarial
(el qué), la experiencia del cliente (el por qué) debe influir en el impacto de las experiencias digitales en las
experiencias de los clientes. Este proceso es la transformación digital. La transformación digital rara vez supone
todo el por qué en una estrategia empresarial, pero es un aspecto importante.
Modelo operativo: si el modelo empresarial representa el qué y el por qué, un modelo operativo representa
cómo y quién pone en marcha la estrategia empresarial. El modelo operativo define las formas en que las
personas colaboran para lograr los grandes objetivos que se describen en la estrategia empresarial. Los
modelos operativos suelen describirse como las personas, los procesos y la tecnología que hay detrás de la
estrategia empresarial. En el artículo sobre el modelo operativo del marco de adopción de la nube, este
concepto se explica en detalle.
Adopción de la nube: Como ya se mencionó antes, la transformación digital es un aspecto importante de la
experiencia del cliente y del modelo empresarial. Del mismo modo, la adopción de la nube es un aspecto
importante de cualquier modelo operativo. La adopción de la nube es un habilitador sólido para ofrecer las
tecnologías y los procesos adecuados necesarios para implantar correctamente el modelo operativo moderno.
La adopción de la nube es lo que hacemos para obtener el valor empresarial. El modelo operativo describe
quiénes somos y cómo funcionamos cada día mientras se proporciona la adopción de la nube.
Realizar acción
Aprovechar el modelo operativo proporcionado por Cloud Adoption Framework para desarrollar la madurez
operativa.
Pasos siguientes
Avance a la siguiente sección de Cloud Adoption Framework. Conozca cómo una zona de aterrizaje proporciona
el bloque de creación básico de cualquier entorno de adopción de la nube.
Aprovechar el modelo operativo
¿Qué es una zona de aterrizaje de Azure?
Las zonas de aterrizaje de Azure son la salida de un entorno de Azure con varias suscripciones que tiene en
cuenta la escala, seguridad, gobernanza, redes e identidad. Las zonas de aterrizaje de Azure permiten la
migración, modernización e innovación de aplicaciones a escala empresarial en Azure. Estas zonas tienen en
cuenta todos los recursos de la plataforma necesarios para dar soporte a la cartera de aplicaciones del cliente y
no diferencian entre infraestructura como servicio o plataforma como servicio.
Una zona de aterrizaje es un entorno para hospedar cargas de trabajo que se aprovisionan previamente
mediante código. Vea el siguiente vídeo para obtener más información.
Escalable y modular
No hay ninguna que sirva para todos los entornos técnicos. Hay varias opciones de implementación de la zona
de aterrizaje de Azure que pueden ayudarle a satisfacer las necesidades de implementación y operaciones de su
creciente cartera en la nube.
Escalable: todas las zonas de aterrizaje de Azure admiten la adopción de la nube a escala proporcionando
entornos repetibles, con una configuración y controles coherentes, independientemente de las cargas de
trabajo o los recursos de Azure implementados en cada instancia de zona de aterrizaje.
Modular : todas las zonas de aterrizaje de Azure proporcionan un enfoque modular para crear un entorno
basado en un conjunto común de áreas de diseño. Cada área de diseño se puede ampliar fácilmente para
admitir las distintas necesidades de varias plataformas tecnológicas, como SQL, AKS, WVD, etc.
Tanto si desea implementar su primera aplicación de producción en Azure como si va a manejar una compleja
cartera de plataformas tecnológicas y cargas de trabajo, las opciones de implementación de la zona de aterrizaje
de Azure se pueden adaptar a sus necesidades.
Pasos siguientes
Antes de elegir la opción de implementación de zona de aterrizaje de Azure adecuada, debe conocer las áreas de
diseño de la zona de aterrizaje de Azure.
Examen de las áreas de diseño
Áreas de diseño de las zonas de aterrizaje de Azure
Cada opción de implementación de zona de aterrizaje de Azure proporciona un enfoque de implementación y

principios de diseño definidos. Antes de elegir una opción de implementación, use este artículo para
comprender las áreas de diseño que se enumeran en la tabla siguiente.
NOTE
Estas áreas de diseño describen lo que debe tener en cuenta antes de implementar una zona de aterrizaje. Úselo como
referencia. Consulte las opciones de implementación de zonas de aterrizaje para conocer los principios de diseño y los
pasos procesables para la implementación.
Área de diseño
Independientemente de la opción de implementación, debe considerar detenidamente cada área de diseño. Sus
decisiones afectan a la base de la plataforma de la que depende cada zona de aterrizaje.
Á REA DE DISEÑ O O B JET IVO M ETO DO LO GÍA S REL EVA N T ES
Inscripciones de la empresa En el caso de los clientes empresariales Ready

con un compromiso de Azure, la
creación e inscripción de inquilinos
adecuadas es un paso importante.
Identidad La administración de identidades y Ready

acceso es un límite de seguridad
principal en la nube pública. Es la base
de cualquier arquitectura segura y
totalmente compatible.
Topología de red y conectividad Las redes y las decisiones de Ready

conectividad son un aspecto
fundamental igualmente importante
de cualquier arquitectura en la nube.
Organización de recursos A medida que se escala la adopción de Control

la nube, las opciones a tener en cuenta
sobre el diseño de las suscripciones y
la jerarquía de los grupos de
administración afectarán la
gobernanza, la administración de
operaciones y la adopción de patrones.
Disciplinas de gobernanza Automatice la auditoría y el Control

cumplimiento de las directivas de
seguridad, gobernanza y
cumplimiento.
Á REA DE DISEÑ O O B JET IVO M ETO DO LO GÍA S REL EVA N T ES
Base de referencia de operaciones En el caso de las operaciones continuas Administrar

y en curso en la nube, es necesario
tener una línea base de operaciones
para proporcionar opciones de
visibilidad, cumplimiento de
operaciones y funcionalidades de
protección y recuperación.
Recuperación ante desastres y La resistencia es fundamental para el Administrar

continuidad empresarial (BCDR) funcionamiento sin problemas de las
aplicaciones. BCDR es un componente
importante de la resistencia. BCDR
implica la protección de datos
mediante copias de seguridad y la
protección de las aplicaciones frente a
interrupciones mediante la
recuperación ante desastres.
Opciones de implementación Alinee las mejores herramientas y Ready

plantillas para implementar sus zonas
de aterrizaje y recursos de soporte
técnico.
Pasos siguientes
Puede implementar estas áreas de diseño poco a poco para ir desarrollándose en el modelo operativo en la
nube. Como alternativa, hay opciones de implementación bien fundamentadas y enriquecidas que comienzan
con una posición definida en cada área de diseño.
Una vez que comprenda las áreas de diseño modulares, el paso siguiente consiste en elegir la opción de
implementación de la zona de aterrizaje que mejor se ajuste al plan de adopción de la nube y los requisitos.
Elección de una opción de implementación
Selección de la zona de aterrizaje de la
organización
Existen diferentes enfoques para implementar zonas de aterrizaje en Cloud Adoption Framework. El enfoque
adecuado para la organización tiene los servicios necesarios para admitir sus aplicaciones empresariales sin
suponer una sobrecarga de administración. Partir de una implementación que no satisface sus necesidades
puede resultar una pérdida de tiempo y esfuerzo.
Microsoft ofrece dos opciones de implementación para zonas de aterrizaje:
Escala empresarial
Consulte el siguiente vídeo de 15 minutos para más información sobre cómo elegir las opciones de
implementación de la zona de aterrizaje de Azure que mejor se adapten a sus necesidades.
También puede considerar las implementaciones de terceros. Nuestros asociados disponen de muchas
implementaciones mediante sus servicios. Para obtener más información, consulte Evaluación de la zona de
aterrizaje de Azure de un asociado de Microsoft.
Información general sobre las opciones de la zona de aterrizaje

En la tabla siguiente se resumen las consideraciones para cada enfoque de implementación de zona de
aterrizaje.
Escala empresarial
Consideraciones iniciales
Alineación del modelo operativo
Operaciones centralizadas
Operaciones empresariales
Arquitectura de base de referencia
Ofrece un punto de partida sencillo para crear su propia solución con suscripciones mínimas que puede escalar
según sea necesario.
Ofrece una referencia de inquilino de Azure completa, independientemente del punto de escalado, que incluye
operaciones nativas en la nube.
Consideraciones del plan de adopción
Proporciona autosuficiencia a largo plazo
Requiere metodologías de gobernanza y administración de Cloud Adoption Framework para lograr la
autosuficiencia a largo plazo.
El enfoque y la arquitectura de las zonas de aterrizaje del modelo de escala empresarial preparan la
organización para la autosuficiencia a largo plazo. Proporciona instancias reservadas para empezar.
Habilita la velocidad de adopción en toda la organización
Habilite rápidamente la adopción de bajo riesgo. Desarrolle de forma orientada un proceso de seguridad,
gobernanza y de cumplimiento a largo plazo.
Empiece por la seguridad, la gobernanza y el cumplimiento para habilitar antes una adopción conforme.
Logra excelencia operativa
Requiere metodologías de gobernanza y administración de Cloud Adoption Framework para lograr la excelencia
operativa.
Habilita la excelencia operativa con autonomía para los equipos de la plataforma y la aplicación a partir de la
administración y la gobernanza basadas en directivas.
Consideraciones de cumplimiento normativo
El camino hacia la seguridad, la gobernanza y el cumplimiento
Enfoque iterativo. Requiere metodologías de gobernanza y administración para admitir información confidencial
o cargas de trabajo críticas.
La arquitectura de escala empresarial incluye diseños para la gobernanza, segmentación de seguridad y
separación de tareas. Este enfoque permite a los equipos actuar dentro de las zonas de aterrizaje adecuadas.
Riesgos asociados de la compilación orientada a la seguridad, la gobernanza y el cumplimiento
Existe un riesgo de refactorización extensiva o incluso reimplementación para satisfacer las necesidades
requeridas.
Existe el riesgo de habilitar productos de operaciones nativas en la nube que podrían no estar alineados con el
modelo operativo.
Consideraciones de la implementación
Procedimientos recomendados del proveedor de nube
Es necesario agregar más procedimientos recomendados mediante metodologías de Cloud Adoption
Framework para aplicar la seguridad, la gobernanza y el cumplimiento.
La escala empresarial incluye procedimientos recomendados de Azure y es el estado técnico de destino para el
entorno de Azure.
Todos los servicios críticos están presentes y configurados correctamente de acuerdo con las prácticas
recomendadas para la administración de identidades y acceso, la gobernanza, la seguridad, la red y el registro.
Parcial. Algunos recursos se implementan. Se requieren ofertas adicionales alineadas con las metodologías de
Cloud Adoption Framework para aplicar los procedimientos recomendados para admitir la seguridad, la
gobernanza y el cumplimiento.
La arquitectura de escala empresarial es la recomendación de estado técnico de destino del entorno de Azure
que se alinea con la hoja de ruta de la plataforma Azure.
Funcionalidades de automatización, como infraestructura como código (IaC) y Azure DevOps
Azure Resource Manager, Azure Policy y Azure Blueprints se pueden usar para crear su propia canalización de
integración y desarrollo continuos.
Azure Resource Manager, Azure Policy y GitHub/Azure DevOps. Las opciones de canalización de CI/CD se
incluyen en la guía de implementación de referencia.
Consideraciones sobre la escala de tiempo
Escala de tiempo para adoptar o migrar una carga de trabajo de bajo riesgo:
De 3 a 10 días
De 3 a 10 días
Escala de tiempo para lograr los requisitos de seguridad, gobernanza y cumplimiento de todas las cargas de
trabajo:
De cuatro a seis meses
De seis a ocho semanas
Consideraciones iniciales
¿Qué modelo operativo describe mejor su organización? Tenga en cuenta no solo el aspecto actual de su
organización, sino también lo que espera y quiere que sea en un plazo de entre tres meses y un año o más.
Operaciones centralizadas: En este pequeño entorno, los equipos centralizados para operaciones de TI,
seguridad y otros roles administran la producción y las cargas de trabajo.
Operaciones empresariales: En estos entornos, normalmente más grandes o especializados del sector, las
operaciones empresariales tienen un estado estable y constante que se administra de forma centralizada.
Las operaciones centralizadas favorecen un enfoque de inicio a pequeña escala y expansión. Es posible que las
operaciones empresariales se aborden mejor con una escala empresarial.
¿Necesita un entorno o una arquitectura de base de referencia? El enfoque de inicio a pequeña escala y
expansión ofrece un punto inicial sencillo desde el que crear su propia solución. El enfoque de escala
empresarial proporciona un entorno para todo el inquilino de Azure que incluye operaciones nativas en la nube.
Para obtener más información sobre los tipos de operaciones, consulte Comparación de los modelos operativos
en la nube más habituales.
Consideraciones del plan de adopción

Las consideraciones siguientes son fundamentales para el plan de adopción de cualquier tipo:
Autosuficiencia a largo plazo
Velocidad de adopción en toda la organización
Excelencia operativa
La escala empresarial proporciona excelencia operativa y autosuficiencia a largo plazo inmediatamente. La
escala empresarial también ayuda a acelerar la adopción del cumplimiento en toda la organización. El enfoque
de escala empresarial crea una base para usted. La escala empresarial incluye límites de protección de
seguridad, identidad y red. El enfoque incluye opciones de canalización de CI/CD para DevOps y Automation.
Si empieza a pequeña escala y, a continuación, realiza una expansión, hay formas de lograr autosuficiencia, la
velocidad de adopción y la excelencia operativa. Use las metodologías de gobernanza y administración de Cloud
Adoption Framework para compilar iterativamente estas partes en la solución de la zona de aterrizaje. Use las
ocho áreas de diseño, las instrucciones de diseño de escala empresarial de Cloud Adoption Framework, para
mejorar el diseño de forma iterativa.
Para obtener más información sobre la excelencia operativa, consulte Ofrecer excelencia operativa durante la
transformación digital.
Consideraciones de cumplimiento normativo
Tenga en cuenta los siguientes aspectos sobre el cumplimiento para la organización:
El camino hacia la seguridad, la gobernanza y el cumplimiento
Riesgos de la compilación orientada a la seguridad, la gobernanza y el cumplimiento
Es posible que la organización necesite una carga de trabajo o aplicación determinada que deba ser compatible
en un breve período de tiempo, requisito que podría afectar a su elección.
El inicio a pequeña escala y expansión es un enfoque iterativo hacia el cumplimiento. Use metodologías de
gobernanza y administración de Cloud Adoption Framework para admitir información confidencial o cargas de
trabajo críticas. Para obtener más información, consulte Gobernanza de la metodología para la nube y
Administración de TI y operaciones en la nube.
La arquitectura de escala empresarial incluye diseños para la segmentación y separación para admitir los
objetivos de cumplimiento y un marco de habilitación del servicio para determinar cómo lograr los niveles
adecuados de gobernanza, seguridad y cumplimiento.
Si es posible, identifique las cargas de trabajo de bajo riesgo para implementarlas en primer lugar. Esta técnica le
ayuda a crear una infraestructura y aptitudes con el tiempo. Puede agregar las metodologías de gobernanza y
administración a medida que comprenda cómo funciona la nube.
Consideraciones de la implementación
La implementación de la zona o zonas de aterrizaje plantea varias consideraciones a la hora de elegir una
implementación:
Procedimientos recomendados del proveedor de nube.
Todos los servicios críticos están presentes y configurados correctamente de acuerdo con las prácticas
recomendadas para la administración de identidades y acceso, la gobernanza, la seguridad, la red y el
registro.
Funcionalidades de automatización, como IaC y Azure DevOps.
Ambas implementaciones ofrecen procedimientos recomendados. El inicio a pequeña escala y la expansión
permiten agregar procedimientos recomendados mediante metodologías de Cloud Adoption Framework para
aplicar la seguridad, la gobernanza y el cumplimiento.
La escala empresarial viene con todos los servicios críticos configurados. El inicio a pequeña escala y la
expansión viene con algunos recursos implementados.
Para obtener más información, consulte Procedimientos recomendados de preparación para Azure.
Ambas metodologías ofrecen funcionalidades de automatización.
Inicio a pequeña escala y expansión : plantillas de ARM, Azure Policy y Azure Blueprints. Puede crear su
propia canalización de CI/CD.
Escala empresarial : en la guía de implementación de referencia se incluyen las opciones de plantillas de
ARM, Azure Policy, GitHub/Azure DevOps y la canalización de CI/CD.
El inicio a pequeña escala y expansión usa plantillas de ARM, Azure Policy y Azure Blueprints.
Plano técnico de Fundación CAF
Plano técnico de la zona de aterrizaje de la migración de CAF
La escala empresarial usa plantillas de ARM, Azure Policy y ofrece tres implementaciones de referencia, así como
distintas opciones de implementación.
Base de la escala empresarial
Virtual WAN de escala empresarial
Escala empresarial radial
Tanto si implementa el inicio a pequeña escala y expansión como la escala empresarial, puede usar plantillas y
una experiencia basada en el portal. Puede incluir IaC más adelante en el proceso. Para obtener más
información, explore esta Introducción a IaC.
Consideraciones sobre la escala de tiempo

Las opciones de la zona de aterrizaje tardan diferentes cantidades de tiempo en implementarse. Hay dos tipos
de escalas de tiempo:
Una escala de tiempo para adoptar o migrar una carga de trabajo de bajo riesgo.
Una escala de tiempo para lograr los requisitos de seguridad, gobernanza y cumplimiento de todas las
cargas de trabajo.
Con un enfoque de inicio a pequeña escala y expansión, puede tener una carga de trabajo de bajo riesgo en
funcionamiento en un plazo de entre 3 y 10 días. En el caso de las cargas de trabajo con grandes requisitos de
seguridad, gobernanza y cumplimiento, esto puede tardar entre cuatro y seis meses.
En el caso de una implementación de escala empresarial, puede seguir adoptando una carga de trabajo de bajo
riesgo en un plazo de entre 3 y 10 días, pero las cargas de trabajo más elaboradas pueden estar listas en un
período de entre seis y ocho semanas.
Pasos siguientes
Inicio a escala empresarial
Opciones de implementación de zonas de aterrizaje
Las zonas de aterrizaje de Azure proporcionan a los equipos de adopción de la nube un entorno bien
administrado para sus cargas de trabajo. Siga las instrucciones de las áreas de diseño de la zonas de aterrizaje
para aprovechar estas capacidades.
Las opciones de implementación siguientes están diseñadas para un conjunto específico de dependencias de
modelo operativo cada una y para que sean compatibles con los requisitos no funcionales. Cada opción de
implementación incluye enfoques de automatización distintos. Cuando están disponibles, se incluyen
arquitecturas e implementaciones de referencia para acelerar el recorrido de la adopción de la nube. Aunque
cada opción está asignada a un modelo operativo diferente, comparten las mismas áreas de diseño. La
diferencia es la forma en que decida implementarlas.
Velocidad de desarrollo de la plataforma

Además de las áreas de diseño recomendadas, la velocidad de desarrollo de la plataforma (la rapidez con la que
el equipo de la plataforma puede desarrollar las aptitudes necesarias) es un factor clave a la hora de elegir la
mejor opción de implementación. Considere dos modos principales:
Inicio a escala empresarial: Use este modo si los requisitos empresariales requieren una implementación
inicial enriquecida de zonas de aterrizaje con gobernanza, seguridad y operaciones totalmente integradas desde
el principio. Con este enfoque se puede usar Azure Portal o la infraestructura como código para instalar y
configurar el entorno. También se puede realizar la transición entre Azure portal y la infraestructura como
código (recomendado) cuando la organización está lista. Para usar el enfoque de infraestructura como código
recomendado, la organización necesitará aptitudes en plantillas de Azure Resource Manager y GitHub.
Inicio a pequeña escala y expansión: Use este modo si es más importante desarrollar estas aptitudes y
comprometerse con las decisiones a medida que se aprende más sobre la nube. En este enfoque, las zonas de
aterrizaje solo se centran en la implementación de las consideraciones básicas de las zonas de aterrizaje
necesarias para iniciar la adopción de la nube. Cuando se vaya expandiendo la adopción, los módulos de las
metodologías de gobernanza y administración se basarán en las zonas de aterrizaje iniciales. Los principios de
diseño de cualquier zona de aterrizaje de Azure describen las áreas de diseño específicas que requerirán la
refactorización con el tiempo.
En la siguiente tabla se describen algunas de las opciones de implementación para las zonas de aterrizaje y las
variables que pueden guiar sus decisiones.
P RIN C IP IO S DE
O P C IÓ N DE VELO C IDA D DE DISEÑ O M Á S IN ST RUC C IO N ES DE
IM P L EM EN TA C IÓ N DESC RIP C IÓ N IM P L EM EN TA C IÓ N P RO F UN DO S IM P L EM EN TA C IÓ N
Plano técnico de la Implementa los Empezar por algo Principios de diseño Implementación
zona de aterrizaje de fundamentos básicos pequeño
la migración de CAF para migrar recursos
de bajo riesgo.
P RIN C IP IO S DE
Plano técnico de Agrega las Empezar por algo Principios de diseño Implementación
Fundación CAF herramientas pequeño
mínimas necesarias
para empezar a
desarrollar una
estrategia de
gobernanza.
Zona de aterrizaje de Implementa una base Escala empresarial Principios de diseño Implementación
escala empresarial de de plataforma
CAF (conectividad preparada para la
híbrida con Virtual empresa con todos
WAN) los servicios
compartidos
necesarios para
admitir toda la
cartera de TI, incluida
la conectividad
híbrida (Virtual
WAN).
Zona de aterrizaje de Implementa una base Escala empresarial Principios de diseño Implementación
CAF (conectividad preparada para la
híbrida con topología empresa con todos
de red en estrella los servicios
tipo hub-and-spoke) compartidos
necesarios para
admitir toda la
cartera de TI, incluida
la conectividad
híbrida (tipo hub-
and-spoke).
Zona de aterrizaje a Implementa una base Escala empresarial Principios de diseño Implementación
CAF (base) preparada para la
empresa con todos
los servicios
compartidos
necesarios para
admitir toda la
cartera de TI, en la
que la conectividad
se puede agregar
más tarde según sea
necesario.
P RIN C IP IO S DE
Zona de aterrizaje a Esta implementación Escala empresarial Principios de diseño Implementación

escala empresarial de de referencia está
CAF (pequeña y pensada para
mediana empresa) organizaciones que
no tienen un equipo
de TI de gran tamaño
y no requieren
modelos de
delegación de
administración muy
específicos.
Módulo Terraform Implementa una base Escala empresarial Principios de diseño Implementación
para Cloud Adoption de plataforma
Framework a escala preparada para la
empresarial empresa mediante
Terraform. Use esta
opción cuando
administre la
plataforma mediante
Terraform y necesite
acelerar la entrega de
la jerarquía de
recursos y el modelo
de gobernanza
recomendados. Este
módulo se ha
comprobado
oficialmente en el
registro de Terraform.
Los servicios
compartidos, la
conectividad de red y
las cargas de trabajo
de aplicaciones se
pueden integrar en la
implementación o
administrar de forma
independiente.
Módulos de CAF Ruta de acceso de Empezar por algo Principios de diseño Implementación
Terraform terceros para los pequeño
modelos operativos
de varias nubes. Esta
ruta de acceso puede
limitar los primeros
modelos operativos
de Azure.
P RIN C IP IO S DE
Zonas de aterrizaje Los asociados que Variable Principios de diseño Buscar un asociado
de asociado proporcionan ofertas
que están en línea
con la metodología
de preparación de
Cloud Adoption
Framework pueden
proporcionar su
propia opción de
implementación
personalizada.
En la siguiente tabla se muestran algunas de estas opciones de implementación desde una perspectiva
ligeramente diferente, para orientar procesos de decisiones más técnicas.
O P C IÓ N DE T EC N O LO GÍA DE IN ST RUC C IO N ES DE
IM P L EM EN TA C IÓ N H UB RA DIO IM P L EM EN TA C IÓ N IM P L EM EN TA C IÓ N
Zona de aterrizaje a Se incluye Se incluye Plantillas de Azure Implementación

escala empresarial de Resource Manager,
Cloud Adoption Azure Portal, Azure
Framework Policy y GitHub
Plano técnico de la Se requiere Se incluye Plantillas de Azure Implementación

zona de aterrizaje de refactorización Resource Manager,
la migración de CAF Azure Portal y Azure
Blueprints
Módulos de CAF Incluidos en el Se incluye Terraform Implementación

Terraform módulo del centro de
datos virtual
Módulo Terraform Excluido Excluido Terraform Implementación

para Cloud Adoption
Framework a escala
empresarial
Pasos siguientes
Para continuar, elija una de las opciones de implementación de la tabla anterior. Cada opción incluye un vínculo
a las instrucciones de implementación y los principios de diseño específicos que guían la implementación.
Empiece a utilizar las zonas de aterrizaje de escala
empresarial de Cloud Adoption Framework
La arquitectura de escala empresarial representa la ruta de acceso estratégica de diseño y el estado técnico de
destino de su entorno de Azure. Evolucionará al mismo tiempo que la plataforma Azure y la definirán las
distintas decisiones de diseño que su organización debe tomar para asignar su recorrido en Azure.
No todas las empresas adoptan Azure de la misma manera, por lo que la arquitectura de la zona de aterrizaje de
escala empresarial de Cloud Adoption Framework varía de un cliente a otro. Tanto las consideraciones técnicas
como las recomendaciones de diseño de la arquitectura a escala empresarial pueden aportar diferentes ventajas
en función del escenario de su organización. Puede haber cierta variación, pero si sigue las recomendaciones
principales, la arquitectura de destino resultante colocará a su organización en una ruta de acceso hacia una
escala sostenible.
Guía prescriptiva
La arquitectura a escala empresarial proporciona una guía prescriptiva, junto con los procedimientos
recomendados para su plano de control de Azure. Sigue los principios de diseño en las áreas de diseño críticas
para el entorno de Azure de una organización.
Calificadores: ¿debo empezar con un enfoque de escala empresarial?

La arquitectura a escala empresarial es modular por diseño. Le permite empezar con un plano de control de las
zonas de aterrizaje básicas que dan soporte a sus carteras de aplicaciones, independientemente de que si las
aplicaciones se hayan migrado o acaben de desarrollarse e implementarse en Azure. La arquitectura puede
escalar al mismo tiempo que los requisitos de su empresa, independientemente del punto de la escala.
Empiece a utilizar una zona de aterrizaje a escala empresarial de

Cloud Adoption Framework
El enfoque de escala empresarial para crear zonas de aterrizaje incluye tres conjuntos de recursos para dar
soporte a los equipos en la nube:
Guías de diseño: guía para la toma de decisiones críticas que impulsan el diseño de la zona de aterrizaje a
escala empresarial de Cloud Adoption Framework para Azure.
Arquitectura: arquitectura de referencia conceptual que muestra áreas de diseño y procedimientos
recomendados.
Implementaciones: plantilla de Azure Resource Manager de la arquitectura para acelerar la adopción.
Comunidad
Esta guía la desarrollan principalmente arquitectos de Microsoft y la amplia comunidad técnica de la unidad
Cloud Solutions. Esta comunidad avanza de forma activa esta guía para compartir las lecciones aprendidas
durante los esfuerzos de adopción a escala empresarial.
Esta guía comparte los mismos principios de diseño que la metodología de preparación estándar. Amplía dichos
principios para integrar asuntos como el gobierno y la seguridad en fases anteriores del proceso de
planeamiento. Es necesario expandir el proceso estándar, ya que se pueden realizar algunas suposiciones
naturales cuando un esfuerzo de adopción requiere un cambio empresarial a gran escala.
Pasos siguientes
Implementación de una zona de aterrizaje a escala empresarial de Cloud Adoption Framework
Implementación de zonas de aterrizaje a escala
empresarial de Cloud Adoption Framework en
Azure
Cuando los requisitos empresariales requieren una implementación inicial de muchas zonas de aterrizaje con
una gobernanza, seguridad y plano de control de operaciones totalmente integrados desde el principio, use las
opciones de ejemplo de escala empresarial que se enumeran aquí. Con este enfoque, puede usar Azure Portal o
una infraestructura como código para instalar y configurar el entorno de Azure. También es posible realizar la
transición entre el portal y la infraestructura como código (recomendado) cuando la organización está lista.
Implementación de referencia
En la tabla siguiente se enumeran las implementaciones de referencia de ejemplo basadas en la arquitectura de
escala empresarial recomendada.
IM P L EM EN TA C IÓ N DE
E JEM P LO DESC RIP C IÓ N REP O SITO RIO DE GIT H UB IM P L EM EN TA R EN A Z URE
Base de la escala Esta es la base Ejemplo en GitHub

empresarial recomendada para la
adopción de la escala
empresarial.
Escala empresarial radial Agregue un módulo de red Ejemplo en GitHub

radial a la base de escala
empresarial.
Virtual WAN de escala Agregue un módulo de red Ejemplo en GitHub

empresarial Virtual WAN a la base de
escala empresarial.
Pasos siguientes
En estos ejemplos, se proporciona una opción de implementación sencilla para soportar el aprendizaje continuo
para el enfoque de escala empresarial. Antes de usar estos ejemplos en una versión de producción de escala
empresarial, revise la arquitectura de escala empresarial.
Examinar la arquitectura a escala empresarial
Arquitectura de la zona de aterrizaje a escala
empresarial de Cloud Adoption Framework
El término "escala empresarial" hace referencia a un enfoque de arquitectura y una implementación de

referencia que permite la construcción y la puesta en marcha eficaz de zonas de aterrizaje en Azure, a escala.
Este enfoque está en línea con la hoja de ruta de Azure y Cloud Adoption Framework para Azure.
Introducción a la arquitectura
La arquitectura de la zona de aterrizaje de escala empresarial de Cloud Adoption Framework representa la ruta
de acceso de diseño estratégica y el estado técnico de destino del entorno de Azure de una organización.
Evolucionará al mismo tiempo que la plataforma Azure y la definirán las distintas decisiones de diseño que su
organización debe tomar para asignar su recorrido en Azure.
No todas las empresas adoptan Azure de la misma manera, por lo que la arquitectura de la zona de aterrizaje de
escala empresarial de Cloud Adoption Framework varía de un cliente a otro. Las consideraciones técnicas y las
recomendaciones de diseño de esta guía pueden producir diferentes desventajas en función del escenario de su
organización. Puede haber cierta variación, pero si sigue las recomendaciones principales, la arquitectura de
destino resultante colocará a su organización en una ruta de acceso hacia una escala sostenible.
Zona de aterrizaje de escala empresarial

Las zonas de aterrizaje de Azure son la salida de un entorno de Azure con varias suscripciones que tiene en
cuenta la escala, seguridad, gobernanza, redes e identidad. Las zonas de aterrizaje de Azure permiten la
migración de aplicaciones y el desarrollo de Greenfield a escala empresarial en Azure. Estas zonas tienen en
cuenta todos los recursos de la plataforma necesarios para dar soporte a la cartera de aplicaciones del cliente y
no diferencian entre infraestructura como servicio o plataforma como servicio.
Un ejemplo podría ser el modo en que se puede obtener acceso a los servicios de la ciudad como el agua, el gas
y la electricidad antes de que se construyan nuevos hogares. En este contexto, la red, administración de
identidades y acceso, directivas, administración y supervisión son servicios de utilidades compartidos que
deben estar disponibles fácilmente para ayudar al usuario a simplificar el proceso de migración de la aplicación
antes de que comience.
Figura 1: diseño de la zona de aterrizaje.

Arquitectura de alto nivel
Una arquitectura de escala empresarial se define mediante un conjunto de recomendaciones y consideraciones
de diseño en ocho áreas de diseño críticas, con dos topologías de red recomendadas: una arquitectura de escala
empresarial basada en una topología de red de Azure Virtual WAN (que se muestra en la figura 2) o en una
topología de red de Azure tradicional basada en una arquitectura en estrella tipo hub-and-spoke (que se
describe en la figura 3).
Figura 2: Arquitectura de la zona de aterrizaje de escala empresarial de Cloud Adoption Framework que se basa
en una topología de red de Azure Virtual WAN. Tenga en cuenta que la suscripción de conectividad usa un
centro de conectividad de Virtual WAN.
Figura 3: Arquitectura de la zona de aterrizaje de escala empresarial de Cloud Adoption Framework que se basa
en una topología de red de Azure tradicional. Tenga en cuenta que la suscripción de conectividad usa una red
virtual de centro de conectividad.
Descargue los archivos PDF o Visio que contienen los diagramas de la arquitectura de escala empresarial
basada en la topología de red de Virtual WAN (PDF) o en una topología de red de Azure tradicional basada en la
arquitectura en estrella tipo hub-and-spoke (PDF). Un archivo de Visio que contenga Virtual WAN y el diagrama
de la arquitectura de estrella tipo hub-and-spoke se puede descargar como diagrama de Visio (VSDX).
En las figuras 2 y 3 se hace referencia a las áreas de diseño críticas de la escala empresarial, que se indican con
las letras de la "A" a la "I":
Inscripción en el Contrato Enterprise (EA) e inquilinos de Azure Active Directory. Una inscripción en el
Contrato Enterprise (EA) representa la relación comercial entre Microsoft y el modo en que su organización usa
Azure. Proporciona la base de facturación en todas las suscripciones y afecta a la administración de su
patrimonio digital. La inscripción en EA se administra mediante el portal de Azure EA. Una inscripción suele
representar la jerarquía de una organización, la cual incluye departamentos, cuentas y suscripciones. Un
inquilino de Azure AD proporciona administración de identidades y acceso, lo cual es una parte importante de
su posición de seguridad. Un inquilino de Azure AD garantiza que los usuarios autenticados y autorizados solo
tengan acceso a los recursos para los que tienen permisos de acceso.
Administración de identidades y acceso. El diseño y la integración de Azure Active Directory deben

compilarse para garantizar la autenticación del servidor y del usuario. El control de acceso basado en rol de
Azure (RBAC de Azure) se debe modelar e implementar para aplicar la separación de deberes y derechos
necesarios para la administración y el funcionamiento de la plataforma. La administración de claves debe
diseñarse e implementarse para garantizar un acceso seguro a los recursos y las operaciones de soporte, como
la rotación y la recuperación. En última instancia, los roles de acceso se asignan a los propietarios de la
aplicación en los planos de control y de datos para crear y administrar los recursos de forma autónoma.
Organización de grupos de administración y suscripciones. Las estructuras de grupo de administración
dentro de un inquilino de Azure Active Directory (Azure AD) son compatibles con la asignación organizativa y
deben examinarse a fondo cuando una organización planea adoptar Azure a escala. Las suscripciones son una
unidad de administración, facturación y escalado en Azure. Desempeñan un papel fundamental cuando se lleva
a cabo el diseño para la adopción de Azure a gran escala. Esta área de diseño crítica le ayuda a comprender los
requisitos de suscripción y a diseñar suscripciones de destino basadas en factores críticos. Estos factores son el
tipo de entorno, la propiedad y el modelo de gobierno, la estructura de la organización y las carteras de
aplicaciones.
Administración y supervisión. Deben diseñarse, implementarse e integrarse la supervisión y la generación

de alertas de recursos holísticas (horizontales) en el nivel de la plataforma. También se deben definir y optimizar
tareas operativas como la revisión y la copia de seguridad. Igualmente, las operaciones de seguridad, la
supervisión y el registro deben diseñarse e integrarse con ambos recursos en Azure, así como en los sistemas
locales existentes. Todos los registros de actividades de la suscripción que capturan las operaciones del plano de
control entre los recursos se deben transmitir a Log Analytics para que estén disponibles para su consulta y
análisis, en función de los permisos de RBAC de Azure.
Topología de red y conectividad. La topología de red de un extremo a otro se debe compilar e implementar
entre las regiones de Azure y los entornos locales para garantizar la conectividad de tipo norte-sur y este-oeste
entre las implementaciones de la plataforma. Los servicios y recursos necesarios como firewalls y aplicaciones
virtuales de red deben identificarse, implementarse y configurarse en el diseño de seguridad de red para
garantizar que se cumplen los requisitos de seguridad.
, y Continuidad empresarial y recuperación ante desastres y Seguridad, gobernanza y cumplimiento.

Las directivas holísticas y específicas de la zona de aterrizaje deben identificarse, describirse, compilarse e
implementarse en la plataforma de Azure de destino para garantizar que se implementen controles
corporativos, normativos y de línea de negocio. Asimismo, deben usarse directivas para garantizar el
cumplimiento normativo de las aplicaciones y los recursos subyacentes que no cuenten con ninguna
funcionalidad de aprovisionamiento o administración de la abstracción.
Automatización de la plataforma y DevOps. Una experiencia de DevOps de un extremo a otro con prácticas
eficaces del ciclo de vida de desarrollo de software debe diseñarse, compilarse e implementarse para garantizar
una entrega segura, repetible y coherente de artefactos de infraestructura como código. Estos artefactos se van
a desarrollar, probar e implementar con canalizaciones de integración, lanzamiento e implementación que
cuenten con controles de código fuente y rastreabilidad seguros.
Pasos siguientes
Personalice la implementación de esta arquitectura con las directrices de diseño de escala empresarial de Cloud
Adoption Framework.
Guías de diseño
Principios de diseño a escala empresarial de Cloud
Adoption Framework
La arquitectura de escala empresarial indicada en esta guía se basa en los principios de diseño que se describen
aquí. Estos principios sirven como guía para las decisiones de diseño posteriores en los dominios técnicos
críticos. Familiarícese con estos principios para comprender mejor su impacto y las ventajas y desventajas
asociadas a la no adherencia.
Democratización de las suscripciones

Las suscripciones deben usarse como una unidad de administración y escalado alineadas con las necesidades y
prioridades del negocio, para poder admitir las áreas de negocio y los propietarios de cartera y acelerar las
migraciones de aplicaciones y el nuevo desarrollo de aplicaciones. Se deben proporcionar suscripciones a las
unidades de negocios para apoyar el diseño, desarrollo y prueba de nuevas cargas de trabajo, y la migración de
cargas de trabajo.
Gobernanza controlada mediante directivas

Debe usarse Azure Policy para proporcionar barreras de protección y garantizar el cumplimiento continuo de la
plataforma de la organización, además de las aplicaciones implementadas en ella. Azure Policy también
proporciona a los propietarios de la aplicación libertad suficiente y una ruta de acceso a la nube segura y sin
obstáculos.
Control único y plano de administración

La arquitectura de escala empresarial no debe tener en cuenta las capas de abstracción (como los portales o las
herramientas desarrollados por el cliente). Debe proporcionar una experiencia coherente para AppOps (equipos
de operaciones administrados centralmente) y DevOps (equipos dedicados de operaciones de aplicación). Azure
proporciona un plano de control unificado y coherente en todos los recursos y canales de aprovisionamiento de
Azure que estén sujetos a un acceso basado en roles y controles basados en directivas. Azure se utiliza para
establecer un conjunto normalizado de directivas y controles para administrar todo el patrimonio del cliente.
Centrado en la aplicación y arquetipo neutro

La arquitectura de escala empresarial debe centrarse en migraciones y desarrollos centrados en aplicaciones, en
lugar de migraciones de tipo lift-and-shift puras de la infraestructura (como mover máquinas virtuales). No
debería diferenciar entre las aplicaciones antiguas y nuevas, y aplicaciones de infraestructura como servicio o de
plataforma como servicio. En última instancia, debe proporcionar una base segura para que todos los tipos de
aplicaciones se implementen en su plataforma de Azure.
Alineación del diseño y las hojas de ruta nativos de Azure

El enfoque de arquitectura de escala empresarial aboga por el uso de servicios y funcionalidades de la
plataforma nativa de Azure siempre que sea posible. Este enfoque debe ajustarse a la hoja de ruta de la
plataforma Azure para asegurarse de que las nuevas funcionalidades estén disponibles en los entornos. Las
hojas de ruta de la plataforma Azure le ayudarán a obtener información sobre la estrategia de migración y la
trayectoria a escala empresarial.
Recomendaciones
Conozca a fondo esta funcionalidad, ya que no es probable que todo sea necesario desde el primer día. Use los
servicios en versión preliminar y tome las dependencias de las hojas de ruta para eliminar los obstáculos
técnicos.
Directrices de diseño a escala empresarial de Cloud
Adoption Framework
En este artículo y en la serie de artículos siguiente se describe la manera en que la arquitectura a escala
empresarial proporciona una posición bien fundamentada en cada una de las áreas de diseño de la zona de
aterrizaje de Azure. Esta serie proporciona un conjunto de directrices de diseño paso a paso que se pueden
seguir para implementar los principios de diseño en la solución de escala empresarial.
El núcleo de la arquitectura a escala empresarial contiene una ruta de acceso de diseño crítica compuesta por
temas de diseño fundamentales que cuentan con decisiones de diseño dependientes e interrelacionadas. Este
repositorio proporciona instrucciones de diseño a través de estos dominios técnicos de arquitectura significativa
para apoyar las decisiones de diseño críticas que se deben tener en cuenta para definir la arquitectura de escala
empresarial. En cada uno de los dominios considerados, revise las consideraciones y recomendaciones
proporcionadas y úselas para estructurar y dirigir diseños dentro de cada área.
Por ejemplo, puede preguntar cuántas suscripciones se necesitan para su espacio. Puede revisar la organización
y gobernanza de la suscripción y usar las recomendaciones proporcionadas para impulsar las decisiones de
suscripción.
Áreas de diseño críticas

Las siguientes ocho áreas de diseño críticas pueden ayudarle a convertir sus requisitos en construcciones y
funcionalidades de Azure. Estas áreas de diseño pueden ayudarle a resolver la disparidad entre la infraestructura
local y en la nube, que normalmente crea fricciones entre la definición de escala empresarial y la adopción de
Azure.
El impacto de las decisiones tomadas en estas áreas críticas afectará a la arquitectura a escala empresarial e
influirá en otras decisiones. Familiarícese con las ocho áreas siguientes para comprender mejor las
consecuencias de las decisiones tomadas, que después podrían tener desventajas en las áreas relacionadas.
Inscripción en el Contrato Enterprise (EA) e inquilinos de Azure Active Directory
Inscripción en el Contrato Enterprise e inquilinos de
Azure Active Directory
Planeación de la inscripción Enterprise

Una inscripción en el Contrato Enterprise (EA) representa la relación comercial entre Microsoft y el modo en que
su organización usa Azure. Proporciona la base de facturación en todas las suscripciones y afecta a la
administración de su patrimonio digital. La inscripción en EA se administra mediante el portal de Azure EA. Una
inscripción suele representar la jerarquía de una organización, la cual incluye departamentos, cuentas y
suscripciones. Esta jerarquía representa los grupos de costos de inscripción dentro de una organización.
Figura 1: Jerarquía una inscripción en EA de Azure.

Los departamentos ayudan a dividir los costos en agrupaciones lógicas y a establecer un presupuesto o una
cuota en el nivel de departamento. La cuota no se aplica firmemente y se utiliza en la elaboración de
informes.
Las cuentas son unidades organizativas en el portal de Azure EA. Se pueden usar para administrar las
suscripciones y acceder a los informes.
Las suscripciones son la unidad más pequeña en el portal de Azure EA. Son contenedores para los servicios
de Azure que administra el administrador de servicios. Es donde la organización implementa los servicios de
Azure.
Los roles de inscripción de EA vinculan a los usuarios con su rol funcional. Estos roles son:
Administrador de empresa
Administrador de departamentos
Propietario de cuenta
Administrador de servicios
Contacto para notificaciones
Consideraciones de diseño:
La inscripción proporciona una estructura organizativa jerárquica para controlar la administración de las
suscripciones.
Se pueden separar varios entornos en un nivel de cuentas de EA para admitir el aislamiento holístico.
Puede haber varios administradores designados en una inscripción única.
Cada suscripción debe tener un propietario de cuenta asociado.
Cada propietario de la cuenta se convertirá en un propietario de suscripción para todas las suscripciones
aprovisionadas en esa cuenta.
Una suscripción solo puede pertenecer a una cuenta en un momento dado.
Una suscripción se puede suspender en función de un conjunto específico de criterios.
Recomendaciones de diseño:
Use solo el tipo de autenticación Work or school account en todos los tipos de cuenta. Evite el uso del tipo de
cuenta Microsoft account (MSA) .
Configure la dirección de correo electrónico de contacto para recibir notificaciones y así asegurarse de que
estas se envían a un buzón de grupo adecuado.
Asigne un presupuesto para cada cuenta y establezca una alerta asociada con ese presupuesto.
Una organización puede tener varias estructuras, como una estructura funcional, de división, geográfica, de
matriz o de equipo. Use la estructura organizativa para asignar la estructura de la organización a la jerarquía
de inscripción.
Cree un nuevo departamento de TI si los dominios empresariales tienen capacidades de TI independientes.
Restrinja y minimice el número de propietarios de cuentas dentro de la inscripción para evitar la
proliferación de accesos de administrador a las suscripciones y los recursos de Azure asociados.
Si se usan varios inquilinos de Azure Active Directory (Azure AD), compruebe que el propietario de la cuenta
esté asociado al mismo inquilino en el que se aprovisionan las suscripciones de la cuenta.
Configure entornos de desarrollo, pruebas y producción de Enterprise en un nivel de cuenta de EA para
admitir el aislamiento holístico.
No ignore los correos electrónicos de notificación que se envían a la dirección de correo electrónico que
recibe las notificaciones. Tenga en cuenta que Microsoft envía comunicaciones importantes de EA a esta
cuenta.
No mueva ni cambie el nombre de una cuenta de EA en Azure AD.
Realice auditorías periódicas en el portal de EA para revisar quién tiene acceso y evitar el uso de una cuenta
de Microsoft siempre que sea posible.
Defina los inquilinos de Azure AD

Un inquilino de Azure AD proporciona administración de identidades y acceso, lo cual es una parte importante
de su posición de seguridad. Un inquilino de Azure AD garantiza que los usuarios autenticados y autorizados
solo tengan acceso a los recursos para los que tienen permisos de acceso. Azure AD proporciona estos servicios
a las aplicaciones y los servicios implementados en Azure, y también a los servicios y aplicaciones
implementados fuera de Azure (como proveedores de nube locales o de terceros).
Azure AD también se usa en aplicaciones de software como servicio, como Microsoft 365 y Azure Marketplace.
Las organizaciones que ya usan la versión local de Active Directory pueden usar su infraestructura y ampliar la
autenticación a la nube mediante la integración con Azure AD. Cada directorio de Azure AD tiene uno o varios
dominios. Un directorio puede tener varias suscripciones asociadas, pero solo un inquilino de Azure AD.
Es importante formular preguntas básicas de seguridad durante la fase de diseño de Azure AD, como la forma
en que una organización administra las credenciales y el modo en que controla el acceso mediante
programación a personas y aplicaciones.
varios inquilinos de Azure AD pueden trabajar en la misma inscripción.
Use el inicio de sesión único de conexión directa de Azure AD basado en la topología de planeación
seleccionada.
Si su organización no tiene una infraestructura de identidad, empiece por implementar una identidad que
solo sea de Azure AD. Esta implementación con Azure AD Domain Services y Microsoft Enterprise Mobility +
Security proporciona protección completa a las aplicaciones de SaaS y empresariales, así como a los
dispositivos.
La autenticación multifactor proporciona otra capa de seguridad y una segunda barrera de autenticación.
Aplique la autenticación multifactor y las directivas de acceso condicional a todas las cuentas con privilegios
para obtener una mayor seguridad.
Planee e implemente el acceso de emergencia o las cuentas de emergencia para evitar el bloqueo de cuentas
en todo el inquilino.
Use Azure AD Privileged Identity Management para la administración de la identidad y el acceso.
Si el proceso de desarrollo, pruebas y producción va a estar en un entorno aislado desde una perspectiva de
identidad, separe estas operaciones a nivel de inquilino a través de varios inquilinos.
Evite crear un nuevo inquilino de Azure AD a menos que haya una justificación sólida de la administración de
identidades y acceso, y que ya haya procesos en vigor.
La identidad aporta gran parte de las garantías de seguridad. Permite el acceso basado en la autenticación de la
identidad y los controles de autorización en los servicios en la nube, para proteger los datos y los recursos, y
para decidir qué solicitudes deben permitirse.
La administración de identidad y de acceso (IAM) es un límite de seguridad principal en la nube pública. Debe
tratarse como la base de cualquier arquitectura de nube pública segura y totalmente compatible. Azure ofrece
un conjunto completo de servicios, herramientas y arquitecturas de referencia para que las organizaciones
puedan crear entornos altamente seguros y que funcionen de manera eficiente, como se describe aquí.
En esta sección se examinan las consideraciones y las recomendaciones de diseño relativas a IAM en un entorno
empresarial.
Por qué necesitamos la administración de identidades y acceso

El panorama tecnológico de la empresa se está volviendo cada vez más complejo y heterogéneo. Con el fin de
administrar el cumplimiento y la seguridad de este entorno, IAM permite a los usuarios adecuados acceder a los
recursos correctos en un momento determinado y por las razones adecuadas.
Plan de la administración de identidades y acceso
Normalmente, las organizaciones empresariales siguen un enfoque de privilegios mínimos para el acceso
operativo. Este modelo se debe expandir para incluir a Azure mediante el control de acceso basado en rol (RBAC
de Azure) de Azure Active Directory (Azure AD) y las definiciones de roles personalizados. Es fundamental
planear cómo administrar el control y el acceso al plano de datos en los recursos de Azure. Cualquier diseño
para IAM y RBAC de Azure debe cumplir los requisitos legales, de seguridad y de funcionamiento antes de que
se pueda aceptar.
La administración de identidades y acceso es un proceso de varios pasos que implica un planeamiento
cuidadoso de la integración de identidades y otras consideraciones de seguridad, como el bloqueo de la
autenticación heredada y el planeamiento de contraseñas modernas. El planeamiento del almacenamiento
provisional también implica la necesidad de seleccionar la administración de identidades y acceso de tipo
"negocio a negocio" o "negocio a consumidor". Aunque estos requisitos varían, existen consideraciones de
diseño comunes y recomendaciones que se deben tener en cuenta cuando se use una zona de aterrizaje de la
empresa.
Figura 1: Administración de identidades y acceso.

Existen límites en el número de roles personalizados y las asignaciones de roles que se deben tener en
cuenta al diseñar un marco relativo a IAM y la gobernanza. Para más información, consulte Limites de
servicio de RBAC de Azure.
Hay un límite de 2000 asignaciones de roles por suscripción.
Hay un límite de 500 asignaciones de roles por grupo de administración.
Propiedad de recursos centralizada o federada:
Es necesario administrar de forma centralizada los recursos compartidos o cualquier aspecto del
entorno que implemente o aplique un límite de seguridad, como la red. Este requisito forma parte de
muchos marcos normativos. Es una práctica habitual en cualquier organización que conceda o
deniegue el acceso a los recursos empresariales confidenciales o críticos.
La administración de los recursos de la aplicación que no infrinjan los límites de seguridad u otros
aspectos necesarios para mantener la seguridad y el cumplimiento se pueden delegar a los equipos
de la aplicación. Permitir a los usuarios aprovisionar recursos dentro de un entorno administrado de
forma segura ofrece a las organizaciones la oportunidad de aprovechar la naturaleza ágil de la nube y,
al mismo tiempo, evitar la infracción de cualquier límite crítico de seguridad o gobernanza.
En función de la definición de la propiedad de recursos centralizada o federada, los roles
personalizados pueden diferir. Los roles personalizados de la propiedad de recursos centralizada son
limitados y pueden necesitar derechos adicionales en función del modelo de responsabilidad. Por
ejemplo, en algunas organizaciones, es posible que un rol de NetOps solo necesite administrar y
configurar la conectividad global. Sin embargo, en otras organizaciones que necesitan un enfoque
más centralizado, el rol de NetOps debe enriquecerse con más acciones permitidas como la creación
de un emparejamiento entre el centro de conectividad y los radios.
Use RBAC de Azure para administrar el acceso del plano de datos a los recursos, siempre que sea posible.
Algunos ejemplos son Azure Key Vault, una cuenta de almacenamiento o una base de datos SQL.
Implemente las directivas de acceso condicional de Azure AD para cualquier usuario con derechos en los
entornos de Azure. Al hacerlo, obtendrá otro mecanismo para proteger un entorno de Azure controlado
frente a accesos no autorizados.
Exija que los usuarios con derechos en los entornos de Azure realicen la autenticación multifactor. La
aplicación de la autenticación multifactor es un requisito de muchos marcos de cumplimiento. Reduce en
gran medida el riesgo de robo de credenciales y el acceso no autorizado.
Use Azure AD Privileged Identity Management (PIM) para establecer un privilegio mínimo pero no un acceso
permanente. Asigne los roles de la organización al nivel mínimo de acceso necesario. PIM de Azure AD puede
ser una extensión de las herramientas y los procesos existentes, usar herramientas nativas de Azure tal y
como se describió anteriormente, o bien pueden usarse ambas opciones si es necesario.
Cuando acceda a los recursos, use los grupos que solo sean de Azure AD para los recursos del plano de
control de Azure en PIM de Azure AD.
Agregue grupos locales al grupo que solo sea de Azure AD, si ya existe un sistema de administración
de grupos.
Use las revisiones de acceso de Azure AD PIM para validar periódicamente los derechos de los recursos. Las
revisiones del acceso forman parte de muchos marcos de cumplimiento normativo. Como resultado, muchas
organizaciones ya tendrán implantado un proceso para abordar este requisito.
Integre los registros de Azure AD con el elemento central Azure Monitor de la plataforma. Azure Monitor
permite tener un único origen de confianza de datos de registro y supervisión en Azure, lo que proporciona a
las organizaciones opciones nativas de la nube para cumplir los requisitos de recopilación y retención de
registros.
Si existen requisitos de soberanía de datos, se pueden implementar directivas de usuario personalizadas para
aplicarlos.
Use las definiciones de roles personalizados en el inquilino de Azure AD al considerar los siguientes roles
clave:
RO L E USO A C C IO N ES N IN GUN A A C C IÓ N
Propietario de la plataforma Administración de grupos y *

Azure (como, por ejemplo, del ciclo de vida de la
el rol de propietario suscripción.
integrado)
Administración de redes Administración de */read ,

(NetOps) conectividad global en toda Microsoft.Network/vpnGateways/*
la plataforma: Redes ,
virtuales, enrutamientos Microsoft.Network/expressRouteCircuits/*
definidos por el usuario, ,
grupos de seguridad de red, Microsoft.Network/routeTables/write
dispositivos virtuales de ,
red, VPN, Azure Microsoft.Network/vpnSites/*
ExpressRoute y otros
RO L E USO A C C IO N ES N IN GUN A A C C IÓ N
Operaciones de seguridad Rol de administrador de */read ,

(SecOps) seguridad que cuenta con */register/action ,
una vista horizontal en todo Microsoft.KeyVault/locations/deletedVaults/purge/action
el espacio de Azure y la ,
directiva de depuración de Microsoft.Insights/alertRules/*
Azure Key Vault. ,
Microsoft.Authorization/policyDefinitions/*
,
Microsoft.Authorization/policyAssignments/*
,
Microsoft.Authorization/policySetDefinitions/*
,
Microsoft.PolicyInsights/*
, Microsoft.Security/*
Propietario de la suscripción Rol delegado del propietario * Microsoft.Authorization/*/write

de la suscripción derivado ,
del rol del propietario de la Microsoft.Network/vpnGateways/*
suscripción. ,
Microsoft.Network/expressRouteCircuits/*
,
Microsoft.Network/routeTables/write
,
Microsoft.Network/vpnSites/*
Propietarios de aplicaciones Rol del colaborador * Microsoft.Authorization/*/write

(DevOps/AppOps) concedido para el equipo de ,
aplicaciones u operaciones Microsoft.Network/publicIPAddresses/write
en el nivel del grupo de ,
recursos. Microsoft.Network/virtualNetworks/write
,
Microsoft.KeyVault/locations/deletedVaults/purge/acti
Use el acceso Just-in-Time de Azure Security Center en todos los recursos de tipo Infraestructura como
servicio (IaaS) y así habilitar la protección de nivel de red para el acceso de usuario efímero a las máquinas
virtuales de IaaS.
Use identidades administradas de Azure AD para recursos de Azure a fin de evitar la autenticación en función
de los nombres de usuario y las contraseñas. Como muchas infracciones de seguridad de los recursos de la
nube pública se originan con el robo de credenciales insertadas en el código u otros orígenes de texto, el uso
de identidades administradas para el acceso mediante programación reduce considerablemente el riesgo de
robo de credenciales.
Use identidades con privilegios para los runbooks de Automation que requieran permisos de acceso
elevados. Los flujos de trabajo automatizados que infringen los límites de seguridad críticos deben regirse
con las mismas herramientas y directivas que cuenten los usuarios con privilegios equivalentes.
No agregue usuarios directamente a los ámbitos de recursos de Azure. En su lugar, agregue usuarios a los
roles definidos, que luego se asignan a los ámbitos de recursos. Las asignaciones de usuarios directas eluden
la administración centralizada y aumentan en gran medida la administración necesaria para evitar el acceso
no autorizado a los datos restringidos.
Plan de la autenticación en una zona de aterrizaje
Una decisión de diseño fundamental que debe tomar una organización empresarial al adoptar Azure, es si
quiere ampliar el dominio de identidades local existente a Azure o si quiere crear uno nuevo. Los requisitos de
autenticación dentro de la zona de aterrizaje deben evaluarse minuciosamente e incorporarse en planes para
implementar Active Directory Domain Services (AD DS) en Windows Server, Azure AD Domain Services
(Azure AD DS) o ambos. La mayoría de los entornos de Azure usarán al menos Azure AD para la autenticación
del tejido de Azure, la autenticación del host local de AD DS y la administración de directivas de grupo.
Tenga en cuenta las responsabilidades centralizadas y delegadas para administrar los recursos
implementados dentro de la zona de aterrizaje.
Las aplicaciones que dependen de los servicios de dominio y utilizan protocolos más antiguos pueden usar
Azure AD DS.
Use las responsabilidades centralizadas y delegadas para administrar los recursos implementados en la zona
de aterrizaje en función de los requisitos de roles y seguridad.
Las operaciones con privilegios, como la creación de objetos de entidades de servicio, el registro de
aplicaciones en Azure AD y la obtención y administración de certificados o certificados comodín requieren
permisos especiales. Tenga en cuenta qué usuarios van a controlar estas solicitudes y cómo va a proteger y
supervisar sus cuentas con el grado de diligencia necesaria.
Si una organización tiene un escenario en el que el acceso a una aplicación que use la autenticación
integrada de Windows deba realizarse de forma remota con Azure AD, considere la posibilidad de usar
Azure AD Application Proxy.
Hay una diferencia entre Azure AD, Azure AD DS y AD DS que se ejecuta en Windows Server. Evalúe las
necesidades de la aplicación y comprenda y documente el proveedor de autenticación que utilizará cada una
de ellas. Realice sus planes teniendo en mente todas las aplicaciones.
Evalúe la compatibilidad de las cargas de trabajo para AD DS en Windows Server y para Azure AD DS.
Asegúrese de que el diseño de red permite que los recursos que requieren AD DS en Windows Server para la
autenticación y administración locales obtengan acceso a los controladores de dominio adecuados.
En el caso de AD DS en Windows Server, considere la posibilidad de usar entornos de servicios
compartidos que ofrezcan autenticación local y administración de host en un contexto de red más
amplio para toda la empresa.
Implemente Azure AD DS en la región primaria, ya que este servicio solo se puede proyectar en una
suscripción.
Use identidades administradas en lugar de entidades de servicio para realizar la autenticación en los
servicios de Azure. Este enfoque reduce la posibilidad de que le roben las credenciales.
Organización de grupos de administración y
suscripciones
Figura 1: Jerarquía de los grupos de administración.
Definición de una jerarquía de grupos de administración

Las estructuras de grupo de administración de un inquilino de Azure Active Directory (Azure AD) admiten la
asignación organizativa y deben examinarse a fondo cuando una organización planea adoptar Azure a escala.
Los grupos de administración se pueden usar para agregar asignaciones de directivas e iniciativas a
través de Azure Policy.
Un árbol de grupo de administración puede admitir hasta seis niveles de profundidad. Este límite no
incluye el nivel raíz o de suscripción.
Cualquier entidad de seguridad (usuario, entidad de servicio) de un inquilino de Azure AD puede crear
nuevos grupos de administración, ya que la autorización del control de acceso basado en rol de Azure
(RBAC) para las operaciones del grupo de administración no está habilitada de forma predeterminada.
De forma predeterminada, todas las suscripciones nuevas se colocarán en el grupo de administración
raíz.
Mantenga la jerarquía de los grupos de administración lo más horizontal posible; idealmente, con no más
de tres o cuatro niveles. Esta restricción reduce la sobrecarga y la complejidad de la administración.
Evite duplicar la estructura organizativa en una jerarquía de grupos de administración anidados el uno en
el otro. Los grupos de administración deben usarse para la asignación de directivas, en lugar de la
facturación. Este enfoque requiere el uso de grupos de administración para su fin previsto en la
arquitectura de escala empresarial, que es proporcionar directivas de Azure para las cargas de trabajo
que precisan el mismo tipo de seguridad y cumplimiento en el mismo nivel de grupo de administración.
Cree grupos de administración en el grupo de administración de nivel raíz para representar los tipos de
cargas de trabajo (arquetipos) que va a hospedar y según sus necesidades de seguridad, cumplimiento,
conectividad y características. Esta estructura de agrupación le permite disponer de un conjunto de
directivas de Azure aplicadas en el nivel de grupo de administración para todas las cargas de trabajo que
requieran la misma configuración de seguridad, cumplimiento, conectividad y características.
Use etiquetas de recursos, que se pueden aplicar o anexar a través de Azure Policy, para consultar y
explorar de forma horizontal la jerarquía de grupos de administración. Luego, puede agrupar los recursos
según sus requisitos de búsqueda sin necesidad de usar una jerarquía de grupos de administración
compleja.
Cree un grupo de administración de espacio aislado general para que los usuarios puedan experimentar
inmediatamente con Azure. Los usuarios pueden experimentar después con recursos que quizás aún no
se han permitido en entornos de producción. El espacio aislado proporciona aislamiento de los entornos
de desarrollo, prueba y producción. Para más información sobre el grupo de administración de espacios
aislados de nivel superior, revise las instrucciones de implementación.
Use un nombre de entidad de seguridad de servicio (SPN) dedicado para ejecutar operaciones de
administración de grupos de administración, operaciones de administración de suscripciones y
asignaciones de roles. El uso de una SPN reduce el número de usuarios que tienen derechos elevados y
sigue las instrucciones con privilegios mínimos.
Asigne el rol User Access Administrator de Azure en el ámbito del grupo de administración raíz ( / ) para
conceder al SPN mencionado anteriormente acceso en el nivel raíz. Una vez concedidos los permisos al
SPN, el rol User Access Administrator se puede quitar de forma segura. De esta manera, solo el SPN
forma parte del rol User Access Administrator .
Asigne el permiso Contributor al SPN mencionado anteriormente en el ámbito del grupo de
administración raíz ( / ), que permite las operaciones de nivel de inquilino. Este nivel de permisos
permite usar el SPN para implementar y administrar los recursos en cualquier suscripción de una
organización.
Cree el grupo de administración Platform en el grupo de administración raíz para admitir la directiva de
plataforma común y la asignación de roles de Azure. Esta estructura de agrupación permite aplicar
distintas directivas a las suscripciones utilizadas para la base de Azure. También centraliza la facturación
de los recursos comunes en un conjunto de suscripciones fundamentales.
Limite el número de asignaciones de Azure Policy realizadas en el ámbito del grupo de administración
raíz ( / ). Esta limitación reduce a un mínimo la depuración de directivas heredadas en grupos de
administración de nivel inferior.
Use las directivas disponibles para las zonas de aterrizaje a escala empresarial para aplicar los requisitos
de cumplimiento en el ámbito del grupo de administración o la suscripción. Consulte las instrucciones de
la sección sobre el Gobernanza controlada mediante directivas para obtener más información sobre los
requisitos de gobernanza que se pueden detallar.
Asegúrese de que solo los usuarios con privilegios puedan trabajar con grupos de administración en el
inquilino habilitando la autorización mediante el control de acceso basado en roles de Azure en la
configuración de jerarquía del grupo de administración (de forma predeterminada, todos los usuarios
tienen autorización para crear sus propios grupos de administración en el grupo de administración raíz).
Configure un grupo de administración predeterminado y dedicado para nuevas suscripciones para
asegurarse de que no haya ninguna suscripción en el grupo de administración raíz. Esto es especialmente
importante si hay usuarios aptos para beneficiarse de las ventajas y suscripciones de MSDN o
Visual Studio. Un buen candidato para este grupo de administración es un grupo de administración de
Sandbox .
Organización y gobernanza de las suscripciones
Las suscripciones son una unidad de administración, facturación y escalado en Azure. Desempeñan un papel
fundamental cuando se lleva a cabo el diseño para la adopción de Azure a gran escala. Esta sección le ayuda a
comprender los requisitos de suscripción y a diseñar suscripciones de destino basadas en factores críticos. Estos
factores son el tipo de entorno, la propiedad y el modelo de gobierno, la estructura de la organización y las
carteras de aplicaciones.
Las suscripciones funcionan como límites para la asignación de directivas de Azure. Por ejemplo, las
cargas de trabajo seguras, como las cargas de trabajo de la industria de tarjetas de pago (PCI), suelen
requerir directivas adicionales para lograr el cumplimiento. En lugar de usar un grupo de administración
para agrupar las cargas de trabajo que requieren el cumplimiento del PCI, puede obtener el mismo
aislamiento con una suscripción. De esta forma, no necesita tener demasiados grupos de administración
con pocas suscripciones.
Las suscripciones funcionan como una unidad de escalado para que las cargas de trabajo de
componentes puedan escalarse dentro de los límites de suscripción de la plataforma. Asegúrese de tener
en cuenta los límites de recursos de la suscripción durante las sesiones de diseño de la carga de trabajo.
Las suscripciones proporcionan un límite de administración para la gobernanza y el aislamiento, lo que
crea una separación clara de los intereses.
Hay un proceso manual, la automatización futura planeada, que se puede llevar a cabo para limitar un
inquilino de Azure AD para que use solo las suscripciones inscritas en un Contrato Enterprise. Este
proceso evita la creación de suscripciones de Microsoft Developer Network en el ámbito del grupo de
administración raíz.
Trate las suscripciones como una unidad democratizada de administración en consonancia con las
necesidades y prioridades de la empresa.
Informe a los propietarios de la suscripción de sus roles y responsabilidades:
Realice una revisión de acceso en Azure AD Privileged Identity Management cada trimestre o dos
veces al año para asegurarse de que los privilegios no se propaguen a medida que los usuarios se
mueven dentro de la organización del cliente.
Hágase cargo por completo de los gastos presupuestarios y del uso de recursos.
Garantice el cumplimiento de la directiva y las correcciones, cuando sean necesarias.
Use los siguientes principios durante la identificación de requisitos para nuevas suscripciones:
Límites de escalado: Las suscripciones funcionan como una unidad de escalado para que las cargas
de trabajo de componentes se escalen dentro de los límites de suscripción de la plataforma. Por
ejemplo, con las cargas de trabajo especializadas de gran tamaño (como la informática de alto
rendimiento, IoT y SAP), resulta más adecuado usar suscripciones independientes para evitar las
limitaciones (como el límite de 50 integraciones de Azure Data Factory).
Límite de administración: Las suscripciones proporcionan un límite de administración para la
gobernanza y el aislamiento, lo que permite separar claramente los intereses. Por ejemplo, los
distintos entornos, como los de desarrollo, prueba y producción, suelen estar aislados desde una
perspectiva administrativa.
Límite de la directiva: Las suscripciones funcionan como límite para la asignación de directivas de
Azure. Por ejemplo, las cargas de trabajo seguras, como las del sector de las tarjetas de pago (PCI),
suelen requerir directivas adicionales para lograr el cumplimiento. No es necesario que esta
sobrecarga adicional se considere holísticamente si se usa una suscripción independiente. Del mismo
modo, los entornos de desarrollo pueden tener requisitos de directiva más flexibles en relación con
los entornos de producción.
Topología de la red de destino: Las redes virtuales no se pueden compartir entre suscripciones,
pero pueden conectarse con distintas tecnologías, como el emparejamiento de redes virtuales o Azure
ExpressRoute. Tenga en cuenta qué cargas de trabajo deben comunicarse entre sí cuando decida si se
requiere una nueva suscripción.
Agrupe las suscripciones en grupos de administración en consonancia con la estructura del grupo de
administración y los requisitos de directiva a escala. La agrupación permite que las suscripciones con el
mismo conjunto de directivas y asignaciones de roles de Azure puedan heredarlas de un grupo de
administración, lo que evitará las asignaciones duplicadas.
Configure una suscripción de administración dedicada en el grupo de administración Platform para
admitir funcionalidades de administración globales como las áreas de trabajo de Azure Monitor Log
Analytics y los runbooks de Azure Automation.
Configure una suscripción de identidad dedicada en el grupo de administración Platform para hospedar
los controladores de dominio de Windows Server Active Directory, cuando sea necesario.
Establezca una suscripción de conectividad dedicada en el grupo de administración Platform para
hospedar un centro de conectividad de Azure Virtual WAN, un sistema de nombres de dominio (DNS)
privado, un circuito ExpressRoute y otros recursos de red. Una suscripción dedicada garantiza que todos
los recursos de la red de base se facturen juntos y se aíslen de otras cargas de trabajo.
Evite un modelo de suscripción rígida y, en su lugar, opte por un conjunto de criterios flexibles para
agrupar las suscripciones en toda la organización. Esta flexibilidad garantiza que, a medida que la
estructura de la organización y la composición de la carga de trabajo cambien, pueda crear nuevos
grupos de suscripciones en lugar de usar un conjunto fijo de las suscripciones existentes. Un tamaño no
se ajusta a todas las suscripciones. Lo que funciona para una unidad de negocio podría no funcionar para
otra. Algunas aplicaciones pueden coexistir en la misma suscripción de zona de aterrizaje, mientras que
otras pueden requerir su propia suscripción.
Configuración de la capacidad y la cuota de suscripción

Cada región de Azure contiene un número finito de recursos. A la hora de considerar una adopción de Azure a
escala empresarial que implique grandes cantidades de recursos, asegúrese de que haya suficiente capacidad y
SKU disponibles, y de que la capacidad obtenida se pueda conocer y supervisar.
Tenga en cuenta los límites y las cuotas de la plataforma de Azure para cada uno de los servicios que
requieran las cargas de trabajo.
Tenga en cuenta la disponibilidad de las SKU necesarias dentro de las regiones de Azure seleccionadas.
Por ejemplo, las características nuevas podrían estar disponibles solo en determinadas regiones. La
disponibilidad de ciertas SKU para recursos concretos, como las máquinas virtuales, puede cambiar de
una región a otra.
Tenga en cuenta que las cuotas de suscripción no son garantías de capacidad y se aplican en cada región.
Use las suscripciones como unidades de escalado y escale horizontalmente los recursos y las
suscripciones según sea necesario. La carga de trabajo puede usar los recursos necesarios para el
escalado horizontal, cuando sea necesario, sin alcanzar los límites de suscripción en la plataforma Azure.
Use las instancias reservadas para clasificar la capacidad reservada en las regiones necesarias. La carga
de trabajo tendrá la capacidad necesaria, aunque haya una alta demanda de ese recurso en una región
específica.
Establezca un panel con vistas personalizadas para supervisar los niveles de capacidad usados. Configure
alertas si el uso de la capacidad está alcanzando niveles críticos (por ejemplo, un 90 % de uso de la CPU).
Genere solicitudes de soporte técnico para aumentar la cuota como parte del aprovisionamiento de
suscripciones (por ejemplo, el total de núcleos de máquina virtual disponibles en una suscripción). Con
este enfoque, los límites de cuota se configuran antes de que las cargas de trabajo requieran superar los
límites predeterminados.
Asegúrese de que los servicios y las características necesarios están disponibles en las regiones de
implementación seleccionadas.
Establecimiento de la administración de costos

La transparencia de costos en el inmueble técnico es un desafío de administración crítico al que se enfrentan
todas las organizaciones empresariales de gran tamaño. En esta sección se exploran los aspectos clave de la
transparencia de los costos en los entornos de gran tamaño de Azure.
Es posible que se necesiten modelos de anulación en aquellos casos relacionados con recursos
compartidos de plataforma como servicio (PaaS), como Azure App Service Environment y Azure
Kubernetes Service, que pueden requerir compartirse para lograr una mayor densidad.
Use una programación de apagado para las cargas de trabajo que no sean de producción, a fin de
optimizar los costos.
Use Azure Advisor para comprobar las recomendaciones para optimizar los costos.
Use Azure Cost Management + Billing para agregar los costos. Ponga esta información a disposición de
los propietarios de la aplicación.
Use etiquetas de recursos de Azure para clasificar los costos y los recursos del grupo. El uso de etiquetas
le permite disponer de un mecanismo de contracargo para las cargas de trabajo que comparten una
suscripción, o bien para una carga de trabajo determinada que abarque varias suscripciones.
Gobernanza controlada mediante directivas

Las organizaciones pueden usar directivas de Azure a escala empresarial para aplicar los siguientes requisitos
de gobernanza:
Impedir ser vicios basados en IP públicas
La mayoría de los servicios de plataforma como servicio (PaaS) de Azure se crean con una dirección IP
pública asignada a cada servicio. Esta opción puede ayudar a los desarrolladores que necesitan empezar
a usar estos servicios rápidamente.
El punto de conexión público acelera la curva de aprendizaje y admite el desarrollo de pilotos e
implementaciones de pruebas de concepto (POC) a pequeña escala, pero los desarrolladores a veces
pasan por alto sus direcciones IP públicas al realizar la transición de las soluciones piloto o POC a
aplicaciones empresariales listas para producción.
Las cargas de trabajo de producción que usan direcciones IP públicas sin las medidas de seguridad
adecuadas pueden aumentar los riesgos de seguridad. Un tipo de amenaza es un actor que usa una
dirección IP pública como puerta de enlace para iniciar un ataque. Para minimizar los riesgos de
seguridad, muchas directivas de cumplimiento empresarial no permiten IP públicas.
Hay una directiva personalizada que tiene como destino un ámbito y evita que se cree allí una dirección
IP pública. Las empresas también pueden usar esta directiva para crear máquinas virtuales sin IP
públicas. Del mismo modo, hay un conjunto de directivas o iniciativas de directiva personalizadas que
también ayuda a las empresas a evitar que los servicios de Azure se creen con direcciones IP públicas.
Recopilación de información de auditoría y registro
La falta de información de auditorías y diagnósticos en un nivel detallado puede afectar a los
procedimientos operativos. La información de auditoría incompleta dificulta la correlación de los
registros de varios servicios de Azure y crea una depuración coherente.
Una vez que se aprovisionan los servicios de Azure, estos deben proporcionar información detallada
sobre la plataforma de Azure con la que interactúan. Esta información se puede dividir ampliamente en
registros y métricas, y cada servicio de Azure se puede agrupar aún más en sus subcomponentes (por
ejemplo, un recurso de IP pública de Azure con DDoSProtectionNotifications , DDoSMitigationReports y
DDoSMitigationFlowLogs como subcomponentes). La recopilación de información de diagnóstico en estas
subcategorías también puede ayudar a las organizaciones a mejorar sus procesos de auditoría y
depuración.
Hay disponible una iniciativa de directiva de Azure personalizada para ayudar a las empresas a recopilar
registros y métricas en un nivel más profundo para cada servicio de Azure. Esta iniciativa incluye una
directiva para cada servicio de Azure y las directivas recopilan automáticamente las categorías de registro
y las métricas clave.
Proporcionar una seguridad completa para las bases de datos SQL
Las bases de datos SQL son un servicio de Azure común en la mayoría de las implementaciones de
Azure. Desafortunadamente, también son el objetivo de actividades malintencionadas dentro y fuera de
una empresa. Una iniciativa de directiva de Azure personalizada para bases de datos SQL ayuda a las
organizaciones a aplicar los siguientes procedimientos de gobernanza clave:
Cifrado de los datos SQL en reposo
Las bases de datos SQL y sus copias de seguridad son vulnerables para numerosos actores
malintencionados. Dado que es fácil restaurar bases de datos SQL a partir de copias de seguridad
o archivos de base de datos, los actores malintencionados pueden acceder a estos datos si no hay
un sistema de defensa adecuado.
Debe asegurarse de que la base de datos SQL está cifrada en reposo, ya que este es uno de los
primeros pasos de una estrategia de defensa para la base de datos SQL. El cifrado de datos
transparente de Azure SQL Database permite cifrar los datos en reposo de la base de datos sin
cambiar el código de una aplicación y supone un obstáculo para los actores malintencionados que
intentan acceder a los datos, incluso si estos se encuentran en peligro. A medida que las
implementaciones de SQL Database aumentan dentro de una empresa, es importante crearlas con
el cifrado de datos transparente. Existe una directiva personalizada que garantiza el cifrado de
datos transparente en las bases de datos SQL.
Optimización de aler tas de actividades sospechosas
Los actores malintencionados pretenden acceder y explotar las vulnerabilidades de seguridad de
las bases de datos SQL críticas para la empresa. Si las empresas no son conscientes de estos
intentos, aumenta el riesgo de no detectar y resolver estos incidentes. En el peor de los casos, es
posible que una empresa nunca sepa si su base de datos SQL ha estado en peligro.
SQL Database permite a las empresas configurar alertas de seguridad que informan de
actividades de Microsoft SQL Server sospechosas. Estas alertas llegan a direcciones de correo
electrónico preconfiguradas y, opcionalmente, a los administradores y propietarios de las
suscripciones de Azure. Pueden exponer actividades malintencionadas como ataques por
inyección de código SQL, ataques por fuerza bruta, etc.
Hay disponible una directiva de Azure personalizada para habilitar alertas de seguridad en bases
de datos SQL. Las alertas de seguridad proporcionan información detallada sobre cada incidente,
la cual se puede ver en Azure Portal o en los correos electrónicos del momento en que se
desencadenaron las alertas.
Examen de un registro de auditoría de las operaciones
Una base de datos SQL crítica para la empresa puede funcionar diariamente con una amplia
variedad de comandos de lenguaje de manipulación, control y definición de datos. Si no tiene un
control claro e información sobre estas actividades operativas, puede resultar difícil distinguir
entre las operaciones legítimas y las sospechosas.
La habilitación de la auditoría de SQL puede ayudar a las empresas a recopilar información
importante sobre todas las actividades de las bases de datos y la auditoría de SQL ayuda a las
empresas a crear y analizar un registro de auditoría de eventos de base de datos. Esto también
forma parte de muchos requisitos de cumplimiento normativo del sector o regionales.
Asimismo, las empresas pueden usar una directiva personalizada de Azure para aplicar la auditoría
a bases de datos SQL. Esta directiva audita e informa sobre eventos clave de bases de datos, como
la propiedad, la pertenencia a roles o los cambios de esquema, inicios de sesión correctos o con
errores, etc. Las empresas pueden usar este registro de auditoría de la directiva para obtener
información sobre las operaciones de bases de datos y el cumplimiento de los requisitos
normativos regionales o del sector.
Evaluación de procedimientos recomendados probados
Una base de datos SQL puede experimentar una gran cantidad de cambios de esquema, permisos y
configuración a lo largo de su ciclo de vida, y estos cambios pueden desviarse de los procedimientos
recomendados. Al mismo tiempo, los actores malintencionados pueden aprovecharse de permisos
excesivos, roles huérfanos y muchos otros desplazamientos de la configuración.
Los procedimientos recomendados de Microsoft para bases de datos SQL pueden ayudar a las empresas
a evaluar sus bases de datos SQL, y SQL Database dispone de un servicio integrado de evaluación de
vulnerabilidades que le servirá de ayuda. Una evaluación de vulnerabilidades examina e identifica los
riesgos de seguridad en los niveles de la base de datos y el servidor, y ofrece tareas que permiten
corregir vulnerabilidades.
Una directiva personalizada de Azure garantiza que las bases de datos SQL estén configuradas con la
evaluación de vulnerabilidades. Los exámenes de evaluación se ejecutan periódicamente, los informes se
almacenan en una cuenta de Azure Storage y una dirección de correo electrónico predefinida comparte
los resultados de los informes.
Protección contra la eliminación intencionada o accidental de secretos
Azure Key Vault almacena información confidencial como claves, certificados, contraseñas, etc. Un
usuario malintencionado puede abusar del servicio mediante la eliminación de los secretos que almacena
y un usuario estándar podría eliminar accidentalmente la información confidencial almacenada. Así pues,
sin las disposiciones adecuadas, la eliminación accidental o malintencionada de contenido en Azure Key
Vault puede dañar a la empresa.
La característica de eliminación temporal de Azure Key Vault puede proteger a las empresas frente a
eliminaciones intencionadas o accidentales. Con la eliminación temporal habilitada, las claves
eliminadas se conservan durante un período de tiempo predefinido. Si la operación de eliminación fue
intencionada, el contenido de la clave se puede eliminar hasta que se realice otra operación de purga,
normalmente por parte de alguien con más privilegios de acceso. Si la operación de eliminación fue
accidental, las claves eliminadas se pueden restaurar durante el período de tiempo definido.
Azure ofrece una directiva personalizada para asegurarse de que la eliminación temporal se habilite de
forma predeterminada con Azure Key Vault. Esta directiva proporciona una capa de seguridad adicional si
el contenido de Azure Key Vault se elimina de forma malintencionada y, al mismo tiempo, las empresas
tienen más control si el contenido se elimina accidentalmente.
Aplicación del firewall de aplicaciones web de Azure Application Gateway
Las aplicaciones web que se ejecutan en Azure son objetivos potenciales de los ataques
malintencionados. Los 10 principales riesgos de seguridad de las aplicaciones web como la inyección, el
scripting entre sitios, etc, aprovechan las vulnerabilidades de las aplicaciones web y un ataque con éxito
puede costar a una organización sus recursos y reputación.
El firewall de aplicaciones web de Azure Application Gateway usa Open Web Application Security Project
(OWASP) y Core Rule Set 3.1, 3.0 o 2.2 para proteger las aplicaciones web frente a ataques habituales. Se
puede acceder a las directivas del firewall de aplicaciones web de Application Gateway mediante los
modos Prevención o Detección .
Azure ofrece una directiva personalizada para ayudar a evitar posibles errores de configuración en
Application Gateway. Crea un firewall de aplicaciones web para Application Gateway de forma
predeterminada. Este firewall de aplicaciones web protege las aplicaciones web de Azure mediante
Application Gateway.
Impedir el reenvío de direcciones IP en VM
El reenvío de direcciones IP permite que una máquina virtual de Azure enrute su tráfico hacia otros
destinos. A menos que se requiera expresamente, este enrutamiento puede exponer una máquina virtual
y otras redes no deseadas con una dirección IP pública como enrutador.
Azure proporciona una opción para configurar el reenvío de direcciones IP en máquinas virtuales con
herramientas como firewalls, equilibradores de carga, etc, implementadas a través de Azure Marketplace.
Cualquier aplicación puede usar estos servicios en transacciones de Azure Marketplace.
Fuera de las necesidades específicas, el reenvío de direcciones IP en las máquinas virtuales puede
convertirse en una responsabilidad de seguridad. Azure ofrece una directiva personalizada para evitar
que las máquinas virtuales actúen como enrutadores de reenvío de direcciones IP y esta directiva se
aplica en el ámbito de la zona de aterrizaje. Centrarse en las máquinas virtuales de las zonas de aterrizaje
debe ser el destino final de las solicitudes de los usuarios. Cualquier enrutamiento debe implementarse
en la suscripción de conectividad.
Exigir la administración centralizada de registros DNS
Las zonas privadas de Azure DNS le permitirán crear y administrar registros de DNS para los recursos de
Azure. Sin un control de la proliferación de estas zonas, se pueden producir problemas de depuración de
conectividad de red y administración. En entornos híbridos en los que hay que conectar sitios locales a
recursos de Azure, las zonas DNS fragmentadas pueden generar registros DNS duplicados y provocar
dificultades relacionadas con el mantenimiento.
Las empresas pueden implementar zonas privadas de Azure DNS de forma centralizada para administrar
fácilmente los registros DNS. Azure Virtual Network puede vincularse con zonas privadas para ayudar a
ejecutar controladores de dominio, lo cual puede simplificar la conectividad desde los sitios locales. Los
servicios que admiten puntos de conexión o vínculos privados de Azure pueden usar zonas DNS privadas
administradas centralmente sin necesidad de crearlas durante cada implementación de la aplicación.
Azure ofrece una directiva personalizada que puede impedir la creación de una zona DNS privada en el
ámbito durante el cual se aplica. Las empresas pueden ver el estado de cumplimiento de esta directiva
incluso cuando la aplicación de la directiva está deshabilitada. Esta directiva le ayuda a simplificar la
conectividad entre sitios locales y el acceso a los servicios PaaS de Azure mediante un vínculo o un punto
de conexión privado.
Exigir el control de tráfico de la red
Una red virtual de Azure se puede dividir en varias subredes. Dado que los controles de acceso a la red
entre estas subredes no existen de forma predeterminada, esto puede dar lugar a tráfico de red no
solicitado en una subred.
Los grupos de seguridad de red de Azure ayudan a filtrar el tráfico de subred entrante y saliente, y las
inspecciones de paquetes con estado pueden permitir o denegar el tráfico de red. Los recursos de la
subred pueden recibir tráfico solo de intervalos de direcciones IP permitidos.
Azure ofrece una directiva personalizada que empareja cada subred con un grupo de seguridad de red.
Una combinación de subredes y grupos de seguridad de red garantiza que un conjunto predeterminado
de reglas controle el tráfico hacia una subred y desde esta. En función de sus necesidades, las empresas
también pueden agregar o modificar reglas para controlar aún más el tráfico.
Detección de amenazas y protección frente a ellas mediante Azure Security Center
Una suscripción de Azure puede contener una amplia variedad de recursos como máquinas virtuales,
imágenes de contenedor, etc., y estos recursos se exponen a riesgos como la instalación de software no
deseado o malware, el acceso sin control a los puertos de administración de una máquina virtual, etc.
Con unos ataques de seguridad cada vez más sofisticados y un número limitado de profesionales de
seguridad experimentados, la detección de vulnerabilidades de seguridad y la protección de cargas de
trabajo es muy complicada.
Azure Security Center es un sistema de administración de seguridad nativo de Azure que evalúa la
posición de seguridad de los recursos de Azure en comparación con los procedimientos recomendados
de seguridad. Ayuda a detectar y evitar amenazas contra los datos y los servicios de aplicaciones, y con
varios puntos de integración, se puede implementar rápidamente.
Azure ofrece una directiva personalizada que empareja las suscripciones de Azure con Security Center, lo
que ayuda a las suscripciones a poder utilizar rápidamente las funcionalidades de detección y protección
contra amenazas de Security Center. Esta directiva incluye automáticamente servicios clave de Azure,
como máquinas virtuales, cuentas de almacenamiento y otros siete con Security Center. Las empresas se
benefician de la evaluación continua de la seguridad y las recomendaciones útiles en caso de que se
produzca alguna desviación del procedimiento recomendado de seguridad.
Protección contra ataques de ransomware y pérdida de datos
La frecuencia cada vez mayor de los ataques de ransomware y de intrusión supone otra preocupación
para las empresas. Un ataque de ransomware puede interrumpir las aplicaciones y procesos críticos para
la empresa, y los atacantes pueden mantener a las empresas como rehenes para conseguir una gran
cantidad de dinero.
Azure Backup protege los datos de las máquinas virtuales de Azure frente a la destrucción
malintencionada o accidental. Las copias de seguridad son fáciles de configurar y escalar, y Azure
Recovery Vault hace una copia de seguridad de los datos para una administración y protección sencillas.
Azure ofrece una directiva personalizada que protege Virtual Machines mediante su configuración con
Azure Backup. Esta directiva aprovisiona automáticamente el almacén de Azure Recovery Services y crea
un contenedor de copias de seguridad para cada máquina virtual de Azure que se crea.
Protección contra ataques de denegación de ser vicio distribuido
Los recursos de Azure accesibles públicamente son vulnerables a ataques de denegación de servicio
distribuido (DDoS). Estos ataques pueden afectar a la disponibilidad de una aplicación para sus usuarios
previstos, y los ataques prolongados pueden agotar todos los recursos disponibles y generar tiempo de
inactividad para las aplicaciones críticas para la empresa.
Azure DDoS Protection defiende los recursos de Azure frente a ataques DDoS mediante la supervisión
continua del tráfico entrante para identificar posibles amenazas. Durante un ataque activo, las empresas
pueden beneficiarse de trabajar con el equipo de respuesta rápida de DDoS de Microsoft.
Azure ofrece una directiva personalizada que aprovisiona automáticamente un plan estándar de DDoS de
Azure en todas las suscripciones de Azure de su ámbito. Esta directiva permite a las empresas seleccionar
las regiones de Azure que el servicio abarcará.
Aprovisionamiento automático de vínculo o punto de conexión privado con zonas DNS
privadas
Una dificultad del mantenimiento empresarial es cómo crear zonas DNS privadas para cada aplicación
que necesite acceso a los servicios PaaS de Azure. Azure Private Link y los puntos de conexión privados
usan direcciones IP privadas para proporcionar acceso a los servicios de plataforma como servicio (PaaS)
de Azure, y las zonas DNS privadas resuelven registros DNS. Los grupos de las zonas DNS privadas usan
categorías de servicios de Azure como blobs, colas, tablas, SQL, etc., para agrupar conexiones de Private
Link y usan una zona DNS privada por servicio.
Las empresas también pueden crear zonas DNS privadas centrales y las directivas personalizadas de
Azure pueden conectar automáticamente a Private Link y a los puntos de conexión privados con zonas
DNS privadas para los servicios de Azure.
Administración centralizada de las reglas de firewall
Las reglas de firewall fragmentadas pueden conducir a rutas de acceso de tráfico de red no controladas y
ambiguas. Los cambios continuos en las reglas de firewall para cada instancia de firewall dificultan la
evaluación de la posición de seguridad de la red, y varias reglas dificultan la distinción entre un conjunto
básico de reglas con administración centralizada y las reglas de la ruta de acceso de red específicas de la
carga de trabajo.
Las directivas de Azure Firewall ayudan a las organizaciones a definir un conjunto mínimo de reglas que
se aplican en toda la organización. Las directivas específicas de la aplicación pueden heredar reglas
básicas para crear reglas jerárquicas que cumplan los requisitos de firewall específicos de la aplicación y
la empresa. Cuando las reglas se configuran mediante directivas, se pueden administrar y supervisar de
forma centralizada.
Azure ofrece una directiva personalizada que ayuda a las empresas a definir de forma centralizada las
directivas de Azure Firewall. Las empresas pueden definir las reglas y prioridades para satisfacer sus
requisitos de enrutamiento del tráfico de red. En función de sus necesidades, las empresas pueden definir
las directivas de firewall de forma centralizada y aplicarlas a la topología de red de tipo hub-and-spoke
de Azure Virtual WAN.
Aprovisionamiento de la topología de red en estrella tipo hub-and-spoke
A medida que se empiezan a implementar más cargas de trabajo en Azure, comienzan a usar un conjunto
común de servicios como firewalls, puertas de enlace de VPN, etc. Si no se planea cuidadosamente, los
servicios comunes se pueden replicar en cada implementación de aplicaciones, lo cual crea costos
innecesarios y sobrecarga operativa. En aquellos escenarios en los que se necesita conectividad local
desde Azure y dicha conectividad se establece por cada implementación de la aplicación, la topología de
red es más difícil de mantener.
La topología de red en estrella de tipo hub-and-spoke de Azure ayuda a simplificar las necesidades de
conectividad de red. La red virtual de un centro de conectividad puede hospedar servicios compartidos,
mientras que las redes virtuales radiales pueden hospedar los recursos de Azure específicos de la
aplicación. Las redes virtuales de la topología en estrella de tipo hub-and-spoke usan el emparejamiento
de redes virtuales para conectarse entre sí, y la topología de red promueve un diseño de red simple, una
administración más sencilla y costos optimizados.
Azure ofrece una directiva personalizada que usa Azure Firewall y puertas de enlace de VPN y
ExpressRoute para aprovisionar las redes virtuales del centro de conectividad. Las empresas pueden
configurar todas las opciones de firewalls y puertas de enlace como parte de la asignación de directivas.
Esta directiva simplifica el proceso de implementación de la topología de red en estrella tipo hub-and-
spoke de Azure.
Otra directiva de Azure personalizada impide que dos redes virtuales se emparejen entre sí y, en vez de
eso, se comuniquen mutuamente a través de una red virtual de un centro de conectividad. La
configuración de las redes virtuales para que se comuniquen entre sí a través de centros de conectividad
permite controlar y supervisar las conexiones de red. La topología de red se simplifica también desde la
perspectiva del mantenimiento.
Aprovisionamiento de la configuración predeterminada para Azure Monitor
La incapacidad para identificar y visualizar la relación entre la plataforma de Azure, sus servicios y
aplicaciones puede provocar una interrupción o un rendimiento no detectado y degradado. Los equipos
de operaciones o soporte técnico podrían perder la oportunidad de corregir situaciones específicas y es
posible que una aplicación de Azure no se escale a sí misma para responder a un aumento o una caída de
la demanda.
Los registros de Azure Monitor y las áreas de trabajo de Log Analytics usan alertas para ayudar a las
empresas a comprender y resolver situaciones críticas. Usan paneles, libros y Microsoft Power BI para
ayudar a las empresas a visualizar e interactuar con un sólido conjunto de información de registro. Las
empresas pueden usar los registros de Azure Monitor y las áreas de trabajo de Log Analytics
conjuntamente para configurar el escalado automático de las máquinas virtuales y agregar o quitar
automáticamente instancias adicionales.
Azure ofrece una directiva personalizada para configurar los registros Azure Monitor con áreas de trabajo
de Log Analytics. Esta directiva implementa informes de paneles empaquetados previamente
procedentes de soluciones de Azure Monitor para servicios específicos de Azure como Azure SQL
Database o Azure AD. También configura orígenes de datos de métricas de rendimiento de máquinas
virtuales Linux y Windows con Azure Monitor.
Habilitar el almacenamiento de registros y consultas
Si no se planea cuidadosamente, la información de registro de varios orígenes de Azure puede ser difícil
de administrar, ya que la captura, almacenamiento y administración de registros puede consumir
recursos, tiempo y costos. Por ello, la identificación de tendencias o patrones a lo largo de un período
prolongado de tiempo y de una gran cantidad de registros puede resultar también todo un desafío. Las
consultas de Log Analytics usan alertas e informes interactivos para ayudar a las empresas a almacenar y
administrar registros de varios orígenes de forma eficaz.
Azure ofrece una directiva personalizada que crea un área de trabajo de Log Analytics para que sirva
como repositorio que almacena los registros de datos. Se crea una cuenta de Azure Automation y se
vincula a un área de trabajo de Log Analytics para automatizar las tareas o implementar las soluciones de
Azure Monitor que podrían depender de esas áreas de trabajo. La directiva también ayuda a configurar
los períodos de retención de registros, las regiones de Azure y otras propiedades.
Aprovisionamiento de registros para ser vidores habilitados para Azure Arc
Con departamentos de TI que abarcan varias nubes, sitios locales y ubicaciones perimetrales, las
empresas pueden tener problemas para administrar y controlar los servidores que están dispersos en
diferentes entornos y ubicaciones geográficas. La idea de usar varios productos para supervisar estos
servidores podría ser abrumadora y asignar servidores a varios entornos en una solución unificada de
administración de identidades y acceso puede ser difícil de configurar y administrar.
Azure Arc simplifica la forma en que recursos como servidores, clústeres de Kubernetes y servicios de
datos se rigen y administran de forma heterogénea. Al proyectar recursos híbridos como recursos
nativos de Azure, Azure Arc proporciona un único panel de control para la administración de recursos
nativos e híbridos, lo que aporta tales recursos a una solución unificada de control de acceso basado en
roles.
Azure ofrece dos directivas personalizadas que pueden ayudar a las empresas a configurar agentes de
Log Analytics en servidores de Linux y Windows habilitados para Azure Arc. También se configura un
área de trabajo de Log Analytics para almacenar y administrar registros. Cuando se asigna
correctamente, la directiva identifica el nombre de los servidores de su ámbito y lo asigna a un agente de
Log Analytics.
Aplicación de la recopilación de registros del tráfico de red
Aunque Virtual Network y las subredes proporcionan límites de red privada lógicos, todavía es necesario
supervisar el tráfico de red en Azure. Sin la supervisión adecuada, las redes empresariales son
vulnerables al tráfico malintencionado o desconocido de direcciones IP en peligro. Sin un buen
conocimiento del tráfico actual, puede ser complicado aprovisionar capacidad adicional para aumentar el
tráfico de red.
Azure Network Watcher ayuda a las empresas a supervisar y reparar problemas de red de los servicios
de infraestructura como servicio (IaaS) de Azure. Con este servicio, los registros de flujo de los grupos de
seguridad de red proporcionan una manera de capturar información sobre el tráfico de red. Las
empresas pueden beneficiarse del análisis del tráfico y los patrones, predecir las futuras necesidades de
capacidad y exigir el cumplimiento de las directivas de gobernanza corporativas.
Azure ofrece una directiva personalizada para configurar los registros de flujo de los grupos de seguridad
de red en Network Watcher. Aquí, se aprovisiona una cuenta de almacenamiento como repositorio para
almacenar los registros de flujo de grupos de seguridad de red. Esta directiva también configura el
período de retención para almacenar los registros de flujo de NSG.
Aprovisionamiento de una solución de conectividad de red a escala
Los requisitos de conectividad de red de una empresa pueden ser complejos. Las solicitudes constantes
para agregar nuevos sitios, dispositivos y usuarios a una red en constante expansión son difíciles de
aprovisionar y administrar, y las demandas de ancho de banda y rendimiento de la red desde varios
puntos de contacto de una empresa pueden ser exigentes.
Azure Virtual WAN es un servicio de red de nivel empresarial que ayuda a las organizaciones a resolver
los desafíos de conectividad. El servicio proporciona un mayor rendimiento agregado con conectividad
de red, un enrutamiento óptimo a través de la red troncal de Azure y una experiencia de administración
unificada de Azure.
Azure ofrece una directiva personalizada para configurar Virtual WAN y aprovisionar un centro de
conectividad virtual dentro del servicio. Las empresas pueden implementar centros de conectividad
virtuales para que actúen como punto central de las conexiones de varios orígenes y destinos.
ExpressRoute, las puertas de enlace de VPN y Azure Firewall también se aprovisionan para satisfacer los
requisitos de conectividad de la red.
Copia de seguridad de máquinas vir tuales
A medida que aumenta el grado adopción de la nube, las empresas se enfrentan al desafío de garantizar
que las cargas de trabajo de Azure tengan una copia de seguridad. En modelos de soporte técnico de TI
convencionales en los que la administración del desarrollo de aplicaciones y las operaciones de TI están
en manos de equipos independientes, la propiedad de las copias de seguridad de las máquinas virtuales
puede ser confusa. Si faltan procesos de copia de seguridad se pueden producir también consecuencias
costosas en escenarios previstos o no que necesitan copias de seguridad de máquinas virtuales para
restaurar cargas de trabajo.
Azure Backup proporciona una opción perfecta, sencilla e integrada para realizar copias de seguridad de
máquinas virtuales que se ejecutan en Azure o en sitios locales. Azure Backup usa el almacenamiento a
escala de nube y libera a las empresas de tener que adquirir y administrar constantemente el
almacenamiento necesario para las copias de seguridad. Azure Backup proporciona un repositorio para
almacenar de forma segura los datos en tránsito y en reposo.
Azure ofrece una directiva personalizada que configura automáticamente la protección de copias de
seguridad de Azure para máquinas virtuales Windows y Linux. Un almacén de Azure Recovery Services
está configurado para almacenar copias de seguridad, almacenar datos de forma segura y usar la
eliminación temporal para evitar que las copias de seguridad se eliminen de forma malintencionada.
Asimismo, se crea una directiva de copia de seguridad predeterminada que se asigna con valores
preconfigurados para la programación de copias de seguridad, los períodos de retención, etc.
Aprovisionamiento de la conectividad entre redes vir tuales
Es habitual que las empresas dispersen las cargas de trabajo entre varias suscripciones o redes virtuales.
Sin embargo, las aplicaciones empresariales críticas pueden tener dificultades para intercambiar datos sin
una conectividad de red dedicada y segura. Una conexión de red basada en Internet puede ofrecer un
rendimiento y ancho de banda de red incoherentes, y una latencia de red potencialmente alta puede
afectar negativamente a la experiencia del usuario.
El emparejamiento de red virtual proporciona dos redes virtuales a través de la red troncal de Microsoft.
El emparejamiento de Azure admite una conectividad de red con un ancho de banda alto y baja latencia,
en la que los datos entre suscripciones, inquilinos o regiones de Azure independientes se pueden
intercambiar de forma segura.
Azure ofrece una directiva personalizada que proporciona una plantilla para configurar el
emparejamiento de red virtual. Un diseño de red expresado en la definición de la plantilla de Azure
Resource Manager se puede pasar como un parámetro. Esta directiva pondrá en marcha redes virtuales y
configurará el emparejamiento de redes virtuales entre ellas, además de dependencias como grupos de
seguridad de red, enrutamiento definido por el usuario, etc.
Exigir que las máquinas vir tuales Windows se unan al dominio de Azure AD
Las empresas han estado usando VM unidas a un dominio para obtener una experiencia de
administración coherente. Cuando se crean operaciones como las directivas de contraseñas corporativas,
la autenticación central y otras como parte de las directivas de dominio, una máquina virtual que no se
une al dominio se expone a riesgos como contraseñas débiles y la imposibilidad de conectarse con
dispositivos y aplicaciones corporativos y otras limitaciones. Cuando se implementa en máquinas
virtuales que no están unidas al dominio, las aplicaciones heredadas que se basan en protocolos de
autenticación como Microsoft New Technology LAN Manager o Kerberos podrían tener problemas de
autenticación.
Azure proporciona soluciones administradas y no administradas para implementar servicios de dominio.
Con los servicios de Azure AD DS administrados de forma automática, las empresas obtienen el mismo
control completo de las configuraciones y operaciones que con el entorno local. El servicio libera a las
empresas de la sobrecarga de administración a la vez que proporciona servicios de dominio esenciales.
Azure ofrece una directiva personalizada que ayuda a las nuevas máquinas virtuales Windows a unirse
automáticamente a dominios. La extensión "JsonADDomainExtension" implementada en la máquina
virtual usa valores de configuración como el nombre de usuario, el dominio, OUPath, etc., para
asegurarse de que la máquina virtual se une al dominio especificado. Esta directiva usa Azure KeyVault
para administrar información confidencial, como el nombre de usuario y la contraseña del dominio.
Introducción a la topología de red y la conectividad
En esta serie de artículos se examinan las principales consideraciones de diseño y las recomendaciones en
relación con las redes y la conectividad hacia, desde y dentro de Microsoft Azure.

Para una organización, resulta fundamental planear el direccionamiento IP en Azure a fin de garantizar que no
haya espacios de direcciones IP que se superpongan entre las ubicaciones locales y las regiones de Azure. En
esta sección se proporcionan instrucciones sobre cómo planear el direccionamiento IP para una implementación
híbrida.
Configuración de DNS y la resolución de nombres para los recursos

locales y de Azure
El sistema de nombres de dominio (DNS) es un tema de diseño fundamental en la arquitectura general de
escala empresarial. Es posible que algunas organizaciones deseen usar sus inversiones existentes en DNS. Otros
usuarios podrían ver la adopción de la nube como una oportunidad para modernizar su infraestructura DNS
interna y usar las funcionalidades nativas de Azure. En esta sección se analizan las instrucciones sobre la
planeación de DNS y la resolución de nombres para implementaciones híbridas.

La topología de red es un elemento esencial de la arquitectura de escala empresarial, ya que define el modo en
que las aplicaciones pueden comunicarse entre sí. En esta sección se analizan las tecnologías y las soluciones de
topología para las implementaciones de Azure. Se centra en dos enfoques principales: topologías basadas en
Azure Virtual WAN y topologías tradicionales.
Topología de red de Virtual WAN

En esta sección se explora la opción de implementación de una topología de red de Azure Virtual WAN.

En esta sección se explora la opción de implementación de una topología de redes de Azure tradicional.
Esta sección desarrolla la información sobre la topología de red e incluye los modelos recomendados para
conectar las ubicaciones locales a Azure.

En esta sección se describe cómo integrar Azure Private Link para los servicios de PaaS con zonas de DNS
privado de Azure en las arquitecturas de red en estrella tipo hub-and-spoke.

A partir de lo indicado en las secciones sobre conectividad anteriores, en esta sección se exploran los enfoques
de conectividad recomendados al usar los servicios de PaaS de Azure.
Planeamiento de la conectividad de Internet entrante y saliente

En esta sección se describen los modelos de conectividad recomendados para las conexiones entrantes y
salientes con la red pública de Internet como origen y destino.
Planeamiento para la entrega de aplicaciones

En esta sección se analizan las principales recomendaciones para entregar aplicaciones internas y externas de
una manera segura, muy escalable y con una elevada disponibilidad.
Planeamiento de la segmentación de la red de zona de aterrizaje

En esta sección se analizan las recomendaciones clave para ofrecer una segmentación muy segura de la red
interna en una zona de aterrizaje para impulsar una implementación de red de confianza cero.

En esta sección se analizan las recomendaciones clave para lograr el cifrado de red entre el entorno local y
Azure, así como entre regiones de Azure.

En muchos sectores, las organizaciones requieren que el tráfico en Azure se refleje en un recopilador de
paquetes de red para llevar a cabo una inspección y un análisis en profundidad. Este requisito se suele centrar
en el tráfico entrante y saliente de Internet. En esta sección se describen las principales consideraciones y los
enfoques recomendados para el reflejo o la transmisión del tráfico en Azure Virtual Network.

En esta sección se proporcionan diferentes enfoques de conectividad para integrar una arquitectura de zona de
aterrizaje de escala empresarial de Azure con otros proveedores de nube.
Para una organización, resulta fundamental planear el direccionamiento IP en Azure a fin de garantizar que no
haya espacios de direcciones IP que se superpongan entre las ubicaciones locales y las regiones de Azure.
Los espacios de direcciones IP superpuestos entre las regiones locales y de Azure crearán importantes
desafíos de contención.
Puede agregar un espacio de direcciones después de crear una red virtual. Este proceso requiere una
interrupción, si la red virtual ya está conectada a otra mediante el emparejamiento de red virtual, ya que
el emparejamiento se debe eliminar y volverse a crear.
Azure reserva algunas direcciones IP dentro de cada subred. Céntrese en esas direcciones al cambiar el
tamaño de las redes virtuales y las subredes englobadas.
Algunos servicios de Azure requieren subredes dedicadas. Entre estos servicios se incluyen Azure
Firewall y Azure VPN Gateway.
Puede delegar las subredes a determinados servicios para crear instancias de un servicio dentro de la
subred.
Planee de antemano los espacios de direcciones IP que no se superponen entre las regiones de Azure y
las ubicaciones locales.
Use las direcciones IP de la asignación de direcciones para las redes de Internet privadas (RFC 1918).
En entornos que tienen disponibilidad limitada de direcciones IP privadas (RFC 1918), considere el uso de
IPv6.
No cree redes virtuales innecesariamente grandes (por ejemplo: /16 ) para asegurarse de que el espacio
de direcciones IP no se desperdicie.
No cree redes virtuales sin planear el espacio de direcciones necesario de antemano. Al agregar espacio
de direcciones, se producirá una interrupción una vez que una red virtual se conecte mediante el
emparejamiento de redes virtuales.
No use direcciones IP públicas para las redes virtuales, en especial si no pertenecen a su organización.
DNS para recursos locales y de Azure
El sistema de nombres de dominio (DNS) es un tema de diseño fundamental en la arquitectura general de

escala empresarial. Es posible que algunas organizaciones deseen usar sus inversiones existentes en DNS. Otros
usuarios podrían ver la adopción de la nube como una oportunidad para modernizar su infraestructura DNS
interna y usar las funcionalidades nativas de Azure.
Puede usar la resolución DNS junto con DNS privado de Azure para la resolución de nombres entre
entornos.
Es posible que necesite usar soluciones DNS existentes en el entorno local y en Azure.
Uno es la cantidad máxima de zonas de DNS privado a las que se puede vincular una red virtual con el
registro automático.
Si el registro automático no está habilitado, la cantidad máxima de zonas de DNS privado a las que se
puede vincular una red virtual es de 1000.
En entornos donde solo se necesita la resolución de nombres en Azure, use DNS privado de Azure para la
resolución. Cree una zona delegada para la resolución de nombres (como azure.contoso.com ).
En los entornos en los que se requiera la resolución de nombres entre Azure y el entorno local, use la
infraestructura de DNS existente (por ejemplo, DNS integrado de Active Directory) que haya
implementado en al menos dos máquinas virtuales. Configure DNS en las redes virtuales para usar esos
servidores DNS.
Puede seguir vinculando una zona de DNS privado de Azure a las redes virtuales y usar servidores DNS
como resoluciones híbridas con reenvío condicional a nombres DNS locales, como onprem.contoso.com ,
mediante servidores DNS locales. Puede configurar los servidores locales con reenviadores condicionales
a las máquinas virtuales de resolución en Azure para la zona de DNS privado de Azure (por ejemplo,
azure.contoso.com ).
Las cargas de trabajo especiales que requieren e implementan su propio DNS (como Red Hat OpenShift)
deben usar su solución de DNS preferida.
Habilite el registro automático para que Azure DNS administre automáticamente el ciclo de vida de los
registros DNS de las máquinas virtuales implementadas en una red virtual.
Use una máquina virtual como solucionador para la resolución de DNS entre entornos con DNS privado
de Azure.
Cree una instancia de Azure Private DNS Zones en la suscripción de conectividad global. Puede crear
otras zonas de DNS privado de Azure (por ejemplo, privatelink.database.windows.net o
privatelink.blob.core.windows.net para Azure Private Link).
En este artículo se describe cómo integrar Azure Private Link para los servicios de PaaS con zonas de DNS
privado de Azure en las arquitecturas de red en estrella tipo hub-and-spoke.
Introducción
Muchos clientes crean su infraestructura de red en Azure con la arquitectura de red en estrella tipo hub-and-
spoke, donde:
los servicios compartidos de redes (como las aplicaciones virtuales de red, las puertas de enlace de
ExpressRoute o VPN o los servidores DNS) se implementan en la red virtual de concentrador (VNet);
las redes virtuales radiales consumen esos servicios compartidos mediante el emparejamiento de redes
virtuales.
En las arquitecturas de red en estrella tipo hub-and-spoke, se suele proporcionar a los propietarios de la
aplicación una suscripción a Azure, que incluye una red virtual (radio) conectada a la red virtual de
concentrador. En esta arquitectura, pueden implementar sus máquinas virtuales y tener conectividad privada
con otras redes virtuales o con redes locales mediante ExpressRoute o VPN.
La conectividad saliente a Internet se proporciona mediante una aplicación virtual de red central (NVA) como
Azure Firewall.
Muchos equipos de aplicaciones crean sus soluciones mediante una combinación de recursos de IaaS y PaaS de
Azure. Algunos servicios de PaaS de Azure (como SQL Managed Instance) se pueden implementar en redes
virtuales de cliente. Como resultado, el tráfico seguirá siendo privado en la red de Azure y se podrá redirigir
completamente desde el entorno local.
Sin embargo, algunos servicios de PaaS de Azure (como Azure Storage o Azure Cosmos DB) no se pueden
implementar en las redes virtuales de un cliente y son accesibles mediante su punto de conexión público. En
algunos casos, esto puede provocar un conflicto con las directivas de seguridad de un cliente, ya que es posible
que el tráfico corporativo no permita la implementación de recursos corporativos (como una base de datos
SQL) o el acceso a estos mediante puntos de conexión públicos.
Azure Private Link permite el acceso a una lista de servicios de Azure mediante puntos de conexión privados,
pero requiere que esos registros de puntos de conexión privados estén registrados en una zona DNS
privadacorrespondiente.
En este artículo se describe cómo los equipos de aplicaciones pueden implementar servicios de PaaS de Azure
en sus suscripciones, a las que solo se puede obtener acceso mediante puntos de conexión privados.
En este artículo también se describe cómo los equipos de la aplicación pueden asegurarse de que los servicios
se integren automáticamente con las zonas DNS privadas mediante un DNS privado de Azure: eliminando la
necesidad de crear o eliminar manualmente registros en DNS.
Integración de Private Link y DNS en las arquitecturas de red en

estrella tipo hub-and-spoke
Las zonas de DNS privado se suelen hospedar de forma centralizada en la misma suscripción a Azure en que se
implementa la red virtual del concentrador. Esta práctica de hospedaje central se rige por la resolución de
nombres DNS entre entornos locales y otras necesidades de resolución de DNS central, como Active Directory.
En la mayoría de los casos, solo los administradores de redes o identidades tienen permisos para administrar
registros DNS en esas zonas.
Los equipos de la aplicación tienen permisos para crear recursos de Azure en su propia suscripción. No tienen
permisos en la suscripción de conectividad de red central, lo que incluye la administración de registros DNS en
las zonas DNS privadas. Esta limitación de acceso significa que no tienen la posibilidad de crear los registros
DNS necesarios para implementar los servicios de PaaS de Azure con puntos de conexión privados.
En el diagrama siguiente se muestra una arquitectura de alto nivel típica para entornos empresariales con
resolución de DNS central y donde la resolución de nombres para los recursos de Private Link se realiza
mediante el DNS privado de Azure:
En relación con el diagrama anterior, es importante resaltar que:

Los servidores DNS locales tienen reenviadores condicionales configurados para cada reenviador de zona
DNS pública de punto de conexión privado que apunte a los reenviadores de DNS ( 10.100.2.4 y
10.100.2.5 ) hospedados en la red virtual de concentrador.
Todas las redes virtuales de Azure tienen los reenviadores de DNS ( 10.100.2.4 y 10.100.2.5 ) configurados
como servidores DNS principal y secundario.
Hay dos condiciones que deben cumplirse para permitir a los equipos de la aplicación la libertad de crear los
recursos de PaaS de Azure necesarios en su suscripción:
El equipo de plataforma central o redes centrales debe asegurarse de que los equipos de la aplicación solo
pueden implementar los servicios de PaaS de Azure y acceder a ellos mediante puntos de conexión privados.
Los equipos de plataforma central o redes centrales deben asegurarse de que, cada vez que se crean puntos
de conexión privados, los registros correspondientes se crean automáticamente en la zona DNS privada
centralizada correspondiente al servicio creado.
El registro DNS debe seguir el ciclo de vida del punto de conexión privado y quitar automáticamente
el registro DNS cuando se elimine el punto de conexión privado.
En las secciones siguientes se describe cómo los equipos de la aplicación pueden habilitar estas condiciones
mediante Azure Policy. Usaremos Azure Storage como servicio de Azure que los equipos de aplicaciones
necesitan implementar en el ejemplo siguiente, pero se puede aplicar el mismo principio a la mayoría de los
servicios de Azure que admiten Private Link.
Configuración requerida por el equipo de plataforma

Creación de zonas DNS privadas
Cree zonas DNS privadas en la suscripción de conectividad central para los servicios de Private Link admitidos
según se describe en la documentación.
En nuestro caso, dado que vamos a usar la Cuenta de almacenamiento con blob como ejemplo, esto se
traduce en crear una zona DNS privada privatelink.blob.core.windows.net en la suscripción de conectividad.
Definiciones de directiva
Además de las zonas DNS privadas, también es necesario crear un conjunto de definiciones de Azure Policy
personalizadas para aplicar el uso de puntos de conexión privados y automatizar la creación de registros DNS
en la zona DNS que hemos creado:
1. Denegar el punto de conexión público para la directiva de servicios de PaaS
Esta directiva impedirá que los usuarios creen servicios de PaaS de Azure con puntos de conexión
públicos y les asignarán un mensaje de error si no se selecciona ningún punto de conexión privado al
crear el recurso.
La regla de directiva exacta puede diferir entre servicios de PaaS. En el caso de las cuentas de Azure
Storage, observamos la propiedad networkAcls.defaultAction que define si se permiten o no las
solicitudes de la red pública. En nuestro caso, estableceremos una condición para denegar la creación del
tipo de recurso Microsoft.Storage/storageAccounts si la propiedad networkAcls.defaultAction no
es Deny . Esta definición de directiva se muestra a continuación:
{
"mode": "All",
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
"notequals": "Deny"
}
]
},
"then": {
"effect": "Deny"
}
}
}
2. Denegar la creación de una zona DNS privada con la directiva de prefijo privatelink
Dado que usamos una arquitectura DNS centralizada con un reenviador condicional y zonas DNS
privadas hospedadas en las suscripciones que administra el equipo de la plataforma, es necesario evitar
que los propietarios de los equipos de la aplicación creen sus propias zonas DNS privadas de Private Link
y que vinculen servicios a sus suscripciones.
Para ello, debemos asegurarnos de que, cuando los equipos de la aplicación creen un punto de conexión
privado, la opción de Integrate with private DNS zone se establezca en No si se usa Azure Portal.
Si se selecciona Yes , Azure Policy impedirá la creación del punto de conexión privado. En nuestra
definición de directiva, se denegará la creación del tipo de recurso
Microsoft.Network/privateDnsZones si la zona tiene el prefijo privatelink . Esta definición de
directiva se describe a continuación:
{
"description": "This policy restricts creation of private DNS zones with the `privatelink` prefix",
"displayName": "Deny-PrivateDNSZone-PrivateLink",
"mode": "All",
"parameters": null,
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Network/privateDnsZones"
},
{
"field": "name",
"like": "privatelink*"
}
]
},
"then": {
"effect": "Deny"
}
}
}
3. Directiva DeployIfNotExists para crear automáticamente el registro DNS necesario en la zona DNS
privada central
Esta directiva se desencadenará si se crea un recurso de punto de conexión privado con un identificador
groupId específico del servicio. groupId es el identificador del grupo obtenido del recurso remoto
(servicio) al que se debe conectar este punto de conexión privado. A continuación, desencadenamos una
implementación de privateDNSZoneGroup en el punto de conexión privado, que se usa para asociar el
punto de conexión privado con nuestra zona DNS privada. En nuestro ejemplo, el identificador groupId
para los blobs de Azure Storage es blob (el valor de groupId para otros servicios de Azure se puede
encontrar en este artículo, en la columna Subrecurso ). Cuando la directiva detecta que se ha creado
groupId en el punto de conexión privado, implementa un elemento privateDNSZoneGroup en el punto de
conexión privado y se vincula al identificador de recurso de la zona DNS privada que se especifica como
parámetro. En nuestro ejemplo, el identificador de recurso de la zona DNS privada sería:
/subscriptions/<subscription-
id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net
Esta definición de directiva se muestra a continuación:
{
"mode": "Indexed",
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Network/privateEndpoints"
},
{
"count": {
"field":
"Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]",
"where": {
"field":
"Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]",
"equals": "blob"
}
},
"greaterOrEquals": 1
"greaterOrEquals": 1
}
]
},
"then": {
"effect": "deployIfNotExists",
"details": {
"type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
"roleDefinitionIds": [
"/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
],
"existenceCondition": {
"allOf": [
{
"field":
"Microsoft.Network/privateEndpoints/privateDnsZoneGroups/privateDnsZoneConfigs[*].privateDnsZoneId",
"equals": "[parameters('privateDnsZoneId')]"
}
]
},
"deployment": {
"properties": {
"mode": "incremental",
"template": {
"$schema": "https://schema.management.azure.com/schemas/2019-04-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"privateDnsZoneId": {
"type": "string"
},
"privateEndpointName": {
"type": "string"
},
"location": {
"type": "string"
}
},
"resources": [
{
"name": "[concat(parameters('privateEndpointName'), '/deployedByPolicy')]",
"type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
"apiVersion": "2020-03-01",
"location": "[parameters('location')]",
"properties": {
"privateDnsZoneConfigs": [
{
"name": "storageBlob-privateDnsZone",
"properties": {
"privateDnsZoneId": "[parameters('privateDnsZoneId')]"
}
}
]
}
}
]
},
"parameters": {
"value": "[parameters('privateDnsZoneId')]"
},
"privateEndpointName": {
"value": "[field('name')]"
},
"location": {
"value": "[field('location')]"
}
}
}
}
}
}
}
},
"parameters": {
"type": "String",
"metadata": {
"displayName": "privateDnsZoneId",
"strongType": "Microsoft.Network/privateDnsZones"
}
}
}
}
Asignaciones de directivas
Una vez implementadas las definiciones de directiva, asigne las directivas en el ámbito deseado de la jerarquía
del grupo de administración. Asegúrese de que las asignaciones de la directiva tienen como destino las
suscripciones de Azure que usarán los equipos de la aplicación para implementar servicios de PaaS con acceso
de punto de conexión privado exclusivamente.
IMPORTANT
Recuerde asignar el rol de Colaborador de zona de DNS privada en la suscripción o el grupo de recursos en que estén
hospedadas las zonas DNS privadas a la identidad administrada creada por la asignación de directiva
DeployIfNotExists que será responsable de crear y administrar el registro DNS del punto de conexión privado en la
zona DNS privada. Esto se debe a que el punto de conexión privado se encuentra en la suscripción de Azure del
propietario de la aplicación, mientras que la zona DNS privada se encuentra en una suscripción diferente (como una
suscripción de conectividad central).
Una vez que el equipo de la plataforma termina esta configuración, las suscripciones a Azure de los equipos de
aplicaciones están listas para que creen los servicios de PaaS de Azure con acceso de punto de conexión privado
exclusivamente y se aseguren de que los registros DNS para los puntos de conexión privados se registran
automáticamente (y se quiten cuando se elimine el punto de conexión privado) en las zonas DNS privadas
correspondientes.
Experiencia del propietario de la aplicación

Una vez que el equipo de la plataforma ha implementado los componentes de la infraestructura de la
plataforma (zonas y directivas DNS privadas) descritos en la sección anterior, cuando un propietario de la
aplicación intente implementar un servicio de PaaS de Azure en la suscripción a Azure, el propietario de la
aplicación tendrá la siguiente experiencia, que será la misma si realiza actividades mediante Azure Portal u otros
clientes, como PowerShell o la CLI, ya que sus suscripciones se rigen por las directivas de Azure.
1. Cree una cuenta de almacenamiento desde Azure Portal. En la pestaña Aspectos básicos, proporcione un
nombre y la configuración que quiera y haga clic en Siguiente .
2. En la sección Redes, asegúrese de que está seleccionada la opción Punto de conexión privado . Si se
selecciona una opción distinta de Punto de conexión privado , Azure Portal no permitirá la creación de
la cuenta de almacenamiento en la sección Revisar y crear del Asistente para la implementación, ya que
la directiva impide la creación de este servicio si está habilitado el punto de conexión público.
3. Es posible crear el punto de conexión privado en esta pantalla o también puede hacerlo después de crear
la cuenta de almacenamiento. En este ejercicio, crearemos el punto de conexión privado una vez creada la
cuenta de almacenamiento. Haga clic en Revisar y crear y complete la creación de la cuenta de
almacenamiento.
4. Una vez creada la cuenta de almacenamiento, cree un punto de conexión privado desde Azure Portal.
5. En la sección Recurso , busque la cuenta de almacenamiento creada en el paso anterior y, para el
subrecurso de destino, seleccione Blob y, a continuación, Siguiente .
6. En la sección Configuración , después de seleccionar la red virtual y la subred, asegúrese de que la

opción Integrar con la zona DNS privada esté establecida en No . De lo contrario, Azure Portal
impedirá la creación del punto de conexión privado, ya que Azure Policy no permitirá la creación de una
zona DNS privada con el prefijo privatelink .
7. Seleccione Revisar y crear y, después, seleccione Crear para implementar el punto de conexión
privado.
8. Después de unos minutos, se desencadenará la directiva DeployIfNotExists y la implementación de
dnsZoneGroup posterior agregará los registros DNS necesarios para el punto de conexión privado en la
zona DNS administrada centralmente.
9. Una vez creado el punto de conexión privado, selecciónelo y revise su FQDN y dirección IP privada:
10. Consulte el registro de actividad del grupo de recursos en el que se creó el punto de conexión privado.
También puede consultar el registro de actividad del propio punto de conexión privado. Observará que,
después de unos minutos, se ejecuta una acción de directiva DeployIfNotExist que configura el grupo de
zona DNS en el punto de conexión privado:
11. Si el equipo de redes central va a la zona DNS privada privatelink.blob.core.windows.net , confirmará
que se ha creado el registro DNS para el punto de conexión privado que hemos creado y que el nombre y
la dirección IP coinciden con los valores del punto de conexión privado.
En este punto, los equipos de la aplicación pueden usar la cuenta de almacenamiento mediante un punto de
conexión privado desde cualquier red virtual del entorno de red en estrella tipo hub-and-spoke y desde el
entorno local, ya que el registro DNS se ha registrado automáticamente en la zona DNS privada.
Si el propietario de una aplicación elimina el punto de conexión privado, se quitarán automáticamente los
registros correspondientes de la zona DNS privada.
La topología de red es un elemento esencial de la arquitectura de escala empresarial, ya que define el modo en
que las aplicaciones pueden comunicarse entre sí. En esta sección se analizan las tecnologías y las soluciones de
topología para las implementaciones de Azure. Se centra en dos enfoques principales: topologías basadas en
Azure Virtual WAN y topologías tradicionales.
Virtual WAN se usa para cumplir los requisitos de interconectividad a gran escala. Dado que se trata de un
servicio administrado por Microsoft, también reduce la complejidad general de la red y ayuda a modernizar la
red de la organización. Una topología de Virtual WAN puede ser más adecuada si alguno de los siguientes
puntos se ajusta a sus requisitos:
Su organización tiene previsto implementar recursos en varias regiones de Azure y requiere conectividad
global entre redes virtuales en estas regiones de Azure y varias ubicaciones locales.
La organización tiene la intención de integrar una red de sucursales a gran escala directamente en Azure a
través de una implementación de WAN (SD-WAN) definida por software o requiere más de 30 sitios de
sucursal para la terminación de IPsec nativa.
Requiere enrutamiento transitivo entre VPN y ExpressRoute. Por ejemplo, las sucursales remotas conectadas
mediante VPN de sitio a sitio o los usuarios remotos conectados mediante VPN de punto a sitio requieren
conectividad con un controlador de dominio conectado de ExpressRoute a través de Azure.
Una topología de red en estrella tipo hub-and-spoke tradicional le ayuda a crear redes seguras personalizadas a
gran escala en Azure en las que el cliente administra el enrutamiento y la seguridad. Una topología tradicional
puede ser más adecuada si alguno de los siguientes puntos se ajusta a sus requisitos:
Su organización piensa implementar recursos en una o varias regiones de Azure y, aunque es previsible
cierto tráfico entre regiones de Azure (por ejemplo, tráfico entre dos redes virtuales de dos regiones
diferentes de Azure), no se requiere una red de malla completa en todas las regiones de Azure.
Tiene un número reducido de ubicaciones remotas o sucursales por región. Es decir, necesita menos de
30 túneles de sitio a sitio IPsec.
Necesita control total y granularidad para configurar manualmente la directiva de enrutamiento de red de
Azure.
Topología de red de Virtual WAN (administrada por Microsoft)

Figura 1: Topología de red de Virtual WAN.
Figura 2: Topología tradicional de red de Azure.

Topología de red de Virtual WAN (administrada por
Microsoft)
Explore las principales recomendaciones y consideraciones de diseño en relación con las redes virtuales de área
extensa (Virtual WAN) en Microsoft Azure.
Figura 1: Topología de red de Virtual WAN.

Azure Virtual WAN es una solución administrada por Microsoft en la que se proporciona conectividad de
tránsito global, dinámica y de un extremo a otro de forma predeterminada. Los concentradores de Virtual
WAN eliminan la necesidad de configurar manualmente la conectividad de red. Por ejemplo, no tiene que
administrar las rutas definidas por el usuario (UDR) ni las aplicaciones virtuales de red (NVA) para
habilitar la conectividad de tránsito global.
Virtual WAN simplifica la conectividad de red de un extremo a otro en Azure y la conectividad con Azure
desde entornos locales mediante la creación de una arquitectura de red tipo hub-and-spoke. La
arquitectura se puede escalar fácilmente para que admita varias regiones de Azure y ubicaciones locales
(conectividad universal), tal como se muestra en la siguiente figura:
Figura 2: Red de tránsito global con Virtual WAN.
La conectividad transitiva universal de Virtual WAN admite las siguientes rutas de acceso (dentro de la
misma región y entre regiones):
De red virtual a red virtual
De red virtual a rama
De rama a red virtual
De rama a rama
Los centros de conectividad de Virtual WAN están restringidos a la implementación de los recursos
administrados por Microsoft. Los únicos recursos que puede implementar dentro de ellos son puertas de
enlace de red virtual (VPN de punto a sitio, VPN de sitio a sitio y Azure ExpressRoute), Azure Firewall a
través de Firewall Manager, tablas de rutas y algunas aplicaciones virtuales de red (NVA) para
funcionalidades de SD-WAN específicas de proveedores.
Se aplican a Virtual WAN algunos límites de suscripción de Azure para Virtual WAN.
La conectividad transitiva de red a red (dentro de una región y entre regiones desde un centro de
conectividad a otro) se encuentra disponible ahora con carácter general (GA).
La conectividad de tránsito entre las redes virtuales de Virtual WAN estándar se habilita debido a la
presencia de una función de enrutamiento administrada por Microsoft en cada centro de conectividad
virtual. Cada centro de conectividad admite un rendimiento agregado de hasta 50 Gbps para el tráfico de
red virtual a red virtual.
Un centro de conectividad de Azure puede admitir un número máximo específico de cargas de trabajo de
máquina virtual en todas las redes virtuales conectadas directamente. Esta información se documenta en
el artículo sobre los límites de Azure Virtual WAN.
Virtual WAN se integra con varios proveedores de SD-WAN.
Muchos proveedores de servicios administrados ofrecen servicios administrados para Virtual WAN.
Las puertas de enlace (de punto a sitio) de la VPN de usuario de Virtual WAN se pueden escalar hasta
20 Gbps de rendimiento agregado y 10 000 conexiones de cliente por cada centro de conectividad
virtual.
Las puertas de enlace de VPN de sitio a sitio en Virtual WAN pueden escalarse hasta un rendimiento
agregado de 20 Gbps.
Los circuitos de ExpressRoute que usan una SKU local, estándar o prémium se pueden conectar a un
concentrador de Virtual WAN.
Los circuitos Estándar o Premium de ExpressRoute que se encuentran en las ubicaciones compatibles con
ExpressRoute Global Reach se pueden conectar a una puerta de enlace Virtual WAN ExpressRoute y
pueden disfrutar de todas las funcionalidades de tránsito de Virtual WAN (tránsito de VPN a VPN, de VPN
y de ExpressRoute). Los circuitos estándar o prémium de ExpressRoute que se encuentren en ubicaciones
que no sean compatibles con Global Reach pueden conectarse a los recursos de Azure, pero no podrán
usar las funcionalidades de tránsito de Virtual WAN.
ExpressRoute local es compatible con los concentradores de conectividad de Azure Virtual WAN si las
redes virtuales de radio conectadas a un concentrador de Virtual WAN están en la misma región que
este.
Azure Firewall Manager, ahora con disponibilidad general, permite implementar Azure Firewall en el
centro de conectividad de Virtual WAN. Revise la información general de Azure Firewall Manager para
obtener información general sobre los centros virtuales protegidos y las restricciones más recientes.
Actualmente no se admite el tráfico de un centro de conectividad a otro de Virtual WAN a través de Azure
Firewall si la instancia de Azure Firewall está implementada en el propio concentrador de Virtual WAN
(centro virtual protegido). Existen varias soluciones alternativas en función de sus requisitos, entre las
que se incluyen la colocación de Azure Firewall en una red virtual en estrella tipo hub-and-spoke o el uso
de grupos de seguridad de red para el filtrado del tráfico.
Se recomienda usar Virtual WAN para nuevas implementaciones de redes grandes o globales en Azure,
siempre que requiera conectividad de tránsito global entre regiones de Azure y ubicaciones locales. De
este modo, no tendrá que configurar manualmente el enrutamiento transitivo para las redes de Azure.
En la siguiente figura se muestra una implementación empresarial global de ejemplo con centros datos
distribuidos en Europa y Estados Unidos. La implementación también tiene muchas sucursales en ambas
regiones. El entorno está conectado de forma global a través de Azure Virtual WAN y Global Reach de
ExpressRoute.
Figura 3: Ejemplo de topología de red.

Use un centro de conectividad de Virtual WAN en cada región de Azure para conectar varias zonas de
aterrizaje entre las regiones de Azure mediante una instancia común global de Azure Virtual WAN.
Use características de enrutamiento de centros de conectividad virtuales para segmentar aún más el
tráfico entre redes virtuales y sucursales.
Conecte los centros de conectividad de Virtual WAN a los centros de datos locales mediante
ExpressRoute.
Implemente los servicios compartidos necesarios, como los servidores DNS, en una red virtual en
estrella tipo hub-and-spoke dedicada. Los recursos compartidos implementados por el cliente no se
pueden implementar en el propio centro de conectividad de Virtual WAN.
Conecte las ubicaciones remotas y sucursales al centro de conectividad de Virtual WAN más cercano a
través de una VPN de sitio a sitio, o bien habilite la conectividad de rama a Virtual WAN a través de una
solución de partner SD-WAN.
Conecte los usuarios al centro de conectividad de Virtual WAN mediante una VPN de punto a sitio.
Siga el principio de "el tráfico de Azure permanece en Azure" para que la comunicación entre los recursos
de Azure se produzca mediante la red troncal de Microsoft, incluso si los recursos se encuentran en
regiones diferentes.
Para la protección y el filtrado de salida de Internet, considere la posibilidad de implementar Azure
Firewall en el centro de conectividad virtual.
Si las aplicaciones virtuales de red de los asociados son necesarias para la protección y filtrado del tráfico
horizontal de derecha a izquierda y vertical de arriba abajo, y dado que Azure Virtual WAN no permite la
implementación de esas aplicaciones en el centro de conectividad virtual, evalúe si la implementación de
esas aplicaciones en una red en estrella tipo hub-and-spoke independiente y la configuración del
enrutamiento estático como se describe aquí le ayudaría a cumplir con sus requisitos. Como alternativa,
considere la posibilidad de usar una topología de red tradicional basada en el modelo en estrella de tipo
hub-and-spoke, ya que las aplicaciones virtuales de red de los asociados se pueden implementar en la
red virtual de un centro de conectividad normal.
Al implementar las tecnologías de red y los dispositivos virtuales de red de los asociados, siga las
instrucciones de su proveedor para asegurarse de que no haya configuraciones en conflicto con las redes
de Azure.
Para ver los escenarios heredados en los que va a migrar de una topología de red en estrella tipo hub-
and-spoke que no se basa en Virtual WAN, consulte Migración a Azure Virtual WAN.
Cree los recursos de Azure Virtual WAN y Azure Firewall dentro de la suscripción de conectividad.
No cree más de 500 conexiones de red virtual por cada centro de conectividad virtual Virtual WAN.
Planee la implementación meticulosamente y asegúrese de que la arquitectura de la red está dentro de
los límites de Azure Virtual WAN.
Use las conclusiones de Azure Monitor para Virtual WAN (versión preliminar) para supervisar la
topología de un extremo a otro de la instancia de Virtual WAN, así como el estado y las métricas clave.
Explore las consideraciones y las recomendaciones claves en el diseño de las topologías de red en Microsoft
Azure.
Figura 1: Topología tradicional de red de Azure.

Varias topologías de red pueden conectar varias redes virtuales de zona de aterrizaje. Algunos ejemplos
son una red virtual plana grande, varias redes virtuales conectadas con varias conexiones o circuitos
ExpressRoute, y las redes radiales, de malla completa e híbridas.
Las redes virtuales no pueden atravesar los límites de la suscripción. Sin embargo, puede lograr la
conectividad entre las redes virtuales en suscripciones diferentes mediante el emparejamiento de redes
virtuales, un circuito ExpressRoute o puertas de enlace VPN.
El emparejamiento de red virtual es el método preferido para conectar redes virtuales en Azure. Puede
usar el emparejamiento de redes virtuales para conectarlas en la misma región, a través de regiones de
Azure diferentes y en distintos inquilinos de Azure Active Directory (Azure AD).
El emparejamiento de red virtual y el emparejamiento de red virtual global no son transitivos. Se
necesitan rutas definidas por el usuario (UDR) y aplicaciones virtuales de red (NVA) para habilitar una red
de tránsito. Para más información, consulte topología de red en estrella tipo hub-and-spoke en Azure.
Puede usar circuitos ExpressRoute para establecer la conexión entre redes virtuales dentro de la misma
región geopolítica o mediante el complemento prémium para la conectividad entre regiones geopolíticas.
Tenga en cuenta los siguientes puntos:
El tráfico de red a red puede experimentar más latencia porque debe conectarse en los
enrutadores de Microsoft Enterprise Edge (MSEE).
El ancho de banda se limitará a la SKU de puerta de enlace de ExpressRoute.
Sigue teniendo que implementar y administrar enrutamientos definidos por el usuario si
requieren la inspección o el registro del tráfico entre redes virtuales.
Las puertas de enlace VPN con Protocolo de puerta de enlace de borde (BGP) son transitivas dentro de
Azure y en el entorno local, pero no proporcionan acceso transitivo a redes conectadas mediante
ExpressRoute.
Cuando haya varios circuitos ExpressRoute conectados a la misma red virtual, use pesos de conexión y
técnicas de BGP para garantizar una ruta de acceso óptima para el tráfico entre el entorno local y Azure.
Para obtener más información, consulte Optimización del enrutamiento de ExpressRoute.
El uso de métricas de BGP para influir en el enrutamiento de ExpressRoute es un cambio de configuración
hecho fuera de la plataforma de Azure. Por lo tanto, la organización o el proveedor de conectividad deben
configurar sus enrutadores locales según corresponda.
Los circuitos ExpressRoute con complementos prémium proporcionan conectividad global.
ExpressRoute está sujeto a ciertos límites, como el número máximo de conexiones de ExpressRoute por
puerta de enlace, o el número máximo de rutas que se pueden anunciar desde Azure en el entorno local a
través del emparejamiento privado de ExpressRoute. Estos límites se documentan en el artículo sobre los
límites de ExpressRoute.
El rendimiento máximo en total de una puerta de enlace VPN es de 10 Gbps. Admite hasta 30 túneles de
sitio a sitio o de red a red.
Se debe tener en cuenta un diseño de red basado en la topología tradicional de red tipo hub-and-spoke
para los siguientes escenarios:
Una arquitectura de red implementada dentro de una única región de Azure.
Una arquitectura de red que abarca varias regiones de Azure y en la que no es necesaria la
conectividad transitiva entre las redes virtuales de las zonas de aterrizaje de varias regiones.
Una arquitectura de red que abarca varias regiones de Azure en la que se puede usar el
emparejamiento de red virtual global para conectar redes virtuales entre regiones de Azure.
No es necesario disponer de conectividad transitiva entre las conexiones VPN y ExpressRoute.
El principal método de conectividad híbrida en vigor es ExpressRoute y el número de conexiones
VPN es inferior a 30 por cada puerta de enlace VPN.
Existe una dependencia en los dispositivos virtuales de red centralizados y en el enrutamiento
pormenorizado.
En el caso de las implementaciones regionales, use principalmente la topología de tipo hub and spoke.
Use redes virtuales de zona de aterrizaje que se conecten con el emparejamiento de redes virtuales a una
red virtual de centro de conectividad central para la conectividad entre entornos locales a través de
ExpressRoute, VPN para la conectividad de sucursales, conectividad entre radios mediante NVA y rutas
definidas por el usuario, y protección frente a conexiones salientes a Internet mediante Azure Firewall u
otras VNA de terceros. En la siguiente figura se muestra esta topología. Esta permite un control de tráfico
adecuado que cumple la mayoría de los requisitos de segmentación e inspección.
Figura 2: Topología de red en estrella tipo hub-and-spoke.
Use la topología de varias redes virtuales conectadas con varios circuitos ExpressRoute cuando se cumpla
una de estas condiciones:
Necesita un alto nivel de aislamiento.
Necesita un ancho de banda de ExpressRoute dedicado para unidades de negocio específicas.
Ha alcanzado el número máximo de conexiones por puerta de enlace de ExpressRoute (consulte el
artículo sobre los límites de ExpressRoute para conocer este número máximo).
En la siguiente figura se muestra esta topología.
Figura 3: Varias redes virtuales conectadas con varios circuitos ExpressRoute.

Implemente un conjunto de servicios compartidos mínimos, incluidas las puertas de enlace
ExpressRoute, las puertas de enlace VPN (según sea necesario) y Azure Firewall o los dispositivos
virtuales de red de asociados (según sea necesario) en la red virtual del centro de conectividad central. Si
es necesario, implemente también controladores de dominio de Active Directory y servidores DNS.
Implemente Azure Firewall o dispositivos virtuales de red de asociados para la protección y filtrado del
tráfico este-oeste o sur-norte en la red virtual del centro de conectividad central.
Cuando vaya a implementar tecnologías de red o dispositivos virtuales de red de asociados, siga las
instrucciones del proveedor del asociado para asegurarse de que:
El proveedor admite la implementación.
La guía está diseñada para lograr una alta disponibilidad y un rendimiento máximo.
No hay configuraciones en conflicto con las redes de Azure.
No implemente las NVA de entrada de nivel 7, como Azure Application Gateway, como un servicio
compartido en la red virtual del centro de conectividad central. En su lugar, impleméntelos junto con la
aplicación en sus respectivas zonas de aterrizaje.
Use sus redes existentes, MPLS y SD-WAN, para conectar las ubicaciones de las sucursales con las
oficinas centrales de la empresa. No se admite el tránsito en Azure entre ExpressRoute y las puertas de
enlace VPN.
En el caso de las arquitecturas de red con varias topologías de red tipo hub-and-spoke en regiones de
Azure, use el emparejamiento de red virtual global para conectar redes virtuales de zona de aterrizaje
cuando sea necesario comunicar entre regiones un pequeño número de zonas de aterrizaje. Este enfoque
ofrece ventajas como el ancho de banda de red elevado con el emparejamiento global de redes virtuales,
tal y como lo permite la SKU de la máquina virtual. Sin embargo, se omitirá la NVA central, en caso de
que se requiera la inspección o el filtrado del tráfico. Esto también está sujeto a las limitaciones del
emparejamiento de las redes virtuales globales.
Cuando implemente la arquitectura de red tipo hub-and-spoke en dos regiones de Azure y requiera
conectividad de tránsito entre todas las zonas de aterrizaje a través de las regiones, use ExpressRoute con
circuitos dobles para proporcionar conectividad de tránsito a las redes virtuales de zona de aterrizaje de
las regiones de Azure. En este escenario, las zonas de aterrizaje pueden transitar dentro de una región a
través de NVA en la red virtual del centro de conectividad y entre regiones a través de un circuito
ExpressRoute. El tráfico debe conectarse a los enrutadores MSEE. En la siguiente figura se muestra este
diseño.
Figura 4: Diseño de conectividad de las zonas de aterrizaje.

Cuando en una organización se requieran arquitecturas de red tipo hub-and-spoke en más de dos
regiones de Azure además de conectividad de tránsito global entre las zonas de aterrizaje, entre esas
regiones de Azure se precisa el uso de redes virtuales. Para implementar esta arquitectura, puede
interconectar las redes virtuales del centro de conectividad central con el emparejamiento de red virtual
global, mediante el uso de enrutamiento definido por el usuario y dispositivos virtuales de red, a fin de
habilitar el enrutamiento de tránsito global. Dado que la complejidad y la sobrecarga de administración
son altas, se recomienda evaluar una arquitectura de red de tránsito global con Virtual WAN.
Use Azure Monitor para redes (versión preliminar) para supervisar el estado global de las redes en Azure.
Al conectar redes virtuales de radio con la red virtual del centro de conectividad, es necesario tener en
cuenta dos límites:
El número máximo de conexiones de emparejamiento de red virtual por red virtual.
El número máximo de prefijos anunciados desde Azure al entorno local mediante ExpressRoute con
emparejamiento privado.
Asegúrese de que el número de redes virtuales en estrella tipo hub-and-spoke conectadas a la red virtual
del centro de conectividad no supere ninguno de esos límites.
Esta sección desarrolla la información sobre la topología de red e incluye los modelos recomendados para
conectar las ubicaciones locales a Azure.
Azure ExpressRoute proporciona conectividad privada dedicada para la funcionalidad de infraestructura
como servicio (IaaS) y plataforma como servicio (PaaS) de Azure desde ubicaciones locales.
Puede usar Private Link para establecer las conexiones con los servicios PaaS a través de ExpressRoute
mediante el emparejamiento privado.
Cuando varias redes virtuales estén conectadas al mismo circuito ExpressRoute, se convierten en parte
del mismo dominio de enrutamiento y todas las redes virtuales comparten el ancho de banda.
Puede usar Global Reach de ExpressRoute, si está disponible, en el caso de que desee conectarse a
ubicaciones locales mediante circuitos ExpressRoute para enviar el tráfico a través de la red troncal de
Microsoft.
Global Reach de ExpressRoute está disponible en muchas ubicaciones de emparejamiento de
ExpressRoute.
ExpressRoute Direct permite la creación de varios circuitos ExpressRoute sin costo adicional, hasta la
capacidad del puerto ExpressRoute Direct (10 Gbps o 100 Gbps). También permite conectarse
directamente a los enrutadores ExpressRoute de Microsoft. En el caso de la SKU de 100 Gbps, el ancho de
banda mínimo del circuito es de 5 Gbps. En el caso de la SKU de 10 Gbps, el ancho de banda mínimo del
circuito es de 1 Gbps.
use ExpressRoute como canal de conectividad principal para conectar una red local a Azure. Puede usar
VPN como origen de la conectividad de respaldo para mejorar la resistencia de la conectividad.
Use los circuitos ExpressRoute dobles de diferentes ubicaciones de emparejamiento al conectar una
ubicación local a las redes virtuales en Azure. Esta configuración garantizará las rutas de acceso
redundantes a Azure, al eliminar los puntos únicos de error entre el entorno local y Azure.
Cuando use varios circuitos ExpressRoute, optimice el enrutamiento de ExpressRoute a través de la
preferencia local de BGP y anteponiendo AS PATH.
Asegúrese de usar la SKU adecuada para las puertas de enlace de ExpressRoute o VPN en función de los
requisitos de ancho de banda y rendimiento.
Implemente una puerta de enlace de ExpressRoute con redundancia de zona en las regiones de Azure
admitidas.
Para los escenarios que requieren un ancho de banda superior a 10 Gbps o puertos de 10/100 Gbps
dedicados, use ExpressRoute Direct.
Cuando se requiere una latencia baja o el rendimiento del entorno local a Azure debe ser superior a
10 Gbps, debe habilitar FastPath para omitir la puerta de enlace de ExpressRoute en la ruta de acceso de
datos.
Use puertas de enlace de VPN para conectar sucursales o ubicaciones remotas a Azure. Para una mayor
resistencia, implemente puertas de enlace con redundancia de zona (cuando está disponible).
Use Global Reach de ExpressRoute para conectar oficinas grandes, sedes regionales o centros de datos
conectados a Azure a través de ExpressRoute.
Cuando se requiera el aislamiento del tráfico o el ancho de banda dedicado, por ejemplo, para separar los
entornos, tanto los que están en producción como los que no, use circuitos ExpressRoute diferentes. Le
ayudará a asegurarse de que los dominios de enrutamiento estén aislados y a aliviar el riesgo de sufrir
entornos ruidosos.
Supervise de forma proactiva los circuitos ExpressRoute con Network Performance Monitor.
No use explícitamente circuitos ExpressRoute desde una sola ubicación de emparejamiento. De esta
forma, se crea un único punto de error y la organización es vulnerable a las interrupciones en la
ubicación del emparejamiento.
A partir de lo indicado en las secciones sobre conectividad anteriores, en esta sección se explorarán las
soluciones de conectividad recomendadas al usar los servicios PaaS de Azure.
Normalmente, se accede a los servicios PaaS de Azure a través de puntos de conexión públicos. Sin
embargo, la plataforma Azure ofrece funcionalidades para proteger dichos puntos de conexión o incluso
hacerlos totalmente privados:
La inserción de red virtual proporciona implementaciones privadas dedicadas para los servicios
compatibles. El tráfico del plano de administración sigue fluyendo mediante direcciones IP
públicas.
Private Link proporciona un acceso dedicado mediante direcciones IP privadas a instancias de
PaaS de Azure o a servicios personalizados detrás de Azure Load Balancer de nivel estándar.
Los puntos de conexión del servicio de red virtual proporcionan acceso de nivel de servicio de las
subredes seleccionadas a los servicios PaaS seleccionados.
A menudo, a las empresas les preocupan los puntos de conexión públicos para los servicios PaaS que
deben mitigarse de forma adecuada.
En el caso de los servicios admitidos, Private Link soluciona los problemas de la filtración de datos
asociados con los puntos de conexión de servicio. También puede usar el filtrado de salida a través de los
dispositivos virtuales de red para proporcionar pasos que mitiguen la filtración de datos.
Use la inserción de red virtual para los servicios de Azure compatibles, a fin de hacer que estén
disponibles desde la red virtual.
Los servicios PaaS de Azure que se han insertado en una red virtual aún realizan operaciones del plano
de administración mediante direcciones IP públicas. Asegúrese de que esta comunicación esté bloqueada
dentro de la red virtual con enrutamientos definidos por el usuario y grupos de seguridad de red.
Use Private Link, si está disponible, para los servicios PaaS de Azure compartidos. Private Link está
disponible con carácter general para varios servicios y está en versión preliminar pública para muchos
otros.
Acceda a los servicios PaaS de Azure desde el entorno local a través del emparejamiento privado de
ExpressRoute. Use la inserción de red virtual para los servicios de Azure dedicados o bien Azure Private
Link para los servicios de Azure compartidos disponibles. Para acceder a los servicios PaaS de Azure
desde el entorno local cuando no esté disponible la inserción de red virtual o Private Link, use
ExpressRoute con el emparejamiento de Microsoft. Este método evita el tránsito a través de la red pública
de Internet.
Use puntos de conexión del servicio de red virtual para proteger el acceso a los servicios PaaS de Azure
desde la red virtual, pero solo cuando Private Link no esté disponible y no se produzcan problemas de
filtración de datos. Para solucionar los problemas de filtración de datos con los puntos de conexión de
servicio, use el filtrado de dispositivos virtuales de red o las directivas de punto de conexión de servicio
de red virtual para Azure Storage.
No habilite los puntos de conexión del servicio de red virtual de forma predeterminada en todas las
subredes.
No use puntos de conexión de servicio de red virtual cuando haya problemas de filtración de datos, a
menos que use el filtrado de dispositivos virtuales de red.
No se recomienda implementar la tunelización forzada para habilitar la comunicación de Azure a los
recursos de Azure.
Planeamiento de la conectividad de Internet
entrante y saliente
En esta sección se describen los modelos de conectividad recomendados para las conexiones entrantes y
salientes con la red pública de Internet como origen y destino.
Los servicios de seguridad de red nativos de Azure como Azure Firewall, Azure Web Application Firewall
(WAF) en Azure Application Gateway y Azure Front Door son servicios totalmente administrados. Por lo
tanto, no se incurre en los costos operativos y de administración asociados a las implementaciones de
infraestructura, lo que puede resultar complejo a escala.
La arquitectura de escala empresarial es totalmente compatible con los dispositivos virtuales de red de
asociados, en caso de que su organización los prefiera, o bien en situaciones en las que los servicios
nativos no satisfagan los requisitos específicos de su organización.
Use las etiquetas de Azure Firewall para controlar:
El tráfico saliente de Azure a Internet.
Las conexiones entrantes que no son de HTTP/S.
El filtrado del tráfico este-oeste (si lo requiere su organización).
Use Firewall Manager con Virtual WAN para implementar y administrar firewalls de Azure en centros de
conectividad de Virtual WAN o redes virtuales de centro de conectividad. Firewall Manager está
disponible actualmente con disponibilidad general para Virtual WAN y para las redes virtuales normales.
Cree una directiva de Azure Firewall global para controlar la postura de seguridad en todo el entorno de
red global y asígnela a todas las instancias de Azure Firewall. Permita que las directivas pormenorizadas
cumplan los requisitos de regiones específicas al delegar las directivas de firewall incrementales a los
equipos de seguridad locales mediante el control de acceso basado en rol de Azure.
Configure los proveedores de seguridad SaaS de asociados compatibles en Firewall Manager si la
organización quiere usar tales soluciones para proteger las conexiones salientes.
Use WAF en una red virtual de zona de aterrizaje para proteger el tráfico entrante HTTP/S de Internet.
Use las directivas de WAF y Azure Front Door para proporcionar protección global en todas las regiones
de Azure para las conexiones entrantes HTTP/S a una zona de aterrizaje.
Cuando utilice Azure Front Door y Azure Application Gateway para ayudar a proteger las aplicaciones
HTTP/S, use las directivas del WAF de Azure Front Door. Bloquee Azure Application Gateway para que
reciba solo el tráfico procedente de Azure Front Door.
Si se requieren dispositivos virtuales de red de asociados para la protección y filtrado del tráfico este-
oeste o sur-norte:
En el caso de las topologías de red Virtual WAN, implemente los dispositivos virtuales de red en una
red virtual independiente (por ejemplo, una red virtual NVA). A continuación, conéctelo al centro de
conectividad de Virtual WAN y a las zonas de aterrizaje que requieran acceso a los dispositivos
virtuales de red. En este artículo se describe el proceso.
En el caso de las topologías de red que no sean de Virtual WAN, implemente los dispositivos virtuales
de red de asociales en la red virtual del centro de conectividad central.
Si se requieren NVA de asociados para las conexiones entrantes HTTP/S, impleméntelas en una red
virtual de zona de aterrizaje junto con las aplicaciones a las que protegen y exponen a Internet.
Use los planes de protección estándar de Azure DDoS Protection para proteger todos los puntos de
conexión públicos hospedados en las redes virtuales.
No replique los conceptos y arquitecturas de redes perimetrales locales en Azure. Hay funcionalidades de
seguridad similares disponibles en Azure, pero la implementación y la arquitectura deben adaptarse a la
nube.
Planeamiento para la entrega de aplicaciones
En esta sección se analizan las principales recomendaciones para entregar aplicaciones internas y externas de
una manera segura, muy escalable y con una elevada disponibilidad.
Azure Load Balancer (interno y público) proporciona alta disponibilidad para la entrega de aplicaciones
en el nivel regional.
Azure Application Gateway permite la entrega segura de aplicaciones HTTP/S en el nivel regional.
Azure Front Door permite la entrega segura de aplicaciones HTTP/S con alta disponibilidad entre
regiones de Azure.
Azure Traffic Manager permite la entrega de aplicaciones globales.
Realice la entrega de aplicaciones dentro de las zonas de aterrizaje, tanto para las aplicaciones internas
como para las externas.
Para lograr la entrega segura de las aplicaciones HTTP/S, use Application Gateway v2 y asegúrese de que
estén habilitadas las directivas y la protección de WAF.
Use una NVA de asociado si no puede usar Application Gateway v2 para la seguridad de las aplicaciones
HTTP/S.
Implemente Azure Application Gateway v2 o las NVA de los asociados que se usen para las conexiones
HTTP/S entrantes dentro de la red virtual de la zona de aterrizaje junto con las aplicaciones que vayan a
proteger.
Use un plan de protección contra DDoS estándar para todas las direcciones IP públicas en una zona de
aterrizaje.
Use Azure Front Door con directivas WAF para entregar y ayudar a proteger aplicaciones HTTP/S globales
que abarquen regiones de Azure.
Cuando vaya a usar Front Door y Application Gateway para ayudar a proteger aplicaciones HTTP/S, use
las directivas WAF de Front Door. Bloquee Application Gateway para recibir tráfico únicamente desde
Front Door.
Use Traffic Manager para ofrecer aplicaciones globales que abarquen protocolos distintos de HTTP/S.
Planeamiento de la segmentación de la red de zona
de aterrizaje
En esta sección se analizan las recomendaciones clave para ofrecer una segmentación muy segura de la red
interna en una zona de aterrizaje para impulsar una implementación de red de confianza cero.
El modelo de confianza cero presupone un estado de infracción y comprueba cada solicitud como si
proviniera de una red no controlada.
Una implementación de red avanzada de cero confianza emplea microperímetros de entrada y salida de
la nube totalmente distribuidos y una microsegmentación más profunda.
Los grupos de seguridad de red pueden usar etiquetas de servicio de Azure para facilitar la conectividad
con los servicios PaaS de Azure.
Los grupos de seguridad de aplicaciones no abarcan ni proporcionan protección en las redes virtuales.
Los registros de flujo de grupos de seguridad de red ahora se admiten mediante las plantillas de Azure
Resource Manager.
Delegue la creación de subredes al propietario de la zona de aterrizaje. De esta forma, podrán definir el
modo de segmentar las cargas de trabajo entre subredes (por ejemplo, una sola subred de gran tamaño,
una aplicación de varios niveles o una aplicación insertada en la red). El equipo de la plataforma puede
usar Azure Policy para asegurarse de que un grupo de seguridad de red con reglas específicas (como la
denegación de SSH o RDP entrante desde Internet, o la opción para permitir o bloquear el tráfico entre
zonas de aterrizaje) siempre esté asociado a las subredes que tengan directivas de solo denegación.
Use los grupos de seguridad de red a través de las subredes, así como el tráfico este-oeste a través de la
plataforma (tráfico entre zonas de aterrizaje).
El equipo de la aplicación debe usar grupos de seguridad de aplicaciones en los grupos de seguridad de
red de las subredes para proteger las máquinas virtuales de varios niveles dentro de su zona de
aterrizaje.
Use NSG y grupos de seguridad de aplicaciones para microsegmentar el tráfico dentro de la zona de
aterrizaje y evite el uso de una NVA central para filtrar los flujos de tráfico.
Habilite los registros de flujo de NSG y envíelos a Análisis de tráfico para obtener conclusiones sobre los
flujos de tráfico interno y externo.
Use los grupos de seguridad de red para permitir de forma selectiva la conectividad entre las zonas de
aterrizaje.
En el caso de las topologías de Virtual WAN, enrute el tráfico entre las zonas de aterrizaje a través de
Azure Firewall, si su organización necesita funciones de filtrado y registro para el flujo de tráfico entre
zonas de aterrizaje.
Si su organización decide implementar la tunelización forzada (anuncie la ruta predeterminada) en el
entorno local, se recomienda incorporar las siguientes reglas de salida para el grupo de seguridad de
red para denegar el tráfico de salida desde las redes virtuales directamente a Internet en caso de que la
sesión BGP deje de estar activa.
NOTE
Las prioridades de las reglas se deberán ajustar en función del conjunto de reglas existente del grupo de seguridad de red.
P RIO RIT Y N O M B RE SO URC E DEST IN AT IO N SERVIC IO A C C IÓ N C O M EN TA RIO
100 AllowLocal Any VirtualNetwork Any Allow Permite el

tráfico
durante las
operaciones
normales.
Con la
tunelización
forzada
habilitada,
0.0.0.0/0
se considera
parte de la
etiqueta
VirtualNetwork
siempre que
BGP la esté
anunciando
en
ExpressRoute
o VPN
Gateway.
110 DenyInternet Any Internet Any Deny Deniegue el

tráfico que
sale
directamente
a Internet si la
ruta
0.0.0.0/0
se retira de
las rutas
anunciadas
(por ejemplo,
debido a una
interrupción o
configuración
incorrecta).
En esta sección se analizan las recomendaciones clave para lograr el cifrado de red entre el entorno local y
Azure, así como entre regiones de Azure.
El costo y el ancho de banda disponible son inversamente proporcionales a la longitud del túnel de
cifrado entre los puntos de conexión.
Al usar una red privada virtual para conectarse a Azure, el tráfico se cifra a través de Internet mediante
los túneles IPsec.
Cuando se usa ExpressRoute con el emparejamiento privado, actualmente el tráfico no se cifra.
La configuración de una conexión VPN de sitio a sitio mediante el emparejamiento privado de
ExpressRoute se encuentra ya en versión preliminar.
Puede aplicar el cifrado de Seguridad de control de acceso a medios (MACsec) a ExpressRoute Direct para
lograr el cifrado de red.
Cuando el tráfico de Azure se mueve entre centros de datos (fuera de los límites físicos no controlados
por Microsoft o en nombre de Microsoft), se usa el cifrado de capa de vínculo de datos MACsec en el
hardware de red subyacente. Esto es aplicable al tráfico de emparejamiento de VNet.
Figura 1: Flujos de cifrado.

Cuando establece conexiones VPN desde el entorno local a Azure mediante puertas de enlace VPN, el
tráfico se cifra en un nivel de protocolo con túneles IPsec. En el diagrama anterior se muestra este cifrado
en el flujo A .
Cuando use ExpressRoute Direct, configure MACsec para cifrar el tráfico en el nivel de la capa dos entre
los enrutadores de la organización y MSEE. El diagrama muestra este cifrado en el flujo B .
En el caso de escenarios de Virtual WAN en los que MACsec no sea una opción (por ejemplo, si no se usa
ExpressRoute Direct), use la puerta de enlace VPN de Virtual WAN para establecer los túneles IPsec a
través del emparejamiento privado de ExpressRoute. El diagrama muestra este cifrado en el flujo C .
En el caso de escenarios donde no se use Virtual WAN y en los que MACsec no sea una opción (por
ejemplo, donde no se utilice ExpressRoute Direct), las únicas opciones son las siguientes:
Use las aplicaciones virtuales de red de los asociados para establecer túneles IPsec a través del
emparejamiento privado de ExpressRoute.
Establezca un túnel VPN sobre ExpressRoute con el emparejamiento de Microsoft.
Evalúe la funcionalidad para configurar una conexión VPN de sitio a sitio por medio del
emparejamiento privado de ExpressRoute (en versión preliminar).
Si tiene que cifrar el tráfico entre regiones de Azure, use el emparejamiento de VNet global para conectar
las redes virtuales entre regiones.
Si las soluciones nativas de Azure (como se muestra en los flujos B y C en el diagrama) no satisfacen
sus requisitos, use aplicaciones virtuales de red de un asociado de Azure para cifrar el tráfico a través del
emparejamiento privado de ExpressRoute.
En muchos sectores, las organizaciones requieren que el tráfico en Azure se refleje en un recopilador de
paquetes de red para llevar a cabo una inspección y un análisis en profundidad. Este requisito se suele centrar
en el tráfico entrante y saliente de Internet. En esta sección se describen las consideraciones clave y los enfoques
recomendados para el reflejo o transmisión del tráfico en Azure Virtual Network.
Punto de acceso de terminal de Azure Virtual Network está en versión preliminar. Póngase en contacto
con [email protected] para obtener detalles de disponibilidad.
La captura de paquetes en Azure Network Watcher está disponible con carácter general, pero las capturas
se limitan a un período máximo de cinco horas.
Como alternativa a TAP de Azure Virtual Network, evalúe las siguientes opciones:
Use los paquetes de Network Watcher para las capturas, a pesar de la ventana de captura limitada.
Evalúe si la versión más reciente de los registros de flujo del grupo de seguridad de red proporciona el
nivel de detalle que necesita.
Use soluciones de asociados para los escenarios que requieren una inspección en profundidad de los
paquetes.
No desarrolle una solución personalizada para reflejar el tráfico. Aunque este enfoque puede ser
aceptable en los escenarios a pequeña escala, no es aconsejable a una escala mayor debido a la
complejidad y a los problemas de compatibilidad que puedan surgir.
Examine las principales recomendaciones y consideraciones de diseño en relación con los distintos enfoques de
conectividad para integrar una arquitectura de zona de aterrizaje de escala empresarial de Azure en otros
proveedores de nube.
Oracle Cloud Infrastructure (OCI)

En esta sección se proporcionan diferentes enfoques de conectividad para integrar una arquitectura de zona de
aterrizaje de escala empresarial de Azure con Oracle Cloud Infrastructure (OCI).
Con ExpressRoute y FastConnect, los clientes pueden conectar una red virtual de Azure con una red
virtual en la nube de OCI, siempre que el espacio de direcciones IP privado no se solape. Una vez
establecida esta conectividad, los recursos de la red virtual de Azure pueden comunicarse con los de la
red de nube virtual de OCI como si estuvieran en la misma red.
Azure ExpressRoute FastPath se ha diseñado para mejorar el rendimiento de la ruta de acceso de datos
entre dos redes (entorno local y Azure) y, en este escenario, entre OCI y Azure. Cuando está habilitado,
FastPath envía el tráfico de red directamente a las máquinas virtuales que están en la red, omitiendo la
puerta de enlace de ExpressRoute.
FastPath está disponible en todos los circuitos de ExpressRoute.
FastPath todavía requiere la creación de una puerta de enlace de red virtual para el intercambio de
rutas. La puerta de enlace de red virtual debe usar la SKU de ultrarrendimiento o la SKU de
ErGw3AZ para la puerta de enlace de ExpressRoute con el fin de habilitar la administración de
rutas.
Hay características que no se admiten actualmente en ExpressRoute FastPath, como los concentradores
de Azure Virtual WAN o el emparejamiento de redes virtuales.
Aunque puede usar ExpressRoute Global Reach para habilitar la comunicación desde el entorno local a
OCI mediante circuitos ExpressRoute, esto puede conllevar costos de ancho de banda adicionales que se
pueden calcular con la calculadora de precios de Azure. Esta es una consideración especialmente
importante al migrar grandes cantidades de datos de un entorno local a Oracle mediante circuitos de
ExpressRoute.
En las regiones de Azure que admiten zonas de disponibilidad, la colocación de las cargas de trabajo de
Azure en una zona u otra puede tener un pequeño impacto en la latencia. Diseñe la aplicación para
equilibrar los requisitos de disponibilidad y rendimiento.
La interconectividad entre Azure y OCI solo está disponible para regiones específicas.
Para obtener documentación más detallada sobre la interconectividad entre Azure y OCI, consulte
Soluciones de aplicaciones de Oracle que integran Microsoft Azure y Oracle Cloud Infrastructure o la
documentación de Oracle.
Cree los circuitos de ExpressRoute que se usarán para interconectar Azure con OCI en la suscripción de
conectividad .
Puede interconectar una arquitectura de red de Azure basada en la arquitectura tradicional en estrella
tipo hub-and-spoke o en las topologías de red basadas en Azure Virtual WAN. Para hacerlo, conecte el
circuito de ExpressRoute que se usará para interconectar Azure con OCI y la red virtual del concentrador
o el concentrador de Virtual WAN, tal como se muestra en la figura siguiente.
Figura 1: Interconectividad entre Azure y OCI mediante ExpressRoute.

Si la aplicación requiere la menor latencia posible entre Azure y OCI, considere la posibilidad de
implementar la aplicación en una sola red virtual con una puerta de enlace de ExpressRoute y FastPath
habilitado.
Figura 2: Interconectividad entre Azure y OCI con una red virtual única.
Al implementar los recursos de Azure en Availability Zones, realice pruebas de latencia de VM de Azure
ubicadas en distintas zonas de disponibilidad con los recursos de OCI para comprender cuál de las tres
zonas de disponibilidad proporciona la latencia más baja a los recursos de OCI.
Para trabajar con recursos de Oracle hospedados en OCI mediante el uso de recursos y tecnologías de
Azure, puede hacer lo siguiente:
Desde Azure: implementar un jumpbox en una red virtual de radio. El jumpbox proporciona
acceso a la red de la nube virtual en OCI, tal como se muestra en la siguiente imagen:
Figura 3: Administración de recursos de OCI desde Azure mediante un jumpbox.

Desde el entorno local: use ExpressRoute Global Reach para enlazar un circuito de ExpressRoute
existente (que conecte el entorno local con Azure) con un circuito de OCI ExpressRoute (que
interconecte Azure con OCI). De esta manera, el enrutador de Microsoft Enterprise Edge (MSEE) se
convierte en el punto de enrutamiento central entre ambos circuitos de ExpressRoute.
Figura 4: Administración de recursos de OCI desde un entorno local mediante ExpressRoute Global Reach.
Plan de administración y supervisión de la plataforma

En esta sección se examina cómo mantener operativo un patrimonio empresarial de Azure mediante la
administración y supervisión centralizadas en la plataforma. Más concretamente, aquí se ofrecen
recomendaciones clave para que los equipos centrales mantengan la visibilidad operativa en una plataforma de
Azure a gran escala.
Figura 1: supervisión y administración de la plataforma.

Use un área de trabajo de Log Analytics de Azure Monitor como límite administrativo.
Supervisión de la plataforma centrada en la aplicación, que engloba las rutas de acceso de telemetría
activas y pasivas para las métricas y los registros, respectivamente:
Métricas del sistema operativo; por ejemplo, contadores de rendimiento y métricas personalizadas
Registros del sistema operativo; por ejemplo, Internet Information Services, Seguimiento de eventos
para Windows y syslogs
Eventos de estado del recurso.
Registro de auditorías de seguridad y control horizontal de la seguridad en todo el patrimonio de Azure
de la organización:
Posibilidad de integración en sistemas locales de Administración de eventos e información de
seguridad (SIEM), como ServiceNow, ArcSight o la plataforma de seguridad Onapsis.
Registros de actividad de Azure
Informes de auditoría de Azure Active Directory (Azure AD)
Servicios, registros y métricas de diagnóstico de Azure; eventos de auditoría de Azure Key Vault;
registros de flujo de grupos de seguridad de red (NSG) y registros de eventos.
Azure Monitor, Azure Network Watcher, Azure Security Center y Azure Sentinel
Umbrales de retención de datos de Azure y requisitos de archivado:
El período de retención predeterminado de los registros de Azure Monitor es de 30 días, con un
máximo de dos años.
El período de retención predeterminado de los informes de Azure AD (Prémium) es de 30 días.
El período de retención predeterminado del servicio de diagnóstico de Azure es de 90 días.
Requisitos operativos:
Paneles operativos con herramientas nativas como registros de Azure Monitor o herramientas de
terceros.
Control de actividades con privilegios con roles centralizados.
Identidades administradas de recursos de Azure para obtener acceso a los servicios de Azure.
Bloqueos de recursos para proteger la edición y la eliminación de recursos.
Use una sola área de trabajo de registros de supervisión para administrar las plataformas de forma
centralizada, excepto en los lugares donde el control de acceso basado en roles de Azure (RBAC de
Azure), los requisitos para la soberanía de datos y las directivas de retención de datos exijan áreas de
trabajo independientes. Tener un registro central es fundamental para dar a los equipos de
administración de operaciones la visibilidad que necesitan. La centralización de los registros permite
crear informes sobre la administración de cambios, el estado del servicio, la configuración y muchos
otros aspectos de las operaciones de TI. La convergencia en un modelo del área de trabajo centralizada
reduce el esfuerzo administrativo y las posibilidades de brechas en las operaciones de observabilidad.
En cuanto a la arquitectura a escala empresarial, el registro centralizado se refiere principalmente a las
operaciones de plataforma. Este énfasis no impide el uso de la misma área de trabajo para el registro de
aplicaciones basado en VM. Con un área de trabajo configurada en el modo de control de acceso
centrado en los recursos, se aplica un RBAC de Azure detallado para asegurarse de que los equipos de la
aplicación solo tendrán acceso a los registros de sus recursos. En este modelo, los equipos de la
aplicación se benefician del uso de la infraestructura de la plataforma existente, ya que se reduce la
sobrecarga de administración. En el caso de los recursos que no pertenezcan al proceso, como las
aplicaciones web o las bases de datos de Azure Cosmos DB, los equipos de la aplicación pueden usar sus
propias áreas de trabajo de Log Analytics y configurar los diagnósticos y métricas que se enrutarán aquí.
Exporte registros a Azure Storage si los requisitos de retención de registros superan los dos años. Use el
almacenamiento inmutable con la directiva para escribir una vez y leer varias si desea que los datos no se
puedan borrar ni modificar durante un intervalo de tiempo que haya especificado el usuario.
Use Azure Policy para el control de acceso y los informes de cumplimiento. Azure Policy proporciona la
capacidad de aplicar la configuración en toda la organización para garantizar así la aplicación coherente de la
directiva y la rápida detección de infracciones. Para obtener más información, consulte Comprensión de los
efectos de Azure Policy.
Supervise el desfase de configuración de la máquina virtual (VM) en el invitado mediante Azure Policy. Al
habilitar las funcionalidades de auditoría de la configuración de invitado a través de la directiva, las cargas de
trabajo del equipo de aplicaciones podrán consumir inmediatamente las funcionalidades de características
con poco esfuerzo.
Use Update Management de Azure Automation como mecanismo de revisión a largo plazo de las máquinas
virtuales Windows y Linux. La aplicación de configuraciones de Update Management mediante Azure Policy
garantiza que todas las máquinas virtuales se incluyan en el régimen de administración de revisiones y
permite a los equipos de aplicaciones administrar la implementación de revisiones para sus máquinas
virtuales. También proporciona funciones de visibilidad y cumplimiento al equipo de TI central en todas las
máquinas virtuales.
Use Network Watcher para supervisar de forma proactiva los flujos de tráfico a través de los registros de
flujo de grupo de seguridad de red de Network Watcher v2. Análisis de tráfico analiza los registros de flujo
de grupos de seguridad de red para recopilar información detallada sobre el tráfico IP en una red virtual y así
poder proporcionar información crítica para llevar a cabo con eficacia la administración y la supervisión.
Análisis de tráfico proporciona información sobre los hosts y protocolos de aplicaciones con mayor
comunicación, los pares de hosts con mayor número de interlocutores, el tráfico permitido o bloqueado, el
tráfico de entrada o salida, los puertos de Internet abiertos, las mayoría de las reglas de bloqueo, la
distribución del tráfico por centro de datos de Azure, la red virtual, las subredes o las redes no autorizadas.
Use los bloqueos de recursos para evitar eliminar de forma accidental servicios compartidos críticos.
Use las directivas de denegación para complementar las asignaciones de roles de Azure. Las directivas de
denegación se usan para evitar la implementación y configuración de recursos que no coinciden con
estándares definidos, evitando así que se envíe la solicitud al proveedor de recursos. La combinación de las
directivas de denegación y las asignaciones de roles de Azure garantiza que las barreras de protección
adecuadas estén en vigor para aplicar quién puede implementar y configurar recursos y qué recursos
pueden implementar y configurar.
Incluya los eventos de mantenimiento del servicio y los recursos como parte de la solución general de
supervisión de la plataforma. El servicio de seguimiento y el estado de los recursos desde la perspectiva de la
plataforma es un componente importante de la administración de recursos en Azure.
No envíe de nuevo entradas de registro sin procesar a sistemas de supervisión locales. En su lugar, adopte un
principio según el cual los datos creados en Azure permanezcan en Azure. Si la integración de SIEM local es
necesaria, envíe alertas críticas en lugar de registros.
Plan de administración y supervisión de la aplicación

Para ampliar la sección anterior, en esta sección se tendrá en cuenta un modelo federado y se explicará la forma
en que los equipos de la aplicación mantienen estas cargas de trabajo.
La supervisión de aplicaciones puede usar áreas de trabajo de Log Analytics dedicadas.
En el caso de las aplicaciones que se implementen en máquinas virtuales, los registros se deben almacenar
de forma centralizada en el área de trabajo de Log Analytics dedicada desde la perspectiva de una
plataforma. Los equipos de la aplicación pueden acceder a los registros sujetos al RBAC de Azure que tienen
en sus aplicaciones o máquinas virtuales.
Rendimiento de la aplicación y supervisión del estado de los recursos de infraestructura como servicio (IaaS)
y plataforma como servicio (PaaS).
Agregación de datos en todos los componentes de la aplicación.
Modelado y operacionalización del estado:
Cómo medir el estado de la carga de trabajo y sus subsistemas.
Un modelo de tipo semáforo para representar el estado.
Cómo responder a errores entre componentes de la aplicación
Use un área de trabajo de Log Analytics centralizada de Azure Monitor para recopilar registros y métricas de
los recursos de aplicaciones IaaS y PaaS y controlar el acceso a los registros con RBAC de Azure.
Use las métricas de Azure Monitor para realizar un análisis que tenga en cuenta el tiempo. Las métricas en
Azure Monitor se almacenan en una base de datos de serie temporal que está optimizada para el análisis de
datos con marca de tiempo. Estas métricas son adecuadas para enviar las alertas y detectar rápidamente
problemas. También pueden indicarle cómo está funcionando el sistema. Por lo general, deben combinarse
con registros para identificar la causa principal de los problemas.
Use los registros de Azure Monitor para obtener detalles e informes. Los registros contienen distintos tipos
de datos organizados en registros con diferentes conjuntos de propiedades. Resultan útiles para analizar
datos complejos de diversos orígenes, como los datos de rendimiento, los eventos y los seguimientos.
Cuando sea necesario, use cuentas de almacenamiento compartidas en la zona de aterrizaje para el
almacenamiento de registros de la extensión de diagnósticos de Azure.
Use alertas de Azure Monitor para generar alertas operativas. Las alertas de Azure Monitor unifican las
alertas de métricas y registros, y usan características como la acción y los grupos inteligentes para fines de
corrección y administración avanzados.
Continuidad empresarial y recuperación ante
desastres
Una organización o empresa necesita diseñar funcionalidades adecuadas del nivel de plataforma que las cargas
de trabajo de las aplicaciones puedan consumir para satisfacer sus requisitos específicos. En concreto, estas
cargas de trabajo de aplicaciones tienen requisitos relacionados con la recuperación del objetivo de tiempo
(RTO) y el objetivo de punto de recuperación (RPO). Asegúrese de capturar los requisitos de recuperación ante
desastres (DR) para diseñar las funcionalidades adecuadas para estas cargas de trabajo.
Tenga en cuenta los siguientes factores:
Requisitos de disponibilidad de la aplicación y los datos, y el uso de patrones de disponibilidad de tipo
"activo-activo" y "activo-pasivo" (como los requisitos de RTO y RPO de la carga de trabajo).
Continuidad empresarial y recuperación ante desastres para los servicios de Plataforma como servicio
(PaaS) y las características de alta disponibilidad y la disponibilidad de la recuperación ante desastres
nativa.
Compatibilidad con implementaciones de varias regiones con fines de conmutación por error, con
proximidad de componentes por motivos de rendimiento.
Operaciones de aplicación con funcionalidad reducida o rendimiento degradado si se produce una
interrupción.
Idoneidad de la carga de trabajo para zonas de disponibilidad o conjuntos de disponibilidad.
Uso compartido de datos y dependencias entre zonas.
Repercusión de Availability Zones en los dominios de actualización en comparación con los
conjuntos de disponibilidad y el porcentaje de cargas de trabajo que pueden estar en
mantenimiento al mismo tiempo.
Compatibilidad con SKU de máquinas virtuales específicas con zonas de disponibilidad.
Es necesario usar zonas de disponibilidad si se usa el almacenamiento en disco Ultra de
Microsoft Azure.
Copias de seguridad coherentes para aplicaciones y datos.
Instantáneas de máquina virtual y uso de Azure Backup y almacenes de Recovery Services.
Los límites de la suscripción restringen el número de almacenes de Recovery Services y el tamaño
de cada almacén.
Funcionalidades de replicación geográfica y recuperación ante desastres para los servicios PaaS.
Conectividad de red si se produce una conmutación por error.
Planeamiento de la capacidad de ancho de banda para Azure ExpressRoute.
Enrutamiento del tráfico si se produce una interrupción regional, de zona o de red.
Conmutaciones por error planeadas y no planeadas.
Los requisitos de coherencia de las direcciones IP y la posible necesidad de mantener direcciones
IP después de la conmutación por error y la conmutación por recuperación.
Capacidades de DevOps de ingeniería que se mantienen.
Recuperación ante desastres de Azure Key Vault para las claves de aplicaciones, certificados y secretos.
A continuación se muestran los procedimientos recomendados para el diseño:
Emplee Azure Site Recovery en escenarios de recuperación ante desastres de Azure a Azure Virtual
Machines. De este modo, puede replicar las cargas de trabajo entre las regiones.
Site Recovery proporciona capacidades de plataforma integradas para que las cargas de trabajo de VM
cumplan los requisitos de RPO/RTO bajo, a través de la replicación en tiempo real y la automatización de
la recuperación. Además, el servicio proporciona la capacidad de ejecutar simulacros de recuperación sin
afectar a las cargas de trabajo en producción. Puede usar Azure Policy para habilitar la replicación y
también para auditar la protección de las máquinas virtuales.
Use las funcionalidades de recuperación ante desastres del servicio PaaS nativo.
Las características integradas proporcionan una solución sencilla a la compleja tarea que supone
compilar la replicación y la conmutación por error en una arquitectura de carga de trabajo, lo que
simplifica tanto la automatización del diseño como la implementación. Una organización que ha definido
un estándar para los servicios que usa, también puede auditar y aplicar la configuración del servicio a
través de Azure Policy.
Use las funcionalidades de la copia de seguridad nativa de Azure.
Las características de copia de seguridad nativas de Azure Backup y PaaS eliminan la necesidad de
administrar la infraestructura y el software de copia de seguridad de terceros. Al igual que con otras
características nativas, puede establecer, auditar y aplicar las configuraciones de copia de seguridad con
Azure Policy. De este modo se garantiza que los servicios sigan siendo compatibles con los requisitos de
la organización.
Use varias regiones y ubicaciones de emparejamiento para la conectividad de ExpressRoute.
Una arquitectura de red híbrida redundante puede ayudarle a garantizar una conectividad entre locales
ininterrumpida en caso de que se produzca una interrupción de servicio que afecte a una región de Azure
o a una ubicación del proveedor de emparejamiento.
Evite el uso de intervalos de direcciones IP superpuestos para los sitios de producción y de recuperación
ante desastres.
Cuando sea posible, planee una continuidad empresarial y una arquitectura de red de recuperación ante
desastres que proporcione una conectividad simultánea a todos los sitios. Las redes de recuperación ante
desastres que usan los mismos bloques de enrutamiento entre dominios sin clase, como son las redes de
producción, requerirán un proceso de conmutación por error de red que pueda complicar y retrasar la
conmutación por error de las aplicaciones en caso de una interrupción.
Seguridad, gobernanza y cumplimiento a escala
empresarial
En este artículo se explica cómo definir el cifrado y la administración de claves, el planeamiento de la

gobernanza, la definición de la supervisión de seguridad y una directiva de auditoría, así como el planeamiento
de la seguridad de la plataforma. Al final del artículo, puede consultar una tabla que describe un marco para
evaluar la preparación de la seguridad empresarial de los servicios de Azure.
Definición del cifrado y administración de claves

El cifrado es un paso fundamental para garantizar la privacidad de los datos, el cumplimiento normativo y la
residencia de los datos en Microsoft Azure. También es una de las preocupaciones de seguridad más
importantes de muchas empresas. En esta sección, se tratan las consideraciones de diseño y las
recomendaciones en relación con el cifrado y la administración de claves.
Límites de suscripción y escala en relación a su aplicación a Azure Key Vault: Key Vault tiene límites de
transacciones de claves y secretos. Para limitar las transacciones por almacén en un período determinado,
consulte Límites de Azure.
Key Vault actúa como límite de seguridad, ya que los permisos para acceder a las claves, los secretos y los
certificados se encuentran en los almacenes. Las asignaciones de las directivas de acceso de Key Vault
conceden permisos independientes a las claves, los secretos o los certificados. No admiten los permisos
de nivel de objeto pormenorizados, como una clave, un secreto o una administración de claves de
certificado específicos.
Puede aislar los secretos específicos de la aplicación y de la carga de trabajo, y los secretos compartidos,
con el control de acceso apropiado.
Puede optimizar las SKU Premium cuando se requieran claves protegidas por el módulo de seguridad de
hardware. Los módulos de seguridad de hardware (HSM) subyacentes son compatibles con el nivel 2 de
FIPS 140-2. Administre el HSM dedicado de Azure para el cumplimiento del nivel 3 de FIPS 140-2,
teniendo en cuenta los escenarios admitidos.
Rotación de claves y expiración de secretos.
Adquisición y firma de certificados con certificados de Key Vault.
Alertas, notificaciones y renovaciones de certificados automatizadas.
Requisitos de recuperación ante desastres para claves, certificados y secretos.
Funcionalidades de replicación y conmutación por error del servicio Key Vault: disponibilidad y
redundancia.
La clave de supervisión, el certificado y el uso de secretos.
Detección del acceso no autorizado mediante un almacén de claves o un área de trabajo de Log Analytics
de Azure Monitor: supervisión y alertas.
Creación delegada de instancias de Key Vault y acceso con privilegios: acceso seguro.
Requisitos relacionados con el uso de claves administradas por el cliente para los mecanismos de cifrado
nativos como el cifrado de Azure Storage:
claves administradas por el cliente.
Cifrado de todo el disco para máquinas virtuales (VM).
Cifrado de datos en tránsito.
Cifrado de datos en reposo.
Use un modelo de Azure Key Vault federado para evitar límites de escala de transacciones.
Aprovisione Azure Key Vault con las directivas de eliminación temporal y purga habilitadas para permitir
la protección de retención de los objetos eliminados.
Siga un modelo de privilegios mínimos y limite a los roles de Azure Active Directory (Azure AD)
personalizados y especializados la autorización para eliminar de forma permanente claves, secretos y
certificados.
Automatice el proceso de renovación y administración de certificados con entidades de certificación
públicas para facilitar la administración.
Establezca un proceso automatizado para la rotación de claves y certificados.
Habilite el firewall y el punto de conexión de servicio de red virtual en el almacén para controlar el acceso
al almacén de claves.
Use el área de trabajo de Log Analytics de Azure Monitor central de la plataforma para auditar el uso de
claves, certificados y secretos en cada instancia de Key Vault.
Delegue la creación de instancias de Key Vault y el acceso con privilegios, y use Azure Policy para aplicar
una configuración compatible coherente.
Use de forma predeterminada las claves administradas por Microsoft para la funcionalidad de cifrado de
entidad de seguridad y use las claves administradas por el cliente cuando sea necesario.
No use instancias de Key Vault centralizadas para claves o secretos de aplicación.
No comparta instancias de Key Vault entre aplicaciones para evitar el uso compartido de secretos entre
entornos.
Planeación para la gobernanza

La gobernanza proporciona mecanismos y procesos para mantener el control de las aplicaciones y recursos de
Azure. Azure Policy es esencial para garantizar la seguridad y el cumplimiento en medios técnicos de la empresa.
Puede aplicar convenciones vitales de administración y seguridad en los servicios de la plataforma Azure, así
como el control de acceso basado en roles de Azure (RBAC de Azure) complementario que controla qué
acciones pueden realizar los usuarios autorizados.
Determine qué directivas de Azure son necesarias.
Aplique convenciones de administración y seguridad, como el uso de puntos de conexión privados.
La administración y creación de asignaciones de directivas mediante definiciones de directiva se pueden
reutilizar en varios ámbitos de asignación heredados. Puede tener asignaciones de directivas de
referencia centralizadas en los ámbitos de grupo de administración, suscripción y grupo de recursos.
Garantice el cumplimiento continuo con informes de cumplimiento y auditorías.
Sepa que Azure Policy tiene límites, como la restricción de definiciones en cualquier ámbito dado: límites
de las directivas.
Conozca las directivas de cumplimiento normativo. Estas podrían incluir los principios de servicio de
confianza HIPAA, PCI-DSS o SOC 2.
Identifique las etiquetas de Azure necesarias y use el modo de directiva de anexión para aplicar el uso.
Asigne requisitos legislativos y de cumplimiento normativo a las definiciones de Azure Policy y a las
asignaciones de roles de Azure.
Establezca definiciones de Azure Policy en el grupo de administración raíz de nivel superior para que se
puedan asignar en ámbitos heredados.
Administre las asignaciones de directivas en el nivel más alto adecuado, con exclusiones en los niveles
inferiores si es necesario.
Use Azure Policy para controlar los registros de proveedores de recursos en el nivel de suscripción o de
grupo de administración.
Use directivas integradas siempre que sea posible para reducir al mínimo la sobrecarga operativa.
Asigne el rol Colaborador de directiva integrada en un ámbito determinado para habilitar la gobernanza
en las aplicaciones.
Limite el número de asignaciones de Azure Policy realizadas en el ámbito del grupo de administración
raíz para evitar la administración mediante exclusiones en ámbitos heredados.
Definir la supervisión de seguridad y una directiva de auditoría

Una empresa debe tener visibilidad sobre lo que está ocurriendo dentro de su patrimonio tecnológico en la
nube. La supervisión de seguridad y el registro de auditoría de los servicios de la plataforma Azure es un
componente clave de un marco escalable.
Períodos de retención de datos para los datos de auditoría. Los informes de Azure AD Premium tienen un
período de retención de 30 días.
El archivo a largo plazo de registros como los registros de actividad de Azure, de máquina virtual y de
plataforma como servicio (PaaS).
Base de referencia de configuración de la seguridad mediante una directiva de máquina virtual invitada
de Azure.
Revisión de emergencia de los puntos vulnerables críticos.
Revisión de las máquinas virtuales desconectadas durante largos períodos de tiempo.
Requisitos de supervisión y alertas en tiempo real.
Integración de la información de seguridad y la administración de eventos con Azure Security Center y
Azure Sentinel.
Evaluación de los puntos vulnerables de las máquinas virtuales.
Use las funcionalidades de informe de Azure AD para generar informes de auditoría de control de acceso.
Exporte los registros de actividad de Azure a los registros de Azure Monitor para la retención de datos a
largo plazo. Exporte a Azure Storage para el almacenamiento a más allá de dos años, si es necesario.
Habilite Security Center Standard para todas las suscripciones y use Azure Policy para garantizar el
cumplimiento.
Supervise el desfase de revisiones del sistema operativo base mediante los registros de Azure Monitor y
Azure Security Center.
Use directivas de Azure para implementar automáticamente las configuraciones de software con
extensiones de máquina virtual y aplicar una base de referencia de configuración de máquina virtual
compatible.
Supervise el desfase en la configuración de seguridad de máquina virtual a través de Azure Policy.
Conecte las configuraciones de los recursos predeterminados a un área de trabajo de Log Analytics de
Azure Monitor centralizada.
Use una solución basada en Azure Event Grid para las alertas en tiempo real orientadas a registros.
Plan de la seguridad de la plataforma

Debe mantener unos principios de seguridad correctos en su adopción de Azure. Además de la visibilidad, tiene
que ser capaz de controlar la configuración inicial y los cambios a medida que evolucionen los servicios de
Azure. Por lo tanto, el planeamiento de la seguridad de la plataforma es fundamental.
Responsabilidad compartida.
Alta disponibilidad y recuperación ante desastres.
Seguridad coherente entre los servicios de Azure en cuanto a la administración de datos y las
operaciones del plano de control.
Multiinquilino para los componentes clave de la plataforma. Esto incluye Hyper-V, los HSM que hospedan
Key Vault y los motores de base de datos.
En el contexto de sus requisitos subyacentes, realice un examen conjunto de cada servicio necesario. Si
quiere emplear sus propias claves, es posible que no se admita en todos los servicios considerados.
Implemente la mitigación pertinente para que las incoherencias no impidan los resultados deseados. Elija
los pares de regiones adecuados y las regiones de recuperación ante desastres que minimicen la latencia.
Desarrolle un plan de listas de permitidos de seguridad para evaluar la configuración de seguridad de los
servicios, la supervisión, las alertas y cómo integrarlas con los sistemas existentes.
Determine el plan de respuesta a incidentes para los servicios de Azure antes de permitirlo en
producción.
Use las funcionalidades de informe de Azure AD para generar informes de auditoría de control de acceso.
Alinee sus requisitos de seguridad con las hojas de ruta de la plataforma Azure para mantenerse al día
con los controles de seguridad publicados recientemente.
Implemente un enfoque de confianza cero para el acceso a la plataforma Azure, cuando sea necesario.
Prueba comparativa de la seguridad de Azure

La prueba comparativa de seguridad de Azure incluye una recopilación de recomendaciones de seguridad de
gran impacto que puede usar para ayudar a proteger la mayoría de los servicios que usa en Azure. Puede
considerar estas recomendaciones como "generales" u "organizativas", ya que son aplicables a la mayoría de los
servicios de Azure. Las recomendaciones de las pruebas comparativas de seguridad de Azure se personalizan
después para cada servicio de Azure y esta guía personalizada se incluye en los artículos de recomendaciones
de servicio.
La documentación de las pruebas comparativas de seguridad de Azure especifica controles de seguridad y
recomendaciones de servicio.
Controles de seguridad: Las recomendaciones de las pruebas comparativas de seguridad de Azure se
clasifican por controles de seguridad. Los controles de seguridad representan requisitos de seguridad
independientes del proveedor de alto nivel, como la seguridad de red y la protección de datos. Cada control
de seguridad tiene un conjunto de recomendaciones de seguridad e instrucciones que le ayudan a
implementar esas recomendaciones.
Recomendaciones de servicio: Cuando estén disponibles, las recomendaciones de las pruebas comparativas
de los servicios de Azure incluirán recomendaciones de pruebas comparativas de seguridad exclusivas para
el servicio en concreto.
Marco de habilitación del servicio

A medida que las unidades de negocio soliciten la implementación de cargas de trabajo en Azure, necesitará una
visibilidad adicional de la carga de trabajo para determinar cómo lograr los niveles adecuados de gobernanza,
seguridad y cumplimiento. Cuando se requiera un nuevo servicio, debe permitirlo. En la tabla siguiente se
proporciona un marco para evaluar la preparación de la seguridad empresarial de los servicios de Azure:
EVA L UA C IÓ N C AT EGO RY C RIT ERIO S
Seguridad Punto de conexión de red ¿Tiene el servicio un punto de

conexión público que es accesible fuera
de una red virtual?
¿Admite puntos de conexión de

servicio de red virtual?
¿Pueden los servicios de Azure

interactuar directamente con el punto
de conexión de servicio?
¿Admite puntos de conexión de Private

Link?
¿Se puede implementar en una red

virtual?
Prevención de la filtración de datos ¿Tiene el servicio PaaS una comunidad

de protocolo de puerta de enlace de
borde (BGP) diferente en el
emparejamiento de Microsoft de Azure
ExpressRoute? ¿ExpressRoute expone
un filtro de ruta para el servicio?
¿Admite el servicio puntos de conexión

de Private Link?
Aplicar el flujo de tráfico de red para ¿Es posible inspeccionar el tráfico que
las operaciones de administración y de entra y sale del servicio? ¿Se puede
plano de datos forzar el tráfico por túnel con el
enrutamiento definido por el usuario?
¿Usan las operaciones de

administración rangos de direcciones
IP públicas compartidas de Azure?
¿Se dirige el tráfico de administración a

través de un punto de conexión local
de vínculo expuesto en el host?
Cifrado de datos en reposo ¿Se aplica el cifrado de forma

predeterminada?
¿Se puede deshabilitar el cifrado?
¿Se realiza el cifrado con claves

administradas por Microsoft o claves
administradas por el cliente?
Cifrado de datos en tránsito ¿Está cifrado el tráfico que se dirige al

servicio en un nivel de protocolo
(SSL/TLS)?
¿Hay algún punto de conexión HTTP y

se puede deshabilitar?
¿Está también cifrada la comunicación

del servicio subyacente?
¿Se realiza el cifrado con claves

administradas por Microsoft o claves
administradas por el cliente? (¿Se
admite el cifrado propio?)
Implementación de software ¿Se puede implementar software de

aplicaciones o productos de terceros
en el servicio?
¿Cómo se realiza y administra la

implementación de software?
¿Se pueden aplicar directivas para

controlar la integridad del origen o del
código?
Si el software se puede implementar,

¿se puede usar la funcionalidad
antimalware, la administración de
puntos vulnerables y las herramientas
de supervisión de la seguridad?
¿El servicio proporciona estas

funcionalidades de forma nativa, como
con Azure Kubernetes Service?
Administración de identidades y Autenticación y control de acceso ¿Se rigen todas las operaciones del
acceso plano de control por Azure AD? ¿Hay
un plano de control anidado, como
con Azure Kubernetes Service?
¿Qué métodos existen para

proporcionar acceso al plano de datos?
¿Se integra el plano de datos con

Azure AD?
¿La autenticación entre los servicios de

Azure usa identidades administradas o
entidades de servicio?
¿Se realiza la autenticación de Azure en

IaaS (servicio a red virtual) a través de
Azure AD?
¿Cómo se administran las firmas de

acceso compartido o las claves
aplicables?
¿Cómo se puede revocar el acceso?
Segregación de obligaciones ¿Separa el servicio las operaciones de

plano de control y de plano de datos
dentro Azure AD?
Autenticación multifactor y acceso ¿Se aplica la autenticación multifactor

condicional para las interacciones entre el usuario
y el servicio?
Gobernanza Exportación e importación de datos ¿Permite el servicio importar y

exportar datos de forma segura y
cifrada?
Privacidad y uso de datos ¿Pueden los ingenieros de Microsoft

acceder a los datos?
¿Hay alguna interacción de soporte

técnico de Microsoft con el servicio
auditado?
Residencia de datos ¿Están los datos contenidos en la

región de implementación del servicio?
Operaciones Supervisión ¿Se integra el servicio con Azure

Monitor?
Administración de copias de seguridad ¿De qué datos de carga de trabajo se

debe hacer una copia de seguridad?
¿Cómo se capturan las copias de

seguridad?
¿Con qué frecuencia se pueden realizar

copias de seguridad?
¿Durante cuánto tiempo se pueden

conservar las copias de seguridad?
¿Se cifran las copias de seguridad?
¿El cifrado de las copias de seguridad

se realiza con claves administradas por
Microsoft o con claves administradas
por el cliente?
Recuperación ante desastres ¿Cómo se puede usar el servicio en un

modo redundante regional?
¿Cuál es el objetivo de tiempo de

recuperación y el objetivo de punto de
recuperación que se pueden lograr?
SKU ¿Qué SKU están disponibles? ¿Y cómo

difieren?
¿Hay alguna característica relacionada

con la seguridad para la SKU Premium?
Administración de la capacidad ¿Cómo se supervisa la capacidad?
¿Cuál es la unidad de escala

horizontal?
Administración de revisiones y ¿El servicio requiere una actualización

actualizaciones activa o las actualizaciones se realizan
de forma automática?
¿Con qué frecuencia se aplican las

actualizaciones? ¿Se pueden
automatizar?
Auditoría ¿Se capturan las operaciones de plano

de control anidadas (por ejemplo,
Azure Kubernetes Service o Azure
Databricks)?
¿Se registran las actividades de plano

de datos clave?
Administración de configuración ¿Admite etiquetas y proporciona un

esquema de put para todos los
recursos?
Cumplimiento de servicio de Azure Confirmación de servicio, certificación ¿Es compatible el servicio con
y auditorías externas PCI/ISO/SOC?
Disponibilidad del servicio ¿El servicio es una versión preliminar

privada, una versión preliminar pública
o está disponible con carácter general?
¿En qué regiones está disponible el

servicio?
¿Cuál es el ámbito de implementación

del servicio? ¿Es un servicio regional o
global?
Contratos de nivel de servicio (SLA) ¿Cuál es el contrato de nivel de

servicio para la disponibilidad del
servicio?
Si es aplicable, ¿cuál es el contrato de

nivel de servicio para el rendimiento?
Figura 1: Automatización de la plataforma y DevOps.
Planeamiento de un enfoque DevOps

Muchos modelos operativos de TI tradicionales no son compatibles con la nube y las organizaciones deben
someterse a una transformación organizativa y operativa para cumplir los objetivos de migración de la
empresa. Debe usar un enfoque de DevOps para los equipos centrales y de aplicaciones.
En lo que respecta a los equipos centrales, debe usar canalizaciones para la integración y la
implementación continuas. Use las canalizaciones para administrar las definiciones de directiva, las
definiciones de roles, las asignaciones de directivas, las jerarquías de grupos de administración y las
suscripciones. Estas canalizaciones garantizan la administración operativa de varias suscripciones
mientras se mantiene el estado deseado.
La aplicación global de un modelo de DevOps no establece de forma instantánea equipos con capacidad
de DevOps.
Invertir en capacidades y recursos de ingeniería es fundamental.
Puede organizar los roles y funciones de DevOps internos y externos de diversos orígenes en línea con la
estrategia de su organización.
En el caso de algunas aplicaciones heredadas, es posible que el equipo de la aplicación asociado no tenga
los recursos de ingeniería necesarios para emplear una estrategia de DevOps.
Establezca un equipo de plataforma DevOps interfuncional para compilar, administrar y mantener la
arquitectura de escala empresarial. En este equipo se deben incluir miembros del equipo de TI central,
seguridad, cumplimiento y unidades de negocio para asegurarse de que esté representado un amplio espectro
de la empresa. En la siguiente lista se presenta un conjunto de roles de DevOps recomendados para un equipo
de plataforma central:
PlatformOps (operaciones de plataforma) para:
El aprovisionamiento y la delegación de suscripciones de la red necesaria, la administración de
identidades y acceso, y las directivas.
La administración y supervisión de la plataforma (holística).
La administración de costos (holística).
La plataforma como código (la administración de plantillas, scripts y otros recursos).
La responsabilidad de las operaciones generales en Microsoft Azure dentro del inquilino de
Azure Active Directory (la administración de entidades de servicio, el registro de Microsoft Graph
API y la definición de roles).
SecOps (operaciones de seguridad)
Control de acceso basado en roles de Azure (RBAC de Azure) (holístico).
Administración de claves (para los servicios centrales, el protocolo simple de transferencia de
correo y el controlador de dominio).
Administración y aplicación de directivas (holística).
Supervisión y auditoría de seguridad (holística).
NetOps (operaciones de red)
Administración de red (holística).
AppDevOps. Permite a los propietarios de aplicaciones crear y administrar los recursos de la aplicación
a través de un modelo DevOps. En la siguiente lista se presenta un rol de DevOps recomendado para los
equipos de aplicaciones:
Migración o transformación de la aplicación.
Administración y supervisión de la aplicación.
RBAC de Azure (recursos de la aplicación).
Supervisión y auditoría de seguridad (recursos de la aplicación).
Administración de costos (recursos de la aplicación).
Administración de redes (recursos de la aplicación).
En algunos casos puede que quiera dividir AppDevOps en roles más pormenorizados, como
AppDataOps para la administración de bases de datos, o AppSecOps para aplicaciones que
requieran una mayor seguridad.
Proporcione una función de DevOps de aplicación central que admita aplicaciones en las que no
existen funcionalidades de DevOps, o un caso empresarial para establecer una (por ejemplo,
aplicaciones heredadas con funcionalidades de desarrollo mínimas).
Use un enfoque controlado por directivas con límites de RBAC de Azure claros para aplicar de
forma centralizada la coherencia y la seguridad entre los equipos de la aplicación. Esto garantiza
que se toma un enfoque de privilegios mínimos mediante el uso de una combinación de RBAC de
Azure y Azure Policy, y que las cargas de trabajo son compatibles con las asignaciones de Azure
Policy en todo momento.
Para acelerar la adopción de Azure, el equipo de la plataforma central debe establecer un conjunto
común de plantillas y bibliotecas para que los equipos de la aplicación las aprovechen. Por
ejemplo, la orientación horizontal (interfuncional) puede ayudar a realizar migraciones mediante la
experiencia en la materia y garantizar la alineación con la arquitectura de escala empresarial de
destino general.
No limite el uso de artefactos o enfoques centrales a los equipos de la aplicación, ya que los
ralentizará. Se pueden aplicar configuraciones de línea de base coherentes mediante un enfoque
de infraestructura controlada por directivas y RBAC de Azure. Esto garantiza que los equipos de la
aplicación (unidad empresarial) sean lo suficientemente flexibles para innovar y poder seguir
aprovechando un conjunto predefinido de plantillas.
No obligue a los equipos de las aplicaciones a utilizar una canalización de aprovisionamiento o un
proceso central para la creación de instancias o la administración de recursos de la aplicación. Los
equipos existentes que ya se basan en una canalización de DevOps para la entrega de aplicaciones
deben poder seguir usando las mismas herramientas que hasta ahora. Recuerde que puede seguir
usando Azure Policy para mantener las protecciones, independientemente de cómo se
implementen los recursos en Azure.
Definición de responsabilidades centrales y federadas

La distribución de roles, responsabilidades y confianza entre los equipos de TI central y los equipos de las
aplicaciones es primordial para la transformación operativa a la que la organización se debe someter al adoptar
la nube a gran escala.
Los equipos centrales se esfuerzan por mantener el control total, mientras que los propietarios de las
aplicaciones buscan maximizar la agilidad. El equilibrio entre estos objetivos puede influir en gran medida en el
éxito de la migración.
La lista siguiente presenta una distribución recomendada de responsabilidades entre el equipo de TI central y
los equipos de aplicaciones. Es un esfuerzo por permitir las actividades de migración y transformación con unas
dependencias centrales mínimas. Al mismo tiempo, se desea admitir la gobernanza centralizada de la seguridad
y la interoperabilidad en todo el patrimonio.
Funciones de la aplicación
Migración y transformación de la aplicación.
Administración y supervisión de la aplicación (recursos de la aplicación).
Administración de claves (claves de aplicación).
RBAC de Azure (recursos de la aplicación).
Supervisión y auditoría de seguridad (recursos de la aplicación).
Administración de costos (recursos de la aplicación).
Administración de redes (recursos de la aplicación).
Funciones centrales
Gobernanza de la arquitectura.
Administración de suscripciones.
Plataforma como código (administración de plantillas, scripts y otros recursos).
Administración y aplicación de directivas (holística).
La administración y supervisión de la plataforma (holística).
RBAC de Azure (holístico).
Administración de claves (servicios centrales).
Administración de redes (como las redes y los dispositivos virtuales de red).
Supervisión y auditoría de seguridad (holística).
La administración de costos (holística).
Un modelo de Azure DevOps basado en estas recomendaciones proporciona el control deseado para los
equipos centrales y la agilidad de migración que requieren los equipos de la aplicación.
Instrucciones de implementación a escala
empresarial
En este artículo se describe cómo empezar a trabajar con la implementación de referencia nativa de la
plataforma de escala empresarial y se definen los objetivos de diseño.
Para implementar la arquitectura de escala empresarial, debe considerar las siguientes categorías de actividades:
1. Actividades necesarias para la arquitectura de escala empresarial: engloba las actividades que
deben realizar los administradores de Azure Active Directory (Azure AD) para establecer una
configuración inicial. Estas actividades son secuenciales por naturaleza y son principalmente actividades
puntuales.
2. Habilitación de una nueva región (Archivo -> Nuevo -> Región): engloba las actividades que
serán necesarias siempre que haya que expandir la plataforma de escala empresarial en una nueva
región de Azure.
3. Implementación de una nueva zona de aterrizaje (Archivo -> Nuevo -> Zona de aterrizaje):
se trata de actividades periódicas necesarias para crear una instancia de una nueva zona de aterrizaje.
Para operar a escala, estas actividades deben seguir los principios de la infraestructura como código (IaC) y se
deben automatizar mediante canalizaciones de implementación.
Lo que debe cumplirse para una zona de aterrizaje de escala

empresarial
En las secciones siguientes se enumeran los pasos para completar esta categoría de actividad en Microsoft
Cloud Adoption Framework para Azure.
Inscripción del Contrato Enterprise e inquilinos de Azure AD
1. Configure el administrador del Contrato Enterprise (EA) y la cuenta de notificación.
2. Cree departamentos: dominios empresariales/geoárea/organización.
3. Cree una cuenta de EA en un departamento.
4. Configure Azure AD Connect para cada inquilino de Azure AD si la identidad se va a sincronizar desde el
entorno local.
5. Establezca un acceso no permanente a los recursos de Azure y un acceso Just-in-Time a través de
Azure AD Privileged Identity Management (PIM).
Grupo de administración y suscripción
1. Cree una jerarquía de grupos de administración; para ello, siga las recomendaciones de Organización de
grupos de administración y suscripciones.
2. Defina los criterios para el aprovisionamiento de suscripciones junto con las responsabilidades del
propietario de una suscripción.
3. Cree suscripciones de administración, conectividad e identidad para los recursos de administración de la
plataforma, redes globales y conectividad e identidad como, por ejemplo, los controladores de dominio
de Active Directory.
4. Configure un repositorio de Git para hospedar las entidades de servicio e IaC a fin de usarlas con una
canalización de plataforma para la integración y la implementación continuas.
5. Cree definiciones de roles personalizados y administre los derechos mediante Azure AD PIM para los
ámbitos del grupo de administración y suscripción.
6. Cree las asignaciones de Azure Policy de la tabla siguiente para las zonas de aterrizaje.
N O M B RE DESC RIP C IÓ N
Deny-PublicEndpoints Deniega la creación de servicios con puntos de conexión

/.AzState/Microsoft.Authorization_policySetDefinitions- públicos en todas las zonas de aterrizaje.
Deny-PublicEndpoints.parameters.json)
Deploy-VM-Backup Garantiza que la copia de seguridad está configurada e

/Landing%20Zones%20(landingzones) implementada en todas las máquinas virtuales de las
/.AzState/Microsoft.Authorization_policyAssignments- zonas de aterrizaje.
Deploy-VM-Backup.parameters.json)
Deploy-VNet Garantiza que todas las zonas de aterrizaje tengan

/.AzState/Microsoft.Authorization_policyDefinitions- implementada una red virtual y que estén emparejadas
Deploy-vNet.parameters.json) con el centro de conectividad virtual regional.
Guía de gobernanza de espacios aislados

Tal y como se detalla en el área de diseño principal de la organización de grupos de administración y
suscripciones, las suscripciones colocadas dentro de la jerarquía del grupo de administración de espacios
aislados deben tener un enfoque de directiva menos restrictivo. Estas suscripciones están destinadas a los
usuarios de la empresa que tengan que experimentar e innovar con productos y servicios de Azure que aún no
estén permitidos en la jerarquía de su zona de aterrizaje, con el fin de validar si sus ideas o conceptos podrían
funcionar antes de aplicarlos al entorno de desarrollo formal.
Sin embargo, estas suscripciones de la jerarquía del grupo de administración de espacios aislados aún requieren
algunas protecciones para asegurarse de que se usan de la manera correcta. Por ejemplo, para la innovación, la
experimentación con nuevos servicios y características de Azure y la validación de ideas.
Por lo tanto, se recomienda:
1. Crear las asignaciones de Azure Policy de la tabla siguiente en el ámbito del grupo de administración de
espacios aislados:
N O M B RE DESC RIP C IÓ N N OTA S SO B RE L A A SIGN A C IÓ N
Deny-VNET-Peering-Cross- Impide que las conexiones de Asegúrese de que esta directiva solo se
Subscription emparejamiento de VNET se creen en asigna en el nivel de ámbito de la
/.AzState) otras redes virtuales fuera de la jerarquía del grupo de administración
suscripción. de espacios aislados.
N O M B RE DESC RIP C IÓ N N OTA S SO B RE L A A SIGN A C IÓ N
Denied-Resources Recursos cuya creación se deniega en Al asignar esta directiva, seleccione los
/.AzState/Microsoft.Authorization_polic las suscripciones del espacio aislado. siguientes recursos para denegar la
yAssignments-Denied- Esto impedirá que los recursos de creación de: Puertas de enlace de VPN:
Resources.parameters.json) conectividad híbrida se creen. Por microsoft.network/vpngateways ,
ejemplo, puertas de enlace P2S:
VPN/ExpressRoute/VirtualWAN microsoft.network/p2svpngateways ,
instancias de Virtual WAN:
microsoft.network/virtualwans ,
centros de conectividad de Virtual
WAN:
microsoft.network/virtualhubs ,
circuitos ExpressRoute:
microsoft.network/expressroutecircuits
, puertas de enlace de ExpressRoute:
microsoft.network/expressroutegateways
, puertos ExpressRoute:
microsoft.network/expressrouteports
, conexiones cruzadas de ExpressRoute:
microsoft.network/expressroutecrossconnections
y puertas de enlace de red local:
microsoft.network/localnetworkgateways
.
Deploy-Budget-Sandbox /.AzState) Garantiza la existencia de un Si durante la asignación de la directiva

presupuesto para cada suscripción de los parámetros no se cambian de sus
espacio aislado, con las alertas por valores predeterminados, se creará el
correo electrónico habilitadas. El presupuesto (
presupuesto se denominará default-sandbox-budget ) con un
default-sandbox-budget en cada límite de moneda de 1000 y se enviará
suscripción. una alerta por correo electrónico a los
propietarios y colaboradores de la
suscripción (según la asignación de
roles de Azure) cuando se alcance el
90 % y el 100 % del umbral de
presupuesto.
Conectividad y redes globales

1. Asigne un intervalo de CIDR de red virtual adecuado para cada región de Azure en la que se vayan a
implementar los conmutadores virtuales y los centros de conectividad virtuales.
2. Si decide crear los recursos de red mediante Azure Policy, asigne las directivas que se muestran en la
tabla siguiente a la suscripción de conectividad. Al hacerlo, Azure Policy se asegura de que los recursos de
la lista siguiente se creen según los parámetros proporcionados.
Cree una instancia Estándar de Azure Virtual WAN.
Cree un centro de conectividad virtual de Azure Virtual WAN para cada región. Asegúrese de que se
implemente al menos una puerta de enlace (Azure ExpressRoute o VPN) por cada centro virtual.
Proteja los centros de conectividad virtuales mediante la implementación de Azure Firewall en cada
uno de ellos.
Cree directivas de Azure Firewall obligatorias y asígnelas a los centros de conectividad virtuales
seguros.
Asegúrese de que todas las redes virtuales conectadas a un centro de conectividad virtual seguro
estén protegidas por Azure Firewall.
3. Implemente y configure una zona DNS privada de Azure.
4. Aprovisione circuitos ExpressRoute con emparejamiento privado de Azure. Siga las instrucciones de
Creación y modificación del emparejamiento de un circuito ExpressRoute.
5. Conecte HQ/DC locales a los centros virtuales de Azure Virtual WAN a través de circuitos ExpressRoute.
6. Proteja el tráfico de red virtual entre centros de conectividad virtuales con grupos de seguridad de red
(NSG).
7. (Opcional) Configure el cifrado sobre el emparejamiento privado de ExpressRoute. Siga las instrucciones
que se indican en Cifrado de ExpressRoute: IPsec sobre ExpressRoute para Virtual WAN.
8. (Opcional) Conecte ramas al centro de conectividad virtual a través de VPN. Siga las instrucciones de
Creación de una conexión de sitio a sitio mediante Azure Virtual WAN.
9. (Opcional) Configure Global Reach de ExpressRoute para conectar HQ/DC locales cuando haya más de
una ubicación local conectada a Azure a través de ExpressRoute. Siga las instrucciones de Configuración
de ExpressRoute Global Reach.
En la siguiente lista se muestran las asignaciones de Azure Policy que se usan al implementar recursos de red
para una implementación a escala empresarial:
Deploy-FirewallPolicy Crea una directiva de firewall.

/.AzState/Microsoft.Authorization_policyDefinitions-Deploy-
FirewallPolicy.parameters.json)
Deploy-VHub Esta directiva implementa un centro de conectividad virtual,

/.AzState/Microsoft.Authorization_policyDefinitions-Deploy- Azure Firewall y puertas de enlace de VPN y ExpressRoute.
vHUB.parameters.json) También configura la ruta predeterminada en las redes
virtuales conectadas a Azure Firewall.
Deploy-VWAN Implementa una instancia de Virtual WAN.

vWAN.parameters.json)

1. Defina y aplique un marco de habilitación del servicio para asegurarse de que los servicios de Azure
cumplan los requisitos de seguridad y gobernanza de la empresa.
2. Cree definiciones de roles personalizados.
3. Habilite PIM de Azure AD y detecte los recursos de Azure para facilitar la aplicación de PIM.
4. Cree grupos de solo Azure AD para la administración de recursos de plano de control de Azure mediante
PIM de Azure AD.
5. Aplique las directivas que aparecen en la siguiente tabla para asegurarse de que los servicios de Azure
sean compatibles con los requisitos empresariales.
6. Defina una convención de nomenclatura y aplíquela a través de Azure Policy.
7. Cree una matriz de directivas en todos los ámbitos (por ejemplo, habilite la supervisión de todos los
servicios de Azure mediante Azure Policy).
Las siguientes directivas deben usarse para aplicar un estado de cumplimiento en toda la compañía.
Allowed-ResourceLocation Especifica la región permitida en la que se pueden

/.AzState/Microsoft.Authorization_policyAssignments- implementar los recursos.
Allowed-ResourceLocation.parameters.json)
Allowed-RGLocation Especifica la región permitida en la que se pueden

/.AzState/Microsoft.Authorization_policyAssignments- implementar los grupos de recursos.
Allowed-RGLocation.parameters.json)
Denied-Resources Los recursos que la empresa rechaza.

/.AzState/Microsoft.Authorization_policyAssignments-
Denied-Resources.parameters.json)
Deny-AppGW-Without-WAF Permite las puertas de enlace de aplicación implementadas

/.AzState/Microsoft.Authorization_policyDefinitions-Deny- con Azure Web Application Firewall (WAF) habilitado.
AppGW-Without-WAF.parameters.json)
Deny-IP-Forwarding Deniega el reenvío IP.

/.AzState/Microsoft.Authorization_policyAssignments-Deny-
IP-Forwarding.parameters.json)
Deny-RDP-From-Internet Deniega las conexiones RDP desde Internet.

/.AzState/Microsoft.Authorization_policyAssignments-Deny-
RDP-From-Internet.parameters.json)
Deny-Subnet-Without-Nsg Deniega la creación de la subred sin un grupo de seguridad

/.AzState/Microsoft.Authorization_policyDefinitions-Deny- de red.
Subnet-Without-Nsg.parameters.json)
Deploy-ASC-CE Configura la exportación continua de Azure Security Center

/.AzState/Microsoft.Authorization_policyDefinitions-Deploy- en el área de trabajo de Log Analytics.
ASC-CE.parameters.json)
Deploy-ASC-Monitoring Habilita la supervisión en Security Center.

/.AzState/Microsoft.Authorization_policyAssignments-
Deploy-ASC-Monitoring.parameters.json)
Deploy-ASC-Standard Garantiza que las suscripciones tengan habilitado Security

/.AzState/Microsoft.Authorization_policyDefinitions-Deploy- Center Estándar.
ASC-Standard.parameters.json)
Deploy-Diag-ActivityLog Permite el análisis de registros de diagnóstico y el reenvío a

/.AzState/Microsoft.Authorization_policyDefinitions-Deploy- Log Analytics.
Diagnostics-ActivityLog.parameters.json)
Deploy-Diag-LogAnalytics
Log-Analytics.parameters.json)
Deploy-VM-Monitoring Garantiza que la supervisión de VM esté habilitada.

Diagnostics-VM.parameters.json)
Identidad de la plataforma
1. Si crea los recursos de identidad mediante Azure Policy, asigne las directivas que se muestran en la tabla
siguiente a la suscripción de identidad. Al hacerlo, Azure Policy se asegura de que los recursos de la lista
siguiente se creen según los parámetros proporcionados.
2. Implemente controladores de dominio de Active Directory.
En la siguiente lista se muestran las directivas que se pueden usar al implementar recursos de identidad para
una implementación a escala empresarial.
DataProtectionSecurityCenter /.AzState/) Protección de datos creada automáticamente por Security

Center.
Deploy-VNet-Identity Implementa una red virtual en la suscripción de identidad

/.AzState/Microsoft.Authorization_policyDefinitions-Deploy- para hospedar (por ejemplo, un controlador de dominio).
vNet.parameters.json)
Supervisión y administración de la plataforma

1. Cree paneles de seguridad y cumplimiento de directivas para las vistas de organización y las centradas en
recursos.
2. Cree un flujo de trabajo para los secretos de la plataforma (entidades de servicio y cuenta de
automatización) y la sustitución de claves.
3. Configure el archivado y la retención a largo plazo de los registros de Log Analytics.
4. Configure Azure Key Vault para almacenar los secretos de la plataforma.
5. Si decide crear los recursos de administración de la plataforma mediante Azure Policy, asigne las
directivas que se muestran en la tabla siguiente a la suscripción de administración. Al hacerlo, Azure
Policy se asegura de que los recursos de la lista siguiente se creen según los parámetros proporcionados.
Deploy-LA-Config Configura el área de trabajo de Log Analytics.

LA-Config.parameters.json)
Deploy-Log-Analytics Implementa un área de trabajo de Log Analytics.

Log-Analytics.parameters.json)
Archivo -> Nuevo -> Región

1. Si crea los recursos de red mediante Azure Policy, asigne las directivas que se muestran en la tabla
siguiente a la suscripción de conectividad. Al hacerlo, Azure Policy se asegura de que los recursos de la
lista siguiente se creen según los parámetros proporcionados.
En la suscripción de conectividad, cree un nuevo centro de conectividad virtual en la instancia
existente de Virtual WAN.
Proteja el centro de conectividad virtual mediante la implementación de Azure Firewall en el centro de
conectividad virtual y vincule las directivas de firewall nuevas o existentes a Azure Firewall.
Asegúrese de que todas las redes virtuales conectadas a un centro de conectividad virtual seguro
estén protegidas por Azure Firewall.
2. Conecte el centro de conectividad virtual a la red local a través de ExpressRoute o VPN.
3. Proteja el tráfico de red virtual entre centros virtuales con grupos de seguridad de red.
4. (Opcional) Configure el cifrado sobre el emparejamiento privado de ExpressRoute.
Deploy-VHub Esta directiva implementa un centro de conectividad virtual,

/.AzState/Microsoft.Authorization_policyDefinitions-Deploy- Azure Firewall y puertas de enlace (VPN/ExpressRoute).
vHUB.parameters.json) También configura la ruta predeterminada en las redes
virtuales conectadas a Azure Firewall.
Archivo -> Nuevo -> Zona de aterrizaje para aplicaciones y cargas de

trabajo
1. Cree una suscripción y muévala en el ámbito del grupo de administración de Landing Zones .
2. Cree grupos de Azure AD para la suscripción, como Owner , Reader y Contributor .
3. Cree derechos PIM de Azure AD para los grupos de Azure AD establecidos.
Módulo Terraform para Cloud Adoption Framework
a escala empresarial
Azure proporciona servicios nativos para implementar las zonas de aterrizaje. Otras herramientas de terceros
también pueden ayudarle con este trabajo. Una herramienta de este tipo que los clientes y asociados suelen
usar para implementar zonas de aterrizaje es Terraform de HashiCorp.
En esta sección se muestra cómo usar el módulo Terraform oficial para Cloud Adoption Framework a escala
empresarial para acelerar la administración de zonas de aterrizaje de Azure a escala mediante Terraform.
Objetivo de las zonas de aterrizaje de escala empresarial

El módulo Terraform para Cloud Adoption Framework a escala empresarial proporciona un método simplificado
para implementar la jerarquía de grupos de administración y suscripciones desde la arquitectura de referencia
de escala empresarial mediante Terraform, lo que permite:
1. Una jerarquía de recursos administrados para la organización de suscripciones mediante grupos de
administración.
2. Un modelo de gobernanza y seguridad escalable mediante Azure Policy y Access Control (IAM) , con una
amplia biblioteca de definiciones personalizadas listas para asignar.
3. Una configuración de la gobernanza y la seguridad aplicadas en las suscripciones a través de la herencia de
grupos de administración.
Al empaquetar estas funcionalidades en un solo módulo Terraform, resulta más fácil crear y aplicar la coherencia
en la plataforma de Azure al trabajar a escala.
Uso de módulos estándar

La reutilización de componentes es un principio fundamental de la infraestructura como código. Los módulos
son fundamentales para definir los estándares y la coherencia a través de la implementación de recursos dentro
y entre entornos. Este módulo se publica en el registro de Terraform oficial y lo comprueba HashiCorp.
Diagrama de la arquitectura
El módulo Terraform para Cloud Adoption Framework a escala empresarial implementa los siguientes
componentes de la arquitectura de referencia de escala empresarial:
Figura 1: información general de los recursos implementados por el módulo Terraform para Cloud Adoption
Framework de escala empresarial.
Capacidades
Los componentes implementados y su finalidad incluyen lo siguiente:
C O M P O N EN T E RESP O N SA B IL IDA D
Grupos de administración Los grupos de administración principales proporcionan las

bases de la jerarquía de recursos de la arquitectura de
referencia de escala empresarial:
Grupos de administración opcionales para zonas de
aterrizaje de demostración (SAP, corp. y en línea).
Grupos de administración opcionales para zonas de
aterrizaje personalizadas (defina los suyos).
Azure Policy Azure Policy permite proporcionar seguridad y gobernanza

en toda la plataforma:
Definiciones de directivas personalizadas y definiciones de
conjuntos de directivas que cubren patrones de gobernanza
comunes no cubiertos por las directivas integradas.
Crear y asignar directivas en cualquier ámbito dentro de la
jerarquía de grupos de administración para garantizar que el
cumplimiento se aplica a través de la herencia.
Expandir con sus definiciones personalizadas, con el fin de
satisfacer sus requisitos específicos de gobernanza y
seguridad.
Configuración de Access control (IAM) Crear y asignar roles en la jerarquía de recursos para
garantizar el cumplimiento de las directivas de RBAC:
Crear definiciones de roles personalizados para garantizar
el principio de privilegios mínimos.
Crear asignaciones de roles en el ámbito adecuado para
asegurarse de que los equipos de plataforma y aplicación
tengan los permisos adecuados.
Suscripciones Las suscripciones se asignan a grupos de administración:

Habilitar la herencia de directivas y RBAC
Garantizar el cumplimiento de los requisitos de
gobernanza y seguridad de la plataforma
Personalización e implementación
Para facilitar la familiarización con este módulo, se ha publicado en el registro de Terraform, lo que permite
utilizarlo directamente desde el registro como un módulo reutilizable y poder beneficiarse de las actualizaciones
cuando se publican.
Estas son las únicas dependencias de este módulo:
Terraform (versión recomendada: 0.13.2 y versiones posteriores)
Proveedor de AzureRM (versión recomendada: 2.34.0 y versiones posteriores)
IMPORTANT
Existen varios problemas conocidos con ciertas combinaciones de versiones de Terraform y del proveedor de AzureRM.
Algunos de ellos se deben a que han surgido nuevos errores, que se han corregido, mientras que otros son errores
transitorios, que normalmente se pueden resolver volviendo a ejecutar la implementación. Por lo general, se recomienda
usar siempre versiones específicas y hacer pruebas exhaustivas antes realizar cualquier actualización. Cuando se publica
cada versión nueva del módulo, el equipo del proyecto planea fusionar mediante cambio de base el módulo para
garantizar la compatibilidad con las versiones más recientes tanto de Terraform como del proveedor de AzureRM.
Ejemplo sencillo
A continuación se facilita una configuración de inicio simple para el módulo raíz main.tf :
TIP
Aunque el módulo tiene solo una variable obligatoria root_parent_id , se recomienda establecer también root_id . Al
cambiar el valor root_id se iniciará una nueva implementación completa de todos los recursos administrados por el
módulo, incluidas las dependencias de nivel inferior.
# We strongly recommend using the required_providers block to set the
# Azure Provider source and version being used.
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = ">= 2.46.1"
}
}
}
provider "azurerm" {
features {}
}
# You can use the azurerm_client_config data resource to dynamically

# extract the current Tenant ID from your connection settings.
data "azurerm_client_config" "current" {

}
# Call the caf-enterprise-scale module directly from the Terraform Registry

# pinning to the latest version
module "enterprise_scale" {
source = "Azure/caf-enterprise-scale/azurerm"
version = "0.1.0"
root_parent_id = data.azurerm_client_config.current.tenant_id
root_id = "demo"
Este código de ejemplo implementará el grupo de administración y la organización de suscripciones mínimos

recomendados desde la arquitectura de referencia de escala empresarial. Posteriormente, una vez que todo esto
esté funcionando, se puede empezar a personalizar la implementación.
TIP
Si es la primera vez que utiliza Terraform, consulte este tutorial sobre HashiCorp Learn, en el que encontrará información
sobre la instalación y el uso de Terraform, así como las guías del proveedor de AzureRM para obtener información sobre
cómo configurar el proveedor y autenticarlo en Azure.
Pasos siguientes
El módulo Terraform para Cloud Adoption Framework de escala empresarial proporciona una manera rápida de
crear sus zonas de aterrizaje a escala empresarial. También proporciona una gran flexibilidad para expandir y
personalizar la implementación, a la vez que conserva un enfoque simplificado para administrar la
configuración de cada zona de aterrizaje.
Para más información, examine el módulo en el registro de Terraform y consulte el wiki de GitHub, donde se
publicarán más ejemplos y tutoriales que explican cómo personalizar cualquier implementación.
Examen del módulo en el registro de Terraform
Transición de entornos existentes de Azure a escala
empresarial
Somos conscientes de que es posible que la mayoría de las organizaciones tenga una experiencia previa en
Azure, una o más suscripciones y, posiblemente, una estructura existente con sus grupos de administración. En
función de sus requisitos empresariales y escenarios iniciales, es posible que se hayan implementado recursos
de Azure como, por ejemplo, la conectividad híbrida (por ejemplo, con VPN de sitio a sitio o ExpressRoute).
Este artículo ayuda a las organizaciones a recorrer el camino correcto según un entorno de Azure existente que
realiza la transición a la escala empresarial. En este artículo también se describen las consideraciones para el
traslado de recursos de Azure (por ejemplo, el traslado de una suscripción de un grupo de administración
existente a otro), lo que le ayudará a evaluar y planear la transición del entorno de Azure existente a zonas de
aterrizaje de escala empresarial.
Traslado de recursos de Azure

Algunos recursos de Azure se pueden migrar después de la creación y hay diferentes enfoques que las
organizaciones pueden adoptar en función de los permisos de RBAC de Azure de los usuarios en los diferentes
ámbitos y entre estos. En la tabla siguiente se describen los recursos que se pueden trasladar, a qué ámbito lo
pueden hacer y las ventajas y desventajas asociadas a cada uno de ellos.
Á M B ITO DEST IN AT IO N VEN TA JA S DESVEN TA JA S
Recursos de grupos de Pueden trasladarse al nuevo Permite modificar la - No admitido por todos los
recursos grupo de recursos en la composición de los recursos resourceTypes
misma suscripción o en otra de un grupo de recursos - Algunos de los
diferente después de la resourceTypes tienen
implementación limitaciones o requisitos
específicos
- Los ResourceIds están
actualizados y afectan a las
operaciones de supervisión,
alertas y plano de control
existentes
- Los grupos de recursos
están bloqueados durante
el período de traslado
- Requiere la evaluación de
las directivas y el RBAC
antes y después de la
operación de traslado
Suscripciones de un Pueden trasladarse a No afecta a los recursos Requiere la evaluación de

inquilino distintos grupos de existentes de la suscripción, las directivas y el RBAC
administración ya que no se cambiará antes y después de la
ningún valor de resourceId operación de traslado
Para comprender qué estrategia de traslado se debe usar, veremos ejemplos de ambas:
Traslado de suscripción
Los casos de uso habituales para el traslado de suscripciones son para organizar las suscripciones en grupos de
administración o al transferir las suscripciones a un nuevo inquilino de Azure Active Directory. Los traslados de
suscripciones a escala empresarial se centran en transferirlas a grupos de administración. El objetivo principal
de trasladar una suscripción a un nuevo inquilino es transferir la propiedad de la facturación.
Requisitos de RBAC de Azure
Para evaluar una suscripción antes de un traslado, es importante que el usuario tenga la configuración de RBAC
de Azure adecuada, como Propietario de la suscripción (asignación de rol directa), y que tenga permiso de
escritura en el grupo de administración de destino (los roles integrados que admiten esto son Propietario,
Colaborador y Colaborador de grupo de administración).
Si el usuario tiene un permiso heredado de Propietario en la suscripción de un grupo de administración
existente, la suscripción solo se puede trasladar al grupo de administración en el que se ha asignado el rol de
Propietario al usuario.
Directiva
Las suscripciones existentes pueden estar sujetas a las directivas de Azure asignadas directamente o en el grupo
de administración en el que están ubicadas actualmente. Es importante evaluar las directivas actuales y las
directivas que pueden existir en el nuevo grupo de administración o jerarquía de grupos de administración.
Azure Resource Graph se puede usar para realizar un inventario de los recursos existentes y comparar su
configuración con las directivas existentes en el destino.
Una vez que las suscripciones se hayan trasladado a un grupo de administración con la configuración de RBAC
de Azure y directivas ya existentes, tenga en cuenta las siguientes opciones:
Cualquier configuración de RBAC de Azure que se herede en las suscripciones trasladadas puede tardar
hasta 30 minutos antes de que se actualicen los tokens de usuario en la memoria caché del grupo de
administración. Para acelerar este proceso, puede actualizar el token cerrando la sesión y volviendo a
iniciarla, o solicitando un nuevo token.
Todas las directivas en las que el ámbito de la asignación incluya las suscripciones trasladadas realizará
operaciones de auditoría solo en los recursos existentes. Más concretamente:
Cualquier recurso existente de la suscripción sujeto al efecto de una directiva DeployIfNotExists
aparecerá como no compatible y no se corregirá automáticamente, sino que requerirá la interacción
del usuario para realizar la corrección manualmente.
Cualquier recurso existente en la suscripción sujeto al efecto de directiva Deny aparecerá como no
compatible y no se rechazará. El usuario debe mitigar manualmente este resultado según
corresponda.
Cualquier recurso existente en la suscripción sujeto a los efectos de directiva Append y Modify
aparecerá como no compatible y requerirá la interacción del usuario para su mitigación.
Cualquier recurso existente en la suscripción sujeto a los efectos de directiva Audit y
AuditIfNotExist aparecerá como no compatible y requerirá la interacción del usuario para su
mitigación.
Todas las nuevas escrituras en los recursos de la suscripción trasladada están sujetas a las directivas
asignadas en tiempo real de la forma habitual.
Movimiento de recurso
Los casos de uso principales para realizar un traslado de recursos son: consolidar recursos en el mismo grupo
de recursos si comparten el mismo ciclo de vida, o trasladar recursos a una otra suscripción debido al costo, la
propiedad o los requisitos de RBAC de Azure.
Al realizar un traslado de recursos, el grupo de recursos de origen y el de destino están bloqueados (este
bloqueo no afectará a ninguno de los recursos del grupo de recursos) durante la operación de traslado, lo que
significa que no se pueden agregar, actualizar ni eliminar los recursos de los grupos de recursos. La operación
de traslado de los recursos no cambiará la ubicación de estos.
Antes de trasladar los recursos
Antes de realizar una operación de traslado, debe comprobar que se admiten los recursos del ámbito así como
evaluar sus requisitos y dependencias. Por ejemplo, para trasladar una red virtual emparejada es necesario
deshabilitar el emparejamiento de redes virtuales primero y volver a habilitarlo una vez que se haya
completado la operación de traslado. Esta operación para deshabilitar y volver a habilitar la dependencia
requiere una planeación previa para comprender el impacto en las cargas de trabajo existentes que puedan
estar conectadas a las redes virtuales.
Después de la operación de traslado
Si los recursos se trasladan a un nuevo grupo de recursos de la misma suscripción, se seguirán aplicando las
directivas y la configuración de RBAC de Azure heredados del grupo de administración o ámbito de la
suscripción. Si se trasladan a un grupo de recursos de una suscripción nueva, en la que la suscripción puede
estar sujeta a otra configuración de RBAC de Azure y otra asignación de directivas, se aplican las mismas
directrices que al escenario de traslado de suscripción para validar la compatibilidad de recursos y los controles
de acceso.
Implementación de una zona de aterrizaje de
migración en Azure
Una zona de aterrizaje de migración es un entorno que se ha aprovisionado y preparado para hospedar las
cargas de trabajo que se van a migrar desde un entorno local a Azure.
Implementación del plano técnico

Antes de usar el plano técnico de la zona de aterrizaje de migración de CAF en Cloud Adoption Framework,
revise los siguientes principios de diseño, supuestos, decisiones e instrucciones de implementación. Si esta guía
se ajusta al plan de adopción de la nube, siga los pasos del ejemplo técnico de la zona de aterrizaje de migración
de CAF para la implementación.
Implementación del ejemplo de plano técnico
Esta opción de implementación proporciona un enfoque bien fundamentado para las áreas de diseño comunes
que comparten todas las zonas de aterrizaje de Azure. Consulte los supuestos y decisiones siguientes para
obtener detalles técnicos adicionales.
Esta opción implementa un producto mínimo viable (MVP) para iniciar una migración. A medida que progresa la
migración, el cliente seguirá un enfoque basado en la refactorización de módulos para consolidar el modelo
operativo en orientación paralela, mediante la metodología de gobernanza y la metodología de administración
para abordar esos temas complejos en paralelo a la iniciativa inicial de migración.
Los recursos específicos que implementa este enfoque de MVP se describen en la sección sobre decisiones que
aparece a continuación.
Inscripciones de la empresa
Esta opción de implementación no adopta una postura inherente sobre la inscripción empresarial. Este enfoque
está diseñado para aplicarse a los clientes, independientemente de los acuerdos contractuales con Microsoft o
los asociados de Microsoft. Antes de implementar esta opción, se supone que el cliente ha creado una
suscripción de destino.
Identidad
Esta opción de implementación supone que la suscripción de destino ya está asociada a una instancia de Azure
Active Directory de acuerdo con los procedimientos recomendados de administración de identidades.
Esta opción creará una red virtual con subredes para la puerta de enlace, el firewall, el jumpbox y la zona de
aterrizaje. Como iteración siguiente, el equipo seguiría la guía de toma de decisiones sobre redes para
implementar la forma adecuada de conectividad entre la subred de puerta de enlace y otras redes, en
consonancia con los procedimientos recomendados de seguridad de red.
Esta opción de implementación crea una sola zona de aterrizaje, en la que los recursos se organizarán en cargas
de trabajo definidas por grupos de recursos específicos. Al elegir este enfoque minimalista para la organización
de recursos, se aplaza la decisión técnica de la organización de recursos hasta que el modelo de funcionamiento
en la nube del equipo se defina con mayor claridad.
Este enfoque está basado en la suposición de que la iniciativa de adopción de la nube no superará los límites de
suscripción. Esta opción también presupone unos requisitos limitados de seguridad y complejidad
arquitectónica dentro de esta zona de aterrizaje.
Si esto cambiara durante el plan de adopción de la nube, podría ser necesario refactorizar la organización de
recursos con las instrucciones de la metodología de gobernanza.
Materias de gobernanza
Esta opción no implementa ninguna herramienta de gobernanza. En ausencia de una automatización de
directivas definida, esta zona de aterrizaje no debe usarse para cargas de trabajo críticas ni para datos
confidenciales. Se supone que esta zona de aterrizaje se usa para la implementación de producción limitada, a
fin de iniciar el aprendizaje, la iteración y el desarrollo del modelo operativo general en paralelo a estas
iniciativas tempranas de migración.
Para agilizar el desarrollo en paralelo de las materias de gobernanza, revise la metodología de gobernanza y
plantéese la posibilidad de implementar el plano técnico de fundamentos de CAF, además del plano técnico de
la zona de aterrizaje de migración de CAF.
WARNING
A medida que se consolidan las materias de gobernanza, puede ser necesario refactorizarlas. En concreto, los recursos
pueden moverse a una nueva suscripción o grupo de recursos más adelante.
Base de referencia de operaciones

Esta opción no implementa ninguna operación. En ausencia de una base de referencia de operaciones definida,
esta zona de aterrizaje no debe usarse para cargas de trabajo críticas ni para datos confidenciales. Se supone
que esta zona de aterrizaje se usa para la implementación de producción limitada, a fin de iniciar el aprendizaje,
la iteración y el desarrollo del modelo operativo general en paralelo a estas iniciativas tempranas de migración.
Para agilizar el desarrollo paralelo de una base de referencia de operaciones, consulte la metodología de
administración y plantéese la posibilidad de implementar la guía de administración de servidores de Azure.
WARNING
A medida que se desarrolla la base de referencia de las operaciones, podría ser necesaria la refactorización. En concreto,
los recursos pueden moverse a una nueva suscripción o grupo de recursos más adelante.
Recuperación ante desastres y continuidad empresarial (BCDR )

Esta opción no implementa ninguna solución de continuidad empresarial y recuperación ante desastres. Se
supone que el desarrollo de la base de referencia de las operaciones se encargará de la solución de protección y
recuperación.
Supuestos
Esta zona de aterrizaje inicial incluye las siguientes suposiciones o restricciones. Si estas suposiciones van
acordes con las restricciones, puede usar el plano técnico para crear la primera zona de aterrizaje. El plano
técnico también se puede ampliar para crear un plano técnico de la zona de aterrizaje que cumpla las
restricciones únicas.
Límites de suscripción: no se espera que este esfuerzo de adopción supere los límites de suscripción.
Cumplimiento: no se necesita ningún requisito de cumplimiento de terceros en esta zona de aterrizaje.
Complejidad de la arquitectura: la complejidad de la arquitectura no requiere suscripciones de
producción adicionales.
Ser vicios compar tidos: no hay servicios compartidos en Azure que requieran que esta suscripción se trate
como un radio en una arquitectura en estrella tipo hub-and-spoke.
Ámbito de producción limitado: esta zona de aterrizaje podría hospedar cargas de trabajo de producción.
Sin embargo, no constituye un entorno adecuado para los datos confidenciales o las cargas de trabajo
críticas.
Si estas suposiciones se adaptan a las necesidades de adopción actuales, este plano técnico podría ser un buen
punto de partida para empezar a crear la zona de aterrizaje.
Decisiones
Las siguientes decisiones se representan en el plano técnico de la zona de aterrizaje.
C O M P O N EN T E DEC ISIO N ES EN F O Q UES A LT ERN AT IVO S
Herramientas de migración Azure Site Recovery se implementará y Guía para la toma de decisiones de las
se creará un proyecto de Azure herramientas de migración
Migrate.
Registro y supervisión Se aprovisionará a la cuenta de

almacenamiento de diagnósticos y el
área de trabajo de Operational
Insights.
Red Se creará una red virtual con subredes Decisiones respecto a las redes
para la puerta de enlace, el firewall, el
jumpbox y la zona de aterrizaje.
Identidad Se da por sentado que la suscripción Procedimientos recomendados de

ya está asociada a una instancia de administración de identidades
Azure Active Directory.
Directiva En la actualidad, en este plano técnico

se da por hecho que no se aplicará
ninguna directiva de Azure.
Detalles de la suscripción N/A: diseñado para una sola Creación de las suscripciones iniciales
suscripción de producción.
Grupos de recursos N/A: diseñado para una sola Escalado de suscripciones

Grupos de administración N/A: diseñado para una sola Organización y administración de

suscripción de producción. suscripciones
data N/D Elección de la opción correcta de

SQL Server en Azure y Guía de un
almacén de datos para Azure
Storage N/D Guía de Azure Storage
Estándares de nomenclatura y N/D Procedimientos recomendados de

etiquetado nomenclatura y etiquetado
Administración de costos N/D Seguimiento de costos
Proceso N/D Opciones de proceso
Personalización o implementación de una zona de aterrizaje

Obtenga más información y descargue un ejemplo de referencia del plano técnico de la zona de aterrizaje de
migración de CAF para implementarlo o personalizarlo de los ejemplos de planos técnicos de Azure.
Para obtener instrucciones sobre la personalización que se debe realizar en este plano técnico o la zona de
aterrizaje resultante, consulte las consideraciones de zona de aterrizaje.
Pasos siguientes
Después de implementar la primera zona de aterrizaje, ya está listo para expandirla.
Expansión de la zona de aterrizaje
Implementación de un plano técnico de
fundamentos de CAF en Azure
El plano técnico de fundamentos de CAF no implementa una zona de aterrizaje. En su lugar, implementa las
herramientas necesarias para establecer un MVP (producto mínimo viable) de gobernanza para comenzar a
desarrollar las materias de gobernanza. Este plano técnico está diseñado para ser el complemento de una zona
de aterrizaje existente y se puede aplicar al plano técnico de la zona de aterrizaje de migración de CAF con una
sola acción.
Implementación del plano técnico

Antes de usar el plano técnico de fundamentos de CAF en Cloud Adoption Framework, revise los siguientes
principios de diseño, supuestos, decisiones e instrucciones de implementación. Si esta guía se adapta al plan de
adopción de la nube deseado, el plano técnico de fundamentos de CAF se puede implementar mediante los
pasos de implementación.
Esta opción de implementación proporciona un enfoque bien fundamentado para las áreas de diseño comunes
que comparten todas las zonas de aterrizaje de Azure. Consulte los supuestos y decisiones siguientes para
obtener detalles técnicos adicionales.
Esta opción implementa un MVP que funciona como base para las materias de gobernanza. El equipo seguirá un
enfoque basado en la refactorización de módulos para consolidar las materias de gobernanza mediante la
metodología de gobernanza.
Inscripciones de la empresa
Esta opción de implementación no adopta una postura inherente en la inscripción empresarial. Este enfoque
está diseñado para aplicarse a los clientes, independientemente de los acuerdos contractuales con Microsoft o
sus asociados. Antes de implementar esta opción, se supone que el cliente ya ha creado una suscripción de
destino.
Identidad
Esta opción de implementación supone que la suscripción de destino ya está asociada a una instancia de Azure
Active Directory de acuerdo con los procedimientos recomendados de administración de identidades.
Esta opción de implementación supone que la zona de aterrizaje ya tiene una topología de red definida según
los procedimientos recomendados de seguridad de red.
Esta opción de implementación muestra cómo Azure Policy puede agregar algunos elementos de organización
de recursos mediante la aplicación de etiquetas. En concreto, se aplicará una etiqueta CostCenter a los recursos
mediante Azure Policy.
El equipo de gobernanza debe comparar y contrastar los elementos de la organización de recursos que se
abordarán al etiquetarlos, frente a los que se deben abordar a través del diseño de suscripciones. Estas
decisiones tan importantes informarán a la organización de recursos a medida que progresen los planes de
Para facilitar esta comparación en etapas tempranas de los ciclos de adopción, se deben tener en cuenta los
siguientes artículos:
Suscripciones a Azure iniciales: en esta fase de la escala de adopción, ¿el modelo operativo requiere de dos,
tres o cuatro suscripciones?
Escalado de suscripciones: a medida que se escala la adopción, ¿qué criterios se usarán para impulsar el
escalado de suscripciones?
Organización de suscripciones: ¿cómo se organizan las suscripciones a medida que se escalan?
Estándares de etiquetado: ¿qué otros criterios deben capturarse de forma coherente en las etiquetas para
reforzar el diseño de las suscripciones?
Para ayudar en esta comparación cuando los equipos ya han avanzado el proceso de adopción de la nube,
consulte la sección de patrones de gobernanza en el artículo guía de gobernanza: instrucciones prescriptivas. En
esta sección de la guía prescriptiva se muestra un conjunto de patrones basados en un modelo de narrativa y
funcionamiento específicos. En esta guía también se incluyen vínculos a otros patrones que deben tenerse en
cuenta.
Esta implementación muestra un enfoque hacia la consolidación de la materia de administración de costos de la
metodología de gobernanza. En concreto, muestra cómo se puede usar Azure Policy para crear una lista de
permitidos para SKU específicas. Al limitar los tipos y tamaños de recursos que se pueden implementar en una
zona de aterrizaje, se reduce el riesgo de gastos innecesarios.
Para agilizar el desarrollo en paralelo de las otras materias de gobernanza, revise la metodología de gobernanza.
Para continuar la consolidación de la materia de administración de costos de gobernanza, consulte la guía de la
materia de administración de costos.
WARNING
A medida que se consolidan las materias de gobernanza, puede ser necesario refactorizarlas. La refactorización puede
resultar necesaria. En concreto, los recursos pueden moverse a una nueva suscripción o grupo de recursos más adelante.

Esta opción no implementa ningún aspecto de la base de referencia de operaciones. En ausencia de una base de
referencia de operaciones definida, esta zona de aterrizaje no debe usarse para cargas de trabajo críticas ni para
datos confidenciales. Se supone que esta zona de aterrizaje se usa para la implementación de producción
limitada, a fin de iniciar el aprendizaje, la iteración y el desarrollo del modelo operativo general en paralelo a
estas iniciativas tempranas de migración.
Para agilizar el desarrollo paralelo de una base de referencia de operaciones, consulte la metodología de
administración y plantéese la posibilidad de implementar la guía de administración de servidores de Azure.
WARNING
A medida que se desarrolla la base de referencia de las operaciones, podría ser necesaria la refactorización. En concreto,
los recursos pueden moverse a una nueva suscripción o grupo de recursos más adelante.
Recuperación ante desastres y continuidad empresarial (BCDR )

Esta opción no implementa ninguna solución de continuidad empresarial y recuperación ante desastres. Se
supone que el desarrollo de la base de referencia de las operaciones se encargará de la solución de protección y
recuperación.
Supuestos
En este plano técnico inicial se supone que el equipo está comprometido con la consolidación de las
funcionalidades de gobernanza en paralelo a las iniciativas iniciales de migración a la nube. Si estas
suposiciones van acordes con las restricciones, puede usar el plano técnico para iniciar el proceso de
consolidación de la gobernanza.
Cumplimiento: no se necesita ningún requisito de cumplimiento de terceros en esta zona de aterrizaje.
Ámbito de producción limitado: esta zona de aterrizaje podría hospedar cargas de trabajo de producción.
Sin embargo, no constituye un entorno adecuado para los datos confidenciales o las cargas de trabajo
críticas.
Si estas suposiciones se adaptan a las necesidades de adopción actuales, este plano técnico podría ser un buen
punto de partida para empezar a crear la zona de aterrizaje.
Personalización o implementación de este plano técnico

Obtenga más información y descargue un ejemplo de referencia del plano técnico de fundamentos de CAF para
implementarlo o personalizarlo mediante los ejemplos de plano técnico de Azure.
Pasos siguientes
Después de implementar la primera zona de aterrizaje, ya está listo para expandirla.
Expansión de la zona de aterrizaje
Uso de Terraform para crear zonas de aterrizaje
Azure proporciona servicios nativos para implementar las zonas de aterrizaje. Otras herramientas de terceros
también pueden ayudarle con este trabajo. Una herramienta de este tipo que los clientes y asociados suelen
usar para implementar zonas de aterrizaje es Terraform de HashiCorp. En esta sección se muestra cómo usar
una zona de aterrizaje de ejemplo para implementar funcionalidades de gobernanza, contabilidad y seguridad
fundamentales para una suscripción de Azure.
Propósito de la zona de aterrizaje

La zona de aterrizaje básica de Cloud Adoption Framework para Terraform presenta características para aplicar
las funcionalidades de registro, contabilidad y seguridad. Esta zona de aterrizaje usa componentes estándar
conocidos como módulos de Terraform para aplicar la coherencia entre los recursos implementados en el
entorno.
Uso de módulos estándar

La reutilización de componentes es un principio fundamental de la infraestructura como código. Los módulos
son fundamentales para definir los estándares y la coherencia a través de la implementación de recursos dentro
y entre entornos. Los módulos usados para implementar esta primera zona de aterrizaje están disponible en el
registro de Terraform oficial.
Diagrama de la arquitectura
La primera zona de aterrizaje implementa los siguientes componentes en su suscripción:
Figura 1: Zona de aterrizaje básica con Terraform.
Capacidades
Los componentes implementados y su finalidad incluyen lo siguiente:
Grupos de recursos Grupos de recursos principales necesarios para la base
Registro de actividad Realizar la auditoría de todas las actividades de suscripción y

el archivado:
Cuenta de almacenamiento
Azure Event Hubs
Registro de diagnóstico Registros de todas las operaciones que se mantienen

durante un número específico de días:
Cuenta de almacenamiento
Event Hubs
Log Analytics Almacenar los registros de operaciones. Implementar

soluciones comunes para la revisión profunda de los
procedimientos recomendados de aplicaciones:
NetworkMonitoring
AdAssessment
AdReplication
AgentHealthAssessment
DnsAnalytics
KeyVaultAnalytics
Azure Security Center Métricas de higiene de seguridad y alertas enviadas al correo

electrónico y al número de teléfono
Uso de este plano técnico

Antes de usar la zona de aterrizaje básica de Cloud Adoption Framework, revise los supuestos, las decisiones y
las instrucciones de implementación siguientes.
Supuestos
Las siguientes suposiciones o restricciones se tuvieron en cuenta cuando se definió esta zona de aterrizaje
inicial. Si estas suposiciones van acordes con las restricciones, puede usar el plano técnico para crear la primera
zona de aterrizaje. El plano técnico también se puede ampliar para crear un plano técnico de la zona de
aterrizaje que cumpla las restricciones únicas.
Límites de suscripción: no es probable que este trabajo de adopción supere los límites de suscripción. Dos
indicadores comunes constituyen un exceso de 25 000 máquinas virtuales o 10 000 vCPU.
Cumplimiento: no se necesita ningún requisito de cumplimiento de terceros para esta zona de aterrizaje.
Complejidad de la arquitectura: la complejidad de la arquitectura no requiere suscripciones de
producción adicionales.
Ser vicios compar tidos: no hay servicios compartidos en Azure que requieran que esta suscripción se trate
como un radio en una arquitectura en estrella tipo hub-and-spoke.
Si estas suposiciones coinciden con su entorno actual, este plano técnico podría ser un buen punto de partida
para empezar a crear la zona de aterrizaje.
Decisiones de diseño
Las siguientes decisiones se representan en los módulos de CAF Terraform:
Registro y supervisión Se utiliza el área de trabajo de Log

Analytics de Azure Monitor. Se
aprovisionará una cuenta de
almacenamiento de diagnósticos y un
centro de eventos.
Red N/A: la red se implementa en otra zona Decisiones respecto a las redes
de aterrizaje.
Identidad Se da por sentado que la suscripción Procedimientos recomendados de

ya está asociada a una instancia de administración de identidades
Azure Active Directory.
Directiva En la actualidad, en esta zona de

aterrizaje se da por hecho que no se
aplicará ninguna directiva de Azure.
Detalles de la suscripción N/A: diseñado para una sola Creación de las suscripciones iniciales
Grupos de recursos N/A: diseñado para una sola Escalado de suscripciones

Grupos de administración N/A: diseñado para una sola Organización de suscripciones

data N/D Elección de la opción correcta de

SQL Server en Azure y Guía de un
almacén de datos para Azure
Storage N/D Guía de Azure Storage
Estándares de nomenclatura Cuando se crea el entorno, también se Procedimientos recomendados de

crea un prefijo único. Los recursos que nomenclatura y etiquetado
requieren un nombre único global
(como las cuentas de almacenamiento)
utilizan este prefijo. El nombre
personalizado se anexa con un sufijo
aleatorio. El uso de etiquetas se ordena
como se describe en la tabla siguiente.
Administración de costos N/D Seguimiento de costos
Proceso N/D Opciones de proceso
Estándares de etiquetado
El conjunto de etiquetas mínimas siguiente debe estar presente en todos los recursos y grupos de recursos:
N O M B RE DE ET IQ UETA DESC RIP C IÓ N C L AVE VA LO RES DE E JEM P LO
Unidad de negocio División de nivel superior de BusinessUnit finance , marketing ,

la empresa que posee la <product-name> , corp ,
suscripción o la carga de shared
trabajo a la que pertenece
el recurso.
Centro de costos Centro de costo de CostCenter <cost-center-number>

contabilidad asociado a este
recurso.
N O M B RE DE ET IQ UETA DESC RIP C IÓ N C L AVE VA LO RES DE E JEM P LO
Recuperación ante desastres Importancia empresarial de DR dr-enabled ,

la aplicación, la carga de non-dr-enabled
trabajo o el servicio.
Entorno Entorno de implementación Env prod , dev , qa ,

de la aplicación, la carga de staging , test ,
trabajo o el servicio. training
Nombre del propietario Propietario de la aplicación, Owner email

la carga de trabajo o el
servicio.
Tipo de implementación Define cómo se mantienen DeploymentType manual , terraform

los recursos.
Versión Versión del plano técnico Version v0.1

implementado.
Nombre de la aplicación Nombre de la aplicación, el ApplicationName <app-name>

servicio o la carga de
trabajo que se ha asociado
al recurso.
Personalizar e implementar la primera zona de aterrizaje

Puede clonar la zona de aterrizaje básica de Terraform. Empiece trabajar fácilmente con la zona de aterrizaje
mediante la modificación de las variables de Terraform. En nuestro ejemplo, usamos
blueprint_foundations.sandbox.auto.tfvars , de modo que Terraform establece automáticamente los valores
de este archivo.
Echemos un vistazo a las diferentes secciones de variables.
En este primer objeto, se crean dos grupos de recursos en la región southeastasia , denominados
-hub-core-sec y -hub-operations , junto con un prefijo agregado en tiempo de ejecución.
resource_groups_hub = {
HUB-CORE-SEC = {
name = "-hub-core-sec"
location = "southeastasia"
}
HUB-OPERATIONS = {
name = "-hub-operations"
location = "southeastasia"
}
}
A continuación, se especifican las regiones en las que se pueden establecer las bases. En este caso, se utiliza
southeastasia para implementar todos los recursos.
location_map = {
region1 = "southeastasia"
region2 = "eastasia"
}
A continuación, se especifica el período de retención para los registros de operaciones y los registros de
suscripción de Azure. Estos datos se almacenan en cuentas de almacenamiento independientes y en un centro
de eventos, cuyos nombres se generan de forma aleatoria, ya que deben ser únicos.
azure_activity_logs_retention = 365
azure_diagnostics_logs_retention = 60
En tags_hub, se especifica el conjunto mínimo de etiquetas que se aplican a todos los recursos creados.
tags_hub = {
environment = "DEV"
owner = "Arnaud"
deploymentType = "Terraform"
costCenter = "65182"
BusinessUnit = "SHARED"
DR = "NON-DR-ENABLED"
}
A continuación, se especifica el nombre de la instancia de Log Analytics y un conjunto de soluciones que

analizan la implementación. Aquí se conservan las características de supervisión de red,
Active Directory Assessment, replicación de Active Directory, DNS Analytics y Key Vault Analytics.
analytics_workspace_name = "lalogs"
solution_plan_map = {
NetworkMonitoring = {
"publisher" = "Microsoft"
"product" = "OMSGallery/NetworkMonitoring"
},
ADAssessment = {
"product" = "OMSGallery/ADAssessment"
},
ADReplication = {
"product" = "OMSGallery/ADReplication"
},
AgentHealthAssessment = {
"product" = "OMSGallery/AgentHealthAssessment"
},
DnsAnalytics = {
"product" = "OMSGallery/DnsAnalytics"
},
KeyVaultAnalytics = {
"product" = "OMSGallery/KeyVaultAnalytics"
}
}
A continuación, se configuran los parámetros de alerta de Azure Security Center.
# Azure Security Center Configuration

security_center = {
contact_email = "[email protected]"
contact_phone = "+6500000000"
}
Realizar acción
Una vez que haya revisado la configuración, podrá implementar la configuración como implementaría un
entorno de Terraform. Se recomienda usar el róver, que es un contenedor de Docker que permite la
implementación desde Windows, Linux o MacOS. Puede empezar a trabajar con las zonas de aterrizaje.
Pasos siguientes
La zona de aterrizaje básica establece la base para un entorno complejo de forma descompuesta. Esta edición
proporciona un conjunto de funcionalidades sencillas que se pueden ampliar agregando otros módulos al plano
técnico o superponiendo zonas de aterrizaje adicionales sobre ella.
La distribución en capas de las zonas de aterrizaje es un buen procedimiento para desacoplar sistemas, realizar
el control de versiones de cada componente que utiliza, y permitir la innovación rápida y la estabilidad para su
implementación de infraestructura como código.
Las arquitecturas de referencia futuras mostrarán este concepto para una topología de concentrador y radio.
Revisar la zona de aterrizaje de Terraform básica de ejemplo
Expansión de una zona de aterrizaje
Esta sección de la metodología de preparación se basa en los principios de la refactorización de la zona de

aterrizaje. Como se describe en este artículo, un enfoque de refactorización a la infraestructura como código
elimina los elementos que bloquean el éxito de una empresa y, al mismo tiempo, minimiza el riesgo. En esta
serie de artículos se supone que ya ha implementado su primera zona de aterrizaje y desea expandirla para
cumplir los requisitos empresariales.
Principios arquitectónicos compartidos

La expansión de la zona de aterrizaje proporciona un enfoque de programación básica para insertar los
siguientes principios en la zona de aterrizaje y, de forma más amplia, en el entorno de nube global.
Figura 1: Principios arquitectónicos compartidos.

Estos mismos principios arquitectónicos los comparten Azure Advisor, el marco de buena arquitectura de
Microsoft Azurey las soluciones del Centro de arquitectura de Azure.
Aplicación de estos principios a las mejoras de la zona de aterrizaje

Para una mejor alineación con las metodologías de Cloud Adoption Framework, los principios anteriores se
agrupan en mejoras de la zona de aterrizaje que requieren acciones:
Consideraciones básicas: refactorice una zona de aterrizaje para refinar el hospedaje, los fundamentos y
otros elementos básicos.
Expansiones de operaciones: agregue configuraciones de administración de operaciones para mejorar el
rendimiento, la confiabilidad y la excelencia operativa .
Expansiones de gobernanza: agregue configuraciones de la gobernanza para mejorar el costo, la
confiabilidad, la seguridad y la coherencia.
Expansiones de seguridad: agregue configuraciones de la seguridad para mejorar la protección de los datos
confidenciales y los sistemas críticos.
WARNING
Los equipos de adopción que tengan como objetivo a medio plazo (24 meses) hospedar más de 1000 recursos
(aplicaciones, infraestructura o recursos de datos) en la nube deben tener en cuenta todas estas expansiones al
principio del proceso de adopción de la nube. En el caso de los restantes patrones de adopción, las expansiones de la zona
de aterrizaje pueden ser una iteración paralela, lo que permite un éxito temprano en la empresa.
Pasos siguientes
Antes de refactorizar la primera zona de aterrizaje, es importante conocer el desarrollo controlado por pruebas
de las zonas de aterrizaje.
Desarrollo controlado por pruebas de las zonas de aterrizaje
Consideraciones sobre la zona de aterrizaje
Una zona de aterrizaje es el bloque de creación básico de cualquier entorno de adopción de la nube. El término
zona de aterrizaje hace referencia a un entorno que se ha aprovisionado y preparado para hospedar cargas de
trabajo en un entorno en la nube como Azure. Una zona de aterrizaje plenamente funcional es el resultado final
de cualquier iteración de la metodología de preparación de Cloud Adoption Framework.
Figura 1: Consideraciones sobre la zona de aterrizaje.

Esta imagen muestra las principales consideraciones para realizar cualquier implementación de la zona de
aterrizaje. Las consideraciones se pueden dividir en tres categorías o tipos: hospedaje, aspectos básicos de Azure
y gobernanza.
Consideraciones sobre hospedaje

Todas las zonas de aterrizaje proporcionan una estructura para las opciones de hospedaje. La estructura se crea
explícitamente mediante controles de gobernanza u orgánicamente mediante la adopción de servicios dentro de
la zona de aterrizaje. Los artículos siguientes pueden ayudarle a tomar decisiones que se reflejarán en el plano
técnico o en otros scripts de automatización que crean la zona de aterrizaje:
Decisiones de proceso: Para minimizar la complejidad operativa, adapte las opciones de proceso a la
finalidad de la zona de aterrizaje. Esta decisión se puede llevar a la práctica mediante cadenas de
herramientas de automatización, como las iniciativas de Azure Policy y las zonas de aterrizaje.
Decisiones sobre el almacenamiento: Seleccione la solución de Azure Storage adecuada que cumpla los
requisitos de las cargas de trabajo.
Decisiones respecto a las redes: Elija los servicios, las herramientas y las arquitecturas de red que cumplan
los requisitos de carga de trabajo, gobernanza y conectividad de su organización.
Decisiones respecto a las bases de datos: Determinar qué tecnología de base de datos es la más adecuada
para sus requisitos de cargas de trabajo.

Cada zona de aterrizaje forma parte de una solución más amplia para organizar los recursos a través de un
entorno en la nube. Los aspectos básicos de Azure constituyen los bloques de creación fundamentales de
cualquier organización.
Conceptos básicos de Azure: Conozca los conceptos y términos fundamentales que se usan para organizar
los recursos en Azure y cómo los conceptos se relacionan entre sí.
Guía de decisiones con coherencia de recursos: Una vez que comprenda cada uno de los aspectos básicos, la
guía para la toma de decisiones sobre la organización de recursos puede ayudarle a tomar las decisiones que
darán forma a la zona de aterrizaje.
Consideraciones de gobernanza
Las metodologías de gobierno de Cloud Adoption Framework establecen un proceso que permite gobernar el
entorno en su conjunto. Hay muchos casos de uso que pueden requerir que se tomen decisiones de gobernanza
al respecto de cada zona de aterrizaje. En muchos escenarios, las bases de referencia de gobernanza se aplican
por zona de aterrizaje, aunque se hayan establecido de manera holística. Esto es aplicable a las primeras zonas
de aterrizaje que una organización implementa.
Los artículos siguientes pueden ayudarle a tomar decisiones relacionadas con la gobernanza respecto a su zona
de aterrizaje. Puede tener en cuenta cada decisión en las líneas de base de gobernanza.
Requisitos de costos. Según la motivación de una organización en relación con los compromisos
operativos y de adopción de la nube respecto a su entorno, es posible que sea necesario cambiar varias
configuraciones de administración de costos para la zona de aterrizaje.
Decisiones relacionadas con la super visión. En función de los requisitos operativos para una zona de
aterrizaje, se pueden implementar varias herramientas de supervisión. El artículo sobre la toma de
decisiones relacionadas con la supervisión le puede ayudar a determinar las herramientas más adecuadas
que puede implementar.
Control de acceso basado en rol de Azure. El control de acceso basado en rol de Azure (RBAC de Azure)
ofrece administración de acceso específico basado en grupos para recursos organizados en torno a roles de
usuario.
Decisiones sobre directivas . Los ejemplos de plano técnico de Azure proporcionan planos técnicos de
cumplimiento previamente creados, cada uno con iniciativas de directivas predefinidas. Las decisiones sobre
directivas le informan sobre una selección del mejor plano técnico o iniciativa de directiva según sus
requisitos y restricciones.
Creación de coherencia en la nube híbrida . Cree soluciones de nube híbrida que ofrezcan a su
organización las ventajas de la innovación en la nube conservando muchas de las comodidades de la
administración local.
Revisión de las opciones de proceso
La determinación de los requisitos de proceso para hospedar las cargas de trabajo es una consideración
importante a la hora de prepararse para la adopción de la nube. Los productos y servicios de proceso de Azure
admiten una amplia variedad de escenarios y funcionalidades de computación de la carga de trabajo. El modo
en que se configure el entorno de la zona de aterrizaje para satisfacer los requisitos de proceso depende de los
requisitos de gobernanza, técnicos y empresariales de la carga de trabajo.
Identificación de los requisitos de los servicios de proceso

Como parte de la evaluación y preparación de la zona de aterrizaje, debe identificar todos los recursos de
proceso que deba admitir dicha zona. Este proceso implica la evaluación de cada una de las aplicaciones y
servicios que componen las cargas de trabajo para determinar los requisitos de proceso y hospedaje. Después
de identificar y documentar los requisitos, puede crear directivas para la zona de aterrizaje con el fin de
controlar qué tipos de recursos se permiten en función de las necesidades de su carga de trabajo.
Para cada aplicación o servicio que vaya a implementar en el entorno de la zona de aterrizaje, use el siguiente
árbol de decisión como punto de partida para ayudarlo a determinar los requisitos de los servicios de proceso:
Figura 1: Árbol de decisión de los servicios de proceso de Azure.

Definiciones:
"Lift-and-shift" es una estrategia de migración de una carga de trabajo a la nube sin volver a diseñar la
aplicación ni realizar cambios en el código. También se denomina rehospedaje. Para más información,
consulte Azure Migration Center.
"Optimizado para la nube" es una estrategia de migración a la nube mediante la refactorización de una
aplicación para aprovechar las funcionalidades y características nativas de la nube.
La salida de este diagrama de flujo es un punto de inicio para tenerlo en consideración. A continuación, realice
una evaluación más detallada del servicio para ver si satisface sus necesidades.
NOTE
Más información sobre cómo evaluar las opciones de proceso para cada una de sus aplicaciones o servicios en la guía de
arquitectura de aplicaciones de Azure.
Preguntas clave
Responda a las siguientes preguntas sobre las cargas de trabajo como ayuda para tomar decisiones basadas en
el árbol de decisión de los servicios de proceso de Azure:
¿Va a crear aplicaciones y ser vicios o a migrar a par tir de cargas de trabajo locales existentes?
El desarrollo de nuevas aplicaciones como parte de las labores de adopción de la nube permite sacar el
máximo partido de las modernas tecnologías de hospedaje basadas en la nube desde la fase de diseño en
adelante.
Si va a migrar cargas de trabajo existentes, ¿pueden aprovechar las modernas tecnologías de la
nube? La migración de cargas de trabajo locales requiere análisis. ¿Se pueden optimizar fácilmente las
aplicaciones y los servicios existentes para aprovechar las modernas tecnologías de la nube o funcionará
mejor un enfoque de migración mediante lift-and-shift con las cargas de trabajo?
¿Pueden aprovechar las aplicaciones o ser vicios los contenedores? Si las aplicaciones son buenas
candidatas para el hospedaje en contenedor, puede aprovechar las funcionalidades de eficacia de recursos,
escalabilidad y orquestación proporcionadas por los servicios de contenedor de Azure. Tanto Azure Managed
Disks como Azure Files se pueden usar para el almacenamiento persistente en aplicaciones en contenedor.
¿Están basadas las aplicaciones en web o en API y usan PHP, ASP.NET, Node.js o tecnologías
similares? Las aplicaciones web se pueden implementar en instancias de Azure App Service administradas,
por lo que no tiene que mantener máquinas virtuales con fines de hospedaje.
¿Necesitará control total sobre el sistema operativo y el entorno de hospedaje de la carga de
trabajo? Si necesita controlar el entorno de hospedaje, incluidos el sistema operativo, los discos, el software
que se ejecuta localmente y otras configuraciones, puede usar Azure Virtual Machines para hospedar sus
aplicaciones y servicios. Además de elegir los tamaños de máquina virtual y los niveles de rendimiento, las
decisiones relacionadas con el almacenamiento de discos virtuales afectarán al rendimiento y a los Acuerdos
de Nivel de Servicio (SLA) relacionados con las cargas de trabajo de infraestructura como servicio. Para más
información, consulte la documentación sobre almacenamiento en disco de Azure.
¿En la carga de trabajo inter vienen funcionalidades de informática de alto rendimiento (HPC)?
Azure Batch proporciona programación de trabajos y escalabilidad automática de recursos de proceso como
servicio de plataforma, lo que facilita la ejecución de aplicaciones de HPC y paralelas a gran escala en la
nube.
¿Van a usar las aplicaciones una arquitectura de microser vicios? Las aplicaciones que usan una
arquitectura basada en microservicios pueden aprovechar varias tecnologías de proceso optimizadas. Las
cargas de trabajo basadas en eventos independientes pueden usar Azure Functions para compilar
aplicaciones escalables y sin servidor que no necesitan una infraestructura. En el caso de las aplicaciones que
requieren más control sobre el entorno en el que se ejecutan los microservicios, puede usar servicios de
contenedor, como Azure Container Instances, Azure Kubernetes Service y Azure Service Fabric.
NOTE
La mayoría de los servicios de proceso de Azure se usan en combinación con Azure Storage. Consulte la guía de
decisiones de almacenamiento para información sobre las decisiones relacionadas con el almacenamiento.
Escenarios comunes de proceso

En la tabla siguiente se muestran algunos escenarios de uso comunes y los servicios de proceso recomendados
para gestionarlos:
ESC EN A RIO SERVIC IO C O M P UT E
Necesito aprovisionar máquinas virtuales Linux y Windows Azure Virtual Machines

en cuestión de segundos con las configuraciones de mi
elección.
Necesito conseguir alta disponibilidad con la escalabilidad Conjuntos de escalado de máquinas virtuales
automática para crear miles de máquinas virtuales en
cuestión de minutos.
Quiero simplificar la implementación, la administración y las Azure Kubernetes Service (AKS)

operaciones de Kubernetes.
Necesito acelerar el desarrollo de aplicaciones con una Funciones de Azure

arquitectura sin servidor basada en eventos.
Necesito desarrollar microservicios y organizar los Azure Service Fabric

contenedores en Windows y Linux.
Quiero crear rápidamente aplicaciones en la nube para web y Azure App Service
móviles mediante una plataforma totalmente administrada.
Quiero incluir aplicaciones en contenedores y ejecutar Azure Container Instances

fácilmente contenedores con un solo comando.
Necesito escalar a la nube la programación de trabajos y la Azure Batch

administración de procesos con la posibilidad de escalar
hasta decenas, centenares o miles de máquinas virtuales.
Necesito crear aplicaciones en la nube escalables y de alta Azure Cloud Services

disponibilidad, así como API que me ayuden a centrarme en
las aplicaciones y no en el hardware.
Disponibilidad regional
Azure le permite ofrecer servicios a la escala que necesita para llegar a sus clientes y asociados, dondequiera
que se encuentren . Uno de los factores clave a la hora de planear la implementación en la nube es determinar
qué región de Azure hospedará los recursos de la carga de trabajo.
Algunas servicios de proceso, como Azure App Service, tienen disponibilidad general en la mayoría de las
regiones de Azure mientras que otros solo se admiten en determinadas regiones. Algunos tipos de máquinas
virtuales y sus tipos de almacenamiento asociados tienen una disponibilidad regional limitada. Antes de decidir
en qué regiones va a implementar los recursos de proceso, se recomienda que consulte la página de regiones
para comprobar el estado más reciente de la disponibilidad regional.
Para más información sobre la infraestructura global de Azure, consulte la página de regiones de Azure. También
puede ver los productos disponibles por región para conocer detalles específicos sobre los servicios generales
que están disponibles en cada región de Azure.
Requisitos de cumplimiento y residencia de datos

Con frecuencia, se aplicarán a las cargas de trabajo los requisitos legales y contractuales que están relacionados
con el almacenamiento de datos. Estos requisitos pueden variar en función de la ubicación de la organización, la
jurisdicción en la que se almacenan y procesan los archivos y los datos y el sector empresarial aplicable. Entre
los componentes de las obligaciones de datos que deben tenerse en cuenta se incluyen la clasificación de datos,
la ubicación de los datos y las responsabilidades correspondientes relativas a la protección de datos en el
modelo de responsabilidad compartida. Muchas soluciones de proceso dependen de recursos de
almacenamiento vinculados. Este requisito también podría influir en las decisiones de proceso. Para comprender
estos requisitos, consulte las notas del producto Consecución de la seguridad y la residencia de datos
compatibles con Azure.
Parte de sus esfuerzos de cumplimiento puede incluir el control del lugar donde sus recursos de base de datos
se encuentran físicamente. Las regiones de Azure se organizan por grupos llamados zonas geográficas. Una
zona geográfica de Azure garantiza que se cumplan los requisitos de residencia, soberanía, cumplimiento
normativo y resistencia de los datos dentro de las fronteras geográficas y políticas. Si sus cargas de trabajo
están sujetas a la soberanía de datos u otros requisitos de cumplimiento, debe implementar sus recursos de
almacenamiento en regiones que se encuentren en una zona geográfica de Azure compatible.
Establecimiento de controles para servicios de proceso

Al preparar el entorno de la zona de aterrizaje, puede establecer controles que limiten qué recursos puede
implementar cada usuario. Los controles pueden ayudarle a administrar los costos y a limitar los riesgos de
seguridad, al tiempo que permiten a los desarrolladores y equipos de TI implementar y configurar los recursos
necesarios para admitir las cargas de trabajo.
Después de identificar y documentar los requisitos de la zona de aterrizaje, puede usar Azure Policy para
controlar los recursos de proceso que permite que creen los usuarios. Los controles pueden tener la forma de
permitir o denegar la creación de tipos de recursos de proceso. Por ejemplo, puede restringir a los usuarios que
solo creen recursos Azure App Service o Azure Functions. También puede usar directivas para controlar las
opciones permitidas cuando se crea un recurso, como restringir las SKU de máquina virtual que se pueden
aprovisionar o permitir solo imágenes de máquina virtual específicas.
Las directivas se pueden limitar a recursos, grupos de recursos, suscripciones y grupos de administración. Puede
incluir las directivas en las definiciones de Azure Blueprints y aplicarlas varias veces a todo el patrimonio de la
nube.
Revisión de las opciones de red
El diseño y la implementación de las funcionalidades de redes de Azure es una parte fundamental de las labores
de adopción de la nube. Deberá tomar decisiones sobre el diseño de redes para acomodar correctamente las
cargas de trabajo y los servicios que se hospedarán en la nube. Los servicios y productos de redes de Azure
admiten una amplia variedad de funcionalidades de red. La forma de estructurar estos servicios y las
arquitecturas de red que elija depende de los requisitos de carga de trabajo, gobernanza y conectividad de su
organización.
Identificación de los requisitos de red de la carga de trabajo

Como parte de la evaluación y preparación de la zona de aterrizaje, debe identificar las funcionalidades de red
que debe admitir la zona de aterrizaje. Este proceso supone evaluar cada una de las aplicaciones y servicios que
componen las cargas de trabajo para determinar sus requisitos de control de red de conectividad. Después de
identificar y documentar los requisitos, puede crear directivas para la zona de aterrizaje con el fin de controlar la
configuración y los recursos de red permitidos en función de las necesidades de su carga de trabajo.
árbol de decisión como punto de partida para que le ayude a determinar las herramientas o los servicios de red
que debe usar:
Ilustración 1: Árbol de decisión de servicios de red de Azure.
Preguntas clave
Responda a las siguientes preguntas sobre las cargas de trabajo para tomar decisiones basadas en el árbol de
decisión de servicios de red de Azure:
¿Necesitarán las cargas de trabajo una red vir tual? Los tipos de recursos de plataforma como servicio
(PaaS) administrados usan funcionalidades de red de la plataforma subyacente que no siempre necesitan
una red virtual. Si las cargas de trabajo no necesitan características de red avanzadas y no es necesario
implementar recursos de infraestructura como servicio (IaaS), las funcionalidades de red nativas
predeterminadas que proporcionan los recursos de PaaS podrían satisfacer su requisitos de conectividad y
administración del tráfico de la carga de trabajo.
¿Necesitarán las cargas de trabajo conectividad entre las redes vir tuales y el centro de recursos
local? Azure proporciona dos soluciones para establecer las funcionalidades de red híbrida: Azure VPN
Gateway y Azure ExpressRoute. Azure VPN Gateway conecta las redes locales a Azure mediante VPN de sitio
a sitio, de forma muy parecida a cómo podría configurar una sucursal remota y conectarse a ella. VPN
Gateway tiene un ancho de banda máximo de 10 Gbps. Azure ExpressRoute ofrece una mayor confiabilidad y
una menor latencia gracias al uso de una conexión privada entre Azure y la infraestructura local. Las
opciones de ancho de banda de ExpressRoute van de 50 Mbps a 100 Gbps.
¿Necesitará inspeccionar y auditar el tráfico saliente mediante dispositivos de red locales? En el
caso de cargas de trabajo nativas de la nube, puede usar Azure Firewall o aplicaciones virtuales de red (NVA)
de terceros hospedadas en la nube para inspeccionar y auditar el tráfico que entra en la red pública de
Internet o sale de ella. Sin embargo, muchas de las directivas de seguridad de TI de la empresa requieren que
el tráfico saliente enlazado a Internet pase por dispositivos administrados centralmente en el entorno local
de la organización. La tunelización forzada admite estos escenarios. No todos los servicios administrados
admiten la tunelización forzada. Servicios y características, como App Service Environment de Azure App
Service, Azure API Management, Azure Kubernetes Service (AKS), Instancia administrada de Azure SQL,
Azure Databricks y Azure HDInsight admiten esta configuración cuando el servicio o la característica se
implementa dentro de una red virtual.
¿Necesita conectar varias redes vir tuales? Puede usar emparejamiento de redes virtuales para conectar
varias instancias de Azure Virtual Network. El emparejamiento puede admitir conexiones entre suscripciones
y regiones. En el caso de escenarios en los que se proporcionan servicios que se comparten entre varias
suscripciones o en los que es necesario administrar un gran número de emparejamientos de red, considere
la posibilidad de adoptar una arquitectura de red de concentrador y radio, o bien usar Azure Virtual WAN. El
emparejamiento de redes virtuales solo proporciona conectividad entre dos redes emparejadas. De forma
predeterminada, no proporciona conectividad transitiva entre varios emparejamientos.
¿Serán accesibles sus cargas de trabajo a través de Internet? Azure proporciona servicios que están
diseñados para ayudarlo a administrar y proteger el acceso externo a sus aplicaciones y servicios:
Azure Firewall
Aplicaciones de red
Azure Front Door
Introducción a Puerta de enlace de aplicaciones
Azure Traffic Manager
¿Deberá admitir la administración de DNS personalizada? Azure DNS es un servicio de hospedaje
para dominios DNS. Azure DNS proporciona resolución de nombres mediante la infraestructura de Azure. Si
las cargas de trabajo requieren una resolución de nombres que supere las características proporcionadas por
Azure DNS, puede que tenga que implementar otras soluciones. Si las cargas de trabajo también requieren
servicios de Active Directory, considere la posibilidad de usar Azure Active Directory Domain Services para
aumentar las funcionalidades de Azure DNS. Para obtener más funcionalidades, también puede implementar
máquinas virtuales de IaaS personalizadas para satisfacer sus necesidades.
Escenarios comunes de redes

Las redes de Azure se componen de varios productos y servicios que proporcionan diferentes funcionalidades
de red. Como parte del proceso de diseño de redes, puede comparar los requisitos de carga de trabajo con los
escenarios de red de la tabla siguiente para identificar las herramientas o los servicios de Azure que puede usar
para proporcionar estas funcionalidades de red:
ESC EN A RIO P RO DUC TO O SERVIC IO DE RED
Necesito que infraestructura de red conecte todo, desde Azure Virtual Network
máquinas virtuales a conexiones VPN entrantes.
Necesito equilibrar las conexiones entrantes y salientes y las Equilibrador de carga de Azure
solicitudes a mis aplicaciones o servicios.
Quiero optimizar la entrega desde las granjas de servidores Introducción a Puerta de enlace de aplicaciones
de aplicaciones y aumentar al mismo tiempo la seguridad de Azure Front Door
las aplicaciones con un firewall de aplicaciones web.
Necesito usar Internet de forma segura para acceder a Azure VPN Gateway
instancias de Azure Virtual Network con instancias de VPN
Gateway de alto rendimiento.
Quiero garantizar respuestas de DNS ultrarrápidas y una DNS de Azure

disponibilidad ultraalta para todas mis necesidades de
dominio.
Necesito acelerar la entrega de contenido de alto ancho de Azure Content Delivery Network
banda a clientes de todo el mundo, desde aplicaciones y
contenido almacenado hasta streaming de vídeo.
Necesito proteger mis aplicaciones de Azure de ataques de Azure DDoS Protection

DDoS.
Necesito distribuir el tráfico de forma óptima a los servicios Azure Traffic Manager
entre regiones globales de Azure, y proporcionar al mismo
tiempo alta disponibilidad y capacidad de respuesta. Azure Front Door
Necesito agregar conectividad de red privada para acceder a Información técnica de ExpressRoute
los servicios en la nube de Microsoft desde mis redes
corporativas, como si estuvieran en el entorno local y
residieran en su propio centro de datos.
Quiero supervisar y diagnosticar condiciones en un nivel de Azure Network Watcher

escenario de red.
Necesito funcionalidades nativas de firewall con alta Azure Firewall

disponibilidad integrada, escalabilidad en la nube sin
restricciones y cero mantenimiento.
Necesito conectar de forma segura las oficinas de negocio, Azure Virtual WAN
las ubicaciones comerciales y los sitios.
Necesito un punto de entrega escalable y con seguridad Azure Front Door

mejorada para aplicaciones web globales basadas en
microservicios.
Elección de una arquitectura de red

Después de identificar los servicios de red de Azure que necesita para admitir sus cargas de trabajo, también
debe diseñar la arquitectura que combinará estos servicios para proporcionar la infraestructura de red de la
nube de la zona de aterrizaje. En la Guía de decisiones sobre redes definidas por software del marco de
adopción de la nube se proporcionan detalles sobre algunos de los patrones de arquitectura de red más
comunes usados en Azure.
En la tabla siguiente se resumen los escenarios principales que admiten estos patrones:
ESC EN A RIO A RQ UIT EC T URA DE RED SUGERIDA
Todas las cargas de trabajo hospedadas en Azure e Solo PaaS

implementadas en la zona de aterrizaje se basarán por
completo en PaaS, no requerirán una red virtual y no
formarán parte de un esfuerzo mayor de adopción de la
nube que incluya los recursos de IaaS.
Las cargas de trabajo hospedadas en Azure implementarán Nativo de la nube

recursos basados en IaaS, como máquinas virtuales, o
requerirán una red virtual, pero no requieren conectividad
con el entorno local.
Las cargas de trabajo hospedadas en Azure requieren acceso Red perimetral en la nube
limitado a los recursos locales, pero es necesario tratar las
conexiones de la nube como que no son de confianza.
Las cargas de trabajo hospedadas en Azure requieren acceso Híbrido

limitado a los recursos locales, y tiene pensado implementar
directivas de seguridad maduras y proteger la conectividad
entre la nube y el entorno local.
Necesita implementar y administrar un gran número de Concentrador y radio

máquinas virtuales y cargas de trabajo, lo que puede superar
posiblemente los límites de suscripción de Azure, debe
compartir los servicios entre las suscripciones, o necesita una
estructura más segmentada para la segregación de roles,
aplicaciones o permisos.
Tiene muchas sucursales que necesitan conectarse entre sí y Azure Virtual WAN
con Azure.
Centro de datos virtual de Azure

Además de usar uno de estos patrones de arquitectura, si el grupo de TI de la empresa administra entornos de
nube de gran tamaño, considere la posibilidad de consultar Zona de aterrizaje de escala empresarial de CAF. Al
diseñar la infraestructura de nube basada en Azure, la zona de aterrizaje de escala empresarial de CAF ofrece un
enfoque combinado de las redes, la seguridad, la administración y la infraestructura si tiene un objetivo a medio
plazo (dentro de 24 meses) para hospedar más de 1000 activos (aplicaciones, infraestructura o
recursos de datos) en la nube .
En las organizaciones que cumplen los siguientes criterios, es posible que también desee empezar con la zona
de aterrizaje de escala empresarial de CAF:
Su empresa está sujeta a los requisitos de cumplimiento normativo, que exigen funcionalidades de
supervisión y auditoría centralizadas.
Debe mantener el cumplimiento de las directivas comunes y de la gobernanza, y el control de TI centralizado
de los servicios principales.
Su sector depende de una plataforma compleja que requiere controles complejos y un conocimiento
profundo del dominio para controlar la plataforma. Esto es lo más habitual en grandes empresas del sector
financiero, petrolífero y gasístico, o de fabricación.
Las directivas de gobernanza de TI existentes requieren una paridad más ajustada con las características
existentes, incluso durante la adopción en fases tempranas.
Seguimiento de los procedimientos recomendados de redes de Azure

Como parte del proceso de diseño de redes, consulte estos artículos:
Planeamiento de redes virtuales. Obtenga información sobre cómo planear redes virtuales según los
requisitos de aislamiento, conectividad y ubicación.
Procedimientos recomendados de seguridad de la red de Azure. Más información sobre los procedimientos
recomendados de Azure que pueden ayudarlo a mejorar la seguridad de la red.
Procedimientos recomendados para la configuración de redes para las cargas de trabajo migradas a Azure.
Obtenga instrucciones adicionales sobre cómo implementar redes de Azure para admitir cargas de trabajo
basadas en IaaS y en PaaS.
Revisión de las opciones de almacenamiento
Las funcionalidades de almacenamiento son fundamentales para admitir las cargas de trabajo y los servicios
que se hospedan en la nube. Como parte de sus preparativos de preparación para la adopción de la nube, revise
este artículo para planear y atender sus necesidades de almacenamiento.
Selección de herramientas y servicios de almacenamiento para

admitir las cargas de trabajo
Azure Storage es el servicio administrado de la plataforma Azure para proporcionar almacenamiento en la nube.
Azure Storage se compone de varias características de soporte y servicios principales. El almacenamiento en
Azure tiene una alta disponibilidad y es seguro, duradero, escalable y redundante. Revise los escenarios y
consideraciones descritos aquí para elegir los servicios de Azure pertinentes y las arquitecturas correctas para
cumplir los requisitos de carga de trabajo, gobernanza y almacenamiento de datos de la organización.
Preguntas clave
Responda a las siguientes preguntas sobre las cargas de trabajo para tomar decisiones basadas en el árbol de
decisión de Azure Storage:
¿Requieren las cargas de trabajo Disk Storage para admitir la implementación de máquinas
vir tuales de infraestructura como ser vicio (IaaS)? Azure Disk Storage proporciona funcionalidades de
disco virtual para máquinas virtuales de IaaS.
¿Será necesario proporcionar imágenes descargables, documentos u otros elementos
multimedia como par te de las cargas de trabajo? Almacenamiento de blobs de Azure proporciona la
capacidad de hospedar archivos estáticos, los cuales se pueden descargar a través de Internet. Puede hacer
que los recursos que se hospedan en Almacenamiento de blobs sean públicos, o puede limitar los recursos a
los usuarios autorizados a través de Azure Active Directory (Azure AD), claves compartidas o firmas de
acceso compartido.
¿Será necesaria una ubicación para almacenar registros de máquinas vir tuales, registros de
aplicaciones y datos de análisis? Puede usar Almacenamiento de blobs de Azure para almacenar datos
de registro de Azure Monitor.
¿Será necesario proporcionar una ubicación para la copia de seguridad, la recuperación ante
desastres o el archivado de datos relacionados con la carga de trabajo? Azure Disk Storage usa
Azure Blob Storage para proporcionar funcionalidades de copia de seguridad y recuperación ante desastres.
También puede usar Almacenamiento de blobs como ubicación para realizar copias de seguridad de otros
recursos, como los datos de SQL Server hospedados por VM de IaaS o locales.
¿Será necesario admitir las cargas de trabajo de análisis de macrodatos? Azure Data Lake Storage
Gen 2 se crea encima de Azure Blob Storage. Data Lake Storage Gen 2 puede admitir la funcionalidad de lago
de datos para grandes empresas. También puede controlar el almacenamiento de petabytes de información,
al mismo tiempo que mantiene un rendimiento de cientos de gigabits.
¿Será necesario proporcionar recursos compar tidos de archivos nativos de la nube? Azure tiene
dos servicios principales que proporcionan recursos compartidos de archivos hospedados en la nube: Azure
NetApp Files y Azure Files. Azure NetApp Files proporciona recursos compartidos de NFS de alto
rendimiento que son adecuados para cargas de trabajo empresariales habituales como SAP. Azure Files
proporciona recursos compartidos de archivos accesibles a través de SMB 3.0 y HTTPS.
¿Será necesario admitir el almacenamiento de nube híbrida para las cargas de trabajo de
informática de alto rendimiento (HPC) locales? Avere vFXT for Azure es una solución de
almacenamiento en caché híbrida que puede usar para ampliar sus funcionalidades de almacenamiento
locales mediante el almacenamiento basado en la nube. Avere vFXT for Azure está optimizado para las
cargas de trabajo HPC con mucha actividad de lectura que implican granjas de servidores de proceso de
1000 a 40 000 núcleos de CPU. Avere vFXT for Azure puede integrarse con el almacenamiento conectado a la
red (NAS) de hardware local, Almacenamiento de blobs de Azure, o ambos.
¿Será necesario llevar a cabo un archivado a gran escala y una sincronización de sus datos
locales con la nube? Los productos Azure Data Box están diseñados para ayudarle a migrar grandes
cantidades de datos desde su entorno local a la nube. Azure Data Box Gateway es un dispositivo virtual que
reside en el entorno local. Data Box Gateway le ayuda a administrar la migración de datos a gran escala a la
nube. Si es necesario analizar, transformar o filtrar datos antes de migrarlos a la nube, puede usar Azure Data
Box Edge, un dispositivo informático perimetral que admite inteligencia artificial que se implementa en su
entorno local. Data Box Edge agiliza el procesamiento y la transferencia segura de datos a Azure.
¿Desea expandir un recurso compar tido de archivos local existente para usar el
almacenamiento en la nube? Azure File Sync permite usar el servicio Azure Files como extensión de
recursos compartidos de archivos que se hospedan en sus máquinas de Windows Server locales. El servicio
de sincronización transforma Windows Server en una caché rápida de los recursos compartidos de archivos
de Azure. Permite a las máquinas locales con acceso al recurso compartido usar cualquier protocolo que esté
disponible en Windows Server.
Escenarios de almacenamiento habituales

Azure ofrece varios productos y servicios para diversas funcionalidades de almacenamiento. Además del árbol
de decisión de los requisitos de almacenamiento mostrado anteriormente, en la siguiente tabla se describen una
serie de posibles escenarios de almacenamiento y los servicios de Azure recomendados para cumplir los
requisitos del escenario.
Escenarios de almacenamiento en bloque
SERVIC IO S DE A Z URE C O N SIDERA C IO N ES SO B RE LO S
ESC EN A RIO REC O M EN DA DO S SERVIC IO S REC O M EN DA DO S
Tengo servidores de reconstrucción Azure Disk Storage (SSD Premium) En el caso de los servicios de
completa o máquinas virtuales (Hyper- producción, la opción SSD Premium
V o VMware) con almacenamiento con proporciona una baja latencia
conexión directa que ejecutan coherente y altos niveles de IOPS y
aplicaciones de línea de negocio. rendimiento.
Tengo servidores que hospedarán Azure Disk Storage (SSD estándar) Es posible que IOPS y el rendimiento
aplicaciones web y móviles. de SSD estándar sean suficientes (a un
costo menor que SSD Premium) para
los servidores de aplicaciones y web
vinculados a la CPU en producción.
Tengo una SAN empresarial o una Azure Disk Storage (SSD Premium o SSD Ultra se basa en NVMe y ofrece
matriz all-flash. Ultra) una latencia de submilisegundos con
altos niveles de IOPS y ancho de
Azure NetApp Files banda. SSD Ultra es escalable hasta
64 TB. La selección de SSD Premium y
SSD Ultra depende de los requisitos de
escalabilidad, IOPS y latencia máxima.
Tengo servidores en clúster de alta Azure Files (Premium) Las cargas de trabajo en clúster
disponibilidad (HA) (como los clústeres requieren que varios nodos monten el
de conmutación por error de Windows Azure Disk Storage (SSD Premium o mismo almacenamiento compartido
Server o la FCI de SQL Server). Ultra) subyacente para la conmutación por
error o alta disponibilidad. Los recursos
compartidos de archivos Premium
ofrecen almacenamiento compartido
que se puede montar a través de SMB.
El almacenamiento en bloque
compartido también se puede
configurar en SSD Premium o SSD
Ultra mediante soluciones de
asociados.
Tengo una base de datos relacional o Azure Disk Storage (SSD Premium o La selección de SSD Premium frente a
una carga de trabajo de Ultra) SSD Ultra depende de los requisitos de
almacenamiento de datos (como SQL escalabilidad, IOPS y latencia máxima.
Server u Oracle). SSD Ultra también reduce la
complejidad al poner fin a la necesidad
de configuración del bloque de
almacenamiento para conseguir
escalabilidad.
Tengo un clúster NoSQL (como Azure Disk Storage (SSD Premium) La oferta de SSD Premium de Azure
Cassandra o MongoDB). Disk Storage proporciona una baja
latencia constante y altos niveles de
IOPS y rendimiento.
Ejecuto contenedores con volúmenes Azure Files (estándar o Premium) Las opciones de controlador de
persistentes. volúmenes de archivos (RWX) y
Azure Disk Storage (SSD estándar, bloques (RWO) están disponibles tanto
Premium o Ultra) para Azure Kubernetes Service (AKS)
como para las implementaciones de
Kubernetes personalizadas. Los
volúmenes persistentes pueden
asignarse a un disco de Azure Disk
Storage o a un recurso compartido de
Azure Files administrado. Elija las
opciones Premium frente a las
estándar en función de los requisitos
de carga de trabajo para los
volúmenes persistentes.
Tengo un lago de datos (como un Azure Data Lake Storage Gen 2 La característica Data Lake Storage
clúster de Hadoop para los datos de Gen 2 de Azure Blob Storage
HDFS). Azure Disk Storage (SSD estándar o proporciona compatibilidad con HDFS
Premium) del servidor y escala de petabyte para
realizar análisis paralelos. También
ofrece alta disponibilidad y
confiabilidad. El software como
Cloudera puede usar SSD Premium o
estándar en nodos maestros o de
trabajo si es necesario.
Tengo una implementación de SAP o Azure Disk Storage (SSD Premium o SSD Ultra está optimizado para ofrecer
SAP HANA. Ultra) una latencia de submilisegundos para
cargas de trabajo de SAP de nivel 1.
SSD Ultra está ahora en versión
preliminar. SSD Premium con máquinas
virtuales de la serie M ofrece una
opción de disponibilidad general.
Tengo un sitio de recuperación ante Blobs en páginas de Azure El software de replicación usa los blobs
desastres con RPO/RTO estrictos que en páginas de Azure para habilitar una
se sincronizan desde mis servidores replicación de bajo costo en Azure sin
principales. que sean necesarias VM de proceso
hasta producirse la conmutación por
error. Para más información, consulte la
documentación de Azure Disk Storage.
Nota: Los blobs en páginas admiten
un máximo de 8 TB.
Escenarios de almacenamiento de archivos y objetos

Uso el servidor de archivos de Archivos de Azure Con Azure File Sync, puede almacenar
Windows. datos que apenas se usan en recursos
Azure File Sync compartidos de archivo de Azure
basados en la nube al mismo tiempo
que se almacenan en caché sus
archivos más utilizados en el entorno
local para obtener acceso rápido y
local. También puede usar la
sincronización multisitio para mantener
sincronizados los archivos entre varios
servidores. Si tiene previsto migrar sus
cargas de trabajo a una
implementación solo en la nube, Azure
Files podría ser suficiente.
Tengo un NAS empresarial (como Azure NetApp Files Si tiene una implementación local de
NetApp o Dell-EMC Isilon). NetApp, considere la posibilidad de
Azure Files (Premium) usar Azure NetApp Files para migrar su
implementación a Azure. Si usa o
migra a un servidor Windows o Linux,
o tiene necesidades básicas de
recursos compartidos de archivos,
considere la posibilidad de usar Azure
Files. Para tener acceso local de forma
ininterrumpida, use Azure File Sync
para sincronizar recursos compartidos
de archivos de Azure con recursos
compartidos de archivos locales
mediante un mecanismo de nube por
niveles.
Tengo un recurso compartido de Azure Files (estándar o Premium) La selección de niveles Premium frente
archivos (SMB o NFS). a los niveles estándar de Azure Files
Azure NetApp Files depende de IOPS, del rendimiento y de
su necesidad de coherencia de la
latencia. Si tiene una implementación
local de NetApp, considere la
posibilidad de usar Azure NetApp Files.
Si es necesario migrar sus listas de
control de acceso (ACL) y marcas de
tiempo a la nube, Azure File Sync
puede llevar todas estas opciones de
configuración a sus recursos
compartidos de archivos de Azure
como ruta de migración cómoda.
Tengo un sistema de almacenamiento Almacenamiento de blobs de Azure Almacenamiento de blobs de Azure

de objetos local para petabytes de proporciona niveles Premium, de
datos (como Dell-EMC ECS). acceso frecuente, acceso esporádico y
acceso de archivo de forma que se
adapte a sus necesidades relativas al
costo y el rendimiento de cargas de
trabajo.
Tengo una implementación de DFSR u Archivos de Azure Azure File Sync ofrece sincronización
otra forma de controlar las sucursales. multisitio para mantener sincronizados
Azure File Sync los archivos entre varios servidores y
recursos compartidos de archivos de
Azure nativos en la nube. Migre a una
superficie de almacenamiento fija en el
entorno local mediante la nube por
niveles. La nube por niveles transforma
su servidor en una caché para los
archivos pertinentes al mismo tiempo
que se escalan datos inactivos en
recursos compartidos de archivos de
Azure.
Tengo una biblioteca de cintas (en el Almacenamiento de blobs de Azure Un nivel de archivo de Azure Blob
entorno local o fuera de las (niveles de acceso esporádico o acceso Storage tendrá el costo más bajo
instalaciones) para la copia de de archivo) posible, pero puede que necesite horas
seguridad y la recuperación ante para copiar los datos sin conexión en
desastres o la retención de datos a un nivel de acceso esporádico, acceso
largo plazo. frecuente o Premium de
almacenamiento para permitir el
acceso. Los niveles de acceso
esporádico proporcionan acceso
instantáneo por un bajo costo.
Tengo el almacenamiento de archivos Almacenamiento de blobs de Azure Para hacer una copia de seguridad de
u objetos configurado para recibir mis (niveles de acceso esporádico o acceso datos para la retención a largo plazo
copias de seguridad. de archivo) con el almacenamiento de costo más
Azure File Sync bajo, migre los datos a
Almacenamiento de blobs de Azure y
use los niveles de acceso esporádico y
acceso de archivo. A fin de habilitar la
recuperación ante desastres rápida
para los datos de archivo de un
servidor (en el entorno local o en una
máquina virtual de Azure), sincronice
recursos compartidos con recursos
compartidos de archivos de Azure
individuales mediante Azure File Sync.
Con las instantáneas de recursos
compartidos de archivos de Azure,
puede restaurar versiones anteriores y
volver a sincronizarlas con servidores
conectados u obtener acceso a las
mismas de forma nativa en el recurso
compartido de archivos de Azure.
Ejecuto la replicación de datos en un Archivos de Azure Azure File Sync pone fin a la necesidad
sitio de recuperación ante desastres. de un servidor de recuperación ante
Azure File Sync desastres y almacena archivos en
recursos compartidos de SMB de
Azure. La recuperación ante desastres
rápida recompila los datos de un
servidor local erróneo de forma rápida.
Puede incluso mantener sincronizados
varias ubicaciones del servidor o usar
la nube por niveles para almacenar
solo datos pertinentes en el entorno
local.
Administro la transferencia de datos Azure Data Box Edge o Azure Data Box Con Data Box Edge o Data Box
en escenarios desconectados. Gateway Gateway, puede copiar datos en
escenarios desconectados. Si la puerta
de enlace está desconectada, guardará
todos los archivos que copie en la
memoria caché y, a continuación, los
cargará cuando esté conectado.
Administro una canalización de datos Azure Data Box Edge o Azure Data Box Migre datos a la nube desde sistemas
en curso en la nube. Gateway que generan datos de forma
ininterrumpida simplemente haciendo
que copien dichos datos directamente
en la puerta de enlace de
almacenamiento. Si tienen que obtener
acceso a dichos datos más tarde, es
justo ahí donde los colocan.
Tengo ráfagas de cantidades de datos Azure Data Box Edge o Azure Data Box Administre grandes cantidades de
que llegan al mismo tiempo. Gateway datos que llegan al mismo tiempo,
como cuando un automóvil autónomo
vuelve al garaje o una máquina de
secuenciación genética finaliza su
análisis. Copie todos los datos en Data
Box Gateway a velocidades locales
rápidas y, a continuación, permita a la
puerta de enlace cargarlos a medida
que su red lo permita.
Plan basado en las cargas de trabajo de datos

Deseo desarrollar una nueva aplicación Almacenamiento de blobs de Azure

nativa de la nube que necesite guardar
datos no estructurados.
Debo migrar datos desde una Azure NetApp Files

instancia de NetApp local a Azure.
Debo migrar datos desde instancias de Archivos de Azure

servidores de archivos de Windows
locales a Azure.
Debo migrar datos de archivo a la Archivos de Azure

nube, pero, principalmente, tengo que
seguir obteniendo acceso a los datos Azure File Sync
desde el entorno local.
Debo admitir el "proceso de ráfagas": Avere vFXT for Azure Almacenamiento en caché de archivos
cargas de trabajo basadas en archivos NFS/SMB de escalabilidad horizontal
con mucha actividad de lectura de IaaS
NFS/SMB con recursos de datos que
residen en el entorno local al mismo
tiempo que se ejecuta el cálculo en la
nube.
Debo migrar una aplicación local que Azure Disk Storage

use un disco local o iSCSI.
Debo migrar una aplicación basada en Azure Disk Storage

contenedores que tenga volúmenes
persistentes. Archivos de Azure
Debo migrar recursos compartidos de Archivos de Azure Instantánea de requisitos de

archivos que no sean de rendimiento de disponibilidad regional
Windows Server ni NetApp a la nube. Azure NetApp Files de compatibilidad con protocolos y
sensibilidad del precio de las
funcionalidades del clon
Debo transformar los terabytes en Azure Data Box Edge

petabytes de datos de local a Azure.
Debo procesar los datos antes de Azure Data Box Edge

transferirlos a Azure.
Debo admitir la ingesta de datos Azure Data Box Gateway

continua de forma automatizada
mediante la memoria caché local.
Más información sobre los servicios de Azure Storage

Una vez que identifique las herramientas de Azure que mejor coincidan con sus requisitos, use la
documentación detallada vinculada en la siguiente tabla para familiarizarse con estos servicios:
SERVIC IO DESC RIP C IÓ N
Almacenamiento de blobs de Azure Azure Blob Storage es la solución de almacenamiento de

objetos de Microsoft para la nube. Blob Storage está
optimizado para el almacenamiento de cantidades masivas
de datos no estructurados. Los datos no estructurados son
datos que no cumplen un modelo de datos o definición
concretos, como texto o datos binarios.
Blob Storage está diseñado para:

Visualización de imágenes o documentos directamente en
un explorador.
Almacenamiento de archivos para acceso distribuido.
Streaming de audio y vídeo.
Escribir en archivos de registro.
Almacenamiento de datos para copia de seguridad y
restauración, recuperación ante desastres y archivado.
Almacenamiento de datos para el análisis en local o en un
servicio hospedado de Azure.
Azure Data Lake Storage Gen 2 Blob Storage es compatible con Azure Data Lake Storage
Gen2, solución de análisis de macrodatos empresarial de
Microsoft para la nube. Azure Data Lake Storage Gen2
ofrece un sistema de archivos jerárquico, así como las
ventajas de Blob Storage, que incluyen las siguientes
funcionalidades: almacenamiento de bajo costo y en niveles,
alta disponibilidad, coherencia fuerte y recuperación ante
desastres.
Azure Disk Storage Azure Disk Storage ofrece almacenamiento en bloque de alto
rendimiento persistente para impulsar Azure Virtual
Machines. Los discos de Azure son muy duraderos y
seguros, y ofrecen el único Acuerdo de Nivel de Servicio de
una sola instancia del sector para máquinas virtuales que
usan SSD Premium o Ultra. Los discos de Azure
proporcionan alta disponibilidad con conjuntos de
disponibilidad y Availability Zones que se asignan a sus
dominios de error de Azure Virtual Machines. Además, los
discos de Azure se administran como recurso de nivel
superior en Azure. De forma predeterminada, se
proporcionan funcionalidades de Azure Resource Manager
como el control de acceso basado en rol de Azure (RBAC de
Azure), las directivas y el etiquetado.
SERVIC IO DESC RIP C IÓ N
Archivos de Azure Azure Files proporciona recursos compartidos de archivos

SMB nativos totalmente administrados, sin necesidad de
ejecutar una máquina virtual. Puede montar un recurso
compartido de Azure Files como unidad de red en cualquier
máquina virtual de Azure o máquina local.
Azure File Sync Se puede usar Azure File Sync para centralizar los recursos
compartidos de archivos de su organización en Azure Files
sin renunciar a la flexibilidad, el rendimiento y la
compatibilidad de un servidor de archivos local. Azure File
Sync transforma Windows Server en una caché rápida de los
recursos compartidos de archivos de Azure.
Azure NetApp Files Azure NetApp Files es un servicio de almacenamiento de

archivos de alto rendimiento, medido y de clase empresarial.
Admite cualquier tipo de carga de trabajo y demuestra una
alta disponibilidad de forma predeterminada. Puede
seleccionar niveles de servicio y de rendimiento y configurar
las instantáneas mediante el servicio.
Azure Data Box Edge Azure Data Box Edge es un dispositivo de red local que
traslada datos a Azure y fuera de este. Data Box Edge tiene
un proceso perimetral que admite inteligencia artificial para
preprocesar datos durante la carga. Data Box Gateway es
una versión virtual del dispositivo, pero con las mismas
funcionalidades de transferencia de datos.
Azure Data Box Gateway Azure Data Box Gateway es una solución de almacenamiento
que permite enviar fácilmente datos a Azure. Data Box
Gateway es un dispositivo virtual basado en una máquina
virtual aprovisionada en un entorno virtualizado o
hipervisor. El dispositivo virtual reside en el entorno local y
se pueden escribir datos en él mediante los protocolos SMB
y NFS. El dispositivo, a continuación, transfiere los datos a
blobs en bloques de Azure o blobs en páginas de Azure, o a
Azure Files.
Avere vFXT for Azure Avere vFXT for Azure proporciona una solución de
almacenamiento en caché del sistema de archivos para
tareas de informática de alto rendimiento (HPC) en las que
se usan muchos datos. Aproveche la escalabilidad de la
informática en la nube para hacer que los datos sean
accesibles cuando y donde se necesiten, incluso para los
datos que están almacenados en su propio hardware local.
Disponibilidad y redundancia de datos

Azure Storage tiene diversas opciones de redundancia para ayudar a garantizar la durabilidad y alta
disponibilidad basadas en las necesidades de los clientes: almacenamiento con redundancia local,
almacenamiento con redundancia de zona, almacenamiento con redundancia geográfica (GRS) y GRS con
acceso de lectura (RA-GRS).
Consulte Redundancia de Azure Storage para obtener más información sobre estas funcionalidades y cómo
puede decidir sobre la mejor opción de redundancia para sus casos de uso. Además, los Acuerdos de Nivel de
Servicio (SLA) para los servicios de almacenamiento proporcionan garantías de que cuentan con respaldo
financiero. Para obtener más información, consulte Contrato de nivel de servicio para Managed Disks, Contrato
de nivel de servicio para Máquinas virtuales y Contrato de nivel de servicio para Cuentas de almacenamiento.
Para recibir ayuda con la planeación de la solución adecuada para los discos de Azure, consulte Copia de
seguridad y recuperación ante desastres para Azure Disk Storage.
Seguridad
Para ayudarle a proteger sus datos en la nube, Azure Storage ofrece varios procedimientos recomendados para
la seguridad de los datos y el cifrado de los datos en reposo y en tránsito. Puede:
Proteger la cuenta de almacenamiento mediante RBAC de Azure y Azure AD.
Proteger los datos en tránsito entre una aplicación y Azure mediante cifrados de cliente, HTTPS o SMB 3.0.
Establecer una configuración para que los datos se cifren automáticamente cuando se escriban en Azure
Storage mediante el cifrado de este servicio.
Conceder acceso delegado a los objetos de datos de Azure Storage mediante las firmas de acceso
compartido.
Usar análisis para seguir el método de autenticación que alguien esté usando cuando obtienen acceso a
Storage en Azure.
Estas características de seguridad se aplican a Almacenamiento de blobs de Azure (bloque y página) y a Azure
Files. Obtenga instrucciones de seguridad de almacenamiento detalladas en la Guía de seguridad de Azure
Storage.
El cifrado de Azure Storage proporciona cifrado en reposo y protege sus datos con el fin de cumplir con los
compromisos de cumplimiento y seguridad de su organización. El cifrado de Azure Storage está habilitado de
forma predeterminada para todos los discos administrados, instantáneas e imágenes en todas las regiones de
Azure. Desde el 10 de junio de 2017, todos los nuevos discos administrados, instantáneas, imágenes, así como
los datos nuevos que se escriban en discos administrados existentes, se cifran automáticamente en reposo con
claves administradas por Microsoft. Para más información, consulte Preguntas más frecuentes de discos
administrados.
Azure Disk Encryption permite cifrar discos administrados asociados a VM de IaaS como discos de sistema
operativo y de datos en reposo y en tránsito mediante sus claves almacenadas en Azure Key Vault. Para
Windows, las unidades se cifran mediante la tecnología de cifrado de BitLocker estándar del sector. Para Linux,
los discos se cifran mediante el subsistema dm-crypt. El proceso de cifrado se integra con Azure Key Vault para
permitirle controlar y administrar las claves de cifrado del disco. Para más información, consulte Azure Disk
Encryption para máquinas virtuales IaaS de Windows y Linux.
Puede usar Azure para ofrecer servicios a la escala que necesita para llegar a sus clientes y asociados
dondequiera que se encuentren . En las páginas de disponibilidad regional sobre discos administrados y
Azure Storage se muestran las regiones en las que estos servicios se encuentran disponibles. La comprobación
previa de la disponibilidad regional de un servicio puede ayudar a tomar la decisión adecuada para sus
necesidades de carga de trabajo y del cliente.
Los discos administrados están disponibles en todas las regiones de Azure que tienen ofertas de SSD Premium
y SSD estándar. Aunque SSD Ultra se encuentra actualmente en versión preliminar pública, se ofrece solo en una
zona de disponibilidad, la región East US 2 . Compruebe la disponibilidad regional al planear cargas de trabajo
de nivel superior críticas que requieran SSD Ultra.
Los niveles de Blob Storage de acceso frecuente y de acceso esporádico, Data Lake Storage Gen2 y el
almacenamiento de Azure Files están disponibles en todas las regiones de Azure. Blob Storage de archivo, los
recursos compartidos de archivos Premium y al almacenamiento de blobs en bloques Premium están limitados
a determinadas regiones. Recomendamos que consulte la página de regiones para comprobar el último estado
de la disponibilidad regional.
Para obtener más información sobre la infraestructura global de Azure, consulte la página Regiones de Azure.
También puede consultar los productos disponibles por región para obtener detalles específicos sobre lo que
hay disponible en cada región de Azure.

Los requisitos legales y contractuales que están relacionados con el almacenamiento de datos se aplicarán a
menudo a sus cargas de trabajo. Estos requisitos pueden variar en función de la ubicación de su organización, la
jurisdicción de los recursos físicos que hospedan sus almacenes de datos y su sector empresarial aplicable. Entre
modelo de responsabilidad compartida. Para comprender estos requisitos, consulte las notas del producto
Consecución de la seguridad y la residencia de datos compatibles con Azure.
están sujetos a la soberanía de datos u otros requisitos de cumplimiento, debe implementar sus recursos de
Revisión de las opciones de datos
Cuando prepare el entorno de la zona de aterrizaje para la adopción de la nube, deberá determinar los
requisitos de datos para hospedar las cargas de trabajo. Los productos y servicios de base de datos de Azure
admiten una amplia variedad de escenarios y funcionalidades de almacenamiento de datos. El modo en que se
configure el entorno de la zona de aterrizaje para satisfacer los requisitos de datos depende de los requisitos de
gobierno, técnicos y empresariales de la carga de trabajo.
Identificación de los requisitos de los servicios de datos

Como parte de la evaluación y preparación de la zona de aterrizaje, debe identificar los almacenes de datos que
debe admitir la zona de aterrizaje. Este proceso supone evaluar cada una de las aplicaciones y servicios que
componen las cargas de trabajo para determinar sus requisitos de acceso y almacenamiento de datos. Después
de identificar y documentar estos requisitos, puede crear directivas para la zona de aterrizaje con el fin de
controlar qué tipos de recursos se permiten en función de las necesidades de su carga de trabajo.
árbol de decisión como punto de partida para que le ayude a determinar los servicios de almacenamiento de
datos adecuados que usar:
Ilustración 1: Árbol de decisión de los servicios de base de datos de Azure.
Preguntas clave
Responda a las siguientes preguntas sobre las cargas de trabajo como ayuda para tomar decisiones basadas en
el árbol de decisión de los servicios de base de datos de Azure:
¿Necesita control total o propiedad del software de base de datos o del sistema operativo del
host? Algunos escenarios requieren un alto grado de control o propiedad de la configuración de software y
los servidores host para las cargas de trabajo de base de datos. En estos casos, puede implementar máquinas
virtuales de infraestructura como servicio (IaaS) personalizadas para controlar completamente la
implementación y la configuración de los servicios de datos. Si no tiene estos requisitos, los servicios de base
de datos de plataforma como servicio (PaaS) pueden reducir los costos de administración y operaciones.
¿Usarán las cargas de trabajo una tecnología de base de datos relacional? Si es así, ¿qué
tecnología planea usar? Azure proporciona capacidades de base de datos de PaaS administradas para Azure
SQL Database, MySQL, PostgreSQL y MariaDB.
¿Usarán las cargas de trabajo SQL Ser ver? En Azure, puede hacer que las cargas de trabajo se ejecuten
en SQL Server en Azure Virtual Machines basadas en IaaS o en el servicio hospedado de Azure SQL
Database basado en PaaS. La elección de la opción que se vaya a usar es principalmente una pregunta sobre
si desea administrar la base de datos, aplicar revisiones y realizar copias de seguridad, o si desea delegar
esas operaciones a Azure. En algunos escenarios, los problemas de compatibilidad pueden requerir el uso de
SQL Server con IaaS hospedado. Para obtener más información sobre cómo elegir la opción correcta para las
cargas de trabajo, consulte Selección de la opción de SQL Server correcta en Azure.
¿Usarán las cargas de trabajo el almacenamiento de base de datos de clave-valor? Azure Redis
Cache ofrece una solución de almacenamiento de datos clave-valor en caché de alto rendimiento que puede
potenciar aplicaciones escalables y rápidas. Azure Cosmos DB también proporciona capacidades de
almacenamiento de clave-valor de uso general.
¿Las cargas de trabajo usarán datos de gráficos o documentos? Azure Cosmos DB es un servicio de
base de datos multimodelo que admite una amplia variedad de tipos de datos y API. Azure Cosmos DB
también proporciona capacidades de base de datos de documentos y de grafos.
¿Usarán las cargas de trabajo datos de familias de columnas? Apache HBase en Azure HDInsight se
basa en Apache Hadoop. Admite grandes cantidades de datos no estructurados y semiestructurados en una
base de datos sin esquemas organizada por familias de columnas.
¿Las cargas de trabajo requerirán funcionalidades de análisis de datos de alta capacidad? Puede
usar Azure SQL Data Warehouse para almacenar y consultar de forma eficaz datos estructurados a escala de
petabytes. En el caso de cargas de macrodatos no estructuradas, puede usar Azure Data Lake para almacenar
y analizar archivos de tamaño en petabytes y billones de objetos.
¿Requerirán las cargas de trabajo capacidades del motor de búsqueda? Puede usar Azure Cognitive
Search para crear índices de búsqueda basados en la nube mejorados con inteligencia artificial que se
pueden integrar en sus aplicaciones.
¿Usarán las cargas de trabajo los datos de serie temporal? Azure Time Series Insights se usa para
almacenar, visualizar y consultar grandes cantidades de datos de series temporales, como los que generan
los dispositivos de IoT.
NOTE
Más información sobre cómo evaluar las opciones de base de datos para cada una de sus aplicaciones o servicios en la
guía de arquitectura de aplicaciones de Azure.
Escenarios comunes de bases de datos

En la tabla siguiente se muestran algunos requisitos de escenarios de uso comunes y los servicios de base de
datos recomendados para gestionarlos:
ESC EN A RIO SERVIC IO DE DATO S
Necesito una base de datos multimodelo distribuida Azure Cosmos DB

globalmente que admita opciones NoSQL.
Necesito una base de datos relacional totalmente Azure SQL Database

administrada que se aprovisione con rapidez, admita
escalado sobre la marcha e incluya inteligencia y seguridad
integradas.
ESC EN A RIO SERVIC IO DE DATO S
Necesito una base de datos relacional MySQL escalable y Azure Database for MySQL
totalmente administrada, con alta disponibilidad y seguridad
integrada sin costo adicional.
Necesito una base de datos relacional PostgreSQL escalable Azure Database para PostgreSQL
y totalmente administrada, con alta disponibilidad y
seguridad integrada sin costo adicional.
Tengo previsto hospedar aplicaciones de SQL Server SQL Server en Virtual Machines
empresarial en la nube y tener un control total sobre el
sistema operativo del servidor.
Necesito almacenamiento de datos elástico totalmente Azure SQL Data Warehouse

administrado que disponga de seguridad en todos los
niveles de escalado y sin costo adicional.
Necesito recursos de Data Lake Storage que puedan admitir Azure Data Lake
clústeres de Hadoop o datos de HDFS.
Necesito acceso a datos coherente, de baja latencia y alto Azure Cache for Redis
rendimiento para mis datos para admitir aplicaciones rápidas
y escalables.
Necesito una base de datos relacional MariaDB escalable y Azure Database for MariaDB
totalmente administrada, con alta disponibilidad y seguridad
integrada sin costo adicional.
Azure le permite ofrecer servicios a la escala que necesita para llegar a sus clientes y asociados, dondequiera
que se encuentren . Uno de los factores clave a la hora de planear la implementación en la nube es determinar
qué región de Azure hospedará los recursos de la carga de trabajo.
La mayoría de los servicios de base de datos están disponibles de forma general en la mayoría de las regiones
de Azure. Sin embargo, hay algunas regiones, dirigidas principalmente a clientes gubernamentales, que solo
admiten un subconjunto de estos productos. Antes de decidir en qué regiones va a implementar los recursos de
base de datos, se recomienda que consulte la página de regiones para comprobar el estado más reciente de la
disponibilidad regional.
Para obtener más información sobre la infraestructura global de Azure, consulte la página Regiones de Azure.
También puede ver los productos disponibles por región para conocer detalles específicos sobre los servicios
generales que están disponibles en cada región de Azure.

Los requisitos legales y contractuales que están relacionados con el almacenamiento de datos se aplicarán a
menudo a sus cargas de trabajo. Estos requisitos pueden variar en función de la ubicación de su organización, la
jurisdicción de los recursos físicos que hospedan sus almacenes de datos y su sector empresarial aplicable. Entre
modelo de responsabilidad compartida. Para comprender estos requisitos, consulte las notas del producto
Consecución de la seguridad y la residencia de datos compatibles con Azure.
están sujetas a la soberanía de datos u otros requisitos de cumplimiento, debe implementar sus recursos de
Establecimiento de controles para servicios de base de datos

Al preparar el entorno de la zona de aterrizaje, puede establecer controles que limiten qué almacenes de datos
puede implementar cada usuario. Los controles pueden ayudarle a administrar los costos y a limitar los riesgos
de seguridad, al tiempo que permiten a los desarrolladores y equipos de TI implementar y configurar los
recursos necesarios para admitir las cargas de trabajo.
Después de identificar y documentar los requisitos de la zona de aterrizaje, puede usar Azure Policy para
controlar los recursos de base de datos que permite que creen los usuarios. Los controles pueden tener la forma
de permitir o denegar la creación de tipos de recursos de base de datos. Por ejemplo, puede restringir a los
usuarios que solo creen recursos de Azure SQL Database. También puede usar directivas para controlar las
opciones permitidas cuando se crea un recurso, como restringir las SKU de SQL Database que se pueden
aprovisionar o permitir que se instalen solo versiones específicas de SQL Server en una máquina virtual de IaaS.
Las directivas se pueden limitar a recursos, grupos de recursos, suscripciones y grupos de administración. Puede
incluir las directivas en las definiciones de Azure Blueprints y aplicarlas varias veces a todo el patrimonio de la
nube.
Control de acceso basado en roles de Azure
Los privilegios y los derechos de acceso basados en grupo son una buena práctica. Lidiar con grupos en lugar
de con usuarios individuales simplifica el mantenimiento de las directivas de acceso, proporciona la
administración de acceso coherente entre equipos y reduce los errores de configuración. Asignar usuarios a los
grupos adecuados y eliminar aquellos de estos ayuda a mantener actualizados los privilegios de un usuario
específico. El control de acceso basado en rol de Azure (RBAC de Azure) ofrece una administración de acceso
específico para los recursos organizada en torno a roles de usuario.
Para información general sobre las prácticas de RBAC de Azure recomendadas como parte de una estrategia de
identidad y seguridad, consulte Uso del control de acceso basado en rol.
Introducción al control de acceso basado en rol de Azure

Mediante el control de acceso basado en rol de Azure, puede separar las tareas dentro de su equipo y otorgar
solo el acceso suficiente para usuarios, grupos, entidades de servicio o identidades administradas de Azure
Active Directory (Azure AD) específicos para realizar sus trabajos. En lugar de proporcionar acceso no
restringido a todos los empleados a los recursos o la suscripción de Azure, puede limitar los permisos para cada
conjunto de recursos.
Las definiciones de roles de Azure enumeran las operaciones permitidas o no permitidas para los usuarios o
grupos asignados a ese rol. El ámbito de un rol especifica a qué recursos se aplican estos permisos definidos.
Los ámbitos se pueden especificar en varios niveles: grupo de administración, suscripción, grupo de recursos o
recurso. Los ámbitos se estructuran en una relación de elementos primarios y secundarios.
Para instrucciones detalladas para la asignación de usuarios y grupos a roles específicos y la asignación de roles
a ámbitos, consulte Incorporación o eliminación de asignaciones de roles de Azure mediante Azure Portal.
Al planear la estrategia de control de acceso, use un modelo de acceso con privilegios mínimos que solo
conceda a los usuarios los permisos necesarios para realizar su trabajo. El siguiente diagrama muestra un
patrón sugerido para usar RBAC de Azure con este enfoque.
NOTE
Los permisos más específicos o detallados son los que define y lo más probable es que los controles de acceso sean
complejos y difíciles de administrar. Esto es especialmente cierto cuando los recursos en la nube aumentan de tamaño.
Evite asignar permisos específicos de recursos. En su lugar, utilice grupos de administración para control de acceso en toda
la compañía y grupos de recursos para control de acceso en las suscripciones. Asimismo, evite permisos específicos del
usuario. En su lugar, asigne acceso a grupos en Azure AD.
Uso de los roles integrados de Azure

Azure proporciona muchas definiciones de roles integrados, con tres roles principales para proporcionar acceso:
El rol Propietario puede administrarlo todo, incluido el acceso a los recursos.
El rol Colaborador puede administrarlo todo, excepto el acceso a los recursos.
El rol Lector puede verlo todo, pero no realizar cambios.
A partir de estos niveles de acceso principales, los roles integrados adicionales proporcionan controles más
detallados para acceder a determinados tipos de recursos o características de Azure. Por ejemplo, puede
administrar el acceso a las máquinas virtuales mediante los siguientes roles integrados:
El rol Inicio de sesión de administrador de máquina virtual puede ver las máquinas virtuales en el portal e
iniciar sesión como administrator .
El rol Colaborador de la máquina virtual puede administrar máquinas virtuales, pero no puede acceder a
ellas ni a la red virtual ni a la cuenta de almacenamiento a las que está conectado.
El rol Inicio de sesión de usuario de máquina virtual puede ver las máquinas virtuales en el portal e iniciar
sesión como usuario normal.
Para ver otro ejemplo del uso de roles integrados para administrar el acceso a características concretas, consulte
la explicación sobre cómo controlar el acceso a las características de seguimiento de costos en Seguimiento de
los costos a través de las unidades de negocio, entornos o proyectos.
Para una lista completa de los roles integrados disponibles, consulte Roles integrados de Azure.
Uso de roles personalizados

Aunque los roles integrados en el soporte técnico de Azure admiten una amplia variedad de escenarios de
control de acceso, es posible que no satisfagan todas las necesidades de su organización o equipo. Por ejemplo,
si tiene un único grupo de usuarios responsables de administrar máquinas virtuales y recursos de Azure SQL
Database, es posible que desee crear un rol personalizado para optimizar la administración de los controles de
acceso necesarios.
La documentación de RBAC de Azure contiene instrucciones sobre la creación de roles personalizados, junto con
detalles sobre cómo funcionan las definiciones de los roles.
Separación de responsabilidades y roles para organizaciones de gran

tamaño
RBAC de Azure permite a las organizaciones asignar distintos equipos a diversas tareas de administración en
grandes patrimonios de recursos en la nube. Puede permitir que los equipos de TI centrales controlen las
características de acceso y seguridad principales, concediendo al mismo tiempo grandes dosis de control sobre
cargas de trabajo o grupos de recursos específicos a los desarrolladores de software y a otros equipos.
La mayoría de los entornos en la nube también pueden beneficiarse de una estrategia de control de acceso que
utiliza varios roles y hace hincapié en una separación de responsabilidades entre estos roles. Este enfoque
requiere que cualquier cambio significativo en los recursos o la infraestructura implique varios roles para
completarse, lo que garantiza que más de una persona debe revisar y aprobar un cambio. Esta separación de
responsabilidades limita la capacidad de una sola persona a acceder a datos confidenciales o a introducir
vulnerabilidades sin que otros miembros del equipo lo sepan.
En la tabla siguiente se muestra un patrón común para dividir las responsabilidades de TI en roles
personalizados independientes:
GRUP O N O M B RE C O M ÚN DEL RO L RESP O N SA B IL IDA DES
Operaciones de seguridad SecOps Proporciona información general sobre

la seguridad.
Establece y aplica las directivas de
seguridad, como el cifrado en reposo.
Administra las claves de cifrado.
Administra las reglas de firewall.
Operaciones de red NetOps Administra la configuración y las

operaciones de red dentro de las redes
virtuales, como las rutas y los
emparejamientos.
Operaciones del sistema SysOps Especifica las opciones de

infraestructura de proceso y
almacenamiento y mantiene los
recursos que se han implementado.
Desarrollo, prueba y operaciones DevOps Compila e implementa características y

aplicaciones de carga de trabajo.
Opera características y aplicaciones

para cumplir los acuerdos de nivel de
servicio y otros estándares de calidad.
El desglose de las acciones y los permisos de estos roles estándar suelen ser los mismos en las aplicaciones, en
las suscripciones o en todos los recursos en la nube, aunque estos roles los realicen diferentes personas en
distintos niveles. En consecuencia, puede crear un conjunto común de definiciones de roles de Azure para
aplicarlos a distintos ámbitos dentro de su entorno. Después, se puede asignar a un rol común a los usuarios y
grupos, pero solo para el ámbito de los recursos, los grupos de recursos, las suscripciones o los grupos de
administración que son responsables de administrar.
Por ejemplo, en una topología de red radial con varias suscripciones, es posible que tenga un conjunto común
de definiciones de roles para el centro y todos los radios de la carga de trabajo. El rol NetOps de una suscripción
de centro de conectividad se puede asignar a los miembros del equipo de TI central de la organización, que son
los responsables del mantenimiento de la red para los servicios compartidos que todas las cargas de trabajo
usan. A continuación, se puede asignar el rol NetOps de una suscripción de radio de carga de trabajo a los
miembros de ese equipo de carga de trabajo específico, lo que les permite configurar las redes dentro de esa
suscripción para admitir mejor sus requisitos de carga de trabajo. Se usa la misma definición de rol para ambos,
pero las asignaciones basadas en el ámbito garantizan que los usuarios solo tengan el acceso que necesitan
para realizar su trabajo.
Creación de coherencia en la nube híbrida
En este artículo le guiaremos a través de los enfoques de alto nivel para crear una coherencia en la nube híbrida.
Los modelos de implementación híbridos durante la migración pueden reducir el riesgo y contribuir a una
transición sin problemas de la infraestructura. Las plataformas en la nube ofrecen el mayor nivel de flexibilidad
cuando se trata de procesos de negocios. Muchas organizaciones no tienen claro si deberían trasladarse a la
nube. Prefieren mantener el control absoluto sobre los datos más confidenciales. Desafortunadamente, los
servidores locales no permiten la misma tasa de innovación que la nube. Las soluciones de nube híbrida ofrecen
la velocidad de la innovación en la nube y el control de la administración local.
Integrar la coherencia en la nube híbrida

El uso de una solución de nube híbrida permite a las organizaciones escalar los recursos informáticos. También
elimina la necesidad de realizar grandes gastos de capital para administrar los picos de demanda a corto plazo.
Los cambios en su empresa pueden impulsar la necesidad de liberar recursos locales para aplicaciones o datos
más confidenciales. Es más fácil, rápido y menos costoso desaprovisionar recursos en la nube. Así, solo debe
pagar por aquellos recursos que su organización usa temporalmente, en lugar de tener que comprar y
mantener recursos adicionales. Este enfoque reduce la cantidad de equipo que podría permanecer inactivo
durante largos períodos de tiempo. La informática en la nube híbrida ofrece todas las ventajas de la informática
en la nube (flexibilidad, escalabilidad y rentabilidad) con el menor riesgo posible para los datos.
Figura 1: Creación de coherencia en la nube híbrida en función de la identidad, la administración, la seguridad,

los datos, el desarrollo y DevOps
Una verdadera solución de nube híbrida debe proporcionar cuatro componentes, cada uno de los cuales aporta
ventajas significativas:
Identidad común para aplicaciones locales y en la nube : este componente mejora la productividad del
usuario al otorgarle un inicio de sesión único (SSO) para todas sus aplicaciones. También garantiza la
coherencia a medida que las aplicaciones y los usuarios cruzan los límites de la red o la nube.
Administración y seguridad integradas en toda la nube híbrida : este componente proporciona una
manera coherente de supervisar, administrar y asegurar el entorno, permitiéndole obtener una mayor
visibilidad y control.
Plataforma de datos coherente para el centro de datos y la nube: este componente crea una
portabilidad de datos y ofrece un acceso continuo a los servicios de datos locales y en la nube, para obtener
una visión profunda de todos los orígenes de datos.
Desarrollo unificado y DevOps en la nube y centros de datos locales : este componente permite
trasladar las aplicaciones entre los dos entornos según sea necesario. La productividad de los
desarrolladores mejora porque ambas ubicaciones tienen ahora el mismo entorno de desarrollo.
Estos son algunos ejemplos de estos componentes desde una perspectiva de Azure:
Azure Active Directory (Azure AD) funciona con una instancia local de Active Directory para proporcionar
una identidad común a todos los usuarios. El inicio de sesión único local y en la nube facilita a los usuarios el
acceso seguro a las aplicaciones y a los activos que necesiten. Los administradores pueden administrar
controles de seguridad y gobernanza, y también tienen la flexibilidad de ajustar los permisos sin que ello
afecte a la experiencia del usuario.
Azure proporciona servicios de administración y seguridad integrados para la infraestructura en la nube y en
el entorno local. Estos servicios incluyen un conjunto integrado de herramientas que se usan para supervisar,
configurar y proteger nubes híbridas. Este enfoque integral de administración aborda específicamente los
desafíos del mundo real a los que deben enfrentarse las organizaciones que consideran tener una solución
de nube híbrida.
La nube híbrida de Azure proporciona herramientas comunes que garantizan el acceso seguro a todos los
datos, de manera transparente y eficaz. Igualmente, los servicios de datos de Azure se combinan con
Microsoft SQL Server para crear una plataforma de datos coherente. Un modelo de nube híbrida coherente
permite a los usuarios trabajar con datos analíticos y operativos. Los mismos servicios se proporcionan de
forma local y en la nube para el almacenamiento de datos, el análisis de datos y la visualización de datos.
Los servicios en la nube de Azure, combinados con la instancia local de Azure Stack, proporcionan un
desarrollo unificado y DevOps. La coherencia local y en la nube significa que su equipo de DevOps puede
compilar aplicaciones que se ejecuten en cualquier entorno y que pueden implementarse fácilmente en la
ubicación correcta. También puede reutilizar las plantillas en la solución híbrida, lo que puede simplificar aún
más los procesos de DevOps.
Azure Stack en un entorno de nube híbrida

Azure Stack es una solución de nube híbrida que permite a las organizaciones ejecutar servicios de Azure
coherentes en su centro de datos. Proporciona una experiencia simplificada de desarrollo, administración y
seguridad coherente con los servicios en la nube pública de Azure. Azure Stack es una extensión de Azure.
Puede usarlo para ejecutar servicios de Azure desde sus entornos locales y, después, pasar a la nube de Azure si
es necesario.
Con Azure Stack, puede implementar y usar tanto IaaS como PaaS mediante las mismas herramientas; además,
ofrece la misma experiencia que la nube pública de Azure. La administración de Azure Stack, ya sea a través del
portal de la interfaz de usuario web o a través de PowerShell, tiene una apariencia coherente con Azure tanto
para los administradores de TI como para los usuarios finales.
Azure y Azure Stack abren nuevos casos de uso híbridos para aplicaciones de línea de negocio que están
orientadas al cliente e internas:
Soluciones perimetrales y desconectadas . Para abordar los requisitos de latencia y conectividad, los
clientes pueden procesar los datos localmente en Azure Stack y, después, agregarlos a Azure para realizar
análisis adicionales. Pueden usar la lógica de aplicación común en ambos. Muchos clientes están interesados
en este escenario de vanguardia de diferentes maneras, como pisos de fábricas, cruceros y minas.
Aplicaciones en la nube que cumplen diversas regulaciones . Los clientes pueden desarrollar e
implementar aplicaciones en Azure, ya que cuentan con total flexibilidad de implementación en el entorno
local de Azure Stack para satisfacer sus requisitos de cumplimiento normativo o de directivas. No es
necesario realizar ningún cambio de código. Algunos ejemplos de aplicación son la auditoría global, los
informes financieros, las operaciones de cambio de divisas, los juegos en línea y los informes de gastos. A
veces los clientes buscan implementar diferentes instancias de la misma aplicación en Azure o Azure Stack,
en función de los requisitos empresariales y técnicos. Si bien Azure cumple con la mayoría de los requisitos,
Azure Stack complementa el enfoque de implementación allí donde es necesario.
Modelo de aplicación en la nube en el entorno local . Los clientes pueden usar los servicios web,
contenedores, microservicios y arquitecturas sin servidor de Azure para actualizar y ampliar las aplicaciones
existentes o crear otras nuevas. Puede usar un proceso de DevOps coherente a través de Azure en la nube, y
mediante Azure Stack en un entorno local. Existe un creciente interés en la modernización de aplicaciones,
incluso para las aplicaciones críticas fundamentales.
Azure Stack se ofrece a través de dos opciones de implementación:
Sistemas integrados de Azure Stack : los sistemas integrados de Azure Stack se ofrecen a través de
Microsoft y asociados de hardware para crear una solución que proporciona una oportunidad de innovación
dirigida a la nube y que a su vez está equilibrada con una administración sencilla. Como Azure Stack se
suministra como un sistema integrado de hardware y software, se consigue flexibilidad y control, al mismo
tiempo que se adopta la innovación de la nube. Los sistemas integrados de Azure Stack tienen un tamaño de
entre 4 y 12 nodos. Son compatibles conjuntamente con el asociado de hardware y Microsoft. Use los
sistemas integrados de Azure Stack para permitir nuevos escenarios para las cargas de trabajo de
producción.
Kit de desarrollo de Azure Stack : El Kit de desarrollo de Microsoft Azure Stack es una implementación de
un único nodo de Azure Stack. Puede usarlo para evaluar y obtener información sobre Azure Stack. También
puede usar el kit como entorno de desarrollo, donde puede desarrollar elementos mediante las API y las
herramientas que sean coherentes con Azure. El Kit de desarrollo de Azure Stack no está pensado para usarlo
como entorno de producción.
Ecosistema de Azure Stack One Cloud

Puede acelerar las iniciativas de Azure Stack si usa el ecosistema de Azure al completo:
Azure garantiza que la mayoría de las aplicaciones y servicios certificados para Azure funcionarán en Azure
Stack. Varios fabricantes de software independientes están extendiendo sus soluciones a Azure Stack.
Algunos de estos fabricantes son Bitnami, Docker, Kemp Technologies, Pivotal Cloud Foundry, Red Hat
Enterprise Linux y SUSE Linux.
Puede configurar Azure Stack para que funcione como un servicio totalmente administrado. Varios asociados
tendrán ofertas de servicios administrados en Azure y Azure Stack en breve. Entre estos asociados se
incluyen Tieto, Yourhosting, Revera, Pulsant, y NTT. Estos asociados ofrecen servicios administrados para
Azure a través del programa de Proveedor de soluciones en la nube (CSP). Están ampliando sus ofertas para
incluir soluciones híbridas.
Un ejemplo de solución de nube híbrida completa y totalmente administrada es Avanade, con una oferta
todo en uno. Incluye servicios de transformación en la nube, software, infraestructura, instalación y
configuración y servicios administrados en curso. De esta forma, los clientes pueden consumir Azure Stack
igual que hacen con Azure en la actualidad.
Con los proveedores, es más fácil acelerar las iniciativas de modernización de aplicaciones mediante la
creación de soluciones integrales de Azure para los clientes. Cada proveedor ofrece una serie detallada de
habilidades de Azure, el dominio y conocimiento del sector y la experiencia en procesos (por ejemplo,
DevOps). Cada implementación de Azure Stack es una oportunidad para que un proveedor diseñe la solución
y pueda influir en la implementación del sistema. También puede personalizar las funcionalidades incluidas y
ofrecer actividades operativas. Algunos ejemplos de proveedores son Avanade, DXC, Dell EMC Services,
Infront Consulting Group, HPE Pointnext y PWC (anteriormente PricewaterhouseCoopers).
Las operaciones de la zona de aterrizaje proporcionan la base inicial de la administración de las operaciones. A
medida que se escalan las operaciones, estas mejoras refactorizan las zonas de aterrizaje para satisfacer los
crecientes requisitos de excelencia operativa, confiabilidad y rendimiento.
Procedimientos recomendados de las operaciones de zona de

aterrizaje
Los vínculos siguientes proporcionan procedimientos recomendados para mejorar las operaciones de la zona
de aterrizaje.
Azure Server Management: guía de incorporación para agregar las herramientas y servicios nativos en la
nube necesarios para administrar las operaciones.
Supervisión híbrida: Muchos clientes ya han realizado una inversión sustancial en System Center Operations
Manager. Para esos clientes, esta guía sobre la supervisión híbrida puede ayudar a comparar y contrastar las
herramientas de notificación nativas de la nube con las herramientas de Operations Manager. Con esta
comparación resulta más fácil decidir qué herramientas utilizar para la administración operativa.
Centralización de operaciones de administración: use Azure Lighthouse para centralizar la administración de
operaciones en varios inquilinos de Azure.
Establecimiento de una revisión de ajuste operativo: revise un entorno para ver si su ajuste es operativo.
Procedimientos recomendados de las operaciones específicas de la carga de trabajo:
Lista de comprobación de resistencia
Análisis del modo de error
Recuperación después de una interrupción del servicio en toda la región
Recuperación de datos dañados o de una eliminación accidental de datos
Cuatro pasos para mejorar las operaciones más allá de una única zona
de aterrizaje
En el artículo sobre la metodología de administración se proporcionan instrucciones generales para crear la
capacidad de administración de las operaciones. Consulte este artículo aquí. Usaremos la estructura básica de
esa metodología y sus pasos siguientes para mejorar las operaciones de todas las zonas de aterrizaje.
Ilustración 1: Metodología de administración de Cloud Adoption Framework.
1. Establecimiento de una base de referencia de administración: una base de referencia de administración
establece la base de la administración de las operaciones. Las instrucciones de este primer paso se pueden
aplicar a cualquier zona de aterrizaje para mejorar las operaciones iniciales.
2. Definición de los compromisos empresariales: la comprensión de la importancia y el impacto de cada carga
de trabajo en una zona de aterrizaje establecerá una "definición de finalizado" para cualquier mejora de la
administración en curso de las zonas de aterrizaje. Este proceso también identificará los requisitos de
confiabilidad, rendimiento y operaciones de cada carga de trabajo.
3. Expansión de la base de referencia de administración: este conjunto de procedimientos recomendados se
puede aplicar para mejorar las operaciones de la zona de aterrizaje más allá de la base de referencia inicial.
4. Operaciones avanzadas y principios de diseño: revise el diseño y las operaciones de cargas de trabajo
específicas, plataformas o zonas de aterrizaje completas para satisfacer los requisitos más específicos.
Ciclo de desarrollo controlado por pruebas

Antes de comenzar con las mejoras de seguridad, es importante comprender la "definición de finalización" y
todos los "criterios de aceptación". Para obtener más información, consulte los artículos sobre el desarrollo
controlado por pruebas de las zonas de aterrizaje y el desarrollo controlado por pruebas de Azure.
Ilustración 2: Proceso de desarrollo controlado por pruebas para zonas de aterrizaje en la nube.
Pasos siguientes
Comprenda cómo mejorar la gobernanza de la zona de aterrizaje para admitir la adopción a escala.
La gobernanza de la zona de aterrizaje es la unidad más pequeña de la gobernanza general. El establecimiento

de una base de gobernanza sólida en las primeras zonas de aterrizaje reducirá la cantidad de refactorización
necesaria más adelante en el ciclo de vida de la adopción. La mejora de la gobernanza de la zona de aterrizaje
integrará los controles de costos, establecerá herramientas básicas que permitirán el escalado y facilitará que el
equipo de gobernanza en la nube cumpla las cinco materias de la gobernanza en la nube.
Procedimientos recomendados sobre gobernanza de la zona de

aterrizaje
Gobernanza inicial de la zona de aterrizaje: El artículo sobre el establecimiento de una base de
gobernanza inicial puede ayudar a agregar las herramientas de gobernanza iniciales a las primeras zonas de
aterrizaje. Estas prácticas proporcionarán ayuda en la adopción y gobernanza del escalado, junto con la
implementación de una administración de costos sólida. Este enfoque comienza con : organización de
recursos, definiciones de directivas, roles de Azure y definiciones del plano técnico.
Estándares de nomenclatura y etiquetado : garantice la coherencia en la asignación de nombres y el
etiquetado, ya que son los datos fundamentales para establecer procedimientos de gobernanza sólidos.
Seguimiento de los costos en todas las cargas de trabajo : comience a realizar un seguimiento de los
costos en la primera zona de aterrizaje. Evalúe cómo va a aplicar la coherencia entre varias cargas de trabajo
y roles.
Escalabilidad con varias suscripciones : evalúe cómo se escalará esta zona de aterrizaje y las otras, a
medida que se convierte en un requisito el hecho de contar con varias suscripciones.
Organización de suscripciones : : comprenda cómo organizar y administrar varias suscripciones.
Cuatro pasos para mejorar la gobernanza general

En el artículo sobre la metodología de gobernanza se proporcionan instrucciones generales para crear
directivas, procesos y materias de gobernanza. Usaremos la estructura básica de esa metodología y sus pasos
siguientes para mejorar la gobernanza de todas las zonas de aterrizaje.
1. Descripción de la metodología: comprenda la metodología básica para orientar el diseño de la gobernanza
de estado final.
2. Banco de pruebas: evalúe el estado actual y futuro para establecer una visión y tomar medidas.
3. Base de gobernanza inicial: conjunto pequeño y fácil de implementar de herramientas de gobernanza para
establecer una base inicial para todas las zonas de aterrizaje.
4. Mejora de la base de gobernanza: agregue controles de gobernanza de forma iterativa para reforzar toda la
gobernanza de la zona de aterrizaje.
Pasos siguientes
La adopción de la nube se seguirá expandiendo con cada oleada o versión de nuevas cargas de trabajo. Para
poder cumplir estos requisitos por adelantado, los equipos de la plataforma en la nube deben revisar
periódicamente los procedimientos recomendados de la zona de aterrizaje adicional.
Revisar los procedimientos recomendados de la zona de aterrizaje adicional
Mejora de la seguridad en la zona de aterrizaje
Cuando la carga de trabajo, o las zonas de aterrizaje en la que se hospeda, requieren acceso a datos
confidenciales o a sistemas críticos, es importante proteger los datos y los recursos. La mejora de la seguridad
de la zona de aterrizaje se basa en el enfoque de desarrollo controlado por pruebas para las zonas de aterrizaje
mediante la expansión o refactorización de la zona de aterrizaje para tener en cuenta los requisitos de seguridad
mejorados.
Procedimientos recomendados de seguridad de la zona de aterrizaje

En la siguiente lista de arquitecturas de referencia y procedimientos recomendados, se proporcionan ejemplos
de maneras de mejorar la seguridad de la zona de aterrizaje:
Azure Security Center: incorporación de una suscripción a Security Center.
Azure Sentinel: incorpore Azure Sentinel para proporcionar una solución de administración de eventos
de información de seguridad (SIEM) y respuesta automatizada de orquestación de seguridad
(SOAR) .
Seguridad en los límites de la red: varios patrones de referencia para desarrollar una red, de forma similar a
cómo se protege el límite de la red en un centro de recursos.
Arquitectura de red segura: Arquitectura de referencia para implementar una red perimetral y una
arquitectura de red segura.
Administración de identidades y control del acceso: series de procedimientos recomendados para
implementar la identidad y el acceso a fin de proteger una zona de aterrizaje en Azure.
Procedimientos de seguridad de red: proporciona procedimientos recomendados adicionales para proteger
la red.
La seguridad operativa proporciona procedimientos recomendados para aumentar la seguridad operativa en
Azure.
La materia de base de referencia de seguridad: ejemplo de desarrollo de una base de referencia de seguridad
que controla la gobernanza para aplicar los requisitos de seguridad.

Antes de comenzar con las mejoras de seguridad, es importante comprender la "definición de finalización" y
todos los "criterios de aceptación". Para obtener más información, consulte los artículos sobre el desarrollo
controlado por pruebas de las zonas de aterrizaje y el desarrollo controlado por pruebas de Azure.
Pasos siguientes
Comprenda cómo mejorar las operaciones de zona de aterrizaje para admitir aplicaciones críticas.
Evaluación de la zona de aterrizaje de Azure de un
asociado de Microsoft
Cloud Adoption Framework aborda la adopción de la nube como una actividad de autoservicio. El objetivo es
capacitar a cada uno de los equipos que respaldan la adopción mediante enfoques normalizados. En la práctica,
no se puede suponer que un enfoque de autoservicio será suficiente para todas las actividades de adopción.
Los programas de adopción de la nube bien implantados suelen incluir al menos un nivel de respaldo por parte
de terceros. Muchos esfuerzos de adopción de la nube requieren el apoyo de un integrador de sistemas (SI) o un
asociado de consultoría que proporcione servicios que aceleren la adopción de la nube. Los proveedores de
servicios administrados (MSP) proporcionan un valor permanente en el apoyo de las zonas de aterrizaje y la
adopción de la nube, y también en la administración de las operaciones posteriores a la adopción. Además, los
esfuerzos de adopción de la nube tienden a involucrar a uno o varios fabricantes de software independientes
(ISV) que proporcionan servicios basados en software que aceleran la adopción de la nube. Los ecosistemas
enriquecidos de asociados de SI, ISV, MSP y otras formas de asociados de Microsoft han adaptado sus ofertas a
metodologías específicas que se encuentran en Cloud Adoption Framework. Si un asociado está en línea con la
metodología de preparación de este marco, es probable que desee ofrecer su propia opción de implementación
de una zona de aterrizaje de Azure.
En este artículo se proporciona un conjunto de preguntas que le ayudarán a comprender el ámbito de las
opciones de implementación de zonas de aterrizaje de Azure del asociado.
IMPORTANT
El asociado define las ofertas de los asociados y las opciones de implementación de zonas de aterrizaje de Azure en
función de su amplia experiencia ayudando a los clientes a adoptar la nube.
Los asociados pueden optar por omitir la implementación de áreas de diseño específicas en su implementación inicial de
una zona de aterrizaje. Sin embargo, deben ser capaces de comunicar cuándo y cómo se implementa cada área de diseño,
así como indicar, siempre que sea posible, una serie de costos para completar esa área de diseño.
Otras soluciones de asociados pueden ser lo suficientemente flexibles como para admitir varias opciones para cada una de
las preguntas siguientes. Use estas preguntas para asegurarse de que está comparando las ofertas de los asociados y las
opciones de autoservicio de forma equitativa.
Buscar un asociado
Si necesita un asociado para implementar sus zonas de aterrizaje de Azure, empiece por la lista aprobada de
asociados en línea con Cloud Adoption Framework. En concreto, empiece por los asociados que disponen de
ofertas en línea con la metodología de preparación.
Además, todos los proveedores expertos de servicios administrados de Azure han sido auditados para validar
su capacidad de ofrecer cada una de las metodologías de Cloud Adoption Framework. Aunque es posible que
un determinado asociado no tenga una oferta alineada, todos ellos han demostrado su alineación durante la
ejecución técnica.
Validación de la oferta de un asociado

Una vez seleccionado un asociado, emplee el resto de este artículo para que le oriente en la validación de la
oferta de este asociado. Cada sección incluye un resumen de lo que se debe buscar y una lista de preguntas que
se deben formular al asociado. Las respuestas del asociado a estas preguntas no se deben considerar como
correctas o incorrectas. En vez de eso, las preguntas están diseñadas para ayudarle a valorar si la oferta del
asociado satisfará sus requisitos empresariales.
Velocidad de desarrollo de la plataforma

Como se indica en las opciones de implementación de las zonas de aterrizaje de Azure, hay dos enfoques de alto
nivel para la implementación de estas zonas en función de cómo desee desarrollar sus zonas de aterrizaje.
Pregunta para el asociado: ¿Cuál de los siguientes enfoques es compatible con la solución de zona de
aterrizaje de Azure del asociado?
Inicio a pequeña escala y expansión: Comience con una plantilla sencilla. La solución de zona de
aterrizaje va evolucionando con el tiempo a medida que el modelo operativo deseado de la nube se vuelve
más claro.
Inicio a escala empresarial: Comience con una implementación de referencia más completa. La
arquitectura de referencia se basa en un modelo operativo de nube bien definido que requiere menos
iteración para llegar a una solución madura.
Otros: El asociado tiene un enfoque modificado y debe ser capaz de describirlo.
Todas las zonas de aterrizaje de Azure deben tener en cuenta el siguiente conjunto de áreas de diseño comunes.
Nos referimos a la forma en que esas áreas de diseño se implementan como principios de diseño. Las secciones
siguientes le ayudarán a validar los principios de diseño del asociado que definen la implementación de la zona
de aterrizaje de Azure.
Los asociados que ofrecen una solución de zona de aterrizaje de Azure pueden admitir una o varias opciones de
implementación (o modificación o expansión de la zona de aterrizaje) de la solución en su inquilino de Azure.
Pregunta para el asociado: ¿Cuál de las siguientes opciones admiten sus soluciones de zona de aterrizaje de
Azure?
Automatización de la configuración: ¿Implementa la solución la zona de aterrizaje a partir de una
canalización de implementación o una herramienta de implementación?
Configuración manual: ¿La solución capacita al equipo de TI para que configure manualmente la zona de
aterrizaje sin insertar errores en el código fuente de esta?
Pregunta para el asociado: ¿Cuál de las siguientes opciones de implementación de zonas de aterrizaje de
Azure es compatible con la solución del asociado? Consulte el artículo sobre opciones de implementación de
zonas de aterrizaje de Azure para obtener una lista completa de las opciones.
Identidad
Es posible que la identidad sea el área de diseño más importante de la solución del asociado que se va a evaluar.
Pregunta para el asociado: ¿Cuál de las siguientes opciones de administración de identidades admite la
solución del asociado?
Azure AD: el procedimiento recomendado es usar Azure AD y el control de acceso basado en roles de Azure
para administrar las identidades y el acceso en Azure.
Active Director y: si es necesario, ¿proporciona la solución del asociado una opción para implementar
Active Directory como una solución de infraestructura como servicio?
Proveedor de identidades de terceros: si su empresa usa una solución de identidad de terceros,
determine si la zona de aterrizaje de Azure del asociado se integra con la solución de ese proveedor
independiente y cómo lo hace.
La red es posiblemente la segunda área de diseño más importante que se va a evaluar. Existen varios enfoques
de procedimientos recomendados relacionados con la topología de red y la conectividad.
Pregunta para el asociado: ¿Cuál de las siguientes opciones se incluye con la solución de zonas de aterrizaje
de Azure del asociado? ¿Alguna de las siguientes opciones es incompatible con la solución del asociado?
Red vir tual: ¿Configura la solución del asociado una red virtual? ¿Se puede modificar su topología para que
cumpla con sus restricciones técnicas o empresariales?
Red privada vir tual (VPN): ¿Se incluye la configuración de VPN en el diseño de zonas de aterrizaje del
asociado para conectar la nube a los centros de datos u oficinas existentes?
Conectividad de alta velocidad: ¿Se incluye una conexión de alta velocidad como Azure ExpressRoute en
el diseño de la zona de aterrizaje?
Emparejamiento de red vir tual: ¿Incluye el diseño conectividad entre diferentes suscripciones o redes
virtuales de Azure?
Una administración sólida y operativa de la nube comienza con unos procedimientos recomendados de
organización de recursos.
Pregunta para el asociado: ¿Incluye el diseño de la zona de aterrizaje del asociado consideraciones sobre los
siguientes procedimientos de organización de recursos?
Estándares de nomenclatura: ¿Qué estándares de nomenclatura seguirá esta oferta? ¿Se aplicarán
automáticamente a través de una directiva?
Estándares de etiquetado: ¿Sigue y aplica la configuración de la zona de aterrizaje unos estándares
específicos para etiquetar los recursos?
Diseño de la suscripción: ¿Qué estrategias de diseño de suscripciones admite la oferta del asociado?
Diseño del grupo de administración: ¿Sigue la oferta del asociado un patrón definido para la jerarquía
de grupos de administración de Azure para organizar las suscripciones?
Alineación del grupo de recursos: ¿Cómo se usan los grupos de recursos para agrupar los recursos
implementados en la nube? En la oferta del asociado, ¿se usan los grupos de recursos para agrupar los
recursos en cargas de trabajo, paquetes de implementación u otros estándares de la organización?
Pregunta para el asociado: ¿Ofrece el asociado documentación sobre la incorporación para poder realizar un
seguimiento de las decisiones fundamentales y educar al personal? Consulte la plantilla de decisiones iniciales
para obtener un ejemplo de esta documentación.
Los requisitos de gobernanza pueden influir en gran medida en cualquier diseño de zona de aterrizaje complejo.
Muchos asociados proporcionan una oferta independiente para implementar las materias de gobernanza por
completo después de implementar las zonas de aterrizaje. Las siguientes preguntas le ayudarán a aclarar los
aspectos de la gobernanza que se integrarán en todas las zonas de aterrizaje.
Pregunta para el asociado: ¿Qué herramientas de gobernanza incluye la solución del asociado como parte
de la implementación de la zona de aterrizaje?
Super visión del cumplimiento de la directiva: ¿Incluye la solución de zona de aterrizaje del asociado
directivas de gobernanza definidas junto con herramientas y procesos para supervisar el cumplimiento?
¿Incluye la oferta la personalización de directivas para ajustarse a sus necesidades de gobernanza?
Aplicación de directivas: ¿Incluye la solución de zona de aterrizaje del asociado herramientas y procesos
de cumplimiento automatizados?
Gobernanza de la plataforma en la nube: ¿Incluye la oferta de asociado una solución para mantener el
cumplimiento de un conjunto común de directivas en todas las suscripciones? ¿O el ámbito se limita a
suscripciones individuales?
N/D: los enfoques de inicio a pequeña escala posponen decisiones de gobernanza intencionadamente hasta
que el equipo haya implementado cargas de trabajo de bajo riesgo en Azure. Esto puede abordarse mediante
una oferta independiente una vez implementada la solución de zona de aterrizaje.
Pregunta para el asociado: ¿La oferta del asociado va más allá de las herramientas de gobernanza para
incluir también procesos y procedimientos a la hora de proporcionar cualquiera de las siguientes materias de
gobernanza en la nube?
Administración de costos : ¿Prepara la oferta del asociado al equipo para evaluar, supervisar y optimizar el
gasto al tiempo que genera una responsabilidad sobre los costos en los equipos de cargas de trabajo?
Base de referencia de seguridad : ¿Prepara la oferta del asociado al equipo para mantener el
cumplimiento de los requisitos de seguridad y consolidación?
Coherencia de recursos : ¿Prepara la oferta del asociado al equipo para asegurarse de que todos los
recursos de la nube están incorporados en los procesos de administración de operaciones pertinentes?
Base de referencia de identidad : ¿Prepara la oferta del asociado al equipo para mantener la identidad, las
definiciones de roles y las asignaciones después de implementar la zona de aterrizaje inicial?
Los requisitos de administración de las operaciones podrían afectar a la configuración de productos específicos
de Azure durante la implementación de la zona de aterrizaje. Muchos asociados proporcionan una oferta
independiente para implementar por completo la base de referencia de las operaciones y las operaciones
avanzadas más adelante en el recorrido de adopción de la nube, pero siempre antes de que se publique la
primera carga de trabajo para su uso en producción. Sin embargo, la solución de zona de aterrizaje del asociado
puede incluir de forma predeterminada la configuración de varias herramientas de administración de
operaciones.
Pregunta para el asociado: ¿Incluye la solución del asociado opciones de diseño para admitir todas las
materias de operaciones en la nube?
Inventario y visibilidad: ¿Incluye la zona de aterrizaje herramientas para asegurarse de que el 100 % de
los recursos se supervisan de forma centralizada?
Cumplimiento operativo: ¿Incluye la arquitectura herramientas y procesos automatizados para aplicar
revisiones u otros requisitos de cumplimiento operativo?
Protección y recuperación: ¿Incluye la oferta del asociado herramientas y configuración para garantizar
un nivel mínimo de copia de seguridad y recuperación para el 100 % de los recursos implementados?
Operaciones de la plataforma: ¿Incluye la oferta de zona de aterrizaje herramientas o procesos para
optimizar las operaciones en la cartera?
Operaciones con cargas de trabajo: ¿Incluye la oferta de zona de aterrizaje herramientas para
administrar los requisitos operativos específicos de la carga de trabajo y asegurarse de que cada carga de
trabajo está bien diseñada?
Realizar acción
Después de revisar la oferta o solución de zona de aterrizaje de Azure del asociado con las preguntas anteriores,
el equipo estará más capacitado para elegir el asociado cuya zona de aterrizaje de Azure esté más
estrechamente en consonancia con el modelo operativo de la nube.
Si determina que un enfoque de autoservicio con respecto a la implementación de la zona de aterrizaje de Azure
es una opción mejor, revise o vuelva a considerar las opciones de implementación de la zona de aterrizaje de
Azure para encontrar el enfoque de la zona de aterrizaje con plantilla que más en consonancia esté con el
modelo operativo de la nube.
Pasos siguientes
Más información sobre el proceso para refactorizar zonas de aterrizaje.
Una zona de aterrizaje es un entorno para hospedar cargas de trabajo que se aprovisionan previamente
mediante código . Dado que la infraestructura de la zona de aterrizaje se define en el código, se puede
refactorizar de manera similar a cualquier otro código base. La refactorización es el proceso de modificar o
reestructurar el código fuente para optimizar la salida del código sin cambiar su finalidad ni su función básica.
La metodología de preparación usa el concepto de refactorización para acelerar la migración y quitar los
bloqueadores comunes. En los pasos de la introducción a la metodología de preparación se describe un proceso
que comienza con una plantilla de zona de aterrizaje predefinida que se alinea mejor con su función de
hospedaje. A continuación, refactorice o amplíe el código fuente para expandir la capacidad de las zonas de
aterrizaje para ofrecer esa función con una seguridad, operaciones o gobernanza mejoradas. En la imagen
siguiente se ilustra el concepto de refactorización.
Figura 1: Refactorización de zonas de aterrizaje.
Bloqueadores comunes
Cuando los clientes adoptan la nube, las consideraciones sobre la zona de aterrizaje son el bloqueador más
común para la adopción y los resultados empresariales relacionados con la nube. Los clientes tienden a
decantarse por uno de los dos bloqueadores siguientes. A menudo, los diferentes equipos se inclinan hacia uno
de estos dos obstáculos, lo cual da lugar a interbloqueos que dificultan el proceso de adopción.
Los dos bloqueadores principales se basan en la creencia de que el entorno en la nube y los centros de datos
existentes deben tener paridad de características en relación con las operaciones, la gobernanza y la seguridad.
Este es un objetivo a largo plazo inteligente. Sin embargo, lo difícil es el delicado equilibrio entre los tiempos
para lograr ese objetivo y la velocidad necesaria para proporcionar resultados empresariales.
Bloqueador: Actuar demasiado pronto
Se necesitaron años y un esfuerzo considerable para alcanzar el estado actual de seguridad, gobernanza y
operaciones en el centro de datos actual. También se necesitaron observaciones, aprendizaje y personalización
para ajustarse a las restricciones únicas del entorno. La replicación de los mismos procedimientos y
configuraciones llevará tiempo. Alcanzar la paridad de características total también puede generar un entorno
con un rendimiento deficiente en la nube. Este enfoque de paridad también conduce a un considerable gasto
excesivo no planeado en el entorno en la nube. No intente aplicar los requisitos de estado actual a un entorno
de estado futuro como fase de desarrollo temprana. Este enfoque no suele ser rentable.
Figura 2: Actuar demasiado pronto es un obstáculo habitual.
En la imagen anterior, el cliente tiene un objetivo de 100 cargas de trabajo en ejecución en la nube. Para ello, es
probable que el cliente implemente su primera carga de trabajo y, a continuación, sus primeras diez cargas de
trabajo (aproximadamente) antes de que estén listas para publicar una de ellas en producción. Finalmente,
alcanzarán el objetivo del plan de adopción y contarán con una sólida cartera en la nube. Sin embargo, la x roja
de la imagen muestra dónde se bloquean, normalmente, los clientes. Esperar una alineación total puede retrasar
la primera carga de trabajo en semanas, meses o, incluso, años.
Bloqueador: Actuar demasiado tarde
Por otra parte, actuar demasiado tarde puede tener importantes consecuencias a largo plazo en el éxito del
trabajo de adopción de la nube. Si el equipo espera a alcanzar la paridad de características hasta que se
completen los esfuerzos de adopción, se encontrará con obstáculos innecesarios y se requerirán varias
escalaciones para mantener los esfuerzos bien encaminados.
Figura 3: Actuar demasiado tarde es un obstáculo habitual.

Este caso es similar al anterior, en que se actuaba demasiado pronto. En esta imagen, el cliente espera
demasiado tiempo para conseguir la preparación empresarial en todas las zonas de aterrizaje. Al esperar
demasiado, el cliente se verá limitado por la cantidad de refactorización y expansión que puede aplicar en el
entorno. Estas restricciones limitarán su capacidad de generar un éxito continuado.
Buscar el equilibrio
Para evitar estos bloqueadores comunes, se recomienda un enfoque iterativo basado en un plan de adopción en
la nube bien estructurado que maximiza las oportunidades de aprendizaje y minimiza el tiempo necesario para
conseguir éxito empresarial. La refactorización y los esfuerzos paralelos son fundamentales para este enfoque.
WARNING
Los equipos de adopción que tengan un objetivo a medio plazo (en 24 meses) para hospedar más de 1000 recursos
(aplicaciones, infraestructura o recursos de datos) en la nube tienen pocas posibilidades de tener éxito con un
enfoque de refactorización. La curva de aprendizaje es demasiado alta y la escala de tiempo es demasiado ajustada para
los enfoques orgánicos para adquirir aptitudes. Un punto inicial más completo que requiera menos personalización será
una ruta de acceso mejor para lograr sus objetivos. Los asociados de implementación, probablemente, podrán guiarle
hacia un enfoque mejor.
El resto de este artículo se centrará en algunas restricciones clave que pueden facilitar un enfoque de
refactorización, a la vez que se minimiza el riesgo.
Teoría
El concepto de refactorización de una zona de aterrizaje es sencillo, pero su realización requiere de las
protecciones adecuadas. El concepto anterior describe el flujo básico:
Cuando esté listo para compilar la primera zona de aterrizaje, comience con una zona de aterrizaje inicial
definida mediante una plantilla.
Una vez implementada la zona de aterrizaje, use los árboles de decisiones en los artículos siguientes de la
sección Expand your landing zone del índice para refactorizar y ampliar la zona de aterrizaje inicial.
Repita los árboles de decisiones y la refactorización hasta que tenga un entorno preparado para la empresa
que cumpla los requisitos mejorados de los equipos de seguridad, operaciones y gobernanza.
Enfoque de desarrollo
La ventaja de un enfoque basado en la refactorización es la capacidad de crear rutas de acceso de iteración
paralelas para el desarrollo. La imagen siguiente proporciona un ejemplo de dos rutas de acceso de iteración
paralelas: la adopción de la nube y la plataforma de nube. Ambas progresan a su propio ritmo, con el mínimo
riesgo de convertirse en un bloqueador para los esfuerzos diarios de ningún equipo. La alineación con el plan
de adopción y las protecciones de refactorización pueden conducir a acuerdos respecto a los hitos y claridad con
respecto a las dependencias de estados futuros.
Figura 4: Iteración paralela de zonas de aterrizaje.

En las rutas de acceso de iteración de ejemplo anteriores, el equipo de adopción en la nube está migrando su
cartera de 100 cargas de trabajo a la nube. En paralelo, el equipo de plataforma en la nube se centra en seguir el
plan de adopción en la nube para asegurarse de que el entorno está preparado para esas cargas de trabajo.
En este ejemplo, las iteraciones planeadas se ejecutan de la siguiente manera:
El equipo de la plataforma en la nube inicia sus esfuerzos de desarrollo con la implementación de una zona
de aterrizaje inicial. Esa zona de aterrizaje permite al equipo de adopción en la nube implementar y comenzar
a probar su primera carga de trabajo.
Para prepararse para la próxima implementación de 10 cargas de trabajo del equipo de adopción en la nube,
el equipo de la plataforma en la nube trabaja por adelantado para refactorizar y agregar un entorno
conectado que trata la nube como una red perimetral.
Antes de que el equipo de adopción pueda lanzar su primera carga de trabajo de producción, el equipo de
seguridad necesita una revisión de seguridad. Mientras el equipo de adopción implementa las 10 primeras
cargas de trabajo, el equipo de la plataforma avanza para definir e implementar los requisitos de seguridad.
En el momento en que se libera la primera carga de trabajo para producción, ambos equipos deben tener
suficientes conocimientos para prepararse para un modelo de servicio compartido más a largo plazo. La
centralización de las arquitecturas de servicio principales le ayudará a alinear al equipo de operaciones y
gobernanza. La centralización de los servicios principales le ayudará a preparar el equipo de adopción para
escalar y liberar las siguientes olas de cargas de trabajo de producción.
A medida que el equipo se aproxima a su objetivo de migrar 100 cargas de trabajo, el equipo comenzará a
avanzar de forma natural hacia una estructura de equipo y modelo de colaboración de excelencia más
centrado en la nube.
La configuración de un entorno preparado para la empresa llevará tiempo. Este enfoque no eliminará ese
requisito. En su lugar, este enfoque está diseñado para quitar los bloqueadores iniciales y crear oportunidades
para que los equipos de plataforma y adopción aprendan juntos.
Protección de la refactorización de las zonas de aterrizaje

Todas las plantillas de la zona de aterrizaje iniciales tienen limitaciones. Las protecciones o las directivas durante
la refactorización deben reflejar esas limitaciones. Antes de comenzar un proceso de refactorización de zona de
aterrizaje, es importante comprender los requisitos a largo plazo del plan de adopción en la nube y la
clasificación de las cargas de trabajo candidatas, en comparación con las limitaciones de las plantillas iniciales.
Como ejemplo de establecimiento de protecciones de refactorización, comparemos el enfoque de desarrollo del
ejemplo anterior y el plano técnico de la zona de aterrizaje de migración de CAF.
En lo que se refiere a los supuestos del plano técnico de la zona de aterrizaje de migración de CAF, esta zona
de aterrizaje inicial no está diseñada para cargas de trabajo críticas ni datos confidenciales. Estas
características se deberán agregar mediante refactorización.
En este ejemplo, supongamos que la cartera de 100 cargas de trabajo requerirá funcionalidades de
hospedaje de datos críticos y confidenciales.
Para equilibrar estos dos requisitos competitivos, los equipos de adopción y plataforma trabajarán con las
siguientes condiciones acordadas:
El equipo de adopción en la nube priorizará las cargas de trabajo de producción que no tienen acceso a datos
confidenciales y no se consideran críticas.
Antes de la versión de producción, el equipo de seguridad y operaciones validará la alineación con la
directiva anterior.
El equipo de plataforma en la nube trabajará con los equipos de seguridad y gobernanza para implementar
una línea de base de seguridad. Una vez que la seguridad apruebe la implementación, se borrará el equipo
de adopción para migrar las cargas de trabajo que tengan acceso a algunos datos confidenciales.
El equipo de plataforma en la nube trabajará con el equipo de operaciones para implementar una línea de
base de administración. Una vez que el equipo de operaciones apruebe la implementación, el equipo de
adopción podrá migrar las cargas de trabajo con un nivel más alto de importancia.
En este ejemplo, el conjunto anterior de condiciones acordadas permitirá que el equipo de adopción empiece a
trabajar en la migración. También ayuda al equipo de plataforma a dar forma a sus interacciones con otros
equipos a medida que avanzan hacia un entorno listo para la empresa más a largo plazo.
Refactorización y cumplimiento de los requisitos a largo plazo

La sección de la metodología de protección para expandir la zona de aterrizaje le ayudará a avanzar hacia los
requisitos a largo plazo. A medida que el equipo de adopción de la nube progrese en su plan de adopción,
consulte Expansión de una zona de aterrizaje para obtener instrucciones que ayuden a tomar decisiones y
realice la refactorización para dar respuesta a los requisitos cambiantes de los diversos equipos.
Figura 5: Metodologías más detalladas que ayudan a una iteración paralela de zona de aterrizaje.
Cada subsección de Expansión de la zona de aterrizaje se corresponde a una de las adiciones descritas en la
imagen anterior. Más allá de esas expansiones básicas, las metodologías más profundas (como las de
gobernanza o administración) de este marco de trabajo le ayudarán a ir más allá de las modificaciones básicas
de la zona de aterrizaje para implementar materias a largo plazo.
Pasos siguientes
Para empezar a trabajar en un proceso de refactorización, comience por usar las zonas de aterrizaje de Azure.
Desarrollo controlado por pruebas (TDD) de las
zonas de aterrizaje
El desarrollo controlado por pruebas es un proceso de DevOps y de desarrollo de software común que
perfecciona la calidad de las nuevas características y las mejoras de cualquier solución basada en código. La
infraestructura basada en la nube y el código fuente subyacente pueden utilizar este proceso para garantizar
que las zonas de aterrizaje cumplan los requisitos principales y sean de alta calidad. Este proceso resulta
especialmente útil cuando se desarrollan y refactorizan las zonas de aterrizaje en un trabajo de desarrollo
paralelo.
En la nube, la infraestructura es la salida de la ejecución del código. El código bien estructurado, probado y
verificado genera una zona de aterrizaje viable. Una zona de aterrizaje es un entorno para hospedar cargas de
trabajo que se aprovisionan previamente mediante código. Incluye funcionalidades básicas que usan un
conjunto definido de servicios en la nube y procedimientos recomendados para poder lograr el éxito del
proceso. En esta guía se describe un enfoque para usar el desarrollo controlado por pruebas con el fin de
satisfacer la última parte de esa definición, a la vez que se cumplen los requisitos de calidad, seguridad,
operaciones y gobernanza.
Este enfoque se puede usar para satisfacer las solicitudes de características simples durante las primeras fases
del desarrollo. Más adelante en el ciclo de vida de la adopción de la nube, este proceso se puede usar para
cumplir los requisitos de seguridad, operaciones, gobernanza o cumplimiento.
Definición de finalizado
La instrucción "Configuración para lograr el éxito" es subjetiva. Proporciona al equipo de la plataforma en la
nube poca información útil durante el desarrollo de la zona de aterrizaje o los trabajos de refactorización. Esta
falta de claridad puede dar lugar a unas expectativas insuficientes y a puntos vulnerables inesperados en un
entorno de nube. Antes de refactorizar o expandir cualquier zona de aterrizaje, el equipo de la plataforma en la
nube debe tratar de aclarar la "definición de finalización" de cada zona de aterrizaje.
La definición de finalizado es un contrato sencillo entre el equipo de la plataforma en la nube y otros equipos
afectados. En este contrato se describen las características esperadas de valor añadido, que deben incluirse en
cualquier trabajo de desarrollo de las zonas de aterrizaje. La definición de finalizado es una lista de
comprobación que se alinea con el plan de adopción de la nube a corto plazo. En los procesos consolidados,
estas características esperadas de la lista de comprobación tendrán sus propios criterios de aceptación para
crear aún más claridad. Cuando todas características de valor añadido cumplen los criterios de aceptación,
significa que la zona de aterrizaje está suficientemente configurada para permitir el éxito de la oleada actual o
realizar el lanzamiento del trabajo de adopción.
A medida que los equipos adopten otras cargas de trabajo y características en la nube, la definición de
finalización y los criterios de aceptación se volverán cada vez más complejos.

El ciclo que hace efectivo el desarrollo controlado por pruebas a menudo se denomina prueba roja o verde. En
este enfoque, el equipo de la plataforma en la nube comienza con una prueba errónea (prueba roja) en función
de la definición de finalización y los criterios de aceptación definidos. Para cada característica o criterio de
aceptación, el equipo de la plataforma en la nube completará las tareas de desarrollo hasta que se supere la
prueba (prueba verde). En un ciclo de desarrollo controlado por pruebas (o una prueba roja/verde), se repetirán
los pasos básicos de la imagen y la lista que se muestran a continuación hasta que se pueda cumplir la
definición de finalización en su totalidad.
Creación de una prueba: defina una prueba para validar que se han cumplido los criterios de aceptación
de una característica de valor añadido específica. Automatice la prueba siempre que sea posible.
Prueba de la zona de aterrizaje: ejecute la prueba nueva y las existentes. Si la característica necesaria
todavía no se ha cumplido con los trabajos de desarrollo anteriores y no se incluye en la oferta del
proveedor de la nube, se debería producir un error en la prueba. La ejecución de pruebas existentes le
ayudará a validar que la nueva prueba no reduce la confiabilidad de las características de la zona de
aterrizaje que ofrece el código existente.
Expansión y refactorización de la zona de aterrizaje: agregue o modifique el código fuente para
cumplir la característica de valor añadido solicitada y mejorar la calidad general de la base de código. Para
satisfacer el espíritu más completo del desarrollo controlado por pruebas, el equipo de la plataforma en la
nube solo agregaría código para satisfacer la característica solicitada y nada más. Al mismo tiempo, la calidad
y el mantenimiento del código son un trabajo compartido. Al cumplir las nuevas solicitudes de
características, el equipo de la plataforma en la nube debe tratar de mejorar el código quitando la duplicación
y aclarándolo. Se recomienda encarecidamente ejecutar pruebas entre la creación de código nuevo y la
refactorización del código fuente.
Implementación de la zona de aterrizaje: una vez que el código fuente pueda cumplir la solicitud de la
característica, implemente la zona de aterrizaje modificada en el proveedor de nube en un entorno de
espacio aislado o de pruebas controlado.
Prueba de la zona de aterrizaje: la nueva prueba de la zona de aterrizaje debe validar que el nuevo
código cumple los criterios de aceptación de la característica solicitada. Una vez que se superen todas las
pruebas, la característica se considerará completada y se considerará que se cumplen los criterios de
aceptación.
Cuando todas las características de valor añadido y los criterios de aceptación superen las pruebas asociadas, la
zona de aterrizaje estará lista para admitir la siguiente oleada del plan de adopción de la nube.
Ejemplo sencillo de una definición de finalización

Para un trabajo de migración inicial, la definición de finalización puede ser demasiado simple. A continuación, se
muestra uno de estos ejemplos demasiado sencillos.
La zona de aterrizaje inicial se usará para hospedar 10 cargas de trabajo con fines de aprendizaje inicial.
Estas cargas de trabajo no son críticas para la empresa y no tienen acceso a datos confidenciales. En el
futuro, es probable que estas cargas de trabajo se liberen a producción, pero no se espera que la
importancia y la confidencialidad cambien. Para admitir estas cargas de trabajo, el equipo de adopción de
la nube necesitará que se cumplan los siguientes criterios:
Segmentación de la red que se alineará con el diseño de la red propuesto.
Acceso a recursos de proceso, almacenamiento y redes para hospedar las cargas de trabajo orientadas a
la detección de patrimonio digital.
Asignación de un nombre al esquema y etiquetado de este para facilitar su uso.
Este entorno se debe tratar como una red perimetral con acceso a la red pública de Internet.
Durante los trabajos de adopción, el equipo de adopción de la nube quiere obtener acceso temporal al
entorno para cambiar las configuraciones del servicio.
Solo a título informativo: antes de pasar a una versión de producción, estas cargas de trabajo requerirán
la integración con el proveedor de identidades corporativo para controlar la identidad y el acceso
continuos, con el fin de administrar las operaciones. En ese momento, se debe revocar el acceso al equipo
El último punto no es una característica ni un criterio de aceptación, sino que se trata de un indicador para
señalar que se necesitarán expansiones adicionales y que estas se deben explorar con otros equipos
anteriormente.
Ejemplos adicionales de una definición de finalización

La metodología de gobernanza de Cloud Adoption Framework proporciona un recorrido narrativo a través de la
consolidación natural de un equipo de gobernanza. Insertados en ese recorrido, hay varios ejemplos de
"definición de finalizado" y "criterios de aceptación" en formato de instrucciones de directiva.
Declaraciones de la directiva iniciales: ejemplo de las directivas corporativas que rigen y la definición inicial
de finalizado en función de los requisitos de adopción de la fase temprana.
Expansión de identidad: ejemplo de las directivas corporativas que rigen la definición de finalizado a fin de
cumplir con los requisitos para expandir la administración de identidades para una zona de aterrizaje.
Expansión de seguridad: ejemplo de las directivas corporativas que rigen la definición de finalizado para
cumplir los requisitos de seguridad que se ajustan al plan de adopción de la nube de referencia.
Expansión de operaciones: ejemplo de las directivas corporativas que rigen la definición de finalizado para
cumplir los requisitos básicos de administración de operaciones.
Expansión de costos: ejemplo de las directivas corporativas que rigen definición de finalizado para cumplir
los requisitos de administración de costos.
Los ejemplos anteriores son ejemplos básicos para desarrollar una definición de finalizado para las zonas de
aterrizaje. Hay más ejemplos de directivas disponibles para cada una de las disciplinas de gobernanza de la
nube.
Pasos siguientes
Para acelerar el desarrollo controlado por pruebas en Azure, revise las características de desarrollo controlado
por pruebas de Azure.
Desarrollo controlado por pruebas en Azure
Desarrollo controlado por pruebas de las zonas de
aterrizaje en Azure
Como se describe en el artículo anterior sobre el desarrollo controlado por pruebas para zonas de aterrizaje
(TDD), los ciclos de TDD comienzan con una prueba que valida los criterios de aceptación de una característica
específica necesaria para proporcionar el plan de adopción de la nube. A continuación, se puede probar la
expansión o refactorización de la zona de aterrizaje para validar que se cumplen los criterios de aceptación. En
este artículo se describe una cadena de herramientas nativa en la nube de Azure para automatizar los ciclos de
desarrollo controlado por pruebas.
Herramientas de Azure para admitir ciclos de TDD de zona de

aterrizaje
Figura 1: Herramientas de desarrollo controlado por pruebas de Azure.

La cadena de herramientas de los productos y servicios de gobernanza nativa de Azure se puede integrar
fácilmente en el desarrollo controlado por pruebas para la creación de zonas de aterrizaje. Cada una de estas
herramientas sirve para un propósito específico, lo que facilita el desarrollo, la prueba y la implementación de la
zona de aterrizaje en alineación con los ciclos de TDD.
Plantillas de implementación y prueba proporcionadas por Microsoft

para acelerar el TDD
Microsoft proporciona los ejemplos siguientes con fines de gobernanza. Cada uno se puede usar como prueba o
serie de pruebas en un ciclo de desarrollo controlado por pruebas para zonas de aterrizaje. En las siguientes
secciones se proporciona más información acerca de cada herramienta:
Azure Blueprints proporciona varios ejemplos de planos técnicos que incluyen directivas para las pruebas y
plantillas para la implementación. Estos ejemplos de plano técnico pueden acelerar los esfuerzos de
desarrollo, implementación y pruebas en ciclos de TDD.
Azure Policy también incluye iniciativas de directivas integradas, que se pueden usar para probar y aplicar la
definición completa de finalización para una zona de aterrizaje. Azure Policy incluye definiciones de directivas
integradas que pueden cumplir los criterios de aceptación individuales dentro de la definición de finalización.
Azure Graph incluye muestras de consulta avanzadas que se pueden usar para entender cómo se
implementan las cargas de trabajo en una zona de aterrizaje para escenarios de prueba avanzados.
Las plantillas de inicio rápido de Azure proporcionan plantillas de código fuente para ayudar a agilizar la
implementación de la carga de trabajo y la zona de aterrizaje.
Los ejemplos anteriores se pueden usar como herramientas para acelerar los ciclos de TDD. Esos ejemplos se
ejecutan en las herramientas de gobernanza en las secciones siguientes, lo que permite a los equipos de
plataforma en la nube crear sus propias pruebas y código fuente.
Herramientas de gobernanza de Azure que pueden acelerar los ciclos

de TDD
Azure Policy: Cuando las implementaciones o intentos de implementación se desvían de las directivas de
gobierno, Azure Policy puede proporcionar detección, protección y resolución automatizadas. Pero Azure Policy
también proporciona el mecanismo principal para probar los criterios de aceptación en la "definición de
finalización". En un ciclo de TDD, se puede crear una definición de directiva para probar un único criterio de
aceptación. Del mismo modo, se pueden agregar todos los criterios de aceptación a una iniciativa de directiva
asignada a toda la suscripción. Este enfoque proporciona un mecanismo para "pruebas rojas" antes de modificar
la zona de aterrizaje. Una vez que la zona de aterrizaje cumple la definición de finalización, se puede usar para
aplicar los criterios de prueba con el fin de evitar cambios en el código que podrían provocar errores en la
prueba en futuras versiones.
Azure Blueprints. Azure Blueprints agrupa las directivas y otras herramientas de implementación en un paquete
repetible que se puede asignar a varias zonas de aterrizaje. Blueprints resulta útil cuando varios esfuerzos de
adopción comparten definiciones de finalización, que podría querer actualizar con el tiempo. También puede
ayudar con la implementación durante los siguientes esfuerzos para expandir y refactorizar zonas de aterrizaje.
Azure Resource Graph Resource Graph proporciona un lenguaje de consulta para crear pruebas controladas por
datos basadas en información sobre los recursos implementados en una zona de aterrizaje. Más adelante en el
plan de adopción, esta herramienta también puede definir pruebas complejas basadas en las interacciones entre
los recursos de carga de trabajo y el entorno en la nube subyacente.
Plantillas de Azure Resource Manager: Estas plantillas proporcionan el código fuente principal de cualquier
entorno implementado en Azure. Algunas herramientas de terceros como Terraform generan sus propias
plantillas de Resource Manager, las cuales se envían a continuación a Azure Resource Manager.
Azure Resource Manager: Resource Manager proporciona una plataforma coherente para las funciones de
compilación e implementación. Esta plataforma puede implementar zonas de aterrizaje basadas en definiciones
de código fuente.
Pasos siguientes
Para empezar a refactorizar la primera zona de aterrizaje, evalúe las consideraciones básicas de la zona de
aterrizaje.
Consideraciones básicas sobre la zona de aterrizaje
Procedimientos recomendados de preparación para
Azure
El proceso de preparación para la nube consiste en dotar al personal de las aptitudes técnicas necesarias para
comenzar un esfuerzo de adopción de la nube y preparar el entorno de destino de la migración para los
recursos y las cargas de trabajo que trasladará a la nube. Lea estos procedimientos recomendados e
instrucciones adicionales para ayudar al equipo a preparar el entorno de Azure.

Organice e implemente los recursos en el entorno de Azure.
Conceptos básicos de Azure. Conozca los conceptos y términos clave de Azure y cómo se relacionan entre sí
estos conceptos.
Cree las suscripciones iniciales. Establezca un conjunto inicial de suscripciones de Azure para comenzar la
Escale el entorno de Azure mediante varias suscripciones. Comprenda los motivos y estrategias de la
creación de suscripciones adicionales para escalar el entorno de Azure.
Organización de los recursos con grupos de administración de Azure. Conozca cómo los grupos de
administración de Azure pueden administrar recursos, roles, directivas e implementaciones en varias
suscripciones.
Siga las convenciones recomendadas de nomenclatura y etiquetado. Revise las recomendaciones detalladas
para asignar nombres a los recursos y etiquetarlos. Estas recomendaciones son aplicables a los procesos de
adopción de la nube empresarial.
Creación de coherencia en la nube híbrida. Cree soluciones de nube híbrida que ofrezcan las ventajas de la
innovación en la nube conservando muchas de las comodidades de la administración local.
Redes
Prepare la infraestructura de red en la nube para admitir las cargas de trabajo.
Decisiones respecto a las redes. Elija los servicios, herramientas y arquitecturas de redes que satisfagan los
requisitos de carga de trabajo, gobernanza y conectividad de la organización.
Planeamiento de redes virtuales. Planee redes virtuales según los requisitos de aislamiento, conectividad y
ubicación.
Procedimientos recomendados de seguridad de la red. Conozca los procedimientos recomendados para
solucionar problemas habituales de seguridad de la red mediante las funcionalidades de Azure integradas.
Redes perimetrales. Permita la conectividad segura entre las redes de la nube y las redes de los centros de
datos locales o físicos, así como todo tipo de conectividad hacia Internet y desde este.
Topología de red en estrella tipo hub-and-spoke. Administre los requisitos comunes de comunicación o
seguridad de manera eficaz para cargas de trabajo complicadas y afronte posibles limitaciones de
suscripción.
Control de identidades y acceso

Diseñe la infraestructura de control de identidades y acceso para mejorar la seguridad y la eficacia de la
administración de las cargas de trabajo.
Procedimientos recomendados de seguridad para la administración de identidades y el control de acceso en
Azure. Conozca los procedimientos recomendados para la administración de identidades y la seguridad del
control de acceso mediante las funcionalidades integradas de Azure.
Procedimientos recomendados del control de acceso basado en rol de Azure. Habilite la administración de
acceso específico y basado en grupos para recursos organizados en torno a roles de usuario.
Protección del acceso con privilegios para las implementaciones híbridas y en la nube en Azure Active
Directory. Asegúrese de que las cuentas de acceso administrativo y las cuentas con privilegios de la
organización son seguras en la nube y en el entorno local.
Storage
Guía de Azure Storage. Seleccione la solución de Azure Storage adecuada que admita sus escenarios de uso.
Guía de seguridad de Azure Storage. Obtenga más información sobre las características de seguridad de
Azure Storage.
Bases de datos
Elección de la opción correcta de SQL Server en Azure. Elija la solución PaaS o IaaS que mejor admita las
cargas de trabajo de SQL Server.
Procedimientos recomendados sobre la seguridad de las bases de datos. Conozca los procedimientos
recomendados sobre la seguridad de las bases de datos en la plataforma Azure.
Elija el almacén de datos apropiado. Seleccione el almacén de datos adecuado que satisfaga sus necesidades.
Hay cientos de opciones de implementación disponibles entre bases de datos SQL y NoSQL. Los almacenes
de datos a menudo se clasifican según la forma de estructurar los datos y según los tipos de operaciones que
admiten. Este artículo describe algunos de los modelos de almacenamiento habituales.
AI + Aprendizaje automático
Configuración de Azure Machine Learning para escala empresarial. Obtenga información sobre los puntos de
decisión clave en la configuración de Azure Machine Learning para su organización.
Seguimiento de los costos a través de las unidades de negocio, entornos o proyectos. Obtenga información
sobre los procedimientos recomendados para crear mecanismos adecuados de seguimiento de costos.
Optimización de la inversión en la nube con Azure Cost Management + Billing. Implemente una estrategia de
administración de costos y obtenga información sobre las herramientas disponibles para afrontar los
desafíos de los costos.
Creación y administración de presupuestos. Aprenda a crear y administrar presupuestos mediante Azure
Cost Management + Billing.
Exportación de datos de costos. Aprenda a exportar datos de costos mediante Azure Cost Management +
Billing.
Optimización de los costos a partir de las recomendaciones. Aprenda a identificar recursos infrautilizados y a
reducir los costos con Azure Cost Management + Billing y Azure Advisor.
Uso de alertas de costos para supervisar el uso y el gasto. Aprenda a usar las alertas de Azure Cost
Management + Billing para supervisar el uso y el gasto en Azure.
Creación de las suscripciones de Azure iniciales
Para empezar el proceso de adopción de Azure, cree un conjunto inicial de suscripciones. Obtenga información
sobre las suscripciones con las que debe comenzar según sus requisitos iniciales.
Las dos primeras suscripciones

Empiece por crear dos suscripciones:
Cree una suscripción de Azure para que contenga las cargas de trabajo de producción.
Cree una segunda suscripción que actúe como entorno de no producción, mediante una oferta con los
precios de desarrollo y pruebas de Azure para conseguir un precio más reducido.
Figura 1: Modelo de suscripción inicial con imágenes de

llaves junto a cuadros de "producción" y "no producción".
Este enfoque tiene muchas ventajas:
El uso de suscripciones independientes para los entornos de producción y de no producción crea un límite
que hace que la administración de los recursos sea más sencilla y segura.
Las ofertas de la suscripción de desarrollo y pruebas de Azure están disponibles para cargas de trabajo que
no son de producción. Estas ofertas proporcionan tarifas con descuento para los servicios y licencias de
software de Azure.
Los entornos de producción y no producción probablemente tendrán diferentes conjuntos de directivas de
Azure. El uso de suscripciones independientes simplifica la aplicación de cada directiva específica en el nivel
de suscripción.
Puede permitir determinados tipos de recursos de Azure en la suscripción de no producción con fines de
prueba. Puede habilitar esos proveedores de recursos en la suscripción de no producción sin que estén
disponibles en el entorno de producción.
Puede usar las suscripciones de desarrollo y pruebas de Azure como entornos de espacio aislado. Estos
espacios aislados permiten a los administradores y desarrolladores crear y eliminar rápidamente conjuntos
completos de recursos de Azure. Este aislamiento también puede ayudar con la protección de datos y los
problemas de seguridad.
Los umbrales de costo aceptables que define variarán probablemente entre las suscripciones de producción
y no producción.
Suscripciones de espacio aislado

Si incluye objetivos de innovación como parte de la estrategia de adopción de la nube, considere la posibilidad
de crear una o varias suscripciones de espacio aislado. Puede aplicar directivas de seguridad para mantener
estas suscripciones de prueba aisladas de los entornos de producción y de no producción. Los usuarios pueden
experimentar fácilmente con las funcionalidades de Azure en estos entornos aislados. Use la oferta del plan de
tarifa Desarrollo/pruebas de Azure para crear estas suscripciones.
Figura 2: Modelo
de suscripción con suscripciones de espacios aislados.
Suscripción de servicios compartidos

Si planea hospedar más de 1000 máquinas vir tuales o instancias de proceso en la nube en un plazo
de 24 meses , cree otra suscripción de Azure para hospedar servicios compartidos. Esto le preparará para que
pueda admitir la arquitectura empresarial en su estado final.
Figura 3: Modelo de suscripción con servicios

compartidos.
Pasos siguientes
Revise las razones por las que es posible que quiera crear suscripciones de Azure adicionales para satisfacer sus
necesidades.
Creación de suscripciones adicionales para escalar el entorno de Azure
Creación de suscripciones adicionales para escalar
el entorno de Azure
Las organizaciones suelen usar varias suscripciones de Azure para evitar límites de recursos por suscripción y
administrar y gobernar mejor sus recursos de Azure. Es importante definir una estrategia para escalar las
suscripciones.
Revisión de los conceptos básicos

A medida que expande el entorno de Azure más allá de las suscripciones iniciales, es importante comprender
conceptos de Azure como cuentas, inquilinos, directorios y suscripciones. Para más información, consulte
Conceptos básicos de Azure.
Otras consideraciones podrían requerir suscripciones adicionales. Tenga en cuenta lo siguiente al ampliar su
espacio en la nube.
Consideraciones técnicas
Límites de suscripción: Las suscripciones tienen límites definidos para algunos tipos de recursos. Por
ejemplo, el número de redes virtuales de una suscripción es limitado. Si una suscripción se acerca a estos
límites, tendrá que crear otra suscripción y colocar ahí los recursos adicionales. Para más información, consulte
Azure subscription and service limits (Límites de suscripción y servicio de Azure).
Recursos del modelo clásico: Si usa Azure desde hace mucho tiempo, puede que tenga recursos que se
crearon con el modelo de implementación clásica. Las directivas de Azure, el control de acceso basado en rol de
Azure, la agrupación de recursos y las etiquetas no se pueden aplicar a los recursos del modelo clásico. Estos
recursos se deben trasladar a suscripciones que contengan solo recursos del modelo clásico.
Costos: Es posible que se generen costos adicionales por la entrada y salida de datos entre las suscripciones.
Las prioridades empresariales pueden llevarle a crear suscripciones adicionales. Estas prioridades incluyen:
Innovación
Migración
Coste
Operaciones
Seguridad
Gobernanza
Para otras consideraciones sobre el escalado de las suscripciones, revise la Guía de decisiones de suscripción de
Traslado de recursos entre suscripciones

A medida que crezca el modelo de suscripciones, puede decidir que algunos de los recursos pertenezcan a otras
suscripciones. Hay muchos tipos de recursos que se pueden mover entre suscripciones. También puede usar
implementaciones automatizadas para volver a crear recursos en otra suscripción. Para más información,
consulte Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción.
Sugerencias para crear suscripciones

Identifique quién será responsable de crear las suscripciones.
Decida qué tipos de recursos estarán disponibles en una suscripción de forma predeterminada.
Decida el aspecto de todas las suscripciones estándar. Es necesario considerar el acceso RBAC de Azure, las
directivas, las etiquetas y los recursos de infraestructura.
Si es posible, cree mediante programación nuevas suscripciones con una entidad de servicio. Debe conceder
permiso a la entidad de servicio para crear suscripciones. Defina un grupo de seguridad que pueda solicitar
nuevas suscripciones a través de un flujo de trabajo automatizado.
Si es cliente de un Contrato Enterprise (EA), pídale al servicio de soporte técnico de Azure que bloquee la
creación de suscripciones no EA en su organización.
Pasos siguientes
Cree una jerarquía de grupos de administración que le ayude a organizar y administrar las suscripciones y
recursos.
Organización y administración de las suscripciones y recursos
Organización y administración de varias
suscripciones de Azure
Si solo tiene algunas suscripciones, administrarlas de forma independiente es relativamente sencillo. Pero si
tiene muchas suscripciones, cree una jerarquía de grupos de administración que le ayude a administrar las
suscripciones y recursos.
Grupos de administración de Azure

Los grupos de administración de Azure lo ayudan a administrar de forma eficaz el acceso, las directivas y el
cumplimiento de las suscripciones. Cada grupo de administración es un contenedor de una o más suscripciones.
Los grupos de administración están organizados en una sola jerarquía. Esta jerarquía se define en el inquilino de
Azure Active Directory (Azure AD) para que se alinee con la estructura y las necesidades de la organización. El
nivel superior se denomina grupo de administración raíz. Puede definir hasta seis niveles de grupos de
administración en la jerarquía. Cada suscripción está contenida en un solo grupo de administración.
Azure proporciona cuatro niveles de ámbito de administración:
Grupos de administración
Suscripciones
Grupos de recursos
Recursos
Cualquier acceso o directiva aplicados en un nivel de la jerarquía se hereda por los niveles inferiores. El
propietario de un recurso o de una suscripción no puede modificar una directiva heredada. Esta limitación
ayuda a mejorar la gobernanza.
NOTE
La herencia de etiquetas no se admite en este momento, pero lo hará próximamente.
Este modelo de herencia le permite organizar las suscripciones de la jerarquía de forma que cada suscripción
siga las directivas y los controles de seguridad adecuados.
Ilustración 1: Los cuatro niveles de ámbito para

organizar los recursos de Azure.
Todas las asignaciones de acceso o directivas en el grupo de administración raíz se aplican a todos los recursos
dentro del directorio. Considere cuidadosamente qué elementos define en este ámbito. Incluya solo las
asignaciones que debe tener.
Creación de la jerarquía de grupos de administración

Al definir la jerarquía de grupos de administración, primero debe crear el grupo de administración raíz. A
continuación, mueva todas las suscripciones existentes en el directorio al grupo de administración raíz. Las
nuevas suscripciones siempre se crean en el grupo de administración raíz. Posteriormente, puede moverlas a
otro grupo de administración.
Cuando se mueve una suscripción a un grupo de administración existente, se heredan las asignaciones de
directivas y roles de la jerarquía de grupos de administración que se encuentra por encima. Una vez que haya
establecido varias suscripciones para las cargas de trabajo de Azure, puede crear suscripciones adicionales para
que contengan los servicios de Azure que otras suscripciones comparten.
Si prevé que el entorno de Azure crecerá, debe crear grupos de administración de producción y de no
producción ahora, y aplicar las directivas y controles de acceso adecuados en el nivel del grupo de
administración. Las nuevas suscripciones heredarán los controles adecuados a medida que se agreguen a cada
Ilustración 2: Ejemplo de una jerarquía de grupos de administración.
Casos de uso de ejemplo

Estos son algunos ejemplos básicos del uso de grupos de administración para separar diferentes cargas de
trabajo:
Cargas de trabajo de producción y de no producción: Use los grupos de administración para administrar
más fácilmente los distintos roles y directivas entre las suscripciones de producción y de no producción. Por
ejemplo, los desarrolladores pueden tener acceso de colaborador en suscripciones que no son de producción,
pero solo acceso de lectura en suscripciones de producción.
Ser vicios internos y ser vicios externos: Las empresas suelen tener requisitos, directivas y roles diferentes
para los servicios internos y los servicios externos orientados al cliente.
Revise los siguientes recursos para más información sobre la organización y administración de los recursos de
Azure.
Organización de los recursos con grupos de administración de Azure
Elevación de los privilegios de acceso para administrar todas las suscripciones y los grupos de
administración de Azure
Traslado de recursos de Azure a otro grupo de recursos o a otra suscripción
Pasos siguientes
Revise las convenciones de recomendadas de nomenclatura y etiquetado que se deben seguir al implementar
los recursos de Azure.
Convenciones recomendadas de nomenclatura y etiquetado
Desarrollo de la estrategia de nomenclatura y
etiquetado de los recursos de Azure
Organice sus recursos en la nube para dar apoyo a la gobernanza y a los requisitos de administración de
operaciones y de contabilidad. Unas convenciones de nomenclatura y etiquetado de metadatos bien definidas
ayudan a localizar y administrar los recursos rápidamente. Estas convenciones también ayudan a asociar los
costos de uso de la nube a los equipos empresariales mediante los mecanismos de contabilidad de contracargo
y visualización de costos.
Defina su estrategia de nomenclatura y etiquetado lo antes posible. Use los vínculos siguientes para ayudarle a
definir e implementar su estrategia:
Abreviaturas recomendadas para los tipos de recursos de Azure
Guía de decisiones de nomenclatura y etiquetado de recursos
NOTE
Cada empresa tiene sus propios requisitos de organización y administración. Estas recomendaciones ayudan a iniciar un
debate con los equipos de adopción de la nube. A medida que avanza el debate, use la siguiente plantilla para
documentar las decisiones sobre nomenclatura y etiquetado que tome al adaptar estas recomendaciones a sus
necesidades empresariales específicas.
Descargue la plantilla de seguimiento de convención de nomenclatura y etiquetado.
Finalidad de la nomenclatura y el etiquetado

La representación y nomenclatura precisa de los recursos es esencial por motivos de seguridad. En caso de que
se produzca un incidente de seguridad, es fundamental identificar rápidamente los sistemas afectados, las
funciones que apoyan esos sistemas y el posible impacto empresarial. Servicios de seguridad como Azure
Security Center y Azure Sentinel consultan los recursos y su información de registro o alerta asociada por el
nombre del recurso.
Azure define reglas y restricciones de nomenclatura para los recursos de Azure. Esta guía proporciona
recomendaciones detalladas para respaldar los esfuerzos de adopción de la nube empresarial.
El cambio de nombres de los recursos puede ser difícil. Establezca una convención de nomenclatura completa
antes de comenzar cualquier implementación de nube de gran tamaño.
Estrategia de nomenclatura y etiquetado

Una estrategia de nomenclatura y etiquetado incluye detalles empresariales y operativos como componentes de
nombres de recursos y etiquetas de metadatos:
La parte empresarial de esta estrategia garantiza que los nombres y las etiquetas de los recursos incluyen
la información organizativa necesaria para identificar a los equipos. Use un recurso junto con los
propietarios de la empresa responsables de los costos de los recursos.
El lado operativo garantiza que los nombres y las etiquetas incluyen información que los equipos de TI
usan para identificar la carga de trabajo, la aplicación, el entorno, la importancia y otra información útil
para administrar los recursos.
Pasos siguientes
Obtenga información sobre los aspectos a considerar para definir la convención de nomenclatura de los
recursos de Azure y revise los nombres de ejemplo de estos.
Asignación de un nombre a los recursos de Azure
Una convención de nomenclatura eficaz crea nombres de recursos a partir de información importante sobre
cada recurso. Un nombre bien elegido le ayuda a identificar rápidamente el tipo del recurso, su carga de trabajo
asociada, su entorno de implementación y la región de Azure que lo hospeda. Por ejemplo, el nombre de un
recurso de IP pública de una carga de trabajo de producción de SharePoint residente en la región Oeste de
EE. UU. podría ser pip-sharepoint-prod-westus-001 .
Diagrama 1: Componentes de un nombre de recurso de Azure.
Ámbito de nomenclatura
Todos los tipos de recursos de Azure tienen un ámbito que define el nivel en el que los nombres de los recursos
deben ser únicos. Un recurso debe tener un nombre único dentro de su ámbito.
Por ejemplo, una red virtual tiene un ámbito de grupo de recursos, lo que significa que solo puede haber una
red llamada vnet-prod-westus-001 en un grupo de recursos determinado. Otros grupos de recursos podrían
tener su propia red virtual llamada vnet-prod-westus-001 . Las subredes tienen como ámbito las redes virtuales
por lo que cada subred de una red virtual debe tener un nombre diferente.
Algunos nombres de recursos, como los servicios PaaS con puntos de conexión públicos o etiquetas DNS de
máquina virtual, tienen ámbitos globales, por lo que deben ser únicos en toda la plataforma de Azure.
Diagrama 2: Niveles de ámbito de los nombres de recursos de Azure.

Los nombres de los recursos tienen límites de longitud. Equilibrar el contexto insertado en un nombre con su
ámbito y límite de longitud es importante al desarrollar las convenciones de nomenclatura. Para más
información, consulte Reglas y restricciones de nomenclatura para los recursos de Azure.
Componentes de nomenclatura recomendados
Cuando construya su convención de nomenclatura, identifique las partes clave de la información que quiere
reflejar en el nombre de un recurso. Cada información es pertinente para un tipo de recurso. En la lista siguiente
se proporcionan ejemplos de información que son útiles al construir nombres de recursos.
Mantenga corta la longitud de los componentes de nomenclatura para evitar que se superen los límites de
longitud de los nombres de recursos.
C O M P O N EN T E DE N O M EN C L AT URA DESC RIP C IÓ N
Tipo de recurso Una abreviatura que representa el tipo de recurso de Azure.

Este componente se usa a menudo como prefijo o sufijo en
el nombre. Para más información, consulte las Abreviaturas
recomendadas para los tipos de recursos de Azure. Ejemplos:
rg , vm
Unidad de negocio División de nivel superior de la empresa que posee la

suscripción o la carga de trabajo a la que pertenece el
recurso. En organizaciones más pequeñas, este componente
podría representar un único elemento organizativo de nivel
superior corporativo. Ejemplos: fin , mktg , product ,
it , corp
Nombre de aplicación o ser vicio Nombre de la aplicación, carga de trabajo o servicio del que
forma parte el recurso. Ejemplos: navigator , emissions ,
sharepoint , hadoop
Tipo de suscripción Descripción resumida del propósito de la suscripción que

contiene el recurso. A menudo desglosado por tipo de
entorno de implementación o cargas de trabajo específicas.
Ejemplos: prod , shared , client
**Entorno de implementación ** Fase del ciclo de vida de desarrollo de la carga de trabajo que
admite el recurso. Ejemplos: prod , dev , qa , stage ,
test
Región La región de Azure en la que se implementa el recurso.

Ejemplos: westus , eastus2 , westeu , usva , ustx
Nombres de ejemplo de los tipos de recursos comunes de Azure

En la siguiente sección se proporcionan algunos ejemplos de nombres para tipos de recursos comunes de Azure
en una implementación de nube en la empresa.
NOTE
Algunos de estos nombres de ejemplo usan un esquema de relleno de tres dígitos ( ### ), como mktg-prod-001 .
El relleno mejora la legibilidad y la ordenación de los recursos cuando esos recursos se administran en una base de datos
de administración de configuración (CMDB), en la herramienta de administración de recursos de TI o en las herramientas
de contabilidad tradicionales. Cuando el recurso implementado se administra de forma centralizada como parte de un
inventario mayor o de una cartera de recursos de TI, el enfoque de relleno está en línea con las interfaces que los sistemas
usan para administrar la nomenclatura del inventario.
Desafortunadamente, el enfoque tradicional de relleno de recursos puede resultar problemático en los enfoques de
infraestructura como código que pueden recorrer en iteración los recursos en función de un número no rellenado. Este
enfoque es común durante la implementación o las tareas de administración de configuración automatizadas. Esos scripts
tendrían que seccionar el relleno sistemáticamente y convertir el número rellenado en un número real, lo que ralentizaría
el desarrollo del script y el tiempo de ejecución.
Elija un enfoque adecuado para su organización. El relleno que se muestra aquí ejemplifica la importancia del uso de un
enfoque coherente para la numeración del inventario, no para indicar cuál es el mejor enfoque. Antes de elegir un
esquema de numeración (con o sin relleno), evalúe qué tendrá un mayor impacto en las operaciones a largo plazo:
Soluciones de administración de activos y CMDB o administración del inventario basada en código. Después, decida de
forma coherente la opción de relleno que mejor se adapte a sus necesidades operativas.
Nombres de ejemplo General

T IP O DE REC URSO Á M B ITO F O RM ATO Y E JEM P LO S
Grupo de administración Unidad de negocio y/o mg-<business unit>[-<environment

tipo de entorno type>]
mg-mktg
mg-hr
mg-corp-prod
mg-fin-client
Suscripción Cuenta o Contrato Enterprise <business unit>-<subscription type>-

<###>
mktg-prod-001
corp-shared-001
fin-client-001
Grupos de recursos Suscripción rg-<app or service name>-

<subscription type>-<###>
rg-mktgsharepoint-prod-001
rg-acctlookupsvc-shared-001
rg-ad-dir-services-shared-001
Instancia del ser vicio API Global apim-<app or service name>

Management
apim-navigator-prod
Identidad administrada Resource group id-<app or service name>
id-appcn-keda-prod-eastus2-001
Nombres de ejemplo: Redes
Red vir tual Resource group vnet-<subscription type>-<region>-

<###>
vnet-shared-eastus2-001
vnet-prod-westus-001
vnet-client-eastus2-001
Subred Virtual network snet-<subscription>-<region>-

<###>
snet-shared-eastus2-001
snet-prod-westus-001
snet-client-eastus2-001
Tarjeta de interfaz de red (NIC) Resource group nic-<##>-<vm name>-

<subscription>-<###>
nic-01-dc1-shared-001
nic-02-vmhadoop1-prod-001
nic-02-vmtest1-client-001
Dirección IP pública Resource group pip-<vm name or app name>-

<environment>-<region>-<###>
pip-dc1-shared-eastus2-001
pip-hadoop-prod-westus-001
Equilibrador de carga Resource group lb-<app name or role>--<###>
lb-navigator-prod-001
lb-sharepoint-dev-001
Grupo de seguridad de red (NSG) Subred o NIC nsg-<policy name or app name>-
<###>
nsg-weballow-001
nsg-rdpallow-001
nsg-sqlallow-001
nsg-dnsblocked-001
Puer ta de enlace de red local Puerta de enlace virtual lgw-<subscription type>-<region>-

<###>
lgw-shared-eastus2-001
lgw-prod-westus-001
lgw-client-eastus2-001
Puer ta de enlace de red vir tual Virtual network vgw-<subscription type>-<region>-

<###>
vgw-shared-eastus2-001
vgw-prod-westus-001
vgw-client-eastus2-001
Conexión de sitio a sitio Resource group cn-<local gateway name>-to-

<virtual gateway name>
cn-lgw-shared-eastus2-001-to-
vgw-shared-eastus2-001
cn-lgw-shared-eastus2-001-to-
vgw-shared-westus-001
Conexión VPN Resource group cn-<subscription1>-<region1>-to-

<subscription2>-<region2>-
cn-shared-eastus2-to-shared-
westus
cn-prod-eastus2-to-prod-westus
Tabla de rutas Resource group route-<route table name>
route-navigator
route-sharepoint
Etiqueta DNS Global <DNS A record for VM>.

<region>.cloudapp.azure.com
dc1.westus.cloudapp.azure.com
web1.eastus2.cloudapp.azure.com
Nombres de ejemplo: Procesos y web

Máquina vir tual Resource group vm<policy name or app name><###>
vmnavigator001
vmsharepoint001
vmsqlnode001
vmhadoop001
Cuenta de almacenamiento de Global stvm<performance type><app name

máquina vir tual or prod name><region><###>
stvmstcoreeastus2001
stvmpmcoreeastus2001
stvmstplmeastus2001
stvmsthadoopeastus2001
Aplicación web Global app-<app name>-<environment>-

<###>.azurewebsites.net
app-navigator-prod-
001.azurewebsites.net
app-accountlookup-dev-
Aplicación de función Global func-<app name>-<environment>-

<###>.azurewebsites.net
func-navigator-prod-
func-accountlookup-dev-
ser vicio en la nube Global cld-<app name>-<environment>-

<###>.cloudapp.net}
cld-navigator-prod-
cld-accountlookup-dev-
Espacio de nombres de Global ntfns-<app name>-<environment>

Notification Hubs
ntfns-navigator-prod
ntfns-emissions-dev
Centro de notificaciones Espacio de nombres de Notification ntf-<app name>-<environment>

Hubs
ntf-navigator-prod
ntf-emissions-dev
Nombres de ejemplo: Bases de datos

Ser vidor de Azure SQL Database Global sql-<app name>-<environment>
sql-navigator-prod
sql-emissions-dev
Azure SQL Database Azure SQL Database sqldb-<database name>-

<environment>
sqldb-users-prod
sqldb-users-dev
Base de datos de Azure Global cosmos-<app name>-<environment>

Cosmos DB
cosmos-navigator-prod
cosmos-emissions-dev
Instancia de Azure Cache for Global redis-<app name>-<environment>

Redis
redis-navigator-prod
redis-emissions-dev
Base de datos de MySQL Global mysql-<app name>-<environment>
mysql-navigator-prod
mysql-emissions-dev
Base de datos de PostgreSQL Global psql-<app name>-<environment>
psql-navigator-prod
psql-emissions-dev
Azure SQL Data Warehouse Global sqldw-<app name>-<environment>
sqldw-navigator-prod
sqldw-emissions-dev
SQL Ser ver Stretch Database Azure SQL Database sqlstrdb-<app name>-
<environment>
sqlstrdb-navigator-prod
sqlstrdb-emissions-dev
Nombres de ejemplo: Storage

Cuenta de Storage (uso general) Global st<storage name><###>
stnavigatordata001
stemissionsoutput001
Cuenta de Storage (registros de Global stdiag<first 2 letters of subscription

diagnóstico) name and number><region><###>
stdiagsh001eastus2001
stdiagsh001westus001
Azure StorSimple Global ssimp<app name>-<environment>
ssimpnavigatorprod
ssimpemissionsdev
Azure Container Registr y Global acr<app name><environment>

<###>
acrnavigatorprod001
Nombres de ejemplo: AI y aprendizaje automático

Azure Cognitive Search Global srch-<app name>-<environment>
srch-navigator-prod
srch-emissions-dev
Azure Cognitive Ser vices Resource group cog-<app name>-<environment>
cog-navigator-prod
cog-emissions-dev
área de trabajo de Azure Machine Resource group mlw-<app name>-<environment>

Learning
mlw-navigator-prod
mlw-emissions-dev
Nombres de ejemplo: Analytics e IoT

Azure Data Factor y Global adf-<app name><environment>
adf-navigator-prod
adf-emissions-dev
Azure Stream Analytics Resource group asa-<app name>-<environment>
asa-navigator-prod
asa-emissions-dev
Cuenta de Data Lake Analytics Global dla<app name><environment>
dlanavigatorprod
dlanavigatorprod
Cuenta de Data Lake Storage Global dls<app name><environment>
dlsnavigatorprod
dlsemissionsdev
Centro de eventos Global evh-<app name>-<environment>
evh-navigator-prod
evh-emissions-dev
Clúster de HDInsight (HBase) Global hbase-<app name>-<environment>
hbase-navigator-prod
hbase-emissions-dev
Clúster de HDInsight (Hadoop) Global hadoop-<app name>-<environment>
hadoop-navigator-prod
hadoop-emissions-dev
Clúster de HDInsight (Spark) Global spark-<app name>-<environment>
spark-navigator-prod
spark-emissions-dev
centro de IoT Global iot-<app name>-<environment>
iot-navigator-prod
iot-emissions-dev
¿Qué es Power BI Embedded de Global pbi-<app name>-<environment>

Azure?
pbi-navigator-prod
pbi-emissions-dev
Nombres de ejemplo: Integración

Ser vice Bus Global sb-<app name>-

<environment>.servicebus.windows.ne
t
sb-navigator-prod
sb-emissions-dev
Cola de Ser vice Bus Azure Service Bus sbq-<query descriptor>
sbq-messagequery
Tema de Ser vice Bus Azure Service Bus sbt-<query descriptor>
sbt-messagequery
Pasos siguientes
Revise las abreviaturas recomendadas que se usarán para los diversos tipos de recursos de Azure al asignar
nombres a los recursos.
Abreviaturas recomendadas para los tipos de recursos de Azure
Abreviaturas recomendadas para los tipos de
recursos de Azure
Las cargas de trabajo de Azure suelen estar compuestas de varios recursos y servicios. Incluir un componente
de nomenclatura en los nombres de los recursos que represente el tipo de recurso de Azure hace que sea más
fácil reconocer visualmente los componentes de aplicaciones o servicios.
En esta lista se proporcionan las abreviaturas recomendadas de los diversos tipos de recursos de Azure que se
deben incluir en las convenciones de nomenclatura. Estas abreviaturas suelen usarse como prefijos en los
nombres de los recursos, por lo que cada abreviatura que se muestra a continuación va seguida de un guion ( -
), excepto en los tipos de recursos que no permiten guiones en el nombre del mismo. La convención de
nomenclatura permite colocar la abreviatura del tipo de recurso en un lugar diferente del nombre si esto resulta
más adecuado para las necesidades de su organización.
General
ESPA C IO DE N O M B RES DEL
T IP O DE REC URSO P RO VEEDO R DE REC URSO S O EN T IDA D A B REVIAT URA
Instancia del servicio API Management Microsoft.ApiManagement/service apim-
Identidad administrada Microsoft.ManagedIdentity/userAssignedIdentities

id-
Grupo de administración Microsoft.Management/managementGroups mg-
Definición de directiva Microsoft.Authorization/policyDefinitions

policy-
Resource group Microsoft.Resources/resourceGroups rg-
Redes
puerta de enlace de aplicaciones Microsoft.Network/applicationGateways agw-
Grupo de seguridad de aplicaciones Microsoft.Network/applicationSecurityGroups

asg-
(ASG)
Bastion Microsoft.Network/bastionHosts bas-
Perfil de CDN Microsoft.Cdn/profiles cdnp-
Punto de conexión de CDN Microsoft.Cdn/profiles/endpoints cdne-
Conexiones Microsoft.Network/connections con-

DNS Microsoft.Network/dnsZones dnsz-
Zona DNS Microsoft.Network/privateDnsZones pdnsz-
Firewall Microsoft.Network/azureFirewalls afw-
Circuito ExpressRoute Microsoft.Network/expressRouteCircuits erc-
Instancia de Front Door Microsoft.Network/frontDoors fd-
Directiva de firewall de Front Door Microsoft.Network/frontdoorWebApplicationFirewallPolicies

fdfp-
Equilibrador de carga (interno) Microsoft.Network/loadBalancers lbi-
Equilibrador de carga (externo) Microsoft.Network/loadBalancers lbe-
Regla de equilibrador de carga Microsoft.Network/loadBalancers/inboundNatRules

rule-
Puerta de enlace de red local Microsoft.Network/localNetworkGateways lgw-
Tarjeta de interfaz de red (NIC) Microsoft.Network/networkInterfaces nic-
Grupo de seguridad de red (NSG) Microsoft.Network/networkSecurityGroupsn sg-
Reglas de seguridad del grupo de Microsoft.Network/networkSecurityGroups/securityRules

nsgsr-
seguridad de red
Network Watcher Microsoft.Network/networkWatchers nw-
Private Link "Microsoft.Network/privateLinkServices pl-
Dirección IP pública Microsoft.Network/publicIPAddresses pip-
Prefijo de dirección IP pública Microsoft.Network/publicIPPrefixes ippre-
Filtro de ruta Microsoft.Network/routeFilters rf-
Tabla de rutas Microsoft.Network/routeTables rt-
Punto de conexión de servicio Microsoft.serviceEndPointPolicies se-
Perfil de Traffic Manager Microsoft.Network/trafficManagerProfiles

traf-
Ruta definida por el usuario (UDR) Microsoft.Network/routeTables/routes udr-
Virtual network Microsoft.Network/virtualNetworks vnet-

Emparejamiento de redes virtuales de Microsoft.Network/virtualNetworks/virtualNetworkPeerings

peer-
Azure
Subred de red virtual Microsoft.Network/virtualNetworks/subnets

snet-
Red WAN virtual Microsoft.Network/virtualWans vwan-
VPN Gateway Microsoft.Network/vpnGateways vpng-
Conexión VPN Microsoft.Network/vpnGateways/vpnConnections

cn-
Sitio VPN Microsoft.Network/vpnGateways/vpnSites st-
Puerta de enlace de red virtual Microsoft.Network/virtualNetworkGateways

vgw-
Directiva de firewall de aplicaciones Microsoft.Network/firewallPolicies waf

web
Grupo de reglas de la directiva del Microsoft.Network/firewallPolicies/ruleGroups

wafrg
firewall de aplicaciones web
Procesos y web
App Service Environment Microsoft.Web/sites ase-
Plan de App Service Microsoft.Web/serverFarms plan-
Conjunto de disponibilidad Microsoft.Compute/availabilitySets avail-
Servidor habilitado para Azure Arc Microsoft.HybridCompute/machines arcs-
Clúster de Kubernetes habilitado para Microsoft.Kubernetes/connectedClusters arck

Azure Arc
servicio en la nube Microsoft.Compute/cloudServices cld-
Conjunto de cifrado de disco Microsoft.Compute/diskEncryptionSets des
Aplicación de funciones Microsoft.Web/sites func-
Galería Microsoft.Compute/galleries gal
Disco administrado (SO) Microsoft.Compute/disks osdisk
Disco administrado (datos) Microsoft.Compute/disks disk

Notification Hubs Microsoft.NotificationHubs/namespaces/notificationHubs

ntf-
Espacio de nombres de Notification Microsoft.NotificationHubs/namespaces ntfns-

Hubs
Instantánea Microsoft.Compute/snapshots snap-
Aplicación web estática Microsoft.Web/sites stapp
Máquina virtual Microsoft.Compute/virtualMachines vm
Conjunto de escalado de máquina Microsoft.Compute/virtualMachineScaleSets

vmss-
virtual
Cuenta de almacenamiento de Microsoft.Storage/storageAccounts stvm

máquina virtual
Aplicación web Microsoft.Web/sites app-
Contenedores
Clúster de AKS Microsoft.ContainerService/managedClusters

aks-
Registro de contenedor Microsoft.ContainerRegistry/registries cr
Instancia de contenedor Microsoft.ContainerInstance/containerGroups

ci
Clúster de Service Fabric Microsoft.ServiceFabric/clusters sf-
Bases de datos
Base de datos de Azure Cosmos DB Microsoft.DocumentDB/databaseAccounts/sqlDatabases

cosmos-
Instancia de Azure Cache for Redis Microsoft.Cache/Redis redis-
Servidor de Azure SQL Database Microsoft.Sql/servers sql-
Azure SQL Database Microsoft.Sql/servers/databases sqldb-
Azure Synapse Analytics Microsoft.Synapse/workspaces syn-

Áreas de trabajo de Azure Synapse Microsoft.Synapse/workspaces syn-

Analytics
Grupo dedicado de SQL de Azure Microsoft.Synapse/workspaces/sqlPools syndw-

Synapse Analytics
Grupo de Spark para Azure Synapse Microsoft.Synapse/workspaces/sqlPools synspark-

Analytics
Base de datos MySQL Microsoft.DBforMySQL/servers mysql-
Base de datos PostgreSQL Microsoft.DBforPostgreSQL/servers psql-
SQL Server Stretch Database Microsoft.Sql/servers/databases sqlstrdb-
Instancia administrada de SQL Microsoft.Sql/managedInstances sqlmi-
Storage
Cuenta de almacenamiento Microsoft.Storage/storageAccounts st
Azure StorSimple Microsoft.StorSimple/managers ssimp
IA y Machine Learning
Azure Cognitive Search Microsoft.Search/searchServices srch-
Azure Cognitive Services Microsoft.CognitiveServices/accounts cog-
Área de trabajo de Azure Machine Microsoft.MachineLearningServices/workspaces

mlw-
Learning
Analytics e IoT
Servidor de Azure Analysis Services Microsoft.AnalysisServices/servers as
Área de trabajo de Azure Databricks Microsoft.Databricks/workspaces dbw-
Azure Stream Analytics Microsoft.StreamAnalytics/cluster asa-

Clúster de Azure Data Explorer Microsoft.Kusto/clusters dec
Base de datos del clúster de Azure Microsoft.Kusto/clusters/databases dedb

Data Explorer
Azure Data Factory Microsoft.DataFactory/factories adf-
Cuenta de Data Lake Store Microsoft.DataLakeStore/accounts dls
Cuenta de Data Lake Analytics Microsoft.DataLakeAnalytics/accounts dla
Espacio de nombres de Event Hubs Microsoft.EventHub/namespaces evhns-
Centro de eventos Microsoft.EventHub evh-

namespaces/eventHubs
Dominio de Event Grid Microsoft.EventGrid/domains evgd-
Tema de Event Grid Microsoft.EventGrid/domains/topics evgt-
Clúster de HDInsight (Hadoop) Microsoft.HDInsight/clusters hadoop-
Clúster de HDInsight (HBase) Microsoft.HDInsight/clusters hbase-
Clúster de HDInsight (Kafka) Microsoft.HDInsight/clusters kafka-
Clúster de HDInsight (Spark) Microsoft.HDInsight/clusters spark-
Clúster de HDInsight (Storm) Microsoft.HDInsight/clusters storm-
Clúster de HDInsight (Machine Microsoft.HDInsight/clusters mls-

Learning Services)
centro de IoT Microsoft.Devices/IotHubs iot-
Aprovisionamiento de servicios Microsoft.Devices/provisioningServices provs-
Aprovisionamiento del certificado de Microsoft.Devices/provisioningServices/certificates

pcert-
servicios
Power BI Embedded Microsoft.PowerBIDedicated/capacities pbi-
Entorno de Time Series Insights Microsoft.TimeSeriesInsights/environments

tsi-
Herramientas para desarrolladores

Almacén de App Configuration Microsoft.AppConfiguration/configurationStores

appcs-
Azure Static Web Apps Microsoft.Web/sites stap-
SignalR Microsoft.SignalRService/SignalR sigr
Integración
cuenta de integración Microsoft.Logic/integrationAccounts ia-
Aplicaciones lógicas Microsoft.Logic/workflows logic-
Azure Service Bus Microsoft.ServiceBus/namespaces sb-
Cola de Service Bus Microsoft.ServiceBus/namespaces/queues sbq-
Tema de Service Bus Microsoft.ServiceBus/namespaces/topics sbt-
Administración y gobernanza
Cuenta de Automation Microsoft.Automation/automationAccountsa a-
Application Insights Microsoft.Insights/components appi-
Grupo de acciones de Azure Monitor Microsoft.Insights/actionGroups ag-
Instancia de Azure Purview Microsoft.Purview/accounts pview-
Plano técnico Microsoft.Blueprint/blueprints bp-
Asignación de plano técnico Microsoft.Blueprint/blueprints/artifacts

bpa-
Almacén de claves Microsoft.KeyVault/vaults kv-
Área de trabajo de Log Analytics Microsoft.OperationalInsights/workspaces

log-
Migración
Proyecto de Azure Migrate Microsoft.Migrate/assessmentProjects migr-
Instancia de Database Migration Microsoft.DataMigration/services dms-

Service
Almacén de Recovery Services Microsoft.RecoveryServices/vaults rsv-
Nombres de productos en desuso

Azure SQL Data Warehouse Microsoft.Sql/servers sqldw-
Pasos siguientes
Revise las recomendaciones para etiquetar los recursos de Azure.
Al aplicar etiquetas de metadatos a los recursos en la nube, puede incluir información sobre esos recursos que
no se pudo incluir en el nombre del recurso. Puede usar esa información para realizar filtrados e informes más
elaborados sobre los recursos. Quiere que estas etiquetas incluyan contexto sobre la carga de trabajo o la
aplicación asociadas del recurso, los requisitos operativos y la información de propiedad. Esta información la
pueden usar los equipos de TI o empresariales para encontrar recursos o generar informes sobre el uso y la
facturación de los recursos.
Las etiquetas que se aplican a los recursos y las etiquetas que son necesarias u opcionales varían según la
organización. En la lista siguiente se proporcionan ejemplos de etiquetas comunes que capturan contexto e
información importantes sobre un recurso. Use esta lista como punto de partida para establecer sus propias
convenciones de etiquetado.
Etiquetas mínimas sugeridas

Las siguientes etiquetas le guiarán en la implementación y los procesos de todas las metodologías de Cloud
Adoption Framework posteriores. Muchos de los procedimientos recomendados en esas metodologías
muestran la automatización de las operaciones en la nube y la gobernanza basada en las siguientes etiquetas.
N O M B RE DE ET IQ UETA DESC RIP C IÓ N VA LO RES DE C L AVE Y DE E JEM P LO
Nombre de la carga de trabajo Nombre de la carga de trabajo que WorkloadName

admite el recurso.
ControlCharts
Clasificación de datos Confidencialidad de los datos que DataClassification

hospeda este recurso.
Non-business
Public
General
Confidential
Highly confidential
Crucial para la empresa Impacto empresarial del recurso o de Grado de importancia

la carga de trabajo admitida.
Low
Medium
High
Business unit-critical
Mission-critical
Unidad de negocio División de nivel superior de la BusinessUnit

empresa que posee la suscripción o la
carga de trabajo a la que pertenece el Finance
recurso. En organizaciones más Marketing
pequeñas, esta etiqueta puede Product XYZ
representar un solo elemento Corp
organizativo de nivel superior Shared
corporativo o compartido.
Compromiso con las operaciones Nivel de soporte técnico para las OpsCommitment
operaciones que se proporciona para
esta carga de trabajo o recurso. Baseline only
Enhanced baseline
Platform operations
Workload operations
Equipo de operaciones Equipo responsable de las operaciones OpsTeam

cotidianas.
Central IT
Cloud operations
ControlCharts team
MSP-{Managed Service Provider

name}
Ejemplos de etiquetas comunes adicionales

A continuación se muestran una serie de etiquetas que se suelen usar en Azure para aumentar la visibilidad
sobre el uso de los recursos de Azure.
Nombre de la aplicación Se ha agregado granularidad cuando la ApplicationName

carga de trabajo se subdivide en varias
aplicaciones o servicios. IssueTrackingSystem
Nombre del aprobador Persona responsable de la aprobación Approver

de los costos relacionados con este
recurso. [email protected]
Presupuesto requerido o Dinero asignado para esta aplicación, BudgetAmount

aprobado servicio o carga de trabajo.
$200,000
Centro de costos Centro de costo de contabilidad CostCenter

asociado a este recurso.
55332
Recuperación ante desastres Importancia empresarial de la DR

aplicación, la carga de trabajo o el
servicio. Mission-critical
Critical
Essential
Fecha de finalización del proyecto Fecha en la que la aplicación, la carga EndDate

de trabajo o el servicio están
programados para su retirada. 2023-10-15
Entorno Entorno de implementación de la Env

aplicación, la carga de trabajo o el
servicio. Prod
Dev
QA
Stage
Test
Nombre del propietario Propietario de la aplicación, la carga de Propietario

trabajo o el servicio.
[email protected]
Nombre del solicitante Usuario que solicitó la creación de esta Solicitante

aplicación.
[email protected]
Clase de ser vicio Nivel de contrato de nivel de servicio ServiceClass

de la aplicación, la carga de trabajo o el
servicio. Dev
Bronze
Silver
Gold
Fecha de inicio del proyecto Fecha en que se implementó por StartDate

primera vez la aplicación, la carga de
trabajo o el servicio. 2020-10-15
Realizar acción
Revise la Guía de decisiones de nomenclatura y etiquetado de recursos.
Pasos siguientes
Aprenda a migrar recursos y grupos de recursos entre suscripciones de Azure.
Traslado de recursos y grupos de recursos entre suscripciones
Centro de datos virtual: Una perspectiva de la red
Las aplicaciones que se migren desde el entorno local se beneficiarán de la infraestructura segura y rentable de
Azure, incluso con cambios mínimos en las aplicaciones. Aun así, las empresas deben adaptar sus arquitecturas
para mejorar la agilidad y aprovechar las funcionalidades de Azure.
Microsoft Azure ofrece servicios y una infraestructura a gran escala con funcionalidades y confiabilidad de nivel
empresarial. Estos servicios y esta infraestructura ofrecen muchas opciones de conectividad híbrida, así que los
clientes pueden elegir acceder a ellos a través de Internet, o bien a través de una conexión de red privada. Los
partners de Microsoft también pueden proporcionar funcionalidades mejoradas al ofrecer servicios de
seguridad y aplicaciones virtuales optimizados para su ejecución en Azure.
Los clientes pueden usar Azure para ampliar su infraestructura a la nube sin problemas y crear arquitecturas de
varios niveles.
¿Qué es un centro de datos virtual?

La nube comenzó como plataforma para hospedar aplicaciones orientadas al público. Las empresas
reconocieron el valor de la nube y comenzaron a migrar las aplicaciones de línea de negocio internas. Estas
aplicaciones trajeron factores adicionales de seguridad, confiabilidad, rendimiento y costo que requerían mayor
flexibilidad al prestar servicios en la nube. La nueva infraestructura y los nuevos servicios de red se diseñaron
para proporcionar dicha flexibilidad, y las nuevas características ofrecieron escalabilidad elástica, recuperación
ante desastres y otros factores.
En un principio, las soluciones en la nube se diseñaron para hospedar aplicaciones únicas y relativamente
aisladas en el espectro público. Este método funcionó bien unos años. A medida que las ventajas de las
soluciones en la nube se hicieron obvias, muchas cargas de trabajo a gran escala se hospedaron en la nube. Dar
respuesta a los problemas de seguridad, confiabilidad, rendimiento y costo de las implementaciones de una o
varias regiones resultó ser vital a lo largo del ciclo de vida del servicio en la nube.
En el ejemplo de diagrama de implementación en la nube a continuación, el cuadro rojo resalta una brecha de
seguridad. El recuadro amarillo muestra una oportunidad para optimizar las aplicaciones virtuales de red en las
cargas de trabajo.
Los centros de datos virtuales ayudan a lograr la escala necesaria para las cargas de trabajo empresariales. Esta
escala debe abordar los desafíos presentados al ejecutar aplicaciones a gran escala en la nube pública.
Una implementación de centro de datos virtual (VDC) incluye más que las cargas de trabajo de aplicación en la
nube. También proporciona la red, la seguridad, la administración y otras infraestructuras, como servicios de
DNS y Active Directory. A medida que las empresas migran cargas de trabajo adicionales a Azure, tenga en
cuenta la infraestructura y los objetos que admiten estas cargas de trabajo. Estructurar detenidamente los
recursos ayuda a evitar la proliferación de cientos de "islas de cargas de trabajo" administradas por separado,
con flujos de datos, modelos de seguridad y desafíos de cumplimiento independientes.
El concepto de centro de datos virtual proporciona recomendaciones y diseños de alto nivel para implementar
una colección de entidades independientes, pero relacionadas. A menudo, estas entidades tienen funciones
auxiliares, características e infraestructura comunes. Ver las cargas de trabajo como un centro de datos virtual
ayuda a lograr menores costos debido a las economías de escala, a optimizar la seguridad gracias a la
centralización de los componentes y flujos de datos, además de lograr más facilidad en las operaciones, en la
administración y en las auditorías de cumplimiento.
NOTE
Un centro de datos virtual no es un servicio específico de Azure. En su lugar, se combinan varias características y
funcionalidades de Azure para satisfacer sus necesidades. Un centro de datos virtual es una forma de pensar en sus
cargas de trabajo y en el uso de Azure para optimizar los recursos y funcionalidades en la nube. Ofrece un enfoque
modular para la prestación de servicios de TI en Azure, al mismo tiempo que se respetan los roles y responsabilidades
organizativos de la empresa.
Un centro de datos virtual ayuda a las empresas a implementar cargas de trabajo y aplicaciones en Azure en los
siguientes escenarios:
Hospedaje de varias cargas de trabajo relacionadas.
Migración de cargas de trabajo desde un entorno local a Azure.
Implementación de requisitos de seguridad y acceso compartido o centralizado para las cargas de trabajo.
Combinación de DevOps y TI centralizada adecuada para una gran empresa.
¿Quién debe implementar un centro de datos virtual?
Todos los clientes que hayan decidido adoptar Azure pueden beneficiarse de la eficacia de configurar un
conjunto de recursos que pueden usar todas las aplicaciones. Dependiendo del tamaño, hasta las aplicaciones
individuales pueden beneficiarse del uso de los patrones y componentes que se utilizan para crear una
implementación de un centro de datos virtual.
Algunas organizaciones tienen equipos o departamentos centralizados para TI, redes, seguridad o cumplimiento
normativo. La implementación de un centro de datos virtual puede ayudar a imponer puntos de directiva,
responsabilidades independientes y garantizar la coherencia de los componentes comunes subyacentes. Los
equipos de aplicaciones pueden mantener la libertad y el control adecuados para sus requisitos.
Las organizaciones con un enfoque de DevOps también pueden usar los conceptos del centro de datos virtual
para proporcionar paquetes autorizados de recursos de Azure. Este método puede garantizar que los grupos de
DevOps tengan control total dentro de esa agrupación, ya sea a nivel de la suscripción o en los grupos de
recursos de una suscripción común. Al mismo tiempo, los límites de red y de seguridad se mantienen en
cumplimiento, según lo definido por una directiva centralizada en la red del centro y en el grupo de recursos
administrado de manera centralizada.
Consideraciones para la implementación de un centro de datos virtual

Al diseñar un centro de datos virtual, tenga en cuenta los siguientes asuntos centrales:
Servicios de identidad y directorio
Los servicios de identidad y directorio son funcionalidades clave de los centros de datos tanto locales como en
la nube. La identidad cubre todos los aspectos del acceso y autorización a los servicios de una implementación
del centro de datos virtual. Para garantizar que solo los usuarios y procesos autorizados tengan acceso a los
recursos de Azure, Azure usa varios tipos de credenciales para la autenticación, incluidas contraseñas de
cuentas, claves criptográficas, firmas digitales y certificados. Azure Multi-Factor Authentication proporciona una
capa adicional de seguridad para acceder a los servicios de Azure mediante una autenticación sólida, gracias a
su variedad de opciones de verificación sencillas (notificación mediante llamada telefónica, mensaje de texto o
aplicación móvil) que permite a los clientes elegir el método que prefieran.
Cualquier empresa de gran tamaño precisa definir un proceso de administración de identidad que describa la
administración de identidades individuales, su autenticación, autorización, roles y privilegios dentro de su centro
de datos virtual. Los objetivos de este proceso deben ser mejorar la seguridad y productividad al reducir los
costos, el tiempo de inactividad y las tareas manuales repetitivas.
Las organizaciones empresariales pueden requerir una combinación exigente de servicios para las diferentes
líneas de negocio y los empleados a menudo tienen distintos roles cuando están implicados en proyectos
diferentes. Un centro de datos virtual requiere buena cooperación entre distintos equipos, cada uno con
definiciones de rol específicas, para tener una buena gobernanza de los sistemas en ejecución. La matriz de
responsabilidades, acceso y derechos puede ser compleja. La administración de identidades en el centro de
datos virtual se implementa mediante Azure Active Directory (Azure AD) y el control de acceso basado en roles
de Azure (RBAC de Azure).
Un servicio de directorio es una infraestructura de información compartida para buscar, gestionar, administrar y
organizar los elementos cotidianos y los recursos de red. Estos recursos pueden incluir volúmenes, carpetas,
archivos, impresoras, usuarios, grupos, dispositivos y otros objetos. El servidor de directorio considera cada
recurso de la red como un objeto. La información sobre un recurso se almacena como una colección de
atributos asociada a ese recurso u objeto.
Todos los servicios de negocio en línea de Microsoft dependen de Azure Active Directory (Azure AD) para el
inicio de sesión y otras necesidades de identidad. Azure Active Directory es solución en la nube de
administración de acceso e identidades completa y de alta disponibilidad que combina una administración de
acceso a aplicaciones, gobernanza de identidades avanzada y servicios de directorio fundamentales. Azure AD
se puede integrar con Active Directory local a fin de habilitar el inicio de sesión único para todas las aplicaciones
basadas en la nube y hospedadas localmente. Los atributos de usuario de Active Directory local se pueden
sincronizar automáticamente con Azure AD.
No es necesario que un administrador global único asigne todos los permisos en una implementación de VDC.
En su lugar, cada departamento o grupo de usuarios o servicios específico del servicio de directorio puede tener
los permisos necesarios para administrar sus propios recursos dentro de una implementación del centro de
datos virtual. La estructura de permisos requiere un equilibrio. Demasiados permisos pueden disminuir el
rendimiento y muy pocos permisos o permisos flexibles pueden aumentar los riesgos de seguridad. El control
de acceso basado en roles de Azure (RBAC de Azure) le ayuda a abordar este problema, ya que ofrece una
administración detallada del acceso a los recursos de una implementación de un centro de datos virtual.
Infraestructura de seguridad
Por infraestructura de seguridad se entiende la segregación del tráfico del segmento de red virtual específico de
una implementación de un centro de datos virtual. Esta infraestructura especifica cómo se controlan la entrada y
la salida en la implementación de un centro de datos virtual. Azure se basa en una arquitectura multiinquilino
que impide el tráfico no autorizado e involuntario entre implementaciones mediante el uso del aislamiento de
redes virtuales, las listas de control de acceso, los equilibradores de carga, los filtros de direcciones IP y las
directivas de flujo de tráfico. La traducción de direcciones de red (NAT) se usa para separar el tráfico de red
interno del tráfico externo.
El tejido de Azure asigna recursos de infraestructura para las cargas de trabajo del inquilino y administra las
comunicaciones a y desde las máquinas virtuales (VM). El hipervisor de Azure fuerza la separación de la
memoria y el proceso entre las máquinas virtuales y enruta de forma segura el tráfico de red a los SO invitado
de cada inquilino.
Conectividad a la nube
Un centro de datos virtual necesita conectividad con redes externas para ofrecer servicios a los clientes, partners
y usuarios internos. Esta necesidad de conectividad no solo sucede en Internet, sino en las redes y centros de
datos locales.
Los clientes controlan qué servicios pueden acceder a Internet pública y a qué servicios se puede acceder desde
Internet pública. Este acceso se controla mediante Azure Firewall o cualquier otro tipo de aplicaciones de red
virtual (NVA), directivas de enrutamiento personalizadas mediante rutas definidas por el usuario y filtrado de
redes mediante grupos de seguridad de red. Se recomienda que todos los recursos a los que se pueda acceder
desde Internet estén también protegidos por el estándar Azure DDoS Protection.
Es posible que las empresas necesiten conectar su centro de datos virtual a centros de datos locales u otros
recursos. Esta conectividad entre las redes de Azure y las locales es un aspecto fundamental del diseño de una
arquitectura eficaz. Las empresas tienen dos formas distintas de crear esta interconexión: pasar por Internet o
mediante conexiones directas privadas.
Una VPN de sitio a sitio de Azure conecta las redes locales a su centro de datos virtual en Azure. El vínculo se
establece mediante conexiones cifradas seguras (túneles IPsec). Las conexiones VPN de sitio a sitio de Azure son
flexibles, rápidas de crear y, por lo general, no requieren ninguna adquisición de hardware adicional. En función
de los protocolos estándar del sector, la mayoría de los dispositivos de red actuales pueden crear conexiones
VPN a Azure a través de Internet o de rutas de conectividad existentes.
ExpressRoute habilita las conexiones privadas entre el centro de datos virtual y las redes locales. Las conexiones
ExpressRoute no se realizan sobre una conexión a Internet pública, ofrecen una mayor confiabilidad, seguridad y
velocidades mayores (hasta 100 Gbps) con una latencia menor. ExpressRoute proporciona las ventajas de las
reglas de cumplimiento asociadas a las conexiones privadas. Con ExpressRoute Direct puede conectarse
directamente a los enrutadores de Microsoft a 10 o 100 Gbps.
La implementación de conexiones ExpressRoute implica normalmente tomar contacto con un proveedor de
servicios de ExpressRoute (donde ExpressRoute Direct es la excepción). Para clientes que necesitan comenzar
rápidamente, es habitual usar inicialmente una VPN de sitio a sitio para establecer la conectividad entre el
centro de datos virtual y los recursos locales. Una vez que se complete la interconexión física con su proveedor
de servicios, migre la conectividad a su conexión de ExpressRoute.
Para muchas conexiones VPN o de ExpressRoute, Azure Virtual WAN es un servicio de red que ofrece
conectividad automatizada y optimizada entre ramas mediante Azure. Virtual WAN permite conectar y
configurar los dispositivos de rama para comunicarse con Azure. La conexión y configuración se pueden realizar
manualmente o mediante los dispositivos de proveedores preferidos mediante un partner de Virtual WAN. El
uso de dispositivos de proveedores preferidos permite la administración de la configuración, facilita el uso y
simplifica la conectividad. El panel integrado de Azure WAN proporciona información instantánea para
solucionar problemas que puede ayudarle a ahorrar tiempo y le ofrece una manera fácil de ver la conectividad
de sitio a sitio y a gran escala. Virtual WAN también proporciona servicios de seguridad con una instancia
opcional de Azure Firewall y Firewall Manager en su centro de Virtual WAN.
Conectividad dentro de la nube
Las instancias de Azure Virtual Network y el emparejamiento de redes virtuales son los componentes básicos de
conexión en red de un centro de datos virtual. Una red virtual garantiza un límite de aislamiento para los
recursos del centro de datos virtual. El emparejamiento permite la intercomunicación entre distintas redes
virtuales dentro de la misma región de Azure, entre regiones e, incluso, entre redes en distintas suscripciones.
Tanto dentro como entre redes virtuales, los flujos de tráfico pueden controlarse mediante conjuntos de reglas
de seguridad especificadas en grupos de seguridad de red, directivas de firewall (Azure Firewall o aplicaciones
virtuales de red) y rutas personalizadas definidas por el usuario.
Las redes virtuales también son puntos de anclaje para la integración de productos de Azure de plataforma
como servicio (PaaS), como Azure Storage, Azure SQL y otros servicios públicos integrados que tienen puntos
de conexión públicos. Con puntos de conexión de servicio y Azure Private Link, puede integrar sus servicios
públicos con la red privada. Incluso puede convertir en privados sus servicios públicos, pero disfrutar de las
ventajas de los servicios PaaS administrados por Azure.
Introducción al centro de datos virtual

Topologías
Un centro de datos virtual se puede crear con una de estas topologías de alto nivel, según sus necesidades y
requisitos de escala:
En una topología plana, todos los recursos se implementan en una única red virtual. Las subredes permiten el
control y la segregación del flujo.
En una topología de malla, el emparejamiento de red virtual conecta todas las redes virtuales directamente
entre sí.
Una topología de emparejamiento de tipo hub-and-spoke es adecuada para aplicaciones distribuidas y equipos
con responsabilidades delegadas.
Una topología de Azure Virtual WAN puede admitir escenarios de sucursales a gran escala y servicios WAN
globales.
La topología de emparejamiento en estrella tipo hub-and-spoke y la topología de Azure Virtual WAN usan
ambas un diseño de estrella tipo hub-and-spoke, que es óptima para la comunicación, los recursos compartidos
y la directiva de seguridad centralizada. Los centros se crean mediante un centro de emparejamiento de red
virtual (etiquetado como Hub Virtual Network en el diagrama) o un centro de Virtual WAN (etiquetado como
Azure Virtual WAN en el diagrama). Azure Virtual WAN está diseñada para comunicaciones de rama a rama y de
rama a Azure a gran escala, o para evitar las complejidades de la creación de todos los componentes de forma
individual en un centro de emparejamiento de red virtual. En algunos casos, es posible que sus requisitos exijan
un diseño de centro de emparejamiento de red virtual, como la necesidad de aplicaciones virtuales de red en el
centro.
En ambas topologías de hub-and-spoke, el centro (hub) es la zona de red central que controla e inspecciona
todo el tráfico entre las diferentes zonas: Internet, local y los radios (spokes). La topología de hub-and-spoke
ayuda al Departamento de TI a aplicar directivas de seguridad de forma centralizada. También reduce la
posibilidad de exposición y de configuración incorrecta.
El centro a menudo contiene los componentes de los servicios comunes que consumen los radios. Los ejemplos
siguientes son servicios centrales comunes:
La infraestructura de Active Directory de Windows necesaria para la autenticación de usuarios de terceros
que acceden desde redes que no son de confianza antes de obtener acceso a las cargas de trabajo del radio
(spoke). Incluye los Servicios de federación de Active Directory (AD FS) relacionados.
Un servicio de Sistema de nombres de dominio (DNS) que resuelve los nombres de la carga de trabajo en
los radios para acceder a recursos locales y en Internet si no se utiliza Azure DNS.
Una infraestructura de clave pública (PKI), para implementar el inicio de sesión único en las cargas de trabajo.
Control de flujo de tráfico TCP y UDP entre las zonas de red de los radios (spokes) e Internet.
Control de flujo entre los radios (spokes) y local.
Si es necesario, control de flujo entre un radio y otro.
Un centro de datos virtual reduce el costo total, ya que utiliza la infraestructura del centro compartida entre
varios radios.
El rol de cada radio puede ser el hospedaje de diferentes tipos de cargas de trabajo. Los radios (spokes) también
proporcionan un enfoque modular para implementaciones repetibles de las mismas cargas de trabajo. Entre los
ejemplos se incluyen el desarrollo y las pruebas, las pruebas de aceptación de usuario, la preproducción y la
producción. Los radios también pueden segregar y habilitar varios grupos dentro de su organización. Por
ejemplo, los grupos de DevOps. Dentro de un radio, es posible implementar una carga de trabajo básica o
cargas de trabajo de varios niveles complejas con control de tráfico entre los niveles.
Límites de la suscripción y múltiples concentradores
IMPORTANT
En función del tamaño de las implementaciones de Azure, es posible que se necesite una estrategia de varios centros. Al
diseñar la estrategia de hub-and-spoke, pregúntese: "¿puede este diseño escalarse para usar otra red virtual de centro en
esta región?", o bien "¿puede este diseño escalarse para aceptar varias regiones?". Es mucho mejor planear un diseño que
pueda escalarse y no lo necesite, a no planearlo y necesitarlo.
Cuándo escalar a un centro secundario (o más) dependerá de infinidad de factores, en general en función de límites
inherentes a la escala. Asegúrese de revisar los límites de la suscripción, de la red virtual y de las máquinas virtuales al
diseñar para el escalado.
En Azure, todos los componentes, de cualquier tipo, se implementan en una suscripción de Azure. El aislamiento
de componentes de Azure en distintas suscripciones de Azure puede satisfacer los requisitos de diferentes líneas
de negocio, como la configuración de niveles diferenciados de acceso y autorización.
Una implementación individual de un centro de datos virtual puede escalarse verticalmente a gran número de
radios, aunque, al igual que en todos los sistemas de TI, existen límites en las plataformas. La implementación
del centro se enlaza a una suscripción de Azure específica que tiene restricciones y límites (por ejemplo, un
número máximo de emparejamientos de red virtual. Para más información, consulte Límites, cuotas y
restricciones de suscripción y servicios de Azure). En los casos en los que los límites puedan ser un problema, la
arquitectura se puede escalar verticalmente más allá extiendo el modelo desde un único concentrador-radios a
un clúster de concentradores y radios. Se pueden conectar varios centros de una o más regiones de Azure
mediante el emparejamiento de red virtual, ExpressRoute, Virtual WAN o VPN de sitio a sitio.
La introducción de varios centros aumenta el costo y el esfuerzo de administración del sistema. Esto solo se
justifica por motivos de escalabilidad, límites del sistema, redundancia, replicación regional para el rendimiento
del usuario final o recuperación ante desastres. En escenarios que requieran múltiples concentradores, todos los
concentradores deben procurar ofrecer el mismo conjunto de servicios para facilitar la operativa.
Interconexión entre los radios
En un solo radio, o en un diseño de red plano, es posible implementar cargas de trabajo complejas en varios
niveles. Las configuraciones de varios niveles se pueden implementar utilizando subredes, una para cada nivel o
aplicación, en la misma red virtual. El control y filtrado del tráfico se realizan mediante grupos de seguridad de
red y rutas definidas por el usuario.
Un arquitecto podría querer implementar una carga de trabajo de varios niveles entre varias redes virtuales.
Con el emparejamiento de redes virtuales, los radios pueden conectarse a otros radios en el mismo centro o en
centros diferentes. Un ejemplo típico de este escenario es el caso en el que los servidores de procesamiento de
la aplicación están en un radio o red virtual. La base de datos se implementa en un radio o red virtual diferente.
En este caso, es fácil interconectar los radios con el emparejamiento de red virtual y así evitar el tránsito a través
del centro. Debe realizarse una meticulosa revisión tanto de la arquitectura como de la seguridad para
asegurarse de que, aunque se omita el centro, no se omiten puntos de seguridad o de auditoría importantes que
podrían existir solo en el centro.
Los radios también pueden estar conectados entre sí mediante un radio que actúa como concentrador. Este
método crea una jerarquía de dos niveles: el radio del nivel superior (nivel 0) se convierten en el concentrador
de radios inferiores (nivel 1) en la jerarquía. Los radios de una implementación de un centro de datos virtual
están obligados a reenviar el tráfico al centro principal, con el fin de que pueda llegar a su destino pasando por
la red local o Internet pública. Una arquitectura con dos niveles de centros de conectividad presenta un
enrutamiento complejo que anula las ventajas de una relación simple concentrador-radio.
Aunque Azure permite topologías complejas, uno de los principios básicos del concepto de centro de datos
virtual es la repetibilidad y simplicidad. Para minimizar el esfuerzo de administración, el diseño simple en
estrella tipo hub-and-spoke es la arquitectura de referencia recomendada para un centro de datos virtual.
Componentes
El centro de datos virtual se compone de cuatro tipos de componentes básicos: Infraestructura , redes
perimetrales , cargas de trabajo y super visión .
Cada tipo de componente consta de varias características de Azure y recursos. La implementación del centro de
datos virtual se compone de instancias de varios tipos de componentes y múltiples variaciones del mismo tipo
de componente. Por ejemplo, puede tener muchas instancias de cargas de trabajo diferentes, separadas
lógicamente, que representan las distintas aplicaciones. Estos distintos tipos de componentes e instancias se
utilizan para crear el centro de datos virtual.
La arquitectura conceptual de alto nivel anterior del centro de datos virtual muestra distintos tipos de
componentes utilizados en distintas zonas de la topología en estrella tipo hub-and-spoke. El diagrama muestra
los componentes de la infraestructura en distintas partes de la arquitectura.
Como procedimiento recomendado en general, los derechos de acceso y privilegios deben estar basados en
grupos. Trabajar con grupos, en lugar de con usuarios individuales, facilita el mantenimiento de directivas de
acceso, ya que proporciona una manera coherente de administrarlo a en varios equipos y ayuda a reducir los
errores de configuración. Asignar y quitar usuarios de los grupos adecuados le ayuda a mantener actualizados
los privilegios de un usuario específico.
Cada grupo de roles debe tener un prefijo único en sus nombres. Este prefijo facilita una rápida identificación de
qué grupo está asociado con qué carga de trabajo. Por ejemplo, una carga de trabajo que hospeda un servicio
de autenticación podría tener grupos denominados AuthSer viceNetOps , AuthSer viceSecOps ,
AuthSer viceDevOps y AuthSer viceInfraOps . Los roles centralizados o los roles no relacionados con un
servicio concreto, podrían estar precedidos de Corp . Por ejemplo: CorpNetOps .
Muchas organizaciones usan una variación de los grupos siguientes para proporcionar un desglose mayor de
los roles:
El equipo de TI central llamado Corp tiene los derechos de propiedad para controlar los componentes de la
infraestructura. Ejemplos de redes y seguridad. El grupo debe tener el rol de colaborador en la suscripción, el
control del centro y derechos de colaborador de la red en los radios. Las grandes organizaciones suelen
dividir estas responsabilidades de administración entre varios equipos. Ejemplos: un grupo CorpNetOps de
operaciones de red con atención exclusiva a las redes, y un grupo CorpSecOps de operaciones de seguridad
responsable del firewall y la directiva de seguridad. En este caso específico, deben crearse dos grupos
diferentes para la asignación de estos roles personalizados.
El grupo de desarrollo y pruebas llamado AppDevOps tiene la responsabilidad de implementar las cargas
de trabajo de aplicaciones o servicios. Este grupo adopta el rol de colaborador de la máquina Virtual para las
implementaciones de IaaS y uno o varios roles de colaborador de PaaS. Para más información, consulte Roles
integrados en Azure. Opcionalmente, el equipo de desarrollo y pruebas podría necesitar tener visibilidad de
las directivas de seguridad (grupos de seguridad de red) y de las directivas de enrutamiento (rutas definidas
por el usuario) en el centro o en un radio concreto. Además de los roles de colaborador para las cargas de
trabajo, este grupo también necesitaría el rol de lector de red.
El grupo de operaciones y mantenimiento llamado CorpInfraOps o AppInfraOps tiene la responsabilidad
de administrar las cargas de trabajo en producción. Este grupo debe ser un colaborador de la suscripción en
las cargas de trabajo en las suscripciones de producción. Algunas organizaciones también pueden evaluar si
necesitan un grupo de equipo de soporte técnico con el rol de colaborador en la suscripción de producción y
en la suscripción del centro principal. El grupo adicional permite solucionar posibles problemas de
configuración en el entorno de producción.
El centro de datos virtual está diseñado de forma que los grupos creados para el equipo de TI central, que
administra el centro, tengan los grupos correspondientes en el nivel de carga de trabajo. Además de la
administración de los recursos del centro, el quipo de TI central puede controlar el acceso externo y los permisos
de nivel superior en la suscripción. Además, los grupos de cargas de trabajo pueden controlar los recursos y los
permisos de su red virtual con independencia del equipo TI central.
Las particiones de los centros de datos virtuales están creadas para que puedan hospedar de forma segura
varios proyectos en líneas de negocios (LOB) diferentes. Todos los proyectos requieren diferentes entornos
aislados (desarrollo, UAT y producción). El uso de suscripciones de Azure independientes para cada uno de estos
entornos puede proporcionar un aislamiento natural.
El diagrama anterior muestra la relación entre los proyectos de una organización, los usuarios, grupos y los
entornos donde se implementan los componentes de Azure.
Normalmente, en TI, un entorno (o nivel) es un sistema en el que se implementan y ejecutan varias aplicaciones.
Las empresas grandes usan un entorno de desarrollo (en el que se realizan y se prueban los cambios) y un
entorno de producción (el que utilizan los usuarios finales). Dichos entornos están separados y a menudo hay
varios entornos de ensayo entre ellos para permitir la implementación por fases (lanzamiento), la realización de
pruebas y la reversión si surgen problemas. Las arquitecturas de implementación varían considerablemente,
aunque normalmente siguen el proceso básico de comenzar en un desarrollo (DEV) y terminar en producción
(PROD).
Una arquitectura común para estos tipos de entornos de varios niveles consta de DevOps para el desarrollo y
las pruebas, UAT para el almacenamiento provisional y entornos de producción. Las organizaciones pueden usar
uno o varios inquilinos de Azure AD para definir el acceso y los derechos para estos entornos. El diagrama
anterior muestra un caso en el que se usan dos inquilinos diferentes de Azure AD: uno para DevOps y UAT y
otro exclusivamente para producción.
La presencia de inquilinos de Azure AD diferentes refuerza la separación entre entornos. El mismo grupo de
usuarios, como el equipo TI central, debe autenticarse con un URI diferente para obtener acceso a un inquilino
de Azure AD diferente y modificar los roles o permisos de los entornos de DevOps o de producción de un
proyecto. La presencia de una autenticación de usuario diferente para acceder a diferentes entornos reduce
posibles interrupciones y otros problemas causados por errores humanos.
Tipo de componente: Infraestructura
Este tipo de componente es en el que reside la mayor parte de la infraestructura de soporte. También es donde
los equipos de TI central, seguridad y cumplimiento dedican la mayor parte de su tiempo.
Los componentes de la infraestructura proporcionan una interconexión para los distintos componentes de una
implementación de un centro de datos virtual y están presentes tanto en el centro de conectividad como en los
radios. Normalmente se asigna la responsabilidad de administrar y mantener los componentes de
infraestructura al equipo de TI central o al de seguridad.
Una de las tareas principales del equipo de infraestructura de TI es garantizar la coherencia de los esquemas de
direcciones IP en toda la empresa. El espacio de direcciones IP privadas asignado a una implementación de un
centro de datos virtual debe ser coherente y NO superponerse con las direcciones IP privadas asignadas a las
redes locales.
Aunque el uso de NAT en los enrutadores locales perimetrales o en entornos de Azure puede evitar conflictos de
direcciones IP, agrega complicaciones a los componentes de infraestructura. La simplicidad de la administración
es uno de los principales objetivos del centro de datos virtual, por lo que el uso de NAT para controlar
cuestiones de direcciones IP, si bien es una solución válida, no es la recomendada.
Los componentes de infraestructura tienen la siguiente funcionalidad:
Servicios de identidad y de directorio. El acceso a cada tipo de recurso en Azure se controla mediante una
identidad que se almacena en un servicio de directorio. El servicio de directorio almacena no solo la lista de
usuarios, sino también los derechos de acceso a los recursos en una suscripción de Azure específica. Estos
servicios pueden existir solo en la nube, o se pueden sincronizar con la identidad local almacenada en Active
Directory.
Virtual Network. Las redes virtuales son uno de los componentes principales del centro de datos virtual y le
permiten crear un límite de aislamiento de tráfico en la plataforma de Azure. Una red virtual se compone de
uno o varios segmentos de red virtual, cada uno con un prefijo de red IP específico (una subred, ya sea IPv4
o doble pila IPv4/IPv6). La red virtual define un área de perímetro interno en el que las máquinas virtuales de
IaaS y los servicios de PaaS pueden establecer comunicaciones privadas. Las VM (y los servicios de PaaS) de
una red virtual no pueden comunicarse directamente con VM (y servicios de PaaS) de una red virtual
diferente, incluso si el mismo cliente ha creado ambas redes virtuales en la misma suscripción. El aislamiento
consiste en una propiedad fundamental que garantiza que las máquinas virtuales del cliente y la
comunicación sigan siendo privadas en una red virtual. Cuando se desee la conectividad entre redes, las
siguientes características describen cómo se puede lograr.
Emparejamiento de red virtual. La característica fundamental utilizada para crear la infraestructura de un
centro de datos virtual es el emparejamiento de red virtual, un mecanismo que conecta dos redes virtuales
de la misma región mediante la red del centro de datos de Azure o la red troncal mundial de Azure para
regiones distintas.
Puntos de conexión de servicio de red virtual. Los puntos de conexión del servicio amplían el espacio de
direcciones privadas de una red virtual para incluir el espacio de PaaS. También amplían la identidad de la
red virtual a los servicios de Azure a través de una conexión directa. Los puntos de conexión permiten
proteger los recursos de servicio de Azure críticos únicamente para las redes virtuales.
Private Link. Azure Private Link le permite acceder a los servicios PaaS de Azure (por ejemplo, Azure Storage,
Azure Cosmos DB y Azure SQL Database) y a los servicios de partners o clientes hospedados en Azure
mediante un punto de conexión privado de la red virtual. El tráfico entre la red virtual y el servicio atraviesa
la red troncal de Microsoft, eliminando la exposición a la red pública de Internet. También puede crear su
propio servicio Private Link en la red virtual y enviarlo de forma privada a los clientes. La experiencia de
configuración y consumo con Azure Private Link es coherente en los servicios compartidos de PaaS de Azure,
de propiedad del cliente y de asociados.
Rutas definidas por el usuario. El tráfico en una red virtual se enruta de forma predeterminada en función de
la tabla de enrutamiento del sistema. Una ruta definida por el usuario es una tabla de enrutamiento
personalizada que los administradores de red pueden asociar a una o varias subredes para reemplazar el
comportamiento de la tabla de enrutamiento del sistema y definir una ruta de comunicación en una red
virtual. La presencia de rutas definidas por el usuario garantiza que el tráfico de salida del radio transita a
través de máquinas virtuales personalizadas concretas o de aplicaciones virtuales de red y equilibradores de
carga presentes en el centro y los radios.
Grupos de seguridad de red. Un grupo de seguridad de red es una lista de reglas de seguridad que actúan
como filtro de los orígenes de IP, destinos de IP, protocolos y puertos de origen de IP y puertos de destino de
IP (también denominado 5-tupla de nivel 4). El grupo de seguridad de red se puede aplicar a una subred, una
NIV virtual asociada a una VM de Azure, o a ambas. Los grupos de seguridad de red son esenciales para
implementar un control de flujo correcto en el centro y en los radios. El nivel de seguridad que permite el
grupo de seguridad de red está en función de los puertos que abra y de su finalidad. Los clientes deben
aplicar filtros adicionales en cada máquina virtual con firewalls basados en host, como iptables o el Firewall
de Windows.
DNS. DNS proporciona resolución de nombres para los recursos de un centro de centros de datos virtual.
Azure proporciona servicios DNS tanto para la resolución de nombres públicos como privados. Las zonas
privadas proporcionan la resolución de nombres dentro de una red virtual o en redes virtuales distintas.
Puede hacer que las zonas privadas abarquen redes virtuales de la misma región, e incluso de distintas
regiones y suscripciones. Azure DNS proporciona un servicio de hospedaje de dominios DNS que permite
resolver nombres mediante la infraestructura de Microsoft Azure (resolución pública). Al hospedar dominios
en Azure, puede administrar los registros DNS con las mismas credenciales, API, herramientas y facturación
que con los demás servicios de Azure.
Administración de grupos de administración, suscripciones y grupos de recursos. Una suscripción define un
límite natural para crear varios grupos de recursos en Azure. Esta separación puede ser para la función, la
segregación de roles o la facturación. Los recursos de una suscripción se ensamblan juntos en contenedores
lógicos llamados grupos de recursos. El grupo de recursos representa un grupo lógico para organizar los
recursos de un centro de datos virtual. Si su organización tiene varias suscripciones, puede que necesite una
manera de administrar el acceso, las directivas y el cumplimiento de esas suscripciones de forma eficaz. Los
grupos de administración de Azure proporcionan un nivel de ámbito por encima de las suscripciones. Las
suscripciones se organizan en contenedores, conocidos como grupos de administración, y las condiciones de
gobernanza se aplican a los grupos de administración. Todas las suscripciones dentro de un grupo de
administración heredan automáticamente las condiciones que se aplican al grupo de administración. Para ver
estas tres características en una vista de jerarquía, consulte Organización de los recursos en Cloud Adoption
Framework.
Control de acceso basado en roles de Azure (Azure RBAC). RBAC de Azure puede asignar roles organizativos
y derechos de acceso a recursos específicos de Azure, lo que le permite restringir a los usuarios a solo un
subconjunto determinado de acciones. Si va a sincronizar Azure Active Directory con una instancia de Active
Directory local, puede usar los mismos grupos de Active Directory en Azure que usa en el entorno local. Con
RBAC de Azure, puede conceder acceso mediante la asignación del rol adecuado a usuarios, grupos y
aplicaciones dentro del ámbito correspondiente. El ámbito de una asignación de roles puede ser una
suscripción de Azure, un grupo de recursos o un único recurso. RBAC de Azure permite la herencia de
permisos. Un rol asignado en un ámbito principal también concede acceso a los elementos secundarios
dentro del mismo. Con RBAC de Azure, podrá repartir las tareas y conceder a los usuarios únicamente el
nivel de acceso que necesitan para realizar su trabajo. Por ejemplo, un empleado puede administrar
máquinas virtuales en una suscripción, mientras que otro puede administrar bases de datos de SQL Server
en la misma suscripción.
Tipo de componente: Redes perimetrales
Los componentes de una red perimetral (en ocasiones denominada red DMZ) conectan sus redes locales o
físicas del centro de datos, junto con toda conectividad a Internet. Normalmente, el perímetro requiere una
inversión de tiempo considerable de los equipos de red y de seguridad.
Los paquetes entrantes deben fluir a través de las aplicaciones de seguridad del centro antes de llegar a los
servicios y servidores back-end en los radios. Entre los ejemplos se incluyen el firewall, IDS e IPS. Antes de
abandonar la red, los paquetes enlazados a Internet desde las cargas de trabajo también deberían fluir a través
de las aplicaciones de seguridad de la red perimetral. Este flujo permite la aplicación de directivas, las
inspecciones y las auditorías.
Los componentes de una red perimetral incluyen:
Redes virtuales, rutas definidas por el usuario y grupos de seguridad de red
Aplicaciones virtuales de red
Equilibrador de carga de Azure
Azure Application Gateway con firewall de aplicaciones web (WAF)
Direcciones IP públicas.
Azure Front Door con firewall de aplicaciones web (WAF)
Azure Firewall y Azure Firewall Manager
DDoS Protection estándar
Normalmente, los equipos de TI central y de seguridad son responsables de la definición de requisitos y el
funcionamiento de las redes perimetrales.
El diagrama anterior muestra el cumplimiento de dos perímetros con acceso a Internet y a una red local, ambos
residentes en el centro de DMZ. En el centro de DMZ, la red perimetral a Internet se puede escalar verticalmente
para admitir muchas líneas de negocio, mediante varias granjas de firewalls de aplicaciones web (WAF) o
instancias de Azure Firewall. El centro también permite la conectividad local a través de VPN o ExpressRoute,
según sea necesario.
NOTE
En el diagrama anterior, en "DMZ hub", muchas de las características siguientes se pueden agrupar en un centro de Azure
Virtual WAN (por ejemplo, redes virtuales, rutas definidas por el usuario, grupos de seguridad de red, puertas de enlace
de VPN, puertas de enlace de ExpressRoute, instancias de Azure Load Balancer, instancias de Azure Firewall, Firewall
Manager y DDOS). El uso de centros de Azure Virtual WAN puede facilitar la creación de la red virtual del centro y, por
tanto, del centro de datos virtual, ya que Azure controla automáticamente la mayor parte de la complejidad de ingeniería
cuando se implementa un centro de Azure Virtual WAN.
Redes virtuales. El centro normalmente se basa en una red virtual con varias subredes para hospedar los
distintos tipos de servicios con filtrado e inspección del tráfico hacia o desde Internet mediante Azure Firewall,
NVA, WAF e instancias de Azure Application Gateway.
Rutas definidas por el usuario. Con las rutas definidas por el usuario, los clientes pueden implementar firewalls,
IDS e IPS y otras aplicaciones virtuales, así como enrutar el tráfico de red mediante estas aplicaciones de
seguridad para la aplicación de directivas de límites de seguridad, auditoría e inspección. Las rutas definidas por
el usuario pueden crearse en el centro y los radios para garantizar que el tráfico transita a través de VM
personalizadas específicas, aplicaciones virtuales de red y equilibradores de carga utilizados en una
implementación de un centro de datos virtual. Para garantizar que el tráfico que se genera desde las máquinas
virtuales residentes en el radio transita a las aplicaciones virtuales correctas, se debe establecer una ruta
definida por el usuario en las subredes del radio configurando la dirección IP del front-end del equilibrador de
carga interno como el próximo salto. El equilibrador de carga interno distribuye el tráfico interno a las
aplicaciones virtuales (grupo de back-end de equilibradores de carga).
Azure Firewall es un servicio de seguridad de red administrado que protege los recursos de Azure Virtual
Network. Se trata de un firewall administrado con estado, con alta disponibilidad y escalabilidad en la nube.
Puede crear, aplicar y registrar directivas de aplicaciones y de conectividad de red a nivel central en
suscripciones y redes virtuales. Azure Firewall usa una dirección IP pública estática para los recursos de red
virtual. Esto permite que los firewalls externos identifiquen el tráfico que procede de su red virtual. El servicio
está totalmente integrado con Azure Monitor para los registros y análisis.
Si usa la topología de Azure Virtual WAN, Azure Firewall Manager es un servicio de administración de seguridad
que proporciona una directiva de seguridad central y administración de rutas para perímetros de seguridad
basados en la nube. Funciona con el centro de Azure Virtual WAN, un recurso administrado por Microsoft que le
permite crear fácilmente arquitecturas en estrella tipo hub-and-spoke. Cuando las directivas de seguridad y
enrutamiento están asociadas a un centro de ese tipo, se conoce como centro virtual protegido.
Aplicaciones virtuales de red. En el centro, la red perimetral con acceso a Internet se administra normalmente a
través de una instancia de Azure Firewall o una granja de firewalls o mediante un firewall de aplicaciones web
(WAF).
Las diferentes líneas de negocio normalmente utilizan diversas aplicaciones web, que tienden a sufrir varias
vulnerabilidades y puntos débiles potenciales. Los firewall de aplicaciones web son un tipo especial de producto
que se usa para detectar ataques contra las aplicaciones web (HTTP/HTTPS) con mayor profundidad que un
firewall genérico. En comparación con la tecnología de firewall tradicional, los WAF tienen un conjunto de
características específicas para proteger los servidores web internos frente a amenazas.
Una instancia de Azure Firewall o un firewall de aplicación virtual de red utilizan un plano de administración
común, con un conjunto de reglas de seguridad para proteger las cargas de trabajo hospedadas en los radios y
controlar el acceso a las redes locales. Azure Firewall tiene escalabilidad integrada, mientras que los firewalls de
aplicación virtual de red se pueden escalar manualmente detrás de un equilibrador de carga. En general, una
granja de firewalls tiene menos software especializado en comparación con un WAF, pero tiene un ámbito más
amplio de aplicación para filtrar e inspeccionar cualquier tipo de tráfico de entrada y salida. Si se usa un enfoque
de aplicación virtual de red, se pueden encontrar e implementar desde Azure Marketplace.
Es recomendable que use un conjunto de instancias de Azure Firewall o de aplicaciones virtuales de red para el
tráfico que se origina en Internet. Use otro para el tráfico que se origina en el entorno local. Utilizar únicamente
un conjunto de firewalls para ambos es un riesgo de seguridad, ya que no proporciona ningún perímetro de
seguridad entre los dos conjuntos de tráfico de red. El uso de capas de firewalls independientes reduce la
complejidad de la comprobación de las reglas de seguridad y deja claro qué reglas se corresponden con cada
solicitud de red entrante.
Azure Load Balancer ofrece un servicio de nivel 4 (TCP/UDP) de alta disponibilidad que puede distribuir el
tráfico entrante entre instancias del servicio definidas en un conjunto de carga equilibrada. El tráfico que se
envía al equilibrador de carga desde los puntos de conexión de front-end (puntos de conexión de direcciones IP
públicas o privadas) se puede redistribuir con o sin traducción de direcciones a un conjunto de grupo de
direcciones IP de back-end (como aplicaciones virtuales de red o máquinas virtuales).
Azure Load Balancer puede sondear el estado de las diversas instancias de servidor y, si una instancia no
responde a alguna sonda, el equilibrador de carga deja de enviar tráfico a la instancia incorrecta. En un centro de
datos virtual se implementa un equilibrador de carga externo en el centro y en los radios. En el centro, el
equilibrador de carga se usa para enrutar el tráfico de forma eficaz entre instancias del firewall, mientras que en
los radios, los equilibradores de carga se utilizan para administrar el tráfico de las aplicaciones.
Azure Front Door (AFD) es una plataforma de aceleración de aplicaciones web de alta disponibilidad y
escalabilidad de Microsoft, con equilibrador de carga HTTP global, protección de aplicaciones y red de entrega
de contenido. Al ejecutarse en más de cien ubicaciones en el perímetro de la red global de Microsoft, AFD
permite crear, operar y escalar horizontalmente una aplicación web dinámica y contenido estático. AFD
proporciona a la aplicación un rendimiento de usuario final de primer orden, una automatización de
mantenimiento de marca/regional unificada, una automatización de BCDR, una información de cliente/usuario
unificada, un almacenamiento en caché y una información detallada de servicios. La plataforma ofrece:
Acuerdos de Nivel de Servicio (SLA) de rendimiento, confiabilidad y soporte técnico.
Certificaciones de cumplimiento.
Prácticas de seguridad auditables desarrolladas, dirigidas y compatibles de forma nativa con Azure.
Azure Front Door también ofrece un firewall de aplicaciones web (WAF), que protege las aplicaciones web de las
vulnerabilidades más habituales.
Azure Application Gateway es una aplicación virtual dedicada que proporciona un controlador de entrega de
aplicaciones administrado. Ofrece diversas funcionalidades de equilibrio de carga de nivel 7 para la aplicación.
Le permite optimizar el rendimiento de las granjas de servidores web al traspasar la carga de la terminación SSL
con mayor actividad de la CPU a Application Gateway. También dispone de otras funcionalidades de
enrutamiento de nivel 7, como la distribución round robin del tráfico entrante, la afinidad de sesiones basada en
cookies, el enrutamiento basado en rutas de acceso URL y la capacidad de hospedar varios sitios web detrás de
una única instancia de Application Gateway. También se proporciona un firewall de aplicaciones web (WAF)
como parte de la SKU de WAF de Application Gateway. Esta SKU proporciona protección a las aplicaciones web
frente a vulnerabilidades web y vulnerabilidades de seguridad comunes. Application Gateway puede
configurarse como una puerta de enlace orientada a Internet, una puerta de enlace solo para uso interno o una
combinación de las dos.
Direcciones IP públicas. Algunas características de Azure le permiten asociar los puntos de conexión de servicio
a una dirección IP pública de modo que pueda accederse al recurso desde Internet. Este punto de conexión usa
NAT para enrutar el tráfico a la dirección interna y el puerto de la red virtual de Azure. Esta ruta es la vía
principal para que el tráfico externo pase a la red virtual. Las direcciones IP públicas se pueden configurar para
determinar qué tráfico se pasa y cómo y a dónde se traslada en la red virtual.
Azure DDoS Protection estándar ofrece funcionalidades de mitigación adicionales, en comparación con el nivel
de servicio básico, que se ajustan específicamente a los recursos de Azure Virtual Network. El servicio
Protección contra DDoS estándar es fácil de habilitar y no requiere ningún cambio en la aplicación. Las
directivas de protección se ajustan a través de la supervisión del tráfico dedicado y los algoritmos de Machine
Learning. Las directivas se aplican a direcciones IP públicas asociadas a recursos implementados en redes
virtuales. Entre los ejemplos se incluyen instancias de Azure Load Balancer, Azure Application Gateway y Azure
Service Fabric. Casi en tiempo real, los registros generados por el sistema están disponibles a través de las vistas
de Azure Monitor durante un ataque y para el historial. Se puede agregar protección en la capa de aplicación
mediante el firewall de aplicaciones web de Azure Application Gateway. Se proporciona protección para
direcciones IP públicas de Azure IPv4 e IPv6.
La topología de hub-and-spoke usa el emparejamiento de red virtual y las rutas definidas por el usuario para
enrutar el tráfico correctamente.
En el diagrama, la ruta definida por el usuario garantiza que el tráfico fluya del radio al firewall antes de pasar al
entorno local a través de la puerta de enlace de ExpressRoute (si la directiva de firewall permite ese flujo).
Tipo de componente: Supervisión
Los componentes de supervisión proporcionan visibilidad y alertas sobre todos los demás tipos de
componente. Todos los equipos deben tener acceso a la supervisión de los componentes y servicios a los que
tienen acceso. Si tiene equipos de soporte técnico o de operaciones centralizados, necesitan un acceso integrado
a los datos que proporcionan estos componentes.
Azure ofrece diferentes tipos de servicios de registro y supervisión para realizar un seguimiento del
comportamiento de los recursos hospedados en Azure. La gobernanza y el control de las cargas de trabajo en
Azure no se basa solo en recopilar datos de registro, sino también en la posibilidad de desencadenar acciones
basándose en eventos notificados específicos.
Azure Monitor. Azure incluye varios servicios que realizan individualmente una tarea o un rol específico en el
espacio de supervisión. Juntos, estos servicios ofrecen una solución completa para recopilar, analizar y actuar en
función de los registros generados por el sistema desde las aplicaciones y los recursos de Azure que las
admiten. También pueden servir para supervisar recursos locales críticos, a fin de proporcionar un entorno de
supervisión híbrido. Conocer las herramientas y los datos que están disponibles es el primer paso para
desarrollar una estrategia de supervisión completa para las aplicaciones.
Hay dos tipos fundamentales de registros en Azure Monitor:
Las métricas son valores numéricos que describen algún aspecto de un sistema en un momento dado.
Las métricas son ligeras y capaces de admitir escenarios de tiempo casi real. En muchos recursos de
Azure, los datos recopilados por Azure Monitor aparecen directamente en la página de información
general de Azure Portal. Como ejemplo, eche un vistazo a cualquier máquina virtual y verá varios
gráficos en los que aparecen métricas de rendimiento. Seleccione cualquiera de los gráficos para abrir los
datos en el explorador de métricas de Azure Portal, lo que le permitirá crear gráficos con los valores de
diversas métricas a lo largo del tiempo. Puede ver los gráficos de forma interactiva o anclarlos a un panel
para verlos con otras visualizaciones.
Los registros contienen distintos tipos de datos organizados en grupos de registros, donde cada tipo
tiene diferentes conjuntos de propiedades. Los eventos y seguimientos se almacenan como registros
junto con los datos de rendimiento, que se pueden combinar todos para su análisis. Los datos de registro
recopilados por Azure Monitor se pueden analizar con consultas para recuperar, consolidar y analizar
rápidamente los datos recopilados. Los registros se almacenan y se consultan desde Log Analytics. Puede
crear y probar consultas mediante Log Analytics en Azure Portal y después analizar los datos
directamente mediante estas herramientas o guardar las consultas para usarlas con las visualizaciones o
las reglas de alertas.
Azure Monitor puede recopilar datos de diversos orígenes. Puede pensar en supervisar datos para las
aplicaciones en niveles que abarcan desde la aplicación, pasando por el sistema operativo y los servicios en los
que se basa, hasta la propia plataforma de Azure. Azure Monitor recopila datos de cada uno de los siguientes
niveles:
Datos de super visión de aplicaciones: datos sobre el rendimiento y la funcionalidad del código que ha
escrito, independientemente de la plataforma.
Datos de super visión del sistema operativo invitado : datos sobre el sistema operativo en el que se
ejecuta la aplicación. Este sistema operativo se puede ejecutar en Azure, en otra nube o en el entorno local.
Super visión de recursos con DMV : datos sobre el funcionamiento de un recurso de Azure.
Datos de super visión de la suscripción de Azure: datos sobre el funcionamiento y la administración de
una suscripción de Azure, así como sobre el estado y el funcionamiento del propio Azure.
Datos de super visión de inquilino de Azure: datos sobre el funcionamiento de los servicios de Azure en
el nivel del inquilino, como Azure Active Directory.
Orígenes personalizados: También se pueden incluir los registros enviados desde orígenes locales.
Algunos ejemplos incluyen los eventos de servidores locales o la salida syslog de dispositivos de red.
Los datos de supervisión solo resultan útiles si aportan una mayor visibilidad sobre el funcionamiento del
entorno informático. Azure Monitor cuenta con varias características y herramientas que proporcionan valiosa
información sobre las aplicaciones y los recursos de los que dependen. Las características y las soluciones de
supervisión, como Application Insights y Azure Monitor para contenedores, proporcionan información
exhaustiva sobre diferentes aspectos de la aplicación y determinados servicios de Azure.
Las soluciones de supervisión de Azure Monitor son conjuntos empaquetados de lógica que proporcionan
información sobre una determinada aplicación o servicio. Incluyen la lógica para recopilar datos de supervisión
para la aplicación o servicio, consultas para analizar esos datos y vistas para su visualización. Las soluciones de
supervisión están disponibles en Microsoft y partners, y ofrecen herramientas de supervisión para distintos
servicios de Azure y otras aplicaciones.
Una vez que se han recopilado todos estos datos enriquecidos, es importante tomar medidas proactivas sobre
los eventos que ocurren en el entorno en el que las consultas manuales solas no bastarán. Las alertas de Azure
Monitor informan de manera proactiva los estados críticos e intentan aplicar acciones correctivas. Las reglas de
alertas basadas en métricas proporcionan avisos casi en tiempo real que se generan en función de unos valores
numéricos, mientras que las reglas basadas en registros permiten aplicar una lógica compleja entre datos de
diversos orígenes. Las reglas de alertas de Azure Monitor utilizan grupos de acciones, que contienen diferentes
conjuntos de destinatarios y acciones que pueden compartirse entre varias reglas. En función de los requisitos,
los grupos de acciones pueden realizar diferentes acciones, como utilizar webhooks para que las alertas inicien
acciones externas o se integren en las herramientas de administración de servicios de TI.
Azure Monitor también permite la creación de paneles personalizados. Los paneles de Azure permiten combinar
distintos tipos de datos, como métricas y registros, en un único panel de Azure Portal. Si lo desea, también
compartir el panel con otros usuarios de Azure. Los elementos que componen Azure Monitor pueden agregarse
a un panel de Azure, así como a la salida de cualquier consulta de registro o gráfico de métricas. Por ejemplo,
puede crear un panel que contenga diferentes iconos que muestren un gráfico de métricas, una tabla de
registros de actividad, un gráfico de uso de Application Insights y la salida de una consulta de registro.
Por último, los datos de Azure Monitor son un origen nativo para Power BI. Power BI es un servicio de análisis
empresarial que proporciona visualizaciones interactivas en una serie de orígenes de datos, y que constituye un
mecanismo eficaz para poner los datos a disposición de personas que están dentro y fuera de la organización.
Puede configurar Power BI para que los datos de registro se importen automáticamente desde Azure Monitor y
utilizar estas visualizaciones adicionales.
Azure Network Watcher proporciona herramientas para supervisar, diagnosticar, ver las métricas y habilitar o
deshabilitar los registros de los recursos en una red virtual de Azure. Es un servicio polifacético, lo que permite
las funcionalidades siguientes y muchas más:
Supervisión de la comunicación entre una máquina virtual y un punto de conexión.
Visualización de recursos de una red virtual y sus relaciones.
Diagnóstico de problemas de filtrado del tráfico de red hacia o desde una máquina virtual.
Diagnóstico de problemas de enrutamiento de red desde una máquina virtual.
Diagnóstico de conexiones de salida desde una máquina virtual.
Captura de paquetes hacia y desde una máquina virtual.
Diagnóstico de problemas con conexiones y una puerta de enlace de una red virtual.
Determinación de latencias relativas entre las regiones de Azure y los proveedores de acceso a Internet.
Visualización de las reglas de seguridad para una interfaz de red.
Visualización de métricas de red.
Análisis del tráfico hacia y desde un grupo de seguridad de red.
Visualización de registros de diagnóstico de recursos de red.
Tipo de componente: Cargas de trabajo
Los componentes de carga de trabajo son donde residen los servicios y aplicaciones reales. Es donde los
equipos de desarrollo de aplicaciones dedican la mayor parte de su tiempo.
Las posibilidades de cargas de trabajo son infinitas. Estos son solo algunos de los tipos posibles de cargas de
trabajo:
Aplicaciones internas: Las aplicaciones de línea de negocio son críticas para las operaciones empresariales.
Estas aplicaciones tienen algunas características comunes:
Interactivas: Se especifican los datos y se devuelven resultados o informes.
Orientadas a datos: Uso intensivo de datos con acceso frecuente a bases de datos o a otros
almacenamientos.
Integradas: Integración de ofertas con otros sistemas dentro o fuera de la organización.
Sitios web accesibles para clientes (accesibles desde Internet o internamente): La mayoría de las
aplicaciones de Internet son sitios web. Azure puede ejecutar un sitio web a través de una máquina virtual IaaS o
una sitio de Azure Web Apps (PaaS). Azure Web Apps se integra en las redes virtuales para implementar
aplicaciones web en una zona de red de radios. Los sitios web a los que se accede internamente no necesitan
exponer un punto de conexión de Internet pública, ya que se puede acceder a los recursos a través de
direcciones privadas enrutables sin conexión a Internet desde la red virtual privada.
Análisis de macrodatos: Cuando sea necesario escalar los datos verticalmente a volúmenes más grandes, es
posible que las bases de datos relacionales no funcionen correctamente bajo la carga extrema o la naturaleza no
estructurada de los datos. Azure HDInsight es un servicio de análisis, de código abierto, espectro completo y
administrado en la nube para empresas. Puede usar marcos de código abierto, como Hadoop, Apache Spark,
Apache Hive, LLAP, Apache Kafka, Apache Storm y R. HDInsight admite la implementación en una red virtual
basada en ubicación, que se puede implementar en un clúster en un radio del centro de recursos virtual.
Eventos y mensajería: Azure Event Hubs es una plataforma de streaming de macrodatos y un servicio de
ingesta de eventos. Puede recibir y procesar millones de eventos por segundo. Ofrece retención de tiempo
configurable y baja latencia, lo que permite ingerir grandes cantidades de datos en Azure y leerlos desde varias
aplicaciones. Una única transmisión puede admitir canalizaciones en tiempo real y basadas en lotes.
Puede implementar un servicio de mensajería en la nube altamente confiable entre aplicaciones y servicios
mediante Azure Service Bus. Este ofrece mensajería asincrónica entre cliente y servidor, además de mensajería
estructurada de tipo FIFO (primero en entrar, primero en salir) y funcionalidades de publicación y suscripción.
Estos ejemplos apenas esbozan los tipos de cargas de trabajo que se pueden crear en Azure; todo desde una
aplicación web y SQL básica, hasta lo más reciente de IoT, macrodatos, aprendizaje automático, IA y mucho más.
Alta disponibilidad: varios centros de datos virtuales
Hasta ahora, este artículo se ha centrado en el diseño de un único centro de datos virtual, y en él se describen
los componentes básicos y las arquitecturas que contribuyen a su resistencia. Las características de Azure, como
Azure Load Balancer, las aplicaciones virtuales de red, las zonas de disponibilidad, los conjuntos de
disponibilidad, los conjuntos de escalado y otras funcionalidades, le ayudan a incluir niveles de SLA sólidos en
los servicios de producción.
Sin embargo, dado que un centro de datos virtual normalmente se implementa en una sola región, puede ser
vulnerable a cualquier interrupción que afecte a toda la región. Los clientes que requieran alta disponibilidad
deben proteger los servicios a través de implementaciones del mismo proyecto en dos implementaciones de
centros de datos virtuales (o más) ubicadas en regiones diferentes.
Además de los aspectos del acuerdo de nivel de servicio, varios escenarios comunes se benefician de la
ejecución de varios centros de datos virtuales:
Presencia regional o global de los usuarios finales o partners.
Requisitos de recuperación ante desastres.
Un mecanismo para desviar el tráfico entre centros de datos para la carga o el rendimiento.
Presencia regional y global
Existen centros de datos de Azure en muchas regiones de todo el mundo. Si selecciona varios centros de datos
de Azure, tenga en cuenta dos factores relacionados: distancias geográficas y latencia. Para optimizar la
experiencia del usuario, evalúe la distancia entre cada centro de datos virtual, así como la distancia entre cada
centro de datos virtual y los usuarios finales.
Una región de Azure que hospeda su centro de datos virtual debe cumplir los requisitos normativos de la
jurisdicción legal en la que opere su organización.
Recuperación ante desastres
El diseño de un plan de recuperación ante desastres depende de los tipos de cargas de trabajo y de la capacidad
para sincronizar el estado dichas cargas entre diferentes implementaciones de centros de datos virtuales.
Idealmente, la mayoría de los clientes desea un mecanismo de conmutación por error rápido, y este requisito
puede necesitar la sincronización de los datos de las aplicaciones entre las implementaciones que se ejecuten en
distintas implementaciones de centros de datos virtuales. Sin embargo, al diseñar los planes de recuperación
ante desastres, es importante tener en cuenta que a la mayoría de las aplicaciones les afecta la latencia que
puede provocar dicha sincronización de datos.
La sincronización y la supervisión del latido de las aplicaciones en diferentes implementaciones de centros de
datos virtuales exige comunicación a través de la red. Varias implementaciones de centros de datos virtuales de
diferentes regiones se pueden conectar mediante:
Comunicación de centro a centro, integrada en los centros de Azure Virtual WAN entre regiones de la misma
Virtual WAN.
Emparejamiento de red virtual para conectar centros de diferentes regiones.
Emparejamiento privado de ExpressRoute cuando los centros en cada una de las implementaciones de
centros de datos virtuales están conectados al mismo circuito de ExpressRoute.
Varios circuitos de ExpressRoute conectados a través de la red troncal corporativa y varias implementaciones
de centros de datos virtuales conectadas a los circuitos de ExpressRoute.
Conexiones VPN de sitio a sitio entre la zona del concentrador de las implementaciones de los centros de
datos virtuales de cada región de Azure.
Normalmente, los centros de Virtual WAN, el emparejamiento de red virtual o las conexiones de ExpressRoute
se prefieren para la conectividad de red, ya que tienen mayor ancho de banda y niveles de latencia coherentes al
pasar por la red troncal de Microsoft.
Ejecute pruebas de calificación de red para verificar la latencia y el ancho de banda de dichas conexiones y
decidir si la replicación de datos sincrónica o asincrónica es adecuada en función del resultado. También es
importante sopesar estos resultados teniendo en cuenta el objetivo de tiempo de recuperación óptimo (RTO).
Recuperación ante desastres: desvío del tráfico de una región a otra
Tango Azure Traffic Manager como Azure Front Door comprueban periódicamente el mantenimiento del
servicio de los puntos de conexión de escucha en distintas implementaciones de centros de datos virtuales y, si
se produce algún error en ellos, enruta automáticamente al siguiente centro de datos virtual secundario más
cercano. Traffic Manager usa medidas de usuario en tiempo real y DNS para enrutar a los usuarios al l más
cercano (o próximamente al más cercano durante el error). Azure Front Door es un proxy inverso en más de
100 sitios perimetrales de la red troncal de Microsoft, con difusión por proximidad para enrutar a los usuarios al
punto de conexión de escucha más cercano.
Resumen
El centro de datos virtual es un enfoque hacia la migración de centros de datos para crear una arquitectura
escalable que optimice los recursos que usa Azure, reduzca los costos y simplifique la gobernanza del sistema. El
centro de datos virtual suele basarse en topologías en estrella tipo hub-and-spoke (mediante el emparejamiento
de red virtual o los centros de Virtual WAN). Los servicios compartidos comunes que se proporcionan en el
centro y las aplicaciones y cargas de trabajo específicas se implementan en los radios. El centro de datos virtual
también coincide con la estructura de roles de la empresa, en la que diferentes departamentos, como TI Central,
DevOps, Operaciones y Mantenimiento, funcionan conjuntamente, aunque cumplan con sus roles específicos. El
centro de datos virtual permite migrar las cargas de trabajo locales existentes a Azure, pero también
proporciona muchas ventajas para las implementaciones nativas en la nube.
Referencias
Obtenga más información sobre las funcionalidades de Azure que se describen en este documento.
Características de red
Azure Virtual Network
Grupos de seguridad de red
Puntos de conexión de servicio
Private Link
Rutas definidas por el usuario
Direcciones IP públicas
DNS de Azure
Equilibrio de carga
Azure Front Door
Azure Load Balancer (capa 4)
Application Gateway (capa 7)
Azure Traffic Manager
Conectividad
Emparejamiento de redes virtuales
Red privada virtual
Virtual WAN
ExpressRoute
ExpressRoute Direct
Identidad
Azure Active Directory
Multi-Factor Authentication
Control de acceso basado en rol
Roles integrados en los recursos de Azure
Super visión
Network Watcher
Azure Monitor
Log Analytics
procedimientos recomendados
Grupo de administración
Administración de suscripciones
Administración de grupos de recursos
Límites de la suscripción de Azure
Seguridad
Azure Firewall
Firewall Manager
Application Gateway con WAF
Front Door con WAF
Azure DDoS
Otros ser vicios de Azure
Almacenamiento de Azure
SQL de Azure
Azure Web Apps
Azure Cosmos DB
HDInsight
Event Hubs
Service Bus
Azure IoT
Azure Machine Learning
Pasos siguientes
Obtenga más información sobre el emparejamiento de red virtual, la tecnología básica de las topologías en
estrella tipo hub-and-spoke.
Implemente Azure Active Directory para usar el control de acceso basado en roles de Azure.
Desarrolle un modelo de administración de recursos y suscripciones mediante un control de acceso basado
en roles de Azure que se adapte a la estructura, los requisitos y las directivas de su organización. La actividad
más importante es el planeamiento. Analice de qué manera las reorganizaciones, las fusiones, las nuevas
líneas de productos y otras consideraciones afectarán a los modelos iniciales, con el fin asegurarse de que
pueda escalar para satisfacer las necesidades y el crecimiento futuros.
Redes perimetrales
Las redes perimetrales permiten la conectividad segura entre las redes de la nube y las redes de los centros de
datos locales o físicos, así como todo tipo de conectividad hacia Internet y desde este. Una red perimetral a
veces se denomina subred filtrada o DMZ.
Para que las redes perimetrales sean eficaces, los paquetes entrantes deben fluir a través de los dispositivos de
seguridad hospedados en subredes seguras antes de llegar a los servidores back-end. Algunos ejemplos son el
firewall, los sistemas de detección de intrusiones y los sistemas de prevención de intrusiones. Antes de
abandonar la red, los paquetes enlazados a Internet de las cargas de trabajo también deberían fluir por las
aplicaciones de seguridad de la red perimetral. Este flujo tiene fines de auditoría, inspección y aplicación de
directivas.
Las redes perimetrales usan las siguientes características y servicios de Azure:
Redes virtuales, rutas definidas por el usuario y grupos de seguridad de red
Aplicaciones virtuales de red (NVA)
Equilibrador de carga de Azure
Azure Application Gateway y firewall de aplicaciones web (WAF)
Direcciones IP públicas.
Azure Front Door con firewall de aplicaciones web
Azure Firewall
NOTE
Las arquitecturas de referencia de Azure proporcionan plantillas de ejemplo que puede usar para implementar sus propias
redes perimetrales:
Implementación de una red perimetral entre Azure y el centro de datos local
Implementación de una red perimetral entre Azure e Internet
Por lo general, el equipo de TI y de seguridad centrales son responsables de definir los requisitos para el
funcionamiento de las redes perimetrales.
Ilustración 1:
Ejemplo de una topología de red en estrella tipo hub-and-spoke.
En el diagrama anterior se muestra un ejemplo de topología de red en estrella tipo hub-and-spoke que
implementa la aplicación de dos perímetros con acceso a Internet y a una red local. Ambos perímetros residen
en el concentrador de la red perimetral. En el concentrador de DMZ, la red perimetral a Internet puede escalarse
verticalmente para admitir varias líneas de negocio mediante varias granjas de firewalls de aplicaciones web
que ayudan a proteger las redes virtuales radiales. El concentrador también permite la conectividad a través de
VPN o Azure ExpressRoute, según sea necesario.
Redes virtuales
Las redes perimetrales normalmente se basan en una red virtual con varias subredes para hospedar los
distintos tipos de servicios con filtrado e inspección del tráfico hacia o desde Internet mediante NVA, WAF e
instancias de Azure Application Gateway.
Rutas definidas por el usuario

Con las rutas definidas por el usuario, los clientes pueden implementar los firewalls, sistemas de detección de
intrusiones, sistemas de prevención de intrusiones y otras aplicaciones virtuales. Los clientes pueden entonces
enrutar el tráfico de red a través de estas aplicaciones de seguridad para la aplicación de directivas de límites de
seguridad, auditoría e inspección. Se pueden crear rutas definidas por el usuario para garantizar que el tráfico
pase por las máquinas virtuales personalizadas, NVA y equilibradores de carga especificados.
En un ejemplo de red en estrella tipo hub-and-spoke, garantizar que el tráfico generado por las máquinas
virtuales que residen en el radio pase a través de los dispositivos virtuales correctos en el concentrador requiere
una ruta definida por el usuario definida en las subredes del radio. Esta ruta establece la dirección IP de front-
end del equilibrador de carga interno como el tipo de próximo salto. El equilibrador de carga interno distribuye
el tráfico interno a las aplicaciones virtuales (grupo de back-end de equilibradores de carga).
Azure Firewall
Azure Firewall es un servicio administrado basado en la nube que ayuda a proteger los recursos de la red virtual
de Azure. Se trata de un firewall administrado con estado completo, con alta disponibilidad integrada y una
escalabilidad sin restricciones en la nube. Puede crear, aplicar y registrar directivas de aplicaciones y de
conectividad de red a nivel central en suscripciones y redes virtuales.
Azure Firewall usa una dirección IP pública estática para los recursos de red virtual. Esto permite que los
firewalls externos identifiquen el tráfico que procede de su red virtual. El servicio interopera con Azure Monitor
para los registros y análisis.

Las redes perimetrales con acceso a Internet se administran normalmente mediante una instancia de Azure
Firewall o una granja de firewalls o mediante un firewall de aplicaciones web.
Las distintas líneas de negocio suelen usar muchas aplicaciones web. Estas aplicaciones tienden a sufrir varias
vulnerabilidades y posibles puntos débiles. Un firewall de aplicaciones web detecta ataques contra las
aplicaciones web (HTTP/S) con mayor profundidad que un firewall genérico. En comparación con la tecnología
de firewall tradicional, los firewalls de aplicaciones web tienen un conjunto de características específicas para
ayudar a proteger los servidores web internos frente a amenazas.
Una instancia de Azure Firewall y un firewall de [aplicación virtual de red][NVA] utilizan un plano de
administración común con un conjunto de reglas de seguridad para ayudar a proteger las cargas de trabajo
hospedadas en los radios y controlar el acceso a las redes locales. Azure Firewall tiene escalabilidad integrada,
mientras que los firewalls de aplicación virtual de red se pueden escalar manualmente detrás de un equilibrador
de carga.
En general, una granja de firewalls tiene menos software especializado en comparación con un WAF, pero tiene
un ámbito más amplio de aplicación para filtrar e inspeccionar cualquier tipo de tráfico de entrada y salida. Si
usa un enfoque NVA, puede buscar e implementar el software desde Azure Marketplace.
Use un conjunto de instancias de Azure Firewall (o NVA) para el tráfico que se origina en Internet y otro para el
que se origina en el entorno local. Utilizar únicamente un conjunto de firewalls para ambos es un riesgo de
seguridad, ya que no proporciona ningún perímetro de seguridad entre los dos conjuntos de tráfico de red. El
uso de capas de firewalls independientes reduce la complejidad de la comprobación de las reglas de seguridad y
deja claro qué reglas se corresponden con cada solicitud de red entrante.
Azure Load Balancer

Azure Load Balancer ofrece un servicio de nivel 4 (TCP y UDP) de alta disponibilidad que puede distribuir el
tráfico entrante entre instancias del servicio definidas en un conjunto de equilibrio de carga. El tráfico enviado al
equilibrador de carga desde los puntos de conexión front-end (puntos de conexión de direcciones IP públicas o
privadas) se puede redistribuir con o sin traducción de direcciones a un grupo de direcciones IP de back-end
(ejemplo: aplicaciones virtuales de red o máquinas virtuales).
Azure Load Balancer también puede sondear el estado de las distintas instancias de servidor. Cuando una
instancia no puede responder a un sondeo, el equilibrador de carga deja de enviar tráfico a las instancias
incorrectas.
Como ejemplo del uso de una topología de red en estrella tipo hub-and-spoke, puede implementar un
equilibrador de carga externo en el concentrador y en los radios. En el concentrador, el equilibrador de carga
enruta de forma eficaz el tráfico a los servicios de los radios. En los radios, los equilibradores de carga
administran el tráfico de la aplicación.
Azure Front Door

Azure Front Door es la plataforma de aceleración de aplicaciones web altamente disponible y escalable de
Microsoft y el equilibrador de carga HTTP global. Puede usar Azure Front Door para crear, operar y escalar
horizontalmente las aplicaciones web dinámicas y el contenido estático. Se ejecuta en más de 100 ubicaciones
de la red global de Microsoft.
Azure Front Door proporciona a la aplicación una automatización de mantenimiento de marca o regional
unificada, una automatización de BCDR, una información de cliente o usuario unificada, un almacenamiento en
caché y una información detallada de servicios. La plataforma ofrece Acuerdos de Nivel de Servicio de
rendimiento, confiabilidad y soporte técnico. También ofrece certificaciones de cumplimiento y procedimientos
de seguridad auditables desarrollados y operados por Azure, y compatibles de forma nativa con Azure.
Azure Application Gateway

Azure Application Gateway es una aplicación virtual dedicada que proporciona un controlador de entrega de
aplicaciones administrado como servicio. Ofrece diversas funcionalidades de equilibrio de carga de nivel 7 para
la aplicación.
Azure Application Gateway permite optimizar la productividad de las granjas de servidores web traspasando la
carga de la terminación SSL con mayor actividad de la CPU a la puerta de enlace de aplicaciones. También
dispone de otras funcionalidades de enrutamiento de nivel 7, como la distribución round robin del tráfico
entrante, la afinidad de sesiones basada en cookies, el enrutamiento basado en rutas de acceso URL y la
capacidad de hospedar varios sitios web detrás de una única puerta de enlace de aplicaciones.
La SKU de WAF de Azure Application Gateway incluye un firewall de aplicaciones web. Esta SKU proporciona
protección a las aplicaciones web frente a vulnerabilidades web y vulnerabilidades de seguridad comunes.
Puede configurar Azure Application Gateway como una puerta de enlace accesible desde Internet, una puerta de
enlace solo para uso interno o una combinación de las dos.
Direcciones IP públicas
Algunas características de Azure le permiten asociar los puntos de conexión de servicio a una dirección IP
pública que permite al recurso estar accesible desde Internet. Este punto de conexión usa la traducción de
direcciones de red (NAT) para enrutar el tráfico a la dirección interna y el puerto de la red virtual de Azure. Esta
ruta es la vía principal para que el tráfico externo pase a la red virtual. Las direcciones IP públicas se pueden
configurar para determinar qué tráfico se pasa y cómo y a dónde se traslada en la red virtual.
Protección contra DDoS de Azure estándar

Azure DDoS Protection estándar ofrece funcionalidades de mitigación adicionales, en comparación con el nivel
de servicio básico, que se ajustan específicamente a los recursos de Azure Virtual Network. La protección contra
DDoS estándar es fácil de habilitar y no requiere ningún cambio en la aplicación.
Puede ajustar las directivas de protección mediante la supervisión del tráfico dedicado y los algoritmos de
aprendizaje automático. Las directivas se aplican a direcciones IP públicas asociadas a recursos implementados
en redes virtuales. Algunos ejemplos incluyen Azure Load Balancer, Application Gateway e instancias de Service
Fabric.
La telemetría en tiempo real está disponible mediante las vistas de Azure Monitor durante un ataque y con fines
históricos. Se puede agregar protección en la capa de aplicación mediante el firewall de aplicaciones web de
Azure Application Gateway. Se proporciona protección para direcciones IP públicas de Azure IPv4.
Topología de red en estrella tipo hub-and-spoke
La red en estrella tipo hub-and-spoke es un modelo de red que permite la administración eficaz de los
requisitos habituales de comunicación o seguridad. También ayuda a evitar las limitaciones de las suscripciones
de Azure. Este modelo aborda los siguientes aspectos:
Ahorro en costos y eficiencia de la administración . La centralización de los servicios que se pueden
compartir entre varias cargas de trabajo, como las aplicaciones virtuales de red (NVA) y los servidores DNS,
en una única ubicación permite que TI minimice los recursos redundantes y el esfuerzo de administración.
Superación de los límites de las suscripciones. Las cargas de trabajo grandes basadas en la nube
pueden requerir el uso de más recursos que los permitidos en una sola suscripción de Azure. El
emparejamiento de redes virtuales de carga de trabajo de distintas suscripciones con un centro de
conectividad central puede superar estos límites. Para más información, consulte Límites de suscripción de
Azure.
Separación de intereses . Puede implementar cargas de trabajo individuales entre los equipos de TI
centrales y los equipos de las cargas de trabajo.
Es posible que los entornos en la nube más pequeños no se beneficien de la estructura y las funcionalidades
agregadas que ofrece este modelo. Pero los trabajos de adopción de la nube mayores deben considerar la
implementación de una arquitectura de red en estrella tipo hub-and-spoke si tienen alguna de las
preocupaciones mencionadas anteriormente.
NOTE
El sitio de arquitecturas de referencia de Azure contiene plantillas de ejemplo que puede usar como base para
implementar sus propias redes en estrella tipo hub-and-spoke:
Implementación de una topología de red en estrella tipo hub-and-spoke en Azure
Implementación de una topología de red en estrella tipo hub-and-spoke con servicios compartidos en Azure
Figura 1: Ejemplo de una topología de red en estrella tipo hub-and-spoke.
Como se muestra en el diagrama, Azure admite dos tipos de diseño en estrella tipo hub-and-spoke. Admite la
comunicación, los recursos compartidos y la directiva de seguridad centralizada (etiquetada como VNet hub en
el diagrama) o un diseño basado en Azure Virtual WAN (etiquetado como Virtual WAN en el diagrama) para
comunicaciones de rama a rama y de rama a Azure a gran escala.
Un concentrador es la zona de red central que controla e inspecciona el tráfico de entrada y salida entre las
diferentes zonas: Internet, local y radial. La topología en estrella tipo hub-and-spoke ofrece al departamento de
TI una manera eficaz de aplicar directivas de seguridad en una ubicación central. También reduce la posibilidad
de exposición y de configuración incorrecta.
El concentrador contiene los componentes de los servicios comunes utilizados por los radios. Los ejemplos
siguientes son servicios centrales comunes:
La infraestructura de Windows Server Active Directory necesaria para la autenticación de usuarios de
terceros que acceden desde redes que no son de confianza antes de obtener acceso a las cargas de trabajo
del radio. Incluye los Servicios de federación de Active Directory (AD FS) relacionados.
Un servicio DNS que resuelve los nombres de la carga de trabajo en los radios para acceder a recursos
locales y en Internet si no se utiliza Azure DNS.
Una infraestructura de clave pública (PKI), para implementar el inicio de sesión único en las cargas de trabajo.
Control de flujo de tráfico TCP y UDP entre las zonas de red de los radios (spokes) e Internet.
Control de flujo entre los radios (spokes) y local.
Si es necesario, control de flujo entre un radio y otro.
Puede minimizar la redundancia, simplificar la administración y reducir el costo general mediante el uso de la
infraestructura de concentrador compartida para admitir varios radios.
El rol de cada radio puede ser el hospedaje de diferentes tipos de cargas de trabajo. Los radios (spokes) también
proporcionan un enfoque modular para implementaciones repetibles de las mismas cargas de trabajo. Algunos
ejemplos incluyen desarrollo/pruebas, pruebas de aceptación del usuario, ensayo y producción.
Los radios también pueden segregar y habilitar varios grupos dentro de su organización. Por ejemplo, los
grupos de Azure DevOps. Dentro de un radio, es posible implementar una carga de trabajo básica o cargas de
trabajo de varios niveles complejas con control de tráfico entre los niveles.
Límites de la suscripción y múltiples concentradores

En Azure, todos los componentes, de cualquier tipo, se implementan en una suscripción de Azure. El aislamiento
de componentes de Azure en distintas suscripciones de Azure puede satisfacer los requisitos de diferentes líneas
de negocio, como la configuración de niveles diferenciados de acceso y autorización.
Una única implementación en estrella tipo hub-and-spoke puede escalarse verticalmente a un gran número de
radios. Pero, al igual que pasa con todos los sistemas de TI, hay límites en las plataformas. La implementación
del centro se enlaza a una suscripción de Azure específica que tiene restricciones y límites. Un ejemplo es un
número máximo de emparejamientos de redes virtuales. Para más información, consulte Azure subscription and
service limits (Límites de suscripción y servicio de Azure).
En los casos en los que los límites puedan ser un problema, puede escalar verticalmente la arquitectura
extendiendo el modelo desde un único concentrador y radio a un clúster de concentradores y radios. Puede
conectar entre sí varios concentradores en una o más regiones de Azure mediante el emparejamiento de redes
virtuales, Azure ExpressRoute, Azure Virtual WAN o una red privada virtual de sitio a sitio.
Figura 2: un clúster de centros de conectividad y radios.

La introducción de varios concentradores aumenta la sobrecarga del costo y del esfuerzo del sistema. Esto solo
se justifica por motivos de escalabilidad, límites del sistema o redundancia y replicación regional para el
rendimiento del usuario o recuperación ante desastres. En escenarios que requieran múltiples concentradores,
todos los concentradores deben procurar ofrecer el mismo conjunto de servicios para facilitar la operativa.
Interconexión entre los radios

Es posible implementar cargas de trabajo complejas de varios niveles en un único radio. Puede implementar
configuraciones de varios niveles mediante el uso de subredes (una para cada nivel) en la misma red virtual y el
uso de grupos de seguridad de red para filtrar los flujos.
Un arquitecto podría querer implementar una carga de trabajo de varios niveles entre varias redes virtuales.
Con el emparejamiento de redes virtuales, los radios pueden conectarse a otros radios en el mismo
concentrador o en concentradores diferentes.
Un ejemplo típico de este escenario es el caso en el que los servidores de procesamiento de la aplicación están
en un radio o red virtual. La base de datos se implementa en un radio o red virtual diferente. En este caso, es
fácil interconectar los radios con el emparejamiento de redes virtuales y así evitar el tránsito a través del
concentrador. La solución consiste en realizar una revisión cuidadosa de la arquitectura y la seguridad para
asegurarse de que evitar el paso por el concentrador no omite puntos de seguridad o auditoría de importancia
que podrían existir solo en el concentrador.
Figura 3: Radios que se conectan entre sí y un centro de conectividad.

Los radios también pueden estar conectados entre sí mediante un radio que actúa como concentrador. Este
método crea una jerarquía de dos niveles: el radio del nivel superior (nivel 0) se convierten en el concentrador
de radios inferiores (nivel 1) en la jerarquía. Los radios de una implementación en estrella tipo hub-and-spoke
están obligados a reenviar el tráfico al centro principal, con el fin de que pueda llegar a su destino pasando por
la red local o Internet pública. Una arquitectura con dos niveles de concentradores presenta un enrutamiento
complejo que anula las ventajas de una relación en estrella tipo hub-and-spoke simple.
Organización y configuración de entornos de Azure
Machine Learning
Al planear una implementación de Azure Machine Learning para un entorno empresarial, hay algunos puntos de
decisión comunes que afectan al modo en que se crea el área de trabajo:
Estructura del equipo: la forma en que se organizan los equipos de Machine Learning y colaboran en
los proyectos según el caso de uso y la segregación de datos, o los requisitos de administración de
costos.
Entornos: son los entornos que se usan como parte del flujo de trabajo de desarrollo y lanzamiento para
separar el desarrollo de la producción.
Región: indica la ubicación de los datos y la audiencia que necesita para proporcionar la solución de
Machine Learning.
Configuración del área de trabajo y estructura del equipo

El área de trabajo es el recurso de nivel superior de Azure Machine Learning. Almacena los artefactos que se
producen al trabajar con Machine Learning y los punteros y el proceso administrados para los recursos
asociados y asignados. Desde el punto de vista de la facilidad de uso, el área de trabajo como un recurso de
Azure Resource Manager permite el control de acceso basado en roles de Azure (RBAC de Azure), la
administración mediante la directiva, y se puede usar como una unidad para los informes de costos.
Normalmente, las organizaciones eligen una combinación de los siguientes patrones de solución para seguir los
requisitos de capacidad de administración.
Área de trabajo por equipo : puede usar un área de trabajo para cada equipo cuando todos los miembros de
este requieran el mismo nivel de acceso a los datos y los recursos de experimentación. Por ejemplo, una
organización con tres equipos de aprendizaje automático podría crear tres áreas de trabajo, una para cada
equipo.
La ventaja de usar un área de trabajo por equipo es que todos los artefactos de Machine Learning para los
proyectos del equipo se almacenan en un solo lugar. Igualmente, se puede aumentar la productividad, ya que los
miembros del equipo pueden acceder, explorar y reutilizar los resultados de la experimentación con facilidad. La
organización de las áreas de trabajo por equipo reduce la superficie de Azure y simplifica la administración de
costos por equipo. Dado que el número de activos de experimentación puede crecer rápidamente, puede
mantener los artefactos organizados siguiendo las convenciones de nomenclatura y el etiquetado. Para obtener
recomendaciones sobre cómo asignar nombres a los recursos, consulte Desarrollo de la estrategia de
nomenclatura y etiquetado de los recursos de Azure.
En este enfoque debe tener en cuenta que cada miembro del equipo debe tener permisos de nivel de acceso a
datos similares. El RBAC granular y las listas de control de acceso (ACL) para los orígenes de datos y los recursos
de experimentación se limitan dentro de un área de trabajo. Asimismo, no puede tener requisitos de
segregación de datos de los casos de uso.
Área de trabajo por proyecto: puede elegir el uso de un área de trabajo para cada proyecto si necesita
segregar los datos y los recursos de experimentación por proyecto, o si tiene requisitos de generación de
informes de costos y presupuestos en un nivel de proyecto. Por ejemplo, una organización con cuatro equipos
de aprendizaje automático, cada uno de los cuales ejecuta tres proyectos, podría crear 12 instancias de área de
trabajo.
La ventaja de usar un área de trabajo por proyecto es que los costos se pueden administrar en el nivel de
proyecto. Normalmente, los equipos crean un grupo de recursos dedicado para Azure Machine Learning y los
recursos asociados por motivos similares. Al trabajar con colaboradores externos, por ejemplo, un área de
trabajo centrada en el proyecto simplifica la colaboración en un proyecto porque los usuarios externos solo
necesitan obtener acceso a los recursos del proyecto, no a los recursos del equipo.
En este enfoque debe tener en cuenta el aislamiento de los resultados y los recursos de experimentación. La
detección y reutilización de los recursos puede ser más difícil debido a la distribución de recursos entre varias
instancias del área de trabajo.
Área de trabajo única: elija cómo va a usar un área de trabajo para realizar el trabajo que no esté relacionado
con el equipo o con el proyecto, o si los costos no se pueden asociar directamente a una unidad de facturación
específica como, por ejemplo, con R&D.
La ventaja de esta configuración es que el costo de un trabajo individual que no esté relacionado con el proyecto
se puede desacoplar de los costos que sí estén relacionados con el proyecto. Cuando se configura una sola área
de trabajo para que todos los usuarios realicen su trabajo individual, se reduce la superficie de Azure.
Una consideración para este enfoque es que el área de trabajo puede estar abarrotada rápidamente cuando
muchos profesionales de Machine Learning comparten la misma instancia. Los usuarios pueden necesitar usar
el filtrado basado en la interfaz de usuario de los recursos, para encontrar eficazmente esos recursos. Asimismo,
puede crear áreas de trabajo de Machine Learning compartidas para cada división de negocios a fin de mitigar
los problemas de escalado o los presupuestos de segmentos.
Configuración de los entornos y las áreas de trabajo

Un entorno es una colección de recursos que se implementa en el destino en función de su fase en el ciclo de
vida de la aplicación. Algunos ejemplos comunes de los nombres de entorno son Dev, Test, QA, Staging y
Production.
El proceso de desarrollo de su organización afecta a los requisitos de uso del entorno. El entorno afecta a la
configuración de Azure Machine Learning y a los recursos asociados, como el proceso adjunto. Por ejemplo, la
disponibilidad de los datos puede aplicar restricciones si tiene que administrar una instancia de Machine
Learning que esté disponible en cada entorno. Los siguientes patrones de solución son comunes:
Implementación del área de trabajo de un solo entorno: al elegir una implementación del área de trabajo
de un solo entorno, Azure Machine Learning se implementa en un solo entorno. Esta configuración es habitual
en escenarios centrados en la investigación, en los que no es necesario liberar los artefactos de Machine
Learning en función de su fase en el ciclo de vida de los entornos. Otro escenario en el que tiene sentido usar
este programa de instalación, es el momento de implementarlo en entornos los servicios de inferencia, y no en
las canalizaciones de Machine Learning.
La ventaja de usar una configuración centrada en la investigación es que otorga una superficie de Azure más
pequeña y tiene una sobrecarga mínima de administración. Esta forma de trabajar implica que no es necesario
tener un área de trabajo de Azure Machine Learning implementada en cada entorno.
En este enfoque debe tener en cuenta que la implementación de un solo entorno está sujeta a la disponibilidad
de los datos. Debe tener cuidado con la configuración del almacén de datos. Si configura un acceso amplio
como, por ejemplo, el acceso de escritor en los orígenes de datos de producción, podría dañar
involuntariamente la calidad de los datos. Si lleva trabajo al proceso de producción en el mismo entorno en el
que se realiza el desarrollo, se aplican las mismas restricciones de RBAC tanto para el trabajo de desarrollo
como para el trabajo de producción. Esta configuración podría hacer que ambos entornos sean demasiado
rígidos o demasiado flexibles.
Implementación del área de trabajo de varios entornos: al elegir una implementación de área de trabajo
de varios entornos, se implementa una instancia de área de trabajo para cada entorno. Un escenario común
para esta configuración es un área de trabajo regulada con una separación clara de deberes entre entornos, y
para los usuarios que tienen acceso a los recursos en esos entornos.
Las ventajas de esta migración son las siguientes:
Lanzamiento por fases de los flujos de trabajo y los artefactos de Machine Learning. Por ejemplo los
modelos entre entornos, que cuentan con el potencial de mejorar la agilidad y reducir el tiempo de
implementación.
Mayor seguridad y control de los recursos, ya que otorga la capacidad de asignar más restricciones de
acceso en entornos de nivel inferior.
Escenarios de entrenamiento en los datos de producción que se encuentran en entornos que no son de
desarrollo, ya que puede conceder acceso a un grupo de usuarios seleccionado.
En este enfoque debe tener en cuenta que es posible que deba realizar más operaciones administración y tenga
una sobrecarga de procesos, ya que este programa de instalación requiere un proceso de desarrollo e
implementación específico para los artefactos de Machine Learning entre instancias del área de trabajo.
Asimismo, es posible que necesite administrar los datos y realizar un esfuerzo de ingeniería para que los datos
de producción estén disponibles para el entrenamiento en el entorno de desarrollo. La administración de acceso
es necesaria para conceder a un equipo acceso para resolver e investigar incidentes en la producción. Por
último, los conocimientos de ingeniería de Azure DevOps y Machine Learning son necesarios en su equipo para
poder implementar flujos de trabajo de automatización.
Un entorno con acceso limitado a los datos y uno con acceso a los datos de producción: al elegir
esta configuración, Azure Machine Learning se implementa en dos entornos – un entorno que tiene acceso
limitado a los datos y un entorno que tiene acceso a los datos de producción. Esta configuración es habitual si
necesita separar los entornos de desarrollo y de producción. Por ejemplo, si está trabajando con restricciones
organizativas para que los datos de producción estén disponibles en cualquier entorno, o si quiere separar el
trabajo de desarrollo del trabajo de producción sin duplicar los datos más de lo necesario debido al alto costo
del mantenimiento.
La ventaja de esta configuración es la separación clara de las tareas y el acceso entre los entornos de desarrollo
y producción. Otra ventaja es la menor sobrecarga en la administración de recursos en comparación con un
escenario de implementación de varios entornos.
En este enfoque es necesario tener en cuenta que debe tener un proceso de desarrollo e implementación
definido para los artefactos de Machine Learning entre áreas de trabajo. Otro punto a tener en cuenta es que la
administración de datos y el esfuerzo de ingeniería pueden ser necesarios para que los datos de producción
estén disponibles para el entrenamiento en un entorno de desarrollo. Sin embargo, esto podría suponer un
esfuerzo relativamente menor que la implementación de un área de trabajo de varios entornos.
Configuración de regiones y recursos

La ubicación de los recursos, datos o usuarios puede requerir la creación de instancias de área de trabajo de
Azure Machine Learning y sus recursos asociados en varias regiones de Azure. Por ejemplo, un proyecto podría
abarcar sus recursos en las regiones de Azure del Oeste de Europa y el Este de EE. UU. por razones de
rendimiento, costo y cumplimiento normativo. Los escenarios siguientes son comunes:
Entrenamiento regional: los trabajos de aprendizaje de automático se ejecutan en la misma región de Azure
donde se encuentran los datos. En esta configuración, se implementa un área de trabajo de Machine Learning en
cada región de Azure donde se encuentran los datos. Este es un escenario común cuando se está actuando
según un cumplimiento normativo, o cuando se tienen restricciones de movimiento de datos entre regiones.
La ventaja de esta configuración es que la experimentación se puede realizar en el centro de datos donde se
encuentran los datos con la menor latencia de red. En este enfoque hay que tener en cuenta la ejecución de una
canalización de Machine Learning en varias instancias del área de trabajo, ya que agrega más complejidad de
administración. Es difícil comparar los resultados de experimentación entre instancias y, además, agrega una
sobrecarga a la administración de cuotas y procesos.
Si quiere adjuntar el almacenamiento entre regiones pero usa Compute desde una región, Azure Machine
Learning admite el escenario de conexión de cuentas de almacenamiento en una región en lugar de la conexión
en el área de trabajo. Los metadatos (por ejemplo, las métricas), por su parte, se almacenarán en la región del
área de trabajo.
Ser vicios regionales: las instancias de Machine Learning Service se implementan cerca del lugar en el que
reside el público de destino. Por ejemplo, si los usuarios de destino están en Australia y el almacenamiento
principal y la región de experimentación están en el Oeste de Europa, implemente el área de trabajo de Machine
Learning para realizar la experimentación en el Oeste de Europa e implemente un clúster de AKS para realizar la
implementación de puntos de conexión de inferencia en Australia.
Esta configuración otorga la oportunidad de realizar inferencias en el centro de datos donde se ingieren los
datos nuevos, minimizando así la latencia y el movimiento de datos y garantizando el cumplimiento de la
normativa local.
En este enfoque hay que tener en cuenta que una configuración de varias regiones proporciona varias ventajas,
pero también agrega más sobrecarga en la administración de cuotas y procesos. Cuando hay un requisito para
la inferencia de lotes, el servicio regional puede requerir una implementación de varias áreas de trabajo. Los
datos recopilados a través de puntos de conexión de inferencia pueden requerir que se transfieran entre
regiones para escenarios en los que se deba volver a realizar el entrenamiento.
Ajuste regional: un modelo base se entrena en un conjunto de datos inicial (por ejemplo, datos públicos o
datos de todas las regiones), y se ajusta posteriormente a un conjunto de datos regional. El conjunto de datos
regional puede existir solo en una región determinada debido a las restricciones de movimiento de datos o de
cumplimiento normativo. Por ejemplo, el entrenamiento del modelo base puede realizarse en un área de trabajo
de la región A, mientras que la optimización puede realizarse en un área de trabajo de la región B.
La ventaja de esta configuración es que la experimentación está disponible de acuerdo con el centro de datos
donde residen los datos; asimismo, sigue aprovechando el entrenamiento del modelo base en un conjunto de
datos más grande en una fase de canalización anterior.
En este enfoque hay que tener en cuenta que puede usar la capacidad de las canalizaciones de experimentación
complejas, pero esto podría crear más desafíos. Por ejemplo, si compara los resultados de los experimentos
entre regiones, puede agregar más sobrecarga a la administración de cuotas y procesos.
Implementación de referencia
Para ilustrar la implementación de Azure Machine Learning en una configuración más grande, en esta sección se
describe el modo en que la organización "Contoso" ha configurado Azure Machine Learning teniendo en cuenta
las restricciones organizativas, los informes y los requisitos de presupuesto:
Contoso crea grupos de recursos de acuerdo con las soluciones de administración de costos e informes.
Los administradores de TI solo crean grupos de recursos y recursos para soluciones financiadas y así
poder satisfacer los requisitos del presupuesto.
Debido a la naturaleza incierta y exploratoria de la ciencia de los datos, es necesario que los usuarios
tengan un lugar para experimentar y trabajar con el caso de uso y la exploración de datos. Muchas veces
el trabajo exploratorio no se puede asociar directamente a un caso de uso determinado y solo se puede
asociar al presupuesto R&D. Contoso quiere financiar algunos recursos de Machine Learning de forma
centralizada, para que cualquiera pueda usarlos con fines de exploración.
Una vez que un caso de uso de Machine Learning se crea de forma correcta en el entorno de exploración,
los equipos pueden solicitar grupos de recursos. Por ejemplo, Dev, QA y Prod se pueden usar para el
proyecto de experimentación iterativa y para configurar el acceso a los orígenes de datos de producción.
La segregación de datos y los requisitos de cumplimiento no permiten la existencia de datos de
producción activos en entornos de desarrollo.
Existen distintos requisitos de RBAC para varios grupos de usuarios en función de la directiva de TI por
entorno; por ejemplo, el acceso es más restrictivo en la producción.
Asimismo, todos los datos, la experimentación y la inferencia se realizan en una sola región de Azure.
Para cumplir los requisitos anteriores, Contoso ha configurado sus recursos de la siguiente manera:
Las áreas de trabajo y los grupos de recursos de Azure Machine Learning tienen como ámbito cada proyecto
para cumplir los requisitos de segregación de los casos de uso y de presupuesto.
Una configuración de varios entornos para Azure Machine Learning y sus recursos asociados para tratar los
requisitos de administración de costos, RBAC y acceso a datos.
Un solo grupo de recursos y un área de trabajo de Machine Learning dedicada a la exploración.
Grupos diferentes de Azure Active Directory por cada rol y entorno de usuario; por ejemplo, las operaciones
que puede realizar un científico de datos en un entorno de producción son diferentes de las del entorno de
desarrollo, y los niveles de acceso pueden variar en función de la solución.
Todos los recursos se crean en una única región de Azure.
Seguimiento de los costos en unidades de negocio,
entornos o proyectos
Para crear una organización con control de costos, hay que tener visibilidad de los datos relacionados con los
costos y contar también con un acceso (o ámbito) definido correctamente. En este artículo de procedimientos
recomendados se describen las decisiones y los enfoques de implementación para crear mecanismos de
seguimiento.
Ilustración 1: Esquema de un proceso de control de costos.
Establecimiento de la jerarquía de un entorno bien administrado

El control de costos, al igual que la gobernanza y otros elementos de administración, depende de que tengamos
un entorno bien administrado. El establecimiento de este tipo de entorno (especialmente uno complejo)
requiere procesos coherentes en la clasificación y organización de todos los recursos.
Los recursos incluyen todas las máquinas virtuales, los orígenes de datos y las aplicaciones que se implementan
en la nube. Azure proporciona varios mecanismos para clasificar y organizar los recursos. En Organización y
administración de las suscripciones de Azure se detallan las opciones para organizar los recursos en función de
varios criterios para establecer un entorno bien administrado. Este artículo se centra en la aplicación de
conceptos fundamentales de Azure para proporcionar visibilidad de costos de la nube.
clasificación
El etiquetado es una forma sencilla de clasificar los recursos, ya que asocia los metadatos a un recurso. Esos
metadatos se pueden usar para clasificar el recurso en función de varios puntos de datos. Cuando se usan
etiquetas para clasificar recursos como parte de un trabajo de administración de costos, las empresas suelen
necesitar las siguientes etiquetas: unidad de negocio, departamento, código de facturación, zona geográfica,
entorno, proyecto y carga de trabajo o categorización de aplicaciones. Azure Cost Management + Billing puede
usar estas etiquetas para crear vistas diferentes de los datos de costos.
El etiquetado es la principal forma de comprender los datos en los informes de costos. Se trata de una parte
fundamental de cualquier entorno bien administrado. También supone el primer paso para establecer la
gobernanza adecuada de cualquier entorno.
El primer paso para realizar un seguimiento preciso de la información de costos entre unidades de negocio,
entornos y proyectos es definir un estándar de etiquetado. El segundo paso es asegurarse de que el estándar de
etiquetado se aplica de forma coherente. Los artículos siguientes pueden ayudarlo a realizar cada uno de estos
pasos: desarrollo de convenciones de nomenclatura y etiquetado y establecimiento de un MVP de gobernanza
para aplicar estándares de etiquetado.
Existen varios métodos para organizar los recursos. En esta sección se describe un procedimiento recomendado
en función de las necesidades de una gran empresa con estructuras de costos distribuidas entre unidades de
negocio, zonas geográficas y organizaciones de TI. Hay un procedimiento recomendado similar para una
organización más pequeña y menos compleja en la Guía de gobernanza para empresas estándar.
En el caso de una empresa grande, el siguiente modelo para grupos de administración, suscripciones y grupos
de recursos creará una jerarquía que permite a cada equipo tener el nivel adecuado de visibilidad para realizar
sus tareas. Cuando la empresa necesita controles de costos para evitar la saturación del presupuesto, puede
aplicar herramientas de gobernanza como Azure Blueprints o Azure Policy a las suscripciones de esta estructura
para evitar rápidamente futuros errores de costos.
Ilustración 2: Organización de recursos de una gran empresa.

En el diagrama anterior, la raíz de la jerarquía del grupo de administración contiene un nodo para cada unidad
de negocio. En este ejemplo, la compañía multinacional necesita visibilidad de las unidades de negocio
regionales, por lo que crea un nodo para la zona geográfica en cada unidad de negocio de la jerarquía.
En cada zona geográfica, hay un nodo independiente para entornos de producción y de otros tipos con el
objetivo de aislar los controles de costos, acceso y gobernanza. Para que haya operaciones más eficientes y
sensatas, la empresa usa suscripciones para aislar aún más los entornos de producción con distintos grados de
compromisos de rendimiento operativo. Finalmente, la empresa usa grupos de recursos para capturar las
unidades que se pueden implementar de una función, denominadas "aplicaciones".
En el diagrama se muestran los procedimientos recomendados, pero no se incluyen estas opciones:
Muchas empresas limitan las operaciones a una única región geopolítica. Este enfoque reduce la necesidad
de diversificar las disciplinas de gobernanza o los datos de costos en función de los requisitos de soberanía
de datos locales. En esos casos, no se requiere un nodo de zona geográfica.
Algunas empresas prefieren separar aún más los entornos de desarrollo, pruebas y control de calidad en
suscripciones independientes.
Cuando una empresa integra un equipo de centro de excelencia de la nube (CCoE), las suscripciones de
servicios compartidos de cada nodo de zona geográfica pueden reducir los recursos duplicados.
Las tareas de adopción más reducidas podrían tener una jerarquía de administración mucho más pequeña.
Es habitual ver un solo nodo raíz para el grupo de TI corporativo, con un único nivel de nodos subordinados
en la jerarquía para varios entornos. Aunque no se trata de una infracción de los procedimientos
recomendados para un entorno bien administrado, hace más difícil proporcionar un modelo de acceso con
derechos mínimos para el control de costos y otras funciones importantes.
En el resto de este artículo se da por hecho que se utiliza el enfoque de procedimientos recomendados del
diagrama anterior. Sin embargo, los siguientes artículos pueden ayudarle a aplicar el enfoque a una
organización de recursos que se adapta mejor a su empresa:
Escalado del entorno de Azure con varias suscripciones
Organización y administración de las suscripciones de Azure
Implementación de un MVP de gobernanza para controlar los estándares de un entorno bien administrado
Proporcionar el nivel adecuado de acceso a los costos

La administración de costos es una actividad que tiene que realizar el equipo. La sección de preparación de la
plataforma de adopción de la nube (CAF) define un número reducido de equipos principales y describe cómo
esos equipos asumen los esfuerzos de adopción de la nube. En este artículo se amplían las definiciones de
equipo para definir el ámbito y los roles que se asignan a los miembros de cada equipo para tener el nivel de
visibilidad adecuado de los datos de administración de costos.
Los roles definen lo que un usuario puede hacer en varios recursos. El ámbito establece los recursos (usuario,
grupo, entidad de servicio o identidad administrada) en los que un usuario puede llevar a cabo operaciones.
Como procedimiento recomendado general, sugerimos un modelo con privilegios mínimos para asignar
personas a varios roles y ámbitos.
Roles
Azure Cost Management and Billing admite los siguientes roles integrados para cada uno de los siguientes
ámbitos:
Propietario: Puede ver los costos y administrar todo, incluida la configuración de costos.
Colaborador: Puede ver los costos y administrar todo, incluida la configuración de costos, pero sin incluir el
control de acceso.
Lector: puede ver todo, incluidos la configuración y los datos de costos, pero no realizar cambios.
Colaborador de Cost Management: Puede ver los costos y administrar la configuración de costos.
Lector de Cost Management: puede ver los datos de costo y configuración.
Como procedimiento recomendado general, a los miembros de todos los equipos se les debe asignar el rol
Colaborador de Cost Management, ya que concede a los usuarios acceso para crear y administrar presupuestos
y exportaciones con el objetivo de supervisar y notificar de manera más eficaz los costos. Sin embargo, los
miembros del equipo de estrategia de la nube deben tener solamente el rol Lector de Cost Management. Esto se
debe a que no están implicados en la configuración de presupuestos dentro de la herramienta de Azure Cost
Management + Billing.
Ámbito
La siguiente configuración de ámbito y rol creará la visibilidad necesaria de la administración de costos. Este
procedimiento recomendado podría requerir realizar cambios menores para que estén en consonancia con las
decisiones de la organización de recursos.
Equipo de adopción de la nube. Las responsabilidades de los cambios de optimización continua requieren
el acceso de Colaborador de Cost Management en el nivel de grupo de recursos.
Entorno de trabajo . Como mínimo, el equipo de adopción de la nube ya debe tener acceso de
Colaborador a todos los grupos de recursos afectados o, al menos, a los grupos relacionados con las
actividades de implementación en curso o de desarrollo/pruebas. No se requiere ninguna
configuración de ámbito adicional.
Entornos de producción . Cuando se establece una separación adecuada de la responsabilidad, es
probable que el equipo de adopción de la nube no siga teniendo acceso a los grupos de recursos
relacionados con sus proyectos. Los grupos de recursos que admiten las instancias de producción de
sus cargas de trabajo necesitarán un ámbito adicional para dar a este equipo visibilidad del impacto
de sus decisiones en el costo de producción. Al establecer el ámbito Colaborador de Cost
Management para los grupos de recursos de producción de este equipo, el equipo podrá supervisar
los costos y definir presupuestos en función del uso y la inversión continua en las cargas de trabajo
admitidas.
Equipo de estrategia de la nube. La responsabilidad de realizar un seguimiento de los costos en varios
proyectos y unidades de negocio requiere el acceso de Lector de Cost Management en el nivel raíz de la
jerarquía de grupos de administración.
Asigne Lector de Cost Management a este equipo en el grupo de administración. Esto garantizará una
visibilidad continua de todas las implementaciones asociadas a las suscripciones controladas por esa
Equipo de gobernanza de la nube. La responsabilidad de administrar el costo, la alineación del
presupuesto y los informes en todos los esfuerzos de adopción requiere el acceso de Colaborador de
Cost Management en el nivel de raíz de la jerarquía de grupos de administración.
En un entorno bien administrado, el equipo de gobernanza de la nube probablemente tiene un mayor
grado de acceso, por lo que la asignación del ámbito adicional de Colaborador de Cost Management
resulta innecesaria.
Centro de excelencia de la nube. La responsabilidad de administrar los costos relacionados con los
servicios compartidos requiere acceso de Colaborador de Cost Management en el nivel de suscripción.
Además, es posible que este equipo necesite el acceso de Colaborador de Cost Management a grupos de
recursos o suscripciones que contengan recursos implementados mediante automatizaciones de CCoE
para entender cómo afectan a los costos.
Ser vicios compar tidos . Cuando se activa un centro de excelencia en la nube, los procedimientos
recomendados sugieren que los recursos administrados mediante CCoE se admitan desde una
suscripción de servicios compartidos centralizada dentro de un modelo en estrella tipo hub-and-
spoke. En este escenario, es probable que el CCoE tenga acceso de colaborador o propietario a esa
suscripción, por lo que la asignación del ámbito adicional de Colaborador de Cost Management
resulta innecesaria.
Controles/automatización del CCoE . Normalmente, el CCoE proporciona controles y scripts de
implementación automatizados a los equipos de adopción de la nube. El CCoE tiene la responsabilidad
de comprender cómo afectan estos aceleradores a los costos. Para obtener esa visibilidad, el equipo
necesita acceso de Colaborador de Cost Management a cualquier grupo de recursos o suscripción que
ejecute dichos aceleradores.
Equipo de operaciones en la nube . La responsabilidad de administrar los costos continuos de los
entornos de producción requiere el acceso de Colaborador de Cost Management a todas las
suscripciones de producción.
La recomendación general coloca los recursos de producción y de otros tipos en suscripciones
independientes que se rigen por nodos de la jerarquía de grupos de administración asociados con
entornos de producción. En un entorno bien administrado, los miembros del equipo de operaciones
probablemente ya tienen acceso de propietario o colaborador a las suscripciones de producción, por
lo que el rol Colaborador de Cost Management resulta innecesario.
Recursos adicionales de administración de costos

Azure Cost Management + Billing es una herramienta bien documentada para establecer presupuestos y
obtener visibilidad de los costos de la nube de Azure o AWS. Después de establecer el acceso a la jerarquía de
un entorno bien administrado, los siguientes artículos pueden ayudarlo a usar esa herramienta para supervisar
y controlar los costos.
Introducción a Azure Cost Management + Billing
Para empezar a usar Azure Cost Management + Billing, consulte Optimización de la inversión en la nube con
Azure Cost Management + Billing.
Uso de Azure Cost Management + Billing
Creación y administración de presupuestos
Exportación de datos de costos
Optimización de los costos a partir de recomendaciones
Uso de alertas de costos para supervisar el uso y los gastos
Uso de Azure Cost Management + Billing para controlar los costos de AWS
Configuración de la integración de informes de uso y costos de AWS
Administración de los costos de AWS
Establecimiento de acceso, roles y ámbito
Información del ámbito de administración de costos
Establecimiento del ámbito de un grupo de recursos
Ruta de preparación de aptitudes durante la fase de
preparación de un recorrido de migración
Durante la fase de preparación de un recorrido de migración, el objetivo es prepararse para el viaje. Esta fase se
realiza en dos áreas principales: preparación de la organización y preparación (técnica) del entorno. Cada área
puede requerir nuevas aptitudes para los colaboradores técnicos y no técnicos. En las secciones siguientes se
describen algunas opciones para ayudarle a crear las aptitudes necesarias.
Preparación de la organización
En función de las motivaciones y los resultados empresariales asociados a un esfuerzo de adopción de la nube,
es posible que se requieran líderes para establecer nuevas estructuras organizativas o equipos virtuales para
facilitar diversas funciones. Los artículos siguientes le ayudarán a desarrollar las aptitudes necesarias para
estructurar los equipos de acuerdo con los resultados deseados:
Alineación inicial de la organización Información general sobre la alineación de la organización y diversas
estructuras de equipo para facilitar objetivos específicos.
Desglose en silos y feudos: Comprenda los dos antipatrones de organización comunes, así como formas de
guiar al equipo a la colaboración productiva.
Rutas de aprendizaje de la preparación (técnica) del entorno

Durante la fase de preparación, se llama al personal técnico para crear una zona de aterrizaje de la migración
capaz de hospedar, operar y gobernar las cargas de trabajo que se migraron a la nube. Es posible acelerar el
desarrollo de las aptitudes necesarias con las siguientes rutas de aprendizaje:
Creación de una cuenta de Azure: El primer paso para usar Azure es crear una cuenta. La cuenta contiene los
servicios de Azure que aprovisiona y controla su configuración personal como identidad, facturación y
preferencias.
Portal de Azure: Pasee por las características y servicios de Azure Portal, y personalice el portal.
Introducción a Azure: Para empezar a usar Azure, cree y configure su primera máquina virtual en la nube.
Introducción a la seguridad en Azure: Analice los conceptos básicos para proteger la infraestructura y los
datos cuando trabaje en la nube. Comprenda qué responsabilidades son suyas y de cuáles se encarga de
Azure.
Administración de recursos en Azure: Aprenda a trabajar con la línea de comandos de Azure y el portal web
Creación de una máquina virtual: Cree una máquina virtual con Azure Portal.
Redes de Azure: Obtenga información sobre los aspectos básicos de las redes de Azure y cómo la red de
Azure ayuda a mejorar la resistencia y a reducir la latencia.
Opciones de proceso de Azure: Revise los servicios de proceso de Azure.
Proteja los recursos con el control de acceso basado en rol de Azure (RBAC de Azure): Use RBAC de Azure
para proteger los recursos.
Opciones de almacenamiento de datos: Ventajas del almacenamiento de datos de Azure.
Durante la fase de preparación, se llama a los arquitectos en las soluciones de arquitectura que abarcan todos
los entornos de Azure. Los siguientes recursos de creación de aptitudes pueden preparar a los arquitectos para
estas tareas:
Fundamentos de la arquitectura en la nube: curso de PluralSight para ayudar a los arquitectos a encontrar las
soluciones básicas adecuadas.
Arquitectura de Microsoft Azure: curso de PluralSight para asentar a los arquitectos en la arquitectura de
Azure.
Diseño de migraciones para Microsoft Azure: curso de PluralSight para ayudar a los arquitectos a diseñar
una solución de migración.

Microsoft Learn
Los ejemplos siguientes son algunas rutas de aprendizaje personalizadas en Microsoft Learn que se alinean con
la metodología de preparación de Cloud Adoption Framework:
Aspectos básicos de Azure: obtenga información sobre conceptos de la nube, como los de alta disponibilidad,
escalabilidad, elasticidad, agilidad, tolerancia a errores y recuperación ante desastres. Comprenda las ventajas de
la informática en la nube en Azure y cómo puede ayudarle a ahorrar tiempo y dinero. Compare y contraste las
estrategias básicas para la transición a la nube de Azure. Explore toda la cartera de servicios disponibles en
Azure, como los servicios de proceso, red, almacenamiento y seguridad.
Administración de recursos en Azure: Aprenda a trabajar con la línea de comandos de Azure y el portal web
Administrar recursos de infraestructura en Azure: Aprenda a crear, administrar, proteger y escalar recursos de
Almacenamiento de datos en Azure: Azure proporciona una gran variedad de formas de almacenar datos (no
estructurados, para archivo, relacionales, etc.). Conozca los aspectos básicos de la administración del
almacenamiento en Azure, cómo crear una cuenta de almacenamiento y cómo elegir el modelo adecuado para
los datos que desea almacenar en la nube.
Diseño de soluciones excelentes en Azure: Aprenda a diseñar y compilar soluciones seguras, escalables y de alto
rendimiento en Azure mediante el examen de los principios básicos que se encuentran en cada una arquitectura
sólida.
Más información
Para conocer más rutas de aprendizaje, eche un vistazo al catálogo de Microsoft Learn. Use el filtro Roles para
Antipatrones de preparación de la nube
A menudo, los clientes experimentan antipatrones durante la fase de preparación de la adopción de la nube.
Estos antipatrones pueden provocar tiempos de inactividad inesperados, problemas de recuperación ante
desastres y problemas de disponibilidad.
Antipatrón: suponer que los servicios lanzados están preparados para

producción
Dado que la informática en la nube evoluciona rápidamente, las empresas a menudo lanzan versiones
preliminares de nuevos servicios. Los clientes tienden a suponer que pueden usar cualquier servicio en la nube
disponible en un entorno de producción. Sin embargo, pueden producirse problemas por estos motivos:
Normalmente, los servicios en versión preliminar no proporcionan Acuerdos de Nivel de Servicio (SLA) de
tiempo de actividad.
Los nuevos servicios no suelen estar tan desarrollados como los servicios en la nube que ya están
disponibles.
Ejemplo: uso de la versión preliminar de un servicio en producción
Un instituto de investigación utiliza en producción la versión preliminar de un servicio en la nube. El servicio
parece ser una buena opción para su caso de uso. Sin embargo, el instituto no realiza las debidas diligencias en
el servicio. El instituto tampoco sigue las instrucciones y los requisitos de la arquitectura de referencia.
Surgen problemas con el servicio en versión preliminar que provocan un tiempo de inactividad inesperado. El
instituto comienza a pensar que los servicios en la nube en general no están tan desarrollados ni son tan
resistentes como se había prometido.
Resultado preferido: uso de servicios en la nube aprobados previamente en producción
Al evaluar los nuevos servicios que se encuentran en versión preliminar, solo debe usar estos servicios en
escenarios de prueba de concepto (POC). No utilice estos servicios en entornos de producción, ya que no tienen
Acuerdos de Nivel de Servicio. Busque el equilibrio adecuado entre funcionalidad y madurez al aprobar
servicios en la nube. Consulte Lista de comprobación de diligencia debida de servicios en la nube para obtener
un marco establecido que pueda usar para evaluar rápidamente los servicios en la nube.
Antipatrón: suponer una mayor resistencia y disponibilidad

La informática en la nube suele tener ventajas frente a la informática local. Algunos ejemplos son:
Mayor resistencia: Recuperación después de un error.
Disponibilidad: Ejecución en un estado correcto sin tiempo de inactividad relevante.
Dado que la mayoría de los servicios en la nube ofrecen estas ventajas, muchas empresas suponen que todos
los servicios en la nube ofrecen resistencia y alta disponibilidad de forma predeterminada. En realidad, estas
características a menudo solo están disponibles con un costo y un esfuerzo técnico adicionales.
Ejemplo: suposición de una alta disponibilidad
Una empresa emergente implementa una aplicación crítica en servicios de infraestructura como servicio (IaaS).
Los desarrolladores de dicha empresa buscaron una máquina virtual (VM) con un Acuerdo de Nivel de Servicio
cuyo tiempo de actividad fuera del 99,9 %. Puesto que su intención era reducir los costos, usan una VM única y
almacenamiento prémium.
Cuando se produce un error en la VM, su aplicación no se puede recuperar. Se produce un tiempo de inactividad
inesperado. Habían dado por sentado que la nube ofrece alta disponibilidad de forma predeterminada. No
tuvieron en cuenta que las garantías de rendimiento pueden diferir entre:
Modelos de servicio tales como plataforma como servicio (PaaS) y software como servicio (SaaS).
Arquitecturas técnicas, como conjuntos de disponibilidad con equilibrio de carga y Availability Zones.
Resultado preferido: reducción de errores y equilibrio de la resistencia y los costos
Consulte los recursos de confianza y desarrollados para obtener información sobre los procedimientos
recomendados de arquitectura que pueden reducir el ámbito de los errores:
Arquitecturas de referencia
Marco de buena arquitectura de Microsoft Azure
Identifique el equilibrio adecuado entre costos y características como la alta resistencia y la disponibilidad. El
aumento de la resistencia y la disponibilidad normalmente supondrán un aumento de los costos. Por ejemplo:
Una sola VM puede tener un Acuerdo de Nivel de Servicio con un tiempo de actividad garantizado del
99,9 %.
Dos VM que ejecutan la misma carga de trabajo proporcionarán un Acuerdo de Nivel de Servicio con un
tiempo de actividad entre el 99,95 y el 99,99 %.
Participe en el proceso esencial de ingeniería de los requisitos cuando diseñe una solución basada en la nube.
Use un estimador de Acuerdo de Nivel de Servicio como ayuda para calcular dicho acuerdo de un extremo a
otro de la aplicación.
Antipatrón: convertirse en un proveedor de nube

Algunas empresas intentan convertir su departamento de TI interno en un proveedor de nube. A continuación,
el departamento de TI se responsabiliza de las arquitecturas de referencia. TI también debe proporcionar IaaS y
PaaS a las unidades de negocio. Puesto que este tipo de trabajo no suele formar parte del negocio principal de
TI, las ofertas de servicio resultantes pueden carecer de facilidad de uso, resistencia, eficacia y seguridad.
Ejemplo: prestación de servicios en la nube monolíticos administrados
El departamento de TI de una corporación establece un centro de excelencia de la nube (CCoE) que actúa como
agente entre TI y las unidades de negocio. Para asegurarse de que la corporación cumple los requisitos de la
nube, la junta directiva asigna al CCoE la tarea de proporcionar servicios monolíticos de un extremo a otro. El
CCoE configura un portal de compras interno en la nube, que las unidades de negocio pueden usar para solicitar
una VM en la nube totalmente administrada como un servicio. Sin embargo, TI controla quién puede acceder a
toda la plataforma y utilizarla. Como resultado, TI impide activamente que las unidades de negocio aprovechen
toda la gama de servicios que proporciona Azure. Las unidades de negocio no pueden acceder al portal de la
nube. Solo obtienen acceso a través de Secure Shell (SSH) y del Protocolo de escritorio remoto (RDP) al servidor
que solicitan.
Por varias razones, el CCoE tiene problemas para proporcionar un servicio monolítico administrado para
encapsular cada servicio disponible en la nube:
La nube ofrece un gran número de servicios en varias áreas de solución. En comparación con el desarrollo de
soluciones IaaS, el diseño y la ingeniería de soluciones de Internet de las cosas (IoT) e IA requieren distintos
conocimientos y conjuntos de aptitudes.
Los servicios en la nube cambian con frecuencia.
Intentar proporcionar servicios monolíticos aumenta el tiempo de comercialización de forma sustancial. TI
administra el proceso, no las unidades de negocio.
Resultado preferido: suministro de límites de protección
Al adoptar tecnologías de nube, haga que el departamento de TI obtenga una experiencia de primera mano con
la nube empezando por las cargas de trabajo de TI. Use Microsoft Cloud Adoption Framework para identificar su
primer proyecto de adopción.
Use un modelo operativo de nube desarrollado, como las operaciones centralizadas que atribuyen al
departamento de TI la responsabilidad de definir los límites de protección de la plataforma, como la
gobernanza. A continuación, las unidades de negocio pueden adoptar proyectos en la nube de forma segura y
coherente, dentro de los límites de protección definidos por TI.
Considere la posibilidad de adoptar un solo proveedor principal de nube pública al principio, ya que todas las
plataformas principales difieren significativamente en la configuración, la administración y el uso.
Use las soluciones de SaaS tanto como sea posible para las herramientas de TI, como:
Repositorios de código.
Integración continua y entrega continua (CI/CD).
Sistemas de colaboración.
En el caso de cargas de trabajo de la nube, aconseje a TI que use procedimientos conocidos que funcionen de
forma segura a escala.
Pasos siguientes
Información general sobre el fundamento de confiabilidad
Primer proyecto de adopción
Migración a la nube en Cloud Adoption Framework
Todos los planes de adopción de la nube a escala empresarial incluirán cargas de trabajo que no garantizan
inversiones significativas en la creación de una lógica de negocios. Estas cargas de trabajo se pueden mover a la
nube mediante diversos métodos: migración mediante lift-and-shift, lift-and-optimize o modernización. Cada
uno de estos enfoques se considera una migración. Los ejercicios siguientes le ayudarán a establecer los
procesos iterativos para evaluar, migrar, optimizar, proteger y administrar esas cargas de trabajo.
Para prepararse para esta fase del ciclo de vida de la adopción de la nube, se recomienda lo siguiente:
Migración de la primera carga de trabajo: Use la guía de

migración de Azure para familiarizarse tanto con las
herramientas nativas de Azure como con el método de
migración.
Escenarios de migración: Use otros enfoques y herramientas

de migración para actuar en otros escenarios de migración.
Procedimientos recomendados: Aborde las necesidades

comunes de migración mediante la aplicación de
procedimientos recomendados coherentes.
Mejoras de procesos: La migración es una actividad de

proceso intensivo. A medida que se escalan los esfuerzos de
migración, utilice estas mejoras de procesos para evaluar y
consolidar diversos aspectos de la migración.
Esta metodología de migración y los pasos anteriores se basan en los siguientes supuestos:
La metodología que rige los sprints de la migración se ajusta a las oleadas o versiones de esta, que se
definen mediante las metodologías de planeamiento, preparación y adopción. En cada sprint, se migra un
lote de cargas de trabajo a la nube.
Antes de migrar las cargas de trabajo, se ha identificado, configurado e implementado al menos una zona de
aterrizaje para satisfacer las necesidades del plan de adopción de la nube a corto plazo.
La migración se asocia normalmente con los términos lift-and-shift o rehospedaje. Tanto esta metodología
como los pasos anteriores se basan en la creencia de que no se deben migrar ningún centro de datos, y
pocas cargas de trabajo, mediante un enfoque de rehospedaje puro. Aunque se pueden rehospedar muchas
cargas de trabajo, los clientes suelen optar por modernizar recursos específicos dentro de cada carga de
trabajo. Durante este proceso iterativo, el equilibrio entre velocidad y modernización es un punto de debate
común.
Esfuerzo de migración
Las acciones necesarias para migrar las cargas de trabajo se divide en tres trabajos (o fases) para cada carga de
trabajo: evaluación, implementación y lanzamiento de las cargas de trabajo. Esta sección de Cloud Adoption
Framework enseña a los lectores a maximizar el retorno en todas las fases necesarias para migrar una carga de
trabajo a producción.
En una iteración estándar de dos semanas de duración, un equipo de migración experimentado puede
completar este proceso para entre 2 y 5 cargas de trabajo que tengan una complejidad de nivel media-baja. En
el caso de cargas de trabajo más complejas, como SAP, es posible que haya que realizar varias iteraciones de dos
semanas para completar las tres fases del trabajo de migración en una sola carga de trabajo. El grado de
experiencia y la complejidad pueden afectar considerablemente tanto a las escalas de tiempo como a la
velocidad de la migración.
En los siguientes puntos se proporciona información general sobre las fases de este proceso (representadas
arriba):
Evaluación de las cargas de trabajo: aquí se evalúan el costo, la modernización y las herramientas de
implementación. Este proceso se centra en la validación o el cuestionamiento de las suposiciones realizadas
durante la detección y las evaluaciones anteriores, para lo que se examinan detenidamente las opciones de
racionalización. Aquí es también cuando se estudian más detenidamente los patrones de usuario y las
dependencias, con el fin de asegurarse de que las cargas de trabajo van a funcionar correctamente a nivel
técnico después de la migración.
Implementación de las cargas de trabajo: una vez que las cargas de trabajo se evalúan, su funcionalidad
existente se replica (o se mejora) en la nube. Esto puede implicar una migración mediante lift-and-shift o un
rehospedar en la nube. Pero lo habitual en esta fase es modernizar muchos de los recursos que admiten
estas cargas de trabajo para aprovechar las ventajas de la nube.
Lanzar las cargas de trabajo: Una vez que la funcionalidad se replica en la nube, las cargas de trabajo se
pueden probar, optimizar, documentar y lanzar para las operaciones en curso. Durante este proceso, el
esfuerzo de revisar las cargas de trabajo migradas y proporcionarlas a los equipos de gobernanza,
administración de operaciones y seguridad es muy importante para poder ofrecer soporte técnico continuo
de las mismas.
NOTE
En algunas de las iteraciones iniciales del esfuerzo de migración, es habitual limitar el ámbito a una sola carga de trabajo.
Este enfoque maximiza la retención de las aptitudes y concede al equipo más tiempo para aprender y experimentar.
NOTE
Al crear una fábrica de migración, algunos equipos pueden elegir propagar todas y cada una de las fases anteriores entre
varios equipos y en varios sprints. Este enfoque no solo puede mejorar la capacidad de repetición, sino también acelerar
los esfuerzos de migración.
Olas de migración y administración de cambios iterativos

Las iteraciones de la migración aportan un valor técnico mediante la migración de recursos y cargas de trabajo.
Una oleada de una migración es la colección más pequeña de cargas de trabajo que proporcionan un valor
empresarial tangible y medible. Todas las iteraciones deben generar un informe en el que se resalten los
trabajos técnicos realizados. Sin embargo, lo habitual es que tanto los cambios empresariales como el
planeamiento estratégico se produzcan en un nivel algo superior. Dado que el equipo de adopción de la nube
realiza el esfuerzo de la migración, el equipo de estrategia de la nube se centra en planear las 1-2 oleadas de
migración siguientes. Este último equipo también realiza un seguimiento del progreso técnico como métrica de
aprendizaje para conocer mejor las escalas de tiempo para obtener un valor empresarial. En este sentido, las
oleadas de migración son el enfoque de la administración de cambios iterativos para realizar un seguimiento de
los resultados empresariales, los usuarios y las escalas de tiempo.
Como se mostraba en el gráfico de la sección anterior, los procesos de la metodología de planeamiento, de la
metodología de preparación y, hasta cierto punto, de la metodología de estrategia de Cloud Adoption
Framework proporcionan una guía para planear y administrar las oleadas de la migración. La administración de
estas oleadas asignará las prioridades y definirá los esfuerzos de migración que realizarán los equipos técnicos.
Pasos siguientes
Tanto los pasos que se han descrito anteriormente como la posterior guía que se puede encontrar en la
metodología de migración sirven de ayuda para desarrollar las aptitudes necesarias para mejorar los procesos
en los sprints de migración. La guía de migración de Azure es una breve serie de artículos en los que se
describen las herramientas y los enfoques más comunes necesarios durante la primera oleada de la migración.
Guía de migración a Azure
Introducción a la guía de migración de Azure
La Metodología de migración de Cloud Adoption Framework guía a los lectores a través de un proceso iterativo
de migración de una carga de trabajo, o de una pequeña colección de cargas de trabajo por cada lanzamiento.
En cada iteración, se sigue el proceso de evaluación, migración, optimización y promoción para asegurarse de
que las cargas de trabajo están listas para satisfacer las demandas de producción. Ese proceso independiente de
la nube puede guiar la migración a cualquier proveedor de servicios en la nube.
En esta guía se muestra una versión simplificada de ese proceso cuando migra desde su entorno local a Azure .
TIP
Para una experiencia interactiva, consulte esta guía en Azure Portal. Vaya al Centro de inicio rápido de Azure en
Azure Portal, seleccione Guía de migración a Azure y, después, siga las instrucciones detalladas.
Herramientas de migración
Cuándo utilizar esta guía
Esta guía es la ruta de acceso sugerida para su primera migración a Azure, ya que le mostrará la metodología y
las herramientas nativas de la nube que se usan con más frecuencia durante la migración a Azure. Estas
herramientas se presentan en las páginas siguientes:
Evaluación de la adecuación técnica de cada carga de trabajo. Valide la preparación técnica y la
idoneidad para la migración.
Migración de los ser vicios. Realice la migración real mediante la replicación de recursos locales en Azure.
Administrar costos y facturación : Conozca las herramientas necesarias para controlar los costos en
Azure.
Optimización y promoción. Optimice el equilibrio entre el costo y el rendimiento antes de promocionar la
carga de trabajo a producción.
Obtención de ayuda. Obtenga ayuda y soporte técnico durante las actividades de migración o posteriores
a ella.
Se supone que ya se ha implementado una zona de aterrizaje según los procedimientos recomendados en la
metodología de preparación de Cloud Adoption Framework.
Evaluación de cargas de trabajo y
perfeccionamiento de planes
Los recursos de esta guía le ayudarán a evaluar cada carga de trabajo, a cuestionar las suposiciones sobre la
idoneidad de cada una de ellas para la migración y a tomar decisiones arquitectónicas sobre las opciones de
migración.
Herramientas
Cuestionamiento de suposiciones
Escenarios y partes interesadas
Escalas de tiempo
Si no ha seguido las instrucciones de los vínculos anteriores, es probable que necesite datos y una herramienta
de evaluación para tomar decisiones bien fundamentadas sobre la migración. Azure Migrate es la herramienta
nativa para realizar la evaluación y migración a Azure. Si todavía no lo ha hecho, siga estos pasos para crear un
nuevo proyecto de migración de servidores y recopile los datos necesarios.
Azure Migrate
Azure Migrate proporciona un centro centralizado para evaluar y migrar a Azure servidores, infraestructuras,
aplicaciones y datos locales. Este servicio:
Evalúa si los servidores locales están listos para la migración a Azure.
Calcula el tamaño de las VM de Azure, la configuración de Azure SQL o el número de nodos de Azure
VMware Solution después de la migración.
Calcule el costo de la ejecución de servidores locales en Azure.
Identifica las dependencias entre servidores y las estrategias de optimización para mover servidores
interdependientes a Azure.
Si está considerando utilizar un enfoque lift-and-shift o se encuentra en las primeras fases de la evaluación de la
migración, este es el servicio que debe elegir. Después de completar la evaluación, use Azure Migrate para
ejecutar la migración.
Creación de un nuevo proyecto
Inicie una migración, evaluación y detección del servidor con Azure Migrate mediante estos pasos:
1. Seleccione Azure Migrate .
2. En Información general , seleccione Detectar, evaluar y migrar .
3. Seleccione Agregar herramientas .
4. En el Proyecto , seleccione la suscripción a Azure y cree un grupo de recursos, en caso de que no lo tenga.
5. En Detalles del proyecto , especifique el nombre del proyecto y la zona geográfica en la que quiere crearlo;
a continuación, seleccione Siguiente .
6. Después de crear el proyecto, las herramientas están visibles en el este y el usuario puede empezar con la
detección.
D IS C O V E R , AS S E S S AND
M I G R ATE
Más información
Información general de Azure Migrate.
Migración de servidores físicos o virtualizados a Azure
Azure Migrate en Azure Portal.
Análisis de dependencias
El análisis de dependencias identifica las dependencias entre los servidores locales detectados. Proporciona
estas ventajas:
Puede recopilar servidores en grupos para su evaluación de manera más precisa y con mayor confianza.
Puede identificar los servidores que se deben migrar juntos. Esto resulta especialmente útil si no está seguro
de qué servidores forman parte de la implementación de una aplicación que quiere migrar a Azure.
Puede identificar si los servidores están en uso y cuáles se pueden retirar en lugar de migrarlos.
El análisis de dependencias le ayuda a garantizar que no se olvida de nada y a evitar interrupciones
inesperadas después de la migración.
Más información
Análisis de dependencias de Azure Migrate
Migración de cargas de trabajo y recursos
(infraestructura, aplicaciones y datos)
En esta fase del recorrido, se usa la salida de la fase de evaluación para iniciar la migración del entorno. Esta
guía ayuda a identificar las herramientas adecuadas para alcanzar un estado completado. Explorará
herramientas nativas, herramientas de terceros y herramientas de administración de proyectos.
Herramientas de migración nativas
Herramientas de migración de terceros
Herramientas de administración de proyectos
En las secciones siguientes se describen las herramientas de Azure nativas disponibles para realizar la migración
o ayudar en ese proceso. Para información sobre cómo elegir las herramientas adecuadas para admitir los
esfuerzos de migración, consulte la Guía para la toma de decisiones sobre herramientas de migración de Cloud
Adoption Framework.
Azure Migrate
Azure Migrate ofrece una experiencia de migración unificada y extensible. Azure Migrate proporciona una
experiencia dedicada única para hacer el seguimiento del recorrido de la migración en las fases de evaluación y
migración a Azure. Ofrece la opción de usar las herramientas que prefiera y de hacer seguimiento del progreso
de la migración en estas herramientas.
Azure Migrate es un centro de conectividad para evaluar y migrar servidores, infraestructuras, aplicaciones y
datos locales a Azure. Proporciona la siguiente funcionalidad:
Plataforma unificada con evaluación, migración y seguimiento del progreso.
Funcionalidades mejoradas de evaluación y migración:
evaluar servidores locales, incluidas las instancias de SQL Server, y migrarlos a Azure Virtual
Machines o a Azure VMware Solution (versión preliminar).
Migración sin agentes de máquinas virtuales de VMware a Azure.
Evalúe bases de datos locales y mígrelas a Azure SQL Database o a una instancia administrada de
SQL.
Evalúe aplicaciones web locales y mígrelas a Azure App Service mediante Azure App Service
Migration Assistant.
Evalúe la infraestructura de escritorio virtual (VDI) local y mígrela a Windows Virtual Desktop en
Azure.
Migre grandes cantidades de datos a Azure de manera rápida y rentable gracias a los productos de
Azure Data Box.
Enfoque ampliable con integración de ISV (como Cloudamize).
Para realizar una migración con Azure Migrate, siga estos pasos:
1. Busque Azure Migrate en Todos los ser vicios . Seleccione Azure Migrate para continuar.
2. a. En Información general , seleccione Detectar, evaluar y migrar .
3. Seleccione Agregar herramientas .
4. En el Proyecto , seleccione la suscripción a Azure y cree un grupo de recursos, en caso de que no lo tenga.
5. En Detalles del proyecto , especifique el nombre del proyecto y la zona geográfica en la que quiere crearlo;
a continuación, seleccione Siguiente .
6. Después de crear el proyecto, las herramientas están visibles en el este y el usuario puede empezar con la
detección.
NOTE
Para obtener instrucciones específicas sobre su escenario, consulte los tutoriales y la documentación de Azure Migrate.
Más información
Acerca de Azure Migrate
Tutorial de Azure Migrate: Migración de servidores físicos o virtualizados a Azure
Azure Database Migration Service
Azure Database Migration Service es un servicio totalmente administrado que permite migraciones completas
desde varios orígenes de base de datos hasta las plataformas de datos de Azure con un tiempo de inactividad
mínimo (migraciones en línea). Database Migration Service realiza todos los pasos necesarios. Puede iniciar sus
proyectos de migración con la seguridad de que el proceso aprovecha los procedimientos recomendados de
Microsoft.
Creación de una instancia de Azure Database Migration Service
Si es la primera vez que usa Azure Database Migration Service, debe registrar el proveedor de recursos para la
suscripción de Azure:
1. Seleccione Todos los ser vicios > Suscripciones y elija la suscripción de destino.
2. Seleccione Proveedores de recursos .
3. Busque migration y, a la derecha de Microsoft.DataMigration , seleccione Registrar .
G O TO
Después de registrar el proveedor de recursos, puede crear una instancia de Azure Database Migration Service.
1. Seleccione +Crear un recurso y busque Azure Database Migration Ser vice en Marketplace.
2. Complete el asistente para creación de un servicio de migración y, después, seleccione Crear .
El servicio ya está listo para migrar las bases de datos de origen compatibles a las plataformas de destino, como
SQL Server, MySQL, PostgreSQL o MongoDB.
C R E ATE A N A Z U R E D ATA B A S E M I G R ATI O N S E R V I C E
I N S TA N C E
Para más información, consulte:

Introducción a Azure Database Migration Service.
Azure Migrate en Azure Portal.
Azure Portal: creación de un proyecto de migración
Azure App Service Migration Assistant
Azure App Service Migration Assistant forma parte de un conjunto de aplicaciones mayor que ayuda a las
organizaciones a realizar su transición a la nube. Migration Assistant proporciona una experiencia de usuario
guiada parecida a la de un asistente que realiza dos tareas:
1. Realiza una evaluación de una aplicación web específica instalada en Windows Server mediante la ejecución
de comprobaciones de compatibilidad previas a la migración en la aplicación web para determinar si es
posible realizar una migración a Azure App Service sin modificaciones en la aplicación web.
2. Si la evaluación demuestra que se puede migrar la aplicación web, Migration Assistant realizará la migración.
Tiene que proporcionar a Migration Assistant acceso a la cuenta de Azure, seleccionar el grupo de recursos
que quiere usar y seleccionar un nombre para la aplicación web, entre otros detalles.
Como alternativa, Migration Assistant genera una plantilla de Azure Resource Manager que puede utilizar para
migrar la aplicación web de forma más automatizada y repetible.
Migración de una aplicación web a Azure App Service
Migration Assistant comienza el proceso de migración mediante la recopilación de detalles clave de la cuenta de
Azure y, luego, realiza la migración.
En primer lugar, inicie sesión en la cuenta de Azure y asocie la sesión de Migration Assistant con la cuenta
mediante un código único. Luego, elija la suscripción, el grupo de recursos y el nombre de dominio del sitio
web. Puede optar por crear un nuevo plan de Azure App Service para hospedar la aplicación web o seleccionar
un plan existente. La elección afecta a la región geográfica desde la que se hospeda la aplicación web. También
tendrá la oportunidad de asociar este trabajo de migración a un proyecto de Azure Migrate existente Por último,
puede optar por omitir la configuración de la base de datos o configurar una conexión híbrida para habilitar una
conexión de base de datos.
Una vez que Migration Assistant recopila y comprueba sus selecciones, crea los recursos de Azure App Service
necesarios en la región y el grupo de recursos seleccionados. Comprime los archivos de origen de la aplicación
web y usa la API de implementación de Azure App Service para implementarlos. Por último, realiza pasos de
migración opcionales, como ayudar a configurar una conexión híbrida.
Después de una migración correcta, tiene que realizar algunas tareas posteriores a la migración. Entre ellas se
incluyen:
Migrar manualmente la configuración de la aplicación y las cadenas de conexión del archivo web.config a
Azure App Service.
Migrar datos de una instancia de SQL Server local a una instancia de Azure SQL Database.
Configurar un certificado SSL.
Configurar nombres de dominio personalizados.
Configurar permisos en Azure Active Directory.
También puede decidir cambiar el plan de hospedaje de Azure App Service y otras opciones como el escalado
automático y las ranuras de implementación.
Migración de aplicaciones de ASP.NET a Azure
Data Migration Assistant
Data Migration Assistant (DMA) ayuda a actualizar a una plataforma de datos moderna mediante la detección de
problemas de compatibilidad que pueden afectar la funcionalidad de la versión nueva de SQL Server o
Azure SQL Database. DMA recomienda mejoras de rendimiento y confiabilidad para el entorno de destino y le
permite migrar el esquema, los datos y objetos no contenidos desde el servidor de origen al servidor de
destino.
Data Migration Assistant se integra con Azure Migrate, lo que le permite realizar un seguimiento del progreso
de la evaluación en el panel de Azure Migrate. Inicie Data Migration Assistant desde Azure Migrate mediante la
herramienta Azure Migrate: Database Assessment y agregue la evaluación de la base de datos a Azure Migrate
seleccionando el botón Cargar en Azure Migrate de Data Migration Assistant.
NOTE
En el caso de migraciones de gran tamaño (en cuanto al número y tamaño de bases de datos), se recomienda usar Azure
Database Migration Service, que puede migrar bases de datos a escala.
Comience a usar Data Migration Assistant con estos pasos:

1. Descargue e instale Data Migration Assistant desde el Centro de descarga de Microsoft.
2. Para crear una evaluación, seleccione el icono Nuevo (+) y el tipo de proyecto Evaluación .
3. Establezca el tipo de servidor de origen y de destino y, a continuación, seleccione Crear .
4. Configure las opciones de evaluación según sea necesario (se recomiendan todos los valores
predeterminados).
5. Agregue las bases de datos que se van a evaluar.
6. Seleccione Siguiente para iniciar la evaluación.
7. Vea los resultados en Data Migration Assistant.
En el caso de una empresa, se recomienda seguir el enfoque descrito en el artículo sobre cómo evaluar una
empresa y consolidar informes de evaluación con DMA para evaluar varios servidores, combinar los informes y,
luego, usar los informes de Power BI proporcionados para analizar los resultados.
Para obtener más información, incluidos los pasos de uso detallados, consulte:
Información general de Data Migration Assistant.
Evaluación de una empresa y consolidación de informes de evaluación con DMA.
Análisis de informes de evaluación consolidados creados por Data Migration Assistant con Power BI.
SQL Server Migration Assistant
Microsoft SQL Server Migration Assistant (SSMA) es una herramienta diseñada para automatizar la migración
de bases de datos a SQL Server desde Microsoft Access, DB2, MySQL, Oracle y SAP ASE. El concepto general es
recopilar, evaluar y revisar con estas herramientas; sin embargo, debido a las variaciones del proceso para cada
uno de los sistemas de origen, recomendamos revisar la documentación detallada de SQL Server Migration
Assistant.
Información general de SQL Server Migration Assistant.
Asistente para experimentación con bases de datos
Asistente para experimentación con bases de datos (DEA) es una nueva solución de pruebas A/B para las
actualizaciones de SQL Server. Ayudará a evaluar una versión de SQL de destino para una carga de trabajo
determinada. Los clientes que actualizan de versiones anteriores de SQL Server (SQL Server 2005 y versiones
posteriores) a cualquier versión nueva de SQL Server pueden usar estas métricas de análisis.
El Asistente para experimentación con bases de datos contiene estas actividades de flujo de trabajo:
Captura: el primer paso de las pruebas A/B de SQL Server es capturar un seguimiento en el servidor de
origen. Por lo general, el servidor de origen es el servidor de producción.
Reproducción: el segundo paso de las pruebas A/B de SQL Server es reproducir el archivo de seguimiento
que se capturó en los servidores de destino. Luego, recopile seguimientos amplios a partir de las
reproducciones para el análisis.
Análisis: el último paso es generar un informe de análisis mediante el uso de los seguimientos de
reproducción. El informe de análisis puede ayudarlo a obtener información sobre las implicaciones de
rendimiento del cambio propuesto.
Información general del Asistente para experimentación con bases de datos.
Herramienta de migración de datos de Azure Cosmos DB
La herramienta de migración de datos de Azure Cosmos DB puede importar datos desde diversos orígenes a
colecciones y tablas de Azure Cosmos DB. Puede importar archivos JSON, archivos CSV, SQL, MongoDB, Azure
Table Storage, Amazon DynamoDB e incluso colecciones de SQL API de Azure Cosmos DB. También se puede
utilizar la herramienta de migración de datos para migrar una colección de partición única a una colección de
varias particiones de SQL API.
Herramienta de migración de datos de Azure Cosmos DB
Liberación de cargas de trabajo (prueba,
optimización y entrega)
Ahora que migró los servicios a Azure, la fase siguiente incluye revisar la solución para ver posibles áreas de
optimización. Este esfuerzo podría incluir la revisión del diseño de la solución, el ajuste correcto del tamaño de
los servicios y el análisis de los costos.
Esta fase también es una oportunidad para optimizar el entorno y realizar las transformaciones posibles del
entorno. Por ejemplo, es posible que haya realizado una migración de "rehospedaje" y ahora que los servicios se
ejecutan en Azure, puede revisar la configuración de soluciones o los servicios consumidos y, posiblemente,
realizar alguna "refactorización" para modernizar y aumentar la funcionalidad de la solución.
El resto de este artículo se centra en las herramientas para optimizar la carga de trabajo migrada. Cuando se
alcanza el equilibrio adecuado entre rendimiento y costo, ya se puede pasar a producción una carga de trabajo.
Para más información sobre las opciones de promoción, consulte los artículos sobre la mejora de procesos de
Optimización y promoción.
Recursos del tamaño correcto
Se puede cambiar el tamaño de todos los servicios de Azure que proporcionan un modelo de costos basado en
el consumo mediante Azure Portal, la CLI o PowerShell. El primer paso para ajustar correctamente el tamaño de
un servicio es revisar sus métricas de uso. El servicio Azure Monitor proporciona acceso a estas métricas. Puede
que tenga que configurar la recopilación de las métricas para el servicio que está analizando y permitir un
tiempo adecuado para recopilar datos significativos en función de los patrones de carga de trabajo.
1. Vaya a Super visar .
2. Seleccione Métricas y configure el gráfico para que se muestren las métricas del servicio que se va a
analizar.
G O TO
M O N I TO R
A continuación, se muestran algunos servicios comunes cuyo tamaño se puede cambiar.

Cambio de tamaño de una máquina virtual
Azure Migrate realiza un análisis del ajuste de tamaño como parte de la fase de evaluación previa a la migración
y las máquinas virtuales migradas con esta herramienta probablemente ya tengan el tamaño correcto en
función de los requisitos previos a la migración.
Sin embargo, en el caso de las máquinas virtuales creadas o migradas mediante otros métodos, o en los casos
en los que es necesario ajustar los requisitos de las máquinas virtuales posteriores a la migración, es posible
que quiera refinar aún más el tamaño de la máquina virtual.
1. Vaya a Máquinas vir tuales .
2. Seleccione la máquina virtual deseada en la lista.
3. Seleccione Tamaño y el nuevo tamaño deseado en la lista. Es posible que tenga que ajustar los filtros para
encontrar el tamaño que necesita.
4. Seleccione Cambiar tamaño .
El cambio de tamaño de las máquinas virtuales de producción puede generar interrupciones en el servicio.
Intente aplicar el ajuste de tamaño correcto en las máquinas virtuales antes de promocionarlas a producción.
G O TO V I R TU A L
M AC H INE S
Administración de reservas para los recursos de Azure

Cambio de tamaño de una máquina virtual Windows
Cambiar el tamaño de una máquina virtual Linux que usa la CLI de Azure
Los asociados pueden revisar el uso en el Centro de partners.
Cambio de tamaño de máquina virtual de Azure para usar la máxima reserva
Cambio de tamaño de una cuenta de almacenamiento
1. Vaya a Cuentas de almacenamiento .
2. Seleccione la cuenta de almacenamiento deseada.
3. Seleccione Configurar y ajuste las propiedades de la cuenta de almacenamiento para que coincidan con sus
requisitos.
4. Seleccione Guardar .
G O TO S TO R A G E
A C C O U N TS
Cambio de tamaño de una base de datos SQL

1. Vaya a Bases de datos SQL o a Ser vidores SQL y, a continuación, seleccione el servidor.
2. Seleccione la base de datos deseada.
3. Seleccione Configurar y el nuevo tamaño de nivel de servicio deseado.
4. Seleccione Aplicar .
G O TO S Q L
D ATA B A S E S
Mecanismos de control de costos centrados en la
migración
La nube presenta algunos cambios en nuestra forma de trabajar, independientemente de nuestro rol en el
equipo tecnológico. El costo es un buen ejemplo de este cambio. En el pasado, solo al liderazgo financiero y de
TI le preocupaban el costo de los recursos de TI (infraestructura, aplicaciones y datos). La nube permite a todos
los miembros de TI tomar decisiones que mejoren el soporte técnico para el usuario final y actuar sobre ellas. Si
embargo, con esa eficacia aparece la responsabilidad de tener en cuenta el costo al tomar esas decisiones.
En este artículo se presentan las herramientas que pueden ayudar a tomar decisiones inteligentes relativas al
costo antes, durante y después de la migración de las cargas de trabajo a Azure.
Entre las herramientas de este artículo, se incluyen:
Azure Migrate
Calculadora de precios de Azure
Calculadora de TCO de Azure
Administración de costos + facturación de Azure
Azure Advisor
También es posible que los procesos descritos en este artículo requieran una asociación con propietarios de
aplicaciones de línea de negocio, de finanzas o administradores de TI.
Estimación de costos de máquina virtual antes de la migración
Estimación y optimización de costos de máquina virtual durante y después de la migración
Trucos y sugerencias para optimizar los costos
Antes de la migración de cualquier recurso (infraestructura, aplicación o datos), hay una oportunidad de estimar
los costos y refinar el ajuste de tamaño en función de los criterios de rendimiento observados para esos
recursos. La estimación de costos cumple dos propósitos: permite el control de costos y proporciona un punto
de control para garantizar que los presupuestos actuales tengan en cuenta los requisitos de rendimiento
necesarios.
Calculadoras de costos
Para los cálculos de costos manuales, hay dos prácticas calculadoras que pueden proporcionar una estimación
del costo rápida en función de la arquitectura de la carga de trabajo que se va a migrar.
La calculadora de precios de Azure proporciona estimaciones de costos para los productos de Azure que
seleccione.
En ocasiones, las decisiones requieren una comparación de los costos de la nube futuros y los costos locales
actuales. La calculadora del costo total de propiedad (TCO) puede proporcionar esta comparación.
Estas calculadoras de costos manuales se pueden usar por su cuenta para prever los posibles gastos y ahorros.
También se pueden usar junto con las herramientas de previsión de costos de Azure Migrate para ajustar las
expectativas de costos para que se adapten a arquitecturas alternativas o restricciones de rendimiento.
Cálculos de Azure Migrate
Requisitos previos: el recordatorio de esta pestaña da por sentado que el lector ya ha rellenado Azure Migrate
con una colección de recursos (infraestructura, aplicaciones y datos) que se van a migrar. En el artículo anterior
sobre evaluaciones se proporcionan instrucciones de cómo recopilar los datos iniciales. Una vez que se rellenen
los datos, siga los siguientes pasos para estimar los costos mensuales en función de los datos recopilados.
Azure Migrate calcula los costos mensuales estimados en función de los datos capturados por el recopilador y el
mapa de servicio. Los siguientes pasos cargarán las estimaciones del costo:
1. Vaya a Evaluación de Azure Migrate en el portal.
2. En la página Información general del proyecto, seleccione +Crear evaluación .
3. Seleccione View all (Ver todo) para revisar la configuración de la evaluación.
4. Cree el grupo y especifique un nombre para él.
5. Seleccione las máquinas que desee agregar al grupo.
6. Seleccione Crear evaluación para crear el grupo y la evaluación.
7. Una vez creada la evaluación, puede verla en Introducción > Panel .
8. En la sección Detalles de la evaluación de la navegación del portal, seleccione Detalles del costo .
La estimación resultante, mostrada a continuación, identifica los costos mensuales de proceso y
almacenamiento, que suelen representar la parte más grande de los costos de la nube.
Figura 1: Diagrama de la vista de detalles del costo de una evaluación en Azure Migrate.
Configuración y revisión de una evaluación con Azure Migrate
Para obtener un plan más completo sobre la administración de costos en números más grandes de recursos
(infraestructura, aplicaciones y datos), consulte el artículo sobre el modelo de gobernanza de la Plataforma
de adopción de la nube. En concreto, consulte las directrices de la materia de administración de costos y la
mejora de la materia de administración de costos.
Obtención de ayuda
Somos conscientes de que obtener el soporte técnico adecuado en el momento adecuado acelerará los
esfuerzos de migración. Revise los medios de ayuda que se indican a continuación para satisfacer sus
necesidades.
Planes de soporte técnico
Asociados
Soporte técnico de Microsoft

Microsoft ofrece un plan de soporte técnico básico a todos los clientes de Azure. Dispone de acceso
ininterrumpido a soporte técnico sobre facturación y suscripciones, autoayuda en línea, documentación, notas
del producto y foros de soporte técnico.
Si necesita ayuda de Soporte técnico de Microsoft mientras usa Azure, siga estos pasos para crear una solicitud
de soporte técnico:
1. En Azure Portal, vaya a Ayuda y sopor te técnico .
2. Seleccione Nueva solicitud de sopor te técnico para especificar los detalles del problema y ponerse en
contacto con el soporte técnico.
1. Seleccione Ayuda y sopor te técnico .
2. Seleccione Nueva solicitud de sopor te técnico para especificar los detalles del problema y ponerse en
contacto con el soporte técnico.
C R E ATE A S U P P O R T
REQU EST
Para ver las solicitudes de soporte técnico, siga estos pasos:

2. Seleccione Todas las solicitudes de sopor te técnico para ver las solicitudes de soporte técnico.
2. Seleccione Todas las solicitudes de sopor te técnico para ver las solicitudes de soporte técnico.
V I E W YO U R S U P P O R T
R E Q U E S TS
¿Necesita ayuda de los ingenieros de soporte técnico para recibir instrucciones técnicas complejas?
2. Seleccione Planes de sopor te técnico para revisar los planes disponibles.
2. Seleccione Planes de sopor te técnico para revisar los planes disponibles.
R E V IE W S U PPO R T
PLANS
Comunidades en línea
Las siguientes comunidades en línea proporcionan soporte técnico basado en comunidad:
Foros de MSDN
Stack Overflow
El enfoque de una migración para migrar la cartera
de TI
Azure y Azure Migrate son muy conocidos a la hora de hospedar tecnologías de Microsoft. Pero es posible que
desconozca la capacidad de Azure para admitir migraciones más allá de Windows y SQL Server. Los escenarios
de una migración que se capturan en la metodología de migración muestran el mismo conjunto de directrices y
procesos consistentes para la migración de tecnologías de Microsoft y de terceros.
Escenarios de migración
El diagrama y la tabla siguientes describen varios escenarios que siguen la misma metodología de migración
iterativa para la migración y modernización.
Máquinas vir tuales Máquinas virtuales Servidores Linux Escritorios virtuales
Aplicaciones ASP.NET Java PHP
Data SQL Server Bases de datos de código Analytics

abierto
Híbrido Azure Stack VMware
Plataformas SAP (clásico y HANA) Kubernetes Sistemas centrales

tecnológicas
Otros escenarios Protección de cargas de Entornos multiinquilino NetApp

trabajo
Metodología de migración
En cada uno de los escenarios de migración anteriores, el mismo proceso básico le guiará en sus esfuerzos por
mover sus cargas de trabajo existentes a la nube, como se muestra aquí:
En todos los escenarios, estructurará las oleadas de migración para guiar los lanzamientos de varias cargas de
trabajo. El establecimiento de un plan de adopción de la nube y de las zonas de aterrizaje de Azure mediante las
metodologías de planeamiento y preparación ayuda a agregar una estructura a las oleadas de la migración.
En todas las iteraciones, siga la metodología de migración para evaluar las cargas de trabajo, implementarlas y
lanzarlas. Para modificar esos procesos para que se ajusten al escenario concreto de su organización, seleccione
cualquiera de los escenarios de migración de la tabla.
Pasos siguientes
Si no va a migrar un escenario concreto, empiece por seguir el proceso de migración de Cloud Adoption
Framework en cuatro pasos.
Información general de ejemplos de migración de
aplicaciones para Azure
En esta sección de Cloud Adoption Framework para Azure se proporcionan ejemplos de varios escenarios
comunes de migración y se muestra cómo puede migrar la infraestructura local a Microsoft Azure.
Introducción
Azure proporciona acceso a un conjunto completo de servicios en la nube. Los desarrolladores y profesionales
de TI pueden usar estos servicios para compilar, implementar y administrar aplicaciones en una variedad de
herramientas y marcos, a través de una red mundial de centros de datos. A medida que su negocio se enfrenta a
desafíos asociados con el cambio digital, la plataforma Azure le ayuda a averiguar cómo:
Optimizar los recursos y las operaciones.
Ponerse en contacto con sus clientes y empleados.
Transformar sus productos.
La nube ofrece ventajas en relación con la velocidad y la flexibilidad, la reducción de los costos, el rendimiento y
la confiabilidad. Pero muchas organizaciones tendrán que seguir ejecutando centros de recursos locales. En
respuesta a las barreras de adopción de la nube, Azure proporciona una estrategia híbrida de nube que
construye puentes entre sus centros de datos locales y la nube pública de Azure. Un ejemplo es el uso de
recursos de nube de Azure como Azure Backup para proteger los recursos locales o de Azure Analytics y
obtener información detallada sobre las cargas de trabajo locales.
Como parte de la estrategia de nube híbrida, Azure proporciona soluciones innovadoras para migrar
aplicaciones locales y cargas de trabajo a la nube. Con pasos sencillos, puede evaluar exhaustivamente sus
recursos locales para averiguar cómo se ejecutarán en la plataforma de Azure. Después, con una valoración
profunda en la mano, puedes migrar recursos con seguridad a Azure. Cuando los recursos están funcionando en
Azure, puede optimizarlos para retener y mejorar el acceso, la flexibilidad, la seguridad y la confiabilidad.
Patrones de migración
Las estrategias para la migración a la nube abarcan cuatro patrones amplios: rehospedar, refactorizar, rediseñar
o recompilar. La estrategia que adopte depende de los impulsores de negocio y los objetivos de la migración.
Puede adoptar varios patrones. Por ejemplo, podría optar por rehospedar las aplicaciones no críticas al volver a
diseñar la arquitectura de las aplicaciones más complejas y críticas para la empresa. Echemos un vistazo a estos
patrones.
PAT RÓ N DEF IN IC IÓ N C UÁ N DO SE USA

Rehospedaje Esta opción, que a menudo se conoce Cuando necesite mover aplicaciones
como "migración mediante lift-and- rápidamente a la nube.
shift", no requiere cambios en el
código. Puede usarla para migrar Cuando quiera mover una aplicación
rápidamente las aplicaciones existentes sin modificación alguna.
a Azure. Cada aplicación se migra tal
cual, para aprovechar las ventajas que Cuando las aplicaciones se diseñen de
ofrece la nube, sin correr los riesgos ni modo que puedan aprovechar la
incurrir en los costos asociados con los escalabilidad de la infraestructura
cambios de código. como servicio de Azure (IaaS) después
de la migración.
Cuando las aplicaciones son

importantes para su empresa, pero no
es necesario cambiar inmediatamente
las funcionalidades de estas.
Refactorización Este concepto con frecuencia se Si la aplicación se puede reempaquetar

conoce como "reempaquetar" y fácilmente para que funcione en Azure.
requiere una mínima cantidad de
cambios en las aplicaciones para que Si quiere aplicar prácticas DevOps
puedan conectarse a la plataforma innovadoras proporcionadas por
Azure como un servicio (PaaS) y usar Azure, o piensa en DevOps con una
las ofertas de la nube. estrategia de contenedor para las
cargas de trabajo.
Por ejemplo, puede migrar sus
aplicaciones existentes a Azure App Para la refactorización, debe pensar en
Service o Azure Kubernetes Service la portabilidad de la base de código
(AKS). existente y en las capacidades de
desarrollo disponibles.
O bien, podría refactorizar las bases de
datos relacionales y no relacionales en
opciones como, por ejemplo, Azure
SQL Managed Instance,
Azure Database for MySQL,
Azure Database for PostgreSQL y
Azure Cosmos DB.
Rediseño El rediseño para la migración se centra Cuando las aplicaciones necesitan

en modificar y ampliar la funcionalidad revisiones importantes para incorporar
de las aplicaciones y el código base con funcionalidades nuevas o para
el fin de optimizar la arquitectura de funcionar de forma eficaz en una
aplicación para la escalabilidad en la plataforma de nube.
nube.
Si desea usar las inversiones existentes
Por ejemplo, podría dividir una en las aplicaciones, cumplir los
aplicación monolítica en un grupo de requisitos de escalabilidad, aplicar
microservicios que funcionan en procedimientos innovadores de
conjunto y se escalan fácilmente. DevOps y minimizar el uso de
O bien, puede rediseñar también las
bases de datos relacionales y no
relacionales para adaptarlas a
soluciones de bases de datos
totalmente administradas, como SQL
Managed Instance, Azure Database for
MySQL, Azure Database for
PostgreSQL y Azure Cosmos DB.
Recompilación La recompilación va un paso más allá y Cuando quiera un desarrollo rápido y

recompila una aplicación desde cero las aplicaciones existentes tengan
mediante las tecnologías en la nube de funcionalidad y ciclo de vida limitados.
Azure.
Cuando esté listo para acelerar la
Por ejemplo, puede compilar innovación comercial (como las
aplicaciones totalmente nuevas con prácticas de DevOps que proporciona
tecnologías nativas de la nube como Azure), compilar nuevas aplicaciones
Azure Functions, Azure AI, Azure SQL mediante tecnologías nativas a la nube
Managed Instance y Azure y aprovechar los avances en
Cosmos DB. inteligencia artificial, cadena de
bloques e IoT.
Artículos de ejemplo de una migración

En esta sección se proporcionan ejemplos de varios escenarios comunes de migración. Cada ejemplo incluye
información general y escenarios de implementación detallados en los que se muestra cómo configurar una
infraestructura de migración y evaluar la idoneidad de los recursos locales para la migración. Con el tiempo, se
agregarán más artículos en esta sección.
Figura 1: Categorías comunes de proyectos de migración y modernización.

Esta serie se centra en cada escenario de migración impulsado por objetivos empresariales ligeramente
distintos que determinan la estrategia de migración. Para cada escenario de implementación, se proporciona
información sobre:
Controladores y objetivos empresariales.
Una arquitectura propuesta.
Pasos para realizar la migración.
Recomendaciones para la limpieza y los pasos siguientes una vez finalizada la migración.
Evaluación
A RT ÍC ULO DETA L L ES
Valoración de los recursos locales para su migración a Azure En este artículo de procedimientos recomendados del plan
metodológico se describe cómo ejecutar una evaluación de
una aplicación local que se ejecuta en VMware. En este
artículo, una organización de ejemplo evalúa las máquinas
virtuales de la aplicación mediante Azure Migrate y la base
de datos SQL Server de la aplicación mediante Data
Migration Assistant.
Infraestructura
Implementación de una infraestructura de Azure En este artículo se muestra cómo una organización puede
preparar su infraestructura local y su infraestructura de
Azure para la migración. En el resto de los ejemplos que se
proporcionan en esta sección se hace referencia al ejemplo
de infraestructura que se establece en este artículo.
Cargas de trabajo de Windows Server

Rehospedaje de una aplicación en máquinas virtuales de En este artículo se proporciona un ejemplo de migración de
Azure máquinas virtuales de aplicaciones locales a máquinas
virtuales de Azure mediante Azure Migrate.
Cargas de trabajo de SQL Server

Migración de bases de datos de SQL Server en Azure En este artículo se muestra cómo la empresa ficticia Contoso
evaluó, planeó y migró sus diversas bases de datos de SQL
Server locales a Azure.
Rehospedaje de una aplicación en una máquina virtual de En este artículo se proporciona un ejemplo de migración de
Azure e Instancia administrada de Azure SQL mediante lift-and-shift a Azure para una aplicación local. Este
proceso implica la migración de la máquina virtual de front-
end de aplicaciones mediante Azure Migrate y la base de
datos de la aplicación a SQL Managed Instance con Azure
Database Migration Service.
Rehospedaje de una aplicación en máquinas virtuales de En este ejemplo se muestra cómo migrar una aplicación y
Azure y en los grupos de disponibilidad Always On de SQL datos mediante las máquinas virtuales de SQL Server
Server hospedadas en Azure. Usa Azure Migrate para migrar las
máquinas virtuales de la aplicación y Database Migration
Service para migrar la base de datos de la aplicación a un
clúster de SQL Server protegido por un grupo de
disponibilidad Always On.
Bases de datos Linux y de código abierto

Migración de bases de datos de código abierto a Azure En este artículo se muestra cómo la empresa ficticia Contoso
evaluó, planificó y migró sus diversas bases de datos de
código abierto locales a Azure.
Migración de MySQL a Azure En este artículo se muestra cómo la empresa ficticia Contoso
evaluó, planificó y migró sus bases de datos de código
abierto locales de MySQL a Azure.
Migración de PostgreSQL a Azure En este artículo se muestra cómo la empresa ficticia Contoso
evaluó, planeó y migró a Azure su plataforma de bases de
datos de código abierto locales de PostgreSQL.
Migración de MariaDB a Azure En este artículo se muestra cómo la empresa ficticia Contoso
evaluó, planificó y migró su plataforma de bases de datos de
código abierto locales de MariaDB a Azure.
Rehospedaje de una aplicación Linux en máquinas virtuales En este artículo se proporciona un ejemplo de migración de
de Azure y Azure Database for MySQL una aplicación hospedada por Linux a máquinas virtuales de
Azure mediante Azure Migrate. La base de datos de la
aplicación se migra a una instancia de Azure Database for
MySQL mediante Azure Database Migration Service.
Rehospedaje de una aplicación de Linux en máquinas En este ejemplo se muestra cómo completar una migración
virtuales de Azure mediante lift-and-shift de una aplicación basada en Linux a
las máquinas virtuales de Azure con Azure Migrate.
Cargas de trabajo de desarrollo/pruebas

Migración de entornos de desarrollo/pruebas a IaaS de En este artículo se muestra el modo en que Contoso
Azure rehospeda su entorno de desarrollo y pruebas para dos
aplicaciones que se ejecutan en máquinas virtuales de
VMware mediante la migración a Azure Virtual Machines.
Migración a Azure DevTest Labs En este artículo se describe el modo en que Contoso
traslada sus cargas de trabajo de desarrollo y pruebas a
Azure mediante DevTest Labs.
Aplicaciones web de ASP.NET y PHP

Refactorización de una aplicación de Windows con App En este ejemplo se muestra cómo migrar una aplicación local
Service y SQL Database basada en Windows a una aplicación web de Azure y la base
de datos de la aplicación a una instancia de servidor de
Azure SQL Database con Database Migration Service.
Refactorización de una aplicación de Windows con App En este ejemplo se muestra cómo migrar una aplicación local
Service y SQL Managed Instance basada en Windows a una aplicación web de Azure y la base
de datos de la aplicación a Azure SQL Managed Instance con
Refactorización de una aplicación de Linux a varias regiones En este ejemplo se muestra cómo migrar una aplicación local
con Azure App Service, Azure Traffic Manager y Azure basada en Linux a una aplicación web de Azure en varias
Database for MySQL regiones de Azure con Traffic Manager integrado con GitHub
para la entrega continua. La base de datos de la aplicación se
migra a una instancia de Azure Database for MySQL.
Recompilación de una aplicación en Azure En este artículo se proporciona un ejemplo de recompilación

de una aplicación local mediante diversas funcionalidades y
servicios administrados de Azur. Entre estas funcionalidades
y servicios, se incluyen App Service, AKS, Azure Functions,
Azure Cognitive Services y Azure Cosmos DB.
Refactorización de Team Foundation Server en Azure DevOps En este artículo se muestra un ejemplo de migración de una
Services implementación de Team Foundation Server local a Azure
DevOps Services en Azure.
SAP
Guía de migración de SAP Obtenga instrucciones prácticas para trasladar sus cargas de
trabajo de SAP locales a la nube.
Migración de aplicaciones de SAP a Azure Notas del producto y guía básica para el recorrido de SAP a
la nube.
Metodologías de migración para SAP en Azure Información general sobre las distintas opciones de
migración para mover aplicaciones de SAP a Azure.
Cargas de trabajo especializadas

Traslado de la infraestructura de VMware local a Azure En este artículo se proporciona un ejemplo de cómo mover
una máquina virtual de VMware local a Azure mediante
Azure VMware Solution.
Azure NetApp Files Almacenamiento de archivos de empresa con tecnología de

NetApp. Ejecute cargas de trabajo de archivos de Windows y
Linux en Azure.
Oracle en Azure Ejecute las bases de datos de Oracle y las aplicaciones

empresariales en Azure y en la infraestructura en la nube de
Oracle.
Cray en Azure Informática de alto rendimiento con Cray en Azure. Un

superequipo dedicado en la red virtual.
VDI
Traslado de una instancia local de Servicios de Escritorio En este artículo se muestra cómo migrar una instancia de
remoto a Windows Virtual Desktop en Azure Servicios de Escritorio remoto local a Windows Virtual
Desktop en Azure.
Escalado de una migración

Escalado de una migración a Azure En este artículo se muestra cómo una organización de
ejemplo se prepara para escalar a una migración completa a
Azure.
Aplicaciones de demostración
En los artículos de ejemplo que se proporcionan en esta sección se usan dos aplicaciones de demostración:
SmartHotel360 y osTicket.
Smar tHotel360 : Microsoft desarrolló esta aplicación de prueba para usarla al trabajar con Azure. Se
proporciona con una licencia de código abierto y se puede descargar desde GitHub. Se trata de una aplicación
ASP.NET conectada a una base de datos de SQL Server. En los escenarios que se describen en estos artículos, la
versión actual de esta aplicación está implementada en dos máquinas virtuales de VMware que ejecutan
Windows Server 2008 R2 y SQL Server 2008 R2. Estas máquinas virtuales de la aplicación se hospedan en el
entorno local y las administra vCenter Server.
osTicket : esta aplicación de consola de servicio de código abierto para incidencias se ejecuta en Linux. Puede
descargarlo en GitHub. En los escenarios que se describen en estos artículos, la versión actual de esta aplicación
se implementa de manera local en dos máquinas virtuales de VMware que ejecutan Ubuntu 16.04 LTS, con
Apache 2, PHP 7.0 y MySQL 5.7.
Rehospedaje de una aplicación local en máquinas
virtuales de Azure mediante Azure Migrate
En este artículo se muestra cómo la compañía ficticia Contoso rehospeda una aplicación de front-end de
Windows .NET de dos niveles que se ejecuta en máquinas virtuales de VMware mediante la migración de las VM
de la aplicación a VM de Azure.
SmartHotel360, la aplicación usada en este ejemplo, se proporciona como software de código abierto. Si quiere
utilizarla para sus propias pruebas, puede descargarla desde GitHub.

El equipo directivo de TI ha trabajado estrechamente con sus socios comerciales para comprender lo quieren
lograr con esta migración. Quieren:
Abordar el crecimiento del negocio. Contoso está creciendo y, como resultado, sus sistemas locales e
infraestructura están bajo presión.
Limitar el riesgo. La aplicación SmartHotel360 es fundamental para el negocio de Contoso. La empresa
quiere mover la aplicación a Azure sin ningún riesgo.
Extensión. Contoso no quiere modificar la aplicación, pero quiere asegurarse de que esta sea estable.
El equipo de la nube de Contoso ha establecido los objetivos de esta migración. Estos objetivos se utilizan para
determinar el mejor método de migración:
Después de la migración, la aplicación de Azure debería tener las mismas funcionalidades de rendimiento
que tiene actualmente en VMware. La aplicación seguirá siendo tan imprescindible en la nube como lo es en
el entorno local.
Aunque esta aplicación es importante para Contoso, la empresa no desea invertir en ella en este momento.
Contoso desea migrar la aplicación de forma segura a la nube en su forma actual.
Contoso no quiere cambiar el modelo de operaciones de esta aplicación. Lo que quiere es interactuar con ella
en la nube de la misma manera que lo hace ahora.
Contoso no quiere cambiar la funcionalidad de la aplicación. Solo cambiará su ubicación.
Diseño de la solución
Después de establecer los objetivos y requisitos, Contoso diseña y revisa una solución de implementación.
También identifica el proceso de migración, incluidos los servicios de Azure que se usarán para la migración.
Aplicación actual
La aplicación se divide en niveles entre dos VM ( WEBVM y SQLVM ).
Las máquinas virtuales se encuentran en el host de VMware ESXi contosohost1.contoso.com (versión 6.5).
El entorno de VMware se administra con vCenter Server 6.5 ( vcenter.contoso.com ) que se ejecuta en una
máquina virtual.
Contoso tiene un centro de datos local ( contoso-datacenter ) con un controlador de dominio local (
contosodc1 ).
Arquitectura propuesta
Dado que la aplicación es una carga de trabajo de producción, las VM de la aplicación en Azure residirán en
el grupo de recursos de producción ContosoRG .
Las VM de la aplicación se migrarán a la región primaria de Azure (Este de EE. UU. 2) y se colocarán en la red
de producción ( VNET-PROD-EUS2 ).
La VM front-end web residirá en la subred front-end ( PROD-FE-EUS2 ), en la red de producción.
La VM de base de datos residirá en la subred de base de datos ( PROD-DB-EUS2 ), en la red de producción.
Las VM locales del centro de datos de Contoso se retirarán después de realizar la migración.
Consideraciones sobre la base de datos

Como parte del proceso de diseño de la solución, Contoso hizo una comparación de características entre Azure
SQL Database y SQL Server. Las siguientes consideraciones ayudaron a la empresa a decidirse por una máquina
virtual de IaaS de Azure que ejecuta SQL Server:
El uso de una máquina virtual de Azure que ejecuta SQL Server parece ser una solución óptima si Contoso
necesita personalizar el sistema operativo y la base de datos, o colocar y ejecutar aplicaciones de terceros en
la misma máquina virtual.
Con Software Assurance, Contoso puede intercambiar sus licencias existentes para obtener descuentos en
una instancia de SQL Managed Instance con la Ventaja híbrida de Azure para SQL Server. Con esto, podrá
ahorrar hasta un 30 % en SQL Managed Instance.
Revisión de la solución
Contoso evalúa el diseño propuesto y crea una lista de ventajas y desventajas.
C O N SIDERA C IÓ N DETA L L ES
Ventajas Las dos máquinas virtuales de aplicaciones se moverán a

Azure sin cambios, de forma que se simplifica la migración.
Dado que Contoso usa un enfoque lift-and-shift para ambas

máquinas virtuales de aplicaciones, no se necesitan
herramientas de configuración ni de migración especiales
para la base de datos de aplicación.
Contoso puede aprovechar su inversión en

Software Assurance si usa la Ventaja híbrida de Azure.
Contoso conservará el control total de las VM de la

aplicación en Azure.
Desventajas WEBVM y SQLVM ejecutan Windows Server 2008 R2. Azure

admite el sistema operativo para roles específicos. Más
información.
Las capas de datos y web de la aplicación siguen siendo un

único punto de error.
SQLVM se está ejecutando en SQL Server 2008 R2.

SQL Server 2008 R2 ya no tiene soporte estándar, pero es
compatible con las máquinas virtuales de Azure. Más
información.
Contoso debe seguir admitiendo la aplicación en las

máquinas virtuales de Azure, en lugar de cambiar a un
servicio administrado, como Azure App Service o Azure SQL
Database.
Proceso de migración
Contoso migrará el front-end de aplicaciones y las máquinas virtuales de la base de datos a las máquinas
virtuales de Azure mediante el método sin agente de Azure Migrate: Herramienta de migración del servidor.
Como primer paso, contoso prepara y configura componentes de Azure para Azure Migrate: Server
Migration y prepara la infraestructura local de VMware.
La infraestructura de Azure ya está implementada, por lo que Contoso solo tiene que configurar la
replicación de las máquinas virtuales con la herramienta Azure Migrate: Herramienta de migración del
servidor.
Con todo preparado, Contoso puede comenzar a replicar las máquinas virtuales.
Una vez que se haya habilitado la replicación y esta se encuentre en funcionamiento, Contoso migrará la
máquina virtual. Para ello, probará la migración y, si es correcta, la conmutará por error en Azure.
Servicios de Azure
SERVIC IO DESC RIP C IÓ N C O ST E
Azure Migrate: Server Migration El servicio orquesta y administra la Durante la replicación en Azure, se
migración de las aplicaciones y cargas incurre en gastos de Azure Storage.
de trabajo locales, así como las Las VM de Azure se crean e incurren
instancias de máquinas virtuales de en gastos cuando se produce la
Amazon Web Services (AWS) y Google migración y las VM se ejecutan en
Cloud Platform (GCP). Azure. Más información sobre cargos y
precios.
Requisitos previos
Contoso y otros usuarios tienen que cumplir los requisitos previos a continuación en este escenario.
REQ UISITO S DETA L L ES
Suscripción de Azure En un artículo anterior de esta serie, Contoso creó

suscripciones. Si no tiene una suscripción a Azure, cree una
cuenta gratuita.
Si crea una cuenta gratuita, será el administrador de su

suscripción y podrá realizar todas las acciones.
Si usa una suscripción existente y no es el administrador,

solicite al administrador que le asigne permisos de
propietario o colaborador.
Si necesita permisos más específicos, consulte Administración

del acceso de Site Recovery con el control de acceso basado
en rol de Azure.
Infraestructura de Azure Vea cómo Contoso configuró una infraestructura de Azure.
Más información sobre los requisitos previos específicos para

Azure Migrate: Server Migration.
Ser vidores locales Los servidores vCenter locales deberían ejecutar las
versiones 5.5, 6.0, 6.5 o 6.7.
Los hosts ESXi deben ejecutar la versión 5.5, 6.0, 6.5 o 6.7.
Una o más VM VMware se deben ejecutar en el host ESXi.

Pasos del escenario
Los administradores de Contoso ejecutarán la migración de la forma siguiente:
Paso 1: Preparación de Azure para Azure Migrate: Ser ver Migration. Se agrega la herramienta de
migración del servidor al proyecto de Azure Migrate.
Paso 2: Replicación en máquinas vir tuales locales. Se configura la replicación y se comienzan a
replicar las máquinas virtuales en Azure Storage.
Paso 3: Migración de las máquinas vir tuales con Azure Migrate: Ser ver Migration. Se ejecuta una
migración de prueba para garantizar que todo funciona y, luego, se ejecuta una migración completa para
mover las VM a Azure.
Paso 1: Preparación de Azure para Azure Migrate: Server Migration

Para migrar máquinas virtuales a Azure, Contoso necesita una red virtual en la que se encontrarán las máquinas
virtuales de Azure cuando se creen durante la migración. También necesita la herramienta Azure Migrate: Server
Migration (archivo OVA) aprovisionada y configurada.
1. Configure una red. Contoso ya configuró una que se puede usar para Azure Migrate: Server Migration
cuando implementó la infraestructura de Azure.
La aplicación SmartHotel360 es una aplicación de producción, y las máquinas virtuales se migrarán a
la red de producción de Azure ( VNET-PROD-EUS2 ) en la región primaria ( East US 2 ).
Ambas máquinas virtuales se colocarán en el grupo de recursos ContosoRG , que se usa para los
recursos de producción.
La máquina virtual de front-end de aplicaciones ( WEBVM ) se migrará a la subred de front-end (
PROD-FE-EUS2 ), en la red de producción.
La máquina virtual de base de datos de aplicaciones ( SQLVM ) se migrará a la subred de base de datos
( PROD-DB-EUS2 ), en la red de producción.
2. Aprovisione la herramienta Azure Migrate:Server Migration: Herramienta de migración del servidor.
a. Desde Azure Migrate, descargue la imagen de OVA e impórtela en VMware.
b. Inicie la imagen importada y configure la herramienta, incluidos los pasos siguientes:

Configure los requisitos previos.
Dirija la herramienta a la suscripción de Azure.
Configure las credenciales de VMWare vCenter.
Agregue las credenciales basadas en Windows para la detección.

Al completar la configuración, la herramienta tardará un tiempo en mostrar todas las máquinas virtuales.
Cuando este proceso finalice, verá que se rellenan en la herramienta Azure Migrate de Azure.
¿Necesita más ayuda?
Aprenda a configurar la herramienta Azure Migrate: Server Migration.
Preparación de las VM locales
Después de la migración, Contoso quiere conectarse a las VM de Azure y permitir que Azure administre las VM.
Para ello, los administradores de Contoso tienen que realizar los siguientes pasos antes de la migración:
1. Para el acceso a través de Internet:
Habilite RDP o SSH en la VM local antes de la migración.
Se asegura de que se agregan las reglas TCP y UDP para el perfil público .
Compruebe que se permite RDP o SSH en el firewall del sistema operativo.
2. Para el acceso a través de VPN de sitio a sitio:
En Windows, establezca en OnlineAll la directiva de SAN del sistema operativo de la máquina virtual
local.
3. Instale el agente de Azure Windows.
Otras consideraciones:
Para Windows, no debe haber actualizaciones de Windows pendientes en la máquina virtual cuando se
desencadene una migración. Si las hay, los administradores no podrán iniciar sesión en la máquina virtual
hasta que se completen las actualizaciones.
Después de la migración, los administradores pueden comprobar los diagnósticos de arranque para ver
una captura de pantalla de la máquina virtual. Si no funciona, debe comprobar que la máquina virtual está
en ejecución, así como revisar las sugerencias de solución de problemas.
Más información sobre cómo preparar las máquinas virtuales para la migración.
Paso 2: Replicar máquinas virtuales locales
Antes de que los administradores de Contoso puedan ejecutar una migración a Azure, tienen que configurar y
habilitar la replicación.
Una vez completada la detección, se puede comenzar la replicación de máquinas virtuales de VMware en Azure.
1. En el proyecto de Azure Migrate, vaya a Ser vidores > Azure Migrate: Ser ver Migration . A
continuación, seleccione Replicar .
2. En Replicar > Configuración de origen > ¿Las máquinas están vir tualizadas? , seleccione Sí, con
VMware vSphere .
3. En Dispositivo local , seleccione el nombre del dispositivo de Azure Migrate que configuró y, a
continuación, seleccione Aceptar .
4. En Máquinas vir tuales , seleccione las máquinas que quiere replicar.
Si ha ejecutado una evaluación para las máquinas virtuales, puede aplicar las recomendaciones de
tamaño y tipo de disco (Premium o estándar) de máquina virtual que sugieren los resultados de dicha
evaluación. Para ello, en ¿Quiere impor tar la configuración de migración de evaluación de
Azure Migrate? , seleccione la opción Sí .
Si no ha ejecutado una evaluación o no desea usar la configuración de la evaluación, seleccione la
opción No .
Si ha decidido usar la evaluación, seleccione el grupo de máquinas virtuales y el nombre de la
evaluación.
5. En Máquinas vir tuales , busque las máquinas virtuales que necesite y compruebe todas las que desee
migrar. Después, seleccione Next: Configuración de destino .
6. En Configuración de destino , seleccione la suscripción y la región de destino a la que migrará. A
continuación, especifique el grupo de recursos en el que residirán las máquinas virtuales de Azure
después de la migración. En Red vir tual , seleccione la red virtual o la subred de Azure a la que se unirán
las máquinas virtuales de Azure después de la migración.
7. En Ventaja híbrida de Azure :
Seleccione No si no desea aplicar la Ventaja híbrida de Azure. Luego, seleccione Siguiente .
Seleccione Sí si tiene equipos con Windows Server que están incluidos en suscripciones activas de
Software Assurance o Windows Server y desea aplicar el beneficio a las máquinas que va a migrar.
Luego, seleccione Siguiente .
8. En Proceso , revise el nombre de la máquina virtual, su tamaño, el tipo de disco del sistema operativo y el
conjunto de disponibilidad. Las máquinas virtuales deben cumplir los requisitos de Azure.
Tamaño de VM: si usa las recomendaciones de la evaluación, la lista desplegable de tamaño de
máquina virtual contendrá el tamaño recomendado. De lo contrario, Azure Migrate elige un tamaño
en función de la coincidencia más cercana en la suscripción de Azure. También puede elegir un
tamaño de manera manual en Tamaño de la máquina vir tual de Azure .
Disco del sistema operativo : especifique el disco del sistema operativo (arranque) de la máquina
virtual. El disco de sistema operativo tiene el cargador de arranque y el instalador del sistema
operativo.
conjunto de disponibilidad: si la máquina virtual debe estar incluida en un conjunto de
disponibilidad de Azure después de la migración, especifique el conjunto. El conjunto debe estar en el
grupo de recursos de destino que especifique para la migración.
9. En Discos , especifique si los discos de la máquina virtual se deben replicar en Azure y seleccione el tipo
de disco (discos SSD o HDD estándar, o bien discos administrados prémium) en Azure. Luego, seleccione
Siguiente .
Puede excluir discos de la replicación. Si excluye discos, no estarán presentes en la máquina virtual de
Azure después de la migración.
10. En Revisar e iniciar la replicación , revise la configuración y, a continuación, seleccione Replicar para
iniciar la replicación inicial de los servidores.
NOTE
Puede actualizar la configuración de replicación en cualquier momento antes de que esta comience; para ello, vaya a
Administrar > Replicación de máquinas . Una vez iniciada la replicación, su configuración no se puede cambiar.
Paso 3: Migración de las máquinas virtuales con Azure Migrate: Server

Migration
Los administradores de Contoso ejecutan una migración de prueba rápida y, a continuación, una migración para
migrar las máquinas virtuales.
Ejecutar una migración de prueba
1. En Objetivos de migración > Ser vidores > Azure Migrate: Ser ver Migration , seleccione Probar
ser vidores migrados .
2. Mantenga presionada o haga clic con el botón derecho en la máquina virtual que va a probar y, a
continuación, seleccione Migración de prueba .
3. En Migración de prueba , seleccione la red virtual de Azure en la que se ubicará la máquina virtual de
Azure después de la migración. Se recomienda que use una red virtual que no sea de producción.
4. Comienza el trabajo de Migración de prueba . Supervise el trabajo en las notificaciones del portal.
5. Una vez finalizada la migración, la máquina virtual de Azure migrada se puede ver en Máquinas
vir tuales en Azure Portal. El nombre de la máquina tiene un sufijo -Test .
6. Una vez finalizada la prueba, mantenga presionada o haga clic con el botón derecho en la máquina
virtual de Azure, en Replicación de máquinas y seleccione Limpiar la migración de prueba .
Migrar las VM
Ahora, los administradores de Contoso ejecutan una migración completa.
1. En el proyecto de Azure Migrate, seleccione Ser vidores > Azure Migrate: Ser ver Migration >
Replicando ser vidores .
2. En Replicación de máquinas , mantenga presionada o haga clic con el botón derecho en la máquina
virtual y seleccione Migrar .
3. En Migrar > ¿Quiere apagar las máquinas vir tuales y realizar una migración planificada sin
perder datos? , seleccione Sí > Aceptar .
De forma predeterminada, Azure Migrate apaga la máquina virtual local y ejecuta una replicación a
petición para sincronizar los cambios que se han producido en la máquina virtual desde la última
replicación. De esta forma se garantiza que no se pierden datos. Si no desea apagar la VM, seleccione No .
4. Se inicia un trabajo de migración de la máquina virtual. Realice un seguimiento del trabajo en las
notificaciones de Azure.
5. Una vez finalizado el trabajo, la máquina virtual puede ver y administrar desde la página Máquinas
vir tuales .
Más información sobre cómo ejecutar una migración de prueba.
Más información sobre cómo migrar máquinas virtuales a Azure.
Limpiar después de la migración

Al finalizar la migración, las capas de la aplicación SmartHotel360 ahora se ejecutan en VM de Azure.
Ahora, Contoso debe realizar estos pasos de limpieza:
Una vez completada la migración, detenga la replicación.
Quite la máquina WEBVM del inventario de vCenter.
Quite la máquina SQLVM del inventario de vCenter.
Quite WEBVM y SQLVM de los trabajos de copia de seguridad locales.
Actualice la documentación interna para mostrar la nueva ubicación y las direcciones IP de las máquinas
virtuales.
Revisar los recursos que interactúan con las VM y actualizar las opciones de configuración pertinentes o la
documentación para reflejar la nueva configuración.
Revisión de la implementación
Con la aplicación en ejecución, Contoso debe hacer que sea totalmente operativa y protegerla en Azure.
Seguridad
El equipo de seguridad de Contoso revisa las máquinas virtuales de Azure para determinar si existe algún
problema de seguridad. Para controlar el acceso, el equipo revisa los grupos de seguridad de red de las
máquinas virtuales. Los NSG se usan para garantizar que solo el tráfico permitido pueda comunicarse con la
aplicación. El equipo también tiene en cuenta la protección de los datos en el disco con Azure Disk Encryption y
Key Vault.
Para obtener más información, consulte Procedimientos de seguridad recomendados para cargas de trabajo de
IaaS de Azure.

Para la continuidad empresarial y la recuperación ante desastres, Contoso realiza las siguientes acciones:
Mantener seguros los datos: Contoso realiza la copia de seguridad de los datos de las máquinas virtuales
mediante Azure Backup.
Mantener las aplicaciones en funcionamiento: Contoso replica las máquinas virtuales de aplicaciones en
Azure en una región secundaria mediante Azure Site Recovery.
Optimización de los costos y licencias
Actualmente, Contoso tiene licencia para las máquinas virtuales existentes y aprovechará la Ventaja híbrida de
Azure. Contoso convertirá las máquinas virtuales de Azure existentes para aprovechar las ventajas que ofrecen
estos precios.
Contoso habilitará Azure Cost Management + Billing para ayudar a supervisar y administrar los recursos de
Azure.
Conclusión
En este artículo, Contoso ha rehospedado la aplicación SmartHotel360 en Azure. Los administradores migraron
las máquinas virtuales de la aplicación a las máquinas virtuales de Azure mediante Azure Migrate: Herramienta
de migración del servidor. También puede revisar los proyectos de Azure DevOps publicados en el Generador de
demos de Azure DevOps. Una vez en el generador, descargue el proyecto de migración de servidor en la barra
de navegación de Cloud Adoption Framework.
Migración de bases de datos de SQL Server en
Azure
En este artículo se muestra cómo una empresa ficticia, Contoso, evaluó, planificó y migró sus diversas bases de
datos de SQL Server locales a Azure.
equipo de Contoso quiere valorar la compatibilidad de las máquinas y bases de datos para la migración.
Además, desea calcular la capacidad y los costos de ejecutar los recursos de Contoso en Azure.

Contoso tiene varios problemas para mantener toda la gama de versiones de cargas de trabajo de SQL Server
que existen en su red. Después de la reunión más reciente de los inversores, el director financiero y el director
de tecnología han tomado la decisión de mover todas estas cargas de trabajo a Azure. Esto les permitirá cambiar
de un modelo de gastos de capital estructurados a un modelo de gastos operativos fluidos.
El equipo directivo de TI ha trabajado estrechamente con sus socios comerciales para comprender los requisitos
técnicos y de negocio:
Aumentar la seguridad: Contoso debe ser capaz de supervisar y proteger todos los recursos de datos
de forma más rápida y eficaz. También les gustaría obtener una configuración más centralizada del
sistema de informes en los patrones de acceso a las bases de datos.
Optimizar los recursos de proceso: Contoso ha implementado una enorme infraestructura de
servidores locales. Tienen varias instancias de SQL Server que consumen, pero no usan realmente la
CPU, la memoria y el disco subyacentes asignados de forma eficaz.
Aumentar la eficacia: Contoso debe quitar procedimientos innecesarios y optimizar los procesos para
sus desarrolladores y usuarios. La empresa necesita que el departamento de TI sea rápido y no malgaste
tiempo ni dinero a fin de satisfacer más rápidamente los requisitos del cliente. Después de migrar la
aplicación, las tareas administrativas de las bases de datos deberían reducirse o minimizarse.
Aumentar la agilidad: el equipo de TI de Contoso necesita más capacidad de respuesta a las
necesidades de la empresa. Debe poder reaccionar con más rapidez que los cambios del mercado para
facilitar el éxito en una economía global. No se debe interponer en el camino ni bloquear el negocio.
Escalado: a medida que el negocio crece satisfactoriamente, el equipo de TI de Contoso debe
proporcionar sistemas que puedan crecer al mismo ritmo. Hay varios entornos de hardware heredados
que no se pueden actualizar más allá y se encuentran al final del soporte técnico o ya lo han superado.
Costos: Los propietarios de aplicaciones y negocios quieren saber que no quedarán atrapados por altos
costos de la nube en comparación con la ejecución de las aplicaciones en el entorno local.
El equipo de la nube de Contoso ha establecido los objetivos de las distintas migraciones. Estos objetivos se
usaron para determinar los mejores métodos de migración.
Rendimiento Tras la migración, las aplicaciones de Azure deben tener las

mismas funcionalidades de rendimiento que las que tienen
actualmente en el entorno local de Contoso. Pasar a la nube
no significa que el rendimiento de las aplicaciones sea menos
crítico.
Compatibilidad Contoso debe comprender la compatibilidad de sus

aplicaciones y bases de datos con Azure. Además, Contoso
debe comprender las opciones de hospedaje de Azure.
Orígenes de datos Todas las bases de datos se moverán a Azure sin

excepciones. Según el análisis de bases de datos y
aplicaciones de las características de SQL que se usen, se
moverán a PaaS, IaaS o instancias administradas. Todas las
bases de datos deben moverse.
Aplicación Las aplicaciones deben moverse a la nube siempre que sea

posible. Si no pueden moverse, se les permitirá conectarse a
la base de datos migrada por medio de la red de Azure a
través de conexiones privadas únicamente.
Costos Contoso quiere comprender no solo las opciones de

migración, sino también los costos asociados con la
Administración Deben crearse grupos de administración de recursos para los

distintos departamentos junto con grupos de recursos para
administrar todas las bases de datos SQL que se migran.
Todos los recursos deben etiquetarse con información de
departamento para los requisitos de contracargo.
Limitaciones En un principio, no todas las sucursales que ejecutan

aplicaciones tendrán un vínculo directo de ExpressRoute a
Azure, por lo que estas oficinas deberán conectarse a través
de puertas de enlace de redes virtuales.
Contoso ya ha realizado una evaluación de la migración de su patrimonio digital mediante Azure Migrate.
La valoración genera varias cargas de trabajo distribuidas en varios departamentos. El tamaño total del proyecto
de migración requerirá una oficina de administración de proyectos (PMO) completa para administrar los
detalles de la comunicación, los recursos y la planificación de la programación.
Contoso evalúa el diseño propuesto creando una lista de ventajas y desventajas.
Ventajas Azure proporcionará un único panel para visualizar las cargas

de trabajo de base de datos.
Los costos se supervisarán mediante Azure Cost

La facturación de los contracargos de negocio será fácil de

llevar a cabo con las API de facturación de Azure.
El mantenimiento de servidores y software se reducirá

únicamente a los entornos basados en IaaS.
Desventajas Debido al requisito de las máquinas virtuales basadas en

IaaS, todavía será necesario administrar el software en esas
máquinas.
Presupuesto y administración
Antes de que se pueda realizar la migración, es necesario disponer de la estructura de Azure necesaria para
admitir los aspectos de administración y facturación de la solución.
En cuanto a los requisitos de administración, se crearon varios grupos de administración para admitir la
estructura organizativa.
En cuanto a los requisitos de facturación, cada uno de los recursos de Azure se etiqueta luego con las etiquetas
de facturación adecuadas.
Las migraciones de datos siguen un patrón estándar repetible. Esto implica los pasos siguientes en función de
los procedimientos recomendados de Microsoft:
Antes de la migración:
Detección: Inventaríe los recursos de base de datos y pila de aplicaciones.
Evaluación: Evalúe las cargas de trabajo y corrija las recomendaciones.
Conversión: Convierta el esquema de origen para que funcione en el destino.
Migración:
Migración: Migre el esquema de origen, los datos de origen y los objetos al destino.
Sincronización de datos: Sincronice los datos (para un tiempo de inactividad mínimo).
Traslado: Migre todo el origen al destino.
Después de la migración:
Corrección de aplicaciones: Realice de forma iterativa los cambios necesarios en las aplicaciones.
Realización de pruebas: Realice pruebas funcionales y de rendimiento de forma iterativa.
Optimización: En función de las pruebas, solucione los problemas de rendimiento y vuelva a realizar
las pruebas para confirmar las mejoras en el rendimiento.
Retiro de recursos: Existen copias de seguridad de las VM y los entornos de hospedaje anteriores y
se han retirado.
Paso 1: Detección
Contoso usó Azure Migrate para exponer las dependencias en el entorno de Contoso. Azure Migrate detectó
automáticamente componentes de aplicación en sistemas Windows y Linux y asignó la comunicación entre
servicios. Azure Migrate también expuso las conexiones entre los servidores de Contoso, los procesos, la
latencia de conexión entrante y saliente, y los puertos a través de su arquitectura conectada por TCP.
Además, Contoso agregó Data Migration Assistant a su proyecto de Azure Migrate. Al seleccionar esta
herramienta, se pueden evaluar las bases de datos para la migración a Azure.
Paso 2: Valoración de aplicaciones

La evaluación ha determinado que Contoso usa principalmente aplicaciones basadas en .NET, aunque algunos
proyectos han usado otras tecnologías, como PHP y Node.js. Los sistemas comprados a proveedores también
han incorporado aplicaciones no basadas en .NET. Contoso ha identificado las aplicaciones siguientes:
~800 aplicaciones .NET de Windows
~50 aplicaciones PHP
25 aplicaciones Node.js
10 aplicaciones Java
Paso 3: Evaluación de la base de datos
A medida que se detectaba cada carga de trabajo de base de datos, se ejecutaba la herramienta Data Migration
Assistant (DMA) para determinar qué características se estaban usando. DMA ayuda a Contoso a evaluar las
migraciones de bases de datos a Azure mediante la detección de problemas de compatibilidad que pueden
afectar a la funcionalidad de la base de datos en una nueva versión nueva de SQL Server o Azure SQL Database.
Contoso siguió estos pasos para evaluar las bases de datos y, a continuación, cargó los datos de resultados en
Azure Migrate:
1. Descarga de DMA.
2. Creación de un proyecto de valoración.
3. En DMA, inicio de sesión en el proyecto de Azure Migrate y sincronización del resumen de valoración.
DMA recomienda mejoras de rendimiento y confiabilidad para el entorno de destino, y le permite migrar el
esquema, los datos y objetos no contenidos desde el servidor de origen al servidor de destino.
Más información sobre Data Migration Assistant
Contoso usó DMA para ejecutar la valoración y, a continuación, cargó los datos directamente en Azure Migrate.
Con la información de base de datos ahora cargada en Azure Migrate, Contoso ha identificado más de
1000 instancias de base de datos que se deben migrar. De estas instancias, aproximadamente el 40 % puede
moverse a SQL Database en Azure. El 60 % restante debe moverse a SQL Server que se ejecute en Azure Virtual
Machines o Azure SQL Managed Instance. De ese 60 %, aproximadamente un 10 % requiere un enfoque basado
en máquinas virtuales, y las instancias restantes se moverán a Azure SQL Managed Instance.
Cuando no se pudo ejecutar DMA en un origen de datos, se siguieron las directrices a continuación en las
migraciones de base de datos.
NOTE
Contoso ha detectado varias bases de datos de código abierto durante la fase de evaluación. Por otra parte, se ha
decidido seguir las indicaciones de Migración de bases de datos de código abierto a Azure para el plan de migración.
Paso 4: Planeamiento de la migración

Con la información a mano, Contoso usa las siguientes directrices para determinar qué método de migración se
va a usar para cada base de datos.
USO DE M IGRA C IÓ N
B A SES DE M IGRA C IÓ N SIN TA M A Ñ O GUÍA DE
DEST IN O DATO S DETA L L ES EN L ÍN EA C O N EXIÓ N M Á XIM O M IGRA C IÓ N
Azure SQL SQL Server Estas bases Data BACPAC, bcp 1 TiB Vínculo
Database (solo datos) de datos Migration
(PaaS) simplemente Assistant,
usan tablas, replicación
columnas, transaccional
procedimient
os
almacenados
y funciones
básicos
Instancia SQL Server Estas bases Data BACPAC, bcp, 2 TiB - 8 TiB Vínculo
administrada (característica de datos usan Migration copia de
de Azure SQL s avanzadas) desencadena Assistant, seguridad y
dores y otros replicación restauración
conceptos transaccional nativas
avanzados,
como tipos
.NET
personalizado
s, agentes de
servicio, etc.
USO DE M IGRA C IÓ N
B A SES DE M IGRA C IÓ N SIN TA M A Ñ O GUÍA DE
DEST IN O DATO S DETA L L ES EN L ÍN EA C O N EXIÓ N M Á XIM O M IGRA C IÓ N
SQL Server SQL Server SQL Server Replicación BACPAC, bcp, 4 GiB - 64 TiB Vínculo
en Azure (integraciones debe tener transaccional replicación de
Virtual con características instantáneas,
Machines productos de de SQL copia de
(IaaS) terceros) Managed seguridad y
Instance no restauración
admitidas nativas,
(agentes de conversión de
servicio entre máquina física
instancias, a VM
proveedores
de servicios
criptográficos,
grupos de
búferes,
niveles de
compatibilida
d por debajo
de 100,
creación de
reflejos de
bases de
datos,
FILESTREAM,
PolyBase,
todo lo que
requiera
acceso a
recursos
compartidos
de archivos,
scripts
externos,
procedimient
os
almacenados
extendidos,
etc.) o
software de
terceros
instalado para
admitir las
actividades de
la base de
datos.
Debido al gran número de bases de datos, Contoso ha creado una oficina de administración de proyectos (PMO)
para realizar un seguimiento de cada instancia de migración de bases de datos. Se asignaron el el compromiso y
las responsabilidades a cada equipo negocios y de aplicaciones.
Contoso también llevó a cabo una revisión de preparación de las cargas de trabajo. En esta revisión se
examinaron los componentes de infraestructura, base de datos y red.
Paso 5: Migraciones de prueba
La primera parte de la preparación de la migración implicó una migración de prueba de cada una de las bases
de datos a los entornos de preinstalación. Con el fin de ahorrar tiempo, se generaron scripts para todas las
operaciones de las migraciones y se registraron los intervalos de cada una de ellas. Para acelerar la migración,
se identificaron las operaciones de migración que se podían ejecutar simultáneamente.
Se detectaron los procedimientos de reversión para cada una de las cargas de trabajo de base de datos en caso
de que se produjeran errores inesperados.
En el caso de las cargas de trabajo basadas en IaaS, se configuró con antelación todo el software de terceros
necesario.
Después de la migración de prueba, Contoso pudo usar las diversas herramientas de estimación de costos de
Azure para obtener un panorama más preciso de los costos operativos futuros de la migración.
Paso 6: Migración
En el caso de la migración de producción, Contoso identificó los períodos de tiempo para todas las migraciones
de base de datos y lo que podía ejecutarse de manera suficiente en la ventana de un fin de semana (de la
medianoche del viernes a la medianoche del domingo) con un mínimo de tiempo de inactividad para los
negocios.
En función de los procedimientos de prueba documentados, se ejecutó cada migración a través de scripting
tanto como fue posible, lo que limitaba las tareas manuales con el fin de minimizar los errores.
Si se producía algún error en cualquier migración durante la ventana, se revertía el procedimiento y se volvía a
programar en la siguiente ventana de migración.
Contoso identificó la ventana de archivo para todas las cargas de trabajo de base de datos. A medida que expire
la ventana, se retirarán los recursos de la infraestructura local.
Esto incluye:
Quitar los datos de producción de los servidores locales.
Retirar el servidor de hospedaje cuando expire la última ventana de las cargas de trabajo.
Con los recursos migrados de Azure, Contoso debe proteger la infraestructura nueva y ponerla totalmente en
marcha.
Seguridad
Contoso necesita asegurarse de que las nuevas cargas de trabajo de base de datos de Azure sean seguras.
Más información.
En concreto, Contoso debe revisar las configuraciones de firewall y de red virtual.
Configure Private Link para que todo el tráfico de las bases de datos se mantenga dentro de Azure y la red
local.
Habilite Microsoft Defender for Identity para Azure SQL Database.
Copias de seguridad
Asegúrese de que se hagan copias de seguridad de las bases de datos de Azure mediante la restauración
geográfica. Esto permite usar las copias de seguridad en una región emparejada en caso de una interrupción
regional.
Impor tante: Asegúrese de que el recurso de Azure tenga un bloqueo de recursos para impedir su
eliminación. Los servidores eliminados no se pueden restaurar.
Muchas cargas de trabajo de base de datos de Azure se pueden escalar o reducir verticalmente, por lo que la
supervisión del rendimiento del servidor y de las bases de datos es importante para garantizar que se
satisfagan sus necesidades, pero también para mantener los costos al mínimo.
Tanto la CPU como el almacenamiento tienen costos asociados. Hay varios planes de tarifa entre los que
elegir. Asegúrese de que esté seleccionado el plan de precios adecuado para las cargas de trabajo de datos.
Los grupos elásticos se implementarán para las bases de datos que tengan patrones compatibles de uso de
recursos.
Cada réplica de lectura se factura según el proceso y el almacenamiento seleccionados.
Use la capacidad reservada para ahorrar en costos.
Conclusión
En este artículo, Contoso evaluó, planeó y migró sus cargas de trabajo de Microsoft SQL Server a Azure.
Se ha desarrollado un proyecto de Azure DevOps para que lo estudie durante la migración de SQL; dicho
proyecto se alinea con Cloud Adoption Framework. Este proyecto le guiará en las principales decisiones
necesarias. Seleccione este vínculo para ir al proyecto Azure DevOps.
Rehospedaje de una aplicación local mediante la
migración a máquinas virtuales de Azure y Azure
SQL Managed Instance
En este artículo se muestra cómo la empresa ficticia Contoso migra una aplicación front-end de Windows .NET
de dos niveles que se ejecuta en máquinas virtuales de VMware a una máquina virtual de Azure mediante el
servicio Azure Migrate. También se muestra cómo Contoso migra la base de datos de la aplicación a Azure SQL
Managed Instance.
utilizarla para realizar sus propias pruebas, descárguela en GitHub.

El equipo directivo de TI de Contoso ha trabajado en estrecha colaboración con sus asociados comerciales para
comprender lo que quiere lograr la empresa con esta migración. Quieren:
Abordar el crecimiento del negocio. Contoso está creciendo. Como resultado, ha aumentado la presión
sobre los sistemas locales y la infraestructura de la empresa.
desarrolladores y usuarios. La empresa necesita que el departamento de TI actúe con rapidez y no pierda el
tiempo ni malgaste dinero, para que la empresa pueda satisfacer más rápidamente los requisitos de los
clientes.
de la empresa. Tiene que ser capaz de anticiparse a los cambios que se producen en el mercado para
propiciar el éxito de la empresa dentro de una economía global. No debe ser un obstáculo ni convertirse en
un inhibidor del negocio.
El equipo de la nube de Contoso ha establecido los objetivos de esta migración. La empresa usa los objetivos de
migración para determinar el mejor método de migración.
tiene actualmente en su entorno de VMware local. Pasar a la nube no significa que el rendimiento de las
aplicaciones sea menos crítico.
Contoso no quiere invertir en la aplicación. La aplicación es crítica e importante para la empresa, pero
Contoso solo quiere mover la aplicación en su formato actual a la nube.
Después de migrar la aplicación, las tareas administrativas de la base de datos deberían ser menores.
Contoso no quiere usar Azure SQL Database para esta aplicación. Busca alternativas.
Una vez precisados los objetivos y requisitos, Contoso diseña y revisa una solución de implementación e
identifica el proceso de migración. También se identifican los servicios de Azure que usarán para la migración.
Arquitectura actual
Contoso tiene un centro de datos principal ( contoso-datacenter ). El centro de datos está situado en la ciudad
de Nueva York, al este de Estados Unidos.
Contoso tiene tres sucursales locales más en los Estados Unidos.
(500 megabits por segundo).
Cada una de las sucursales está conectada localmente a Internet mediante conexiones de categoría
empresarial, y con túneles VPN con IPSec hacia el centro de datos principal. Esta configuración permite que
la red entera de Contoso esté conectada de forma permanente, y además optimiza la conectividad a Internet.
virtualización ESXi 6.5 que están administrados por vCenter Server 6.5.
Contoso usa Active Directory para la administración de identidades. Contoso usa servidores DNS en la red
interna.
Contoso tiene un controlador de dominio local ( contosodc1 ).
Los controladores de dominio se ejecutan en las máquinas virtuales de VMware. Los controladores de
dominio de las sucursales locales se ejecutan en servidores físicos.
La aplicación SmartHotel360 se divide en capas en dos máquinas virtuales ( WEBVM y SQLVM ) que se
encuentran en un host de VMware ESXi versión 6.5 ( contosohost1.contoso.com ).
El entorno de VMware se administra con vCenter Server 6.5 ( vcenter.contoso.com ) que se ejecuta en una
máquina virtual.
En este escenario, Contoso quiere migrar su aplicación de viajes local de dos capas como se indica a
continuación:
Se migra la base de datos de la aplicación ( SmartHotelDB ) a una instancia administrada de SQL.
Se migra la máquina virtual WEBVM de front-end a una máquina virtual de Azure.
Las máquinas virtuales locales del centro de datos de Contoso se retirarán cuando finalice la migración.
SQL Database y SQL Managed Instance. Las siguientes consideraciones ayudaron a la empresa a decidirse por
SQL Managed Instance.
El objetivo de SQL Managed Instance es proporcionar casi un 100 % de compatibilidad con la versión de la
instalación local de SQL Server más reciente. Recomendamos SQL Managed Instance para los clientes que
ejecutan SQL Server de forma local o en máquinas virtuales de infraestructura como servicio (IaaS), y que
desean migrar sus aplicaciones a un servicio totalmente administrado con cambios mínimos en el diseño.
Contoso planea migrar un gran número de aplicaciones del en el entorno local a IaaS. Muchas de estas
aplicaciones las proporciona el fabricante de software independiente. Contoso se da cuenta de que el uso de
SQL Managed Instance le ayudará a garantizar la compatibilidad de la base de datos con estas aplicaciones,
en lugar de utilizar SQL Database, que podría no ser compatible.
Contoso puede realizar una migración a SQL Managed Instance mediante lift-and-shift con el servicio Azure
Database Migration Service totalmente automatizado. Con este servicio, Contoso puede reutilizarla para las
migraciones futuras de la base de datos.
SQL Managed Instance admite el Agente SQL Server, un componente importante de la aplicación
SmartHotel360. Contoso necesita esta compatibilidad. Sin ella, tendrá que volver a diseñar los planes de
mantenimiento que requiere la aplicación.
una instancia de SQL Managed Instance con la Ventaja híbrida de Azure para SQL Server. Por esta razón,
Contoso podrá ahorrar hasta un 30 % en SQL Managed Instance.
Instancia administrada de SQL se incluye totalmente en la red virtual, por lo que ofrece un mayor nivel de
aislamiento y seguridad para los datos de Contoso. Contoso puede obtener las ventajas de la nube pública y,
al mismo tiempo, mantener el entorno aislado de la red Internet pública.
SQL Managed Instance admite muchas características de seguridad. Entre estas se incluyen Always
Encrypted, el enmascaramiento dinámico de datos, la seguridad de nivel de fila y la detección de amenazas.
Ventajas WEBVM se moverá a Azure sin cambios, lo que simplifica la

migración.
Instancia administrada de SQL admite los requisitos técnicos

y los objetivos de Contoso.
SQL Managed Instance proporcionará compatibilidad total

con la implementación actual de Contoso, mientras la
empresa deja de usar SQL Server 2008 R2.
Contoso puede aprovechar su inversión en Software

Assurance y usar la Ventaja híbrida de Azure para
SQL Server y Windows Server.
Puede volver a usar Azure Database Migration Service para

futuras migraciones adicionales.
SQL Managed Instance tiene tolerancia a errores integrada

que Contoso no necesita configurar. Esta característica
garantiza que la capa de datos ya no sea un único punto de
error.
Desventajas WEBVM ejecuta Windows Server 2008 R2. Aunque este

sistema operativo es compatible con Azure, ha dejado de ser
una plataforma compatible. Para más información, consulte
Directiva de soporte técnico para productos de Microsoft
SQL Server.
El nivel web sigue siendo un punto único de conmutación

por error en el que WEBVM es la única máquina virtual que
proporciona servicios.
Contoso tendrá que seguir dando soporte al nivel web de la

aplicación como una máquina virtual, en lugar de pasarse a
un servicio administrado, como Azure App Service.
Para la capa de datos, es posible que SQL Managed Instance

no sea la mejor solución si Contoso desea personalizar el
sistema operativo o el servidor de base de datos, o si la
empresa desea ejecutar aplicaciones de terceros junto con
SQL Server. La ejecución de SQL Server en una máquina
virtual IaaS puede proporcionar esta flexibilidad.
Contoso migrará la capas web y de datos de su aplicación SmartHotel360 a Azure mediante estos pasos:
1. Contoso ya tiene su infraestructura de Azure, por lo que solo necesita agregar un par de componentes de
Azure específicos a este escenario.
2. La capa de datos se migrará con Azure Database Migration Service. Este servicio se conecta a la máquina
virtual local con SQL Server mediante una conexión VPN de sitio a sitio entre el centro de datos de
Contoso y Azure. Después, el servicio migra la base de datos.
3. La capa web se migrará con una migración mediante lift-and-shift por medio de Azure Migrate. Este
proceso supone la preparación del entorno local de VMware, la configuración y habilitación de la
replicación y la migración de las máquinas virtuales mediante su conmutación por error a Azure.
Servicios de Azure
Azure Database Migration Service Azure Database Migration Service Obtenga información sobre las
permite migraciones completas de regiones admitidas y los precios de
varios orígenes de base de datos a Azure Database Migration Service.
plataformas de datos de Azure, con un
tiempo de inactividad mínimo.
Instancia administrada de Azure SQL SQL Managed Instance es un servicio El uso de una instancia administrada
de base de datos administrada que de SQL que se ejecute en Azure genera
representa una instancia de cargos en función de la capacidad. Más
SQL Server completamente información acerca de los precios de
administrada en la nube de Azure. Usa SQL Managed Instance.
el mismo código que la versión más
reciente del motor de base de datos de
SQL Server, y tiene las características,
mejoras de rendimiento y
actualizaciones de seguridad más
recientes.
Azure Migrate Contoso usa Azure Migrate para Azure Migrate está disponible sin
evaluar sus máquinas virtuales de costo adicional. Se pueden aplicar
VMware. Azure Migrate valora la cargos según las herramientas (propias
idoneidad de las máquinas para la o de un fabricante de software
migración. Proporciona estimaciones independiente) que decidan usar para
de tamaño y costos para su ejecución la evaluación y la migración. Más
en Azure. información sobre los precios de Azure
Migrate.
Requisitos previos
Contoso y otros usuarios tienen que cumplir los requisitos previos a continuación en este escenario.

Suscripción de Azure Contoso ya ha creado una suscripción en el primer artículo

de esta serie. Si no tiene una suscripción a Azure, cree una
cuenta gratuita.

Si usa una suscripción existente pero no es el administrador

de la misma, solicite al administrador que le asigne permisos
de propietario o colaborador para los recursos o grupos de
recursos necesarios.
Infraestructura de Azure Contoso configura su infraestructura de Azure según se

describe en la infraestructura de Azure para la migración.
Ser vidores locales La versión de la instalación local de vCenter Server debe ser
5.5, 6.0 o 6.5.
Un host ESXi debe ejecutar la versión 5.5, 6.0 o 6.5.
Máquinas vir tuales locales Revise las máquinas Linux que se han aprobado para
ejecutarse en Azure.
Database Migration Ser vice Para Azure Database Migration Service, necesita un
dispositivo de VPN local compatible.
Tiene que poder configurar el dispositivo VPN local. Debe

tener una dirección IPv4 pública de uso externo. Esta
dirección no puede estar situada detrás de un dispositivo
NAT.
Asegúrese de que tiene acceso a la base de datos local de

SQL Server.
Firewall de Windows debe poder acceder al motor de base

de datos de origen. Aprenda a configurar Firewall de
Windows para el acceso al motor de base de datos.
Si hay un firewall delante de la máquina de base de datos,

agregue reglas para permitir el acceso a la base de datos y a
los archivos a través del puerto 445 de SMB.
Las credenciales usadas para conectar con la instancia de

SQL Server de origen y esa instancia de SQL Managed
Instance de destino tienen que ser miembros del rol de
servidor sysadmin.
Es necesario tener un recurso compartido de red en la base

de datos local que Azure Database Migration Service pueda
usar para realizar una copia de seguridad de la base de datos
de origen.
Asegúrese de que la cuenta de servicio que ejecuta la

instancia de SQL Server de origen tenga permisos de
escritura sobre el recurso compartido de red.
Anote un nombre de usuario y una contraseña de Windows

que tengan permisos de control completos sobre el recurso
compartido de red. Azure Database Migration Service
suplanta estas credenciales de usuario para cargar los
archivos de copia de seguridad en el contenedor de Azure
Storage.
El proceso de instalación de SQL Server Express establece el

protocolo TCP/IP en deshabilitado de forma
predeterminada. Asegúrese de que esté habilitado.
Pasos del escenario

A continuación se indica cómo Contoso configura la implementación:
Paso 1: Preparación de una instancia administrada de SQL. Contoso necesita una instancia
administrada existente a la que se migrará la base de datos de SQL Server local.
Paso 2: Preparación de Azure Database Migration Ser vice. Contoso tiene que registrar al proveedor
de migración de base de datos, crear una instancia y, luego, crear un proyecto de Database Migration Service.
Contoso también tiene que configurar un identificador de recursos uniforme (URI) de una firma de acceso
compartido (SAS) para la instancia de Database Migration Service. Un URI de SAS proporciona acceso
delegado a los recursos de la cuenta de almacenamiento de Contoso para que Contoso puede conceder
permisos limitados a los objetos de almacenamiento. Contoso configura un URI de SAS, así Azure Database
Migration Service puede acceder al contenedor de cuenta de almacenamiento en el que el servicio carga los
archivos de copia de seguridad de SQL Server.
Paso 3: Preparación de Azure para Azure Migrate: herramienta Ser ver Migration . Contoso agrega
la herramienta de migración del servidor al proyecto de Azure Migrate.
Paso 4: Preparación del entorno de VMware local para Azure Migrate: Ser ver Migration. Contoso
prepara las cuentas para la detección de máquinas virtuales y prepara la conexión a las máquinas virtuales
de Azure tras la migración.
Paso 5: Replicación de las máquinas vir tuales locales. Contoso configura la replicación y comienza a
replicar las máquinas virtuales en Azure Storage.
Paso 6: Migración de la base de datos mediante Azure Database Migration Ser vice. Contoso
migra la base de datos.
Paso 7: Migración de las máquinas vir tuales con Azure Migrate: Ser ver Migration. Contoso
ejecuta una migración de prueba para garantizar que todo funciona y, luego, ejecuta una migración completa
para mover las máquinas virtuales a Azure.
Paso 1: Preparación de una instancia administrada de SQL

Para configurar una instancia administrada de SQL Contoso necesita una subred que cumpla los requisitos
siguientes:
La subred debe estar dedicada. Tiene que estar vacía. No puede contener ningún otro servicio en la nube. La
subred no puede ser una subred de puerta de enlace.
Una vez creada la instancia administrada, Contoso no debe agregar recursos a la subred.
La subred no puede tener asociado un grupo de seguridad de red.
La subred debe tener una tabla de rutas definida por el usuario. La única ruta asignada debe ser 0.0.0.0/0 ,
con Internet como próximo salto.
Si se especifica un DNS personalizado para la red virtual, es necesario agregar a la lista la dirección IP virtual
168.63.129.16 de las resoluciones recursivas de Azure. Más información sobre cómo configurar un DNS
personalizado para una instancia de SQL Managed Instance.
La subred no puede tener un punto de conexión de servicio (de almacenamiento o SQL) asociado a ella. Los
puntos de conexión de servicio se deben deshabilitar en la red virtual.
La subred tiene que tener como mínimo 16 direcciones IP. Aprenda cómo cambiar el tamaño de la subred de
la instancia administrada.
En el entorno híbrido de Contoso, se requiere la configuración de DNS personalizada. Contoso configura los
valores de DNS para usar uno o varios de los servidores de Azure DNS de la empresa. Más información
sobre la personalización de DNS.
Configurar una red virtual para la instancia administrada
Para configurar la red virtual, los administradores de Contoso:
1. Crean una nueva red virtual ( VNET-SQLMI-EU2 ) en la región primaria ( East US 2 ). Agregan la red virtual
al grupo de recursos ContosoNetworkingRG .
2. Asignan un espacio de direcciones de 10.235.0.0/24 . Garantizan que el intervalo no se solapa con otras
redes de su empresa.
3. Agregan dos subredes a la red:
SQLMI-DS-EUS2 ( 10.235.0.0/25 ).
SQLMI-SAW-EUS2 ( 10.235.0.128/29 ). Esta subred se usa para asociar un directorio a la instancia
administrada.
4. Después de implementar la red virtual y las subredes, emparejan las redes como se indica a continuación:
Se empareja VNET-SQLMI-EUS2 con VNET-HUB-EUS2 (la red virtual del centro de conectividad de
East US 2 ).
Se empareja VNET-SQLMI-EUS2 con VNET-PROD-EUS2 (la red de producción).
5. Establecen una configuración de DNS personalizada. DNS primero apunta a los controladores de
dominio de Azure de Contoso. Azure DNS es secundario. Los controladores de dominio de Azure de
Contoso están ubicados de la manera siguiente:
Ubicados en la subred PROD-DC-EUS2 , en la red de producción East US 2 ( VNET-PROD-EUS2 ).
Dirección de CONTOSODC3 : 10.245.42.4 .
Dirección de CONTOSODC4 : 10.245.42.5 .
Solucionador de Azure DNS: 168.63.129.16 .
Consulte la introducción a SQL Managed Instance.
Aprenda cómo crear una red virtual para una instancia de SQL Managed Instance.
Más información sobre cómo configurar el emparejamiento.
Más información sobre cómo actualizar la configuración de DNS de Azure Active Directory.
Configuración del enrutamiento
La instancia administrada se coloca en una red privada virtual. Contoso necesita una tabla de enrutamiento para
que la red virtual se comunique con el servicio de administración de Azure. Si la red virtual no puede
comunicarse con el servicio que la administra, se vuelve inaccesible.
Contoso tiene en cuenta estos factores:
La tabla de enrutamiento contiene un conjunto de reglas (rutas) que especifican cómo se deben enrutar los
paquetes enviados en la red virtual desde la instancia administrada.
La tabla de enrutamiento se asocia con subredes en las que se implementan instancias administradas. Cada
paquete que sale de una subred se controla en función de la tabla de rutas asociada.
Una subred puede asociarse con una sola tabla de rutas.
No hay ningún cargo adicional por la creación de tablas de redirección en Microsoft Azure.
Para configurar el enrutamiento, los administradores de Contoso siguen estos pasos:
1. Crean una tabla de enrutamiento definida por el usuario en el grupo de recursos ContosoNetworkingRG .
2. Para cumplir los requisitos de SQL Managed Instance, tras implementar la tabla de enrutamiento (
MIRouteTable ), se agrega una ruta que tiene el prefijo de dirección 0.0.0.0/0 . La opción Tipo de
próximo salto está establecida en Internet .
3. Asocian la tabla de enrutamiento con la subred SQLMI-DB-EUS2 (en la red VNET-SQLMI-EUS2 ).

Aprenda cómo configurar rutas para una instancia administrada.
Creación de una instancia administrada
Ahora, los administradores de Contoso pueden aprovisionar una instancia administrada de SQL:
1. Como la instancia administrada da servicio una aplicación empresarial, la instancia administrada se
implementa en la región primaria de la empresa ( East US 2 ). La instancia administrada se agrega al
grupo de recursos ContosoRG .
2. Seleccionan un plan de tarifa y el tamaño de los recursos de tamaño y almacenamiento de la instancia.
Más información acerca de los precios de SQL Managed Instance.
3. Una vez implementada la instancia administrada, aparecen dos nuevos recursos en el grupo de recursos
ContosoRG :
La instancia administrada de SQL.

Un clúster virtual en caso de que Contoso tenga varias instancias administradas.

Aprenda cómo aprovisionar una instancia administrada.
Paso 2: Preparación de una instancia de Azure Database Migration

Service
Para preparar Azure Database Migration Service, los administradores de Contoso tienen que realizar varias
operaciones:
Registrar al proveedor de Database Migration Service en Azure.
Dar a Database Migration Service acceso a Azure Storage para cargar los archivos de copia de seguridad que
se usan para migrar una base de datos. Para proporcionar acceso a Azure Storage, crean un contenedor de
Azure Blob Storage. Generan un identificador URI de SAS para el contenedor de Blob Storage.
Crear un proyecto de Azure Database Migration Service.
Realizan los siguientes pasos:
1. Registran el proveedor de migración de base de datos en su suscripción.
2. Crean un contenedor de Azure Blob Storage. Contoso genera un URI de SAS para que Azure Database
Migration Service pueda acceder a él.
3. Crear una instancia de Azure Database Migration Service.

4. Colocan la instancia de Database Migration Service en la subred PROD-DC-EUS2 de la red virtual
VNET-PROD-DC-EUS2 .
La instancia se coloca ahí porque el servicio tiene que estar en una red virtual que pueda acceder a
la máquina virtual de SQL Server local mediante una puerta de enlace de VPN.
VNET-PROD-EUS2está emparejado con VNET-HUB-EUS2 y puede usar puertas de enlace remotas. La
opción Usar puer tas de enlace remotas garantiza que la instancia pueda comunicarse cuando
sea necesario.

Aprenda a configurar Azure Database Migration Service.
Más información sobre cómo crear y usar SAS.
Paso 3: Preparación de Azure para Azure Migrate: Herramienta Server

Migration
Estos son los componentes de Azure que Contoso necesita para migrar las VM a Azure:
Una red virtual en la que se encontrarán las máquinas virtuales de Azure cuando se creen durante la
migración.
Azure Migrate: Server Migration aprovisionada.
Los administradores de Contoso configuran estos componentes:
1. Configuran una red. Contoso ya configuró una red que se puede usar para Azure Migrate: Server
Migration cuando implementó la infraestructura de Azure.
La máquina virtual de front-end de la aplicación ( WEBVM ) se migrará a la subred de front-end (
PROD-FE-EUS2 ) de la red de producción.
La base de datos de la aplicación ( SQLVM ) se migrará a la subred de base de datos ( PROD-DB-EUS2 ) de
la red de producción.
Paso 4: Preparación del entorno de VMware local para Azure Migrate:

Server Migration
Una red virtual en la que se ubicarán las máquinas virtuales de Azure cuando se creen durante la migración.
La aplicación de Azure Migrate, aprovisionada y configurada.
Los administradores de Contoso configuran estos componentes siguiendo estos pasos:
1. Configuran una red. Contoso ya configuró una red que se puede usar para Azure Migrate: Server
La máquina virtual de front-end de aplicaciones ( WEBVM ) se migrará a la subred de front-end (
La máquina virtual de base de datos de aplicaciones ( SQLVM ) se migrará a la subred de base de datos
( PROD-DB-EUS2 ), en la red de producción.
2. Aprovisionamiento de la aplicación de Azure Migrate.
a. Desde Azure Migrate, descargue la imagen de OVA e impórtela en VMware.
b. Inicie la imagen importada y configure la herramienta siguiendo los pasos a continuación:

a. Configure los requisitos previos.
b. Dirija la herramienta a la suscripción de Azure.
c. Configure las credenciales de VMWare vCenter.
d. Agregue las credenciales basadas en Linux o en Windows para la detección.

3. Una vez configurada, la herramienta tardará algún tiempo en enumerar todas las máquinas virtuales.
Una vez finalizado el proceso, los administradores de Contoso pueden ver las máquinas virtuales
rellenadas en la herramienta de Azure Migrate de Azure.
Aprenda cómo configurar la aplicación de Azure Migrate.
Para ello, los administradores de Contoso tienen que realizar los siguientes pasos antes de la migración:
2. Para el acceso a través de la VPN de sitio a sitio:
local.
3. Instalan el agente de Azure:
Agente Linux de Azure
Agente de Windows de Azure
4. Otras consideraciones:
Para Windows, no debe haber actualizaciones de Windows pendientes en la VM cuando se
desencadene una migración. Si las hay, no podrá iniciar sesión en la máquina virtual hasta que se
completen las actualizaciones.
Después de la migración, se pueden comprobar los diagnósticos de arranque para ver una captura
de pantalla de la VM. Si no funciona, debe comprobar que la máquina virtual está en ejecución, así
como revisar estas sugerencias de solución de problemas.
Aprenda cómo preparar las máquinas virtuales para la migración.

Una vez completada la detección, se puede comenzar la replicación de máquinas virtuales de VMware en Azure.
1. En el proyecto de Azure Migrate, van a Ser vidores > Azure Migrate: Ser ver Migration . A
continuación, seleccionan Replicar .
2. En Replicar > Configuración de origen > ¿Las máquinas están vir tualizadas? , seleccionan Sí,
con VMware vSphere .
3. En Dispositivo local , seleccionan el nombre del dispositivo de Azure Migrate que se configuró y, a
continuación, seleccionan Aceptar .
4. En Máquinas vir tuales , seleccionan las máquinas que quieren replicar:
Si han ejecutado una evaluación para las máquinas virtuales, pueden aplicar las recomendaciones de
tamaño y tipo de disco (Premium/Estándar) de máquina virtual que sugieren los resultados de dicha
evaluación. Para ello, en ¿Quiere impor tar la configuración de migración de evaluación de
Azure Migrate? , seleccionan la opción Sí .
Si no han ejecutado una evaluación o no desean usar la configuración de la evaluación, seleccionan la
opción No .
Si han decidido usar la evaluación, seleccionan el grupo de máquinas virtuales y el nombre de la
evaluación.
5. En Máquinas vir tuales , buscan las máquinas virtuales que necesitan y comprueban todas las que
desean migrar. Luego, seleccionan Siguiente: Configuración de destino .
6. En Configuración de destino , seleccionan la suscripción y la región de destino a la que migrarán.
También especifican el grupo de recursos en el que residirán las máquinas virtuales de Azure después de
la migración. En Red vir tual , seleccionan la red virtual o la subred de Azure a la que se unirán las
máquinas virtuales de Azure después de la migración.
Seleccionan No si no desean aplicar la Ventaja híbrida de Azure. Luego, seleccionan Siguiente .
Seleccionan Sí si tienen equipos con Windows Server que están incluidos en suscripciones activas de
Software Assurance o Windows Server y desean aplicar la ventaja a las máquinas que va a migrar.
Luego, seleccionan Siguiente .
8. En Proceso , revisan el nombre de la máquina virtual, su tamaño, el tipo de disco del sistema operativo y
el conjunto de disponibilidad. Las máquinas virtuales deben cumplir los requisitos de Azure.
Tamaño de VM: si usan las recomendaciones de la evaluación, la lista desplegable de tamaño de
máquina virtual contiene el tamaño recomendado. De lo contrario, Azure Migrate elige un tamaño en
función de la coincidencia más cercana en la suscripción de Azure. También pueden elegir un tamaño
de manera manual en Tamaño de la máquina vir tual de Azure .
Disco del sistema operativo : especifican el disco del sistema operativo (arranque) de la máquina
virtual. Este es el disco que tiene el cargador de arranque y el instalador del sistema operativo.
disponibilidad de Azure después de la migración, especifican el conjunto. El conjunto tiene que estar
en el grupo de recursos de destino que se especifica para la migración.
9. En Discos , especifican si los discos de la máquina virtual se deben replicar en Azure. Después,
seleccionan el tipo de disco (SSD/HDD Estándar o discos administrados Premium) de Azure y seleccionan
Siguiente .
Pueden excluir discos de la replicación.
Si se excluyen discos, no estarán presentes en la máquina virtual de Azure después de la migración.
10. En Revisar + iniciar replicación , revisan la configuración. A continuación, seleccionan Replicar para
NOTE
La configuración de replicación se puede actualizar en cualquier momento antes de que esta comience en Administrar >
Replicación de máquinas . Una vez iniciada la replicación, su configuración no se puede cambiar.
Paso 6: Migración de la base de datos mediante Azure Database

Migration Service
Los administradores de Contoso tienen que crear un proyecto de Database Migration Service y luego migrar la
base de datos.
Creación de un proyecto de Azure Database Migration Service
1. Los administradores crean un proyecto de Database Migration Service. Seleccionan el tipo de servidor de
origen SQL Ser ver y Azure SQL Managed Instance como destino.
2. Se abre el Asistente para migración.

Migración de la base de datos
1. En el Asistente para migración, especifican la máquina virtual de origen en la que se encuentra la base de
datos local. Escriben las credenciales para acceder a la base de datos.
2. Seleccionan la base de datos que se va a migrar ( SmartHotel.Registration ).
3. Como destino, escriben el nombre de la instancia administrada de Azure y las credenciales de acceso.
4. En Nueva actividad > Ejecutar migración , especifican la configuración para ejecutar la migración:
Credenciales de origen y destino.
La base de datos para migrar.
El recurso compartido de red creado en la máquina virtual local. Azure Database Migration Service
lleva las copias de seguridad de origen a este recurso compartido.
La cuenta de servicio que ejecuta la instancia de SQL Server de origen debe tener permisos de
escritura sobre este recurso compartido.
Se debe usar la ruta de acceso del nombre de dominio completo (FQDN) al recurso
compartido.
El URI de SAS que proporciona a Azure Database Migration Service acceso al contenedor de
cuentas de almacenamiento en el que el servicio carga los archivos de copia de seguridad de la
migración.
5. Guardan la configuración de migración y, después, ejecutan la migración.

6. En Introducción , supervisa el estado de la migración.
7. Cuando la migración ha finalizado, comprueban que las bases de datos de destino existen en la instancia
administrada.
Paso 7: Migración de las máquinas virtuales con Azure Migrate: Server

Migration
Los administradores de Contoso ejecutan una migración de prueba rápida y comprueban que la máquina
virtual funciona correctamente. Después, migran la máquina virtual.
1. En Objetivos de migración > Ser vidores > Azure Migrate: Ser ver Migration , seleccionan Probar
2. Los administradores mantienen presionada (o hacen clic con el botón derecho) la máquina virtual que
van a probar y, a continuación, seleccionan Migración de prueba .
3. En Migración de prueba , seleccionan la red virtual de Azure en la que se ubicará la máquina virtual de
Azure después de la migración. Se recomienda utilizar una red virtual que no sea de producción.
4. Comienza el trabajo de Migración de prueba . Los administradores supervisan el trabajo en las
notificaciones del portal.
vir tuales en Azure Portal. El nombre de la máquina tiene el sufijo -Test .
6. Una vez finalizada la prueba, los administradores mantienen presionada (o hacen clic con el botón
derecho) en la máquina virtual de Azure, en Replicación de máquinas y seleccionan Limpiar la
migración de prueba .
Migración de la VM
Ahora, los administradores de Contoso ejecutan una migración completa para completar el traslado.
1. En el proyecto de Azure Migrate, van a Ser vidores > Azure Migrate: Ser ver Migration , y seleccionan
2. En Replicación de máquinas , mantienen presionada (o hacen clic con el botón derecho) la máquina
virtual y seleccionan Migrar .
perder datos? , seleccionan Sí > Aceptar .
replicación. Esta acción garantiza que no se pierdan datos.
Si no desean apagar la máquina virtual, seleccionan No .
4. Se inicia un trabajo de migración de la máquina virtual. Los administradores realizan un seguimiento del
trabajo en las notificaciones de Azure.
5. Una vez finalizado el trabajo, pueden ver y administrar la máquina virtual desde la página Máquinas
vir tuales .
6. Por último, se actualizan los registros DNS de WEBVM en uno de los controladores de dominio de
Contoso.
Actualización de la cadena de conexión
Como último paso del proceso de migración, los administradores de Contoso actualizan la cadena de conexión
de la aplicación para que apunte a la base de datos migrada que se ejecuta en la instancia administrada de SQL.
1. En Azure Portal, seleccionan Configuración > Cadenas de conexión para buscar la cadena de
conexión.
2. Actualizan la cadena con el nombre de usuario y la contraseña de la instancia administrada de SQL.
3. Una vez configurada la cadena, reemplazan la cadena de conexión actual en el archivo web.config de su
aplicación.
4. Después de actualizar el archivo y guardarlo, ejecutan iisreset /restart en una ventana del símbolo del
sistema para reiniciar IIS en WEBVM .
5. Después de reiniciar IIS, la aplicación usa la base de datos que se ejecuta en la instancia administrada de
SQL.
6. En este momento, ya pueden apagar la máquina SQLVM local. La migración ha finalizado.

Más información sobre cómo ejecutar una conmutación por error de prueba.
Más información sobre cómo crear un plan de recuperación.
Más información sobre cómo conmutar por error a Azure.

Una vez terminada la migración, la aplicación SmartHotel360 se ejecuta en una máquina virtual de Azure y la
base de datos de SmartHotel360 está disponible en la instancia administrada de SQL.
Ahora, Contoso tiene que realizar estas tareas de limpieza:
Quitar la máquina WEBVM del inventario de vCenter Server.
Quitar la máquina SQLVM del inventario de vCenter Server.
Quitar WEBVM y SQLVM de los trabajos de copia de seguridad locales.
Actualizar la documentación interna para mostrar la nueva ubicación y la dirección IP de WEBVM .
Quitar SQLVM de la documentación interna. Como alternativa, Contoso puede revisar la documentación para
mostrar SQLVM como eliminada y ya no aparecerá en el inventario de máquinas virtuales.
Revise todos los recursos que interactúan con las máquinas virtuales fuera de servicio. Actualice la
configuración o la documentación pertinentes para que reflejen la nueva configuración.
marcha.
Seguridad
El equipo de seguridad de Contoso comprueba las máquinas virtuales de Azure y la instancia administrada de
SQL para determinar posibles problemas de seguridad de la implementación:
El equipo revisa los grupos de seguridad de red que se usan para controlar el acceso de la máquina
virtual. Los grupos de seguridad de red ayudan a garantizar que solo pueda pasar el tráfico que se
permite para la aplicación.
El equipo de seguridad de Contoso también está pensando en proteger los datos en el disco mediante
Azure Disk Encryption y Azure Key Vault.
El equipo permite la detección de amenazas en la instancia administrada. La detección de amenazas envía
una alerta al sistema del equipo o departamento de seguridad de Contoso para abrir una incidencia si se
detecta una amenaza. Obtenga más información sobre la detección de amenazas para SQL Managed
Instance.
Para más información sobre los procedimientos de seguridad para máquinas virtuales, consulte Procedimientos
de seguridad recomendados para cargas de trabajo de IaaS de Azure.
Mantener seguros los datos. Contoso realiza la copia de seguridad de los datos de las máquinas virtuales
mediante el servicio Azure Backup. Para más información, consulte la introducción a la copia de seguridad de
máquinas virtuales de Azure.
Mantener las aplicaciones en funcionamiento. Contoso replica las máquinas virtuales de aplicaciones
en Azure, en una región secundaria mediante Site Recovery. Para más información, consulte Configuración
de la recuperación ante desastres en una región secundaria de Azure de una máquina virtual de Azure.
Más información. Contoso obtiene más información acerca de cómo administrar SQL Managed Instance,
incluidas las copias de seguridad de la base de datos.
Contoso ya tiene una licencia para WEBVM . Para aprovechar las ventajas de precios con Ventaja híbrida de
Azure, Contoso convierte la máquina virtual de Azure existente.
Contoso usará Azure Cost Management + Billing para que la compañía permanezca dentro de los
presupuestos establecidos por la dirección de TI.
Conclusión
En este artículo, Contoso vuelve a hospedar la aplicación SmartHotel360 en Azure mediante la migración de la
máquina virtual de front-end de aplicaciones a Azure con el servicio Azure Migrate. Contoso migra la base de
datos local a una instancia administrada de SQL mediante Azure Database Migration Service.
Rehospedaje de una aplicación local en VM de
Azure y grupos de disponibilidad Always On de
SQL Server
En este artículo se muestra cómo la compañía ficticia Contoso rehospeda una aplicación de Windows .NET de
dos niveles que se ejecuta en máquinas virtuales (VM) de VMware como parte de una migración a Azure.
Contoso migra la VM de front-end de la aplicación a una VM de Azure, y la base de datos de la aplicación a otra
VM de Azure con SQL Server, que se ejecuta en el clúster de conmutación por error de Windows Server con
grupos de disponibilidad Always On de SQL Server.
utilizarla para realizar sus propias pruebas, descárguela en GitHub.

Abordar el crecimiento del negocio. Contoso está creciendo y, como resultado, los sistemas y la
infraestructura locales están bajo presión.
desarrolladores y usuarios. La empresa necesita que el departamento de TI sea rápido y no gaste tiempo ni
dinero para satisfacer más rápidamente los requisitos del cliente.
de la empresa. Debe poder reaccionar con más rapidez que los cambios del mercado para facilitar el éxito en
una economía global. No debe entorpecer el avance ni ser un obstáculo para la empresa.
Escala. A medida que el negocio crece satisfactoriamente, el equipo de TI de Contoso debe proporcionar
sistemas que crezcan al mismo ritmo.
El equipo de la nube de Contoso ha establecido los objetivos de esta migración. Estos objetivos se usaron para
determinar el mejor método de migración:
que tiene actualmente en VMware. La aplicación seguirá siendo tan imprescindible en la nube como lo es en
el entorno local.
Contoso no quiere invertir en esta aplicación. Es importante para la empresa, pero, en su formato actual,
Contoso solo quiere trasladarla a la nube de forma segura.
La base de datos local de la aplicación ha tenido problemas de disponibilidad. Contoso quiere implementarla
en Azure como un clúster de alta disponibilidad con funcionalidades de conmutación por error.
Contoso quiere actualizar su plataforma actual de SQL Server 2008 R2 a SQL Server 2017.
Contoso no quiere usar Azure SQL Database para esta aplicación y busca alternativas.
Una vez precisados los objetivos y requisitos, Contoso diseña y revisa una solución de implementación e
identifica el proceso de migración. También se identifican los servicios de Azure que usarán para la migración.
Arquitectura actual
La aplicación se divide en niveles entre dos VM ( WEBVM y SQLVM ).
El entorno de VMware se administra con vCenter Server 6.5 ( vcenter.contoso.com ), que se ejecuta en una
máquina virtual.
contosodc1 ).
En este escenario:
Contoso va a migrar el front-end de la aplicación, WEBVM , a una máquina virtual de infraestructura como
servicio (IaaS) de Azure.
La VM de front-end de Azure se implementará en el grupo de recursos ContosoRG (usado con los
recursos de producción).
Se ubicará en la red de producción de Azure ( VNET-PROD-EUS2 ) en la región primaria ( East US 2 ).
La base de datos de la aplicación se migrará a una VM de Azure que ejecute SQL Server.
Se ubicará en la red de base de datos de Azure de Contoso ( PROD-DB-EUS2 ) en la región primaria (
East US 2 ).
Se colocará en un clúster de conmutación por error con Windows Server con dos nodos que usa
grupos de disponibilidad Always On de SQL Server.
En Azure, los dos nodos de VM de SQL Server del clúster se implementarán en el grupo de recursos
ContosoRG .
Los nodos de VM se ubicarán en la red de producción de Azure ( VNET-PROD-EUS2 ) en la región
primaria ( East US 2 ).
Las VM ejecutarán Windows Server 2016 con SQL Server 2017 Enterprise Edition. Contoso no tiene
licencias para este sistema operativo. Usará una imagen de Azure Marketplace que ofrece la licencia
como un cargo con respecto al compromiso de Contrato Enterprise de Azure de la empresa.
A parte de los nombres únicos, ambas máquinas virtuales utilizan la misma configuración.
Contoso implementará un equilibrador de carga interno que escucha el tráfico en el clúster y lo dirige al
nodo de clúster adecuado.
El equilibrador de carga interno se implementará en ContosoNetworkingRG (utilizado para los recursos
de redes).
SQL Database y SQL Server. Las siguientes consideraciones ayudaron a la empresa a decidirse por usar una
máquina virtual de IaaS de Azure que ejecuta SQL Server:
El uso de una VM de Azure que ejecuta SQL Server parece ser una solución óptima si Contoso necesita
personalizar el sistema operativo o el servidor de bases de datos, o si quisiera ubicar conjuntamente y
ejecutar aplicaciones de terceros en la misma VM.
Ventajas WEBVM se moverá a Azure sin cambios, lo que simplifica la

migración.
El nivel de SQL Server se ejecutará en SQL Server 2017 y

Windows Server 2016, que retira el sistema operativo
Windows Server 2008 R2 actual. La ejecución de
SQL Server 2017 hace posibles los requisitos técnicos y los
objetivos de Contoso. Proporciona el 100 % de
compatibilidad en la transición desde SQL Server 2008 R2.

Software Assurance si usa la Ventaja híbrida de Azure.
Una implementación de SQL Server de alta disponibilidad en

Azure proporciona tolerancia a errores, para que el nivel de
datos de la aplicación ya no sea un único punto de error en
la conmutación por error.
Desventajas WEBVM ejecuta Windows Server 2008 R2. El sistema

operativo se admite en Azure para roles específicos (julio de
2018). Para más información, consulte Compatibilidad de
software de Microsoft Server para Azure Virtual Machines.
La capa web de la aplicación sigue siendo un único punto de

conmutación por error.
Contoso debe seguir admitiendo la capa web como una VM

de Azure en lugar de pasar a un servicio administrado, como
Azure App Service.
Con la solución elegida, Contoso debe seguir administrando

dos máquinas virtuales con SQL Server en lugar de pasar a
una plataforma administrada como Azure SQL Managed
Instance. Además, con Software Assurance, Contoso puede
intercambiar sus licencias existentes por descuentos en
Azure SQL Managed Instance.
Servicios de Azure
evaluar sus máquinas virtuales de costo adicional. Se pueden aplicar
idoneidad de las máquinas para la o de un fabricante de software
migración. Proporciona estimaciones independiente) que decidan usar para
de tamaño y costos para su ejecución la evaluación y la migración. Más
en Azure. información sobre los precios de Azure
Migrate.
Los administradores de Contoso migrarán las máquinas virtuales de la aplicación a Azure.
Migrarán la máquina virtual de front-end a una máquina virtual de Azure mediante Azure Migrate:
Primero, prepararán y configurarán los componentes de Azure, y prepararán la infraestructura local
de VMware.
Con todo preparado, podrá empezar a replicar la VM.
Una vez que se haya habilitado la replicación y esté en funcionamiento, la máquina virtual se migra
con Azure Migrate.
Después de comprobar la base de datos, se migrará a un clúster de SQL Server en Azure con Azure
Para empezar, deberán aprovisionar las máquinas virtuales con SQL Server en Azure, configurar el
clúster y un equilibrador de carga interno y configurar los grupos de disponibilidad Always On.
Cuando complete todo esto, podrá migrar la base de datos.
Después de la migración, deberá habilitar los grupos de disponibilidad Always On para la base de datos.
Requisitos previos
Esto es lo que debe hacer Contoso en este escenario.
Suscripción de Azure Contoso ya ha creado una suscripción en un artículo

anterior de esta serie. Si no tiene una suscripción a Azure,
cree una cuenta gratuita.


Infraestructura de Azure Contoso configura la infraestructura de Azure según se


la 5.5, 6.0, 6.5 o 6.7.
Un host ESXi que ejecute la versión 5.5, 6.0, 6.5 o 6.7.
Una o más máquinas virtuales VMware que se ejecuten en el

host ESXi.
Pasos del escenario

Contoso ejecutará la migración de la forma siguiente:
Paso 1: Preparación de un clúster del grupo de disponibilidad Always On de SQL Ser ver. cree un
clúster para implementar dos nodos de máquina virtual de SQL Server en Azure.
Paso 2: Implementación y configuración del clúster. Prepare un clúster de SQL Server en Azure. Las
bases de datos se migran a este clúster existente.
Paso 3: Implementación de Azure Load Balancer. implemente un equilibrador de carga para equilibrar
el tráfico entre los nodos de SQL Server.
Paso 4: Preparación de Azure para Azure Migrate. Cree una cuenta de Azure Storage para almacenar
los datos replicados.
Paso 5: Preparación del entorno de VMware local para Azure Migrate. prepare cuentas para la
instalación del agente y la detección de máquinas virtuales. Prepare las máquinas virtuales locales para que
los usuarios puedan conectarse a las máquinas virtuales de Azure después de la migración.
Paso 6: Replicación de las máquinas vir tuales locales en Azure. habilite la replicación de máquinas
virtuales en Azure.
Paso 7: Migración de la base de datos mediante Azure Database Migration Ser vice. Migre la base
de datos a Azure con Azure Database Migration Service.
Paso 8: Protección de la base de datos con Always On de SQL Ser ver. Cree un grupo de
disponibilidad AlwaysOn para el clúster.
Paso 9: Migración de la máquina vir tual con Azure Migrate. Ejecute una migración de prueba para
asegurarse de que todo funciona de la forma esperada. A continuación, ejecute una migración a Azure
Paso 1: Preparación de un clúster del grupo de disponibilidad

AlwaysOn de SQL Server
Para configurar el clúster, los administradores de Contoso:
1. Crean dos máquinas virtuales con SQL Server mediante la selección de la imagen de
Windows Server 2016 con SQL Server 2017 Enterprise en Azure Marketplace.
2. En el Asistente para crear máquinas vir tuales > Conceptos básicos , se configura:
Nombres de las VM: SQLAOG1 y SQLAOG2 .
Dado que las máquinas son críticas para la empresa, se habilita SSD para el tipo de disco de la
máquina virtual.
Especifican las credenciales de la máquina.
Implementan las máquinas virtuales en la región primaria ( East US 2 ), en el grupo de recursos
ContosoRG .
3. En Tamaño , comienza con D2S v3 instancias para ambas VM. Posteriormente, se escalarán según sea
necesario.
4. En Configuración , realizan las siguientes acciones:
Dado que en estas máquinas virtuales hay bases de datos críticas para la aplicación, se usan discos
administrados.
Coloca las máquinas en la subred de base de datos ( PROD-DB-EUS2 ) de la red de producción (
VNET-PROD-EUS2 ) en la región primaria ( East US 2 ).
Crea un nuevo conjunto de disponibilidad, denominado SQLAOGAVSET , con dos dominios de error y
cinco dominios de actualización.
5. En Configuración de SQL Ser ver , se limita la conectividad de SQL a la red virtual (privada) del puerto
1433 predeterminado. Para la autenticación, se usan las mismas credenciales que en el entorno local (
contosoadmin ).

Más información sobre el aprovisionamiento de una máquina virtual con SQL Server.
Más información sobre la configuración de máquinas virtuales para diferentes SKU de SQL Server.
Paso 2: Implementación y configuración del clúster

Para configurar el clúster, los administradores de Contoso:
1. Configuran una cuenta de Azure Storage para que actúe como testigo en la nube.
2. Agregan las máquinas virtuales con SQL Server en el dominio de Active Directory del centro de datos local
de Contoso.
3. Crean el clúster en Azure.
4. Configuran el testigo en la nube.
5. Habilitan grupos de disponibilidad Always On de SQL.
Configuración de una cuenta de almacenamiento como testigo en la nube
Para configurar un testigo en la nube, Contoso necesita una cuenta de Azure Storage que contendrá el archivo
de blob que se usa para el arbitraje de clúster. La misma cuenta de almacenamiento puede utilizarse para
configurar el testigo en la nube para varios clústeres.
Para crear una cuenta de almacenamiento, los administradores de Contoso:
1. Especifican un nombre reconocible para la cuenta ( contosocloudwitness ).
2. Implementan una cuenta de uso general con LRS.
3. Colocan la cuenta en una tercera región ( South Central US ). La coloca fuera de la región principal y
secundaria para que permanezca disponible durante un error regional.
4. La colocan en el grupo de recursos que contiene los recursos de infraestructura, ContosoInfraRG .
5. Al crear la cuenta de almacenamiento, se generan las claves de acceso principal y secundaria. La clave de
acceso principal es necesaria para crear al testigo en la nube. La clave aparece bajo el nombre de la
cuenta de almacenamiento > Claves de acceso .
Adición de las VM con SQL Server al dominio de Contoso
1. Contoso agrega SQLAOG1 y SQLAOG2 al dominio contoso.com .
2. Los administradores instalan en cada máquina virtual la característica de clúster de conmutación por error
con Windows y las herramientas.
Configuración del clúster
Antes de configurar el clúster, los administradores de Contoso toman una instantánea del disco del sistema
operativo en cada máquina.
1. Ejecutan un script para crear el clúster de conmutación por error con Windows.
2. Después de crear el clúster, comprueban que las máquinas virtuales aparecen como nodos de clúster.
Configuración del testigo en la nube

1. Los administradores de Contoso configuran el testigo en la nube mediante el Asistente para la
configuración de cuórum en el Administrador de clústeres de conmutación por error.
2. En el asistente, se selecciona la opción para crear a un testigo en la nube con la cuenta de
almacenamiento.
3. Después de configurar el testigo en la nube, este aparece en el complemento Administrador de clústeres
de conmutación por error.
Habilitación de Grupos de disponibilidad Always On de SQL Server

Los administradores de Contoso ahora pueden habilitar grupos de disponibilidad Always On:
1. En el Administrador de configuración de SQL Server, se habilita Grupos de disponibilidad Always On
para el servicio SQL Ser ver (MSSQLSERVER) .
2. Reinicia el servicio para que los cambios surtan efecto.
Con los grupos de disponibilidad Always On habilitados, Contoso puede configurar el grupo de disponibilidad
Always On que protegerá la base de datos de SmartHotel360.
Más información sobre el testigo en la nube y sobre cómo configurar una cuenta de almacenamiento
para este.
Obtenga instrucciones acerca de cómo configurar un clúster y crear un grupo de disponibilidad.
Paso 3: Implementación de Azure Load Balancer

Ahora, los administradores de Contoso quieren implementar un equilibrador de carga interno que se ubique
delante de los nodos del clúster. El equilibrador de carga escucha el tráfico y lo dirige al nodo adecuado.
Para crear el equilibrador de carga, los administradores de Contoso:
1. En Azure Portal, seleccionan Redes > Equilibrador de carga y configuran un equilibrador de carga
interno nuevo: ILB-PROD-DB-EUS2-SQLAOG .
2. Colocan el equilibrador de carga en la subred de la base de datos ( PROD-DB-EUS2 ) de la red de producción
( VNET-PROD-EUS2 ).
3. Le asignan una dirección IP estática ( 10.245.40.100 ).
4. Al ser un elemento de redes, implementan el equilibrador de carga en el grupo de recursos de redes
ContosoNetworkingRG .
Una vez implementado el equilibrador de carga interno, los administradores de Contoso deben configurarlo. Se
crea un grupo de direcciones de back-end, configura un sondeo de estado y establece una regla de equilibrio de
carga.
Adición de un grupo de back-end
Para distribuir el tráfico a las máquinas virtuales del clúster, los administradores de Contoso configuran un
grupo de direcciones de back-end que contiene las direcciones IP de las NIC de las máquinas virtuales que van a
recibir tráfico de red del equilibrador de carga.
1. En la configuración del equilibrador de carga del portal, Contoso agrega un grupo de back-end:
ILB-PROD-DB-EUS-SQLAOG-BEPOOL .
2. Los administradores asocian el grupo con el conjunto de disponibilidad SQLAOGAVSET . Las VM del
conjunto ( SQLAOG1 y SQLAOG2 ) se agregan al grupo.
Creación de un sondeo de estado
Para que el equilibrador de carga pueda supervisar el estado de la aplicación, los administradores de Contoso
crean un sondeo de estado. El sondeo agrega o elimina de forma dinámica las máquinas virtuales de la rotación
del equilibrador de carga en función de cómo responden a las comprobaciones de estado.
Para crear el sondeo, los administradores de Contoso:
1. Crean un sondeo de estado en la configuración del equilibrador de carga en el portal:
SQL AlwaysOnEndPointProbe .
2. Lo establecen para supervisar las máquinas virtuales en el puerto TCP 59999.
3. Establecen un intervalo de 5 segundos entre sondeos y un umbral de 2. Si se produce un error en los dos
sondeos, se considerará que el estado de la VM es incorrecto.
Configuración del equilibrador de carga para recibir tráfico
Ahora, los administradores de Contoso configuran una regla del equilibrador de carga para definir cómo se
distribuye el tráfico a las máquinas virtuales.
La dirección IP de front-end controla el tráfico entrante.
El grupo de IP de back-end recibe el tráfico.
Para crear la regla, los administradores de Contoso:
1. Agregan una nueva regla en la configuración del equilibrador de carga en el portal:
SQLAlwaysOnEndPointListener .
2. Establecen un cliente de escucha de front-end para recibir el tráfico entrante del cliente de SQL en el
puerto TCP 1433.
3. Especifican el grupo de back-end al que se enrutará el tráfico y el puerto en el que las máquinas virtuales
escuchan el tráfico.
4. Habilitan la dirección IP flotante (Direct Server Return), que siempre es necesaria para Always On de
SQL Server.
Obtenga información general sobre Azure Load Balancer.
Obtenga información sobre cómo crear un equilibrador de carga.
Paso 4: Preparación de Azure para Azure Migrate

Estos son los componentes de Azure que Contoso necesita para implementar Azure Migrate:
Una red virtual en la que ubicar las máquinas virtuales cuando se migren.
Una cuenta de Azure Storage para almacenar los datos replicados.
Los administradores de Contoso configuran estos componentes:
1. Contoso ya creó una red y una subred que se puede utilizar para Azure Migrate cuando se implementó la
infraestructura de Azure.
La aplicación SmartHotel360 es una aplicación de producción, y WEBVM se migrará a la red de
producción de Azure ( VNET-PROD-EUS2 ) en la región primaria ( East US 2 ).
WEBVM se colocará en el grupo de recursos ContosoRG , que se utiliza para los recursos de producción,
y en la subred de producción ( PROD-FE-EUS2 ).
2. Los administradores de Contoso crean una cuenta de Azure Storage ( contosovmsacc20180528 ) en la región
primaria.
Se utiliza una cuenta de uso general con almacenamiento estándar y replicación LRS.
Paso 5: Preparación del entorno de VMware local para Azure Migrate

Así preparan el entorno local los administradores de Contoso:
Una cuenta en vCenter Server o en el host ESXi de vSphere para automatizar la detección de máquinas
virtuales.
Configuración de la máquina virtual local para que Contoso pueda conectarse a la máquina virtual de Azure
replicada después de la migración.
Preparación de una cuenta de detección automática
Azure Migrate necesita acceso a los servidores de VMware para:
Detectar automáticamente las máquinas virtuales.
Organizar la replicación y la migración.
Se requiere al menos una cuenta de solo lectura. Se necesita una cuenta que pueda ejecutar operaciones
como la creación y eliminación de discos, así como la activación de máquinas virtuales.
Para configurar la cuenta, los administradores de Contoso:
1. Cree un rol en el nivel de vCenter.
2. Asignan a ese rol los permisos necesarios.
Preparación para la conexión a VM de Azure después de la migración
Para ello, los administradores de Contoso realizan las siguientes tareas antes de la migración:
local.
3. Instale el agente de Azure:
Agente Linux de Azure
Agente de Windows de Azure
4. Varios
Para Windows, no debe haber actualizaciones de Windows pendientes en la VM cuando se
desencadene una migración. Si las hay, los administradores de Contoso no podrán iniciar sesión en la
máquina virtual hasta que se complete la actualización.
Después de la migración, puede comprobar los diagnósticos de arranque para ver una captura de
pantalla de la VM. Si no funciona, deben comprobar que la máquina virtual está en ejecución, así
como revisar estas sugerencias de solución de problemas.
Paso 6: Replicar VM locales en Azure

Una vez finalizada la detección, se puede comenzar la replicación de máquinas virtuales de VMware en Azure.
1. En el proyecto de Azure Migrate, seleccionan Ser vidores > Azure Migrate: Migración del ser vidor y
seleccionan Replicar .
2. En Replicar > Configuración de origen > ¿Las máquinas están vir tualizadas? , seleccionan Sí,
con VMware vSphere .
3. En Dispositivo local , seleccionan el nombre del dispositivo de Azure Migrate que se configuró y, a
continuación, seleccionan Aceptar .
4. En Máquinas vir tuales , seleccionan las máquinas que se van a replicar.

Si los administradores de Contoso han ejecutado una evaluación de las máquinas virtuales, pueden
aplicar las recomendaciones de tamaño y tipo de disco (Premium/Estándar) de máquina virtual que
sugieren los resultados de dicha evaluación. En ¿Quiere impor tar la configuración de migración
de evaluación de Azure Migrate? , seleccionan la opción Sí .
Si no han ejecutado una evaluación o no desean usar la configuración de la evaluación, seleccionan la
opción No .
Si han decidido usar la evaluación, seleccionan el grupo de máquinas virtuales y el nombre de la
evaluación.
5. En Máquinas vir tuales , buscan las máquinas virtuales que necesitan y comprueban todas las que
desean migrar. A continuación, seleccionan Agregar : Configuración de destino .
6. En Configuración de destino , seleccionan la suscripción y la región de destino a la que se va a migrar
y especifican el grupo de recursos en el que residirán las máquinas virtuales de Azure después de la
migración. En Red vir tual , seleccionan la red virtual y la subred de Azure a la que se unirán las
máquinas virtuales de Azure después de la migración.
7. En Ventaja híbrida de Azure , los administradores de Contoso:
Seleccionan No si no desean aplicar la Ventaja híbrida de Azure. A continuación, seleccionan
Siguiente .
Seleccionan Sí si tienen equipos con Windows Server que están incluidos en suscripciones activas de
Software Assurance o Windows Server y desean aplicar la ventaja a las máquinas que va a migrar. A
continuación, seleccionan Siguiente .
8. En Proceso , revisan el nombre de la máquina virtual, su tamaño, el tipo de disco del sistema operativo y
el conjunto de disponibilidad. Las máquinas virtuales deben cumplir los requisitos de Azure.
Tamaño de VM: si usan las recomendaciones de la evaluación, la lista desplegable de tamaño de
función de la coincidencia más cercana en la suscripción de Azure. También pueden elegir un tamaño
Disco del sistema operativo : especifican el disco del sistema operativo (arranque) de la máquina
disponibilidad de Azure después de la migración, especifican el conjunto. El conjunto tiene que estar
en el grupo de recursos de destino que se especifica para la migración.
9. En Discos , especifican si los discos de la máquina virtual se deben replicar en Azure. Después,
seleccionan el tipo de disco (SSD/HDD Estándar o discos administrados Premium) de Azure y seleccionan
Siguiente .
Pueden excluir discos de la replicación.
Si se excluyen discos, no estarán presentes en la máquina virtual de Azure después de la migración.
10. En Revisar + iniciar replicación , revisan la configuración. A continuación, seleccionan Replicar para
NOTE
La configuración de replicación se puede actualizar en cualquier momento antes de que esta comience en Administrar >
Replicación de máquinas . Una vez iniciada la replicación, su configuración no se puede cambiar.
Paso 7: Migración de la base de datos mediante Azure Database

Migration Service
Los administradores de Contoso siguen el tutorial de migración paso a paso para migrar la base de datos con
Azure Database Migration Service. Pueden realizar migraciones en línea, sin conexión e híbridas (versión
preliminar).
En resumen, deben realizar las siguientes tareas:
Usar el plan de tarifa Premium para crear una instancia de Azure Database Migration Service que se conecte
a la red virtual.
Asegúrese de que la instancia pueda acceder a la instancia remota de SQL Server a través de la red virtual.
Asegurarse de que todos los puertos de entrada están permitidos desde Azure a SQL Server en el nivel de la
red virtual, la VPN de red y la máquina que hospeda SQL Server.
Configure la instancia:
Cree un proyecto de migración.
Agregue un origen (base de datos local).
Seleccione un destino.
Seleccione las bases de datos que se van a migrar.
Configure las opciones avanzadas.
Inicie la replicación.
Resuelva posibles errores.
Realice la migración final.
Paso 8: Protección de la base de datos con Always On de SQL Server

Una vez que la base de datos de la aplicación se ejecuta en SQLAOG1 , los administradores de Contoso pueden
protegerla ahora con grupos de disponibilidad Always On. Configuran Always On de SQL Server con
SQL Server Management Studio y, a continuación, asignan un cliente de escucha mediante la agrupación en
clústeres de Windows.
Creación de un grupo de disponibilidad Always On
1. En SQL Server Management Studio, selecciona y mantiene presionado (o hace doble clic) en Alta
disponibilidad de Always On para iniciar el Asistente para nuevo grupo de disponibilidad .
2. En Especificar opciones , asigna el nombre SHAOG al grupo de disponibilidad. En Seleccionar bases
de datos , selecciona la base de datos SmartHotel360 .
3. En Especificar réplicas , agregan los dos nodos de SQL como réplicas de disponibilidad y los configuran
para proporcionar la conmutación por error automática con confirmación sincrónica.
4. Configura un agente de escucha para el grupo ( SHAOG ) y el puerto. La dirección IP del equilibrador de
carga interno se agrega como dirección IP estática ( 10.245.40.100 ).
5. En Seleccionar sincronización de datos , permite la inicialización automática. Con esta opción,

SQL Server crea automáticamente las réplicas secundarias para cada base de datos del grupo, por lo que
Contoso no debe realizar manualmente la copia de seguridad ni restaurarla. Después de la validación, se
crea el grupo de disponibilidad.
6. Contoso tuvo un problema al crear el grupo. Dado que no usa la seguridad integrada de Windows de
Active Directory, debe conceder permisos para el inicio de sesión de SQL para crear los roles del clúster
de conmutación por error con Windows.
7. Una vez creado el grupo, aparece en SQL Server Management Studio.

Configuración de un agente de escucha en el clúster
Como último paso en la configuración de la implementación de SQL, los administradores de Contoso
configuran el equilibrador de carga interno como cliente de escucha del clúster y conectan el cliente de escucha.
Utilizan un script para realizar esta tarea.
Comprobar la configuración
Con todo configurado, Contoso ahora tiene un grupo de disponibilidad funcional en Azure que usa la base de
datos migrada. Los administradores comprueban la configuración con una conexión al equilibrador de carga
interno desde SQL Server Management Studio.

Obtenga información acerca de cómo crear un grupo de disponibilidad y un cliente de escucha.
Configure el clúster manualmente para que utilice la dirección IP del equilibrador de carga.
Más información sobre cómo crear y usar SAS.
Paso 9: Migración de la VM con Azure Migrate

Los administradores de Contoso ejecutan una conmutación por error de prueba rápida y, a continuación, migran
la máquina virtual.
La ejecución de una migración de prueba ayuda a garantizar que todo funciona según lo esperado antes de la
migración. Los administradores de Contoso:
1. Ejecutan una conmutación por error de prueba en el punto más reciente en el tiempo disponible (
Latest processed ).
2. Seleccionan Apague la máquina antes de comenzar con la conmutación por error para que
Azure Migrate intente apagar la máquina virtual de origen antes de desencadenar la conmutación por
error. La conmutación por error continúa aunque se produzca un error de cierre.
3. Se ejecuta una conmutación por error de prueba:
Se ejecuta una comprobación de requisitos previos para garantizar que todas las condiciones
necesarias para la conmutación por error están correctamente establecidas.
La conmutación por error procesa los datos, de modo que se pueda crear una máquina virtual de
Azure. Si se selecciona el último punto de recuperación, se crea un punto de recuperación a partir de
los datos.
Se crea una máquina virtual de Azure con los datos procesados en el paso anterior.
4. Una vez finalizada la conmutación por error, la VM de Azure de réplica aparece en Azure Portal. Contoso
comprueba si la VM tiene el tamaño adecuado, si está conectada a la red correspondiente y si se está
ejecutando.
5. Después, limpia la conmutación por error y registra y guarda las observaciones.
Ejecución de la conmutación por error
1. Después de comprobar que la conmutación por error de prueba ha funcionado según lo esperado, crean
un plan de recuperación para la migración y agregan WEBVM al plan.
2. Ejecuta una conmutación por error en el plan. Seleccionan el punto de recuperación más reciente.
Especifican que Azure Migrate debe intentar apagar la máquina virtual local antes de desencadenar la
3. Después de la conmutación por error, Contoso comprueba si la VM de Azure aparece según lo esperado
en Azure Portal.
4. Después de verificar la VM en Azure, completa la migración para finalizar el proceso de migración,
detiene la replicación para la VM y detiene la facturación de Azure Migrate de la VM.
Actualización de la cadena de conexión

de la aplicación para que apunte a la base de datos migrada que se ejecuta en el cliente de escucha SHAOG . Esta
configuración se cambiará en WEBVM , que ahora se ejecuta en Azure. Esta configuración se encuentra en el
archivo web.config de la aplicación ASP.NET.
1. Los administradores de Contoso buscan el archivo en C:\inetpub\SmartHotelWeb\web.config y cambian el
nombre del servidor para que refleje el FQDN del grupo de disponibilidad Always On: shaog.contoso.com
.
2. Después de actualizar el archivo y guardarlo, reinicia IIS en WEBVM . Utilizan iisreset /restart desde un
símbolo del sistema.
3. Después de reiniciar IIS, la aplicación usa la base de datos que se ejecuta en la instancia administrada.
Más información sobre la ejecución de una conmutación por error de prueba.
Más información sobre cómo crear un plan de recuperación.
Más información sobre cómo realizar una conmutación por error en Azure.
Después de la migración, la aplicación SmartHotel360 se ejecuta en una máquina virtual de Azure. La base de
datos SmartHotel360 se encuentra en el clúster de SQL Server de Azure.
Ahora, Contoso debe completar estos pasos de limpieza:
Quitar las VM locales del inventario de vCenter.
Quitar las VM de los trabajos de copia de seguridad locales.
Actualizar la documentación interna para que muestre las nuevas ubicaciones y las direcciones IP de las VM.
Revise todos los recursos que interactúan con las máquinas virtuales fuera de servicio. Actualice la
configuración o la documentación pertinentes para que reflejen la nueva configuración.
Agregar las dos nuevas máquinas virtuales ( SQLAOG1 y SQLAOG2 ) a los sistemas de supervisión de
producción.
marcha.
Seguridad
El equipo de seguridad de Contoso revisa las máquinas virtuales WEBVM , SQLAOG1 y SQLAOG2 para determinar si
existe algún problema de seguridad. El equipo debe:
Revisar los grupos de seguridad de red (NSG) de la máquina virtual para controlar el acceso. Los NSG se
usan para garantizar que solo el tráfico permitido puede pasar a la aplicación.
Considerar la posibilidad de proteger los datos en disco mediante Azure Disk Encryption y Azure Key Vault.
Evaluar el cifrado de datos transparente. A continuación, habilitarlo en la base de datos SmartHotel360 que
se ejecuta en el nuevo grupo de disponibilidad Always On. Más información sobre el cifrado de discos
transparente.
IaaS de Azure.

Para mantener los datos seguros, Contoso hace una copia de seguridad de los datos de las VM WEBVM ,
SQLAOG1 y SQLAOG2 mediante la copia de seguridad de VM de Azure.
Contoso también aprenderá a usar Azure Storage para hacer una copia de seguridad de SQL Server
directamente en Azure Blob Storage. Más información en Uso de Azure Storage para la copia de seguridad y
la restauración de SQL Server.
Para mantener las aplicaciones activas, Contoso replica las máquinas virtuales de la aplicación en Azure en
una región secundaria mediante Site Recovery. Para más información, consulte Configuración de la
recuperación ante desastres en una región secundaria de Azure de una máquina virtual de Azure.
Actualmente, Contoso tiene licencias existentes para su WEBVM y aprovechará la Ventaja híbrida de Azure.
Contoso convertirá las máquinas virtuales de Azure existentes para aprovechar las ventajas que ofrecen
estos precios.
Conclusión
En este artículo, Contoso ha rehospedado la aplicación SmartHotel360 en Azure mediante la migración de la
máquina virtual de front-end de la aplicación a Azure con Azure Migrate. Contoso ha migrado la base de datos
de la aplicación a un clúster de SQL Server aprovisionado en Azure mediante Azure Database Migration Service
y la ha protegido en un grupo de disponibilidad Always On de SQL Server.
Migración de bases de datos de código abierto a
Azure
En este artículo se muestra cómo la empresa ficticia Contoso evaluó, planificó y migró sus diversas bases de
datos de código abierto locales a Azure.
equipo de Contoso quiere valorar la compatibilidad de las máquinas y bases de datos para la migración.
Además, desea calcular la capacidad y los costos de ejecutar los recursos de Contoso en Azure.

Contoso tiene varios problemas para dar mantenimiento a la amplia gama de versiones de cargas de trabajo de
bases de datos de código abierto que existen en su red. Después de la reunión más reciente de los inversores, el
director financiero y el director de tecnología decidieron mover todas estas cargas de trabajo a Azure. Este
movimiento les permitirá cambiar de un modelo de gastos de capital estructurados a un modelo de gastos
operativos fluidos.
El equipo directivo de TI ha trabajado estrechamente con sus socios comerciales para comprender los requisitos
técnicos y de negocio. Quieren:
Aumentar la seguridad. Contoso debe ser capaz de supervisar y proteger todos los recursos de datos de
forma más rápida y eficaz. La empresa también quiere obtener una configuración más centralizada del
sistema de informes en los patrones de acceso a las bases de datos.
Optimizar los recursos de proceso. Contoso ha implementado una enorme infraestructura de servidores
locales. La empresa tiene varias instancias de SQL Server que consumen, pero no usan realmente, la CPU, la
memoria y el disco subyacentes asignados de forma eficaz.
dinero para satisfacer más rápidamente los requisitos del cliente. Después de migrar la aplicación, las tareas
administrativas de las bases de datos deberían reducirse o minimizarse.
Comprender los costos. Los propietarios de aplicaciones y negocios quieren saber que no quedarán
atrapados por altos costos de la nube cuando se ejecutan las aplicaciones en el entorno local.
El equipo de la nube de Contoso ha establecido los objetivos de las distintas migraciones. Estos objetivos se
usaron para determinar los mejores métodos de migración.
Rendimiento Tras la migración, las aplicaciones de Azure deben tener las

mismas funcionalidades de rendimiento que las que tienen
actualmente en el entorno local de Contoso. Pasar a la nube
no significa que el rendimiento de las aplicaciones sea menos
crítico.
Compatibilidad Contoso debe comprender la compatibilidad de sus

aplicaciones y bases de datos con Azure. Además, Contoso
debe comprender las opciones de hospedaje de Azure.
Orígenes de datos Todas las bases de datos se moverán a Azure sin

excepciones. En función del análisis de aplicación y base de
datos de las características SQL que se usan, se moverán a la
plataforma como servicio (PaaS) o a la infraestructura como
servicio (IaaS). Todas las bases de datos deben moverse.
Aplicación Las aplicaciones deben moverse a la nube siempre que sea

posible. Si no pueden moverse, se conectarán a la base de
datos migrada por medio de la red de Azure a través de
conexiones privadas únicamente.
Costos Contoso quiere comprender no solo las opciones de

migración, sino también los costos asociados con la
Administración Debe crear grupos de administración de recursos para los

distintos departamentos junto con grupos de recursos para
administrar todas las bases de datos que se migran. Todos
los recursos se deben etiquetar con información de los
departamentos para los requisitos de contracargo.
Limitaciones Inicialmente, no todas las sucursales que ejecutan

aplicaciones tendrán un vínculo directo de Azure
ExpressRoute a Azure. Estas oficinas deberán conectarse a
través de puertas de enlace de red virtual.
Contoso ya ha realizado una valoración de la migración de su patrimonio digital mediante Azure Migrate.
Ilustración 1: El proceso de migración.

Ventajas Azure proporcionará un único panel para visualizar las cargas

de trabajo de base de datos.
Los costos se supervisarán mediante Azure Cost

La facturación de los contracargos de negocio será fácil de

llevar a cabo con las API de facturación de Azure.
El mantenimiento de servidores y software se reducirá

únicamente a los entornos basados en IaaS.
Desventajas Debido al requisito de las VM basadas en IaaS, todavía será

necesario administrar el software en esas máquinas.
Presupuesto y administración
Antes de que se pueda realizar la migración, es necesario disponer de la estructura de Azure necesaria para
admitir los aspectos de administración y facturación de la solución.
En cuanto a los requisitos de administración, se crearon varios grupos de administración para admitir la
estructura organizativa.
En cuanto a los requisitos de facturación, cada uno de los recursos de Azure se etiqueta luego con las etiquetas
de facturación adecuadas.
Las migraciones de datos siguen un patrón estándar y repetible. Este proceso implica los pasos siguientes en
función de los procedimientos recomendados de Microsoft:
Antes de la migración:
Detección: Inventaríe los recursos de base de datos y pila de aplicaciones.
Evaluación: Evalúe las cargas de trabajo y corrija las recomendaciones.
Conversión: Convierta el esquema de origen para que funcione en el destino.
Migración:
Migración: Migre el esquema de origen, los datos de origen y los objetos al destino.
Sincronización de datos: Sincronice los datos (para un tiempo de inactividad mínimo).
Traslado: Migre todo el origen al destino.
Después de la migración:
Corrección de aplicaciones: Realice de forma iterativa los cambios necesarios en las aplicaciones.
Realización de pruebas: Realice pruebas funcionales y de rendimiento de forma iterativa.
Optimización: En función de las pruebas, solucione los problemas de rendimiento y vuelva a realizar
las pruebas para confirmar las mejoras en el rendimiento.
Retiro de recursos: Existen copias de seguridad de las VM y los entornos de hospedaje anteriores y
se han retirado.
Paso 1: Detección
Contoso usó Azure Migrate para exponer las dependencias en el entorno de Contoso. Azure Migrate puede
detectar automáticamente componentes de aplicación en sistemas Windows y Linux y asignar la comunicación
entre servicios. Azure Migrate también expuso las conexiones entre los servidores de Contoso, los procesos, la
latencia de conexión entrante y saliente, y los puertos a través de su arquitectura conectada por TCP. Contoso
solo debe instalar Microsoft Monitoring Agent y Microsoft Dependency Agent.
Contoso ha identificado más de 300 instancias de base de datos que se deben migrar. De estas instancias,
aproximadamente el 40 % puede moverse a servicios basados en PaaS. El 60 % restante de las instancias deben
moverse a un enfoque basado en IaaS con una máquina virtual que ejecute el software de base de datos
correspondiente.
Paso 2: Evaluación de aplicaciones
Los resultados de la evaluación le mostraron a Contoso que principalmente usa aplicaciones Java, PHP y
Node.js. La empresa identificó las aplicaciones siguientes:
100 aplicaciones de Java
Aproximadamente 50 aplicaciones de Node.js
Aproximadamente 25 aplicaciones de PHP
A medida que se hizo el inventario de las bases de datos, se revisó cada tipo de base de datos para determinar el
método de migración a Azure. Se siguieron las siguientes directrices en las migraciones de base de datos.
T IP O DE B A SE DE DATO S DETA L L ES DEST IN O GUÍA DE M IGRA C IÓ N
MySQL Todas las versiones Azure Database for MySQL Guía

admitidas se actualizan a (PaaS)
una versión compatible
antes de realizar la
migración
PostgreSQL Todas las versiones Azure Database for Guía

admitidas se actualizan a PostgreSQL (PaaS)
migración
MariaDB Todas las versiones Azure Database for Guía

admitidas se actualizan a MariaDB (PaaS)
migración
Paso 4: Planeamiento de la migración

Debido al gran número de bases de datos, Contoso estableció una oficina de administración de proyectos para
realizar un seguimiento de cada instancia de migración de bases de datos. Se asignaron compromisos y
responsabilidades a cada equipo negocios y de aplicaciones.
Contoso también llevó a cabo una revisión de preparación de las cargas de trabajo. En esta revisión se
examinaron los componentes de infraestructura, base de datos y red.
Paso 5: Migraciones de prueba
La primera parte de la preparación de la migración implicó una migración de prueba de cada una de las bases
de datos a los entornos de preinstalación. Parra ahorrar tiempo, Contoso generó scripts para todas las
operaciones de las migraciones y se registraron los intervalos de cada una de ellas. Para acelerar la migración, la
empresa identificó las operaciones de migración que se pueden ejecutar simultáneamente.
Se detectaron los procedimientos de reversión para cada una de las cargas de trabajo de base de datos en caso
de que se produjeran errores inesperados.
En el caso de las cargas de trabajo basadas en IaaS, la empresa configuró con antelación todo el software de
terceros necesario.
Después de la migración de prueba, Contoso usó las diversas herramientas de estimación de costos de Azure
para obtener un panorama más preciso de los costos operativos futuros de la migración.
Paso 6: Migración
En el caso de la migración de producción, Contoso identificó los períodos de tiempo para todas las migraciones
de base de datos y lo que podía ejecutarse de manera suficiente en durante un fin de semana (de la medianoche
del viernes a la medianoche del domingo) con un mínimo de tiempo de inactividad para los negocios.
Contoso identificó la ventana de archivo para todas las cargas de trabajo de base de datos. A medida que expire
la ventana, los recursos dejarán de estar asignados en la infraestructura local. Este proceso incluye la
eliminación de los datos de producción de los servidores locales y la retirada del servidor de hospedaje cuando
expire la última ventana de carga de trabajo.
marcha.
Seguridad
Contoso debe:
Asegurarse de que las cargas de trabajo nuevas de base de datos de Azure sean seguras. Para más
información, consulte el artículo sobre las funcionalidades de seguridad de Azure SQL Database y SQL
Managed Instance.
Revisar las configuraciones de firewall y de red virtual.
Configurar Private Link para que todo el tráfico de las bases de datos se mantenga dentro de Azure y la red
local.
Habilite Microsoft Defender for Identity.
Copias de seguridad
Asegúrese de que se hagan copias de seguridad de las bases de datos de Azure mediante la restauración
geográfica. De esta manera, las copias de seguridad se pueden usar en una región emparejada si se produce
una interrupción regional.
IMPORTANT
Asegúrese de que el recurso de Azure tenga un bloqueo de recursos para impedir su eliminación. No se pueden restaurar
los servidores eliminados.

Muchas cargas de trabajo de bases de datos de Azure se pueden escalar o reducir verticalmente. La
supervisión de rendimiento del servidor y las bases de datos es importante para garantizar que se satisfacen
las necesidades y los costos se mantienen al mínimo.
elegir. Asegúrese de elegir el plan de precios adecuado para las cargas de trabajo de datos.
Cada réplica de lectura se factura en función del proceso y el almacenamiento seleccionados.
Use la capacidad reservada para reducir los costos.
Conclusión
En este artículo, Contoso evaluó, planificó y migró sus bases de datos de código abierto a las soluciones de PaaS
e IaaS de Azure.
Migración de bases de datos de MySQL a Azure
En este artículo se muestra cómo la empresa ficticia Contoso evaluó, planificó y migró sus bases de datos de
código abierto locales de MySQL a Azure.

Aumentar la disponibilidad. Contoso ha tenido problemas de disponibilidad con su entorno local de
MySQL. La empresa requiere que las aplicaciones que usan este almacén de datos sean más confiables.
una economía global. Esto no debe convertirse en un elemento de bloqueo de la empresa.
determinar el mejor método de migración.
Disponibilidad Actualmente, el personal interno tiene dificultades con el

entorno de hospedaje de la instancia de MySQL. Contoso
desea tener un nivel de disponibilidad de la capa de base de
datos que esté cerca del 99,99 %.
Escalabilidad El host de base de datos local se está quedando sin

capacidad rápidamente. Contoso necesita una forma de
escalar sus instancias más allá de las limitaciones actuales o
reducir la escala verticalmente si el entorno empresarial
cambia, para ahorrar costos.
Rendimiento El departamento de recursos humanos de Contoso ejecuta

varios informes diariamente, semanalmente y
mensualmente. Al ejecutar estos informes, experimenta
importantes problemas de rendimiento asociados a la
aplicación orientada a los empleados. Es necesario ejecutar
los informes sin que afecte al rendimiento de la aplicación.
Seguridad Contoso necesita saber que la base de datos solo está

accesible para sus aplicaciones internas, pero no está visible
ni accesible a través de Internet.
Super visión Contoso usa actualmente herramientas para supervisar las

métricas del servidor de bases de datos de MySQL y para
enviar notificaciones cuando la CPU, la memoria o el
almacenamiento tienen problemas. La empresa quiere
disponer de esta misma funcionalidad en Azure.
Continuidad del negocio El almacén de datos de RR. HH. es una parte importante de
las operaciones diarias de Contoso. Si resulta dañado o es
necesario restaurarlo, la empresa desea minimizar el tiempo
de inactividad en la medida de lo posible.
Azure Contoso quiere mover la aplicación a Azure sin ejecutarla en

máquinas virtuales. Contoso quiere usar los servicios de
plataforma como servicio (PaaS) de Azure para la capa de
datos.
Después de precisar los objetivos y requisitos, Contoso diseña y revisa una solución de implementación e
identifica el proceso de migración. También se identifican las herramientas y los servicios que se usarán para la
migración.
Aplicación actual
La base de datos de MySQL hospeda datos de empleados que se utilizan en todos los niveles del Departamento
de RR. HH. de la empresa. Se emplea una aplicación basada en LAMP como front-end para administrar las
solicitudes de RR. HH. a los empleados. Contoso tiene 100 000 empleados en todo el mundo, por lo que el
tiempo de actividad es importante.
Solución propuesta
Use Azure Database Migration Service o migre la base de datos a una instancia de Azure Database for MySQL.
Modificar todas las aplicaciones y procesos para que utilicen la nueva instancia de Azure Database for MySQL.
Como parte del proceso de diseño de la solución, Contoso revisó las características de Azure para hospedar los
datos de MySQL. Las siguientes consideraciones sirvieron a la empresa para decidir utilizar Azure:
Al igual que Azure SQL Database, Azure Database for MySQL permite usar reglas de Firewall.
Azure Database for MySQL puede usarse junto con Azure Virtual Network para evitar que la instancia sea
accesible públicamente.
Azure Database for MySQL cuenta con las certificaciones de privacidad y cumplimiento que Contoso necesita
presentar a sus auditores.
El rendimiento del procesamiento de informes y aplicaciones mejorará mediante el uso de réplicas de
lectura.
Posibilidad de exponer el servicio solo al tráfico de red interno (acceso no público) mediante Azure Private
Link.
Contoso decidió no migrar a Azure Database for MySQL porque están planteándose utilizar en el futuro
MariaDB ColumnStore y el modelo de base de datos de grafos.
Aparte de por las características de MySQL, Contoso es partidario de los proyectos de código abierto
verdaderos y decidió no usar MySQL.
El ancho de banda y la latencia de la aplicación con respecto a la base de datos serán suficientes de acuerdo
con la puerta de enlace elegida (Azure ExpressRoute o VPN de sitio a sitio).
Ventajas Azure Database for MySQL ofrece un contrato de nivel de

servicio con un respaldo financiero del 99,99 % en términos
de alta disponibilidad.
Azure facilita el escalado vertical o la reducción vertical en

épocas de máxima carga en cada trimestre. Contoso puede
ahorrar aún más si compra capacidad reservada.
Azure proporciona funcionalidades de restauración a un

momento dado y de restauración geográfica para Azure
Database for MySQL.
Desventajas Contoso se limita a usar las versiones de lanzamiento de

MySQL que son compatibles con Azure, que son
actualmente la 10.2 y la 10.3.
Azure Database for MySQL tiene algunas limitaciones, como

la reducción vertical del almacenamiento.
Ilustración 1: Arquitectura del

escenario.
Preparación
Antes de migrar las bases de datos de MySQL, debe asegurarse de que esas instancias cumplan todos los
requisitos previos de Azure para que la migración se realice correctamente.
Versiones compatibles
MySQL usa el esquema de versiones x.y.z , donde x es la versión principal, y es la versión secundaria y z
es la versión de revisión.
Azure admite actualmente las versiones 10.2.25 y 10.3.16 de MySQL.
Azure administra automáticamente las actualizaciones de revisiones. Algunos ejemplos son de 10.2.21 a 10.2.23.
Actualmente, no se admiten las actualizaciones de las versiones principales y secundarias. Por ejemplo, no se
admite la actualización de MySQL 10.2 a MySQL 10.3. Si quiere actualizar de la versión 10.2 a la 10.3, realice un
volcado de memoria y restáurela en un servidor creado con la nueva versión del motor.
Red
Contoso tiene que configurar una conexión de puerta de enlace de red virtual desde el entorno local a la red
virtual donde está ubicada la base de datos de MySQL. Esta conexión permitirá que la aplicación local acceda a
la base de datos a través de la puerta de enlace al actualizar las cadenas de conexión.

Migración
preliminar) mediante MySQL 5.6 o 5.7.
NOTE
MySQL 8.0 se admite en Azure Database for MySQL. La herramienta Database Migration Service todavía no admite esa
versión.
En resumen, deben completar las tareas siguientes:

Asegúrese de que se cumplen todos los requisitos previos:
El origen del servidor de bases de datos MySQL debe coincidir con la versión que admite Azure
Database for MySQL. Azure Database for MySQL admite MySQL Community Edition, el motor de
almacenamiento InnoDB y la migración entre origen y destino con las mismas versiones.
Habilite el registro binario en my.ini (Windows) o my.cnf (Unix). Si no se habilita el registro binario,
se produce el siguiente error en el Asistente para migración:
Error in binary logging. Variable binlog_row_image has value 'minimal.' please change it to 'full'.
. Para más información, consulte la documentación de MySQL.
El usuario debe tener el rol ReplicationAdmin .
Migre los esquemas de base de datos sin claves externas ni desencadenadores.
Cree una red virtual que se conecte a través de ExpressRoute o VPN a la red local.
Cree una instancia de Azure Database Migration Service con una SKU Premium que esté conectada a la
red virtual.
Asegúrese de que la instancia pueda acceder a la base de datos de MySQL a través de la red virtual.
Asegúrese de que todos los puertos de entrada estén permitidos desde Azure a MySQL en el nivel de la
red virtual, la VPN de red y la máquina que hospeda MySQL.
Creación de un proyecto de Database Migration Service:
Ilustración 3: Proyecto de Azure Database Migration Service.
Migración mediante herramientas nativas
Como alternativa al uso de Azure Database Migration Service, Contoso puede usar utilidades y herramientas
habituales como MySQL Workbench, mysqldump, Toad o Navicat, para conectarse a los datos y migrarlos a
Azure Database for MySQL.
Volcado y restauración con mysqldump:
Use la opción para excluir desencadenadores de mysqldump para impedir que se ejecuten los
desencadenadores durante la importación y mejorar el rendimiento.
Use la opción de transacción única para establecer el modo de aislamiento de traducción en
REPEATABLE READ y enviar una instrucción SQL START TRANSACTION antes de volcar los datos.
Use la opción para deshabilitar claves de mysqldump para deshabilitar las restricciones de clave
externa antes de la carga. La eliminación de restricciones proporciona mejoras en el rendimiento.
Use Azure Blob Storage para almacenar los archivos de copia de seguridad y realizar la restauración a
partir de ahí para una restauración más rápida.
Actualice las cadenas de conexión de la aplicación.
Después de haber migrado la base de datos, Contoso debe actualizar las cadenas de conexión para
que apunten a la nueva instancia de Azure Database for MySQL.

Después de la migración, Contoso debe realizar una copia de seguridad de la base de datos local con fines de
retención y retirar el servidor de bases de datos local de MySQL.
marcha.
Seguridad
Contoso debe:
Asegurarse de que la nueva instancia de Azure Database for MySQL y las bases de datos estén protegidas.
Para más información, consulte Seguridad en Azure Database for MySQL.
Revisar las configuraciones de firewall y de red virtual.
Configure Private Link para que todo el tráfico de las bases de datos se mantenga dentro de Azure y la red
local.
Copias de seguridad
Asegúrese de que se realiza una copia de seguridad de las instancias de Azure Database for MySQL mediante la
restauración geográfica, de modo que se puedan usar copias de seguridad de una región emparejada si se
produce una interrupción regional.
IMPORTANT
Asegúrese de que el recurso de Azure Database for MySQL disponga de un bloqueo de recursos para impedir su
eliminación. No se pueden restaurar los servidores eliminados.

Azure Database for MySQL se puede escalar o reducir verticalmente. La supervisión del rendimiento del
servidor y las bases de datos es importante para garantizar que se cumplan los requisitos, a la vez que se
minimizan los costos.
Tanto la CPU como el almacenamiento tienen costos asociados. Hay disponibles varios planes de tarifa.
Asegúrese de que esté seleccionado el plan de precios adecuado para cada carga de trabajo de datos.
Cada réplica de lectura se factura según el proceso y el almacenamiento seleccionados.
Use la capacidad reservada para ahorrar costos.
Conclusión
En este artículo, Contoso migró sus bases de datos de MySQL a una instancia de Azure Database for MySQL.
Migración de bases de datos de PostgreSQL a
Azure
En este artículo se muestra cómo la empresa ficticia Contoso evaluó, planeó y migró a Azure su plataforma de
bases de datos de código abierto locales de PostgreSQL.

Automatizar los macrodatos. Contoso usa PostgreSQL en varias de sus iniciativas con macrodatos e
inteligencia artificial. La empresa desea crear canalizaciones repetibles escalables para automatizar muchas
de estas cargas de trabajo analíticas.
de la empresa. Debe reaccionar con más rapidez que los cambios del mercado para facilitar el éxito en una
economía global y no debe convertirse en un obstáculo para la empresa.
Aumentar la seguridad. Contoso entiende que los problemas normativos harán que la empresa adapte su
estrategia local en función de los requisitos de auditoría, registro y cumplimiento.
El equipo de la nube de Contoso ha definido los objetivos de esta migración con el fin de identificar la mejor
forma de llevarla a cabo.
Actualizaciones Contoso quiere asegurarse de que dispone de las revisiones

más recientes instaladas cuando estén disponibles, pero no
quiere administrarlas.
Integraciones Contoso quiere integrar los datos en la base de datos con

las canalizaciones de datos e inteligencia artificial para
Machine Learning.
Copia de seguridad y restauración Contoso busca la capacidad de realizar restauraciones a un

momento dado cuando, por algún motivo, se produzcan
errores o daños en las actualizaciones de datos.
Azure Contoso quiere supervisar el sistema y activar alertas

basadas en el rendimiento y la seguridad.
Rendimiento En algunos casos, Contoso tendrá canalizaciones de

procesamiento de datos en paralelo en distintas regiones
geográficas y deberá leer los datos de esas regiones.
migración.
Entorno actual
PostgreSQL 9.6.7 se ejecuta en una máquina física de Linux ( sql-pg-01.contoso.com ) en el centro de recursos de
Contoso. Contoso ya tiene una suscripción a Azure con una puerta de enlace de VPN de sitio a sitio conectada a
una red de centro de datos local.
Solución propuesta
Use Azure Database Migration Service o migre la base de datos a una instancia de Azure Database for
PostgreSQL.
Modificar todas las aplicaciones y procesos para que utilicen la nueva instancia de Azure Database for
PostgreSQL.
Cree una nueva canalización de procesamiento de datos mediante Azure Data Factory que se conecte a la
instancia de Azure Database for PostgreSQL.
Como parte del proceso de diseño de la solución, Contoso revisó las características de Azure para hospedar los
datos de PostgreSQL. Las siguientes consideraciones sirvieron a la empresa para decidir utilizar Azure:
Al igual que Azure SQL Database, Azure Database for PostgreSQL permite usar reglas de firewall.
Azure Database for PostgreSQL puede usarse junto con las redes virtuales para evitar que la instancia sea
Azure Database for PostgreSQL cuenta con las certificaciones de cumplimiento que Contoso necesita
presentar.
La integración con DevOps y Azure Data Factory permitirá crear canalizaciones de procesamiento de datos
automatizadas.
El rendimiento del procesamiento puede mejorar mediante el uso de réplicas de lectura.
Compatibilidad con "bring your own key " (BYOK) para el cifrado de datos.
Link.
Ventajas Todas las características necesarias y en uso actualmente

están disponibles en Azure Database for PostgreSQL.
Desventajas Contoso aún deberá realizar la migración manual desde la

versión principal de PostgreSQL.
Ilustración 1: Arquitectura del

escenario.
Preparación
Antes de que Contoso pueda migrar las bases de datos de PostgreSQL, asegúrese de que esas instancias de
Contoso cumplan todos los requisitos previos de Azure para que la migración se realice correctamente.
Versiones compatibles
Solo se admiten las migraciones a la misma versión o a otra superior. Se admite la migración de PostgreSQL 9.5
a Azure Database for PostgreSQL 9.6 o 10, pero no de PostgreSQL 11 a PostgreSQL 9.6.
Microsoft tiene la intención de admitir versiones n-2 del motor de PostgreSQL en el servicio Azure Database for
PostgreSQL: servidor único. Estas versiones serían la versión principal actual en Azure (n) y las dos versiones
principales anteriores ( -2).
Para obtener las actualizaciones más recientes de las versiones compatibles, consulte Versiones principales de
PostgreSQL admitidas.
NOTE
No se admite la actualización automática de la versión principal. Por ejemplo, no hay una actualización automática de
PostgreSQL 95 a PostgreSQL 9.6. Para actualizar a la siguiente versión principal, realice un volcado de base de datos y
restáurelo en un servidor creado con la nueva versión del motor.
Red
Contoso tendrá que configurar una conexión de puerta de enlace de red virtual desde el entorno local a la red
virtual en la que está ubicada la base de datos de Azure Database for PostgreSQL. Esta conexión permite que la
aplicación local tenga acceso a la base de datos sin migrarse a la nube.
Evaluación
Contoso tendrá que evaluar la base de datos actual para detectar los problemas de replicación. Entre los
problemas se incluyen:
La versión de la base de datos de origen es compatible con la migración a la versión de base de datos de
destino.
Las claves principales deben existir en todas las tablas que se van a replicar.
Los nombres de base de datos no pueden incluir ningún punto y coma ( ; ).
La migración de varias tablas con el mismo nombre, pero con distintas mayúsculas y minúsculas, puede
provocar un comportamiento impredecible.
Figura 2: El proceso de migración.

Migración
Contoso puede realizar la migración de varias maneras:
Volcado y restauración
Import/Export
Contoso seleccionó Azure Database Migration Service para permitir a la empresa volver a usar el proyecto de
migración siempre que necesite realizar actualizaciones importantes. Ya que una sola actividad de Database
Migration Service solo es compatible con un máximo de cuatro bases de datos, Contoso configura varios
trabajos mediante los siguientes pasos.
Para prepararse, configure una red virtual para acceder a la base de datos. Cree una conexión de red virtual
mediante las puertas de enlace de VPN de varias maneras.
1. En Azure Portal, seleccione Agregar un recurso .
2. Busque Azure Database Migration Ser vice y selecciónelo.
3. Seleccione +Agregar .
4. Seleccione la suscripción y el grupo de recursos para el servicio.
5. Escriba un nombre para la instancia.
6. Seleccione la ubicación más cercana a su centro de datos o puerta de enlace de VPN de Contoso.
7. Seleccione Azure para el modo de servicio.
8. Seleccione un plan de tarifa.
9. Seleccione Revisar + crear .
. Figura 3: Revisión y creación.
10. Seleccione Crear .
Creación de una instancia de Azure Database for PostgreSQL
1. En el servidor local, configure el archivo postgresql.conf .
2. Configure el servidor para que escuche a la dirección IP adecuada que Azure Database Migration Service
usará para tener acceso al servidor y a las bases de datos.
Establezca la variable listen_addresses .
3. Habilite SSL.
a. Establezca la variable ssl=on .
b. Compruebe que Contoso está usando un certificado SSL firmado públicamente para el servidor que
es compatible con TLS 1.2. De lo contrario, la herramienta de Database Migration Service producirá un
error.
4. Actualice el archivo pg_hba.conf .
Agregue entradas específicas de la instancia de Database Migration Service.
5. La replicación lógica debe habilitarse en el servidor de origen; para ello, modifique los valores del archivo
postgresql.conf para cada servidor.
a. wal_level = logical
b. = [como mínimo, el número máximo de bases de datos para la migración]
max_replication_slots
Por ejemplo, si Contoso quiere migrar cuatro bases de datos, establezca el valor en 4.
c. max_wal_senders = [número de bases de datos que se ejecutarán simultáneamente]
El valor recomendado es 10.
6. El User de la migración debe tener el rol REPLICATION en la base de datos de origen.
7. Agregue la dirección IP de la instancia de Database Migration Service al archivo PostgreSQLpg_hba.conf .
8. Para exportar los esquemas de la base de datos, ejecute los comandos siguientes:
pg_dump -U postgres -s dvdrental > dvdrental_schema.sql
9. Copie el archivo, asigne el nombre de la copia como dvdrental_schema_foreign.sql y quite todos los
elementos relacionados con la clave no externa y los desencadenadores.
10. Quite todos los elementos relacionados con la clave externa y el desencadenador del archivo
dvdrental_schema.sql .
11. Importe el esquema de la base de datos (paso 1):
psql -h {host}.postgres.database.azure.com -d dvdrental -U username -f dvdrental_schema.sql
Migración
1. En Azure Portal, Contoso va a su recurso de Database Migration Service.
2. Si el servicio no se inicia, seleccione Iniciar ser vicio .
3. Seleccione Nuevo proyecto de migración .
Ilustración 4:
Inicio de una nueva migración.
4. Seleccione Nueva actividad > Migración de datos en línea .
5. Escriba un nombre.
6. Seleccione PostgreSQL como origen.
7. Seleccione Azure Database for PostgreSQL como destino y, a continuación, seleccione Guardar .
Ilustración 5: Un nuevo
proyecto de migración está resaltado.
8. Especifique la información de origen y seleccione Guardar .
Ilustración 6: Especificación de la información de origen.
9. Especifique la información de destino y seleccione Guardar .
Ilustración 7:
Selección de la información de destino.
10. Seleccione las bases de datos que se van a migrar. El esquema de cada base de datos se debe haber
migrado anteriormente. Después, seleccione Guardar .
. Ilustración 8: Selección de las bases de datos.

11. Configure las opciones avanzadas y seleccione Guardar .
Ilustración 9: Configuración de opciones avanzadas.
12. Asigne un nombre a la actividad y seleccione Ejecutar .
Ilustración 10: Asignación de nombre y ejecución de la actividad.

13. Supervisar la migración Vuelva a intentarlo si se produce algún error. Un ejemplo se produce si faltan
referencias de clave externa.
14. Una vez que Full load completed coincida con el número de tablas, seleccione Iniciar transición .
Ilustración 11: Supervisión de la migración para iniciar la transición.
15. Detenga todas las transacciones del servidor de origen.
16. Marque la casilla Confirmar y, a continuación, seleccione Aplicar .
Ilustración 12: Ejecución de la transición.

17. Espere a que se complete la transición.
Figure 13: Finalización de la transición.
NOTE
Los pasos de Database Migration Service anteriores también se pueden realizar a través de la CLI de Azure.
18. Importe el esquema de la base de datos (paso 2):
psql -h {host}.postgres.database.azure.com -d dvdrental -U username -f dvdrental_schema_foreign.sql
19. Vuelva a configurar todas las aplicaciones o procesos que usen la base de datos local para que apunten a
la nueva instancia de base de datos de Azure Database for PostgreSQL.
20. Para después de la migración, Contoso se asegurará de que también configura las réplicas de lectura
entre regiones, si es necesario, una vez finalizada la migración.

Después de la migración, Contoso debe realizar una copia de seguridad de la base de datos local para fines de
retención y retirar el servidor de PostgreSQL anterior como parte del proceso de limpieza.
marcha.
Seguridad
Contoso debe:
Asegurarse de que la nueva instancia de Azure Database for PostgreSQL y las bases de datos estén
protegidas. Para más información, consulte Seguridad en Azure Database for PostgreSQL con un único
servidor.
Revise las reglas de firewall y las configuraciones de red virtual para comprobar que las conexiones se
limiten únicamente a las aplicaciones que lo requieran.
Implemente el servicio BYOK para el cifrado de datos.
Actualice todas las aplicaciones para que requieran conexiones SSL a las bases de datos.
Configure Private Link para que todo el tráfico de las bases de datos se mantenga dentro de Azure y de la red
local.
Configure Log Analytics para supervisar y enviar alertas sobre seguridad y entradas de registro de interés.
Copias de seguridad
Asegúrese de que las copias de seguridad de las bases de datos de Azure Database for PostgreSQL se realicen
mediante la restauración geográfica. De esta manera, las copias de seguridad se pueden usar en una región
emparejada si se produce una interrupción regional.
IMPORTANT
Asegúrese de que el recurso de Azure Database for PostgreSQL tenga un bloqueo de recursos para impedir su

Azure Database for PostgreSQL se puede escalar o reducir verticalmente. La supervisión de rendimiento del
servidor y las bases de datos es importante para garantizar que se satisfacen las necesidades y los costos se
mantienen al mínimo.
elegir. Asegúrese de seleccionar el plan de precios adecuado para las cargas de trabajo de datos.
Cada réplica de lectura se factura en función del proceso y el almacenamiento que se hayan seleccionado.
Conclusión
En este artículo, Contoso migró sus bases de datos de PostgreSQL a una instancia de Azure Database for
PostgreSQL.
Migración de bases de datos de MariaDB a Azure
En este artículo se muestra cómo la empresa ficticia Contoso evaluó, planificó y migró su plataforma de bases
de datos de código abierto locales de MariaDB a Azure.
Contoso usa MariaDB en lugar de MySQL debido a:
Sus numerosas opciones del motor de almacenamiento.
Su rendimiento de índice y caché.
Compatibilidad de código abierto con características y extensiones.
Su motor de almacenamiento ColumnStore para cargas de trabajo analíticas.
El objetivo de migración de la empresa es seguir usando MariaDB, sin tener que administrar el entorno
necesario para darle apoyo.

Aumentar la disponibilidad. Contoso ha tenido problemas de disponibilidad con su entorno local de
MariaDB. La empresa requiere que las aplicaciones que usan este almacén de datos sean más confiables.
Disponibilidad Actualmente, el personal interno tiene dificultades con el

entorno de hospedaje de la instancia de MariaDB. Contoso
desea tener un nivel de disponibilidad de la capa de base de
datos que esté cerca del 99,99 %.
Escalabilidad El host de base de datos local se está quedando sin

capacidad rápidamente. Contoso necesita una forma de
escalar sus instancias más allá de las limitaciones actuales o
reducir la escala verticalmente si el entorno empresarial
cambia, para ahorrar costos.
Rendimiento El Departamento de RR. HH. de Contoso dispone de varios

informes que se ejecutan diaria, semanal y mensualmente. Al
ejecutar estos informes, se observan importantes problemas
de rendimiento asociados a la aplicación orientada a los
empleados. Es necesario ejecutar los informes sin que afecte
al rendimiento de la aplicación.
Seguridad Contoso necesita saber que la base de datos solo está

accesible para sus aplicaciones internas, pero no está visible
ni accesible a través de Internet.
Super visión Actualmente Contoso utiliza herramientas para supervisar

las métricas de la base de datos de MariaDB y para enviar
notificaciones cuando la CPU, la memoria o el
almacenamiento tienen problemas. La empresa quiere
disponer de esta misma funcionalidad en Azure.
Continuidad del negocio El almacén de datos de RR. HH. es una parte importante de
las operaciones diarias de Contoso. Si resulta dañado o es
necesario restaurarlo, la empresa desea minimizar el tiempo
de inactividad.
Azure Contoso quiere mover la aplicación a Azure sin ejecutarla en

máquinas virtuales. Los requisitos de Contoso establecen el
uso de los servicios de plataforma como servicio (PaaS) de
Azure para la capa de datos.
migración.
Aplicación actual
La base de datos de MariaDB hospeda datos de empleados que se utilizan en todos los niveles del
Departamento de RR. HH. de la empresa. Se emplea una aplicación basada en LAMP como front-end para
administrar las solicitudes de RR. HH. a los empleados. Contoso tiene 100 000 empleados en todo el mundo,
por lo que el tiempo de actividad es importante para las bases de datos.
Solución propuesta
Evaluar los entornos en términos de compatibilidad con la migración.
Usar herramientas comunes de código abierto para migrar bases de datos a la instancia de Azure Database
for MariaDB.
Modificar todas las aplicaciones y procesos para que utilicen la nueva instancia de Azure Database for
MariaDB.
Como parte del proceso de diseño de la solución, Contoso revisó las características de Azure para hospedar las
bases de datos de MariaDB. Las siguientes consideraciones sirvieron a la empresa para decidir utilizar Azure:
Al igual que Azure SQL Database, Azure Database for MariaDB permite usar reglas de firewall.
Azure Database for MariaDB puede usarse junto con Azure Virtual Network para evitar que la instancia esté
Azure Database for MariaDB cuenta con las certificaciones de privacidad y cumplimiento que Contoso
necesita presentar a sus auditores.
El rendimiento del procesamiento de informes y aplicaciones mejorará mediante el uso de réplicas de
lectura.
Link.
Contoso decidió no migrar a Azure Database for MySQL porque están planteándose utilizar en el futuro
MariaDB ColumnStore y el modelo de base de datos de grafos.
Ventajas Azure Database for MariaDB ofrece un contrato de nivel de

servicio con un respaldo financiero del 99,99 % en términos
de alta disponibilidad.
Azure facilita el escalado vertical o la reducción vertical en

épocas de máxima carga en cada trimestre. Contoso puede
ahorrar aún más si compra capacidad reservada.
Azure Database for MariaDB admite funcionalidad de

restauración a un momento dado y de restauración
geográfica para Azure Database for MariaDB.
Desventajas Contoso se limita a usar las versiones de lanzamiento de

MariaDB que son compatibles con Azure, que son
actualmente la 10.2 y la 10.3.
Azure Database for MariaDB tiene algunas limitaciones,

como la reducción vertical del almacenamiento.
Ilustración 1: Arquitectura del escenario.

Preparación
Antes de migrar las bases de datos de MariaDB, debe asegurarse de que esas instancias cumplan todos los
requisitos previos de Azure para que la migración se realice correctamente.
Versiones compatibles:
MariaDB usa el esquema de nomenclatura X.Y.Z. Por ejemplo, x es la versión principal, y es la versión
secundaria, y z es la versión de revisión.
Azure admite actualmente las versiones 10.2.25 y 10.3.16.
Azure administra automáticamente las actualizaciones de revisiones. Algunos ejemplos son de 10.2.21 a
10.2.23. Actualmente, no se admiten las actualizaciones de las versiones principales y secundarias. Por
ejemplo, no se admite la actualización de MariaDB 10.2 a MariaDB 10.3. Si quiere actualizar de la
versión 10.2 a la 10.3, haga un volcado y restáurelo en un servidor creado con la versión del motor de
destino.
La red:
Contoso tiene que configurar una conexión de puerta de enlace de red virtual desde el entorno local a la red
virtual donde está ubicada la base de datos de MariaDB. Esta conexión permitirá que la aplicación local acceda a
la base de datos a través de la puerta de enlace al actualizar las cadenas de conexión.

Migración
Como que MariaDB es similar a MySQL, Contoso puede usar las mismas utilidades y herramientas comunes,
como MySQL Workbench, mysqldump, Toad o Navicat, para conectarse a los datos y migrarlos a Azure
Database for MariaDB.
Contoso realizó los pasos que se indican a continuación para migrar las bases de datos.
Determinar la versión local de MariaDB mediante la ejecución de los siguientes comandos y observar el
resultado. En la mayoría de los casos, la versión no debería importar mucho en cuanto al esquema y al
volcado de datos. Si usa características en el nivel de aplicación, asegúrese de que esas aplicaciones sean
compatibles con la versión de destino en Azure.
mysql -h localhost -u root -P
Ilustración 3: Determinación de la versión local de MariaDB.

Crear una nueva instancia de MariaDB en Azure:
Abra Azure Portal.
Seleccione Agregar un recurso .
Busque MariaDB .
Ilustración 4: Una nueva instancia de MariaDB en Azure.

Seleccione Crear .
Seleccione su suscripción y grupo de recursos.
Seleccione un nombre de servidor y una ubicación.
Seleccione la versión de destino, que es 10.2 o 10.3.
Seleccione el proceso y el almacenamiento.
Especifique un nombre de usuario y una contraseña de administrador.
Seleccione Revisar + crear .
Figura 5: Revisión y creación.
Seleccione Crear .
Anote el nombre de host, el nombre de usuario y la contraseña del servidor.
Seleccione Seguridad de la conexión .
Seleccione Agregar IP de cliente (la dirección IP desde la que va a restaurar la base de datos).
Seleccione Guardar .
Ejecutar los comandos siguientes para exportar la base de datos llamada Employees . Repita el
procedimiento para cada base de datos:
mysqldump -h localhost -u root -p --skip-triggers --single-transaction --extended-insert --order-by-

primary --disable-keys Employees > Employees.sql
Restaure la base de datos. Reemplácela por el punto de conexión de la instancia de Azure Database for
MariaDB y el nombre de usuario:
mysql -h {name}.mariadb.database.azure.com -u user@{name} -p -ssl

create database employees;
use database employees;
source employees.sql;
Use phpMyAdmin o una herramienta similar, como, MySQL Workbench, Toad y Navicat, para comprobar
la restauración mediante la comprobación de los recuentos de registros de cada tabla.
Actualizar todas las cadenas de conexión de la aplicación para que apunten a la base de datos migrada.
Probar que todas las aplicaciones funcionan correctamente.

Después de verificar que la migración es correcta, Contoso debe hacer una copia de seguridad y almacenar los
archivos de copia de seguridad de la base de datos local con fines de retención. Retire el servidor local de
MariaDB.
marcha.
Seguridad
Contoso debe:
Asegurarse de que la nueva instancia de Azure Database for MariaDB y las bases de datos estén protegidas.
Para más información, consulte Seguridad en Azure Database for MariaDB.
Revise las reglas de firewall y las configuraciones de red virtual para comprobar que las conexiones se
limiten únicamente a las aplicaciones que lo requieran.
Configure los requisitos de IP de salida para permitir conexiones a las direcciones IP de puerta de enlace de
MariaDB.
Actualice todas las aplicaciones para que requieran conexiones SSL a las bases de datos.
Configure Private Link para que todo el tráfico de las bases de datos se mantenga dentro de Azure y de la red
local.
Configure Log Analytics para supervisar y enviar alertas sobre seguridad y entradas de registro de interés.
Copias de seguridad
Asegúrese de que las copias de seguridad de las instancias de Azure Database for MariaDB se hagan mediante
restauración geográfica. De esta manera, las copias de seguridad se pueden usar en una región emparejada si se
produce una interrupción regional.
IMPORTANT
Asegúrese de que la instancia de Azure Database for MariaDB disponga de un bloqueo de recursos para impedir su

Azure Database for MariaDB se puede escalar o reducir verticalmente. La supervisión de rendimiento del
servidor y las bases de datos es importante para garantizar que se satisfacen sus necesidades, pero que
también se conservan los costos a un mínimo.
elegir. Asegúrese de seleccionar el plan de precios adecuado para las cargas de trabajo de datos.
Cada réplica de lectura se factura en función del proceso y el almacenamiento que se hayan seleccionado.
Use la capacidad reservada para ahorrar costos.
Conclusión
En este artículo, Contoso migró sus bases de datos de MariaDB a una instancia de Azure Database for MariaDB.
Rehospedaje de una aplicación local de Linux en
máquinas virtuales de Azure
En este artículo se muestra cómo la empresa ficticia Contoso rehospeda una aplicación basada en LAMP de dos
niveles mediante máquinas virtuales de infraestructura como servicio (IaaS) de Azure.
La aplicación del departamento de servicios que se usa en este ejemplo, osTicket, se proporciona como software
de código abierto. Si quiere utilizarla para sus propias pruebas, puede descargarla desde GitHub.

lograr con esta migración:
Limitar el riesgo. La aplicación de consola de servicio es fundamental para la actividad de Contoso.
Contoso quiere moverla a Azure sin ningún riesgo.
Extensión. Contoso no quiere cambiar la aplicación en este momento. Quiere asegurarse de que la
aplicación es estable.
El equipo de la nube de Contoso ha definido los objetivos de esta migración con el fin de determinar el mejor
método para llevarla a cabo:
tiene actualmente en el entorno de VMware local de la empresa. La aplicación seguirá siendo tan
imprescindible en la nube como lo es en el entorno local.
Contoso no quiere invertir en esta aplicación. Es importante para la empresa, pero en su formato actual
Contoso no quiere cambiar el modelo de operaciones de esta aplicación. Quiere interactuar con la aplicación
en la nube de la misma manera que lo hace ahora.
Contoso no quiere cambiar la funcionalidad de la aplicación. Solo cambiará su ubicación.
Tras haber completado un par de migraciones de aplicaciones de Windows, Contoso desea aprender a usar
una infraestructura basada en Linux en Azure.
identifica el proceso de migración. También se identifican los servicios de Azure que usará Contoso para la
migración.
Aplicación actual
La aplicación osTicket se distribuye en niveles entre dos máquinas virtuales ( OSTICKETWEB y OSTICKETMYSQL ).
El entorno de VMware se administra con vCenter Server 6.5 ( vcenter.contoso.com ) y se ejecuta en una
máquina virtual.
contosodc1 ).
Dado que la aplicación es para una carga de trabajo de producción, las máquinas virtuales de Azure residirán
en el grupo de recursos de producción ContosoRG .
Las máquinas virtuales se migrarán a la región principal (Este de EE. UU. 2) y se colocarán en la red de
producción ( VNET-PROD-EUS2 ):
La máquina virtual web residirá en la subred de front-end ( PROD-FE-EUS2 ).
La máquina virtual de base de datos residirá en la subred de la base de datos ( PROD-DB-EUS2 ).
Ventajas Las dos máquinas virtuales de aplicaciones se moverán a

Azure sin cambios, de forma que se simplifica la migración.
Dado que Contoso usa un enfoque lift-and-shift para ambas

máquinas virtuales de aplicaciones, no se necesitan
para la base de datos de aplicación.
Contoso conservará el control total de las máquinas

virtuales de aplicaciones en Azure.
Las máquinas virtuales de aplicación ejecutan Ubuntu 16.04-

TLS, que es una distribución de Linux aprobada. Obtenga
más información sobre Distribuciones de Linux aprobadas en
Azure.
Desventajas Las capas de datos y web de la aplicación siguen teniendo

un único punto de conmutación por error.
Contoso deberá seguir utilizando la aplicación en máquinas

virtuales de Azure en lugar de moverla a un servicio
administrado, como Azure App Service y Azure Database for
MySQL.
Contoso sabe que al simplificar las cosas con una migración

de máquina virtual mediante lift-and-shift, la empresa no
está aprovechando al máximo las características
proporcionadas por Azure Database for MySQL, entre las
que se incluyen alta disponibilidad integrada, rendimiento
predecible, escalado sencillo, copias de seguridad
automáticas y seguridad integrada.
Contoso completará el proceso de migración como se indica a continuación:
Como primer paso, contoso prepara y configura componentes de Azure para Azure Migrate: Server
Migration y prepara la infraestructura local de VMware.
La empresa ya tiene la infraestructura de Azure implementada, por lo que solo tiene que configurar la
servidor.
Una vez que se haya habilitado la replicación y esta se encuentre en funcionamiento, Contoso migrará la
máquina virtual, haciendo que conmute por error en Azure.
Servicios de Azure
de trabajo locales, así como las Las VM de Azure se crean, y generan
instancias de máquinas virtuales de gastos, cuando se produce la
Amazon Web Services (AWS) y Google migración. Obtenga más información
Cloud Platform (GCP). sobre tarifas y precios.
Requisitos previos
Esto es lo que Contoso necesita para este escenario.

cuenta gratuita.



del acceso a Site Recovery con el control de acceso basado
en rol de Azure (RBAC de Azure).
Infraestructura de Azure Vea cómo Contoso configura una infraestructura de Azure.

5.5, 6.0 o 6.5.
Un host ESXi que ejecute la versión 5.5, 6.0 o 6.5.

host ESXi.
Máquinas vir tuales locales Revise las distribuciones de Linux que se han aprobado para
Pasos del escenario

Así es como Azure realizará la migración:
Paso 1: Preparación de Azure para Azure Migrate: Ser ver Migration. Agregar la herramienta Azure
Migrate: Server Migration al proyecto de Azure Migrate.
Paso 2: Preparación del entorno de VMware local para Azure Migrate: Ser ver Migration. Preparar
las cuentas para la detección de máquinas virtuales y preparar la conexión a las máquinas virtuales de Azure
tras la migración.
Paso 3: Replicación de máquinas vir tuales. Configurar la replicación y comenzar a replicar las máquinas
virtuales en Azure Storage.
Paso 4: Migración de las máquinas vir tuales con Azure Migrate: Ser ver Migration. Ejecutar una
migración de prueba para garantizar que todo funciona y, luego, ejecutar una migración para mover las
máquinas virtuales a Azure.

Migration
migración.
Azure Migrate: Server Migration aprovisionada.
Estos componentes se configuran como se muestra a continuación:
1. Configurar una red. Contoso ya configuró una red que se puede usar para Azure Migrate: Server
Migration cuando la empresa implementó la infraestructura de Azure.
La aplicación SmartHotel360 es una aplicación de producción. Las máquinas virtuales se migrarán a la
red de producción de Azure ( VNET-PROD-EUS2 ) en la región primaria ( East US 2 ).
La máquina virtual de front-end de aplicaciones ( OSTICKETWEB ) se migrará a la subred de front-end (
La máquina virtual de base de datos de aplicaciones ( OSTICKETMYSQL ) se migrará a la subred de base
de datos ( PROD-DB-EUS2 ), en la red de producción.
2. Aprovisione la herramienta Azure Migrate:Server Migration: Herramienta de migración del servidor. Con
la cuenta de almacenamiento y de red que tiene implementada, Contoso crea un almacén de Recovery
Services ( ContosoMigrationVault ) y lo coloca en el grupo de recursos ContosoFailoverRG de la región
primaria ( East US 2 ).

Aprenda cómo configurar la herramienta Azure Migrate: Server Migration.

Server Migration
Después de la migración a Azure, Contoso quiere poder conectarse a las VM replicadas de Azure. Hay un par de
cosas que los administradores de Contoso deben hacer:
Para acceder a las máquinas virtuales de Azure a través de Internet, habilitan SSH en la máquina virtual Linux
local antes de la migración. En el caso de Ubuntu, este paso se puede realizar mediante el siguiente comando:
sudo apt-get ssh install -y .
Instale el agente Linux de Azure.
Después de ejecutar la migración, pueden comprobar los diagnósticos de arranque para ver una captura
de pantalla de la VM.
Si esto no funciona, deberán comprobar que la máquina virtual está en ejecución y revisar estas sugerencias
de solución de problemas.

Para que los administradores de Contoso puedan ejecutar una migración a Azure, tienen que configurar y
Una vez finalizada la detección, inicie la replicación de máquinas virtuales de VMware en Azure.
1. En el proyecto de Azure Migrate, vaya a Ser vidores > Azure Migrate: Ser ver Migration y seleccione
Replicar .
VMware vSphere .
4. En Máquinas vir tuales , seleccione las máquinas que desea replicar.

tamaño y tipo de disco (Premium/estándar) de máquina virtual que sugieren los resultados de dicha
evaluación. En ¿Quiere impor tar la configuración de migración de evaluación de Azure
Migrate? , seleccione la opción Sí .
opción No .
evaluación.
5. En Máquinas vir tuales , busque las máquinas virtuales que necesite y seleccione todas las que desee
6. En Configuración de destino , seleccione la suscripción y la región de destino a la que migrará.
Especifique el grupo de recursos en el que residirán las máquinas virtuales de Azure después de la
migración. En Red vir tual , seleccione la red virtual o la subred de Azure a la que se unirán las máquinas
virtuales de Azure después de la migración.
Seleccione Sí si tiene equipos con Windows Server que están incluidos en suscripciones activas de
Software Assurance o Windows Server y desea aplicar el beneficio a las máquinas que va a migrar.
Luego, seleccione Siguiente .
máquina virtual contendrá el tamaño recomendado. De lo contrario, Azure Migrate elige un tamaño
en función de la coincidencia más cercana en la suscripción de Azure. También puede elegir un
tamaño de manera manual en Tamaño de la máquina vir tual de Azure .
9. En Discos , especifique si los discos de máquina virtual se deben replicar en Azure. Seleccione el tipo de
disco (SSD/HDD Estándar o discos administrados Premium) de Azure. Luego, seleccione Siguiente .
Puede excluir discos de la replicación.
Si excluye discos, no estarán presentes en la máquina virtual de Azure después de la migración.
10. En Revisar + iniciar replicación , revise la configuración. A continuación, seleccione Replicar para
NOTE
Paso 4: Migrar las VM

mover las máquinas virtuales.
2. Mantenga presionada o haga clic con el botón derecho en la máquina virtual que va a probar. Luego,
seleccione Migración de prueba .
Azure después de la migración. Se recomienda usar una red virtual que no sea de producción.
virtual de Azure, en Replicación de máquinas . A continuación, seleccione Limpiar la migración de
prueba .
Migrar las VM
Ahora, los administradores de Contoso ejecutan una migración completa para completar el movimiento.
Si no desea apagar la VM, seleccione No .
vir tuales .
Conexión de la VM a la base de datos
de la aplicación para que apunte a la base de datos de la aplicación que se ejecuta en la máquina virtual
OSTICKETMYSQL .
1. Establezca una conexión SSH con la máquina virtual OSTICKETWEB mediante PuTTY u otro cliente SSH. La
máquina virtual es privada, por lo que debe conectarse mediante la dirección IP privada.
2. Asegúrese de que la máquina virtual OSTICKETWEB pueda comunicarse con la máquina virtual
OSTICKETMYSQL . Actualmente, la configuración está codificada de forma rígida con la dirección IP local
172.16.0.43 .
Antes de la actualización:
Después de la actualización:
3. Reinicie el servicio con systemctl restar t apache2 .
4. Por último, actualice los registros DNS de OSTICKETWEB y OSTICKETMYSQL en uno de los controladores de
dominio de Contoso.

Al finalizar la migración, los niveles de la aplicación osTicket se ejecutan en las máquinas virtuales de Azure.
Ahora, Contoso debe hacer las siguientes tareas:
Quitar las VM locales del inventario de vCenter.
Quitar las VM locales de los trabajos de copia de seguridad locales.
Actualizar la documentación interna para mostrar la nueva ubicación y las direcciones IP de OSTICKETWEB y
OSTICKETMYSQL .
Revisar todos los recursos que interactúan con las máquinas virtuales. Actualice la configuración o la
documentación pertinentes para que reflejen la nueva configuración.
Contoso usaba el servicio Azure Migrate con la VM de administración para evaluar las VM para la migración.
Los administradores deben quitar la máquina virtual de migración y las máquinas virtuales web de VMware
ESXi Server.
Con la aplicación en ejecución, Contoso debe proteger y poner plenamente en funcionamiento la nueva
infraestructura.
Seguridad
El equipo de seguridad de Contoso revisa las máquinas virtuales OSTICKETWEB y OSTICKETMYSQL para determinar
si existe algún problema de seguridad.
El equipo revisa los grupos de seguridad de red de las máquinas virtuales para controlar el acceso. Los NSG
se usan para garantizar que solo el tráfico permitido puede pasar a la aplicación.
El equipo también se plantea proteger los datos de los discos de máquina virtual mediante Azure Disk
Encryption y Azure Key Vault.
IaaS de Azure.
Mantener seguros los datos. Contoso hace una copia de seguridad de los datos de las máquinas
virtuales mediante la copia de seguridad de máquina virtual de Azure.
Mantener las aplicaciones en funcionamiento. Contoso replica las máquinas virtuales de
aplicaciones en Azure en una región secundaria mediante Site Recovery. Para más información, consulte
Inicio rápido: Configuración de la recuperación ante desastres en una región secundaria de Azure de una
máquina virtual de Azure.
Después de implementar los recursos, Contoso asigna etiquetas de Azure según lo definido durante la
implementación de la infraestructura de Azure.
Contoso no tiene problemas relacionados con las licencias con sus servidores de Ubuntu.
Rehospedaje de una aplicación de Linux local en
máquinas virtuales de Azure y en Azure Database
for MySQL
En este artículo se muestra cómo la empresa ficticia Contoso rehospeda una aplicación de dos niveles basada en
LAMP y la migra de un entorno local a Azure mediante Azure Virtual Machines y Azure Database for MySQL.
La aplicación del departamento de servicios que se usa en este ejemplo, osTicket, se proporciona como software
de código abierto. Si quiere utilizarla para sus propias pruebas, puede descargarla desde GitHub.

El equipo directivo de TI ha trabajado estrechamente con sus socios comerciales para comprender sus objetivos:
Limitar el riesgo. La aplicación de consola de servicio es fundamental para la empresa. Contoso quiere
moverla a Azure sin ningún riesgo.
Extensión. Contoso no quiere cambiar la aplicación en este momento. La empresa desea mantener la
aplicación estable.
tiene actualmente en el entorno de VMware local de la empresa. La aplicación seguirá siendo tan
imprescindible en la nube como lo es en el entorno local.
Contoso no quiere invertir en esta aplicación. Es importante para la empresa, pero en su formato actual
Tras haber completado un par de migraciones de aplicaciones de Windows, Contoso desea aprender a usar
una infraestructura basada en Linux en Azure.
Quiere minimizar las tareas de administración de la base de datos tras mover la aplicación a la nube.
En este escenario:
Actualmente, la aplicación se divide en niveles entre dos máquinas virtuales ( OSTICKETWEB y
OSTICKETMYSQL ).
El entorno de VMware se administra con vCenter Server 6.5 ( vcenter.contoso.com ) y se ejecuta en una
máquina virtual.
Contoso tiene un centro de datos local ( contoso-datacenter ), con un controlador de dominio local (
contosodc1 ).
La aplicación web en OSTICKETWEB se migrará a una máquina virtual IaaS de Azure.
La base de datos de la aplicación se migrará al servicio PaaS de Azure Database for MySQL.
Dado que Contoso va a migrar una carga de trabajo de producción, los recursos residirán en el grupo de
recursos de producción ContosoRG .
El recurso OSTICKETWEB se replicará en la región principal (Este de EE. UU. 2) y se colocará en la red de
producción ( VNET-PROD-EUS2 ):
La máquina virtual web residirá en la subred de front-end ( PROD-FE-EUS2 ).
La base de datos de la aplicación se migrará a Azure Database for MySQL mediante Azure Database
Migration Service.
Para migrar la VM web:
Como primer paso, Contoso configura la infraestructura local y de Azure necesaria para implementar Azure
Migrate.
La empresa ya tiene la infraestructura de Azure implementada, por lo que solo tiene que agregar y
configurar la replicación de las máquinas virtuales con la herramienta Azure Migrate: Herramienta de
migración del servidor.
Con todo preparado, Contoso puede comenzar a replicar la VM.
Una vez que se haya habilitado la replicación y esta se encuentre en funcionamiento, Contoso completará el
movimiento con Azure Migrate.
Migración de la base de datos:
1. Contoso proporciona una instancia de MySQL en Azure.
2. Contoso configura Database Migration Service (DMS), lo que garantiza el acceso al servidor de bases de
datos local.
3. Contoso migra la base de datos a Azure Database for MySQL.
Servicios de Azure
evaluar sus máquinas virtuales de costo adicional. Puede incurrir en
idoneidad de las máquinas para la o de otros ISV) que decida usar para la
migración. Proporciona estimaciones valoración y migración.
de tamaño y costos para su ejecución
en Azure.
Azure Database Migration Service Database Migration Service permite Información acerca de las regiones
migraciones completas de varios admitidas y los precios de Database
orígenes de base de datos a Migration Service.
Azure Database for MySQL La base de datos se basa en el motor Obtenga más información sobre las
de base de datos MySQL de código opciones de precios y escalabilidad de
abierto. Proporciona una base de Azure Database for MySQL.
datos MySQL de la comunidad
completamente administrada y lista
para la empresa para el desarrollo y la
implementación de aplicaciones.
Prerrequisitos
Esto es lo que Contoso necesita para este escenario.

Suscripción de Azure En un artículo anterior, Contoso creó suscripciones. Si no

tiene una suscripción a Azure, cree una cuenta gratuita.



del acceso de Azure Site Recovery con el control de acceso
basado en rol (RBAC).

la 5.5, 6.0, 6.5 o 6.7.
Un host ESXi que ejecute la versión 5.5, 6.0, 6.5 o 6.7.

host ESXi.
Pasos del escenario

Así es como los administradores de Contoso realizarán la migración:
migración al proyecto de Azure Migrate.
Paso 2: Preparación del entorno de VMware local para Azure Migrate: Ser ver Migration. Se
preparan las cuentas para la detección de máquinas virtuales y se prepara la conexión a las máquinas
virtuales de Azure tras la migración.
Paso 3: Replicación de máquinas vir tuales. Se configura la replicación y se empiezan a replicar las
máquinas virtuales en Azure Storage.
Paso 4: Migración de la máquina vir tual de la aplicación con Azure Migrate: Ser ver Migration.
Se ejecuta una migración de prueba para garantizar que todo funciona y, luego, se ejecuta una migración
completa para mover las VM a Azure.
Paso 5: Migración de la base de datos. Se configura la migración con Azure Database Migration Service.

Migration
migración.
Azure Migrate: Server Migration (OVA) aprovisionada y configurada.
Para configurar los componentes, los administradores de Contoso realizan estos pasos:
1. Configuración de una red. Contoso ya configuró una red que se puede usar para Azure Migrate: Server
a. Desde Azure Migrate, se descarga la imagen .OVA y se importa en VMWare.
b. Inicie la imagen importada y configure la herramienta mediante los pasos siguientes:

a. Configure los requisitos previos.
b. Dirija la herramienta a la suscripción de Azure.

c. Configure las credenciales de VMWare vCenter.
d. Agregue las credenciales basadas en Linux para la detección.

3. Una vez configurada, la herramienta tardará algún tiempo en mostrar todas las máquinas virtuales. Una
vez finalizado el proceso, aparecen las máquinas virtuales en la herramienta de Azure Migrate en Azure.
Aprenda a configurar la herramienta Azure Migrate: Server Migration.

Server Migration
Después de la migración a Azure, Contoso quiere poder conectarse a las VM replicadas de Azure. Hay un par de
cosas que los administradores de Contoso deben hacer:
Para acceder a las máquinas virtuales de Azure, deben habilitar SSH en la máquina virtual Linux local antes
de la migración. En el caso de Ubuntu, este paso se puede realizar mediante el siguiente comando:
sudo apt-get ssh install -y .
Después de que los administradores ejecutan la migración, pueden comprobar los diagnósticos de
arranque para ver una captura de pantalla de la máquina virtual.
Si esto no funciona, deberán comprobar que la máquina virtual está en ejecución y revisar estas sugerencias
de solución de problemas.
Instale el agente Linux de Azure.
Paso 3: Replicación de máquinas virtuales

Una vez finalizada la detección, pueden comenzar la replicación de la máquina virtual de la aplicación en Azure.
Replicar .
VMware vSphere .
4. En Máquinas vir tuales , seleccione las máquinas que desea replicar:

tamaño y tipo de disco (Premium/estándar) de máquina virtual que sugieren los resultados de dicha
evaluación. En ¿Quiere impor tar la configuración de migración de evaluación de Azure
Migrate? , seleccione la opción Sí .
opción No .
evaluación.
5. En Máquinas vir tuales , busque las máquinas virtuales que necesite y seleccione todas las que desee
6. En Configuración de destino , seleccione la suscripción y la región de destino a la que migrará.
Especifique el grupo de recursos en el que residirán las máquinas virtuales de Azure después de la
migración. En Red vir tual , seleccione la red virtual o la subred de Azure a la que se unirán las máquinas
virtuales de Azure después de la migración.
función de la coincidencia más cercana en la suscripción de Azure. También puede elegir un tamaño
9. En Discos , especifique si los discos de máquina virtual se deben replicar en Azure. Después, seleccionan
el tipo de disco (SSD/HDD Estándar o discos administrados Premium) de Azure y seleccionan Siguiente .
Puede excluir discos de la replicación.
Si excluye discos, no estarán presentes en la máquina virtual de Azure después de la migración.
10. En Revisar + iniciar replicación , revise la configuración. A continuación, seleccione Replicar para
NOTE
Paso 4: Migración de la máquina virtual con Azure Migrate: Server

Migration
mover las máquinas virtuales web.
Azure después de la migración. Se recomienda usar una red virtual que no sea de producción.
virtual de Azure, en Replicación de máquinas . A continuación, seleccione Limpiar la migración de
prueba .
Migración de la VM
Ahora, los administradores de Contoso ejecutan una migración completa para completar el movimiento.
Si no desea apagar la VM, seleccione No .
vir tuales .
Paso 5: Aprovisionamiento de Azure Database for MySQL

El administrador de Contoso aprovisiona una instancia de base de datos de MySQL en la región primaria (
East US 2 ).
1. En Azure Portal, crea un recurso de Azure Database for MySQL.

2. Agrega el nombre contosoosticket para la base de datos de Azure. Agrega la base de datos al grupo de
recursos de producción ContosoRG y especifica sus credenciales.
3. La base de datos MySQL local es de la versión 5.7, por lo que se selecciona esta versión por cuestiones de
compatibilidad. Utiliza los tamaños predeterminados, que coinciden con los requisitos de la base de
datos.
4. Para las opciones de redundancia de copia de seguridad , se selecciona Redundancia geográfica .

Esta opción le permite restaurar la base de datos en la región secundaria ( Central US ) si se produce una
interrupción. Solo puede configurar esta opción al aprovisionar la base de datos.
5. En la red VNET-PROD-EUS2 , vaya a Puntos de conexión de ser vicio , agregue un punto de conexión de
servicio (una subred de la base de datos) para el servicio SQL.
6. Tras agregar la subred, crea una regla de red virtual que permite obtener acceso desde la subred de la
base de datos de la red de producción.
Paso 6: Migración de la base de datos
Hay varias maneras de mover la base de datos MySQL. Cada opción requiere que los administradores de
Contoso creen una instancia de Azure Database for MySQL para el destino. Una vez creada, pueden realizar la
migración mediante el uso de dos rutas de acceso que se describen en los pasos siguientes:
6a: Database Migration Service
6b: Copia de seguridad y restauración de MySQL Workbench
Paso 6a: Migración de la base de datos mediante Database Migration Service
Database Migration Service. Pueden realizar migraciones en línea, sin conexión e híbridas (versión preliminar)
mediante MySQL 5.6 o 5.7.
NOTE
MySQL 8.0 se admite en Azure Database for MySQL, pero la herramienta Azure Database Migration Service todavía no es
compatible con esa versión.
En resumen, los administradores de Contoso deben realizar las siguientes tareas:

Asegúrese de que se cumplen todos los requisitos previos:
La versión del servidor MySQL de la base de datos de origen debe ser una que Azure Database for
MySQL admita. Azure Database for MySQL admite MySQL Community Edition, el motor de
Habilite el registro binario en my.ini (Windows) o my.cnf (Unix). Si esto no se hace, se producirá el
siguiente error en el Asistente para migración:
Error in binary logging. Variable binlog_row_image has value 'minimal.' Please change it to 'full.'
Cree una red virtual que se conecte a través de Azure ExpressRoute o VPN a la red local.
Cree una instancia de Azure Database Migration Service con una SKU Premium que esté conectada a la red
virtual.
Asegúrese de que la instancia pueda acceder a la base de datos de MySQL a través de la red virtual.
Asegúrese de que todos los puertos de entrada estén permitidos desde Azure a MySQL en el nivel de la red
virtual, la VPN de red y la máquina que hospeda MySQL.
Ejecute la herramienta Database Migration Service:

Inicie la replicación y resuelva los posibles errores.

Restablezca las claves externas y los desencadenadores.
Modifique las aplicaciones para que usen la nueva base de datos.
Paso 6b: Migración de la base de datos (MySQL Workbench)
Los administradores de Contoso migran la base de datos mediante la copia de seguridad y la restauración con
herramientas de MySQL. Instalan MySQL Workbench, hacen una copia de seguridad de la base de datos desde
OSTICKETMYSQL y, a continuación, la restauran en Azure Database for MySQL.
Instalación de MySQL Workbench

1. Comprueban los requisitos previos y las descargas de MySQL Workbench.
2. Instalan MySQL Workbench para Windows de acuerdo con las instrucciones de instalación.
3. En MySQL Workbench, cree una conexión de MySQL a OSTICKETMYSQL .
4. Se exporta la base de datos como osticket a un archivo independiente local.

5. Después de realizar la copia de seguridad de la base de datos localmente, crean una conexión a la
instancia de Azure Database for MySQL.
6. Ahora, importan (restauran) la base de datos en la instancia de Azure Database for MySQL desde el
archivo independiente. Se crea un nuevo esquema ( osticket ) para la instancia.
Conexión de la VM a la base de datos
de la aplicación para que apunte a la base de datos de la aplicación que se ejecuta en la máquina virtual
OSTICKETMYSQL .
1. Establezca una conexión SSH con la máquina virtual OSTICKETWEB mediante PuTTY u otro cliente SSH. La
máquina virtual es privada, por lo que debe conectarse mediante la dirección IP privada.
2. Asegúrese de que la máquina virtual OSTICKETWEB pueda comunicarse con la máquina virtual
OSTICKETMYSQL . Actualmente, la configuración está codificada de forma rígida con la dirección IP local
172.16.0.43 .
Antes de la actualización:
Después de la actualización:
3. El servicio se reinicia con systemctl restart apache2 .
4. Por último, actualice los registros DNS de OSTICKETWEB y OSTICKETMYSQL en uno de los controladores de
dominio de Contoso.
Con la aplicación en ejecución, Contoso debe proteger y poner plenamente en funcionamiento la nueva
infraestructura.

Al finalizar la migración, los niveles de la aplicación osTicket se ejecutan en máquinas virtuales de Azure.
Ahora, Contoso debe hacer las siguientes tareas:
Quitar las VM de VMware del inventario de vCenter.
Quitar las VM locales de los trabajos de copia de seguridad locales.
Actualizar la documentación interna para que muestre las nuevas ubicaciones y direcciones IP.
Revisar todos los recursos que interactúan con las máquinas virtuales locales. Actualice la configuración o la
documentación pertinentes para que reflejen la nueva configuración.
Contoso usaba el servicio Azure Migrate con la asignación de dependencias para evaluar la máquina virtual
OSTICKETWEB para la migración.
Seguridad
El equipo de seguridad de Contoso revisa la máquina virtual y la base de datos para determinar cualquier
problema de seguridad:
Revisan los grupos de seguridad de red de la máquina virtual con el fin de controlar el acceso. Los NSG se
usan para garantizar que solo el tráfico permitido puede pasar a la aplicación.
Consideran la posibilidad de proteger los datos en los discos de la máquina virtual mediante Azure Disk
Encryption y Azure Key Vault.
La comunicación entre la instancia de la base de datos y la VM no está configurada para SSL. Deberán
configurar SSL para garantizar que el tráfico de la base de datos no pueda piratearse.
IaaS de Azure.
Mantener seguros los datos. Contoso hace copias de seguridad de los datos de la máquina virtual de la
aplicación mediante una copia de seguridad de máquina virtual de Azure. La empresa no tiene que
configurar la copia de seguridad de la base de datos. Azure Database for MySQL crea automáticamente
copias de seguridad del servidor y las almacena. Contoso optó por utilizar la redundancia geográfica para la
base de datos para que sea resistente y esté lista para la producción.
Mantener las aplicaciones en funcionamiento. Contoso replica las máquinas virtuales de aplicaciones
en Azure en una región secundaria mediante Site Recovery. Para más información, consulte Inicio rápido:
Configuración de la recuperación ante desastres en una región secundaria de Azure de una máquina virtual
de Azure.
Después de implementar los recursos, Contoso asigna etiquetas de Azure según lo definido durante la
implementación de la infraestructura de Azure.
No hay ningún problema relacionado con las licencias para los servidores de Ubuntu de Contoso.
Introducción a la migración manual de Moodle
Moodle es un sistema gratuito de código abierto de administración del aprendizaje escrito en PHP. En esta guía
se explica cómo migrar una implementación de Moodle desde un entorno local a Azure. En esta guía se
proporcionan los pasos de dos enfoques diferentes que utilizan Azure Portal o la interfaz de la línea de
comandos de Azure (CLI de Azure).
Prerrequisitos
Antes de empezar la migración, necesita los siguientes requisitos previos:
Software local actualizado y revisado con las siguientes versiones:
Ubuntu 18.04 LTS
NGINX 1.14
Servidor de bases de datos MySQL 5.6, 5.7 u 8.0. En esta guía se utiliza Azure Database for MySQL.
PHP 7.2, 7.3 o 7.4
Moodle 3.8 o 3
El sitio web de Moodle establecido en modo de mantenimiento .
Acceda a la infraestructura local para realizar copias de seguridad de la implementación y las configuraciones
de Moodle (incluidas las configuraciones de la base de datos).
CLI de Azure y AzCopy instalado de forma local.
Una suscripción de Azure y una cuenta de Azure Blob Storage creadas.
Proceso de migración de Moodle

La migración de Moodle con una plantilla de Azure Resource Manager crea la infraestructura en Azure y luego
migra la pila de software de Moodle y las dependencias asociadas.
Los pasos de migración de Moodle a Azure se dividen en las tres fases siguientes:
1. Antes de la migración
2. Migración de aplicaciones
3. Después de la migración
Pasos siguientes
Continúe con Preparación de una migración de Moodle.
Preparación de una migración de Moodle
Antes de migrar una aplicación de Moodle desde el entorno local a Azure, debe exportar los datos. En esta guía
se explican los pasos del proceso de exportación.
Instalación de la CLI de Azure

Siga estos pasos para configurar la CLI de Azure en el entorno local:
1. En un host que pueda usar para las tareas de Azure, escriba este comando para instalar la CLI de Azure:
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
2. En la CLI de Azure, escriba este comando para iniciar sesión en su cuenta de Azure:
az login -u <username> -p <password>
3. Si la CLI de Azure abre una pestaña o ventana del explorador, inicie sesión en Azure con su cuenta de
Microsoft. Si no se abre una ventana del explorador, vaya a https://aka.ms/devicelogin y escriba el código
de autorización que se muestra en el terminal.
una suscripción
Omita este paso si ya tiene una suscripción de Azure.
Si no tiene una suscripción de Azure, puede crear una gratis. También puede configurar una suscripción de pago
por uso, o bien puede crear una suscripción en Azure Portal.
Para usar Azure Portal para crear una suscripción, abra Suscripciones , seleccione Agregar y escriba la
información necesaria.
Para usar la CLI de Azure para crear una suscripción, escriba este comando:
az account set --subscription '<subscription name>'
Este es un comando de ejemplo:

az account set --subscription 'ComputePM LibrarySub'
Crear un grupo de recursos

Una vez configurada la suscripción de Azure, cree un grupo de recursos en Azure mediante Azure Portal o la CLI
de Azure.
Para usar Azure Portal, siga estos pasos:
1. Abra Grupos de recursos y seleccione Agregar .
2. Escriba el nombre de la suscripción, un nombre de grupo de recursos y una región. Consulte
Residencia de datos en Azure para obtener una lista de las regiones disponibles. Anote el nombre
del grupo de recursos que especifique para que pueda usar ese nombre en pasos posteriores.
Para usar la CLI de Azure para crear un grupo de recursos, escriba este comando:
az group create -l <region> -n <resource group name> -s '<subscription name>'
Por ejemplo, escriba:

az group create -l eastus -n manual_migration -s 'ComputePM LibrarySub'
El valor que se proporciona con el parámetro -l especifica la ubicación predeterminada. Utilice la

misma ubicación que se usó en pasos anteriores. Anote el nombre del grupo de recursos que cree para
que pueda usarlo en pasos posteriores.
Crear una cuenta de almacenamiento

A continuación, cree una cuenta de almacenamiento dentro del grupo de recursos que acaba de crear: Usará
esta cuenta de almacenamiento para realizar copias de seguridad de los datos de Moodle locales.
Puede usar Azure Portal o la CLI de Azure para crear una cuenta de almacenamiento.
Para usar Azure Portal, siga estos pasos:
1. Vaya a Crear cuenta de almacenamiento .
2. Escribe la siguiente información:
El nombre de la suscripción de Azure
El nombre del grupo de recursos que acaba de crear
Un nombre de la cuenta de almacenamiento
Su región
3. En Tipo de cuenta , seleccione BlobStorage en la lista desplegable.
4. En Replicación , seleccione Almacenamiento con redundancia geográfica con acceso de
lectura (RA-GRS) en la lista desplegable.
Para usar la CLI de Azure para crear la cuenta de almacenamiento, escriba este comando:
az storage account create -n <storage account name> -g <resource group name> --sku <storage account
SKU> --kind <storage account type> -l <region>

az storage account create -n onpremisesstorage -g manual_migration --sku Standard_LRS --kind
BlobStorage -l eastus
El parámetro --kind especifica el tipo de cuenta de almacenamiento.
Copia de seguridad de los datos locales

Antes de realizar una copia de seguridad de los datos de Moodle locales, active el modo de mantenimiento
en el sitio web de Moodle siguiendo estos pasos:
1. En la instancia de Moodle en su entorno local, escriba este comando:
sudo /usr/bin/php admin/cli/maintenance.php --enable
2. Escriba el siguiente comando para comprobar el estado del sitio web de Moodle:
sudo /usr/bin/php admin/cli/maintenance.php
Debe realizar las copias de seguridad de los archivos moodledata y Moodle locales, las configuraciones y las
bases de datos en un único directorio. En el diagrama siguiente se resume esta recomendación:
Creación de un directorio de almacenamiento

Para copiar los datos, cree un directorio de almacenamiento vacío en cualquier ubicación que desee. Por
ejemplo, si la ubicación es /home/azureadmin , escriba estos comandos:
sudo -s
cd /home/azureadmin
mkdir storage
Copia de seguridad de directorios de Moodle

En el entorno local, el directorio moodle contiene contenido HTML del sitio web. El directorio moodledata
contiene datos del sitio web de Moodle.
Escriba estos comandos para copiar los archivos de los directorios moodle y moodledata en el directorio de
almacenamiento:
cp -R /var/www/html/moodle /home/azureadmin/storage/
cp -R /var/moodledata /home/azureadmin/storage/
Copia de seguridad de las configuraciones de PHP y el servidor web

Para realizar una copia de seguridad de los archivos de configuración, siga estos pasos:
1. Escriba estos comandos para crear un nuevo directorio en el directorio de almacenamiento:
cd /home/azureadmin/storage
mkdir configuration
2. Escriba estos comandos para copiar los archivos de configuración de PHP y NGINX:
cp -R /etc/php /home/azureadmin/storage/configuration/
cp -R /etc/nginx /home/azureadmin/storage/configuration/
El directorio php almacena los archivos de configuración de PHP, como php-fpm.conf , php.ini , pool.d
y conf.d . El directorio nginx almacena las configuraciones de nginx, como nginx.conf y
sites-enabled/dns.conf .
Copia de seguridad de la base de datos

Siga estos pasos para realizar una copia de seguridad de la base de datos:
1. Escriba estos comandos para comprobar si mysql-client está instalado:
sudo -s
mysql -V
2. Si mysql-client está instalado, omita este paso. En caso contrario, escriba este comando para instalar
mysql-client:
sudo apt-get install mysql-client
3. Escriba este comando para hacer una copia de seguridad de la base de datos:
mysqldump -h <database server name> -u <database user ID> -p<database password> <database name> >
/home/azureadmin/storage/database.sql
Para <database server name> , <database user ID> , <database password> y <database name> , use los
valores que usa la base de datos local.
Creación de un archivo
Escriba este comando para crear un archivo de almacenamiento, storage.tar.gz , para el directorio de copia de
seguridad:
cd /home/azureadmin/ tar -zcvf storage.tar.gz storage
Descarga e instalación de AzCopy

Especifique los siguientes comandos para instalar AzCopy:
sudo -s
wget https://aka.ms/downloadazcopy-v10-linux
tar -xvf downloadazcopy-v10-linux
sudo rm /usr/bin/azcopy
sudo cp ./azcopy_linux_amd64_*/azcopy /usr/bin/
Copia de los archivos almacenados en Azure Blob Storage

Siga estos pasos para utilizar AzCopy para copiar los archivos locales archivados en Azure Blob Storage.
Generación de un token de seguridad
Para generar un token de firma de acceso compartido (SAS) para AzCopy, siga estos pasos:
1. En Azure Portal, vaya a la página de la cuenta de almacenamiento que creó anteriormente.
2. En el panel izquierdo, seleccione Firma de acceso compar tido .
3. En Tipos de recursos permitidos , seleccione Contenedor .

4. En Fecha y hora de inicio y caducidad , escriba una hora de inicio y de finalización para el token de
SAS.
5. Seleccione Generar la cadena de conexión y SAS .
6. Realice una copia del token de SAS para usarlo en pasos posteriores.
Crear un contenedor
Cree un contenedor en la cuenta de almacenamiento. Puede usar la CLI de Azure o Azure Portal para este paso.
Para usar la CLI de Azure, escriba este comando:
az storage container create --account-name <storage account name> --name <container name> --auth-mode
login

az storage container create --account-name onpremisesstorage --name migration --auth-mode login
Cuando se usa el parámetro --auth-mode con un valor de login , Azure usa sus credenciales para la
autenticación y, a continuación, crea el contenedor.
Para usar Azure Portal para crear el contenedor, siga estos pasos:
1. En el portal, vaya a la página de la cuenta de almacenamiento que creó anteriormente.
2. Seleccione Contenedor y, luego, seleccione Agregar .
3. Escriba un nombre para el contenedor y, después, seleccione Crear .
Copia del archivo de almacenamiento en Azure Blob Storage
Escriba este comando para copiar el archivo de almacenamiento en el contenedor que creó en Blob Storage:
sudo azcopy copy /home/azureadmin/storage.tar.gz 'https://<storage account

name>.blob.core.windows.net/<container name>/<SAS token>'

azcopy copy /home/azureadmin/storage.tar.gz 'https://onpremisesstorage.blob.core.windows.net/migration/?
sv=2019-12-12&ss='
Su cuenta de Blob Storage ahora debe contener una copia del archivo.
Pasos siguientes
Continúe con Arquitectura y plantillas de migración de Moodle.
Arquitectura y plantillas de migración de Moodle
La migración de Moodle a Azure incluye las tareas siguientes:

1. Implementación de la infraestructura de Azure con plantillas de Azure Resource Manager.
2. Descarga e instalación de AzCopy.
3. Copia del archivo de copia de seguridad de Moodle en la máquina virtual controladora en la implementación
de Azure Resource Manager.
4. Migración de la aplicación y configuración de Moodle.
5. Configuración de la instancia de la controladora de Moodle y los nodos de trabajo.
6. Configuración de PHP y el servidor web.
En este artículo se describen las opciones de la infraestructura de Azure para Moodle y cómo implementar los
recursos de Azure mediante el uso de una plantilla de ARM que ofrece su elección de funcionalidades de Azure.
Infraestructura de Azure
En el diagrama siguiente se proporciona información general sobre los recursos de la infraestructura de Azure
para Moodle:
Opciones de la plantilla de Resource Manager

Para implementar recursos de Moodle en Azure, puede usar una plantilla de Resource Manager totalmente
configurable o una de las diversas plantillas predefinidas. Una implementación totalmente configurable es la
que ofrece la mayor flexibilidad y el mayor número de opciones de implementación. Puede encontrar la plantilla
totalmente configurable y las plantillas predefinidas en el repositorio de Moodle en GitHub.
Una plantilla de implementación predefinida usa uno de los cuatro tamaños de Moodle predefinidos: mínimo,
pequeño y mediano, grande o máximo.
La implementación mínima solo requiere dos máquinas virtuales por lo que funciona con una
suscripción de evaluación gratuita de Azure. Esta implementación usa Network File System (NFS), MySQL
y una SKU más pequeña de máquina virtual de front-end web de escalado automático con un núcleo
virtual. Esta plantilla tiene un tiempo de implementación rápido de menos de 30 minutos.
La implementación de tamaño pequeño a mediano admite hasta 1 000 usuarios simultáneos. Esta
implementación usa NFS, sin alta disponibilidad y MySQL en ocho núcleos virtuales. Esta
implementación no incluye opciones como Elasticsearch o Azure Cache for Redis.
La implementación grande y de alta disponibilidad admite más de 2 000 usuarios simultáneos. Esta
implementación usa Azure Files, MySQL con 16 núcleos virtuales y Azure Cache for Redis, pero no otras
opciones, como Elasticsearch.
La implementación de tamaño máximo usa Azure Files, MySQL con la SKU más alta, Azure Cache for
Redis, Elasticsearch en tres máquinas virtuales y tamaños de almacenamiento grandes para discos de
datos y bases de datos.
Implementación de la plantilla
Para implementar una de las plantillas predefinidas de Resource Manager:
1. En la sección anterior, seleccione el botón Implementar en Azure para la implementación que desee.
Esta acción le lleva a Azure Portal.
2. En la página Implementación personalizada de Azure Portal, complete los campos obligatorios
Suscripción , Grupo de recursos , Región y Clave pública SSH . Para más información sobre cómo
agregar la clave SSH, consulte Generación de una clave SSH nueva y su adición al agente de SSH.
Edición de la plantilla
Las plantillas de Resource Manager predefinidas implementan las siguientes versiones de software
predeterminadas:
Ubuntu: 18.04 LTS
PHP: 7.4
Moodle: 3.8
Si las versiones de PHP y Moodle locales difieren de los valores anteriores, actualice las versiones de las
plantillas para que coincidan siguiendo estos pasos:
1. En Azure Portal, en la página Implementación personalizada de la plantilla de Resource Manager,
seleccione Editar plantilla .
2. En la sección Recursos de la plantilla, en parámetros , agregue los parámetros de las versiones de
Moodle y PHP.
"phpVersion": { "value": "7.2" },

"moodleVersion": { "value": "MOODLE_38_STABLE"}
Por ejemplo, en el caso de Moodle 3.9, el valor moodleVersion debe ser MOODLE_39_STABLE .
Pasos siguientes
Pase al artículo Recursos de migración de Moodle para obtener información sobre los recursos que la plantilla
de Resource Manager implementa en Azure.
Recursos de migración de Moodle
Cuando se usa una plantilla de Azure Resource Manager para migrar Moodle, la implementación crea recursos
dentro de Azure. Como parte de este proceso de implementación, las implementaciones adicionales se ejecutan
automáticamente a través de plantillas secundarias. En las secciones siguientes se describen estas
implementaciones y los recursos que crean.
Plantilla de red
La implementación de la plantilla de red crea los siguientes recursos:
Azure Virtual Network: una representación de su propia red en la nube. Una red virtual es un aislamiento
lógico de la nube de Azure dedicado a su suscripción. Cuando se crea una red virtual, los servicios y las
máquinas virtuales de la red virtual pueden comunicarse de manera directa y segura en la nube. La red
virtual que crea la plantilla de red incluye el nombre de la red virtual, la versión de la API, la ubicación, el
nombre del servidor DNS y el espacio de direcciones. El espacio de direcciones contiene un intervalo de
direcciones IP que pueden usar las subredes.
Grupo de seguridad de red (NSG): un filtro de red, o firewall, que contiene una lista de reglas de
seguridad. Estas reglas permiten o deniegan el tráfico de red a los recursos conectados a una red virtual.
Interfaz de red: una interfaz que una máquina virtual de Azure puede usar para comunicarse con los
recursos de Internet, Azure y locales.
Subred: una red más pequeña dentro de una red de mayor tamaño. A estas redes más pequeñas se las
conoce como subredes. De forma predeterminada, una dirección IP de una subred se puede comunicar
con cualquier otra dirección IP dentro de la red virtual.
Dirección IP pública: una dirección IP que un recurso de Azure usa para comunicarse con Internet. La
dirección está dedicada al recurso de Azure.
Azure Load Balancer: un distribuidor de carga que distribuye eficazmente el tráfico de red o de
aplicaciones entre varios servidores de una granja de servidores. Load Balancer garantiza una alta
disponibilidad y confiabilidad mediante el envío de solicitudes solo a los servidores que están en línea.
Azure Application Gateway: una alternativa a Load Balancer. Las cuatro plantillas de Resource Manager
predefinidas implementan Load Balancer. Si usa una implementación totalmente configurable en lugar de
una plantilla de Resource Manager, puede elegir Application Gateway en lugar de Load Balancer.
Application Gateway es un equilibrador de carga de tráfico web que puede usar para administrar el
tráfico a las aplicaciones web. Application Gateway puede tomar decisiones de enrutamiento basadas en
los atributos adicionales de una solicitud HTTP, como una ruta de acceso de identificador URI o un
encabezado host.
Azure Cache for Redis: un almacén de datos en memoria basado en el software de código abierto Redis.
Redis mejora el rendimiento y la escalabilidad de una aplicación que usa en gran medida los almacenes
de datos de back-end. Puede procesar grandes volúmenes de solicitudes de aplicación al mantener los
datos a los que se accede con frecuencia en la memoria del servidor. Estos datos se pueden escribir y leer
rápidamente.
Plantilla de almacenamiento
La implementación de la plantilla de la cuenta de almacenamiento crea una cuenta de Azure Storage de tipo
FileStorage. La cuenta tiene un rendimiento premium, replicación de almacenamiento con redundancia local
(LRS) y 1 terabyte de almacenamiento. La plantilla predefinida está configurada de manera que una cuenta de
almacenamiento con Azure Files crea recursos compartidos de archivos.
Una cuenta de Azure Storage contiene objetos de datos de Azure Storage como blobs, archivos, colas, tablas y
discos. La cuenta de almacenamiento proporciona un espacio de nombres único para los datos de Azure Storage
que es accesible desde cualquier lugar del mundo mediante HTTP o HTTPS. Están disponibles los siguientes
tipos de cuentas de Azure Storage: Uso general v1, Uso general v2, BlockBlobStorage, FileStorage y Blob Storage.
El tipo de replicación puede ser con redundancia geográfica o LRS, y el almacenamiento con redundancia de
zona. Los tipos de rendimiento son Estándar y Premium, y una cuenta de almacenamiento individual puede
almacenar hasta 500 TB de datos como cualquier otro servicio de Azure.
Las plantillas de Resource Manager admiten los siguientes tipos de cuentas de almacenamiento:
Network File System (NFS): un tipo de cuenta que puede usar un host remoto para montar sistemas de
archivos en una red. El host remoto puede interactuar con esos sistemas de archivos como si estuvieran
montados localmente. Con este diseño, los administradores del sistema pueden consolidar los recursos
en servidores centralizados en la red.
GlusterFS: un sistema de archivos distribuido de código abierto que se puede escalar horizontalmente en
bloques de creación para almacenar varios petabytes de datos.
Azure Files: el único almacenamiento de archivos en la nube pública que ofrece recursos compartidos de
archivos en la nube seguros, basados en SMB y totalmente administrados que también se pueden
almacenar en caché de forma local para el rendimiento y la compatibilidad. Para NFS y GlusterFS, la
replicación es LRS estándar y el tipo de almacenamiento es Uso general v1. Para Azure Files, la
replicación es LRS, y el tipo es FileStorage.
Estos mecanismos de almacenamiento son diferentes en función de la implementación que elija. NFS y
GlusterFS crean un contenedor y Azure Files crea un recurso compartido de archivos. En el caso del tamaño de
Moodle mínimo y del tamaño pequeño y medianos, la plantilla admite NFS. Con los tamaños grande y máximo,
la plantilla admite Azure Files. Para acceder a los contenedores y a los recursos compartidos de archivos, vaya a
Azure Portal y seleccione la cuenta de almacenamiento en el grupo de recursos.
Plantilla de base de datos

La implementación de la plantilla de base de datos crea un servidor de Azure Database for MySQL. Azure
Database for MySQL es fácil de configurar, administrar y escalar. Automatiza la administración y el
mantenimiento de la infraestructura y el servidor de base de datos, incluidas las actualizaciones rutinarias, las
copias de seguridad y la seguridad. Azure Database for MySQL se ha creado con la última edición de la
comunidad de MySQL, incluidas las versiones 5.6, 5.7 y 8.0. Para acceder al servidor de bases de datos que crea
la plantilla, vaya a Azure Portal y abra el grupo de recursos que proporciona el proceso de implementación. A
continuación, vaya a Ser vidor de Azure Database for MySQL . La plantilla asigna al servidor de base de
datos un nombre de servidor, un nombre de inicio de sesión de administrador del servidor, una versión de
MySQL y una configuración de rendimiento.
Plantilla de máquina virtual

La implementación de la plantilla de máquina virtual designa una máquina virtual como máquina virtual
controladora. El sistema operativo de la máquina virtual controladora es Ubuntu 18.04.
Las extensiones de máquina virtual son pequeñas aplicaciones que realizan tareas de automatización y
configuración posterior a la implementación en Azure Virtual Machines. Una extensión de máquina virtual
ejecuta un script del shell que instala Moodle en la máquina virtual controladora y captura los archivos de
registro. Crea los archivos de registro stderr y stdout en la carpeta
/var/lib/waagent/custom-script/download/0/ . Puede ver estos archivos como usuario raíz.
Plantilla de conjunto de escalado

La implementación de la plantilla del conjunto de escalado crea un conjunto de escalado de máquinas virtuales.
Mediante un conjunto de escalado de máquinas virtuales puede implementar y administrar un conjunto de
máquinas virtuales de escalabilidad automática. Puede escalar el número de máquinas virtuales del conjunto de
escalado manualmente o definir reglas de escalado automático según el uso de recursos tales como la CPU, la
demanda de memoria o el tráfico de red. Cuando una instancia se escala verticalmente, implementa una
máquina virtual. Después, se ejecuta un script de Shell que instala los requisitos previos de Moodle y configura
los trabajos cron. Una máquina virtual de un conjunto de escalado tiene una dirección IP privada. Para más
información sobre cómo ver las instancias de máquina virtual de un conjunto de escalado y cómo acceder a
estas instancias, consulte la documentación del conjunto de escalado de máquinas virtuales.
Pasos siguientes
Continúe en Pasos de la migración manual de Moodle para los siguientes pasos del proceso de migración de
Moodle.
Pasos de la migración manual de Moodle
En este artículo se describen los pasos necesarios para migrar el archivo de Moodle local a Azure. El contenido
de este archivo de Moodle incluye la aplicación Moodle, la configuración correspondiente y una copia de la base
de datos de la implementación de Moodle local. Una vez que haya importado correctamente la copia de
seguridad local en la infraestructura de Azure, deberá realizar las actualizaciones de configuración de Moodle.
Antes de comenzar este proceso, asegúrese de completar todos los pasos de estos artículos:
Preparación de una migración de Moodle
Arquitectura y plantillas de migración de Moodle
Una vez finalizada la implementación de la plantilla de Azure Resource Manager (ARM), inicie sesión en Azure
Portal y vaya al grupo de recursos que creó como parte del proceso de implementación. Revise la lista de
recursos de infraestructura recién creados. Los recursos creados tienen un aspecto similar al de la siguiente
imagen, en función de la plantilla de ARM utilizada para la implementación.
Copia del archivo de Moodle

El primer paso del proceso de migración es copiar el archivo de copia de seguridad de Moodle desde Azure Blob
Storage a la máquina virtual del controlador para la implementación de moodle. Este es el mismo archivo que
creó en Creación de un archivo.
Inicio de sesión en la máquina virtual controladora
1. Use un emulador de terminal de código abierto gratuito o una herramienta de la consola serie como
PuTTY para iniciar sesión en una máquina virtual controladora.
2. En PuTTY Configuration (Configuración de PuTTY), escriba la dirección IP pública de la máquina virtual
controladora como Host Name (Nombre de host).
3. En la barra de navegación de la izquierda, expanda SSH .
4. Seleccione Auth (Autenticación) y busque el archivo de clave SSH que usó para implementar la
infraestructura de Azure con la plantilla de Resource Manager.
5. seleccione Open (Abrir). Como nombre de usuario, escriba azureadmin , ya que está codificado de forma
rígida en la plantilla.
Para más información acerca de PuTTY, consulte Preguntas generales más frecuentes y preguntas sobre solución
de problemas.
Descarga e instalación de AzCopy en la máquina virtual controladora
Después de iniciar sesión en la máquina virtual controladora, ejecute los siguientes comandos para instalar
AzCopy:
sudo -s
wget https://aka.ms/downloadazcopy-v10-linux
tar -xvf downloadazcopy-v10-linux
sudo rm /usr/bin/azcopy
sudo cp ./azcopy_linux_amd64_*/azcopy /usr/bin/
Copia de seguridad de la configuración actual

Antes de iniciar el proceso de importación, se recomienda realizar una copia de seguridad de la configuración
predeterminada o actual.
1. Cree un directorio de copia de seguridad:
cd /home/azureadmin/
mkdir -p backup
mkdir -p backup/moodle
mkdir -p backup/moodle/html
2. Cree copias de seguridad de los directorios moodle y moodledata :
mv /moodle/html/moodle /home/azureadmin/backup/moodle/html/moodle
mv /moodle/moodledata /home/azureadmin/backup/moodle/moodledata
Copia del archivo de Moodle en la máquina virtual controladora

1. Ejecute los siguientes comandos para descargar el archivo de copia de seguridad comprimido
storage.tar.gz de Azure Blob Storage en el directorio /home/azureadmin/ de la máquina virtual
controladora:
sudo -s
azcopy copy "https://<storageaccount>.blob.core.windows.net/<container>/<BlobDirectoryName>
<SAStoken>" "/home/azureadmin/storage.tar.gz"
Sustituya los datos por los de su cuenta de almacenamiento y los valores de token de SAS. Por ejemplo:
azcopy copy "https://onpremisesstorage.blob.core.windows.net/migration/storage.tar.gz?sv=2019-12-
12&ss=" "/home/azureadmin/storage.tar.gz"
2. Extraiga el archivo comprimido en un directorio.
cd /home/azureadmin
tar -zxvf storage.tar.gz
Importación de los archivos de Moodle en Azure

Una vez extraído, puede encontrar el directorio storage en home/azureadmin . El directorio storage contiene los
directorios moodle , moodledata y configuration , y un archivo de copia de seguridad de la base de datos. En los
pasos siguientes, va a copiar cada uno de estos archivos y directorios en las ubicaciones de destino:
1. Copie los directorios moodle y moodledata en una ubicación compartida en /moodle .
cp -rf /home/azureadmin/storage/moodle /moodle/html/

cp -rf /home/azureadmin/storage/moodledata /moodle/moodledata
Importación de la base de datos de Moodle a Azure

Conéctese al servidor de Azure Database for MySQL e importe el archivo de base de datos de Moodle local a
Conexión al servidor MySQL
Las instancias de Azure Database for MySQL están protegidas por un firewall. De forma predeterminada, se
rechazan todas las conexiones al servidor y a las bases de datos del servidor. Antes de conectarse a Azure
Database for MySQL por primera vez, configure el firewall para permitir el acceso a la dirección IP (o intervalo
de direcciones IP) pública de la máquina virtual controladora.
Puede configurar el firewall mediante la línea de comandos de Azure (CLI de Azure) o Azure Portal.
Ejecute el siguiente comando de la CLI de Azure, sustituyendo los marcadores de posición por sus propios
valores:
az mysql server firewall-rule create --resource-group <myresourcegroup> --server <mydemoserver> --name

<AllowMyIP> --start-ip-address <192.168.0.1> --end-ip-address <192.168.0.1>
O bien, en Azure Portal, seleccione el servidor de Azure Database for MySQL de entre los recursos de
infraestructura de Moodle implementados. En la barra de navegación izquierda de la página del servidor,
seleccione Seguridad de la conexión .
Puede agregar direcciones IP permitidas y configurar las reglas de firewall aquí. Seleccione Guardar después de
crear las reglas.
Ahora puede conectarse al servidor MySQL con la herramienta de la línea de comandos mysql o con MySQL
Workbench.
Para obtener la información de la conexión, vaya a la página Información general de MySQL Server en Azure
Portal. Use los iconos de copia situados junto a cada campo para copiar el nombre del ser vidor y el nombre
de inicio de sesión del administrador del ser vidor .
Por ejemplo, el nombre del servidor podría ser mydemoserver.mysql.database.azure.com y el de inicio de sesión
del administrador del servidor podría ser myadmin@mydemoserver .
También necesitará la contraseña. Si tiene que restablecer la contraseña, seleccione Restablecer la contraseña
en la barra de menús.
Use estos detalles del servidor de bases de datos en las siguientes secciones.
Importación de la base de datos de Moodle a Azure Database for MySQL
1. Cree una base de datos de MySQL para importar la base de datos local a:
mysql -h $server_name -u $server_admin_login_name -p$admin_password -e "CREATE DATABASE $moodledbname

CHARACTER SET utf8;"
2. Asigne los permisos correctos a la base de datos:
mysql -h $server_name -u $server_admin_login_name -p$admin_password -e "GRANT ALL ON $moodledbname.*

TO '$server_admin_login_name' IDENTIFIED BY '$admin_password';"
3. Importe la base de datos:
mysql -h $server_name -u $server_admin_login_name -p$admin_password $moodledbname <

/home/azureadmin/storage/database.sql
Actualización de las configuraciones

Después de importar el archivo de la base de datos de Moodle local en Azure Database for MySQL, actualice las
siguientes configuraciones de la máquina virtual controladora según sea necesario:
Actualice el archivo de configuración de Moodle.
Configure los permisos de directorio.
Configure los servidores web PHP y NGINX.
Actualice el nombre DNS y otras variables.
Instale todas las extensiones de PHP que falten.
Asegúrese de que las instancias del servidor web de la máquina virtual controladora estén detenidas.
Copie los archivos de configuración en una ubicación compartida para copiarlos en conjuntos de escalado de
Actualización del archivo de configuración de Moodle
Actualice los parámetros de detalles de la base de datos en el archivo de configuración de Moodle
/moodle/config.php .
Para obtener el nombre DNS de esta tarea:

1. En Azure Portal, seleccione la dirección IP pública del equilibrador de carga de los recursos de la
infraestructura de Moodle implementada.
2. En la página Información general , seleccione el icono de copia situado junto al nombre DNS .
Para actualizar el archivo config.php :
1. Escriba los siguientes comandos para editar config.php en el editor nano :
cd /moodle/html/moodle/
nano config.php
2. Actualice los detalles de la base de datos en el archivo con los valores que copió de Azure Portal:
$CFG->dbhost = 'localhost'; // Change 'localhost' to the server name.

$CFG->dbname = 'moodle'; // Change 'moodle' to the newly created database name.
$CFG->dbuser = 'root'; // Change 'root' to the server admin login name.
$CFG->dbpass = 'password'; // Change 'password' to the server admin login
password.
$CFG->wwwroot = 'https://on-premises.com'; // Change 'on-premises' to the DNS name.
$CFG->dataroot = '/var/moodledata'; // Change the path to '/moodle/moodledata'.
3. Después de realizar los cambios, pulse CTRL + O para guardar el archivo y CTRL + X para salir del editor.
Puede almacenar el directorio dataroot local en cualquier ubicación.
Configuración de los permisos de directorio
Asigne a owner:group los permisos 755 y www-data en el directorio moodle .
sudo chmod 755 /moodle/html/moodle sudo chown -R www-data:www-data /moodle/html/moodle
Asigne a owner:group los permisos 770 y www-data en el directorio moodledata .
sudo chmod 770 /moodle/moodledata sudo chown -R www-data:www-data /moodle/moodledata
Actualización de los archivos de configuración web

Realice una copia de seguridad y actualice el archivo conf de NGINX:
sudo mv /etc/nginx/sites-enabled/*.conf /home/azureadmin/backup/

cd /home/azureadmin/storage/configuration/
sudo cp -rf nginx/sites-enabled/*.conf /etc/nginx/sites-enabled/
Realice una copia de seguridad y actualice el archivo www.conf de PHP:
_PHPVER='/usr/bin/php -r "echo PHP_VERSION;" | /usr/bin/cut -c 1,2,3'

echo $_PHPVER
sudo mv /etc/php/$_PHPVER/fpm/pool.d/www.conf /home/azureadmin/backup/www.conf
sudo cp -rf /home/azureadmin/storage/configuration/php/$_PHPVER/fpm/pool.d/www.conf
/etc/php/$_PHPVER/fpm/pool.d/
Actualización de las variables de configuración de NGINX

Actualice el nombre DNS de la nube de Azure al nombre DNS de la aplicación de Moodle local.
1. Abra el archivo de configuración de NGINX:
nano /etc/nginx/sites-enabled/*.conf
2. La implementación de la plantilla de ARM establece el servidor NGINX en el puerto 81. Cambie a 81 el

valor SERVER_PORT del archivo si su valor es diferente.
3. Actualice el server_name . Por ejemplo, para un server_name on-premises.com , cambie on-premises.com al
nombre DNS. En la mayoría de los casos, el nombre DNS no cambia en la migración.
4. Actualice la ubicación del directorio root de HTML. Por ejemplo, actualice root /var/www/html/moodle; a
root /moodle/html/moodle; .
El directorio raíz local puede estar en cualquier ubicación.

5. Después de realizar los cambios, pulse CTRL + O para guardar el archivo y CTRL + X para salir.
Instalación de todas las extensiones de PHP que faltan
Las plantillas de implementación de ARM instalan las siguientes extensiones de PHP:
fpm
cli
curl
zip
pear
mbstring
dev
mcrypt
soap
json
redis
bcmath
gd
mysql
xmlrpc
intl
xml
bz2
Si la aplicación de Moodle local tiene extensiones PHP que no se encuentran en la máquina virtual controladora,
puede instalarlas manualmente.
Para obtener la lista de extensiones PHP en la aplicación local, ejecute:
php -m
Para instalar las extensiones de PHP que faltan, ejecute:
sudo apt-get install -y php-<extension>
Asegurarse de que las instancias del servidor web de la máquina virtual controladora estén detenidas
1. Reinicie los servidores web.
sudo systemctl restart nginx

sudo systemctl restart php$_PHPVER-fpm
2. Detenga los servidores web.

sudo systemctl stop nginx
sudo systemctl stop php$_PHPVER-fpm
Cuando una solicitud llega a Azure Load Balancer, ahora se redirige a las instancias del conjunto de escalado de
máquinas virtuales, pero no a la máquina virtual controladora.
Copia de los archivos de configuración
Copie los archivos de configuración de PHP y del servidor web en una ubicación compartida para copiarlos
posteriormente en instancias del conjunto de escalado de máquinas virtuales.
Para crear un directorio para los archivos de configuración en una ubicación compartida, ejecute:
mkdir -p /moodle/config
mkdir -p /moodle/config/php
mkdir -p /moodle/config/nginx
Para copiar los archivos de configuración del servidor web y de PHP en un directorio compartido, ejecute:
cp /etc/nginx/sites-enabled/* /moodle/config/nginx
cp /etc/php/$_PHPVER/fpm/pool.d/www.conf /moodle/config/php
Pasos siguientes
Continúe con Configuración de la instancia de la controladora y los nodos de trabajo de Moodle para ver los
pasos siguientes del proceso de migración de Moodle.
Configuración de nodos de trabajo de Moodle
Siga estos pasos para configurar un conjunto de escalado de máquinas virtuales, o nodos de trabajo, para
Moodle.
Instancias del conjunto de escalado de máquinas virtuales

Se asigna una dirección IP privada a una instancia de conjunto de escalado de máquinas virtuales. Solo puede
acceder a esta dirección IP con una máquina virtual controladora que se encuentra en la misma red virtual que
la dirección IP. En este artículo se describe cómo configurar esa dirección IP y, después, el conjunto de escalado
de máquinas virtuales de Azure que crea la migración de Moodle.
Acceso al conjunto de escalado de máquinas virtuales
Siga estos pasos para acceder al conjunto de escalado de máquinas virtuales:
1. Determine la dirección IP privada que usa Azure para la instancia del conjunto de escalado de máquinas
virtuales:
a. Inicie sesión en Azure Portal y busque el grupo de recursos que creó la implementación.
b. Abra la página de recurso del conjunto de escalado de máquinas virtuales.
c. En el panel izquierdo, seleccione Instancias .
d. Abra la instancia en ejecución. En la sección Información general , copie la dirección IP privada
asociada a esa instancia.
2. Escriba estos comandos para iniciar sesión en el conjunto de escalado de máquinas virtuales desde la
máquina virtual controladora:
sudo -s
sudo ssh azureadmin@<private IP address>
En el comando, <private IP address> es la dirección IP privada del conjunto de escalado de máquinas

virtuales. Por ejemplo, escriba:
sudo -s
sudo ssh [email protected]
Creación de un directorio de copia de seguridad

Un paso anterior del proceso de migración extrajo los archivos de copia de seguridad a un directorio
denominado storage en /home/azureadmin . Este directorio storage contiene los directorios moodle y
moodledata , un directorio de configuración y un archivo de copia de seguridad de base de datos. Después de
iniciar sesión en la instancia de la máquina virtual del conjunto de escalado, escriba estos comandos para crear
un directorio de copia de seguridad para estos archivos:
mkdir -p backup
mkdir -p backup/moodle
Configuración de PHP y el servidor web
Para configurar PHP y el servidor web, siga estos pasos:
1. Establezca la versión de PHP en una variable:
_PHPVER=`/usr/bin/php -r "echo PHP_VERSION;" | /usr/bin/cut -c 1,2,3`

echo $_PHPVER
2. Cree una copia de seguridad de las configuraciones de PHP y el servidor web:
sudo mv /etc/nginx/sites-enabled/*.conf /home/azureadmin/backup/

sudo mv /etc/php/$_PHPVER/fpm/pool.d/www.conf /home/azureadmin/backup/www.conf
3. Copie los archivos de configuración de PHP y del servidor web:
sudo cp /moodle/config/nginx/*.conf /etc/nginx/sites-enabled/

sudo cp /moodle/config/php/www.conf /etc/php/$_PHPVER/fpm/pool.d/
Instalación de las extensiones que faltan

Para instalar las extensiones que faltan, siga estos pasos:
1. Para obtener una lista de extensiones de PHP que están instaladas en el entorno local, escriba el siguiente
comando en una máquina virtual local:
php -m
2. Use una plantilla de Azure Resource Manager para instalar las siguientes extensiones de PHP:
fpm
cli
curl
zip
pear
mbstring
dev
mcrypt
soap
json
redis
bcmath
gd
mysql
xmlrpc
intl
xml
bz2
3. Si la aplicación de Moodle local tiene extensiones de PHP que no se encuentran en la máquina virtual
controladora, puede instalarlas manualmente con este comando:
sudo apt-get install -y php-<extension name>
Pasos siguientes
Continúe en Cómo continuar después de una migración de Moodle.
Cómo continuar después de una migración de
Moodle
Pasos posteriores a la migración

Después de la migración de Moodle, debe realizar algunas tareas posteriores a la migración para completar la
configuración. Entre las tareas, se incluyen las siguientes:
Actualización de las rutas de acceso de registro en instancias de conjuntos de escalado de máquinas
virtuales.
Reinicio de servidores en instancias de conjuntos de escalado de máquinas virtuales.
Actualización de los certificados.
Actualización de las ubicaciones de los certificados.
Actualización de la copia HTML local.
Reinicio de los servidores NGINX y PHP.
Asignación del nombre DNS a la dirección IP de la instancia de Azure Load Balancer.
Conjunto de escalado de máquinas virtuales del controlador

Siga estos pasos para finalizar la configuración del conjunto de escalado de máquinas virtuales. Tendrá que
conectarse mediante SSH a la instancia del conjunto de escalado de máquinas virtuales mediante la dirección IP
privada, como se describe en Acceso al conjunto de escalado de máquinas virtuales.
Actualización de las rutas de acceso de registro
El entorno local y Azure pueden almacenar archivos de registro en diferentes ubicaciones. Por ejemplo, puede
que tenga que actualizar estas rutas de acceso de registro:
/var/log/syslogs/moodle/access.log
/var/log/syslogs/moodle/error.log
Siga estos pasos para actualizar las ubicaciones de los archivos de registro:
1. Use este comando para abrir el archivo de configuración:
nano /etc/nginx/nginx.conf
2. Busque access_log y error_log , y actualice las rutas de acceso de registro.

3. Pulse CTRL + O para guardar los cambios y CTRL + X para cerrar el archivo.
Reinicio de los servidores
Escriba estos comandos para reiniciar los servidores nginx y php-fpm :

sudo systemctl restart php<php version>-fpm
Máquina virtual del controlador

Siga estos pasos para completar la configuración de la máquina virtual controladora.
Actualización de certificados de seguridad
1. Inicie sesión en la máquina virtual controladora. Puede encontrar los certificados de la aplicación Moodle
en la carpeta /moodle/certs .
2. Copie los archivos .crt y .key en /moodle/certs/ . Cambie los nombres de archivo a nginx.crt y
nginx.key , respectivamente, para que los servidores NGINX configurados los reconozcan. Si el entorno
local admite la utilidad SCP o una herramienta como WinSCP, puede usarlas para copiar estos archivos en
la máquina virtual controladora. En caso contrario, utilice estos comandos:
cd /<path to certs location>

mv /<path to certs location>/*.key /moodle/certs/nginx.key
mv /<path to certs location>/*.crt /moodle/certs/nginx.crt
Como alternativa a copiar los archivos, use estos comandos para generar un certificado autofirmado:
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \

-keyout /moodle/certs/nginx.key \
-out /moodle/certs/nginx.crt \
-subj "/C=US/ST=WA/L=Redmond/O=IT/CN=mydomain.com"
Solo puede usar un certificado autofirmado para las pruebas.

3. Se recomienda que los archivos del certificado sean propiedad de www-data:www-data y que sean de solo
lectura para el propietario. Escriba estos comandos para realizar estos cambios:
chown www-data:www-data /moodle/certs/nginx.*

chmod 400 /moodle/certs/nginx.*
4. Siga estos pasos para actualizar la ubicación del certificado:

a. Use este comando para abrir el archivo de configuración:
nano /etc/nginx/sites-enabled/*.conf
b. Busque ssl_certificate en el archivo.

c. Reemplace las rutas de acceso del certificado por estos valores:
/moodle/certs/moodle/certs/nginx.crt;
/moodle/certs/nginx.key;
d. Pulse CTRL + O para guardar los cambios y CTRL + X para cerrar el archivo.
Actualización de la copia HTML local
La copia local del contenido del sitio HTML de Moodle, /moodle/html/moodle , se crea en el conjunto de escalado
de máquinas virtuales en esta carpeta: /var/www/html/moodle . La copia local solo se actualiza cuando cambia la
marca de tiempo. Escriba este comando en la máquina virtual controladora para actualizar la marca de tiempo:
sudo -s
/usr/local/bin/update_last_modified_time.moodle_on_azure.sh
El archivo de la marca de tiempo de la última modificación,
/moodle/html/moodle/last_modified_time.moodle_on_azure , contiene un script. Cada vez que se ejecuta el script, el
contenido del directorio /moodle/html/moodle se actualiza en la copia local /var/www/html .
Reinicio de los servidores
Escriba estos comandos para reiniciar los servidores nginx y php-fpm :

sudo systemctl restart php<php version>-fpm
Asignación del nombre DNS a la dirección IP de la instancia de Azure Load Balancer

Siga estos pasos en el nivel de proveedor de hospedaje para asignar el nombre DNS a la dirección IP de la
instancia de Azure Load Balancer:
1. Escriba el siguiente comando en la máquina virtual controladora para desactivar el modo de
mantenimiento en el sitio web de Moodle:
sudo /usr/bin/php admin/cli/maintenance.php --disable
2. Escriba este comando para comprobar el estado del sitio web de Moodle:
sudo /usr/bin/php admin/cli/maintenance.php
3. Vaya al nombre DNS para consultar la página web de Moodle migrada.
Preguntas más frecuentes y solución de problemas

Consulte la siguiente información si tiene preguntas sobre la migración de Moodle. Estos archivos de registro
también pueden ayudarle a solucionar problemas:
Archivos de Syslog:
Siempre que un usuario se dirige a la página web, el sistema genera un registro de error o un registro
de acceso.
Puede encontrarlos en esta carpeta: /var/log/nginx/ .
Archivo de registro de Cron:
Cuando se ejecuta un trabajo cron, este actualiza la copia local del archivo de registro.
Puede encontrar el archivo en esta carpeta: /var/log/sitelogs/moodle/cron.log .
Error de conexión de base de datos
En el caso de errores como No se pudo realizar la conexión de base de datos o No se pudo conectar a la base de
datos especificada, estas son algunas posibles razones y soluciones:
El servidor de base de datos no está instalado o no está en ejecución. Para comprobar esta condición en
MySQL, escriba el siguiente comando:
$telnet database_host_name 3306
Si la base de datos se está ejecutando, debería obtener una respuesta que incluye el número de versión
del servidor MySQL.
La dirección de host se ha configurado incorrectamente. Si intenta ejecutar dos instancias de Moodle en
puertos diferentes, utilice la dirección IP del host, no localhost , en la opción $CFG->dbhost . Por ejemplo,
use:
$CFG->dbhost = 127.0.0.1:3308
No ha creado una base de datos de Moodle. O bien, no ha asignado los permisos adecuados para acceder
a la base de datos. Compruebe la base de datos y los permisos que ha concedido.
La configuración de la base de datos de Moodle no es correcta. Por ejemplo, el nombre de la base de
datos, el nombre de usuario o la contraseña del archivo de configuración de Moodle, config.php , no son
correctos. Asegúrese de que el nombre de usuario y la contraseña de MySQL no contienen apóstrofos ni
caracteres no alfanuméricos.
Error interno del servidor
Hay varias causas posibles para este error: 500: Error interno del servidor. Para empezar, revise el registro de
errores del servidor web, que debería tener una explicación detallada. Estas son algunas posibilidades:
Hay un error de sintaxis en los archivos .htaccess o httpd.conf . La sintaxis correcta para las directivas
difiere en función del archivo que esté usando. Use el siguiente comando para comprobar los errores de
configuración en los archivos de NGINX:
`nginx -t`
El servidor web se ejecuta bajo su propio nombre de usuario y los permisos de acceso son incorrectos. En
este caso, todos los archivos necesitan un nivel de permiso máximo de 755. Compruebe que este nivel
está establecido para el directorio de Moodle en el panel de control. También puede usar este comando
para establecer el nivel si tiene acceso al shell:
chmod -R 755 moodle
Error de límite de memoria

Cuando se produce un error 403: Prohibido, el valor memory_limit de PHP no es suficientemente grande para el
script de PHP. El valor memory_limit es el tamaño de memoria permitido. Aumente el valor memory_limit de
PHP en pequeñas cantidades hasta que el mensaje desaparezca. Use uno de estos métodos:
En el caso de una instalación hospedada, debe preguntar al equipo de soporte técnico del host cómo
aumentar este valor. Muchos entornos usan archivos .htaccess . Si la instalación lo hace, agregue la
siguiente línea al archivo .htaccess :
php_value memory_limit <value>M
Por ejemplo, para aumentar el valor a 40 megabytes, escriba:

php_value memory_limit 40M
Si no existe ningún archivo .htaccess , cree uno en el directorio de Moodle con esa línea.
si tiene su propio servidor con acceso al shell, edite el archivo php.ini . A continuación, reinicie el
servidor web para aplicar los cambios realizados en php.ini . Para asegurarse de que ha actualizado el
valor correctamente, escriba este comando:
`phpinfo`
La salida de phpinfo debe contener una línea parecida a esta:
memory_limit <value>M
Por ejemplo, podría contener esta línea:

memory_limit 40M
Una alternativa a aumentar el valor memory_limit es desactivar el límite de memoria. Para ello, desactive este
comando:
memory_limit 0
Errores de inicio de sesión

A veces no puede iniciar sesión o aparece uno de estos mensajes:
Your session has timed out. Please log in again.
A server error that affects your login session was detected. Please log in again or restart your
browser.
Puede haber un problema con el método de autenticación, especialmente si usa un método externo como LDAP
para autenticar a los usuarios. Intente iniciar sesión en otra cuenta manual, como su cuenta de administrador
principal. Si no puede iniciar sesión, compruebe la autenticación. Si puede iniciar sesión en la otra cuenta, estas
son las posibles razones y las soluciones para el problema de inicio de sesión de Moodle:
Es posible que el disco duro esté lleno. En esta situación, Moodle no puede crear nuevas sesiones y los
usuarios no pueden iniciar sesión. Compruebe que el disco duro no está lleno, que el servidor está en un
hospedaje compartido y que no ha alcanzado la cuota de espacio en disco.
El servidor web no puede escribir en el subdirectorio sessions . Compruebe cuidadosamente los
permisos en el área moodledata .
Errores graves
Los permisos de Moodle y moodledata pueden ser incorrectos si aparece este error:
fatal error: $cfg->dataroot is not writable. The admin has to fix directory permissions! Exiting.
Compruebe que estos permisos son solo www-data:www-data . Si los permisos se encuentran en un nivel
diferente, use este comando para cambiar el grupo y los permisos de propiedad:
sudo chown -R /moodle/moodledata
Errores del curso de nivel superior

Si no encuentra un curso de nivel superior justo después de instalar Moodle, es probable que la instalación no
haya finalizado. Justo antes de que finalice la instalación, Moodle le pide el perfil de administrador y le pide que
asigne un nombre al sitio. Si faltan estos pasos, compruebe si hay errores en los registros. A continuación,
reinicie la base de datos. Si usó el instalador basado en web, vuelva a instalar Moodle mediante la línea de
comandos.
Errores de navegación
Si no puede navegar libremente por Moodle después de iniciar sesión, es posible que la configuración de la
dirección URL sea incorrecta. Asegúrese de que la dirección URL de la opción $CFG->wwwroot sea la misma que
se usa para acceder al sitio.
Errores de carga de archivos
Si aparece un error Archivo no encontrado al cargar un archivo, es posible que el servidor web no haya activado
los argumentos de barra diagonal.
Si el servidor web admite argumentos de barra diagonal, actívelos.
Si el servidor web no admite argumentos de barra diagonal, se pueden desactivar en Moodle; para ello,
desactive la casilla Use slash arguments (Usar argumentos de barra diagonal) en Administration >
Site administration > Ser ver > HTTP (Administración > Administración del sitio > Servidor > HTTP).
Puede que haya recibido este mensaje.
WARNING
Si se deshabilitan los argumentos de barra diagonal, los paquetes SCORM no funcionarán y se mostrarán las
advertencias de los argumentos de barra diagonal.
Errores del modo de mantenimiento

Cuando Moodle está en modo de mantenimiento e intenta dejar ese modo, a veces aparece este mensaje: Este
sitio está en mantenimiento y actualmente no está disponible. Esta situación se produce cuando hay un
problema con el archivo maintenance.html que Moodle crea en la carpeta moodledata cuando entra en modo de
mantenimiento. En este caso, siga estos pasos:
Compruebe que el usuario del servidor web tiene permisos de escritura en el directorio moodledata .
Elimine el archivo maintenance.html manualmente.
Pasos siguientes
Documentación de Azure Database for MySQL
¿Qué son los conjuntos de escalado de máquinas virtuales?
Introducción a las cuentas de almacenamiento
Rehospedaje de un entorno de desarrollo/pruebas
local en Azure Virtual Machines mediante Azure
Migrate
En este artículo se muestra cómo la empresa ficticia Contoso rehospeda su entorno de desarrollo/pruebas para
dos aplicaciones que se ejecutan en máquinas virtuales de VMware mediante la migración a Azure Virtual
Machines.
Las aplicaciones SmartHotel360 y osTicket que se usan en este ejemplo son de código abierto. Puede
descargarlas para realizar sus propias pruebas.
Opciones de migración
Contoso tiene varias opciones disponibles para trasladar entornos de desarrollo/pruebas a Azure:
O P C IO N ES DE M IGRA C IÓ N RESULTA DO
Azure Migrate Evaluación y migración de máquinas virtuales locales.
Ejecución de servidores de desarrollo y pruebas mediante la

infraestructura como servicio (IaaS) de Azure.
Administración de máquinas virtuales con Azure Resource

Manager.
Azure DevTest Labs Aprovisionamiento rápido de entornos de desarrollo y

pruebas.
Minimización de pérdidas con cuotas y directivas.
Establecimiento de apagados automáticos para minimizar los

costos.
Creación de entornos de Windows y Linux.
NOTE
Vea cómo Contoso ha trasladado su entorno de desarrollo/pruebas a Azure mediante DevTest Labs.

El equipo de responsables del desarrollo ha descrito lo que quiere lograr con esta migración. Su objetivo es
trasladar rápidamente sus funcionalidades de desarrollo/pruebas fuera de un centro de datos local y no tener
que volver a comprar hardware para desarrollar software. Contoso también quiere capacitar a los
desarrolladores para que puedan crear y ejecutar sus entornos sin que intervenga TI.
NOTE
Contoso usará la oferta de suscripción Desarrollo/pruebas - Pago por uso para sus entornos. Cada suscriptor activo de
Visual Studio del equipo puede usar el software de Microsoft incluido en las máquinas virtuales de la suscripción para el
desarrollo y las pruebas sin cargo adicional. Contoso solo pagará la tarifa de Linux para las máquinas virtuales que se
ejecuten. Eso incluye máquinas virtuales con SQL Server, SharePoint Server u otro software que normalmente se facture a
una tarifa superior.
El equipo de desarrollo de Contoso ha establecido los objetivos de esta migración. Estos objetivos se utilizan
para determinar el mejor método de migración:
Contoso quiere trasladar rápidamente sus entornos de desarrollo/pruebas locales.
Después de la migración, el entorno de desarrollo y pruebas de Contoso en Azure debe tener
funcionalidades mejoradas en comparación con las del sistema actual de VMware.
El modelo de operaciones pasará de estar aprovisionado por TI a DevOps con autoservicio de
aprovisionamiento.
identifica el proceso de migración. El proceso incluye los servicios de Azure que Contoso usará para la
migración.
Aplicación actual
Las máquinas virtuales de desarrollo y pruebas de las dos aplicaciones se ejecutan en máquinas virtuales (
WEBVMDEV , SQLVMDEV , OSTICKETWEBDEV , OSTICKETMYSQLDEV ). Estas máquinas virtuales se usan para el
desarrollo antes de promocionar el código a las máquinas virtuales de producción.
El entorno de VMware lo administra vCenter Server 6.5 ( vcenter.contoso.com ) que se ejecuta en una
máquina virtual.
contosodc1 ).
Puesto que las máquinas virtuales se usan para desarrollo/pruebas, residirán en el grupo de recursos
ContosoDevRG de Azure.
Las máquinas virtuales se migrarán a la región principal de Azure ( East US 2 ) y se colocarán en la red
virtual de desarrollo ( VNET-DEV-EUS2 ).
Las máquinas virtuales front-end web residirán en la subred front-end ( DEV-FE-EUS2 ) de la red de
desarrollo.
La máquina virtual de la base de datos residirá en la subred de la base de datos ( DEV-DB-EUS2 ) de la red
de desarrollo.
Figura 1: arquitectura propuesta.
Para respaldar el desarrollo continuo, Contoso ha decidido seguir usando las máquinas virtuales existentes y
migrarlas a Azure. En el futuro, Contoso pretenderá el uso de servicios de plataforma como servicio (PaaS),
como Azure SQL Database y Azure Database for MySQL.
Las máquinas virtuales de las bases de datos se migrarán tal cual están, sin cambios.
Con el uso de la oferta de suscripción Desarrollo/pruebas de Azure, los equipos que ejecuten
Windows Server y SQL Server no incurrirán en cargos de licencias. Al evitar esas tarifas, los costos de
proceso se reducirán al mínimo.
En el futuro, Contoso buscará integrar su desarrollo con los servicios de PaaS.
Ventajas Todas las máquinas virtuales de desarrollo se trasladarán a

Azure sin cambios, lo cual simplifica la migración.
Dado que Contoso usa un enfoque lift-and-shift para ambos

conjuntos de máquinas virtuales, no se necesitan
para la base de datos de la aplicación.
Contoso puede aprovechar su inversión en la suscripción de

Desarrollo/pruebas de Azure para ahorrarse el precio de las
licencias.

A los desarrolladores se les proporcionarán derechos sobre

la suscripción que les permitirán crear nuevos recursos sin
esperar a que el equipo de TI responda a sus solicitudes.
Desventajas La migración solo trasladará sus máquinas virtuales, pero

aún no se trasladarán a los servicios de PaaS para su
desarrollo. Esto significa que Contoso tendrá que empezar a
dar soporte a las operaciones de sus máquinas virtuales,
incluidos los parches de seguridad. En el pasado esto lo
realizaba el equipo de TI, por lo que Contoso tendrá que
encontrar una solución para esta nueva tarea operativa.
La solución basada en la nube capacita a los desarrolladores

y no tiene medidas de seguridad para el
sobreaprovisionamiento de sistemas. Los desarrolladores
podrán aprovisionar sus sistemas de forma instantánea, pero
podrían crear recursos que cuestan dinero pero que no
están incluidos en el presupuesto.
NOTE
Contoso podría afrontar las desventajas de su lista mediante DevTest Labs.
Contoso migrará la base de datos y el front-end de desarrollo a máquinas virtuales de Azure con el método sin
agente de Azure Migrate: Herramienta de migración del servidor.
Contoso prepara y configura componentes de Azure para Azure Migrate: Server Migration y prepara la
infraestructura local de VMware.
La infraestructura de Azure ya está implementada, por lo que Contoso solo tiene que configurar la
servidor.
Una vez que se haya habilitado la replicación y esta se encuentre en funcionamiento, Contoso migrará las
máquinas virtuales. Para ello, probará la migración y, si es correcta, la conmutará por error en Azure.
Una vez que las máquinas virtuales de desarrollo estén en funcionamiento en Azure, Contoso volverá a
configurar sus estaciones de trabajo de desarrollo para que apunten a las máquinas virtuales que ahora se
ejecutan en Azure.
Figura 2: información general sobre el proceso de migración.
Servicios de Azure
de trabajo locales, y las instancias de Las máquinas virtuales de Azure se
máquinas virtuales de AWS o GCP. crean e incurren en gastos cuando se
produce la migración y empiezan a
ejecutarse en Azure. Más información
sobre cargos y precios.
Requisitos previos
Esto es lo que tiene hacer Contoso para ejecutar este escenario:
Suscripción de Desarrollo/pruebas de Azure Contoso crea una suscripción de Desarrollo/pruebas de

Azure para aprovechar unos costos rebajados hasta el 80
por ciento.
Si no tiene una suscripción a Azure, cree una cuenta gratuita.




Ser vidores locales Los servidores vCenter locales deberían ejecutar las
versiones 5.5, 6.0, 6.5 o 6.7.
Los hosts ESXi deben ejecutar la versión 5.5, 6.0, 6.5 o 6.7.
Pasos del escenario

migración del servidor al proyecto de Azure Migrate.
Paso 2: Preparación del entorno de VMware local para Azure Migrate: Ser ver Migration. Se
preparan las cuentas para la detección de máquinas virtuales y se prepara la conexión a las máquinas
virtuales de Azure tras la migración.
Paso 3: Replicación de máquinas vir tuales. Se configura la replicación y se comienzan a replicar las
máquinas virtuales en Azure Storage.
Paso 4: Migración de las máquinas vir tuales con Azure Migrate: Ser ver Migration. Se ejecuta una
migración de prueba para garantizar que todo funciona y, luego, se ejecuta una migración completa para
mover las máquinas virtuales a Azure.

Migration
Contoso tiene que migrar las máquinas virtuales a una red virtual en la que residirán las máquinas virtuales de
Azure cuando se creen, aprovisionen y configuren mediante Azure Migrate: Herramienta de migración del
servidor.
1. Configure una red: Contoso ya configuró una red que puede ser para Azure Migrate: Server Migration
cuando implementó la infraestructura de Azure.
Las máquinas virtuales que se van a migrar se usan para el desarrollo. Se migrarán a la red virtual de
desarrollo de Azure ( VNET-DEV-EUS2 ) en la región principal East US 2 .
Ambas máquinas virtuales se colocarán en el grupo de recursos ContosoDevRG que se usa para los
recursos de desarrollo.
Las máquinas virtuales de front-end de aplicaciones ( WEBVMDEV y OSTICKETWEBDEV ) se migrarán a la
subred de front-end ( DEV-FE-EUS2 ) de la red de producción.
Las máquinas virtuales de la base de datos de aplicación ( SQLVMDEV y OSTICKETMYSQLDEV ) se migrarán
a la subred de base de datos ( DEV-DB-EUS2 ) de la red de producción.
a. Desde Azure Migrate, descargue la imagen .OVA e impórtela en VMWare.
Figura 3: descarga del archivo .OVA.
b. Inicie la imagen importada y configure la herramienta, incluidos los pasos siguientes:
Configure los requisitos previos.
Figura 4: configuración de los requisitos previos.

Dirija la herramienta a la suscripción de Azure.
Figura 5: suscripción de Azure.
Configure las credenciales de VMWare vCenter.
Figura 6: establecimiento de las credenciales de VMware vCenter.

Agregue las credenciales basadas en Windows para la detección.
Figura 7: incorporación de credenciales basadas en Windows para la detección.
3. Al completar la configuración, la herramienta tardará un tiempo en mostrar todas las máquinas virtuales.
Cuando este proceso finalice, verá que se rellenan en la herramienta Azure Migrate de Azure.
Aprenda a configurar Azure Migrate: Server Migration.
Para ello, los administradores de Contoso realizan lo siguiente antes de la migración:
Se asegura de que se agregan las reglas TCP y UDP para el perfil Public .
Instale SSH con el comando siguiente: sudo apt-get ssh install -y .
Para Windows, establezca la directiva de SAN del sistema operativo en la máquina virtual local en
OnlineAll .
3. Instale el Agente de Windows de Azure y el Agente de Linux de Azure.
En el caso de Windows, no debe haber actualizaciones pendientes en la máquina virtual cuando se desencadene
una migración. Si las hay, los administradores no podrán iniciar sesión en la máquina virtual hasta que se
completen las actualizaciones. Después de la migración, los administradores pueden comprobar los
diagnósticos de arranque para ver una captura de pantalla de la máquina virtual. Si no funciona, debe
comprobar que la máquina virtual está en ejecución, así como revisar las sugerencias de solución de problemas.
Aprenda a preparar las máquinas virtuales para la migración.

habilitar la replicación. Una vez finalizada la detección, puede comenzar la replicación de máquinas virtuales de
VMware en Azure.
1. En el proyecto de Azure Migrate, vaya a Ser vidores > Azure Migrate: Ser ver Migration . A
continuación, seleccione Replicar .
Ilustración 8: Replicación de máquinas virtuales.

VMware vSphere .
Ilustración 9: La configuración de origen.
4. En Máquinas vir tuales , seleccione las máquinas que quiere replicar.
tamaño y tipo de disco (Premium o estándar) de máquina virtual que sugieren los resultados de
dicha evaluación. Para ello, en ¿Quiere impor tar la configuración de migración de
evaluación de Azure Migrate? , seleccione la opción Sí .
Si no ha ejecutado una evaluación o no desea usar la configuración de evaluación, seleccione la
opción No .
evaluación.
Figura 10: configuración de los requisitos previos.

5. En Máquinas vir tuales , busque las máquinas virtuales que necesite y compruebe todas las que desee
6. En Configuración de destino , seleccione la suscripción y la región de destino a la que migrará. A
continuación, especifique el grupo de recursos en el que residirán las máquinas virtuales de Azure
después de la migración. En Red vir tual , seleccione la red virtual o la subred de Azure a la que se unirán
las máquinas virtuales de Azure después de la migración.
7. En Ventaja híbrida de Azure , seleccione No si no desea aplicar la Ventaja híbrida de Azure. Luego,
seleccione Siguiente . Seleccione Sí si tiene equipos con Windows Server que están incluidos en
suscripciones activas de Software Assurance o Windows Server y desea aplicar el beneficio a las
máquinas que va a migrar. Luego, seleccione Siguiente .
NOTE
En el caso de Contoso, los administradores seleccionarán No en Ventaja híbrida de Azure porque se trata de una
suscripción de Desarrollo/pruebas de Azure. Esto significa que solo pagarán por el proceso. Ventaja híbrida de
Azure solo se debe usar en los sistemas de producción que tienen ventajas de Software Assurance.
Tamaño de VM: si usa las recomendaciones de la evaluación, esta lista desplegable contiene el
tamaño recomendado. De lo contrario, Azure Migrate selecciona un tamaño en función de la
coincidencia más cercana en la suscripción de Azure. En su lugar, puede elegir un tamaño manual en
Tamaño de la máquina vir tual de Azure .
virtual. El disco de sistema operativo tiene el cargador de arranque y el instalador del sistema
operativo.
9. En Discos , especifique si los discos de la máquina virtual se deben replicar en Azure y seleccione el tipo
de disco (discos SSD o HDD Estándar, o bien discos administrados Premium) en Azure. Luego, seleccione
Siguiente . Puede excluir discos de la replicación. Si lo hace, esos discos no estarán presentes en la
máquina virtual de Azure después de la migración.
10. En Revisar e iniciar la replicación , revise la configuración y seleccione Replicar para iniciar la
replicación inicial de los servidores.
NOTE
Paso 4: Migrar las VM

migrar las máquinas virtuales.
Ilustración 11:
Prueba de servidores migrados.
Ilustración 12: Prueba de la migración.

Azure después de la migración. Se recomienda que use una red virtual que no sea de producción.
vir tuales en Azure Portal. El nombre de la máquina tiene un sufijo -Test .
virtual de Azure, en Replicación de máquinas y seleccione Limpiar la migración de prueba .
Figure 13: Limpieza de la migración de prueba.

Migrar las VM
Ahora, los administradores de Contoso ejecutan una migración completa.
1. En el proyecto de Azure Migrate, seleccione Ser vidores > Azure Migrate: Ser ver Migration >
Figura 14:
Replicación de servidores.
perder datos? , seleccione Sí > Aceptar . De forma predeterminada, Azure Migrate apaga la máquina
virtual local y ejecuta una replicación a petición para sincronizar los cambios que se han producido en la
máquina virtual desde la última replicación. De esta forma se garantiza que no se pierden datos. Si no
desea apagar la VM, seleccione No .
vir tuales .
Aprenda a ejecutar una migración de prueba y como migrar máquinas virtuales a Azure.

Las máquinas virtuales de desarrollo de las aplicaciones SmartHotel360 y osTicket comienzan a ejecutarse en
máquinas virtuales de Azure cuando la migración está completa.
Una vez completada la migración, detenga la replicación.
Quite las máquinas virtuales WEBVMDEV , SQLVMDEV , OSTICKETWEBDEV y OSTICKETMYSQLDEV del inventario de
vCenter.
Quite todas las máquinas virtuales de los trabajos de copia de seguridad locales.
virtuales.
Con la aplicación en ejecución, Contoso ahora debe hacer que sea totalmente operativa y protegerla en Azure.
Seguridad
máquinas virtuales. Los grupos de seguridad de red se usan para garantizar que solo el tráfico permitido pueda
comunicarse con la aplicación. El equipo también tiene en cuenta la protección de los datos en el disco con
IaaS de Azure.

mantener seguros los datos. Contoso realiza la copia de seguridad de los datos de las máquinas virtuales
mediante el servicio Azure Backup. Para más información, consulte la introducción a la copia de seguridad de
máquinas virtuales de Azure.
Contoso se va a asegurar de que todos los recursos de desarrollo de Azure se creen con una suscripción de
desarrollo/pruebas para ahorrar el 80 %. Los administradores habilitarán Azure Cost Management + Billing
para ayudar a supervisar y administrar los recursos de Azure.
Conclusión
En este artículo, Contoso ha rehospedado las máquinas virtuales de desarrollo usadas para sus aplicaciones
SmartHotel360 y osTicket en Azure. Los administradores migraron las máquinas virtuales de la aplicación a las
máquinas virtuales de Azure mediante Azure Migrate: Herramienta de migración del servidor.
Migración de un entorno de desarrollo/pruebas a
Azure DevTest Labs
En este artículo se muestra cómo la empresa ficticia Contoso migra su entorno de desarrollo/pruebas a Azure
DevTest Labs.
Opciones de migración
Contoso tiene varias opciones disponibles a la hora de trasladar su entorno de desarrollo/pruebas a Azure.
Ejecución de servidores de desarrollo y pruebas mediante la

infraestructura como servicio (IaaS) de Azure.
Administración de máquinas virtuales con Azure Resource

Manager.
DevTest Labs Aprovisionamiento rápido de entornos de desarrollo y

pruebas.
Minimización de pérdidas con cuotas y directivas.
Establecimiento de apagados automáticos para minimizar los

costos.
Creación de entornos de Windows y Linux.
NOTE
Este artículo se centra en el uso de DevTest Labs para trasladar un entorno de desarrollo/pruebas local a Azure. Consulte
cómo Contoso trasladó un entorno de desarrollo/pruebas a Azure IaaS a través de Azure Migrate.

El equipo de responsables del desarrollo ha descrito lo que quiere lograr con esta migración:
Ofrezca a los desarrolladores acceso a las herramientas de DevOps y a los entornos de autoservicio.
Conceda acceso a las herramientas de DevOps para canalizaciones de integración continua/ entrega continua
(CI/CD) y herramientas nativas de nube para entornos de desarrollo/pruebas, como IA, aprendizaje
automático y sin servidor.
Garantice la gobernanza y el cumplimiento en los entornos de desarrollo/pruebas.
Ahorre costos al sacar todos los entornos de desarrollo/pruebas de su centro de recursos y dejar de adquirir
hardware para desarrollar software.
NOTE
Contoso usará la oferta de suscripción Desarrollo/pruebas - Pago por uso para sus entornos. Cada suscriptor activo de
Visual Studio del equipo puede usar el software de Microsoft incluido en la suscripción a Azure Virtual Machines para el
desarrollo/pruebas sin cargo adicional. Contoso solo pagará la tarifa de Linux para las VM que se ejecuten. Eso incluye MV
con SQL Server, SharePoint Server u otro software que normalmente se facture a una tarifa superior.
NOTE
Los clientes de Azure con un Contrato Enterprise también pueden beneficiarse de la oferta de suscripción
Desarrollo/pruebas de Azure. Para más información, revise el vídeo para habilitar y crear suscripciones Desarrollo/pruebas
- Enterprise mediante el portal de EA.
El equipo de desarrollo de Contoso ha establecido los objetivos de esta migración. Estos objetivos se utilizan
para determinar el mejor método de migración:
Aprovisionamiento rápido de entornos de desarrollo y pruebas. Debería tardar unos minutos, en lugar de
meses, en crear la infraestructura que un desarrollador necesita para escribir o probar software.
Después de la migración, el entorno de desarrollo/pruebas de Contoso en Azure debe tener funcionalidades
mejoradas en comparación con las del sistema local actual.
El modelo de operaciones pasará de VM aprovisionadas por TI a DevOps con autoservicio de
aprovisionamiento.
Contoso quiere trasladar rápidamente sus entornos de desarrollo/pruebas locales.
Todos los desarrolladores se conectarán a los entornos de desarrollo/pruebas de forma remota y segura.
Después de precisar los objetivos y requisitos, Contoso diseña y revisa una solución de implementación. La
solución incluye los servicios de Azure que usará para desarrollo y pruebas.
Arquitectura actual
Las VM de desarrollo/pruebas de las aplicaciones de Contoso se ejecutan en VMware desde el centro de
datos local.
Estas VM se usan para el desarrollo y pruebas antes de promocionar el código a las VM de producción.
Los desarrolladores dan mantenimiento a sus propias estaciones de trabajo, pero necesitan nuevas
soluciones para conectarse de forma remota desde sus oficinas domésticas.
Contoso usará una suscripción Desarrollo/pruebas de Azure para reducir los costos de los recursos de Azure.
Esta suscripción ofrece un ahorro significativo, incluidas las VM que no incurren en los cargos de licencias del
software de Microsoft.
Contoso usará DevTest Labs para administrar los entornos. Se crearán nuevas VM en DevTest Labs para
permitir su traslado a nuevas herramientas para desarrollo y pruebas en la nube.
Las VM locales de desarrollo/pruebas del centro de datos de Contoso se retirarán después de realizar la
migración.
Los desarrolladores y evaluadores tendrán acceso a Windows Virtual Desktop en sus estaciones de trabajo.
Figura 1: Arquitectura del escenario.
Para respaldar el desarrollo continuo, Contoso ha decidido seguir usando bases de datos que se ejecutan en VM.
Sin embargo, las VM actuales se reemplazarán por otras nuevas que se ejecuten en DevTest Labs. En el futuro,
Contoso pretenderá el uso de servicios de plataforma como servicio (PaaS), como Azure SQL Database y Azure
Database for MySQL.
Las máquinas virtuales de base de datos de VMware actuales se retirarán y reemplazarán por máquinas
virtuales de Azure en DevTest Labs. Las bases de datos existentes se migrarán con copias de seguridad y
restauraciones sencillas. El uso de la oferta de suscripción Desarrollo/pruebas de Azure no incurrirá en los
cargos de licencias para instancias de Windows Server y SQL Server, lo que minimiza los costos de proceso.
Ventajas Todas las máquinas virtuales de desarrollo actuales

(aplicación y base de datos) se reemplazarán por nuevas
máquinas virtuales que se ejecuten en DevTest Labs. De este
modo, podrán aprovechar las características de un entorno
de desarrollo en la nube creado específicamente.
Contoso puede aprovechar su inversión en la suscripción de

Desarrollo/pruebas de Azure para ahorrarse el precio de las
licencias.

A los desarrolladores se les proporcionarán derechos sobre

la suscripción que les permitirán crear nuevos recursos sin
esperar a que el equipo de TI responda a sus solicitudes.
Desventajas La migración solo moverá el desarrollo a la nube. Los

desarrolladores no usarán los servicios de PaaS en su
desarrollo porque todavía están usando VM. Esto significa
que Contoso tendrá que empezar a dar soporte a las
operaciones de sus VM, incluidos parches de seguridad. En el
pasado, el mantenimiento de las VM estaba a cargo del
equipo de TI, por lo que Contoso tendrá que encontrar una
solución para esta nueva tarea operativa.
Contoso tendrá que crear nuevas máquinas virtuales de

aplicaciones y bases de datos, lo que automatizaba el
proceso. Esto significa que puede aprovechar las ventajas de
la creación de VM en la nube y las herramientas
proporcionadas por DevTest Labs. Por lo tanto, se trata de
un resultado positivo, incluso con una desventaja en la lista.
Contoso migrará las VM de aplicación y bases de datos de desarrollo a VM de Azure nuevas mediante DevTest
Labs.
Contoso ya tiene preparada la infraestructura de Azure, incluida la red virtual de desarrollo.
Con todo preparado, Contoso aprovisionará y configurará DevTest Labs.
Configurará la red virtual de desarrollo, asignará un grupo de recursos y establecerá las directivas.
Creará instancias de Windows Virtual Desktop para que los desarrolladores usen ubicaciones remotas.
Creará VM en DevTest Labs para el desarrollo y migración de las bases de datos.
Prerrequisitos
Esto es lo que tiene hacer Contoso para ejecutar este escenario.

Suscripción de Desarrollo/pruebas de Azure Contoso crea una suscripción de Desarrollo/pruebas de

Azure para reducir los costos hasta el 80 %.
Si no tiene una suscripción a Azure, cree una cuenta gratuita.



en rol de Azure.
Pasos del escenario

Paso 1: Aprovisionamiento de una nueva suscripción Desarrollo/pruebas de Azure y creación de una
instancia de DevTest Labs.
Paso 2: Configuración de la red virtual de desarrollo, asignación de un grupo de recursos y configuración de
directivas.
Paso 3: Creación de escritorios virtuales multisesión de Windows 10 Enterprise para que los desarrolladores
los usen desde ubicaciones remotas.
Paso 4: Creación de fórmulas y VM en DevTest Labs para el desarrollo y migración de las bases de datos.
Paso 1: Aprovisionamiento de una nueva suscripción

Desarrollo/pruebas de Azure y creación de una instancia de DevTest
Labs
Los administradores de Contoso primero deben aprovisionar una nueva suscripción mediante la oferta
Desarrollo/pruebas de Azure y, después, crear una instancia de DevTest Labs.
Se deben configurar como se muestra a continuación:
Los administradores siguen el vínculo a la oferta de suscripción Desarrollo/pruebas de Azure y aprovisionan
una nueva suscripción, con un ahorro de hasta un 80 % en sus sistemas. Esta oferta les permite ejecutar
imágenes de Windows 10 en Azure para desarrollo/pruebas. Tendrá acceso a Windows Virtual Desktop para
simplificar la experiencia de administración de los desarrolladores remotos.
Figura 3: Oferta de suscripción a

Desarrollo/pruebas de Azure.
Con la nueva suscripción aprovisionada, los administradores de Contoso usan Azure Portal para crear una
nueva instancia de DevTest Labs. Este nuevo laboratorio se crea en el grupo de recursos ContosoDevRG .
Figura 4: Creación de una nueva instancia de

DevTest Labs.
Paso 2: Configuración de la red virtual de desarrollo, asignación de un

grupo de recursos y configuración de directivas
Una vez creada la instancia de DevTest Labs, Contoso realiza las configuraciones siguientes:
1. Configure la red virtual:
a. En el portal, Contoso abre la instancia de DevTest Labs y selecciona Configuración y directivas .
Ilustración 5: Instancia de DevTest Labs: configuración y directivas.

b. Contoso selecciona Redes vir tuales > + Agregar , elige vnet-dev-eus2 y, a continuación,
selecciona Guardar . De este modo, la red virtual de desarrollo se podrá usar para las
implementaciones de VM. También se creó una red virtual durante la implementación de la
instancia de DevTest Labs.
Ilustración 6: Redes virtuales.

2. Asigne un grupo de recursos:
Para asegurarse de que los recursos se implementan en el grupo de recursos ContosoDevRG ,
Contoso los configura desde las opciones del laboratorio. También asigna a sus desarrolladores el
rol Colaborador .
Ilustración 7: Asignación de un grupo de recursos.
NOTE
El rol Colaborador es un rol de nivel de administrador con todos los derechos, excepto la capacidad de
proporcionar acceso a otros usuarios. Más información sobre el Control de acceso basado en roles de Azure.
3. Defina las directivas de laboratorio:

a. Contoso debe asegurarse de que sus desarrolladores usen DevTest Labs según las directivas del
equipo. Contoso configura DevTest Labs con estas directivas.
b. Habilita el apagado automático con una hora local de 19:00:00 h y la zona horaria correcta.
Ilustración 8: Apagado automático.
c. Contoso habilita el inicio automático para que las VM funcionen cuando los desarrolladores se
conecten para trabajar. Dichas máquinas están configuradas para la zona horaria local y los días de
la semana en los que trabajan los desarrolladores.
Ilustración 9: Inicio automático.

d. Contoso configura los tamaños de VM permitidos y se asegura de que las VM grandes y costosas
no puedan iniciarse.
Ilustración 10: Tamaños de máquina virtual permitidos.
e. Contoso configura el mensaje de soporte técnico.
Ilustración 11: Un mensaje de soporte técnico.
Paso 3: Creación de escritorios virtuales multisesión de Windows 10

Enterprise para que los desarrolladores los usen desde ubicaciones
remotas
Contoso debe crear una base de Windows Virtual Desktop para desarrolladores remotos.
1. Contoso selecciona Todas las máquinas vir tuales > + Agregar y elige una base de Windows 10
Enterprise para sesiones múltiples para una VM.
Ilustración 12: Base multisesión de Windows 10 Enterprise.
2. Contoso configura el tamaño de la VM junto con los artefactos que se van a instalar. En este caso, los
desarrolladores tienen acceso a herramientas de desarrollo comunes, como Visual Studio Code, Git y
Chocolatey.
Figure 13: Artefactos.

3. Contoso revisa la configuración de VM para mejorar la precisión.
Ilustración 14: Creación de una máquina virtual a partir de una imagen base.
4. Después de creada la VM, los desarrolladores remotos de Contoso pueden conectarse y usar esta
estación de trabajo de desarrollo para trabajar. Los artefactos seleccionados se instalan, con lo que los
desarrolladores ahorran tiempo de configuración de la estación de trabajo.
Ilustración 15: Una máquina virtual de desarrollador remoto.
Paso 4: Creación de fórmulas y máquinas virtuales en DevTest Labs

para el desarrollo y migración de las bases de datos
Con la instancia de DevTest Labs configurada y la estación de trabajo de los desarrolladores remotos en
funcionamiento, Contoso se centra en la creación de las VM para desarrollo. Para comenzar, Contoso realiza los
pasos siguientes:
1. Crea fórmulas (bases reutilizables) para las VM de aplicaciones y bases de datos, y aprovisiona las VM de
estos tipos mediante dichas fórmulas.
Selecciona Fórmulas > + Agregar y, a continuación, una base de Windows Ser ver 2012 R2
Datacenter .
Ilustración 16: Una base de Windows 2012 R2.

2. Contoso configura el tamaño de la VM junto con los artefactos que se van a instalar. En este caso, los
desarrolladores tienen acceso a herramientas de desarrollo comunes, como Visual Studio Code, Git y
Chocolatey.
Ilustración 17: Configuración de una imagen base de Windows 2012 R2.
3. Para crear la fórmula de VM de bases de datos, Contoso sigue los mismos pasos básicos. Esta vez,
selecciona una imagen de SQL Server 2012 para la base.
Ilustración 18: Una imagen de SQL Server 2012.

4. Contoso configura la fórmula con el tamaño y los artefactos. Los artefactos incluyen SQL Server
Management Studio, que es necesario para esta fórmula de VM de desarrollo de bases de datos.
Ilustración 19: Configuración de una imagen base de SQL 2020 R2.
Obtenga más información sobre el uso de fórmulas con Azure DevTest Labs.
5. Contoso ya creó las fórmulas de la base de Windows para que los desarrolladores las usen en las
aplicaciones y bases de datos.
Ilustración 20: Fórmulas de base de Windows.

En los próximos pasos se aprovisionan las VM de aplicaciones y bases de datos con las fórmulas:
1. Una vez creadas las fórmulas, Contoso selecciona Todas las máquinas vir tuales y, después, la fórmula
Windows2012AppDevVmBase para que coincida con la configuración de las VM actuales para
desarrollo de aplicaciones.
Ilustración 21: Una máquina virtual de desarrollo de aplicaciones.
2. Contoso configura la VM con el tamaño y los artefactos necesarios para esta VM de aplicaciones.
Ilustración 22: Configuraciones de tamaño y artefactos para una máquina virtual.

3. Contoso aprovisiona la VM de bases de datos mediante la fórmula SQLDbDevVmBase , para que
coincida con la configuración de las VM actuales para desarrollo de bases de datos.
Ilustración 23: Una máquina virtual de base de datos.
4. Contoso configura la VM con el tamaño y los artefactos necesarios.
Ilustración 24: Configuraciones de base de datos para una máquina virtual.

5. Los desarrolladores de Contoso están preparados para empezar a escribir código en Azure gracias a sus
primeras VM creadas y sus estaciones de trabajo remotas de desarrolladores.
Ilustración 25: VM de Contoso.
6. Contoso ahora puede restaurar sus bases de datos de desarrollo desde copias de seguridad o mediante
algún tipo de proceso de generación de código para compilar el esquema en las VM. Con SQL Server
Management Studio ya instalado con los artefactos, estas son tareas sencillas que no requieren la
instalación de ninguna herramienta.

Contoso seguirá usando estos pasos para migrar sus VM a Azure mediante DevTest Labs. Con cada migración
completada, todas las máquinas virtuales de desarrollo se comenzarán a ejecutar en DevTest Labs.
Quitar las máquinas virtuales del inventario de vCenter.
Quite todas las VM de los trabajos de copia de seguridad locales.
virtuales.
Seguridad
Azure Disk Encryption y Azure Key Vault. Para obtener más información, consulte Procedimientos de seguridad
recomendados para cargas de trabajo de IaaS de Azure.
Contoso se asegurará de que todos los recursos de desarrollo de Azure se creen con una suscripción de
Desarrollo/pruebas de Azure para aprovechar los ahorros del 80 %.
Se revisarán los presupuestos para todas las instancias de DevTest Labs y las directivas de las VM para
garantizar que los costos estén contenidos y el exceso de aprovisionamiento no se produzca por error.
Azure.
Conclusión
En este artículo, Contoso trasladó sus entornos de desarrollo a DevTest Labs. También implementó Windows
Virtual Desktop como plataforma para desarrolladores remotos y con contrato.
Cree una instancia de DevTest Labs en su suscripción ahora mismo y aprenda a usar DevTest Labs para
desarrolladores.
Migración de una aplicación a Azure App Service y
SQL Database
En este artículo se muestra cómo la compañía ficticia Contoso refactoriza una aplicación de .NET de Windows de
dos niveles que se ejecuta en máquinas virtuales VMware como parte de una migración a Azure. El equipo de
Contoso migra la máquina virtual (VM) de front-end de la aplicación a una aplicación web de Azure App Service
y la base de datos de la aplicación a Azure SQL Database.
La aplicación SmartHotel360 que usamos en este ejemplo se proporciona como software de código abierto. Si
quiere utilizarla para sus propias pruebas, puede descargarla desde GitHub.

El equipo directivo de TI de Contoso ha trabajado estrechamente con sus socios comerciales para comprender lo
quieren lograr con esta migración:
Abordar el crecimiento del negocio. Contoso está creciendo y los sistemas y la infraestructura locales
están bajo presión.
Aumentar la agilidad. Para alcanzar el éxito en una economía global, el departamento de TI de Contoso
necesita más capacidad de respuesta a las necesidades de la empresa. Debe ser capaz de reaccionar con más
rapidez a los cambios del mercado. No se debe interponer en el camino ni bloquear el negocio.
Reducir los costos. Contoso quiere minimizar los costos de licencia.
El equipo de la nube de Contoso ha definido los siguientes objetivos con el fin de determinar el mejor método
de migración:

Aplicación La aplicación de Azure seguirá siendo tan crítica como lo es

hoy en día en el entorno local.
Debe tener las mismas funcionalidades de rendimiento que

las que tiene actualmente en VMware.
El equipo no quiere invertir en la aplicación. Por ahora, los

administradores simplemente moverán la aplicación de
forma segura a la nube.
El equipo quiere finalizar el soporte técnico de

Windows Server 2008 R2, donde se ejecuta actualmente la
aplicación.
El equipo también quiere abandonar SQL Server 2008 R2 y

pasar a una base de datos de plataforma como servicio
(PaaS), lo que minimizará la necesidad de administración.
Contoso quiere aprovechar su inversión en licencias de

SQL Server y Software Assurance, tanto como que sea
posible.
Además, Contoso quiere mitigar el único punto de error en

el nivel web.
Limitaciones La aplicación está formada por una aplicación de ASP.NET y

un servicio Windows Communication Foundation (WCF) que
se ejecutan en la misma máquina virtual. Contoso quiere
distribuir estos componentes entre dos aplicaciones web con
Azure App Service.
Azure Contoso quiere mover la aplicación a Azure, pero no quiere

que se ejecute en máquinas virtuales. Quiere usar los
servicios de PaaS de Azure para los niveles web y de datos.
DevOps Contoso quiere migrar a un modelo DevOps, con Azure

DevOps para las canalizaciones de compilación y de versión.
Después de precisar los objetivos y requisitos, Contoso diseña y revisa una solución de implementación.
También identifica el proceso de migración, incluidos los servicios de Azure que usarán para la migración.
Aplicación actual
La aplicación SmartHotel360 local se divide en niveles entre dos máquinas virtuales ( WEBVM y SQLVM ).
máquina virtual.
Contoso tiene un centro de datos local (contoso-datacenter), con un controlador de dominio local
(contosodc1).
Solución propuesta
Para la capa de base de datos de la aplicación, Contoso comparó Azure SQL Database con SQL Server según
el artículo Comparación de características: Azure SQL Database y Azure SQL Managed Instance. Contoso se
decantó por Azure SQL Database por diversos motivos:
Azure SQL Database es un servicio administrado de bases de datos relacionales. Ofrece un
rendimiento predecible en los diferentes niveles del servicio, con administración casi inexistente. Las
ventajas incluyen escalabilidad dinámica sin tiempo de inactividad, optimización inteligente integrada
y disponibilidad y escalabilidad global.
Contoso puede usar la herramienta ligera Data Migration Assistant para evaluar la migración de la
base de datos local a Azure SQL Database.
Contoso puede usar Azure Database Migration Service para migrar la base de datos local a Azure SQL
Database.
Con Software Assurance, Contoso puede intercambiar las licencias existentes por descuentos en una
base de datos de SQL Database con la Ventaja híbrida de Azure para SQL Server. Este enfoque podría
proporcionar un ahorro de costos de hasta un 30 por ciento.
SQL Database proporciona características de seguridad, por ejemplo, Always Encrypted,
enmascaramiento dinámico de datos, seguridad a nivel de fila y detección de amenazas SQL.
Para el nivel web de la aplicación, Contoso ha decidido usar Azure App Service. Este servicio PaaS permite
implementar la aplicación con tan solo unos cambios en la configuración. Contoso usará Visual Studio para
realizar el cambio e implementará dos aplicaciones web, una para el sitio web y otra para el servicio WCF.
Para cumplir los requisitos de una canalización de DevOps, Contoso usará Azure DevOps para la
administración del código fuente con repositorios de Git. Se usarán compilaciones y versiones automatizadas
para compilar el código e implementarlo en Azure App Service.
Contoso evalúa el diseño propuesto y crea una lista de ventajas y desventajas como se muestra en la tabla
siguiente:
Ventajas No es necesario modificar el código de la aplicación

SmartHotel360 para la migración a Azure.

Assurance con la Ventaja híbrida de Azure para SQL Server y
Windows Server.
Después de la migración, ya no será necesaria la

compatibilidad con Windows Server 2008 R2. Para obtener
más información, consulte la directiva de ciclo de vida de
Microsoft.
Contoso puede configurar el nivel web de la aplicación con

varias instancias, para que el nivel web deje de ser un único
punto de error.
La base de datos ya no dependerá de la antigüedad de

SQL Server 2008 R2.
SQL Database es compatible con los requisitos técnicos.

Contoso evaluó la base de datos local con Data Migration
Assistant y averiguó que es compatible.
Azure SQL Database cuenta con tolerancia a errores

integrada que no es necesario que Contoso configure. Esto
Si Contoso usa Azure Database Migration Service para

migrar su base de datos, tendrá la infraestructura preparada
para migrar bases de datos a gran escala.
Desventajas Azure App Service solo admite la implementación de una

aplicación por cada aplicación web. Esto significa que se
deben aprovisionar dos aplicaciones web, una para el sitio
web y otra para el servicio WCF.
1. Contoso aprovisiona una instancia de Azure SQL Managed Instance a la que migra la base de datos
SmartHotel360 mediante Azure Database Migration Service.
2. Aprovisiona y configura las aplicaciones web e implementa la aplicación SmartHotel360 en ellas.
Servicios de Azure
Azure App Service Migration Assistant Una forma sencilla y gratuita de migrar Es una herramienta que se puede
sin problemas aplicaciones web de descargar de forma gratuita.
.NET desde el entorno local a la nube
con cambios mínimos en el código o
incluso sin ningún cambio.
Data Migration Assistant Contoso va a usar Data Migration Es una herramienta que se puede
Assistant para evaluar y detectar descargar de forma gratuita.
problemas de compatibilidad que
podrían afectar a la funcionalidad de la
base de datos en Azure. Data
Migration Assistant evalúa la paridad
de características entre orígenes y
destinos de SQL y recomienda mejoras
de rendimiento y confiabilidad.
Azure Database Migration Service Azure Database Migration Service Información acerca de las regiones
permite migraciones completas de admitidas y los precios de Database
varios orígenes de base de datos a Migration Service.
Azure SQL Database Servicio de base de datos relacional El costo se basa en las características,
inteligente y completamente el rendimiento y el tamaño. Más
administrado en la nube. información.
Azure App Service Permite crear aplicaciones en la nube Los precios se basan en el tamaño, la
eficaces que usan una plataforma ubicación y la duración del uso. Más
totalmente administrada. información.
Azure DevOps Ofrece una canalización de integración

continua e implementación continua
(CI/CD) para el desarrollo de
aplicaciones. La canalización comienza
con un repositorio de Git para
administrar código de aplicaciones, un
sistema de compilación para producir
paquetes y otros artefactos de
compilación, y un sistema de
administración de versiones para
implementar cambios en entornos de
desarrollo, prueba y producción.
Requisitos previos
Contoso debe cumplir los siguientes requisitos previos para ejecutar este escenario:
Suscripción de Azure Suscripciones creadas por Contoso anteriormente en esta

serie de artículos. Si no tiene una suscripción a Azure, cree
una cuenta gratuita.


tendrá que solicitar al administrador que le asigne permisos
de propietario o colaborador.

describe en Infraestructura de Azure para la migración.
Pasos del escenario

Paso 1: Evaluar y migrar las aplicaciones web . Contoso usa la herramienta Azure App Service
Migration Assistant para ejecutar comprobaciones de compatibilidad previas a la migración y migrar sus
aplicaciones web a Azure App Service.
Paso 2: Aprovisionamiento de una base de datos en Azure SQL Database . Contoso aprovisiona una
instancia de Azure SQL Database. Después de migrar el sitio web de la aplicación a Azure, la aplicación web
del servicio WCF apuntará a esta instancia.
Paso 3: Evaluación de la base de datos . Contoso evalúa la base de datos para la migración con Data
Migration Assistant y, a continuación, realiza la migración con Azure Database Migration Service.
Paso 4: Configuración de Azure DevOps . Contoso crea un proyecto de Azure DevOps e importa el
repositorio de Git.
Paso 5: Configuración de las cadenas de conexión . Contoso configura las cadenas de conexión para
que la instancia de SQL, la aplicación web del servicio WCF y la aplicación web de nivel de web puedan
comunicarse.
Paso 6: Configuración de las canalizaciones de compilación y de versión en Azure DevOps .
Como último paso, Contoso configura las canalizaciones de compilación y de versión en Azure DevOps para
crear la aplicación y, a continuación, las implementa en dos aplicaciones web independientes.
Paso 1: Evaluar y migrar las aplicaciones web
Los administradores de Contoso evalúan y migran su aplicación web mediante la herramienta Azure App
Service Migration Assistant. Usan la ruta de aprendizaje sobre migración de aplicaciones de ASP.NET a Azure
como guía durante el proceso. Los administradores realizan estas acciones:
Usan la herramienta Azure App Service Migration Assistant para evaluar las dependencias entre sus
aplicaciones web y determinar si hay alguna incompatibilidad entre sus aplicaciones web locales y
aquellas que se admiten en Azure App Service.
Descargan Azure App Service Migration Assistant e inician sesión en su cuenta de Azure.
Eligen una suscripción, un grupo de recursos y el nombre de dominio del sitio web.
Paso 2: Aprovisionamiento de una base de datos en Azure SQL

Database
1. Los administradores de Contoso deciden crear una instancia de Azure SQL Database.
2. Especifican un nombre de base de datos para que coincida con la base de datos, SmartHotel.Registration
, que se ejecuta en la máquina virtual local. Colocan la base de datos en el grupo de recursos ContosoRG .
Este es el grupo de recursos que usa para los recursos de producción en Azure.
3. Configuran una nueva instancia de SQL Server, sql-smarthotel-eus2 , en la región primaria.
4. Establece el plan de tarifa que mejor se adapta a las necesidades de su servidor y base de datos. Así
mismo, selecciona esta opción para ahorrar dinero con la Ventaja híbrida de Azure, porque ya tiene una
licencia de SQL Server.
5. Para ajustar el tamaño, realiza compras basadas en el núcleo virtual y establece los límites para los
requisitos esperados.
6. Crean la instancia de la base de datos.
7. Abren la base de datos y anotan los detalles que necesitarán cuando usen Data Migration Assistant para
la migración.

Obtenga ayuda para aprovisionar una instancia de SQL Database.
Obtenga información acerca de los límites de recursos de núcleo virtual.

Los administradores de Contoso evalúan la base de datos mediante Data Migration Assistant y, a continuación,
la migran con Azure Database Migration Service según el tutorial de migración paso a paso. Pueden realizar
migraciones en línea, sin conexión e híbridas (versión preliminar).
En resumen, los administradores hacen lo siguiente:
Usan Data Migration Assistant para detectar y resolver los problemas de migración de base de datos.
Crean una instancia de Azure Database Migration Service con una SKU Premium que está conectada a la red
virtual.
Se aseguran de que la instancia pueda acceder a la instancia remota de SQL Server mediante la red virtual.
Esto implica asegurarse de que todos los puertos de entrada están permitidos desde Azure a SQL Server en
el nivel de la red virtual, la VPN de red y la máquina que hospeda SQL Server.
Configuran la instancia:
Paso 4: Configurar Azure DevOps

Contoso necesita compilar la infraestructura y las canalizaciones de DevOps para la aplicación. Para ello, los
administradores de Contoso crean un proyecto de DevOps, importan el código y luego configuran las
canalizaciones de compilación y versión.
1. En la cuenta de Azure DevOps de Contoso, crean un nuevo proyecto, ContosoSmar tHotelRefactor , y, a
continuación, seleccionan Git como control de versiones.
2. Importan el repositorio de Git que actualmente contiene su código de la aplicación. Lo descargan desde
el repositorio público de GitHub.
3. Conectan Visual Studio al repositorio y clonan el código en la máquina de desarrollo mediante Team
Explorer.
4. Abren el archivo de la solución para la aplicación. La aplicación web y el servicio WCF tienen proyectos
separados dentro del archivo.
Paso 5: Configurar cadenas de conexión
Los administradores de Contoso se aseguran de que las aplicaciones web y la base de datos pueden
comunicarse. Para ello, configura las cadenas de conexión en el código y en las aplicaciones web.
1. En la aplicación web del servicio WCF, SHWCF-EUS2 , en Configuración > Configuración de la
aplicación , agregan una nueva cadena de conexión llamada DefaultConnection .
2. Extraen la cadena de conexión de la base de datos SmartHotel-Registration y, a continuación, la actualizan
con las credenciales correctas.
3. En Visual Studio, los administradores abren el proyecto SmartHotel.Registration.wcf desde el archivo de

la solución. En el proyecto, actualizan la sección connectionStrings del archivo web.config con la cadena
de conexión.
4. Cambian la sección client del archivo web.config para que SmartHotel.Registration.Web apunte a la
nueva ubicación del servicio WCF. Esta es la dirección URL de la aplicación web WCF que hospeda el
punto de conexión de servicio.
5. Una vez realizados los cambios en el código, los administradores los confirman y los sincronizan
mediante Team Explorer en Visual Studio.
Paso 6: Configurar canalizaciones de compilación y versión en Azure

DevOps
Los administradores de Contoso configuran ahora Azure DevOps para ejecutar el proceso de compilación y
creación de versiones.
1. En Azure DevOps, seleccionan Compilación y versión > Nueva canalización .
2. Seleccionan GIT de Azure Repos y, en la lista desplegable Repositorio , seleccionan el repositorio

correspondiente.
3. En Seleccionar una plantilla , seleccionan la plantilla ASP.NET para su compilación.
4. Usan el nombre ContosoSmartHotelRefactor-ASP.NET-CI para la compilación y, a continuación, seleccionan

Guardar y poner en cola , lo que inicia la primera compilación.
5. Seleccionan el número de compilación para ver el proceso. Cuando termina, los administradores pueden
ver los comentarios del proceso y seleccionar Ar tefactos para revisar los resultados de la compilación.
Se abre el panel Explorador de ar tefactos y la carpeta drop muestra los resultados de la compilación.
Los dos archivos ZIP son los paquetes que contienen las aplicaciones.
Estos archivos ZIP se usan en la canalización de versión para la implementación en Azure App Service.
6. Seleccionan Versiones > + Nueva canalización .
7. Seleccionan la plantilla de implementación de Azure App Service.

8. Asignan a la canalización de versión el nombre ContosoSmartHotel360Refactor y, en Nombre de la fase ,
especifican SHWCF-EUS2 como nombre de la aplicación web de WCF.
9. En las fases, seleccionan 1 phase, 1 task (1 fase, 1 tarea) para configurar la implementación del servicio
WCF.
10. Comprueban que la suscripción está seleccionada y autorizada y, a continuación, seleccionan Nombre
de App Ser vice .
11. En la canalización > Ar tefactos , seleccionan + Agregar un ar tefacto y, después, optan por compilar
con la canalización ContosoSmarthotel360Refactor .
12. Los administradores seleccionan el icono de rayo en el artefacto para habilitar el desencadenador de la
implementación continua.
13. Establecen el desencadenador de implementación continua en Habilitado .

14. Ahora, vuelven a la fase 1 trabajo, 1 tarea y, después, seleccionan Implementación de Azure App
Ser vice .
15. En Seleccione un archivo o carpeta , expanden la carpeta drop , seleccionan el archivo

SmartHotel.Registration.Wcf.zip que se creó durante la compilación y, a continuación, seleccionan
Guardar .
16. Seleccionan Canalización > Fases y, a continuación, seleccionan + Agregar para agregar un entorno
para SHWEB-EUS2 . Seleccionan otra implementación de Azure App Service.
17. Repiten el proceso para publicar el archivo SmartHotel.Registration.Web.zip en la aplicación web
correcta y, a continuación, seleccionan Guardar .
Aparece la canalización de versión, como se muestra aquí:
18. Vuelven a Compilación , seleccionan Desencadenadores y, a continuación, activan la casilla Habilitar

la integración continua . Esta acción habilita la canalización para que, cuando se confirmen los cambios
en el código, se produzcan la compilación y la creación de versión completas.
19. Seleccionan Guardar y poner en cola para ejecutar la canalización completa. Se desencadena una
nueva compilación que, a su vez, crea la primera versión de la aplicación en Azure App Service.
20. Los administradores de Contoso pueden seguir el proceso de canalización de compilación y versión en
Azure DevOps. Una vez finalizada la compilación, se inicia la creación de versión.
21. Una vez finalizada la canalización, se habrán implementado ambos sitios y la aplicación estará en
funcionamiento en línea.
La aplicación se ha migrado correctamente a Azure.

Después de la migración, Contoso debe completar estos pasos de limpieza:
Quita las VM locales del inventario de vCenter.
Eliminan las máquinas virtuales de los trabajos de copia de seguridad locales.
Actualizan la documentación interna para que muestre las nuevas ubicaciones de la aplicación
SmartHotel360. La documentación muestra que la base de datos se ejecuta en Azure SQL Database y el
front-end está en ejecución en dos aplicaciones web.
Revisan los recursos que interactúan con las máquinas virtuales retiradas y actualizan los valores de
configuración pertinentes y la documentación para reflejar la nueva configuración.
Con los recursos ya migrados a Azure, Contoso debe proteger la infraestructura nueva y ponerla totalmente en
marcha.
Seguridad
Contoso tiene que asegurarse de que la nueva base de datos SmartHotel-Registration es segura. Más
información.
Específicamente, Contoso actualiza las aplicaciones web para usar SSL con certificados.
Copias de seguridad
El equipo de Contoso revisa los requisitos de copia de seguridad para la instancia de Azure SQL Database.
Más información.
También aprenden a administrar las copias de seguridad y las restauraciones de SQL Database. Más
información sobre las copias de seguridad automáticas.
Consideran la implementación de grupos de conmutación por error para proporcionar conmutación por
error regional para la base de datos. Más información.
Para lograr resistencia, consideran la implementación de la aplicación web en la región principal ( East US 2 )
y la región secundaria ( Central US ). El equipo podría configurar Traffic Manager para garantizar la
conmutación por error durante las interrupciones regionales.
Una vez implementados todos los recursos, Contoso asigna etiquetas de Azure según el planeamiento de la
infraestructura.
Todas las licencias se integran en el costo de los servicios de PaaS que consume Contoso. Este costo se
deduce del Contrato Enterprise.
Contoso usará Azure Cost Management + Billing para asegurarse de que la compañía permanece dentro de
los presupuestos establecidos por la dirección de TI.
Conclusión
En este artículo, Contoso refactorizó la aplicación SmartHotel360 en Azure mediante la migración de la VM de
front-end de la aplicación a dos aplicaciones web de Azure App Service. La base de datos de la aplicación se
migró a Azure SQL Database.
Refactorización de una aplicación local a una
aplicación web de Azure App Service y una
instancia de SQL Managed Instance
En este artículo se muestra cómo la compañía ficticia Contoso refactoriza una aplicación de Windows .NET de
dos niveles que se ejecuta en máquinas virtuales de VMware como parte de una migración a Azure. El equipo
de Contoso migra la máquina virtual de front-end de la aplicación a la aplicación web de Azure App Service. En
este artículo también se muestra cómo Contoso migra la base de datos de la aplicación a Azure SQL Managed
Instance.
La aplicación SmartHotel360 que se usa en este ejemplo se proporciona como software de código abierto. Si

Abordar el crecimiento del negocio. Contoso está creciendo y los sistemas y la infraestructura locales
están bajo presión.
de la empresa. El equipo de TI debe ir por delante de los cambios del mercado para garantizar el éxito en una
economía global. El tiempo de reacción no se debe interponer en el camino ni bloquear el negocio.
El equipo de la nube de Contoso ha definido los siguientes objetivos con el fin de determinar el mejor método
de migración:

Aplicación La aplicación de Azure seguirá siendo tan crítica como lo es

hoy en día en el entorno local.
Debe tener las mismas funcionalidades de rendimiento que

las que tiene actualmente en VMware.
El equipo no quiere invertir en la aplicación. Por ahora, los

administradores simplemente moverán la aplicación de
forma segura a la nube.
El equipo quiere finalizar el soporte técnico de

Windows Server 2008 R2, donde se ejecuta actualmente la
aplicación.
El equipo también quiere abandonar SQL Server 2008 R2 y

pasar a una base de datos de plataforma como servicio
(PaaS), lo que minimizará la necesidad de administración.
Contoso quiere aprovechar su inversión en licencias de

SQL Server y Software Assurance, tanto como que sea
posible.
Además, Contoso quiere mitigar el único punto de error en

el nivel web.
Limitaciones La aplicación está formada por una aplicación de ASP.NET y

un servicio Windows Communication Foundation (WCF) que
se ejecutan en la misma máquina virtual. Contoso quiere
distribuir estos componentes entre dos aplicaciones web con
Azure App Service.
Azure Contoso quiere mover la aplicación a Azure, pero no quiere

que se ejecute en máquinas virtuales. Quiere usar los
servicios de PaaS de Azure para los niveles web y de datos.
DevOps Contoso quiere migrar a un modelo DevOps, con Azure

DevOps para las canalizaciones de compilación y de versión.
Después de precisar los objetivos y requisitos, Contoso diseña y revisa una solución de implementación.
También identifica el proceso de migración, incluidos los servicios de Azure que usarán para la migración.
Aplicación actual
La aplicación SmartHotel360 local se divide en niveles entre dos máquinas virtuales ( WEBVM y SQLVM ).
máquina virtual.
Contoso tiene un centro de datos local (contoso-datacenter), con un controlador de dominio local
(contosodc1).
Solución propuesta
Para el nivel web de la aplicación, Contoso ha decidido usar Azure App Service. Este servicio PaaS permite
implementar la aplicación con tan solo unos cambios en la configuración. Contoso usará Visual Studio para
realizar el cambio e implementará dos aplicaciones web, una para el sitio web y otra para el servicio WCF.
Para cumplir los requisitos de una canalización de DevOps, Contoso usará Azure DevOps para la
administración del código fuente con repositorios de Git. Se usarán compilaciones y versiones automatizadas
para compilar el código e implementarlo en Azure App Service.
SQL Database y SQL Managed Instance. Contoso ha decidido usar SQL Managed Instance basándose en las
siguientes consideraciones:
El objetivo de SQL Managed Instance es proporcionar casi un 100 % de compatibilidad con la versión de la
instalación local de SQL Server más reciente. Microsoft recomienda SQL Managed Instance para los clientes
que ejecutan SQL Server de forma local o en máquinas virtuales de infraestructura como servicio (IaaS), que
desean migrar sus aplicaciones a un servicio totalmente administrado con cambios mínimos en el diseño.
Contoso planea migrar un gran número de aplicaciones desde el entorno local a máquinas de IaaS. Muchas
de estas máquinas virtuales las proporcionan proveedores de software independientes. Contoso se da
cuenta de que el uso de SQL Managed Instance le ayudará a garantizar la compatibilidad de las bases de
datos con estas aplicaciones. Utilizarán SQL Managed Instance en lugar de utilizar SQL Database, que podría
no ser compatible.
Contoso simplemente puede realizar una migración mediante lift-and-shift a SQL Managed Instance con
Azure Database Migration Service totalmente automatizado. Con este servicio, Contoso puede reutilizarla
para las migraciones futuras de la base de datos.
SQL Managed Instance admite el Agente SQL Server, un componente importante de la aplicación
SmartHotel360. Contoso necesita esta compatibilidad porque, sin ella, tendrá que volver a diseñar los planes
de mantenimiento que requiere la aplicación.
una instancia de SQL Managed Instance con la Ventaja híbrida de Azure para SQL Server. Esto permite a
Contoso ahorrar hasta un 30 % mediante el uso de SQL Managed Instance.
La instancia de SQL Managed Instance está totalmente integrada en la red virtual, por lo que ofrece un
mayor nivel de aislamiento y seguridad para los datos de Contoso. Contoso puede obtener las ventajas de la
nube pública y, al mismo tiempo, mantener el entorno aislado de la red Internet pública.
SQL Managed Instance admite muchas características de seguridad, entre otras, Always Encrypted,
enmascaramiento dinámico de datos, seguridad en el nivel de fila y detección de amenazas.
Contoso evalúa el diseño propuesto y crea una lista de ventajas y desventajas como se muestra en la tabla
siguiente:
Ventajas No es necesario modificar el código de la aplicación

SmartHotel360 para la migración a Azure.

Assurance con la Ventaja híbrida de Azure para SQL Server y
Windows Server.
Después de la migración, ya no será necesaria la

compatibilidad con Windows Server 2008 R2. Para obtener
más información, consulte la directiva de ciclo de vida de
Microsoft.
Contoso puede configurar el nivel web de la aplicación con

varias instancias, para que el nivel web deje de ser un único
punto de error.
La base de datos ya no dependerá de la antigüedad de

SQL Server 2008 R2.
Instancia administrada de SQL admite los requisitos técnicos

y los objetivos de Contoso.
La instancia de SQL Managed Instance va a proporcionar

compatibilidad total con su implementación actual, al tiempo
que le permite dejar de usar SQL Server 2008 R2.

Software Assurance y usar la Ventaja híbrida de Azure para
SQL Server y Windows Server.
Puede volver a usar Azure Database Migration Service para

futuras migraciones adicionales.
La instancia de SQL Managed Instance tiene tolerancia a

errores integrada que Contoso no necesita configurar. Esto
Desventajas Azure App Service solo admite la implementación de una

aplicación por cada aplicación web. Esto significa que deben
aprovisionarse dos aplicaciones web (una para el sitio web y
otra para el servicio WCF).
Para la capa de datos, es posible que SQL Managed Instance

no sea la mejor solución si Contoso desea personalizar el
sistema operativo o el servidor de base de datos, o si desea
ejecutar aplicaciones de terceros junto con SQL Server. La
ejecución de SQL Server en una máquina virtual IaaS puede
proporcionar esta flexibilidad.
1. Contoso aprovisiona una instancia de Azure SQL Managed Instance a la que migra la base de datos
SmartHotel360 mediante Azure Database Migration Service.
2. Aprovisiona y configura las aplicaciones web e implementa la aplicación SmartHotel360 en ellas.
Servicios de Azure
Azure App Service Migration Assistant Una forma sencilla y gratuita de migrar Es una herramienta que se puede
sin problemas aplicaciones web de descargar de forma gratuita.
.NET desde el entorno local a la nube
con cambios mínimos en el código o
incluso sin ningún cambio.
Instancia administrada de Azure SQL SQL Managed Instance es un servicio El uso de una instancia de SQL
de base de datos administrada que Managed Instance que se ejecuta en
representa una instancia de Azure conlleva cargos en función de la
SQL Server completamente capacidad. Más información acerca de
administrada en Azure. Usa el mismo los precios de SQL Managed Instance.
código que la versión más reciente del
motor de base de datos de SQL Server
y tiene las características, mejoras de
rendimiento y revisiones de seguridad
más recientes.
Azure App Service Permite crear aplicaciones en la nube Los precios se basan en el tamaño, la
eficaces que usan una plataforma ubicación y la duración del uso. Más
totalmente administrada. información.
Azure Pipelines Ofrece una canalización de integración

continua e implementación continua
(CI/CD) para el desarrollo de
aplicaciones. La canalización comienza
con un repositorio de Git para
administrar código de aplicaciones, un
sistema de compilación para producir
paquetes y otros artefactos de
compilación, y un sistema de
administración de versiones para
implementar cambios en entornos de
desarrollo, prueba y producción.
Requisitos previos




Pasos del escenario

Paso 1: Evaluar y migrar las aplicaciones web . Contoso usa la herramienta Azure App Service
Migration Assistant para ejecutar comprobaciones de compatibilidad previas a la migración y migrar sus
aplicaciones web a Azure App Service.
Paso 2: Configuración de una instancia de SQL Managed Instance . Contoso necesita una instancia
administrada existente a la que se migrará la base de datos de SQL Server local.
Paso 3: Migración a través de Azure Database Migration Ser vice . Contoso migra la base de datos de
la aplicación a través de Azure Database Migration Service.
Paso 4: Configuración de Azure DevOps . Contoso crea un proyecto de Azure DevOps e importa el
repositorio de Git.
Paso 5: Configuración de cadenas de conexión . Contoso configura las cadenas de conexión para que la
instancia de SQL Managed Instance, la aplicación web del servicio WCF y la aplicación web del nivel web
puedan comunicarse.
Paso 6: Configuración de las canalizaciones de compilación y versión en Azure DevOps . Como
último paso, Contoso configura las canalizaciones de compilación y de versión en Azure DevOps para crear
la aplicación. A continuación, el equipo implementa las canalizaciones en dos aplicaciones web
independientes.
Paso 1: Evaluar y migrar las aplicaciones web

Los administradores de Contoso evalúan y migran su aplicación web mediante la herramienta Azure App
Service Migration Assistant. Usan la ruta de aprendizaje de Microsoft Learn como guía durante el proceso. En
resumen, los administradores realizan las siguientes acciones:
Usan la herramienta Azure App Service Migration Assistant para evaluar las dependencias entre sus
aplicaciones web y determinar si hay alguna incompatibilidad entre las aplicaciones web locales y
aquellas que se admiten en Azure App Service.
Descargan Azure App Service Migration Assistant e inician sesión en su cuenta de Azure.
Eligen una suscripción, un grupo de recursos y el nombre de dominio del sitio web.
Paso 2: Configuración de una instancia de SQL Managed Instance

Para configurar una instancia de Azure SQL Managed Instance, Contoso necesita una subred que cumpla los
requisitos siguientes:
La subred debe estar dedicada. Debe estar vacía y no puede contener ningún otro servicio en la nube. La
subred no puede ser una subred de puerta de enlace.
Una vez creada la instancia administrada, Contoso no debe agregar recursos a la subred.
La subred no puede tener asociado un grupo de seguridad de red.
La subred debe tener una tabla de rutas definida por el usuario. La única ruta asignada debe ser 0.0.0.0/0 ,
con Internet como próximo salto.
Si se especifica un DNS personalizado para la red virtual, es necesario agregar a la lista la dirección IP virtual
168.63.129.16 de las resoluciones recursivas de Azure. Aprenda a configurar un servidor DNS personalizado
para una instancia de Azure SQL Managed Instance.
La subred no puede tener un punto de conexión de servicio (de almacenamiento o SQL) asociado a ella. Los
puntos de conexión de servicio se deben deshabilitar en la red virtual.
La subred tiene que tener como mínimo 16 direcciones IP. Aprenda cómo cambiar el tamaño de la subred de
la instancia administrada.
En el entorno híbrido de Contoso, se requiere la configuración de DNS personalizada. Contoso configura los
valores de DNS para usar uno o varios de los servidores de Azure DNS de la empresa. Más información
sobre la personalización de DNS.
Configurar una red virtual para la instancia administrada
Los administradores de Contoso configuran la red virtual de la forma siguiente:
1. Crean una nueva red virtual ( VNET-SQLMI-EU2 ) en la región primaria ( East US 2 ). Agregan la red virtual
al grupo de recursos ContosoNetworkingRG .
2. Asignan el espacio de direcciones 10.235.0.0/24 . Garantizan que el intervalo no se solapa con otras
redes de su empresa.
3. Se agregan dos subredes a la red:
SQLMI-DS-EUS2 ( 10.235.0.0/25 ).
SQLMI-SAW-EUS2 ( 10.235.0.128/29 ). Esta subred se usa para asociar un directorio a la instancia
administrada.
4. Después de implementar la red virtual y las subredes, emparejan las redes como se indica a continuación:
Se empareja VNET-SQLMI-EUS2 con VNET-HUB-EUS2 (la red virtual del centro de conectividad de
East US 2 ).
Se empareja VNET-SQLMI-EUS2 con VNET-PROD-EUS2 (la red de producción).
5. Establecen una configuración de DNS personalizada. La configuración de DNS primero apunta a los
controladores de dominio de Azure de Contoso. Azure DNS es secundario. Los controladores de dominio
de Azure de Contoso están ubicados de la manera siguiente:
Ubicados en la subred PROD-DC-EUS2 , en la red de producción ( VNET-PROD-EUS2 ) en la región
East US 2 .
Dirección de CONTOSODC3 : 10.245.42.4
Dirección de CONTOSODC4 : 10.245.42.5
Solucionador de Azure DNS: 168.63.129.16

Consulte la introducción a SQL Managed Instance.
Aprenda cómo crear una red virtual para una instancia de SQL Managed Instance.
Más información sobre cómo configurar el emparejamiento.
Más información sobre cómo actualizar la configuración de DNS de Azure Active Directory.
Configuración del enrutamiento
La instancia administrada se coloca en una red privada virtual. Contoso necesita una tabla de enrutamiento para
que la red virtual se comunique con el servicio de administración de Azure. Si la red virtual no puede
comunicarse con el servicio que la administra, se vuelve inaccesible.
Contoso tiene en cuenta estos factores:
La tabla de enrutamiento contiene un conjunto de reglas (rutas) que especifican cómo se deben enrutar los
paquetes enviados en la red virtual desde la instancia administrada.
La tabla de enrutamiento se asocia con subredes en las que se implementan instancias administradas. Cada
paquete que sale de una subred se controla en función de la tabla de rutas asociada.
Una subred puede asociarse con una sola tabla de rutas.
No hay ningún cargo adicional por la creación de tablas de redirección en Microsoft Azure.
Para configurar el enrutamiento, los administradores de Contoso siguen estos pasos:
1. Se crea una tabla de enrutamiento definida por el usuario en el grupo de recursos ContosoNetworkingRG .
2. Para cumplir los requisitos de SQL Managed Instance, tras implementar la tabla de rutas ( MIRouteTable ),
los administradores agregan una ruta con un prefijo de dirección 0.0.0.0/0 . La opción Tipo de
próximo salto está establecida en Internet .
3. Se asocia la tabla de enrutamiento con la subred SQLMI-DB-EUS2 (en la red VNET-SQLMI-EUS2 ).

Aprenda cómo configurar rutas para una instancia administrada.
Creación de una instancia administrada
Ahora, los administradores de Contoso aprovisionan una instancia de SQL Managed Instance. Para ello:
1. Como la instancia administrada da servicio a una aplicación empresarial, los administradores
implementan la instancia administrada en la región primaria de la empresa (Este de EE. UU. 2). La
instancia administrada se agrega al grupo de recursos ContosoRG .
2. Seleccionan un plan de tarifa y el tamaño de los recursos de tamaño y almacenamiento de la instancia.
Más información acerca de los precios de SQL Managed Instance.
Una vez implementada la instancia administrada, aparecen dos nuevos recursos en el grupo de recursos
ContosoRG :
La instancia de SQL Managed Instance.

Un clúster virtual en caso de que Contoso tenga varias instancias administradas.

Aprenda cómo aprovisionar una instancia administrada.
Paso 3: Migración a través de Azure Database Migration Service

Los administradores de Contoso siguen las instrucciones del tutorial de migración paso a paso para migrar la
instancia administrada con Azure Database Migration Service. Pueden realizar migraciones en línea, sin
conexión e híbridas (versión preliminar).
En resumen, los administradores de Contoso hacen lo siguiente:
Crean una instancia de Azure Database Migration Service con una SKU Premium que está conectada a la red
virtual.
Se aseguran de que Database Migration Service pueda acceder a la instancia remota de SQL Server a través
de la red virtual. Esto implicaría asegurarse de que todos los puertos de entrada están permitidos desde
Azure a SQL Server en el nivel de la red virtual, la VPN de red y la máquina que hospeda SQL Server.
Configuran Azure Database Migration Service:
Paso 4: Configurar Azure DevOps

Contoso necesita compilar la infraestructura y las canalizaciones de DevOps para la aplicación. Para ello, los
administradores de Contoso crean un proyecto de DevOps, importan el código y luego configuran las
canalizaciones de compilación y versión.
1. En la cuenta de Azure DevOps de Contoso, crean un nuevo proyecto, ContosoSmartHotelRefactor , y, a
continuación, seleccionan Git como control de versiones.
2. Importan el repositorio de Git que actualmente contiene su código de la aplicación. Lo descargan desde
el repositorio público de GitHub.
3. Conectan Visual Studio al repositorio y clonan el código en la máquina de desarrollo mediante Team
Explorer.
4. Abren el archivo de la solución para la aplicación. La aplicación web y el servicio WCF tienen proyectos
separados dentro del archivo.
Paso 5: Configurar cadenas de conexión
Los administradores de Contoso se aseguran de que las aplicaciones web y la base de datos pueden
comunicarse. Para ello, configura las cadenas de conexión en el código y en las aplicaciones web.
1. En la aplicación web del servicio WCF, SHWCF-EUS2 , en Configuración > Configuración de la
aplicación , agregan una nueva cadena de conexión llamada DefaultConnection .
2. Extraen la cadena de conexión de la base de datos SmartHotel-Registration y, a continuación, la actualizan
con las credenciales correctas.
3. En Visual Studio, los administradores abren el proyecto SmartHotel.Registration.wcf desde el archivo de

la solución. En el proyecto, actualizan la sección connectionStrings del archivo web.config con la cadena
de conexión.
4. Cambian la sección client del archivo web.config para que SmartHotel.Registration.Web apunte a la
nueva ubicación del servicio WCF. Esta es la dirección URL de la aplicación web WCF que hospeda el
punto de conexión de servicio.
5. Una vez realizados los cambios en el código, los administradores los confirman y los sincronizan
mediante Team Explorer en Visual Studio.
Paso 6: Configurar canalizaciones de compilación y versión en Azure

DevOps
Los administradores de Contoso configuran ahora Azure DevOps para ejecutar el proceso de compilación y
creación de versiones.
1. En Azure DevOps, seleccionan Compilación y versión > Nueva canalización .
2. Seleccionan Repositorio GIT de Azure Repos y el repositorio correspondiente.

3. En Seleccionar una plantilla , selecciona la plantilla de ASP.NET para su compilación.
4. Usan el nombre ContosoSmartHotelRefactor-ASP.NET-CI para la compilación y, a continuación, seleccionan

Guardar y poner en cola , lo que inicia la primera compilación.
5. Seleccionan el número de compilación para ver el proceso. Cuando termina, los administradores pueden
ver los comentarios del proceso y seleccionar Ar tefactos para revisar los resultados de la compilación.
Se abre el panel Explorador de ar tefactos y la carpeta drop muestra los resultados de la compilación.
Los dos archivos ZIP son los paquetes que contienen las aplicaciones.
Estos archivos ZIP se usan en la canalización de versión para la implementación en Azure App Service.
6. Seleccionan Versiones > + Nueva canalización .
7. Seleccionan la plantilla de implementación de Azure App Service.

8. Asignan a la canalización de versión el nombre ContosoSmartHotel360Refactor y, en Nombre de la fase ,
especifican SHWCF-EUS2 como nombre de la aplicación web de WCF.
9. En las fases, seleccionan 1 phase, 1 task (1 fase, 1 tarea) para configurar la implementación del servicio
WCF.
10. Comprueban que la suscripción está seleccionada y autorizada y, a continuación, seleccionan Nombre
de App Ser vice .
11. En la canalización, seleccionan Ar tefactos , + Agregar un ar tefacto , después, seleccionan

Compilación como el tipo de origen y, finalmente, compilan con la canalización
ContosoSmarthotel360Refactor .
12. Los administradores seleccionan el icono de rayo en el artefacto para habilitar el desencadenador de la
implementación continua.
13. Establecen el desencadenador de implementación continua en Habilitado .

14. Ahora, vuelven a la fase 1 trabajo, 1 tarea y, después, seleccionan Implementación de Azure App
Ser vice .
15. En Seleccione un archivo o carpeta , expanden la carpeta drop , seleccionan el archivo

SmartHotel.Registration.Wcf.zip que se creó durante la compilación y, a continuación, seleccionan
Guardar .
16. Seleccionan Canalización > Fases y, a continuación, seleccionan + Agregar para agregar un entorno
para SHWEB-EUS2 . Seleccionan otra implementación de Azure App Service.
17. Repiten el proceso para publicar el archivo de aplicación web ( SmartHotel.Registration.Web.zip ) en la
aplicación web correcta y, a continuación, seleccionan Guardar .
Aparece la canalización de versión, como se muestra aquí:
18. Vuelven a Compilación , seleccionan Desencadenadores y, a continuación, activan la casilla Habilitar

la integración continua . Esta acción habilita la canalización para que, cuando se confirmen los cambios
en el código, se produzcan la compilación y la creación de versión completas.
19. Seleccionan Guardar y poner en cola para ejecutar la canalización completa. Se desencadena una
nueva compilación que, a su vez, crea la primera versión de la aplicación en Azure App Service.
20. Los administradores de Contoso pueden seguir el proceso de canalización de compilación y versión en
Azure DevOps. Una vez finalizada la compilación, se inicia la creación de versión.
21. Una vez finalizada la canalización, se han implementado ambos sitios, y la aplicación está funcionamiento
en línea.
La aplicación se ha migrado correctamente a Azure.
Limpieza después de la migración

Después de la migración, el equipo de Contoso realiza los siguientes pasos de limpieza:
Quita las VM locales del inventario de vCenter.
Eliminan las máquinas virtuales de los trabajos de copia de seguridad locales.
Actualizan la documentación interna para que muestre las nuevas ubicaciones de la aplicación
SmartHotel360. La documentación muestra que la base de datos se ejecuta en SQL Managed Instance y el
front-end está en ejecución en dos aplicaciones web.
Revisan los recursos que interactúan con las máquinas virtuales retiradas y actualizan los valores de
configuración pertinentes y la documentación para reflejar la nueva configuración.
Con los recursos ya migrados a Azure, Contoso debe proteger la infraestructura nueva y ponerla totalmente en
marcha.
Seguridad
Contoso tiene que asegurarse de que la nueva base de datos SmartHotel-Registration es segura. Más
información.
Específicamente, Contoso actualiza las aplicaciones web para usar SSL con certificados.
Copias de seguridad
El equipo de Contoso revisa los requisitos de copia de seguridad de la base de datos de Azure SQL Managed
Instance. Más información.
También aprenden a administrar las copias de seguridad y las restauraciones de SQL Database. Más
información sobre las copias de seguridad automáticas.
Consideran la implementación de grupos de conmutación por error para proporcionar conmutación por
error regional para la base de datos. Más información.
Para lograr resistencia, consideran la implementación de la aplicación web en la región principal ( East US 2 )
y la región secundaria ( Central US ). El equipo podría configurar Traffic Manager para garantizar la
conmutación por error durante las interrupciones regionales.
Una vez implementados todos los recursos, Contoso asigna etiquetas de Azure según el planeamiento de la
infraestructura.
Todas las licencias se integran en el costo de los servicios de PaaS que consume Contoso. Este costo se
deduce del Contrato Enterprise.
Contoso va a usar Azure Cost Management + Billing para asegurarse de ajustarse a los presupuestos
establecidos por la dirección de TI.
Conclusión
En este artículo, Contoso refactorizó la aplicación SmartHotel360 en Azure mediante la migración de la VM de
front-end de la aplicación a dos aplicaciones web de Azure App Service. La base de datos de la aplicación se
migró a una instancia de Azure SQL Managed Instance.
Refactorización de una aplicación de Linux
mediante Azure App Service, Traffic Manager y
Azure Database for MySQL
En este artículo se muestra cómo la empresa ficticia Contoso refactoriza una aplicación basada en LAMP de dos
niveles y la migra del entorno local a Azure mediante Azure App Service con integración de GitHub y Azure
Database for MySQL.
osTicket, la aplicación de consola de servicio que se usa en este ejemplo, se proporciona como software de
código abierto. Si quiere utilizarla para sus propias pruebas, puede descargarla desde el repositorio de osTicket
de GitHub.

El equipo directivo de TI ha trabajado estrechamente con sus socios comerciales para comprender sus objetivos:
Abordar el crecimiento del negocio. Contoso crece y se mueve a mercados nuevos. Se necesitan más
agentes de servicio al cliente.
Escala. se debe compilar la solución para que Contoso pueda agregar más agentes de servicio al cliente al
escalar el negocio.
Mejora de la resistencia. En el pasado, los problemas del sistema afectaban solo a los usuarios internos.
Con su nuevo modelo de negocio, se verán afectados los usuarios externos, y Contoso necesita que la
aplicación esté siempre en funcionamiento.
La aplicación debe escalar más allá de la capacidad y el rendimiento local actual. Contoso va a mover la
aplicación para aprovechar las ventajas del escalado a petición de Azure.
Contoso quiere mover el código base de la aplicación a una canalización de entrega continua. Cuando los
cambios de la aplicación se inserten en GitHub, Contoso quiere implementar dichos cambios sin tareas para
el personal de operaciones.
La aplicación debe ser resistente, con funcionalidades para el crecimiento y la conmutación por error.
Contoso quiere implementar la aplicación en dos regiones de Azure diferentes y configurarla para el
escalado automático.
Quiere minimizar las tareas de administración de la base de datos tras mover la aplicación a la nube.
Después de fijar sus objetivos y requisitos, Contoso diseña y revisa una solución de implementación e identifica
el proceso de migración, incluidos los servicios de Azure que usará para la migración.
Arquitectura actual
La aplicación se divide en niveles entre dos máquinas virtuales ( OSTICKETWEB y OSTICKETMYSQL ).
máquina virtual.
contosodc1 ).
Esta es la arquitectura propuesta:
La aplicación de nivel web en OSTICKETWEB se migrará mediante la compilación de una aplicación web de
Azure App Service en dos regiones de Azure. El equipo de Contoso implementará Azure App Service para
Linux mediante el contenedor Docker de PHP 7.0.
El código de la aplicación se moverá a GitHub y Azure App Service Web App se configurará para la entrega
continua con GitHub.
Azure App Service se implementará tanto en la región primaria ( East US 2 ) como en la región secundaria (
Central US ).
Azure Traffic Manager se configurará delante de las dos aplicaciones web en ambas regiones.
Traffic Manager se configurará en modo de prioridad para forzar el tráfico a través de East US 2 .
Si Azure App Server en East US 2 se queda sin conexión, los usuarios pueden obtener acceso a la aplicación
de conmutación por error en la Central US .
La base de datos de la aplicación se migrará al servicio Azure Database for MySQL mediante Azure Database
Migration Service. La copia de seguridad de la base de datos local se realizará localmente y se restaurará de
forma directa en Azure Database for MySQL.
La base de datos residirá en la región primaria ( East US 2 ) de la subred de la base de datos ( PROD-DB-EUS2 )
de la red de producción ( VNET-PROD-EUS2 ).
Dado que se migra una carga de trabajo de producción, los recursos de Azure para la aplicación residirán en
el grupo de recursos de producción ContosoRG .
El recurso Traffic Manager se implementará en el grupo de recursos de la infraestructura de Contoso,
ContosoInfraRG .
Contoso completa el proceso de migración como se indica a continuación:
1. Como primer paso, los administradores de Contoso configuran la infraestructura de Azure, incluido el
aprovisionamiento de Azure App Service, la configuración de Traffic Manager y el aprovisionamiento de una
instancia de Azure Database for MySQL.
2. Después de preparar la infraestructura de Azure, migran la base de datos mediante Azure Database
Migration Service.
3. Cuando la base de datos se ejecuta en Azure, configuran un repositorio privado de GitHub para Azure App
Service con entrega continua y lo cargan con la aplicación osTicket.
4. En Azure Portal, se carga la aplicación desde GitHub en el contenedor Docker que ejecuta Azure App Service.
5. Se modifica la configuración de DNS y se configura el escalado automático para la aplicación.
Servicios de Azure
Azure App Service El servicio ejecuta y escala Los precios se basan en el

aplicaciones mediante el tamaño de las instancias y
servicio PaaS de Azure para en las características que se
sitios web. necesiten. Más información.
Azure Traffic Manager Un equilibrador de carga Los precios se basan en el Más información.
que usa un Sistema de número de consultas de
nombres de dominio (DNS) DNS recibidas y el número
para dirigir los usuarios a de puntos de conexión
Azure o a sitios web y supervisados.
servicios externos.
Azure Database Migration Azure Database Migration Información acerca de las

Service Service permite migraciones regiones admitidas y los
completas de varios precios de Database
orígenes de base de datos a Migration Service.
plataformas de datos de
Azure, con un tiempo de
inactividad mínimo.
Azure Database for MySQL La base de datos se basa en Los precios se basan en los
el motor de base de datos requisitos de proceso,
MySQL de código abierto. almacenamiento y copia de
Proporciona una base de seguridad. Más información.
datos MySQL de la
comunidad completamente
administrada y lista para la
empresa para el desarrollo y
la implementación de
aplicaciones.
Requisitos previos




Pasos del escenario

Este es el plan de Contoso para realizar la migración:
Paso 1: Aprovisionamiento de Azure App Ser vice . Los administradores de Contoso aprovisionarán
aplicaciones web en las regiones primarias y secundarias.
Paso 2: Configuración de Traffic Manager . Configurarán Traffic Manager delante de las aplicaciones web
para el enrutamiento y el equilibrio de carga del tráfico.
Paso 3: Aprovisionamiento de Azure Database for MySQL . En Azure, aprovisionarán una instancia de
Paso 4: Migración de la base de datos . Contoso migra la base de datos mediante Azure Database
Migration Service.
Paso 5: Configuración de GitHub . Se configura un repositorio de GitHub local para los sitios web y el
código de la aplicación.
Paso 6: Configuración de las aplicaciones web . Se configuran las aplicaciones web con los sitios web
de osTicket.
Paso 1: Aprovisionamiento de Azure App Service.

Los administradores de Contoso aprovisionan dos aplicaciones web (una en cada región) con Azure App
Service.
1. Crean un recurso de aplicación web ( osticket-eus2 ) en la región primaria ( East US 2 ) desde Azure
Marketplace.
2. Colocan el recurso en el grupo de recursos de producción ContosoRG .
3. Se crea un plan de App Service ( APP-SVP-EUS2 ) en la región primaria y se usa el tamaño estándar.
4. Seleccionan un sistema operativo Linux con la pila en tiempo de ejecución PHP 7.0, que es un contenedor
de Docker.
5. Crean una segunda aplicación web ( osticket-cus ) y un plan de Azure App Service para la región Centro
de EE. UU .

Más información sobre Azure App Service Web Apps.
Información sobre Azure App Service en Linux.
Paso 2: Configuración de Traffic Manager

Los administradores de Contoso configuran Traffic Manager para dirigir las solicitudes web entrantes a las
aplicaciones web que se ejecutan en nivel web de osTicket.
1. Crean un recurso de Traffic Manager ( osticket.trafficmanager.net ) en Azure Marketplace. Usan el
enrutamiento de prioridad para que la región Este de EE. UU. 2 sea el sitio primario. Colocan el recurso
en el grupo de recursos de la infraestructura existente ( ContosoInfraRG ). Tenga en cuenta que Traffic
Manager es global y no está enlazado a una ubicación específica.
2. Configuran Traffic Manager con puntos de conexión. Agregan la aplicación web de la región Este de
EE. UU. 2 como sitio primario ( osticket-eus2 ) y la aplicación web del Centro de EE. UU. como secundario
( osticket-cus ).
3. Después de agregar los puntos de conexión, los administradores pueden supervisarlos.

Más información sobre Traffic Manager.
Más información sobre el enrutamiento del tráfico a un punto de conexión prioritario.
Paso 3: Aprovisionamiento de Azure Database for MySQL

Los administradores de Contoso aprovisionan una instancia de base de datos MySQL en la región primaria (Este
de EE. UU. 2).
1. En Azure Portal, crea un recurso de Azure Database for MySQL.
2. Agrega el nombre contosoosticket para la base de datos de Azure. Agregan la base de datos al grupo de
recursos de producción ContosoRG y, después, especifican las credenciales.
3. La base de datos MySQL local es de la versión 5.7, por lo que selecciona esta versión por cuestiones de
compatibilidad. Utiliza los tamaños predeterminados, que coinciden con los requisitos de la base de
datos.
4. Para las opciones de redundancia de copia de seguridad , seleccionan Redundancia geográfica .

Esta opción permite restaurar la base de datos de su región secundaria (Centro de EE. UU.) si se produce
una interrupción. Solo pueden configurar esta opción al aprovisionar la base de datos.
5. Configuran la seguridad de conexión. En la base de datos, seleccionan Seguridad de la conexión y

configuran las reglas de firewall para permitir que la base de datos acceda a los servicios de Azure.
6. Se agrega la dirección IP del cliente de la estación de trabajo local a las direcciones IP inicial y final. Esto
permite que las aplicaciones web tengan acceso a la base de datos MySQL, junto con el cliente de base de
datos que realiza la migración.
Paso 4: Migración de la base de datos

Hay varias maneras de mover la base de datos MySQL. Cada opción requiere que los administradores de
Contoso creen una instancia de Azure Database for MySQL para el destino. Después de crear la instancia,
pueden migrar la base de datos mediante cualquiera de las dos rutas de acceso:
Paso 4a: Azure Database Migration Service
Paso 4b: Copia de seguridad y restauración de MySQL Workbench
Paso 4a: Migración de la base de datos mediante Azure Database Migration Service
preliminar) mediante MySQL 5.6 o 5.7.
NOTE
MySQL 8.0 se admite en Azure Database for MySQL, pero la herramienta Azure Database Migration Service todavía no es
compatible con esta versión.
En Resumen, Contoso hace lo siguiente:

Garantizan que se cumplen todos los requisitos previos:
El origen del servidor de bases de datos MySQL debe coincidir con la versión que admite Azure
Database for MySQL. Azure Database for MySQL admite MySQL Community Edition, el motor de
Habilitan el registro binario en my.ini (Windows) o my.cnf (Unix). Si esto no se hace, se
producirá el siguiente error en el Asistente para migración:
Error in binary logging. Variable binlog_row_image has value 'minimal'. Please change it to
'full'.
Crean una red virtual que se conecta a través de ExpressRoute o VPN a la red local.
Crean una instancia de Azure Database Migration Service con una SKU Premium que está conectada a la
red virtual.
Garantizan que Azure Database Migration Service pueda acceder a la base de datos MySQL a través de la
red virtual. Esto implica asegurarse de que todos los puertos de entrada están permitidos desde Azure a
MySQL en el nivel de la red virtual, la VPN de red y la máquina que hospeda MySQL.
Ejecutan la herramienta Database Migration Service y, a continuación, hacen lo siguiente:
1. Crean un proyecto de migración basado en la SKU Premium.
2. Agregue un origen (base de datos local).
3. Seleccione un destino.
4. Seleccione las bases de datos que se van a migrar.

5. Configure las opciones avanzadas.
6. Inicie la replicación y resuelva los posibles errores.
7. Realice la migración final.

8. Restablezca las claves externas y los desencadenadores.
9. Modifique las aplicaciones para que usen la nueva base de datos.
Paso 4b: Migración de la base de datos (MySQL Workbench)
1. Los administradores de Contoso comprueban los requisitos previos y las descargas de MySQL
Workbench.
2. Instala MySQL Workbench para Windows de acuerdo con las instrucciones de instalación. La máquina en
la que instalen MySQL Workbench debe ser accesible para la máquina virtual osticketmysql y para
Azure a través de Internet.
3. En MySQL Workbench, se crea una conexión de MySQL a osticketmysql .
4. Exportan la base de datos como osticket a un archivo independiente local.

5. Después de realizar la copia de seguridad de la base de datos localmente, los administradores crean una
conexión a la instancia de Azure Database for MySQL.
6. Ahora, pueden importar (restaurar) la base de datos en la instancia de Azure Database for MySQL desde
el archivo independiente. Se crea un nuevo esquema ( osticket ) para la instancia.
7. Una vez que hayan restaurado los datos, los administradores podrán consultarlos mediante MySQL
Workbench. Los datos se muestran en Azure Portal.
8. Los administradores actualizan la información de la base de datos en las aplicaciones web. En la instancia
de MySQL, se abre Cadenas de conexión .
9. En la lista cadenas de conexión, seleccionan la configuración de la aplicación web y, a continuación, la
copian seleccionando Haga clic para copiar .
10. Abren una nueva ventana del Bloc de notas, pegan la cadena allí y la actualizan para que coincida con la
base de datos de osTicket, la instancia de MySQL y la configuración de credenciales.
11. Pueden comprobar el nombre del servidor y el inicio de sesión en el panel de información general de
la instancia de MySQL en Azure Portal.
Paso 5: Configuración de GitHub

Los administradores de Contoso crean un repositorio de GitHub privado y configuran una conexión a la base de
datos osTicket en Azure Database for MySQL. Después, cargan la aplicación web en Azure App Service.
1. Van al repositorio de GitHub público de software de osTicket y lo bifurcan a la cuenta de GitHub de
Contoso.
2. Después de bifurcar el repositorio, van a la carpeta include y seleccionan el archivo ost-config.php .

3. Se abre el archivo en el explorador y se edita.
4. En el editor, los administradores actualizan los detalles de la base de datos, específicamente para DBHOST
y DBUSER .
5. Los administradores confirman los cambios.
6. Para cada aplicación web ( osticket-eus2 y osticket-cus ), en Azure Portal, seleccionan Configuración
de la aplicación en el panel izquierdo y, a continuación, modifican la configuración.
7. Se especifica la cadena de conexión con el nombre osticket y se copia la cadena desde el Bloc de notas
en el área de valores . Se selecciona MySQL en la lista desplegable junto a la cadena y se guarda la
configuración.
Paso 6: Configuración de las aplicaciones web

Como último paso del proceso de migración, los administradores de Contoso configuran las aplicaciones web
con los sitios web de osTicket.
1. En la aplicación web principal ( osticket-eus2 ), abren Opción de implementación y establecen el
origen en GitHub .
2. Se seleccionan las opciones de implementación.

3. Después de establecer las opciones, la configuración aparece como pendiente en Azure Portal.
4. Después de actualizar la configuración y cargar la instancia de la aplicación web de osTicket desde GitHub
en el contenedor de Docker que ejecuta Azure App Service, el sitio se muestra como activo .
5. Repiten los pasos anteriores para la aplicación web secundaria, osticket-cus .

6. Tras configurar el sitio, es accesible a través del perfil de Traffic Manager. El nombre DNS es la nueva
ubicación de la aplicación osTicket. Más información.
7. Contoso quiere usar un nombre DNS que sea fácil de recordar. En el panel Nuevo registro de
recursos , crean un alias (CNAME) y un nombre de dominio completo ( osticket.contoso.com ) que
apunta al nombre de Traffic Manager en el DNS de sus controladores de dominio.
8. Se configuran ambas aplicaciones web, osticket-eus2 y osticket-cus , para permitir los nombres de host
personalizados.
Configurar el escalado automático
Por último, los administradores de Contoso configuran el escalado automático de la aplicación. El escalado
automático garantiza que, a medida que los agentes usan la aplicación, las instancias de aplicación aumentan y
disminuyen en función de las necesidades empresariales.
1. En App Service APP-SVP-EUS2 , abren Unidad de escalado .
2. Se configura una nueva opción de escalado automático con una única regla que aumenta el recuento de
instancias en uno cuando el uso de CPU para la instancia actual es superior al 70 % durante 10 minutos.
3. Se configura la misma opción en APP-SVP-CUS para asegurarse de que se aplica el mismo

comportamiento si la aplicación conmuta por error a la región secundaria. La única diferencia es que se
establece la instancia predeterminada en 1, ya que solo es para las conmutaciones por error.
Al completar la migración, se refactoriza la aplicación osTicket para que se ejecute en una aplicación web de
Azure App Service con entrega continua mediante un repositorio de GitHub privado. La aplicación se ejecuta en
dos regiones para aumentar la resistencia. La base de datos de osTicket se ejecuta en Azure Database for MySQL
después de la migración a la plataforma PaaS.
Para realizar una limpieza después de la migración, Contoso hace lo siguiente:
Eliminan las máquinas virtuales de VMware del inventario de vCenter.
Quita las VM locales de los trabajos de copia de seguridad locales.
Actualizan la documentación interna para que muestre las nuevas ubicaciones y direcciones IP.
Revisan los recursos que interactúan con las máquinas virtuales locales y actualizan los valores de
configuración pertinentes o la documentación para reflejar la nueva configuración.
Vuelven a configurar la supervisión para que apunte a la dirección URL osticket-trafficmanager.net , para
realizar un seguimiento de que la aplicación está en funcionamiento.
Con la aplicación en ejecución, Contoso debe proteger y poner plenamente en funcionamiento la infraestructura
nueva.
Seguridad
El equipo de seguridad de Contoso revisa la aplicación para determinar si existe algún problema de seguridad.
Identifican que la comunicación entre la aplicación osTicket y la instancia de base de datos MySQL no está
configurada para SSL. Hacen todo esto para garantizar que el tráfico de la base de datos no pueda piratearse.
Más información.
Copias de seguridad
Las aplicaciones web de osTicket no contienen datos de estado y, por tanto, no es necesario hacer copias de
seguridad.
El equipo de Contoso no tiene que configurar la copia de seguridad de la base de datos. Azure Database for
MySQL crea automáticamente copias de seguridad del servidor y las almacena. El equipo optó por utilizar la
redundancia geográfica para la base de datos para que sea resistente y esté lista para la producción. Las
copias de seguridad pueden utilizarse para restaurar el servidor a un momento dado. Más información.
No hay ningún problema relacionado con las licencias para la implementación de PaaS.
Contoso usará Azure Cost Management + Billing para asegurarse de que la compañía permanece dentro de
los presupuestos establecidos por la dirección de TI.
Recompilación de una aplicación local en Azure
En este artículo se muestra cómo la compañía ficticia Contoso recompila una aplicación de Windows .NET de
dos niveles que se ejecuta en máquinas virtuales de VMware como parte de una migración a Azure. Contoso
migra la máquina virtual de front-end a una aplicación web de Azure App Service. Contoso compila el back-end
de la aplicación mediante microservicios que se implementan en contenedores administrados por Azure
Kubernetes Service. El sitio interactúa con Azure Functions para ofrecer la funcionalidad de fotos de mascotas.
SmartHotel360, la aplicación que se usa en este ejemplo, se proporciona con una licencia de código abierto. Si

Abordar el crecimiento del negocio. Contoso está creciendo y quiere ofrecer experiencias diferenciadas
para los clientes en sitios web de Contoso.
Ser ágil. Contoso debe poder reaccionar con más rapidez que los cambios del mercado para facilitar el éxito
en una economía global.
Escala. A medida que el negocio crece satisfactoriamente, el equipo de TI de Contoso debe facilitar sistemas
que puedan crecer al mismo ritmo.
El equipo de la nube de Contoso ha establecido los requisitos de la aplicación para esta migración. Estos
requisitos se usaron para determinar el mejor método de migración:
La aplicación de Azure debe seguir siendo tan importante como lo es hoy en día en el entorno local. Debe
funcionar correctamente y escalarse fácilmente.
La aplicación no debe utilizar componentes de infraestructura como servicio (IaaS). Debe compilarse todo
para usar servicios de plataforma como servicio (PaaS) o sin servidor.
Las compilaciones de la aplicación deben ejecutarse en servicios en la nube y los contenedores deben residir
en un registro de nivel empresarial y privado en la nube.
El servicio de API que se usa para las fotos de mascotas debe ser preciso y fiable en el mundo real, ya que las
decisiones que toma la aplicación deben cumplirse en sus hoteles. Cualquier mascota con acceso autorizado
podrá permanecer en los hoteles.
Para cumplir los requisitos de una canalización de DevOps, Contoso usará un repositorio de Git en Azure
Repos para la administración de código fuente. Se usarán compilaciones y versiones automatizadas para
compilar el código e implementarlo en Azure App Service, Azure Functions y AKS.
Se requieren canalizaciones independientes de integración e implementación continuas (CI/CD) para los
microservicios en el back-end y para el sitio web en el front-end.
Los servicios de back-end tienen ciclos de lanzamiento diferentes a los de la aplicación web de front-end.
Para satisfacer este requisito, Contoso implementará dos canalizaciones distintas.
Contoso necesita la aprobación de administración en todas las implementaciones de sitio web de front-end y
la canalización de CI/CD debe facilitarlo.
Después de fijar sus objetivos y requisitos, Contoso diseña y revisa una solución de implementación e identifica
el proceso de migración, incluidos los servicios de Azure que usará para la migración.
Aplicación actual
La aplicación local de SmartHotel360 se divide en niveles entre dos VM ( WEBVM y SQLVM ).
máquina virtual.
contosodc1 ).
El front-end de la aplicación se implementa como una aplicación web de Azure App Service en la región
primaria de Azure.
Una función de Azure proporciona las cargas de las fotos de mascotas y el sitio interactúa con esta
funcionalidad.
La función de fotos de mascotas aprovecha Computer Vision API de Azure Cognitive Services junto con
Azure Cosmos DB.
El back-end del sitio se ha compilado mediante microservicios. Estos microservicios se implementarán en
contenedores que administra AKS.
Los contenedores se crearán con Azure DevOps y se insertarán en Azure Container Registry.
Por ahora, Contoso implementará manualmente el código de función y la aplicación web con
Visual Studio.
Contoso implementará los microservicios mediante un script de PowerShell que llama a las herramientas
de línea de comandos de Kubernetes.
Figura 1: Arquitectura del escenario.

Ventajas El uso de PaaS y soluciones sin servidor para una

implementación completa reduce significativamente el
tiempo de administración que Contoso debe proporcionar.
Cambiar a una arquitectura basada en microservicios

permite que Contoso amplíe fácilmente su solución con el
tiempo.
La nueva funcionalidad se puede poner en línea sin

interrumpir ninguna de las bases de código de las soluciones
existentes.
La aplicación web se configurará con varias instancias y sin

ningún único punto de error.
El escalado automático se habilitará para que la aplicación

pueda controlar volúmenes de tráfico diferentes.
Con el cambio a los servicios de PaaS, Contoso puede retirar

soluciones obsoletas que se ejecutan en el sistema operativo
Windows Server 2008 R2.
Azure Cosmos DB tiene tolerancia a errores integrada que

no requiere ninguna configuración por parte de Contoso.
Esto significa que la capa de datos ya no es un único punto
de conmutación por error.
Desventajas Los contenedores son más complejos que otras opciones de

migración. La curva de aprendizaje podría ser un problema
para Contoso. Contoso introduce un nuevo nivel de
complejidad que proporciona valor a pesar de la curva.
El equipo de operaciones de Contoso debe esforzarse en

comprender y ofrecer soporte técnico de Azure, los
contenedores y los microservicios de la aplicación.
Contoso no ha implementado completamente DevOps para

toda la solución. Tiene que pensar en ello para la
implementación de servicios en AKS, Azure Functions y
Azure App Service.
1. Contoso aprovisiona Azure Container Registry, AKS y Azure Cosmos DB.
2. Contoso aprovisiona la infraestructura para la implementación, incluida la aplicación web de Azure App
Service, la función, la cuenta de almacenamiento y la API.
3. Una vez instalada la infraestructura, Contoso compila las imágenes de contenedor de los microservicios
con Azure DevOps, que las inserta en el registro de contenedor.
4. Contoso implementa estos microservicios en AKS mediante un script de PowerShell.
5. Por último, Contoso implementa la función y la aplicación web.
Servicios de Azure
Azure Kubernetes Service Simplifica las operaciones, la AKS es un servicio gratuito. Solo debe
implementación y la administración de pagar por las máquinas virtuales y el
Kubernetes. Proporciona un servicio de almacenamiento y los recursos de red
orquestación de contenedores de asociados que use. Más información.
Kubernetes totalmente administrado.
Funciones de Azure Acelera el proceso de desarrollo con Solo debe pagar solo por los recursos
una experiencia de proceso sin consumidos. El plan se factura en
servidor controlada por eventos. función del consumo de recursos y las
Escalado a petición. ejecuciones por segundo. Más
información.
Azure Container Registry Almacena imágenes para todos los El costo se basa en características,
tipos de implementaciones de almacenamiento y duración de la
contenedor. utilización. Más información.
Azure App Service Compile, implemente y escale con Los planes de App Service se facturan
rapidez aplicaciones web, móviles y de por segundo. Más información.
API de naturaleza empresarial que se
puedan ejecutar en cualquier
plataforma.
Prerrequisitos
Esto es lo que Contoso requiere en este escenario:
Suscripción de Azure En un artículo anterior, Contoso creó suscripciones. Si no

tiene una suscripción a Azure, cree una cuenta gratuita.
Infraestructura de Azure Vea cómo Contoso configuró una infraestructura de

Azure.
Requisitos previos para desarrolladores Contoso necesita las siguientes herramientas en una
estación de trabajo de desarrollador:
Visual Studio Community 2017, versión 15.5
Carga de trabajo. NET habilitada
Git
Azure PowerShell
La CLI de Azure
Docker Community Edition (Windows 10) o Docker
Enterprise Edition (Windows Server) configurado para usar
contenedores de Windows
Pasos del escenario

Paso 1: Aprovisionamiento de AKS y Azure Container Registr y. Contoso aprovisiona el clúster de
AKS administrado y el registro de contenedor mediante PowerShell.
Paso 2: Compilar contenedores de Docker. Contoso configura la integración continua (CI) para
contenedores de Docker mediante Azure DevOps y los inserta en el registro de contenedor.
Paso 3: Implementar microser vicios de back-end. Contoso implementa el resto de la infraestructura
que aprovecharán los microservicios de back-end.
Paso 4: Implementar la infraestructura de front-end. Contoso implementa la infraestructura de front-
end, lo que incluye Blob Storage para los teléfonos de mascotas, Azure Cosmos DB y Computer Vision API.
Paso 5: Migrar el back-end. Contoso implementa los microservicios y los ejecuta en AKS para migrar el
back-end.
Paso 6: Publicar el front-end. Contoso publica la aplicación SmartHotel360 en Azure App Service junto
con la aplicación de funciones a la que llamará el servicio de mascotas.
Aprovisionar recursos de back-end

Contoso ejecuta un script de implementación para crear el clúster de Kubernetes administrado con AKS y Azure
Container Registry. Las instrucciones de esta sección usan el repositorio SmartHotel360-Backend de GitHub. El
repositorio contiene todo el software para esta parte de la implementación.
Comprobación de que se cumplen los requisitos previos
Antes de empezar, los administradores de Contoso se aseguran de que todo el software necesario está instalado
en la máquina de desarrollo que se utiliza para la implementación. Se clona el repositorio localmente en la
máquina de desarrollo mediante Git:
git clone https://github.com/Microsoft/SmartHotel360-Backend.git
Aprovisionamiento de AKS y Azure Container Registry.

Los administradores de Contoso aprovisionan AKS y Azure Container Registry como se indica a continuación:
1. En Visual Studio Code, abren la carpeta y se desplazan al directorio /deploy/k8s , que contiene el script
gen-aks-env.ps1 .
2. Ejecutan el script para crear el clúster de Kubernetes administrado con AKS y Azure Container Registry.
Figura 3: Creación de un clúster de Kubernetes
administrado.
3. Con el archivo abierto, actualizan el parámetro $location a eastus2 y guardan el archivo.
Ilustración 4: Guardado del archivo.

4. En Visual Studio Code, seleccionan Ver > Terminal integrado para abrir el terminal integrado de
Visual Studio Code.
Ilustración 5: Terminal de Visual Studio
Code.
5. En el terminal integrado de PowerShell, inician sesión en Azure mediante el comando
Connect-AzureRmAccount . Para más información, consulte el artículo de introducción a PowerShell.
Ilustración 6: Terminal integrado de

PowerShell.
6. Autentican la CLI de Azure mediante la ejecución del comando az login y siguen las instrucciones para
autenticarse con su explorador web. Obtenga más información acerca del inicio de sesión con la CLI de
Azure.
Ilustración 7: Autenticación de la CLI de Azure.
7. Ejecutan el siguiente comando pasando el nombre del grupo de recursos de ContosoRG , el nombre del
clúster de AKS smarthotel-aks-eus2 y el nuevo nombre del registro.
.\gen-aks-env.ps1 -resourceGroupName ContosoRg -orchestratorName smarthotelakseus2 -registryName
smarthotelacreus2
Ilustración 8: Ejecución del comando.

8. Azure crea otro grupo de recursos que contiene los recursos del clúster de AKS.
Ilustración 9: Creación de un grupo de recursos en Azure.
9. Una vez finalizada la implementación, instalan la herramienta de línea de comandos kubectl . La
herramienta ya está instalada en Azure Cloud Shell.
az aks install-cli
10. Ejecutan el comando kubectl get nodes para verificar la conexión al clúster. El nodo tiene el mismo
nombre que la máquina virtual en el grupo de recursos creado automáticamente.
Figura 10: comprobación de la conexión con el clúster.

11. Ejecutan el comando siguiente para iniciar el panel de Kubernetes:
az aks browse --resource-group ContosoRG --name smarthotelakseus2
12. Se abre una pestaña del explorador con el panel. Se trata de una conexión de túnel que usa la CLI de
Azure.
Figura 11: conexión de túnel.
Paso 2: Configurar la canalización de back-end

Crear un proyecto de Azure DevOps y compilarlo
Contoso crea un proyecto de Azure DevOps y configura una compilación de CI para crear el contenedor que,
luego, inserta en el registro de contenedor. Las instrucciones de esta sección usan el repositorio SmartHotel360-
Backend.
1. En visualstudio.com , crea una nueva organización ( contosodevops360.visualstudio.com ) y la configura
para usar Git.
2. Crea un proyecto ( SmartHotelBackend ) con Git como control de versiones y Agile como flujo de trabajo.
Ilustración 12: Creación de un proyecto nuevo.
3. Importan el repositorio de GitHub.
Figure 13: Importación del

repositorio de GitHub.
4. En Canalizaciones , selecciona Compilar y crea una canalización con el repositorio Git de Azure Repos
como origen en el repositorio.
Ilustración 14:
Creación de una nueva canalización.
5. Se selecciona Trabajo vacío .
Ilustración 15: Inicio a partir de un trabajo vacío.

6. Selecciona Hosted Linux Preview (Versión preliminar hospedada de Linux) como canalización de la
compilación.
Ilustración 16:
Configuración de la canalización de compilación.
7. En el paso 1 se agrega una tarea de Docker Compose . Esta tarea compila Docker Compose.
Ilustración 17: Compilación de Docker Compose.
8. Repiten la acción y agregan otra tarea de Docker Compose . Esta inserta los contenedores en el registro
de contenedor.
Ilustración 18: Adición de otra

tarea de Docker Compose.
9. Seleccionan la primera tarea que van a compilar y configuran la compilación con la suscripción a Azure,
la autorización y Container Registry.
Ilustración 19:
Generación y configuración de la compilación.
10. Especifica la ruta de acceso del archivo docker-compose.yaml en la carpeta src del repositorio. Se elige
compilar imágenes de servicio y se incluye la etiqueta más reciente. Cuando la acción cambia a Build
ser vice images (Compilar imágenes del servicio), el nombre de la tarea de Azure DevOps cambia a
Build ser vices automatically (Compilar servicios automáticamente).
Figura 20: detalles de la tarea.

11. Ahora, configura la segunda tarea de Docker (para insertar). Selecciona la suscripción y el registro de
contenedor ( smarthotelacreus2 ).
Figura 21:
configuración de la segunda tarea de Docker.
12. Se especifica el nombre de archivo en docker-compose.yaml y se selecciona Push ser vice images
(Insertar imágenes del servicio) incluyendo la última etiqueta. Cuando la acción cambia a Push ser vice
images (Insertar imágenes de servicio), el nombre de la tarea de Azure DevOps cambia a Push
ser vices automatically (Insertar servicios automáticamente).
Figura 22: cambio del nombre de la tarea de Azure DevOps.

13. Con las tareas de Azure DevOps configuradas, Contoso guarda la canalización de compilación e inicia el
proceso de compilación.
Figura 23: inicio del proceso de compilación.
14. Seleccionan el trabajo de compilación para comprobar el progreso.
Figura 24: comprobación del progreso.
15. Una vez finalizada la compilación, el registro de contenedor muestra los nuevos repositorios, que se
rellenan con los contenedores que usan los microservicios.
Figura 25: visualización de

repositorios nuevos una vez finalizada la compilación.
Implementar la infraestructura de back-end
Con el clúster de AKS creado y las imágenes de Docker compiladas, los administradores de Contoso
implementan ahora el resto de la infraestructura que usarán los microservicios de back-end.
Las instrucciones de esta sección usan el repositorio SmartHotel360-Backend.
En la carpeta /deploy/k8s/arm , hay un único script que permite crear todos los elementos.
Los administradores implementan la infraestructura de la siguiente manera:

1. Abren un símbolo del sistema para desarrolladores y, después, utilizan el comando az login con la
suscripción de Azure.
2. Usan el archivo deploy.cmd para implementar los recursos de Azure en el grupo de recursos ContosoRG
y la región East US 2 , escribiendo el comando siguiente:
.\deploy.cmd azuredeploy ContosoRG -c eastus2
Figura 26:
Implementación del back-end.
3. En Azure Portal, capturan la cadena de conexión de cada base de datos para usarla más adelante.
Figura 27:
Captura de la cadena de conexión de cada base de datos.
Crear la canalización de versión de back-end
Ahora, los administradores de Contoso hacen lo siguiente:
Implementan el controlador de entrada NGINX que permite el tráfico entrante a los servicios.
Implementan los microservicios en el clúster de AKS.
Como primer paso, los administradores actualizan las cadenas de conexión a los microservicios con Azure
DevOps. Luego configuran una nueva canalización de versión de Azure DevOps para implementar los
microservicios.
Las instrucciones de esta sección usan el repositorio SmartHotel360-Backend.
Algunas de las opciones de configuración (por ejemplo, Active Directory B2C) no se tratan en este artículo.
Para más información acerca de esta configuración, revise el repositorio SmartHotel360-Backend
mencionado anteriormente.
Los administradores crean la canalización:
1. En Visual Studio, actualizan el archivo /deploy/k8s/config_local.yml con la información de conexión de la
base de datos que apuntaron anteriormente.
2. Abren Azure DevOps y, en el proyecto SmartHotel360, seleccionan + Nueva canalización en el panel
Versiones .
Figura 29: Creación de una nueva canalización.

3. Seleccionan Fase vacía para iniciar la canalización sin una plantilla.
4. Especifican los nombres de fase y de canalización.
Figura 30: El nombre de la fase.
Figura 31: El nombre de la canalización.

5. Agregan un artefacto.
Figura 32: Adición de un artefacto.
6. Seleccionan Git como tipo de origen y especifican el proyecto, el origen y la rama principal de la
aplicación de SmartHotel360.
Figura 33: Panel de configuración del artefacto.

7. Seleccionan el vínculo de tarea.
Figura 34: El vínculo de tarea.

8. Agregan una nueva tarea de Azure PowerShell para poder ejecutar un script de PowerShell en un entorno
de Azure.
Figura 35: Adición de una nueva tarea de PowerShell.
9. Seleccionan la suscripción de Azure para la tarea y eligen el script deploy.ps1 en el repositorio de Git.
Figura 36: Ejecución del script.

10. Agregan los argumentos al script. El script elimina todo el contenido del clúster (excepto la entrada y el
controlador de entrada ) e implementa los microservicios.
Figura 37: incorporación de argumentos al script.

11. Establecen la versión de Azure PowerShell preferida en la más reciente y guardan la canalización.
12. Vuelven al panel Crear una versión nueva y crean manualmente una nueva versión.
Figura 38: creación manual de una nueva versión.
13. Después de crear la versión, la seleccionan y, en Acciones , seleccionan Implementar .
Figura 39: implementación de una versión.

14. Una vez completada la implementación, ejecutan el siguiente comando para comprobar el estado de los
servicios con Azure Cloud Shell: kubectl get services .
Paso 3: Aprovisionar servicios front-end
Los administradores de Contoso tienen que implementar la infraestructura que se usará en las aplicaciones de
front-end. Crean:
Un contenedor de Blob Storage para almacenar las imágenes de mascotas.
Una base de datos de Azure Cosmos DB para almacenar documentos que contienen la información de las
mascotas.
La instancia de Computer Vision API para el sitio web.
Las instrucciones de esta sección usan el repositorio SmartHotel360-website.
Creación de contenedores de Blob Storage
1. En Azure Portal, los administradores abren la cuenta de almacenamiento que se creó y seleccionan
Blobs .
2. Crean un nuevo contenedor denominado Pets con el nivel de acceso público establecido para el
contenedor. Los usuarios cargarán las fotos de sus mascotas en este contenedor.
Figura 40: Creación de un nuevo contenedor.

3. Crean un segundo contenedor nuevo denominado settings . Un archivo con la configuración de
aplicación de front-end se colocará en este contenedor.
Figura 41: Creación de un segundo contenedor.

4. Capturan los detalles de acceso de la cuenta de almacenamiento en un archivo de texto para futuras
referencias.
Figura
42: Un archivo de texto que captura los detalles de acceso.
Aprovisionamiento de una base de datos de Azure Cosmos DB
Los administradores de Contoso aprovisionan una base de datos de Azure Cosmos DB que se usará para la
información de las mascotas.
1. Crean una base de datos de Azure Cosmos DB en Azure Marketplace.
Figura 43: Creación

de una base de datos de Azure Cosmos DB.
2. Especifican un nombre contososmarthotel , seleccionan la API de SQL y la colocan en el grupo de recursos
de producción ContosoRG , en la región principal East US 2 .
Figura 44: Asignación de un nombre a
una base de datos de Azure Cosmos DB.
3. Agrega una nueva colección a la base de datos, con los valores de capacidad y rendimiento
predeterminados.
Figura 45:
Adición de una nueva colección a la base de datos.
4. Anotan la información de conexión de la base de datos para futuras referencias.
Figura 46: La información de la conexión para la base de datos.

Aprovisionamiento de Computer Vision API
Los administradores de Contoso aprovisionan la instancia de Computer Vision API. La función llamará a la API
para evaluar las imágenes cargadas por los usuarios.
1. Los administradores crean una instancia de Computer Vision en Azure Marketplace.
Figura 47: Una nueva instancia en Azure Marketplace.

2. Aprovisionan la API ( smarthotelpets ) en el grupo de recursos de producción ContosoRG , en la región
principal ( East US 2 ).
Figura 48: Aprovisionamiento de
una API en un grupo de recursos de producción.
3. Guarda la configuración de conexión para la API en un archivo de texto para consultarla más adelante.
Figura 49: guardado de

la configuración de conexión de la API.
Aprovisionar la aplicación web de Azure
Los administradores de Contoso aprovisionan la aplicación web con Azure Portal.
1. Selecciona Aplicación web en el portal.
Figura 50: Selección de la aplicación web.
2. Especifican un nombre de aplicación web ( smarthotelcontoso ), la ejecutan en Windows y la colocan en el
grupo de recursos de producción ContosoRG . Crean una instancia de Application Insights para la
supervisión de la aplicación.
Figura 51: El
nombre de la aplicación web.
3. Cuando terminan, los administradores van a la dirección de la aplicación para comprobar que se ha
creado correctamente.
4. En Azure Portal, crean un espacio de ensayo para el código. La canalización se implementará en este
espacio. Este enfoque garantiza que el código no se pondrá en producción hasta que los administradores
ejecuten una publicación.
Figura 52: Adición de un espacio de ensayo de la aplicación web.
Aprovisionamiento de la aplicación de funciones
En Azure Portal, los administradores de Contoso aprovisionan la aplicación de funciones.
1. Seleccionan Function App .
Figura 53:
Selección de la aplicación de funciones.
2. Proporcionan un nombre para la aplicación de funciones ( smarthotelpetchecker ). Colocan la aplicación
de funciones en el grupo de recursos de producción ( ContosoRG ). Establecen la ubicación de hospedaje
en Plan de consumo y colocan la aplicación de funciones en la región East US 2 . Se crea una cuenta de
almacenamiento, junto con una instancia de Application Insights para la supervisión.
Figura 54: Configuración de la
aplicación de funciones.
3. Una vez implementada la aplicación de funciones, los administradores van a su dirección para comprobar
que se ha creado correctamente.
Paso 4: Configurar la canalización de front-end

Los administradores de Contoso crean dos proyectos distintos en el sitio de front-end.
1. En Azure DevOps, crean un proyecto SmartHotelFrontend .
Figura 55:
Creación de un proyecto de front-end.
2. Importan el repositorio de Git del front-end de SmartHotel360 al nuevo proyecto.
3. Para la aplicación de funciones, crean otro proyecto de Azure DevOps ( SmartHotelPetChecker ) e importan
el repositorio de Git de PetChecker en este proyecto.
Configuración de la aplicación web
Ahora los administradores de Contoso configuran la aplicación web para usar los recursos de Contoso.
1. Los administradores se conectan al proyecto de Azure DevOps y clonan el repositorio localmente en la
máquina de desarrollo.
2. En Visual Studio, abre la carpeta para mostrar todos los archivos del repositorio.
Figura 56: Visualización de todos los archivos del repositorio.

3. Actualizan los cambios de configuración según sea necesario.
Cuando la aplicación web se inicia, busca la configuración de la aplicación SettingsUrl .
Esta variable debe contener una dirección URL que apunta a un archivo de configuración.
De forma predeterminada, esta opción de configuración se usa como un punto de conexión público.
4. Actualizan el archivo /config-sample.json/sample.json .
Este es el archivo de configuración para la web cuando se usa el punto de conexión público.
Editan las secciones urls y pets_config con los valores correspondientes a los puntos de conexión
de la API de AKS, las cuentas de almacenamiento y la base de datos de Azure Cosmos DB.
Las direcciones URL deben coincidir con el nombre DNS de la nueva aplicación web que Contoso va a
crear.
Para Contoso, se trata de smarthotelcontoso.eastus2.cloudapp.azure.com .
Figura 57: Configuración del archivo .json.

5. Una vez actualizado el archivo, los administradores le cambian el nombre a smarthotelsettingsurl y lo
cargan en la instancia de Blob Storage creada anteriormente.
Figura 58: Cambio de nombre y carga del archivo.

6. Seleccionan el archivo para obtener la dirección URL. La aplicación usa esta dirección URL cuando extrae
los archivos de configuración.
Figura 59: La dirección URL de la aplicación.
7. En el archivo appsettings.Production.json , actualizan SettingsURL con la dirección URL del nuevo
archivo.
Figura 60: Actualización de la dirección URL al nuevo archivo.

Implementación del sitio web en Azure App Service
Los administradores de Contoso ahora pueden publicar el sitio web.
1. Abren Azure DevOps y, en el proyecto SmartHotelFrontend , en Builds and Releases (Compilaciones y
versiones) y seleccionan + New Pipeline (+ Nueva canalización).
2. Seleccionan Git de Azure DevOps como origen.
3. Seleccionan la plantilla ASP.NET Core .
4. Revisan la canalización y se aseguran de que las opciones Publicar proyectos web y Comprimir
proyectos publicados están seleccionadas.
Figura 61: Configuración de la canalización.
5. En Desencadenadores , habilitan la integración continua y agregan la rama principal. Así se garantiza
que se inicia la canalización de compilación cada vez que la solución tiene código nuevo confirmado en la
rama principal.
Figura 62: Habilitación de la integración continua.

6. Seleccionan Guardar y poner en cola para iniciar una compilación.
7. Una vez finalizada la compilación, configuran una canalización de versión con Implementación de
Azure App Ser vice .
8. Especifican un nombre de fase, Almacenamiento provisional .
Figura 63: Asignación de un nombre al
entorno.
9. Agregan un artefacto y seleccionan la compilación que han configurado.
Figura 64: Adición de un artefacto.

10. Seleccionan el icono de rayo en el artefacto y establecen la implementación continua en Habilitada .
Figura 65: habilitación de la implementación continua.
11. En Entorno , seleccionan 1 job, 1 task (1 trabajo, 1 tarea) en Almacenamiento provisional .
12. Después de seleccionar la suscripción y el nombre de la aplicación web, los administradores abren la
tarea Implementar Azure App Ser vice . La implementación está configurada para usar la ranura de
implementación de ensayo . Así se genera automáticamente código para su revisión y aprobación en esta
ranura.
Figura 66: implementación en una ranura.
13. En Canalización , agregan una nueva fase.
Figura 67: adición de una nueva fase.
14. Seleccionan Implementación de Azure App Ser vice con espacio y asignan el nombre Prod al
entorno.
15. Seleccionan 1 job, 2 tasks (1 trabajo, 2 tareas) y, después, seleccionan la suscripción, el nombre del
servicio de App Service y el espacio de ensayo .
Figura 68: asignación de
nombre al entorno.
16. Quitan Deploy Azure App Ser vice to Slot (Implementar Azure App Service con espacio) de la
canalización. Se había colocado allí en los pasos anteriores.
Figura 69: eliminación de una ranura de la canalización.
17. Guardan la canalización. En la canalización, seleccionan Condiciones posteriores a la
implementación .
Figura 70: condiciones posteriores a la implementación.
18. Habilitan Aprobaciones posteriores a la implementación y agregan un responsable de desarrollo
como aprobador.
Figura 71: incorporación de un aprobador.

19. En la canalización de compilación, los administradores inician manualmente una compilación. Así se
desencadena la nueva canalización de versión, que implementa el sitio en el espacio de ensayo. En el caso
de Contoso, la dirección URL del espacio es https://smarthotelcontoso-staging.azurewebsites.net/ .
20. Una vez finalizada la compilación e implementada la versión en el espacio, Azure DevOps solicita la
aprobación por correo electrónico al responsable de desarrollo.
21. El responsable de desarrollo selecciona Ver aprobación en el portal de Azure DevOps, donde puede
aprobar o rechazar la solicitud.
Figura 72: solicitud de aprobación de versión pendiente.

22. El responsable de desarrollo realiza un comentario y aprueba. Así se inicia el intercambio entre los
espacios de ensayo y de producción , y se traslada la compilación a producción.
Figura 73: paso de la compilación a producción.
23. La canalización finaliza el intercambio.
Figura 74: finalización del intercambio.

24. El equipo comprueba el espacio de producción en https://smarthotelcontoso.azurewebsites.net/ para
asegurarse de que la aplicación web se encuentra en producción.
Implementación de la aplicación de funciones PetChecker
Los administradores de Contoso implementan la aplicación de la manera siguiente:
1. Se conectan al proyecto de Azure DevOps y clonan el repositorio localmente en la máquina de desarrollo.
2. En Visual Studio, abren la carpeta para mostrar todos los archivos del repositorio.
3. Abren el archivo src/PetCheckerFunction/local.settings.json y agregan la configuración de
almacenamiento de la aplicación, la base de datos de Azure Cosmos DB y Computer Vision API.
Figura 75: Implementación de la función.

4. Confirman el código y lo sincronizan con Azure DevOps, lo que inserta los cambios.
5. Agregan una nueva canalización de compilación y, después, seleccionan Git de Azure DevOps como
origen.
6. Seleccionan la plantilla ASP.NET Core (.NET Framework) .
7. Aceptan los valores predeterminados de la plantilla.
8. En Desencadenadores , seleccionan Habilitar la integración continua y luego seleccionan Guardar
y poner en cola para iniciar una compilación.
9. Una vez iniciada la compilación, compilan una canalización de versión, lo que agrega Implementación
de Azure App Ser vice con espacio .
10. Asignan el nombre Producción al entorno y, a continuación, seleccionan la suscripción. Establecen el
Tipo de aplicación en Function App y el nombre del servicio como smarthotelpetchecker .
Figura 76: aplicación de funciones.

11. Agregan un artefacto de compilación .
Figura 77: incorporación de un artefacto.
12. Habilitan la opción Desencadenador de implementación continua y, a continuación, seleccionan
Guardar .
13. Seleccionan Poner nueva compilación en cola para ejecutar la canalización de CI/CD completa.
14. Una vez implementada la función, aparece en Azure Portal, con el estado En ejecución .
Figura 78: actualización del estado de la función.
15. Navegan a la aplicación Pet Checker en http://smarthotel360public.azurewebsites.net/pets para
comprobar que funciona correctamente.
16. Seleccionan el avatar para cargar una imagen.
Figura 79: asignación de una

imagen a un avatar.
17. La primera foto que quiere comprobar es la de un perro pequeño.
Figura 80: comprobación de la foto.
18. La aplicación devuelve un mensaje de aceptación.
Figura 81: mensaje de aceptación.
Con los recursos migrados de Azure, Contoso debe ahora poner completamente en marcha la nueva
infraestructura y protegerla.
Seguridad
Contoso tiene que asegurarse de que sus nuevas bases de datos son seguras. Para más información, consulte
Información general sobre las capacidades de seguridad de Azure SQL Database e Instancia administrada de
SQL.
La aplicación debe actualizarse para usar SSL con certificados. La instancia del contenedor debe
reimplementarse para responder en 443.
Contoso debería plantearse el uso de Azure Key Vault para proteger los secretos de las aplicaciones de
Service Fabric. Para más información, consulte Administración de secretos cifrados en aplicaciones de
Service Fabric.
Copia de seguridad y recuperación ante desastres
Contoso necesita revisar los requisitos de copia de seguridad de Azure SQL Database.
Contoso debería plantearse la implementación de grupos de conmutación por error de SQL para
proporcionar conmutación por error regional a la base de datos.
Contoso puede usar la replicación geográfica para la SKU Premium de Azure Container Registry.
La copia de seguridad de Azure Cosmos DB se realiza automáticamente. Para más información, consulte
Copias de seguridad automáticas en línea y restauración de datos a petición con Azure Cosmos DB.
Una vez implementados todos los recursos, Contoso debe asignar etiquetas de Azure según la planificación
de su infraestructura.
Todas las licencias se integran en el costo de los servicios de PaaS que consume Contoso. Esto se deducirá
del contrato Enterprise.
Azure.
Conclusión
En este artículo, Contoso recompila la aplicación SmartHotel360 en Azure. Se recompila la máquina virtual de
front-end de la aplicación local para las aplicaciones web de Azure App Service. El back-end de la aplicación se
compila con microservicios que se implementan en contenedores administrados por AKS. Contoso mejora la
funcionalidad con una aplicación de fotos de mascotas.
Aptitudes sugeridas
más gratificante para el aprendizaje práctico que le ayuda a lograr sus objetivos con más rapidez. Con Microsoft
Learn, puede ganar puntos, aumentar de nivel y mucho más.
A continuación se muestran dos ejemplos de rutas de aprendizaje adaptadas en Microsoft Learn que se alinean
con la aplicación SmartHotel360 de Contoso en Azure.
Implementación de un sitio web en Azure con Azure App Ser vice : Mediante la creación de
aplicaciones web en Azure, puede publicar y administrar el sitio web fácilmente sin tener que trabajar con
los servidores, almacenamiento o recursos de red subyacentes. En su lugar, puede centrarse en las
características del sitio web y confiar en la sólida plataforma de Azure para proporcionar un acceso
seguro al sitio.
Procese y clasifique las imágenes con los ser vicios de visión cognitiva de Azure : Azure
Cognitive Services ofrece una funcionalidad pregenerada para habilitar la funcionalidad de Computer
Vision en las aplicaciones. Aprenda a usar los servicios de visión cognitiva de Azure para detectar caras,
etiquetar y clasificar imágenes e identificar objetos.
Refactorizar una implementación de Team
Foundation Server a Azure DevOps Services
En este artículo se muestra cómo la empresa ficticia Contoso refactoriza su implementación local de Team
Foundation Server de Visual Studio mediante la migración a Azure DevOps Services en Azure. El equipo de
desarrollo de Contoso ha utilizado Team Foundation Server para la colaboración en equipo y el control de
código fuente durante los últimos cinco años. Ahora, quieren pasar a una solución basada en la nube para el
trabajo de desarrollo y pruebas, y para el control de código fuente. Azure DevOps Services jugarán un papel
importante cuando el equipo de Contoso pase a un modelo de Azure DevOps y desarrolle nuevas aplicaciones
nativas de la nube.

El equipo de dirección de TI de Contoso ha trabajado estrechamente con asociados comerciales para identificar
los objetivos futuros. Los asociados no están demasiado preocupados por las tecnologías ni las herramientas de
desarrollo, pero el equipo ha recogido estos puntos:
Software: Sin tener en cuenta el negocio principal, todas las compañías ahora son compañías de software,
incluida Contoso. El equipo de dirección empresarial está interesado en saber cómo el departamento de TI
puede ayudar a dirigir la empresa con nuevas prácticas de trabajo para los usuarios y nuevas experiencias
para sus clientes.
Eficacia: Contoso debe eliminar los procedimientos innecesarios y optimizar los procesos para los
desarrolladores y los usuarios. Esto permitirá a la empresa cumplir los requisitos de los clientes de manera
más eficaz. La empresa necesita que el departamento de TI sea rápido, sin perder tiempo ni dinero.
Agilidad: Para ayudar a lograr el éxito en una economía global, el departamento de TI de Contoso debe ser
más receptivo a las necesidades de la empresa y ser capaz de reaccionar con más rapidez a los cambios en el
mercado. No se debe interponer en el camino ni bloquear el negocio.
El equipo de la nube de Contoso ha establecido los siguientes objetivos para la migración a Azure DevOps
Services:
El equipo necesita una herramienta para migrar sus datos a la nube. Es posible que sean necesarios algunos
procesos manuales.
El historial y los datos de elementos de trabajo del año pasado deberán migrarse.
El equipo no quiere configurar nuevos nombres de usuario y contraseñas. Se deben mantener todas las
asignaciones del sistema actual.
El equipo quiere pasar del Control de versiones de Team Foundation (TFVC) a GIT para el control de código
fuente.
La transición a Git será una migración sugerida que importa solo la versión más reciente del código fuente.
Se realizará aprovechando el tiempo de inactividad; se detendrá todo el trabajo mientras se desplace el
código base. El equipo entiende que después del paso solo estará disponible el historial de la rama principal
actual.
El equipo está preocupado por el cambio y quiere probarlo antes de llevarlo a cabo. Quieren conservar el
acceso a Team Foundation Server incluso después de la migración a Azure DevOps Services.
El equipo tiene varias colecciones y, para comprender mejor el proceso, quiere empezar por una que tenga
pocos proyectos.
El equipo entiende que las colecciones de Team Foundation Server tienen una relación uno a uno con las
organizaciones de Azure DevOps Services, por lo que habrá varias direcciones URL. Esto, sin embargo, ya
coincide con su modelo actual de separación de bases de código y proyectos.
Contoso moverá sus proyectos de Team Foundation Server a la nube; dejará de hospedar los proyectos y el
control de código fuente localmente.
Team Foundation Server se migrará a Azure DevOps Services.
Actualmente, Contoso tiene una colección de Team Foundation Server, denominada ContosoDev , que se
migrará a una organización de Azure DevOps Services denominada contosodevmigration.visualstudio.com .
Los proyectos, los elementos de trabajo, los errores y las iteraciones del último año se migrarán a Azure
DevOps Services.
Contoso usará su instancia de Azure Active Directory (Azure AD), que configuró al implementar su
infraestructura de Azure al principio del planeamiento de la migración.
1. Se requiere una preparación significativa. En primer lugar, Contoso debe actualizar su implementación de
Team Foundation Server a un nivel compatible. Contoso ejecuta actualmente Team Foundation Server 2017
Update 3, pero para usar la migración de base de datos es necesario ejecutar una versión de 2018
compatible que tenga las actualizaciones más recientes.
2. Después de que Contoso lleve a cabo la actualización, ejecutará la herramienta de migración de Team
Foundation Server y validará su colección.
3. Contoso compilará un conjunto de archivos de preparación y, a continuación, realizará un simulacro de
migración de prueba.
4. Después, Contoso ejecutará otra migración, esta vez una migración completa, que incluye elementos de
trabajo, errores, sprints y código.
5. Tras la migración, Contoso moverá su código de TFVC a Git.
Requisitos previos

cuenta gratuita.



Infraestructura de Azure Contoso configura su infraestructura de Azure según se

Instancia de Team Foundation Ser ver local La instancia local debe ejecutar Team Foundation
Server 2018 Update 2 o actualizarse a ella como parte de
este proceso.
Pasos del escenario

Así es como Azure realizará la migración:
Paso 1: Creación de una cuenta de Azure Storage . Esta cuenta de almacenamiento se usará durante el
proceso de migración.
Paso 2: Actualización de Team Foundation Ser ver . Contoso actualizará su implementación a Team
Foundation Server 2018 Update 2.
Paso 3: Validación de la colección de Team Foundation Ser ver . Contoso validará la colección de Team
Foundation Server como preparación para la migración.
Paso 4: Creación de los archivos de migración . Contoso creará los archivos de migración mediante la
herramienta de migración de Team Foundation Server.
Paso 1: Creación de una cuenta de Azure Storage

1. En Azure Portal, los administradores de Contoso crean una cuenta de almacenamiento (
contosodevmigration ).
2. La cuenta se incluirá en la región secundaria, que se usa para la conmutación por error ( Central US ). Se
usa una cuenta de uso general estándar con almacenamiento con redundancia local.

Introducción a Azure Storage.
Crear una cuenta de almacenamiento.
Paso 2: Actualización de Team Foundation Server

Los administradores de Contoso actualizan la instancia de Team Foundation Server a Team Foundation
Server 2018 Update 2. Antes de empezar, llevan a cabo lo siguiente:
Descargan Team Foundation Server 2018 Update 2.
Comprueban los requisitos de hardware.
Leen las notas de la versión y las sugerencias de actualización.
Realiza la actualización como se muestra a continuación:
1. Para empezar, los administradores realizan una copia de seguridad de su instancia de Team Foundation
Server, que se ejecuta en una máquina virtual de VMware, y toman una instantánea de VMware.
2. El instalador de Team Foundation Server se inicia y eligen la ubicación de instalación. El instalador
necesita acceso a Internet.
3. Una vez finalizada la instalación, se inicia el Asistente para configuración de servidor.

4. Después de la verificación, el Asistente para configuración del servidor completa la actualización.
5. Los administradores comprueban la instalación de Team Foundation Server revisando los proyectos, los
elementos de trabajo y el código.
NOTE
En algunas actualizaciones de Team Foundation Server es necesario ejecutar el Asistente para configurar características
una vez finalizada la actualización. Más información.

Obtenga información sobre la actualización de Team Foundation Server.
Paso 3: Validación de la colección de Team Foundation Server

Los administradores de Contoso ejecutan la herramienta de migración de Team Foundation Server en la base de
datos de la colección contosodev para validarla antes de la migración.
1. Descargan y descomprimen la herramienta de migración de Team Foundation Server. Es importante
descargar la versión correspondiente a la actualización de Team Foundation Server que se está
ejecutando. La versión puede comprobarse en la consola de administración.
2. Ejecutan la herramienta para llevar a cabo la validación especificando la dirección URL de la colección de
proyectos, tal como se muestra en el siguiente comando:
TfsMigrator validate /collection:http://contosotfs:8080/tfs/ContosoDev
La herramienta muestra un error.
3. Localizan los archivos de registro en la carpeta Logs , justo antes de la ubicación de la herramienta. Se
genera un archivo de registro para cada validación principal. TfsMigration.log contiene la información
principal.
4. Encuentran esta entrada, que está relacionada con la identidad.
5. Ejecutan TfsMigrator validate /help en la línea de comandos y observan que el comando

/tenantDomainName parece ser necesario para validar las identidades.
6. Vuelven a ejecutar el comando de validación e incluyen este valor, junto con su nombre de Azure AD,
TfsMigrator validate /collection:http://contosotfs:8080/tfs/ContosoDev
/tenantDomainName:contosomigration.onmicrosoft.com
.
7. En la ventana de inicio de sesión de Azure AD que aparece, especifican las credenciales de un usuario
administrador global.
8. La validación se pasa y la herramienta la confirma.
Paso 4: Creación de los archivos de migración

Con la validación completa, los administradores de Contoso pueden usar la herramienta de migración de Team
Foundation Server para compilar los archivos de migración.
1. Ejecutan el paso de preparación en la herramienta.
TfsMigrator prepare /collection:http://contosotfs:8080/tfs/ContosoDev
/tenantDomainName:contosomigration.onmicrosoft.com /accountRegion:cus
En el paso de preparación se hace lo siguiente:

Se examina la colección para obtener una lista de todos los usuarios y se rellena el registro de
asignación de identidades ( IdentityMapLog.csv ).
Se prepara la conexión a Azure AD para buscar una coincidencia para cada identidad.
Contoso ya ha implementado Azure AD y lo ha sincronizado mediante Azure AD Connect, por lo que
el comando de preparación debería poder buscar las identidades coincidentes y marcarlas como
activas .
2. Aparece la pantalla de inicio de sesión de Azure AD y los administradores escriben las credenciales de un
administrador global.
3. La preparación se completa, y la herramienta notifica que se han generado correctamente los archivos de
importación.
4. Ahora los administradores pueden ver los archivos IdentityMapLog.csv e import.json , que se han
creado en una carpeta nueva.
5. El archivo import.json proporciona opciones de importación. Incluye información como el nombre de
organización deseado y detalles de la cuenta de almacenamiento. La mayoría de los campos se rellenan
automáticamente. Algunos campos requieren la intervención del usuario. Los administradores abren el
archivo y agregan el nombre de la organización de Azure DevOps Services que se va a crear,
contosodevmigration . Con este nombre, la dirección URL de Azure DevOps Services de Contoso será
contosodevmigration.visualstudio.com .
NOTE
La organización debe crearse antes de comenzar la migración, pero se puede cambiar una vez completada.
6. Los administradores revisan el archivo de registro de asignación de identidades, en el que se muestran

las cuentas que se van a incluir en Azure DevOps Services durante la importación.
Las identidades activas hacen referencia a las identidades que se convertirán en usuarios de Azure
DevOps Services después de la importación.
En Azure DevOps Services, se concederá una licencia a estas identidades y aparecerán como usuarios
de la organización después de la migración.
Estas identidades se marcan como Active (Activas) en la columna Expected Impor t Status (Estado
de importación esperado) del archivo.
Paso 5: Migrar a Azure DevOps Services
Una vez completada la preparación, los administradores de Contoso pueden centrarse en la migración. Después
de ejecutar la migración, pasarán de usar TFVC a usar Git para el control de versiones.
Antes de empezar, los administradores programan el tiempo de inactividad con el equipo de desarrollo, para
planear la desconexión de la colección durante la migración.
Este es el proceso de migración que seguirán:
1. Desasociar la colección. los datos de identidad de la colección residen en la base de datos de
configuración de la instancia de Team Foundation Server, en tanto que la colección está adjunta y en línea.
Cuando se desasocia una colección de la instancia de Team Foundation Server, se realiza una copia de los
datos de identidad que se empaqueta con la colección para el transporte. Sin estos datos, no se puede
ejecutar la parte de la identidad de la importación.
Se recomienda que la colección permanezca desasociada hasta que se complete la importación, ya que
no hay ninguna manera de importar los cambios que se produzcan durante este proceso.
2. Generar una copia de seguridad. el siguiente paso consiste en generar una copia de seguridad que se
pueda importar en Azure DevOps Services. El paquete de componentes de aplicación de capa de datos
(DACPAC) es una característica de SQL Server que permite que los cambios de la base de datos se
empaqueten en un único archivo y después se implementen en otras instancias de SQL.
La copia de seguridad también se puede restaurar directamente en Azure DevOps Services y usar como
método de empaquetado para introducir los datos de la colección en la nube. Contoso usará la
herramienta sqlpackage.exe para generar el archivo DACPAC. Esta herramienta se incluye en SQL Server
Data Tools.
3. Cargar en el almacenamiento. tras crear el archivo DACPAC, los administradores lo cargan en Azure
Storage. Una vez cargado, obtienen una firma de acceso compartido (SAS), para permitir que la
herramienta de migración de Team Foundation Server acceda al almacenamiento.
4. Rellenar la impor tación. a continuación, Contoso puede rellenar los campos que faltan en el archivo
de importación, incluida la configuración de DACPAC. Para comprobar que todo funciona correctamente
antes de la migración completa, los administradores especificarán que quieren realizar un simulacro de
importación.
5. Realice un simulacro de impor tación. este simulacro les ayuda a probar la migración de la colección.
Los simulacros tienen una vida limitada y se eliminan antes de que se ejecute la migración de producción.
Se eliminan automáticamente tras un período determinado. En el correo electrónico de operación
correcta que se envía cuando finaliza la importación, se incluye una nota que informa a Contoso acerca
de cuándo se eliminará el simulacro. El equipo toma nota y planea en consecuencia.
6. Completar la migración de producción. una vez completado el simulacro de migración, los
administradores de Contoso realizan la migración final, para lo cual actualizan el archivo import.json y,
después, vuelven a ejecutar la importación.
Desasociar la colección
Antes de desasociar la colección, los administradores de Contoso realizan una copia de seguridad de la instancia
local de SQL Server y una instantánea de VMware de la instancia de Team Foundation Server.
1. En el consola de administración de Team Foundation Server, los administradores seleccionan la colección
que desean desasociar, ContosoDev .
2. Seleccionan la pestaña General y, después, seleccionan Desasociar colección .
3. En el asistente Desasociar colección de proyectos de equipo , en el panel Mensaje de

mantenimiento , los administradores incluyen un mensaje para los usuarios que puede que intenten
conectarse a proyectos de la colección.
4. En el panel Progreso de desasociación , supervisan el progreso. Cuando finaliza el proceso,

seleccionan Siguiente .
5. En el panel Comprobaciones de disponibilidad , cuando finalicen las comprobaciones, seleccionan
Desasociar .
6. Cuando la colección se ha desasociado correctamente, seleccionan Cerrar para finalizar.

En la consola de administración de Team Foundation Server ya no se hace referencia a la colección.
Generar un archivo DACPAC

Los administradores de Contoso crean una copia de seguridad, o DACPAC, para importar en Azure DevOps
Services.
Los administradores emplean la utilidad sqlpackage.exe de SQL Server Data Tools (SSDT) para crear el
archivo DACPAC. Hay varias versiones de sqlpackage.exe que se instalan con SQL Server Data Tools,
ubicadas en carpetas con nombres como 120 , 130 y 140 . Es importante usar la versión correcta para
preparar el archivo DACPAC.
Las importaciones de Team Foundation Server 2018 deben usar el archivo sqlpackage.exe de la
carpeta 140 o superior. En el caso de CONTOSOTFS , este archivo se encuentra en
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\140
.
Los administradores de Contoso generan el archivo DACPAC como se indica a continuación:
1. Abren un símbolo del sistema y van a la ubicación de sqlpackage.exe . Para generar el archivo DACPAC,
ejecutan el siguiente comando:
SqlPackage.exe /sourceconnectionstring:"Data Source=SQLSERVERNAME\INSTANCENAME;Initial
Catalog=Tfs_ContosoDev;Integrated Security=True" /targetFile:C:\TFSMigrator\Tfs_ContosoDev.dacpac
/action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true
/p:Storage=Memory
Se muestra el mensaje siguiente:
2. Verifica las propiedades del archivo DACPAC.
Carga del archivo en Azure Storage

Una vez que los administradores crean el archivo DACPAC, lo cargan en la cuenta de Azure Storage.
1. Descarga e instala el Explorador de Azure Storage.
2. En el Explorador de Storage, los administradores se conectan a su suscripción y, a continuación, buscan y

seleccionan la cuenta de almacenamiento que crearon para la migración ( contosodevmigration ). Crean un
contenedor de blobs, azuredevopsmigration .
3. En el panel Cargar archivos , en la lista desplegable Tipo de blob , los administradores especifican la
opción Blob en bloques para cargar el archivo DACPAC.
4. Después de cargar el archivo, seleccionan el nombre de archivo y, a continuación, seleccionan Generar

SAS . Expanden la lista Contenedores de blobs en la cuenta de almacenamiento, seleccionan el
contenedor con los archivos de importación y, a continuación, seleccionan Obtener firma de acceso
compar tido .
5. En el panel Firma de acceso compar tido , aceptan la configuración predeterminada y, a continuación,
seleccionan Crear . Esto permite el acceso durante 24 horas.
6. Copian la URL de la firma de acceso compartido, para que la pueda usar la herramienta de migración de
Team Foundation Server.
NOTE
La migración debe realizarse antes de que transcurra el tiempo permitido o los permisos expirarán. No genere ninguna
clave SAS desde Azure Portal. Las claves que se generan desde el portal son para el ámbito de cuenta y no funcionan con
la importación.
Rellenar la configuración de importación

Antes, los administradores de Contoso rellenaron de forma parcial el archivo de especificación de importación,
import.json . Ahora, debe agregar el resto de configuraciones.
Abren el archivo import.json y rellenan los campos siguientes:

Ubicación: especifican la ubicación de la clave SAS que se generó anteriormente.
DACPAC: especifican el nombre del archivo DACPAC que cargaron anteriormente en la cuenta de
almacenamiento, asegurándose de incluir la extensión .dacpac.
Impor tType: por ahora, escriben Dr yRun .
Realización de un simulacro de importación
Los administradores de Contoso realizan un simulacro de migración para asegurarse de que todo funciona de la
forma esperada.
1. Abren un símbolo del sistema y van a la ubicación de TfsMigrator ( C:\TFSMigrator ).
2. Quieren asegurarse de que el archivo tiene el formato correcto y de que la clave SAS está funcionando.
Validan el archivo de importación ejecutando el siguiente comando:
TfsMigrator import /importFile:C:\TFSMigrator\import.json /validateonly
La validación devuelve un error que indica que la clave SAS necesita un tiempo más largo antes de
expirar.
3. Usan el Explorador de Azure Storage para crear una nueva clave SAS en la que establecen el período
antes de la expiración en siete días.
4. Actualizan el archivo import.json y vuelven a ejecutar el comando. Esta vez, la validación finaliza
correctamente.
TfsMigrator import /importFile:C:\TFSMigrator\import.json /validateonly
5. Inician el simulacro ejecutando el siguiente comando:

TfsMigrator import /importFile:C:\TFSMigrator\import.json
Aparece un mensaje que les pide que confirmen que desean continuar con la migración. Es necesario
tener en cuenta el período de siete días después del simulacro durante el cual se mantendrán los datos
almacenados provisionalmente.
6. Se abre la ventana de inicio de sesión de Azure AD. Los administradores de Contoso inician sesión en
Azure AD con permisos de administrador.
Se muestra un mensaje que confirma que la importación se ha iniciado correctamente.
7. Después de unos 15 minutos, los administradores van al sitio web y ven la siguiente información:
8. Después de que finalice la migración, un director de desarrollo de Contoso inicia sesión en Azure DevOps
Services para asegurarse de que el simulacro ha funcionado correctamente. Después de la autenticación,
Azure DevOps Services necesita algunos detalles para confirmar la organización.
El director de desarrollo puede ver que los proyectos se migraron correctamente. Un aviso cerca de la
parte superior de la página advierte de que la cuenta de simulacro se eliminará en 15 días.
9. El director de desarrollo abre uno de los proyectos y, después, selecciona Elementos de trabajo >
Asignados a mí . En esta página se comprueba que los datos del elemento de trabajo se han migrado
correctamente, junto con la identidad.
10. Para confirmar que se han migrado el código fuente y el historial, el director de desarrollo también
comprueba otros proyectos y código.
Ejecutar la migración de producción

Una vez que se ha completado el simulacro, los administradores de Contoso pasan a la migración de
producción. Eliminan el simulacro, actualizan la configuración de importación y vuelven a ejecutar la
importación.
1. En el portal de Azure DevOps Services, eliminan la organización del simulacro.
2. Actualizan el archivo import.json para establecer Impor tType en ProductionRun .
3. Como hicieron en el simulacro, inician la migración mediante la ejecución del siguiente comando:
TfsMigrator import /importFile:C:\TFSMigrator\import.json .
Aparece un mensaje que pide a los administradores que confirmen la migración, donde se advierte que
es posible que los datos se queden almacenados en una ubicación segura como área de almacenamiento
provisional durante un máximo de siete días.
4. En la ventana de inicio de sesión de Azure AD, especifican un inicio de sesión de administrador de

Contoso.
Se muestra un mensaje que indica que la importación se ha iniciado correctamente.
5. Después de unos 15 minutos, los administradores van al sitio web y ven la siguiente información:
6. Cuando finaliza la migración, un director de desarrollo inicia sesión en Azure DevOps Services para
comprobar que la migración ha funcionado correctamente. Después del inicio de sesión, el director de
desarrollo ve que los proyectos se han migrado.
7. El director de desarrollo abre uno de los proyectos y selecciona Elementos de trabajo > Asignados a
mí . Esto muestra que se han migrado los datos de los elementos de trabajo, junto con la identidad.
8. El director de desarrollo realiza comprobaciones para confirmar que se han migrado otros datos de
elementos de trabajo.
9. Para confirmar que se han migrado el código fuente y el historial, el director de desarrollo también
comprueba otros proyectos y código.
Traslado del control de código fuente de TFVC a Git
Una vez completada la migración, los administradores de Contoso quieren trasladar la administración del
código fuente de TFVC a Git. Deben importar el código fuente que se encuentra actualmente en su organización
de Azure DevOps Services como repositorios de Git de la misma organización.
1. En el portal de Azure DevOps Services, abren uno de los repositorios de TFVC ( $/PolicyConnect ) y lo
revisan.
2. En la lista desplegable de $/PolicyConnect de origen, seleccionan Impor tar repositorio .

3. En la lista desplegable Tipo de origen , seleccionan TFVC . En el cuadro Ruta de acceso , especifican la
ruta de acceso al repositorio y, a continuación, seleccionan Impor tar . Deciden dejar desactivada la casilla
Migrar historial .
NOTE
Dado que TFVC y Git almacenan la información de control de versiones de forma diferente, se recomienda que
Contoso no migre el historial del repositorio. Este es el enfoque que se adoptó en Microsoft al migrar tanto
Windows como otros productos desde el control de versiones centralizado a Git.
4. Una vez finalizada la importación, los administradores revisan el código.
5. Repiten el proceso para el segundo repositorio, $/smarthotelcontainer .
6. Después de que el director de desarrollo revise el código fuente, se acepta que la migración a Azure
DevOps Services ha finalizado. Ahora Azure DevOps Services se convierte en el origen de todo el
desarrollo para los equipos implicados en la migración.
Para obtener más información, consulte Importación de repositorios de TFVC a Git.

Una vez finalizada la migración, el equipo de Contoso debe hacer lo siguiente:
Deberá revisar el artículo posterior a la importación para obtener información acerca de las actividades de
importación adicionales.
También deberá eliminar los repositorios TFVC, o establecerlos en modo de solo lectura. Las bases de código
no deben usarse, pero se puede hacer referencia a su historial.
Entrenamiento posterior a la migración

Contoso tendrá que ofrecer aprendizaje sobre Azure DevOps Services y Git a los miembros del equipo
pertinentes.
Traslado de la infraestructura de VMware local a
Azure
Cuando la empresa ficticia Contoso migra sus máquinas virtuales de VMware desde un centro de datos local a
Azure, hay dos opciones disponibles para el equipo. Este artículo se centra en Azure VMware Solution, la mejor
opción de migración para Contoso.

Ejecución de cargas de trabajo mediante la infraestructura
como servicio (IaaS) de Azure.
Administración de VM con Azure Resource Manager.
Azure VMware Solution Uso de Hybrid Cloud Extension de VMware o vMotion

para trasladar máquinas virtuales locales.
Ejecución de cargas de trabajo de VMware nativas en
hardware sin sistema operativo de Azure.
Administración de VM mediante vSphere.
En este artículo, Contoso utiliza Azure VMware Solution para crear una nube privada en Azure con acceso nativo
a VMware vCenter y otras herramientas compatibles con VMware para la migración de cargas de trabajo.
Contoso puede usar con confianza Azure VMware Solution, sabiendo que son ofertas originales de Microsoft
respaldadas por VMware.

Mediante una estrecha colaboración con los partners comerciales, el equipo de TI de Contoso definirá las
motivaciones empresariales para una migración de VMware a Azure. Entre estas motivaciones se pueden incluir:
Evacuación o apagado del centro de datos: Traslade sin problemas las cargas de trabajo basadas en
VMware cuando consolide o retire los centros de datos existentes.
Recuperación ante desastres y continuidad empresarial: Use una pila de VMware implementada en
Azure como sitio primario o secundario de recuperación ante desastres a petición para la infraestructura de
centros de datos locales.
Modernización de aplicaciones: aproveche el ecosistema de Azure para modernizar las aplicaciones de
Contoso sin tener que reconstruir los entornos basados en VMware.
Implementación de DevOps: incorpore las cadenas de herramientas de Azure DevOps a los entornos de
VMware y modernice las aplicaciones al propio ritmo de estas.
Garantía de continuidad operativa: Vuelva a implementar en Azure aplicaciones basadas en vSphere, a la
vez que evita las conversiones de hipervisor y la refactorización de aplicaciones. Amplíe la compatibilidad
con aplicaciones heredadas que ejecutan Windows y SQL Server.
Objetivos de la migración de VMware local a VMware en la nube

Teniendo en cuenta las motivaciones empresariales, Contoso ha establecido varios objetivos para esta
migración:
Seguir administrando sus entornos existentes con las herramientas de VMware más conocidas para sus
equipos, a la vez que moderniza las aplicaciones con servicios nativos de Azure.
Trasladar sin problemas las cargas de trabajo basadas en VMware de Contoso desde su centro de datos a
Azure e integrar el entorno de VMware con Azure.
que tiene actualmente en VMware. La aplicación sigue siendo tan imprescindible en la nube como lo es en el
entorno local.
Estos objetivos respaldan la decisión de Contoso de usar Azure VMware Solution y hacen que considere a esta
solución como el mejor método de migración.
Ventajas de ejecutar cargas de trabajo de VMware en Azure

Con Azure VMware Solution, Contoso ahora puede ejecutar, administrar y proteger aplicaciones sin problemas
en entornos de VMware y en Azure con un marco operativo común.
Contoso podrá aprovechar las inversiones, aptitudes y herramientas existentes de VMware, incluido VMware
vSphere, vSAN y vCenter. Y, al mismo tiempo, usará la escala, el rendimiento y la innovación de Azure. Además,
puede:
Configurar la infraestructura de VMware en la nube en cuestión de minutos.
Modernizar las aplicaciones a su ritmo.
Mejora de las aplicaciones de VMware con una infraestructura dedicada, aislada y de alto rendimiento, así
como productos y servicios exclusivos de Azure.
Trasladar o ampliar las máquinas virtuales locales a Azure sin tener que refactorizar las aplicaciones.
Obtención de la escala, la automatización y el aprovisionamiento rápido para cargas de trabajo de VMware
en la infraestructura global de Azure.
Beneficiarse de una solución que ofrece Microsoft, está verificada por VMware y que se ejecuta en la
infraestructura de Azure.
Diseño de soluciones
Después de que Contoso establece los objetivos y requisitos, la compañía diseña y revisa una solución de
implementación e identifica el proceso de migración.
Arquitectura actual
Características de la arquitectura actual de Contoso:
Máquinas virtuales implementadas en un centro de datos local administrado por vSphere.
Cargas de trabajo implementadas en un clúster de hosts de VMware ESXi que se administra con vCenter,
vSAN y NSX.
En la arquitectura propuesta, Contoso:
Implementará una nube privada de Azure VMware Solution en la región de Azure "Oeste de EE. UU".
Conectará el centro de datos local a Azure VMware Solution que se ejecuta en la región Oeste de EE. UU.
mediante redes virtuales y ExpressRoute con Global Reach habilitado.
Migrará las máquinas virtuales a una implementación dedicada de Azure VMware Solution mediante
VMware Hybrid Cloud Extension (HCX).
Contoso evalúa el diseño propuesto y crea una lista de ventajas y desventajas como se indica en la tabla
siguiente:
Ventajas Infraestructura de VMware sin sistema operativo con alto

rendimiento.
Una infraestructura dedicada totalmente a Contoso y
aislada físicamente de la infraestructura de otros clientes.
Dado que Contoso usa un rehost con VMware, no hay
ninguna configuración especial y la migración no es
compleja.
Software Assurance con la Ventaja híbrida de Azure y las
actualizaciones de seguridad extendidas para las plataformas
Windows y SQL heredadas.
Contoso conservará el control total de las VM de la
aplicación en Azure.
Desventajas Contoso tendrá que seguir admitiendo la aplicación como

máquinas virtuales de VMware en lugar de trasladarlas a un
servicio administrado, como Azure App Service y
Azure SQL Database.
Se configura Azure VMware Solution y se calcula su precio
en función de un mínimo de tres nodos grandes en lugar de
máquinas virtuales individuales en IaaS de Azure. Contoso
tendrá que planear sus necesidades de capacidad, ya que la
empresa usa actualmente un entorno local que limita la
naturaleza a petición de otros servicios de Azure.
NOTE
Para más información sobre los precios, consulte Precios de Azure VMware Solution.
Contoso trasladará sus máquinas virtuales a Azure VMware Solution mediante la herramienta VMware HCX. Las
máquinas virtuales se ejecutarán en una nube privada de Azure VMware Solution. Entre los métodos de
migración de VMware HCX se incluye la ejecución de una migración masiva o en frío. VMware vMotion o
Replication-assisted vMotion (RAV) es un método reservado para cargas de trabajo que se ejecutan mediante
una migración en vivo.
Para realizar el proceso, el equipo de Contoso:
Planea sus redes en Azure y ExpressRoute.
Crea la nube privada de Azure VMware Solution mediante Azure Portal.
Configura la red para que incluya los circuitos de ExpressRoute.
Configura los componentes de HCX para conectar su entorno de vSphere local a la nube privada de Azure
VMware Solution.
Replica las máquinas virtuales y, a continuación, las traslada a Azure mediante VMware HCX.
Pasos del escenario

Paso 1: Planeamiento de la red
Paso 2: Creación de una nube privada de Azure VMware Solution
Paso 3: Configuración de la red
Paso 4: Migración de las máquinas vir tuales mediante HCX
Paso 1: Planeamiento de red
Contoso necesita planear sus redes, entre las que se incluyen Azure Virtual Network y la conectividad entre el
entorno local y Azure. La compañía debe proporcionar una conexión de alta velocidad entre el entorno local y
los entornos basados en Azure, junto con una conexión a la nube privada de Azure VMware Solution.
Esta conectividad se proporciona mediante Azure ExpressRoute, y requerirá algunos rangos de direcciones de
red y puertos de firewall específicos para habilitar los servicios. Esta conexión de alto ancho de banda y baja
latencia permite a Contoso acceder a los servicios que se ejecutan en la suscripción de Azure desde el entorno
de la nube privada de Azure VMware Solution.
Contoso tendrá que planear un esquema de direcciones IP que incluya un espacio de direcciones no
superpuesto para sus redes virtuales. La compañía deberá incluir una subred de puerta de enlace para la puerta
de enlace de ExpressRoute.
La nube privada de Azure VMware Solution se conecta a la red virtual de Contoso en Azure mediante otra
conexión de Azure ExpressRoute. Global Reach de ExpressRoute se habilitará para permitir la conexión directa
desde las máquinas virtuales del entorno local a las máquinas virtuales que se ejecutan en la nube privada de
Azure VMware Solution. Se requiere la SKU Premium de ExpressRoute para habilitar Global Reach.
Las nubes privadas de Azure VMware Solution requieren como mínimo un bloque de direcciones de red CIDR
/22 para las subredes. Para conectarse a entornos locales y redes virtuales, debe ser un bloque de direcciones
de red no superpuestas.
NOTE
Para más información sobre el planeamiento de redes de Azure VMware Solution, consulte Lista de comprobación de
redes para Azure VMware Solution.
Paso 2: Creación de una nube privada de Azure VMware Solution

Una vez completada la planeación de sus redes y direcciones IP, Contoso se centrará a continuación en la
configuración del servicio Azure VMware Solution en la región de Azure "Oeste de EE. UU." Mediante Azure
VMware Solution, Contoso puede implementar un clúster de vSphere en Azure.
Una nube privada de Azure VMware Solution es un centro de datos definido por software de VMware aislado
que admite hosts ESXi, vCenter, vSAN y NSX. La pila se ejecuta en nodos de hardware sin sistema operativo
dedicados y aislados en una región de Azure. La implementación inicial mínima para una nube privada de Azure
VMware Solution es de tres hosts. Se pueden agregar más hosts de uno en uno, hasta un máximo de 16 hosts
por clúster.
Para más información, consulte Conceptos de nubes privadas y clústeres de la versión preliminar de Azure
VMware Solution.
Las nubes privadas de Azure VMware Solution se administran a través del portal de dicha solución. Contoso
tiene su propio servidor vCenter Server en su propio dominio de administración.
Para aprender a crear nubes privadas de Azure VMware Solution, consulte Implementación de una nube privada
de Azure VMware Solution en Azure.
1. El equipo de Contoso registra primero el proveedor de Azure VMware Solution con Azure mediante la
ejecución del siguiente comando:
az provider register -n Microsoft.AVS --subscription <your subscription ID>
2. En Azure Portal, el equipo crea la nube privada de Azure VMware Solution proporcionando la
información de red del plan. A continuación, el equipo selecciona Revisar y crear . Este paso tarda
aproximadamente dos horas.
3. El equipo comprueba que se haya completado la implementación de la nube privada de Azure VMware
Solution; para ello, va al grupo de recursos y selecciona el recurso de nube privada. El estado aparece
como correcto .
Paso 3: Configuración de las redes

Una nube privada de Azure VMware Solution requiere una red virtual. Dado que Azure VMware Solution no
admite una instancia de vCenter local durante la versión preliminar, Contoso tiene que realizar pasos adicionales
para la integración con su entorno local. Mediante la configuración de un circuito de ExpressRoute y una puerta
de enlace de red virtual, el equipo conectará sus redes virtuales a la nube privada de Azure VMware Solution.
Para más información, consulte Configuración de redes para la nube privada de VMware en Azure.
1. El equipo de Contoso primero crea una red virtual con una subred de puerta de enlace.
IMPORTANT
El equipo debe usar un espacio de direcciones que no se superponga con el que se usó al crear la nube privada.
2. A continuación, el equipo crea la puerta de enlace de VPN de ExpressRoute, asegurándose de seleccionar

la SKU correcta y, después, selecciona Revisar y crear .
3. El equipo obtiene la clave de autorización para conectar ExpressRoute a la red virtual. Esta se encuentra
en la pantalla Conectividad del recurso de la nube privada de Azure VMware Solution en Azure Portal.
4. El equipo conecta ExpressRoute a la puerta de enlace de VPN que conecta la nube privada de Azure
VMware Solution a la red virtual de Contoso. Para ello, crea una conexión en Azure.
Para más información, consulte Acceso a una nube privada de Azure VMware Solution.
Paso 4: Migración con VMware HCX
Para migrar las máquinas virtuales de VMware a Azure mediante HCX, el equipo de Contoso tendrá que seguir
estos pasos de alto nivel:
Instalar y configurar VMware HCX.
Realizar migraciones a Azure mediante HCX.
Para más información, consulte Instalación de HCX para Azure VMware Solution.
Instalación y configuración de VMware HCX para la nube pública
VMware HCX es un producto de VMware que forma parte de la instalación predeterminada de Azure VMware
Solution. HCX Advanced está instalado de manera predeterminada, pero se puede actualizar a HCX Enterprise
para obtener características y funcionalidades adicionales a medida que se necesiten.
Azure VMware Solution automatiza el componente de administrador de la nube de HCX en Azure VMware
Solution. Proporciona las claves de activación del cliente y el vínculo de descarga al dispositivo HCX Connector
que se debe configurar en el lado local y en un dominio de vCenter del cliente. A continuación, estos elementos
se emparejan con el dispositivo en la nube de Azure VMware Solution, de modo que los clientes pueden
aprovechar servicios como la migración y el ajuste de nivel 2.
El equipo de Contoso está implementando HCX mediante el uso de un paquete OVF que VMware
proporciona.
Para instalar y configurar HCX para la nube privada de Azure VMware Solution, consulte Instalación de
HCX para Azure VMware Solution.
A medida que el equipo configura HCX, ha elegido habilitar la migración y otras opciones, incluida la
Para más información, consulte Flujo de trabajo de instalación de HCX para nubes públicas de HCX.
Migración de máquinas virtuales a Azure mediante HCX
Cuando el centro de datos local (origen) y la nube privada de Azure VMware Solution (destino) están
configurados con la nube de VMware y HCX, Contoso puede empezar a migrar las máquinas virtuales. El equipo
puede migrar las máquinas virtuales con centros de datos compatibles con VMware HCX como origen y destino,
mediante varias tecnologías de migración.
La aplicación HCX de Contoso está en línea y el estado es verde. El equipo ya está listo para migrar y
proteger las máquinas virtuales de soluciones de Azure VMware Solution mediante HCX.
Migración masiva de VMware HCX
Este método de migración utiliza los protocolos de replicación de VMware vSphere para trasladar
simultáneamente varias máquinas virtuales a un sitio de destino. Dicha integración aporta las siguientes
ventajas:
Este método está diseñado para trasladar varias máquinas virtuales en paralelo.
La migración se puede establecer para que finalice según una programación predefinida.
Las máquinas virtuales se ejecutan en el sitio de origen hasta que se inicia la conmutación por error. La
interrupción del servicio equivale a un reinicio.
Migración en vivo de VMware HCX vMotion
Este método de migración usa el protocolo de VMware vMotion para trasladar una única máquina virtual a un
sitio remoto. Dicha integración aporta las siguientes ventajas:
Este método está diseñado para trasladar una máquina virtual a la vez.
No se produce ninguna interrupción del servicio cuando se migra el estado de la máquina virtual.
Migración en frío de VMware HCX
Este método de migración usa el protocolo de transmisión de datos en proximidad de VMware. La opción se
selecciona automáticamente cuando se apaga la máquina virtual de origen.
VMware HCX Replication-assisted vMotion
VMware HCX RAV combina las ventajas de la migración masiva de VMware HCX, que incluye operaciones en
paralelo, resistencia y programación, con las ventajas de la migración de VMware HCX vMotion, entre las que se
incluye la eliminación del tiempo de inactividad durante la migración del estado de la máquina virtual.
Para obtener documentación técnica adicional de VMware, consulte:
Documentación de VMware HCX
Migración de máquinas virtuales mediante VMware HCX
Traslado de una instancia local de Servicios de
Escritorio remoto a un escenario de Windows
Virtual Desktop
Windows Virtual Desktop es un servicio completo de virtualización de escritorio y aplicaciones que se ejecuta
en la nube. Es la única Infraestructura de escritorio virtual (VDI) que ofrece administración simplificada,
multisesión de Windows 10 Enterprise, optimizaciones para aplicaciones de Microsoft 365 para empresas y
compatibilidad con entornos de Servicios de Escritorio remoto (RDS). Implemente y escale las aplicaciones y
escritorios de Windows en Azure en cuestión de minutos y obtenga características de cumplimiento y seguridad
integradas.
Azure Migrate Evaluación y migración de entornos de RDS locales.
Ejecución de cargas de trabajo con Windows Virtual Desktop

de Azure.
Administración de Windows Virtual Desktop con la

experiencia de usuario de administración de Windows Virtual
Desktop.
NOTE
Este artículo se centra en el uso de Windows Virtual Desktop de Azure para migrar un entorno de RDS local a Azure.

Al trabajar en estrecha colaboración con los partners comerciales, el equipo de TI de Contoso definirá los
impulsores del negocio para una migración de VDI a Azure. Entre los impulsores principales se incluyen:
Vencimiento del entorno actual: un centro de datos agota su capacidad cuando alcanza el final de una
concesión o se cierra. La migración a la nube ofrece una capacidad prácticamente ilimitada. Es posible que el
software actual también esté llegando al final de su ciclo de vida, de modo que es necesario actualizar el
software que ejecuta la solución VDI actual de Contoso.
VDI multisesión de Windows 10: Proporcione a los usuarios de Contoso el único escritorio de Windows
10 multisesión virtualizado en la nube que es altamente escalable y está actualizado y disponible en todos
los dispositivos.
Optimización para aplicaciones de Microsoft 365 para empresas: Ofrezca la mejor experiencia para
las aplicaciones de Microsoft 365 para empresas, con escenarios de escritorio virtual multisesión que
proporcionan la experiencia virtualizada más productiva para los usuarios de Contoso.
Implementación y escalado en cuestión de minutos: Virtualice e implemente rápidamente
aplicaciones de escritorio modernas y heredadas en la nube en cuestión de minutos gracias a la
administración unificada en Azure Portal.
Seguridad y productividad en Azure y Microsoft 365: Implemente una solución completa e inteligente
que mejora la creatividad y la colaboración para todo el mundo. Cambie a Microsoft 365 y obtenga
Office 365, Windows 10 y Enterprise Mobility + Security.
Objetivos de un entorno local de RDS a Windows Virtual Desktop en
la nube
Teniendo en cuenta los impulsores del negocio, Contoso ha establecido los objetivos de esta migración:
Modernizar el entorno de escritorio virtual para la nube.
Aprovechar las licencias de Microsoft 365 existentes.
Mejorar la seguridad de los datos corporativos cuando los usuarios trabajan de forma remota.
Optimizar el entorno nuevo para los costo y el crecimiento.
Estos objetivos admiten la decisión de usar Windows Virtual Desktop y validarlo como el mejor método de
migración para Contoso.
Ventajas de ejecutar Windows Virtual Desktop en Azure

Con Windows Virtual Desktop de Azure, Contoso puede ejecutar, administrar y escalar sin problemas su
solución VDI de forma rápida y sencilla. La empresa también puede proporcionar a sus usuarios un entorno
optimizado de Windows 10 de varias sesiones.
Contoso aprovechará las licencias de Microsoft 365 existentes, a la vez que usará la escala, el rendimiento, la
seguridad y la innovación de Azure.
Entre las ventajas adicionales se pueden incluir:
Acceso a Windows Virtual Desktop desde cualquier parte.
Entorno de aplicaciones de Microsoft 365 para empresas optimizado.
Windows Virtual Desktop para entornos de desarrollo o pruebas.
Diseño de soluciones
identifica el proceso de migración.
Arquitectura actual
RDS se implementa en un centro de datos local. La organización usa Microsoft 365 y posee la licencia.
Sincronice Active Directory o Azure Active Directory Domain Services.
Implemente Windows Virtual Desktop en Azure.
Migre los servidores locales de RDS a Azure.
Convierta los discos de perfil de usuario en contenedores de perfil de FSLogix.
Figura 1: Arquitectura propuesta.
Ventajas Entorno multisesión de Windows 10 Enterprise.
Basado en la nube, lo que permite el acceso desde cualquier

lugar.
Aprovechar otros servicios de Azure, como Azure Files

dentro del entorno de Windows Virtual Desktop.
Optimizado para el escritorio moderno de Microsoft.
Desventajas Para optimizarse por completo para Azure, Contoso tendrá

que recompilar las imágenes de Windows 10 optimizadas
para sesiones multiusuario.
Windows Virtual Desktop no admite los discos de perfil de

usuario, por lo que los UDP se deben migrar a los
contenedores de perfil de FSLogix.
Contoso moverá las máquinas virtuales a Windows Virtual Desktop en Azure con la herramienta de evaluación
de Lakeside y Azure Migrate. Contoso tendrá que:
Ejecutar la herramienta de evaluación en su infraestructura de RDS local para determinar la escala de la
implementación de Windows Virtual Desktop en Azure.
Migre a Windows Virtual Desktop mediante máquinas virtuales persistentes o multisesión de Windows
10 Enterprise.
Optimizar el escalado y la reducción vertical de Windows Virtual Desktop multisesión según sea
necesario para administrar los costos.
Virtualice las aplicaciones y asigne usuarios según sea necesario para continuar con la protección y
administración del entorno de Windows Virtual Desktop.
Pasos del escenario

1. Evalúe el entorno de RDS actual.
2. Cree la VDI y las nuevas imágenes en Azure, y migre las máquinas virtuales persistentes a Azure.
3. Convierta los discos de perfil de usuario en contenedores de perfil de FSLogix.
4. Replique las todas máquinas virtuales en Azure.
Paso 1: Evaluación del entorno de RDS actual

Contoso aprovisionará el servicio de Windows Virtual Desktop en la región East US 2 de Azure. Con Windows
Virtual Desktop, Contoso puede aprovisionar máquinas virtuales y grupos host, y crear grupos de aplicaciones.
Windows Virtual Desktop también configura un conjunto de disponibilidad para todos los servidores de la
solución de Windows Virtual Desktop. Windows Virtual Desktop permite a Contoso crear un entorno de VDI de
alta disponibilidad, así como escalar y reducir verticalmente con rapidez según sea necesario.
NOTE
Contoso analizó dos escenarios durante la evaluación: instancias de RDS multisesión (compartidas) y máquinas virtuales
persistentes (o dedicadas al usuario).
1. Asegúrese de que los servicios de dominio, ya sean Active Directory o Azure Active Directory Domain
Services, estén sincronizados con Azure Active Directory (Azure AD). Asegúrese de que el servicio de
dominio es accesible desde la suscripción de Azure y la red virtual que se va a conectar donde se
implementará el escalado y la reducción vertical de Windows Virtual Desktop.
NOTE
Obtenga más información acerca de Azure AD Connect para sincronizar el entorno local de Active Directory con
Azure AD.
NOTE
Obtenga información sobre el aprovisionamiento de Azure Active Directory Domain Services y la sincronización de
Azure AD.
2. Cree un nuevo proyecto de Azure Migrate.

Figura 3: Creación de un nuevo proyecto de Azure Migrate.
3. Seleccione la opción para evaluar y migrar servidores, seleccione VDI y agregue una herramienta.
Figura 4: Objetivos de Azure

Migrate de destino.
4. Configure la suscripción, el grupo de recursos, el nombre de proyecto y la geografía para los datos del
trabajo de migración.
Figura 5: Adición de datos de trabajo a la migración.
IMPORTANT
Esta ubicación no es donde se implementará el nuevo entorno de Windows Virtual Desktop. Aquí solo se
almacenarán los datos relacionados con el proyecto de Azure Migrate.
5. Seleccione Lakeside: SysTrack como herramienta de evaluación.

6. Seleccione Azure Migrate: Migración del ser vidor como herramienta de migración.
7. Agregue las herramientas al proyecto de migración.
Figura 6: Adición de herramientas a la migración.

8. Para iniciar la evaluación del entorno actual, seleccione Register with Azure Migrate (Registrarse con
Azure Migrate) en la herramienta Lakeside.
Figura 7: Evaluación del entorno
actual.
9. Contoso se conecta con Azure Migrate y Lakeside, y acepta los permisos solicitados.
Figura 8: Conexión de Azure a Lakeside.

10. Contoso sigue con la herramienta Lakeside para crear un nuevo inquilino y comenzar a evaluar su
entorno local de RDS actual. Desde el panel, Contoso puede acceder a la guía de implementación,
descargar el cliente de evaluación para implementarlo en su entorno actual y revisar los datos
recopilados de estos agentes.
Figura 9: El panel de Lakeside.
11. Cuando haya capturado una cantidad adecuada de datos, Contoso revisará los datos de evaluación para
determinar la mejor ruta de migración. Estos datos de evaluación incluyen los datos de evaluación sin
procesar de los equipos de escritorio, así como los datos divididos en diferentes roles de usuario. Esta
información incluye:
El número de usuarios de cada rol.
Las aplicaciones que usan los usuarios.
El consumo de recursos por cada usuario.
Los promedios de uso de recursos por cada rol de usuario.
Los datos de rendimiento del servidor de VDI.
Los informes de usuarios simultáneos.
Los paquetes de software más importantes en uso.
Ilustración 10: Informes del panel de Lakeside.
Contoso analiza estos datos para determinar el uso más rentable de los recursos de Windows Virtual Desktop
agrupados y personales.
NOTE
Contoso también tendrá que migrar sus servidores de aplicaciones a Azure para acercarlos más al entorno de Windows
Virtual Desktop y reducir la latencia de red para sus usuarios.
Paso 2: Creación del entorno de Windows Virtual Desktop para

equipos de escritorio agrupados
Con Azure Portal, Contoso creará un entorno de Windows Virtual Desktop a fin de usarlo para los recursos
agrupados. Más adelante, realizará los pasos de migración para conectar los dispositivos de escritorio
personales al mismo entorno.
1. Contoso selecciona la suscripción correcta y crea un nuevo grupo de hosts de Windows Virtual Desktop.
Figura 11: Un nuevo grupo de hosts de Windows Virtual Desktop.

2. Se especifica la suscripción, el grupo de recursos y la región. A continuación, seleccione el nombre del
grupo de hosts, el tipo de dispositivo de escritorio y los usuarios de escritorio predeterminados. El tipo de
dispositivo de escritorio se establece como Agrupado , ya que Contoso comenzará con un nuevo entorno
compartido para algunos de sus usuarios. Los usuarios de escritorio predeterminados pueden dejarse en
blanco. Siga configurando las máquinas virtuales.
Figura 12: Requisitos previos para configurar máquinas virtuales.
Contoso configura la máquina virtual y elige un tamaño personalizado; para ello, selecciona Cambiar
tamaño o bien usa el valor predeterminado.
Windows Virtual Desktop se elige como el prefijo de nombre de máquina virtual para estos
escritorios agrupados.
Dado que Contoso crea los servidores agrupados para usar la nueva funcionalidad de varias sesiones
de Windows 10 Enterprise para la configuración de la máquina virtual, deje el origen de la imagen
establecido en Galería . Esta opción permite a Contoso seleccionar la imagen de varias sesiones de
Windows 10 Enterprise para las máquinas virtuales.
En función de los roles de los usuarios de la evaluación de Lakeside, Contoso establece un total de
150 usuarios.
Otras opciones incluyen el tipo de disco, un campo UPN de unión a un dominio de Active Directory,
una contraseña de administrador, una ruta de acceso a una unidad organizativa opcional a la que se
agregan las máquinas, la red virtual y una subred para agregar servidores.
Figura 13: Configuración de máquinas virtuales.
NOTE
Contoso no puede crear una red virtual nueva en este paso. Antes de llegar a este paso, Contoso ya debe haber
creado una red virtual que tenga acceso a Active Directory.
NOTE
Contoso no puede utilizar una cuenta de usuario que requiera la autenticación multifactor en este paso. Si
Contoso planea usar la autenticación multifactor para sus usuarios, deberá crear una entidad de servicio para ese
fin.
3. Contoso valida nuevamente la configuración de Windows Virtual Desktop y crea el nuevo entorno de
máquinas virtuales de Windows Virtual Desktop agrupadas.
Figura 14: Revisión y creación de máquinas virtuales.
Paso 3: Conversión de discos de perfil de usuario en contenedores de

perfil de FSLogix
Ya que Windows Virtual Desktop no admite los discos de perfil de usuario (UPD), Contoso tiene que convertir
todos sus discos de este tipo en FSLogix a través del módulo de PowerShell FSLogixMigration.
Una vez que Contoso haya importado el módulo FSLogixMigration, ejecutará los siguientes cmdlets de
PowerShell para migrar de los discos de perfil de usuario a FSLogix.
IMPORTANT
Los módulos de PowerShell para Hyper-V, Active Directory y Pester son requisitos previos para ejecutar los cmdlets para
convertir los discos de perfil de usuario a FSLogix.
Una conversión de disco de perfil de usuario:
Convert-RoamingProfile -ParentPath "C:\Users\" -Target "\\Server\FSLogixProfiles$" -MaxVHDSize 20 -

VHDLogicalSectorSize 512
Una conversión de perfil móvil:
Convert-RoamingProfile -ProfilePath "C:\Users\User1" -Target "\\Server\FSLogixProfiles$" -MaxVHDSize 20 -

VHDLogicalSectorSize 512 -VHD -IncludeRobocopyDetails -LogPath C:\temp\Log.txt
En este punto, la migración ha habilitado el uso de recursos agrupados con Windows 10 Enterprise multisesión.
Contoso puede empezar a implementar las aplicaciones necesarias para los usuarios que usarán Windows 10
Enterprise multisesión.
No obstante, ahora Contoso debe migrar las máquinas virtuales persistentes a Azure.
Paso 4: Replicación y máquinas virtuales persistentes en

El siguiente paso del proceso de migración de Contoso consiste en migrar sus máquinas virtuales persistentes a
Windows Virtual Desktop. Para ello, Contoso vuelve al trabajo Azure Migrate: Migración del servidor que creó al
principio del proceso.
1. Contoso comienza por seleccionar la opción Detectar en las herramientas de Azure Migrate: Migración
del servidor.
Figura 15: Detección de una migración de servidores.

2. Contoso convierte una aplicación del entorno que va a administrar la replicación de las máquinas en
Windows Virtual Desktop. Asegúrese de que la región de destino esté establecida en East US 2 , que es
donde se creó su entorno de Windows Virtual Desktop.
Figura 16: Conversión de un dispositivo.

3. El proveedor de replicación se descarga, se instala y se registra en el proyecto de Azure Migrate para
iniciar la replicación en Azure.
Figura 17: Requisitos previos para la replicación en Azure.

4. Ahora se inicia la replicación de los hosts en Azure Blob Storage. Contoso puede continuar para permitir
que la replicación se realice hasta que esté preparado para probar las máquinas virtuales y, a
continuación, migrarlas a producción.
A medida que los equipos empiecen a ejecutarse en Azure, Contoso se asegurará de instalar el agente
de máquina virtual de Windows Virtual Desktop en cada máquina.
Como parte de la instalación, escriba el token de registro del entorno de Windows Virtual Desktop
para asociar el servidor con el entorno correcto.
5. El token de registro se puede obtener mediante los siguientes comandos:
Export-RDSRegistrationInfo -TenantName "Contoso" -HostPoolName "ContosoWVD" | Select-Object -
ExpandProperty Token > .\registration-token.txt
NOTE
Contoso también puede automatizar este proceso mediante los comandos msiexec al pasar el token de registro
como una variable.
6. Como último paso antes de la migración final, Contoso selecciona el elemento Usuarios en la
configuración de Azure Windows Virtual Desktop para asignar los servidores a sus usuarios y grupos
respectivos.
Figura 18: Último paso antes de la migración final.

Tras asignar un grupo de hosts a los usuarios, Contoso finaliza la migración de esas máquinas y continúa
migrando gradualmente el resto de los hosts de VDI locales a Azure.
Ya que los escritorios virtuales y servidores de aplicaciones se están ejecutando en Azure, Contoso debe poner
en plena marcha la implementación y protegerla.
Seguridad
IaaS de Azure.
Para la continuidad empresarial y la recuperación ante desastres (BCDR), Contoso realiza una copia de
seguridad de los datos de las máquinas virtuales mediante Azure Backup para proteger los datos. Para más
información, consulte la introducción a la copia de seguridad de máquinas virtuales de Azure.
Las licencias de Microsoft 365 se usan para las implementaciones de escritorio.
Azure.
Actualmente, Contoso tiene licencia para sus máquinas virtuales y aprovechará la Ventaja híbrida de Azure
para los servidores de aplicación. Contoso convertirá las máquinas virtuales de Azure existentes para
aprovechar las ventajas que ofrecen estos precios.
Conclusión
En este artículo, Contoso migró su implementación de RDS a una instancia de Windows Virtual Desktop
hospedada en Azure.
Procedimientos recomendados para la migración
del host de VMware para Azure
La migración de un host de VMware a Azure puede acelerar la metodología estándar que se describe en Cloud
Adoption Framework y que se muestra aquí.
Figura 1
En la tabla de contenido de la izquierda se describen los procedimientos recomendados en varias propiedades
web de Microsoft. Estos procedimientos recomendados pueden servir de guía para ejecutar la migración del
host de VMware a Azure VMware Solution. Marque esta página para tener una referencia rápida a la lista
completa de procedimientos recomendados.
Migración o implementación de instancias de
Windows Virtual Desktop en Azure
La migración de los escritorios de los usuarios finales de una organización a la nube es un escenario común en
las migraciones a la nube. Esto ayuda a mejorar la productividad de los empleados y a acelerar la migración de
varias cargas de trabajo para dar soporte a la experiencia del usuario de la organización.
Estrategia y motivaciones
Las migraciones de escritorios virtuales están motivadas por varios objetivos comunes que se muestran aquí:
Las organizaciones quieren ampliar la productividad a equipos, teléfonos, tabletas o exploradores que
podrían no estar bajo el control directo del equipo de TI.
Los empleados necesitan acceder a los datos corporativos y aplicaciones desde sus dispositivos.
A medida que las cargas de trabajo se migran a la nube, los empleados necesitan más soporte para tener
una experiencia más optimizada y de menor latencia.
Los costos de las experiencias de escritorios virtuales actuales o propuestas deben optimizarse para ayudar a
las organizaciones a escalar su trabajo remoto de forma más eficaz.
El equipo de TI desea transformar el área de trabajo, y esta transformación a menudo empieza por la
experiencia de los empleados.
La virtualización de los escritorios de los usuarios finales en la nube puede ayudar a su equipo a comprender
cada uno de estos resultados.
Enfoque: refactorización y modernización de Windows Virtual

Desktop
En el enfoque que se describe en esta serie de artículos, las granjas existentes de Citrix, VMware o Servicios de
Escritorio remoto se modernizan y reemplazan por una solución de plataforma como servicio (PaaS)
denominada Windows Virtual Desktop.
En este escenario, las imágenes de escritorio se migran a Azure o se generan imágenes nuevas. Del mismo
modo, los perfiles de usuario se migran a Azure o se crean perfiles nuevos. En su mayor parte, la solución del
cliente está habilitada, pero este esfuerzo de migración no ha supuesto demasiados cambios en ella.
Cuando la migración a la nube ha finalizado, tanto la sobrecarga como los costos derivados de administrar una
granja de escritorios virtuales se reemplazan por una solución nativa de la nube que administra la experiencia
del escritorio virtual para su equipo. Al equipo solo debe preocuparle el soporte de las imágenes de escritorio,
las aplicaciones disponibles, Azure Active Directory y los perfiles de usuario.
Pasos siguientes
Para obtener una guía sobre elementos concretos del recorrido de adopción de la nube, consulte:
Planeamiento de la migración o implementación de Windows Virtual Desktop
Finalización de una prueba de concepto de Windows Virtual Desktop
Evaluación de la migración o implementación de Windows Virtual Desktop
Implementación o migración de instancias de Windows Virtual Desktop
Lanzamiento de la implementación de Windows Virtual Desktop en producción
Planificación de Windows Virtual Desktop
Los escenarios de implementación de Windows Virtual Desktop siguen la misma metodología de migración que
otros trabajos de migración. Este enfoque coherente permite que los generadores de migración o los equipos de
migración existentes adopten el proceso con pocos cambios en los requisitos no técnicos.
Planeación de la migración
Al igual que con otras migraciones, el equipo evaluará las cargas de trabajo, las implementará y las lanzará para
los usuarios finales. Sin embargo, Windows Virtual Desktop incluye requisitos específicos de consulta de las
zonas de aterrizaje de Azure durante la evaluación de las cargas de trabajo. El proceso también requerirá una
prueba de concepto antes de la primera implementación.
Para compilar el plan, consulte la plantilla de DevOps del plan de adopción de la nube para un trabajo pendiente
de migración existente en Azure DevOps. Úsela para crear un plan de actividades detallado.
Justificación comercial
Parte de la planeación requerirá poder articular las ventajas empresariales de empezar a usar Windows Virtual
Desktop. En la lista siguiente se incluyen los elementos que se van a usar en un caso empresarial.
El plano de control de Windows Virtual Desktop o el plano de administración se proporciona como un
servicio a los clientes. El plano de control administra la conectividad global ininterrumpida del usuario final
en su escritorio, así como la implementación centralizada y la orquestación que requiere TI. Se trata de un
servicio de PaaS en el que no tiene que adquirir hardware, implementarlo, revisarlo ni proporcionarle
soporte técnico. Es un servicio permanente que simplemente se usa. No tiene ningún costo, es un servicio
del que dispone gracias a una licencia que ya posee; por lo tanto, puede lograr un ahorro de costos mediante
este servicio PaaS. Esto también significa que, una vez realizada la migración, no es necesario que realice la
administración, mantenimiento, solución de problemas, corrección de errores, aplicación de revisiones, etc.,
de su propio servicio local de administración de escritorios virtuales. Esto permite al equipo de TI centrarse
en lo más importante, es decir, en ofrecer más valor a la empresa, lo que implica normalmente garantizar a
los clientes la mejor experiencia de usuario posible cuando usen sus aplicaciones y datos.
Sin costes por adelantado. La creación de un escritorio virtual local requiere el pago por adelantado o un
acuerdo de leasing prolongado para todo el hardware necesario para satisfacer la carga máxima demandada,
incluso aunque el hardware no se use a medida que avanza el proyecto, e incluso si el hardware no se utiliza
el 100% del tiempo una vez completado el proyecto. Windows Virtual Desktop y Azure se cobran según el
uso; por lo tanto, solo paga por lo que utiliza. Además, se puede escalar y reducir verticalmente en función de
los requisitos empresariales lo que le permitirá cumplir con estos requisitos y, posteriormente, reducir los
costos mediante una reducción vertical.
Windows Virtual Desktop y Azure tienen una cadencia mucho más rápida en términos de nuevas
características y funcionalidades. El hardware local y el software comercial tienen una vida útil y no reciben
nuevas características o funcionalidades con mucha frecuencia, y normalmente necesitan un proyecto
costoso para su implementación. Windows Virtual Desktop y Azure reciben nuevas funcionalidades de forma
periódica y la implementación la administra Microsoft. Para el usuario, este es un servicio permanente que
simplemente se usa. No necesita un proyecto para implementar nuevos servicios para que los usuarios de su
empresa puedan usarlos. Estas nuevas características pueden proporcionar una ventaja competitiva o al
menos impedir que se vea lastrado por la deuda técnica.
Azure es una nube de hiperescala que puede proporcionar un escalado masivo. Los servicios locales nunca
podrán competir con Azure como plataforma informática. Esto proporciona una agilidad significativa para su
organización. Si la organización tiene la oportunidad de expandirse a otras ubicaciones globales para las que
no se dispone de un centro de datos local, Microsoft puede hospedar este servicio en un número ilimitado de
regiones de Azure, lo cual permite a Microsoft situar la infraestructura y los servicios mucho más cerca de los
usuarios finales de lo que usted podría hacerlo.
La experiencia de usuario enriquecida de Windows 10 que esperan los usuarios finales, al precio de una
solución multisesión. Windows Virtual Desktop permite el escalado de Windows Server con Servicios de
Escritorio remoto junto con la experiencia del usuario de Windows 10, sin poner en peligro la compatibilidad
de las aplicaciones
No hay ningún requisito de licencias de acceso del cliente con Windows 10 multisesión, ya que este no
requiere una licencia CAL.
En Windows Virtual Desktop, si implementa Windows Server (Windows Server 2012 R2, 2016 o 2019), no
es necesario adquirir ninguna licencia de Windows Server.
Todas las máquinas virtuales de Windows Virtual Desktop se cobran según la tarifa de proceso básica.
Windows Virtual Desktop está autorizado mediante otra licencia de la que ya probablemente dispone
(M365 E3+), que incluye la licencia de Windows
Todas las máquinas virtuales de Windows 7 en Windows Virtual Desktop recibirán actualizaciones de
seguridad extendidas gratis hasta el 14 de enero de 2023
Pasos siguientes
Revisión de las zonas de aterrizaje de Azure para
Para que el equipo de adopción de la nube de Contoso realice la migración a Windows Virtual Desktop,
necesitará una zona de aterrizaje de Azure que hospede escritorios y cargas de trabajo auxiliares. La siguiente
lista de comprobación sirve de ayuda para que el equipo evalúe la compatibilidad de la zona de aterrizaje. La
guía de la metodología de preparación de este marco puede ayudar al equipo a crear una zona de aterrizaje de
Azure compatible si no se ha proporcionado ninguna.
Evaluación de la compatibilidad
Plan de organización de recursos: la zona de aterrizaje debe incluir referencias a las suscripciones que se
van a usar, instrucciones de uso de los grupos de recursos, y los estándares de etiquetado y la nomenclatura
que el equipo usará al implementar los recursos.
Azure AD: se debe proporcionar una instancia de Azure Active Directory (Azure AD) o un inquilino de
Azure AD para la autenticación de los usuarios finales.
Red: Antes de la migración, debe establecerse toda configuración de red necesaria en la zona de aterrizaje.
VPN o ExpressRoute: además, toda zona de aterrizaje que admita escritorios virtuales necesitará una
conexión de red para que los usuarios finales se conecten a ella y a los recursos hospedados. Si hay un
conjunto existente de puntos de conexión configurados para los escritorios virtuales, se puede seguir
enrutando a los usuarios finales mediante los dispositivos locales con una conexión VPN o Azure
ExpressRoute. Si aún no existe, puede que desee revisar las instrucciones sobre cómo configurar las opciones
de conectividad de red en la metodología de preparación.
Gobernanza, usuarios e identidad: para lograr homogeneidad en el cumplimiento, los requisitos de
control de acceso desde los escritorios virtuales, y de los usuarios y sus identidades deben configurarse
como directivas de Azure y aplicarse a la zona de aterrizaje.
Seguridad: el equipo de seguridad ha revisado la configuración de las zonas de aterrizaje y las ha aprobado
para el uso previsto, como la conexión externa, las aplicaciones críticas o la información confidencial.
Windows Vir tual Desktop: se ha habilitado como plataforma como servicio.
Toda zona de aterrizaje que el equipo desarrolle según los procedimientos recomendados de la metodología de
preparación y que cumpla los requisitos especializados indicados anteriormente sería apta como zona de
aterrizaje para esta migración.
Para aprender a diseñar la arquitectura de Windows Virtual Desktop, revise los requisitos de Windows Virtual
Desktop.
Pasos siguientes
Prueba de concepto de Windows Virtual Desktop
Antes de que el equipo de adopción de la nube de Contoso implemente sus escritorios de usuario final,
completa y realiza una prueba de concepto para validar la configuración de la zona de aterrizaje de Azure y la
capacidad de la red del usuario final.
El método siguiente para el proceso de migración se ha simplificado para describir la implementación de una
prueba de concepto.
1. Evaluación : el equipo implementa los grupos de host mediante el uso de tamaños de máquina virtual
predeterminados. Los datos de la evaluación ayudan al equipo a identificar no solo el número esperado de
sesiones de usuario simultáneas, sino también el número de máquinas virtuales necesarias para admitir esas
sesiones simultáneas.
2. Implementación : el equipo crea un grupo de hosts para escritorios agrupados mediante una imagen de la
galería de Windows 10 obtenida de Azure Marketplace y el ajuste de tamaño del paso 1 de evaluación.
3. Implementación : el equipo crea grupos de aplicaciones de RemoteApp para las cargas de trabajo que ya se
han migrado.
4. Implementación : el equipo crea un contenedor de perfiles de FSLogix para almacenar los perfiles de
usuario.
5. Lanzamiento : el equipo prueba el rendimiento y la latencia de los grupos de aplicaciones y los escritorios
implementados para realizar un muestreo de los usuarios.
6. Lanzamiento : el equipo incorpora los usuarios finales para enseñarles cómo conectarse mediante el cliente
de escritorio de Windows, el cliente web, el cliente de Android, el cliente de macOS o el cliente de iOS.
Supuestos
El enfoque de prueba de concepto podría satisfacer algunas necesidades de producción, pero se basa en una
serie de supuestos.
Es poco probable que todo lo siguiente se cumpla para todas las migraciones empresariales de Windows Virtual
Desktop. El equipo de adopción debe presuponer que la implementación de producción necesitará una
implementación independiente que se ajuste mejor a los requisitos de producción identificados durante la
evaluación de Windows Virtual Desktop. Dichas suposiciones son:
Los usuarios finales tienen una conexión de baja latencia con la zona de aterrizaje asignada en Azure.
Todos los usuarios pueden trabajar desde un grupo compartido de escritorios.
Todos los usuarios pueden utilizar la imagen de Windows 10 Enterprise para varias sesiones de Azure
Marketplace.
Todos los perfiles de usuario se migrarán a Azure Files, a Azure NetApp Files o a un servicio de
almacenamiento basado en máquinas virtuales para los contenedores de perfiles de FSLogix.
Todos los usuarios se pueden describir mediante un rol común con una densidad de seis usuarios por cada
unidad central de procesamiento virtual (vCPU) y 4 gigabytes (GB) de memoria RAM, tal como se indica en
las recomendaciones de tamaño de la máquina virtual.
Todas las cargas de trabajo son compatibles con Windows 10 Enterprise multisesión.
La latencia entre los escritorios virtuales y los grupos de aplicaciones es aceptable para el uso de producción.
Para calcular el costo del escenario de Windows Virtual Desktop basado en la referencia de la configuración de
la prueba de concepto, el equipo usa la calculadora de precios para las regiones Este de EE. UU., Oeste de Europa
o Sudeste Asiático.
NOTE
Todos estos ejemplos usan Azure Files como servicio de almacenamiento para los perfiles de usuario.
Pasos siguientes
Valoración de Windows Virtual Desktop
La prueba de concepto de Windows Virtual Desktop proporciona un ámbito inicial como implementación de
referencia para el equipo de adopción de la nube de Contoso. Pero es poco probable que la salida de esa prueba
de concepto satisfaga las necesidades de producción.
El ejercicio de evaluación de Windows Virtual Desktop sirve para probar supuestos concretos mediante un
proceso controlado por datos. Los datos de la evaluación ayudarán al equipo a responder varias preguntas
importantes, validar o invalidar los supuestos, y refinar el ámbito cuando sea necesario permitir el uso de su
escenario de Windows Virtual Desktop. Este enfoque de validación de supuestos acelera la migración de los
escritorios de usuario final a Windows Virtual Desktop o su implementación.
Evaluación de implementaciones de Windows Virtual Desktop

En cada evaluación de Windows Virtual Desktop se evalúa una combinación de un rol de usuario, un grupo de
hosts de máquinas virtuales coherente, las aplicaciones y los datos de usuario final, y los perfiles de usuario
(datos). En la evaluación, el objetivo del equipo es usar datos para dar respuesta a las preguntas de esta sección.
Esas respuestas darán forma al ámbito real de la implementación y el lanzamiento de la migración de Windows
Virtual Desktop.
Las respuestas a estas preguntas comienzan con datos. En la metodología de planeamiento, y más
concretamente en los procedimientos recomendados y la evaluación del patrimonio digital, para crear un plan
de migración, los datos deben recopilarse y analizarse previamente. Sin embargo, las preguntas de evaluación
de esta carga de trabajo específica es probable que requieran datos adicionales. Para desarrollar un plan de
implementación de Windows Virtual Desktop, se necesitan los datos de los dispositivos de escritorio, los
usuarios y las cargas de trabajo que emplea cada usuario.
Si usa Movere como herramienta de recopilación de datos, es probable que tenga los datos necesarios para
desarrollar roles y responder a estas preguntas mediante los datos de Azure Migrate, igual que en cualquier
otro escenario de migración.
Si no tiene los datos necesarios para responder a todas las preguntas de esta sección, hay otro proveedor de
software externo que ofrece un proceso de detección independiente que aumenta los datos de los que ya
dispone. El proveedor, Lakeside, también está integrado en Azure Migrate en la sección de objetivos de la
migración de la infraestructura de escritorio virtual. El proveedor puede ayudarle a diseñar un plan de
implementación de Windows Virtual Desktop, incluidos roles, grupos de hosts, aplicaciones y perfiles de
usuario.
Roles de usuario
¿Cuántos roles distintos serán necesarios para dar soporte a todos los usuarios incluidos en este escenario de
migración? La definición de roles es el resultado de incluir usuarios en cubos según los criterios siguientes:
Grupos personales: ¿hay grupos de usuarios concretos que requieran dispositivos de escritorio dedicados,
en lugar de grupos? Por ejemplo, los requisitos de seguridad, cumplimiento, alto rendimiento o unos vecinos
ruidosos pueden hacer que algunos usuarios se ejecuten en escritorios dedicados que no formen parte de
una estrategia de agrupación. Especifique un tipo del grupo de hosts de roles durante la implementación del
grupo de hosts de Windows Virtual Desktop para indicar esta información.
Densidad: ¿hay grupos de usuarios concretos que requieran experiencias de escritorio de menor densidad?
Por ejemplo, una densidad mayor podría requerir dos usuarios por cada unidad central de procesamiento
virtual (vCPU) en lugar del supuesto de densidad de usuarios ligera, seis por vCPU. Escriba la información de
la densidad en la configuración del grupo de implementación del grupo de hosts de Windows Virtual
Desktop.
Rendimiento: ¿hay grupos de usuarios concretos que requieran experiencias de escritorio de mayor
rendimiento? Por ejemplo, algunos usuarios necesitan más memoria que los 4 gigabytes de RAM por unidad
central de procesamiento virtual. El tamaño de la máquina virtual se especifica en los detalles de la máquina
virtual de la implementación del grupo de hosts de Windows Virtual Desktop.
Procesamiento gráfico (GPU): ¿tienen determinados grupos de usuarios requisitos gráficos más
exigentes? Por ejemplo, algunos usuarios requieren máquinas virtuales con procesador GPU en Azure, como
se muestra en esta guía de configuración de máquinas virtuales con GPU.
Región de Azure: ¿operan los usuarios de un sistema operativo de grupo específico desde varias regiones
geográficas? Por ejemplo, antes de configurar el grupo de hosts, un usuario de cada región debería usar la
herramienta de estimación para probar la latencia en Azure. El usuario de prueba debería compartir la región
de Azure de menor latencia, así como la latencia, en milisegundos, de las tres regiones principales de Azure.
Funciones empresariales: ¿se pueden agrupar las agrupaciones específicas de usuarios por unidad
empresarial, código de cargo o función en la empresa? Este tipo de agrupación ayudará a ajustar los costos
corporativos en las fases posteriores de las operaciones.
Número de usuarios: ¿cuántos usuarios estarán en cada uno de los roles?
Número máximo de sesiones: en función de la zona geográfica y de las horas en funcionamiento,
¿cuántos usuarios simultáneos se esperan para cada rol en los periodos de carga máxima?
Los elementos diferenciadores de cada una de las preguntas anteriores comenzarán a ilustrar los roles de
usuario por función empresarial, centro de costos, región geográfica y requisitos técnicos. La tabla siguiente
puede ayudar a registrar las respuestas para rellenar un documento completo de evaluación o diseño:
C RIT ERIO GRUP O DE RO L ES 1 GRUP O DE RO L ES 2 GRUP O DE RO L ES 3
Grupos Grupos Grupos Dedicado (problemas de

seguridad)
Densidad Ligera (6 usuarios/vCPU) Mayor (2 usuarios/vCPU) Dedicada (1 usuario/vCPU)
Rendimiento Bajo Uso de memoria alto Bajo
GPU N/D Obligatorio N/D
Región de Azure Norteamérica Europa Occidental Norteamérica
Número de usuarios 1,000 50 20
Número de sesiones 200 50 10
Cada rol (o cada grupo de usuarios con funciones empresariales y requisitos técnicos únicos) necesitaría una
configuración concreta del grupo de hosts.
La evaluación del usuario final proporcionará los datos necesarios: tipo de grupo, densidad, tamaño, CPU o GPU,
región de la zona de aterrizaje, etc.
A continuación, la evaluación de la configuración del grupo de hosts asigna esos datos a un plan de
implementación. La alineación tanto de los requisitos técnicos y empresariales como del costo ayudará a
determinar el número y la configuración correctos de los grupos de hosts.
Consulte los ejemplos de precios de las regiones Este de EE. UU., Oeste de Europa o Sudeste de Asia.
Grupos de aplicaciones
Los exámenes del entorno local actual que realizan tanto Movere como Lakeside proporcionan datos relativos a
las aplicaciones que se ejecutan en los escritorios de los usuarios finales. Utilice esos datos para crear una lista
de las aplicaciones necesarias para cada rol. En todas estas aplicaciones, las respuestas a las siguientes
preguntas darán forma a las iteraciones de la implementación:
¿Es preciso instalar alguna aplicación para que el rol use este dispositivo de escritorio? Salvo que el rol utilice
aplicaciones de software como servicio basadas totalmente en web, es probable que sea preciso configurar
una imagen maestra personalizada de un disco duro virtual para cada rol, con las aplicaciones necesarias
instaladas en esa imagen.
¿Necesita este rol aplicaciones de Microsoft 365? En caso afirmativo, tendrá que agregar Microsoft 365 a una
imagen maestra personalizada de un disco duro virtual.
¿Es esta aplicación compatible con Windows 10 Enterprise multisesión? Si las aplicaciones no son
compatibles, puede que se necesite un grupo de roles para ejecutar la imagen personalizada del disco duro
virtual. Para obtener ayuda sobre los problemas de compatibilidad de las aplicaciones con Windows Virtual
Desktop, consulte al servicio de asesoría de aplicaciones de escritorio.
¿Es probable que las aplicaciones críticas sufran latencia entre la instancia de Windows Virtual Desktop y los
sistemas de back-end? Si eso sucediera, puede considerar la posibilidad de migrar a Azure los sistemas de
back-end que permiten el uso de la aplicación.
Las respuestas a estas preguntas pueden requerir que el plan incluya la corrección en las imágenes de escritorio
o los componentes de las aplicaciones auxiliares antes de la migración o implementación del escritorio.
Pasos siguientes
Implementación o migración de Windows Virtual
Desktop
En las instrucciones de este artículo se presupone que ha establecido un plan para Windows Virtual Desktop, ha
evaluado los requisitos de implementación del escritorio, ha completado una prueba de concepto y ya está listo
para migrar o implementar las instancias de Windows Virtual Desktop.
Ámbito inicial
La implementación de instancias de Windows Virtual Desktop sigue un proceso similar al de prueba de
concepto. Utilice este ámbito inicial como base de referencia para explicar los distintos cambios de ámbito que
requiere la salida de la evaluación.
Cree un grupo de hosts para escritorios agrupados mediante una imagen de la galería de Windows 10
obtenida de Azure Marketplace y el ajuste de tamaño del paso 1 de ese procedimiento.
Cree grupos de aplicaciones de RemoteApp para las cargas de trabajo que ya se han migrado.
Cree un contenedor de perfiles de FSLogix para almacenar perfiles de usuario.
La implementación o migración constan de las siguientes tareas: migración de roles, migración de aplicaciones y
migración de perfiles de usuario. En función de los resultados de la evaluación de las cargas de trabajo, es
probable que se produzcan cambios en todas esas tareas de migración. Este artículo ayuda a identificar las
distintas formas en que puede cambiar el ámbito en función de los comentarios de la evaluación.
Metodología de iteración
Es probable que cada rol requiera una iteración del ámbito inicial descrito anteriormente, lo que generaría
varios grupos de hosts. En función de la evaluación de Windows Virtual Desktop, el equipo de adopción debería
definir el número de iteraciones según el número de roles o usuarios por rol. El desglose del proceso en
iteraciones controladas por roles ayuda a reducir el impacto que la velocidad de los cambios puede tener en el
negocio y permite que el equipo se centre en la correcta realización de pruebas e incorporaciones de cada uno
de los grupos de roles.
Consideraciones acerca del ámbito

Los siguientes conjuntos de consideraciones deben incluirse en la documentación de diseño de cada grupo de
roles que se vaya a migrar o implementar. Una vez tenidas en cuenta las consideraciones acerca del ámbito en el
ámbito inicial mencionado anteriormente, la implementación o migración puede comenzar.
Consideraciones sobre la zona de aterrizaje de Azure
Antes de implementar los grupos de roles, se debe crear una zona de aterrizaje en la región de Azure necesaria
que permita la implementación de cada rol. Todas las zonas de aterrizaje asignadas deben evaluarse con
respecto a los requisitos de revisión de la zona de aterrizaje.
Si la zona de aterrizaje de Azure asignada no cumple los requisitos, debe agregarse un ámbito cada vez que se
realice cualquier modificación en el entorno.
Consideraciones sobre las aplicaciones y el escritorio
Algunos roles pueden tener cierta dependencia de las soluciones heredadas, que no son compatibles con
Windows 10 Enterprise multisesión. En ese caso, algunos roles pueden requerir escritorios dedicados. Es posible
que esta dependencia no se detecte hasta que se realicen la implementación y las pruebas.
Si se detecta en una fase tardía del proceso, se deben asignar las futuras iteraciones a la modernización o
migración de la aplicación heredada para reducir el costo a largo plazo de la experiencia de escritorio. Tanto la
prioridad de estas futuras iteraciones como su realización se establecerán en función del impacto general de los
precios de modernización, frente al costo adicional asociado a los escritorios dedicados. Esta priorización no
debe afectar a las iteraciones en curso para evitar interrupciones en las canalizaciones y la obtención de
resultados empresariales.
Algunas aplicaciones pueden requerir corrección, modernización o migración a Azure para obtener la
experiencia del usuario final que se desea. Es probable que esos cambios se realicen después de la publicación.
Como alternativa, si la latencia del escritorio puede afectar a las funciones empresariales, los cambios en la
aplicación pueden crear dependencias de bloqueo para la migración de algunos roles.
Consideraciones sobre los perfiles de usuario
En el ámbito inicial se presupone que usa un contenedor de perfiles de usuario de FSLogix que se encuentra en
una máquina virtual.
Puede usar Azure NetApp Files para hospedar perfiles de usuario. Sin embargo, para ello, necesitará varios
pasos adicionales en el ámbito, por ejemplo:
Por instancia de NetApp: configure los archivos, volúmenes y conexiones de Active Directory de NetApp.
Por host o rol: configure FSLogix en las máquinas virtuales del host de sesión.
Por usuario: asigne usuarios a la sesión del host.
También puede usar Azure Files para hospedar perfiles de usuario. Sin embargo, para ello, necesitará varios
pasos adicionales en el ámbito, por ejemplo:
Por instancia de Azure Files: configure la cuenta de almacenamiento, el tipo de disco y la conexión de
Active Directory (también se admite Active Directory Domain Services [AD DS]), asigne acceso mediante el
control de acceso basado en rol de Azure a un grupo de usuarios de Active Directory, aplique permisos de
New Technology File System y obtenga la clave de acceso de la cuenta de almacenamiento.
Por host o rol: configure FSLogix en las máquinas virtuales del host de sesión.
Por usuario: asigne usuarios a la sesión del host.
Es posible que los perfiles de usuario de algunos roles o usuarios también requieran un trabajo de migración de
datos, lo que puede retrasar la migración de roles concretos hasta que se puedan corregir los perfiles de usuario
en la versión local de Active Directory o en los escritorios de usuario individuales; este retraso podría afectar de
manera significativa al ámbito fuera del escenario de Windows Virtual Desktop. Una vez solucionado esto, el
ámbito inicial y los enfoques anteriores se pueden reanudar.
Implementación o migración de Windows Virtual Desktop

Una vez que se han tenido en cuenta todas las consideraciones en el ámbito de producción de la migración o
implementación de Windows Virtual Desktop, el proceso puede comenzar. Con una cadencia iterativa, el equipo
de adopción implementará ahora los grupos de hosts, las aplicaciones y los perfiles de usuario. Tras finalizar
esta fase, puede comenzar el trabajo posterior a la implementación, es decir, las pruebas y la incorporación de
usuarios.
Pasos siguientes
Tareas posteriores a la implementación de Windows
Virtual Desktop
El proceso de lanzamiento tras la migración o la implementación de las instancias de Windows Virtual Desktop
es relativamente sencillo. Este proceso refleja el que se sigue durante la prueba de concepto de Windows Virtual
Desktop:
pruebe el rendimiento y la latencia de los grupos de aplicaciones y los escritorios implementados para
realizar un muestreo de los usuarios.
Incorpore usuarios finales para enseñarles a conectarse mediante el:
Cliente de escritorio de Windows
Cliente web
Cliente de Android
Cliente de macOS
Cliente de iOS
Posterior a la implementación
Una vez finalizado el lanzamiento, es habitual agregar operaciones de registro y diagnósticos para que Windows
Virtual Desktop funcione mejor. También es típico que los equipos de operaciones incorporen los hosts
agrupados y las máquinas virtuales de escritorio a los procedimientos recomendados de administración de
servidores de Azure para administrar los informes, la aplicación de revisiones y las configuraciones de
continuidad empresarial y recuperación ante desastres.
Aunque escapa del ámbito de este escenario de migración, el proceso de lanzamiento puede exponer la
necesidad de migrar cargas de trabajo adicionales a Azure durante las posteriores iteraciones de la migración. Si
no ha configurado Microsoft 365 ni Azure Active Directory, el equipo de adopción de la nube podría incorporar
esos servicios después del lanzamiento de los escenarios de escritorio. En el caso de un modelo de
funcionamiento híbrido, los equipos de operaciones también podrían optar por integrar Intune, System Center u
otras herramientas de administración de la configuración para mejorar las operaciones, el cumplimiento y la
seguridad.
Pasos siguientes
Finalizada la migración de Windows Virtual Desktop, el equipo de adopción de la nube puede comenzar la
siguiente migración específica del escenario. Por otra parte, esta serie de artículos se puede usar de nuevo para
guiar la siguiente migración o implementación de Windows Virtual Desktop si se van a migrar más escritorios.
Planeamiento de la migración o implementación de Windows Virtual Desktop
Procedimientos recomendados de migración de
SQL Server para Azure
La migración de SQL Server a Azure puede acelerar la metodología estándar que se describe en el Marco de
adopción Microsoft Cloud. El proceso se muestra en el diagrama siguiente.
Figura 1
En la tabla de contenido de la izquierda se describen los procedimientos recomendados que pueden guiar la
ejecución de la migración de SQL Server. Puede realizar la migración mediante la guía de migración de
Azure Database, Azure Database Migration Service u otras herramientas. Marque esta página para tener una
referencia rápida a la lista completa de procedimientos recomendados.
Azure Stack: una opción estratégica para ejecutar
Azure en cualquier centro de datos
Microsoft adopta el enfoque de dar prioridad a la nube para el almacenamiento de datos y las aplicaciones. La
prioridad es trasladar las aplicaciones y los datos a una o varias de las nubes de hiperescala, lo que incluye la
opción de Azure global o una nube regional específica soberana como Azure Alemania o Azure Government.
Azure Stack Hub actúa como otra instancia de una nube soberana, independientemente de que lo usen los
clientes en sus centros de datos o que se consuma a través de un proveedor de servicios en la nube. Sin
embargo, Azure Stack Hub no es una nube de hiperescala y Microsoft no publica ni da soporte a contratos de
nivel de servicio para Azure Stack Hub.
Descripción del recorrido en la nube

Cada organización tiene un recorrido exclusivo hacia la nube, y dicho recorrido depende de su historial,
características específicas del negocio, cultura y, quizás lo más importante, su punto de partida. Su recorrido
proporciona muchas opciones, características y funcionalidades. También presenta oportunidades para mejorar
el gobierno y las operaciones existentes, implementar otras nuevas e incluso rediseñar sus aplicaciones para
aprovechar las arquitecturas en la nube.
El recorrido de su organización podría identificar las claras ventajas que supone usar la nube como parte de su
estrategia empresarial y de TI. Sin embargo, su recorrido también podría identificar motivos igualmente
poderosos para mantener la nube en el centro de datos existente, al menos por el momento. Si se enfrenta a
estas dos motivaciones contradictorias, no es necesario que elija. En esencia, Azure Stack Hub es una
infraestructura como servicio (IaaS). También proporciona servicios de plataforma como servicio (PaaS) que le
permiten ejecutar un subconjunto de servicios de Azure en su propio centro de datos.
Azure Stack Hub en su estrategia

Azure Stack Hub proporciona un enfoque alternativo a la migración de las aplicaciones existentes que se
ejecutan en servidores físicos o en plataformas de virtualización existentes. Si estas cargas de trabajo se mueven
a un entorno de IaaS de implementación de Azure Stack Hub, los equipos se pueden beneficiar de operaciones
más fluidas, autoservicio de implementaciones, configuraciones de hardware estandarizadas y coherencia de
Azure. El uso de Azure Stack Hub para apoyar la modernización o innovación permite que los equipos preparen
sus aplicaciones y cargas de trabajo para que aproveche la nube al máximo.
Si sigue un procedimiento coherente de adopción de la nube en Azure y Azure Stack Hub, podrá aplicar los
mismos modelos de gobernanza y de operaciones a los recursos en la nube pública o en su propio centro de
datos. Azure Stack Hub usa el mismo modelo de Azure Resource Manager que Azure, lo que permite una
visualización sencilla de sus soluciones en un único panel.
Comparación de Azure con Azure Stack Hub

Hay varias diferencias entre Azure y Azure Stack Hub. Algunas de ellas se ven a primera vista, mientras que otras
no se pueden ver hasta una fase tardía del ciclo de implementación. Tenga en cuenta las siguientes diferencias:
Azure ofrece una capacidad prácticamente ilimitada. Azure Stack Hub se basa en el hardware físico del centro
de datos, lo cual conduce a limitaciones de capacidad.
Es posible que tanto las versiones de las API como los mecanismos de autenticación de Azure sean un poco
diferentes de los de Azure Stack Hub.
Azure Stack Hub difiere en quién opera la nube, lo cual afecta al nivel de las operaciones de carga de trabajo.
Tenga en cuenta en qué parte del servicio Azure Stack Hub se ejecuta el operador de este, ya que eso
determina si el cliente llama a una PaaS de servicio o a un software como servicio (SaaS).
Se tratarán otras diferencias en otros artículos de Azure Stack Hub en varios momentos del ciclo de vida de
Pasos siguientes
Planeamiento de la migración de Azure Stack Hub
Preparación del entorno
Evaluación de las cargas de trabajo de Azure Stack Hub
Implementación de las cargas de trabajo en Azure Stack Hub
Gobernanza de Azure Stack Hub
Administración de Azure Stack Hub
Planeamiento de la migración a Azure Stack Hub
En este artículo se da por supuesto que ha revisado cómo integrar Azure Stack en su estrategia de nube y que el
recorrido se alinea con los ejemplos del artículo.
Antes de pasar directamente a los trabajos de migración de la organización, es importante establecer
apropiadamente las expectativas sobre Azure y Azure Stack Hub. Esto ayuda a evitar que surjan problemas o
contratiempos en fases posteriores del proyecto. La clave para una implementación correcta es saber
perfectamente cuándo usar Azure y cuándo Azure Stack Hub.
Alineación del patrimonio digital

La alineación del patrimonio digital de la organización comienza por unas preguntas sencillas tras la
racionalización del patrimonio digital.
¿Por qué motivo mantiene las aplicaciones y los datos en un entorno local? Por ejemplo, por requisitos
normativos, por la importancia de los datos o por las necesidades de cumplimiento.
¿Cuáles son los requisitos legales o de cumplimiento concretos que más afectan la decisión de permanencia
en el centro de datos?
¿Cómo va a afectar la privacidad de los datos a la migración de estos?
¿Se define la migración como un recorrido de modernización?
En caso afirmativo, ¿ha definido los pasos siguientes y los objetivos necesarios después de la migración?
¿Cuáles son el contrato de nivel de servicio, el objetivo de punto de recuperación, el objetivo de tiempo de
recuperación y los requisitos de disponibilidad?
Con algunas cargas de trabajo, la respuesta a estas preguntas fomentará conversaciones sobre el valor de Azure
frente a Azure Stack Hub para esa carga de trabajo concreta.
Procedimientos recomendados de evaluación

Con este procedimiento recomendado de evaluación del patrimonio digital con Azure Migrate puede acelerar la
evaluación y la alineación de las cargas de trabajo y los recursos de su patrimonio digital. Este procedimiento
recomendado proporciona una visión general de toda la cartera de TI. También ayuda a identificar los requisitos
técnicos de capacidad, escala y configuración para guiar la migración.
Con los datos de evaluación adecuados, el equipo de adopción de la nube puede tomar decisiones más
inteligentes y establecer prioridades más claras al evaluar las opciones de las plataformas en la nube pública o
privada de Azure.
Procedimientos recomendados de planeamiento

Los siguientes recursos pueden ayudar a su equipo a entender las diferencias entre Azure y Azure Stack Hub:
Introducción y hoja de ruta de Azure Stack
Planificación de la capacidad de Azure Stack
Tutorial sobre la integración del centro de datos de Azure Stack Hub
Características de la máquina virtual de Azure Stack
Cuando sepa cuál es la mejor plataforma para cada carga de trabajo, puede integrar esas decisiones en un plan
de adopción de la nube para administrar las migraciones de la nube pública y privada como un trabajo alineado.
Pasos siguientes
Preparación del entorno de nube para la migración de Azure Stack Hub
Preparación del entorno de nube para la migración
de Azure Stack Hub
En este artículo se da por supuesto que ha decidido integrar Azure Stack en su estrategia de nube y ha
desarrollado un plan de para la migración de Azure Stack Hub.
Evalúe primero las dependencias de infraestructura que se deben abordar:
Identidad
Conectividad
Seguridad
Cifrado
Configuración del entorno híbrido

En un entorno híbrido, algunas partes de la cartera de TI se encuentran en la nube pública de Azure y otras, en la
nube privada de Azure Stack Hub. Para desarrollar este tipo de entorno, primero se configuran algunos
elementos básicos en la nube pública. Para empezar a establecer zonas de aterrizaje en la nube pública, consulte
Asegúrese de que el entorno está preparado para el plan de adopción de la nube.
Conexiones de la zona de aterrizaje y la plataforma en la nube : Durante el proceso, asegúrese de que
tiene una conexión de red estable entre el centro de datos actual y Azure. Una vez establecida la conexión de red,
pruebe la latencia, el ancho de banda y la confiabilidad de la conexión con Azure.
Gobernanza y operaciones : Al migrar a ambas nubes, deberá tomar algunas decisiones tempranas que
afectarán al entorno. Con los procedimientos recomendados se compila mediante operaciones nativas de la
nube y herramientas de gobernanza que se ejecutan en la nube pública. Este enfoque reduce el costo de la
ejecución de sistemas caros en el centro de datos o el consumo de la capacidad en la implementación de Azure
Stack Hub. Al migrar a cualquiera de las dos nubes, tendrá que decidir si desea implementar los procedimientos
recomendados o seguir usando los sistemas existentes para las operaciones, la gobernanza y la administración
de los cambios.
Entorno de nube privada

Si decide usar solo la versión de nube privada de Azure, una implementación de Azure Stack Hub, tendrá que
tener en cuenta los mismos puntos de decisión:
Gobernanza y operaciones en el entorno local : El procedimiento recomendado todavía sugiere el uso de
las operaciones nativas en la nube y las herramientas de gobernanza que se encuentran en la versión en la nube
pública de Azure. Es importante evaluar pronto ese procedimiento recomendado y decidir si se aplica a su
escenario.
Conexiones de la zona de aterrizaje y la plataforma en la nube : Si las migraciones de cargas de trabajo
van a residir en una implementación de Azure Stack Hub, es importante documentar y probar la latencia, el
ancho de banda y la confiabilidad de las rutas de red entre los usuarios finales y el dispositivo de Azure Stack.
Pasos siguientes
Evaluación de cargas de trabajo para la migración
de Azure Stack Hub
En este artículo se da por supuesto que ha decidido integrar Azure Stack en su estrategia de nube, que ha
desarrollado un plan para la migración de Azure Stack Hub y que su entorno está preparado para la migración.
Durante la racionalización del patrimonio digital de la organización en la metodología de planeamiento, se ha
detectado e inventariado cada carga de trabajo y se han tomado decisiones iniciales basadas en datos
cuantitativos. Antes de la implementación de cada carga de trabajo, es importante validar los datos y las
decisiones con datos cualitativos.
Ubicación
El primer punto de datos que se debe tener en cuenta es la selección de ubicación. Es decir, ¿se migrará esta
carga a su nube pública, su nube privada o a cualquier otra plataforma en la nube, como una nube soberana o el
entorno de Azure del proveedor de servicios?
La información de cada una de las secciones siguientes puede ayudar a validar las decisiones sobre la selección
de ubicación. La información también ayuda a exponer los datos útiles durante la implementación de las cargas
de trabajo.
Valor de la parte interesada

Evalúe el valor que supone la migración de esta carga de trabajo con las partes interesadas de la empresa y de
TI:
Menos fricción: enfoque a corto plazo, viabilidad limitada a largo plazo.
Más fricción: inversión a largo plazo, más fácil de iterar y continuar la modernización.
Un equilibrio entre ambas opciones.
Gobernanza, riesgo y cumplimiento

Evalúe el impacto de los requisitos legales, de cumplimiento y de privacidad:
¿Qué datos pueden residir en Azure y cuáles deben permanecer en un entorno local?
¿Quién puede administrar la plataforma subyacente?
¿Dependen los datos de la ubicación?
¿Hay fechas de expiración para almacenar los datos?
Métricas correctas
Determine las métricas correctas y las tolerancias de disponibilidad:
Rendimiento
Disponibilidad
Resistencia
Enfoque con implementación o migración
Licencias
Evalúe el impacto de las licencias y del soporte técnico:
¿Existen restricciones en las licencias de productos que limiten la transformación?
¿Son compatibles la aplicación o el conjunto de datos con el nuevo entorno?
¿Hay proveedores de software de terceros que necesiten proporcionar instrucciones de soporte técnico?
Requisitos de operaciones
Evite la duplicación de trabajos y optimice los Acuerdos de Nivel de Servicio mediante el examen de la
correlación entre servicios en la nube administrados por TI y servicios específicos de la aplicación.
Tenga en cuenta la automatización necesaria para orquestar el aprovisionamiento de servicios durante la
implementación y la migración de aplicaciones.
Para ayudar a cumplir los requisitos operativos, tenga en cuenta los servicios de escalabilidad y
disponibilidad, como el pago por uso, los conjuntos de disponibilidad, los conjuntos de escalado de
máquinas virtuales, los adaptadores de red y la capacidad de agregar y cambiar el tamaño tanto de las VM y
los discos.
Supervisión
Supervise el mantenimiento del sistema, y el estado y el rendimiento operativos mediante métricas bien
definidas que forman la base de los Acuerdos de Nivel de Servicio que ofrece a los usuarios finales.
Compruebe la seguridad y el cumplimiento, y evalúe hasta qué punto el entorno de la nube cumple los
requisitos legales y de cumplimiento impuestos por la aplicación.
¿Cuáles son los procesos para la copia de seguridad o restauración y la replicación o conmutación por error?
Busque los servicios de protección de datos para la infraestructura como servicio, la plataforma como
servicio y los recursos de software como servicio.
Incorpore varios proveedores, tecnologías y funcionalidades para lograr una estrategia de protección
completa.
Pasos siguientes
Implementación de cargas de trabajo en Azure
Stack Hub
Con Azure Stack, su organización puede ejecutar su propia instancia de Azure en su centro de datos. Las
organizaciones incluyen Azure Stack como parte de su estrategia en la nube porque les ayuda a controlar
situaciones en las que la nube pública no les serviría. Las tres razones más comunes para usar Azure Stack son:
Conectividad de red inestable a la nube pública.
Requisitos normativos o contractuales.
Sistemas de back-end que no se pueden exponer a Internet.
Implementación de una infraestructura como servicio

Independientemente del motivo por el que se realice, la implementación de una infraestructura como servicio
en Azure Stack Hub es similar a cualquier otra implementación de IaaS. A menudo, los usuarios piensan en la
infraestructura como servicio como en máquinas virtuales, pero es algo más. Cuando se implementa una
máquina virtual en Azure o Azure Stack, esta viene con una red definida por software que incluye un sistema de
nombres de dominio, direcciones IP públicas y reglas de firewall (también denominadas grupos de seguridad de
red), entre otras muchas funcionalidades. Con la implementación de las máquinas virtuales también se crean
discos para ellas en el almacenamiento definido por software mediante Azure Blob Storage.
Para obtener instrucciones más detalladas sobre la implementación de máquinas virtuales en Azure Stack,
consulte la introducción al proceso de Azure Stack.
Implementación de una plataforma como servicio

En la nube, todos los recursos de una plataforma como servicio se ejecutan en algún tipo de servicio de
infraestructura, como, por ejemplo, una máquina virtual. Sin embargo, los servicios de Azure ofuscan esos
recursos de back-end, por lo que no es preciso administrarlos. Azure Resource Manager administra tanto la
ofuscación como la coordinación de esos recursos de la infraestructura. Es posible que haya visto un aspecto de
Resource Manager al realizar una implementación en Azure mediante una plantilla de Azure Resource Manager.
Esas plantillas indican a Azure qué proveedor de recursos se desea invocar y cómo desea que se configuren los
recursos.
Si la nube se ejecuta en el centro de datos, es preciso que los administradores de Stack Hub estén algo
familiarizados con las capas de ofuscación. Para que los usuarios o desarrolladores puedan usar un recurso de
PaaS, el administrador de Azure Stack Hub deberá instalar previamente el proveedor de recursos desde
Marketplace. Estos proveedores de recursos permiten que la instancia de Azure Stack Hub replique la
funcionalidad del proveedor de recursos de Azure en la instancia de Stack. Para más información sobre la
implementación de proveedores de recursos de Azure Stack Hub, consulte la serie de blogs de Azure Stack IaaS.

Una vez que el administrador de Azure Stack Hub haya configurado correctamente la instancia de Stack, las
migraciones pueden seguir realizándose como lo harían en la mayoría de los trabajos de migración de Azure.
Con Azure Stack, el equipo puede ejecutar cualquiera de los siguientes tipos de migración:
Red de la cadena de bloques Ethereum
Motor de AKS
Azure Cognitive Services
Aplicación web para ASP.NET en C#
Máquina virtual Linux
Aplicaciones web de Java
Consideraciones adicionales durante la migración

Los siguientes recursos pueden ayudar a su equipo durante la migración y la modernización:
Los servicios de escalabilidad y disponibilidad, como el pago por uso, los conjuntos de disponibilidad, los
conjuntos de escalado de máquinas virtuales, los adaptadores de red y la capacidad de agregar y cambiar el
tamaño de las VM y de los discos.
La capacidad de almacenamiento, incluida la capacidad de carga y descarga, y también la de captura e
implementación de imágenes de VM.
Las plantillas de inicio rápido de Azure Stack en el repositorio de GitHub.
Las plantillas de inicio rápido de Azure en el repositorio de GitHub.
Pasos siguientes
Gobernanza de una instancia de Azure desde el
centro de datos
El control de soluciones híbridas en plataformas de nube pública y privada agrega complejidad. Como la
implementación de Azure Stack Hub es su instancia privada de Azure propia y se ejecuta en su centro de datos,
la complejidad se reduce.
Los procesos empresariales, las disciplinas y muchos de los procedimientos recomendados que se describen en
Metodología de gobernanza de Cloud Adoption Framework se pueden aplicar a la gobernanza híbrida con
Azure Stack Hub. Muchas herramientas nativas de la nube que se usan en la versión de nube pública de Azure
también se pueden utilizar en la implementación de Azure Stack Hub.
Consideraciones acerca de la gobernanza de Azure Stack Hub

La siguiente serie de blogs muestra cómo la organización puede implementar los conceptos de gobernanza en
la nube con Azure Stack Hub:
Servicios organizativos, como los grupos de recursos, el control de acceso basado en rol de Azure (RBAC de
Azure), la auditoría de cambios, los bloqueos y las etiquetas.
Servicios de seguridad, entre los que se incluyen los firewalls predeterminados, las restricciones, la
administración de parches y las actualizaciones de las máquinas virtuales, y el estado del malware.
Opciones de DevOps, como la infraestructura como código, un portal con PowerShell e interfaz de la línea de
comandos, Azure Application Insights, y la integración con Azure DevOps y Jenkins.
Cadena de herramientas de gobernanza para Azure Stack Hub

Para instrucciones sobre cómo aplicar herramientas de gobernanza nativas de la nube a entornos de Azure
Stack Hub, consulte:
Plantillas de Azure Resource Manager y Desired State Configuration
PowerShell
Azure Policy
Control de acceso basado en rol
Pasos siguientes
Administración de cargas de trabajo que se
ejecutan en Azure Stack Hub
Las operaciones y la administración de soluciones híbridas en plataformas de nube pública y privada son
complejas y pueden generar riesgos para las operaciones empresariales. Como Azure Stack Hub es la instancia
privada de Azure propia de la organización que se ejecuta en su centro de datos, el riesgo de las operaciones
híbridas se reduce de forma considerable.
Como se describe en la metodología de administración de Cloud Adoption Framework, las actividades
sugeridas de administración de operaciones se centran en la siguiente lista de responsabilidades centrales. Esas
mismas responsabilidades son válidas para los equipos de administración de operaciones que dan soporte a
Azure Stack Hub.
Inventario y visibilidad: cree un inventario de recursos en varias nubes. Desarrolle la visibilidad del estado
de ejecución de cada recurso.
Cumplimiento operativo: establezca controles y procesos para asegurarse de que todos los estados están
configurados correctamente y de que se ejecutan en un entorno bien controlado.
Protección y recuperación: asegúrese de que todos los recursos administrados están protegidos y se
pueden recuperar mediante las herramientas de administración de la línea de base.
Opciones de línea de base mejorada: evalúe las incorporaciones comunes a la línea de base que puedan
satisfacer las necesidades empresariales.
Operaciones de la plataforma: amplíe la línea de base de administración con un catálogo de servicios
bien definido y plataformas administradas centralmente.
Operaciones con cargas de trabajo: amplíe la línea de base de administración para incluir la posibilidad
de centrarse en las cargas de trabajo críticas.
Consideraciones acerca de la administración de las operaciones de

Azure Stack Hub
Algunas de las actividades de administración de operaciones estándar requieren consideraciones técnicas algo
diferentes. En los artículos siguientes se describen esas consideraciones.
Soporte del autoservicio para sus clientes, lo que incluye el diagnósticos de arranque, capturas de pantallas,
registros en serie y métricas.
Administración de invitados, que incluye las extensiones de máquina virtual, la capacidad para ejecutar
código personalizado, el inventario de software y el seguimiento de los cambios.
Continuidad empresarial a través de las copias de seguridad de máquinas virtuales y las opciones de
Pasos siguientes
Una vez que la migración de Azure Stack Hub haya alcanzado un estado operativo, puede comenzar la siguiente
iteración de migraciones mediante Azure Stack Hub u otros escenarios de migración de la nube pública de
Azure.
Planeamiento de las migraciones con Azure Stack Hub
Preparación del entorno
Soluciones de Azure Synapse Analytics
Las ofertas actuales del mercado no son suficientes para satisfacer las necesidades en continuo crecimiento de
una organización. Los entornos locales heredados, como Teradata, Netezza y Oracle Exadata, son caros, lentos
para la innovación y poco elásticos. Las organizaciones que usan sistemas locales ahora consideran la
posibilidad de aprovechar las ventajas de la nube, la infraestructura como servicio y las ofertas de plataforma
como servicio innovadoras en entornos más recientes, como Azure.
Muchas organizaciones están preparadas para llevar a cabo el paso de mover tareas costosas como el
mantenimiento de la infraestructura y el desarrollo de las plataformas a un proveedor de nube. En Microsoft
Azure, las organizaciones tienen acceso a un entorno de nube escalable, muy seguro y disponible a nivel global
que incluye Azure Synapse Analytics dentro de un ecosistema de herramientas y funcionalidades
complementarias.
Azure Synapse Analytics proporciona el mejor rendimiento de las bases de datos relacionales gracias al uso de
técnicas como el procesamiento paralelo masivo (MPP) y el almacenamiento en caché automático en memoria.
Los resultados de este enfoque pueden verse en pruebas comparativas independientes, como la ejecutada
recientemente por GigaOm, que compara Azure Synapse con otras ofertas conocidas de almacenamiento de
datos en la nube.
Las organizaciones que ya se han migrado a Azure Synapse Analytics han logrado muchas ventajas, como, por
ejemplo:
Rendimiento y relación precio/rendimiento mejorados.
Mayor agilidad y tiempo de rentabilidad menor.
Implementación de servidores y desarrollo de aplicaciones más rápidos.
Escalabilidad elástica para garantizar que solo se paga por lo que se usa.
Cumplimiento y seguridad avanzados.
Costos reducidos de almacenamiento y recuperación ante desastres.
Menor TCO general y mejor control de costos (gastos operativos).
Para aumentar estas ventajas, es necesario migrar los datos y las aplicaciones existentes a la plataforma Azure
Synapse. En muchas organizaciones, este enfoque incluye la migración de un almacenamiento de datos
existente desde una plataforma local heredada como Teradata, Netezza o Exadata. Las organizaciones necesitan
modernizar su patrimonio de datos con una oferta de análisis que tenga una buena relación precio-rendimiento,
que permita innovaciones rápidas y que sea escalable y realmente elástica. En las secciones siguientes, puede
encontrar más información sobre los procedimientos recomendadas de migración en Teradata, Netezza y
Exadata.
Pasos siguientes
Soluciones de Azure Synapse Analytics para Teradata
Soluciones de Azure Synapse Analytics para Netezza
Soluciones de Azure Synapse Analytics para Exadata
Soluciones y migración de Azure Synapse Analytics
para Teradata
De hecho, muchas están preparadas para acometer el paso de pasar las tareas costosas de almacenamiento de
datos, como mantenimiento de la infraestructura y desarrollo de la plataforma, a un proveedor de nube. Las
organizaciones buscan ahora aprovechar las innovaciones de la nube, la infraestructura como servicio y las
ofertas de plataforma como servicio en entornos más novedosos, como Azure.
Azure Synapse Analytics es un servicio de análisis ilimitado que reúne el almacenamiento de datos
empresariales y el análisis de macrodatos. Este servicio ofrece la libertad de consultar los datos a gran escala de
la manera que prefiera: a petición sin servidor o con recursos aprovisionados. Sepa qué debe planear cuando
migre un sistema de Teradata heredado a Azure Synapse.
Aunque Teradata y Azure Synapse son parecidas, ya que ambas son bases de datos SQL diseñadas para usar
técnicas de procesamiento paralelo masivo destinadas a lograr un alto rendimiento de las consultas en grandes
volúmenes de datos, presentan algunas diferencias:
Los sistemas heredados de Teradata se instalan de forma local y usan hardware propio. Azure Synapse está
basado en la nube y usa recursos de almacenamiento y proceso de Azure.
La actualización de una configuración de Teradata es una tarea importante que abarca hardware físico
adicional y una reconfiguración o volcado, y recarga de las bases de datos potencialmente prolongadas. En
Azure Synapse, los recursos de proceso y almacenamiento son independientes, por lo que se pueden escalar
o reducir verticalmente por separado y con facilidad mediante el uso de la escalabilidad elástica de Azure.
Sin un sistema físico que haya que mantener, puede pausar o cambiar el tamaño de Azure Synapse según
sea necesario para reducir el costo y el uso de recursos. En Azure, tiene acceso a un entorno de nube
escalable, muy seguro y disponible a nivel global que incluye Azure Synapse dentro de un ecosistema de
herramientas y funcionalidades complementarias.
En este artículo, se examina la migración de esquemas, con miras a obtener un rendimiento equivalente o mejor
del almacenamiento de datos y de los data marts migrados de Teradata en Azure Synapse. Se considerarán los
problemas que se aplican en concreto a la migración desde un entorno de Teradata existente.
A nivel general, el proceso de migración incluye los pasos que se enumeran en la tabla siguiente:
P REPA RA C IÓ N M IGRA C IÓ N ETA PA P O ST ERIO R A L A M IGRA C IÓ N
Definir el ámbito: ¿Qué se quiere Comience con algo pequeño y Supervise y documente todas las
migrar? sencillo. fases del proceso de migración.
Cree un inventario de los datos y Automatice siempre que sea posible. Aproveche la experiencia adquirida
procesos que se van a migrar. Use herramientas y características para generar una plantilla de cara a
Defina cualquier cambio en el integradas de Azure para reducir el migraciones futuras.
modelo de datos. trabajo de migración. Vuelva a diseñar el modelo de datos,
Identifique las mejores herramientas Migre los metadatos de tablas y si es necesario, con el rendimiento y la
y características de Azure y de terceros vistas. escalabilidad de la nueva plataforma.
que se usarán. Migre los datos históricos Pruebe las aplicaciones y
Entrene al personal en la nueva apropiados. herramientas de consulta.
plataforma desde el principio. Migre o refactorice los Realice evaluaciones comparativas y
Configure la plataforma de destino procedimientos almacenados y los optimice el rendimiento de las
de Azure. procesos empresariales. consultas.
Migre o refactorice los procesos de
carga incremental ETL/ELT.
Al migrar desde un entorno de Teradata heredado a Azure Synapse, además de los temas más generales que se
describen en la documentación de Teradata, debe tener en cuenta algunos factores más específicos.
Carga de trabajo de migración inicial

En general, los entornos heredados de Teradata han evolucionado con el tiempo para abarcar varias áreas
temáticas y cargas de trabajo mixtas. Al decidir por dónde empezar en un proyecto de migración inicial, es
razonable elegir un área que pueda:
Demostrar la viabilidad de la migración a Azure Synapse con la obtención de beneficios rápidos del nuevo
entorno.
Permitir que el personal técnico interno adquiera experiencia con nuevos procesos y herramientas de forma
que puedan usarlos para migrar otras áreas.
Crear una plantilla basada en las herramientas y los procesos actuales para usar en migraciones adicionales
desde el entorno de Teradata de origen.
Un buen candidato para una migración inicial desde un entorno de Teradata es aquel que implementa una carga
de trabajo de Power BI o análisis en lugar de una carga de trabajo de OLTP. La carga de trabajo debe tener un
modelo de datos que se pueda migrar con modificaciones mínimas, como un esquema de estrella o copo de
nieve.
En cuanto al tamaño, es importante que el volumen de datos que se migre en el ejercicio inicial sea lo
suficientemente grande como para demostrar las funcionalidades y las ventajas del entorno de Azure Synapse
en un corto espacio de tiempo. El tamaño que normalmente cumple los requisitos está comprendido entre 1 y
10 TB.
Una estrategia para el proyecto de migración inicial que minimiza el riesgo y el tiempo de implementación es
limitar el ámbito de la migración a los data marts. En Teradata, un buen ejemplo es la parte de la base de datos
OLAP de un almacenamiento de datos de Teradata. Esta estrategia es un buen punto de partida, ya que limita el
ámbito de la migración y normalmente se puede lograr en un corto espacio de tiempo.
Un ámbito de migración inicial de los data marts no aborda por sí solo cuestiones más amplias, como la
migración de datos de ETL e históricos. Estas áreas se deben abordar en fases posteriores y se debe reponer la
capa de los data marts migrados con los datos y procesos necesarios para compilarlos.
Estrategia de migración mediante lift-and-shift y por fases

Con independencia de los controladores y el ámbito que elija para la migración, puede elegir entre dos tipos
generales de migración:
Estrategia de migración mediante lift-and-shift: en esta estrategia, el modelo de datos existente
(por ejemplo, un esquema de estrella) se migra sin modificaciones a la nueva plataforma de Azure
Synapse. El énfasis se pone en minimizar el riesgo y el tiempo que se tarda en migrar mediante la
reducción del trabajo necesario para lograr las ventajas de pasarse al entorno de nube de Azure.
Esta estrategia es una buena opción para los entornos de Teradata existentes en los que se va a migrar un
único data mart y cuando los datos ya están en un esquema de estrella o copo de nieve bien diseñado.
También lo es si el paso a un entorno de nube más moderno está afectado por limitaciones de tiempo y
dinero.
Estrategia por fases que incorpora modificaciones: si el almacén heredado ha evolucionado con el
tiempo, es posible que tenga que volver a diseñar el almacenamiento de datos para mantener el
rendimiento necesario o admitir nuevos orígenes de datos, como las secuencias de IoT. La migración a
Azure Synapse para lograr las ventajas conocidas de un entorno de nube escalable se puede considerar
parte del proceso de rediseño. Este proceso podría incluir la modificación del modelo de datos
subyacente, como puede ser pasar de un modelo Inmon a un almacén de datos de Azure.
La estrategia que se recomienda es trasladar inicialmente el modelo de datos existente tal y como está a
Azure. Luego, puede aprovechar el rendimiento y la flexibilidad de los servicios de Azure para aplicar los
cambios de rediseño sin que el sistema de origen existente se vea afectado.
Ubicación de la máquina virtual para ayudar con la migración

Un enfoque opcional para migrar desde un entorno de Teradata local aprovecha el económico almacenamiento
en la nube y la escalabilidad elástica en Azure. En primer lugar, cree una instancia de Teradata en una máquina
virtual de Azure colocada con el entorno de Azure Synapse de destino. A continuación, use una utilidad de
Teradata estándar como Teradata Parallel Transporter o una herramienta de replicación de datos de terceros
como Qlik Replicate (antes Attunity) para trasladar de forma eficaz el subconjunto de tablas de Teradata que va a
migrar a la instancia de máquina virtual. Todas las tareas de migración tienen lugar en el entorno de Azure.
Este enfoque tiene varias ventajas:
Después de la replicación inicial de los datos, el sistema de origen no se ve afectado por otras tareas de
migración.
Las conocidas interfaces, herramientas y utilidades de Teradata están disponibles en el entorno de Azure.
Una vez que la migración pasa al entorno de Azure, no hay ningún posible problema con la disponibilidad
del ancho de banda de red entre el sistema de origen local y el sistema de destino en la nube.
Herramientas como Azure Data Factory pueden llamar de manera eficaz a utilidades como Teradata Parallel
Transporter para migrar datos de forma rápida y sencilla.
El proceso de migración se organiza y controla completamente desde dentro del entorno de Azure.
Migración de metadatos
Es razonable automatizar y organizar el proceso de migración mediante las funcionalidades del entorno de
Azure. Este enfoque también minimiza el impacto en el entorno de Teradata existente (que es posible que ya
funcione próximo a la capacidad plena).
Azure Data Factory es un servicio de integración de datos en la nube. Puede usar Data Factory para crear flujos
de trabajo controlados por datos en la nube a fin de organizar y automatizar tanto el movimiento como la
transformación de datos. Las canalizaciones de Data Factory pueden ingerir datos de distintos almacenes de
datos. Después, pueden procesar y transformar los datos mediante servicios de proceso, como Azure HDInsight
para Apache Hadoop y Apache Spark, Azure Data Lake Analytics y Azure Machine Learning.
Empiece por crear metadatos que muestren las tablas de datos que desea migrar junto con sus ubicaciones. A
continuación, use las funciones de Data Factory para administrar el proceso de migración.
Diferencias de diseño entre Teradata y Azure Synapse

Cuando planee la migración de un entorno de Teradata heredado a Azure Synapse, es importante tener en
cuenta las diferencias de diseño entre las dos plataformas.
Varias bases de datos frente a esquemas y bases de datos únicas
En un entorno de Teradata, es posible que tenga varias bases de datos independientes para distintas partes del
entorno general. Por ejemplo, puede haber una base de datos distinta para la ingesta de datos y las tablas de
almacenamiento provisional, otra para las tablas del almacén principal y una más para los data marts, en
ocasiones denominada capa semántica. Para procesar bases de datos dispares como canalizaciones de ETL/ELT
en Azure Synapse, podría ser necesario implementar combinaciones entre bases de datos y mover los datos
entre las bases de datos dispares.
El entorno de Azure Synapse tiene una sola base de datos. Se utilizan esquemas para separar las tablas en
grupos separados de forma lógica. Se recomienda usar una serie de esquemas en Azure Synapse para imitar las
bases de datos independientes que se migran desde Teradata.
Si se usan esquemas en el entorno de Teradata, es posible que sea necesario utilizar una nueva convención de
nomenclatura para trasladar las tablas y vistas de Teradata existentes al nuevo entorno. Por ejemplo, podría
concatenar los nombres de tabla y esquema de Teradata existentes en el nuevo nombre de tabla de Azure
Synapse y, luego, usar nombres de esquema del nuevo entorno para mantener los nombres originales de las
bases de datos dispares.
Otra opción consiste en usar vistas SQL sobre las tablas subyacentes para mantener sus estructuras lógicas. El
uso de las vistas de SQL presenta algunas posibles desventajas:
Las vistas de Azure Synapse son de solo lectura, por lo que toda actualización de los datos debe realizarse en
las tablas base subyacentes.
Si ya existen capas de vistas, agregar otra capa de vistas podría afectar al rendimiento.
Tablas
Al migrar tablas entre diferentes tecnologías, solo se mueven físicamente los datos sin procesar y los metadatos
que los describen entre los dos entornos. No se migran los elementos de base de datos, como los índices del
sistema de origen, ya que es posible que no se necesiten o que se implementen de manera diferente en el nuevo
entorno.
Sin embargo, entender dónde se han utilizado las optimizaciones de rendimiento, como los índices, en el
entorno de origen puede ser una indicación útil de dónde podría optimizarse el rendimiento en el nuevo
entorno. Por ejemplo, si se creó un indice secundario no exclusivo en el entorno de Teradata de origen, podría
llegar a la conclusión de que sería beneficioso crear un índice no agrupado en el entorno de Azure Synapse
migrado, o que el uso de otras técnicas nativas de optimización del rendimiento, como la replicación de tablas,
podría ser preferible a crear un índice similar.
Base de datos de alta disponibilidad
Teradata admite la replicación de datos entre nodos mediante la opción FALLBACK . Las filas de tabla que residen
físicamente en un nodo se replican en otro nodo dentro del sistema. Este enfoque garantiza que los datos no se
perderán si se produce un error en el nodo y proporciona la base para los escenarios de conmutación por error.
El objetivo de la arquitectura de alta disponibilidad en Azure SQL Database es garantizar que la base de datos
funcione el 99,99 % de las veces. No tiene que preocuparse del impacto de las operaciones de mantenimiento y
las interrupciones en la carga de trabajo. Azure controla automáticamente tareas de mantenimiento críticas,
como aplicación de revisiones, copias de seguridad, actualizaciones de Windows y SQL, así como eventos no
planeados, como los errores subyacentes de hardware, software o red.
Las instantáneas son una característica integrada del servicio que crea puntos de restauración en Azure
Synapse. Las instantáneas proporcionan copias de seguridad automáticas para el almacenamiento de datos en
Azure Synapse. No es necesario que habilite la funcionalidad. Actualmente, los usuarios individuales no pueden
eliminar los puntos de restauración automáticos que el servicio usa para mantener los Acuerdos de Nivel de
Servicio para la recuperación.
Azure Synapse captura las instantáneas del almacenamiento de datos a lo largo del día. Los puntos de
restauración que crea están disponibles durante siete días. El período de retención no se puede modificar. Azure
Synapse admite un objetivo de punto de recuperación de ocho horas. Puede restaurar el almacenamiento de
datos de la región primaria a partir de cualquiera de las instantáneas capturadas en los últimos siete días. Hay
disponibles otras opciones definidas por el usuario si la organización necesita copias de seguridad más
pormenorizadas.
Tipos de tabla de Teradata no admitidos
Teradata incluye compatibilidad con los tipos de tabla especiales para las series temporales y los datos
temporales. La sintaxis y algunas de las funciones de estos tipos de tabla no se admiten directamente en Azure
Synapse, pero los datos se pueden migrar a una tabla estándar con los tipos de datos necesarios e indexar o
crear las particiones correspondientes en la columna de fecha y hora.
Teradata implementa la funcionalidad de consulta temporal mediante la reescritura de consultas para agregar
filtros adicionales a una consulta temporal para limitar el rango de fechas aplicable. Si usa consultas temporales
en el entorno de origen de Teradata y desea migrarlas, debe agregar filtros a las consultas temporales
adecuadas.
El entorno de Azure también incluye características para análisis complejos en datos de series temporales a
escala mediante Azure Time Series Insights. Time Series Insights está diseñado para aplicaciones de análisis de
datos de IoT y puede ser más adecuado para ese caso de uso. Para obtener más información, consulte Azure
Time Series Insights.
Asignación de tipos de datos de Teradata
Algunos tipos de datos de Teradata no se admiten directamente en Azure Synapse Analytics. En la tabla
siguiente se muestran estos tipos de datos, junto con el enfoque recomendado para manipularlos. En la tabla, el
tipo de columna de Teradata es el tipo que se almacena en el catálogo del sistema (por ejemplo, en
DBC.ColumnsV ).
Use los metadatos de las tablas del catálogo de Teradata para decidir si alguno de estos tipos de datos se va a
migrar y posteriormente planear los recursos auxiliares en el plan de migración. Por ejemplo, puede usar una
consulta SQL como la que se encuentra en la sección siguiente para buscar cualquier aparición de tipos de datos
no admitidos que deba resolver.
Los proveedores de terceros ofrecen herramientas y servicios que pueden automatizar la migración, incluida la
asignación de tipos de datos entre plataformas. Si ya usa una herramienta ETL de terceros como Informatica o
Talend en el entorno de Teradata, puede utilizarla para implementar las transformaciones de datos necesarias.
Diferencias en la sintaxis del lenguaje de manipulación de datos de

SQL
Existen algunas diferencias entre Teradata SQL y Azure Synapse en cuanto a la sintaxis del lenguaje de
manipulación de datos de SQL que se deben tener en cuenta:
QUALIFY : Teradata admite el operador QUALIFY .
Por ejemplo:
SELECT col1 FROM tab1 WHERE col1='XYZ'
Las herramientas y servicios de terceros pueden automatizar las tareas de asignación de datos:
QUALIFY ROW_NUMBER() OVER (PARTITION by col1 ORDER BY col1) = 1;
En Azure Synapse, puede lograr el mismo resultado mediante la siguiente sintaxis:

SELECT * FROM (SELECT col1, ROW_NUMBER() OVER (PARTITION by col1 ORDER BY col1) rn FROM tab1 WHERE
c1='XYZ' ) WHERE rn = 1;
Aritmética de fecha: Azure Synapse tiene operadores como DATEADD y DATEDIFF , que puede usar en
DATE o DATETIME .
Teradata admite la resta directa en fechas:

SELECT DATE1 - DATE2 FROM ...
Sintaxis de LIKE ANY
Ejemplo:
SELECT * FROM CUSTOMER WHERE POSTCODE LIKE ANY ('CV1%', 'CV2%', CV3%') ; .
El equivalente en la sintaxis de Azure Synapse es:
SELECT * FROM CUSTOMER WHERE (POSTCODE LIKE 'CV1%') OR (POSTCODE LIKE 'CV2%') OR (POSTCODE LIKE
'CV3%') ;
En función de la configuración del sistema, las comparaciones de caracteres en Teradata pueden no

distinguir mayúsculas y minúsculas de forma predeterminada. En Azure Synapse, estas comparaciones
siempre distinguen mayúsculas y minúsculas.
Funciones, procedimientos almacenados, desencadenadores y

secuencias
Al migrar un almacenamiento de datos de un entorno heredado consolidado como Teradata, a menudo es
necesario migrar elementos que no sean tablas y vistas simples al nuevo entorno de destino. Entre los ejemplos
de elementos que no son tablas en Teradata que podrían tener que migrarse a Azure Synapse se pueden incluir
funciones, procedimientos almacenados y secuencias. Durante la fase de preparación de la migración, se debe
crear un inventario de los objetos que se van a migrar. En el plan del proyecto, defina el método para controlar
todos los objetos y asignar los recursos adecuados para su migración.
Puede que encuentre servicios en el entorno de Azure que reemplacen la funcionalidad implementada, como las
funciones o los procedimientos almacenados del entorno de Teradata. Normalmente, es más eficaz usar las
funciones integradas de Azure en lugar de volver a codificar las funciones de Teradata.
A continuación, se muestra información adicional sobre la migración de funciones, procedimientos
almacenados, desencadenadores y secuencias:
Funciones: al igual que la mayoría de los productos de base de datos, Teradata admite funciones del
sistema y funciones definidas por el usuario en una implementación de SQL. Cuando se migran
funciones comunes del sistema a otra plataforma de base de datos, como Azure Synapse, suelen estar
disponibles en el nuevo entorno y se pueden migrar sin cambios. Si las funciones del sistema tienen una
sintaxis ligeramente diferente en el nuevo entorno, normalmente se pueden automatizar los cambios
necesarios.
Es posible que haya que volver a programar funciones arbitrarias definidas por el usuario y funciones del
sistema que no tengan ningún equivalente en el nuevo entorno. Use los lenguajes que están disponibles
en el nuevo entorno. Azure Synapse usa el conocido lenguaje Transact-SQL para la implementación de
funciones definidas por el usuario.
Procedimientos almacenados: en la mayoría de los productos de base de datos modernos, se pueden
almacenar procedimientos en la base de datos. En general, un procedimiento almacenado contiene
instrucciones SQL y alguna lógica de procedimiento. También puede devolver datos o un estado.
Teradata proporciona el lenguaje de procedimiento almacenado para crear procedimientos almacenados.
Azure Synapse admite procedimientos almacenados mediante T-SQL. Si se migran los procedimientos
almacenados a Azure Synapse, se deben volver a programar mediante T-SQL.
Desencadenadores: No puede crear desencadenadores en Azure Synapse, pero puede implementar
desencadenadores en Data Factory.
Secuencias: Las secuencias de Azure synapse se controlan de forma similar a cómo se administran en
Teradata. Use columnas IDENTITY o código SQL para crear el siguiente número de secuencia en una
serie.
Metadatos y extracción de datos

Al planear cómo extraer metadatos y datos del entorno de Teradata, es necesario tener en cuenta la siguiente
información:
Generación del lenguaje de definición de datos (DDL): Es posible editar los scripts existentes de
Teradata CREATE TABLE y CREATE VIEW para crear las definiciones equivalentes, con tipos de datos
modificados, si es necesario, tal y como se describió anteriormente. En este escenario, normalmente se
deben eliminar las cláusulas específicas de Teradata adicionales (por ejemplo, FALLBACK ).
La información que especifican las definiciones actuales de tabla y de vista se mantiene en las tablas del
catálogo del sistema. Las tablas del catálogo del sistema son la mejor fuente de información, ya que es
probable que estas tablas estén actualizadas y completadas. La documentación mantenida por el usuario
podría no estar sincronizada con las definiciones de tabla actuales.
Puede acceder a la información mediante el uso de vistas en el catálogo, como DBC.ColumnsV . También
puede usar las vistas para generar las instrucciones CREATE TABLE equivalentes del lenguaje de definición
de datos para las tablas equivalentes de Azure Synapse.
Las herramientas de migración y ETL de terceros también usan la información del catálogo para lograr el
mismo resultado.
Extracción de datos
Migre los datos sin procesar desde las tablas de Teradata existentes mediante utilidades de Teradata
estándar, como BTEQ y FASTEXPORT . En un ejercicio de migración, normalmente es importante extraer los
datos de la manera más eficaz posible. Para las versiones recientes de Teradata, se recomienda Teradata
Parallel Transporter, una utilidad que usa varios flujos de FASTEXPORT paralelos para lograr el mejor
rendimiento.
Puede llamar a Teradata Parallel Transporter directamente desde Data Factory. Se recomienda este
enfoque para administrar el proceso de migración de datos, tanto si la instancia de Teradata es local
como si se copia en una máquina virtual en el entorno de Azure, como se ha descrito anteriormente.
Los formatos de datos que se recomiendan para los datos extraídos son archivos de texto delimitados
(también denominados archivos de valores separados por comas), archivos de columnas de filas
optimizadas o archivos Parquet.
Para obtener información más detallada sobre el proceso de migración de datos y ETL desde un entorno de
Teradata, consulte la documentación sobre Teradata.
Recomendaciones para la optimización del rendimiento

En lo referente a la optimización, existen algunas diferencias entre las plataformas. En la siguiente lista de
recomendaciones para la optimización del rendimiento se resaltan las diferencias de implementación de nivel
inferior entre Teradata y Azure Synapse, y las alternativas para la migración:
Opciones de distribución de datos: En Azure, puede establecer los métodos de distribución de datos
para las tablas individuales. El propósito de la funcionalidad es reducir la cantidad de datos que se
mueven entre los nodos de procesamiento cuando se ejecuta una consulta.
En el caso de las combinaciones de tabla grande con tabla grande, la distribución de hash de una o
ambas (lo ideal es que sea de ambas) tablas en las columnas de combinación garantizará que el
procesamiento de combinación se pueda realizar localmente, ya que las filas de datos que se van a
combinar ya se han colocado en el mismo nodo de procesamiento.
Azure Synapse proporciona una manera adicional de lograr combinaciones locales para combinaciones
de tablas grandes o pequeñas, a menudo denominadas tablas de dimensión o combinaciones de tablas
de hechos en un modelo de esquema de estrella. Puede replicar la tabla más pequeña en todos los nodos,
con lo que se garantiza que cualquier valor de la clave de combinación de la tabla mayor tendrá una fila
de dimensión coincidente que esté disponible localmente. La sobrecarga de replicación de la tabla de
dimensiones es relativamente baja, siempre que las tablas no sean grandes. En este caso, es preferible
usar la estrategia de distribución de hash que se ha descrito anteriormente.
Indexación de datos: Azure Synapse proporciona varias opciones de indexación que son diferentes, en
cuanto al funcionamiento y al uso, de las opciones de indexación de Teradata. Para más información
sobre las opciones de indexación en Azure Synapse, consulte Diseño de tablas en un grupo de Azure
Synapse.
Los índices existentes en el entorno de origen de Teradata pueden proporcionar indicaciones útiles de
cómo se usan los datos y cuáles son las columnas candidatas a la indexación en el entorno de Azure
Synapse.
Creación de par ticiones de datos: en un almacén de datos empresarial, las tablas de hechos pueden
contener muchos miles de millones de filas de datos. La creación de particiones es una manera de
optimizar el mantenimiento y las consultas en estas tablas. La división de las tablas en distintas partes
reduce la cantidad de datos procesados al mismo tiempo. Las particiones de una tabla se definen en la
instrucción CREATE TABLE .
En la creación de particiones, solo se puede usar un campo por tabla. El campo que se usa para la
creación de particiones suele ser un campo de fecha, ya que muchas consultas se filtran por fecha o por
un intervalo de fechas. Se puede cambiar la partición de una tabla después de la carga inicial. Para
cambiar la partición de una tabla, vuelva a crear la tabla con una nueva distribución que use la
instrucción CREATE TABLE AS SELECT . Puede encontrarse una explicación detallada de la creación de
particiones en Azure Synapse en Creación de particiones de tablas en el grupo de SQL de Synapse.
Estadísticas de tablas de datos: Puede asegurarse de que las estadísticas sobre las tablas de datos
están actualizadas mediante la incorporación de un paso COLLECT STATISTICS en trabajos de ETL/ELT o
habilitando la recopilación automática de estadísticas en la tabla.
PolyBase para la carga de datos: PolyBase es el método más eficaz que se usa para cargar grandes
cantidades de datos en un almacén. Se puede usar PolyBase para cargar datos en secuencias paralelas.
Clases de recursos para la administración de cargas de trabajo: Azure Synapse utiliza clases de
recursos para administrar las cargas de trabajo. En general, las clases de recursos grandes proporcionan
un mejor rendimiento con consultas individuales. Las clases de recursos más pequeñas proporcionan
mayores niveles de simultaneidad. Se pueden emplear vistas de administración dinámica para supervisar
el uso y garantizar que los recursos adecuados se utilicen de forma eficaz.
Pasos siguientes
Para más información sobre la implementación de una migración de Teradata, hable con su representante de
cuentas de Microsoft sobre las ofertas de migración en el entorno local.
en Netezza
Debido a que el soporte técnico de IBM para Netezza finaliza, muchas organizaciones que actualmente usan
sistemas de almacenamiento de datos de Netezza buscan aprovechar las ventajas de las ofertas de nube
innovadoras, de infraestructura como servicio y de plataforma como servicio en entornos más nuevos como
Azure. De hecho, muchas están preparadas para acometer el paso de pasar las tareas costosas, como
mantenimiento de la infraestructura y desarrollo de la plataforma, a un proveedor de nube.
Azure Synapse Analytics es un servicio de análisis ilimitado que reúne el almacenamiento de datos
empresariales y el análisis de macrodatos. Este servicio ofrece la libertad de consultar los datos a gran escala de
la manera que prefiera: a petición sin servidor o con recursos aprovisionados. Conozca lo que debe planear
cuando migre un sistema Netezza heredado a Azure Synapse.
Netezza y Azure Synapse son parecidos, ya que ambos son una base de datos SQL diseñada para usar técnicas
de procesamiento paralelo masivo destinadas a lograr un alto rendimiento de las consultas en grandes
volúmenes de datos. Sin embargo, las dos plataformas presentan algunas diferencias importantes:
Los sistemas Netezza heredados se instalan de forma local y usan hardware propio. Azure Synapse está
basado en la nube y usa recursos de almacenamiento y proceso de Azure.
La actualización de una configuración de Netezza es una tarea importante que abarca hardware físico
adicional y una reconfiguración o volcado y recarga de las bases de datos potencialmente largas. En Azure
Synapse, los recursos de almacenamiento y proceso son independientes. Puede usar la escalabilidad elástica
de Azure para escalarlos o reducirlos verticalmente de forma independiente.
Sin un sistema físico que haya que mantener, puede pausar o cambiar el tamaño de Azure Synapse según
sea necesario para reducir el costo y el uso de recursos. En Azure, tiene acceso a un entorno de nube
escalable, muy seguro y disponible a nivel global que incluye Azure Synapse dentro de un ecosistema de
herramientas y funcionalidades complementarias.
En este artículo, se examina la migración de esquemas, con miras a obtener un rendimiento equivalente o mejor
del almacenamiento de datos y de los data marts migrados de Netezza en Azure Synapse. Se considerarán los
problemas que se aplican en concreto a la migración desde un entorno de Netezza existente.
A nivel general, el proceso de migración incluye los pasos que se enumeran en la tabla siguiente:

Definir el ámbito: ¿Qué se quiere Comience con algo pequeño y Supervise y documente todas las
migrar? sencillo. fases del proceso de migración.
Cree un inventario de los datos y Automatice siempre que sea posible. Aproveche la experiencia adquirida
procesos que se van a migrar. Use herramientas y características para generar una plantilla de cara a
Defina cualquier cambio en el integradas de Azure para reducir el migraciones futuras.
modelo de datos. trabajo de migración. Vuelva a diseñar el modelo de datos,
Identifique las mejores herramientas Migre los metadatos de tablas y si es necesario, con el rendimiento y la
y características de Azure y de terceros vistas. escalabilidad de la nueva plataforma.
que se usarán. Migre los datos históricos Pruebe las aplicaciones y
Entrene al personal en la nueva apropiados. herramientas de consulta.
plataforma desde el principio. Migre o refactorice los Realice evaluaciones comparativas y
Configure la plataforma de destino procedimientos almacenados y los optimice el rendimiento de las
de Azure. procesos empresariales. consultas.
Migre o refactorice los procesos de
carga incremental ETL o ELT.
Al migrar de un entorno de Netezza heredado a Azure Synapse, además de los temas más generales que se
describen en la documentación de Netezza, debe tener en cuenta algunos factores específicos.
Carga de trabajo de migración inicial

En general, los entornos heredados de Netezza han evolucionado con el tiempo para abarcar varias áreas
temáticas y cargas de trabajo mixtas. Al decidir por dónde empezar en un proyecto de migración inicial, es
razonable elegir un área que pueda:
Demostrar la viabilidad de la migración a Azure Synapse con la obtención de beneficios rápidos del nuevo
entorno.
Permitir que el personal técnico interno adquiera experiencia con nuevos procesos y herramientas de forma
que puedan usarlos para migrar otras áreas.
Crear una plantilla basada en las herramientas y los procesos actuales para usar en migraciones adicionales
desde el entorno de Netezza de origen.
Un buen candidato para una migración inicial desde un entorno de Netezza que admita estos objetivos es
normalmente aquel que implementa una carga de trabajo de Power BI/Analytics en lugar de una carga de
trabajo OLTP. La carga de trabajo debe tener un modelo de datos que se pueda migrar con modificaciones
mínimas, como un esquema de estrella o copo de nieve.
En cuanto al tamaño, es importante que el volumen de datos que se migre en el ejercicio inicial sea lo
suficientemente grande como para demostrar las funcionalidades y las ventajas del entorno de Azure Synapse
en un corto espacio de tiempo. El tamaño que normalmente cumple los requisitos está comprendido entre 1 y
10 TB.
Una estrategia para el proyecto de migración inicial que minimiza el riesgo y el tiempo de implementación es
limitar el ámbito de la migración a los data marts. Esta estrategia es un buen punto de partida, ya que limita
claramente el ámbito de la migración y normalmente se puede lograr en un corto espacio de tiempo. La
migración inicial de los data marts no solo aborda cuestiones más amplias, como la migración de datos de ETL e
históricos. Estas áreas se deben abordar en fases posteriores y se debe reponer la capa de los data marts
migrados con los datos y procesos necesarios para compilarlos.
Estrategia de migración mediante lift-and-shift y por fases

Con independencia de los controladores y el ámbito que elija para la migración, puede elegir entre dos tipos
generales de migración:
Estrategia de migración mediante lift-and-shift: en esta estrategia, el modelo de datos existente
(por ejemplo, un esquema de estrella) se migra sin modificaciones a la nueva plataforma de Azure
Synapse. Aquí, el énfasis se pone en minimizar el riesgo y el tiempo que se tarda en migrar, puesto que se
reduce el trabajo que debe realizarse para lograr las ventajas de pasarse al entorno de nube de Azure.
Esta estrategia es una buena opción para los entornos de Teradata existentes en los que se va a migrar un
único data mart y cuando los datos ya están en un esquema de estrella o copo de nieve bien diseñado.
También lo es si el paso a un entorno de nube más moderno está afectado por limitaciones de tiempo y
dinero.
Estrategia por fases que incorpora modificaciones: cuando un almacén heredado ha evolucionado
con el tiempo, es posible que tenga que volver a diseñar el almacenamiento de datos para mantener el
rendimiento necesario o admitir nuevos orígenes de datos, como las secuencias de IoT. La migración a
Azure Synapse para lograr las ventajas conocidas de un entorno de nube escalable se puede considerar
parte del proceso de rediseño. Este proceso podría incluir la modificación del modelo de datos
subyacente, como puede ser pasar de un modelo Inmon a un almacén de datos de Azure.
La estrategia que se recomienda es trasladar inicialmente el modelo de datos existente tal y como está a
Azure. Luego, puede aprovechar el rendimiento y la flexibilidad de los servicios de Azure para aplicar los
cambios de rediseño sin que el sistema de origen existente se vea afectado.
Migración de metadatos
Es razonable automatizar y organizar el proceso de migración mediante las funcionalidades del entorno de
Azure. Este enfoque también reduce el impacto en el entorno de Netezza existente (que podría estar ya próximo
a la capacidad máxima).
Azure Data Factory es un servicio de integración de datos en la nube. Puede usar Data Factory para crear flujos
de trabajo controlados por datos en la nube a fin de organizar y automatizar tanto el movimiento como la
transformación de datos. Las canalizaciones de Data Factory pueden ingerir datos de almacenes de datos
dispares y, luego, procesar y transformar los datos mediante servicios de proceso como Azure HDInsight para
Apache Hadoop y Apache Spark, Azure Data Lake Analytics y Azure Machine Learning. Para comenzar, cree
metadatos para mostrar las tablas de datos que quiere migrar, con sus ubicaciones y, luego, use las
funcionalidades de Data Factory para administrar el proceso de migración.
Diferencias de diseño entre Netezza y Azure Synapse

Cuando planee la migración de un entorno de Netezza heredado a Azure Synapse, es importante tener en
cuenta las diferencias de diseño entre las dos plataformas.
Varias bases de datos frente a esquemas y bases de datos únicas
En un entorno de Netezza, es posible que tenga varias bases de datos independientes para distintas partes del
entorno general. Por ejemplo, puede haber una base de datos distinta para la ingesta de datos y las tablas de
almacenamiento provisional, otra para las tablas del almacén principal y una más para los data marts, en
ocasiones denominada capa semántica. Para procesar bases de datos dispares como canalizaciones de ETL/ELT
en Azure Synapse, podría ser necesario implementar combinaciones entre bases de datos y mover los datos
entre las bases de datos dispares.
El entorno de Azure Synapse tiene una sola base de datos. Se utilizan esquemas para separar las tablas en
grupos separados de forma lógica. Se recomienda usar un conjunto de esquemas en la instancia de
Azure Synapse de destino para imitar las bases de datos dispares que se migran desde Netezza. Si se usan
esquemas en el entorno de Netezza, es posible que sea necesario utilizar una nueva convención de
nomenclatura para trasladar las tablas y vistas de Netezza existentes al nuevo entorno. Por ejemplo, podría
concatenar los nombres de tabla y esquema de Netezza existentes en el nuevo nombre de tabla de Azure
Synapse y, luego, usar nombres de esquema del nuevo entorno para mantener los nombres originales de las
bases de datos dispares.
Otra opción consiste en usar vistas SQL sobre las tablas subyacentes para mantener las estructuras lógicas. El
uso de las vistas de SQL presenta algunas posibles desventajas:
Las vistas de Azure Synapse son de solo lectura, por lo que toda actualización de los datos debe realizarse en
las tablas base subyacentes.
Si ya existen capas de vistas, agregar otra capa de vistas podría afectar al rendimiento.
Tablas
Al migrar tablas entre diferentes tecnologías, solo se mueven físicamente los datos sin procesar y los metadatos
que los describen entre los dos entornos. No se migran los elementos de base de datos, como los índices del
sistema de origen, ya que es posible que no se necesiten o que se implementen de manera diferente en el nuevo
entorno.
Sin embargo, entender dónde se han utilizado las optimizaciones de rendimiento, como los índices, en el
entorno de origen puede ser una indicación útil de dónde podría optimizarse el rendimiento en el nuevo
entorno. Por ejemplo, si en las consultas del entorno de Netezza de origen se suelen usar mapas de zona, podría
concluirse que sería beneficioso crear un índice no agrupado en el entorno de Azure Synapse migrado, o que el
uso de otras técnicas nativas de optimización del rendimiento, como la replicación de tabla, podría ser preferible
a crear un índice similar.
Tipos de objetos de base de datos de Netezza no admitidos
Netezza implementa algunos objetos de base de datos que no se admiten directamente en Azure Synapse. Sin
embargo, Azure Synapse ofrece métodos que pueden usarse para lograr la misma funcionalidad en el nuevo
entorno, como se describe en la lista siguiente:
Mapas de zona: en Netezza, los mapas de zona se crean y mantienen automáticamente para algunos
tipos de columna. Los mapas de zona se usan en el momento de la consulta en los siguientes tipos de
columna para restringir la cantidad de datos que se van a examinar:
Columnas INTEGER que tienen una longitud de 8 bytes o menos
Columnas temporales, como DATE , TIME y TIMESTAMP
Columnas CHAR , si forman parte de una vista materializada y se incluyen en la cláusula ORDER BY
Se puede averiguar qué columnas tienen mapas de zona mediante la utilidad nz_zonemap. La utilidad
forma parte del kit de herramientas de NZ.
Azure Synapse no usa mapas de zona, pero se pueden obtener resultados similares con los tipos de
índice definidos por el usuario o las particiones.
Tablas base agrupadas (CBT): en Netezza, la tabla CBT más común es la tabla de hechos, que tiene
miles de millones de registros. El examen de una tabla de gran tamaño requiere mucho tiempo de
procesamiento, ya que podría ser necesario realizar un recorrido de tabla completo para obtener los
registros de interés. Mediante la organización de los registros en tablas CBT restrictivas, Netezza puede
agruparlos en las mismas extensiones o en otras próximas. El proceso también crea mapas de zona que
mejoran el rendimiento al reducir la cantidad de datos que se examinan.
En Azure Synapse, se puede obtener un resultado similar mediante la creación de particiones o con otros
tipos de índices.
Vistas materializadas: Netezza recomienda que los usuarios creen una o varias vistas materializadas
en tablas grandes que tengan muchas columnas y en las que solo se usen con frecuencia unas cuantas
columnas en las consultas. El sistema mantiene las vistas materializadas automáticamente cuando se
actualizan los datos de la tabla base.
Actualmente, Microsoft ofrece compatibilidad en versión preliminar con vistas materializadas, con la
misma funcionalidad que Netezza, en Azure Synapse.
Asignación de tipos de datos: la mayoría de los tipos de datos de Netezza tienen un equivalente
directo en Azure Synapse. En la tabla siguiente se muestran los tipos de datos y las estrategias
recomendadas para asignarlos.
Algunos proveedores de terceros ofrecen herramientas y servicios que pueden automatizar las tareas de
migración, incluida la asignación de tipos de datos. Si ya se usa una herramienta ETL de terceros como
Informatica o Talend en el entorno de Netezza, se puede emplear para implementar las transformaciones
de datos necesarias.
Sintaxis del lenguaje de manipulación de datos (DML) de SQL : se deben tener en cuenta algunas
diferencias entre la sintaxis DML de SQL de Netezza SQL y Azure Synapse.
Estas son algunas funciones clave y en qué se diferencian:
STRPOS: en Netezza, la función STRPOS devuelve la posición de una subcadena dentro de una
cadena. El equivalente en Azure Synapse es la función CHARINDEX , y se invierte el orden de los
argumentos.
En Netezza:
SELECT STRPOS('abcdef', 'def') ...
se reemplaza por el código siguiente en Azure Synapse:

SELECT CHARINDEX('def', 'abcdef') ...
AGE: Netezza admite el operador AGE para proporcionar el intervalo entre dos valores
temporales (por ejemplo, marcas de tiempo y fechas). Por ejemplo:
SELECT AGE ('23-03-1956', '01-01-2019') FROM ...
El mismo resultado se puede obtener en Azure Synapse mediante DATEDIFF (tenga en cuenta la
secuencia de representación de fecha):
SELECT DATEDIFF(day, '1956-03-23', '2019-01-01') FROM ...
NOW() : Netezza usa NOW() para representar CURRENT_TIMESTAMP en Azure Synapse.
Funciones, procedimientos almacenados y secuencias

Al migrar un almacenamiento de datos de un entorno heredado consolidado como Netezza, a menudo es
necesario migrar elementos que no sean tablas y vistas simples al nuevo entorno de destino. Ejemplos de
elementos que no son tablas en Netezza que podrían tener que migrarse a Azure Synapse son funciones,
procedimientos almacenados y secuencias. Durante la fase de preparación de la migración, se debe crear un
inventario de los objetos que se van a migrar. En el plan del proyecto, defina el método para controlar todos los
objetos y asignar los recursos adecuados para su migración.
Puede que encuentre servicios en el entorno de Azure que reemplacen la funcionalidad implementada, como las
funciones o los procedimientos almacenados del entorno de Netezza. Normalmente, es más eficaz usar las
funciones integradas de Azure en lugar de volver a programar las funciones de Netezza.
Además, los proveedores de terceros ofrecen herramientas y servicios que pueden automatizar la migración de
funciones, procedimientos almacenados y secuencias desde Netezza. Entre los ejemplos se incluyen Qlik
(anteriormente Attunity) y WhereScape.
A continuación, se muestra información adicional sobre la migración de funciones, procedimientos almacenados
y secuencias:
Funciones: al igual que la mayoría de los productos de base de datos, Netezza admite funciones del
sistema y funciones definidas por el usuario dentro de la implementación de SQL. Cuando se migran
funciones comunes del sistema a otra plataforma de base de datos, como Azure Synapse, generalmente
están disponibles en el nuevo entorno y se pueden migrar sin cambios. Si las funciones del sistema
tienen una sintaxis ligeramente diferente en el nuevo entorno, normalmente se pueden automatizar los
cambios necesarios.
Es posible que haya que volver a programar funciones arbitrarias definidas por el usuario y funciones del
sistema que no tengan ningún equivalente en el nuevo entorno. Use los lenguajes que están disponibles
en el nuevo entorno. Las funciones definidas por el usuario de Netezza se programan mediante nzLua o
C++. Azure Synapse usa el conocido lenguaje Transact-SQL para la implementación de funciones
definidas por el usuario.
Procedimientos almacenados: en la mayoría de los productos de base de datos modernos, se pueden
almacenar procedimientos en la base de datos. En general, un procedimiento almacenado contiene
instrucciones SQL y alguna lógica de procedimiento. También puede devolver datos o un estado.
Netezza proporciona el lenguaje NZPLSQL basado en PL/pgSQL para los procedimientos almacenados.
Azure Synapse admite procedimientos almacenados mediante T-SQL. Si se migran los procedimientos
almacenados a Azure Synapse, se deben volver a programar mediante T-SQL.
Secuencias: en Netezza, una secuencia es un objeto de base de datos con nombre que se crea a través
de una instrucción CREATE SEQUENCE . Los objetos pueden proporcionar el valor único a través del método
NEXT() . Se pueden usar valores para generar números únicos como valores de clave suplente para los
valores de clave principal.
Azure Synapse no admite CREATE SEQUENCE . En Azure Synapse, las secuencias se administran mediante
columnas de identidad o código SQL para crear el siguiente número de secuencia de una serie.
Metadatos y extracción de datos

Al planear cómo extraer metadatos y datos del entorno de Netezza, es necesario tener en cuenta la siguiente
información:
Generación del lenguaje de definición de datos (DDL): es posible editar los scripts CREATE TABLE y
CREATE VIEW existentes de Netezza para crear las definiciones equivalentes, con tipos de datos
modificados, si es necesario, tal y como se describió anteriormente. Esta tarea normalmente conlleva la
eliminación o modificación de las cláusulas específicas de Netezza, como ORGANIZE ON .
En Netezza, la información que especifica las definiciones actuales de tabla y vista se mantiene en tablas
del catálogo del sistema. Las tablas del catálogo del sistema son la mejor fuente de información, ya que
es probable que estas tablas estén actualizadas y completadas. La documentación mantenida por el
usuario podría no estar sincronizada con las definiciones de tabla actuales.
Se puede tener acceso a las tablas del catálogo del sistema en Netezza con una utilidad como nz_ddl_table. Se
pueden usar las tablas para generar instrucciones DDL CREATE TABLE , que luego se pueden editar obtener tablas
equivalentes en Azure Synapse. Las herramientas ETL y de migración de terceros también usan la información
del catálogo para lograr el mismo resultado.
Extracción de datos: se pueden extraer datos sin procesar para migrarlos de una tabla de Netezza
existente a un archivo plano y delimitado mediante utilidades estándar de Netezza, como nzsql y
nzunload, y por medio de tablas externas. Comprima los archivos mediante Gzip y, luego, use AzCopy o
un servicio de transporte de datos de Azure, como Azure Data Box, para cargar los archivos en Azure
Blob Storage.
Durante un ejercicio de migración, es importante extraer los datos de la manera más eficaz posible. La
estrategia recomendada para Netezza es usar tablas externas, que también es el método más rápido. Para
maximizar el rendimiento de la extracción de datos, se pueden realizar varias extracciones en paralelo.
A continuación, se muestra un ejemplo sencillo de una extracción de tablas externas:
CREATE EXTERNAL TABLE '/tmp/export_tab1.CSV' USING (DELIM ',') AS SELECT * from <TABLE-NAME>;
Si hay suficiente ancho de banda de red, los datos se pueden extraer directamente de un sistema de Netezza
local en tablas de Azure Synapse o en almacenamiento de datos de Azure mediante procesos de Data Factory o
productos ETL o de migración de datos de terceros.
Los formatos de datos recomendados para los datos extraídos son archivos de texto delimitados (también
denominados valores separados por comas), archivos de columnas de filas optimizadas o archivos Parquet.
Se puede encontrar información más detallada sobre el proceso de migración de datos y ETL desde un entorno
de Netezza en la documentación de Netezza sobre ETL de migración de datos y carga.
Recomendaciones para la optimización del rendimiento

Al pasar a Azure Synapse desde un entorno de Netezza, muchos de los conceptos de optimización del
rendimiento que se usan le resultarán familiares.
Por ejemplo, estos conceptos son iguales en ambos entornos:
La distribución de datos ubica conjuntamente los datos que se van a combinar en el mismo nodo de
procesamiento.
El uso de tipos de datos más pequeños en una columna determinada ahorra espacio de almacenamiento y
acelera el procesamiento de las consultas.
Comprobar que los tipos de datos de las columnas que se van a combinar sean idénticos optimizará el
procesamiento de las combinaciones al reducir la necesidad de transformar los datos para que coincidan.
Asegurarse de que las estadísticas están actualizadas ayudará al optimizador a generar el mejor plan de
ejecución.
En lo referente a la optimización, existen algunas diferencias entre las plataformas. En la siguiente lista de
recomendaciones para la optimización del rendimiento se resaltan las diferencias de implementación de nivel
inferior entre Netezza y Azure Synapse, y las alternativas para la migración:
Opciones de distribución de datos: tanto en Netezza como en Azure Synapse, se puede usar una
instrucción CREATE TABLE para especificar una definición de distribución. Use DISTRIBUTE ON en Netezza
y DISTRIBUTION = en Azure Synapse.
Azure Synapse proporciona una manera adicional de lograr combinaciones locales para combinaciones
de tablas grandes o pequeñas, a menudo denominadas tablas de dimensión o combinaciones de tablas
de hechos en un modelo de esquema de estrella. La estrategia consiste en replicar la tabla de
dimensiones más pequeña en todos los nodos, con lo que se garantiza que cualquier valor de la clave de
combinación de la tabla mayor tendrá una fila de dimensión coincidente que esté disponible localmente.
La sobrecarga de replicación de la tabla de dimensiones es relativamente baja, siempre que las tablas no
sean grandes. En este caso, es preferible usar la estrategia de distribución de hash que se ha descrito
anteriormente.
Indexación de datos: Azure Synapse proporciona varias opciones de indexación definibles por el
usuario, pero que son diferentes en cuanto al funcionamiento y el uso de los mapas de zona
administrados por el sistema de Netezza. Para más información sobre las opciones de indexación en
Azure Synapse, consulte Indexación de tablas en el grupo de SQL de Synapse.
Los mapas de zona administrados por el sistema existentes en el entorno de origen de Netezza pueden
proporcionar indicaciones útiles de cómo se usan los datos y cuáles son las columnas candidatas a la
indexación en el entorno de Azure Synapse.
Creación de par ticiones de datos: en un almacén de datos empresarial, las tablas de hechos pueden
contener muchos miles de millones de filas de datos. La creación de particiones es una manera de
optimizar el mantenimiento y las consultas en estas tablas. La división de las tablas en distintas partes
reduce la cantidad de datos procesados al mismo tiempo. Las particiones de una tabla se definen en la
instrucción CREATE TABLE .
En la creación de particiones, solo se puede usar un campo por tabla. El campo que se usa para la
creación de particiones suele ser un campo de fecha, ya que muchas consultas se filtran por fecha o por
un intervalo de fechas. Se puede cambiar la partición de una tabla después de la carga inicial. Para
cambiar la partición de una tabla, vuelva a crear la tabla con una nueva distribución que use la
instrucción CREATE TABLE AS SELECT . Puede encontrarse una explicación detallada de la creación de
particiones en Azure Synapse en Creación de particiones de tablas en el grupo de SQL de Synapse.
PolyBase para la carga de datos: PolyBase es el método más eficaz que se usa para cargar grandes
cantidades de datos en un almacén. Se puede usar PolyBase para cargar datos en secuencias paralelas.
Clases de recursos para la administración de cargas de trabajo: Azure Synapse utiliza clases de
recursos para administrar las cargas de trabajo. En general, las clases de recursos grandes proporcionan
un mejor rendimiento con consultas individuales. Las clases de recursos más pequeñas proporcionan
mayores niveles de simultaneidad. Se pueden emplear vistas de administración dinámica para supervisar
el uso y garantizar que los recursos adecuados se utilicen de forma eficaz.
Pasos siguientes
Para más información sobre la implementación de una migración de Netezza, hable con su representante de
cuentas de Microsoft sobre las ofertas de migración locales.
para un almacenamiento de datos de Oracle
Un esquema de almacenamiento de datos de Oracle difiere de Azure Synapse Analytics de varias maneras. Entre
las diferencias se incluyen las de las bases de datos, tipos de datos y diversos tipos de objetos de base de datos
de Oracle que no se admiten en Azure Synapse Analytics.
Al igual que otros sistemas de administración de bases de datos, al migrar un almacenamiento de datos de
Oracle a Azure Synapse, observará que hay varias bases de datos independientes en Oracle y una sola base de
datos en Azure Synapse. Puede que sea necesario usar una nueva convención de nomenclatura, como la
concatenación de nombres de tablas y esquemas de Oracle, para mover tablas y vistas de la base de datos
provisional del almacenamiento de datos de Oracle, la base de datos de producción y las bases de datos de data
marts a Azure Synapse.
No se admiten varios objetos de base de datos de Oracle en Azure Synapse. Entre los objetos de base de datos
que no se admiten en Azure Synapse se incluyen índices en mapas de bits de Oracle, índices basados en
funciones, índices de dominio, tablas agrupadas de Oracle, desencadenadores en el nivel de fila, tipos de datos
definidos por el usuario y procedimientos almacenados de PL/SQL. Estos objetos se pueden identificar mediante
la consulta de varias vistas y tablas del catálogo del sistema de Oracle. En algunos casos, puede usar soluciones
alternativas. Por ejemplo, se pueden usar otros tipos de índices o particiones de Azure Synapse para solucionar
los tipos de índices no admitidos en Oracle. Puede usar vistas materializadas en lugar de tablas agrupadas de
Oracle, siempre y herramientas de migración como SQL Server Migration Assistant para que Oracle pueda
traducir al menos algo de código PL/SQL.
Al migrar un esquema de almacenamiento de datos de Oracle, también debe tener en cuenta las diferencias de
los tipos de datos en las columnas. Para encontrar las columnas de los esquemas de data marts y de
almacenamiento de datos de Oracle que tengan tipos de datos que no se asignen a tipos de datos de Azure
Synapse, consulte el catálogo de Oracle. En algunos de estos casos, puede usar soluciones alternativas.
Para mantener o mejorar el rendimiento del esquema después de la migración, tenga en cuenta los mecanismos
de rendimiento, como la indexación de Oracle, que tiene actualmente en vigor. Por ejemplo, los índices en mapa
de bits que Oracle consulta con frecuencia pueden indicar que la creación de un índice no agrupado en el
esquema migrado de Azure Synapse resultaría beneficiosa.
Entre los procedimientos recomendados de Azure Synapse se incluye el uso de la distribución de datos para
ubicar conjuntamente los datos que se van a combinar en el mismo nodo de procesamiento. Otra
procedimiento recomendado en Azure Synapse es asegurarse de que los tipos de datos de las columnas que se
van a combinar sean idénticos. El uso de columnas de combinación idénticas optimiza el procesamiento de las
combinaciones mediante la reducción de la necesidad de transformar los datos para que coincidan. En Azure
Synapse, no suele ser necesario migrar todos los índices de Oracle, ya que otras características proporcionan un
alto rendimiento. Así, se pueden usar en su lugar las opciones de procesamiento de consultas en paralelo, datos
en memoria, almacenamiento en caché de conjuntos de resultados y distribución de datos para reducir la E/S.
SQL Server Migration Assistant le puede ayudar a migrar un almacenamiento de datos o un data mart de
Oracle en Azure Synapse. SQL Server Migration Assistant está diseñado para automatizar el proceso de
migración de tablas, vistas y datos desde un entorno de Oracle existente. Entre otras características, SQL Server
Migration Assistant recomienda distribuciones de datos y tipos de índices para las tablas de Azure Synapse de
destino, y aplica asignaciones de tipos de datos durante la migración. Aunque SQL Server Migration Assistant
no será la estrategia más eficaz para grandes volúmenes de datos, resulta útil en el caso de tablas más
pequeñas.
Información general sobre la migración del sistema
central
Muchas empresas y organizaciones se benefician del traslado de algunas o todas sus bases de datos,
aplicaciones y cargas de trabajo de sistema central a la nube. Azure proporciona características similares al
sistema central en el escalado de la nube sin muchos de los inconvenientes asociados a los sistemas centrales.
Normalmente, el término sistema central hace referencia a un equipo de gran tamaño, pero, actualmente, la
inmensa mayoría de los sistemas centrales implementados son servidores IBM System Z o sistemas
compatibles con enchufe IBM que ejecutan MVS, DOS, VSE, OS/390 o z/OS. Los sistemas centrales continúan
usándose en muchos sectores para ejecutar sistemas de información vitales y ocupan un lugar en situaciones
muy específicas, como entornos de TI donde se realizan una gran cantidad de transacciones y que tienen gran
volumen y tamaño.
La migración a la nube permite a las empresas modernizar su infraestructura. Con los servicios en la nube,
puede hacer que las aplicaciones de sistema central y el valor que proporcionan estén disponibles como carga
de trabajo siempre que su organización así lo necesite. Muchas cargas de trabajo pueden transferirse a Azure
con solo leves cambios en el código, como la actualización de los nombres de las bases de datos. Puede migrar
cargas de trabajo más complejas con un enfoque por fases.
La mayoría de las empresas Fortune 500 ya ejecutan Azure para sus cargas de trabajo críticas. Incentivos finales
significativos de Azure fomentan muchos proyectos de migración. Normalmente, las empresas trasladan las
cargas de trabajo de desarrollo y pruebas a Azure primero, a lo que le sigue DevOps, el correo electrónico y la
Destinatarios
Si tiene en cuenta una migración o la adición de servicios en la nube como opción para su entorno de TI, esta
guía es para usted.
Ayuda a las organizaciones de TI a iniciar la conversación sobre la migración. Puede que esté más familiarizado
con Azure y las infraestructuras basadas en la nube que con los sistemas centrales, de modo que esta guía
comienza con información general sobre el funcionamiento de los sistemas centrales y continúa con diversas
estrategias para determinar qué y cómo migrar.
Arquitectura de sistema central

En los últimos años de la década de los 50, los sistemas centrales se diseñaron como servidores de escalabilidad
vertical para ejecutar transacciones en línea de gran volumen y procesamiento por lotes. Por ello, los sistemas
centrales tienen software para formularios de transacciones en línea (a veces llamados pantallas verdes) y
sistemas de E/S de alto rendimiento para procesar ejecuciones por lotes.
Los sistemas centrales son conocidos por su alta confiabilidad y disponibilidad, así como por su capacidad de
ejecución de grandes transacciones en línea y trabajos por lotes. Una transacción deriva de un componente del
procesamiento iniciado por una sola solicitud, normalmente de un usuario en un terminal. Las transacciones
también pueden proceder de varios orígenes distintos, incluidas páginas web, estaciones de trabajo y
aplicaciones de otros sistemas de información. Una transacción también se puede desencadenar
automáticamente en un tiempo predefinido como se muestra en la figura siguiente.
Una arquitectura de sistema central IBM típica incluye estos componentes comunes:
Sistemas de front-end: los usuarios pueden iniciar las transacciones desde terminales, páginas web o
estaciones de trabajo remotas. Las aplicaciones de sistema central suelen tener interfaces de usuario
personalizadas que se pueden conservar tras la migración a Azure. Los emuladores de terminal (también
se les llama terminales de pantalla verde) se siguen usando para acceder a las aplicaciones de sistema
central.
Capa de aplicación: los sistemas centrales suelen incluir un sistema de control de información del
cliente (CICS), un conjunto de administración de transacciones inicial para el sistema central z/OS de IBM
que a menudo se usa con Information Management System (IMS) de IBM, un administrador de
transacciones basado en mensajes. Los sistemas de lotes controlan actualizaciones de datos de alto
rendimiento para grandes volúmenes de registros de cuenta.
Código: lenguajes de programación usados por sistemas centrales, incluidos COBOL, Fortran, PL/I y
Natural. El lenguaje de control de trabajos (JCL) se usa para trabajar con z/OS.
Nivel de base de datos: un sistema de administración de bases de datos (DBMS) relacionales común
para z/OS es IBM DB2. Administra estructuras de datos llamadas dbspaces que contienen una o varias
tablas y se asignan a bloques de almacenamiento de conjuntos de datos físicos llamados dbextents. Dos
componentes de base de datos importantes son el directorio que identifica ubicaciones de datos en los
bloques de almacenamiento y el registro que contiene un registro de operaciones realizadas en la base
de datos. Se admiten diversos formatos de datos de archivos planos. DB2 para z/OS suele usar conjuntos
de datos del método de acceso de almacenamiento virtual (VSAM) para almacenar los datos.
Nivel de administración: los sistemas centrales IBM incluyen software de programación como TWS-
OPC, herramientas para la administración de salida e impresión como CA-SAR y SPOOL, y un sistema de
control de código fuente para el código. El centro de control de acceso a los recursos (RACF) administra
un control de acceso seguro para z/OS. Un administrador de base de datos proporciona acceso a los
datos de la base de datos y se ejecuta en su propia partición en un entorno z/OS.
LPAR: las particiones lógicas o LPARs se usan para dividir recursos de proceso. Un sistema central físico
se particiona en varias LPARs.
z/OS: un sistema operativo de 64 bits que se usa con mayor frecuencia para los sistemas centrales IBM.
Los sistemas IBM usan un monitor de transacciones como CICS para seguir y administrar todos los aspectos de
una transacción empresarial. CICS administra el uso compartido de recursos, la integridad de datos y la
priorización de la ejecución. CICS autoriza a los usuarios, asigna recursos y pasa solicitudes de base de datos de
la aplicación a un administrador de base de datos, como IBM DB2.
Para un ajuste más preciso, CICS se usa habitualmente con IMS/TM, anteriormente IMS/Data Communications
(IMS/DC). IMS se diseñó para reducir la redundancia de datos manteniendo una sola copia de los datos.
Complementa CICS como monitor de transacciones manteniendo el estado en todo el proceso y registrando
funciones empresariales en un almacén de datos.
Operaciones del sistema central

Estas son operaciones del sistema central típicas:
En línea: entre las cargas de trabajo se incluyen el procesamiento de transacciones, la administración de
base de datos y las conexiones. Normalmente se implementan mediante los conectores z/OS, CICS e IBM
DB2.
Lote: los trabajos se ejecutan sin la interacción del usuario, normalmente de forma periódica (por
ejemplo, todos los días laborables por las mañanas). Los trabajos por lotes se pueden ejecutar en
sistemas basados en Windows o Linux mediante un emulador JCL como el software Control-M de BMC o
Micro Focus Enterprise Server Edition.
Lenguaje de control de trabajos (JCL): especifique los recursos necesarios para procesar trabajos
por lotes. JCL transmite esta información a z/OS a través de un conjunto de instrucciones de control de
trabajo. El JCL básico contiene seis tipos de instrucciones: JOB, ASSGN, DLBL, EXTENT, LIBDEF y EXEC. Un
trabajo puede contener varias instrucciones EXEC (pasos) y cada paso podría tener varias instrucciones
LIBDEF, ASSGN, DLBL y EXTENT.
Carga de programas de inicio (IPL): hace referencia a la carga de una copia del sistema operativo
desde el disco en el almacenamiento real de un procesador y su ejecución. Las IPLs se usan para
recuperarse del tiempo de inactividad. Una IPL es algo similar a arrancar el sistema operativo en
máquinas virtuales Windows o Linux.
Pasos siguientes
Mitos y verdades
Mitos y verdades del sistema central
Los sistemas centrales aparecen de en un lugar destacado de la historia de la informática y siguen siendo
viables para cargas de trabajo muy específicas. La mayoría está de acuerdo en que los sistemas centrales son
una plataforma probada, con procedimientos operativos arraigados, que los convierten en entornos de
confianza y sólidos. Hay ejecuciones de software basadas en el uso, medidas en millones de instrucciones por
segundo (MIPS), e informes extensos del uso disponibles para anulaciones.
La confiabilidad, la disponibilidad y la capacidad de procesamiento de los sistemas centrales se han encargado
de proporciones casi míticas. Para evaluar las cargas de trabajo de los sistemas centrales que son más
adecuadas para Azure, primero debe distinguir entre los mitos y la realidad.
Mito: Los sistemas centrales nunca dejan de funcionar y tienen un

mínimo de cinco nueves (99,999 %) de disponibilidad.
El hardware del sistema central y los sistemas operativos se perciben confiables y estables. Sin embargo, la
realidad es que debe programarse un tiempo de inactividad para el mantenimiento y los reinicios, lo que se
conoce como cargas iniciales del programa (IPL). Cuando se toman en consideración estas tareas, una solución
de sistema central suele estar más cerca de dos o tres nueves de disponibilidad, lo que es equivalente a la de los
servidores de gama alta, basados en Intel.
Los sistemas centrales también son vulnerables ante desastres como cualquier otro servidor y requieren
sistemas de alimentación ininterrumpida (SAI) para controlar estos tipos de errores.
Mito: Los sistemas centrales gozan de una escalabilidad sin límites.

La escalabilidad de un sistema central depende de la capacidad del software del sistema, como el sistema de
control de la información de clientes (CICS) y la capacidad de las nuevas instancias de motores y
almacenamiento del sistema central. Algunas grandes compañías que usan sistemas centrales han
personalizado el rendimiento de su CICS y han sobrepasado la capacidad de los sistemas centrales más grandes
disponibles.
Mito: Los servidores basados en Intel no son tan eficaces como los
sistemas centrales.
Los nuevos sistemas basados en Intel con núcleo denso tienen tanta capacidad de proceso como los sistemas
centrales.
Mito: La nube no puede acomodar aplicaciones críticas de empresas

grandes, como instituciones financieras.
Aunque puede haber algunos casos aislados en que las soluciones en la nube se quedan cortas, suele ser
porque no se pueden distribuir los algoritmos de la aplicación. Estos pocos ejemplos son la excepción, no la
regla.
Resumen
En comparación, Azure proporciona una plataforma alternativa que es capaz de ofrecer unas características y
una funcionalidad equivalentes a un sistema central con un costo mucho menor. Además, el costo total de
propiedad (TCO) del modelo de costo controlado por el uso basado en suscripciones de la nube es mucho más
económico que los sistemas centrales.
Pasos siguientes
Realizar el cambio desde sistemas centrales a Azure
Realizar el cambio desde sistemas centrales a Azure
Como plataforma alternativa para ejecutar aplicaciones de sistemas centrales tradicionales, Azure ofrece un
proceso y el almacenamiento en hiperescala de un entorno de alta disponibilidad. Obtenga el valor y la agilidad
de una plataforma moderna basada en la nube sin los costos asociados a un entorno de sistema central.
En esta sección se proporciona orientación técnica para hacer el cambio desde una plataforma de sistema
central a Azure.
MIPS vs. vCPU

No existe una fórmula de asignación universal para determinar la cantidad de unidades centrales de
procesamiento virtual (vCPU) necesarias para ejecutar las cargas de trabajo del sistema central. Sin embargo, la
métrica de un millón de instrucciones por segundo (MIPS) a menudo se asigna a las vCPU en Azure. El valor de
MIPS mide la potencia del proceso global de un sistema central, y proporciona un valor constante del número
de ciclos por segundo de una máquina determinada.
Una organización pequeña puede requerir menos de 500 MIPS, mientras que una organización grande
generalmente usa más de 5.000 MIPS. A 1000 USD por cada MIPS, una organización grande gasta
aproximadamente 5 millones de USD al año para implementar una infraestructura de 5.000 MIPS. El costo anual
estimado para una implementación típica de Azure de esta escala es aproximadamente una décima parte del
costo de una infraestructura MIPS. Para obtener más información, consulte la Tabla 4 en las notas del producto
Demystifying Mainframe-to-Azure Migration (Desmitificar la migración del sistema central a Azure).
Un cálculo preciso de MIPS a vCPU con Azure depende del tipo de vCPU y la carga de trabajo exacta que está
ejecutando. Sin embargo, los estudios del banco de pruebas proporcionan una buena base para estimar la
cantidad y el tipo de vCPU que necesitará. Una prueba comparativa reciente de HPE zRef proporciona las
estimaciones siguientes:
288 MIPS por núcleo basado en Intel que se ejecuta en servidores de HPE Proliant para trabajos en línea
(CICS).
170 MIPS por núcleo Intel para trabajos por lotes COBOL.
En esta guía se calculan 200 MIPS por vCPU para realizar el procesamiento en línea y 100 MIPS por vCPU para
realizar el procesamiento por lotes.
NOTE
Estas estimaciones pueden cambiar a medida que la nueva serie de máquinas virtuales (VM) esté disponible en Azure.
Alta disponibilidad y conmutación por error
Los sistemas centrales a menudo ofrecen cinco 9s de disponibilidad (99.999 por ciento) cuando se usan el
acoplamiento de sistemas centrales y el Sysplex Paralelo. Sin embargo, los operadores de sistemas aún deben
programar el tiempo de inactividad del mantenimiento y las cargas iniciales del programa (IPL). La
disponibilidad real se acerca a dos o tres 9s, a la par con los servidores de gama alta, basados en Intel.
En comparación, Azure ofrece Acuerdos de Nivel de Servicio (SLA) basados en el compromiso, donde la
disponibilidad de varios nueves es el valor predeterminado y está optimizada con la replicación local o basada
en información geográfica de los servicios.
Azure proporciona disponibilidad adicional al replicar datos de varios dispositivos de almacenamiento, ya sea
localmente o en otras regiones geográficas. Si se produce un error basado en Azure, los recursos del proceso
pueden obtener acceso a los datos replicados a nivel regional o local.
Cuando usa recursos de plataforma como servicio (PaaS) de Azure, como Azure SQL Database y Azure
Cosmos DB, Azure puede administrar automáticamente las conmutaciones por error. Cuando se usa la
infraestructura de Azure como servicio (IaaS), la conmutación por error se basa en las funciones específicas del
sistema, como las características Always On de SQL Server, las instancias de clústeres de conmutación por error
y los grupos de disponibilidad.
Escalabilidad
Los sistemas centrales suelen escalarse verticalmente, mientras que los entornos de nube se escalan
horizontalmente. Los sistemas centrales también pueden escalarse horizontalmente si usan una instalación de
acoplamiento (CF), pero debido a los elevados costos que conllevan el hardware y el almacenamiento, resulta
caro escalarlos horizontalmente.
Una instalación de acoplamiento también ofrece un proceso estrechamente acoplado, mientras que las
características de escalamiento horizontal de Azure están acopladas débilmente. La nube puede escalarse
verticalmente u horizontalmente para que coincida con las especificaciones exactas del usuario, con la potencia
del proceso, el almacenamiento y los servicios que se escalan a petición según un modelo de facturación basado
en el uso.
Copia de seguridad y recuperación

Los clientes del sistema central generalmente mantienen sitios de recuperación ante desastres o hacen uso de
un proveedor de sistemas centrales independiente para hacer frente a situaciones de desastre. La sincronización
con un sitio de recuperación ante desastres generalmente se realiza a través de copias de datos sin conexión.
Ambas opciones conllevan costos elevados.
La redundancia geográfica automatizada también está disponible a través de la instalación de acoplamiento del
sistema central. Este enfoque es costoso y normalmente se reserva para sistemas críticos. En cambio, Azure
tiene opciones fáciles de implementar y muy rentables para realizar la copia de seguridad, la recuperación y la
redundancia a nivel local o regional, o por medio de la redundancia geográfica.
Storage
Para comprender cómo funcionan los sistemas centrales, debe descodificar varios términos que se superponen.
Por ejemplo, el almacenamiento central, la memoria real, el almacenamiento real y el almacenamiento principal
generalmente se refieren al almacenamiento conectado directamente al procesador del sistema central.
El hardware del sistema central incluye procesadores y otros dispositivos, como dispositivos de almacenamiento
de acceso directo (DASD), unidades de cinta magnética y varios tipos de consolas de usuario. Los programas de
usuario usan las cintas y los DASD en las funciones del sistema.
Los tipos de almacenamiento físico para sistemas centrales incluyen:
Almacenamiento central : ubicado directamente en el procesador del sistema central, también se conoce
como procesador o almacenamiento real.
Almacenamiento auxiliar : está separado del sistema central; este tipo incluye el almacenamiento en DASD
y también se conoce como almacenamiento de paginación.
La nube ofrece una gama de opciones flexibles y escalables, y solo deberá pagar las opciones que necesite.
Azure Storage ofrece un almacén de objetos que se puede escalar de forma masiva destinado a objetos de
datos, un servicio de sistema de archivos para la nube, un almacén de mensajería para mensajería confiable y
un almacén NoSQL. En cuanto a las máquinas virtuales, los discos administrados y no administrados
proporcionan un almacenamiento de disco persistente y seguro.
Desarrollo y pruebas del sistema central

Un factor importante de los proyectos de migración del sistema central es la evolución del desarrollo de
aplicaciones. Las organizaciones quieren que su entorno de desarrollo sea más ágil y pueda responder
rápidamente a las necesidades comerciales.
Los sistemas centrales suelen tener particiones lógicas separadas (LPAR) para realizar el desarrollo y las
pruebas, como el control de calidad y las LPAR de almacenamiento provisional. Las soluciones de desarrollo del
sistema central incluyen compiladores (COBOL, PL/I, Assembler) y editores. El más común es el conjunto de
herramientas Interactive System Productivity Facility (ISPF) para el sistema operativo z/OS que se ejecuta en los
sistemas centrales de IBM. Otros incluyen las herramientas ROSCOE Programming Facility (RPF) y Computer
Associates, como CA Librarian y CA-Panvalet.
Igualmente, los entornos de emulación y los compiladores están disponibles en plataformas x86, por lo que el
desarrollo y las pruebas suelen estar entre las primeras cargas de trabajo que se usan para migrar de un
sistema central a Azure. La disponibilidad y el uso generalizado de las herramientas de DevOps en Azure está
acelerando la migración de los entornos de desarrollo y prueba.
Cuando las soluciones se desarrollen y se prueben en Azure y estén listas para su implementación en el sistema
central, deberá copiar el código en el sistema central y compilarlo allí.
Pasos siguientes
Migrar la aplicación del sistema central
Migración de aplicaciones del sistema central
Al migrar aplicaciones de entornos de sistema central a Azure, la mayoría de los equipos siguen un enfoque
pragmático: reutilizar siempre que sea posible y, después, iniciar una implementación por fases en la que las
aplicaciones se reescriben o se reemplazan.
Normalmente, la migración de aplicaciones implica una o varias de las estrategias siguientes:
Rehospedaje: puede trasladar el código, los programas y las aplicaciones existentes desde el sistema
central y, después, recompilar el código que se ejecutará en un emulador de sistema central hospedado
en una instancia de la nube. Normalmente, este enfoque comienza con el traslado de las aplicaciones a
un emulador basado en la nube y, después, se migra la base de datos a una base de datos en la nube. Hay
que hacer algunos trabajos de ingeniería y refactorización, además de las conversiones de datos y
archivos.
Como alternativa, puede rehospedar mediante un proveedor de hospedaje tradicional. Una de las
principales ventajas de la nube es la subcontratación de la administración de la infraestructura. Puede
encontrar un proveedor de centro de datos que hospede sus cargas de trabajo de sistema central. Este
modelo puede darle algo de tiempo, reducir el bloqueo de los proveedores y producir un ahorro de los
costos intermedios.
Retirada: todas las aplicaciones que ya no son necesarias deberán retirarse antes de la migración.
Recompilación: algunas organizaciones deciden volver a escribir los programas usando técnicas
modernas. Dado el costo adicional y la complejidad de este enfoque, no es tan común como una
migración mediante lift-and-shift. Después de este tipo de migración, suele ser conveniente reemplazar
los módulos y el código mediante motores de transformación de código.
Reemplazo: este método reemplaza la funcionalidad del sistema central por las características en la
nube equivalentes. El software como servicio (SaaS) es una opción, que consiste en usar una solución
creada específicamente para abordar una cuestión empresarial; por ejemplo, finanzas, recursos humanos,
producción o planeamiento de recursos empresariales. Además, ahora hay disponibles muchas
aplicaciones específicas del sector para resolver los problemas que antes solían resolver las soluciones
del sistema central personalizadas.
Plantéese comenzar con el planeamiento de las cargas de trabajo que desea migrar inicialmente y, después,
determine los requisitos para trasladar las aplicaciones, las bases de código heredado y las bases de datos
asociados.
Emulación de sistema central en Azure

Los servicios de Azure pueden emular entornos de sistema central tradicionales, lo que le permite reutilizar las
aplicaciones y el código existentes en el sistema central. Los componentes de servidor habituales que puede
emular son procesamiento de transacciones en línea (OLTP), lotes y sistemas de ingesta de datos.
Sistemas OLTP
Muchos sistemas centrales tienen sistemas OLTP que procesan miles o millones de actualizaciones para una
cantidad inmensa de usuarios. Con frecuencia, estas aplicaciones utilizan software de procesamiento de
transacciones, entrada de formularios y control de la pantalla, como los sistemas de control de información del
cliente (CICS), sistemas de administración de la información (IMS) y procesadores de interfaz de terminal (TIP).
Al trasladar las aplicaciones de OLTP a Azure, hay disponibles emuladores de supervisión de procesamiento de
transacciones (TP) de sistema central que se ejecutan como infraestructura como servicio (IaaS) con máquinas
virtuales en Azure. Los servidores web también pueden implementar funcionalidades de control de la pantalla y
entrada de formularios. Este enfoque se puede combinar con las API de base de datos, como los objetos de
datos ActiveX (ADO), conectividad abierta de base de datos (ODBC) y conectividad de base de datos de Java
(JDBC) para las transacciones y el acceso a los datos.
Actualizaciones por lotes con restricciones de tiempo
Muchos sistemas centrales realizan actualizaciones mensuales o anuales de millones de registros de cuentas,
por ejemplo, las que se utilizan en banca, seguros y administraciones públicas. Los sistemas centrales pueden
trabajar con estos tipos de cargas de trabajo mediante sistemas de control de datos con alta capacidad de
procesamiento. Por su diseño, los trabajos por lotes de los sistemas centrales suelen procesarse en serie y su
rendimiento depende de las operaciones de entrada y salida por segundo (IOPS) que proporcione la red troncal
del sistema central.
Los entornos de procesamiento por lotes en la nube usan recursos de proceso en paralelo y redes de alta
velocidad para obtener un mayor rendimiento. Si necesita optimizar el rendimiento del procesamiento por lotes,
Azure dispone de varias opciones de red, almacenamiento y proceso.
Sistemas de ingesta de datos
Los sistemas centrales ingieren grandes lotes de datos de soluciones de venta minorista, servicios financieros y
fabricación, entre otras, para su procesamiento. Con Azure, puede usar las utilidades de línea de comandos tales
como AzCopy para copiar los datos hacia y desde la ubicación de almacenamiento. También puede usar el
servicio Azure Data Factory, que permite ingerir datos de distintos almacenes de datos para crear y programar
flujos de trabajo basados en datos.
Además de los entornos de emulación, Azure proporciona servicios de análisis y de plataforma como servicio
(PaaS) que pueden mejorar los entornos de sistema central existentes.
Migración de cargas de trabajo OLTP a Azure

La migración mediante lift-and-shift permite migrar rápidamente las aplicaciones existentes a Azure sin tener
que codificar. Cada aplicación se migra tal cual, lo que ofrece las ventajas de la nube sin el riesgo ni los costos
que conlleva la modificación del código. Este enfoque es compatible con el uso de un emulador de supervisión
de procesamiento de transacciones (TP) de sistema central en Azure.
Hay disponibles monitores de procesamiento de transacciones de varios proveedores que se ejecutan en
máquinas virtuales, una opción de infraestructura como servicio (IaaS) de Azure. Los siguientes diagramas de
antes y después muestran la migración de una aplicación en línea basada en IBM DB2, un sistema de
administración de bases de datos relacionales (DBMS), en un sistema central IBM z/OS. DB2 para z/OS usa
archivos de método de acceso a almacenamiento virtual (VSAM) para almacenar los datos, y el método de
acceso secuencial indexado (ISAM) para archivos planos. Esta arquitectura también utiliza CICS para la
supervisión de transacciones.
En Azure, se usan entornos de emulación para ejecutar el administrador de TP y los trabajos por lotes que usan
JCL. En la capa de datos, DB2 se reemplaza por Azure SQL Database, aunque también se puede usar Microsoft
SQL Server, DB2 LUW u Oracle Database. Un emulador admite IMS, VSAM y SEQ. Las herramientas de
administración del sistema central se reemplazan por los servicios de Azure y software de otros proveedores
que se ejecutan en máquinas virtuales.
La funcionalidad de entrada de formularios y tratamiento de la pantalla normalmente se implementa mediante
servidores web, que se pueden combinar con API de base de datos tales como ADO, ODBC y JDBC para el
acceso a los datos y las transacciones. La gama exacta de componentes de IaaS de Azure que usará dependerá
del sistema operativo que prefiera. Por ejemplo:
Máquinas vir tuales basadas en Windows: Internet Information Server (IIS) junto con ASP.NET para el
control de la pantalla y la lógica de negocios. Use ADO.NET para las transacciones y el acceso a los datos.
Máquinas vir tuales basadas en Linux: los servidores de aplicaciones basados en Java que están
disponibles, como Apache Tomcat para el control de la pantalla y la funcionalidad empresarial basada en
Java. Use JDBC para las transacciones y el acceso a los datos.
Migración de cargas de trabajo por lotes a Azure

En Azure, las operaciones por lotes difieren del entorno típico de procesamiento por lotes de los sistemas
centrales. Por su diseño, los trabajos por lotes de los sistemas centrales suelen procesarse en serie y su
rendimiento depende del valor de IOPS que proporcione la red troncal del sistema central. Los entornos de
procesamiento por lotes en la nube usan recursos de proceso en paralelo y redes de alta velocidad para obtener
un mayor rendimiento.
Para optimizar el rendimiento del procesamiento por lotes con Azure, considere las siguientes opciones de
proceso, almacenamiento, red y supervisión.
Proceso
Uso:
Máquinas virtuales con la mayor velocidad de reloj. Las aplicaciones del sistema central suelen ser de un
único subproceso y las CPU de los sistemas centrales tienen una velocidad de reloj muy alta.
Máquinas virtuales con gran capacidad de memoria para permitir el almacenamiento en caché de los
datos y las áreas de trabajo de las aplicaciones.
Máquinas virtuales con CPU virtuales de mayor densidad para aprovechar las ventajas del
procesamiento multiproceso si la aplicación lo admite.
Procesamiento paralelo, porque Azure se escala horizontalmente para el procesamiento paralelo y ofrece
más capacidad de proceso para una ejecución por lotes.
Storage
Uso:
Discos SSD Premium de Azure o discos Ultra de Azure para tener el número máximo de IOPS disponible.
Creación de particiones con varios discos para tener más E/S por segundo en cada tamaño de
almacenamiento.
Creación de particiones de almacenamiento, para distribuir la E/S entre varios dispositivos de Azure
Storage.
Redes
Use redes aceleradas de Azure para minimizar la latencia.
Supervisión
El uso de herramientas de supervisión, Azure Monitor, Azure Application Insights y registros de Azure
permite a los administradores supervisar cualquier exceso de rendimiento de las ejecuciones por lotes y
ayuda a eliminar los cuellos de botella.
Migración de entornos de desarrollo

Las arquitecturas de nube distribuidas se basan en un conjunto de herramientas de desarrollo diferente que
aportan las ventajas que ofrecen los procedimientos y lenguajes de programación modernos. Para facilitar esta
transición, puede usar un entorno de desarrollo con otras herramientas que estén diseñadas para emular los
entornos de IBM z/OS. La siguiente lista muestra las opciones de Microsoft y otros proveedores:
C O M P O N EN T E O P C IO N ES DE A Z URE
z/OS Windows, Linux o Unix
CICS Servicios de Azure ofrecidos por Micro Focus, Oracle, GT

Software (Fujitsu), TmaxSoft, Raincode y NTT Data, o
reescribir con Kubernetes
IMS Servicios de Azure ofrecidos por Micro Focus y Oracle
Assembler Servicios de Azure ofrecidos por Raincode y TmaxSoft; o

COBOL, C o Java; o asignación a las funciones del sistema
operativo
JCL JCL, PowerShell u otras herramientas de scripting
COBOL COBOL, C o Java
Natural Natural, COBOL, C o Java
Fortran y PL/I FORTRAN, PL/I, COBOL, C o Java
REXX y PL/I REXX, PowerShell u otras herramientas de scripting
Migración de bases de datos y datos

Normalmente, la migración de aplicaciones implica el rehospedaje de la capa de datos. Migre las bases de datos
de SQL Server de código abierto y otras bases de datos relacionales a soluciones de Azure totalmente
administradas, como Azure SQL Managed Instance, Azure Database for PostgreSQL y Azure Database for
MySQL con Azure Database Migration Service.
Por ejemplo, puede migrar si la capa de datos del sistema central usa:
IBM DB2 o una base de datos IMS; use Azure SQL Database, SQL Server, DB2 LUW u Oracle Database en
Azure.
VSAM y otros archivos sin formato; use archivos planos de método de acceso secuencial indexado (ISAM)
para Azure SQL Database, SQL Server, DB2 LUW u Oracle.
Grupos de fechas de generación (GDG); migre a archivos de Azure que usen una convención de
nomenclatura y extensiones de nombre de archivo que proporcionen una funcionalidad similar a los
GDG.
La capa de datos de IBM incluye varios componentes clave que se deben migrar también. Por ejemplo, al migrar
una base de datos, migre también una colección de los datos contenidos en grupos, cada uno de los cuales
contiene dbextents, que son conjuntos de datos VSAM de z/OS. La migración debe incluir el directorio que
identifica las ubicaciones de los datos en los grupos de almacenamiento. Además, el plan de migración debe
tener en cuenta el registro de base de datos, que contiene un registro de las operaciones realizadas en la base
de datos. Una base de datos puede tener uno, dos (doble o alternativo) o cuatro (dobles y alternativos) registros.
La migración de la base de datos también incluye los siguientes componentes:
Administrador de base de datos: proporciona acceso a los datos de la base de datos. El administrador de
base de datos se ejecuta en su propia partición en un entorno de z/OS.
Solicitante de aplicaciones: acepta las solicitudes de aplicaciones antes de pasarlas a un servidor de
aplicaciones.
Adaptador de recursos en línea: incluye componentes de solicitante de aplicaciones para su uso en
transacciones CICS.
Adaptador de recursos de procesamiento por lotes: implementa componentes de solicitante de
aplicaciones para aplicaciones de procesamiento por lotes en z/OS.
SQL interactivo (ISQL): se ejecuta como una aplicación e interfaz CICS que permite a los usuarios para
escribir instrucciones SQL o comandos de operador.
Aplicación CICS: se ejecuta bajo el control de CICS, y usa los orígenes de datos y los recursos disponibles
en CICS.
Aplicación de procesamiento por lotes: ejecuta lógica de proceso sin comunicación interactiva con los
usuarios, por ejemplo, crear actualizaciones masivas de datos o generar informes de una base de datos.
Optimización de la escala y la capacidad de proceso de Azure

Por lo general, los sistemas centrales se escalan verticalmente, mientras que la nube se escala horizontalmente.
Para optimizar la escala y el rendimiento de las aplicaciones del estilo de sistema central que se ejecutan en
Azure, es importante que comprenda cómo los sistemas centrales separan y aíslan las aplicaciones. Un sistema
central z/OS usa una característica llamada particiones lógicas (LPAR) para aislar y administrar los recursos para
una aplicación específica en una sola instancia.
Por ejemplo, un sistema central puede usar una partición LPAR para una región CICS con programas COBOL
asociados y una partición LPAR independiente para DB2. A menudo se usan LPAR diferentes para los entornos
de desarrollo, pruebas y ensayo.
En Azure, es más habitual utilizar máquinas virtuales independientes con este propósito. Normalmente, las
arquitecturas de Azure implementan máquinas virtuales para la capa de aplicación, un conjunto independiente
de máquinas virtuales para la capa de datos, otro conjunto para el desarrollo, y así sucesivamente. Cada nivel de
procesamiento se puede optimizar con el tipo de máquinas virtuales y las características más apropiados para
ese entorno.
Además, cada nivel también puede proporcionar también los servicios de recuperación ante desastres
adecuados. Por ejemplo, las máquinas virtuales de producción y base de datos pueden requerir una
recuperación activa o semiactiva, mientras que las máquinas virtuales de desarrollo y pruebas permiten una
recuperación pasiva.
En la siguiente ilustración se muestra una posible implementación de Azure con un sitio principal y uno
secundario. En el sitio principal, las máquinas virtuales de producción, almacenamiento provisional y pruebas se
implementan con alta disponibilidad. El sitio secundario es para recuperación ante desastres y copia de
seguridad.
Migración preconfigurada de un sistema central a Azure

Trasladar las soluciones de un sistema central a Azure puede requerir una migración preconfigurada. En ella, se
trasladan primero algunas aplicaciones y las demás se quedan en el sistema central de forma temporal o
permanente. Normalmente, este enfoque requiere sistemas que permitan que las aplicaciones y las bases de
datos interactúen entre el sistema central y Azure.
Un escenario común es trasladar una aplicación a Azure y mantener en el sistema central los datos que la
aplicación utiliza. Se utiliza un software específico para que las aplicaciones que se encuentran en Azure puedan
acceder a los datos del sistema central. Afortunadamente, existe una amplia gama de soluciones que
proporcionan la integración entre Azure y los entornos de sistema central existentes, compatibilidad con
escenarios híbridos y migración con el tiempo. Los partners de Microsoft, proveedores de software
independientes e integradores pueden ayudarle en camino.
Una opción es Microsoft Host Integration Server, una solución que proporciona la arquitectura distribuida de
bases de datos relacionales (DRDA) necesaria para que las aplicaciones que se encuentran en Azure puedan
acceder a los datos de DB2 que permanecen en el sistema central. Otras opciones para la integración entre el
sistema central y Azure son algunas soluciones de IBM, Attunity, Codit u otros proveedores, y opciones de
código abierto.
Soluciones de socios
Si se está planteando migrar un sistema central, el ecosistema de asociados está disponible para ayudarlo.
Azure es una infraestructura probada que ofrece alta disponibilidad y escalabilidad para los sistemas que
actualmente se ejecutan en sistemas centrales. Algunas cargas de trabajo se pueden migrar con relativa
facilidad. Otras cargas de trabajo que dependen de software del sistema heredado, como CICS e IMS, pueden
rehospedarse con las soluciones de los asociados y migrarse a Azure con el tiempo. Independientemente de la
opción que elija, Microsoft y nuestros asociados están a su disposición para ayudarlo a optimizar su
implementación en Azure, manteniendo la funcionalidad del software en el sistema central.
Más información
Para obtener más información, consulte los siguientes recursos:
Comience a usar Azure
Implementación de IBM DB2 pureScale en Azure
Documentación de Host Integration Server
Procedimientos recomendados para proteger y
gestionar las cargas de trabajo migradas a Azure
A medida que planea y diseña la migración, además de pensar en la migración propiamente dicha, debe tener
en cuenta el modelo de seguridad y administración en Azure después de la migración. En este artículo se
describe el planeamiento y los procedimientos recomendados para proteger la implementación de Azure
después de la migración. También se abordan las tareas en curso para mantener el funcionamiento de la
implementación en un nivel óptimo.
IMPORTANT
Los procedimientos recomendados y las opiniones que se describen en este artículo se basan en la plataforma de Azure y
las características del servicio disponibles en el momento de redactar el artículo. Las características y funcionalidades
cambian con el tiempo.
Protección de las cargas de trabajo migradas

Tras la migración, la tarea más crítica es proteger las cargas de trabajo migradas de amenazas internas y
externas. Estos procedimientos recomendados le ayudarán a hacerlo:
obtenga información sobre cómo trabajar con la supervisión, las valoraciones y las recomendaciones
proporcionadas por Azure Security Center.
consulte los procedimientos recomendados para cifrar los datos en Azure.
proteja las máquinas virtuales frente a malware y ataques malintencionados.
proteja la información confidencial de las aplicaciones web migradas.
compruebe quién tiene acceso a las suscripciones y los recursos de Azure después de la migración.
revise los registros de auditoría y seguridad de Azure de forma periódica.
conozca y evalúe las características de seguridad avanzadas que ofrece Azure.
Estos procedimientos recomendados se describen con más detalle en las secciones siguientes.
Procedimiento recomendado: seguir las recomendaciones de Azure

Security Center
Los administradores de inquilinos de Azure tienen que habilitar características de seguridad que protegen las
cargas de trabajo frente a ataques. Security Center proporciona administración de seguridad unificada. Desde
Security Center, puede aplicar directivas de seguridad en las cargas de trabajo, limitar la exposición a amenazas
y detectar y responder a los ataques. Security Center analiza las configuraciones y los recursos de los inquilinos
de Azure y hace recomendaciones de seguridad, entre las que se incluyen:
Administración de directivas centralizada: Garantice el cumplimiento de los requisitos de seguridad
normativos o de la empresa administrando las directivas de seguridad de forma centralizada de las cargas de
trabajo en la nube híbridas.
Evaluación continua de la seguridad: supervise la seguridad de máquinas, redes, almacenamiento y
servicios de datos y aplicaciones para detectar posibles problemas de seguridad.
Recomendaciones prácticas: corrija los puntos vulnerables de seguridad para evitar que puedan ser
usadas por los atacantes, mediante recomendaciones de seguridad prácticas y clasificadas en orden de
prioridad.
Aler tas e incidentes clasificados por orden de prioridad: Céntrese primero en las amenazas más
críticas con la clasificación en orden de prioridad de las alertas e incidentes de seguridad.
Además de las evaluaciones y las recomendaciones, Security Center proporciona otras características de
seguridad que se pueden habilitar para recursos específicos.
Acceso Just-In-Time (JIT). Reduzca la superficie de red expuesta a ataques mediante JIT, un acceso
controlado a los puertos de administración de las VM de Azure.
Si se tiene abierto en Internet el puerto RDP 3389 de la máquina virtual, se exponen las máquinas
virtuales a la actividad continua de actores perjudiciales. Las direcciones IP de Azure son bien
conocidas y los piratas informáticos las sondean continuamente para posibles ataques en los puertos
3389 abiertos.
JIT utiliza grupos de seguridad de red (NSG) y reglas de entrada que limitan el tiempo que un puerto
específico está abierto.
Si se habilita el acceso JIT, Security Center comprueba que un usuario tenga permisos de acceso de
escritura de control de acceso basado en rol de Azure (RBAC de Azure) para una VM. Además, puede
especificar reglas para determinar cómo pueden conectarse los usuarios a las máquinas virtuales. Si
los permisos son correctos, se aprueba la solicitud de acceso y Security Center configura grupos de
seguridad de red para permitir el tráfico entrante a los puertos seleccionados durante el tiempo
especificado. Los grupos de seguridad de red se devuelven a su estado anterior cuando expira el
tiempo.
Controles de aplicaciones adaptables. Use listas dinámicas de aplicaciones permitidas para controlar
qué aplicaciones se ejecutan en las máquinas virtuales y protegerlas de software malintencionado.
Los controles de aplicaciones adaptables le permiten aprobar aplicaciones y evitar que usuarios o
administradores no autorizados instalen en las máquinas virtuales aplicaciones de software no
autorizadas o que están siendo examinadas.
Es posible bloquear los intentos de ejecución de aplicaciones malintencionadas o enviar alertas,
evitar las aplicaciones no deseadas o malintencionadas y garantizar el cumplimiento de la
directiva de seguridad de aplicaciones de su organización.
Super visión de la integridad de los archivos. garantice la integridad de los archivos que se ejecutan en
las máquinas virtuales.
No es necesario instalar software para causar problemas en la máquina virtual. El cambio de un
archivo del sistema también puede causar la degradación del rendimiento o errores en la máquina
virtual. La funcionalidad Supervisión de la integridad de los archivos examina los archivos del sistema
y la configuración del registro en busca de cambios y le avisa si algo ha cambiado.
Security Center recomienda qué archivos se deben supervisar.
Más información:
Más información sobre Azure Security Center
Más información sobre el acceso Just-in-Time a las máquinas virtuales.
Más información sobre la aplicación de los controles de aplicación adaptables.
Introducción a la supervisión de la integridad de los archivos.
Procedimiento recomendado: Cifrado de datos

El cifrado es una parte importante de los procedimientos de seguridad de Azure. Garantizar que el cifrado está
habilitado en todos los niveles ayuda a prevenir que personas no autorizadas puedan tener acceso a
información confidencial, incluidos los datos en tránsito y en reposo.
Cifrado para la infraestructura como servicio
Máquinas vir tuales: para las VM, puede usar Azure Disk Encryption para cifrar los discos de las VM de
infraestructura como servicio (IaaS) con Linux y Windows.
Azure Disk Encryption utiliza BitLocker para Windows y dm-crypt para Linux con la finalidad de
facilitar el cifrado de volúmenes para discos de datos y del sistema operativo.
Puede usar una clave de cifrado creada por Azure o puede proporcionar sus propias claves de cifrado
protegidas en Azure Key Vault.
Azure Disk Encryption protege los datos de máquinas virtuales de IaaS cuando están en reposo (en el
disco) y durante el arranque de la máquina virtual.
Security Center le avisa si tiene VM que no están cifradas.
Storage: proteja los datos almacenados en reposo en Azure Storage.
Los datos almacenados en cuentas de Azure Storage se pueden cifrar mediante claves AES generadas
por Microsoft conforme al estándar FIPS 140-2. También puede usar sus propias claves.
El cifrado de Azure Storage está habilitado para todas las cuentas de almacenamiento, nuevas o
existentes, y no se puede deshabilitar.
Cifrado para plataforma como servicio
A diferencia de IaaS, en que administra sus propias VM e infraestructura, en un modelo de plataforma como
servicio (PaaS), es el proveedor quien se ocupa de la administración de la infraestructura y la plataforma. El
usuario puede centrarse en las funcionalidades y la lógica de la aplicación principal. Con tantos tipos distintos de
servicios de PaaS, cada servicio se evalúa individualmente por motivos de seguridad. Por ejemplo, veamos
cómo se puede habilitar el cifrado para Azure SQL Database.
Always Encr ypted: use el asistente de Always Encrypted en SQL Server Management Studio para proteger
los datos en reposo.
Puede crear claves de Always Encrypted para cifrar datos de columnas individuales.
Las claves de Always Encrypted se pueden almacenan cifradas en los metadatos de la base de datos o
se pueden almacenar en almacenes de claves de confianza, como Azure Key Vault.
Lo más probable es que, para usar esta característica, tenga que realizar cambios en la aplicación.
Cifrado de datos transparente (TDE) : proteja Azure SQL Database con cifrado y descifrado en tiempo
real de la base de datos, las copias de seguridad asociadas y los archivos de registro de transacciones en
reposo.
TDE permite que las actividades de cifrado tengan lugar sin hacer cambios en el nivel de aplicación.
TDE puede usar las claves de cifrado proporcionadas por Microsoft, o bien el usuario puede traer su
propia clave.
Más información:
Más información acerca de Azure Disk Encryption para máquinas virtuales y conjuntos de escalado de
Habilitación de Azure Disk Encryption para máquinas virtuales Windows.
Más información acerca del cifrado de Azure Storage para datos en reposo.
Lea la introducción a Always Encrypted.
Obtenga información acerca de TDE para SQL Database y Azure Synapse.
Obtenga información acerca de TDE de Azure SQL Database con una clave administrada por el cliente.
Procedimiento recomendado: protección de las máquinas virtuales

con antimalware
En particular, las máquinas virtuales anteriores migradas a Azure podrían no tener instalado el nivel adecuado
de antimalware. Azure proporciona una solución de punto de conexión gratuita que ayuda a proteger las
máquinas virtuales frente a virus, spyware y otro malware.
Microsoft Antimalware para Azure Cloud Services y Virtual Machines genera alertas cuando se intenta
instalar software malintencionado o no deseado conocido.
Es una solución de un solo agente que se ejecuta en segundo plano sin intervención humana.
En Security Center, puede identificar las VM que no estén ejecutando la protección del punto de conexión
e instalar Microsoft Antimalware según sea necesario.
Figura 1: Antimalware para máquinas virtuales.

Más información:
Más información sobre Microsoft Antimalware para Azure.
Procedimiento recomendado: protección de aplicaciones web

Las aplicaciones web migradas se enfrentan a un par de problemas:
La mayoría de las aplicaciones web heredadas tienden a tener información confidencial dentro de los
archivos de configuración. Los archivos que contienen dicha información pueden presentar problemas de
seguridad al hacer copias de seguridad de las aplicaciones o cuando el código de las aplicaciones se confirma
o extrae del control de código fuente.
Además, al migrar aplicaciones web que residen en una máquina virtual, es probable que mueva esa
máquina desde una red local y un entorno protegido mediante firewall a un entorno abierto a Internet.
Asegúrese de que configura una solución que lleve a cabo el trabajo de los recursos de protección locales.
Azure proporciona las soluciones siguientes:
Azure Key Vault: hoy en día, los desarrolladores de aplicaciones web dan pasos para asegurarse de que
la información confidencial no se filtra de estos archivos. Un método para proteger la información
consiste en extraerla de los archivos y colocarla en una instancia de Azure Key Vault.
Puede usar Key Vault para centralizar el almacenamiento de secretos de aplicación y controlar su
distribución. Así se evita la necesidad de almacenar información de seguridad en los archivos de
aplicación.
Las aplicaciones pueden acceder de forma segura a la información del almacén mediante
identificadores URI, sin necesidad de código personalizado.
Azure Key Vault le permite bloquear el acceso mediante los controles de seguridad de Azure e
implementar a la perfección claves de rotación. Microsoft no puede ver ni extraer sus datos.
App Ser vice Environment para Power Apps: si una aplicación que haya migrado necesita más
protección, puede incorporar App Service Environment y el firewall de aplicaciones web para proteger los
recursos de aplicación.
App Service Environment proporciona un entorno completamente aislado y dedicado para ejecutar
aplicaciones. Por ejemplo, aplicaciones web de Windows y Linux, contenedores de Docker, aplicaciones
móviles y aplicaciones de funciones.
Resulta útil para aplicaciones que ofrecen una gran escalabilidad, requieren aislamiento y acceso
seguro a la red, o bien consumen mucha memoria.
Firewall de aplicaciones web: una característica de Azure Application Gateway que ofrece una
protección centralizada para las aplicaciones web.
Protege las aplicaciones web sin necesidad de modificaciones en el código de back-end.
Protege varias aplicaciones web al mismo tiempo mediante Application Gateway.
Puede supervisar el Firewall de aplicaciones web mediante Azure Monitor. Web Application Firewall
está integrado en Security Center.
Figura 2: Azure Key Vault.

Más información:
Lea la introducción a Azure Key Vault.
Más información sobre el firewall de aplicaciones web.
Lea la introducción a los entornos de Azure App Service.
Más información sobre cómo configurar una aplicación web para leer los secretos de Key Vault.
Procedimiento recomendado: revisión de suscripciones y permisos de

recursos
Al migrar las cargas de trabajo y ejecutarlas en Azure, el personal con acceso a las cargas de trabajo varía. El
equipo de seguridad debe revisar el acceso a los grupos de recursos y el inquilino de Azure de forma periódica.
Azure incluye ofertas de administración de identidades y seguridad de control de acceso, incluido el control de
acceso basado en rol de Azure (RBAC de Azure), para autorizar los permisos para acceder a los recursos de
Azure.
RBAC de Azure asigna los permisos de acceso para las entidades de seguridad. Las entidades de seguridad
representan a usuarios, grupos (conjuntos de usuarios), entidades de servicio (identidades usadas por
aplicaciones y servicios) e identidades administradas (es decir, identidades de Azure Active Directory
administradas automáticamente por Azure).
RBAC de Azure puede asignar roles a las entidades de seguridad (como las de propietario, colaborador y
lector) y definiciones de rol (una colección de permisos) que definen las operaciones que los roles pueden
realizar.
RBAC de Azure también puede establecer los ámbitos que definen el límite de un rol. El ámbito se puede
establecer en varios niveles, como un grupo de administración, una suscripción, un grupo de recursos o un
recurso.
Asegúrese de que los administradores con acceso a Azure solo pueden acceder a los recursos que desea
permitir. Si los roles predefinidos de Azure no son lo suficientemente pormenorizados, puede crear roles
personalizados para separar y limitar los permisos de acceso.
Asegúrese de que los administradores con acceso a Azure solo pueden acceder a los recursos que desea
permitir. Si los roles predefinidos de Azure no son lo suficientemente pormenorizados, puede crear roles
personalizados para separar y limitar los permisos de acceso.
Figura 3: Control de acceso.

Más información:
Obtenga más información sobre RBAC de Azure.
Aprenda a administrar el acceso mediante RBAC de Azure y Azure Portal.
Más información acerca de los roles personalizados.
Procedimiento recomendado: revisión de los registros de auditoría y

seguridad
Azure AD proporciona registros de actividad que aparecen en Azure Monitor. Los registros capturan las
operaciones realizadas en el inquilino de Azure, cuándo se produjeron y quién las realizó.
Los registros de auditoría muestran el historial de tareas del inquilino. Los registros de actividad de inicio
de sesión registros muestran quién llevó a cabo las tareas.
El acceso a los informes de seguridad depende de la licencia de Azure AD. Con las licencias gratuitas y
básicas, obtendrá una lista de usuarios e inicios de sesión de riesgo. Con las licencias Prémium, obtiene
información de eventos subyacentes.
Puede enrutar los registros de actividad a varios puntos de conexión para la retención a largo plazo y
obtención de conclusiones sobre los datos.
Convierta en una práctica común la revisión de los registros o integre las herramientas de administración
de eventos e información de seguridad (SIEM) para revisar automáticamente las anomalías. Si no usa una
edición Prémium, tendrá que hacer un análisis en profundidad usted mismo o mediante el sistema SIEM.
El análisis incluye la búsqueda de inicios de sesión en riesgo y eventos y otros patrones de ataque del
usuario.
Figura 4: Usuarios y grupos de Azure AD.

Más información:
Más información sobre los registros de actividad de Azure AD en Azure Monitor.
Más información sobre la auditoría de informes de actividad en Azure Portal.
Procedimiento recomendado: evaluación de otras características de

seguridad
Azure proporciona otras características de seguridad que ofrecen opciones avanzadas de seguridad. Observe
que algunos de estos procedimientos recomendados requieren licencias adicionales y opciones Prémium.
Implementación de unidades administrativas de Azure AD. la delegación de derechos administrativos
al personal de soporte técnico puede resultar complicada con el control de acceso básico de Azure. Otorgar
al personal de soporte técnico acceso para administrar todos los grupos de Azure AD podría no ser el
enfoque ideal para la seguridad de la organización. El uso de AU le permite separar los recursos de Azure en
contenedores de forma similar a las unidades organizativas (UO) de un entorno local. Para utilizar AU, el
administrador de AU debe tener una licencia de Azure AD prémium. Para obtener más información, consulte
Administración de unidades administrativas en Azure AD.
Uso de Multi-factor Authentication. Si tiene una licencia de Azure AD Premium, puede habilitar y aplicar
la autenticación multifactor en las cuentas de administrador. La suplantación de identidad es la manera más
común de poner en peligro las credenciales de las cuentas. Si un actor perjudicial consigue unas credenciales
de cuenta de administrador, no hay ningún freno posible ante acciones de gran alcance como la eliminación
de todos los grupos de recursos. Puede establecer la autenticación multifactor de varias maneras como, por
ejemplo, con correo electrónico, una aplicación autenticadora y mensajes de texto de teléfono. Como
administrador puede seleccionar la opción menos intrusiva. La autenticación multifactor se integra con el
análisis de amenazas y las directivas de acceso condicional para solicitar aleatoriamente la respuesta a un
desafío de autenticación multifactor. Más información sobre la guía de seguridad y cómo configurar la
autenticación multifactor.
Implementación del acceso condicional. En la mayoría de las organizaciones pequeñas y medianas, los
administradores y el equipo de soporte técnico de Azure probablemente están en una misma ubicación
geográfica. En este caso, la mayoría de los inicios de sesión provienen de las mismas áreas. Si las
direcciones IP de estas ubicaciones son lo bastante estáticas, tendría sentido que no se vieran inicios de
sesión de administrador fuera de estas áreas. Incluso si un actor perjudicial remoto pone en peligro las
credenciales de administrador, puede implementar características de seguridad, como el acceso condicional
combinado con la autenticación multifactor, para evitar el inicio de sesión desde ubicaciones remotas. Esto
también puede impedir ubicaciones suplantadas desde direcciones IP aleatorias. Obtenga más información
sobre el acceso condicional y revise los procedimientos recomendados para el acceso condicional en
Azure AD.
Revisión de los permisos de las aplicaciones empresariales. Con el paso del tiempo, los
administradores pueden seleccionar vínculos de Microsoft y de terceros sin conocer su efecto en la
organización. Los vínculos pueden presentar pantallas de consentimiento que asignan permisos a las
aplicaciones de Azure. Esto podría permitir el acceso para leer datos de Azure AD o incluso acceso completo
para administrar toda la suscripción de Azure. Es recomendable revisar periódicamente las aplicaciones a
través de las que los administradores y usuarios han permitido el acceso a recursos de Azure. Asegúrese de
que estas aplicaciones solo tengan asociados los permisos necesarios. Además, con carácter trimestral o
semestral, puede enviar por correo electrónico a los usuarios un vínculo a páginas de aplicaciones para que
sepan cuáles son las aplicaciones a través de las que han permitido el acceso a datos de su organización. Para
más información, consulte Aplicación inesperada en mi lista de aplicaciones y cómo controlar las
asignaciones de aplicaciones en Azure AD.
Administración de las cargas de trabajo migradas

En las secciones siguientes se indican algunos procedimientos recomendados para la administración de Azure,
por ejemplo:
procedimientos recomendados para los grupos de recursos y los recursos de Azure, como la nomenclatura
inteligente, la prevención de la eliminación accidental, la administración de los permisos de recursos y el
etiquetado eficaz de los recursos.
obtenga una visión general rápida sobre el uso de planos técnicos para crear y administrar los entornos de
implementación.
revise arquitecturas de Azure de ejemplo para obtener información al crear las implementaciones
posteriores a la migración.
si tiene varias suscripciones, puede reunirlas en grupos de administración y aplicar la configuración de
gobernanza a esos grupos.
aplique directivas de cumplimiento a los recursos de Azure.
elabore una estrategia de continuidad empresarial y recuperación ante desastres (BCDR) para mantener los
datos seguros, el entorno resistente y los recursos activos y en ejecución cuando se producen interrupciones.
agrupe las máquinas virtuales en grupos de disponibilidad para alta disponibilidad y resistencia. Use discos
administrados para facilitar la administración de los discos y el almacenamiento de la máquina virtual.
habilite el registro de diagnóstico para los recursos de Azure, cree alertas y cuadernos de estrategias para la
solución proactiva de problemas y use el panel de Azure para obtener una vista unificada del mantenimiento
y el estado de la implementación.
Conozca el plan de soporte técnico de Azure y cómo implementarlo, consulte los procedimientos
recomendados para mantener actualizadas las máquinas virtuales y ponga en marcha procesos para la
administración de los cambios.
Procedimiento recomendado: nomenclatura de los grupos de

recursos
Asegúrese de que los grupos de recursos tengan nombres significativos que los administradores y los
miembros del equipo de soporte técnico puedan reconocer y examinar con facilidad. De esta forma, puede
mejorar significativamente la productividad y la eficacia.
Si va a sincronizar Active Directory local con Azure AD mediante Azure AD Connect, considere la posibilidad de
hacer coincidir los nombres de los grupos de seguridad locales con los nombres de los grupos de recursos de
Azure.
Ilustración 5:
Nomenclatura de los grupos de recursos.
Más información:
Más información sobre las convenciones de nomenclatura recomendadas.
Procedimiento recomendado: implementación de bloqueos de

eliminación para grupos de recursos
Lo último que necesita es que un grupo de recursos desaparezca porque se eliminó accidentalmente. Se
recomienda implementar bloqueos de eliminación para que esto no suceda.
Ilustración 6: Bloqueos de eliminación.
Más información:
Más información sobre el bloqueo de recursos para impedir cambios inesperados.
Procedimiento recomendado: descripción de los permisos de acceso

a los recursos
Un propietario de la suscripción tiene acceso a todos los grupos de recursos y recursos de la suscripción.
Agregue personas con moderación a esta asignación valiosa. Comprender las ramificaciones de estos tipos
de permisos es importante para mantener el entorno seguro y estable.
Asegúrese de colocar los recursos en los grupos de recursos adecuados:
Agrupe los recursos con un ciclo de vida similar. Idealmente, no debería ser necesario mover un
recurso cuando se necesita eliminar un grupo de recursos completo.
Los recursos que posibilitan una función o una carga de trabajo se deben colocar juntos para una
administración simplificada.
Más información:
Más información sobre la organización de suscripciones y grupos de recursos.
Procedimiento recomendado: etiquetado eficaz de los recursos

A menudo, solo el uso de un nombre de grupo de recursos relacionado con los recursos no proporciona
suficientes metadatos para la implementación eficaz de mecanismos como la facturación interna o la
administración dentro de una suscripción.
Como procedimiento recomendado, use etiquetas de Azure para agregar metadatos útiles que se pueden
consultar y sobre los que se puede informar.
Las etiquetas proporcionan una manera de organizar lógicamente los recursos con las propiedades que
defina. Las etiquetas se pueden aplicar a grupos de recursos o directamente a recursos.
Las etiquetas se pueden aplicar en un grupo de recursos o en recursos individuales. Los recursos del
grupo no heredan las etiquetas del grupo de recursos.
Puede automatizar el etiquetado con PowerShell o Azure Automation, o bien etiquetar grupos y recursos
individuales.
Si tiene en funcionamiento un sistema de administración de cambios y solicitudes, puede usar fácilmente
la información de la solicitud para rellenar las etiquetas de recursos específicos de la empresa.
Figura 7: Etiquetado.
Más información:
Más información sobre el etiquetado y las limitaciones de las etiquetas.
Consulte los ejemplos de PowerShell y la CLI para configurar el etiquetado y para aplicar las etiquetas de un
grupo de recursos a sus recursos.
Consulte los procedimientos recomendados de etiquetado de Azure.
Procedimiento recomendado: implementación de planos técnicos

Del mismo modo que un plano técnico permite a los ingenieros y arquitectos esbozar los parámetros de diseño
de un proyecto, el servicio Azure Blueprints permite que los arquitectos de nube y los grupos de TI centrales
definan un conjunto repetible de recursos de Azure. Esto les ayuda a implementar y a cumplir los estándares,
patrones y requisitos de una organización. Con Azure Blueprints, los equipos de desarrollo pueden crear y
construir rápidamente nuevos entornos que cumplan los requisitos de cumplimiento de la organización. Estos
nuevos entornos tienen un conjunto de componentes integrados, como redes, para acelerar el desarrollo y la
entrega.
Utilice planos técnicos para organizar la implementación de grupos de recursos, plantillas de Azure Resource
Manager y asignaciones de roles y directivas.
Almacene los planos técnicos en un servicio distribuido globalmente, Azure Cosmos DB. Los objetos de
plano técnico se replican en varias regiones de Azure. La replicación proporciona una baja latencia, una alta
disponibilidad y un acceso coherente a un plano técnico, con independencia de la región en la que este
implemente los recursos.
Más información:
Más información sobre planos técnicos.
Revise un plano técnico de ejemplo para acelerar la inteligencia artificial en la atención sanitaria.
Procedimiento recomendado: revisión de las arquitecturas de

referencia de Azure
Crear cargas de trabajo seguras, escalables y fáciles de administrar en Azure puede ser abrumador. Con los
continuos cambios, puede resultar difícil mantenerse al día con las diferentes características para un entorno
óptimo. Tener una referencia de la que aprender puede ser útil al diseñar y migrar las cargas de trabajo. Azure y
sus asociados han desarrollado varias arquitecturas de referencia de ejemplo para varios tipos de entornos.
Estos ejemplos están diseñados para proporcionar ideas para aprender y crear a partir de ellas.
Las arquitecturas de referencia están organizadas por escenario. Contienen procedimientos recomendados y
consejos sobre administración, disponibilidad, escalabilidad y seguridad. App Service Environment proporciona
un entorno completamente aislado y dedicado para ejecutar las aplicaciones. Por ejemplo, las aplicaciones web
de Windows y Linux, los contenedores de Docker, las aplicaciones móviles y las aplicaciones de funciones. App
Service agrega a la aplicación las funcionalidades de Azure, con seguridad, equilibrio de carga, escalabilidad
automática y administración automatizada. También puede sacar partido de sus funcionalidades de DevOps, por
ejemplo, la implementación continua desde Azure DevOps y GitHub, la administración de paquetes, los entornos
de ensayo, el dominio personalizado y los certificados SSL. App Service es útil para las aplicaciones que
requieren aislamiento y acceso seguro a la red y para aquellas que consumen gran cantidad de memoria y otros
recursos que requieren escalabilidad.
Más información:
Más información sobre las arquitecturas de referencia de Azure.
Consulte los escenarios de ejemplo de Azure.
Procedimiento recomendado: Administración de recursos con grupos

de administración de Azure
Si la organización tiene varias suscripciones, deberá administrar el acceso, las directivas y su cumplimiento. Los
grupos de administración de Azure proporcionan un nivel de ámbito por encima de las suscripciones. A
continuación se incluyen algunas sugerencias:
Las suscripciones se organizan en contenedores llamados grupos de administración, a los que se aplican las
condiciones de gobernanza.
Todas las suscripciones de un grupo de administración heredan automáticamente las condiciones del grupo
de administración.
Los grupos de administración proporcionan una administración de nivel empresarial a gran escala con
independencia del tipo de suscripciones que tenga.
Por ejemplo, puede aplicar una directiva de grupo de administración que limita las regiones en las que se
pueden crear máquinas virtuales. Esta directiva se aplica a todos los grupos de administración, las
suscripciones y los recursos de ese grupo de administración.
Puede crear una estructura flexible de grupos de administración y suscripciones para organizar los recursos
en una jerarquía para la administración unificada de las directivas y el acceso.
El diagrama siguiente muestra un ejemplo de creación de una jerarquía para la gobernanza mediante grupos de
administración.
Ilustración 8: Grupos de administración.
Más información:
Más información acerca de la organización de recursos en grupos de administración.
Procedimiento recomendado: implementación de Azure Policy

Azure Policy es un servicio que se usa para crear, asignar y administrar directivas. Las directivas aplican distintas
reglas y efectos a los recursos, con el fin de que estos sigan cumpliendo los estándares corporativos y los
contratos de nivel de servicio.
Azure Policy evalúa los recursos y los examina en busca de los que no son compatibles con las directivas. Por
ejemplo, puede crear una directiva que permita solo un tamaño específico de SKU para las máquinas virtuales
del entorno. Azure Policy evaluará esta configuración al crear y actualizar los recursos, y al buscar los recursos
existentes. Tenga en cuenta que Azure proporciona algunas directivas integradas que puede asignar o bien
puede crear las suyas propias.
Ilustración 9: Azure Policy.

Más información:
Lea la introducción a Azure Policy.
Más información acerca de cómo crear y administrar directivas para exigir el cumplimiento.
Procedimiento recomendado: implementación de una estrategia de

BCDR
El planeamiento de BCDR es un ejercicio esencial que se debe realizar como parte del proceso de planeamiento
de la migración de Azure. En términos legales, los contratos pueden incluir una cláusula de fuerza mayor que
exima de las obligaciones debido a una fuerza mayor, como los huracanes o los terremotos. No obstante, debe
asegurarse de que los servicios esenciales siguen funcionando y se recuperan si se produce un desastre. La
capacidad de hacer esto puede crear o interrumpir el futuro de su empresa.
En general, la estrategia de BCDR debe tener en cuenta:
Copia de seguridad de datos: cómo mantener seguros los datos para una recuperación sencilla si se
producen interrupciones.
Recuperación ante desastres: cómo garantizar la resistencia y la disponibilidad de las aplicaciones si se
producen interrupciones del servicio.
Configuración de BCDR
Al migrar a Azure, tenga en cuenta que, aunque la plataforma Azure proporcione algunas funcionalidades de
resistencia integradas, debe diseñar la implementación de Azure para sacarles el máximo partido.
La solución de BCDR dependerá de los objetivos de la empresa y estará influida por la estrategia de
implementación en Azure. Las implementaciones de infraestructura como servicio (IaaS) y plataforma como
servicio (PaaS) presentan diversos desafíos para BCDR.
Una vez en funcionamiento, las soluciones de BCDR se deben probar con regularidad para comprobar que la
estrategia sigue siendo viable.
Copia de seguridad de una implementación de IaaS
En la mayoría de los casos, una carga de trabajo local se retira tras la migración y la estrategia local para copias
de seguridad se debe extender o reemplazar. Si migra todo el centro de datos a Azure, tendrá que diseñar e
implementar una solución de copia de seguridad completa con tecnologías de Azure o soluciones de terceros
integradas.
Para cargas de trabajo que se ejecutan en máquinas virtuales de IaaS de Azure, tenga en cuenta estas soluciones
de copia de seguridad:
Azure Backup: proporciona copias de seguridad coherentes con la aplicación para máquinas virtuales
Windows y Linux de Azure.
Instantáneas de almacenamiento: toma instantáneas de Blob Storage.
Azure Backup
Azure Backup crea puntos de recuperación de datos que se almacenan en Azure Storage. Azure Backup puede
hacer una copia de seguridad de discos de máquina virtual de Azure y de Azure Files (versión preliminar). Azure
Files proporciona recursos compartidos de archivos en la nube, accesibles mediante Bloques de mensajes del
servidor.
Puede usar Azure Backup para realizar una copia de seguridad de las máquinas virtuales de las siguientes
maneras:
Copia de seguridad directa desde la configuración de la máquina vir tual : puede realizar copias de
seguridad de máquinas virtuales con Azure Backup directamente desde las opciones de la máquina virtual
en Azure Portal. Puede realizar una copia de seguridad de la VM una vez al día y restaurar el disco de la VM
cuando sea necesario. Azure Backup toma instantáneas de datos con reconocimiento de aplicaciones y no se
instala ningún agente en la máquina virtual.
Copia de seguridad directa en un almacén de Recover y Ser vices : puede realizar copias de seguridad
de las máquinas virtuales de IaaS mediante la implementación de un almacén de Azure Backup Recovery
Services. De esta forma, se proporciona una ubicación única para realizar el seguimiento y la administración
de las copias de seguridad así como opciones de copia de seguridad y restauración pormenorizadas. La copia
de seguridad se realiza hasta tres veces al día, en los niveles de archivo y de carpeta. No son copias basadas
en la aplicación y no son compatibles con Linux. Instale el agente de Microsoft Azure Recovery Services
(MARS) en cada máquina virtual de la que quiera realizar copias de seguridad mediante este método.
Protección de la máquina vir tual en Azure Backup Ser ver. Azure Backup Server se proporciona de
forma gratuita con Azure Backup. Una copia de seguridad de la máquina virtual se crea en el
almacenamiento local de Azure Backup Server. A continuación, se hace una copia de seguridad de Azure
Backup Server en Azure, en un almacén. Es una copia de seguridad basada en la aplicación, con una
granularidad completa en la frecuencia y la retención de la copia de seguridad. Puede hacer una copia de
seguridad en el nivel de la aplicación. Por ejemplo, al crear una copia de seguridad de SQL Server o
SharePoint.
Por seguridad, Azure Backup cifra los datos sobre la marcha mediante AES-256. Los envía a Azure a través de
HTTPS. Los datos en reposo de la copia de seguridad se cifran mediante el cifrado de Azure Storage.
Figura 10: Azure Backup.

Más información:
Obtenga información sobre Azure Backup.
Planeación de una infraestructura de copia de seguridad para VM de Azure.
Instantáneas de almacenamiento
Las máquinas virtuales de Azure se almacenan como blobs en páginas en Azure Storage. Dichas instantáneas
capturan el estado del blob en un momento específico del tiempo. Como un método de copia de seguridad
alternativo para discos de máquina virtual de Azure, puede tomar una instantánea de los blobs de
almacenamiento y copiarlos en otra cuenta de almacenamiento.
Puede copiar un blob completo o utilizar una copia de instantánea incremental para copiar solo los cambios
incrementales y reducir el espacio de almacenamiento. Como precaución adicional, puede habilitar la
eliminación temporal para las cuentas de Blob Storage. Con esta característica habilitada, un blob eliminado se
puede marcar para su eliminación, pero no se purga inmediatamente. Durante el período provisional, puede
restaurar el blob.
Más información:
Más información sobre Azure Blob Storage.
Más información sobre cómo crear una instantánea de blob.
Consulte un escenario de ejemplo de la copia de seguridad de Blob Storage.
Más información acerca de la eliminación temporal para blobs.
Recuperación ante desastres y conmutación por error forzada (versión preliminar) en Azure Storage
Copia de seguridad de terceros
Además, puede usar soluciones de terceros para realizar copias de seguridad de máquinas virtuales de Azure y
contenedores de almacenamiento en el almacenamiento local u otros proveedores en la nube. Para más
información, consulte las soluciones de copia de seguridad en Azure Marketplace.
Configuración de la recuperación ante desastres para aplicaciones IaaS
Además de proteger los datos, el planeamiento de BCDR debe tener en cuenta cómo garantizar la disponibilidad
de las aplicaciones y las cargas de trabajo si se produjera un desastre. En el caso de cargas de trabajo que se
ejecutan en las máquinas virtuales de IaaS de Azure y Azure Storage, tenga en cuenta las soluciones de las
secciones siguientes.
Azure Site Recovery
Azure Site Recovery es el servicio principal de Azure para garantizar la puesta en marcha de las máquinas
virtuales de Azure y la disponibilidad de las aplicaciones de máquina virtual cuando se produzcan
interrupciones del servicio.
Site Recovery replica las máquinas virtuales de una región primaria en una región secundaria de Azure. Si se
produce un desastre, se realiza una conmutación por error de las máquinas virtuales de la región primaria y el
acceso a las mismas se sigue produciendo con normalidad en la región secundaria. Cuando las operaciones
vuelven al estado normal, puede realizar una conmutación por recuperación de las máquinas virtuales a la
región primaria.
Ilustración 11: Recuperación del sitio.

Más información:
Consulte los escenarios de recuperación ante desastres para VM de Azure.
Más información sobre la configuración de la recuperación ante desastres de una VM de Azure tras la
migración.
Procedimiento recomendado: uso de discos administrados y
conjuntos de disponibilidad
Azure usa conjuntos de disponibilidad para agrupar lógicamente las máquinas virtuales y para aislar las
máquinas virtuales de un conjunto de otros recursos. Las máquinas virtuales de un conjunto de disponibilidad
se distribuyen entre varios dominios de error con subsistemas independientes, lo cual protege frente a errores
locales. Las máquinas virtuales también se distribuyen entre varios dominios de actualización y esto impide el
reinicio simultáneo de todas las máquinas virtuales del conjunto.
Los discos administrados de Azure simplifican la administración de los discos de Azure Virtual Machines, ya que
administran las cuentas de almacenamiento asociadas a los discos de las máquinas virtuales.
Use discos administrados siempre que sea posible. Solo tiene que especificar el tipo de almacenamiento
que desea usar y el tamaño del disco que necesita y Azure crea y administra el disco automáticamente.
Puede convertir los discos existentes en discos administrados.
Debe crear las máquinas virtuales en conjuntos de disponibilidad para alta resistencia y disponibilidad.
Cuando se producen errores previstos e imprevistos, los conjuntos de disponibilidad garantizan que al
menos una de las máquinas virtuales del conjunto permanece disponible.
Figura 12: Discos administrados.

Más información:
Lea la introducción a Managed Disks.
Más información sobre cómo convertir discos en administrados.
Más información sobre la administración de la disponibilidad de las VM Windows en Azure.
Procedimiento recomendado: supervisión del uso de recursos y el

rendimiento
Puede que haya trasladado las cargas de trabajo a Azure por sus grandes funcionalidades de escalado. Sin
embargo, mover la carga de trabajo no significa que Azure vaya a implementar automáticamente el escalado sin
intervención del usuario. Estos son dos ejemplos:
Si una organización de marketing inserta un nuevo anuncio de televisión que genera un 300 % más de
tráfico, esto podría provocar problemas de disponibilidad del sitio. La carga de trabajo recién migrada podría
alcanzar los límites asignados y bloquearse.
Si hay un ataque de denegación de servicio distribuido (DDoS) en la carga de trabajo migrada, en este caso
no es conveniente escalar. Desea evitar que el origen de los ataques alcance sus recursos.
Estos dos casos tienen resoluciones diferentes, pero en ambos se necesita información sobre lo que sucede con
la supervisión del rendimiento y el uso.
Azure Monitor puede ayudar a mostrar estas métricas y dar respuesta por medio de alertas, escalabilidad
automática, centros de eventos y aplicaciones lógicas.
También puede integrar una aplicación de SIEM de terceros para supervisar los registros de Azure en
busca de eventos de auditoría y rendimiento.
Figura 13: Azure Monitor.

Más información:
Más información acerca de Azure Monitor.
Procedimientos recomendados para supervisión y diagnóstico.
Más información sobre la escalabilidad automática.
Más información sobre cómo enrutar datos de Azure a una herramienta de SIEM.
Procedimiento recomendado: Activación del registro de diagnóstico

Los recursos de Azure generan un número razonable de métricas de registro y datos de telemetría. De forma
predeterminada, la mayoría de los tipos de recursos no tienen el registro de diagnóstico habilitado. Al habilitar
el registro de diagnóstico en los recursos, puede consultar los datos de registro y crear alertas y cuadernos de
estrategias en función de los mismos.
Cuando se habilita el registro de diagnóstico, cada recurso tendrá un conjunto específico de categorías.
Seleccione una o varias categorías de registro y una ubicación para los datos de registro. Los registros se
pueden enviar a una cuenta de almacenamiento, un centro de eventos o a los registros de Azure Monitor.
Figura 14: Registro de diagnóstico.
Más información:
Más información de recopilación y consumo de datos de registro.
Más información sobre lo que se admite para el registro de diagnóstico.
Procedimiento recomendado: configuración de alertas y cuadernos

de estrategias
Con el registro de diagnóstico habilitado para los recursos de Azure, puede empezar a usar los datos de registro
para crear alertas personalizadas.
Las alertas le informan de forma proactiva cuando se detectan condiciones en los datos que supervisa. A
continuación, puede solucionar problemas antes de que los usuarios del sistema puedan
experimentarlos. Puede alertar de los valores de las métricas, las consultas de búsqueda de registros, los
eventos del registro de actividad, el mantenimiento de la plataforma y la disponibilidad del sitio web.
Cuando se desencadenan alertas, es posible ejecutar un cuaderno de estrategias de aplicaciones lógicas.
Un cuaderno de estrategias le ayuda a automatizar y coordinar una respuesta a una alerta específica. Los
cuadernos de estrategias se basan en Azure Logic Apps. Puede usar plantillas de aplicaciones lógicas para
crear cuadernos de estrategias, o bien crear sus propios cuadernos.
Por ejemplo, puede crear una alerta que se desencadene cuando se produzca un examen de puertos en
un grupo de seguridad de red. Puede configurar un cuaderno de estrategias que se ejecuta y bloquea la
dirección IP de origen del examen.
Otro ejemplo podría ser una aplicación que tiene una fuga de memoria. Cuando el uso de memoria llega
a un punto determinado, un cuaderno de estrategias puede reciclar el proceso.
Figura 15: Alertas.
Más información:
Más información sobre las alertas.
Más información sobre cuadernos de estrategias de seguridad que responden a alertas de Security Center.
Procedimiento recomendado: uso del panel de Azure

Azure Portal es una consola unificada basada en web que le permite crear, administrar y supervisar cualquier
elemento, desde aplicaciones web sencillas a aplicaciones complejas en la nube. Incluye un panel personalizable
y opciones de accesibilidad.
Puede crear varios paneles y compartirlos con otras personas que tengan acceso a sus suscripciones de
Azure.
Con este modelo compartido, el equipo tiene visibilidad sobre el entorno de Azure, lo que le ayuda a ser
proactivo al administrar los sistemas en la nube.
Figura 16: Panel de Azure.
Más información:
Más información sobre cómo crear un panel.
Más información sobre la estructura del panel.
Procedimiento recomendado: información de los planes de soporte

técnico
En algún momento necesitará colaborar con el personal de soporte técnico o el personal de soporte técnico de
Microsoft. Es fundamental contar con un conjunto de directivas y procedimientos para obtener soporte técnico
durante escenarios como la recuperación ante desastres. Además, se debe formar a los administradores y al
personal de soporte técnico sobre la implementación de esas directivas.
En el improbable caso de que un problema en un servicio de Azure afecte a la carga de trabajo, los
administradores deben saber cómo enviar una incidencia de soporte técnico a Microsoft de la manera
más adecuada y eficaz.
Familiarícese con los diversos planes de soporte técnico que ofrece Azure. Se ofrecen desde tiempos de
respuesta específicos para instancias de desarrollador hasta soporte técnico Premier, con un tiempo de
respuesta inferior a 15 minutos.
Figura 17: Planes de soporte técnico.

Más información:
Lea una introducción a los planes de soporte técnico de Azure.
Obtenga información adicional sobre los contratos de nivel de servicio (SLA).
Procedimiento recomendado: Administración de actualizaciones

Mantener las máquinas virtuales de Azure actualizadas con el sistema operativo y las actualizaciones de
software más recientes es una tarea rutinaria masiva. La capacidad de exponer todas las máquinas virtuales,
determinar qué actualizaciones se necesitan e insertar de modo automático esas actualizaciones es algo
extremadamente valioso.
Puede usar Update Management de Azure Automation para administrar las actualizaciones del sistema
operativo. Esto se aplica a las máquinas que ejecutan equipos con Windows y Linux, y se implementan en
Azure, de forma local y en otros proveedores en la nube.
Utilice Update Management para evaluar rápidamente el estado de las actualizaciones disponibles en
todos los equipos agente y administrar la instalación de las actualizaciones.
Update Management se puede habilitar en máquinas virtuales directamente desde una cuenta de Azure
Automation. También puede actualizar una sola máquina virtual en la página de la máquina virtual en
Azure Portal.
Además, puede registrar máquinas virtuales de Azure con System Center Configuration Manager. A
continuación, puede migrar la carga de trabajo de Configuration Manager a Azure y realizar informes y
actualizaciones de software desde una única interfaz web.
Figura 18: Actualizaciones de VM.

Más información:
Más información sobre Update Management en Azure.
Más información sobre la integración de Configuration Manager con Update Management.
Preguntas más frecuentes acerca de Configuration Manager en Azure.
Implementación de un proceso de administración de cambios

Al igual que con cualquier sistema de producción, cualquier tipo de cambio puede afectar al entorno. Un
proceso de administración de cambios que requiere que se envíen solicitudes para realizar cambios en los
sistemas de producción es una adición valiosa en el entorno migrado.
Puede crear marcos de procedimientos recomendados para la administración de cambios para aumentar el
conocimiento de los administradores y personal de soporte técnico.
Puede usar Azure Automation para ayudar con la administración de configuración y el seguimiento de
cambios para los flujos de trabajo migrados.
Al forzar el proceso de administración de cambios, puede usar los registros de auditoría para vincular los
registros de cambios de Azure con las solicitudes de cambio existentes. Entonces, si ve un cambio realizado
sin la correspondiente solicitud de cambio, puede investigar qué salió mal en el proceso.
Azure tiene una solución de seguimiento de cambios en Azure Automation:
La solución realiza un seguimiento de los cambios efectuados en el software de Windows y Linux, en los
archivos y las claves del Registro de Windows, en los servicios de Windows y en los demonios de Linux.
Los cambios en los servidores supervisados se envían a Azure Monitor para ser procesados.
La lógica se aplica a los datos recibidos y el servicio de nube registra los datos.
En el panel de Change Tracking, puede ver fácilmente los cambios realizados en su infraestructura de
servidor.
Figura 19: Gráfico de administración de cambios.

Más información:
Obtenga información sobre Change Tracking.
Más información sobre las funcionalidades de Azure Automation.
Pasos siguientes
Examine otros procedimientos recomendados:
Procedimientos recomendados para las redes después de la migración.
Procedimientos recomendados para la administración de costos después de la migración.
Lista de comprobación de procedimientos
recomendados para la migración a la nube de
Azure
Si está interesado en la migración a Azure, comience por la guía de migración de Azure de Cloud Adoption
Framework. Esta guía le guiará a través de un conjunto de herramientas y enfoques básicos para la migración
de máquinas virtuales a la nube.
En las siguientes listas de comprobación encontrará procedimientos recomendados para la migración a la nube
de Azure que van más allá de las herramientas nativas de la nube básicas. Aquí se describen las áreas comunes
de complejidad que podrían requerir que el ámbito de la migración se ampliara más allá de la guía de migración
a Azure.
Procedimientos recomendados de migración para la ampliación del

ámbito controlado por la empresa
Apoyo de los mercados globales : El negocio opera en varias regiones geográficas con diferentes
requisitos de soberanía de datos. Para cumplir esos requisitos, debe tener en cuenta consideraciones
adicionales tanto en el examen de los requisitos previos como en la distribución de los recursos durante la
migración.
Procedimientos recomendados de migración para la ampliación del

ámbito controlado por la tecnología
Migración de VMware : la migración de hosts de VMware puede acelerar el proceso de migración global.
Todos los hosts de VMware migrados pueden mover varias cargas de trabajo a la nube. Después de la
migración, tanto las máquinas virtuales como las cargas de trabajo pueden permanecer en VMware o
migrarse a las funcionalidades modernas de la nube.
Migración de SQL Ser ver : la migración de instancias de SQL Server puede acelerar el proceso general de
migración. Cada instancia migrada puede mover varias bases de datos y servicios, con lo que se podrían
acelerar varias cargas de trabajo.
Varios centros de datos : la migración de varios centros de datos agrega una complejidad significativa.
Durante todos y cada uno de los procesos del traslado (evaluación, migración, optimización y
administración) se describen consideraciones adicionales para preparar entornos más complejos.
Los requisitos de datos superan la capacidad de la red : con frecuencia, las empresas optan por
migrar a la nube porque la capacidad, la velocidad o la estabilidad de un centro de datos existente ya no son
satisfactorias. Lamentablemente, esas mismas limitaciones agregan complejidad al proceso de migración y
requieren un planeamiento adicional durante los procesos de evaluación y migración.
Estrategia de cumplimiento o de gobernanza : si la gobernanza y el cumplimiento son vitales para el
éxito de una migración, tanto los equipos de gobernanza de TI como el equipo de adopción de la nube deben
garantizar una mayor alineación entre ellos.
Otros procedimientos recomendados de migración

Configuración de redes para las cargas de trabajo migradas a Azure
Implementación de una infraestructura de migración
Procedimientos recomendados para gestionar los costos y el tamaño de las cargas de trabajo migradas a
Azure
Escalado de una migración a Azure
Pasos siguientes
La siguiente información es un buen punto de partida para examinar los procedimientos recomendados para la
migración de Azure.
A menudo, el ámbito de una migración implica la transición de varios centros de datos. La siguiente guía amplía
el ámbito de la guía de migración de Azure para dar respuesta a varios centros de datos.

La mayor parte del trabajo que se requiere en esta expansión del ámbito se produce durante los procesos de
requisitos previos, evaluación y optimización de procesos de una migración.
Requisitos previos sugeridos

Antes de iniciar la migración, debe crear epopeyas dentro de la herramienta de administración de proyectos
para cada uno de los centros de datos que se van a migrar. Cada epopeya representa un centro de datos. Es
importante comprender los resultados y las motivaciones empresariales de esta migración. Use estas
motivaciones para priorizar la lista de epopeyas (o centros de datos). Por ejemplo, si la migración está motivada
por un deseo de abandonar un centro de datos antes de que haya que renovar el alquiler, cada epopeya se
debería priorizar en función de la fecha de renovación del alquiler.
Dentro de cada epopeya, las cargas de trabajo que se van a evaluar y migrar se administran como
características. Cada recurso dentro de esa carga de trabajo se administra como un caso de usuario. El trabajo
necesario para evaluar, migrar, optimizar, promover, proteger y administrar cada recurso se representa como
tareas de cada recurso.
Los sprints o iteraciones consisten en una serie de tareas necesarias para migrar los recursos y los casos de
usuario confirmados por el equipo de adopción de la nube. Los lanzamientos se componen de una o varias
cargas de trabajo o características que se van a promocionar a producción.
Evaluación de los cambios en el proceso

Cuando se amplía el ámbito para dar respuesta a varios centros de datos, el cambio más importante en el
proceso de evaluación está relacionado con el registro y la priorización precisos de las cargas de trabajo y
dependencias entre los centros de datos.
Acción sugerida durante el proceso de evaluación
Evaluación de las dependencias entre centros de datos: Las herramientas de visualización de
dependencias de Azure Migrate pueden ayudar a identificar las dependencias. Usar este conjunto de
herramientas antes de la migración suele ser un procedimiento recomendado. Pero cuando la complejidad es
generalizada, se trata de un paso necesario en el proceso de evaluación. A través de una agrupación de
dependencias, la visualización puede ayudar a identificar los puertos y las direcciones IP de cualquiera de los
recursos que se necesitan para admitir la carga de trabajo.
IMPORTANT
En primer lugar, es necesario que un experto en la materia que entienda los esquemas de dirección IP y la ubicación de
los recursos identifique los recursos que residen en un centro de datos secundario.
Evalúe tanto las dependencias de nivel inferior como los clientes en la visualización para comprender las dependencias
bidireccionales.
La migración de varios centros de datos se parece al proceso de consolidación. Después de la migración, la nube
se convierte en la solución singular de centro de datos para varios recursos. La expansión de ámbito más
probable durante el proceso de migración es la validación y la alineación de las direcciones IP.
Acción sugerida durante el proceso de migración
A continuación se indican las actividades que afectan en gran medida al éxito de una migración en la nube:
Evaluación de los conflictos de red: Al consolidar los centros de recursos en un solo proveedor de nube,
es probable que cree conflictos de red, DNS u otros. Durante la migración, es importante comprobar si hay
conflictos para evitar interrupciones en los sistemas de producción hospedados en la nube.
Actualización de las tablas de enrutamiento: A menudo, las modificaciones en las tablas de
enrutamiento son necesarias al consolidar redes o centros de datos.
Optimización y promoción de los cambios del proceso

Durante la optimización, pueden ser necesarias pruebas adicionales.
Acción sugerida durante el proceso de optimización y promoción
Antes de la promoción, proporcione niveles adicionales de prueba durante esta expansión de ámbito. Durante
las pruebas, es importante probar el enrutamiento u otros conflictos de red. Además, es importante aislar la
aplicación implementada y volver a probar para asegurarse de que todas las dependencias se han migrado a la
nube. En este caso, el aislamiento implica separar el entorno implementado de las redes de producción. Si lo
hace, puede detectar recursos que se han pasado por alto y que se están ejecutando todavía en el entorno local.
Cambios en el proceso de protección y administración

Es poco probable que la expansión del ámbito altere los procesos seguros y administrados.
Pasos siguientes
Vuelva a la lista de comprobación para asegurarse de que el método de migración está totalmente alineado.
Lista de comprobación de procedimientos recomendados de migración
Guía de decisiones sobre regiones de Azure
Azure abarca muchas regiones de todo el mundo. Cada una de las regiones de Azure tiene unas características
concretas, lo que hace que elegir cuál de ellas se usa sea algo extraordinariamente importante. Estas incluyen
servicios disponibles, capacidad, restricciones y soberanía:
Ser vicios disponibles: los servicios que se implementan en cada región varían en función de varios
factores. Seleccione para la carga de trabajo una región que contenga el servicio que desea. Para más
información, consulte Productos disponibles por región.
Capacidad : cada región tiene una capacidad máxima. Esto puede afectar a los tipos de suscripciones que
pueden implementar los tipos de servicios y en qué circunstancias. La capacidad es diferente a las cuotas de
suscripción. Si planea una migración a gran escala del centro de datos a Azure, puede que quiera consultarlo
con el equipo de campo local de Azure o con el administrador de cuentas para confirmar que puede realizar
la implementación a la escala necesaria.
Restricciones: la implementación de servicios en determinadas regiones está sujeta a ciertas restricciones.
Por ejemplo, algunas regiones solo están disponibles como destino de copia de seguridad o de conmutación
por error. Otras restricciones que se deben tener en cuenta son los requisitos de soberanía de los datos.
Soberanía: determinadas regiones están dedicadas a entidades soberanas concretas. Aunque todas las
regiones son regiones de Azure, estas regiones soberanas están completamente aisladas del resto de Azure.
Microsoft no las administra necesariamente y podrían estar restringidas a determinados tipos de clientes.
Estas regiones soberanas son:
Azure China 21Vianet
Azure Alemania: Azure Alemania está en desuso en favor de regiones de Azure no soberanas estándar
en Alemania.
Azure Gobierno de EE. UU.
Microsoft administra dos regiones de Australia, pero se proporcionan para el gobierno australiano y
sus clientes y contratistas. Por lo tanto, estas regiones llevan unas restricciones del cliente similares a
las demás nubes soberanas.
Funcionamiento en varias regiones geográficas

Cuando las empresas operan en diversas regiones geográficas, lo que puede ser esencial para lograr resistencia,
se introduce una complejidad potencial en los siguientes aspectos:
Distribución de los recursos
Perfiles de acceso de los usuarios
Requisitos de cumplimiento
Resistencia regional
La selección regional es muy importante para la estrategia global de adopción de la nube. Empecemos por las
consideraciones sobre la red.
Consideraciones sobre la red

Cualquier implementación sólida en la nube requiere una red bien ponderada que tenga en cuenta las regiones
de Azure. Se debe tener en cuenta lo siguiente:
Las regiones de Azure se implementan por pares. Si se produce un error grave en una región, se designa
otra región dentro del mismo límite geopolítico como su región emparejada. La implementación en
regiones emparejadas debe considerarse una estrategia de resistencia principal y secundaria. Una
excepción a esta estrategia es Brazil South , que está emparejada con South Central US . Para más
información, consulte Regiones emparejadas de Azure.
Azure Storage admite almacenamiento con redundancia geográfica (GRS). Esto significa que se
almacenan tres copias de los datos en la región primaria y otras tres copias en la región emparejada.
En el almacenamiento con redundancia geográfica no se puede cambiar el emparejamiento del
almacenamiento.
Los servicios que se basan en este tipo de almacenamiento de Azure Storage pueden sacar el máximo
partido a esta funcionalidad de región emparejada. Para ello, se deben orientar las aplicaciones y la
red para que admitan dicha funcionalidad.
Si no planea usar el almacenamiento con redundancia geográfica para apoyar sus necesidades de
resistencia regional, no debe utilizar la región emparejada como secundaria. En caso de error regional,
los recursos de la región emparejada estarán sometidos a una gran presión mientras se migran los
recursos. Para evitarlo, se puede realizar la recuperación en un sitio alternativo y conseguir una mayor
velocidad durante la recuperación.
WARNING
No intente utilizar el almacenamiento con redundancia geográfica de Azure para las operaciones de copia de
seguridad o recuperación de máquinas virtuales. Use mejor Azure Backup y Azure Site Recovery, junto con Azure
Managed Disks, para respaldar la resistencia de las cargas de trabajo de infraestructura como servicio (IaaS).
Azure Backup y Azure Site Recovery funcionan de forma conjunta con el diseño de la red para facilitar la
resistencia regional para sus necesidades de IaaS y de copia de seguridad de datos. Asegúrese de que la
red está optimizada para que las transferencias de datos permanezcan en la red troncal de Microsoft, y
use el emparejamiento de redes virtuales si es posible. Algunas organizaciones de mayor tamaño con
implementaciones globales pueden usar en su lugar ExpressRoute Premium para enrutar el tráfico entre
regiones y ahorrarse los posibles costos de salida regionales.
Los grupos de recursos de Azure son específicos de cada región. Sin embargo, es normal que los
recursos de un grupo de recursos abarquen varias regiones. Tenga en cuenta que, en caso de error en
una región, las operaciones del plano de control en un grupo de recursos producirán un error en la
región afectada, aunque los recursos de otras regiones (dentro de ese grupo de recursos) sigan
funcionando. Esto puede afectar tanto al diseño de la red como al del grupo de recursos.
Muchos servicios de plataforma como servicio (PaaS) dentro de Azure admiten puntos de conexión de
servicio o Azure Private Link. Ambas soluciones afectan notablemente a aspectos de la red como la
resistencia, la migración y la gobernanza regionales.
Muchos servicios de PaaS se basan en sus propias soluciones de resistencia regional. Por ejemplo, tanto
Azure SQL Database como Azure Cosmos DB permiten realizar fácilmente réplicas en regiones
adicionales. Los servicios como Azure DNS no tienen dependencias regionales. A la hora de considerar
qué servicios va a utilizar en el proceso de adopción, asegúrese de que conoce a la perfección las
funcionalidades de la conmutación por error y los pasos de recuperación que puede necesitar cada
servicio de Azure.
Además de realizar la implementación en varias regiones para permitir la recuperación ante desastres,
muchas organizaciones deciden usar un patrón activo-activo en la implementación para que no sea
necesaria ninguna conmutación por error. Este método ofrece las ventajas adicionales de equilibrio de
carga global, tolerancia a errores adicional y mejoras del rendimiento de la red. Para sacar el máximo
partido a este patrón, las aplicaciones deben admitir la ejecución activa-activa en varias regiones.
WARNING
Las regiones de Azure son construcciones de alta disponibilidad a las que se ha aplicado un Acuerdo de Nivel de Servicio a
los servicios que se ejecutan en ellas. Pero nunca debe haber dependencia de una sola región en las aplicaciones con
misiones críticas. Disponga siempre de algún plan contra errores regionales y practique medidas de recuperación y de
mitigación.
Después de tener en cuenta la topología de red, es necesario consultar la documentación adicional y la

alineación de los procesos que podría ser necesaria. El enfoque siguiente puede ayudar a evaluar los desafíos
posibles y a establecer una línea de acción general:
Considere una implementación de disponibilidad y gobernanza más sólida.
Realice un inventario de las geografías afectadas. Cree una lista de las regiones y los países afectados.
Documente los requisitos de soberanía de datos. ¿Los países identificados tienen requisitos de cumplimiento
que rigen la soberanía de datos?
Documente la base de usuarios. ¿La migración a la nube afectará a los empleados, asociados o clientes del
país identificado?
Documente los centros de datos y los recursos. ¿En el país identificado hay recursos que se podrían incluir en
el trabajo de migración?
Documente los requisitos de disponibilidad y conmutación por error de la SKU regional.
Alinee los cambios en el proceso de migración para dirigir el inventario inicial.
Complejidad de documentos
La tabla siguiente puede ayudar a documentar los resultados de los pasos anteriores:
C EN T RO S DE
USUA RIO S DATO S O REQ UISITO S DE
EM P L EA DO S EXT ERN O S REC URSO S SO B ERA N ÍA DE
REGIO N C O UN T RY LO C A L ES LO C A L ES LO C A L ES DATO S
Norteamérica Estados Unidos Sí Asociados y Sí No

clientes
Norteamérica Canadá No Clientes Sí Sí
Europa Alemania Sí Asociados y No, solo red Sí

clientes
Asia Pacífico Corea del Sur Sí Asociados Sí No
Importancia de la soberanía de datos

En todo el mundo, las organizaciones gubernamentales han empezado a establecer requisitos de soberanía de
datos, como el Reglamento general de protección de datos (RGPD). Con frecuencia, los requisitos de
cumplimiento de esta naturaleza requieren localización dentro de una región específica o, incluso, dentro de un
país específico para proteger a sus ciudadanos. En algunos casos, los datos que pertenecen a clientes,
empleados o asociados se deben almacenar en una plataforma en la nube dentro de la misma región en que se
encuentra el usuario final.
Abordar este desafío ha sido una motivación importante para que las empresas que operan a escala global
realicen la migración a la nube. Para mantener los requisitos de cumplimiento, algunas empresas han optado
por implementar recursos de TI duplicados en los proveedores de nube dentro de la región. En la tabla anterior,
Alemania es un buen ejemplo de este escenario. En este ejemplo se incluyen clientes, asociados y empleados,
pero no los recursos de TI actuales de Alemania. Esta empresa puede optar por implementar algunos recursos
en un centro de datos dentro del área del RGPD, posiblemente incluso usando los centros de datos de Azure
Alemania. Entender cuáles son los datos a los que afectará el RGPD podría ayudar al equipo de adopción de la
nube a comprender cuál es el mejor enfoque de migración en este caso.
¿Por qué es importante la ubicación de los usuarios finales?
Las empresas que admiten usuarios finales en varios países han desarrollado soluciones técnicas para abordar
el tráfico de usuario final. En algunos casos, esto implica la localización de los recursos. En otros escenarios, la
empresa puede optar por implementar soluciones globales de red de área extensa (WAN) para abordar bases de
usuarios dispares a través de soluciones centradas en la red. En cualquier caso, la estrategia de migración se
puede ver afectada por los perfiles de uso de esos distintos usuarios finales.
Dado que la empresa admite empleados, asociados y clientes de Alemania sin tener actualmente allí centros de
datos, es probable que esta empresa haya implementado una solución de línea alquilada. Este tipo de solución
enruta el tráfico a los centros de datos de otros países. Este enrutamiento existente presenta un riesgo
importante al rendimiento percibido de las aplicaciones migradas. Insertar saltos adicionales en una WAN
global establecida y ajustada puede crear la percepción de que las aplicaciones bajan su rendimiento después de
la migración. Buscar y corregir estos problemas puede agregar retrasos importantes a un proyecto.
En cada uno de los procesos siguientes, se incluyen instrucciones para abordar esta complejidad en lo referente
a los requisitos previos, los recursos, la migración y los procesos de optimización. Comprender los perfiles de
usuario de cada país resulta crítico para administrar correctamente esta complejidad.
¿Por qué es importante la ubicación de los centros de datos?
La ubicación de los centros de datos existentes puede afectar a una estrategia de migración. Por ejemplo:
Decisiones sobre la arquitectura: la región de destino es uno de los primeros pasos que se incluyen en el
diseño de la estrategia de migración. Suele verse afectado por la ubicación de los recursos existentes. Además, la
disponibilidad de los servicios en la nube y el costo unitario de esos servicios puede variar de una región a otra.
Entender dónde se encuentran los recursos actuales y futuros afecta a las decisiones en materia de arquitectura
y puede influir en las estimaciones de presupuesto.
Dependencias de los centros de datos: los datos de la tabla anterior muestran que es probable que existan
dependencias entre varios centros de datos globales. En muchas organizaciones que operan en este tipo de
escala, es posible que esas dependencias no estén documentadas o que no se comprendan bien. El enfoque de
la empresa para evaluar los perfiles de usuario ayuda a identificar algunas de estas dependencias en la
organización. Además, el equipo debe explorar otros pasos de evaluación que puedan mitigar los riesgos y las
complejidades que surgen de las dependencias.
Implementación del enfoque general

El enfoque siguiente usa un modelo controlado por datos para abordar las complejidades de la migración
global. Cuando el ámbito de una migración abarca varias regiones, el equipo de adopción de la nube debe
evaluar las consideraciones de preparación siguientes:
Es posible que la soberanía de datos requiera localizar algunos recursos, pero puede que muchos de los
recursos no estén regulados por esas restricciones de cumplimiento. Aspectos como el registro, la creación
de informes, el enrutamiento de red, la identidad y otros servicios centrales de TI pueden ser elegibles para
hospedarlos como servicios compartidos entre varias suscripciones o, incluso, varias regiones. Al realizar la
evaluación, el equipo de adopción de la nube debería usar un modelo de servicio compartido para esos
servicios, como se describe en la arquitectura de referencia para una topología radial con servicios
compartidos.
Cuando se implementan varias instancias de entornos similares, un generador de entornos podría crear
coherencia, mejorar la gobernanza y acelerar la implementación. La guía de gobernanza de empresas
complejas establece un enfoque que crea un entorno que se escala en varias regiones.
Cuando el equipo esté cómodo con el enfoque de línea de base y la preparación esté alineada, deberían tenerse
en cuenta algunos requisitos previos controlados por datos:
Detección general: complete la tabla de documentación de la complejidad.
Realice un análisis de los perfiles de usuario en cada país afectado: es importante entender el
enrutamiento del usuario final general en una etapa temprana del proceso de migración. Cambiar las líneas
alquiladas globales y agregar conexiones como ExpressRoute a un centro de datos en la nube pueden
requerir meses de retrasos en la red. Aborde esta complejidad tan pronto como sea posible en el proceso.
Racionalización del patrimonio digital inicial: cada vez que se introducen complejidades en una
estrategia de migración, se debe realizar una racionalización del patrimonio digital inicial. Consulte las
instrucciones sobre racionalización del patrimonio digital.
Requisitos adicionales del patrimonio digital: establezca directivas de etiquetado para identificar
todas las cargas de trabajo afectadas por los requisitos de soberanía de datos. Las etiquetas necesarias
deben empezar en la racionalización del patrimonio digital y pasar a los recursos migrados.
Evaluación de un modelo radial: a menudo, los sistemas distribuidos comparten dependencias comunes.
Por lo general, esas dependencias se pueden abordar mediante la implementación de un modelo radial. Si
bien ese tipo de modelo está fuera del ámbito del proceso de migración, se debe marcar para considerarlo
durante las iteraciones futuras de los procesos de preparación.
Asignación de prioridades de los trabajos pendientes de migración: cuando se necesitan cambios
en la red para respaldar la implementación en producción de una carga de trabajo que admite varias
regiones, el equipo de estrategia de nube debe realizar un seguimiento de las escalaciones y administrarlas
con respecto a esos cambios en la red. El nivel más alto de respaldo ejecutivo ayuda a acelerar el cambio, ya
que se libera al equipo de estrategia del trabajo de cambiar las prioridades del trabajo pendiente y de que los
cambios en la red no bloquean las cargas de trabajo globales. La prioridad de dichas cargas de trabajo solo
se debe establecer una vez que se completen los cambios en la red.
Estos requisitos previos ayudan a establecer procesos que puedan abordar esta complejidad durante la
ejecución de la estrategia de migración.

Al enfrentarse a las complejidades de los recursos y la base de usuarios globales de los escenarios de migración,
se deben agregar algunas actividades clave a la evaluación de los candidatos para la migración. Estas
actividades producen datos para comprender bien los obstáculos y los resultados de los usuarios y recursos
globales.
Evaluación de las dependencias entre centros de datos: Las herramientas de visualización de
dependencias de Azure Migrate pueden ayudar a identificar las dependencias. El uso de estas herramientas
antes de la migración es un procedimiento recomendado. Cuando existe una complejidad global, pasa a ser un
paso necesario para el proceso de evaluación. A través de una agrupación de dependencias, la visualización
puede ayudar a identificar los puertos y las direcciones IP de cualquiera de los recursos que se necesitan para
admitir la carga de trabajo.
IMPORTANT
En primer lugar, es necesario que un experto en la materia que entienda los esquemas de dirección IP y la ubicación de
los recursos identifique los recursos que residen en un centro de datos secundario.
Evalúe tanto las dependencias de nivel inferior como los clientes en la visualización para comprender las dependencias
bidireccionales.
Identificación del impacto en el usuario global: las salidas del análisis de perfiles de usuario de requisito
previo deben identificar las cargas de trabajo afectadas por los perfiles de usuario globales. Cuando un
candidato a la migración se encuentra en la lista de cargas de trabajo afectadas, el arquitecto que prepara la
migración debe consultar a los expertos en redes y operaciones para validar las expectativas de enrutamiento y
rendimiento de la red. Como mínimo, la arquitectura debe incluir una conexión ExpressRoute entre el centro de
operaciones de red más cercano y Azure. La arquitectura de referencia para las conexiones de ExpressRoute
puede ayudar a configurar la conexión necesaria.
Diseño para el cumplimiento: las salidas del análisis de perfiles de usuario de requisito previo deben
identificar las cargas de trabajo afectadas por los requisitos de soberanía de datos. Durante las actividades de
arquitectura del proceso de evaluación, el arquitecto asignado debe consultar a expertos en cumplimiento para
comprender los requisitos de migración e implementación en varias regiones. Esos requisitos afectan
considerablemente a las estrategias de diseño. Las arquitecturas de referencia para aplicaciones web de varias
regiones y aplicaciones de n niveles de varias regiones pueden contribuir al diseño.
WARNING
Al usar cualquiera de las arquitecturas de referencia anteriores, puede ser necesario excluir elementos de datos específicos
de los procesos de replicación para cumplir con los requisitos de soberanía de datos. Esto agregará un paso adicional al
proceso de promoción.

Al migrar una aplicación que se debe implementar en varias regiones, el equipo de adopción de la nube debe
considerar algunos aspectos. Por ejemplo, el diseño del almacén de Azure Site Recovery, el diseño del servidor
de configuración y proceso, los diseños del ancho de banda de la red y la sincronización de datos.
Diseño del almacén de Azure Site Recover y: Azure Site Recovery es la herramienta sugerida para la
replicación nativa de la nube y la sincronización de recursos digitales en Azure. Site Recovery replica los datos
sobre el recurso en un almacén de Site Recovery, que está enlazado a una suscripción específica en un centro de
datos de Azure y una región específicos. Al replicar recursos en una segunda región, es posible que también se
necesite un segundo almacén de Site Recovery.
Diseño del ser vidor de configuración y proceso: Site Recovery funciona con una instancia local de un
servidor de configuración y proceso, que está enlazado a un almacén de Site Recovery único. Esto significa que
es posible que sea necesario instalar una segunda instancia de estos servidores en el centro de datos de origen
para facilitar la replicación.
Diseño del ancho de banda de la red: durante la replicación y la sincronización en curso, los datos binarios
se mueven a través de la red, desde el centro de datos de origen al almacén de Site Recovery en el centro de
datos de Azure de destino. Este proceso consume ancho de banda. La duplicación de la carga de trabajo en una
segunda región duplicará la cantidad de ancho de banda consumido. Cuando el ancho de banda es limitado o
una carga de trabajo implica una gran cantidad de configuración o la desviación de los datos, puede interferir
con el tiempo que se necesita para completar la migración. Lo que es más importante, puede afectar a la
experiencia de los usuarios o aplicaciones que siguen dependiendo del ancho de banda del centro de datos de
origen.
Sincronización de datos: a menudo, el mayor consumo de ancho de banda se origina en la sincronización de
la plataforma de datos. Tal como se define en las arquitecturas de referencia de las aplicaciones web de varias
regiones y las aplicaciones de n niveles de varias regiones, a menudo se requiere la sincronización de datos para
mantener alineadas las aplicaciones. Si este es el estado operativo deseado de la aplicación, puede ser
aconsejable realizar una sincronización entre la plataforma de datos de origen y cada una de las plataformas de
nube. Hágalo antes de migrar los recursos de la aplicación y de nivel intermedio.
Recuperación ante desastres de Azure a Azure: una opción alternativa puede reducir aún más la
complejidad. Si las estrategias de sincronización de datos y escalas de tiempo van orientadas a una
implementación en dos pasos, una solución aceptable podría ser la recuperación ante desastres de Azure a
Azure. En este escenario, la carga de trabajo se migra al primer centro de datos de Azure con un solo almacén de
Site Recovery y un diseño de servidor de configuración o proceso. Después de probar la carga de trabajo, se
puede recuperar en un segundo centro de recursos de Azure desde los recursos migrados. Este enfoque reduce
el impacto en los recursos del centro de datos de origen y usa las velocidades de transferencia más rápidas y los
límites altos de ancho de banda disponibles entre los centros de datos de Azure.
NOTE
Este enfoque puede aumentar los costos de migración a corto plazo debido a los cargos adicionales de ancho de banda
de salida.

A medida que se enfrenta a la complejidad global durante la optimización y la promoción, podría ser necesario
duplicar los esfuerzos en cada una de las regiones adicionales. Cuando es aceptable una sola implementación,
aun así, podría tener que duplicar los planes de cambio y prueba empresarial.
Prueba preliminar de optimización: una prueba de automatización inicial puede identificar posibles
oportunidades de optimización, como con cualquier trabajo de migración. En el caso de cargas de trabajo
globales, pruebe la carga de trabajo en cada región de forma independiente. Los cambios de configuración
secundarios en la red o en el centro de datos de Azure de destino pueden afectar al rendimiento.
Planes de cambios empresariales: en cualquier escenario de migración complejo, cree un plan de cambio
empresarial. Este plan garantiza una comunicación clara con respecto a cualquier cambio en los procesos
empresariales, las experiencias de usuario y la temporización de las tareas necesarias para integrar los cambios.
En el caso de los trabajos de migración global, el plan debe incluir las consideraciones para los usuarios finales
de cada geografía afectada.
Pruebas empresariales: junto con el plan de cambio empresarial, es posible que se requieran pruebas
empresariales en cada región. Estas pruebas garantizan un rendimiento adecuado y el cumplimiento de los
patrones de enrutamiento de red modificados.
Pilotos de promoción: a menudo, la promoción se realiza como una actividad única, reenrutando el tráfico de
producción a las cargas de trabajo migradas. En el caso de los trabajos de liberación globales, la promoción
debe realizarse en paquetes piloto (o colecciones predefinidas de usuarios). Esto permite que el equipo de
estrategia de la nube y el equipo de adopción de la nube observen un mejor rendimiento y mejoren el respaldo
de los usuarios de cada región. Por lo general, los pilotos de promoción se controlan en el nivel de red al
cambiar el enrutamiento de intervalos IP específicos desde los recursos de carga de trabajo de origen a los
recursos migrados recientemente. Una vez que se migra una colección especificada de usuarios finales, es
posible volver a enrutar el grupo siguiente.
Optimización de pilotos: una de las ventajas de los paquetes piloto de promoción es que permiten
observaciones más profundas y la optimización adicional de los recursos implementados. Después de un
período breve de uso de producción por parte del primer piloto, se sugiere perfeccionar más los recursos
migrados cuando así lo permitan los procedimientos de operaciones de TI.
Procedimientos recomendados cuando los
requisitos de datos superan la capacidad de la red
durante un esfuerzo de migración
En una migración a la nube, los recursos se replican y se sincronizan por la red entre el centro de datos existente
y la nube. No es infrecuente que los requisitos de tamaño de datos existentes de varias cargas de trabajo
superen la capacidad de la red. En dicho escenario, el proceso de migración se puede ralentizar de manera
considerable o, en algunos casos, se puede detener por completo. En las instrucciones siguientes se expande el
ámbito de la Guía de migración a Azure para proporcionar una solución para las limitaciones de la red.

La mayor parte del trabajo que se requiere en esta expansión del ámbito se produce durante las fases de
requisitos previos, evaluación y migración de un trabajo de migración.

Validación de los riesgos de la capacidad de la red: La racionalización del patrimonio digital es un
requisito previo muy recomendado, especialmente si existen preocupaciones con respecto a sobrecargar la
capacidad de red disponible. Durante la racionalización del patrimonio digital, se recopila un inventario de los
recursos digitales. Dicho inventario debe incluir los requisitos de almacenamiento existentes en todo el
patrimonio digital.
Tal como se describe en Riesgos de replicación: física de la replicación, ese inventario se puede usar para calcular
el tamaño total de los datos de la migración, que se puede comparar con el ancho de banda total disponible
para la migración. Si esa comparación no se alinea con el tiempo requerido para el cambio empresarial, la
información de este artículo puede ayudar a acelerar la velocidad de la migración, lo que disminuye el tiempo
requerido para migrar el centro de datos.
Transferencia sin conexión de almacenes de datos independientes: en el diagrama siguiente se
muestran ejemplos de transferencias de datos en línea y sin conexión con Azure Data Box. Estos enfoques se
pueden usar para enviar grandes volúmenes de datos a la nube antes de la migración de las cargas de trabajo.
En una transferencia de datos sin conexión, los datos de origen se copian en Azure Data Box y, a continuación, se
envían físicamente a Microsoft para su transferencia a una cuenta de Azure Storage como archivo o blob. Este
proceso se puede usar para enviar datos que no estén vinculados directamente a una carga de trabajo
específica, antes de los demás esfuerzos de migración. Esto reduce la cantidad de datos que es necesario enviar
por la red y permite completar la migración a pesar de las restricciones de la red.
Este enfoque se puede usar para transferir datos desde HDFS, copias de seguridad, archivos, servidores de
archivos y aplicaciones. La guía técnica existente explica cómo usar este enfoque para transferir datos desde un
almacén de HDFS o desde discos con SMB, NFS, REST o el servicio de copia de datos a Data Box.
También hay soluciones de terceros asociados que usan Azure Data Box para la migración. Con estas soluciones
se mueve un gran volumen de datos por transferencia sin conexión, pero se sincroniza más adelante por la red a
una escala inferior.
Si los requisitos de almacenamiento de una carga de trabajo (o varias) superan la capacidad de la red, podrá
seguir usando Azure Data Box para la transferencia de datos sin conexión.
La transmisión a través de la red es el enfoque recomendado a menos que la red no esté disponible. La
velocidad de transferencia de los datos por la red (incluso con restricciones de ancho de banda) suele ser mayor
que el envío físico de la misma cantidad de datos mediante un mecanismo de transferencia sin conexión.
Si hay conectividad con Azure disponible, se debe realizar un análisis antes de usar Data Box, especialmente si la
migración de la carga de trabajo tiene limitaciones de tiempo. Solo se recomienda usar Data Box cuando el
tiempo para transferir los datos necesarios supere el tiempo de llenado, envío y restauración.
Análisis de la capacidad de red: si la transferencia de datos relacionados con la carga de trabajo requiere
una capacidad superior que la de la red, el equipo de adopción de la nube agrega una tarea de análisis adicional
al proceso de evaluación llamada Análisis de la capacidad de red. Durante este análisis, un miembro del equipo
calcula la cantidad de capacidad de red disponible y el tiempo de transferencia de datos necesario. Tenga en
cuenta que este miembro del equipo debe tener conocimientos sobre la red local y la conectividad de red.
La capacidad disponible se compara con los requisitos de almacenamiento de todos los recursos que se van a
migrar durante la migración actual. Si se necesita más almacenamiento que el ancho de banda disponible, los
recursos que admiten la carga de trabajo se seleccionan para una transferencia sin conexión.
IMPORTANT
Al concluir el análisis, podría ser necesario actualizar el plan de migración para que refleje el tiempo necesario para enviar,
restaurar y sincronizar los recursos que se van a transferir sin conexión.
Análisis de la desviación: se debe analizar cada recurso que se va a transferir sin conexión para conocer la
desviación del almacenamiento y la configuración. La desviación del almacenamiento es la cantidad de cambios
en el almacenamiento subyacente a lo largo del tiempo. La desviación de la configuración es el cambio en la
configuración del recurso a lo largo del tiempo. Desde el momento en el que se copia el almacenamiento al
momento en el que el recurso se envía a producción, esa desviación se podría perder. Si es necesario reflejar esa
desviación en el recurso migrado,deberá sincronizar el recurso local y el migrado. Marque esto para tenerlo en
cuenta durante la ejecución de la migración.
Cuando se usan mecanismos de transferencia sin conexión, no se suelen necesitar procesos de replicación, pero
sí procesos de sincronización. Entender los resultados del análisis de desviación a partir del proceso de
evaluación proporcionará información sobre las tareas necesarias durante la migración si hay algún recurso que
se transfiere sin conexión.
Copia del almacenamiento: este enfoque sirve para transferir datos de HDFS, copias de seguridad, archivos,
servidores de archivos o aplicaciones. La guía técnica existente explica cómo usar este enfoque para transferir
datos desde un almacén de HDFS o desde discos con SMB, NFS, REST o el servicio de copia de datos a Data Box.
También hay soluciones de terceros asociados que usan Azure Data Box para la migración. Con estas soluciones
se mueve un gran volumen de datos por transferencia sin conexión, pero se sincroniza más adelante por la red a
una escala inferior.
Envío del dispositivo: Después de copiar los datos, se puede enviar el dispositivo a Microsoft. Una vez
recibidos e importados los datos, están disponibles en una cuenta de Azure Storage.
Restauración del recurso: compruebe que los datos estén disponibles en la cuenta de almacenamiento. Si es
así, puede usarlos como blob o en Azure Files. Si los datos son un archivo VHD/VHDX, el archivo se puede
convertir en discos administrados. Esos discos administrados se pueden usar para crear instancias de una
máquina virtual, que crea una réplica del recurso local original.
Sincronización: si la sincronización de la desviación es obligatoria para un recurso migrado, se puede usar una
de las soluciones de terceros asociados para sincronizar los archivos hasta que se restaure el recurso.

Este cambio de ámbito probablemente no afecte a las actividades de optimización.

Este cambio del ámbito probablemente no afecte a las actividades de protección y administración.
Pasos siguientes
Vuelva a la lista de comprobación para asegurarse de que el método de migración está totalmente alineado.
Procedimientos recomendados para la
configuración de redes para las cargas de trabajo
migradas a Azure
A la hora de planear y diseñar la migración, además de la migración propiamente dicha, uno de los pasos más
importantes es el diseño y la implementación de redes de Azure. En este artículo se describen procedimientos
recomendados para la configuración de redes al migrar a implementaciones de infraestructura como servicio
(IaaS) y plataforma como servicio (PaaS) en Azure.
IMPORTANT
Los procedimientos recomendados y las opiniones que se describen en este artículo se basan en la plataforma de Azure y
las características del servicio disponibles en el momento de redactar el artículo. Las características y funcionalidades
cambian con el tiempo. Es posible que no todas las recomendaciones sean aplicables a su implementación, así que
seleccione las que sean válidas en su caso.
Diseño de redes virtuales

Azure proporciona redes virtuales con estas funcionalidades:
Los recursos de Azure se comunican de forma privada, directa y segura entre sí a través de redes virtuales.
Puede configurar conexiones de punto de conexión en redes virtuales para máquinas virtuales y servicios
que requieran comunicación por Internet.
Una red virtual es un aislamiento lógico de la nube de Azure dedicado a su suscripción.
Puede implementar varias redes virtuales dentro de cada suscripción y región de Azure.
Cada red virtual está aislada de las otras redes virtuales.
Las redes virtuales pueden contener direcciones IP públicas y privadas definidas en RFC 1918 y expresadas
en notación de enrutamiento de interdominios sin clases (CIDR). Las direcciones IP públicas especificadas en
el espacio de direcciones de una red virtual no son accesibles directamente desde Internet.
Las redes virtuales pueden conectarse entre sí con el emparejamiento de red virtual. Las redes virtuales
conectadas pueden estar en la misma región o en regiones diferentes; los recursos de una red virtual pueden
conectarse a los de otras redes virtuales.
De forma predeterminada, Azure enruta el tráfico entre subredes de una red virtual, redes virtuales
conectadas, redes locales e Internet.
Al planear la topología de la red virtual, debe tener en cuenta cómo organizar los espacios de direcciones IP,
cómo implementar una topología de red en estrella tipo hub-and-spoke, cómo segmentar las redes virtuales en
subredes, cómo configurar DNS y cómo implementar Azure Availability Zones.
Procedimiento recomendado: Planeamiento de las direcciones IP

Al crear redes virtuales como parte de la migración, es importante planear el espacio de direcciones IP de la red
virtual.
Debe asignar un espacio de direcciones que no sea mayor que un intervalo de CIDR de /16 para cada red
virtual. Las redes virtuales permiten el uso de 65 536 direcciones IP. La asignación de un prefijo menor que /16
, como /15 , que tiene 131 072 direcciones, provocaría un exceso de direcciones IP que no se podrían usar en
otro lugar. Es importante no desperdiciar direcciones IP, aunque se encuentren en los intervalos privados
definidos en RFC 1918.
A continuación se incluyen otras sugerencias para la planeación:
El espacio de direcciones de red virtual no debe superponerse con intervalos de red local.
La superposición de direcciones puede provocar que las redes no se puedan conectar y que el enrutamiento
no funcione correctamente.
Si las redes se superponen, tendrá que volver a diseñar la red.
Si no puede rediseñar la red de ningún modo, la traducción de direcciones de red (NAT) puede ayudar, pero
debe evitarse o limitarse lo máximo posible.
Más información:
Lea la información general sobre Azure Virtual Network.
Revise las Preguntas más frecuentes sobre Azure Virtual Network.
Obtenga información sobre los límites de redes de Azure.
Procedimiento recomendado: Implementación de una topología de

red de concentrador y radio
Una topología de red en estrella tipo hub-and-spoke aísla las cargas de trabajo mientras se comparten servicios
tales como los de identidad y seguridad. El centro de conectividad es una red virtual de Azure que actúa como
punto central de conectividad. Los radios son redes virtuales que se conectan a la red virtual del centro
mediante el emparejamiento de red virtual. Los servicios compartidos se implementan en el centro, mientras
que las cargas de trabajo individuales se implementan como radios.
Tenga en cuenta lo siguiente.
La implementación de una topología de red en estrella tipo hub-and-spoke en Azure centraliza la creación de
servicios comunes tales como las conexiones a redes locales, los firewalls y el aislamiento entre redes
virtuales. La red virtual del centro de conectividad proporciona un punto central de conectividad a redes
locales y un lugar para el hospedaje de servicios que utilizan las cargas de trabajo hospedadas en redes
virtuales de radio.
Las empresas más grandes normalmente usan una configuración en estrella tipo hub-and-spoke. Para redes
más pequeñas podría considerarse un diseño más sencillo para ahorrar en costos y complejidad.
Puede utilizar redes virtuales de radio para aislar cargas de trabajo, donde cada radio se administra
independientemente de otros radios. Cada carga de trabajo puede incluir varios niveles y varias subredes
que se conectan a través de equilibradores de carga de Azure.
Puede implementar redes virtuales en estrella tipo hub-and-spoke en distintos grupos de recursos e incluso
en distintas suscripciones. Cuando se emparejan redes virtuales en distintas suscripciones, las suscripciones
pueden estar asociadas al mismo inquilino de Azure Active Directory (Azure AD) o a uno diferente. Esto
permite realizar una administración descentralizada de cada carga de trabajo, mientras se comparten los
servicios que se mantienen en la red virtual del centro de conectividad.
Figura 1: Topología de red en estrella tipo hub-and-spoke.
Más información:
Obtenga información sobre una topología de red en estrella tipo hub-and-spoke.
Obtenga recomendaciones de red para ejecutar máquinas virtuales Windows y Linux en Azure.
Más información sobre el emparejamiento de redes virtuales.
Procedimiento recomendado: Diseño de subredes

Para proporcionar aislamiento en una red virtual, debe segmentarla en una o varias subredes y asignar una
parte del espacio de direcciones de la red virtual a cada subred.
Puede crear varias subredes en cada red virtual.
De forma predeterminada, Azure enruta el tráfico de red entre todas las subredes de una red virtual.
Las decisiones de subred se basan en los requisitos técnicos y organizativos.
Cree subredes con la notación CIDR.
Al decidir el intervalo de red para las subredes, tenga en cuenta que Azure conserva cinco direcciones IP de cada
subred que no se pueden usar. Por ejemplo, si crea la subred más pequeña disponible de /29 (con ocho
direcciones IP), Azure conservará cinco direcciones. En este caso, solo tendrá tres direcciones utilizables que se
pueden asignar a los hosts en la subred. Para la mayoría de los casos, use /28 como la subred más pequeña.
Ejemplo :
La tabla muestra un ejemplo de una red virtual con un espacio de direcciones de 10.245.16.0/20 segmentada
en subredes, para una migración planeada.
SUB N ET C IDR DIREC C IO N ES USO
DEV-FE-EUS2 10.245.16.0/22 1019 Máquinas virtuales de nivel

web o front-end
SUB N ET C IDR DIREC C IO N ES USO
DEV-APP-EUS2 10.245.20.0/22 1019 Máquinas virtuales de

capas de aplicaciones
DEV-DB-EUS2 10.245.24.0/23 507 VM de base de datos
Más información:
Obtenga información sobre el diseño de subredes.
Vea cómo una compañía ficticia, Contoso, ha preparado su infraestructura de red para la migración.
Procedimiento recomendado: Configuración de un servidor DNS

Azure agrega un servidor DNS de forma predeterminada al implementar una red virtual. Esto le permite
compilar redes virtuales e implementar recursos rápidamente. Sin embargo, este servidor DNS solo
proporciona servicios a los recursos en esa red virtual. Si desea conectar varias redes virtuales entre sí o
conectarse a un servidor local desde las redes virtuales, necesita funcionalidades adicionales de resolución de
nombres. Por ejemplo, es posible que necesite Active Directory para resolver nombres DNS entre redes
virtuales. Para ello, implemente su propio servidor DNS personalizado en Azure.
Los servidores DNS de una red virtual pueden reenviar consultas de DNS a las resoluciones recursivas en
Azure. Esto le permite resolver los nombres de host dentro de esa red virtual. Por ejemplo, un
controlador de dominio que se ejecute en Azure puede responder a las consultas de DNS
correspondientes a sus propios dominios y reenviar todas las demás consultas a Azure.
El reenvío de DNS permite que las máquinas virtuales visualicen sus recursos locales (mediante el
controlador de dominio) y los nombres de host proporcionados por Azure (mediante el reenviador).
Puede acceder a las resoluciones recursivas de Azure mediante la dirección IP virtual 168.63.129.16 .
El reenvío de DNS también habilita la resolución de DNS entre redes virtuales y permite que las
máquinas locales resuelvan nombres de host proporcionados por Azure.
Para resolver el nombre de host de una máquina virtual, la máquina virtual del servidor DNS debe
residir en la misma red virtual y debe configurarse para reenviar consultas de nombre de host a
Azure.
Dado que el sufijo DNS es diferente en cada red virtual, puede usar las reglas de desvío condicional
para enviar consultas de DNS a la red virtual correcta para su resolución.
Al usar sus propios servidores DNS, puede especificar varios servidores DNS para cada red virtual.
También puede especificar varios servidores DNS por interfaz de red (para Azure Resource Manager) o
por servicio en la nube (para el modelo de implementación clásica).
Los servidores DNS especificados para una interfaz de red o un servicio en la nube tienen prioridad
sobre los servidores DNS especificados para la red virtual.
En Azure Resource Manager, puede especificar servidores DNS para una red virtual y una interfaz de red,
pero el procedimiento recomendado consiste en usar la opción solo en las redes virtuales.
Figura 2: Servidores DNS para una red virtual.
Más información:
Obtenga información sobre la resolución de nombres al usar su propio servidor DNS.
Obtenga información sobre las reglas y restricciones de nomenclatura DNS.
Procedimiento recomendado: Configuración de Availability Zones

La característica Availability Zones aumenta la alta disponibilidad para proteger las aplicaciones y los datos
frente errores del centro de datos. Las zonas de disponibilidad son ubicaciones físicas exclusivas dentro de una
región de Azure. Cada zona de disponibilidad consta de uno o varios centros de datos equipados con
alimentación, refrigeración y redes independientes. Para garantizar la resistencia, hay un mínimo de tres zonas
independientes en todas las regiones habilitadas. La separación física de las zonas de disponibilidad dentro de
una región protege las aplicaciones y los datos frente a los errores del centro de datos.
A continuación se indican algunos aspectos adicionales que deben tenerse en cuenta al configurar Availability
Zones:
Los servicios con redundancia de zona replican las aplicaciones y los datos en Availability Zones para
protegerlos frente a puntos de error únicos.
Con Availability Zones, Azure ofrece un Acuerdo de Nivel de Servicio con un tiempo de actividad de VM
del 99,99 %.
Figura 3: Availability Zones.
Puede planear y compilar alta disponibilidad en la arquitectura de la migración. Para ello, coloque los
recursos de proceso, almacenamiento, red y datos dentro de una zona y replíquelos en otras zonas. Los
servicios de Azure que admiten zonas de disponibilidad se dividen en dos categorías:
Ser vicios de zona: puede asociar un recurso con una zona específica, como máquinas virtuales,
discos administrados o direcciones IP.
Ser vicios con redundancia de zona: el recurso se replica automáticamente en distintas zonas,
como el almacenamiento con redundancia de zona o Azure SQL Database.
Para proporcionar tolerancia a errores de zona, puede implementar una instancia de Azure Load Balancer
estándar con cargas de trabajo o capas de aplicación accesibles desde Internet.
Figura 4: Equilibrador de carga.
Más información:
Lea la introducción a las zonas de disponibilidad.
Diseño de redes de nube híbrida

Para una migración correcta, es fundamental conectar las redes corporativas locales a Azure. Esto crea una
conexión AlwaysOn conocida como red de nube híbrida, donde se ofrecen servicios de Azure Cloud a los
usuarios corporativos. Hay dos opciones para crear este tipo de red:
VPN de sitio a sitio: esta conexión se establece entre el dispositivo VPN local compatible y una instancia
de Azure VPN Gateway que está implementada en una red virtual. Todos los recursos locales autorizados
tienen acceso a las redes virtuales. Las comunicaciones de sitio a sitio se envían a través de un túnel cifrado a
través de Internet.
Azure ExpressRoute: Esta conexión se establece entre la red local y Azure, a través de un partner de
ExpressRoute. Se trata de una conexión privada y el tráfico no pasa por Internet.
Más información:
Obtenga más información sobre las redes de nube híbrida.
Procedimiento recomendado: Implementación de una VPN de sitio a

sitio de alta disponibilidad
Para implementar una VPN de sitio a sitio, configure una instancia de VPN Gateway en Azure.
Una puerta de enlace de VPN es un tipo de puerta de enlace de red virtual. Envía el tráfico cifrado entre una
red virtual de Azure y una ubicación local a través de Internet público.
Una instancia de VPN Gateway también puede enviar tráfico cifrado entre las redes virtuales de Azure a
través de la red de Microsoft.
Cada red virtual solo puede tener una instancia de VPN Gateway.
Se pueden crear varias conexiones a la misma instancia. Al crear varias conexiones a la misma instancia de
VPN Gateway, todos los túneles VPN comparten el ancho de banda de puerta de enlace disponible.
Cada instancia de Azure VPN Gateway consta de dos instancias en una configuración activa-en espera:
En caso de mantenimiento planeado o interrupción imprevista de la instancia activa, se produce la
conmutación por error y la instancia en espera toma el relevo automáticamente. Esta instancia reanuda la
conexión de sitio a sitio o de red a red.
El cambio produce una breve interrupción.
En el caso del mantenimiento planeado, la conectividad se debe restaurar en un plazo de 10 a 15 segundos.
Si se trata de problemas imprevistos, la recuperación de la conexión llevará más tiempo, hasta un minuto y
medio en el peor de los casos.
Las conexiones de cliente VPN de punto a sitio con la puerta de enlace se desconectarán y los usuarios
tendrán que volver a conectarse desde las máquinas cliente.
Al configurar una VPN de sitio a sitio:
Necesita una red virtual cuyo intervalo de direcciones no se superponga con la red local a la que se
conectará la VPN.
Cree una subred de puerta de enlace en la red.
Cree una instancia de VPN Gateway, especifique el tipo de puerta de enlace (VPN) y si la puerta de enlace
está basada en directivas o en rutas. Se considera que una VPN basada en ruta es más eficaz y está mejor
preparada para el futuro.
Cree una puerta de enlace de red local en el entorno local y configure el dispositivo VPN local.
Cree una conexión VPN de sitio a sitio de conmutación por error entre la puerta de enlace de red virtual y el
dispositivo local. El uso de VPN basadas en rutas permite conexiones de tipo activa-pasiva o activa-activa con
Azure. La opción basada en rutas también admite conexiones simultáneas de sitio a sitio (desde cualquier
equipo) y de punto a sitio (desde un único equipo).
Especifique la SKU de la puerta de enlace que quiere utilizar. Esto depende de los requisitos, el rendimiento,
las características y los Acuerdos de Nivel de Servicio de la carga de trabajo.
El Protocolo de puerta de enlace de borde (BGP) es una característica opcional. Se puede usar con Azure
ExpressRoute e instancias de VPN Gateway basadas en rutas para propagar las rutas BGP locales a sus redes
virtuales.
Figura 5: VPN de sitio a sitio.

Más información:
Revise los dispositivos VPN locales compatibles.
Lea la información general de Azure VPN Gateway.
Obtenga información sobre las conexiones VPN de alta disponibilidad.
Obtenga información sobre cómo planear y diseñar una instancia de VPN Gateway.
Revise la configuración de VPN Gateway.
Revise las SKU de puerta de enlace.
Obtenga información sobre cómo configurar BGP con instancias de Azure VPN Gateway.
Procedimiento recomendado: Configuración de una puerta de enlace para instancias de VPN Gateway
Al crear una instancia de VPN Gateway en Azure, se debe usar una subred especial denominada GatewaySubnet .
Al crear esta subred, tenga en cuenta los procedimientos recomendados siguientes:
GatewaySubnet puede tener una longitud máxima de prefijo de 29 (por ejemplo, 10.119.255.248/29 ). La
recomendación actual es usar una longitud de prefijo de 27 (por ejemplo, 10.119.255.224/27 ).
Al definir el espacio de direcciones de la subred de puerta de enlace, use la última parte del espacio de
direcciones de la red virtual.
Cuando use la subred de puerta de enlace de Azure, no implemente nunca en ella máquinas virtuales u otros
dispositivos, como Azure Application Gateway.
No asigne a un grupo de seguridad de red (NSG) a esta subred. Hará que la puerta de enlace deje de
funcionar.
Procedimiento recomendado: Implementación de Azure Virtual WAN

para las sucursales
En el caso de varias conexiones VPN, Azure Virtual WAN es un servicio de redes que ofrece conectividad de
rama a rama automatizada y optimizada mediante Azure.
Virtual WAN permite conectar y configurar los dispositivos de rama para comunicarse con Azure. Esto puede
realizarse manualmente o con dispositivos del proveedor preferido mediante un asociado de Azure Virtual
WAN.
El uso de dispositivos del proveedor preferido simplifica el uso, la conectividad y la administración de la
configuración.
El panel integrado de Azure Virtual WAN facilita información instantánea para la resolución de problemas
que ahorra tiempo y ofrece una forma sencilla de realizar un seguimiento de la conectividad de sitio a sitio a
gran escala.
Más información: Obtenga información acerca de Azure Virtual WAN.
Procedimiento recomendado: Implementación de ExpressRoute para las conexiones críticas
El servicio Azure ExpressRoute amplía su infraestructura local a la nube de Microsoft mediante la creación de
conexiones privadas entre el centro de datos virtual de Azure y redes locales. Estos son algunos detalles de la
implementación:
Las conexiones ExpressRoute pueden efectuarse a través de una red de conectividad universal (IP VPN), una
red Ethernet de punto a punto o mediante un proveedor de conectividad. No pasan por la red pública de
internet.
Las conexiones ExpressRoute ofrecen mayor seguridad, confiabilidad y velocidades más altas (hasta 10
Gbps), con una latencia constante.
ExpressRoute resulta útil para los centros de datos virtuales, ya que los clientes pueden aprovechar las reglas
de cumplimiento asociadas a las conexiones privadas.
Con ExpressRoute Direct, puede conectarse directamente a los enrutadores de Microsoft a 100 Gbps, en caso
de que se necesite un ancho de banda mayor.
ExpressRoute utiliza BGP para intercambiar rutas entre redes locales, instancias de Azure y direcciones
públicas de Microsoft.
La implementación de conexiones ExpressRoute implica normalmente tomar contacto con un proveedor de
servicios de ExpressRoute. Para comenzar rápidamente, es habitual usar inicialmente una VPN de sitio a sitio
para establecer la conectividad entre el centro de datos virtual y los recursos locales. Posteriormente, deberá
migrar a una conexión ExpressRoute cuando se establezca la interconexión física con su proveedor de servicios.
Más información:
Lea la información general sobre ExpressRoute.
Obtenga información sobre ExpressRoute Direct.
Procedimiento recomendado: Optimización del enrutamiento de ExpressRoute con las comunidades de BGP
Cuando hay varios circuitos ExpressRoute, tiene más de una ruta de acceso para conectarse a Microsoft. Por
consiguiente, puede producirse un enrutamiento no óptimo y es posible que el tráfico utilice una ruta de acceso
más larga para conectarse con Microsoft y este a su vez, con su red. Cuanto más larga sea la ruta de acceso a la
red, mayor será la latencia. La latencia tiene un efecto directo en la experiencia del usuario y en el rendimiento
de las aplicaciones.
Ejemplo :
Vamos a ver un ejemplo:
Tiene dos oficinas en Estados Unidos, una en Los Ángeles y la otra en Nueva York.
Las oficinas están conectadas a una WAN, que puede ser su propia red troncal o la VPN de la dirección IP del
proveedor de servicios.
Tiene dos circuitos ExpressRoute, uno en West US y otro en East US , que también están conectados a la red
de área extensa. Obviamente, tiene dos rutas de acceso para conectarse a la red de Microsoft.
Problema:
Ahora supongamos que tiene una implementación de Azure (por ejemplo, Azure App Service) en West US y
East US .
Quiere que los usuarios de ambas oficinas tengan acceso a sus servicios de Azure más cercanos para
disfrutar de una experiencia óptima.
Así que quiere conectar los usuarios de Los Ángeles a Azure West US y los usuarios de Nueva York a
East US .
Esto funciona para los usuarios de la costa este, pero no para los de la costa oeste. El problema es el
siguiente:
En cada circuito ExpressRoute, se indican los prefijos de Azure East US ( 23.100.0.0/16 ) y Azure
West US ( 13.100.0.0/16 ).
Al no saber qué prefijo corresponde a cada región, los prefijos no se tratan de forma distinta.
La red WAN puede presuponer que ambos prefijos están más cerca de East US que de West US y,
por tanto, enrutar a los usuarios de ambas oficinas al circuito ExpressRoute de East US , lo que ofrece
una peor experiencia a los usuarios de la oficina de Los Ángeles.
Figura 6: Conexión no optimizada de comunidades de BGP.
Solución:
Para optimizar el enrutamiento para ambas oficinas, debe saber qué prefijo corresponde a Azure West US y qué
prefijo corresponde a Azure East US . Puede codificar esta información mediante los valores de la comunidad
de BGP.
Asigne un valor único de comunidad de BGP a cada región de Azure. Por ejemplo, 12076:51004 para
East US y 12076:51006 para West US .
Ahora que ha quedado claro qué prefijo pertenece a cada región de Azure, puede configurar un circuito
ExpressRoute preferido.
Puesto que usa BGP para intercambiar información de enrutamiento, puede usar la preferencia local de BGP
para influir en el enrutamiento.
En nuestro ejemplo, asigna un valor de preferencia local superior a 13.100.0.0/16 en West US que en
East US . Del mismo modo, asigna un valor de preferencia local superior a 23.100.0.0/16 en East US que
en West US .
Esta configuración garantiza que, cuando las dos rutas de acceso a Microsoft estén disponibles, los usuarios
de Los Ángeles se conectarán a West US con el circuito oeste, y los de Nueva York se conectarán a East US
con el circuito este.
Figura 7: Conexión optimizada de comunidades de BGP.
Más información:
Obtenga información sobre cómo optimizar el enrutamiento.
Protección de redes virtuales

La responsabilidad de proteger las redes virtuales se comparte entre Microsoft y usted. Microsoft facilita
muchas características de red, además de servicios que ayudan a proteger los recursos. Al diseñar la seguridad
de las redes virtuales, se recomienda implementar una red perimetral, usar filtrado y grupos de seguridad,
proteger el acceso a los recursos y las direcciones IP e implementar protección frente a ataques.
Más información:
Obtenga información general sobre los procedimientos recomendados de seguridad de red.
Aprenda a diseñar redes seguras.
Procedimiento recomendado: Implementación de una red perimetral

de Azure
Aunque Microsoft realiza importantes inversiones en la protección de la infraestructura en la nube, el usuario
también debe proteger los servicios en la nube y los grupos de recursos. Un enfoque de varios niveles de
seguridad proporciona la mejor defensa. La implementación de una red perimetral es un elemento importante
de dicha estrategia de defensa.
Una red perimetral protege los recursos de red internos de una red que no sea de confianza.
Es la capa más externa que queda expuesta a Internet. Suele ubicarse entre Internet y la infraestructura de la
empresa, normalmente con algún tipo de protección a ambos lados.
En una topología red de empresa típica, la infraestructura principal está considerablemente reforzada en los
perímetros, con varias capas de dispositivos de seguridad. El límite de cada nivel consta de dispositivos y
puntos de aplicación de directivas.
Cada capa puede incluir una combinación de las soluciones de seguridad de red, como firewalls, prevención
de ataques por denegación de servicio (DoS), sistemas de protección o detección de intrusiones (IDS/IPS) y
dispositivos VPN.
El cumplimiento de directivas en la red perimetral puede usar directivas de firewall, listas de control de
acceso (ACL) o enrutamientos específicos.
A medida que el tráfico entrante llega desde Internet, se intercepta y controla mediante una combinación de
soluciones de defensa. Las soluciones bloquean los ataques y el tráfico perjudicial, a la vez que permiten el
paso de solicitudes legítimas a la red.
El tráfico entrante puede enrutarse directamente a los recursos de la red perimetral. El recurso de la red
perimetral puede entonces comunicarse con otros recursos más profundos de la red, lo que hace avanzar el
tráfico hacia la red después de la validación.
A continuación se muestra un ejemplo de una sola red perimetral de subred en una red corporativa con dos
límites de seguridad.
Figura 8: Implementación de red perimetral.

Más información:
Obtenga información sobre cómo implementar una red perimetral entre Azure y el centro de datos local.
Procedimiento recomendado: Filtrar el tráfico de red virtual con

grupos de seguridad de red
Los grupos de seguridad de red (NSG) contienen varias reglas de seguridad entrante y saliente que filtran el
tráfico hacia y desde los recursos. El filtrado puede ser por dirección IP de origen y destino, puerto y protocolo.
Los NSG contienen reglas de seguridad que permiten o deniegan el tráfico de red entrante (o el tráfico de
red saliente) de varios tipos de recursos de Azure. Para cada regla, puede especificar un origen y destino, un
puerto y un protocolo.
Las reglas de NSG se evalúan por prioridad con información de tupla de cinco elementos (origen, puerto de
origen, destino, puerto de destino y protocolo) para permitir o denegar el tráfico.
Se crea un registro de flujo para las conexiones existentes. Se permite o deniega la comunicación en función
del estado de conexión del registro de flujo.
Un registro de flujo permite que un NSG sea de tipo con estado. Por ejemplo, si especifica una regla de
seguridad de salida para cualquier dirección a través del puerto 80, no tiene que especificar una regla de
seguridad de entrada para la respuesta al tráfico saliente. Solo debe especificar una regla de seguridad de
entrada si la comunicación se inicia de forma externa.
Lo contrario también es cierto. Si se permite el tráfico entrante a través de un puerto, no hay que especificar
una regla de seguridad de salida que responda al tráfico a través del puerto.
Las conexiones existentes no se interrumpen cuando se quita una regla de seguridad que habilitó el flujo. Los
flujos de tráfico se interrumpen cuando se detienen las conexiones y no fluye ningún tráfico en ninguna
dirección durante al menos unos minutos.
Al crear grupos de seguridad de red, cree el menor número posible pero tantos como sean necesarios.
Procedimiento recomendado: Protección del tráfico vertical de arriba abajo y horizontal de derecha a
izquierda
Para proteger las redes virtuales, considere la posibilidad de utilizar vectores de ataque. Tenga en cuenta los
siguientes puntos:
El uso exclusivo de grupos de seguridad de red de subred simplifica el entorno, pero solo protege el tráfico
en la subred. Esto se conoce como tráfico vertical de arriba abajo.
El tráfico entre máquinas virtuales en la misma subred se conoce como tráfico horizontal de derecha a
izquierda.
Es importante usar ambos formatos de protección, de modo que si un hacker obtiene acceso desde el
exterior, se le detendrá cuando intente conectarse a máquinas ubicadas en la misma subred.
Uso de etiquetas de servicio en los NSG
Una etiqueta de servicio representa un grupo de prefijos de direcciones IP. El uso de una etiqueta de servicio
contribuye a minimizar la complejidad al crear reglas de NSG.
Puede utilizar etiquetas de servicio en lugar de direcciones IP específicas al crear reglas.
Microsoft administra los prefijos de direcciones asociados a una etiqueta de servicio y actualiza la etiqueta
automáticamente a medida que las direcciones cambian.
No puede crear su propia etiqueta de servicio ni especificar qué direcciones IP se incluyen dentro de una
etiqueta.
Las etiquetas de servicio eliminan el trabajo manual de asignar una regla a grupos de servicios de Azure. Por
ejemplo, si quiere permitir que una subred que incluye servidores web tenga acceso a Azure SQL Database,
puede crear una regla de salida al puerto 1433 y usar la etiqueta de servicio Sql .
Esta etiqueta Sql denota los prefijos de direcciones de los servicios Azure SQL Database y Azure SQL Data
Warehouse.
Si especifica Sql como valor, se permite o se deniega el tráfico a SQL.
Si solo quiere permitir el acceso a Sql en una región determinada, puede especificarla. Por ejemplo, si quiere
permitir el acceso a Azure SQL Database solo en la región Este de EE. UU., puede especificar Sql.EastUS
como la etiqueta de servicio.
La etiqueta representa el servicio, no instancias específicas del mismo. Por ejemplo, la etiqueta representa el
servicio Azure SQL Database, pero no un servidor o una instancia de SQL Database en particular.
Todos los prefijos de dirección representados por esta etiqueta también se representan mediante la etiqueta
Internet .
Más información:
Obtenga información sobre los grupos de seguridad de red (NSG).
Revise las etiquetas de servicio disponibles para los NSG.
Procedimiento recomendado: Uso de grupos de seguridad de

aplicaciones
Los grupos de seguridad de aplicaciones permiten configurar la seguridad de red como extensión natural de
una estructura de aplicación.
Puede agrupar las máquinas virtuales y definir directivas de seguridad de red basadas en grupos de
seguridad de aplicaciones.
Los grupos de seguridad de aplicaciones le permiten reutilizar la directiva de seguridad a escala sin
mantenimiento manual de direcciones IP explícitas.
Los grupos de seguridad de aplicaciones controlan la complejidad de las direcciones IP explícitas y de varios
conjuntos de reglas, lo que le permite centrarse en su lógica de negocios.
Ejemplo :
Figura 9:
Ejemplo de grupo de seguridad de aplicaciones.
IN T ERFA Z DE RED GRUP O DE SEGURIDA D DE A P L IC A C IO N ES
NIC1 AsgWeb
NIC2 AsgWeb
NIC3 AsgLogic
NIC4 AsgDb
En nuestro ejemplo, cada interfaz de red pertenece a un único grupo de seguridad de aplicaciones, pero en
realidad una interfaz puede pertenecer a varios grupos, de acuerdo con los límites de Azure. Ninguna de las
interfaces de red tiene un grupo de seguridad de red asociado. NSG1 se asocia con ambas subredes y contiene
las siguientes reglas:
N O M B RE DE L A REGL A P RO P Ó SITO DETA L L ES
Allow-HTTP-Inbound-Internet Se permite el tráfico de Internet a los Prioridad: 100

servidores web. La regla de seguridad
predeterminada DenyAllInbound Origen: internet
deniega el tráfico entrante desde
Internet, por lo que no se necesita Puerto de origen: *
ninguna regla adicional para los
grupos de seguridad de aplicaciones Destino: AsgWeb
AsgLogic y AsgDb .
Puerto de destino: 80
Protocolo: TCP
Acceso: Allow
Deny-Database-All La regla de seguridad predeterminada Prioridad: 120

AllowVNetInBound permite todas las
comunicaciones entre recursos de la Origen: *
misma red virtual. Esta regla es
necesaria para denegar el tráfico de Puerto de origen: *
todos los recursos.
Destino: AsgDb
Puerto de destino: 1433
Protocolo: All
Acceso: Deny
Allow-Database-BusinessLogic Se permite el tráfico desde el grupo de Prioridad: 110

seguridad de aplicaciones AsgLogic
al grupo de seguridad de aplicaciones Origen: AsgLogic
AsgDb . La prioridad de esta regla es
mayor que la prioridad de la regla Puerto de origen: *
Deny-Database-All , por lo que esta
regla se procesará en primer lugar. Por Destino: AsgDb
tanto, se permite el grupo de
seguridad de la aplicación AsgLogic y Puerto de destino: 1433
el resto del tráfico se bloquea.
Protocolo: TCP
Acceso: Allow
Las reglas que especifican un grupo de seguridad de aplicaciones como origen o destino solo se aplican a las
interfaces de red que son miembros del grupo de seguridad de aplicaciones. Si la interfaz de red no es miembro
de un grupo de seguridad de aplicaciones, la regla no se aplica a la interfaz de red aunque el grupo de seguridad
de red esté asociado a la subred.
Más información:
Obtenga información sobre los grupos de seguridad de aplicaciones.
Procedimiento recomendado: Protección del acceso a PaaS mediante el uso de puntos de conexión de
servicio de red virtual
Los puntos de conexión de servicio de red virtual extienden el espacio de direcciones privadas y la identidad de
la red virtual a los servicios de Azure a través de una conexión directa.
Los puntos de conexión permiten proteger los recursos de servicio de Azure críticos únicamente para las
redes virtuales. El tráfico desde la red virtual al servicio de Azure siempre permanece en la red troncal de
Azure.
El espacio de direcciones privadas de red virtual se puede estar solapando y, por tanto, no se puede usar para
identificar de forma única el tráfico que se origina en la red virtual.
Una vez que los puntos de conexión de servicio se habilitan en la red virtual, puede proteger los recursos de
servicio de Azure mediante la incorporación de una regla de red virtual a los recursos del servicio. Esta regla
proporciona una mayor seguridad dado que se elimina totalmente el acceso público a Internet a los recursos
y solo se permite el tráfico que procede de la red virtual.
Figura 10: Puntos de conexión de servicio.

Más información:
Obtenga más información sobre los puntos de conexión de servicio de red virtual.
Procedimiento recomendado: Control de las direcciones IP públicas

Las direcciones IP públicas de Azure pueden asociarse a máquinas virtuales, equilibradores de carga, instancias
de Application Gateway e instancias de VPN Gateway.
Las direcciones IP públicas permiten la comunicación entrante de los recursos de Internet con los recursos de
Azure y la comunicación saliente de los recursos de Azure con Internet.
Las direcciones IP públicas se crean mediante una SKU básica o una SKU estándar. Las SKU estándar pueden
asignarse a cualquier servicio, pero normalmente se configuran en las VM, los equilibradores de carga y las
instancias de Application Gateway.
Una dirección IP pública básica no tiene un NSG configurado automáticamente. Debe configurar el suyo
propio y asignarle reglas para controlar el acceso. Las direcciones IP de SKU estándar tienen asignados un
NSG y reglas de forma predeterminada.
Como procedimiento recomendado, las máquinas virtuales no deben configurarse con una dirección IP
pública.
Si necesita un puerto abierto, debe ser solo para servicios web, como el puerto 80 o 443.
Los puertos de administración remota estándar, como SSH (22) y RDP (3389), junto con los demás
puertos, deben establecerse para que denieguen el uso de grupos de seguridad de red.
Lo más recomendable es situar las máquinas virtuales detrás de una instancia de Azure Load Balancer o de
Azure Application Gateway. Si después se necesita acceso a los puertos de administración remota, puede
usar el acceso Just-In-Time a máquinas virtuales en Azure Security Center.
Más información:
Direcciones IP públicas en Azure
Administración del acceso a máquina virtual mediante Just-In-Time
Aproveche las ventajas de las características de seguridad de Azure

para redes
Azure tiene características de seguridad de nivel de plataforma, como Azure Firewall, Azure Web Application
Firewall (WAF) y Azure Network Watcher.
Procedimiento recomendado: Implementación de Azure Firewall

Azure Firewall es un servicio de seguridad de red administrado y basado en la nube que protege los recursos de
red virtual. Se trata de un firewall administrado con estado completo, con alta disponibilidad integrada y una
escalabilidad sin restricciones en la nube.
Figura 11: Azure Firewall.

Estos son algunos puntos que deben tenerse en cuenta si implementa el servicio:
Azure Firewall puede crear, aplicar y registrar directivas de conectividad de red y de aplicaciones de forma
centralizada en suscripciones y redes virtuales.
Azure Firewall usa una dirección IP pública estática para los recursos de red virtual. Esto permite que los
firewalls externos identifiquen el tráfico que procede de su red virtual.
Azure Firewall está totalmente integrado con Azure Monitor a efectos de registros y análisis.
Al crear reglas de Azure Firewall, se recomienda usar las etiquetas de nombre de dominio completo.
Una etiqueta FQDN representa un grupo de FQDN asociados a conocidos servicios de Microsoft.
Puede usar una etiqueta FQDN para permitir que pase el tráfico de red saliente necesario a través del
firewall.
Por ejemplo, para permitir manualmente el tráfico de red de Windows Update a través del firewall, tendría
que crear varias reglas de aplicación. Con las etiquetas de nombre de dominio completo, cree una regla de
aplicación e incluya la etiqueta de Windows Update. Con esta regla en curso, el tráfico de red a los puntos de
conexión de Microsoft Windows Update puede fluir a través del firewall.
Más información:
Lea la información general de Azure Firewall.
Obtenga información sobre las etiquetas FQDN en Azure Firewall.
Procedimiento recomendado: Implementación del firewall de

aplicaciones web
Las aplicaciones web son cada vez más los objetivos de ataques malintencionados que aprovechan
vulnerabilidades habitualmente conocidas. Entre las vulnerabilidades de seguridad se incluyen los ataques por
inyección de código SQL y los ataques de scripts de sitios. Impedir tales ataques en el código de aplicación
puede ser un verdadero desafío y requerir tareas rigurosas de mantenimiento, aplicación de revisiones y
supervisión en varias capas de la topología de aplicación.
El firewall de aplicaciones web, una característica de Azure Application Gateway, contribuye a simplificar
enormemente la administración de la seguridad y ayuda a los administradores de aplicaciones a protegerse
frente a amenazas o intrusiones. Puede reaccionar más rápidamente ante las amenazas de seguridad aplicando
revisiones a las vulnerabilidades conocidas en una ubicación central en lugar de proteger cada una de las
aplicaciones web por separado. Es posible transformar fácilmente las puertas de enlace de aplicaciones
existentes en una instancia de Application Gateway habilitada para un firewall de aplicaciones web.
A continuación se muestran algunas notas adicionales sobre el firewall de aplicaciones web:
El firewall de aplicaciones web ofrece una protección centralizada de las aplicaciones web contra las
vulnerabilidades de seguridad comunes.
No es necesario modificar el código para usar el firewall de aplicaciones web.
Puede proteger varias aplicaciones web al mismo tiempo detrás de una instancia de Application Gateway.
WAF se integra con Azure Security Center.
Puede personalizar las reglas y grupos de reglas de WAF para que adapten a sus requisitos de aplicación.
Como procedimiento recomendado, debe usar un firewall de aplicaciones web delante de cualquier
aplicación accesible desde la web, como las aplicaciones en máquinas virtuales de Azure o en Azure App
Service.
Más información:
Obtenga información sobre WAF.
Revise las limitaciones y exclusiones de WAF.
Procedimiento recomendado: Implementación de Network Watcher

Network Watcher ofrece herramientas para supervisar los recursos y las comunicaciones en una red virtual de
Azure. Por ejemplo, puede supervisar las comunicaciones entre una máquina virtual y un punto de conexión,
como otra máquina virtual o nombre de dominio completo. También puede ver los recursos y las relaciones de
recursos en una red virtual, o bien diagnosticar problemas de tráfico de red.
Figura 12: Network Watcher.
A continuación se incluyen algunos detalles más:
Con Network Watcher puede supervisar y diagnosticar problemas de red sin iniciar sesión en las máquinas
virtuales.
Puede desencadenar la captura de paquetes estableciendo alertas y obtener acceso a información de
rendimiento en tiempo real en el ámbito de paquete. Cuando vea un problema, podrá investigarlo en detalle.
Como procedimiento recomendado, use Network Watcher para revisar los registros de flujo de NSG.
Los registros de flujo de NSG de Network Watcher le permiten visualizar información sobre el tráfico
IP de entrada y de salida en un grupo de seguridad de red.
Los registros de flujo se escriben en formato JSON.
Los registros de flujo muestran los flujos de entrada y salida en función de cada regla y la interfaz de
red (NIC) a la que se aplica el flujo. También muestran información de 5-tupla sobre el flujo (IP de
origen/destino, puerto de origen/destino y protocolo) y si se permitió o denegó el tráfico.
Más información:
Lea la introducción a Network Watcher.
Obtenga más información sobre los registros de flujo de NSG.
Uso de herramientas de partner en Azure Marketplace
En el caso de topologías de red más complejas, puede usar los productos de seguridad de partners de Microsoft,
en aplicaciones virtuales de red (NVA) concretas.
Una NVA es una máquina virtual que ejecuta una función de red, como, por ejemplo, un firewall, la
optimización de WAN u otra función de red.
Las NVA refuerzan las funciones de red y seguridad de las redes virtuales. Pueden implementarse para
firewalls de alta disponibilidad, prevención de intrusiones, detección de intrusiones, firewalls de aplicaciones
web, optimización de WAN, enrutamiento, equilibrio de carga, VPN, administración de certificados, Active
Directory y autenticación multifactor.
Hay NVA disponibles de numerosos proveedores en Azure Marketplace.
Procedimiento recomendado: Implementación de aplicaciones

virtuales de red (NVA) y firewalls en redes de centro de conectividad
En el centro de conectividad, la red perimetral (con acceso a Internet) suele administrarse mediante una
instancia de Azure Firewall, una granja de firewalls o firewalls de aplicaciones web. En la tabla siguiente se
comparan estos tipos de firewalls.
T IP O DE F IREWA L L DETA L L ES
WAF Las aplicaciones web son comunes y tienden a experimentar

vulnerabilidades de seguridad y de otro tipo. Los firewalls de
aplicaciones web están diseñados para detectar ataques
contra las aplicaciones web (HTTP/HTTPS). En comparación
con la tecnología de firewall tradicional, los WAF tienen un
conjunto de características específicas que protegen los
servidores web internos frente a amenazas.
Azure Firewall Al igual que las granjas de firewalls de NVA, Azure Firewall
usa un mecanismo de administración común y un conjunto
de reglas de seguridad para proteger las cargas de trabajo
hospedadas en redes de radio. Azure Firewall también ayuda
a controlar el acceso a las redes locales. Azure Firewall tiene
escalabilidad integrada.
Firewalls de NVA Al igual que Azure Firewall, las granjas de firewalls de NVA
tienen un mecanismo de administración común y un
conjunto de reglas de seguridad para proteger las cargas de
trabajo hospedadas en redes de radio. Las granjas de
firewalls también ayudan a controlar el acceso a las redes
locales. Los firewalls de NVA se pueden escalar manualmente
detrás de un equilibrador de carga.
Aunque un firewall de NVA tiene menos software

especializado en comparación con un WAF, tiene un ámbito
de aplicación más amplio para filtrar e inspeccionar cualquier
tipo de tráfico de entrada y salida.
Se recomienda usar un conjunto de firewalls de Azure (o aplicaciones virtuales de red) para el tráfico que se
origina en Internet y otro para el tráfico que se origina en el entorno local. Utilizar únicamente un conjunto de
firewalls para ambos es un riesgo de seguridad, ya que no proporciona ningún perímetro de seguridad entre los
dos conjuntos de tráfico de red. El uso de capas de firewalls independientes reduce la complejidad de la
comprobación de las reglas de seguridad y deja claro qué reglas se corresponden con cada solicitud de red
entrante.
Más información:
Obtenga información sobre cómo usar NVA en Azure Virtual Network.
Pasos siguientes
Procedimientos recomendados para la seguridad y administración después de la migración.
Procedimientos recomendados para la administración de costos después de la migración.
Implementación de una infraestructura de
migración
En este artículo se muestra cómo la empresa ficticia Contoso prepara su infraestructura local para la migración,
configura una infraestructura de Azure como preparación para la migración a Azure y dirige el negocio en un
entorno híbrido.
Cuando use este ejemplo como ayuda para planear sus propios trabajos de migración de la infraestructura,
tenga en cuenta que la arquitectura de ejemplo proporcionada es específica de Contoso. Antes de tomar
decisiones importantes sobre la infraestructura relacionadas con el diseño de las suscripciones o la arquitectura
de red examine las necesidades empresariales de su organización, su estructura y los requisitos técnicos.
El que necesite todos los elementos que se describen en este artículo depende de su estrategia de migración.
Por ejemplo, puede que necesite una estructura de red menos compleja si solo va a crear aplicaciones nativas de
nube en Azure.
Antes de poder migrar Contoso a Azure, es fundamental preparar una infraestructura de Azure. Por lo general,
Contoso debe pensar en seis áreas:
Paso 1: Suscripciones de Azure. ¿Cómo adquirirá el equipo de TI la plataforma Azure y cómo interactuará
con la plataforma y los servicios de Azure?
Paso 2: Identidad híbrida. ¿Cómo administrará y controlará el equipo de TI el acceso a los recursos de
Azure y locales después de la migración? ¿Cómo ampliará o moverá el equipo de TI la administración de
identidades a la nube?
Paso 3: Recuperación ante desastres y resistencia. ¿Cómo garantizará el equipo de TI que sus
aplicaciones e infraestructuras sean resistentes en caso de interrupciones y desastres?
Paso 4: Red. ¿Cómo debería diseñar el equipo de TI una infraestructura de red y establecer la conectividad
entre el centro de datos local y Azure?
Paso 5: Seguridad. ¿Cómo protegerá el equipo de TI la implementación híbrida?
Paso 6: Gobernanza. ¿De qué manera el equipo de TI mantendrá alineada la implementación con los
requisitos de seguridad y gobernanza?
Antes de comenzar
Antes de empezar a revisar la infraestructura, considere la posibilidad de conocer algunos datos generales sobre
las funcionalidades de Azure relevantes:
Hay varias opciones para adquirir acceso a Azure, entre ellas, suscripciones de pago por uso, un Contrato
Enterprise (EA) de Microsoft, licencias Open de revendedores de Microsoft, o compra a asociados de
Microsoft en el programa Proveedor de soluciones en la nube (CSP). Obtenga información acerca de las
opciones de compra y sobre cómo se organizan las suscripciones a Azure.
Obtenga información general acerca de Administración de identidad y acceso de Azure. Obtenga
información sobre Azure Active Directory y la ampliación del entorno de Active Directory local a la nube.
Azure ofrece una sólida infraestructura de red con opciones para conectividad híbrida. Obtenga información
general acerca de las redes y el control de acceso de red.
Lea la introducción a la seguridad de Azure y aprenda a crear un plan de gobernanza en Azure.
Arquitectura local
Aquí se muestra un diagrama de la infraestructura local de Contoso en la actualidad.
Figura 1: Arquitectura local de Contoso.

Contoso tiene un centro de datos principal situado en Nueva York, al este de los Estados Unidos.
Asimismo, tiene tres sucursales locales más en los Estados Unidos.
(500 Mbps).
Cada una de las sucursales está conectada localmente a Internet con conexiones de categoría empresarial y
con túneles de VPN, con IPsec de nuevo al centro de datos principal. Este enfoque permite que toda la red
esté conectada de forma permanente, además de optimizar la conectividad a Internet.
virtualización de ESXi 6.5, que administra vCenter Server 6.5.
Contoso usa Active Directory para la administración de identidades y servidores del sistema de nombres de
dominio en la red interna.
Los controladores de dominio del centro de datos se ejecutan en máquinas virtuales de VMware. Los
controladores de dominio de las sucursales locales se ejecutan en servidores físicos.
Paso 1: Compra y suscripción a Azure

Contoso debe averiguar cómo comprar Azure, cómo administrar las suscripciones y cómo obtener licencias
para los servicios y recursos.
Comprar Azure
Contoso va a inscribirse en un Contrato Enterprise (EA). Este contrato implica un compromiso monetario inicial
con Azure, que da derecho a Contoso a disfrutar de grandes ventajas, que incluyen opciones de facturación
flexibles y precios optimizados.
Estos son los detalles:
Contoso hizo una estimación de lo que se gastará anualmente en Azure. Cuando Contoso firmó el acuerdo,
pagó por el primer año en su totalidad.
Contoso debe usar todo lo que tiene asignado antes de que finalice el año, o perderá el valor de ese dinero.
Si por algún motivo Contoso supera su asignación y gasta más, Microsoft le facturará la diferencia.
Los gastos por encima de la asignación se facturarán con las mismas tarifas que las del contrato de Contoso.
No hay penalizaciones por excederse.
Administrar suscripciones
Después de pagar Azure, Contoso debe averiguar cómo administrar las suscripciones de Azure. Como Contoso
tiene un Contrato Enterprise, no hay ningún límite en el número de suscripciones de Azure que puede crear. Una
inscripción en el Contrato Enterprise de Azure define cómo una empresa da forma y usa los servicios de Azure,
y define una estructura de gobernanza básica.
Como primer paso, Contoso ha definido una estructura conocida como scaffolding empresarial para su
inscripción. Contoso usó la guía de scaffold de Azure Enterprise para ayudar a comprender y diseñar un scaffold.
Por ahora, Contoso ha decidido usar un enfoque funcional para administrar sus suscripciones:
Dentro de la empresa, tendrá un solo departamento de TI que controlará el presupuesto de Azure. Este es el
único grupo con suscripciones.
En el futuro, Contoso podrá ampliar este modelo para que otros grupos corporativos puedan unirse como
departamentos en la jerarquía de inscripción.
Dentro del departamento de TI, Contoso ha estructurado dos suscripciones, Production y Development .
Si Contoso necesita más suscripciones en el futuro, deberá administrar también el acceso, las directivas y el
cumplimiento de esas suscripciones. Para ello, introducirá grupos de administración de Azure como un nivel
adicional por encima de las suscripciones.
Figura 2: Jerarquía
empresarial.
Examinar la concesión de licencias
Con las suscripciones configuradas, Contoso puede consultar sus licencias de Microsoft. Su estrategia de
licencias dependerá de los recursos que quiera migrar a Azure y de cómo se seleccionan e implementan los
servicios y las máquinas virtuales de Azure.
Ventaja híbrida de Azure
Para implementar máquinas virtuales en Azure, las imágenes estándar incluyen una licencia que se le cobrará a
Contoso por minuto en función del software que se esté usando. Sin embargo, Contoso ha sido cliente de
Microsoft durante mucho tiempo y ha mantenido Contrato Enterprise y licencias Open con Software Assurance.
Ventaja híbrida de Azure proporciona un método rentable para la migración. Permite a Contoso ahorrar en
máquinas virtuales de Azure y cargas de trabajo de SQL Server mediante la conversión o reutilización de
Windows Server Datacenter y licencias Standard Edition que cubre Software Assurance. Esto permitirá que
Contoso pague una tarifa de proceso base más baja por las VM y SQL Server. Para más información, consulte
Ventaja híbrida de Azure.
Movilidad de licencias
Movilidad de licencias a través de Software Assurance ofrece a los clientes del programa de licencias por
volumen de Microsoft, como Contoso, la flexibilidad de implementar aplicaciones de servidor aptas, con una
instancia activa de Software Assurance en Azure. Esto elimina la necesidad de adquirir licencias nuevas. Sin
costos asociados a movilidad, las licencias existentes se pueden implementar fácilmente en Azure. Para obtener
más información, consulte Movilidad de Licencias a través de Software Assurance en Azure.
Instancias reservadas para cargas de trabajo predecibles
Las cargas de trabajo predecibles son aquellas que siempre tienen que estar disponibles con máquinas virtuales
en ejecución; por ejemplo, las aplicaciones de línea de negocio como un sistema ERP de SAP. Las cargas de
trabajo impredecibles son variables, como las máquinas virtuales que están encendidas durante los períodos de
alta demanda y apagadas cuando la demanda es baja.
Figura 3: Azure Reserved Virtual

Machine Instances.
A cambio de usar instancias reservadas para instancias específicas de máquinas virtuales que necesitan
mantenimiento durante largos períodos de tiempo, Contoso puede obtener un descuento y una capacidad
prioritaria. Usar Azure Reserved Virtual Machine Instances junto con la Ventaja de híbrida de Azure permite a
Contoso ahorrar hasta un 82 % del precio de pago por uso habitual (en abril de 2018).
Paso 2: Administración de identidad híbrida

Otorgar y controlar el acceso de los usuarios a los recursos de Azure mediante Administración de identidad y
acceso es un paso importante a la hora de crear una infraestructura de Azure.
Contoso decide extender su instancia de Active Directory local a la nube, en lugar de crear un nuevo sistema
independiente en Azure. Como Contoso todavía no usa Microsoft 365, debe aprovisionar una instancia de
Azure AD. Si Contoso usara Microsoft 365, ya tendría un inquilino y un directorio de Azure AD que podría usar
como instancia principal de Azure AD.
Obtenga más información sobre los modelos de identidad de Microsoft 365 y Azure Active Directory. También
puede aprender a asociar o agregar una suscripción de Azure a su inquilino de Azure Active Directory.
Crear un directorio de Azure AD
Contoso usa la edición Azure AD Free que se incluye con una suscripción a Azure. Los administradores de
Contoso crean un directorio de Azure AD:
1. En Azure Portal, estos administradores irán a Crear un recurso > Identidad > Azure Active
Director y .
2. En Crear directorio , especificarán un nombre para el directorio, un nombre de dominio inicial y la
región en la que se debe crear el directorio.
Ilustración 4: Creación de un directorio de Azure AD.
NOTE
El directorio creado tiene un nombre de dominio inicial con el formato domain-name.onmicrosoft.com . Este nombre no
se podrá modificar ni eliminar. En su lugar, los administradores deberán agregar su nombre de dominio registrado en
Azure AD.
Agregar el nombre del dominio

Para usar el nombre de dominio estándar, los administradores de Contoso tienen que agregarlo como un
nombre de dominio personalizado a Azure AD. Esta opción permite a los administradores asignar nombres de
usuario conocidos. Por ejemplo, un usuario puede iniciar sesión con la dirección de correo electrónico
[email protected] , en lugar de [email protected] .
Para configurar un nombre de dominio personalizado, los administradores lo agregan al directorio, se agrega
una entrada DNS y, luego, se comprueba el nombre en Azure AD.
1. En Nombres de dominio personalizado > Agregar dominio personalizado , Contoso agrega el
dominio.
2. Para utilizar una entrada DNS en Azure, es necesario registrarla con el registrador de dominios:
En la lista Nombres de dominio personalizado , se tiene en cuenta la información de DNS para el
nombre. Usa un registro MX.
Es necesario acceder al servidor de nombres. Se inicia sesión en el dominio contoso.com y se crea un
nuevo registro MX para la entrada DNS proporcionada por Azure AD con los detalles indicados.
3. Una vez propagados los registros DNS, en los detalles del dominio, se selecciona Verificar para
comprobar el nombre de dominio personalizado.
Ilustración 5: Comprobación del nombre de dominio.
Configurar usuarios y grupos de Azure y locales
Ahora que Azure AD ya está establecido, los administradores de Contoso deben agregar empleados a grupos de
Active Directory locales que se sincronizarán con Azure AD. Es recomendable que usen nombres de grupos
locales que coincidan con los nombres de los grupos de recursos de Azure. Esto hace más fácil identificar las
coincidencias con fines de sincronización.
Crear grupos de recursos en Azure
Los grupos de recursos de Azure recopilan los recursos de Azure. Usar un identificador de grupo de recursos
permite que Azure realice operaciones en los recursos del grupo.
Una suscripción de Azure puede tener varios grupos de recursos. Un grupo de recursos existe en una sola
suscripción. Además, un único grupo de recursos puede tener varios recursos. Cada recurso pertenece a un
único grupo de recursos.
Los administradores de Contoso configuran los grupos de recursos de Azure tal como se muestra en la tabla
siguiente.
RESO URC E GRO UP DETA L L ES
ContosoCobRG Este grupo contiene todos los recursos relacionados con la

continuidad de negocio. Aquí se incluyen los almacenes que
Contoso usará para los servicios Azure Site Recovery y Azure
Backup.
También se incluyen los recursos que se usaron para la

migración, como Azure Migrate y Azure Database Migration
Service.
ContosoDevRG Este grupo contiene recursos de desarrollo y pruebas.
ContosoFailoverRG Este grupo actúa como una zona de aterrizaje para los
recursos conmutados por error.
RESO URC E GRO UP DETA L L ES
ContosoNetworkingRG Este grupo contiene todos los recursos de red.
ContosoRG Este grupo contiene los recursos relacionados con las

aplicaciones y bases de datos de producción.
Contoso crea los grupos de recursos de la siguiente manera:

1. En Azure Portal > Grupos de recursos , agrega un grupo.
2. Para cada grupo especifica un nombre, la suscripción a la que pertenece el grupo y la región.
3. Los grupos de recursos aparecen en la lista Grupos de recursos .
Ilustración 6: Grupos de recursos.

Esc a l a r g r u p o s d e r e c u r so s
En el futuro, Contoso agregará otros grupos de recursos según las necesidades. Por ejemplo, se podría definir
un grupo de recursos para cada aplicación o servicio, para que se pueden administrar y proteger de forma
independiente.
Crear grupos de seguridad coincidentes locales
En la instancia de Active Directory local, los administradores de Contoso configurarán los grupos de seguridad
con nombres que coincidan con los nombres de los grupos de recursos de Azure.
Figura 7: Grupos de seguridad de Active Directory locales.
Para fines de administración, se crea un grupo adicional que se agregará a todos los demás grupos. Este grupo
tendrá derechos para todos los grupos de recursos de Azure. A este grupo se agregará un número limitado de
administradores globales.
Sincronización de Active Directory
Contoso quiere proporcionar una identidad común para obtener acceso a los recursos locales y en la nube. Para
ello, integrará la instancia de Active Directory local con Azure AD. Con este modelo, los usuarios y las
organizaciones pueden aprovechar las ventajas de una identidad única para acceder a aplicaciones locales y a
servicios como Microsoft 365 y miles de sitios más en Internet. Los administradores pueden usar los grupos de
Active Directory para implementar el control de acceso basado en roles de Azure (RBAC de Azure).
Para facilitar la integración, Contoso usa la herramienta Azure AD Connect. Al instalar y configurar la
herramienta en un controlador de dominio, se sincronizan las identidades locales de Active Directory en
Azure AD.
Descargar la herramienta
1. En Azure Portal, los administradores de Contoso van a Azure Active Director y > Azure AD Connect y
descargan la versión más reciente de la herramienta en el servidor que se usa para la sincronización.
Ilustración 8: Descarga de Azure AD Connect.

2. Inician la instalación de AzureADConnect.msi con la opción Configuración rápida . Esta es la instalación
más habitual y puede utilizarse para una topología de bosque único con sincronización de hash de
contraseñas para la autenticación.
Ilustración 9: Asistente para Azure AD Connect.
3. En Conectar con Azure AD , se especifican las credenciales para conectarse a Azure AD (con el formato
[email protected] o [email protected] ).
Ilustración 10: Asistente para Azure AD Connect: Conéctese a Azure AD.

4. En Conectar con AD DS , se especifican las credenciales del directorio local (con el formato
CONTOSO\admin o contoso.com\admin ).
Ilustración 11: Asistente para Azure AD Connect: Conectar con AD DS.

5. En Listo para configurar , se selecciona Star t the synchronization process when configuration
completes (Iniciar el proceso de sincronización cuando finalice la configuración) para iniciar de
inmediato la sincronización. A continuación, se realiza la instalación.
Tenga en cuenta lo siguiente:
Contoso tiene una conexión directa con Azure. Si su instancia local de Active Directory está detrás
de un proxy, consulte Solución de problemas de conectividad de Azure AD.
Después de la primera sincronización, los objetos locales de Active Directory están visibles en el
directorio de Azure AD.
Ilustración 12: Objetos del entorno local de Active Directory visibles en Azure AD.
El equipo de TI de Contoso está representado en cada grupo y se basa en su rol.
Figure 13: Pertenencia a grupos.

Configuración de RBAC de Azure
RBAC de Azure permite la administración detallada del acceso a Azure. Con RBAC de Azure, puede conceder
únicamente el grado de acceso que los usuarios necesiten para realizar su trabajo. Asigne el rol de Azure
adecuado a los usuarios, grupos y aplicaciones en un nivel de ámbito. El ámbito de una asignación de roles
puede ser una suscripción, un grupo de recursos o un único recurso.
A continuación, los administradores de Contoso asignan roles a los grupos de Active Directory que
sincronizaron desde el entorno local.
1. En el grupo de recursos ControlCobRG , seleccionan Control de acceso (IAM) > Agregar asignación
de roles .
2. En Agregar asignación de roles > Rol > Colaborador , seleccionan el grupo de seguridad
ContosoCobRG de la lista. El grupo aparece entonces en la lista Miembros seleccionados .
3. Esto se repite con los mismos permisos para los demás grupos de recursos (excepto para
ContosoAzureAdmins ), mediante la adición de permisos de Colaborador al grupo de seguridad que
corresponda al grupo de recursos.
4. Para el grupo de seguridad ContosoAzureAdmins , se asigna el rol Propietario .
Ilustración 14: Asignación de roles a grupos de seguridad.
Paso 3: Diseño para lograr resistencia

Configuración de regiones
Los recursos de Azure se implementan en las regiones. Las regiones se organizan por zonas geográficas. Los
requisitos de residencia, soberanía, cumplimiento normativo y resistencia de los datos se cumplen dentro de las
fronteras geográficas.
Una región se compone de un conjunto de centros de datos. Estos centros de datos se implementan dentro de
un perímetro que define la latencia y se conectan a través de una red regional dedicada de baja latencia.
Cada región de Azure se empareja con una región diferente para proporcionar resistencia. Obtenga información
acerca de las regiones de Azure para comprender cómo están emparejadas.
Contoso ha decidido que su región primaria sea East US 2 (que se encuentra en Virginia) y su región
secundaria, Central US (que se encuentra en Iowa), por estos motivos:
El centro de datos de Contoso se encuentra en Nueva York, y Contoso consideró la latencia en función de del
centro de datos más cercano.
East US 2 tiene todos los servicios y productos que necesita Contoso. No todas las regiones de Azure tienen
los mismos productos y servicios disponibles. Para obtener más información, consulte Productos de Azure
disponibles por región.
Central US es la región de Azure emparejada para East US 2 .
Cuando piensa en su entorno híbrido, Contoso debe considerar cómo compilar una estrategia de recuperación
ante desastres y de resistencia en su diseño de la región. La estrategia más sencilla es una implementación en
una sola región, que se basa en características de la plataforma Azure como, por ejemplo, los dominios de error
y el emparejamiento regional para lograr resistencia. La estrategia más compleja consiste en un modelo
completamente activo-activo en el que los servicios y las bases de datos en la nube se implementan y ofrecen a
los usuarios de dos regiones.
Contoso ha decidido tomar un camino intermedio. Se implementarán las aplicaciones y recursos en una región
primaria y se mantendrá una copia completa de la infraestructura en la región secundaria. Con esa estrategia, la
copia está lista para funcionar como una copia de seguridad completa en caso de que se produzca un desastre
completo o un error regional de la aplicación.
Configuración de la disponibilidad
Conjuntos de disponibilidad
Los conjuntos de disponibilidad ayudan a proteger las aplicaciones y los datos en caso de interrupción de la red
o del hardware local de un centro de datos. Los conjuntos de disponibilidad distribuyen las máquinas virtuales
de Azure entre el hardware físico de un centro de datos.
Los dominios de error representan el hardware subyacente con una fuente de alimentación común y un
conmutador de red dentro del centro de datos. Las máquinas virtuales de un conjunto de disponibilidad están
distribuidas entre los dominios de error para minimizar las interrupciones provocadas por un solo error de la
red o del hardware.
Los dominios de actualización representan hardware subyacente que puede someterse a mantenimiento o
reiniciarse al mismo tiempo. Los conjuntos de disponibilidad también distribuyen las máquinas virtuales entre
varios dominios de actualización para garantizar que al menos habrá una instancia en ejecución en todo
momento.
Contoso implementará los conjuntos de disponibilidad cada vez que las cargas de trabajo de VM requieran alta
disponibilidad. Para más información, consulte Administración de la disponibilidad de las máquinas virtuales
Windows en Azure.
Zonas de disponibilidad
Las zonas de disponibilidad ayudan a proteger las aplicaciones y los datos frente a los errores que afecten a
todo un centro de datos dentro de una región.
Cada zona de disponibilidad representa una ubicación física exclusiva dentro de una región de Azure. Cada zona
de disponibilidad consta de uno o varios centros de datos equipados con alimentación, refrigeración y redes
independientes.
Hay tres zonas independientes como mínimo en todas las regiones habilitadas. La separación física de las zonas
dentro de una región protege las aplicaciones y los datos frente a los errores del centro de datos.
Contoso usará zonas de disponibilidad siempre que las aplicaciones requieran mayor escalabilidad,
disponibilidad y resistencia. Para obtener más información, consulte Regiones y zonas de disponibilidad en
Azure.
Configuración de la copia de seguridad
Azure Backup
Puede usar Azure Backup para crear copias de seguridad de discos de máquinas virtuales de Azure y
restaurarlos.
Azure Backup permite crear copias de seguridad automatizadas de imágenes de discos de máquinas virtuales y
almacenarlas en Azure Storage. Las copias de seguridad son coherentes con la aplicación para garantizar que los
datos con copia de seguridad sean transaccionalmente coherentes y que las aplicaciones arranquen después de
la restauración.
Azure Backup admite el almacenamiento con redundancia local para replicar varias copias de los datos con
copia de seguridad de un centro de datos si se produce un error de hardware local. Si se produce una
interrupción regional, Azure Backup también admite el almacenamiento con redundancia geográfica, que replica
los datos de la copia de seguridad en una región secundaria emparejada.
Azure Backup cifra los datos en tránsito mediante AES-256. Los datos en reposo con copia de seguridad se
cifran mediante el cifrado de Azure Storage.
Contoso usará Azure Backup con GRS en todas las VM de producción para garantizar que se creen copias de
seguridad de los datos de cargas de trabajo y que se puedan restaurar rápidamente si se produce una
interrupción. Para más información, consulte la introducción a la copia de seguridad de máquinas virtuales de
Azure.
Configuración de la recuperación ante desastres
Azure Site Recovery
Azure Site Recovery ayuda a garantizar la continuidad empresarial manteniendo las aplicaciones y cargas de
trabajo empresariales en funcionamiento durante las interrupciones regionales.
Azure Site Recovery replica de manera continua las VM de Azure de una región primaria a una secundaria, lo
que garantiza la existencia de copias funcionales en ambas ubicaciones. En caso de que se produzca una
interrupción en la región primaria, la aplicación o el servicio conmutará por error y pasará a usar instancias de
máquinas virtuales replicadas en la región secundaria. Esta conmutación por error minimiza las posibles
interrupciones. Cuando las operaciones vuelven a la normalidad, las aplicaciones o servicios pueden conmutar
por recuperación en las máquinas virtuales de la región primaria.
Contoso implementará Azure Site Recovery para todas las VM de producción que se usan en cargas de trabajo
críticas, lo que garantiza una interrupción mínima durante un corte en la región primaria.
Paso 4: Diseño de una infraestructura de red

Con el diseño de la región establecido, Contoso está listo para considerar una estrategia de red. Debe pensar en
cómo se conectan y comunican entre sí el centro de datos local y Azure, y cómo diseñar la infraestructura de red
en Azure. En concreto, Contoso debe:
Planear la conectividad de red híbrida : averiguar cómo van a conectarse las redes entre las instancias
locales y Azure.
Diseñar una infraestructura de red de Azure : decidir cómo implementar las redes en las regiones.
¿Cómo se comunicarán las redes dentro de la misma región y entre las diferentes regiones?
Diseñar y configurar redes de Azure : configurar redes y subredes de Azure, y decidir qué residirá en
cada una.
Planear conectividad de red híbrida
Contoso consideró varias arquitecturas de redes híbridas entre Azure y su centro de datos local. Para obtener
más información, consulte. Elección de una solución para conectar una red local a Azure.
Como recordatorio, la infraestructura de red local de Contoso está formada por su centro de datos de Nueva
York y sucursales locales en la mitad oriental de Estados Unidos. Todas las ubicaciones tienen una conexión de
clase empresarial a Internet. Cada una de las sucursales está conectada al centro de datos a través de un túnel
VPN con IPsec a través de Internet.
Figura 15: La red de Contoso.

Aquí se muestra cómo Contoso decidió implementar conectividad híbrida:
1. Se configura una nueva conexión VPN de sitio a sitio entre el centro de datos de Contoso en Nueva York y las
dos regiones de Azure: East US 2 y Central US .
2. El tráfico de las sucursales con destino a las redes virtuales en Azure se dirigirá a través del centro de datos
principal de Contoso.
3. Al escalar verticalmente la implementación de Azure, Contoso establecerá una conexión de Azure
ExpressRoute entre su centro de datos y las regiones de Azure. Cuando esto suceda, Contoso podrá
conservar la conexión VPN de sitio a sitio únicamente con fines de conmutación por error.
Obtenga más información acerca de la elección entre una solución híbrida ExpressRoute y VPN.
Comprobar el soporte y las ubicaciones de ExpressRoute.
Solo VPN:
Figura 16: La VPN de Contoso.

VPN y ExpressRoute:
Figura 17: VPN de Contoso y
ExpressRoute.
Diseño de la infraestructura de red de Azure
La configuración de la red de Contoso debe hacer que implementación híbrida sea segura y escalable. Para ello,
Contoso adoptará un enfoque a largo plazo y diseñará redes virtuales resistentes y listas para la empresa. Para
más información, consulte Planear redes virtuales.
Para conectar las dos regiones, Contoso implementará un modelo de red entre centros de conectividad. En cada
región, Contoso utilizará un modelo de tipo hub-and-spoke. Para conectar redes y concentradores, Contoso
usará el emparejamiento de redes de Azure.
Emparejamiento de redes
El emparejamiento de redes virtuales en Azure conecta las redes virtuales y los centros de conectividad. El
emparejamiento global permite realizar conexiones entre redes virtuales o centros de regiones diferentes. El
emparejamiento local conecta redes virtuales en la misma región.
El emparejamiento de redes virtuales proporciona varias ventajas:
El tráfico de red entre redes virtuales emparejadas es privado.
El tráfico entre las redes virtuales se mantiene en la red troncal de Microsoft. No se requiere ninguna red
pública de Internet, puertas de enlace ni cifrado en la comunicación entre las redes virtuales.
El emparejamiento proporciona una conexión predeterminada de gran ancho de banda y baja latencia entre
los diferentes recursos de las redes virtuales.
Modelo de centro de conectividad a centro de conectividad entre regiones
Contoso implementará un concentrador en cada región. Un centro de conectividad es una red virtual en Azure
que actúa como punto central de conectividad para la red local. Las redes virtuales del centro de conectividad se
conectarán entre sí mediante el emparejamiento global de redes virtuales, que conecta las redes virtuales entre
las regiones de Azure. El concentrador de cada región está emparejado a su concentrador asociado en la otra
región. El centro de conectividad está emparejado con todas las redes de la región y puede conectarse a todos
los recursos de red.
Figura 18: Emparejamiento global.
Modelo de topología de red en estrella tipo hub-and-spoke dentro de una región
Dentro de cada región, Contoso implementará redes virtuales con fines diferentes como redes radiales que
parten del centro de conectividad de la región. Las redes virtuales de una región usan la opción de
emparejamiento para conectarse a su centro de conectividad y entre sí.
Diseño de la red del concentrador
En el modelo de topología en estrella tipo hub-and-spoke, Contoso tiene que pensar en cómo se enrutará el
tráfico desde el centro de datos local y desde Internet. A continuación, se muestra cómo Contoso decidió
controlar el enrutamiento para los centros de conectividad de East US 2 y Central US :
Contoso está diseñando una red que permite el tráfico desde Internet y desde su red corporativa a Azure a
través de una VPN.
Su arquitectura de red tiene dos límites, una zona de confianza perimetral front-end y una zona de confianza
de back-end.
Un firewall tendrá un adaptador de red en cada zona, para controlar el acceso a zonas de confianza.
Desde Internet:
El tráfico de Internet alcanzará una dirección IP pública de carga equilibrada en la red perimetral.
Este tráfico se enruta a través del firewall y está sujeto a las reglas de firewall.
Después de implementar los controles de acceso de red, el tráfico se reenviará a la ubicación
adecuada en la zona de confianza.
El tráfico saliente de la red virtual se enrutará a Internet mediante rutas definidas por el usuario. El
tráfico se fuerza a través del firewall y se inspecciona que cumpla las directivas de Contoso.
Desde el centro de datos de Contoso:
El tráfico que entra a través de la VPN de sitio a sitio o ExpressRoute llega a la dirección IP pública de
la puerta de enlace de red virtual de Azure.
Este tráfico se enruta a través del firewall y está sujeto a las reglas de firewall.
Después de la aplicación de las reglas de firewall, el tráfico se reenvía a un equilibrador de carga
interno (SKU estándar) en la subred de la zona interna de confianza.
El tráfico saliente de la subred de confianza que va al centro de datos local a través de VPN se enruta a
través del firewall. Las reglas se aplican antes de que el tráfico pase por la conexión de VPN de sitio a
sitio.
Diseño y configuración de redes de Azure
Con una red y una topología de enrutamiento, Contoso está preparado para configurar sus redes y subredes de
Azure:
Contoso implementará una red privada de clase A en Azure ( 10.0.0.0/8 ). Esto funciona debido al entorno
local. Actualmente tiene un espacio de direcciones privadas de clase B ( 172.160.0.0/16 ). Contoso puede
estar seguro de que no habrá ninguna superposición entre los intervalos de direcciones.
Contoso implementará redes virtuales en las regiones primarias y secundarias.
Contoso usará una convención de nomenclatura que incluye el prefijo VNET y la abreviatura de región EUS2
o CUS . Según este estándar, las redes del centro de conectividad se denominarán VNET-HUB-EUS2 en la región
East US 2 y VNET-HUB-CUS en la región Central US .
Redes virtuales en East US 2
East US 2 es la región principal que Contoso usará para implementar servicios y recursos. A continuación se
indica cómo diseñará Contoso las redes en esa región:
Centro: la red virtual del centro de conectividad de East US 2 se considera la conectividad principal de
Contoso con el centro de datos local.
Redes vir tuales: las redes virtuales de radios de East US 2 pueden usarse para aislar las cargas de
trabajo si es necesario. Además de la red virtual del centro de conectividad, Contoso tendrá dos redes
virtuales de radios en East US 2 :
VNET-DEV-EUS2. Esta red virtual proporcionará al equipo de desarrollo y pruebas una red
totalmente funcional para los proyectos de desarrollo. Actuará como una zona piloto de
producción y dependerá de la infraestructura de producción para su funcionamiento.
VNET-PROD-EUS2 . los componentes de producción de IaaS de Azure se encontrarán en esta red.
Cada red virtual tendrá su propio espacio de direcciones únicas, sin superposiciones. Contoso desea
configurar el enrutamiento sin necesidad de una traducción de direcciones de red (NAT).
Subredes: Habrá una subred en cada red para cada capa de aplicación. Cada subred de la red de
producción tendrá una subred correspondiente en la red virtual de desarrollo. La red de producción tiene
una subred para controladores de dominio.
En la tabla siguiente se resumen las redes virtuales de East US 2 .
VIRT UA L N ET W O RK IN T ERVA LO DEL M ISM O N IVEL
VNET-HUB-EUS2 10.240.0.0/20 VNET-HUB-CUS2 , VNET-DEV-EUS2 ,

VNET-PROD-EUS2
VNET-DEV-EUS2 10.245.16.0/20 VNET-HUB-EUS2
VNET-PROD-EUS2 10.245.32.0/20 VNET-HUB-EUS2 , VNET-PROD-CUS
Figura 19: Modelo radial.

Subredes en la red East US 2 Hub ( VNET-HUB-EUS2 )
SUB RED/ Z O N A C IDR DIREC C IO N ES IP Q UE SE P UEDEN USA R
IB-UntrustZone 10.240.0.0/24 251
IB-TrustZone 10.240.1.0/24 251
OB-UntrustZone 10.240.2.0/24 251
OB-TrustZone 10.240.3.0/24 251
GatewaySubnet 10.240.10.0/24 251
Subredes en la red de desarrollo East US 2 ( VNET-DEV-EUS2 )

El equipo de desarrollo usa la red virtual de desarrollo como área piloto de producción. Tiene tres subredes.
SUB N ET C IDR DIREC C IO N ES EN L A SUB RED
DEV-FE-EUS2 10.245.16.0/22 1019 Máquinas virtuales de nivel

web o servidores front-end
DEV-APP-EUS2 10.245.20.0/22 1019 Máquinas virtuales de

DEV-DB-EUS2 10.245.24.0/23 507 VM de base de datos
Subredes en la red de producción East US 2 ( VNET-PROD-EUS2 )

Los componentes de IaaS de Azure se encuentran en la red de producción. Cada capa de aplicación tiene su
propia subred. Las subredes se corresponden con las de la red de desarrollo, además de una subred para los
controladores de dominio.
PROD-FE-EUS2 10.245.32.0/22 1019 Máquinas virtuales de nivel

PROD-APP-EUS2 10.245.36.0/22 1019 Máquinas virtuales de

PROD-DB-EUS2 10.245.40.0/23 507 VM de base de datos
PROD-DC-EUS2 10.245.42.0/24 251 VM del controlador de

dominio
Figura 20: Arquitectura de red de centro de conectividad.
Redes virtuales de Central US (región secundaria)
Central US es la región secundaria de Contoso. Así es como Contoso diseñará sus redes:
Centro: la red virtual del centro de conectividad de Central US se considera el punto de conectividad
secundario con respecto al centro de datos local. las redes virtuales de radios de Central US pueden
usarse para aislar las cargas de trabajo si es necesario y administrarlas de manera independiente con
respecto a las de otros radios.
Redes vir tuales: Contoso tendrá dos redes virtuales en Central US :
VNET-PROD-CUS : esta es una red de producción y se puede considerar un centro de conectividad
secundario.
VNET-ASR-CUS : Esta red virtual actuará como una ubicación en la que las máquinas virtuales se crean
después de la conmutación por error desde el entorno local, o como una ubicación para las máquinas
virtuales de Azure que conmuten por error desde el servidor principal en la región secundaria. Esta
red es similar a las redes de producción, pero sin ningún controlador de dominio.
Cada red virtual de la región tendrá su propio espacio de direcciones, sin superposición. Contoso
configurará el enrutamiento sin NAT.
Subredes: las subredes se diseñarán de una manera similar a las de la región East US 2 .
En la tabla siguiente se resumen las redes virtuales de Central US .
VIRT UA L N ET W O RK IN T ERVA LO DEL M ISM O N IVEL
VNET-HUB-CUS 10.250.0.0/20 VNET-HUB-EUS2 , VNET-ASR-CUS ,

VNET-PROD-CUS
VNET-ASR-CUS 10.255.16.0/20 VNET-HUB-CUS , VNET-PROD-CUS
VNET-PROD-CUS 10.255.32.0/20 VNET-HUB-CUS , VNET-ASR-CUS ,

VNET-PROD-EUS2
Figura 21: Modelo radial en una región emparejada.
Subredes de la red del centro de conectividad de Central US ( VNET-HUB-CUS )
SUB N ET C IDR DIREC C IO N ES IP Q UE SE P UEDEN USA R
IB-UntrustZone 10.250.0.0/24 251
IB-TrustZone 10.250.1.0/24 251
OB-UntrustZone 10.250.2.0/24 251
OB-TrustZone 10.250.3.0/24 251
GatewaySubnet 10.250.10.0/24 251
Subredes en la red de producción Central US ( VNET-PROD-CUS )

En paralelo con la red de producción de la región primaria ( East US 2 ), hay una red de producción en la región
secundaria ( Central US ).
PROD-FE-CUS 10.255.32.0/22 1019 Máquinas virtuales de nivel

PROD-APP-CUS 10.255.36.0/22 1019 Máquinas virtuales de

PROD-DB-CUS 10.255.40.0/23 507 VM de base de datos
PROD-DC-CUS 10.255.42.0/24 251 VM del controlador de

dominio
Subredes de la red de conmutación por error o por recuperación de Central US ( VNET-ASR-CUS )

La red VNET-ASR-CUS se utiliza para la conmutación por error entre regiones. Site Recovery se usará para
replicar y conmutar por error las VM de Azure entre las regiones. También funciona como un centro de datos de
Contoso para la red de Azure creada para las cargas de trabajo protegidas que se guardan de forma local, pero
que conmutan por error a Azure en caso de recuperación ante desastres.
VNET-ASR-CUS es la misma subred básica que la de la red virtual de producción de East US 2 , pero sin
necesidad de una subred de controlador de dominio.
ASR-FE-CUS 10.255.16.0/22 1019 Máquinas virtuales de nivel

ASR-APP-CUS 10.255.20.0/22 1019 Máquinas virtuales de

ASR-DB-CUS 10.255.24.0/23 507 VM de base de datos
Figura 22: Arquitectura de red de centro de conectividad.

Configurar conexiones emparejadas
El centro de conectividad de cada región se emparejará al centro de conectividad de la otra región, y a todas las
redes virtuales de la región del centro de conectividad. Esta configuración permite que los centros de
conectividad se comuniquen y ver todas las redes virtuales de una región. Tenga en cuenta que el
emparejamiento crea una conexión con dos lados. Uno desde el mismo nivel de inicio en la primera red virtual,
y otro en la segunda red virtual.
En una implementación híbrida, el tráfico que pasa entre equipos del mismo nivel debe verse desde la conexión
VPN entre el centro de datos local y Azure. Para habilitar esto, Contoso debe usar una configuración específica
en las conexiones emparejadas. Para las conexiones desde redes virtuales de radios que se realizan a través del
centro de conectividad hasta el centro de datos local, Contoso debe permitir que el tráfico se reenvíe y atraviese
las puertas de enlace de VPN.
Con t r ol ador de dom i n i o
En el caso de los controladores de dominio de la red VNET-PROD-EUS2 , Contoso desea que el tráfico fluya entre la
red del centro de conectividad o producción EUS2 a través de la conexión de VPN hasta el entorno local. Para
ello, los administradores de Contoso deben permitir lo siguiente:
1. Allow for warded traffic (Permitir tráfico reenviado) y Allow gateway transit configurations
(Permitir configuraciones de tránsito de puer ta de enlace) en la conexión emparejada. En nuestro
ejemplo, esta sería la conexión de VNET-HUB-EUS2 a VNET-PROD-EUS2 .
Ilustración 23: Conexión emparejada.
2. Seleccione Permitir tráfico reenviado y Usar puer tas de enlace remotas en el otro lado del
emparejamiento, en la conexión de VNET-PROD-EUS2 a VNET-HUB-EUS2 .

3. En el entorno local, se configurará una ruta estática que enruta el tráfico local a la red virtual a través del
túnel VPN. La configuración se completará en la puerta de enlace que proporciona el túnel VPN desde
Contoso a Azure. Se usa el servicio de enrutamiento y acceso remoto (RRAS) para la ruta estática.

Redes de pr o du c c i ó n
Una red del mismo nivel con radio no puede ver a través de un concentrador a otra red del mismo nivel con
radio que se encuentre en otra región. Para que las redes de producción de Contoso en ambas regiones puedan
verse entre sí, los administradores de Contoso deben crear una conexión directa emparejada para
VNET-PROD-EUS2 y VENT-PROD-CUS .
Figura 26: Creación de una conexión emparejada directa.

Configurar DNS
Al implementar recursos en redes virtuales, tiene un par de opciones para la resolución del nombre de dominio.
Puede usar la resolución de nombres que proporciona Azure o proporcionar servidores DNS para la resolución.
El tipo de resolución de nombres que use dependerá de cómo se comuniquen los recursos entre sí. Obtenga
más información acerca del servicio Azure DNS.
Los administradores de Contoso han decidido que el servicio Azure DNS no es una buena opción en su entorno
híbrido. En su lugar, se usarán los servidores DNS locales. Estos son los detalles:
Puesto que se trata de una red híbrida, todas las máquinas virtuales locales y en Azure deben ser capaces
de resolver nombres para funcionar correctamente. Esto significa que la configuración personalizada de
DNS debe aplicarse a todas las redes virtuales.
Contoso actualmente tiene controladores de dominio implementados en el centro de datos de Contoso y
en las sucursales. Los servidores DNS principales son contosodc1 ( 172.16.0.10 ) y contosodc2 (
172.16.0.1 ).
Una vez que se implementan las redes virtuales, los controladores de dominio locales se configuran
como servidores DNS en las redes.
Si se especifica un DNS personalizado para la red virtual, es necesario agregar a la lista la dirección IP
virtual 168.63.129.16 de las resoluciones recursivas de Azure. Para ello, Contoso configura el servidor
DNS en cada red virtual. Por ejemplo, la configuración de DNS personalizada para la red VNET-HUB-EUS2
sería la siguiente:
Figura 27: Servidor DNS personalizado.
Además de sus controladores de dominio local, Contoso implementará cuatro más para dar apoyo a sus redes
de Azure (dos para cada región):
REGIO N DC VIRT UA L N ET W O RK SUB N ET DIREC C IÓ N IP
East US 2 contosodc3 VNET-PROD-EUS2 PROD-DC-EUS2 10.245.42.4
East US 2 contosodc4 VNET-PROD-EUS2 PROD-DC-EUS2 10.245.42.5
Central US contosodc5 VNET-PROD-CUS PROD-DC-CUS 10.255.42.4
Central US contosodc6 VNET-PROD-CUS PROD-DC-CUS 10.255.42.4
Después de implementar los controladores de dominio local, Contoso necesita actualizar la configuración de
DNS en redes en ambas regiones para incluir los nuevos controladores de dominio en su lista de servidores
DNS.
Configurar controladores de dominio de Azure
Después de actualizar la configuración de red, los administradores de Contoso están listos para crear sus
controladores de dominio en Azure.
1. En Azure Portal, se implementa una nueva máquina virtual de Windows Server en la red virtual
adecuada.
2. Se crean conjuntos de disponibilidad en cada ubicación para la VM. Los conjuntos de disponibilidad
garantizan que el tejido de Azure separa las máquinas virtuales en infraestructuras diferentes en la
región de Azure. Los conjuntos de disponibilidad también permiten a Contoso optar a un Acuerdo de
Nivel de Servicio del 99,95 % para las máquinas virtuales de Azure.
Figura 28: Conjunto de disponibilidad.
3. Una vez implementada la VM, hay que encargarse de la interfaz de red de la VM. Se establece la dirección
IP privada como estática y se especifica una dirección válida.
Figura 29: CONEXIÓN DE INTERFAZ DE RED (NIC) DE MÁQUINA VIRTUAL.

4. Ahora, se conecta un nuevo disco de datos a la máquina virtual. Este disco contiene la base de datos de
Active Directory y el recurso compartido de SYSVOL.
El tamaño del disco determinará el número de IOPS que admite. Con el tiempo, es posible que el tamaño
del disco tenga que aumentar a medida que crece el entorno.
NOTE
El disco no se debe configurar como de lectura y escritura para el almacenamiento en caché del host. Las bases de
datos de Active Directory no admiten esto.
Figura 30: Disco de Active Directory.
5. Una vez agregado el disco, se conecta a una máquina virtual a través de los servicios de Escritorio
remoto y abren el Administrador del servidor.
6. En Ser vicios de archivos y almacenamiento , se ejecuta el Asistente para nuevo volumen. Se
comprueba que a la unidad se le asigna la letra F u otra posterior en la máquina virtual local.
Figura 31: Asistente para nuevo volumen.

7. En Administrador del servidor, se agrega el rol Active Director y Domain Ser vices . A continuación, la
máquina virtual se configura como un controlador de dominio.
Figura 32: Adición del rol de servidor.

8. Cuando la máquina virtual esté configurada como controlador de dominio y se haya reiniciado, Contoso
abrirá el administrador de DNS y configurará el solucionador de Azure DNS como reenviador. Esto
permite que el controlador de dominio reenvíe consultas DNS que no se pueden resolver en el DNS de
Azure.
Figura 33: Configuración del solucionador de Azure DNS.
9. Contoso actualiza la configuración de DNS personalizada para cada red virtual con el controlador de
dominio adecuado para la región de la red virtual. La lista incluye controladores de dominio locales.
Configuración de Active Directory
Active Directory es un servicio crítico de la red y debe estar configurado correctamente. Los administradores de
Contoso crean sitios de Active Directory para el centro de datos de Contoso y para las regiones East US 2 y
Central US .
1. Crean dos nuevos sitios ( AZURE-EUS2 y AZURE-CUS ) junto con el sitio del centro de datos (
contoso-datacenter ).
2. Después de crear los sitios, se crean subredes en ellos, para que coincidan las redes virtuales y el centro
de datos.
Figura 34: Subredes del centro de datos.

3. Se crean dos vínculos a sitios para conectarlo todo. Los controladores de dominio deberán moverse a su
ubicación.
Figura 35: Vínculos del centro de datos.
4. Se confirma que la topología de replicación de Active Directory está lista.
Figura 36: Replicación del centro de datos.

Con todo completo, se muestra una lista de los sitios y los controladores de dominio en el Centro de
administración de Active Directory local.
Figura 37: Centro

de administración de Active Directory.
Paso 5: Planeación para la gobernanza

Azure proporciona una gama de controles de gobernanza a través de los servicios y la plataforma de Azure.
Para obtener más información, consulte las opciones de gobernanza en Azure.
A medida que Contoso configura la identidad y el control de acceso, comienza a tener en cuenta algunos
aspectos acerca de la gobernanza y la seguridad. En términos generales, hay tres áreas que deben tener en
cuenta:
Directiva: Azure Policy aplica reglas y efectos a los recursos para que cumplan los requisitos corporativos y
los Acuerdos de Nivel de Servicio.
Bloqueos: Azure permite el bloqueo de suscripciones, recursos y grupos de recursos para que solo puedan
modificarlos aquellas personas con los permisos adecuados.
Etiquetas: los recursos pueden controlarse, auditarse y administrarse con etiquetas. Las etiquetas asocian
metadatos a recursos, que proporcionan información acerca de los recursos o propietarios.
Configurar directivas
El servicio Azure Policy evalúa los recursos para detectar los que no son compatibles con las definiciones de
directivas. Por ejemplo, podría tener una directiva que solo permite determinados tipos de máquinas virtuales o
que requieren que los recursos tengan una etiqueta específica.
Las directivas especifican una definición de directiva, mientras que una asignación de directiva especifica el
ámbito en el que se debe aplicar una directiva. El ámbito puede ir desde un grupo de administración a un grupo
de recursos. Aprenda a crear y administrar directivas.
Contoso desea comenzar con dos directivas. Quiere una directiva para asegurarse de que los recursos solo
pueden implementarse en las regiones East US 2 y Central US . También quiere otra directiva para limitar las
SKU de máquinas virtuales a las SKU aprobadas. La intención es asegurarse de que no se usan SKU de VM
costosas.
Limitación de recursos en las regiones
Contoso usa la definición de directiva integrada Ubicaciones permitidas para limitar las regiones de los
recursos.
1. En Azure Portal, seleccione Todos los ser vicios y busque Directiva .
2. Seleccione Asignaciones > Asignar directiva .
3. En la lista de directivas, seleccione Ubicaciones permitidas .
4. Establezca Ámbito en el nombre de la suscripción de Azure y seleccione las dos regiones en la lista de
permitidos.
Figura 38: Ubicaciones permitidas definidas mediante directiva.

5. De forma predeterminada, se establece la directiva con Denegar . Esto significa que si alguien inicia una
implementación en la suscripción que no está en la región East US 2 o Central US , se produce un error
en la implementación. Esto es lo que ocurre si alguien de la suscripción de Contoso intenta configurar
una implementación en la región West US .
Figura 39: Directiva con errores.
Permitir determinadas SKU de VM
Contoso usará la definición de la directiva integrada Allow virtual machine SKUs para limitar los tipos de VM
que se pueden crear en la suscripción.
Figura 40: SKU de directiva.

Comprobar cumplimiento de directivas
Las directivas entran inmediatamente en vigor y Contoso puede comprobar el cumplimiento de los recursos. En
Azure Portal, seleccione el vínculo Cumplimiento . Aparece el panel de cumplimiento. Puedes explorar en
profundidad para obtener más detalles.
Figura 41: Cumplimiento de la directiva.

Configurar bloqueos
Contoso lleva mucho tiempo usando el marco de ITIL para administrar sus sistemas. Uno de los aspectos más
importantes del marco es el control de cambios, y Contoso quiere asegurarse de que el control de cambios se
incluye en la implementación de Azure.
Contoso bloqueará los recursos. Cualquier componente de conmutación por error o de producción debe estar
en un grupo de recursos con un bloqueo de solo lectura. Esto significa que, para modificar o eliminar elementos
de producción, los usuarios autorizados deben quitar el bloqueo. Los grupos de recursos que no son de
producción tendrán bloqueos CanNotDelete . Esto significa que los usuarios autorizados pueden leer o modificar
un recurso, pero no pueden eliminarlo.
Configuración del etiquetado
Para realizar el seguimiento de los recursos que se agregan, será cada vez más importante que Contoso asocie
los recursos con el departamento, el cliente o el entorno adecuados. Además de proporcionar información
acerca de los recursos y propietarios, las etiquetas permitirán a Contoso agregar y agrupar recursos, y usar esos
datos con fines de contracargo.
Contoso necesita visualizar sus recursos de Azure de forma que tenga sentido para su empresa, por ejemplo por
rol o departamento. Tenga en cuenta que los recursos no tienen que residir en el mismo grupo de recursos para
compartir una etiqueta. Contoso creará una taxonomía de etiquetas para que todo el mundo use las mismas
etiquetas.
N O M B RE DE ET IQ UETA VA L UE
CostCenter 12345: debe ser un centro de coste válido de SAP.
BusinessUnit Nombre de la unidad de negocio (de SAP). Coincide con

CostCenter .
ApplicationTeam Alias de correo electrónico del equipo propietario del

soporte técnico de la aplicación.
CatalogName Nombre de la aplicación o SharedServices , según el

catálogo de servicios que el recurso admita.
ServiceManager Alias de correo electrónico del Administrador de servicios de

ITIL para el recurso.
COBPriority Prioridad que estableció la empresa para BCDR. Valores de 1

a 5.
ENV DEV , STG y PROD son los valores permitidos, que

representan los procesos de desarrollo, almacenamiento
provisional y producción.
Por ejemplo:
Figura 42: Etiquetas de Azure.
Después de crear la etiqueta, Contoso volverá atrás y creará nuevas asignaciones y definiciones de directiva
para exigir el uso de las etiquetas necesarias en toda la organización.
Paso 6: Consideración de la seguridad

La seguridad es fundamental en la nube y Azure proporciona una amplia gama de herramientas y
funcionalidades de seguridad. Esto ayuda a crear soluciones seguras en la plataforma segura de Azure. Para más
información sobre la seguridad de Azure, consulte Confíe en su nube.
Hay algunos aspectos que Contoso debe contemplar:
Azure Security Center proporciona administración de la seguridad unificada y Microsoft Defender for Identity
en todas las cargas de trabajo de la nube híbrida. Úselo para aplicar directivas de seguridad en las cargas de
trabajo, limitar la exposición a amenazas, y detectar y responder a ataques.
Un grupo de seguridad de red filtra el tráfico de red en función de una lista de reglas de seguridad que
permiten o deniegan el tráfico de red a los recursos conectados con redes virtuales de Azure.
Azure Disk Encryption es una funcionalidad que permite cifrar los discos de las máquinas virtuales IaaS con
Windows y Linux.
Trabajar con Azure Security Center.
Contoso quiere conocer rápidamente la postura de seguridad de su nueva nube híbrida y, sobre todo, de las
cargas de trabajo de Azure. Como resultado, Contoso ha decidido implementar Azure Security Center a partir de
las siguientes características:
Administración de directivas centralizada
Evaluación continua
Recomendaciones prácticas
Administración de directivas centralizada
Gracias a la administración centralizada de directiva, Contoso garantizará el cumplimiento de los requisitos de
seguridad administrando las directivas de seguridad de forma centralizada en todo el entorno. Puede
implementar una directiva que se aplique a todos sus recursos de Azure de manera simple y rápida.
Figura 43:
Directiva de seguridad.
Evaluación de la seguridad
Contoso aprovechará la evaluación de seguridad continua que supervisa la seguridad de máquinas, redes,
almacenamiento, datos y aplicaciones, para detectar posibles problemas de seguridad.
Security Center analiza el estado de seguridad del proceso, la infraestructura y los recursos de datos de Contoso.
También analiza el estado de seguridad de las aplicaciones y servicios de Azure. La evaluación continua ayuda al
equipo de operaciones de Contoso a detectar posibles problemas de seguridad, por ejemplo, sistemas a los que
les faltan actualizaciones de seguridad o puertos de red expuestos.
Contoso quiere asegurarse de que todas las máquinas virtuales estén protegidas. Security Center ayuda a
hacerlo. Lo hace mediante la comprobación del estado de las máquinas virtuales, realizando recomendaciones
con prioridad, útiles para corregir las vulnerabilidades de seguridad antes de que surjan.
Figura
44: Supervisión.
Trabajar con Grupos de seguridad de red
Contoso puede limitar el tráfico de red a los recursos de una red virtual mediante grupos de seguridad de red.
Un grupo de seguridad de red contiene una lista de reglas de seguridad que permiten o deniegan el tráfico de
red entrante o saliente en función de las direcciones IP de origen o destino, el puerto y el protocolo. Cuando se
aplican a una subred, las reglas se aplican a todos los recursos de la subred. Además de interfaces de red, esto
incluye instancias de servicios de Azure implementados en la subred.
Los grupos de seguridad de aplicaciones permiten configurar la seguridad de red como extensión natural de
una estructura de aplicación. Puede agrupar las máquinas virtuales y definir directivas de seguridad de red
basadas en esos grupos.
Contoso puede utilizar grupos de seguridad de aplicaciones para reutilizar la directiva de seguridad a escala sin
mantenimiento manual de direcciones IP explícitas. La plataforma controla la complejidad de las direcciones IP
explícitas y de varios conjuntos de reglas, lo que permite a la organización centrarse en la lógica de negocios.
Contoso puede especificar un ASG como origen y destino en una regla de seguridad. Cuando se haya definido
una directiva de seguridad, Contoso podrá crear redes virtuales y asignar los adaptadores de red de las
máquinas virtuales a un grupo.
Contoso implementará una mezcla de NSG y ASG. Le preocupa la administración de NSG. También le preocupa
el uso excesivo de los grupos de seguridad de red y la mayor complejidad para el personal encargado de las
operaciones. Esto es lo que Contoso hará:
Todo el tráfico que entra y sale de todas las subredes (norte-sur) estará sujeto a una regla de grupo de
seguridad de red, excepto las subredes de puerta de enlace en las redes de centro de conectividad.
Cualquier controlador de dominio o firewall estará protegido por los grupos de seguridad de red de la
subred y por los de NIC.
Todas las aplicaciones de producción tendrán ASG aplicados.
Contoso ha creado un modelo con el aspecto que esta configuración de seguridad presentará para sus
aplicaciones.
Figura 45: Modelo de seguridad.
Los NSG asociados con el ASG se configurarán con privilegios mínimos para asegurarse de que solo los
paquetes permitidos pueden fluir de una parte de la red a su destino.
A C C IÓ N N O M B RE SO URC E DEST IN O P O RT
Allow AllowInternetToFE VNET-HUB-EUS1 / APP1-FE 80, 443

IB-TrustZone
Allow AllowWebToApp APP1-FE APP1-APP 80, 443
Allow AllowAppToDB APP1-APP APP1-DB 1433
Deny DenyAllInbound Any Any Any
Cifrado de datos
Azure Disk Encryption se integra con Azure Key Vault para ayudar a controlar y administrar las claves y los
secretos de cifrado de discos de una suscripción. Esto garantiza que todos los datos de los discos de máquina
virtual se cifren en reposo en Azure Storage.
Contoso determinó que las VM específicas requieren cifrado. Contoso aplicará el cifrado a las máquinas
virtuales que contengan datos de clientes, confidenciales o personales.
Conclusión
En este artículo, Contoso configuró su infraestructura y directiva para la suscripción a Azure, la identificación
híbrida, la recuperación ante desastres, las redes, la gobernanza y la seguridad.
No es necesario realizar todos los pasos que se indican aquí en una migración a la nube. En este caso, Contoso
ha planeado una infraestructura de red que permite controlar todos los tipos de migraciones y que es segura,
resistente y escalable.
Pasos siguientes
Después de configurar su infraestructura de Azure, Contoso está listo para empezar a migrar las cargas de
trabajo a la nube. Consulte la sección de introducción sobre los patrones y ejemplos de migración para ver una
selección de los escenarios que usan esta infraestructura de ejemplo como destino de migración.
Procedimientos recomendados para gestionar los
costos y el tamaño de las cargas de trabajo
migradas a Azure
Al planear y diseñar una migración de Azure, centrarse en los costos puede ayudar a garantizar su éxito a largo
plazo. Durante un proyecto de migración, es fundamental que todos los equipos (como los de finanzas,
administración y desarrollo de aplicaciones) comprendan los costos asociados a este proceso.
Antes de la migración, es importante tener una base de referencia para los objetivos de presupuesto
mensual, trimestral y anual con el fin de evaluar la cantidad de tiempo empleado en la migración y
asegurarse de que se ha realizado correctamente.
Tras la migración, debe optimizar los costos, supervisar continuamente las cargas de trabajo y planear los
patrones de uso futuro. Los recursos migrados podrían comenzar como un tipo de carga de trabajo y
cambiar a otro con el tiempo, en función del uso, los costos y requisitos empresariales cambiantes.
En este artículo se describen los procedimientos recomendados para preparar y administrar el costo y el
tamaño, tanto antes como después de la migración.
IMPORTANT
Los procedimientos recomendados y las opiniones que se describen en este artículo se basan en la plataforma Windows
Azure y las características disponibles en el momento de redactar el artículo. Las características y funcionalidades cambian
con el tiempo. No todas las recomendaciones pueden aplicarse para una implementación, de modo que seleccione lo que
sea válido en su caso.
Antes de la migración
Antes de mover las cargas de trabajo a la nube, valore el costo mensual que supone ejecutarlas en Azure. Una
administración proactiva de los costos de la nube le ayuda a cumplir su presupuesto para los gastos operativos.
Si el presupuesto es limitado, debe tenerlo en cuenta antes de la migración. Considere la posibilidad de
convertir las cargas de trabajo a las tecnologías sin servidor de Azure, cuando sea apropiado, para reducir los
costos.
Los procedimientos recomendados de esta sección le ayudarán a:
Evaluar los costos.
Realizar el ajuste de tamaño adecuado para las máquinas virtuales (VM) y el almacenamiento.
Usar la Ventaja híbrida de Azure.
Uso de Azure Reserved VM Instances.
Evaluar el gasto en la nube entre suscripciones.
Procedimiento recomendado: Evalúe los costos de la carga de trabajo

mensualmente
Para realizar la previsión de la factura mensual de las cargas de trabajo migradas, puede usar varias
herramientas.
Calculadora de precios de Azure: Seleccione los productos que desee calcular, por ejemplo las
máquinas virtuales y el almacenamiento. Después, especifique los costos en la calculadora, para calcular
una estimación.
Figura 1: Calculadora de precios de Azure.

Azure Migrate: Para calcular los costos, debe revisar y tener en cuenta todos los recursos necesarios
para ejecutar sus cargas de trabajo en Azure. A fin de obtener estos datos, cree un inventario de sus
activos, incluidos los servidores, las máquinas virtuales, las bases de datos y el almacenamiento. Puede
usar Azure Migrate para recopilar esta información.
Azure Migrate detecta y evalúa el entorno local para proporcionar un inventario.
Azure Migrate puede asignar y mostrar las dependencias entre las máquinas virtuales, de modo
que tenga una imagen completa.
Una evaluación de Azure Migrate contiene el costo estimado.
Costos de proceso: con el tamaño de máquina virtual de Azure recomendado cuando se crea
una evaluación, Azure Migrate usa las API de facturación de Azure para calcular los costos
mensuales estimados de cada máquina virtual. El cálculo considera la configuración del sistema
operativo, Software Assurance, Azure Reserved VM Instances, el tiempo de actividad de las VM,
la ubicación y la moneda. Suma el costo de todas las máquinas virtuales de la valoración y
calcula un costo de proceso total mensual.
Costo de almacenamiento : Azure Migrate calcula los costos de almacenamiento mensuales
totales; para ello, suma los costos de almacenamiento de todas las máquinas virtuales de la
evaluación. Puede sumar el costo mensual de todos los discos conectados a una máquina
concreta para calcular el costo de almacenamiento mensual de dicha máquina.
Figura 2: Valoración de Azure Migrate.
Más información:
Use la calculadora de precios de Azure.
Consulte la sección Información general de Azure Migrate.
Obtenga información sobre las evaluaciones de Azure Migrate.
Obtenga información sobre Azure Database Migration Service.
Procedimiento recomendado: Elección del tamaño adecuado para las

máquinas virtuales
Puede elegir varias opciones al implementar las máquinas virtuales de Azure para admitir cargas de trabajo.
Cada tipo tiene características específicas y combinaciones diferentes de CPU, memoria y discos. Las máquinas
virtuales se agrupan como se muestra en la tabla siguiente:
T IP O DETA L L ES USO
Uso general Uso equilibrado de CPU y memoria. Adecuada para pruebas y desarrollo,
bases de datos de tamaño pequeño o
mediano, y servidores web con un
volumen de tráfico bajo o medio.
Optimizada para proceso Uso elevado de la CPU respecto a la Adecuada para servidores web con un
memoria. volumen de tráfico medio, aplicaciones
de red, procesos por lotes y servidores
de aplicaciones.
Optimizada para memoria Memoria alta en relación con CPU. Adecuada para bases de datos
relacionales, memorias caché de
tamaño mediano a grande y análisis en
memoria.
Almacenamiento optimizado Alto rendimiento de disco y E/S. Adecuada para bases de datos SQL y
NoSQL, y macrodatos.
GPU optimizada Máquinas virtuales especializadas. Una Gráficos pesados y edición de vídeo.
o varias GPU.
Alto rendimiento CPU más rápida y eficaz. Máquinas Aplicaciones críticas de alto
virtuales con interfaces de red de alto rendimiento.
rendimiento (RDMA) opcionales.
Es importante comprender las diferencias de precio entre estas máquinas virtuales y los efectos a largo plazo
en el presupuesto.
Cada tipo tiene varias series de máquinas virtuales.
Además, cuando se selecciona una máquina virtual dentro de una serie, solo puede escalar la máquina
virtual y reducirla verticalmente dentro de esa serie. Por ejemplo, una instancia de DS2_v2 se puede escalar
verticalmente a DS4_v2 , pero no se puede cambiar a una instancia de otra serie, como F2s_v2 .
Más información:
Obtenga más información sobre los tipos de máquina virtual y el tamaño, y asigne tamaños a los tipos.
Planee los tamaños de las instancias de VM.
Revise un ejemplo de valoración de la empresa ficticia Contoso.
Procedimiento recomendado: Selección del almacenamiento correcto

El ajuste y el mantenimiento del almacenamiento local (SAN o NAS) y las redes para admitirlo puede resultar
costoso y lento. Los datos de los archivos (almacenamiento) normalmente se migran a la nube para ayudar a
aliviar las dificultades de administración y operativas. Microsoft ofrece varias opciones para mover datos a
Azure. Debe tomar decisiones acerca de esas opciones. Seleccionar el tipo correcto para el almacenamiento de
los datos puede ahorrar a la organización varios miles de dólares al mes. Sí, pero debe tener en cuenta algunas
consideraciones:
Los datos a los que no se accede mucho y no son críticos para la empresa no tienen por qué colocarse en el
almacenamiento más costoso.
Por el contrario, los datos empresariales importantes deben ubicarse en las opciones de almacenamiento de
nivel superior.
Durante el planeamiento de la migración, realice un inventario de los datos y clasifíquelos según su
importancia, con el fin de asignarlos al almacenamiento más adecuado. Considere el presupuesto y los
costos, así como el rendimiento. El costo no debe ser necesariamente el factor principal. Seleccionar la opción
menos cara podría exponer a la carga de trabajo a riesgos relacionados con la disponibilidad y el
rendimiento.
Tipos de datos de almacenamiento
Azure proporciona diferentes tipos de datos de almacenamiento.
T IP O DE DATO S DETA L L ES USO
Blobs Optimizado para almacenar grandes Permite el acceso a datos desde

cantidades de datos de objetos no cualquier lugar a través de
estructurados, como datos de texto o HTTP/HTTPS.
binarios.
Se usa para escenarios de acceso
aleatorio y streaming. Por ejemplo,
para servir imágenes y documentos
directamente a un explorador,
secuencias de vídeo y audio, y
almacenar los datos de recuperación
ante desastres y copia de seguridad.
Archivos Recursos compartidos de archivos Se usa al migrar recursos compartidos

administrados a los que se accede a de archivos locales y para proporcionar
través de SMB 3.0. varios tipos de acceso y conexiones a
los datos de los archivos.
Discos En función de los blobs en páginas. Se usan discos Premium para las
máquinas virtuales. Se usan discos
Tipo de disco: estándar (HDD o SSD) o administrados para simplificar la
premium (SSD). administración y la escala.
Administración de discos: no
administrado (se administra la
configuración de los discos y el
almacenamiento) o administrado (se
selecciona el tipo de disco y Azure lo
administra en su lugar).
Colas Se almacenan y recuperan grandes Se conectan componentes de

cantidades de mensajes, a los que se aplicaciones con colas de mensajes
accede a través de llamadas asincrónicas.
autenticadas (HTTP o HTTPS).
Tablas Se almacenan tablas. Este tipo de datos forma parte de la

Table API de Azure Cosmos DB.
Niveles de acceso
Azure Storage ofrece diferentes opciones para obtener acceso a los datos de blob en bloques. Si selecciona el
nivel de acceso adecuado, ayuda a garantizar que almacena los datos de blob en bloques de la manera más
rentable.
N IVEL DE A C C ESO DETA L L ES USO
Acceso frecuente El costo de almacenamiento es mayor Se emplea para datos en uso activo a
que en el nivel esporádico. Los gastos los que se accede con frecuencia.
de acceso son menores que en el nivel
esporádico.
Este es el nivel predeterminado.
Acceso esporádico El costo de almacenamiento es menor Almacenamiento a corto plazo. Los

que en el nivel frecuente. Los gastos datos están disponibles, pero se
de acceso son mayores que en el nivel accede a ellos con poca frecuencia.
frecuente.
El almacenamiento es para 30 días

como mínimo.
Archivar Se usa para blobs en bloques Se usa para los datos que admiten
individuales. varias horas de latencia de
recuperación y que permanecerán en
Es la opción más rentable para el ese nivel al menos durante 180 días.
almacenamiento. El acceso a los datos
es más caro que en los niveles de
acceso de uso frecuente y esporádico.
Tipos de cuenta de almacenamiento

Azure proporciona diferentes tipos de cuentas de almacenamiento y niveles de rendimiento.
T IP O DE C UEN TA DETA L L ES USO
Uso general v2 Estándar Admite blobs (de bloques, páginas y Se usa para la mayoría de los
anexos), archivos, discos, colas y tablas. escenarios y la mayoría de los tipos de
datos. Las cuentas de almacenamiento
Admite los niveles de acceso frecuente, estándar pueden basarse en HDD o en
esporádico y de archivo. Se admite el SSD.
almacenamiento con redundancia de
zona (ZRS).
Uso general v2 Premium Admite datos de Blob Storage (blobs Microsoft recomienda usarlo para
en páginas). Admite los niveles de todas las máquinas virtuales.
acceso frecuente, esporádico y de
archivo. Se admite ZRS.
Se almacena en SSD.
Uso general v1 No se admiten los niveles de acceso. Se usa si las aplicaciones necesitan el
No admite ZRS. modelo de implementación clásica de
Azure.
Blob Es la cuenta de almacenamiento En estas cuentas no se pueden

especializada para almacenar los almacenar blobs en páginas y, por lo
objetos no estructurados. Proporciona tanto, no se pueden almacenar
solo los blobs en bloques y blobs archivos de disco duro virtual. Puede
anexos (ningún servicio de establecer un nivel de acceso frecuente
almacenamiento de archivo, cola, tabla o esporádico.
o disco). Ofrece la misma durabilidad,
disponibilidad, escalabilidad y
rendimiento que el nivel estándar de
uso general v2.
Opciones de redundancia de almacenamiento

Las cuentas de almacenamiento pueden usar diferentes tipos de redundancia para lograr resistencia y alta
disponibilidad.
Almacenamiento con redundancia Protege contra una interrupción local Considere si la aplicación almacena
local (LRS) mediante la replicación dentro de una datos que se pueden reconstruir
unidad de almacenamiento individual a fácilmente.
un dominio de error y un dominio de
actualización independientes. Mantiene
varias copias de los datos en un centro
de datos. Proporciona una durabilidad
mínima del 99,999999999 por ciento
(once nueves) de los objetos en un año
en concreto.
Almacenamiento con redundancia Protege contra una interrupción del Considere si necesita coherencia,
de zona (ZRS) centro de datos; para ello, replica a durabilidad y alta disponibilidad. Podría
través de tres clústeres de no proteger frente a un desastre
almacenamiento en una sola región. regional en el que varias zonas
Cada clúster de almacenamiento está resulten afectadas de forma
separado físicamente y ubicado en su permanente.
propia zona de disponibilidad.
Proporciona al menos una durabilidad
del 99,9999999999 % (doce nueves)
de los objetos durante un año
determinado, para lo cual mantiene
varias copias de sus datos en varios
centros de datos o en regiones
diferentes.
Almacenamiento con redundancia Protege contra una interrupción de No hay disponibles datos de réplica a
geográfica (GRS) toda la región, mediante la replicación menos que Microsoft inicie la
de los datos en una región secundaria conmutación por error para la región
lejos de la réplica principal. Proporciona secundaria. Si se produce la
al menos una durabilidad del conmutación por error, el acceso de
99,99999999999999 por ciento lectura y de escritura está disponible.
(dieciséis nueves) de los objetos en un
año determinado.
Almacenamiento con redundancia Similar a GRS. Proporciona al menos Proporciona una disponibilidad de
geográfica con acceso de lectura una durabilidad del lectura del 99,99 %, ya que permite el
(RA-GRS). 99,99999999999999 por ciento acceso de lectura desde la segunda
(dieciséis nueves) de los objetos en un región utilizada para GRS.
año determinado.
Más información:
Revise los precios de Azure Storage.
Más información sobre la importación y exportación de Azure.
Compare blobs, archivos y tipos de datos de almacenamiento de disco.
Obtenga más información sobre los niveles de acceso.
Revise los diferentes tipos de cuentas de almacenamiento.
Obtenga información sobre la redundancia de Azure Storage, que incluye LRS, ZRS, GRS y GRS de solo
lectura.
Obtenga más información sobre Azure Files.
Procedimiento recomendado: use la Ventaja híbrida de Azure

Una cartera que integre el software de Microsoft local con Azure puede proporcionar ventajas competitivas y de
costos. Si actualmente tiene un sistema operativo o utiliza otras licencias de software mediante Software
Assurance, puede transferir esas licencias a la nube con la Ventaja híbrida de Azure.
Más información:
Eche un vistazo a la calculadora de ahorro de la Ventaja híbrida de Azure.
Obtenga más información sobre la Ventaja híbrida de Azure de Windows Server.
Revise la guía de precios de las VM de Azure de SQL Server.
Procedimiento recomendado: Uso de instancias reservadas de

máquina virtual
La mayoría de las plataformas en la nube usan un modelo de pago por uso. Este modelo presenta
inconvenientes, dado que no se tiene por qué conocer hasta qué punto variarán las cargas de trabajo. Cuando se
especifican intenciones claras para una carga de trabajo, se contribuye al plan de la infraestructura.
Si usa Azure Reserved VM Instances, paga por adelantado su uso durante un plazo de uno o de tres años para
VM Instances.
El pago por adelantado proporciona un descuento por los recursos que se utilizan.
Puede reducir considerablemente los costos de las máquinas virtuales, la capacidad de proceso de
SQL Database, Azure Cosmos DB u otros recursos con respecto a los precios de pago por uso.
Las reservas permiten un descuento en la facturación y no afectan al estado del entorno de ejecución de los
recursos.
Puede cancelar las instancias reservadas.
Figura 3: Azure Reserved VM Instances.

Más información:
Aprenda más sobre Azure Reservations.
Lea las preguntas más frecuentes sobre Azure Reserved VM Instances.
Consulte Orientación de precios de SQL Server en máquinas virtuales de Azure.
Procedimiento recomendado: Agregado del gasto en la nube entre

suscripciones
A la larga, es muy probable que tenga más de una suscripción de Azure. Por ejemplo, puede necesitar una
suscripción adicional para separar los límites de desarrollo y producción, o podría tener una plataforma que
requiera una suscripción independiente para cada cliente. Tener la capacidad de agregar informes de datos a
través de todas las suscripciones en una sola plataforma es una característica valiosa.
Para ello, puede usar las API de Azure Cost Management + Billing. A continuación, después de agregar los datos
en un único origen, como Azure SQL Database, puede usar herramientas como Power BI para mostrar los datos
agregados. Puede crear informes de suscripción agregados e informes pormenorizados. Por ejemplo, para los
usuarios que necesitan información proactiva sobre administración de costos, puede crear vistas específicas de
los costos, por departamento, grupo de recursos o cualquier otra información. No es necesario proporcionarles
acceso total a los datos de facturación de Azure.
Más información:
Lea la información general sobre las API de consumo de Azure.
Obtenga información sobre cómo conectarse a Azure Consumption Insights en Power BI Desktop.
Aprenda cómo administrar el acceso a la información de facturación de Azure mediante el control de acceso
basado en rol de Azure (RBAC de Azure).
Después de la migración
Después de una migración correcta de las cargas de trabajo y un par de semanas de recopilar datos de
consumo, tendrá una idea clara de los costos que suponen los recursos. Cuando analice los datos, podrá
empezar a generar una base de referencia de presupuesto para los recursos y los grupos de recursos de Azure.
A continuación, como ya sabe dónde se gasta su presupuesto en la nube, puede analizar cómo reducir aún más
los costos.
Procedimiento recomendado: Uso de Azure Cost Management +

Billing
Microsoft ofrece Azure Cost Management + Billing para ayudarle a realizar un seguimiento de los gastos. Este
servicio:
Le ayuda a supervisar y controlar el gasto de Azure y a optimizar el uso de los recursos.
Revisa la suscripción completa y todos sus recursos, y sugiere recomendaciones.
Proporciona una API completa para integrar las herramientas externas y los sistemas financieros para los
informes.
Realiza un seguimiento del uso de los recursos y le ayuda a administrar los costos en la nube con una sola
vista unificada.
Proporciona información valiosa operativa y financiera para ayudarle a tomar decisiones informadas.
Con Azure Cost Management + Billing:
cree un presupuesto de responsabilidad financiera.
Puede tener en cuenta los servicios que consume o suscribirse por un periodo específico (mensual,
trimestral o anual) y un ámbito (grupos de recursos o suscripciones). Por ejemplo, puede crear un
presupuesto de suscripción de Azure durante un período mensual, trimestral o anual.
Después de crear un presupuesto, se muestra en el análisis de costos. Es importante ver el
presupuesto frente al gasto actual cuando se analizan los costos y los gastos.
Puede elegir que se envíen notificaciones por correo electrónico cuando se alcancen los umbrales de
presupuesto.
Puede exportar datos de administración de costos en Azure Storage para analizarlos.
Figura 4: Presupuesto de Azure Cost Management + Billing.
Realice un análisis de los costos para explorar y analizar los gastos de la organización a fin de
comprender cómo se acumulan, así como identificar las tendencias del gasto.
El análisis de costos está disponible para los usuarios con el Contrato Enterprise.
Puede ver datos del análisis de costos de varios ámbitos y también por departamento, cuenta,
suscripción o grupo de recursos.
Puede obtener un análisis de costos que muestre los costos totales del mes actual y los acumulados
diariamente.
Figura 5: Análisis de Azure Cost Management + Billing.

Obtenga recomendaciones de Azure Advisor que le muestren cómo puede optimizar y mejorar la
eficacia.
Más información:
Consulte la introducción a Azure Cost Management + Billing.
Obtenga información sobre cómo optimizar la inversión en la nube con Azure Cost Management + Billing.
Obtenga información sobre los informes de Azure Cost Management + Billing.
Obtenga un tutorial para optimizar costos a partir de las recomendaciones.
Revise las API de consumo de Azure.
Procedimiento recomendado: Supervisar la utilización de recursos

En Azure se paga por lo que usa, cuando los recursos se utilizan, y no se paga cuando no se utilizan. En el caso
de las máquinas virtuales, la facturación se produce cuando alguna se asigna y no se cobra una vez se
desasigna. Teniendo esto en cuenta, debe supervisar las máquinas virtuales que se utilizan, así como comprobar
su tamaño.
Evalúe continuamente las cargas de trabajo de las máquinas virtuales para determinar las bases de referencia.
Por ejemplo, si la carga de trabajo se produce principalmente de lunes a viernes, de 8 a.m. a 6 p.m., pero apenas
hay fuera de esas horas, las máquinas virtuales pueden cambiarse a una versión inferior fuera de las horas
punta. Esto podría significar cambiar los tamaños de máquina virtual o el uso de conjuntos de escalado de
máquinas virtuales para escalarlas de forma automática, ampliándolas o reduciéndolas. Algunas compañías
"posponen" las VM a través de un calendario que especifica cuándo deben estar disponibles y cuándo no son
necesarias.
Puede supervisar el uso de las VM con herramientas de Microsoft, como Azure Cost Management + Billing,
Azure Monitor y Azure Advisor. También hay disponibles herramientas de terceros.
NOTE
Además de supervisar las máquinas virtuales, debe supervisar otros recursos de red, como Azure ExpressRoute y las
puertas de enlace de red, a fin de tener en cuenta cuándo se usan demasiado o demasiado poco.
Más información:
Lea los documentos de información general de Azure Monitor y Azure Advisor.
Obtenga recomendaciones sobre el costo de Azure Advisor.
Obtenga información sobre cómo optimizar los costos a partir de las recomendaciones y evitar cargos
imprevistos.
Obtenga información sobre el Kit de herramientas Azure Resource Optimization (ARO).
Procedimiento recomendado: Implementar presupuestos para los

grupos de recursos
A menudo, es posible que le resulte útil representar límites de costos con grupos de recursos. Un presupuesto
para un grupo de recursos le ayuda a realizar un seguimiento de los costos asociados al mismo. Puede
desencadenar alertas y ejecutar una amplia variedad de guías cuando alcance o supere el presupuesto.
Más información:
Aprenda a administrar los costos con Azure Budgets.
Revise un tutorial sobre la creación y administración de un presupuesto de Azure.
Procedimiento recomendado: Optimizar la retención de Azure
Monitor
A medida que mueve recursos a Azure y habilita el registro de diagnóstico para ellos, se genera una gran
cantidad de datos de registro. Normalmente, estos datos de registro se envían a una cuenta de almacenamiento
que se asigna a un área de trabajo de Log Analytics. Estas son algunas sugerencias para optimizar la retención
de Azure Monitor:
Cuanto mayor sea el período de retención de los datos de registro, más datos tendrá.
No todos los datos de registro son iguales y algunos recursos generarán más datos de registro que otros.
Debido a cuestiones relativas a la normativa y al cumplimiento, es probable que deba conservar los datos de
registro para algunos recursos más tiempo que para otros.
Debe delimitar con cuidado la estrategia para optimizar los costos de almacenamiento de registro frente a
mantener los datos de registro que necesita.
Se recomienda evaluar y configurar el registro inmediatamente después de completar una migración, de
modo que no invierta dinero en conservar registros no esenciales.
Más información:
Aprenda cómo supervisar el uso y los costos previstos.
Procedimiento recomendado: Optimizar el almacenamiento

Si ha seguido los procedimientos recomendados para seleccionar el almacenamiento antes de efectuar la
migración, probablemente disfrute ya de algunas ventajas. Sin embargo, puede que haya otros costos de
almacenamiento que se puedan optimizar. Con el tiempo, los blobs y archivos se vuelven obsoletos. Los datos
podrían dejar de usarse, pero los requisitos normativos podrían implicar que tenga que conservarlos durante un
período determinado. Por lo tanto, es posible que no necesite almacenarlos en el almacenamiento de alto
rendimiento que usa para la migración original.
Identificar y mover los datos obsoletos a áreas de almacenamiento más económicas puede tener un efecto
enorme en el presupuesto mensual de almacenamiento y en el ahorro en los costos. Azure ofrece muchas
maneras para ayudarle a identificar y, a continuación, almacenar estos datos obsoletos.
Aproveche las ventajas de los niveles de acceso para el almacenamiento de uso general v2. Para ello, pase los
datos menos importantes del nivel de acceso frecuente a los niveles esporádico y de archivo.
Use StorSimple para ayudar a mover los datos obsoletos en función de directivas personalizadas.
Más información:
Lea Introducción a StorSimple.
Revise Precios de StorSimple.
Procedimiento recomendado: Automatizar la optimización de las

máquinas virtuales
El objetivo final de ejecutar una máquina virtual en la nube es maximizar la CPU, la memoria y el disco que
utiliza. Si detecta que las máquinas virtuales no están optimizadas o hay con frecuencia períodos en los que no
se utilizan, tiene sentido apagarlas o disminuir su nivel mediante conjuntos de escalado de máquinas virtuales.
Puede optimizar una máquina virtual con Azure Automation, conjuntos de escalas de máquinas virtuales,
apagado automático y soluciones de terceros o con script.
Más información:
Obtenga información sobre el escalado automático vertical.
Programe el inicio automático de una máquina virtual.
Aprenda a iniciar o detener las VM fuera del horario laboral en Azure Automation.
Obtenga más información sobre Azure Advisor y el Kit de herramientas Azure Resource Optimization (ARO).
Procedimientos recomendados: Uso de Azure Logic Apps y runbooks

con la API de presupuestos
Azure proporciona una API REST que tiene acceso a la información de facturación del inquilino. Puede usar la
API de presupuestos para integrar los sistemas externos y los flujos de trabajo que las métricas construidas a
partir de los datos de la API desencadenen. Puede extraer datos de uso y de recursos, e incorporarlos en las
herramientas de análisis de datos de su preferencia. Puede integrar la API de presupuestos con Azure Logic
Apps y runbooks.
Las API de RateCard y de uso de recursos de Azure pueden ayudarlo a predecir y administrar los costos de
forma precisa. Las API se implementan como un proveedor de recursos y se incluyen entre las que Azure
Resource Manager expone.
Más información:
Revise la API de Azure Budgets.
Obtenga información sobre el uso con las API de facturación de Azure.
Procedimiento recomendado: Implementar tecnologías sin servidor

A menudo, las cargas de trabajo de máquina virtual se migran "tal cual" para evitar tiempos de inactividad. Con
frecuencia, las VM pueden hospedar tareas que son intermitentes, y que se ejecutan durante un breve período o
bien durante muchas horas. Algunos ejemplos son las máquinas virtuales que ejecutan tareas programadas,
como las del programador de tareas de Windows o los scripts de PowerShell. Cuando estas tareas no se están
ejecutando, incurre en gastos por la VM y el almacenamiento en disco.
Después de migrar y revisar exhaustivamente estos tipos de tareas, considere la posibilidad de migrarlas a
tecnologías sin servidor, como Azure Functions o trabajos de Azure Batch. Estas soluciones pueden reducir los
costos y ya no es necesario administrar y mantener las máquinas virtuales.
Más información:
Más información sobre Azure Functions.
Más información sobre Azure Batch.
Pasos siguientes
Explore los procedimientos recomendados de seguridad y administración después de la migración de cargas
de trabajo a Azure.
Explore los procedimientos recomendados de redes después de la migración de cargas de trabajo a Azure.
Escalado de una migración en Azure
En este artículo se muestra cómo la empresa ficticia Contoso realiza una migración a escala en Azure. La
compañía está considerando cómo planear y realizar una migración de más de 3000 cargas de trabajo, 8000
bases de datos y 10 000 máquinas virtuales.

lograr con esta migración:
de la empresa. El equipo de TI debe ir por delante de los cambios del mercado para garantizar el éxito en una
economía global. No debe entorpecer el avance ni ser un obstáculo para la empresa.
Escala. A medida que el negocio crece satisfactoriamente, el equipo de TI de Contoso debe facilitar sistemas
que puedan crecer al mismo ritmo.
Mejorar los modelos de costos. Contoso desea reducir los requisitos de capital del presupuesto de TI.
Asimismo, desea utilizar las capacidades de la nube para escalar y reducir la necesidad de hardware
demasiado caro.
Reducir los costos de licencias. Contoso quiere minimizar los costos de la nube.
El equipo de la nube de Contoso ha establecido los objetivos de esta migración. Estos objetivos se utilizan para
Migrar rápidamente a Azure Contoso desea comenzar a mover máquinas virtuales y

aplicaciones a Azure tan pronto como sea posible.
Compilar un inventario completo Contoso desea un inventario completo de todas las

aplicaciones, las bases de datos y las máquinas virtuales de
la organización.
Evaluación y clasificación de las aplicaciones Contoso quiere aprovechar al máximo la nube. De forma
predeterminada, Contoso supone que todos los servicios se
ejecutarán como plataforma como servicio (PaaS). Sin
embargo, se usará infraestructura como servicio cuando no
sea adecuado usar PaaS.
Entrenarse y migrar a DevOps Contoso desea pasar a un modelo DevOps. Para ello,
proporcionará formación de Azure y DevOps, y reorganizará
los equipos según sea necesario.
Después de establecer los objetivos y requisitos, Contoso revisa la huella de TI e identifica el proceso de
migración.
Implementación actual
Contoso ha planeado y configurado una infraestructura de Azure y ha probado otras combinaciones de
migración de prueba de concepto como se detalla en la tabla anterior. Ahora está listo para embarcarse en una
migración completa a Azure a escala. Esto es lo que Contoso desea migrar.
EL EM EN TO VO L UM EN DETA L L ES
Cargas de trabajo > 3000 aplicaciones Las aplicaciones se ejecutan en

Las plataformas de aplicaciones son
Windows, SQL Server y LAMP, entre
otras.
Bases de datos Aproximadamente 8500 bases de Las bases de datos incluyen

datos SQL Server, MySQL y PostgreSQL.
Máquinas virtuales Alrededor de 35 000 VM Las máquinas virtuales se ejecutan en

hosts de VMware y las administran
servidores vCenter.
Ahora que Contoso ha establecido las motivaciones empresariales y los objetivos de la migración, se puede
alinear con la metodología de migración. Puede basarse en la aplicación de oleadas y sprints de migración para
planear y ejecutar de forma iterativa los esfuerzos de migración.
Plan
Contoso inicia el proceso de planeamiento con la detección y evaluación de las aplicaciones, la infraestructura y
los datos locales. Esto es lo que Contoso hará:
Contoso debe detectar las aplicaciones, asignar las dependencias entre estas y decidir la prioridad y el orden
de la migración.
A medida que Contoso realiza esta evaluación, se creará un inventario detallado de las aplicaciones y
recursos. Junto con el nuevo inventario, Contoso usará y actualizará estos elementos existentes:
La base de datos de administración de configuración (CMDB). Esta contiene la configuración técnica
de las aplicaciones de Contoso.
El catálogo de servicios. El catálogo de servicios documenta los detalles operativos de las aplicaciones,
incluidos los socios comerciales asociados y los Acuerdos de Nivel de Servicio.
Detección de aplicaciones
Contoso ejecuta miles de aplicaciones en una amplia gama de servidores. Además de la CMDB y del catálogo de
servicios, Contoso necesita herramientas de detección y evaluación.
Las herramientas deben proporcionar un mecanismo que introduzca datos de evaluación en el proceso de
migración. Las herramientas de evaluación deben proporcionar datos que ayuden a crear un inventario
inteligente de los recursos físicos y virtuales de Contoso. Estos datos deben incluir información de perfil y
métricas de rendimiento.
Una vez completada la detección, Contoso debería disponer de un inventario completo de los recursos y los
metadatos asociados con estos. La compañía usará este inventario para definir el plan de migración.
Identificar las clasificaciones
Contoso identifica algunas categorías comunes para clasificar los recursos en el inventario. Estas clasificaciones
son fundamentales para la toma de decisiones de Contoso para la migración. La lista de clasificación ayuda a
establecer prioridades en la migración e identificar problemas complejos.
C AT EGO RY VA LO R A SIGN A DO DETA L L ES
Grupo de negocios Lista de nombres de grupos de ¿Qué grupo es responsable del artículo
negocios del inventario?
Candidato POC S/N ¿Se puede usar la aplicación como

prueba de concepto o pionera para la
migración a la nube?
Deuda técnica Ninguna/Alguna/Grave ¿El artículo del inventario se está

ejecutando o está utilizando un
producto, una plataforma o un sistema
operativo no compatible?
Implicaciones de Firewall S/N ¿La aplicación se comunica con

Internet o con tráfico externo? ¿Se
integra con un firewall?
Problemas de seguridad S/N ¿Hay problemas de seguridad

conocidos en la aplicación? ¿La
aplicación usa datos sin cifrar o
plataformas obsoletas?
Detección de dependencias de aplicaciones

Como parte del proceso de evaluación, Contoso debe identificar dónde se ejecutan las aplicaciones. También
debe averiguar las dependencias y las conexiones entre los servidores de aplicaciones. Contoso asigna el
entorno en diferentes pasos:
1. Contoso detecta cómo los servidores y los equipos se asignan a aplicaciones individuales, ubicaciones de red
y grupos.
2. Contoso identifica claramente las aplicaciones que tienen pocas dependencias y que son adecuadas para una
migración rápida.
3. Contoso puede usar la asignación para identificar las dependencias y las comunicaciones más complejas
entre servidores de aplicaciones. A continuación, Contoso podrá agrupar los servidores lógicamente para
representar las aplicaciones y planear una estrategia de migración en función de estos grupos.
Una vez concluida la asignación, Contoso puede garantizar que todos los componentes de la aplicación se
identifican y se tienen en cuenta al crear el plan de migración.
Evaluación de aplicaciones
Como último paso en el proceso de detección y evaluación, Contoso puede evaluar los resultados de la
evaluación y de la asignación para averiguar cómo migrar cada aplicación al catálogo de servicios.
Para capturar este proceso de evaluación, Contoso agrega un par de clasificaciones al inventario.
Grupo de negocios Lista de nombres de grupos de ¿Qué grupo es responsable del artículo
negocios del inventario?
Candidato POC S/N ¿Se puede usar la aplicación como

prueba de concepto o pionera para la
migración a la nube?
Deuda técnica Ninguna/Alguna/Grave ¿El artículo del inventario se está

ejecutando o está utilizando un
producto, una plataforma o un sistema
operativo no compatible?
Implicaciones de Firewall S/N ¿La aplicación se comunica con

Internet o con tráfico externo? ¿Se
integra con un firewall?
Problemas de seguridad S/N ¿Hay problemas de seguridad

conocidos en la aplicación? ¿La
aplicación usa datos sin cifrar o
plataformas obsoletas?
Estrategia de migración Rehospedar, refactorizar, rediseñar y ¿Qué tipo de migración necesita la

recompilar aplicación? ¿Cómo se implementará la
aplicación en Azure? Más información.
Complejidad técnica 1-5 ¿Cuál es el nivel de complejidad de la

migración? Este valor debe definirlo
Contoso DevOps y sus asociados
relevantes.
Crucial para la empresa 1-5 ¿Qué importancia tiene la aplicación

para la empresa? Por ejemplo, a una
aplicación de un grupo de trabajo
pequeño podría asignársele una
puntuación de 1, mientras que a una
aplicación fundamental que use toda la
organización se le asignaría una
puntuación de 5. Esta puntuación
afectará al nivel de prioridad de la
migración.
Prioridad de la migración 1/2/3 ¿Cuál es la prioridad de migración de la

aplicación?
Riesgo de migración 1-5 ¿Cuál es el nivel de riesgo de migrar la

aplicación? Este valor deben acordarlo
Contoso DevOps y los asociados
pertinentes.
Determinación de los costos

Para determinar los costos y el ahorro potencial de la migración a Azure, Contoso puede usar la calculadora del
costo total de propiedad (TCO) para calcular y comparar el TCO de Azure con una implementación local
comparable.
Identificar las herramientas de valoración
Contoso decide qué herramienta se usará para detectar, evaluar y crear el inventario. Contoso identifica
diferentes herramientas y servicios de Azure, scripts y herramientas de la aplicación, y herramientas de
asociados. En concreto, Contoso está interesado en cómo Azure Migrate puede usarse para evaluar a escala.
Azure Migrate
El servicio Azure Migrate le ayuda a detectar y evaluar VM de VMware locales que se están preparando para la
migración a Azure. Esto es lo que hace Azure Migrate:
1. Descubrir : detecta las máquinas virtuales locales de VMware.
Azure Migrate admite la detección de varios servidores vCenter (en serie) y puede ejecutar detecciones
en diferentes proyectos de Azure Migrate.
Azure Migrate realiza la detección a través de una VM de VMware que ejecuta Azure Migrate Collector. El
mismo recopilador puede detectar máquinas virtuales en diferentes servidores vCenter y enviar datos a
diferentes proyectos.
2. Evaluación de la preparación: evalúe si las máquinas locales son apropiadas para ejecutarse en Azure.
Una evaluación incluye:
Recomendaciones de tamaño: averigüe el tamaño recomendado de las máquinas virtuales de
Azure en función del historial de rendimiento de las máquinas virtuales locales.
Costos mensuales estimados: calcule el costo estimado de la ejecución de máquinas locales en
Azure.
3. Identificar las dependencias: visualice las dependencias de las máquinas locales, para crear grupos de
máquinas óptimos para la migración y la evaluación.
Contoso necesita usar Azure Migrate correctamente para determinar la escala de esta migración:
Contoso evalúa cada aplicación mediante Azure Migrate. Esta evaluación garantiza que Azure Migrate
devolverá los datos oportunamente a Azure Portal.
Los administradores de Contoso aprenden a implementar Azure Migrate a escala.
Contoso anota un resumen de los límites de Azure Migrate en la tabla siguiente.
A C C IÓ N L ÍM IT E
Crear un proyecto de Azure Migrate 10 000 máquinas virtuales
Detección 10 000 máquinas virtuales
Evaluación 10 000 máquinas virtuales
Contoso usará Azure Migrate como se indica a continuación:

En vCenter, Contoso organiza las máquinas virtuales en carpetas. Esto les permitirá a los administradores
concentrarse fácilmente al realizar una evaluación a las máquinas virtuales de una carpeta específica.
Evaluación de dependencias entre máquinas. Esto requiere la instalación de agentes en las máquinas
virtuales que deben evaluarse.
Contoso usará scripts automatizados para instalar los agentes necesarios de Windows o Linux. Mediante scripts,
Contoso puede realizar la instalación en las VM desde una carpeta vCenter.
Herramientas de base de datos
Además de Azure Migrate, Contoso usará herramientas específicas para la evaluación de la base de datos.
Herramientas como Data Migration Assistant ayudarán a evaluar las bases de datos de SQL Server para la
migración.
Data Migration Assistant puede ayudar a Contoso a averiguar si las bases de datos locales son compatibles con
una amplia gama de soluciones de Azure Database. Estas soluciones incluyen Azure SQL Database, SQL Server
en ejecución en una máquina virtual de IaaS de Azure y Azure SQL Managed Instance.
Además de Database Migration Service, Contoso tiene varios scripts que se usan para detectar y documentar las
bases de datos de SQL Server. Estos scripts se encuentran en el repositorio de GitHub.
Herramientas de evaluación de asociados
Hay otras herramientas de asociados que pueden ayudar a Contoso a evaluar el entorno local para la migración
a Azure. Obtenga más información sobre los asociados de migración de Azure.
Paso 2: Migrar
Una vez concluida la evaluación, Contoso debe identificar herramientas para trasladar sus aplicaciones, datos e
infraestructura a Azure.
Estrategias de migración
Hay cuatro estrategias de migración generales que Contoso puede considerar.
EST RAT EGIA DETA L L ES USO
Rehospedaje Esta opción sin necesidad de escribir Contoso puede rehospedar

código, que a menudo se denomina aplicaciones menos estratégicas que
migración mediante lift-and-shift, no requieren ningún cambio de
permite migrar las aplicaciones código.
existentes a Azure con rapidez.
Una aplicación se migra tal cual, con
las ventajas que ofrece la nube, y sin
correr el riesgo ni incurrir en los costos
asociados con los cambios de código.
Refactorización También denominada Contoso puede refactorizar

reempaquetado, esta estrategia aplicaciones estratégicas para
requiere una mínima cantidad de conservar la misma funcionalidad
cambios en el código de la aplicación o básica, pero moverlas para que se
en la configuración para conectar la ejecuten en una plataforma Azure
aplicación a Azure PaaS, y aprovechar como Azure App Service.
mejor las funcionalidades de la nube. Esta acción requiere cambios
mínimos en el código.
Por otro lado, Contoso deberá
mantener una plataforma de máquinas
virtuales, ya que esto ya no lo
administrará Microsoft.
Rediseño Esta estrategia modifica o amplía

una base de código de aplicación para
optimizar la arquitectura de la
aplicación para las capacidades y la
escala de la nube.
Moderniza una aplicación para que
tenga una arquitectura resistente y
muy escalable que se puede
implementar de forma independiente.
Los servicios de Azure permiten
agilizar el proceso, escalar aplicaciones
con confianza y administrar las
aplicaciones con facilidad.
EST RAT EGIA DETA L L ES USO
Volver a generar Este enfoque recompila una Contoso puede volver a escribir
aplicación desde cero con tecnologías aplicaciones críticas para aprovechar
nativas de la nube. las ventajas de las tecnologías de la
La plataforma como servicio (PaaS) nube, como los procesos sin servidor o
de Azure ofrece un entorno de los microservicios.
desarrollo e implementación completo Contoso administrará la aplicación y
en la nube. Elimina algunos gastos y la los servicios que desarrolla, y Azure
complejidad de las licencias de administrará todo lo demás.
software. También elimina la necesidad
de una infraestructura de aplicaciones
subyacente, middleware y otros
recursos.
También hay que tener en cuenta los datos, especialmente con el volumen de bases de datos que tiene Contoso.
De manera predeterminada, Contoso usa los servicios PaaS, como Azure SQL Database, para aprovechar al
máximo las características de la nube. Al cambiar a un servicio PaaS para bases de datos, Contoso solo tendrá
que mantener los datos. Dejará a Microsoft encargarse de la plataforma subyacente.
Evaluación de las herramientas de migración
Contoso usa principalmente estos servicios y herramientas de Azure para la migración:
Azure Migrate: servicio para migrar máquinas virtuales locales y otros recursos a Azure.
Azure Database Migration Service: herramienta que migra las bases de datos locales como SQL Server,
MySQL y Oracle a Azure.
Azure Migrate
Azure Migrate es el servicio principal de Azure para orquestar la migración dentro de Azure y desde sitios
locales a Azure.
Azure Migrate organiza la replicación de las ubicaciones locales a Azure. Cuando se configura y ejecuta la
replicación, los equipos locales pueden conmutar por error a Azure, completando la migración.
Contoso ya completó una prueba de concepto para ver cómo puede ayudarles Azure Migrate con la migración a
la nube.
U so d e A z u r e M i g r a t e a e sc a l a
Contoso planea realizar múltiples migraciones mediante lift-and-shift. Para asegurarse de que funciona, Azure
Migrate replicará lotes de aproximadamente 100 máquinas virtuales a la vez. Para determinar cómo funcionará,
Contoso debe planear la capacidad para la migración propuesta.
Contoso necesita recopilar información acerca de sus volúmenes de tráfico. En concreto:
Contoso necesita determinar la frecuencia de cambio para las máquinas virtuales que quiere replicar.
También debe tener en cuenta la conectividad de red desde el sitio local a Azure.
En respuesta a los requisitos de capacidad y volumen, Contoso deberá asignar un ancho de banda suficiente
basado en la frecuencia de cambio diaria de las máquinas virtuales necesarias, para así cumplir con el objetivo
del punto de recuperación (RPO). Por último, se debe terminar cuántos servidores se necesitan para ejecutar los
componentes de Azure Migrate necesarios para la implementación.
R e c o p i l a c i ó n d e i n fo r m a c i ó n l o c a l
Contoso puede usar Azure Migrate:

Para generar un perfil de máquinas virtuales de forma remota sin que afecte al entorno de producción. Esto
ayuda a identificar los requisitos de ancho de banda y almacenamiento para la replicación y la conmutación
por error.
Sin que sea preciso instalar localmente ningún componente de Site Recovery.
La herramienta recopila información sobre máquinas virtuales compatibles e incompatibles, discos por máquina
virtual y la actividad de datos por disco. También identifica los requisitos de ancho de banda de red y de la
infraestructura de Azure necesaria para una replicación y conmutación por error correctas.
A continuación, Contoso debe asegurarse de que se ejecute la herramienta de planeación en una máquina de
Windows Server que cumpla con los requisitos mínimos del servidor de configuración de Site Recovery. El
servidor de configuración es una máquina de Site Recovery necesaria para poder replicar máquinas virtuales de
VMware locales.
I d e n t i fi c a c i ó n d e l o s r e q u i si t o s d e Si t e R e c o v e r y
Además de las máquinas virtuales que se replican, Site Recovery requiere una serie de componentes para la
migración de VMware.
C O M P O N EN T E DETA L L ES
Servidor de configuración Normalmente, una máquina virtual de VMware se

configura mediante una plantilla de OVF.
El componente servidor de configuración coordina las
comunicaciones entre el entorno local y Azure, y administra
la replicación de datos.
Servidor de proceso Se instala de forma predeterminada en el servidor de

configuración.
El componente del servidor de procesos recibe los datos
de la replicación; los optimiza mediante almacenamiento en
caché, compresión y cifrado, y los envía a Azure Storage.
El servidor de procesos también instala el servicio Mobility
de Azure Site Recovery en las máquinas virtuales que se van
a replicar y realiza la detección automática de las máquinas
locales.
Las implementaciones de escalado necesitan servidores de
procesos independientes y adicionales para controlar
grandes volúmenes de tráfico de replicación.
Mobility Service El agente del servicio Mobility se instala en cada una de

las máquinas virtuales de VMware que se va a migrar con
Azure Site Recovery.
Contoso necesita averiguar cómo implementar estos componentes, en función de las consideraciones de
capacidad.
C O M P O N EN T E REQ UISITO S DE C A PA C IDA D
Tasa máxima de cambios diaria Un servidor de un solo proceso puede administrar una
tasa de cambio diaria de hasta 2 terabytes. Puesto que una
máquina virtual solo puede usar un servidor de procesos, la
frecuencia de cambio de datos diaria máxima que se admite
para una máquina virtual replicada es de 2 TB.
Rendimiento máximo Una cuenta de Azure Storage estándar puede controlar un

máximo de 20 000 solicitudes por segundo. Las operaciones
de E/S por segundo (IOPS) en una máquina virtual de
replicación deben estar dentro de este límite. Por ejemplo, si
una máquina virtual tiene 5 discos y cada disco genera
120 E/S por segundo (8 K de tamaño) en la máquina virtual,
esta máquina se encontrará dentro del límite de 500
operaciones de E/S por segundo por disco de Azure.
El número de cuentas de almacenamiento necesario es
igual al número total de operaciones de E/S por segundo de
la máquina de origen dividido por 20 000. Una máquina
replicada solo puede pertenecer a una cuenta de
almacenamiento en Azure.
Servidor de configuración Según la estimación de Contoso de replicar de 100 a 200

máquinas virtuales a la vez, y los requisitos de configuración
del tamaño de servidor, Contoso calcula que necesita el
siguiente tipo de configuración de la máquina del servidor:
CPU: 16 vCPU (2 sockets x 8 núcleos a 2,5 GHz)
Memoria: 32 GB
Disco de caché: 1 TB
Frecuencia de cambio de datos: De 1 a 2 TB
Además de los requisitos de tamaño, Contoso debe
asegurarse de que el servidor de configuración está ubicado
de forma óptima, en la misma red y segmento LAN que las
máquinas virtuales que se van a migrar.
Servidor de proceso Contoso implementará un servidor de procesos dedicado e

independiente con capacidad para replicar entre 100 y 200
máquinas virtuales:
CPU: 16 vCPU (2 sockets x 8 núcleos a 2,5 GHz)
Memoria: 32 GB
Disco de caché: 1 TB
Frecuencia de cambio de datos: De 1 a 2 TB
Como el servidor de procesos trabajará de forma intensiva,
está ubicado en un host ESXi que puede administrar las E/S
de disco, el tráfico de red y la CPU necesarios para la
replicación. Contoso se planteará la posibilidad de contar con
un host dedicado para este fin.
Redes Contoso ha revisado la infraestructura de VPN de sitio a

sitio actual y ha decidido implementar Azure ExpressRoute.
La implementación es fundamental porque reducirá la
latencia y mejorará el ancho de banda en la región primaria
de Azure de Contoso ( East US 2 ).
Contoso deberá supervisar cuidadosamente los datos que
fluyen desde el servidor de procesos. Si los datos
sobrecargan el ancho de banda de red, Contoso considerará
limitar el ancho de banda del servidor de procesos.
Azure Storage Para la migración, Contoso debe identificar el tipo y el

número correctos de cuentas de Azure Storage de destino.
Site Recovery replica los datos de máquina virtual en Azure
Storage.
Site Recovery puede replicar en cuentas de
almacenamiento SSD Premium o estándar.
Para decidir sobre el almacenamiento, Contoso debe
revisar los límites de almacenamiento y tener en cuenta el
crecimiento esperado y el aumento del uso en el futuro.
Dada la velocidad y la prioridad de las migraciones, Contoso
ha decidido usar discos SSD Premium.
Contoso decidió usar discos administrados para todas las
máquinas virtuales implementadas en Azure. El número de
IOPS necesario va a ayudar a determinar si los discos serán
HDD estándar, SSD estándar o SSD Premium.

Azure Database Migration Service es un servicio totalmente administrado que permite migraciones completas
desde varios orígenes de base de datos hasta las plataformas de datos de Azure con un tiempo de inactividad
mínimo. Estos son algunos detalles sobre el servicio:
Integra la funcionalidad de las herramientas y servicios existentes. También usa Data Migration Assistant
para generar informes de evaluación que identifican las recomendaciones sobre la compatibilidad de las
bases de datos y las modificaciones necesarias.
Usa un proceso de migración sencillo y autoguiado, con una evaluación inteligente que ayuda a abordar los
posibles problemas antes de la migración.
Puede llevar a cabo una migración a escala desde varios orígenes a la base de datos de destino de Azure.
Es compatible desde SQL Server 2005 a SQL Server 2017.
Database Migration Service no es la única herramienta de migración de base de datos de Microsoft. Consulta
una comparación de herramientas y servicios.
U so d e l se r v i c i o D a t a b a se M i g r a t i o n Se r v i c e a e sc a l a
Contoso usará Database Migration Service para las migraciones desde SQL Server.
Al aprovisionar Database Migration Service, Contoso tiene que ajustar el tamaño correctamente y configurarlo
para optimizar el rendimiento de las migraciones de datos. Contoso va a seleccionar el nivel Crítico para la
empresa con cuatro núcleos virtuales. Esta opción permite que el servicio aproveche varias CPU virtuales para
la paralelización y para una transferencia de datos más rápida.
Otra táctica de escalado de Contoso es escalar verticalmente y de manera temporal la instancia de destino de
Azure SQL Database o Azure Database for MySQL al plan de tarifa Premium durante la migración de los datos.
Esto minimiza la limitación de base de datos que podría afectar a las actividades de transferencia de datos
cuando una organización usa los niveles inferiores.
U so d e o t r a s h e r r a m i e n t a s
Además de Database Migration Service, Contoso puede usar otras herramientas y servicios para identificar la
información de la máquina virtual:
Los scripts pueden ayudar con las migraciones manuales. Estos se encuentran disponibles en el repositorio
de GitHub.
Varias herramientas de asociados para la migración.
<-- docutune:ignore "herramientas de administración de costos" -->
Listo para producción

Una vez que Contoso traslada los recursos a Azure, necesita agilizarlos para mejorar el rendimiento y maximizar
la rentabilidad de la inversión con herramientas de administración de costos. Dado que Azure es un servicio de
pago por uso, es fundamental que Contoso comprenda cómo funcionan los sistemas y se asegure de que
cuentan con el tamaño correcto.
Administración de costos + facturación de Azure
Para aprovechar al máximo su inversión en la nube, Contoso va a usar la herramienta gratuita Azure Cost
Management + Billing. Esta solución permite a Contoso administrar el gasto en la nube con transparencia y
precisión. Proporciona herramientas para supervisar, asignar y reducir los costos en la nube.
La herramienta Azure Cost Management + Billing proporciona informes de panel sencillos para ayudar con la
asignación de costos, los contracargos y la visibilidad de los gastos. La herramienta ayuda a optimizar los gastos
en la nube mediante la identificación de los recursos que Contoso no está aprovechando para que pueda
administrarlos y ajustarlos.
Puede obtener más información en Introducción a Azure Cost Management + Billing.
Herramientas nativas
Contoso también usará scripts para localizar los recursos no utilizados.
Durante las migraciones de gran tamaño, a menudo hay piezas de datos sobrantes, como unidades de disco
duro virtuales, que conllevan un costo, pero no proporcionan ningún valor para la empresa. Los scripts están
disponibles en el repositorio de GitHub.
Contoso aprovechará el trabajo realizado por el departamento de TI de Microsoft y considerará la posibilidad de
implementar el kit de herramientas de Azure Resource Optimization (ARO). El kit de herramientas también está
en el repositorio de GitHub.
Contoso puede implementar una cuenta de Azure Automation con runbooks preconfigurados, programar sus
suscripciones y empezar a ahorrar dinero. La optimización de recursos se realiza automáticamente en una
suscripción al crear o habilitar una programación, incluida la optimización en nuevos recursos. Esto proporciona
funcionalidades de automatización descentralizada para reducir costos. Características incluidas:
Posponer automáticamente las máquinas virtuales de Azure cuando el uso de CPU sea bajo.
Programar las máquinas virtuales de Azure para posponerse y no posponerse.
Programar las máquinas virtuales de Azure para que se pospongan o no en orden ascendente y descendente
con etiquetas de Azure.
Eliminación masiva de grupos de recursos a petición.
Herramientas de optimización de asociados
Contoso puede usar herramientas de asociados como Hanu y Scalr.
Paso 4: Proteger y administrar

Durante este paso, Contoso usa los recursos de seguridad y administración de Azure para gobernar, proteger y
supervisar las aplicaciones en la nube de Azure. Estos recursos ayudan a una organización a ejecutar un entorno
protegido y bien administrado mientras utiliza los productos disponibles en Azure Portal.
Contoso comienza a usar estos servicios durante la migración. Gracias a la funcionalidad híbrida de Azure,
Contoso continúa usando muchos de ellos para lograr una experiencia coherente en toda la nube híbrida.
Seguridad
Contoso se va a basar en Azure Security Center para lograr una administración unificada de la seguridad y en
Microsoft Defender for Identity en las cargas de trabajo de nube híbrida.
Security Center aporta visibilidad total y control sobre la seguridad de sus aplicaciones en la nube de Azure.
Contoso puede detectar rápidamente posibles amenazas y tomar medidas con rapidez, y reducir su exposición
de seguridad usando protección contra amenazas adaptable.
Más información sobre Security Center.
Supervisión
Contoso necesita visibilidad sobre el estado y el rendimiento de las aplicaciones recién migradas, así como
sobre la infraestructura y los datos que ahora se está ejecutando en Azure. Contoso usará las herramientas
integradas de supervisión de la nube de Azure, como Azure Monitor, área de trabajo de Log Analytics y
Application Insights.
Con estas herramientas, Contoso puede recopilar datos fácilmente de diversos orígenes y obtener conocimiento
con ellos. Por ejemplo, Contoso puede medir el uso de CPU, disco y memoria de sus máquinas virtuales, ver las
dependencias de aplicaciones y red entre varias máquinas virtuales y mantener un seguimiento del rendimiento
de las aplicaciones. Contoso usará estas herramientas de supervisión en la nube para tomar medidas e
integrarlas con las soluciones de servicios.
Más información sobre la supervisión de Azure.
Contoso necesita una estrategia de continuidad empresarial y recuperación ante desastres (BCDR) para sus
recursos de Azure.
Azure ofrece características integradas de BCDR para ayudar a proteger los datos y mantener en ejecución las
aplicaciones y los servicios.
Además de las características integradas, Contoso desea asegurarse de que puede recuperarse de errores, evitar
interrupciones empresariales costosas, satisfacer los objetivos de cumplimiento y proteger sus datos frente a
ransomware y errores humanos. Para ello, siga estos pasos:
Contoso implementará Azure Backup como una solución rentable para realizar copias de seguridad de los
recursos de Azure. Al estar integrado, Contoso permite configurar copias de seguridad en la nube con solo
algunos sencillos pasos.
Contoso configurará la recuperación ante desastres para máquinas virtuales de Azure con Azure Site
Recovery para la replicación, conmutación por error y conmutación por recuperación entre las regiones de
Azure que especifique. Esto garantiza que, si se produce una interrupción en la región primaria, las
aplicaciones que se ejecutan en máquinas virtuales de Azure siguen estando disponibles en la región
secundaria que elija Contoso. Más información.
Conclusión
En este artículo, Contoso planea una migración con escala a Azure. El proceso de migración se divide en cuatro
etapas. Las etapas van desde la evaluación y la migración, pasando por la optimización, la seguridad y la
administración una vez que la migración concluye.
Es importante para una organización planear un proyecto de migración como un proceso completo y migrar
sus sistemas mediante el desglose de conjuntos en clasificaciones y cifras que sean significativas para el
negocio. Al evaluar los datos y aplicar clasificaciones, el proyecto se puede dividir en una serie de migraciones
más pequeñas, que pueden ejecutarse rápidamente y de forma segura. La suma de estas migraciones más
pequeñas se convierte rápidamente en una migración correcta de gran tamaño a Azure.
Lenguajes de definición de datos para la migración
de esquemas
En este artículo se describen los aspectos de diseño y las opciones de rendimiento para los lenguajes de
definición de datos cuando se migran esquemas a Azure Synapse Analytics.
Consideraciones de diseño
Revise estas consideraciones de diseño al planear la migración del esquema.
Preparación de la migración
Al preparar la migración de los datos existentes a Azure Synapse Analytics, es importante definir claramente el
ámbito del ejercicio (especialmente para un proyecto de migración inicial). El tiempo invertido por anticipado
para comprender cómo se migrarán los objetos de base de datos y los procesos relacionados puede reducir el
esfuerzo y los riesgos más adelante en el proyecto.
Cree un inventario de los objetos de base de datos que se van a migrar. En función de la plataforma de origen,
este inventario incluirá algunos o todos los objetos siguientes:
Tablas
Vistas
Índices
Funciones
Procedimientos almacenados
Distribución de datos y creación de particiones
La información básica sobre estos objetos debe incluir métricas como los recuentos de filas, el tamaño físico, la
razón de compresión de los datos y las dependencias de objetos. Esta información debe estar disponible a
través de las consultas en las tablas del catálogo del sistema de origen. Los metadatos del sistema son el mejor
origen de esta información. Es posible que la documentación externa esté obsoleta y no esté sincronizada con
los cambios que se han aplicado a la estructura de datos desde la implementación inicial.
También es posible analizar el uso real de los objetos a partir de los registros de consultas o usar herramientas
de asociados de Microsoft, como Attunity Visibility, como ayuda. Es posible que no sea necesario migrar algunas
tablas debido a que ya no se usan en las consultas de producción.
La información sobre el tamaño de los datos y la carga de trabajo es importante para Azure Synapse Analytics
porque ayuda a definir las configuraciones adecuadas. Un ejemplo son los niveles de simultaneidad necesarios.
Comprender el crecimiento previsible de los datos y las cargas de trabajo puede afectar a una configuración de
destino recomendada por lo que resulta útil aprovechar esta información.
Al usar volúmenes de datos para calcular el almacenamiento necesario para la plataforma de destino nueva, es
importante comprender la razón de compresión de los datos (si existe) en la base de datos de origen. Es
probable que la cantidad de almacenamiento que se usa en el sistema de origen sea una base falsa para el
ajuste de tamaño. La información de metadatos y supervisión puede ayudarle a determinar el tamaño de los
datos sin procesar sin comprimir, así como las sobrecargas de la indexación, la replicación de datos, el registro u
otros procesos del sistema actual.
El tamaño de los datos sin procesar no comprimidos de las tablas que se van a migrar es un buen punto inicial
para calcular el almacenamiento necesario en el entorno de Azure Synapse Analytics de destino nuevo.
La nueva plataforma de destino incluirá también un factor de compresión y una sobrecarga de indexación, pero
probablemente serán distintas en comparación con el sistema de origen. Los precios de almacenamiento de
Azure Synapse Analytics también incluyen siete días de copias de seguridad de instantáneas. Esto puede tener
un impacto en el costo total del almacenamiento necesario en comparación con el entorno existente.
Puede retrasar el ajuste del rendimiento del modelo de datos para más adelante en el proceso de migración y
programar este para cuando los volúmenes de datos reales estén en el almacenamiento de datos. Sin embargo,
se recomienda implementar algunas opciones de ajuste del rendimiento por anticipado.
Por ejemplo, en Azure Synapse Analytics, tiene sentido definir tablas de dimensiones pequeñas como tablas
replicadas y definir tablas de hechos grandes como índices agrupados de almacén de columnas. Del mismo
modo, los índices definidos en el entorno de origen proporcionan una buena indicación de las columnas que
pueden beneficiarse de la indexación en el entorno nuevo. Usar esta información al definir inicialmente las
tablas antes de la carga permitirá ahorrar tiempo más adelante en el proceso.
Se recomienda medir la razón de compresión y la sobrecarga de índice para sus propios datos en Azure
Synapse Analytics a medida que progresa el proyecto de migración. Esta medida permite planear la capacidad
futura.
Para reducir la complejidad y facilitar la migración, es posible simplificar el almacenamiento de datos existente
antes de la migración. Este esfuerzo puede incluir:
Quitar o archivar las tablas no utilizadas antes de la migración para evitar la migración de datos que no se
usan. Archivar en Azure Blob Storage y definir los datos como una tabla externa podría hacer que los datos
estuvieran disponibles a un menor costo.
Convertir los data marts físicos en data marts virtuales mediante software de virtualización de datos para
reducir lo que se debe migrar. Esta conversión también mejora la agilidad y reduce el costo total de
propiedad. Puede considerarla como una modernización durante la migración.
Un objetivo del ejercicio de migración también podría ser el de modernizar el almacén cambiando el modelo de
datos subyacente. Un ejemplo es el paso de un modelo de datos de estilo Inmon a un enfoque de almacén de
datos. Esto se debe decidir como parte de la fase de preparación y se debe incorporar una estrategia para la
transición en el plan de migración.
El enfoque recomendado en este escenario consiste en migrar primero el modelo de datos tal cual a la nueva
plataforma y, a continuación, realizar la transición al nuevo modelo en Azure Synapse Analytics. Utilice las
características de escalabilidad y rendimiento de la plataforma para ejecutar la transformación sin que ello
afecte al sistema de origen.
Migración del modelo de datos
Dependiendo de la plataforma y de los orígenes del sistema de origen, el modelo de datos de algunas o todas
las partes puede estar ya en formato de esquema de estrella o de copo de nieve. Si es así, se puede migrar
directamente a Azure Synapse Analytics tal como está. Este escenario es la migración más sencilla y con menos
riesgo que se puede lograr. Una migración tal cual también podría ser la primera fase de una migración más
compleja que incluye una transición a un modelo de datos subyacente nuevo como, por ejemplo, un almacén de
datos, tal como se describió anteriormente.
Cualquier conjunto de tablas y vistas relacionales se puede migrar a Azure Synapse Analytics. En el caso de las
cargas de trabajo de consulta analítica en un conjunto de datos grande, un modelo de datos de estrella o copo
de nieve generalmente ofrece el mejor rendimiento general. Si el modelo de datos de origen todavía no tiene
este formato, puede que valga la pena usar el proceso de migración para volver a diseñar el modelo.
Si el proyecto de migración incluye cualquier cambio en el modelo de datos, el procedimiento recomendado es
realizar estos cambios en el nuevo entorno de destino. Es decir, migre primero el modelo existente y, a
continuación, use la potencia y la flexibilidad de Azure Synapse Analytics para transformar los datos según el
nuevo modelo. Este enfoque minimiza el impacto en el sistema existente y usa el rendimiento y la escalabilidad
de Azure Synapse Analytics para hacer cambios de forma rápida y rentable.
Puede migrar el sistema existente como varias capas; por ejemplo, la capa de ingesta y almacenamiento
provisional de datos, la capa de almacenamiento de datos y la capa de informes o data marts. Cada capa se
compone de tablas y vistas relacionales. Aunque se pueden todas a Azure Synapse Analytics tal cual, puede que
sea más rentable y confiable usar algunas de las características y funcionalidades del ecosistema de Azure. Por
ejemplo:
Almacenamiento provisional e ingesta de datos: en lugar de usar tablas relacionales para la carga
rápida de datos en paralelo, puede usar Azure Blob Storage junto con PolyBase para parte del proceso de
ETL (extracción, transformación y carga de datos) o ELT (extracción, carga y transformación de datos).
Almacenamiento provisional e ingesta de datos: puede usar Azure Blob Storage junto con PolyBase
para la carga rápida de datos en paralelo para parte del proceso de ETL (extracción, transformación y
carga de datos) o ELT (extracción, carga y transformación de datos) en lugar de usar tablas relacionales.
Nivel de informes y data mar ts: las características de rendimiento de Azure Synapse Analytics
pueden eliminar la necesidad de crear físicamente instancias de las tablas agregadas para la elaboración
de informes o los data marts. Es posible implementarlos como vistas en el almacenamiento de datos
principal o a través de una capa de virtualización de datos de terceros. En el nivel básico, puede conseguir
el proceso para la migración de datos históricos y, posiblemente, también las actualizaciones
incrementales, como se indica en este diagrama:
Figura 1: Un almacenamiento de datos moderno.

Si puede utilizar estos métodos u otros similares, se reducirá el número de tablas que se van a migrar. Algunos
procesos se pueden simplificar o eliminar, lo que reduciría de nuevo la carga de trabajo de migración. La
aplicabilidad de estos enfoques depende del caso de uso individual. No obstante, el principio general es
considerar el uso de las características y las funciones del ecosistema de Azure, siempre que sea posible, para
reducir la carga de trabajo de migración y crear un entorno de destino rentable. Esto también se aplica a otras
funciones, como la copia de seguridad y restauración, y la administración y supervisión de flujos de trabajo.
Los productos y servicios disponibles de los asociados de Microsoft pueden ayudarle con las migraciones del
almacenamiento de datos y, en algunos casos, con la automatización de partes del proceso. Si el sistema
existente incorpora un producto ETL de terceros, es posible que ya sea compatible con Azure Synapse Analytics
como entorno de destino. Los flujos de trabajo ETL existentes se pueden redirigir al nuevo almacenamiento de
datos de destino.
Data marts: físicos o virtuales
Es un procedimiento habitual para las organizaciones con entornos de almacenamiento de datos más antiguos
crear data marts que proporcionen a sus departamentos o funciones empresariales un buen rendimiento de
informes y consultas de autoservicio ad hoc. Un data mart normalmente consta de un subconjunto del
almacenamiento de datos que contiene versiones agregadas de los datos originales. Su formato, normalmente
un modelo de datos dimensional, permite a los usuarios consultar fácilmente los datos y obtener tiempos de
respuesta rápidos de herramientas fáciles de usar como Tableau, MicroStrategy o Microsoft Power BI.
Un uso de los data marts es exponer los datos en un formato utilizable, incluso si el modelo de datos del
almacenamiento subyacente es algo distinto (como, por ejemplo, un almacén de datos). Este enfoque también
se conoce como un modelo de tres niveles.
Puede usar data marts independientes para unidades de negocio individuales dentro de una organización para
implementar regímenes de seguridad de datos sólidos. Por ejemplo, puede permitir el acceso de los usuarios a
los data marts específicos que les interesan y eliminar, ofuscar o anonimizar información confidencial.
Si estos data marts se implementan como tablas físicas, requieren recursos de almacenamiento adicionales para
almacenarlos y también procesamiento adicional para compilarlos y actualizarlos de forma periódica. Las tablas
físicas muestran que los datos del data mart solo están actualizados según la última operación de actualización,
por lo que puede que no sea adecuado para los paneles de datos altamente volátiles.
Con la llegada de arquitecturas de procesamiento paralelo masivo (MPP) escalables de bajo costo, es posible
que pueda proporcionar la funcionalidad de data mart sin tener que crear una instancia del data mart como un
conjunto de tablas físicas. Puede lograrlo con Azure Synapse Analytics mediante uno de estos métodos para
virtualizar los data marts:
Vistas SQL en el almacenamiento de datos principal.
Una capa de virtualización que usa características como vistas de Azure Synapse Analytics o productos de
virtualización de terceros como Denodo.
Este enfoque simplifica o elimina la necesidad de almacenamiento adicional y de procesamiento de
agregaciones. Reduce el número total de objetos de base de datos que se van a migrar.
Otra ventaja del enfoque de almacenamiento de datos es la capacidad para ejecutar operaciones como
combinaciones y agregaciones en grandes volúmenes de datos. Por ejemplo, implementar la lógica de
agregación y de combinación dentro de una capa de virtualización y mostrar los informes externos en una vista
virtualizada contribuye a generar el potente procesamiento necesario para crear estas vistas en el
almacenamiento de datos.
Los objetivos principales para elegir la implementación de data mart físico o virtual son:
Más agilidad. Un data mart virtual es más fácil de cambiar que las tablas físicas y los procesos ETL asociados.
Menor costo total de propiedad debido a que hay menos almacenes de datos y copias de datos en una
implementación virtualizada.
Eliminación de trabajos ETL para migrar y arquitectura de almacenamiento de datos simplificada en un
entorno virtualizado.
Rendimiento. Históricamente, los data marts físicos han sido más confiables. Los productos de virtualización
implementan ahora técnicas inteligentes de almacenamiento en caché para mitigar este riesgo.
También puede utilizar la virtualización de datos para mostrar los datos a los usuarios de forma coherente
durante un proyecto de migración.
Asignación de datos
Restricciones de integridad y claves en Azure Synapse
Las restricciones de clave principal y clave externa no se aplican actualmente en Azure Synapse Analytics. Sin
embargo, puede incluir la definición de PRIMARY KEY en la instrucción CREATE TABLE con la cláusula
NOT ENFORCED . Esto significa que los productos de informes de terceros pueden usar los metadatos de la tabla
para comprender las claves dentro del modelo de datos y, por tanto, generar las consultas más eficaces.
Compatibilidad de tipos de datos en Azure Synapse Analytics
Algunos sistemas de base de datos antiguos incluyen compatibilidad con tipos de datos que no se admiten
directamente en Azure Synapse Analytics. Puede controlar estos tipos de datos mediante el uso de un tipo de
datos compatible para almacenar los datos tal cual, o mediante la transformación de los datos en un tipo de
datos compatible.
A continuación se muestra una lista alfabética de los tipos de datos compatibles:
bigint
binary [ (n) ]
bit
char [ (n) ]
date
datetime
datetime2 [ (n) ]
datetimeoffset [ (n) ]
decimal [ (precision [, scale ]) ]
float [ (n) ]
int
money
nchar [ (n) ]
numeric [ (precision [ , scale ]) ]
nvarchar [ (n | MAX) ]
real [ (n) ]
smalldatetime
smallint
smallmoney
time [ (n) ]
tinyint
uniqueidentifier
varbinary [ (n | MAX) ]
varchar [ (n | MAX) ]
En la tabla siguiente se enumeran algunos tipos de datos comunes que no se admiten actualmente con el
enfoque recomendado para almacenarlos en Azure Synapse Analytics.
T IP O DE DATO S N O A DM IT IDO SO L UC IÓ N A LT ERN AT IVA
geometry varbinary
geography varbinary
hierarchyid nvarchar(4000)
T IP O DE DATO S N O A DM IT IDO SO L UC IÓ N A LT ERN AT IVA
image varbinary
text varchar
ntext nvarchar
sql_variant Dividir la columna en varias columnas fuertemente tipadas
table Convertir en tablas temporales
timestamp Reprocesar el código para usar datetime2 y la función

CURRENT_TIMESTAMP
xml varchar
Tipo definido por el usuario Volver a convertir el tipo de datos nativo cuando sea posible
Posibles problemas de datos

Según el entorno de origen, se pueden presentar algunos problemas al migrar los datos:
Puede haber diferencias sutiles en la forma en que se manejan los datos NULL en diferentes productos de
base de datos. Ejemplos de esto pueden ser las diferentes secuencias de intercalación y el control de las
cadenas con caracteres vacíos.
Los datos de DATE , TIME , INTERVAL , TIME ZONE y las funciones asociadas pueden variar considerablemente
de un producto a otro.
Pruébelos exhaustivamente para determinar si se han logrado los resultados deseados en el entorno de destino.
El ejercicio de migración también puede sacar a la luz errores o resultados incorrectos que actualmente forman
parte del sistema de origen existente, y el proceso de migración es una buena oportunidad para corregir las
anomalías.
Procedimientos recomendados para definir columnas en Azure Synapse Analytics
Es habitual que los sistemas antiguos contengan columnas con tipos de datos ineficaces. Por ejemplo, puede
que encuentre un campo definido como VARCHAR(20) cuando los valores de los datos reales resultarían más
adecuados para un campo CHAR(5) . O bien, puede que encuentre el uso de campos INTEGER cuando todos los
valores resultarían más adecuados para un campo SMALLINT . Unos tipos de datos insuficientes pueden dar
lugar a ineficacias en el rendimiento y el almacenamiento de las consultas, especialmente en tablas de hechos
de gran tamaño.
Es un buen momento para comprobar y racionalizar las definiciones de datos actuales durante un ejercicio de
migración. Puede automatizar estas tareas mediante el uso de consultas SQL para buscar el valor numérico
máximo o la longitud máxima de caracteres dentro de un campo de datos y comparar el resultado con el tipo de
datos.
En general, se recomienda minimizar la longitud total de fila definida para una tabla. Para obtener el mejor
rendimiento de las consultas, puede usar el tipo de datos más pequeño para cada columna, como se describió
anteriormente. El método recomendado para la carga de datos de tablas externas en Azure Synapse Analytics
consiste en usar la utilidad PolyBase que admite una longitud de fila máxima definida de 1 MB. PolyBase no
cargará tablas con filas de más de 1 MB y, en su lugar, se deberá usar la utilidad bcp .
Para lograr la ejecución de combinación más eficaz, defina las columnas en ambos lados de la combinación
como el mismo tipo de datos. Si la clave de una tabla de dimensiones se define como SMALLINT , las columnas
de referencia correspondientes de las tablas de hechos que usan esa dimensión también se deben definir como
SMALLINT .
Evite definir los campos de caracteres con un tamaño predeterminado de gran tamaño. Si el tamaño máximo de
los datos de un campo es 50 caracteres, use VARCHAR(50) . Del mismo modo, no se NVARCHAR si VARCHAR es
suficiente. NVARCHAR almacena datos Unicode para permitir diferentes juegos de caracteres de idiomas. VARCHAR
almacena datos ASCII y ocupa menos espacio.
Resumen de recomendaciones de diseño

No migre objetos o procesos innecesarios. Use características y funciones integradas en el entorno de Azure de
destino donde sea adecuado para reducir el número real de objetos y procesos que se van a migrar. Considere
la posibilidad de usar una capa de virtualización para reducir o eliminar la cantidad de data marts físicos que se
van a migrar y para insertar el procesamiento en el almacenamiento de datos.
Automatice siempre que sea posible y use los metadatos de los catálogos de sistema del sistema de origen para
generar DDL para el entorno de destino. Si es posible, también puede automatizar la generación de
documentos. Los asociados de Microsoft, como WhereScape, pueden proporcionar herramientas y servicios
especializados para ayudar con esta automatización.
Realice los cambios necesarios en el modelo de datos o las optimizaciones de asignación de datos en la
plataforma de destino. Estos cambios se pueden hacer de forma más eficaz en Azure Synapse Analytics. Este
enfoque reduce el impacto en los sistemas de origen que pueden estar ejecutándose casi a capacidad completa.
Opciones de rendimiento
En esta sección se describen las características disponibles en Azure Synapse Analytics que se pueden usar para
mejorar el rendimiento de un modelo de datos.
Enfoque general
Las características de la plataforma ejecutan el ajuste del rendimiento en la base de datos que se va a migrar. Los
índices, la creación de particiones de datos y la distribución de datos son ejemplos de este ajuste del
rendimiento. Durante la preparación de la migración, documentar el ajuste permite capturar y descubrir
optimizaciones que puede aplicar en el entorno de destino de Azure Synapse Analytics.
Por ejemplo, la presencia de un índice no único en una tabla puede indicar que los campos que se usan en el
índice se utilizan con frecuencia para filtrar, agrupar o combinar. Este seguirá siendo el caso en el entorno nuevo
y, por tanto, se debe tener en cuenta al elegir qué campos quiere indexar. Para obtener información más
detallada sobre los entornos de Teradata o Netezza, consulte los artículos de Azure Synapse Analytics sobre
soluciones y migración para Teradata y soluciones y migración para Netezza.
Use el rendimiento y la escalabilidad del entorno de Azure Synapse Analytics de destino para experimentar con
distintas opciones de rendimiento como la distribución de datos. Determine el mejor enfoque alternativo (por
ejemplo, el enfoque replicado en comparación con el distribuido por hash para una tabla de dimensiones de
gran tamaño). Esto no significa que los datos se deben volver a cargar desde orígenes externos. Es relativamente
rápido y fácil probar enfoques alternativos en Azure Synapse Analytics mediante la creación de copias de
cualquier tabla con distintas opciones de creación de particiones o distribución a través de una instrucción
CREATE TABLE AS SELECT .
Use las herramientas de supervisión que proporciona el entorno de Azure para comprender cómo se ejecutan
las consultas y dónde se pueden producir cuellos de botella. También hay herramientas disponibles de
asociados de Microsoft independientes que proporcionan paneles de supervisión y alertas y administración
automatizada de recursos.
Cada operación de SQL en Azure Synapse Analytics y en el recurso como, por ejemplo, la memoria o la CPU
usada por esa consulta, se registra en las tablas del sistema. Una serie de vistas de administración dinámica
simplifica el acceso a esta información.
En las secciones siguientes se explican las opciones clave de Azure SQL Data Warehouse para optimizar el
rendimiento de las consultas. Los entornos existentes contendrán información sobre la optimización potencial
en el entorno de destino.
Tablas temporales
Azure Synapse Analytics admite tablas temporales que solo son visibles para la sesión en la que se crearon.
Existen mientras dura una sesión de usuario y se eliminan automáticamente al final de la sesión.
Para crear una tabla temporal, anteponga el carácter de almohadilla ( # ) al nombre de la tabla, como prefijo.
Puede usar todas las opciones de indexación y distribución habituales con tablas temporales, como se describe
en la sección siguiente.
Las tablas temporales tienen algunas restricciones:
No se permite el cambio de nombre.
No se permite la visualización ni la creación de particiones.
No se permiten los cambios de permisos.
Las tablas temporales suelen usarse dentro del procesamiento ETL/ELT, donde los resultados intermedios
transitorios se usan como parte de un proceso de transformación.
Opciones de distribución de tabla
Azure Synapse Analytics es un sistema de bases de datos de procesamiento paralelo masivo (MPP) que logra
rendimiento y escalabilidad al ejecutarse en paralelo en varios nodos de procesamiento.
El escenario de procesamiento idóneo para ejecutar una consulta SQL en un entorno de varios nodos consiste
en equilibrar la carga de trabajo y dar a todos los nodos una cantidad de datos igual que procesar. Este enfoque
también le permite minimizar, o incluso eliminar, la cantidad de datos que deben moverse entre los nodos para
satisfacer la consulta.
Puede resultar difícil lograr el escenario ideal ya que, a menudo, en las consultas de análisis habituales hay
agregaciones y varias combinaciones entre varias tablas como, por ejemplo, entre tablas de hechos y de
dimensiones.
Una manera de influir en cómo se procesan las consultas es usar las opciones de distribución de Azure Synapse
Analytics para especificar dónde se almacenan las filas de datos individuales de cada tabla. Por ejemplo,
supongamos que dos tablas grandes están combinadas en la columna de datos, CUSTOMER_ID . Mediante la
distribución de las dos tablas a través de las columnas CUSTOMER_ID cada vez que se realiza la combinación,
puede asegurarse de que los datos de cada lado de la combinación se colocarán ya en el mismo nodo de
procesamiento. Este método elimina la necesidad de trasladar los datos entre los nodos. La especificación de
distribución para una tabla se define en la instrucción CREATE TABLE .
En las secciones siguientes se describen las opciones de distribución disponibles y las recomendaciones sobre
cuándo se deben usar. Es posible cambiar la distribución de una tabla después de la carga inicial, si es necesario;
para ello, vuelva a crear la tabla con la distribución nueva mediante la instrucción CREATE TABLE AS SELECT .
Round robin
Esta distribución de tabla del tipo round robin es la opción predeterminada y permite distribuir los datos de
manera uniforme entre los nodos del sistema. Este método es adecuado para la carga rápida de datos y para
aquellos datos con un volumen relativamente bajo y que no tienen un candidato obvio para la aplicación de un
algoritmo hash. Se suele usar para las tablas de almacenamiento provisional como parte de un proceso ETL o
ELT.
Con hash
El sistema asigna la fila a un cubo de hash, una tarea basada en un algoritmo hash se aplica a una clave definida
por un usuario como CUSTOMER_ID en el ejemplo anterior. A continuación, el cubo se asigna a un nodo específico
y todas las filas de datos que se distribuyen con hash en el mismo valor terminan en el mismo nodo de
procesamiento.
Este método es útil para las tablas grandes que con frecuencia se combinan o se agregan en una clave. Si es
posible, se debe aplicar un algoritmo hash a otras tablas grandes que se van a combinar en la misma clave. Si
hay varios candidatos para la clave hash, elija la combinación más frecuente.
La columna hash no debe contener valores NULL y, por lo general, no es una fecha porque muchas consultas se
filtran por fecha. Habitualmente, el hash es más eficaz si la clave para aplicar el algoritmo hash es un valor
entero en lugar de CHAR o VARCHAR . Evite también la elección de claves que tengan un intervalo muy sesgado
de valores, como un pequeño número de valores de clave que representan un porcentaje alto de filas de datos.
Replicado
Elegir el replicado como opción de distribución para una tabla hará que se replique una copia completa de esa
tabla en cada nodo de ejecución con fines de procesamiento de consultas.
Este enfoque es útil para las tablas relativamente pequeñas (por lo general, con menos de 2 GB comprimidos)
que son relativamente estáticas y se combinan con frecuencia con tablas grandes a través de una combinación
de igualdad. Estas tablas suelen ser tablas de dimensiones en un esquema de estrella.
Indización
Azure Synapse Analytics incluye opciones de indexación de datos en tablas de gran tamaño para reducir los
recursos y el tiempo necesarios para recuperar registros:
Índice de almacén de columnas agrupado
Índice agrupado
Índice no agrupado
Hay una opción no indexada, denominada HEAP , para las tablas que no se beneficiarían de ninguna de las
opciones de indexación. El uso de índices supone un equilibrio entre mejores tiempos de consulta y tiempos de
carga más largos y más uso de espacio de almacenamiento. Los índices suelen acelerar las operaciones de
SELECT , UPDATE , DELETE y MERGE en tablas grandes que afectan a un pequeño porcentaje de las filas de datos
y pueden minimizar los recorridos de tabla completos.
Los índices se crean automáticamente cuando se definen las restricciones UNIQUE o PRIMARY KEY en las
columnas.
Índice de almacén de columnas agrupado
El índice de almacén de columnas agrupado es la opción de indexación predeterminada de Azure Synapse
Analytics. Proporciona la mejor compresión y rendimiento de consultas para tablas grandes. En el caso de las
tablas más pequeñas (con menos de 60 millones de filas), estos índices no son eficaces y, por tanto, se debe usar
la opción HEAP . Del mismo modo, si los datos de una tabla son transitorios y forman parte de un proceso ETL o
ETL, una tabla de montón o una tabla temporal puede ser más eficaz.
Índice agrupado
Si hay un requisito para recuperar de manera periódica una fila única o un número pequeño de filas de una
tabla de gran tamaño en función de una condición de filtro segura, un índice agrupado puede ser más eficaz que
un índice de almacén de columnas agrupado. Solo se permite un índice agrupado por tabla.
Índice no agrupado
Los índices no agrupados son similares a los índices agrupados, ya que pueden acelerar la recuperación de filas
individuales o de un número pequeño de filas en función de una condición de filtro. Internamente, los índices no
agrupados se almacenan de forma independiente de los datos y se pueden definir varios índices no agrupados
en una tabla. Sin embargo, cada índice adicional necesitará más almacenamiento y reducirá el rendimiento de la
inserción o carga de datos.
Montón
Las tablas de montones no incurren en la sobrecarga asociada con la creación y el mantenimiento de índices en
el momento de la carga de datos. Pueden ayudar a cargar rápidamente datos transitorios durante los procesos,
incluidos los procesos de ELT. El almacenamiento en caché también puede ayudar cuando los datos se leen
inmediatamente después. Dado que los índices de almacén de columnas agrupados son ineficaces en tablas con
menos de 60 millones de filas, las tablas de montones también pueden ayudar a almacenar aquellas tablas con
un número menor de filas.
Creación de particiones de datos
En un almacén de datos empresarial, las tablas de hechos pueden contener muchos miles de millones de filas de
datos. La creación de particiones es una manera de optimizar el mantenimiento y las consultas de estas tablas al
dividirlas en partes independientes para reducir la cantidad de datos que se procesan al ejecutar consultas. La
especificación del particionamiento para una tabla se define en la instrucción CREATE TABLE .
En la creación de particiones, solo se puede usar un campo por tabla. Suele ser un campo de fecha porque
muchas consultas se filtran por una fecha o un intervalo de fechas. Puede cambiar la creación de particiones de
una tabla después de la carga inicial, si es necesario; para ello, vuelva a crear la tabla con la nueva distribución
mediante la instrucción CREATE TABLE AS SELECT .
Creación de par ticiones para la optimización de consultas: si las consultas realizadas en una tabla de
hechos de gran tamaño se filtran con frecuencia por una determinada columna de datos, la creación de
particiones en esa columna puede reducir considerablemente la cantidad de datos que se deben procesar para
realizar las consultas. Un ejemplo común es usar un campo de fecha para dividir la tabla en grupos más
pequeños. Cada grupo contiene datos de un solo día. Cuando una consulta contiene una cláusula WHERE que
filtra por la fecha, solo es necesario tener acceso a las particiones que coinciden con el filtro de fecha.
Creación de par ticiones para la optimización del mantenimiento de tablas: es habitual que los
entornos de almacenamiento de datos mantengan una ventana con desplazamiento de datos de hechos
detallados. Por ejemplo, las transacciones de ventas de hasta cinco años atrás. Al crear particiones en la fecha de
venta, la eliminación de los datos antiguos que van más allá del período acumulado es mucho más eficaz. Quitar
la partición más antigua es más rápido y usa menos recursos que las eliminación de todas las filas individuales.
Estadísticas
Cuando se envía una consulta a Azure Synapse Analytics, la procesa primero el optimizador de consultas. El
optimizador determina los mejores métodos internos para ejecutar la consulta de forma eficaz.
El optimizador compara los distintos planes de ejecución de consultas que están disponibles en función de un
algoritmo basado en el costo. La precisión de las estimaciones de costos depende de las estadísticas disponibles.
Por lo tanto, se recomienda asegurarse de que las estadísticas estén actualizadas.
En Azure Synapse Analytics, si está activada la opción AUTO_CREATE_STATISTICS , se desencadenará una
actualización automática de las estadísticas. Las estadísticas también se pueden crear o actualizar manualmente
mediante el comando CREATE STATISTICS .
Actualice las estadísticas cuando el contenido haya cambiado sustancialmente (por ejemplo, en una
actualización diaria). Esta actualización se puede incorporar en un proceso ETL.
Todas las tablas de la base de datos deben tener estadísticas recopiladas en al menos una columna. Garantiza
que la información básica, como el recuento de filas y el tamaño de la tabla, está disponible para el optimizador.
Otras columnas que deben tener estadísticas recopiladas son las columnas especificadas en el procesamiento
JOIN , DISTINCT , ORDER BY y GROUP BY .
Administración de cargas de trabajo

Azure Synapse Analytics incorpora características completas para administrar el uso de recursos en cargas de
trabajo mixtas. La creación de clases de recursos para diferentes tipos de cargas de trabajo, como consultas
frente a carga de datos, le ayuda a administrar la carga de trabajo. Permite establecer límites en el número de
consultas que se ejecutan simultáneamente y en los recursos de proceso que se asignan a cada consulta. Gracias
a esto, la memoria y la simultaneidad se compensan:
Las clases de recursos más pequeñas reducen la memoria máxima por cada consulta, pero aumentan la
simultaneidad.
Las clases de recursos más grandes aumentan la memoria máxima por cada consulta, pero reducen la
simultaneidad.
Recomendaciones de rendimiento
Use cualquier método de mejora del rendimiento, como los índices o la distribución de datos, para detectar
candidatos para medidas similares en el entorno de destino nuevo, pero realice una prueba comparativa para
confirmar que se necesitan en Azure Synapse Analytics. Cree pasos de COLLECT STATISTICS en los procesos
ETL/ELT para asegurarse de que las estadísticas están actualizadas o seleccione la creación automática de
estadísticas.
Comprenda las opciones de optimización disponibles en Azure Synapse Analytics y las características de
rendimiento de las utilidades asociadas, como PolyBase para la carga rápida de datos paralelos. Use estas
opciones para crear una implementación eficaz de un extremo a otro.
Use la flexibilidad, la escalabilidad y el rendimiento del entorno de Azure para implementar cualquier cambio en
el modelo de datos o las opciones de optimización del rendimiento en contexto. Este esfuerzo reducirá el
impacto en los sistemas de origen existentes.
Descripción de las vistas de administración dinámica disponibles en Azure Synapse Analytics. Estas vistas
proporcionan información sobre el uso de recursos en todo el sistema e información detallada sobre la
ejecución para consultas individuales.
Comprenda las clases de recursos de Azure y asígnelas como corresponda para garantizar la simultaneidad y la
administración eficaz de las cargas de trabajo mixtas.
Considere la posibilidad de usar una capa de virtualización como parte del entorno de Azure Synapse Analytics.
Puede proteger los cambios en la implementación de almacenamiento de usuarios empresariales y
herramientas de informes.
Investigue las herramientas de migración y los servicios proporcionados por proveedores de terceros, tales
como Qlik Replicate for Microsoft Migrations, Wherescape y Datometry. Estos servicios pueden automatizar
partes del proceso de migración y reducir el tiempo transcurrido y el riesgo que implica un proyecto de
migración.
Alta disponibilidad para Azure Synapse Analytics
Una de las principales ventajas de una infraestructura moderna basada en la nube, como Microsoft Azure, es
que las características de alta disponibilidad y recuperación ante desastres están integradas y son fáciles de
implementar y personalizar. Estos recursos suelen ser de menor costo que la funcionalidad equivalente en un
entorno local. El uso de estas funciones integradas también significa que no es necesario migrar los
mecanismos de copia de seguridad y de recuperación del almacenamiento de datos existente.
En las secciones siguientes se describen las características estándar de Azure Synapse Analytics que satisfacen
los requisitos de alta disponibilidad y recuperación ante desastres.
Alta disponibilidad
Azure Synapse Analytics usa instantáneas de base de datos para proporcionar una alta disponibilidad del
almacén. Una instantánea de almacenamiento de datos crea un punto de restauración que se puede usar para
copiar el almacenamiento de datos o recuperarlo a un estado anterior. Como Azure Synapse Analytics es un
sistema distribuido, una instantánea de almacenamiento de datos consta de muchos archivos que se almacenan
en Azure Storage. Las instantáneas capturan los cambios incrementales de los datos almacenados en el
almacenamiento de datos.
Azure Synapse Analytics toma automáticamente instantáneas a lo largo del día y crea puntos de restauración
que están disponibles durante siete días. Este período de retención no se puede modificar. Azure Synapse
Analytics admite un objetivo de punto de recuperación (RPO) de ocho horas. Puede restaurar el
almacenamiento de datos de la región primaria a partir de cualquiera de las instantáneas capturadas en los
últimos siete días.
El servicio también admite los puntos de restauración definidos por el usuario. El desencadenamiento manual
de las instantáneas sirve para crear puntos de restauración de un almacenamiento de datos antes y después de
realizar grandes modificaciones. Esta funcionalidad garantiza la coherencia lógica de los puntos de restauración.
La coherencia lógica proporciona protección de datos adicional ante posibles interrupciones de la carga de
trabajo o errores del usuario para una pronta recuperación.

Además de las instantáneas descritas anteriormente, Azure Synapse Analytics realiza de forma predeterminada
una copia de seguridad geográfica una vez al día en un centro de centros emparejado. El RPO para una
restauración geográfica es de 24 horas. Se realiza una copia de seguridad del grupo de SQL dedicado. Puede
restaurar la copia de seguridad geográfica en un servidor de cualquier otra región donde se admita Azure
Synapse Analytics. Una copia de seguridad geográfica garantiza que se pueda restaurar un almacenamiento de
datos en caso de que los puntos de restauración de la región primaria no estén disponibles.
Estrategia de cumplimiento o de gobernanza
Cuando se requiere gobierno o cumplimiento a lo largo de un trabajo de migración, es necesario ampliar el

ámbito para que tenga en cuenta estos requisitos. En la siguiente guía se amplía el ámbito de la guía de
migración de Azure para abarcar los distintos enfoques de los requisitos de cumplimiento o de gobernanza.

La mayor parte de las actividades de requisitos previos se ven afectadas cuando están implicados la gobernanza
y el cumplimiento. Pueden ser necesarios ajustes adicionales durante la evaluación, migración y optimización.

La configuración del entorno base de Azure puede cambiar de forma significativa al integrar los requisitos de
cumplimiento o gobernanza. Para entender cómo cambian los requisitos previos, es importante comprender su
naturaleza. Antes de comenzar cualquier migración que requiera gobernanza o cumplimiento, debe elegir e
implementar un enfoque en el entorno de nube. A continuación se muestran algunos enfoques de alto nivel que
se suelen observar durante las migraciones:
Enfoque de gobernanza común: Para la mayoría de las organizaciones, el modelo de gobierno de Cloud
Adoptation Framework es un enfoque suficiente. Consta de una implementación mínima viable del producto
(MVP), seguida de iteraciones concretas de madurez de gobierno para abordar los riesgos tangibles
identificados en el plan de adopción. Este enfoque proporciona las herramientas mínimas necesarias para
establecer una gobernanza coherente, de modo que el equipo pueda comprender las herramientas. Después se
expande en esas herramientas para abordar los problemas comunes de gobierno.
Blueprints de cumplimiento de Organización internacional de normalización (ISO) 27001: si una
organización tiene que cumplir los estándares de cumplimiento normativo de ISO, los ejemplos de planos
técnicos de Shared Services de ISO 27001 pueden servir como el MVP más eficaz. El plano técnico puede
producir mayores restricciones de gobierno antes en el proceso iterativo. El ejemplo de plano técnico para
cargas de trabajo de App Service Environment y SQL Database que se ajusta a la norma ISO 27001 amplía el
plano técnico de Servicios compartidos de ISO 27001 para asignar controles e implementar una arquitectura
común en un entorno de aplicaciones.
Zona de aterrizaje a escala empresarial de Cloud Adoption Framework : es posible que se requiera un
punto de partida de gobernanza más sólido. Si fuera así, considere la zona de aterrizaje a escala empresarial de
Cloud Adoption Framework. El método de la zona de aterrizaje de escala empresarial de Cloud Adoption
Framework se centra en los equipos de adopción que tienen un objetivo a medio plazo (un máximo de
24 meses) para hospedar más de 1000 recursos (aplicaciones, infraestructura o recursos de datos) en la nube.
La zona de aterrizaje de escala empresarial de Cloud Adoption Framework es la opción estándar si se realizan
grandes esfuerzos de adopción de la nube en escenarios de gobernanza complejos.
Opción de asociación para completar los requisitos previos
Ser vicios de Microsoft: Servicios de Microsoft proporciona ofertas de soluciones que se pueden alinear con
el modelo de gobernanza de Cloud Adoption Framework, los planos técnicos de cumplimiento o las opciones de
zona de aterrizaje a nivel empresarial de Cloud Adoption Framework. Esta opción le ayuda a asegurarse de que
está usando el modelo de gobierno o cumplimiento más adecuado. Use la solución Secure Cloud Insights para
establecer una imagen controlada por datos de una implementación de cliente en Azure. Esta solución también
valida la madurez de la implementación de Azure del cliente al tiempo que identifica la optimización de las
arquitecturas de implementación existentes. Secure Cloud Insights contribuye además a reducir el riesgo
relacionado con la seguridad y la disponibilidad de la gobernanza. En función de la información del cliente, debe
llevar a cabo los siguientes enfoques:
Cloud Foundation: Establezca los principales diseños, patrones y arquitectura de gobernanza de Azure del
cliente con la ayuda de la solución Hybrid Cloud Foundation. Asignar los requisitos del cliente a la
arquitectura de referencia más adecuada. Implemente un producto mínimo viable que conste de servicios
compartidos y cargas de trabajo de IaaS.
Modernización de la nube: Use la solución de modernización de la nube como un enfoque integral para
trasladar las aplicaciones, los datos y la infraestructura a una nube preparada para la empresa. También
puede llevar a cabo la optimización y modernización después de la implementación en la nube.
Innovación con la nube: Póngase en contacto con el cliente mediante la solución Centro de excelencia de
la nube (CCoE). Implementa un enfoque ágil para capturar los requisitos empresariales y reutilizar los
paquetes de implementación en alineación con las directivas de seguridad, cumplimiento y administración
de los servicios. También mantiene la alineación de la plataforma Azure con los procedimientos operativos.

Durante la evaluación, debe tomar decisiones adicionales para seguir el enfoque de gobernanza requerido. El
equipo de gobernanza de la nube proporciona a todos los miembros del equipo de adopción de la nube
instrucciones, pautas arquitectónicas o requisitos de gobernanza o cumplimiento antes de evaluar una carga de
trabajo.
Los requisitos de evaluación de gobernanza y cumplimiento son demasiado específicos del cliente para
proporcionar instrucciones generales sobre los pasos reales que se llevan a cabo durante la evaluación. El
proceso debe incluir tareas y tiempo para la alineación de los requisitos de cumplimiento y gobernanza.
Para comprender mejor la gobernanza, consulte la información general de Las materias de la gobernanza de la
nube. En esta sección de Cloud Adoption Framework también se incluyen plantillas para documentar las
directivas, las instrucciones y los requisitos de cada una de las secciones:
Materia de administración de costos
Materia de base de referencia de seguridad
Materia de coherencia de recursos
Materia de base de referencia de identidad
Materia de aceleración de la implementación
Para información sobre el desarrollo de instrucciones de gobernanza basadas en el modelo de gobernanza de
Cloud Adoption Framework, consulte Implementación de una estrategia de gobernanza de la nube.

Durante los procesos de optimización y promoción, el equipo de gobernanza de la nube debe emplear tiempo
en probar y validar si se respetan los estándares de gobernanza y cumplimiento. Además, este paso supone una
buena ocasión para que el equipo de gobernanza de la nube mantenga las plantillas que proporcionan una guía
adicional para proyectos futuros, en particular en la disciplina de aceleración de la implementación.
Durante este proceso, el plan del proyecto debe incluir asignaciones de tiempo para que el equipo de
gobernanza de la nube ejecute una revisión de cumplimiento para cada carga de trabajo planeada para la
promoción de producción.
Pasos siguientes
Vuelva a la lista de comprobación para volver a evaluar los requisitos de ámbito adicionales para el trabajo de
migración.
Antipatrones de migración en la nube
A menudo, los clientes experimentan antipatrones durante la fase de migración de la adopción de la nube. Las
siguientes medidas ayudan a evitar los antipatrones de migración:
Comprobación de que las barreras de seguridad y cumplimiento normativo están implementadas.
Descripción de las posibles dependencias de aplicaciones y servidores.
Elección de una arquitectura basada en una evaluación exhaustiva.
Antipatrón: migración, modernización o innovación sin barreras

Cuando los clientes implementan sus primeras cargas de trabajo en la nube, la consideran una plataforma para
probar soluciones innovadoras. Disfrutan de la flexibilidad que está disponible en la nube. No obstante, siempre
que estas cargas de trabajo sean productivas, necesiten almacenar los datos de la empresa o deban acceder a
los sistemas de la empresa, el progreso se ralentizará, ya que se deben satisfacer los estándares de
cumplimiento, normativa y seguridad.
Ejemplo: omitir de barreras de seguridad
Una empresa desea modernizar su tienda en línea para mejorar la experiencia del usuario. Para llevar a cabo la
modernización, se deben mover el sitio web de la tienda en línea y la base de datos de inventario subyacente a
Azure. Dado que existen dependencias entre la base de datos de inventario y el sistema SAP de la empresa,
estos sistemas deben comunicarse. Por lo tanto, la empresa debe crear una nube híbrida.
El equipo de la tienda en línea es innovador, por lo que inicia la modernización de la aplicación, pero no tiene en
cuenta los requisitos de seguridad debido a la conexión híbrida. Al probar la aplicación, detecta que el equipo de
seguridad de TI no permite la comunicación en los sistemas locales y de Azure, ya que no se cumplen los
requisitos de seguridad y cumplimiento.
Resultado preferido: establecer barreras de seguridad y cumplimiento
Antes de cambiar las cargas de trabajo a la nube, implemente las barreras de seguridad y cumplimiento. Estas
barreras garantizan que las cargas de trabajo siguen los requisitos de seguridad y cumplimiento. Los equipos de
gobernanza y seguridad de la nube ofrecen el barreras en una zona de aterrizaje de Azure. Compruebe las
barreras con TI, especialmente en el caso de las cargas de trabajo híbridas. Consulte Arquitectura de la zona de
aterrizaje a escala empresarial de Cloud Adoption Framework para obtener ayuda con la definición de barreras
que ayuden a los equipos de carga de trabajo a trabajar de manera rápida, constante, conforme y segura.
Antipatrón: migración, modernización o innovación sin evaluación

Cuando una empresa considera un proyecto de migración o de modernización, debe comprender las posibles
dependencias de aplicaciones y servidores para que el planeamiento resulte más preciso. En escenarios de
innovación de aplicaciones, una empresa experimenta más éxito si usa sesiones de diseño de arquitectura y
arquitecturas de referencia que con esfuerzos de ingeniería sin un objetivo.
Ejemplo: causar tiempo de inactividad mediante la migración sin un planeamiento minucioso
Un miembro del equipo planea migrar aplicaciones a la nube para reducir la huella de carbono de la empresa. El
plan de migración, que identifica el primer recurso que se va a migrar, se basa en las entradas de la base de
datos de administración de configuración (CMDB) y en una sola entrevista del propietario de la aplicación. Una
vez que el miembro del equipo migra uno de los servidores de base de datos de la aplicación, otros propietarios
de aplicaciones llaman a TI para reclamar el funcionamiento incorrecto de sus aplicaciones. Las dependencias
que se representan en la base de datos CMDB ya no son precisas, lo que provoca un tiempo de inactividad
inesperado en otras aplicaciones.
Resultado preferido: evaluar la infraestructura antes de la migración o la modernización
Para una migración a gran escala o un proyecto de modernización, realice una evaluación de la infraestructura
antes de iniciar la migración. Esta evaluación le ayuda a identificar las dependencias y los problemas de
compatibilidad. Consulte la Guía de migración de Azure para obtener la información detallada que Azure Cloud
Adoption Framework proporciona en los procedimientos recomendados para la migración.
En los proyectos de modernización, use evaluaciones de aplicaciones adicionales para identificar los
antipatrones de codificación, los problemas de compatibilidad y la deuda técnica. Para obtener más información
sobre los aspectos de modernización, consulte Información general sobre los ejemplos de migración de
aplicaciones para Azure.
En el caso de los proyectos de innovación, consulte Introducción a la guía de soluciones innovadoras de Azure
para obtener ayuda con la identificación de la manera correcta de planear y desarrollar una solución en la nube
innovadora.
En el caso de las cargas de trabajo críticas o que requieran cambios en la arquitectura, use el Marco de buena
arquitectura de Azure o una sesión de diseño de arquitectura (ADS) para ayudar a diseñar, crear e implementar
una arquitectura sólida y de alta calidad que crezca en una empresa. Use las pizarras de ADS para detectar,
prever y planear la solución.
Antipatrón: dictar una arquitectura

Una empresa podría llevar a cabo una estrategia de microservicios en primer lugar al desarrollar en la nube,
suponiendo que una arquitectura de microservicios siempre es mejor que una arquitectura monolítica
tradicional. Si la empresa no realiza una evaluación adecuada y la debida diligencia para su aplicación, se puede
producir un error en la estrategia. Otros enfoques de arquitectura podrían ser más adecuados para la aplicación.
Elegir o dictar una arquitectura de microservicios o una arquitectura para todas las situaciones suele dar lugar a
proyectos con errores.
Ejemplo: usar una arquitectura de microservicios para todas las aplicaciones
El director de información (CIO) de una empresa establece una directiva de uso de una arquitectura de
microservicios al compilar nuevas aplicaciones en la nube. Los desarrolladores de la empresa nunca han
trabajado con una arquitectura de microservicios. Deben desarrollar una aplicación web sencilla. Después de
trabajar en la aplicación durante unos meses, los desarrolladores se dan cuenta de que probablemente ya
habrían terminado el desarrollo si hubieran empezado con una arquitectura monolítica. La empresa no ha
logrado un tiempo de comercialización más rápido, entre otras ventajas.
Resultado preferido: decisiones de arquitectura base sobre evaluaciones
En lugar de concentrarse en un estilo de arquitectura específico, tome una decisión de arquitectura basada en
una evaluación y la debida diligencia del caso de uso o de una arquitectura. No limite las arquitecturas que se
pueden usar, ya que la libertad de elección es una de las principales ventajas de la nube. La elección de una
arquitectura solo porque está de moda es un antipatrón que se debe evitar. Para obtener más información,
consulte Guía de arquitectura de aplicaciones en Azure y Patrones de diseño en la nube.
Antipatrón: usar una suscripción única

A menudo, las empresas deciden usar una sola suscripción para hospedar todas sus cargas de trabajo.
Normalmente eligen esta opción al implementar migraciones rápidas que requieren velocidad ante todo. Esta
decisión conduce a panoramas con una gobernanza y un diseño deficientes. Estas empresas pueden encontrarse
rápidamente con límites de suscripción, lo que significa que deben volver a diseñar la arquitectura.
Ejemplo: realizar la migración en una suscripción
Un conglomerado decide segregar su división de hoteles a una empresa independiente. La división de hoteles
debe trasladar o migrar sus recursos de TI a un nuevo lugar. La nueva compañía hotelera elige un enfoque
primero en la nube y migra todos los recursos de TI a la nube. Debido a las restricciones de tiempo, la nueva
compañía lo migra todo a una suscripción y usa una red virtual enorme, donde hay pocas posibilidades de
separar las tareas y el modelo de seguridad correctamente. Tres meses después de completar la segregación, la
compañía hotelera determina que la seguridad y la gobernanza de sus recursos han empeorado y que está
enfrentando a límites de suscripción.
Resultado preferido: usar una estrategia de segmentación
Separe las distintas tareas y planee un entorno diferente antes de la migración a Azure. Puede llegar a los límites
de suscripción rápidamente al combinar diferentes fases en una suscripción. Establezca una estrategia de
segmentación para facilitar la implementación de la gobernanza y el cumplimiento.
Pasos siguientes
Introducción a la guía de migración de Azure
Lista de comprobación de procedimientos recomendados para la migración a la nube de Azure
Modelo de migración de Cloud Adoption
Framework
En esta sección de Cloud Adoption Framework se explican los principios que subyacen en el modelo de
migración. Siempre que sea posible, este contenido intenta mantener una posición neutral respecto a los
proveedores mientras le guía por los procesos y actividades que se pueden aplicar a cualquier migración a la
nube, independientemente del proveedor de nube elegido.
Descripción de las motivaciones de migración

La migración a la nube es un esfuerzo de administración de carteras, disfrazado de manera inteligente como
una implementación técnica. Durante el proceso de migración, decidirá mover algunos recursos, invertir en
otros y retirar recursos obsoletos o no utilizados. Algunos recursos se optimizarán, refactorizarán o se
reemplazarán por completo como parte de este proceso. Cada una de estas decisiones debe alinearse con las
motivaciones que subyacen a la migración a la nube. Las migraciones de más éxito también van un paso más
allá y alinean estas decisiones con los resultados empresariales deseados.
El modelo de migración de Cloud Adoption Framework depende de que la organización haya completado un
proceso de preparación empresarial para la adopción de la nube. Asegúrese de que ha revisado la metodología
de planeamiento y de preparación en Cloud Adoption Framework para determinar las motivaciones
empresariales u otra justificación para una migración a la nube, así como cualquier planeamiento organizativo o
aprendizaje necesario antes de ejecutar un proceso de migración a escala.
NOTE
Mientras que el planeamiento empresarial es importante, una mentalidad de crecimiento es igualmente importante.
Paralelamente a los esfuerzos de planeamiento empresarial más amplios del equipo de estrategia en la nube, se sugiere
que el equipo de adopción de la nube comience a migrar una primera carga de trabajo como precursora de los esfuerzos
de migración a mayor escala. Esta migración inicial permitirá que el equipo adquiera experiencia práctica con las cuestiones
comerciales y técnicas que implica una migración.
Previsión de un estado final

Es importante tener una visión aproximada del estado final antes de iniciar los trabajos de migración. En el
diagrama siguiente se muestra un punto inicial local de la infraestructura, las aplicaciones y los datos, que define
su patrimonio digital. Durante el proceso de migración, esos recursos realizan la transición mediante una de las
cinco estrategias de migración descritas en Las cinco "R" de la racionalización.
La migración y modernización de las cargas de trabajo van desde simples migraciones de rehospedaje
(llamadas también migraciones lift and shift) mediante las funcionalidades de infraestructura como servicio
(IaaS) que no requieren cambios de código y aplicaciones, pasando por la refactorización con cambios mínimos,
hasta el rediseño para modificar y ampliar la funcionalidad de código y aplicaciones para aprovechar las
tecnologías de la nube.
Las estrategias nativas de la nube y las estrategias de plataforma como servicio (PaaS) recompilan cargas de
trabajo locales mediante ofertas de la plataforma Azure y servicios administrados. Las cargas de trabajo que
tienen ofertas equivalentes de software como servicio (SaaS) totalmente administrado basadas en la nube
pueden reemplazarse totalmente por estos servicios como parte del proceso de migración.
NOTE
Durante la versión preliminar pública de Cloud Adoption Framework, en esta sección de la plataforma se hace hincapié en
una estrategia de migración de rehospedaje. Aunque las soluciones PaaS y SaaS se tratan como alternativas cuando es
apropiado, la migración de cargas de trabajo basadas en máquinas virtuales que utilizan funcionalidades IaaS es el
objetivo principal.
Otras secciones e iteraciones futuras de este contenido se ampliarán en otros enfoques. Para obtener una descripción de
alto nivel sobre la ampliación del ámbito de la migración para incluir estrategias de migración más complicadas, consulte el
artículo sobre cómo equilibrar la cartera.
Migración incremental
El modelo de migración de Cloud Adoption Framework se basa en un proceso de transformación incremental
en la nube. Asume que la organización comenzará con un esfuerzo inicial, de ámbito limitado, de migración a la
nube, al que nos referimos comúnmente como la primera carga de trabajo. Este esfuerzo se ampliará de forma
iterativa para incluir más cargas de trabajo a medida que los equipos de operaciones perfeccionen y mejoren
sus procesos de migración.
Las herramientas de migración en nube como Azure Site Recovery pueden migrar centros de datos completos
que consisten en decenas de miles de máquinas virtuales. Sin embargo, la empresa y las operaciones de TI
existentes rara vez pueden controlar un ritmo de cambio tan alto. Como tales, muchas organizaciones dividen el
esfuerzo de migración en varias iteraciones y, para ello, mueven una carga de trabajo (o una colección de cargas
de trabajo) por iteración.
Los principios que subyacen en este modelo incremental se basan en la ejecución de procesos y requisitos
previos a los que se hace referencia en la siguiente infografía.
La aplicación coherente de estos principios representa un objetivo final para sus procesos de migración a la
nube y no debe considerarse como un punto inicial necesario. A medida que maduren los esfuerzos de
migración, consulte la guía en esta sección para ayudar a definir el mejor proceso para apoyar sus necesidades
organizacionales.
Pasos siguientes
Para aprender sobre este modelo, investigue los requisitos previos para la migración.
Requisitos previos para la migración
Requisitos previos para la migración
Antes de comenzar cualquier migración, es preciso preparar el entorno de destino de la migración para los
cambios que se van a producir. En este caso, el entorno hace referencia a la base técnica en la nube. El entorno
también significa el entorno empresarial y la mentalidad que promueven la migración. Del mismo modo, el
entorno incluye la referencia cultural de los equipos que llevan a cabo los cambios y de los que se ven afectados
por estos. La falta de preparación para estos cambios es el motivo más habitual para los errores en las
migraciones. Esta serie de artículos le guiará a través de los requisitos previos recomendados para preparar el
entorno.
Objetivo
Garantice la preparación empresarial, cultural y técnica antes de comenzar un plan de migración iterativo.
Revisión de los impulsores de negocios

Antes de comenzar cualquier migración a la nube, revise la metodología de Planeamiento y de Preparación de
Cloud Adoption Framework para asegurarse de que la organización está preparada para los procesos de
adopción de la nube y de migración. En concreto, revise los requisitos empresariales y los resultados esperados
que impulsan la migración:
¿Por qué queremos realizar el traslado a la nube?
Los requisitos previos están completos cuando se cumple lo siguiente:
Preparación empresarial. El equipo de estrategia en la nube ha definido y clasificado por orden de
prioridad un trabajo pendiente de migración de alto nivel que representa la parte del patrimonio digital que
se va a migrar en las próximas dos o tres etapas. Los equipos de estrategia en la nube y de adopción de esta
han acordado una estrategia inicial para administrar los cambios.
Preparación cultural. Se han acordado las funciones, responsabilidades y expectativas del equipo de
adopción de la nube, el equipo de estrategia en la nube y los usuarios afectados en relación con las cargas de
trabajo que se van a migrar en las próximas dos o tres etapas.
Preparación técnica. La zona de aterrizaje (o espacio asignado de hospedaje en la nube) que recibirá los
recursos migrados cumple unos requisitos mínimos para hospedar la primera carga de trabajo migrada.
Cau t i on
La preparación es clave para el éxito de una migración. Sin embargo, demasiada preparación puede conducir a
una parálisis del análisis en la que el exceso de tiempo invertido en la planeación puede retrasar seriamente un
esfuerzo de migración. Los procesos y requisitos previos que se definen en esta sección están diseñados para
ayudarle a tomar decisiones, pero no les permita que supongan un impedimento para lograr un progreso
significativo.
Elija una carga de trabajo relativamente sencilla para la migración inicial. Use los procesos descritos en esta
sección cuando planee e implemente esta primera migración. Este primer esfuerzo de migración permitirá
mostrar rápidamente los principios de la nube a su equipo y obligarlos a obtener información acerca del
funcionamiento de la nube. A medida que el equipo gana en experiencia, integre los elementos aprendidos en
migraciones de mayor calado y complejidad.
Responsabilidad durante la fase de los requisitos previos
Dos equipos son responsables de la preparación al completar los requisitos previos:
Equipo de estrategia en la nube: Este equipo es responsable de identificar y clasificar por orden de
prioridad la dos o tres primeras cargas de trabajo que actuarán como candidatas a la migración.
Equipo de adopción de la nube: Este equipo es responsable de validar la preparación del entorno técnico
y la viabilidad de migrar las cargas de trabajo propuestas.
Se debe identificar un único miembro de cada equipo como responsable de cada una de las tres definiciones de
preparación que se indicaban en la sección anterior.
Responsabilidades durante la fase de los requisitos previos

Además de la responsabilidad de alto nivel, hay acciones de las que un individuo o grupo se deben hacer
responsables directamente. Estas son algunas de las responsabilidades que afectan a estas actividades:
Prioridades empresariales. Tome decisiones empresariales en relación a las cargas de trabajo que se
desean migrar y a las restricciones temporales generales. Para más información, consulte Cloud migration
business motivations (Motivaciones empresariales para la migración a la nube).
Preparación para la administración de cambios. Establezca y comunique el plan para realizar el
seguimiento de los cambios técnicos durante la migración.
Alineación del usuario empresarial. Establezca un plan de preparación de la comunidad de usuarios
empresariales para la ejecución de la migración.
Inventario y análisis del patrimonio digital. Ejecución de las herramientas necesarias para catalogar y
analizar el patrimonio digital. Consulte el análisis de Cloud Adoption Framework del patrimonio digital para
más información.
Preparación de la nube. Evalúe el entorno de implementación de destino para asegurarse de que cumple
con los requisitos de las primeras cargas de trabajo candidatas a la migración. Consulte la Guía de instalación
de Azure para más información.
Los artículos restantes de esta serie ayudan con la ejecución de cada uno de los pasos.
Pasos siguientes
Con un reconocimiento general de los requisitos previos, estará listo para adoptar las primeras decisiones
iniciales de la migración sobre los requisitos previos.
Decisiones iniciales de la migración
Decisiones que afectan a la migración
Durante la migración, hay varios factores que afectan a las decisiones y las actividades de ejecución. En este
artículo se explica el tema central de esas decisiones y se exploran algunas de las cuestiones que conducen los
análisis de los principios de la migración en esta sección de la guía del marco de adopción de la nube.
El objetivo o meta de cualquier esfuerzo de adopción puede tener un efecto importante sobre el enfoque que se
ha sugerido ejecutar.
Migración. Los impulsores de negocio urgentes, la velocidad de adopción o el ahorro de costos son
ejemplos de resultados operativos. Estos resultados son fundamentales para los esfuerzos que generan valor
empresarial por los cambios transitivos en los modelos de TI o de operaciones. La metodología de migración
de Cloud Adoption Framework se centra en gran medida en los resultados empresariales basados en la
migración.
Innovación de aplicaciones. La mejora de la experiencia del cliente y el crecimiento de la cuota de
mercado son ejemplos de resultados incrementales. Los resultados proceden de una colección de cambios
incrementales centrados en las necesidades y los deseos de los clientes actuales.
Innovación controlada por datos . Los nuevos productos o servicios, especialmente los que se basan en la
eficacia de los datos, son ejemplos de resultados perjudiciales. Estos resultados son el producto de la
experimentación y las predicciones que usan datos para alterar el status quo en el mercado.
Ninguna empresa perseguirá solamente uno de estos resultados. Sin operaciones, no hay clientes y viceversa.
La adopción de la nube no es diferente. Normalmente, las empresas trabajan para lograr cada uno de estos
resultados, pero tratar de centrarse en todos ellos a la vez puede hacer que se abarque demasiado y que se
ralentice el progreso del trabajo que podría beneficiar más a las necesidades de su empresa.
Este requisito previo no es una exigencia para que elija uno de estos tres objetivos, sino que puede ayudar a los
equipos de estrategia y adopción de la nube a establecer un conjunto de prioridades operativas que guíen la
ejecución durante el próximo período de tres a seis meses. Estas prioridades se establecen mediante la
clasificación de cada una de las tres opciones detalladas de más importante a menos importante, ya que se
relacionan con los esfuerzos con los que puede contribuir este equipo en el próximo par de trimestres.
Actuación sobre los resultados de la migración
Si los resultados operativos obtienen la clasificación más alta de la lista, esta sección de Cloud Adoption
Framework se adaptará bien al equipo. En esta sección, se supone que debe priorizar la velocidad y el ahorro en
los costos como indicadores clave de rendimiento (KPI) principales, en cuyo caso un modelo de migración a la
adopción se alineará bien con los resultados. Un modelo centrado en la migración se basa en gran medida en la
migración mediante lift-and-shift de los recursos de infraestructura como servicio (IaaS) para consumir un
centro de datos y producir ahorros en los costos. En este modelo, puede producirse alguna modernización, pero
es un enfoque secundario hasta que se realice la misión principal de la migración.
Actuación sobre las innovaciones de las aplicaciones
Si la cuota de mercado y la experiencia del cliente son los impulsores principales, es posible que esta no sea la
mejor sección de Cloud Adoption Framework para guiar los esfuerzos de los equipos. La innovación de las
aplicaciones requiere un plan que se centre en la modernización y la transición de las cargas de trabajo, sin
importar la infraestructura subyacente. En tal caso, las instrucciones de esta sección pueden ser informativas,
pero es posible que no sea el mejor enfoque para guiar las decisiones básicas.
Actuación sobre las innovaciones de los datos
Si los datos, la experimentación, la investigación y el desarrollo (I+D) o los nuevos productos son su prioridad
durante los próximos seis meses, es posible que esta no sea la mejor sección de Cloud Adoption Framework
para guiar los esfuerzos de los equipos. Cualquier esfuerzo de innovación de los datos podría beneficiarse de las
instrucciones relativas a la migración de los datos de origen existentes. Sin embargo, el enfoque más amplio de
ese esfuerzo estaría sobre la entrada y la integración de orígenes de datos adicionales. La ampliación de estas
instrucciones con predicciones y nuevas experiencias es mucho más importante que la migración de recursos
de IaaS.
Esfuerzo
El esfuerzo de migración puede variar considerablemente en función del tamaño y las complejidades de las
cargas de trabajo implicadas. Una migración de cargas de trabajo más pequeña en la que solo intervengan unos
cientos de máquinas virtuales (VM) es un proceso táctico, que puede implementarse mediante herramientas
automatizadas como Azure Migrate. Por el contrario, una gran migración empresarial de decenas de miles de
cargas de trabajo requiere un proceso muy estratégico y puede implicar una extensa refactorización,
recompilación y reemplazo de las aplicaciones existentes que integran las funcionalidades de plataforma como
servicio (PaaS) y software como servicio (SaaS). Es fundamental identificar y equilibrar el ámbito de las
migraciones planeadas.
Antes de tomar decisiones que pudieran tener un efecto a largo plazo sobre el programa de migración actual, es
fundamental crear un consenso sobre las siguientes decisiones.
Tipo de esfuerzo
En cualquier migración de escala considerable (más de 250 máquinas virtuales), los recursos se migran
mediante una variedad de opciones de transición, que se describen en las cinco R de la racionalización:
rehospedaje, refactorización, rediseño, recompilación y reemplazo.
Algunas cargas de trabajo se modernizan mediante un proceso de recompilación o rediseño, lo que crea
aplicaciones más modernas con nuevas características y funcionalidades técnicas. Otros recursos pasan por un
proceso de refactorización, por ejemplo, se mueven a contenedores u otros enfoques más modernos de
funcionamiento y hospedaje que no afectan necesariamente al código base de las soluciones. Normalmente, las
máquinas virtuales y otros recursos que están más establecidos pasan por un proceso de rehospedaje, con una
transición de esos recursos del centro de datos a la nube. Es posible que algunas cargas de trabajo se puedan
migrar a la nube, pero que en cambio se deban reemplazar mediante servicios en la nube basados en servicios
(basados en SaaS) que satisfagan la misma necesidad empresarial; por ejemplo, usar Microsoft 365 como
alternativa a la migración de instancias de Exchange Server.
En la mayoría de los escenarios, algunos eventos empresariales crean una función impulsora que hace que un
alto porcentaje de recursos se migren temporalmente mediante el proceso de rehospedaje, seguido de una
transición secundaria más significativa por medio de una de las otras estrategias de migración después de que
están en la nube. Este proceso se conoce normalmente como transición a la nube.
Durante el proceso de racionalización del patrimonio digital, estos tipos de decisiones se aplican a cada recurso
que se va a migrar. Sin embargo, el requisito previo necesario en este momento es realizar una suposición de
línea base. De las cinco estrategias de migración, ¿cuál concuerda más con los objetivos empresariales o los
resultados empresariales que impulsan este esfuerzo de migración? Esta decisión sirve como supuesto guía en
todo el esfuerzo de migración.
Escala del esfuerzo
La escala de la migración es la siguiente decisión importante que constituye un requisito previo. Los procesos
necesarios para migrar 1000 recursos serán diferentes de los procesos necesarios para trasladar 10 000. Antes
de comenzar cualquier esfuerzo de migración, es importante responder a las siguientes preguntas:
¿Cuántos recursos admiten las cargas de trabajo de migración hoy en día? Los recursos incluirán
estructuras de datos, aplicaciones, VM y los dispositivos de TI necesarios. Elija una carga de trabajo
relativamente pequeña para su primer candidato a la migración.
De esos recursos, ¿cuántos están planeados para la migración? Es habitual que durante un proceso
de migración se finalicen los recursos, debido a la falta de dependencia sostenida del usuario final.
¿Cuáles son las estimaciones descendentes de la escala de recursos que se pueden migrar? En el
caso de las cargas de trabajo que se incluyen en la migración, calcule el número de recursos auxiliares, como
aplicaciones, máquinas virtuales, orígenes de datos y dispositivos de TI. Consulte la sección sobre el
patrimonio digital de Cloud Adoption Framework para obtener instrucciones sobre cómo identificar recursos
importantes.
Tiempo del esfuerzo
A menudo, las migraciones están impulsadas por un evento empresarial apremiante que depende del tiempo.
Por ejemplo, un impulsor común es la terminación o la renovación de un contrato de hospedaje de terceros.
Aunque hay muchos posibles eventos empresariales que requieren una migración, todos comparten un factor
común: una fecha de finalización. Es importante comprender la temporalidad de cualquier evento empresarial
inminente, de forma que sea posible planear y validar correctamente las actividades y la velocidad.
Resumen
Antes de continuar, documente los siguientes supuestos y compártalos con los equipos de estrategia en la nube
y adopción de la nube:
Roles, documentados y definidos para los procesos de migración Evaluación, Migración, Optimización y
Protección y administración.
Definición de hecho, documentada y perfeccionada por separado para los procesos de migración.
Tipo de esfuerzo
Escala del esfuerzo
Tiempo del esfuerzo
Pasos siguientes
Una vez entendido el proceso en el equipo, es el momento de revisar los requisitos previos técnicos. La lista de
comprobación de planeamiento del entorno de migración ayuda a garantizar que los cimientos técnicos están
listos para la migración.
Una vez que el proceso se entienda en el equipo, es hora de revisar los requisitos previos técnicos; la lista de
comprobación del planeamiento de la migración ayudará a garantizar que los cimientos técnicos están listos
para la migración.
Revisión de la lista de comprobación del planeamiento de la migración
Lista de comprobación del planeamiento del
entorno de migración: Validación de la preparación
del entorno antes de la migración
Como paso inicial en el proceso de migración, debe crear el entorno adecuado en la nube para recibir, hospedar
y respaldar la migración de los recursos. En este artículo se proporciona una lista de aspectos que se deben
validar en el entorno actual antes de la migración.
La siguiente lista de comprobación se alinea con las instrucciones de la metodología de preparación del marco
de adopción de la nube. Revise esa sección para obtener instrucciones sobre la ejecución de cualquiera de las
siguientes opciones.
Supuesto del tipo de esfuerzo

En este artículo y lista de comprobación se da por hecho un enfoque de rehospedaje o de transición a la nube
en la migración a la nube.
Alineación de la gobernanza
La primera decisión, y la más importante, con respecto a cualquier entorno preparado para la migración es la
elección de la alineación de la gobernanza. ¿Se ha logrado un consenso con respecto a la alineación de la
gobernanza con la base de la migración? Como mínimo, el equipo de adopción de la nube debe comprender si
esta migración se va a realizar en un único entorno con gobernanza limitada, en una factoría con un entorno
completamente regulado o en alguna opción intermedia. Para más información sobre la alineación de
gobernanza, consulte la metodología de gobernanza.
Alineación de la administración de operaciones

Antes de migrar los recursos a la nube, es importante comprender los requisitos y restricciones relacionados
con la administración de operaciones. Como mínimo, el entorno de migración debe incluir todas las
implementaciones necesarias para cumplir la línea de base de operaciones. Para más información sobre la
alineación de operaciones, consulte la metodología de administración.
Implementación de la preparación de la nube

Tanto si elige alinearse con una estrategia de control de la nube más amplia como si no para la migración inicial,
deberá asegurarse de que el entorno de implementación de la nube esté configurado para admitir las cargas de
trabajo.
Si desde el principio tiene previsto alinear la migración con una estrategia de gobernanza de la nube, deberá
aplicar Las cinco disciplinas de la gobernanza de la nube para ayudar a tomar decisiones sobre las directivas,
cadenas de herramientas y mecanismos de cumplimiento que alinearán el entorno de nube con los requisitos
corporativos generales. Consulte las guías de diseño de gobernanza accionables del marco de adopción de la
nube para ver ejemplos de cómo implementar este modelo con los servicios de Azure.
Si las migraciones iniciales no están estrechamente alineadas con una estrategia de gobernanza de la nube más
amplia, aún será necesario gestionar los problemas generales de planeamiento de la organización, acceso e
infraestructura. Consulte la guía de configuración de Azure para obtener ayuda con estas decisiones de
preparación de la nube.
Cau t i on
Se recomienda encarecidamente desarrollar una estrategia de gobernanza para todos aquellos aspectos que
vayan más allá de la migración inicial de la carga de trabajo.
Con independencia del nivel de alineación de la gobernanza, deberá tomar decisiones relacionadas con los
temas siguientes.
En función de la decisión sobre la alineación de la gobernanza, se debe establecer un enfoque para la
organización y la implementación de recursos antes de la migración.
Nomenclatura
Antes de la migración, se debe establecer un enfoque coherente para asignar nombres a los recursos, junto con
esquemas de nomenclatura coherentes.
Regulación de recursos
Antes de la migración, se debe tomar una decisión con respecto a las herramientas para regular los recursos.
Aunque no es necesario que las herramientas estén totalmente implementadas, se deben seleccionar y probar
en una dirección. Antes de la migración, el equipo de gobernanza de la nube debe definir y exigir la
implementación de un producto mínimo viable (MVP) para las herramientas de gobernanza.
Red
Las cargas de trabajo basadas en la nube requerirán el aprovisionamiento de redes virtuales para admitir el
acceso administrativo y del usuario final. En función de las decisiones sobre la organización y la gobernanza de
los recursos, debe seleccionar un enfoque de red para alinearlo con los requisitos de seguridad de TI. Además,
las decisiones de red deben estar en consonancia con cualquier restricción de red híbrida necesaria para operar
las cargas de trabajo en el trabajo pendiente de migración y admitir cualquier acceso a los recursos hospedados
de forma local.
Identidad
Los servicios de identidad basados en la nube son un requisito previo para ofrecer administración de
identidades y acceso (IAM) para los recursos en la nube. Alinee la estrategia de administración de identidades
con los planes de adopción de la nube antes de continuar. Por ejemplo, al migrar recursos locales existentes,
considere la posibilidad de admitir un enfoque de identidad híbrida mediante la sincronización de directorios
para permitir un conjunto coherente de credenciales de usuario en el entorno local y en la nube durante y
después de la migración.
Pasos siguientes
Si el entorno cumple los requisitos mínimos, se puede considerar aprobado para la preparación de la migración.
La administración de la complejidad cultural y de los cambios ayuda a alinear roles y responsabilidades para
garantizar las expectativas adecuadas durante la ejecución del plan.
Administración de la complejidad cultural y de los cambios
Preparación para la complejidad cultural: alineación
de roles y responsabilidades
Es importante comprender la referencia cultural necesaria para poner en funcionamiento los centros de
recursos existentes para que cualquier migración se realice correctamente. En algunas organizaciones, la
administración de los centros de datos está incluida en los equipos de operaciones de TI centralizados. En estos
equipos centralizados, los roles y las responsabilidades tienden a estar bien definidos y a que todo el equipo los
comprenda bien. En el caso de las empresas más grandes, especialmente las que están determinadas por los
requisitos de cumplimiento normativo de terceros, la referencia cultural tiende a ser más matizada y compleja.
La complejidad cultural puede llevar a obstáculos que son difíciles de comprender y que tardan mucho tiempo
en superarse.
En cualquier escenario, es recomendable invertir en la documentación de los roles y las responsabilidades que
se necesitan para completar una migración. En este artículo se describen algunos de los roles y las
responsabilidades que se han visto en una migración de centros de datos, para servir como plantilla para la
documentación que puede brindar claridad a lo largo de la ejecución.
Funciones empresariales
En cualquier migración, hay algunas funciones clave que las ejecuta mejor en la empresa, siempre que sea
posible. A menudo, el departamento de TI es capaz de completar las tareas siguientes. Sin embargo, la
participación de miembros de la empresa podría ayudar a disminuir las barreras más adelante en el proceso de
adopción. También garantiza la inversión mutua de las partes interesadas clave durante todo el proceso de
migración.
P RO C ESO A C T IVIDA D DESC RIP C IÓ N
Evaluar Objetivos empresariales Definir los resultados empresariales

deseados del esfuerzo de migración.
Evaluar Prioridades Garantizar la alineación con las

cambiantes necesidades del negocio y
las condiciones del mercado.
Evaluar Justificación Validar las suposiciones que impulsan

las justificaciones comerciales que
están en constante evolución.
Evaluar Riesgo Ayudar al equipo de adopción de la

nube a comprender el impacto de los
riesgos empresariales tangibles.
Evaluar Aprobación Revisar y aprobar el impacto en la

empresa de los cambios de
arquitectura propuestos.
P RO C ESO A C T IVIDA D DESC RIP C IÓ N
Optimización Plan de cambio Definir un plan para el consumo de

cambios dentro de la empresa,
incluidos los períodos de baja actividad
y los bloqueos de cambio.
Optimización Prueba Alinear a los usuarios avanzados

capaces de validar el rendimiento y la
funcionalidad.
Proteger y administrar Impacto de la interrupción Ayudar al equipo de adopción de la

nube a cuantificar el impacto de una
interrupción del proceso de negocio.
Proteger y administrar Validación del acuerdo de nivel de Ayudar al equipo de adopción de la

servicio nube a definir contratos de nivel de
servicio y las tolerancias aceptables
para interrupciones del negocio.
En última instancia, el equipo de adopción de la nube es responsable de cada una de estas actividades. Sin
embargo, el establecimiento de responsabilidades y una cadencia periódica con el negocio para completar estas
actividades a un ritmo establecido puede mejorar la alineación y la cohesión de las partes interesadas con el
negocio.
Roles y responsabilidades comunes

Cada proceso dentro de la descripción de los principios de migración de la Plataforma de adopción de la nube
incluye un artículo de proceso en el que se describen actividades específicas para alinear los roles y las
responsabilidades. Para mayor claridad durante la ejecución, se debe asignar una sola entidad responsable para
cada actividad, junto con cualquier otra parte responsable necesaria para admitir dichas actividades. Sin
embargo, la lista siguiente contiene una serie de roles y responsabilidades comunes que tienen un mayor grado
de impacto en la ejecución de la migración. Estos roles se deben identificar en una fase temprana del esfuerzo
de migración.
NOTE
En la tabla siguiente, una entidad responsable debe iniciar la alineación de los roles. Esa columna se debe personalizar para
ajustarse a los procesos existentes para realizar una ejecución eficaz. Idealmente, se debe asignar a una sola persona como
la entidad responsable.
P RO C ESO A C T IVIDA D DESC RIP C IÓ N EN T IDA D RESP O N SA B L E
Requisito previo Patrimonio digital Alinear el inventario Equipo de estrategia de la

existente con los supuestos nube
básicos, en función de los
Requisito previo Trabajo pendiente de Clasificar por orden de Equipo de estrategia de la

migración prioridad la secuencia de nube
cargas de trabajo que
quiere migrar.
P RO C ESO A C T IVIDA D DESC RIP C IÓ N EN T IDA D RESP O N SA B L E
Evaluar Architecture Desafiar las suposiciones Equipo de adopción de la

iniciales para definir la nube
arquitectura de destino en
función de las métricas de
uso.
Evaluar Aprobación Aprobar la arquitectura Equipo de estrategia de la

propuesta. nube
Migrar Acceso de replicación Acceder a los hosts locales Equipo de adopción de la

existentes y a los recursos nube
para establecer procesos de
replicación.
Optimización Ready Comprobar que el sistema Equipo de adopción de la

cumple los requisitos de nube
rendimiento y costo antes
de la promoción.
Optimización Promoción Permisos para promover Equipo de adopción de la

una carga de trabajo a nube
producción y redirigir el
tráfico de producción.
Proteger y administrar Transición de operaciones Documentar los sistemas de Equipo de adopción de la

producción antes de las nube
operaciones de producción.
Cau t i on
Para estas actividades, los permisos y las autorizaciones influyen en gran medida en la parte responsable, que
debe tener acceso directo a los sistemas de producción en el entorno existente o debe tener medios para
proteger el acceso a través de otros actores responsables. Determinar esta entidad responsable afecta
directamente a la estrategia de promoción durante el proceso de migración y optimización.
Pasos siguientes
Cuando el equipo entiende en términos generales los roles y las responsabilidades, es el momento de empezar
a preparar los detalles técnicos de la migración. Comprender la complejidad técnica y la administración de
cambios puede ayudarlo a preparar el equipo de adopción de la nube para la complejidad técnica de la
migración mediante la alineación con un proceso de administración de cambios incremental.
Complejidad técnica y administración de cambios
Prepárese para abordar la complejidad técnica:
Administración de cambios ágil
Cuando se puede desaprovisionar y volver a crear un centro de datos entero con una sola línea de código, los
procesos tradicionales luchan por estar a la altura. Las instrucciones de Cloud Adoption Framework se basan en
prácticas como la administración de servicios de TI (ITSM), el marco de arquitectura de grupo abierta (TOGAF),
etc. Sin embargo, para garantizar la agilidad y la capacidad de respuesta al cambio empresarial, este marco de
trabajo moldea esas prácticas para incorporar metodologías ágiles y enfoques de DevOps.
Al cambiar a un modelo ágil donde se resaltan la flexibilidad y la iteración, la complejidad técnica y la
administración de cambios se tratan de forma diferente a como se hace en un modelo en cascada tradicional,
que se centra en una serie lineal de pasos de migración. En este artículo se describe un enfoque general para la
administración de cambios en un trabajo de migración basado en el método ágil. Al final del artículo, debería
tener una idea general de los niveles de administración de cambios y de la documentación que conlleva un
enfoque de migración incremental. Es necesario más aprendizaje y tomar más decisiones para seleccionar e
implementar prácticas ágiles basadas en esta idea. La intención de este artículo es preparar a los arquitectos de
la nube para una conversación facilitada con los directores de proyectos al objeto de explicar el concepto
general de administración de cambios con este enfoque.
Solucionar la complejidad técnica

Cuando se cambia cualquier sistema técnico, la complejidad y la interdependencia suponen un riesgo en los
planes del proyecto. Las migraciones a la nube no son una excepción. Cuando se mueven miles o decenas de
miles de recursos a la nube, estos riesgos se multiplican. La detección y la asignación de todas las dependencias
de un patrimonio digital podría tardar años. Pocas empresas pueden tolerar un ciclo de análisis tan largo. Con el
fin de equilibrar la necesidad de análisis arquitectónico y aceleración empresarial, el marco Cloud Adoption
Framework se centra en un modelo INVEST para la administración del trabajo pendiente de los productos. En las
secciones siguientes se resume este tipo de modelo.
INVEST en las cargas de trabajo

El término carga de trabajo está presente en todo el marco Cloud Adoption Framework. Una carga de trabajo es
una unidad de funcionalidad de una aplicación que se puede migrar a la nube. Podría ser una sola aplicación,
una capa de una aplicación o una colección de una aplicación. La definición es flexible y puede variar en
diferentes fases de la migración. El marco Cloud Adoption Framework utiliza el término INVEST para definir una
carga de trabajo.
INVEST es un acrónimo común en muchas metodologías ágiles para escribir casos de usuario o elementos de
trabajo pendiente de productos. Ambos son unidades de salida en herramientas de administración de proyectos
ágiles. La unidad de salida mensurable en una migración es una carga de trabajo migrada. El marco Cloud
Adoption Framework modifica un poco el acrónimo inglés INVEST para crear una construcción que defina las
cargas de trabajo:
Independent (independiente): una carga de trabajo no debe tener ninguna dependencia inaccesible. Para
que una carga de trabajo se considere migrada, todas las dependencias deben ser accesibles y estar incluidas
en el trabajo de migración.
Negotiable (negociable): a medida que se realiza una nueva detección, la definición de una carga de trabajo
cambia. Los arquitectos que planean la migración podrían negociar factores con respecto a las dependencias.
Algunos ejemplos de puntos de negociación podrían ser la versión preliminar de características, el acceso a
las características a través de una red híbrida o el empaquetado de todas las dependencias en una única
versión.
Valuable (valiosa): el valor de una carga de trabajo se mide por la capacidad de proporcionar a los usuarios
acceso a una carga de trabajo de producción.
Estimable (calculable): las dependencias, los recursos, el tiempo de migración, el rendimiento y los costos de
la nube deben poderse calcular y deben calcularse antes de la migración.
Small (pequeña): el objetivo es empaquetar las cargas de trabajo en un solo sprint. Sin embargo, puede que
esto no sea posible siempre. Por eso se recomienda que los equipos planeen los sprints y las versiones para
minimizar el tiempo necesario para mover una carga de trabajo a producción.
Testable (comprobable): Siempre debe haber un medio definido para probar o validar la finalización de la
migración de una carga de trabajo.
Este acrónimo no pretende ser una base que haya que adoptar de forma estricta, pero debería servir de guía
para definir el término carga de trabajo.
Trabajo pendiente de migración: alineación de las prioridades

empresariales y los plazos
El trabajo pendiente de migración permite realizar un seguimiento de la cartera general de cargas de trabajo
que se pueden migrar. Se recomienda que, antes de la migración, los equipos de estrategia en la nube y de
adopción de la nube revisen el patrimonio digital actual y acuerden una lista de las cargas de trabajo que deben
migrarse por orden de prioridad. Esta lista constituye la base del trabajo pendiente de migración inicial.
Al principio, es poco probable que las cargas de trabajo pendientes de migración cumplan los criterios INVEST
que se han descrito en la sección anterior. Más bien sirven como agrupación lógica de recursos de un inventario
inicial que se usará como marcador de posición para el trabajo futuro. Puede que esos marcadores de posición
no sean exactos desde un punto de vista técnico, pero sirven como base para la coordinación con la empresa.
Los trabajos pendientes de migración, versión e iteración realizan un seguimiento de los distintos niveles de
actividad durante los procesos de migración.
En cualquier trabajo pendiente de una migración, el equipo de administración de cambios debe procurar
obtener la siguiente información para cualquier carga de trabajo del plan. Como mínimo, estos datos deben
estar disponibles para cualquier carga de trabajo prioritaria para la migración en las dos o tres versiones
siguientes.
Puntos de datos del trabajo pendiente de migración
Impacto de negocio. Comprensión del impacto que tendría en el negocio si no se cumple la escala de
tiempo prevista o si se reduce la funcionalidad durante los períodos de inmovilización.
Prioridad empresarial relativa. Lista de cargas de trabajo clasificada por prioridad empresarial.
Propietario empresarial. Documente la persona responsable de tomar decisiones empresariales en
relación con esta carga de trabajo.
Propietario técnico. Documente la persona responsable de tomar decisiones técnicas en relación con esta
carga de trabajo.
Escalas de tiempo previstas. Fecha de finalización programada para la migración.
Inmovilizaciones de la carga de trabajo. Períodos en los que no se puede cambiar la carga de trabajo.
Nombre de la carga de trabajo.
Inventario inicial. Recursos necesarios para proporcionar la funcionalidad de la carga de trabajo, como las
máquinas virtuales, los dispositivos de TI, los datos, las aplicaciones, las canalizaciones de implementación,
etc. Es probable que esta información no sea precisa.
Trabajo pendiente de versión: alineación del cambio empresarial y la

coordinación técnica
En el contexto de una migración, una versión es una actividad que implementa una o varias cargas de trabajo en
producción. Generalmente, una versión abarca varias iteraciones o trabajo técnico. Sin embargo, representa una
sola iteración del cambio empresarial. Una vez que se han preparado una o más cargas de trabajo para pasarlas
a producción, se produce una versión. La decisión de empaquetar una versión se realiza cuando las cargas de
trabajo migradas representan un valor empresarial suficiente para justificar la inserción del cambio en un
entorno empresarial. Las versiones se ejecutan junto con un plan de cambio empresarial, después de haber
realizado pruebas empresariales. El equipo de estrategia en la nube es responsable de planear y supervisar la
ejecución de una versión para asegurarse de que se publica el cambio empresarial deseado.
Un trabajo pendiente de versión es el plan de estado futuro que define una versión próxima. El trabajo
pendiente de versión es el punto de inflexión entre la administración de cambios empresariales (trabajo
pendiente de migración) y la administración de cambios técnicos (trabajo pendiente de sprint). Un trabajo
pendiente de versión consiste en una lista de cargas de trabajo del trabajo pendiente de migración que están
alineadas con la realización de un subconjunto específico de resultados empresariales. La definición y el envío
de un trabajo pendiente de versión al equipo de adopción de la nube sirven como desencadenador para un
análisis más profundo y el planeamiento de la migración. Una vez que el equipo de adopción de la nube ha
comprobado los detalles técnicos asociados a una versión, puede optar por confirmar la versión y establecer
una escala de tiempo basada en el conocimiento actual.
Dado el grado de análisis necesario para validar una versión, el equipo de estrategia en la nube debe mantener
una lista activa de las dos a cuatro versiones siguientes. El equipo también debe intentar validar la información
siguiente en la medida de lo posible, antes de definir y enviar una versión. Un equipo de estrategia en la nube
disciplinado capaz de mantener las cuatro versiones siguientes puede aumentar considerablemente la
coherencia y la precisión de los cálculos de escala de tiempo para las versiones.
Puntos de datos del trabajo pendiente de versión
Los equipos de estrategia en la nube y de adopción de la nube deben colaborar para agregar los siguientes
puntos de datos para cualquier carga de trabajo en el trabajo pendiente de versión:
Inventario refinado. Validación de los recursos necesarios que se van a migrar. A menudo se validan con
datos de registro o de supervisión a nivel de host, de la red o del sistema operativo para asegurar un
conocimiento preciso de las dependencias de red y de hardware de cada recurso con una carga estándar.
Patrones de uso. Comprensión de los patrones de uso de los usuarios finales. Estos patrones suelen incluir
un análisis de la distribución geográfica de los usuarios finales, las rutas de red, los picos de uso temporales,
los picos de uso por día y hora, y la composición de los usuarios finales (internos o externos).
Expectativas de rendimiento. Análisis de los datos de registro disponibles que capturan el rendimiento,
las vistas de páginas, las rutas de red y otros datos de rendimiento necesarios para replicar la experiencia del
usuario final.
Dependencias. Análisis del tráfico de red y de los patrones de uso de las aplicaciones para identificar otras
dependencias posibles de las cargas de trabajo, que deben factorizarse en una secuenciación y en la
preparación del entorno. No incluya una carga de trabajo en una versión hasta que se cumpla alguno de los
siguientes criterios:
Todas las cargas de trabajo dependientes se han migrado.
Las configuraciones de red y de seguridad se han implementado para permitir que la carga de trabajo
tenga acceso a todas las dependencias en línea con las expectativas de rendimiento actuales.
Estrategia de migración deseada. En el nivel de trabajo pendiente de migración, el trabajo de migración
supuesto es la única consideración que se usa en el análisis. Por ejemplo, si el resultado empresarial es la
salida de un centro de datos actual, se supone que todas las migraciones son un escenario de rehospedaje en
el trabajo pendiente de migración. En el trabajo pendiente de versión, los equipos de estrategia en la nube y
de adopción de la nube deben evaluar el valor a largo plazo de características adicionales, la modernización y
las inversiones continuas en desarrollo para evaluar si debe utilizarse un enfoque más moderno.
Criterios para pruebas empresariales. Una vez agregada una carga de trabajo al trabajo pendiente de
migración, deben acordarse los criterios de prueba. En algunos casos, los criterios de prueba se pueden
limitar a una prueba de rendimiento con un grupo de usuarios avanzados definido. Sin embargo, para la
validación estadística, es preferible una prueba de rendimiento automatizada y debe incluirse. A menudo, la
instancia actual de la aplicación no tiene ninguna funcionalidad de pruebas automatizadas. En estos casos, no
es raro que los arquitectos de la nube trabajen con usuarios avanzados para crear una prueba de carga de
referencia para la solución actual con el fin de establecer un banco de pruebas que se usará durante la
migración.
Cadencia del trabajo pendiente de versión
En migraciones consolidadas, las versiones tienen una cadencia periódica. La velocidad del equipo de adopción
de la nube a menudo se normaliza y se produce una versión cada dos a cuatro iteraciones (aproximadamente
cada uno o dos meses). Sin embargo, debe ser un resultado natural. La creación de cadencias de versión
artificiales puede afectar negativamente a la capacidad del equipo de adopción de la nube de lograr un
rendimiento constante.
Para estabilizar el impacto de negocio, el equipo de estrategia en la nube debe establecer un proceso de versión
mensual con la empresa para mantener un diálogo regular, pero también debe crear la expectativa de que serán
necesarios varios meses para que se pueda predecir una cadencia de versión periódica.
Trabajo pendiente de sprint o iteración: alineación del cambio técnico

y el trabajo
Un sprint, o iteración, es una unidad de trabajo coherente con un plazo determinado. En el proceso de
migración, suele medirse en incrementos de dos semanas. Sin embargo, no es raro que se tengan iteraciones de
una semana o de cuatro semanas. La creación de iteraciones con un plazo determinado obliga a tener intervalos
de finalización del trabajo coherentes y permite ajustarse a los planes con más frecuencia, en función de los
nuevos conocimientos. Durante un sprint determinado, suele haber tareas para la evaluación, la migración y la
optimización de las cargas de trabajo definidas en el trabajo pendiente de migración. Debe realizarse un
seguimiento de estas unidades de trabajo y deben administrarse con la misma herramienta de administración
de proyectos que la migración y el trabajo pendiente de versión, con el fin de favorecer la coherencia en cada
nivel de la administración de cambios.
Un trabajo pendiente de sprint, o trabajo pendiente de iteración, consiste en el trabajo técnico que debe
realizarse en un único sprint (o iteración), abordando la migración de recursos individuales. Ese trabajo debe
derivarse de la lista de cargas de trabajo que se van a migrar. Cuando se usan herramientas como Azure DevOps
(antes conocido como Visual Studio Online) para la administración de proyectos, los elementos de trabajo de un
sprint serían elementos secundarios de los elementos de trabajo pendiente del producto en un trabajo
pendiente de versión y las epopeyas en un trabajo pendiente de migración. Esta relación principal-secundario
aporta claridad en todos los niveles de la administración de cambios.
Dentro de un solo sprint o una iteración, el equipo de adopción de la nube trabajaría para ofrecer la cantidad de
trabajo técnico confirmada, con el fin de migrar una carga de trabajo definida. Este es el resultado final de la
estrategia de administración de cambios. Una vez finalizado este trabajo, se puede probar validando la
preparación para producción de una carga de trabajo almacenada provisionalmente en la nube.
Estructuras de sprint grandes o complejas
Para una migración pequeña con un equipo de migración independiente, un solo sprint podría incluir las cuatro
fases de la migración para una sola carga de trabajo (evaluación, migración, optimización y protección y
administración). Normalmente, cada uno de estos procesos se comparte entre varios equipos en elementos de
trabajo diferentes en varios sprints. En función del tipo de trabajo, la escala de trabajo y los roles, estos sprints
pueden tener formas diferentes.
Factoría de migración. A veces, las migraciones a gran escala requieren un enfoque similar al de una
fábrica en el modelo de ejecución. En este modelo, se asignan varios equipos a la ejecución de un proceso (o
subconjunto del proceso) de migración específico. Una vez finalizado, la salida del sprint de un equipo rellena
el trabajo pendiente del equipo siguiente. Este enfoque es eficaz para migraciones de rehospedaje a gran
escala de muchas cargas de trabajo posibles que implican miles de máquinas virtuales pasando por las fases
de evaluación, arquitectura, corrección y migración. Sin embargo, para que este enfoque funcione, es
imprescindible un entorno homogéneo con procesos optimizados de aprobación y administración de
cambios.
Oleadas de migración. Otro enfoque que funciona bien para migraciones de gran envergadura es un
modelo por oleadas. En este modelo, la división del trabajo no está tan clara. Los equipos se dedican a
ejecutar procesos de migración de cargas de trabajo individuales. Sin embargo, la naturaleza de cada sprint
cambia. En un sprint, el equipo puede completar el trabajo de evaluación y de arquitectura. En otro sprint,
puede completar el trabajo de migración. En otro sprint, la atención estaría en la optimización y en la versión
para producción. Este enfoque permite que un equipo central permanezca alineado con las cargas de trabajo
y las vea a lo largo del proceso en su totalidad. Cuando se usa este enfoque, la diversidad de conocimientos y
el cambio de contexto puede reducir la velocidad potencial del equipo y ralentizar así el trabajo de migración.
Además, los obstáculos durante los ciclos de aprobación pueden dar lugar a retrasos considerables. Con este
modelo, es importante mantener opciones en el trabajo pendiente de versión para que el equipo no se
quede parado durante los períodos de bloqueo. También es importante el aprendizaje cruzado de los
miembros del equipo y asegurarse de que los conjuntos de aptitudes sean los adecuados para el tema de
cada sprint.
Puntos de datos del trabajo pendiente de sprint
El resultado de un sprint captura y documenta los cambios realizados en una carga de trabajo, con lo que se
cierra el bucle de administración de cambios. Una vez finalizado, debe documentarse, como mínimo, lo
siguiente. A lo largo de la ejecución de un sprint, esta documentación debe completarse junto con los elementos
de trabajo técnico.
Recursos implementados. Todos los recursos implementados en la nube para hospedar la carga de
trabajo.
Corrección. Cambios realizados en los recursos con el fin de prepararlos para la migración a la nube.
Configuración. Configuración elegida de los recursos implementados, incluidas las referencias a los scripts
de configuración.
Modelo de implementación. Enfoque usado para implementar el recurso en la nube, incluidas las
referencias a cualquier script o herramienta de implementación.
Arquitectura. Documentación de la arquitectura implementada en la nube.
Métricas de rendimiento. Salida de pruebas automatizadas o pruebas empresariales realizadas para
validar el rendimiento en el momento de la implementación.
Configuración o requisitos únicos. Cualquier aspecto único de la implementación, la configuración o los
requisitos técnicos necesarios para el funcionamiento de la carga de trabajo.
Aprobación operativa. Aprobación que valida la preparación operativa que proporcionan el propietario de
la aplicación y el personal de operaciones de TI responsable de administrar la carga de trabajo después de la
implementación.
Aprobación de la arquitectura. Aprobación del propietario de la carga de trabajo y del equipo de
adopción de la nube que valida los cambios de arquitectura necesarios para hospedar cada recurso.
Pasos siguientes
Una vez establecidos los enfoques de administración de cambios, es el momento de abordar el último requisito
previo, la revisión del trabajo pendiente de migración
La salida accionable durante la fase de planeamiento es un trabajo pendiente de migración, que influye en todos
los requisitos previos descritos hasta ahora. El desarrollo del trabajo pendiente de migración se debe completar
como primer requisito previo. Este artículo sirve como hito para completar las actividades de requisitos previos.
El equipo de la estrategia en la nube es responsable del cuidado y el mantenimiento del patrimonio digital. Sin
embargo, la realización del trabajo pendiente resultante es responsabilidad de cada miembro del trabajo de
migración. Como requisito previo final, el equipo de la estrategia en la nube y el equipo de adopción de la nube
deben revisar y comprender el trabajo pendiente de migración. Durante esa revisión, los miembros de ambos
equipos deben obtener conocimientos suficientes para articular los siguientes puntos clave en el trabajo
pendiente de migración.
Resultados y métricas empresariales

Cada miembro del equipo debe comprender los resultados empresariales deseados. Las migraciones tardan
tiempo. Es fácil que los miembros del equipo se distraigan por las actividades urgentes pero menos importantes
durante la migración. Establecer y reforzar los resultados deseados ayuda al equipo a comprender la prioridad y
la importancia relativa de la migración, lo que permite una mejor toma de decisiones a lo largo del tiempo.
El seguimiento del progreso de la migración es igualmente importante para la motivación del equipo y para el
soporte técnico continuado de las partes interesadas. Se puede realizar un seguimiento del progreso a través de
los KPI de migración y métricas de aprendizaje. Independientemente de cómo se realice el seguimiento del
trabajo, es importante que el equipo sea consciente de estas métricas para que puedan evaluar el rendimiento
durante las iteraciones posteriores.
A veces, dar prioridad a una carga de trabajo sobre otra puede parecer ilógico al equipo de adopción de la nube.
Comprender las prioridades empresariales que condujeron esas decisiones puede ayudar a mantener la
motivación del equipo. También permite al equipo realizar una mayor contribución al proceso de priorización.
Suposiciones básicas
En el artículo sobre la racionalización del patrimonio digital se describe la agilidad y el impacto del ahorro de
tiempo de las suposiciones básicas al evaluar un patrimonio digital. Para darse plena cuenta de estos valores, el
equipo de adopción de la nube necesita entender las suposiciones y las razones por las que se establecieron. Ese
conocimiento provee mejor al equipo de adopción de la nube para desafiar esas suposiciones.
Pasos siguientes
Con una descripción general del patrimonio digital y del trabajo pendiente de migración, el equipo está
preparado para ir más allá de los requisitos previos y comenzar a evaluar las cargas de trabajo.
Evaluación de las cargas de trabajo
Evaluación de cargas de trabajo y validación de las
suposiciones antes de la migración
Muchas de sus cargas de trabajo ya existentes son candidatas ideales para la migración a la nube, pero no todos
los recursos son compatibles con plataformas en la nube y no todas las cargas de trabajo se pueden beneficiar
del hospedaje en la nube. El planeamiento del patrimonio digital le permite generar un completo trabajo
pendiente de migración con posibles cargas de trabajo que se pueden migrar. Sin embargo, este esfuerzo de
planeamiento es de alto nivel. Se basa en suposiciones realizadas por el equipo de estrategia en la nube y no
analiza en profundidad las consideraciones técnicas.
Por tanto, antes de migrar una carga de trabajo a la nube es fundamental evaluar los recursos individuales
asociados a esa carga de trabajo para determinar su idoneidad para la migración. Durante esta valoración, su
equipo de adopción de la nube deberá evaluar la compatibilidad técnica, la arquitectura necesaria, las
expectativas de rendimiento y tamaño, y las dependencias para asegurarse de que la carga de trabajo migrada
se puede implementar eficazmente en la nube.
El proceso de valoración constituye la primera de las cuatro actividades incrementales que se producen en una
iteración. Como ya se ha descrito en el artículo de requisitos previos acerca de la complejidad técnica y la
administración de cambios, se debe tomar una decisión de antemano para determinar cómo se ejecuta esta
fase. Concretamente, ¿será el equipo de adopción de la nube el que complete las valoraciones durante el mismo
sprint que el esfuerzo de migración real? O, por el contrario, ¿se usará una oleada o modelo de fábrica para
completar las valoraciones en una iteración independiente? Si todos los miembros del equipo no pueden dar
una respuesta a esta pregunta básica sobre el proceso, es recomendable que revisen la sección de Requisitos
previos.
Objetivo
Valorar a una candidata a la migración mediante la evaluación de la carga de trabajo, los recursos y las
dependencias asociados antes de realizar la migración.
Este proceso termina cuando se realizan las siguientes tareas relacionadas con una carga de trabajo candidata a
la migración:
Se ha definido la ruta de acceso del entorno local a la nube, incluida la decisión sobre el método de
promoción de la producción.
Se han completado las aprobaciones, cambios, estimaciones de costos o procesos de validación necesarios
para permitir al equipo de adopción de la nube ejecutar la migración.
Responsabilidad durante la valoración

El equipo de adopción de la nube es responsable de todo el proceso de valoración. No obstante, los miembros
del equipo de estrategia en la nube también tienen algunas responsabilidades como se indica en la siguiente
sección.
Responsabilidades durante la valoración

responsables directamente. Estas son algunas de las actividades que se tienen que asignar a las partes
responsables:
Prioridad empresarial. El equipo comprende perfectamente la finalidad de la migración de esta carga de
trabajo, incluyendo cualquier impacto previsto en la empresa.
Un miembro del equipo de estrategia en la nube se debe hacer cargo de la responsabilidad final de
esta actividad, bajo la dirección del equipo de adopción de la nube.
Acuerdo con las par tes interesadas. El equipo ha acordado las expectativas y prioridades con las partes
interesadas internas identificando los factores para lograr el éxito de la migración. ¿Cómo identificar el éxito
después de la migración?
Racionalización perfeccionada. Evalúe las suposiciones iniciales en relación con la racionalización. ¿Se
debe usar un enfoque de racionalización diferente para migrar esta carga de trabajo específica?
Decisiones de modernización. Independientemente de la decisión sobre la racionalización, ¿se deben
modernizar varios recursos de la carga de trabajo para usar las soluciones basadas en PaaS?
Costo. Se ha estimado el costo de la arquitectura de destino y se ha ajustado el presupuesto total.
Compatibilidad con la migración. El equipo ha decidido cómo se llevará a cabo el trabajo técnico de la
migración, incluidas las decisiones relacionadas con el soporte de los asociados o de Microsoft.
Evaluación. Se evalúa la compatibilidad y las dependencias de la carga de trabajo.
Esta actividad debe asignarse a un experto en la materia que esté familiarizado con la arquitectura y
las operaciones de la carga de trabajo candidata.
Arquitecto. El equipo ha acordado la arquitectura final de la carga de trabajo migrada.
Herramientas de migración. Según los enfoques de modernización y arquitectura, se podrían usar varias
herramientas de migración para automatizar la migración. En función de la arquitectura propuesta, ¿usará
esta migración las mejores herramientas de migración?
Acuerdo sobre el trabajo pendiente. El equipo de adopción de la nube revisa los requisitos y se
compromete a la migración de la carga de trabajo candidata. Después de este compromiso, se debe
actualizar el trabajo pendiente de publicación y el de iteración según corresponda.
Estructura de descomposición del trabajo o programación del trabajo. El equipo define una
programación con los hitos más importantes identificando los objetivos que determinan cuándo finalizar los
procesos de planeamiento, implementación y revisión.
Aprobación final. Todos los aprobadores necesarios han revisado el plan y han aprobado el enfoque para
migrar el recurso.
Para evitar sorpresas más adelante en el proceso, al menos un representante de la empresa debe
participar en el proceso de aprobación.
Cau t i on
Esta lista completa de responsabilidades y acciones puede admitir migraciones grandes y complejas que
implican varios roles con distintos niveles de responsabilidad y que requieren un proceso de aprobación
detallado. Puede que otros esfuerzos de migración más sencillos y pequeños no necesiten todos los roles y
acciones que se describen aquí. Para determinar cuáles de estas actividades agregan valor y cuáles son
innecesarias, tanto el equipo de adopción de la nube como el de estrategia en la nube deberían usar todo este
proceso como parte de la migración de la primera carga de trabajo. Después de haber comprobado y probado
la carga de trabajo, el equipo puede evaluar este proceso y elegir qué acciones desea usar más adelante.
Pasos siguientes
Si tiene un conocimiento general del proceso de valoración, estará listo para comenzar el proceso de
clasificación de las cargas de trabajo.
Clasificación de cargas de trabajo
Clasificación de la carga de trabajo antes de la
migración
Durante cada iteración de un proceso de migración, una o más cargas de trabajo se migrarán y promoverán a
producción. Antes de realizar estas actividades de migración, es importante clasificar cada carga de trabajo. La
clasificación ayuda a aclarar los requisitos de gobernanza, seguridad, operaciones y administración de datos.
La siguiente guía se basa en los requisitos de etiquetado sugeridos que se describen en Definición de la
estrategia de etiquetado y agrega importantes operaciones y elementos de gobernanza.
En este artículo, se recomienda específicamente agregar el grado de importancia y la confidencialidad de los
datos a los estándares de etiquetado existentes. Cada uno de estos puntos de datos ayudará a otros equipos a
comprender qué cargas de trabajo pueden requerir atención o soporte técnico adicional.
Confidencialidad de los datos

Como se describe en el artículo sobre clasificación de datos, esta mide el impacto que tendría una fuga de datos
en la empresa o los clientes. Los equipos de gobernanza y seguridad utilizan la confidencialidad o la clasificación
de los datos como un indicador de riesgo para la seguridad. Durante la evaluación, el equipo de adopción de la
nube debe evaluar la clasificación de los datos para cada carga de trabajo destinada a la migración y compartir
esa clasificación con los equipos auxiliares. Es posible que las cargas de trabajo que traten estrictamente con
"datos públicos" no afecten a los equipos auxiliares. Sin embargo, a medida que los datos se mueven hacia el
extremo "extremadamente confidencial" del espectro, es probable que tanto los equipos de gobernanza como
los de seguridad tengan interés en participar en la valoración de la carga de trabajo.
Trabaje con los equipos de seguridad y gobernanza tan pronto como sea posible para definir los siguientes
elementos:
Un proceso claro para compartir las cargas del trabajo pendiente que incluyan datos confidenciales.
La comprensión de los requisitos de gobernanza y de base de referencia de seguridad necesarios para los
distintos niveles de confidencialidad de los datos.
Cualquier impacto que la confidencialidad de los datos pueda tener en el diseño de las suscripciones, las
jerarquías de los grupos de administración o los requisitos de la zona de aterrizaje.
Cualquier requisito para probar la clasificación de datos, que puede incluir herramientas específicas o un
ámbito de clasificación definido.
Grado de importancia de la misión

Tal y como se describe en el artículo sobre el grado de importancia de la carga de trabajo, este valor indica en
qué medida se verá afectado el negocio durante una interrupción. Este punto de datos ayuda a los equipos de
seguridad y administración de operaciones a evaluar los riesgos relacionados con las interrupciones y las
vulneraciones. Durante la evaluación, el equipo de adopción de la nube debe evaluar el grado de importancia de
la misión de cada carga de trabajo destinada a la migración y compartir esa clasificación con los equipos
auxiliares. Es probable que las cargas de trabajo con un grado "bajo" o "no compatibles" tengan poco impacto
en los equipos auxiliares. Sin embargo, a medida que las cargas de trabajo se aproximan a las clasificaciones de
grado "crítico para la misión" o "crítico para la unidad", sus dependencias operativas se hacen más evidentes.
Trabaje con los equipos de operaciones y seguridad tan pronto como sea posible para definir los siguientes
elementos:
Un proceso claro para compartir las cargas del trabajo pendiente con requisitos de soporte técnico.
La comprensión de los requisitos de administración de operaciones y coherencia de recursos para los
diferentes grados de importancia.
Cualquier impacto que el grado de importancia pueda tener en el diseño de las suscripciones, las jerarquías
de los grupos de administración o los requisitos de la zona de aterrizaje.
Cualquier requisito necesario para documentar el grado de importancia, que puede incluir informes de uso o
tráfico específicos, análisis financieros u otras herramientas.
Pasos siguientes
Una vez que las cargas de trabajo están clasificadas correctamente, es mucho más fácil alinear las prioridades
empresariales.
Alineación de las prioridades empresariales
Prioridades empresariales: mantenimiento de la
alineación
La transformación se suele definir como un cambio drástico o espontáneo. En el nivel de panel, el cambio puede
ser similar a una transformación drástica. Sin embargo, para aquellos que trabajan a lo largo del proceso de
cambio en una organización, la transformación es un poco engañosa. Bajo la superficie, la transformación se
describe mejor como una serie de transiciones ejecutadas correctamente de un estado a otro.
La cantidad de tiempo que se necesita para racionalizar o cambiar una carga de trabajo variará en función de la
complejidad técnica implicada. Sin embargo, incluso cuando este proceso se puede aplicar rápidamente a una
sola carga de trabajo o a un grupo de aplicaciones, generar cambios sustanciales entre una base de usuarios
tarda un tiempo. Los cambios tardan más en propagarse a través de las diversas capas de procesos
empresariales existentes. Si se espera que la transformación dé forma a los patrones de comportamiento de los
consumidores, los resultados pueden tardar más tiempo en generar resultados significativos.
Desafortunadamente, el mercado no espera a que las empresas cambien. Los patrones de comportamiento del
consumidor cambian por sí solos, a menudo de manera inesperada. La percepción del mercado de una empresa
y sus productos se puede ver influenciada por las redes sociales o por la posición de un competidor. Los
cambios de mercado rápidos e inesperados exigen que las empresas sean ágiles y receptivas.
La capacidad de ejecutar procesos y transiciones técnicas requiere un esfuerzo constante y estable. Se necesitan
decisiones rápidas y medidas ágiles para responder a las condiciones del mercado. Estos dos aspectos entran en
conflicto, lo que facilita que las prioridades queden fuera de la alineación. En este artículo se describen los
enfoques para mantener la alineación transitoria durante los esfuerzos de migración.
¿Cómo pueden las prioridades empresariales y técnicas mantenerse

alineadas durante una migración?
El equipo de adopción de la nube y el equipo de gobernanza de la nube se centran en la ejecución de la iteración
actual y de la liberación actual. Las iteraciones proporcionan incrementos estables de trabajo técnico y, por lo
tanto, evitan interrupciones costosas que, de otro modo, ralentizarían el progreso de los esfuerzos de migración.
Las liberaciones se aseguran de que la energía y el esfuerzo técnico se mantengan centrados en los objetivos de
negocio de la migración de la carga de trabajo. Un proyecto de migración podría requerir muchas liberaciones
durante un período prolongado. Cuando se complete, es probable que las condiciones de mercado hayan
cambiado considerablemente.
En paralelo, el equipo de estrategia en la nube se centra en la ejecución del plan de cambio empresarial y en la
preparación de la próxima liberación. Por lo general, el equipo de estrategia en la nube examina al menos una
liberación por anticipado y supervisa las condiciones de mercado cambiantes para ajustar en consecuencia el
trabajo pendiente de la migración. El objetivo de administrar la transformación y ajustar el plan crea
dinamizaciones naturales en torno al trabajo técnico. Cuando cambian las prioridades empresariales, la
adopción solo está una liberación atrás, lo que permite crear agilidad técnica y empresarial.
Preguntas sobre la alineación empresarial

Las siguientes preguntas pueden ayudar a que el equipo de estrategia en la nube dé forma al trabajo pendiente
de la migración y le asigne prioridad para garantizar que el esfuerzo de transformación se alinee mejor con las
necesidades empresariales actuales.
¿El equipo de adopción de la nube identificó una lista de las cargas de trabajo listas para la migración?
¿El equipo de adopción de la nube seleccionó un candidato único para una migración inicial de esa lista de
cargas de trabajo?
¿Los equipos de adopción de la nube y de gobernanza de la nube tienen todos los datos necesarios
relacionados con la carga de trabajo y el entorno de nube para que las operaciones se realicen
correctamente?
¿La carga de trabajo candidata ofrece el impacto más importante para la empresa en la próxima liberación?
¿Hay otras cargas de trabajo que sean mejores candidatas para la migración?
Acciones tangibles
Durante la ejecución del plan de cambio empresarial, el equipo de estrategia en la nube supervisa los resultados
positivos y negativos. Cuando esas observaciones requieren cambios técnicos, los ajustes se agregan como
elementos de trabajo al trabajo pendiente de liberación para que se asigne su prioridad en la siguiente iteración.
Cuando el mercado cambia, el equipo de estrategia en la nube trabaja con la empresa para saber cómo
responder mejor a los cambios. Cuando esa respuesta requiere un cambio en las prioridades de la migración, se
ajusta el trabajo pendiente de la migración. De este modo, se asigna una prioridad más alta a cargas de trabajo
que tenían previamente menos prioridad.
Pasos siguientes
Con las prioridades empresariales correctamente alineadas, el equipo de adopción de la nube puede comenzar a
evaluar las cargas de trabajo con confianza para desarrollar planes de arquitectura y migración.
Evaluación de las cargas de trabajo
Evaluación de la disponibilidad de las cargas de
trabajo
Esta actividad se centra en evaluar la disponibilidad de una carga de trabajo para migrar a la nube. Durante esta
actividad, el equipo de adopción de la nube valida que todos los recursos y las dependencias asociadas sean
compatibles con el modelo de implementación y el proveedor de nube elegidos. Durante el proceso, el equipo
documenta los esfuerzos necesarios para corregir los problemas de compatibilidad.
Suposiciones de evaluación
La mayor parte del contenido que analiza los principios de Cloud Adoption Framework no depende de la nube.
Sin embargo, el proceso de evaluación de la disponibilidad debe ser muy específico para cada plataforma de
nube específica. En la siguiente guía se presupone una intención de migrar a Azure. También se presupone el
uso de Azure Migrate (también conocido como Azure Site Recovery) para las actividades de replicación. Para ver
herramientas alternativas, consulte las opciones de replicación.
Este artículo no incluye todas las actividades de evaluación posibles. Se presupone que cada entorno y resultado
empresarial determinarán los requisitos específicos. Para ayudar a acelerar la creación de estos requisitos, el
resto de este artículo comparte algunas actividades de evaluación comunes relacionadas con la evaluación de la
infraestructura, la base de datos y la red.
Actividades comunes de evaluación de la infraestructura

Requisitos de VMware: revise los requisitos de Azure Site Recovery para VMware.
Requisitos de Hyper-V: revise los requisitos de Azure Site Recovery para Hyper-V.
Asegúrese de documentar cualquier discrepancia que haya en la configuración del host, la configuración de la
máquina virtual replicada, los requisitos de almacenamiento o la configuración de red.
Actividades comunes de evaluación de bases de datos

Documente los objetivos de punto de recuperación (RPO) y los objetivos de tiempo de recuperación (RTO) de
la implementación de base de datos actual. Se usan durante las actividades de arquitectura como ayuda para
la toma de decisiones.
Documente los requisitos de configuración de alta disponibilidad. Para entender los requisitos de SQL Server,
consulte la guía de soluciones de alta disponibilidad de SQL Server.
Evalúe la compatibilidad de PaaS. En la guía de migración de datos de Azure se asignan bases de datos
locales a soluciones de PaaS de Azure compatibles, como Azure Cosmos DB, Azure SQL Database, Azure
Database for MySQL, Azure Database for PostgreSQL o Azure Database for MariaDB.
Cuando la compatibilidad con PaaS es una opción sin necesidad de realizar ninguna corrección, consulte al
equipo responsable de las actividades de arquitectura. Las migraciones de PaaS pueden generar importantes
ahorros de tiempo y disminuciones en el costo total de propiedad (TCO) de la mayoría de las soluciones en la
nube.
Cuando la compatibilidad con PaaS es una opción, pero se requiere una corrección, consulte a los equipos
responsables de las actividades de arquitectura y las actividades de corrección. En muchos escenarios, las
ventajas de las migraciones de PaaS para las soluciones de base de datos pueden superar el aumento en el
tiempo de corrección.
Documente el tamaño y la tasa de cambio de cada base de datos que se va a migrar.
Siempre que sea posible, documente las aplicaciones u otros recursos que realicen llamadas a cada base de
datos.
NOTE
La sincronización de cualquier recurso consume ancho de banda durante los procesos de replicación. Una dificultad muy
común es pasar por alto el consumo de ancho de banda necesario para mantener los recursos sincronizados entre el
punto de replicación y la liberación. Las bases de datos son consumidores comunes de ancho de banda durante los ciclos
de liberación y las bases de datos con grandes superficies de almacenamiento o una alta tasa de cambio están son de
especial interés. Considere un enfoque de replicación de la estructura de datos, con actualizaciones controladas antes de
las pruebas de aceptación de usuario (UAT) y las liberaciones. En estos escenarios, pueden ser más adecuadas alternativas
a Azure Site Recovery. Para más información, consulte las instrucciones de la Guía de migración de Azure Database.
Actividades comunes de evaluación de la red

Calcule el almacenamiento total para todas las máquinas virtuales que se van a replicar durante las
iteraciones que conducen a una liberación.
Calcule la desviación o la tasa de cambio del almacenamiento para todas las máquinas virtuales que se van a
replicar durante las iteraciones que conducen a una liberación.
Calcule los requisitos de ancho de banda necesarios para cada iteración mediante la suma del
almacenamiento y la desviación totales.
Calcule el ancho de banda sin usar disponible en la red actual para validar por alineación de iteraciones.
Documente el ancho de banda necesario para alcanzar la velocidad de migración esperada. Si se requiere
alguna corrección para proporcionar el ancho de banda necesario, notifique al equipo responsable de las
actividades de corrección.
NOTE
El almacenamiento total afecta directamente a los requisitos de ancho de banda durante la replicación inicial. Sin embargo,
la desviación del almacenamiento continúa desde el punto de replicación hasta la liberación. Esto significa que la
desviación tiene un efecto acumulativo en el ancho de banda disponible.
Pasos siguientes
Una vez que se completa la evaluación de un sistema, los resultados alimentan el desarrollo de una nueva
arquitectura de nube.
Diseño de las cargas de trabajo antes de una migración
Diseño de las cargas de trabajo antes de una
migración
En este artículo se amplía el proceso de evaluación a través de la revisión de las actividades asociadas con la
definición de la arquitectura de una carga de trabajo dentro de una iteración determinada. Tal como se describe
en el artículo sobre la racionalización incremental, se realizan algunas suposiciones de diseño durante cualquier
transformación empresarial que requiera una migración. En este artículo se explican estas suposiciones, se
comparten algunos obstáculos que se pueden evitar y se identifican oportunidades para acelerar el valor
empresarial al desafiar esas suposiciones. Este modelo incremental para la arquitectura permite que los equipos
se muevan más rápido y obtengan resultados empresariales antes.
Suposiciones de arquitectura antes de la migración

Las suposiciones siguientes son típicas para cualquier esfuerzo de migración:
IaaS. Se suele suponer que la migración de cargas de trabajo implica principalmente el movimiento de
máquinas virtuales desde un centro de datos físico a un centro de datos en la nube a través de una
migración de IaaS, que requiere un mínimo de redesarrollo o reconfiguración. Este enfoque se conoce como
migración mediante lift-and-shift. (A continuación, se muestran algunas excepciones).
Coherencia de la arquitectura. Los cambios en la arquitectura central durante una migración aumentan
considerablemente la complejidad. La depuración de un sistema modificado en una plataforma nueva
presenta muchas variables que pueden ser difíciles de aislar. Es por esta razón que las cargas de trabajo se
deben someter solo a cambios menores durante la migración y cualquier cambio se debe probar
minuciosamente.
Prueba de retirada. Las migraciones y el hospedaje de recursos consumen gastos operativos y de capital
potenciales. Se supone que las cargas de trabajo que se van a migrar se revisaron para validar su uso
continuo. La opción de retirar los recursos no utilizados genera un ahorro de costos inmediato.
Cambiar el tamaño de los recursos. Se presupone que unos pocos recursos locales están usando por
completo los recursos asignados. Antes de la migración, se presupone que el tamaño de los recursos se
modificará para ajustarlo mejor a los requisitos de uso reales.
Requisitos de continuidad empresarial y recuperación ante desastres (BCDR). Se supone que un
acuerdo de nivel de servicio acordado para la carga de trabajo se negoció con la empresa antes de planear
una liberación. Es probable que estos requisitos generen cambios de arquitectura menores.
Tiempo de inactividad de la migración. Del mismo modo, el tiempo de inactividad para promover la
carga de trabajo al entorno de producción puede tener un efecto adverso en la empresa. A veces, las
soluciones que deben realizar la transición con un tiempo de inactividad mínimo necesitan cambios de
arquitectura. Se supone que se estableció una descripción general de los requisitos de tiempo de inactividad
antes de planear una liberación.
Patrones de tráfico de usuario. Las soluciones existentes pueden depender de los patrones de
enrutamiento de red existentes. Estos patrones podrían ralentizar considerablemente el rendimiento.
Además, la introducción de nuevas soluciones de red de área extensa (WAN) híbrida puede tardar semanas o
incluso meses. Antes de la migración, se supone que las zonas de aterrizaje ya han tenido en cuenta los
patrones de tráfico pertinentes y los cambios en los servicios de infraestructura principales.
Mitigación de obstáculos potenciales

Las suposiciones detalladas pueden crear obstáculos que podrían ralentizar el progreso o generar más puntos
críticos. A continuación, se indican algunos obstáculos que hay que supervisar antes de la liberación:
Pago de una deuda técnica. Algunas cargas de trabajo antiguas tienen una gran cantidad de deuda
técnica. La deuda técnica puede conducir a desafíos a largo plazo al aumentar los costos de hospedaje con
cualquier proveedor de servicios en la nube. Cuando la deuda técnica aumenta de manera poco natural los
costos de hospedaje, se deben evaluar arquitecturas alternativas.
Mejorar la confiabilidad. Las bases de referencia de las operaciones estándar proporcionan un grado de
confiabilidad y recuperación en la nube. Sin embargo, algunos equipos de carga de trabajo pueden requerir
acuerdos de nivel de equipo superiores que podrían conducir a cambios arquitectónicos.
Cargas de trabajo de alto costo. Durante la migración, todos los recursos deben optimizarse para alinear
el tamaño con el uso real. Sin embargo, algunas cargas de trabajo pueden requerir modificaciones
arquitectónicas para solucionar los problemas específicos de los costos.
Requisitos de rendimiento. Cuando el rendimiento de la carga de trabajo tiene un impacto empresarial
directo, es posible que sea necesaria una consideración de arquitectura adicional.
Aplicaciones seguras. Los requisitos de seguridad tienden a implementarse de forma centralizada y se
aplican a todas las cargas de trabajo de la cartera. Sin embargo, algunas cargas de trabajo pueden tener
requisitos de seguridad específicos que podrían conducir a cambios arquitectónicos.
Todos los criterios anteriores sirven de indicadores de obstáculos potenciales para la migración. Normalmente,
los criterios anteriores se tratan después de migrar una carga de trabajo. Pero si se requiere alguno de estos
criterios antes de migrar una carga de trabajo, debe quitarse de la onda de migración y evaluarse
individualmente.
El Marco de buena arquitectura de Microsoft Azure y la Reseña de buena arquitectura de Microsoft Azure
pueden ayudar a guiar esas conversaciones con el propietario técnico de una carga de trabajo específica a fin de
tener en cuenta las opciones alternativas para implementar la carga de trabajo. A continuación, estas cargas de
trabajo se clasificarían como un esfuerzo de rediseño del plan de adopción de la nube. Dado el tiempo adicional
necesario para rediseñar una carga de trabajo, estas rutas de acceso de adopción de carga de trabajo
alternativas no se deben considerar parte del proceso de migración.
Aceleración del valor empresarial

Algunos escenarios podrían requerir una arquitectura diferente a la de la estrategia de rehospedaje de IaaS
supuesta. Estos son algunos ejemplos:
Modernización de PaaS. Algunos recursos tecnológicos se pueden migrar a soluciones de plataforma
como servicio más modernas, lo que reduce el riesgo durante la migración. Las herramientas de migración
automatizadas como Azure Migrate sugieren e incluso automatizan las oportunidades de modernización.
Algunos ejemplos de modernización en curso incluirían cambios de bajo riesgo como el uso de
Azure Database Migration Service (DMS) para modernizar las bases de datos. Para una lista de los enfoques
que podrían beneficiarse de una conversión de PaaS, consulte el artículo sobre la evaluación de los recursos.
Implementaciones con scripts/DevOps. Si una carga de trabajo tiene una implementación de DevOps
existente u otras formas de implementaciones con scripts, el costo de cambiar esos scripts podría ser menor
que el costo de migrar el recurso.
Esfuerzos de corrección. Los esfuerzos de corrección necesarios para preparar una carga de trabajo para
la migración pueden ser importantes. En algunos casos, tiene más sentido modernizar la solución que
corregir los problemas de compatibilidad subyacentes.
En cada uno de estos escenarios detallados, una arquitectura alternativa podría ser la mejor solución posible.
Pasos siguientes
Una vez definida la arquitectura nueva, se pueden calcular estimaciones de costos precisas.
Estimación del costo de la nube
Estimación del costo de la nube
Durante la migración, hay varios factores que pueden afectar a las decisiones y las actividades de ejecución. Para
ayudar a entender cuáles son las opciones más adecuadas para las distintas situaciones, en este artículo se
describen varias opciones para estimar el costo de la nube.
Tamaño del patrimonio digital

El tamaño del patrimonio digital afecta directamente a las decisiones de migración. Las migraciones que
impliquen menos de 250 máquinas virtuales se pueden calcular mucho más fácilmente que una migración que
implique más de 10 000 máquinas virtuales. Se recomienda encarecidamente que seleccione una carga de
trabajo más pequeña para su primera migración. Esto le brinda al equipo una oportunidad para aprender a
calcular los costos de un esfuerzo de migración sencillo antes de intentar calcular migraciones de cargas de
trabajo más grandes y complejas.
Sin embargo, tenga en cuenta que las migraciones más pequeñas, de una sola carga de trabajo, de todos modos
pueden implicar una cantidad muy variable de recursos complementarios. Si la migración implica menos de
1000 máquinas virtuales, una herramienta como Azure Migrate probablemente sea suficiente para recopilar
datos sobre el inventario y realizar una previsión de los costos. Las opciones de herramientas de cálculos de
costos adicionales se describen en el artículo sobre los cálculos de costos del patrimonio digital.
Si hablamos de patrimonios digitales con más de 1000 unidades, todavía es posible desglosar una estimación
en cuatro o cinco iteraciones accionables, lo que permite que el proceso de estimación sea manejable. En el caso
de patrimonios más grandes o cuando se requiere un mayor grado de precisión para la previsión, es posible
que se requiera un enfoque más integral, como el que se describe en la sección Patrimonio digital de Cloud
Adoption Framework.
Modelos de contabilidad
Modelos de contabilidad
Si está familiarizado con los procesos de adquisición de TI tradicionales, es posible que la estimación en la nube
parezca externa. Cuando se adoptan tecnologías de nube, la adquisición pasa de un modelo rígido y
estructurado de gastos de capital a un modelo de gastos operativos fluidos. En el modelo de gastos de capital
tradicional, el equipo de TI intentaría consolidar el poder adquisitivo de varias cargas de trabajo en varios
programas con el fin de centralizar un grupo de recursos de TI compartidos que podrían admitir cada una de
esas soluciones. En el modelo de gastos operativos en la nube, los costos se pueden atribuir directamente a las
necesidades de compatibilidad de cargas de trabajo individuales, equipos o unidades de negocio. Este enfoque
permite una atribución más directa de los costos al cliente interno compatible. Al estimar los costos, es
importante comprender primero qué parte de esta nueva funcionalidad de contabilidad usará el equipo de TI.
Para quienes deseen replicar el enfoque de gastos de capital heredado para la contabilidad, use las salidas de
cualquiera de los enfoques sugeridos en la sección Tamaño del patrimonio digital más arriba para obtener una
base de costos anual. A continuación, multiplique ese costo anual por el ciclo de actualización de hardware típico
de la empresa. El ciclo de actualización de hardware se refiere la velocidad con la que una empresa reemplaza el
hardware antiguo y que, por lo general, se mide en años. La velocidad de ejecución anual multiplicada por el
ciclo de actualización de hardware crea una estructura de costos similar a un patrón de inversión de gastos de
capital.
Pasos siguientes
Después de estimar los costos, puede comenzar la migración. Sin embargo, sería aconsejable revisar las
opciones de colaboración y soporte técnico antes de comenzar cualquier migración.
Descripción de las opciones de colaboración y soporte técnico
Descripción de las opciones de colaboración y
soporte técnico
Durante la migración, el equipo de adopción de la nube realiza la migración real de cargas de trabajo a la nube.
A diferencia de las tareas de colaboración y solución de problemas a la hora de definir el patrimonio digital o de
crear la infraestructura en la nube principal, la migración tiende a ser una serie de tareas de ejecución
repetitivas. Más allá de los aspectos repetitivos, es probable que haya esfuerzos de prueba y optimización que
requieren un conocimiento profundo del proveedor de nube elegido. En algunas ocasiones, un asociado puede
abordar mejor la naturaleza repetitiva de este proceso, lo que reduce la presión sobre el personal a tiempo
completo. Además, los asociados pueden ser capaces de alinear mejor los conocimientos técnicos cuando los
procesos repetitivos detectan anomalías en una ejecución.
Los asociados tienden a estar estrechamente alineados con un solo proveedor de nube o con un número
reducido de proveedores de nube. Para ilustrar mejor las opciones de asociación, para el resto de este artículo
se presupone que Microsoft Azure es el proveedor de nube elegido.
Durante el plan, la compilación o la migración, una empresa generalmente tiene cuatro opciones de
colaboración para la ejecución:
Autoser vicio guiado. El equipo técnico existente ejecuta la migración, con la ayuda de Microsoft.
FastTrack for Azure. Use el programa Microsoft FastTrack for Azure para acelerar la migración.
Par tners de soluciones. Póngase en contacto con partners de Azure o proveedores de soluciones en la
nube (CSP) para acelerar la migración.
Autoser vicio compatible. La ejecución la lleva a cabo el personal técnico existente con soporte técnico de
Microsoft.
Autoservicio guiado
Si una organización planea realizar una migración a Azure por sí misma, Microsoft siempre está ahí para
ayudarle durante el recorrido. Para ayudar a realizar una migración acelerada a Azure, Microsoft y sus asociados
han desarrollado un amplio conjunto de arquitecturas, guías, herramientas y servicios con el fin de disminuir el
riesgo y acelerar la migración de máquinas virtuales, aplicaciones y bases de datos. Estas herramientas y
servicios admiten una amplia selección de sistemas operativos, lenguajes de programación, marcos y bases de
datos.
Herramientas de evaluación y migración. Azure proporciona una amplia variedad de herramientas que
se pueden usar en distintas fases para la transformación en la nube, incluida la evaluación de la
infraestructura existente. Para obtener más información, consulte la sección "Evaluación" en el capítulo
"Migración" que aparece a continuación.
Plataforma de adopción de la nube de Microsoft . Esta plataforma presenta un enfoque estructurado
para la adopción y la migración a la nube. Se basa en los procedimientos recomendados en muchas de las
interacciones con los clientes compatibles con Microsoft y se organiza como una serie de pasos, desde la
arquitectura y el diseño hasta la implementación. Para cada paso, hay instrucciones auxiliares que lo
ayudarán con el diseño de la arquitectura de la aplicación.
Patrones de diseño en la nube . Azure proporciona algunos patrones útiles de diseño en la nube para
crear cargas de trabajo confiables, escalables y seguras en la nube. Cada patrón describe el problema al que
hace frente, las consideraciones sobre su aplicación y un ejemplo basado en Azure. La mayoría incluye
ejemplos de código o fragmentos de código que muestran cómo implementar el patrón en Azure. Sin
embargo, son importantes para todos los sistemas distribuidos, tanto si se hospedan en Azure como en otras
plataformas en la nube.
Aspectos básicos de la nube . Estos ayudan a enseñar los enfoques básicos para la implementación de los
conceptos básicos. Esta guía ayuda a los técnicos a pensar en soluciones que van más allá de un único
servicio de Azure.
Escenarios de ejemplo . En esta guía se proporcionan referencias de implementaciones de clientes reales,
donde se describen las herramientas, los enfoques y los procesos que los clientes han seguido para lograr
objetivos empresariales específicos.
Arquitecturas de referencia . Las arquitecturas de referencia se organizan por escenario, agrupando juntas
aquellas arquitecturas relacionadas. Cada arquitectura incluye procedimientos recomendados junto con
consideraciones sobre escalabilidad, disponibilidad, capacidad de administración y seguridad. La mayoría
también incluye una solución que se puede implementar.
FastTrack for Azure

FastTrack for Azure ofrece asistencia directa por parte de los ingenieros de Azure, en estrecha colaboración con
los asociados, para ayudar a los clientes a compilar las soluciones de Azure con rapidez y confianza. FastTrack
aporta procedimientos recomendados y herramientas de experiencias reales del cliente para guiar a los clientes
desde la instalación, la configuración y el desarrollo hasta la producción de soluciones de Azure, lo que incluye:
Migración de centros de datos
Windows Server en Azure
Linux en Azure
SAP en Azure
Recuperación ante desastres y continuidad empresarial (BCDR)
Informática de alto rendimiento
Aplicaciones nativas de la nube
DevOps
Modernización de aplicaciones
Análisis a escala de nube
Aplicaciones inteligentes
Agentes inteligentes
Modernización de datos en Azure
Seguridad y administración
Datos distribuidos globalmente
Azure Marketplace
Aspectos básicos y gobernanza
Durante una interacción típica de FastTrack for Azure, Microsoft ayuda a definir la visión empresarial para
planear y desarrollar correctamente soluciones de Azure. El equipo evalúa las necesidades de diseño y
proporciona instrucciones, principios de diseño, herramientas y recursos para ayudar a compilar, implementar y
administrar soluciones de Azure. El equipo empareja asociados cualificados para los servicios de
implementación a petición y se registran periódicamente para asegurarse de que la implementación está en
buen pie y para ayudar a quitar los bloqueadores.
Las principales fases de una interacción típica de FastTrack for Azure son:
Detección. Identifique a las partes interesadas clave, comprenda el objetivo o la visión de los problemas que
se van a resolver y evalúe las necesidades de diseño.
Habilitación de soluciones. Aprenda principios de diseño para crear aplicaciones, revisar la arquitectura
de aplicaciones y soluciones y obtenga instrucciones y herramientas para impulsar el trabajo de prueba de
concepto hasta producción.
Colaboración continua. Los administradores de programas y los ingenieros de Azure se registran cada
tanto para asegurarse de que la implementación está en buen pie y para ayudar a quitar los bloqueadores.
Ofertas de los Servicios de Microsoft alineadas con los enfoques de la

Plataforma de adopción de la nube
Evaluación: Los Servicios de Microsoft usan un enfoque unificado impulsado por datos y herramientas que se
compone de talleres de diseño, información en tiempo real de Azure, modelos de amenazas de seguridad e
identidad, y diversas herramientas para proporcionar información sobre los desafíos, los riesgos, las
recomendaciones y los problemas a un entorno de Azure existente con un resultado clave como la hoja de ruta
de modernización de alto nivel.
Adopción: A través de Azure Cloud Foundation de los Servicios de Microsoft, establezca sus diseños, patrones
y arquitectura de gobernanza principales de Azure mediante la asignación de sus requisitos a la arquitectura de
referencia más adecuada, y planee, diseñe e implemente la infraestructura, la administración, la seguridad y la
identidad necesarias para las cargas de trabajo.
Migración/optimización: La solución de modernización de la nube de los Servicios de Microsoft ofrece un
enfoque integral para trasladar aplicaciones e infraestructura a Azure, así como para optimizar y modernizar
después de la implementación en la nube con el respaldo de una migración simplificada.
Innovación: La solución Centro de excelencia en la nube (CCoE) de los Servicios de Microsoft ofrece un
compromiso de preparación para DevOps, y usa principios de DevOps combinados con controles prescriptivos
de seguridad y administración de servicios nativos de la nube para ayudar a impulsar la innovación empresarial,
aumentar la agilidad y reducir el tiempo de amortización, dentro de una funcionalidad de administración de
operaciones y entrega de servicios segura, predecible y flexible.
Compatibilidad para Azure

Si tiene alguna pregunta o necesita ayuda, cree una solicitud de soporte técnico. Si su solicitud de soporte
técnico requiere una guía técnica profunda, visite los planes de soporte técnico de Azure para alinear el mejor
plan según sus necesidades.
Asociado de soluciones de Azure
Los proveedores de soluciones certificados de Microsoft se especializan en ofrecer modernas soluciones de
cliente basadas en tecnologías de Microsoft en todo el mundo. Optimice su negocio en la nube con la ayuda de
un asociado experimentado.
Obtenga ayuda de asociados que tengan soluciones de Azure personalizadas o listas para usar, así como
asociados que puedan ayudarle a implementar y administrar esas soluciones:
Busque un asociado de soluciones en la nube. Un CSP certificado puede ayudarle a sacar el máximo
provecho de la nube mediante la evaluación de los objetivos empresariales para la adopción de la nube, la
identificación de la solución en la nube adecuada que satisface las necesidades empresariales y ayuda a la
empresa a ser más ágil y eficaz.
Encuentre un proveedor cualificado de servicios administrados de Azure. Estos proveedores ayudan a las
empresas a realizar la transición a Azure guiando todos los aspectos del recorrido de adopción de la nube.
Desde la consultoría hasta la administración de operaciones y migraciones, estos asociados muestran a los
clientes todas las ventajas que aporta la adopción de la nube. También actúan como un lugar único donde
ofrecer soporte técnico común, aprovisionamiento y la experiencia de facturación, todo ello con un modelo
empresarial de pago por uso flexible.
Pasos siguientes
Una vez que se selecciona un asociado y una estrategia de soporte técnico, los trabajos pendientes de liberación
e iteración se pueden actualizar para reflejar los esfuerzos y las asignaciones planeados.
Administración de cambios con trabajos pendientes de liberación e iteración
Administración de los cambios en un esfuerzo de
migración incremental
En este artículo se presupone que los procesos de migración son incrementales por naturaleza y que se ejecutan
en paralelo al proceso de control. Sin embargo, se podría usar la misma guía para rellenar las tareas iniciales en
una estructura de descomposición del trabajo para los enfoques tradicionales de administración de cambios en
cascada.
Trabajo pendiente de liberación

Un trabajo pendiente de liberación consta de una serie de recursos (máquinas virtuales, bases de datos, archivos
y aplicaciones, entre otros) que se deben migrar antes de que se pueda liberar una carga de trabajo para su uso
de producción en la nube. Durante cada iteración, el equipo de adopción de la nube documenta y calcula los
esfuerzos necesarios para trasladar cada recurso a la nube. Consulte la sección "Trabajo pendiente de iteración"
que aparece a continuación.
Trabajo pendiente de iteración

Un trabajo pendiente de iteración es una lista del trabajo detallado que se necesita para migrar un número
específico de recursos desde el patrimonio digital existente a la nube. Las entradas de esta lista se suelen
almacenar en una herramienta de administración ágil, como Azure DevOps, como elementos de trabajo.
Antes de iniciar la primera iteración, el equipo de adopción de la nube especifica su duración, que habitualmente
va de dos a cuatro semanas. Este tiempo asignado es importante para crear un período de tiempo de inicio y
finalización para cada conjunto de actividades confirmadas. Mantener ventanas de ejecución coherentes facilita
la medición de la velocidad (el ritmo de la migración) y la alineación con las necesidades empresariales en
constante evolución.
Antes de cada iteración, el equipo revisa el trabajo pendiente de liberación, calculando el esfuerzo y las
prioridades de los recursos que se van a migrar. A continuación, se confirma para ofrecer un número específico
de migraciones acordadas. Una vez que el equipo de adopción de la nube la acepta, la lista de actividades se
convierte en el trabajo pendiente de iteración actual.
Durante cada iteración, los miembros del equipo trabajan como un equipo de organización automática para
cumplir con los compromisos existentes en el trabajo pendiente de iteración actual.
Pasos siguientes
Una vez que se define el trabajo pendiente de iteración y el equipo de adopción de la nube lo acepta, se pueden
finalizar las aprobaciones de administración de cambios.
Aprobación de los cambios de arquitectura antes de la migración
Aprobación de los cambios de arquitectura antes de
la migración
Durante el proceso de evaluación de la migración, cada carga de trabajo se evalúa, diseña y calcula para
desarrollar un plan de estado a futuro para la carga de trabajo. Algunas cargas de trabajo se pueden migrar a la
nube sin cambiar la arquitectura. Mantener la arquitectura y la configuración local puede disminuir el riesgo y
optimizar el proceso de migración. Desafortunadamente, no todas las aplicaciones se pueden ejecutar en la
nube sin realizar cambios en la arquitectura. Cuando se requieren cambios en la arquitectura, este artículo
puede ayudarlo a clasificar el cambio y puede proporcionar alguna orientación sobre las actividades de
aprobación adecuadas.
Impacto de negocio y aprobación

Durante la migración, es probable que algunas cosas cambien de maneras que afecten a la empresa. Aunque a
veces no se pueden evitar los cambios, sí se deben evitar las sorpresas como resultado de los cambios no
divulgados o no documentados. Para mantener el respaldo de las partes interesadas a lo largo del trabajo de
migración, es importante evitar las sorpresas. Sorprender a los propietarios de aplicaciones o las partes
interesadas puede ralentizar o detener un esfuerzo de adopción de la nube.
Antes de la migración, es importante preparar al propietario empresarial de la carga de trabajo para los cambios
que podrían afectar a los procesos empresariales, como los cambios en:
Contratos de nivel de servicio.
Patrones de acceso o requisitos de seguridad que afectan al usuario final.
Prácticas de retención de datos.
Rendimiento de la aplicación principal.
Incluso cuando una carga de trabajo se puede migrar con ningún cambio, o muy pocos, podría haber un
impacto en el negocio. Los procesos de replicación pueden ralentizar el rendimiento de los sistemas de
producción. Los cambios en el entorno como preparación para la migración tienen la posibilidad de generar
limitaciones en el rendimiento de la red o el enrutamiento. Hay muchos efectos adicionales que pueden
derivarse de las actividades de replicación, almacenamiento provisional o promoción.
Las actividades de aprobación periódicas pueden ayudar a minimizar o evitar sorpresas como consecuencia de
los cambios o de los impactos de negocio generados por el rendimiento. El equipo de adopción de la nube debe
ejecutar un proceso de aprobación de cambios al final del proceso de evaluación, antes de comenzar el proceso
de migración.
Referencia cultural existente

Es probable que los equipos de TI tengan mecanismos existentes para administrar los cambios que implican los
recursos locales. Habitualmente, estos mecanismos se rigen por los procesos de administración de cambios
basados en la biblioteca de infraestructuras de tecnologías de la información (basados en ITIL) tradicionales. En
muchas migraciones de empresas, estos procesos implican a un comité de evaluación de cambios (CAB)
responsable de revisar, documentar y aprobar todas las solicitudes de cambios (RFC) relacionadas con TI.
Por lo general, el CAB incluye expertos de varios equipos de TI y empresariales, que ofrecen una amplia variedad
de perspectivas y una revisión detallada de todos los cambios relacionados con TI. Un proceso de aprobación
del CAB es una manera comprobada para reducir el riesgo y minimizar el impacto empresarial de los cambios
que implican cargas de trabajo estables administradas por las operaciones de TI.
Aprobación técnica
La disponibilidad de la organización para la aprobación de los cambios técnicos se encuentra entre las causas
más comunes de los errores del proceso de migración a la nube. Hay más proyectos detenidos por una serie de
aprobaciones técnicas que cualquier déficit en una plataforma en la nube. Preparar la organización para la
aprobación de los cambios técnicos es un requisito importante para que la migración se realice correctamente.
A continuación, se indican algunos procedimientos recomendados para garantizar que la organización está lista
para la aprobación técnica.
Desafíos del comité de evaluación de cambios de ITIL
Cada enfoque de administración de cambios tiene su propio conjunto de controles y procesos de aprobación. La
migración es una serie de cambios continuos que comienzan con un alto grado de ambigüedad y desarrollan
mayor claridad durante el curso de la ejecución. De ese modo, la migración se rige mejor por los enfoques de
administración de cambios basados en Agile, con el equipo de estrategia en la nube que actúa como propietario
del producto.
Sin embargo, la escala y la frecuencia de los cambios durante una migración a la nube no se ajustan bien a la
naturaleza de los procesos de ITIL. Los requisitos de una aprobación del CAB pueden poner en peligro el éxito de
una migración, lo que ralentiza o detiene el trabajo. Además, en las primeras fases de la migración, la
ambigüedad es alta y la experiencia en la materia tiende a ser baja. En el caso de las primeras migraciones o
liberaciones de varias cargas de trabajo, el equipo de adopción de la nube suele estar en modo de aprendizaje.
De ese, podría ser difícil para el equipo proporcionar los tipos de datos necesarios para pasar una aprobación
del CAB.
Los procedimientos recomendados siguientes pueden ayudar al CAB a mantener un grado de confort durante la
migración sin convertirse en un obstáculo bloqueador complicado.
Estandarización de los cambios
Para un equipo de adopción de la nube resulta tentador considerar decisiones de diseño detalladas para cada
carga de trabajo que se va a migrar a la nube. Es igualmente tentador usar la migración a la nube como
catalizador para refactorizar las decisiones de diseño anteriores. En el caso de las organizaciones que están
migrando cientos de máquinas virtuales o algunas docenas de cargas de trabajo, cualquiera de estos enfoques
se puede administrar correctamente. Al migrar un centro de información que consta de 1000 o más recursos,
cada uno de estos enfoques se considera un como un antipatrón de alto riesgo que disminuye
considerablemente la probabilidad de éxito. Modernizar, refactorizar y rediseñar cada aplicación requiere un
conjunto de aptitudes diversas y una gran variedad de cambios y estas tareas crean dependencias de los
esfuerzos humanos a escala. Cada una de estas dependencias inserta riesgo en el esfuerzo de migración.
En el artículo sobre la racionalización del patrimonio digital se describe la agilidad y el impacto del ahorro de
tiempo de las suposiciones básicas al racionalizar un patrimonio digital. El cambio estandarizado agrega una
ventaja adicional. Al elegir un enfoque de racionalización predeterminado para regir el esfuerzo de migración, el
comité de evaluación de la nube o el propietario del producto puede revisar y aprobar la aplicación de un
cambio a una larga lista de cargas de trabajo. Esto reduce la aprobación técnica de cada carga de trabajo a
aquellas que requieren un cambio significativo en la arquitectura para ser compatible con la nube.
Aclaración de las expectativas y los roles de los aprobadores
Antes de evaluar la primera carga de trabajo, el equipo de estrategia en la nube debe documentar y comunicar
las expectativas de cualquier persona implicada en la aprobación de los cambios. Esta sencilla actividad puede
evitar retrasos costosos cuando el equipo de adopción de la nube está totalmente comprometido.
Búsqueda anticipada de la aprobación
Cuando sea posible, el cambio técnico se debe detectar y documentar durante el proceso de evaluación.
Independientemente de los procesos de aprobación, el equipo de adopción de la nube debe ponerse en contacto
con los aprobadores al principio. Cuanto antes se pueda comenzar la aprobación de los cambios, menos
probable será que un proceso de aprobación bloquee las actividades de migración.
Pasos siguientes
Con la ayuda de estos procedimientos recomendados, debería ser más fácil integrar la aprobación adecuada y
de bajo riesgo en los esfuerzos de migración. Una vez que se aprueban los cambios en la carga de trabajo, el
equipo de adopción de la nube está listo para migrar las cargas de trabajo.
Migración de cargas de trabajo
Una vez que las cargas de trabajo se hayan evaluado, se pueden implementar en la nube o almacenar
provisionalmente para su lanzamiento. En esta serie de artículos se explican las diversas actividades que pueden
estar implicadas en esta fase del trabajo de migración.
Objetivo
El objetivo de una migración es migrar una sola carga de trabajo a la nube.
La fase de migración está completa cuando la carga de trabajo está almacenada provisionalmente y lista para
las pruebas en la nube, incluidos todos los recursos dependientes necesarios para que la carga de trabajo
funcione. Durante el proceso de optimización, la carga de trabajo se prepara para su uso en producción.
Esta definición de listo puede variar en función de los procesos de pruebas y liberación. El siguiente artículo de
esta serie trata sobre la elección de un modelo de promoción y puede ayudarle a entender cuándo sería mejor
promover una carga de trabajo migrada a producción.
Responsabilidad durante la migración

El equipo de adopción de la nube es responsable de todo el proceso de migración. No obstante, los miembros
del equipo de estrategia en la nube también tienen algunas responsabilidades como se analiza en la siguiente
sección.
Responsabilidades durante la migración

responsables:
Corrección. Resuelva los problemas de compatibilidad que impidan que la carga de trabajo se migre a la
nube.
Como ya se ha descrito en el artículo de requisitos previos acerca de la complejidad técnica y la
administración de cambios, se debe tomar una decisión de antemano para determinar cómo se
ejecuta esta actividad. Concretamente, ¿será el equipo de adopción de la nube el que complete la
corrección durante el mismo sprint que el esfuerzo de migración real? O, por el contrario, ¿se usará
una oleada o modelo de fábrica para completar la corrección en una iteración independiente? Si no
todos los miembros del equipo pueden dar una respuesta a esta pregunta básica sobre el proceso, es
recomendable que revisen la sección sobre Requisitos previos.
Replicación. Cree una copia de cada recurso en la nube para sincronizar las máquinas virtuales, los datos y
las aplicaciones con recursos en la nube.
Según el modelo de promoción, puede que se necesiten herramientas diferentes para completar esta
actividad.
Almacenamiento provisional. Una vez que todos los recursos de una carga de trabajo se han replicado y
comprobado, se puede almacenar provisionalmente la carga de trabajo para pruebas empresariales y para la
ejecución de un plan de cambios en la empresa.
Pasos siguientes
Con una comprensión general del proceso de migración, está listo para decidir sobre un modelo de promoción.
Decidir sobre un modelo de promoción
Modelos de promoción: De paso único,
almacenados provisionalmente o piloto
La migración de una carga de trabajo se suele tratar como una actividad única. En la práctica, es un conjunto de
actividades más pequeñas que facilitan el traslado de un recurso digital a la nube. Una de las últimas actividades
de una migración es la promoción de un recurso a producción. La promoción es el punto en el que el sistema de
producción cambia para los usuarios finales. A menudo, puede ser algo tan simple como cambiar el
enrutamiento de red, redirigiendo a los usuarios finales al nuevo recurso en producción. La promoción es
también el punto en el que las operaciones de TI o las operaciones en la nube cambian el foco de atención,
pasando de los procesos de administración operativa del sistema de producción anterior a los nuevos sistemas
de producción.
Hay varios modelos de promoción. En este artículo se describen tres de los más comunes que se usan en las
migraciones a la nube. La elección de un modelo de promoción cambia las actividades que se pueden ver en los
procesos de migración y optimización. Por ello, el modelo de promoción debe decidirse en una fase temprana
del lanzamiento.
Impacto del modelo de promoción en las actividades de migración y

optimización
En cada uno de los siguientes modelos de promoción, la herramienta de migración elegida replica y almacena
en un entorno provisional los recursos que conforman una carga de trabajo. Después del entorno provisional,
cada modelo trata el recurso de forma un poco diferente.
Promoción en un solo paso. En un modelo de promoción en un solo paso, el entorno provisional se
duplica como proceso de promoción. Una vez que todos los recursos están en el entorno provisional, el
tráfico de los usuarios finales se vuelve a enrutar y el entorno provisional se convierte en entorno de
producción. En este caso, la promoción forma parte del proceso de migración. Este es el modelo de
migración más rápido. Sin embargo, este enfoque dificulta la integración de actividades sólidas de
optimización y prueba. Además, en este tipo de modelo se da por hecho que el equipo de migración tiene
acceso al entorno provisional y de producción, lo que pone en peligro la separación de los deberes en
algunos entornos.
NOTE
La tabla de contenido de este sitio muestra la actividad de promoción como parte del proceso de optimización. En
un modelo en un solo paso, la promoción se produce durante la fase de migración. Al usar este modelo, los roles y
las responsabilidades se deben actualizar para reflejar esto.
Provisional. En un modelo de promoción provisional, la carga de trabajo se considera migrada cuando está
en el entorno provisional pero aún no se ha promocionado. Antes de la promoción, la carga de trabajo
migrada se somete a una serie de pruebas de rendimiento, pruebas empresariales y cambios de
optimización. Después, se promociona en una fecha futura junto con un plan de pruebas empresariales. Este
enfoque mejora el equilibrio entre el costo y el rendimiento, a la vez que facilita la obtención de validación
empresarial.
Por etapas. El modelo de promoción por etapas combina los modelos en un solo paso y provisional. En un
modelo por etapas, los recursos de la carga de trabajo se tratan como recursos de producción después de
ponerlos en el entorno provisional. Después de un período comprimido de pruebas automatizadas, el tráfico
de producción se enruta a la carga de trabajo. Sin embargo, se trata de un subconjunto del tráfico. Ese tráfico
actúa como la primera etapa de producción y pruebas. Si damos por hecho que la carga de trabajo se realiza
desde una perspectiva de características y rendimiento, se migra tráfico adicional. Una vez que todo el tráfico
de producción se ha trasladado a los nuevos recursos, la carga de trabajo se considera totalmente
promocionada.
El modelo de promoción elegido afecta a la secuencia de actividades que se van a realizar. También afecta a los
roles y responsabilidades del equipo de adopción de la nube. Incluso puede afectar a la composición de un
sprint o de varios.
Promoción en un solo paso

Este modelo utiliza herramientas de automatización de la migración para replicar recursos, enviarlos al entorno
provisional y promoverlos. Los recursos se replican en un entorno de ensayo contenido que la herramienta de
migración controla. Una vez que se han replicado todos los recursos, la herramienta puede ejecutar un proceso
automatizado para promocionarlos a la suscripción elegida en un solo paso. Mientras se encuentran en el
entorno de ensayo, la herramienta continúa replicando los recursos para minimizar la pérdida de datos entre los
dos entornos. Una vez que se promociona un recurso, se rompe la vinculación entre el sistema de origen y el
sistema replicado. En este enfoque, si se producen cambios adicionales en los sistemas de origen iniciales, se
perderán los cambios.
Ventajas. Las ventajas de este enfoque incluyen:
Este modelo introduce menos cambios en los sistemas de destino.
La replicación continua minimiza la pérdida de datos.
Si se produce un error en un proceso del entorno provisional, este puede eliminarse y repetirse rápidamente.
La replicación y las pruebas de ensayo repetidas habilitan un proceso de scripting y pruebas incremental.
Inconvenientes. Entre los aspectos negativos de este enfoque se incluyen:
Los recursos que se encuentran provisionalmente en el espacio aislado de las herramientas no permiten
modelos de prueba complejos.
Durante la replicación, la herramienta de migración consume ancho de banda en el centro de datos local.
Mantener en un entorno provisional un gran volumen de recursos durante mucho tiempo tiene un impacto
exponencial en el ancho de banda disponible, lo que perjudica al proceso de migración y puede afectar al
rendimiento de las cargas de trabajo de producción en el entorno local.
Promoción provisional
En este modelo, el espacio aislado de ensayo administrado por la herramienta de migración se usa para realizar
un número limitado de pruebas. Los recursos replicados se implementan después en el entorno en la nube, que
actúa como un entorno de ensayo extendido. Los recursos migrados se ejecutan en la nube, mientras que los
recursos adicionales se replican, se envían al entorno provisional y se migran. Cuando hay cargas de trabajo
completas disponibles, se inicia un conjunto de pruebas enriquecidas. Cuando se han migrado todos los
recursos asociados a una suscripción, la suscripción y todas las cargas de trabajo hospedadas se promocionan a
producción. En este escenario, no se produce ningún cambio en las cargas de trabajo durante el proceso de
promoción. En vez de eso, los cambios tienden a producirse en las capas de red y de identidad, los usuarios se
enrutan al nuevo entorno y se revoca el acceso del equipo de adopción de la nube.
Este modelo ofrece la posibilidad de realizar pruebas empresariales más precisas.
La carga de trabajo se puede estudiar más detenidamente para optimizar mejor el rendimiento y el costo de
los recursos.
Se puede replicar un mayor número de recursos en un límite de tiempo y de ancho de banda similar.
La herramienta de migración elegida no puede facilitar la replicación en curso después de la migración.
Se requiere un medio secundario de replicación de datos para sincronizar las plataformas de datos durante
el período provisional.
Promoción por etapas

Este modelo es similar al modelo de promoción provisional. Sin embargo, hay una diferencia fundamental.
Cuando la suscripción está lista para su promoción, el enrutamiento del usuario final se produce en fases o
etapas. En cada etapa se vuelve a enrutar a más usuarios a los sistemas de producción.
Este modelo mitiga los riesgos asociados a una gran actividad de migración o promoción. Los errores de la
solución migrada se pueden identificar con un menor impacto en los procesos empresariales.
Permite supervisar las demandas de rendimiento de la carga de trabajo en el entorno en la nube durante un
período prolongado, lo que aumenta la precisión de las decisiones sobre el tamaño de los recursos.
Se puede replicar un mayor número de recursos en un límite de tiempo y de ancho de banda similar.
La herramienta de migración elegida no puede facilitar la replicación en curso después de la migración.
Se requiere un medio secundario de replicación de datos para sincronizar las plataformas de datos durante
el período provisional.
Pasos siguientes
Una vez que el equipo de adopción de la nube define y acepta un modelo de promoción, se puede iniciar la
corrección de los recursos.
Corrección de los recursos antes de la migración
Corrección de los recursos antes de la migración
Durante el proceso de evaluación de la migración, el equipo intenta identificar cualquier configuración que
pueda hacer que un recurso sea incompatible con el proveedor de nube elegido. La corrección es un punto de
control en el proceso de migración para asegurarse de que se han resuelto esas incompatibilidades. En este
artículo se describen algunas tareas de corrección habituales a modo de referencia. También se establece un
proceso estructural para decidir si la corrección es una inversión razonable.
Tareas de corrección habituales

En cualquier entorno corporativo, existe una deuda técnica. En cierto modo, esto es algo correcto y previsible.
Puede que las decisiones con respecto a la arquitectura resultaran adecuadas para un entorno local pero no
completamente apropiadas para una plataforma de nube. En cualquier caso, es posible que se requieran tareas
habituales de corrección para preparar los recursos para la migración. Estos son algunos ejemplos:
Actualizaciones de host secundarias. En ocasiones, un host obsoleto debe actualizarse antes de la
replicación.
Actualizaciones secundarias del sistema operativo invitado. Es más probable que sea necesario
actualizar o aplicar revisiones al sistema operativo antes de la replicación.
Modificaciones en el acuerdo de nivel de ser vicio. Las operaciones de copia de seguridad y
recuperación cambian significativamente en una plataforma en la nube. Es probable que los recursos
necesiten modificaciones menores en sus procesos de copia de seguridad para garantizar que seguirán
funcionando en la nube.
Migración de PaaS. En algunos casos, puede ser necesaria una implementación de PaaS de una estructura
de datos o una aplicación para acelerar la implementación. Puede que se necesiten modificaciones menores
para preparar la solución para la implementación de PaaS.
Cambios de código para PaaS. No es infrecuente que las aplicaciones personalizadas requieran
modificaciones menores de código para estar preparadas para PaaS. Entre los ejemplos cabe incluir los
métodos que escriben en un disco local o que usan el estado de sesión en memoria.
Cambios de configuración de la aplicación. Las aplicaciones migradas pueden requerir cambios en las
variables como, por ejemplo, las rutas de acceso de red a recursos dependientes, cambios en la cuenta de
servicio o actualizaciones de direcciones IP dependientes.
Cambios menores en las rutas de acceso de red. Es posible que sea necesario modificar los patrones
de enrutamiento para enrutar correctamente el tráfico de los usuarios a los nuevos recursos.
NOTE
Este no es el enrutamiento de producción a los nuevos recursos, sino la configuración que permite el
enrutamiento correcto a los recursos en general.
Tareas de corrección a gran escala

Cuando un centro de recursos se mantiene, revisa y actualiza correctamente, es probable que se necesite poca
corrección. Los entornos en los que hay una gran necesidad de corrección tienden a ser habituales en grandes
empresas, organizaciones que han experimentado una gran reducción del departamento de TI, algunos
entornos de servicios administrados heredados y entornos con muchas adquisiciones. En cada uno de estos
tipos de entornos, la corrección puede suponer una gran parte del esfuerzo de migración. Si las siguientes
tareas de corrección aparecen con frecuencia y afectan negativamente a la velocidad o coherencia de la
migración, puede que sea conveniente dividir estas tareas de corrección en trabajos y equipos paralelos (de
forma parecida a como funcionan los procesos de adopción y de gobernanza de la nube).
Actualizaciones de host frecuentes. Si se debe actualizar un gran número de hosts para completar la
migración de una carga de trabajo, es probable que el equipo de migración sufra retrasos. Es aconsejable
dividir las aplicaciones afectadas y afrontar los pasos de corrección antes de incluir esas aplicaciones en las
versiones planeadas.
Actualización frecuente del sistema operativo invitado. Las grandes empresas suelen tener
servidores que se ejecutan en versiones obsoletas de Linux o Windows. Además del riesgo de seguridad
evidente que supone el uso de un sistema operativo obsoleto, también hay problemas de incompatibilidad
que impiden la migración de las cargas de trabajo afectadas. Si un gran número de máquinas virtuales
requiere la corrección del sistema operativo, puede que sea conveniente dividir esta tarea en trabajos
paralelos.
Cambios principales de código. Las aplicaciones personalizadas más antiguas pueden requerir un
número significativamente más elevado de modificaciones para prepararlas para la implementación de PaaS.
En este caso, puede que sea aconsejable eliminarlas por completo del trabajo pendiente de la migración y
administrarlas en un programa totalmente independiente.
Marco de decisión
Puesto que la corrección de las cargas de trabajo más pequeñas es sencilla, debe elegir una carga de trabajo
más pequeña para la migración inicial. Sin embargo, a medida que los esfuerzos de migración evolucionan y se
empieza a tratar con cargas de trabajo de mayor tamaño, la corrección puede ser un proceso lento y costoso.
Por ejemplo, los esfuerzos de corrección para una migración de Windows Server 2003 que incluye un conjunto
de recursos de más de 5000 máquinas virtuales puede retrasar una migración varios meses. Cuando se
requiere este tipo de corrección a gran escala, las siguientes preguntas pueden servir de orientación para tomar
decisiones:
¿Se han identificado todas las cargas de trabajo afectadas por la corrección y se han anotado en el trabajo
pendiente de migración?
En el caso de las cargas de trabajo que no se ven afectadas, ¿una migración puede producir una rentabilidad
de la inversión parecida?
¿Se pueden corregir los recursos afectados dentro de la escala de tiempo original de la migración? ¿Qué
impacto tendrían los cambios de la escala de tiempo en la rentabilidad de la inversión?
¿Es económicamente factible corregir los recursos en paralelo a los trabajos de migración?
¿Hay suficiente ancho de banda para efectuar la corrección y la migración? ¿Debe participar un asociado
para ejecutar una o ambas tareas?
Si estas preguntas no tienen una respuesta favorable, puede que sea conveniente considerar la posibilidad de
utilizar otros enfoques que vayan más allá de una simple estrategia de rehospedaje de IaaS:
Creación de contenedores. Algunos recursos se pueden hospedar en un entorno con contenedores sin
corrección. Esto podría generar un rendimiento inferior al deseable y no resuelve los problemas de
seguridad o de cumplimiento.
Automatización. Según los requisitos de la carga de trabajo y de la corrección, puede que sea más
beneficioso crear un script para la implementación en nuevos recursos utilizando un enfoque de DevOps.
Recompilación. Cuando los costos de la corrección son muy altos y el valor empresarial es igualmente alto,
una carga de trabajo puede ser una buena candidata para la recompilación o el rediseño de su arquitectura.
Pasos siguientes
Una vez finalizado el proceso de corrección, las actividades de replicación están listas.
Replicación de recursos
¿Qué papel desempeña la replicación en el proceso
de migración?
Los centros de datos locales se rellenan con recursos físicos como servidores, dispositivos y dispositivos de red.
Sin embargo, cada servidor es solo un shell físico. El valor real procede de los datos binarios que se ejecutan en
el servidor. Las aplicaciones y los datos constituyen el objetivo del centro de datos. Esos son los datos binarios
principales que se van a migrar. Detrás de estas aplicaciones y de los almacenes de datos se encuentran otros
recursos digitales y fuentes de datos binarios, como sistemas operativos, rutas de red, archivos y protocolos de
seguridad.
La replicación es el verdadero caballo de batalla de los trabajos de migración. Es el proceso que consiste en
copiar una versión en un momento dado de varios datos binarios. Posteriormente, las instantáneas de los datos
binarios se copian en una nueva plataforma y se implementan en un hardware nuevo, en un proceso
denominado propagación. Cuando se ejecuta correctamente, la copia propagada de los datos binarios se debe
comportar de forma idéntica a los datos binarios originales en el hardware antiguo. Sin embargo, esa
instantánea de los datos binarios deja de estar actualizada y alineada con la fuente original inmediatamente.
Para mantener alineados los nuevos datos binarios y los antiguos existe un proceso denominado sincronización
que continuamente actualiza la copia almacenada en la nueva plataforma. La sincronización continúa hasta que
se promociona el recurso según el modelo de promoción elegido. En ese momento, se interrumpe la
sincronización.
Requisitos previos necesarios para la replicación

Antes de la replicación, la nueva plataforma y el hardware deben estar preparados para recibir las copias de los
datos binarios. En el artículo sobre requisitos previos se describen los requisitos mínimos del entorno para
ayudar a crear una plataforma segura, sólida y de alto rendimiento para recibir las réplicas de los datos binarios.
Los datos binarios de origen también deben estar preparados para la replicación y la sincronización. Los
artículos sobre evaluación, arquitectura y corrección abordan cada uno las acciones necesarias para asegurarse
de que los datos binarios de origen están listos para la replicación y la sincronización.
Se debe implementar una cadena de herramientas que se alinee con la nueva plataforma y con los datos
binarios de origen para ejecutar y administrar los procesos de replicación y sincronización. En el artículo sobre
opciones de replicación se describen varias herramientas que pueden contribuir a una migración a Azure.
Riesgos de la replicación: física de la replicación

Al planear la replicación de cualquier fuente de datos binarios en un nuevo destino, hay algunas leyes
fundamentales que se deben tener en cuenta durante la planeación y la ejecución.
Velocidad de la luz. Para mover grandes volúmenes de datos, la fibra sigue siendo la opción más rápida.
Lamentablemente, este tipo de cables solo puede trasladar datos a dos tercios de la velocidad de la luz. Esto
significa que no hay ningún método para la replicación instantánea o ilimitada de datos.
Velocidad de la canalización WAN. De mayor importancia que la velocidad del movimiento de datos es
el ancho de banda del vínculo superior, que define el volumen de datos por segundo que se pueden trasladar
a través de la WAN existente de la compañía al centro de datos de destino.
Velocidad de expansión de WAN. Si el presupuesto lo permite, se puede agregar ancho de banda
adicional a la solución WAN de la empresa. Sin embargo, puede tardar semanas o meses en adquirir,
aprovisionar e integrar conexiones de fibra adicionales.
Velocidad de los discos. Aunque los datos pudieran moverse más rápidamente y no hubiera limitación del
ancho de banda entre los datos binarios de origen y el destino, aún existiría otra limitación física. Los datos
solo se pueden replicar a la velocidad a la que se pueden leer desde los discos de origen. Leer cada uno o
cada cero de todos los discos en movimiento de un centro de datos lleva tiempo.
Velocidad de los cálculos humanos. Los discos y la luz son infinitamente más rápidos que los procesos
humanos de toma de decisiones. Cuando se necesita que un grupo de personas colabore y tome decisiones
de forma conjunta, los resultados serán incluso más lentos. La replicación nunca podrá solventar los retrasos
relacionados con la inteligencia humana.
Cada una de estas leyes físicas conlleva los siguientes riesgos que pueden afectar normalmente a los planes de
migración:
Tiempo de replicación. La replicación exige tiempo y ancho de banda. Los planes deben incluir escalas de
tiempo realistas que reflejen la cantidad de tiempo que se tarda en replicar los datos binarios. El ancho de
banda total disponible para la migración es la cantidad de ancho de banda ascendente, medida en megabits
por segundo (Mbps) o gigabits por segundo (Gbps), que no consumen otras necesidades empresariales de
mayor prioridad. El almacenamiento total de migración es el espacio total en disco, medido en gigabytes o
terabytes, necesario para almacenar una instantánea de todos los recursos que se van a migrar. Se puede
calcular una estimación del tiempo inicial dividiendo el almacenamiento total de migración por el ancho de
banda total disponible para la migración. Observe la conversión de bits a bytes. Consulte el elemento
siguiente, "Efectos acumulativos del desfase del disco", para obtener un cálculo de tiempo más preciso.
Efectos acumulativos del desfase del disco. Desde el punto de replicación al de promoción de un
recurso a producción, los datos binarios de origen y destino deben estar sincronizados. El desfase de los
datos binarios consume ancho de banda adicional, ya que se deben replicar los datos binarios de forma
periódica. Durante la sincronización, se debe incluir todo el desfase de los datos binarios en el cálculo del
almacenamiento total de la migración. Cuanto más tiempo se tarde en promocionar un recurso a producción,
se acumulará un mayor desfase. Cuanto mayor es el número de recursos que se sincronizan, mayor es el
ancho de banda consumido. Con cada recurso que se mantiene en estado de sincronización, se pierde un
poco más del ancho de banda total disponible para la migración.
Tiempo para el cambio empresarial. Como se mencionó anteriormente, el tiempo de sincronización
tiene un efecto negativo acumulativo en la velocidad de la migración. La priorización del trabajo pendiente
de la migración y la preparación avanzada del plan de cambio empresarial es fundamental para la velocidad
de la migración. La prueba más significativa de la alineación técnica y empresarial durante un esfuerzo de
migración es el ritmo de promoción. Cuanto más rápido se pueda promocionar un recurso a producción,
menor será el impacto del desfase de disco en el ancho de banda y mayor será el ancho de banda y el tiempo
que se puedan asignar a la replicación de la siguiente carga de trabajo.
Pasos siguientes
Una vez completada la replicación, pueden comenzar las actividades de ensayo.
Actividades de ensayo durante una migración
Opciones de replicación
Antes de realizar cualquier migración, debe asegurarse de que los sistemas principales sean seguros y de que
continuarán ejecutándose sin problemas. Cualquier tiempo de inactividad interrumpe a los usuarios o clientes, y
cuesta tiempo y dinero. La migración no es tan sencilla como desactivar las máquinas virtuales locales y
copiarlas en Azure. Las herramientas de migración deben tener en cuenta la replicación sincrónica o asincrónica
para asegurarse de que los sistemas activos se puedan copiar en Azure sin tiempo de inactividad. Y lo más
importante de todo, los sistemas deben ir a la par con sus homólogos locales. Es posible que desee probar los
recursos migrados en particiones aisladas de Azure para asegurarse de que las cargas de trabajo funcionan
según lo previsto.
El contenido de Cloud Adoption Framework supone que Azure Migrate (o Azure Site Recovery) es la
herramienta más adecuada para replicar recursos en la nube. No obstante, hay otras opciones disponibles. En
este artículo se describen esas opciones para ayudarle con la toma de decisiones.
Azure Site Recovery (también conocido como Azure Migrate)

Azure Site Recovery orquesta y administra la recuperación ante desastres de las máquinas virtuales de Azure y
de las máquinas virtuales y servidores físicos locales. También puede usar Site Recovery para administrar la
migración de máquinas locales y de otros proveedores de nube a Azure. Replique las máquinas locales en Azure
o las máquinas virtuales de Azure en una región secundaria. Después, conmute por error la máquina virtual del
sitio principal al secundario y complete el proceso de migración. Con Azure Site Recovery, puede conseguir
varios escenarios de migración:
Migración desde un entorno local a Azure. Puede migrar las máquinas virtuales de Hyper-V locales, las
máquinas virtuales de VMware y los servidores físicos a Azure. Para ello, debe completar casi los mismos
pasos que seguiría para una recuperación ante desastres completa. Lo único que no debe hacer es una
conmutación por recuperación de las máquinas de Azure al sitio local.
Migración entre regiones de Azure. Migre las máquinas virtuales de Azure de una región de Azure a
otra. Una vez completada la migración, puede configurar la recuperación ante desastres de las máquinas
virtuales de Azure en la región secundaria a la que ha migrado.
Migración desde otra nube a Azure. Puede migrar las instancias de proceso aprovisionadas en otros
proveedores de nube a máquinas virtuales de Azure. Site Recovery trata esas instancias como servidores
físicos en lo que respecta a la migración.
Figura 1: Movimiento de recursos de Azure Site Recovery a Azure o a otras nubes.
Después de haber evaluado la infraestructura local y en la nube para la migración, Azure Site Recovery
contribuye a la estrategia de migración mediante la replicación de las máquinas locales. Con los siguientes
pasos sencillos, puede configurar la migración de las máquinas virtuales locales, los servidores físicos y las
instancias de máquina virtual en la nube a Azure:
Compruebe los requisitos previos.
Prepare los recursos de Azure.
Prepare las instancias de máquinas virtuales locales o en la nube para la migración.
Implemente un servidor de configuración.
Habilite la replicación para máquinas virtuales.
Pruebe la conmutación por error para asegurarse de que todo funciona.
Ejecute una conmutación por error única en Azure.

Este servicio ayuda a reducir la complejidad de la migración a la nube con un servicio completo en lugar de usar
varias herramientas. Azure Database Migration Service se ha diseñado como una solución integral para migrar
bases de datos de SQL Server locales a la nube sin problemas. Es un servicio totalmente administrado diseñado
para permitir migraciones completas desde varios orígenes de base de datos hasta las plataformas de datos de
Azure con un tiempo de inactividad mínimo. Integra parte de la funcionalidad de los servicios y herramientas
existentes, lo que proporciona a los clientes una solución completa y de alta disponibilidad.
El servicio utiliza Data Migration Assistant para generar informes de evaluación que proporcionen
recomendaciones que le guíen a través de los cambios necesarios antes de realizar una migración. Es decisión
suya aplicar las correcciones necesarias. Cuando esté listo para comenzar el proceso de migración, Azure
Database Migration Service realizará todos los pasos asociados. Ya puede iniciar sus proyectos de migración y
olvidarse de ellos con la tranquilidad de saber que el proceso utiliza los procedimientos recomendados que
determina Microsoft.
Pasos siguientes
Una vez completada la replicación, pueden comenzar las actividades de ensayo.
Actividades de ensayo durante una migración
Descripción de las actividades de almacenamiento
provisional durante una migración
Tal como se describe en el artículo sobre los modelos de promoción, el almacenamiento provisional es el punto
en el que se han migrado los recursos a la nube. Sin embargo, todavía no están preparados para promoverse a
producción. Este suele ser el último paso del proceso de migración de una migración. Después del
almacenamiento provisional, la carga de trabajo la administra un equipo de operaciones de TI o de operaciones
en la nube para prepararla para su uso en producción.
Resultados
Es posible que los recursos almacenados provisionalmente no estén listos para su uso en producción. Hay varias
comprobaciones de disponibilidad para la producción que se deben finalizar antes de que esta fase se considere
completa. A continuación, se muestra una lista de los resultados que se suelen asociar con la finalización de la
etapa del almacenamiento provisional de los recursos.
Pruebas automatizadas. Las pruebas automatizadas disponibles para validar el rendimiento de la carga de
trabajo deben ejecutarse antes de concluir el proceso de almacenamiento provisional. Una vez que el recurso
sale del almacenamiento provisional, se finaliza la sincronización con el sistema de origen original. Por lo
tanto, es más difícil volver a implementar los recursos replicados una vez que los recursos se almacenan
provisionalmente para su optimización.
Documentación de la migración. La mayoría de las herramientas de migración pueden generar un
informe automatizado de los recursos que se están migrando. Antes de concluir la actividad de
almacenamiento provisional, todos los recursos migrados deben documentarse para mayor claridad.
Documentación de la configuración. Cualquier cambio realizado en un recurso (durante la corrección, la
replicación o el almacenamiento provisional) debe documentarse para la disponibilidad operativa.
Documentación del trabajo pendiente. El trabajo pendiente de migración se debe actualizar para reflejar
la carga de trabajo y los recursos almacenados provisionalmente.
Pasos siguientes
Después de probar y documentar los recursos almacenados provisionalmente, puede continuar con las
actividades de optimización.
Optimización de las cargas de trabajo migradas
Una vez que una colección de cargas de trabajo y sus recursos de apoyo se han implementado en la nube, es
preciso prepararlas para poder lanzarlas. En esta fase del trabajo de migración, se realiza una prueba de carga
de las cargas de trabajo y se validan con la empresa. Luego, se optimizan y se documentan. Una vez que los
equipos de TI y de la empresa han revisado las implementaciones de las cargas de trabajo y han cerrado sesión,
las cargas se pueden lanzar o entregar a los equipos de gobernanza, seguridad y operaciones para sus
operaciones en curso.
El objetivo del "lanzamiento de las cargas de trabajo" es preparar las cargas de trabajo migradas para su uso en
producción.
El proceso de optimización estará completo cuando una carga de trabajo se haya configurado correctamente, se
haya ajustado su tamaño y se haya implementado en producción.
Responsabilidad durante la optimización

El equipo de adopción de la nube es responsable de todo el proceso de optimización. No obstante, los
miembros del equipo de estrategia en la nube, el equipo de operaciones en la nube y el equipo de gobernanza
de la nube también deben ser responsables de las actividades de este proceso.
Responsabilidades durante la optimización

responsables:
Pruebas empresariales. Resuelva los problemas de compatibilidad que impidan que la carga de trabajo
complete su migración a la nube.
Los usuarios avanzados de la empresa deben participar activamente en las pruebas de la carga de
trabajo migrada. Según el grado de optimización que haya intentado, puede que necesite varios ciclos
de pruebas.
Plan de cambio de negocio. El desarrollo de un plan para la adopción del usuario, los cambios en los
procesos empresariales y la modificación de los KPI empresariales o las métricas de aprendizaje son el
resultado del esfuerzo de migración.
Realización de pruebas comparativas y optimización. Análisis de las pruebas empresariales y de las
pruebas automatizadas para comparar el rendimiento. Según el uso, el equipo de adopción de la nube ajusta
el tamaño de los recursos implementados para equilibrar el costo y el rendimiento según los requisitos de
producción esperados.
Listo para producción. Prepare la carga de trabajo y el entorno para que sea compatible con la utilización
continua en producción de la carga de trabajo.
Promoción. Redirija el tráfico de producción a la carga de trabajo migrada y optimizada. Esta actividad
representa la finalización de un ciclo de migración.
Además de las actividades básicas, hay algunas actividades paralelas que requieren asignaciones específicas y
planes de ejecución:
Dar de baja. Por lo general, se pueden obtener ahorros en el costo de una migración, si se dan de baja los
recursos de producción anteriores y se eliminan adecuadamente.
Retrospectiva. Cada ciclo de migración crea una oportunidad de aprendizaje más profundo y la adopción
de una mentalidad de crecimiento. Cuando se completa cada ciclo de migración, el equipo de adopción de la
nube debe evaluar los procesos usados durante la migración para identificar las mejoras.
Pasos siguientes
Con un conocimiento general del proceso de optimización, estará listo para comenzar el proceso mediante el
establecimiento de un plan de cambio empresarial para la carga de trabajo candidata a la migración.
Plan de cambio empresarial
Plan de cambio de negocio
Tradicionalmente, TI supervisaba la publicación de nuevas cargas de trabajo. Durante una transformación

principal, como la migración de un centro de datos o una migración en la nube, se podría aplicar un patrón
similar de adopción de liderazgo por parte del departamento de TI. Sin embargo, el enfoque tradicional podría
pasar por alto oportunidades para obtener un valor empresarial adicional. Por este motivo, antes de que una
carga de trabajo migrada se promocione a producción, se recomienda implementar un enfoque más amplio
para la adopción de los usuarios. En este artículo se describen las formas en que un plan de cambio empresarial
se agrega a un plan estándar de adopción de los usuarios.
Enfoque tradicional de adopción de los usuarios

Los planes de adopción de los usuarios se centran en cómo adoptarán los usuarios una nueva tecnología o
cambio en una tecnología determinada. Este enfoque es de eficacia probada a la hora de presentar nuevas
herramientas a los usuarios. En un plan de adopción de los usuarios típico, el departamento de TI se centra en la
instalación, configuración, mantenimiento y entrenamiento asociados a los cambios técnicos que se van a
introducir en el entorno empresarial.
Aunque los enfoques pueden variar, los temas generales están presentes en la mayoría de los planes de
adopción de los usuarios. Estos temas se basan normalmente en un enfoque de control de riesgos y de
facilitación que se adapta a las mejoras incrementales. La matriz Eason, que se muestra en la ilustración
siguiente, representa los controladores que se encuentran detrás de estos temas en un espectro de tipos de
adopción.
Diagrama: Matriz
Eason de tipos de adopción por parte de los usuarios.
Estos temas suelen basarse en la suposición de que la introducción de nuevas soluciones para los usuarios debe
centrarse en gran medida en el control de riesgos y en facilitar el cambio. Además, el equipo de TI se suele
centrar principalmente en el riesgo de ese cambio tecnológico y en facilitar dicho cambio.
Creación de planes de cambio empresariales

Un plan de cambio empresarial va más allá del cambio técnico y presupone que cada fase de un esfuerzo de
migración promueve un cierto grado de cambio en el proceso empresarial. Analiza la situación previa y
posterior de los cambios técnicos. Las siguientes preguntas ayudan a los participantes a pensar en el proceso de
adopción por parte de los usuarios desde una perspectiva de cambio empresarial para maximizar el impacto en
la empresa:
Preguntas previas. Las preguntas previas analizan los impactos o cambios que se producen antes de que se
produzca la adopción por parte del usuario:
¿Se ha cuantificado un resultado empresarial previsible?
¿Se asigna el impacto empresarial a métricas de aprendizaje definidas?
¿Qué procesos y equipos empresariales podrán aprovechar esta solución técnica?
¿Qué persona de la empresa puede preparar mejor a los usuarios avanzados para realizar pruebas y enviar
comentarios?
¿Se ha implicado a los directivos en el planeamiento de las prioridades y de la migración?
¿Hay eventos o fechas críticas para la empresa que pudieran verse afectados por este cambio?
¿Es un plan de cambio empresarial que maximiza el impacto pero minimiza la interrupción del negocio?
¿Se prevé algún tiempo de inactividad? ¿Se ha comunicado algún período de tiempo de inactividad a los
usuarios finales?
Preguntas posteriores. Una vez completada la fase de adopción, puede comenzar el cambio empresarial.
Desafortunadamente, aquí es donde acaban muchos planes de adopción por parte de los usuarios. Las
preguntas posteriores ayudan al equipo de estrategia en la nube a centrarse en la transformación una vez
completado el cambio técnico:
¿Están respondiendo bien los usuarios empresariales a los cambios?
¿Se ha mantenido la previsión del rendimiento ahora que se ha adoptado el cambio técnico?
¿Están cambiando los procesos empresariales o las experiencias de los clientes de la manera prevista?
¿Se requieren cambios adicionales para conseguir las métricas de aprendizaje?
¿Se alinearon los cambios con los resultados empresariales que se querían conseguir? Si no es así, ¿por qué
no?
¿Es necesario algún cambio adicional para contribuir a conseguir los resultados empresariales?
¿Se ha observado algún efecto negativo como resultado de este cambio?
El plan de cambio empresarial varía de una empresa a otra. El objetivo de estas preguntas es ayudar a integrar
mejor la empresa en el cambio asociado a cada nuevo lanzamiento. Al considerar cada lanzamiento no como un
cambio de tecnología que se debe adoptar sino como un plan de cambio empresarial, se puede lograr que los
resultados de la empresa sean más viables.
Pasos siguientes
Una vez que el cambio empresarial está documentado y planeado, pueden comenzar las pruebas empresariales.
Guía sobre las pruebas empresariales (UAT) durante la migración
Referencias
Eason, K. (1988) Information technology and organizational change (Tecnologías de la información y cambios
organizativos), Nueva York: Taylor and Francis.
Guía sobre las pruebas empresariales (UAT) durante
la migración
Tradicionalmente consideradas como una función del equipo de TI, las pruebas de aceptación de usuario
durante una transformación empresarial las puede organizar exclusivamente dicho equipo. Sin embargo, esta
función se ejecuta a menudo de forma más eficaz como una función empresarial. El equipo de TI respalda esta
actividad empresarial facilitando los planes de pruebas y desarrollo, y automatizando las pruebas cuando es
posible. Aunque a menudo el equipo de TI puede actuar como suplente para las pruebas, no hay mejor sustituto
que la observación de primera mano de usuarios reales que intentan usar una nueva solución en el contexto de
un proceso empresarial real o replicado.
NOTE
Cuando están disponibles, las pruebas automatizadas son un medio mucho más eficaz de probar cualquier sistema. Sin
embargo, las migraciones en la nube a menudo se centran principalmente en sistemas heredados o en sistemas de
producción menos estables. A menudo, esos sistemas no se administran mediante pruebas automatizadas exhaustivas y
bien conservadas. En este artículo se da por supuesto que no hay ninguna de esas pruebas disponible en el momento de
la migración.
Por detrás de las pruebas automatizadas, se encuentran las pruebas de los cambios de procesos y tecnologías
por parte de usuarios avanzados. Los usuarios avanzados son las personas que normalmente ejecutan un
proceso real que requiere interacciones con una herramienta o conjunto de herramientas tecnológicas. Un
cliente externo que usa un sitio de comercio electrónico para adquirir bienes o servicios podría constituir un
buen ejemplo. Otro ejemplo de usuarios avanzados lo podría constituir un grupo de empleados que ejecutan un
proceso empresarial como, por ejemplo, un centro de llamadas que atiende a clientes y registra sus
experiencias.
El objetivo de las pruebas empresariales es solicitar la validación de los usuarios avanzados para certificar que la
nueva solución funciona según las expectativas y no impide los procesos empresariales. Si no se cumple ese
objetivo, las pruebas empresariales pueden servir como circuito de retroalimentación que puede ayudar a
definir cómo y por qué la carga de trabajo no satisface las expectativas.
Actividades del negocio durante las pruebas empresariales

Durante las pruebas empresariales, la primera iteración se controla manualmente directamente con los clientes.
Esta es la forma más pura, y la que consume más tiempo, de un circuito de retroalimentación.
Identificación de los usuarios avanzados. La propia empresa tiene generalmente una mejor percepción
de los usuarios avanzados a los que un cambio técnico puede afectar.
Alineación y preparación de los usuarios avanzados. Asegúrese de que los usuarios avanzados
entienden los objetivos de negocio, los resultados deseados y los cambios previsibles de los procesos
empresariales. Prepáreles a ellos y a su infraestructura de administración para el proceso de pruebas.
Par ticipación en la interpretación de los comentarios del circuito de retroalimentación. Ayude al
personal de TI a comprender el impacto de los distintos puntos de los comentarios de los usuarios
avanzados.
Aclaración del cambio de proceso. Si la transformación puede desencadenar un cambio en los procesos
empresariales, comunique el cambio y cualquier posible impacto en los niveles afectados.
Clasificación de los comentarios. Ayude al equipo de TI a clasificar los comentarios en función del
impacto empresarial.
En ocasiones, el equipo de TI puede emplear analistas o propietarios de productos que puedan actuar como
representantes de las actividades detalladas de las pruebas empresariales. Sin embargo, la participación
empresarial es muy recomendable y probablemente producirá resultados empresariales favorables.
Actividades del equipo de TI durante las pruebas empresariales

El equipo de TI actúa como uno de los destinatarios del resultado de las pruebas empresariales. Los ciclos de
retroalimentación expuestos durante las pruebas empresariales se convierten en elementos de trabajo que
definen el cambio técnico o el cambio de proceso. Como destinatario, se espera que el equipo de TI ayude en la
facilitación, recopilación de comentarios y administración de las acciones técnicas resultantes. Entre las
actividades habituales que realiza el equipo de TI durante las pruebas empresariales se incluyen:
Proporcionar la estructura y la logística para las pruebas empresariales.
Ayudar con la facilitación durante la realización de las pruebas.
Proporcionar un medio y un proceso para registrar los comentarios.
Ayudar a la empresa a priorizar y validar los comentarios.
Desarrollar planes para actuar sobre cambios técnicos.
Identificar las pruebas automatizadas existentes que puedan optimizar las pruebas por parte de los usuarios
avanzados.
Estudiar los procesos de las pruebas, definir pruebas comparativas y crear automatización para optimizar
aún más las pruebas de los usuarios avanzados (en el caso de cambios que requieran procesos de
implementación o prueba repetidos).
Pasos siguientes
Junto con las pruebas de negocio, la optimización de los recursos migrados puede contribuir a refinar el costo y
el rendimiento de la carga de trabajo.
Pruebas comparativas y ajuste del tamaño de los recursos de la nube
Pruebas comparativas y ajuste del tamaño de los
recursos de la nube
La supervisión del uso y el gasto es muy importante para las infraestructuras en la nube. Las organizaciones
pagan por los recursos que consumen a lo largo del tiempo. Cuando el uso supera los umbrales del contrato,
pueden acumularse gastos inesperados rápidamente. Los informes de administración de costos ayudan a
supervisar los gastos para analizar y realizar un seguimiento del uso de la nube, los costos y las tendencias. Los
informes de uso a lo largo del tiempo permiten detectar anomalías que difieren de las tendencias normales. Los
informes de optimización también permiten detectar las deficiencias en la implementación de la nube. Observe
las deficiencias en los informes de análisis de costos.
En los modelos locales tradicionales de TI, la solicitud de sistemas de TI es costosa y lenta. Los procesos
requieren a menudo ciclos de revisión de inversiones prolongados e incluso pueden requerir un proceso de
planeamiento anual. Como tal, es una práctica habitual comprar más de lo necesario. También es habitual que
los administradores de TI sobreaprovisionen los recursos para anticiparse a demandas futuras.
En la nube, los modelos de contabilidad y aprovisionamiento eliminan los retrasos de tiempo que conducen a la
adquisición excesiva. Si un recurso necesita recursos adicionales, se puede escalar vertical u horizontalmente de
forma casi instantánea. Esto significa que los activos se pueden reducir de forma segura para minimizar el
número de recursos y los costes consumidos. Durante las pruebas comparativas y la optimización, el equipo de
adopción de la nube trata de encontrar el equilibrio entre el rendimiento y los costos, aprovisionando los
recursos para que tengan justo el tamaño adecuado para satisfacer las demandas de producción.
¿Se deben optimizar los recursos durante la migración o después de

esta?
¿Un recurso se debería optimizar durante la migración o después de esta? La respuesta simple sería: en ambos
casos. Sin embargo, eso no es totalmente correcto. Para explicarlo, eche un vistazo a dos escenarios básicos de
optimización del tamaño de los recursos:
Cambio de tamaño planeado. Frecuentemente, hay recursos claramente sobredimensionados e
infrautilizados a los que se debería cambiar el tamaño durante la implementación. La determinación de si se
ha cambiado el tamaño de un recurso correctamente en este caso requiere pruebas de aceptación de usuario
después de la migración. Si un usuario avanzado no experimenta pérdidas de rendimiento o funcionalidad
durante las pruebas, puede deducir que el tamaño del recurso se ha ajustado correctamente.
Optimización. En los casos en los que la necesidad de optimización no es clara, los equipos de TI deben
usar un enfoque basado en datos con respecto a la administración del tamaño de los recursos. Mediante el
uso de pruebas comparativas del rendimiento del recurso, un equipo de TI puede tomar decisiones
fundamentadas con respecto al tamaño, los servicios, la escala y la arquitectura de una solución más
adecuados. Posteriormente, pueden cambiar el tamaño y probar las teorías de rendimiento después de la
migración.
Durante la migración, utilice conjeturas razonadas y experimente con el cambio de tamaño. Sin embargo, la
verdadera optimización de los recursos requiere datos basados en el rendimiento real de un entorno en la nube.
Para que se produzca una verdadera optimización, el equipo de TI debe implementar primero métodos para
supervisar el rendimiento y la utilización de recursos.
Pruebas comparativas y optimización con Azure Cost Management +

Billing
Azure Cost Management + Billing administra el gasto en la nube con transparencia y precisión. Este servicio
supervisa, realiza pruebas comparativas, asigna y optimiza los costos de la nube.
Los datos históricos pueden ayudar a administrar los costos mediante el análisis del uso y los gastos a lo largo
del tiempo para identificar tendencias, que a continuación se usan para pronosticar gastos futuros. La
administración de costos también incluye informes útiles de costos previstos. La asignación de costos
administra los costos mediante el análisis basado en las directivas de etiquetado. Use la asignación de costos
para el proceso de visualización completa de los gastos y contracargo, y para mostrar el uso de recursos y los
costos asociados para influir en los comportamientos de consumo o cobrar a los clientes del inquilino. El control
de acceso ayuda a administrar los costos al garantizar que los equipos y los usuarios solo tienen acceso a los
datos de administración de costos que necesitan. Las alertas ayudan a administrar los costos mediante la
notificación automática cuando se producen gastos adicionales o inusuales. También pueden notificar
automáticamente a otras partes interesadas sobre anomalías de gastos y riesgos de gastos adicionales. Existen
varios informes que admiten alertas en función de los umbrales de costo y presupuesto.
Mejorar la eficiencia
Determine el uso óptimo de las máquinas virtuales e identifique o elimine aquellas que están inactivas, y detecte
discos sin conexión con Azure Cost Management + Billing. Con la información de los informes acerca de la
optimización de tamaño y las deficiencias puede crear un plan para reducir o eliminar las máquinas virtuales
inactivas.
Pasos siguientes
Después de probar y optimizar una carga de trabajo, es el momento de preparar la carga de trabajo para la
promoción.
Preparación de una carga de trabajo migrada para la promoción a producción
Preparación de una aplicación migrada para la
promoción de producción
Después de promocionar una carga de trabajo, el tráfico de usuario de producción se enruta a los recursos
migrados. Las actividades de preparación proporcionan una oportunidad para preparar la carga de trabajo para
ese tráfico. A continuación se muestran algunas consideraciones empresariales y tecnológicas que le ayudarán a
guiar las actividades de preparación.
Validación del plan de cambio empresarial

La transformación se produce cuando los usuarios o clientes empresariales pueden beneficiarse de una solución
técnica para ejecutar procesos que impulsan la empresa. La preparación es una buena oportunidad para validar
el plan de cambio empresarial y de garantizar un entrenamiento adecuado para los equipos empresariales y
técnicos implicados. En concreto, asegúrese de que se comunican correctamente los siguientes aspectos
relacionados con la tecnología del plan de cambios:
Se completó el entrenamiento del usuario final (o al menos se planeó).
Se han comunicado y aprobado los períodos de interrupción.
Los usuarios finales han sincronizado y validado los datos de producción.
Valide la promoción y el tiempo de adopción, y asegúrese de que las escalas de tiempo y los cambios se han
comunicado a los usuarios finales.
Pruebas finales de reparación técnica

La preparación es el último paso antes de la versión de producción. Esto significa que también es la última
oportunidad de probar la carga de trabajo. A continuación se indican algunas pruebas que se sugieren durante
esta fase:
Pruebas del aislamiento de red. Pruebe y supervise el tráfico de red para garantizar el aislamiento
adecuado y las vulnerabilidades de red inesperadas. Compruebe también que cualquier enrutamiento de red
que se interrumpa durante la migración no esté experimentando tráfico inesperado.
Pruebas de dependencia. Asegúrese de que todas las dependencias de la aplicación de carga de trabajo se
han migrado y son accesibles desde los recursos migrados.
Pruebas de continuidad empresarial y recuperación ante desastres (BCDR). Compruebe que se han
establecido los SLA de copia de seguridad y recuperación. Si es posible, realice una recuperación completa
de los recursos desde la solución BCDR.
Pruebas de enrutamiento de usuarios finales. Valide los patrones de tráfico y el enrutamiento para el
tráfico de usuarios finales. Asegúrese de que el rendimiento de la red se alinee con las expectativas.
Comprobación final de rendimiento. Asegúrese de que las pruebas de rendimiento se han completado y
aprobado por los usuarios finales. Ejecute las pruebas de rendimiento automatizadas.
Validación final empresarial

Una vez validados el plan de cambio empresarial y la preparación técnica, los siguientes pasos finales pueden
completar la validación empresarial:
Validación de costos (planeados frente a reales). Es probable que las pruebas produzcan cambios en el
tamaño y la arquitectura. Asegúrese de que los precios reales de implementación siguen alineados con el
plan original.
Comunicación y ejecución del plan de migración. Antes de la migración, comunique la migración y
ejecútela en consecuencia.
Pasos siguientes
Una vez completadas todas las actividades de preparación, es el momento de promover la carga de trabajo.
¿Qué se necesita para promover un recurso migrado a producción?
¿Qué se necesita para promover un recurso
migrado a producción?
La promoción a producción marca la finalización de la migración de una carga de trabajo a la nube. Después de
promocionar el recurso y todas sus dependencias, se vuelve a enrutar el tráfico de producción. El
redireccionamiento del tráfico hace que los recursos locales sean obsoletos, lo que permite su retirada.
El proceso de promoción varía según la arquitectura de la carga de trabajo. Sin embargo, hay varios requisitos
previos coherentes y algunas tareas comunes. En este artículo se describen cada uno de ellos, y sirve como un
tipo de lista de comprobación de promoción previa.
Procesos de requisitos previos

Cada uno de los siguientes procesos debe ejecutarse, documentarse y validarse antes de la implementación de
producción:
Evaluación : La carga de trabajo se ha evaluado para la compatibilidad con la nube.
Diseño : La estructura de la carga de trabajo se ha diseñado correctamente para alinearse con el proveedor
de nube elegido.
Replicación : Los recursos se han replicado en el entorno de nube.
Preparación por fases : Los recursos replicados se han restaurado en una instancia por fases del entorno
de nube.
Pruebas empresariales : Los usuarios empresariales han probado y validado completamente la carga de
trabajo.
Plan de cambio empresarial : La empresa ha compartido un plan para que los cambios se realicen de
acuerdo con la promoción de producción. Esto debe incluir un plan de adopción de usuarios, cambios en los
procesos empresariales, usuarios que requieren entrenamiento y escalas de tiempo para diversas
actividades.
Listo : Por lo general, se deben realizar una serie de cambios técnicos antes de la promoción.
Prácticas recomendadas para ejecutar antes de la promoción

Los siguientes cambios técnicos probablemente tendrán que completarse y documentarse como parte del
proceso de promoción:
Alineación del dominio. Algunas directivas corporativas requieren dominios independientes para el
almacenamiento provisional y la producción. Asegúrese de que todos los recursos se unen al dominio
adecuado.
Enrutamiento de usuarios. Valide que los usuarios tengan acceso a la carga de trabajo mediante las rutas
de red adecuadas; compruebe las expectativas de rendimiento coherentes.
Alineación de identidad. Compruebe que los usuarios que se redirigen a la aplicación tienen los permisos
adecuados en el dominio para hospedar la aplicación.
Rendimiento. Realice una validación final del rendimiento de la carga de trabajo para minimizar las
sorpresas.
Validación de la continuidad empresarial y recuperación ante desastres. Compruebe que los
procesos de copia de seguridad y recuperación adecuados funcionan según lo previsto.
Clasificación de datos. Compruebe la clasificación de datos para asegurarse de que se han implementado
las directivas y protecciones adecuadas.
Verificación del director de seguridad de la Información. Compruebe que el responsable de
seguridad de la información ha revisado la carga de trabajo, los riesgos empresariales, la tolerancia a riesgos
y las estrategias de mitigación.
Paso final: Promoción

Las cargas de trabajo requerirán niveles variables de procesos detallados de revisión y promoción. Sin embargo,
la realineación de red sirve como el paso final común para todas las versiones de promoción. Cuando todo lo
demás esté listo, actualice los registros DNS o las direcciones IP para enrutar el tráfico a la carga de trabajo
migrada.
Pasos siguientes
La promoción de una carga de trabajo indica la finalización de una versión. Sin embargo, en paralelo con la
migración, los recursos retirados debe darse de baja del servicio.
Baja de recursos retirados
Retirar activos retirados
Después de promocionar una carga de trabajo a producción, ya no es necesario que los recursos que
hospedaban previamente la carga de trabajo de producción admitan las operaciones empresariales. En ese
momento, los recursos más antiguos se consideran retirados. Los recursos retirados se pueden dar de baja, lo
cual reducirá los costos operativos. Dar de baja un recurso puede ser tan sencillo como apagarlo y desecharlo
de manera responsable. Desafortunadamente, dar de baja los recursos a veces puede acarrear consecuencias no
deseadas. Las siguientes instrucciones pueden ayudarle a dar de baja correctamente los recursos retirados, con
interrupciones mínimas de la actividad empresarial.
Conseguir ahorros de costos

Cuando el ahorro de costos es el motivo principal de una migración, dar de baja los recursos retirados es un
paso importante. Hasta que se da de baja un recurso, este continúa consumiendo energía, apoyo ambiental y
otros recursos que generan costos. Una vez dado de baja, se empieza a conseguir un ahorro de costos.
Supervisión continuada
Después de que se promocione una carga de trabajo migrada, se debe seguir supervisando los recursos que se
van a retirar para comprobar que no hay ningún tráfico de producción adicional que se esté enrutando a los
recursos equivocados.
Períodos de prueba y validación de las dependencias

Incluso con el mejor planeamiento, es posible que las cargas de trabajo de producción sigan conteniendo
dependencias de recursos que se han retirado. En tales casos, la desactivación de un recurso retirado podría
producir errores inesperados en el sistema. Por lo tanto, la terminación de los recursos debe tratarse con el
mismo nivel de rigor que una actividad de mantenimiento del sistema. Se deben establecer períodos de
interrupción y pruebas adecuados para facilitar la terminación del recurso.
Período de conservación y validación de datos

No es raro que las migraciones pierdan datos durante los procesos de replicación. Esto es especialmente cierto
para los datos más antiguos que no se usan de forma periódica. Una vez desactivado el recurso retirado, sigue
siendo aconsejable conservar el recurso durante un tiempo para que actúe como una copia de seguridad
temporal de los datos. Las empresas deben permitir al menos 30 días para pruebas y conservación antes de
destruir los recursos retirados.
Pasos siguientes
Después de dar de baja los recursos retirados, se completa la migración. Esto crea una buena oportunidad para
mejorar el proceso de migración, y una visión retrospectiva puede hacer que el equipo de adopción de la nube
revise el lanzamiento con el fin de aprender y mejorar.
Retrospectiva
¿Cómo ayudan las retrospectivas a crear una
mentalidad de crecimiento?
"La cultura se come la estrategia para desayunar". El mejor plan de migración se puede deshacer fácilmente, en
caso de que no tenga soporte ejecutivo ni estímulo por parte del equipo de dirección. El aprendizaje, el
crecimiento e incluso los errores se encuentran en el corazón de la mentalidad de crecimiento. También se
encuentran en el centro de cualquier esfuerzo de transformación.
La humildad y la curiosidad nunca son más importantes que durante una transformación empresarial. La
adopción de la transformación digital requiere ambas en gran cantidad. Estos rasgos se refuerzan mediante una
introspección normal y un entorno de estímulo. Cuando se anima a los empleados a asumir riesgos, encuentran
mejores soluciones. Cuando se permite que los empleados generen errores y aprendan de ellos, tendrán éxito.
Las retrospectivas son una oportunidad para la investigación y el crecimiento.
Las retrospectivas refuerzan los principios de una mentalidad de crecimiento: experimentación, pruebas,
aprendizaje, uso compartido, crecimiento y capacitación. Proporcionan un lugar seguro para que los miembros
del equipo compartan los desafíos a los que se enfrentan en el sprint actual. Y permiten que el equipo discuta y
colabore en las formas de superar esos desafíos. Las retrospectivas permiten al equipo crear un crecimiento
sostenible.
Estructura retrospectiva
Una búsqueda rápida en cualquier motor de búsqueda ofrecerá muchos enfoques y herramientas diferentes
para ejecutar una retrospectiva. En función de la madurez de la cultura y el nivel de experiencia del equipo, estos
podrían resultar útiles. Sin embargo, la estructura general de una retrospectiva se mantiene aproximadamente
igual. Durante estas reuniones, se espera que cada miembro del equipo aporte un pensamiento con respecto a
tres preguntas básicas:
¿Qué salió bien?
¿Qué podría haber salido mejor?
¿Qué hemos aprendido?
Aunque estas preguntas son sencillas por naturaleza, requieren que los empleados hagan una pausa y
reflexiones sobre su trabajo en la última iteración. Esta pequeña pausa para la introspección es el componente
principal de una mentalidad de crecimiento. La humildad y honestidad que se produce al compartir las
respuestas puede ser contagiosa más allá del contrato de tiempo para la reunión retrospectiva.
Rol de liderazgo en una retrospectiva

El tema de la implicación de liderazgo en una retrospectiva es muy debatido. Muchos equipos técnicos sugieren
que los líderes de cualquier nivel no deberían implicarse en el proceso, ya que podría desaconsejar la
transparencia y abrir el diálogo. Otros sugieren que las retrospectivas son un buen lugar para que los líderes
sigan conectados y encuentren formas de proporcionar soporte técnico adicional. Esta decisión se deja mejor
para el equipo y su estructura de liderazgo.
Si los líderes están implicados en la retrospectiva, se recomienda encarecidamente que desempeñen un rol. El
deber principal del líder en una retrospectiva es hacer que el equipo se sienta seguro. Crear una mentalidad de
crecimiento dentro de una cultura requiere que los empleados puedan compartir sus fracasos y éxitos
libremente sin temor a ser reprendidos. Los líderes que aplauden el coraje y la humildad necesarios para admitir
las deficiencias tienen más probabilidades de ver establecida una mentalidad de crecimiento en sus equipos.
Cuando los líderes realizan acciones sobre los puntos de datos compartidos en una retrospectiva, es probable
que vean que esta herramienta se convierte en una formalidad ineficaz.
Lecciones aprendidas
Los equipos muy eficaces no solo ejecutan reuniones retrospectivas. Viven los procesos retrospectivos. Las
lecciones aprendidas y compartidas en estas reuniones pueden influir en el proceso, conformar el trabajo futuro
y ayudar a que el equipo funcione de forma más eficaz. Las lecciones aprendidas en una retrospectiva deben
ayudar al equipo a crecer orgánicamente. Los principales subproductos de una retrospectiva son el aumento de
la experimentación y el perfeccionamiento de las lecciones aprendidas por el equipo.
Ese nuevo crecimiento se representa de forma más tangible en los cambios del trabajo pendiente de la iteración
o de la versión.
La retrospectiva marca el final de una versión o iteración, a medida que los equipos adquieren experiencia y
aprenden lecciones, y ajustan el trabajo pendiente de la iteración o de la versión para reflejar los nuevos
procesos y experimentos que se van a probar. Esto inicia la siguiente iteración mediante los procesos de
migración.
Preparación de las aptitudes para la migración a la
nube
Durante una migración a la nube, es probable que los empleados, así como algunos asociados de integración de
sistemas o asociados de servicios administrados, deban desarrollar nuevas aptitudes para que sean eficaces
durante los trabajos de migración.
Hay cuatro procesos distintos que se completan de forma iterativa en la metodología de migración. En las
secciones siguientes se alinean las aptitudes necesarias para cada uno de esos procesos con referencias a dos
requisitos previos para los recursos de desarrollo de aptitudes.
Requisitos previos de los recursos de desarrollo de aptitudes

La implementación de la metodología de migración se basa en las aptitudes adquiridas durante el planeamiento
y la preparación del recorrido de la migración.
Evaluación de los recursos de desarrollo de aptitudes

Las siguientes herramientas pueden ayudar al equipo a ejecutar las actividades de evaluación:
Equilibrar la cartera: garantice el equilibrio y las asignaciones de inversión adecuadas en una cartera de
aplicaciones.
Elaboración de una justificación comercial: elabore y comprenda la justificación comercial que impulsa el
esfuerzo de migración a la nube.
Racionalización del patrimonio digital: racionalice los recursos del patrimonio digital.
Evaluación de la cartera de aplicaciones: criterios para tomar decisiones relacionadas con las opciones de
migración o innovación dentro de la cartera de aplicaciones.
Evaluación y planeamiento de la migración a Microsoft Azure: curso de PluralSight para ayudar a evaluar las
cargas de trabajo locales.
Durante los procesos de evaluación, los arquitectos diseñarán soluciones para cada carga de trabajo. Los
siguientes recursos de desarrollo de aptitudes ayudan a preparar a los arquitectos para estas tareas:
Arquitectura de Microsoft Azure: Introducción: curso de Pluralsight para proporcionar a los arquitectos un
conocimiento básico de la arquitectura de Azure.
Migración de los recursos de desarrollo de aptitudes

El tutorial siguiente puede preparar al equipo para las actividades de migración:
Migración a Azure: use Azure Migrate para migrar máquinas virtuales a Azure.
Rehospedaje de cargas de trabajo en Azure: curso de PluralSight que enseña a los espectadores a rehospedar
las cargas de trabajo en Azure.
Migración de servidores físicos y virtuales a Azure: curso de PluralSight para migrar servidores a Azure.
Importación y exportación de datos a Azure: curso de PluralSight sobre el traslado de datos hacia y desde
Azure.

Las herramientas siguientes pueden ayudar al equipo a optimizar los recursos y promoverlos a producción:
Costo y ajuste de tamaño: ajuste del tamaño para alinear los costos y presupuestos.
Promoción de una carga de trabajo: cambie la configuración de la red para volver a enrutar los usuarios de
producción a las cargas de trabajo migradas.

Las herramientas siguientes pueden ayudar al equipo a encontrar formas de proteger y administrar los recursos
migrados:
Protección y administración de cargas de trabajo en Azure: procedimientos recomendados para proteger y
administrar cargas de trabajo en Azure.
Pasos siguientes
Vuelva a la lista de comprobación de procedimientos recomendados de migración para asegurarse de que el
método de migración está totalmente alineado.
Innovación relacionada con la adopción de la nube
Todas las carteras de TI contienen varias cargas de trabajo e ideas que pueden mejorar considerablemente la
posición de una empresa en el mercado. La mayor parte de los esfuerzos de adopción de la nube se centran en
la migración y modernización de las cargas de trabajo existentes. Sin embargo, la innovación en la nube puede
proporcionar el máximo valor empresarial. La innovación relacionada con la adopción de la nube puede
desbloquear nuevas aptitudes técnicas y ampliar las funcionalidades empresariales.
Esta sección de Cloud Adoption Framework se centra en los elementos de la que más rentabilidad de la
inversión generan.
Para prepararse para esta fase del ciclo de vida de la adopción de la nube, el marco sugiere los siguientes
ejercicios de innovación de la nube:
Consenso del valor empresarial: antes de decidir qué

soluciones técnicas va a usar, identifique la forma en que la
innovación en la nube puede potenciar el valor empresarial.
Asigne ese valor a su estrategia en la nube. En esta
metodología incremental, el valor empresarial se representa
mediante una hipótesis acerca de las necesidades del cliente.
Guía de innovación de Azure: Azure incluye herramientas de

innovación en la nube que aceleran la implementación de
soluciones innovadoras. En función de lo que necesite, puede
plantearse varias combinaciones de herramientas. Se
recomienda crear un producto viable mínimo con
herramientas básicas.
Procedimientos recomendados: Las decisiones

arquitectónicas deberían seguir los procedimientos
recomendados en todas las herramientas de la cadena. Si se
ciñe a esta guía, acelerará más el desarrollo de soluciones y
proporcionará una referencia para la creación de diseños
arquitectónicos sólidos.
Bucles de comentarios: Durante cada iteración de desarrollo,

las soluciones en desarrollo ofrecen a los equipos aprender la
posibilidad de aprender al mismo tiempo que sus clientes.
Unos bucles de comentarios con los clientes rápidos y
precisos le ayudan a probar, medir, aprender y reducir el
impacto del tiempo necesario para la comercialización. Más
información acerca de la forma en que Azure y GitHub
aceleran los bucles de comentarios.
Resumen de la innovación
En la innovación en la economía digital se establece un lenguaje común para la innovación en la nube en los
equipos de desarrollo de aplicaciones, DevOps, TI y empresariales. El enfoque siguiente se basa en metodologías
lean existentes. Está diseñado para ayudarle a crear una conversación centrada en la nube acerca de la adopción
por parte del cliente y un modelo científico para crear valor empresarial. El enfoque también asigna los actuales
servicios de Azure a procesos de toma de decisiones administrables. Esta alineación puede ayudarle a encontrar
las opciones técnicas correctas para satisfacer las hipótesis o necesidades específicas del cliente.
Aptitudes sugeridas
La preparación para las nuevas aptitudes y responsabilidades que acompañan a la adopción de la nube no es
fácil. Microsoft Learn proporciona un enfoque gratificante para el aprendizaje práctico que le ayuda a lograr sus
objetivos con más rapidez. Gane puntos y niveles y consiga más.
A continuación, se muestran un par de ejemplos de rutas de aprendizaje específicas de roles de Microsoft Learn
que se alinean con la metodología de innovación de Cloud Adoption Framework.
Administración de contenedores en Azure: Azure Container Instances es la forma más rápida y sencilla de
ejecutar contenedores en Azure. Esta ruta de aprendizaje le enseñará no solo a crear y administrar los
contenedores, sino también cómo se puede usar Azure Container Instances para proporcionar una escala
elástica para Kubernetes.
Cree aplicaciones sin servidor: Azure Functions permite la creación sistemas de proceso a petición y basados en
eventos que pueden desencadenar varios eventos externos. Aprenda a usar Functions para ejecutar la lógica del
servidor y crear arquitecturas sin servidor.
Para descubrir más rutas de aprendizaje, eche un vistazo al catálogo de Microsoft Learn. Use el filtro Roles para
Introducción a la guía de soluciones innovadoras de
Azure
NOTE
Esta guía de soluciones innovadoras ofrece un punto de partida para la guía de innovación en Cloud Adoption
Framework. También está disponible en el Centro de inicio rápido de Azure.
Antes de empezar a desarrollar soluciones innovadoras mediante los servicios de Azure, es preciso preparar el
entorno, lo que incluye la preparación de la administración de los bucles de comentarios de los clientes. En esta
guía se presentan características que le ayudan a captar clientes, crear soluciones innovadoras e impulsar la
adopción. Para más información, procedimientos recomendados y consideraciones relacionados con la
preparación de un entorno en la nube, consulte la sección Innovación en la nube en Cloud Adoption Framework.
En esta guía de innovación, aprenderá a:
Administrar los comentarios de los clientes: configure las herramientas y procesos necesarios para
administrar el bucle de comentarios crear-medir-aprender mediante GitHub y Azure DevOps.
Democratizar los datos: los datos por sí solos pueden ser suficientes para impulsar soluciones
innovadoras para sus clientes. Implemente opciones de datos comunes en Azure.
Par ticipación a través de aplicaciones: la innovación requiere una experiencia atractiva. Use las
plataformas de aplicaciones nativas en la nube para crear experiencias atractivas.
Capacitar la adopción: la invención es excelente, pero se necesita un plan que reduzca la fricción para
capacitar y escalar la adopción. Implemente una base para CI/CD, DevOps y otros habilitadores de la
adopción.
Interactuar mediante dispositivos: cree experiencias ambientales que acerquen sus aplicaciones y datos
a las necesidades de los clientes. IoT, la realidad mixta y las experiencias móviles son más fáciles con Azure.
Predecir e influir : busque patrones en los datos. Con esos patrones puede predecir e influir en los
comportamientos de los clientes mediante herramientas el uso de análisis predictivo basadas en Azure.
TIP
Para una experiencia interactiva, consulte esta guía en Azure Portal. Vaya al Centro de inicio rápido de Azure en
Azure Portal, seleccione Guía de innovación de Azure y, después, siga las instrucciones paso a paso.
Pasos siguientes:
Prepárese para la innovación con un repositorio compartido y herramientas de administración de la
conceptualización
Preparación para los comentarios de los clientes
La adopción del usuario, el compromiso y la retención son clave para la innovación correcta. ¿Por qué?
La creación de una nueva solución innovadora no consiste en ofrecer a los usuarios lo que desean o lo que
pensamos que desean. Se trata de la formulación de una hipótesis que se pueda probar y mejorar. Las pruebas
se incluyen en dos formatos:
Cuantitativas (comentarios sobre la prueba): estos comentarios miden las acciones que esperamos ver.
Cualitativas (comentarios del cliente): estos comentarios nos indican lo que significan las métricas
desde el punto de vista del cliente.
Los datos cuantitativos se basan en números y usan un proceso de medida cuantificable. Los comentarios
cuantitativos proporcionan información numérica sobre los datos, lo cual resulta útil para recopilar rápidamente
un gran número de respuestas de los clientes. Algunos ejemplos de comentarios cuantitativos serían preguntas
de tipo test y datos numéricos de involucración del usuario. Los comentarios cualitativos son más detallados y
permiten obtener una variedad más amplia de respuestas e información sobre los pensamientos o las opiniones
de los clientes. Algunos ejemplos de comentarios cualitativos serían una encuesta a clientes con preguntas
abiertas. Ambos métodos relacionados con los comentarios de los clientes proporcionan una información
valiosa para mejorar los productos y servicios de la empresa.
Antes de integrar bucles de comentarios, debe tener un repositorio compartido para la solución. Un repositorio
centralizado proporcionará una manera de registrar todos los comentarios que se emiten sobre el proyecto, así
como actuar sobre estos. GitHub es el lugar principal para encontrar software de código abierto. También es una
de las plataformas que se usan con más frecuencia para hospedar los repositorios de código fuente para
aplicaciones que se desarrollan comercialmente. El artículo sobre creación de repositorios de GitHub puede
ayudarle a empezar a trabajar con su repositorio.
Cada una de las siguientes herramientas de Azure se integra (o es compatible) con proyectos hospedados en
GitHub:
Comentarios cuantitativos para aplicaciones web

Comentarios cuantitativos para API
Comentarios cualitativos
Cierre del bucle con canalizaciones
Application Insights es una herramienta de supervisión que proporciona comentarios cuantitativos casi en
tiempo real sobre el uso de su aplicación. Estos comentarios pueden ayudarle a probar y validar la hipótesis
actual para dar forma a la siguiente característica o caso de usuario en el trabajo pendiente.
Acción
Para ver los datos cuantitativos en las aplicaciones:
1. Vaya a Application Insights .
Si la aplicación no aparece en la lista, seleccione Agregar y siga las indicaciones para iniciar la
configuración de Application Insights.
Si la aplicación deseada está en la lista, selecciónela.
2. En el panel Información general se incluyen algunas estadísticas sobre la aplicación. Seleccione Panel de
la aplicación para crear un panel personalizado con los datos más importantes para su hipótesis.
G O TO A P P L I C ATI O N
I N S I G H TS
Para ver los datos sobre sus aplicaciones, vaya a Azure Portal.
Más información
Configuración de Azure Monitor
Introducción a Azure Monitor Application Insights
Compile un panel de telemetría
La democratización de datos es la capacidad de hacer que la información digital sea accesible para el usuario
medio con poco conocimientos técnicos de los sistemas de información, sin necesidad de un equipo selector ni
ayuda externa para acceder a los datos. La democratización de datos ayuda a los usuarios a conseguir un acceso
ilimitado a datos importantes sin crear un cuello de botella que impida la productividad.
Uno de los primeros pasos para la democratización de datos es mejorar la detectabilidad de los datos. Catalogar
y administrar los datos compartidos puede ayudar a las empresas a sacar el máximo partido de sus recursos de
información existentes. Mediante la democratización, un catálogo de datos facilita que los usuarios que
administran los datos puedan detectar y comprender los orígenes de datos. Azure Data Catalog permite la
administración dentro de una empresa, mientras que Azure Data Share permite la administración y el uso
compartido fuera de la empresa.
Los servicios de Azure que proporcionan procesamiento de datos como Azure Time Series Insights y Stream
Analytics son otras funcionalidades que los clientes y asociados usan correctamente en sus necesidades de
innovación.
Catálogo
Compartir
Insights
Azure Data Catalog

Azure Data Catalog aborda los desafíos de detección de los consumidores de datos, además de permitir a los
productores de datos mantener los recursos de información. Tiende un puente entre el personal de TI y la
empresa, y permite que todo el mundo aporte sus conocimientos. Puede almacenar los datos donde quiera y
conectarse con las herramientas que prefiera usar. Con Azure Data Catalog, puede controlar quién puede
detectar los recursos de datos registrados. Use las API de REST abiertas para integrar el servicio con las
herramientas y los procesos que ya utiliza.
Register
Buscar y anotar
Conectar y administrar
Consulte la documentación de Azure Data Catalog
Acción
Solo se puede usar una instancia de Azure Data Catalog por organización. Si su organización ya cuenta con un
catálogo, no podrá agregar más.
Para crear un catálogo para su organización:
1. Vaya a Azure Data Catalog .
G O TO A Z U R E D ATA
C ATA L O G
Interacción con los clientes mediante aplicaciones
Cree aplicaciones nativas de nube para conectar a los clientes de nuevas maneras. Las aplicaciones nativas de la
nube se crean desde cero y están optimizadas para la escala y el rendimiento de la nube. Las aplicaciones
nativas de nube, se basan en arquitecturas de microservicios, utilizan servicios administrados y se benefician de
la entrega continua para conseguir confiabilidad y una comercialización más rápida.
La innovación con aplicaciones incluye la modernización de las aplicaciones existentes hospedadas en el
entorno local y la compilación de aplicaciones nativas de la nube con contenedores o tecnologías sin servidor.
Azure proporciona servicios PaaS, como Azure App Service, para ayudar a modernizar fácilmente las
aplicaciones web y de API existentes escritas en .NET, .NET Core, Java, Node.js, Ruby, Python o PHP para su
implementación en Azure.
Con un modelo de contenedor de estándar abierto, la creación de microservicios o la inclusión en contenedores
de sus aplicaciones actuales y su implementación en Azure son sencillas cuando se usan servicios
administrados, como Azure Kubernetes Service, Azure Container Instances y Web App for Containers. Las
tecnologías sin servidor como Azure Functions y Azure Logic Apps usan un modelo de consumo (pago por lo
que se usa) y ayudan a centrarse en la compilación de la aplicación, en un lugar de implementar y administrar la
infraestructura.
Entregar valor más rápido
Creación de aplicaciones nativas de la nube
Aislar puntos de error
Una de las ventajas de las soluciones basadas en la nube es la capacidad de recopilar comentarios más rápido y
de comenzar a entregar valor al usuario. Si ese usuario es un cliente externo o un usuario de su propia empresa,
cuanto más rápido pueda obtener comentarios sobre sus aplicaciones, mejor.
Azure App Service
Azure App Service proporciona un entorno de hospedaje para las aplicaciones que elimina la carga de
administración de la infraestructura y la aplicación de revisiones del sistema operativo. Permite la
automatización del escalado para satisfacer las demandas de los usuarios, pero debe cumplir con los límites que
defina para mantener los costos en la comprobación.
Azure App Service ofrece compatibilidad de primera clase con lenguajes de programación como ASP.NET,
ASP.NET Core, Java, Ruby, Node.js, PHP y Python. Si necesita hospedar otra pila en tiempo de ejecución, Web
App for Containers le permite hospedar de forma rápida y sencilla un contenedor de Docker en App Service, de
modo que pueda hospedar la pila de código personalizada en un entorno fuera de la empresa del servidor.
Acción
Para configurar o supervisar las implementaciones de Azure App Service:
1. Vaya a App Ser vices .
2. Configure un nuevo servicio: seleccione Agregar y siga las indicaciones.
3. Administre los servicios existentes: seleccione la aplicación deseada de la lista de aplicaciones hospedadas.
G O TO A P P
S E R V IC E S
Azure Cognitive Services

Con Azure Cognitive Services, puede incorporar la inteligencia avanzada directamente en su aplicación a través
de un conjunto de API que le permite aprovechar los algoritmos de aprendizaje automático y de IA respaldados
por Microsoft.
Acción
Para configurar o supervisar las implementaciones de Azure Cognitive Services:
1. Vaya a Cognitive Ser vices .
3. Administre los servicios existentes: seleccione el servicio que desee de la lista de servicios hospedados.
G O TO C O G N I TI V E
S E R V IC E S
Azure Bot Service

Para ampliar su aplicación estándar, Azure Bot Service agrega una interfaz de bot natural que usa IA y Machine
Learning para crear una nueva manera de interactuar con sus clientes.
Acción
Para configurar o supervisar las implementaciones de Azure Bot Service:
1. Vaya a Ser vicios de Bot .
3. Administre los servicios existentes: seleccione el bot que desee de la lista de servicios hospedados.
G O TO B O T
S E R V IC E S
Azure DevOps
Durante el recorrido de innovación, con el tiempo se encontrará en la ruta de acceso a DevOps. Microsoft ya ha
tenido un producto local conocido como Team Foundation Server (TFS). Durante nuestro propio recorrido de
innovación, Microsoft desarrolló Azure DevOps, un servicio basado en la nube que proporciona herramientas de
compilación y lanzamiento que admiten muchos lenguajes y destinos diferentes para sus versiones. Para más
información, consulte Azure DevOps.
Visual Studio App Center
A medida que las aplicaciones móviles continúan creciendo en popularidad, crece la necesidad de una
plataforma que pueda proporcionar pruebas automatizadas en dispositivos reales de diversas configuraciones.
Visual Studio App Center no solo proporciona un lugar en el que puede probar sus aplicaciones nativas de nube
en iOS, Android, Windows y macOS, sino que también proporciona una plataforma de supervisión que puede
utilizar Azure Application Insights para analizar los datos de telemetría de forma rápida y sencilla. Para más
información, consulte Visual Studio App Center.
Visual Studio App Center también proporciona un servicio de notificación que le permite usar una sola llamada
para enviar notificaciones a la aplicación entre plataformas sin tener que ponerse en contacto con cada servicio
de notificación de forma individual. Para obtener más información, consulte Visual Studio App Center Push
(ACP).
Más información
Información general de App Service
Web App for Containers: ejecutar un contenedor personalizado
Introducción a Azure Functions
Azure para desarrolladores de .NET y .NET Core
Azure SDK para la documentación Python
Azure para desarrolladores de Java Cloud
Creación de una aplicación web de PHP en Azure
Documentación de Azure SDK para JavaScript
Documentación de Azure SDK para Go
Soluciones de DevOps
Capacitación para la adopción de la nube
Como sabe, la innovación y la transformación digital son fundamentales para el éxito empresarial. La
transformación digital consiste en la adopción de tecnologías basadas en la nube y tecnologías digitales para
reemplazar los sistemas antiguos y crear unas mejores experiencias para los clientes, una mayor eficacia,
información empresarial y una mayor innovación a partir de los datos. La innovación no se logra únicamente a
través de la introducción de nuevas tecnologías. Debe centrarse en respaldar a las personas que catalizan el
cambio y crean el nuevo valor que busca. Los desarrolladores están en el centro de la transformación digital y,
para ayudarles a mejorar sus logros, es necesario acelerar la velocidad del desarrollador. Para liberar la energía
creativa de los equipos de desarrolladores, debe ayudarles a compilar de forma productiva, fomentar la
colaboración global segura y eliminar las barreras para que puedan escalar la innovación.
Generar valor
En todos los sectores, todas las organizaciones intentan hacer algo: impulsar la generación de valores
constante.
Centrarse en la innovación es esencialmente un proceso que le ayuda a su organización a encontrar nuevas
formas de generar valor.
Quizás el mayor error que cometen las organizaciones es introducir nuevas tecnologías para intentar
generar valor nuevo.
A veces, la actitud es "si solo usamos más tecnología, veremos que las cosas mejoran". Sin embargo, la
innovación es ante todo una historia de personas.
La innovación es un asunto de la combinación de personas y tecnología.
Las organizaciones que innovan correctamente hacia la transformación digital ven la visión, la estrategia, la
cultura, el potencial único y las capacidades como elementos fundamentales. Luego, recurren a la tecnología con
un propósito específico en mente. Cada empresa está convirtiéndose en una compañía de software. La
contratación de ingenieros de software está creciendo a un ritmo más rápido fuera del sector tecnológico que
dentro, según datos de LinkedIn.
La innovación se logra cuando las organizaciones permiten a sus usuarios crear el valor que buscan. Un grupo
de usuarios de este tipo, el de desarrolladores, funciona como catalizador para la innovación. Desempeñan un
papel cada vez más importante en la creación y el crecimiento de los valores en todo el sector. Son los creadores
de nuestra era, quienes escriben el código del mundo y se sitúan en el corazón de la innovación. Las
organizaciones innovadoras crean una cultura que permite a los desarrolladores obtener más.
Productividad de los desarrolladores

Innovar en colaboración
Características de la innovación
Innovación de LiveOps
Velocidad de desarrollador
Permitir a los desarrolladores inventar significa acelerar la velocidad del desarrollador, lo que les permite crear
más, innovar más y resolver más problemas. La velocidad del desarrollador es la base de la intensidad
tecnológica de cada organización. La velocidad del desarrollador no es solo cuestión de rapidez. También guarda
relación con el impulso del ingenio del desarrollador, para convertir su ideas en software con velocidad y
agilidad, de modo que se puedan crear soluciones innovadoras. La solución diferenciada de Azure goza de una
posición única para facilitar la innovación y la adopción de la nube en su organización.
Compilación de manera productiva
Existen varias áreas de oportunidad en las que Azure puede ayudarle a compilar de manera productiva:
Asegurarse de que los desarrolladores se convierten en expertos en su dominio y lo siguen siendo gracias a
la ayuda para fomentar su conocimiento.
Mejore las habilidades adecuadas con las herramientas adecuadas.
Una de las mejores formas de mejorar las aptitudes de los desarrolladores es proporcionarles herramientas que
conocen y adoran. Las herramientas de Azure se adaptan a las que los desarrolladores utilizan hoy en día y los
introducen en las nuevas tecnologías de transformación digital en el contexto del código que están escribiendo.
Con el compromiso de Azure con el software de código abierto y la compatibilidad con todos los lenguajes y
marcos de sus herramientas, los desarrolladores pueden compilar lo que quieran e implementarlo donde
quieran.
Azure DevOps proporciona las mejores herramientas para cada desarrollador. Los servicios para
desarrolladores de Azure y los de transformación digital incorporan procedimientos de desarrollo modernos y
tendencias emergentes en nuestras herramientas. Con la plataforma Azure, los desarrolladores tienen acceso a
las tecnologías más recientes y a una cadena de herramientas de vanguardia que admite la forma en que
trabajan.
Herramientas de desarrollo asistido por IA
Herramientas y nube integradas
Desarrollo remoto y programación en pareja
Vaya a la documentación de Azure DevOps
Acción
Para crear un proyecto de DevOps:
1. Vaya a Azure DevOps Projects .
2. Seleccione Crear un proyecto de DevOps .
3. Seleccione Runtime, Marco y Ser vicio .
G O TO A Z U R E D E V O P S
P R O J E C TS
Interacción mediante dispositivos conectados
Innove mediante dispositivos conectados intermitentemente y dispositivos perimetrales perceptivos. Organice

millones de estos dispositivos, adquiera y procese datos sin límites y aproveche las ventajas de un número cada
vez mayor de experiencias multidispositivos y multisentidos. En el caso de los dispositivos en el borde de la red,
Azure proporciona un marco para crear soluciones empresariales envolventes y eficaces. Con la informática
omnipresente, hecha realidad gracias a Azure en conjunto con la tecnología IA, puede compilar todos los tipos
de aplicación y sistema inteligentes que pueda idear.
La computación ubicua es el procesamiento de la información que conecta dispositivos y procesadores que
permite tener disponibilidad constante, de modo que la computación y el procesamiento puedan aparecer en
cualquier momento y lugar en el que se necesiten, mediante cualquier dispositivo conectado o dispositivo
perimetral perceptivo. Entre los ejemplos de computación ubicua se pueden incluir todos los sistemas que
envían información a otro sistema para completar una tarea sin interrupciones, como un reloj de actividad física
que alerta de que hay una llamada entrante de un teléfono móvil y que permite atender la llamada mediante el
reloj, o los sistemas que "aprenden y se ajustan" como un termostato o unos altavoces inteligentes.
Los clientes de Azure emplean un conjunto de sistemas y dispositivos conectados en constante expansión que
recaba y analiza datos (cerca de los usuarios, de los datos o de ambos) con una administración de dispositivos
completa. Los usuarios obtienen conclusiones y experiencias en tiempo real, a través de aplicaciones con gran
capacidad de respuesta y conscientes del contexto. Al mover elementos de la carga de trabajo al perímetro,
estos dispositivos conectados pueden dedicar menos tiempo a enviar mensajes a la nube y reaccionar más
rápidamente a los eventos espaciales.
Recursos industriales
Microsoft HoloLens 2
Azure Sphere
Azure Kinect DK
Drones
Azure SQL Edge
IoT Plug and Play
Servicio de IoT a escala global

Azure Digital Twins
Inteligencia de ubicación
Experiencias espaciales
Azure Remote Rendering
Diseñe soluciones que ejerzan comunicación bidireccional con dispositivos de IoT a escala de miles de millones.
Utilice datos de telemetría enviados desde el dispositivo a la nube listos para usar para determinar el estado de
sus dispositivos y definir rutas de mensajes hacia otros servicios de Azure solo con la configuración. Al
aprovechar los mensajes enviados de la nube al dispositivo, puede enviar comandos y notificaciones de forma
confiable a los dispositivos conectados y realizar un seguimiento de la entrega de los mensajes con acuses de
recibo. Los mensajes de los dispositivos se reenviarán automáticamente según sea necesario para ajustarse a
una conectividad intermitente.
Estas son algunas de las características que encontrará:
Canal de comunicación con seguridad mejorada para enviar y recibir datos desde los dispositivos de IoT.
Administración de dispositivos integrada y aprovisionamiento para conectarse y administrar
dispositivos IoT y perimetrales a escala.
Integración total con Event Grid y la informática sin servidor, para simplificar el desarrollo de
aplicaciones de IoT.
Compatibilidad con Azure IoT Edge para crear aplicaciones de IoT híbridas.
Más información
Azure IoT Hub
Azure IoT Hub Device Provisioning Service (DPS)
Use nuestro proyecto de Azure DevOps de IoT moderno para facilitar el proceso de administración de
elementos de trabajo.
Acción
Para crear un centro de IoT:
1. Vaya a IoT Hub .
2. Seleccione Crear IoT Hub .
G O TO I O T
HUB
Azure IoT Hub Device Provisioning Service es un servicio auxiliar de Azure IoT Hub que permite un
aprovisionamiento Just-In-Time, sin interacción.
Acción
Para crear una instancia de Azure IoT Hub Device Provisioning Service:
1. Vaya a Ser vicios Device Provisioning .
G O TO D E V I C E P R O V I S I O N I N G
S E R V IC E S
Innovación con IA en Azure
Como innovador, su empresa tiene abundante información sobre su negocio y sus clientes. Mediante la
innovación con inteligencia artificial, su empresa puede:
Realizar predicciones sobre las necesidades de los clientes.
Automatizar los procesos empresariales.
Detectar la información latente en datos no estructurados.
Interactuar de nuevas formas con los clientes para ofrecer mejores experiencias.
En este artículo se presentan algunos enfoques para innovar con IA. Las innovaciones pueden ampliar la
información empresarial que se obtiene a partir de los datos existentes. La tabla siguiente puede resultar útil a la
hora de encontrar la mejor solución en función de las necesidades de implementación.
C AT EGO RÍA DE L A SO L UC IÓ N DESC RIP C IÓ N A P T IT UDES N EC ESA RIA S
Machine Learning Azure Machine Learning Científico de datos y desarrollador

Cree, implemente y administre sus
propios modelos de Machine Learning.
Aplicaciones y agentes de IA Azure Cognitive Ser vices Desarrollador

Use modelos de inteligencia artificial
específicos de dominio para la visión, la
voz, el lenguaje y la decisión que se
pueden personalizar con los datos.
Azure Bot Ser vice

Mejore la involucración del cliente
agregando bots a aplicaciones y sitios
web.
Minería de conocimientos Azure Cognitive Search Desarrollador

Descubra información latente en el
contenido, incluidos documentos,
contratos, imágenes y otros tipos de
datos.
Machine Learning
Azure proporciona funcionalidades avanzadas de aprendizaje automático. Compile, entrene e implemente los
modelos de Machine Learning en toda la nube y el entorno perimetral con Azure Machine Learning. Desarrolle
modelos con más rapidez mediante el aprendizaje automático automatizado. Use las herramientas y los marcos
de trabajo que prefiera sin que se bloquee.
Para más información, consulte Información general sobre Azure Machine Learning e Introducción al primer
experimento de aprendizaje automático. Para más información sobre el formato de modelo de código abierto y
el runtime para el aprendizaje automático, consulte ONNX Runtime.
Acción
Un científico de datos puede usar Azure Machine Learning para entrenar y compilar un modelo mediante
lenguajes avanzados como Python y R, así como usar una experiencia visual de arrastrar y colocar. Para empezar
a usar Azure Machine Learning:
1. En Azure Portal, busque y seleccione Machine Learning .
2. Seleccione Agregar y siga los pasos del portal para crear un área de trabajo.
3. El área de trabajo nueva proporciona un enfoque de código reducido y controlado por código para que
los científicos de datos entrenen, compilen, implementen y administren modelos.
G O TO A Z U R E M A C H I N E L E A R N I N G
RESO URCES
Vaya directamente a los recursos de Azure Machine Learning en Azure Portal.
Aplicaciones y agentes de IA
Azure proporciona un conjunto de servicios de inteligencia artificial precompilados denominados Cognitive
Services para compilar aplicaciones de inteligencia artificial. Además, Azure ofrece un servicio de bot que
permite a los desarrolladores crear agentes de IA de conversación que mejoran la interacción entre el cliente y el
empleado.
Aplicaciones de IA
Cognitive Services permite incorporar las funcionalidades de inteligencia artificial de visión, voz, lenguaje y
decisión a las aplicaciones. La mayoría de los modelos predictivos no requieren entrenamiento adicional. Estos
servicios resultan útiles cuando entre el personal no se cuenta con científicos de datos para que entrenen el
modelo predictivo. Otros requieren un entrenamiento mínimo.
Para más información sobre el entrenamiento necesario y una lista de los servicios disponibles en visión, voz,
lenguaje y decisión, consulte la documentación de Cognitive Services.
Acción
Para empezar a trabajar con una Cognitive Services API:
1. En Azure Portal, busque y seleccione Cognitive Ser vices .
2. Seleccione Agregar para buscar una API de Cognitive Services en Azure Marketplace.
3. Busque y seleccione un servicio:
Si conoce el nombre del servicio que quiere usar, escríbalo en Buscar en el Marketplace y
selecciónelo.
Para obtener una lista de Cognitive Services APIs, seleccione Más junto al encabezado Cognitive
Ser vices . y, después, el servicio.
4. Seleccione Crear y siga los pasos que aparecen en el portal para aprovisionar el servicio.
G O TO C O G N I TI V E
S E R V IC E S
Vaya directamente a Cognitive Services en Azure Portal.

Agentes de IA
Interactúe de manera más natural con los clientes y mejore la involucración del cliente a través de experiencias
de conversación con tecnología de Bot Framework y Azure Bot Service. También puede usar Cognitive Services
APIs como Language Understanding (LUIS), QnA Maker y el servicio Voz. Ayudarán a sus clientes con las tareas
típicas y los teleoperadores podrán dedicarle tiempo a centrarse en casos con más matices y mayor valor.
Para más información sobre cómo compilar bots, consulte Azure Bot Service.
Acción
Para empezar a trabajar con Azure Bot Service:
1. En Azure Portal, busque y seleccione Bot Ser vices .
2. Seleccione Agregar y, luego, Bot de aplicación web o Registro de canales de bot .
3. Seleccione Crear . Siga los pasos que aparecen en el portal para aprovisionar el servicio.
G O TO A Z U R E B O T
S E R V IC E
Vaya directamente a Azure Bot Service en Azure Portal.
La minería de conocimientos usa la inteligencia artificial para mejorar la comprensión de los contenidos
procedentes de grandes cantidades de información no estructurada, semiestructurada y estructurada. Use Azure
Cognitive Search para descubrir información latente del contenido, incluidos documentos, imágenes y
elementos multimedia. Puede detectar patrones y relaciones en el contenido, comprender las opiniones y
extraer frases clave.
Azure Cognitive Search usa la misma pila de lenguaje natural que usan Bing y Microsoft Office. Dedique más
tiempo a innovar y menos tiempo a mantener una solución de búsqueda en la nube compleja.
Para más información, consulte ¿Qué es Azure Cognitive Search?
Acción
Primeros pasos:
1. En Azure Portal, busque y seleccione Azure Cognitive Search .
2. Siga los pasos que aparecen en el portal para aprovisionar el servicio.
G O TO A Z U R E C O G N I TI V E
SEARCH
Vaya directamente a Azure Cognitive Search en Azure Portal.

Kubernetes en Cloud Adoption Framework
Revise un marco normativo que incluye herramientas, programas y contenido (procedimientos recomendados,
plantillas de configuración e instrucciones de arquitectura) que simplifican la adopción tanto de Kubernetes
como de prácticas nativas de la nube a escala.
La lista de acciones necesarias está clasificada por rol, con el fin de impulsar una implementación correcta de las
aplicaciones en Kubernetes, desde la prueba de concepto a la producción y, posteriormente, su escalado y
optimización.
Introducción
Para prepararse para esta fase del ciclo de vida de la adopción de la nube, realice los siguientes ejercicios:
Desarrollo e implementación de aplicaciones: examine los patrones y prácticas de desarrollo de aplicaciones,
configure canalizaciones de integración continua y entrega continua, e implemente los procedimientos
recomendados de ingeniería de confiabilidad de sitios (SRE).
Diseño y operaciones de clústeres: Identifíquese para la configuración de clústeres y el diseño de la red.
Garantice la escalabilidad futura mediante la automatización del aprovisionamiento de la infraestructura.
Mantenga una alta disponibilidad mediante el planeamiento de la continuidad empresarial y recuperación
ante desastres.
Seguridad de clústeres y aplicaciones: Familiarícese con los elementos esenciales de la seguridad de
Kubernetes. Consulte la configuración segura de los clústeres y las instrucciones para la protección de
aplicaciones.
Desarrollo e implementación de aplicaciones
Examine los patrones y prácticas del desarrollo de aplicaciones, configure Azure Pipelines e implemente los
procedimientos recomendados de ingeniería de confiabilidad de sitios (SRE). La Ingeniería de confiabilidad de
sitios (SRE) es un enfoque de ingeniería de software para el desarrollo e implementación de aplicaciones, la
administración de cambios, la supervisión, la respuesta de emergencia y mucho más.
Planeamiento, entrenamiento y prueba

Al comenzar, use la lista de comprobación y los recursos de desarrollo de aplicaciones en las siguientes
secciones, para planificar el desarrollo y la implementación de su aplicación. Debe ser capaz de responder a
estas preguntas:
¿Ha preparado el entorno de desarrollo de aplicaciones y el flujo de trabajo de configuración?
¿Cómo estructurará la carpeta del proyecto para dar respaldo al desarrollo de aplicaciones de Kubernetes?
¿Ha identificado los requisitos de estado, configuración y almacenamiento de la aplicación?
Lista de comprobación de ingeniería de confiabilidad de sitios:
Preparación del entorno de desarrollo . Configure el entorno con las herramientas que necesita para
crear contenedores y configurar el flujo de trabajo de desarrollo.
Uso de Docker en Visual Studio Code
Uso de Kubernetes con Visual Studio Code
Introducción a Bridge to Kubernetes
Inclusión de la aplicación en contenedores . Familiarícese con la experiencia global de desarrollo de
Kubernetes, en la que se incluyen scaffolding de aplicaciones, flujos de trabajo de bucle interno, marcos
de administración de aplicaciones, canalizaciones de CI/CD, agregación de registros, supervisión y
métricas de aplicaciones.
Comience a trabajar con Kubernetes (colección de libros electrónicos)
Contenedorización de las aplicaciones con Kubernetes en Azure (seminario web)
Revisión de escenarios habituales de Kubernetes. A menudo, se considera que Kubernetes es una
plataforma que proporciona microservicios, pero se está convirtiendo en una plataforma mucho más
amplia. Consulte este vídeo para obtener más información sobre escenarios de Kubernetes habituales,
como el análisis y el flujo de trabajo por lotes: Información general de escenarios comunes de Kubernetes
(vídeo).
Preparación de la aplicación para Kubernetes . Prepare el diseño del sistema de archivos de la
aplicación para Kubernetes y organice las versiones semanales o diarias. Obtenga información sobre
cómo el proceso de implementación de Kubernetes permite actualizaciones confiables sin tiempo de
inactividad.
Diseño de proyectos para aplicaciones de Kubernetes correctas (seminario web)
Funcionamiento de las implementaciones de Kubernetes (vídeo)
Desarrollo e implementación de aplicaciones en Kubernetes (Microsoft Learn)
Administración del almacenamiento de aplicaciones. Comprenda las necesidades de rendimiento
y los métodos de acceso a los pods para que pueda proporcionar las opciones de almacenamiento
adecuadas. También debe planear las formas de realizar copias de seguridad y probar el proceso de
restauración en busca de almacenamiento conectado.
Aspectos básicos de las aplicaciones con estado en Kubernetes (vídeo)
Estado y datos en aplicaciones de Docker
Opciones de almacenamiento de Azure Kubernetes Service
Administración de secretos de aplicación . Use un almacén de claves para almacenar y recuperar
claves y credenciales. No almacene las credenciales en el código de la aplicación.
Funcionamiento de Kubernetes y la administración de configuración (vídeo)
Descripción de la administración de secretos en Kubernetes (vídeo)
Uso de Azure Key Vault con Kubernetes
Uso de Azure AD Pod Identity para autenticar los recursos de Azure y acceder a ellos
Implementación en producción y aplicación de procedimientos

recomendados
Cuando prepare la aplicación para producción, use la siguiente lista de comprobación. Debe ser capaz de
responder a estas preguntas:
¿Puede supervisar todos los aspectos de la aplicación?
¿Ha definido los requisitos de los recursos para la aplicación? ¿De qué información dispone sobre los
requisitos de escalado?
¿Puede implementar nuevas versiones de la aplicación sin que afecte a los sistemas de producción?
Lista de comprobación de procedimientos recomendados de SRE:
Configuración de las comprobaciones del estado de preparación y ejecución. Kubernetes usa
comprobaciones de preparación y ejecución para saber cuándo la aplicación está lista para recibir tráfico
y cuándo debe reiniciarse. Si no se definen estas comprobaciones, Kubernetes no podrá determinar si la
aplicación está en funcionamiento. Para obtener más información, consulte Comprobaciones de
disponibilidad y preparación.
Configuración del registro, la super visión de aplicaciones y las aler tas. La supervisión de los
contenedores es fundamental, sobre todo cuando se ejecuta un clúster de producción, a escala, con varias
aplicaciones. El método recomendado de registro para las aplicaciones contenedorizadas consiste en
escribir en los flujos de salida estándar ( stdout ) y de error estándar ( stderr ).
Registro en Kubernetes
Introducción a la supervisión y las alertas de Kubernetes (vídeo)
Azure Monitor para contenedores
Habilitación y revisión de los registros del plano de control de Kubernetes en Azure Kubernetes
Service (AKS)
Visualización de registros, eventos y métricas de pods de Kubernetes en tiempo real
Definición de los requisitos de los recursos para la aplicación. La manera principal de
administrar los recursos de proceso en un clúster de Kubernetes consiste en usar solicitudes y límites de
pods. Estos límites y solicitudes le indican al programador de Kubernetes qué recursos de proceso deben
asignarse a un pod. Para obtener más información, consulte Definición de solicitudes y límites de pod.
Configuración de los requisitos de escalado de la aplicación. Kubernetes admite el escalado
automático horizontal de pods para ajustar el número de pods en una implementación en función del
uso de la CPU o de otras métricas de selección. Para usar la escalabilidad automática, todos los
contenedores de los pod deben tener definidos solicitudes y límites de CPU. Para obtener más
información, consulte Configuración del escalado horizontal automático de pods.
Implementación de aplicaciones mediante una canalización automatizada y DevOps. La
automatización completa de todos los pasos entre la confirmación del código y la implementación en
producción permite a los equipos concentrarse en la compilación del código y elimina la sobrecarga, y los
posibles errores humanos, en los pasos manuales. La implementación de nuevo código es más rápida y
menos arriesgada, y esto ayuda a los equipos a ser más ágiles, productivos y a confiar en la ejecución del
código.
Logre que sus prácticas de DevOps evolucionen
Configuración de una canalización de compilación de Kubernetes (vídeo)
Centro de implementación de Azure Kubernetes Service
Acciones de GitHub para la implementación de Azure Kubernetes Service
Tutorial: Implementación desde GitHub en Azure Kubernetes Service con Jenkins
Optimización y escalado
Ahora que la aplicación está en producción, ¿cómo puede optimizar el flujo de trabajo y preparar la aplicación y
el equipo para el escalado? Use la lista de comprobación de optimización y escalado para la preparación. Debe
ser capaz de responder a estas preguntas:
¿Se han eliminado las cuestiones transversales de la aplicación?
¿Puede mantener la confiabilidad del sistema y de la aplicación mientras recorre en iteración nuevas
características y versiones?
Lista de comprobación de implementación de aplicaciones:
Implementación de una puer ta de enlace de API . Una puerta de enlace de API sirve como punto de
entrada a los microservicios, desacopla a los clientes de los microservicios, agrega otra capa de
seguridad y reduce la complejidad de los microservicios al eliminar la carga que supone la
administración de las cuestiones transversales. Para obtener más información, consulte Uso de Azure API
Management con microservicios implementados en Azure Kubernetes Service.
Implementación de una malla de ser vicio . Una malla de servicio proporciona a las cargas de trabajo
funcionalidades como administración del tráfico, resistencia, directiva, seguridad, identidad sólida y
observabilidad. La aplicación se desacopla de estas funciones operativas y la malla del servicio las retira
de la capa de la aplicación, bajándolas al nivel de infraestructura.
Funcionamiento de las mallas de servicio en Kubernetes (vídeo)
Más información sobre mallas de servicio
Uso de Open Service Mesh con Azure Kubernetes Service
Uso de Istio con Azure Kubernetes Service
Uso de Linkerd con Azure Kubernetes Service
Uso de Consul con Azure Kubernetes Service
Implementación de procedimientos de ingeniería de confiabilidad de sitios (SRE). La
ingeniería de confiabilidad de sitios (SRE) es un enfoque de eficacia probada para mantener la
confiabilidad de sistemas y aplicaciones cruciales mientras se realizan las iteraciones al ritmo que el
mercado demanda.
Introducción a la ingeniería de confiabilidad de sitios (SRE)
DevOps at Microsoft: Game streaming SRE (DevOps en Microsoft: SRE de streaming de juegos)
Diseño y operaciones de clústeres
En este artículo se trata la configuración de clústeres y el diseño de red. Aprenda a realizar una prueba de la
escalabilidad mediante la automatización del aprovisionamiento de la infraestructura. El aprovisionamiento es el
proceso de configuración de la infraestructura de TI que desea. El aprovisionamiento de infraestructura
automatizado admite una instalación remota y configura entornos virtuales. También le ayuda a mantener una
alta disponibilidad mediante el planeamiento de la continuidad empresarial y recuperación ante desastres.

Al principio, la lista de comprobación y los recursos siguientes de Kubernetes le ayudarán a planear el diseño del
clúster. Al final de esta sección, podrá responder a estas preguntas:
¿Ha identificado los requisitos de diseño de red para el clúster?
¿Tiene servicios con requisitos variables? ¿Cuántos grupos de nodos va a utilizar?
Lista de comprobación:
Identificación de los aspectos sobre el diseño de red . Comprenda los aspectos del diseño de red
del clúster, compare modelos de red y elija el complemento de red de Kubernetes que mejor se adapte a
sus necesidades. En el caso de las redes de Azure Container Networking Interface (CNI), considere el
número de direcciones IP necesarias como un múltiplo del máximo de pods por nodo (el valor
predeterminado es 30) y del número de nodos. Agregue un nodo necesario durante la actualización. Al
elegir los servicios del equilibrador de carga, considere la posibilidad de usar un controlador de entrada
cuando haya demasiados servicios para reducir el número de puntos de conexión expuestos. Para Azure
CNI, el servicio CIDR debe ser único en toda la red virtual y en todas las redes virtuales conectadas para
garantizar el enrutamiento adecuado.
Kubenet y redes de Azure CNI
Uso de redes kubenet con intervalos de direcciones IP propios en Azure Kubernetes Service (AKS)
Configuración de redes de Azure CNI en Azure Kubernetes Service (AKS)
Diseño de red seguro para un clúster de AKS
Creación de grupos de varios nodos . Para admitir aplicaciones con diferentes necesidades de
proceso o almacenamiento, puede configurar opcionalmente el clúster con grupos de varios nodos. Por
ejemplo, puede usar más grupos de nodos para proporcionar GPU para aplicaciones de proceso
intensivo o acceso a almacenamiento SSD de alto rendimiento. Para más información, consulte Creación
y administración de varios grupos de nodos para un clúster de Azure Kubernetes Service.
Decidir los requisitos de disponibilidad . Un mínimo de dos pods detrás de Azure Kubernetes
Service garantiza una alta disponibilidad de la aplicación si hay errores o reinicios de pods. Use tres o
más pods para controlar la carga durante los errores y reinicios de los pods. Para la configuración de
clústeres, se requiere un mínimo de dos nodos en un conjunto de disponibilidad o conjunto de escalado
de máquinas virtuales para cumplir el Acuerdo de Nivel de Servicio del 99,95 %. Use al menos tres pods
para garantizar la programación del pod durante los errores y los reinicios de los nodos.
Para proporcionar un mayor nivel de disponibilidad a las aplicaciones, los clústeres se pueden distribuir
entre zonas de disponibilidad. Estas zonas son centros de datos físicamente separados dentro de una
región determinada. Si los componentes del clúster se distribuyen entre varias zonas, el clúster podrá
tolerar un error en una de las zonas. Sus aplicaciones y operaciones de administración continuarán
disponibles incluso si todo un centro de datos sufre una interrupción. Para obtener más información,
consulte Creación de un clúster de Azure Kubernetes Service (AKS) que use zonas de disponibilidad.
Traslado a producción y aplicación de los procedimientos

recomendados de la infraestructura
Cuando prepare la aplicación para producción, implemente un conjunto mínimo de procedimientos
recomendados. En esta fase, use esta lista de comprobación. Al final de esta sección, podrá responder a estas
preguntas:
¿Puede reimplementar con confianza la infraestructura del clúster?
¿Ha aplicado cuotas de recurso?
Automatización del aprovisionamiento del clúster . Mediante la infraestructura como código, puede
automatizar el aprovisionamiento de la infraestructura para proporcionar una mayor resistencia durante
desastres y ganar agilidad a la hora de reimplementar la infraestructura según sea necesario. Para
obtener más información, consulte Creación de un clúster de Kubernetes con Azure Kubernetes Service
mediante Terraform.
Planeación de disponibilidad mediante presupuestos de interrupciones de pods . Para
mantener la disponibilidad de las aplicaciones, defina presupuestos de interrupciones de pods (PDB) para
asegurarse de que haya un número mínimo de pods disponible en el clúster durante los errores de
hardware o las actualizaciones del clúster. Para más información, consulte Planeación de disponibilidad
mediante presupuestos de interrupciones de pods.
Aplicación de cuotas de recursos en espacios de nombres . Planee y aplique cuotas de recursos en
el nivel del espacio de nombres. Las cuotas se pueden establecer en los recursos de proceso, de
almacenamiento y en el recuento de objetos. Para más información, consulte Aplicación de cuotas de
recursos.
Una vez que la aplicación esté en producción, ¿cómo puede optimizar el flujo de trabajo y preparar la aplicación
y el equipo para el escalado? Use la lista de comprobación de optimización y escalado para la preparación. Al
final de esta sección, podrá responder a estas preguntas:
¿Dispone de un plan de continuidad empresarial y recuperación ante desastres?
¿Puede escalarse el clúster para satisfacer las necesidades de la aplicación?
¿Puede supervisar el estado del clúster y la aplicación y recibir alertas?
Escalado automático de un clúster para satisfacer las necesidades de la aplicación . Para
satisfacer las necesidades de la aplicación, es posible que deba ajustar el número de nodos que ejecutan
las cargas de trabajo mediante la escalabilidad automática del clúster. Para obtener más información,
consulte Configuración de la escalabilidad automática de clústeres en Kubernetes.
Planes de continuidad empresarial y recuperación ante desastres . Planee una implementación
en varias regiones, cree un plan de migración del almacenamiento y habilite la replicación geográfica
para las imágenes de contenedor. Para obtener más información, consulte Procedimientos recomendados
para implementaciones de regiones - Replicación geográfica en Azure Container Registry.
Configuración de la super visión y solución de problemas a escala . Configure las alertas y la
supervisión de aplicaciones en Kubernetes. Obtenga más información sobre la configuración
predeterminada, la integración de más métricas avanzadas, y la incorporación de supervisión y alertas
personalizadas para manejar la aplicación.
Introducción a la supervisión y las alertas de Kubernetes (vídeo)
Configuración de alertas mediante Azure Monitor para contenedores
Revisión de los registros de diagnóstico de los componentes maestros
Diagnósticos de Azure Kubernetes Service (AKS)
Seguridad de clústeres y aplicaciones
Familiarícese con los elementos esenciales de seguridad de Kubernetes y revise la configuración de seguridad
de clústeres y aplicaciones. La seguridad de Kubernetes es importante a lo largo del ciclo de vida del contenedor
debido a la naturaleza dinámica y distribuida de un clúster de Kubernetes. Las aplicaciones son igual de seguras
que el eslabón más débil de la cadena de servicios que conforma la seguridad de la aplicación.

Según empieza a trabajar, la lista de comprobación de los requisitos de seguridad básicos y los recursos de
seguridad de Kubernetes siguientes le ayudarán a planear la seguridad de las operaciones del clúster y la
aplicación. Al final de esta sección, podrá responder a estas preguntas:
¿Ha revisado el modelo de seguridad y amenazas de los clústeres de Kubernetes?
¿Está el clúster habilitado para el control de acceso basado en roles de Kubernetes?
Lista de comprobación de seguridad:
Familiarícese con las notas del producto sobre los aspectos esenciales de la seguridad . Los
objetivos principales de un entorno de Kubernetes seguro son garantizar que las aplicaciones que ejecuta
están protegidas, que los problemas de seguridad se pueden identificar y resolver rápidamente, y que se
impedirán problemas similares en el futuro. Para obtener más información, consulte La guía definitiva
para proteger Kubernetes (notas del producto).
Revisión de la configuración de mejora de la seguridad en los nodos de clúster . Un sistema
operativo host con seguridad mejorada reduce el área expuesta a los ataques y permite implementar
contenedores de forma segura. Para obtener más información, consulte Mejora de la seguridad de los
hosts de máquinas virtuales de AKS.
Configure el control de acceso basado en rol de Kubernetes del clúster (RBAC de
Kubernetes). Este mecanismo de control le permite asignar a usuarios o grupos de usuarios, permiso
para realizar acciones como crear o modificar recursos, o ver registros de cargas de trabajo de
aplicaciones en ejecución.
Para obtener más información, vea
Descripción del control de acceso basado en roles de Kubernetes (RBAC de Kubernetes) (vídeo)
Integración de Azure AD con Azure Kubernetes Service
Limitación del acceso al archivo de configuración de clúster
Implementación en producción y aplicación de procedimientos

recomendados de seguridad de Kubernetes
Cuando prepare la aplicación para producción, implemente un conjunto mínimo de procedimientos
recomendados. En esta fase, use esta lista de comprobación. Al final de esta sección, podrá responder a estas
preguntas:
¿Ha configurado las reglas de seguridad de red para la comunicación de entrada, salida y entre pods?
¿Está el clúster configurado para aplicar automáticamente las actualizaciones de seguridad del nodo?
¿Va a ejecutar una solución de examen de seguridad para los servicios del clúster y del contenedor?
Control del acceso a clústeres mediante la per tenencia a grupos . Configure el control de acceso
basado en rol de Kubernetes (RBAC de Kubernetes) para limitar el acceso a los recursos de clúster en
función de la identidad de los usuarios o su pertenencia a un grupo. Para obtener más información,
consulte Administración del acceso a recursos de clúster mediante el control de acceso basado en roles
de Kubernetes y las identidades de Azure Active Directory en Azure Kubernetes Service.
Creación de una directiva de administración de secretos . Implemente y administre información
confidencial como, por ejemplo, contraseñas y certificados, mediante la administración de secretos en
Kubernetes. Para obtener más información, consulte Descripción de la administración de secretos en
Kubernetes (vídeo).
Protección del tráfico de red entre pods con directivas de red . Aplique el principio del privilegio
mínimo para controlar el flujo del tráfico de red entre los pods del clúster. Para obtener más información,
consulte Protección del tráfico entre pods con directivas de red.
Restricción del acceso al ser vidor de API mediante direcciones IP autorizadas . Para mejorar la
seguridad del clúster y reducir el área expuesta a ataques restrinja el acceso al servidor de API a un
conjunto limitado de intervalos de direcciones IP. Para obtener más información, consulte Protección del
acceso al servidor de API.
Restricción del tráfico de salida del clúster . Averigüe qué puertos y direcciones debe permitir si
restringe el tráfico de salida para el clúster. Puede usar Azure Firewall o un dispositivo de firewall de
terceros para proteger el tráfico de salida y definir estos puertos y direcciones obligatorios. Para obtener
más información, consulte Control del tráfico de salida de los nodos de clúster en AKS.
Protección del tráfico con un firewall de aplicaciones web (WAF) . Utilice Azure Application
Gateway como controlador de entrada para los clústeres de Kubernetes. Para obtener más información,
consulte Configuración de Azure Application Gateway como controlador de entrada.
Aplicación de actualizaciones de seguridad y de kernel en nodos de trabajo . Conozca la
experiencia de actualización de nodos de AKS. Para proteger los clústeres, las actualizaciones de
seguridad se aplican automáticamente a los nodos de Linux en AKS. Estas actualizaciones incluyen las
revisiones de seguridad del sistema operativo o las actualizaciones del kernel. Algunas de estas
actualizaciones requieren un reinicio del nodo para completar el proceso. Para obtener más información,
consulte Uso de Kured para reiniciar automáticamente los nodos para aplicar actualizaciones.
Configuración de un contenedor y una solución de examen del clúster . Examine los
contenedores insertados en Azure Container Registry y obtenga una mayor visibilidad sobre los nodos
de clúster, el tráfico en la nube y los controles de seguridad.
Integración de Azure Container Registry con Security Center
Integración de Azure Kubernetes Service con Security Center
Ahora que la aplicación está en producción, ¿cómo puede optimizar el flujo de trabajo y preparar la aplicación y
el equipo para el escalado? Use la lista de comprobación de optimización y escalado para la preparación. Al final
de esta sección, podrá responder a esta pregunta:
¿Puedo aplicar directivas de gobernanza y clúster a escala?
Aplicación de directivas de gobernanza del clúster . Aplique medidas de seguridad y cumplimiento
a escala en los clústeres de una manera centralizada y coherente. Para obtener más información, consulte
Control de implementaciones con Azure Policy.
Rotación periódica de los cer tificados del clúster . Kubernetes usa certificados para la autenticación
con muchos de sus componentes. Puede que quiera rotar periódicamente esos certificados por motivos
de seguridad o de directivas. Para obtener más información, consulte Rotación de certificados en Azure
Kubernetes Service (AKS).
Inteligencia artificial en Cloud Adoption Framework
Cloud Adoption Framework es una colección de documentación, pautas de implementación, procedimientos

recomendados y herramientas que conforman una guía probada de Microsoft diseñada para acelerar el ciclo de
vida de la adopción de la nube.
Revise un marco normativo que incluye herramientas, programas y contenido (procedimientos recomendados,
plantillas de configuración e instrucciones de arquitectura) que simplifican la adopción tanto de la inteligencia
artificial como de procedimientos nativos de la nube a escala.
La lista de acciones necesarias se clasificada por rol, con el fin de impulsar una implementación correcta de la
inteligencia artificial en las aplicaciones, desde la prueba de concepto a la producción y, posteriormente, su
escalado y optimización.
Introducción
Para prepararse para esta fase del ciclo de vida de la adopción de la nube, realice los siguientes ejercicios:
Desarrollo, implementación y administración del modelo de Machine Learning: Examine los patrones y
procedimientos de creación de sus propios modelos de aprendizaje automático, como las operaciones de
aprendizaje automático (MLOps), aprendizaje automático automatizado y herramientas de aprendizaje de
Machine Learning responsables como InterpretML y FairLearn.
Incorporación de modelos de inteligencia artificial específicos de un dominio a las aplicaciones: obtenga
información sobre los procedimientos recomendados para agregar funcionalidades de inteligencia artificial a
sus aplicaciones con Cognitive Services. Conozca también los principales escenarios que estos servicios le
ayudan a afrontar.
Creación de su propia solución de inteligencia artificial de conversación: Aprenda a crear su propio asistente
virtual, una aplicación de inteligencia artificial de conversación que puede comprender el lenguaje y la voz,
percibir grandes cantidades de información y responder de forma inteligente.
Creación de soluciones de minería de conocimientos basadas en inteligencia artificial: Aprenda a usar la
minería de conocimientos para extraer datos estructurados del contenido no estructurado y detectar
información procesable en los datos de su organización.
Machine Learning
El aprendizaje automático es un subconjunto de la inteligencia artificial que permite que las máquinas detecten
patrones y aprendan de los datos sin que estén expresamente programadas para ello. Las soluciones de Azure
Machine Learning pueden mejorar sus conclusiones informáticas.
Azure le permite obtener las funcionalidades más avanzadas de aprendizaje automático. Compile, entrene e
implemente de forma rápida y sencilla los modelos de Machine Learning mediante Azure Machine Learning. La
IA de Machine Learning se puede usar para todo tipo de aprendizaje automático, del clásico al profundo,
supervisado y no supervisado. Tanto si prefiere escribir código de Python o de R como si se decide por opciones
con poco o ningún código, como el diseñador, puede compilar y entrenar modelos de aprendizaje automático y
aprendizaje profundo muy precisos en un área de trabajo de Machine Learning y realizar su seguimiento.
Así que puede comenzar a entrenar en su máquina local y luego escalar horizontalmente a la nube. El servicio
también interopera con herramientas aprendizaje profundo y de código abierto populares, como PyTorch,
TensorFlow, scikit-learn, Ray y RLlib.
Para empezar, lea Soluciones de Machine Learning, donde encontrará un tutorial sobre cómo configurar el
primer experimento de aprendizaje automático. Para más información sobre el formato de los modelos de
código abierto y el tiempo de ejecución para el aprendizaje automático, consulte ONNX Runtime.
Entre los escenarios comunes para las soluciones de aprendizaje automático se incluyen:
Mantenimiento predictivo
Administración de inventario
Detección de fraudes
Previsión de la demanda
Recomendaciones inteligentes
Previsión de ventas
Lista de comprobación de Machine Learning

Para empezar, familiarícese con Machine Learning y, después, elija la experiencia con la que
comenzar. Puede seguir con los pasos para usar un cuaderno de Jupyter Notebook con Python, la
experiencia visual de arrastrar y colocar, o aprendizaje automático automatizado (AutoML).
Información sobre Machine Learning
Creación del primer experimento de aprendizaje automático con un cuaderno de Jupyter Notebook
con Python
Experimento con una herramienta visual de arrastrar y colocar
Uso de la UI de AutoML
Configuración del entorno de desarrollo
Experimente con tutoriales más avanzados para predecir las tarifas de taxi, clasificar imágenes y
compilar una canalización para la puntuación por lotes.
Uso de AutoML para predecir tarifas de taxi
Clasificación de imágenes con scikit-learn
Compilación de una canalización de Machine Learning para la puntuación por lotes
Siga los tutoriales en vídeo para más información sobre las ventajas de Machine Learning, incluida la
compilación de modelos sin código, las operaciones de aprendizaje automático (MLOps), ONNX Runtime,
la interpretabilidad y transparencia de los modelos, y mucho más.
Novedades de Machine Learning
Uso de AutoML para crear modelos
Compilación de modelos sin código con el diseñador de Machine Learning
MLOps para administrar el ciclo de vida de un extremo a otro
Incorporación de ONNX Runtime en los modelos
Interpretabilidad y transparencia de modelos
Creación de modelos con R
Revise las arquitecturas de referencia para las soluciones de IA y aprendizaje automático.
Pasos siguientes
Explore otras categorías de soluciones de IA:
Las aplicaciones de IA abarcan una amplia variedad de aplicaciones, como plataformas de comercio electrónico,
detección remota, control de robots y diagnóstico médico. La infusión de IA en una aplicación puede resultar ser
una tarea difícil y lenta. Hasta hace poco, se necesitaba una comprensión profunda del aprendizaje automático y
meses de desarrollo para adquirir datos, entrenar modelos e implementarlos a gran escala. Incluso entonces, el
éxito no estaba garantizado. El camino estaba lleno de obstáculos y dificultades que hacían que los equipos no
pudieran obtener valor de sus inversiones en IA.
Aplicaciones de IA
Microsoft Azure Cognitive Services son servicios de IA específicos de un dominio y están disponibles como API.
Estos servicios eliminan los desafíos de la infusión de IA en las aplicaciones y están diseñados para que hacerlas
productivas, estén preparadas para la empresa y sean de confianza. Le permiten aprovechar las últimas
novedades en IA sin necesidad de crear e implementar sus propios modelos; en su lugar, puede implementar
modelos de IA con solo ajustar unas pocas líneas de código. Incluso sin un equipo de ciencia de datos de gran
tamaño, pueda crear rápidamente aplicaciones de IA que vean, escuchen, hablen, comprendan e, incluso,
empiecen a razonar.
Algunos ejemplos comunes de aplicaciones de IA incluyen:
análisis de opiniones
Detección de objetos
Traducción
Personalización
Automatización de procesos robóticos
Siga estas instrucciones para planear el desarrollo y la implementación de aplicaciones de IA:
Familiarícese con la gran variedad de funcionalidades y servicios que se ofrecen en Azure Cognitive Services,
y decida cuáles usará.
Decida si tiene datos personalizados con los que desea entrenar y personalizar estos modelos de IA. Algunos
servicios de Cognitive Services se pueden personalizar.
Explore los tutoriales de inicio rápido de Azure Cognitive Services para aprender a usar el SDK y las API REST.
Los SDK de Cognitive Services están disponibles para muchos lenguajes de desarrollo populares, como C#,
Python, Java, JavaScript y Go.
Decida si necesita implementar estos productos de Cognitive Services en contenedores.
Lista de comprobación de aplicaciones de IA

Para empezar, familiarícese con las distintas categorías y servicios de Azure Cognitive Services, como visión, voz,
lenguaje, decisión y búsqueda web. Visite las páginas del producto para obtener más información e interactuar
con las demos. Cada categoría de la página ofrece un conjunto de guías de inicio rápido, tutoriales, guías paso a
paso para las API REST y los SDK. También puede leer un libro electrónico que describe los escenarios comunes
y cómo compilar su primera aplicación de IA con Cognitive Services.
Lea la documentación de Cognitive Services.
Explore las demos interactivas en las páginas de productos y servicios.
Lea el libro electrónico sobre la compilación de aplicaciones inteligentes con API cognitivas.
Descargue el quiosco multimedia inteligente para experimentar y demostrar los servicios.
Obtenga más información sobre la compatibilidad de contenedores con Azure Cognitive Services.
Revise las arquitecturas de referencia para las soluciones de IA.
Agentes de IA
La plataforma de Microsoft Azure AI pretende permitir a los desarrolladores innovar y acelerar sus proyectos. En
el caso de la IA conversacional, Azure ofrece Azure Bot Service, SDK y herramientas de Bot Framework para
permitir a los desarrolladores crear experiencias de conversación enriquecidas. Además, los desarrolladores
pueden usar Azure Cognitive Services, como Language Understanding (LUIS), QnA Maker y el servicio Voz, para
agregar las capacidades de que los bots de chat entiendan a los usuarios finales y hablen con ellos.
Entre los escenarios comunes de soluciones de IA conversacional o bot de chat se incluyen:
Bot de chat informativo de preguntas y respuestas
Bot de chat de servicio al cliente o soporte técnico
Bot de chat del departamento de soporte técnico o RR. HH.
Bot de chat de ventas o comercio electrónico
Dispositivos compatibles con voz
NOTE
Microsoft ofrece Power Virtual Agents, creados a partir de Bot Framework, para los desarrolladores que desean crear un
bot de chat principalmente con una experiencia sin código o de poco código. En este escenario, los desarrolladores no
hospedan el bot ellos mismos ni controlan el lenguaje natural ni otros modelos de IA con Cognitive Services.
Lista de comprobación de agentes de IA

Azure Bot Service y Microsoft Bot Framework tienen las siguientes características:
Bot Framework es una oferta de código abierto que proporciona un SDK para ayudarle a diseñar, compilar y
probar su bot. Este SDK está disponible en C#, JavaScript, Python y Java. También ofrece un lienzo de
creación visual gratuito en Bot Framework Composer y una herramienta de pruebas en Bot Framework
Emulator.
Azure Bot Service es un servicio dedicado dentro de Azure, que le permite hospedar o publicar su bot en
Azure y conectarse a canales populares.
Para más información sobre Azure Bot Service y Bot Framework, consulte:
Información general de Azure Bot Service y Bot Framework
Principios de diseño de bots
Una de las maneras más sencillas de empezar es usar QnA Maker, parte de Azure Cognitive Services, que puede
convertir de forma inteligente un documento de preguntas más frecuentes o un sitio web en una experiencia de
PyR en minutos. Para usar QnA Maker, consulte:
Tutorial: Uso de QnA Maker en el bot para responder preguntas
Prueba del servicio QnA Maker
Para descargar y usar el SDK y las herramientas de Bot Framework para el desarrollo de bots, consulte:
Versiones más recientes del SDK y las herramientas de Bot Framework
Creación del primer bot
Creación de un bot con Bot Framework SDK para .NET
Para obtener información sobre cómo agregar Cognitive Services para que el bot sea aún más inteligente,
consulte:
Guía del desarrollador para la creación de aplicaciones de IA (libro electrónico)
Documentación de Cognitive Services
Para obtener información sobre cómo crear su propio asistente virtual con aceleradores de soluciones de Bot
Framework, y seleccionar un conjunto común de aptitudes, como calendario, correo electrónico, punto de
interés y tareas pendientes, consulte la documentación de las soluciones de Bot Framework.
Pasos siguientes
Aprendizaje automático
La minería de conocimientos hace referencia a una categoría emergente de inteligencia artificial diseñada para
simplificar el proceso de acceso a información latente contenida en datos estructurados y no estructurados. La
minería de conocimientos define el proceso de uso de una canalización de inteligencia artificial para detectar
patrones ocultos e información procesable en conjuntos de datos estructurados y no estructurados de una
manera escalable. Asimismo, la minería de conocimientos incluye una comprensión lógica compleja, y puede
conectar flujos de información para formar una perspectiva empresarial real.
Azure Cognitive Search es un servicio y una solución de búsqueda en la nube administrada que proporciona a
los desarrolladores las API y las herramientas necesarias para agregar una experiencia completa de búsqueda
de datos a través de contenido privado y heterogéneo en aplicaciones web, móviles y empresariales. Ofrece
funcionalidades como puntuación, facetas, sugerencias, sinónimos y búsqueda geográfica para proporcionar
una experiencia de usuario enriquecida. Azure Cognitive Search es también el único servicio de búsqueda en la
nube con funcionalidades de minería de conocimientos integradas. Azure Cognitive Search actúa como
orquestador de la canalización de enriquecimiento de la minería de conocimientos, tras los pasos de ingesta,
enriquecimiento, exploración y análisis.
Los escenarios clave de la minería de conocimientos incluyen:
Administración de contenido digital: ayuda a los clientes a consumir contenido más rápidamente al
proporcionarles resultados de búsqueda pertinentes en el catálogo de contenido.
Asistencia al cliente y análisis de comentarios: encuentre rápidamente la respuesta correcta en
documentos y descubra tendencias de lo que los clientes solicitan para mejorar su experiencia.
Extracción de datos y administración de procesos: acelere el procesamiento de documentos al extraer
la información clave y rellenándola en otra documentación empresarial.
Revisión e investigación del contenido técnico: revise rápidamente documentos y extraiga la
información clave para tomar decisiones informadas.
Administración de auditoría y cumplimiento: identifique rápidamente las áreas clave y marque ideas o
información importantes en los documentos.
Lista de comprobación de soluciones de minería de conocimientos

Introducción: Acceda a aceleradores de soluciones de minería de conocimientos, actividades de
formación y talleres.
Acelerador de soluciones de minería de conocimientos
Taller sobre minería de conocimientos
Actividades de formación sobre minería de conocimientos
Libro electrónico sobre minería de conocimientos
Proyecto de Azure DevOps de minería de conocimientos. Para este proyecto, inicie sesión, vaya a
Cloud Adoption Framework y seleccione Minería de conocimientos .
Uso de aptitudes avanzadas: Las aptitudes avanzadas de Azure Search proporcionan funciones útiles
que se pueden implementar como aptitudes personalizadas para Azure Cognitive Search. Las aptitudes
se pueden usar como plantillas o puntos de partida para sus propias aptitudes personalizadas. También
puede implementarlas y usarlas tal y como están, si es que cumplen sus necesidades. También le
invitamos a aportar su propio trabajo mediante el envío de una solicitud de incorporación de cambios.
Exploración de recursos adicionales:
Introducción a Azure Cognitive Search
Aptitudes cognitivas integradas para el procesamiento de texto e imagen durante la indexación
Recursos de documentación para el enriquecimiento con inteligencia artificial en Azure Cognitive
Search
Trucos y sugerencias de diseño para el enriquecimiento con inteligencia artificial
Búsqueda de texto completo
Pasos siguientes
Aprendizaje automático
Desarrollo de invenciones digitales en Azure
Azure puede ayudarle a acelerar el desarrollo de todas las áreas de la invención digital. Esta sección de
procedimientos recomendados digitales de Cloud Adoption Framework se basa en la metodología de
innovación. En ella se muestra cómo combinar servicios de Azure para crear una cadena de herramientas para
la invención digital.
Alineación con la metodología

Hay muchas combinaciones de herramientas basadas en la nube para la invención digital y la innovación en
Azure. La siguiente imagen muestra información general sobre la forma en que las distintas herramientas de
invención digital se alinean con cada tipo de innovación.
Cadena de herramientas
En la siguiente serie de artículos se muestran algunos de los procedimientos recomendados y las herramientas
que se alinean estrechamente con la metodología de innovación. Para probar si hipótesis, empiece por la página
de información general del tipo de invención digital que necesita. La página de información general tiene la guía
de procedimientos recomendados sobre la que actuar para que pueda crear con empatía con el cliente.
Estos son los tipos de invención digital de que esta serie de artículos:
Democratización de datos: herramientas para compartir datos que satisfagan las necesidades de los clientes
relacionadas con la información.
Participación a través de aplicaciones: Herramientas para crear aplicaciones que permitan la participación de
los clientes más allá de los datos sin procesar.
Capacitación de la adopción: herramientas para acelerar la adopción por parte del cliente mediante el apoyo
digital a los ciclos de crear-medir-aprender.
Interacción con dispositivos: herramientas para crear distintos niveles de experiencias ambientales para los
clientes.
Predicción e influencia: herramientas para el análisis predictivo y la integración de su salida en aplicaciones.
Herramientas de innovación para la
democratización de los datos en Azure
Tal y como se describe en el artículo conceptual sobre la democratización de los datos, se pueden ofrecer
muchas innovaciones de recopilación de datos con una inversión técnica mínima. Muchas innovaciones
importantes requieren poco más que datos sin procesar. La democratización de los datos consiste en invertir la
menor cantidad de recursos necesarios para atraer a los clientes. Luego los clientes usan los datos para
aprovechar el conocimiento existente.
Comenzar con la democratización de los datos es una forma rápida de probar una hipótesis antes de pasar a
invenciones digitales más amplias y costosas. A medida que refine más la hipótesis y empiece a adoptar las
invenciones a escala, los siguientes procesos le ayudarán a preparar el soporte operativo de la innovación.

Este tipo de invención digital se puede acelerar en cada fase de los procesos siguientes, tal como se describe en
la imagen anterior. En la tabla de contenido de la izquierda de esta página se incluye una guía técnica para
acelerar la invención digital. Estos artículos se han agrupado por fase para alinear la guía con la metodología
global.
Uso compar tido de los datos recopilados: El primer paso de la democratización de los datos es
compartirlos abiertamente.
Gobernanza de los datos: asegúrese de que los datos confidenciales estén protegidos, sometidos a un
seguimiento y controlados antes de compartirlos.
Centralización de los datos: A veces, es necesario proporcionar una plataforma centralizada para la
democratización, el uso compartido y la gobernanza de los datos.
Recopilación de los datos: los procesos de migración, integración, ingesta y virtualización pueden
recopilar los datos existentes para centralizarlos, controlarlos y compartirlos.
En cada iteración, los equipos de adopción de la nube solo deben profundizar en la pila lo necesario para dar
prioridad a las necesidades del cliente frente a la arquitectura. Al retrasar las demandas técnicas en favor de las
necesidades del cliente, se acelera la validación de la hipótesis.
Todas las guías se asignan a los cuatro procesos anteriores. La guía abarca desde el mayor efecto para el cliente
hasta el mayor efecto técnico. En cada proceso, encontrará una guía sobre las diversas formas posibles en que
Azure puede acelerar su capacidad de crear con la empatía de los clientes.
En Azure, las siguientes herramientas de innovación se suelen usar para acelerar la invención digital en las fases
anteriores:
Power BI
Azure Data Catalog
Azure Synapse Analytics
Azure Cosmos DB
Azure Database para PostgreSQL
Azure Database for MySQL
Azure Database for MariaDB
Hiperescala para Azure Database for PostgreSQL
Almacén de Azure Data Lake
Azure SQL Database, con o sin Instancia administrada de Azure SQL
Azure Data Factory
Azure Stream Analytics
SQL Server Integration Services
Azure Stack
SQL Server Stretch Database
Azure StorSimple
Archivos de Azure
Azure File Sync
PolyBase
A medida que la invención se aproxima a la adopción a escala, los aspectos de cada solución requieren una fase
de refinamiento y maduración técnica. A medida que eso vaya sucediendo, es probable que se requieran más
servicios de los mencionados. Use la tabla de contenido de la izquierda de esta página para obtener la guía de
herramientas de Azure correspondiente a su proceso de prueba de hipótesis.
Introducción
En la tabla de contenido del lado izquierdo de esta página se describen muchos artículos. Estos artículos ayudan
a empezar a trabajar con cada una de las herramientas de esta cadena de herramientas.
NOTE
Algunos vínculos pueden salir de Cloud Adoption Framework para ayudarle a ir más allá del ámbito de esta plataforma.
Clasificación de los datos de la organización
La clasificación de datos permite determinar y asignar valor a los datos de la organización y proporciona un
punto de partida común para la gobernanza. El proceso de clasificación de datos clasifica los datos por
confidencialidad e impacto empresarial a fin de identificar los riesgos. Cuando los datos están clasificados, se
pueden administrar de formas que protegen aquellos confidenciales o importantes frente al robo o la pérdida.
Comprender los riesgos de los datos y administrarlos

Para administrar cualquier riesgo, hay que entenderlo. En el caso de la responsabilidad por infracción de datos,
ese conocimiento comienza con la clasificación de datos. La clasificación de datos es el proceso de asociar una
característica de metadatos a cada recurso de un entorno digital, que identifica el tipo de datos asociado con ese
recurso.
Cualquier recurso que se haya identificado como un posible candidato para la migración o la implementación
en la nube debería tener metadatos documentados para registrar la clasificación de los datos, la importancia
para la empresa y la responsabilidad de facturación. Estos tres puntos de clasificación pueden recorrer un largo
camino para comprender y mitigar los riesgos.
Clasificaciones que usa Microsoft

La siguiente es una lista de clasificaciones que usa Microsoft. Según su sector o los requisitos de seguridad
existentes, puede que ya existan estándares de clasificación de datos dentro de su organización. Si no existe
ningún estándar, es posible que quiera usar esta clasificación de ejemplo para comprender mejor el patrimonio
digital propio y el perfil de riesgo.
No empresarial: datos de la vida personal que no pertenecen a Microsoft.
Pública: datos comerciales públicamente disponibles y aprobados para uso público.
General: datos empresariales que no están destinados a una audiencia pública.
Confidencial: datos empresariales que pueden causar daños a Microsoft si se compartieran en exceso.
Extremadamente confidencial: datos empresariales que podrían causar graves daños a Microsoft si se
compartieran en exceso.
Etiquetado de la clasificación de datos en Azure

Las etiquetas de recursos son una buena opción para el almacenamiento de metadatos; puede usar estas
etiquetas para aplicar información de clasificación de datos a recursos implementados. Aunque el etiquetado de
los recursos en la nube por clasificación no sustituye a un proceso de clasificación de datos formal, proporciona
una valiosa herramienta para administrar recursos y aplicar directivas. Azure Information Protection es una
solución excelente para ayudarle a clasificar datos, independientemente de dónde se encuentren (en el entorno
local, en Azure, en alguna otra ubicación). Tenga en cuenta esta herramienta como parte de una estrategia
general de clasificación.
Realizar acción
Actúe definiendo y etiquetando los recursos con una clasificación de datos definida.
Elija una de las guías prácticas de gobernanza en la nube para obtener ejemplos de cómo aplicar etiquetas a
toda la cartera.
Revise las convenciones recomendadas de nomenclatura y etiquetado para definir un estándar de etiquetado
más completo.
Para información adicional sobre el etiquetado de recursos, consulte Uso de etiquetas para organizar los
recursos de Azure y la jerarquía de administración.
Pasos siguientes
Siga aprendiendo con esta serie de artículos revisando el artículo sobre la protección de datos confidenciales. El
siguiente artículo contiene información detallada que es aplicable si está trabajando con datos clasificados como
confidenciales o extremadamente confidenciales.
Protección de datos confidenciales
Recopilación de datos mediante migración y
modernización de los orígenes existentes
A menudo, las empresas tienen diferentes tipos de datos existentes que pueden democratizar. Cuando una
hipótesis de cliente requiere el uso de los datos existentes para crear soluciones modernas, un primer paso
puede ser la migración y modernización de los datos para prepararse para las innovaciones e invenciones. Para
alinear los esfuerzos de migración existentes dentro de un plan de adopción de la nube, migre y modernice los
datos según la metodología de migración.
Uso de este artículo

En este artículo se describe una serie de enfoques que se alinean con la metodología de migración. Puede
alinear mejor estos enfoques con la cadena de herramientas de migración de bases de datos estándar.
Durante la fase de evaluación de las cargas de trabajo, un equipo de adopción de la nube evalúa el estado actual
y el estado futuro del recurso migrado. Cuando ese proceso forma parte de un trabajo de innovación, ambos
equipos de adopción de la nube pueden usar este artículo para ayudar con las evaluaciones.
Conjunto de herramientas principal

Al migrar y modernizar datos locales, la elección de herramienta de Azure más común es Azure Database
Migration Service. Este servicio forma parte del centro de conectividad de Azure Migrate más amplio. Para los
orígenes de datos de SQL Server existentes, Data Migration Assistant ayuda a evaluar y migrar las estructuras
de datos.
Para admitir las migraciones de Oracle y NoSQL, también puede usar Azure Database Migration Service para
determinados tipos de bases de datos de origen a destino. Por ejemplo, la migración de bases de datos de
Oracle a PostgreSQL, o de MongoDB a Azure Cosmos DB. Más comúnmente, los equipos de adopción usan
herramientas de asociado o scripts personalizados para migrar a Azure Cosmos DB, Azure HDInsight o las
opciones de máquina virtual basadas en infraestructura como servicio (IaaS).
Consideraciones e instrucciones
Al usar Azure Database Migration Service para la migración y modernización de los datos, es importante
comprender lo siguiente:
La plataforma actual para hospedar el origen de datos.
La versión actual.
La plataforma y la versión futuras que mejor respaldan la hipótesis o el destino del cliente.
Tipo de migración de datos
Con una migración sin conexión, el tiempo de inactividad de la aplicación se inicia cuando comienza la
migración. Con una migración en línea, el tiempo de inactividad se limita al momento de la transición al final de
la migración.
Pruebe una migración sin conexión para determinar si el tiempo de inactividad es aceptable. Si el tiempo de
restauración no es aceptable, realice una migración en línea.
En la tabla siguiente de los tipos de migración de datos se muestran los pares de origen y de destino que se van
a revisar con el equipo de migración. Cada par incluye una elección de herramienta y un vínculo a un tutorial
relacionado.
SO URC E DEST IN O H ERRA M IEN TA T IP O DE M IGRA C IÓ N GUÍA
SQL Server Azure SQL Database Database Migration Sin conexión Tutorial
Service
SQL Server Azure SQL Database Database Migration En línea Tutorial

Service
SQL Server Instancia Database Migration Sin conexión Tutorial

administrada de Service
Azure SQL
SQL Server Instancia Database Migration En línea Tutorial

administrada de Service
Azure SQL
RDS SQL Server Azure SQL Database Database Migration En línea Tutorial
o Azure SQL Service
Managed Instance
MySQL Azure Database for Database Migration En línea Tutorial

MySQL Service
PostgreSQL Azure Database for Database Migration En línea Tutorial

PostgreSQL Service
MongoDB Azure Cosmos DB Database Migration Sin conexión Tutorial

API para MongoDB Service
MongoDB Azure Cosmos DB Database Migration En línea Tutorial

API para MongoDB Service
Herramientas de participación a través de
aplicaciones en Azure
Cree aplicaciones nativas de nube para conectar a los clientes de nuevas maneras. Las aplicaciones nativas de la
nube se crean desde cero y están optimizadas para la escala y el rendimiento de la nube. Se basan en
arquitecturas de microservicios, usan servicios administrados y se benefician de la entrega continua para
conseguir confiabilidad y una comercialización más rápida.
Como se describe en Participación a través de las aplicaciones, las aplicaciones pueden ser un aspecto
importante de una solución de producto viable mínimo (MVP). Por ejemplo, las aplicaciones suelen ser
necesarias para probar una hipótesis. Este artículo le ayuda a conocer las herramientas de desarrollo de
aplicaciones que proporciona Azure para acelerar el desarrollo de esas aplicaciones.
Alineación con la metodología de innovación

Puede acelerar este tipo de invención digital a través de cada uno de los enfoques siguientes. En la tabla de
contenido de la izquierda de esta página se incluye una guía técnica para acelerar la invención digital. Estos
artículos se han agrupado por sus enfoques para alinear la guía con la metodología global de innovación.
En este artículo, se da por hecho que todas las invenciones que dan lugar a una aplicación provienen de una
solución compartida, como se describe en el artículo sobre la capacitación para la adopción. Supongamos
también que cada aplicación produce algún tipo de experiencia del cliente, tanto para clientes internos como
externos.
En función de esas suposiciones, las siguientes son las tres rutas más comunes para los equipos de adopción de
la nube que desarrollan invenciones digitales:
Desarrolladores cívicos: antes de contratar a desarrolladores profesionales, los expertos en la materia de
negocios usan las herramientas para desarrolladores cívicos. Estas herramientas prueban y validan
rápidamente que la hipótesis de un cliente pueda satisfacer sus necesidades.
Experiencias inteligentes: cree experiencias modernas con plataformas en la nube para impulsar la
implementación rápida y los bucles de comentarios breves. Amplíe las aplicaciones web para infundir
inteligencia o incluso integrar bots.
Nativo de la nube: cree una nueva invención que aproveche de forma natural las funcionalidades de la
nube.
Cada ruta produce ventajas y desventajas a corto y a largo plazo. Cuando los equipos de gobernanza en la nube,
operaciones en la nube y centro de excelencia en la nube están preparados para admitir cada enfoque, puede
acelerar la adopción con un efecto mínimo en las operaciones empresariales sostenibles.
En función de la ruta tomada por el equipo de adopción de la nube, Azure proporciona servicios y herramientas
de desarrollo de aplicaciones para acelerar su capacidad de crear teniendo en cuenta la empatía con el cliente.
La siguiente lista de ofertas de Azure se agrupa en función de las rutas de decisiones anteriores. Estas ofertas
incluyen:
Azure App Service
Azure Kubernetes Service (AKS)
Azure Migrate
Azure Stack
PowerApps
Power Automate
Power BI
Introducción
NOTE
Herramientas que posibilitan la adopción en Azure
Tal y como se describe en Capacitación para la adopción, crear verdaderas innovaciones a escala requiere una
inversión para eliminar fricciones, lo que puede ralentizar la adopción. En las primeras etapas de la prueba de
una hipótesis, una solución es pequeña. La inversión para eliminar la fricción probablemente también lo sea. A
medida que se demuestran las hipótesis, crecen la solución y la inversión en posibilitar la adopción. En este
artículo se proporcionan vínculos clave para empezar a trabajar con cada fase del modelo de madurez.
Alineación con la metodología de innovación

Puede acelerar este tipo de invención digital a través de los siguientes niveles de madurez. En la tabla de
contenido de la izquierda de esta página se incluye una guía técnica para acelerar la invención digital. Estos
artículos se agrupan por nivel de modelo de madurez.
Solución compar tida: establezca un repositorio centralizado para todos los aspectos de la solución.
Bucles de comentarios: asegúrese de que los bucles de comentarios se pueden administrar de forma
coherente mediante iteraciones.
Integración continua: compile y consolide regularmente una solución de integración y de implementación
continua (CI/CD).
Pruebas confiables: valide la calidad de la solución y los cambios esperados para controlar las medidas de
protección.
Implementación de la solución: implemente una solución para que un equipo pueda compartir
rápidamente los cambios con los clientes.
Medida integrada: agregue métricas de aprendizaje al bucle de comentarios para que el equipo completo
los analice.
En el caso de los equipos de adopción que sean equipos de desarrollo profesional experimentados con
numerosos colaboradores, la cadena de herramientas de Azure comienza con GitHub y Azure DevOps.
A medida que crezcan sus necesidades, puede ampliar esta base para usar otras características de la
herramienta. La base ampliada puede incluir herramientas como las siguientes:
Azure Blueprint
Azure Policy
Plantillas del Administrador de recursos de Azure
Azure Monitor
En la tabla de contenido de la izquierda de esta página se muestra las guías de cada herramienta, que se alinean
con el modelo de madurez descrito anteriormente.
Introducción
NOTE
MLOps con Azure Machine Learning
MLOps (operaciones de aprendizaje automático) se basa en principios y procedimientos de DevOps que

aumentan la eficacia de los flujos de trabajo, como la integración, entrega e implementación continuas. MLOps
aplica estos principios al proceso de aprendizaje automático para:
Experimentar y desarrollar modelos con mayor rapidez.
Implementar modelos en producción con mayor rapidez.
Practicar y perfeccionar el control de calidad.
Azure Machine Learning ofrece las siguientes funcionalidades de MLOps:
Creación de canalizaciones reproducibles. Las canalizaciones de Machine Learning permiten definir
pasos repetibles y reutilizables para los procesos de preparación de datos, entrenamiento y puntuación.
Cree entornos de software reutilizables para entrenar e implementar modelos.
Registro, empaquetado e implementación de modelos desde cualquier lugar. Puede realizar el
seguimiento de los metadatos asociados necesarios para utilizar el modelo.
Captura de los datos de gobernanza del ciclo de vida de un extremo a otro. La información
registrada puede incluir quién está publicando modelos, por qué se han realizado los cambios y cuándo se
implementaron o usaron los modelos en producción.
Notificación y aler ta sobre eventos del ciclo de vida. Por ejemplo, puede recibir alertas sobre la
finalización del experimento, el registro del modelo, la implementación de este y la detección del desfase de
datos.
Super visión de aplicaciones para las incidencias operativas y las relacionadas con el
aprendizaje automático. Compare las entradas del modelo durante el entrenamiento y la inferencia,
explore las métricas de un modelo específico e incluya supervisión y alertas en su infraestructura de
aprendizaje automático.
Automatización del ciclo de vida de aprendizaje automático de un extremo a otro con Azure
Machine Learning y Azure Pipelines . El uso de canalizaciones le permite actualizar con frecuencia los
modelos, probar los modelos nuevos e implementar continuamente nuevos modelos de aprendizaje
automático junto con sus otras aplicaciones y servicios.
Procedimientos recomendados para MLOps con Azure Machine

Learning
Los modelos se diferencian del código en que tienen una vida útil orgánica y se deterioran a menos que se
mantengan. Una vez implementados, pueden agregar valor empresarial real, lo que resulta más fácil cuando se
proporcionan a los científicos de datos las herramientas necesarias para adoptar prácticas de ingeniería
estándar.
MLOps con Azure le ayuda a:
Cree modelos reproducibles y canalizaciones de entrenamiento reutilizables.
Simplificar el empaquetado, la validación y la implementación de modelos de cara a los controles de calidad
y las pruebas A/B.
Explicar y observar el comportamiento de los modelos y automatizar el proceso de reentrenamiento.
MLOps mejora la calidad y la coherencia de las soluciones de aprendizaje automático. Para más información
sobre cómo usar Azure Machine Learning para administrar el ciclo de vida de los modelos, consulte MLOps:
administración de modelos, implementación y supervisión con Azure Machine Learning.
Pasos siguientes
Para más información, lea y explore los siguientes recursos:
MLOps: administración de modelos, implementación y supervisión con Azure Machine Learning
Cómo y dónde se implementan los modelos con Azure Machine Learning.
Tutorial: Implementación de un modelo de clasificación de imágenes en Azure Container Instances.
Repositorio de ejemplos de MLOps de un extremo a otro
CI/CD de modelos de aprendizaje automático con Azure Pipelines
Creación de clientes que consumen un modelo implementado
Aprendizaje automático a escala
Repositorio de procedimientos recomendados y arquitecturas de referencia de Azure AI
Herramientas de experiencia ambiental para
interactuar con dispositivos en Azure
Tal y como se describe en el artículo sobre la interacción con dispositivos, los dispositivos que se usan para
interactuar con un cliente dependen de la cantidad de experiencia ambiental del usuario necesaria para
satisfacer las necesidades del cliente y facilitar la adopción. La velocidad del desencadenador que provoca la
necesidad y la capacidad de la solución para satisfacerla son factores determinantes en el uso de la repetición.
Las experiencias ambientales contribuyen a acelerar el tiempo de respuesta y a crear una mejor experiencia para
los clientes, ya que incorporan la solución en el entorno inmediato de los clientes.

Este tipo de invención digital se puede ofrecer a través de cualquiera de los siguientes niveles de experiencia
ambiental. En la tabla de contenido de la izquierda de esta página se incluye una guía técnica para acelerar la
invención digital. Estos artículos de interacción con dispositivos se agrupan por nivel de experiencia ambiental
de los usuarios para ajustarse a la metodología.
Experiencia móvil: las aplicaciones móviles suelen formar parte del entorno de un cliente. En algunos
escenarios, un dispositivo móvil puede proporcionar interactividad suficiente para crear una ambiente de
solución.
Realidad mixta: A veces, el entorno natural de un cliente debe modificarse a través de la realidad mixta. La
participación de un cliente en esa realidad mixta puede proporcionar una forma de experiencia ambiental de
los usuarios.
Realidad integrada: al aproximarse a un ambiente real, las soluciones de realidad integrada se centran en
el uso del dispositivo físico de un cliente para integrar la solución en comportamientos naturales.
Realidad ajustada: cuando alguna de las soluciones anteriores usa el análisis predictivo para proporcionar
una interacción con un cliente en su entorno natural, la solución crea la forma más alta de experiencia
ambiental.
En Azure, se suelen usar las siguientes herramientas para acelerar la invención digital en cada nivel de las
soluciones de experiencia ambiental de los usuarios. Estas herramientas se han agrupado en función de la
cantidad de experiencia necesaria para reducir la complejidad en la alineación de las herramientas con esas
experiencias.
C AT EGO RY H ERRA M IEN TA S
Experiencias móviles Azure App Service

PowerApps
Power Automate
Intune
Realidad mixta Unity

Azure Spatial Anchors
HoloLens
Realidad integrada Azure IoT Hub

Azure Sphere
Azure Kinect DK
Realidad ajustada IoT de la nube al dispositivo

Azure Digital Twins + HoloLens
Introducción
NOTE
Uso de herramientas innovadoras de predicción e
influencia con inteligencia artificial
IA significa inteligencia artificial, mediante la que un equipo detecta patrones de datos para generar información
que puede ayudar a las empresas a comprender el comportamiento de sus clientes. Las predicciones con
inteligencia artificial pueden predecir las necesidades de los clientes y automatizar los procesos empresariales.
Mediante el uso de aplicaciones con inteligencia artificial y herramientas digitales de innovación, las empresas
pueden detectar información latente en datos no estructurados y ofrecer nuevas formas de interactuar con los
clientes para proporcionar una mejor experiencia.
Puede acelerar este tipo de innovación digital a través de cada una de las siguientes áreas de solución. En la
tabla de contenido de la izquierda de esta página se incluyen los procedimientos recomendados y una guía
técnica para acelerar la invención digital. Estos artículos se agrupan por área de solución:
Machine Learning
Consideraciones a la hora de iniciar el recorrido de innovación digital

con aplicaciones de inteligencia artificial
La estrategia de inteligencia artificial, la cultura de esta, el uso responsable y escalable de la misma, y la
inteligencia artificial para cada uno de los distintos roles empresariales son elementos cruciales para cualquier
empresa que se deben tener en cuenta a la hora de planear el recorrido de predicción e innovación con
inteligencia artificial.
Estrategia de inteligencia ar tificial: los líderes del sector aplican un marco para crear una visión de
inteligencia artificial que se puede aplicar estratégicamente en toda una organización. Las preguntas
sobre la perspectiva de creación de valores, la perspectiva de la organización y la ejecución, y la
perspectiva del entorno del sector son las que definen el entorno de la inteligencia artificial.
Cultura de inteligencia ar tificial: para desarrollar correctamente una cultura de inteligencia artificial,
es posible que sea necesario realizar cambios clave para estar preparado para la inteligencia artificial.
Esto incluye la posibilidad de explorar el potencial de la inteligencia artificial en toda la empresa,
reconocer y fomentar las aptitudes y los roles necesarios para hacer que la inteligencia artificial se
implemente con éxito, proporcionar ejemplos de implementaciones satisfactorias de inteligencia artificial
en escenarios significativos pertenecientes a los campos de finanzas, marketing, ventas, servicio de
atención al cliente y promoción de la aplicación de la inteligencia artificial.
Inteligencia ar tificial responsable: la inteligencia artificial responsable es un compromiso con el
avance de la inteligencia artificial que está impulsado por principios que ponen a las personas en primer
lugar. Los principios y recursos de Microsoft AI admiten la inteligencia artificial de confianza en marcos
empresariales y de infraestructura. Para crear correctamente un procedimiento de inteligencia artificial,
se debe incorporar una inteligencia artificial responsable al enfoque de innovación digital.
Inteligencia ar tificial escalable: La inteligencia artificial escalable fomenta las herramientas de
innovación en todos los niveles y permite evaluar las inversiones y establecer procesos técnicos
relacionados con la inteligencia artificial para toda la organización. Los patrones y procedimientos
recomendados de inteligencia artificial permiten el escalado horizontal y vertical de esta en toda la
empresa.
Inteligencia ar tificial para usuarios empresariales: la inteligencia artificial puede permitir a todos
los usuarios de una organización conseguir más, no solo a los desarrolladores y los científicos de datos.
Con el tiempo, todos los usuarios deben comprender las aplicaciones, conceptos, herramientas y
tecnologías que hacen posible la inteligencia artificial.
Inteligencia ar tificial para líderes empresariales: comprensión de la tecnología de inteligencia
artificial de vanguardia mediante la exploración holística de los conceptos de aprendizaje automático y su
uso para optimizar empresas de todos los sectores, y cómo estas herramientas y tecnologías innovadoras
pueden beneficiar a su empresa.
Introducción
Los artículos del índice le ayudarán a empezar a trabajar con cada una de las áreas de la solución.
NOTE
¿Qué es el aprendizaje automático?
El aprendizaje automático es una técnica de ciencia de datos que permite a los equipos utilizar datos existentes
para prever tendencias, resultados y comportamientos futuros. Mediante el aprendizaje automático, los equipos
aprenden sin necesidad de programarlos explícitamente. Las herramientas de aprendizaje automático usan
sistemas de inteligencia artificial que proporcionan la capacidad de identificar patrones y crear asociaciones a
partir de experiencias con los datos.
Las previsiones o predicciones del aprendizaje automático automatizado pueden hacer que las aplicaciones y los
dispositivos sean más inteligentes. Por ejemplo, cuando compra en línea, el aprendizaje automático ayuda a
recomendar otros productos según lo que haya adquirido. O, cuando pasa su tarjeta de crédito, el aprendizaje
automático compara la transacción con una base de datos de transacciones y ayuda a detectar fraudes. Y
cuando la aspiradora robot aspira una sala, el aprendizaje automático le ayuda a decidir si se ha terminado el
trabajo.
Herramientas de aprendizaje automático que se ajustan a cada tarea

Azure Machine Learning proporciona todas las herramientas que los desarrolladores y científicos de datos
necesitan para sus flujos de trabajo de aprendizaje automático, entre las que se incluyen:
El diseñador de Azure Machine Learning (versión preliminar): Módulos de arrastrar y colocar para compilar
los experimentos e implementar canalizaciones.
Cuadernos de Jupyter Notebook: use nuestros cuadernos de ejemplo o cree los suyos propios para
aprovechar los ejemplos del SDK para Python.
Scripts o cuadernos de R en los que usa el SDK para R para escribir su propio código, o use los módulos de R
en el diseñador.
El acelerador de soluciones Many Models (versión preliminar) se basa en Azure Machine Learning y permite
entrenar, usar y administrar cientos o incluso miles de modelos de Machine Learning.
Extensión de Visual Studio Code.
CLI de Machine Learning.
Plataformas de código abierto como PyTorch, TensorFlow y scikit-learn, entre muchas otras
Aprendizaje de refuerzo con Ray RLlib.
Incluso puede usar MLflow para realizar un seguimiento de las métricas e implementar modelos o kubeflow
para crear canalizaciones de flujos de trabajo de un extremo a otro.
Generación de modelos de Machine Learning en Python o R

Empiece a entrenar en su máquina local mediante el SDK de Python o el SDK de R para Azure Machine Learning.
Luego, puede escalar horizontalmente a la nube. Con muchos destinos de proceso disponibles, por ejemplo, los
procesos de Azure Machine Learning y Azure Databricks, y con los servicios avanzados de ajuste de
hiperparámetros, puede compilar mejores modelos de forma más rápida gracias al potencial de la nube.
También puede automatizar el entrenamiento y optimización del modelo mediante el SDK.
Generación de modelos de Machine Learning con herramientas sin

código
Para realizar la implementación y el entrenamiento sin código o con poco código, pruebe:
Diseñador de Azure Machine Learning (versión preliminar)
Use el diseñador para preparar los datos, entrenar, probar, implementar, administrar y realizar un
seguimiento de los modelos de aprendizaje automático sin necesidad de escribir código. No se requiere
programación; conecte visualmente los conjuntos de datos y los módulos para construir el modelo.
Pruebe el tutorial del diseñador.
Puede obtener más información en el artículo de introducción al diseñador de Azure Machine Learning.
UI de aprendizaje automático automatizado (AutoML)
Aprenda a crear experimentos de AutoML en una interfaz fácil de usar.
MLOps: Administración de implementaciones y ciclos de vida

Las operaciones de aprendizaje automático (MLOps) se basan en los principios y procedimientos de DevOps
que aumentan la eficacia de los flujos de trabajo. Por ejemplo, integración continua, entrega e implementación.
MLOps aplica estos principios al proceso de aprendizaje automático, con el objetivo de:
Conseguir una experimentación y desarrollo de modelos más rápidos
Conseguir una implementación más rápida de los modelos en producción
Control de calidad
Cuando tenga el modelo adecuado, podrá usarlo fácilmente en un servicio web, en un dispositivo de IoT o en
Power BI. Para más información, consulte Implementación de modelos con Azure Machine Learning.
Luego, puede administrar los modelos implementados mediante el SDK de Azure Machine Learning para
Python, Azure Machine Learning Studio o la CLI de Machine Learning.
Se pueden usar estos modelos para que devuelvan predicciones en tiempo real o de forma asincrónica para
grandes cantidades de datos.
Y con las canalizaciones de aprendizaje automático avanzadas, puede colaborar en cada paso desde la
preparación de datos, el entrenamiento y la evaluación de modelos hasta su implementación. Las canalizaciones
permiten:
Automatizar el proceso de aprendizaje automático de un extremo a otro en la nube
Reutilizar los componentes y volver a ejecutar los pasos cuando sea necesario
Usar recursos de proceso diferentes en cada paso
Ejecutar tareas de puntuación por lotes
Si desea usar scripts para automatizar el flujo de trabajo de aprendizaje automático, la CLI de Machine Learning
proporciona herramientas de línea de comandos que realizan tareas comunes, como el envío de una ejecución
de entrenamiento o la implementación de un modelo.
Para comenzar a usar Azure Machine Learning, consulte la sección Pasos siguientes.
Automated Machine Learning

Los científicos de datos dedican una cantidad de tiempo desmesurada a la iteración de los modelos durante la
fase de experimentación. Todo el proceso de prueba de los distintos algoritmos y combinaciones de
hiperparámetros hasta que se alcanza un modelo aceptable es extremadamente exigente para los científicos de
datos, debido a la naturaleza monótona y poco desafiante del trabajo. Si bien se trata de un ejercicio que genera
enormes ganancias en cuanto a la eficacia del modelo, a veces cuesta demasiado en cuanto a tiempo y recursos
y, por tanto, puede tener una rentabilidad de la inversión (ROI) negativa.
Aquí es donde entra en juego el aprendizaje automático automatizado (AutoML). Usa los conceptos del
documento de investigación sobre la factorización probabilística de matrices e implementa una canalización
automatizada de probar los algoritmos seleccionados de forma inteligente y la configuración de
hipermedidores, en función de la heurística de los datos presentados, teniendo en cuenta el problema o
escenario dados. El resultado de esta canalización es un conjunto de modelos que son más adecuados para el
problema y el conjunto de resultados dados.
Para obtener más información sobre AutoML, consulte AutoML y MLOps con Azure Machine Learning.
Aprendizaje automático responsable

A lo largo del desarrollo y el uso de sistemas de AI, la confianza debe ser el centro de todo. Debe confiar en la
plataforma, el proceso y los modelos. La IA y los sistemas autónomos están cada vez más integrados en la
sociedad, por lo que es importante hacer un esfuerzo para prever y mitigar las consecuencias no deseadas de
estas tecnologías.
Comprenda los modelos y compile según el principio de equidad: explique el comportamiento del
modelo y descubra las características que tengan el mayor impacto en las predicciones. Use los explicadores
integrados para los modelos de caja de cristal y caja negra durante el entrenamiento y la inferencia del
modelo. Use visualizaciones interactivas para comparar modelos y realizar análisis de hipótesis para mejorar
la precisión del modelo. Pruebe la equidad de los modelos con algoritmos de última generación. Mitigue la
inequidad a lo largo del ciclo de vida del aprendizaje automático, compare los modelos mitigados, y realice
concesiones intencionales entre equidad y precisión según lo desee.
Proteja la privacidad y la confidencialidad de los datos: cree modelos que preserven la privacidad
usando las últimas innovaciones en privacidad diferencial, que inyecta niveles precisos de ruido estadístico
en los datos con el fin de limitar la divulgación de información confidencial. Identifique las fugas de datos y
limite de forma inteligente las consultas repetidas para controlar el riesgo de exposición. Utilice técnicas de
cifrado y aprendizaje automático confidencial (próximamente) diseñadas específicamente para el aprendizaje
automático con el fin de crear de forma segura modelos usando datos confidenciales.
Controle y regule cada paso del proceso de aprendizaje automático: acceda a las funcionalidades
integradas para realizar un seguimiento automático del linaje y cree una prueba de auditoría en el ciclo de
vida del aprendizaje automático. Obtenga visibilidad completa del proceso de aprendizaje automático
mediante el seguimiento de conjuntos de datos, modelos, experimentos, código, etc. Utilice etiquetas
personalizadas para implementar hojas de datos de modelo, documentar metadatos clave del modelo,
aumentar la responsabilidad y garantizar un proceso responsable.
Obtenga más información sobre cómo implementar ML responsable.
Integración con otros servicios

Azure Machine Learning funciona con otros servicios de la plataforma de Azure y también se integra con
herramientas de código abierto como Git y MLFlow.
Objetivos de proceso, como Azure Kubernetes Ser vice, Azure Container Instances, Azure
Databricks, Azure Data Lake Analytics y Azure HDInsight. Para más información sobre los destinos de
proceso, consulte ¿Qué son los destinos de proceso?
Azure Event Grid. Para más información, consulte Consumo de eventos de Azure Machine Learning.
Azure Monitor. Para más información, consulte Supervisión de Azure Machine Learning.
Almacenes de datos, como cuentas de Azure Storage, Azure Data Lake Storage, Azure SQL
Database, Azure Database for PostgreSQL y conjuntos de datos abier tos de Azure. Para más
información, consulte Acceso a los datos en Azure Storage Services y Creación de conjuntos de datos con
conjuntos de datos abiertos de Azure.
Azure Vir tual Network . Para más información, consulte Protección de la experimentación y la inferencia
en una red virtual.
Azure Pipelines. Para más información, consulte Entrenamiento e implementación de modelos de
aprendizaje automático.
Registros del repositorio de Git. Para más información, consulte Integración de Git.
MLflow. Para más información, consulte MLflow para el seguimiento de las métricas y la implementación de
modelos.
Kubeflow. Para más información, consulte Creación de canalizaciones de flujo de trabajo de un extremo a
otro.
Comunicaciones seguras : la cuenta de Azure Storage, los destinos de proceso y otros recursos se pueden
usar de forma segura dentro de una red virtual para entrenar modelos y realizar la inferencia. Para más
información, consulte Protección de experimentos e inferencias en una red virtual.
Pasos siguientes
Revise las notas del producto y los libros electrónicos sobre Machine Learning Studio y Machine Learning
Service.
Revise las arquitecturas de IA + aprendizaje automático.
Procedimientos para enfocar las operaciones de
Las operaciones de aprendizaje automático constan de principios y procedimientos recomendados sobre cómo
organizar y estandarizar el desarrollo, la implementación y el mantenimiento del modelo de máquina de una
forma escalable.
Los componentes principales de cómo se desarrolla un sistema de aprendizaje automático se describen a

continuación:
Sculley, et al. 2015. Deuda técnica oculta en sistemas de aprendizaje automático. Procedimientos de la 28.ª
conferencia internacional sobre sistemas de procesamiento de información neuronal, volumen 2 (NIPS 2015).
Operaciones de aprendizaje automático frente a operaciones de

desarrollo
Aunque las operaciones de desarrollo (DevOps) influyen en las operaciones de aprendizaje automático, existen
diferencias entre los procesos. Además de las prácticas de DevOps, las operaciones de aprendizaje automático
abordan los siguientes conceptos que no se tratan en DevOps:
Control de versiones de datos: debe haber un control de versiones del código y del conjunto de
datos, ya que el esquema y los datos reales pueden cambiar con el tiempo. De este modo, se pueden
reproducir los datos, los datos son visibles para otros miembros del equipo y se pueden auditar los casos
de uso.
Seguimiento de modelos: los artefactos de modelos suelen almacenarse en un registro de modelos
que debe identificar las funcionalidades de almacenamiento, control de versiones y etiquetado. Estos
registros deben identificar el código fuente, sus parámetros y los datos correspondientes que se usan
para entrenar el modelo, los cuales indican dónde se creó un modelo.
Pista de auditoría digital: al trabajar con código y datos, se debe realizar un seguimiento de todos los
cambios.
Generalización: los modelos son diferentes del código para su reutilización, ya que deben ajustarse en
función de los datos de entrada o el escenario. Es posible que tenga que ajustar el modelo a fin de que los
nuevos datos lo utilicen para un nuevo escenario.
Reentrenamiento de los modelos: el rendimiento de los modelos puede disminuir con el tiempo, de
modo que es importante volver a entrenar los modelos para que sigan siendo útiles.
Enfoques para las operaciones de aprendizaje automático

Los científicos de datos de una organización aplican una experiencia, madurez, conocimientos y herramientas
muy amplios para experimentar con operaciones de aprendizaje automático. Dado que es importante alentar a
que el mayor número de participantes adopten la IA, no es posible ni deseable contar con un consenso sobre
cómo todas las organizaciones deben abordar las operaciones de aprendizaje automático. A la luz de esta
variedad, un punto inicial claro para su organización es comprender cómo su tamaño y recursos influirán en su
enfoque para las operaciones de aprendizaje automático.
El tamaño y la madurez de una empresa indican si los equipos de ciencia de datos o los individuos con roles
únicos serán propietarios del ciclo de vida del aprendizaje automático y recorrerán cada fase. Los siguientes
enfoques del ciclo de vida son los más comunes para cada escenario:
Un enfoque centralizado
Probablemente, los equipos de ciencia de datos supervisarán el ciclo de vida del aprendizaje automático en
pequeñas empresas con recursos y especialistas limitados. Este equipo aplica su experiencia técnica para limpiar
y agregar datos, desarrollar e implementar modelos y supervisar y mantener los modelos implementados.
Una ventaja de este método es que hace avanzar el modelo rápidamente a la fase de producción, pero aumenta
los costos debido a los niveles de aptitud especializados que deben mantenerse en el equipo de ciencia de datos.
La calidad se ve afectada cuando no existen los niveles de especialización necesarios.
Un enfoque descentralizado
Probablemente, personas con roles especializados supervisarán el ciclo de vida de aprendizaje automático y
serán responsables de este en empresas con equipos de operaciones dedicados. Una vez que se aprueba un
caso de uso, se asigna un ingeniero de aprendizaje automático para evaluar su estado actual y la cantidad de
trabajo necesario a fin de elevarlo al formato que se puede admitir.
El científico de datos deberá recopilar información para las siguientes preguntas:
¿Quién será el propietario de la empresa?
¿Cómo se consumirá el modelo?
¿Qué nivel de disponibilidad de servicio se necesitará?
¿Cómo se volverá a entrenar el modelo?
¿Con qué frecuencia se volverá a entrenar el modelo?
¿Quién decidirá las condiciones para la promoción del modelo?
¿Qué grado de confidencialidad tiene el caso de uso? ¿El código se puede compartir?
¿Cómo se modificarán el modelo y el código en el futuro?
¿Cuántos experimentos actuales se pueden volver a usar?
¿Existen flujos de trabajo de proyectos existentes que puedan ayudarle?
¿Cuánto trabajo se deberá completar para avanzar el modelo a la fase de producción?
Después, un ingeniero de aprendizaje automático diseña el flujo de trabajo y calcula la cantidad de trabajo
necesario. Un procedimiento recomendado consiste en involucrar a los científicos de datos para crear el flujo de
trabajo. Esta es una oportunidad clave para formarles y familiarizarles con el repositorio final, ya que es habitual
que el científico de datos trabaje con el caso de uso en el futuro.
Cómo benefician las operaciones de aprendizaje automático a las

empresas
Las operaciones de aprendizaje automático conectan las operaciones de desarrollo tradicionales, las
operaciones de datos y la ciencia de datos o IA. Comprender cómo las operaciones de aprendizaje automático
pueden beneficiar a su empresa le resultará de ayuda para su recorrido por la IA.
Al integrar las operaciones de aprendizaje automático con su empresa puede obtener las ventajas siguientes:
La administración de modelos empresariales simplifica y automatiza el ciclo de vida de desarrollo,
entrenamiento, implementación y operacionalización de los modelos. De este modo, las empresas
adquieren agilidad y pueden responden a las necesidades inmediatas y los cambios empresariales de una
manera repetitiva y administrada.
El control de versiones y la realización de datos permiten que la empresa genere modelos iterados y con
versiones para ajustarse a los matices de los datos o al caso de uso concreto. Esto proporciona
flexibilidad y agilidad a la hora de responder a los problemas y los cambios de la empresa.
Cuando las organizaciones supervisan y administran sus modelos, pueden responder rápidamente a
cambios significativos en los datos o en el escenario. Por ejemplo, un modelo implementado podría
experimentar un desfase de datos extremo debido a un factor externo o a un cambio en los datos
subyacentes. Esto inutilizaría los modelos anteriores y requeriría que se volviera a entrenar el modelo
actual lo antes posible. Es necesario realizar un seguimiento de los modelos de aprendizaje automático
con fines de precisión y rendimiento. De este modo, se envía una alerta a las partes interesadas cuando
los cambios afectan a la confiabilidad y al rendimiento del modelo, lo que permite realizar un
reentrenamiento y una implementación rápidamente.
Los procesos de operaciones de aprendizaje automático aplicados admiten resultados empresariales, ya
que permiten las auditorías, el cumplimiento normativo, el gobierno y el control de acceso rápidos
durante todo el ciclo de vida de desarrollo. La visibilidad de la generación de modelos, el uso de datos y
el cumplimiento normativo está clara a medida que los cambios se realizan en la empresa.
Pasos siguientes
Microsoft AI Business School es un recurso que describe la IA, lo que incluye cómo abordar la
implementación de forma holística, comprender las dependencias más allá de la tecnología e impulsar un
impacto empresarial duradero.
Obtenga más información sobre el proceso de operaciones de aprendizaje automático para explorarlo
con más detalle.
Proceso de las operaciones de aprendizaje
automático
Ciclo de desarrollo del modelo

El proceso de desarrollo debe generar los resultados siguientes:
El entrenamiento es automático y los modelos se validan, lo que incluye la funcionalidad y el rendimiento
de las pruebas (por ejemplo, el uso de métricas de precisión).
La implementación en la infraestructura que se usa para la inferencia (incluida la supervisión) está
automatizada.
Los mecanismos crean un registro de auditoría de datos integral. El reentrenamiento automático de los
modelos se produce cuando hay un desfase de datos a lo largo del tiempo, lo que resulta pertinente para
sistemas basados en aprendizaje automático a gran escala.
En el siguiente diagrama se muestra el ciclo de vida de la implementación de un sistema de aprendizaje
automático:
Una vez desarrollado, se entrena, valida, implementa y supervisa un modelo de aprendizaje automático. Desde
el punto de vista de la organización y en el nivel técnico y administrativo, es importante definir quién se encarga
de este proceso y lo implementa. En las empresas más grandes, un científico de datos podría encargarse de los
pasos de entrenamiento y validación del modelo, mientras que un ingeniero de aprendizaje automático podría
ocuparse de los pasos restantes. En empresas más pequeñas, un científico de datos podría encargarse de todos
los pasos.
Entrenamiento del modelo
En este paso, un conjunto de datos de entrenamiento entrena el modelo de aprendizaje automático. El código de
entrenamiento tiene control de versiones y es reutilizable, y esta característica optimiza los clics de botón y los
desencadenadores de eventos (p. ej., una nueva versión de los datos que pasan a estar disponibles) a fin de
automatizar cómo se entrena el modelo.
Validación del modelo
Este paso usa métricas establecidas, como una métrica de precisión, para validar automáticamente el modelo
recién entrenado y compararlo con los más antiguos. ¿La precisión aumentó? En caso afirmativo, este modelo
podría registrarse en el registro de modelos a fin de garantizar que se puede usar en los pasos siguientes. Si la
precisión del nuevo modelo es peor, se puede avisar a un científico de datos para que investigue el motivo o
descartar el modelo recién entrenado.
Implementación del modelo
Implemente el modelo como un servicio de API para aplicaciones web en el paso de implementación. Este
enfoque permite escalar y actualizar el modelo de forma independiente de las aplicaciones. Como alternativa, el
modelo se puede utilizar para realizar la puntuación por lotes, en la que se usa una vez o periódicamente para
calcular las predicciones en los nuevos puntos de datos. Esto resulta útil cuando se deben procesar grandes
cantidades de datos de forma asincrónica. Puede encontrar más detalles sobre los modelos de implementación
en la página inferencia de aprendizaje automático durante la implementación .
Supervisión del modelo
Es necesario supervisar el modelo por dos motivos clave. En primer lugar, la supervisión del modelo permite
garantizar que sea técnicamente funcional, por ejemplo, que pueda generar predicciones. Esto es importante si
las aplicaciones de una organización dependen del modelo y lo usan en tiempo real. La supervisión del modelo
también ayuda a las organizaciones a medir si genera predicciones útiles continuamente. Esto podría no resultar
útil cuando se produce el desfase de datos, por ejemplo, cuando los datos usados para entrenar el modelo
difieren significativamente de los datos que se envían a este durante la fase de predicción. Por ejemplo, un
modelo entrenado para recomendar productos a personas jóvenes podría producir resultados no deseados si
recomienda productos a personas de otro grupo de edad. La supervisión de modelos con el desfase de datos
puede detectar este tipo de discrepancia, alertar a los ingenieros de aprendizaje automático y volver a entrenar
de manera automática el modelo con datos más pertinentes o más recientes.
Cómo supervisar los modelos
Dado que el desfase de datos, la estacionalidad o la arquitectura más reciente optimizada para mejorar el
rendimiento pueden provocar que el rendimiento del modelo varíe a lo largo del tiempo, es importante
establecer un proceso para implementar modelos continuamente. Algunos de los procedimientos
recomendados son los siguientes:
Propiedad: se debe asignar un propietario al proceso de supervisión del rendimiento del modelo a fin
de administrar activamente su rendimiento.
Canalizaciones de versión: configure una canalización de versión en Azure DevOps primero y
establezca el desencadenador en el registro de modelo. Cuando se registra un nuevo modelo en el
registro, la canalización de versión se desencadena y se aprueba en un proceso de implementación.
Requisitos previos para volver a entrenar modelos

La recopilación de datos de modelos en producción es un requisito previo para volver a entrenar modelos en un
marco de desarrollo continuo o de integración continua, y este proceso usa datos de entrada de solicitudes de
puntuación. Actualmente, esta funcionalidad está limitada a los datos tabulares que se pueden analizar como
JSON con un formato y manipulación mínimos. Se excluyen los vídeos, los audios y las imágenes. Esta
funcionalidad está disponible para los modelos en Azure Kubernetes Service (AKS). Los datos recopilados se
almacenan en un blob de Azure.
Para preparar el reentrenamiento de un modelo, haga lo siguiente:
1. Super vise el desfase de datos de los datos de entrada recopilados. La configuración de un
proceso de supervisión requiere la extracción de la marca de tiempo de los datos de producción. Esto se
requiere para comparar los datos de producción y los datos de la base de referencia (los datos de
entrenamiento que se usan para generar el modelo). La mejor manera de supervisar el desfase de datos
es a través de Azure Monitor Application Insights. Esta característica proporciona una alerta que puede
desencadenar acciones, como correo electrónico, texto SMS, inserciones o Azure Functions. Debe habilitar
Application Insights para registrar datos.
2. Analice los datos recopilados. Asegúrese de recopilar datos de los modelos en producción e incluya
los resultados en el script de puntuación del modelo. Recopile todas las características usadas para la
puntuación del modelo, ya que ello garantiza que existen todas las características necesarias y se pueden
usar como datos de entrenamiento.
3. Decida si es necesario volver a entrenarlo con los datos recopilados. Hay muchos factores que
causan el desfase de datos, incluidos los problemas del sensor en la estacionalidad, los cambios en el
comportamiento del usuario y los problemas de calidad de los datos relacionados con el origen de datos.
No es necesario volver a entrenar los modelos en todos los casos, por lo que, antes de hacerlo, se
recomienda investigar y comprender la causa del desfase de datos.
4. Vuelva a entrenar el modelo. El entrenamiento del modelo ya debe estar automatizado, y este paso
implica desencadenar el paso de entrenamiento actual. Esto podría ser cuando se ha detectado un
desfase de datos (y no está relacionado con un problema de datos) o cuando un ingeniero de datos ha
publicado una nueva versión de un conjunto de datos. En función del caso de uso, los usuarios pueden
automatizar o supervisar por completo estos pasos. Por ejemplo, aunque puede que algunos casos de
uso, como las recomendaciones de productos, se ejecuten de forma autónoma en el futuro, otros
relacionados con finanzas podrían tener en cuenta estándares, como la equidad y la transparencia del
modelo, y requerir que un usuario apruebe modelos recién entrenados.
En primer lugar, es habitual que una organización solo automatice el entrenamiento y la implementación de un
modelo, pero no los pasos de validación, supervisión y reentrenamiento, que se realizan manualmente.
Finalmente, los pasos de automatización de estas tareas pueden progresar hasta que se alcance el estado
deseado. Las operaciones de DevOps y aprendizaje automático son conceptos que se desarrollan a lo largo del
tiempo, y las organizaciones deben tener en cuenta su evolución.
El ciclo de vida del proceso de ciencia de datos en equipo

El proceso de ciencia de datos en equipo (TDSP) proporciona un ciclo de vida para estructurar el desarrollo de
los proyectos de ciencia de datos. El ciclo de vida describe las fases principales por las que pasan normalmente
los proyectos, a menudo de forma iterativa:
Conocimiento del negocio
Adquisición y comprensión de los datos
Modelado
Implementación
En el tema El ciclo de vida del proceso de ciencia de datos en equipo se describen los objetivos, las tareas y los
artefactos de documentación de cada fase del ciclo de vida de TDSP.
Roles y las actividades de las operaciones de aprendizaje automático

Según el ciclo de vida de TDSP, los roles clave del proyecto de IA son el ingeniero de datos, el científico de datos
y el ingeniero de operaciones de aprendizaje automático. Estos roles son fundamentales para el éxito del
proyecto y deben funcionar juntos a fin de lograr soluciones precisas, repetibles, escalables y listas para la
producción.
Ingeniero de datos: este rol ingiere, valida y limpia los datos. Una vez que se refinan los datos, se
catalogan y se ponen a disposición de los científicos de datos para su uso. En esta fase, es importante
explorar y analizar los datos duplicados, quitar los valores atípicos e identificar los datos que faltan. Estas
actividades se deben definir en los pasos de canalización y se ejecutan a medida que se realiza el
procesamiento previo de la canalización de entrenamiento. Los nombres únicos y específicos deben
asignarse a las características básicas y generadas.
Ingeniero de datos (o inteligencia de IA): este rol navega por el proceso de canalización de
entrenamiento y evalúa los modelos. Un científico de datos recibe datos del ingeniero de datos e
identifica patrones y relaciones en estos, posiblemente seleccionando o generando características para el
experimento. Dado que la ingeniería de características desempeña un papel importante en la creación de
un modelo generalizado de sonido, es fundamental que esta fase se complete lo mejor posible. Se
pueden realizar varios experimentos con distintos algoritmos e hiperparámetros. Las herramientas de
Azure, como el aprendizaje automático automatizado, pueden automatizar esta tarea, lo que también
puede permitir realizar un sobreajuste o un ajuste insuficiente en un modelo. A continuación, un modelo
entrenado correctamente se registra en el registro del modelo. El modelo debe tener un nombre único y
específico, y se debe conservar un historial de versiones con fines de rastreabilidad.
Ingeniero de operaciones de aprendizaje automático: este rol crea canalizaciones integrales para
la integración y entrega continuas. Incluye el empaquetado del modelo en una imagen de Docker, la
validación y generación de perfiles del modelo, la espera de la aprobación de una parte interesada y la
implementación del modelo en un servicio de orquestación de contenedores como AKS. Se pueden
establecer varios desencadenadores durante la integración continua, y el código del modelo puede
desencadenar la canalización de entrenamiento y la canalización de versión posteriormente.
Seguridad del aprendizaje automático
El aprendizaje automático presenta consideraciones de seguridad únicas para las empresas, y las empresas
deben tener en cuenta varios principios de seguridad al diseñar y evaluar arquitecturas de aprendizaje
automático.
Resistencia: los sistemas de aprendizaje automático deben identificar un comportamiento anómalo y
evitar la manipulación o la coerción.
Discreción : cualquier escenario de acceso a datos que implique la IA debe limitar el acceso a los datos lo
máximo posible.
Datos malintencionados: los algoritmos de aprendizaje automático deben protegerse frente a datos
introducidos de forma malintencionada.
Transparencia y responsabilidad: la inteligencia artificial debe tener funcionalidades forenses
integradas para brindar transparencia y responsabilidad. Estas funcionalidades funcionan como un
método temprano de detección de intrusiones de la IA para ayudar a los ingenieros a comprender el
momento exacto en el que se tomó la decisión y los datos que se usaron.
Entornos seguros: el acceso a los entornos de desarrollo, entrenamiento e inferencia debe estar
protegido a fin de proteger también los datos y los resultados y las predicciones del modelo.
Implementación de Azure Kubernetes Service para proteger un

entorno de inferencia
Se recomienda usar Azure Kubernetes Service (AKS) para la inferencia en un entorno de producción. Hay dos
opciones disponibles en la red virtual:
Implementar o adjuntar un clúster de AKS con una dirección IP pública a la red virtual.
Conectar un clúster de AKS privado a la red virtual.
Los clústeres de AKS predeterminados tienen un plano de control con una dirección IP pública. Si necesita una
dirección IP privada para el clúster de AKS, use el clúster de AKS privado. Para la inferencia, el clúster de AKS y el
área de trabajo de Azure Machine Learning deben estar en la misma red virtual.
Para proteger el clúster de inferencia de AKS predeterminado en la red virtual, especifique tres direcciones IP:
La notación CIDR especifica un inter valo de direcciones de AKS . No debe superponerse con ningún
otro intervalo IP de subred.
Se asigna una dirección IP del ser vicio DNS de AKS para el servicio DNS en AKS. Debe estar
comprendida en el intervalo de direcciones de AKS.
Se asigna una dirección de puente de Docker al puente de Docker, que ejecuta el script de puntuación
como un contenedor. Esta dirección no debe estar comprendida en el intervalo de direcciones IP de la
subred o AKS.
Puede configurar AKS para que use un equilibrador de carga interno y privado con un clúster de AKS privado.
Para este escenario, solo se permiten direcciones IP privadas, y puede usar un SDK de Python o una extensión de
línea de comandos de Azure, pero no Azure Machine Learning Studio para esta tarea. Al usar un equilibrador de
carga privado, debe conceder el rol de colaborador de red al grupo de recursos de clúster de AKS que contiene
la red virtual.
Pasos siguientes
Consulte cómo proteger un entorno de inferencia de Azure Machine Learning con redes virtuales para
ver un intervalo de direcciones IP y los pasos para realizar la inferencia en una red virtual.
Consulte la sección Rol de colaborador de red para aprender a configurar un equilibrador de carga
privado y un rol de colaborador de red.
Inferencia de aprendizaje automático durante la
implementación
Al implementar el modelo de IA durante la fase de producción, debe tener en cuenta cómo realizará las
predicciones. Los dos procesos principales de los modelos de IA son los siguientes:
Inferencia por lotes: proceso asincrónico que basa sus predicciones en un lote de observaciones. Las
predicciones se almacenan como archivos o en una base de datos para usuarios finales o aplicaciones
empresariales.
Inferencia en tiempo real (o interactiva): libera el modelo para que realice predicciones en cualquier
momento y desencadene una respuesta inmediata. Este patrón se puede usar para analizar datos de
streaming e interactivos de la aplicación.
Tenga en cuenta las siguientes preguntas para evaluar el modelo, comparar los dos procesos y seleccionar el
que mejor se adapte a su modelo:
¿Con qué frecuencia se deben generar las predicciones?
¿Con qué puntualidad se necesitan los resultados?
¿Se deben generar predicciones de forma individual, en lotes pequeños o en lotes grandes?
¿Se espera la latencia del modelo?
¿Cuánta capacidad de proceso se necesita para ejecutar el modelo?
¿Existen implicaciones y costos operativos para mantener el modelo?
El siguiente árbol de decisión puede ayudarle a determinar qué modelo de implementación se adapta mejor a
su caso de uso:
Inferencia por lotes

La inferencia por lotes, a veces denominada inferencia sin conexión, es un proceso de inferencia más sencillo
que permite que los modelos se ejecuten en intervalos de tiempo y las aplicaciones empresariales almacenen
predicciones.
Tenga en cuenta los siguientes procedimientos recomendados para la inferencia por lotes:
Desencadenar la puntuación por lotes: utilice canalizaciones de Azure Machine Learning y la
característica de ParallelRunStep de Azure Machine Learning para configurar una programación o una
automatización basada en eventos. Vaya a la presentación de IA para realizar la inferencia por lotes con
Azure Machine Learning ParallelRunStep y obtener más información sobre el proceso.
Opciones de proceso para la inferencia por lotes: dado que los procesos de inferencia por lotes no
se ejecutan de forma continua, se recomienda iniciar, detener y escalar automáticamente los clústeres
reutilizables que pueden controlar una amplia variedad de cargas de trabajo. Los diferentes modelos
requieren entornos distintos, y la solución debe poder implementar un entorno específico y quitarlo
cuando la inferencia finalice para que el proceso esté disponible para el modelo siguiente. Vea el árbol de
decisión siguiente para identificar la instancia de proceso correcta para el modelo:
Implementar la inferencia por lotes: Azure admite varias características para la inferencia por lotes.
Una característica es ParallelRunStep en Azure Machine Learning, que permite a los clientes obtener
conclusiones a partir de terabytes de datos estructurados o no estructurados almacenados en Azure.
ParallelRunStep proporciona un paralelismo listo para usarse en canalizaciones de Azure Machine
Learning.
Desafíos de la inferencia por lotes: aunque la inferencia por lotes es una forma más sencilla de usar
e implementar el modelo en producción, presenta desafíos determinados:
En función de la frecuencia con la que se ejecuta la inferencia, los datos generados podrían ser
irrelevantes en el momento en que se accede a ellos.
Una variación del problema de inicio en frío. Es posible que los resultados no estén disponibles
para los nuevos datos. Por ejemplo, si un nuevo usuario crea una cuenta e inicia la compra con un
sistema de recomendación de venta directa, las recomendaciones de productos no estarán
disponibles hasta que después de la siguiente ejecución de la inferencia por lotes. Si este es un
obstáculo para su caso de uso, considere la posibilidad de usar la inferencia en tiempo real.
La implementación en muchas regiones y la alta disponibilidad no son problemas críticos en un
escenario de inferencia por lotes. No es necesario implementar el modelo por regiones, y es
posible que sea necesario implementar el almacén de datos con una estrategia de alta
disponibilidad en muchas ubicaciones. Normalmente, se seguirá el diseño y la estrategia de alta
disponibilidad de la aplicación.
Inferencia en tiempo real

La inferencia en tiempo real, o interactiva, es una arquitectura en la que la inferencia del modelo se puede
desencadenar en cualquier momento y se espera una respuesta inmediata. Este patrón se puede usar para
analizar datos de streaming, interactivos de la aplicación, etc. Este modo le permite aprovechar el modelo de
aprendizaje automático en tiempo real y resolver el problema de inicio en frío descrito anteriormente en la
inferencia por lotes.
Las siguientes consideraciones y procedimientos recomendados están disponibles si la inferencia en tiempo real
es adecuada para el modelo:
Desafíos de la inferencia en tiempo real: los requisitos de latencia y rendimiento hacen que la
arquitectura de inferencia en tiempo real sea más compleja para el modelo. Un sistema puede necesitar
responder en 100 milisegundos o menos, en cuyo tiempo debe recuperar los datos, realizar la inferencia,
validar y almacenar los resultados del modelo, ejecutar cualquier lógica de negocios necesaria y devolver
los resultados al sistema o a la aplicación.
Opciones de proceso para la inferencia en tiempo real: la mejor manera de implementar la
inferencia en tiempo real es implementar el modelo en un formulario de contenedor de un clúster de AKS
o Docker y exponerlo como un servicio web con la API REST. De este modo, el modelo se ejecuta en su
propio entorno aislado y se puede administrar como cualquier otro servicio web. Luego, las
funcionalidades de Docker o AKS se pueden usar para la administración, la supervisión, el escalado y
mucho más. El modelo se puede implementar de forma local, en la nube o en el perímetro. La decisión de
proceso anterior describe la inferencia en tiempo real.
Implementación en varias regiones y alta disponibilidad: la implementación regional y las
arquitecturas de alta disponibilidad se deben tener en cuenta en escenarios de inferencia en tiempo real,
ya que la latencia y el rendimiento del modelo serán cuestiones complicadas de resolver. Para reducir la
latencia en implementaciones en varias regiones, se recomienda localizar el modelo que esté lo más
cerca posible del punto de consumo. El modelo y la infraestructura compatible deben cumplir los
principios y la estrategia de alta disponibilidad y recuperación ante desastres de la empresa.
Escenario de varios modelos

Un modelo singular podría no ser capaz de capturar la naturaleza compleja de los problemas del mundo real,
como predecir las ventas de un supermercado en el que los datos demográficos, la marca, las SKU y otras
características pueden hacer que el comportamiento del cliente varíe de forma significativa. Las regiones
podrían hacer que el desarrollo del mantenimiento predictivo para los medidores inteligentes también varíe
significativamente. El hecho de contar con muchos modelos para estos escenarios a fin de capturar datos
regionales o relaciones a nivel de tienda podría generar una mayor precisión que un solo modelo. En este
enfoque se supone que hay suficientes datos disponibles para este nivel de granularidad.
En un nivel alto, un escenario de varios modelos se produce en tres fases: origen de datos, ciencia de datos y
muchos modelos.
Origen de datos: es importante segmentar los datos sin demasiadas cardinalidades en la fase del origen de
datos. El identificador del producto o el código de barras no se deben factorizar en la partición principal, ya que
esto producirá demasiados segmentos y podría impedir que los modelos sean significativos. La marca, la SKU o
la ubicación pueden ser características más adecuadas. También es importante quitar aquellas anomalías que
podrían sesgar la distribución de los datos a fin de homogeneizar los datos.
Ciencia de datos: en la fase de la ciencia de datos, se ejecutan varios experimentos en paralelo en cada
partición de datos. Este suele ser un proceso iterativo en el que se evalúan los modelos de los experimentos
para determinar cuál es el mejor.
Varios modelos: los mejores modelos para cada segmento o categoría se registran en el registro del modelo.
Asigne nombres descriptivos a los modelos a fin de que sean más detectables para la inferencia. Use el
etiquetado cuando sea necesario para agrupar el modelo en categorías específicas.
Inferencia por lotes para varios modelos

Durante la inferencia por lotes para varios modelos, normalmente las predicciones se programan de forma
periódica y pueden controlar grandes volúmenes de datos que se ejecutan al mismo tiempo. A diferencia de lo
que ocurre en un escenario de un solo modelo, muchos modelos infieren al mismo tiempo, de modo que es
importante seleccionar los correctos. En el diagrama siguiente se muestra el patrón de referencia para la
inferencia por lotes de varios modelos:
El objetivo principal de este patrón es observar el modelo y ejecutar varios modelos simultáneamente para
lograr una solución de inferencia muy escalable que pueda controlar grandes volúmenes de datos. Para lograr la
inferencia jerárquica del modelo, muchos modelos se pueden dividir en categorías. Cada categoría puede tener
su propio almacenamiento de inferencia, como un lago de datos de Azure. Al implementar este patrón, es
necesario equilibrar el escalado horizontal y vertical de los modelos, ya que esto afectaría al costo y al
rendimiento. Ejecutar demasiadas instancias de modelos podría aumentar el rendimiento, pero el costo podría
verse afectado. Tener muy pocas instancias con nodos de alta especificación podría resultar más rentable, pero
podrían producirse problemas con el escalado.
Inferencia en tiempo real para varios modelos

La inferencia en tiempo real para varios modelos requiere baja latencia y solicitudes a petición, normalmente a
través de un punto de conexión REST. Esto resulta útil cuando las aplicaciones o los servicios externos requieren
una interfaz estándar para interactuar con el modelo, normalmente a través de una interfaz REST con una carga
JSON.
El objetivo principal de este patrón es usar el servicio de detección para identificar una lista de servicios y sus
metadatos. Esto puede implementarse como una función de Azure y permite a los clientes obtener los detalles
pertinentes del servicio, que se pueden invocar con un URI de REST seguro. Se envía una carga JSON al servicio,
que llama el modelo pertinente y proporciona una respuesta JSON al cliente.
Cada servicio es un microservicio sin estado que puede controlar varias solicitudes simultáneamente y se limita
al recurso de máquina virtual física. El servicio puede implementar varios modelos si se seleccionan varios
grupos. Para ello, se recomiendan agrupaciones homogéneas, como la categoría, la SKU, etc. La asignación entre
la solicitud de servicio y el modelo seleccionado para un servicio determinado debe incorporarse a la lógica de
inferencia, normalmente a través del script de puntuación. Si el tamaño de los modelos es relativamente
pequeño (unos pocos megabytes), se recomienda cargarlos en la memoria por motivos de rendimiento. De lo
contrario, cada modelo se puede cargar dinámicamente por solicitud.
Pasos siguientes
Explore los siguientes recursos para obtener más información sobre la inferencia con Azure Machine Learning:
Compilación de una canalización de Azure Machine Learning para la puntuación por lotes
Ejecución de la predicción por lotes mediante el diseñador de Azure Machine Learning
Inferencia por lotes en Azure Machine Learning
Determinación de las instancias de proceso,
desarrollo y entrenamiento para el modelo de
A la hora de determinar las instancias de proceso, desarrollo y entrenamiento para el modelo de aprendizaje
automático, tenga en cuenta el algoritmo que usa, el tipo de datos, los tamaños de los datos y si va a realizar el
entrenamiento distribuido.
Desarrollo y entrenamiento del modelo de aprendizaje automático

Consulte el diagrama siguiente para comprender el desarrollo y el entrenamiento del modelo de aprendizaje
automático:
Instancias de proceso del modelo de aprendizaje automático

El diagrama siguiente puede ayudarle a elegir las instancias de proceso que permiten al modelo de aprendizaje
automático ejecutar la inferencia:
Pasos siguientes
Cree y administre una instancia de proceso en el área de trabajo de Azure Machine Learning para
comprender el proceso con más detalle.
Obtenga información sobre los destinos de proceso en Azure Machine Learning para conocer cómo estos
entornos pueden ayudarle a entrenar e implementar el modelo durante el ciclo de vida de desarrollo.
Configuración de las áreas de trabajo de
Entornos de aprendizaje automático y control de acceso basado en

roles
Los entornos de desarrollo, pruebas y producción admiten procesos de operaciones de aprendizaje automático.
En un entorno de desarrollo: las canalizaciones de aprendizaje automático deben ser compatibles con las
actividades de ingeniería y ciencia de datos que realizan los científicos e ingenieros de datos. Deben tener
permisos completos relacionados con los experimentos en ejecución, como el aprovisionamiento de clústeres
de entrenamiento o la creación de modelos. Sin embargo, no deben tener permiso para actividades como
eliminar o crear áreas de trabajo, o agregar o quitar usuarios del área de trabajo.
En un entorno de pruebas: se realizan varias pruebas en el entorno del modelo, y se deben usar las de tipo
champion/challenger o A/B para el modelo. El entorno de prueba debe imitar el entorno de implementación y
debe realizar pruebas como las de carga, el tiempo de respuesta del modelo, etc. Los ingenieros y científicos de
datos tienen acceso limitado a este entorno (principalmente, acceso de solo lectura y algunos derechos de
configuración). Un ingeniero de DevOps tiene acceso total al entorno. Automatización de tantas pruebas como
sea posible. Una vez completadas todas las pruebas, se requiere la aprobación de las partes interesadas para la
implementación en el entorno de producción.
En un entorno de producción: se implementa un modelo durante la inferencia por lotes o en tiempo real.
Normalmente, un entorno de producción es de solo lectura; sin embargo, un ingeniero de DevOps tiene acceso
total a este entorno y es responsable de ofrecer soporte técnico y mantenimiento continuamente. Los
ingenieros y científicos de datos tienen acceso limitado al entorno (de solo lectura).
En el diagrama siguiente se muestra el control de acceso basado en roles para todos los entornos:
En esta tabla se muestra que los niveles de acceso de los ingenieros y científicos de datos se reducen en
entornos más altos, mientras que el acceso de los ingenieros de DevOps aumenta. Esto se debe a que un
ingeniero de operaciones de aprendizaje automático crea la canalización, reúne cosas e implementa modelos en
producción. Este nivel de granularidad se recomienda para cada rol.
Factores que influyen en las áreas de trabajo de aprendizaje

automático
Hay varios factores que pueden influir en la forma en que configura las áreas de trabajo de aprendizaje
automático y que pueden ayudarle a determinar la mejor estructura y controles para cada tipo de área de
trabajo:
Pública, restringida:
Área de trabajo de desarrollo, pruebas y producción
Rol personalizado: Científico de datos
Integración de GIT para el control de versiones y la integración continua y desarrollo continuo (CI/CD)
Pública, sin restricciones:
Rol: colaborador
Integración de GIT para el control de versiones y CI/CD
Privada, restringida:
Private Link habilitado
Rol personalizado: Científico de datos
Privada, sin restricciones:
Private Link habilitado
Rol: colaborador
Todas las áreas de trabajo:
Un área de trabajo de Estudio de Azure Machine Learning por proyecto
Una instancia de proceso por científico de datos
Un clúster de proceso por tamaño de máquina virtual compartido con científicos de datos para
desarrollo
Un clúster de proceso por canalización de producción
Establecer el tamaño mínimo de nodo del clúster de proceso en 0 para reducir los costos
Indicar a los usuarios que cierren las instancias de proceso manualmente después del uso
Un rol personalizado de "administrador de área de trabajo" con acceso para crear instancias de
proceso y clústeres
Un rol personalizado de "científico de datos" que requiere la configuración de toda la infraestructura
por parte de otro usuario antes de que el científico de datos pueda empezar a trabajar
Pasos siguientes
Obtenga más información sobre cómo crear y administrar un área de trabajo en Azure Machine Learning.
Use el SDK de Python para crear un área de trabajo en su entorno de desarrollo.
Use los cuadernos de Jupyter y Azure Portal durante el ciclo de vida de desarrollo para configurar el
entorno de desarrollo de Azure Machine Learning y entrenar el modelo.
Microsoft destaca seis principios rectores para la inteligencia artificial responsable: responsabilidad, inclusión,
confiabilidad y seguridad, equidad, transparencia y privacidad y seguridad. Estos principios son esenciales para
crear inteligencia artificial de confianza y responsable a medida que se incorpora en productos y servicios más
convencionales. Se regirán por dos perspectivas: ética y explicable.
Ética
Desde una perspectiva ética, la inteligencia artificial deben ser equitativa e inclusiva en sus aserciones,
responsable de sus decisiones y no discriminar ni obstaculizar diferentes razas, discapacidades o conocimientos.
Microsoft estableció un comité ético para la inteligencia artificial, la ética y los efectos en la ingeniería e
investigación (Aether), en 2017. La responsabilidad principal del comité es informar sobre temas, tecnologías,
procesos y procedimientos recomendados responsables. Obtenga más información sobre Aether en este
módulo de Microsoft Learn.
Rendición de cuentas
La responsabilidad es un pilar esencial de la inteligencia artificial responsable. Las personas que diseñan e
implementan el sistema de inteligencia artificial deben ser responsables de sus acciones y decisiones,
especialmente a medida que progresamos hacia sistemas más autónomos. Las organizaciones deben considerar
la posibilidad de establecer un cuerpo de revisión interno que proporcione supervisión, conclusiones y
orientación sobre el desarrollo e implementación de sistemas de inteligencia artificial. Aunque esta guía puede
variar en función de la empresa y la región, debe reflejar el recorrido de la inteligencia artificial de una
organización.
Inclusión
La inclusión exige que la inteligencia artificial tenga en cuenta todas las razas y experiencias humanas, y las
prácticas de diseño inclusivas pueden ayudar a los desarrolladores a comprender y abordar las barreras
potenciales que podrían excluir involuntariamente a personas. Siempre que sea posible, se debe usar la
tecnología de reconocimiento visual, de voz a texto y de texto a voz a fin de empoderar a los usuarios con
discapacidades auditivas, visuales y otras.
Confiabilidad y seguridad
Los sistemas de inteligencia artificial deben ser confiables y seguros para que los usuarios puedan confiar en
ellos. Es importante que un sistema se ejecute según lo previsto originalmente y que responda de forma segura
a las nuevas situaciones. Su resistencia inherente debe soportar la manipulación prevista o imprevista. Se deben
establecer rigurosas pruebas y validaciones para las condiciones de funcionamiento con el fin de garantizar que
el sistema responde de forma segura a los casos extremos. Además, las pruebas A/B y los métodos de tipo
champion/challenger deben integrarse en el proceso de evaluación.
El rendimiento de un sistema de inteligencia artificial puede reducirse con el tiempo. Por este motivo, es
necesario establecer un proceso de supervisión y seguimiento de modelos sólido a fin de medir de forma
reactiva y proactiva el rendimiento del modelo y volver a entrenarlo, según sea necesario, a fin de modernizarlo.
Qué puede explicarse

La explicabilidad permite a los científicos de datos, auditores y responsables de la toma de decisiones
empresariales garantizar que los sistemas de inteligencia artificial pueden justificar razonablemente sus
decisiones y cómo llegan a sus conclusiones. Así mismo, garantiza el cumplimiento de directivas de la empresa,
estándares del sector y reglamentos gubernamentales. Un científico de datos debe ser capaz de explicar a la
parte interesada cómo logró determinados niveles de precisión y lo que influyó en este resultado. Del mismo
modo, para cumplir con las directivas de la empresa, un auditor necesita una herramienta que valide el modelo,
y un encargado de la toma de decisiones empresariales debe ser capaz de proporcionar un modelo transparente
con el fin de obtener confianza.
Herramientas con explicabilidad
Microsoft ha desarrollado InterpretML, un kit de herramientas de código abierto que ayuda a lograr la
explicabilidad del modelo y admite modelos de caja negra y caja de cristal.
Los modelos de caja de cristal se pueden interpretar debido a su estructura. En el caso de estos modelos,
utilice una máquina que potencie la explicabilidad, que es el estado del algoritmo basado en un árbol de
decisión o modelos lineales, proporciona explicaciones sin pérdida y la pueden editar expertos en el
dominio.
Los modelos de caja negra son más difíciles de interpretar debido a que tienen una estructura interna
compleja, la red neuronal. Los explicadores como LIME o SHapley Additive exPlanations (SHAP)
interpretan estos modelos mediante el análisis de la relación entre la entrada y la salida.
Fairlearn es una integración de Azure Machine Learning y un kit de herramientas de código abierto para
el SDK y la interfaz gráfica de usuario de AutoML. Use los explicadores para comprender las principales
influencias del modelo y cuente con expertos en el dominio para validar dichas influencias.
Explore la interpretación del modelo en Azure Machine Learning para obtener más información sobre la
explicabilidad.
Imparcialidad
La equidad es un principio ético básico que todos los seres humanos tienen como objetivo comprender y aplicar.
Este principio aún es más importante cuando se desarrollan sistemas de inteligencia artificial. Las
comprobaciones y verificaciones clave deben garantizar que las decisiones del sistema no discriminan ni aplican
ningún sesgo de sexo, raza, orientación sexual o religión respecto a un grupo o una persona.
Microsoft proporciona una lista de comprobación de equidad de inteligencia artificial que ofrece
instrucciones y soluciones para sistemas de inteligencia artificial. Estas soluciones se clasifican de forma
flexible en cinco fases: planeamiento, prototipo, compilación, lanzamiento y evolución. Cada fase muestra
las actividades de diligencia debida recomendadas que ayudan a minimizar el impacto de la falta de
equidad en el sistema.
Fairlearn se integra con Azure Machine Learning y permite a los científicos de datos y desarrolladores
evaluar y mejorar la equidad de sus sistemas de inteligencia artificial. El cuadro de herramientas
proporciona varios algoritmos de mitigación de inequidad y un panel interactivo que visualiza la equidad
del modelo. Use el kit de herramientas y evalúe atentamente la equidad del modelo mientras se cree. Esto
debe ser una parte integral del proceso de ciencia de datos.
Obtenga información sobre cómo mitigar la equidad en los modelos de aprendizaje automático.
Transparencia
Al conseguir transparencia, el equipo puede comprender los datos y algoritmos que se usan para entrenar el
modelo, la lógica de transformación que se aplicó a los datos, el modelo final generado y sus recursos
asociados. Esta información ofrece conclusiones sobre cómo se creó el modelo, lo que permite reproducirlo de
forma transparente. Las instantáneas de las áreas de trabajo de Azure Machine Learning admiten la
transparencia mediante el registro o reentrenamiento de todos los recursos y métricas relacionados con el
entrenamiento implicados en el experimento.
Privacidad y seguridad
Un propietario de datos está obligado a proteger los datos en un sistema de IA, y la privacidad y la seguridad
son una parte integral de este sistema. Los datos personales deben estar protegidos, y el acceso a estos debe
realizarse de forma que no ponga en peligro la privacidad de ningún individuo. La privacidad diferencial de
Azure protege y conserva la privacidad mediante la selección aleatoria de datos y la adición de ruido para
ocultar información personal a los científicos de datos.
Directrices de la inteligencia artificial centrada en el usuario

Las directrices del diseño de la inteligencia artificial centrada en el usuario se componen de 18 principios que
tienen lugar a lo largo de cuatro periodos: en el inicio, durante la interacción, cuando es incorrecto y a lo largo
del tiempo. Estos principios están diseñados para generar un sistema de inteligencia artificial más inclusivo y
centrado en el usuario.
En el inicio
Aclare lo que puede hacer el sistema. Si el sistema de inteligencia artificial usa o genera métricas, es
importante mostrarlas todas e indicar cómo se realiza el seguimiento.
Aclare la eficacia en la que el sistema puede realizar su función. Ayude a los usuarios a
comprender que la IA no será completamente precisa y establezca expectativas sobre las situaciones en
que el sistema de IA puede cometer errores.
Durante la interacción
Muestre información per tinente contextualmente. Proporcione información visual relacionada con
el contexto y el entorno actuales del usuario, como hoteles cercanos, y devuelva detalles cercanos al
destino y la fecha seleccionados.
Mitigue los sesgos sociales. Asegúrese de que el idioma y el comportamiento no presentan
estereotipos ni sesgos no deseados. Por ejemplo, una característica de tipo autocompletar debe
reconocer ambos sexos.
Cuando es incorrecto
Admita una opción para descar tar que sea eficaz. Proporcione un mecanismo sencillo para omitir o
descartar características o servicios no deseados.
Admita una corrección eficaz. Proporcione una manera intuitiva de facilitar la edición, el refinamiento o
la recuperación.
Clarifique el motivo de la acción del sistema. Optimice la inteligencia artificial explicable para ofrecer
conclusiones sobre las aserciones del sistema de IA.
A lo largo del tiempo
Recuerde las interacciones recientes. Conserve un historial de interacciones para futuras referencias.
Aprenda del compor tamiento de los usuarios. Personalice la interacción en función del
comportamiento del usuario.
Realice actualizaciones y adaptaciones con precaución. Limite los cambios perturbadores y haga
actualizaciones según el perfil del usuario.
Anime a los usuarios a realizar comentarios pormenorizados. Recopile comentarios de los usuarios
sobre sus interacciones con el sistema de IA.
Un marco de inteligencia artificial de confianza centrado en la

persona
Diseñador de IA
El diseñador de IA crea el modelo y es responsable de lo siguiente:
Realizar comprobaciones de calidad y desfase de datos. Detectan valores atípicos y realizan
comprobaciones de calidad de datos para identificar los valores que faltan, estandarizar la distribución,
examinar los datos y generar informes de casos de uso y de proyectos.
Evaluar los datos en el origen del sistema para identificar posibles sesgos.
El diseño de algoritmos de inteligencia artificial para minimizar las sesgos de datos, como la detección de
la discretización, la agrupación y la normalización (especialmente en los modelos de aprendizaje
automático tradicionales, como los basados en árboles) pueden eliminar los grupos minoritarios de los
datos. El diseño de IA por categorías reitera los sesgos de los datos mediante la agrupación de clases
sociales, raciales y de género en los segmentos verticales del sector que dependen de la información
médica protegida (PHI) e información de identificación personal (PII).
Optimizar la supervisión y las alertas para identificar la pérdida de destinos y fortalecer el desarrollo del
modelo.
Establecer los procedimientos recomendados para la creación de informes y las conclusiones que ofrecen
una comprensión pormenorizada del modelo, y evitar enfoques de caja negra que utilizan la importancia
de características o vectores, la agrupación en clústeres de UMAP, la estadística H de Friedman, efectos de
características, etc. Las métricas de identificación ayudan a definir influencias, relaciones y dependencias
predictivas entre correlaciones en conjuntos de valores complejos y modernos.
Administradores y responsables de la inteligencia artificial
El administrador y los responsables de la IA supervisan las operaciones del marco de inteligencia artificial,
gobierno y auditoría y las métricas de rendimiento, además de cómo se implementa la seguridad de la IA y del
retorno de la inversión de la empresa.
Supervisión de un panel de seguimiento que ayuda a supervisar el modelo, combina métricas del
modelo para modelos de producción y se centra en la precisión, degradación del modelo, el desfase de
datos, la desviación y los cambios en la velocidad/error de inferencia.
La realización de una implementación y reimplementación flexibles (preferiblemente, la API REST)
permite que los modelos se implementen en una arquitectura abierta e independiente, que integra el
modelo con procesos de negocio y genera un valor para los bucles de comentarios.
Al trabajar en la creación de la gobernanza y el acceso de los modelos, se establecen límites y se mitiga el
impacto empresarial y operativo negativo. Los estándares de control de acceso basado en roles
determinan los controles de seguridad, que conservan los entornos de producción restringidos y la IP.
Uso de los marcos de auditoría y cumplimiento de inteligencia artificial para realizar un seguimiento de
cómo los modelos desarrollan y cambian para cumplir los estándares específicos del sector. La IA
interpretable y responsable se basa en medidas de explicabilidad, características concisas, visualizaciones
de modelos y lenguaje del segmento vertical del sector.
Consumidor empresarial de IA
Los consumidores empresariales de IA (expertos empresariales) cierran el bucle de comentarios y proporcionan
entradas para el diseñador de IA. La toma de decisiones predictiva y las posibles implicaciones de sesgo, como
la equidad y las medidas éticas, la privacidad y el cumplimiento y la eficiencia empresarial, ayudan a evaluar los
sistemas de IA.
Los bucles de comentarios pertenecen al ecosistema de una empresa. Los datos que muestran el sesgo,
los errores, la velocidad de predicción y la equidad de un modelo establecen la confianza y el equilibrio
entre el diseñador, el administrador y los responsables de la IA. La evaluación centrada en el usuario
debería mejorar gradualmente la IA a lo largo del tiempo. Además, el hecho de minimizar el aprendizaje
de la IA a partir de datos complejos y multidimensionales (aprendizaje "LO-shot") puede ayudar a
prevenir el aprendizaje sesgado.
El uso de herramientas y el diseño de interpretabilidad responsabiliza a los sistemas de IA de posibles
sesgos. Los problemas de sesgo y equidad del modelo deben marcarse y enviarse a un sistema de alerta
y detección de anomalías que aprenda de este comportamiento y aborde automáticamente los sesgos.
Cada valor predictivo debe desglosarse en características o vectores individuales según la importancia o
el impacto, así como ofrecer explicaciones de predicción detalladas que se puedan exportar a un informe
empresarial para realizar revisiones de auditoría y cumplimiento, con fines de transparencia del cliente y
para la preparación comercial.
Debido al aumento de los riesgos globales de seguridad y privacidad, los procedimientos recomendados
para resolver infracciones de datos durante la inferencia requieren el cumplimiento de regulaciones de
los segmentos verticales concretos del sector, por ejemplo, alertas sobre incumplimiento de la
información PHI y PII, infracción de las leyes de seguridad nacional, etc.
Pasos siguientes
Explore las instrucciones de la IA centrada en el usuario para obtener más información sobre la IA responsable.
¿Qué son las aplicaciones de IA?
Las aplicaciones de inteligencia artificial incluyen elementos como las API de reconocimiento de voz, las API de
Computer Vision, las API de lógica de decisiones y otros tipos de sistemas inteligentes que imitan la razón
humana. Estas son funciones esenciales de muchos productos de software del mercado actual, ya que las
aplicaciones de inteligencia artificial pueden comunicarse con los usuarios finales de una forma más natural y
ofrecer una mejor experiencia de usuario. Azure puede ayudarle a usted y a su equipo a ahorrar tiempo
mediante la implementación de aplicaciones de inteligencia artificial en cualquier lugar.
En Azure, puede compilar aplicaciones inteligentes más rápido con las herramientas y tecnologías que prefiera y
la inteligencia artificial integrada.
Compile e implemente fácilmente en cualquier par te: utilice su conjunto preferido de aptitudes y
herramientas de su equipo para compilar aplicaciones inteligentes e implementarlas sin cambiar el código.
Se compila solo una vez y se implementa en la nube, en el entorno local y en dispositivos perimetrales.
Puede estar seguro de que la distribución global se realizará a más centros de datos que con cualquier otro
proveedor.
Genere impacto con una plataforma abier ta : elija sus tecnologías favoritas, incluido el código abierto.
Azure admite una amplia gama de opciones de implementación, pilas y lenguajes populares, y un conjunto
completo de motores de datos. Aproveche esta flexibilidad, junto con el rendimiento, la escala y la seguridad
que ofrecen las tecnologías de Microsoft, para crear aplicaciones para cualquier escenario.
Desarrolle aplicaciones con inteligencia integrada: La creación de aplicaciones inteligentes con Azure
es fácil, porque ninguna otra plataforma aporta análisis e IA nativa a los datos dondequiera que se
encuentren y en los lenguajes que use. Aproveche las ventajas de un completo conjunto de API cognitivas
para compilar fácilmente nuevas experiencias en sus aplicaciones con el fin de obtener inteligencia de tipo
humano.
¿Qué es Azure Cognitive Services?

Azure Cognitive Services simplifica la integración de funcionalidades e innovaciones de inteligencia artificial en
las aplicaciones con unas pocas líneas de código sencillas. Ayuda a crear aplicaciones que vean, oigan, hablen,
comprendan e incluso comiencen un razonamiento en los procesos empresariales. Cognitive Services
proporciona inteligencia artificial de manera que sea fácil de usar e incorporar en las aplicaciones.
Cognitive Services está compuesto por las API, los SDK y los servicios disponibles para ayudar a los
desarrolladores a compilar aplicaciones inteligentes sin necesidad de inteligencia artificial directa o aptitudes ni
conocimientos sobre ciencia de datos. Cognitive Services permite a los desarrolladores agregar fácilmente
características cognitivas en sus aplicaciones. El catálogo de servicios de Cognitive Services se puede dividir en
cinco pilares principales: visión, voz, lenguaje, búsqueda web y decisión.
API Computer Vision
N O M B RE DEL SERVIC IO DESC RIP C IÓ N DEL SERVIC IO
Computer Vision Proporciona acceso a algoritmos avanzados para procesar

imágenes y devolver información.
Custom Vision Permite compilar clasificadores personalizados de imágenes.

Face Proporciona acceso a algoritmos faciales avanzados que

permiten la detección y el reconocimiento de atributos
faciales.
Form Recognizer (versión preliminar) Identifica y extrae los pares clave-valor y los datos de tabla
de formularios. A continuación, genera una salida de datos
estructurados que incluye las relaciones en el archivo
original.
Video Indexer Video Indexer permite extraer información de vídeos.
API de reconocimiento de voz

Voz El servicio de voz agrega a las aplicaciones características

habilitadas por voz.
Speaker Recognition (versión preliminar) Speaker Recognition API proporciona algoritmos para la
identificación y la verificación del hablante.
Bing Speech (retirada) Puede migrar aplicaciones de API Bing Speech existentes al
servicio Voz.
Translator Speech (retirada) Puede migrar aplicaciones de API Bing Translator Speech
existentes al servicio Voz.
API de idioma
Language Understanding (LUIS) Language Understanding Service (LUIS) permite que la

aplicación entienda lo que una persona quiere en sus propias
palabras.
QnA Maker Permite compilar un servicio de preguntas y respuestas a

partir de contenido semiestructurado.
Text Analytics Proporciona procesamiento de lenguaje natural en texto sin

formato para el análisis de opiniones, la extracción de frases
clave y la detección del idioma.
Traductor Proporciona la traducción automática de texto casi en

tiempo real.
API de lógica de decisiones

Anomaly Detector (versión preliminar) Anomaly Detector permite supervisar y detectar anomalías
en datos de series temporales.
Content Moderator Content Moderator proporciona la supervisión de posibles

contenidos ofensivos, indeseables y peligrosos.
Personalizer Permite aprender del comportamiento de los usuarios en

tiempo real para elegir la experiencia más personalizada para
ellos.
Idiomas culturales admitidos

Cognitivas Services admite una amplia gama de idiomas culturales en el nivel de servicio. Puede encontrar la
disponibilidad de idiomas para cada API en la lista de idiomas admitidos.
Recursos seguros
Cognitive Services proporciona un modelo de seguridad por niveles, que incluye la autenticación con
credenciales de Azure Active Directory, una clave de recurso válida y Azure Virtual Network.
Compatibilidad con los contenedores
Cognitive Services proporciona contenedores para la implementación en la nube o en un entorno local.
Obtenga más información sobre contenedores de Cognitive Services.
Certificaciones y cumplimiento
Cognitive Services ha recibido certificaciones, como la certificación CSA STAR, FedRAMP Moderate y HIPAA BAA.
Para conocer la administración de los datos y la privacidad, vaya al Centro de confianza de Microsoft
¿En qué se parecen Cognitive Services y Azure Machine Learning?

Cognitive Services y Azure Machine Learning tienen el objetivo común de aplicar inteligecia artificial para
mejorar las operaciones empresariales. La manera de proporcionar esta funcionalidad en las ofertas
correspondientes difiere de uno a otro. Por lo general, las audiencias son diferentes:
Cognitive Services es para desarrolladores sin experiencia en aprendizaje automático.
Machine Learning se adapta a los científicos de datos.
¿En qué se diferencia un servicio cognitivo del aprendizaje

automático?
Un servicio cognitivo proporciona un modelo entrenado. Este modelo une los datos y un algoritmo, y está
disponible desde un SDK o una API REST. Puede implementar este servicio en cuestión de minutos, en función
de su escenario. Un servicio cognitivo proporciona respuestas a problemas generales, como frases clave en
texto o identificación de elementos en imágenes.
El aprendizaje automático es un proceso que generalmente requiere un período de tiempo más largo para
implementarse correctamente. Este tiempo se emplea en la recopilación de datos, la limpieza, la transformación,
la selección de algoritmos, el entrenamiento de modelos y la implementación para llegar al mismo nivel de
funcionalidad proporcionado por un servicio cognitivo. Con el aprendizaje automático, es posible proporcionar
respuestas a problemas muy especializados o específicos. Para los problemas de aprendizaje automático, es
necesario estar familiarizado con la materia y los datos específicos del problema en cuestión, así como tener
conocimientos sobre ello.
Pasos siguientes
Más información sobre Cognitive Services.
Busque los procedimientos recomendados para arquitecturas de inteligencia artificial.
¿Qué son los agentes de inteligencia artificial?
Los agentes de inteligencia artificial consisten en código o mecanismos que actúan para lograr objetivos
predeterminados. Puede encontrar ejemplos de agentes de inteligencia artificial en el código de elementos
como bots de chat, hogares inteligentes y el software comercial mediante programación que se usa en finanzas.
Azure Bot Service y Bot Framework son ejemplos de plataformas que se pueden usar para crear estos agentes
de inteligencia artificial e integrarlos en aplicaciones de software de mayor tamaño.
Los usuarios interactúan cada vez más con interfaces de conversación que pueden ofrecer una experiencia más
natural en la que las personas expresan sus necesidades a través de expresiones de lenguaje natural y
completan tareas con rapidez. Para muchas empresas, las aplicaciones de inteligencia artificial conversacionales
están convirtiéndose en un diferenciador competitivo. Muchas organizaciones están haciendo que los bots estén
disponibles de forma estratégica en las mismas plataformas de mensajería que utilizan sus clientes.
Las organizaciones de todo el mundo están transformando sus negocios gracias a la inteligencia artificial de
conversación, la cual puede promover unas interacciones más eficientes y naturales con sus clientes y sus
empleados. A continuación, se presentan algunos casos de uso:
Servicio al cliente
Asistente empresarial
Optimización del centro de llamadas
Asistente de voz para el coche
Creación de un bot
Azure Bot Service y Bot Framework ofrecen un conjunto integrado de herramientas y servicios que le ayudarán
a crear el agente de inteligencia artificial que necesite. Elija el entorno de desarrollo o las herramientas de línea
de comandos que prefiera para crear el bot. Existen SDK para C#, JavaScript, Typescript y Python. El SDK para
Java está en desarrollo. Proporcionamos herramientas para varias etapas del desarrollo de bots para ayudarle a
diseñar y crear bots.
Plan
Tener un conocimiento exhaustivo de los objetivos, los procesos y las necesidades de los usuarios es importante
para el proceso de creación de un bot potente. Antes de escribir código, revise las directrices de diseño del bot
para seguir los procedimientos recomendados e identificar las necesidades del bot. Puede crear un agente de
inteligencia artificial sencillo o incluir funcionalidades más sofisticadas, como la voz, el reconocimiento de
lenguaje natural y la respuesta a preguntas.
Al diseñar el agente de inteligencia artificial durante la fase de planeamiento, tenga en cuenta estos aspectos:
Definición de los roles del bot:
¿Qué aspecto debería tener el bot?
¿Cómo se denominará?
¿Cuál es la personalidad del bot? ¿Tendrá género?
¿Cómo debe manejar el bot situaciones y preguntas difíciles?
Diseño del flujo conversacional:
¿Cuál es el tipo de conversaciones que prevé para sus casos de uso?
Definición de un plan de evaluación:
¿Cómo se puede medir el éxito?
¿Qué medidas desea usar para mejorar el servicio?
Para más información sobre el diseño del bot, consulte Principios de diseño de bots.
Build
Un bot es un servicio web que implementa una interfaz de conversación y que se comunica con el servicio Bot
Framework para enviar y recibir mensajes y eventos. Bot Framework Service es uno de los componentes de
Azure Bot Service y Bot Framework. Se pueden crear bots en cualquier número de entornos y lenguajes. Puede
comenzar el desarrollo del bot en Azure Portal o usar plantillas de C#, JavaScript o Python para el desarrollo
local. También tiene acceso a una variedad de ejemplos que presentan muchas de las funcionalidades
disponibles a través del SDK. Estos ejemplos son magníficos para los desarrolladores que desean un punto de
partida con muchas más características.
Como parte de Azure Bot Service y Bot Framework, ofrecemos componentes adicionales que se pueden usar
para ampliar la funcionalidad del bot. Con Azure Bot Service y Bot Framework, puede crear un bot con confianza
y rapidez.
C A RA C T ERÍST IC A DESC RIP C IÓ N VÍN C ULO
Agregar procesamiento de lenguaje Habilite el bot para que reconozca el Uso de LUIS
natural lenguaje natural y los errores de
ortografía, use la voz, y reconozca la
intención del usuario.
Responder preguntas Agregue una knowledge base para Uso de QnA Maker
responder a las preguntas que los
usuarios formulen de forma más
natural y conversacional.
Administrar varios modelos Si usa más de un modelo, por ejemplo, Herramienta de distribución
para LUIS y para QnA Maker,
determine de manera inteligente
cuándo usar cada uno de ellos durante
la conversación del bot.
Agregar tarjetas y botones Mejore la experiencia del usuario con Procedimientos para agregar tarjetas
medios distintos al texto, como
gráficos, menús y tarjetas.
NOTE
Esta tabla no es una lista completa. Para más información, consulte la documentación de Azure Bot Service.
Prueba
Los bots son aplicaciones complejas con muchos elementos distintos que funcionan conjuntamente. Como
cualquier otra aplicación compleja, esta complejidad puede provocar errores interesantes o que el bot se
comporte de forma diferente a la esperada. Antes de publicar el bot, pruébelo. Hay varias maneras de probar los
bots antes de ponerlos en funcionamiento:
Pruebe el bot localmente con el emulador. Bot Framework Emulator es una aplicación independiente que no
solo proporciona una interfaz de chat, sino también herramientas de depuración y consulta que ayudan a
conocer el funcionamiento del bot. El emulador se puede ejecutar localmente junto con la aplicación del bot
en desarrollo.
Pruebe el bot en la Web. Una vez configurado el bot mediante Azure Portal, también se puede acceder a él
desde una interfaz de chat web, que es una excelente manera de conceder acceso al bot tanto a los
evaluadores como a otras personas que no tienen acceso directo al código de ejecución.
Realice una prueba unitaria del bot con la actualización de julio del SDK de Bot Framework.
Publicar
Cuando esté listo para que el bot esté disponible en Internet, publíquelo en Azure o en su propio servicio web o
centro de datos. Tener una dirección en la red pública de Internet es el primer paso para que el bot cobre vida en
su sitio web o en los canales de chat.
Conectar
Conecte el bot a canales como Facebook, Messenger, Kik, Slack, Microsoft Teams, Telegram, mensajes de texto o
SMS, Twilio, Cortana y Skype. Bot Framework realiza la mayor parte del trabajo necesario para enviar y recibir
mensajes de todas estas plataformas diferentes. La aplicación de bot recibe una secuencia unificada y
normalizada de mensajes independientemente del número y del tipo de canales a los que esté conectado. Para
más información sobre la incorporación de canales, consulte Canales.
Evaluate
Use los datos recopilados en Azure Portal para identificar oportunidades para mejorar las funcionalidades y el
rendimiento del bot. Puede obtener nivel de servicio y datos de instrumentación como tráfico, latencia e
integraciones. Analytics proporciona también informes en el nivel de conversación relativos a los datos del
usuario, los mensajes y los canales. Para más información, consulte el artículo acerca de cómo recopilar análisis.
Patrones para casos de uso habituales
Hay patrones habituales que se usan para la implementación de una aplicación de inteligencia artificial de
conversación:
Knowledge base : Puede diseñar un bot de conocimientos para proporcionar información sobre
prácticamente cualquier tema. Por ejemplo, un bot de conocimientos podría responder a preguntas sobre
eventos, como "¿Qué actos sobre bots se celebran en esta conferencia?" o "¿Cuándo es el próximo
concierto de reggae?" Otro bot podría responder a preguntas sobre TI, por ejemplo, "¿Cómo actualizo el
sistema operativo?" Otro incluso podría responder a preguntas sobre contactos, como "¿Quién es John
Doe?" o "¿Cuál es la dirección de correo electrónico de Jane Doe?".
Para más información sobre los elementos de diseño de los bots de conocimiento, consulte Diseño de
bots de conocimientos.
Paso a una persona : independientemente de la inteligencia artificial que posea un bot, puede haber
ocasiones en las que sea necesario pasar la conversación a una persona. En tales casos, el bot debe
reconocer esta necesidad y que la transición sea fácil para el usuario.
Para más información sobre los patrones para este paso, consulte Paso de conversaciones de un bot a
una persona.
Inserción de un bot en una aplicación : aunque los bots normalmente existen fuera de las
aplicaciones, también pueden integrarse en ellas. Por ejemplo, puede insertar un bot de conocimientos en
una aplicación para ayudar a los usuarios a buscar información. Podría también insertar un bot en una
aplicación del departamento de soporte técnico para que actúe como primer respondedor de las
solicitudes entrantes de los usuarios. El bot podría resolver problemas sencillos de manera independiente
y derivar problemas más complejos a un agente humano.
Para más información sobre las maneras de integrar el bot en una aplicación, consulte Inserción de un
bot en una aplicación.
Inserción de un bot en un sitio web : al igual que en las aplicaciones, los bots también se pueden
insertar en un sitio web para habilitar varios modos de comunicación entre canales.
Para más información sobre las maneras de integrar su bot en un sitio web, consulte Inserción de un bot
en un sitio web.
Pasos siguientes
Consulte las notas del producto sobre aprendizaje automático y los libros electrónicos acerca de Azure Bot
Service.
Revise las arquitecturas de IA + aprendizaje automático.
Creación de aplicaciones inteligentes con las API cognitivas (libro electrónico).
Preguntas frecuentes sobre la arquitectura del bot.
¿Qué es Azure Cognitive Search?
Azure Cognitive Search (anteriormente conocido como Azure Search) es una solución administrada en la nube
que proporciona a los desarrolladores las API y herramientas necesarias para agregar una experiencia de
búsqueda de datos enriquecida en un contenido privado y heterogéneo en las aplicaciones web, para
aplicaciones móviles y empresariales. El código o una herramienta invoca la ingesta de datos (indexación) para
crear y cargar un índice. Opcionalmente, puede agregar aptitudes cognitivas para aplicar procesos de
inteligencia artificial durante la indexación. Mediante el uso de Azure Cognitive Services puede agregar nueva
información y estructuras útiles para escenarios de búsqueda y de otros tipos.
En el otro lado del servicio, el código de la aplicación genera solicitudes de consulta y controla las respuestas. La
experiencia de búsqueda se define en el cliente mediante el uso de funciones de Azure Cognitive Search, con la
ejecución de consultas en un índice persistente que crea, es de su propiedad y almacena en el servicio.
Azure Cognitive Search es una funcionalidad importante de las aplicaciones. La capacidad de encontrar
rápidamente los datos importantes es fundamental para la experiencia y los resultados del usuario final. El
motor de Azure Cognitive Search usa la funcionalidad de inteligencia artificial que ayuda a las aplicaciones a
trabajar de forma más humana y a realizar asociaciones que van más allá de la mera coincidencia de palabras
clave. Azure Cognitive Services puede ayudar a los usuarios finales a encontrar lo que quieren saber, de forma
más rápida.
La funcionalidad se expone a través de API de REST o SDK de .NET sencillos que enmascaran la complejidad
inherente de la recuperación de información. Además de las API, Azure Portal proporciona soporte
administrativo y de administración de contenido, con herramientas para la creación de prototipos y la consulta
de índices. Como el servicio se ejecuta en la nube, Microsoft administra la infraestructura y la disponibilidad.
Cuándo usar Azure Cognitive Search

Azure Cognitive Search es adecuado en los siguientes escenarios de aplicación:
Consolidación de tipos de contenido heterogéneos en un único índice privado que admita búsquedas. Las
consultas siempre se encuentran sobre un índice que se crea y se carga con los documentos. El índice
siempre reside en la nube en la instancia de Azure Cognitive Search. Puede rellenar un índice con secuencias
de documentos JSON de cualquier origen o plataforma. Como alternativa, para el contenido proporcionado
en Azure, puede usar un indexador para introducir datos en un índice. Definir el índice y la propiedad o
administración son uno de los principales motivos para usar Azure Cognitive Search.
El contenido sin procesar incluye texto grande no diferenciado, archivos de imagen o archivos de aplicación,
como los tipos de contenido de Microsoft Office en un origen de datos de Azure, como Azure Blob Storage o
Azure Cosmos DB. Puede aplicar aptitudes cognitivas durante la indexación para agregar una estructura o
extraer significado de los archivos de imagen y de aplicación.
Implementación sencilla de las características relacionadas con la búsqueda. Las API de Azure Cognitive
Search simplifican la creación de consultas, la navegación por facetas, el filtrado (incluida la búsqueda
geoespacial), la asignación de sinónimos, las consultas de escritura anticipada y la optimización de la
relevancia. Mediante el uso de las características integradas, puede satisfacer las expectativas del usuario y
ofrecer una experiencia de búsqueda similar a la de los motores de búsqueda web comerciales.
Indexación del texto no estructurado, o bien, extracción de texto e información de archivos de imagen. La
característica de enriquecimiento con inteligencia artificial de Azure Cognitive Search agrega procesamiento
con inteligencia artificial a una canalización de indexación. Algunos casos de uso comunes son OCR en
documentos digitalizados, reconocimiento de entidades y extracción de frases clave en documentos de gran
tamaño, detección del idioma y traducción de textos, y análisis de opinión.
Cumplimiento de los requisitos lingüísticos gracias al uso de analizadores de idioma y personalizados de
Azure Cognitive Search. Si tiene contenido que no está en inglés, Azure Cognitive Search admite tanto los
analizadores de Lucene como los procesadores de lenguaje natural de Microsoft. También puede configurar
los analizadores para obtener un procesamiento especializado de contenido sin procesar, como el filtrado de
los caracteres diacríticos.
Uso de Azure Cognitive Search

Paso 1: aprovisionamiento del servicio
Puede aprovisionar una instancia de Azure Cognitive Search en Azure Portal o mediante la API REST de Azure
Resource Manager. Puede elegir cualquier servicio gratuito compartido con otros suscriptores o un nivel de
pago que dedica recursos que solo usa su servicio. Para los niveles de pago, es posible escalar un servicio en
dos dimensiones:
Agregar réplicas para aumentar su capacidad de administrar cargas de consulta elevadas.
Agregar particiones para aumentar el almacenamiento de más documentos.
Controlar el almacenamiento de documentos y el procesamiento de consultas por separado, con lo que podrá
calibrar los recursos en función de los requisitos de producción.
Paso 2: Creación de un índice
Para cargar el contenido en el que quiere realizar búsquedas, primero debe definir un índice de Azure Cognitive
Search. Un índice es como una tabla de base de datos que contiene los datos y puede aceptar consultas de
búsqueda. El esquema de índice se define para su asignación y reflejo en la estructura de los documentos que
desee buscar, igual que los campos de una base de datos.
Se puede crear un esquema en Azure Portal o mediante programación con el SDK de .NET o la API REST.
Paso 3: Cargar datos
Una vez definido un índice, estará listo para cargar contenido. Puede usar un modelo de inserción o de
extracción.
El modelo de extracción recupera datos de orígenes de datos externos. Se admite mediante indexadores que
agilizan y automatizan diversos aspectos de la ingesta de datos, como conectarse, leer y serializar datos. Los
indexadores están disponibles para las instancias de Azure Cosmos DB, Azure SQL Database, Azure Blob Storage
y SQL Server hospedadas en una máquina virtual de Azure. Puede configurar un indexador para una
actualización de datos programada o a petición.
El modelo de inserción se proporciona a través del SDK o las API de REST usadas para enviar documentos
actualizados a un índice. Se pueden insertar datos desde prácticamente cualquier conjunto de datos con el
formato JSON. Para más información, consulte Agregar, actualizar o eliminar documentos o Uso del SDK de .NET
para instrucciones sobre la carga de datos.
Paso 4: Search
Tras completar un índice, puede generar consultas de búsqueda para el punto de conexión de servicio mediante
solicitudes HTTP sencillas con API REST o el SDK de .NET. Consulte Creación de la primera aplicación de
búsqueda para crear y, posteriormente, ampliar una página web que recoja los datos que especifique el usuario
y controle los resultados. También puede usar llamadas a Postman para REST interactivo o el Explorador de
búsqueda integrado en Azure Portal para consultar un índice existente.
Pasos siguientes
Más información sobre Azure Cognitive Search.
Examinar más arquitecturas de inteligencia artificial.
Consulte una solución de minería de conocimientos de ejemplo en el artículo de ejemplo de arquitectura y
solución de los archivos de JFK.
Innovación en la economía digital
La economía digital es una fuerza innegable en casi todos los sectores. Durante la revolución industrial, la
gasolina, las cintas transportadoras y el ingenio humano fueron recursos clave para impulsar la innovación en el
mercado. La calidad del producto, el precio y la logística inciden en el mercado, mientras las empresas buscan
ofrecer mejores productos a sus clientes con más rapidez. La economía digital actual cambia el modo en que los
clientes interactúan con las organizaciones. Como resultado, las principales formas de capital y los
diferenciadores de mercado también han cambiado. En la economía digital, los clientes están menos
preocupados por la logística y más por su experiencia general de uso de un producto. Este cambio surge de la
interacción directa con la tecnología en nuestras vidas diarias y del descubrimiento de las propuestas de valor
asociadas a esas interacciones.
En la metodología de innovación de Cloud Adoption Framework, nos centraremos en comprender las
necesidades de los clientes y en crear rápidamente innovaciones que se adapten al modo en que los clientes
interactúan con sus productos. Ilustraremos también el valor que aporta entregar un producto viable mínimo.
Por último, veremos la correspondencia entre las decisiones comunes y los ciclos de innovación para ayudarle a
entender cómo la nube puede dar rienda suelta a la innovación y crear asociaciones con sus clientes.
Metodología innovadora
La siguiente imagen ilustra la metodología sencilla de la innovación en la nube dentro de Cloud Adoption
Framework. En los artículos posteriores de esta sección se muestra cómo establecer los principales procesos,
enfoques y mecanismos de innovación para buscar e impulsar la innovación en su empresa.
En esta serie de artículos se destacan los siguientes aspectos de esta metodología:

En primer lugar, comience siempre con la adopción del cliente para crear bucles de comentarios que generen
asociaciones con los clientes basadas en el proceso crear-medir-aprender.
En segundo lugar, examine los enfoques para desarrollar inventos digitales que prioricen la adopción.
En la siguiente sección se describe qué es la innovación, cuál es su fórmula y los compromisos necesarios para
tener éxito con este enfoque.
Fórmula para la innovación

La innovación es el desarrollo y la aplicación de ideas que mejoran la forma en que se realizan las cosas o lo que
se puede lograr.
El éxito en la innovación no es un evento de transformación espectacular ni un escurridizo unicornio mágico. El
éxito en la innovación es más una acción de equilibrio, que se ilustra con una sencilla ecuación: innovación =
invención + adopción .
La innovación se produce en la intersección entre la invención y la adopción. Una verdadera innovación es el
resultado del ajuste lento de las experiencias humanas mediante nuevos enfoques, nuevos procesos y nuevas
tecnologías. En esta fórmula, invención significa crear una nueva solución que satisfaga las necesidades de los
clientes. Por el contrario, adopción significa aplicar la nueva solución para dar forma a los comportamientos y
las interacciones de los usuarios. La búsqueda del equilibrio adecuado entre la invención y la adopción requiere
iteración, toma de decisiones controlada por datos, aprendizaje constante y mentalidad de crecimiento. También
requiere tecnologías que puedan seguir el ritmo de las innumerables oportunidades de aprendizaje que ofrece
la actual economía digital.
La nube suele ser una plataforma excelente para la invención o los aspectos tecnológicos de la innovación.
Lamentablemente, la mayoría de las grandes ideas fracasan durante el duro proceso de adopción y no durante
los procesos de creación o invención. Para garantizar su éxito, los equipos de desarrollo deben comenzar
siempre por la adopción como prueba de innovación. Para usar esta metodología, el equipo debe aceptar estos
tres compromisos:
Compromiso para dar prioridad a los clientes frente a la tecnología
Compromiso con la transparencia
Compromiso con la iteración
Compromisos culturales
La adopción de la metodología de innovación requiere algunos compromisos culturales para usar de forma
efectiva las métricas que se describen en este artículo. Antes de cambiar el enfoque para impulsar la innovación,
asegúrese de que los equipos de adopción y dirección están preparados para asumir estos importantes
compromisos.
Compromiso para dar prioridad a los clientes frente a la tecnología

Cada equipo de desarrollo tiene un conjunto de herramientas o tecnologías con las que están más
familiarizados. Es aconsejable aprovechar esos puntos fuertes y usar lo que ya se conoce. Sin embargo, para que
la innovación tenga éxito, los equipos deben mantener su atención tanto en las necesidades del cliente como en
la hipótesis que se está probando. En ocasiones, es posible que este enfoque no esté en línea con las
funcionalidades de una herramienta o un enfoque de arquitectura determinados. Para que la innovación tenga
éxito, el equipo de desarrollo debe mantener una mentalidad abierta. Durante el proceso de invención, las
decisiones técnicas deben centrarse en las necesidades del cliente frente a las preferencias de su equipo.
Compromiso con la transparencia

Para comprender las medidas en un enfoque de innovación, primero debe comprender el compromiso con la
transparencia. La innovación solo puede prosperar en un entorno que se adhiera a una mentalidad de
crecimiento. En la raíz de una mentalidad de crecimiento se encuentra un imperativo cultural que incita a
aprender de la experiencia. El éxito en la innovación y el aprendizaje continuo comienzan con un compromiso
con la transparencia en las medidas. Este es un compromiso valiente por parte del equipo de adopción de la
nube. Sin embargo, ese compromiso no tiene sentido si no tiene correspondencia con un compromiso para
conservar la transparencia dentro de los equipos de dirección y estrategia en la nube.
La transparencia es importante porque medir el impacto del cliente no aborda la pregunta de si es correcto o
incorrecto. Las medidas del impacto tampoco indican la calidad del trabajo ni el rendimiento del equipo de
adopción. En cambio, representan la oportunidad de aprender y satisfacer mejor las necesidades de los clientes.
El uso incorrecto de las métricas de innovación anula esa cultura. En última instancia, este uso incorrecto
conducirá a la manipulación de las métricas, lo que a su vez conducirá a errores a largo plazo de la invención, el
personal de soporte técnico y, en última instancia, la estructura de administración que ha utilizado los datos
incorrectamente. Tanto los líderes como los colaboradores deben evitar el uso de medidas para otra cosa que no
sea una oportunidad de aprender y mejorar el producto viable mínimo.
Compromiso con la iteración

Solo hay una certeza en todos los ciclos de innovación: no saldrá bien a la primera. Las medidas ayudan a
comprender qué ajustes se deben hacer para lograr los resultados deseados. Los cambios que conducen a los
resultados favorables provienen de las iteraciones del proceso crear-medir-aprender. El equipo de adopción de
la nube y el equipo de estrategia en la nube deben comprometerse a mantener una mentalidad iterativa antes
de adoptar una mentalidad de crecimiento o un enfoque crear-medir-aprender.
Pasos siguientes
Antes de crear el siguiente gran invento, empiece por la adopción del cliente, para lo cual debe comprender el
bucle de comentarios crear-medir-aprender.
Adopción del cliente con el bucle de comentarios crear-medir-aprender
Creación de consenso sobre el valor empresarial de
la innovación
El primer paso para desarrollar cualquier innovación nueva es identificar la forma en que puede impulsar el
valor empresarial. En este ejercicio, debe responder a una serie de preguntas que destacan la importancia de
invertir bastante tiempo cuando la organización define el valor empresarial.
¿Qué es el valor empresarial?

El valor empresarial es un término informal que puede variar de negocio a negocio. Es el beneficio neto que
realiza el cliente e incluye todos los tipos de valor, que determina el estado y el bienestar de la empresa a la
larga.
Calificación de preguntas para determinar el valor empresarial

Antes de desarrollar cualquier innovación o solución de valor empresarial (ya sea en la nube o de forma local),
responda a las preguntas siguientes para validar los criterios de valor empresarial:
1. ¿Qué necesidad definida del cliente quiere satisfacer con esta solución?
2. ¿Qué oportunidades creará esta solución para la empresa?
3. ¿Qué resultados empresariales se lograrán con esta solución?
4. ¿Qué motivación de la empresa se atenderá con esta solución?
Si las respuestas a las cuatro preguntas están bien documentadas, es posible que no necesite realizar el resto de
este ejercicio. Afortunadamente, puede probar cualquier documentación fácilmente. Configure dos reuniones
breves para probar la documentación y la alineación interna de su organización. Invite a las partes interesadas
del negocio confirmadas a una reunión y configure una reunión aparte con el equipo de desarrollo
comprometido. Formule las cuatro preguntas anteriores a cada uno de los grupos y compare los resultados.
NOTE
La documentación existente no se debe compartir con ninguno de los equipos antes de la reunión. Si existe una
verdadera alineación, los miembros de cada grupo deben mencionar (o mejor aún, recitar) las hipótesis orientadoras.
WARNING
No facilite la reunión. Esta prueba está destinada a determinar la alineación; no es un ejercicio para crear una alineación. Al
iniciar la reunión, recuerde a los asistentes que el objetivo es probar la alineación direccional con los acuerdos existentes
dentro del equipo. Establezca un límite de tiempo de cinco minutos para cada pregunta. Establezca un temporizador y
cierre cada pregunta transcurridos cinco minutos, aunque los asistentes no hayan acordado una respuesta.
Tenga en cuenta los distintos idiomas e intereses de cada grupo. Si la prueba da como resultado respuestas
alineadas direccionalmente, considere que el ejercicio ha sido una victoria. Está listo para pasar al desarrollo de
la solución.
Si una o dos de las respuestas están alineadas direccionalmente, reconozca que el trabajo duro compensa. Ya se
ha alineado mejor que la mayoría de las organizaciones. Es probable que se produzca un éxito futuro, con una
pequeña inversión continua en la alineación. Revise en cada una de las siguientes secciones las ideas que
pueden ayudarle a crear más alineación.
Si alguno de los equipos no responde a las cuatro preguntas en 30 minutos, es probable que la alineación y las
consideraciones de las siguientes secciones tengan un gran impacto sobre este y otros esfuerzos. Preste especial
atención a cada una de las siguientes secciones.
Observe primero la perspectiva general

Cloud Adoption Framework sigue una ruta prescrita en cuatro fases: creación de estrategia, planeamiento,
preparación y adopción. La innovación empresarial en la nube encaja en la fase de adopción de este proceso.
Las respuestas a las preguntas calificadoras tres y cuatro están relacionadas con los resultados y las
motivaciones. Cuando estas respuestas están mal alineadas, significa que la organización ha pasado algo por
alto durante la fase de creación de estrategia del ciclo de vida de la adopción de la nube. Es probable que se
produzcan algunos de los escenarios siguientes.
Opor tunidad de alineación: cuando las partes interesadas de la empresa no pueden acordar las
motivaciones ni los resultados empresariales relacionados con un esfuerzo de innovación en la nube del
negocio, esto es síntoma de un desafío mayor. Los ejercicios de la metodología de estrategia pueden ser
útiles para desarrollar la alineación entre las partes interesadas de la empresa. Además, se recomienda
encarecidamente que las mismas partes interesadas formen un equipo de estrategia en la nube que se
reúna con regularidad.
Opor tunidad de comunicación: Cuando el equipo de desarrollo no puede acordar las motivaciones y
los resultados empresariales, puede ser un síntoma de brechas en la comunicación estratégica. Para
resolver rápidamente este problema, puede revisar la estrategia en la nube con el equipo de adopción de
la nube. Varias semanas después de la revisión, el equipo debe repetir el ejercicio de preguntas
calificadoras.
Opor tunidad de priorización: Una estrategia en la nube es esencialmente una hipótesis de nivel
ejecutivo. Las mejores estrategias en la nube están abiertas a la iteración y los comentarios. Si ambos
equipos entienden la estrategia, pero todavía no pueden alinear las respuestas a estas preguntas, es
posible que las prioridades no estén alineadas. Organice una sesión con el equipo de adopción de la nube
y el equipo de estrategia en la nube. Esta sesión puede ser útil para el trabajo de ambos grupos. El equipo
de adopción de la nube comienza compartiendo sus respuestas alineadas con las preguntas calificadoras.
A partir de ahí, una conversación entre el equipo de adopción de la nube y el equipo de estrategia en la
nube puede resaltar oportunidades para alinear mejor las prioridades.
Estas oportunidades generales suelen revelar maneras de alinear mejor la solución innovadora con la estrategia
en la nube. Este ejercicio tiene dos resultados comunes:
Estas conversaciones pueden ayudar a su equipo a mejorar la estrategia en la nube de la organización y a
representar mejor las necesidades importantes del cliente. Este cambio puede dar lugar a un mayor soporte
ejecutivo para el equipo.
Por el contrario, estas conversaciones pueden indicar que el equipo de adopción de la nube debe invertir en
una solución diferente. En este caso, considere la posibilidad de migrar esta solución antes de continuar con
la inversión en innovación. Como alternativa, estas conversaciones pueden indicar que adopta un enfoque de
desarrollador cívico para probar primero el valor empresarial. En cualquier caso, ayudarán al equipo a evitar
una gran inversión con un retorno empresarial limitado.
Solucionar la alineación de la solución

Es bastante habitual que las respuestas a las preguntas uno y dos estén mal alineadas. Durante las primeras
fases de concepción y desarrollo, la necesidad de los clientes y la oportunidad de negocio a menudo no se
alinean. Muchos equipos de desarrollo perciben como un reto conseguir un equilibrio entre demasiada y poca
definición. Cloud Adoption Framework recomienda enfoques eficaces como los bucles de comentarios crear-
medir-aprender para responder a estas preguntas. En la lista siguiente se muestran las oportunidades y los
enfoques para crear la alineación.
Opor tunidad de hipótesis: Es habitual que varias partes interesadas y equipos de desarrollo tengan
demasiadas expectativas para una solución. Las expectativas irreales pueden ser un signo de que la hipótesis
es demasiado imprecisa. Siga las instrucciones que se indican en Creación con la empatía de los clientes para
construir una hipótesis más clara.
Opor tunidad de creación: es posible que los equipos no estén alineados porque no están de acuerdo en
la forma de resolver las necesidades del cliente. Este desacuerdo suele indicar que el equipo está retrasado
por un pico técnico prematuro. Para que el equipo se centre en el cliente, inicie la primera iteración y cree un
producto mínimo viable (MVP) pequeño para abordar parte de la hipótesis. Para obtener más información,
consulte Desarrollo de inventos digitales.
Opor tunidad de aprendizaje: cualquier equipo puede estar mal alineado porque necesita requisitos
técnicos profundos y requisitos funcionales amplios. Esta necesidad puede conducir a una oportunidad de
entrenamiento en metodologías ágiles. Cuando la referencia cultural del equipo no está lista para los
procesos ágiles, puede resultar difícil innovar y seguir el ritmo del mercado. Para obtener información sobre
los recursos de aprendizaje sobre DevOps y las prácticas ágiles, consulte:
Logre que sus prácticas de DevOps evolucionen
Creación de aplicaciones con Azure DevOps
Implementación de aplicaciones con Azure DevOps
El seguimiento de la metodología de innovación y las herramientas de administración del trabajo pendiente de
cada sección de este artículo pueden ayudarle a crear la alineación de la solución.
Pasos siguientes
Una vez que la propuesta de valor empresarial esté bien alineada y la haya comunicado, está listo para empezar
a compilar la solución.
Volver a los ejercicios de innovación para los pasos siguientes
Crear asociaciones con los clientes a través del
bucle de comentarios crear-medir-aprender
La verdadera innovación proviene del duro trabajo de creación de soluciones que muestran la empatía de los
clientes, a partir de la medición del impacto de los cambios en el cliente y a partir del aprendizaje con el cliente.
Lo más importante es que proviene de los comentarios realizados durante varias iteraciones.
Si la pasada década nos ha enseñado algo sobre la innovación, es que las antiguas reglas empresariales han
cambiado. Los que hoy son prósperos ya no conservan de forma ininterrumpida su posición en el mercado. El
primer contendiente en comercializar el producto (o el mejor) no siempre es el ganador. Tener la mejor idea no
conduce a dominar el mercado. En un clima empresarial de cambios rápidos, los líderes del mercado son los
más ágiles.
Las empresas grandes o pequeñas que prosperan en la economía digital como líderes innovadores son las que
tienen la mejor capacidad de escuchar a su base de clientes. Esa aptitud puede ser cultivada y administrada. En
el centro de todas las buenas asociaciones entre clientes siempre hay un bucle de comentarios claro. El proceso
para crear asociaciones con los clientes dentro del marco de adopción de la nube es el bucle de comentarios
crear-medir-aprender.
¿Qué es el bucle de comentarios de compilación, medida y

aprendizaje?
El bucle de comentarios de compilación, medida y aprendizaje es una descripción del proceso para la creación
de empatía con los clientes, la medición de sus reacciones y la opción de aprender qué ajustes son necesarios
para mejorar las interacciones con ellos. Tal y como se describe en Innovación en la economía digital, la
innovación requiere un equilibrio entre la invención y adopción. Los comentarios de los clientes y la asociación
impulsan la adopción. Al convertir a los clientes en asociados firmes y fieles durante los ciclos de innovación,
puede obtener mejores productos y ganar terreno rápidamente en el mercado.
Este proceso de administración de asociaciones con los clientes y su integración en los esfuerzos de innovación
incluye tres fases de desarrollo:
Crear con la empatía de los clientes
Aprender con los clientes
Cada fase del proceso del bucle de comentarios de compilación, medida y aprendizaje le ayuda a crear
soluciones mejores con sus clientes.
Pasos siguientes
Obtenga información sobre cómo crear con la empatía de los clientes para comenzar el ciclo crear-medir-
aprender.
Crear con la empatía de los clientes
Creación con la empatía de los clientes
"La necesidad es la madre la invención". Este proverbio captura la durabilidad del espíritu humano, así como
nuestro impulso natural de inventario. Tal y como se explica en el Oxford English Dictionary, "cuando se torna
imperativa la necesidad de algo, estás obligado a encontrar formas de conseguirlo". Pocas personas podrían
negar estas verdades universales sobre las invenciones. No obstante, como se describe en Innovación en la
economía digital, la innovación en la nube requiere un equilibrio entre la invención y adopción.
Para continuar con la analogía, la innovación proviene de una familia más amplia. La empatía hacia el cliente es
el padre orgulloso de la innovación. La creación de una solución de empatía con los clientes que impulse la
innovación requiere que el cliente legítimamente necesite volver para resolver sus desafíos críticos. Estas
soluciones se basan en lo que el cliente necesita, en lugar de en lo que quiere o desea. Para detectar sus
verdaderas necesidades, comenzamos con la empatía: una comprensión profunda de la experiencia del cliente.
Se trata de una aptitud poco desarrollada para muchos ingenieros, administradores de productos e incluso
líderes empresariales. Afortunadamente, las diversas interacciones y el rápido ritmo del rol de arquitecto de la
nube probablemente ya ha empezado a desarrollar esta aptitud.
¿Cómo se genera la empatía y por qué es tan importante la empatía con los clientes? La empatía con los clientes
nos ayuda a comprender y compartir la experiencia de los clientes. Desde la primera versión de un producto
mínimo viable (MVP) hasta la disponibilidad general de una solución apta para el mercado, la empatía con los
clientes nos ayuda a crear una mejor solución. Y lo que es aún más importante, nos posiciona mejor para
inventar soluciones que fomentarán la adopción. En una economía digital, los usuarios que pueden empatizar
inmediatamente con las necesidades del cliente pueden crear un futuro más brillante que redefina y lidere el
mercado.
Cómo crear con la empatía con los clientes

La definición de supuestos es una parte fundamental de la planificación. Cuanto más extenso sea el
planeamiento, mayor será el volumen de suposiciones que sustentarán la base de una gran idea. Las
suposiciones tienden a ser el producto de la autoempatía. En otras palabras: ¿qué es lo que querría si estuviera
en esta posición? A partir de la fase de creación se minimiza el período en que las suposiciones pueden invadir
una solución. Este enfoque también acelera el bucle de comentarios con clientes reales, lo que desencadena
oportunidades anteriores para aprender y centrar la empatía.
Cau t i on
La definición correcta de lo que se va a crear puede ser complicado y requiere alguna práctica. Si se crea algo
demasiado rápido, si es posible que no refleje las necesidades de los clientes. Si dedica demasiado tiempo a
intentar comprender las necesidades iniciales del cliente y los requisitos de la solución, el mercado puede
satisfacer dichas necesidades antes de que pueda crear algo siquiera. En cualquier escenario, la oportunidad de
aprender se puede retrasar o reducir considerablemente. A veces, los datos pueden estar dañados.
Las soluciones más innovadoras de la historia comenzaron con una creencia intuitiva. Ese presentimiento
proviene de la experiencia existente y de la observación de primera mano. Comenzamos con la fase de creación
porque permite realizar una prueba rápida de esa intuición. A partir de ahí, podemos cultivar una comprensión
más profunda y unos grados de empatía más claros. En cada iteración o versión de una solución, el saldo
procede de la creación de un MVP que demuestran la empatía hacia el cliente.
Para fijar este acto de equilibrio, en las dos secciones siguientes se describen los conceptos para crear con
empatía y definir un MVP.
Definición de una hipótesis centrada en el cliente
La creación con empatía significa crear una solución basada en hipótesis definidas que ilustran una necesidad
específica del cliente. Los pasos siguientes pretenden formular una hipótesis para fomentar la creación con
empatía.
1. Cuando se crea con empatía, el cliente siempre es el centro de atención. Esta intención puede adoptar
muchas formas. Puede hacer referencia a un arquetipo de cliente, a un rol específico o incluso a la imagen de
un cliente con el problema que quiere resolver. Tenga en cuenta que los clientes pueden ser internos
(empleados o asociados) o externos (consumidores o clientes empresariales). Esta definición es la primera
hipótesis que se va a poner a prueba: ¿podemos ayudar a este cliente específico?
2. Comprender la experiencia del cliente. La creación con empatía significa que puede verse reflejado en la
experiencia del cliente y comprender sus desafíos. Esta forma de pensar lleva a la siguiente hipótesis que se
va a poner a prueba: ¿podemos ayudar a este cliente específico a solucionar este desafío manejable?
3. Definir una solución sencilla para un único desafío. Depender de la experiencia de las personas, los procesos
y los expertos en la materia conducirá a una posible solución. Esta es la hipótesis completa que se va a poner
a prueba: ¿podemos ayudar a este cliente específico a solucionar este desafío manejable con la solución
apropiada?
4. Llegar a una instrucción de valor. ¿Qué valor a largo plazo espera proporcionar a estos clientes? La respuesta
a esta pregunta constituye la hipótesis completa: ¿cómo mejorará la vida de los clientes con el uso de la
solución propuesta para abordar este desafío manejable?
Este último paso es la culminación de una hipótesis guiada por la empatía con los clientes. Define a la audiencia,
el problema, la solución y la métrica por la que se va a realizar la mejora, todo ello centrado en el cliente.
Durante las fases de medida y aprendizaje, se debe probar cada hipótesis. Los cambios en el cliente, la
declaración del problema o la solución se prevén a medida que el equipo desarrolla una mayor empatía hacia la
base de clientes disponible.
Cau t i on
El objetivo es crear con empatía con el cliente, no planear con esta. Es fácil quedarse atascado en ciclos de
planeamiento y ajuste interminables para encontrar la declaración perfecta de empatía con el cliente. Antes de
intentar desarrollar una instrucción de este tipo, revise las dos secciones siguientes sobre cómo definir y crear
un MVP.
Una vez que se puedan demostrar las suposiciones principales, las iteraciones posteriores se centrarán en las
pruebas de crecimiento, así como en las pruebas de empatía. Una vez que se ha creado, probado y validado la
empatía, puede empezar a comprender el mercado disponible a escala. Esto puede realizarse a través de una
expansión de la fórmula de hipótesis estándar descrita anteriormente. En función de los datos disponibles,
estime el tamaño del mercado total (el número de posibles clientes).
A partir de ahí, estime el porcentaje de ese mercado total que experimenta un desafío similar y que podría estar
interesado en esta solución. Este es su mercado disponible. La siguiente hipótesis que se quedará fuera será:
¿cómo se mejorará la vida de un x % de los clientes al usar la solución propuesta para abordar este desafío
manejable? Una pequeña muestra de los clientes revela indicadores principales, lo que sugiere un impacto
porcentual en el grupo de clientes que han participado.
Definición de una solución para probar la hipótesis
Durante cada iteración de un ciclo de comentarios de creación, medida y aprendizaje, el intento de crear con
empatía se define mediante un MVP.
Un MVP es la unidad de trabajo más pequeña (invención, ingeniería, desarrollo de aplicaciones o arquitectura de
datos) necesaria para crear una solución suficiente como para aprender con el cliente. El objetivo de cada MVP
es probar algunas o todas las hipótesis anteriores y recibir comentarios directamente del cliente. La salida no es
una aplicación hermosa con todas las características necesarias para cambiar el sector. La salida deseada de cada
iteración es una oportunidad de aprendizaje, una oportunidad de probar con mayor profundidad una hipótesis.
La definición del tiempo asignado es una manera estándar de asegurarse de que un producto sigue siendo
eficiente. Por ejemplo, asegúrese de que el equipo de desarrollo piense que la solución se puede crear en una
sola iteración para permitir pruebas rápidas. Para comprender mejor el uso de la velocidad, las iteraciones y las
versiones para definir el significado de mínimo, consulte la planificación de la velocidad, las iteraciones, el
lanzamiento y las rutas de acceso de iteración.
Reducción de la complejidad y retraso de los picos técnicos
Las materias de invención que se encuentran dentro de la metodología de innovación describen la funcionalidad
que a menudo se necesita para ofrecer una solución de MVP preparada para el escalado o de innovación
madura. Use estas disciplinas como guía a largo plazo para la inclusión de características. Del mismo modo,
úselas como guía de cautela durante las primeras pruebas de valor para los clientes y empatía en la solución.
La amplitud de las características y las distintas materias de invención no se pueden crear todas en una sola
iteración. Pueden ser necesarias varias versiones para que una solución de MVP incluya la complejidad de varias
materias. En función de la inversión en desarrollo, puede haber varios equipos trabajando en paralelo en
distintas materias para probar varias hipótesis. Aunque se aconseja mantener la alineación arquitectónica entre
esos equipos, no es aconsejable intentar crear soluciones complejas integradas hasta que se puedan validar las
hipótesis de valor.
La complejidad se detecta mejor mediante la frecuencia o el volumen de los picos técnicos. Los picos técnicos
son esfuerzos para crear soluciones técnicas que no se pueden probar fácilmente con los clientes. Cuando el
valor del cliente y la empatía con el cliente no se prueban, los picos técnicos representan un riesgo para la
innovación y deben minimizarse. En el caso de los tipos de soluciones probadas Y consolidadas incluidas en un
esfuerzo de migración, los picos técnicos pueden ser comunes durante toda la adopción. Sin embargo, retrasan
las pruebas de las hipótesis en los esfuerzos de innovación y deben posponerse cuando sea posible.
Se sugiere un enfoque de simplificación constante para la definición de cualquier MVP. Este enfoque consiste en
eliminar todo lo que no contribuya a su capacidad de validar la hipótesis. Para minimizar la complejidad,
reduzca el número de integraciones y características que no son necesarias para probar la hipótesis.
Crear un MVP
En cada iteración, una solución de MVP puede tomar muchas formas diferentes. El requisito común es
simplemente que la salida permita medir y probar la hipótesis. Este requisito sencillo inicia el proceso científico
y permite al equipo crear con empatía. Para hacer realidad este enfoque centrado en el cliente, un MVP inicial
solo puede basarse en una de las materias de invención.
En algunos casos, la ruta más rápida a la innovación consiste en evitar temporalmente estas materias por
completo hasta que el equipo de adopción de la nube está seguro de que la hipótesis se ha validado
correctamente. Procedente de una empresa tecnológica como Microsoft, esta guía puede parecer contradictoria.
Sin embargo, esto solo enfatiza que las necesidades del cliente, no una decisión tecnológica específica, son la
máxima prioridad en una solución de MVP.
Normalmente, una solución de MVP consta de una sencilla solución de datos o aplicación con características
mínimas y detalles limitados. En el caso de las organizaciones que tienen experiencia de desarrollo profesional,
esta suele ser la ruta más rápida hacia el aprendizaje y la iteración. En la lista siguiente se incluyen otros
enfoques que un equipo puede adoptar para crear un MVP:
Un algoritmo predictivo que no es correcto un 99 por ciento del tiempo, pero que muestra resultados
deseados específicos.
Un dispositivo IoT que no se comunica de forma segura a nivel de producción, pero que muestra el valor de
los datos prácticamente en tiempo real dentro de un proceso.
Una aplicación creada por un desarrollador cívico para probar una hipótesis o satisfacer necesidades de
menor escala.
Un proceso manual que reproduce las ventajas que debe seguir la aplicación.
Un contorno reticular o vídeo lo suficientemente detallado como para permitir que el cliente interactúe con
él.
El desarrollo de un MVP no debe requerir grandes cantidades de inversión en desarrollo. Preferiblemente, la
inversión se debe restringir tanto como sea posible para minimizar el número de hipótesis que se ponen a
prueba al mismo tiempo. Después, en cada iteración y cada versión, la solución mejora de forma intencionada
hasta convertirse en una solución preparada para el escalado que representa varias materias de invención.
Aceleración del desarrollo de MVP
El tiempo de comercialización es fundamental para el éxito de cualquier innovación. Los lanzamientos más
rápidos conducen a un aprendizaje más rápido. Un aprendizaje más rápido conduce a productos que se pueden
escalar más rápido. En ocasiones, los ciclos de desarrollo de aplicaciones tradicionales pueden ralentizar este
proceso. Con mayor frecuencia, la innovación está restringida por los límites de la experiencia disponible. Los
presupuestos, las reducciones de plantilla y la disponibilidad del personal pueden crear límites para el número
de innovaciones nuevas que un equipo puede gestionar.
Las restricciones de personal y el deseo de crear con empatía han generado una tendencia en auge: los
desarrolladores cívicos. Estos desarrolladores reducen el riesgo y proporcionan una escala dentro de la
comunidad de desarrollo profesional de una organización. Los desarrolladores cívicos son expertos en la
materia en lo que se refiere a la experiencia del cliente, pero no están entrenados como ingenieros. Estas
personas usan herramientas de creación de prototipos o herramientas de desarrollo más ligeras que podrían los
desarrolladores profesionales podrían mirar con desdén. Estos nuevos desarrolladores alineados con la
empresa crean soluciones de MVP y prueban teorías. Cuando se coordina correctamente, este proceso puede
crear soluciones de producción que proporcionan valor, pero no pasan una hipótesis de escala suficientemente
eficaz. También se pueden usar para validar un prototipo antes de comenzar el trabajo de escalado.
Dentro de cualquier plan de innovación, los equipos de adopción de la nube deben diversificar su cartera para
incluir el trabajo de los desarrolladores cívicos. Al escalar los esfuerzos de desarrollo, se pueden formar y probar
más hipótesis con una menor inversión. Cuando se valida una hipótesis y se identifica un mercado disponible,
los desarrolladores profesionales pueden reforzar y escalar la solución mediante herramientas de desarrollo
modernas.
Último obstáculo de creación: problemas del cliente
Cuando la empatía con el cliente es fuerte, debe resultar fácil identificar un problema que existe claramente. Los
problemas del cliente deben ser obvios. Durante la creación, el equipo de adopción de la nube está generando
una solución para probar una hipótesis basada en un punto problemático para el cliente. Si la hipótesis está bien
definida, pero el punto problemático no, la solución no se basa realmente en la empatía con el cliente. En este
escenario, la creación no es el punto de inicio correcto. En su lugar, invierta primero en la generación de empatía
y en el aprendizaje de clientes reales. El mejor enfoque para generar empatía y validar los problemas es sencillo:
escuche a los clientes. Dedique tiempo a reunirse con sus clientes y a observarlos hasta que pueda identificar un
punto problemático que se produce con frecuencia. Una vez que entienda el punto problemático, estará
preparado para probar una solución hipotética para resolver ese problema.
Cuándo no se debe aplicar este enfoque

Hay muchos requisitos de cumplimiento, legales y del sector que podrían requerir un enfoque alternativo. Si las
versiones públicas de una solución de desarrollo crean riesgos para los plazos de patentes, la protección de la
propiedad intelectual, la pérdida de datos de clientes o la infracción de los requisitos de cumplimiento
establecidos, este enfoque podría no resultar adecuado. Cuando perciba riesgos como estos, consulte a su
asesor legal antes de adoptar cualquier enfoque guiado en la administración de versiones.
Referencias
Algunos de los conceptos de este artículo se basan en los temas examinados en el libro El método Lean Startup
de Eric Ries.
Pasos siguientes
Después de crear una solución de MVP, puede medir los valores de empatía y escalado. Obtenga información
sobre cómo medir el impacto en los clientes.
Hay varias maneras de medir el impacto en los clientes. Este artículo le ayudará a definir métricas para validar
las hipótesis que surgen de un trabajo para crear con la empatía de los clientes.
Métricas estratégicas
La metodología de estrategia analiza las motivaciones y los resultados empresariales. Estos procedimientos
proporcionan un conjunto de métricas con las que probar el impacto para el cliente. Si la innovación es
satisfactoria, podrá ver normalmente resultados que están en línea con sus objetivos estratégicos.
Antes de establecer métricas de aprendizaje, defina un pequeño número de métricas estratégicas a las que
quiera que afecte esta innovación. Por lo general, las métricas estratégicas están en línea con una o varias de las
áreas de resultados siguientes:
Agilidad empresarial
Involucración del cliente
Cobertura del cliente
Impacto financiero
Rendimiento de la solución, en el caso de la innovación operativa.
Documente las métricas acordadas y realice un seguimiento de su impacto con frecuencia, pero no espere que
los resultados de estas métricas aparezcan durante varias iteraciones. Para obtener más información sobre
cómo establecer y alinear las expectativas entre las partes implicadas, consulte Compromiso con la iteración.
Aparte de la motivación y las métricas de los resultados empresariales, el resto de este artículo se centra en las
métricas de aprendizaje diseñadas como guía para la detección transparente y las iteraciones centradas en el
cliente. Para obtener más información sobre estos aspectos, consulte Compromiso con la transparencia.
Métricas de aprendizaje
Cuando se comparte con los clientes la primera versión de un producto viable mínimo (MVP), preferiblemente
al final de la primera iteración de desarrollo, no habrá ningún impacto en las métricas estratégicas. Después de
varias iteraciones, es posible que el equipo todavía esté lidiando para cambiar los comportamientos lo suficiente
para que afecten de manera significativa a las métricas estratégicas. Durante los procesos de aprendizaje, como
los ciclos de crear-medir-aprender, se recomienda que el equipo adopte métricas de aprendizaje. Estas miden las
oportunidades de seguimiento y aprendizaje.
Métricas de flujo y aprendizaje del cliente
Si una solución de MVP valida una hipótesis centrada en el cliente, la solución impulsará algún cambio en los
comportamientos de los clientes. Estos cambios de comportamiento en los cohortes del cliente deben mejorar
los resultados empresariales. Tenga en cuenta que el cambio en el comportamiento del cliente suele ser un
proceso de varios pasos. Dado que cada paso proporciona una oportunidad para medir el impacto, el equipo de
adopción puede aprender durante todo el proceso y crear una solución mejor.
El aprendizaje de los cambios en el comportamiento del cliente comienza con la asignación del flujo que espera
ver de una solución de MVP.
En la mayoría de los casos, el flujo de cliente tendrá un punto inicial fácil de definir y no más de dos puntos
finales. Entre los puntos inicial y finales se encuentran varias métricas de aprendizaje que se usarán como
medidas en el bucle de comentarios:
1. Punto inicial (desencadenador inicial): el punto inicial es el escenario que desencadena la necesidad de
esta solución. Cuando la solución se crea con la empatía de los clientes, ese desencadenador inicial debe
animar al cliente a probar la solución MVP.
2. Necesidad del cliente satisfecha: La hipótesis se valida cuando una necesidad del cliente se satisface
mediante la solución.
3. Pasos de la solución: este término hace referencia a los pasos necesarios para mover al cliente desde el
desencadenador inicial hasta un resultado correcto. Cada paso genera una métrica de aprendizaje basada en
la decisión del cliente para pasar al siguiente paso.
4. Adopción individual conseguida: la próxima vez que se encuentre el desencadenador, si el cliente vuelve
a la solución para satisfacer su necesidad, se consigue la adopción individual.
5. Indicador de resultados empresariales: cuando un cliente se comporta de una manera que contribuye al
resultado empresarial definido, se observa un indicador de resultado empresarial.
6. Innovación verdadera: cuando los indicadores de resultados empresariales y la adopción individual se
producen en la escala deseada, se ha conseguido una verdadera innovación.
Cada paso del flujo de cliente genera métricas de aprendizaje. Después de cada iteración (o versión), se prueba
una nueva versión de la hipótesis. Al mismo tiempo, se prueban los retoques de la solución para reflejar los
ajustes de la hipótesis. Cuando los clientes siguen el trazado prescrito en cualquier paso determinado, se
registra una métrica positiva. Cuando los clientes se desvían del trazado prescrito, se registra una métrica
negativa.
Estos contadores de alineación y desviación crean métricas de aprendizaje. Es necesario registrarlas y realizar su
seguimiento a medida que el equipo de adopción de la nube progresa hacia la consecución de los resultados
empresariales y la verdadera innovación. En el apartado sobre el aprendizaje con los clientes, analizaremos las
maneras de aplicar estas métricas para aprender y crear soluciones mejores.
Agrupación y observación de los asociados cliente
La primera medida para definir las métricas de aprendizaje es la definición del asociado cliente. Cualquier cliente
que participe en ciclos de innovación se califica como asociado cliente. Para medir el comportamiento con
precisión, debe utilizar un modelo de cohorte para definir los asociados cliente. En este modelo, los clientes se
agrupan para mejorar la comprensión de sus respuestas a los cambios en el MVP. Estos grupos suelen ser
similares a los siguientes:
Grupo de experimento o enfoque: agrupación de clientes basada en su participación en un experimento
específico diseñada probar los cambios con el tiempo.
Segmento: Agrupación de los clientes por el tamaño de la empresa.
Ver tical: agrupación de clientes por el sector vertical que representan.
Datos demográficos individuales: agrupación basada en datos demográficos personales, como la edad o
la ubicación física.
Estos tipos de agrupaciones le ayudan a validar las métricas de aprendizaje en varias secciones transversales de
los clientes que deciden asociarse usted durante los trabajos de innovación. Todas las métricas posteriores
deben derivarse de la agrupación de clientes definible.
Pasos siguientes
A medida que se acumulan métricas de aprendizaje, el equipo puede empezar a aprender con los clientes.
Aprender con los clientes
Algunos de los conceptos de este artículo se basan en temas descritos en el libro El método Lean Startup, escrito
por Eric Ries.
Aprendizaje con los clientes
Nuestros clientes actuales representan nuestro mejor recurso de aprendizaje. Al asociarse con nosotros, nos
ayudan a crear con la empatía de los clientes y a encontrar la mejor solución para sus necesidades. También
ayudan a crear una solución de producto mínimo viable (MVP) mediante la generación de métricas con las que
medir el impacto para los clientes. En este artículo, describiremos cómo aprender con y de nuestros asociados
clientes.
Aprendizaje continuo
Al final de cada iteración, tenemos la oportunidad de aprender de los ciclos de creación y medida. Este proceso
de aprendizaje continuo es bastante sencillo. La imagen siguiente ofrece información general del flujo de
proceso.
En su forma más básica, el aprendizaje continuo es un método para responder a las métricas de aprendizaje y
evaluar su impacto en las necesidades de los clientes. Este proceso consta de tres decisiones principales que
deben realizarse al final de cada iteración:
¿Se ha demostrado la hipótesis? Cuando la respuesta sea afirmativa, celébrelo un momento y luego
continúe. Siempre hay más cosas que aprender, más supuestos para probar y más formas de ayudar al
cliente en la siguiente iteración. Cuando una hipótesis es verdadera, suele ser un buen momento para que los
equipos tomen una decisión sobre una nueva característica que mejorará la utilidad de la solución para el
cliente.
¿Puede aproximarse más a una hipótesis validada mediante la iteración en la solución actual?
Esta respuesta suele ser sí. Las métricas de aprendizaje suelen sugerir puntos del proceso que conducen a la
desviación de los clientes. Use estos puntos de datos para buscar la raíz de una hipótesis con errores. En
ocasiones, las métricas también pueden sugerir una solución.
¿Es necesario restablecer la hipótesis? Lo peor que se puede aprender en cualquier iteración es que la
hipótesis o la necesidad subyacente eran erróneas. Cuando esto sucede, una iteración por sí sola no es
necesariamente la respuesta correcta. Si es necesario restablecer, se debe volver a escribir la hipótesis y
revisar la solución a la luz de la nueva hipótesis. Cuanto antes se produzca este tipo de aprendizaje, más fácil
será dinamizar el proceso. La hipótesis temprana debe centrarse en probar los aspectos más arriesgados de
la solución para evitar dinamizaciones más adelante en el desarrollo.
¿No está seguro? La segunda respuesta más común después de "iterar" es "no estamos seguros". Adopte
esta respuesta. Representa una oportunidad para implicar al cliente y mirar más allá de los datos.
Las respuestas a estas preguntas formarán la iteración que se va a seguir. Las compañías que tienen la
capacidad de aplicar el aprendizaje continuo y la valentía de tomar las decisiones adecuadas para sus clientes
tienen más probabilidad de convertirse en líderes de su mercado.
Para bien o para mal, la práctica del aprendizaje continuo es un arte que requiere una gran cantidad de pruebas
y errores. También requiere la toma de algunas decisiones basadas en la ciencia y en los datos. Quizás la parte
más difícil de la adopción del aprendizaje continuo está relacionada con los requisitos culturales. Para adoptar
de forma eficaz el aprendizaje continuo, la cultura empresarial debe estar abierta a un enfoque centrado en el
cliente y a que primero se produzcan errores. En la sección siguiente se proporcionan más detalles acerca de
este enfoque.
Mentalidad de crecimiento
Pocos podrán negar la transformación radical que se ha producido en la cultura de Microsoft en los últimos
años. Esta transformación multifaceta dirigida por Satya Nadella se considera una sorprendente historia de éxito
empresarial. En el corazón de esta historia hay una sencilla creencia denominada mentalidad de crecimiento.
Podríamos dedicar una sección completa de este marco a la adopción de una mentalidad de crecimiento. Sin
embargo, para simplificar esta guía, nos centraremos en unos cuantos puntos clave que fundamentarán el
proceso de aprendizaje con los clientes:
El cliente primero: si una hipótesis está diseñada para mejorar la experiencia de los clientes reales, debe
reunirse con los clientes reales en el entorno real. No confíe solo en métricas. Compare y analice las métricas
basándose en una observación de primera mano de las experiencias de los clientes.
Aprendizaje continuo: centrarse en el cliente y tener empatía con el cliente derivan de una mentalidad de
aprendizaje. La metodología de innovación pretende ser un método centrado en aprenderlo todo, no en
saberlo todo.
Mentalidad de principiante: demuestre empatía y enfoque todas las conversaciones con una mentalidad
de principiante. Tanto si no está familiarizado con su campo como si tiene una experiencia de 30 años,
suponga que no sabe nada y aprenderá mucho.
Escuche más: los clientes desean colaborar con usted. Lamentablemente, la necesidad ególatra de hacerlo
bien bloquea esa asociación. Para aprender más allá de las métricas, hable menos y escuche más.
Anime a otros: no solo tiene que escuchar; use lo que dice para animar a otros. En todas las reuniones,
busque formas de extraer distintas perspectivas de aquellas personas que no pueden compartir
rápidamente.
Compar ta el código: cuando creemos que nuestra obligación es tener la propiedad de una base de código,
perdemos de vista el verdadero poder de la innovación. Céntrese en poseer y promover resultados para sus
clientes. Comparta su código (públicamente con el mundo o de forma privada con su empresa) para incluir
distintas perspectivas en la solución y el código base.
Desafío qué funciona: el éxito no significa necesariamente que se muestre verdadera empatía con el
cliente. Evite tener una mentalidad cerrada y una inclinación por repetir aquello que ha funcionado antes.
Implique a sus clientes y busque el aprendizaje en las métricas positivas y negativas.
Sea inclusivo: trabaje duro para incluir distintas perspectivas en la combinación. Hay muchas variables que
pueden dividir a los seres humanos en distintos grupos. Normativas culturales, comportamientos anteriores,
sexo, religión, orientación sexual e incluso capacidades físicas. La verdadera innovación se produce cuando
nos desafiamos a ver más allá de las diferencias y trabajamos a conciencia para incluir a todos los clientes,
asociados y compañeros de trabajo.
Pasos siguientes
El paso siguiente para entender esta metodología es consultar Desafíos y factores de bloqueo comunes para la
innovación a fin de prepararle para los cambios que se avecinan.
Explicación de los desafíos y factores de bloqueo comunes
Algunos de los conceptos de este artículo se basan en temas descritos en el libro El método Lean Startup, escrito
por Eric Ries.
Factores de bloqueo comunes para la adopción de
tecnología y desafíos de la innovación
Tal y como se describe en Innovación en la economía digital, la innovación requiere un equilibrio entre la
invención y adopción. En este artículo se amplía la información sobre los desafíos y los factores de bloqueo
comunes de la adopción en la nube, y tiene por objetivo ayudarle a comprender cómo este enfoque puede
aportar valor durante los ciclos de innovación.
Fórmula para la innovación: innovación = invención + adopción
Saber cómo superar los desafíos de innovación lleva algún tiempo, ya que debe aprender los métodos
correctos. En este artículo se profundiza en los desafíos de adopción de tecnología en el área de trabajo.
Desafíos de adopción de tecnología en la nube

Aunque los avances tecnológicos de la nube han reducido parte de la fricción relacionada con la adopción, la
adopción de la tecnología está más centrada en las personas que en la propia tecnología. Lamentablemente, la
nube no puede corregir a las personas.
En la lista siguiente se describen algunos de los desafíos más comunes de la adopción relacionados con la
innovación. A medida que avance por la metodología de innovación, se identificarán y abordarán todos los
desafíos de las secciones siguientes. Antes de aplicar esta metodología, evalúe sus ciclos actuales de innovación
para determinar cuáles son los principales desafíos o factores de bloqueo. A continuación, use la metodología
para solucionar o eliminar los factores de bloqueo.
Tipos de desafíos externos
Plazo de comercialización: en una economía digital, el plazo de comercialización es uno de factores
cruciales que indican el dominio del mercado. Sorprendentemente, el impacto del plazo de comercialización
tiene poco que ver con la posición o la cuota inicial del mercado. Ambos factores son inconstantes y
temporales. La ventaja del plazo de comercialización se encuentra en el hecho de que, cuanto más tiempo
lleva la solución en el mercado, más tiempo tiene para aprender, iterar y mejorar. Céntrese especialmente en
definir y crear rápidamente un producto mínimo viable para reducir los plazos de comercialización y acelerar
las oportunidades de aprendizaje.
Desafíos de la competencia: los operadores dominantes reducen las oportunidades de participación y
aprendizaje de los clientes. Los competidores también crean presión externa para realizar sus entregas más
rápidamente. Compile con rapidez, pero no escatime inversiones en comprender las medidas adecuadas. Los
nichos bien definidos producen medidas más útiles de los comentarios, además de mejorar su capacidad
para asociarse y aprender, lo que dará lugar a mejores soluciones generales.
Comprenda a su cliente: la empatía con el cliente comienza por el conocimiento de la base de clientes y
los clientes. Uno de los mayores desafíos para los innovadores es la capacidad de categorizar rápidamente
las medidas y el aprendizaje dentro del ciclo de creación-medición-aprendizaje. Es importante mirar al
cliente desde la perspectiva de la segmentación del mercado, los canales y los tipos de relaciones. En el ciclo
de creación-medida-aprendizaje, estos puntos de datos ayudan a crear empatía y a dar forma a las lecciones
aprendidas.
Tipos de desafíos internos
Elección de candidatos de innovación: a la hora de invertir en innovación, las empresas saludables
generan un suministro interminable de posibles invenciones. Muchas de estas crean casos empresariales
atractivos que sugieren un alto rendimiento y generan hojas de cálculo de justificación comercial sugerentes.
Tal y como se describe en el artículo sobre creación, se debe dar prioridad a la creación con empatía con el
cliente frente a la invención que se basa únicamente en proyecciones de ganancias. Si la empatía con el
cliente no es visible en la propuesta, es muy improbable que se adopte a largo plazo.
Equilibrio de la car tera: La mayoría de las implementaciones tecnológicas no se centran en cambiar el
mercado ni en mejorar la vida de los clientes. En un departamento de TI medio, más del 80 % de las cargas
de trabajo se mantienen para automatizar procesos básicos. La facilidad para innovar hace que sea tentador
innovar y rediseñar esas soluciones. La mayoría de las veces, estas cargas de trabajo pueden experimentar
retornos similares o mejores mediante la migración o modernización de la solución, sin necesidad de realizar
cambios en la lógica de negocios principal ni en los procesos de datos. Equilibre su cartera para favorecer las
estrategias de innovación que se puedan crear con una empatía clara con el cliente (interno o externo). Para
todas las demás cargas de trabajo, siga una ruta de migración para obtener retornos financieros.
Centrar la atención y proteger las prioridades: una vez adquirido el compromiso con la innovación, es
importante centrar la atención del equipo. Durante la primera iteración de una fase de creación, es
relativamente fácil mantener al equipo entusiasmado con las posibilidades de cambiar el futuro de los
clientes. Sin embargo, esa primera versión del producto mínimo viable es solo el principio. La verdadera
innovación se produce con cada ciclo de creación-medida-aprendizaje, con el aprendizaje de los bucles de
comentarios para producir una solución mejor. Como líder en cualquier proceso de innovación, debe
concentrarse en mantener al equipo centrado y las prioridades de innovación durante las siguientes
iteraciones de creación menos glamurosas.
Desafíos de la invención
Antes de la adopción generalizada de la nube, los ciclos de invención que dependían de la tecnología de la
información eran lentos y laboriosos. Los ciclos de adquisición y aprovisionamiento solían retrasar los primeros
pasos esenciales hacia nuevas soluciones. El costo de las soluciones de DevOps y los bucles de comentarios
retrasaban la capacidad de los equipos para colaborar en la concepción e invención durante las primeras fases.
Los costos relacionados con los entornos de desarrollo y las plataformas de datos impedían que solo
desarrolladores profesionales muy cualificados pudieran participar en la creación de nuevas soluciones.
La nube ha superado muchos de estos desafíos de la invención al ofrecer aprovisionamiento automatizado de
autoservicio, herramientas de desarrollo e implementación ligeras y oportunidades para que los
desarrolladores profesionales y los desarrolladores cívicos colaboren con rapidez en la creación de soluciones.
Usar la nube para la innovación reduce drásticamente los desafíos y los factores de bloqueo de los clientes en el
lado de la invención de la ecuación de la innovación.
Desafíos de la invención y la innovación en una economía digital
Los desafíos de la invención de hoy en día son diferentes a los desafíos del pasado. El potencial interminable de
las tecnologías en la nube también genera más opciones de implementación y consideraciones más detalladas
sobre cómo se podrían usar esas implementaciones.
La metodología de innovación utiliza las siguientes disciplinas de innovación para ayudar a alinear las
decisiones de implementación con los objetivos de invención y adopción:
Plataformas de datos: Hay disponibles nuevos orígenes y variaciones de los datos. Anteriormente, muchos
de estos datos no se podrían integrar en aplicaciones heredadas o locales para crear una solución rentable.
Comprender el cambio que espera generar en los clientes determinará las decisiones acerca de la plataforma
de datos. Dichas decisiones serán una extensión de los enfoques seleccionados para ingerir, integrar,
categorizar y compartir los datos. Microsoft se refiere a este proceso de toma de decisiones como
democratización de los datos.
Interacciones de los dispositivos: IoT, los dispositivos móviles y la realidad aumentada difuminan las
líneas entre lo digital y lo físico, lo que acelera la economía digital. Comprender las interacciones del mundo
real en torno al comportamiento de un cliente determinará las decisiones relacionadas con la integración de
los dispositivos.
Aplicaciones: las aplicaciones ya no son de dominio exclusivo de los desarrolladores profesionales.
Tampoco requieren enfoques tradicionales basados en servidor. Capacitar a los desarrolladores
profesionales, habilitar a los especialistas de la empresa para que se conviertan en desarrolladores cívicos y
expandir las opciones de proceso de las API, los microservicios y las soluciones PaaS amplía las opciones de
interfaz de las aplicaciones. Comprender la experiencia digital necesaria para dar forma al comportamiento
de los clientes mejorará la toma de decisiones acerca de las opciones de aplicación.
Código fuente e implementación: la colaboración entre desarrolladores de todos los sectores mejora la
calidad y el tiempo de comercialización. La integración de los comentarios y una respuesta rápida permite a
los líderes del mercado definir el aprendizaje. Los compromisos en los procesos de creación, medida y
aprendizaje ayudan a acelerar las decisiones de adopción de herramientas.
Soluciones predictivas: en una economía digital, rara vez es suficiente para satisfacer las necesidades
actuales de los clientes. Los clientes esperan que las empresas prevean los pasos siguientes y predigan sus
necesidades futuras. El aprendizaje continuo suele evolucionar en herramientas de predicción. La
complejidad de las necesidades de los clientes y la disponibilidad de los datos ayudarán a definir las mejores
herramientas y los mejores enfoques de predicción e influencia.
En una economía digital, el mayor reto al que se enfrentan los arquitectos es la capacidad de comprender
claramente las necesidades de invención y adopción del cliente, así como de determinar la mejor cadena de
herramientas en la nube para satisfacer dichas necesidades.
Pasos siguientes
Con los conocimientos adquiridos sobre el modelo de creación-medida-aprendizaje y la mentalidad de
crecimiento, ya está listo para desarrollar invenciones digitales dentro de la metodología de innovación.
¿Qué son las invenciones digitales? Tal y como se describe en Innovación en la economía digital, la innovación
requiere un equilibrio entre la invención y adopción. Las invenciones digitales son productos de innovación
tecnológica que resuelven las necesidades de los clientes y proporcionan soluciones innovadoras. Los
comentarios de los clientes y la colaboración son necesarios para impulsar la adopción, preferiblemente
mediante el bucle de comentarios crear-medir-aprender. Para más información, consulte Crear asociaciones con
los clientes a través del bucle de comentarios crear-medir-aprender.
Los tipos de innovación y las materias que se indican en la siguiente sección presentan una serie de enfoques
para desarrollar invenciones digitales teniendo en mente la adopción y la empatía con el cliente. Cada materia
se describe brevemente junto con vínculos a cada proceso.
Resumen de cada materia de invención digital

Hay diferentes tipos de innovación para el desarrollo de productos. No todas las materias son necesarias para
impulsar la innovación en cada caso específico. Siguiendo las instrucciones relativas a la creación con empatía
con el cliente, probará una hipótesis en cada iteración. Definir el resultado de cada iteración como un producto
mínimo viable (MVP) debería permitirle crear innovaciones con el menor número de materias.
Democratización de los datos : al poner los datos en manos de los clientes, asociados y empleados,
fomenta una observación innovadora. Los datos se ingieren, centralizan, controlan y comparten.
Par ticipación a través de aplicaciones : Los usuarios se conectan con el conocimiento mediante
aplicaciones y experiencias. Dé a los desarrolladores profesionales y cívicos las herramientas necesarias para
crear aplicaciones con rapidez.
Capacitación para la adopción : fomente la innovación reduciendo la fricción a la adopción y la
asociación. Diseñe para conseguir visibilidad, colaboración, velocidad y bucles de comentarios.
Interacción con dispositivos : las líneas físicas y digitales se han desdibujado en varios canales. Ofrezca
experiencias a través de dispositivos, IoT y realidad mixta.
Predicción e influencia : mire al futuro para liderar la innovación. Examine los datos actuales más recientes
para fundamentar la experiencias y las interacciones mediante herramientas de predicción.
Pasos siguientes
La primera materia de la innovación que se debe considerar y evaluar es la democratización de los datos.
Democratización de datos con la invención digital
El carbón, el aceite y el potencial humano fueron los tres recursos más importantes durante la revolución
industrial. Estos recursos creaban compañías, movían los mercados y, en última instancia, cambiaban países. En
la economía digital, hay tres recursos igualmente importantes: datos, dispositivos y potencial humano. Cada uno
de estos recursos presenta un fantástico potencial de innovación. En cualquier trabajo de innovación de la era
moderna, los datos son el nuevo aceite.
En todas las empresas de hoy en día, hay depósitos de datos que podrían emplearse para buscar y satisfacer las
necesidades de los clientes de manera más eficaz. Lamentablemente, el proceso de minería de datos para
impulsar la innovación es muy costoso y lento. Muchas de las soluciones más valiosas para las necesidades de
los clientes se desestiman porque las personas adecuadas no pueden acceder a los datos que necesitan.
La democratización de los datos es el proceso de poner estos datos en las manos adecuadas para impulsar la
innovación. Este proceso puede tener varias formas, pero generalmente incluye soluciones para datos sin
procesar ingeridos o integrados, centralización de datos, uso compartido de datos y protección de datos.
Cuando estos métodos se ejecutan correctamente, los expertos de la empresa pueden usar los datos para
probar los supuestos. En muchos casos, los equipos de adopción de la nube pueden crear con empatía con el
cliente usando solo datos, lo que permite satisfacer rápidamente las necesidades existentes de los clientes.
Proceso de democratización de los datos

En las siguientes fases se guiarán las decisiones y los enfoques necesarios para adoptar una solución que
democratiza los datos. No todas las fases serán obligatorias para crear una solución específica. Sin embargo,
debe evaluar cada fase cuando cree una solución para una hipótesis de cliente. Cada una de ellas proporciona
un enfoque único para la creación de soluciones innovadoras.
Compartir datos
Al crear con empatía con el cliente, todos los procesos priorizan la necesidad del cliente frente a una solución
técnica. Dado que la democratización de los datos no es una excepción, comenzaremos compartiendo los datos.
Para democratizar los datos, debe incluir una solución que comparta los datos con un consumidor de datos. El
consumidor de datos puede ser un cliente directo o un servidor proxy que toma decisiones para los clientes. Los
consumidores de datos aprobados tienen la capacidad de realizar análisis, preguntas e informes con los datos
centralizados, sin soporte técnico del personal de TI.
Muchas innovaciones de éxito se han iniciado como soluciones de producto mínimo viable (MVP) que
proporcionan procesos manuales y controlados por datos en nombre del cliente. En este modelo, un empleado
es el consumidor de los datos. Ese empleado utiliza datos para ayudar al cliente. Cada vez que el cliente se pone
en contacto con el soporte manual, se puede probar y validar una hipótesis. Este enfoque suele ser un medio
rentable de probar una hipótesis centrada en el cliente antes de realizar grandes inversiones en soluciones
integradas.
Las principales herramientas para compartir datos directamente con los consumidores de datos incluyen
informes de autoservicio o datos insertados en otras experiencias mediante herramientas como Power BI.
NOTE
Antes de compartir datos, asegúrese de haber leído las secciones siguientes. El uso compartido de datos puede requerir
gobernanza para proteger los datos compartidos. Además, los datos pueden estar diseminados en varias nubes y podrían
requerir centralización. Gran parte de los datos pueden residir incluso dentro de las aplicaciones, lo que requerirá recopilar
los datos antes de compartirlos.
Gobernanza de los datos

El uso compartido de datos puede generar rápidamente un producto viable mínimo que puede usar en las
conversaciones con los clientes. No obstante, para convertir los datos compartidos en conocimientos
procesables, suele hacer falta algo más. Una vez que se ha validado una hipótesis mediante el uso compartido
de datos, la siguiente fase de desarrollo suele ser la gobernanza de los datos.
La gobernanza de los datos es un tema amplio que podría requerir su propio marco dedicado. Este grado de
granularidad queda fuera del ámbito de Cloud Adoption Framework. Sin embargo, hay algunos aspectos de la
gobernanza de los datos que se deben tener en cuenta en el momento en que se valida la hipótesis del cliente.
Por ejemplo:
¿Los datos compar tidos son confidenciales? Los datos se deben clasificar antes de hacer cualquier uso
compartido público para proteger los intereses de los clientes y de la empresa.
Si los datos son confidenciales, ¿se han protegido? La protección de los datos confidenciales debe ser
un requisito en todo dato democratizado. La carga de trabajo de ejemplo centrada en proteger las soluciones
de datos proporciona algunas referencias para proteger los datos.
¿Los datos están catalogados? Capturar detalles sobre los datos que se comparten ayuda a administrar
los datos a largo plazo. Las herramientas para documentar datos, como Azure Data Catalog, pueden hacer
que este proceso sea mucho más fácil en la nube. El asesoramiento sobre la anotación de los datos y la
documentación de los orígenes de datos puede ayudar a acelerar el proceso.
Cuando la democratización de los datos es importante para una hipótesis centrada en el cliente, asegúrese de
que la gobernanza de los datos compartidos esté en alguna parte del plan de lanzamiento. Esto ayudará a
proteger a los clientes, los consumidores de datos y la empresa.
Cuando se interrumpe el flujo de datos en un entorno de TI, las oportunidades de innovación pueden ser muy
limitadas, costosas y lentas. La nube proporciona nuevas oportunidades para centralizar los datos en silos de
datos. Cuando es necesario centralizar varios orígenes de datos para crear con empatía con el cliente, la nube
puede acelerar la prueba de las hipótesis.
Cau t i on
La centralización de los datos representa un punto de riesgo en cualquier proceso de innovación. Cuando la
centralización de datos supone una demanda técnica, y no una fuente de valor del cliente, se recomienda
retrasar la centralización hasta que se hayan validado las hipótesis del cliente.
Si es necesario centralizar los datos, el primer paso es definir el almacén de datos adecuado para los datos
centralizados. El procedimiento recomendado es establecer un almacenamiento de datos en la nube. Esta opción
escalable proporciona una ubicación central para todos los datos. Este tipo de solución está disponible en las
opciones de procesamiento analítico en línea (OLAP) o de macrodatos.
Las arquitecturas de referencia de las soluciones OLAP y de macrodatos pueden ayudarle a elegir la solución
más adecuada en Azure. Si se requiere una solución híbrida, la arquitectura de referencia para la extensión de
los datos locales también puede ayudar a acelerar el desarrollo de soluciones.
IMPORTANT
En función de las necesidades del cliente y la solución correspondiente, quizás un enfoque más sencillo sea suficiente. El
arquitecto de la nube debe desafiar al equipo para que considere soluciones de menor costo que podrían permitir una
validación más rápida de la hipótesis del cliente, especialmente durante las primeras fases del desarrollo. En la siguiente
sección sobre la recopilación de datos se tratan algunos escenarios que podrían sugerir una solución diferente para su
situación.
Recopilación de datos
Cuando los datos deben centralizarse para satisfacer las necesidades de un cliente, es muy probable que
también sea necesario recopilar los datos de varios orígenes y pasarlos al almacén de datos centralizado. Existen
principalmente dos maneras de recopilar datos: integración e ingesta.
Integración: los datos existentes que ya residen en un almacén de datos se pueden integrar en el almacén de
datos centralizado mediante técnicas tradicionales de movimiento de datos. Esto es especialmente frecuente en
escenarios que implican el almacenamiento de datos en varias nubes. Estas técnicas implican la extracción de los
datos del almacén de datos existente y su carga posterior en el almacén de datos central. En algún momento de
este proceso, los datos suelen transformarse para facilitar su uso y para que sean más pertinentes en el almacén
central.
Las herramientas basadas en la nube han convertido estas técnicas en herramientas de pago por uso, lo que
reduce las barreras iniciales para la centralización y recopilación de los datos. Herramientas como Azure
Database Migration Service y Azure Data Factory son dos ejemplos. La arquitectura de referencia para una
factoría de datos con un almacén de datos OLAP es un ejemplo de este tipo de solución.
Ingesta: algunos datos no residen en un almacén de datos existente. Cuando estos datos transitorios son una
fuente principal de innovación, se deben tener en cuenta enfoques alternativos. Los datos transitorios se pueden
encontrar en diversos orígenes, tales como aplicaciones, API, flujos de datos, dispositivos IoT, cadenas de
bloques, caché de aplicaciones, contenido multimedia o incluso archivos planos.
Puede integrar estas diversas formas de datos en un almacén de datos central en una solución OLAP o de
macrodatos. Sin embargo, en las primeras iteraciones del ciclo de creación-medición-aprendizaje, una solución
de procesamiento transaccional en línea (OLTP) puede ser más que suficiente para validar la hipótesis de un
cliente. Las soluciones OLTP no son la mejor opción en todos los escenarios de informes. Sin embargo, al crear
con empatía con el cliente, es más importante centrarse en las necesidades del cliente que en las decisiones
sobre herramientas técnicas. Una vez validada la hipótesis del cliente a escala, puede ser necesaria una
plataforma más adecuada. La arquitectura de referencia de los almacenes de datos OLTP puede ayudar a
determinar qué almacén de datos es el más adecuado para la solución.
Vir tualización: La integración y la ingesta de datos a veces pueden ralentizar la innovación. Si ya hay
disponible una solución de virtualización de datos, podría representar un enfoque más razonable. La ingesta y la
integración pueden duplicar los requisitos de almacenamiento y desarrollo, agregar latencia de datos, aumentar
el área expuesta a ataques, desencadenar problemas de calidad y aumentar el trabajo de gobernanza. La
virtualización de los datos es una alternativa más actual que deja los datos originales en una ubicación única y
crea consultas de paso a través o almacenadas en caché de los datos de origen.
SQL Server 2017 y Azure SQL Data Warehouse admiten PolyBase, que es el enfoque de virtualización de datos
que se usa con más frecuencia en Azure.
Pasos siguientes
Cuando ya se disponga de una estrategia de democratización de los datos, lo siguientes es evaluar los enfoques
para involucrar a los clientes mediante las aplicaciones.
Involucrar a los clientes mediante las aplicaciones
Desarrollo de aplicaciones innovadoras
Como se indica en Democratización de datos con la invención digital los datos impulsan la mayoría de las
innovaciones en la economía digital. Según esta analogía, las aplicaciones serían las estaciones de servicio y la
infraestructura necesaria para que dicho combustible llegue a las manos adecuadas.
En algunos casos, los datos por sí mismos son suficientes para producir un cambio y satisfacer las necesidades
de los clientes. Sin embargo, lo más frecuente es que la solución para las necesidades de los clientes requiera
aplicaciones para dar forma a los datos y crear una experiencia. Las aplicaciones innovadoras involucran al
usuario y permiten interactuar con él, proporcionando información e instrucciones. En este artículo se resumen
varios principios que pueden ayudarle a encontrar la solución de desarrollo de aplicaciones correcta, en función
de las hipótesis que se vayan a validar.
Código compartido
Los equipos que son rápidos a la hora de responder a los comentarios de los clientes, los cambios en el
mercado y las oportunidades suelen innovar mejor. El primer principio de las aplicaciones innovadoras es un
elemento de la mentalidad de crecimiento, "Compartir el código". El uso compartido de código invita a disponer
de diversas perspectivas y contribuciones, e impulsa la innovación. Por ello, todo el desarrollo de aplicaciones
debe comenzar por un repositorio de código compartido.
Una herramienta ampliamente adoptada para administrar los repositorios de código es GitHub, que permite
crear rápidamente un repositorio de código compartido. Una alternativa es Microsoft Azure Repos, que es un
servicio de Azure DevOps que proporciona repositorios privados ilimitados hospedados en la nube para el
proyecto. Para el control de versiones cuando usa Azure Repos, puede elegir Git, que es un tipo distribuido, o
Control de versiones de Team Foundation (TFVC), que está centralizado. Para más información sobre Azure
Repos, Git y Control de versiones de Team Foundation (TFVC), consulte la documentación de Azure Repos.
Desarrolladores cívicos
Los desarrolladores profesionales son importantes para la innovación. Cuando una hipótesis resulta precisa a
gran escala, puede estabilizar la solución y prepararla para el escalado. Desafortunadamente, los
desarrolladores profesionales pueden tener poca oferta y el desarrollo profesional puede aumentar los costos y
ralentizar la innovación.
Los desarrolladores civiles son usuarios que crean nuevas aplicaciones empresariales mediante entornos de
desarrollo y entornos de tiempo de ejecución autorizados por el equipo de TI corporativo. El uso de
desarrolladores civiles puede ayudar a escalar los esfuerzos de desarrollo y acelerar las primeras pruebas de
hipótesis. Esta estrategia resulta viable y efectiva cuando se pueden validar las primeras hipótesis con
herramientas como Power Apps para interfaces de aplicaciones, AI Builder para procesos y predicciones, Power
Automate para flujos de trabajo y Power BI para el consumo de datos.
NOTE
Cuando confía en desarrolladores civiles para probar hipótesis, se recomienda contar con desarrolladores profesionales
que apoyen, revisen y guíen el trabajo. Los profesionales pueden ayudar a desarrollar un diseño sólido que acelere los
resultados de la innovación. Al implicar a desarrolladores profesionales en el momento adecuado, podrá realizar
transiciones más sencillas en el futuro.
Experiencias inteligentes
Las experiencias inteligentes combinan la velocidad y la escala de las aplicaciones web modernas, con la
inteligencia de los servicios y bots cognitivos. Por sí solas, cada una de estas tecnologías puede bastar para
satisfacer las necesidades de los clientes. Cuando se combinan adecuadamente, amplían el espectro de
necesidades que se pueden satisfacer a través de una experiencia digital, a la vez que ayudan a contener los
costos de desarrollo de la aplicación.
Aplicaciones web modernas
Las aplicaciones web modernas pueden ser la manera más rápida de satisfacer las necesidades de los clientes
internos o externos. Las experiencias que proporcionan pueden involucrar a los clientes rápidamente y permitir
una rápida evolución de la solución.
Incorporación de inteligencia
A los desarrolladores profesionales y civiles les resulta más fácil agregar características de aprendizaje
automático e inteligencia artificial a las aplicaciones que ayudan a satisfacer las necesidades del cliente y que
crean una experiencia interactiva. Estos son algunos ejemplos de estas características:
Conversión de voz en texto
Texto a voz
Visión del equipo
Búsqueda visual
Inteligencia artificial predictiva
Los innovadores deben estar atentos para aprovechar estas características y crear una experiencia interactiva y
moderna.
Bots
Un bot es una aplicación de inteligencia artificial conversacional que proporciona a los usuarios una experiencia
que se parece más a trabajar con una persona y menos a tratar con una aplicación informática convencional. Los
usuarios conversan con los bot a través de texto, tarjetas interactivas y la voz. Una interacción con un bot puede
ir desde una pregunta y una respuesta rápidas (para hacer una reserva para cenar, por ejemplo) a una
conversación sofisticada que proporcione acceso a servicios de forma inteligente.
Los bots puede hacer lo mismo que otros tipos de software: leer y escribir archivos, usar bases de datos y API y
realizar las tareas de cálculo habituales. Lo que hace que los bots sean únicos es su uso de mecanismos que
generalmente se reservan para la comunicación entre humanos. Los bots se parecen mucho a las aplicaciones
web modernas: residen en Internet y usan las API para enviar y recibir mensajes. El contenido de un bot varía
considerablemente en función de su tipo. El software para bot moderno se basa en una pila de tecnología y
herramientas que proporcionan experiencias cada vez más complejas en varias plataformas. Sin embargo, un
bot simple simplemente puede recibir un mensaje y devolvérselo al usuario con muy poco código implicado.
Soluciones nativas de la nube

La arquitectura nativa de la nube permite adoptar cambios rápidos y ejecutar aplicaciones resistentes y
escalables más fácilmente. Las aplicaciones nativas de la nube se suelen crear mediante contenedores,
microservicios, servicios administrados, funciones sin servidor y programación basada en eventos.
Normalmente, las soluciones nativas de la nube usan la entrega continua para lograr un tiempo de
comercialización más rápido.
Una solución nativa de la nube permite a los equipos de desarrollo centralizados mantener el control de la
lógica de negocios, sin necesidad de soluciones centralizadas monolíticas. Este tipo de solución también crea un
marcador para impulsar la coherencia entre las entradas de los desarrolladores cívicos y las experiencias
modernas. Por último, las soluciones nativas de la nube proporcionan un acelerador de la innovación al dar
libertad a los desarrolladores cívicos y profesionales para innovar de manera segura y con un mínimo de
bloqueos.
Innovar a través de soluciones existentes

Muchas hipótesis de clientes se pueden entregar mejor mediante una versión modernizada de una solución
existente. Esto puede ocurrir cuando la lógica de negocios actual busca satisfacer las necesidades del cliente.
La mayoría de las formas de modernización, incluida la refactorización, se describen en la metodología de
migración de Cloud Adoption Framework. Esa metodología guía a los equipos de adopción de la nube a través
del proceso de migración de un estado digital a la nube. La Guía de migración a Azure proporciona un enfoque
simplificado de la misma metodología, que es adecuada para un número reducido de cargas de trabajo o
incluso una sola aplicación.
Después de migrar y modernizar una solución, hay varias formas de usarla en la creación de nuevas soluciones
de aplicaciones innovadoras para satisfacer las necesidades de los clientes. Por ejemplo, los desarrolladores
cívicos podrían probar las hipótesis o los desarrolladores profesionales podrían crear experiencias inteligentes o
soluciones nativas de la nube.
Ampliar una solución existente
La ampliación de una solución es una forma común de modernización. Este enfoque puede ser la ruta más
rápida a la innovación cuando se cumplen las siguientes condiciones de la hipótesis del cliente:
La lógica de negocios existente satisface por completo o en su mayor parte las necesidades del cliente.
Una experiencia mejorada, no una nueva, satisface mejor las necesidades de los clientes.
La lógica de negocios que requiere la solución de producto mínimo viable (MVP) se ha centralizado,
normalmente a través de un diseño de n niveles, servicios web, API o microservicios. Este enfoque consiste
en encapsular la solución existente dentro de una nueva experiencia hospedada en la nube. En Azure, esta
solución probablemente residiría en Azure App Service.
Volver a crear una solución existente
Si una solución existente satisface por completo o en su mayor parte las necesidades del cliente, pero no se
puede ampliar fácilmente, puede que sea necesario refactorizarla. En este enfoque, la aplicación se migra a la
nube. Después de migrar la aplicación, se modifican o duplican partes de esta, como servicios web o
microservicios, que se implementan en paralelo a la solución existente. La solución paralela basada en servicio
podría tratarse como una solución ampliada. Esta solución simplemente encapsularía la solución existente con
una nueva experiencia hospedada en la nube. En Azure, esta solución probablemente residiría en Azure App
Service.
Cau t i on
La refactorización o la rearquitectura de soluciones o la centralización de la lógica de negocios puede
desencadenar rápidamente un pico técnico prolongado, en lugar de una fuente de valor para el cliente. Es un
riesgo de la innovación, especialmente en la validación de hipótesis. Con un poco de creatividad en el diseño de
una solución, debe haber una ruta a MVP que no requiera la refactorización de las soluciones existentes. Es
aconsejable retrasar la refactorización, hasta que se pueda validar la hipótesis inicial a escala.
Innovaciones del modelo operativo

Además de los enfoques modernos e innovadores para el desarrollo de aplicaciones, se han producido
innovaciones importantes en las operaciones de aplicaciones. Estos enfoques han generado muchos
movimientos de la organización. Uno de los más destacados es el modelo operativo de centro de excelencia en
la nube. Los equipos empresariales, cuando están provistos de personal y consolidados, tienen la opción de
proporcionar su propio soporte técnico operativo para una solución.
El tipo de modelo de administración operativa de autoservicio, que se encuentra en un centro de excelencia en
la nube, permite controles más estrictos e iteraciones más rápidas dentro del entorno de la solución. Estas metas
se logran mediante la transferencia del control operativo y la responsabilidad al equipo empresarial.
Si intenta escalar o satisfacer la demanda global de una solución existente, este enfoque puede ser suficiente
para validar una hipótesis de cliente. Una vez que una solución se migra y se moderniza ligeramente, el equipo
empresarial puede escalarla para probar una variedad de hipótesis. Normalmente implican a los cohortes de los
clientes que están preocupados por el rendimiento, la distribución global y otras necesidades de los clientes que
se ven entorpecidas por las operaciones de TI.
Reducir la sobrecarga y la administración

Cuantos más recursos haya que mantener en una aplicación o solución innovadora, más tiempo tardará esta en
iterar. Esto implica que puede acelerar la innovación al reducir el impacto de las operaciones en el ancho de
banda disponible.
Para prepararse para el número de iteraciones necesarias para ofrecer una solución innovadora, es importante
anticiparse. Por ejemplo, minimice las cargas operativas al principio del proceso, favoreciendo las opciones sin
servidor. En Azure, las opciones de aplicación sin servidor podrían incluir Azure App Service o contenedores.
En paralelo, tenga en cuenta las opciones de datos de transacción sin servidor que proporciona Azure, ya que
también pueden reducir la sobrecarga. El catálogo de productos de Azure proporciona opciones de base de
datos que hospedan datos sin necesidad de una plataforma de datos completa.
Pasos siguientes
En función de la hipótesis y la solución, los principios de este artículo pueden ayudar a diseñar aplicaciones que
cumplan con las definiciones de MVP e interaccionen con los usuarios. A continuación, se indican los principios
de capacitación para la adopción, que ofrecen formas de poner la aplicación y los datos en las manos de los
clientes de forma más rápida y eficiente.
Capacitación de la adopción con invención digital
La prueba definitiva de la innovación es la reacción de los clientes a su invención. ¿Se ha demostrado la

hipótesis? ¿Los clientes usan la solución? ¿Se puede escalar para satisfacer las necesidades del porcentaje de
usuarios deseado? Lo más importante, ¿siguen volviendo? No se puede realizar ninguna de estas preguntas
hasta que se haya implementado la solución de producto mínimo viable (MVP).
En este artículo, nos centraremos en capacitar la adopción con herramientas de la canalización de integración
continua y entrega continua (CI/CD). La integración continua es la automatización del código varias veces al día
para tener un único proyecto actualizado. La implementación continua es la entrega automática de esas
funciones a lo largo del día.
Reducción de la fricción de CI/CD que afecta a la adopción

Algunos obstáculos de la adopción se pueden minimizar con una combinación de tecnología y procesos. Para
los lectores con conocimientos sobre procesos de CI/CD o DevOps, los siguientes procesos de la canalización de
CI/CD les resultarán familiares. En este artículo se establece un punto de partida para los equipos de adopción
de la nube que ayuda con los bucles de innovación y comentarios. Este punto de partida podría fomentar
enfoques de CI/CD o DevOps más sólidos a medida que los productos y equipos se consoliden.
Tal y como se describe en Medida del impacto en los clientes, una validación positiva de cualquier hipótesis
requiere iteración y determinación. El objetivo de este artículo sobre CI/CD es minimizar la demanda técnica que
ralentiza la innovación y, al mismo tiempo, asegurarse de mantener en vigor los procedimientos recomendados.
Si lo hace, ayudará a que el diseño del equipo tenga éxito en el futuro, al mismo tiempo que satisface las
necesidades actuales de los clientes.
Capacitación para la adopción y la invención digital: el modelo de

madurez
El objetivo principal de la metodología de innovación es crear asociaciones con los clientes y acelerar los bucles
de comentarios, lo que dará lugar a innovaciones en el mercado. En la imagen y las secciones siguientes se
describen las implementaciones iniciales que apoyan esta metodología.
Solución compartida: establezca un repositorio centralizado para todos los aspectos de la solución.
Bucles de comentarios: asegúrese de que los bucles de comentarios se pueden administrar de forma
coherente mediante iteraciones.
Integración continua: compile la solución y consolídela con regularidad.
Pruebas confiables: valide la calidad de la solución y los cambios previstos para garantizar la confiabilidad de
las métricas de pruebas.
Implementación de la solución: implemente soluciones para que el equipo pueda compartir rápidamente los
cambios con los clientes.
Medida integrada: agregue métricas de aprendizaje al bucle de comentarios para que el equipo completo los
analice.
Para minimizar las demandas técnicas, dé por hecho que la madurez de cada uno de estos principios será baja
inicialmente. Planee por adelantado la alineación con las herramientas y los procesos que se pueden escalar a
medida que las hipótesis sean más específicas. En Azure, GitHub y Azure DevOps permiten a los equipos
pequeños empezar a trabajar con facilidad. Estos equipos pueden crecer hasta incluir a miles de desarrolladores
que colaboran en soluciones a escala y prueban cientos de hipótesis de clientes. En el resto de este artículo se
ilustra el enfoque "planea a lo grande, da pasos pequeños" para posibilitar la adopción de cada uno de estos
principios.
Solución compartida
Tal y como se describe en Medida del impacto en los clientes, una validación positiva de cualquier hipótesis
requiere iteración y determinación. Experimentará muchos más errores que aciertos durante los ciclos de
innovación. Se espera que esto sea así. Sin embargo, cuando se alinean a escala la necesidad del cliente, la
hipótesis y la solución, todo cambia rápidamente.
Cuando escala la invención digital y la innovación, la herramienta más valiosa es una base de código
compartido para la solución. Lamentablemente, no hay ninguna manera confiable de predecir qué iteración o
producto viable mínimo será la combinación ganadora. Esta es la razón por la que nunca es demasiado pronto
para establecer una base de código o un repositorio compartido. Esta es la única demanda técnica que no se
debe retrasar. A medida que el equipo itera por las distintas soluciones de producto viable mínimo, un
repositorio compartido facilita colaboración y acelera el desarrollo. Cuando los cambios en la solución minan las
métricas de aprendizaje, el control de versiones le permite revertir a una versión anterior y más efectiva de la
solución.
La herramienta de CI/CD más adoptada para administrar los repositorios de código es GitHub, que permite la
creación de un repositorio de código compartido en tan solo unos pasos. Como alternativa, se puede usar la
característica Azure Repos de Azure DevOps para crear un repositorio Git o TFVC.
Hacer que el cliente forme parte de la solución es la clave para crear asociaciones con los clientes durante los
ciclos de innovación. Esto se logra, en parte, midiendo el impacto del cliente. Requiere conversaciones y pruebas
directas con el cliente. Ambos generan comentarios que se deben administrar de forma eficaz.
Cada comentario es una posible solución a las necesidades del cliente. Lo que es más importante, cada uno de
los comentarios directos de un cliente representa una oportunidad para mejorar la relación. Si los comentarios
permiten dar con la solución viable mínima, celébrelo con el cliente. Aunque algunos comentarios no sean
accionables, ser transparentes con la decisión de reducir la prioridad de los comentarios demuestra una
mentalidad de crecimiento y una atención en el aprendizaje continuo.
Azure DevOps incluye maneras de solicitar, proporcionar y administrar comentarios. Cada una de estas
herramientas centraliza los comentarios para que el equipo pueda tomar medidas y proporcionar seguimiento
en servicio de un bucle de comentarios transparente.
Integración continua
La integración continua es la automatización del código varias veces al día para tener un único proyecto
actualizado. A medida que la adopción escala y la hipótesis se aproxima a una verdadera innovación a escala, el
número de pequeñas hipótesis que hay que probar tiende a crecer rápidamente. Para facilitar bucles de
comentarios precisos y procesos de adopción fluidos, es importante que cada una de esas hipótesis se integre y
respalde la hipótesis principal que subyace a la innovación. Esto requiere que sea rápido a la hora de innovar y
crecer, para lo cual necesita que varios desarrolladores prueben variantes de la hipótesis principal. En los
trabajos de desarrollo de fases posteriores, es posible que necesite varios equipos de desarrolladores que
colaboren en la creación de una solución compartida. La integración continua es el primer paso para la
administración de todas las partes móviles.
En la integración continua, los cambios de código se combinan con frecuencia en la rama principal. Los procesos
automatizados de compilación y pruebas garantizan que el código de la rama principal siempre tenga una
calidad de producción. Esto permite que los desarrolladores trabajen juntos para desarrollar soluciones
compartidas que proporcionen bucles de comentarios precisos y confiables.
Azure DevOps y Azure Pipelines proporcionan funcionalidades de integración continua con unos pocos pasos
en GitHub o en otros repositorios. Para más información, consulte ¿Qué es la integración continua? o el
laboratorio práctico. Existen arquitecturas de soluciones que pueden acelerar la creación de las canalizaciones de
CI/CD a través de Azure DevOps.
Pruebas confiables
Los defectos de cualquier solución pueden crear falsos positivos o falsos negativos. Los errores inesperados
pueden dar lugar a una interpretación incorrecta de las métricas de adopción de los usuarios. También pueden
generar comentarios negativos de los clientes que no representen con precisión la demostración de su
hipótesis.
En las primeras iteraciones de una solución de MVP, es normal que haya defectos. Los usuarios pioneros pueden
incluso encontrarlos simpáticos. En las primeras versiones, no suelen existir pruebas de aceptación. Sin
embargo, uno de los aspectos de la creación con empatía está relacionado con la validación de la necesidad y la
hipótesis. Ambas se pueden realizar mediante pruebas unitarias en el nivel de código y pruebas de aceptación
manuales antes de la implementación. En conjunto, proporcionan medios para confiar en las pruebas. Debe
procurar automatizar una serie bien definida de pruebas de creación, unitarias y de aceptación. Esto garantizará
métricas confiables relacionadas con ajustes más pormenorizados de la hipótesis y la solución resultante.
La característica Azure Test Plans proporciona herramientas para desarrollar y utilizar planes de pruebas durante
la ejecución de pruebas manuales o automatizadas.
Implementación de la solución
Quizás el aspecto más significativo de la capacitación para la adopción es la posibilidad de controlar la
publicación de una solución para los clientes. Proporcionar una canalización de autoservicio o automatizada
para lanzar una solución a los clientes acelera el bucle de comentarios. Permitir a los clientes interactuar con los
cambios en la solución rápidamente les invita a participar en el proceso. Este enfoque también desencadena
pruebas más rápidas de las hipótesis, lo que reduce las suposiciones y las posibles repeticiones del trabajo.
Existen varios métodos para la implementación de soluciones. Los tres más comunes son los siguientes:
La implementación continua es el enfoque más avanzado, ya que implementa automáticamente los
cambios de código en producción. Para los equipos experimentados que realizan pruebas de hipótesis más
desarrolladas, la implementación continua puede ser muy valiosa.
Durante las primeras fases del desarrollo, puede ser más adecuada la entrega continua . En la entrega
continua, los cambios de código se implementan automáticamente en un entorno similar al de producción.
Los desarrolladores, los responsables de la toma de decisiones empresariales y otros miembros del equipo
pueden usar este entorno para comprobar si su trabajo está listo para producción. También puede usar este
método para probar una hipótesis con los clientes, sin que ello afecte a las actividades empresariales en
curso.
La implementación manual es el enfoque menos sofisticado para la administración de versiones. Como
sugiere el nombre, alguien del equipo implementara manualmente los cambios de código más recientes.
Este enfoque es propenso a errores, no confiable y considerado un antipatrón por los ingenieros más
experimentados.
Durante la primera iteración de una solución mínima viable, es habitual la implementación manual a pesar de la
valoración anterior. Cuando la solución es muy fluida y no se conocen los comentarios de los clientes,
restablecer toda la solución (o incluso la hipótesis principal) supone un riesgo significativo. La regla general de
la implementación manual es que no se realiza ninguna prueba de cliente ni automatización de la
implementación.
Invertir pronto puede provocar pérdida de tiempo. Lo que es más importante, puede crear dependencias en la
canalización de lanzamiento, lo que hace que el equipo sea más resistente a una dinamización temprana.
Después de las primeras iteraciones o cuando los comentarios de los clientes sugieren un posible éxito, se debe
adoptar rápidamente un modelo de implementación más avanzado.
En cualquier etapa de la validación de hipótesis, Azure DevOps y Azure Pipelines proporcionan funciones de
entrega continua e implementación continua. Obtenga más información sobre la entrega continua o consulte el
laboratorio práctico. La arquitectura de la solución también puede acelerar la creación de sus canalizaciones de
CI/CD a través de Azure DevOps.
Medidas integradas
A la hora de medir el impacto en el cliente, es importante comprender cómo reaccionan los clientes a los
cambios en la solución. Estos datos, que se conocen como telemetría, proporcionan información detallada sobre
las acciones que tomó un usuario (o una cohorte de usuarios) al trabajar con la solución. A partir de estos datos,
es fácil obtener una validación cuantitativa de la hipótesis. Estas métricas se pueden usar para ajustar la solución
y generar hipótesis más específicas. Estos cambios más sutiles ayudan a madurar la solución inicial en
iteraciones posteriores, lo que conduce en última instancia a repetir la adopción a gran escala.
En Azure, Azure Monitor proporciona herramientas y una interfaz para recopilar y revisar datos de las
experiencias de los clientes. Puede aplicar dichas observaciones e información para refinar el trabajo pendiente
mediante Azure Boards.
Pasos siguientes
Una vez que comprenda las herramientas y los procesos de la canalización de CI/CD necesarios para posibilitar
la adopción, es el momento de examinar una materia de innovación más avanzada: la interacción con
dispositivos. Esta materia puede ayudar a reducir las barreras entre las experiencias física y digital, lo que facilita
la adopción de la solución.
Experiencias ambientales de usuario: Interacción
con dispositivos
En Crear con la empatía de los clientes, analizamos las tres pruebas de la verdadera innovación: solucionar las
necesidades de un cliente, lograr que el cliente vuelva y escalar a través de una base de cohortes de clientes.
Probar cada hipótesis requiere trabajo e iteraciones en el enfoque de la adopción. En este artículo se
proporciona información detallada sobre enfoques avanzados para reducir ese trabajo mediante experiencias
ambientales de usuario. Al interactuar con dispositivos en lugar de hacerlo con una aplicación, es posible que el
cliente tenga más probabilidades de acudir primero a su solución.
Experiencias ambientales de usuario

Una experiencia ambiental de usuario es una experiencia digital que está relacionada con el entorno inmediato.
Las experiencias ambientales de usuario se producen cuando los sistemas tecnológicos interactúan sin
problemas con un usuario en función de sus necesidades y del contexto de sus solicitudes. Una solución que
ofrece experiencias ambientales de usuario se esfuerza por satisfacer al cliente en el momento que lo necesita.
Siempre que es posible, la solución satisface las necesidades del cliente sin abandonar el flujo de actividades
que la provocó.
La vida en la economía digital está llena de distracciones. A todos nos bombardean con mensajes de redes
sociales, correo electrónico, web, visuales y verbales, y cada uno de estos elementos supone una posibilidad de
distracción. Este riesgo aumenta con cada segundo que transcurre entre el momento que se produce la
necesidad del cliente y el momento en que se encuentra una solución. Innumerables clientes se pierden en ese
breve intervalo de tiempo. Para fomentar una mayor adopción reiterada, debe reducir el tiempo de solución y
así disminuirá también el número de distracciones.

Una experiencia web estándar es la técnica de desarrollo de aplicaciones más común que se usa para satisfacer
las necesidades de un cliente. En este enfoque se supone que el cliente está delante de su equipo. Si el cliente
normalmente satisface sus requisitos mientras está delante del equipo, cree una aplicación web. Esta aplicación
proporcionará una experiencia ambiental de usuario para ese cliente en ese escenario. Sin embargo, sabemos
que este escenario cada vez es menos probable.
Hoy en día, las experiencias ambientales de usuario requieren normalmente algo más que una aplicación web.
Mediante la medición y el aprendizaje con el cliente, el comportamiento que desencadena la necesidad del
cliente se puede observar, controlar y usar para crear una experiencia digital ambiental más adecuada. En la
siguiente lista se resumen algunos enfoques para integrar soluciones ambientales en sus hipótesis con más
información sobre cada una de ellas en los párrafos siguientes.
Tipos de dispositivos interactivos para las experiencias ambientales de usuario:
Experiencia móvil : las aplicaciones móviles están omnipresentes en los entornos de clientes. En algunas
situaciones, esto puede proporcionar un nivel suficiente de interactividad para crear una solución ambiental.
Realidad mixta:: a veces, el entorno típico de un cliente debe modificarse para conformar un ambiente de
interacción. Este factor crea una suerte de realidad falsa en la que el cliente interactúa con la solución y se
resuelve una de sus necesidades. En este caso, la solución es un ambiente dentro de la realidad falsa.
Realidad integrada : al aproximarse a un ambiente real, las soluciones de realidad integrada se centran en
el uso de un dispositivo que existe dentro de la realidad del cliente para integrar la solución en
comportamientos naturales. Un asistente virtual es un buen ejemplo de integración de la realidad en el
entorno circundante. Una opción menos conocida es el uso de tecnologías de Internet de las cosas (IoT) que
integran dispositivos que ya existen en el entorno del cliente.
Realidad ajustada : cuando alguna de las soluciones ambientales anteriores usa el análisis predictivo en la
nube para definir y proporcionar una interacción con el cliente dentro de su entorno natural, la solución
incluye realidad ajustada.
Comprender la necesidad del cliente y cuantificar los efectos en él contribuirá a determinar si se va a requerir la
interacción de un dispositivo o una experiencia ambiental para comprobar su hipótesis. Las secciones siguientes
le ayudarán a encontrar la mejor solución con experiencia digital para cada uno de esos puntos de datos.
Experiencia móvil
En la primera fase de la experiencia ambiental de usuario, este se debe alejar del equipo. Los consumidores y los
profesionales de la actualidad se mueven con fluidez entre dispositivos móviles y PC. Cada una de las
plataformas o dispositivos usados por el cliente crea una nueva experiencia potencial. Agregar una experiencia
móvil que amplíe la solución principal es la forma más rápida de mejorar la integración en el entorno inmediato
del cliente. Aunque un dispositivo móvil esté lejos del ambiente, podría estar más próximo a la necesidad del
cliente.
Cuando los clientes cambian de ubicación con frecuencia, puede ser la forma más pertinente de experiencia
ambiental y digital para una solución concreta. En la última década, la integración de las soluciones existentes
con una experiencia móvil ha desencadenado frecuentemente la innovación.
Azure App Service es un buen ejemplo de este enfoque. Durante las primeras iteraciones, se puede usar la
característica de aplicación web de Azure App Service para probar la hipótesis. A medida que las hipótesis se
vuelven más complejas, la característica de aplicación móvil de Azure App Service puede ampliar la aplicación
web para que se ejecute en diversas plataformas móviles.
Realidad mixta
Las soluciones de realidad mixta representan el siguiente paso en las experiencias ambientales de usuario. Este
enfoque aumenta o replica el entorno del cliente y crea una extensión de la realidad para que el cliente trabaje
dentro de ella.
IMPORTANT
Si se requiere un dispositivo de realidad virtual y todavía no forma parte de los comportamientos naturales o
circundantes inmediatos de un cliente, la realidad virtual o aumentada es más una experiencia alternativa digital y menos
una experiencia ambiental.
Las experiencias de realidad mixta son cada vez más habituales entre los empleados remotos. Su uso está
creciendo aún más rápido en sectores que requieren conocimientos de colaboración o especializados que no
están disponibles en el mercado local. Las situaciones que requieren la implementación centralizada de un
producto complejo para un grupo de empleados remotos son un terreno especialmente adecuado para la
realidad aumentada. En esos casos, el equipo de soporte técnico central y los empleados remotos pueden usar
la realidad aumentada para solucionar problemas, instalar el producto o trabajar con él.
Por ejemplo, considere el caso de los anclajes espaciales. Los anclajes espaciales le permiten crear experiencias
de realidad mixta con objetos cuyas ubicaciones correspondientes persisten en todos los dispositivos a lo largo
del tiempo. Los anclajes espaciales se usan para capturar, grabar y conservar un comportamiento específico, que
proporcionará una experiencia ambiental la próxima vez que el usuario trabaje dentro de ese entorno
aumentado. Azure Spatial Anchors es un servicio que mueve esta lógica a la nube, lo que permite compartir
experiencias digitales entre dispositivos interactivos e incluso entre soluciones.
Realidad integrada
La realidad integrada va más allá de la realidad móvil o incluso de la realidad mixta. La realidad integrada
pretende eliminar por completo la experiencia digital. Todos los dispositivos que usamos tienen funcionalidades
de conectividad y proceso. Estos dispositivos se pueden usar para recopilar datos del entorno inmediato sin que
el cliente tenga que tocar un teléfono, un portátil o un dispositivo de realidad virtual.
Esta experiencia digital es idónea cuando una forma de dispositivo es coherente en el mismo entorno en el que
se produce la necesidad del cliente. Entre los escenarios comunes se incluyen las fábricas, los ascensores o
incluso su automóvil. Estos tipos de dispositivos grandes ya contienen potencia de proceso. También puede usar
datos del propio dispositivo para detectar los comportamientos del cliente y enviarlos a la nube. Esta captura
automática de los datos de comportamiento del cliente reduce drásticamente la necesidad de que un cliente
escriba datos. Además, la experiencia web, móvil o de realidad virtual puede funcionar como un bucle de
comentarios para compartir lo que se ha aprendido de la solución de realidad integrada.
Entre los ejemplos de realidad integrada en Azure se incluyen:
Soluciones de Internet de las cosas (IoT) de Azure: Una colección de servicios de Azure que ayuda a
administrar los dispositivos y el flujo de datos desde esos dispositivos hacia la nube y de vuelta a los
usuarios finales.
Azure Sphere: Una combinación de hardware y software que ofrece una manera intrínsecamente segura de
permitir que un dispositivo existente transmita datos entre el dispositivo y las soluciones de Azure IoT.
Azure Kinect DK, sensores de IA con modelos avanzados de Computer Vision y de voz. Estos sensores
pueden recopilar datos visuales y de audio del entorno inmediato y alimentan la solución con esas entradas.
Puede usar las tres herramientas de experiencia digital para recopilar datos del entorno natural y en el
momento en que se produce la necesidad del cliente. A partir de ahí, la solución puede responder a esas
entradas de datos para resolver la necesidad, a veces antes de que el cliente sea consciente de que se ha
desencadenado esa necesidad.
Realidad ajustada
La forma más refinada de experiencia ambiental de usuario es la realidad ajustada, también conocida como
inteligencia ambiental. La inteligencia ambiental hace referencia a cualquier entorno electrónico o digital que
responde a la presencia de personas y se ajusta automáticamente. La realidad ajustada es un enfoque
relacionado con el uso de la información de la solución para cambiar la realidad del cliente sin que este tenga
que interactuar directamente con una aplicación. En este enfoque, la aplicación que creó inicialmente para
demostrar su hipótesis puede que ya no sea pertinente. En su lugar, los dispositivos del entorno ayudarían a
modular las entradas y salidas para satisfacer las necesidades de los clientes.
Los asistentes virtuales o altavoces inteligentes son un buen ejemplo de realidad ajustada. Por sí mismo, un
altavoz inteligente es un ejemplo de realidad integrada simple. Agregue una luz inteligente y un sensor de
movimiento a una solución de altavoz inteligente, y habrá creado fácilmente una solución básica que encienda
las luces cuando se entra en una habitación.
Las fábricas de todo el mundo constituyen otros ejemplos de realidad ajustada. En las primeras fases de la
realidad integrada, los sensores de los dispositivos detectaban condiciones como un sobrecalentamiento, y la
notificaban a un ser humano mediante una aplicación. En la realidad ajustada, el cliente podría seguir
participando, pero el bucle de comentarios es más estrecho. En una fábrica con realidad ajustada, un dispositivo
podría detectar el sobrecalentamiento de una máquina vital en alguna parte de la línea de montaje. En cualquier
otra parte de la planta, un segundo dispositivo ralentizaría la producción ligeramente para permitir que la
máquina se enfriara y el ritmo se reanudara cuando se resolviera la condición. En esta situación, el cliente es un
participante de segunda mano. El cliente utiliza la aplicación para establecer las reglas y entender cómo han
afectado a la producción, pero no sería una parte necesaria del bucle de comentarios.
Los servicios de Azure que se describen en Soluciones de Internet de las cosas (IoT) de Azure, Azure Sphere y
Azure Kinect DK podrían ser componentes de una solución de realidad ajustada. La aplicación original y la lógica
de negocios serviría como intermediario entre la entrada del entorno y el cambio que se debe realizar en el
entorno físico.
Un gemelo digital es otro ejemplo de realidad ajustada. Este término se refiere a una representación digital de
un dispositivo físico que se presenta mediante equipos, dispositivos móviles o formatos de realidad mixta. A
diferencia de los modelos 3D menos sofisticados, un gemelo digital refleja los datos recopilados de un
dispositivo real en el entorno físico. Esta solución permite al usuario interactuar con la representación digital de
maneras que nunca podrían darse en el mundo real. En este enfoque, los dispositivos físicos ajustan un entorno
de realidad mixta. Sin embargo, la solución sigue recopilando datos de una solución de realidad integrada y
usándolos para dar forma a la realidad del entorno actual del cliente.
En Azure, se crean gemelos digitales y se accede a ellos con un servicio llamado Azure Digital Twins.
Pasos siguientes
Ahora que conoce mejor las interacciones con los dispositivos y la experiencia ambiental de usuario o las
herramientas de inteligencia ambiental adecuadas para su solución, ya está preparado para explorar la materia
final de innovación: predicción e influencia.
Predicción e influencia
Modelado predictivo e influencia en el
comportamiento del cliente
Hay dos clases de aplicaciones en la economía digital: históricas y predictivas. Muchas de las necesidades de los
clientes se pueden satisfacer únicamente mediante el uso de datos históricos, incluidos los datos casi en tiempo
real. En este momento, la mayoría de las soluciones se centran principalmente en la agregación de datos.
Después, procesan y comparten los datos de nuevo con el cliente, en forma de experiencia digital o sobre el
terreno.
Lo opuesto al modelado histórico es el modelado predictivo. Pero, ¿qué es el modelado predictivo? El modelado
predictivo usa estadísticas y resultados conocidos para procesar y crear modelos que se pueden usar para
predecir resultados futuros, dentro de lo razonable. A medida que el modelado predictivo es más rentable y está
disponible fácilmente, los clientes exigen experiencias avanzadas que les lleven a mejores decisiones y acciones.
Sin embargo, esa demanda no siempre sugiere una solución predictiva. En la mayoría de los escenarios, una
vista de los datos históricos puede proporcionar información suficiente para permitir al cliente tomar una
decisión por sí mismo.
Por desgracia, los clientes suelen tener una falta de visión que conduce a tomar decisiones en función de su
entorno inmediato y de su esfera de influencia. A medida que las opciones y las decisiones crecen en número y
consecuencias, es posible que esta falta de visión no satisfaga las necesidades de los clientes. Al mismo tiempo,
cuando se demuestra una hipótesis a escala, la empresa que proporciona la solución puede comprender miles o
millones de decisiones de los clientes. Este enfoque general permite ver patrones amplios, así como el impacto
que tienen. La funcionalidad de modelado predictivo es una inversión razonable cuando es necesario
comprender esos patrones para tomar las decisiones más acertadas para el cliente.
Ejemplos de modelado predictivo y cómo influye en el

comportamiento del cliente
Diversas aplicaciones y experiencias ambientales usan datos para realizar predicciones:
Comercio electrónico: en función de lo que otros consumidores similares hayan adquirido, un sitio web de
comercio electrónico sugiere productos que puede merecer la pena agregar al carro.
Realidad ajustada: IoT ofrece instancias más avanzadas de funcionalidad predictiva. Por ejemplo, un
dispositivo en una línea de ensamblado detecta un aumento de la temperatura de una máquina. Un modelo
predictivo basado en la nube determina cómo responder. En función de esa predicción, otro dispositivo
ralentiza la línea de montaje hasta que la máquina se enfría.
Productos de consumo: los teléfonos móviles, las casas inteligentes, incluso el automóvil, usan
funcionalidades predictivas, las cuales estos analizan para sugerir el comportamiento del usuario en función
de factores como la ubicación o la hora del día. Cuando la predicción y la hipótesis inicial se alinean, la
predicción conduce a la acción. En una fase muy avanzada, esta alineación puede hacer que productos, como
un vehículo autónomo, sean una realidad.
Desarrollo de funcionalidades predictivas

Las soluciones que proporcionan constantemente funcionalidades de predicción precisas suelen incluir cinco
características principales. Las cinco características principales del modelado predictivo son:
data
Información detallada
Patrones
Predicciones
Interacciones
Cada aspecto es necesario para desarrollar las funcionalidades predictivas. Al igual que todas las grandes
innovaciones, el desarrollo de funcionalidades predictivas requiere un compromiso con la iteración. En cada
iteración, una o varias de las siguientes características se consolidan para comprobar hipótesis de clientes cada
vez más complejas.
Cau t i on
Si la hipótesis del cliente desarrollada en Creación con la empatía de los clientes incluye funcionalidades
predictivas, puede que se apliquen los principios descritos. Sin embargo, las funcionalidades predictivas
requieren una gran inversión de tiempo y energía. Cuando las funcionalidades predictivas constituyen
demandas técnicas en lugar de una posible fuente de valor para el cliente, se recomienda retrasar las
predicciones hasta que se hayan comprobado las hipótesis de los clientes a escala.
data
Los datos son el componente más elemental de las características mencionadas anteriormente. Cada una de las
materias para desarrollar invenciones digitales genera datos. Ciertamente, esos datos contribuyen al desarrollo
de predicciones. Para más información sobre las formas de trasladar datos a una solución predictiva, consulte
Democratización de datos con la invención digital e Interacción con dispositivos.
Se pueden usar diversos orígenes de datos para proporcionar funcionalidades de modelado predictivo.
Información detallada
Los expertos en la materia usan los datos sobre las necesidades y comportamientos de los clientes para
desarrollar conclusiones empresariales básicas a partir de un estudio de datos sin procesar. Esta información
detallada puede identificar los casos de comportamientos deseados de los clientes (o, por el contrario, los
resultados no deseados). Durante las iteraciones en las predicciones, esta información detallada puede ayudar a
identificar posibles correlaciones, lo que finalmente podría generar resultados positivos. Para obtener
información sobre cómo permitir que los expertos en la materia elaboren conclusiones, consulte
Democratización de datos con la invención digital.
Patrones
Las personas siempre han intentado detectar patrones en grandes volúmenes de datos. Los equipos
informáticos se diseñaron para ese propósito. La solución Machine Learning acelera esta misión mediante la
detección precisa de dichos patrones, una aptitud que comprende el modelo de modelo de Machine Learning. A
continuación, estos patrones se aplican mediante algoritmos de aprendizaje automático para predecir los
resultados cuando se especifique un nuevo conjunto de puntos de datos en los algoritmos.
Usando las conclusiones como punto de partida, el aprendizaje automático desarrolla y aplica modelos
predictivos para exprimir los patrones de datos. A través de varias iteraciones de entrenamiento, prueba y
adopción, estos modelos y algoritmos pueden predecir con precisión los resultados futuros.
Azure Machine Learning es el servicio nativo en la nube de Azure para la creación y el entrenamiento de
modelos basados en los datos. Esta herramienta también incluye un flujo de trabajo para acelerar el desarrollo
de algoritmos de aprendizaje automático. Este flujo de trabajo se puede usar para desarrollar algoritmos
mediante una interfaz visual o Python.
Si lo que se busca son modelos de aprendizaje automático más sólidos, los servicios de aprendizaje automático
de Azure HDInsight proporcionan una plataforma de aprendizaje automático basada en clústeres de Apache
Hadoop. Este enfoque permite un control más pormenorizado de los clústeres subyacentes, el almacenamiento
y los nodos de proceso. Azure HDInsight también proporciona una integración más avanzada mediante
herramientas como ScaleR y SparkR para crear predicciones basadas en datos integrados e ingeridos, incluso
con datos de una secuencia. La solución de predicción de retrasos de vuelos muestra cada una de estas
funcionalidades avanzadas cuando se usa para predecir retrasos de vuelos en función de las condiciones
meteorológicas. La solución de HDInsight también permite controles empresariales, como la seguridad de los
datos, el acceso a la red y la supervisión del rendimiento para la puesta en marcha de patrones.
Predicciones
Después de crear y entrenar un patrón, puede aplicarlo mediante las API, que pueden realizar predicciones
durante la entrega de una experiencia digital. La mayoría de estas API se crean a partir de un modelo bien
entrenado basado en un patrón de los datos. A medida que más clientes implementan las cargas de trabajo
diarias en la nube, las API de predicción que usan los proveedores de la nube conducen a una adopción cada vez
más rápida.
Azure Cognitive Services es un ejemplo de API predictiva creada por un proveedor de la nube. Este servicio
incluye API predictivas para la moderación de contenido, la detección de anomalías y las sugerencias para
personalizar el contenido. Estas API están preparadas para usar y se basan en patrones de contenido conocidos,
que Microsoft ha usado para entrenar los modelos. Cada una de esas API realiza predicciones basadas en los
datos que se introducen en la API.
Azure Machine Learning permite la implementación de algoritmos personalizados, que pueden crear y entrenar
únicamente con sus propios datos. Para obtener información sobre la implementación de predicciones con
Azure Machine Learning, consulte Implementación de modelos de aprendizaje automático en Azure.
Para más información sobre los procesos para exponer las predicciones desarrolladas para ML Services en
Azure HDInsight, consulte Configuración de clústeres de HDInsight.
Interacciones
Una vez que una predicción está disponible a través de una API, se puede usar para influir en el
comportamiento del cliente. Esa influencia se produce en forma de interacciones. Una interacción con un
algoritmo de aprendizaje automático se produce dentro de las otras experiencias digitales o ambientales. A
medida que se recopilan datos a través de la aplicación o la experiencia, se ejecutan mediante los algoritmos de
aprendizaje automático. Cuando el algoritmo predice un resultado, la predicción se puede volver a compartir
con el cliente mediante la experiencia actual.
Obtenga más información sobre cómo crear una experiencia ambiental a través de una solución de realidad
ajustada.
Pasos siguientes
Una vez familiarizado con las materias de invención y la metodología de innovación, está preparado para
aprender a crear usando la empatía con el cliente.
Crear con empatía
Gobernanza en Microsoft Cloud Adoption
Framework para Azure
La nube crea nuevos paradigmas para las tecnologías que respaldan el negocio. Estos nuevos paradigmas
también cambian la forma en que se adoptan, administran y gobiernan esas tecnologías. Si es posible destruir y
volver a crear centros de datos enteros con una sola línea de código ejecutada desde un proceso desatendido, es
preciso volver a considerar los enfoques tradicionales. Esto es especialmente cierto en el caso de la gobernanza.
La gobernanza de la nube es un proceso iterativo. Para las organizaciones con directivas existentes que
gobiernan los entornos de TI locales, la gobernanza de la nube debe complementar esas directivas. El nivel de
integración de las directivas corporativas entre el entorno local y la nube varía en función de la madurez de la
gobernanza de la nube y del patrimonio digital en la nube. A medida que el patrimonio de la nube cambia con el
tiempo, también lo hacen los procesos y las directivas de gobernanza de la nube. Los ejercicios siguientes le
ayudarán a empezar a crear su base de gobernanza inicial.
1. Metodología: Establezca un reconocimiento básico de la metodología que promueve la gobernanza en la
nube dentro de Cloud Adoption Framework para empezar a pensar en la solución de estado final.
2. Banco de pruebas: Evaluación del estado actual y futuro para establecer una visión a la hora de aplicar la
plataforma.
3. Base de gobernanza inicial: Comience su recorrido por la gobernanza con un pequeño conjunto de
herramientas de gobernanza de fácil implementación. Esta base de gobernanza inicial se denomina producto
viable mínimo (MVP).
4. Mejora de la base de gobernanza inicial: Durante la implementación del plan de adopción de la nube,
agregue de manera iterativa los controles de gobernanza para afrontar riesgos tangibles a medida que
avanza hacia el estado final.
Objetivo de este contenido

La guía de esta sección de Cloud Adoption Framework sirve para dos fines:
Proporcionar ejemplos de guías prácticas de gobernanza que representan experiencias comunes que los
clientes encuentran a menudo. Cada ejemplo encapsula los riesgos empresariales, las directivas corporativas
para la mitigación de riesgos y la guía de diseño para la implementación de soluciones técnicas. Por
necesidad, la guía de diseño es específica de Azure. El contenido restante de estas guías puede aplicarse en
un enfoque independiente de la nube o en un enfoque de nube múltiple.
Ayudar a crear soluciones de gobernanza personalizadas que satisfagan diferentes necesidades
empresariales. Estas necesidades incluyen la gobernanza de varias nubes públicas con una guía detallada
sobre el desarrollo de las herramientas, los procesos y las directivas corporativas.
Este contenido está diseñado para su uso por parte del equipo de gobernanza de la nube. También es relevante
para los arquitectos de nube que necesitan desarrollar una base sólida en la gobernanza de la nube.
Destinatarios
El contenido de Cloud Adoption Framework afecta al negocio, a la tecnología y a la cultura de las empresas. Esta
sección de Cloud Adoption Framework interactúa considerablemente con los equipos de seguridad de TI,
gobernanza de TI, finanzas, responsables de línea de negocio, redes, identidad y adopción de la nube. Varias
dependencias de estos roles requieren un enfoque facilitador por parte de los arquitectos de la nube que usan
esta guía. La facilitación de estos equipos puede ser una tarea única. En algunos casos, las interacciones con
estos otros usuarios serán continuas.
El arquitecto de la nube sirve como líder de pensamiento y facilitador para reunir a estas audiencias. El
contenido de esta colección de guías está diseñado para ayudar al arquitecto de la nube a facilitar la
conversación correcta, con la audiencia adecuada, para tomar las decisiones necesarias. La transformación
empresarial que potencia la nube depende de que el arquitecto de la nube sirva de guía en las decisiones tanto
de TI como de toda la empresa.
Especialización de arquitecto de la nube en esta sección : Cada una de las secciones de Cloud Adoption
Framework representa una especialización o variante diferentes del rol de arquitecto de la nube. Esta sección de
Cloud Adoption Framework está diseñada para arquitectos de la nube con pasión por la reducción de riesgos
técnicos. Algunos proveedores de servicios en la nube se refieren a estos especialistas como administradores de
la nube, pero nosotros preferimos llamarles protectores de la nube o, colectivamente, equipo de gobernanza de
la nube. Las guías de gobernanza que requiere acción muestran de qué forma tanto la composición como el rol
del equipo de gobernanza de la nube pueden cambiar con el tiempo.
Uso de esta guía

Leer el contenido de la metodología de gobernanza de un extremo a otro le ayudará a desarrollar una sólida
estrategia de gobernanza en la nube en paralelo con la implementación en la nube. Estas instrucciones le guían
mediante la teoría y la implementación de esta estrategia.
Para un curso intensivo sobre la teoría y el acceso rápido a la implementación de Azure, comience con la
introducción a las guías de gobernanza. Mediante esta guía, puede empezar con poco y mejorar iterativamente
sus necesidades de gobernanza en paralelo con los esfuerzos de adopción de la nube.
Gobernanza de la metodología para la nube
Adoptar la nube es un recorrido, no un destino. En el camino, hay hitos claros y ventajas empresariales
tangibles. El estado final de la adopción de la nube es desconocido cuando una compañía comienza el recorrido.
La gobernanza de la nube crea barreras de seguridad que mantienen a la compañía en una ruta segura a lo
largo del recorrido.
Cloud Adoption Framework ofrece guías de gobernanza que describen las experiencias de compañías ficticias
basadas en experiencias de clientes reales. Cada guía sigue al cliente a través de los aspectos de gobernanza de
la adopción de la nube.
Previsión de un estado final

Un recorrido sin un destino objetivo no es más que una deambulación. Es importante establecer una visión
aproximada del estado final antes de dar el primer paso. La infografía siguiente proporciona un marco de
referencia del estado final. No es el punto de partida, sino que muestra el destino posible.
El modelo de gobernanza del marco de adopción en la nube identifica las principales áreas de importancia del
recorrido. Cada área se relaciona con diferentes tipos de riesgos que la compañía debe resolver al adoptar más
servicios en la nube. En este marco, la guía de gobernanza identifica las acciones necesarias para el equipo de
gobernanza en la nube. En el camino, cada entidad de seguridad del modelo de gobernanza del marco de
adopción en la nube se describe con más detalle. En líneas generales, se incluyen las siguientes:
Directivas corporativas: Las directivas corporativas rigen la gobernanza de la nube. La guía de gobernanza se
centra en aspectos específicos de las directivas corporativas:
Riesgos empresariales: identificación y reconocimiento de los riesgos corporativos.
Directiva y cumplimiento: conversión de los riesgos en instrucciones de directiva que admitan los
requisitos de cumplimiento.
Procesos: garantía del cumplimiento de las directivas indicadas.
Cinco disciplinas de la gobernanza de la nube: Estas disciplinas admiten las directivas corporativas. Cada
disciplina protege a la compañía de posibles dificultades:
Materia de base de referencia de seguridad
Materia de base de referencia de identidad
Materia de aceleración de la implementación
Básicamente, las directivas corporativas sirven como sistema de advertencia anticipada para detectar posibles
problemas. Las disciplinas ayudan a la compañía a mitigar los riesgos y crear barreras de seguridad.
Alcanzar el estado final

Dado que los requisitos de gobernanza cambiarán a lo largo del recorrido de adopción de la nube, se requiere
un enfoque diferente para la gobernanza. Las compañías ya no pueden esperar a que un equipo pequeño cree
las barreras de seguridad y los mapas de ruta de cada trayectoria antes de dar el primer paso . Se esperan
resultados empresariales más rápidamente y sin problemas. La gobernanza de TI también debe avanzar
rápidamente y mantener el ritmo de las demandas empresariales para conservar su relevancia durante la
adopción de la nube y evitar "shadow IT".
Un enfoque de gobernanza incremental fortalece estos rasgos. La gobernanza incremental se basa en un
pequeño conjunto de directivas corporativas, procesos y herramientas para establecer una base para la
adopción y la gobernanza. Esta base se denomina producto viable mínimo (MVP) . Un MVP permite al equipo de
gobernanza incorporar con rapidez la gobernanza en las implementaciones a lo largo del ciclo de vida de la
adopción. Se puede establecer un MVP en cualquier punto durante el proceso de adopción de la nube. Es
recomendable adoptar un MVP tan pronto como sea posible.
La capacidad de responder rápidamente a los riesgos cambiantes faculta al equipo de gobernanza en la nube
para desarrollar nuevos métodos. El equipo de gobernanza en la nube puede unirse al equipo de estrategia de la
nube con una función de explorador, moviéndose por delante de los equipos de adopción de la nube, trazando
rutas y estableciendo rápidamente barreras de seguridad para administrar los riesgos asociados con los planes
de adopción. Estos niveles de gobernanza just-in-time se conocen como iteraciones de gobernanza. Con este
enfoque, la estrategia de gobernanza avanza un paso por delante de los equipos de adopción de la nube.
En el siguiente diagrama se muestra un MVP de gobernanza simple y tres iteraciones de gobernanza. Durante
las iteraciones, se definen directivas corporativas adicionales para corregir los nuevos riesgos. Luego la
disciplina de aceleración de la implementación aplica dichos cambios en cada implementación.
NOTE
La gobernanza no sustituye a las funciones clave como la seguridad, las redes, la identidad, las finanzas, DevOps o las
operaciones. En el camino, surgirán interacciones y dependencias con los miembros de cada función. Estos miembros
deben incluirse en el equipo de gobernanza en la nube para acelerar las decisiones y las acciones.
Pasos siguientes
Aprenda a usar la herramienta de pruebas comparativas de gobernanza de Cloud Adoption Framework para
evaluar su recorrido de transformación e identificar carencias en su organización en seis dominios clave, tal y
como se define en el marco.
Evaluación del recorrido de transformación
Evaluación del recorrido de transformación
Cloud Adoption Framework proporciona una herramienta de pruebas comparativas de gobernanza que le
ayudará a identificar carencias en su organización en seis dominios clave, tal y como se define en el marco.
Herramienta de pruebas comparativas de gobernanza

Reciba un informe personalizado que describe la diferencia entre el estado actual y las prioridades
empresariales, junto con los recursos personalizados que le ayudarán a empezar. Evaluación del estado actual y
futuro para establecer una visión a la hora de aplicar la plataforma.
Uso de la herramienta de pruebas comparativas de gobernanza
Pasos siguientes
Comience su recorrido por la gobernanza con un pequeño conjunto de herramientas de gobernanza de fácil
implementación. Esta base de gobernanza inicial se denomina producto viable mínimo (MVP).
Establecimiento de una base de gobernanza inicial
Establecimiento de una base de gobernanza de la
nube inicial
El establecimiento de la gobernanza de la nube es un esfuerzo iterativo amplio. Es difícil lograr un equilibrio

efectivo entre velocidad y control, especialmente durante la ejecución de las metodologías iniciales de la
adopción de la nube. La guía de gobernanza de Cloud Adoption Framework ayuda a proporcionar ese equilibrio
mediante un enfoque ágil de adopción.
En este artículo se proporcionan dos opciones para establecer una base inicial de gobernanza. Cualquiera de las
opciones garantiza que las restricciones de gobernanza se pueden escalar y expandir a medida que se
implementa el plan de adopción y se definen más claramente los requisitos. De forma predeterminada, la base
inicial presupone una posición de aislamiento y control. También se centra más en la organización de los
recursos que en la gobernanza de estos. Este punto de partida inicial se denomina producto viable mínimo para
la gobernanza. El objetivo del producto viable mínimo es reducir las barreras en el establecimiento de una
posición de gobernanza inicial y, a continuación, permitir la rápida maduración de la solución para dar respuesta
a diversos riesgos tangibles.
Ya usa Cloud Adoption Framework

Si ya ha leído la información sobre Cloud Adoption Framework, puede que ya haya implementado un MVP de
gobernanza. La gobernanza es un aspecto fundamental de cualquier modelo operativo. Está presente en todas
las metodologías del ciclo de vida de la adopción de la nube. Por tanto, Cloud Adoption Framework proporciona
una guía que incluye gobernanza en las actividades relacionadas con la implementación del plan de adopción de
la nube. Un ejemplo de esta integración de la gobernanza es el uso de planos técnicos para implementar una o
varias zonas de aterrizaje presentes en la guía de metodología de preparación. Otro ejemplo es una guía para el
escalado horizontal de suscripciones. Si ha seguido alguna de esas recomendaciones, las siguientes secciones
del producto viable mínimo son simplemente una revisión de las decisiones de implementación ya existentes.
Después de una revisión rápida, vaya directamente a Maduración de la solución de gobernanza inicial y
aplicación de controles recomendados.
Establecimiento de una base de gobernanza inicial

A continuación se muestran dos ejemplos diferentes de bases de gobernanza iniciales (también denominados
productos mínimos viables de gobernanza) para aplicar una base sólida para la gobernanza de las
implementaciones nuevas o ya existentes. Elija el producto viable mínimo que mejor se adapte a sus
necesidades empresariales para empezar:
Guía de gobernanza estándar: Una guía útil para la mayoría de las organizaciones basada en el modelo inicial
recomendado de dos suscripciones, diseñada para implementaciones en varias regiones, pero que no abarca
nubes públicas ni soberanas.
Guía de gobernanza para empresas complejas: Una guía para empresas administradas por varias unidades
de negocio de TI independientes o que incluyen nubes públicas y soberanas o gubernamentales.
Pasos siguientes
Una vez que se implementa una base de gobernanza, aplique las recomendaciones adecuadas para mejorar la
solución y protegerse frente a riesgos tangibles.
Mejora de la base de gobernanza inicial
Mejora de una base de gobernanza de la nube
inicial
En este artículo se supone que ha establecido una base de gobernanza de la nube inicial. A medida que se
implementa el plan de adopción de la nube, surgen riesgos tangibles a partir de los enfoques propuestos
mediante los cuales los equipos quieren adoptar la nube. A medida que estos riesgos afloren en las
conversaciones de planeamiento del lanzamiento, use la siguiente cuadrícula para identificar con rapidez
algunos procedimientos recomendados para aprovechar el plan de adopción y evitar que los riesgos se
conviertan en amenazas reales.
Vectores de madurez
Los procedimientos recomendados siguientes se pueden aplicar en cualquier momento a los fundamentos
iniciales de gobernanza a fin de afrontar los riesgos o necesidades que se mencionan en la siguiente tabla.
IMPORTANT
La organización de los recursos puede afectar al modo en que estos procedimientos recomendados se aplican. Es
importante comenzar con las recomendaciones que mejor se adaptan a la base de gobernanza de la nube inicial que
implementó en el paso anterior.
RIESGO O N EC ESIDA D EM P RESA ESTÁ N DA R EM P RESA C O M P L E JA
Información confidencial en la nube Mejora de la materia Mejora de la materia
Aplicaciones críticas en la nube Mejora de la materia Mejora de la materia
Administración de costos de la nube Mejora de la materia Mejora de la materia
Nube múltiple Mejora de la materia Mejora de la materia
Administración de identidades N/D Mejora de la materia

compleja o heredada
Varias capas de gobernanza N/D Mejora de la materia
Pasos siguientes
Además de la aplicación de los procedimientos recomendados, la metodología de gobernanza de Cloud
Adoption Framework se puede personalizar para adaptarse a restricciones empresariales específicas. Después
de seguir las recomendaciones aplicables, evalúe las directivas corporativas para comprender los requisitos de
personalización adicionales.
Evaluación de las directivas corporativas
Guías de gobernanza en la nube
En las guías prácticas de gobernanza de esta sección se explica el enfoque incremental del modelo de
gobernanza de Cloud Adoption Framework, basado en la metodología de gobernanza descrita anteriormente.
Puede establecer un enfoque ágil con respecto a la gobernanza en la nube que crecerá para satisfacer las
necesidades de cualquier escenario de gobernanza en la nube.
Revisar y adoptar los procedimientos recomendados de gobernanza

en la nube
Para comenzar el proceso de adopción de la nube, elija una de las siguientes guías de gobernanza. Cada guía
describe un conjunto de procedimientos recomendados, basados en un conjunto de experiencias ficticias de
clientes. Para los lectores que no están familiarizados con el enfoque incremental del modelo de gobernanza de
Cloud Adoption Framework, se recomienda revisar la introducción de nivel superior a la teoría de la gobernanza
que aparece a continuación, antes de adoptar cualquier procedimiento recomendado.
Guía de gobernanza estándar: Una guía útil para la mayoría de las organizaciones basada en el modelo
recomendado de dos suscripciones, diseñada para implementaciones en varias regiones, pero que no abarca
nubes públicas ni soberanas.
Guía de gobernanza estándar
Guía de gobernanza para empresas complejas: Una guía para empresas administradas por varias unidades
de negocio de TI independientes o que incluyen nubes públicas y soberanas o gubernamentales.
Enfoque incremental para la gobernanza de la nube

Elección de una guía de gobernanza
Las guías muestran cómo implementar un MVP de gobernanza. A partir de ahí, cada guía muestra cómo el
equipo de gobernanza en la nube puede trabajar por delante de los equipos de adopción de la nube, como
asociado, para acelerar los esfuerzos de adopción. El modelo de gobernanza de Cloud Adoption Framework guía
la aplicación de la gobernanza desde la base mediante mejoras y evoluciones posteriores.
Para iniciar un recorrido de gobernanza, elija una de las dos opciones siguientes. Las opciones se basan en
experiencias sintetizadas de los clientes. Los títulos se basan en la complejidad de la empresa para facilitar la
navegación. Es posible que su decisión sea más compleja. En las tablas siguientes se indican las diferencias entre
las dos opciones.
WARNING
Es posible que se requiera un punto de partida de gobernanza más sólido. En tales casos, considere la posibilidad de usar
la zona de aterrizaje de escala empresarial de CAF. Este método se centra en los equipos de adopción que tengan un
objetivo a medio plazo (un máximo de 24 meses) para hospedar más de 1000 recursos (aplicaciones, infraestructura o
datos) en la nube. La zona de aterrizaje de escala empresarial de CAF es la opción habitual para escenarios de gobernanza
complejos en los trabajos de adopción de la nube.
NOTE
Es improbable que alguna de las guías se ajuste en su totalidad a su situación. Elija la guía más adecuada y úsela como
punto de partida. A lo largo de la guía, se proporciona información adicional que le ayudará a personalizar las decisiones
para que cumplan criterios específicos.
Características empresariales
C A RA C T ERÍST IC A O RGA N IZ A C IÓ N ESTÁ N DA R EM P RESA C O M P L E JA
Geografía (país o región geopolítica) Los clientes y el personal residen en Los clientes y el personal residen en
gran medida en una geografía. varias regiones geográficas o requieren
nubes soberanas.
Unidades de negocio afectadas Unidades de negocio que comparten Varias unidades de negocio que no
una infraestructura de TI común comparten ninguna infraestructura de
TI común.
Presupuesto de TI Presupuesto de TI único. Presupuesto asignado a varias

unidades de negocio y en varias
divisas.
Inversiones en TI Las inversiones determinadas por los Las inversiones orientadas a los gastos
gastos de capital se planean de capital se planean anualmente y a
anualmente y, por lo general, cubren menudo incluyen el mantenimiento y
solo el mantenimiento básico. un ciclo de actualización de 3 a 5 años.
Estado actual antes de adoptar la gobernanza de la nube

STAT E EM P RESA ESTÁ N DA R EM P RESA C O M P L E JA
Proveedores de hospedaje de terceros Menos de cinco centros de datos Más de cinco centros de datos
o centro de datos
Redes Sin WAN o 1 – 2 proveedores de WAN Red compleja o WAN global
Identidad Un único bosque, un único dominio. Varios bosques complejos, varios

dominios.
Estado futuro deseado después de la mejora incremental de la gobernanza de la nube

STAT E O RGA N IZ A C IÓ N ESTÁ N DA R EM P RESA C O M P L E JA
Administración de costos: contabilidad Modelo showback. La facturación se Modelo chargeback. La facturación se

en la nube centraliza a través de TI. puede distribuir a través de la
contratación de TI.
Base de referencia de seguridad: datos Datos financieros de la compañía e IP. Varias colecciones de datos financieros
protegidos Datos limitados del cliente. Sin y personales de los clientes. Es posible
requisitos de cumplimiento de que deba tener en cuenta el
terceros. cumplimiento de terceros.
Zona de aterrizaje de escala empresarial de CAF

La zona de aterrizaje de escala empresarial de CAF permite sacar el máximo partido a las funcionalidades de la
plataforma de nube de Azure, al mismo tiempo que respeta los requisitos de seguridad y de gobernanza de una
empresa.
En comparación con los entornos locales tradicionales, Azure permite a los equipos de desarrollo de cargas de
trabajo y a sus patrocinadores empresariales disfrutar de una mayor agilidad de implementación que otras
ofertas de plataforma de nube. A medida que sus esfuerzos de adopción de la nube se amplían para incluir
cargas de trabajo y datos críticos, esta agilidad puede entrar en conflicto con los requisitos de cumplimiento de
directivas y seguridad corporativos que han establecido sus equipos de TI. Esto es especialmente cierto en el
caso de grandes empresas que tienen requisitos normativos y de gobernanza complejos.
El objetivo de la arquitectura de la zona de aterrizaje de escala empresarial de CAF es resolver estos problemas
en una fase anterior del ciclo de vida de la adopción mediante arquitecturas, implementaciones y las
instrucciones necesarias para poder lograr un equilibrio entre los requisitos del equipo de adopción de la nube y
los requisitos del equipo de TI central durante los esfuerzos de la empresa para la adopción de la nube. Para este
enfoque es fundamental el concepto de una arquitectura de servicios compartidos y zonas de aterrizaje bien
administradas.
La zona de aterrizaje de escala empresarial de CAF implementa su propia "nube aislada" dentro de la plataforma
de Azure, que integra los procesos de administración,los requisitos normativos y los procesos de seguridad que
requieren sus directivas de gobernanza. Dentro de este límite virtual, la zona de aterrizaje de escala empresarial
de CAF ofrece modelos de ejemplo para implementar cargas de trabajo y garantizar un cumplimiento constante,
además de proporcionar instrucciones básicas sobre cómo implementar la separación de roles y
responsabilidades de la organización en la nube.
Cualificaciones de una zona de aterrizaje de escala empresarial de CAF
Aunque los equipos más pequeños ya pueden beneficiarse de la arquitectura y las recomendaciones que
proporciona la zona de aterrizaje de escala empresarial de CAF, nuestro objetivo es seguir simplificando las
implementaciones de la zona de aterrizaje de escala empresarial de CAF para que sean más fáciles de usar para
los equipos más pequeños. Actualmente, este enfoque está diseñado para guiar a los equipos de TI centrales en
la administración de entornos de nube de gran tamaño.
El método de la zona de aterrizaje de escala empresarial de CAF se centra en los equipos de adopción que tienen
un objetivo a medio plazo (un máximo de 24 meses) para hospedar más de 1000 recursos (aplicaciones,
infraestructura o recursos de datos) en la nube .
En las organizaciones que cumplen los siguientes criterios, es posible que también desee empezar con la zona
de aterrizaje de escala empresarial de CAF:
Su empresa está sujeta a los requisitos de cumplimiento normativo, que exigen funcionalidades de
supervisión y auditoría centralizadas.
Debe mantener el cumplimiento de las directivas comunes y de la gobernanza, y el control de TI centralizado
de los servicios principales.
Su sector depende de una plataforma compleja que requiere controles complejos y un conocimiento
profundo del dominio para controlar la plataforma. Esto es lo más habitual en grandes empresas del sector
financiero, petrolífero y gasístico, o de fabricación.
Las directivas de gobernanza de TI existentes requieren una paridad más ajustada con las características
existentes, incluso durante la adopción en fases tempranas.
Pasos siguientes
Elija una de estas guías:
Introducción sobre los procedimientos recomendados

Esta guía de gobernanza muestra las experiencias de una empresa ficticia a través de diversas fases de madurez
del proceso de gobernanza. Se basa en experiencias reales de los clientes. Los procedimientos recomendados se
basan en las restricciones y necesidades de la empresa ficticia.
Como punto de inicio rápido, esta información general define un producto viable mínimo (MVP) para la
gobernanza en función de los procedimientos recomendados. También proporciona vínculos a algunas mejoras
de gobernanza que agregan más procedimientos recomendados a medida que emergen nuevos riesgos
técnicos o empresariales.
WARNING
Este MVP es un punto de inicio de la base de referencia, basado en un conjunto de suposiciones. Incluso este conjunto
mínimo de procedimientos recomendados se basa en directivas corporativas controladas por las tolerancias al riesgo y los
riesgos empresariales únicos. Para ver si estas suposiciones se aplican a los usuarios, lea la narrativa más larga que sigue
este artículo.
Procedimientos recomendados sobre gobernanza

Estos procedimientos recomendados sirven como punto de partida para que una organización agregue
barreras de seguridad de gobernanza de forma rápida y coherente a las suscripciones.
En el siguiente diagrama se muestra la jerarquía de MVP de gobernanza para organizar recursos.
Todas las aplicaciones deben implementarse en el área adecuada de la jerarquía de grupos de recursos,
suscripción y grupos de administración. Durante el planeamiento de la implementación, el equipo de
gobernanza en la nube creará los nodos necesarios en la jerarquía para capacitar a los equipos de adopción de
la nube.
1. Un grupo de administración para cada tipo de entorno (por ejemplo, producción, desarrollo y pruebas).
2. Dos suscripciones, una para cargas de trabajo de producción y otra para cargas de trabajo que no sean de
producción.
3. Debe aplicarse una nomenclatura coherente en cada nivel de esta jerarquía de agrupación.
4. Los grupos de recursos se deben implementar de forma que se tenga en cuenta el ciclo de vida de su
contenido: todo lo que se desarrolla conjuntamente, se administra conjuntamente y se retira conjuntamente.
Para más información sobre los procedimientos recomendados de los grupos de recursos, consulte la guía
de decisiones con coherencia de recursos.
5. La selección de región es sumamente importante y se debe tener muy en cuenta para que las redes, la
supervisión y la auditoría estén en vigor para la conmutación por error o la conmutación por recuperación
así como para la confirmación de que las SKU necesarias están disponibles en las regiones preferidas.
A continuación, se indica un ejemplo de este patrón de uso:
Estos patrones proporcionan espacio para el crecimiento sin complicar la jerarquía de forma innecesaria.
NOTE
En caso de que se produzcan cambios en sus requisitos empresariales, los grupos de administración de Azure permiten
reorganizar fácilmente la jerarquía de administración y las asignaciones de los grupos de suscripciones. Sin embargo,
tenga en cuenta que las asignaciones de directivas y roles que se aplican a un grupo de administración las heredan todas
las suscripciones que se encuentren debajo de ese grupo en la jerarquía. Si planea reasignar suscripciones entre los
distintos grupos de administración, asegúrese de que conoce todos los cambios en las asignaciones de directivas y roles
que pueden producirse. Para más información, consulte la documentación de los grupos de administración de Azure.
Gobernanza de recursos
Un conjunto de roles RBAC y directivas globales proporcionará un nivel base de referencia de cumplimiento de
gobernanza. Para satisfacer los requisitos de directivas del equipo de gobernanza de la nube, la implementación
del MVP de gobernanza exige completar las tareas siguientes:
1. Identifique las definiciones de Azure Policy personalizadas necesarias para cumplir los requisitos
empresariales. Esto puede incluir el uso de definiciones integradas y la creación de definiciones
personalizadas. Para mantenerse al día de las definiciones integradas recién publicadas, hay una fuente Atom
de todas las confirmaciones de las directivas integradas, que puede usar para una fuente RSS. Como
alternativa, puede comprobar AzAdvertizer.
2. Cree una definición del plano técnico mediante estas directivas integradas y personalizadas y las
asignaciones de roles que requiere el MVP de gobernanza.
3. Aplique las directivas y la configuración globalmente mediante la asignación de la definición del plano
técnico a todas las suscripciones.
Identificación de las definiciones de directivas
Azure proporciona varias directivas integradas y definiciones de roles que se pueden asignar a cualquier grupo
de administración, suscripción o grupo de recursos. Muchos requisitos habituales de gobernanza pueden
controlarse mediante definiciones integradas. Sin embargo, es probable que también necesite crear definiciones
de directivas personalizadas para administrar sus requisitos específicos.
Las definiciones de las directivas personalizadas se guardan en un grupo de administración o en una suscripción
y se heredan a través de la jerarquía de los grupos de administración. Si la ubicación de guardado de la
definición de una directiva es un grupo de administración, dicha definición está disponible para asignarla a
cualquiera de las suscripciones o grupos de administración secundarios de ese grupo.
Dado que las directivas necesarias para dar soporte al MVP de gobernanza están destinadas a aplicarse a todas
las suscripciones actuales, se implementarán los siguientes requisitos empresariales mediante una combinación
de definiciones integradas y personalizadas creadas en el grupo de administración raíz:
1. Restrinja la lista de asignaciones de roles disponibles al conjunto de roles de Azure integrados que autorice el
equipo de gobernanza de la nube. Esto requiere una definición de directiva personalizada.
2. Exija el uso de las siguientes etiquetas en todos los recursos: Departamento/unidad de facturación,
Geografía, Clasificación de los datos, Importancia crítica, Acuerdo de Nivel de Servicio, Entorno, Arquetipo de
aplicación, Aplicación y Propietario de aplicación. Esto se puede controlar mediante la definición integrada de
Require specified tag .
3. Solicite que la etiqueta Application de los recursos coincida con el nombre del grupo de recursos
pertinente. Esto puede controlarse mediante la definición integrada "Requerir etiqueta y su valor".
Para obtener información acerca de cómo definir directivas personalizadas, consulte la documentación de Azure
Policy. Para obtener una guía y ejemplos de directivas personalizadas, consulte el sitio de ejemplos de Azure
Policy y el repositorio de GitHub asociado.
Asignación de roles de RBAC y de Azure Policy mediante Azure Blueprints
Las directivas de Azure se pueden asignar en el nivel de grupo de recursos, suscripción y grupo de
administración, y se pueden incluir en las definiciones de Azure Blueprints. Aunque los requisitos de directiva
que se definen en este MVP de gobernanza se aplican a todas las suscripciones actuales, es muy probable que
las futuras implementaciones requieran excepciones o directivas alternativas. Como resultado, la asignación de
una directiva mediante grupos de administración. y que todas las suscripciones secundarias heredan estas
asignaciones, puede no ser lo suficientemente flexible para admitir estos escenarios.
Azure Blueprints permite la asignación coherente de roles y directivas, la aplicación de plantillas de Resource
Manager y la implantación de grupos de recursos en varias suscripciones. Al igual que las definiciones de
directivas, las definiciones de planos técnicos se guardan en grupos de administración o suscripciones. Las
definiciones de directivas están disponibles mediante la herencia para todos los elementos secundarios de la
El equipo de gobernanza en la nube ha decidido que el cumplimiento de las asignaciones de RBAC y Azure
Policy necesarias en las suscripciones se implementará a través de Azure Blueprints y los artefactos asociados:
1. En el grupo de administración raíz, cree una definición de plano técnico denominada governance-baseline .
2. Agregue los siguientes artefactos de plano técnico a dicha definición:
a. Asignaciones de directivas para las definiciones de Azure Policy personalizadas definidas en la raíz del
b. Definiciones de grupo de recursos para los grupos necesarios en las suscripciones creadas i regidas
por el MVP de gobernanza.
c. Asignaciones de roles estándar necesarias en las suscripciones que el MVP de gobernanza ha creado o
regido.
3. Publique la definición del plano técnico.
4. Asigne la definición del plano técnico governance-baseline a todas las suscripciones.
Consulte la documentación de Azure Blueprints para obtener más información sobre cómo crear y usar
definiciones del plano técnico.
Red virtual híbrida segura
A menudo, determinadas suscripciones requieren cierto nivel de acceso a los recursos locales. Esto es habitual
en escenarios de migración o escenarios de desarrollo en los que los recursos dependientes residen en el centro
de datos local.
Hasta que la confianza en el entorno de nube está completamente establecida es importante controlar y
supervisar estrechamente no solo todas las comunicaciones que se permiten entre el entorno local y las cargas
de trabajo en la nube, sino también que la red local está protegida contra el potencial acceso no autorizado de
recursos basados en la nube. Para admitir estos escenarios, el MVP de gobernanza agrega las siguientes
prácticas recomendadas:
1. Establezca una red virtual híbrida segura en la nube.
a. La arquitectura de referencia de la VPN establece un patrón y un modelo de implementación para
crear una instancia de VPN Gateway en Azure.
b. Compruebe que los mecanismos locales de seguridad y administración del tráfico traten las redes en
la nube conectadas como recursos que no son de confianza. Los recursos y servicios hospedados en la
nube solo deben tener acceso a los servicios locales autorizados.
c. Valide que el dispositivo de extremo local que se encuentra en el centro de datos local es compatible
con los requisitos de Azure VPN Gateway y está configurado para acceder a la red Internet pública.
d. Tenga en cuenta que los túneles de VPN no deben considerarse circuitos preparados para producción
salvo para las cargas de trabajo más simples. Todo lo que vaya más allá de algunas cargas de trabajo
sencillas que requieran conectividad local debería emplear Azure ExpressRoute.
2. En el grupo de administración raíz, cree una segunda definición del plano técnico llamada
secure-hybrid-vnet .
a. Agregue la plantilla de Resource Manager para la instancia de VPN Gateway como un artefacto para la
definición del plano técnico.
b. Agregue la plantilla de Resource Manager para la red virtual como un artefacto para la definición del
plano técnico.
c. Publique la definición del plano técnico.
3. Asigne la secure-hybrid-vnet definición del plano técnico a todas las suscripciones que requieran
conectividad local. Esta definición se debe asignar además de la definición del plano técnico
governance-baseline .
Una de las mayores preocupaciones que plantea la seguridad de TI y los equipos de gobernanza tradicional, es
el riesgo de que la adopción de la nube en una etapa temprana vaya a poner en peligro los recursos existentes.
El método anterior permite a los equipos de adopción de la nube crear y migrar soluciones híbridas, con un
riesgo reducido para los recursos locales. Cuando la confianza en el entorno en la nube aumente, las posteriores
evoluciones podrán quitar esta solución temporal.
NOTE
La información anterior es solo un punto de partida para crear rápidamente un MVP de gobernanza de línea de base.
Esto es solo el comienzo del recorrido hacia la gobernanza. De todos modos, será necesaria una evolución aún mayor a
medida que la empresa continúe adoptando la nube y asuma más riesgos en las siguientes áreas:
Datos protegidos
Además, los detalles concretos de este MVP se basan en el proceso de ejemplo de una empresa ficticia, que se describe en
los artículos siguientes. Le recomendamos encarecidamente que se familiarice con los otros artículos de esta serie antes
de implementar este procedimiento recomendado.
Mejoras de gobernanza iterativas

Una vez que se ha implementado este MVP, se pueden incorporar capas de gobernanza rápidamente en el
entorno. Estas son algunas formas de mejorar el MVP para satisfacer necesidades empresariales específicas:
Base de referencia de seguridad para datos protegidos
Configuraciones de recursos para aplicaciones críticas
Controles de administración de costos
Controles de evolución en varias nubes
¿Qué proporciona esta guía?

En el MVP, se establecen los procedimientos y las herramientas de la materia de aceleración de la
implementación para aplicar rápidamente la directiva corporativa. En concreto, el MVP usa Azure Blueprints,
Azure Policy y grupos de administración de Azure para aplicar algunas directivas corporativas básicas, tal como
se define en la narrativa de esta empresa ficticia. Dichas directivas corporativas se aplican mediante plantillas de
Resource Manager y directivas de Azure para establecer una base de referencia pequeña para la identidad y la
seguridad.
Mejora incremental de las prácticas de gobernanza

Con el tiempo, este MVP de gobernanza se usará para mejorar las prácticas de gobernanza. A medida que
avanza la adopción, aumenta el riesgo empresarial. Para administrar esos riesgos, se cambiarán varias materias
dentro del modelo de gobernanza de Cloud Adoption Framework. En artículos posteriores de esta serie se
explica la mejora incremental de la directiva corporativa que afecta a la empresa ficticia. Estas mejoras se
producen en tres materias:
La materia de administración de costos, cuando se escala la adopción.
La materia de base de referencia de seguridad, cuando se implementan los datos protegidos.
La materia de coherencia de los recursos, cuando las operaciones de TI empiezan a admitir cargas de trabajo
críticas.
Pasos siguientes
Ahora que se ha familiarizado con el producto viable mínimo de gobernanza y tiene una idea de las mejoras de
gobernanza que se deben seguir, lea la documentación complementaria para obtener más contexto.
Lectura de la narrativa de apoyo
Guía de gobernanza para empresas estándar: La
narrativa detrás de la estrategia de gobernanza
La narrativa siguiente describe un caso de uso de gobernanza durante el recorrido de adopción de la nube de
una empresa estándar. Antes de implementar el recorrido, es importante comprender las suposiciones y los
razonamientos que se reflejan en esta descripción. Solo entonces podrá alinear mejor la estrategia de
gobernanza con el recorrido de su organización.
Antecedentes
La junta directiva comenzó el año con planes para dinamizar el negocio de varias maneras. Están impulsando el
liderazgo para mejorar las experiencias de los clientes y ganar cuota de mercado. También están apostando por
nuevos productos y servicios que posicionarán a la compañía como líder indiscutible del sector. Asimismo,
iniciaron un esfuerzo paralelo para reducir los desperdicios y los costos innecesarios. Aunque pueden ser
intimidantes, las acciones que la junta quiere llevar a cabo y su liderazgo muestran que el propósito de invertir
la mayor cantidad de capital posible está enfocado a conseguir un crecimiento futuro.
En el pasado, el director de sistemas de información de la empresa había sido excluido de estas conversaciones
estratégicas. Dado que la visión de futuro está intrínsecamente vinculada al crecimiento técnico, el
departamento de TI tiene un lugar en la mesa para aportar sus ideas en estos grandes planes y ahora se espera
que ofrezca nuevas formas de crecimiento. De todos modos, el equipo no está preparado para estos cambios y
es probable que tenga problemas con la curva de aprendizaje.
La empresa tiene el siguiente perfil de negocio:
Todas las ventas y operaciones residen en un solo país, lo que supone un bajo porcentaje de clientes
globales.
El negocio funciona como una sola unidad de negocio y cuenta con un presupuesto alineado a las
funciones, entre las que se incluyen los departamentos de ventas, marketing, operaciones y TI.
La empresa considera la mayor parte del departamento de TI como una fuga de capital o un centro de
coste.
Estado actual
A continuación se muestra el estado actual de las operaciones de TI y de la nube de la empresa:
El departamento de TI operaba en dos entornos de infraestructura hospedados. Un entorno contiene
activos de producción. El segundo entorno contiene la opción de recuperación ante desastres y algunos
recursos de desarrollo y prueba. Estos entornos se hospedan en dos proveedores diferentes. El
departamento de TI se refiere a estos dos centros de datos como Prod y DR , respectivamente.
Asimismo, el departamento de TI entró en la nube al migrar todas las cuentas de correo electrónico de
los usuarios finales a Microsoft 365. Esta migración se completó hace seis meses. Desde entonces, solo se
han implementado unos pocos recursos de TI en la nube.
Los equipos de desarrollo de aplicaciones están trabajando en una capacidad de desarrollo y prueba para
aprender más sobre las funcionalidades nativas de la nube.
El equipo de inteligencia empresarial (BI) está experimentando con los macrodatos en la nube y la
protección de datos en nuevas plataformas.
La empresa tiene una directiva definida de manera general que indica que la información personal del
cliente y los datos financieros no se pueden hospedar en la nube, lo que limita las aplicaciones críticas en
las implementaciones actuales.
Las inversiones en TI están controladas en gran medida por el gasto de capital. Además, esas inversiones
se planifican anualmente. En los últimos años, en las inversiones se ha incluido poco más que los
requisitos básicos de mantenimiento.
Estado futuro
Se prevén los siguientes cambios para los próximos años:
El Director de sistemas de información está revisando la directiva sobre información personal y datos
financieros para poder llevar a cabo los futuros objetivos de estado.
Los equipos de desarrollo de aplicaciones y de BI quieren ponerse a producir y lanzar soluciones basadas
en la nube en los próximos 24 meses, según el objetivo para atraer clientes y ofrecer nuevos productos.
Este año, el equipo de TI terminará de retirar las cargas de trabajo de recuperación ante desastres del
centro de datos de DR al migrar 2000 máquinas virtuales a la nube. Se espera que esto produzca un
ahorro de costos estimado de 25 millones USD durante los próximos cinco años.
Debido a esto, la empresa planea cambiar la forma en que realiza las inversiones en TI cambiando la
posición del gasto de capital comprometido, que se ha establecido como un gasto operativo dentro del
departamento de TI. Este cambio proporcionará un mayor control de los costos, y permitirá que el
departamento de TI pueda acelerar otros esfuerzos previstos.
Pasos siguientes
La empresa ha desarrollado una directiva corporativa para dar forma a la implementación de la gobernanza. La
directiva corporativa dirige muchas de las decisiones técnicas.
Revisión de la directiva corporativa inicial
Guía de gobernanza para empresas estándar:
directiva corporativa inicial que está detrás de la
estrategia de gobernanza
La siguiente directiva corporativa define una posición de gobernanza inicial, que es el punto de inicio de esta
guía. En este artículo se definen riesgos incipientes, las declaraciones de directiva iniciales y los procesos
iniciales para aplicar las declaraciones de directiva.
NOTE
La directiva corporativa no es un documento técnico, pero promueve muchas decisiones técnicas. El producto mínimo
viable de gobernanza descrito en la información general deriva, en última instancia, de esta directiva. Antes de
implementar un producto mínimo viable de gobernanza, su organización debe desarrollar una directiva corporativa en
función de sus propios objetivos y riesgos empresariales.

En esta narración, el equipo de gobernanza de la nube consta de dos administradores de sistemas que han
reconocido la necesidad de gobernanza. Durante los próximos meses, tendrán que hacerse cargo de limpiar la
gobernanza de la presencia en la nube de la empresa, lo cual les hará merecedores del sobrenombre de
custodios de la nube. En iteraciones posteriores, es probable que este sobrenombre cambie.
Objetivo
El objetivo inicial es establecer una base para la agilidad de gobernanza. Un producto viable mínimo de
gobernanza eficaz permite al equipo de gobernanza anticiparse a la adopción de la nube e implementar
barreras de seguridad a medida que cambia el plan de adopción.
Riesgos empresariales
La empresa está en una fase temprana de adopción de la nube, experimentando y creando pruebas de concepto.
Ahora los riesgos son relativamente bajos, pero es posible que existan riesgos futuros con un impacto
significativo. Existe poca definición acerca del estado final de las soluciones técnicas que se implementarán en la
nube. Además, la preparación de los empleados de TI para la nube es baja. Una base para la adopción de la nube
ayudará al equipo a aprender y crecer de forma segura.
Perdurabilidad: Existe el riesgo de no permitir el crecimiento, pero también el riesgo de no proporcionar los
mecanismos de protección adecuados contra los riesgos futuros.
Es necesario un enfoque de gobernanza ágil, pero sólido para admitir la visión del consejo para el crecimiento
corporativo y técnico. No implementar este tipo de estrategia ralentizará el crecimiento técnico, lo que
posiblemente ponga en riesgo el crecimiento de la cuota de mercado actual y futura. El impacto de un riesgo
empresarial tal es claramente alto. Sin embargo, se desconoce el rol que TI desempeñará en dichos posibles
estados futuros, lo que hace que el riesgo asociado con los esfuerzos actuales de TI sean relativamente altos.
Dicho esto, en tanto no se alineen planes más concretos, la empresa tiene una alta tolerancia al riesgo.
Este riesgo empresarial puede dividirse de manera táctica en varios riesgos técnicos:
Las directivas corporativas bienintencionadas podrían ralentizar los esfuerzos de transformación o
interrumpir los procesos empresariales esenciales si no se tienen en cuenta dentro de un flujo de aprobación
estructurado.
La aplicación de la gobernanza a los recursos implementados podría ser difícil y costosa.
La gobernanza puede no aplicarse correctamente en una aplicación o una carga de trabajo, lo que crea
brechas de seguridad.
Con tantos equipos que trabajan en la nube, existe un riesgo de incoherencia.
Los costos pueden no alinearse correctamente con las unidades de negocio, los equipos u otras unidades de
administración presupuestarias.
El uso de varias identidades para administrar varias implementaciones puede provocar problemas de
seguridad.
A pesar de las directivas actuales, existe el riesgo de que los datos protegidos puedan implementarse por
error en la nube.
Indicadores de tolerancia
La tolerancia al riesgo actual es alta y el apetito por invertir en la gobernanza de la nube es bajo. Como tales, los
indicadores de tolerancia actúan como sistema de advertencia anticipado para desencadenar una mayor
inversión de tiempo y energía. Si se observan los indicadores siguientes, debe mejorar de forma iterativa la
estrategia de gobernanza.
Administración de costos: La escala de la implementación supera los límites predeterminados de número
de recursos o el costo mensual.
Base de referencia de seguridad : inclusión de datos protegidos en planes de adopción de la nube
definidos.
Coherencia de recursos: inclusión de cualquier aplicación crítica en planes de adopción de la nube
definidos.
Policy statements
Las siguientes declaraciones de la directiva establecen los requisitos necesarios para corregir los riesgos
definidos. Estas directivas definen los requisitos funcionales para el MVP de gobernanza. Cada uno se
representará en la implementación del MVP de gobernanza.
Administración de costos:
Con fines de seguimiento, todos los recursos deben asignarse a un propietario de aplicación dentro de una
de las principales funciones empresariales.
Cuando surjan problemas de costos, se establecerán requisitos de gobernanza adicionales con el equipo de
finanzas.
Base de referencia de seguridad:
Cualquier recurso implementado en la nube debe tener una clasificación de datos aprobada.
Ningún recurso identificado con un nivel de datos protegidos se puede implementar en la nube, hasta que se
aprueben e implementen los suficientes requisitos de seguridad y gobernanza.
Hasta que se puedan validar y gobernar los requisitos mínimos de seguridad de red, los entornos en la nube
se perciben como una red perimetral y deben cumplir con requisitos de conexión similares a otros centros de
datos o redes internas.
Coherencia de recursos:
Dado que no se implementa ninguna carga de trabajo crítica en esta fase, no hay ningún requisito de SLA,
rendimiento o BCDR que se deba gobernar.
Cuando se implementen cargas de trabajo críticas, se establecerán requisitos de gobernanza adicionales con
las operaciones de TI.
Base de referencia de identidad:
todos los recursos que se implementan en la nube deben controlarse mediante identidades y roles
aprobados por las directivas de gobernanza actuales.
todos los grupos de la infraestructura local de Active Directory que tienen privilegios elevados deben
asignarse a un rol RBAC aprobado.
Aceleración de la implementación:
Todos los recursos se deben agrupar y etiquetar en función de las estrategias de agrupación y etiquetado
definidas.
Todos los recursos deben usar un modelo de implementación aprobado.
Una vez que se ha establecido una base de gobernanza para un proveedor de nube, las herramientas de
implementación deben ser compatibles con las herramientas definidas por el equipo de gobernanza.
Procesos
No se ha asignado ningún presupuesto para la supervisión en curso y el cumplimiento de estas directivas de
gobernanza. Por este motivo, el equipo de gobernanza de la nube tiene varias formas improvisadas de
supervisar el cumplimiento de las declaraciones de las directivas.
Educación: el equipo de gobernanza de la nube está invirtiendo tiempo en formar a los equipos de
adopción de la nube en las guías de gobernanza que admiten estas directivas.
Revisiones de la implementación: antes de implementar cualquier recurso, el equipo de gobernanza de
la nube revisará la guía de gobernanza con los equipos de adopción de la nube.
Pasos siguientes
Esta directiva corporativa prepara el equipo de gobernanza de la nube para implementar el producto viable
mínimo de gobernanza, que será la base para la adopción. El siguiente paso es implementar dicho producto
mínimo viable.
Explicación de los procedimientos recomendados
La guía de gobernanza empieza con un conjunto de directivas corporativas iniciales. Estas directivas se usan
para establecer un MVP de gobernanza que refleje los procedimientos recomendados.
En este artículo, se abordarán las estrategias generales necesarias para crear un MVP de gobernanza. En el
centro del MVP de gobernanza se encuentra la materia de aceleración de la implementación. Las herramientas y
los patrones que se aplican en esta etapa darán lugar a las mejoras graduales necesarias para expandir la
gobernanza en el futuro.
Producto viable mínimo de gobernanza (base de gobernanza inicial)

La rápida adopción de las directivas corporativas y de gobernanza es factible gracias a unos pocos principios
sencillos y a las herramientas de gobernanza basadas en la nube. Estas son las tres primeras materias a las que
se debe prestar atención en cualquier proceso de gobernanza. Cada una de las materias se describirá más
detalladamente en este artículo.
Para establecer el punto de partida, en este artículo se tratan las estrategias de alto nivel que hay detrás de las
materias de base de referencia de seguridad, base de referencia de identidad y aceleración de la implementación
que son necesarias para crear un MVP de gobernanza, lo que servirá como base para toda la adopción.
Proceso de implementación
La implementación del MVP de gobernanza tiene dependencias de identidad, seguridad y redes. Una vez
resueltas las dependencias, el equipo de gobernanza de la nube decidirá algunos aspectos de la gobernanza. Las
decisiones del equipo de gobernanza de la nube y de los equipos auxiliares se implementarán a través de un
único paquete de recursos de cumplimiento.
Esta implementación también se puede describir con una simple lista:
1. Solicitar decisiones relacionadas con las dependencias principales: identidad, redes, supervisión y cifrado.
2. Determinar el patrón que se usará durante el cumplimiento de las directivas corporativas.
3. Determinar los patrones de gobernanza apropiados para las materias de coherencia de los recursos,
etiquetado de los recursos y registro e informes.
4. Implementar las herramientas de gobernanza alineadas con el patrón elegido de cumplimiento de directivas
para aplicar las decisiones dependientes y las decisiones de gobernanza.
Decisiones dependientes
Las siguientes decisiones proceden de equipos fuera del equipo de gobernanza de la nube. La implementación
de cada una procederá de esos mismos equipos. No obstante, el equipo de gobernanza de la nube es
responsable de implementar una solución para validar que esas implementaciones se aplican de forma
coherente.
La línea de base de identidad es el punto de partida fundamental para toda gobernanza. Antes de intentar
aplicar la gobernanza, se debe establecer la identidad. A continuación, las soluciones de gobernanza harán
cumplir la estrategia de identidad establecida. En esta guía de gobernanza, el equipo de administración de
identidades implementa el patrón de sincronización de directorios:
Azure Active Directory (Azure AD) proporcionará RBAC, mediante la sincronización de directorios o el
"mismo inicio de sesión" que se implementó durante la migración de la empresa a Microsoft 365. Para una
guía sobre la implementación, consulte Arquitectura de referencia para Integración de Azure AD.
El inquilino de Azure AD también regirá la autenticación y el acceso a los recursos implementados en Azure.
En el producto viable mínimo de gobernanza, el equipo de gobernanza hará cumplir la aplicación del inquilino
replicado mediante herramientas de gobernanza de la suscripción que se describen más adelante en este
artículo. En iteraciones futuras, el equipo de gobernanza podría también aplicar herramientas enriquecidas de
Azure AD para ampliar esta funcionalidad.
Base de referencia de seguridad: Redes
Una red definida por software es un aspecto inicial importante de la línea de base de seguridad. Establecer el
MVP de gobernanza depende de decisiones tempranas por parte del equipo de administración de seguridad
para definir cómo se pueden configurar con seguridad las redes.
Debido a la falta de requisitos, el equipo de seguridad de TI busca protección y ha solicitado un patrón de nube
DMZ. Esto significa que la gobernanza de las implementaciones de Azure mismas será muy ligero.
Las suscripciones de Azure pueden conectarse a un centro de datos existente mediante VPN, pero deben
seguir todas las directivas locales de gobernanza de TI con respecto a la conexión de una red perimetral a los
recursos protegidos. Para obtener instrucciones sobre la implementación con respecto a la conectividad de
VPN, consulte el artículo Red local conectada a Azure mediante VPN Gateway.
Actualmente se están aplazando las decisiones con respecto a subredes, firewalls y enrutamiento a cada
cliente potencial de aplicación y carga de trabajo.
Se requiere un análisis adicional antes de la publicación de datos protegidos o cargas de trabajo críticas.
En este patrón, las redes en la nube solo pueden conectarse a los recursos locales a través de una VPN existente
que sea compatible con Azure. El tráfico a través de esa conexión se tratará como cualquier tráfico procedente
de una red perimetral. Puede que sean necesarias consideraciones adicionales relativas al dispositivo perimetral
local para controlar el tráfico de Azure de forma segura.
El equipo de gobernanza de la nube ha invitado activamente a los miembros de los equipos de redes y de
seguridad de TI a reuniones periódicas para anticiparse a las demandas y los riesgos de las redes.
Base de referencia de seguridad: Cifrado
El cifrado es otra decisión fundamental en la materia de línea de base de seguridad. Dado que la empresa
actualmente todavía no almacena ningún dato protegido en la nube, el equipo de seguridad ha decidido un
patrón menos agresivo para el cifrado. En este momento, se sugiere un patrón nativo de la nube para el cifrado,
pero no es obligatorio para ningún equipo de desarrollo.
No se han establecido requisitos de gobernanza con respecto al uso de cifrado, ya que la actual directiva
corporativa no permite datos críticos ni protegidos en la nube.
Serán necesarios análisis adicionales antes de la publicación de datos protegidos o cargas de trabajo críticas.
La primera decisión que se deberá tomar en cuanto a la aceleración de la implementación es el patrón para el
cumplimiento. En esta narración, el equipo de gobernanza ha decidido implementar el patrón cumplimiento
automatizado.
Azure Security Center estará disponible para que los equipos de seguridad e identidad supervisen los riesgos
de seguridad. También es probable que ambos equipos usen Security Center para identificar los nuevos
riesgos y mejorar la directiva corporativa.
RBAC se requiere en todas las suscripciones para controlar el cumplimiento de autenticación.
Azure Policy se publicará en cada grupo de administración y se aplicará a todas las suscripciones. Sin
embargo, el nivel de las directivas que se aplique será muy limitado en este MVP de gobernanza inicial.
Aunque se usen grupos de administración de Azure, se espera una jerarquía relativamente sencilla.
Azure Blueprints se usará para implementar y actualizar las suscripciones mediante la aplicación de
requisitos de RBAC, plantillas de Resource Manager y Azure Policy en los grupos de administración.
Aplicación de los patrones dependientes

Las siguientes decisiones representan los patrones que se harán cumplir a través de la estrategia de
cumplimiento de directivas anterior:
Línea de base de identidad. Azure Blueprints establecerá los requisitos de RBAC en un nivel de suscripción
para asegurarse de que se configure una identidad coherente para todas las suscripciones.
Línea de base de seguridad: Redes. El equipo de gobernanza de la nube mantiene una plantilla de Resource
Manager para establecer una puerta de enlace de VPN entre Azure y el dispositivo de VPN local. Cuando un
equipo de aplicación requiera una conexión VPN, el equipo de gobernanza de la nube aplicará la plantilla de
Resource Manager de la puerta de enlace mediante Azure Blueprints.
Línea de base de seguridad: cifrado. En este punto, no se requiere ningún cumplimiento de directivas en
esta área. Se revisará durante las iteraciones posteriores.
Aplicación de patrones definidos por gobernanza
El equipo de gobernanza de la nube es responsable de las siguientes decisiones e implementaciones. Muchas
requieren aportaciones de otros equipos, pero es probable que el equipo de gobernanza de la nube sea el
responsable de la decisión y la implementación. En las siguientes secciones se describen las decisiones tomadas
para este caso de uso y los detalles de cada decisión.
Detalles de la suscripción
La decisión sobre qué diseño de suscripción usar determina cómo se estructuran las suscripciones de Azure y
cómo se usarán los grupos de administración de Azure para administrar de forma eficaz el acceso, las directivas
y el cumplimiento de estas suscripciones. En esta narración, el equipo de gobernanza ha establecido
suscripciones para el modelo de diseño de suscripciones con cargas de trabajo de producción y de no
producción.
Es probable que no se necesiten los departamentos, dado el foco actual. Se espera que las implementaciones
puedan restringirse en una sola unidad de facturación. En la fase de adopción, incluso podría no haber un
Contrato Enterprise para centralizar la facturación. Es probable que este nivel de adopción se administre
mediante una única suscripción de pago por uso de Azure.
Independientemente del uso de EA Portal o de la existencia de un Contrato Enterprise, se debe definir y
acordar un modelo de suscripción para minimizar la sobrecarga administrativa más allá de solo la
facturación.
Debe acordarse una convención de nomenclatura común como parte del diseño de suscripción, en función
de los dos puntos anteriores.
Las decisiones relacionadas con la coherencia de los recursos determinan las herramientas, los procesos y el
esfuerzo necesarios para garantizar que los recursos de Azure se implementan, configuran y administran de
forma coherente dentro de una suscripción. En este caso, se ha elegido el patrón coherencia de la
implementación como el principal patrón de coherencia de los recursos.
Los grupos de recursos se crean para las aplicaciones que usan el enfoque del ciclo de vida. Todo lo que se
crea, mantiene y retira de forma conjunta debe residir en un único grupo de recursos. Para más información,
vea la Guía de decisiones de la coherencia de recursos.
Azure Policy se debe aplicar a todas las suscripciones del grupo de administración asociado.
Como parte del proceso de implementación, las plantillas de coherencia de recursos de Azure para el grupo
de recursos deben almacenarse en el control de código fuente.
Cada grupo de recursos se asocia con una aplicación o carga de trabajo específica que se basa en el enfoque
del ciclo de vida que se indicó anteriormente.
Los grupos de administración de Azure permiten actualizar los diseños de gobernanza a medida que madura
la directiva corporativa.
La amplia implementación de Azure Policy podría superar los compromisos temporales del equipo y es
posible que no aporte un gran valor en este momento. Debe crearse una directiva predeterminada simple y
aplicarse a cada grupo de administración para hacer cumplir el pequeño número de instrucciones de la
directiva de gobernanza en la nube. Esta directiva definirá la implementación de los requisitos de gobernanza
específicos. Esas implementaciones pueden aplicarse a todos los recursos implementados.
IMPORTANT
Siempre que un recurso de un grupo deje de compartir el mismo ciclo de vida, se debe trasladar a otro grupo de recurso.
Entre los ejemplos se incluyen bases de datos y componentes de red habituales. Aunque pueden servir a la aplicación que
se está desarrollando, también pueden servir para otros fines y, por tanto, existir en otros grupos de recursos.
Las decisiones sobre el etiquetado de recursos determinan cómo se aplican los metadatos a los recursos de
Azure de una suscripción con fines operativos, administrativos y contables. En este caso, se ha elegido el patrón
Clasificación como modelo predeterminado del etiquetado de recursos.
Los recursos implementados se deben etiquetar con:
Grado de importancia
Contrato de nivel de servicio
Entorno
Estos cuatro valores impulsarán las decisiones de gobernanza, operaciones y seguridad.
Si esta guía de gobernanza se implementa en una unidad de negocio o un equipo dentro de una empresa
más grande, el etiquetado también debe incluir los metadatos para la unidad de facturación.
Registro e informes
Las decisiones sobre registro e informes determinan cómo el almacén registra los datos y cómo se estructuran
las herramientas de supervisión e informe que mantienen al personal de TI informado del estado operativo. En
este ejemplo, se sugiere un patrón nativo en la nube** para el registro y los informes.
Mejora gradual de los procesos de gobernanza

A medida que cambia la gobernanza, algunas declaraciones de las directivas no pueden o no deben controlarse
mediante herramientas automatizadas. Con el tiempo, otras directivas generarán un esfuerzo por parte del
equipo de seguridad de TI y el equipo de administración de identidades local. Para ayudar a administrar los
nuevos riesgos que surjan, el equipo de gobernanza de la nube supervisará los procesos siguientes.
Aceleración de la adopción: El equipo de gobernanza de la nube ha estado revisando los scripts de
implementación de varios equipos. Mantienen un conjunto de scripts que actúan como plantillas de
implementación. Los equipos de adopción de la nube y de DevOps usan esas plantillas para definir más
rápidamente las implementaciones. Cada uno de esos scripts contiene los requisitos necesarios para hacer
cumplir un conjunto de directivas de gobernanza, sin ningún esfuerzo adicional por parte de los ingenieros de
adopción de la nube. Como responsables de estos scripts, el equipo de gobernanza de la nube puede
implementar más rápidamente los cambios de directivas. Como resultado de la protección de los scripts, se
considera al equipo de gobernanza de la nube como una fuente de aceleración de la adopción. Esto genera
coherencia entre las implementaciones, sin forzar la adhesión de manera estricta.
Aprendizaje para ingenieros: El equipo de gobernanza de la nube ofrece sesiones de aprendizaje cada dos
meses y ha creado dos vídeos para ingenieros. Estos materiales ayudan a los ingenieros a aprender
rápidamente la cultura de gobernanza y cómo se hacen las cosas durante las implementaciones. El equipo está
agregando recursos de aprendizaje para mostrar la diferencia entre las implementaciones de producción y las
que no son de producción, de modo que los ingenieros comprendan cómo afectarán las nuevas directivas al
proceso de adopción. Esto genera coherencia entre las implementaciones, sin forzar la adhesión de manera
estricta.
Planeación de la implementación: Antes de implementar cualquier recurso que contenga datos protegidos,
el equipo de gobernanza de la nube revisará los scripts de implementación para validar la alineación con la
gobernanza. Se auditará a los equipos existentes con implementaciones previamente aprobadas, mediante
herramientas de programación.
Auditoría mensual e informes: Cada mes, el equipo de gobernanza realiza una auditoría de todas las
implementaciones de la nube para validar la alineación continua con las directivas. Cuando se detectan
divergencias, se documentan y comparten con los equipos de la adopción de la nube. Cuando el cumplimiento
no pone en riesgo una interrupción del negocio ni una pérdida de datos, las directivas se cumplen
automáticamente. Al final de la auditoría, el equipo de gobernanza de la nube compila un informe para el
equipo de estrategia de la nube y cada equipo de adopción de la nube para comunicar la adhesión general a las
directivas. El informe también se almacena con fines de auditoría y legales.
Revisión trimestral de la directiva: Cada trimestre, el equipo de gobernanza y el equipo de estrategia de la
nube revisan los resultados de la auditoría y sugieren cambios relacionados con las directivas corporativas.
Muchas de las sugerencias son consecuencia de mejoras continuas y de la observación de los patrones de uso.
Los cambios aprobados en la directiva se integran en las herramientas de gobernanza durante los ciclos de
auditoría subsiguientes.
Patrones alternativos
Si cualquiera de los patrones seleccionados en esta guía de gobernanza no se adapta a los requisitos del lector,
existen otras alternativas para cada patrón:
Patrones de cifrado
Patrones de identidad
Patrones de registro e informes
Patrones de cumplimiento de directivas
Patrones de coherencia de recursos
Patrones de etiquetado de recursos
Patrones de redes definidos por software
Patrones de diseño de suscripciones
Pasos siguientes
Una vez que se implemente esta guía, cada equipo de adopción de la nube puede continuar con una base sólida
de gobernanza. Al mismo tiempo, el equipo de gobernanza de la nube trabajará para actualizar continuamente
las directivas corporativas y las materias de gobernanza.
Los dos equipos usarán los indicadores de tolerancia para identificar el próximo conjunto de mejoras necesario
para seguir impulsando la adopción de la nube. Para la empresa ficticia de esta guía, el siguiente paso es
mejorar la base de referencia de seguridad para respaldar la migración de datos protegidos a la nube.
Mejora de la materia de base de referencia de la
seguridad
En este artículo se continúa con la descripción de la estrategia de gobernanza y se agregan los controles de
seguridad que respaldan el traslado de datos protegidos a la nube.
Continuación de la historia
El departamento de TI y la dirección de la empresa están satisfechos con los resultados de la experimentación
inicial de los equipos de TI, desarrollo de aplicaciones y BI. Para obtener valores empresariales tangibles de estos
experimentos, los equipos deben poder integrar datos protegidos en soluciones. Esta integración desencadena
cambios en la directiva corporativa. También requiere una mejora gradual de las implementaciones de la
gobernanza de la nube antes de que los datos protegidos se puedan colocar en la nube.
Cambios en el equipo de gobernanza de la nube
Dado el efecto del cambio de narración y el respaldo proporcionados hasta ahora, el equipo de gobernanza de
la nube se percibe de forma diferente. Los dos administradores del sistema que iniciaron el equipo se ven ahora
como arquitectos con experiencia en la nube. A medida que se desarrolla la narración, la percepción que se tiene
de ellos variará, pasarán de ser administradores de la nube a tener más bien un rol de protectores de la nube.
Aunque la diferencia es sutil, puede suponer una distinción importante a la hora de crear una cultura de TI
centrada en la gobernanza. Los administradores de la nube limpian el desorden realizado por los innovadores
arquitectos de la nube. La fricción entre los dos roles es natural ya que sus objetivos son opuestos. Por otro lado,
un protector de la nube ayuda a mantener la nube segura, con el fin de que otros arquitectos de la nube puedan
moverse más rápidamente, ya que hay menos desorden. Los protectores de la nube participan en la creación de
plantillas que aceleran la implementación de la nube y su adopción. Por consiguiente, son los impulsores de la
innovación, además de los defensores de las cinco materias de la gobernanza en la nube.
Cambios en el estado actual
Al principio de esta narración, los equipos de desarrollo de aplicaciones aún estaban trabajando en una
capacidad de desarrollo y prueba, y el equipo de BI aún estaba en la fase experimental. TI manejaba dos
entornos de infraestructura hospedados, denominados Prod y DR .
Desde entonces, han cambiado algunas cosas que afectarán a la gobernanza:
El equipo de desarrollo de aplicaciones ha implementado una canalización de CI/CD para implementar una
aplicación nativa en la nube con una experiencia de usuario mejorada. Dado que la aplicación aún no
interactúa con datos protegidos, no está lista para producción.
El equipo de inteligencia empresarial de TI mantiene activamente los datos en la nube de terceros, inventario
y logística. Estos datos se usan para impulsar nuevas predicciones que pueden dar forma a procesos
empresariales. Esas predicciones y conclusiones no son útiles hasta que los datos del cliente y los financieros
se pueden integrar en la plataforma de datos.
El equipo de TI hace progresos en los planes del CIO y del director financiero para retirar el centro de datos
de DR. Se han retirado o migrado más de 1000 de los 2000 recursos del centro de datos de DR.
Las directivas definidas de forma flexible para la información personal y datos financieros se han
modernizado. Las nuevas directivas corporativas están supeditadas a la implementación de directivas de
seguridad y de gobernanza relacionadas. Así que los equipos siguen estancados.
Mejora gradual del estado futuro
Los primeros experimentos de los equipos de desarrollo de aplicaciones e inteligencia empresarial han
mostrado mejoras potenciales en las experiencias de los clientes y las decisiones basadas en datos. Ambos
equipos quieren expandir la adopción de la nube en los próximos 18 meses mediante la implementación de
estas soluciones en producción.
Durante los seis meses restantes, el equipo de gobernanza de la nube implementará requisitos de seguridad y
gobernanza para permitir que los equipos de adopción de la nube puedan migrar los datos protegidos de esos
centros de datos.
Los cambios de los estados actual y futuro exponen nuevos riesgos que requieren nuevas instrucciones de
directiva.
Cambios en riesgos tangibles

Vulneración de datos: Cuando se adopta una nueva plataforma de datos, hay un aumento inherente de las
responsabilidades relacionadas con las posibles vulneraciones de datos. Los técnicos que adoptan las
tecnologías de la nube tienen una mayor responsabilidad a la hora de implementar soluciones que reduzcan
este riesgo. Para asegurarse de que los técnicos cumplen con estas responsabilidades se debe implementar una
estrategia eficaz de seguridad y gobernanza.
Este riesgo empresarial puede ampliarse a algunos riesgos técnicos:
Se podrían implementar aplicaciones críticas o datos protegidos de forma no intencionada.
Los datos protegidos podrían quedar expuestos durante el almacenamiento si las decisiones relativas al
cifrado no son apropiadas.
Usuarios no autorizados podrían tener acceso a datos protegidos.
Podrían producirse intrusiones externas en el acceso a datos protegidos.
Las intrusiones externas o los ataques por denegación de servicio podrían provocar una interrupción del
negocio.
Los cambios de organización o empleo podrían permitir el acceso no autorizado a los datos protegidos.
Nuevas vulnerabilidades podrían crear nuevas oportunidades de intrusión o acceso.
Procesos incoherentes de implementación podrían dar lugar a brechas de seguridad y estas, a su vez, a
pérdidas de datos o interrupciones.
El desfase de configuración o la falta revisiones podrían dar lugar a brechas de seguridad y estas, a su vez, a
Pérdida de datos: también hay un riesgo inherente de pérdida de datos en la nueva plataforma. La estrategia
de seguridad y gobernanza también debe tener en cuenta los siguientes escenarios, ya que en ellos se pueden
producir pérdidas de datos:
Se ha perdido o eliminado un recurso crítico.
Existe un recurso crítico, pero los datos se han perdido debido a una eliminación accidental.
Existe un recurso crítico, pero los datos se han perdido a causa de una administración malintencionada.
Mejora gradual de las instrucciones de las directivas

Los siguientes cambios en la directiva le ayudarán a corregir los nuevos riesgos y le guiarán en la
implementación. La lista parece larga, pero puede que la adopción de estas directivas sea más fácil de lo que
piensa.
Todos los recursos implementados deben categorizarse por importancia y clasificación de datos. El equipo de
gobernanza de la nube y el propietario de la aplicación deben revisar estas clasificaciones antes de la
Las aplicaciones que almacenan datos protegidos, o acceden a ellos, se deben administrar de manera
diferente a las demás. Como mínimo, deben segmentarse para evitar el acceso no intencionado de los datos
protegidos.
todos los datos protegidos deben estar cifrados cuando están en reposo. Este cifrado es el predeterminado
para todas las cuentas de Azure Storage. Pero es posible que se necesiten estrategias de cifrado adicionales,
lo que incluye el cifrado de los datos de la cuenta de almacenamiento, el cifrado de máquinas virtuales y el
cifrado en el nivel de base de datos cuando se usa SQL en una máquina virtual (cifrado de datos
transparente y cifrado de columnas).
Los datos críticos se pueden eliminar accidentalmente. Para controlar este riesgo y restaurar los datos desde
antes del punto de eliminación es preciso desarrollar una estrategia de copia de seguridad de datos. Un
administrador malintencionado puede eliminar no solo los datos críticos, sino también sus copias de
seguridad. Para controlar este escenario, los datos de las copias de seguridad se deben eliminar de forma
temporal, de modo que dicha eliminación se pueda revertir. Azure Backup puede ayudar en ambos
escenarios.
Los permisos elevados en los segmentos que contengan datos protegidos deben ser una excepción. Estas
excepciones se registrarán con el equipo de gobernanza de la nube y se auditarán periódicamente.
Las subredes que contengan datos protegidos deben aislarse de las otras. El tráfico de red entre subredes de
datos protegidos se auditará periódicamente.
No se debería poder acceder directamente a ninguna subred que contenga datos protegidos a través de
Internet o entre centros de datos. El acceso a esas subredes debe enrutarse a través de subredes intermedias.
Todo acceso a esas subredes debe realizarse a través de una solución de firewall que pueda realizar
funciones de análisis y bloqueo de paquetes.
Las herramientas de gobernanza deben auditar y aplicar los requisitos de configuración de red definidos por
el equipo de administración de seguridad.
Las herramientas de gobernanza deben limitar la implementación de máquinas virtuales a solo las imágenes
aprobadas.
El proceso de gobernanza debe validar que la copia de seguridad, la recuperación y el cumplimiento de los
Acuerdos de Nivel de Servicios se implementen correctamente para aplicaciones críticas y datos protegidos.
Siempre que sea posible, la administración de configuración de nodos debe aplicar los requisitos de directiva
a la configuración de cualquier sistema operativo invitado.
Las herramientas de gobernanza deben exigir que las actualizaciones automáticas estén habilitadas en todos
los recursos implementados. Las infracciones deben revisarse con los equipos de administración de
operaciones y corregirse de acuerdo con las directivas de operaciones. Los recursos que no se actualicen
automáticamente deben incluirse en procesos que sean propiedad del departamento de operaciones de TI.
La creación de nuevas suscripciones o grupos de administración para aplicaciones críticas o datos protegidos
requerirá una revisión del equipo de gobernanza de la nube para tener la certeza de que se ha asignado el
plano técnico correcto.
Un modelo de acceso con privilegios mínimos se aplicará a cualquier grupo de administración o suscripción
que contenga aplicaciones críticas o datos protegidos.
El equipo de seguridad debe revisar periódicamente las tendencias y vulnerabilidades que podrían afectar a
implementaciones en la nube para proporcionar actualizaciones a las herramientas de administración de
seguridad utilizadas en la nube.
El equipo de gobernanza de la nube debe aprobar las herramientas de implementación para garantizar la
gobernanza en curso de los recursos implementados.
Los scripts de implementación deben conservarse en un repositorio central accesible para el equipo de
gobernanza de la nube, y que así se puedan revisar y se realicen auditorías periódicas.
Los procesos de gobernanza deben incluir auditorías en el punto de implementación y en ciclos regulares
para garantizar la coherencia entre todos los recursos.
La implementación de las aplicaciones que requieren autenticación de cliente debe usar un proveedor de
identidades aprobado que sea compatible con el proveedor de identidades principal de los usuarios internos.
Los procesos de gobernanza en la nube deben incluir revisiones trimestrales con equipos de administración
de identidades. Estas revisiones pueden ayudar a identificar actores malintencionados o patrones de uso que
deben evitarse en la configuración de recursos en la nube.

El diseño de un producto viable mínimo de gobernanza cambiará para incluir nuevas directivas de Azure y una
implementación de Azure Cost Management + Facturación. Juntos, estos dos cambios de diseño cumplirán con
las nuevas declaraciones de directiva corporativa.
Los equipos de redes y seguridad de TI definirán los requisitos de la red. El equipo de gobernanza de la nube
admitirá la conversación.
Los equipos de identidad y seguridad de TI definirán los requisitos de identidad y realizarán los cambios
necesarios en la implementación local de Active Directory. El equipo de gobernanza de la nube revisará los
cambios.
Cree un repositorio en Azure DevOps para almacenar y edite todas las plantillas de Azure Resource Manager
pertinentes y configuraciones con script.
Implementación del almacén de Azure Recovery Services:
Defina e implemente un almacén de Azure Recovery Services para los procesos de copia de seguridad
y recuperación.
Cree una plantilla de Resource Manager para crear un almacén en cada suscripción.
Implementación de Azure Security Center:
Configure Azure Security Center para cualquier grupo de administración que contenga clasificaciones
de datos protegidos.
Active de forma predeterminada el aprovisionamiento automático para garantizar el cumplimiento de
la aplicación de revisiones.
Establezca configuraciones de seguridad del sistema operativo. El equipo de seguridad de TI definirá la
configuración.
Admita el equipo de seguridad de TI en el uso inicial de Security Center. Realice la transición del uso de
Security Center al equipo de seguridad de TI, pero conserve el acceso con el fin de mejorar
continuamente la gobernanza.
Cree una plantilla de Resource Manager que refleje los cambios necesarios para la configuración de
Security Center dentro de una suscripción.
Actualice las directivas de Azure para todas las suscripciones:
Audite y aplique un grado de importancia a los datos y su clasificación en todos los grupos de
administración y suscripciones, con el fin de identificar las suscripciones con clasificaciones de datos
protegidos.
Audite y exija el uso de imágenes aprobadas únicamente.
Actualice las directivas de Azure para todas las suscripciones que contengan clasificaciones de datos
protegidos:
Audite y exija el uso de roles estándar de Azure únicamente.
Audite y exija el cifrado para todas las cuentas de almacenamiento y los archivos en reposo en nodos
individuales.
Audite y exija la aplicación de un NSG a todos los NIC y subredes. Los equipos de redes y seguridad
de TI definirán los NSG.
Audite y exija el uso de la subred de la red aprobada y de la red virtual por interfaz de red.
Audite y exija que se aplique la limitación de las tablas de enrutamiento que defina el usuario.
Aplique las directivas integradas para la configuración de invitado de la manera siguiente:
Confirme que los servidores web de Windows usan protocolos de comunicación segura.
Confirme que la configuración de seguridad de contraseñas es correcta en máquinas de Linux y
Windows.
Audite y exija que existan almacenes de Azure Recovery Services en la suscripción.
Configuración del firewall:
Identifique una configuración de Azure Firewall que cumpla los requisitos de seguridad necesarios.
Como alternativa, puede identificar un dispositivo de terceros que también sea compatible con Azure.
Azure Security Benchmark proporciona información adicional sobre la estrategia de seguridad de red
y las configuraciones de firewall que respaldan su estrategia de seguridad.
Cree una plantilla de Resource Manager para implementar el firewall con las configuraciones
necesarias.
Azure Blueprints:
Cree un nuevo plano técnico denominado protected-data .
Agregue las plantillas de Azure Firewall, las plantillas de Azure Security Center y las plantillas del
almacén de Azure Recovery Services al plano técnico.
Agregue las nuevas directivas para suscripciones de datos protegidos.
Publique el plano técnico en cualquier grupo de administración que planee actualmente el hospedaje
Aplique el nuevo plano técnico a cada una de las suscripciones afectadas y a los planos técnicos
existentes.
Conclusión
La adición de los procesos anteriores y los cambios realizados en el producto viable mínimo de gobernanza
ayudarán a corregir muchos de los riesgos asociados con controles de seguridad. Juntos, agregan herramientas
de supervisión de red, así como la identidad y la seguridad necesarias para proteger los datos.
Pasos siguientes
A medida que avanza la adopción de la nube y aporta valores empresariales adicionales, también cambian los
riesgos y necesidades de gobernanza de la nube. En cuanto a la empresa ficticia de esta guía, el paso siguiente
es dar servicio a las cargas de trabajo críticas. En este punto, se necesitan controles de coherencia de los
recursos.
En este artículo, la narrativa avanza agregando controles de coherencia de los recursos para dar servicio a
aplicaciones críticas.
Las nuevas experiencias de clientes, las nuevas herramientas de predicción y la infraestructura migrada siguen
avanzando. La empresa ahora está lista para comenzar a usar esos recursos en un entorno de producción.
En la fase anterior de esta narrativa, los equipos de BI y desarrollo de aplicaciones estaban prácticamente listos
para integrar los datos financieros y de clientes en cargas de trabajo de producción. El equipo de TI estaba a
punto de retirar el centro de datos de recuperación ante desastres.
TI ha retirado el 100 % del centro de datos de recuperación ante desastres, antes de lo previsto. Durante el
proceso, se identificó un conjunto de recursos del centro de datos de producción como candidatos para la
migración a la nube.
Los equipos de desarrollo de aplicaciones ya están preparados para el tráfico de producción.
El equipo de BI está listo para devolver información y predicciones de fuentes a los sistemas de operaciones
del centro de datos de producción.
Antes de usar las implementaciones de Azure en los procesos empresariales de producción, las operaciones en
la nube deben madurar. En conjunto, se requieren cambios adicionales de la gobernanza para asegurarse de que
los recursos pueden funcionar correctamente.
Los cambios de los estados actual y futuro exponen nuevos riesgos que requerirán nuevas declaraciones de
directiva.

Interrupción del negocio: existe un riesgo inherente de que cualquier nueva plataforma cause interrupciones
en los procesos de negocio críticos. El equipo de operaciones de TI y los equipos que ejecutan tareas en diversas
adopciones de la nube tienen relativamente poca experiencia con las operaciones de la nube. Como esto
aumenta el riesgo de interrupción, hay que tomar medidas al respecto para solucionarlo y gobernarlo.
1. Intrusiones externas o ataques por denegación de servicio podrían provocar una interrupción del negocio.
2. Los recursos críticos podrían no detectarse adecuadamente y, por lo tanto, podrían no utilizarse
correctamente.
3. Los recursos desconocidos o mal etiquetados podrían no ser compatibles con los procesos de administración
operativa existentes.
4. La configuración de los recursos implementados podría no satisfacer las expectativas de rendimiento.
5. Es posible que el registro no se haya anotado y centralizado correctamente para permitir la solución de
problemas de rendimiento.
6. Las directivas de recuperación podrían dar error o tardar más de lo esperado.
7. Unos procesos de implementación incoherentes podrían dar lugar a brechas de seguridad y estas, a su vez, a
8. El desfase de configuración o la falta de revisiones podrían dar lugar a brechas de seguridad y estas, a su vez,
a pérdidas de datos o interrupciones.
9. La configuración podría no aplicar los requisitos de los Acuerdos de Nivel de Servicio definidos o los
requisitos de recuperación confirmados.
10. Los sistemas operativos o aplicaciones implementados podrían no cumplir con los requisitos de protección.
11. Con tantos equipos que trabajan en la nube, existe un riesgo de incoherencia.
Mejora gradual de las declaraciones de las directivas

implementación. La lista parece larga, pero la adopción de estas directivas puede ser más fácil de lo que parece.
1. Todos los recursos implementados deben categorizarse por importancia y clasificación de datos. El equipo de
gobernanza de la nube y el propietario de la aplicación deben revisar las clasificaciones antes de la
2. Las subredes que contienen aplicaciones críticas deben estar protegidas por una solución de firewall capaz
de detectar intrusiones y responder a los ataques.
3. Las herramientas de gobernanza deben auditar y aplicar los requisitos de configuración de red definidos por
4. Las herramientas de gobernanza deben validar que todos los recursos relacionados con aplicaciones críticas
o datos protegidos se incluyen en la supervisión de la disminución y optimización de recursos.
5. Las herramientas de gobernanza deben validar que se recopila el nivel adecuado de datos de registro para
todas las aplicaciones críticas o datos protegidos.
6. El proceso de gobernanza debe validar que la copia de seguridad, la recuperación y el cumplimiento de los
7. Las herramientas de gobernanza deben limitar la implementación de máquina virtual a solo las imágenes
aprobadas.
8. Las herramientas de gobernanza debe exigir que las actualizaciones automáticas se impidan en todos los
recursos implementados que admitan aplicaciones críticas. Las infracciones deben revisarse con los equipos
de administración de operaciones y corregirse de acuerdo con las directivas de operaciones. Los recursos
que no se actualicen automáticamente deben incluirse en procesos que sean propiedad de operaciones de TI.
9. Las herramientas de gobernanza deben validar el etiquetado relacionado con el costo, la importancia, el
Acuerdo de Nivel de Servicio, la aplicación y la clasificación de los datos. Todos los valores deben alinearse
con valores predefinidos, administrados por el equipo de gobernanza.
10. Los procesos de gobernanza deben incluir auditorías en el punto de implementación y en ciclos regulares
11. El equipo de seguridad debe revisar periódicamente las tendencias y vulnerabilidades que podrían afectar a
implementaciones en la nube para proporcionar actualizaciones a las herramientas de administración de
seguridad utilizadas en la nube.
12. Antes de su publicación en producción, todas las aplicaciones críticas y los datos protegidos deben agregarse
a la solución de supervisión operativa designada. Los recursos que no pueden detectarse por las
herramientas de operaciones de TI elegidas no pueden liberarse para su uso en producción. Cualquier
cambio requerido para hacer que los recursos sean detectables debe aplicarse a los procesos de
implementación correspondientes para garantizar que los recursos sean detectables en futuras
implementaciones.
13. Tras la detección, los equipos de administración operativa ajustarán el tamaño de los recursos, a fin de
garantizar que estos cumplan los requisitos de rendimiento.
14. El equipo de gobernanza de la nube debe aprobar las herramientas de implementación para garantizar la
15. Los scripts de implementación deben conservarse en un repositorio central accesible para el equipo de
gobernanza de la nube, y que así se puedan revisar y se realicen auditorías periódicas.
16. Los procesos de revisión de gobernanza deben validar que los recursos implementados se configuren
correctamente de acuerdo con el Acuerdo de Nivel de Servicio y los requisitos de recuperación.

En esta sección del artículo se cambiará el diseño del producto viable mínimo de gobernanza para incluir
nuevas directivas de Azure y una implementación de Azure Cost Management + Billing. Juntos, estos dos
cambios de diseño cumplirán con las nuevas declaraciones de directiva corporativa.
1. El equipo de operaciones de la nube definirá las herramientas de supervisión operativa y las herramientas de
corrección automáticas. El equipo de gobernanza de la nube apoyará estos procesos de detección. En este
caso de uso, el equipo de operaciones de la nube eligió Azure Monitor como herramienta principal para la
supervisión de aplicaciones críticas.
2. Cree un repositorio en Azure DevOps para almacenar y editar todas las plantillas de Resource Manager
pertinentes y las configuraciones con script.
3. Implementación del almacén de Azure Recovery Services:
a. Defina e implemente un almacén de Azure Recovery Services para los procesos de copia de seguridad
y recuperación.
b. Cree una plantilla de Resource Manager para crear un almacén en cada suscripción.
4. Actualice Azure Policy en todas las suscripciones:
a. Audite y exija la clasificación de datos y la importancia en todas las suscripciones, para identificar
aquellas que tienen recursos críticos.
b. Audite y exija el uso de imágenes aprobadas únicamente.
5. Implementación de Azure Monitor:
a. Una vez que identifique una carga de trabajo crítica, cree un área de trabajo de Azure Monitor Log
Analytics.
b. Durante las pruebas de implementación, el equipo de operaciones de la nube implementa la detección
de pruebas y los agentes necesarios.
6. Actualice Azure Policy en todas las suscripciones que contengan aplicaciones críticas.
a. Audite y exija la aplicación de un NSG a todos los NIC y subredes. Los equipos de redes y seguridad
de TI definen los NSG.
b. Audite y exija el uso de redes virtuales y subredes de red aprobadas para cada interfaz de red.
c. Audite y exija que se aplique la limitación de las tablas de enrutamiento que defina el usuario.
d. Audite y exija la implementación de agentes de Azure Monitor para todas las máquinas virtuales.
e. Audite y exija que existan almacenes de Azure Recovery Services en la suscripción.
7. Configuración del firewall:
a. Identifique una configuración de Azure Firewall que cumpla los requisitos de seguridad. También
puede identificar un dispositivo de terceros que sea compatible con Azure.
b. Cree una plantilla de Resource Manager para implementar el firewall con las configuraciones
necesarias.
8. Plano técnico de Azure:
a. Cree un plano técnico de Azure denominado protected-data .
b. Agregue el firewall y las plantillas del almacén de Azure Recovery Services al plano técnico.
c. Agregue las nuevas directivas para suscripciones de datos protegidos.
d. Publique el plano técnico en cualquier grupo de administración que vaya a hospedar aplicaciones
críticas.
e. Aplique el nuevo plano técnico a cada suscripción afectada, además de los planos técnicos existentes.
Conclusión
Estos procesos y cambios adicionales aplicados al producto viable mínimo de gobernanza ayudan a corregir
muchos de los riesgos asociados con la regulación de recursos. Juntos, agregan los controles de recuperación,
tamaño y supervisión que permiten las operaciones basadas en la nube.
Pasos siguientes
riesgos y necesidades de gobernanza de la nube. Para la compañía ficticia de esta guía, el siguiente
desencadenador se da cuando la escala de implementación supera los 100 recursos en la nube o el gasto
mensual supera los 1 000 USD al mes. En este punto, el equipo de gobernanza de la nube agrega controles de
administración de costos.
Mejora de la materia de administración de costos
En este artículo se detalla la incorporación de controles de costos al producto viable mínimo de gobernanza.
La adopción ha aumentado superando el indicador de tolerancia de costos que se definió en el producto
mínimo viable de gobernanza. Esto es algo bueno, ya que se corresponde con las migraciones desde el centro
de datos de recuperación ante desastres. Los aumentos en el gasto ahora justifican una inversión de tiempo por
parte del equipo de gobernanza de la nube.
En una fase anterior de esta narración, TI había retirado el 100 % del centro de datos de recuperación ante
desastres. Los equipos de desarrollo de aplicaciones y de inteligencia empresarial estaban preparados para el
tráfico de producción.
El equipo de migración ha empezado a migrar las máquinas virtuales fuera del centro de datos de
producción.
Los equipos de desarrollo de aplicaciones están insertando activamente aplicaciones de producción en la
nube a través de canalizaciones de CI/CD. Esas aplicaciones se pueden escalar de forma reactiva según las
demandas de los usuarios.
El equipo de inteligencia empresarial del departamento de TI ha entregado varias herramientas de análisis
predictivo en la nube. Los volúmenes de datos agregados en la nube siguen creciendo.
Todo este crecimiento es compatible con los resultados empresariales comprometidos. Los costos han
comenzado a inflarse. Los presupuestos proyectados están creciendo más rápido de lo esperado. El
departamento de dirección financiera necesita enfoques mejorados para administrar los costos.
La supervisión de costos y los informes se agregarán a la solución en la nube. TI aún actúa como un centro de
compensación de costos. Esto significa que los pagos para los servicios en la nube proceden aún de la
contratación de TI. Los informes deben vincular los gastos operativos directos a las funciones que consumen los
costos de la nube. A este modelo se le conoce como modelo de simulación de la repercusión de los costos en
relación con la contabilidad de la nube.
directiva.

Control del presupuesto: Existe un riesgo inherente de que las capacidades de autoservicio generen costos
excesivos e inesperados en la nueva plataforma. Los procesos de gobernanza para la supervisión de los costos y
la mitigación de los riesgos de costos continuos deben estar implementados para asegurar la alineación
continua con el presupuesto planeado.
Los costos reales podrían superar los planeados.
Las condiciones empresariales cambian. Cuando lo hacen, habrá casos en que una función empresarial
necesite consumir más servicios en la nube de lo esperado, provocando anomalías en el gasto. Existe el
riesgo de que estos gastos adicionales se consideren como un uso por encima del límite, en lugar de
considerar la posibilidad de realizar un ajuste en el plan.
Los sistemas se podrían sobreaprovisionar, lo que daría lugar a un exceso en los gastos.

implementación.
El equipo de gobernanza debe supervisar semanalmente todos los costos de la nube comparándolos con los
que están en el plan. Los informes sobre las desviaciones entre los costos en la nube y los del plan deben
compartirse con la dirección financiera y de TI mensualmente. Todos los costos de la nube y las
actualizaciones del plan se deben revisar mensualmente con los departamentos de finanzas y de TI.
Todos los costos deben asignarse a una función empresarial con fines de rendición de cuentas.
Se deben supervisar continuamente los recursos en la nube para detectar las oportunidades de optimización.
Las herramientas de gobernanza de la nube deben limitar las opciones de tamaño de los recursos a una lista
de configuraciones aprobadas. Las herramientas deben asegurarse de que todos los recursos sean
detectables y estén controlados por la solución de supervisión de costos.
Durante la planeación de la implementación, se deben documentar todos los recursos en la nube necesarios
asociados con el hospedaje de las cargas de trabajo de producción. Esta documentación ayudará a ajustar los
presupuestos y preparar las automatizaciones adicionales para impedir el uso de opciones más costosas.
Durante este proceso, debe prestarse atención a las diferentes herramientas de descuento que ofrece el
proveedor de servicios en la nube, como instancias reservadas o reducciones en los costos de la licencia.
Todos los propietarios de aplicaciones deben asistir a prácticas de aprendizaje para optimizar las cargas de
trabajo a fin de controlar mejor los costos de la nube.
Mejora incremental de procedimientos recomendados

1. Implemente Azure Cost Management + Billing.
a. Establezca el ámbito adecuado de acceso para alinearlo con el patrón de suscripciones y la materia
sobre la coherencia de los recursos. Asumiendo la alineación con el MVP de gobernanza definido en
artículos anteriores, esto requiere acceso al ámbito de la cuenta de inscripción para que el equipo
de gobernanza de la nube ejecute el informe general. Los equipos adicionales fuera de la gobernanza
pueden requerir acceso al ámbito del grupo de recursos .
b. Establezca un presupuesto en Azure Cost Management + Billing.
c. Revise las recomendaciones iniciales y actúe sobre ellas. Disponga un proceso periódico que admita
informes.
d. Configure y ejecute los informes de Azure Cost Management + Billing, en el inicio y de manera
periódica.
2. Actualización de Azure Policy
a. Audite los valores de etiquetado, grupo de administración, suscripción y grupo de recursos para
identificar cualquier desviación.
b. Establezca las opciones de tamaño de SKU para limitar las implementaciones a las SKU que aparecen
en la documentación de la planeación de implementación.
Conclusión
La adición de estos procesos y los cambios realizados en el producto viable mínimo de gobernanza ayudan a
corregir muchos de los riesgos asociados con la gobernanza de los costos. Juntos, crean la visibilidad, la
responsabilidad y la optimización necesarias para controlar los costos.
Pasos siguientes
riesgos y necesidades de gobernanza de la nube. Para la empresa ficticia de esta guía, el siguiente paso es usar
esta inversión de gobernanza para administrar varias nubes.
Evolución en varias nubes
Mejora de la nube múltiple
En este artículo se desarrolla la narrativa con la adición de controles para la adopción de varias nubes.
Microsoft reconoce que los clientes pueden adoptar varias nubes para propósitos específicos. El cliente ficticio
de esta guía no es una excepción. Paralelamente al recorrido de adopción de Azure, el éxito del negocio ha
llevado a la adquisición de una empresa pequeña, pero complementaria. Ese negocio ejecuta todas sus
operaciones de TI en un proveedor de servicios en la nube diferente.
En este artículo se describen cómo cambian las cosas cuando se integra la nueva organización. A efectos de la
narrativa, asumimos que esta empresa ha completado cada una de las iteraciones de gobernanza descritas en
esta guía de gobernanza.
En la fase anterior de esta narrativa, la empresa había comenzado a insertar activamente las aplicaciones de
producción en la nube mediante canalizaciones de CI/CD.
La identidad se controla mediante una instancia local de Active Directory. La identidad híbrida se facilita
mediante la replicación a Azure Active Directory.
Las operaciones de TI o las operaciones de la nube se administran en gran parte en Azure Monitor y en
procesos de automatización relacionados.
La recuperación ante desastres y la continuidad empresarial se controlan mediante almacenes de Recovery
Services.
Azure Security Center se utiliza para supervisar infracciones de seguridad y ataques.
Tanto Azure Security Center como Azure Monitor se utilizan para supervisar la gobernanza de la nube.
Azure Blueprints, Azure Policy y los grupos de administración de Azure se utilizan para automatizar el
cumplimiento con la directiva.
El objetivo es integrar la empresa de adquisición en las operaciones existentes siempre que sea posible.

Costo de adquisición de negocios: se estima que la adquisición del nuevo negocio sea rentable en
aproximadamente cinco años. Debido a la lenta tasa de retorno, la junta quiere controlar los costos de
adquisición, en la medida de lo posible. Existe el riesgo de que el control de costos y la integración técnica
entren en conflicto entre sí.
La migración a la nube podría producir costos de adquisición adicionales.
Es posible que el nuevo entorno no esté gobernado adecuadamente, lo que podría dar lugar a infracciones
de las directivas.
implementación:
Todos los recursos en una nube secundaria deben supervisarse mediante las herramientas existentes de
administración operativa y supervisión de seguridad.
Todas las unidades organizativas deben integrarse en el proveedor de identidades existente.
El proveedor de identidades principal debe regir la autenticación de los recursos en la nube secundaria.

nuevas directivas de Azure y una implementación de Azure Cost Management + Billing. Juntos, estos cambios
de diseño cumplirán con las nuevas declaraciones de directiva corporativa.
1. Conecte las redes. Este paso lo ejecutan los equipos de redes y de seguridad de TI y está respaldado por el
equipo de gobernanza de la nube. La adición de una conexión desde el proveedor de líneas alquiladas o
MPLS a la nueva nube integrará las redes. La adición de tablas de enrutamiento y configuraciones de firewall
controlará el acceso y el tráfico entre los entornos.
2. Consolide los proveedores de identidades. Dependiendo de las cargas de trabajo que se hospeden en la nube
secundaria, hay una variedad de opciones para la consolidación de proveedores de identidades. Estos son
algunos ejemplos:
a. Para las aplicaciones que se autentican mediante OAuth 2, los usuarios de Active Directory en la nube
secundaria pueden simplemente replicarse al inquilino de Azure AD existente. Esto asegura que todos
los usuarios se puedan autenticar en el inquilino.
b. En el otro extremo, la federación permite que las unidades organizativas fluyan a Active Directory
local y después a la instancia de Azure AD.
3. Agregue recursos a Azure Site Recovery.
a. Azure Site Recovery se ha diseñado desde el principio como una herramienta híbrida o de varias
nubes.
b. Las máquinas virtuales en la nube secundaria podrían estar protegidas por los mismos procesos de
Azure Site Recovery utilizados para proteger los recursos locales.
4. Agregue los recursos a Azure Cost Management + Billing.
a. Azure Cost Management + Billing se ha diseñado desde el principio como una herramienta para
varias nubes.
b. Las máquinas virtuales en la nube secundaria pueden ser compatibles con Azure Cost Management +
Billing para algunos proveedores de servicios en la nube. Se pueden aplicar costos adicionales.
5. Agregue recursos a Azure Monitor.
a. Azure Monitor se ha diseñado desde el principio como una herramienta de nube híbrida.
b. Las máquinas virtuales en la nube secundaria pueden ser compatibles con los agentes de Azure
Monitor, lo que permite incluirlas en Azure Monitor para la supervisión operativa.
6. Adopte las herramientas de aplicación de la gobernanza.
a. El cumplimiento de gobernanza es específico de la nube.
b. Las directivas corporativas establecidas en la guía de gobernanza no son específicas de la nube.
Aunque la implementación puede variar de una nube a otra, las directivas pueden aplicarse al
proveedor secundario.
La adopción de varias nubes se debe implementar donde sea necesaria en función de necesidades técnicas o los
requisitos empresariales específicos. A medida que progresa la adopción de varias nubes, aumenta la
complejidad y los riesgos de seguridad.
Conclusión
En esta serie de artículos se describe el desarrollo incremental de los procedimientos recomendados de
gobernanza, alineados con las experiencias de esta empresa ficticia. Al comenzar con una base pequeña, pero
con los cimientos adecuados, la empresa podría moverse rápidamente y aún así aplicar la cantidad adecuada de
gobernanza en el momento adecuado. El producto mínimo viable por sí mismo no ha protegido al cliente. En
cambio, ha creado las bases para administrar los riesgos y agregar protecciones. A partir de ahí, se aplicaron
capas de gobernanza para corregir los riesgos tangibles. El recorrido exacto que aquí se ha presentado no se
alinea al 100 % con las experiencias de ningún lector. Más bien, sirve como patrón para la gobernanza
incremental. Debe adaptar estos procedimientos recomendados para que se ajusten a sus propias limitaciones y
requisitos de gobernanza.
Introducción sobre los procedimientos recomendados

Esta guía de gobernanza muestra las experiencias de una empresa ficticia a través de diversas fases de madurez
del proceso de gobernanza. Se basa en experiencias reales de los clientes. Los procedimientos recomendados
sugeridos se basan en las restricciones y necesidades de la empresa ficticia.
Como punto de inicio rápido, esta información general define un producto viable mínimo (MVP) para la
gobernanza en función de los procedimientos recomendados. También proporciona vínculos a algunas mejoras
de gobernanza que agregan más procedimientos recomendados a medida que emergen nuevos riesgos
técnicos o empresariales.
WARNING
Este MVP es un punto de inicio de la base de referencia, basado en un conjunto de suposiciones. Incluso este conjunto
mínimo de procedimientos recomendados se basa en directivas corporativas controladas por las tolerancias al riesgo y los
riesgos empresariales únicos. Para ver si estas suposiciones se aplican a los usuarios, lea la narrativa más larga que sigue
este artículo.
Procedimientos recomendados sobre gobernanza

Este procedimiento recomendado actúa como la base para que una organización agregue barreras de seguridad
de forma rápida y coherente en varias suscripciones de Azure.
En el siguiente diagrama se muestra la jerarquía de MVP de gobernanza para organizar recursos.
Todas las aplicaciones deben implementarse en el área adecuada de la jerarquía de grupos de recursos,
suscripción y grupos de administración. Durante el planeamiento de la implementación, el equipo de
gobernanza en la nube creará los nodos necesarios en la jerarquía para capacitar a los equipos de adopción de
la nube.
1. Defina un grupo de administración para cada unidad de negocio con una jerarquía detallada que refleje
primero la zona geográfica y, después, el tipo de entorno (por ejemplo, los entornos de producción o de
no producción).
2. Cree una suscripción de producción y otra de no producción para cada combinación única de unidad de
negocio o zona geográfica discretas. La creación de varias suscripciones requiere extremar la atención.
Para más información, consulte la Guía de decisiones de suscripción.
3. Aplique una nomenclatura coherente en cada nivel de esta jerarquía de agrupación.
4. Los grupos de recursos se deben implementar de forma que tengan en cuenta el ciclo de vida de su
contenido. Los recursos que se desarrollan, se administran y se retiran juntos pertenecen al mismo
grupo. Para más información sobre los procedimientos recomendados para usar grupos de recursos,
consulte la guía de decisiones con coherencia de recursos.
5. La selección de región es sumamente importante y se debe tener muy en cuenta para que las redes, la
supervisión y la auditoría estén en vigor para la conmutación por error o la conmutación por
recuperación así como para la confirmación de que las SKU necesarias están disponibles en las regiones
preferidas.
Estos patrones permiten crecer sin que la jerarquía sea innecesariamente complicada.
NOTE
En caso de que se produzcan cambios en sus requisitos empresariales, los grupos de administración de Azure permiten
reorganizar fácilmente la jerarquía de administración y las asignaciones de los grupos de suscripciones. Sin embargo,
tenga en cuenta que las asignaciones de directivas y roles que se aplican a un grupo de administración las heredan todas
las suscripciones que se encuentren debajo de ese grupo en la jerarquía. Si planea reasignar suscripciones entre los
distintos grupos de administración, asegúrese de que conoce todos los cambios en las asignaciones de directivas y roles
que pueden producirse. Para más información, consulte la documentación de los grupos de administración de Azure.
Gobernanza de recursos
Un conjunto de roles RBAC y directivas globales proporcionará un nivel base de referencia de cumplimiento de
gobernanza. Para satisfacer los requisitos de directivas del equipo de gobernanza de la nube, la implementación
del MVP de gobernanza exige completar las tareas siguientes:
1. Identifique las definiciones de Azure Policy personalizadas necesarias para cumplir los requisitos
empresariales. Esto puede incluir el uso de definiciones integradas y la creación de definiciones
personalizadas. Para mantenerse al día de las definiciones integradas recién publicadas, hay una fuente Atom
de todas las confirmaciones de las directivas integradas, que puede usar para una fuente RSS. Como
alternativa, puede comprobar AzAdvertizer.
2. Cree una definición del plano técnico mediante estas directivas integradas y personalizadas y las
asignaciones de roles que requiere el MVP de gobernanza.
3. Aplique las directivas y la configuración globalmente mediante la asignación de la definición del plano
técnico a todas las suscripciones.
Identificación de las definiciones de directivas
Azure proporciona varias directivas integradas y definiciones de roles que se pueden asignar a cualquier grupo
de administración, suscripción o grupo de recursos. Muchos requisitos habituales de gobernanza pueden
controlarse mediante definiciones integradas. Sin embargo, es probable que también necesite crear definiciones
de directivas personalizadas para administrar sus requisitos específicos.
Las definiciones de las directivas personalizadas se guardan en un grupo de administración o en una suscripción
y se heredan a través de la jerarquía de los grupos de administración. Si la ubicación de guardado de la
definición de una directiva es un grupo de administración, dicha definición está disponible para asignarla a
cualquiera de las suscripciones o grupos de administración secundarios de ese grupo.
Dado que las directivas necesarias para dar soporte al MVP de gobernanza están destinadas a aplicarse a todas
las suscripciones actuales, se implementarán los siguientes requisitos empresariales mediante una combinación
de definiciones integradas y personalizadas creadas en el grupo de administración raíz:
1. Restrinja la lista de asignaciones de roles disponibles al conjunto de roles de Azure integrados que autorice el
equipo de gobernanza de la nube. Esto requiere una definición de directiva personalizada.
2. Exija el uso de las siguientes etiquetas en todos los recursos: Departamento/unidad de facturación,
Geografía, Clasificación de los datos, Importancia crítica, Acuerdo de Nivel de Servicio, Entorno, Arquetipo de
aplicación, Aplicación y Propietario de aplicación. Esto se puede controlar mediante la definición integrada de
Require specified tag .
3. Solicite que la etiqueta Application de los recursos coincida con el nombre del grupo de recursos
pertinente. Esto puede controlarse mediante la definición integrada "Requerir etiqueta y su valor".
Para obtener información acerca de cómo definir directivas personalizadas, consulte la documentación de Azure
Policy. Para obtener una guía y ejemplos de directivas personalizadas, consulte el sitio de ejemplos de Azure
Policy y el repositorio de GitHub asociado.
Asignación de roles de RBAC y de Azure Policy mediante Azure Blueprints
Las directivas de Azure se pueden asignar en el nivel de grupo de recursos, suscripción y grupo de
administración, y se pueden incluir en las definiciones de Azure Blueprints. Aunque los requisitos de directiva
que se definen en este MVP de gobernanza se aplican a todas las suscripciones actuales, es muy probable que
las futuras implementaciones requieran excepciones o directivas alternativas. Como resultado, la asignación de
una directiva mediante grupos de administración. y que todas las suscripciones secundarias heredan estas
asignaciones, puede no ser lo suficientemente flexible para admitir estos escenarios.
Azure Blueprints permite la asignación coherente de roles y directivas, la aplicación de plantillas de Resource
Manager y la implantación de grupos de recursos en varias suscripciones. Al igual que las definiciones de
directivas, las definiciones de planos técnicos se guardan en grupos de administración o suscripciones. Las
definiciones de directivas están disponibles mediante la herencia para todos los elementos secundarios de la
El equipo de gobernanza en la nube ha decidido que el cumplimiento de las asignaciones de RBAC y Azure
Policy necesarias en las suscripciones se implementará a través de Azure Blueprints y los artefactos asociados:
1. En el grupo de administración raíz, cree una definición de plano técnico denominada governance-baseline .
2. Agregue los siguientes artefactos de plano técnico a dicha definición:
a. Asignaciones de directivas para las definiciones de Azure Policy personalizadas definidas en la raíz del
b. Definiciones de grupo de recursos para los grupos necesarios en las suscripciones creadas i regidas
por el MVP de gobernanza.
c. Asignaciones de roles estándar necesarias en las suscripciones que el MVP de gobernanza ha creado o
regido.
3. Publique la definición del plano técnico.
4. Asigne la definición del plano técnico governance-baseline a todas las suscripciones.
Consulte la documentación de Azure Blueprints para obtener más información sobre cómo crear y usar
definiciones del plano técnico.
Red virtual híbrida segura
A menudo, determinadas suscripciones requieren cierto nivel de acceso a los recursos locales. Esto es habitual
en escenarios de migración o escenarios de desarrollo en los que los recursos dependientes residen en el centro
de datos local.
Hasta que la confianza en el entorno de nube está completamente establecida es importante controlar y
supervisar estrechamente no solo todas las comunicaciones que se permiten entre el entorno local y las cargas
de trabajo en la nube, sino también que la red local está protegida contra el potencial acceso no autorizado de
recursos basados en la nube. Para admitir estos escenarios, el MVP de gobernanza agrega las siguientes
prácticas recomendadas:
1. Establezca una red virtual híbrida segura en la nube.
a. La arquitectura de referencia de la VPN establece un patrón y un modelo de implementación para
crear una instancia de VPN Gateway en Azure.
b. Compruebe que los mecanismos locales de seguridad y administración del tráfico traten las redes en
la nube conectadas como recursos que no son de confianza. Los recursos y servicios hospedados en la
nube solo deben tener acceso a los servicios locales autorizados.
c. Valide que el dispositivo de extremo local que se encuentra en el centro de datos local es compatible
con los requisitos de Azure VPN Gateway y está configurado para acceder a la red Internet pública.
d. Tenga en cuenta que los túneles de VPN no deben considerarse circuitos preparados para producción
salvo para las cargas de trabajo más simples. Todo lo que vaya más allá de algunas cargas de trabajo
sencillas que requieran conectividad local debería emplear Azure ExpressRoute.
2. En el grupo de administración raíz, cree una segunda definición del plano técnico llamada
secure-hybrid-vnet .
a. Agregue la plantilla de Resource Manager para la instancia de VPN Gateway como un artefacto para la
definición del plano técnico.
b. Agregue la plantilla de Resource Manager para la red virtual como un artefacto para la definición del
plano técnico.
c. Publique la definición del plano técnico.
3. Asigne la secure-hybrid-vnet definición del plano técnico a todas las suscripciones que requieran
conectividad local. Esta definición se debe asignar además de la definición del plano técnico
governance-baseline .
Una de las mayores preocupaciones que plantea la seguridad de TI y los equipos de gobernanza tradicional, es
el riesgo de que la adopción de la nube en una etapa temprana vaya a poner en peligro los recursos existentes.
El método anterior permite a los equipos de adopción de la nube crear y migrar soluciones híbridas, con un
riesgo reducido para los recursos locales. Cuando la confianza en el entorno en la nube aumente, las posteriores
evoluciones podrán quitar esta solución temporal.
NOTE
La información anterior es solo un punto de partida para crear rápidamente un MVP de gobernanza de línea de base.
Esto es solo el comienzo del recorrido hacia la gobernanza. De todos modos, será necesaria una evolución aún mayor a
medida que la empresa continúe adoptando la nube y asuma más riesgos en las siguientes áreas:
Datos protegidos
Además, los detalles concretos de este MVP se basan en el proceso de ejemplo de una empresa ficticia, que se describe en
los artículos siguientes. Le recomendamos encarecidamente que se familiarice con los otros artículos de esta serie antes
de implementar este procedimiento recomendado.
Mejoras de gobernanza incremental

Una vez que se ha implementado este MVP, se pueden incorporar capas de gobernanza rápidamente en el
entorno. Estas son algunas formas de mejorar el MVP para satisfacer necesidades empresariales específicas:
Base de referencia de seguridad para datos protegidos
Configuraciones de recursos para aplicaciones críticas
Controles de administración de costos
Controles para la mejora incremental de la nube múltiple
¿Qué proporciona esta guía?

En el MVP, se establecen los procedimientos y las herramientas de la materia de aceleración de la
implementación para aplicar rápidamente la directiva corporativa. En concreto, el MVP usa Azure Blueprints,
Azure Policy y grupos de administración de Azure para aplicar algunas directivas corporativas básicas, tal como
se define en la narrativa de esta empresa ficticia. Dichas directivas corporativas se aplican mediante plantillas de
Azure Resource Manager y directivas de Azure para establecer una base de referencia pequeña para la identidad
y la seguridad.
Mejora incremental de los procedimientos de gobernanza

Con el tiempo, este MVP de gobernanza se usará para mejorar de forma incremental las prácticas de
gobernanza. A medida que avanza la adopción, aumenta el riesgo empresarial. Para administrar esos riesgos, se
adaptarán varias materias dentro del modelo de gobernanza de Cloud Adoption Framework. En artículos
posteriores de esta serie se explica la evolución de la directiva corporativa que afecta a la empresa ficticia. Estos
cambios se producen en cuatro materias:
La disciplina de base de referencia de identidad, cuando las dependencias de migración cambian en la
narración.
La materia de administración de costos, cuando se escala la adopción.
La materia de base de referencia de seguridad, cuando se implementan los datos protegidos.
La materia de coherencia de los recursos, cuando las operaciones de TI empiezan a admitir cargas de trabajo
críticas.
Pasos siguientes
Ahora que se ha familiarizado con el producto viable mínimo de gobernanza y con los próximos cambios de la
gobernanza, lea la documentación complementaria para obtener más contexto.
Lectura de la narrativa de apoyo
Guía de gobernanza para empresas complejas:
Narrativa de apoyo
El siguiente artículo establece un caso de uso de gobernanza durante el recorrido de adopción de la nube de
una empresa compleja. Antes de actuar sobre las recomendaciones de la guía, es importante comprender las
suposiciones y los razonamientos que se reflejan en esta narrativa. Solo entonces podrá alinear mejor la
estrategia de gobernanza con el recorrido de adopción de la nube de su organización.
Antecedentes
Los clientes exigen una mejor experiencia al interactuar con esta empresa. La experiencia actual ha erosionado el
mercado y ha llevado a la junta a contratar a un director de tecnología digital (CDO). El CDO trabaja con
marketing y ventas para impulsar una transformación digital que potenciará las experiencias mejoradas.
Además, varias unidades de negocio contrataron recientemente a científicos de datos para las granjas de datos y
para mejorar muchas de las experiencias manuales mediante el aprendizaje y la predicción. TI apoya estos
esfuerzos en la medida de lo posible. Se están llevando a cabo actividades de "shadow IT" que quedan fuera de
los controles de gobernanza y seguridad necesarios.
La organización de TI también se enfrenta a sus propios retos. Finanzas está planeando reducciones continuas
en el presupuesto de TI durante los próximos cinco años, lo que llevará a algunos recortes de gastos necesarios
a partir de este año. Por el contrario, los requisitos de RGPD y otros requisitos de gobierno de datos están
obligando a TI a invertir en recursos en otros países para localizar datos. Dos de los centros de datos existentes
están atrasados en la actualización de hardware, lo que causa más problemas con la satisfacción de los
empleados y los clientes. Tres centros de datos más requieren actualizaciones de hardware durante la ejecución
del plan quinquenal. El CFO está presionando al CIO para que considere la nube como una alternativa para esos
centros de datos, con objeto de liberar gastos de capital.
El CIO tiene ideas innovadoras que podrían ayudar a la empresa, pero él y sus equipos se limitan a apagar
fuegos y controlar costos. En un almuerzo con el CDO y uno de los responsables de la unidad de negocios, la
conversación sobre la migración a la nube generó el interés de los compañeros del CIO. El objetivo de los tres
responsables es apoyarse mutuamente en el uso de la nube para alcanzar sus objetivos de negocio, y han
comenzado las fases de exploración y planeamiento de la adopción de la nube.
La empresa tiene el siguiente perfil de negocio:
Las ventas y operaciones abarcan varias áreas geográficas con clientes globales en múltiples mercados.
El negocio ha crecido mediante adquisiciones y opera en tres unidades de negocio basadas en la base de
clientes objetivo. La realización de presupuestos es una matriz compleja que abarca todas las unidades de
negocio y funciones.
La empresa considera la mayor parte del departamento de TI como una fuga de capital o un centro de
coste.
Estado actual
A continuación se muestra el estado actual de las operaciones de TI y de la nube de la empresa:
TI opera más de 20 centros de datos privados en todo el mundo.
Debido al crecimiento orgánico y a varias zonas geográficas, hay algunos equipos de TI que tienen
requisitos únicos de soberanía de datos y cumplimiento que afectan a una sola unidad de negocio que
funciona dentro de una zona geográfica específica.
Cada centro de datos está conectado por una serie de líneas regionales alquiladas, que crean una WAN
global sin conexión directa.
Asimismo, el departamento de TI entró en la nube al migrar todas las cuentas de correo electrónico de
los usuarios finales a Microsoft 365. Esta migración se completó hace más de seis meses. Desde
entonces, solo se han implementado unos pocos recursos de TI en la nube.
El equipo de desarrollo principal del CDO está trabajando en una capacidad de desarrollo y pruebas para
aprender sobre las funcionalidades nativas en la nube.
Una unidad de negocio está experimentando con grandes cantidades de datos en la nube. El equipo de la
unidad de negocio dentro de TI participa en ese esfuerzo.
La actual directiva de gobernanza de TI establece que la información personal del cliente y los datos
financieros se deben hospedar en recursos que pertenecen directamente a la empresa. Esta directiva
bloquea la adopción de la nube para las aplicaciones críticas o los datos protegidos.
Las inversiones en TI están controladas en gran medida por el gasto de capital. Estas inversiones se
planean anualmente y a menudo incluyen planes de mantenimiento continuo, así como ciclos de
actualización establecidos de tres a cinco años, dependiendo del centro de datos.
La mayoría de las inversiones en tecnología que no se alinean con el plan anual se abordan con los
trabajos de TI en la sombra. Estos esfuerzos suelen estar administrados por las unidades de negocio y
financiarse mediante los gastos operativos de la unidad de negocio.
Estado futuro
Se prevén los siguientes cambios para los próximos años:
El CIO está liderando un esfuerzo para modernizar la directiva sobre la información personal y los datos
financieros para apoyar los objetivos futuros. Dos miembros del equipo de gobernanza de TI tienen
visibilidad de este esfuerzo.
El CIO quiere usar la migración a la nube como una función de impulso para mejorar la coherencia y la
estabilidad entre las unidades de negocio y las zonas geográficas. El estado futuro debe respetar todos
los requisitos de cumplimiento externos para los que equipos de TI determinados deban apartarse de los
enfoques estándar.
Si los primeros experimentos en el desarrollo de aplicaciones y en BI muestran indicadores de éxito, a
cada uno de ellos le gustaría lanzar soluciones de producción a pequeña escala a la nube durante los
próximos 24 meses.
El CIO y el CFO han asignado un arquitecto y al vicepresidente de infraestructura para crear un análisis de
costos y un estudio de viabilidad. Estos esfuerzos determinarán si la empresa puede y debe mover 5000
recursos a la nube en los próximos 36 meses. Una migración correcta permitiría al CIO eliminar dos
centros de datos, con lo que se reducen los costos en más de 100 millones USD durante el plan
quinquenal. Si tres o cuatro centros de datos pueden experimentar resultados similares, el presupuesto
volverá a la senda de los beneficios, lo que permitirá que el presupuesto del CIO apoye iniciativas más
innovadoras.
Junto con este ahorro de costos, la empresa planea cambiar la administración de algunas inversiones en
TI cambiando la posición del gasto de capital comprometido como un gasto operativo dentro de TI. Este
cambio proporcionará un mayor control de los costos, que los equipos de TI pueden utilizar para acelerar
otros esfuerzos previstos.
Pasos siguientes
La empresa ha desarrollado una directiva corporativa para dar forma a la implementación de la gobernanza. La
directiva corporativa dirige muchas de las decisiones técnicas.
Revisión de la directiva corporativa inicial
directiva corporativa inicial que está detrás de la
estrategia de gobernanza
La siguiente directiva corporativa define la posición inicial de gobernanza, que es el punto de inicio de esta guía.
En este artículo se definen riesgos incipientes, las declaraciones de directiva iniciales y los procesos iniciales
para aplicar las declaraciones de directiva.
NOTE
La directiva corporativa no es un documento técnico, pero promueve muchas decisiones técnicas. El producto mínimo
viable de gobernanza descrito en la información general deriva, en última instancia, de esta directiva. Antes de
implementar un producto mínimo viable de gobernanza, su organización debe desarrollar una directiva corporativa en
función de sus propios objetivos y riesgos empresariales.

El CIO recientemente ha mantenido una reunión con el equipo de gobernanza de TI para conocer el historial de
información personal y las directivas críticas, y revisar el impacto que podría tener cambiar esas directivas.
También ha analizado el potencial general de la nube tanto para TI como para la empresa.
Después de la reunión, dos miembros del equipo de gobernanza de TI solicitaron permiso para investigar y dar
soporte técnico a los trabajos de planeamiento de la nube. Al reconocer la necesidad de gobernanza y una
oportunidad para limitar la TI en la sombra, el director de gobernanza de TI apoyó esta idea. Así nació el equipo
de gobernanza de la nube. En los próximos meses heredarán la limpieza de la gran cantidad de errores
cometidos durante la exploración en la nube desde una perspectiva de gobernanza. Esto les valdrá el
sobrenombre de custodios de la nube. En posteriores iteraciones, esta guía mostrará los cambios sufridos por
sus roles con el paso del tiempo.
Objetivo
El objetivo inicial es establecer una base para la agilidad de gobernanza. Un producto viable mínimo de
gobernanza eficaz permite al equipo de gobernanza anticiparse a la adopción de la nube e implementar
barreras de seguridad a medida que cambia el plan de adopción.
La empresa está en una fase temprana de adopción de la nube, experimentando y creando pruebas de concepto.
Ahora los riesgos son relativamente bajos, pero es posible que existan riesgos futuros con un impacto
significativo. Existe poca definición acerca del estado final de las soluciones técnicas que se implementarán en la
nube. Además, la preparación de los empleados de TI para la nube es baja. Una base para la adopción de la nube
ayudará al equipo a aprender y crecer de forma segura.
Perdurabilidad: Existe el riesgo de no permitir el crecimiento, pero también el riesgo de no proporcionar los
mecanismos de protección adecuados contra los riesgos futuros.
Es necesario un enfoque de gobernanza ágil, pero sólido para admitir la visión del consejo para el crecimiento
corporativo y técnico. No implementar este tipo de estrategia ralentizará el crecimiento técnico, lo que
posiblemente ponga en riesgo el crecimiento de la cuota de mercado actual y futura. El impacto de un riesgo
empresarial tal es claramente alto. Sin embargo, se desconoce el rol que TI desempeñará en dichos posibles
estados futuros, lo que hace que el riesgo asociado con los esfuerzos actuales de TI sean relativamente altos.
Dicho esto, en tanto no se alineen planes más concretos, la empresa tiene una alta tolerancia al riesgo.
Este riesgo empresarial puede dividirse de manera táctica en varios riesgos técnicos:
Las directivas corporativas bienintencionadas podrían ralentizar los esfuerzos de transformación o
interrumpir los procesos empresariales esenciales si no se tienen en cuenta dentro de un flujo de aprobación
estructurado.
La aplicación de la gobernanza a los recursos implementados podría ser difícil y costosa.
La gobernanza puede no aplicarse correctamente en una aplicación o una carga de trabajo, lo que crea
brechas de seguridad.
Con tantos equipos que trabajan en la nube, existe un riesgo de incoherencia.
Los costos pueden no alinearse correctamente con las unidades de negocio, los equipos u otras unidades de
administración presupuestarias.
El uso de varias identidades para administrar varias implementaciones puede provocar problemas de
seguridad.
A pesar de las directivas actuales, existe el riesgo de que los datos protegidos puedan implementarse por
error en la nube.
Indicadores de tolerancia
La tolerancia al riesgo actual es alta y el apetito por invertir en la gobernanza de la nube es bajo. Como tales, los
indicadores de tolerancia actúan como sistema de advertencia anticipado para desencadenar la inversión de
tiempo y energía. Si se observan los indicadores siguientes, es aconsejable cambiar la estrategia de gobernanza.
Materia de administración de costos: la escala de implementación supera los 1000 recursos en la nube,
o bien los gastos mensuales superan los 10 000 dólares al mes.
Materia de base de referencia de identidad: inclusión de aplicaciones con requisitos de autenticación
multifactor de terceros o heredados.
Materia de base de referencia de seguridad: inclusión de datos protegidos en planes de adopción de la
nube definidos.
Materia de coherencia de recursos: inclusión de cualquier aplicación crítica en planes de adopción de la
nube definidos.
Policy statements
Las siguientes declaraciones de la directiva establecen los requisitos necesarios para corregir los riesgos
definidos. Estas directivas definen los requisitos funcionales para el MVP de gobernanza. Cada uno se
representará en la implementación del MVP de gobernanza.
Administración de costos:
Con fines de seguimiento, todos los recursos deben asignarse a un propietario de aplicación dentro de una
de las principales funciones empresariales.
Cuando surjan problemas de costos, se establecerán requisitos de gobernanza adicionales con el equipo de
finanzas.
Base de referencia de seguridad:
Cualquier recurso implementado en la nube debe tener una clasificación de datos aprobada.
Ningún recurso identificado con un nivel de datos protegidos se puede implementar en la nube, hasta que se
aprueben e implementen los suficientes requisitos de seguridad y gobernanza.
Hasta que se puedan validar y gobernar los requisitos mínimos de seguridad de red, los entornos en la nube
se perciben como una red perimetral y deben cumplir con requisitos de conexión similares a otros centros de
datos o redes internas.
Coherencia de recursos:
Dado que no se implementa ninguna carga de trabajo crítica en esta fase, no hay ningún requisito de SLA,
rendimiento o BCDR que se deba gobernar.
Cuando se implementen cargas de trabajo críticas, se establecerán requisitos de gobernanza adicionales con
las operaciones de TI.
Base de referencia de identidad:
todos los recursos que se implementan en la nube deben controlarse mediante identidades y roles
aprobados por las directivas de gobernanza actuales.
todos los grupos de la infraestructura local de Active Directory que tienen privilegios elevados deben
asignarse a un rol RBAC aprobado.
Aceleración de la implementación:
Todos los recursos se deben agrupar y etiquetar en función de las estrategias de agrupación y etiquetado
definidas.
Todos los recursos deben usar un modelo de implementación aprobado.
Una vez que se ha establecido una base de gobernanza para un proveedor de nube, las herramientas de
implementación deben ser compatibles con las herramientas definidas por el equipo de gobernanza.
Procesos
No se ha asignado ningún presupuesto para la supervisión en curso y el cumplimiento de estas directivas de
gobernanza. Por este motivo, el equipo de gobernanza de la nube tiene varias formas improvisadas de
supervisar el cumplimiento de las declaraciones de las directivas.
Educación: el equipo de gobernanza de la nube está invirtiendo tiempo en formar a los equipos de
adopción de la nube en las guías de gobernanza que admiten estas directivas.
Revisiones de la implementación: antes de implementar cualquier recurso, el equipo de gobernanza de
la nube revisará la guía de gobernanza con los equipos de adopción de la nube.
Pasos siguientes
Esta directiva corporativa prepara el equipo de gobernanza de la nube para implementar el producto viable
mínimo de gobernanza como base de la adopción. El siguiente paso es implementar dicho producto mínimo
viable.
La guía de gobernanza empieza con un conjunto de directivas corporativas iniciales. Estas directivas se usan
para establecer un producto viable mínimo (MVP) para la gobernanza que refleje los procedimientos
recomendados.
En este artículo, se abordarán las estrategias generales necesarias para crear un MVP de gobernanza. En el
centro del MVP de gobernanza se encuentra la materia de aceleración de la implementación. Las herramientas y
los patrones que se aplican en esta etapa darán lugar a las mejoras graduales necesarias para expandir la
gobernanza en el futuro.
Producto viable mínimo de gobernanza (base de gobernanza inicial)

La rápida adopción de las directivas corporativas y de gobernanza es factible gracias a unos pocos principios
sencillos y a las herramientas de gobernanza basadas en la nube. Se trata de la primera de las tres materias de
gobernanza para enfocarse en cualquier proceso de gobernanza. Cada una de las materias se explicará más
detalladamente en este artículo.
Para establecer el punto de partida, en este artículo se tratan las estrategias de alto nivel que hay detrás de las
materias de base de referencia de seguridad, base de referencia de identidad y aceleración de la implementación
que son necesarias para crear un MVP de gobernanza. MVP sirve como base para toda la adopción de la nube.
Proceso de implementación
La implementación del MVP de gobernanza tiene dependencias de identidad, seguridad y redes. Una vez
resueltas las dependencias, el equipo de gobernanza de la nube decidirá algunos aspectos de la gobernanza. Las
decisiones del equipo de gobernanza de la nube y de los equipos auxiliares se implementarán a través de un
único paquete de recursos de cumplimiento.
Esta implementación también se puede describir con una simple lista:
1. Solicitar decisiones relacionadas con las dependencias principales: identidad, red y cifrado.
2. Determinar el patrón que se usará durante el cumplimiento de las directivas corporativas.
3. Determinar los patrones de gobernanza apropiados para coherencia de los recursos, etiquetado de recursos
y registro e informes.
4. Implementar las herramientas de gobernanza alineadas con el patrón elegido de cumplimiento de directivas
para aplicar las decisiones dependientes y las decisiones de gobernanza.
Decisiones dependientes
Las siguientes decisiones proceden de equipos fuera del equipo de gobernanza de la nube. La implementación
de cada una procederá de esos mismos equipos. No obstante, el equipo de gobernanza de la nube es
responsable de implementar una solución para validar que esas implementaciones se aplican de forma
coherente.
La línea de base de identidad es el punto de partida fundamental para toda gobernanza. Antes de intentar
aplicar la gobernanza, se debe establecer la identidad. A continuación, las soluciones de gobernanza harán
cumplir la estrategia de identidad establecida. En esta guía de gobernanza, el equipo de administración de
identidades implementa el patrón de sincronización de directorios:
Azure Active Directory (Azure AD) proporcionará RBAC, mediante la sincronización de directorios o el
"mismo inicio de sesión" que se implementó durante la migración de la empresa a Microsoft 365. Para una
guía sobre la implementación, consulte Arquitectura de referencia para Integración de Azure AD.
El inquilino de Azure AD también regirá la autenticación y el acceso a los recursos implementados en Azure.
En el producto viable mínimo de gobernanza, el equipo de gobernanza hará cumplir la aplicación del inquilino
replicado mediante herramientas de gobernanza de la suscripción que se describen más adelante en este
artículo. En iteraciones futuras, el equipo de gobernanza podría también aplicar herramientas enriquecidas de
Azure AD para ampliar esta funcionalidad.
Base de referencia de seguridad: Redes
Una red definida por software es un aspecto inicial importante de la línea de base de seguridad. Establecer el
MVP de gobernanza depende de decisiones tempranas por parte del equipo de administración de seguridad
para definir cómo se pueden configurar con seguridad las redes.
Debido a la falta de requisitos, el equipo de seguridad de TI busca protección y ha solicitado un patrón de nube
DMZ. Esto significa que la gobernanza de las implementaciones de Azure mismas será muy ligero.
Las suscripciones de Azure pueden conectarse a un centro de datos existente mediante VPN, pero deben
seguir todas las directivas locales de gobernanza de TI con respecto a la conexión de una red perimetral a los
recursos protegidos. Para obtener instrucciones sobre la implementación con respecto a la conectividad de
VPN, consulte el artículo Red local conectada a Azure mediante VPN Gateway.
Actualmente se están aplazando las decisiones con respecto a subredes, firewalls y enrutamiento a cada
cliente potencial de aplicación y carga de trabajo.
En este patrón, las redes en la nube solo pueden conectarse a los recursos locales a través de una VPN existente
que sea compatible con Azure. El tráfico a través de esa conexión se tratará como cualquier tráfico procedente
de una red perimetral. Puede que sean necesarias consideraciones adicionales relativas al dispositivo perimetral
local para controlar el tráfico de Azure de forma segura.
El equipo de gobernanza de la nube ha invitado activamente a los miembros de los equipos de redes y de
seguridad de TI a reuniones periódicas para anticiparse a las demandas y los riesgos de las redes.
Base de referencia de seguridad: Cifrado
El cifrado es otra decisión fundamental en la materia de línea de base de seguridad. Dado que la empresa
actualmente todavía no almacena ningún dato protegido en la nube, el equipo de seguridad ha decidido un
patrón menos agresivo para el cifrado. En este momento, se sugiere un patrón nativo de la nube para el cifrado,
pero no es obligatorio para ningún equipo de desarrollo.
No se han establecido requisitos de gobernanza con respecto al uso de cifrado, ya que la actual directiva
corporativa no permite datos críticos ni protegidos en la nube.
Serán necesarios análisis adicionales antes de la publicación de datos protegidos o cargas de trabajo críticas.
La primera decisión que se deberá tomar en cuanto a la aceleración de la implementación es el patrón para el
cumplimiento. En esta narración, el equipo de gobernanza ha decidido implementar el patrón cumplimiento
automatizado.
Azure Security Center estará disponible para que los equipos de seguridad e identidad supervisen los riesgos
de seguridad. También es probable que ambos equipos usen Security Center para identificar los nuevos
riesgos y mejorar la directiva corporativa.
RBAC se requiere en todas las suscripciones para controlar el cumplimiento de autenticación.
Azure Policy se publicará en cada grupo de administración y se aplicará a todas las suscripciones. Sin
embargo, el nivel de las directivas que se aplique será muy limitado en este MVP de gobernanza inicial.
Aunque se usen grupos de administración de Azure, se espera una jerarquía relativamente sencilla.
Azure Blueprints se usará para implementar y actualizar las suscripciones mediante la aplicación de
requisitos de RBAC, plantillas de Resource Manager y Azure Policy en los grupos de administración.
Aplicación de los patrones dependientes

Las siguientes decisiones representan los patrones que se harán cumplir a través de la estrategia de
cumplimiento de directivas anterior:
Línea de base de identidad. Azure Blueprints establecerá los requisitos de RBAC en un nivel de suscripción
para asegurarse de que se configure una identidad coherente para todas las suscripciones.
Línea de base de seguridad: Redes. El equipo de gobernanza de la nube mantiene una plantilla de Resource
Manager para establecer una puerta de enlace de VPN entre Azure y el dispositivo de VPN local. Cuando un
equipo de aplicación requiera una conexión VPN, el equipo de gobernanza de la nube aplicará la plantilla de
Resource Manager de la puerta de enlace mediante Azure Blueprints.
Línea de base de seguridad: cifrado. En este punto, no se requiere ningún cumplimiento de directivas en
esta área. Se revisará durante las iteraciones posteriores.
Aplicación de patrones definidos por gobernanza
El equipo de gobernanza de la nube será responsable de las siguientes decisiones e implementaciones. Muchas
requieren aportaciones de otros equipos, pero es probable que el equipo de gobernanza de la nube sea el
responsable de la decisión y la implementación. En las siguientes secciones se describen las decisiones tomadas
para este caso de uso y los detalles de cada decisión.
Detalles de la suscripción
La decisión sobre qué diseño de suscripción usar determina cómo se estructuran las suscripciones de Azure y
cómo se usarán los grupos de administración de Azure para administrar de forma eficaz el acceso, las directivas
y el cumplimiento de estas suscripciones. En este ejemplo, el equipo de gobernanza ha elegido una estrategia de
suscripción mixta.
Cuando surjan nuevas solicitudes de recursos de Azure, se debe establecer un departamento para cada
unidad de negocio principal en cada ubicación geográfica operativa. Dentro de cada uno de los
departamentos, deben crearse suscripciones para cada arquetipo de aplicación.
Un arquetipo de aplicación es una forma de agrupar las aplicaciones con necesidades similares. Algunos
ejemplos frecuentes son:
Aplicaciones con datos protegidos, aplicaciones reguladas (por ejemplo, HIPAA o FedRAMP)
Aplicaciones de bajo riesgo
Aplicaciones con dependencias locales
SAP u otras aplicaciones centrales en Azure
Aplicaciones que amplían SAP o aplicaciones centrales locales
Cada organización tiene necesidades únicas según las clasificaciones de datos y los tipos de aplicaciones
que respaldan al negocio. La asignación de dependencias del patrimonio digital puede ayudar a definir
los arquetipos de aplicación en una organización.
Debe adoptarse una convención de nomenclatura común como parte del diseño de la suscripción, en
función de la información anterior.
Las decisiones relacionadas con la coherencia de los recursos determinan las herramientas, los procesos y el
esfuerzo necesarios para garantizar que los recursos de Azure se implementan, configuran y administran de
forma coherente dentro de una suscripción. En este caso, se ha elegido el patrón coherencia de la
implementación como el principal patrón de coherencia de los recursos.
Los grupos de recursos se crean para las aplicaciones que usan el enfoque del ciclo de vida. Todo lo que se
crea, mantiene y retira de forma conjunta debe residir en un único grupo de recursos. Para más información,
vea la Guía de decisiones de la coherencia de recursos.
Azure Policy se debe aplicar a todas las suscripciones del grupo de administración asociado.
Como parte del proceso de implementación, las plantillas de coherencia de recursos de Azure para el grupo
de recursos deben almacenarse en el control de código fuente.
Cada grupo de recursos se asocia con una aplicación o carga de trabajo específica que se basa en el enfoque
del ciclo de vida que se indicó anteriormente.
Los grupos de administración de Azure permiten actualizar los diseños de gobernanza a medida que madura
la directiva corporativa.
La amplia implementación de Azure Policy podría superar los compromisos temporales del equipo y es
posible que no aporte un gran valor en este momento. Debe crearse una directiva predeterminada simple y
aplicarse a cada grupo de administración para hacer cumplir el pequeño número de instrucciones de la
directiva de gobernanza en la nube. Esta directiva definirá la implementación de los requisitos de gobernanza
específicos. Esas implementaciones pueden aplicarse a todos los recursos implementados.
IMPORTANT
Siempre que un recurso de un grupo deje de compartir el mismo ciclo de vida, se debe trasladar a otro grupo de recurso.
Entre los ejemplos se incluyen bases de datos y componentes de red habituales. Aunque pueden servir a la aplicación que
se está desarrollando, también pueden servir para otros fines y, por tanto, existir en otros grupos de recursos.
Las decisiones sobre el etiquetado de recursos determinan cómo se aplican los metadatos a los recursos de
Azure de una suscripción con fines operativos, administrativos y contables. En este caso, se ha elegido el patrón
contabilidad como modelo predeterminado del etiquetado de recursos.
Los recursos implementados se deben etiquetar con valores para:
Departamentos o unidad de facturación
Geography
Entorno
Arquetipo de aplicación
Application
Propietario de la aplicación
Estos valores, junto con el grupo de administración y la suscripción de Azure asociados con un recurso
implementado impulsarán las decisiones de gobernanza, operaciones y seguridad.
Registro e informes
Las decisiones sobre registro e informes determinan cómo el almacén registra los datos y cómo se estructuran
las herramientas de supervisión e informe que mantienen al personal de TI informado del estado operativo. En
este caso, se sugiere un patrón de supervisión híbrida para el registro y los informes, pero no es obligatorio
para ningún equipo de desarrollo en este momento.
Actualmente, no hay establecido ningún requisito de gobernanza con respecto a los puntos de datos
específicos que deben recopilarse para fines de registro o informes. Esto es específico de esta narración
ficticia y debe considerarse un antipatrón. Los estándares de registro deben determinarse y cumplirse tan
pronto como sea posible.
Antes de admitir datos protegidos o cargas de trabajo críticas, a la solución de supervisión operativa local
existente se le debe conceder acceso al área de trabajo que se usó para el registro. Las aplicaciones deben
satisfacer los requisitos de seguridad y registro asociados al uso de ese inquilino, si la aplicación contará con
un SLA definido.
Mejora gradual de los procesos de gobernanza

Algunas de las instrucciones de directiva no pueden o no deben controlarse mediante herramientas
automatizadas. Otras directivas exigirán un esfuerzo periódico de los equipos de seguridad de TI y de base de
referencia de identidad local. El equipo de gobernanza de la nube deberá supervisar los siguientes procesos
para implementar las últimas ocho declaraciones de las directivas:
Cambios en la directiva corporativa: El equipo de gobernanza de la nube hará cambios en el diseño del
producto viable mínimo de gobernanza para adoptar las nuevas directivas. El valor del MVP de gobernanza es
que permitirá el cumplimiento automático de las nuevas directivas.
Aceleración de la adopción: El equipo de gobernanza de la nube ha estado revisando los scripts de
implementación de varios equipos. Ha mantenido un conjunto de scripts que actúan como plantillas de
implementación. Los equipos de adopción de la nube y los equipos de DevOps pueden usar esas plantillas para
definir más rápidamente las implementaciones. Cada script contiene los requisitos para hacer cumplir las
directivas de gobernanza, y no es necesario un esfuerzo adicional por parte de los ingenieros de adopción de la
nube. Como curadores de estos scripts, pueden implementar más rápidamente los cambios de directiva.
Además, se los considera aceleradores de la adopción. Esto garantiza implementaciones coherentes sin que se
aplique la adhesión de manera estricta.
Aprendizaje para ingenieros: El equipo de gobernanza de la nube ofrece sesiones de aprendizaje cada dos
meses y ha creado dos vídeos para ingenieros. Ambos recursos ayudan a los ingenieros a ponerse al día
rápidamente con la cultura de gobernanza y con cómo se realizan las implementaciones. El equipo está
agregando recursos de aprendizaje para mostrar las diferencias entre las implementaciones de producción y las
que no son de producción, lo que ayuda a los ingenieros a comprender la manera en que las nuevas directivas
afectan a la adopción. Esto garantiza implementaciones coherentes sin que se aplique la adhesión de manera
estricta.
Planeación de la implementación: Antes de la implementación de cualquier recurso que contenga datos
protegidos, el equipo de gobernanza de la nube será responsable de revisar los scripts de implementación para
validar la alineación de gobernanza. Se auditará a los equipos existentes con implementaciones previamente
aprobadas, mediante herramientas de programación.
Auditoría mensual e informes: Cada mes, el equipo de gobernanza realiza una auditoría de todas las
implementaciones de la nube para validar la alineación continua con las directivas. Cuando se detectan
divergencias, se documentan y comparten con los equipos de la adopción de la nube. Cuando el cumplimiento
no pone en riesgo una interrupción del negocio ni una pérdida de datos, las directivas se cumplen
automáticamente. Al final de la auditoría, el equipo de gobernanza de la nube compila un informe para el
equipo de estrategia de la nube y cada equipo de adopción de la nube para comunicar la adhesión general a las
directivas. El informe también se almacena con fines de auditoría y legales.
Revisión trimestral de la directiva: Cada trimestre, el equipo de gobernanza de la nube y el equipo de
estrategia de la nube revisan los resultados de la auditoría y sugieren cambios relacionados con la directiva
corporativa. Muchas de las sugerencias son consecuencia de mejoras continuas y de la observación de los
patrones de uso. Los cambios aprobados en la directiva se integran en las herramientas de gobernanza durante
los ciclos de auditoría subsiguientes.
Patrones alternativos
Si cualquiera de los patrones seleccionados en esta guía de gobernanza no se adapta a los requisitos del lector,
existen otras alternativas para cada patrón:
Patrones de cifrado
Patrones de identidad
Patrones de registro e informes
Patrones de cumplimiento de directivas
Patrones de coherencia de recursos
Patrones de redes definidos por software
Patrones de diseño de suscripciones
Pasos siguientes
Una vez que se implemente esta guía, cada equipo de adopción de la nube puede continuar con una base sólida
de gobernanza. Al mismo tiempo, el equipo de gobernanza de la nube trabajará para actualizar continuamente
las directivas corporativas y las materias de gobernanza.
Ambos equipos usarán los indicadores de tolerancia para identificar el próximo conjunto de mejoras necesario
para seguir impulsando la adopción de la nube. El siguiente paso para la empresa es la mejora gradual de su
línea de base de gobernanza para dar servicio a aplicaciones con requisitos de autenticación multifactor
heredada o de terceros.
En este artículo se desarrolla la narración al agregar controles de base de referencia de identidad al producto
viable mínimo de gobernanza.
El director financiero aprobó la justificación empresarial para la migración a la nube de los dos centros de datos.
Durante el estudio de viabilidad técnica, se detectaron varios obstáculos:
Los datos protegidos y las aplicaciones críticas representan el 25 % de las cargas de trabajo en los dos
centros de datos. No se puede eliminar ninguno hasta que las directivas de gobernanza actuales con
respecto a la información personal confidencial y a las aplicaciones críticas se hayan modernizado.
El 7 % de los recursos de esos centros de datos no son compatibles con la nube. Se moverán a un centro de
datos alternativo antes de la finalización del contrato del centro de datos.
El 15 % de los recursos en el centro de datos (750 máquinas virtuales) tiene una dependencia en la
autenticación heredada o autenticación multifactor de terceros.
La conexión VPN que se conecta a Azure y a los centros de datos existentes no ofrece suficientes velocidades
de transmisión de datos ni la latencia para migrar el volumen de recursos dentro del plazo de dos años para
retirar el centro de datos.
Los dos primeros obstáculos se están administrando en paralelo. En este artículo se abordará la resolución del
tercer y cuarto obstáculos.
Expansión del equipo de gobernanza de la nube
El equipo de gobernanza de la nube se está expandiendo. Dada la necesidad de soporte adicional con respecto a
la administración de identidades, un administrador del sistema del equipo de la base de referencia de identidad
ahora participa en una reunión semanal para mantener a los miembros del equipo existente al tanto de los
cambios.
El equipo de TI tiene la aprobación para seguir adelante con los planes del director de información (CIO) y del
director financiero (CFO) para retirar dos centros de datos. Al equipo le preocupa que 750 máquinas virtuales
(el 15 % de los recursos) de esos centros de datos tendrán que moverse a algún lugar distinto de la nube.
Los nuevos planes de estado futuro requieren una solución más sólida de base de referencia de identidad para
migrar las 750 máquinas virtuales con los requisitos de autenticación heredados. Más allá de estos dos centros
de datos, es previsible que este problema afecte a un porcentaje similar de recursos en otros centros de datos.
El estado futuro ahora también requiere una conexión desde el proveedor de nube a la solución MPLS o de línea
dedicada de la empresa.
directiva.

Interrupción del negocio durante la migración. La migración a la nube crea un riesgo controlado y
temporal que se puede administrar. El traslado de hardware antiguo a otra parte del mundo es un riesgo mucho
mayor. Se necesita una estrategia de mitigación para evitar las interrupciones en las operaciones empresariales.
Dependencias de identidad existentes. Las dependencias en los servicios existentes de autenticación e
identidad pueden retrasar o impedir la migración de algunas cargas de trabajo a la nube. La incapacidad de
devolver los dos centros de datos a tiempo generará millones de dólares en las tarifas de concesión de centros
de datos.
La autenticación heredada puede no estar disponible en la nube, lo que limita la implementación de algunas
aplicaciones.
La solución actual de autenticación multifactor de terceros puede no estar disponible en la nube, lo que limita
la implementación de algunas aplicaciones.
Cambiar sus herramientas o moverlas podría crear interrupciones y sumar costos.
La velocidad y la estabilidad de la VPN podrían impedir la migración.
El tráfico de entrada en la nube podría producir problemas de seguridad en otras partes de la red global.

implementación.
El proveedor de nube elegido debe ofrecer un medio de autenticación a través de métodos heredados.
El proveedor de nube elegido debe ofrecer un medio de autenticación con la solución actual de autenticación
multifactor de terceros.
Debe establecerse una conexión privada de alta velocidad entre el proveedor de nube y el proveedor de
telecomunicaciones de la empresa, que conecte al proveedor de nube con la red mundial de centros de
datos.
Hasta que no se establezcan requisitos de seguridad suficientes, ningún tráfico público entrante podrá
acceder a los recursos de la empresa hospedados en la nube. Todos los puertos se bloquean desde cualquier
origen fuera de la WAN global.

El diseño del producto viable mínimo de gobernanza cambia para incluir nuevas directivas de Azure y una
implementación de Active Directory en una máquina virtual. Juntos, estos dos cambios de diseño cumplen con
las nuevas instrucciones de directiva corporativa.
Estos son los nuevos procedimientos recomendados:
Plano técnico de la red vir tual híbrida segura : El lado local de la red híbrida debe configurarse para
permitir la comunicación entre la siguiente solución y los servidores locales de Active Directory. Este
procedimiento recomendado requiere una red perimetral para habilitar Active Directory Domain Services
más allá de los límites de la red.
Plantillas de Azure Resource Manager :
1. Defina un grupo de seguridad de red para bloquear el tráfico externo y permitir el interno.
2. Implemente dos máquinas virtuales de Active Directory en un par con equilibrio de carga basado en
una imagen maestra. En el primer arranque, esa imagen ejecuta un script de PowerShell para unirse al
dominio y registrarse en los servicios de dominio. Para más información, consulte Extensión de Active
Directory Domain Services (AD DS) a Azure.
Azure Policy: aplique el NSG a todos los recursos.
Azure Blueprints:
1. Cree un plano técnico denominado active-directory-virtual-machines .
2. Agregue cada una de las directivas y plantillas de Active Directory al plano técnico.
3. Publique el plano técnico en cualquier grupo de administración correspondiente.
4. Aplique el plano técnico a cualquier suscripción que requiera autenticación multifactor de terceros o
heredada.
5. Ahora se puede usar la instancia de Active Directory que se ejecuta en Azure como extensión de la
solución local de Active Directory, lo que le permite integrarse en la herramienta de autenticación
multifactor existente y proporcionar autenticación basada en notificaciones, ambas a través de la
funcionalidad de Active Directory existente.
Conclusión
Agregar estos cambios al producto viable mínimo de gobernanza ayuda a solucionar muchos de los riesgos
indicados en este artículo, lo que permite a cada equipo de adopción de la nube superar rápidamente este
obstáculo.
Pasos siguientes
riesgos y necesidades de gobernanza de la nube. Las siguientes son algunos cambios que pueden presentarse.
Para esta empresa ficticia, el siguiente desencadenador es la inclusión de datos protegidos en el plan de
adopción de la nube. Este cambio requiere controles de seguridad adicionales.
Mejora de la materia de base de referencia de la
seguridad
En este artículo se detalla el método de adición de controles de seguridad que ayudan al traslado de datos
protegidos a la nube.
El director de sistemas de información lleva meses colaborando con sus colegas y el personal del departamento
jurídico de la empresa. Se contrató un consultor de administración con experiencia en ciberseguridad para
ayudar a los equipos de seguridad y gobernanza de TI a redactar una nueva directiva con respecto a los datos
protegidos. El grupo pudo promover el apoyo de la dirección para reemplazar las directivas existentes,
permitiendo así que los proveedores de nube aprobados hospeden los datos financieros y la información
personal confidencial. Debido a ello, es necesario adoptar un conjunto de requisitos de seguridad y un proceso
de gobernanza para comprobar y documentar el cumplimiento de esas directivas.
Durante los últimos 12 meses, los equipos de adopción en la nube han retirado la mayoría de los 5000 recursos
de los dos centros de datos. Por su parte, los 350 recursos incompatibles se llevaron a un centro de datos
alternativo. Así pues, solo quedan las 1250 máquinas virtuales que contienen los datos protegidos.
Cambios en el equipo de gobernanza de la nube
El equipo de gobernanza de la nube continúa cambiando a medida que avanza la historia. Los dos miembros
fundadores del equipo se encuentran ahora entre los arquitectos en la nube más respetados de la empresa. La
colección de scripts de configuración ha crecido a medida que los nuevos equipos abordan nuevas e
innovadoras implementaciones. El equipo de gobernanza de la nube también ha crecido. Hace poco, los
miembros del equipo de operaciones de TI se unieron a las actividades del equipo de gobernanza de la nube
para prepararse para las operaciones en la nube. Asimismo, los arquitectos en la nube que ayudaron a fomentar
esta comunidad son ahora los administradores y aceleradores que revolucionaron y agilizaron la nube.
Aunque la diferencia es sutil, es una distinción importante al crear una cultura de TI centrada en la gobernanza.
Un administrador en la nube se encarga de solucionar los problemas que crean los arquitectos en la nube con
sus innovaciones, así que se puede decir que estos dos roles tienen objetivos encontrados. Un administrador en
la nube ayuda a mantener la nube segura, para que los arquitectos en la nube puedan moverse rápidamente y
crear menos problemas. Un acelerador de la nube realiza ambas funciones, pero también participa en la
creación de plantillas para acelerar la implementación y la adopción, convirtiéndose así en un acelerador de
innovaciones y en un defensor de las cinco materias de gobernanza de la nube.
En la fase anterior de esta historia, la compañía había comenzado el proceso de retirar dos centros de datos. Este
trabajo continuo incluye la migración de algunas aplicaciones con requisitos de autenticación heredados, que
requirieron mejoras graduales de la base de referencia de identidad, como se ha descrito en el artículo anterior.
Miles de recursos de TI y de negocios se han implementado en la nube.
El equipo de desarrollo de aplicaciones ha implementado una canalización de integración e implementación
continua (CI/CD) para implementar una aplicación nativa en la nube y así poder ofrecer una experiencia de
usuario mejorada. Dado que la aplicación aún no interactúa con los datos protegidos, no está lista para la
producción.
El equipo de inteligencia empresarial de TI mantiene activamente los datos en la nube de terceros, inventario
y logística. Estos datos se emplean para impulsar nuevas predicciones, que podrían dar forma a procesos
empresariales. No se puede actuar sobre las predicciones y conclusiones hasta que los datos de cliente y
financieros puedan integrarse en la plataforma de datos.
El equipo de TI hace progresos en los planes del Director de sistemas de información y del Director
financiero de retirar dos centros de datos. Casi 3500 recursos de los dos centros de datos han sido retirados
o migrados.
Las directivas relativas a la información personal y financiera confidencial se han modernizado. Las nuevas
directivas corporativas están supeditadas a la implementación de directivas de seguridad y de gobernanza
relacionadas. Así que los equipos siguen estancados.
Los primeros experimentos de los equipos de desarrollo de aplicaciones y BI han mostrado mejoras
potenciales en las experiencias de los clientes y las decisiones basadas en datos. Ambos equipos quieren
expandir la adopción de la nube en los próximos 18 meses mediante la implementación de esas soluciones
en producción.
Asimismo, el quipo de TI ha desarrollado una justificación comercial para migrar cinco centros de datos más
a Azure, lo que reducirá aún más los costos de TI y proporcionará una mayor agilidad empresarial. Aunque
es menor en escala, se espera que la retirada de esos centros de datos duplique el ahorro en cuanto a costos
totales.
Los presupuestos de gastos de capital y gastos operativos se han aprobado para implementar las directivas,
herramientas y procesos de seguridad y gobernanza requeridos. Los ahorros de costos esperados al retirar el
centro de datos son más que suficientes para pagar esta nueva iniciativa. Los líderes de TI y de negocios
confían en que esta inversión acelerará la realización de devoluciones en otras áreas. El equipo comunitario
de gobernanza de la nube se convirtió en un equipo reconocido con directivos y personal dedicados.
En conjunto, los equipos de adopción de la nube, el equipo de gobernanza de la nube, el equipo de seguridad
de TI y el equipo de gobernanza de TI implementan los requisitos de gobernanza y seguridad para permitir
que los equipos de adopción de la nube migren datos protegidos a la nube.

Vulneración de datos: Existe un aumento inherente en las responsabilidades relacionadas con las
vulneraciones de datos al adoptar cualquier nueva plataforma de datos. Los técnicos que adoptan las
tecnologías de la nube tienen mayores responsabilidades para implementar soluciones que puedan reducir este
riesgo. Para asegurarse de que los técnicos cumplen con estas responsabilidades se debe implementar una
estrategia eficaz de seguridad y gobernanza.
1. Se podrían implementar aplicaciones críticas o datos protegidos de forma no intencionada.
2. Los datos protegidos podrían exponerse durante el almacenamiento debido a decisiones de cifrado
deficiente.
3. Usuarios no autorizados podrían tener acceso a datos protegidos.
4. Podrían producirse intrusiones externas a datos protegidos.
5. Las intrusiones externas o ataques por denegación de servicio podrían provocar una interrupción del
negocio.
6. Los cambios de la organización o empleo podrían permitir el acceso no autorizado a los datos protegidos.
7. Las nuevas vulnerabilidades de seguridad podrían crear oportunidades para la intrusión o el acceso no
autorizado.
10. Diversos dispositivos perimetrales podrían aumentar los costos de operación de la red.
11. Diversas opciones de configuración de dispositivos podrían provocar negligencias en la configuración y la
seguridad podría verse comprometida.
12. El equipo de ciberseguridad insiste en que existe el riesgo de que un proveedor no genere claves de cifrado
en la plataforma de un solo proveedor de nube. Si bien esta afirmación no está demostrada, el equipo la
acepta por el momento.

implementación. La lista es larga, pero la adopción de estas directivas podría ser más fácil de lo que parece.
1. Todos los recursos implementados deben categorizarse por importancia y clasificación de datos. Asimismo,
el equipo de gobernanza de la nube y el propietario de la aplicación deben revisar las clasificaciones antes de
realizar la implementación en la nube.
2. Las aplicaciones que almacenan o acceden a datos protegidos se deben administrar de manera diferente de
las demás. Como mínimo, deben segmentarse para evitar el acceso no intencionado de los datos protegidos.
3. todos los datos protegidos deben estar cifrados cuando están en reposo.
4. Los permisos elevados en los segmentos que contienen datos protegidos deben ser una excepción. Estas
excepciones se registrarán con el equipo de gobernanza de la nube y se auditarán periódicamente.
5. las subredes que contengan datos protegidos deben aislarse de las otras subredes. El tráfico de red entre
subredes de datos protegidos se auditará periódicamente.
6. No se podrá tener acceso a ninguna subred que contenga datos protegidos directamente a través de Internet
o entre centros de datos. El acceso a estas subredes debe enrutarse a través de subredes intermedias. Todo
acceso a estas subredes debe realizarse a través de una solución de firewall que pueda realizar funciones de
análisis y bloqueo de paquetes.
7. Las herramientas de gobernanza deben auditar y aplicar los requisitos de configuración de red definidos por
aprobadas.
9. Siempre que sea posible, la administración de configuración de nodos debe aplicar los requisitos de directiva
a la configuración de cualquier sistema operativo invitado. La administración de configuración de nodos
debe respetar la inversión existente en el objeto de directiva de grupo (GPO) para la configuración de
recursos.
10. Las herramientas de gobernanza deben auditar las actualizaciones automáticas para que estén habilitadas en
todos los recursos implementados. Cuando sea posible, se aplicarán las actualizaciones automáticas. Cuando
las herramientas no puedan aplicar esto, las infracciones deben revisarse con los equipos de administración
de operaciones y corregirse de acuerdo a las directivas de operaciones. Los recursos que no se actualicen
automáticamente deben incluirse en procesos que sean propiedad de operaciones de TI.
11. La creación de nuevas suscripciones o grupos de administración para las aplicaciones críticas o datos
protegidos requiere una revisión del equipo de gobernanza de la nube para garantizar que se ha asignado el
plano técnico correcto.
12. Un modelo de acceso con privilegios mínimos se aplicará a cualquier suscripción que contenga aplicaciones
críticas o datos protegidos.
13. El proveedor en la nube debe ser capaz de integrar las claves de cifrado que administra la solución del
entorno local existente.
14. El proveedor en la nube debe ser capaz de admitir la solución de dispositivos perimetrales existente, así
como cualquier configuración requerida para proteger cualquier límite de red expuesto públicamente.
15. El proveedor en la nube debe ser capaz de admitir una conexión compartida a la red WAN global, con la
transmisión de datos enrutada a través de la solución de dispositivos perimetrales existente.
las implementaciones en la nube para proporcionar actualizaciones a las herramientas de la base de
referencia de seguridad que se usan en la nube.
gobernanza en curso de los recursos implementados. 18. Los scripts de implementación deben conservarse
en un repositorio central accesible para el equipo de gobernanza de la nube, y que así se puedan revisar y se
realicen auditorías periódicas.
19. la implementación de las aplicaciones que requieren autenticación de cliente debe usar un proveedor de
identidades aprobado que sea compatible con el proveedor de identidades principal para usuarios internos.
1. Los procesos de gobernanza en la nube deben incluir revisiones trimestrales con los equipos de la base de
referencia de identidad para así poder identificar usuarios malintencionados o patrones de uso que deban
evitarse mediante la configuración de recursos en la nube.

En esta sección se modifica el diseño de un producto viable mínimo de gobernanza para incluir nuevas
directivas de Azure y una implementación de Azure Cost Management + Billing. Juntos, estos dos cambios de
diseño cumplirán con las nuevas declaraciones de directiva corporativa.
Los nuevos procedimientos recomendados se dividen en dos categorías: TI corporativa (centro de conectividad)
y adopción de la nube (radios).
Establecimiento de una suscripción de tipo hub-and-spoke de TI empresarial para centralizar la
base de referencia de seguridad : En este procedimiento recomendado, la capacidad de gobernanza
existente está encapsulada mediante una topología de tipo hub-and-spoke con servicios compartidos, además
de algunas adiciones clave del equipo de gobernanza de la nube.
1. Repositorio de Azure DevOps. Cree un repositorio en Azure DevOps para almacenar y edite todas las
plantillas de Azure Resource Manager pertinentes y configuraciones con script.
2. Plantilla de topología de red en estrella tipo hub-and-spoke:
a. La guía de la arquitectura de referencia sobre la topología de red en estrella tipo hub-and-spoke con
servicios compartidos se puede usar para generar plantillas de Resource Manager para los recursos
necesarios de un centro de TI de empresa.
b. Gracias a esas plantillas, esta estructura puede repetirse como parte de una estrategia de gobernanza
central.
c. Además de la arquitectura de referencia actual, se debe crear una plantilla de grupo de seguridad de
red que capture los requisitos de bloqueo de puertos o de listas blancas para que la red virtual
hospede el firewall. Este grupo de seguridad de red difiere de los grupos anteriores, porque será el
primer grupo de seguridad de red que permita el tráfico público hacia una red virtual.
3. Crear directivas de Azure. Cree una directiva denominada hub NSG enforcement para aplicar la configuración
del grupo de seguridad de red asignado a cualquier red virtual creada en esta suscripción. Aplique las
directivas integradas para la configuración de invitado de la manera siguiente:
a. Confirme que los servidores web de Windows usan protocolos de comunicación segura.
b. Confirme que la configuración de seguridad de contraseñas es correcta en máquinas de Linux y
Windows.
4. Cree el plano técnico de TI corporativo.
a. Cree un plano técnico de Azure denominado corporate-it-subscription .
b. Agregue las plantillas de la topología en estrella tipo hub-and-spoke y la directiva
hub NSG enforcement .
5. Ampliar la jerarquía inicial del grupo de administración.
a. Para cada grupo de administración que ha solicitado soporte técnico para los datos protegidos, el
plano técnico corporate-it-subscription-blueprint proporciona una solución de centro acelerada.
b. Debido a que los grupos de administración en este ejemplo ficticio incluyen una jerarquía regional
además de una jerarquía de unidades de negocio, este plano técnico se implementará en cada región.
c. Cree una suscripción denominada corporate IT subscription para cada región de la jerarquía del
d. Aplique el plano técnico corporate-it-subscription-blueprint a cada instancia regional.
e. Esto establecerá un centro para cada unidad de negocio de cada región. Nota: Se podrían lograr
mayores ahorros de costos al compartir centros en las unidades de negocio de cada región.
6. Integre los objetos de directivas de grupo (GPO) mediante Desired State Configuration (DSC):
a. Convierta el GPO en DSC. El proyecto de Microsoft de administración de base de referencia en GitHub
puede acelerar este proceso. Asegúrese de guardar DSC en el repositorio en paralelo con las plantillas
de Resource Manager.
b. Implemente la configuración de estado de Azure Automation en cualquier instancia de la suscripción
de TI de empresa. Azure Automation se puede usar para aplicar DSC en máquinas virtuales
implementadas en las suscripciones compatibles del grupo de administración.
c. El plan de desarrollo tiene el objetivo de habilitar directivas personalizadas de configuración de
invitados. Cuando esa característica esté disponible, ya no será necesario usar Azure Automation en
este procedimiento recomendado.
Aplicación de una gobernanza adicional a una suscripción de adopción de la nube (spoke) : Sobre la
base que ofrece corporate IT subscription , los cambios menores en el producto viable mínimo de gobernanza
aplicados a cada suscripción dedicada al apoyo de arquetipos de aplicaciones pueden producir rápidas mejoras.
En cambios iterativos anteriores del procedimiento recomendado, se definieron grupos de seguridad de red
para bloquear el tráfico público y permitir el tráfico interno. Además, el plano técnico de Azure creó
temporalmente las capacidades de DMZ y Active Directory. En esta iteración, ajustaremos esos recursos un
poco, para así poder crear una nueva versión del plano técnico de Azure.
1. Plantilla de emparejamiento de redes. Esta plantilla emparejará la red virtual de cada suscripción con la red
virtual del centro en la suscripción de TI de empresa.
a. En la arquitectura de referencia de la sección anterior, Topología en estrella de tipo hub-and-spoke con
servicios compartidos se generó una plantilla de Resource Manager para habilitar el emparejamiento
de red virtual.
b. Esa plantilla se puede usar como guía para modificar la plantilla de DMZ de la iteración de gobernanza
anterior.
c. Ahora vamos a agregar el emparejamiento de red virtual a la red virtual de DMZ que se conectó
previamente al dispositivo perimetral local a través de VPN.
d. También se debe eliminar la VPN de esta plantilla para garantizar que no se enrute el tráfico
directamente al centro de datos local sin pasar por la solución de firewall y la suscripción de TI
corporativa. También puede establecer esta VPN como un circuito de conmutación por error en caso
de una interrupción del circuito de ExpressRoute.
e. Azure Automation solicitará la configuración de red adicional para aplicar DSC a las máquinas
virtuales hospedadas.
2. Modifique el grupo de seguridad de red. Bloquee todo el tráfico local público y directo en el grupo de
seguridad de red. El único tráfico entrante debe venir a través de la red virtual del mismo nivel en la
suscripción de TI de empresa.
a. En la iteración anterior, se creó un grupo de seguridad de red que bloqueaba todo el tráfico público y
permitía todo el tráfico interno. Ahora queremos cambiar este grupo de seguridad de red un poco.
b. La nueva configuración del grupo de seguridad de red debería bloquear todo el tráfico público y todo
el tráfico del centro de datos local.
c. El tráfico que entra en esta red virtual solo debe proceder de la red virtual del otro lado de la red
virtual del mismo nivel.
3. Implementación de Azure Security Center:
a. Configure Azure Security Center para cualquier grupo de administración que contenga clasificaciones
b. Active de forma predeterminada el aprovisionamiento automático para garantizar el cumplimiento de
la aplicación de revisiones.
c. Establezca configuraciones de seguridad del sistema operativo. Seguridad de TI para definir la
configuración.
d. Habilite el soporte técnico para la seguridad de TI al usar por primera vez Azure Security Center.
Cambie el uso de Security Center a la seguridad de TI, pero mantenga el acceso para poder mejorar
continuamente la gobernanza.
e. Cree una plantilla de Resource Manager que refleje los cambios necesarios para la configuración de
Azure Security Center de una suscripción.
4. Actualice Azure Policy en todas las suscripciones.
a. Audite y exija la clasificación de datos y la importancia en todos los grupos de administración y
suscripciones, para identificar las suscripciones con clasificaciones de datos protegidos.
b. Audite y exija el uso exclusivo de imágenes del sistema operativo que se hayan aprobado.
c. Audite y exija el uso de las configuraciones de los huéspedes según los requisitos de seguridad de
cada nodo.
5. Actualice Azure Policy en todas las suscripciones que contengan clasificaciones de datos protegidos.
a. Audite y aplique solo el uso de roles estándar.
b. Audite y exija la aplicación del cifrado en todas las cuentas de almacenamiento y los archivos en
reposo de los nodos individuales.
c. Audite y fuerce la aplicación de la nueva versión del grupo de seguridad de red de DMZ.
d. Audite y exija el uso de la subred de la red aprobada y de la red virtual por interfaz de red.
e. Audite y exija que se aplique la limitación de las tablas de enrutamiento que defina el usuario.
6. Plano técnico de Azure:
a. Cree un plano técnico de Azure denominado protected-data .
b. Agregue las plantillas de la red virtual del mismo nivel, del grupo de seguridad de red y de Azure
Security Center al plano técnico.
c. Asegúrese de que la plantilla de Active Directory correspondiente a la iteración anterior no esté
incluida en el plano técnico. Cualquier dependencia de Active Directory la proporcionará la suscripción
de TI de empresa.
d. Finalice todas las máquinas virtuales de Active Directory implementadas en la iteración anterior.
e. Agregue las nuevas directivas para suscripciones de datos protegidos.
f. Publique el plano técnico en cualquier grupo de administración que vaya a hospedar datos
protegidos.
g. Aplique el nuevo plano técnico a cada suscripción afectada, además de los planos técnicos existentes.
Conclusión
Al agregar estos procesos y los cambios realizados en el producto viable mínimo de gobernanza, podrá
solucionar muchos de los riesgos asociados a la gobernanza de seguridad. Juntos, agregan herramientas de
supervisión de red, así como la identidad y la seguridad necesarias para proteger los datos.
Pasos siguientes
riesgos y necesidades de gobernanza de la nube. En cuanto a la empresa ficticia de esta guía, el paso siguiente
es dar servicio a las cargas de trabajo críticas. En este punto son necesarios los controles de coherencia de
recursos. Una parte fundamental de esta documentación sobre gobernanza de la seguridad es revisar los
procedimientos recomendados que Microsoft ha creado para la seguridad. La prueba comparativa de seguridad
de Azure (ASB) proporciona recomendaciones y procedimientos recomendados para ayudar a mejorar la
seguridad de las cargas de trabajo, los datos y los servicios de Azure. Obtenga más información aquí.
En este artículo, la narración avanza añadiendo controles de coherencia de los recursos al producto viable
mínimo de gobernanza para dar servicio a aplicaciones críticas.
Los equipos de la adopción de la nube han cumplido todos los requisitos para mover los datos protegidos. Esas
aplicaciones incluyen los compromisos del Acuerdo de Nivel de Servicio en relación con el negocio y la
necesidad de soporte para operaciones de TI. Justo detrás del equipo de migración de los dos centros de datos,
varios equipos de inteligencia empresarial y desarrollo de aplicaciones están listos para poner en marcha
nuevas soluciones en producción. El equipo de operaciones de TI no está familiarizado con las operaciones en la
nube y necesita integrar rápidamente los procesos operativos existentes.
El departamento de TI está moviendo activamente las cargas de trabajo de producción con datos protegidos
a Azure. Varias cargas de trabajo de prioridad baja atienden el tráfico de producción. Se podrán suprimir más
tan pronto como el equipo de operaciones de TI autorice la preparación para dar servicio a las cargas de
trabajo.
Los equipos de desarrollo de aplicaciones están preparados para el tráfico de producción.
El equipo de inteligencia empresarial está listo para integrar las predicciones y perspectivas en los sistemas
que ejecutan operaciones para las tres unidades de negocio.
El equipo de operaciones de TI no está familiarizado con las operaciones en la nube y necesita integrar
rápidamente los procesos operativos existentes.
directiva.

Interrupción del negocio: existe un riesgo inherente de que cualquier nueva plataforma cause interrupciones
en los procesos de negocio críticos. El equipo de operaciones de TI y los equipos que ejecutan tareas en diversas
adopciones de la nube tienen relativamente poca experiencia con las operaciones de la nube. Como esto
aumenta el riesgo de interrupción, hay que tomar medidas al respecto para solucionarlo y gobernarlo.
1. Los procesos operativos mal alineados podrían provocar interrupciones que no se pueden detectar ni mitigar
rápidamente.
2. Intrusiones externas o ataques por denegación de servicio podrían provocar una interrupción del negocio.
3. Los recursos críticos podrían no detectarse adecuadamente y, por lo tanto, podrían pasarse por alto.
4. Los recursos desconocidos o mal etiquetados podrían no ser compatibles con los procesos de administración
operativa existentes.
5. La configuración de los recursos implementados podría no satisfacer las expectativas de rendimiento.
6. Es posible que el registro no se haya anotado y centralizado correctamente para permitir la solución de
problemas de rendimiento.
7. Las directivas de recuperación podrían dar error o tardar más de lo esperado.
10. La configuración podría no aplicar los requisitos de los Acuerdos de Nivel de Servicio definidos o los
requisitos de recuperación confirmados.
11. Los sistemas operativos o aplicaciones implementados podrían no cumplir con los requisitos de protección
de la aplicación y el sistema operativo.
12. Existe un riesgo de incoherencia porque hay varios equipos que trabajan en la nube.

implementación. La lista es larga, pero la adopción de estas directivas podría ser más fácil de lo que parece.
1. Todos los recursos implementados deben categorizarse por importancia y clasificación de datos. El equipo de
gobernanza de la nube y el propietario de la aplicación deben revisar las clasificaciones antes de la
2. Las subredes que contienen aplicaciones críticas deben estar protegidas por una solución de firewall capaz
de detectar intrusiones y responder a los ataques.
3. las herramientas de gobernanza deben auditar y aplicar los requisitos de configuración de red definidos por
el equipo de la base de referencia de seguridad.
4. Las herramientas de gobernanza deben validar que todos los recursos relacionados con aplicaciones críticas
o datos protegidos se incluyen en la supervisión de la disminución y optimización de recursos.
5. Las herramientas de gobernanza deben validar que se recopila el nivel adecuado de datos de registro para
todas las aplicaciones críticas o datos protegidos.
6. El proceso de gobernanza debe validar que la copia de seguridad, la recuperación y el cumplimiento de los
aprobadas.
8. Las herramientas de gobernanza deben hacer cumplir que las actualizaciones automáticas se impidan en
todos los recursos implementados que admitan aplicaciones críticas. Las infracciones deben revisarse con los
equipos de administración de operaciones y corregirse de acuerdo con las directivas de operaciones. Los
recursos que no se actualicen automáticamente deben incluirse en procesos que sean propiedad del
departamento de operaciones de TI para actualizar de forma rápida y eficaz esos servidores.
9. Las herramientas de gobernanza deben validar el etiquetado relacionado con el costo, la importancia, el
Acuerdo de Nivel de Servicio, la aplicación y la clasificación de los datos. Todos los valores deben alinearse
con los valores predefinidos que administra el equipo de gobernanza de la nube.
las implementaciones en la nube para proporcionar actualizaciones a las herramientas de la base de
referencia de seguridad que se usan en la nube.
12. Antes de su publicación en producción, todas las aplicaciones críticas y los datos protegidos deben agregarse
a la solución de supervisión operativa designada. Los recursos que no pueden detectarse por las
herramientas de operaciones de TI elegidas no pueden liberarse para su uso en producción. Cualquier
cambio requerido para hacer que los recursos sean detectables debe aplicarse a los procesos de
implementación correspondientes para garantizar que los recursos sean detectables en futuras
implementaciones.
13. Tras la detección, los equipos de administración operativa validarán el tamaño de los recursos para verificar
que estos cumplen con los requisitos de rendimiento.
15. Los scripts de implementación deben conservarse en un repositorio central accesible para el equipo de
gobernanza de la nube para su revisión y auditoría periódicas.
16. Los procesos de revisión de gobernanza deben validar que los recursos implementados se configuren
correctamente de acuerdo con el Acuerdo de Nivel de Servicio y los requisitos de recuperación.

En esta sección del artículo se mejorará el diseño de un producto mínimo viable de gobernanza para que
incluya nuevas directivas de Azure y una implementación de Azure Cost Management + Billing. Juntos, estos
dos cambios de diseño cumplirán con las nuevas declaraciones de directiva corporativa.
Después de la experiencia de este ejemplo ficticio, se supone que ya se han producido los cambios de los datos
protegidos. A partir de este procedimiento recomendado, a continuación se agregarán los requisitos de
supervisión operativa, preparando una suscripción para aplicaciones críticas.
Suscripción de TI corporativa: agregue lo siguiente a la suscripción de TI corporativa, que actúa como un
centro.
1. Como una dependencia externa, el equipo de operaciones de la nube deberá definir herramientas de
supervisión operativa, herramientas de continuidad empresarial y recuperación ante desastres y
herramientas de corrección automatizadas. El equipo de gobernanza de la nube podrá entonces dar servicio
a los procesos de detección necesarios.
a. En este caso de uso, el equipo de operaciones de la nube eligió Azure Monitor como herramienta
principal para la supervisión de aplicaciones críticas.
b. El equipo eligió también Azure Site Recovery como herramienta principal de continuidad empresarial
y recuperación ante desastres.
2. Implementación de Azure Site Recovery.
a. Defina e implemente el almacén de Azure Site Recovery para los procesos de copia de seguridad y
recuperación.
b. Cree una plantilla de Azure Resource Manager para crear un almacén en cada suscripción.
3. Implementación de Azure Monitor.
a. Una vez que se identifica una suscripción crítica, se puede crear un área de trabajo de Log Analytics.
Suscripción de adopción de la nube individual : con el proceso siguiente se asegurará que cada
suscripción sea detectable por la solución de supervisión y esté lista para incluirse en las prácticas de
continuidad empresarial y recuperación ante desastres.
1. Azure Policy para nodos críticos:
a. Audite y aplique solo el uso de roles estándar.
b. Audite y aplique la aplicación de cifrado para todas las cuentas de almacenamiento.
c. Audite y exija el uso de la subred de la red aprobada y de la red virtual por interfaz de red.
d. Audite y exija que se aplique la limitación de las tablas de enrutamiento que defina el usuario.
e. Audite y aplique la implementación de agentes de Log Analytics para máquinas virtuales Windows y
Linux.
2. Azure Blueprints:
a. Cree un plano técnico denominado mission-critical-workloads-and-protected-data . Este plano técnico
aplicará recursos además del plano técnico de datos protegidos.
b. Agregue las nuevas directivas de Azure al plano técnico.
c. Aplique el plano técnico a las suscripciones que se espera que alojen una aplicación crítica.
Conclusión
La adición de estos procesos y cambios realizados en el producto viable mínimo de gobernanza ayudan a
corregir muchos de los riesgos asociados con la gobernanza de recursos. Juntos, agregan los controles de
recuperación, tamaño y supervisión necesarios para permitir las operaciones basadas en la nube.
Pasos siguientes
riesgos y necesidades de gobernanza de la nube. Para la compañía ficticia de esta guía, el siguiente
desencadenador se da cuando la escala de implementación supera los 1000 recursos en la nube o el gasto
mensual supera los 10 000 USD al mes. En este punto, el equipo de gobernanza de la nube agrega controles de
En este artículo, la narración avanza agregando controles de costos a los mecanismos de gobernanza del
producto viable mínimo.
La adopción ha crecido superando el indicador de tolerancia definido en el MVP para la gobernanza. Los
aumentos en el gasto ahora justifican una inversión de tiempo por parte del equipo de gobernanza de la nube
para supervisar y controlar los patrones de gasto.
En tanto que impulsor claro de la innovación, el departamento de TI ya no se percibe principalmente como un
centro de coste. A medida que la organización de TI genera más valor, el director de sistemas de información y el
director financiero acuerdan que es el momento de cambiar el papel que desempeña el equipo de TI en la
empresa. Entre otros cambios, el director financiero desea probar un enfoque de pago directo para la
contabilidad en la nube destinado a la sucursal canadiense de una de las unidades empresariales. Uno de los
dos centros de datos retirados eran recursos hospedados exclusivamente para las operaciones en Canadá de
esa unidad empresarial. En este modelo, se facturará directamente a la filial canadiense de la unidad empresarial
por los gastos operativos relacionados con los recursos hospedados. Este modelo permite que el equipo de TI se
centre menos en la administración del gasto de los demás y más en la creación de valor. Para que pueda
comenzar esta transición, es necesario que las herramientas de administración de costos estén en vigor.
En la fase anterior de esta narración, el equipo de TI movía activamente las cargas de trabajo de producción con
datos protegidos a Azure.
Se quitaron 5000 recursos de los dos centros de datos marcados para la retirada. Los departamentos de
adquisiciones y de seguridad de TI ahora están desaprovisionando los recursos físicos restantes.
Los equipos de desarrollo de aplicaciones han implementado canalizaciones de CI/CD para implementar
algunas aplicaciones nativas en la nube, lo cual afecta significativamente a la experiencia del cliente.
El equipo de inteligencia empresarial ha creado procesos de agregación, protección, conocimiento y
predicción que generan beneficios tangibles para las operaciones comerciales. Estas predicciones están
dando ahora lugar a nuevos productos y servicios creativos.
La supervisión de costos y los informes se deben agregar a la solución en la nube. Los informes deben vincular
los gastos operativos directos a las funciones que consumen los costos de la nube. Los informes adicionales
deben permitir que el departamento de TI supervise los gastos y proporcione orientación técnica sobre la
administración de costos. En el caso de la sucursal canadiense, se facturará directamente al departamento.
Cambios en los riesgos

Control del presupuesto: Existe un riesgo inherente de que las capacidades de autoservicio generen costos
excesivos e inesperados en la nueva plataforma. Los procesos de gobernanza para la supervisión de los costos y
la mitigación de los riesgos de costos continuos deben estar implementados para asegurar la alineación
continua con el presupuesto planeado.
Existe el riesgo de que los costos reales superen el plan.
Las condiciones empresariales cambian. Cuando lo hacen, habrá casos en que una función empresarial
necesite consumir más servicios en la nube de lo esperado, provocando anomalías en el gasto. Existe el
riesgo de que estos costos adicionales se consideren excesivos en lugar de un ajuste necesario para el plan.
Si se realiza correctamente, el experimento canadiense debe ayudar a corregir este riesgo.
Existe el riesgo de que se sobreaprovisionen los sistemas, lo que daría lugar a un exceso en los gastos.
Cambios en las declaraciones de directiva

implementación.
El equipo de gobernanza de la nube debe supervisar todos los costos de la nube en comparación con el plan
de forma semanal. Los informes sobre las desviaciones entre los costos en la nube y los del plan deben
compartirse con la dirección financiera y de TI mensualmente. Todos los costos de la nube y las
actualizaciones del plan se deben revisar mensualmente con los departamentos de finanzas y de TI.
Todos los costos deben asignarse a una función empresarial con fines de rendición de cuentas.
Se deben supervisar continuamente los recursos en la nube para detectar las oportunidades de optimización.
Las herramientas de gobernanza de la nube deben limitar las opciones de tamaño de los recursos a una lista
de configuraciones aprobadas. Las herramientas deben asegurarse de que todos los recursos sean
detectables y estén controlados por la solución de supervisión de costos.
Durante la planeación de la implementación, se deben documentar todos los recursos en la nube necesarios
asociados con el hospedaje de las cargas de trabajo de producción. Esta documentación ayudará a ajustar los
presupuestos y preparar las herramientas de automatización adicionales para impedir el uso de opciones
más costosas. Durante este proceso, debe prestarse atención a las diferentes herramientas de descuento que
ofrece el proveedor de servicios en la nube, como Azure Reserved VM Instances o reducciones en los costos
de la licencia.
Todos los propietarios de aplicaciones deben asistir a prácticas de aprendizaje para optimizar las cargas de
trabajo a fin de controlar mejor los costos de la nube.

En esta sección del artículo se mejorará el diseño de un producto mínimo viable de gobernanza para que
incluya nuevas directivas de Azure y una implementación de Azure Cost Management + Billing. Juntos, estos
dos cambios de diseño cumplirán con las nuevas declaraciones de directiva corporativa.
1. Realice cambios en el portal de Azure EA para facturar al administrador del departamento la implementación
canadiense.
2. Implemente Azure Cost Management + Billing.
a. Establezca el nivel adecuado de ámbito de acceso para alinearlo con el patrón de suscripción y el
patrón de agrupación de recursos. Asumiendo la alineación con el MVP de gobernanza definido en los
artículos anteriores, esto requeriría acceso al ámbito de la cuenta de inscripción para que el
equipo de gobernanza de la nube ejecute el informe general. Los equipos adicionales fuera de la
gobernanza, como el equipo de adquisiciones canadiense, requerirá acceso al ámbito del grupo de
recursos .
b. Establezca un presupuesto en Azure Cost Management + Billing.
c. Revise las recomendaciones iniciales y actúe sobre ellas. Cree un proceso periódico compatible con el
proceso de generación de informes.
d. Configure y ejecute los informes de Azure Cost Management + Billing, en el inicio y de manera
periódica.
3. Actualice Azure Policy.
a. Audite los valores de etiquetado, grupo de administración, suscripción y grupo de recursos para
identificar cualquier desviación.
b. Establezca las opciones de tamaño de SKU para limitar las implementaciones a las SKU que aparecen
en la documentación de la planeación de implementación.
Conclusión
La adición de los procesos anteriores y los cambios realizados en el producto viable mínimo de gobernanza
ayudan a corregir muchos de los riesgos asociados con la administración de los costos. Juntos, crean la
visibilidad, la responsabilidad y la optimización necesarias para controlar los costos.
Pasos siguientes
riesgos y necesidades de gobernanza de la nube. Para esta empresa ficticia, el siguiente paso es usar esta
inversión en gobernanza para administrar varias nubes.
Microsoft reconoce que los clientes pueden adoptar varias nubes para propósitos específicos. La empresa ficticia
de esta guía no es una excepción. Paralelamente al recorrido de adopción de Azure, el éxito del negocio ha
llevado a la adquisición de una empresa pequeña, pero complementaria. Ese negocio ejecuta todas sus
operaciones de TI en un proveedor de servicios en la nube diferente.
En este artículo se describen cómo cambian las cosas cuando se integra la nueva organización. A efectos de la
narrativa, asumimos que esta empresa ha completado cada una de las iteraciones de gobernanza descritas en
esta guía de gobernanza.
En la fase anterior de esta narrativa, la empresa empezó a implementar controles y supervisión de costos, ya
que el gasto en la nube empieza a formar parte de los gastos operativos normales de la empresa.
La identidad se controla mediante una instancia local de Active Directory. La identidad híbrida se facilita
mediante la replicación a Azure Active Directory.
Las operaciones de TI o las operaciones en la nube se administran en gran parte en Azure Monitor y en las
funcionalidades de automatización relacionadas.
La continuidad empresarial y recuperación ante desastres (BCDR) se controla mediante almacenes de
Recovery Services.
Azure Security Center se utiliza para supervisar infracciones de seguridad y ataques.
Tanto Azure Security Center como Azure Monitor se utilizan para supervisar la gobernanza de la nube.
Azure Blueprints, Azure Policy y los grupos de administración se utilizan para automatizar el cumplimiento
con la directiva.
El objetivo es integrar la empresa de adquisición en las operaciones existentes siempre que sea posible.

Costo de adquisición de negocios: se estima que la adquisición del nuevo negocio sea rentable en
aproximadamente cinco años. Debido a la lenta tasa de retorno, la junta quiere controlar los costos de
adquisición, en la medida de lo posible. Existe el riesgo de que el control de costos y la integración técnica
entren en conflicto entre sí.
Existe el riesgo de que la migración a la nube genere costos de adquisición adicionales.
También se plantea el riesgo de que el nuevo entorno no esté correctamente regulado o de que se produzcan
infracciones de directivas.

implementación.
Todos los recursos en una nube secundaria deben supervisarse mediante las herramientas existentes de
administración operativa y supervisión de seguridad.
Todas las unidades organizativas deben integrarse en el proveedor de identidades existente.
El proveedor de identidades principal debe regir la autenticación de los recursos en la nube secundaria.

En esta sección del artículo se mejora el diseño de un producto viable mínimo de gobernanza para incluir
1. Conecte las redes. Esta instrucción la ejecutan los equipos de redes y seguridad de TI, respaldados por el
equipo de gobernanza.
a. La adición de una conexión desde el proveedor de líneas alquiladas o MPLS a la nueva nube integrará
las redes. La adición de tablas de enrutamiento y configuraciones de firewall controlará el acceso y el
tráfico entre los entornos.
2. Consolide los proveedores de identidades. Dependiendo de las cargas de trabajo que se hospeden en la nube
secundaria, hay una variedad de opciones para la consolidación de proveedores de identidades. Estos son
algunos ejemplos:
a. Para las aplicaciones que se autentican mediante OAuth 2, los usuarios de Active Directory en la nube
secundaria podrían replicarse simplemente al inquilino de Azure AD existente.
b. En el otro extremo, la federación entre los dos proveedores de identidades locales permitiría la
replicación de los usuarios de los nuevos dominios de Active Directory en Azure.
3. Agregue recursos a Azure Site Recovery.
a. Azure Site Recovery se ha diseñado desde el principio como una herramienta híbrida o de varias
nubes.
b. Las máquinas virtuales en la nube secundaria podrían estar protegidas por los mismos procesos de
Azure Site Recovery utilizados para proteger los recursos locales.
4. Agregue los recursos a Azure Cost Management + Billing.
a. Azure Cost Management + Billing se ha diseñado desde el principio como una herramienta para
varias nubes.
b. Las máquinas virtuales de la nube secundaria podrían ser compatibles con Azure Cost Management +
Billing para algunos proveedores de servicios en la nube. Se pueden aplicar costos adicionales.
5. Agregue recursos a Azure Monitor.
a. Azure Monitor se ha diseñado desde el principio como una herramienta de nube híbrida.
b. Las máquinas virtuales en la nube secundaria podrían ser compatibles con los agentes de Azure
Monitor, lo que permite incluirlas en Azure Monitor para la supervisión operativa.
6. Herramientas de cumplimiento de gobernanza.
a. El cumplimiento de gobernanza es específico de la nube.
b. Las directivas corporativas establecidas en la guía de gobernanza no son específicas de la nube.
Aunque la implementación puede variar de una nube a otra, las declaraciones de directivas pueden
aplicarse al proveedor secundario.
La adopción de varias nubes se debe implementar donde sea necesaria en función de necesidades técnicas o los
requisitos empresariales específicos. A medida que progresa la adopción de varias nubes, aumenta la
complejidad y los riesgos de seguridad.
Pasos siguientes
En muchas grandes empresas, las cinco materias de gobernanza de la nube pueden ser obstáculos para la
adopción. El siguiente artículo incluye algunas conclusiones adicionales sobre cómo convertir la gobernanza en
un deporte en equipo, a fin de ayudar a garantizar el éxito a largo plazo en la nube.
Si las grandes empresas requieren varios niveles de gobernanza, existen mayores niveles de complejidad que
deben tenerse en cuenta en el producto viable mínimo de gobernanza y las posteriores mejoras de gobernanza.
Entre algunos ejemplos comunes de esas complejidades se incluyen:
Funciones de gobernanza distribuido.
Grupo de TI corporativo que asiste a organizaciones de TI de unidades de negocio.
Grupo de TI corporativo que asiste a organizaciones de TI distribuidas geográficamente.
En este artículo se exploran algunas maneras de atravesar este tipo de complejidad.
La gobernanza para grandes empresas es un deporte en equipo

A menudo, las grandes empresas establecidas tienen equipos o empleados que se centran en las materias
mencionadas en esta guía. En esta guía se muestra un enfoque para hacer que la gobernanza sea un deporte en
equipo.
En muchas grandes empresas, las cinco materias de gobernanza de la nube pueden ser obstáculos para la
adopción. Generar experiencia de nube en identidad, seguridad, operaciones, implementaciones y configuración
en toda una empresa lleva tiempo. La implementación holística de una directiva de gobernanza de TI y de la
seguridad de TI puede ralentizar la innovación durante meses o incluso años. Equilibrar la necesidad
empresarial de innovar y la necesidad de gobernanza para proteger los recursos existentes es un aspecto
delicado.
Las funcionalidades intrínsecas de la nube pueden eliminar los bloqueadores de la innovación, pero aumentan
los riesgos. En esta guía de gobernanza, hemos mostrado cómo la empresa de ejemplo crea barreras de
seguridad para controlar los riesgos. En lugar de abordar cada una de las materias necesarias para proteger el
entorno, el equipo de gobernanza de la nube pone en práctica un enfoque basado en riesgos para controlar lo
que se podría implementar, mientras que los demás equipos generarían los niveles de madurez necesarios de la
nube. Lo que es más importante, a medida que cada equipo alcanza el nivel de madurez de la nube, la
gobernanza aplica sus soluciones de manera holística. A medida que cada equipo madura y se suma a la
solución general, el equipo de gobernanza de la nube puede abrirse a nuevas etapas, lo que permite que
prosperen nuevas innovaciones y adopciones.
Este modelo ilustra el crecimiento de una asociación entre el equipo de gobernanza de la nube y los equipos
empresariales existentes (seguridad, gobernanza de TI, redes, identidad,etc.). La guía empieza por el producto
viable mínimo de gobernanza y evoluciona hacia un estado final holístico a través de las evoluciones de
gobernanza.
Requisitos para admitir este tipo de deporte en equipo

El primer requisito de un modelo de gobernanza de varias capas es entender la jerarquía de gobernanza.
Responder a las preguntas siguientes le ayudará a comprender la jerarquía general de gobernanza:
¿Cómo se asignan las cuentas de nube (la facturación de servicios en la nube) a las unidades de negocio?
¿Cómo se asignan las responsabilidades de gobernanza entre el grupo de TI corporativo y cada unidad de
negocio?
¿Qué tipos de entorno administra cada una de estas unidades de TI?
Gobernanza central de una jerarquía de gobernanza distribuido

Las herramientas como los grupos de administración permiten al grupo de TI corporativo crear una estructura
jerárquica que coincida con la jerarquía de gobernanza. Herramientas como Azure Blueprints pueden aplicar
recursos a diferentes capas de esa jerarquía. Azure Blueprints puede tener varias versiones, y se pueden aplicar
varias versiones a grupos de administración, suscripciones o grupos de recursos. Cada uno de estos conceptos
se describe con más detalle en el MVP de gobernanza.
El aspecto importante de cada una de estas herramientas es la capacidad para aplicar varios planos técnicos a
una jerarquía. Esto permite que la gobernanza sea un proceso en capas. El siguiente es un ejemplo de esta
aplicación jerárquica de gobernanza:
Grupo de TI corporativo: El grupo de TI corporativo crea un conjunto de estándares y directivas que se
aplican a toda la adopción de la nube. Esto se materializa en un plano técnico de base de referencia. El grupo
de TI corporativo es propietario de la jerarquía de grupos de administración, lo que garantiza que una
versión de la base de referencia se aplique a todas las suscripciones de la jerarquía.
Grupo de TI regional o unidad de negocio : Varios equipos de TI pueden aplicar una capa adicional de
gobernanza al crear su propio plano técnico. Esos planos técnicos crearían estándares y directivas
adicionales. Una vez desarrollado, el grupo de TI corporativo podría aplicar esos planos técnicos a los nodos
correspondientes dentro de la jerarquía de grupos de administración.
Equipos de adopción de la nube: Cada equipo de adopción de la nube puede tomar decisiones detalladas
sobre la implementación de aplicaciones o cargas de trabajo, en el contexto de los requisitos de gobernanza.
El equipo también puede solicitar plantillas adicionales de coherencia de los recursos de Azure para acelerar
los esfuerzos de adopción.
Los detalles relativos a la implementación de gobernanza en cada nivel requerirán la coordinación entre cada
equipo. El producto viable mínimo de gobernanza y las mejoras de gobernanza que se describen en esta guía
pueden ayudar a alinear esta coordinación.
Evaluación de la directiva corporativa
Cualquier cambio en los procesos de negocio o en las plataformas tecnológicas presenta riesgos empresariales.
Los equipos de gobernanza en la nube, cuyos miembros se conocen a veces como administradores en la nube,
tienen la obligación de mitigar estos riesgos con una interrupción mínima de los esfuerzos de adopción o
innovación.
Sin embargo, la gobernanza de la nube requiere más que una implementación técnica. Los cambios sutiles en la
narrativa o las directivas corporativas pueden afectar a los esfuerzos de adopción significativamente. Antes de la
implementación, es importante mirar más allá de TI para definir la directiva corporativa.
Figura 1: Representación visual de la directiva corporativa y las cinco materias de gobernanza en la nube.

La definición de la directiva corporativa se centra en cómo identificar y mitigar los riesgos empresariales,
independientemente de la plataforma de nube. Una buena estrategia de gobernanza en la nube empieza con
una sólida directiva corporativa. El siguiente proceso de tres pasos ofrece orientación sobre el desarrollo
iterativo de dichas directivas.
Riesgo empresarial: Investigue la clasificación de los datos y

los planes de adopción de la nube actuales para identificar
los riesgos empresariales. Trabaje con la empresa para
equilibrar los costos de mitigación y tolerancia a riesgos.
Directiva y cumplimiento: Evalúe la tolerancia a los riesgos

para comunicar directivas mínimamente invasivas que rijan la
adopción de la nube y administren los riesgos. En algunas
industrias, el cumplimiento de terceros afecta a la creación
inicial de la directiva.
Procesos: El ritmo de las actividades de adopción e

innovación naturalmente planteará infracciones de directivas.
La ejecución de procesos pertinentes facilitará la supervisión
y el control del cumplimiento de las directivas.
Pasos siguientes
Obtenga información acerca de cómo preparar la directiva corporativa para la nube.
Preparación de la directiva corporativa para la nube
Preparación de la directiva de TI corporativa para la
nube
La gobernanza de la nube es producto de un esfuerzo continuo de adopción a lo largo del tiempo, ya que una
verdadera transformación duradera no ocurre de la noche a la mañana. Si intenta ofrecer una gobernanza
integral de la nube antes de abordar los cambios clave de las directivas corporativas mediante un método
rápido y agresivo, rara vez conseguirá los resultados deseados. En su lugar, le recomendamos que aplique un
método incremental.
Lo que diferencia a Cloud Adoption Framework es el ciclo de compra y cómo esto puede permitirle realizar una
transformación auténtica. Puesto que no es necesario cumplir con un requisito excesivo de adquisición de
gastos de capital, los ingenieros pueden comenzar el proceso de experimentación y adopción mucho antes. En la
mayoría de las culturas corporativas, la eliminación de la barrera de los gastos de capital para la adopción puede
llevar a ciclos que ofrecen comentarios más precisos, un crecimiento orgánico y una ejecución incremental.
El cambio a la adopción de la nube requiere realizar un cambio en la gobernanza. Por ello, en muchas
organizaciones, la transformación de las directivas corporativas les permite alcanzar una gobernanza mejor y
mayores tasas de cumplimiento gracias a los cambios realizados en las directivas incrementales y a la aplicación
automática de esos cambios, impulsada gracias a las capacidades recién definidas que debe configurar con su
proveedor de servicios en la nube.
En este artículo se describen las actividades clave que le ayudarán a configurar las directivas corporativas para
habilitar un modelo de gobernanza ampliado.
Definir las directivas corporativas para perfeccionar la gobernanza de

la nube.
En la gobernanza tradicional y en la incremental, las directivas corporativas crean la definición del trabajo de
gobernanza. La mayoría de las acciones de gobernanza de TI buscan implementar tecnología para supervisar,
aplicar, usar y automatizar esas directivas corporativas. La gobernanza de la nube se basa en conceptos
similares.
Figura 1: Gobernanza corporativa y disciplinas de gobernanza.

Para poder crear una estrategia de gobernanza, en la imagen anterior se muestran las interacciones entre el
riesgo de negocios, las directivas y el cumplimiento, y la opción de supervisar y exigir. A continuación, verá las
cinco materias de gobernanza en la nube para crear la estrategia.
Revisar las directivas existentes

En la imagen de arriba, la estrategia de gobernanza (riesgo, directivas y cumplimiento, supervisar y exigir)
comienza con el reconocimiento de los riesgos del negocio. Descubrir cómo cambian los riesgos de negocio en
la nube es el primer paso para crear una estrategia duradera de gobernanza en la nube. Debe trabajar con sus
unidades de negocio para obtener un medidor preciso de la tolerancia de riesgo que tiene el negocio; gracias a
ello, podrá comprender qué nivel de riesgo se debe corregir. Si entiende en qué consisten los nuevos riesgos y
cuál es la tolerancia aceptable para su negocio, podrá mejorar la revisión de las directivas existentes, a fin de
determinar el nivel de gobernanza requerido más apropiado para su organización.
TIP
Si su organización se rige en función del cumplimiento de directivas de terceros, uno de los mayores riesgos de negocios a
considerar puede ser el riesgo que supone el cumplimiento normativo. Generalmente este riesgo no se puede corregir y,
en cambio, puede requerir una adherencia estricta. Asegúrese de entender los requisitos de cumplimiento de terceros
antes de comenzar a revisar las directivas.
Enfoque incremental para la gobernanza de la nube

Un enfoque incremental hacia la gobernanza de la nube asume que no se puede superar la tolerancia de riesgo
de la empresa. En su lugar, asume que la función de gobernanza consiste en acelerar el cambio comercial,
ayudar a los ingenieros a entender las pautas de la arquitectura y asegurar que los riesgos de negocio se
notifican y corrigen regularmente. Alternativamente, el rol tradicional de gobernanza puede convertirse en un
obstáculo para que los ingenieros o la empresa en general puedan realizar la adopción.
Debido a un enfoque incremental de la gobernanza de la nube, a veces hay una fricción natural entre los
equipos que crean nuevas soluciones de negocios y los que protegen el negocio de los riesgos. En este modelo,
esos dos equipos pueden convertirse en compañeros que trabajan tanto en incrementos o en sprints. Ahora que
son compañeros, el equipo de gobernanza en la nube y los equipos de adopción de la nube comienzan a
trabajar juntos para exponer, evaluar y corregir los riesgos del negocio. Todo este esfuerzo puede crear un
medio natural para reducir la fricción y mejorar la colaboración entre equipos.
Producto mínimo viable (MVP) para las directivas

El primer paso a dar cuando se surge una asociación emergente entre sus equipos de gobernanza y adopción en
la nube, es crear un acuerdo con respecto a la directiva de MVP. Su MVP para la gobernanza de la nube debe
reconocer que los riesgos del negocio pueden ser pequeños al principio, pero es probable que crezcan a medida
que su organización adopte más servicios en la nube con el tiempo.
Por ejemplo, el riesgo para el negocio es pequeño para un negocio que implementa cinco máquinas virtuales
que no contienen datos de alto impacto para el negocio (HBI). Más adelante en el proceso de adopción de la
nube, cuando el número alcance las 1 000 máquinas virtuales y el negocio empiece a mover datos HBI,
aumentará el riesgo empresarial.
MVP de directivas intenta definir una base requerida para las directivas necesarias para implementar las
primeras x máquinas virtuales o las primeras x número de aplicaciones, donde x es una pequeña aunque
significativa cantidad de las unidades que se van a adoptar. Este conjunto de directivas requiere pocas
restricciones, pero debe contener los aspectos fundamentales necesarios para poder crecer rápidamente de un
incremento de esfuerzo de adopción de la nube a otro. Gracias al desarrollo incremental de directivas, esta
estrategia de gobernanza crecerá con el tiempo. A través de cambios sutiles y constantes, el MVP de la directiva
crecerá en paridad de características con los resultados del ejercicio de revisión de directivas.
Crecimiento incremental de la directiva

El crecimiento incremental de las directivas es el mecanismo clave para aumentar las directivas y la gobernanza
en la nube a lo largo del tiempo. También es el requisito clave para adoptar un modelo de gobernanza
incremental. Para que este modelo funcione bien, el equipo de gobernanza debe comprometerse a realizar
asignaciones continuas de tiempo en cada sprint, a fin de evaluar e implementar las disciplinas cambiantes de la
gobernanza.
Requisitos de tiempo del sprint: Al comienzo de cada iteración, cada equipo de adopción de la nube crea
una lista de recursos que se van a migrar o adoptar en el incremento actual. Se supone que el equipo de
gobernanza en la nube debe otorgar el tiempo suficiente para revisar la lista, validar las clasificaciones de datos
de los recursos, evaluar los nuevos riesgos asociados a cada recurso, actualizar las pautas de la arquitectura e
informar al equipo de los cambios. Estos compromisos comúnmente necesitan entre 10 y 30 horas por sprint.
También se espera que este nivel de participación requiera al menos un empleado dedicado a administrar la
gobernanza; este empleado realizará un gran esfuerzo de adopción de la nube.
Requisitos de tiempo de lanzamiento: Al comienzo de cada versión, los equipos de adopción de la nube y el
equipo de estrategia en la nube deben priorizar una lista de aplicaciones o cargas de trabajo que se migrarán en
la iteración actual, junto con las actividades de cambio de negocio. Esos puntos de datos permiten que el equipo
de gobernanza en la nube entienda los nuevos riesgos del negocio antes. Gracias a ello, los equipos tienen
tiempo suficiente para ponerse al día con el negocio y medir la tolerancia de ese negocio en cuanto a los
posibles riesgos.
Pasos siguientes
Una estrategia eficaz de gobernanza en la nube empieza por conocer el riesgo empresarial.
Descripción del riesgo empresarial
Descripción del riesgo empresarial durante la
migración a la nube
Comprender el riesgo empresarial es uno de los elementos más importantes de cualquier transformación en la
nube. El riesgo impulsa las directivas e influye en los requisitos de supervisión y aplicación. El riesgo influye en
gran medida en nuestra forma de administrar el patrimonio digital, ya sea en el entorno local o en la nube.
Relatividad del riesgo

El riesgo es relativo. Una pequeña empresa con pocos recursos de TI y en un edificio cerrado tiene poco riesgo.
Si se agregan usuarios y una conexión a Internet con acceso a esos recursos, el riesgo se intensifica. Cuando esa
pequeña empresa crece hasta pertenecer a Fortune 500, los riesgos son exponencialmente mayores. A medida
que se acumulan los ingresos, los procesos de negocio, los recuentos de empleados y los recursos de TI, los
riesgos aumentan y se fusionan. Los recursos de TI que ayudan a generar ingresos corren el riesgo tangible de
detener ese flujo de ingresos en caso de que se produzca una interrupción del servicio. Cada momento de
inactividad equivale a pérdidas. Asimismo, a medida que se acumulan los datos, aumenta el riesgo de perjudicar
a los clientes.
En el entorno local tradicional, los equipos de gobernanza de TI se centran en evaluar riesgos, crear procesos
para administrar esos riesgos e implementar sistemas para garantizar que las medidas de corrección se
implementen correctamente. Estos esfuerzos equilibran los riesgos necesarios para operar en un entorno
empresarial conectado y moderno.
Descripción de los riesgos empresariales en la nube

Durante una transformación, se presentan los mismos riesgos relativos.
Durante la experimentación temprana, se implementan algunos recursos con poca o ninguna información
relevante. El riesgo es pequeño.
Cuando se implementa la primera carga de trabajo, el riesgo aumenta un poco. Este riesgo se corrige
fácilmente al elegir una aplicación intrínsecamente de bajo riesgo con una pequeña base de usuarios.
A medida que se conectan más cargas de trabajo, los riesgos cambian en cada versión. Nuevas aplicaciones
se ponen en marcha y los riesgos cambian.
Cuando una empresa lanza las primeras 10 a 20 aplicaciones en línea, el perfil de riesgo es muy diferente al
de cuando la aplicación número mil entra en producción en la nube.
Los recursos que se han acumulado en el patrimonio local tradicional probablemente lo han hecho a lo largo del
tiempo. La madurez de los equipos de negocio y de TI probablemente estaba creciendo de manera similar. Este
crecimiento paralelo puede tender a crear un bagaje de directivas innecesario.
Durante una transformación de la nube, tanto el equipo de negocio como el de TI tienen la oportunidad de
restablecer esas directivas y crear nuevas con una mentalidad madura.
¿Qué es un producto mínimo viable de riesgo empresarial?

Un producto mínimo viable (MVP) se usa normalmente para definir la unidad más pequeña de algo que puede
producir valor tangible. En un producto mínimo viable de riesgo empresarial, el equipo de gobernanza de la
nube parte del supuesto de que algunos recursos se van a implementar en un entorno de nube en algún
momento. Se desconoce lo que esos recursos son en ese momento y es posible que el equipo no esté seguro de
qué tipos de datos se van a almacenar en esos recursos.
Al planear para el riesgo empresarial, el equipo de gobernanza de la nube podría crear para el escenario más
desfavorable y asignar todas las directivas posibles a la nube. La identificación de todos los riesgos
empresariales posibles para todos los escenarios de uso de la nube puede conllevar un tiempo y un esfuerzo
considerables, lo que podría retrasar la implementación de la gobernanza en las cargas de trabajo en la nube.
Esto no es aconsejable, pero es una opción.
Por el contrario, un enfoque de producto mínimo viable puede permitir al equipo definir un punto de partida
inicial y un conjunto de supuestos que serían válidos para la mayoría o todos los recursos. Este producto
mínimo viable de riesgo empresarial admite implementaciones iniciales en la nube de prueba o de pequeña
escala y luego se usa como base para identificar y corregir gradualmente nuevos riesgos a medida que surgen
necesidades empresariales o se agregan cargas de trabajo adicionales al entorno de nube. Este proceso permite
aplicar la gobernanza a lo largo del proceso de adopción de la nube.
A continuación se muestran algunos ejemplos básicos de riesgos empresariales que pueden existir como parte
de un producto mínimo viable:
Todos los recursos corren el riesgo de ser eliminados (por error o mantenimiento).
Todos los recursos corren el riesgo de generar demasiados gastos.
Todos los recursos podrían verse comprometidos por contraseñas débiles o una configuración poco segura.
Cualquier recurso con los puertos abiertos expuestos en Internet corre el riesgo de verse comprometido.
Los ejemplos anteriores tienen por objeto establecer los riesgos empresariales de producto mínimo viable como
una teoría. La lista real será única para cada entorno.
Una vez establecido el producto mínimo viable de riesgo empresarial, se pueden convertir en directivas para
corregir cada riesgo.
Mitigación de riesgos incrementales

A medida que la organización implementa más cargas de trabajo en la nube, los equipos de desarrollo usan una
cantidad creciente de recursos en la nube. En cada iteración, se crean y se almacenan provisionalmente nuevos
recursos. En cada versión, las cargas de trabajo se preparan para la promoción de la producción. Cada uno de
estos ciclos tiene el potencial de incorporar riesgos empresariales no identificados previamente.
Si se supone que un producto mínimo viable de riesgo empresarial es el punto de partida de los esfuerzos
iniciales de adopción de la nube, la gobernanza puede madurar en paralelo con el creciente uso de recursos en
la nube. Cuando el equipo de gobernanza de la nube opera en paralelo con los equipos de adopción de la nube,
el aumento de los riesgos empresariales se puede abordar a medida que se identifican, lo que proporciona un
modelo continuo estable para desarrollar la madurez de la gobernanza.
Cada recurso preconfigurado se puede clasificar fácilmente en función del riesgo. Los documentos de
clasificación de datos pueden generarse o crearse en paralelo a los ciclos de almacenamiento provisional. El
perfil de riesgo y los puntos de exposición también pueden documentarse. Con el paso del tiempo, una visión
extremadamente clara del riesgo empresarial se hace patente en toda la organización.
Con cada iteración, el equipo de gobernanza de la nube puede trabajar con el equipo de estrategia de la nube
para comunicar rápidamente nuevos riesgos, estrategias de mitigación, compensaciones y costos potenciales.
Esto permite a los participantes empresariales y a los responsables de TI tomar decisiones maduras y bien
informadas. Estas decisiones influyen en la madurez de las directivas. Cuando es necesario, los cambios de
directiva producen nuevos elementos de trabajo para la madurez de los sistemas de infraestructura básicos.
Cuando se requieren cambios en los sistemas preconfigurados, los equipos de adopción de la nube tienen
tiempo suficiente para hacer cambios, mientras que el negocio prueba los sistemas preconfigurados y desarrolla
un plan de adopción de usuarios.
Este enfoque minimiza los riesgos, a la vez que capacita al equipo para actuar con rapidez. También garantiza
que los riesgos se abordan y resuelven rápidamente antes de la implementación.
Pasos siguientes
Obtenga información sobre cómo evaluar la tolerancia a los riesgos durante la adopción de la nube.
Cada decisión empresarial genera nuevos riesgos. Hacer una inversión en cualquier cosa genera un riesgo de
pérdida. Los nuevos productos o servicios generan riesgos de fracaso en el mercado. Los cambios realizados en
los productos o servicios actuales podrían reducir la cuota de mercado. La transformación a la nube no ofrece
una solución mágica a los riesgos empresariales cotidianos. Al contrario, las soluciones conectadas (en la nube o
locales) presentan nuevos riesgos. Implementar recursos en cualquier instalación de red conectada también
expande el perfil de amenazas potenciales al exponer las vulnerabilidades de seguridad a una comunidad global
mucho más amplia. Afortunadamente, los proveedores de servicios en la nube son conscientes de los cambios,
del aumento y de la suma de los riesgos. Hacen grandes inversiones para administrar y mitigar esos riesgos en
nombre de sus clientes.
Este artículo no se centra en los riesgos en la nube. En su lugar, describe los riesgos empresariales asociados con
las diversas formas de transformación a la nube. Más adelante en este artículo, el debate cambia el foco para
describir las formas de entender la tolerancia al riesgo por parte de las empresas.
¿Qué riesgos empresariales están asociados con una transformación a

la nube?
Los verdaderos riesgos empresariales se basan en los detalles de las transformaciones específicas. Varios
riesgos comunes ofrecen un punto de partida para comprender los riesgos específicos de la empresa.
IMPORTANT
Antes de leer lo siguiente, tenga en cuenta que cada uno de estos riesgos se puede administrar. El objetivo de este
artículo es informar y preparar a los lectores para mantener conversaciones más productivas sobre la administración de
los riesgos.
Vulneración de datos: El riesgo principal asociado a cualquier transformación es una vulneración de

datos. Las fugas de datos pueden provocar daños importantes en la empresa y, como consecuencia,
provocar la pérdida de clientes, disminución del negocio o incluso responsabilidades legales. Los cambios
en cómo se almacenan, procesan o usan los datos crea un riesgo. Las transformaciones a la nube
suponen un gran cambio con respecto a la administración de los datos, por lo que el riesgo no debe
tomarse a la ligera. Las materias Base de referencia de seguridad, Clasificación de los datos y
Racionalización incremental pueden ayudar a administrar este riesgo.
Interrupción del ser vicio. Las operaciones empresariales y las experiencias de los clientes dependen
en gran medida de las operaciones técnicas. Las transformaciones a la nube generarán cambios en las
operaciones de TI. En algunas organizaciones, el cambio es pequeño y se ajusta fácilmente. En otras
organizaciones, estos cambios podrían requerir nuevas herramientas, nuevos conocimientos o nuevos
enfoques para admitir las operaciones en la nube. Cuanto mayor sea el cambio, mayor será el impacto
potencial en las operaciones empresariales y en las experiencias de los clientes. Administrar este riesgo
requerirá la participación de la empresa en el planeamiento de la transformación. El planeamiento de la
versión y la selección de la primera carga de trabajo que se describen en el artículo de racionalización
incremental describen maneras de elegir las cargas de trabajo para los proyectos de transformación. El
rol de la empresa en esa actividad es comunicar el riesgo para las operaciones empresariales de cambiar
las cargas de trabajo prioritarias. Ayudar al departamento de TI a elegir cargas de trabajo con un menor
impacto en las operaciones reducirá el riesgo general.
Control del presupuesto: Los modelos de costos cambian en la nube. Este cambio puede generar
riesgos asociados con sobrecostos o aumentos en el costo de los bienes vendidos (COGS), en especial
directamente atribuidos a los gastos operativos. Cuando la empresa trabaja en estrecha colaboración con
el equipo de TI, es posible crear la transparencia relativa a los costes y los servicios usados por varias
unidades de negocio, programas o proyectos. En la materia de administración de costos se proporcionan
ejemplos de cómo pueden asociarse las empresas y los departamentos de TI en este tema.
Los anteriores son algunos de los riesgos más comunes que han mencionado los clientes. El equipo de
gobernanza de la nube y los equipos de adopción de la nube pueden empezar a desarrollar un perfil de riesgo, a
medida que las cargas de trabajo se migren y estén listas para pasar a producción. Prepárese para mantener
conversaciones para definir, refinar y administrar los riesgos según los resultados de negocio deseados y el
esfuerzo de transformación.
Explicación de la tolerancia al riesgo

La identificación de riesgos es un proceso bastante directo. Los riesgos relacionados con TI suelen ser estándar
en todos los sectores. La tolerancia a estos riesgos es específica de cada organización. Este es el punto donde las
conversaciones entre la empresa y TI tienden a estancarse. Básicamente, cada lado habla un idioma diferente.
Las comparaciones y las preguntas siguientes están diseñadas para dar pie a conversaciones que ayuden a cada
parte a comprender y calcular la tolerancia al riesgo.
Caso de uso sencillo para comparación

Para ayudarle a entender la tolerancia al riesgo, vamos a examinar los datos del cliente. Si una empresa de
cualquier sector publica datos de clientes en un servidor no seguro, el riesgo técnico de que los datos estén en
peligro o los roben es prácticamente el mismo. La tolerancia de una empresa a este riesgo variará en función de
la naturaleza y el valor potencial de los datos.
Las empresas de atención sanitaria y servicios financieros en Estados Unidos se rigen por rígidos requisitos
de cumplimiento de terceros. Se da por hecho que los datos personales o los datos de salud son
extremadamente confidenciales. Si estas empresas se ven involucradas en los escenarios de riesgo
anteriores, pueden sufrir graves consecuencias. Su tolerancia será extremadamente baja. Los datos de
clientes publicados dentro o fuera de la red deben regirse por esas directivas de cumplimiento de terceros.
Una empresa de juegos cuyos datos de cliente se limitan a un nombre de usuario, tiempos de juego y
puntuaciones más altas no es propensa a sufrir consecuencias negativas significativas más allá de una
pérdida de reputación si reproduce los comportamientos de riesgo anteriores. Aunque todos los datos no
protegidos están en riesgo, el impacto de ese riesgo es pequeño. Por lo tanto, la tolerancia al riesgo en este
caso es alta.
Una empresa mediana que presta servicios de limpieza de alfombras a miles de clientes estaría entre estos
dos extremos de tolerancia. Los datos de los clientes pueden ser más sólidos; por ejemplo, podrían contener
detalles como números de teléfono o direcciones. Ambos se consideran datos personales y deben
protegerse, pero ningún requisito de gobernanza específico exige que los datos estén protegidos. Desde una
perspectiva de TI, la respuesta es sencilla, proteger los datos. Desde una perspectiva empresarial, puede que
no sea tan sencilla. La empresa necesitará más detalles antes de poder decidir un nivel de tolerancia para
este riesgo.
En la siguiente sección se indican algunas preguntas de ejemplo que podrían ayudar a las empresas a decidir el
nivel de tolerancia al riesgo.
Preguntas de tolerancia de riesgo

En esta sección se enumeran las preguntas que dan lugar a conversaciones en tres categorías: impacto en las
pérdidas, probabilidad de pérdida y costos de remediación. Cuando la empresa y el departamento de TI se
asocian para abordar cada una de estas áreas, se puede llegar fácilmente a la decisión sobre la administración
de los riesgos y la tolerancia general a un riesgo en particular.
Impacto de la pérdida. Preguntas para determinar el impacto de un riesgo. Estas preguntas son de difícil
respuesta. Cuantificar el impacto es lo mejor, pero a veces la conversación por sí sola alcanza para comprender
la tolerancia. También son aceptables los rangos, en particular si incluyen supuestos que determinan esos
rangos.
¿Podría infringir este riesgo los requisitos de cumplimiento de terceros?
¿Podría infringir este riesgo las directivas corporativas internas?
¿Podría este riesgo provocar la pérdida de vidas humanas, heridas graves o daños en la propiedad?
¿Podría este riesgo generar un costo para los clientes o para la cuota de mercado? Si es así, ¿se puede
cuantificar este costo?
¿Podría este riesgo crear experiencias de cliente negativas? ¿Es probable que estas experiencias afecten a las
ventas o a los ingresos?
¿Puede este riesgo crear una nueva responsabilidad jurídica? Si es así, ¿hay algún antecedente de sentencias
por daños y perjuicios en estos tipos de casos?
¿Podría este riesgo detener de operaciones empresariales? Si es así, ¿cuánto tiempo se interrumpirían las
operaciones?
¿Podría este riesgo ralentizar las operaciones empresariales? Si es así, ¿cuánto tiempo y en qué medida?
En esta fase de la transformación, ¿se trata de un riesgo puntual o repetido?
¿Aumenta o disminuye en frecuencia este riesgo a medida que avanza la transformación?
¿Aumenta o disminuye la probabilidad del riesgo a lo largo del tiempo?
¿Se ve el riesgo afectado por el tiempo? Si no se aborda, ¿pasará o empeorará el riesgo?
Estas preguntas básicas darán lugar a muchas más. Después de mantener un diálogo adecuado, se recomienda
registrar los riesgos pertinentes y, cuando sea posible, cuantificarlos.
Costos de remediación de los riesgos. Preguntas para determinar el costo de mitigar o eliminar el riesgo.
Estas preguntas pueden ser bastante directas, en particular cuando se representan en un rango.
¿Hay alguna solución clara? Y, en caso afirmativo, ¿cuánto cuesta?
¿Existen opciones para evitar o minimizar este riesgo? ¿Cuál es el rango de costos para esas soluciones?
¿Qué se necesita de la empresa para seleccionar la mejor solución?
¿Qué se necesita de la empresa para validar los costos?
¿Qué otras ventajas puede aportar la solución enfocada a eliminar este riesgo?
Estas preguntas simplifican las soluciones técnicas necesarias para administrar o eliminar riesgos, pero las
comunican de manera que la empresa puede integrarse rápidamente a un proceso de toma de decisiones.
Probabilidad de pérdida. Preguntas para determinar la probabilidad de que el riesgo se vuelva realidad. Esta
es el área más difícil de cuantificar. En su lugar, se sugiere que el equipo de gobernanza de la nube cree
categorías para comunicar la probabilidad, según los datos con los que se cuenta. Las siguientes preguntas
pueden ayudar a crear categorías que sean significativas para el equipo.
¿Se ha realizado alguna investigación sobre la probabilidad de que este riesgo se materialice?
¿Puede el proveedor proporcionar estadísticas o referencias de la probabilidad de impacto?
¿Hay otras empresas del sector pertinente o vertical que se hayan visto afectadas por este riesgo?
Además, ¿existen otras empresas en general que puedan haber sido alcanzadas por este riesgo?
¿Es este riesgo propio a algo que esta empresa haya hecho mal?
Después de responder estas y otras preguntas, según lo establezca el equipo de gobernanza de la nube,
probablemente surjan agrupaciones de probabilidad. A continuación encontrará algunos ejemplos de
agrupación que le ayudarán a empezar a trabajar:
Sin indicación. No se han realizado suficientes investigaciones para determinar la probabilidad.
Riesgo bajo. La investigación actual indica que no es probable que se produzca el riesgo.
Riesgo futuro. La probabilidad actual es de baja. La adopción continua haría necesario un nuevo análisis.
Riesgo medio. Es probable que el riesgo afecte al negocio.
Riesgo alto. Con el tiempo, cada vez es más probable que el riesgo afecte al negocio.
Riesgo en declive. El riesgo es de medio a alto. Las acciones del departamento de TI o de la empresa están
reduciendo la probabilidad del impacto.
Determinación de la tolerancia.
Los tres conjuntos de preguntas anteriores deben hacer surgir datos suficientes para determinar las tolerancias
iniciales. Cuando el riesgo y la probabilidad son bajos, y el costo de remediación es alto, es poco probable que la
empresa invierta en remediarlo. Si el riesgo y la probabilidad son altos, es probable que la empresa considere la
posibilidad de realizar una inversión, siempre y cuando los costos no superen los posibles riesgos.
Pasos siguientes
Este tipo de conversación puede ayudar a las empresas y a TI a evaluar la tolerancia de forma más eficaz. Estas
conversaciones pueden usarse durante la creación de directivas de MVP y durante las revisiones de directivas
incrementales.
Definición de directivas corporativas para la
gobernanza de la nube
Una vez que haya analizado los riesgos conocidos y las tolerancias a riesgos relacionadas del proceso de
transformación hacia la nube de la organización, el siguiente paso consiste en establecer directivas que aborden
explícitamente tales riesgos y definan los pasos necesarios para corregirlos siempre que sea posible.
¿Cómo se puede adaptar la directiva de TI de la empresa a las

soluciones en la nube?
En la gobernanza tradicional y en la incremental, las directivas corporativas crean la definición del trabajo de
gobernanza. La mayoría de las acciones de gobernanza de TI buscan implementar tecnología para supervisar,
aplicar, usar y automatizar esas directivas corporativas. La gobernanza de la nube se basa en conceptos
similares.
Figura 1: Gobernanza corporativa y disciplinas de gobernanza.

La imagen anterior muestra la relación entre el riesgo empresarial, las directivas y el cumplimiento, y los
mecanismos de supervisión y cumplimiento que deben interactuar como parte de la estrategia de gobernanza.
Las cinco materias de gobernanza de la nube permiten administrar estas interacciones y aplicar la estrategia.
La gobernanza de la nube es producto de un esfuerzo continuo de adopción a lo largo del tiempo, ya que una
verdadera transformación duradera no ocurre de la noche a la mañana. Si intenta ofrecer una gobernanza
integral de la nube antes de abordar los cambios clave de las directivas corporativas mediante un método
rápido y agresivo, rara vez conseguirá los resultados deseados. En su lugar, le recomendamos que aplique un
método incremental.
Lo que diferencia a un Marco de adopción de la nube es el ciclo de compra y que puede permitir una
transformación auténtica. Puesto que no hay un requisito grande de inversión de capital, los ingenieros pueden
comenzar con la experimentación y la adopción mucho antes. En la mayoría de las culturas corporativas, la
eliminación de la barrera de los gastos de capital para la adopción puede llevar a ciclos que ofrecen comentarios
más precisos, un crecimiento orgánico y una ejecución incremental.
El cambio a la adopción de la nube requiere realizar un cambio en la gobernanza. Por ello, en muchas
organizaciones, la transformación de las directivas corporativas les permite alcanzar una gobernanza mejor y
mayores tasas de cumplimiento gracias a los cambios realizados en las directivas incrementales y a la aplicación
automática de esos cambios, impulsada gracias a las capacidades recién definidas que debe configurar con su
Revisar las directivas existentes

Puesto que la gobernanza es un proceso en curso, las directivas deben revisarse regularmente con el personal
de TI y las partes interesadas a fin de garantizar que los recursos hospedados en la nube sigan cumpliendo los
requisitos y objetivos corporativos generales. Si entiende en qué consisten los nuevos riesgos y cuál es la
tolerancia aceptable para su negocio, podrá mejorar la revisión de las directivas existentes, a fin de determinar el
nivel de gobernanza requerido más apropiado para su organización.
TIP
Si la organización usa proveedores u otros socios comerciales de confianza, uno de los mayores riesgos empresariales que
se debe tener en cuenta puede ser la falta de cumplimiento normativo por parte de estas organizaciones externas.
Generalmente, este riesgo no se puede corregir y, en cambio, puede requerir un cumplimiento estricto de los requisitos
por parte de todos los interesados. Asegúrese de identificar y entender los requisitos de cumplimiento de terceros antes
de comenzar a revisar las directivas.
Creación de declaraciones de directiva en la nube

Las directivas de TI basadas en la nube establecen los requisitos, estándares y objetivos que su personal de TI y
los sistemas automatizados deberán cumplir. Las decisiones de directiva son el factor principal del diseño de la
arquitectura en la nube y para decidir cómo implementar los procesos de cumplimiento de la directiva.
Cada declaración de directiva de nube es una guía para abordar los riesgos específicos identificados durante el
proceso de evaluación de riesgos. Aunque estas directivas se pueden integrar en la documentación de directivas
corporativas general, las declaraciones de directivas en la nube tratadas en la guía del Marco de adopción de la
nube suelen ser un resumen más conciso de los riesgos y los planes para corregirlos. Cada definición debe
incluir estos fragmentos de información:
Riesgo empresarial : Un resumen del riesgo que esta directiva abordará.
Declaración de directiva : Una explicación concisa de los objetivos y los requisitos de la directiva.
Diseño u orientación técnica: Recomendaciones prácticas, especificaciones u otras guías para respaldar y
aplicar esta directiva que los desarrolladores y equipos de TI pueden utilizar para diseñar y crear sus
implementaciones en la nube.
Si necesita ayuda para empezar a definir directivas, consulte las materias de gobernanza presentadas en la
información general de la sección de gobernanza. Los artículos de cada una de estas materias incluyen ejemplos
de riesgos empresariales comunes detectados al realizar la migración a la nube y directivas de ejemplo usadas
para corregir tales riesgos. Por ejemplo, vea las definiciones de directiva de muestra de la materia de Cost
Management.
Gobernanza incremental e integración con la directiva existente

Las adiciones planeadas al entorno de nube siempre deben analizarse para garantizar su cumplimiento con la
directiva existente, y también es necesario actualizar la directiva para tener en cuenta todos los problemas que
aún no se han detectado. También debe realizar una revisión de la directiva en la nube periódica para asegurarse
de que dicha directiva está actualizada y sincronizada con cualquier nueva directiva corporativa.
La necesidad de integrar la directiva en la nube con las directivas de TI heredadas depende en gran medida de la
madurez de los procesos de gobernanza en la nube y del tamaño de su entorno de nube. Consulte el artículo
sobre la gobernanza incremental y el MVP de la directiva para obtener una explicación más amplia sobre cómo
tratar la integración de una directiva durante la transformación de la nube.
Pasos siguientes
Después de definir las directivas, elabore una guía de diseño de la arquitectura para ofrecer instrucciones
prácticas a los desarrolladores y al personal de TI.
Alinee la guía de diseño de gobernanza con las directivas corporativas
Alineación de la guía de diseño de la gobernanza
de la nube con las directivas corporativas
Cuando haya definido las directivas de la nube basadas en los riesgos identificados, deberá generar una guía
accionable que se ajuste a estas directivas para que la puedan consultar el personal de TI y los desarrolladores.
Elaborar una guía de diseño de la gobernanza de la nube le permite especificar opciones estructurales,
tecnológicas y de procesos específicas basadas en las declaraciones de directiva que generó para cada una de
las cinco materias de gobernanza.
Una guía de diseño de la gobernanza de la nube debe establecer las opciones de arquitectura y los modelos de
diseño para cada uno de los componentes básicos de infraestructura de las implementaciones en la nube que
mejor se adapten a los requisitos de la directiva. Junto a estos, debe proporcionar una explicación de alto nivel
de la tecnología, las herramientas y los procesos que apoyarán cada una de estas decisiones de diseño.
Aunque el análisis de los riesgos y las declaraciones de directivas pueden, hasta cierto punto, ser independientes
de la plataforma de nube, la guía de diseño debe proporcionar detalles de implementación específicos de la
plataforma al departamento de TI y al de desarrollo a la hora de crear e implementar cargas de trabajo basadas
en la nube. Céntrese en la arquitectura, herramientas y características de la plataforma elegida al tomar
decisiones de diseño y proporcionar orientación.
Aunque las guías de diseño de la nube deben tener en cuenta algunos de los detalles técnicos asociados a cada
componente de la infraestructura, no pretenden ser documentos técnicos o especificaciones extensos.
Asegúrese de que las guías aborden las declaraciones de la directiva y de que expongan claramente las
decisiones de diseño en un formato fácil de entender y de consultar para el personal.
Uso de guías accionables de gobernanza

Si piensa utilizar la plataforma de Azure para su adopción de la nube, Cloud Adoption Framework proporciona
guías accionables de gobernanza que ilustran el enfoque incremental del modelo de gobernanza de este marco.
Estas guías abarcan diferentes escenarios de adopción comunes, e incluyen los riesgos empresariales, los
requisitos de tolerancia y las declaraciones de directiva que se incluyeron al crear el producto viable mínimo de
gobernanza. Estas guías representan una síntesis de la experiencia de los clientes en el mundo real durante el
proceso de adopción de la nube en Azure.
Aunque cada adopción de la nube tiene objetivos, prioridades y desafíos únicos, estos ejemplos deberían
proporcionar una buena plantilla para convertir la directiva en una guía. Elija el escenario más cercano a su
situación como punto de partida y moldéelo para que se ajuste a sus necesidades de directivas específicas.
Pasos siguientes
Una vez establecida la guía de diseño, establezca los procesos de adhesión a las directivas para garantizar el
cumplimiento de las mismas.
Establecer procesos de adhesión a directivas
Establecimiento de procesos de adhesión a
directivas
Después de establecer las instrucciones de la directiva de la nube y redactar una guía de diseño, deberá crear
una estrategia para garantizar que su implementación de la nube cumpla con los requisitos de la directiva. Esta
estrategia debe abarcar los procesos de comunicación y revisión en curso del equipo de gobernanza de la nube,
establecer criterios para cuando las infracciones de las directivas requieran medidas y definir los requisitos para
los sistemas automatizados de supervisión y cumplimiento que van a detectar las infracciones y desencadenar
las medidas correctoras.
Vea las secciones de directivas corporativas de las guías prácticas de gobernanza para obtener ejemplos de
cómo el proceso de adhesión a las directivas encaja en un plan de gobernanza de la nube.
Clasificación de los procesos de adhesión a las directivas

¿Cuánta inversión en el desarrollo de procesos se requiere para apoyar los objetivos de la directiva?
Dependiendo del tamaño y la madurez de la implementación de la nube, el esfuerzo requerido para establecer
procesos que admitan el cumplimiento, y los costos asociados con este esfuerzo, pueden variar ampliamente.
Para implementaciones pequeñas que consisten en recursos de desarrollo y de prueba, los requisitos de las
directivas pueden ser simples y requerir pocos recursos dedicados para abordarlos. Por otro lado, una
implementación en la nube madura y crítica con necesidades de seguridad y rendimiento de alta prioridad
puede requerir un equipo de personal, amplios procesos internos y herramientas de supervisión personalizadas
para respaldar los objetivos de las directivas.
Como primer paso para definir la estrategia de adherencia a la directiva, evalúe cómo los procesos que se
discuten a continuación pueden respaldar los requisitos de la directiva. Determine cuánto esfuerzo vale la pena
invertir en estos procesos y después utilice esta información para establecer un presupuesto realista y planes de
personal para satisfacer estas necesidades.
Establecimiento de procesos del equipo de gobernanza de la nube

Antes de definir los desencadenadores para la corrección del cumplimiento de las directivas, debe establecer los
procesos generales que va a usar el equipo y cómo se va a compartir y escalar la información entre el personal
de TI y el equipo de gobernanza de la nube.
Asignación de miembros al equipo de gobernanza de la nube
El equipo de gobernanza de la nube va a proporcionar orientación continua sobre el cumplimiento de las
directivas y se va a ocupar de los problemas relacionados con estas que surjan durante la implementación y el
funcionamiento de los recursos de la nube. Al crear este equipo, invite a miembros del personal de la
organización con experiencia en áreas incluidas en las declaraciones de las directivas definidas y en los riesgos
identificados.
Para las implementaciones de pruebas iniciales, esto puede limitarse a unos pocos administradores de sistemas
responsables de establecer las bases de la gobernanza. A medida que maduren los procesos de gobernanza,
revise regularmente los miembros del equipo de gobernanza de la nube para asegurarse de que puede abordar
adecuadamente los posibles nuevos riesgos y los requisitos de las directivas. Identifique a los miembros del
personal de TI y empresarial con experiencia de relevancia o interés en áreas específicas de gobernanza e
inclúyalos en los equipos de forma permanente o temporal, según sea necesario.
Revisiones e iteración de directivas
A medida que se implementan recursos y cargas de trabajo adicionales, el equipo de gobernanza de la nube
debe asegurarse de que las nuevas cargas de trabajo o los recursos cumplan los requisitos de las directivas.
Evalúe los nuevos requisitos de los equipos de desarrollo de cargas de trabajo para asegurarse de que sus
implementaciones planeadas se alinean con las guías de diseño y actualice las directivas para admitir estos
requisitos cuando sea necesario.
Planee la evaluación de nuevos riesgos potenciales y la actualización de las declaraciones de las directivas y las
guías de diseño cuando sea necesario. Trabaje con el personal de TI y los equipos de cargas de trabajo para
evaluar las nuevas características y los servicios de Azure de manera continua. Además, programe ciclos
regulares de revisión de las cinco materias de gobernanza para asegurar que las directivas estén actualizadas y
se cumplan.
Educación
El cumplimiento de las directivas requiere que el personal de TI y los desarrolladores comprendan los requisitos
de las directivas que afectan a sus áreas de responsabilidad. Planee dedicar recursos a documentar las
decisiones y los requisitos, y eduque a todos los equipos pertinentes sobre las guías de diseño que respaldan
los requisitos de la directiva.
A medida que cambien las directivas, actualice regularmente la documentación y los materiales de aprendizaje,
y asegúrese de que los esfuerzos educativos comuniquen los requisitos actualizados y la guía al personal de TI
pertinente.
En varias fases del recorrido en la nube, es posible que le resulte más conveniente consultar con asociados y
programas de aprendizaje profesional para mejorar la formación de su equipo, técnica y procedimentalmente.
Además, muchos consideran los certificados formales como una valiosa adición a la cartera de formación que
se debe tener en cuenta.
Establecimiento de las rutas de escalado
Si un recurso no cumple con las normas, ¿a quién se le notifica? Si el personal de TI detecta un problema de
cumplimiento de directivas, ¿con quién se ponen en contacto? Asegúrese de que el proceso de escalado al
equipo de gobernanza de la nube está claramente definido. Asegúrese de que estos canales de comunicación se
mantengan actualizados para reflejar los cambios del personal y de la organización.
Desencadenadores y acciones de infracciones

Después de definir el equipo de gobernanza de la nube y sus procesos, debe definir explícitamente lo que se
consideran infracciones de cumplimiento que desencadenan acciones, y cuáles deben ser esas acciones.
Definición de desencadenadores
Para cada una de sus declaraciones de directiva, revise los requisitos para determinar qué constituye una
infracción de la directiva. Genere los desencadenadores con la información que ya ha establecido como parte
del proceso de definición de directivas.
Tolerancia a riesgos: cree desencadenadores de infracción basados en las métricas y los indicadores de
riesgo establecidos como parte del análisis de tolerancia al riesgo.
Requisitos de directivas definidos: las declaraciones de directivas pueden proporcionar requisitos de
contrato de nivel de servicio (SLA), continuidad empresarial y recuperación ante desastres (BRCD) o
rendimiento que deben usarse como base para los desencadenadores de cumplimiento.
Definición de acciones
Cada desencadenador de infracción debe tener una acción correspondiente. Las acciones desencadenadas
siempre deben informar a un miembro del personal de TI o del equipo de gobernanza de la nube cuando se
produce una infracción. Esta notificación puede llevar a una revisión manual del problema de cumplimiento o
iniciar un proceso de corrección preestablecido, en función del tipo y la gravedad de la infracción detectada.
Algunos ejemplos de desencadenadores y acciones de infracciones:
M AT ERIA DE GO B ERN A N Z A DESEN C A DEN A DO R DE E JEM P LO A C C IÓ N DE E JEM P LO
Cost Management El gasto mensual en la nube es más de Notifique al responsable de la unidad

un 20 % mayor de lo esperado. de facturación, quién comenzará una
revisión de la utilización de los
recursos.
Línea de base de seguridad Detecte actividad sospechosa de inicio Notifique al equipo de seguridad de TI
de sesión de usuario. y deshabilite la cuenta de usuario
sospechosa.
Coherencia de recursos La utilización de la CPU para la carga Notifique al equipo de operaciones de

de trabajo es superior al 90 %. TI y amplíe los recursos adicionales
para administrar la carga.
Automatización de la supervisión y el cumplimiento

Después de haber definido los desencadenadores y las acciones de las infracciones de cumplimiento, puede
empezar a planear la mejor manera de utilizar las herramientas de registro y generación de informes y otras
funciones de la plataforma de nube para ayudar a automatizar la estrategia de supervisión y cumplimiento de
directivas.
Consulte el tema Registro e informes de la guía de decisiones de CAF para obtener una guía sobre cómo elegir
el mejor patrón de supervisión para la implementación.
Pasos siguientes
Obtenga más información sobre el cumplimiento normativo en la nube.
Cumplimiento normativo
Introducción al cumplimiento normativo
En este artículo se proporciona una introducción al cumplimiento normativo y, por lo tanto, no está diseñado
para implementar una estrategia de cumplimiento. Encontrará información más detallada sobre las ofertas de
cumplimiento de Azure en el Centro de confianza de Microsoft. Además, toda la documentación que se puede
descargar está disponible para determinados clientes de Azure en Microsoft Service Trust Portal.
Por cumplimiento normativo se entiende la materia y el proceso consistente en garantizar que una empresa
cumple la legislación establecida por las administraciones públicas en su ubicación geográfica, o las normas del
sector adoptadas voluntariamente. En el caso del cumplimiento normativo de TI, los usuarios o los procesos
supervisan los sistemas de la empresa para detectar y evitar las infracciones de las directivas y los
procedimientos que establecen la legislación y los reglamentos existentes. Esto se aplica a su vez a un área muy
amplia de los procesos de supervisión y aplicación. En función del sector y de la ubicación geográfica, estos
procesos pueden ser bastante largos y complejos.
En el caso de las organizaciones multinacionales (especialmente las de los sectores con mucha regulación, como
los servicios financieros y la atención sanitaria), el cumplimiento puede ser muy complicado. Hay un gran
número de normas y regulaciones que, en ciertos casos, cambian con frecuencia. El resultado es que para las
empresas cada vez es más difícil mantenerse al tanto de la evolución de las leyes internacionales de gestión de
datos electrónicos.
Al igual que sucede con los controles de seguridad, las organizaciones deben conocer la división de
responsabilidades con respecto al cumplimiento normativo en la nube. Los proveedores de servicios en la nube
se esfuerzan por asegurarse de que sus servicios y plataformas son cumplen la legislación. Las organizaciones
también deben confirmar que sus aplicaciones, la infraestructura de la que dependen las aplicaciones y los
servicios proporcionados por terceros también estén certificados como conformes a la norma.
Estas son las descripciones de las regulaciones de cumplimiento de diversos sectores y regiones geográficas:
HIPAA
Una aplicación de asistencia sanitaria que procesa información médica protegida (PHI) está sujeta tanto a la
regla de privacidad como a la regla de seguridad incluidas en la Ley de responsabilidad y transferibilidad de
seguros médicos (HIPAA). Como mínimo, es probable que HIPAA requiera que una empresa de atención
sanitaria reciba la garantía por escrito del proveedor de nube de que toda la información médica protegida
recibida o creada estará segura.
PCI
El estándar de seguridad de los datos para la industria de las tarjetas de pago (PCI DSS) es un estándar de
seguridad de información propietario para las organizaciones que controlan las tarjetas de crédito de los
principales sistemas de pago con tarjeta, como Visa, Mastercard, American Express, Discover y JCB. El estándar
de PCI lo imponen las marcas de tarjeta y lo administra la entidad Payment Card Industry Security Standards
Council. Dicho estándar se creó para aumentar los controles de los datos de los titulares, con el fin de reducir el
fraude en las tarjetas de crédito. La validación del cumplimiento la realiza anualmente un asesor de seguridad
cualificado (QSA), un asesor de seguridad interno (ISA) específico de la firma que crea un informe acerca del
cumplimiento (ROC) para las organizaciones que controlan grandes volúmenes de transacciones, o mediante un
cuestionario de autoevaluación (SAQ) de las empresas.
Datos personales
La información personal es cualquier dato que se puede utilizar para identificar a un consumidor, empleado,
asociado o cualquier otra entidad viva o legal. Muchas de las leyes recientes, sobre todo las relacionadas con la
privacidad y los datos personales, no solo requieren que las empresas las cumplan, sino también que informen
acerca del cumplimiento y de las infracciones que se producen.
GDPR
Uno de los desarrollos más importantes en esta área es el Reglamento General de Protección de Datos (RGPD),
diseñado para reforzar la protección de los datos de los ciudadanos de la Unión Europea. El RGPD requiere que
los datos personales (como "el nombre, la dirección particular, la fotografía, la dirección de correo electrónico,
los datos bancarios, las publicaciones en los sitios de redes sociales, la información médica o la dirección IP de
un equipo"), se mantengan en servidores que se encuentren dentro de la UE y no transfieran fuera de ella.
También requiere que las empresas envíen notificaciones a los usuarios si se produce cualquier vulneración de
sus datos y exige que haya un responsable de la protección de los datos. Otros países tienen tipos similares de
regulaciones o los están desarrollando.
Base de cumplimiento en Azure

Para ayudar a los clientes a satisfacer sus propias obligaciones de cumplimiento en industrias y mercados
regulados de todo el mundo, Azure mantiene el cumplimiento más amplio del sector, tanto en amplitud
(número total de las ofertas) como en profundidad (número de servicios orientados al cliente en el ámbito de la
evaluación). Las ofertas de cumplimiento de Azure se agrupan en cuatro segmentos:
Global
Gobierno de EE. UU.
Sector
Regional
Las ofertas de cumplimiento de Azure se basan en varios tipos de controles, entre los que se incluyen
certificaciones oficiales, atestaciones, validaciones, autorizaciones y evaluaciones generadas por empresas de
auditoría de terceros independientes, así como enmiendas contractuales, autoevaluaciones y documentos de
instrucciones para el cliente generados por Microsoft. Todas las descripciones de las ofertas de este documento
proporcionan declaraciones actualizadas acerca del ámbito que indican qué servicios orientados al cliente de
Azure están en el ámbito de la valoración, junto con vínculos a recursos descargables para ayudar a los clientes
con sus propias obligaciones de cumplimiento.
El Centro de confianza de Microsoft proporciona información más detallada sobre las ofertas de cumplimiento
de Azure. Además, toda la documentación que se puede descargar está disponible para determinados clientes
de Azure en el Portal de confianza de servicios de Microsoft, en las siguientes secciones:
Informes de auditoría: incluye secciones de FedRAMP, evaluación de GRC, ISO, PCI DSS e informes de
SOC.
Recursos para la protección de datos: incluye guías de cumplimiento, preguntas frecuentes y notas del
producto, así como secciones de prueba de penetración y evaluaciones de seguridad.
Pasos siguientes
Más información sobre la preparación de la seguridad en la nube.
Preparación de la seguridad en la nube
Guía de preparación de CISO para la nube
Las guías de Microsoft, como Cloud Adoption Framework, no están en posición de determinar o guiar las
restricciones de seguridad únicas de las miles de empresas a las que se puede aplicar esta documentación. Al
cambiar a la nube, sus tecnologías no reemplazarán el rol de responsable de la seguridad de la información. Al
contrario, el Director de seguridad de la información y la Oficial principal de seguridad de la información se
integran aún más. En esta guía se da por supuesto que el lector está familiarizado con los procesos de seguridad
de la información y que desea modernizar esos procesos para habilitar la transformación a la nube.
La adopción de la nube permite obtener servicios que a menudo no se tenían en cuenta en los entornos de TI
tradicionales. Normalmente, las implementaciones de autoservicio o automatizadas las ejecuta el equipo de
desarrollo de aplicaciones u otros equipos de TI que tradicionalmente no estaban en línea con la
implementación de producción. En algunas organizaciones, los componentes del negocio tienen capacidades de
autoservicio. Esta opción puede desencadenar nuevos requisitos de seguridad que no eran necesarios en el
entorno local. La seguridad centralizada es un desafío mayor, puesto que a menudo se convierte en una
responsabilidad compartida en la cultura empresarial y de TI. Este artículo puede servirle de ayuda para
preparar un CISO para ese enfoque y que así pueda participar en una gobernanza incremental.
¿Cómo se puede preparar un CISO para la nube?

Tal y como sucede con la mayoría de las directivas, las directivas de seguridad y gobernanza de una
organización tienden a crecer de forma orgánica. Cuando ocurren incidentes de seguridad, se crea la directiva
oportuna para informar a los usuarios y reducir la probabilidad de que estos incidentes se repitan. Si bien es
normal, este método crea una gran cantidad de directivas y dependencias técnicas. Por ello, los recorridos de
transformación a la nube crean una oportunidad única para modernizar y restablecer las directivas. Mientras se
prepara para realizar un recorrido de transformación, el CISO puede crear un valor inmediato y mensurable al
actuar como la parte interesada en una revisión de la directiva.
En dicha revisión, el rol del CISO radica en crear un equilibrio seguro entre las restricciones y el cumplimiento
de la directiva y seleccionar la mejor opción de seguridad de los proveedores en la nube. La medición de este
progreso se puede realizar de muchas formas, aunque a menudo se mide en función de la cantidad de directivas
de seguridad que se pueden descargar de forma segura al proveedor de nube.
Transferencia de riesgos de seguridad. A medida que los servicios se trasladan a los modelos de hospedaje
de infraestructura como servicio (IaaS), la empresa asume menos riesgos directos con respecto al
aprovisionamiento de hardware. El riesgo no se elimina, sino que se transfiere al proveedor de nube. Si el
enfoque de un proveedor de nube para el aprovisionamiento de hardware proporciona el mismo nivel de
mitigación de riesgos y el proceso es seguro y repetible, el riesgo de la ejecución del aprovisionamiento de
hardware se elimina del área de responsabilidad del departamento de TI corporativo y se transfiere al
proveedor de nube. Esto reduce el riesgo de seguridad general que el departamento de TI corporativo es
responsable de administrar, aunque el riesgo en sí debe seguirse y revisarse periódicamente.
A medida que las soluciones se incorporan a modelos de plataforma como servicio (PaaS) o software como
servicio (SaaS), se pueden evitar o transferir otros riesgos adicionales. Cuando el riesgo se transfiere de manera
segura a un proveedor en la nube, el costo de ejecutar, supervisar y aplicar las directivas de seguridad u otras
directivas de cumplimiento también se puede reducir de manera segura.
Mentalidad de crecimiento. Este cambio puede intimidar a la empresa y a los implementadores técnicos.
Cuando el CISO lidera un cambio en la mentalidad de crecimiento de una organización, descubrimos que esos
temores naturales se reemplazan con un mayor interés en la seguridad y el cumplimiento de directivas. Si se
combina una revisión de directivas, un recorrido de transformación o sencillas revisiones de implementación
con una mentalidad de crecimiento, el equipo tendrá la oportunidad de reaccionar rápidamente, pero no a costa
de un perfil de riesgo razonable y manejable.
Recursos para el director de seguridad de la información

El conocimiento sobre la nube es fundamental para combinar una revisión de directivas con una mentalidad de
crecimiento. Los siguientes recursos pueden ayudar al CISO a comprender mejor la postura de seguridad de la
plataforma Azure de Microsoft.
Recursos de la plataforma de seguridad:
Ciclo de vida de desarrollo de la seguridad, auditorías internas
Entrenamiento de seguridad obligatorio, comprobación de antecedentes
Pruebas de penetración, detección de intrusiones, DDoS, auditorías y registros
Centro de datos de vanguardia, seguridad física, red segura
Privacidad y controles:
Administración constante de los datos
Control en la ubicación de los datos
Proporcionar acceso a datos en sus propios términos
Respuesta a las autoridades judiciales
Rigurosos estándares de privacidad
Cumplimiento:
Microsoft Trust Center
Centro de controles comunes
Lista de comprobación de diligencia debida para los servicio en la nube
Cumplimiento nacional y regional
Transparencia:
Cómo Microsoft protege los datos de clientes en servicios de Azure
Cómo administra Microsoft la ubicación de datos en los servicios de Azure
Personas de Microsoft que pueden acceder a sus datos y bajo qué términos
Revisión de la certificación para servicios de Azure, centro de transparencia
Pasos siguientes
El primer paso para tomar medidas en cualquier estrategia de gobernanza es realizar una revisión de directiva.
La sección Directiva y cumplimiento puede ser una guía útil durante la revisión de las directivas.
Prepararse para una revisión de la directiva
Revisión de una directiva de nube
La revisión de una directiva de nube es el primer paso hacia la madurez de la gobernanza de la nube. El objetivo
de este proceso es modernizar las directivas de TI corporativas existentes. Una vez finalizada esta tarea, las
directivas actualizadas proporcionan un nivel equivalente de mitigación de los riesgos para los recursos en la
nube. En este artículo se explica el proceso de revisión de una directiva en la nube y su importancia.
¿Por qué realizar la revisión de una directiva en la nube?

La mayoría de las empresas administran los procesos de TI mediante la ejecución de procesos que están en
consonancia con las directivas en vigor. En las pequeñas empresas, estas directivas pueden ser anecdóticas y los
procesos se definen de manera imprecisa. A medida que las empresas evolucionan para convertirse en grandes
empresas, las directivas y los procesos tienden a documentarse con mayor claridad y a ejecutarse de manera
coherente.
A medida que las empresas maduran las directivas de TI corporativas, las dependencias de las decisiones
técnicas anteriores tienden a filtrarse en las directivas en vigor. Por ejemplo, es habitual observar procesos de
recuperación ante desastres que incluyen directivas que exigen copias de seguridad en cinta fuera del sitio. En
esta inclusión, se supone que existe una dependencia de un tipo de tecnología (copias de seguridad en cinta)
que puede que ya no sea la solución más importante.
Las transformaciones a la nube crean un punto de inflexión natural para reconsiderar las decisiones que se
tomaron en el pasado en las directivas heredadas. Las funcionalidades técnicas y los procesos predeterminados
cambian considerablemente en la nube, al igual que los riesgos heredados. Tomando como referencia el
ejemplo anterior, la directiva de copia de seguridad en cinta derivó del riesgo de tener un único punto de error al
mantener los datos en una sola ubicación y la necesidad empresarial de minimizar el perfil de riesgo mediante
la mitigación de este riesgo. En una implementación en la nube, hay varias opciones que proporcionan la misma
mitigación de riesgos, con objetivos de tiempo de recuperación (RTO) mucho menores. Por ejemplo:
Una solución nativa en la nube podría habilitar la replicación geográfica de la base de datos de Azure
SQL Database.
Una solución híbrida podría usar Azure Site Recovery para replicar una carga de trabajo IaaS en Azure.
Al ejecutar una transformación en la nube, las directivas suelen regular muchas de las herramientas, servicios y
procesos disponibles para los equipos de adopción de la nube. Si esas directivas se basan en tecnologías
heredadas, pueden obstaculizar los esfuerzos del equipo para realizar cambios. En el peor de los casos, el equipo
de migración ignora completamente directivas importantes para aplicar soluciones alternativas. Ninguno es un
resultado aceptable.
Proceso de revisión de directivas en la nube

Las revisiones de directivas de nube alinean las directivas de seguridad de TI y de gobernanza de TI existentes
con las cinco materias de gobernanza de la nube:
Materia de línea de base de seguridad
Materia de la línea de base de identidad
Materia de aceleración de la implementación.
En cada una de estas materias, siga estos pasos en el proceso de revisión:
1. Revise las directivas locales existentes relacionadas con la materia específica, para lo que debe buscar dos
puntos de datos clave: dependencias heredadas y riesgos empresariales identificados.
2. Evalúe cada riesgo empresarial haciendo una pregunta simple: ¿todavía existe riesgo empresarial en un
modelo de nube?
3. Si el riesgo aún existe, vuelva a escribir la directiva y documente la mitigación empresarial necesaria, no la
solución técnica.
4. Revise la directiva actualizada con los equipos de adopción de la nube para entender las posibles soluciones
técnicas para la mitigación necesaria.
Ejemplo de revisión de una directiva heredada

Para proporcionar un ejemplo del proceso, vamos a volver a usar la directiva de copia de seguridad en cinta de
la sección anterior:
Una directiva corporativa exige copias de seguridad en cinta fuera del sitio para todos los sistemas de
producción. En esta directiva, puede ver dos puntos de datos de interés:
Dependencia heredada en una solución de copia de seguridad en cinta.
Un riesgo empresarial asumido asociado con el almacenamiento de copias de seguridad en la misma
ubicación física que el equipo de producción.
¿Existe todavía el riesgo? Sí. Incluso en la nube, la dependencia de una única instalación plantea algunos
riesgos. Existe una probabilidad más baja de que este riesgo afecte a la empresa en comparación con el
riesgo planteado en la solución local, pero el riesgo aún existe.
Vuelva a escribir la directiva. En caso de que se produzca un desastre que afecte a todo el centro de datos,
deben existir métodos para restaurar los sistemas de producción en un plazo de 24 horas después de la
interrupción en otro centro de datos y en una ubicación geográfica distinta.
También es importante tener en cuenta que la escala de tiempo especificada en el requisito anterior
puede haberse establecido por restricciones técnicas que ya no están presentes en la nube. Asegúrese
de que comprende las restricciones técnicas y las funcionalidades de la nube antes de aplicar
simplemente un RTO/RPO heredado.
Revise el caso con los equipos de adopción de la nube. Según la solución implementada, existen varias
formas de cumplir esta directiva de coherencia de recursos.
Pasos siguientes
Obtenga más información sobre cómo incluir la clasificación de datos en su estrategia de gobernanza de la
nube.
Clasificación de los datos
¿Qué es la clasificación de datos?
La clasificación de datos permite determinar y asignar valor a los datos de la organización y proporciona un
punto de partida común para la gobernanza. El proceso de clasificación de datos clasifica los datos por
confidencialidad e impacto empresarial a fin de identificar los riesgos. Cuando los datos están clasificados, se
pueden administrar de formas que protegen aquellos confidenciales o importantes frente al robo o la pérdida.
Comprender los riesgos de los datos y administrarlos

Para administrar cualquier riesgo, hay que entenderlo. En el caso de la responsabilidad por infracción de datos,
ese conocimiento comienza con la clasificación de datos. La clasificación de datos es el proceso de asociar una
característica de metadatos a cada recurso de un entorno digital, que identifica el tipo de datos asociado con ese
recurso.
Cualquier recurso que se haya identificado como un posible candidato para la migración o la implementación
en la nube debería tener metadatos documentados para registrar la clasificación de los datos, la importancia
para la empresa y la responsabilidad de facturación. Estos tres puntos de clasificación pueden recorrer un largo
camino para comprender y mitigar los riesgos.
Clasificaciones que usa Microsoft

La siguiente es una lista de clasificaciones que usa Microsoft. Según su sector o los requisitos de seguridad
existentes, puede que ya existan estándares de clasificación de datos dentro de su organización. Si no existe
ningún estándar, es posible que quiera usar esta clasificación de ejemplo para comprender mejor el patrimonio
digital propio y el perfil de riesgo.
No empresarial: datos de la vida personal que no pertenecen a Microsoft.
Pública: datos comerciales públicamente disponibles y aprobados para uso público.
General: datos empresariales que no están destinados a una audiencia pública.
Confidencial: datos empresariales que pueden causar daños a Microsoft si se compartieran en exceso.
Extremadamente confidencial: datos empresariales que podrían causar graves daños a Microsoft si se
compartieran en exceso.
Etiquetado de la clasificación de datos en Azure

Las etiquetas de recursos son una buena opción para el almacenamiento de metadatos; puede usar estas
etiquetas para aplicar información de clasificación de datos a recursos implementados. Aunque el etiquetado de
los recursos en la nube por clasificación no sustituye a un proceso de clasificación de datos formal, proporciona
una valiosa herramienta para administrar recursos y aplicar directivas. Azure Information Protection es una
solución excelente para ayudarle a clasificar datos, independientemente de dónde se encuentren (en el entorno
local, en Azure, en alguna otra ubicación). Tenga en cuenta esta herramienta como parte de una estrategia
general de clasificación.
Realizar acción
Actúe definiendo y etiquetando los recursos con una clasificación de datos definida.
Elija una de las guías prácticas de gobernanza en la nube para obtener ejemplos de cómo aplicar etiquetas a
toda la cartera.
Revise las convenciones recomendadas de nomenclatura y etiquetado para definir un estándar de etiquetado
más completo.
Para información adicional sobre el etiquetado de recursos, consulte Uso de etiquetas para organizar los
recursos de Azure y la jerarquía de administración.
Pasos siguientes
Más información sobre las cinco disciplinas de la gobernanza de la nube.
Cinco disciplinas de la gobernanza de la nube
Las cinco disciplinas de la gobernanza de la nube
Cualquier cambio en los procesos de negocio o en las plataformas tecnológicas presenta riesgos. Los equipos
de gobernanza de la nube, cuyos miembros se conocen a veces como custodios de la nube, tienen la tarea de
mitigar estos riesgos y de garantizar una interrupción mínima en los esfuerzos de adopción o innovación.
El modelo de gobernanza de Cloud Adoption Framework guía estas decisiones (independientemente de la

plataforma de nube elegida) centrándose en el desarrollo de directivas corporativas y en las cinco materias de
gobernanza de la nube. Las guías de diseño accionables demuestran este modelo utilizando los servicios de
Azure. Obtenga información sobre las materias del modelo de gobernanza del Marco de adopción de la nube a
continuación.
Figura 1: Representación visual de la directiva corporativa y las cinco materias de gobernanza en la nube.
Materias de gobernanza de la nube

Con cualquier plataforma en la nube, existen materias de gobernanza comunes que ayudan a informar las
directivas y a alinear cadenas de herramientas. Estas materias guían las decisiones relativas al nivel adecuado de
automatización y aplicación de las directivas corporativas en las plataformas en la nube.
Administración de costos: El costo es una de las principales

preocupaciones de los usuarios de la nube. Desarrolle
directivas de control de los costos para todas las plataformas
de nube.
Línea de base de seguridad: La seguridad es un asunto

complejo, único para cada empresa. Una vez establecidos los
requisitos de seguridad, las directivas de cumplimiento y
gobernanza de la nube aplican esos requisitos en las
configuraciones de red, datos y recursos.
Línea de base de identidad: Las incoherencias en la aplicación

de los requisitos de identidad pueden aumentar el riesgo de
infracciones. La materia de línea de base de identidad se
centra en garantizar que la identidad se aplique de manera
coherente en los esfuerzos de adopción de la nube.
Coherencia de recursos: Las operaciones en la nube
dependen de una configuración de los recursos coherente.
Con las herramientas de gobernanza, los recursos se pueden
configurar de forma coherente a fin de administrar los
riesgos relativos a la incorporación, el desfase, la capacidad
de detección y la recuperación.
Aceleración de la implementación: La centralización, la

normalización y la coherencia en los enfoques de
implementación y configuración mejoran los procedimientos
de gobernanza. Si se proporcionan mediante herramientas
de gobernanza basadas en la nube, crean un factor de nube
que puede acelerar las actividades de implementación.
Información general sobre la materia de
administración de costos
La materia de Cost Management es una de las cinco materias de la gobernanza en la nube dentro del modelo de
gobernanza de Cloud Adoption Framework. Para muchos clientes, controlar los costos es una preocupación
importante al adoptar tecnologías de nube. Equilibrar las demandas de rendimiento, el ritmo de adopción y los
costos de los servicios en la nube puede suponer todo un desafío. Esto es especialmente pertinente durante las
transformaciones de negocios importantes que implementan tecnologías de nube. En esta sección se describe el
enfoque de desarrollo de una materia de administración de costos como parte de una estrategia de gobernanza
en la nube.
NOTE
La materia de Cost Management no reemplaza los equipos de negocios, las prácticas contables y los procedimientos
existentes que intervienen en la administración financiera de la organización de los costos relacionados con la TI. El
objetivo principal de esta materia es determinar los posibles riesgos relativos a la nube relacionados con el gasto en TI y
proporcionar una guía de mitigación de riesgos para la empresa y los equipos de TI responsables de la implementación y
la administración de los recursos en la nube.
La principal audiencia a la que se dirigen estas instrucciones son los arquitectos de nube de su organización y
otros miembros de su equipo de gobernanza en la nube. Las decisiones, las directivas y los procesos que surgen
de esta materia deben implicar la involucración y los debates con miembros pertinentes de su empresa y de los
equipos de TI, especialmente con directores responsables de la posesión, administración y pago de cargas de
trabajo basadas en la nube.
Policy statements
Las declaraciones de la directiva que requieren acción y los requisitos de arquitectura resultantes actúan como
base de una materia de administración de costos. Use instrucciones de directiva de ejemplo como punto de
partida para definir las directivas de Cost Management.
Cau t i on
Las directivas de ejemplo proceden de experiencias habituales de los clientes. Para alinear mejor estas directivas
con necesidades de gobernanza en la nube específicas, ejecute los pasos siguientes para crear declaraciones de
la directiva que satisfagan sus necesidades empresariales únicas.
Desarrollo de instrucciones de la directiva de gobierno

Los siguientes pasos le ayudarán a definir directivas de gobernanza para controlar los costos en su entorno.
Plantilla de la materia de Cost Management: Descargue la

plantilla para documentar una materia de Cost
Management.
Riesgos empresariales: Conozca los motivos y riesgos
asociados normalmente a la materia de administración de
costos.
Indicadores y métricas: indicadores para saber si es el

momento adecuado para invertir en la materia de
Procesos de adhesión a directivas: Procesos recomendados

para admitir el cumplimiento de directiva en la materia de
Madurez: Alineación de la madurez de la administración de la

nube con las fases de adopción de la nube.
Cadena de herramientas: Servicios de Azure que se pueden

implementar para admitir la materia de administración de
costos.
Pasos siguientes
Empiece evaluando riesgos empresariales en un entorno específico.
Plantilla de la materia de Cost Management
El primer paso para implementar un cambio es comunicarlo. Lo mismo sucede cuando se cambian los
procedimientos de gobernanza. La plantilla siguiente proporciona un punto de partida para documentar y
comunicar las declaraciones de directiva que rigen los problemas de administración de costos en la nube.
A medida que las conversaciones avancen, use la estructura de esta plantilla como modelo para capturar los
riesgos empresariales, las tolerancias a los riesgos, los procesos de cumplimiento y las herramientas necesarias
para definir las declaraciones de las directivas de Administración de costos de la organización.
IMPORTANT
Esta plantilla es un ejemplo limitado. Antes de actualizar esta plantilla para reflejar sus requisitos, debe revisar los pasos
posteriores para definir una materia sobre la administración de los costos eficaz dentro de su estrategia de gobernanza de
la nube.
Descargue la plantilla de la materia de Cost Management
Pasos siguientes
Los procedimientos de gobernanza sólidos comienzan con una comprensión del riesgo empresarial. Revise el
artículo sobre riesgos empresariales y empiece a documentar aquellos que se alinean con su plan de adopción
de la nube actual.
Motivaciones y riesgos empresariales en la materia
de Cost Management
En este artículo se describen las razones por las que los clientes normalmente adoptan una materia de
administración de costos dentro de una estrategia de gobernanza en la nube. También se proporcionan algunos
ejemplos de riesgos empresariales que impulsan las declaraciones de directiva.
Relevancia
En términos de gobernanza de costos, la adopción de la nube genera un cambio de paradigma. La
administración de costos en un mundo local tradicional se basa en ciclos de actualización, adquisiciones de
centros de datos, renovaciones de hosts y problemas de mantenimiento recurrentes. Puede prever, planear y
ajustar estos costos para alinearlos con los presupuestos anuales de gastos de capital.
Para las soluciones de nube, muchas empresas suelen adoptar un enfoque más reactivo ante la administración
de costos. En muchos casos, las empresas compran previamente, o se comprometen a usar, una cantidad
determinada de servicios en la nube. Este modelo da por supuesto que maximizar los descuentos, en función de
cuánto planee gastar la empresa con un proveedor de servicios en la nube específico, crea la percepción de un
ciclo de costos planeado y proactivo. Esa percepción solo se hará realidad si la empresa también implementa
una materia de administración de costos madura.
La nube ofrece capacidades de autoservicio que antes no se conocían en los centros de datos locales
tradicionales. Estas nuevas capacidades permiten a las empresas ser más ágiles, menos restrictivas y más
abiertas en relación con la adopción de nuevas tecnologías. La desventaja del autoservicio es que los usuarios
finales pueden superar los presupuestos asignados sin saberlo. A la inversa, los mismos usuarios pueden
experimentar un cambio en los planes y, de forma inesperada, no utilizar la cantidad de servicios en la nube
previstos. El potencial de cambio en cualquier dirección justifica la inversión en una materia de administración
de costos dentro del equipo de gobernanza.
Riesgo empresarial
La materia de Cost Management intenta abordar los principales riesgos empresariales relacionados con los
gastos que se derivan de hospedar cargas de trabajo basadas en la nube. Trabaje con su empresa para
identificar estos riesgos y supervise cada uno de ellos para determinar su pertinencia a medida que planee y
aplique sus implementaciones en la nube.
Los riesgos variarán según la organización, pero los siguientes sirven como riesgos comunes relacionados con
los costos que puede usar como punto de partida para debatir en el seno de su equipo de gobernanza de la
nube:
Control del presupuesto: No controlar el presupuesto puede llevar a un gasto excesivo con un proveedor
de servicios en la nube.
Pérdida de uso. Las compras previas o los compromisos previos que no se utilicen pueden generar
inversiones perdidas.
Anomalías en el gasto. Los aumentos inesperados en cualquier dirección pueden ser indicadores de un
uso inadecuado.
Recursos sobreaprovisionados. La implementación de los recursos en una configuración que supere las
necesidades de una aplicación o máquina virtual (VM) puede dar lugar a un desperdicio de los recursos.
Pasos siguientes
Utilice la plantilla de Cost Management para documentar los riesgos empresariales que probablemente se
presentarán en el plan de adopción de la nube actual.
Una vez que se consigue una comprensión realista de los riesgos empresariales, el siguiente paso es
documentar la tolerancia al riesgo de la empresa y los indicadores y métricas clave para supervisar esa
tolerancia.
Descripción de indicadores, métricas y tolerancia al riesgo
Métricas e indicadores de tolerancia al riesgo en
materia de Cost Management
Aprenda a cuantificar la tolerancia al riesgo empresarial asociada a la materia de Cost Management. La

definición de métricas e indicadores ayuda a crear un caso empresarial para invertir en la madurez de esta
materia.
Métricas
Por lo general, la administración de costos se centra en las métricas relacionadas con los costos. Como parte del
análisis de riesgos, querrá recopilar datos relativos a los gastos actuales y planeados en cargas de trabajo
basadas en la nube para determinar el riesgo al que se enfrenta y la importancia que la inversión en la materia
de Cost Management tiene en sus implementaciones planeadas en la nube.
A continuación encontrará varios ejemplos de métricas útiles que debe recopilar para evaluar la tolerancia al
riesgo en la materia de administración de costos:
Gastos anuales. El costo total anual de los servicios que presta un proveedor de nube.
Gastos mensuales. El costo total mensual de los servicios que presta un proveedor de nube.
Relación entre costos previstos y reales. La relación que compara los gastos previstos con los reales
(mensuales o anuales).
Relación del ritmo de la adopción (mes a mes): El porcentaje de la diferencia de los costos de la nube
de un mes a otro.
Costo acumulado. Total de gastos diarios acumulados desde principios de mes.
Tendencias de los gastos. Tendencias de los gastos con respecto al presupuesto.
Indicadores de tolerancia al riesgo

Durante las primeras implementaciones a pequeña escala, como desarrollo/pruebas o las primeras cargas de
trabajo experimentales, es probable que la administración de costos tenga un riesgo relativamente bajo. A
medida que se implementan más activos aumenta el riesgo y la tolerancia de la empresa hacia el riesgo es
probable que se rechace. Además, a medida que más equipos de la adopción de la nube tienen la capacidad de
configurar o implementar recursos en la nube, el riesgo aumenta y la tolerancia se reduce. Por el contrario, el
desarrollo de una materia de Cost Management hará que las personas pasen de la fase de adopción de la nube
a implementar tecnologías más innovadoras.
En las primeras fases de la adopción de la nube, trabajará con su empresa para determinar una base de
referencia para la tolerancia al riesgo. Una vez que la tenga, deberá determinar los criterios que desencadenarán
una inversión en la materia sobre la administración de costos. Es probable que dichos criterios sean diferentes
para cada organización.
Una vez que haya identificado los riesgos empresariales, trabajará con su empresa para identificar las pruebas
comparativas que puede usar para detectar los desencadenadores que podrían aumentar dichos riesgos. A
continuación verá algunos ejemplos de la forma en que varias métricas, como las que se han mencionado, se
pueden comparar con la tolerancia de la base de referencia de riesgo, con el fin de conocer el grado de
necesidad que tiene su empresa en invertir más en la administración de costos.
Movido por el compromiso (más habitual). Una empresa que tiene un compromiso de gasto de
x 000 000 de euros este año en un proveedor de nube. Necesita una materia sobre la administración de
costos para asegurarse de que la empresa no supere sus objetivos de gasto en más del 20 % y que van a
usar al menos el 90 % del gasto al que se han comprometido.
Desencadenador por porcentaje. Una empresa con gastos en la nube estables en sus sistemas de
producción. Si esas cifras cambian más de un x % , la materia de administración de costos será una inversión
inteligente.
Desencadenador por sobreaprovisionamiento. Una empresa que cree que sus soluciones
implementadas están sobreaprovisionadas. La administración de costos es una inversión prioritaria hasta
que se demuestra que la relación entre aprovisionamiento y uso de los recursos es adecuada.
Desencadenador por gastos mensuales. Una compañía que gasta más de X 000 euros al mes se
considera un costo considerable. Si los gastos superan esa cantidad en un mes dado, necesitarán invertir en
la administración de costos.
Desencadenador por gastos anuales. Una empresa con un presupuesto para I+D en TI que permita
gastar X 000 euros al año en experimentación en la nube. Pueden ejecutar las cargas de trabajo de
producción en la nube, pero siguen considerándolas soluciones experimentales si el presupuesto no supera
dicha cantidad. Si la supera, tendrán que tratar el presupuesto como si fuera una inversión de producción y
administrar los gastos atentamente.
Gastos de explotación, adversos (no habituales): como empresa, están en contra de los gastos de
explotación y necesitarán instaurar controles de administración de costos antes de implementar una carga de
trabajo de desarrollo o pruebas.
Pasos siguientes
Use la plantilla de materia de Cost Management para documentar las métricas y los indicadores de tolerancia
que están en línea con el plan de adopción de la nube actual.
Revise las directivas de Cost Management de ejemplo como punto de partida para desarrollar otras suyas que
aborden los riesgos empresariales específicos vinculados a los planes de adopción de la nube.
Revisión de las directivas de ejemplo
Declaraciones de directivas de ejemplo de
administración de costos
proceso de evaluación de riesgos. Estas declaraciones deben proporcionar un breve resumen de los riesgos y
los planes para resolverlos. La definición de cada declaración debe incluir estos fragmentos de información:
Riesgo empresarial : Un resumen del riesgo que esta directiva abordará.
Declaración de directiva : Una explicación clara que resuma los requisitos de la directiva.
Opciones de diseño : Recomendaciones que requieren acción, especificaciones u otras instrucciones que
los equipos de TI y los desarrolladores pueden usar al implementar la directiva.
Las siguientes declaraciones de la directiva de ejemplo abordan algunos riesgos empresariales comunes
relacionados con los costos. Estas declaraciones son ejemplos a los que se puede hacer referencia al elaborar el
borrador de las declaraciones de directiva para satisfacer las necesidades de su organización. Estos ejemplos no
pretenden ser excluyentes y hay varias opciones posibles de directiva para solucionar cada riesgo concreto
identificado. Trabaje estrechamente con los equipos de TI y de dirección para identificar las mejores directivas
para su conjunto de riesgos en particular.
Perdurabilidad
Riesgo empresarial : Criterios actuales que no garantizan una inversión en una materia de Cost Management
por parte del equipo de gobernanza, aunque usted anticipa una inversión en el futuro.
Declaración de directiva : debe asociar todos los recursos implementados en la nube con una unidad de
facturación, una aplicación o una carga de trabajo. Esta directiva garantizará que la materia de Cost
Management sea eficaz.
Opciones de diseño : para obtener información sobre cómo establecer una base orientada al futuro, consulte
los artículos relacionados con la creación de un producto viable mínimo de gobernanza en las guías prácticas
sobre diseño, incluidas como parte de la guía Cloud Adoption Framework.
Rebasamientos del presupuesto

Riesgo empresarial : la implementación de autoservicio plantea un riesgo de exceso de gastos.
Declaración de directiva : todas las implementaciones en la nube deben asignarse a una unidad de
facturación con un presupuesto aprobado y un mecanismo para establecer límites presupuestarios.
Opciones de diseño : en Azure, puede controlar el presupuesto con Azure Cost Management + Billing.
Infrautilización
Riesgo empresarial : la empresa ha realizado el prepago de servicios en la nube o ha asumido un compromiso
anual de gasto de una cantidad específica. Existe el riesgo de que no se use la cantidad acordada, lo que supone
una pérdida de la inversión.
Declaración de directiva : Cada unidad de facturación con un presupuesto asignado para la nube se reunirá
cada año para determinar los presupuestos, cada trimestre para ajustarlos y todos los meses para asignar el
tiempo para revisar el gasto previsto frente al real. Analice todas las desviaciones superiores al 20 % con el jefe
de la unidad de facturación con carácter mensual. Para fines de seguimiento, asigne todos los recursos a una
unidad de facturación.
Opciones de diseño :
en Azure, el gasto planeado frente al real se puede administrar con Azure Cost Management + Billing.
Hay varias opciones para agrupar recursos por unidad de facturación. En Azure, es necesario elegir un
modelo de coherencia de recursos en colaboración con el equipo de gobernanza, que se deberá aplicar a
todos los recursos.
Recursos sobreaprovisionados
Riesgo empresarial : en los centros de datos locales tradicionales, es una práctica habitual implementar los
recursos con un planeamiento de capacidad adicional para abordar el crecimiento en un futuro lejano. La nube
puede escalar más rápido que el equipo tradicional. Los precios de los recursos en la nube también se fijan en
función de la capacidad técnica. Existe el riesgo de que la antigua práctica local infle el gasto en la nube
artificialmente.
Declaración de directiva : todos los recursos implementados en la nube deben inscribirse en un programa
que pueda supervisar la utilización y notificar cualquier aumento de capacidad por encima del 50 % de
utilización. Todos los recursos implementados en la nube deben agruparse o etiquetarse de forma lógica, para
que los miembros del equipo de gobernanza puedan interactuar con el propietario de la carga de trabajo para
abordar cualquier optimización de recursos sobreaprovisionados.
en Azure, Azure Advisor puede proporcionar recomendaciones de optimización.
Hay varias opciones para agrupar recursos por unidad de facturación. En Azure, es necesario elegir un
todos los recursos.
Sobreoptimización
Riesgo empresarial : una administración de costos eficaz puede plantear nuevos riesgos. La optimización del
gasto es lo contrario al rendimiento del sistema. Al reducir los costos, existe el riesgo de restringir
excesivamente el gasto y crear experiencia de usuario deficientes.
Declaración de directiva : todos los recursos que afecten a las experiencias de los clientes deben identificarse
mediante agrupación o etiquetado. Antes de optimizar todos los recursos que afecten a la experiencia del
cliente, el equipo de gobernanza de la nube debe ajustar la optimización basándose en las tendencias de
utilización de 90 días como mínimo. Documente todos los picos temporales o basados en eventos que se han
tenido en cuenta para optimizar los recursos.
en Azure, las características de información de Azure Monitor pueden facilitar el análisis de la utilización del
sistema.
Hay varias opciones para agrupar y etiquetar los recursos en función de los roles. En Azure, debe elegir un
todos los recursos.
Pasos siguientes
Use los ejemplos mencionados en este artículo como punto de partida para desarrollar directivas que aborden
los riesgos de negocio específicos que se alinean con los planes de adopción de la nube.
Para empezar a desarrollar sus propias declaraciones de directivas de Cost Management, descargue la plantilla
de directivas de Cost Management.
Para acelerar la adopción de esta materia, elija la guía accionable de gobernanza que más se ajuste a su entorno.
Después, modifique el diseño para incorporar las decisiones de directiva específicas de su organización.
A partir de los riesgos y la tolerancia, establezca un proceso para gobernar y comunicar la adhesión a la
directiva de administración de costos.
Establecimiento de procesos para el cumplimiento de directivas
Procesos de cumplimiento de directivas de Cost
Management
En este artículo se explica un enfoque de creación de procesos que admiten una materia de Cost Management
eficaz. Una gobernanza eficaz de los costos de la nube empieza con procesos manuales periódicos diseñados
para admitir el cumplimiento de directivas. Esto requiere la participación regular del equipo de gobernanza de la
nube y las partes interesadas de la empresa para revisar y actualizar la directiva y garantizar el cumplimiento de
las directivas. Además, muchos procesos de aplicación y supervisión en curso se pueden automatizar o
complementar con herramientas para reducir la sobrecarga de la gobernanza y permitir una respuesta más
rápida a la desviación de directivas.
Procesos de planeamiento, revisión y generación de informes

Las mejores herramientas de Cost Management en la nube son solo tan buenas como los procesos y directivas
que admiten. A continuación se muestra un conjunto de procesos de ejemplo habitualmente implicados en la
materia de Cost Management. Use estos ejemplos como punto de partida al planear los procesos que le
permitirán continuar actualizando la directiva de costos según los cambios del negocio y los comentarios de los
equipos empresariales sujetos a la guía de gobernanza de costos.
Planeamiento y evaluación inicial de los riesgos: como parte de su adopción inicial de la materia de Cost
Management, identifique sus principales riesgos empresariales y tolerancias relacionadas con los costos de la
nube. Use esta información para debatir sobre el presupuesto y los riesgos relacionados con los costos con los
miembros de sus equipos empresariales y desarrollar un conjunto de base de referencia de directivas para
mitigar estos riesgos a fin de establecer su estrategia de gobernanza inicial.
Planeación de la implementación: antes de implementar cualquier recurso, establezca un presupuesto
previsto en función de la asignación en la nube esperada. Asegúrese de que se documenta la información de
propiedad y contabilidad para la implementación.
Planeación anual: realice un análisis de acumulación de todos los recursos implementados y aquellos que se
van a implementar de forma anual. Alinee los presupuestos por unidades de negocio, departamentos, equipos y
otras divisiones adecuadas para impulsar la adopción de autoservicio. Asegúrese de que el líder de cada unidad
de facturación tenga conocimiento del presupuesto y de cómo realizar un seguimiento de los gastos.
Este es el momento de hacer una preasignación o adquisición previa para maximizar los descuentos. Es
conveniente alinear los presupuestos anuales con el año fiscal del proveedor de nube para aprovechar más las
opciones de descuento de fin de año.
Planeación trimestral: revise los presupuestos de forma trimestral con cada líder de la unidad de facturación
para alinear la previsión y los gastos reales. Si hay cambios en el plan o patrones de gastos inesperados, alinee y
reasigne el presupuesto.
Este proceso de planeamiento trimestral también es un buen momento para evaluar si el equipo de gobernanza
de la nube actual está abordando las carencias de conocimientos relacionadas con los planes de negocios
actuales o futuros. Invite al personal pertinente y los propietarios de la carga de trabajo a participar en las
revisiones y la planeación como asesores temporales o miembros permanentes del equipo.
Educación y aprendizaje: ofrezca sesiones de aprendizaje bimensuales para asegurarse de que el personal de
TI y la dirección está al día de los últimos requisitos de la directiva de administración de costos. Como parte de
este proceso, revise y actualice cualquier documentación, guía u otros recursos de aprendizaje para asegurarse
de que estén sincronizados con las declaraciones de directiva corporativa más recientes.
Informes mensuales: de forma mensual, notifique los gastos reales frente a la previsión. Informe a los líderes
de facturación de cualquier desviación inesperada.
Estos procesos básicos ayudarán a alinear los gastos y establecer una base de la materia de Cost Management.
Procesos de supervisión en curso

Una estrategia de Cost Management correcta depende de la visibilidad de los gastos relacionados con la nube
pasados, actuales y futuros planeados. Sin la capacidad para analizar las métricas pertinentes y los datos de sus
costos existentes, no se pueden identificar cambios en los riesgos o detectar infracciones de las tolerancias al
riesgo. Los procesos de gobernanza en curso explicados anteriormente requieren datos de calidad para
asegurarse de que se puede modificar la directiva para proteger mejor la infraestructura contra requisitos
empresariales en constante cambio y el uso de la nube.
Asegúrese de que sus equipos de TI han implementado sistemas automatizados para supervisar sus gastos en
la nube y el uso de desviaciones no planeadas de los costos esperados. Establezca sistemas de informes y
alertas para garantizar la detección rápida y la mitigación de posibles infracciones de la directiva.
Desencadenadores de infracción de cumplimiento y acciones de

cumplimiento
Al detectarse las infracciones, debe tomar medidas de cumplimiento para la nueva alineación con la directiva.
Puede automatizar la mayoría de los desencadenadores de infracción con las herramientas descritas en la
cadena de herramientas de Cost Management de Azure.
A continuación, se muestran ejemplos de desencadenadores:
Desviaciones de presupuesto mensuales: debata toda desviación en los gastos mensuales que supere el
20 % de la proporción del gasto previsto frente al real con el líder de la unidad de facturación. Resoluciones
de registro y cambios en la previsión.
Ritmo de adopción: toda desviación en un nivel de suscripción que supere el 20 % desencadenará una
revisión con el líder de la unidad de facturación. Resoluciones de registro y cambios en la previsión.
Pasos siguientes
Use la plantilla de la materia de Cost Management para documentar los procesos y los desencadenadores que
se alinean con el plan de adopción actual de la nube.
Para obtener instrucciones sobre cómo ejecutar directivas de Cost Management de conformidad con los planes
de adopción, consulte Mejora de la materia de Cost Management.
La materia de Cost Management intenta abordar los principales riesgos empresariales relacionados con los
gastos que se derivan de hospedar cargas de trabajo basadas en la nube. Dentro de las cinco materias de
gobernanza de la nube, la materia Cost Management está involucrada en el control de costos y el uso de los
recursos en la nube con el objetivo de crear y mantener un ciclo de costos planificado.
En este artículo se describen las tareas potenciales que su empresa realiza para desarrollar y desarrollar la
disciplina de Cost Management. Estas tareas se pueden desglosar en las fases de planeamiento, compilación,
adopción y operación de implementación de una solución en la nube. Las tareas se iteran posteriormente para
permitir el desarrollo de una enfoque incremental a para la gobernanza de la nube.
Figura 1: fases de un enfoque incremental al gobierno en la nube.

Ningún documento único puede dar cuenta de los requisitos de todas las empresas. Por lo tanto, en este artículo
se detallan ejemplos de actividades mínimas y potenciales sugeridas para cada fase del proceso de desarrollo de
la gobernanza. El objetivo inicial de estas actividades es ayudarle a crear un producto viable mínimo de directiva
y establecer un marco para la mejora incremental de las directivas. El equipo de gobernanza de la nube deberá
decidir cuánto invertir en estas actividades para mejorar las funcionalidades de la materia de Cost Management.
Cau t i on
Ni las actividades mínimas ni las posibles que se describen en este artículo están en línea con directivas
corporativas específicas ni con requisitos de cumplimiento de terceros. Esta guía está diseñada como ayuda para
facilitar las conversaciones que darán lugar a la alineación de los requisitos con un modelo de gobernanza de la
nube.
Planeamiento y preparación
Esta fase del desarrollo de la gobernanza permite salvar las diferencias entre los resultados empresariales y
unas estrategias accionables. Durante este proceso, el equipo directivo define métricas específicas, las asigna al
patrimonio digital y empieza a planear el esfuerzo global de migración.
Actividades mínimas sugeridas:
Evalúe las opciones de la cadena de herramientas de Cost Management.
Elabore un documento borrador de las directrices de arquitectura y distribúyalo a las partes interesadas
clave.
Eduque e implique a las personas y equipos a los que afectará el desarrollo de las directrices de arquitectura.
Posible actividades:
Asegúrese de tomar decisiones presupuestarias que respalden la justificación comercial de su estrategia en
la nube.
Valide las métricas de aprendizaje que usa para informar sobre la asignación exitosa de fondos.
Comprenda el modelo de contabilidad en la nube seleccionado y que afecta al modo de contabilizar los
costos de la nube.
Familiarícese con el plan de patrimonio digital y valide las expectativas de costos exactos.
Evalúe las opciones de compra para determinar si es mejor el "pago por uso" o realizar un compromiso
previo mediante la compra de un Contrato Enterprise.
Alinee los objetivos comerciales con los presupuestos planificados y ajuste los planes presupuestarios según
sea necesario.
Desarrolle un mecanismo de notificación de objetivos y presupuestos para enviar una notificación a las
partes técnicas y comerciales interesadas al final de cada ciclo de costos.
Compilación y fase anterior a la implementación

Se necesitan varios requisitos técnicos y no técnicos para migrar correctamente un entorno. Este proceso se
centra en las decisiones, la preparación y la infraestructura principal que precede a una migración.
Para implementar su cadena de herramientas de administración de costos, agréguela en una fase anterior a
la implementación.
Actualice el documento de directrices de arquitectura y distribúyalo a las partes interesadas clave.
Desarrolle materiales y documentación educativos, comunicaciones de concienciación, incentivos y otros
programas para ayudar a impulsar la adopción por parte de los usuarios.
Determine si los requisitos de compra se alinean con los presupuestos y objetivos.
Alinee sus planes presupuestarios con la estrategia de suscripción que defina su modelo de propiedad
principal.
Use la estrategia de la disciplina de Coherencia de los recursos para aplicar las instrucciones de arquitectura
y costos con el tiempo.
Determine si existen anomalías en los costos que afecten a los planes de adopción y migración.
Adopción y migración
La migración es un proceso incremental que se centra en el traslado, las pruebas y la adopción de las
aplicaciones o cargas de trabajo de un patrimonio digital existente.
Migre su cadena de herramientas de administración de costos de la fase anterior a la implementación a la
fase de producción.
Actualice el documento de directrices de arquitectura y distribúyalo a las partes interesadas clave.
Implemente su modelo de contabilidad en la nube.
Asegúrese de que sus presupuestos reflejen los gastos reales durante cada lanzamiento y ajústelos según
sea necesario.
Supervise los cambios en los planes presupuestarios y confirme con las partes interesadas si es necesario
realizar aprobaciones adicionales.
Actualice los cambios en el documento de las directrices de arquitectura para reflejar los costos reales.
Funcionamiento y fase posterior a la implementación
Una vez completada la transformación, la gobernanza y las operaciones deben estar disponibles durante el ciclo
de vida natural de una aplicación o carga de trabajo. Esta fase de desarrollo de la gobernanza se centra en las
actividades que surgen habitualmente cuando la solución ya está implementada y el ciclo de transformación
comienza a estabilizarse.
Personalice la cadena de herramientas de Cost Management según las necesidades cambiantes de su
organización.
Considere la posibilidad de automatizar cualquier notificación e informe para reflejar el gasto real.
Mejore las directrices de arquitectura para guiar los procesos de adopción futuros.
Ofrezca cursos a los equipos afectados de forma periódica para garantizar que se cumplan las directrices de
arquitectura.
Ejecute una revisión trimestral del negocio en la nube para saber el valor entregado al negocio y los costos
asociados.
Ajuste los planes trimestralmente para reflejar los cambios en los gastos reales.
Determine la alineación financiera con los P&L para las suscripciones de las unidades de negocio.
Analice mensualmente el valor y los métodos de notificación de costos con las partes interesadas.
Corrija los recursos infrautilizados y determine si merece la pena continuar con ellos.
Detecte desajustes y anomalías entre los gastos planeados y los reales.
Ayude a los equipos de adopción y estrategia de la nube a conocer y resolver estas anomalías.
Pasos siguientes
Ahora que comprende el concepto de gobernanza de los costos de la nube, revise los procedimientos
recomendados de administración de costos para encontrar formas de reducir sus gastos generales.
Procedimiento recomendados en la materia de administración de costos
Procedimientos recomendados para la gestión de
costos y los ajustes de tamaño de los recursos
hospedados en Azure
Cuando se trata de ofrecer materia sobre gobernanza, la administración de costos es un tema recurrente a nivel
de la empresa. Si optimiza y administra los costos, puede garantizar el éxito a largo plazo de su entorno de
Azure. Es fundamental que todos los equipos (como el de finanzas, administración y equipos de desarrollo de
aplicaciones) conozcan los costos asociados y los revisen de forma periódica.
Procedimientos recomendados por equipo y responsabilidad

La administración de costos en toda la empresa es una función de gobernanza en la nube y de operación en la
nube. Todas las decisiones de administración de costos generan un cambio en los recursos que admiten una
carga de trabajo. Cuando estos cambios afectan a la arquitectura de una carga de trabajo, se requieren
consideraciones adicionales para minimizar el impacto en los usuarios finales y las funciones empresariales. Es
probable que el equipo de adopción de la nube que ha configurado o desarrollado esa carga de trabajo siga
siendo responsable de completar esos tipos de cambios.
En conjunto, los equipos centralizados y descentralizados deben colaborar para asegurarse de que se
implementan los siguientes comportamientos generales en la cartera:
El etiquetado es fundamental para toda gobernanza. Asegúrese de que todas las cargas de trabajo y
los recursos sigan convenciones de nomenclatura y etiquetado adecuadas y aplique convenciones de
etiquetado con Azure Policy. Esto ayudará a los equipos de gobierno centralizados a tomar decisiones de
administración de costos adecuadas.
Alineación de licencias: la asignación adecuada de Ventaja híbrida de Azure y Azure Reserved VM
Instances reducirá de forma significativa el costo por unidad de los recursos de toda la cartera.
Generalmente, las funciones de adquisición centralizadas establecen y mantienen estos tipos de decisiones
sobre licencias. Sin embargo, es posible que los equipos de la carga de trabajo descentralizada deseen ser
consultados en la compra y la asignación de licencias para minimizar el costo de sus cargas de trabajo
individuales.
Identificación de las opor tunidades de tamaño correctas. Revise los requisitos de rendimiento y uso
de recursos actuales en todo el entorno. modifique cada recurso para usar la SKU o la instancia más pequeña
que pueda admitir los requisitos de rendimiento de cada recurso.
Apagado y desaprovisionamiento de los recursos no utilizados: los recursos no utilizados agregan
costo a un entorno en la nube. Identifique y finalice los recursos que agregan costos, pero no agregan valor
empresarial.
Escalabilidad horizontal frente a la ver tical. El uso de varias instancias pequeñas puede permitir una
ruta de escalado más sencilla que una única instancia de mayor tamaño. De este modo, se permite la
automatización de la escalabilidad y, en consecuencia, se optimizan los costos.
Procedimientos recomendados de administración de costos

operativos
Normalmente, un miembro del equipo de gobernanza de la nube o de operaciones en la nube completa los
siguientes procedimientos recomendados, de acuerdo con los procesos de aplicación de revisiones y otros
procesos de mantenimiento programados. Estos procedimientos recomendados se asignan a una guía
procesable más adelante en este artículo.
El etiquetado es fundamental para toda gobernanza: Asegúrese de que todas las cargas de trabajo y
los recursos sigan convenciones de nomenclatura y etiquetado adecuadas y aplique convenciones de
etiquetado con Azure Policy.
Alineación de licencias: El impacto más inmediato en el costo de una amplia cartera de cargas de trabajo
proviene de una estrategia de adquisición de licencias bien planeada. La compra y la asignación de Ventaja
híbrida de Azure, Azure Reserved VM Instances, máquinas virtuales de acceso puntual y otras estrategias de
compra reducirán rápidamente los costos en toda la cartera de servicios en la nube.
Identificación de las opor tunidades de tamaño correcto: Revise los requisitos actuales de uso de
recursos y rendimiento en el entorno para identificar los recursos que han sido subutilizados durante un
período de tiempo (por lo general, más de 90 días).
SKU aprovisionadas de tamaño correcto: modifique el recurso subutilizado para usar la SKU o la
instancia más pequeña que pueda admitir los requisitos de rendimiento de cada recurso.
Apagado automático de máquinas vir tuales: Cuando una VM no está en uso constante, considere el
apagado automático. La máquina virtual no se eliminará ni se retirará, pero dejará de consumir costos de
proceso y memoria hasta que se vuelva a activar.
Apagado automático de todos los recursos que no son de producción: si una VM forma parte de un
entorno que no es de producción, específicamente entornos de desarrollo, establezca una directiva de
apagado automático para reducir los costos no usados. Siempre que sea posible, use Azure DevTest Labs
como opción de autoservicio para ayudar a que los desarrolladores se hagan responsables del costo.
Apagado y retirada de los recursos no utilizados: Sí, lo indicamos dos veces. Si un recurso no se ha
usado durante más de 90 días y no tiene ningún requisito de tiempo de actividad claro, simplemente
desactívelo. Y, lo que es más importante, si se ha detenido o apagado una máquina durante más de 90 días,
desaprovisione y elimine ese recurso. Valide que se cumpla toda directiva de retención de datos a través de
copias de seguridad u otros mecanismos.
Limpieza de los discos huérfanos: Elimine el almacenamiento que no se usa, especialmente el
almacenamiento de máquinas virtuales que ya no está conectado a ninguna máquina virtual.
Redundancia del tamaño correcto: Si el recurso no requiere un alto grado de redundancia, quite el
almacenamiento con redundancia geográfica.
Ajuste de los parámetros de escalabilidad automática: la supervisión operativa es probable que
descubra patrones de uso para varios recursos. Cuando esos patrones de uso se asignan a los parámetros
que se usan para controlar los comportamientos de escalabilidad automática, es habitual que el equipo de
operaciones ajuste los parámetros de escalabilidad automática para satisfacer la demanda estacional o los
cambios en las asignaciones de presupuesto. Revise los procedimientos recomendados de administración de
costos de las cargas de trabajo para conocer las precauciones previas importantes.
Procedimientos recomendados de administración de costos de las

cargas de trabajo
Antes de realizar cambios en la arquitectura, consulte al responsable técnico de la carga de trabajo. Facilite una
revisión de la carga de trabajo mediante la reseña de buena arquitectura de Microsoft Azure y el marco de
buena arquitectura de Microsoft Azure para guiar las decisiones con respecto a los siguientes tipos de cambios
arquitectónicos.
Azure App Ser vice. Compruebe los requisitos de producción para los planes de App Service de nivel
Premium. Si no se conocen los requisitos empresariales de una carga de trabajo y la configuración de los
recursos subyacentes, es difícil determinar si se requiere un plan de nivel Premium.
Escalabilidad horizontal frente a la ver tical. El uso de varias instancias pequeñas puede permitir una
ruta de escalado más sencilla que una única instancia de mayor tamaño. De este modo, se permite la
automatización de la escalabilidad y, en consecuencia, se optimizan los costos. Antes de que una carga de
trabajo se pueda escalar horizontalmente, el equipo técnico debe comprobar que la aplicación sea
idempotente. Lograr el escalado horizontal puede requerir primero cambios en el código y la configuración
de varias capas de la aplicación.
Escalabilidad automática. Habilite la escalabilidad automática en todos los servicios de aplicaciones para
permitir un número ampliable de máquinas virtuales más pequeñas. La habilitación del escalado automático
tiene el mismo requisito de idempotencia, lo que requiere una comprensión de la arquitectura de la carga de
trabajo. El equipo de adopción debe aprobar la carga de trabajo y los recursos auxiliares para el escalado
horizontal y la escalabilidad automática, antes de cualquier cambio operativo.
Implementación de tecnologías sin ser vidor : A menudo, las cargas de trabajo de máquina virtual se
migran "tal cual" para evitar tiempos de inactividad. Con frecuencia, pueden hospedar tareas intermitentes,
que tardan poco en ejecutarse o a veces muchas horas. Por ejemplo, las máquinas virtuales que ejecutan
tareas programadas, como las del programador de tareas de Windows o los scripts de PowerShell. Sin
embargo, cuando estas tareas no se están ejecutando, está incurriendo en gastos por la máquina virtual y el
almacenamiento en disco. Después de la migración, considere la posibilidad de volver a diseñar las capas de
la carga de trabajo en tecnologías sin servidor, como trabajos de Azure Functions o de Azure Batch.
Procedimientos recomendados viables

En el resto de este artículo se proporcionan ejemplos tácticos de los procedimientos recomendados que un
equipo de gobernanza de la nube o de operaciones en la nube puede seguir para optimizar el costo en toda la
empresa.
Antes de la adopción
Antes de mover las cargas de trabajo a la nube, valore el costo mensual que supone ejecutarlas en Azure. Una
administración proactiva de los costos de la nube le ayuda a cumplir su presupuesto para los gastos operativos.
Los procedimientos recomendados de esta sección le ayudarán a calcular los costos y a realizar el ajuste de
tamaño correcto de las VM y del almacenamiento antes de implementar una carga de trabajo en la nube.
Procedimiento recomendado: Evalúe los costos de la carga de trabajo

mensualmente
Para realizar la previsión de la factura mensual de los recursos de Azure, puede usar varias herramientas.
Calculadora de precios de Azure: seleccione los productos que desea calcular, por ejemplo, las
máquinas virtuales y el almacenamiento, y escriba los costos en la calculadora para crear una estimación.
Calculadora de precios de Azure.
Azure Migrate: Para calcular los costos, debe revisar y tener en cuenta todos los recursos necesarios
para ejecutar sus cargas de trabajo en Azure. A fin de obtener estos datos, cree un inventario de sus
activos, incluidos los servidores, las máquinas virtuales, las bases de datos y el almacenamiento. Puede
usar Azure Migrate para recopilar esta información.
Azure Migrate detecta y evalúa el entorno local para proporcionar un inventario.
Azure Migrate puede asignar y mostrar las dependencias entre las máquinas virtuales para que
tenga una imagen completa.
Una evaluación de Azure Migrate contiene el costo estimado.
Costos de proceso: con el tamaño de máquina virtual de Azure recomendado cuando se crea
una evaluación, Azure Migrate usa las API de facturación de Azure para calcular los costos
mensuales estimados de cada máquina virtual. El cálculo considera la configuración del sistema
operativo, Software Assurance, Azure Reserved VM Instances, el tiempo de actividad de las
máquinas virtuales, la ubicación y la moneda. Suma el costo de todas las máquinas virtuales de
la valoración y calcula un costo de proceso total mensual.
Costo de almacenamiento : Azure Migrate calcula los costos de almacenamiento mensuales
totales; para ello, suma los costos de almacenamiento de todas las máquinas virtuales de la
evaluación. Puede sumar el costo mensual de todos los discos conectados a una máquina
concreta para calcular el costo de almacenamiento mensual de dicha máquina.
Evaluación de Azure Migrate.
Más información:
Use la calculadora de precios de Azure.
Consulte la sección Información general de Azure Migrate.
Obtenga información sobre las evaluaciones de Azure Migrate.
Obtenga información sobre Azure Database Migration Service.
Procedimiento recomendado: Elección del tamaño adecuado para las

máquinas virtuales
Puede elegir varias opciones al implementar las máquinas virtuales de Azure para admitir cargas de trabajo.
Cada tipo tiene características específicas y combinaciones diferentes de CPU, memoria y discos. Las máquinas
virtuales se agrupan como sigue:
Uso general Uso equilibrado de CPU y memoria. Adecuada para pruebas y desarrollo,
bases de datos de tamaño pequeño o
mediano, y servidores web de tráfico
bajo o medio.
Optimizada para proceso Uso elevado de la CPU respecto a la Adecuada para servidores web con un
memoria. volumen de tráfico medio, aplicaciones
de red, procesos por lotes y servidores
de aplicaciones.
Optimizada para memoria Memoria alta en relación con CPU. Adecuada para bases de datos
relacionales, memorias caché de
tamaño mediano a grande y análisis en
memoria.
Almacenamiento optimizado Alto rendimiento de disco y E/S. Adecuado para bases de datos SQL y
NoSQL y de macrodatos.
GPU optimizada Máquinas virtuales especializadas. Una Gráficos pesados y edición de vídeo.
o varias GPU.
Alto rendimiento CPU más rápida y eficaz. Máquinas Aplicaciones críticas de alto
virtuales con interfaces de red de alto rendimiento.
rendimiento (RDMA) opcionales.
Es importante comprender las diferencias de precio entre estas máquinas virtuales y los efectos a largo plazo
en el presupuesto.
Cada tipo tiene varias series de VM.
Además, cuando se selecciona una máquina virtual dentro de una serie, solo puede escalar la máquina
virtual y reducirla verticalmente dentro de esa serie. Por ejemplo, una instancia de DS2_v2 se puede escalar
verticalmente a DS4_v2 , pero no se puede cambiar a una instancia de otra serie, como F2S_v2 .
Más información:
Obtenga más información sobre los tipos de máquina virtual y el tamaño, y asigne tamaños a los tipos.
Planee el tamaño de las máquinas virtuales.
Revise un ejemplo de valoración de la empresa ficticia Contoso.
Procedimiento recomendado: Selección del almacenamiento correcto

El ajuste y el mantenimiento del almacenamiento local (SAN o NAS) y las redes para admitirlo puede resultar
costoso y lento. Los datos de los archivos (almacenamiento) normalmente se migran a la nube para ayudar a
aliviar las dificultades de administración y operativas. Microsoft ofrece varias opciones para mover datos a
Azure. Debe tomar decisiones acerca de esas opciones. Seleccionar el tipo correcto para el almacenamiento de
los datos puede ahorrar a la organización varios miles de dólares al mes. Algunas consideraciones:
Los datos a los que no se accede mucho y no son críticos para la empresa no deben colocarse en el
almacenamiento más costoso.
Por el contrario, los datos empresariales importantes deben ubicarse en las opciones de almacenamiento de
nivel superior.
Durante el planeamiento de la adopción, realice un inventario de los datos y clasifíquelos según su
importancia, con el fin de asignarlos al almacenamiento más adecuado. Considere el presupuesto y los
costos, así como el rendimiento. El costo no debería ser necesariamente el factor principal a la hora de
decidir. Seleccionar la opción menos cara podría exponer a la carga de trabajo a riesgos relacionados con la
disponibilidad y el rendimiento.
Tipos de datos de almacenamiento
Azure proporciona diferentes tipos de datos de almacenamiento.
Blobs Optimizado para almacenar grandes Permite el acceso a datos desde

cantidades de datos de objetos no cualquier lugar a través de
estructurados, como datos de texto o HTTP/HTTPS.
binarios.
Se usa para escenarios de acceso
aleatorio y streaming. Por ejemplo,
para servir imágenes y documentos
directamente a un explorador,
secuencias de vídeo y audio, y
almacenar los datos de recuperación
ante desastres y copia de seguridad.
Archivos Recursos compartidos de archivos Se usa al migrar recursos compartidos

administrados a los que se accede a de archivos locales y para proporcionar
través de SMB 3.0. varios tipos de acceso y conexiones a
los datos de los archivos.
Discos En función de los blobs en páginas. Se usan discos Premium para las
máquinas virtuales. Se usan discos
Tipo de disco (velocidad): HDD administrados para simplificar la
estándar, SSD estándar, SSD Premium administración y la escala.
o Discos Ultra.
Administración de discos: no
administrado (se administra la
configuración de los discos y el
almacenamiento) o administrado (se
selecciona el tipo de disco y Azure lo
administra en su lugar).
Colas Se almacenan y recuperan grandes Se conectan componentes de

cantidades de mensajes, a los que se aplicaciones con colas de mensajes
accede a través de llamadas asincrónicas.
autenticadas (HTTP o HTTPS).
Tablas Se almacenan tablas. Ahora forma parte de Table API de

Azure Cosmos DB.
Niveles de acceso
Azure Storage ofrece diferentes opciones para obtener acceso a los datos de blob en bloques. Si selecciona el
nivel de acceso adecuado, ayuda a garantizar que almacena los datos de blob en bloques de la manera más
rentable.
N IVEL DE A C C ESO DETA L L ES USO
Acceso frecuente Mayores costos de almacenamiento, Se emplea para datos en uso activo a
menores costos de acceso y los que se accede con frecuencia.
transacciones
Este es el nivel de acceso

predeterminado.
Acceso esporádico Menores costos de almacenamiento, El almacenamiento es a corto plazo y

mayores costos de acceso y los datos están disponibles, pero se
transacciones. accede a ellos con poca frecuencia.
El almacenamiento es para 30 días

como mínimo.
Archivar Se usa para blobs en bloques Se usa para los datos que pueden
individuales. tolerar varias horas de latencia de
recuperación y que permanecerán en
Es la opción más rentable para el el nivel de archivo durante un mínimo
almacenamiento. Menores costos de de 180 días.
almacenamiento, mayores costos de
acceso y transacciones.
Tipos de cuenta de almacenamiento

Azure proporciona diferentes tipos de cuentas de almacenamiento y niveles de rendimiento.
T IP O DE C UEN TA DETA L L ES USO
Nivel estándar de uso general v2 Admite blobs (de bloques, páginas, Se usa para la mayoría de los
anexos), archivos, discos, colas y tablas. escenarios y la mayoría de los tipos de
datos. Las cuentas de almacenamiento
Admite los niveles de acceso frecuente, estándar pueden basarse en HDD o en
esporádico y de archivo. Se admite el SSD.
almacenamiento con redundancia de
zona (ZRS).
Nivel Premium de uso general v2 Admite datos de Blob Storage (blobs Microsoft recomienda usarlo para
en páginas). Admite los niveles de todas las máquinas virtuales.
acceso frecuente, esporádico y de
archivo. Se admite ZRS.
Se almacena en SSD.
Uso general v1 No se admiten los niveles de acceso. Se usa si las aplicaciones necesitan el
No admite ZRS. modelo de implementación clásica de
Azure.
Blob Es la cuenta de almacenamiento En estas cuentas no se pueden

especializada para almacenar los almacenar blobs en páginas y, por lo
objetos no estructurados. Proporciona tanto, no se pueden almacenar
solo los blobs en bloques y blobs archivos de disco duro virtual. Puede
anexos (ningún servicio de establecer un nivel de acceso frecuente
almacenamiento de archivo, cola, tabla o esporádico.
o disco). Proporciona la misma
durabilidad, disponibilidad,
escalabilidad y rendimiento que el uso
general v2.
Opciones de redundancia de almacenamiento

Las cuentas de almacenamiento pueden usar diferentes tipos de redundancia para lograr resistencia y alta
disponibilidad.
Almacenamiento con redundancia Protege contra una interrupción local Considere si la aplicación almacena
local (LRS) mediante la replicación dentro de una datos que se pueden reconstruir
unidad de almacenamiento individual a fácilmente.
un dominio de error y un dominio de
actualización independientes. Mantiene
varias copias de los datos en un centro
de datos. Proporciona una durabilidad
mínima del 99,999999999 % (once
nueves) de los objetos en un año
determinado.
Almacenamiento con redundancia Protege contra una interrupción del Considere si necesita coherencia,
de zona (ZRS) centro de datos; para ello, replicar a durabilidad y alta disponibilidad. Podría
través de tres clústeres de no proteger frente a un desastre
almacenamiento en una sola región. regional en el que varias zonas
Cada clúster de almacenamiento está resulten afectadas permanentemente.
separado físicamente y ubicado en su
propia zona de disponibilidad.
Proporciona al menos una durabilidad
del 99,9999999999 % (doce nueves)
de los objetos durante un año
determinado, para lo cual mantiene
varias copias de sus datos en varios
centros de datos o en regiones
diferentes.
Almacenamiento con redundancia Protege contra una interrupción de No hay disponibles datos de réplica a
geográfica (GRS) toda la región mediante la replicación menos que Microsoft inicie la
de los datos en una región secundaria conmutación por error para la región
que se encuentra muy lejos de la secundaria. Si se produce la
réplica principal. Proporciona una conmutación por error, el acceso de
durabilidad mínima del lectura y de escritura está disponible.
99,99999999999999 % (dieciséis
nueves) de los objetos en un año
determinado.
Almacenamiento con redundancia Similar a GRS. Proporciona una Proporciona una disponibilidad de
geográfica con acceso de lectura durabilidad mínima del lectura del 99,99 %, ya que permite el
(RA-GRS). 99,99999999999999 % (dieciséis acceso de lectura desde la segunda
nueves) de los objetos en un año región utilizada para GRS.
determinado.
Más información:
Revise los precios de Azure Storage.
Aprenda a usar el servicio Azure Import/Export para importar de forma segura grandes cantidades de datos
en Azure Blob Storage y Azure Files.
Compare blobs, archivos y tipos de datos de almacenamiento de disco.
Revise los diferentes tipos de cuentas de almacenamiento.
Obtenga información sobre la redundancia de Azure Storage, que incluye LRS, ZRS, GRS y GRS de solo
lectura.
Obtenga más información sobre Azure Files.
Fase posterior a la adopción

Antes de la adopción, las previsiones de costos dependen de las decisiones que toman los propietarios de las
cargas de trabajo y el equipo de adopción de la nube. Aunque el equipo de gobernanza puede influir en esas
decisiones, es probable que haya pocas medidas que deba tomar dicho equipo.
Una vez que los recursos se encuentran en fase de producción, los datos se pueden agregar y se pueden
analizar las tendencias a nivel del entorno. Estos datos permiten que el equipo de gobernanza tome decisiones
de tamaño y uso de forma independiente, en función de los patrones de uso reales y la arquitectura de estado
actual.
Analice los datos para generar una base de referencia de presupuesto para los recursos y los grupos de
recursos de Azure.
Identifique patrones de uso que le permitan reducir el tamaño y detener o pausar recursos para reducir aún
más los costos.
Entre los procedimientos recomendados de esta sección, se incluyen el uso de la Ventaja híbrida de Azure y
Azure Reserved VM Instances, la reducción del gasto en la nube de las suscripciones, el uso de Azure Cost
Management + Billing para la presupuestación y el análisis de los costos, la supervisión de los recursos y la
implementación de presupuestos para los grupos de recursos, así como la optimización de la supervisión, el
almacenamiento y las VM.
Procedimiento recomendado: use la Ventaja híbrida de Azure

Debido a los años de inversión en software en sistemas como Windows Server y SQL Server, Microsoft se
encuentra en una posición única para ofrecer a los clientes valor en la nube, con descuentos considerables que
otros proveedores de nubes no necesariamente proporcionan.
La cartera de productos local o de Azure integrada de Microsoft genera ventajas competitivas y en el costo. Si
actualmente tiene un sistema operativo o utiliza otras licencias de software a través de Software Assurance (SA),
puede transferir esas licencias a la nube con la Ventaja híbrida de Azure.
Más información:
Eche un vistazo a la calculadora de ahorro de la Ventaja híbrida de Azure.
Obtenga más información sobre la Ventaja híbrida de Azure de Windows Server.
Procedimiento recomendado: uso de Azure Reserved VM Instances

La mayoría de las plataformas en la nube se configuran como de pago por uso. Este modelo presenta
inconvenientes, dado que no se tiene por qué conocer hasta qué punto variarán las cargas de trabajo. Cuando se
especifican intenciones claras para una carga de trabajo, se contribuye al plan de la infraestructura.
Si usa Azure Reserved VM Instances, paga por adelantado el uso de instancias reservadas durante un plazo de
uno a tres años.
El pago por adelantado proporciona un descuento por los recursos que se utilizan.
Puede reducir considerablemente los costos de proceso de máquinas virtuales, la capacidad de proceso de
SQL Database, Azure Cosmos DB u otros recursos en hasta un 72 % con respecto a los precios de pago por
uso.
Las instancias reservadas permiten un descuento en la facturación y no afectan al estado del entorno de
ejecución de los recursos.
Puede cancelar las instancias reservadas.
Figura 1: Azure Reserved VM Instances.
Más información:
Aprenda más sobre Azure Reservations.
Lea las preguntas más frecuentes sobre las instancias reservadas.
Procedimiento recomendado: Suma del gasto en la nube entre

suscripciones
Resulta inevitable que al final tenga más de una suscripción de Azure. Por ejemplo, puede necesitar una
suscripción adicional para separar los límites de desarrollo y producción, o podría tener una plataforma que
requiera una suscripción independiente para cada cliente. Tener la capacidad de agregar informes de datos a
través de todas las suscripciones en una sola plataforma es una característica valiosa.
Para ello, puede usar las API de Azure Cost Management + Billing. A continuación, después de agregar los datos
en un único origen, como Azure SQL Database, puede usar herramientas como Power BI para mostrar los datos
agregados. Puede crear informes de suscripción agregados e informes pormenorizados. Por ejemplo, para los
usuarios que necesitan información proactiva sobre administración de costos, puede crear vistas específicas de
los costos, por departamento, grupo de recursos o cualquier otra información. No es necesario proporcionarles
acceso total a los datos de facturación de Azure.
Más información:
Lea la información general sobre las API de consumo de Azure.
Obtenga información sobre cómo conectarse a Azure Consumption Insights en Power BI Desktop.
Aprenda a administrar el acceso a la información de facturación de Azure mediante el control de acceso
basado en rol de Azure (RBAC de Azure).
Procedimiento recomendado: Supervisar la utilización de recursos
En Azure se paga por lo que usa, cuando los recursos se utilizan, y no se paga cuando no se utilizan. En el caso
de las máquinas virtuales, la facturación se produce cuando alguna se asigna y no se cobra una vez se
desasigna. Teniendo esto en cuenta, debe supervisar las máquinas virtuales que se utilizan así como comprobar
su tamaño.
Evalúe continuamente las cargas de trabajo de las máquinas virtuales para determinar las bases de
referencia.
Por ejemplo, si la carga de trabajo se produce principalmente de lunes a viernes, de 8 a.m. a 6 p.m., pero
apenas hay fuera de esas horas, las máquinas virtuales podrían cambiarse a una versión inferior fuera de las
horas punta. Esto podría significar cambiar los tamaños de máquina virtual o el uso de conjuntos de
escalado de máquinas virtuales para escalarlas de forma automática, ampliándolas o reduciéndolas.
Algunas compañías "posponen" las máquinas virtuales, para lo cual las colocan en un calendario que
especifica cuándo deben estar disponibles y cuándo no son necesarias.
Además de supervisar las máquinas virtuales, debe supervisar otros recursos de red como ExpressRoute y
las puertas de enlace de red para tener en cuenta cuándo se usan demasiado o demasiado poco.
Para supervisar el uso de las máquinas virtuales, puede emplear herramientas de Microsoft como, por
ejemplo, Azure Cost Management + Billing, Azure Monitor y Azure Advisor. También hay disponibles
herramientas de terceros.
Más información:
Lea los documentos de información general de Azure Monitor y Azure Advisor.
Obtenga recomendaciones sobre el costo de Azure Advisor.
Obtenga información sobre cómo optimizar los costos a partir de las recomendaciones y evitar cargos
imprevistos.
Descubra el kit de herramientas Azure Resource Optimization (ARO).
Procedimiento recomendado: reducción de los costos que no son de

producción
Los entornos de desarrollo, pruebas y control de calidad (QA) son necesarios durante los ciclos de desarrollo.
Desafortunadamente, es habitual que permanezcan aprovisionados cuando dejan de resultar útiles. La
realización de una revisión regular de los entornos que no son de producción que no se usan puede tener un
impacto inmediato en los costos.
Además, considere la posibilidad de reducir los costos generales de cualquier entorno que no sea de
producción:
Reduzca los recursos que no son de producción para usar máquinas virtuales de la serie B de menor costo y
el almacenamiento estándar.
Reduzca los costos de proceso que no sean de producción mediante máquinas virtuales de acceso puntual.
Aplique las directivas de Azure para requerir reducciones de costos a nivel de recursos de los recursos que
no sean de producción.
Más información:
Use etiquetas para identificar los objetivos de desarrollo, pruebas o QA para el cambio de tamaño o la
terminación.
El apagado automático de máquinas virtuales establece una hora de finalización nocturna para las máquinas
virtuales. Si usa esta característica, las VM que no son de producción se detendrán cada noche, de modo que
los desarrolladores se verán obligados a reiniciarlas cuando están listos para reanudar el desarrollo.
Las máquinas virtuales de acceso puntual permiten aprovechar la capacidad no utilizada con un importante
ahorro en los costos. Sin embargo, siempre que Azure necesite recuperar la capacidad, su infraestructura
expulsará las máquinas virtuales de acceso puntual.
Anime a los equipos de desarrollo a usar Azure DevTest Labs para establecer sus propios métodos de control
de costos y evitar el impacto de las horas estándar de apagado automático del paso anterior.
Procedimiento recomendado: Uso de Azure Cost Management +

Billing
Microsoft ofrece Azure Cost Management + Billing para ayudarle a realizar un seguimiento de los gastos:
Le ayuda a supervisar y controlar el gasto de Azure y a optimizar el uso de los recursos.
Revisa la suscripción completa y todos sus recursos, y sugiere recomendaciones.
Proporciona una API completa para integrar las herramientas externas y los sistemas financieros para los
informes.
Realiza un seguimiento del uso de los recursos y de la administración de los costos en la nube con una sola
vista unificada.
Proporciona información valiosa operativa y financiera para ayudarle a tomar decisiones informadas.
En Azure Cost Management + Billing, puede:
Crear un presupuesto : cree un presupuesto de responsabilidad financiera.
Puede tener en cuenta los servicios que consume o suscribirse por un periodo específico
(mensual, trimestral o anual) y un ámbito (grupos de recursos o suscripciones). Por ejemplo,
puede crear un presupuesto de suscripción de Azure durante un período mensual, trimestral o
anual.
Después de crear un presupuesto, se muestra en el análisis de costos. Ver el presupuesto con
respecto al gasto actual es uno de los primeros pasos necesarios al analizar los costos y los
gastos.
Pueden enviarse notificaciones por correo electrónico cuando se alcanzan umbrales de
presupuesto.
Puede exportar datos de administración de costos en Azure Storage, para analizarlos.
Presupuestos de Azure Cost Management + Billing.
Realizar un análisis de los costos : obtenga un análisis de los costos para explorar y analizar los
gastos de la organización y ayudarle a entender cómo se acumulan, así como identificar las tendencias
del gasto.
El análisis de costos está disponible para los usuarios del Contrato Enterprise.
Puede ver datos del análisis de costos de varios ámbitos y también por departamento, cuenta,
suscripción o grupo de recursos.
Puede obtener un análisis de costos que muestre los costos totales del mes actual y los
acumulados diariamente.
Figura: Análisis de Azure Cost Management + Billing.

Obtener recomendaciones: obtenga recomendaciones de Azure Advisor que le muestran cómo puede
optimizar y mejorar la eficacia.
Más información:
Consulte la introducción a Azure Cost Management + Billing.
Aprenda a optimizar la inversión en la nube con Azure Cost Management + Billing.
Aprenda a usar los informes de Azure Cost Management + Billing.
Revise un tutorial sobre la optimización de costos a partir de recomendaciones.
Revise las API de consumo de Azure.
Procedimiento recomendado: Implementar presupuestos para los

grupos de recursos
A menudo, se usan grupos de recursos para representar límites de costos. Junto con este patrón de uso, el
equipo de Azure sigue desarrollando formas nuevas y mejoradas de seguimiento y análisis de gastos a
diferentes niveles, lo que incluye la capacidad de crear presupuestos con el grupo de recursos y con los
recursos.
Un presupuesto para un grupo de recursos le ayuda a realizar un seguimiento de los costos asociados al
mismo.
Puede desencadenar alertas y ejecutar una amplia variedad de cuadernos de estrategias a medida que el
presupuesto se alcanza o se supera.
Más información:
Aprenda a administrar los costos con Azure Budgets.
Revise un tutorial sobre la creación y administración de un presupuesto de Azure.
Procedimiento recomendado: revisión de las recomendaciones de

Azure Advisor
Las recomendaciones de costos de Azure Advisor identifican oportunidades para reducir los costos. Cuando los
presupuestos parezcan altos o el uso parezca bajo, use este informe para encontrar oportunidades inmediatas a
fin de alinear los costos rápidamente.
Más información:
Revise las recomendaciones de costos de Azure Advisor para tomar medidas inmediatas.
Procedimiento recomendado: Optimizar la retención de Azure

Monitor
A medida que mueve recursos a Azure y habilita el registro de diagnóstico para ellos, se genera una gran
cantidad de datos de registro. Normalmente, estos datos de registro se envían a una cuenta de almacenamiento
que se asigna a un área de trabajo de Log Analytics.
Cuanto mayor sea el período de retención de los datos de registro, más datos tendrá.
No todos los datos de registro son iguales y algunos recursos generarán más datos de registro que otros.
Debido a cuestiones relativas a la normativa y al cumplimiento, es probable que deba conservar los datos de
registro para algunos recursos más tiempo que para otros.
Defina un equilibrio entre la optimización de los costos de almacenamiento de registros y el mantenimiento
de los datos de registro que necesita.
Se recomienda evaluar y configurar el registro inmediatamente después de completar una migración, de
modo que no invierta dinero en conservar registros sin importancia.
Más información:
Aprenda cómo supervisar el uso y los costos previstos.
Procedimiento recomendado: Optimizar el almacenamiento

Si ha seguido los procedimientos recomendados para la selección del almacenamiento antes de la adopción,
probablemente esté disfrutando de algunas ventajas. Es probable que pueda optimizar algunos costos de
almacenamiento adicionales. Con el tiempo, los blobs y archivos se vuelven obsoletos. Los datos podrían dejar
de usarse, pero los requisitos normativos podrían implicar que tenga que conservarlos durante un período
determinado. Por lo tanto, es posible que no necesite almacenarlos en el almacenamiento de alto rendimiento
que usó para la adopción original.
Identificar y mover los datos obsoletos a áreas de almacenamiento más económicas puede tener un efecto
enorme en el presupuesto mensual de almacenamiento y en el ahorro en los costos. Azure ofrece muchas
maneras para ayudarle a identificar y, a continuación, almacenar estos datos obsoletos.
Aproveche las ventajas de los niveles de acceso para el almacenamiento de uso general v2 y pase los datos
menos importantes del nivel de acceso frecuente a los niveles de acceso esporádico y de archivo.
Use StorSimple para ayudar a mover los datos obsoletos en función de directivas personalizadas.
Más información:
Lea Introducción a StorSimple.
Revise Precios de StorSimple.
Procedimiento recomendado: Automatizar la optimización de las

máquinas virtuales
El objetivo final de ejecutar una máquina virtual en la nube es maximizar la CPU, la memoria y el disco que
utiliza. Si detecta que las máquinas virtuales no están optimizadas o hay con frecuencia períodos en los que no
se utilizan, tiene sentido apagarlas o disminuir su nivel mediante conjuntos de escalado de máquinas virtuales.
Puede optimizar una máquina virtual con Azure Automation, conjuntos de escalas de máquinas virtuales,
apagado automático y soluciones de terceros o con script.
Más información:
Obtenga información sobre el escalado automático vertical.
Revise Azure DevTest Labs: programación del inicio automático de VM.
Aprenda a iniciar o detener las VM fuera del horario laboral en Azure Automation.
Encuentre más información sobre Azure Advisor y el kit de herramientas Azure Resource Optimization
(ARO).
Procedimiento recomendado: Usar Runbooks y Logic Apps con la API

de presupuestos
Azure proporciona una API REST que puede acceder a la información de facturación del inquilino.
Puede usar la API de presupuestos para integrar los sistemas externos y los flujos de trabajo que las métricas
construidas a partir de los datos de la API desencadenen.
Puede extraer datos de uso y de recursos, e incorporarlos en las herramientas de análisis de datos de su
preferencia.
Azure Resource Usage API y Azure Resource RateCard API pueden ayudar a predecir y administrar los costos
de manera precisa.
Las API se implementan como un proveedor de recursos y se incluyen entre las que expone Azure Resource
Manager.
La API de presupuestos se puede integrar con Azure Logic Apps y los runbooks de Azure Automation.
Más información:
Obtenga más información sobre la API de presupuestos.
Obtenga información sobre el uso de Azure con las API de facturación de Azure.
Pasos siguientes
Una vez que comprenda los procedimientos recomendados, examine la cadena de herramientas de Cost
Management para identificar las características y las herramientas de Azure que le ayudarán a ejecutar esos
procedimientos.
Cadena de herramientas de Cost Management de Azure
Herramientas de Cost Management en Azure
La materia Cost Management es una de las cinco disciplinas de gobernanza en la nube. Esta disciplina se centra
en las formas de establecer planes de gastos en la nube, asignar presupuestos de nube, supervisar y exigir los
presupuestos de nube, detectar anomalías costosas y ajustar el plan de gobernanza en la nube cuando el gasto
real no esté alineado.
A continuación, se muestra una lista de las herramientas nativas de Azure que pueden ayudar a desarrollar las
directivas y los procesos que admiten esta materia.
A Z URE C O ST
M A N A GEM EN T + C O N EC TO R DE
H ERRA M IEN TA A Z URE P O RTA L B IL L IN G P O W ER B I DESK TO P A Z URE P O L IC Y
Control del No Sí No Sí
presupuesto
Supervisión del gasto Sí Sí Sí No

en un único recurso
Supervisión del gasto No Sí Sí No

en varios recursos
Control del gasto en Sí, ajuste de tamaño Sí No Sí

un único recurso manual
Aplicación del gasto No Sí No Sí

en varios recursos
Aplicar los metadatos No No No Sí

de contabilidad a los
recursos
Supervisión y Sí Sí Sí No
detección de
tendencias
Detección de No Sí Sí No
anomalías en el gasto
Socialización de No Sí Sí No
desviaciones
Información general sobre la materia de base de
referencia de seguridad
La coherencia de los recursos es una de las cinco materias de la gobernanza en la nube dentro del modelo de
gobernanza de Cloud Adoption Framework. La seguridad es un componente de cualquier implementación de TI
y la nube presenta problemas de seguridad únicos. Muchas empresas están sujetas a requisitos reglamentarios
que convierten la protección de datos confidenciales en una prioridad importante de la organización al
considerar una transformación de la nube. La identificación de posibles amenazas de seguridad al entorno en la
nube y el establecimiento de procesos y procedimientos de tratamiento de estas amenazas deben ser
prioritarios para cualquier equipo de seguridad cibernética o seguridad de TI. La materia de base de referencia
de seguridad garantiza la aplicación coherente de requisitos técnicos y restricciones de seguridad a entornos en
la nube, a medida que esos requisitos se desarrollan.
NOTE
La materia de base de referencia de seguridad no reemplaza los procedimientos, procesos y equipos de TI existentes que
usa su organización para proteger los recursos implementados por la nube. El principal objetivo de esta materia es
identificar riesgos empresariales relacionados con la seguridad y proporcionar orientación en mitigación de riesgos al
personal de TI responsable de la infraestructura de seguridad. A medida que desarrolla procesos y directivas de
gobernanza, asegúrese de implicar a los equipos de TI pertinentes en sus procesos de revisión y planeación.
En este artículo se describe el enfoque de desarrollo de una materia de base de referencia de seguridad como
parte de su estrategia de gobernanza en la nube. La principal audiencia a la que se dirigen estas instrucciones
son los arquitectos de nube de su organización y otros miembros de su equipo de gobernanza en la nube. Las
decisiones, las directivas y los procesos que emergen de esta materia deben implicar la involucración y
discusiones con miembros pertinentes de los equipos de seguridad y TI, especialmente aquellos líderes técnicos
responsables de la implementación de servicios de identidad, cifrado y redes.
Tomar las decisiones de seguridad correctas es fundamental para el éxito de sus implementaciones en la nube y
un mayor éxito empresarial. Si su organización carece de conocimientos internos sobre seguridad cibernética,
considere la posibilidad de involucrar a consultores de seguridad externos como componente de esta materia.
Considere también la posibilidad de involucrar a Servicios de consultoría de Microsoft, el servicio de adopción
de la nube Microsoft FastTrack u otros expertos en adopción de la nube externos para determinar los problemas
relacionados con esta materia.
Policy statements
Las declaraciones de la directiva accionable y los requisitos de arquitectura resultantes actúan como base de una
materia de base de referencia de seguridad. Use instrucciones de directiva de ejemplo como punto de partida
para definir las directivas de línea de base de seguridad.
Cau t i on

Los siguientes pasos ofrecen ejemplos y posibles opciones que se deben tener en cuenta al desarrollar la
materia de base de referencia de seguridad. Use cada paso como punto de partida de análisis en el equipo de
gobernanza en la nube y con los equipos de seguridad, TI y empresariales afectados de toda la organización
para establecer las directivas y procesos necesarios para administrar los riesgos relacionados con la seguridad.
Plantilla de la materia de base de referencia de seguridad:

Descargue la plantilla para documentar una materia de base
de referencia de seguridad.

asociados normalmente a la materia de base de referencia de
seguridad.

momento adecuado para invertir en la materia de línea base
de seguridad.
Procesos de adhesión a las directivas: Procesos

recomendados para admitir el cumplimiento de directiva en
la materia de base de referencia de seguridad.


implementar para admitir la materia de base de referencia de
seguridad.
Pasos siguientes
Empiece evaluando riesgos empresariales en un entorno específico.
Plantilla de la materia de base de referencia de
seguridad
El primer paso para implementar un cambio es comunicar lo que se pretende. Lo mismo sucede cuando se
cambian los procedimientos de gobernanza. La plantilla siguiente proporciona un punto de partida para
documentar y comunicar declaraciones de directivas que controlan problemas relacionados con la seguridad en
la nube.
para definir las declaraciones de las directivas de Línea de base de seguridad de la organización.
IMPORTANT
posteriores para definir una materia de base de referencia de seguridad eficaz dentro de su estrategia de gobernanza en la
nube.
Descargar la plantilla de la materia de base de referencia de seguridad
Pasos siguientes
de la nube actual.
de base de referencia de seguridad
En este artículo se describen las razones por las que los clientes normalmente adoptan una materia sobre la
base de referencia de la seguridad dentro de una estrategia de gobernanza de la nube. También se proporcionan
algunos ejemplos de posibles riesgos empresariales que pueden motivar las declaraciones de directiva.
Relevancia
La seguridad es una preocupación clave en cualquier organización de TI. Las implementaciones en la nube se
enfrentan a los mismos riesgos para la seguridad que las cargas de trabajo hospedadas en los centros de datos
locales tradicionales. Por su naturaleza, las plataformas de nube pública no poseen la propiedad directa del
hardware físico que almacena y ejecuta las cargas de trabajo, lo que implica que la seguridad en la nube
necesita sus propias directivas y procesos.
Uno de los elementos principales que diferencia la gobernanza de la seguridad en la nube de las directivas de
seguridad tradicionales es la facilidad con la que se pueden crear recursos, que agregan posibles
vulnerabilidades si no se tiene en cuenta la seguridad antes de la implementación. La flexibilidad que las
tecnologías tales como las redes definidas por software (SDN) ofrecen para cambiar rápidamente la topología
de una red basada en la nube puede modificar también la superficie de la red que queda expuesta a ataques
fácilmente y de maneras imprevistas. Las plataformas de nube también proporcionan herramientas y
características que pueden mejorar las funcionalidades de seguridad de maneras no siempre es posible en
entornos locales.
La inversión necesaria en directivas y procesos de seguridad dependerá mucho la naturaleza de su
implementación en la nube. Las implementaciones de prueba iniciales solo necesitarán las directivas de
seguridad más básicas, mientras que una carga de trabajo crítica implicará abordar necesidades de seguridad
exhaustivas y complejas. Todas las implementaciones deberán aplicar la materia en algún nivel.
La materia sobre la base de referencia de la seguridad abarca las directivas corporativas y los procesos
manuales que puede poner en marcha para proteger una implementación en la nube frente a los riesgos para la
seguridad.
NOTE
Aunque es importante entender la materia de base de referencia de identidad en el contexto de la materia de base de
referencia de seguridad y cómo se relaciona con el control de acceso, en las Cinco materias de gobernanza de la nube se
trata como una materia aparte.
Riesgo empresarial
La materia sobre la base de referencia de la seguridad intenta abordar los riesgos relacionados con la seguridad
empresarial. Trabaje con su empresa para identificar estos riesgos y supervise cada uno de ellos para
determinar su pertinencia a medida que planee y aplique sus implementaciones en la nube.
Los riesgos difieren entre organizaciones. Use esta lista de riesgos habituales relacionados con la seguridad
como punto inicial para las discusiones dentro del equipo de gobernanza de la nube:
Vulneración de datos: La exposición accidental o la pérdida de información confidencial hospedada en la
nube puede provocar la pérdida de clientes, problemas contractuales o consecuencias legales.
Interrupción del ser vicio. Las interrupciones y otros problemas de rendimiento debidos a una
infraestructura no segura interrumpe las operaciones normales y puede dar lugar a la pérdida de
productividad o la pérdida de negocio.
Pasos siguientes
Use la plantilla de la materia de base de referencia de seguridad para documentar los riesgos empresariales que
es probable que se introduzcan debido al plan actual de adopción de la nube.
tolerancia.
Indicadores y métricas de tolerancia al riesgo en la
materia de base de referencia de seguridad
Aprenda a cuantificar la tolerancia al riesgo empresarial asociada a la materia de base de referencia de

seguridad. La definición de métricas e indicadores ayuda a crear un caso empresarial para invertir en la
madurez de esta materia.
Métricas
La materia de base de referencia de seguridad se centra por lo general en identificar posibles puntos
vulnerables en las implementaciones en la nube. Como parte del análisis de riesgos, querrá recopilar datos
relacionados con el entorno de seguridad para determinar el riesgo al que se enfrenta y la importancia que la
inversión en la materia de base de referencia de seguridad tiene en sus planes de implementación en la nube.
Cada organización tiene distintos entornos y requisitos de seguridad y diferentes orígenes potenciales de datos
de seguridad. A continuación encontrará varios ejemplos de métricas útiles que debe recopilar, ya que le
ayudarán a evaluar la tolerancia al riesgo en la materia sobre la base de referencia de la seguridad:
Clasificación de datos : Número de servicios y datos almacenados en la nube que no están clasificados
según las normas de privacidad, cumplimiento o impacto empresarial de su organización.
Número de almacenes de datos confidenciales : Número de puntos de conexión de almacenamiento o
bases de datos que contienen información confidencial y que deben protegerse.
Número de almacenes de datos sin cifrar : Número de almacenes de datos confidenciales que no están
cifrados.
Superficie expuesta a ataques : Cuántos orígenes de datos, servicios y aplicaciones en total se hospedarán
en la nube. ¿Qué porcentaje de estos orígenes de datos se clasifican como confidenciales? ¿Qué porcentaje
de estas aplicaciones y servicios es crítico?
Estándares cubier tos : Número de estándares de seguridad definidos por el equipo de seguridad.
Recursos cubier tos : Recursos implementados que están cubiertos por los estándares de seguridad.
Cumplimiento general de estándares : Tasa de cumplimiento de los estándares de seguridad.
Ataques por gravedad : ¿Cuántos intentos de interrupción de los servicios hospedados en la nube, por
ejemplo, mediante ataques de denegación de servicio distribuido (DDoS), experimenta su infraestructura?
¿Cuál es el tamaño y la gravedad de estos ataques?
Protección contra malware : Porcentaje de máquinas virtuales implementadas que tienen todo el software
antimalware, firewall u otro software de seguridad instalado.
Latencia de revisiones : El tiempo que hace desde que se aplicaron las últimas revisiones de software y del
sistema operativo a las máquinas virtuales.
Recomendaciones sobre estado de seguridad : Número de recomendaciones de software de seguridad
para resolver los estándares de mantenimiento para los recursos implementados, organizados por gravedad.

Las plataformas en la nube proporcionan un conjunto básico de características que permiten a los equipos de
implementaciones pequeñas configurar las opciones básicas de seguridad sin un planeamiento adicional
amplio. Como resultado, las primeras cargas de trabajo experimentales o de desarrollo/pruebas pequeñas que
no incluyen información confidencial representan un nivel de riesgo relativamente bajo, y probablemente no
necesitarán demasiado en relación con la directiva formal de la base de referencia de seguridad. En cuanto los
datos importantes o la funcionalidad crítica se transfieren a la nube, los riesgos de seguridad aumentan,
mientras que la tolerancia a dichos riesgos se reduce rápidamente. Cuantos más datos y funcionalidades se
implementen en la nube, más deberá invertir en la materia de la base de referencia de seguridad.
En las primeras fases de adopción de la nube, trabaje con el equipo de seguridad de TI y las partes interesadas
de la empresa para identificar riesgos de negocio relacionados con la seguridad y, luego, determine una línea de
base aceptable para la tolerancia al riesgo de seguridad. En esta sección de Cloud Adoption Framework se
proporcionan ejemplos, pero los riesgos y las bases de referencia específicos de su empresa o sus
implementaciones pueden ser diferentes.
Una vez que tenga una base de referencia, establezca bancos de pruebas mínimos que representen un aumento
inaceptable de los riesgos identificados. Estos bancos de pruebas actúan como desencadenadores cuando se
necesita tomar medidas para corregir estos riesgos. En los siguientes ejemplos, se muestra cómo las métricas
relacionadas con la seguridad, como las descritas anteriormente, pueden justificar una mayor inversión en la
materia de la base de referencia de seguridad.
Desencadenador de cargas de trabajo críticas . Una empresa que implementa cargas de trabajo críticas
en la nube debe invertir en la materia de la base de referencia de seguridad para evitar posibles
interrupciones del servicio o la exposición de información confidencial.
Desencadenador de datos protegidos . Una empresa que hospeda datos en la nube que se pueden
clasificar como confidenciales, privados o sujetos a otras cuestiones legales. Necesitan una materia de base
de referencia de seguridad para garantizar que estos datos no corran el peligro de pérdida, exposición o
robo.
Desencadenador de ataques externos . Una empresa que experimenta graves ataques contra su
infraestructura x veces al mes podría beneficiarse de la materia de la base de referencia de seguridad.
Desencadenador de cumplimiento de estándares . Una empresa con más de un x% de recursos que no
cumplen los estándares de seguridad debe invertir en la materia de la base de referencia de seguridad para
garantizar la aplicación coherente de los estándares en toda la infraestructura de TI.
Desencadenador de tamaño para recursos en la nube . Una empresa que hospeda más de un número
x de aplicaciones, servicios u orígenes de datos. Las implementaciones grandes en la nube pueden
beneficiarse de la inversión en la materia de la base de referencia de seguridad para garantizar que su
superficie expuesta a ataques total esté bien protegida frente a accesos no autorizados u otras amenazas
externas.
Desencadenador de cumplimiento de software de seguridad . Una empresa en la que menos de un
x% de las máquinas virtuales implementadas tienen todo el software de seguridad necesario instalado. Se
puede usar una materia de base de referencia de seguridad para garantizar que el software está instalado de
forma coherente en todo el software.
Desencadenador de aplicación de revisiones . Una empresa en la que a las máquinas virtuales o los
servicios implementados no se les han aplicado revisiones de software o del sistema operativo durante los
últimos x días. Se puede usar una materia de base de referencia de seguridad para garantizar que la
aplicación de revisiones esté actualizada dentro de una programación necesaria.
Centrado en la seguridad . Algunas empresas tendrán estrictos requisitos de seguridad y confidencialidad
de datos incluso para las cargas de trabajo de pruebas y experimentales. Estas empresas deberán invertir en
la materia de la base de referencia de seguridad antes de iniciar las implementaciones.
Las métricas y desencadenadores exactos que use para medir la tolerancia al riesgo y el nivel de inversión en la
materia de base de referencia de seguridad serán específicos para su organización, pero los ejemplos anteriores
deberían servir como base útil para las conversaciones con su equipo de gobernanza en la nube.
Pasos siguientes
Use la plantilla de la materia de base de referencia de seguridad para documentar las métricas y los indicadores
de tolerancia que se alinean con el plan actual de adopción de la nube.
Revise las directivas de base de referencia de seguridad de ejemplo como punto de partida para desarrollar
otras suyas que aborden los riesgos empresariales específicos vinculados a los planes de adopción de la nube.
Declaraciones de directiva de ejemplo de la base de
referencia de la seguridad
Riesgo técnico: Un resumen del riesgo que esta directiva abordará.
Opciones técnicas : Recomendaciones que requieren acción, especificaciones u otras instrucciones que los
equipos de TI y los desarrolladores pueden usar al implementar la directiva.
Las siguientes instrucciones de directiva de ejemplo abordan algunos riesgos empresariales comunes
relacionados con la seguridad. Estas declaraciones son ejemplos a los que se puede hacer referencia al elaborar
el borrador de las declaraciones de directiva para satisfacer las necesidades de su organización. Estos ejemplos
no pretenden ser excluyentes y hay varias opciones posibles de directiva para solucionar cada riesgo concreto
identificado. Trabaje estrechamente con los equipos de TI, seguridad y negocio para identificar las mejores
directivas para su conjunto de riesgos en particular.
Clasificación de los recursos

Riesgo técnico: los recursos que no están identificados correctamente como críticos para la misión o que
trabajan con datos confidenciales podrían no estar suficientemente protegidos, dando lugar a posibles pérdidas
de datos o interrupciones de la actividad.
Declaración de directiva : Todos los recursos implementados deben categorizarse por importancia y
clasificación de datos. El equipo de gobernanza de la nube y el propietario de la aplicación deben revisar las
clasificaciones antes de la implementación en la nube.
Opción de diseño posible : establezca normas de etiquetado de los recursos y asegúrese de que el personal
de TI las aplique de forma coherente a los recursos implementados mediante las etiquetas de recursos de Azure.
Cifrado de datos
Riesgo técnico: hay un riesgo de exposición durante el almacenamiento de datos protegidos.
Declaración de directiva : todos los datos protegidos deben estar cifrados cuando están en reposo.
Opción de diseño posible : consulte el artículo Introducción al cifrado de Azure para ver cómo se realiza el
cifrado de los datos en reposo en la plataforma Azure. También se deben tener en cuenta controles adicionales,
como el cifrado de datos de la cuenta y el control sobre cómo se puede cambiar la configuración de la cuenta de
almacenamiento.
Aislamiento de red
Riesgo técnico: la conectividad entre las redes y subredes presenta posibles vulnerabilidades que pueden dar
lugar a la pérdida de datos o la interrupción de servicios críticos.
Declaración de directiva : las subredes que contengan datos protegidos deben aislarse de las otras subredes.
El tráfico de red entre las subredes de datos protegidos se debe auditar periódicamente.
Opción de diseño posible : en Azure, el aislamiento de las redes y subredes se administra mediante Azure
Virtual Network.
Acceso externo seguro

Riesgo técnico: permitir el acceso a las cargas de trabajo desde la red pública de Internet presenta un riesgo
de intrusión y, como consecuencia, una exposición no autorizada de los datos o la interrupción del negocio.
Declaración de directiva : no se podrá acceder directamente desde Internet a ninguna subred que contenga
datos protegidos, ni desde un centro de datos a otro. El acceso a esas subredes debe enrutarse a través de
subredes intermedias. Todo el acceso a esas subredes debe realizarse a través de una solución de firewall que
pueda realizar funciones de análisis y bloqueo de paquetes.
Opción de diseño posible : en Azure, proteja los puntos de conexión públicos mediante la implementación de
una red perimetral entre la red pública de Internet y su red basada en la nube. Considere la posibilidad de
realizar la implementación, configuración y automatización de Azure Firewall.
Protección contra DDOS

Riesgo técnico: los ataques por denegación de servicio distribuido (DDoS) pueden provocar una interrupción
del negocio.
Declaración de directiva : implemente mecanismos automatizados de mitigación de ataques DDoS en todos
los puntos de conexión de red accesibles públicamente. No se debe exponer a Internet ningún sitio web público
con respaldo de IaaS sin DDoS.
Opción de diseño posible : use Azure DDoS Protection Estándar para minimizar las interrupciones causadas
por ataques DDoS.
Protección de la conectividad local

Riesgo técnico: el tráfico sin cifrar que circula entre su red en la nube y el entorno local a través de la red
pública de Internet puede ser interceptado, con el riesgo de que los datos queden expuestos.
Declaración de directiva : todas las conexiones entre el entorno local y las redes en la nube deben realizarse
mediante una conexión de VPN cifrada segura o un vínculo WAN privado dedicado.
Opción de diseño posible : en Azure, use ExpressRoute o Azure VPN para establecer conexiones privadas
entre el entorno local y las redes en la nube.
Supervisión de la red y cumplimiento

Riesgo técnico: los cambios realizados en la configuración de la red pueden provocar nuevas vulnerabilidades
y riesgos de exposición de los datos.
Declaración de directiva : las herramientas de gobernanza deben auditar y aplicar los requisitos de
configuración de red definidos por el equipo de la base de referencia de seguridad.
Opción de diseño posible : en Azure, la actividad de la red se puede supervisar con Azure Network Watcher, y
Azure Security Center puede ayudar a identificar las vulnerabilidades de seguridad. Azure Policy permite
restringir los recursos de red y la directiva de configuración de los recursos según los límites definidos por el
equipo de seguridad.
Revisión de la seguridad
Riesgo técnico: con el tiempo, aparecen nuevas amenazas para la seguridad y nuevos tipos de ataques, que
aumentan el riesgo de exposición o la interrupción de los recursos en la nube.
Declaración de directiva : el equipo de seguridad debe revisar periódicamente las tendencias y
vulnerabilidades que podrían afectar a las implementaciones en la nube para proporcionar actualizaciones a las
herramientas de la base de referencia de seguridad que se usan en la nube.
Opción de diseño posible : establezca una reunión periódica para revisar la seguridad, que incluya a los
miembros pertinentes de los equipos de TI y gobernanza. Revise las métricas y los datos de seguridad existentes
para identificar deficiencias en las herramientas y la directiva de la base de referencia de seguridad, y actualice la
directiva para remedir los nuevos riesgos. Utilice Azure Advisor y Azure Security Center para obtener
información útil sobre las amenazas emergentes específicas de las implementaciones.
Pasos siguientes
los riesgos específicos para su negocio, en línea con sus planes de adopción de la nube.
Para comenzar a desarrollar sus propias declaraciones de directiva personalizadas de la base de referencia de
seguridad, descargue la plantilla de la materia de base de referencia de seguridad.
directiva de base de referencia de seguridad.
Procesos de cumplimiento de la directiva de la base
de referencia de seguridad
En este artículo se describe un enfoque de los procesos de cumplimiento de directivas que rigen la materia de
base de referencia de seguridad. La gobernanza efectiva de la seguridad de la nube comienza con procesos
manuales periódicos diseñados para detectar vulnerabilidades e imponer directivas para remediar los riesgos
para la seguridad. Esto requiere la participación regular del equipo de gobernanza de la nube y las partes
interesadas de TI y de la empresa para revisar y actualizar la directiva y garantizar el cumplimiento de esta.
Además, muchos procesos de aplicación y supervisión en curso se pueden automatizar o complementar con
herramientas para reducir la sobrecarga de la gobernanza y permitir una respuesta más rápida a la desviación
de directivas.

Las mejores herramientas de la base de referencia de seguridad en la nube están limitadas a los procesos y
directivas que admiten. El siguiente es un conjunto de procesos de ejemplo que normalmente están incluidos en
la materia sobre la base de referencia de la seguridad. Use estos ejemplos como punto de partida al planear los
procesos que le permitirán continuar actualizando la directiva de seguridad en función de los cambios que se
produzcan en la empresa y los comentarios de los equipos de seguridad y TI cuya tarea es la activación de la
guía de gobernanza.
Planeamiento y evaluación inicial de los riesgos: como parte de la adopción inicial de la materia sobre la
base de referencia de la seguridad, identifique los principales riesgos empresariales y las tolerancias
relacionadas con la seguridad de la nube. Esta información se usa para debatir sobre riesgos técnicos concretos
con los miembros de los equipos de seguridad y de TI, y para desarrollar un conjunto de referencia de directivas
de seguridad para mitigar dichos riesgos, con el fin de establecer la estrategia de gobernanza inicial.
Planeación de la implementación: antes de implementar cualquier carga de trabajo o recurso, realice una
revisión de seguridad para identificar los nuevos riesgos y asegurarse de que se cumplen todos los requisitos de
acceso y de la directiva de seguridad de datos.
Pruebas de la implementación: como parte del proceso de implementación de cualquier carga de trabajo o
recurso, el equipo de gobernanza de la nube, en colaboración con los equipos de seguridad corporativa, será
responsable de revisar la implementación para validar el cumplimiento de la directiva de seguridad.
Planeación anual: realice todos los años una revisión general de la estrategia de la base de referencia de la
seguridad. Explore las futuras prioridades corporativas y las estrategias actualizadas de adopción de la nube
para identificar un posible aumento del riesgo y otras necesidades de seguridad emergentes. También puede
usar este tiempo para revisar los procedimientos recomendados de la base de referencia de seguridad más
recientes e integrarlos en sus directivas y procesos de revisión.
Planeamiento y revisión trimestrales: realice una revisión trimestral de los datos de auditoría de seguridad
y los informes de incidentes, con el fin de identificar los cambios necesarios en la directiva de seguridad. Como
parte de este proceso, revise el panorama actual de ciberseguridad para anticiparse proactivamente a las
amenazas emergentes y actualizar la directiva según corresponda. Una vez completada la revisión, alinee la guía
de diseño con la directiva actualizada.
Este proceso de planeamiento también es un buen momento para evaluar a los miembros actuales del equipo
de gobernanza de la nube, por si hay lagunas de conocimientos relacionadas con una directiva nueva o
cambiante, y con los riesgos relacionados con la seguridad. Invite al personal de TI pertinente a participar en las
revisiones y el planeamiento como asesores técnicos temporales o miembros permanentes del equipo.
Educación y aprendizaje: ofrezca sesiones de aprendizaje con carácter bimensual para asegurarse de que
tanto los desarrolladores como el personal de TI están al día de los requisitos más recientes de las directivas de
seguridad. Como parte de este proceso, revise y actualice cualquier documentación, guía u otros recursos de
aprendizaje para asegurarse de que estén sincronizados con las declaraciones de directiva corporativa más
recientes.
Auditoría mensual y revisiones de informes: realice una auditoría mensual de todas las implementaciones
de la nube para garantizar su alineación continuada con la directiva de seguridad. Revise las actividades
relacionadas con la seguridad con el personal de TI e identifique los problemas de cumplimiento que aún no se
han abordado como parte del proceso continuo de supervisión y cumplimiento. El resultado de esta revisión es
un informe para el equipo de estrategia de la nube y cada equipo de adopción de la nube para comunicar la
adhesión general a la directiva. El informe también se almacena con fines de auditoría y legales.

El hecho de que una estrategia de base de referencia de seguridad sea correcta depende de la visibilidad de los
estados actual y pasado de la infraestructura en la nube. Sin la capacidad para analizar las métricas pertinentes y
los datos del estado de seguridad y de la actividad de los recursos en la nube, no se pueden identificar cambios
en los riesgos o detectar infracciones de las tolerancias al riesgo. Los procesos de gobernanza en curso
explicados anteriormente requieren datos de calidad para asegurarse de que se puede modificar la directiva
para proteger mejor la infraestructura contra los constantes cambios que se producen tanto en las amenazas
como en los requisitos de seguridad.
Asegúrese de que los equipos de seguridad y de TI han implementado sistemas de supervisión automatizados
para la infraestructura en la nube que capturen los datos pertinentes de los registros que necesita para evaluar
el riesgo. Sea proactivo en la supervisión de estos sistemas para asegurar la pronta detección y mitigación de
posibles infracciones de la directiva y que su estrategia de supervisión esté en línea con las necesidades de
seguridad.
Desencadenadores de infracción y acciones de cumplimiento

Dado que el incumplimiento de las directivas de seguridad puede dar lugar a riesgos de exposición de datos e
interrupción de servicios críticos, el equipo de gobernanza de la nube debe tener visibilidad sobre las
infracciones graves de la directiva. Asegúrese de que el personal de TI conoce a la perfección las rutas de
escalado para notificar los problemas de seguridad a los miembros del equipo de gobernanza más adecuados
para identificar y comprobar que se han mitigado los problemas de la directiva.
Cuando se detectan infracciones, debe realizar acciones para volver a alinearse con la directiva lo antes posible.
El equipo de TI puede automatizar la mayoría de los desencadenadores de infracciones mediante las
herramientas que se describen en Security Baseline toolchain for Azure (Cadena de herramientas de la base de
referencia de seguridad para Azure).
Los siguientes desencadenadores y acciones de cumplimiento son ejemplos que puede consultar para planear
cómo usar los datos de supervisión para resolver las infracciones de directivas:
Aumento de los ataques detectados. Si el número de ataques de fuerza bruta o DDoS que recibe
cualquier recurso aumenta un 25 %, hable con el personal de seguridad de TI y con el propietario de la carga
de trabajo para determinar las posible soluciones. Realice un seguimiento del problema y actualice la guía si
es preciso realizar una revisión de la directiva para evitar dichos incidentes en el futuro.
Se han detectado datos sin clasificar. A todos los orígenes de datos que carezcan de una adecuada
clasificación de privacidad, seguridad o impacto en la empresa se les denegará el acceso externo hasta que el
propietario de los datos aplique la clasificación y el nivel adecuado de protección.
Se ha detectado un problema en el estado de la seguridad. Deshabilite el acceso a las máquinas
virtuales (VM) que se sepa que tienen acceso o que se haya identificado que tienen vulnerabilidades de
malware hasta que se puedan instalar las revisiones apropiadas o software de seguridad. Actualice las
instrucciones de directiva para que tenga en cuenta las amenazas detectadas recientemente.
Se ha detectado una vulnerabilidad en la red. El acceso a cualquier recurso no permitido
explícitamente por las directivas de acceso de red debe desencadenar una alerta para el personal de
seguridad de TI y el propietario de la carga de trabajo pertinente. Realice un seguimiento del problema y
actualice la guía si es preciso realizar una revisión de la directiva para mitigar dichos incidentes en el futuro.
Pasos siguientes
Use la plantilla de la materia de base de referencia de seguridad para documentar los procesos y los
desencadenadores que se alinean con el plan de adopción actual de la nube.
Para obtener instrucciones acerca de cómo ejecutar directivas de administración en la nube de conformidad con
los planes de adopción, consulte el artículo sobre la mejora de la materia.
Mejora de la materia sobre la base de referencia de la seguridad
Mejora de la materia sobre la base de referencia de
la seguridad
La materia de base de referencia de la seguridad se centra en formas de establecer directivas que protegen la
red, los recursos y, lo que es más importante, los datos que residirán en una solución del proveedor de nube.
Dentro de las cinco materias de gobernanza de la nube, la correspondiente a la base de referencia de seguridad
implica la clasificación del patrimonio digital y los datos. También incluye documentación de estrategias de
mitigación, tolerancia empresarial y riesgos que se asocian a la seguridad de los datos, los recursos y la red.
Desde una perspectiva técnica, también supone la participación en decisiones sobre el cifrado, los requisitos de
red, las estrategias de identidad híbrida y los procesos utilizados para desarrollar las directivas de la base de
referencia de seguridad.
En este artículo se destacan algunas de las posibles tareas en las que su empresa puede participar para
desarrollar y mejorar la materia sobre la base de referencia de la seguridad. Estas tareas se dividen en las fases
de planeamiento, compilación, adopción y funcionamiento de la implementación de una solución de nube que,
posteriormente, se iteran para permitir el desarrollo de un enfoque incremental a la gobernanza de la nube.
Figura 1: fases de un enfoque incremental para la gobernanza de la nube.

Es imposible recopilar en un solo documento los requisitos de todas las empresas. Por lo tanto, en este artículo
la gobernanza. El objetivo inicial de estas actividades es ayudarle a crear un MVP de directiva y establecer un
marco para la mejora incremental de las directivas. El equipo de gobernanza de la nube deberá decidir cuánto
invertir en estas actividades para mejorar la materia de base de referencia de seguridad.
Cau t i on
nube.
Evalúe las opciones que tiene para la cadena de herramientas de la base de referencia de la seguridad.
Elabore un borrador con las directrices de arquitectura y distribúyalo a las principales partes interesadas.
Agregue tareas de seguridad priorizadas a su trabajo pendiente de migración.
Defina un esquema de clasificación de los datos.
Realice un proceso de planeamiento del patrimonio digital para inventariar los recursos de TI actuales que
dan servicio a los procesos empresariales y respaldan las operaciones.
Lleve a cabo una revisión de la directiva para comenzar el proceso de modernización de las directivas de
seguridad de TI corporativas existentes, y defina las directivas de producto mínimo viable para abordar los
riesgos conocidos.
Revise las directrices de seguridad de la plataforma de nube. En el caso de Azure, se encuentran en el portal
de confianza de servicios de Microsoft.
Determine si la directiva de base de referencia de seguridad incluye un ciclo de vida de desarrollo de la
seguridad.
Evalúe la red, los datos y los riesgos empresariales relacionadas con los recursos, utilizando para ello de una
a tres de las próximas versiones, y evalúe la tolerancia de su organización a esos riesgos.
Revise el informe de Microsoft sobre las principales tendencias en ciberseguridad para obtener información
general sobre el panorama actual de la seguridad.
Considere la posibilidad de desarrollar un rol de DevSecOps en su organización.

Implemente su cadena de herramientas de la base de referencia de la seguridad agregándola en una fase
anterior a la implementación.
Actualice el documento de directrices de arquitectura y distribúyalo a las principales partes interesadas.
Implemente tareas de seguridad en su trabajo pendiente de migración priorizado.
Determine la estrategia de cifrado de la organización para los datos hospedados en la nube.
Evalúe la estrategia de identidad de la implementación en la nube. Determine cómo la solución de identidad
basada en la nube coexistirá o se integrará con los proveedores de identidades del entorno local.
Determine las directivas de límites de red para el diseño de sus redes definidas por software (SDN), para
poder garantizar funcionalidades de red virtualizada seguras.
Evalúe las directivas de acceso con privilegios mínimos de su organización y use roles basados en tareas
para proporcionar acceso a recursos específicos.
Aplique mecanismos de seguridad y supervisión a todos los servicios y máquinas virtuales en la nube.
Automatice las directivas de seguridad siempre que sea posible.
Revise la directiva de base de referencia de seguridad y determine si necesita modificar los planes de
acuerdo con la guía de procedimientos recomendados, por ejemplo, los descritos en Ciclo de vida de
desarrollo de seguridad.
Migre la cadena de herramientas de su base de referencia de la seguridad de la fase anterior a la
implementación a la fase de producción.
Revise la información más reciente sobre amenazas y la base de referencia de seguridad para identificar
nuevos riesgos empresariales.
Calibre qué tolerancia tiene su organización para controlar los nuevos riesgos para la seguridad que
pudieran surgir.
Identifique las desviaciones de la directiva y aplique correcciones.
Ajuste la automatización del control de acceso y la seguridad para garantizar el máximo cumplimiento de la
directiva.
Compruebe que los procedimientos recomendados que se definieron durante las fases de compilación y
anterior a la implementación se ejecutan correctamente.
Revise las directivas de acceso con privilegios mínimos y ajuste los controles de acceso para maximizar la
seguridad.
Pruebe la cadena de herramientas de su base de referencia de la seguridad con sus cargas de trabajo para
identificar y resolver las vulnerabilidades.

Valide y ajuste la cadena de herramientas de su base de referencia de la seguridad.
Personalice las notificaciones y los informes para que le avisen de posibles problemas para la seguridad.
Refine las directrices de arquitectura para guiar los procesos de adopción futuros.
Informe a los equipos afectados y ofrézcales cursos de forma periódica para garantizar el cumplimiento de
las directrices de la arquitectura.
Identifique los patrones y el comportamientos de sus cargas de trabajo y configure herramientas de
supervisión e informes para que identifiquen y le notifiquen de actividades, accesos o uso de recursos
anómalos.
Actualice continuamente las directivas de supervisión e informes para detectar los ataques y las
vulnerabilidades más recientes.
Ponga en marcha procedimientos para detener rápidamente el acceso no autorizado y deshabilitar los
recursos que un atacante haya podido poner en riesgo.
Revise con regularidad los procedimientos recomendados de seguridad más recientes y aplique las
recomendaciones a su directiva de seguridad y a sus funcionalidades de automatización y supervisión
siempre que sea posible.
Pasos siguientes
Ahora que comprende el concepto de gobernanza de la seguridad en la nube, vamos a ver qué procedimientos
recomendados y guías para la seguridad ofrece Microsoft para Azure.
Más información sobre las guías de seguridad para Azure Introducción a la seguridad de Azure Más información
sobre registro, informes y supervisión
Directivas de línea de base de seguridad nativas en
la nube
La materia de base de referencia de seguridad es una de las cinco materias de gobernanza de la nube. Esta
materia se centra en temas de seguridad generales que incluyen la protección de la red, los recursos digitales y
los datos. En este artículo se trata un directiva de ejemplo nativa en la nube para la materia de línea de base de
seguridad.
NOTE
Microsoft no es quien debe dictar las directivas corporativas o de TI. Este artículo le ayudará a prepararse para una
revisión de directivas interna. Se supone que este ejemplo de directiva se ampliará, validará y probará con sus directivas
corporativas antes de intentar utilizarla. El uso de este ejemplo de directiva tal y como está, no es recomendable.
Alineación de la directiva
Esta directiva de ejemplo resume un escenario nativo en la nube, lo cual significa que las herramientas y
plataformas que proporciona Azure son suficientes para administrar los riesgos empresariales que conlleva una
implementación. En tal escenario, se supone que una configuración sencilla de los servicios predeterminados de
Azure ofrece suficiente protección a los recursos.
Seguridad en la nube y cumplimiento

La seguridad está integrada en todos los aspectos de Azure y le ofrece unas ventajas exclusivas que se derivan
de una inteligencia global de seguridad, unos sofisticados controles orientados al cliente y una infraestructura
segura reforzada. Esta potente combinación le ayuda a proteger sus datos y aplicaciones, viene en ayuda de sus
esfuerzos en cumplimiento normativo y proporciona una seguridad rentable para organizaciones de todos los
tamaños. Este enfoque permite crear un sólido punto de partida para cualquier directiva de seguridad, pero no
invalida la necesidad de seguir unos procedimientos de seguridad igualmente potentes en relación con los
servicios de seguridad que se usan.
Controles de seguridad integrados
Una infraestructura de alta seguridad resulta difícil de mantener cuando los controles de seguridad no son
intuitivos y deben configurarse por separado. Azure incluye controles de seguridad integrados en una variedad
de servicios que le ayuda a proteger datos y cargas de trabajo de manera rápida, y a administrar el riesgo en los
entornos híbridos. Las soluciones de asociados integradas permiten también trasladar fácilmente a la nube los
elementos de protección existentes.
Directivas de identidad nativas en la nube
La identidad se está convirtiendo en el nuevo plano de control límite de la seguridad, asumiendo ese papel
desde la perspectiva tradicional centrada en la red. Los perímetros de red se han vuelto cada vez más porosos y
la defensa del perímetro ya no es tan eficaz como lo era antes de la aparición de las características BYOD y las
aplicaciones en la nube. La administración de identidades y el control de acceso de Azure permiten un acceso
seguro e ininterrumpido a todas las aplicaciones.
Una directiva de ejemplo nativa en la nube para la identidad en directorios en la nube y locales podría incluir
requisitos como los siguientes:
Acceso autorizado a los recursos con el control de acceso basado en rol de Azure (RBAC de Azure), la
autenticación multifactor y el inicio de sesión único (SSO).
Mitigación rápida de identidades de usuario sospechosas.
Acceso Just-In-Time (JIT) suficiente que se concede tarea por tarea para limitar la exposición de credenciales
de administrador con demasiados privilegios.
Identidad de usuario extendida y acceso a las directivas en varios entornos mediante Azure Active Directory.
Aunque es importante entender la materia de base de referencia de identidad en el contexto de la materia de
base de referencia de seguridad, en las Cinco materias de gobernanza de la nube se trata como una materia
aparte.
Directivas de acceso de red
El control de las redes incluye la configuración, administración y protección de los elementos de la red como,
por ejemplo, las redes virtuales, el equilibrio de carga, los DNS y las puertas de enlace. Los controles
proporcionan a los servicios un medio para comunicarse e interoperar. Azure incluye una sólida y segura
infraestructura de red que respalda sus requisitos de conectividad de aplicaciones y servicios. La conectividad de
red es posible entre recursos ubicados en Azure, entre recursos locales y hospedados en Azure y entre Internet y
Azure.
Una directiva nativa en la nube para los controles de red puede incluir requisitos como los siguientes:
Las conexiones híbridas a recursos locales podrían no estar permitidas en una directiva nativa en la nube. Si
se comprueba la necesidad de una conexión híbrida, puede que un ejemplo de directiva de seguridad
empresarial más sólida resulte más adecuado.
Los usuarios pueden establecer conexiones seguras con Azure y dentro de este mediante redes virtuales y
grupos de seguridad de red.
Windows Azure Firewall nativo protege los hosts del tráfico malintencionado al limitar el acceso a los
puertos. Un buen ejemplo de esta directiva es un requisito para bloquear (o no habilitar) el tráfico directo a
una máquina virtual a través de SSH/RDP.
Servicios como el firewall de aplicaciones web (WAF) en Azure Application Gateway y Azure DDoS Protection
protegen las aplicaciones y garantizan la disponibilidad de las máquinas virtuales que se ejecutan en Azure.
No se deberían deshabilitar estas características.
Protección de los datos
Uno de los elementos clave para la protección de datos en la nube consiste en tener en cuenta los posibles
estados en que se pueden producir datos y qué controles hay disponibles para cada estado. Como parte de los
procedimientos recomendados de cifrado y seguridad de datos en Azure, se ofrecen recomendaciones
centradas en los estados de datos siguientes:
Los controles de cifrado de datos están integrados en los servicios, desde Virtual Machines a Storage y SQL
Database.
A medida que se trasladan los datos entre nubes y clientes, estos se pueden proteger mediante protocolos de
cifrado estándar.
Azure Key Vault permite a los usuarios proteger y controlar las claves criptográficas, contraseñas, cadenas de
conexión y certificados que usan las aplicaciones y servicios en la nube.
Azure Information Protection le ayudará a clasificar, etiquetar y proteger la información confidencial de las
aplicaciones.
Aunque estas características están integradas en Azure, cada una de ellas requiere configuración y esto podría
aumentar los costos. Se recomienda la alineación de cada característica nativa en la nube con una estrategia de
clasificación de datos.
Supervisión de la seguridad
La supervisión de seguridad es una estrategia proactiva que audita los recursos a fin de identificar los sistemas
que no cumplen con los estándares o los procedimientos recomendados de la organización. Azure Security
Center proporciona una línea de base de seguridad unificada y Microsoft Defender for Identity en todas las
cargas de trabajo en la nube híbrida. Con Security Center, puede aplicar directivas de seguridad en las cargas de
trabajo, limitar la exposición a amenazas y detectar y responder a los ataques. Esto incluye lo siguiente:
Vista unificada de la seguridad en todas las cargas de trabajo locales y en la nube con Azure Security Center.
Evaluaciones de seguridad y supervisión continuas para garantizar el cumplimiento y corregir las
vulnerabilidades.
Herramientas interactivas e inteligencia de amenazas contextual para una investigación optimizada.
Registro completo e integración con la información de seguridad existente.
Reduce la necesidad de soluciones de seguridad únicas, caras y no integradas.
Extensión de las directivas nativas de nube
El uso de la nube puede reducir en parte la carga de seguridad. Microsoft proporciona seguridad física para los
centros de datos de Azure y ayuda a proteger la plataforma de nube frente a amenazas como un ataque de
denegación de servicio distribuido. Dado que Microsoft tiene miles de especialistas en ciberseguridad que
trabajan en ella a diario, los recursos para detectar, evitar o mitigar los ciberataques son considerables. De
hecho, aunque las organizaciones solían preocuparse por la seguridad de la nube, la mayoría ahora comprende
que el nivel de la inversión en personal e infraestructura especializada que realizan proveedores como Microsoft
convierte la nube en un entorno más seguro que la mayoría de los centros de datos locales.
El uso de la nube puede reducir en parte la carga de seguridad. Microsoft proporciona seguridad física para los
centros de datos de Azure y ayuda a proteger la plataforma de nube frente a amenazas como un ataque de
denegación de servicio distribuido. Dado que Microsoft tiene miles de especialistas en ciberseguridad que
trabajan en ella a diario, los recursos para detectar, evitar o mitigar los ciberataques son considerables. De
hecho, aunque las organizaciones solían preocuparse por la seguridad de la nube, la mayoría ahora comprende
que el nivel de la inversión en personal e infraestructura especializada que realizan proveedores como Microsoft
convierte la nube en un entorno más seguro que la mayoría de los centros de datos locales.
Sin embargo, incluso con esta inversión en una base de referencia de seguridad nativa de nube, se recomienda
que cualquier directiva de base de referencia de seguridad se extienda a las directivas nativas de nube
predeterminadas. Los siguientes son ejemplos de directivas extendidas que se deben tener en cuenta incluso en
un entorno nativo en la nube:
Proteger las máquinas vir tuales. La seguridad debería ser la prioridad principal de todas las
organizaciones, y lograr que esta sea eficaz requiere varias cosas. Debe evaluar el estado de la seguridad,
protegerse contra amenazas de seguridad y, posteriormente, detectar y responder rápidamente a las
amenazas que ya se están produciendo.
Proteger los contenidos de las máquinas vir tuales. La configuración de copias de seguridad
automatizadas regulares es fundamental para protegerse frente a errores del usuario. Sin embargo, esto no
es suficiente. También hay que asegurarse de que las copias de seguridad están protegidas frente a
ciberataques y que están disponibles cuando las necesita.
Super visión de aplicaciones. Este patrón abarca varias tareas, entre las que se incluye la obtención de
información sobre el estado de las máquinas virtuales, la descripción de las interacciones entre ellas y el
establecimiento de maneras de supervisar las aplicaciones que estas máquinas virtuales ejecutan. Todas
estas tareas son fundamentales para mantener sus aplicaciones en ejecución ininterrumpidamente.
Protección y auditoría del acceso a los datos. Las organizaciones deben auditar todos los accesos a los
datos y usar las funcionalidades avanzadas de aprendizaje automático para resaltar las desviaciones de los
patrones de acceso normales.
Procedimiento de conmutación por error. Las operaciones en la nube que tienen baja tolerancia a
errores deben ser capaces de realizar una conmutación por error o una recuperación después de un
incidente de ciberseguridad o de la plataforma. Estos procedimientos no solo se deben documentar sino que
también se deben practicar con carácter trimestral.
Pasos siguientes
Ahora que ha revisado las directivas de ejemplo de línea de base de seguridad para soluciones nativas en la
nube, vuelva a la guía de revisión de directivas y empiece a trabajar en este ejemplo para crear sus propias
directivas de adopción de la nube.
Cree sus propias directivas mediante la guía de revisión de directivas
Guía de seguridad de Microsoft
Herramientas
El portal de confianza de servicios de Microsoft y el administrador de cumplimiento pueden ayudarle a cumplir
esos requisitos:
Superar los desafíos de administración de cumplimiento.
Responsabilizarse de cumplir los requisitos normativos.
Realizar auditorías y autoevaluaciones de riesgos sobre el uso del servicio en la nube empresarial.
Estas herramientas están diseñadas para ayudar a las organizaciones a llevar a cabo obligaciones de
cumplimiento complejas y a mejorar las funcionalidades de protección de datos al elegir y usar servicios de
Microsoft Cloud.
El por tal de confianza de ser vicios de Microsoft proporciona información detallada y herramientas para
ayudarle a satisfacer sus necesidades de uso de los servicios de Microsoft Cloud, lo que incluye Azure,
Microsoft 365, Dynamics 365 y Windows. El portal es una tienda integral donde puede obtener información
sobre seguridad, normativa, cumplimiento y privacidad relacionada con la nube de Microsoft. Se trata de la
ubicación en la que se publican la información y los recursos necesarios para realizar evaluaciones de riesgos de
autoservicio propias de los servicios y las herramientas en la nube. El portal se creó para ayudar a realizar un
seguimiento de las actividades de cumplimiento normativo de Azure e incluye:
Administrador de cumplimiento: el administrador de cumplimiento, una herramienta de evaluación de
riesgos basada en flujos de trabajo del portal de confianza de servicios de Microsoft, le permite realizar
seguimientos, asignar y comprobar las actividades de cumplimiento normativo de la organización
relacionadas con servicios en la nube de Microsoft, por ejemplo, Microsoft 365, Dynamics 365 y Azure.
Puede encontrar más información en la siguiente sección.
Documentos de confianza: hay tres categorías de guías que proporcionan abundantes recursos para
evaluar la nube de Microsoft y para conocer más información en materia de seguridad, cumplimiento y
privacidad de las operaciones de Microsoft, y que le ayudan a mejorar las funcionalidades de protección de
los datos. Entre estas guías s incluyen:
Informes de auditoría: los informes de auditoría le permiten estar al día con la información más reciente
sobre privacidad, seguridad y cumplimiento de los servicios en la nube de Microsoft. Esta información
incluye ISO, SOC, FedRAMP y otros informes de auditoría, cartas intermedias y materiales relacionados con
auditorías independientes de terceros de servicios en la nube de Microsoft, como Azure, Microsoft 365,
Dynamics 365, etc.
Guías de protección de datos: las guías de protección de datos le proporcionan información sobre cómo
protegen los servicios en la nube de Microsoft sus datos y sobre cómo puede administrar la seguridad de los
datos en la nube y el cumplimiento para su organización. Estas guías incluyen informes técnicos detallados
acerca del diseño y operación de los servicios en la nube de Microsoft, las preguntas frecuentes, los informes
de evaluaciones de seguridad de finales de año, los resultados de las pruebas de penetración, y una guía para
ayudarle a realizar evaluaciones de riesgos y a mejorar las funcionalidades de protección de los datos.
Plano técnico de seguridad y cumplimiento de Azure: Los planos técnicos le proporcionan recursos
que le ayudan a la hora de compilar e iniciar aplicaciones basadas en la nube que le ayudan a cumplir con las
estrictas normativas y estándares. Con más certificaciones que ningún otro proveedor de nube, puede
confiar en la implementación de las cargas de trabajo críticas en Azure, con planos técnicos que incluyen:
Información general y orientaciones específicas del sector.
Matriz de responsabilidades del cliente.
Arquitecturas de referencia con modelos de amenazas.
Matrices de implementación de control.
Automatización para implementar arquitecturas de referencia.
Recursos de privacidad. Se proporciona documentación sobre evaluaciones del efecto de la protección
de los datos, solicitudes del titular de los datos y notificaciones de vulneración de datos para que se
incorporen al propio programa de rendición de cuentas como complemento del Reglamento general
de protección de datos (RGPD).
Introducción al RGPD: Los servicios y productos de Microsoft ayudan a las organizaciones a cumplir con
los requisitos del RGPD cuando recopilan o procesan datos personales. El portal de confianza de servicios de
Microsoft está diseñado para proporcionarle información sobre las funcionalidades de los servicios de
Microsoft que puede usar para abordar los requisitos específicos del RGPD. La documentación puede
ayudarle con sus responsabilidades con respecto al RGPD y a comprender las medidas técnicas y
organizativas que implica. Se proporciona documentación de las evaluaciones del efecto de la protección de
datos, las solicitudes del titular de los datos y notificaciones de vulneración de datos para que los incorpore
en su propio programa de rendición de cuentas como complemento al reglamento general de protección de
datos.
Solicitudes del titular de los datos: El RGPD concede a las personas (o titulares de los datos)
determinados derechos relacionados con el procesamiento de sus datos personales. Entre estos
derechos se incluyen los que implican corregir datos incorrectos, eliminar datos o restringir su
procesamiento, así como el derecho a recibir sus datos y a atender una solicitud para transmitirlos a
otro controlador.
Vulneración de datos: El RGPD impone requisitos de notificación para los controladores y
procesadores de datos en caso de que se presente una vulneración de los datos personales. El portal
de confianza de servicios de Microsoft le proporciona información sobre cómo Microsoft impide las
vulneraciones, cómo las detecta y cómo responde y le envía una notificación como controlador de los
datos si se produce una vulneración.
Evaluación de impacto de la protección de datos: Microsoft ayuda a los controladores a
completar evaluaciones del impacto de la protección de datos del RGPD. El RGPD proporciona una
lista no exhaustiva de casos en que se debe realizar este tipo de evaluaciones como, por ejemplo, el
procesamiento automático con fines de generación de perfiles y actividades semejantes, el
procesamiento a gran escala de categorías especiales de datos personales y la supervisión sistemática
de un área accesible públicamente a gran escala.
Otros recursos: además de una guía sobre herramientas analizadas en las secciones anteriores, el
portal de confianza de servicios de Microsoft también proporciona otros recursos entre los que se
incluyen el cumplimiento regional, recursos adicionales para el Centro de seguridad y cumplimiento, y
preguntas frecuentes sobre dicha plataforma, el administrador de cumplimiento, la privacidad o el
RGPD.
Cumplimiento regional: el portal de confianza de servicios de Microsoft proporciona numerosos
documentos sobre cumplimiento y orientaciones sobre los servicios en línea de Microsoft para ayudarle a
cumplir con los requisitos de cumplimiento en diferentes regiones como, por ejemplo, la República Checa,
Polonia y Rumanía.
Conclusiones inteligentes exclusivas

A medida que crece el volumen y complejidad de las señales de seguridad, determinar si esas señales
constituyen amenazas verdaderas y, posteriormente, actuar en consecuencia, lleva demasiado tiempo. Microsoft
ofrece una variedad sin precedentes en lo que respecta a inteligencia de seguridad que se ofrece a escala en la
nube para ayudarle a detectar y solucionar rápidamente las amenazas. Para más información, consulte la
introducción a Azure Security Center.
Inteligencia de Azure sobre amenazas
Mediante la opción de inteligencia sobre amenazas disponible en Security Center, los administradores de TI
pueden identificar las amenazas de seguridad en el entorno. Por ejemplo, pueden identificar si un determinado
equipo forma parte de una red de robots (botnet). Los equipos pueden convertirse en nodos en una de estas
redes cuando los atacantes instalan de forma ilegal malware que se conecta en secreto al equipo para hacerse
con el control. La inteligencia sobre amenazas también puede identificar posibles amenazas procedentes de
canales de comunicación clandestinos, como la Internet oscura (dark web).
Para crear esta inteligencia sobre amenazas, Security Center usa datos de varios orígenes dentro de Microsoft. y
aprovecha estos datos para identificar posibles amenazas en su entorno. El panel de inteligencia sobre
amenazas está compuesto por tres opciones principales:
Tipos de amenazas detectadas
Origen de la amenaza
Mapa de información sobre amenazas
Aprendizaje automático en Azure Security Center

Azure Security Center analiza en profundidad una gran cantidad de datos procedentes de diversas soluciones de
Microsoft y de asociados que le ayudarán a lograr mayor seguridad. Para aprovechar estos datos, la compañía
puede usar ciencia de datos y aprendizaje automático para la prevención, detección e investigación de las
amenazas.
En líneas generales, Azure Machine Learning le ayuda a lograr dos resultados:
Detección de próxima generación
Los atacantes cada vez están mas automatizados y son más sofisticados. Y ellos también usan la ciencia de
datos. Usan técnicas de ingeniería inversa para sortear las protecciones y compilar sistemas que admiten
mutaciones de comportamiento. Enmascaran sus actividades como ruido y aprenden rápidamente de los
errores. El aprendizaje automático nos ayuda a dar respuesta a estas amenazas.
Base de referencia de seguridad simplificada
Tomar decisiones de seguridad eficaces no es fácil. Requiere experiencia y conocimientos de seguridad. Mientras
que algunas organizaciones grandes pueden contar con estos expertos en plantilla, otras muchas empresas no.
Azure Machine Learning permite a los clientes beneficiarse de los conocimientos de otras organizaciones a la
hora de tomar decisiones de seguridad.
Análisis del comportamiento

El análisis del comportamiento es una técnica que analiza datos y los compara con una serie de patrones
conocidos. Estos patrones no son simples firmas, sino que están determinados por unos complejos algoritmos
de aprendizaje automático que se aplican a conjuntos de datos masivos. También se determinan por medio de
un análisis cuidadoso de los comportamientos malintencionados, llevado a cabo por analistas expertos. Azure
Security Center puede utilizar el análisis del comportamiento para identificar recursos en peligro a partir del
análisis de registros de las máquinas virtuales, registros de los dispositivos de redes virtuales, registros de los
tejidos, volcados de memoria y otros orígenes.
Herramientas de base de referencia de seguridad
La materia de base de referencia de seguridad es una de las cinco materias de gobernanza de la nube. Esta
materia se centra en formas de establecer directivas que protegen la red, los recursos y, lo que es más
importante, los datos que residirán en una solución del proveedor de nube. Dentro de las cinco materias de
gobernanza de la nube, la correspondiente a la base de referencia de seguridad implica la clasificación del
patrimonio digital y los datos. También implica documentación de estrategias de mitigación, tolerancia
empresarial y riesgos que se asocian a la seguridad de los datos, los recursos y las redes. Desde una perspectiva
técnica, esta materia también incluye la participación en decisiones sobre el cifrado, los requisitos de red, las
estrategias de identidad híbrida y las herramientas para automatizar la aplicación de directivas de seguridad en
los grupos de recursos.
La siguiente lista de herramientas de Azure puede contribuir desarrollar las directivas y los procesos que
admiten esta materia.
A Z URE
P O RTA L Y
A Z URE A Z URE
H ERRA M IEN T RESO URC E A Z URE K EY A Z URE SEC URIT Y A Z URE
A M A N A GER VA ULT A Z URE A D P O L IC Y C EN T ER M O N ITO R
Aplicación de Sí No Sí No No No
controles de
acceso a
recursos y
creación de
recursos
Protección de Sí No No Sí No No
redes
virtuales
Cifrado de No Sí No No No No
discos
virtuales
Cifrado de No Sí No No No No
bases de
datos y
almacenamie
nto PaaS
Administració No No Sí No No No
n de servicios
de identidad
híbrida
Restricción de No No No Sí No No
tipos de
recurso
permitidos
A Z URE
P O RTA L Y
A Z URE A Z URE
H ERRA M IEN T RESO URC E A Z URE K EY A Z URE SEC URIT Y A Z URE
A M A N A GER VA ULT A Z URE A D P O L IC Y C EN T ER M O N ITO R
Aplicación de No No No Sí No No
restricciones
geográficas
regionales
Supervisión No No No No Sí Sí
del estado de
seguridad de
redes y
recursos
Detección de No No No No Sí Sí
actividad
malintenciona
da
Detección de No No No No Sí No
vulnerabilidad
es de forma
preventiva
Configuración Sí No No No No No
de copia de
seguridad y
recuperación
ante
desastres
Para ver una lista completa de servicios y herramientas de seguridad de Azure, consulte Servicios y tecnologías
de seguridad disponibles en Azure.
Los clientes suelen usar herramientas de terceros para habilitar las actividades de la materia de base de
referencia de seguridad. Para más información, consulte el artículo Integración de soluciones de seguridad en
Azure Security Center.
Además de las herramientas de seguridad, Administración de cumplimiento de Microsoft 365 proporciona
orientación amplia, informes y documentación relacionada que pueden ayudarle a realizar evaluaciones de
riesgos como parte de su proceso de planeación de migración.
Información general sobre la materia de base de
referencia de identidad
La base de referencia de identidad es una de las cinco materias de la gobernanza en la nube dentro del modelo
de gobernanza de Cloud Adoption Framework. La identidad se considera cada vez más como el perímetro de
seguridad principal en la nube, lo que supone un avance respecto del enfoque tradicional de seguridad de red.
Los servicios de identidad proporcionan los mecanismos principales que respaldan el control de acceso y la
organización en entornos de TI, y la materia de la base de referencia de identidad complementa a la materia de
la base de referencia de seguridad mediante la aplicación coherente de requisitos de autenticación y
autorización en el trabajo de adopción de la nube.
NOTE
La materia de base de referencia de identidad no reemplaza los procedimientos, procesos y equipos de TI existentes que
permiten a su organización administrar y proteger los servicios de identidad. El propósito principal de esta materia es
identificar los posibles riesgos empresariales relacionados con la identidad y proporcionar orientación sobre la mitigación
de riesgos al personal de TI responsable de la implementación, el mantenimiento y el funcionamiento de la infraestructura
de administración de identidad. A medida que desarrolla procesos y directivas de gobernanza, asegúrese de implicar a los
equipos de TI pertinentes en sus procesos de revisión y planeación.
En esta sección de Cloud Adoption Framework se describe el enfoque de desarrollo de una materia de base de
referencia de identidad como parte de la estrategia de gobernanza en la nube. La principal audiencia a la que se
dirigen estas instrucciones son los arquitectos de nube de su organización y otros miembros de su equipo de
gobernanza en la nube. Las decisiones, las directivas y los procesos que emergen de esta materia deben implicar
la involucración y discusiones con miembros pertinentes de los equipos de TI responsables de la
implementación y administración de soluciones de administración de identidad de su organización.
Si su organización carece de conocimientos internos sobre la identidad y seguridad, considere la posibilidad de
involucrar a consultores externos como parte de esta materia. Considere también la posibilidad de involucrar a
Servicios de consultoría de Microsoft, el servicio de adopción de la nube Microsoft FastTrack u otros asociados
externos de adopción de la nube para determinar los problemas relacionados con esta materia.
Policy statements
materia de base de referencia de identidad. Use instrucciones de directiva de ejemplo como punto de partida
para definir las directivas de línea de base de seguridad.
Cau t i on

materia de base de referencia de identidad. Use cada paso como punto de partida para análisis en el equipo de
gobernanza en la nube y con los equipos de TI y empresariales afectados de toda la organización para
establecer las directivas y los procesos necesarios para administrar los riesgos relacionados con la identidad.
Plantilla de la materia de base de referencia de identidad:

Descargue la plantilla para documentar una materia de base
de referencia de identidad.

asociados normalmente a la materia de base de referencia de
identidad.

momento adecuado para invertir en la materia de base de
referencia de identidad.
Procesos de adhesión a las directivas: Procesos

recomendados para admitir el cumplimiento de directiva en
la materia de base de referencia de identidad.


implementar para admitir la materia de base de referencia de
identidad.
Pasos siguientes
Empiece evaluando los riesgos empresariales en un entorno específico.
Plantilla de la materia de base de referencia de
identidad
procedimientos de gobernanza. La plantilla siguiente proporciona un punto inicial para documentar y
comunicar las declaraciones de las directivas que rigen los servicios de identidad en la nube.
para definir las declaraciones de las directivas de Línea de base de identidad de la organización.
IMPORTANT
posteriores para definir una materia de base de referencia de identidad eficaz dentro de su estrategia de gobernanza en la
nube.
Descargar la plantilla de la materia de base de referencia de identidad
Pasos siguientes
de la nube actual.
de base de referencia de identidad
En este artículo se describen las razones por las que los clientes normalmente adoptan una materia sobre la
base de referencia de la identidad dentro de una estrategia de gobernanza de la nube. También se proporcionan
algunos ejemplos de riesgos empresariales que impulsan las declaraciones de directiva.
Relevancia
Los directorios locales tradicionales están diseñados para permitir a las empresas controlar estrictamente los
permisos y directivas de usuarios, grupos y roles dentro de sus redes internas y centros de datos. Estos
directorios suelen facilitar implementaciones de un solo inquilino, con servicios aplicables únicamente en el
entorno local.
Los servicios de identidad de la nube amplían las funcionalidades de autenticación y control de acceso de una
organización a Internet. Admiten la existencia de varios inquilinos y se pueden usar para administrar usuarios y
la directiva de acceso en todas las aplicaciones en la nube y las implementaciones. Las plataformas de nube
pública disponen de servicios de identidad nativos para la nube que admiten tareas de administración e
implementación, y que son capaces de variar los niveles de integración con las soluciones de identidad locales
existentes. Puede que todas estas características den lugar a que la directiva de identidad de la nube sea más
compleja de lo que requieren sus soluciones locales tradicionales.
La importancia de la materia sobre la base de referencia de la identidad para su implementación de la nube
dependerá del tamaño de su equipo y de la necesidad de integrar la solución de identidad basada en la nube
con un servicio de identidad local existente. Puede que las implementaciones de prueba iniciales no requieran
mucho de organización o administración por parte del usuario pero, a medida que el patrimonio de la nube
evoluciona, necesitará probablemente dar cabida a una integración organizativa y administración centralizada
más complejas.
Riesgo empresarial
La materia sobre la base de referencia de la identidad intenta dar respuesta a los principales riesgos
empresariales relacionados con los servicios de identidad y el control de acceso. Trabaje con su empresa para
identificar estos riesgos y supervise cada uno de ellos para determinar su pertinencia a medida que planee y
aplique sus implementaciones en la nube.
Los riesgos variarán según la organización, pero los siguientes pueden servir como ejemplos de riesgos
habituales relacionados con la identidad que puede usar como punto de partida para su análisis en el seno de
su equipo de gobernanza de la nube:
Acceso no autorizado. El acceso de usuarios no autorizados a información y recursos confidenciales puede
provocar pérdidas de datos o interrupciones del servicio, infracciones del perímetro de seguridad de la
organización y poner en riesgo responsabilidades empresariales o legales.
Ineficacia debida a la existencia de varias soluciones de identidad. Las organizaciones con varios
inquilinos de servicios de identidad pueden requerir varias cuentas para los usuarios. Esto puede provocar
ineficacias para los usuarios, ya que tienen que recordar varios juegos de credenciales, y para TI a la hora de
administrar las cuentas en varios sistemas. Si no se actualizan las asignaciones de acceso de los usuarios en
todas las soluciones de identidad a medida que cambia el personal, los equipos y los objetivos empresariales,
los recursos en la nube serán susceptibles de un acceso no autorizado o los usuarios no podrán acceder a
determinados recursos necesarios.
Imposibilidad de compar tir recursos con asociados externos. Las dificultades para agregar asociados
comerciales externos a las soluciones de identidad existentes pueden impedir un uso compartido de los
recursos y una comunicación empresarial eficaces.
Dependencias de identidad locales. Puede que los mecanismos de autenticación heredados o la
autenticación multifactor de terceros no esté disponible en la nube, lo cual hará que sea necesario adaptar la
migración de las cargas de trabajo o que se deban implementar servicios de identidad adicionales en la
nube. Cualquiera de estos requisitos podría retrasar o incluso impedir la migración, con el consiguiente
aumento de los costos.
Pasos siguientes
Use la plantilla de la materia de base de referencia de identidad para documentar los riesgos empresariales que
es probable que se introduzcan debido al plan actual de adopción de la nube.
tolerancia.
Métricas, indicadores y tolerancia al riesgo de la
base de referencia de identidad
Aprenda a cuantificar la tolerancia al riesgo empresarial asociada a la materia de base de referencia de

identidad. La definición de métricas e indicadores ayuda a crear un caso empresarial para invertir en la madurez
de esta materia.
Métricas
La administración de identidades se centra en la identificación, autenticación y autorización de usuarios, grupos
de usuarios o procesos automatizados, y en proporcionarles acceso adecuado a los recursos en las
implementaciones en la nube. Como parte del análisis de riesgos, querrá recopilar datos de análisis
relacionados con los servicios de identidad para determinar cuánto riesgo enfrenta, y cuán importante es la
inversión en la materia de la base de referencia de identidad para las implementaciones en la nube planeadas.
Los siguientes son ejemplos de métricas útiles que debe reunir para ayudar a evaluar la tolerancia al riesgo en la
materia de la línea de base de identidad:
Tamaño de los sistemas de identidad. Número total de usuarios, grupos u otros objetos administrados a
través de sus sistemas de identidad.
Tamaño general de la infraestructura de ser vicios de directorio. Número de bosques de directorio,
dominios e inquilinos usados por la organización.
Dependencia de los mecanismos de autenticación heredados o locales. Número de cargas de
trabajo que dependen de los mecanismos de autenticación heredados o servicios de autenticación
multifactor de terceros.
Extensión de los ser vicios de directorio implementados en la nube. Número de bosques de
directorio, dominios e inquilinos implementados en la nube.
Ser vidores de Active Director y implementados en la nube. Número de servidores de Active
Directory implementados en la nube.
Unidades organizativas implementadas en la nube. Número de unidades organizativas de Active
Directory implementadas en la nube.
Extensión de la federación. Número de sistemas de administración de identidades federados con
sistemas de la organización.
Usuarios con privilegios. Número de cuentas de usuario con acceso con privilegios elevados a recursos o
herramientas de administración.
Uso del control de acceso basado en rol de Azure. Número de suscripciones, grupos de recursos o
recursos individuales que no se administran mediante el control de acceso basado en rol de Azure (RBAC de
Azure) mediante grupos.
Notificaciones de autenticación. Número de intentos de autenticación de usuario correctos e incorrectos.
Notificaciones de autorización. Número de intentos correctos e incorrectos de los usuarios por acceder a
los recursos.
Cuentas en peligro. Número de cuentas de usuario que podrían estar en peligro.

Los riesgos relacionados con la base de referencia de identidad se relacionan en gran medida con la
complejidad de la infraestructura de identidades de su organización. Si todos los usuarios y grupos se
administran mediante un único directorio o proveedor de identidad nativo en la nube con una integración
mínima con otros servicios, el nivel de riesgo probablemente sea pequeño. A medida que aumenten las
necesidades empresariales, puede que los sistemas de administración de identidades deban admitir escenarios
más complicados, como varios directorios para admitir su organización interna o la federación con proveedores
de identidades externos. A medida que esos sistemas se vuelven más complejos, aumenta el riesgo.
de la empresa para identificar riesgos de negocio relacionados con la identidad y, luego, determine una línea de
base aceptable para la tolerancia al riesgo de identidad. En esta sección de Cloud Adoption Framework se
proporcionan ejemplos, pero los riesgos y las bases de referencia específicos de su empresa o sus
implementaciones pueden ser diferentes.
inaceptable de los riesgos identificados. Estos bancos de pruebas actúan como desencadenadores cuando
necesite tomar medidas para abordar estos riesgos. En los siguientes ejemplos, se muestra cómo las métricas
relacionadas con la identidad, como las descritas anteriormente, pueden justificar una mayor inversión en la
materia de línea de base de identidad.
Desencadenador de número de cuentas de usuario. Una empresa con más de x usuarios, grupos u
otros objetos administrados en sus sistemas de identidad puede beneficiarse de la inversión en la materia de
la línea de base de identidad para asegurarse una gobernanza eficaz en un gran número de cuentas.
Desencadenador de dependencia de identidades locales. Una empresa que planea migrar cargas de
trabajo a la nube y requiere funcionalidades de autenticación heredadas o autenticación multifactor de
terceros debe invertir en la materia de línea de base de identidad para reducir los riesgos relacionados con la
refactorización o la implementación de infraestructura de nube adicional.
Desencadenador de complejidad de ser vicios de directorio. Una empresa que mantiene más de x
bosques, dominios o inquilinos de directorio individuales debe invertir en la materia de línea de base de
identidad para reducir los riesgos relacionados con la administración de cuentas y los problemas de
eficiencia relacionados con varias credenciales de usuario repartidas entre varios sistemas.
Desencadenador de ser vicios de directorio hospedados en la nube. Una empresa que hospeda x
máquinas virtuales en servidores Active Directory hospedadas en la nube, o tiene x unidades organizativas
administradas en estos servidores basados en la nube, puede beneficiarse de la inversión en la materia de
línea de base de identidad para optimizar la integración con cualquier servicio de identidad local o externo.
Desencadenador de federación. Una empresa que implementa la federación de identidades con x
sistemas de administración de identidades externos puede beneficiarse de la inversión en la materia de la
base de referencia de identidad para garantizar una directiva de la organización coherente entre los
miembros de la federación.
Desencadenador de acceso con privilegios elevados. Una empresa con más del x % de los usuarios
con permisos elevados administrar herramientas y recursos debería plantearse invertir en la materia de línea
de base de identidad para minimizar el riesgo de sobreaprovisionamiento involuntario del acceso a los
usuarios.
Desencadenador de RBAC de Azure. Una empresa con menos del x % de los recursos con métodos de
control de acceso basado en roles de Azure debería plantearse invertir en la materia de la base de referencia
de identidad para identificar maneras optimizadas de asignar el acceso de los usuarios a los recursos.
Desencadenador de errores de autenticación. Una empresa donde los errores de autenticación
representan más del x % de los intentos debe invertir en la materia de línea de base de identidad para
asegurarse de que los métodos de autenticación no estén bajo un ataque externo, y de que los usuarios
puedan autenticarse correctamente.
Desencadenador de errores de autorización. Una empresa donde los intentos de acceso se rechazan
más del x % de las veces debe invertir en la materia de línea de base de identidad para mejorar la aplicación
y la actualización de los controles de acceso, e identificar intentos de acceso potencialmente
malintencionados.
Desencadenador de cuentas en peligro. Una empresa con más de 1 cuenta en peligro debe invertir en
la materia de línea de base de identidad para mejorar la eficacia y la seguridad de los mecanismos de
autenticación, y mejorar los mecanismos para remediar los riesgos relacionados con las cuentas en peligro.
Las métricas y desencadenadores exactos que use para medir la tolerancia al riesgo y el nivel de inversión en la
materia de línea de base de identidad serán específicos para su organización, pero los ejemplos anteriores
deberían servir como base útil para las conversaciones con su equipo de gobernanza de la nube.
Pasos siguientes
Use la plantilla de la materia de base de referencia de identidad para documentar las métricas y los indicadores
de tolerancia que se alinean con el plan actual de adopción de la nube.
Revise las directivas de base de referencia de identidad de ejemplo como punto de partida para desarrollar otras
directivas propias que aborden los riesgos empresariales específicos vinculados a los planes de adopción de la
nube.
Declaraciones de directivas de ejemplo de base de
referencia de identidad
relacionados con la identidad. Estas declaraciones son ejemplos a los que se puede hacer referencia al elaborar
el borrador de las declaraciones de directiva para satisfacer las necesidades de su organización. Estos ejemplos
no pretenden ser excluyentes y hay varias opciones posibles de directiva para solucionar cada riesgo concreto
Falta de controles de acceso

Riesgo técnico: Una configuración de control de acceso insuficiente o ad hoc puede plantear riesgos de acceso
no autorizado a recursos confidenciales o críticos.
Declaración de directiva : todos los recursos que se implementan en la nube deben controlarse mediante
identidades y roles aprobados por las directivas de gobernanza actuales.
Opciones de diseño posibles: el acceso condicional de Azure Active Directory es el mecanismo de control de
acceso predeterminado en Azure.
Acceso sobreaprovisionado
Riesgo técnico: los usuarios y grupos que controlan los recursos más allá de su área de responsabilidad
pueden dar lugar a que se produzcan modificaciones no autorizadas que provoquen interrupciones o
vulnerabilidades de seguridad.
Declaración de directiva : se implementarán las siguientes directivas:
Un modelo de acceso con privilegios mínimos se aplicará a cualquier recurso involucrado en aplicaciones
críticas o datos protegidos.
Los permisos elevados deben ser una excepción, y todas las excepciones deberán notificarse al equipo de
gobernanza de la nube. Las excepciones se auditarán con regularidad.
Opciones de diseño posibles: consulte los procedimientos recomendados de la administración de
identidades de Azure para implementar una estrategia de control de acceso basado en rol de Azure (RBAC de
Azure) que restringe el acceso en función de los principios de necesidad de saber y seguridad con privilegios
mínimos.
Ausencia de cuentas de administración compartidas entre el entorno

local y la nube
Riesgo técnico: el personal administrativo y de administración de TI con cuentas en el entorno local de Active
Directory que no tenga acceso suficiente a los recursos en la nube es posible que no pueda resolver con eficacia
los problemas operativos o de seguridad.
Declaración de directiva : todos los grupos de la infraestructura local de Active Directory que tienen
privilegios elevados se deben asignar a un rol de Azure aprobado.
Opciones de diseño posibles: implemente una solución de identidad híbrida entre Azure Active Directory
basado en la nube y Active Directory local, y agregue los grupos locales requeridos a los roles de Azure
necesarios para realizar su trabajo.
Mecanismos de autenticación no seguros

Riesgo técnico: los sistemas de administración de identidad con métodos de autenticación de usuarios que no
son suficientemente seguros, como las combinaciones de usuario y contraseña, pueden generar contraseñas
comprometidas o pirateadas, planteando un riesgo mayor de acceso no autorizado a sistemas en la nube
seguros.
Declaración de directiva : todas las cuentas deben iniciar sesión en recursos protegidos con un método de
autenticación multifactor.
Opciones de diseño posibles: para Azure Active Directory, implemente Azure Multi-factor Authentication
como parte del proceso de autorización de usuario.
Proveedores de identidades aislados

Riesgo técnico: los proveedores de identidades incompatibles pueden provocar la incapacidad de compartir
recursos o servicios con clientes u otros asociados empresariales.
Declaración de directiva : la implementación de las aplicaciones que requieren autenticación de cliente debe
usar un proveedor de identidades aprobado que sea compatible con el proveedor de identidades principal para
usuarios internos.
Opciones de diseño posibles: implemente la federación con Azure Active Directory entre los proveedores de
identidades internos y de cliente, o utilice Azure Active Directory B2B.
Revisiones de identidad
Riesgo técnico: con los cambios empresariales a lo largo del tiempo, la adición de nuevas implementaciones
en la nube u otros problemas de seguridad puede aumentar los riesgos de acceso no autorizado a recursos
seguros.
Declaración de directiva : los procesos de gobernanza en la nube deben incluir revisiones trimestrales con los
equipos de administración de identidad para así poder identificar usuarios malintencionados o patrones de uso
que deban evitarse mediante la configuración de recursos en la nube.
Opciones de diseño posibles: celebrar una reunión de revisión de seguridad trimestral en la que participen
los miembros del equipo de gobernanza y el personal de TI responsable de administrar los servicios de
identidad. Revisar las métricas y los datos de seguridad existentes para identificar deficiencias en las
herramientas y la directiva de administración de identidad, y actualizar la directiva para remediar todos los
riesgos nuevos.
Pasos siguientes
los riesgos empresariales específicos que se alinean con los planes de adopción de la nube.
identidad, descargue la plantilla de la materia de base de referencia de identidad.
directiva de línea de base de identidad.
Procesos de cumplimiento de la directiva de la base
de referencia de identidad
base de referencia de identidad. La gobernanza eficaz de la identidad empieza con procesos manuales
periódicos que guían la adopción y las revisiones de la directiva de identidad. Esto requiere la participación
regular del equipo de gobernanza de la nube y las partes interesadas de TI y de la empresa para revisar y
actualizar la directiva y garantizar el cumplimiento de esta. Además, muchos procesos de aplicación y
supervisión en curso se pueden automatizar o complementar con herramientas para reducir la sobrecarga de la
gobernanza y permitir una respuesta más rápida a la desviación de directivas.

Las herramientas de administración de identidades ofrecen funcionalidades y características que facilitan en
gran medida la administración de usuarios y el control de acceso en una implementación en la nube. También se
requieren procesos y directivas bien diseñados y ponderados para apoyar los objetivos de la organización. El
siguiente es un conjunto de procesos de ejemplo que normalmente están incluidos en la materia sobre la base
de referencia de la identidad. Use estos ejemplos como punto de partida al planear los procesos que le
permitirán continuar actualizando la directiva de identidad en función de los cambios que se produzcan en la
empresa y los comentarios de los equipos de TI cuya tarea es la activación de la guía de gobernanza.
Planeamiento y evaluación inicial de los riesgos: como parte de la adopción inicial de la materia sobre la
base de referencia de la identidad, identifique los principales riesgos empresariales y las tolerancias
relacionadas con la administración de identidades en la nube. Esta información se usa para analizar riesgos
técnicos concretos con los miembros de los equipos de TI responsables de la administración de los servicios de
identidad, y para desarrollar un conjunto de referencia de directivas de seguridad para mitigar esos riesgos, con
el fin de establecer la estrategia de gobernanza inicial.
Planeación de la implementación: Antes de realizar cualquier implementación, revise las necesidades de
acceso de todas las cargas de trabajo y desarrolle una estrategia de control de acceso que se adapte a la
directiva de identidad corporativa establecida. Documente cualquier desajuste entre las necesidades y la
directiva actual para determinar si se requieren actualizaciones de la directiva y modifíquela si es necesario.
Pruebas de la implementación: como parte del proceso de implementación, el equipo de gobernanza de la
nube en colaboración con los equipos de TI encargados de los servicios de identidad son responsables de
revisar la implementación para validar el cumplimiento de la directiva de seguridad.
Planeación anual: realice todos los años una revisión de alto nivel de la estrategia de administración de
identidades. Explore los cambios planeados para el entorno de servicios de identidad y las estrategias
actualizadas de adopción de la nube para identificar un posible aumento del riesgo o la necesidad de modificar
los patrones actuales de la infraestructura de identidades. También puede usar este tiempo para revisar los
procedimientos recomendados de administración de identidades más recientes e integrarlos en sus directivas y
procesos de revisión.
Planeación trimestral: de forma trimestral, efectúe una revisión general de los datos de auditoría de
identidades y de control de acceso, y reúnase con los equipos de adopción de la nube para identificar nuevos
riesgos o requisitos operativos que requieran actualizar la directiva de identidad o cambiar la estrategia de
control de acceso.
de gobernanza de la nube, por si hubiera carencias de conocimientos relacionadas con una directiva nueva o
cambiante, y con los riesgos relacionados con la identidad. Invite al personal de TI pertinente a participar en las
revisiones y el planeamiento como asesores técnicos temporales o miembros permanentes del equipo.
Educación y aprendizaje: ofrezca sesiones de aprendizaje con carácter bimensual para asegurarse de que
tanto los desarrolladores como el personal de TI están al día de los requisitos más recientes de las directivas de
identidad. Como parte de este proceso, revise y actualice cualquier documentación, guía u otros recursos de
aprendizaje para asegurarse de que estén sincronizados con las declaraciones de directiva corporativa más
recientes.
de la nube para garantizar su alineación continuada con la directiva de identidad. Use este proceso de revisión
para comprobar el acceso de los usuarios en relación con los cambios en la empresa para asegurarse de que los
usuarios tienen el acceso correcto a los recursos en la nube y para asegurarse de que las estrategias de acceso,
como RBAC de Azure, se siguen de forma coherente. Identifique todas las cuentas con privilegios elevados y
documente su finalidad. El resultado de este proceso de revisión es un informe para el equipo de estrategia de la
nube y para cada equipo de adopción de la nube en el que se detalla la adhesión general a la directiva. El
informe también se almacena con fines de auditoría y legales.

Una estrategia de base de referencia de identidad correcta depende de la visibilidad del estado actual y pasado
de los sistemas de identidad. Sin la capacidad para analizar las métricas pertinentes de la implementación de la
nube y los datos relacionados, no se pueden identificar cambios en los riesgos ni detectar infracciones de las
tolerancias al riesgo. Los procesos de gobernanza en curso que se analizaron anteriormente requieren datos de
calidad para asegurarse de que se puede modificar la directiva para adaptarse a las necesidades cambiantes de
su negocio.
Asegúrese de que los equipos de TI han implementado sistemas de supervisión automatizados para los
servicios de identidad que capturan los registros y la información de auditoría que necesita para evaluar los
riesgos. Sea proactivo en la supervisión de estos sistemas para asegurar la pronta detección y mitigación de
posibles infracciones de la directiva, y cerciórese de que cualquier cambio en la infraestructura de identidad
queda reflejado en su estrategia de supervisión.

Las infracciones de la directiva de identidad pueden provocar accesos no autorizados a información confidencial
y producir daños importantes en servicios y aplicaciones críticos. Cuando se detectan infracciones, debe realizar
acciones para volver a alinearse con la directiva lo antes posible. El equipo de TI puede automatizar la mayoría
de los desencadenadores de infracciones mediante las herramientas que se describen en la cadena de
herramientas sobre la base de referencia de la identidad.
Se ha detectado una actividad sospechosa: los inicios de sesión de usuarios desde direcciones IP de
proxy anónimo, ubicaciones desconocidas o los inicios de sesión desde ubicaciones sorprendentemente
distantes pueden indicar una posible vulneración de la cuenta o un intento de acceso malintencionado. El
inicio de sesión se bloqueará hasta que se pueda verificar la identidad del usuario y restablecer la contraseña.
Se han filtrado credenciales de usuario: Las cuentas cuyo nombre de usuario y contraseña se filtren a
Internet se deshabilitarán hasta que se pueda verificar la identidad del usuario y restablecer la contraseña.
Se han detectado controles de acceso insuficientes: Aquellos recursos protegidos en los que las
restricciones de acceso no reúnen los requisitos de seguridad tendrán bloqueado el acceso hasta que lo sí
hagan.
Pasos siguientes
Use la plantilla de la materia de base de referencia de identidad para documentar los procesos y los
Mejora de la materia sobre la base de referencia de la identidad
Mejora de la materia sobre la base de referencia de
la identidad
Esta materia sobre la base de referencia de la identidad se centra en las maneras de establecer directivas que
garanticen la coherencia y continuidad de las identidades de usuario, independientemente del proveedor de
servicios en la nube que hospede la aplicación o carga de trabajo. Dentro de las cinco materias de gobernanza
de la nube, la base de referencia de identidad incluye decisiones relacionadas con la estrategia de identidad
híbrida, la evaluación y extensión de los repositorios de identidades, la implementación del inicio de sesión
único (mismo inicio de sesión), la auditoría y la supervisión de usos no autorizados o la intervención de actores
malintencionados. En algunos casos, también puede implicar decisiones para modernizar, consolidar o integrar
varios proveedores de identidades.
En este artículo se destacan algunas tareas potenciales en las que su empresa puede participar para desarrollar
y mejorar la materia sobre la base de referencia de la identidad. Estas tareas se dividen en las fases de
planeamiento, compilación, adopción y funcionamiento de la implementación de una solución de nube que,

decidir cuánto invertir en estas actividades para mejorar la materia de base de referencia de identidad.
Cau t i on
nube.
Evalúe las opciones de su cadena de herramientas de la base de referencia de identidad e implemente una
estrategia híbrida que sea adecuada para su organización.
Defina los roles y asignaciones que gobernarán la administración de la identidad y el acceso en la nube.
Defina los grupos locales y asígnelos a los roles correspondientes basados en la nube.
Proveedores de identidades de inventario (incluidas las identidades controladas por bases de datos que
utilizan las aplicaciones personalizadas).
Consolide e integre a los proveedores de identidades en los que existe una duplicación para simplificar la
solución global de identidad y reducir el riesgo.
Evalúe la compatibilidad híbrida de los proveedores de identidades existentes.
Para aquellos proveedores de identidades que no presentan esta compatibilidad, evalúe las opciones de
consolidación o reemplazo.

Considere la posibilidad de realizar una prueba piloto antes de implementar la cadena de herramientas de la
base de referencia de identidad, para asegurarse de que esta simplifica la experiencia del usuario al máximo.
Aplique la información obtenida de estas pruebas piloto en la fase anterior a la implementación. Repita las
pruebas hasta que los resultados sean aceptables.
Actualice el documento de directrices de arquitectura para que incluya los planes de implementación y
adopción por parte del usuario, y distribúyalo a las principales partes interesadas.
Evalúe la posibilidad de establecer un programa para usuarios pioneros y extiéndalo a un número limitado
de usuarios.
A continuación, eduque a los usuarios y equipos a los que más afecten las directrices de la arquitectura.
Evalúe la arquitectura lógica y física y determine una estrategia de identidad híbrida.
Asigne directivas de administración de acceso de las identidades como, por ejemplo, asignaciones de id. de
inicio de sesión, y elija el método de autenticación adecuado para Azure AD.
Si es federado, habilite restricciones de inquilino para las cuentas administrativas.
Integre los directorios locales y en la nube.
Considere el uso de los siguientes modelos de acceso:
Modelo de acceso administrativo con privilegios mínimos.
Modelo de acceso Privileged Identity Management.
Complete todos los detalles previos a la integración y repase los procedimientos recomendados de
seguridad con control de acceso y administración de identidades.
Habilite el inicio de sesión único (SSO) de identidad única, también denominado SSO de conexión
directa.
Configure la autenticación multifactor para los administradores
Consolide o integre los proveedores de identidades, cuando sea necesario.
Implemente las herramientas necesarias para centralizar la administración de identidades.
Habilite el acceso Just-In-Time (JIT) y las alertas de cambio de rol.
Realice un análisis de riesgos de las actividades de administración principales para la asignación a
roles integrados.
Considere la posibilidad de realizar un lanzamiento actualizado de una autenticación más segura para
todos los usuarios.
Habilite Privileged Identity Management (PIM) para JIT (mediante una activación limitada en el
tiempo) para los roles administrativos adicionales.
Separe las cuentas de usuarios de las cuentas de administrador global, para asegurarse de que los
administradores no abren de forma involuntaria correos electrónicos ni ejecutan programas
asociados a sus cuentas de administrador global.
Migre la cadena de herramientas de la base de referencia de identidad desde el entorno de desarrollo al de
producción.
Compruebe que los procedimientos recomendados que se definieron durante las fases anteriores a la
implementación de la compilación se ejecutan correctamente.
Compruebe y refine la estrategia de identidad híbrida.
Cerciórese de que todas las aplicaciones o cargas de trabajo siguen alineadas con la estrategia de identidad
antes de la publicación.
Compruebe que el inicio de sesión único (SSO) y el SSO de conexión directa funcionan según lo previsto en
las aplicaciones.
Reduzca el número de almacenes de identidades alternativos o elimine algunos de ellos.
Examine la necesidad de almacenes de identidades en aplicaciones o en bases de datos. Las identidades que
se encuentran fuera de un proveedor de identidades adecuado (propias o de terceros) pueden suponer un
riesgo para la aplicación y para los usuarios.
Habilite el acceso condicional para las aplicaciones federadas locales.
Distribuya la identidad entre las regiones globales en varios centros con sincronización entre regiones.
Establezca la federación central del control de acceso basado en rol de Azure (RBAC de Azure).

Personalice la cadena de herramientas de la base de referencia de identidad según las necesidades
cambiantes de la organización.
Automatice notificaciones e informes para que le avisen de posibles amenazas malintencionadas.
Supervise e informe sobre el uso del sistema y el progreso del proceso de adopción por parte del usuario.
Informe sobre las métricas posteriores a la implementación y distribúyalas a las partes interesadas.
Refine las directrices de arquitectura para guiar los procesos de adopción futuros.
Comunique y eduque constantemente a los equipos implicados de forma periódica para garantizar el
cumplimiento continuo de las directrices de arquitectura.
Realice auditorías periódicas de las directivas de identidad y de los procedimientos de cumplimiento.
Asegúrese de que las cuentas de usuario confidenciales (las de los directores ejecutivos de la empresa) estén
siempre habilitadas para la autenticación multifactor y la detección de inicios de sesión anómalos.
Examine en busca de actores malintencionados y vulneraciones de seguridad de los datos de forma
periódica, especialmente aquellas relacionadas con los fraudes de identidad como, por ejemplo, posibles
apropiaciones de cuentas de administrador.
Configure una herramienta de supervisión e informes.
Considere la posibilidad de una integración más estrecha con los sistemas de seguridad y prevención de
fraudes.
Revise con regularidad los derechos de acceso para los usuarios o roles con privilegios elevados.
Identifique a todos aquellos usuarios que sean aptos para activar sus privilegios administrativos.
Revise los procesos de incorporación, baja y actualización de credenciales.
Investigue la posibilidad de aumentar los niveles de automatización y comunicación entre los módulos de
administración de identidad y acceso (IAM).
Considere la posibilidad de implementar un enfoque de desarrollo, seguridad y operaciones (DevSecOps).
Realice un análisis de impacto para medir los resultados de costos, seguridad y adopción por parte del
usuario.
Genere periódicamente un informe de impacto que muestre los cambios en las métricas que crea el sistema
y haga una estimación del impacto empresarial de la estrategia de identidad híbrida.
Establezca la supervisión integrada que recomienda Azure Security Center.
Pasos siguientes
Ahora que conoce el concepto de gobernanza de identidades en la nube, examine la cadena de herramientas de
la base de referencia de identidad para identificar las herramientas y características de Azure que necesitará al
desarrollar la materia de la base de referencia de la identidad en la plataforma Azure.
Cadena de herramientas de la línea de base de identidad para Azure
Herramientas de la base de referencia de identidad
en Azure
La materia de base de referencia de identidad es una de las cinco materias de gobernanza de la nube. Esta
materia se centra en las maneras de establecer directivas que garanticen la coherencia y continuidad de las
identidades de usuario, independientemente del proveedor de servicios en la nube que hospede la aplicación o
carga de trabajo.
Las siguientes herramientas se incluyen en la guía de detección de la identidad híbrida.
Active Director y (local): Active Directory es el proveedor de identidades que más se usa en la empresa para
almacenar y validar credenciales de usuario.
Azure Active Director y: un equivalente de software como servicio (SaaS) a Active Directory, capaz de
federarse con una instancia local de Active Directory.
Active Director y (IaaS): una instancia de la aplicación de Active Directory que se ejecuta en una máquina
virtual de Azure.
Identidad es el plano de control de la seguridad de TI. Por consiguiente, la autenticación es la forma de proteger
el acceso de una organización a la nube. Las organizaciones necesitan un plano de control de identidad que
refuerce su seguridad y mantenga las aplicaciones en la nube protegidas frente a intrusos.
Autenticación en la nube
Elegir el método de autenticación correcto es la primera preocupación para las organizaciones que desean
mover sus aplicaciones a la nube.
Cuando se elige este método, Azure AD controla el proceso de inicio de sesión de los usuarios. Junto con el
inicio de sesión único (SSO) de conexión directa, los usuarios podrán iniciar sesión en las aplicaciones en la
nube sin volver a especificar sus credenciales. Con la autenticación en la nube puede elegir entre dos opciones:
Sincronización de hash de contraseñas de Azure AD: Es la manera más sencilla de habilitar la
autenticación para los objetos de directorio local en Azure AD. Este método también se puede usar utiliza con
cualquier otro como método de autenticación de la conmutación por error de copia de seguridad, en caso de
que el servidor local deje de funcionar.
Autenticación de paso a través de Azure AD: proporciona una validación de contraseñas persistente para
los servicios de autenticación de Azure AD mediante un agente de software que se ejecuta en uno o varios
servidores locales.
NOTE
Las empresas con un requisito de seguridad para aplicar de inmediato los estados de cuenta de los usuarios locales, las
directivas de contraseña y las horas de inicio de sesión deberían considerar la posibilidad de usar el método de
autenticación de paso a través.
Autenticación federada:
si se elige este método, Azure AD pasa el proceso de autenticación a un sistema de autenticación de confianza
como, por ejemplo, una instancia local de Servicios de federación de Active Directory (AD FS) o un proveedor de
federación independiente de confianza para validar la contraseña del usuario.
El artículo Seleccione el método de autenticación adecuado para su solución de identidad híbrida de Azure
Active Directory contiene un árbol de decisión que le ayuda a elegir la mejor solución para su organización.
En la tabla siguiente se enumeran las herramientas nativas que pueden ayudar a desarrollar las directivas y los
procesos que admiten esta materia.
SIN C RO N IZ A C IÓ N DE H A SH A UT EN T IC A C IÓ N DE PA SO
DE C O N T RA SEÑ A S + SSO A T RAVÉS + SSO DE
C O N SIDERA C IÓ N DE C O N EXIÓ N DIREC TA C O N EXIÓ N DIREC TA F EDERA C IÓ N C O N A D F S
¿Dónde se realiza la En la nube En la nube, después de un Local

autenticación? intercambio de
comprobación de
contraseña segura con el
agente de autenticación
local
¿Cuáles son los requisitos None Un servidor para cada Dos o más servidores de
de servidor local más allá agente de autenticación AD FS
del sistema de adicional
aprovisionamiento (Azure Dos o más servidores WAP
AD Connect)? en la red perimetral
¿Cuáles son los requisitos None Acceso saliente a Internet Acceso entrante a Internet
de redes e Internet locales desde los servidores que para los servidores WAP del
más allá del sistema de ejecutan los agentes de perímetro
aprovisionamiento? autenticación
Acceso entrante de red para
los servidores de AD FS
desde los servidores WAP
del perímetro
Equilibrio de carga de red
¿Hay algún requisito de No No Sí

certificado SSL?
¿Hay alguna solución de No se requiere El estado del agente lo Azure AD Connect Health
supervisión de estado? proporciona el Centro de
administración de Azure
Active Directory
¿Los usuarios realizan el Sí, con SSO de conexión Sí, con SSO de conexión Sí
inicio de sesión único en los directa directa
recursos de nube desde
dispositivos unidos a un
dominio de la red de la
empresa?
¿Qué tipos de inicio de UserPrincipalName + UserPrincipalName + UserPrincipalName +

sesión se admiten? contraseña contraseña contraseña
Autenticación de Windows Autenticación de Windows SamAccountName +

integrada con SSO de integrada con SSO de contraseña
conexión directa conexión directa
Autenticación integrada de
Identificador de inicio de Identificador de inicio de Windows
sesión alternativo sesión alternativo
Autenticación de
certificados y tarjetas
inteligentes
Identificador de inicio de
sesión alternativo
¿Se admite Windows Hello Modelo de confianza de Modelo de confianza de Modelo de confianza de
para empresas? clave clave clave
Modelo de confianza de Modelo de confianza de Modelo de confianza de

certificado con Intune certificado con Intune certificado
¿Cuáles son las opciones de Azure Multi-Factor Azure Multi-Factor Azure Multi-Factor
autenticación multifactor? Authentication Authentication Authentication
Controles personalizados Controles personalizados Servidor de Azure Multi-

con el acceso condicional de con el acceso condicional de Factor Authentication
Azure AD* Azure AD*
Autenticación multifactor de
terceros
Controles personalizados
con el acceso de Azure AD
¿Qué estados de cuenta de Cuentas deshabilitadas Cuentas deshabilitadas Cuentas deshabilitadas

usuario se admiten? (Retraso de hasta
30 minutos) Cuenta bloqueada Cuenta bloqueada
Cuenta expirada Cuenta expirada
Contraseña expirada Contraseña expirada
Horas de inicio de sesión Horas de inicio de sesión
¿Cuáles son las opciones de Acceso condicional de Azure Acceso condicional de Azure Acceso condicional de Azure
acceso condicional de AD AD AD
Azure AD?
Reglas de notificaciones de
AD FS
¿Se admite el bloqueo de Sí Sí Sí

protocolos heredados?
¿Se puede personalizar el Sí, con Azure AD Premium Sí, con Azure AD Premium Sí
logotipo, la imagen y la
descripción en las páginas
de inicio de sesión?
¿Qué escenarios avanzados Smart Password Lockout Smart Password Lockout Sistema de autenticación
se admiten? (Bloqueo inteligente de (Bloqueo inteligente de multisitio de baja latencia
contraseñas) contraseñas)
Bloqueo de extranet de AD
Informes de credenciales FS
filtradas
Integración con sistemas de
identidad de terceros
NOTE
Actualmente, los controles personalizados del acceso condicional de Azure AD no admiten el registro de dispositivos.
Pasos siguientes
Notas del producto del marco de transformación digital de la identidad híbrida describe diversas combinaciones
y soluciones para elegir e integrar estos componentes.
La herramienta Azure AD Connect le permite integrar sus directorios locales con Azure AD.
Introducción a la materia de coherencia de recursos
La coherencia de recursos es una de las cinco materias de la gobernanza de la nube dentro del modelo de
gobernanza de Cloud Adoption Framework. Esta materia se centra en las distintas formas de establecer
directivas relacionadas con la administración operativa de un entorno, una aplicación o una carga de trabajo.
Los equipos de operaciones de TI suelen proporcionar supervisión de las aplicaciones, de la carga de trabajo y
del rendimiento de los recursos. También suelen ejecutar las tareas necesarias para satisfacer las demandas de
ampliación y corregir las infracciones del Acuerdo de Nivel de Servicio (SLA) de rendimiento y evitarlas de
forma proactiva mediante la corrección automatizada. Dentro de las cinco materias de gobernanza de la nube, la
coherencia de recursos es una materia que garantiza la configuración coherente de los recursos de forma que
las operaciones de TI puedan detectarlos, su inclusión en soluciones de recuperación y su incorporación en
procesos de operaciones reiterativas.
NOTE
La materia de coherencia de recursos no viene a reemplazar a los procedimientos, procesos y equipos de TI existentes que
permiten a su organización administrar eficazmente los recursos basados en la nube. El principal objetivo de esta materia
es identificar posibles riesgos empresariales y proporcionar orientación en mitigación de riesgos al personal de TI
responsable de la administración de sus recursos en la nube. A medida que desarrolla procesos y directivas de
gobernanza, asegúrese de implicar a los equipos de TI pertinentes en sus procesos de revisión y planeación.
En esta sección de Cloud Adoption Framework se describe cómo desarrollar una materia de coherencia de
recursos como parte de la estrategia de gobernanza en la nube. La principal audiencia a la que se dirigen estas
instrucciones son los arquitectos de nube de su organización y otros miembros de su equipo de gobernanza en
la nube. Las decisiones, las directivas y los procesos que emergen de esta materia deben incluir la involucración
y los debates con miembros pertinentes de los equipos de TI responsables de implementar y administrar las
soluciones de coherencia de recursos de su organización.
Si su organización carece de conocimientos internos sobre estrategias de coherencia de recursos, considere la
posibilidad de interaccionar con consultores externos como parte de esta materia. Considere también la
posibilidad de involucrar a Servicios de consultoría de Microsoft, el servicio de adopción de la nube Microsoft
FastTrack u otros expertos en adopción de la nube externos para determinar la mejor forma de organizar,
optimizar y realizar un seguimiento de sus recursos basados en la nube.
Policy statements
materia de coherencia de recursos. Use declaraciones de directivas de ejemplo. Estos ejemplos pueden servir
como punto de partida para definir las directivas de coherencia de recursos.
Cau t i on

materia de coherencia de recursos. Use cada paso como punto de partida para las conversaciones dentro del
equipo de gobernanza de la nube y con los equipos de TI y empresariales afectados de toda la organización a fin
de establecer las directivas y procesos necesarios para administrar los riesgos de la materia de coherencia de
recursos.
Plantilla de la materia de coherencia de recursos: Descargue

la plantilla para documentar una materia de coherencia de
recursos.

asociados normalmente a la materia de coherencia de
recursos.

coherencia de recursos.

coherencia de recursos.


implementar para admitir la materia de coherencia de
recursos.
Pasos siguientes
Plantilla de la materia de coherencia de recursos
El primer paso para implementar un cambio es comunicar lo que se pretende. Lo mismo sucede cuando se
cambian los procedimientos de gobernanza. La plantilla siguiente proporciona un punto de partida para
documentar y comunicar las declaraciones de directiva que rigen la administración y las operaciones de TI en la
nube.
para definir las declaraciones de las directivas de coherencia de los recursos de la organización.
IMPORTANT
Esta plantilla es un ejemplo limitado. Antes de actualizar la plantilla para que incluya sus requisitos, debe revisar los pasos
posteriores para definir una materia sobre la coherencia de los recursos eficaz dentro de su estrategia de gobernanza de la
nube.
Descarga de la plantilla de la materia de coherencia de recursos
Pasos siguientes
de la nube actual.
de coherencia de los recursos
En este artículo se describen las razones por las que los clientes normalmente adoptan una materia de
coherencia de recursos dentro de una estrategia de gobernanza en la nube. También se proporcionan algunos
ejemplos de posibles riesgos empresariales que pueden motivar las declaraciones de directiva.
Relevancia
Cuando se trata de implementar recursos y cargas de trabajo, la nube ofrece una mayor agilidad y flexibilidad
con respecto a la mayoría de los centros de datos locales tradicionales. Estas posibles ventajas basadas en la
nube también implican posibles inconvenientes de administración que pueden poner en grave peligro el éxito
de su adopción de la nube. ¿Qué recursos ha implementado? ¿Qué equipos poseen qué recursos? ¿Tiene
suficientes recursos para admitir una carga de trabajo? ¿Cómo sabe si las cargas de trabajo están funcionando
correctamente?
La coherencia de los recursos es crucial para garantizar que los recursos se implementen, actualicen y
configuren de manera coherente y repetitiva, y que las interrupciones del servicio se minimicen y solucionen en
el menor tiempo posible.
La materia de coherencia de recursos se ocupa de identificar y mitigar los riesgos empresariales relacionados
con los aspectos operativos de su implementación en la nube. La coherencia de los recursos incluye la
supervisión de aplicaciones, cargas de trabajo y rendimiento de los recursos. También incluye las tareas
necesarias para satisfacer las demandas de escalado, proporcionar funcionalidades de recuperación ante
desastres, corregir las infracciones del Acuerdo de Nivel de Servicio (SLA) de rendimiento y evitar de forma
activa las infracciones del SLA de rendimiento mediante una corrección automatizada.
Es posible que las implementaciones iniciales de prueba no requieran mucho más que la adopción de algunos
estándares de nomenclatura y etiquetado para satisfacer sus necesidades de coherencia de recursos. A medida
que su adopción de la nube madure e implemente recursos más complicados y críticos, la necesidad de invertir
en la materia de coherencia de recursos aumentará rápidamente.
Riesgo empresarial
La materia de coherencia de recursos intenta abordar los principales riesgos empresariales operativos. Trabaje
con su empresa y los equipos de TI para identificar estos riesgos y supervise cada uno de ellos para determinar
su pertinencia a medida que planifique e implemente sus implementaciones en la nube.
Los riesgos variarán según la organización, pero los siguientes sirven como riesgos comunes que puede usar
como punto de partida para debatir en el seno de su equipo de gobernanza de la nube:
Costos operativos innecesarios. Los recursos obsoletos o no utilizados, o los recursos que se
sobreaprovisionan en épocas de baja demanda, agregan costos operativos innecesarios.
Recursos infraaprovisionados. Los recursos que experimentan una demanda mayor a la prevista pueden
dar lugar a una interrupción del negocio, ya que los recursos de la nube se ven desbordados por la demanda.
Ineficiencias de administración. La falta de metadatos de nomenclatura y etiquetado coherentes
asociados con los recursos puede hacer que el personal de TI tenga dificultades para encontrar recursos para
las tareas de administración o para determinar la propiedad y la información de cuentas relacionada con los
recursos. Esto se traduce en ineficiencias de administración que pueden aumentar los costos y retardar la
capacidad de respuesta de la TI ante la interrupción del servicio u otros problemas operativos.
Interrupción del negocio. Las interrupciones del servicio que resultan en infracciones de los Acuerdos de
Nivel de Servicio (SLA) establecidos por su organización pueden dar lugar a la pérdida de negocios o a
repercusiones financieras negativas para la empresa.
Pasos siguientes
Use la plantilla de la materia de coherencia de los recursos para documentar los riesgos empresariales que es
probable que se introduzcan debido al plan actual de adopción de la nube.
tolerancia.
Indicadores y métricas de tolerancia al riesgo en la
materia de coherencia de recursos
Aprenda a cuantificar la tolerancia al riesgo empresarial asociada a la materia de coherencia de recursos. La

definición de métricas e indicadores ayuda a crear un caso empresarial para invertir en la madurez de esta
materia.
Métricas
La coherencia de recursos se centra en abordar los riesgos relacionados con la administración operativa de las
implementaciones en la nube. Como parte del análisis de riesgos, querrá recopilar datos relativos a las
operaciones de TI para determinar el riesgo al que se enfrenta, y la importancia que la inversión en la materia de
coherencia de recursos tiene en sus planes de implementación en la nube.
Cada organización tiene diferentes escenarios operativos, pero los elementos siguientes son ejemplos útiles de
las métricas que debe recopilar a la hora de evaluar la tolerancia a los riesgos en materia sobre la coherencia de
los recursos:
Recursos en la nube. Número total de recursos implementados en la nube.
Recursos sin etiquetar. Número de recursos sin las etiquetas necesarias de propiedad, impacto
empresarial u organizativas.
Recursos infrautilizados. Número de recursos cuyas capacidades de red, CPU o memoria se infrautilizan
de forma constante.
Agotamiento de los recursos. Número de recursos en los que la carga agota las capacidades de red, CPU
o memoria.
Antigüedad de los recursos. Tiempo transcurrido desde que el recurso se implementó o se modificó por
última vez.
Máquinas vir tuales en condición crítica. Número de VM implementadas en las que se han detectado
uno o varios problemas críticos que deben solucionarse para restaurar la funcionalidad normal.
Aler tas por gravedad. Número total de alertas en un recurso implementado, desglosado por gravedad.
Vínculos de red incorrectos. Número de recursos con problemas de conectividad de red.
Puntos de conexión de ser vicio incorrectos. Número de problemas con los puntos de conexión de red
externos.
Incidencias de estado de mantenimiento del ser vicio del proveedor de nube. Número de
interrupciones o incidencias de rendimiento causados por el proveedor de servicios en la nube.
Acuerdos de Nivel de Ser vicio. Pueden incluir tanto los compromisos de Microsoft correspondientes al
tiempo de actividad y conectividad de los servicios de Azure como los compromisos adquiridos por la
empresa con sus clientes externos e internos.
Disponibilidad del ser vicio. Porcentaje del tiempo de actividad real de las cargas de trabajo hospedadas
en la nube en comparación con el tiempo de actividad esperado.
Objetivo de tiempo de recuperación (RTO). El tiempo máximo aceptable que una aplicación puede estar
no disponible después de un incidente.
Objetivo de punto de recuperación (RPO). La duración máxima de pérdida de datos que es aceptable
durante un desastre. Por ejemplo, si se almacenan datos en una única base de datos, sin replicación en otras
bases de datos y se realizan copias de seguridad por hora, se podría perder hasta una hora de datos.
Promedio de tiempo de recuperación (MTTR). El tiempo promedio necesario para restaurar un
componente después de un error.
Promedio de tiempo entre errores (MTBF). La duración razonable que se puede suponer que un
componente se ejecutará entre interrupciones. Esta métrica puede ayudarle a calcular la frecuencia con la
que un servicio dejará de estar disponible.
Estado de mantenimiento de las copias de seguridad. Número de copias de seguridad que se están
sincronizando activamente.
Estado de mantenimiento de la recuperación. Número de operaciones de recuperación realizadas
correctamente.

Las plataformas de nube ofrecen un conjunto básico de características que permiten a los equipos de
implementación administrar de forma eficaz pequeñas implementaciones sin necesidad de extensos
planeamientos o procesos adicionales. Como resultado, las primeras cargas de trabajo experimentales o de
desarrollo/pruebas que incluyan una pequeña cantidad de recursos basados en la nube representan un nivel de
riesgo bajo y, probablemente, no necesitarán mucho una directiva de coherencia de recursos formal.
A medida que crezca el tamaño de su patrimonio en la nube, la administración de los recursos se volverá más
compleja. Al haber más recursos en la nube, es fundamental poder identificar quién es el propietario y controlar
los recursos de forma útil. A medida que se implementan en la nube más cargas de trabajo críticas para la
misión, el tiempo de actividad del servicio pasa a ser más importante y tolerancia a los posibles sobrecostos
producidos por interrupciones del servicio disminuye rápidamente.
de la empresa para identificar los riesgos empresariales relativos a la coherencia de recursos y, después,
determine una base de referencia aceptable para la tolerancia al riesgo. En esta sección de Cloud Adoption
Framework se proporcionan ejemplos, pero los riesgos y las bases de referencia específicos de su empresa o
sus implementaciones pueden ser diferentes.
operativas, como las descritas anteriormente, pueden justificar una mayor inversión en la materia sobre la
coherencia de los recursos.
Desencadenador de etiquetado y nomenclatura. Una empresa con más de x recursos que carecen de la
información necesaria de etiquetado o que no cumplen los estándares de nomenclatura debe plantearse
invertir en la materia de coherencia de los recursos para ayudar a pulir estos estándares y garantizar su
aplicación coherente a los recursos implementados en la nube.
Desencadenador de recursos sobreaprovisionados. Si una empresa tiene más de un x % de recursos
que usan regularmente pequeñas cantidades de sus capacidades disponibles de memoria, CPU o red, se
recomienda invertir en la materia de coherencia de los recursos para ayudar a optimizar el uso que hacen de
estos elementos.
Desencadenador de recursos infraaprovisionados. Si una empresa tiene más de un x % de recursos
que agotan regularmente la mayor parte de sus capacidades disponibles de memoria, CPU o red, se
recomienda invertir en la materia de coherencia de los recursos para ayudar a garantizar que estos recursos
tengan la capacidad necesaria para evitar interrupciones del servicio.
Desencadenador de antigüedad de los recursos. Una empresa con más de x recursos que no se han
actualizado en más de y meses podría beneficiarse de la inversión en la materia de coherencia de recursos,
cuyo objetivo es asegurarse de que los recursos activos estén revisados y en buen estado, y de que se retiren
los recursos obsoletos o que no se usen.
Desencadenador de contrato de nivel de ser vicio. Una empresa que no puede cumplir sus contratos
de nivel de servicio con sus clientes externos o asociados internos debe invertir en la disciplina de
aceleración de la implementación para reducir el tiempo de inactividad del sistema.
Desencadenadores de tiempo de recuperación. Si una compañía supera los umbrales necesarios para
el tiempo de recuperación tras un error del sistema, debe invertir en la mejora de la disciplina de aceleración
de la implementación y el diseño de sistemas para reducir o eliminar los errores o el efecto del tiempo de
inactividad de un componente individual.
Desencadenador de estado de mantenimiento de las máquinas vir tuales. Una empresa que tenga
más de un x % de máquinas virtuales con problemas de estado de mantenimiento críticos debe invertir en la
materia de coherencia de los recursos para identificar los problemas y mejorar la estabilidad de las máquinas
virtuales.
Desencadenador de estado de mantenimiento de las redes. Una empresa que tiene más de un x % de
subredes o puntos de conexión con problemas de conectividad debe invertir en la materia de coherencia de
los recursos para identificar y resolver los problemas de red.
Desencadenador de cober tura de las copias de seguridad. Una empresa con un x % de los recursos
críticos sin copias de seguridad actualizadas se beneficiaría de una mayor inversión en la materia de
coherencia de los recursos para garantizar una estrategia de copia de seguridad coherente.
Desencadenador de estado de mantenimiento de las copias de seguridad. Una empresa con más
de un x % de errores en las operaciones de restauración debe invertir en la materia de coherencia de los
recursos para identificar los problemas de copia de seguridad y garantizar que los recursos importantes
estén protegidos.
Las métricas y los desencadenadores exactos que use para medir la tolerancia al riesgo y el nivel de inversión en
la materia de coherencia de los recursos son específicos para su organización, pero los ejemplos anteriores
sirven como base para las conversaciones con el equipo de gobernanza de la nube.
Pasos siguientes
Use la plantilla de la materia de coherencia de recursos para documentar las métricas y los indicadores de
tolerancia que se alinean con el plan actual de adopción de la nube.
Revise las directivas de coherencia de recursos de muestra como punto de partida para desarrollar otras suyas
que aborden los riesgos empresariales específicos vinculados a los planes de adopción de la nube.
Instrucciones de directiva de ejemplo de coherencia
de recursos
Las siguientes declaraciones de directiva de ejemplo abordan riesgos empresariales comunes relacionados con
la coherencia de recursos. Estas declaraciones son ejemplos a los que se puede hacer referencia al elaborar el
borrador de las declaraciones de directiva para satisfacer las necesidades de su organización. Estos ejemplos no
pretenden ser excluyentes y hay varias opciones posibles de directiva para solucionar cada riesgo concreto
Etiquetado
Riesgo técnico: sin el etiquetado correcto de metadatos asociado con los recursos implementados, las
operaciones de TI no pueden dar prioridad al soporte técnico o la optimización de recursos en función del
Acuerdo de Nivel de Servicio necesario, la importancia de las operaciones empresariales o los costos operativos.
Esto puede provocar una asignación errónea de recursos de TI y posibles retrasos en la resolución de incidentes.
Los recursos implementados se deben etiquetar con los valores siguientes:
Coste
Entorno
Las herramientas de gobernanza deben validar el etiquetado relacionado con el costo, la importancia, el SLA,
la aplicación y el entorno. Todos los valores deben alinearse con valores predefinidos, administrados por el
equipo de gobernanza.
Opciones de diseño posibles: En Azure, se admiten las etiquetas de metadatos estándar de nombre y valor
en la mayoría de los tipos de recursos. Azure Policy se usa para exigir etiquetas específicas como parte de la
creación de recursos.
Suscripciones sin gobierno

Riesgo técnico: La creación arbitraria de suscripciones y grupos de administración puede dar lugar a secciones
aisladas del entorno de nube que no estén correctamente sujetas a las directivas de gobernanza.
Declaración de directiva : La creación de suscripciones o grupos de administración para las aplicaciones
críticas o datos protegidos requerirá una revisión del equipo de gobernanza en la nube. Los cambios aprobados
se integrarán en una asignación de plano técnico adecuada.
Opciones de diseño posibles: Bloquear el acceso administrativo a los grupos de administración de Azure de
la organización y solo permitirlo a los miembros aprobados del equipo de gobernanza que controlarán la
creación de suscripciones y el proceso de control de acceso.
Administrar las actualizaciones de las máquinas virtuales

Riesgo técnico: Las máquinas virtuales (VM) que no estén actualizadas con las actualizaciones y revisiones de
software más recientes son vulnerables a problemas de seguridad o rendimiento, que pueden dar lugar a
interrupciones del servicio.
Declaración de directiva : Las herramientas de gobernanza deben exigir que las actualizaciones automáticas
estén habilitadas en todas las máquinas virtuales implementadas. Las infracciones deben revisarse con los
equipos de administración de operaciones y corregirse de acuerdo con las directivas de operaciones. Los
recursos que no se actualicen automáticamente deben incluirse en procesos que sean propiedad de operaciones
de TI.
Opciones de diseño posibles: Para las máquinas virtuales hospedadas en Azure, puede proporcionar la
administración de actualizaciones coherentes mediante la solución Update Management en Azure Automation.
Cumplimiento de la implementación
Riesgo técnico: Los scripts y las herramientas de automatización de la implementación que el equipo de
gobernanza en la nube no haya aprobado completamente pueden dar lugar a implementaciones de recursos
que infrinjan la directiva.
El equipo de gobernanza de la nube debe aprobar las herramientas de implementación para garantizar la
Los scripts de implementación deben conservarse en un repositorio central accesible para el equipo de
gobernanza de la nube para su revisión y auditoría periódicas.
Opciones de diseño posibles: Un uso coherente de Azure Blueprints para administrar implementaciones
automatizadas permite implementaciones coherentes de los recursos de Azure que cumplan con los estándares
de gobernanza y las directivas de la organización.
Supervisión
Riesgo técnico: Si la supervisión se implementa incorrectamente o se instrumenta de forma incoherente
puede impedir la detección de problemas de mantenimiento de la carga de trabajo u otras infracciones de
cumplimiento de directivas.
Las herramientas de gobernanza deben validar que todos los recursos se incluyen en la supervisión de la
disminución, seguridad, cumplimiento y optimización de los recursos.
Las herramientas de gobernanza deben validar que se recopila el nivel adecuado de datos de registro para
todas las aplicaciones y datos.
Opciones de diseño posibles: Azure Monitor es el servicio de supervisión predeterminado de Azure y puede
aplicarse supervisión coherente a través de Azure Blueprints al implementar recursos.

Riesgo técnico: Los errores, las eliminaciones o los daños de los recursos pueden producir una interrupción de
las aplicaciones críticas o de los servicios y la pérdida de datos confidenciales.
Declaración de directiva : Todas las aplicaciones críticas y los datos protegidos deben tener implementadas
soluciones de copia de seguridad y recuperación para minimizar el impacto en el negocio de las interrupciones
o errores del sistema.
Opciones de diseño posibles: El servicio Azure Site Recovery proporciona funcionalidades de copia de
seguridad, recuperación y replicación que minimizan la duración de la interrupción en escenarios de
recuperación ante desastres y continuidad del negocio (BCDR).
Pasos siguientes
Para comenzar a desarrollar sus propias instrucciones de directivas personalizadas de coherencia de recursos,
descargue la plantilla de la materia de coherencia de recursos.
directiva de coherencia de los recursos.
Procesos de cumplimiento de directivas de
coherencia de recursos
En este artículo se describe un enfoque de los procesos de cumplimiento de directivas que rigen la directiva de
la coherencia de recursos. Una gobernanza eficaz de la coherencia de recursos en la nube comienza con
procesos manuales periódicos diseñados para identificar la falta de eficiencia operativa, mejorar la
administración de los recursos implementados y garantizar que las cargas de trabajo críticas tengan
interrupciones mínimas. Estos procesos manuales se complementan con supervisión, automatización y
herramientas para ayudar a reducir la sobrecarga de gobernanza y permitir una respuesta más rápida ante una
desviación de la directiva.

Las plataformas en la nube proporcionan una matriz de características y herramientas de administración que se
pueden utilizar para organizar, aprovisionar, escalar y minimizar el tiempo de inactividad. El uso de estas
herramientas para estructurar y administrar de forma eficaz las implementaciones en la nube de formas que
corrijan los riesgos potenciales requiere directivas y procesos bien meditados, además de una cooperación
estrecha con los equipos de operaciones de TI y las partes interesadas del negocio.
A continuación, se presenta un conjunto de procesos de ejemplo que normalmente están implicados en la
materia de la coherencia de recursos. Use estos ejemplos como punto de partida al planear los procesos que le
permitirán continuar actualizando la directiva de coherencia de recursos en función de los cambios que se
produzcan en la empresa y los comentarios de los equipos de seguridad y TI cuya tarea es poner en práctica las
instrucciones.
Planeamiento y evaluación inicial de los riesgos: como parte de su adopción inicial de la materia de
coherencia de recursos, identifique sus principales riesgos empresariales y tolerancias relacionadas con las
operaciones y la administración de TI. Esta información se usa para hablar de riesgos técnicos concretos con los
miembros de los equipos de TI y los propietarios de cargas de trabajo a fin de desarrollar un conjunto de
referencia de directivas de coherencia de recursos diseñado para corregir dichos riesgos, con el establecimiento
de la estrategia de gobernanza inicial.
Planeación de la implementación: antes de implementar cualquier recurso, realice una revisión para
identificar los nuevos riesgos operativos. Establezca requisitos de recursos y los patrones de demanda esperada
e identifique las necesidades de escalabilidad y posibles oportunidades de optimización del uso. Asegúrese
también de que existan planes de copia de seguridad y recuperación.
Pruebas de la implementación: como parte de la implementación, el equipo de gobernanza de la nube, en
colaboración con los equipos de operaciones en la nube, se encarga de revisar la implementación a fin de
validar el cumplimiento de las directivas de coherencia de recursos.
Planeación anual: realice todos los años una revisión de alto nivel de la estrategia de coherencia de recursos.
Explore las prioridades o los planes de expansión corporativa futuros y actualice las estrategias de adopción de
la nube para identificar un posible aumento del riesgo u otras necesidades emergentes relativas a la coherencia
de los recursos. Use también este tiempo para revisar los procedimientos recomendados de coherencia de los
recursos en la nube más recientes e integrarlos en sus directivas y procesos de revisión.
Planeamiento y revisión trimestrales: realice una revisión trimestral de los datos operativos y los informes
de incidentes, con el fin de identificar los cambios necesarios en la directiva de coherencia de recursos. Como
parte de este proceso, revise los cambios de rendimiento y uso de recursos para identificar los recursos que
requieren aumentar o reducir la asignación de recursos y, además, identifique todas las cargas de trabajo o los
recursos que se pueden retirar.
de gobernanza de la nube, por si hay lagunas de conocimientos relacionadas con las directivas nuevas o
cambiantes y con los riesgos relacionados con la materia de coherencia de los recursos. Invite al personal de TI
pertinente a participar en las revisiones y el planeamiento como asesores técnicos temporales o miembros
permanentes del equipo.
Educación y aprendizaje: ofrezca sesiones de aprendizaje con carácter bimensual para asegurarse de que los
desarrolladores y el personal de TI están al tanto de las instrucciones y los requisitos más recientes de las
directivas de coherencia de recursos. Como parte de este proceso, revise y actualice cualquier documentación u
otros recursos de aprendizaje para asegurarse de que estén sincronizados con las declaraciones de directiva
corporativa más recientes.
de la nube para garantizar su alineación continuada con la directiva de coherencia de recursos. Revise las
actividades relacionadas con el personal de TI e identifique los problemas de cumplimiento que aún no se han
abordado como parte del proceso continuo de supervisión y cumplimiento. El resultado de esta revisión es un
informe para el equipo de estrategia de la nube y cada equipo de adopción de la nube para comunicar la
adhesión general a la directiva y su cumplimiento. El informe también se almacena con fines de auditoría y
legales.

Una la estrategia de coherencia de los recursos correcta depende de la visibilidad del estado actual y pasado de
la infraestructura en la nube. Sin la capacidad para analizar las métricas pertinentes y los datos del estado y la
actividad del entorno en la nube, no se pueden identificar cambios en los riesgos o detectar infracciones de las
tolerancias al riesgo. Los procesos de gobernanza mencionados anteriormente requieren datos de calidad para
garantizar que la directiva se pueda modificar a fin de optimizar el uso de los recursos en la nube y mejorar el
rendimiento general de las cargas de trabajo hospedadas en la nube.
Asegúrese de que los equipos de TI han implementado sistemas de supervisión automatizados para la
infraestructura en la nube que capturen los datos pertinentes de los registros que necesita para evaluar los
riesgos. Sea proactivo en la supervisión de estos sistemas para asegurar la pronta detección y mitigación de
posibles infracciones de la directiva y que su estrategia de supervisión esté en línea con las necesidades
operativas.

Como el cumplimiento de las directivas de coherencia de recursos puede provocar interrupciones de servicio
críticas o riesgos importantes de sobrecostos, el equipo de gobernanza de la nube debe tener visibilidad sobre
los incidentes de incumplimiento. Asegúrese de que el personal de TI tiene rutas de escalado claras para
notificar estos problemas a los miembros del equipo de gobernanza más adecuados para identificar y
comprobar que se han corregido los problemas de directivas cuando se han detectado.
El equipo de TI puede automatizar la mayoría de los desencadenadores de infracción con las herramientas
descritas en Resource Consistency toolchain for Azure (Cadena de herramientas de coherencia de recursos para
Azure).
Recurso sobreaprovisionado detectado. cuando se detectan recursos que utilizan menos del 60 % de
CPU o de capacidad de memoria, estos se deben reducir verticalmente o desaprovisionar automáticamente
para reducir costos.
Recurso infraaprovisionado detectado. cuando se detectan recursos que utilizan más del 80 % de CPU o
de capacidad de memoria, es necesario escalar verticalmente o aprovisionar automáticamente recursos
adicionales para proporcionar más capacidad.
Creación de recursos sin etiquetas. todas las solicitudes para crear un recurso sin las etiquetas META
necesarias se rechazarán automáticamente.
Interrupción de recursos crítica detectada. el personal de TI recibe una notificación de todas las
interrupciones críticas detectadas. Si la interrupción no se puede resolver inmediatamente, el personal escala
el problema e informa a los propietarios de las cargas de trabajo y al equipo de gobernanza de la nube. El
equipo de gobernanza de la nube realiza un seguimiento del problema hasta la resolución y actualiza las
instrucciones si se necesita la revisión de las directivas para prevenir futuros incidentes.
Desfase de configuración. Los recursos detectados que no se ajustan a las líneas de base establecidas
deben desencadenar alertas y corregirse automáticamente mediante herramientas de administración de
configuración como Azure Automation, Chef, Puppet o Ansible.
Pasos siguientes
Use la plantilla de la materia de coherencia de los recursos para documentar los procesos y los
Mejora de la materia de coherencia de recursos
Mejora de la materia de coherencia de recursos
Esta materia de coherencia de recursos se centra en formas de establecer directivas relacionadas con la
administración operativa de un entorno, una aplicación o una carga de trabajo. En las cinco materias de
gobernanza de la nube, la de coherencia de los recursos incluye la supervisión del rendimiento de las
aplicaciones, las cargas de trabajo y los recursos. También incluye las tareas necesarias para satisfacer las
demandas de escala, corregir las infracciones del Acuerdo de Nivel de Servicio (SLA) de rendimiento y evitar de
forma proactiva las infracciones del SLA a través de la corrección automatizada.
y mejorar la materia de coherencia de recursos. Estas tareas se dividen en las fases de planeamiento,
compilación, adopción y funcionamiento de la implementación de una solución de nube que, posteriormente, se
iteran para permitir el desarrollo de un enfoque incremental a la gobernanza de la nube.

decidir cuánto se invertirá en estas actividades para mejorar la materia de la coherencia de los recursos.
Cau t i on
nube.
evalúe sus opciones de la cadena de herramientas de coherencia de recursos.
Conozca los requisitos de licencia para su estrategia en la nube.
Familiarícese con el administrador de recursos que use para implementar, administrar y supervisar todos los
recursos para su solución como grupo.
Agregue tareas de implementación de recursos priorizadas a su trabajo pendiente de migración.
trabaje con las partes interesadas de la empresa o con su equipo de estrategia de la nube para conocer el
enfoque de cuentas de nube deseado y las prácticas de contabilidad de costos dentro de sus unidades de
negocio y su organización como un todo.
Defina sus requisitos de supervisión y aplicación de directivas.
Examine el valor empresarial y el costo de interrupción para definir los requisitos del Acuerdo de Nivel de
Servicio y la directiva de corrección.
Determine si aplicará una estrategia de gobernanza de carga de trabajo sencilla o varios equipos para sus
recursos.
Determine los requisitos de escalabilidad para sus cargas de trabajo planeadas.

Para implementar su cadena de herramientas de coherencia de los recursos, agréguela en una fase anterior a
la implementación.
Implemente tareas de implementación de recursos en su trabajo pendiente de migración priorizado.
decida sobre una estrategia de diseño de la suscripción, eligiendo los patrones de suscripción que mejor se
adapten a las necesidades de su organización y carga de trabajo.
Use una estrategia de coherencia de recursos para aplicar las instrucciones de arquitectura con el tiempo.
Implemente los estándares de nomenclatura y etiquetado de recursos para que sus recursos se adecuen a
sus requisitos organizativos y de contabilidad.
Para crear una gobernanza activa en un momento específico, use plantillas de implementación y
automatización para aplicar configuraciones habituales y una estructura de agrupación coherente al
implementar recursos y grupos de recursos.
Establezca un modelo de permisos de privilegios mínimos, en el cual los usuarios no poseen permisos de
forma predeterminada.
Determine quién de su organización posee cada carga de trabajo y cuenta, y quién deberá tener acceso para
mantener o modificar estos recursos. Defina roles y responsabilidades en la nube que coincidan con estas
necesidades y use estos roles como base para el control de acceso.
Defina las dependencias entre recursos.
Implemente el escalado de recursos automatizado para adecuarse a los requisitos definidos durante la fase
de planeamiento.
Gestione el rendimiento de acceso para medir la calidad de los servicios recibidos.
Considere la posibilidad de implementar Azure Policy para administrar la aplicación del Acuerdo de Nivel de
Servicio mediante reglas de creación de recursos y valores de configuración.
migre su cadena de herramientas de coherencia de los recursos desde la fase anterior a la implementación a
la de producción.
Migre las herramientas o scripts de corrección automatizados existentes para admitir los requisitos del
Acuerdo de Nivel de Servicio definidos.
Complete y pruebe los datos de supervisión y generación de informes con el entorno local, la puerta de
enlace en la nube o la solución híbrida que elija.
Determine si los cambios se deben aplicar a la directiva de administración o al Acuerdo de Nivel de Servicio
de los recursos.
Mejore las tareas de operaciones implementando funcionalidades de consulta para buscar recursos con
eficacia en todo su patrimonio en la nube.
Alinee los recursos para cambiar las necesidades empresariales y los requisitos de gobernanza.
Asegúrese de que sus máquinas virtuales, redes virtuales y cuentas de almacenamiento reflejan necesidades
de acceso a los recursos reales durante cada lanzamiento y realice los ajustes que sean necesarios.
Compruebe que el escalado automatizado de recursos cumple los requisitos de acceso.
Revise el acceso del usuario a los recursos, los grupos de recursos y las suscripciones de Azure, y ajuste los
controles de acceso según sea necesario.
Supervise los cambios en los planes de acceso a los recursos y valide con las partes interesadas si son
necesarias aprobaciones adicionales.
Actualice los cambios en el documento de las directrices de arquitectura para reflejar los costos reales.
Determine si su organización requiere una alineación financiera más clara con P&Ls para las unidades de
negocio.
Para las organizaciones globales, implemente sus requisitos de soberanía o cumplimiento del Acuerdo de
Nivel de Servicio.
Para la agregación de la nube, implemente una solución de puerta de enlace en un proveedor de nube.
Para las herramientas que no permiten opciones de puerta de enlace o híbridas, asocie estrechamente la
supervisión con una herramienta de supervisión operativa que abarque todos los centros de datos y nubes.

personalice su cadena de herramientas de coherencia de recursos en función de las necesidades en
constante cambio de su organización.
Considere la posibilidad de automatizar cualquier notificación e informe para reflejar el uso de recursos real.
Refina las directrices de arquitectura para guiar los procesos de adopción futuros.
Ofrezca cursos a los equipos afectados de forma periódica para garantizar la adhesión en curso a las
directrices de arquitectura.
ajuste los planes trimestralmente para reflejar los cambios en los recursos reales.
Aplique automáticamente los requisitos de gobernanza durante las implementaciones futuras.
Evalúe los recursos infrautilizados y determine si merece la pena continuar con ellos.
Detecte desajustes y anomalías entre el uso de recursos planeado y el real.
Ayude a los equipos de adopción y estrategia de la nube a conocer y resolver estas anomalías.
Determine si se deben realizar cambios en materia de coherencia de recursos para la facturación y los
Acuerdos de Nivel de Servicio.
Evalúe las herramientas de registro y supervisión para determinar si su entorno local, su puerta de enlace en
la nube o su solución híbrida debe ajustarse.
Para las unidades de negocio y los grupos distribuidos geográficamente, determine si la organización debe
considerar la posibilidad de usar características de administración en la nube adicionales (por ejemplo,
grupos de administración de Azure) para aplicar mejor la directiva centralizada y cumplir los requisitos del
Acuerdo de Nivel de Servicio.
Pasos siguientes
Ahora que comprende el concepto de gobernanza de recursos en la nube, puede obtener información acerca de
cómo se administra el acceso a los recursos en Azure como preparación para aprender a diseñar un modelo de
gobernanza para una carga de trabajo sencilla o para varios equipos.
Más información sobre la administración del acceso a los recursos en Azure Más información sobre los
Acuerdos de Nivel de Servicio de Azure Más información sobre registros, informes y supervisión
Herramientas de la coherencia de recursos en Azure
Coherencia de recursos es una de las cinco materias de gobernanza de la nube. Esta materia se centra en las
distintas formas de establecer directivas relacionadas con la administración operativa de un entorno, una
aplicación o una carga de trabajo. En las cinco materias de gobernanza de la nube, la de coherencia de los
recursos implica la supervisión del rendimiento de las aplicaciones, las cargas de trabajo y los recursos. También
abarca las tareas necesarias para satisfacer las demandas de escala, corregir las infracciones del contrato de
nivel de servicio de rendimiento y evitar estas de forma proactiva mediante la corrección automatizada.
A continuación, se muestra una lista de las herramientas de Azure que pueden ayudar a desarrollar las directivas
y los procesos que admiten esta materia.
A Z URE A Z URE A Z URE

H ERRA M IE A Z URE RESO URC E B L UEP RIN T A UTO M AT I A Z URE A Z URE SIT E
N TA P O RTA L M A N A GER S ON A Z URE A D B A C K UP REC O VERY
Implement Sí Sí Sí Sí No No No
ación de
recursos
Administrar Sí Sí Sí Sí No No No
recursos
Implement No Sí No Sí No No No
ación de
recursos
mediante
plantillas
Implement No No Sí No No No No
ación de
entornos
organizada
Definición Sí Sí Sí No No No No
de grupos
de recursos
Administrac Sí Sí Sí No No No No
ión de
propietario
s de
cuentas y
de cargas
de trabajo
Administrac Sí Sí Sí No No No No
ión del
acceso
condicional
a los
recursos
Configuraci Sí No No No Sí No No
ón de
usuarios de
RBAC de
Azure
Asignación Sí Sí Sí No Sí No No
de roles y
permisos a
los recursos
Definición No Sí Sí No No No No
de las
dependenci
as entre
recursos
Aplicación Sí Sí Sí No Sí No No
del control
de acceso
Evaluación No No No Sí No No No
de
disponibilid
ad y
escalabilida
d
Aplicación Sí Sí Sí No No No No
de
etiquetas a
recursos
Asignación Sí Sí Sí No No No No
de reglas
de Azure
Policy
Aplicación No No No Sí No No No
de la
corrección
automatiza
da
Administrac Sí No No No No No No
ión de
facturas
Planeamien Sí Sí Sí No No Sí Sí
to de
recursos
para la
recuperació
n ante
desastres
Recuperació No No No No No Sí Sí
n de datos
durante un
corte o una
infracción
del
Acuerdo de
Nivel de
Servicio
Recuperació No No No No No Sí Sí
n de
aplicaciones
y datos
durante un
corte o una
infracción
del
Acuerdo de
Nivel de
Servicio
Junto con estas características y herramientas de la coherencia de recursos, será preciso que supervise si los
recursos implementados tienen problemas de rendimiento y mantenimiento. Azure Monitor es la solución de
supervisión y generación de informes predeterminada de Azure. Azure Monitor proporciona características para
supervisar los recursos en la nube. Esta lista muestra qué característica se ocupa de los requisitos de
supervisión habituales.
A P P L IC AT IO N A P I DE REST DE
H ERRA M IEN TA A Z URE P O RTA L IN SIGH T S LO G A N A LY T IC S A Z URE M O N ITO R
Registro de datos de No No Sí No
telemetría de
máquina virtual
telemetría de redes
virtuales
telemetría de
servicios de PaaS
Registro de datos de No Sí No No
telemetría de las
aplicaciones
Configuración de Sí No No Sí
informes y alertas
Programación de No No No No
informes periódicos o
análisis
personalizados
A P P L IC AT IO N A P I DE REST DE
H ERRA M IEN TA A Z URE P O RTA L IN SIGH T S LO G A N A LY T IC S A Z URE M O N ITO R
Visualización y Sí No No No
análisis de datos de
rendimiento y
registro
Integración con una No No No Sí

solución de
supervisión local o de
terceros
Al planear la implementación, será preciso que tenga en cuenta dónde se almacenan los datos de registro y
cómo se integran los servicios de supervisión y generación de informes en la nube con las herramientas y los
procesos existentes.
NOTE
Las organizaciones también usan herramientas de DevOps de terceros para supervisar las cargas de trabajo y los
recursos. Para obtener más información, vea DevOps Tool Integrations.
Pasos siguientes
Aprenda a crear, asignar y administrar definiciones de directivas en Azure.
La metodología de gobernanza describe las cinco materias correspondientes, que incluye la administración de
recursos. Gobernanza del acceso a los recursos explica cómo la administración del acceso a los recursos está
incluida en la materia sobre la administración de los recursos. Antes de continuar y aprender cómo se diseña un
modelo de gobernanza, es importante comprender los controles de administración de acceso a los recursos de
Azure. La configuración de estos controles de administración de acceso a los recursos constituye la base de su
modelo de gobernanza.
Comience por examinar más de cerca cómo se implementan los recursos en Azure.
¿Qué es un recurso de Azure?

En Azure, el término recurso hace referencia a una entidad administrada por Azure. Por ejemplo, las máquinas
virtuales, las redes virtuales y las cuentas de almacenamiento se denominan recursos de Azure.
Figura 1: Un recurso.
¿Qué es un grupo de recursos de Azure?

En Azure, todos los recursos deben pertenecer a un grupo de recursos. Un grupo de recursos es simplemente
una construcción lógica que agrupa varios recursos para poder administrarlos como una sola entidad en
función del ciclo de vida y la seguridad . Por ejemplo, los recursos que comparten un ciclo de vida similar,
como los recursos para una aplicación de n niveles, pueden crearse o eliminarse como un grupo. En otras
palabras, todo aquello que se origina, se administra y se pone en desuso conjuntamente, se incluye en el mismo
grupo de recursos.
Figura 2: Un grupo de recursos contiene un recurso.
Los grupos de recursos, y los recursos que contienen, están asociados a una suscripción a Azure.
¿Qué es una suscripción de Azure?

Una suscripción a Azure es similar a un grupo de recursos en cuanto que se trata de una construcción lógica que
agrupa los grupos de recursos y sus recursos. Además, está asociada con los controles que usa Azure Resource
Manager. Veamos más de cerca Azure Resource Manager y cómo se relaciona con una suscripción de Azure.
Figura 3: Una suscripción de Azure.
¿Qué es Azure Resource Manager?

En ¿Cómo funciona Azure?, aprendió que Azure incluye un front-end con muchos servicios que orquestan todas
las funciones de Azure. Uno de estos servicios es Azure Resource Manager y hospeda la API RESTful que los
clientes utilizan para administrar los recursos.
Figura 4: Azure Resource Manager.
En la siguiente ilustración se muestran tres clientes: PowerShell, Azure Portal y la CLI de Azure:
Figura 5: Los clientes de Azure conectan con la API REST de Resource Manager.
Aunque estos clientes se conectan a Resource Manager mediante la API REST, Resource Manager no incluye una
funcionalidad para administrar los recursos directamente. En su lugar, la mayoría de los tipos de recursos de
Azure tienen sus propios proveedores de recursos.
Figura 6: Proveedores de recursos de Azure.
Cuando un cliente realiza una solicitud para administrar un recurso específico, Azure Resource Manager conecta
con el proveedor de recursos para ese tipo de recurso para completar la solicitud. Por ejemplo, si un cliente
realiza una solicitud para administrar un recurso de máquina virtual, Azure Resource Manager conecta con el
proveedor de recursos Microsoft.Compute .
Figura 7: Azure Resource Manager conecta con el proveedor de recursos Microsoft.Compute para administrar el
recurso especificado en la solicitud del cliente.
Azure Resource Manager requiere que el cliente especifique un identificador de suscripción y de grupo de
recursos para poder administrar el recurso de máquina virtual.
Ahora que ya comprende cómo funciona Azure Resource Manager, volvamos a la explicación de cómo una
suscripción de Azure está asociada con los controles utilizados por Azure Resource Manager. Antes de que Azure
Resource Manager pueda ejecutar ninguna solicitud de administración de recursos, se comprueban un conjunto
de controles.
El primer control es que la solicitud debe realizarla un usuario validado y Azure Resource Manager tiene una
relación de confianza con Azure Active Directory (Azure AD), que proporciona la funcionalidad de identidades de
usuario.
Figura 8: Azure Active Directory.

Los usuarios de Azure AD se segmentan en inquilinos. Un inquilino es una construcción lógica que representa
una instancia segura y dedicada de Azure AD, normalmente asociada a una organización. Cada suscripción está
asociada a un inquilino de Azure AD.
Figura 9: Inquilino de Azure AD asociado a una suscripción.
Para poder procesar solicitudes de cliente para administrar un recurso en una determinada suscripción, el
usuario debe tener una cuenta en el inquilino de Azure AD.
El control siguiente es una comprobación de que el usuario tiene permisos suficientes para realizar la solicitud.
Los permisos se asignan a los usuarios con el control de acceso basado en rol de Azure (RBAC de Azure).
Figura 10: cada usuario del inquilino se asigna a uno o varios roles de Azure.
Un rol de Azure especifica un conjunto de permisos que un usuario puede tener en un recurso específico.
Cuando se asigna el rol al usuario, se aplican estos permisos. Por ejemplo, el rol integrado owner permite a un
usuario realizar cualquier acción en un recurso.
El siguiente control es una comprobación de que la solicitud se permite de acuerdo con la configuración
especificada para la directiva de recursos de Azure. Las directivas de recursos de Azure especifican las
operaciones permitidas para un recurso específico. Por ejemplo, una directiva de recursos de Azure puede
especificar que los usuarios solo pueden implementar un tipo específico de máquina virtual.
Figura 11: Directiva de recursos de Azure.
El siguiente control es una comprobación de que la solicitud no supera un límite de suscripción de Azure. Por
ejemplo, cada suscripción tiene un límite de 980 grupos de recursos por suscripción. Si se recibe una solicitud
para implementar un grupo de recursos adicional cuando se ha alcanzado el límite, se deniega.
Figura 12: Límites de recursos de Azure.
El control final es una comprobación de que la solicitud está dentro del compromiso financiero asociado a la
suscripción. Por ejemplo, si la solicitud es para implementar una máquina virtual, Azure Resource Manager
comprueba que la suscripción tiene suficiente información de pago.
Figura 13: Una suscripción tiene asociado un compromiso financiero.
Resumen
En este artículo, ha aprendido cómo se administra el acceso a los recursos en Azure mediante Azure Resource
Manager.
Pasos siguientes
Ahora que comprende cómo administrar el acceso a los recursos en Azure, aprenda ahora cómo diseñar un
modelo de gobernanza para una carga de trabajo simple o para varios equipos con estos servicios.
Introducción a la gobernanza
Diseño de gobernanza para una carga de trabajo
sencilla
El objetivo de esta guía es ayudarle a obtener información sobre el proceso para diseñar un modelo de
gobernanza de recursos en Azure que admita un único equipo y una carga de trabajo simple. Veremos un
conjunto de requisitos de gobernanza hipotéticos y, después, describiremos varias implementaciones de
ejemplo que cumplen dichos requisitos.
En la fase de adopción de fundación, nuestro objetivo es implementar una carga de trabajo simple en Azure. El
resultado son los siguientes requisitos:
Administración de identidades para un solo propietario de cargas de trabajo , que es responsable de
implementar y mantener la carga de trabajo simple. El propietario de la carga de trabajo necesita permisos
para crear, leer, actualizar y eliminar recursos, así como permisos para delegar estos derechos a otros
usuarios en el sistema de administración de identidades.
Administrar todos los recursos para la carga de trabajo simple como una unidad única de administración.
Licencias de Azure
Antes de comenzar el diseño de nuestro modelo de gobernanza, es importante comprender cómo se conceden
las licencias de Azure. El motivo es que las cuentas administrativas asociadas con su licencia de Azure tienen el
mayor nivel de acceso a los recursos de Azure. Estas cuentas administrativas forman la base de su modelo de
gobernanza.
NOTE
Si su organización ya tiene un Contrato Enterprise de Microsoft que no incluye Azure, se puede agregar Azure mediante
un compromiso monetario por adelantado. Para obtener más información, consulte Licencias de Azure para la empresa.
Cuando Azure se agregó al contrato Enterprise de su organización, se solicitó a su organización la creación de

una cuenta de Azure . Durante el proceso de creación de la cuenta, se crea un propietario de la cuenta de
Azure y un inquilino de Azure Active Directory (Azure AD) con una cuenta de administrador global . Un
inquilino de Azure AD es una construcción lógica que representa una instancia segura y dedicada de Azure AD.
Figura 1: Una cuenta de Azure con un propietario de la cuenta de Azure y el administrador global de Azure AD
Administración de identidades
Azure solo confía en Azure AD para autenticar usuarios y autorizar el acceso de los usuarios a los recursos, por
lo que Azure AD es nuestro sistema de administración de identidades. El administrador global de Azure AD tiene
el mayor nivel de permisos y puede realizar todas las acciones relacionadas con la identidad, incluida la creación
de usuarios y asignación de permisos.
Nuestro requisito es una administración de identidades para un solo propietario de cargas de trabajo , que
es responsable de implementar y mantener la carga de trabajo simple. El propietario de la carga de trabajo
necesita permisos para crear, leer, actualizar y eliminar recursos, así como permisos para delegar estos derechos
a otros usuarios en el sistema de administración de identidades.
Nuestro administrador global de Azure AD creará la cuenta de propietario de carga de trabajo para el
propietario de la carga de trabajo:
Figura 2: El administrador global de Azure AD crea la cuenta de usuario del propietario de carga de trabajo.
No puede asignar permiso de acceso a los recursos hasta que este usuario se agregue a una suscripción , lo
que haremos en las dos secciones siguientes.
Ámbito de la administración de recursos

A medida que crece el número de los recursos implementados por la organización, aumenta también la
complejidad del gobierno de estos recursos. Azure implementa una jerarquía de contenedores lógicos para que
su organización pueda administrar los recursos en grupos con distintos niveles de granularidad, lo que también
se conoce como ámbito .
El nivel superior del ámbito de administración de recursos es el nivel de suscripción . El propietario de la
cuenta de Azure crea una suscripción, que establece el compromiso financiero y es responsable del pago de
todos los recursos de Azure asociados con la suscripción:
Figura 3: El propietario de la cuenta de Azure crea una suscripción.
Cuando se crea la suscripción, el propietario de la cuenta de Azure asocia un inquilino de Azure AD con la
suscripción, y este inquilino de Azure AD se usa para autenticar y autorizar a los usuarios:
Figura 4: El propietario de la cuenta de Azure asocia el inquilino de Azure AD con la suscripción.

Puede que haya observado que actualmente no hay ningún usuario asociado con la suscripción, lo que significa
que nadie tiene permiso para administrar los recursos. En la práctica, el propietario de la cuenta es el
propietario de la suscripción y tiene permiso para realizar cualquier acción en un recurso en la suscripción. En la
práctica, es muy probable que el propietario de la cuenta sea un encargado de finanzas de su organización y
no el responsable de crear, leer, actualizar y eliminar los recursos. Esas tareas las realizará el propietario de la
carga de trabajo ; por lo tanto, hay que agregar el propietario de la carga de trabajo a la suscripción y
asignar los permisos.
El propietario de la cuenta es actualmente el único usuario con permiso para agregar el propietario de la
carga de trabajo a la suscripción, por lo que agrega el propietario de la carga de trabajo a la suscripción:
Figura 5: El propietario de la cuenta de Azure agrega el propietario de la carga de trabajo a la suscripción.

El propietario de la cuenta de Azure concede permisos al propietario de la carga de trabajo mediante su
asignación a un rol de Azure. El rol de Azure especifica el conjunto de permisos que tiene el propietario de la
carga de trabajo para un tipo de recurso individual o para un conjunto de tipos de recursos.
Tenga en cuenta que, en este ejemplo, el propietario de la cuenta ha asignado el rol integrado propietario :
Figura 6: Se asignó el rol integrado propietario al propietario de la carga de trabajo.

El rol integrado propietario concede todos los permisos al propietario de la carga de trabajo en el ámbito
de la suscripción.
IMPORTANT
El propietario de la cuenta de Azure es responsable del compromiso financiero asociado con la suscripción, pero el
propietario de la carga de trabajo tiene los mismos permisos. El propietario de la cuenta debe confiar en el
propietario de la carga de trabajo para implementar los recursos que están dentro del presupuesto de suscripción.
El siguiente nivel del ámbito de administración es el nivel grupo de recursos . Un grupo de recursos es un
contenedor lógico de recursos. Las operaciones que se aplican en el nivel de grupo de recursos se aplican a
todos los recursos de un grupo. Además, es importante tener en cuenta que los permisos de cada usuario se
heredan de los permisos del siguiente nivel superior, a menos que se cambien explícitamente en ese ámbito.
Para ilustrar esto, veamos lo que sucede cuando el propietario de la carga de trabajo crea un grupo de
recursos:
Figura 7: El propietario de la carga de trabajo crea un grupo de recursos y hereda el rol integrado propietario en
el ámbito del grupo de recursos.
De nuevo, el rol integrado propietario concede todos los permisos al propietario de la carga de trabajo en
el ámbito del grupo de recursos. Tal y como se explicó anteriormente, este rol se hereda del nivel de suscripción.
Si se asigna un rol diferente a este usuario en este ámbito, se aplica solo a este ámbito.
El nivel del ámbito de administración más bajo es el nivel recurso . Las operaciones que se aplican en el nivel de
recursos se aplican solo al recurso en sí. De nuevo, los permisos del nivel de recurso se heredan del ámbito del
grupo de recursos. Por ejemplo, veamos lo que sucede si el propietario de la carga de trabajo implementa
una red virtual en el grupo de recursos:
Figura 8: El propietario de la carga de trabajo crea un recurso y hereda el rol integrado propietario en el ámbito
del recurso.
El propietario de la carga de trabajo hereda el rol de propietario en el ámbito del recurso, lo que significa
que el propietario de la carga de trabajo tiene todos los permisos para la red virtual.
Implementación del modelo de administración de acceso a los

recursos básico
Vamos a aprender a implementar el modelo de gobernanza diseñado anteriormente.
Para empezar, la organización necesita una cuenta de Azure. Si su organización ya tiene un Contrato Enterprise
de Microsoft que no incluye Azure, se puede agregar Azure mediante un compromiso monetario por
adelantado. Para obtener más información, consulte Licencias de Azure para la empresa.
Cuando cree la cuenta de Azure, especifique el usuario de su organización que será el propietario de la
cuenta de Azure. Después, se crea un inquilino de Azure Active Directory (Azure AD) de forma predeterminada.
El propietario de la cuenta de Azure debe crear la cuenta de usuario para el usuario de la organización que
sea el propietario de cargas de trabajo .
A continuación, el propietario de la cuenta de Azure debe crear una suscripción y asociar el inquilino de
Azure AD a ella.
Por último, con la suscripción creada y el inquilino de Azure AD asociado a ella, puede agregar el propietario
de cargas de trabajo a la suscripción con el rol integrado propietario .
Pasos siguientes
Obtenga información sobre el acceso a los recursos para varios equipos
Diseño de gobernanza para varios equipos
El objetivo de esta guía es ayudarle a obtener información sobre el proceso de diseño de un modelo de
gobernanza de recursos en Azure que admita varios equipos, varias cargas de trabajo y varios entornos.
Primero, veremos un conjunto de requisitos de gobernanza hipotéticos y, después, describiremos varias
implementaciones de ejemplo que cumplen dichos requisitos.
Los requisitos son:
La empresa planea la transición de nuevos roles y responsabilidades en la nube a un conjunto de usuarios y,
por tanto, se requiere la administración de identidades para varios equipos con diferentes necesidades de
acceso a los recursos de Azure. Este sistema de administración de identidades es necesario para almacenar la
identidad de los usuarios siguientes:
La persona de la organización responsable de la propiedad de las suscripciones .
La persona de la organización responsable de los recursos de la infraestructura compar tida
utilizados para conectar la red local a una red virtual en Azure.
Dos personas de la organización responsables de administrar una carga de trabajo .
Compatibilidad para varios entornos . Un entorno es una agrupación lógica de recursos, como máquinas
virtuales, redes virtuales y servicios de enrutamiento de tráfico de red. Estos grupos de recursos tienen
requisitos de seguridad y administración similares y se suelen usar para un propósito específico, como
pruebas o producción. En este ejemplo, son necesarios cuatro entornos:
Un entorno de infraestructura compar tida que incluya los recursos compartidos por las cargas
de trabajo en otros entornos. Por ejemplo, una red virtual con una subred de puerta de enlace que
proporciona conectividad con el entorno local.
Un entorno de producción con las directivas de seguridad más restrictivas. Puede incluir las cargas
de trabajo de acceso interno o externo.
Un entorno que no sea de preproducción para trabajos de desarrollo y pruebas. Las directivas de
seguridad, de cumplimiento normativo y de costos de este entorno difieren de los del entorno de
producción. En Azure, esto adopta la forma de una suscripción de desarrollo/pruebas - Enterprise.
Un entorno de espacio aislado con fines de prueba de concepto y educativos. Este entorno se
asigna normalmente por cada empleado que participa en las actividades de desarrollo e incluye
estrictos controles de seguridad de procedimientos y controles operativos para evitar que los datos
corporativos entren aquí. En Azure, estos adoptan la forma de suscripciones de Visual Studio. Estas
suscripciones no se deben asociar tampoco a la instancia de Azure Active Directory de la empresa.
Un modelo de permisos de privilegios mínimos en el cual los usuarios no poseen permisos de forma
predeterminada. El modelo debe admitir lo siguiente:
Un único usuario de confianza en el ámbito de la suscripción, tratado como una cuenta de servicio,
con permiso para asignar derechos de acceso a los recursos.
De forma predeterminada, a los propietarios de las cargas de trabajo se les deniega el acceso a los
recursos. Los derechos de acceso a los recursos los concede explícitamente el usuario único de
confianza en el ámbito del grupo de recursos.
Acceso de administración a los recursos compartidos de la infraestructura limitado a los propietarios
de la infraestructura compartida.
Acceso de administración para cada carga de trabajo limitado al propietario de la carga de trabajo en
producción, con el aumento de los niveles de control a medida que el desarrollo continúa a través de
los distintos entornos de implementación (desarrollo, prueba, ensayo y producción).
La empresa no quiere tener que administrar los roles de forma independiente en cada uno de los tres
entornos principales, por lo tanto, solo se necesita el uso de los roles integrados que están disponibles
en el control de acceso basado en rol de Azure (RBAC de Azure). Si la empresa requiere
necesariamente roles personalizados, serán necesarios procesos adicionales para sincronizar los roles
personalizados en los tres entornos.
Seguimiento de los costos por nombre de propietario de la carga de trabajo, entorno o ambos.
Administración de identidades
Antes de diseñar la administración de identidades para nuestro modelo de gobernanza, es importante
comprender las cuatro áreas principales que incluye:
Administración: procesos y herramientas para crear, editar y eliminar identidades de usuario.
Autenticación: validación de las credenciales, por ejemplo, nombre de usuario y contraseña, para
comprobar la identidad del usuario.
Authorization: determinación de cuáles son los recursos a los que puede acceder un usuario autenticado o
qué operaciones está autorizado a realizar.
Auditoría: revisión periódica de los registros y otra información para detectar problemas de seguridad
relacionados con la identidad de los usuarios. Esto incluye la revisión de los patrones de uso sospechosos, la
revisión periódica de los permisos de usuario para comprobar que son precisos, entre otras funciones.
Hay solo un servicio de Azure de confianza para la identidad y es Azure Active Directory (Azure AD). Los
usuarios se agregan a Azure AD, que se usa para todas las funciones enumeradas anteriormente. Antes de ver
cómo configurar Azure AD, es importante comprender las cuentas con privilegios que se utilizan para
administrar el acceso a estos servicios.
Cuando la organización se registró para una cuenta de Azure, se asignó al menos un propietario de la cuenta
de Azure. Además, se creó un inquilino de Azure AD, a menos que ya hubiera un inquilino asociado con el uso
por parte de la organización de otros servicios de Microsoft como Microsoft 365. Al crear el inquilino de Azure
AD, se asocia un administrador global con permisos completos.
Ambas identidades de usuario, administrador global de Azure AD y propietario de la cuenta de Azure, se
almacenan en un sistema de identidades de alta seguridad administrado por Microsoft. El propietario de la
cuenta de Azure tiene autorización para crear, actualizar y eliminar suscripciones. El administrador global de
Azure AD tiene autorización para realizar muchas acciones en Azure AD pero, para los fines de esta guía de
diseño, nos centraremos en la creación y eliminación de identidades de usuario.
NOTE
Puede que su organización ya tenga un inquilino de Azure AD si ya hay una licencia de Microsoft 365, Intune o
Dynamics 365 asociada a su cuenta.
El propietario de la cuenta de Azure tiene permiso para crear, actualizar y eliminar suscripciones:
Figura 1: Una cuenta de Azure con un propietario de la cuenta de Azure y el administrador global de Azure AD
El administrador global de Azure AD tiene permiso para crear cuentas de usuario:
Figura 2: El administrador global de Azure AD crea las cuentas de usuario necesarias en el inquilino.
Las dos primeras cuentas, propietario de la carga de trabajo de app1 y propietario de la carga de
trabajo de app2 , están asociadas a una persona de la organización responsable de administrar una carga de
trabajo. La cuenta de operaciones de red pertenece a la persona responsable de los recursos de la
infraestructura compartida. Por último, la cuenta del propietario de la suscripción está asociada con la
persona responsable de la propiedad de las suscripciones.
Modelo de permisos de acceso a recursos con privilegios mínimos

Ahora que se han creado las cuentas de usuario y el sistema de administración de identidades, debe decidir
cómo aplicar roles de Azure a cada cuenta para admitir un modelo de permisos con privilegios mínimos.
Otro requisito indica que los recursos asociados a cada carga de trabajo estén aislados entre sí para que ningún
propietario de carga de trabajo tenga acceso administrativo a otras cargas de trabajo que no les pertenezcan.
También hay un requisito para implementar este modelo solo con los roles integrados del control de acceso
basado en rol de Azure.
Cada rol de Azure se aplica en uno de los tres ámbitos en Azure: suscripción , grupo de recursos y recursos
individuales. Los roles se heredan en los ámbitos inferiores. Por ejemplo, si a un usuario se le asigna el rol de
propietario integrado en el nivel de suscripción, ese rol también se asigna a ese usuario en el nivel de recurso
individual y grupal, a menos que se invalide.
Por lo tanto, para crear un modelo de acceso con privilegios mínimos, hay que decidir qué acciones puede
realizar un determinado tipo de usuario en cada uno de estos tres ámbitos. Por ejemplo, el requisito es que el
propietario de una carga de trabajo tenga permiso para administrar el acceso únicamente a los recursos
asociados con su carga de trabajo y no a otros. Si quisiéramos asignar el rol de propietario integrado en el
ámbito de la suscripción, cada propietario de carga de trabajo tendría acceso de administración a todas las
cargas de trabajo.
Veamos dos ejemplos de modelos de permisos para entender este concepto algo mejor. En el primer ejemplo, el
modelo confía solo en el administrador de servicios para crear grupos de recursos. En el segundo ejemplo, el
modelo asigna el rol de propietario integrado a cada propietario de carga de trabajo en el ámbito de la
suscripción.
En ambos ejemplos, hay un administrador de servicios de la suscripción al que se asigna el rol integrado
Propietario en el ámbito de la suscripción. Recuerde que el rol de propietario integrado concede todos los
permisos, incluida la administración del acceso a los recursos.
Figura 3: Una suscripción con un administrador de servicios al que se asigna el rol integrado Propietario.
1. En el primer ejemplo, el propietario de carga de trabajo A no tiene ningún permiso en el ámbito de
suscripción y ningún derecho de administración de acceso a los recursos de manera predeterminada. Este
usuario quiere volver a implementar y administrar los recursos de su carga de trabajo. Debe ponerse en
contacto con el administrador de ser vicios para pedir la creación de un grupo de recursos.
2. El administrador de ser vicios revisa la solicitud y crea el grupo de recursos A . En este momento, el
propietario de carga de trabajo A aún no tiene permiso para hacer nada.
3. El administrador de ser vicios agrega al propietario de la carga de trabajo A al grupo de recursos
A y le asigna el rol integrado Colaborador. El rol Colaborador concede todos los permisos en el grupo de
recursos A excepto la administración de los permisos de acceso.
4. Supongamos que el propietario de carga de trabajo A necesita que un par de miembros del equipo vean
los datos de supervisión del tráfico de red y la CPU como parte de la planeación de la capacidad para la
carga de trabajo. Dado que el propietario de la carga de trabajo A tiene asignado el rol Colaborador, no
tiene permisos para agregar un usuario al grupo de recursos A . Debe enviar esta solicitud al
administrador de ser vicios .
5. El administrador de ser vicios revisa la solicitud y agrega los dos usuarios colaboradores de carga de
trabajo al grupo de recursos A . Ninguno de estos dos usuarios necesitan permisos para administrar los
recursos, por lo que se les asigna el rol integrado Lector.
6. El propietario de carga de trabajo B también necesita un grupo de recursos para incluir los recursos de
su carga de trabajo. Al igual que con el propietario de carga de trabajo A , el propietario de carga de
trabajo B inicialmente no tiene permisos para realizar ninguna acción en el ámbito de la suscripción, por lo
que debe enviar una solicitud al administrador de ser vicios .
7. El administrador de ser vicios revisa la solicitud y crea el grupo de recursos B .
8. El administrador de ser vicios agrega al propietario de la carga de trabajo B al grupo de recursos

B y le asigna el rol integrado Colaborador.
En este momento, cada uno de los propietarios de carga de trabajo está aislado en su propio grupo de recursos.
Ninguno de los propietarios de carga de trabajo ni los miembros del equipo tienen acceso administrativo a los
recursos de otros grupos de recursos.
Figura 4: Una suscripción con dos propietarios de cargas de trabajo aislados con su propio grupo de recursos.
Este es un modelo con privilegios mínimos. A cada usuario se le asignan los permisos correctos en el ámbito de
administración de recursos correcto.
Tenga en cuenta que todas las tareas del ejemplo las realizó el administrador de ser vicios . Este es un
ejemplo sencillo y quizás esto no parezca un problema porque hay solo dos propietarios de cargas de trabajo,
pero es fácil imaginar los tipos de problemas que habría en una organización grande. Por ejemplo, el
administrador de ser vicios puede convertirse en un cuello de botella con muchas solicitudes acumuladas
que, como resultado, producen retrasos.
Veamos otro ejemplo que reduce el número de tareas realizadas por el administrador de ser vicios .
1. En este modelo, al propietario de la carga de trabajo A se le asigna el rol de propietario integrado en el
ámbito de la suscripción, lo que le permite crear su propio grupo de recursos: grupo de recursos A .
2. Cuando se crea el grupo de recursos A , se agrega el propietario de la carga de trabajo A de forma

predeterminada y se hereda el rol de propietario integrado del ámbito de la suscripción.
3. El rol de propietario integrado concede al propietario de la carga de trabajo A permisos para

administrar el acceso al grupo de recursos. El propietario de la carga de trabajo A agrega dos
colaboradores de carga de trabajo y les asigna a cada uno el rol integrado Lector.
4. Ahora, el administrador de ser vicios agrega al propietario de la carga de trabajo B a la suscripción

con el rol integrado Propietario.
5. El propietario de carga de trabajo B crea el grupo de recursos B y se agrega de forma

predeterminada. Una vez más, el propietario de carga de trabajo B hereda el rol de propietario integrado
del ámbito de la suscripción.
Tenga en cuenta que, en este modelo, el administrador de ser vicios realizó menos acciones que en el primer
ejemplo debido a que se delegó la administración del acceso a cada uno de los propietarios de carga de trabajo
individuales.
Figura 5: Una suscripción con un administrador de servicios y dos propietarios de cargas de trabajo a los que se
asigna el rol integrado Propietario.
Because both workload owner A and workload owner B are assigned the built-in Owner role at the
subscription scope, they have each inherited the built-in Owner role for each other's resource group. Esto
significa que no solo tienen acceso total a los recursos mutuos sino que también pueden delegar el acceso
administrativo a los grupos de recursos mutuos. Por ejemplo, el propietario de carga de trabajo B tiene
derechos para agregar otros usuarios al grupo de recursos A y puede asignarles cualquier rol, como el rol de
propietario integrado.
Si comparamos cada ejemplo con los requisitos, vemos que ambos ejemplos admiten un único usuario de
confianza en el ámbito de la suscripción con permisos para conceder derechos de acceso a los recursos a los
dos propietarios de carga de trabajo. Ninguno de los dos propietarios de carga de trabajo tenía acceso a la
administración de recursos de forma predeterminada y necesitaron que el administrador de ser vicios les
asignara los permisos explícitamente. Solo el primer ejemplo admite que los recursos asociados a cada carga de
trabajo estén aislados entre sí, de manera que ningún propietario de carga de trabajo tenga acceso a los
recursos de otras cargas de trabajo.
Modelo de administración de recursos

Ahora que hemos diseñado un modelo de permisos con privilegios mínimos, vamos a ver algunas aplicaciones
prácticas de estos modelos de gobernanza. Recuerde que los requisitos son que debemos admitir los siguientes
tres entornos:
1. Entorno de infraestructura compar tida: un grupo de recursos que todas las cargas de trabajo
comparten. Estos son recursos tales como puertas de enlace de red, firewalls y servicios de seguridad.
2. Entorno de producción: varios grupos de recursos que representan varias cargas de trabajo de
producción. Estos recursos se utilizan para hospedar los artefactos de aplicación de acceso privado y público.
Estos recursos normalmente tienen una gobernanza y modelos de seguridad más estrictos para proteger los
recursos, el código de la aplicación y los datos contra accesos no autorizados.
3. Entorno de preproducción: varios grupos de recursos que representan varias cargas de trabajo que no
están listas para producción. Estos recursos se usan con fines de desarrollo y pruebas y pueden tener un
modelo de gobernanza más flexible para ofrecer más agilidad a los desarrolladores. La seguridad dentro de
estos grupos debe aumentar a medida que el proceso de desarrollo de aplicaciones se acerca al entorno de
producción.
En cada uno de estos tres entornos, hay que realizar el seguimiento de los datos de costo por propietario de
carga de trabajo , entorno o ambos. Es decir, querrá conocer el costo actual de la infraestructura
compar tida , los costos en los que incurren los usuarios tanto en entornos que no son de producción como
en entornos de producción y, por último, el costo total de los entornos que no son de producción y los de
producción .
Ya ha aprendido que el ámbito de los recursos se establece en dos niveles: suscripción y grupo de recursos .
Por lo tanto, la primera decisión es cómo organizar los entornos por suscripción . Hay solo dos posibilidades:
una sola suscripción o varias suscripciones.
Antes de adentrarnos en los ejemplos de cada uno de estos modelos, revisemos la estructura de administración
de las suscripciones de Azure.
Recuerde que necesitamos tener una persona en la organización que sea responsable de las suscripciones y que
este usuario tiene la cuenta de propietario de la suscripción en el inquilino de Azure AD. Esta cuenta no tiene
permisos para crear suscripciones. Solo el propietario de la cuenta de Azure tiene permisos para hacerlo:
Figura 6: El propietario de una cuenta de Azure crea una suscripción.
Una vez creada la suscripción, el propietario de la cuenta de Azure puede agregar la cuenta del
propietario de la suscripción a la suscripción con el rol Propietario :
Figura 7: El propietario de la cuenta de Azure agrega la cuenta de usuario de propietario de la suscripción a la
suscripción con el rol de propietario.
Ahora, la cuenta del propietario de la suscripción puede crear grupos de recursos y delegar la
administración del acceso a los recursos.
Veamos primero un ejemplo de un modelo de administración de recursos con una sola suscripción. La primera
decisión es cómo alinear los grupos de recursos con los tres entornos. Tiene dos opciones:
1. Alinear cada entorno con un único grupo de recursos. Todos los recursos de la infraestructura compartida se
implementan en un único grupo de recursos de la infraestructura compar tida . Todos los recursos
asociados con las cargas de trabajo de desarrollo se implementan en un único grupo de recursos de
desarrollo . Todos los recursos asociados con las cargas de trabajo de producción se implementan en un
solo grupo de recursos de producción para el entorno de producción .
2. Crear grupos de recursos independientes para cada carga de trabajo, utilizando una convención de
nomenclatura y etiquetas para alinear los grupos de recursos con cada uno de los tres entornos.
Comencemos evaluando la primera opción. Vamos a usar el modelo de permisos que analizamos en la sección
anterior, con un único administrador de servicios de la suscripción que crea los grupos de recursos y agrega los
usuarios a ellos con el rol integrado Colaborador o Lector .
1. El primer grupo de recursos implementado representa el entorno de infraestructura compar tida . La
cuenta del propietario de la suscripción crea un grupo de recursos para los recursos de la infraestructura
compartida llamado netops-shared-rg .
2. La cuenta del propietario de la suscripción agrega la cuenta del usuario de operaciones de red al
grupo de recursos y le asigna el rol de colaborador .
3. El usuario de operaciones de red crea una puerta de enlace VPN y la configura para que se conecte al
dispositivo VPN local. El usuario de operaciones de red también aplica un par de etiquetas a cada uno de
los recursos: environment:shared y managedBy:netops . Cuando el administrador de ser vicios de
suscripción exporta un informe de costos, los costos se alinearán con cada una de estas etiquetas. Esto
permite al administrador de ser vicios de la suscripción dinamizar los costos con las etiquetas
environment y managedBy . Observe el contador límites de recursos en la parte superior derecha de la
ilustración. Cada suscripción de Azure tiene límites de servicio y, para ayudarle a comprender el efecto de
estos límites, seguiremos los límites de redes virtuales para cada suscripción. Hay un límite de 1000 redes
virtuales por suscripción y, después de implementar la primera red virtual, quedan 999 disponibles.
4. Se implementan dos grupos de recursos más. El primero se llama prod-rg . Este grupo de recursos se alinea
con el entorno de producción. El segundo se llama dev-rg y se alinea con el entorno de desarrollo. Todos los
recursos asociados con las cargas de trabajo de producción se implementan en el entorno de producción y
todos los recursos asociados con las cargas de trabajo de desarrollo se implementan en el entorno de
desarrollo. En este ejemplo solo implementaremos dos cargas de trabajo en cada uno de estos dos entornos,
por lo que no encontraremos ningún límite del servicio de suscripción de Azure. Hay que tener en cuenta
que cada grupo de recursos tiene un límite de 800 recursos por grupo. Si continúa agregando cargas de
trabajo a cada grupo de recursos, con el tiempo alcanzará este límite.
5. El primer propietario de carga de trabajo envía una solicitud al administrador de ser vicios de
suscripción y se agrega a cada uno de los grupos de recursos de los entornos de desarrollo y producción
con el rol de colaborador . Tal y como hemos visto, el rol de colaborador permite al usuario realizar
cualquier operación distinta de la asignación de un rol a otro usuario. Ahora, el primer propietario de
carga de trabajo puede crear los recursos asociados con la carga de trabajo.
6. El primer propietario de carga de trabajo crea una red virtual en cada uno de los dos grupos de recursos
con un par de máquinas virtuales en cada una. El primer propietario de carga de trabajo aplica las
etiquetas environment y managedBy a todos los recursos. Tenga en cuenta que el contador de límite de
servicio de Azure ahora está en 997 redes virtuales restantes.
7. Ninguna de las redes virtuales tiene conectividad local cuando se crean. En este tipo de arquitectura, se debe
emparejar cada red virtual con la red hub-vnet en el entorno de la infraestructura compar tida . El
emparejamiento de redes virtuales crea una conexión entre dos redes virtuales diferentes y permite que el
tráfico de red viaje entre ellas. Tenga en cuenta que el emparejamiento de redes virtuales no es
intrínsecamente transitivo. Un emparejamiento debe especificarse entre las dos redes virtuales que están
conectadas y, si solo una de las redes virtuales especifica un emparejamiento, entonces la conexión está
incompleta. Para mostrar este efecto, el primer propietario de carga de trabajo especifica un
emparejamiento entre prod-vnet y hub-vnet . Se crea el primer emparejamiento, pero el tráfico no circula
porque el emparejamiento complementario de hub-vnet a prod-vnet todavía no se ha especificado. El
primer propietario de carga de trabajo se pone en contacto con el usuario de operaciones de red y
solicita esta conexión de emparejamiento complementaria.
8. El usuario de operaciones de red revisa la solicitud, la aprueba y luego especifica el emparejamiento en la
configuración de hub-vnet . La conexión de emparejamiento ya está completa y el tráfico de red circula entre
las dos redes virtuales.
9. Ahora, el segundo propietario de carga de trabajo envía una solicitud al administrador de ser vicios
de suscripción y se agrega a los grupos de recursos existentes en los entornos de desarrollo y
producción con el rol de colaborador . El segundo propietario de carga de trabajo tiene los mismos
permisos en todos los recursos que el primer propietario de carga de trabajo en cada grupo de recursos.
10. El segundo propietario de carga de trabajo crea una subred en la red virtual prod-vnet y luego agrega
dos máquinas virtuales. El segundo propietario de carga de trabajo aplica las etiquetas environment y
managedBy a todos los recursos.
Este modelo de administración de recursos de ejemplo permite administrar los recursos en los tres entornos
necesarios. Los recursos de la infraestructura compartida están protegidos porque hay un único usuario en la
suscripción con permisos para acceder a esos recursos. Cada uno de los propietarios de cargas de trabajo puede
utilizar los recursos de la infraestructura compartida sin tener permisos en los recursos compartidos en sí. Este
modelo de administración no cumple el requisito de aislamiento de las cargas de trabajo; los dos propietarios
de cargas de trabajo pueden acceder a los recursos de la carga de trabajo del otro.
Hay otra consideración importante con este modelo puede no resultar obvio a simple vista. En el ejemplo, el
propietario de carga de trabajo app1 solicitó la conexión de emparejamiento de red con la red virtual
hub-vnet para proporcionar conectividad a la red local. El usuario de operaciones de red evaluó la solicitud
según los recursos implementados con esa carga de trabajo. Cuando la cuenta de propietario de la
suscripción agregó al propietario de carga de trabajo app2 con el rol de colaborador , ese usuario tenía
derechos de acceso de administración a todos los recursos del grupo de recursos prod-rg .
Esto significa que el propietario de carga de trabajo app2 tenía permisos para implementar su propia
subred con máquinas virtuales en la red virtual prod-vnet . De forma predeterminada, esas máquinas virtuales
tienen acceso a la red local. El usuario de operaciones de red no es consciente de esas máquinas y no aprobó
su conectividad al entorno local.
Ahora, veamos a un única suscripción con varios grupos de recursos para diferentes entornos y cargas de
trabajo. Tenga en cuenta que, en el ejemplo anterior, los recursos de cada entorno se podían identificar
fácilmente porque estaban en el mismo grupo de recursos. Ahora que ya no tenemos esa agrupación, tenemos
que utilizar una convención de nomenclatura en el grupo de recursos para proporcionar esa funcionalidad.
1. Los recursos de la infraestructura compar tida seguirán teniendo un grupo de recursos independiente en
este modelo, por lo que esta parte sigue igual. Cada carga de trabajo requiere dos grupos de recursos, uno
para cada uno de los entornos de desarrollo y producción . Para la primera carga de trabajo, la cuenta del
propietario de la suscripción crea dos grupos de recursos. El primero se denomina app1-prod-rg y el
segundo app1-dev-rg . Tal y como se indicó anteriormente, esta convención de nomenclatura identifica los
recursos como asociados con la primera carga de trabajo, app1 , y el entorno de desarrollo o producción .
Una vez más, la cuenta del propietario de la suscripción agrega el propietario de carga de trabajo
app1 al grupo de recursos con el rol de colaborador .
2. De forma similar al primer ejemplo, el propietario de carga de trabajo app1 implementa una red virtual
llamada app1-prod-vnet en el entorno de producción , y otra llamada app1-dev-vnet en el entorno de
desarrollo . Una vez más, el propietario de carga de trabajo app1 envía una solicitud al usuario de
operaciones de red para crear una conexión de emparejamiento. Tenga en cuenta que el propietario de
carga de trabajo app1 agrega las mismas etiquetas que en el primer ejemplo, y el límite de contadores se
ha reducido a 997 redes virtuales disponibles en la suscripción.
3. La cuenta del propietario de la suscripción ahora crea dos grupos de recursos para el propietario de
carga de trabajo app2 . Siguiendo las mismas convenciones que para el propietario de carga de
trabajo app1 , los grupos de recursos se llaman app2-prod-rg y app2-dev-rg . La cuenta del propietario de
la suscripción agrega el propietario de carga de trabajo app2 a cada uno de los grupos de recursos
con el rol de colaborador .
4. La cuenta del propietario de carga de trabajo app2 implementa las redes virtuales y las máquinas
virtuales en los grupos de recursos con las mismas convenciones de nomenclatura. Se agregan las etiquetas
y el contador de límite se ha reducido a 995 redes virtuales disponibles en la suscripción.
5. La cuenta del propietario de carga de trabajo app2 envía una solicitud al usuario de operaciones de
red para emparejar app2-prod-vnet con hub-vnet . El usuario de operaciones de red crea la conexión de
emparejamiento.
El modelo de administración resultante es similar al primer ejemplo, con algunas diferencias importantes:
Cada una de las dos cargas de trabajo se aísla por carga de trabajo y por entorno.
Este modelo requiere dos redes virtuales más que el primer ejemplo de modelo. Aunque esto no supone
mucha diferencia cuando solo hay dos cargas de trabajo, el límite teórico en el número de cargas de trabajo
en este modelo es 24.
Los recursos ya no se agrupan en un único grupo de recursos para cada entorno. Para agrupar los recursos
es necesario conocer las convenciones de nomenclatura que se usan en cada entorno.
El usuario de operaciones de red ha revisado y aprobado cada una de las conexiones de emparejamiento
de red virtual.
Veamos ahora un ejemplo de un modelo de administración de recursos con varias suscripciones. En este
modelo, alinearemos cada uno de los tres entornos con una suscripción diferente: una suscripción de ser vicios
compar tidos , una suscripción de producción y, por último, una suscripción de desarrollo . Las
consideraciones para este modelo son similares a las del modelo con una sola suscripción en el sentido de que
hay que decidir cómo alinear los grupos de recursos con las cargas de trabajo. Ya hemos determinado que crear
un grupo de recursos para cada carga de trabajo satisface el requisito de aislamiento de las cargas de trabajo,
por lo que nos quedaremos con ese modelo en este ejemplo.
1. En este modelo, hay tres suscripciones: infraestructura compar tida , producción y desarrollo . Cada
una de estas tres suscripciones requiere un propietario de la suscripción y, en el ejemplo sencillo,
usaremos la misma cuenta de usuario para las tres. Los recursos de la infraestructura compar tida se
administran de manera similar a los primeros dos ejemplos anteriores, y la primera carga de trabajo se
asocia con el grupo de recursos app1-rg en el entorno de producción y el segundo grupo de recursos
con el mismo nombre en el entorno de desarrollo . La cuenta del propietario de carga de trabajo
app1 se agrega a cada uno de los grupos de recursos con el rol de colaborador .
2. Al igual que en los ejemplos anteriores, el propietario de carga de trabajo app1 crea los recursos y
solicita la conexión de emparejamiento con la red virtual de la infraestructura compar tida . La cuenta
del propietario de carga de trabajo app1 agrega solo la etiqueta managedBy porque ya no se
necesita la etiqueta environment . Es decir, los recursos de cada entorno están agrupados en la misma
suscripción y la etiqueta environment es redundante. El contador de límite se reduce a 999 redes
virtuales disponibles.
3. Por último, la cuenta del propietario de la suscripción repite el proceso para la segunda carga de
trabajo, y agrega el propietario de carga de trabajo app2 a los grupos de recursos con el rol de
colaborador . El contador de límite para cada una de las suscripciones del entorno se reducido a 998
redes virtuales disponibles.
Este modelo de administración tiene las ventajas del segundo ejemplo anterior. La principal diferencia es que los
límites suponen un problema menor porque se extienden a dos suscripciones. El inconveniente es que los datos
de los costos que se controlan con las etiquetas se deben agregar a las tres suscripciones.
Por lo tanto, puede seleccionar cualquiera de estos dos ejemplos de modelos de administración de recursos
según la prioridad de sus requisitos. Si prevé que su organización no llegará a los límites de servicio para una
sola suscripción, puede utilizar una sola suscripción con varios grupos de recursos. Por el contrario, si su
organización anticipa muchas cargas de trabajo, puede ser mejor tener varias suscripciones para cada entorno.
Implementación del modelo de administración de recursos

Ha aprendido varios modelos diferentes para gobernar el acceso a los recursos de Azure. Ahora veremos los
pasos necesarios para implementar el modelo de administración de recursos con una suscripción para cada uno
de los entornos de infraestructura compar tida , producción y desarrollo con la guía de diseño. Tendremos
una cuenta de propietario de la suscripción para los tres entornos. Cada carga de trabajo se aislará en un
grupo de recursos y se agregará propietario de carga de trabajo con el rol de colaborador .
NOTE
Consulte Descripción del acceso a los recursos de Azure para más información sobre la relación entre las cuentas y las
suscripciones de Azure.
Siga estos pasos:

1. Cree una cuenta de Azure si su organización aún no tiene una. La persona que se suscribe a la cuenta de
Azure se convierte en el administrador de la cuenta de Azure y los responsables de su organización deben
seleccionar la persona que asumirá este rol. Esta persona será responsable de:
Crear suscripciones
Crear y administrar los inquilinos de Azure Active Directory (AD) que almacenan las identidades de
usuario de esas suscripciones
2. El equipo directivo de su organización decide quién es responsable de:
Administrar las identidades de usuario; de forma predeterminada, se crea un inquilino de Azure AD
cuando se crea la cuenta de Azure de su organización y el administrador de la cuenta se agrega como
administrador global de Azure AD. Su organización puede elegir que otro usuario administre las
identidades de usuario; para ello, puede asignar el rol de administrador global de Azure AD para ese
usuario.
Suscripciones, lo que significa que estos usuarios son responsables de:
Administrar los costos asociados con el uso de recursos en esa suscripción
Implementar y mantener el modelo de permisos mínimos para el acceso a los recursos
Realizar un seguimiento de los límites de servicio.
Servicios de infraestructura compartida (si su organización decide usar este modelo), lo que significa
que este usuario es responsable de:
La conectividad del entorno local a la red de Azure.
La propiedad de la conectividad de red dentro de Azure mediante el emparejamiento de redes
virtuales.
Propietarios de cargas de trabajo.
3. El administrador global de Azure AD crea las cuentas de usuario nuevas para:
La persona que será el propietario de la suscripción para cada suscripción asociada con cada entorno.
Tenga en cuenta que esto es necesario solo si el administrador de ser vicios de la suscripción no
será responsable de administrar el acceso a los recursos para cada suscripción o entorno.
La persona que será el usuario de operaciones de red .
Las personas que serán propietarios de cargas de trabajo .
4. El administrador de cuenta de Azure crea tres suscripciones de Azure:
Una suscripción para el entorno de infraestructura compar tida .
Una suscripción para el entorno de producción .
Una suscripción para el entorno de desarrollo .
5. El administrador de la cuenta de Azure agrega el propietario del servicio de suscripción a cada suscripción.
6. Cree un proceso de aprobación para que propietarios de cargas de trabajo soliciten la creación de
grupos de recursos. El proceso de aprobación se puede implementar de muchas maneras, por ejemplo, por
correo electrónico, o bien puede usar una herramienta de administración de procesos como flujos de trabajo
de Sharepoint. El proceso de aprobación puede seguir estos pasos:
El propietario de la carga de trabajo prepara una lista de materiales de los recursos de Azure que
necesita en el entorno de desarrollo , de producción o ambos, y la envía al propietario de la
suscripción .
El propietario de la suscripción revisa la lista de materiales y valida los recursos solicitados para
asegurarse de que son los adecuados para el uso previsto; por ejemplo, comprueba que los tamaños
de máquina virtual solicitados sean los correctos.
Si no se aprueba la solicitud, el propietario de la carga de trabajo recibe una notificación. Si se
aprueba la solicitud, el propietario de la suscripción crea el grupo de recursos solicitado según las
convenciones de nomenclatura de la organización, agrega el propietario de carga de trabajo con
el rol de colaborador y notifica al propietario de la carga de trabajo que se ha creado el grupo
de recursos.
7. Crear un proceso de aprobación para que los propietarios de cargas de trabajo soliciten una conexión de
emparejamiento de red virtual desde el propietario de la infraestructura compartida. Al igual que con el paso
anterior, este proceso de aprobación se puede implementar mediante correo electrónico o con una
herramienta de administración de procesos.
Ahora que ha implementado el modelo de gobernanza, puede implementar los servicios de infraestructura
compartida.
Roles integrados en los recursos de Azure
Introducción a la materia de aceleración de la
implementación
La aceleración de la implementación es una de las cinco materias de la gobernanza en la nube dentro del
modelo de gobernanza de Cloud Adoption Framework. Esta materia se centra en las distintas maneras de
establecer directivas para gobernar la configuración o implementación de recursos. Dentro de las cinco materias
de la gobernanza en la nube, la materia de la aceleración de la implementación incluye la implementación, la
alineación de la configuración y la reutilización de scripts. Esto se puede realizar a través de actividades
manuales o de actividades de DevOps completamente automatizadas. En cualquier caso, las directivas seguirían
siendo en gran medida las mismas. A medida que madura esta materia, el equipo de gobernanza en la nube
puede actuar como asociado en las estrategias de DevOps y de implementación al acelerar las
implementaciones y eliminar los obstáculos para la adopción de la nube, mediante la aplicación de recursos
reutilizables.
En este artículo se describe el proceso de aceleración de la implementación que una empresa experimenta
durante las fases de planeamiento, compilación, adopción y operación de implementación de una solución en la
nube. Es imposible que ningún documento recopile todos los requisitos para ninguna empresa. Por lo tanto,
cada sección de este artículo describe actividades posibles y mínimas sugeridas. El objetivo inicial de estas
actividades es ayudarle a crear un MVP de directivas, pero establecer un marco para la mejora de directivas
incrementales. El equipo de gobernanza en la nube debe decidir cuánto invertir en estas actividades para
mejorar la posición de la aceleración de la implementación.
NOTE
La materia de aceleración de la implementación no reemplaza los procedimientos, procesos y equipos de TI existentes que
permiten a su organización implementar y configurar de manera eficaz los recursos basados en la nube. El principal
objetivo de esta materia es identificar posibles riesgos empresariales y proporcionar orientación en mitigación de riesgos
al personal de TI responsable de la administración de sus recursos en la nube. A medida que desarrolla procesos y
directivas de gobernanza, asegúrese de implicar a los equipos de TI pertinentes en sus procesos de revisión y planeación.
La principal audiencia a la que se dirigen estas instrucciones son los arquitectos de nube de su organización y
otros miembros de su equipo de gobernanza en la nube. Las decisiones, las directivas y los procesos que
emergen de esta materia deben implicar la involucración y los debates con miembros pertinentes de los
equipos de TI y la empresa, especialmente aquellos directores responsables de la implementación y
configuración de cargas de trabajo basadas en la nube.
Policy statements
Las instrucciones accionables de las directivas y los requisitos de arquitectura resultantes actúan como base de
una materia de aceleración de la implementación. Use instrucciones de directiva de ejemplo como punto de
partida para definir las directivas de aceleración de la implementación.
Cau t i on

Los siguientes pasos le ayudarán a definir las directivas de gobernanza para controlar la implementación y
configuración de recursos en un entorno de nube.
Plantilla de la materia de aceleración de la implementación:

Descargue la plantilla para documentar una materia de
aceleración de la implementación.

asociados normalmente a la materia de aceleración de la
implementación.




implementar para admitir la materia de aceleración de la
implementación.
Pasos siguientes
Plantilla de aceleración de la implementación
procedimientos de gobernanza. La plantilla siguiente proporciona un punto de partida para documentar y
comunicar las declaraciones de la directiva que rigen los problemas de configuración e implementación en la
nube. La plantilla también describe los criterios empresariales que podrían haberle llevado a redactar las
declaraciones de directiva documentadas.
para definir las declaraciones de las directivas de aceleración de la implementación de la organización.
IMPORTANT
Esta plantilla es un ejemplo limitado. Antes de actualizar la plantilla para que incluya sus requisitos, debe revisar los pasos
posteriores para definir una materia sobre la aceleración de la implementación eficaz dentro de su estrategia de
gobernanza de la nube.
Descargar la plantilla de la materia de aceleración de la implementación
Pasos siguientes
de la nube actual.
de aceleración de la implementación
En este artículo se describen las razones por las que los clientes normalmente adoptan la materia sobre la
aceleración de la implementación dentro de una estrategia de gobernanza de la nube. También se proporcionan
algunos ejemplos de riesgos empresariales que impulsan las declaraciones de directiva.
Relevancia
Los sistemas locales a menudo se implementan mediante imágenes de base referencia o scripts de instalación.
Por lo general, es necesaria una configuración adicional, que puede implicar múltiples pasos o la intervención
humana. Estos procesos manuales son propensos a errores y a menudo dan lugar a un "desfase de
configuración", lo que requiere tareas de solución de problemas y de corrección que necesitan mucho tiempo.
La mayoría de los recursos de Azure se pueden implementar y configurar manualmente mediante Azure Portal.
Este enfoque puede ser suficiente para sus necesidades cuando solo tiene unos pocos recursos para administrar.
A medida que el patrimonio en la nube crece, su organización debe comenzar a integrar funciones de
automatización en los procesos de implementación para garantizar que no ocurre un desfase de configuración
de los recursos en la nube u otros problemas que presentan los procesos manuales. Adoptar un enfoque
DevOps o DevSecOps suele ser la mejor manera de administrar las implementaciones cuando la adopción de la
nube está en una fase más avanzada.
Un sólido plan de aceleración de la implementación garantiza que los recursos de nube se implementen,
actualicen y configuren de forma correcta y coherente, y que permanezcan así. La madurez de la estrategia de
aceleración de la implementación también puede ser un factor significativo en la estrategia de administración de
costos. El aprovisionamiento y la configuración automatizados de los recursos de nube le permiten reducir o
desasignar los recursos cuando la demanda es baja o está limitada en el tiempo, por lo que solo paga por los
recursos cuando los necesita.
Riesgo empresarial
La material sobre la aceleración de la implementación intenta abordar los siguientes riesgos empresariales.
Durante la adopción de la nube, supervise cada uno de los siguientes aspectos para determinar su relevancia:
Interrupción del ser vicio. La falta de procesos de implementación predecibles y repetibles o de cambios
no administrados en las configuraciones del sistema puede interrumpir las operaciones normales y provocar
una pérdida de productividad o de negocio.
Sobrecostos: Los cambios inesperados en la configuración de los recursos del sistema pueden dificultar la
identificación de la causa raíz de los problemas, lo que aumenta los costos de desarrollo, operaciones y
mantenimiento.
Ineficacias de la organización: Las barreras entre los equipos de desarrollo, operaciones y seguridad
pueden causar numerosos desafíos para la adopción efectiva de las tecnologías de nube y el desarrollo de un
modelo unificado de gobernanza de la nube.
Pasos siguientes
Use la plantilla de la materia de aceleración de la implementación para documentar los riesgos empresariales
que es probable que se introduzcan debido al plan actual de adopción de la nube.
tolerancia.
Métricas, indicadores y tolerancia al riesgo
Métricas e indicadores de la tolerancia al riesgo de
la materia de aceleración de la implementación
Aprenda a cuantificar la tolerancia al riesgo empresarial asociada a la materia de aceleración de la

implementación. La definición de métricas e indicadores ayuda a crear un caso empresarial para invertir en la
madurez de esta materia.
Métricas
La aceleración de la implementación se centra en los riesgos relacionados con la configuración, implementación,
actualización y mantenimiento de los recursos en la nube. La siguiente información es útil al adoptar la materia
de aceleración de la implementación:
Errores de implementación. Porcentaje de implementaciones que generan errores o producen recursos
mal configurados.
Tiempo de implementación. La cantidad de tiempo que se necesita para implementar las actualizaciones
en un sistema existente.
Recursos fuera de cumplimiento. El número o porcentaje de recursos que no cumplen con las directivas
definidas.

Los riesgos relacionados con la aceleración de la implementación están, en gran medida, relacionados con el
número y la complejidad de los sistemas basados en la nube implementados para la empresa. A medida que
crece su entorno de nube, aumentará el número de sistemas implementados y la frecuencia de actualización de
los recursos de nube. Las dependencias entre recursos aumentan la importancia de garantizar la correcta
configuración de los recursos y el diseño de los sistemas para lograr resistencia si uno o varios recursos
experimentan tiempos de inactividad inesperados.
A menudo, las organizaciones de TI corporativas tradicionales han aislado las operaciones, la seguridad y los
equipos de desarrollo que no suelen colaborar o que incluso se encuentran enfrentados. Reconocer estos
desafíos al principio e integrar partes interesadas clave de cada uno de los equipos puede ayudar a garantizar la
agilidad en la adopción de la nube, mientras permanecen protegidos y bien controlados. Por tanto, considere la
posibilidad de adoptar una cultura organizativa DevOps o DevSecOps al principio del proceso de adopción de la
nube.
Trabaje con el equipo de DevSecOps y las partes interesadas de la empresa para identificar los riesgos del
negocio relacionados con la configuración, luego determine una línea de base aceptable para la tolerancia al
riesgo de la configuración. En esta sección de la guía Cloud Adoption Framework se proporcionan ejemplos,
pero los riesgos y las bases de referencia específicos de su empresa o sus implementaciones serán diferentes.
relacionadas con la configuración, como las descritas anteriormente, pueden justificar una mayor inversión en la
disciplina de aceleración de la implementación.
Desencadenadores de desfase de configuración: Una compañía que experimente cambios inesperados
en la configuración de los componentes clave del sistema o errores en la implementación o las
actualizaciones de sus sistemas, debe invertir en la disciplina de aceleración de la implementación para
identificar las causas raíz y los pasos de corrección.
Desencadenadores de no cumplimiento: Si el número de recursos fuera de cumplimiento supera un
umbral definido (ya sea como un número total de recursos o un porcentaje del total de recursos), la
compañía debe invertir en mejoras de la disciplina de aceleración de la implementación para asegurarse de
que la configuración de cada recurso permanece en cumplimiento a lo largo del ciclo de vida de ese recurso.
Desencadenadores de programación de proyecto: Si el tiempo para implementar los recursos y
aplicaciones de la compañía suele superar un umbral definido, la compañía debe invertir en los procesos de
aceleración de la implementación para introducir o mejorar la coherencia y previsibilidad de las
implementaciones automatizadas. Los tiempos de implementación, medidos en días o incluso semanas,
suelen indicar una estrategia de aceleración de la implementación poco óptima.
Pasos siguientes
Use la plantilla de la materia de aceleración de la implementación para documentar las métricas y los
indicadores de tolerancia que se alinean con el plan actual de adopción de la nube.
Revise las directivas de aceleración de la implementación de ejemplo como punto de partida para desarrollar
sus propias directivas para abordar los riesgos empresariales específicos en línea con los planes de adopción de
la nube.
Declaraciones de la directiva de ejemplo de
aceleración de la implementación
relacionados con la configuración. Estas declaraciones son ejemplos a los que se puede hacer referencia al
elaborar el borrador de las declaraciones de directiva para satisfacer las necesidades de su organización. Estos
ejemplos no pretenden ser excluyentes y hay varias opciones posibles de directiva para solucionar cada riesgo
concreto identificado. Trabaje estrechamente con los equipos de TI y de dirección para identificar las mejores
directivas para su conjunto de riesgos en particular.
Dependencia de la configuración o implementación manual de

sistemas
Riesgo técnico: depender de la intervención humana durante la implementación o configuración aumenta la
probabilidad de error humano y reduce la repetibilidad y previsión de las implementaciones y la configuración
del sistema. Normalmente, también conlleva una implementación más lenta de los recursos del sistema.
Declaración de directiva : todos los recursos que se implementan en la nube deben implementarse mediante
plantillas o scripts de automatización siempre que sea posible.
Opciones de diseño posibles: las plantillas de Azure Resource Manager permiten usar infraestructura como
código para implementar los recursos en Azure. También puede usar Terraform como una herramienta de
implementación coherente tanto local como basada en la nube.
Falta de visibilidad de los problemas del sistema

Riesgo técnico: una supervisión y un diagnóstico insuficientes de los sistemas empresariales impiden al
personal de operaciones identificar y corregir problemas antes de que se produzca una interrupción del sistema,
lo que puede aumentar considerablemente el tiempo necesario para resolver correctamente una interrupción.
Se identificarán medidas de diagnóstico y métricas clave para todos los sistemas de producción y los
componentes, y se aplicarán herramientas de supervisión y diagnóstico a estos sistemas, que el personal de
operaciones se encargará de supervisar regularmente.
El personal de operaciones considerará la opción de usar las herramientas de supervisión y diagnóstico en
entornos que no sean de producción, como ensayo y control de calidad, a fin de identificar los problemas del
sistema antes de que se produzcan en el entorno de producción.
Opciones de diseño posibles: Azure Monitor, que incluye Log Analytics y Application Insights, proporciona
herramientas para recopilar y analizar datos de telemetría para ayudarle a comprender cómo funcionan las
aplicaciones e identificar proactivamente los problemas que les afectan y los recursos de los que dependen.
Además, el registro de actividad de Azure notifica todos los cambios que se realizan en la plataforma y que se
deben supervisar y auditar para detectar cambios no compatibles.
Revisiones de seguridad de configuración

Riesgo técnico: con el tiempo, los nuevos problemas y amenazas de seguridad pueden aumentar los riesgos
de acceso no autorizado a recursos seguros.
Declaración de directiva : los procesos de gobernanza de la nube deben incluir revisiones mensuales con los
equipos de administración de configuración para así poder identificar usuarios malintencionados o patrones de
uso que deban evitarse mediante la configuración de recursos en la nube.
Opciones de diseño posibles: celebrar una reunión de revisión de seguridad mensual en la que participen
los miembros del equipo de gobernanza y el personal de TI responsable de los recursos y las aplicaciones de
configuración en la nube. Revisar las métricas y los datos de seguridad existentes para identificar deficiencias en
las herramientas y la directiva de aceleración de la implementación y actualizar la directiva para remediar todos
los nuevos riesgos.
Pasos siguientes
identidad, descargue la plantilla de la materia de base de referencia de identidad.
A partir de los riesgos y la tolerancia, establezca un proceso para regular y comunicar la adhesión a la directiva
de aceleración de la implementación.
Procesos de cumplimiento de directivas de
aceleración de la implementación
aceleración de la implementación. Una gobernanza efectiva de la configuración en la nube comienza con los
procesos manuales periódicos diseñados para detectar problemas e imponer directivas para remediar los
riesgos. Puede automatizar estos procesos y complementarlos para reducir la sobrecarga de gobernanza y
permitir una respuesta más rápida a las desviaciones.

Las mejores herramientas de aceleración de la implementación en la nube son solo tan buenas como los
procesos y directivas que admiten. El siguiente es un conjunto de procesos de ejemplo que se utilizan
normalmente como parte de la materia de aceleración de la implementación. Use estos ejemplos como punto
de partida al planear los procesos que le permitirán continuar actualizando la directiva de implementación y
configuración en función de los cambios del negocio y los comentarios de los equipos de seguridad y TI
responsables de poner en práctica la guía de gobernanza.
Planeamiento y evaluación inicial de los riesgos: Como parte de la adopción inicial de la disciplina de
aceleración de la implementación, identifique los riesgos y tolerancias principales del negocio, relacionados con
la implementación de las aplicaciones empresariales. Use esta información para analizar los riesgos técnicos
específicos con los miembros del equipo de operaciones de TI. Desarrolle una base de referencia de directivas
de implementación y configuración para remediar estos riesgos y establecer la estrategia de gobernanza inicial.
Planeación de la implementación: antes de implementar cualquier recurso, realice una revisión de la
seguridad y las operaciones para identificar nuevos riesgos y asegurarse de que se cumplen todos los requisitos
de la directiva de implementación.
Pruebas de la implementación: como parte del proceso de implementación para cualquier recurso, el
equipo de gobernanza de la nube, en colaboración con los equipos de operaciones de TI, es el responsable de
revisar el cumplimiento de la directiva de implementación.
Planeación anual: Lleve a cabo una revisión anual de nivel superior de la estrategia de aceleración de la
implementación. Explore las prioridades corporativas futuras y las estrategias de adopción de la nube
actualizadas para identificar un posible aumento del riesgo y otras necesidades y oportunidades de
configuración emergentes. También puede usar este tiempo para revisar los procedimientos recomendados de
DevOps e integrarlos en sus directivas y procesos de revisión.
Planeamiento y revisión trimestrales: realice una revisión trimestral de los datos de auditoría de las
operaciones y los informes de incidentes para identificar los cambios necesarios en la directiva de aceleración
de la implementación. Como parte de este proceso, revise los procedimientos recomendados actuales de
DevOps y devtechops y actualice la directiva según corresponda. Una vez completada la revisión, alinee la guía
de diseño de sistemas y aplicaciones con la directiva actualizada.
de gobernanza de la nube, por si hubiera carencias de conocimientos relacionadas con la directiva nueva o
cambiante, y los riesgos relacionados con DevOps y la aceleración de la implementación. Invite al personal de TI
pertinente a participar en las revisiones y el planeamiento como asesores técnicos temporales o miembros
permanentes del equipo.
Educación y aprendizaje: ofrezca sesiones de aprendizaje con carácter bimensual para asegurarse de que los
desarrolladores y el personal de TI están al día de los requisitos y la estrategia de aceleración de la
implementación más reciente. Como parte de este proceso, revise y actualice cualquier documentación, guía u
otros recursos de aprendizaje para asegurarse de que estén sincronizados con las declaraciones de directiva
corporativa más recientes.
Auditoría mensual y revisiones de informes: Realice una auditoría mensual en todas las implementaciones
de nube para garantizar su alineación continuada con la directiva de configuración. Revise las actividades
relacionadas con la implementación con el personal de TI e identifique los problemas de cumplimiento que aún
no se han abordado como parte del proceso continuo de supervisión y cumplimiento. El resultado de esta
revisión es un informe para el equipo de estrategia de la nube y cada equipo de adopción de la nube para
comunicar la adhesión general a la directiva. El informe también se almacena con fines de auditoría y legales.

Una la estrategia de aceleración de la implementación correcta depende de la visibilidad del estado actual y
pasado de la infraestructura en la nube. Sin la capacidad para analizar las métricas pertinentes y los datos del
estado de las operaciones y la actividad de los recursos en la nube, no se pueden identificar cambios en los
riesgos ni detectar infracciones de las tolerancias al riesgo. Los procesos de gobernanza en curso explicados
anteriormente requieren datos de calidad para asegurarse de que se puede modificar la directiva para proteger
la infraestructura contra amenazas y riesgos cambiantes de recursos mal configurados.
Asegúrese de que los equipos de operaciones de TI han implementado sistemas de supervisión automatizados
para la infraestructura en la nube que capturen los datos pertinentes de los registros que necesita para evaluar
los riesgos. Sea proactivo en la supervisión de estos sistemas para asegurar la pronta detección y mitigación de
posibles infracciones de la directiva de supervisión y que su estrategia de supervisión esté en línea con las
necesidades de implementación y configuración.

Dado que el incumplimiento de las directivas de configuración puede dar lugar a riesgos de interrupción de los
servicios críticos, el equipo de gobernanza de la nube debe tener visibilidad sobre las infracciones graves de la
directiva. Asegúrese de que el personal de TI tiene rutas de escalación claras para notificar problemas de
cumplimiento de la configuración a los miembros del equipo de gobernanza más adecuados para identificar y
comprobar que se han mitigado los problemas de la directiva cuando se han detectado.
El equipo de TI puede automatizar la mayoría de los desencadenadores de infracción con las herramientas
descritas en Deployment Acceleration toolchain for Azure (Cadena de herramientas de aceleración de la
implementación para Azure).
Los siguientes desencadenadores y acciones de cumplimiento son ejemplos que puede usar al analizar cómo
usar los datos de supervisión para resolver las infracciones de directivas:
Se han detectado cambios inesperados en la configuración. Si la configuración de un recurso cambia
de forma inesperada, trabaje con los propietarios de la carga de trabajo y el personal de TI para identificar la
causa raíz y desarrollar un plan de corrección.
La configuración de nuevos recursos no se adhiere a la directiva. Trabaje con los equipos de
DevOps y los propietarios de la carga de trabajo para revisar las directivas de aceleración de la
implementación durante el inicio del proyecto para que todos los implicados entiendan los requisitos
correspondientes de la directiva.
Los errores de implementación o problemas de configuración provocan retrasos en las
programaciones del proyecto. Trabaje con los equipos de desarrollo y los propietarios de la carga de
trabajo para asegurarse de que el equipo entienda cómo automatizar la implementación de recursos
basados en la nube para lograr coherencia y capacidad de repetición. Las implementaciones totalmente
automatizadas deben exigirse en una etapa temprana del ciclo de desarrollo. Tratar de hacerlo más adelante
suele provocar problemas inesperados y retrasos.
Pasos siguientes
Use la plantilla de la materia de aceleración de la implementación para documentar los procesos y los
los planes de adopción, consulte Mejora de la materia de aceleración de la implementación.
Mejora de la disciplina de aceleración de la implementación
Mejora de la disciplina de aceleración de la
implementación
La disciplina de aceleración de la implementación se centra en establecer directivas que aseguren que los
recursos se implementen y configuren de manera coherente y repetitiva, y que puedan cumplir los requisitos
establecidos durante todo su ciclo de vida. Dentro de las cinco materias de la gobernanza de la nube, la materia
de aceleración de la implementación incluye decisiones relacionadas con la automatización de
implementaciones, los artefactos de implementación que controlan el origen, la supervisión de los recursos
implementados para mantener el estado establecido y la auditoría de cualquier problema de cumplimiento.
y mejorar la materia sobre la aceleración de la implementación. Estas tareas se dividen en las fases de
planeamiento, compilación, adopción y funcionamiento de la implementación de una solución de nube que,

decidir cuánto invertir en estas actividades para mejorar la materia de base de referencia de identidad.
Cau t i on
nube.
Evalúe las opciones de su cadena de herramientas de aceleración de la implementación, e implemente una
estrategia híbrida que sea adecuada para su organización.
Entrene a los equipos de desarrollo y al personal de TI para que comprendan los principios y estrategias de
DevSecOps y la importancia de las implementaciones totalmente automatizadas de la materia de aceleración
de la implementación.
Defina los roles y asignaciones que regirán la aceleración de la implementación en la nube.

Para las nuevas aplicaciones basadas en la nube, introduzca implementaciones totalmente automatizadas al
principio del proceso de desarrollo. Esta inversión mejorará la confiabilidad de sus procesos de prueba y
garantizará la coherencia en sus entornos de desarrollo, el control de calidad y la producción.
Almacene todos los artefactos de implementación, como las plantillas de implementación o los scripts de
configuración, mediante una plataforma de control de origen como GitHub o Azure DevOps.
Almacene todos los secretos, contraseñas, certificados y cadenas de conexión en Azure Key Vault.
Considere la posibilidad de realizar una prueba piloto antes de implementar su cadena de herramientas para
la aceleración de la implementación; así se asegurará de que se optimizan sus implementaciones tanto como
sea posible. Aplique los comentarios de las pruebas piloto durante la fase previa a la implementación,
repitiendo el proceso según sea necesario.
Evalúe la arquitectura lógica y física de sus aplicaciones e identifique las oportunidades para automatizar la
implementación de los recursos de la aplicación o mejorar partes de la arquitectura con otros recursos
basados en la nube.
Actualice el documento de directrices de arquitectura para que incluya los planes de implementación y
adopción por parte del usuario, y distribúyalo a las principales partes interesadas.
A continuación, eduque a los usuarios y equipos a los que más afecten las directrices de la arquitectura.
Defina una canalización de integración e implementación continua (CI/CD) para administrar completamente
las actualizaciones de versión de la aplicación a través de los entornos de desarrollo, el control de calidad y la
producción.
Migre la cadena de herramientas para la aceleración de la implementación desde el entorno de desarrollo al
de producción.
Desarrolle materiales y documentación educativos, comunicaciones de reconocimiento, incentivos y otros
programas para ayudar a impulsar la adopción de TI y a los desarrolladores.
Compruebe que los procedimientos recomendados que se definieron durante las fases de compilación y
anterior a la implementación se ejecutan correctamente.
Cerciórese de que todas las aplicaciones o cargas de trabajo siguen alineadas con la estrategia de aceleración
de la implementación antes de la publicación.

Personalice la cadena de herramientas para la aceleración de la implementación según las necesidades de
cambio de la organización.
Automatice notificaciones e informes para que le avisen de posibles amenazas malintencionadas o
problemas con la configuración.
Supervise y envíe notificaciones sobre el uso de los recursos y la aplicación.
Informe sobre las métricas posteriores a la implementación y distribúyalas a las partes interesadas.
Revise las directrices de arquitectura para guiar los procesos de adopción futuros.
Continue comunicándose y capacitando a las personas y equipos afectados de manera regular para
garantizar el cumplimiento continuo de las directrices sobre la arquitectura.
Configure una herramienta de supervisión e información de la configuración de estado que quiera
establecer.
Revise periódicamente las herramientas de configuración y los scripts para mejorar los procesos e identificar
problemas comunes.
Trabaje con los equipos de desarrollo, operaciones y seguridad para mejorar las prácticas de DevSecOps y
ordenar la maraña organizativa que conduce a ineficiencias.
Pasos siguientes
Ahora que conoce el concepto de gobernanza de identidades en la nube, examine la cadena de herramientas de
la base de referencia de identidad para identificar las herramientas y características de Azure que necesitará al
desarrollar la materia sobre la base de referencia de la identidad en la plataforma Azure.
Cadena de herramientas de la línea de base de identidad para Azure
Herramientas de aceleración de la implementación
en Azure
La materia de aceleración de la implementación es una de las cinco materias de la gobernanza de la nube. Esta
materia se centra en las distintas maneras de establecer directivas para gobernar la configuración o
implementación de recursos. Dentro de las cinco materias de la gobernanza de la nube, la aceleración de la
implementación incluye la alineación de la implementación y la configuración. Esto se puede realizar a través de
actividades manuales o de actividades de DevOps completamente automatizadas. En cualquier caso, las
directivas implicadas seguirían siendo en gran medida las mismas.
Es probable que tanto los guardianes de la nube como los arquitectos de la nube interesados en su gobernanza
inviertan mucho tiempo en la materia sobre la aceleración de la implementación, que codifica las directivas y los
requisitos en diversos trabajos de adopción de la nube. Las herramientas de esta cadena de herramientas son
importantes para el equipo de gobernanza de la nube y deben tener una prioridad alta en la ruta de aprendizaje
del equipo.
A continuación, se muestra una lista de las herramientas de Azure que pueden ayudar a desarrollar las directivas
y los procesos que admiten esta materia.
GRUP O S DE
A DM IN IST RA A Z URE A Z URE A Z URE C O ST
A Z URE C IÓ N DE RESO URC E A Z URE RESO URC E M A N A GEM EN
P O L IC Y A Z URE M A N A GER B L UEP RIN T S GRA P H T + B IL L IN G
Implementa Sí No No No No No
ción de
directivas
corporativa
s
Aplicación Obligatorio Sí No No No No
de
directivas a
suscripcione
s
Implementa No No Sí No No Sin
ción de
recursos
definidos
Creación de Obligatorio Obligatorio Obligatorio Sí No No

entornos
totalmente
compatibles
Auditoría Sí No No No No No
de
directivas
GRUP O S DE
A DM IN IST RA A Z URE A Z URE A Z URE C O ST
A Z URE C IÓ N DE RESO URC E A Z URE RESO URC E M A N A GEM EN
P O L IC Y A Z URE M A N A GER B L UEP RIN T S GRA P H T + B IL L IN G
Consulta de No No No No Sí No
recursos de
Azure
Informe de No No No No No Sí
costo de
recursos
Las siguientes son herramientas adicionales que pueden ser necesarias para lograr objetivos específicos de
aceleración de la implementación. A menudo estas herramientas se usan fuera del equipo de gobernanza, pero
se consideran un aspecto de la materia de aceleración de la implementación.
A Z URE
A Z URE RESO URC E A Z URE A Z URE A Z URE A Z URE SIT E
P O RTA L M A N A GER P O L IC Y DEVO P S B A C K UP REC O VERY
Implementa Sí Sí No No es eficaz No Sí
ción manual
(un solo
recurso)
Implementa No es eficaz Sí No No es eficaz No Sí

ción manual
(entorno
completo)
Implementa No Sí No Sí No Sí
ción
automática
(entorno
completo)
Actualizació Sí Sí No es eficaz No es eficaz No Sí, durante la

n de la replicación
configuració
n de un
recurso
individual
Actualizació No es eficaz Sí Sí Sí No Sí, durante la

n de la replicación
configuració
n de un
entorno
completo
Administrac No es eficaz No es eficaz Sí Sí No Sí, durante la

ión de un replicación
desfase de
configuració
n
A Z URE
A Z URE RESO URC E A Z URE A Z URE A Z URE A Z URE SIT E
P O RTA L M A N A GER P O L IC Y DEVO P S B A C K UP REC O VERY
Creación de No No No Sí No No
una
canalización
automática
para la
implementa
ción de
código y la
configuració
n de
recursos
(DevOps)
Aparte de las herramientas nativas de Azure que se han mencionado, es habitual que los clientes usen
herramientas de terceros para facilitar la aceleración de la implementación y las implementaciones de DevOps.
Gobernanza de antipatrones
A menudo, los clientes experimentan antipatrones durante la fase de gobernanza de la adopción de la nube.
Dedicar tiempo a comprender las responsabilidades compartidas le ayuda a evitar estos antipatrones, ya que
crea su estrategia de seguridad según los marcos existentes en lugar de crear el suyo propio.
Antipatrón: malinterpretar las responsabilidades compartidas

Cuando adopte la nube, no siempre está claro dónde termina su responsabilidad y dónde comienza la
responsabilidad del proveedor de la nube con respecto a los diferentes modelos de servicio. Los conocimientos
y las aptitudes de la nube son necesarios para crear procesos y prácticas en relación con los elementos de
trabajo que usan modelos de servicio.
Ejemplo: suposición de que el proveedor de nube administra las actualizaciones
Los miembros del departamento de recursos humanos (RR. HH.) de una empresa configuran muchos
servidores Windows en la nube mediante la infraestructura como servicio (IaaS). Dan por sentado que el
proveedor de nube administra las actualizaciones, ya que el personal de TI local suele controlar la instalación de
actualizaciones. El departamento de RR. HH. no configura las actualizaciones porque no son conscientes de que
Azure no implementa ni instala las actualizaciones del sistema operativo de forma predeterminada. Como
resultado, los servidores no son compatibles y suponen un riesgo para la seguridad.
Resultado preferido: creación de un plan de preparación
Comprenda la responsabilidad compartida en la nube. Diseñe y elabore un plan de preparación. Un plan de
preparación puede ser un impulso continuo para aprender y desarrollar experiencia.
Antipatrón: suponer que las soluciones integradas proporcionan

seguridad
A menudo, las empresas perciben la seguridad como un elemento integrado en la nube. Aunque esta suposición
suele ser correcta, la mayoría de los entornos también deben satisfacer los requisitos del marco de
cumplimiento, que pueden diferir de los requisitos de seguridad. Azure proporciona seguridad básica. A través
de Azure Security Center, Azure Portal proporciona ayuda para mejorar la seguridad. Sin embargo, la aplicación
de un estándar de cumplimiento y seguridad no es una experiencia integrada cuando se crea una suscripción.
Ejemplo: negligencia de la seguridad de la nube
Una empresa desarrolla una nueva aplicación en la nube. Elige una arquitectura basada en muchos servicios de
plataforma como servicio (PaaS), además de algunos componentes de IaaS con fines de depuración. Después de
enviar la aplicación a producción, la empresa se da cuenta de que uno de sus servidores de salto estaba en
peligro y extraía datos en una dirección IP desconocida. La empresa detecta que el problema se encuentra en la
dirección IP pública del servidor de salto y en una contraseña fácil de adivinar. La compañía podría haber
evitado esta situación si se hubiera centrado más en la seguridad de la nube.
Resultado preferido: definición de una estrategia de seguridad en la nube
Defina una estrategia de seguridad de la nube adecuada. Para obtener más información, consulte Guía de
preparación de CISO para la nube y remita a su oficina de seguridad de la información (CISO) a esta guía. En
esta, se describen temas como los de recursos de la plataforma de seguridad, privacidad y controles,
cumplimiento y transparencia.
Obtenga información sobre las cargas de trabajo seguras en la nube en Azure Security Benchmark. Básese en
CIS Controls v7.1 del Center for Internet Security y en NIST SP800-53 del National Institute of Standards and
Technology, que abordan la mayoría de los riesgos y las medidas de seguridad.
Use Azure Security Center para identificar riesgos, adaptar los procedimientos recomendados y mejorar la
posición de seguridad de su empresa.
Implementar o apoye los requisitos de cumplimiento y seguridad automatizados específicos de la empresa
mediante Azure Policy y Azure Blueprints.
Antipatrón: usar un marco de cumplimiento o gobernanza

personalizado
La introducción de un marco personalizado de cumplimiento y gobernanza que no se basa en los estándares del
sector puede aumentar considerablemente el tiempo de adopción de la nube, ya que puede ser difícil convertir
el marco personalizado a la configuración de la nube. Este escenario puede aumentar el esfuerzo necesario para
convertir las medidas y los requisitos personalizados en controles de seguridad implementables. La mayoría de
las empresas deben satisfacer conjuntos similares de requisitos de seguridad y cumplimiento. Como resultado,
la mayoría de los marcos de seguridad y cumplimiento personalizados solo se diferencian ligeramente de los
marcos de cumplimiento actuales. Las empresas con requisitos de seguridad adicionales pueden considerar la
creación de nuevos marcos.
Ejemplo: uso de un marco de seguridad personalizado
La oficina CISO de una empresa asigna a los empleados de seguridad de TI la tarea de proporcionar una
estrategia y un marco de seguridad de la nube. En lugar de basarse en los estándares del sector, el
departamento de seguridad de TI crea un nuevo marco que se basa en la directiva de seguridad local actual.
Después de completar la directiva de seguridad de la nube, los equipos de AppOps y DevOps tienen dificultades
para implementar dicha directiva.
Azure ofrece una estructura de seguridad y cumplimiento más completa que difiere del marco de la empresa. El
equipo de CISO considera que los controles de Azure no son compatibles con sus propias reglas de
cumplimiento y seguridad. Si hubiera basado su marco en controles estandarizados, no habría llegado a esa
conclusión.
Resultado preferido: dependencia de marcos existentes
Use o desarrolle marcos existentes, como CIS Controls v7.1 o NIST SP800-53, antes de establecer o introducir
un marco de cumplimiento personalizado de la empresa. Los marcos existentes hacen que la transición a la
configuración de seguridad de la nube sea más sencilla y más mensurable. Busque más implementaciones de
marcos en la página Ejemplos de Azure Blueprints. Los planos técnicos para los marcos de cumplimiento
comunes también están disponibles para Azure.
Pasos siguientes
Adaptación de los roles, las aptitudes y los procesos existentes de la nube
Definición de una estrategia de seguridad
Administración de la nube en Cloud Adoption
Framework
Proporcionar una estrategia de nube requiere un planeamiento, una preparación y una adopción sólidos. Pero
es el funcionamiento continuo de los recursos digitales lo que produce unos resultados empresariales tangibles.
Sin un plan de operaciones confiables y bien administradas de las soluciones en la nube, esos esfuerzos
generarán resultados escasos. Los ejercicios siguientes ayudan a desarrollar los enfoques técnicos y
empresariales necesarios para proporcionar una administración de la nube que impulse las operaciones en
curso.
Introducción
Para prepararse para esta fase del ciclo de vida de la adopción de la nube, el marco sugiere los siguientes
ejercicios:
Definición de los compromisos empresariales: Documente las

cargas de trabajo admitidas para establecer los compromisos
operativos con la empresa y acordar las inversiones en
administración de la nube para cada carga de trabajo.
Establecimiento de una base de referencia de administración:

Defina los grados de importancia, las herramientas de
administración de la nube y los procesos necesarios para
ofrecer su compromiso mínimo con la administración de
operaciones.
Expansión de la base de referencia de administración: Según

los compromisos empresariales y las decisiones operativas,
saque el máximo partido a los procedimientos
recomendados que se incluyen para implementar las
herramientas necesarias de administración de la nube.
Operaciones avanzadas y principios de diseño: Es posible

que las plataformas o cargas de trabajo que necesiten un
mayor nivel de compromiso empresarial requieran una
revisión más profunda de la arquitectura para cumplir con
los compromisos de resistencia y confiabilidad.
En los pasos anteriores se crean enfoques prácticos para proporcionar la metodología de administración de
Tal y como se comentó en el artículo sobre alineación empresarial, no todas las cargas de trabajo son críticas.
Dentro de toda cartera hay distintos grados de necesidades de administración operativa. Los trabajos de
alineación empresarial ayudan a identificar el impacto empresarial y a negociar los costos de administración con
la empresa para garantizar el uso de los procesos y herramientas de administración operativa más adecuados.
La guía de la sección de administración de Cloud Adoption Framework sirve para dos fines:
Proporcionar ejemplos de enfoques prácticos de administración de operaciones que representan
experiencias comunes que los clientes encuentran a menudo.
Ayudarle a crear soluciones de administración personalizadas basadas en compromisos empresariales.
Este contenido está diseñado para su uso por parte del equipo de operaciones en la nube. También es
importante para los arquitectos de la nube que necesitan desarrollar una base sólida para las operaciones en la
nube o los principios de diseño.
El contenido de Cloud Adoption Framework afecta al negocio, a la tecnología y a la cultura de las empresas. Esta
sección de Cloud Adoption Framework interactúa considerablemente con los equipos de operaciones de TI,
gobernanza de TI, finanzas, responsables de línea de negocio, redes, identidad y adopción de la nube. Varias
dependencias de estos roles requieren un enfoque facilitador por parte de los arquitectos de la nube que usan
esta guía. La facilitación de estos equipos rara vez es una tarea única.
El arquitecto de la nube sirve como líder de pensamiento y facilitador para reunir a estas audiencias. El
contenido de esta colección de guías está diseñado para ayudar al arquitecto de la nube a facilitar la
conversación correcta, con la audiencia adecuada, para tomar las decisiones necesarias. La transformación
empresarial que potencia la nube depende de que el arquitecto de la nube sirva de guía en las decisiones tanto
de TI como de toda la empresa.
Cada una de las secciones de Cloud Adoption Framework representa una especialización o variante diferentes
del rol de arquitecto de la nube. Esta sección de Cloud Adoption Framework está diseñada para arquitectos de la
nube apasionados con las operaciones y con la administración de soluciones de implementación. Dentro de este
marco, se hace referencia a estos especialistas con frecuencia como operaciones en la nube o colectivamente
como equipo de operaciones en la nube.
Si desea seguir esta guía de principio a fin, este contenido ayuda a desarrollar una sólida estrategia de
operaciones en la nube. Estas instrucciones le guían mediante la teoría y la implementación de dicha estrategia.
También puede aplicar la metodología para establecer compromisos empresariales claros.
Guía de administración de Azure: Antes de
comenzar
Antes de comenzar
La guía de administración de Azure ayuda a los clientes de Azure a crear una línea de base de administración
para establecer la coherencia de los recursos en Azure. En esta guía se describen las herramientas básicas
necesarias para los entornos de producción de Azure, especialmente aquellos que hospedan información
confidencial. Para más información, procedimientos recomendados y consideraciones relacionadas con la
preparación del entorno en la nube, consulte la sección de preparación de Cloud Adoption Framework.
Ámbito de esta guía

Esta guía le enseña a establecer las herramientas necesarias para una línea de base de administración. En ella
también se describen las distintas formas de ampliar la línea de base o de crear resistencia más allá de esta.
Inventario y visibilidad: cree un inventario de recursos en varias nubes. Desarrolle la visibilidad del estado
de ejecución de cada recurso.
Cumplimiento operativo: establezca controles y procesos para asegurarse de que todos los estados están
configurados correctamente y de que se ejecutan en un entorno bien controlado.
Protección y recuperación: asegúrese de que todos los recursos administrados están protegidos y se
pueden recuperar mediante las herramientas de administración de la línea de base.
Opciones de línea de base mejorada: evalúe las incorporaciones comunes a la línea de base que puedan
satisfacer las necesidades empresariales.
Operaciones de la plataforma: amplíe la línea de base de administración con un catálogo de servicios
bien definido y plataformas administradas centralmente.
Operaciones con cargas de trabajo: amplíe la línea de base de administración para incluir la posibilidad
de centrarse en las cargas de trabajo críticas.
Línea de base de administración

Una línea base de administración es el conjunto mínimo de herramientas y procesos que se debe aplicar a todos
los recursos de un entorno. En la línea de base de administración se pueden incluir varias opciones adicionales.
En los siguientes artículos se aceleran las funcionalidades de administración de la nube, para lo que nos
centramos en las mínimas necesarias, en lugar de en todas las opciones disponibles.
El paso siguiente es Inventario y visibilidad.
Inventario y visibilidad en Azure
El Inventario y la visibilidad es la primera de tres disciplinas en una línea de base para la administración en la
nube.
Esta materia va en primer lugar porque es fundamental recopilar los datos operativos adecuados al tomar
decisiones sobre las operaciones. Los equipos de administración en la nube deben comprender lo que se está
administrando y el grado de funcionamiento de esos recursos. En este artículo se describen las diversas
herramientas que proporcionan un inventario y permiten ver el estado de ejecución del inventario.
Para cualquier entorno de nivel empresarial, en la tabla siguiente se describen los mínimos sugeridos para una
línea de referencia de administración.
P RO C ESO H ERRA M IEN TA P RO P Ó SITO
Supervisión del estado de los servicios Azure Service Health Mantenimiento, rendimiento y
de Azure diagnóstico de los servicios que se
ejecutan en Azure
Centralización de registros Log Analytics Registro central para todos los fines de
visibilidad
Centralización de la supervisión Azure Monitor Supervisión central de los datos

operativos y las tendencias
Inventario de máquina virtual y Change Tracking e Inventario Inventario de máquinas virtuales y

Change Tracking supervisión de cambios para el nivel de
SO invitado
Supervisión de la suscripción Registro de actividades de Azure Supervisión de los cambios en el nivel

de suscripción
Supervisión del sistema operativo Azure Monitor para VM Supervisión de los cambios y el
invitado rendimiento de las VM
Supervisión de redes Azure Network Watcher Supervisión de los cambios y el

rendimiento de la red
Supervisión de DNS DNS Analytics Seguridad, rendimiento y operaciones

de DNS

Azure Service Health proporciona una vista personalizada del estado de los servicios y regiones de Azure. La
información acerca de los problemas activos se publica en Azure Service Health, lo cual le ayudará a
comprender el efecto que tienen en los recursos. Las actualizaciones periódicas le mantendrán informado a
medida que se resuelven los problemas.
También se publican los eventos de mantenimiento planeado en Azure Service Health para proporcionarle
información sobre los cambios que pueden afectar a la disponibilidad de los recursos. Configure alertas de
Service Health para que le envíen notificaciones si se producen problemas en el servicio, mantenimientos
planeados o cualquier otro cambio que puedan afectar a los servicios y regiones de Azure.
Azure Service Health incluye:
Estado de Azure: una vista global del estado de los servicios de Azure.
Estado del ser vicio: una vista personalizada del estado de los servicios de Azure.
Estado de los recursos: una vista más detallada del estado de los recursos individuales.
Acción
Para configurar una alerta de Service Health:
1. Vaya a Ser vice Health .
2. Seleccione Aler tas de estado .
3. Cree una alerta de Service Health.
G O TO S E R V I C E
H E A LTH
Para configurar las alertas de Service Health, vaya a Azure Portal.

Más información
Para obtener más información, consulte Azure Service Health.
Log Analytics
Log Analytics
Un área de trabajo de Log Analytics es un entorno único para almacenar los datos de registro de Azure Monitor.
Cada área de trabajo tiene su propio repositorio y configuración de datos. Los orígenes de datos y las soluciones
se configuran para almacenar sus datos en áreas de trabajo determinadas. Las soluciones de supervisión de
Azure requieren que todos los servidores se conecten a un área de trabajo, para poder almacenar los datos de
registro y obtener acceso a ellos.
Acción
M O N I TO R
Más información
Para obtener más información, consulte la documentación para la creación de áreas de trabajo de Log Analytics.
Azure Monitor
Azure Monitor
Azure Monitor proporciona un único centro unificado para todos los datos de supervisión y diagnóstico en
Azure, además de ofrecer visibilidad sobre todos los recursos. Con Azure Monitor, puede buscar y corregir
problemas y optimizar el rendimiento. También puede comprender el comportamiento de los clientes.
Super vise y visualice las métricas: las métricas son valores numéricos disponibles en los recursos de
Azure. Ayudan a comprender el estado de los sistemas. Personalice los gráficos de los paneles y use los
libros para los informes.
Consulte y analice los registros: los registros incluyen los registros de actividad y los registros de
diagnóstico de Azure. Recopile registros adicionales de otras soluciones de supervisión y administración
para los recursos de nube o locales. Log Analytics proporciona un repositorio central para agregar todos
estos datos. Desde allí, puede ejecutar consultas para ayudar a solucionar problemas o para visualizar los
datos.
Configure aler tas y acciones: las alertas le notifican las condiciones críticas. Las acciones correctivas
se pueden tomar basándose en los desencadenadores de las métricas, los registros o los problemas de
estado del servicio. Puede configurar diferentes notificaciones y acciones, así como enviar datos a las
herramientas de administración de servicios de TI.
Acción
M O N I TO R
Comience a supervisar lo siguiente:

Aplicaciones
Contenedores
Máquinas virtuales
Redes
Para supervisar otros recursos, busque soluciones adicionales en Azure Marketplace.
Para explorar Azure Monitor, vaya a Azure Portal.
Más información
Para más información, consulte Documentación sobre Azure Monitor.
Incorporación de soluciones
Incorporación de soluciones
Para habilitar las soluciones, tiene que configurar el área de trabajo Log Analytics. Las VM de Azure y los
servidores locales incorporados obtienen las soluciones de las áreas de trabajo de Log Analytics a las que se
conectan.
Hay dos enfoques en la incorporación:
Una única máquina virtual
Toda la suscripción
Cada uno de los artículos le guía a través de una serie de pasos para incorporar las siguientes soluciones:
Solución Update Management
Solución Seguimiento de cambios e inventario
Registro de actividades de Azure
Agent Health para Azure Log Analytics
Evaluación de antimalware
Azure Monitor para máquinas virtuales
Cada uno de los pasos anteriores ayuda a establecer el inventario y la visibilidad.
Cumplimiento operativo en Azure
El cumplimiento operativo es la segunda materia en cualquier línea de referencia de administración en la nube.
La mejora del cumplimiento operativo reduce la probabilidad de una interrupción relacionada con el desfase en
la configuración o vulnerabilidades relacionadas con sistemas que se han revisado de forma incorrecta.
Para cualquier entorno de nivel empresarial, en esta tabla se describen los mínimos sugeridos para una línea de
referencia de administración.
Administración de revisiones Update Management en Azure Administración y programación de

Automation actualizaciones
Aplicación de directivas Azure Policy Aplicación de directivas para garantizar

el cumplimiento del entorno y el
invitado
Configuración del entorno Azure Blueprint Compatibilidad automatizada para

servicios principales
Configuración de recurso Configuración de estado deseado Configuración automatizada en el

sistema operativo invitado y algunos
aspectos del entorno
Administración de actualizaciones
Los equipos administrados por la Update Management para Azure Automation usan las siguientes
configuraciones para evaluar e implementar actualizaciones:
Microsoft Monitoring Agent (MMA) para Windows o Linux
Configuración de estado deseado (DSC) de PowerShell para Linux
Hybrid Runbook Worker de Azure Automation.
Microsoft Update o Windows Server Update Services (WSUS) para equipos Windows
Para más información, consulte Solución Update Management para Update Management.
WARNING
Antes de usar Update Management, debe incorporar máquinas virtuales o una suscripción completa en Log Analytics y
Azure Automation.
Hay dos enfoques en la incorporación:
Una única máquina virtual
Toda la suscripción
Debe seguir uno para poder continuar con Update Management.
Para aplicar una directiva a un grupo de recursos:
1. Vaya a Azure Automation.
2. Seleccione Cuentas de Automation y elija una de las cuentas de la lista.
3. Diríjase a Administración de configuración .
4. Inventario , Administración de cambios y State Configuration pueden usarse para controlar el estado
y el cumplimiento operativo de las VM administradas.
AS S IG N
PO LIC Y
Azure Policy
Azure Policy
Azure Policy se utiliza en los procesos de gobierno. También es muy útil en los procesos de administración en la
nube. Azure Policy puede auditar y corregir los recursos de Azure, además de auditar la configuración en una
máquina. La validación se realiza mediante el cliente y la extensión Guest Configuration. La extensión, a través
del cliente, valida opciones de configuración como:
Configuración del sistema operativo.
Configuración o presencia de la aplicación.
Configuración del entorno.
Actualmente, la configuración de invitado de Azure Policy solo realiza la auditoría de la configuración dentro de
la máquina. No aplica configuraciones.
Acción
Asigne una directiva integrada a un grupo de administración, suscripción o grupo de recursos.
AS S IG N
PO LIC Y
Aplicación de una directiva

Para aplicar una directiva a un grupo de recursos:
1. Vaya a Azure Policy.
2. Seleccione Asignar una directiva .
Más información
Azure Policy
Azure Policy: Configuración de invitado
Guía de decisiones sobre el cumplimiento de directivas de Cloud Adoption Framework
Azure Blueprint
Azure Blueprints
Con Azure Blueprints, los arquitectos de la nube y los grupos de TI central pueden definir un conjunto repetible
de recursos de Azure. Estos recursos implementan y cumplen los estándares, patrones y requisitos de una
organización.
Con Azure Blueprints, los equipos de desarrollo pueden crear y erigir rápidamente nuevos entornos. Los
equipos también pueden tener la certeza de que actúan en conformidad con la organización. Para ello, usan un
conjunto de componentes integrados como redes para acelerar el desarrollo y la entrega.
Los planos técnicos son una manera declarativa de organizar la implementación de distintas plantillas de
recursos y de otros artefactos, como son:
Asignaciones de roles.
Asignaciones de directivas.
Grupos de recursos.
La aplicación de un plano técnico puede exigir el cumplimiento operativo en un entorno, si aún no lo exige el
equipo de gobernanza de la nube.
Creación de un plano técnico
Para crear un plano técnico, realice el siguiente procedimiento:
1. Vaya a Planos técnicos: Introducción .
2. En el panel Crear un plano técnico , seleccione Crear .
4. En el cuadro Nombre del plano técnico , escriba el nombre del plano técnico.
5. Seleccione Ubicación de definición y elija la ubicación correspondiente.
6. Seleccione Siguiente: Ar tefactos y revise los artefactos incluidos en el plano técnico.
C R E ATE A
B LU E PR INT
1. Vaya a Planos técnicos: Introducción.

2. En el panel Crear un plano técnico , seleccione Crear .
4. En el cuadro Nombre del plano técnico , escriba el nombre del plano técnico.
5. Seleccione Ubicación de definición y elija la ubicación correspondiente.
6. Seleccione Siguiente: Ar tefactos y revise los artefactos incluidos en el plano técnico.
Publicación de un plano técnico
Para publicar artefactos de plano técnico en su suscripción, haga lo siguiente:
1. Vaya a Planos técnicos - Definiciones del plano técnico .
4. En el cuadro Versión , escriba una versión, como "1.0".
5. En el cuadro Notas de cambios , introduzca sus notas.
6. Seleccione Publicar .
B LU E PR INT
D E F I N I TI O N S
1. En Azure Portal, vaya a Instancias de Blueprint: Definiciones del plano técnico.

4. En el cuadro Versión , escriba una versión, como "1.0".
5. En el cuadro Notas de cambios , introduzca sus notas.
6. Seleccione Publicar .
Más información
Azure Blueprints
Guía de decisiones de la coherencia de recursos de Cloud Adoption Framework
Ejemplos de planos técnicos basados en estándares
Protección y recuperación en Azure
La materia de protección y recuperación es la tercera y última en cualquier base de referencia para la

administración en la nube.
En Cumplimiento operativo en Azure, el objetivo es reducir la probabilidad de una interrupción del negocio. El
artículo actual tiene el objetivo de reducir la duración y el impacto de las interrupciones que no se pueden evitar.
Para cualquier entorno de nivel empresarial, en esta tabla se describen los mínimos sugeridos para cualquier
base de referencia de administración:
Protección de datos Azure Backup Realizar copias de seguridad de los

datos y las máquinas virtuales en la
nube.
Protección del entorno Azure Security Center Reforzar la seguridad y proporcionar

protección contra amenazas avanzada
en todas las cargas de trabajo híbridas.
Azure Backup
Azure Backup
Con Azure Backup puede crear copias de seguridad de sus datos, así como protegerlos y recuperarlos, en la
nube de Microsoft. Azure Backup reemplaza su solución de copia de seguridad local o remota existente por una
solución basada en la nube. Esta nueva solución es confiable, segura y rentable. Azure Backup también puede
ayudar a proteger y recuperar los recursos locales a través de una solución coherente.
En el caso de los datos presentes en Azure, Azure Backup ofrece diversos niveles de protección. Por ejemplo,
para realizar copias de seguridad de partes importantes de la infraestructura de la nube, como Azure Virtual
Machines y Azure Files, ofrece copia de seguridad de máquinas virtuales de Azure y copia de seguridad de
archivos de Azure. Para otros componentes críticos, como bases de datos que se ejecutan en Azure Virtual
Machines, ofrece soluciones dedicadas de copia de seguridad de base de datos para SQL Server y SAP HANA
con un RPO mucho menor.
Revise la sección siguiente para ver la facilidad con la que puede habilitar la copia de seguridad de Azure Virtual
Machines.
Habilitación de la copia de seguridad de una máquina virtual de Azure
1. En Azure Portal, seleccione Máquinas vir tuales y, a continuación, seleccione la máquina virtual de la que
desea realizar la copia de seguridad.
2. En el panel Operaciones , seleccione Copia de seguridad .
3. Cree un almacén de Azure Recovery Services o seleccione uno existente.
4. Seleccione Crear una nueva directiva (o editar una) .
5. Configure la programación y el período de retención.
6. Seleccione Aceptar .
7. Seleccione Habilitar copia de seguridad .
G O TO V I R TU A L
M AC H INE S
Para más información acerca de Azure Backup, consulte Introducción a Azure Backup.
Azure Site Recovery

Azure Site Recovery
Azure Site Recovery es un componente esencial de la estrategia de recuperación ante desastres.

Site Recovery replica las VM y las cargas de trabajo que se hospedan en una región principal de Azure. Las
replica en una copia que se hospeda en una región secundaria. Cuando se produce una interrupción en la región
primaria, se realiza una conmutación por error en la copia que se ejecuta en la región secundaria. Después
puede seguir accediendo a sus aplicaciones y servicios desde allí. Este enfoque proactivo hacia la recuperación
puede reducir significativamente los tiempos de recuperación. Cuando el entorno de recuperación ya no es
necesario, el tráfico de producción puede revertirse al entorno original.
Replicación de una VM de Azure en otra región con Site Recovery
En los pasos siguientes se describe el proceso para usar Site Recovery servicio para la replicación de Azure a
Azure, que consiste en replicar una VM de Azure en otra región:
TIP
Los pasos exactos pueden diferir ligeramente según el escenario.
Habilitación de la replicación para la máquina virtual de Azure

1. En Azure Portal, seleccione Máquinas vir tuales y, después, la máquina virtual que desea replicar.
2. En el panel Operaciones , seleccione Recuperación ante desastres .
3. Seleccione Configurar la recuperación ante desastres > Región de destino y elija la región de destino
en la que quiere realizar la replicación.
4. Para esta guía de inicio rápido, acepte los valores predeterminados de todas las demás opciones.
5. Seleccione Habilitar replicación para habilitar la replicación de la máquina virtual.
G O TO V I R TU A L
M AC H INE S
Comprobación de la configuración
Cuando haya finalizado el trabajo de replicación, puede comprobar el estado de la replicación y probar la
implementación.
1. En el menú de la máquina virtual, seleccione Recuperación ante desastres .
2. Compruebe el estado de la replicación, los puntos de recuperación que se crearon y las regiones de origen y
destino en el mapa.
G O TO V I R TU A L
M AC H INE S
Más información
Información general sobre Azure Site Recovery
Replicación de una máquina virtual de Azure en otra región
Línea base de administración mejorada en Azure
Las tres primeras materias de administración de la nube describen una línea de base de administración. En los
artículos anteriores de esta guía se describe un producto mínimo viable (MVP) para servicios de administración
en la nube, lo que se conoce como "línea de referencia de administración". En este artículo se describen algunas
mejoras comunes de la línea base.
El propósito de una línea de referencia de administración es crear una oferta coherente que proporcione un
nivel mínimo de compromiso empresarial para todas las cargas de trabajo que se admiten. Con esta línea de
referencia de ofertas de administración repetibles comunes, el equipo puede ofrecer una administración
operativa altamente optimizada con una desviación mínima.
Sin embargo, podría ser necesario un mayor compromiso con la empresa más allá de la oferta estándar. La
imagen y la lista siguientes muestran tres maneras de ir más allá de la base de referencia de administración.
Línea de base de administración mejorada:

Agregue mejoras a la base de referencia de administración cuando la mayoría de las cargas de trabajo
de la cartera tengan un requisito compartido.
Compromisos empresariales mejorados mediante herramientas y procesos de operaciones nativos de
nube.
Las mejoras de base de referencia no deben tener ninguna influencia en la arquitectura de cargas de
trabajo específicas.
Operaciones con cargas de trabajo:
Mayor inversión por operaciones de carga de trabajo.
Mayor grado de resistencia.
Se sugiere para aproximadamente el 20 % de las cargas de trabajo que impulsan el valor empresarial.
Normalmente se reserva para cargas de trabajo de gran importancia o críticas.
Operaciones de la plataforma:
La inversión en operaciones se reparte entre varias cargas de trabajo.
Las mejoras de resistencia afectan a todas las cargas de trabajo que usan la plataforma definida.
Se sugieren para aproximadamente el 20 % de las plataformas que tienen una importancia crítica.
Normalmente se reservan para cargas de trabajo de importancia media a importancia crítica.
Ambas operaciones de carga de trabajo y plataforma requieren cambios en los principios de diseño y
arquitectura. Estos cambios pueden tardar un tiempo y generar mayores gastos de funcionamiento. Para reducir
el número de cargas de trabajo que requieren tales inversiones, una base de referencia de administración
mejorada puede proporcionar una mejora suficiente en el compromiso empresarial.
En esta tabla se describen algunos procesos, herramientas y posibles consecuencias comunes en las bases de
referencia de administración mejorada de los clientes:
M AT ERIA P RO C ESO H ERRA M IEN TA P O SIB L E IM PA C TO M Á S IN F O RM A C IÓ N
Inventario y Servicio Change Azure Resource Una mayor visibilidad Información general
visibilidad Tracking Graph de los cambios en los de Azure Resource
servicios de Azure Graph
puede ayudar a
detectar antes los
efectos negativos o a
remediarlos más
rápido.
Inventario y Integración de IT Service La conexión de ITSM Conector de

visibilidad administración de Management automatizada crea Administración de
servicios de TI (ITSM) Connector reconocimiento más servicios de TI
rápido. (ITSMC)
Cumplimiento Automatización de Azure Automation Automatiza el Consulte las

operativo operaciones cumplimiento secciones siguientes
operativo para
obtener una
respuesta más rápida
y precisa ante los
cambios.
Cumplimiento Automatización del Azure Automation Automatice el Consulte las

operativo rendimiento cumplimiento secciones siguientes
operativo con
expectativas de
rendimiento para
resolver problemas
comunes de escala o
tamaño específicos
del recurso.
M AT ERIA P RO C ESO H ERRA M IEN TA P O SIB L E IM PA C TO M Á S IN F O RM A C IÓ N
Cumplimiento Operaciones de nube Hybrid Runbook Automatiza Introducción a

operativo múltiple Worker de Azure operaciones en varias Hybrid Runbook
Automation nubes. Worker
Cumplimiento Automatización de Configuración de Configuración basada Información general

operativo invitados estado deseado en código de sobre DSC
(DSC) sistemas operativos
invitados para reducir
los errores y el
desfase de la
configuración.
Protección y Notificación de Azure Security Center Amplía la protección Consulte las

recuperación infracción para incluir secciones siguientes
desencadenadores de
recuperación ante
infracciones de
seguridad.
Azure Automation
Azure Automation
Azure Automation proporciona un sistema centralizado para la administración de controles automatizados. En

Azure Automation, puede ejecutar procesos de corrección, escala y optimización simples en respuesta a las
métricas del entorno. Estos procesos reducen la sobrecarga asociada con el procesamiento manual de
incidentes.
Lo más importante es que la corrección automatizada se puede ofrecer casi en tiempo real, lo que reduce
significativamente las interrupciones en los procesos empresariales. Un estudio de las interrupciones
empresariales más comunes identifica las actividades que podrían automatizarse dentro de su entorno.
Runbooks
La unidad básica de código para ofrecer corrección automatizada es un runbook. Los runbooks contienen las
instrucciones para corregir o recuperarse de un incidente.
Para crear o administrar runbooks:
1. Vaya a Azure Automation .
2. Seleccione Cuentas de Automation y elija una de las cuentas de la lista.
3. Diríjase a Automatización de procesos .
4. Con las opciones presentadas, puede crear o administrar runbooks, programaciones y otras funcionalidades
de corrección automatizadas.
G O TO A Z U R E
A U TO M ATI O N

Azure Security Center también desempeña un papel importante en su estrategia de protección y recuperación.
Le permite supervisar la seguridad de las máquinas, las redes, el almacenamiento, los servicios de datos y las
aplicaciones.
Azure Security Center proporciona detección de amenazas avanzada mediante análisis del comportamiento y
aprendizaje automático para ayudar a identificar las amenazas activas dirigidas a los recursos de Azure. También
proporciona protección contra amenazas, que bloquea el malware y otro código no deseado, y reduce la
superficie expuesta a los ataques por fuerza bruta y a otros ataques a la red.
Cuando Azure Security Center identifica una amenaza, desencadena una alerta de seguridad con los pasos que
debe seguir para responder a un ataque. También proporciona un informe con datos sobre la amenaza
detectada.
Azure Security Center se ofrece en dos niveles: Gratis y Estándar. Características como las recomendaciones de
seguridad están disponibles en el nivel Gratis. El nivel Estándar proporciona protección adicional, como
detección de amenazas avanzada y protección en las cargas de trabajo de nube híbrida.
Acción
Probar el nivel Estándar gratis durante los primeros 30 días
Después de habilitar y configurar las directivas de seguridad para los recursos de una suscripción, puede ver el
estado de seguridad de los recursos y cualquier problema en el panel Prevención . Una lista de dichos
problemas también se puede encontrar en el icono Recomendaciones .
E XP L O R E A Z U R E S E C U R I TY
C E N TE R
Para explorar Azure Security Center, vaya a Azure Portal.

Más información
Para más información, consulte la documentación de Azure Security Center.
Especialización de la plataforma para la
administración en la nube
Al igual que la línea de base de administración mejorada, la especialización de plataforma es una extensión más
allá de la línea de base de administración estándar. Consulte la lista y la imagen siguientes, que muestran las
maneras de ampliar la línea de referencia de administración. En este artículo se tratan las opciones de
especialización de la plataforma.
Operaciones con cargas de trabajo: mayor inversión en operaciones por carga de trabajo y mayor grado
de resistencia. Las operaciones con cargas de trabajo se sugieren para aproximadamente el 20 % de las
cargas de trabajo que impulsan el valor empresarial. Esta especialización suele reservarse para cargas de
trabajo de gran importancia o críticas.
Operaciones de la plataforma: La inversión en operaciones se reparte entre varias cargas de trabajo. Las
mejoras de resistencia afectan a todas las cargas de trabajo que usan la plataforma definida. Las operaciones
de la plataforma se sugieren para aproximadamente el 20 % de las plataformas que tienen una importancia
crítica. Esta especialización se suele reservar para cargas de trabajo de importancia media a crítica.
Línea de base de administración mejorada: inversión en operaciones relativamente más baja. Esta
especialización mejora ligeramente los compromisos empresariales mediante herramientas y procesos de
operaciones nativos de la nube.
Ambas operaciones de carga de trabajo y plataforma requieren cambios en los principios de diseño y
arquitectura. Estos cambios pueden tardar un tiempo y generar mayores gastos de funcionamiento. Para reducir
el número de cargas de trabajo que requieren tales inversiones, una línea de referencia de administración
mejorada puede proporcionar una mejora suficiente en el compromiso empresarial.
En esta tabla se describen algunos procesos, herramientas y posibles consecuencias comunes en las líneas de
referencia de administración mejorada de los clientes:
N IVEL DE
A DM IN IST RA C IÓ N
P RO C ESO H ERRA M IEN TA P RO P Ó SITO SUGERIDO
Mejora del diseño del Marco de buena Mejora del diseño N/D
sistema arquitectura de Microsoft arquitectónico de la
Azure plataforma para mejorar las
operaciones
Corrección automática Azure Automation Respuesta a datos Operaciones de la

avanzados de la plataforma plataforma
con automatización
específica de la plataforma
Catálogo de servicios Centro de Managed Suministro de un catálogo Operaciones de la

Applications de autoservicio de plataforma
soluciones aprobadas que
cumplen los estándares de
la organización
Rendimiento de Azure Monitor para Supervisión y diagnóstico Operaciones de la

contenedores contenedores de contenedores plataforma
Rendimiento de datos de la Azure SQL Analytics Supervisión y diagnóstico Operaciones de la

plataforma como servicio de bases de datos PaaS plataforma
(PaaS)
Rendimiento de los datos Comprobación de estado Supervisión y diagnóstico Operaciones de la

de infraestructura como de SQL Server de bases de datos IaaS plataforma
servicio (IaaS)
Proceso de alto nivel

La especialización de la plataforma consta de una ejecución disciplinada de los cuatro procesos siguientes con
un enfoque iterativo. Cada proceso se explica con más detalle en secciones posteriores de este artículo.
Mejora del diseño del sistema: mejora el diseño de sistemas o plataformas comunes para minimizar las
interrupciones de forma eficaz.
Corrección automática: algunas mejoras no son rentables. En tales casos, es posible que tenga más
sentido automatizar la corrección y reducir el efecto de las interrupciones.
Escalado de la solución: a medida que se mejoran el diseño de sistemas y la corrección automatizada, los
cambios se pueden escalar en el entorno a través del catálogo de servicios.
Mejora continua: se pueden usar distintas herramientas de supervisión para detectar mejoras
incrementales. Estas mejoras se pueden tratar en el siguiente paso del diseño, la automatización y la escala
del sistema.
Mejora del diseño del sistema
La mejora del diseño del sistema es el enfoque más eficaz para mejorar las operaciones de cualquier plataforma
común. Gracias a las mejoras en el diseño del sistema, la estabilidad puede aumentar y las interrupciones del
negocio pueden disminuir. El diseño de sistemas individuales está más allá del ámbito de la vista del entorno
que se usa en todo Cloud Adoption Framework.
Como complemento de esta plataforma, el Marco de buena arquitectura de Microsoft Azure proporciona unos
principios rectores para mejorar la calidad de una plataforma o carga de trabajo específica. El marco se centra
en la mejora de los cinco pilares de la excelencia arquitectónica:
Optimización de costos: administra los costos para maximizar el valor entregado.
Excelencia operativa: sigue los procesos de operaciones que mantienen un sistema ejecutándose en
producción.
Eficiencia del rendimiento: escala los sistemas para adaptarse a los cambios en la carga.
Confiabilidad: diseña sistemas para que se recuperen de los errores y sigan funcionando.
Seguridad: protege las aplicaciones y los datos frente a amenazas.
La deuda técnica y los errores arquitectónicos provocan la mayoría de las interrupciones de la empresa. En el
caso de las implementaciones existentes, puede ver las mejoras en el diseño de los sistemas como pagos de la
deuda técnica existente. En el caso de las nuevas implementaciones, puede ver estas mejoras como una medida
para evitar la deuda técnica.
La pestaña Corrección automatizada siguiente examina las formas de abordar la deuda técnica que no se
puede o no se debe solucionar.
Obtenga más información acerca del Marco de buena arquitectura de Microsoft Azure para mejorar el diseño
del sistema.
A medida que el diseño del sistema mejora, vuelva a consultar este artículo para encontrar nuevas
oportunidades de mejorar y escalar esas mejoras en todo el entorno.
Corrección automatizada
Algunas deudas técnicas no se pueden abordar, ya que la resolución puede tener un costo demasiado alto o
haberse planeado, pero tener una duración de proyecto prolongada. Es posible que la interrupción empresarial
no tenga un efecto importante para la empresa. O bien, la prioridad empresarial podría ser una recuperación
rápida en lugar de la inversión en resistencia.
Cuando el enfoque deseado no es la resolución de la deuda técnica, la corrección automática suele ser el
siguiente paso. El uso de Azure Automation y Azure Monitor para detectar tendencias y proporcionar una
corrección automatizada es el enfoque más común para la corrección automatizada.
Para obtener instrucciones sobre la corrección automatizada, consulte Azure Automation y alertas.
Escalado de la solución con un catálogo de servicios

La piedra angular de las operaciones la especialización de la plataforma es un catálogo de servicios bien

administrado. A través del catálogo se escalan las mejoras en el diseño de los sistemas y las correcciones en un
entorno.
El equipo de plataforma en la nube y el equipo de automatización en la nube se coordinan para crear soluciones
repetibles para las plataformas más comunes en cualquier entorno. Sin embargo, si esas soluciones no se
utilizan de forma coherente, la administración en la nube puede proporcionar poco más que una oferta de línea
de referencia.
Para maximizar la adopción y minimizar la sobrecarga de mantenimiento de cualquier plataforma optimizada,
dicha plataforma se debe agregar a un catálogo de servicios de Azure. Todas las aplicaciones del catálogo se
pueden implementar para consumo interno a través del catálogo de servicios o como una oferta de
Marketplace para consumidores externos.
Para obtener instrucciones sobre cómo publicar en un catálogo de servicios, consulte la serie de artículos sobre
cómo publicar en un catálogo de servicios.
Implementación de aplicaciones desde el catálogo de servicios
1. En Azure Portal, busque Centro de Managed Applications (versión preliminar) .
2. En el panel Examinar , seleccione Aplicaciones del catálogo de ser vicios .
3. Seleccione + Agregar para seleccionar una definición de aplicación del catálogo de servicios de su empresa.
Se muestran las aplicaciones administradas a las que presta mantenimiento.
G O TO V I R TU A L
M AC H INE S
Administración de las aplicaciones del catálogo de servicios

1. En Azure Portal, busque Centro de Managed Applications (versión preliminar) .
2. En el panel Ser vicio , seleccione Aplicaciones del catálogo de ser vicios .
Se muestran las aplicaciones administradas a las que presta mantenimiento.
G O TO V I R TU A L
M AC H INE S
Mejora continua
Mejora continua
La especialización de la plataforma y las operaciones de la misma dependen de ciclos de comentarios sólidos

entre los equipos de adopción, plataforma, automatización y administración. El hecho de que esos ciclos de
comentarios estén basados en datos ayuda a cada equipo a tomar decisiones acertadas. En el caso de las
operaciones de plataforma para lograr compromisos empresariales a largo plazo, es importante usar la
información específica de la plataforma centralizada.
Containers y SQL Server son las dos plataformas administradas de forma centralizada más comunes. Estos
artículos pueden ayudarle a empezar con la recopilación de datos de mejora continua en estas plataformas:
Rendimiento de contenedores
Rendimiento de bases de datos PaaS
Rendimiento de bases de datos IaaS
Especialización de la carga de trabajo para la
administración en la nube
La especialización de la carga de trabajo se basa en los conceptos que se describen en Especialización de la

plataforma.
Operaciones con cargas de trabajo: mayor inversión en operaciones por carga de trabajo y mayor grado
de resistencia. Las operaciones con cargas de trabajo se sugieren para aproximadamente el 20 % de las
cargas de trabajo que impulsan el valor empresarial. Esta especialización suele reservarse para cargas de
trabajo de gran importancia o críticas.
Operaciones de la plataforma: La inversión en operaciones se reparte entre varias cargas de trabajo. Las
mejoras de resistencia afectan a todas las cargas de trabajo que usan la plataforma definida. Las operaciones
de la plataforma se sugieren para aproximadamente el 20 % de las plataformas que tienen una importancia
crítica. Esta especialización se suele reservar para cargas de trabajo de importancia media a crítica.
Línea de base de administración mejorada: inversión en operaciones relativamente más baja. Esta
especialización mejora ligeramente los compromisos empresariales mediante herramientas y procesos de
operaciones nativos de la nube.
Proceso de alto nivel
La especialización de la carga de trabajo consta de una ejecución disciplinada de los cuatro procesos siguientes
con un enfoque iterativo. Cada proceso se explica con más detalle en Especialización de la plataforma.
Mejora del diseño del sistema: se mejora el diseño de una carga de trabajo específica para minimizar las
interrupciones de forma eficaz.
sentido automatizar la corrección y reducir el efecto de las interrupciones.
Escalado de la solución: a medida mejora el diseño de los sistemas y la corrección automatizada, los
cambios se pueden escalar en el entorno mediante el catálogo de servicios.
Mejora continua: puede usar distintas herramientas de supervisión para detectar mejoras incrementales.
Estas mejoras se pueden tratar en el siguiente paso del diseño, la automatización y la escala del sistema.
Cambio cultural
La especialización de la carga de trabajo suele desencadenar un cambio cultural en los procesos de compilación
de TI tradicionales que se centran en ofrecer una base de referencia de administración, bases de referencia
mejoradas y operaciones de plataforma. Estos tipos de ofertas se pueden escalar en todo el entorno. La
especialización de la carga de trabajo es similar en aplicación a la especialización de plataforma. Sin embargo, a
diferencia de las plataformas comunes, la especialización que requieren las cargas de trabajo individuales no
suele escalarse.
Cuando se requiere la especialización de carga de trabajo, la administración operativa suele evolucionar más
allá de una perspectiva de TI centralizada. El enfoque sugerido de Cloud Adoption Framework es una
distribución de la funcionalidad de administración en la nube.
En este modelo, las tareas operativas como la supervisión, la implementación, DevOps y otras funciones
centradas en la innovación se desplazan a una organización de desarrollo de aplicaciones o de unidad de
negocio. El equipo de plataforma de la nube y el equipo de supervisión de la nube principal todavía cumplen
con la base de referencia de administración en todo el entorno.
Esos equipos centralizados también guían e instruyen a los equipos especializados en cargas de trabajo sobre
las operaciones de sus cargas de trabajo. Sin embargo, la responsabilidad operativa cotidiana recae en un
equipo de administración en la nube que se administra fuera de TI. Este tipo de control distribuido es uno de los
indicadores principales de madurez del centro de excelencia de la nube.
Más allá de la especialización de la plataforma: Application Insights

Se requieren más detalles sobre la carga de trabajo específica para proporcionar operaciones de carga de
trabajo claras. Durante la fase de mejora continua, Application Insights será una adición necesaria a la cadena de
herramientas de administración en la nube.
REQ UISITO H ERRA M IEN TA P RO P Ó SITO
Supervisión de aplicaciones Application Insights Supervisión y diagnóstico de

aplicaciones
Rendimiento, disponibilidad y uso Application Insights Supervisión avanzada de aplicaciones

mediante el panel de aplicaciones, los
mapas compuestos, el uso y
seguimiento
Implementar Application Insights

1. En Azure Portal, diríjase a Application Insights .
2. Haga clic en + Agregar para crear un recurso de Application Insights y supervisar la aplicación web en vivo.
3. Siga las instrucciones que aparecen en pantalla.
Para obtener instrucciones sobre cómo configurar la aplicación para la supervisión, consulte el centro sobre
Application Insights de Azure Monitor.
C R E ATE A P P L I C ATI O N I N S I G H T
RESO URCES
Supervisión del rendimiento, la disponibilidad y el uso

1. En Azure Portal, busque Application Insights .
2. Elija uno de los recursos de Application Insights de la lista.
Application Insights contiene diversos tipos de opciones para supervisar el rendimiento, la disponibilidad, el uso
y las dependencias. Cada una de estas vistas de los datos de la aplicación proporciona más claridad sobre el
ciclo de comentarios para la mejora continua.
M O N I TO R
A P P L I C ATI O N S
Establecimiento de los procedimientos de
administración operativa en la nube
La adopción de la nube actúa como catalizador para impulsar el valor empresarial. Sin embargo, el valor
empresarial real se obtiene mediante el funcionamiento constante y estable de los recursos tecnológicos
implementados en la nube. Esta sección de Cloud Adoption Framework le guía por diversas transiciones hasta la
administración operativa de la nube.
Procedimientos recomendados viables

Las soluciones actuales de administración operativa crean una vista de varias nubes de las operaciones. Los
recursos administrados mediante los siguientes procedimientos recomendados pueden residir en la nube, en un
centro de datos existente o incluso en un proveedor de nube de la competencia. Actualmente, la plataforma
incluye dos referencias de procedimientos recomendados para lograr la madurez de la administración de las
operaciones en la nube:
Azure Server Management: guía de incorporación para agregar las herramientas y servicios nativos en la
nube necesarios para administrar las operaciones.
Supervisión híbrida: Muchos clientes ya han realizado una inversión sustancial en System Center Operations
Manager. Para esos clientes, esta guía sobre la supervisión híbrida puede ayudar a comparar y contrastar las
herramientas de notificación nativas de la nube con las herramientas de Operations Manager. Con esta
comparación resulta más fácil decidir qué herramientas utilizar para la administración operativa.
Operaciones en la nube
Ambos procedimientos recomendados conducen hacia una metodología de estado futuro para la
administración de operaciones, como se ilustra en el diagrama siguiente:
Alineación empresarial: En la metodología de administración todas las cargas de trabajo se clasifican por
nivel de importancia y por valor empresarial. Posteriormente, esa clasificación se puede medir mediante un
análisis de impacto, que calcula el valor perdido asociado con una degradación del rendimiento o con
interrupciones en su negocio. Con ese impacto tangible de los ingresos, los equipos de operaciones en la nube
pueden trabajar con la empresa para establecer un compromiso que equilibre el costo y el rendimiento.
Materias de operaciones en la nube: Una vez alineado el negocio, es mucho más fácil realizar un
seguimiento e informar sobre las materias adecuadas de las operaciones en la nube para cada carga de trabajo.
La toma de decisiones en cada materia se puede convertir posteriormente en términos de compromiso
fácilmente comprensibles para la empresa. Este enfoque de colaboración hace que las partes interesadas de la
empresa se conviertan en asociados a la hora de encontrar el equilibrio adecuado entre costo y rendimiento.
Inventario y visibilidad: Como mínimo, la administración de operaciones necesita un medio para realizar
un inventario de los recursos y visibilidad sobre el estado de ejecución de cada recurso.
Cumplimiento operativo: La administración frecuente de la configuración, tamaño, costo y rendimiento de
los recursos es clave para mantener las expectativas de rendimiento.
Protección y recuperación: minimizar las interrupciones operativas y agilizar la recuperación ayudan a
evitar pérdidas de rendimiento e impactos negativos en los ingresos. Detección y recuperación son aspectos
esenciales de esta materia.
Operaciones de la plataforma: Todos los entornos de TI contienen un conjunto de plataformas que se
emplean habitualmente. Estas plataformas pueden incluir almacenes de datos como SQL Server o Azure
HDInsight. Otras plataformas comunes pueden incluir soluciones de contenedores como Azure Kubernetes
Service (AKS). Con independencia de la plataforma, la madurez de las operaciones que se realizan en esta se
centra en personalizar las operaciones en función de cómo las cargas de trabajo implementan, configuran y
utilizan las plataformas habituales.
Operaciones con cargas de trabajo: En el nivel más alto de madurez operativa, los equipos de
operaciones en la nube pueden optimizar las operaciones de las cargas de trabajo críticas. Para esas cargas
de trabajo, los datos disponibles pueden ayudar a automatizar la corrección, el ajuste de tamaño o la
protección de las cargas de trabajo según su uso.
Instrucciones adicionales, como las que se incluyen en el Marco de buena arquitectura de Microsoft Azure,
pueden ayudar a tomar decisiones de arquitectura detalladas en relación con cada carga de trabajo de las
materias descritas anteriormente.
Esta sección de Cloud Adoption Framework se creará sobre cada uno de estos temas para ayudar a promover
operaciones en la nube maduras dentro de la organización.
Introducción sobre los servicios de administración
de servidores de Azure
Los servicios de administración de servidores de Azure proporcionan una experiencia coherente para
administrar sus servidores a escala. Estos servicios abarcan los sistemas operativos Linux y Windows. Se
pueden usar en entornos de producción, desarrollo y pruebas. Los servicios de administración de servidores
pueden admitir máquinas virtuales IaaS de Azure, servidores físicos y máquinas virtuales hospedados de forma
local o en otros entornos de hospedaje.
El conjunto de servicios de administración de servidores de Azure incluye los servicios del siguiente diagrama:
En esta sección de Microsoft Cloud Adoption Framework se ofrece un plan preceptivo y viable para la
implementación de los servicios de administración de servidores en su entorno. Este plan le ayuda a orientarse
rápidamente en estos servicios y le guía a través de un conjunto progresivo de fases de administración para
entornos de todos los tamaños.
Para simplificar, se han clasificado las instrucciones en tres fases:
¿Por qué usar los servicios de administración de servidores de Azure?
Los servicios de administración de servidores de Azure ofrecen las siguientes ventajas:
Nativos de Azure: Los servicios de administración de servidores están integrados de forma nativa con
Azure Resource Manager. Estos servicios se mejoran continuamente para proporcionar funcionalidades y
características nuevas.
Windows y Linux: Las máquinas Windows y Linux obtienen la misma experiencia de administración
coherente.
Híbrido: Los servicios de administración de servidores abarcan máquinas virtuales IaaS de Azure, así como
servidores físicos y virtuales hospedados en el entorno local o en otros entornos de hospedaje.
Seguridad: Microsoft dedica bastantes recursos a todo lo que aporte seguridad. Esta inversión no solo
protege la infraestructura de Azure, sino que también extiende las tecnologías y conocimientos resultantes
para proteger los recursos de los clientes allá donde se encuentren.
Pasos siguientes
Familiarícese con las herramientas, servicios y planeamiento relacionados con la adopción del paquete de
administración de servidores de Azure.
Requisitos previos de herramientas y planeamiento
Fase 1: Planeamiento de los requisitos previos de los
servicios de administración de servidores de Azure
En esta fase, se familiarizará con el conjunto de servicios de administración de servidores de Azure y planeará la
implementación de los recursos necesarios para implementar estas soluciones de administración.
Descripción de las herramientas y los servicios

Consulte Servicios y herramientas de administración de servidores de Azure para obtener información general
detallada sobre:
Las áreas de administración que intervienen en las operaciones de Azure en curso.
Los servicios y las herramientas de Azure que le ayudan en estas áreas.
Para cumplir los requisitos de administración, deberá usar varios de estos servicios. Nos referiremos a estas
herramientas con frecuencia a lo largo de esta guía.
En las secciones siguientes se describen el planeamiento y la preparación necesarios para utilizar estas
herramientas y los servicios.
Planeamiento del área de trabajo de Log Analytics y cuenta de Azure

Automation
Muchos de los servicios que usará para incorporar los servicios de administración de Azure requieren un área
de trabajo de Log Analytics y una cuenta de Azure Automation vinculada.
Un área de trabajo de Log Analytics es un entorno único para almacenar los datos de registro de Azure Monitor.
Cada área de trabajo tiene su propio repositorio y configuración de datos. Los orígenes de datos y las soluciones
se configuran para almacenar sus datos en áreas de trabajo determinadas. Las soluciones de supervisión de
Azure requieren que todos los servidores se conecten a un área de trabajo, para poder almacenar los datos de
registro y obtener acceso a ellos.
Algunos de los servicios de administración requieren una cuenta de Azure Automation. Esta cuenta y las
funcionalidades de Azure Automation se usan para integrar los servicios de Azure y otros sistemas públicos
para implementar, configurar y administrar los procesos de administración de servidores.
Los siguientes servicios de administración de servidores de Azure requieren un área de trabajo de Log Analytics
vinculada y una cuenta de Automation:
Change Tracking e Inventario
Trabajo híbrido de runbook
Desired State Configuration
La segunda fase de esta guía se centra en la implementación de los servicios y los scripts de automatización.
Muestra cómo crear un área de trabajo de Log Analytics y una cuenta de Azure Automation. En esta guía
también se muestra cómo usar Azure Policy para asegurarse de que las nuevas máquinas virtuales estén
conectadas al área de trabajo correcta.
En los ejemplos de esta guía se da por hecho que hay una implementación que aún no tiene servidores
implementados en la nube. Para más información sobre los principios y las consideraciones que conlleva el
planeamiento de las áreas de trabajo, consulte Administración de los datos de registro y las áreas de trabajo en
Azure Monitor.
Consideraciones de planeación
Al preparar las áreas de trabajo y las cuentas que necesita para incorporar los servicios de administración, tenga
en cuenta los siguientes problemas:
Zonas geográficas de Azure y cumplimiento normativo: Las regiones de Azure se organizan por
zonas geográficas. Una zona geográfica de Azure garantiza que se cumplan los requisitos de residencia,
soberanía, cumplimiento normativo y resistencia de los datos dentro de las fronteras geográficas. Si las
cargas de trabajo están sujetas a la soberanía de datos u otros requisitos de cumplimiento, las cuentas de
Azure Automation y el área de trabajo deben implementarse en regiones dentro de la misma ubicación
geográfica de Azure que los recursos de la carga de trabajo a los que corresponden.
Número de áreas de trabajo: Como regla general, cree el número mínimo de áreas de trabajo necesarias
por ubicación geográfica de Azure. Se recomienda al menos un área de trabajo para cada zona geográfica de
Azure donde se encuentren los recursos de proceso o almacenamiento. Esta alineación inicial ayuda a evitar
problemas normativos futuros al migrar datos a zonas geográficas diferentes.
Límite y retención de los datos: También es posible que deba tener en cuenta las directivas de retención
de datos o los requisitos de límite de datos al crear áreas de trabajo o cuentas de Azure Automation. Para
más información sobre los estos principios y las consideraciones adicionales que conlleva el planeamiento
de las áreas de trabajo, consulte Administración de los datos de registro y las áreas de trabajo en Azure
Monitor.
Asignación de región: solo se pueden vincular un área de trabajo de Log Analytics y una cuenta de Azure
Automation entre determinadas regiones de Azure. Por ejemplo, si el área de trabajo de Log Analytics se
hospeda en la región East US , la cuenta de Azure Automation vinculada se debe crear en la región
East US 2 para poder usarse con los servicios de administración. Si tiene una cuenta de Automation creada
en otra región, no podrá vincularla a un área de trabajo en East US . La elección de la región de
implementación puede afectar significativamente a los requisitos de zona geográfica de Azure. Consulte la
tabla de asignación de regiones para decidir qué región debe hospedar las áreas de trabajo y las cuentas de
Automation.
Hospedaje múltiple de áreas de trabajo: el agente de Azure Log Analytics admite el hospedaje múltiple
en algunos escenarios, pero se esta configuración presenta varias limitaciones y retos. A menos que
Microsoft lo recomiende para su escenario, no configure el host múltiple en el agente de Log Analytics.
Ejemplos de ubicación de recursos

Hay varios modelos diferentes para elegir la suscripción en la que se colocan el área de trabajo de Log Analytics
y la cuenta de Automation. En resumen, coloque el área de trabajo y las cuentas de Automation en una
suscripción que sea propiedad del equipo responsable de la implementación de las soluciones Update
Management y Seguimiento de cambios e inventario.
A continuación se muestran ejemplos de algunas formas de implementar áreas de trabajo y cuentas de
Automation.
Ubicación por zona geográfica
Los entornos pequeños y medianos tienen una sola suscripción y varios cientos de recursos que abarcan varias
zonas geográficas de Azure. Para estos entornos, cree un área de trabajo Log Analytics y una cuenta de Azure
Automation en cada zona geográfica.
Puede crear un área de trabajo y una cuenta de Azure Automation como un par en cada grupo de recursos. A
continuación, implemente el par de la zona geográfica correspondiente en las máquinas virtuales.
Como alternativa, si las directivas de cumplimiento de datos no dictan que los recursos residan en regiones
específicas, puede crear un par para administrar todas las máquinas virtuales. También se recomienda colocar
los pares de área de trabajo y cuenta de Automation en grupos de recursos independientes para proporcionar
un control de acceso basado en rol de Azure (RBAC de Azure) más detallado.
El ejemplo del diagrama siguiente tiene una suscripción con dos grupos de recursos, cada uno de los cuales se
encuentra en una zona geográfica diferente:
Ubicación en una suscripción de administración

Los entornos más grandes abarcan varias suscripciones y tienen un equipo de TI central propietario de la
supervisión y el cumplimiento. Para estos entornos, cree pares de áreas de trabajo y cuentas de Automation en
una suscripción de administración de TI. En este modelo, los recursos de máquina virtual situados en una zona
geográfica almacenan sus datos en el área de trabajo de la zona geográfica correspondiente, en la suscripción
de administración de TI. Si los equipos de aplicaciones necesitan ejecutar tareas de automatización, pero no
requieren un área de trabajo vinculada ni cuentas de Automation, pueden crear cuentas de Automation
independientes en sus propias suscripciones de aplicación.
Ubicación descentralizada
En un modelo alternativo para entornos de gran tamaño, el equipo de desarrollo de aplicaciones puede tener la
responsabilidad de la administración y aplicación de revisiones. En este caso, coloque los pares de área de
trabajo y cuenta de Automation en las suscripciones del equipo de aplicaciones, junto con los demás recursos.
Creación de un área de trabajo y una cuenta de Automation
Después de elegir la mejor manera de colocar y organizar los pares de área de trabajo y cuenta, asegúrese de
crear estos recursos antes de iniciar el proceso de incorporación. En los ejemplos de automatización que se
incluyen más adelante en esta guía, se crea automáticamente un par de área de trabajo y cuenta de Automation.
Sin embargo, si quiere realizar la incorporación mediante Azure Portal y no tiene ningún par de área de trabajo
y cuenta de Automation, tendrá que crear uno.
Para crear un área de trabajo de Log Analytics mediante Azure Portal, consulte Creación de un área de trabajo. A
continuación, cree la cuenta de Automation correspondiente a cada área de trabajo siguiendo los pasos
descritos en Creación de una cuenta de Azure Automation.
NOTE
Al crear una cuenta de Automation mediante Azure Portal, el portal intenta de forma predeterminada crear cuentas de
ejecución para los recursos de Azure Resource Manager y del modelo de implementación clásica. Si no tiene máquinas
virtuales clásicas en su entorno y no es coadministrador de la suscripción, el portal crea una cuenta de ejecución para
Resource Manager pero genera un error al implementar la cuenta de ejecución clásica. Si no desea admitir recursos
clásicos, puede omitir este error.
También puede crear una cuenta de ejecución con PowerShell.
Pasos siguientes
Aprenda cómo incorporar sus servidores a los servicios de administración de servidores de Azure.
Incorporación a los servicios de administración de servidores de Azure
Fase 2: Incorporación a los servicios de
administración de servidores de Azure
Una vez que esté familiarizado con las herramientas y el planeamiento implicados en los servicios de
administración de Azure, estará listo para la segunda fase. La segunda fase proporciona una guía paso a paso
para incorporar estos servicios para su uso con los recursos de Azure. Empiece por evaluar este proceso de
incorporación antes de adoptarlo ampliamente en su entorno.
NOTE
Los enfoques de automatización descritos en secciones posteriores de esta guía están destinados a implementaciones que
aún no tienen servidores implementados en la nube. Estos enfoques requieren que tenga el rol de propietario en una
suscripción para crear todos los recursos y directivas necesarios. Si ya ha creado áreas de trabajo de Log Analytics y de
cuenta de Automation, se recomienda que pase estos recursos en los parámetros adecuados al iniciar los scripts de
automatización de ejemplo.
Procesos de incorporación
En esta sección de la guía se tratan los siguientes procesos de incorporación tanto para máquinas virtuales de
Azure como para servidores locales:
Habilitar los ser vicios de administración en una única máquina vir tual para su evaluación con
el por tal. Utilice este proceso para familiarizarse con los servicios de administración de servidores de Azure.
Configuración de ser vicios de administración para una suscripción con el por tal. Este proceso le
ayuda a configurar el entorno de Azure para que las nuevas máquinas virtuales que se aprovisionan usen
automáticamente los servicios de administración. Use este enfoque si prefiere la experiencia de Azure Portal
a scripts y líneas de comandos.
Configuración de ser vicios de administración para una suscripción con Azure Automation. Este
proceso está totalmente automatizado. Solo tiene que crear una suscripción y los scripts configurarán el
entorno para usar los servicios de administración para cualquier VM que se haya aprovisionado
recientemente. Use este enfoque si está familiarizado con los scripts de PowerShell y las plantillas de Azure
Resource Manager, o si quiere aprender a usarlos.
Los procedimientos para cada uno de estos enfoques son diferentes.
NOTE
Cuando se usa Azure Portal, la secuencia de pasos de incorporación difiere de los pasos de incorporación automatizados.
El portal ofrece una experiencia de incorporación más sencilla.
En el diagrama siguiente se muestra el modelo de implementación recomendado para los servicios de

administración:
Como se muestra en el diagrama anterior, el agente de Log Analytics tiene dos configuraciones para los
servidores locales:
Inscripción automática: cuando el agente de Log Analytics se instala en un servidor y se configura para
conectarse a un área de trabajo, las soluciones habilitadas en esa área de trabajo se aplican automáticamente
al servidor.
Opcional: aunque el agente esté instalado y conectado al área de trabajo, la solución no se aplica, a menos
que se agregue a la configuración de ámbito del servidor en el área de trabajo.
Pasos siguientes
Obtenga información sobre cómo incorporar una única máquina virtual mediante el portal para evaluar el
proceso de incorporación.
Incorporación de una única máquina virtual de Azure para su evaluación
Habilitar los servicios de administración en una
única VM para su evaluación
Obtenga información sobre cómo habilitar los servicios de administración en una única VM para su evaluación.
NOTE
Cree el área de trabajo de Log Analytics y la cuenta de Azure Automation necesarias antes de implementar servicios de
administración de Azure en una VM.
La incorporación de servicios de administración de servidores de Azure a máquinas virtuales individuales es

sencilla en Azure Portal. Puede familiarizarse con estos servicios antes de incorporarlos. Al seleccionar una
instancia de VM, todas las soluciones que se describen en la lista de herramientas y servicios de administración
aparecen en el menú Operaciones o en el menú Super visión . Debe seleccionar una solución y seguir el
asistente para incorporarla.
Para obtener más información sobre cómo incorporar estas soluciones a VM individuales, consulte:
Incorporación de las soluciones Update Management y Seguimiento de cambios e inventario para una
máquina virtual de Azure
Incorporar Azure Monitor para VM
Pasos siguientes
Aprenda a usar Azure Policy para incorporar máquinas virtuales de Azure a escala.
Configuración de servicios de administración de Azure para una suscripción
Configuración de servicios de administración de
servidores de Azure a escala
Debe completar estas dos tareas para incorporar los servicios de administración de servidores de Azure en sus
servidores:
Implementar los agentes de servicio en los servidores
Habilitar las soluciones de administración
En este artículo se tratan los siguientes tres procesos necesarios para realizar estas tareas:
1. Implementar los agentes necesarios en las VM de Azure mediante Azure Policy
2. Implementar los agentes necesarios en servidores locales
3. Habilitar y configurar las soluciones
NOTE
Cree el área de trabajo de Log Analytics y la cuenta de Azure Automation necesarias antes de incorporar máquinas
virtuales a los servicios de administración de servidores de Azure.
Uso de Azure Policy para implementar extensiones en VM de Azure

Todas las soluciones de administración descritas en el artículo sobre servicios y herramientas de administración
de Azure requieren que el agente de Log Analytics esté instalado en las máquinas virtuales de Azure y en los
servidores locales. Puede incorporar sus máquinas virtuales de Azure a escala mediante Azure Policy. Asigne
una directiva para asegurarse de que el agente esté instalado en sus VM de Azure y conectado al área de trabajo
de Log Analytics correcta.
Azure Policy tiene una iniciativa de directiva integrada que incluye el agente de Log Analytics y
Microsoft Dependency Agent, que necesita Azure Monitor para VM.
NOTE
Para más información sobre distintos agentes de supervisión de Azure, consulte Introducción a los agentes de supervisión
de Azure.
Asignación de directivas
Para asignar las directivas que se describen en la sección anterior:
1. En Azure Portal, vaya a Directiva > Asignaciones > Asignar iniciativa .
2. En la página Asignar directiva , seleccione los puntos suspensivos ( ... ) para establecer la opción
Ámbito y seleccione una suscripción o un grupo de administración. Opcionalmente, seleccione un grupo
de recursos. Luego elija Seleccionar en la parte inferior de la página Ámbito . El ámbito determina los
recursos o el grupo de recursos a los que se asigna la directiva.
3. Seleccione los puntos suspensivos ( ... ) que aparecen junto a Definición de directiva para abrir la lista
de definiciones disponibles. Para filtrar las definiciones de iniciativa, escriba Azure Monitor en el cuadro
de búsqueda :
4. Nombre de asignación se rellena automáticamente con el nombre de directiva seleccionado, pero

puede cambiarlo. También puede agregar una descripción opcional para proporcionar más información
sobre esta asignación de directiva. El campo Asignado por se rellena automáticamente en función de
quién inicie sesión. Este campo es opcional y admite valores personalizados.
5. Para esta directiva, seleccione Área de trabajo de Log Analytics como agente de Log Analytics que se
va a asociar.
6. Seleccione la casilla Ubicación de la identidad administrada . Si esta directiva es de tipo

DeployIfNotExists , se necesitará una identidad administrada para implementarla. En el portal, la cuenta
se creará como se indica con la selección de la casilla.
7. Seleccione Asignar .
Después de completar el asistente, la asignación de directiva se implementará en el entorno. La directiva puede
tardar hasta 30 minutos en surtir efecto. Para probarla, cree nuevas máquinas virtuales después de 30 minutos
y compruebe si el agente de Log Analytics está habilitado en la máquina virtual de forma predeterminada.
Instalación de los agentes en servidores locales

NOTE
Cree el área de trabajo de Log Analytics y la cuenta de Azure Automation necesarias antes de incorporar los servicios de
administración de servidores de Azure en los servidores.
En el caso de los servidores locales, debe descargar e instalar manualmente el agente de Log Analytics y
Microsoft Dependency Agent, y configurarlos para que se conecten al área de trabajo correcta. Debe especificar
el identificador del área de trabajo y la información de clave. Para obtener esa información, vaya al área de
trabajo de Log Analytics en Azure Portal y, a continuación, seleccione Configuración > Configuración
avanzada .
Habilitación y configuración de soluciones

Para habilitar las soluciones, tiene que configurar el área de trabajo Log Analytics. Las VM de Azure y los
servidores locales incorporados obtendrán las soluciones de las áreas de trabajo de Log Analytics a las que se
han conectado.
La soluciones Update Management y Seguimiento de cambios e inventario requieren un área de trabajo de Log
Analytics y una cuenta de Azure Automation. Para asegurarse de que estos recursos están configurados
correctamente, se recomienda realizar la incorporación a través de la cuenta de Automation. Para más
información, consulte Incorporación de las soluciones Update Management y Seguimiento de cambios e
inventario.
Se recomienda habilitar la solución Update Management para todos los servidores. Update Management es
gratis para las máquinas virtuales de Azure y los servidores locales. Si habilita Update Management a través de
su cuenta de Automation, se creará una configuración de ámbito en el área de trabajo. Actualice manualmente el
ámbito para incluir las máquinas que cubre la solución Update Management.
Para cubrir los servidores existentes, así como los futuros, debe quitar la configuración de ámbito. Para hacerlo,
consulte la cuenta de Automation en Azure Portal. Seleccione Update Management > Administrar
máquinas > Habilitar en todas las máquinas disponibles y futuras . Es opción permite que todas las VM
de Azure conectadas al área de trabajo usen Update Management.
Soluciones Change Tracking e Inventory
Para incorporar soluciones de Change Tracking e Inventory, siga los mismos pasos que para Update
Management. Para más información sobre cómo incorporar estas soluciones desde su cuenta de Automation,
consulte Incorporación de las soluciones Update Management y Seguimiento de cambios e inventario.
La solución Seguimiento de cambios e inventario es gratuita para las máquinas virtuales de Azure y cuesta
6 USD por nodo al mes para los servidores locales. Este costo cubre Seguimiento de cambios e inventario y
Desired State Configuration. Si solo quiere inscribir determinados servidores locales, puede participar en esos
servidores. Se recomienda que incorpore todos los servidores de producción.
Participación a través de Azure Portal
1. Vaya a la cuenta de Automation que tiene Change Tracking e Inventory habilitada.
2. Seleccione Seguimiento de cambios .
3. Seleccione Administrar máquinas en el panel superior derecho.
4. Seleccione Habilitar en las máquinas seleccionadas . A continuación, seleccione Agregar junto al
nombre de la máquina.
5. Seleccione Habilitar para habilitar la solución para esas máquinas.
<a name="opt-in-by-using-saved-searches">Participación mediante búsquedas guardadas Opt in by using saved searches

También puede establecer la configuración de ámbito para participar en servidores locales.Alternatively, you can
configure the scope configuration to opt in on-premises servers. La configuración de ámbito usa búsquedas
guardadas.Scope configuration uses saved searches.
Para crear o modificar la búsqueda guardada, siga estos pasos:To create or modify the saved search, follow these
steps:
1. Vaya al área de trabajo de Log Analytics que está vinculada a la cuenta de Automation que configuró en
los pasos anteriores.Go to the Log Analytics workspace that is linked to the Automation account that you
configured in the preceding steps.
2. En General , seleccione Búsquedas guardadas .Under General , select Saved searches .
3. En el cuadro Filtro , escriba Change Tracking para filtrar la lista de búsquedas guardadas.In the Filter
box, enter Change Tracking to filter the list of saved searches. En los resultados, seleccione
MicrosoftDefaultComputerGroup .In the results, select MicrosoftDefaultComputerGroup .
4. Escriba el VMUUID o el nombre del equipo para incluir los equipos en los que quiere participar con
Seguimiento de cambios e inventario.Enter the computer name or the VMUUID to include the computers
that you want to opt in for Change Tracking and Inventory.
Heartbeat
| where AzureEnvironment=~"Azure" or Computer in~ ("list of the on-premises server
names", "server1")
| distinct Computer
NOTE
El nombre del servidor debe coincidir exactamente con el valor de la expresión y no debe contener ningún sufijo de
nombre de dominio.
1. Seleccione Guardar . De forma predeterminada, la configuración de ámbito está vinculada a la búsqueda

guardada de MicrosoftDefaultComputerGroup . Se actualizará automáticamente.
Registro de actividades de Azure
Registro de actividad de Azure es una de las secciones de Azure Monitor. Proporciona información sobre los
eventos de nivel de suscripción que se producen en Azure.
Para implementar esta solución:
1. En Azure Portal, abra Todos los ser vicios y, a continuación, seleccione Administración y gobernanza >
Soluciones .
2. En la vista Soluciones , seleccione Agregar .
3. Busque Activity Log Analytics y selecciónela.
Debe especificar el nombre del área de trabajo que creó en la sección anterior donde está habilitada la
solución.
Agent Health para Azure Log Analytics
La solución Agent Health para Azure Log Analytics ofrece información sobre el mantenimiento, el rendimiento y
la disponibilidad de los servidores Windows y Linux.
Soluciones .
3. Busque Agent Health para Azure Log Analytics y selecciónela.
solución.
Una vez completada la creación, la instancia de recurso del área de trabajo muestra AgentHealthAssessment
al seleccionar Vista > Soluciones .
Evaluación de antimalware
La solución Antimalware Assessment le ayuda a identificar los servidores que están infectados o que presentan
mayor riesgo de infección por malware.
Soluciones .
3. Busque la opción Antimalware Assessment y selecciónela.
solución.
Una vez completada la creación, la instancia de recurso del área de trabajo muestra AntiMalware al seleccionar
Vista > Soluciones .
Azure Monitor para máquinas virtuales
Puede habilitar Azure Monitor para VM a través de la página de vista de la instancia de VM, tal y como se
describe en Habilitar los servicios de administración en una única máquina virtual para su evaluación. No debe
habilitar soluciones directamente desde la página Soluciones como hizo con las otras soluciones que se
describen en este artículo. Para implementaciones a gran escala, puede ser más fácil usar automatización para
habilitar las soluciones correctas en el área de trabajo.
Se recomienda que incorpore todos los servidores como mínimo en el nivel Gratis de Azure Security Center.
Esta opción le ofrece evaluaciones de seguridad básicas y recomendaciones de seguridad prácticas para su
entorno. El nivel Estándar proporciona ventajas adicionales. Para más información, consulte Precios de Azure
Security Center.
Para habilitar el nivel Gratis de Azure Security Center, siga estos pasos:
1. Vaya a la página Security Center del portal.
2. En POLICY & COMPLIANCE (DIRECTIVA Y CUMPLIMIENTO), seleccione Directiva de seguridad .
3. Busque el recurso del área de trabajo de Log Analytics que ha creado en el panel de la derecha.
4. Seleccione Editar configuración para esa área de trabajo.
5. Seleccione Plan de tarifa .
6. Seleccione la opción Gratis .
Pasos siguientes
Aprenda a usar la automatización para incorporar servidores y crear alertas.
Automatización de la incorporación y configuración de alertas
Automatizar la incorporación
Para mejorar la eficacia de la implementación de los servicios de administración de servidores de Azure,

considere la posibilidad de automatizar la implementación como se describe en las secciones anteriores de esta
guía. El script y las plantillas de ejemplo que se proporcionan en las siguientes secciones son puntos de partida
para desarrollar su propia automatización de procesos de incorporación.
Esta guía se apoya en un ejemplo de código del repositorio de GitHub. El repositorio proporciona scripts y
plantillas de Azure Resource Manager de ejemplo que le ayudarán a automatizar la implementación de los
servicios de administración de servidores de Azure.
En estos archivos de ejemplo se muestra cómo usar los cmdlets de Azure PowerShell para automatizar estas
tareas:
Crear un área de trabajo de Log Analytics. (O bien, use un área de trabajo existente si cumple los
requisitos. Para obtener más información, consulte el tema sobre el planeamiento del área de trabajo).
Crear una cuenta de Automation, o usar una cuenta existente que cumpla los requisitos. Para más
información, vea Planeamiento del área de trabajo.
Vincular cuenta de Automation y el área de trabajo de Log Analytics. Este paso no es necesario si realiza
la incorporación mediante Azure Portal.
Habilite las soluciones Update Management y Seguimiento de cambios e inventario para el área de
trabajo.
Incorporar VM de Azure mediante Azure Policy. Una directiva instala el agente de Log Analytics y
Microsoft Dependency Agent en las VM de Azure.
Habilitación automática de Azure Backup para máquinas virtuales mediante Azure Policy
Incorporar los servidores locales mediante la instalación del agente de Log Analytics en ellos.
Los archivos que se describen en la tabla siguiente se usan en este ejemplo. Puede personalizarlos para que
admitan sus propios escenarios de implementación.
N O M B RE DE A RC H IVO DESC RIP C IÓ N
New-AMSDeployment.ps1 Script de orquestación principal que automatiza la

incorporación. Crea grupos de recursos, la ubicación, el área
de trabajo y las cuentas de Automation, si aún no existen.
Este script de PowerShell requiere una suscripción existente.
Workspace-AutomationAccount.json Plantilla de Resource Manager que implementa el área de

trabajo y los recursos de la cuenta de Automation.
WorkspaceSolutions.json Plantilla de Resource Manager que permite habilitar las

soluciones que desee en el área de trabajo de Log Analytics.
ScopeConfig.json Plantilla de Resource Manager que usa el modelo de

participación para servidores locales con la solución
Seguimiento de cambios e inventario. El uso del modelo de
participación es opcional.
N O M B RE DE A RC H IVO DESC RIP C IÓ N
Enable-VMInsightsPerfCounters.ps1 Script de PowerShell que habilita Azure Monitor para VM y

configura los contadores de rendimiento.
ChangeTracking-FileList.json Plantilla de Resource Manager que define la lista de archivos

que se supervisarán mediante el seguimiento de cambios.
Use el comando siguiente para ejecutar New-AMSDeployment.ps1 :
.\New-AMSDeployment.ps1 -SubscriptionName '{Subscription Name}' -WorkspaceName '{Workspace Name}' -

WorkspaceLocation '{Azure Location}' -AutomationAccountName {Account Name} -AutomationAccountLocation
{Account Location}
Pasos siguientes
Aprenda a configurar alertas básicas para informar al equipo de problemas y eventos de administración
esenciales.
Una parte clave de la administración de recursos es la recepción de notificaciones cuando se producen

problemas; Las alertas notifican proactivamente las condiciones críticas en función de los desencadenadores de
las métricas, los registros o los problemas de estado del servicio. Como parte de la incorporación a los servicios
de administración de servidores de Azure, puede configurar alertas y notificaciones que ayuden a los equipos
de TI a mantenerse informados de los problemas que se produzcan.
Alertas de Azure Monitor

Azure Monitor ofrece funcionalidades de alerta para enviar notificaciones por correo electrónico o mensajería
cuando se producen errores. Estas funcionalidades se basan en una plataforma común de supervisión de datos
que incluye registros y métricas generados por los servidores y otros recursos. Un conjunto de herramientas
común de Azure Monitor le permite analizar los datos combinados procedentes de varios recursos y usarlos
para desencadenar alertas. Estos desencadenadores pueden incluir:
Valores de métrica
Consultas de búsqueda de registros
Eventos del registro de actividad
Estado de la plataforma Azure subyacente
Pruebas de disponibilidad del sitio web
Consulte la lista de orígenes de datos de Azure Monitor para obtener una descripción más detallada de los
orígenes de los datos de supervisión que recopila este servicio.
Para más información sobre la creación y la administración manuales de alertas mediante Azure Portal, consulte
la documentación de Azure Monitor.
Implementación automatizada de alertas recomendadas

En esta guía se recomienda crear un conjunto de 15 alertas para la supervisión básica de la infraestructura. Los
scripts de implementación se encuentran en el kit de herramientas de alerta del repositorio de GitHub.
Este paquete crea alertas de:
Espacio de disco bajo
Poca memoria disponible
Uso elevado de CPU
Cierres inesperados
Sistemas de archivos dañados
Errores de hardware comunes
El paquete usa hardware de servidor de HPE como ejemplo. Cambie la configuración del archivo de
configuración asociado para reflejar su hardware OEM. También puede agregar más contadores de rendimiento
al archivo de configuración. Para implementar el paquete, ejecute el archivo New-CoreAlerts.ps1 .
Pasos siguientes
Obtenga información sobre las operaciones y los mecanismos de seguridad que admiten las operaciones en
curso.
Administración y seguridad en curso
Fase 3: Administración y seguridad en curso
Una vez que haya incorporado los servicios de administración de servidores de Azure, deberá centrarse en las
configuraciones de operaciones y seguridad en las que se basarán las operaciones en curso. Empezaremos
echando un vistazo a Azure Security Center para proteger el entorno. Después, configuraremos directivas para
mantener el cumplimiento de los servidores y automatizar las tareas comunes. En esta sección se describen los
temas siguientes:
Recomendaciones de seguridad: Azure Security Center ofrece sugerencias para mejorar la seguridad del
entorno. Si sigue estas recomendaciones, podrá ver su impacto reflejado en una puntuación de seguridad.
Habilitar la directiva Configuración de invitado: Use la característica Configuración de invitado de Azure
Policy para auditar la configuración de una máquina virtual. Por ejemplo, puede comprobar si los certificados
están a punto de expirar.
Realizar un seguimiento de los cambios críticos y alertar sobre ellos: Cuando está solucionando un problema,
la primera pregunta que debe hacerse es: "¿qué ha cambiado?" En este artículo, aprenderá a realizar un
seguimiento de los cambios y crear alertas para supervisar de forma proactiva los componentes críticos.
Creación de programaciones de actualizaciones: Programe la instalación de actualizaciones para asegurarse
de que todos los servidores tengan las más recientes.
Ejemplos comunes de Azure Policy: Este artículo proporciona ejemplos de directivas de administración
comunes.
Recomendaciones de seguridad
Azure Security Center es el lugar central para administrar la seguridad de su entorno. Allí encontrará una
evaluación general y recomendaciones específicas.
Se recomienda revisar e implementar las recomendaciones proporcionadas por este servicio. Para más
información sobre las ventajas adicionales de Azure Security Center, vea Seguir las recomendaciones de Azure
Security Center.
Pasos siguientes
Obtenga información sobre cómo habilitar la característica Configuración de invitado de Azure Policy.
Directivas de configuración de invitado
Azure Policy: extensión de configuración de invitado
La extensión Configuración de invitado de Azure Policy se puede usar para auditar la configuración en una
máquina virtual. Configuración de invitado solo se admite de momento en máquinas virtuales de Azure.
Para encontrar la lista de directivas de configuración de invitado, busque la categoría Configuración de
invitado en la página del portal de Azure Policy o ejecute este cmdlet en una ventana de PowerShell para
buscar la lista:
Get-AzPolicySetDefinition | where-object {$_.Properties.metadata.category -eq "Guest Configuration"}
NOTE
La funcionalidad de configuración de invitado se actualiza periódicamente para admitir conjuntos de directivas adicionales.
Compruebe periódicamente si hay nuevas directivas admitidas y evalúe si le resultarán útiles.
Implementación
Utilice el siguiente script de ejemplo de PowerShell para implementar estas directivas para llevar a cabo lo
siguiente:
Compruebe que la configuración de seguridad de las contraseñas en equipos Windows y Linux está
establecida correctamente.
Compruebe que los certificados no están próximos a expirar en máquinas virtuales Windows.
Antes de ejecutar este script, utilice el cmdlet Connect-AzAccount para iniciar sesión. Al ejecutar el script, debe
proporcionar el nombre de la suscripción a la que quiere aplicar las directivas.
# Assign Guest Configuration policy.
param (
[Parameter(Mandatory=$true)]
[string] $SubscriptionName
)
$Subscription = Get-AzSubscription -SubscriptionName $SubscriptionName

$scope = "/subscriptions/" + $Subscription.Id
$PasswordPolicy = Get-AzPolicySetDefinition -Name "3fa7cbf5-c0a4-4a59-85a5-cca4d996d5a6"

$CertExpirePolicy = Get-AzPolicySetDefinition -Name "b6f5e05c-0aaa-4337-8dd4-357c399d12ae"
New-AzPolicyAssignment -Name "PasswordPolicy" -DisplayName "[Preview]: Audit that password security

settings are set correctly inside Linux and Windows machines" -Scope $scope -PolicySetDefinition
$PasswordPolicy -AssignIdentity -Location eastus
New-AzPolicyAssignment -Name "CertExpirePolicy" -DisplayName "[Preview]: Audit that certificates are not
expiring on Windows VMs" -Scope $scope -PolicySetDefinition $CertExpirePolicy -AssignIdentity -Location
eastus
Pasos siguientes
Aprenda a Habilitar el seguimiento y las alertas de los cambios críticos de archivos, servicios, software y el
registro.
Habilitar el seguimiento y las alertas de los cambios críticos
Habilitar el seguimiento y las alertas de los cambios
críticos
Azure Change Tracking e Inventario proporciona alertas sobre el estado de configuración de su entorno híbrido
y los cambios que se realizan en ese entorno. Puede notificar los cambios críticos en los archivos, los servicios,
el software y el Registro que pueden afectar a los servidores implementados.
De forma predeterminada, el servicio de inventario de Azure Automation no supervisa la configuración del
Registro o los archivos. La solución proporciona una lista de las claves del Registro que se recomienda
supervisar. Para ver esta lista, vaya a la cuenta de Azure Automation en Azure Portal y seleccione Inventario >
Editar configuración .
Para más información sobre cada una de las claves del Registro, consulte Seguimiento de cambios en las claves
del Registro. Seleccione cualquier clave que desee evaluar y, a continuación, habilítela. La configuración se aplica
a todas las VM que están habilitadas en el área de trabajo actual.
También puede usar el servicio para realizar un seguimiento de los cambios críticos en los archivos. Por ejemplo,
puede que desee realizar el seguimiento del archivo C:\windows\system32\drivers\etc\hosts porque el sistema
operativo lo usa para asignar nombres de host a direcciones IP. Los cambios en este archivo podrían provocar
problemas de conectividad o redirigir el tráfico a sitios web peligrosos.
Para habilitar el seguimiento del contenido del archivo de hosts, siga los pasos descritos en Habilitación del
seguimiento del contenido de los archivos.
También puede agregar una alerta para los cambios realizados en los archivos de los que está realizando el
seguimiento. Por ejemplo, suponga que desea establecer una alerta para los cambios realizados en el archivo de
hosts. Para hacerlo, seleccione Log Analytics en la barra de comandos o en la búsqueda de registros del
área de trabajo de Log Analytics vinculada. En Log Analytics, use la siguiente consulta para buscar cambios en el
archivo de hosts:
ConfigurationChange | where FieldsChanged contains "FileContentChecksum" and FileSystemPath contains "hosts"
Esta consulta busca cambios en el contenido de los archivos que tienen una ruta de acceso que contiene la
palabra "hosts". También puede buscar un archivo específico cambiando el parámetro de ruta de acceso. (Por
ejemplo, FileSystemPath == "c:\\windows\\system32\\drivers\\etc\\hosts" ).
Después de que la consulta devuelva los resultados, seleccione Nueva regla de aler tas para abrir el editor de
reglas de alertas. También puede acceder a este editor mediante Azure Monitor en Azure Portal.
En el editor de reglas de alertas, revise la consulta y cambie la lógica de la alerta si es necesario. En este caso,
queremos que se genere la alerta si se detectan cambios en cualquier máquina del entorno.
Después de establecer la lógica de la condición, puede asignar grupos de acciones para realizar acciones como
respuesta a la alerta. En este ejemplo, cuando se genera la alerta, se envían mensajes de correo electrónico y se
crea un vale de ITSM. Se pueden realizar muchas otras acciones útiles, como desencadenar una función de
Azure, un runbook de Azure Automation, un webhook o una aplicación lógica.
Una vez configurados todos los parámetros y la lógica, aplique la alerta al entorno.
Ejemplos de alertas y seguimiento
En esta sección se muestran otros escenarios habituales de seguimiento y alertas que puede utilizar.
Archivo de controlador modificado
Utilice la consulta siguiente para detectar si se modifican, agregan o quitan archivos de controlador. Resulta útil
para el seguimiento de cambios en archivos críticos del sistema.
ConfigurationChange | where ConfigChangeType == "Files" and FileSystemPath contains "

c:\\windows\\system32\\drivers\\"
Servicio específico detenido

Utilice la consulta siguiente para realizar el seguimiento de los cambios en los servicios críticos del sistema.
ConfigurationChange | where SvcState == "Stopped" and SvcName contains "w3svc"
Nuevo software instalado

Utilice la consulta siguiente para entornos que necesitan bloquear configuraciones de software.
ConfigurationChange | where ConfigChangeType == "Software" and ChangeCategory == "Added"
Una versión de software específica está o no está instalada en una máquina

Utilice la consulta siguiente para evaluar la seguridad. Esta consulta hace referencia a ConfigurationData , que
contiene los registros del inventario e indica el último estado de configuración notificado, pero no los cambios.
ConfigurationData | where SoftwareName contains "Monitoring Agent" and CurrentVersion != "8.0.11081.0"
Archivo DLL conocido modificado a través del Registro

Utilice la consulta siguiente para detectar los cambios en las claves del Registro conocidas.
ConfigurationChange | where RegistryKey == "HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Session

Manager\\KnownDlls"
Pasos siguientes
Obtenga información acerca de cómo Azure Automation puede crear programaciones de actualizaciones para
administrar las actualizaciones de los servidores.
Creación de programaciones de actualizaciones
Creación de programaciones de actualizaciones
Puede administrar las programaciones de actualizaciones mediante Azure Portal o con los nuevos módulos de
cmdlet de PowerShell.
Para crear una programación de actualización mediante Azure Portal, consulte Programación de una
implementación de actualizaciones.
El módulo Az.Automation ahora admite la configuración de la administración de actualizaciones mediante Azure
PowerShell. El cmdlet New-AzAutomationUpdateManagementAzureQuery permite usar etiquetas, ubicaciones y
búsquedas guardadas para configurar programaciones de actualizaciones para un grupo flexible de máquinas.
Script de ejemplo
En el script de ejemplo de esta sección se muestra el uso del etiquetado y la consulta para crear grupos
dinámicos de máquinas en los que se pueden aplicar programaciones de actualización. Realiza las siguientes
acciones. Puede hacer referencia a las implementaciones de acciones específicas cuando cree sus propios
scripts.
Crea una programación de actualización de Azure Automation que se ejecuta todos los sábados a las
8:00 a. m.
Crea una consulta para todos los equipos que coinciden con estos criterios:
Se ha implementado en las ubicaciones de Azure westus , eastus o eastus2 .
Tiene aplicada una etiqueta Owner con un valor establecido en JaneSmith .
Tiene aplicada una etiqueta Production con un valor establecido en true .
Aplica la programación de actualización a las máquinas consultadas y establece una ventana de actualización
de dos horas.
Antes de ejecutar este script de ejemplo, debe iniciar sesión con el cmdlet Connect-AzAccount. Cuando inicie el
script, proporcione la siguiente información:
Identificador de la suscripción de destino
Grupo de recursos de destino
Nombre del área de trabajo de Log Analytics
Nombre de la cuenta de Azure Automation
<#
.SYNOPSIS
This script orchestrates the deployment of the solutions and the agents.
.Parameter SubscriptionName
.Parameter WorkspaceName
.Parameter AutomationAccountName
.Parameter ResourceGroupName
#>
param (
[string] $SubscriptionId,
[string] $ResourceGroupName,
[string] $WorkspaceName,
[string] $AutomationAccountName,
[Parameter(Mandatory=$false)]
[string] $scheduleName = "SaturdayCriticalSecurity"
)
Import-Module Az.Automation
$startTime = ([DateTime]::Now).AddMinutes(10)
$schedule = New-AzAutomationSchedule -ResourceGroupName $ResourceGroupName `
-AutomationAccountName $AutomationAccountName `
-StartTime $startTime `
-Name $scheduleName `
-Description "Saturday patches" `
-DaysOfWeek Saturday `
-WeekInterval 1 `
-ForUpdateConfiguration
# Using AzAutomationUpdateManagementAzureQuery to create dynamic groups.
$queryScope = @("/subscriptions/$SubscriptionID/resourceGroups/")
$query1Location =@("westus", "eastus", "eastus2")

$query1FilterOperator = "Any"
$ownerTag = @{ "Owner"= @("JaneSmith") }
$ownerTag.Add("Production", "true")
$DGQuery = New-AzAutomationUpdateManagementAzureQuery -ResourceGroupName $ResourceGroupName `

-Scope $queryScope `
-Tag $ownerTag
$AzureQueries = @($DGQuery)
$UpdateConfig = New-AzAutomationSoftwareUpdateConfiguration -ResourceGroupName $ResourceGroupName `

-Schedule $schedule `
-Windows `
-Duration (New-TimeSpan -Hours 2) `
-AzureQuery $AzureQueries `
-IncludedUpdateClassification Security,Critical
Pasos siguientes
Consulte ejemplos de cómo implementar directivas comunes en Azure que pueden ayudar a administrar los
servidores.
Directivas habituales en Azure
Ejemplos comunes de Azure Policy
Azure Policy permite aplicar la gobernanza a los recursos en la nube. Con este servicio es más fácil crear
barreras que garanticen que toda la compañía cumple los requisitos de la directiva de gobierno. Para crear
directivas, use los cmdlets de PowerShell o Azure Portal. En este artículo se proporcionan ejemplos de cmdlets
de PowerShell.
NOTE
Con Azure Policy, las directivas de cumplimiento ( DeployIfNotExists ) no se implementan automáticamente en las
máquinas virtuales existentes. Se debe corregir para mantener el cumplimiento de las VM. Para más información, vea
Corregir los recursos no conformes con Azure Policy.
Ejemplos de directivas comunes

En estas secciones se describen algunas de las directivas más comunes.
Restricción de regiones de recursos
La regulación y el cumplimiento de directivas a menudo dependen del control de la ubicación física en la que se
implementan los recursos. Puede usar una directiva integrada para permitir que los usuarios creen recursos
solo en determinadas regiones de Azure permitidas.
Para encontrar esta directiva en el portal, busque "ubicación" en la página de definición de directivas. O bien,
ejecute este cmdlet para encontrar la directiva:
Get-AzPolicyDefinition | Where-Object { ($_.Properties.policyType -eq 'BuiltIn') `

-and ($_.Properties.displayName -like '*location*') }
El siguiente script muestra cómo asignar la directiva. Cambie el valor de $SubscriptionID para que apunte a la
suscripción a la que quiere asignar la directiva. Antes de ejecutar el script, utilice el cmdlet Connect-AzAccount
para iniciar sesión.
# Specify the value for $SubscriptionID.
$SubscriptionID = <subscription ID>

$scope = "/subscriptions/$SubscriptionID"
# Replace the -Name GUID with the policy GUID you want to assign.
$AllowedLocationPolicy = Get-AzPolicyDefinition -Name "e56962a6-4747-49cd-b67b-bf8b01975c4c"
# Replace the locations with the ones you want to specify.
$policyParam = '{ "listOfAllowedLocations":{"value":["eastus","westus"]}}'

New-AzPolicyAssignment -Name "Allowed Location" -DisplayName "Allowed locations for resource creation" -
Scope $scope -PolicyDefinition $AllowedLocationPolicy -Location eastus -PolicyParameter $policyParam
Puede usar este mismo script para aplicar las otras directivas que se describen en este artículo. Solo tiene que
reemplazar el GUID de la línea que establece $AllowedLocationPolicy con el GUID de la directiva que quiere
aplicar.
Bloquear determinados tipos de recursos
Otra directiva integrada común que se usa para controlar los costos también se puede utilizar para bloquear
determinados tipos de recursos.
Para encontrar esta directiva en el portal, busque "tipos de recursos permitidos" en la página de definición de
directivas. O bien, ejecute este cmdlet para encontrar la directiva:
Get-AzPolicyDefinition | Where-Object { ($_.Properties.policyType -eq "BuiltIn") -and

($_.Properties.displayName -like "*allowed resource types") }
Después de identificar la directiva que quiere usar, puede modificar el ejemplo de PowerShell en la sección
Restringir regiones de recursos para asignar la directiva.
Restringir tamaño de máquina virtual
Azure ofrece una amplia gama de tamaños de VM para admitir distintas cargas de trabajo. Para controlar el
presupuesto, puede crear una directiva que permita solamente un subconjunto de tamaños de máquina virtual
en las suscripciones.
Implementar antimalware
Esta directiva se puede usar para implementar una extensión de Microsoft Antimalware con una configuración
predeterminada en las máquinas virtuales que no están protegidas por antimalware.
El GUID de la directiva es 2835b622-407b-4114-9198-6f7064cbe0dc .
El siguiente script muestra cómo asignar la directiva. Para usar el script, cambie el valor de $SubscriptionID
para que apunte a la suscripción a la que quiere asignar la directiva. Antes de ejecutar el script, utilice el cmdlet
Connect-AzAccount para iniciar sesión.
# Specify the value for $SubscriptionID.
$subscriptionID = <subscription ID>

$scope = "/subscriptions/$subscriptionID"
$antimalwarePolicy = Get-AzPolicyDefinition -Name "2835b622-407b-4114-9198-6f7064cbe0dc"
# Replace location "eastus" with the value that you want to use.
New-AzPolicyAssignment -Name "Deploy Antimalware" -DisplayName "Deploy default Microsoft IaaSAntimalware

extension for Windows Server" -Scope $scope -PolicyDefinition $antimalwarePolicy -Location eastus -
AssignIdentity
Pasos siguientes
Obtenga información sobre otros servicios y herramientas de administración de servidores que hay disponibles.
Servicios y herramientas de administración de servidores de Azure
Servicios y herramientas de administración de
servidores de Azure
Como se describe en la introducción de esta guía, el conjunto de servicios de administración de servidores de

Azure cubre estas áreas:
Migrar
Seguridad
Protección
Supervisión
Configuración
Control
En las secciones siguientes se describen sucintamente estas áreas de administración y se proporcionan vínculos
a información detallada acerca de los principales servicios de Azure compatibles con ellas.
Migrar
Los servicios de migración pueden ayudarle a migrar sus cargas de trabajo a Azure. Para proporcionar la mejor
orientación, el servicio Azure Migrate comienza midiendo el rendimiento del servidor local y evaluando la
idoneidad para la migración. Una vez que Azure Migrate completa la evaluación, puede usar Azure Site
Recovery y Azure Database Migration Service para migrar las máquinas locales a Azure.
Seguridad
Azure Security Center es una aplicación de administración de seguridad completa. Al incorporarse a Security
Center, puede obtener rápidamente una evaluación de la seguridad y el estado de cumplimiento normativo de
su entorno. Para obtener instrucciones sobre la incorporación de los servidores a Azure Security Center, consulte
Configuración de los servicios de administración de Azure para una suscripción.
Protección
Para proteger los datos, debe planear la copia de seguridad, la alta disponibilidad, el cifrado, la autorización y los
problemas operativos relacionados. Estos temas se tratan ampliamente en línea, por lo que aquí nos
centraremos en la creación de un plan de continuidad empresarial y recuperación ante desastres (BCDR).
Incluiremos referencias a la documentación que describe en detalle cómo implementar este tipo de plan.
Al crear estrategias de protección de datos, considere la posibilidad de desglosar las aplicaciones de carga de
trabajo en sus distintos niveles. Este enfoque resulta útil porque cada nivel suele requerir su propio plan de
protección único. Para obtener más información sobre el diseño de las aplicaciones para que sean resistentes,
consulte Diseño de aplicaciones resistentes para Azure.
La protección de datos más básica es la copia de seguridad. Para acelerar el proceso de recuperación en caso de
pérdida de servidores, debe realizar una copia de seguridad no solo de los datos sino también de las
configuraciones de servidor. La copia de seguridad es un mecanismo eficaz para controlar la eliminación
accidental de datos y los ataques de ransomware. Azure Backup puede ayudarle a proteger los datos en Azure y
en los servidores locales que ejecutan Windows o Linux. Para más información sobre las funcionalidades de
Azure Backup y guías paso a paso, consulte la información general del servicio Azure Backup.
Si una carga de trabajo requiere continuidad empresarial en tiempo real ante errores de hardware o una
interrupción del centro de datos, considere la posibilidad de usar la replicación de datos. Azure Site Recovery
proporciona una replicación continua de las máquinas virtuales, una solución que proporciona una pérdida
mínima de datos. Site Recovery también admite varios escenarios de replicación, como los siguientes:
Replicación de VM de Azure entre dos regiones de Azure.
Replicación entre servidores locales.
Replicación entre servidores locales y Azure.
Para más información, consulte la matriz completa de replicación de Azure Site Recovery.
En el caso de los datos del servidor de archivos, otro servicio que se puede tener en cuenta es Azure File Sync.
Este servicio le ayuda a centralizar los recursos compartidos de archivos de su organización en Azure Files sin
renunciar a la flexibilidad, el rendimiento y la compatibilidad de un servidor de archivos local. Para usar este
servicio, siga las instrucciones para implementar Azure File Sync.
Supervisión
Azure Monitor proporciona una vista de varios recursos, como aplicaciones, contenedores y máquinas virtuales.
También recopila datos de varios orígenes:
Azure Monitor para VM proporciona una visión detallada del estado, las tendencias de rendimiento y las
dependencias de las máquinas virtuales. El servicio supervisa el estado del sistema operativo de las
máquinas virtuales de Azure, los conjuntos de escalado de máquinas virtuales y las máquinas en el entorno
local.
Log Analytics es una característica de Azure Monitor. Su rol es fundamental para la función global de
administración de Azure. Sirve como almacén de datos para el análisis de registros y para muchos otros
servicios de Azure. Ofrece un lenguaje de consulta completo y un motor de análisis que proporciona
información sobre el funcionamiento de las aplicaciones y los recursos.
El registro de actividad de Azure es también una característica de Azure Monitor. Proporciona información
sobre los eventos de nivel de suscripción que se producen en Azure.
Configuración
En esta categoría se ajustan varios servicios. Pueden ayudarle a:
Automatizar las tareas de las operaciones.
Administrar las configuraciones del servidor.
Medir el cumplimiento de las actualizaciones.
Programar actualizaciones.
Detectar cambios en los servidores.
Estos servicios son esenciales para la compatibilidad con las operaciones en curso:
Update Management automatiza la implementación de revisiones en el entorno, incluida la implementación
en instancias del sistema operativo que se ejecutan fuera de Azure. Es compatible con sistemas operativos
Windows y Linux, y realiza un seguimiento de las vulnerabilidades clave del sistema operativo y el
incumplimiento provocados por la falta de revisiones.
Change Tracking e Inventario proporciona información sobre el software que se ejecuta en el entorno y
resalta los cambios que se han producido.
Azure Automation permite ejecutar scripts o runbooks de Python y PowerShell para automatizar las tareas
en el entorno. Cuando se usa Azure Automation con Hybrid Runbook Worker, también se pueden ampliar los
runbooks a los recursos locales.
Azure Automation State Configuration permite insertar configuraciones de Desired State Configuration
(DSC) de PowerShell directamente desde Azure. DSC también permite supervisar y conservar las
configuraciones de las cargas de trabajo y los sistemas operativos invitados.
Control
La adopción y la migración a la nube crean nuevos desafíos de administración. Requieren una mentalidad
diferente a medida que pasa de una carga de administración operativa a la supervisión y la gobernanza. Cloud
Adoption Framework comienza con la gobernanza. El marco explica cómo migrar a la nube, cómo será el
recorrido y quién debe estar implicado.
El diseño de la gobernanza para organizaciones estándar es, a menudo, diferente del de las empresas complejas.
Para más información sobre los procedimientos recomendados de gobernanza para una organización estándar,
consulte la Guía de gobernanza para empresas estándar. Para más información sobre los procedimientos
recomendados de gobernanza para una empresa compleja, consulte la Guía de gobernanza para empresas
complejas.
Información de facturación
Para obtener información sobre los precios de los servicios de administración de Azure, vaya a estas páginas:
Azure Site Recovery
Azure Backup
Azure Monitor
Azure Automation, que incluye:
Configuración de estado deseado
Solución Update Management
Solución Seguimiento de cambios e inventario
Azure Policy
Azure File Sync
NOTE
La solución Azure Update Management es gratuita, pero hay un pequeño costo relacionado con la ingesta de datos.
Como regla general, los primeros 5 gigabytes (GB) al mes de ingesta de datos son gratuitos. Hemos observado que
habitualmente cada equipo usa unos 25 MB al mes. Por lo tanto, se incluyen de forma gratuita 200 máquinas al mes. Para
aumentar el número de servidores, multiplique el número de servidores adicionales por 25 MB al mes. A continuación,
multiplique el resultado por el precio del almacenamiento adicional que necesita. Para más información sobre los costos,
consulte Precios de Azure Storage. Cada servidor adicional suele tener un impacto nominal en el costo.
Guía sobre la supervisión en la nube: Introducción
La nube cambia fundamentalmente el modo en que las empresas adquieren y usan los recursos tecnológicos.
En el pasado, las empresas asumían la propiedad y responsabilidad en todos los niveles de tecnología desde la
infraestructura al software. Ahora, la nube ofrece a las empresas la posibilidad de aprovisionar y consumir
recursos según sea necesario.
Aunque la nube ofrece una flexibilidad prácticamente ilimitada en términos de opciones de diseño, las empresas
buscan una metodología probada y coherente para la adopción de tecnologías en la nube. Cada empresa tiene
objetivos y escalas de tiempo diferentes para la adopción de la nube, lo cual hace que sea casi imposible
encontrar un único enfoque de adopción.
Esta transformación digital también permite una oportunidad de modernizar la infraestructura, las cargas de
trabajo y las aplicaciones. Según la estrategia empresarial y los objetivos, la adopción de un modelo de nube
híbrida forma, probablemente, parte del proceso de transición de la migración desde un entorno local al
funcionamiento completo en la nube. Durante este proceso, los equipos de TI se enfrentan al desafío de adoptar
y obtener un valor rápido de la nube. El personal de TI también debe saber cómo supervisar con eficacia la
aplicación o el servicio que se van a migrar a Azure y seguir ofreciendo DevOps y operaciones de TI eficaces.
Las partes interesadas quieren usar herramientas de supervisión y administración de software como servicio
(SaaS) basadas en la nube. Necesitan comprender lo que los servicios y las soluciones ofrecen para lograr una
visibilidad de un extremo a otro, reducir costos y prestar una menor atención a la infraestructura y el
mantenimiento de las herramientas operativas tradicionales de TI basadas en software.
Sin embargo, el equipo de TI suele preferir utilizar las herramientas en las que ya ha realizado una inversión
importante. Este enfoque permite que sus procesos de operaciones de servicio supervisen ambos modelos de
nube, con el objetivo final de realizar la transición a una oferta basada en SaaS. El departamento de TI prefiere
este enfoque no solo porque el planeamiento, los recursos y la financiación del cambio requiere bastante
tiempo. También existe confusión sobre qué productos o servicios de Azure son apropiados o aplicables para
conseguir la transición.
El objetivo de esta guía es proporcionar una referencia detallada para ayudar a los administradores
empresariales de tecnologías de TI, a los responsables de toma de decisiones empresariales y a los arquitectos y
desarrolladores de aplicaciones a comprender:
Las plataformas de supervisión, con información general y una comparación de sus funcionalidades.
La solución que mejor se adapta a la supervisión de cargas de trabajo híbridas, privadas y nativas de Azure.
El enfoque de supervisión de un extremo a otro recomendado tanto para la infraestructura como para las
aplicaciones. Este enfoque incluye soluciones que se pueden implementar para migrar estas cargas de
trabajo comunes a Azure.
Esta no es una guía paso a paso de uso o configuración de servicios y soluciones individuales de Azure, pero
hace referencia a esas fuentes si son aplicables o están disponibles. Después de leerla, comprenderá cómo usar
correctamente una carga de trabajo siguiendo unos procedimientos y patrones recomendados.
Si no está familiarizado con Azure Monitor y System Center Operations Manager, y desea descubrir qué es lo
que los hace únicos y cómo compararlos entre sí, revise Introducción a las plataformas de supervisión.
Público
Esta guía resulta especialmente útil para administradores de empresas, operaciones de TI, seguridad y
cumplimiento de TI, arquitectos de aplicaciones, propietarios del desarrollo de cargas de trabajo y propietarios
de operaciones con estas.
Cómo se estructura esta guía

Este artículo forma parte de una serie. Los siguientes artículos están diseñados para leerlos de forma conjunta y
en orden:
Introducción (este artículo)
Estrategia de supervisión en la nube
Supervisión de la estrategia de la plataforma para los modelos de implementación en la nube
Observabilidad
Recopilación de los datos adecuados
Alertas
Productos y servicios
Hay software y servicios disponibles para ayudarle a supervisar y administrar los diversos recursos hospedados
en Azure, en la red corporativa o en otros proveedores de nube. Son las siguientes:
System Center Operations Manager
Azure Monitor (incluye Log Analytics y Application Insights)
Azure Policy y Azure Blueprints
Azure Arc
Azure Automation
Azure Logic Apps
Azure Event Hubs
En esta primera versión de la guía se describen nuestras plataformas de supervisión actuales: Azure Monitor y
System Center Operations Manager. También se describe la estrategia recomendada para supervisar cada uno
de los modelos de implementación en la nube. También se incluye el primer conjunto de recomendaciones de
supervisión, que comienza con la recopilación de datos, la observabilidad y la generación de alertas.
Pasos siguientes
Estrategia de supervisión para modelos de implementación en la nube
Guía sobre la supervisión en la nube: estrategia de
supervisión para los modelos de implementación en
la nube
En este artículo se incluye la estrategia de supervisión recomendada para cada uno de los modelos de
implementación en la nube, según los criterios siguientes:
Es necesario mantener el compromiso con Operations Manager u otra plataforma de supervisión
empresarial porque está integrado con los procesos, conocimientos y experiencia de las operaciones de TI, o
porque aún no está disponible una cierta funcionalidad en Azure Monitor.
Tiene que supervisar las cargas de trabajo tanto en el entorno local como en la nube pública, o solo en la
nube.
La estrategia de migración a la nube incluye modernizar las operaciones de TI y trasladarse a nuestros
servicios y soluciones de supervisión en la nube.
Es posible que cuente con sistemas críticos que no tienen una conexión física o que están aislados
físicamente, hospedados en una nube privada o en hardware físico, y que sea necesario supervisarlos.
Nuestra estrategia incluye compatibilidad con la supervisión de los recursos de infraestructura (cargas de
trabajo de proceso, almacenamiento y servidor), aplicación (usuario final, excepciones y cliente) y red. Esto
ofrece una perspectiva completa de supervisión orientada a servicios.
Supervisión de la nube de Azure

Azure Monitor es el servicio de plataforma nativo de Azure que proporciona un único origen para la supervisión
de recursos de Azure. Está diseñado para soluciones en la nube que:
Se crean en Azure.
Admiten una funcionalidad empresarial que se basa en cargas de trabajo de máquinas virtuales o en
arquitecturas complejas que usan microservicios y otros recursos de la plataforma.
Supervisa todos los niveles de la pila, empezando por los servicios de inquilino como Azure Active Directory
Domain Services, así como los eventos de suscripción y Azure Service Health.
También supervisa los recursos de infraestructura, como las máquinas virtuales, el almacenamiento y los
recursos de red. En el nivel superior, supervisa la aplicación.
La supervisión de cada una de estas dependencias y la recopilación de las señales correctas que cada una puede
emitir le proporcionan la observabilidad de las aplicaciones y la infraestructura clave que necesita.
En la tabla siguiente se resume el enfoque recomendado para supervisar cada nivel de la pila:
N IVEL RESO URC E Á M B ITO M ÉTO DO

Application Una aplicación basada en la Supervisa una aplicación Application Insights (una
Web que se ejecuta en la web activa para detectar característica de Azure
plataforma .NET, .NET Core, automáticamente anomalías Monitor).
Java, JavaScript y Node.js en de rendimiento, identificar
una máquina virtual de problemas y excepciones de
Azure, Azure App Service, código, y recopilar análisis
Azure Service Fabric, Azure de comportamiento del
Functions y Azure Cloud usuario.
Services.
Recursos de Azure: Servicios de Azure Database Métricas de rendimiento de Habilitar el registro de

plataforma como servicio (por ejemplo, SQL o Azure SQL Database. diagnósticos para transmitir
(PaaS) MySQL). datos de SQL a registros de
Azure Monitor.
Recursos de Azure: 1. Azure Storage 1. Capacidad, disponibilidad En el caso de los elementos

infraestructura como 2. Servicios de equilibrio de y rendimiento. 1 a 5 de la primera
servicio (IaaS) carga de Azure 2. Registros de rendimiento columna, las métricas de
3. Grupos de seguridad de y diagnóstico (actividad, plataforma y el registro de
red acceso, rendimiento y actividad se recopilan
4. Azure Virtual Machines firewall). automáticamente y están
5. Azure Kubernetes Service 3. Supervisa los eventos disponibles en Azure
/ Azure Container Instances que se producen cuando se Monitor para el análisis y la
aplican las reglas y el generación de alertas.
contador de la regla para Configure los valores de
determinar el número de diagnóstico para reenviar
veces que se aplica una los registros de recursos a
regla a las acciones de los registros de Azure
denegar o permitir. Monitor.
4. Supervisa la capacidad, la 4. Habilitar Azure Monitor
disponibilidad y el para VM.
rendimiento en un sistema 5. Habilitar Azure Monitor
operativo de máquina para contenedores.
virtual invitada. Asigna las
dependencias de
aplicaciones hospedadas en
cada máquina virtual,
incluida la visibilidad de las
conexiones de red activas
entre servidores, la latencia
de conexiones entrantes y
salientes, y los puertos en
cualquier arquitectura
conectada a TCP.
5. Supervisa la capacidad, la
disponibilidad y el
rendimiento de las cargas
de trabajo que se ejecutan
en contenedores e
instancias de contenedor.
Red Comunicación entre la Supervisa la disponibilidad, Azure Network Watcher.

máquina virtual y uno o la latencia y los cambios de
más puntos de conexión la topología de red que se
(otra máquina virtual, un producen entre la máquina
nombre de dominio virtual y el punto de
completo, un identificador conexión.
uniforme de recursos o una
dirección IPv4).
Suscripción de Azure Azure Service Health y Acciones administrativas Se entrega en el registro de

estado básico de los realizadas en un servicio o actividad para la
recursos desde la recurso. supervisión y alertas
perspectiva del servicio de El estado de un servicio mediante Azure Monitor.
Azure. de Azure se ha degradado o
no está disponible.
Problemas de estado
detectados con un recurso
de Azure desde la
perspectiva del servicio de
Azure.
Operaciones realizadas
con la escalabilidad
automática de Azure que
indican un error o una
excepción.
Operaciones realizadas
con Azure Policy que
indican que se ha producido
una acción permitida o
denegada.
Registro de las alertas
generadas por Azure
Security Center.
Inquilino de Azure Azure Active Directory Registros de inicios de Habilita el registro de

sesión y de auditoría de diagnóstico y configura la
Azure AD. transmisión a los registros
de Azure Monitor.
Supervisión de la nube híbrida

En muchas organizaciones, la transición a la nube se debe abordar gradualmente y el modelo de nube híbrida
suele ser el primer paso del recorrido. Puede seleccionar cuidadosamente el subconjunto adecuado de
aplicaciones e infraestructura para comenzar la migración, a la vez que evita la interrupción de su actividad
empresarial. Sin embargo, dado que ofrecemos dos plataformas de supervisión que admiten este modelo de
nube, los responsables de la toma de decisiones de TI pueden tener dudas sobre qué plataforma es la mejor
opción para respaldar sus objetivos de negocio y operaciones de TI.
En esta sección, vamos a intentar despejar esas dudas revisando diversos factores y proporcionándole
conocimientos sobre qué plataforma debe considerar.
Tenga en cuenta los siguientes aspectos técnicos clave:
Debe recopilar datos de los recursos de Azure que admitan la carga de trabajo y reenviarlos a las
herramientas del proveedor de servicios locales o administrados existentes.
Debe mantener la inversión actual en System Center Operations Manager y configurarlo para supervisar
los recursos IaaS y PaaS que se ejecutan en Azure. De manera opcional, debido a que supervisa dos
entornos con características diferentes, debe determinar, en función de los requisitos, si la integración con
Azure Monitor respalda su estrategia.
Como parte de la estrategia de modernización para normalizar una única herramienta para reducir
costes y complejidad, se debe comprometer con Azure Monitor para la supervisión de los recursos en
Azure y en la red corporativa.
En la tabla siguiente se resumen los requisitos que Azure Monitor y System Center Operations Manager
admiten con la supervisión del modelo de nube híbrida según un conjunto de criterios comunes.
REQ UISITO A Z URE M O N ITO R O P ERAT IO N S M A N A GER
Requisitos de infraestructura No Sí
Requiere como mínimo un servidor de

administración y una instancia de
SQL Server para hospedar la base de
datos operativa y la base de datos de
almacenamiento de datos de informes.
La complejidad aumenta si se requiere
alta disponibilidad y recuperación ante
desastres, y hay máquinas en varios
sitios, sistemas que no son de
confianza y otras consideraciones de
diseños complejos.
Conectividad limitada: red aislada o sin No Sí

Internet
Conectividad limitada: acceso a Sí Sí

Internet controlado
Conectividad limitada: desconexión Sí Sí

frecuente
Supervisión del estado configurable No Sí
Prueba de disponibilidad de la Sí, limitada Sí

aplicación web (red aislada)
Azure Monitor tiene compatibilidad
limitada en esta área y requiere
excepciones de firewall personalizadas.
Prueba de disponibilidad de la No Sí
aplicación web (distribuida
globalmente)
Supervisión de cargas de trabajo de Sí, limitada Sí

máquinas virtuales
Puede recopilar registros de errores, Admite la supervisión de la mayoría de
eventos de Windows y contadores de las cargas de trabajo de servidor con
rendimiento de IIS y SQL Server. los módulos de administración
Requiere la creación de consultas, disponibles. Requiere que el agente de
alertas y visualizaciones Windows de Log Analytics o el agente
personalizadas. de Operations Manager de la máquina
virtual informe al grupo de
administración de la red corporativa.
Supervisión de IaaS de Azure Sí Sí
Admite la supervisión de la mayor

parte de la infraestructura de la red
corporativa. Realiza un seguimiento del
estado de disponibilidad, las métricas y
las alertas de máquinas virtuales de
Azure, SQL y almacenamiento a través
del módulo de administración de
Azure.
Supervisión de PaaS de Azure Sí Sí, limitada
En función de lo que se admite en el

módulo de administración de Azure.
Supervisión del servicio de Azure Sí Sí
Aunque actualmente no se
proporciona ninguna supervisión
nativa de Azure Service Health
mediante un módulo de
administración, puede crear flujos de
trabajo personalizados para consultar
las alertas de Service Health. Use la
API de REST de Azure para obtener
alertas a través de las notificaciones
existentes.
Supervisión de aplicaciones web Sí No

modernas
Supervisión de aplicaciones web Sí, la limitación varía según el SDK Sí, limitada
heredadas
Admite la supervisión de versiones
anteriores de aplicaciones web de Java
y .NET.
Supervisión de contenedores de Azure Sí No

Kubernetes Service
Supervisión de contenedores de Sí No
Docker o Windows
Supervisión del rendimiento de red Sí Sí, limitada
Admite comprobaciones de
disponibilidad y recopila estadísticas
básicas de los dispositivos de red
mediante el protocolo simple de
administración de redes (SNMP) de la
red corporativa.
Análisis de datos interactivos Sí No
Se basa en informes definidos o

personalizados de SQL Server
Reporting Services, soluciones de
visualización de terceros o una
implementación de Power BI
personalizada. Existen limitaciones de
escala y rendimiento en el
almacenamiento de datos de
Operations Manager. Se puede
integrar con los registros de Azure
Monitor como alternativa para los
requisitos de agregación de datos. La
integración se logra configurando el
conector de Log Analytics.
Diagnósticos de un extremo a otro, Sí Sí, limitada

análisis de la causa principal y solución
de problemas puntuales Admite los diagnósticos de un extremo
a otro y la solución de problemas solo
para infraestructuras y aplicaciones
locales. Utiliza otros componentes de
System Center o soluciones de
asociados.
Visualizaciones interactivas (paneles) Sí Sí, limitada
Proporciona los paneles esenciales con

su consola web de HTML5 o una
experiencia avanzada mediante
soluciones de asociados, como
Squared Up y Savision.
Integración con herramientas de TI y Sí Sí, limitada

DevOps
Recopilación y transmisión en secuencia datos de supervisión a herramientas de terceros o locales

Para recopilar métricas y registros de recursos de la infraestructura y la plataforma de Azure, debe habilitar los
registros de Azure Diagnostics para esos recursos. Además, con las máquinas virtuales de Azure, puede
recopilar métricas y registros del sistema operativo invitado habilitando la extensión de Azure Diagnostics. Para
reenviar los datos de diagnóstico que se emiten desde los recursos de Azure a sus herramientas locales o al
proveedor de servicios administrados, configure Event Hubs para transmitir en secuencias los datos.
Supervisión con System Center Operations Manager
Si bien System Center Operations Manager se diseñó originalmente como una solución local para supervisar las
aplicaciones, las cargas de trabajo y los componentes de la infraestructura que se ejecuta en el entorno de TI,
evolucionó para incluir funcionalidades de supervisión en la nube. Se integra con Azure, Microsoft 365 y
Amazon Web Services (AWS). Puede supervisar los distintos entornos con módulos de administración
diseñados y actualizados para admitirlos.
En el caso de los clientes que han realizado grandes inversiones en Operations Manager para lograr una
supervisión completa que se integre estrechamente con sus procesos y herramientas de administración de
servicios de TI, o los nuevos clientes de Azure, es comprensible que se hagan las preguntas siguientes:
¿Puede Operations Manager continuar proporcionando valor y tiene sentido para la empresa?
¿Resultan adecuadas las características de Operations Manager para nuestra organización de TI?
¿Proporciona la integración de Operations Manager con Azure Monitor la solución de supervisión rentable y
completa que se requiere?
Si ya ha invertido en Operations Manager, no es necesario concentrarse en planear una migración para
reemplazarlo inmediatamente. Con Azure u otros proveedores de nube presentes como una extensión de su
propia red local, Operations Manager puede supervisar las máquinas virtuales invitadas y los recursos de Azure
como si estuvieran en la red corporativa. Este enfoque requiere tener una conexión de red confiable entre la red
y la red virtual en Azure con el ancho de banda suficiente.
Para supervisar las cargas de trabajo que se ejecutan en Azure, necesita:
El módulo de administración de System Center Operations Manager para Azure. Este recopila las
métricas de rendimiento que los servicios de Azure emiten, como los roles web y de trabajo, las pruebas
de disponibilidad de Application Insights (pruebas web), Azure Service Bus, etc. El módulo de
administración usa la API de REST de Azure para supervisar la disponibilidad y el rendimiento de estos
recursos. Algunos tipos de servicios de Azure no tienen ninguna métrica ni supervisores predefinidos en
el módulo de administración, pero se pueden supervisar a través de las relaciones definidas en el módulo
de administración de Azure de los servicios detectados.
El módulo de administración de Azure SQL Database para supervisar la disponibilidad y el rendimiento
de las bases de datos de Azure SQL y las instancias de Azure SQL Database mediante la API REST de
Azure y las consultas de T-SQL en vistas del sistema SQL Server.
Para supervisar el sistema operativo invitado y las cargas de trabajo que se ejecutan en la máquina
virtual, como SQL Server, IIS o Apache Tomcat, deberá descargar e importar el módulo de administración
que admite la aplicación, el servicio y el sistema operativo.
La información se define en el módulo de administración, que describe cómo supervisar las dependencias y los
componentes individuales. Para ambos módulos de administración de Azure, es necesario realizar un conjunto
de pasos de configuración en Azure y Operations Manager para comenzar a supervisar estos recursos.
En la capa de aplicación, Operations Manager ofrece funciones básicas de supervisión de rendimiento de
aplicaciones para algunas versiones heredadas de .NET y Java. Si algunas aplicaciones del entorno de la nube
híbrida operan en modo sin conexión o con aislamiento de red, de manera que no pueden comunicarse con un
servicio en la nube pública, la Supervisión de rendimiento de aplicaciones (APM) de Operations Manager puede
ser una opción viable para ciertos escenarios limitados. En el caso de las aplicaciones que no se ejecutan en
plataformas heredadas, pero que están hospedadas tanto en el entorno local como en cualquier nube pública
que permita la comunicación a través de un firewall (directo o a través de un proxy) con Azure, use Azure
Monitor Application Insights. Este servicio ofrece una supervisión profunda y en el nivel de código, con
compatibilidad de primera clase con ASP.NET, ASP.NET Core, Java, JavaScript y Node.js.
En el caso de las aplicaciones web a las que se puede acceder externamente, debe habilitar un tipo de
transacciones sintéticas conocido como supervisión de la disponibilidad. Es importante saber si la aplicación o
un punto de conexión HTTP/HTTPS crítico en el que se basa la aplicación está disponible y con capacidad de
respuesta. La supervisión de la disponibilidad de Application Insights le permite ejecutar pruebas desde varios
centros de datos de Azure y proporcionar información sobre el estado de la aplicación desde una perspectiva
global.
Aunque Operations Manager sea capaz de supervisar los recursos hospedados en Azure, existen varias ventajas
si se incluye Azure Monitor, ya que sus capacidades solventan las limitaciones de Operations Manager y
establecen una base sólida para respaldar una eventual migración. Aquí revisamos cada una de las ventajas y
desventajas, y recomendamos incluir Azure Monitor en su estrategia de supervisión híbrida.
Desventajas de usar únicamente Operations Manager
El análisis de los datos de supervisión en Operations Manager se suele realizar mediante vistas
predefinidas en módulos de administración a los que se accede desde la consola, los informes de SQL
Server Reporting Services (SSRS) o las vistas personalizadas que crean los usuarios finales. El análisis de
datos ad hoc no es posible de forma predefinida. Los informes de Operations Manager no son flexibles. El
almacenamiento de datos que proporciona la retención a largo plazo de los datos de supervisión no se
escala ni funciona bien. Además, se requiere experiencia en la escritura de instrucciones de T-SQL, el
desarrollo de una solución de Power BI o el uso de soluciones de terceros para el respaldo de los
requisitos de los diversos roles de la organización de TI.
Las alertas de Operations Manager no admiten expresiones complejas ni incluyen lógica de correlación.
Para ayudar a reducir el ruido, las alertas se agrupan para mostrar las relaciones entre ellas y para
identificar sus causas.
Ventajas del uso de Operations Manager con Azure Monitor
Azure Monitor es la manera de solucionar las limitaciones de Operations Manager. Complementa la base
de datos de almacenamiento de datos de Operations Manager mediante la recopilación de datos
importantes de rendimiento y registro. Azure Monitor ofrece un mejor análisis, rendimiento (al consultar
grandes volúmenes de datos) y retención que el almacenamiento de datos de Operations Manager.
Con el lenguaje de consulta de los registros de Azure Monitor, puede crear consultas mucho más
complejas y sofisticadas. Puede ejecutar consultas en terabytes de datos en cuestión de segundos. Puede
transformar rápidamente los datos en gráficos circulares, gráficos de tiempo y muchas otras
visualizaciones. Para analizar estos datos, ya no estará limitado por el trabajo con informes de Operations
Manager que se basan en SQL Server Reporting Services, consultas SQL personalizadas u otras
soluciones alternativas.
Puede ofrecer una experiencia de alertas mejorada mediante la implementación de la solución de
administración de alertas de Azure Monitor. Las alertas que se generan en el grupo de administración de
Operations Manager se pueden reenviar al área de trabajo de Log Analytics de Azure Monitor. Puede
configurar la suscripción responsable de reenviar alertas desde Operations Manager a registros de Azure
Monitor para que reenvíe solo determinadas alertas. Por ejemplo, puede reenviar únicamente las alertas
que cumplan con sus criterios para las consultas que ayuden a la administración de problemas de
tendencias y la investigación de la causa principal de errores o problemas, a través de un único panel.
Además, puede correlacionar otros datos de registro de Application Insights u otros orígenes para
obtener información que ayude a mejorar la experiencia del usuario, aumentar el tiempo de actividad y
reducir el tiempo de resolución de incidentes.
Puede supervisar la infraestructura y las aplicaciones nativas en la nube desde una arquitectura simple o
de varios niveles en Azure mediante Azure Monitor y usar Operations Manager para supervisar la
infraestructura local. Esta supervisión incluye una o más máquinas virtuales, varias máquinas virtuales
colocadas en un conjunto de disponibilidad o un conjunto de escalado de máquinas virtuales, o una
aplicación en contenedor implementada en Azure Kubernetes Service (AKS) que se ejecuta en
contenedores de Windows Server o Linux.
Si necesita una supervisión completa de las cargas de trabajo de Microsoft o de terceros que se ejecutan
en las máquinas virtuales de Azure y tiene escenarios avanzados que no se pueden evaluar solo según
los datos de registro o de rendimiento, use System Center Operations Manager. Sus módulos de
administración ofrecen una lógica avanzada, que incluye un modelo de servicio y estado para determinar
el estado operativo de la carga de trabajo.
Con la característica de asignación de Azure Monitor para VM, puede supervisar las métricas de
conectividad estándar de las conexiones de red entre las máquinas virtuales de Azure y las máquinas
virtuales locales. Las métricas incluyen el tiempo de respuesta, las solicitudes por minuto, el rendimiento
del tráfico y los vínculos. Puede identificar las conexiones con errores, solucionar problemas, realizar la
validación de la migración, ejecutar el análisis de seguridad y verificar la arquitectura general del servicio.
La asignación puede detectar automáticamente componentes de aplicación en sistemas Windows y Linux
y asignar la comunicación entre servicios. Esta automatización le ayuda a identificar conexiones y
dependencias de las que no tenía constancia, a planear y validar la migración a Azure y a minimizar la
especulación durante la resolución de incidentes.
Con Network Performance Monitor, puede supervisar la conectividad de red entre:
La red corporativa y Azure.
Aplicaciones y microservicios críticos de varios niveles.
Ubicaciones de usuario y aplicaciones basadas en web (HTTP/HTTPS).
Esta estrategia ofrece visibilidad del nivel de red, sin necesidad de SNMP. También puede
presentarse en un mapa de topología interactivo, la topología salto a salto de rutas entre el punto
de conexión de origen y de destino. Es una opción mejor que intentar lograr el mismo resultado
con la supervisión de red en Operations Manager u otras herramientas de supervisión de red que
se usan actualmente en su entorno.
Supervisión con Azure Monitor
Aunque una migración a la nube presenta numerosos desafíos, también proporciona oportunidades. Permite a
la organización migrar desde una o varias herramientas locales de supervisión de la empresa para no solo
reducir potencialmente los gastos de capital y los costos operativos, sino también para beneficiarse de las
ventajas que una plataforma de supervisión en la nube como Azure Monitor puede ofrecer a escala de nube.
Examine los requisitos de supervisión y alertas, la configuración de las herramientas de supervisión existentes,
las cargas de trabajo que pasan a la nube. Una vez finalizado el plan, configure Azure Monitor.
Supervise la infraestructura y las aplicaciones híbridas, desde una arquitectura simple o de varios niveles
en la que los componentes se hospedan entre Azure, otros proveedores de nube y la red corporativa. Los
componentes pueden incluir una o más máquinas virtuales, varias máquinas virtuales colocadas en un
conjunto de disponibilidad o un conjunto de escalado de máquinas virtuales, o una aplicación en
contenedor implementada en Azure Kubernetes Service (AKS) que se ejecuta en contenedores de
Windows Server o Linux.
Use Azure Arc para preparar los servidores, las máquinas virtuales, los clústeres de Kubernetes y las
bases de datos en su entorno para la administración como si se ejecutaran en Azure. Azure Arc ofrece
inventario, administración, gobernanza y seguridad coherentes con conocidos servicios y funcionalidades
de administración de Azure.
Habilite Azure Monitor para VM, Azure Monitor para contenedores y Application Insights para detectar y
diagnosticar problemas entre la infraestructura y las aplicaciones. Para un análisis y una correlación más
completos de los datos recopilados de los diversos componentes o dependencias compatibles con la
aplicación, debe usar los registros de Azure Monitor.
Cree alertas inteligentes que se apliquen a un conjunto básico de aplicaciones y componentes de servicio,
ayude a reducir el ruido de las alertas con umbrales dinámicos para señales complejas y use la
agregación de alertas basada en algoritmos de aprendizaje automático para ayudar a identificar
rápidamente el problema.
Defina una biblioteca de consultas y paneles para respaldar los requisitos de los diversos roles de la
organización de TI.
Defina estándares y métodos para habilitar la supervisión en los recursos híbridos y en la nube, una línea
de base de supervisión para cada recurso, umbrales de alerta, etc.
Configure el control de acceso basado en rol de Azure (RBAC de Azure) para conceder a los usuarios y
grupos únicamente el nivel de acceso que necesiten para supervisar los datos de los recursos que
administran.
Incluya automatización y autoservicio para permitir que cada equipo cree, habilite y ajuste las
configuraciones de supervisión y alertas según sea necesario.
Supervisión de la nube privada

Puede lograr una supervisión holística de Azure Stack con System Center Operations Manager. En concreto,
puede supervisar las cargas de trabajo que se ejecutan en el inquilino, en el nivel de recurso, en las máquinas
virtuales y en la infraestructura que hospeda a Azure Stack (servidores físicos y conmutadores de red).
También puede lograr una supervisión holística con una combinación de las funcionalidades de supervisión de
infraestructuras incluidas en Azure Stack. Estas funcionalidades ayudan a ver el estado y las alertas de una
región de Azure Stack y el servicio de Azure Monitor en Azure Stack, que proporciona registros y métricas de
infraestructura de nivel básico para la mayoría de los servicios.
Si ya ha invertido en Operations Manager, use el módulo de administración de Azure Stack para supervisar la
disponibilidad y el estado de mantenimiento de las implementaciones de Azure Stack, incluidas las regiones, los
proveedores de recursos, las actualizaciones, las ejecuciones de actualización, las unidades de escalado, los
nodos de unidad, los roles de la infraestructura y sus instancias (entidades lógicas compuestas por los recursos
de hardware). Este módulo de administración utiliza las API REST del proveedor de recursos de mantenimiento y
actualización para comunicarse con Azure Stack. Para supervisar los servidores físicos y los dispositivos de
almacenamiento, use el módulo de administración de los proveedores OEM (proporcionado, por ejemplo, por
Lenovo, HPE o Dell). Operations Manager puede supervisar de forma nativa los conmutadores de red para
recopilar estadísticas básicas mediante el protocolo SNMP. Es posible supervisar las cargas de trabajo de
inquilinos con el módulo de administración de Azure siguiendo dos pasos básicos. Configure la suscripción que
desea supervisar y, a continuación, agregue los monitores de dicha suscripción.
Pasos siguientes
Guía de supervisión en la nube: observabilidad
Este artículo está pensado para ayudar a las organizaciones a implementar una estrategia de supervisión
coherente de forma más rápida, ya que garantiza que la observabilidad se establezca en la zona de aterrizaje de
Azure (es decir, en cada producto mínimo viable) para cada solución de supervisión.
Como planificador, debe formular un plan de supervisión para un servicio e incluir algunos objetivos de
supervisión. Uno de los objetivos que se recomienda establecer, es que los consumidores de la supervisión
lleguen lo antes posible a un nivel de comodidad o confianza con la solución que está planeando. A
continuación, puede trabajar con otros objetivos, como la creación de informes y de paneles personalizados.
Llamamos a este proceso adopción.
El objetivo de este artículo es aplicar las recomendaciones de la estrategia de supervisión para crear un plan de
supervisión que consiga el objetivo de modernizar y desarrollar la estrategia de operaciones de TI de la
organización. El segundo objetivo es impulsar la madurez operativa; para ello, debemos estar constantemente
atentos a los detalles y la iteración para mejorar el modo en que se supervisan esos servicios.
NOTE
En este artículo, una solución de supervisión es la unidad de producción que realiza la supervisión de un servicio en la
nube y un destino de supervisión es el servicio o aquello que se está supervisando. Una solución abarca todos los
aspectos de la supervisión: la herramienta, los datos de supervisión, las alertas, el tipo de respuesta, las acciones de
recuperación, el tipo de visualización, el acceso basado en roles, etc.
Por qué es importante la observabilidad

Es muy simple: la observabilidad es lo primero que el consumidor de supervisión considera o percibe como el
funcionamiento normal de un servicio. En otras palabras, se busca obtener la visibilidad total, un principio clave
de supervisión, lo antes posible. Una vez que se logra la observabilidad inicial, puede basarse en ese nivel inicial
de visibilidad para desarrollar alertas accionables, crear paneles útiles y evaluar soluciones de AIOps. Esto le
permite familiarizarse con la métrica subyacente y los datos de supervisión de registro.
NOTE
Este es el enfoque opuesto al que se utilizaba en el pasado, cuando los equipos trabajaban para definir todos los
requisitos de supervisión primero en papel, antes de la compilación, prueba e implementación.
Tanto si el plan (es decir, el objetivo) tiene como destino un tipo de recurso de Azure, como Key Vault, un grupo
de recursos completo o incluso de Microsoft 365 Exchange Online, el primer paso es establecer la
observabilidad.
Este enfoque también simplifica los planes. En todos los casos, la visibilidad total significa lograr y mantener la
visibilidad suficiente en tres dimensiones o aspectos:
Supervisión detallada
Supervisión en amplitud
Supervisión en el modelo de estado
Estar atentos a los detalles no es solo un enfoque de TI; recuerde que el objetivo es garantizar que los usuarios
finales pueden consumir el producto y que se cumplan las expectativas empresariales. Por supuesto, no puede
supervisar lo que no conoce y, como resultado, no podrá ofrecer el nivel de disponibilidad del servicio
prometido a la empresa. Antes de la llegada de la informática en la nube, Microsoft destacaba el análisis del
modo de error durante el desarrollo y el diseño de aplicaciones. El análisis del modo de error ayudó a los
desarrolladores a determinar cómo y cuándo podrían producirse errores de lógica u otros errores críticos en el
código. Asimismo, cuando se obtenían esos errores, se podía exponer la condición de forma significativa para
permitir que la herramienta de supervisión no solo la detectara y actuara en ella, sino que también se ofrecía a
los desarrolladores, operadores o ingenieros del sistema información útil para comprender mejor el
comportamiento de las aplicaciones y tomar decisiones controladas en función de los datos. En la actualidad, la
instancia de Cloud Adoption Framework recomienda seguir ese proceso como parte de las fases de diseño y
arquitectura para compilar la recuperación de los servicios de Azure en el diseño.
En pocas palabras, esta es la observabilidad que quiere, al principio y en el producto mínimo viable.
Sistemas de supervisión y observabilidad

La supervisión de la infraestructura y de las aplicaciones es complicada; siempre ha sido así y así seguirá,
incluso con la introducción de la informática en la nube. La transformación empresarial aplica la tecnología para
lograr la estrategia actual y ayudarle a dar forma a su estrategia futura. Asimismo, la nube ha influido aún más
en la naturaleza complicada de la supervisión.
Esto último se muestra en de las formas siguientes:
Los esfuerzos de transformación empresarial (digital) cambian hacia la hiperexplotación de la tecnología
en la nube.
La supervisión se integra en los recursos y grupos de recursos de Azure frente a las herramientas
independientes que administra de forma local.
Las arquitecturas de supervisión nativas de la nube son similares a SIEM, como Azure Monitor. Por lo
tanto se pueden ampliar, están basadas en registros y varias órdenes de magnitud que son más flexibles.
En el caso de los arquitectos, los diagnósticos constituyen el núcleo de la explotación de estructuras de
supervisión nativas de la nube más rentables, que permiten al departamento de TI administrar los servicios de
manera integral en los diferentes modelos de nube.
Los arquitectos, al igual que los operadores, deben comprender qué información de diagnóstico emite una
aplicación o componente de infraestructura de TI. La combinación de flujos de registros multivariantes,
dinámicos, de serie temporal, con eventos, con estado y de telemetría, y su conversión en información valiosa,
depende de lo siguiente:
El conocimiento y la experiencia del desarrollador o ingeniero de sistemas, que tiene un conocimiento
profundo del objetivo de supervisión.
La experiencia real de soporte técnico y la resolución de problemas mediante los datos, para encontrar
problemas o localizar las causas de los mismos.
La revisión de incidentes pasados para encontrar razones no tecnológicas, que luego se pueden
automatizar (reparación automática).
Las instrucciones en forma de documentación, software, entrenamiento o consultoría por parte del
proveedor de software o hardware.
Si está familiarizado con System Center Operations Manager, Microsoft y sus asociados le proporcionarán los
módulos de administración. Los módulos de administración son específicos de la tecnología; por ejemplo, si
importa un módulo de administración de SQL, Operations Manager detecta y apunta automáticamente a los
servidores que alojan SQL Server y comienza a supervisarlos. En este caso, la observación la predefinen más o
menos los ingenieros de productos de Microsoft y de docenas de sectores. Gracias a Operations Manager, no es
necesario preocuparse por las dependencias norte-sur y este-oeste, de modo que la observación del estado de
SQL forma parte del servicio de TI más grande con redes, virtualización y aplicaciones incluidas. Debido a un
esquema común basado en el familiar modelo de mantenimiento de cuatro partes, Operations Manager está
diseñado para funcionar en la infraestructura local. Las arquitecturas de servicios de infraestructura tienden a
corregirse en componentes y patrones arquitectónicos, en relación con los servicios en la nube.
En la nube dispone de una enorme flexibilidad en el tipo de servicios que puede elegir. La supervisión incluye la
manera en que cambian con el tiempo, y pueden ser dinámicos, globales y resistentes. Así pues, como
arquitecto en la nube, el pensamiento local fijo no supone una limitación. Operations Manager puede participar,
pero, de nuevo, recuerde que su fortaleza es la infraestructura y las aplicaciones locales tradicionales. Por el
contrario, la arquitectura de Azure Monitor es mucho más flexible para admitir los tres modelos de nube. Para
poder alcanzar sus objetivos de observabilidad en Azure Monitor, ahora tiene más libertad para decidir sobre
los recursos, dónde ubicarlos geográficamente y cómo visualizar los componentes que funcionan juntos.
Gracias a Azure Monitor, puede aprovechar los libros existentes que se incluyen en Insights y que proporcionan
una funcionalidad similar a la de un módulo de administración en Operations Manager. De lo contrario, debe
revisar la documentación de Azure para cada uno de los servicios de Azure para comprender cómo puede
supervisar y detectar errores conocidos o síntomas que indiquen errores potenciales.
Disciplinas de supervisión
En la ilustración siguiente se muestra la disciplina de observación a la izquierda y, más adelante en esta sección,
se explica cómo Microsoft Azure desempeña un rol central en ella.
Observabilidad y respuesta
La obser vabilidad es un indicador cualitativo de que una solución de supervisión ayuda al consumidor de
supervisión a lograr el nivel de control satisfactorio de un servicio definido. Asimismo, la supervisión
proporciona a los consumidores del servicio una gama adecuada de capacidades y perspectivas de supervisión.
La respuesta es la capacidad de la organización de determinar rápidamente la importancia de los datos de
supervisión observados (eventos detectados, patrones de telemetría, información correlacionada, etc.), de modo
que pueda restaurar o corregir rápidamente los eventos negativos. En el caso de los eventos positivos o los
eventos informativos, pueden ayudarle a mantener los acuerdos de servicio, mejorar la confiabilidad y reducir
los costos de soporte técnico. Los eventos se producen dinámicamente en el sistema o en el servicio, donde las
soluciones de supervisión proporcionan alertas, controlan la automatización de los bucles y notifican incidentes,
problemas o cambios en un sistema externo de administración de servicios de TI (ITSM). Observe que muchos
eventos no se pueden o no se deben corregir automáticamente.
Utilidad: en este sentido, la observabilidad (y respuesta) está relacionada con el uso operativo o la utilidad de la
solución de supervisión. Azure Monitor proporciona a Microsoft la perspectiva de nuestros recursos de servicio
y ofrece funcionalidades similares a las de un sistema de supervisión local. Una solución de supervisión necesita
visualizaciones; por ejemplo, paneles y libros con acceso basado en roles.
La responsabilidad es el elemento que comparten el cliente del servicio y el recurso compartido del
proveedor de servicios para poder aprender y mejorar en función de ciertos datos. Como tal, debe comprender
la responsabilidad del proveedor de la nube en comparación con la responsabilidad del cliente o del
consumidor. Para cada recurso de Azure, obtiene perspectivas basadas en registros o métricas; estos datos se
pueden representar en paneles específicos de recursos o visualizaciones personalizadas en función de sus
requisitos y compartirlos con los roles necesarios de la organización.
NOTE
La observabilidad es una propiedad de un sistema, que se deriva de la teoría de control del sistema. Es una medida de lo
bien que se pueden inferir los estados internos de un sistema a partir de las salidas externas del mismo junto con la
controlabilidad, otra propiedad de un sistema. Además, con el tiempo, un observador estatal mide o calcula el estado de
mantenimiento del sistema gracias al sistema dinámico. En cambio, en términos modernos de administración de servicios,
debe consultar la sección Super visión y control del ser vicio de Microsoft Operations Framework (MOF), y el bucle de
super visión y control de la biblioteca de Infraestructuras de tecnologías de la información (ITIL) v3.
Antes de entrar en detalles sobre la observabilidad, es necesario resaltar varios términos relacionados con la
supervisión que vamos a usar:
Recurso: son recursos digitales como el contenido de recursos compartidos de archivos, hardware y
recursos de software que también se denominan destinos.
Enfoque: es el ámbito para lograr los objetivos; esto es, si es estrecho, amplio, un componente único, la
clase de componente, la agrupación de componentes y el servicio.
Aspecto: son perspectivas, como la de usuario, de la empresa, del propietario del servicio, etc.
Cober tura: es el indicador de visibilidad y de objetivo, para asegurarse de que todos los recursos
pertinentes se incluyen en el ámbito de supervisión.
Capacidad de administración: es la medida en que un recurso digital se puede controlar, reparar
automáticamente y relacionar con el riesgo de cambios y los grupos de acciones que diagnostican o
corrigen elementos automáticamente.
Origen de datos: son los datos de supervisión de la ubicación principal que proceden de, por ejemplo,
una cuenta de almacenamiento de Azure, Azure Active Directory, orígenes personalizados, etc.
Frecuencia: es la supervisión continua frente a la ocasional.
El arte de fijarse en los detalles

La observabilidad se basa en los elementos que se supervisan y cómo se hace. En Azure, hay varios orígenes y
cada uno ofrece una perspectiva diferente de cómo se comporta algo. También cabe mencionar que Azure
incluye varias herramientas que le ayudarán a analizar los distintos aspectos de estos datos. Observar el estado
y el rendimiento de los servicios de Azure y de los recursos que no son de Azure es la forma principal de usar
Azure Monitor y sus características. En Azure, Microsoft tiene un amplio catálogo de servicios y las máquinas
virtuales que no son el foco principal. Asimismo, en Azure se proporciona la perspectiva del proveedor de
servicios a través de diferentes registros de plataforma:
El estado del servicio que comunica Azure acerca de los incidentes del servicio y del mantenimiento
planeado.
El registro de actividad de Azure que notifica los eventos de nivel de suscripción en todos los recursos
implementados en la suscripción.
Azure Resource Health, que informa sobre el mantenimiento actual y pasado de los recursos.
Azure Advisor, que sirve para recibir soluciones recomendadas basadas en procedimientos recomendados
para optimizar las implementaciones de Azure.
Todas las demás perspectivas basadas en métricas y registros se entregan a través de las diversas características
de Azure Monitor. O bien, en función del recurso de Azure, puede ver las métricas de la plataforma directamente
desde ese recurso en el portal.
La observabilidad es un término diseñado para garantizar que Azure Monitor proporciona visibilidad total del
estado, el rendimiento y otros aspectos de los servicios de Azure en profundidad y amplitud. Aún así, existen
otras actividades o estas se centran en la supervisión de servicios y componentes. Ser observador no debe
considerarse algo que solo ciertas personas realizan según sea necesario, según lo requiera su rol o función o
como apoyo de un proceso. Es similar a la astronomía. La observación no es un proceso de un solo paso, sino
que debe supervisar los objetos en el espacio ocasionalmente, en intervalos de tiempo establecidos o de forma
continua. Algunos objetos, como los agujeros negros, son difíciles de observar. Igualmente, el tipo de
supervisión necesario depende del consumidor. Por ejemplo, los astrónomos aficionados observan
ocasionalmente, mientras que los astrofísicos valoran la medición a largo plazo y el seguimiento continuo de las
emisiones de radio.
Con un planeamiento adecuado, puede crear un servicio medio o complejo en Azure en cuestión de horas, en
lugar de necesitar semanas o más en el entorno local. Si lo hiciera, podría organizar una combinación de más de
una docena de recursos de Azure (componentes de servicio) en todas las regiones. Así pues, controlará y
administrará estos recursos mediante Azure Resource Manager y, al usar la supervisión de grupos de recursos
en Azure, obtendrá una imagen del servicio. Una vez en producción, el servicio es dinámico y flexible. El
consumo comienza a aumentar y escalar. La capacidad responde a la demanda. Se producirán eventos y los
consumidores de servicios podrán observar los datos de supervisión, observar las tendencias y establecer su
importancia.
Asimismo, el servicio puede cambiar de formas diferentes e impredecibles a lo largo del tiempo. Por lo tanto,
podríamos decir que este comportamiento es dinámico. Los administradores de servicios en la nube que
observan el servicio a lo largo del tiempo deben tener en cuenta lo siguiente:
Que los recursos se mueven entre ubicaciones o la geografía.
Que los recursos se agregan, eliminan o modifican.
Que el consumo varía.
Como proveedor de servicios de supervisión, el trabajo consiste en facilitar la supervisión de las soluciones que
proporcionan el valor que se muestra en el siguiente orden de prioridad: 1) al servicio, 2) a las partes
interesadas y 3) a los consumidores principales.
El flujo de valor debe tener en cuenta la observabilidad de los servicios de una forma temprana y de las
siguientes maneras:
Debe realizar la supervisión con la profundidad y la amplitud suficientes.
Debe proporcionar cobertura en el modelo de estado (disponibilidad, capacidad, rendimiento, seguridad,
conformidad).
Debe supervisar también la utilidad (lo que hace el servicio), incluida la experiencia del usuario final.
En la estrategia de supervisión, se recomienda establecer un plan de supervisión que empiece por lo mínimo
viable o lo más importante para supervisar y observar. Esto puede basarse en recomendaciones de Microsoft,
en otros orígenes de confianza y de sus desarrolladores internos o ingenieros del sistema, en función del
recurso o del sistema. Establezca la visibilidad inicial del consumo, el rendimiento, la seguridad y la
disponibilidad de los recursos de los grupos de recursos de Azure y el inquilino de Azure Active Directory. A
través de la observación, aprenderá a interpretar los datos y aprenderá qué es importante para ajustar y
optimizar el modo en que se supervisa el servicio. El valor se consigue cuando este es incremental y hay una
creación conjunta de valores en la que los consumidores trabajan con el equipo de supervisión (o en algunos
casos, con el proveedor de servicios) en la creación conjunta del valor.
La observabilidad evoluciona gradualmente, empezando por un plan de supervisión mínimamente viable;
asimismo, el esfuerzo de integrar herramientas y procesos ya está en marcha. A medida que se sienta cómodo
con los datos (es decir, las métricas, los registros y las transacciones), podrá comprender el comportamiento y
los signos de los síntomas o los problemas de esos recursos o aplicaciones. Igualmente, al familiarizarse con los
datos, se crea confianza al trabajar con Azure Monitor y los datos. A través de la observabilidad, obtendrá
confianza, podrá determinar la causa y encontrar respuestas que le puedan ayudar a realizar lo siguiente:
Reducir las zonas ciegas de supervisión asegurándose de todos los componentes de supervisión son
necesarios.
Mejorar la supervisión de recursos y servicios para poder identificar el problema en el futuro. Centrarse en
los problemas o los síntomas que son predecibles y confiables.
Evaluar si no se previeron, qué se puede hacer para mejorar la infraestructura, la aplicación, etc.
Descartar la infraestructura o la aplicación como origen, y determinar si un explorador específico, la versión
del explorador o el sistema operativo del cliente es el posible problema.
Identificar y documentar o implementar soluciones alternativas que pueden usarse para minimizar los
problemas de rendimiento o de disponibilidad de la aplicación, la infraestructura, etc.
Adaptarse a la naturaleza dinámica y compleja de una aplicación. Puede continuar aprendiendo sus patrones
de comportamiento normales con el fin de limitarse a los inusuales.
Ajustar el tipo de datos recopilados, agregados y enviados en alertas para minimizar el costo de
almacenamiento de datos que nunca se analizan, notifican o visualizan.
En un principio ya no necesita preocuparse por la infraestructura o la aplicación tal como se encontraba en un
entorno local y, además, ahora puede supervisar u obtener datos de supervisión para satisfacer las necesidades
de los responsables de la administración y el funcionamiento de la carga de trabajo.
Al igual que sucede con cualquier servicio de infraestructura o aplicación, una lista diversa de partes interesadas
y roles debe obtener acceso a las características de supervisión, los datos y los informes. Antes de ampliar el
acceso a otras partes interesadas, comience con los ingenieros de sistemas, las operaciones o los proveedores
de servicios, ya que son los principales responsables de admitir la carga de trabajo.
Enfoque fijo frente a dinámico

La supervisión local de servicios en el centro de datos se lleva a cabo tradicionalmente con un producto como
System Center Operations Manager. El enfoque de Operations Manager está fuertemente arraigado en la
infraestructura y los servidores, y cuenta con agentes y sistemas operativos. La supervisión de aplicaciones (ya
sea en un contenedor o no), está en la pila y depende de la supervisión de la infraestructura de los servidores
que no se encuentran en esa pila. De forma vertical, verá la cobertura de la solución de abajo arriba,
comenzando por las funciones de red y, en la parte superior, verá la supervisión de la experiencia de usuario.
El largo historial de la supervisión de IaaS revela que la observabilidad puede estar predefinida o, si lo desea,
que se haya diseñado previamente. Un servicio basado en IaaS es aquel en el que los ingenieros de productos
pueden crear módulos de administración de Operations Manager; en esencia, pueden personalizar la solución
de supervisión para la mayoría de los casos de uso admitidos.
Por lo tanto, si necesitan controlar los servicios de infraestructura mediante la supervisión de soluciones, los
clientes buscan más de un enfoque fijo en la mayoría de los casos.
Un enfoque fijo no se puede crear en la nube dada la disposición casi infinita y las combinaciones de recursos
tanto en el espacio como en el tiempo. Cada servicio puede ser único. La observabilidad de los servicios en
Azure debe crearse en función de la naturaleza flexible del servicio (es decir, dinámica, global, resistente,
centrada en el usuario, etc.) o de acuerdo con un conjunto de plantillas de arquitectura, que puede que no
existan todavía.
La observabilidad es una opción fundamental para ver de forma holística cómo funcionan todos los
componentes juntos antes de establecer la importancia de los eventos (alertas, resúmenes, libros, etc.).
De nuevo, la supervisión del servicio en la nube es mucho más flexible y dinámica con una velocidad de cambio
más rápida.
Plan de supervisión
Puede crear un plan de supervisión para describir los objetivos, los requisitos y otros detalles importantes. A
continuación, solicite un acuerdo entre todas las partes interesadas pertinentes de la organización. Un plan de
supervisión debe explicar cómo desarrollar y usar una o varias soluciones de supervisión. Comience a
desarrollar los planes de supervisión antes de la estrategia y las fases de planeación del proyecto.
Al crear el plan, es importante tener en cuenta las cinco disciplinas de supervisión moderna: observar, medir,
responder, aprender y mejorar.
A continuación se proporciona un esquema recomendado y se enumeran las principales consideraciones para
crear un plan individual para los servicios o cuando se estandarizan las características del servicio en la nube,
como los tipos de recursos de Azure o los servicios de Microsoft 365. La esencia del plan es definir la línea de
visibilidad entre el proveedor de servicios (que hará las soluciones de campo) y los consumidores (que
funcionarán o derivarán el valor).
También es importante incluir la programación que hace referencia a cuándo (y cómo), para obtener el enfoque
de administración del trabajo (por ejemplo, DevOps frente a cascada).
Perspectiva empresarial
Un plan de supervisión completo debe tener en cuenta las necesidades empresariales con respecto a la
supervisión, y esto debe incluir un enfoque centrado en el usuario. Al definir el plan, es importante documentar
y compartir los requisitos empresariales y las opciones siguientes sugieren el ámbito de esta parte del plan.
Partes interesadas y consumidores
Flujos y procesos de valor empresarial
Perspectiva y utilidad del usuario final
Requisitos de medición e informes
Riesgos identificados y marcos de control de cumplimiento
Requisitos de control y acceso
Riesgo para la empresa
Perspectiva del servicio
Un plan de supervisión completo debe tener en cuenta lo que los propietarios de servicios necesitan con y
desde la supervisión. Al definir el plan, es importante documentar y compartir sus requisitos y las opciones
siguientes sugieren el ámbito de esta parte del plan.
Partes interesadas y consumidores
Roles y responsabilidad
Definición del servicio
Requisitos de control y acceso
¿Consideraciones arquitectónicas?
Contratos de respaldo de proveedores y asociados
Acuerdos de Servicio (SLA, OLA)
Identificación de la cobertura de garantía de servicio
Requisitos de medición e informes
Riesgos
Perspectiva tecnológica
En esta sección del plan se representa la solución de supervisión mediante la información procedente de la
perspectiva empresarial y del servicio.
Escenarios y casos de usuario
Objetivos técnicos (por ejemplo, redes)
Asignación de dependencias de componentes
Tipos (por ejemplo, nativo en la nube, híbrido, local)
Observacional
Capacidad de respuesta
Medición
Ajuste y optimización
Consideraciones clave
Resuma el plan para asegurarse de que comunica e informa a todos los consumidores, partes interesadas y
niveles de administración pertinentes.
Fases de producción: la solución de supervisión debe estar preparada para el valor cuando el servicio
se active, por lo que la planeación puede incluir la configuración de laboratorio o de preproducción (en
otra suscripción dedicada a esto) para experimentar y probar sus suposiciones. En la nube, un inquilino
de producción suele ser seguro en función de la gobernanza general.
Estrategia: los planes también se pueden volver a asignar a la supervisión y a la estrategia de TI para
que los objetivos de supervisión realicen el seguimiento de la misión o la empresa. Esto depende de si la
carga de trabajo es una nube nativa.
Destinos: en el plan, debe describir y analizar los recursos o servicios de destino que se deben tener en
cuenta y, si es necesario, asignar todos los componentes que se van a supervisar para incluir las
dependencias de servicio. Identifique las brechas de cobertura y determine quién posee parte del
servicio.
Solución: para la solución de supervisión, identifique a los consumidores, las partes interesadas, los
proveedores, los asociados, el acceso y la instrumentación. Supervise también los aspectos, el enfoque, la
respuesta, los informes y los paneles (disponibilidad, seguridad, experiencia del usuario, etc.).
Consideraciones ágiles y eficientes
Producto mínimo viable: permita que el plan defina el producto mínimo viable, que es lo que se
necesita inicialmente para empezar, y continúe desarrollando la solución de supervisión para maximizar
el valor. Por ejemplo, puede definir una tarea futura para compilar otros libros basados en el registro,
anclar elementos a paneles de Azure y expandir el acceso de la parte interesada a Azure Portal.
Empiece desde cualquier nivel y obtenga valor rápidamente: realice experimentos con rapidez y
de forma drástica, y aproveche SaaS, ya que es fácil y útil.
Conozca las barreras: la nube es nueva y algo desconocida, por lo que es recomendable que permita a
los expertos guiarle para no agregar ningún riesgo extra (por ejemplo, exponer datos de supervisión
confidenciales).
Microsoft 365 depende de Azure: cualquier plan adecuado tiene en cuenta el inquilino de Azure con
Microsoft 365 como opción principal. Microsoft 365 depende de Azure AD, y Azure Monitor proporciona
la integración de Microsoft 365 con la administración de puntos de conexión.
Obser vabilidad para todo: céntrese en la visibilidad total antes de enviar una alerta, ya que esto ahora
supone un costo.
Arquitectura del registro: emisores, telemetría, señales, inteligencia artificial y soluciones
preempaquetadas como Intelligent Security Graph. Céntrese más en un enfoque SIEM, en cómo crear
registros dispares en soluciones de registro como los registros de Azure Monitor.
Movilidad de los datos: si supervisa mucho más, deberá centrarse en el emisor del panel y en el lugar
en el que los datos se transmiten a través de Internet y en las regiones de la nube, las conexiones de
ExpressRoute y las VPN.
Super visión de actividades: las auditorías, el inicio de sesión y los registros de actividad ahora son
fáciles de segmentar para los propietarios y la seguridad de los servicios.
Pasos siguientes
Guía sobre la supervisión en la nube: recopilación
de los datos correctos
En este artículo se describen algunas consideraciones para recopilar datos de supervisión en una aplicación de
la nube.
Para observar el estado y la disponibilidad de la solución en la nube, debe configurar las herramientas de
supervisión para recopilar un nivel de señales que se basen en estados de error predecibles. Estas señales son
los síntomas del error, no la causa. Las herramientas de supervisión usan métricas y, para los diagnósticos
avanzados y los análisis de la causa principal, usan registros.
Planee cuidadosamente la supervisión y la migración. Para empezar, incluya al propietario del servicio de
supervisión, al administrador de las operaciones y a otro personal relacionado durante la fase de planeamiento
y continúe contando con ellos en todo el ciclo de desarrollo y lanzamiento. Su enfoque será desarrollar una
configuración de supervisión basada en los criterios siguientes:
¿Cuál es la composición del servicio? ¿Se supervisan las dependencias actualmente? Si es así, ¿hay varias
herramientas implicadas? ¿Hay alguna oportunidad de consolidarla, sin introducir riesgos?
¿Cuál es el Acuerdo de Nivel de Servicio y cómo se mide y se notifica?
¿Qué aspecto debería tener el panel de servicio cuando se produce un incidente? ¿Qué aspecto debería tener
el panel para el propietario del servicio y el equipo que respalda el servicio?
¿Qué métricas genera el recurso que se debe supervisar?
¿Cómo realizarán búsquedas los registros el propietario del servicio, los equipos de soporte técnico y otro
personal?
El modo en que se responda a esas preguntas, y los criterios de alerta, determinarán cómo se usará la
plataforma de supervisión. Si va a migrar desde una plataforma de supervisión o un conjunto de herramientas
de supervisión existentes, use la migración como una oportunidad para volver a evaluar las señales que
recopile. Esto es especialmente cierto ahora que hay varios factores de costo que se deben tener en cuenta
durante la migración o integración con una plataforma de supervisión basada en la nube como Azure Monitor.
Recuerde que los datos de supervisión deben ser procesables. Es necesario haber recopilado datos optimizados
para tener una buena visión general del estado del servicio. La instrumentación que está definida para
identificar incidentes reales debe ser tan sencilla, predecible y confiable como sea posible.
Desarrollo de una configuración de supervisión

El equipo y el propietario del servicio de supervisión normalmente siguen un conjunto común de actividades
para desarrollar una configuración de supervisión. Estas actividades se inician en las fases de planeación
iniciales, continúan con las pruebas y se validan en un entorno que no es de producción; posteriormente, se
amplían para implementarse en producción. Las configuraciones de supervisión se derivan de modos de error
conocidos, de resultados de pruebas de errores simulados y de la experiencia de varias personas de la
organización (el departamento de servicios, las operaciones, los ingenieros y los desarrolladores). En tales
configuraciones se supone que el servicio ya existe, se está migrando a la nube y no se ha rediseñado.
Para obtener los resultados de calidad del nivel de servicio, supervise el estado y la disponibilidad de estos
servicios al principio del proceso de desarrollo. Si supervisa el diseño del servicio o aplicación como una
ocurrencia tardía, los resultados no serán tan buenos.
Para impulsar una resolución más rápida del incidente, tenga en cuenta las siguientes recomendaciones:
Defina un panel para cada componente de servicio.
Use métricas que ayuden a guiar un diagnóstico posterior y a identificar una solución definitiva o temporal
del problema en caso de que no se pueda descubrir la causa principal.
Use las funcionalidades de exploración en profundidad del panel o respalde la personalización de la vista
para mejorarla.
Si necesita registros detallados, las métricas deberían haber ayudado a identificar los criterios de búsqueda.
Si las métricas no resultaron de ayuda, se pueden mejorar para el siguiente incidente.
La adopción de este conjunto de principios puede ayudarle a obtener información casi en tiempo real, así como
una mejor administración del servicio.
Pasos siguientes
Estrategia de alertas
Guía sobre la supervisión en la nube: Alertas
Durante años, las organizaciones de TI se han esforzado por combatir la fatiga por alertas que crean las
herramientas de supervisión implementadas en la empresa. Muchos sistemas generan un gran volumen de
alertas que a menudo se consideran no significativas, mientras que otras son pertinentes pero se pasan por alto
o se omiten. Como resultado, las operaciones de los responsables de TI y de los desarrolladores han tenido
dificultades para satisfacer la calidad de nivel de servicio prometida a los clientes internos o externos. Para
garantizar la confiabilidad, es fundamental comprender el estado de la infraestructura y de las aplicaciones. Para
minimizar la degradación y la interrupción del servicio o para reducir el efecto o el número de los incidentes, es
necesario identificar las causas rápidamente.
Estrategia de alertas correcta

No se puede corregir lo que no se sabe que está dañado.
Alertar sobre lo que importa es fundamental. Para ello, es necesario recopilar y medir las métricas y los
registros correctos. También se necesita una herramienta de supervisión capaz de almacenar, agregar, visualizar,
analizar e iniciar una respuesta automatizada cuando se cumplan las condiciones. Puede mejorar la
observabilidad de los servicios y de las aplicaciones solo si se entiende totalmente su composición. A esa
composición se le asigna una configuración de supervisión detallada que aplica la plataforma de supervisión.
Esta incluye los estados de error predecibles (los síntomas, no la causa del error) que tienen sentido para la
alerta.
Para determinar si un síntoma es un candidato adecuado de una alerta, tenga en cuenta los siguientes
principios:
¿Impor ta? ¿La incidencia es síntoma de un problema real o de un problema que influye en el estado general
de la aplicación? Por ejemplo, ¿le preocupa si el uso de CPU es alto en el recurso? ¿o que una determinada
consulta SQL que se ejecuta en una instancia de base de datos SQL en ese recurso haga un uso elevado de
CPU durante un período prolongado? Dado que la condición de uso de CPU es un problema real, debe
alertar sobre ella. Pero no es necesario notificarlo al equipo, ya que no es de ayuda señalar qué está
causando la condición en primer lugar. Las alertas y notificaciones sobre el problema de utilización del
proceso de consultas SQL son pertinentes y procesables.
¿Es urgente? ¿El problema es real y requiere atención urgente? Si es así, se debe notificar inmediatamente
al equipo responsable.
¿Se ven afectados los clientes? ¿Los usuarios del servicio o de la aplicación resultan afectados a causa
del problema?
¿Se ven afectados otros sistemas dependientes? ¿Hay alertas de dependencias que están
interrelacionadas y que, por lo tanto, se pueden correlacionar para evitar notificar a distintos equipos que
trabajan con el mismo problema?
Formule estas preguntas al desarrollar inicialmente una configuración de supervisión. Pruebe y valide las
suposiciones en un entorno que no sea de producción y, luego, implemente en producción. Las configuraciones
de supervisión se derivan de modos de error conocidos, de resultados de pruebas de errores simulados y de la
experiencia de los distintos miembros del equipo.
Después del lanzamiento de la configuración de supervisión, puede aprender mucho sobre lo que funciona y lo
que no. Piense en los problemas con un alto volumen de alertas desapercibidos en la supervisión pero
advertidos por los usuarios finales, y cuáles fueron las mejores acciones que se tomaron como parte de esta
evaluación. Identifique los cambios que se deben implementar para mejorar la entrega del servicio, como parte
de un proceso continuo de mejora de la supervisión. No consiste solo en evaluar el ruido de las alertas o la
ausencia de ellas, sino también la efectividad de la supervisión de la carga de trabajo. Consiste en la efectividad
de las directivas, procesos y cultura general de alertas para determinar si hay mejoras.
Tanto System Center Operations Manager como Azure Monitor admiten alertas basadas en umbrales estáticos o
incluso dinámicos y acciones configuradas sobre ellos. Algunos ejemplos son las alertas de correo electrónico,
SMS y llamadas de voz para notificaciones simples. Ambos servicios también admiten la integración de la
administración de servicios de TI (ITSM) para automatizar la creación de registros de incidentes y escalarlos al
equipo de soporte técnico correcto, o cualquier otro sistema de administración de alertas que use un webhook.
Cuando sea posible, puede usar cualquiera de los diversos servicios para automatizar las acciones de
recuperación. Por ejemplo, System Center Orchestrator, Azure Automation, Azure Logic Apps o la escalabilidad
automática en caso de cargas de trabajo elásticas. Aunque la acción más normal de alerta es notificar a los
equipos responsables, también podría ser adecuado automatizar las acciones correctivas. Esta automatización
puede ayudar a simplificar todo el proceso de administración de incidentes. La automatización de estas tareas
de recuperación también puede reducir el riesgo de errores humanos.
Alertas de Azure Monitor

Si usa Azure Monitor exclusivamente, siga estas instrucciones a medida que se plantee la velocidad, el costo y el
volumen de almacenamiento.
En función de la característica y configuración que use, puede almacenar los datos de supervisión en cualquiera
de los siguientes seis repositorios:
Base de datos de métricas de Azure Monitor : Una base de datos de serie temporal usada
principalmente para las métricas de la plataforma de Azure Monitor, pero también tiene los datos de
métricas de Application Insights reflejados en ella. La información que entra en esta base de datos tiene
los tiempos de alerta más rápidos.
Recurso de Application Insights : Una base de datos que almacena la mayor parte de la telemetría de
Application Insights en forma de registros.
Área de trabajo de Log Analytics de Azure Monitor : El almacén principal de los datos de registro
de Azure. Otras herramientas pueden enrutar los datos a él y se pueden analizar en registros de Azure
Monitor. Debido a la ingesta e indexación, las consultas de alertas de registro tienen una latencia mayor.
Esta latencia suele ser de entre 5 y 10 minutos, aunque puede ser mayor en determinadas circunstancias.
Registro de actividad : Se usa en todos los eventos de estado del servicio y registro de actividad. Es
posible crear alertas dedicadas. Contiene los eventos de nivel de suscripción que se producen en objetos
de la suscripción, tal como se ha ve desde fuera de esos objetos. Un posible ejemplo es cuando se
establece una directiva o se accede a un recurso o se elimina.
Azure Storage: Almacenamiento de uso general que está respaldado por Azure Diagnostics y otras
herramientas de supervisión. Se trata de una opción de bajo costo para la retención de la telemetría de
supervisión a largo plazo. No se admiten las alertas de datos que están almacenados en este servicio.
Event Hubs: Se suele usar para transmitir datos al entorno local o a otras herramientas de supervisión o
ITSM de los asociados.
Azure Monitor tiene cuatro tipos de alertas, cada una está vinculada en cierto modo al repositorio en el que se
almacenan los datos:
Alerta de métrica: alerta sobre datos de métricas en Azure Monitor. Las alertas se producen cuando un
valor supervisado cruza un umbral definido por el usuario y, después, vuelve al estado "normal".
Alerta de consulta de registro: disponible para alertar sobre los datos de registro de los registros de
Application Insights o Azure Monitor. También puede generar alertas basadas en consultas entre áreas de
trabajo.
Alerta de registro de actividad: alerta sobre los elementos del registro de actividad, a excepción de los
datos de Azure Service Health.
Alerta de Azure Service Health: tipo especial de alerta que se usa solo con problemas de Azure Service
Health que proceden del registro de actividad como, por ejemplo, interrupciones y un mantenimiento
planeado próximo. Tenga en cuenta que este tipo de alerta se configura mediante Azure Service Health,
un servicio complementario de Azure Monitor.
Habilitar las alertas a través de herramientas de asociados
Si usa una solución de alertas externa, enrútelas lo más posible por Azure Event Hubs, que es la ruta más rápida
de Azure Monitor. Tendrá que pagar por la ingesta en Event Hubs. Si el costo es un problema y la velocidad no,
puede usar Azure Storage como alternativa de menor costo. Solo tiene que asegurarse de que las herramientas
de supervisión o ITSM puedan leer Azure Storage para extraer los datos.
Azure Monitor incluye compatibilidad con la integración con otras plataformas de supervisión, y software ITSM,
como ServiceNow. Puede usar alertas de Azure y seguir desencadenando acciones fuera de Azure, según lo
requiera el proceso de administración de incidentes o DevOps. Si quiere generar alertas en Azure Monitor y
automatizar la respuesta, puede iniciar acciones automatizadas mediante Azure Functions, Azure Logic Apps o
Azure Automation, según el escenario y los requisitos.
Ofertas especializadas de supervisión de Azure
Las soluciones de administración generalmente almacenan sus datos en registros de Azure Monitor. Las dos
excepciones son Azure Monitor para VM y Azure Monitor para contenedores. En la tabla siguiente se describe la
experiencia de alerta basada en el tipo de datos concreto y el lugar donde se almacena.
SO L UC IÓ N T IP O DE DATO S C O M P O RTA M IEN TO DE A L ERTA
Azure Monitor para contenedores Los datos de rendimiento medio Cree alertas de métricas si quiere
calculados de nodos y pods se escriben recibir alertas en función de la
en la base de datos de métricas. variación del rendimiento de uso
medido, acumulado a lo largo del
tiempo.
Los datos de rendimiento calculados Cree alertas de consulta de registro si

que usan percentiles de nodos, quiere recibir alertas en función de la
controladores, contenedores y pods se variación del uso medido de clústeres y
escriben en el área de trabajo. Los contenedores. Las alertas de consulta
registros de contenedor y la de registro también se pueden
información de inventario también se configurar en función de los recuentos
escriben en el área de trabajo. de fase de pod y el número de nodos
de estado.
Azure Monitor para máquinas Los criterios de mantenimiento son Se generan alertas cuando el estado
virtuales métricas que se almacenan en la base de mantenimiento cambia de correcto
de datos de métricas. a incorrecto. Esta alerta solo admite
grupos de acciones que están
configurados para enviar notificaciones
por correo electrónico o SMS.
Los datos de registro de rendimiento Cree alertas de consulta de registros.

de asignación y del sistema operativo
invitado se escriben en el área de
trabajo de Log Analytics.
Velocidad más rápida controlada por el costo
La latencia es una de las decisiones más importantes que determinan las alertas y la resolución rápida de
incidencias que afectan a su servicio. Si necesita alertas casi en tiempo real en menos de cinco minutos, evalúe
primero si tiene o puede obtener alertas sobre la telemetría donde se almacena de forma predeterminada. En
general, esta estrategia es también la opción más económica porque la herramienta que usa ya está enviando
los datos a esa ubicación.
Dicho esto, hay algunas notas al pie importantes para esta regla.
La telemetría del sistema operativo invitado tiene varias rutas de acceso para entrar en el sistema.
La forma más rápida de alertar sobre estos datos es importarlos como métricas personalizadas. Para ello,
use la extensión de Azure Diagnostics y, luego, utilice una alerta de métrica. Sin embargo, las métricas
personalizadas se encuentran actualmente en versión preliminar y son más caras que otras opciones.
Lo menos costoso, aunque produce cierta latencia de ingesta, es enviarlas a un área de trabajo de Log
Analytics. Ejecutar el agente de Log Analytics en la máquina virtual es la mejor manera de recoger todos
los datos de registro y métricas del sistema operativo invitado en esta área de trabajo.
Puede enviarlas para el almacenamiento como métricas y registros en Azure Monitor; para ello, ejecute la
extensión Azure Diagnostics y el agente de Log Analytics en la misma máquina virtual. Después puede
generar alertas más rápidamente, pero también puede usar los datos del sistema operativo invitado
como parte de consultas más complejas al combinarlos con otros datos de telemetría.
Impor tar los datos del entorno local: Si intenta consultar y supervisar datos en máquinas que se ejecutan
en Azure y en el entorno local, puede usar el agente de Log Analytics para recopilar datos del sistema operativo
invitado. Después puede usar una característica denominada registros en métricas para simplificar las métricas
en Azure Monitor. Este método omite parte del proceso de ingesta en los registros de Azure Monitor y, por
tanto, los datos están disponibles antes.
Minimizar las alertas
Si usa una solución como Azure Monitor para VM y le parecen aceptables los criterios de mantenimiento
predeterminados que supervisan el uso de rendimiento, no cree alertas de métricas o de consulta de registro
superpuestas basadas en los mismos contadores de rendimiento.
Si no usa Azure Monitor para VM, facilite el trabajo de creación de alertas y administración de notificaciones al
explorar las siguientes características:
NOTE
Estas características solo se aplican a las alertas de métricas; es decir, las alertas basadas en los datos que se envían a la
base de datos de métricas de Azure Monitor. Las características no se aplican a los otros tipos de alertas. Como se
mencionó anteriormente, el objetivo principal de las alertas de métricas es la velocidad. Si recibir una alerta en menos de
cinco minutos no es la principal preocupación, puede usar en su lugar una alerta de consulta de registro.
Umbrales dinámicos: Los umbrales dinámicos examinan la actividad del recurso durante un período de
tiempo y crean umbrales de "comportamiento normal" superiores e inferiores. Cuando la métrica que se
supervisa está fuera de estos umbrales, recibe una alerta.
Alertas de varias señales: Puede crear una alerta de métrica que use la combinación de dos entradas
diferentes de dos tipos de recursos diferentes. Por ejemplo, si quiere activar una alerta cuando el uso de
CPU de una máquina virtual supere el 90 por ciento y el número de mensajes en una determinada cola
de Azure Service Bus que alimenta esa máquina virtual supera una cantidad determinada, puede hacerlo
sin crear una consulta de registro. Esta característica solo funciona para dos señales. Si tiene una consulta
más compleja, suministre los datos de métricas al área de trabajo de Log Analytics y use una consulta de
registro.
Alertas de varios recursos: Azure Monitor permite una única regla de alertas de métricas que se aplica a
todos los recursos de máquina virtual. Esta característica puede ahorrar tiempo, ya que no es necesario
crear alertas individuales para cada máquina virtual. Los precios de este tipo de alerta son los mismos.
Tiene el mismo costo crear 50 alertas para supervisar el uso de CPU de 50 máquinas virtuales, o una
alerta para supervisar el uso de CPU de las 50 máquinas virtuales. También puede usar estos tipos de
alertas en combinación con umbrales dinámicos.
En conjunto, estas características pueden ahorrar tiempo al minimizar las notificaciones de alerta y la
administración de las alertas subyacentes.
Límites de alertas
Asegúrese de tener en cuenta los límites en el número de alertas que puede crear. Algunos límites (pero no
todos) se pueden aumentar mediante una llamada a soporte técnico.
Mejor experiencia de consulta
Si busca tendencias en todos los datos, tiene sentido importar todos los datos en los registros de Azure Monitor,
a menos que ya estén en Application Insights. Puede crear consultas en ambas áreas de trabajo, por lo que no es
necesario mover los datos entre ellas. También puede importar los datos del registro de actividad y de Azure
Service Health en el área de trabajo de Log Analytics. Se paga por esta ingesta y almacenamiento, pero se
obtienen todos los datos en un solo lugar para su análisis y consulta. Este enfoque también le ofrece la
posibilidad de crear condiciones de consulta complejas y alertar sobre ellas.
Guía sobre la supervisión en la nube: Introducción a
las plataformas de supervisión
Microsoft ofrece una gama de funcionalidades de supervisión en dos productos: System Center Operations
Manager, diseñado para el entorno local y después ampliado a la nube, y Azure Monitor, diseñado para la nube,
pero que también puede supervisar sistemas locales. Estas dos ofertas proporcionan servicios de supervisión
principales, como alertas, seguimiento del tiempo de actividad del servicio, supervisión del estado de la
aplicación y la infraestructura, diagnóstico y análisis.
Muchas organizaciones están adoptando las prácticas más recientes en agilidad de DevOps e innovaciones en la
nube, con el fin de administrar sus entornos heterogéneos. Pero también les preocupa su capacidad para tomar
decisiones adecuadas y responsables sobre la forma de supervisar estas cargas de trabajo.
En este artículo se ofrece una introducción general sobre nuestras plataformas de supervisión, para ayudarle a
entender cómo proporciona cada una la funcionalidad de supervisión principal.
Historia de System Center Operations Manager

En el año 2000, nos adentramos en el campo de la administración de operaciones con Microsoft Operations
Manager 2000. En 2007, presentamos una versión rediseñada del producto, System Center Operations
Manager. Pasó de realizar una simple supervisión de instancias de Windows Server y se centró en una
supervisión sólida y completa de aplicaciones y servicios, incluidas las plataformas heterogéneas, los
dispositivos de red y otras dependencias de aplicaciones o servicios. Ahora es una reconocida plataforma de
supervisión de nivel empresarial para entornos locales, del mismo tipo que IBM Tivoli o HP Operations Manager
en el sector. Ha crecido para admitir la supervisión de recursos de proceso y plataforma que se ejecutan en
Azure, Amazon Web Services (AWS) y otros proveedores de nube.
Historia de Azure Monitor

Cuando se lanzó Azure en 2010, la supervisión de los servicios en la nube se proporcionaba con el agente de
Azure Diagnostics, que ofrecía una manera de recopilar datos de diagnóstico de los recursos de Azure. Esta
funcionalidad se consideraba una herramienta de supervisión general y no una plataforma de supervisión de
clase empresarial.
Se presentó Application Insights para adaptarse a los cambios en un sector donde aumentaban los dispositivos
en la nube, móviles e IoT y comenzaban las prácticas de DevOps. Pasó de ser Supervisión de rendimiento de
aplicaciones en Operations Manager a un servicio de Azure, donde ofrece sofisticadas funciones de supervisión
de las aplicaciones web escritas en diversos lenguajes. En 2015 se anunció la versión preliminar de Application
Insights para Visual Studio, que más adelante pasó a conocerse simplemente como Application Insights.
Recopila detalles sobre el rendimiento de las aplicaciones, las solicitudes y las excepciones, y los seguimientos.
En 2015, Azure Operational Insights empezó a estar disponible de forma general. Incluía el servicio Log
Analytics, que recopilaba y buscaba datos de máquinas en Azure, en entornos locales o en otros entornos en la
nube, conectadas a System Center Operations Manager. Se ofrecían Intelligence Packs con una variedad de
configuraciones de administración y supervisión empaquetadas con una recopilación de lógica de consulta y
analítica, visualizaciones y reglas de recopilación de datos para escenarios como la auditoría de seguridad, las
evaluaciones de estado y la administración de alertas. Más adelante, Azure Operational Insights pasó a
conocerse como Log Analytics.
En 2016, la versión preliminar de Azure Monitor se anunció en la conferencia Microsoft Ignite. Proporcionó un
marco común para recopilar métricas de plataformas, registros de diagnóstico de recursos y eventos de registro
de actividades en el nivel de suscripción de cualquier servicio de Azure iniciado desde el marco. Anteriormente,
cada servicio de Azure tenía su propio método de supervisión.
En la conferencia Microsoft Ignite 2018 se anunció que la marca Azure Monitor se ampliaba para incluir varios
servicios diferentes, originalmente desarrollados con una funcionalidad independiente:
Azure Monitor original para la recopilación de métricas de plataforma, registros de diagnóstico de
recursos y registros de actividad solo para recursos de la plataforma Azure.
Application Insights para la supervisión de aplicaciones.
Log Analytics como ubicación principal para la recopilación y el análisis de los datos de registro.
Un nuevo ser vicio unificado de aler tas que reunía los mecanismos de alerta de cada uno de los
servicios mencionados anteriormente.
Azure Network Watcher para supervisar, diagnosticar y ver las métricas de los recursos en una
máquina virtual.
Historia de Operations Management Suite (OMS)

Entre 2015 y abril de 2018, Operations Management Suite (OMS) fue la unión de los siguientes servicios de
administración de Azure por motivos de licencia:
Application Insights
Azure Automation
Azure Backup
Operational Insights (nombre cambiado más adelante a Log Analytics)
Site Recovery
La funcionalidad de los servicios que formaban parte de OMS no cambió cuando se interrumpió OMS. Se
volvieron a combinar en Azure Monitor.
Requisitos de infraestructura
Operations Manager
Operations Manager requiere una infraestructura y un mantenimiento importantes para admitir un grupo de
administración, que es una unidad básica de funcionalidad. Como mínimo, un grupo de administración consta
de uno o varios servidores de administración, una instancia de SQL Server —que hospeda la base de datos de
almacenamiento de datos operativos y de informes— y agentes. La complejidad del diseño de un grupo de
administración depende de varios factores, como el ámbito de las cargas de trabajo que se van a supervisar y el
número de dispositivos o equipos que admiten las cargas de trabajo. Si necesita alta disponibilidad y resistencia
de los sitios, como suele suceder en las plataformas de supervisión empresarial, los requisitos de infraestructura
y el mantenimiento asociado pueden aumentar drásticamente.
Operations Manager
Management Group
Network Device
Web
console UNIX/Linux System
Management
server Agent-managed
system
Operations Operational DB
console
Data Warehouse DB
Agentless-managed
system
Reporting DB
Azure Monitor
Azure Monitor es una oferta de software como servicio (SaaS), en el que toda la infraestructura subyacente se
ejecuta en Azure, bajo la administración de Microsoft. Lleva a cabo tareas de supervisión, análisis y diagnóstico a
escala. Está disponible en todas las nubes nacionales. Microsoft mantiene las partes principales de la
infraestructura (recopiladores, almacén de métricas y registros, y análisis) que dan apoyo a Azure Monitor.
Azure Monitor
Sources Collectors Storage Usage
Insights
Application Container VM Monitoring
Solutions
Application Application Insights

SDK Visualize
Operating System Workbooks Views Dashboards Power BI
Azure Diagnostics
Extension Metrics
Azure Resources
Log Analytics Analyze
Agent
Azure Subscription Metric Explorer Log Analytics
Logs
Activity Log
Azure Tenant
Respond
Other methods Autoscale Alerts
Custom Sources
Integrate
Export APIs Logic Apps
Grey items not part of Azure Monitor, but part of Azure Monitor story.
datos, recopilación
Operations Manager
Agentes
Operations Manager solo recopila datos directamente de los agentes instalados en equipos Windows. Puede
aceptar datos del SDK de Operations Manager, pero este enfoque se utiliza habitualmente para los asociados
que amplían el producto con aplicaciones personalizadas, no para recopilar datos de supervisión. Puede
recopilar datos de otros orígenes, como equipos Linux y dispositivos de red, mediante módulos especiales que
se ejecutan en el agente de Windows, que accede de forma remota a estos otros dispositivos.
Network Device
Linux server
Management
server
Agent-managed
Windows computer
El agente de Operations Manager puede recopilar de varios orígenes de datos en el equipo local, como el
registro de eventos, registros personalizados y contadores de rendimiento. También puede ejecutar scripts, que
pueden recopilar datos del equipo local o de orígenes externos. Se pueden escribir scripts personalizados para
recopilar datos que no se pueden recopilar por otros medios, o para recopilar datos desde una variedad de
dispositivos remotos que de otro modo no se podrían supervisar.
Módulos de administración
Operations Manager realiza toda la supervisión con flujos de trabajo (reglas, monitores y detecciones de
objetos). Estos flujos de trabajo se empaquetan en un módulo de administración y se implementan en agentes.
Hay módulos de administración disponibles para una variedad de productos y servicios, que incluyen reglas y
monitores predefinidos. También se pueden crear módulos de administración para aplicaciones propias y
escenarios personalizados.
Configuración de supervisión
Los módulos de administración pueden contener cientos de reglas, monitores y reglas de detección de objetos.
Un agente ejecuta toda la configuración de supervisión de todos los módulos de administración
correspondientes, determinados mediante reglas de detección. Cada instancia de cada configuración de
supervisión se ejecuta de forma independiente y actúa inmediatamente en los datos que recopila. Así es como
Operations Manager puede lograr alertas casi en tiempo real y el estado de mantenimiento actual de los
recursos supervisados.
Por ejemplo, un monitor podría tomar una muestra de un contador de rendimiento cada pocos minutos. Si ese
contador supera un umbral, establece inmediatamente el estado de mantenimiento de su objeto de destino, lo
que desencadena también inmediatamente una alerta en el grupo de administración. Una regla programada
puede inspeccionar la creación de un evento determinado y activar al instante una alerta cuando se crea ese
evento en el registro de eventos local.
Dado que las configuraciones de supervisión están aisladas entre sí y funcionan desde los orígenes individuales
de datos, Operations Manager tiene dificultades para correlacionar los datos entre varios orígenes. También le
resulta difícil reaccionar a los datos después de que se hayan recopilado. Se pueden ejecutar flujos de trabajo
que accedan a la base de datos de Operations Manager, pero este escenario no es habitual y se usa
normalmente para un número limitado de flujos de trabajo de uso especial.
Operations Manager
Management Group
Network Device
Web
console UNIX/Linux System
Management
server Agent-managed
system
Operations Operational DB
console
Data Warehouse DB
Agentless-managed
system
Reporting DB
Azure Monitor
Orígenes de datos
Azure Monitor recopila datos de diversos orígenes, incluidos los recursos de la infraestructura y la plataforma
de Azure, los agentes en los equipos Windows y Linux, y la supervisión de datos recopilados en Azure Storage.
Cualquier cliente de REST puede escribir datos de registro en Azure Monitor mediante una API, y se pueden
definir métricas personalizadas para las aplicaciones web. Algunos datos de métricas se pueden enrutar a
ubicaciones diferentes, en función de su uso. Por ejemplo, puede usar los datos para las alertas "tan rápidas
como sea posible" o para las búsquedas de análisis de tendencias a largo plazo junto con otros datos de
registro.
Soluciones de supervisión e información
Las soluciones de supervisión usan la plataforma de registros en Azure Monitor para proporcionar supervisión
para una aplicación o un servicio determinados. Normalmente definen la recopilación de datos a partir de los
agentes o de los servicios de Azure y proporcionan consultas y vistas de registros para analizar los datos. No
suelen incluir reglas de alertas, lo que significa que debe definir sus propios criterios de alertas en función de
los datos recopilados.
Las soluciones de información, como Azure Monitor para contenedores y Azure Monitor para VM, usan la
plataforma de registros y métricas de Azure Monitor para proporcionar una experiencia de supervisión
personalizada de una aplicación o un servicio en Azure Portal. Pueden proporcionar supervisión del estado y
condiciones de alerta, además del análisis personalizado de los datos recopilados.
Configuración de supervisión
Azure Monitor separa la recopilación de datos de las acciones realizadas en ellos, lo que aporta compatibilidad
con microservicios distribuidos en un entorno en la nube. Consolida los datos de varios orígenes en una
plataforma de datos común y proporciona funcionalidad de análisis, visualización y alerta basadas en los datos
recopilados.
Todos los datos recopilados por Azure Monitor se almacenan como registros o como métricas, y las distintas
características de Azure Monitor se basan en ambos. Las métricas contienen valores numéricos en una serie
temporal lo cual resulta adecuado para disponer de alertas casi en tiempo real y para la detección rápida de
problemas. Los registros contienen texto o datos numéricos, y se pueden consultar mediante un lenguaje
potente que los hace especialmente útiles para realizar análisis complejos.
Dado que Azure Monitor separa la recopilación de datos de las acciones que se realizan en estos, es posible que
no pueda proporcionar alertas casi en tiempo real en muchos casos. Para generar alertar sobre los datos del
registro, se ejecutan consultas según una programación periódica definida en la alerta. Este comportamiento
permite a Azure Monitor correlacionar fácilmente los datos de todos los orígenes supervisados, lo que a su vez
permite analizar interactivamente los datos de diversas maneras. Esto resulta especialmente útil para realizar
análisis de la causa principal e identificar en qué otras circunstancias puede producirse un problema.
Supervisión del estado

Operations Manager
Los módulos de administración de Operations Manager incluyen un modelo de servicio que describe los
componentes de la aplicación que se está supervisando y su relación. Los monitores identifican el estado de
mantenimiento actual de cada componente en función de los datos y los scripts del agente. Los estados de
mantenimiento se acumulan para que se pueda ver rápidamente el estado de mantenimiento resumido de las
aplicaciones y los equipos supervisados.
Azure Monitor
Azure Monitor no ofrece un método definible por el usuario para implementar un modelo de servicio ni
monitores que indiquen el estado de mantenimiento actual de los componentes del servicio. Dado que las
soluciones de supervisión se basan en las características estándar de Azure Monitor, no proporcionan
supervisión de estado. Las siguientes características de Azure Monitor pueden resultar útiles:
Application Insights: crea un mapa compuesto de la aplicación web y proporciona el estado de
mantenimiento de cada componente o dependencia de la aplicación. Esto incluye el estado de las alertas
y la exploración en profundidad de diagnósticos más detallados de la aplicación.
Azure Monitor para VM: ofrece una experiencia de supervisión de estado para las VM invitadas de
Azure, similar a la de Operations Manager, al supervisar máquinas virtuales Windows y Linux. Evalúa el
estado de componentes clave del sistema operativo desde la perspectiva de la disponibilidad y el
rendimiento, para determinar el estado de mantenimiento actual. Cuando determina que la VM invitada
está experimentando problemas de uso sostenido de los recursos, capacidad de espacio en disco o
relacionados con la funcionalidad básica del sistema operativo, genera una alerta para llamar la atención
sobre este estado.
Azure Monitor para contenedores: supervisa el rendimiento y el estado de Azure Kubernetes Service
o Azure Container Instances. Dicha característica recopila métricas del procesador y de la memoria
procedentes de los controladores, los nodos y los contenedores disponibles en Kubernetes mediante
Metrics API. También recopila los registros de contenedor y los datos de inventario sobre los
contenedores y sus imágenes. Los criterios de mantenimiento predefinidos basados en los datos de
rendimiento recopilados ayudan a identificar si existe un problema de capacidad o un cuello de botella en
los recursos. También se puede comprender el rendimiento global o el rendimiento de un tipo de objeto
Kubernetes específico (pod, nodo, controlador o contenedor).
Análisis de datos
Operations Manager
Operations Manager proporciona cuatro formas básicas de analizar los datos después de su recopilación:
Explorador de estado: ayuda a descubrir qué monitores identifican un problema de estado de
mantenimiento, así como a revisar la información acerca del monitor y las posibles causas de las acciones
relacionadas con él.
Vistas: ofrece visualizaciones predefinidas de los datos recopilados, como, por ejemplo, un gráfico de
datos de rendimiento o una lista de los componentes supervisados y su estado de mantenimiento actual.
Las vistas de diagrama presentan visualmente el modelo de servicio de una aplicación.
Informes: permiten resumir los datos históricos guardados en el almacenamiento de datos de
Operations Manager. Se pueden personalizar los datos en los que se basan las vistas y los informes. Sin
embargo, no hay ninguna característica que permita el análisis complejo o interactivo de los datos
recopilados.
Shell de comandos de Operations Manager : amplía Windows PowerShell con un conjunto adicional
de cmdlets, puede consultar y visualizar los datos recopilados. Esto incluye gráficos y otras
visualizaciones, de forma nativa con PowerShell o mediante la consola web basada en HTML de
Operations Manager.
Azure Monitor
Con el motor de análisis de alta eficacia de Azure Monitor, puede trabajar de forma interactiva con los datos de
registro y combinarlos con otros datos de supervisión para el análisis de tendencias y otros análisis de datos.
Las vistas y los paneles permiten visualizar los datos de consulta de maneras diferentes desde Azure Portal e
importarlos en Power BI. Las soluciones de supervisión incluyen consultas y vistas para presentar los datos que
recopilan. Las soluciones de información como Application Insights, Azure Monitor para VM y Azure Monitor
para contenedores incluyen visualizaciones personalizadas para admitir escenarios de supervisión interactivos.
Alertas
Operations Manager
Operations Manager crea alertas como respuesta a eventos predefinidos, cuando se alcanza un umbral de
rendimiento y cuando cambia el estado de mantenimiento de un componente supervisado. Incluye la
administración completa de las alertas, lo que permite establecer su resolución y asignarlas a distintos
operadores o ingenieros del sistema. Se pueden establecer reglas de notificación que especifiquen qué alertas
enviarán notificaciones proactivas.
Los módulos de administración incluyen varias reglas de alertas predefinidas para distintas condiciones críticas
en la aplicación que se supervisa. Puede ajustar estas reglas o crear reglas personalizadas para los requisitos
específicos de su entorno.
Azure Monitor
Con Azure Monitor, puede crear alertas basadas en una métrica que supera un umbral o en función del
resultado de una consulta programada. Aunque las alertas basadas en métricas pueden lograr resultados casi
en tiempo real, las consultas programadas tienen un tiempo de respuesta más largo, en función de la velocidad
de ingesta e indexación de los datos. En lugar de limitarse a un agente específico, las alertas de consulta de
registro en Azure Monitor permiten realizar análisis con todos los datos almacenados en varias áreas de trabajo.
Estas alertas también incluyen datos de una aplicación de Application Insights específica mediante una consulta
entre áreas de trabajo.
Aunque las soluciones de supervisión pueden incluir reglas de alerta, normalmente se crean en función de los
propios requisitos.
Workflows
Operations Manager
Los módulos de administración de Operations Manager contienen cientos de flujos de trabajo individuales y
determinan tanto los datos que se van a recopilar como la acción que se debe realizar con ellos. Por ejemplo,
una regla podría tomar una muestra de un contador de rendimiento cada pocos minutos y almacenar los
resultados para su análisis. Un monitor podría tomar una muestra del mismo contador de rendimiento y
comparar su valor con un umbral para determinar el estado de mantenimiento de un objeto supervisado. Otra
regla podría ejecutar un script para recopilar y analizar algunos datos en el equipo de un agente y, a
continuación, activar una alerta si devuelve un valor determinado.
Los flujos de trabajo de Operations Manager son independientes entre sí, por lo que resulta difícil realizar un
análisis en varios objetos supervisados. Estos escenarios de supervisión deben basarse en los datos después de
su recopilación, lo que es posible, pero puede ser difícil y no es habitual.
Azure Monitor
Azure Monitor separa la recopilación de datos de las acciones y los análisis efectuados a partir de estos datos.
Los agentes y otros orígenes de datos escriben datos de registro en un área de trabajo de Log Analytics y datos
de métricas en la base de datos de métricas, sin ningún análisis de esos datos ni conocimientos de cómo
podrían usarse. El monitor genera las alertas y realizar otras acciones a partir de los datos almacenados, lo que
permite realizar análisis con datos de todos los orígenes.
Ampliación de la plataforma base

Operations Manager
Operations Manager implementa toda la lógica de supervisión en un módulo de administración, que puede
crear usted mismo o bien obtener de nosotros o de un asociado. Al instalar un módulo de administración, se
detectan automáticamente los componentes de la aplicación o el servicio en agentes diferentes, y se
implementan las reglas y los monitores adecuados. El módulo de administración contiene definiciones de
estado, reglas de alertas, reglas de rendimiento y recopilación de eventos, y vistas para proporcionar una
supervisión completa que admita la aplicación o el servicio de la infraestructura.
El SDK de Operations Manager permite que Operations Manager se integre con plataformas de supervisión de
terceros o software de administración de servicios de TI (ITSM). Algunos asociados utilizan el SDK en los
módulos de administración para admitir la supervisión de dispositivos de red y ofrecer experiencias de
presentación personalizadas, como el panel de HTML5 de Squared Up o la integración con
Microsoft Office Visio.
Azure Monitor
Azure Monitor recopila las métricas y los registros de los recursos de Azure, con poca o ninguna configuración.
Las soluciones de supervisión agregan lógica para la supervisión de una aplicación o un servicio, pero siguen
funcionando en las consultas y vistas de registro estándar en Azure Monitor. Las soluciones de información,
como Application Insights y Azure Monitor para VM, usan la plataforma de Azure Monitor para la recopilación y
el procesamiento de datos. También proporcionan herramientas adicionales para visualizar y analizar los datos.
Puede combinar los datos recopilados por las soluciones de información con otros datos, mediante el uso de
características de Azure Monitor principales, como las alertas y las consultas de registro.
Monitor admite varios métodos de recopilación de datos de supervisión o administración desde recursos
externos o de Azure. A continuación, puede extraer los datos de los almacenes de métricas o registros y
reenviarlos a sus herramientas de supervisión o ITSM. También puede realizar tareas administrativas mediante
la API de REST de Azure Monitor.
Pasos siguientes
Supervisión de los modelos de implementación en la nube
Preparación de las aptitudes para la supervisión de
la nube
Al planear el recorrido de la migración, el objetivo es desarrollar los planes necesarios para guiar la
implementación. Los planes también deben prever cómo funcionarán estas cargas de trabajo antes de que se
realice la transición a producción, y no posteriormente. Las partes interesadas de la empresa esperan servicios
valiosos y los esperan sin interrupciones. Los miembros del personal de TI son conscientes de que necesitan
aprender nuevas aptitudes y adaptarse de modo que estén preparados para emplear con confianza los servicios
de Azure integrados para supervisar eficazmente los recursos en Azure y en entornos híbridos.
Es posible acelerar el desarrollo de las aptitudes necesarias con las siguientes rutas de aprendizaje. Se
organizaron empezando por el aprendizaje de los aspectos básicos y, a continuación, se dividen en tres
dominios de conocimiento principales: infraestructura, aplicación y análisis de datos.
Aspectos básicos
En la introducción a Azure Resource Manager se describen los conceptos básicos de administración e
implementación de recursos de Azure. El personal de TI que administra la experiencia de supervisión en
la empresa debe comprender los ámbitos de administración y el control de acceso basado en roles de
Azure (RBAC de Azure) mediante plantillas de Azure Resource Manager, y la administración de recursos
mediante la CLI de Azure y Azure PowerShell.
La introducción a Azure Policy le ayuda a usar Azure Policy para crear, asignar y administrar directivas.
Azure Policy puede implementar y configurar los agentes de Azure Monitor, habilitar la supervisión con
Azure Monitor para VM y Azure Security Center, implementar la configuración de diagnóstico, auditar la
configuración de invitados, etc.
Revise la introducción a la interfaz de la línea de comandos (CLI) de Azure, la experiencia de línea de
comandos multiplataforma para administrar recursos de Azure. Revise también la introducción a Azure
PowerShell. LinkedIn ofrece, como parte de su curso de nivel básico denominado Aprendizaje de las
herramientas de administración de Azure, sesiones que tratan sobre la CLI de Azure y los lenguajes de
programación de PowerShell:
Uso de la CLI de Azure.
Introducción a Azure PowerShell
Para aprender a proteger los recursos mediante directivas, control de acceso basado en roles de Azure y
otros servicios de Azure, consulte Implementación de la seguridad de administración de recursos en
Azure.
Supervisión de recursos y cargas de trabajo de Microsoft Azure le ayuda a usar herramientas de
supervisión de Azure para supervisar los recursos de red de Azure, así como los locales.
Obtenga información acerca de cómo planear y diseñar las implementaciones de supervisión a escala y
automatizar acciones en Prácticas recomendadas y recomendaciones de Azure Monitor.
Supervisión de infraestructura
Diseño de una estrategia de supervisión para la infraestructura en Microsoft Azure le ayuda a obtener
conocimiento básico sobre las funcionalidades y soluciones de supervisión en Azure.
Cómo supervisar los clústeres de Kubernetes proporciona un análisis detallado de nivel intermedio para
ayudarle a obtener información sobre cómo supervisar el clúster de Kubernetes con Azure Monitor para
contenedores.
Use Azure Monitor para obtener información sobre cómo supervisar los datos de Azure Storage y
HDInsight.
El Cuaderno de estrategias para la supervisión de la base de datos de Microsoft Azure explora las
funcionalidades clave de supervisión que se pueden usar para obtener conclusiones y acciones
recomendadas para Azure SQL Database, Azure SQL Data Warehouse y Azure Cosmos DB.
Supervisión de redes híbridas de nube de Microsoft Azure es un curso avanzado que le ayuda a usar las
herramientas de supervisión de Azure para visualizar, dar mantenimiento y optimizar las redes virtuales,
así como las conexiones de red privada virtual para su implementación en la nube híbrida.
Con Azure Arc para servidores, aprenda a administrar las máquinas Windows y Linux hospedadas fuera
de Azure de forma parecida a como administra las máquinas virtuales que se ejecutan en Azure.
Cómo supervisar las máquinas virtuales proporciona un análisis detallado de nivel intermedio para
ayudarle a obtener información sobre la supervisión de equipos o servidores híbridos y de máquinas
virtuales de Azure o conjuntos de escalado de máquinas virtuales con Azure Monitor para VM.
Supervisión de aplicaciones
Vea cómo Azure Monitor le ayuda a visualizar la disponibilidad y el rendimiento de las aplicaciones y
servicios en un solo lugar. Pluralsight ofrece los siguientes cursos de ayuda:
Microsoft Azure DevOps Engineer: Optimización de los mecanismos de comentarios le ayuda a
prepararse para usar Azure Monitor, incluido Application Insights, para supervisar y optimizar las
aplicaciones web.
Captura y visualización de los tiempos de carga de página en la aplicación web de Azure con
Application Insights. Use este curso como introducción sobre el uso de Azure Monitor Application
Insights para la supervisión de un extremo a otro de los componentes de las aplicaciones que se
ejecutan en Azure.
El cuaderno de estrategias de supervisión de bases de datos de Microsoft Azure le ayuda a
implementar y usar la supervisión de Azure SQL Database, Azure SQL Data Warehouse y Azure
Cosmos DB.
Instrumentación de aplicaciones con Azure Monitor Application Insights es un curso detallado
sobre el uso del SDK de Application Insights para recopilar telemetría y eventos de una aplicación
con componentes de Angular y Node.js.
Depuración y generación de perfiles de la aplicación es una grabación de una conferencia de
Microsoft sobre el uso e interpretación de los datos proporcionados por las herramientas de
depuración de instantáneas y generación de perfiles de Azure Monitor Application Insights.
Análisis de datos
Aprenda a escribir consultas de registro en Azure Monitor. El lenguaje de consulta Kusto es el recurso
principal para escribir consultas de registro de Azure Monitor para explorar y analizar los datos de
registro entre los datos recopilados de Azure y las dependencias de las aplicaciones de recursos híbridos,
incluida la aplicación activa.
Lenguaje de consulta Kusto (KQL) desde cero es un curso completo que incluye ejemplos detallados
sobre una amplia gama de casos de uso y técnicas para el análisis de registros en los registros de Azure
Monitor.

Azure DevOps y administración de proyectos

El entorno de nube híbrida supone un obstáculo para TI ya que presenta roles, responsabilidades y actividades
no definidos. Las organizaciones deben evolucionar a unos procedimientos más modernos de administración de
servicios, entre los que se incluyen las metodologías Agile y DevOps, para satisfacer mejor las necesidades de
transformación y optimización de las empresas actuales de una manera simplificada y eficaz.
Como parte de la migración a una plataforma de supervisión en la nube, el equipo de TI responsable de
administrar la supervisión en la empresa debe incluir entrenamiento y participación ágiles en actividades de
DevOps. Esto también incluye el desarrollo en DevOps que toma los requisitos y los convierte en requisitos
ágiles organizados con el fin de ofrecer soluciones de supervisión mínimamente viables que se refinan de
manera iterativa y en línea con las necesidades empresariales. Para que el control de código fuente administre
los paquetes de la solución de supervisión iterativa y cualquier otro material relacionado, conecte el proyecto de
Azure DevOps Server a un repositorio de GitHub Enterprise Server. Esto proporciona un vínculo entre las
confirmaciones y las solicitudes de incorporación de cambios de GitHub en los elementos de trabajo. Puede usar
GitHub Enterprise para el desarrollo con el fin de apoyar la integración e implementación continuas de la
supervisión al tiempo que usa Azure Boards para planear y realizar un seguimiento de su trabajo.
Para más información, consulte lo siguiente:
Introducción a Azure DevOps
Introducción a DevOps Dojo: creación de métodos eficientes para el negocio.
Evolución de las prácticas de DevOps.
Automatización de las implementaciones con Azure DevOps.
Otras consideraciones
A menudo, los clientes tienen dificultades para administrar, mantener y ofrecer los resultados empresariales
esperados, al igual que la organización de TI con respecto a los servicios que TI tiene obligación de proporcionar.
La supervisión se considera fundamental para administrar la infraestructura y el negocio, ya que se centra en la
medición de la calidad del servicio y la experiencia del cliente. Con el fin de lograr estos objetivos, siente las
bases mediante el uso de ITSM junto con DevOps, los cuales ayudarán al equipo de supervisión a consolidar la
forma en que administran, entregan y apoyan al servicio de supervisión. La adopción de un marco de ITSM
permite al equipo de supervisión funcionar como proveedor y obtener reconocimiento como un facilitador
empresarial de confianza mediante la alineación con los objetivos estratégicos y las necesidades de la
organización.
Repase lo siguiente para conocer las actualizaciones realizadas en el marco de trabajo de ITSM más popular, las
notas del producto ITIL v4 y la nube, que se centra en combinar la guía de ITIL existente con los procedimientos
recomendados de DevOps, Agile y Lean. Tenga en cuenta también la arquitectura de referencia de IT4IT que
proporciona un plano técnico alternativo sobre como transformar TI mediante un marco independiente de los
procesos.
Más información
Para descubrir más rutas de aprendizaje, eche un vistazo al catálogo de Microsoft Learn. Use el filtro de roles
para alinear las rutas de aprendizaje con su rol.
Centralización de operaciones de administración
Para la mayoría de las organizaciones, el uso de un único inquilino de Azure Active Directory (Azure AD) para
todos los usuarios simplifica las operaciones de administración y reduce los costos de mantenimiento. Esto se
debe a que todas las tareas de administración pueden realizarlas usuarios designados, grupos de usuarios o
entidades de servicio dentro de ese inquilino.
Si es posible, se recomienda que use un único inquilino de Azure AD en cada organización. No obstante, algunas
situaciones pueden requerir que una organización mantenga varios inquilinos de Azure AD por los siguientes
motivos:
Es una subsidiaria totalmente independiente.
Funciona de forma independiente en varias zonas geográficas.
Se aplican determinados requisitos de cumplimiento o de tipo legal.
Se adquirieron otras organizaciones (a veces de forma temporal hasta que se define una estrategia de
consolidación de inquilinos a largo plazo).
Cuando se requiere una arquitectura de multiinquilino, Azure Lighthouse proporciona una manera de
centralizar y simplificar las operaciones de administración. Las suscripciones de varios inquilinos se pueden
incorporar para la administración de recursos delegados de Azure. Esta opción permite a los usuarios
especificados en el inquilino de administración realizar funciones de administración entre inquilinos de una
manera centralizada y escalable.
Por ejemplo, supongamos que su organización tiene un solo inquilino, Tenant A . Posteriormente, la
organización adquiere dos inquilinos adicionales, Tenant B y Tenant C y, por motivos empresariales, ambos
deben mantenerse como inquilinos independientes.
Su organización quiere usar las mismas definiciones de directiva, prácticas de copia de seguridad y procesos de
seguridad en todos los inquilinos. Dado que ya tiene usuarios (incluidos los grupos de usuarios y las entidades
de servicio) que son responsables de realizar estas tareas en Tenant A , puede incorporar todas las
suscripciones en Tenant B y en Tenant C , con el fin de que los mismos usuarios de Tenant A puedan realizar
esas mismas tareas. Tenant A a continuación, se convierte en el inquilino de administración de Tenant B y
Tenant C .
Para más información, consulte Azure Lighthouse en escenarios empresariales.
Establecimiento de una revisión de adecuación
operativa
Una vez que la empresa comienza a trabajar con cargas de trabajo en Azure, el siguiente paso es establecer un
proceso de revisión de la adecuación operativa. Este proceso enumera, implementa y revisa de forma iterativa
los requisitos no funcionales de estas cargas de trabajo. Los requisitos no funcionales están relacionados con el
comportamiento operativo esperado del servicio.
Hay cinco categorías esenciales de requisitos no funcionales, que se denominan los fundamentos de la
excelencia de la arquitectura:
Optimización de costos
Eficiencia del rendimiento
Confiabilidad
Seguridad
El proceso de revisión de la adecuación operativa garantiza que sus cargas de trabajo críticas cumplen las
expectativas de la empresa con respecto a estos fundamentos.
Lleve a cabo un proceso de revisión de la adecuación operativa para entender los problemas derivados de
ejecutar cargas de trabajo en un entorno de producción y cómo solucionar y resolver los problemas. En este
artículo se describe un proceso general de revisión de la adecuación operativa que puede usar su empresa para
conseguir este objetivo.
Adecuación operativa en Microsoft

Desde el principio, muchos equipos de Microsoft han participado en el desarrollo de la plataforma Azure. Es
difícil garantizar la calidad y la coherencia de un proyecto de tal tamaño y complejidad. Necesita un proceso
sólido para enumerar e implementar los requisitos fundamentales no funcionales de forma periódica.
Los procesos que Microsoft sigue constituyen la base de los procesos que se describen en este artículo.
Comprender el problema
Como se describe en Primeros pasos: Aceleración de la migración, el primer paso en la transformación digital de
una empresa es identificar los problemas empresariales que se van a resolver con la adopción de Azure. El
siguiente paso es determinar una solución general para el problema, como la migración de una carga de trabajo
a la nube o la adaptación de un servicio local existente para incluir funcionalidad de nube. Por último, diseña e
implementa la solución.
Durante este proceso, el foco suelen ser las características del servicio: el conjunto de requisitos funcionales que
desea que el servicio realice. Por ejemplo, un servicio de entrega de productos requiere funciones para
determinar las ubicaciones de origen y destino del producto, realizar el seguimiento del producto durante la
entrega y enviar notificaciones al cliente.
En cambio, los requisitos no funcionales se relacionan con propiedades como la disponibilidad, la resistencia y la
escalabilidad del servicio. Estas propiedades se diferencian de los requisitos funcionales en que no influyen
directamente sobre la función final de ninguna característica en particular del servicio. Sin embargo, los
requisitos no funcionales están relacionados con el rendimiento y la continuidad del servicio.
Puede especificar algunos requisitos no funcionales en los términos de un Acuerdo de Nivel de Servicio (SLA).
Por ejemplo, puede expresar la continuidad del servicio como un porcentaje de disponibilidad: "Disponible el
99,99 por ciento del tiempo". Otros requisitos no funcionales pueden ser más difíciles de definir y pueden
cambiar a medida que cambian las necesidades de producción. Por ejemplo, un servicio orientado al
consumidor podría comenzar a toparse con requisitos de rendimiento no anticipados tras un aumento
repentino de popularidad.
NOTE
Para obtener más información sobre los requisitos de resistencia, consulte Diseño de aplicaciones confiables de Azure. Este
artículo incluye explicaciones de conceptos como el objetivo de punto de recuperación (RPO), el objetivo de tiempo de
recuperación (RTO) y el Acuerdo de Nivel de Servicio.
Proceso de revisión de la adecuación operativa

La clave para mantener el rendimiento y la continuidad de los servicios de una empresa es implementar un
proceso de revisión de la adecuación operativa.
En un nivel alto, el proceso tiene dos fases. En la fase de requisitos previos, se establecen los requisitos y se
asignan a los servicios correspondientes. Esta fase se produce con poca frecuencia; quizás cada año o cuando se
introducen nuevas operaciones. El resultado de la fase de requisitos previos se usa en la fase de flujo. La fase de
flujo se produce con más frecuencia; por ejemplo, una vez al mes.
Fase de requisitos previos
En los pasos descritos en esta fase se capturan los requisitos para llevar a cabo una revisión periódica de los
servicios importantes.
1. Identificar las operaciones empresariales críticas. Identifique las operaciones empresariales
críticas de la empresa. Las operaciones empresariales son independientes de cualquier funcionalidad de
servicio complementaria. En otras palabras, las operaciones empresariales representan las actividades
reales que el negocio debe realizar y están respaldadas por un conjunto de servicios de TI.
El término crítico (o crítico para el empresa) refleja un impacto grave en la empresa si se impide la
operación. Por ejemplo, un minorista en línea puede tener una operación empresarial del tipo "permitir
que un cliente agregue un artículo al carro de la compra" o "procesar un pago con tarjeta de crédito". Si
alguna de estas operaciones genera un error, el cliente no puede realizar la transacción y la empresa no
puede realizar ventas.
2. Asignar operaciones a ser vicios. Asigne las operaciones empresariales críticas a los servicios
correspondientes. En el ejemplo del carro de la compra, pueden intervenir varios servicios, incluido un
servicio de administración del stock de inventario y un servicio de carro de la compra. Para procesar un
pago con tarjeta de crédito, un servicio de pago local podría interactuar con un servicio de
procesamiento de pagos de terceros.
3. Analizar las dependencias de los ser vicios. La mayoría de las operaciones empresariales requiere la
orquestación de varios servicios. Es importante comprender las dependencias entre los servicios y el
flujo de transacciones críticas a través de estos servicios.
Considere también las dependencias entre los servicios locales y los servicios de Azure. En el ejemplo de
carro de la compra, el servicio de administración de existencias de inventario podría estar hospedado en
el entorno local e ingerir los datos introducidos por los empleados desde un almacén físico. Sin embargo,
podría almacenar los datos fuera del entorno local en un servicio de Azure, como Azure Storage, o en una
base de datos, como Azure Cosmos DB.
Una salida de estas actividades es un conjunto de métricas del cuadro de mandos de las operaciones de servicio.
El cuadro de mandos mide criterios como la disponibilidad, la escalabilidad y la recuperación ante desastres. Las
métricas del cuadro de mandos expresan los criterios operativos que se espera que el servicio cumpla. Estas
métricas se pueden expresar con cualquier nivel de detalle que sea necesario para la operación del servicio.
El cuadro de mandos debe expresarse en términos sencillos para facilitar la comunicación significativa entre los
propietarios de empresa y los ingenieros. Por ejemplo, una métrica de cuadro de mandos para la escalabilidad
podría estar codificada por colores de una manera sencilla. El verde indica que se cumplen los criterios
deseados, el amarillo, que no se cumplen los criterios deseados pero se está en proceso de implementar un plan
de corrección, y el rojo que no se cumplen los criterios deseados con ningún plan o acción.
Es importante destacar que estas métricas deben reflejar directamente las necesidades empresariales.
Fase de revisión de los servicios
La fase de revisión de los servicios es el núcleo del proceso de revisión de la adecuación operativa. Implica estos
pasos:
1. Medir las métricas de los ser vicios. Use las métricas del cuadro de mandos para supervisar los
servicios con el fin de garantizar que cumplen las expectativas empresariales. La supervisión de los
servicios es fundamental. Si no puede supervisar un conjunto de servicios con respecto a los requisitos
no funcionales, las métricas del cuadro de mando correspondientes se deben considerar en rojo. En este
caso, el primer paso para solucionarlo es implementar la supervisión de los servicios adecuada. Por
ejemplo, si la empresa espera que un servicio funcione con una disponibilidad del 99,99 por ciento, pero
no dispone de datos de telemetría de producción para medir la disponibilidad, dé por hecho que no
satisface el requisito.
2. Planear las acciones correctivas. Para cada operación de servicio con métricas que se encuentren por
debajo de un umbral aceptable, determine el costo de corregir el servicio para llevar la operación a un
nivel aceptable. Si el costo de la corrección del servicio es mayor que ingresos esperados del servicio,
pase a considerar los costos no tangibles como la experiencia del cliente. Por ejemplo, si los clientes
tienen dificultad para realizar pedidos correctamente con el servicio, podrían elegir en su lugar a la
competencia.
3. Implementar el plan correctivo. En cuanto los propietarios del negocio y el equipo de ingeniería
acuerden un plan, impleméntelo. Informe del estado de la implementación cada vez que revise las
métricas del cuadro de mandos de revisión.
Este proceso es iterativo y lo ideal es que la empresa tenga un equipo destinado a él. Este equipo debe reunirse
periódicamente para revisar los proyectos de corrección existentes, poner en marcha la revisión de aspectos
básicos de nuevas cargas de trabajo y realizar un seguimiento del cuadro de mandos general de la empresa. El
equipo debe tener la autoridad necesaria para hacer responsables a los equipos de corrección si se retrasan o
no cumplen las métricas.
Estructura del equipo de revisión
El equipo de revisión de la adecuación operativa se compone de los siguientes roles:
Propietario de la empresa: proporciona los conocimientos del negocio para identificar y clasificar por
orden de prioridad cada operación empresarial crítica. Este rol también compara el costo de la solución
con la repercusión para el negocio y conduce la decisión final sobre la corrección.
Defensor del negocio: Divide las operaciones empresariales en diferentes partes y las asigna a los
servicios y la infraestructura, ya sea en el entorno local o en la nube. El rol requiere un conocimiento
profundo de la tecnología asociada con cada operación empresarial.
Propietario de ingeniería: Implementa los servicios asociados al funcionamiento del negocio. Estas
personas pueden participar en el diseño y la implementación de posibles soluciones para resolver los
problemas de requisitos no funcionales detectados por el equipo de revisión.
Propietario del ser vicio: Se encarga del funcionamiento de las aplicaciones y los servicios de la
empresa. Estos individuos recopilan datos de registro y uso de estas aplicaciones y servicios. Estos datos
se usan para identificar problemas y para comprobar las correcciones una vez que se han implementado.
Reuniones de revisión
Es recomendable que el equipo de revisión se reúna periódicamente. Por ejemplo, puede reunirse todos los
meses e informar del estado y las métricas al equipo de dirección trimestralmente.
Adapte los detalles del proceso y las reuniones a sus necesidades específicas. Como punto de partida, se
recomiendan las siguientes tareas:
1. El propietario y el defensor del negocio enumeran y determinan los requisitos no funcionales de cada
operación empresarial, con la aportación de los propietarios de la ingeniería y los servicios. En el caso de
las operaciones empresariales que se han identificado previamente, revise y compruebe la prioridad. Con
las operaciones de negocio nuevas, asigne una prioridad de la lista existente.
2. Los propietarios de la ingeniería y los servicios asignan el estado actual de las operaciones empresariales
a los servicios en la nube y locales correspondientes. La asignación es una lista de los componentes de
cada servicio en forma de árbol de dependencias. Los propietarios del servicio e ingeniería determinan
las rutas de acceso críticas a través del árbol.
3. Los propietarios de ingeniería y del servicio revisan el estado actual del registro y la supervisión
operativos de los servicios enumerados en el paso anterior. Para identificar los componentes del servicio
que contribuyen al incumplimiento de los requisitos no funcionales, son esenciales procedimientos de
registro y supervisión de gran solidez. Si no se disponen de suficientes procedimientos de registro y
supervisión, el equipo debe crear e implementar un plan para llevarlos a cabo.
4. El equipo crea métricas del cuadro de mandos para las nuevas operaciones empresariales. El cuadro de
mandos consta de la lista de componentes que forman cada uno de los servicios identificados en el paso
2. Está en línea con los requisitos no funcionales e incluye una medida del grado en que cada
componente cumple los requisitos.
5. Para los componentes constituyentes que no cumplen los requisitos no funcionales, el equipo diseña una
solución general y asigna un propietario de ingeniería. En este momento, el propietario y el defensor del
negocio establecen un presupuesto para el trabajo de corrección, en función de los ingresos previstos de
la operación empresarial.
6. Por último, el equipo lleva a cabo una revisión del trabajo de corrección en curso. Cada una de las
métricas del cuadro de mandos de trabajo en curso se revisa comparándola con los criterios previstos. En
el caso de los componentes constituyentes que cumplen los criterios, el propietario de los servicios
presenta los datos de registro y supervisión para confirmar que se cumplen los criterios. En cuanto a los
componentes constituyentes que no cumplen los criterios de las métricas, cada propietario de ingeniería
explica los problemas que impiden que se alcancen las métricas y presenta nuevas formas posibles de
corregir el problema.
Recursos recomendados
Marco de buena arquitectura de Microsoft Azure: Obtenga información sobre los principios guía para
mejorar la calidad de una carga de trabajo. Dicho marco consta de cinco pilares de excelencia de la
arquitectura:
Optimización de costos
Eficiencia del rendimiento
Confiabilidad
Seguridad
Diez principios de diseño para las aplicaciones de Azure. Siga estos principios de diseño para que la
aplicación sea más escalable, resistente y administrable.
Diseño de aplicaciones resistentes de Azure. Cree y mantenga sistemas confiables mediante un enfoque
estructurado durante la vigencia de una aplicación, desde el diseño y la puesta en marcha hasta la
implementación y operaciones.
Patrones de diseño en la nube. Use modelos de diseño para crear aplicaciones basadas en los fundamentes
de la excelencia de la arquitectura.
Azure Advisor. Azure Advisor ofrece recomendaciones personalizadas basadas en el uso y la configuración
para ayudar a optimizar los recursos, a fin de obtener alta disponibilidad, seguridad, rendimiento y
rentabilidad.
Administración de TI y operaciones en la nube
Cuando una empresa pasa a un modelo basado en la nube, la importancia de una administración y operaciones
adecuadas no se puede sobrestimar. Lamentablemente, hay pocas organizaciones que estén preparadas para el
cambio en la administración de TI que se necesita para crear correctamente un modelo operativo en el que la
nube sea prioritaria. En esta sección de Cloud Adoption Framework se describen el modelo operativo, los
procesos y las herramientas que han demostrado un funcionamiento satisfactorio en la nube. Cada una de estas
áreas representa un cambio pequeño, pero fundamental, en la forma en que la empresa debe ver la
administración y las operaciones de TI al empezar a adoptar la nube.
Breve historia sobre el equipo de administración de TI

Antes de la nube, la administración de TI evolucionó a partir de una simple función de adquisición. La
adquisición de equipos técnicos para apoyar los procesos empresariales requería conocimientos técnicos y una
gran experiencia con un grupo específico de proveedores de equipos. El equipo de administración de TI
consolidó la selección, adquisición y configuración de los recursos de TI. Por lo general, los recursos adquiridos,
entre los que se incluían el almacenamiento, la capacidad de procesamiento, las redes y otros recursos similares
necesarios para impulsar la función empresarial deseada. Como principales expertos en cuestiones relacionadas
con los equipos informáticos, también era tarea de TI el funcionamiento de estos para garantizar el máximo
rendimiento y el mínimo de interrupciones en los procesos empresariales.
Cuando la empresa crea nuevas soluciones tecnológicas, tiene una necesidad clara que puede justificar los
importantes gastos asociados con la adquisición de recursos, o incluso la creación de centros de datos
completos. Cuando crea soluciones, la empresa ve los costos de adquisición como una inversión de futuro.
Después de que se satisface la necesidad empresarial, la percepción de esos mismos costos cambia. Los costos
asociados a las soluciones existentes se ven como operaciones que se han creado por necesidades del pasado.
Esa percepción es el motivo por el que muchas empresas perciben el departamento de TI como un centro de
costo. También es el motivo por el que muchas organizaciones de TI realizan regularmente ejercicios de control
de costos o reducciones de personal de TI.
Administración de la nube
El modelo operativo histórico de TI ha sido suficiente durante más de 20 años. Sin embargo, ese modelo ahora
está anticuado y no es tan atractivo como las alternativas en las que la nube tiene prioridad. Cuando los equipos
de administración de TI pasan a la nube, tienen una oportunidad de replantear este modelo y generar un mayor
valor para la empresa. En esta serie de artículos se describe un modelo moderno de administración de TI.
Pasos siguientes
Para comprender mejor el nuevo modelo de administración de la nube, empiece por Descripción de la
alineación empresarial.
Descripción de la alineación empresarial
Crear la alineación empresarial en la administración
en la nube
En entornos locales, TI administra los activos de TI (aplicaciones, máquinas virtuales, hosts de máquina virtual,
discos, servidores, dispositivos y orígenes de datos) para admitir operaciones de carga de trabajo. En términos
de TI, una carga de trabajo es una colección de activos de TI que admiten una operación empresarial específica.
Para ayudar a respaldar las operaciones empresariales, la administración de TI ofrece procesos diseñados para
minimizar las interrupciones de esos recursos. Cuando una organización pasa a la nube, la administración y las
operaciones cambian un poco, lo que crea una oportunidad para desarrollar una mejor alineación empresarial.
Jerga empresarial
El primer paso para crear la alineación empresarial es garantizar la alineación de los términos. La administración
de TI, como la mayoría de las profesiones de ingeniería, ha acumulado una colección de jerga o de términos
muy técnicos. Estos términos pueden generar confusión en las partes interesadas del negocio y dificultar la
asignación de servicios de administración al valor empresarial.
Afortunadamente, el proceso para desarrollar una estrategia de adopción de la nube y un plan de adopción de
la nube crean una oportunidad ideal para la reasignación de estos términos. El proceso también crea
oportunidades para replantear los compromisos para la administración operativa, en colaboración con la
empresa. En la siguiente serie de artículos se describe este nuevo enfoque en tres términos específicos que
pueden ayudar a mejorar las conversaciones entre las partes interesadas del negocio:
Impor tancia crítica : asignación de cargas de trabajo a procesos empresariales. Clasificación del grado de
importancia para enfocar las inversiones.
Impacto : comprensión del impacto de las posibles interrupciones para ayudar a evaluar la rentabilidad de la
inversión para la administración en la nube.
Compromiso : desarrollo de verdaderas asociaciones, mediante la creación y la documentación de contratos
con la empresa.
NOTE
Subyacentes a estos términos hay términos de TI clásicos como SLA, RTO y RPO. Para más información sobre la
asignación de términos empresariales y de TI específicos, consulte Compromiso empresarial en la administración de la
nube.
Libro de administración de operaciones

Para ayudar a tomar decisiones derivadas de esta conversación sobre la alineación de los términos, existe un
libro de administración de operaciones en el sitio de GitHub. Este libro no supone un contrato de nivel de
servicio ni cálculos de costos. Solo sirve de ayuda para capturar estas medidas y prever los esfuerzos para evitar
el retorno de pérdidas.
Como alternativa, estas mismas cargas de trabajo y recursos asociados podrían etiquetarse directamente en
Azure, si las soluciones ya están implementadas en la nube.
Pasos siguientes
Comience a crear la alineación empresarial definiendo el grado de importancia de la carga de trabajo.
Definir el grado de importancia de la carga de trabajo
Importancia crítica para la empresa en la
administración de la nube
En cada empresa, existe un pequeño número de cargas de trabajo que son demasiado importantes como para
que produzcan errores. Estas cargas de trabajo se consideran críticas. Cuando esas cargas de trabajo
experimentan interrupciones o una degradación del rendimiento, el impacto negativo en los ingresos y la
rentabilidad se puede notar en toda la empresa.
En el otro extremo del espectro, pueden pasar meses sin que se utilicen algunas cargas de trabajo. En este caso,
tampoco se quiere que experimenten un bajo rendimiento o interrupciones, aunque el efecto será aislado y
limitado.
Comprender la importancia crítica de cada carga de trabajo de la cartera de TI es el primer paso para establecer
compromisos mutuos con la administración de la nube. El diagrama siguiente ilustra una alineación común
entre la escala de importancia crítica que se debe seguir y los compromisos estándar realizados por la empresa.
Escala de importancia crítica

El primer paso en cualquier trabajo de alineación de la importancia crítica para la empresa es crear una escala.
En la tabla siguiente se presenta una escala de ejemplo que se usará como referencia, o plantilla, para crear su
propia escala.
GRA DO DE IM P O RTA N C IA VISIÓ N EM P RESA RIA L
Críticas Afecta a la misión de la empresa y puede afectar

notablemente a los balances corporativos de pérdidas y
ganancias.
Crítico para la unidad Afecta a la misión de una unidad de negocio específica y a

sus balances de pérdidas y ganancias.
Alto Aunque puede que no entorpezca la misión, afecta a los

procesos de importancia alta. En el caso de las
interrupciones, las pérdidas mensurables se pueden
cuantificar.
GRA DO DE IM P O RTA N C IA VISIÓ N EM P RESA RIA L
Media Es problema que se produzca un impacto en los procesos.

Las pérdidas son bajas o imperceptibles, pero pueden
producirse daños en la marca o pérdidas en la etapa inicial
de la producción.
Bajo El impacto en los procesos empresariales es imperceptible.

No es probable que se produzcan daños en la marca ni
pérdidas en la etapa inicial de producción. Lo más probable
es que se produzca un impacto localizado en un solo equipo.
No compatible Ningún propietario, equipo o proceso de negocio asociado a

esta carga de trabajo puede justificar una inversión en la
administración continua de la carga de trabajo.
Es habitual que las empresas incluyan clasificaciones adicionales de importancia crítica específicas de su sector,
segmento vertical o proceso empresarial determinado. Entre los ejemplos de clasificaciones adicionales se
incluyen:
Crítica para el cumplimiento: en sectores muy regulados, algunas cargas de trabajo pueden ser críticas
como parte de las labores de cumplimiento de la normativa.
Crítica para la seguridad: es posible que algunas cargas de trabajo no sean críticas, pero las
interrupciones podrían provocar la pérdida de datos o el acceso no deseado a información protegida.
Crítica para la protección: cuando la vida o la seguridad física de empleados y clientes están en juego
durante una interrupción, puede ser aconsejable clasificar las cargas de trabajo como críticas para la
seguridad.
Valor de la importancia crítica precisa

Más adelante en el proceso de adopción de la nube, el equipo de administración de la nube usará esta
clasificación para determinar la cantidad de trabajo necesaria para cumplir los niveles de importancia crítica
alineados. En entornos locales, la administración de operaciones se suele procurar de forma central y se trata
como una carga empresarial necesaria, con poco o ningún costo operativo adicional. Como todos los servicios
en la nube, la administración de operaciones se adquiere por recurso según los costos operativos mensuales.
Dado que hay un costo claro y directo para la administración de operaciones en la nube, es importante alinear
correctamente los costos y las escalas de importancia crítica deseadas.
Selección de una importancia crítica predeterminada

La revisión inicial de cada carga de trabajo de la cartera puede llevar mucho tiempo. Para tener la seguridad de
que este trabajo no bloquea la estrategia en la nube más amplia, se recomienda que los equipos lleguen a un
acuerdo sobre la importancia crítica predeterminada que se aplicará a todas las cargas de trabajo.
En función de la tabla de escala de importancia crítica anterior, se recomienda adoptar el nivel de importancia
crítica medio como valor predeterminado. De esta forma, el equipo de estrategia en la nube podrá identificar
rápidamente las cargas de trabajo que requieren un nivel más alto de importancia crítica.
Uso de la plantilla
Los siguientes pasos se aplican si usa el libro de administración de operaciones para planear la administración
de la nube.
1. Registre la escala de criticidad en la hoja de cálculo Scale .
2. Actualice cada carga de trabajo en la hoja de cálculo Example o en la hoja de cálculo Clean Template para
reflejar la criticidad predeterminada en la columna Criticality .
3. La empresa debe introducir los valores correctos para reflejar cualquier desviación de la importancia crítica
predeterminada.
Pasos siguientes
Cuando el equipo haya definido la importancia crítica para la empresa, puede calcular y registrar el impacto
empresarial.
Cálculo y registro del efecto para la empresa
Efecto empresarial en la administración de la nube
Presuponga lo mejor y prepárese para lo peor. En la administración de TI es seguro presuponer que las cargas
de trabajo necesarias para admitir las operaciones empresariales estarán disponibles y se realizarán según el
acuerdo en cuanto a las restricciones, en función de la importancia seleccionada. Sin embargo, para administrar
las inversiones de forma inteligente, es importante comprender el impacto en la empresa cuando se produce
una interrupción o una degradación del rendimiento. Esta importancia se ilustra en el siguiente gráfico, que
asigna posibles interrupciones empresariales de cargas de trabajo específicas al impacto empresarial de las
interrupciones en una escala de valor relativa.
Para crear una base justa de comparación para el impacto sobre varias cargas de trabajo en una cartera, se
sugiere una métrica de tiempo/valor. La métrica de tiempo/valor captura el impacto negativo de una
interrupción en la carga de trabajo. Por lo general, este efecto se registra como una pérdida directa de ingresos
o ingresos operativos durante un período de interrupción típico. Más concretamente, calcula la pérdida de
ingresos por unidad de tiempo. La métrica más común de tiempo/valor es el impacto por hora, que mide las
pérdidas de ingresos operativos por hora de interrupción.
Se pueden utilizar varios enfoques para calcular el impacto. Puede aplicar cualquiera de las opciones de las
secciones siguientes para lograr resultados similares. Es importante usar el mismo enfoque para cada carga de
trabajo al calcular las pérdidas protegidas en una cartera.
Comienzo con estimaciones

Los modelos operativos actuales pueden dificultar la determinación precisa del impacto. Afortunadamente,
pocos sistemas necesitan gran precisión en el cálculo de las pérdidas. En el paso de clasificación de la
importancia anterior, se sugirió que todas las cargas de trabajo se comenzaran por un valor predeterminado de
importancia media. Por lo general, las cargas de trabajo de importancia media reciben un nivel estándar de
soporte de administración con un impacto relativamente reducido sobre los costos operativos. Solo cuando una
carga de trabajo requiere recursos adicionales de administración operativa, puede requerir un impacto
financiero preciso.
En todas las cargas de trabajo estandarizadas, el impacto empresarial sirve como variable de priorización a la
hora de recuperar sistemas durante una interrupción. Aparte esas situaciones limitadas, el impacto empresarial
supone poco o ningún cambio en la experiencia de administración de las operaciones.
Cálculo del tiempo

En función de la naturaleza de la carga de trabajo, las pérdidas se pueden calcular de forma diferente. En el caso
de los sistemas transaccionales de alto ritmo, como una plataforma comercial en tiempo real, las pérdidas por
milisegundo pueden ser significativas. Es posible que los sistemas que se usan con menos frecuencia, como los
de nóminas, no se utilicen a todas horas. Es importante saber si la frecuencia de uso es alta o baja para
normalizar la variable temporal al calcular el impacto financiero.
Cálculo del impacto total

Cuando se quieren considerar inversiones de administración adicionales, es más importante que el impacto
empresarial sea más preciso. Los tres enfoques siguientes para calcular las pérdidas están ordenados del más al
menos preciso:
Pérdidas ajustadas : si la empresa ha experimentado un suceso con pérdidas importantes en el pasado,
como un huracán u otro desastre natural, un ajuste de las notificaciones puede haber calculado las
pérdidas reales durante la interrupción. Estos cálculos se basan en los estándares del sector de los
seguros para el cálculo de pérdidas y la administración de riesgos. El uso de pérdidas ajustadas como
total de pérdidas en un período de tiempo específico puede generar proyecciones muy precisas.
Historial de pérdidas : si su entorno local ha sufrido interrupciones en el pasado por inestabilidad de la
infraestructura, puede ser un poco más difícil calcular las pérdidas. Sin embargo, puede seguir aplicando
las fórmulas de ajuste que se usan internamente. Para calcular el historial de pérdidas, compare las
diferencias en las ventas, los ingresos brutos y los costos operativos en tres intervalos de tiempo: antes,
durante y después de la interrupción. Al examinar estas diferencias se pueden identificar las pérdidas
exactas cuando no hay otros datos disponibles.
Cálculo de pérdidas totales: si no hay historial de datos disponible, puede derivar un valor de pérdida
comparativo. En este modelo se determina el promedio de ingresos brutos por hora de la unidad de
negocio. Cuando proyecta inversiones en prevención de pérdidas, no es justo suponer que una
interrupción completa del sistema equivale a una pérdida del 100 % de los ingresos. Sin embargo, puede
usar esta suposición como base para comparar el impacto de las pérdidas y priorizar las inversiones.
Antes de realizar determinadas suposiciones sobre posibles pérdidas asociadas a interrupciones de la carga de
trabajo, se recomienda trabajar con el departamento financiero para determinar el mejor enfoque para realizar
estos cálculos.
Cálculo del impacto de la carga de trabajo

Al calcular las pérdidas mediante la aplicación de datos históricos, puede tener información suficiente para
determinar con claridad la contribución de cada carga de trabajo a esas pérdidas. En la realización de esta
evaluación es donde las asociaciones dentro la empresa son absolutamente fundamentales. Una vez calculado el
impacto total, este debe atribuirse en cada una de las cargas de trabajo. Esa distribución del efecto debe
provenir de las partes interesadas de la empresa, que deben estar de acuerdo en el efecto relativo y acumulativo
de cada carga de trabajo. Con ese objetivo, el equipo debe solicitar comentarios de los ejecutivos de la empresa
para validar la alineación. Estos comentarios suelen ser sentimiento y experiencia en el tema a partes iguales. Es
importante que este ejercicio represente la lógica y las creencias de las partes interesadas de la empresa,
quienes deben tener algo que decir sobre la asignación del presupuesto.
Uso de la plantilla
Si utiliza el libro de administración de las operaciones para planear la administración de la nube, considere la
posibilidad de realizar los pasos siguientes:
Cada empresa debe actualizar cada carga de trabajo en la hoja de cálculo Example o en la hoja de cálculo
Clean Template , junto con el objeto Time/Value Impact de cada carga de trabajo. De forma predeterminada,
el objeto Time/Value Impact representa las pérdidas proyectadas por hora asociadas con una interrupción en
la carga de trabajo.
Pasos siguientes
Una vez que la empresa haya definido el impacto, puede alinear los compromisos.
Alineación de los compromisos de administración con la empresa
Compromiso empresarial en la administración de la
nube
La definición de un compromiso empresarial es un ejercicio de equilibrar prioridades. El objetivo es alinear el

nivel adecuado de administración operativa con un costo operativo aceptable. La búsqueda de ese equilibrio
requiere algunos puntos de datos y cálculos, que se describen en este artículo.
Los compromisos de estabilidad empresarial, a través de la resistencia técnica u otros efectos del Acuerdo de
Nivel de Servicio (SLA), son una decisión de justificación empresarial. Para la mayoría de las cargas de trabajo
de un entorno, es suficiente un nivel de base de referencia de administración de la nube. Para otros, un aumento
de los costos de 2x a 4x se justifica fácilmente por el posible efecto de las interrupciones en el negocio.
Los artículos anteriores de esta serie pueden ayudarle a comprender la clasificación y el impacto de las
interrupciones en varias cargas de trabajo. Este artículo le ayuda a calcular los resultados. Como se muestra en
la imagen anterior, cada nivel de administración de la nube tiene puntos de inflexión en los que los costos
pueden aumentar más rápido que la resistencia. Esos puntos de inflexión requerirán decisiones y compromisos
empresariales detallados.
Determinación de un compromiso adecuado con el negocio

Para cada carga de trabajo de la cartera, el equipo de operaciones en la nube y el equipo de estrategia en la
nube deben alinearse en el nivel de administración que proporciona directamente el equipo de operaciones en
la nube.
A medida que establece un compromiso con el negocio, existen algunos aspectos clave que se deben alinear:
Requisitos previos de las operaciones de TI
Responsabilidad de administración
Inquilino en la nube
Factores de costo indirecto
ROI con prevención de pérdidas
Validación del nivel de administración
Para ayudar en el proceso de toma de decisiones, en el resto de este artículo se describe con mayor detalle cada
uno de estos aspectos.
Requisitos previos de las operaciones de TI

En la Guía de administración de Azure se describen las herramientas de administración disponibles en Azure.
Antes de llegar a un compromiso con la empresa, el departamento de TI debe determinar una línea de base de
administración estándar que se aplique a todas las cargas de trabajo administradas. Después, debe calcular los
costos de administración estándares para cada una de las cargas de trabajo administradas en la cartera de TI en
función de la cantidad de núcleos de CPU, del espacio en disco y de otras variables relacionadas con los
recursos. También estimará un Acuerdo de Nivel de Servicio compuesto para cada carga de trabajo en función
de la arquitectura.
TIP
Los equipos de operaciones de TI a menudo usan un tiempo de actividad mínimo predeterminado del 99,9 % para el
Acuerdo de Nivel de Servicio compuesto inicial. También pueden optar por normalizar los costos de administración en
función de la carga de trabajo media, especialmente en el caso de las soluciones con requisitos mínimos de registro y
almacenamiento. Calcular el promedio de los costos de algunas cargas de trabajo de importancia intermedia puede ser un
buen punto de partida para las conversaciones iniciales.
TIP
Si usa el libro de administración de operaciones para planear la administración de la nube, los campos de administración
de las operaciones deben actualizarse para reflejar estos requisitos previos. Estos campos incluyen el nivel de compromiso,
el Acuerdo de Nivel de Servicio compuesto y el costo mensual. El costo mensual debe representar el costo mensual
agregado de las herramientas de administración de las operaciones.
La base de referencia de administración de las operaciones sirve como punto de partida que validar en las
siguientes secciones.
Responsabilidad de administración
En un entorno local tradicional, los costos de administración del entorno se suelen presuponer como costos
ocultos de las operaciones de TI. En la nube, la administración es una decisión intencionada con impacto
presupuestario directo. Los costos de cada función de administración se pueden atribuir más directamente a
cada carga de trabajo implementada en la nube. Este enfoque permite mayor control, pero exige a los equipos
de operaciones en la nube y los equipos de estrategia en la nube que celebren primero en un acuerdo sobre las
responsabilidades.
Las organizaciones también pueden optar por externalizar algunas de sus funciones de administración actuales
a algún proveedor de servicios. Estos proveedores de servicios pueden usar Azure Lighthouse para ofrecer a las
organizaciones un control más preciso al conceder acceso a los recursos, además de mayor visibilidad en las
acciones que realizan.
Responsabilidad delegada : dado que no es necesario centralizar y adoptar una sobrecarga de
administración operativa, se están pensando nuevos enfoques para las operaciones de TI de muchas
organizaciones. Un enfoque típico es la responsabilidad delegada. En un modelo de excelencia en la nube,
las operaciones y la automatización de la plataforma proporcionan herramientas de administración de
servicios de autoservicio que pueden usar los equipos de operaciones empresariales,
independientemente de los equipos de operaciones de TI centralizadas. Este enfoque proporciona a las
partes interesadas de la empresa un control total sobre los presupuestos relacionados con la
administración. También permite al centro de excelencia de la nube (CCoE) asegurarse de que un mínimo
de barreras se ha implementado correctamente. En este modelo, el equipo de TI actúa como agente y
guía que ayuda a la empresa a tomar decisiones sensatas. Las operaciones empresariales supervisan las
operaciones cotidianas de las cargas de trabajo dependientes.
Responsabilidad centralizada : los requisitos de cumplimiento, la complejidad técnica y algunos
modelos de servicios compartidos pueden requerir un modelo de equipo de TI central. En este modelo, el
equipo de TI sigue ejerciendo las responsabilidades de administración de las operaciones. El diseño del
entorno, los controles de administración y las herramientas de gobernanza se pueden administrar y
controlar de forma centralizada, lo que restringe el rol de las partes interesadas de la empresa al realizar
compromisos de administración. Sin embargo, la visibilidad del costo y la arquitectura de los enfoques en
la nube facilitan mucho a los equipos de TI centralizados la comunicación de los costos y el nivel de
administración de cada carga de trabajo.
Modelo mixto: la clasificación es la esencia de un modelo mixto de responsabilidades de
administración. Las empresas que se encuentran en medio de una transformación de sus instalaciones
locales a la nube pueden necesitar un modelo operativo local primero durante un tiempo. Las empresas
con requisitos estrictos de cumplimiento o que dependen de contratos a largo plazo con proveedores
externos de TI pueden necesitar un modelo operativo centralizado.
Independientemente de sus restricciones, las empresas actuales deben innovar. En los escenarios de
rápida innovación, en medio de un modelo de responsabilidad centralizada en un equipo de TI central, un
enfoque de modelo mixto puede proporcionar equilibrio. En este enfoque, un equipo de TI central
proporciona un modelo operativo centralizado para todas las cargas de trabajo críticas o que contienen
información confidencial. Al mismo tiempo, el resto de clasificaciones de las cargas de trabajo se pueden
colocar en un entorno de nube diseñado para responsabilidades delegadas. El enfoque de
responsabilidad centralizada actúa como modelo operativo general. La empresa tiene flexibilidad para
adoptar un modelo operativo especializado, en función del nivel de soporte y confidencialidad necesario.
El primer paso es el compromiso con un enfoque de responsabilidad, que a continuación dé forma a los
siguientes compromisos.
¿Qué organización será responsable de la administración de las operaciones diarias de esta carga
de trabajo?
Inquilino en la nube
Para la mayoría de las empresas, la administración es más fácil cuando todos los recursos residen en un único
inquilino. Sin embargo, algunas organizaciones pueden tener que mantener varios inquilinos. Para saber por
qué una empresa puede requerir un entorno multiinquilino de Azure, consulte Centralización de operaciones de
administración con Azure Lighthouse.
¿Residirá esta carga de trabajo en un único inquilino de Azure junto con todas las demás?
Factores de costo indirecto

En la siguiente sección se describe un enfoque comparativo del rendimiento en relación con los niveles de los
procesos y las herramientas de administración. Al final de esta sección, cada carga de trabajo analizada mide los
costos de administración en relación con el impacto previsto de las interrupciones de la empresa. Este enfoque
proporciona una forma relativamente sencilla de comprender si se justifica una inversión en enfoques de
administración más completos.
Antes de calcular los números, es importante examinar los factores de costo indirecto. Los factores de costo
indirecto producen un rendimiento difícil de medir mediante ahorro en los costos fijos, que sería visible en un
balance de pérdidas y ganancias. Los factores de costo indirecto son importantes, ya que pueden indicar una
necesidad de invertir en más administración que la que sería prudente desde el punto de vista fiscal.
Estos son algunos ejemplos de factores de costo indirecto:
Uso diario de una carga de trabajo por parte del Consejo o el consejero delegado.
Uso de la carga de trabajo por parte del x % de clientes como máximo, que provoca un mayor impacto en los
ingresos en otro lugar.
Efecto sobre la satisfacción de los empleados.
El siguiente punto de datos necesario para realizar un compromiso es una lista de los factores de costo
indirecto. No es necesario documentar estos factores en esta fase, pero las partes interesadas de la empresa
deben ser conscientes de la importancia de estos factores y su exclusión de los siguientes cálculos.
Cálculo de la ROI con la prevención de pérdidas

Al calcular el rendimiento relativo en los costos de administración de las operaciones, el equipo de TI
responsable de las operaciones en la nube debe cumplir los requisitos previos anteriores y presuponer un nivel
mínimo de administración para todas las cargas de trabajo.
El siguiente compromiso que debe realizarse es una aceptación por parte de la empresa de los costos asociados
con la oferta administrada según la base de referencia.
¿Acuerda la empresa inver tir en la ofer ta de base de referencia para cumplir los estándares
mínimos de las operaciones en la nube?
Si la empresa no está de acuerdo con ese nivel de administración, debe idearse una solución que le permita
continuar sin que ello afecte de forma significativa a las operaciones en la nube de otras cargas de trabajo.
Si la empresa desea un nivel de administración superior al estándar, el resto de esta sección le ayudará a validar
esa inversión y el rendimiento asociado (en forma de prevención de pérdidas).
Mayores niveles de administración: principios de diseño y catálogo de servicios
En el caso de las soluciones administradas, se pueden aplicar varios principios de diseño y soluciones de
plantilla además de la base de referencia de administración. Todos los principios de diseño para la confiabilidad
y la resistencia suman costos operativos a la carga de trabajo. Para que el equipo de TI y la empresa acuerden
estos compromisos adicionales, es importante comprender las posibles pérdidas que se pueden evitar con esa
mayor inversión.
Los cálculos siguientes le guiarán por las fórmulas para comprender mejor las diferencias entre las pérdidas y el
aumento de las inversiones en administración. Para obtener instrucciones sobre cómo calcular el costo de la
mayor administración, consulte los artículos sobre la automatización de la carga de trabajo y la automatización
de la plataforma.
TIP
Si usa el libro de administración de operaciones para planear la administración de la nube, actualice los campos de
administración de operaciones para que reflejen cada conversación. Estos campos incluyen el nivel de compromiso, el
Acuerdo de Nivel de Servicio compuesto y el costo mensual. El costo mensual debe representar el costo mensual de las
herramientas de administración de las operaciones agregadas. Una vez actualizados, esos campos actualizarán las
fórmulas del ROI y los campos siguientes.
Estimación de las interrupciones (horas al año )

El Acuerdo de Nivel de Servicio compuesto se basa en la implementación de cada recurso en la carga de trabajo.
Ese campo controla la interrupción estimada ( Est.Outage en el libro). Para calcular la interrupción estimada en
horas al año sin usar el libro, aplique la siguiente fórmula:
Interrupción estimada = (1 - porcentaje del Acuerdo de Nivel de Servicio compuesto) x número de horas de
un año
En el libro se usa el valor predeterminado de 8760 horas al año.
Efecto estándar de las pérdidas
El efecto estándar de las pérdidas ( Standard Impact en el libro) pronostica el efecto financiero de las
interrupciones, suponiendo que la predicción interrupción estimada resulte precisa. Para calcular esta previsión
sin usar el libro, aplique la siguiente fórmula:
Efecto estándar = interrupción estimada a tres novenos del tiempo de actividad x tiempo/valor del efecto
Esto sirve como base de referencia del costo si las partes interesadas de la empresa optan por invertir en más
administración.
Efecto del Acuerdo de Nivel de Servicio compuesto
El efecto del Acuerdo de Nivel de Servicio compuesto ( Commitment level impact en el libro) proporciona el
efecto fiscal actualizado en función de los cambios en el Acuerdo de Nivel de Servicio sobre el tiempo de
actividad. Este cálculo le permite comparar el efecto financiero previsto de ambas opciones. Para calcular este
efecto previsto sin la hoja de cálculo, aplique la siguiente fórmula:
Efecto del Acuerdo de Nivel de Servicio compuesto = interrupción estimada x tiempo/valor del efecto
El valor representa las posibles pérdidas que se deben evitar con el cambio en el nivel de compromiso y el
nuevo Acuerdo de Nivel de Servicio compuesto.
Base de comparación
La base de comparación evalúa el efecto estándar y el efecto del Acuerdo de Nivel de Servicio compuesto para
determinar cuál es el más adecuado en la columna de rendimiento.
Rendimiento con la prevención de pérdidas
Si el costo de administrar una carga de trabajo supera las pérdidas potenciales, la inversión propuesta en la
administración de la nube podría no ser adecuada. Para comparar el rendimiento con la prevención de pérdidas,
consulte la columna denominada *Annual ROI**** (ROI anual). Para calcular esta columna por su cuenta, use
esta fórmula:
Rendimiento con la prevención de pérdidas = (base de comparación - [costo mensual × 12] / [costo
mensual × 12])
A menos que haya otros factores de costo indirecto que considerar, esta comparación puede sugerir
rápidamente si debe haber una mayor inversión en las operaciones en la nube, la resistencia, la confiabilidad u
otras áreas.
Validación del compromiso

Ya en este punto del proceso se han realizado compromisos: responsabilidad centralizada o delegada, inquilino
de Azure y nivel de compromiso. Es necesario validar y documentar cada compromiso para garantizar la
alineación del equipo de operaciones en la nube, del equipo de estrategia en la nube y de las partes interesadas
de la empresa respecto a este compromiso con el fin de administrar la carga de trabajo.
Pasos siguientes
Una vez realizados los compromisos, los equipos de operaciones responsables pueden comenzar a configurar la
carga de trabajo en cuestión. Para empezar, evalúe varios enfoques para el inventario y la visibilidad.
Opciones de inventario y visibilidad
Nivelación de la administración entre las materias
de administración de la nube
Las claves de una administración adecuada en cualquier entorno son la coherencia y los procesos repetibles.
Hay infinitas opciones para las tareas que se pueden hacer en Azure. Del mismo modo, hay innumerables
estrategias de administración de la nube. Para proporcionar coherencia y repetibilidad, es importante restringir
esas opciones a un conjunto coherente de herramientas y procesos de administración que se ofrecerán para las
cargas de trabajo hospedadas en la nube.
Niveles de administración sugeridos

Dado que las cargas de trabajo de la cartera de TI varían, no es probable que un solo nivel de administración sea
suficiente para todas ellas. Para ayudar a admitir diversas cargas de trabajo y distintos compromisos
empresariales, se recomienda que los equipos de operaciones de la nube y de la plataforma establezcan algunos
niveles de administración de operaciones.
Como punto de partida, considere la posibilidad de establecer los niveles de administración que se muestran en
el diagrama anterior y que se sugieren en la lista siguiente:
Base de referencia de administración: una base de referencia de administración de la nube (o base de
referencia de administración) es el conjunto definido de herramientas, procesos y precios coherentes que
sirven de base para toda la administración de la nube en Azure. Para establecer una base de referencia de
administración de la nube y determinar las herramientas que se incluirán en la oferta de base de referencia
para su empresa, revise la lista de la sección "Materias de administración de la nube".
Base de referencia mejorada: puede que algunas cargas de trabajo requieran mejoras de la base de
referencia que no son necesariamente específicas de una sola plataforma o carga de trabajo. Aunque estas
mejoras no son rentables para todas las cargas de trabajo, debe haber procesos, herramientas y soluciones
comunes para cualquier carga de trabajo que pueda justificar los costos de permitir administración adicional.
Especialización de la plataforma: en cualquier entorno proporcionado, distintas cargas de trabajo utilizan
algunas plataformas comunes. Estos elementos comunes de la arquitectura general no cambian cuando las
empresas adoptan la nube. La especialización de la plataforma es un nivel elevado de administración que
aplica los datos y la experiencia en materia de arquitectura para proporcionar un mayor nivel de
administración operativa. Algunos ejemplos de especialización de la plataforma incluirían funciones de
administración específicas de SQL Server, contenedores, Active Directory u otros servicios que se pueden
administrar mejor mediante procesos, herramientas y arquitecturas coherentes y repetibles.
Especialización de la carga de trabajo: en el caso de las cargas de trabajo realmente críticas, los costos
de profundizar aún más en la administración de esa carga de trabajo pueden estar justificados. La
especialización de la carga de trabajo aplica la telemetría de las cargas de trabajo para determinar estrategias
más avanzadas para la administración diaria. Esos mismos datos a menudo identifican mejoras en la
automatización, la implementación y el diseño que llevarán a una mayor estabilidad, confiabilidad y
resistencia más allá de lo que es posible con la administración operativa por sí sola.
No admitidas: igual de importante es comunicar los procesos de administración comunes que no se
facilitarán mediante materias de administración de la nube en las cargas de trabajo clasificadas como no
admitidas o no críticas.
Las organizaciones también pueden optar por subcontratar las funciones relacionadas con uno o varios de estos
niveles de administración a un proveedor de servicios. Estos proveedores de servicios pueden usar Azure
Lighthouse para proporcionar una mayor precisión y transparencia.
En el resto de artículos de esta serie se describen los procesos que se encuentran normalmente en cada una de
estas materias. Al mismo tiempo, la guía de administración de Azure muestra las herramientas que puede
admitir cada uno de estos procesos. Si necesita ayuda para crear la base de referencia de administración,
comience con la guía de administración de Azure. Una vez establecida la base de referencia, esta serie de
artículos y los procedimientos recomendados que los acompañan pueden ayudarle a ampliarla para definir
otros niveles de asistencia de la administración.
Materias de administración de la nube

Cada nivel de administración sugerido puede invocar una variedad de disciplinas de administración de la nube.
Sin embargo, la asignación está diseñada para que sea más fácil encontrar las herramientas y los procesos
sugeridos que se deben ofrecer en el nivel adecuado de administración de la nube.
En la mayoría de los casos, el nivel de base de referencia de administración descrito anteriormente se compone
de procesos y herramientas de las siguientes materias. En cada caso, se resaltan algunos procesos y
herramientas para demostrar las funciones de base de referencia mejoradas.
Inventario y visibilidad: la base de referencia de administración debe incluir como mínimo un medio para
realizar el inventario de los recursos y crear visibilidad sobre el estado de ejecución de cada uno.
Cumplimiento operativo: la administración normal de la configuración, el tamaño, el costo y el
rendimiento de los recursos es vital para mantener las expectativas de rendimiento y una línea de base de
administración.
Protección y recuperación: minimizar las interrupciones operativas y agilizar la recuperación puede
ayudar a evitar pérdidas de rendimiento e impactos en los ingresos. La detección y la recuperación son
aspectos esenciales de esta materia en cualquier línea de base de administración.
El nivel de especialización de la plataforma de la administración se extrae de los procesos y las herramientas que
se alinean con las materias de operaciones de la plataforma. Del mismo modo, el nivel de especialización de la
carga de trabajo de la administración se extrae de los procesos y las herramientas que se alinean con las
materias de operaciones de la carga de trabajo.
Pasos siguientes
El siguiente paso en la definición de cada nivel de administración de la nube es entender el inventario y la
visibilidad.
Opciones de inventario y visibilidad
Inventario y visibilidad de la administración en la
nube
La administración operativa depende claramente de los datos. Una administración coherente requiere conocer
lo que se administra (inventario) y de cómo cambian los recursos y las cargas de trabajo administradas con el
tiempo (visibilidad). La información clara y la visibilidad del inventario permiten al equipo administrar el
entorno de forma eficaz. El resto de actividades y procesos de administración operativa se basan en estas dos
áreas.
Algunas frases clásicas sobre la importancia de las medidas establecen la línea de este artículo:
Administrar lo que importa.
Solo se puede administrar lo que se puede medir.
Si no se puede medir, es posible que no sea importante.
La materia de inventario y visibilidad se basa en estas frases atemporales. Para poder establecer de manera
eficaz los procesos de administración operativa, es importante recopilar datos y crear el nivel adecuado de
visibilidad para los equipos correctos.
Desafíos comunes de los clientes

Si los procesos de inventario y visibilidad no se aplican de forma coherente, los equipos de administración
operativa pueden sufrir un mayor volumen de interrupciones del negocio, tiempos de recuperación más
prolongados y mayor esfuerzo necesario para solucionar y evaluar los problemas. Cuando los cambios afectan
negativamente a aplicaciones de mayor prioridad y a un gran número de recursos, cada una de estas métricas
crece aún más rápido.
Estos desafíos derivan de un pequeño número de preguntas que solo se pueden responder mediante datos y
telemetría coherentes:
¿En qué medida se desvía el rendimiento actual de los datos de telemetría de rendimiento operativos
estándar?
¿Qué recursos están causando las interrupciones del negocio en el nivel de carga de trabajo?
¿Qué recursos deben corregirse para volver al rendimiento aceptable de este proceso de negocio o carga de
trabajo?
¿Cuándo se inició la desviación? ¿Cuál fue el desencadenador?
¿Qué cambios se han realizado en los recursos subyacentes? ¿Quién los ha realizado?
¿Los cambios son intencionados? ¿Malintencionados?
¿Cómo afectaron los cambios a los datos de telemetría del rendimiento?
Es difícil, si no imposible, responder a estas preguntas sin un origen enriquecido y centralizado de registros y
datos de telemetría. Para habilitar la administración en la nube y garantizar la configuración coherente que se
requiere para centralizar los datos, el servicio de base de referencia debe empezar por definir los procesos. Los
procesos deben capturar cómo una configuración aplica la recopilación de datos para poder contar con los
componentes de inventario y visibilidad en la sección siguiente.
Componentes de inventario y visibilidad

La creación de visibilidad en cualquier plataforma de nube requiere algunos componentes clave:
Responsabilidad y visibilidad
Inventario
Registro central
seguimiento de cambios
Telemetría de rendimiento
Responsabilidad y visibilidad
A la hora de establecer compromisos para cada carga de trabajo, la responsabilidad de la administración es un
factor clave. La responsabilidad delegada crea una necesidad de visibilidad delegada. El primer paso hacia el
inventario y la visibilidad es asegurarse de que las partes interesadas tengan acceso a los datos correctos. Antes
de implementar las herramientas en la nube nativas para la visibilidad, asegúrese de que cada herramienta de
supervisión se ha configurado con el acceso y el ámbito adecuados para cada equipo de operaciones.
Inventario
Si nadie sabe que existe un recurso, es difícil administrarlo. Para poder administrar un recurso o una carga de
trabajo, deben inventariarse y clasificarse. El primer paso técnico hacia la estabilidad de las operaciones es
validar y clasificar el inventario.
Registro central
Tener un registro central es fundamental para dar a los equipos de administración de operaciones la visibilidad
que necesitan diariamente. Todos los recursos implementados en la nube deben guardar los registros en una
ubicación central. En Azure, la ubicación central es Log Analytics. La centralización de los registros permite crear
informes sobre la administración de cambios, el estado de mantenimiento del servicio, la configuración y
muchos otros aspectos de las operaciones de TI.
Realizar un uso coherente del registro central es el primer paso para establecer operaciones repetibles. La
aplicación se puede realizar mediante directivas corporativas. Sin embargo, cuando sea posible, la aplicación se
debe automatizar para garantizar la coherencia.
seguimiento de cambios
Los cambios son una constante en los entornos tecnológicos. Conocer y comprender los cambios en las
distintas cargas de trabajo es esencial para contar con operaciones confiables. Cualquier solución de
administración en la nube debe incluir un medio para comprender el cuándo, cómo y por qué de un cambio
técnico. Sin esos datos, las labores de corrección resultan mucho más difíciles.
Telemetría de rendimiento
Los compromisos empresariales con respecto a la administración en la nube se controlan mediante datos. Para
mantener los compromisos correctamente, el equipo de operaciones en la nube debe comprender primero los
datos de telemetría en cuanto a estabilidad, rendimiento y operaciones de la carga de trabajo, así como los
recursos que respaldan la carga de trabajo.
Las operaciones y el mantenimiento continuos de la red, servidores DNS, sistemas operativos y otros aspectos
fundamentales del entorno son puntos de datos críticos que afectan al estado general de cualquier carga de
trabajo.
Procesos
Quizás más importante que las características de la plataforma de administración en la nube son los procesos
de administración en la nube, que se encargarán de los compromisos de operaciones con la empresa. Cualquier
metodología de administración en la nube debe incluir, como mínimo, los siguientes procesos:
Super visión reactiva: cuando las desviaciones afectan negativamente a las operaciones empresariales,
¿quién aborda esas desviaciones? ¿Qué acciones llevan a cabo para corregir las desviaciones?
Super visión proactiva: cuando se detectan desviaciones pero las operaciones empresariales no se ven
afectadas, ¿cómo se abordan esas desviaciones y quién lo hace?
Informes de compromiso: ¿cómo se comunica el cumplimiento del compromiso de la empresa a las
partes interesadas del negocio?
Revisiones presupuestarias: ¿Cuál es el proceso de revisión de dichos compromisos con relación a los
costos presupuestados? ¿Cuál es el proceso de ajuste de la solución implementada o de los compromisos
para crear la alineación?
Rutas de escalación: ¿Qué rutas de escalación hay disponibles cuando alguno de los procesos anteriores
no satisface las necesidades del negocio?
Hay varios procesos más relacionados con el inventario y la visibilidad. La lista anterior está diseñada para
generar ideas en el equipo de operaciones. Responder a estas preguntas ayudará a desarrollar algunos de los
procesos necesarios y, probablemente, a desencadenar nuevas preguntas más profundas.
Responsabilidades
Cuando desarrolla procesos de supervisión de las operaciones, es igualmente importante determinar las
responsabilidades de soporte regular y de las operaciones diarias para cada proceso.
En una organización de TI centralizada, el departamento de TI proporciona la experiencia operativa. La empresa
tendría una naturaleza consultiva cuando se requiere una corrección para los problemas.
En la organización de un centro de excelencia en la nube, las operaciones empresariales proporcionarían la
experiencia y serían responsables de la administración de estos procesos. El departamento de TI se centraría en
la automatización y la prestación de soporte a los equipos, ya que operan en el entorno.
Sin embargo, estas son las responsabilidades comunes. A menudo, las organizaciones requieren una
combinación de responsabilidades para satisfacer los compromisos del negocio.
Actuación en el inventario y la visibilidad

Independientemente de la plataforma de nube, los cinco componentes de inventario y visibilidad se usan en la
mayoría de los procesos operativos. Todas las materias posteriores se basarán en los datos que se están
capturando. En los siguientes artículos de esta serie se describen las formas de actuar sobre esos datos y de
integrar otros orígenes de datos.
Compartir la visibilidad
Los datos sin acción no producen retornos. La administración en la nube puede expandirse más allá de los
procesos y las herramientas nativas de la nube. Para dar cabida a procesos más amplios, es posible que sea
necesario mejorar la base de referencia de administración en la nube para que incluya informes, integración de
la Administración de servicios de TI o centralización de los datos. Es posible que la administración en la nube
necesite incluir una o varias de las siguientes operaciones durante las distintas fases de madurez operativa.
Informe
Los procesos sin conexión y la comunicación de los compromisos a las partes interesadas del negocio suelen
requerir informes. Los informes periódicos o de autoservicio pueden ser un componente necesario de una base
de referencia de administración mejorada.
Integración de Administración de servicios de TI (ITSM )
La integración de ITSM suele ser el primer ejemplo de la actuación en el inventario y la visibilidad. Cuando
surgen desviaciones de los patrones de rendimiento esperados, la integración de ITSM usa las alertas de la
plataforma de nube para abrir incidencias en una herramienta de administración de servicios de TI
independiente con el fin de iniciar las actividades de corrección. Algunos modelos operativos pueden requerir la
integración de ITSM como un aspecto de la base de referencia de administración mejorada.
Hay varias razones por las que un negocio puede necesitar varios inquilinos dentro de un único proveedor de
nube. En estos escenarios, la centralización de los datos es un componente necesario de la base de referencia de
administración mejorada para proporcionar visibilidad en cada uno de esos inquilinos o entornos.
Pasos siguientes
El cumplimiento operativo se basa en las funcionalidades de inventario y en la aplicación de controles y
automatización de la administración. Consulte la correspondencia entre el cumplimiento operativo y sus
procesos.
Plan de cumplimiento operativo
Cumplimiento operativo en la administración de la
nube
El cumplimiento operativo se basa en la materia de inventario y visibilidad. Como primer paso accionable de la
administración de la nube, esta materia se centra en las revisiones habituales de los datos de telemetría y en los
trabajos de corrección (tanto proactivos como reactivos). Esta materia es la piedra angular para mantener el
equilibrio entre la seguridad, la gobernanza, el rendimiento y los costos.
Componentes del cumplimiento operativo

Mantener el cumplimiento de los compromisos operativos requiere análisis, automatización y corrección
humana. Para un cumplimiento operativo eficaz se requiere coherencia en algunos procesos críticos:
Coherencia del entorno
Coherencia en la configuración de los recursos
Coherencia de actualización
Automatización de las correcciones
El paso más eficaz que puede dar un equipo de administración de la nube para el cumplimiento operativo es
establecer la coherencia en la organización de los recursos y el etiquetado. La coherencia de organización y
etiquetado de los recursos facilita las demás tareas operativas. Para instrucciones más detalladas sobre la
coherencia de los recursos, consulte la metodología de gobernanza. En concreto, revise los artículos sobre la
base de gobernanza inicial para aprender cómo empezar a desarrollar la coherencia de los recursos.
Coherencia del entorno
Establecer entornos coherentes, o zonas de aterrizaje, son el siguiente paso más importante hacia el
cumplimiento operativo. Con zonas de aterrizaje coherentes y que se aplican mediante herramientas
automatizadas, el diagnóstico y la resolución de problemas operativos son considerablemente menos
complejos. Para instrucciones más detalladas sobre la coherencia del entorno, consulte la fase de preparación
durante el ciclo de vida de la adopción de la nube. En esta fase, los ejercicios ayudan a crear un proceso repetible
para definir y madurar un enfoque coherente basado primero en código para el desarrollo de entornos basados
en la nube.
Coherencia en la configuración de los recursos
Dado que se basa en los enfoques de gobernanza y preparación, la administración de la nube debe incluir
procesos para la supervisión y la evaluación continuas del cumplimiento de los requisitos de coherencia de los
recursos. A medida que las cargas de trabajo cambian o se adoptan nuevas versiones, es fundamental que los
procesos de administración de la nube evalúen los cambios de configuración, que no se regulan fácilmente a
través de la automatización.
Cuando se detectan irregularidades, algunas se solucionan por coherencia en las actualizaciones y otras se
pueden corregir automáticamente.
Coherencia de actualización
La estabilidad del enfoque puede dar lugar a operaciones más estables. Sin embargo, se necesitan algunos
cambios en los procesos de administración de la nube. En concreto, es esencial realizar cambios en el
rendimiento y revisiones habituales para reducir las interrupciones y controlar los costos.
Una de las muchas ventajas de una metodología de administración de la nube madura es centrarse en la
estabilización y el control de los cambios necesarios.
Cualquier base de referencia de administración de la nube debe incluir un medio para programar, controlar y,
posiblemente, automatizar las actualizaciones necesarias. Estas actualizaciones deben incluir como mínimo
revisiones, pero también pueden incluir rendimiento, ajuste de tamaño y otros aspectos de la actualización de
los recursos.
Automatización de las correcciones
Como base de referencia mejorada para la administración de la nube, algunas cargas de trabajo pueden
beneficiarse de la corrección automatizada. Cuando una carga de trabajo con frecuencia detecta problemas que
no se pueden resolver mediante cambios de código o de arquitectura, la automatización de la corrección puede
ayudar a reducir la carga de la administración de la nube para aumentar la satisfacción del usuario.
Muchos dirían que cualquier problema lo suficientemente común para automatizarse, debería solucionarse
mediante la resolución de la deuda técnica. Cuando sea prudente una resolución a largo plazo, esta debe ser la
opción predeterminada. Sin embargo, algunos escenarios empresariales dificultan la justificación de grandes
inversiones en la resolución de la deuda técnica. Cuando no se puede justificar esta resolución, pero la
corrección es una carga común y costosa, la corrección automatizada es la siguiente mejor solución.
Pasos siguientes
Protección y recuperación, esas son las siguientes áreas que se deben considerarse en una base de referencia
para la administración de la nube.
Protección y recuperación en la administración de la
nube
Después de cumplir los requisitos de inventario y visibilidad y de cumplimiento operativo, los equipos de
administración de la nube se pueden anticipar y prepararse para una posible interrupción de la carga de trabajo.
Cuando planean la administración de la nube, los equipos deben plantearse la posibilidad de que se produzca
un error.
No hay ninguna solución técnica que pueda ofrecer constantemente un Acuerdo de Nivel de Servicio de tiempo
de actividad del 100 %. Aquellas soluciones con las arquitecturas más redundantes afirman que pueden ofrecer
un tiempo de actividad de "seis nueves", es decir, del 99,9999 %. Pero incluso estas soluciones dejan de
funcionar durante 31,6 segundos como mínimo cada año. Además, es raro que una solución justifique la gran
inversión operativa constante que se necesita para alcanzar un tiempo de actividad de "seis nueves".
La preparación ante las interrupciones permite que el equipo detecte errores antes y se recupere más
rápidamente. El enfoque de esta materia se centra en los pasos siguientes que hay que tomar inmediatamente
después de un error del sistema. ¿Cómo se protegen las cargas de trabajo para que se puedan recuperar
rápidamente cuando se produce una interrupción?
Traslado de las conversaciones sobre protección y recuperación

Las cargas de trabajo que impulsan las operaciones empresariales constan de aplicaciones, datos, máquinas
virtuales (VM) y otros recursos. Cada uno de esos recursos puede requerir un enfoque diferente para la
protección y la recuperación. Un aspecto importante de esta materia consiste en establecer un compromiso
coherente dentro de la base de referencia de administración, que puede proporcionar un punto de partida
durante las conversaciones empresariales.
Como mínimo, cada recurso que respalda una carga de trabajo determinada debe disponer de un enfoque de
base de referencia con un compromiso claro relativo a la velocidad de recuperación (objetivos de tiempo de
recuperación o RTO) y al riesgo de pérdida de datos (objetivos de punto de recuperación o RPO).
Objetivos de tiempo de recuperación (RTO )
Cuando se produce un desastre, el objetivo de tiempo de recuperación es la cantidad de tiempo que debe tardar
cualquier sistema en recuperar su estado previo al desastre. Para cada carga de trabajo, esto incluye el tiempo
requerido para restaurar la funcionalidad mínima necesaria de las máquinas virtuales y las aplicaciones.
También incluye el tiempo necesario para restaurar los datos que requieren las aplicaciones.
En términos empresariales, el RTO representa la cantidad de tiempo que un proceso de negocio estará fuera de
servicio. En el caso de cargas de trabajo críticas, esta variable debe ser relativamente baja para permitir que los
procesos se reanuden rápidamente. Para aquellas cargas de trabajo de prioridad baja, es posible que un nivel
estándar de RTO no afecte notablemente al rendimiento de la empresa.
La base de referencia de administración debe establecer un objetivo de tiempo de recuperación estándar para
las cargas de trabajo no críticas. Posteriormente, la empresa puede usar esa línea de base como una manera de
justificar inversiones adicionales en los tiempos de recuperación.
Objetivos de punto de recuperación (RPO )
En la mayoría de los sistemas de administración de la nube, los datos se capturan y almacenan periódicamente
mediante algún tipo de protección de datos. La última vez que se capturaron los datos se conoce como punto de
recuperación. Cuando se produce un error en un sistema, solo se puede restaurar al punto de recuperación más
reciente.
Si un sistema tiene un objetivo de punto de recuperación que se mide en horas o días, un error del sistema daría
lugar a la pérdida de datos durante esas horas o días que transcurren entre el último punto de recuperación y la
interrupción. En teoría, un RPO de 1 día dará lugar a la pérdida de todas las transacciones del día en que se
produjo el error.
En el caso de sistemas críticos, un RPO medido en minutos o segundos puede ser más adecuado para evitar una
pérdida de ingresos. Sin embargo, un RPO más corto suele provocar un aumento de los costos generales de
administración.
Una base de referencia de administración debe concentrarse en hallar el RPO más largo aceptable para
minimizar los costos. El equipo de administración de la nube puede aumentar el RPO de plataformas o cargas
de trabajo concretas, lo que justificaría una mayor inversión.
Protección y recuperación de cargas de trabajo

La mayoría de las cargas de trabajo de un entorno de TI respaldan un proceso empresarial o técnico concreto.
Los sistemas que no tienen un impacto sistémico en las operaciones empresariales a menudo no justifican el
aumento de las inversiones que se necesita para una recuperación rápida o la reducción al mínimo de la pérdida
de datos. El establecimiento de una base de referencia permite a las empresas comprender claramente qué nivel
de respaldo a la recuperación se puede ofrecer a cambio de un precio concreto y asumible. Ello ayuda a las
partes interesadas de la empresa a evaluar el valor de una mayor inversión en los procesos de recuperación.
Para la mayoría de los equipos de administración de la nube, una base de referencia mejorada con
compromisos específicos de RPO/RTO para varios recursos, genera el escenario más favorable para establecer
compromisos empresariales mutuos. En las secciones siguientes se describen algunas líneas de base mejoradas
comunes que permiten a la empresa agregar fácilmente funcionalidades de protección y recuperación mediante
un proceso repetible.
Protección y recuperación de datos
Los datos son posiblemente el recurso más valioso en la economía digital. La capacidad para proteger y
recuperar datos de forma más eficaz es la línea de base mejorada más común. En el caso de los datos que
forman parte de una carga de trabajo de producción, la pérdida de datos se puede equiparar directamente a una
pérdida de ingresos o de rentabilidad. Por lo general, se recomienda que los equipos de administración de la
nube ofrezcan un nivel de base de referencia de administración mejorada que admita las plataformas de datos
comunes.
Antes de que los equipos de administración de la nube implementen operaciones de plataforma, es habitual que
respalden las operaciones mejoradas de una plataforma de datos como servicio (PaaS). Por ejemplo, es fácil que
un equipo de administración de la nube aplique una mayor frecuencia de copias de seguridad o de replicación
en varias regiones para las soluciones de Azure SQL Database o Azure Cosmos DB. Esto permite que el equipo
de desarrollo pueda mejorar fácilmente el RPO mediante la modernización de sus plataformas de datos.
Para obtener más información acerca de este proceso de reflexión, consulte la materia sobre operaciones de
plataforma.
Protección y recuperación de máquinas virtuales
La mayoría de las cargas de trabajo tienen alguna dependencia de las máquinas virtuales, que hospedan
diversos aspectos de la solución. Para que la carga de trabajo apoye un proceso empresarial después de un
error del sistema, es necesario recuperar rápidamente algunas máquinas virtuales.
Cada minuto de tiempo de inactividad de esas máquinas virtuales puede provocar una pérdida de ingresos o
una menor rentabilidad. Cuando el tiempo de inactividad de la VM tiene un impacto directo en el rendimiento
fiscal de la empresa, el RTO pasa a ser algo muy importante. Las máquinas virtuales se pueden recuperar más
rápidamente mediante la replicación en un sitio secundario y la recuperación automatizada, un modelo que se
conoce como modelo de recuperación activa-semiactiva. En un estado ideal de recuperación, las máquinas
virtuales se pueden replicar en un sitio secundario totalmente funcional. Este enfoque más caro se conoce como
modelo de recuperación activa-activa o de alta disponibilidad.
Cada uno de los modelos anteriores reduce el RTO, lo que da lugar a una restauración más rápida de las
funcionalidades del proceso de negocio. Sin embargo, cada modelo también supone un aumento considerable
de los costos de administración de la nube.
Tenga en cuenta que, además de la replicación para la alta disponibilidad, la copia de seguridad debe estar
habilitada para escenarios como la eliminación accidental, los daños en los datos y los ataques de ransomware.
Para más información sobre este proceso de reflexión, consulte la materia sobre operaciones de carga de
trabajo.
Pasos siguientes
Una vez satisfecho este componente de la línea de base de administración, el equipo puede prepararse para
evitar interrupciones en sus operaciones de la plataforma y operaciones con cargas de trabajo.
Operaciones de la plataforma Operaciones con cargas de trabajo
Operaciones de plataforma en administración de la
nube
Una base de referencia de administración de la nube que abarca inventario y visibilidad, cumplimiento operativo
y protección y recuperación puede proporcionar un nivel suficiente de administración de la nube para la
mayoría de las cargas de trabajo de la cartera de TI. Sin embargo, esa base de referencia rara vez es suficiente
para la cartera completa. Este artículo se basa en el siguiente paso más común de la administración de la nube,
las operaciones de cartera.
Un estudio rápido de los recursos de la cartera de TI resalta los patrones que se admiten en las cargas de
trabajo. Dentro de esas cargas de trabajo, habrá plataformas comunes. En función de las decisiones técnicas
anteriores de la empresa, esas plataformas pueden variar considerablemente.
En algunas organizaciones habrá una gran dependencia de SQL Server, Oracle u otras plataformas de datos de
código abierto. En otras organizaciones, los puntos en común se pueden originar en las plataformas host de las
máquinas virtuales (VM) o los contenedores. Otras pueden tener una dependencia común de aplicaciones o
sistemas de planeamiento de recursos empresariales (ERP), como SAP u Oracle.
La comprensión de estos puntos en común permite al equipo de administración de la nube especializarse en
niveles superiores de soporte para esas plataformas prioritarias.
Establecimiento de un catálogo de servicios

El objetivo de las operaciones de plataforma es crear soluciones confiables y repetibles que el equipo de
adopción de la nube pueda utilizar para ofrecer una plataforma que proporcione un mayor nivel de
compromiso empresarial. Ese compromiso puede reducir la probabilidad o la frecuencia del tiempo de
inactividad, lo cual mejoraría la confiabilidad. Si se produjera un error del sistema, el compromiso también
podría ayudar a reducir la pérdida de datos o el tiempo de recuperación. Este compromiso suele incluir las
operaciones centralizadas en curso para que se admita la plataforma.
A medida que el equipo de administración de la nube va estableciendo mayores grados de administración
operativa y especialización relacionada con plataformas específicas, esas plataformas se van agregando a un
catálogo de servicios creciente. El catálogo de servicios proporciona una implementación de autoservicio de las
plataformas en una configuración específica, que se adhiere a las operaciones de plataforma en curso. Durante
la conversación de alineación empresarial, los equipos de administración de la nube y de estrategia en la nube
pueden proponer soluciones de catálogo de servicios como una forma de mejorar los compromisos de
confiabilidad, tiempo de actividad y recuperación de la empresa en un proceso controlado y repetible.
Como referencia, algunas organizaciones se refieren a una primera fase del catálogo de servicios como lista
aprobada. La principal diferencia es que un catálogo de servicios incluye compromisos operativos continuos del
centro de excelencia en la nube (CCoE). Una lista aprobada es similar, ya que proporciona una lista aprobada
previamente de soluciones que un equipo puede usar en la nube. Sin embargo, normalmente no existe ninguna
ventaja operativa asociada a las aplicaciones en una lista aprobada.
Al igual que el debate entre el equipo de TI centralizada y el centro de excelencia de la nube (CCoE), la diferencia
es una de las prioridades. Un catálogo de servicios es una buena opción que proporciona contenciones
operativas, de gobernanza y de seguridad que aceleran la innovación. Una lista aprobada dificulta la innovación
hasta que la solución traspasa las puertas de las operaciones, el cumplimiento y la seguridad. Ambas soluciones
son viables, pero requieren que la empresa tome decisiones de priorización ingeniosas para invertir más en
innovación o en cumplimiento.
Creación del catálogo de servicios
La administración de la nube rara vez se realiza correctamente si se entrega un catálogo de servicios en un silo.
El correcto desarrollo del catálogo requiere una asociación entre el equipo de TI central o el de CCoE. Este
enfoque tiende a ser más satisfactorio cuando una organización de TI alcanza un nivel de madurez de CCoE,
pero podría implementarse antes.
Al crear el catálogo de servicios dentro de un modelo de CCoE, el equipo de plataforma en la nube crea la
plataforma de estado deseada. Los equipos de gobernanza y de seguridad en la nube validan la gobernanza y el
cumplimiento en la implementación. El equipo de administración de la nube establece las operaciones en curso
para esa plataforma. Asimismo, el equipo de automatización en la nube empaqueta la plataforma para una
implementación escalable y repetible.
Después de empaquetar la plataforma, el equipo de administración de la nube puede agregarla al catálogo de
servicios creciente. A partir de ahí, el equipo de adopción de la nube puede usar ese paquete u otros del
catálogo durante la implementación. Cuando la solución pasa a producción, la empresa obtiene las ventajas
adicionales de la administración operativa mejorada y una posible reducción de las interrupciones
empresariales.
NOTE
La creación de un catálogo de servicios requiere una gran cantidad de esfuerzo y tiempo de varios equipos. El uso del
catálogo de servicios o la lista aprobada como mecanismo de canalización ralentiza la innovación. Cuando la innovación es
una prioridad, los catálogos de servicios deben desarrollarse en paralelo a otras labores de adopción.
Definición de operaciones de plataforma propias

Aunque las herramientas y los procesos de administración pueden ayudar a mejorar las operaciones de la
plataforma, a menudo no es suficiente para lograr los estados deseados de estabilidad y confiabilidad. Las
verdaderas operaciones de la plataforma requieren una atención especial en los fundamentos de excelencia de
la arquitectura. Cuando una plataforma justifica una inversión mayor en las operaciones, tenga en cuenta los
cinco fundamentos siguientes para que la plataforma pase a ser parte de cualquier catálogo de servicios:
producción.
El Marco de buena arquitectura de Microsoft Azure proporciona una estrategia para evaluar cargas de trabajo
específicas para el cumplimiento de estos fundamentos con el fin de mejorar las operaciones generales. Estos
fundamentos se pueden aplicar tanto a las operaciones de la plataforma como a las de la carga de trabajo.
Introducción a las plataformas específicas

Las plataformas que se tratan en las secciones siguientes son comunes para los clientes típicos de Azure.
Además, pueden justificar fácilmente una inversión en operaciones de la plataforma. Los equipos de
administración de la nube tienden a comenzar por estas al elaborar los requisitos de las operaciones de la
plataforma o el catálogo de servicios completo.
Operaciones de datos de PaaS
Los datos suelen ser los primeros en considerarse para justificar las inversiones en operaciones de plataforma.
Cuando se hospedan datos en un entorno de plataforma como servicio (PaaS), las partes interesadas de la
empresa tienden a solicitar un objetivo de punto de recuperación (RPO) reducido para minimizar la pérdida de
datos. En función de la naturaleza de la aplicación, también pueden solicitar una reducción del objetivo de
tiempo de recuperación (RTO). En cualquier caso, la arquitectura que admite soluciones de datos basadas en
PaaS puede fácilmente dar cabida a un mayor nivel de soporte de administración.
En la mayoría de los escenarios, el costo de mejorar los compromisos de administración se justifica fácilmente,
incluso para las aplicaciones que no son críticas. Esta mejora de las operaciones de la plataforma es tan común
que muchos equipos de administración de la nube la ven más como una base de referencia mejorada que como
una verdadera mejora de las operaciones de la plataforma.
Operaciones con datos de IaaS
Cuando los datos se hospedan en una solución de infraestructura como servicio (IaaS) tradicional, el esfuerzo
para mejorar el RTO y el RPO puede ser mucho mayor. Sin embargo, el deseo de las partes interesadas de la
empresa por lograr mejores compromisos de administración apenas se ve afectado por la decisión de elegir
PaaS o IaaS. Si acaso, la comprensión de las diferencias fundamentales en la arquitectura puede instar a la
empresa a solicitar soluciones de PaaS o compromisos que coincidan con el contenido disponible en las
soluciones de PaaS. La modernización de cualquier plataforma de datos de IaaS se debe considerar como primer
paso a las operaciones de plataforma.
Cuando la modernización no es una opción, los equipos de administración de la nube suelen priorizar las
plataformas de datos basadas en IaaS como primer servicio necesario en el catálogo. Proporcionar a la empresa
una opción entre servidores de datos independientes y soluciones de datos agrupadas de alta disponibilidad
facilita en gran medida la conversación sobre el compromiso de la empresa. Una descripción básica de las
mejoras operativas y el aumento de los costos ayudará a la empresa a tomar la mejor decisión respecto a los
procesos empresariales y las cargas de trabajo de soporte.
Otras operaciones de plataforma comunes
Además de las plataformas de datos, los hosts de máquina virtual suelen ser una plataforma común para las
mejoras en las operaciones. Normalmente, los equipos de administración de la nube y la plataforma en la nube
invierten en mejoras en los hosts o las soluciones de contenedor de VMware. Dichas inversiones pueden
mejorar la estabilidad y la confiabilidad de los hosts, que admiten las VM, que a su vez impulsan las cargas de
trabajo. Las operaciones adecuadas en un host o contenedor pueden mejorar el RPO o el RTO de varias cargas
de trabajo. Este enfoque crea mejores compromisos empresariales, al tiempo que distribuye la inversión. Los
compromisos mejorados y los costos reducidos se combinan para facilitar enormemente la justificación de las
mejoras en las operaciones de la plataforma y de administración de la nube.
Pasos siguientes
En paralelo con las mejoras en las operaciones de plataforma, los equipos de administración de la nube también
se centran en mejorar las operaciones de carga de trabajo para las cargas de trabajo de producción del 20 % o
menos.
Mejora de las operaciones de carga de trabajo
Operaciones de la carga de trabajo en la
administración de la nube
Algunas cargas de trabajo son críticas para el éxito de la empresa. En el caso de esas cargas de trabajo, una base
de referencia de administración no es suficiente para satisfacer los compromisos empresariales necesarios para
la administración de la nube. Puede que incluso las operaciones de la plataforma no sean suficientes para
satisfacer los compromisos empresariales. Este subconjunto de cargas de trabajo de gran importancia requiere
un enfoque especializado respecto de la forma en que funciona la carga de trabajo y cómo se respalda.
A cambio, la inversión en operaciones de la carga de trabajo puede conducir a mejoras en el rendimiento, un
menor riesgo de interrupción del negocio y una recuperación más rápida cuando se producen errores del
sistema. En este artículo se describe un enfoque para la inversión en las operaciones continuadas de estas
cargas de trabajo de alta prioridad con el fin de favorecer mejores compromisos de negocio.
Cuándo invertir en operaciones de la carga de trabajo

El principio de Pareto (conocido también como la regla 80/20) afirma que el 80 % de los efectos proviene del
20 % de las causas. Cuando se permite que las carteras de TI crezcan de manera orgánica con el tiempo, esta
regla se suele ilustrar en una revisión de la cartera de TI. En función del efecto que requiera la inversión, la causa
puede variar, pero el principio general siempre se cumple:
el 80 % de los errores del sistema suele ser el resultado del 20 % de los errores comunes.
el 80 % del valor empresarial suele proceder del 20 % de las cargas de trabajo de una cartera.
el 80 % del trabajo de migración a la nube proviene del 20 % de las cargas de trabajo que se mueven.
el 80 % del trabajo de administración de la nube dará soporte al 20 % de los incidentes de servicio o
incidencias de problemas.
el 80 % del impacto en el negocio por una interrupción procederá del 20 % de los sistemas afectados por la
interrupción.
Las operaciones de carga de trabajo solo se deben aplicar cuando haya una buena comprensión de la estrategia
de adopción de la nube, los resultados empresariales y las métricas operativas. Se trata de un cambio de
paradigma desde la visión clásica de la TI. Tradicionalmente, los responsables de TI dan por hecho que todas las
cargas de trabajo han experimentado el mismo grado de asistencia y han requerido niveles de prioridad
similares.
Antes de invertir en operaciones profundas de la carga de trabajo, tanto los responsables de TI como la empresa
deben comprender las justificaciones empresariales y las expectativas del aumento de la inversión en la
administración de la nube.
Comenzar con los datos

Las operaciones de la carga de trabajo comienzan con una profunda comprensión del rendimiento de la carga
de trabajo y los requisitos de asistencia. Antes de invertir en operaciones de carga de trabajo, el equipo debe
contar con datos completos sobre las dependencias de la carga de trabajo, el rendimiento de las aplicaciones, el
diagnóstico de la base de datos, la telemetría de la máquina virtual y el historial de incidentes.
Estos datos son las simientes de los conocimientos que determinan las decisiones sobre las operaciones de la
carga de trabajo.
Observación continua
Los datos iniciales y la telemetría continua pueden ayudar a formular y probar teorías sobre el rendimiento de
una carga de trabajo. Sin embargo, las operaciones de carga de trabajo continuas proceden de una observación
sistemática y ampliada del rendimiento de la carga de trabajo, con un gran énfasis en el rendimiento de los
datos y las aplicaciones.
Probar la automatización
En el nivel de aplicación, el primer requisito de las operaciones de la carga de trabajo es una inversión en
pruebas en profundidad. En cualquier aplicación respaldada mediante operaciones de carga de trabajo, se debe
establecer y ejecutar con regularidad un plan de prueba para ofrecer pruebas funcionales y de escala entre las
aplicaciones.
La telemetría de prueba habitual puede proporcionar una validación inmediata de las diversas hipótesis sobre la
operación de carga de trabajo. Se pueden ejecutar y probar patrones operativos y arquitectónicos de mejora.
Las diferencias resultantes proporcionan un análisis de impacto claro para guiar las inversiones continuas.
Comprensión de las versiones
Comprender claramente los ciclos y las canalizaciones de versión es un elemento importante de las operaciones
de carga de trabajo.
Una comprensión de los ciclos puede servir de preparación para posibles interrupciones y permitir que el
equipo aborde de manera anticipada las versiones que pueden producir un efecto adverso en las operaciones.
Asimismo, permite que el equipo de administración de la nube colabore con los equipos de adopción para
mejorar continuamente la calidad del producto y solucionar errores que puedan afectar a la estabilidad.
Sobre todo, una comprensión de las canalizaciones de versión puede mejorar de manera considerable el
objetivo de punto de recuperación (RPO) de una carga de trabajo. En muchos escenarios, el camino más rápido
y preciso hacia la recuperación de una aplicación pasa por una canalización de versión. En el caso de las capas
de aplicación que solo cambian cuando se produce una nueva versión, puede ser aconsejable invertir más en la
optimización de la canalización que en la recuperación de la aplicación a partir de los procesos de copia de
seguridad tradicionales.
Aunque una canalización de implementación puede ser el camino más rápido hacia la recuperación, también
puede serlo hacia la corrección. Cuando una aplicación tiene una canalización de versión rápida, eficiente y
confiable, el equipo de administración de la nube dispone de una opción para automatizar la implementación en
un nuevo host como una forma de corrección automatizada.
Aunque puede haber otros muchos mecanismos más rápidos y eficaces de corrección y recuperación, cuando el
uso de una canalización existente puede satisfacer los compromisos empresariales y rentabilizar las inversiones
existentes en DevOps, la canalización existente puede ser una alternativa viable.
Comunicación clara de los cambios en la carga de trabajo
El cambio en cualquier carga de trabajo se encuentra entre los riesgos más importantes para las operaciones de
la carga de trabajo. Para comprender los cambios que incluye cada versión, el equipo de administración de la
nube debe estar estrechamente alineado con los equipos de adopción de la nube respecto a las cargas de
trabajo que pertenecen al nivel de operaciones de la carga de trabajo de la administración de la nube. Esta
inversión en conocimiento anticipado tendrá un impacto positivo directo sobre la estabilidad operativa.
Mejora de los resultados

Las inversiones en datos y comunicación de una carga de trabajo darán lugar a sugerencias de mejora para las
operaciones en curso en una de las tres áreas siguientes:
Resolución de deudas técnicas
Resolución de deudas técnicas
Los mejores planes de operaciones de carga de trabajo siguen necesitando correcciones. Dado que el equipo de
administración de la nube busca permanecer conectado para comprender las versiones y el trabajo de adopción,
igualmente debe compartir periódicamente los requisitos de corrección para garantizar que la deuda técnica y
los errores sean una prioridad continua para los equipos de desarrollo.
Al aplicar el principio de Pareto, podemos decir que el 80 % del impacto empresarial negativo probablemente
proviene del 20 % de los incidentes de servicio. Cuando esos incidentes no se pueden solucionar en los ciclos de
desarrollo normales, las inversiones en la automatización de las correcciones pueden reducir considerablemente
las interrupciones del negocio.
En los casos de resolución de deudas técnicas o automatización de correcciones, los defectos del sistema son la
causa común de la mayoría de las interrupciones del sistema. La adhesión a unos pocos principios de diseño
puede tener el impacto más grande en las operaciones generales de carga de trabajo:
Escalabilidad: La capacidad de un sistema para controlar el aumento de la carga.
Disponibilidad: proporción de tiempo que un sistema es funcional y está en funcionamiento.
Resistencia: La capacidad de un sistema de recuperarse de los errores y seguir funcionando.
Administración: Procesos de operaciones que mantienen un sistema ejecutándose en producción.
Seguridad: Protección de las aplicaciones y los datos frente a amenazas.
Para ayudar a mejorar las operaciones generales, el marco de buena arquitectura de Microsoft Azure
proporciona un enfoque para evaluar cargas de trabajo específicas para el cumplimiento de estos fundamentos.
Aplique los fundamentos a las operaciones de la plataforma y a las de la carga de trabajo.
Pasos siguientes
Con un conocimiento completo de la metodología de administración dentro de Cloud Adoption Framework,
ahora está preparado para implementar los principios de administración de la nube. Aprenda a hacer que esta
metodología sea útil en el entorno de operaciones.
Aplicación de esta metodología
Aplicación de principios de diseño y operaciones
avanzadas
Las tres primeras materias de administración de la nube describen una línea de base de administración. Como
mínimo, una línea de base de administración debe incluir un compromiso empresarial estándar para minimizar
las interrupciones del negocio y acelerar la recuperación si se interrumpe el servicio. La mayoría de las líneas de
base de administración incluyen una materia centrada en el mantenimiento del "inventario y visibilidad", el
"cumplimiento operativo" y la "protección y recuperación".
El propósito de una línea base de administración es crear una oferta coherente que proporcione un nivel
mínimo de compromiso empresarial para todas las cargas de trabajo que se admiten. Esta línea de base de
ofertas de administración repetibles comunes permite al equipo ofrecer un grado de administración operativa
altamente optimizado con una desviación mínima. Sin embargo, es posible que esa oferta estándar no ofrezca
un compromiso suficientemente completo para la empresa.
En el diagrama de la siguiente sección se muestran tres maneras de ampliar la línea de base de administración.
La línea de base de administración debe cumplir el compromiso mínimo requerido por el 80 % de las cargas de
trabajo de importancia crítica más baja de la cartera. La línea de base no se debe aplicar a las cargas de trabajo
críticas. Tampoco debería aplicarse a plataformas comunes que se comparten entre cargas de trabajo. Esas
cargas de trabajo requieren concentrarse en los principios de diseño y las operaciones avanzadas.
Opciones de las operaciones avanzadas

Se recomiendan tres formas de mejorar los compromisos empresariales más allá de la línea de base de
administración, como se indica en el siguiente diagrama:
Línea de base de administración mejorada
Como se describe en la guía de administración de Azure, una línea de base de administración mejorada usa
herramientas nativas en la nube para mejorar el tiempo de actividad y reducir los tiempos de recuperación. Las
mejoras son sustanciales, pero menos que con la especialización de la carga de trabajo o la plataforma. La
ventaja de una línea de base de administración mejorada es la reducción igualmente significativa en el costo y el
tiempo de implementación.
Especialización de la administración
Hay diversos aspectos de las operaciones de carga de trabajo y plataforma que pueden requerir cambios en los
principios de diseño y arquitectura. Estos cambios pueden tardar un tiempo y generar mayores gastos de
funcionamiento. Para reducir el número de cargas de trabajo que requieren tales inversiones, una línea de base
de administración mejorada podría proporcionar una mejora en el compromiso empresarial.
En el caso de las cargas de trabajo que justifican una mayor inversión para satisfacer un compromiso
empresarial, la especialización de las operaciones es clave.
Áreas de especialización de la administración

Hay dos áreas de especialización:
Especialización de la plataforma: Se invierte en las operaciones en curso de una plataforma compartida,
distribuyendo la inversión entre varias cargas de trabajo.
Especialización de la carga de trabajo: Se invierte en las operaciones en curso de una carga de trabajo
específica, normalmente reservada para cargas de trabajo críticas.
Equipo de TI centralizado o Centro de excelencia en la nube (CCoE)
Las decisiones entre la especialización de la plataforma y la especialización de la carga de trabajo se basan en el
nivel de importancia crítica y en el impacto de cada carga de trabajo. No obstante, esta decisión también es
indicativa de una decisión cultural de mayor envergadura entre los modelos organizativos de equipo de TI
central y CCoE.
La especialización de carga de trabajo suele desencadenar un cambio en la cultura. Ambos modelos, TI
tradicional y TI centralizado, crean procesos que pueden proporcionar soporte a escala. El soporte a escala es
más factible para los servicios repetibles que se encuentran en una línea de base de administración, una línea de
base mejorada o incluso en operaciones de plataforma. La especialización de la carga de trabajo no suele
escalarse. Esta falta de escalado dificulta que una organización de TI centralizado proporcione el soporte
necesario sin alcanzar los límites organizativos de escalado.
Como alternativa, el enfoque con un Centro de excelencia en la nube se escala mediante una delegación
intencionada de la responsabilidad y una centralización selectiva. La especialización de la carga de trabajo tiende
a alinearse mejor con el enfoque de responsabilidad delegada de un CCoE.
A continuación, se describe la alineación natural de los roles de un CCoE.
El equipo de plataforma de la nube ayuda a crear plataformas comunes que admiten varios equipos de
El equipo de automatización de la nube extiende esas plataformas a los recursos que se pueden implementar
en un catálogo de servicios.
La administración de la nube ofrece la base de referencia de administración de forma centralizada y ayuda a
admitir el uso del catálogo de servicios.
Sin embargo, la unidad de negocio (en forma de equipo de DevOps empresarial o equipo de adopción de la
nube) mantiene la responsabilidad de las operaciones cotidianas de carga de trabajo, canalización o
rendimiento.
Cuando se trata de coordinar las áreas de administración, los modelos del equipo de TI centralizado y de CCoE
generalmente pueden ofrecer una especialización de plataforma, con un cambio cultural mínimo. Proporcionar
una especialización de la carga de trabajo puede ser más complejo para los equipos de TI central.
Procesos de especialización de la administración

Dentro de cada especialización, el siguiente proceso de cuatro pasos se ofrece en un enfoque iterativo
disciplinado. Este enfoque requiere la asociación con expertos de adopción de la nube, plataforma en la nube,
automatización en la nube y administración de la nube para crear un bucle de comentarios práctico e
informado.
Mejora del diseño del sistema: se mejora el diseño de sistemas comunes (plataformas) o cargas de
trabajo específicas para minimizar las interrupciones de forma eficaz.
sentido automatizar la corrección y reducir el impacto de las interrupciones.
Escalado de la solución: a medida que se mejoran el diseño de sistemas y la corrección automatizada, los
cambios se pueden escalar en el entorno mediante el catálogo de servicios.
Mejora continua: se pueden usar varias herramientas de supervisión para detectar mejoras incrementales
que se pueden llevar a cabo en el siguiente paso del diseño, automatización y escalado del sistema.
La mejora del diseño del sistema es el enfoque más eficaz para mejorar las operaciones de cualquier plataforma
común. Gracias a las mejoras en el diseño del sistema, la estabilidad puede aumentar y las interrupciones del
negocio pueden disminuir. El diseño de sistemas individuales está fuera del ámbito de la perspectiva adoptada la
vista en toda la plataforma de adopción de la nube.
Como complemento de esta plataforma, el Marco de buena arquitectura de Microsoft Azure proporciona unos
principios rectores para mejorar la calidad de una plataforma o carga de trabajo específica. El marco se centra
en la mejora de los cinco pilares de la excelencia arquitectónica:
producción.
La mayoría de las interrupciones empresariales son resultado de alguna forma de deuda técnica o deficiencia en
la arquitectura. En el caso de las implementaciones existentes, las mejoras en el diseño de los sistemas pueden
verse como pagos de la deuda técnica existente. En el caso de las implementaciones nuevas, las mejoras en el
diseño de los sistemas pueden verse como evasión de la deuda técnica. La siguiente sección, "Corrección
automatizada", examina las formas de abordar la deuda técnica que no se puede o no se debe solucionar.
Obtenga más información acerca del Marco de buena arquitectura de Microsoft Azure para mejorar el diseño
del sistema. A medida que el diseño del sistema mejora, vuelva a consultar este artículo para encontrar nuevas
oportunidades de mejorar y escalar esas mejoras en todo el entorno.
Algunas deudas técnicas no se pueden (o no se deben) abordar, ya que la solución podría resultar demasiado
costosa para corregirla. Esta se podría planear, pero es posible que tuviera una duración de proyecto excesiva.
Podría deberse a que la interrupción del negocio no tiene un efecto importante en la empresa o a que la
prioridad empresarial es recuperarse rápidamente en lugar de invertir en resistencia.
Cuando la ruta deseada no es la resolución de la deuda técnica, la corrección automática suele ser el siguiente
paso deseado. El uso de Azure Automation y Azure Monitor para detectar tendencias y proporcionar una
corrección automatizada es el enfoque más común para la corrección automatizada.
Para obtener instrucciones sobre la corrección automatizada, consulte Azure Automation y alertas.
La piedra angular de las operaciones de plataforma y la especialización de plataforma es un catálogo de
servicios bien administrado. A través de él se escalan las mejoras en el diseño del sistema y las correcciones en
un entorno. El equipo de plataforma en la nube y el equipo de automatización en la nube se coordinan para
crear soluciones repetibles para las plataformas más comunes en cualquier entorno. Sin embargo, si esas
soluciones no se aplican de forma coherente, la administración en la nube puede proporcionar poco más que
una oferta de línea de base.
Para maximizar la adopción y minimizar la sobrecarga de mantenimiento de cualquier plataforma optimizada,
dicha plataforma se debe agregar a un catálogo de servicios. Todas las aplicaciones del catálogo se pueden
implementar para consumo interno a través del catálogo de servicios o como una oferta de Marketplace para
consumidores externos.
Para más información sobre cómo publicar en un catálogo de servicios, consulte la serie de artículos sobre
cómo publicar en un catálogo de servicios.
Mejora continua
La especialización de la plataforma y las operaciones de la misma dependen de ciclos de comentarios sólidos
entre los equipos de adopción, plataforma, automatización y administración. Si esos ciclos de comentarios están
basados en datos, cada equipo puede tomar decisiones acertadas. En el caso de las operaciones de plataforma
para lograr compromisos empresariales a largo plazo, es importante aprovechar la información específica de la
plataforma centralizada. Dado que los contenedores y SQL Server son las dos plataformas administradas
centralmente más habituales, los siguientes son algunos artículos que le ayudarán a empezar a usar la
recopilación de datos para mejora continua:
Rendimiento de contenedores
Rendimiento de bases de datos PaaS
Rendimiento de bases de datos IaaS
Antipatrones de operación y administración de la
nube
A menudo, los clientes experimentan antipatrones durante la fase de operación o administración de la adopción
de la nube. Al introducir cadenas de herramientas nuevas o modernizadas con precaución, a menudo se pueden
evitar estos antipatrones.
Antipatrón: centrarse en las herramientas, no en los resultados

empresariales
Las herramientas de TI modernizadas pueden mejorar los entornos de trabajo al liberar a los empleados de
tareas tediosas. Es importante medir las nuevas herramientas de TI para que pueda identificar si mejoran los
resultados empresariales. Una cadena de herramientas nueva o modernizada no proporciona automáticamente
una entrega más rápida ni un mejor resultado empresarial.
Ejemplo: introducción de una plataforma que no mejora el rendimiento
Una empresa introduce una nueva versión mejorada de su plataforma de integración continua y entrega
continua (CI/CD). La herramienta facilita la definición de las canalizaciones de entrega e implementación, lo que
le permite implementar características con mayor rapidez. El departamento de TI es partidario de la entrega de
una plataforma que acelere la configuración de la canalización. Una vez que una unidad de negocio utiliza la
herramienta, detecta que el tiempo de comercialización no es significativamente mejor comparado con la
plataforma anterior. El proceso final de aprobación y lanzamiento no cambia ni mejora.
Resultado preferido: medición del éxito con los resultados empresariales
Para mantener la alineación de la tecnología y los objetivos empresariales, los líderes de ambas áreas definen
conjuntamente los resultados deseados. Asegúrese de que estos resultados y objetivos sean específicos,
mensurables, factibles, razonables y de tiempo limitado (SMART). Asegúrese de que los resultados y los
objetivos tienen un impacto en la tecnología y la empresa. Microsoft Cloud Adoption Framework para Azure
puede ayudar a determinar un compromiso adecuado dentro de la empresa.
No use salidas de tecnología simples (como configuraciones de canalización y de implementación más rápidas)
para medir el éxito. En su lugar, use la tecnología y los resultados empresariales. Para obtener ayuda con esta
tarea, consulte Desarrollo rápido.
Pasos siguientes
Compromiso empresarial en la administración de la nube
Administración de la alineación de la organización
No se puede llevar a cabo la adopción de la nube sin personas bien organizadas. La adopción correcta de la
nube es el resultado de un equipo de personas debidamente cualificadas, que realiza los tipos de trabajo
adecuados, en consonancia con objetivos empresariales claramente definidos y en un entorno bien
administrado. Para ofrecer un modelo de funcionamiento eficaz para la nube, es importante establecer
estructuras organizativas con el personal adecuado. En este artículo se describe un enfoque para establecer y
mantener las estructuras organizativas adecuadas en cuatro pasos.
Los ejercicios siguientes le ayudarán a guiar el proceso de creación de una zona de aterrizaje que admita la
Tipo de estructura: Defina el tipo de estructura organizativa

que mejor se adapte a su modelo operativo.
Funciones de la nube: comprenda la funcionalidad de la nube

que se necesita para adoptar la nube y trabajar en ella.
Estructuras de equipo maduras: defina los equipos que

pueden proporcionar diversas funciones de la nube.
Matrix RACI: Unos roles claramente definidos son un aspecto

importante de cualquier modelo operativo. Use la matriz
RACI que se proporciona para asignar roles de
responsabilidad, consultados e informados, a cada uno de
los equipos de las distintas funciones del modelo operativo
en la nube.
Tipo de estructura
Las siguientes estructuras organizativas no tienen por qué asignarse a un organigrama. Normalmente, los
organigramas reflejan estructuras de administración de mando y control. Por el contrario, las siguientes
estructuras organizativas están diseñadas para capturar la alineación de los roles y las responsabilidades. En una
organización matricial ágil, la mejor forma de representar estas estructuras es como equipos virtuales. No hay
ninguna limitación que sugiera que estas estructuras organizativas no se pudieran representar en un
organigrama, pero no son necesarias para crear un modelo operativo eficaz.
El primer paso en la administración de la alineación organizativa consiste en determinar cómo realizar las
siguientes estructuras organizativas:
Alineación del organigrama: Las jerarquías de administración, las responsabilidades del administrador y
la alineación del personal se alinearán con las estructuras organizativas.
Equipos vir tuales: Las estructuras de administración y los organigramas permanecen sin cambios. En su
lugar, se crearán equipos virtuales que se encargarán de las funciones necesarias.
Modelo mixto: Es más habitual que se necesite una combinación de alineación de organigrama y equipo
virtual para conseguir objetivos de transformación.
Descripción de las funciones necesarias de la nube

A continuación se muestra una lista de las funciones de la nube que se necesitan para tener éxito en la adopción
de la nube y para disponer de modelos operativos a largo plazo. Después de familiarizarse con estas funciones
de la nube, se pueden alinear con las estructuras organizativas en función del personal y el nivel de madurez de
la organización:
Estrategia de la nube: Alineación de cambios técnicos con las necesidades empresariales.
Adopción de la nube: Ofrecimiento de soluciones técnicas.
Gobernanza de la nube: Administración del riesgo.
Equipo de TI central: Soporte técnico del personal de TI existente.
Operaciones en la nube: Soporte y uso de las soluciones adoptadas.
Centro de excelencia de la nube: Mejora de la calidad, velocidad y resistencia de la adopción.
Plataforma de nube: Uso y maduración de la plataforma.
Automatización en la nube: Aceleración de la adopción y la innovación.
Datos en la nube: Administrar datos y habilitar soluciones de análisis.
Seguridad en la nube: Administración del riesgo de seguridad de la información.
Hasta cierto punto, cada una de estas funciones se refleja en todos los esfuerzos de adopción de la nube, ya sea
explícitamente o de acuerdo con una estructura de equipo definida.
A medida que aumentan las necesidades de adopción, aumenta la necesidad de contar con un equilibrio y una
estructura. Para satisfacer estas necesidades, las empresas a menudo siguen un proceso de madurez de las
estructuras organizativas.
El artículo sobre la determinación de la madurez de la estructura organizativa proporciona detalles adicionales

sobre cada nivel de madurez.
Para realizar un seguimiento de las decisiones sobre la estructura de la organización a lo largo del tiempo,
descargue y modifique la plantilla de RACI.
Funciones de estrategia de la nube
Un equipo de estrategia de la nube define las motivaciones y los resultados empresariales y valida y mantiene la
alineación entre las prioridades empresariales y los esfuerzos de adopción de la nube. En ausencia de un equipo
de estrategia de la nube definido, alguien debe proporcionar la funcionalidad para alinear las actividades
técnicas con los resultados empresariales. Esa misma persona o grupo también debe administrar los cambios a
lo largo del proyecto.
Por lo general, los tipos de roles siguientes proporcionan las funciones de estrategia de la nube. Cuando se
define un equipo de estrategia de la nube, debe incluir muchos de los siguientes roles:
Finance
Línea de negocio
Recursos humanos
Operaciones
Arquitectura empresarial
Infraestructura de TI
Grupos de aplicaciones
Jefes de proyecto (a menudo con experiencia en la administración ágil de proyectos)
Esto ayuda a guiar los esfuerzos principales de asignación de prioridades y detección durante la adopción de la
nube. También puede desencadenar cambios en los procesos empresariales, la ejecución de operaciones, las
interacciones de los clientes o incluso el desarrollo del producto. Si estas funciones se reducen a TI, se limitará el
éxito de los esfuerzos de adopción de la nube. Para promover un verdadero cambio empresarial, los líderes de la
empresa deben ser el origen principal de esta funcionalidad. Un equipo definido de estrategia de la nube
proporciona un medio para involucrar a los participantes clave de una manera estructurada.
NOTE
El CEO y el CIO de la organización suelen asignar el equipo. Normalmente, las asignaciones se basan en permitir a este
equipo controlar los cambios que se producen en las diferentes organizaciones de la empresa. Los miembros del equipo
de estrategia de la nube deben asignarse en función de las motivaciones para la adopción de la nube, los resultados
empresariales y los modelos financieros pertinentes.
Preparación
Descubra el valor empresarial de Microsoft Azure.
Descubra como Cloud Adoption Framework puede ayudarlo a alinear la estrategia para la empresa, las
personas y la tecnología.
Revise el proceso de estrategia de adopción de la nube.
Descargue la plantilla de estrategia y plan.
Ámbito mínimo
Alinee las partes interesadas del negocio para maximizar el valor empresarial de las inversiones en adopción de
la nube.
Siempre que sea posible, se deben definir los resultados empresariales y la estrategia de la nube en una fase
temprana del proceso. A medida que crecen las inversiones en la adopción de la nube y se obtienen valores
empresariales, las partes interesadas del negocio suelen implicarse más. Cuando la empresa lidera los esfuerzos
de adopción de la nube, el enfoque podría estar en un modelo operativo y en la organización.
Establecimiento de una visión
Motivaciones para la adopción: Documente y articule los motivos del esfuerzo técnico.
Resultados empresariales: Articule claramente lo que se espera del equipo técnico en lo que respecta a los
cambios empresariales.
Métricas de aprendizaje: Establezca métricas a corto plazo que puedan mostrar el progreso hacia los
resultados empresariales a largo plazo.
Creación de una justificación comercial
Creación de un caso empresarial de migración a la nube. Establezca un caso empresarial para la migración a
la nube.
Racionalización incremental: Un enfoque ágil para la racionalización que alinea correctamente las decisiones
técnicas enlazadas en tiempo de ejecución.
Las cinco "R" de la racionalización: Comprender las diversas opciones de racionalización.
Resultado esperado
El equipo de estrategia de la nube impulsa los esfuerzos críticos de detección y establecimiento de prioridades
durante la adopción de la nube. También pueden cambiar los procesos empresariales, la ejecución de
operaciones, las interacciones de los clientes o incluso el desarrollo del producto. El objetivo principal del equipo
de estrategia de la nube es validar y mantener la alineación entre las prioridades empresariales y los esfuerzos
de adopción de la nube. En segundo lugar, este equipo se tiene que centrar en la administración de cambios de
todos los esfuerzos de adopción. El equipo de estrategia de la nube debe ser capaz de cumplir con las tareas
siguientes.
Tareas de planeamiento iniciales:
Revise y proporcione comentarios sobre los resultados empresariales y los modelos financieros.
Ayude a establecer motivaciones claras para la adopción de la nube que estén alineadas con los objetivos
corporativos.
Defina métricas de aprendizaje relevantes que muestren claramente el progreso hacia la consecución de los
Comprenda que los riesgos empresariales que genera el plan representan la tolerancia al riesgo de la
empresa.
Revise y apruebe la racionalización del patrimonio digital.
Tareas mensuales continuadas:
Apoye al equipo de gobernanza de la nube durante las conversaciones sobre riesgos o tolerancia a estos.
Revise los planes de lanzamiento para comprender las escalas de tiempo y el impacto empresarial de los
cambios técnicos.
Defina los planes de cambios empresariales asociados a los lanzamientos planeados.
Asegúrese de que los equipos empresariales están preparados para ejecutar las pruebas empresariales y el
plan de cambio empresarial.
Cadencia de las reuniones:
Los miembros del equipo de estrategia en la nube deben se capaces de asignar el tiempo necesario para planear
y desarrollar la estrategia en la nube:
Durante los primeros esfuerzos de planeamiento, asigne una hora cada semana para reunirse con el equipo.
Una vez que se consolide el plan de adopción (por lo general, en 4-6 semanas), se pueden reducir los
requisitos de tiempo.
A lo largo de los esfuerzos de adopción, asigne 1 o 2 horas al mes para revisar el progreso y validar las
prioridades continuas.
Es probable que se necesite un tiempo adicional para los miembros delegados del equipo ejecutivo según
sea necesario. Cada miembro del equipo de estrategia de la nube debe designar un delegado que pueda
disponer de 5-10 horas por semana para atender preguntas sobre la priorización en curso e informar sobre
necesidades urgentes.
Pasos siguientes
Inicie un equipo de estrategia de la nube.
Alinee su estrategia con las funciones de adopción de la nube mediante la creación de un equipo de
adopción de la nube con el cual trabajar.
Use la plantilla de RACI para alinear las responsabilidades entre los equipos.
Funciones de adopción de la nube
Las funciones de adopción de la nube permiten la implementación de soluciones técnicas en la nube. Al igual
que en cualquier proyecto de TI, las personas que llevan a cabo el trabajo real determinarán su éxito. Los
equipos que proporcionan las funciones necesarias de adopción de la nube pueden formarse de la mano de
diversos expertos en la materia o asociados de implementación.
Los equipos de adopción de la nube son el equivalente moderno de los equipos de implementación técnica o los
equipos de proyecto. No obstante, la naturaleza de la nube puede requerir una estructura de equipo más fluida.
Algunos equipos se centran exclusivamente en la migración a la nube, mientras que otros se centran en las
innovaciones que aprovechan las tecnologías en la nube. Algunos equipos cuentan con los amplios
conocimientos técnicos necesarios para completar grandes trabajos de adopción, como una migración completa
del centro de datos. Otros equipos tienen un enfoque técnico más estricto y pueden moverse entre proyectos
para lograr objetivos específicos. Un ejemplo sería un equipo de especialistas en plataformas de datos que
ayudan a convertir máquinas virtuales SQL en instancias PaaS de SQL.
Independientemente del tipo o el número de equipos de adopción de la nube, la funcionalidad necesaria para la
adopción de la nube la proporcionan expertos en la materia que se encuentran entre los asociados de TI, análisis
empresarial o implementación.
Según los resultados empresariales deseados, algunas de las aptitudes necesarias para proporcionar
funcionalidades completas de adopción de la nube podrían ser las siguientes:
Implementadores de infraestructura
Ingenieros de DevOps
Desarrolladores de aplicaciones
Científicos de datos
Especialistas en plataformas de aplicaciones o datos
Para una colaboración y eficiencia óptimas, se recomienda que los equipos de adopción de la nube tengan un
tamaño medio de seis personas. Estos equipos deben organizarse internamente desde una perspectiva de
ejecución técnica. Se recomienda encarecidamente que estos equipos incluyan también expertos en
administración de proyectos, con una mayor experiencia en Agile, Scrum u otros modelos iterativos. Este equipo
es más eficaz cuando se administra mediante una estructura plana.
Preparación
Creación de una cuenta de Azure: El primer paso para usar Azure es crear una cuenta.
Introducción a Azure: comience a usar Azure. Cree y configure su primera máquina virtual en la nube.
Aspectos básicos de Azure: Conozca los conceptos de la nube, comprenda las ventajas, compare y contraste
las estrategias básicas y explore la amplitud de servicios disponibles en Azure.
Revise la metodología de migración.
Ámbito mínimo
El núcleo de todos los trabajos de adopción de la nube es el equipo de migración a la nube. Este equipo impulsa
los cambios técnicos que permiten la adopción. En función de los objetivos del esfuerzo de adopción, este
equipo puede estar compuesto por una gama diversa de miembros que se ocupan de un amplio conjunto de
tareas técnicas y comerciales.
Como mínimo, el ámbito del equipo incluye:
Revisión, validación y avance en el trabajo pendiente de migración prioritario
La ejecución de la primera carga de trabajo como una oportunidad de aprendizaje.
Resultado
La principal necesidad de cualquier función de adopción de la nube es la implementación oportuna y de alta
calidad de las soluciones técnicas que se describen en el plan de adopción. Estas soluciones deben estar en
consonancia con los requisitos de gobernanza y los resultados empresariales, y deben aprovechar las ventajas
de la tecnología, las herramientas y las soluciones de automatización que están disponibles para el equipo.
Tareas de planeamiento iniciales:
Ejecución de la racionalización del patrimonio digital.
Revisión, validación y avance en el trabajo pendiente de migración prioritario.
Comienzo de la ejecución de la primera carga de trabajo como oportunidad de aprendizaje.
Supervisión de los procesos de administración de cambios.
Administración de los trabajos pendientes de lanzamiento y sprint.
Creación y mantenimiento de la zona de aterrizaje de la adopción junto con los requisitos de gobernanza.
Ejecución de las tareas técnicas indicadas en los trabajos pendientes de sprint.
Se recomienda que los equipos que proporcionan las funciones de adopción de la nube se dediquen a esta labor
a tiempo completo.
Es preferible que estos equipos se reúnan a diario y se organicen internamente. El objetivo de las reuniones
diarias es actualizar rápidamente el trabajo pendiente y comunicar qué se ha completado, qué se debe realizar
hoy, y qué está bloqueado y precisa soporte externo adicional.
Las programaciones de los lanzamientos y la duración de las iteraciones son únicas para cada empresa. Aunque
parece que la duración media se sitúa en un intervalo de una a cuatro semanas por iteración. Con
independencia de la cadencia de iteración o de lanzamiento, se recomienda que el equipo se reúna con todos los
equipos auxiliares al final de cada lanzamiento para comunicar el resultado del lanzamiento y volver a
establecer la prioridad de los siguientes trabajos. Del mismo modo, resulta útil la reunión del equipo al final de
cada sprint con el centro de excelencia de la nube o con el equipo de gobernanza de la nube para mantenerse al
día del trabajo común y de las necesidades de apoyo.
Algunas de las tareas técnicas asociadas a la adopción de la nube pueden volverse repetitivas. Los miembros del
equipo deben rotar cada 3–6 meses para evitar problemas de satisfacción de los empleados y mantener las
aptitudes adecuadas. Un puesto rotatorio en el centro de excelencia de la nube o en el equipo de gobernanza de
la nube puede suponer una excelente oportunidad para mantener a los empleados actualizados y aprovechar
las innovaciones.
Más información sobre la función de un centro de excelencia de la nube o de un equipo de gobernanza de la
nube.
Pasos siguientes
Formación de un equipo de adopción de la nube
Alinee los trabajos de adopción de la nube con las funciones de gobernanza de la nube para acelerar la
adopción e implementar los procedimientos recomendados y reducir al mismo tiempo los riesgos
empresariales y técnicos.
Funciones de gobernanza de la nube
El equipo de gobernanza de la nube garantiza una evaluación y administración correctas de los riesgos y la
tolerancia a ellos. Este equipo garantiza la identificación adecuada de los riesgos que no puede tolerar la
empresa. Las personas de este equipo convierten los riesgos en directivas corporativas de gobernanza.
Según los resultados empresariales deseados, algunas de las aptitudes necesarias para proporcionar funciones
completas de gobernanza de la nube son:
Gobernanza de TI
Seguridad
Operaciones de TI
Redes
Identidad
Virtualización
Propietarios de aplicaciones dentro de TI
Propietarios de finanzas
Estas funciones de base de referencia le ayudan a identificar los riesgos relacionados con las versiones actuales
y futuras. Estos trabajos le ayudan a evaluar el riesgo, comprender los posibles efectos y tomar decisiones
respecto a la tolerancia a los riesgos. Cuando los haga, actualice rápidamente los planes para que reflejen las
necesidades cambiantes del equipo de migración a la nube.
Preparación
Revise la metodología de gobernanza.
Realice una valoración del banco de pruebas de gobernanza.
Introducción a la seguridad en Azure: conozca los conceptos básicos para proteger la infraestructura y los
datos en la nube. Conozca cuáles son sus responsabilidades y de cuáles se encarga Azure.
Aprenda a trabajar entre grupos para administrar los costos.
Ámbito mínimo
Comprender los riesgos empresariales introducidos por el plan
Representar la tolerancia al riesgo de la empresa
Ayudar a crear un MVP de gobernanza
Implique a los siguientes participantes en las actividades de gobernanza de la nube:
Los líderes de la administración media y los colaboradores directos en puestos destacados deben
representar a la empresa ayudarán a evaluar la tolerancia al riesgo.
Las funciones de gobernanza de la nube se ofrecen como una extensión del equipo de estrategia de la nube.
Igual que se espera que el director de sistemas (CIO) y los líderes empresariales participen en las funciones
de estrategia de la nube, se espera que sus subordinados directos participen en las actividades de
gobernanza de la nube.
Los empleados de la empresa que son miembros de la unidad de negocio que trabajan estrechamente con la
dirección de la línea de negocio deben estar capacitados para tomar decisiones relacionadas con el riesgo
técnico y corporativo.
Los empleados de tecnologías de la información (TI) y seguridad de la información (IS) que comprenden los
aspectos técnicos de la transformación hacia nube pueden servir de capacidad rotativa en lugar de como
proveedor constante de funciones de gobernanza de la nube.
Resultado
La misión de la gobernanza de la nube es equilibrar las fuerzas contrarias de transformación y la mitigación de
los riesgos. Además, la gobernanza de la nube garantiza que el equipo de migración a la nube está al tanto de
las directrices sobre arquitectura y clasificación de datos y recursos que regulan la adopción. Los equipos o
personas de gobernanza también trabajan con el centro de excelencia de la nube para aplicar enfoques
automatizados a los entornos de gobernanza de la nube.
Comprender los riesgos empresariales introducidos en cada versión
Representar la tolerancia al riesgo de la empresa
Ayudar a la mejora incremental de los requisitos de cumplimiento y directivas.
El compromiso de tiempo de cada miembro del equipo de gobernanza de la nube representará un gran
porcentaje de sus programaciones diarias. Las contribuciones no se limitarán a reuniones y ciclos de
comentarios.
Fuera de ámbito
A medida que se extiende la adopción, el equipo de gobernanza de la nube puede tener problemas para
mantenerse al ritmo de las innovaciones. Esto es especialmente cierto en entornos que tienen requisitos
intensivos de cumplimiento, operaciones o seguridad. Si este es el caso, puede desplazar algunas
responsabilidades a un equipo de TI existente para reducir el ámbito del equipo de gobernanza.
Pasos siguientes
Algunas organizaciones de gran tamaño cuentan ya con equipos dedicados que se centran en la gobernanza de
TI. Estos equipos se especializan en la administración de riesgos en la cartera de TI. Cuando se tienen estos
equipos, los siguientes modelos de madurez se pueden acelerar rápidamente. Aunque se recomienda que el
equipo de gobernanza de TI revise el modelo de gobernanza de la nube para comprender cómo la gobernanza
cambia ligeramente en la nube. Los artículos principales incluyen la extensión de la directiva corporativa a la
nube y las cinco materias de la gobernanza de la nube.
Sin gobernanza: a menudo, las organizaciones se mueven a la nube sin planes claros de gobernanza.
Enseguida, los problemas relacionadas con la seguridad, el costo, la escala y las operaciones comienzan a
desencadenar conversaciones sobre la necesidad de un modelo de gobernanza y la dotación de personal para
llevar a cabo los procesos asociados con ese modelo. Iniciar esas conversaciones antes de que se conviertan en
problemas es siempre un buen primer paso para superar el antipatrón de "sin gobernanza". La sección sobre la
definición de la directiva corporativa puede ayudar a facilitar esas conversaciones.
Gobernanza bloqueada: cuando los problemas entono a la seguridad, el costo, la escala y las operaciones
quedan sin respuesta, los proyectos y los objetivos empresariales tienden a bloquearse. La falta de una
gobernanza adecuada genera temor, incertidumbre y dudas entre las partes interesadas y los ingenieros. Tome
medidas lo antes posible para impedir que esta situación avance. Las dos guías de gobernanza definidas en
Cloud Adoption Framework pueden ayudarle a comenzar poco a poco, a establecer directivas inicialmente
limitadoras para reducir la incertidumbre y a desarrollar la gobernanza con el tiempo. Elija entre la guía de
empresa compleja o la guía de empresa estándar.
Gobernanza voluntaria: En todas las empresas siempre hay algunos valientes. Personas que están dispuestas
a lanzarse y ayudar al equipo a aprender de sus errores. A menudo así es como comienza la gobernanza, en
especial en empresas pequeñas. Estos valientes se ofrece como voluntarios para resolver algunos problemas y
empujar a los equipos de adopción de la nube hacia un conjunto de procedimientos recomendados coherentes
y bien administrados.
Los esfuerzos de estas personas son mucho mejores que los escenarios "sin gobernanza" o "gobernanza
bloqueada". Aunque estos esfuerzos son dignos de elogio, este enfoque no debe confundirse con la gobernanza.
Una gobernanza adecuada requiere algo más que ayuda esporádica para impulsar la coherencia, que es el
objetivo de cualquier buen enfoque de gobernanza. La guía de las cinco materias de gobernanza de la nube
puede ayudar a desarrollar esta materia.
Custodio de la nube: este apodo se ha convertido en una insignia de honor para muchos arquitectos de la
nube que se especializan en la gobernanza en su fase temprana. La primera vez que se emprenden las prácticas
de gobernanza, los resultados parecen similares a los de los voluntarios de la gobernanza. Aunque hay una
diferencia fundamental. Un custodio de la nube tiene un plan en mente. En esta fase de madurez, el equipo
dedica tiempo a limpiar el desorden realizado por los arquitectos de la nube que llegaron antes que ellos.
Aunque el custodio de la nube alinea esa labor con directivas corporativas bien estructuradas. También usa
herramientas de gobernanza, como las que se describen en el MVP de gobernanza.
Otra diferencia fundamental entre un custodio de la nube y un voluntario de la gobernanza es el apoyo de la
dirección. El voluntario invierte horas adicionales y sobrepasa las expectativas normales por su afán de aprender
y hacer. El custodio de la nube obtiene el respaldo de la dirección para reducir sus deberes diarios y garantizar
que se pueden invertir las asignaciones normales de tiempo en la mejora de la gobernanza de la nube.
Guardián de la nube: a medida que se consolidan los procedimientos de gobernanza y los equipos de
adopción de la nube las aceptan, el rol de los arquitectos de la nube especializados en la gobernanza cambia un
poco, al igual que el del equipo de gobernanza de la nube. Por lo general, los procedimientos más madurados se
ganan la atención de los expertos en la materia, quienes pueden ayudar a reforzar las protecciones que
proporcionan las implementaciones de la gobernanza.
Aunque la diferencia es sutil, esta es una distinción importante al crear una cultura de TI centrada en la
gobernanza. Un administrador en la nube se encarga de solucionar los problemas que crean los arquitectos en
la nube con sus innovaciones, así que se puede decir que estos dos roles tienen objetivos encontrados. Un
administrador en la nube ayuda a mantener la nube segura, para que los arquitectos en la nube puedan
moverse rápidamente y crear menos problemas.
Los guardianes de la nube comienzan con enfoques de gobernanza avanzados a fin de acelerar la
implementación de la plataforma y ayudar a los equipos a ser autosuficientes en cuanto a sus necesidades
ambientales, de modo que puedan avanzar más rápido. Ejemplos de estas funciones más avanzadas se aprecian
en las mejoras incrementales del MVP de gobernanza, como la mejora de la base de referencia de seguridad.
Aceleradores de la nube: los guardianes y los custodios de la nube recopilan de forma natural scripts y
herramientas de gobernanza que aceleran la implementación de entornos, plataformas o incluso componentes
de varias aplicaciones. Conservar y compartir estos scripts, además de las responsabilidades de gobernanza
centralizadas, desarrolla un alto grado de respeto por estos arquitectos en todo el ámbito de TI.
Aquellos profesionales de gobernanza que compartan de forma abierta sus scripts conservados ayudarán a
ofrecer proyectos tecnológicos con mayor rapidez y a incorporar la gobernanza en la arquitectura de las cargas
de trabajo. Esta influencia de la carga de trabajo y el respaldo de unos buenos patrones de diseño elevan los
aceleradores de la nube a una categoría mayor de especialista en gobernanza.
Gobernanza global: cuando las organizaciones dependen de necesidades de TI distribuidas globalmente,
puede haber desviaciones importantes en las operaciones y la gobernanza de diversas zonas geográficas. Las
demandas de las unidades de negocio e incluso los requisitos de soberanía de los datos locales pueden hacer
que los procedimientos recomendados de gobernanza interfieran con las operaciones necesarias. En estos
casos, un modelo de gobernanza por niveles permite una coherencia mínimamente viable y una gobernanza
localizada. En el artículo sobre varios niveles de gobernanza se proporciona más información sobre el alcance
de este nivel de madurez.
Cada empresa es única y, por lo tanto, también lo son sus necesidades de gobernanza. Elija el nivel de madurez
que mejor se adapte a su organización y use Cloud Adoption Framework para que guíe las prácticas, los
procesos y las herramientas que le ayuden a conseguirlo.
A medida que la gobernanza de la nube madure, los equipos estarán capacitados para adoptar la nube a un
ritmo mayor. Los continuos esfuerzos de adopción de la nube tienden a desencadenar la madurez en las
operaciones de TI. Desarrolle un equipo de operaciones de la nube, o bien permanezca sincronizado con su
equipo de operaciones de la nube para asegurarse de que la gobernanza forme parte del desarrollo de las
operaciones.
Más información sobre el inicio de un equipo de gobernanza de la nube o un equipo de operaciones de la nube.
Cuando haya establecido una base inicial de gobernanza de la nube, use los procedimientos que se indican en
Mejoras de una base de gobernanza para avanzar en el plan de adopción y evitar riesgos.
Funciones del equipo de TI central
A medida que se extiende la adopción de la nube, puede que las funcionalidades de gobernanza de la nube no
sean suficientes por sí solas para gobernar los trabajos de adopción. Si la adopción es gradual, los equipos
tienden a desarrollar orgánicamente las aptitudes y los procesos necesarios para estar preparados para la nube
con el tiempo.
No obstante, cuando un equipo de adopción de la nube usa esta para lograr un resultado empresarial de alto
perfil, este rara vez es el caso. El éxito llama al éxito. Esto también es cierto en la adopción de la nube, pero se
produce en la escala de la nube. Cuando la adopción de la nube se amplía de un equipo a varios equipos con
relativa rapidez, se necesita soporte técnico adicional por parte del personal de TI existente. No obstante, es
posible que ese personal no tenga el entrenamiento y la experiencia necesarios para dar soporte técnico a la
nube mediante herramientas de TI nativas en la nube. Esto a menudo conduce a la formación de un equipo de TI
central que gobierna la nube.
Cau t i on
Aunque se trata de un paso habitual del proceso de consolidación, su adopción puede suponer un riesgo
elevado y es posible que bloquee los esfuerzos de innovación y migración si no se administra correctamente.
Consulte la sección sobre riesgos que aparece a continuación para aprender a mitigar el riesgo de que la
centralización se convierta en un antipatrón cultural.
Las aptitudes necesarias para proporcionar funciones de TI centralizadas pueden proceder de:
Un equipo de TI centralizado existente
Arquitectos empresariales
Operaciones de TI
Gobernanza de TI
Redes
Identidad
Virtualización
WARNING
Las funciones de TI centralizadas solo se deberían aplicar en la nube si el entorno local existente de trabajo se basa en un
modelo de equipo de TI central. Si el modelo local actual se basa en el control delegado, considere la posibilidad de
emplear una estrategia con un centro de excelencia de la nube (CCoE) como alternativa más adecuada para la nube.
Principales responsabilidades
Adapte los procedimientos de TI existentes para asegurarse de que los esfuerzos de adopción den como
resultado entornos bien gobernados y bien administrados en la nube.
Las siguientes tareas se ejecutan normalmente con regularidad:
Tareas estratégicas
Revisión:
Resultados empresariales.
Modelos financieros
Motivaciones para la adopción de la nube
Supervisión de los planes de adopción y del progreso en comparación con los trabajos pendientes de
migración prioritarios.
Identificación y clasificación por orden de prioridad de los cambios necesarios para dar soporte a los trabajos
pendientes de la migración.
Actuar como un nivel intermedio o de traducción entre las necesidades de adopción de la nube y los equipos
de TI existentes.
Aprovechamiento de los equipos de TI existentes para acelerar las funciones de la plataforma y permitir la
adopción.
Tareas técnicas
Creación y mantenimiento de la plataforma en la nube que admita las soluciones.
Definición e implementación de la arquitectura de la plataforma.
Funcionamiento y administración de la plataforma en la nube.
Mejora continua de la plataforma.
Mantenerse al día de las innovaciones en la plataforma de nube.
Proporcionar nuevas funciones de nube para respaldar la creación de valor empresarial.
Sugerir soluciones de autoservicio.
Asegurarse de que las soluciones cumplen los requisitos de gobernanza y cumplimiento existentes.
Creación y validación de la implementación de la arquitectura de la plataforma.
Revisión de los planes de lanzamiento para conocer el origen de los nuevos requisitos de la plataforma.
Cadencia de las reuniones

Normalmente, los conocimientos de un equipo de TI central proceden de un equipo de trabajo. Se espera que
los participantes se comprometan a emplear gran parte de sus programaciones diarias en los esfuerzos de
alineación. Las contribuciones no se limitan a reuniones y ciclos de comentarios.
Riesgos del equipo de TI central

Cada una de las funcionalidades de la nube y las fases de madurez de la organización van acompañadas de la
palabra "nube". El equipo de TI central es la única excepción. Las funciones de TI centralizadas son las más
frecuentes cuando todos los recursos de TI se pueden hospedar en varias ubicaciones y un número reducido de
equipos puede administrarlas y controlarlas mediante una plataforma única de administración de operaciones.
Los procedimientos empresariales globales y la economía digital han reducido en gran medida las instancias de
tales entornos de administración centralizados.
Desde el punto de vista más actual de TI, los recursos se distribuyen globalmente. Las responsabilidades se
delegan. La administración de las operaciones se proporciona gracias a una combinación de personal interno,
proveedores de servicios administrados y proveedores de servicios en la nube. En cuanto a la economía digital,
los procedimientos de administración de TI están evolucionando a un modelo de control delegado y de
autoservicio con claras directrices de seguridad para aplicar la gobernanza. Un equipo de TI central puede
resultar un gran colaborador para la adopción de la nube si se convierte en agente y asociado de la nube para
impulsar la innovación y la agilidad empresarial.
Un equipo de TI central se encuentra en una buena posición para recabar conocimientos y procedimientos
valiosos a partir de los modelos locales existentes y aplicar esos procedimientos para la implementación de la
nube. Aunque este proceso requiere cambios. Se necesitan nuevos procesos, nuevas aptitudes y nuevas
herramientas para promover la adopción de la nube a escala. Cuando se adapta el equipo de TI central, se
convierte en un asociado importante para los esfuerzos de adopción de la nube. No obstante, si el equipo de TI
central no se adapta a la nube, o si intenta usar esta como un catalizador para imponer unos controles más
estrictos, este equipo se convierte rápidamente en un obstáculo para los trabajos de adopción, innovación y
migración.
Los valores para medir este riesgo son la velocidad y la flexibilidad. La nube simplifica la adopción de nuevas
tecnologías rápidamente. Cuando hay nuevas funcionalidades de la nube que se pueden implementar en
cuestión de minutos, pero las revisiones del equipo de TI central suman semanas o meses al proceso de
implementación, estos procesos centralizados se convierten en un impedimento importante para el éxito
empresarial. Si se encuentra este indicador, considere la posibilidad de usar estrategias alternativas a la entrega
de TI.
Excepciones
Muchos sectores requieren una estricta adhesión a requisitos de cumplimiento de terceros. Algunos requisitos
de cumplimiento siguen demandando un control de TI centralizado. Proporcionar estas medidas de
cumplimiento puede agregar tiempo a los procesos de implementación, especialmente en el caso de nuevas
tecnologías que no se han usado ampliamente. En estos casos, espere retrasos en la implementación durante las
primeras fases de la adopción. Pueden existir situaciones similares para las empresas que trabajan con
información confidencial de los clientes, pero que no están gobernadas por un requisito de cumplimiento de
terceros.
Funcionamiento en las excepciones
Si se requieren procesos de TI centralizados y esos procesos crean puntos de control apropiados en la adopción
de nuevas tecnologías, estos puntos de control de la innovación se pueden abordar con rapidez. Los requisitos
de gobernanza y cumplimiento están diseñados para proteger la información confidencial, no para proteger
todo tipo de información. La nube proporciona mecanismos sencillos para adquirir e implementar recursos
aislados manteniendo barreras de seguridad adecuadas.
Un equipo de TI centralizado maduro mantiene las protecciones necesarias, pero negocia procedimientos que
siguen permitiendo la innovación. La demostración de este nivel de madurez depende de una adecuada
clasificación y aislamiento de los recursos.
Ejemplo de narrativa de funcionamiento en las excepciones para habilitar la adopción
Este ejemplo de narrativa sirve para ilustrar el enfoque adoptado por un equipo de TI central maduro en una
empresa imaginaria llamada Contoso para habilitar la adopción.
Contoso ha adoptado un modelo de equipo de TI central para dar soporte a los recursos en la nube de la
empresa. Para proporcionar este modelo, han implementado controles estrictos para varios servicios
compartidos, como las conexiones de red de entrada. Esta medida prudente ha reducido la exposición de su
entorno en la nube y ha proporcionado un único dispositivo de "emergencia" para bloquear todo el tráfico si se
produce una infracción. Sus directivas de base de referencia de seguridad establecen que todo el tráfico de
entrada debe pasar por un dispositivo compartido que administra el equipo de TI central.
No obstante, uno de sus equipos de adopción de la nube necesita ahora un entorno con una conexión de red de
entrada dedicada y configurada especialmente para usar una tecnología en la nube concreta. Un equipo de TI
centralizado inmaduro simplemente rechazaría la solicitud y daría prioridad a los procesos existentes en lugar
de a las necesidades de adopción. El equipo de TI centralizado de Contoso es diferente. Han identificado
rápidamente una solución sencilla de cuatro partes a este dilema:
1. Clasificación: Dado que el equipo de adopción de la nube se encontraba en las primeras fases de la
creación de una nueva solución y no tenía ninguna información confidencial ni necesidades de soporte
técnico críticas, los recursos del entorno se clasificaron como de bajo riesgo y no críticos. Una clasificación
efectiva es un signo de madurez del equipo de TI central. La clasificación de todos los recursos y entornos
permite directivas más claras.
2. Negociación: Solo la clasificación no es suficiente. Se implementaron servicios compartidos para trabajar
de forma coherente con recursos confidenciales y críticos. El cambio de las reglas pondría en peligro las
directivas de cumplimiento y gobernanza diseñadas para los recursos que necesitan más protección. No se
puede habilitar la adopción a costa de poner en peligro la estabilidad, seguridad o gobernanza. Esto condujo
a una negociación con el equipo de adopción para dar respuesta a preguntas específicas. ¿Podría un equipo
de desarrollo y operaciones dirigido por la empresa proporcionar administración de operaciones para este
entorno? ¿Requeriría esta solución acceso directo a otros recursos internos? Si el equipo de adopción de la
nube acepta estos inconvenientes, puede que el tráfico de entrada sea posible.
3. Aislamiento: Como la empresa puede proporcionar su propia administración de las operaciones en curso y
dado que la solución no depende del tráfico directo a otros recursos internos, esta se puede aislar en una
nueva suscripción. Esa suscripción también se agrega a un nodo independiente de la nueva jerarquía del
4. Automation: Otro signo de madurez de este equipo son sus principios de automatización. El equipo usa
Azure Policy para automatizar la aplicación de directivas. También usan Azure Blueprints para automatizar la
implementación de los componentes habituales de la plataforma y aplicar la adhesión a la base de referencia
de la identidad definida. Para esta suscripción y cualquier otra del nuevo grupo de administración, las
directivas y plantillas son ligeramente diferentes. Se han suprimido las directivas que bloqueaban el ancho
de banda de entrada. Se han sustituido por requisitos para enrutar el tráfico a través de la suscripción de los
servicios compartidos, como cualquier tráfico de entrada, para aplicar el aislamiento del tráfico. Dado que las
herramientas de administración de operaciones del entorno local no pueden acceder a esta suscripción, los
agentes de esa herramienta ya no son necesarios. Las demás barreras de seguridad de la gobernanza que
requieren otras suscripciones de la jerarquía del grupo de administración se siguen aplicando, lo que
garantiza que haya suficientes barreras de seguridad.
El enfoque creativo maduro del equipo de TI central de Contoso ofreció una solución que no ponía en peligro ni
la gobernanza ni el cumplimiento, y que fomentaba la adopción. Este enfoque de intermediación en lugar de los
enfoques de propiedad nativos en la nube hacia un equipo de TI centralizado es el primer paso hacia la creación
de un verdadero centro de excelencia de la nube (CCoE). La adopción de este enfoque para desarrollar
rápidamente las directivas existentes le permitirá tener un control centralizado si es necesario y barreras de
seguridad de gobernanza cuando una mayor flexibilidad sea aceptable. El equilibrio entre estos dos aspectos
mitiga los riesgos asociados a un equipo de TI centralizado en la nube.
Pasos siguientes
A medida que el equipo de TI central va madurando sus funcionalidades de la nube, el siguiente paso de
madurez es normalmente el acoplamiento débil de las operaciones de la nube. La disponibilidad de
herramientas de administración de operaciones nativas en la nube y unos costos operativos más bajos de las
soluciones basadas en PaaS, a menudo conducen a los equipos empresariales (o, más concretamente, a los
equipos de desarrollo y operaciones de la empresa) a asumir la responsabilidad de las operaciones en la
nube.
Creación de un equipo de operaciones de la nube
Un equipo de operaciones se centra en la supervisión, la reparación y la corrección de problemas relacionados

con operaciones y recursos de TI tradicionales. En la nube, muchos de los costos de capital y actividades de
operaciones se transfieren al proveedor de la nube, lo que proporciona a las operaciones de TI la oportunidad
de mejorar y agregar valor importante.
Las siguientes personas pueden proporcionar las aptitudes necesarias para las operaciones de la nube:
Operaciones de TI
Proveedores externos de operaciones de TI
Proveedores de servicios en la nube
Proveedores de servicios administrados en la nube
Equipos de operaciones específicos de la aplicación
Equipos de operaciones de aplicaciones empresariales
Equipos de desarrollo y operaciones
IMPORTANT
Las personas o equipos responsables de las operaciones en la nube suelen ser responsables de realizar cambios reactivos
en la configuración durante la corrección. También es probable que sean responsables de los cambios de configuración
proactivos para minimizar las interrupciones operativas. Según el modelo de funcionamiento de la nube en las
organizaciones, dichos cambios se pueden ofrecer a través de la infraestructura como código, Azure Pipelines, o como una
configuración directa en el portal. Dado que es probable que el equipo de operaciones tenga permisos elevados, es muy
importante que los que cumplen este rol sigan los procedimientos recomendados de identidad y control de acceso para
minimizar los cambios de acceso o de producción no deseados.
Preparación
Administración de recursos en Azure: aprenda a trabajar con la CLI de Azure y el portal web para crear,
administrar y controlar los recursos basados en la nube.
Servicios de red de Azure: conozca los aspectos básicos de las redes de Azure y aprenda a mejorar la
resistencia y a reducir la latencia.
Revise lo siguiente:
Modelos financieros
Ámbito mínimo
Entre los deberes de las personas del equipo de operaciones de la nube están los de proporcionar el máximo
rendimiento de las cargas de trabajo con el mínimo de interrupciones del negocio y dentro de los presupuestos
de operaciones acordados.
Determinar la importancia de la carga de trabajo y el efecto de las interrupciones o la degradación del
rendimiento.
Establecer compromisos de rendimiento y costo aprobados por la empresa.
Supervisar y manejar las cargas de trabajo en la nube.
Resultados
Mantener el inventario de recursos y cargas de trabajo
Supervisar el rendimiento de las cargas de trabajo
Mantener el cumplimiento operativo
Proteger las cargas de trabajo y los recursos asociados
Recuperar recursos en caso de degradación del rendimiento o interrupción del negocio
Funcionalidad madura de las plataformas principales
Mejorar continuamente el rendimiento de la carga de trabajo
Mejorar los requisitos presupuestarios y de diseño de las cargas de trabajo para adaptarse a los
compromisos con la empresa
El equipo de operaciones de la nube debe participar en el planeamiento del lanzamiento y en el del centro de
excelencia de la nube para proporcionar comentarios y prepararse para los requisitos operativos.
Fuera de ámbito
Las operaciones de TI tradicionales que se centran en el mantenimiento de las operaciones de estado actual para
recursos técnicos de bajo nivel están fuera del ámbito del equipo de operaciones de la nube. Cuestiones como
almacenamiento, CPU, memoria, equipamiento de red, servidores y hosts de máquina virtual requieren tareas
continuas de mantenimiento, supervisión, reparación y corrección de problemas para mantener las operaciones
de máximo apogeo. En la nube, muchos de estos gastos de capital y actividades operativas se trasladan al
Pasos siguientes
A medida que se escalan las operaciones y la adopción, es importante definir y automatizar los procedimientos
recomendados de gobernanza que amplían los requisitos de TI existentes. La formación de un centro de
excelencia de la nube es un paso importante para ampliar los trabajos de adopción de la nube, operaciones de la
nube y gobernanza de la nube.
Funciones del centro de excelencia de la nube.
identifique a las entidades responsables, encargadas, consultadas e informadas (RACI por sus siglas en inglés).
Descargue la plantilla RACI y modifíquela.
(CCoE)
La agilidad técnica y empresarial son objetivos fundamentales para la mayoría de las organizaciones de TI. El
centro de excelencia de la nube (CCoE) es una función que crea un equilibrio entre velocidad y estabilidad.
Estructura de la función
Un modelo de CCoE requiere la colaboración entre cada una de los siguientes componentes:
Adopción de la nube (concretamente, los arquitectos de soluciones)
Estrategia de la nube (concretamente, los jefes de proyectos y de programas)
Gobernanza de la nube
Plataforma de nube
Automatización en la nube
Impacto y cambio cultural

Si se admite esta función y se estructura correctamente, los participantes pueden acelerar los esfuerzos de
innovación y migración a la vez que reducen el costo total de los cambios y aumentan la agilidad empresarial.
Cuando se implementa correctamente, esta función puede reducir notablemente el tiempo de comercialización.
A medida que los procedimientos del equipo se consolidan, los indicadores de calidad mejoran. Entre estos
indicadores, se incluye la confiabilidad, el rendimiento, la seguridad, el mantenimiento y la satisfacción del
cliente. Estas mejoras en eficacia, agilidad y calidad son especialmente importantes si la empresa tiene previsto
implementar esfuerzos de migración a la nube a gran escala o desea emplear la nube para impulsar las
innovaciones asociadas a la diferenciación de mercado.
Si se realiza correctamente, el modelo de CCoE supondrá un cambio cultural significativo en el equipo de TI. La
premisa fundamental de un enfoque con un CCoE es que el departamento de TI actúa como un agente, asociado
o representante para la empresa. Este modelo representa un cambio de paradigma que se aleja de la
consideración tradicional de TI como una unidad de operaciones o un nivel de abstracción entre la empresa y
los recursos de TI.
La imagen siguiente proporciona una analogía de este cambio cultural. En los enfoques sin CCoE, el equipo de TI
tiende a centrarse en proporcionar control y responsabilidad central, actuando como los semáforos en un cruce.
Si el modelo con CCoE es correcto, la atención se centra en la libertad y la responsabilidad delegada, lo cual se
asemeja más a una rotonda.
Ninguno de los enfoques que se ilustran en la analogía anterior es correcto o incorrecto, solo son puntos de
vista alternativos de responsabilidad y administración. Si se desea establecer un modelo de autoservicio que
permita a las unidades de negocio tomar sus propias decisiones siempre y cuando se adhieran a un conjunto de
directrices y controles establecidos y repetibles, el modelo con un CCoE puede encajar en la estrategia
tecnológica.
Principales responsabilidades
El deber principal del equipo del CCoE es acelerar la adopción de la nube mediante soluciones híbridas o nativas
en la nube.
El objetivo del CCoE es:
Ayudar a crear una organización de TI moderna a través de métodos ágiles para capturar e implementar
requisitos empresariales.
Emplear paquetes de implementación reutilizables que se adapten a las directivas de seguridad,
cumplimiento y administración de servicios.
Mantener una plataforma de Azure funcional en consonancia con los procedimientos operativos.
Revisar y aprobar el uso de herramientas nativas en la nube.
Con el tiempo, estandarizar y automatizar los componentes y soluciones de la plataforma que se necesitan
normalmente.

El CCoE es una función dotada con personal de cuatro equipos con grandes exigencias. Es importante permitir la
colaboración orgánica y realizar un seguimiento del crecimiento mediante un repositorio o catálogo de
soluciones común. Maximice las interacciones naturales y reduzca al mínimo las reuniones. Una vez consolidada
esta función, los equipos deben intentar limitar las reuniones específicas. La asistencia a reuniones periódicas,
como las reuniones de lanzamiento que realiza el equipo de adopción de la nube, proporcionarán entradas de
datos. Al mismo tiempo, una reunión después de compartir cada plan de lanzamiento puede servir de punto de
contacto mínimo para este equipo.
Soluciones y controles
A cada miembro del CCoE se le pide que comprenda las restricciones, riesgos y protecciones necesarios que
condujeron al conjunto actual de controles de TI. Los esfuerzos colectivos del CCoE deben centrarse en
soluciones nativas en la nube (o híbridas) o en controles que permitan los resultados empresariales de
autoservicio que se desean. A medida que se crean las soluciones, estas se comparten con diversos equipos en
forma de controles o procesos automatizados que actúan como medidas de protección de los distintos trabajos.
Estas medidas de protección ayudan a enrutar las actividades de libre circulación de los diversos equipos, al
tiempo que permiten delegar responsabilidades en los participantes de los distintos esfuerzos de migración o
innovación.
Ejemplos de esta transición:
ESC EN A RIO SO L UC IÓ N A N T ERIO R A L C C O E SO L UC IÓ N P O ST ERIO R A L C C O E
Aprovisionamiento de un servidor de Los equipos de las plataformas de El equipo que requiere el servidor
SQL Server de producción redes, TI y datos aprovisionan diversos implementa una instancia de PaaS de
componentes durante días e incluso Azure SQL Database. Como
semanas. alternativa, se podría usar una plantilla
previamente aprobada para
implementar todos los recursos de
IaaS en la nube en cuestión de horas.
Aprovisionamiento de un entorno de Los equipos de redes, TI, desarrollo y El equipo de desarrollo define sus
desarrollo DevOps acuerdan las especificaciones e propias especificaciones e implementa
implementan un entorno. un entorno basado en el presupuesto
asignado.
Actualización de los requisitos de Los equipos de redes, TI y seguridad Se utilizan herramientas de

seguridad para mejorar la protección actualizan diversas máquinas virtuales gobernanza de la nube para actualizar
de datos y dispositivos de red en varios las directivas, las cuales se pueden
entornos para agregar protecciones. aplicar inmediatamente a todos los
recursos de todos los entornos en la
nube.
Negociaciones
En la raíz de cualquier esfuerzo del CCoE se encuentra un proceso de negociación continuo. El equipo del CCoE
negocia las funciones de TI existentes para reducir el control central. Las ventajas de esta negociación para la
empresa son: mayor libertad, agilidad y velocidad. El valor de estas ventajas para los equipos de TI existentes se
traduce en nuevas soluciones. Las nuevas soluciones proporcionan al equipo de TI existente una o varias de las
siguientes ventajas:
Capacidad de automatizar problemas habituales.
Mejoras en la coherencia (con la consiguiente reducción de las frustraciones diarias).
Oportunidad para aprender e implementar nuevas soluciones técnicas.
Reducción de los incidentes graves (menos correcciones y más rápidas, y menor uso de localizadores o
necesidad de respuesta a altas horas de la madrugada).
Capacidad para ampliar su ámbito técnico lo que les permite abordar temas más amplios.
Participación en soluciones empresariales de nivel superior que abordan el impacto de la tecnología.
Reducción de las tareas de mantenimiento de poca importancia.
Aumento de las estrategias tecnológicas y la automatización.
Como contrapartida a estas ventajas, el equipo de TI existente puede experimentar una reducción, real o
percibida, de los siguientes valores:
Sensación de control procedente de los procesos de aprobación manual.
Sensación de estabilidad originada por el control de cambios.
Sensación de seguridad del trabajo gracias a la finalización de tareas necesarias aunque repetitivas.
Sensación de coherencia que procede de la adhesión a los proveedores de soluciones de TI existentes.
En las mejores empresas pioneras en la implementación de la nube, este proceso de negociación es un diálogo
dinámico entre colegas y los equipos de TI asociados. Los detalles técnicos pueden ser complejos, pero son
fáciles de controlar cuando el equipo de TI comprende su finalidad y apoya los esfuerzos del CCoE. Si el equipo
de TI no se muestra tan favorable a estos, la sección siguiente sobre cómo conseguir el éxito del CCoE puede
ayudar a superar los bloqueos culturales.
Consecución del éxito del CCoE

Antes de continuar con este modelo, es importante considerar la tolerancia de la empresa a una mentalidad de
crecimiento y la comodidad del equipo de TI a la hora de delegar responsabilidades centrales. Como se
mencionó anteriormente, el propósito de un CCoE es intercambiar control por agilidad y rapidez.
Este tipo de cambio lleva tiempo, experimentación y negociación. Se producirán obstáculos y retrocesos durante
este proceso de consolidación. Si el equipo persevera y no se desanima durante la fase de experimentación, hay
una alta probabilidad de éxito en la mejora de la agilidad, la velocidad y la confiabilidad. Uno de los factores más
importantes que determinan el éxito o fracaso de un CCoE es el respaldo por parte del equipo directivo y las
principales partes interesadas.
Principales partes interesadas
El equipo de dirección de TI es la primera y más evidente. Los jefes de TI desempeñan un papel importante. No
obstante, durante este proceso se necesita el respaldo del jefe de información y de otros directores ejecutivos de
TI.
Menos evidente es la necesidad para las partes interesadas de la empresa. La agilidad empresarial y el tiempo
de comercialización son motivaciones clave para la formación de un CCoE. Por tanto, las partes interesadas clave
deben tener un interés particular en estas áreas. Entre los ejemplos de partes interesadas de la empresa se
incluyen los responsables de la línea de negocio, directivos financieros, directivos de operaciones y propietarios
de productos empresariales.
Respaldo de las partes interesadas de la empresa
Los esfuerzos del CCoE se pueden acelerar con el respaldo de las partes interesadas de la empresa. El principal
objetivo de los esfuerzos del CCoE se centra en la realización de mejoras a largo plazo en la agilidad y velocidad
empresarial. Definir el impacto de los modelos operativos actuales y el valor de las mejoras es útil como guía y
herramienta de negociación para el CCoE. Se recomienda documentar los siguientes elementos para definir el
respaldo del CCoE:
Establezca el conjunto de resultados y objetivos empresariales que se pretende conseguir como resultado de
la agilidad y velocidad empresarial.
Defina claramente los puntos débiles que generan los procesos de TI actuales (como la velocidad, la agilidad,
la estabilidad y los costos).
Defina claramente el impacto histórico de esos puntos débiles (como, por ejemplo, la pérdida de cuota de
mercado, los logros de la competencia en características y funciones, malas experiencias de los clientes y
aumentos presupuestarios).
Defina las oportunidades de mejora empresarial que están bloqueadas por los actuales puntos débiles y
modelos operativos.
Establezca escalas de tiempo y métricas relacionadas con esas oportunidades.
Estos puntos de datos no son un ataque contra el equipo de TI. En vez de eso, ayudan al CCoE a aprender del
pasado y a establecer una serie de trabajos pendientes y un plan de mejora realistas.
Respaldo e implicación continuos: Los equipos del CCoE pueden generar beneficios rápidos en algunas
áreas. No obstante, los objetivos de nivel superior, como la agilidad empresarial y el tiempo de comercialización,
pueden tardar mucho más. Durante el proceso de consolidación, existe un riesgo elevado de que el CCoE pierda
la motivación o que se le pida que se centre en otros esfuerzos de TI.
Durante los primeros seis a nueve meses de trabajo del CCoE, se recomienda que las partes interesadas de la
empresa dediquen un tiempo para reunirse mensualmente con la dirección de TI y el CCoE. No es necesario que
estas reuniones sean excesivamente formales. Simplemente recordar a los miembros del CCoE y a la dirección la
importancia de este programa puede suponer un impulso para el éxito del CCoE.
Además, se recomienda que las partes interesadas de la empresa permanezcan informadas del progreso y de
los bloqueos que experimente el equipo del CCoE. Muchos de los esfuerzos de este equipo parecerán minucias
técnicas. No obstante, es importante que las partes interesadas de la empresa conozcan el progreso del plan, de
modo que puedan implicarse si el equipo pierde la motivación o se distrae en otras prioridades.
Respaldo de las partes interesadas de TI
Apoyo de la visión: Un trabajo de CCoE satisfactorio requiere una gran cantidad de negociación con los
miembros del equipo de TI existentes. Si se hace bien, todo el equipo de TI contribuye a la solución y se siente
cómodo con el cambio. En caso contrario, puede que algunos miembros del equipo de TI existente quieran
aferrarse a los mecanismos de control por diversas razones. El respaldo de las partes interesadas del
departamento de TI será crucial para lograr el éxito del CCoE si estas situaciones se producen. El estímulo y el
refuerzo de los objetivos generales del CCoE es importante para resolver los bloqueos para lograr una
negociación adecuada. En raras ocasiones, es posible que las partes interesadas de TI tengan incluso que
intervenir para resolver un bloqueo o una votación empatada para mantener el progreso del CCoE.
Mantener el foco de atención: Un CCoE puede suponer un compromiso importante para cualquier equipo
de TI con recursos limitados. Quitar profesionales competentes de los proyectos a corto plazo para centrarse en
objetivos a largo plazo puede provocar dificultades para los miembros del equipo que no forman parte del
CCoE. Es importante que la dirección y las partes interesadas de TI se centren en los objetivos del CCoE. El apoyo
de la dirección y de las partes interesadas de TI es necesario para reducir la prioridad de las interrupciones de
las operaciones diarias en favor de las obligaciones del CCoE.
Crear un espacio reser vado: El equipo del CCoE experimentará nuevos enfoques. Algunos de estos enfoques
no se adaptarán bien a las restricciones técnicas u operativas ya existentes. Existe un riesgo real de que el CCoE
experimente la presión o crítica de otros equipos si se produce un error en los experimentos. Es importante
motivar y proteger al equipo de las consecuencias de las oportunidades de aprendizaje de "error rápido". Es
igualmente importante hacer que el equipo se comprometa con una mentalidad de crecimiento, y asegurarse de
que aprenden de esos experimentos y de que encuentran soluciones mejores.
Pasos siguientes
Un modelo de CCoE requiere funciones de la plataforma de nube y funciones de automatización de la nube. El
siguiente paso consiste en alinear las funciones de la plataforma de nube.
La nube presenta muchos cambios técnicos, así como oportunidades para simplificar las soluciones técnicas. No
obstante, los principios de TI y las necesidades empresariales generales deben seguir siendo los mismos.
Todavía sigue necesitando proteger los datos empresariales confidenciales. Si la plataforma de TI depende de
una red de área local, es bastante probable que necesite definiciones de red en la nube. Los usuarios que
necesitan acceder a las aplicaciones y los datos querrán que sus identidades actuales accedan a los recursos en
la nube pertinentes.
Aunque la nube presenta la oportunidad de aprender nuevas aptitudes, los arquitectos actuales deben poder
aplicar directamente su experiencia y conocimientos. Suele ocuparse de las funciones de la plataforma de nube
un grupo selecto de arquitectos que se centran en el aprendizaje sobre este tema. Después, estos arquitectos
ayudan a otros usuarios a tomar decisiones y a conseguir la aplicación adecuada de los controles en los
entornos en la nube.
Las aptitudes necesarias para proporcionar la funcionalidad completa de la plataforma pueden proceder de:
Operaciones de TI
Gobernanza de TI
Redes
Identidad
Virtualización
Preparación
Azure.
Revise lo siguiente:
Modelos financieros
Ámbito mínimo
Los deberes de la plataforma en la nube se centran en torno a la creación y el soporte de la plataforma en la
nube o las zonas de aterrizaje.
Las siguientes tareas se suelen ejecutar con regularidad:
Identificación y clasificación por orden de prioridad de los cambios necesarios para dar soporte a los trabajos
pendientes de la migración.
Normalmente, la experiencia en la plataforma en la nube procede de un equipo de trabajo. Se espera que los
miembros dediquen gran parte de su labor diaria al trabajo de la plataforma en la nube. Las contribuciones no
se limitan a reuniones y ciclos de comentarios.
Resultados
Creación y mantenimiento de la plataforma en la nube que admita las soluciones.
Definición e implementación de la arquitectura de la plataforma.
Funcionamiento y administración de la plataforma en la nube.
Mejora continua de la plataforma.
Mantenerse al día de las innovaciones en la plataforma de nube.
Incorporación de nuevas funcionalidades de nube para respaldar la creación de valor empresarial.
Sugerir soluciones de autoservicio.
Garantía de que las soluciones cumplan los requisitos de gobernanza y cumplimiento existentes.
Creación y validación de la implementación de la arquitectura de la plataforma.
Revisión de los planes de lanzamiento para conocer el origen de los nuevos requisitos de la plataforma.
Pasos siguientes
A medida que la plataforma de nube está mejor definida, la alineación de las funciones de automatización de la
nube puede acelerar la adopción. También puede ayudar a establecer procedimientos recomendados, así como a
reducir los riesgos técnicos y empresariales.
identifique a las entidades responsables, encargadas, consultadas e informadas (RACI por sus siglas en inglés).
Descargue la plantilla RACI y modifíquela.
Durante los trabajos de adopción de la nube, las funcionalidades de automatización de la nube darán rienda
suelta al potencial de DevOps y al enfoque nativo de la nube. La experiencia en cada una de estas áreas puede
acelerar la adopción y la innovación.
Las aptitudes necesarias para proporcionar funciones de automatización de la nube pueden ser aportadas por
los siguientes expertos:
Ingenieros de DevOps
Desarrolladores con experiencia en infraestructura y DevOps
Ingenieros de TI con experiencia en automatización y DevOps
Es posible que estos expertos en la materia estén ofreciendo funciones en otras áreas, como la adopción de la
nube, la gobernanza de la nube o la plataforma de la nube. Después de demostrar su dominio en la
automatización de cargas de trabajo complejas, se puede contar con ellos para que aporten su experiencia en
este campo.
Preparación
Para admitir a un miembro en este grupo, deben contar con tres características clave:
Experiencia en cualquier plataforma en la nube con un énfasis especial en DevOps y automatización.
Una mentalidad enfocada hacia el crecimiento o versatilidad para cambiar la forma en que la TI funciona hoy
en día.
Deseo de acelerar el cambio empresarial y eliminar los obstáculos tradicionales de la TI.
Ámbito mínimo
El equipo de automatización de la nube es el propietario del catálogo de soluciones; este catálogo y su
promoción constituyen su principal labor. El catálogo consiste en una colección de soluciones precompiladas o
plantillas de automatización. Estas soluciones se pueden implementar rápidamente en varias plataformas, según
sea preciso para dar soporte a las cargas de trabajo necesarias. Las soluciones son bloques de creación que
aceleran la adopción de la nube y reducen el tiempo de comercialización durante las labores de migración o
innovación.
Entre los ejemplos de soluciones en el catálogo se incluyen:
Un script para implementar una aplicación en contenedores.
Una plantilla de Resource Manager para implementar un clúster de alta disponibilidad de SQL AlwaysOn.
Código de ejemplo para crear una canalización de implementación mediante Azure DevOps.
Una instancia de Azure DevTest Labs del ERP corporativo con fines de desarrollo.
Implementación automatizada de un entorno de autoservicio solicitado habitualmente por los usuarios
empresariales.
Las soluciones del catálogo no son canalizaciones de implementación para una carga de trabajo, sino que puede
usar los scripts de automatización del catálogo para crear rápidamente una canalización de implementación.
También puede usar una solución del catálogo para aprovisionar rápidamente componentes de plataforma que
admitan tareas de carga de trabajo como la implementación automatizada, la implementación manual o la
migración.
Tareas estratégicas
Racionalización del patrimonio digital:
Identificar oportunidades para acelerar la adopción de la nube, reducir el esfuerzo a través de la
automatización y mejorar la seguridad, la estabilidad y la coherencia.
Asignar prioridad a un trabajo pendiente de soluciones para el catálogo de soluciones que ofrezca el
máximo valor dadas otras entradas estratégicas.
Revisar los planes de lanzamiento de orígenes de nuevas oportunidades de automatización.
La automatización de la nube es un equipo de trabajo. Se espera que los miembros dediquen gran parte de su
labor diaria al trabajo de automatización de la nube. Las contribuciones no se limitan a reuniones y ciclos de
comentarios.
El equipo de automatización de la nube debe combinar las actividades con otras áreas de funcionalidad. Esto
puede dar lugar a un exceso de reuniones. Para asegurarse de que el equipo de automatización de la nube
dispone de tiempo suficiente para administrar el catálogo de soluciones, se debe revisar la cadencia de las
reuniones, con el fin de maximizar la colaboración y minimizar las interrupciones en las actividades de
desarrollo.
Resultados
Mantener o desarrollar soluciones basadas en el trabajo pendiente prioritario.
Garantizar que las soluciones se adaptan a los requisitos de la plataforma.
Garantizar que las soluciones se aplican de forma coherente y cumplen los requisitos de cumplimiento y
gobernanza existentes.
Crear y validar soluciones en el catálogo.
Pasos siguientes
A medida que se alinean las funciones de nube esenciales, los equipos colectivos pueden ayudar a desarrollar
los conocimientos técnicos necesarios.
Descripción de las funciones de datos en la nube
Hay diversos tipos de audiencias implicadas en una conversación analítica, entre los que cabe destacar el típico
vendedor, el arquitecto de bases de datos y el equipo de infraestructura. Además, en las soluciones de análisis
participan "influencers", asesores y responsables de toma de decisiones que pertenecen a roles de arquitectura
empresarial, ciencia de datos, analistas empresariales y directores ejecutivos.
Azure Synapse Analytics permite a toda la empresa, desde el responsable de TI hasta el analista de negocios,
colaborar en las soluciones de análisis y comprender las funciones de datos en la nube. En las siguientes
secciones se describen los roles con más detalle.
Administradores y arquitectos de bases de datos

Los administradores y arquitectos de bases de datos son responsables de la integración y el enrutamiento de los
orígenes de datos en un repositorio centralizado. Estos expertos también controlan la administración y el
rendimiento necesarios para el sistema, así como la accesibilidad y la eficiencia del modelado de consultas y
análisis con respecto a los datos.
Con Azure Synapse Analytics, los administradores de bases de datos pueden satisfacer sus responsabilidades de
ampliación de los almacenamientos y los lagos de datos. Se pueden usar lenguajes y herramientas conocidos,
como T-SQL, para ejecutar tantas cargas de trabajo como deseen. Se pueden asignar recursos para escalar
cargas de trabajo críticas según la importancia de la carga de trabajo inteligente, el aislamiento de esta y las
funcionalidades de simultaneidad mejoradas.
Equipos de infraestructura
Estos equipos trabajan con el aprovisionamiento y la arquitectura de los recursos de proceso subyacentes
necesarios para sistemas de análisis de gran tamaño. En muchos casos, administran las transiciones entre los
sistemas basados en centros de datos y basados en la nube, y las necesidades actuales de interoperabilidad
entre ambos. La recuperación ante desastres, la continuidad empresarial y la alta disponibilidad son
preocupaciones habituales.
Con Azure Synapse Analytics, los profesionales de TI pueden proteger y administrar los datos de su
organización de forma más eficaz. Son capaces de habilitar el procesamiento de macrodatos tanto con el
proceso a petición como con el aprovisionado. Gracias a la estrecha integración con Azure Active Directory, el
servicio contribuye a proteger el acceso a las configuraciones híbridas y en la nube. Los profesionales de TI
pueden aplicar los requisitos de privacidad mediante el enmascaramiento de datos, junto con la seguridad en
las filas y las columnas.
Arquitectos empresariales e ingenieros de datos

Estos equipos son responsables de reunir soluciones complejas con componentes que abarcan la integración a
través de un amplio abanico de soluciones y herramientas de datos. Se incluyen los siguientes:
Datos estructurados y no estructurados
Transformación
Almacenamiento y recuperación
Modelado analítico
Middleware basado en mensajes
Data marts
Redundancia geográfica y coherencia de los datos
Paneles e informes
Los ingenieros de datos y los arquitectos empresariales se preocupan por la creación de arquitecturas eficaces
que funcionen de manera integrada. Estas arquitecturas conservan el rendimiento, la disponibilidad, la facilidad
de administración, la flexibilidad, la extensibilidad y la capacidad de acción.
Los ingenieros de datos pueden usar Azure Synapse Analytics para simplificar los pasos para tratar varios tipos
de datos de diversos orígenes, entre los que se incluyen los datos de streaming, transaccionales y empresariales.
Pueden usar un entorno visual sin código para conectarse a los orígenes de datos e ingerir, transformar y
colocar los datos en el lago de datos.
Científicos de datos
Los científicos de datos saben cómo crear modelos avanzados para grandes volúmenes de datos críticos, pero a
menudo dispares. Su trabajo implica trasladar las necesidades de la empresa a los requisitos tecnológicos para
la normalización y la transformación de datos. Crean modelos estadísticos y otros modelos analíticos, y
garantizan que los equipos de línea de negocio puedan obtener el análisis que necesitan para su empresa.
Con Azure Synapse Analytics, los científicos de datos pueden crear pruebas de concepto en cuestión de minutos
y crear o ajustar fácilmente las soluciones globales. Pueden aprovisionar los recursos según sea necesario o
consultar los recursos existentes a petición a través de grandes cantidades de datos. Pueden hacer su trabajo en
diversos lenguajes, como T-SQL, R, Python, Scala, .NET y Spark SQL.
Analistas de negocios
Estos equipos crean y usan paneles, informes y otras formas de visualización de datos para obtener información
detallada rápida, necesaria para las operaciones. A menudo, cada departamento de línea de negocio tendrá
analistas de negocios dedicados que recopilen y empaqueten la información y el análisis de aplicaciones
especializadas. Por ejemplo, de tarjetas de crédito, banca al por menor, banca comercial, tesorería, marketing y
otras organizaciones.
Con Azure Synapse Analytics, los analistas de negocios pueden acceder de forma segura a los conjuntos de
datos y usar Power BI para crear paneles. También pueden compartir datos de forma segura dentro y fuera de
su organización a través de Azure Data Share.
Ejecutivos
Los ejecutivos son responsables de trazar las estrategias y garantizar que las iniciativas estratégicas se
implementen de forma eficaz en los departamentos de línea de negocio y de TI. Las soluciones deben ser
rentables, evitar la interrupción del negocio, permitir una extensibilidad sencilla a medida que los requisitos
cambien y crezcan, y generar resultados para la empresa.
Funciones de seguridad en la nube
En este artículo se proporciona un resumen de las funciones organizativas necesarias para administrar el riesgo
de seguridad de la información en una empresa. Estas funciones organizativas forman colectivamente la parte
humana de un sistema de ciberseguridad general. Cada función puede ser realizada por una o varias personas, y
cada persona puede realizar una o varias funciones, dependiendo de varios factores, como la referencia cultural,
el presupuesto y los recursos disponibles.
El diagrama y la documentación siguientes representan una vista idónea de las funciones de un equipo de
seguridad empresarial. El diagrama representa una visión aspiracional para organizaciones más pequeñas o
equipos de seguridad más pequeños que podrían no tener recursos significativos ni responsabilidades formales
definidas en torno a todas estas funciones.
La seguridad es un depor te de equipo: es fundamental que las personas del equipo de seguridad se vean
entre sí como parte de un equipo de seguridad global, parte de toda la organización y parte de una comunidad
de seguridad más grande que se defiende contra los mismos adversarios. Esta vista holística permite al equipo
trabajar bien en términos generales. Esto es especialmente importante, ya que los equipos trabajan en lagunas y
superposiciones no planificadas que se detectan durante la evolución de los roles y las responsabilidades.
Funciones de seguridad
En cada uno de los artículos siguientes se proporciona información sobre cada función. Cada artículo
proporciona un resumen de los objetivos, el modo en que la función puede evolucionar debido a los cambios en
el entorno de amenazas o la tecnología de la nube, y las relaciones y dependencias que son fundamentales para
su éxito.
Directivas y estándares
Operaciones de seguridad
Administración del cumplimiento de la seguridad
Seguridad de las aplicaciones y DevSecOps
Seguridad de datos
Infraestructura y seguridad de los puntos de conexión
Administración de identidades y claves
Administración de la posición
Preparación de incidentes
Función de los estándares y la directiva de
seguridad en la nube
Los equipos de estándares y la directiva de seguridad crean, aprueban y publican los estándares y la directiva de
seguridad para guiar las decisiones de seguridad dentro de la organización.
Las directivas y los estándares deben:
Reflejar la estrategia de seguridad de las organizaciones de una manera suficientemente detallada para guiar
las decisiones de la organización por parte de varios equipos
Habilitar la productividad en toda la organización reduciendo al mismo tiempo el riesgo para el negocio y la
misión de las organizaciones
La directiva de seguridad debe reflejar los objetivos sostenibles a largo plazo que se alinean con la estrategia
de seguridad y la tolerancia a riesgos de las organizaciones. La directiva siempre debe abordar:
Los requisitos de cumplimiento normativo y el estado de cumplimiento actual (requisitos cumplidos, riesgos
aceptados, etc.)
La valoración de la arquitectura del estado actual y lo que es técnicamente posible de diseñar, implementar y
aplicar
La referencia cultural y las preferencias de la organización
Los procedimientos recomendados del sector
La responsabilidad del riesgo de seguridad asignado a las partes interesadas empresariales adecuadas que
son responsables de otros riesgos y resultados empresariales.
Los estándares de seguridad definen los procesos y las reglas para admitir la ejecución de la directiva de
seguridad.
Modernización
Si bien la directiva debe permanecer estática, los estándares deben ser dinámicos y revisarse continuamente
para mantenerse al día de los cambios en la tecnología de la nube, el entorno de amenazas y el panorama
empresarial de la competencia.
Debido a esta alta tasa de cambio, debe estar muy atento a la cantidad de excepciones que se realizan, ya que
esto puede indicar una necesidad de ajustar los estándares (o la directiva).
Los estándares de seguridad deben incluir instrucciones específicas para la adopción de la nube, como:
Uso seguro de las plataformas en la nube para el hospedaje de cargas de trabajo
Uso seguro del modelo DevOps e inclusión de aplicaciones, API y servicios en la nube en desarrollo
Uso de controles de perímetro de identidad para complementar o reemplazar los controles de perímetro de
red
Definición de la estrategia de segmentación antes de mover las cargas de trabajo a la plataforma IaaS
Etiquetado y clasificación de la confidencialidad de los recursos
Definición del proceso para evaluar los recursos y garantizar que estén configurados y protegidos
correctamente
Composición del equipo y relaciones clave
La directiva de seguridad y los estándares en la nube se proporcionan normalmente mediante los siguientes
tipos de roles. La directiva de la organización debe informar a (y ser informada por):
Las arquitecturas de seguridad
Los equipos de administración de riesgos y cumplimiento
Los líderes y representantes de la unidad de negocio
Tecnologías de la información
Equipos de auditoría y legales
La directiva debe refinarse en función de numerosas entradas o requisitos de toda la organización, incluidos,
entre otros, los que se muestran en el diagrama de información general de la seguridad.
Pasos siguientes
Revisión de la función de un centro de operaciones de seguridad en la nube (SOC).
Funciones del centro de operaciones de seguridad
en la nube
El objetivo principal de un centro de operaciones de seguridad en la nube (SOC) es detectar, responder y

recuperarse de ataques activos a los activos empresariales.
A medida que el SOC madura, las operaciones de seguridad deben cumplir estos requisitos:
Responder de forma reactiva a los ataques detectados por las herramientas
Buscar de forma proactiva ataques que han superado detecciones reactivas anteriores
Modernización
La detección y respuesta a las amenazas está actualmente en un importante proceso de modernización en todos
los niveles.
Elevación a la administración de riesgos empresariales: el SOC está creciendo y convirtiéndose en un
componente clave de la administración de riesgo empresariales dentro de la organización.
Métricas y objetivos: el seguimiento de la eficacia del SOC está evolucionando a partir del tiempo de
detección a estos indicadores clave.
Capacidad de respuesta a través del tiempo medio de confirmación (MTTA).
Velocidad de corrección a través del tiempo medio para corregir (MTTR).
Evolución tecnológica: la tecnología SOC está evolucionando a partir del uso exclusivo del análisis estático
de registros en un SIEM para agregar el uso de herramientas especializadas y técnicas de análisis
sofisticadas. Esto proporciona información detallada sobre los activos que proporcionan una experiencia de
investigación y alertas de alta calidad que complementan la visión completa del SIEM. Ambos tipos de
herramientas usan cada vez más la IA y el aprendizaje automático, el análisis de comportamientos y la
inteligencia sobre amenazas integrada para ayudar a detectar y priorizar acciones anómalas que podrían ser
un atacante malintencionado.
Búsqueda de amenazas: los SOC están agregando la búsqueda de amenazas controlada por hipótesis
para identificar de forma proactiva a los atacantes avanzados y eliminar las alertas de las colas de los
analistas que están en primera línea.
Administración de incidentes: la disciplina se está volviendo formalizada para coordinar los elementos
no técnicos de incidentes con los departamentos legales, de comunicaciones y otros equipos. Integración
del contexto interno: para ayudar a priorizar las actividades del SOC, como las puntuaciones de riesgo
relativas de las cuentas de usuario y los dispositivos, la confidencialidad de los datos y las aplicaciones, y los
límites de aislamiento de seguridad clave para defenderse eficazmente.
Normas de estrategia y arquitectura y operaciones de seguridad
Módulo de taller para CISO 4b: estrategia de protección contra amenazas
Serie de blogs del Centro de operaciones de defensa cibernética (CDOC), parte 1, parte 2a, parte 2b, parte 3a
y parte 3b
Guía del NIST para controlar incidentes de seguridad en equipos
Guía del NIST para recuperarse de eventos de ciberseguridad
El centro de operaciones de seguridad en la nube se compone normalmente de los siguientes tipos de roles.
Operaciones de TI (contacto cercano y periódico)
Programa de riesgos de Insider
Recursos legales y humanos
Equipos de comunicaciones
Organización de riesgos (si existe)
Asociaciones, comunidades y proveedores específicos del sector (antes de que se produzca el incidente)
Pasos siguientes
Revise la función de la arquitectura de seguridad.
Funciones de la arquitectura de seguridad en la
nube
La arquitectura de seguridad traduce los objetivos empresariales y de garantía de las organizaciones en

documentación y diagramas para guiar las decisiones de seguridad técnicas.
Modernización
A continuación se mencionan los distintos factores que afectan a la arquitectura de seguridad:
Modelo de compromiso continuo: la publicación continua de actualizaciones de software y las
características en la nube hacen que los modelos de compromiso fijos queden obsoletos. Los arquitectos
deben comprometerse con todos los equipos que trabajan en áreas temáticas técnicas para guiar la toma de
decisiones a lo largo de los ciclos de vida de la capacidad de esos equipos.
Seguridad de la nube: incorpore funcionalidades de seguridad de la nube para reducir el tiempo de
habilitación y los costos de mantenimiento continuos (hardware, software, tiempo y esfuerzo).
Seguridad de la nube: garantice la cobertura de todos los recursos en la nube, incluidas las aplicaciones
de software como servicio (SaaS), las máquinas virtuales de infraestructura como servicio (IaaS) y las
aplicaciones y servicios de plataforma como servicio (PaaS). Esto debe incluir la detección y seguridad de los
servicios autorizados y no autorizados.
Integración de identidades: los arquitectos de seguridad deben garantizar una estrecha alineación con los
equipos de identidades para ayudar a las organizaciones a cumplir un doble objetivo: habilitar la
productividad y proporcionar garantías de seguridad.
Integración del contexto interno en los diseños de seguridad, como el contexto de la administración de
la posición y los incidentes investigados por el centro de operaciones de seguridad (SOC). Esto debe incluir
elementos como las puntuaciones de riesgo relativas de las cuentas de los dispositivos y las cuentas de
usuario, la confidencialidad de los datos y los límites de aislamiento de seguridad clave para defenderse
activamente.

Lo ideal es que la arquitectura de seguridad la proporcione un individuo dedicado o un equipo dedicado, pero
las restricciones de recursos pueden requerir la asignación de esta función a un individuo con otras
responsabilidades.
La arquitectura de seguridad debe tener una amplia gama de relaciones en toda la organización de seguridad,
con las partes interesadas clave en otras organizaciones, y con personas del mismo nivel en organizaciones
externas. Las relaciones clave internas deben incluir:
Arquitectos empresariales y de TI
Administración de la posición de seguridad
Directores de tecnología
Líderes empresariales clave o sus representantes
Personas del mismo nivel del sector y otras personas de la comunidad de seguridad
Los arquitectos de seguridad deben influir activamente en los estándares y directivas de seguridad.
Pasos siguientes
Revise la función de la administración de cumplimiento de seguridad en la nube.
Funciones de administración del cumplimiento de la
El objetivo de la administración del cumplimiento de la seguridad en la nube es velar por que la organización
cumpla los requisitos normativos (y las directivas internas) y realice un seguimiento del estado y lo notifique de
forma eficaz.
Modernización
La nube introduce cambios en el cumplimiento de la seguridad, como los siguientes:
Requisito de validar el estado de cumplimiento del proveedor de nube con sus requisitos normativos.
Esta validación es una responsabilidad compartida. Para obtener más información sobre cómo difieren
estas responsabilidades en los tipos de nube, consulte la adopción del modelo de responsabilidad
compartida
Instrucciones previas a la nube: aunque se han actualizado muchos requisitos normativos para
incorporar la naturaleza dinámica de los servicios en la nube, algunos aún no reflejan estas diferencias.
Las organizaciones deben trabajar con órganos de regulación para actualizar estos requisitos y
prepararse para explicar estas diferencias durante los ejercicios de auditoría.
Vinculación de la conformidad con el riesgo: asegúrese de que las organizaciones están vinculando
las infracciones de cumplimiento y las excepciones a los riesgos organizativos para garantizar el nivel
adecuado de atención y financiación para corregir los problemas.
Seguimiento y generación de informes habilitados por la nube: esta función debe adoptar
activamente la naturaleza definida por software de la nube, ya que ofrece un registro completo, datos de
configuración e información analítica que hacen que la presentación de informes sobre el cumplimiento
sea más eficiente que los enfoques locales tradicionales.
Hay herramientas de cumplimiento basadas en la nube disponibles para facilitar la creación de
informes de cumplimiento normativo, como Microsoft Compliance Manager, que pueden reducir los
costos de sobrecarga de esta función.

La administración del cumplimiento de seguridad en la nube suele interactuar con:
Operaciones de TI
Equipos de administración de riesgos y cumplimiento de la organización
Pasos siguientes
Revise la función de la seguridad de las personas.
Funciones de seguridad de las personas en la nube
La seguridad de las personas protege a la organización del riesgo de errores humanos accidentales y acciones
internas malintencionadas.
Modernización
La modernización de esta función incluye:
Mayor involucración positiva con usuarios que usan ludificación y un refuerzo o educación positivos en
lugar de confiar exclusivamente en enfoques de refuerzo negativos como soluciones tradicionales de
"suplantar identidad y castigar".
Involucración humana de alta calidad: Las comunicaciones y el entrenamiento del reconocimiento de
seguridad deben ser producciones de alta calidad que impulsen la empatía y la involucración emocional para
conectar con el lado humano de los empleados y la misión de las organizaciones.
Expectativas realistas: acepte que los usuarios a veces harán clic en correos electrónicos de suplantación
de identidad y, en su lugar, centre las métricas de éxito en reducir la tasa en vez de esperar detener el 100 %
de los clics.
Cambio de referencia cultural de la organización: el liderazgo de la organización debe impulsar un
cambio de referencia cultural deliberado para que la seguridad sea prioritaria para cada miembro de la
organización.
Mayor atención a riesgos internos para ayudar a las organizaciones a proteger secretos comerciales
valiosos y otros datos frente a casos de uso ilícitos altamente rentables (por ejemplo, ubicaciones de clientes
o registros de comunicaciones).
Detección mejorada de riesgos internos que aprovecha las funcionalidades de la nube para el registro
de actividad, análisis de comportamiento y aprendizaje automático (aprendizaje automático).

La seguridad de las personas normalmente se asocia a los siguientes tipos de roles:
Recursos humanos
Equipo de privacidad
Seguridad de los datos
Equipos de comunicaciones (para el reconocimiento de usuarios)
Operaciones de seguridad (para el riesgo interno)
Seguridad física (riesgo interno)
Pasos siguientes
Revise la función de seguridad de las aplicaciones y DevSecOps.
Funciones de seguridad de las aplicaciones y
DevSecOps
El objetivo de la seguridad de las aplicaciones y DevSecOps es integrar las garantías de seguridad en los
procesos de desarrollo y en las aplicaciones de línea de negocio (LOB) personalizadas.
Modernización
El desarrollo de aplicaciones se reforma rápidamente en varios aspectos simultáneamente, incluido el modelo
de equipo DevOps, la cadencia de publicación rápida de DevOps y la composición técnica de las aplicaciones a
través de servicios en la nube y API. Vea cómo la nube está cambiando las relaciones de seguridad y las
responsabilidades para comprender estos cambios.
Esta modernización de modelos de desarrollo anticuados presenta tanto una oportunidad como un requisito
para modernizar la seguridad de las aplicaciones y los procesos de desarrollo. La fusión de la seguridad en los
procesos de DevOps a menudo se denomina DevSecOps e impulsa cambios que incluyen:
La seguridad está integrada, no la aprobación externa: el rápido ritmo de cambio en el desarrollo de
las aplicaciones hace que los enfoques clásicos independientes de "examinar e informar" se queden
obsoletos. Estos enfoques heredados no pueden mantenerse al día con las versiones sin paralizar el
desarrollo y sin dar lugar a demoras en el tiempo de comercialización, infrautilización del desarrollador y
crecimiento de la acumulación de problemas.
Realice pruebas anticipadas para adoptar la seguridad antes en los procesos de desarrollo de las
aplicaciones, ya que corregirlos con anticipación es más barato, rápido y eficaz. Si espera a que se el
pastel se haya horneado, será más difícil cambiar su forma.
Integración nativa: los procedimientos de seguridad se deben integrar sin problemas para evitar la
fricción negativa en los flujos de trabajo de desarrollo y los procesos de integración continua e
implementación continua (CI/CD). Para más información sobre el enfoque de GitHub, consulte
Protección del software, juntos.
Seguridad de alta calidad: la seguridad debe proporcionar hallazgos de alta calidad e instrucciones
que permitan a los desarrolladores corregir problemas rápidamente y no pierdan tiempo con falsos
positivos.
Referencia cultural convergente: los roles de seguridad, desarrollo y operaciones deben contribuir
con elementos clave en una referencia cultural compartida, valores compartidos y objetivos y
responsabilidades compartidos.
Seguridad ágil: cambie la seguridad de una estrategia del tipo "debe ser perfecto para enviar" a una ágil
que empiece con una seguridad viable mínima para las aplicaciones (y para los procesos para desarrollarlas)
y se vaya mejorando continuamente poco a poco.
Adopte características de seguridad e infraestructura nativas de nube para optimizar los procesos
de desarrollo integrando al mismo tiempo la seguridad.
Administración de riesgos de la cadena de suministro: adopte un enfoque de confianza cero para el
software de código abierto (OSS) y los componentes de terceros que valide la integridad y garantice que las
correcciones de errores y las actualizaciones se aplican a estos componentes.
Aprendizaje continuo: el ritmo de lanzamiento rápido de los servicios para desarrolladores, a veces
denominados servicios de plataforma como servicio (PaaS), y el cambio de composición de aplicaciones
significa que los miembros del equipo de desarrollo, operaciones y seguridad van a aprender
constantemente sobre nuevas tecnologías.
Enfoque mediante programación para la seguridad de la aplicación para garantizar que se produce una
mejora continua del enfoque ágil.
Para más contexto, consulte Ciclo de vida de desarrollo seguro de Microsoft.

Lo ideal es que la seguridad de las aplicaciones y las funciones DevSecOps las realicen desarrolladores y
equipos de operaciones conscientes de la seguridad (con el apoyo de expertos en materia de seguridad).
Esta función suele interactuar con otras funciones y expertos, entre los que se incluyen:
Arquitectura y operaciones de seguridad
Seguridad de la infraestructura
Comunicaciones (entrenamiento y herramientas)
Identidad y claves
Equipos de administración de riesgos y cumplimiento
Pasos siguientes
Revise la función de seguridad de datos.
Función de la seguridad de datos en la nube
El objetivo principal de un equipo de seguridad de datos es proporcionar protecciones de seguridad y controles

de detección para datos empresariales confidenciales en cualquier formato y en cualquier ubicación.
Modernización
Las estrategias de seguridad de datos se modelan principalmente por:
Dispersión de datos: los datos confidenciales se generan y almacenan en una variedad casi ilimitada de
dispositivos y servicios en la nube donde los usuarios colaboran de forma creativa.
Nuevo modelo: la nube permite que los nuevos modelos de "teléfono residencial para la clave"
complementen y reemplacen los modelos clásicos de protección contra pérdida de datos (DLP) que "lo
atrapan al salir por la puerta".
Las regulaciones como el Reglamento General de Protección de Datos (RGPD) requieren que las
organizaciones realicen un seguimiento exhaustivo de los datos privados y del modo en que los usan las
aplicaciones.

La seguridad de los datos suele interactuar con los siguientes roles de la organización:
Equipos de administración de registros
Equipos de directivas y estándares
Equipos de privacidad
Arquitectura y operaciones de TI
Equipos legales
Equipo de riesgo interno
Pasos siguientes
Revise la función de la seguridad de la infraestructura en la nube y los puntos de conexión.
Función de la infraestructura en la nube y la
seguridad de los puntos de conexión
Un equipo de seguridad en la nube que trabaja en la infraestructura y la seguridad de los puntos de conexión
proporciona protección de seguridad, capacidad de detección y controles de respuesta en los componentes de
infraestructura y red que usan los usuarios y las aplicaciones empresariales.
Modernización
Los centros de seguridad definidos por software y otras tecnologías en la nube ayudan a abordar retos de larga
data relacionados con la infraestructura y la seguridad de los puntos de conexión, incluidos los siguientes:
La detección de errores de configuración y de inventario es mucho más confiable en los activos
hospedados en la nube, ya que todos son visibles inmediatamente (si se compara con un centro de datos
físico).
La administración de vulnerabilidades , que se está convirtiendo en una parte esencial de la
administración de la postura de seguridad general.
La incorporación de tecnologías de contenedor cuya administración y protección recaerá en los
equipos de red y de infraestructura a medida que la organización adopte ampliamente esta tecnología.
Consulte Seguridad de los contenedores en Security Center para ver un ejemplo.
La consolidación de agentes de seguridad y la simplificación de herramientas para reducir la
sobrecarga de tareas de mantenimiento y rendimiento que implican las herramientas y los agentes de
seguridad.
La inclusión en listas de aplicaciones permitidas y el filtrado de redes internas es mucho más fácil de
configurar e implementar en servidores hospedados en la nube (mediante conjuntos de reglas generadas
por aprendizaje automático). Consulte Controles de aplicaciones adaptables y Protección de red adaptable en
Azure Security Center para ver ejemplos de Azure.
Las plantillas automatizadas para configurar la infraestructura y la seguridad son mucho más fáciles con
los centros de recursos definidos por software en la nube. Un ejemplo de Azure es Azure Blueprints
El acceso Just-in-Time (JIT) y el acceso suficiente para realizar tareas específicas (JEA) permiten la
aplicación práctica de los principios de privilegios mínimos para acceder con privilegios a los servidores y
puntos de conexión.
La experiencia del usuario se convierte en algo fundamental, ya que los usuarios pueden elegir o comprar
cada vez más sus dispositivos de punto de conexión.
La administración de puntos de conexión unificada permite administrar la postura de seguridad de
todos los dispositivos de punto de conexión, incluidos los PC tradicionales y los dispositivos móviles, así
como proporcionar señales de integridad de dispositivos esenciales para las soluciones de control de acceso
de confianza cero.
Las arquitecturas de seguridad de red y los controles se reducen parcialmente con el cambio a
arquitecturas de aplicaciones en la nube, pero siguen siendo una medida de seguridad fundamental. Para
obtener más información, consulte Independencia y seguridad de la red.

La infraestructura en la nube y la seguridad de los puntos de conexión suelen interactuar con los siguientes
roles:
Centro de operaciones de seguridad (SOC)
Equipo de cumplimiento
Equipo de auditoría
Pasos siguientes
Revise la función de la inteligencia sobre amenazas.
Función de administración de identidades y claves
en la nube
El objetivo principal de un equipo de seguridad que trabaja en la administración de identidades es proporcionar

autenticación y autorización de personas, servicios, dispositivos y aplicaciones. La administración de claves y
certificados proporciona una distribución segura y acceso a material de clave para las operaciones criptográficas
(que suelen admitir resultados similares a la administración de identidades).
Modernización
La modernización de la administración de identidades y claves de datos está formada por:
Las disciplinas de administración de identidades y claves o certificaciones confluyen, ya que proporcionan
garantías de autenticación y autorización para habilitar las comunicaciones seguras.
Los controles de identidad están emergiendo como un perímetro de seguridad principal para las aplicaciones
en la nube.
La autenticación basada en claves para los servicios en la nube se ha reemplazado por la administración de
identidades debido a la dificultad que supone almacenar y proporcionar acceso de forma segura a esas
claves.
La importancia crítica de llevar a cabo lecciones positivas aprendidas de las arquitecturas de identidad
locales, como la identidad única, el inicio de sesión único (SSO) y la integración de aplicaciones nativas.
La importancia crítica de evitar errores comunes de arquitecturas locales, que a menudo las complican
demasiado, lo que dificulta la compatibilidad y facilita los ataques. Entre ellas se incluyen las siguientes:
Grupos de expansión y unidades organizativas (OU).
Conjunto de expansión de directorios de terceros y sistemas de administración de identidades.
Falta de normalización y propiedad claras de la estrategia de identidad de la aplicación.
Los ataques de robo de credenciales siguen teniendo un gran impacto y continúan siendo una amenaza de
alta probabilidad para mitigar.
Las cuentas de servicio y las cuentas de aplicación siguen siendo un gran desafío, pero resultan más fáciles
de resolver. Los equipos de identidad deben adoptar activamente las funcionalidades de la nube que
empiezan a resolver esto, como las identidades administradas de Azure AD.

Los equipos de administración de identidades y claves necesitan crear relaciones sólidas con los siguientes
roles:
Equipos de desarrollo
Equipos de seguridad de datos
Equipos de privacidad
Equipos legales
Pasos siguientes
Revisión de la función de la infraestructura y la seguridad de los puntos de conexión
Función de la inteligencia sobre amenazas en la
nube
La inteligencia sobre amenazas de seguridad proporciona contexto y conclusiones accionables sobre ataques
activos y amenazas potenciales para habilitar la toma de decisiones por parte de los equipos de seguridad,
equipos técnicos y líderes de la organización.
Modernización
Los equipos de inteligencia sobre amenazas están emergiendo y evolucionando para satisfacer las necesidades
del centro de operaciones de seguridad (SOC) y de otras personas que administran el riesgo de seguridad de la
organización.
Estos equipos deben centrarse en una estrategia que incluya:
Inteligencia sobre amenazas estratégica adaptada al reconocimiento de incrementos de audiencias de
ejecutivos de riesgo de ciberseguridad, requisitos de financiamiento y que admita la toma de decisiones de
riesgo por parte de los responsables de la organización.
Crecimiento incremental de programas para proporcionar logros rápidos con un servicio de soporte
técnico de incidentes directo y evolucionar hacia una plataforma de inteligencia sobre amenazas para realizar
un seguimiento e informar a las partes interesadas.
Inteligencia sobre amenazas táctica y operativa para guiar la toma de decisiones durante la
investigación de incidentes y las detecciones de amenazas.

La inteligencia sobre amenazas de la nube la proporcionan normalmente los siguientes tipos de roles.
Administración de la posición de seguridad
Liderazgo ejecutivo de la organización
Equipos de administración de riesgos
Pasos siguientes
Revise la función de la administración de la posición de seguridad en la nube.
Función de la administración de la posición de
El objetivo principal de un equipo de seguridad en la nube que trabaja en la administración de la posición es

informar continuamente sobre la posición de seguridad de la organización y mejorar dicha posición,
centrándose en interrumpir la rentabilidad de la inversión (ROI) de un posible atacante.
Modernización
La administración de la posición es un conjunto de nuevas funciones que desarrollan muchas ideas imaginadas
o intentadas anteriormente que eran difíciles, imposibles o extremadamente manuales antes de la llegada de la
nube. Se puede realizar un seguimiento de algunos de los elementos de la administración de la posición hasta la
confianza cero, desperimetría, supervisión continua y puntuación manual del riesgo por parte de consultorías
expertas.
La administración de la posición presenta un enfoque estructurado para esto, utilizando lo siguiente:
Control de acceso basado en la confianza cero: considera el nivel de amenaza activo durante las
decisiones de control de acceso.
Puntuación del riesgo en tiempo real: para proporcionar visibilidad sobre los principales riesgos.
Administración de amenazas y vulnerabilidades (TVM) para establecer una vista holística de la
superficie y el riesgo de ataque de la organización e integrarla en las operaciones y la toma de decisiones de
ingeniería.
Detectar riesgos de uso compar tido: para comprender la exposición de los datos de la propiedad
intelectual de la empresa en servicios en la nube autorizados y no autorizados.
Administración de la posición de seguridad en la nube para aprovechar la instrumentación en la nube
para supervisar y priorizar las mejoras de seguridad.
Directiva técnica: aplique barreras para auditar y exigir los estándares y directivas de la organización a los
sistemas técnicos. Para más información, consulte Azure Policy y Azure Blueprints.
Sistemas y arquitecturas de modelado de amenazas , así como aplicaciones específicas.
Disciplina emergente: la administración de la posición de seguridad interrumpirá muchas de las normas de la
organización de seguridad de una manera correcta con estas nuevas funcionalidades y puede desplazar las
responsabilidades entre roles o crear nuevos roles.

La administración de la posición de seguridad es una función en evolución, por lo que puede ser un equipo
dedicado la puedan proporcionar otros equipos.
La administración de la posición de seguridad debe funcionar en estrecha colaboración con los siguientes
equipos:
Equipo información sobre amenazas
Tecnología de la información
Líderes empresariales y expertos en la materia
Equipo de auditoría
Pasos siguientes
Revise la función de la preparación de incidentes de seguridad en la nube.
Función de la preparación de incidentes de
El objetivo principal de un equipo de preparación de incidentes es desarrollar la madurez del proceso y la

memoria muscular para responder a incidentes importantes en toda la organización. Esto incluye ayudar a
preparar la seguridad, el liderazgo ejecutivo y muchos componentes ajenos a la seguridad.
Modernización
Los ejercicios de prácticas se han convertido en herramientas poderosas para garantizar que las partes
interesadas estén informadas y familiarizadas con su papel en un incidente de seguridad importante. Estos
ejercicios deben llegar a los siguientes componentes organizativos:
El liderazgo ejecutivo y la junta directiva para tomar decisiones estratégicas de riesgo y brindar
supervisión.
Las comunicaciones y las relaciones públicas para garantizar que los usuarios internos, los clientes y
otras partes interesadas externas tengan la información pertinente y adecuada.
Las par tes interesadas internas para ofrecer asesoramiento legal y otros consejos empresariales.
La administración de incidentes para coordinar las actividades y las comunicaciones.
Los miembros del equipo técnico para investigar y corregir el incidente.
La integración de la continuidad empresarial con funciones organizativas que poseen planes de
continuidad empresarial, administración de crisis y recuperación ante desastres.
Microsoft ha publicado lecciones extraídas y recomendaciones en la guía de referencia de respuesta a incidentes
(IRRG).

Los asociados críticos para la preparación de incidentes de seguridad son:
Centro de operaciones de seguridad (SOC).
Asesor externo según sea necesario.
Formación en medios y comunicación.
Asociados externos y órganos gubernamentales, si procede.
Estructuras de equipo maduras
En cada esfuerzo de adopción de la nube hay alguien encargado de proporcionar las funciones de la nube. Estas
asignaciones y estructuras de equipo se pueden desarrollar de forma orgánica o diseñarse de manera
intencionada para ajustarse a una estructura de equipo definida.
A medida que aumentan las necesidades de adopción, lo mismo ocurre con la necesidad de equilibrio y
estructura. Vea este vídeo para obtener una introducción sobre las estructuras de equipos comunes en varias
fases de la madurez de la organización.
En el gráfico y la lista siguientes se indican esas estructuras en función de fases de madurez típicas. Use estos
ejemplos para encontrar la estructura organizativa que mejor se ajuste a sus necesidades operativas.
Las estructuras organizativas tienden a avanzar según el modelo de madurez común descrito aquí:
1. Equipo de adopción de la nube solo
2. Procedimiento recomendado de producto viable mínimo
3. Equipo de TI central
4. Alineación estratégica
5. Alineación operativa
6. Centro de excelencia de la nube (CCoE)
La mayoría de las empresas comienzan con poco más que un equipo de adopción de la nube, pero se
recomienda establecer una estructura organizativa que se parezca más a la estructura del procedimiento
recomendado de MVP.
Equipo de adopción de la nube solo

El núcleo de todos los esfuerzos de adopción de la nube es el equipo de adopción de la nube. Este equipo
impulsa los cambios técnicos que permiten la adopción. En función de los objetivos del trabajo de adopción,
este equipo puede estar compuesto por una gama diversa de miembros que se ocupan de un amplio conjunto
de tareas técnicas y comerciales.
En los esfuerzos de adopción de pequeña escala o de fase temprana, este equipo podría constar incluso de una
sola persona. En esfuerzos de mayor escala o de fase avanzada, es habitual tener varios equipos de adopción de
la nube, cada uno con aproximadamente seis ingenieros. Independientemente del tamaño o las tareas, el
aspecto común de cualquier equipo de adopción de la nube es que proporciona los medios para incorporar
soluciones a la nube. En algunas organizaciones, esta podría ser una estructura organizativa suficiente. El
artículo Funcionalidades de adopción en la nube proporciona más información sobre la estructura, la
composición y la función del equipo de adopción de la nube.
WARNING
Trabajar solo con un equipo de adopción de la nube (o varios equipos de adopción de la nube) se considera un antipatrón
y debe evitarse. Como mínimo, considere el procedimiento recomendado de MVP.
Procedimiento recomendado: Producto mínimo viable (MVP)
Se recomienda contar con dos equipos para crear equilibrio entre los esfuerzos de adopción de la nube. Estos
dos equipos son responsables de diversas funciones a lo largo del trabajo de adopción.
Equipo de adopción de la nube: responsable de las soluciones técnicas, la alineación del negocio, la
administración de proyectos y el funcionamiento de las soluciones adoptadas.
Equipo de gobernanza de la nube: para equilibrar el equipo de adopción de la nube, un equipo de
gobernanza de la nube se dedica a garantizar la excelencia en las soluciones adoptadas. El equipo de
gobernanza de la nube es responsable de la madurez de la plataforma, las operaciones de esta, la
gobernanza y la automatización.
Este enfoque probado se considera un producto viable mínimo porque podría no ser sostenible. Cada equipo se
ocupa de muchas tareas, como se explica en los gráficos RACI (comprometido, responsable, consultado e
informado).
En las secciones siguientes se describe una estructura organizativa probada y dotada del personal necesario
junto con enfoques para alinear la estructura adecuada con la organización.
Equipo de TI centralizado
A medida que la adopción avanza, el equipo de gobernanza de la nube podría tener problemas para seguir el
ritmo del flujo de innovación de los distintos equipos de adopción de la nube. Esto es especialmente cierto en
entornos que tienen requisitos intensivos de cumplimiento, operaciones o seguridad. En esta fase, es habitual
que las empresas pasen las responsabilidades de la nube a un equipo de TI central existente. Si ese equipo
puede volver a evaluar las herramientas, los procesos y las personas para facilitar una mejor adopción de la
nube a escala, la incorporación del equipo de TI central puede agregar un valor considerable. La incorporación
de expertos en la materia de operaciones, automatización, seguridad y administración para modernizar el
equipo de TI central puede dar lugar a innovaciones operativas eficaces.
Desafortunadamente, la fase del equipo de TI central puede ser una de las fases con más riesgo de madurez de
la organización. El equipo de TI central debe sentarse a la mesa con una profunda mentalidad de crecimiento. Si
el equipo ve la nube como una oportunidad de crecer y adaptarse, puede proporcionar un magnífico valor a lo
largo del proceso. Sin embargo, si el equipo de TI central considera la adopción de la nube fundamentalmente
como una amenaza para su modelo existente, se convierte en un obstáculo para los equipos de adopción de la
nube y los objetivos empresariales que persiguen. Algunos equipos de TI central han dedicado meses o incluso
años a intentar forzar la alineación de la nube con los enfoques locales, con resultados negativos únicamente. La
nube no exige que todo cambie en el equipo de TI central, pero requiere cambios importantes. Si la resistencia a
los cambios es generalizada en el equipo de TI central, esta fase de madurez puede convertirse rápidamente en
un antipatrón cultural.
Los planes de adopción de la nube muy centrados en soluciones de plataforma como servicio (PaaS), DevOps u
otras que requieren menos soporte de operaciones es menos probable que noten valor durante esta fase de
madurez. Por el contrario, estos tipos de soluciones son los más susceptibles de resultar entorpecidos o
bloqueados por intentos de centralizar la TI. Es más probable que un nivel superior de madurez, como un centro
de excelencia de la nube (CCoE), genere resultados positivos para esos tipos de esfuerzos de transformación.
Para comprender las diferencias entre la TI centralizada en la nube y un CCoE, consulte Centro de excelencia en
la nube.
Alineación estratégica
A medida que crece la inversión en la adopción de la nube y se obtienen valores empresariales, las partes
interesadas del negocio suelen implicarse más. Un equipo de estrategia de la nube definido, como se muestra
en la siguiente imagen, alinea esas partes interesadas del negocio a fin de maximizar el valor obtenido por las
inversiones en la adopción de la nube.
Si la madurez se produce de manera orgánica, como resultado de esfuerzos de adopción de la nube dirigidos
por TI, la alineación estratégica suele ir precedida por un equipo de gobernanza o de TI central. Si los esfuerzos
de adopción de la nube son dirigidos por el negocio, el enfoque en el modelo operativo y la organización tiende
a producirse con anterioridad. Siempre que sea posible, se deben definir los resultados empresariales y el
equipo de estrategia de la nube en una fase temprana del proceso.
La obtención de valor empresarial a partir de los esfuerzos de adopción de la nube requiere operaciones
estables. Las operaciones en la nube podrían requerir nuevas herramientas, procesos o aptitudes. Si se
requieren operaciones de TI estables para lograr resultados empresariales, es importante agregar un equipo de
operaciones en la nube definido, como se muestra aquí.
Los roles de operaciones de TI existentes pueden realizar las operaciones en la nube. Pero no es raro que las
operaciones en la nube se deleguen en otras partes ajenas a las operaciones de TI. Los proveedores de servicios
administrados, los equipos de DevOps y la TI de unidad de negocio suelen asumir las responsabilidades
asociadas con las operaciones en la nube, con soporte y protección de las operaciones de TI. Esto es cada vez
más común en los esfuerzos de adopción de la nube muy centrados en implementaciones de DevOps o PaaS.
Centro de excelencia de la nube

En el estado superior de madurez, un centro de excelencia en la nube alinea los equipos en torno a un modelo
operativo moderno que da prioridad a la nube. Este enfoque proporciona funciones de TI centralizada como
gobernanza, seguridad, plataforma y automatización.
La diferencia principal entre esta estructura y la estructura del equipo de TI central anterior es que se centra en
el autoservicio y la democratización. Los equipos de esta estructura se organizan con la intención de delegar el
control tanto como sea posible. La alineación de los procedimientos de gobernanza y cumplimiento con las
soluciones nativas de la nube crea mecanismos de salvaguarda y protección. A diferencia del modelo de equipo
de TI central, el enfoque nativo en la nube logra la máxima innovación y reduce a un mínimo la sobrecarga
operativa. Para que se adopte este modelo, se necesita acuerdo mutuo entre la dirección de negocio y TI para
modernizar los procesos de TI. No es probable que este modelo se desarrolle de forma orgánica y suele requerir
soporte ejecutivo.
Pasos siguientes
Después de alinear con una determinada fase de madurez de la estructura organizativa, puede usar gráficos
RACI para alinear la responsabilidad y el compromiso en cada equipo.
Alineación de la matriz RACI
Alineación de responsabilidades entre los equipos
Aprenda a coordinar las responsabilidades de los equipos mediante el desarrollo de una matriz entre equipos
que identifique a las entidades responsables, encargadas, consultadas e informadas (RACI por sus siglas en
inglés) . En este artículo se proporciona una matriz RACI de ejemplo para las estructuras organizativas que se
describen en Establecimiento de estructuras de equipo:
Procedimiento recomendado de producto viable mínimo
Equipo de TI central
Centro de excelencia de la nube (CCoE)
descargue y modifique la plantilla de RACI.
En los ejemplos de este artículo se especifican estos componentes de RACI:
El equipo encargado de una función.
Los equipos responsables de los resultados.
Los equipos que deben consultarse durante el planeamiento.
Los equipos a los que se debe informar una vez finalizado el trabajo.
La última fila de cada tabla (excepto la primera) contiene un vínculo a la funcionalidad de la nube más adecuada
para más información.

O P ERA C I A UTO M A
EN T REGA A L IN EA C I A DM IN IS O P ERA C I M A DURE O N ES DE T IZ A C IÓ
DE ÓN T RA C IÓ N O N ES DE Z DE L A LA N DE L A
SO L UC IO EM P RESA DE SO L UC IO GO B ERN A P L ATA F O P L ATA F O P L ATA F O
T EA M N ES RIA L C A M B IO S N ES NZA RM A RM A RM A
Equipo Encargad Encargad Encargad Encargad Encargad Encargad Encargad Encargad

de o o o o o o o o
adopción
de la
nube
Procedimiento recomendado: Producto mínimo viable (MVP)

Equipo Encargad Encargad Encargad Encargad Consulta Consulta Consulta Informad

de o o o o do do do o
adopción
de la
nube
Equipo Consulta Informad Informad Informad Encargad Encargad Encargad Encargad

de do o o o o o o o
gobernan
za de la
nube
Funcional Adopción Estrategia Estrategia Operacio CCoE y la CCoE - CCoE y CCoE y

idad en la de la de la de la nes de la gobernan plataform plataform automatiz
nube nube nube nube nube za de la a de nube a de nube ación de
alineada nube la nube
Equipo de TI centralizado
Equipo Encargad Encargad Responsa Responsa Informad Informad Informad Informad

de o o ble ble o o o o
adopción
de la
nube
Equipo Consulta Informad Informad Informad Encargad Consulta Responsa Informad

de do o o o o do ble o
gobernan
za de la
nube
Equipo Consulta Informad Encargad Encargad Responsa Encargad Encargad Encargad

de TI do o o o ble o o o
centraliza
do
Funcional Adopción Estrategia Estrategia Operacio Gobernan Equipo de Equipo de Equipo de

idad en la de la de la de la nes de la za de la TI central TI central TI central
nube nube nube nube nube nube
alineada
Equipo Consulta Encargad Encargad Consulta Consulta Informad Informad Informad

de do o o do do o o o
estrategia
de la
nube
Equipo Encargad Consulta Responsa Encargad Informad Informad Informad Informad

de o do ble o o o o o
adopción
de la
nube
RACI del Consulta Informad Informad Informad Encargad Encargad Encargad Encargad
modelo do o o o o o o o
de CCoE
Funcional Adopción Estrategia Estrategia Operacio CCoE y la CCoE y CCoE y CCoE y


estrategia
de la
nube
Equipo Encargad Consulta Responsa Consulta Informad Informad Informad Informad

de o do ble do o o o o
adopción
de la
nube
Equipo Consulta Consulta Responsa Encargad Consulta Informad Encargad Consulta

de do do ble o do o o do
operacion
es en la
nube
RACI del Consulta Informad Informad Informad Encargad Encargad Responsa Encargad
modelo do o o o o o ble o
de CCoE

Centro de excelencia de la nube (CCoE)


estrategia
de la
nube
Equipo Encargad Consulta Responsa Consulta Informad Informad Informad Informad

de o do ble do o o o o
adopción
de la
nube
Equipo Consulta Consulta Responsa Encargad Consulta Informad Encargad Consulta

de do do ble o do o o do
operacion
es en la
nube
Equipo Consulta Informad Informad Consulta Encargad Consulta Responsa Informad

de do o o do o do ble o
gobernan
za de la
nube
Equipo Consulta Informad Informad Consulta Consulta Encargad Responsa Responsa

de do o o do do o ble ble
plataform
a de la
nube
Equipo Consulta Informad Informad Informad Consulta Responsa Responsa Encargad

de do o o o do ble ble o
automati
zación de
la nube

Pasos siguientes
descargue y modifique la plantilla de RACI. Copie y modifique el ejemplo que se adapte mejor de las matrices de
RACI de este artículo.
Descarga de la plantilla de RACI
Desarrollo de aptitudes técnicas
La preparación (técnica) de la organización y el entorno puede requerir nuevas aptitudes para los colaboradores
técnicos y no técnicos. La siguiente información puede ayudar a su organización a desarrollar las aptitudes
necesarias.
Preparación de la organización
En función de las motivaciones y los resultados empresariales asociados al trabajo de adopción de la nube, es
posible que los responsables necesiten establecer nuevas estructuras organizativas o equipos virtuales para
facilitar diversas funciones. Los siguientes artículos pueden ayudar a su organización a desarrollar las aptitudes
necesarias para estructurar los equipos de modo que alcancen los resultados deseados:
Vinculación de la organización: descubra enfoques para establecer las estructuras organizativas adecuadas.
Ejercicios de alineación de la organización: obtenga información general sobre la alineación y las estructuras
de equipo para ayudar a cumplir objetivos específicos.
Establecimiento de equipos: aprenda cómo establecer los equipos de la organización responsables de la
entrega de funcionalidad de la nube.
Desglose en silos y feudos: información sobre dos antipatrones de organización habituales y sobre formas
de guiar al equipo hacia la colaboración productiva.
Rutas de aprendizaje de la preparación (técnica) del entorno

Durante la fase de preparación, el personal técnico tiene que crear una zona de aterrizaje de la migración para
hospedar, operar y gobernar las cargas de trabajo que migran a la nube. Use las siguientes rutas para acelerar el
desarrollo de las aptitudes necesarias:
Creación de una cuenta de Azure: El primer paso para usar Azure es crear una cuenta. La cuenta contiene los
servicios de Azure que aprovisiona y controla su configuración personal, como la identidad, la facturación y
las preferencias.
Introducción a Azure: comience a usar Azure. Cree y configure su primera máquina virtual en la nube.
Introducción a la seguridad en Azure: conozca los conceptos básicos para proteger la infraestructura y los
datos en la nube. Conozca cuáles son sus responsabilidades y de cuáles se encarga Azure.
Administración de recursos en Azure: aprenda a trabajar con la CLI de Azure y el portal web para crear,
administrar y controlar los recursos basados en la nube.
Creación de una máquina virtual: use Azure Portal para crear una máquina virtual.
Opciones de proceso de Azure: Revise los servicios de proceso de Azure.
Proteja los recursos con RBAC de Azure: use el control de acceso basado en rol de Azure (RBAC de Azure)
para proteger los recursos.
Opciones de almacenamiento de Azure: conozca las ventajas del almacenamiento de datos de Azure.
Durante la fase de preparación, los arquitectos tienen que diseñar soluciones que abarquen todos los entornos
de Azure. Los siguientes recursos pueden prepararles para estas tareas:
Azure.

La siguiente información describe recursos para acceder a más aprendizaje.
Microsoft Learn
Microsoft Learn es un enfoque nuevo al aprendizaje. La preparación para las nuevas responsabilidades que
acompañan a la adopción de la nube no es fácil. Microsoft Learn proporciona un enfoque gratificante para el
aprendizaje práctico que le ayuda a lograr sus objetivos con más rapidez. Gane puntos, alcance nuevos niveles y
consiga más.
Estos son algunos ejemplos de rutas de aprendizaje específicas de roles en Microsoft Learn:
Los usuarios empresariales pueden enfrentarse a una ardua curva de aprendizaje cuando ayudan a
planear, probar y adoptar tecnología basada en la nube. Los módulos de Microsoft Learn se centran en la
adopción de modelos y herramientas de la nube para administrar mejor la empresa a través de servicios
basados en la nube.
Los arquitectos de soluciones pueden acceder a cientos de módulos y rutas de aprendizaje. Los temas
disponibles van desde los servicios de infraestructura básica hasta la transformación avanzada de datos.
Los administradores tienen acceso a los módulos que se centran en los aspectos básicos de Azure, la
configuración de contenedores e incluso la administración avanzada en la nube.
Los desarrolladores pueden usar los recursos de Microsoft Learn para ayudar durante las actividades de
diseño, gobernanza y modernización.
Más información
Para conocer más rutas de aprendizaje, eche un vistazo al catálogo de Microsoft Learn. Use el filtro de roles para
Crear una organización con control de costos
Como se describió en Motivaciones: ¿por qué se realiza el traslado a la nube?, hay muchas razones de peso para
la adopción de la nube por parte de una empresa. Si la reducción de costos es uno de los principales factores, es
importante crear una organización con control de costos.
El control de costos no se garantiza en un solo día. Al igual que otros temas de adopción de la nube, es una
actividad iterativa. En el diagrama siguiente se describe este proceso, centrado en tres actividades
interdependientes: visibilidad, responsabilidad y optimización. Estos procesos se aplican en macro y
microniveles, que se describen en detalle en este artículo.
Figura 1: Esquema de una organización con control de los costos.
Procesos generales de control de costos

Visibilidad : para que una organización pueda controlar los costos, necesita verlos. La visibilidad en una
organización con control de costos requiere informes coherentes para los equipos que adoptan la nube,
los equipos de finanzas que administran los presupuestos y los equipos de administración responsables
de los costos. Esta visibilidad se logra estableciendo:
El ámbito de informes adecuado.
La organización de recursos adecuada (grupos de administración, grupos de recursos, suscripciones).
Estrategias claras de etiquetado.
Controles de acceso adecuados (RBAC de Azure).
Responsabilidad : la responsabilidad es tan importante como la visibilidad. La responsabilidad comienza
con unos presupuestos claros de los esfuerzos de adopción. Los presupuestos deben estar bien
establecidos, comunicarse claramente y basarse en expectativas realistas. La responsabilidad requiere un
proceso iterativo y una mentalidad de crecimiento para situarse en el nivel adecuado.
Optimización : la optimización es la acción que crea las reducciones de costos. Durante la optimización,
las asignaciones de recursos se modifican para reducir el costo de admitir diversas cargas de trabajo. Este
proceso precisa iteración y experimentación. Cada reducción de costo reduce el rendimiento. Para
encontrar el equilibrio adecuado entre el control de costos y las expectativas de rendimiento del usuario
final se necesita información de varias partes.
En las secciones siguientes se describen los roles de los distintos equipos en el desarrollo de una organización
que se preocupa por los costos.

El desarrollo del control de costos en los trabajos de adopción de la nube comienza en el nivel de liderazgo. Para
que sea efectivo a largo plazo, el equipo de estrategia de la nube debe incluir un miembro del equipo de
finanzas. Si la estructura financiera incluye administradores empresariales responsables de los costos de la
solución, también se les debe invitar a unirse al equipo. Además de las actividades básicas que normalmente se
asignan al equipo de estrategia de la nube, todos sus miembros deben ser responsables de los siguientes
aspectos:
Visibilidad : el equipo de estrategia de la nube y el equipo de gobernanza de la nube necesitan conocer
los costos reales de los trabajos de adopción de la nube. Este equipo tiene una visión de nivel ejecutivo,
por lo que debe tener acceso a varios ámbitos de costo para analizar las decisiones de gasto.
Normalmente, un ejecutivo necesita ver el total de los costos en todo el "gasto" de la nube. Como
miembro activo del equipo de estrategia de la nube, también debe poder ver los costos por unidad de
negocio o por unidad de facturación, para validar la visualización de costos, los contracargos u otros
modelos de contabilidad de la nube.
Responsabilidad : los presupuestos se deben establecer entre los equipos de estrategia de la nube,
gobernanza de la nube y adopción de la nube, en función de las actividades de adopción esperadas.
Cuando se producen desviaciones respecto al presupuesto, los equipos de estrategia de la nube y
gobernanza de la nube deben colaborar para determinar rápidamente el mejor curso de acción para
corregirlas.
Optimización : durante los trabajos de optimización, el equipo de estrategia de la nube puede
representar la inversión y el valor devuelto de cargas de trabajo específicas. Si una carga de trabajo tiene
un valor estratégico o un impacto financiero en el negocio, los trabajos de optimización de costos deben
supervisarse muy de cerca. Si no hay ningún impacto estratégico en la organización y no hay ningún
costo inherente para el bajo rendimiento de una carga de trabajo, el equipo de estrategia de la nube
puede aprobar la sobreoptimización. Para adoptar estas decisiones, el equipo debe ser capaz de ver los
costos en un ámbito por proyecto.

El equipo de adopción de la nube se sitúa en el centro de todas las actividades de adopción. Es, por lo tanto, la
primera línea de defensa contra el exceso de gasto. Este equipo tiene un papel activo en las tres fases del control
de costos.
Visibilidad :
Reconocimiento : es importante que el equipo de adopción de la nube conozca los objetivos de
ahorro de costos del trabajo. La simple indicación de que el trabajo de adopción de la nube ayudará a
reducir los costos da pie al error. La visibilidad específica es importante. Por ejemplo, si el objetivo es
reducir el TCO del centro de datos en un 3 por ciento o los gastos operativos anuales en un 7 por
ciento, esta información debe divulgarse pronto y de forma clara.
Telemetría : este equipo necesita ver el impacto de sus decisiones. Durante las actividades de
migración o innovación, sus decisiones tienen un efecto directo en los costos y el rendimiento. El
equipo debe equilibrar estos dos factores opuestos. La supervisión del rendimiento y de los costos
limitada al ámbito de los proyectos activos del equipo es importante para contar con la visibilidad
necesaria.
Responsabilidad : el equipo de adopción de la nube debe tener en cuenta los presupuestos
preestablecidos asociados a sus trabajos de adopción. Cuando los costos reales no se corresponden con
el presupuesto, la responsabilidad entra en juego. La responsabilidad no equivale a penalizar al equipo de
adopción por superar el presupuesto, ya que este exceso puede ser resultado de decisiones de
rendimiento necesarias. En su lugar, la responsabilidad supone educar al equipo sobre los objetivos y
cómo sus decisiones afectan a estos objetivos. Además, incluye establecer un diálogo que permita al
equipo explicar las decisiones que han provocado el exceso de gasto. Si esas decisiones no se ajustan a
los objetivos del proyecto, esta labor ofrece una buena oportunidad de colaborar con el equipo de
estrategia de la nube para adoptar mejores decisiones.
Optimización : este trabajo es una labor de equilibrio, ya que la optimización de los recursos puede
reducir el rendimiento de las cargas de trabajo que admiten. A veces, no se materializan los ahorros
previstos o presupuestados para una carga de trabajo porque esta no funciona correctamente con los
recursos presupuestados. En estos casos, el equipo de adopción de la nube tiene que tomar decisiones
razonables e informar de los cambios a los equipos de estrategia de la nube y gobernanza de la nube,
para que se puedan corregir los presupuestos o las decisiones de optimización.

Por lo general, el equipo de gobernanza de la nube es responsable de la administración de los costos en todo el
trabajo de adopción de la nube. Como se describe en el tema sobre la materia de administración de costos de la
metodología de gobernanza de Cloud Adoption Framework, la administración de costos es la primera de las
cinco materias de gobernanza de la nube. En esos artículos se describen una serie de responsabilidades más
detalladas para el equipo de gobernanza de la nube.
Este trabajo se centra en las siguientes actividades relacionadas con el desarrollo de una organización con
control de costos:
Visibilidad : el equipo de gobernanza de la nube funciona en el mismo nivel y en colaboración con el
equipo de estrategia de la nube a la hora de planear presupuestos de adopción de la nube. Estos dos
equipos también trabajan juntos para revisar periódicamente los gastos reales. El equipo de gobernanza
de la nube es responsable de garantizar unos informes de costos coherentes y confiables, así como una
telemetría del rendimiento.
Responsabilidad : cuando se producen desviaciones de presupuesto, el equipo de estrategia de la nube
y el equipo de gobernanza de la nube deben colaborar para determinar rápidamente el mejor curso de
acción para corregir las desviaciones. Por lo general, el equipo de gobernanza de la nube actuará a partir
de las decisiones adoptadas. A veces, la acción puede ser sencillamente una nueva formación del equipo
de adopción de la nube afectado. El equipo de gobernanza de la nube también puede ayudar a optimizar
los recursos implementados, a cambiar las opciones de descuento o incluso a implementar opciones de
control de costos automatizadas, como el bloqueo de la implementación de recursos no planeados.
Optimización : después de migrar recursos a la nube o crearlos en ella, se pueden emplear herramientas
de supervisión para evaluar el rendimiento y el uso de esos recursos. Unos datos de rendimiento y
supervisión adecuados pueden identificar los recursos que deben optimizarse. El equipo de gobernanza
de la nube es responsable de garantizar que las herramientas de supervisión y generación de informes
de costos se implementan de forma coherente. También pueden ayudar a los equipos de adopción a
identificar oportunidades de optimización en función de la telemetría de costos y rendimiento.
Centro de excelencia de la nube

Aunque no suele ser responsable de la administración de costos, el equipo de CCoE puede tener un impacto
significativo en las organizaciones con control de costos. Muchas decisiones fundamentales de TI afectan a los
costos a escala. Cuando el equipo de CCoE realiza su labor, se pueden reducir los costos de varios trabajos de
Visibilidad : el equipo de CCoE debe ver cualquier grupo de administración o grupo de recursos que
aloje recursos básicos de TI. El equipo puede utilizar estos datos para buscar oportunidades que
optimizar.
Responsabilidad : aunque no suele ser responsable del costo, el equipo de CCoE puede
responsabilizarse de crear soluciones repetibles que minimicen el costo y maximicen el rendimiento.
Optimización : dada la visibilidad con la que cuenta el equipo de CCoE sobre varias implementaciones,
se encuentra en una posición idónea para ofrecer sugerencias de optimización y ayudar a los equipos de
adopción a optimizar los recursos.
Pasos siguientes
La práctica de estas responsabilidades en cada nivel del negocio ayuda a conseguir una organización con
control de costos. Para comenzar a actuar sobre esta guía, revise la Introducción a la preparación de la
organización como ayuda para identificar las estructuras de equipo adecuadas.
Identificación de las estructuras de equipo correctas
Antipatrones de organización de la nube
Los clientes suelen experimentar antipatrones de adopción de la nube en su estructura organizativa. Muchos
factores pueden causar estos problemas:
Conjuntos de herramientas
Asociados
Ingenieros
Departamentos de TI mal alineados
Es importante comprender el rol de cada uno de estos factores en un escenario de adopción de la nube correcta.
Antipatrón: tratar el departamento de TI como un centro de costos

Muchas compañías tratan los departamentos de TI como centros de costos. Este enfoque puede llevar a percibir
que el departamento de TI no agrega valor a la empresa. Si los empleados ven el departamento de TI como un
proveedor en lugar de un facilitador, se pueden desanimar. También es difícil para la empresa captar el talento
adecuado. El resultado es una motivación reducida y tiempos de ciclo de vida prolongados. La calidad del
trabajo de TI puede verse afectada y pueden desarrollarse silos y feudos.
Ejemplo: tratamiento de TI como un centro de costos
Una corporación administra su Departamento de TI como un centro de costos bajo la responsabilidad del
director financiero (CFO). La junta directiva percibe este departamento como un proveedor de servicios lento
que es uno de los principales generadores de costos de la empresa. La junta directiva no se da cuenta de que la
unidad de negocio de movilidad consume la mayoría de los recursos que ha solicitado el Departamento de TI. TI
compra un centro de recursos para todas las unidades de negocio, pero la unidad de negocio de movilidad se
apropia de este recurso sobredimensionado. La junta no percibe el departamento de TI como un facilitador ni
un asociado.
Resultado preferido: percepción de TI como un facilitador
En lugar de administrar el departamento de TI como un centro de costos, tenga en cuenta uno de estos
enfoques:
Contracargo: las unidades de negocio tratan los costos de TI como gastos de explotación en sus
presupuestos.
Visualización o concienciación: TI funciona como un agente. En las reuniones de seguimiento de la empresa,
TI atribuye todos los costos directos a las unidades de negocio pertinentes.
Use la nube como herramienta para aumentar la transparencia de los costos y de la empresa. Por ejemplo,
implemente la disciplina Cost Management para aumentar la transparencia de los costos. De este modo,
conocerá el costo de las distintas unidades de negocio. Verá el departamento de TI como un facilitador para esas
unidades.
Para mejorar la transparencia, céntrese en la visibilidad, la responsabilidad y la optimización al cambiar a la
nube. Para obtener más información, consulte Crear una organización con control de costos.
Antipatrón: invertir en nuevas tecnologías sin la intervención de la

empresa
A menudo, los departamentos de TI invierten recursos humanos y financieros considerables en la creación e
implementación de plataformas y conjuntos de herramientas sólidos. No obstante, en algunas ocasiones TI no
tiene en cuenta las unidades de negocio ni sus necesidades durante las fases de diseño y desarrollo. Esta
omisión conduce a nuevas plataformas con una importancia mínima para las unidades de negocio. En
consecuencia, los empleados dudan si deben aceptar la nueva tecnología. La adopción puede ser deficiente o
lenta. También existe frustración en el departamento de TI cuando las unidades de negocio no usan sus
plataformas.
Ejemplo: configuración de una plataforma sin la intervención de las unidades de negocio
El departamento de TI de una empresa de análisis de datos configura y personaliza una plataforma Azure sin
que intervenga ninguna unidad de negocio. Al usar la plataforma, los desarrolladores de las unidades de
negocio:
Se dan cuenta de que no tienen los permisos que necesitan para la implementación.
Solo pueden utilizar un número restringido de servicios.
Emiten incidencias de soporte técnico, que alargan los ciclos de aprobación.
Comienzan a dudar sobre la nueva plataforma.
Al final, algunos desarrolladores compran una suscripción de Azure por sí mismos para evitar las molestias de
las reglas y normativas de TI. Aparece shadow IT. Dado que la empresa tiene poco control sobre shadow IT,
surgen grandes riesgos de seguridad.
Resultado preferido: implicación de las unidades de negocio en la toma de decisiones
Evite crear silos de TI al implementar una plataforma de nube preparada para la empresa. Implique a los
desarrolladores y responsables de la toma de decisiones técnicas (TDM) de las unidades de negocio en los
procesos de diseño y desarrollo. Para mejorar la adopción de la plataforma, escuche las opiniones de las
unidades de negocio.
Consulte Empiece a utilizar las zonas de aterrizaje de escala empresarial de Cloud Adoption Framework para
conocer los procedimientos recomendados y los principios de diseño de Azure que aumentan la velocidad de
adopción y se adaptan a los desarrolladores. Consiga el equilibrio adecuado entre cumplimiento y flexibilidad.
Por ejemplo, busque formas de cumplir las directivas de gobernanza y seguridad a la vez que mantiene los
entornos de desarrollo ágiles.
Antipatrón: subcontratar las principales funciones empresariales

Los asociados de consultoría y los proveedores de servicios administrados (MSP) pueden desempeñar un papel
importante en un recorrido de la nube. Sin embargo, las empresas deben procurar que el trabajo de los
asociados y los MSP no sea el máximo valor en su negocio. Las empresas que subcontratan responsabilidades a
MSP o consultores de nube no deben depender de estos proveedores.
Ejemplo: subcontratación de la adopción de la nube y la migración a la nube
Un instituto de investigación tiene un proyecto de migración en la nube con una prioridad temporal crítica. Para
acortar el recorrido de la adopción de la nube, contrata a un MSP que cree la base de Azure e implemente la
migración. En lugar de obtener información sobre la fase de adopción de la nube y la creación de aptitudes, el
Instituto opta por atribuir toda la responsabilidad de Azure al MSP. Dado que el instituto no tiene ningún
conocimiento de Azure ni de la nube, el MSP toma el mando en todas las decisiones, por lo que el instituto
depende del MSP.
Resultado preferido: atribución de la responsabilidad de las áreas de diseño críticas a la empresa
Considere la subcontratación una buena estrategia de reducción de costos. Sin embargo, tome decisiones en su
empresa cuando impliquen estas áreas de diseño críticas:
Gobernanza
Riesgo
Cumplimiento normativo
Identidad
Mantenga la responsabilidad dentro de la empresa para estas y otras áreas que son críticas para su seguridad.
Use asociados externos para acelerar el recorrido de la adopción. Sin embargo, para evitar depender de los
proveedores, no lo subcontrate todo.
Antipatrón: contratación de responsables de la toma de decisiones

técnicas en lugar de desarrollar ingenieros de nube
Las compañías dan importancia a la búsqueda del personal adecuado. Como resultado, suelen contratar o
desarrollar TDM durante las fases iniciales de adopción de la nube. Los recorridos de nube correctos dependen
de los TDM. Sin embargo, lo más importante es que las adopciones de nube necesitan ingenieros con
mentalidad participativa y conocimientos técnicos profundos.
Ejemplo: contratación solo de TDM
Un instituto de investigación contrata varios TDM para liderar su recorrido de nube. Una vez finalizada la fase
inicial de concepto de alto nivel, se inicia la fase de implementación. A continuación, el instituto observa que las
implementaciones de nube se comportan de manera diferente que las implementaciones locales. Requiere un
esfuerzo de ingeniería de nube adicional para implementar correctamente los conceptos de infraestructura
como código (IaC) y gobernanza controlada por directivas.
Resultado preferido: uso de ingenieros de nube para la fase de implementación
Recuerde que los ingenieros son esenciales para implementar correctamente los conceptos de zona de aterrizaje
y automatización de la nube. Las responsabilidades y las tareas pueden cambiar significativamente cuando se
adoptan modelos de servicio. Al cambiar las responsabilidades a un proveedor de nube, puede entrar en
producción más rápido. También puede usar TDM para la toma de decisiones, pero emplee ingenieros de nube
con capacidad para tareas que requieren conocimientos profundos de ingeniería. A continuación, podrá
descubrir las ventajas que proporciona la nube.
Pasos siguientes
Alineación de responsabilidades entre los equipos
Crear una organización con control de costos
Antipatrones de la organización: Islas y feudos
El éxito de cualquier cambio importante en las prácticas empresariales, la cultura o las operaciones tecnológicas
requiere una mentalidad de crecimiento. En el fondo de la mentalidad de crecimiento se encuentra la aceptación
del cambio y la capacidad de liderazgo a pesar de la ambigüedad.
Algunos antipatrones pueden bloquear una mentalidad de crecimiento en las organizaciones que quieren crecer
y transformarse, como la microadministración, el pensamiento sesgado y las prácticas excluyentes. Muchos de
estos bloqueadores son desafíos personales que crean oportunidades de crecimiento personal para todo el
mundo. Pero hay dos antipatrones comunes de TI que requieren más que el crecimiento o la madurez
individuales: islas y feudos.
Estos antipatrones son el resultado de cambios orgánicos en varios equipos, lo que da lugar a comportamientos
incorrectos de la organización. Para abordar la resistencia causada por cada antipatrón, es importante
comprender la causa principal de esta formación.
Equipos de TI orgánicos y sin problemas

Es natural crear una división del trabajo en TI. Es recomendable establecer equipos que tengan una experiencia
similar, procesos compartidos, un objetivo común y una visión alineada. También es natural que esos equipos
tengan su propia microcultura, normas compartidas y perspectivas.
Los equipos de TI sin problemas se centran en asociarse con otros equipos para promover el correcto
cumplimiento de sus tareas. Los equipos de TI sin problemas tratan de comprender los objetivos empresariales
para los que está diseñada su contribución tecnológica. Los detalles y el impacto fiscal pueden ser aproximados,
pero la contribución de valor del equipo suele comprenderse dentro del equipo.
Aunque los equipos de TI sin problemas sienten entusiasmo por la tecnología que apoyan, están abiertos al
cambio y dispuestos a probar cosas nuevas. Estos equipos suelen ser los colaboradores más antiguos y fuertes
con el trabajo del centro de excelencia de la nube (CCoE). Su contribución debe fomentarse intensamente.
Resistencia natural al cambio
En ocasiones, las microculturas comprendidas en equipos de TI sin problemas pueden reaccionar mal a las
decisiones ejecutivas o jerárquicas para impulsar el cambio. Esta reacción es natural, ya que los colectivos de
seres humanos con normas compartidas a menudo cooperan para superar las amenazas externas.
Los cambios que afectan al trabajo diario del equipo, la sensación de seguridad o la autonomía pueden verse
como un riesgo para el colectivo. Las señales de resistencia son a menudo un indicador temprano de que los
miembros del equipo no sienten que forman parte del proceso de toma de decisiones.
Cuando los arquitectos y otros responsables de la nube invierten en erradicar los sesgos personales y en
promover la inclusión de los equipos de TI existentes, es probable que esta resistencia disminuya rápidamente y
se resuelva con el tiempo. Una herramienta disponible para que arquitectos y responsables de la nube creen
una toma de decisiones inclusiva es la formación de un CCoE.
Fricción sin problemas
Es fácil confundir resistencia con fricción. Los equipos de TI existentes pueden tener conocimientos sobre
errores del pasado, riesgos tangibles, conocimientos del sector sobre soluciones y deudas técnicas no
documentadas. Desafortunadamente, incluso los mejores equipos de TI pueden caer en la trampa de describir
estos importantes puntos de datos como parte de una solución técnica específica, que no debe cambiarse. Este
enfoque de la comunicación enmascara los conocimientos de los equipos, lo que crea una percepción de
resistencia.
Al proporcionar a estos equipos un mecanismo para comunicarse con una terminología de futuro, se agregarán
puntos de datos, se identificarán lagunas y se creará una fricción sin problemas en torno a las soluciones
propuestas. Esa fricción adicional lijará las aristas de las soluciones e impulsará los valores a largo plazo. Con
tan solo cambiar la conversación se puede aumentar la claridad sobre temas complejos y generar energía que
se traduzca en mejores soluciones.
La guía sobre la definición de la directiva corporativa tiene por objeto facilitar las conversaciones basadas en el
riesgo con las partes interesadas de la empresa. Sin embargo, este mismo modelo se puede usar para facilitar
las conversaciones con los equipos que se perciben como antagonistas a la nube. Cuando la percepción de la
resistencia esté muy extendida, sería prudente incluir prácticas de resolución de resistencia en los estatutos de
un equipo de gobernanza en la nube.
Antipatrones
El crecimiento orgánico y dinámico en TI que crea equipos de TI sin problemas también puede dar lugar a
antipatrones que bloquean la transformación y la adopción de la nube. Las islas y los feudos de TI son distintos
de las microculturas naturales presentes en equipos de TI sin problemas. En cualquiera de los dos patrones, el
enfoque del equipo tiende a estar dirigido a la protección de su "territorio". Cuando los miembros del equipo se
enfrentan a la oportunidad de impulsar el cambio y mejorar las operaciones, invertirán más tiempo y energía en
bloquear el cambio que en encontrar una solución positiva.
Como se mencionó anteriormente, los equipos de TI sin problemas pueden crear resistencia natural y fricción
positiva. Las islas y los feudos son otro desafío. No se ha documentado ningún indicador adelantado para
ninguno de los dos antipatrones. Estos antipatrones tienden a identificarse después de meses de trabajo del
centro de excelencia de la nube y el equipo de gobernanza en la nube. Se detectan como resultado de la
resistencia continuada.
Incluso en las culturas tóxicas, el trabajo del CCoE y el equipo de gobernanza en la nube deberían contribuir a
impulsar el crecimiento cultural y el progreso técnico. Después de meses de trabajo, es posible que algunos
equipos no muestren todavía signos de conductas inclusivas y se mantengan firmes en su resistencia al cambio.
Es probable que estos equipos funcionen en uno de los siguientes modelos de antipatrón: islas y feudos.
Aunque estos modelos presentan síntomas similares, la causa raíz y los enfoques para resolver la resistencia
son radicalmente diferentes entre ellos.
Islas de TI
Es probable que los miembros del equipo de una isla de TI se definan a sí mismos a través de su alineación con
un pequeño número de proveedores de TI o un área de especialización técnica. No obstante, no deben
confundirse las islas de TI con los feudos de TI. Las islas de TI suelen estar determinadas por la comodidad y el
entusiasmo y, a menudo, son más fáciles de superar que los motivos basados en el miedo que subyacen en los
feudos.
Este antipatrón suele surgir de un entusiasmo común por una solución concreta. Las islas de TI se ven luego
reforzadas por las aptitudes avanzadas del equipo como resultado de la inversión en esa solución específica.
Esta aptitud superior puede ser un acelerador del trabajo de adopción en la nube si se puede superar la
resistencia a los cambios. También puede convertirse en un bloqueador importante si las islas se dividen o si los
miembros del equipo no pueden evaluar con precisión las opciones. Afortunadamente, las islas de TI a menudo
se pueden solucionar sin realizar cambios importantes en el organigrama.
Resolución de la resistencia de islas de TI
Las islas de TI se pueden solucionar a través de los siguientes enfoques. El mejor enfoque dependerá de la causa
raíz de la resistencia.
Cree equipos vir tuales: en la sección Preparación de la organización de Cloud Adoption Framework se
describe una estructura de varias capas para integrar y definir cuatro equipos virtuales. Una ventaja de esta
estructura es la visibilidad y la inclusión entre organizaciones. La introducción de un centro de excelencia de la
nube crea un equipo de aspiraciones de alto perfil en el que los mejores ingenieros querrán participar. Esto
ayuda a crear nuevas alineaciones entre soluciones que no están limitadas por las restricciones del organigrama
y que impulsarán la inclusión de los mejores ingenieros que se encuentran protegidos por islas de TI.
La introducción de un equipo de estrategia en la nube creará una visibilidad inmediata de las contribuciones de
TI en cuanto al trabajo de adopción. Cuando las islas de TI luchan por la separación, esta visibilidad puede
ayudar a motivar a los responsables empresariales y de TI para que apoyen adecuadamente a los miembros del
equipo que se resisten. Este proceso es una vía rápida para la involucración y el soporte de las partes
interesadas.
Considere la experimentación y la exposición: Es probable que los miembros de un equipo en una isla de
TI se hayan visto obligados a pensar de cierta manera durante algún tiempo. La ruptura con la mentalidad de vía
única es un primer paso para resolver la resistencia.
La experimentación y la exposición son herramientas eficaces para derribar barreras de las islas. Es posible que
los miembros del equipo sean resistentes a soluciones de la competencia, por lo que no es aconsejable
colocarlos a cargo de un experimento que compite con su solución existente. No obstante, como parte de una
primera prueba de carga de trabajo de la nube, la organización debe implementar soluciones que compitan
entre sí. Debe invitarse al equipo aislado en la isla a participar como origen de entrada y de revisión, pero no
como responsable de la toma de decisiones. Esto debe comunicarse claramente al equipo, junto con el
compromiso de involucrar al equipo más profundamente como responsable de la toma de decisiones antes de
pasar a las soluciones de producción.
Durante la revisión de la solución competitiva, siga las prácticas descritas en la definición de la directiva
corporativa para documentar los riesgos tangibles del experimento y establecer directivas que ayuden a que el
equipo aislado en la isla se sienta más cómodo con el estado futuro. Esto expondrá al equipo a nuevas
soluciones y afianzará la solución futura.
No se ponga límites: A los equipos que impulsan la adopción de la nube les resulta fácil forzar los límites
explorando nuevas e interesantes soluciones nativas de la nube. Esta es la mitad del enfoque para eliminar los
límites. No obstante, ese planteamiento puede reforzar aún más las islas de TI. Si se intenta lograr un cambio
demasiado rápido sin respetar las culturas existentes, se puede crear una fricción incorrecta y provocar una
resistencia natural.
Cuando las islas de TI comienzan a resistirse, es importante no ponerse límites en las propias soluciones. No
olvide una sencilla verdad: una solución nativa de la nube no siempre es la mejor. Plantéese utilizar soluciones
híbridas que puedan ofrecer la oportunidad de proyectar las inversiones existentes de la isla de TI en el futuro.
Plantéese también usar versiones basadas en la nube de la solución que el equipo de la isla de TI usa ya.
Experimente con esas soluciones y expóngase al punto de vista de quienes viven en la isla de TI. Como mínimo,
obtendrá una nueva perspectiva. En muchas situaciones, es posible que gane suficiente respeto de la isla de TI
como para disminuir la resistencia.
Invier ta en educación: Muchas de las personas que viven en una isla de TI se entusiasmaron con la solución
actual como resultado de la expansión de su propia educación. Invertir en la educación de estos equipos rara
vez está fuera de lugar. Asigne tiempo a estas personas para que participen en aprendizaje autodidacta, clases o
incluso conferencias que rompan el enfoque del día a día sobre la solución actual.
Para que la educación sea una inversión, es necesario que el gasto genere algún tipo de rendimiento. A cambio
de la inversión, el equipo podría mostrar la solución propuesta al resto de los equipos involucrados en la
adopción de la nube. También podría facilitar documentación sobre los riesgos tangibles, los enfoques de
administración de riesgos y las directivas esperadas en la adopción de la solución propuesta. Cada uno
involucrará a estos equipos en la solución y le ayudará a aprovechar sus conocimientos tribales.
Convier ta los muros en baches: Las islas de TI pueden ralentizar o detener cualquier transformación. La
experimentación y la iteración encontrarán salida, pero solo si el proyecto sigue avanzando. Céntrese en
convertir los muros en simples baches. Defina directivas con las que todos puedan sentirse temporalmente
cómodos a cambio de un progreso continuo.
Por ejemplo, si la seguridad de TI es el obstáculo porque su solución de seguridad no puede supervisar los
peligros de los datos protegidos en la nube, establezca directivas de clasificación de datos. Evite la
implementación de datos clasificados en la nube hasta que se encuentre una solución aceptable. Invite a la
seguridad de TI a la experimentación con soluciones híbridas o nativas de la nube para supervisar los datos
protegidos.
Si el equipo de red funciona como una isla, identifique las cargas de trabajo que son autónomas y no tienen
dependencias de red. En paralelo, experimente, exponga y enseñe al equipo de red mientras trabaja en
soluciones híbridas o alternativas.
Sea paciente e inclusivo: Es tentador seguir adelante sin contar con una isla de TI. Pero esta decisión causará
interrupciones y presentará obstáculos más adelante. El cambio de mentalidad de los miembros de la isla de TI
puede llevar tiempo. Tenga paciencia con su resistencia natural: conviértala en valor. Sea inclusivo e invite a la
fricción sin problemas para mejorar la solución futura.
No compita nunca: La isla de TI existe por un motivo. Se conserva por un motivo. Existe una inversión en el
mantenimiento de la solución que entusiasma a los miembros del equipo. La competencia directa con la
solución o la isla de TI distraerá la atención del objetivo real de lograr resultados empresariales. Esta trampa ha
bloqueado muchos proyectos de transformación.
Manténgase centrado en el objetivo, y no en un solo componente del objetivo. Contribuya a acentuar los
aspectos positivos de la solución de la isla de TI y ayude a los miembros del equipo a tomar decisiones
acertadas sobre las mejores soluciones para el futuro. No vaya contra la solución actual, ya que esto sería
contraproducente.
Asóciese a la empresa: Si la isla de TI no bloquea los resultados empresariales, ¿por qué se preocupa? No
existe una solución perfecta ni un proveedor de TI perfecto. La competencia existe por un motivo; cada uno tiene
sus propias ventajas.
Adopte la diversidad e incluya la empresa mediante el apoyo y la alineación con un equipo de estrategia en la
nube fuerte. Cuando una isla de TI prefiere una solución que bloquea los resultados empresariales, será más
fácil comunicar ese obstáculo sin el ruido de las disputas técnicas. El apoyo a islas de TI sin pegas mostrará la
posibilidad de asociar los resultados empresariales esperados. Este trabajo conseguirá un mayor respeto y más
apoyos de la empresa cuando una isla de TI presente un bloqueador legítimo.
Feudos de TI
Los miembros del equipo de un feudo de TI probablemente se definan a sí mismos a través de su alineación con
un proceso o un área de responsabilidad en concreto. El equipo trabaja bajo el supuesto de que la influencia
externa en su área de responsabilidad provocará problemas. Los feudos suelen ser un antipatrón basado en el
miedo, lo que requerirá un considerable apoyo de liderazgo para superarlos.
Los feudos son especialmente comunes en organizaciones que han experimentado reducción de TI, inestabilidad
frecuente del personal de TI o un liderazgo de TI deficiente. Cuando la empresa considera la TI simplemente un
centro de costos, es mucho más probable que surjan feudos.
Por lo general, los feudos son consecuencia de un superior jerárquico que teme la pérdida del equipo y de la
base de poder asociada. Estos responsables suelen tener un sentido del deber hacia su equipo y sienten la
necesidad de proteger a sus subordinados de las consecuencias negativas. Frases como "proteger al equipo del
cambio" y "proteger al equipo de la interrupción del proceso" pueden ser indicadores de un jefe demasiado
cauteloso que puede necesitar más apoyo del liderazgo.
Resolución de la resistencia de feudos de TI
Los feudos de TI pueden mostrar cierto crecimiento si se siguen los enfoques de resolución de la resistencia de
silos de TI. Antes de intentar resolver la resistencia de un feudo de TI, se recomienda tratar primero al equipo
como una isla de TI. Si ese tipo de enfoques no produce ningún cambio significativo, el equipo resistente podría
verse afectado por un antipatrón de feudo de TI. La causa raíz de los feudos de TI es un poco más compleja de
resolver, ya que esa resistencia tiende a proceder del superior jerárquico directo (o un responsable superior en
el organigrama). Por lo general, es más fácil superar los retos basados en islas de TI.
Cuando la resistencia continua de los feudos de TI bloquea el trabajo de adopción de la nube, sería conveniente
realizar un trabajo conjunto para evaluar la situación con los responsables de TI existentes. Los responsables de
TI deben considerar detenidamente la información procedente del equipo de estrategia en la nube, el centro de
excelencia de la nube y el equipo de gobernanza de la nube antes de tomar decisiones.
NOTE
Los responsables de TI no deben tomar nunca a la ligera los cambios en el organigrama. También deben validar y analizar
los comentarios de cada uno de los equipos auxiliares. Aunque el trabajo de transformación, como la adopción en la nube,
tiende a magnificar los problemas subyacentes que han pasado desapercibidos o llevan mucho tiempo sin abordarse
antes de esta iniciativa. Cuando los feudos impiden el éxito de la empresa, es posible que se necesite un cambio de
liderazgo.
Afortunadamente, quitar el responsable de un feudo no suele acabar en despido. Estos responsables fuertes y entusiastas
a menudo pueden pasar a desempeñar un papel directivo después de un breve período de reflexión. Con el apoyo
adecuado, este cambio puede ser recomendable para el responsable del feudo y el equipo actual.
Cau t i on
En el caso de los jefes de feudos de TI, proteger el equipo de riesgos es un claro valor de liderazgo. No obstante,
hay una delgada línea divisoria entre protección y aislamiento. Impedir que el equipo participe en impulsar los
cambios puede tener consecuencias psicológicas y profesionales en él. La tentación de resistirse al cambio
puede ser fuerte, especialmente durante los momentos de cambio visible.
El jefe de cualquier equipo aislado puede demostrar mejor una mentalidad de crecimiento experimentando con
la guía asociada a equipos de TI sin problemas de las secciones anteriores. La participación activa y optimista en
actividades de CCoE y de gobernanza puede conducir al crecimiento personal. Los jefes de feudos de TI son los
más idóneos para cambiar las mentalidades asfixiantes y ayudar al equipo a desarrollar nuevas ideas.
Los feudos de TI pueden ser una señal de problemas de liderazgo sistémicos. Para superar un feudo de TI, los
responsables de TI necesitan tener capacidad para realizar cambios en las operaciones, las responsabilidades y,
ocasionalmente, incluso en las personas responsables del mando directo de equipos específicos. Cuando esos
cambios son necesarios, es aconsejable abordarlos con puntos de datos claros y defendibles.
Puede que se requiera la alineación con las partes interesadas de la empresa, las motivaciones empresariales y
los resultados empresariales para impulsar el cambio necesario. La asociación con el equipo de estrategia en la
nube, el centro de excelencia de la nube y el equipo de gobernanza en la nube puede proporcionar los puntos de
datos necesarios para una posición defendible. Cuando sea necesario, estos equipos deben participar en una
escalación de grupo para abordar los desafíos que no se pueden abordar solo con el liderazgo de TI.
Pasos siguientes
La interrupción de los antipatrones de la organización es un trabajo del equipo. Para actuar según esta guía,
revise la introducción a la preparación de la organización para identificar los participantes y las estructuras de
equipo correctos:
Identificación de los participantes y las estructuras de equipo correctos
Herramientas y plantillas
El marco Cloud Adoption Framework incluye herramientas que le permiten implementar rápidamente el cambio
técnico. Use estas herramientas, plantillas y evaluaciones para acelerar la adopción de la nube. Los siguientes
recursos pueden ayudarle en cada fase de adopción. Algunas de las herramientas y plantillas se pueden usar en
varias fases.
Estrategia
REC URSO DESC RIP C IÓ N
Seguimiento del recorrido de la nube Identifique la ruta de adopción de la nube en función de las
necesidades de su empresa.
Plantilla del plan y la estrategia Documente las decisiones a medida que ejecuta la estrategia
y el plan de adopción de la nube.
Plan
Seguimiento del recorrido de la nube Identifique la ruta de adopción de la nube en función de las
necesidades de su empresa.
Plantilla del plan y la estrategia Documente las decisiones, a medida que ejecuta la estrategia
y el plan de adopción de la nube.
Generador del plan de adopción de la nube Para estandarizar los procesos, implemente un trabajo
pendiente en Azure Boards mediante la plantilla.
Uso de la plantilla de ADO de estrategia, planeación, Para estandarizar los procesos, implemente un trabajo
preparación y gobernanza pendiente en Azure Boards mediante la plantilla.
Ready
Lista de comprobación de preparación Use esta lista de comprobación para preparar su entorno
para la adopción, así como para preparar la primera zona de
aterrizaje de migración, personalizar el plano técnico y
expandirlo.
Plantilla de seguimiento de convención de nomenclatura y Documente las decisiones sobre los estándares de
etiquetado nomenclatura y etiquetado para garantizar la coherencia y
reducir el tiempo de incorporación.
Plano técnico de Fundación CAF Use una implementación ligera de una base de gobernanza
inicial para proporcionar experiencia práctica con las
herramientas de gobernanza de Azure.
Plano técnico de la zona de aterrizaje de la migración de CAF Aprovisione las cargas de trabajo que se van a migrar desde
un entorno local a Azure y prepárese para hospedarlas. Para
obtener más información acerca de este plano técnico,
consulte Implementación de una zona de aterrizaje para la
migración.
Módulos de Terraform Base del código fuente de la versión de Terraform de las

zonas de aterrizaje de CAF.
Registro de Terraform El sitio web de registro de Terraform, filtrado para mostrar

todos los módulos de Cloud Adoption Framework necesarios
para crear una zona de aterrizaje mediante Terraform.
Control
Evaluación del banco de pruebas de gobernanza Identifique las brechas entre su estado actual y las
prioridades empresariales, y obtenga los recursos adecuados
para abordarlas.
Plano técnico de Fundación CAF Implementación ligera de una base de gobernanza inicial
para proporcionar experiencia práctica con las herramientas
de gobernanza de Azure.
Plantilla de la materia de gobernanza Defina el conjunto básico de procesos de gobernanza que se

usa para aplicar cada disciplina de gobernanza.
Plantilla de la materia de Cost Management Defina las instrucciones de la directiva y diseñe la guía que le
permitirá consolidar la gobernanza de la nube en su
organización con un enfoque en la administración de costos.
Plantilla de la materia de aceleración de la implementación Defina las instrucciones de directiva y diseñe la guía que le
organización con un enfoque en la aceleración de la
implementación.
Plantilla de la materia de base de referencia de identidad Defina las instrucciones de la directiva y diseñe la guía que le
organización con un enfoque en los requisitos de la
identidad.
Plantilla de la materia de coherencia de recursos Defina las instrucciones de la directiva y diseñe la guía que le
organización con un enfoque en la coherencia de los
recursos.
Plantilla de la materia de base de referencia de seguridad Defina las instrucciones de la directiva y diseñe la guía que le
organización con un enfoque en la base de referencia de
seguridad.
Azure Security Benchmark La prueba comparativa de seguridad de Azure (ASB)

proporciona recomendaciones y procedimientos
recomendados para ayudar a mejorar la seguridad de las
cargas de trabajo, los datos y los servicios de Azure.
Azure Governance Visualizer Azure Governance Visualizer es un script de PowerShell que

recorre en iteración la jerarquía de grupos de administración
de inquilinos de Azure hasta el nivel de suscripción. Captura
los datos de las funcionalidades de gobernanza en Azure
más destacadas, como Azure Policy, el control de acceso
basado en rol de Azure (RBAC de Azure) y Azure Blueprints.
A partir de los datos recopilados, el visualizador muestra el
mapa de jerarquías, crea un resumen de inquilino y crea
información detallada sobre los grupos de administración y
suscripciones.
Migrar
RESO URC E DESC RIP C IÓ N
Lista de detección de migración del centro de datos Revise esta lista de comprobación para obtener información
que le ayude a identificar cargas de trabajo, servidores y
otros recursos de su centro de datos. Use esta información
para planear la migración.
Plantillas de migración En el generador de Azure DevOps, hemos creado una serie

de plantillas que puede usar para simplificar sus proyectos.
Las plantillas se han creado para WVD, Server Migration,
SQL Migration e implementaciones de AKS.
Innovación
Plantillas de implementación En el generador de Azure DevOps se incluyen listas de

comprobación de proyectos que le ayudarán a crear la
minería de conocimientos, el almacenamiento de datos
moderno y los aceleradores centrados en el sector, como el
recomendador de minoristas, mediante la inteligencia
artificial y el IoT moderno. Las plantillas proporcionan un
enfoque estructurado y una lista de comprobación para
seguir. Cada plantilla y elemento de trabajo tiene vínculos a
contenido necesario, recursos y ejemplos de código que
pueden ayudarle a empezar.
Administrar
Reseña de buena arquitectura de Microsoft Azure Esta evaluación en línea le ayudará a definir las opciones de
operaciones y las arquitecturas específicas de la carga de
trabajo.
Procedimientos recomendados del código fuente Este código fuente que se puede implementar complementa
y acelera la adopción de procedimientos recomendados de
los servicios de administración de servidores de Azure. Use
este código fuente para habilitar rápidamente la
administración de operaciones y establecer una base de
referencia de las operaciones.
Libro de administración de operaciones Documente las decisiones sobre la administración de

operaciones en la nube y facilite las conversaciones con la
empresa para garantizar la alineación con los contratos de
nivel de servicio, la inversión en resistencia y la asignación de
presupuestos relacionada con las operaciones.
Organizar
Diagrama RACI entre equipos Descargue y modifique la plantilla de hoja de cálculo de RACI
para realizar un seguimiento de las decisiones sobre la
estructura de la organización a lo largo del tiempo.
Procedimientos recomendados de seguridad de
Azure
Estos son los principales procedimientos recomendados de seguridad que aconseja Microsoft a partir de las
lecciones aprendidas de clientes y de nuestros propios entornos.
Puede ver una presentación en vídeo de estos procedimientos recomendados en la Comunidad tecnológica de
Microsoft.
1. Personas: Formación del equipo sobre el recorrido de seguridad de

la nube
El equipo debe comprender el recorrido que van a realizar.
Qué : instruya a sus equipos de seguridad y de TI sobre el recorrido de seguridad de la nube y los cambios a los
que se enfrentarán, entre los cuales cabe destacar:
Cambios en las amenazas en la nube
Modelo de responsabilidad compartida y cómo afecta este a la seguridad
Cambios culturales y en los roles y responsabilidades que normalmente acompañan a la adopción de la nube
Por qué : el paso a la nube es un cambio significativo que requiere un cambio en la mentalidad y en el enfoque
de seguridad. Aunque los resultados que proporciona la seguridad a la organización serán los mismos, la mejor
manera de obtenerlos en la nube sí cambiará y, en ocasiones, significativamente.
En muchos sentidos, el cambio a la nube es parecido a mudarse de una casa independiente a un edificio de
apartamentos de lujo de muchas plantas. La infraestructura básica seguirá siendo la misma (fontanería,
electricidad, etc.) y realizará actividades similares (socializar, cocinar, ver la tele, navegar por Internet, etc.), pero a
menudo hay grandes diferencias en lo que incluye el edificio (gimnasio, restaurantes, etc.), quién proporciona
esos servicios y quién se encarga de su mantenimiento, y en sus rutinas diarias.
Quién : todos los miembros de los equipos de seguridad y de TI de la organización con responsabilidades en
materia de seguridad deben estar familiarizados con este contexto y los cambios (desde el Director tecnológico
o el de seguridad de la información a los técnicos).
Cómo : proporcione a los equipos el contexto necesario para implementar y operar correctamente durante la
transición al entorno de nube.
Microsoft ha publicado las lecciones que han aprendido nuestros clientes y nuestra propia organización de TI en
sus recorridos a la nube:
Evolución de los roles y responsabilidades de seguridad en el departamento de seguridad
Evolución del entorno de amenazas, los roles y las estrategias digitales.
Transformación de la seguridad, las estrategias, las herramientas y las amenazas.
Aprendizajes de la experiencia de Microsoft a la hora de proteger el entorno de nube de hiperescala que
pueden ayudarle en su recorrido
Consulte también la prueba comparativa de seguridad de Azure GS-3: Alineación de los roles y
responsabilidades de la organización.
2. Personas: Formación del equipo en tecnología de seguridad de la
nube
Los miembros del equipo deben comprender cuáles son los objetivos.
Qué : asegúrese de que los equipos dispongan de un tiempo reservado para la formación técnica sobre la
protección de recursos de la nube que incluya:
Tecnología de la nube y tecnología de seguridad de la nube
Configuraciones y procedimientos recomendados
Dónde obtener más información técnica si es necesario
Por qué : los equipos necesitan tener acceso a la información técnica para tomar decisiones de seguridad bien
fundamentadas. Los equipos técnicos son buenos en el aprendizaje de nuevas tecnologías en el trabajo, pero la
gran cantidad de información sobre la nube suele sobrecargar su capacidad a la hora de incorporar la formación
a sus rutinas diarias.
Estructurar un tiempo dedicado para la formación técnica ayuda a garantizar que los miembros del equipo
dispongan de tiempo para generar la confianza en su capacidad de evaluar la seguridad de la nube y reflexionar
sobre cómo adaptar sus habilidades y procesos existentes. Incluso los equipos de operaciones especiales más
cualificados del ejército necesitan entrenamiento y formación para conseguir el máximo rendimiento.
Quién : todos los roles que interactúan directamente con la tecnología de la nube (en los departamentos de
seguridad y de TI) deben dedicar un tiempo a la formación técnica sobre plataformas en la nube y su protección.
Además, los administradores técnicos de TI y de seguridad (y, a menudo, los jefes de proyectos) deben estar
familiarizados con algunos detalles técnicos para proteger los recursos en la nube (ya que esto les permitirá
liderar y coordinar iniciativas en la nube de forma más eficaz).
Cómo : asegúrese de que los profesionales técnicos de la seguridad dispongan de un tiempo reservado para
realizar un aprendizaje autodirigido sobre protección de los recursos de la nube. A pesar de que no siempre es
factible, lo ideal sería permitir el acceso a un aprendizaje formal con un instructor experimentado y laboratorios
prácticos.
IMPORTANT
Los protocolos de identidad son fundamentales para el control de acceso en la nube pero no suelen tener la misma
prioridad en la seguridad local. Por ello, los equipos de seguridad deben centrarse en desarrollar una familiaridad con
estos protocolos y registros.
Microsoft ofrece gran cantidad de recursos para ayudar a los profesionales técnicos a mejorar su competencia
en relación con la protección de recursos de Azure y los informes sobre cumplimiento:
Azure Security
Ruta de aprendizaje AZ-500 (y certificación)
Pruebas comparativas de seguridad de Azure: procedimientos recomendados y controles de
seguridad de Azure preceptivos
Bases de referencia de seguridad para Azure: aplicación de las pruebas comparativas de
seguridad a servicios de Azure individuales
Procedimientos recomendados de seguridad de Microsoft: vídeos y documentación
Cumplimiento de Azure
Evaluación del cumplimiento normativo con Azure Security Center
Protocolos de identidad y seguridad
Sitio web con documentación de Azure Security Center
Series de vídeos de YouTube sobre autenticación de Azure AD
Protección de entornos de Azure con Azure Active Directory
responsabilidades de la organización
3. Proceso: Asignación de responsabilidades por las decisiones de

Si no se asigna la responsabilidad de tomar las decisiones de seguridad, estas no se llevarán a cabo.
Qué : designe quién es el responsable de tomar cada tipo de decisión de seguridad para el entorno empresarial
de Azure.
Por qué : definir claramente quién es el encargado de tomar cada decisión de seguridad acelera la adopción de
la nube y aumenta la seguridad. Por el contrario, no disponer de esta definición clara genera normalmente
fricciones ya que nadie se siente capacitado para tomar decisiones, nadie sabe a quién preguntar por una
decisión y nadie tiene el incentivo de investigar para tomar una decisión bien fundamentada. Estas fricciones
suelen impedir la consecución de los objetivos empresariales, las escalas de tiempo de los desarrolladores, los
objetivos de TI y las garantías de seguridad, lo que da lugar a:
Proyectos estancados a la espera de la aprobación de seguridad
Implementaciones no seguras que no pudieron esperar la aprobación de seguridad
Quién : la dirección del departamento de seguridad designa qué equipos o personas son los responsables de
tomar decisiones de seguridad sobre la nube.
Cómo : designe los grupos (o personas individuales) que serán responsables de tomar estas decisiones clave de
seguridad.
Registre la información sobre estos responsables, principalmente su información de contacto, y comparta esta
información con los equipos de seguridad, TI y de la nube para garantizar que puedan ponerse en contacto con
ellos con facilidad.
Estas son las áreas típicas en las que se necesitan decisiones de seguridad, descripciones sobre estas y qué
equipos suelen tomarlas.
DEC ISIÓ N DESC RIP C IÓ N EQ UIP O H A B IT UA L
Seguridad de redes Configuración y mantenimiento de Normalmente, el equipo de

Azure Firewall, aplicaciones virtuales de Infraestructura y seguridad de los
red (y el enrutamiento asociado), puntos de conexión es el que se centra
firewalls de aplicaciones web (WAF), en la seguridad de la red
grupos de seguridad de red (NSG),
grupos de seguridad de aplicaciones
(ASG), etc.
Administración de red Asignación de subred y red virtual en Normalmente, el equipo de

toda la empresa operaciones de red existente en el
departamento de Operaciones de TI
central
Seguridad de los puntos de conexión Supervisión y corrección de la Normalmente, los equipos de

de servidor seguridad del servidor (aplicación de Operaciones de TI central e
revisiones, configuración, seguridad de Infraestructura y seguridad de los
los puntos de conexión, etc.) puntos de conexión de forma conjunta
DEC ISIÓ N DESC RIP C IÓ N EQ UIP O H A B IT UA L
Supervisión de incidentes y respuesta Análisis y corrección de incidentes de Normalmente, el equipo de

seguridad en SIEM o en la consola de operaciones de seguridad .
origen (Azure Security Center,
Azure AD Identity Protection, etc.)
Administración de directivas Establecimiento de la dirección de uso Normalmente, los equipos de

del control de acceso basado en rol de Directivas y estándares + Arquitectura
Azure (RBAC de Azure), Azure Security de seguridad de forma conjunta
Center, la estrategia de protección del
administrador y Azure Policy para
gobernar los recursos de Azure
Seguridad y estándares de identidad Establecimiento de la directiva sobre Normalmente, los equipos de

los directorios de Azure AD, el uso de Administración de identidades y claves
PIM/PAM, la autenticación multifactor, + Directivas y estándares +
la configuración de sincronización y Arquitectura de seguridad de forma
contraseñas, o los estándares de conjunta
identidad de la aplicación
NOTE
Asegúrese de que los responsables de la toma de decisiones tengan la formación adecuada en su área de la nube para
respaldar esta responsabilidad.
Asegúrese de que las decisiones se documentan mediante directivas y estándares para proporcionar un registro y que
sirva de guía a la organización a largo plazo.
responsabilidades de la organización
4. Proceso: Actualización de los procesos de respuesta a incidentes

para la nube
No hay tiempo para planear una crisis durante una crisis.
Qué : actualice los procesos y prepare a los analistas para que den respuesta a los incidentes de seguridad en su
plataforma en la nube de Azure (incluidas las herramientas de detección de amenazas nativas que haya
adoptado). Actualice los procesos, prepare a su equipo y practique con ataques simulados para que puedan
alcanzar su mejor rendimiento durante la investigación y corrección de incidentes, y la detección de amenazas.
Por qué : los atacantes activos suponen un riesgo inmediato para la organización que puede convertirse en una
situación difícil de controlar, por lo que debe responder rápidamente a los ataques. Este proceso de respuesta a
incidentes debe ser efectivo para todo el patrimonio digital, incluidas todas las plataformas en la nube que
hospedan datos empresariales, sistemas y cuentas.
Aunque tiene cierta similitud, las plataformas en la nube presentan diferencias técnicas importantes con
respecto a los sistemas locales que pueden interrumpir los procesos existentes, normalmente porque la
información está disponible en un formato diferente. Los analistas de seguridad también pueden tener
dificultades a la hora de dar una respuesta rápida en un entorno desconocido que puede ralentizarlos
(especialmente si están entrenados únicamente en arquitecturas locales clásicas y enfoques de análisis forense
de redes o discos).
Quién : normalmente, la modernización de los procesos de IR la dirige el equipo de Operaciones de seguridad
con la ayuda de los conocimientos y la experiencia de otros equipos.
Patrocinio: este proceso de modernización suele estar patrocinado por el director de Operaciones de
seguridad o equivalente.
Ejecución: la adaptación de los procesos existentes (o escribirlos por primera vez) es un esfuerzo
colaborativo en el que interviene:
El equipo de administración de incidentes o la dirección de Operaciones de seguridad dirige las
actualizaciones de los procesos y la integración de las principales partes interesadas externas entre las
que se incluyen el equipo legal y el de comunicaciones o relaciones públicas
Los analistas de seguridad del equipo de Operaciones de seguridad proporcionan experiencia en la
investigación y evaluación de prioridades de los incidentes técnicos
El equipo de Operaciones de TI central proporciona experiencia en la plataforma en la nube
(directamente, a través del centro de excelencia en la nube, o mediante consultores externos)
Cómo : actualice los procesos y prepare a su equipo para que sepan qué hacer si detectan un atacante activo.
Procesos y cuadernos de estrategias: adapte los procesos existentes de investigación, corrección y
búsqueda de amenazas a las diferencias de funcionamiento de las plataformas en la nube: nuevas (o
diferentes) herramientas, orígenes de datos, protocolos de identidad, etc.
Educación: instruya a los analistas sobre la transformación de la nube en general, los detalles técnicos
de cómo funciona la plataforma y los procesos nuevos o actualizados para que sepan qué será diferente
y dónde acudir en caso de necesidad.
Áreas de enfoque principales : aunque hay más información en los vínculos de recursos, estas son las áreas
principales en las que se deben centrar los esfuerzos de formación y planeación:
Modelo de responsabilidad compar tida y arquitecturas de la nube: Para un analista de seguridad,
Azure es un centro de datos definido por software que proporciona muchos servicios como el de máquinas
virtuales (que resultan conocidos) y otros que son muy diferentes a los del entorno local, como Azure SQL,
Azure Functions, etc., donde los mejores datos se encuentran en los registros del servicio o en los servicios
especializados de detección de amenazas, en lugar de en los registros de las máquinas virtuales o el sistema
operativo subyacente (que está dirigido por Microsoft y clientes de servicios múltiples). Los analistas deben
comprender e integrar este contexto en sus flujos de trabajo diarios para conocer qué datos se deben
esperar, dónde obtenerlos y en qué formato se encontrarán.
Orígenes de datos de puntos de conexión: la obtención de información y datos de ataques y malware
en servidores hospedados en la nube es a menudo más rápida, fácil y precisa con herramientas de detección
nativas de la nube, como Azure Security Center y los sistemas EDR, en comparación con los enfoques
tradicionales de acceso directo a disco. Aunque los métodos de análisis forense de acceso directo a disco
están disponibles para aquellos escenarios en los que son posibles y obligatorios para los procedimientos
legales (Análisis forense de equipos en Azure), constituyen a menudo el método más ineficaz de detección e
investigación de ataques.
Orígenes de datos de redes e identidades: muchas funciones de las plataformas en la nube usan
principalmente la identidad para el control de acceso como, por ejemplo, el acceso a Azure Portal (aunque los
controles de acceso a la red también se usan ampliamente). Esto requiere que los analistas desarrollen una
comprensión de los protocolos de identidad en la nube para obtener una imagen completa y enriquecida de
la actividad de los atacantes (y las actividades de los usuarios legítimos) para respaldar la investigación y la
corrección de incidentes. Los directorios y protocolos de identidad son también diferentes a los del entorno
local ya que, normalmente, se basan en directorios SAML, OAuth, OIDC y en la nube en lugar de LDAP,
Kerberos, NTLM y Active Directory que son los que se encuentran habitualmente en el entorno local.
Ejercicios prácticos: los ataques y respuestas simulados pueden ayudar a mejorar la memoria organizativa
y la preparación técnica de los analistas de seguridad, buscadores de amenazas, administradores de
incidentes y otras partes interesadas de la organización. El aprendizaje sobre la marcha y la adaptación son
parte natural de la respuesta ante incidentes, sin embargo debe esforzarse por reducir al mínimo este
aprendizaje durante una crisis.
Recursos clave:
Guía de referencia de respuesta a incidentes
Guía para crear su propio proceso de respuesta a incidentes de seguridad
Uso del registro y las alertas de Azure
Procedimientos recomendados de seguridad de Microsoft
Transformación de la seguridad, las estrategias, las herramientas y las amenazas
Aprendizajes de Microsoft del Centro de operaciones de defensa cibernética (CDOC)
Lecciones generales aprendidas
Investigación de incidentes
Corrección de incidentes
Consulte también las pruebas comparativas de seguridad de Azure IR-1: Preparación: Actualización del proceso
de respuesta a incidentes para Azure.
5. Proceso: Establecimiento de la administración de la posición de

En primer lugar, conócete a ti mismo.
Qué : asegúrese de que está administrando activamente la posición de seguridad de su entorno de Azure
mediante:
Asignación clara de responsabilidades a la hora de
Supervisar la posición de seguridad
Mitigar los riesgos para los recursos
Automatización y simplificación de estas tareas
Por qué : la rápida identificación y corrección de los riesgos de protección de seguridad comunes reduce de
forma considerable el riesgo para la organización.
La naturaleza definida por software de los centros de datos en la nube permite la supervisión continua de los
riesgos para la seguridad (vulnerabilidades del software, errores de la configuración de seguridad, etc.) con una
amplia instrumentación de los recursos. La velocidad a la que los desarrolladores y el equipo de TI pueden
implementar máquinas virtuales, bases de datos y otros recursos también crea la necesidad de asegurarse de
que los recursos estén configurados de forma segura y de que se supervisan activamente.
Estas nuevas funcionalidades ofrecen nuevas posibilidades, pero para obtener valor de ellas es necesario
asignar la responsabilidad de su uso. La ejecución coherente de las operaciones de la nube en constante
evolución requiere también mantener los procesos humanos lo más simples y automatizados posible. Consulte
el principio de seguridad "Impulso de la simplificación".
NOTE
El objetivo de la simplificación y la automatización no consiste en deshacerse de los trabajos, sino en quitar a las personas
la carga que suponen las tareas repetitivas para que puedan centrarse en actividades humanas de mayor valor, como la
interacción con los equipos de TI y DevOps, y la instrucción de estos.
Quién : esto se divide normalmente en dos conjuntos de responsabilidades:

Administración de la posición de seguridad : esta función reciente suele ser una evolución de las
funciones ya existentes de administración de vulnerabilidades o de gobernanza. Esto incluye la
supervisión de la posición de seguridad general mediante la puntuación de seguridad de Azure Security
Center y otros orígenes de datos, la colaboración activa con los propietarios de los recursos para mitigar
los riesgos y el informe sobre los riesgos para la dirección del equipo de seguridad.
Corrección de seguridad: asigne la responsabilidad de hacer frente a estos riesgos a los equipos
responsables de administrar esos recursos. Estos equipos pueden ser los equipos de DevOps que
administran sus propios recursos de aplicaciones o los equipos de tecnologías específicas del
departamento de Operaciones de TI central :
Recursos de procesos y aplicaciones:
App Ser vices : equipos de desarrollo de aplicaciones y seguridad
Contenedores : equipos de desarrollo de aplicaciones y operaciones de infraestructura o TI
Máquinas vir tuales, conjuntos de escalado y proceso : equipos de operaciones de TI y de
infraestructura
Recursos de datos y almacenamiento:
SQL/Redis/Data Lake Analytics/Data Lake Store : equipo de bases de datos
Cuentas de almacenamiento : equipo de almacenamiento e infraestructura
Identificación y acceso a los recursos:
Suscripciones : equipos de identidad
Key Vault : equipos de identidades o de seguridad de la información y los datos
Recursos de redes : equipo de seguridad de la red
Seguridad de IoT : equipo de operaciones de IoT
Cómo : la seguridad es responsabilidad de todos, pero no todo el mundo sabe lo importante que es, qué hacer y
cómo hacerlo.
Haga responsables a los propietarios de los recursos del riesgo de seguridad, al igual que ya lo hace con
otros factores de éxito como la disponibilidad, el rendimiento, los costos, etc.
Proporcione a los propietarios de los recursos una visión clara de por qué el riesgo de seguridad es
importante para sus recursos, qué deben hacer para mitigar los riesgos y cómo realizar la implementación
con una pérdida de productividad mínima.
IMPORTANT
Las explicaciones sobre por qué, qué y cómo proteger los recursos suelen ser similares para los diferentes tipos de
recursos y aplicaciones, pero es fundamental relacionarlos con lo que cada equipo ya conoce y de lo que ya se ocupa. Los
equipos de seguridad deben interactuar con sus colegas de TI y DevOps como asesores y asociados de confianza
centrados en permitir que estos equipos funcionen correctamente.
Herramientas : La puntuación segura de Azure Security Center proporciona una evaluación de la información
de seguridad más importante de Azure para una amplia variedad de recursos. Este debe ser el punto de partida
en la administración de la posición y se puede complementar con directivas de Azure personalizadas y otros
mecanismos según sea necesario.
Frecuencia : Establezca una cadencia regular (normalmente mensual) para revisar la puntuación segura de
Azure y planear iniciativas con objetivos de mejora específicos. La frecuencia se puede aumentar según sea
necesario.
TIP
Ludifique la actividad si es posible para aumentar el compromiso, con actividades como la creación de divertidas
competiciones y premios para el equipo de DevOps que les permitan mejorar su puntuación al máximo.
Consulte también la prueba comparativa de seguridad de Azure GS-2: Definición de la estrategia de

administración de la posición de seguridad.
6. Tecnología: Requerir autenticación sin contraseña o multifactor

¿Pondrías la mano en el fuego afirmando en relación con la seguridad de tu empresa que los atacantes no
podrán adivinar ni robar la contraseña del administrador?
Qué : exija que todos los administradores de impacto crítico usen la autenticación sin contraseña o la
autenticación multifactor (MFA).
Por qué : del mismo modo que las antiguas llaves maestras no servirán para proteger una casa de los ladrones
de hoy en día, las contraseñas no pueden proteger las cuentas contra los ataques comunes que se producen en
la actualidad. Los detalles técnicos se describen en Su Contra$eña no importa.
Aunque la autenticación multifactor fue en su día un pesado paso adicional, los enfoques de acceso sin
contraseña de hoy en día mejoran la experiencia de inicio de sesión mediante enfoques biométricos como el
reconocimiento facial en Windows Hello y en los dispositivos móviles (en los que no es necesario recordar ni
escribir una contraseña). Además, los enfoques de confianza cero recuerdan los dispositivos de confianza, lo
cual reduce la solicitud de costosas acciones de autenticación multifactor fuera de banda (consulte la frecuencia
de inicio de sesión).
Quién : las iniciativas de contraseña y autenticación multifactor suelen llevarlas a cabo normalmente los equipos
de Administración de identidades y claves y de Arquitectura de seguridad.
Patrocinio: esto normalmente lo patrocina el Director de seguridad de la información, el Director
tecnológico o el Director del equipo de identidad.
Ejecución: este es un esfuerzo colaborativo que involucra
Al equipo de Directivas y estándares para establecer unos requisitos claros
A los equipos de Administración de identidades y claves o Operaciones de TI central para implementar
las directivas
Al equipo de Administración del cumplimiento de la seguridad para garantizar el cumplimiento
normativo
Cómo : implemente la autenticación sin contraseña o la autenticación multifactor, instruya a los administradores
sobre cómo usarlas (según sea necesario) y haga que los administradores utilicen las directivas escritas. Esto
puede lograrse mediante una o varias de estas tecnologías:
Sin contraseña (Windows Hello)
Sin contraseña (aplicación de autenticación)
Azure Multifactor Authentication
Solución de autenticación multifactor de terceros
NOTE
Hoy en día es relativamente sencillo que los atacantes logren sortear una autenticación multifactor basada en mensajes
de texto, por lo que deberá centrarse en la autenticación sin contraseña o en una autenticación multifactor más sólida.
Consulte también la prueba comparativa de seguridad de Azure ID-4: Uso de controles con autenticación
multifactor sólida para todo el acceso basado en Azure Active Directory.
7. Tecnología: Integración del firewall nativo y la seguridad de red

Simplifique la protección de los sistemas y los datos frente a ataques de red.
Qué : simplifique la estrategia de seguridad de red y el mantenimiento mediante la integración de Azure
Firewall, el firewall de aplicaciones web de Azure y las mitigaciones de denegación de servicio distribuido
(DDoS) en el enfoque de seguridad de la red.
Por qué : la simplicidad es fundamental para la seguridad, ya que reduce la probabilidad de confusión,
configuraciones erróneas y otros errores humanos. Consulte el principio de seguridad "Impulso de la
simplificación".
Los firewalls y los firewalls de aplicaciones web son controles de seguridad básicos importantes para proteger
las aplicaciones frente a tráfico malintencionado, pero su configuración y mantenimiento pueden ser complejos
y consumen una cantidad significativa de tiempo y atención por parte del equipo de seguridad (se parece a la
incorporación de repuestos posventa personalizados a un automóvil). Las funcionalidades nativas de Azure
pueden simplificar la implementación y el funcionamiento de los firewalls, firewalls de aplicaciones web,
mitigaciones de denegación de servicio distribuido, etc.
Esto permite liberar parte del tiempo y la atención del equipo para dedicarlos a tareas de seguridad de mayor
valor, como la evaluación de la seguridad de los servicios de Azure, la automatización de las operaciones de
seguridad y la integración de la seguridad con las aplicaciones y soluciones de TI.
Quién :
Patrocinio: esta actualización de la estrategia de seguridad de la red suele estar patrocinada por la
dirección de los equipos de Seguridad y de TI
Ejecución: la integración en su estrategia de seguridad de red en la nube es un esfuerzo colaborativo
que involucra:
Al equipo de Arquitectura de seguridad para establecer la arquitectura de seguridad de la red en la
nube con los responsables de la red en la nube y de la seguridad de esta.
Responsables de la red en la nube (Operaciones de TI central) + responsables de Seguridad
de la red en la nube (equipo de Seguridad de la infraestructura)
Establecimiento de la arquitectura de seguridad de la red en la nube con arquitectos de
seguridad
Configuración de firewalls, grupos de seguridad de red y firewalls de aplicaciones web y
colaboración con los arquitectos de aplicaciones en las reglas del firewall de aplicaciones web
Arquitectos de aplicaciones: trabaje con el equipo de seguridad de la red para crear y adaptar los
conjuntos de reglas del firewall de aplicaciones web y las configuraciones de DDoS para proteger la
aplicación sin interrumpir la disponibilidad
Cómo : las organizaciones que buscan simplificar sus operaciones tienen dos opciones:
Ampliar las funcionalidades y arquitecturas existentes: a menudo, muchas organizaciones optan por
ampliar el uso de las funcionalidades de firewall existentes para aprovechar las inversiones existentes en la
integración de aptitudes y procesos, especialmente cuando adoptan la nube por primera vez.
Adoptar controles de seguridad nativos: cada vez más organizaciones prefieren usar controles nativos
para evitar la complejidad de la integración con funcionalidades de terceros. Normalmente, estas
organizaciones buscan evitar el riesgo de que se produzca una configuración errónea en el equilibrio de
carga, las rutas definidas por el usuario, el firewall o firewall de aplicaciones web en sí y el riesgo de retrasos
en las entregas entre los diferentes equipos técnicos. Esta opción es especialmente atractiva para las
organizaciones que adoptan enfoques de infraestructura como código, ya que pueden automatizar e
instrumentar las funcionalidades integradas más fácilmente que las funcionalidades de terceros.
Se puede encontrar documentación sobre las funcionalidades de seguridad nativas de Azure en:
Azure Firewall
Firewall de aplicaciones web (WAF) de Azure
Azure DDoS Protection
Azure Marketplace incluye muchos proveedores de firewall de terceros.
Consulte también la prueba comparativa de seguridad de Azure NS-4: Protección de las aplicaciones y servicios
de ataques de redes externas.
8. Tecnología: Integración de la detección de amenazas nativa

Simplifique la detección y respuesta a los ataques contra los sistemas y datos de Azure.
Qué : simplifique la detección de amenazas y la estrategia de respuesta mediante la incorporación de
funcionalidades de detección de amenazas nativas en las operaciones de seguridad y en Administración de
eventos e información de seguridad.
Por qué : el propósito de las operaciones de seguridad es reducir el impacto de los atacantes activos que
acceden al entorno, medido según el tiempo medio de confirmación (MTTA) y de corrección (MTTR) de los
incidentes. Esto requiere precisión y velocidad en todos los elementos del proceso de respuesta a incidentes, por
lo que la calidad de las herramientas y la eficacia de la ejecución del proceso son primordiales.
Es difícil obtener detecciones de amenazas de alto nivel mediante las herramientas y enfoques existentes
diseñados para la detección de amenazas en el entorno local debido a las diferencias con la tecnología de la
nube y su rápido ritmo de cambio. Las detecciones integradas de forma nativa proporcionan soluciones a escala
industrial mantenidas por los proveedores en la nube que pueden hacer frente a las amenazas y los cambios
actuales de la plataforma en la nube.
Estas soluciones nativas también permiten a los equipos de operaciones de seguridad centrarse en la
investigación y la corrección de incidentes en lugar de perder tiempo intentando crear alertas a partir de datos
de registro desconocidos, herramientas de integración y tareas de mantenimiento.
Quién : normalmente, este proceso lo dirige el equipo de Operaciones de seguridad.
Patrocinio: este proceso suele estar patrocinado por el director de Operaciones de seguridad (o
equivalente).
Ejecución: la integración de la detección de amenazas nativa es un esfuerzo colaborativo que involucra a:
Operaciones de seguridad: integre alertas en los procesos de Administración de eventos e
información de seguridad y en los de investigación de incidentes, instruya a los analistas sobre las
alertas en la nube y su significado, y en el uso de las herramientas nativas en la nube.
Preparación para incidentes : integre incidentes de la nube en ejercicios prácticos y asegúrese de
que estos se lleven a cabo para impulsar la preparación del equipo.
Inteligencia sobre amenazas : investigue e integre la información sobre ataques en la nube para
proporcionar a los equipos contexto e inteligencia.
Arquitectura de seguridad : integre las herramientas nativas en la documentación de la
arquitectura de seguridad.
Directiva y estándares : establezca estándares y directivas para habilitar las herramientas nativas en
toda la organización. Supervise el cumplimiento.
Infraestructura y puntos de conexión / Operaciones de TI central : configure y habilite
detecciones, e intégrelas en la automatización y la infraestructura como soluciones de código.
Cómo : permita la detección de amenazas en Azure Security Center para todos los recursos que usa y haga que
cada equipo integre estos en sus procesos como se describió anteriormente.
Consulte también la prueba comparativa de seguridad de Azure LT-1: Permitir la detección de amenazas para
recursos de Azure.
9. Arquitectura: Unificación en un único directorio e identidad

A nadie le gusta tratar con varias identidades y directorios.
Qué : unifique en un solo directorio e identidad de Azure AD cada aplicación y usuario de Azure (para todas las
funciones de identidad de la empresa).
NOTE
Este procedimiento recomendado se refiere específicamente a los recursos de empresa. En el caso de las cuentas de
asociados, use Azure AD B2B de modo que no tenga que crear y mantener cuentas en el directorio. En el caso de las
cuentas de clientes o ciudadanos, use Azure AD B2C para administrarlas.
Por qué : varias cuentas y directorios de identidad crean una fricción y confusión innecesarias en los flujos de
trabajo diarios de los usuarios de producción, desarrolladores, administradores de TI y de identidad, analistas de
seguridad y otros roles.
La administración de varias cuentas y directorios también conlleva unos procedimientos de seguridad
deficientes, como la reutilización de la misma contraseña en todas las cuentas, y aumenta la probabilidad de
cuentas obsoletas o abandonadas a las que los atacantes pueden dirigirse.
Aunque a veces parece más fácil crear rápidamente un directorio personalizado (basado en LDAP, etc.) para una
aplicación o carga de trabajo determinada, esto genera más trabajo de integración y mantenimiento que
configurar y administrar. Esto tiene bastantes similitudes con la decisión de configurar un inquilino de Azure
adicional o bosques adicionales locales de Active Directory en lugar de usar la empresa existente. Consulte
también el principio de seguridad "Impulso de la simplificación".
Quién : esto suele ser un esfuerzo conjunto que controlan los equipos de Arquitectura de seguridad o
Administración de identidades y claves.
Patrocinio: este esfuerzo normalmente es patrocinado por los equipos de Administración de identidades y
claves y Arquitectura de seguridad (aunque algunas organizaciones pueden requerir el patrocinio del
Director de seguridad de la información o el Director tecnológico).
Ejecución: este es un esfuerzo colaborativo que involucra:
Arquitectura de seguridad : incorpora documentos y diagramas en los procedimientos de
seguridad y la arquitectura de TI
Directiva y estándares : documenta las directivas y supervisa el cumplimiento
Al equipo de Administración de identidades y claves o al de Operaciones de TI centrales para
que implemente la directiva habilitando las características y apoyando a los desarrolladores con
cuentas, formación, etc.
A los desarrolladores de aplicaciones y al equipo de Operaciones de TI central : usan las
identidades en aplicaciones y configuraciones de servicios de Azure (las responsabilidades variarán en
función del nivel de adopción de DevOps)
Cómo : adopte un enfoque práctico que comience por las nuevas funcionalidades greenfield (que están
surgiendo en la actualidad) y solucione los desafíos que surjan con las aplicaciones y servicios existentes
brownfield como ejercicio de seguimiento:
Nuevas: establezca e implemente una directiva clara en la que todas las identidades de empresa usen, de
ahora en adelante, un solo directorio de Azure AD con una sola cuenta para cada usuario.
Existentes: muchas organizaciones suelen tener varios directorios y sistemas de identidad heredados.
Tendrá que dar una solución a estas si el costo de las fricciones de su administración continua superan al
de la inversión necesaria para eliminarlas. Aunque las soluciones de administración de identidades y
sincronización pueden mitigar algunos de estos problemas, carecen de una integración profunda de las
características de seguridad y productividad que permitan una experiencia sin problemas para los
usuarios, administradores y desarrolladores.
El momento ideal para consolidar el uso de la identidad es durante los ciclos de desarrollo de aplicaciones ya
que puede:
Modernizar las aplicaciones para la nube
Actualizar las aplicaciones en la nube con procesos de DevOps
Aunque existen motivos válidos para un directorio independiente en el caso de unidades de negocio
extremadamente independientes o requisitos normativos, en todas las demás circunstancias se debe evitar el
uso de varios directorios.
Consulte también la prueba comparativa de seguridad de Azure ID-1: Unificación en Azure Active Directory
como sistema central de identidad y autenticación.
IMPORTANT
La única excepción a la regla de cuentas únicas es que los usuarios con privilegios elevados (incluidos los administradores
de TI y los analistas de seguridad) deben tener cuentas independientes para tareas de usuario estándar y tareas
administrativas.
Para más información, consulte la prueba comparativa de seguridad de Azure Acceso con privilegios.
10. Arquitectura: Uso del control de acceso basado en identidades (en

lugar de claves)
Qué : use identidades de Azure AD en lugar de la autenticación basada en claves siempre que sea posible
(servicios de Azure, aplicaciones, API, etc.).
Por qué : la autenticación basada en claves se puede usar para autenticarse en servicios en la nube y en API,
pero requiere administrar las claves de forma segura, lo que supone una dificultad para lograr un buen
rendimiento (especialmente a escala). La administración de claves segura es complicada para los profesionales
no relacionados con la seguridad, como desarrolladores y profesionales de la infraestructura y, a menudo, no lo
hacen de forma segura, lo cual supone riesgos de seguridad importantes para la organización.
La autenticación basada en identidades ayuda a superar muchos de estos problemas con funcionalidades
consolidadas de rotación de secretos, administración del ciclo de vida, delegación administrativa, etc.
Quién : esto suele ser un esfuerzo conjunto que controlan los equipos de Arquitectura de seguridad o
Administración de identidades y claves.
Patrocinio: este esfuerzo lo suelen patrocinar los equipos de Arquitectura de seguridad o Administración de
identidades y claves (aunque algunas organizaciones pueden requerir el patrocinio del Director de seguridad
de la información o el Director tecnológico).
Ejecución: este es un esfuerzo colaborativo que involucra
Arquitectura de seguridad : incorpora documentos y diagramas en los procedimientos de
seguridad y arquitectura de TI.
Directiva y estándares : documenta las directivas y supervisa el cumplimiento.
Al equipo de Administración de identidades y claves o al de Operaciones de TI centrales para
que implemente la directiva habilitando las características y apoyando a los desarrolladores con
cuentas, formación, etc.
A los desarrolladores de aplicaciones y al equipo de Operaciones de TI central : usan las
identidades en aplicaciones y configuraciones de servicios de Azure (las responsabilidades variarán en
función del nivel de adopción de DevOps).
Cómo : el establecimiento de una preferencia organizativa y un hábito para usar la autenticación basada en
identidades requiere seguir un proceso y habilitar la tecnología necesaria.
El proceso:
1. Establezca directivas y normas que describan claramente la autenticación predeterminada basada en
identidades, así como las excepciones aceptables.
2. Instruya a los equipos de desarrolladores e infraestructura sobre el por qué del uso del nuevo enfoque, qué
tienen que hacer y cómo lo tienen que hacer.
3. Implemente los cambios de forma práctica, empezando por las nuevas funcionalidades que se adoptan
ahora y en el futuro (nuevos servicios de Azure, nuevas aplicaciones) y, después, por una limpieza de las
configuraciones ya existentes.
4. Super vise el cumplimiento y haga un seguimiento con los equipos de desarrolladores y de infraestructura
para corregir los posibles problemas.
Las tecnologías: En el caso de cuentas no humanas como las de servicios o automatización, use identidades
administradas. Las identidades administradas de Azure le permiten autenticarse en los servicios y recursos de
Azure que admiten la autenticación de Azure AD. La autenticación se habilita mediante reglas de concesión de
acceso predefinidas que permiten evitar las credenciales codificadas de forma rígida en los archivos de código
fuente o de configuración.
En el caso de los servicios que no admiten identidades administradas, use Azure AD para crear entidades de
servicio con permisos restringidos en el nivel de recurso. Se recomienda configurar entidades de servicio con
credenciales de certificado y revertir a secretos de cliente. En ambos casos, Azure Key Vault se puede usar junto
con las identidades administradas de Azure, de modo que el entorno en tiempo de ejecución (por ejemplo, una
función de Azure) pueda recuperar la credencial del almacén de claves.
Consulte también la prueba comparativa de seguridad de Azure ID-2: Administración de identidades de
aplicaciones de forma segura y automática.
11. Arquitectura: Establecimiento de una estrategia de seguridad

unificada
Es necesario que todos remen en la misma dirección para que el barco avance.
Qué : asegúrese de que todos los equipos estén en línea con una sola estrategia que habilite y proteja los datos
y los sistemas empresariales.
Por qué : cuando los equipos trabajan de forma aislada sin estar alineados con una estrategia común, sus
acciones individuales pueden perjudicar involuntariamente a los esfuerzos de otros, creando una fricción
innecesaria que reduce el progreso de los objetivos de todos.
Un ejemplo de esto que se ha reproducido de forma constante en muchas organizaciones es la segmentación de
recursos:
El equipo de seguridad de red desarrolla una estrategia para segmentar una red plana para aumentar la
seguridad (a menudo basándose en sitios físicos, direcciones IP o intervalos asignados, etc.)
Por separado, el equipo de identidad ha desarrollado una estrategia para grupos y unidades organizativas de
Active Directory en función de sus conocimientos de la organización.
A los equipos de aplicaciones a menudo les resulta difícil trabajar con estos sistemas porque se diseñaron
con una información y un conocimiento de las operaciones, objetivos y riesgos empresariales limitados.
En las organizaciones en las que esto ocurre, los equipos experimentan con frecuencia conflictos en las
excepciones de firewall, lo cual afecta negativamente a la seguridad (las excepciones normalmente se aprueban)
y a la productividad (la implementación se ralentiza para la funcionalidad de la aplicación y las necesidades
empresariales).
Aunque la seguridad puede crear una fricción positiva al forzar el pensamiento crítico, este conflicto solo crea
una fricción negativa que impide la consecución de los objetivos. Para más información, consulte Guía de
estrategias de seguridad: El nivel adecuado de fricción de seguridad.
Quién :
Patrocinio: la estrategia unificada suele estar patrocinada de forma conjunta por el Director de seguridad de
la información y el Director tecnológico (a menudo con el respaldo de la dirección de la empresa para
determinadas cuestiones de alto nivel) y apoyadas por los miembros de cada equipo.
Ejecución: la estrategia de seguridad debe ser implementada por todos, por lo que debe integrar datos de
todos los equipos para aumentar la responsabilidad, la participación y la probabilidad de éxito.
Arquitectura de seguridad : lidera el esfuerzo de crear la estrategia de seguridad y la arquitectura
resultante, recopilar activamente los comentarios de los equipos y documentarlos en presentaciones,
documentos y diagramas para las distintas audiencias.
Directiva y estándares : reflejan los elementos adecuados en estándares y directivas y, a
continuación, supervisan su cumplimiento.
Todos los equipos técnicos de TI y de seguridad: proporcionan los requisitos de información y, a
continuación, se alinean con la estrategia empresarial y la implementan.
Propietarios y desarrolladores de aplicaciones: leen y comprenden la documentación
estratégica que les es aplicable (idealmente, reciben una guía adaptada a su rol).
Cómo :
cree e implemente una estrategia de seguridad para la nube que incluya la información y la participación activa
de todos los equipos. Aunque el formato de la documentación del proceso varíe, esta siempre debe incluir:
Información activa de los equipos: se suelen producir errores en las estrategias si los miembros de la
organización no participan en ellas. Lo ideal sería reunir a todos los equipos para que creen la estrategia de
forma colaborativa. En los talleres que llevamos a cabo con los clientes, a menudo encontramos que las
organizaciones han estado funcionando en silos de facto y estas reuniones suelen dar lugar a personas que
se reúnen entre sí por primera vez. También encontramos que la inclusión es un requisito. Si algunos equipos
no están invitados, normalmente se tiene que repetir la reunión hasta que todos los participantes se unan (o
el proyecto no avanzará).
Documentación y comunicaciones claras: todos los equipos deben conocer la estrategia de seguridad
(idealmente, un componente de seguridad de la estrategia global tecnológica), lo cual incluya el motivo de la
integración de la seguridad, qué es importante en relación con la seguridad y cómo se mide el éxito de la
seguridad. Esto debe incluir instrucciones específicas para los equipos de aplicaciones y desarrollo, de modo
que puedan obtener orientaciones con prioridades claras sin tener que leer las partes no pertinentes de la
guía.
Estable, pero flexible: las estrategias deben ser relativamente coherentes y estables, pero puede que las
arquitecturas y la documentación necesiten cambios para aportar claridad y dar cabida a la naturaleza
dinámica de la nube. Por ejemplo, el filtrado de tráfico externo malintencionado permanecerá coherente
como un imperativo estratégico incluso si cambia de un firewall de próxima generación de terceros a un
firewall de Azure y ajusta los diagramas o instrucciones sobre cómo hacerlo.
Empezar por la segmentación: en el transcurso de la adopción de la nube, los equipos abordarán muchos
temas de estrategia grandes y pequeños, pero debe empezar por alguna parte. Se recomienda iniciar la
estrategia de seguridad con la segmentación de los recursos de la empresa, ya que se trata de una decisión
fundamental que sería difícil de cambiar más adelante y requiere tanto la información empresarial como la
de muchos equipos técnicos.
Microsoft ha publicado instrucciones en vídeo sobre cómo aplicar una estrategia de segmentación a Azure así
como documentos sobre segmentación empresarial y alineación de la seguridad de red con ella.
Cloud Adoption Framework incluye instrucciones para ayudar a los equipos con:
Creación de un equipo de estrategia en la nube : idealmente, la seguridad debe integrarse en una
estrategia en la nube existente.
Creación o modernización de una estrategia de seguridad : para satisfacer los objetivos empresariales
y de seguridad en la situación actual de los servicios en la nube y las amenazas modernas.
Consulte también la prueba comparativa de seguridad de Azure Gobernanza y estrategia.
Guías de decisiones sobre arquitectura
Las guías de decisiones sobre arquitectura de Cloud Adoption Framework describen patrones y modelos que
ayudan a crear la guía de diseño de la gobernanza de la nube. Cada una de estas guías se centra en un
componente principal de la infraestructura de las implementaciones en la nube y enumera los patrones y
modelos que pueden admitir escenarios concretos de implementación en la nube.
Al empezar a establecer la gobernanza de la nube en una organización, los procesos de gobernanza que
requieren acciones ofrecen una hoja de ruta de la base de referencia. Estos recorridos realizan suposiciones
acerca de los requisitos y prioridades que puede que no reflejen los de su organización.
Estas guías de decisiones complementan los recorridos de gobernanza de ejemplo, ya que proporcionan
patrones y modelos alternativos que le ayudan a alinear las opciones de diseño de arquitectura realizadas en la
guía de diseño de ejemplo con sus propios requisitos.
Categorías de guía en la toma de decisiones

Las siguientes categorías representan una tecnologías fundamentales en todas las implementaciones en la nube.
Los recorridos de gobernanza de ejemplo toman decisiones de diseño relacionadas con estas tecnologías en
función de las necesidades de los negocios del ejemplo y es posible que algunas de estas decisiones no coincida
con las de su organización. En las secciones siguientes se describen opciones alternativas para cada categoría, lo
que permite elegir el patrón o modelo que mejor se adapte a las necesidades de cada uno.
Suscripciones: planee la estructura de cuentas y el diseño de la suscripción de la implementación en la nube
para ajustarlos a la propiedad, facturación y funcionalidades de administración de su organización.
Identidad: integre los servicios de identidad basados en la nube en los recursos de identidad existentes para
poder usar la autorización y el control de acceso en su entorno de TI.
Aplicación de directivas: defina y aplique las reglas de la directiva de la organización para los recursos
implementados en la nube y las cargas de trabajo que se alinean con los requisitos de gobernanza.
Coherencia de recursos: asegúrese de que se alinean la implementación y la organización de los recursos
basados en la nube para exigir los requisitos de directiva y administración de recursos.
Etiquetado de recursos: organice los recursos basados en la nube para que admitan los modelos de facturación,
los enfoques de contabilidad en la nube y la administración, y para la utilización de recursos y su costo. El
etiquetado de recursos requiere un esquema de metadatos y de nomenclatura coherente y bien organizado.
Red definida por software: implemente cargas de trabajo seguras en la nube mediante una implementación
rápida y la modificación de las funcionalidades de redes virtuales. Las redes definidas por software pueden
admitir flujos de trabajo ágiles, aislar los recursos e integrar sistemas en la nube en la infraestructura de TI
existente.
Cifrado: proteja la información confidencial para adecuarse a los requisitos de la directiva de seguridad y
cumplimiento de su organización.
Registro e informes: supervise los datos de registro generados por los recursos en la nube. El análisis de los
datos, proporciona información relacionada con el estado de las operaciones, el mantenimiento y el estado de
cumplimiento de las cargas de trabajo.
Pasos siguientes
Obtenga información acerca de cómo tanto las suscripciones como las sirven como base de una
Diseño de suscripciones
Guía de decisiones de suscripción
Un diseño eficaz de las suscripciones ayuda a las organizaciones a establecer una estructura para organizar y
administrar los recursos de Azure durante un proceso de adopción de la nube. Esta guía le ayudará a decidir
cuándo debe crear suscripciones adicionales y expandir la jerarquía de grupos de administración para dar apoyo
a sus prioridades empresariales.
Requisitos previos
La adopción de Azure comienza con la creación de una suscripción, la asociación a una cuenta y la
implementación de recursos tales como máquinas virtuales y bases de datos en la suscripción. Para una
introducción sobre estos conceptos, consulte Conceptos básicos de Azure.
Cree las suscripciones iniciales.
Cree suscripciones adicionales para escalar el entorno de Azure.
Organice y administre sus suscripciones mediante grupos de administración de Azure.
Creación de un modelo de organización

Como cada organización es diferente, los grupos de administración de Azure están diseñados para ser flexibles.
El modelado de su entorno en la nube para reflejar la jerarquía de la organización le ayuda a definir y aplicar
directivas en los niveles más altos de la jerarquía, y a confiar en la herencia para asegurarse de que esas
directivas se aplicarán automáticamente a los grupos de administración situados más abajo. Aunque las
suscripciones se pueden mover entre diferentes grupos de administración, resulta útil diseñar una jerarquía
inicial de grupos de administración que refleje sus necesidades organizativas de forma anticipada.
Antes de finalizar el diseño de la suscripción, considere cómo las decisiones sobre la coherencia de recursos
pueden influir en las opciones de diseño.
NOTE
Un Contrato Enterprise (EA) de Azure le permite definir otra jerarquía organizativa con fines de facturación. Esta jerarquía
es distinta de la jerarquía del grupo de administración, que se centra en proporcionar un modelo de herencia para aplicar
fácilmente directivas adecuadas y control de acceso a los recursos.
Estrategias de diseño de suscripciones

Tenga en cuenta las siguientes estrategias de diseño de suscripciones para dar respuesta a sus prioridades
empresariales.
Estrategia de separación de cargas de trabajo
A medida que una organización agrega nuevas cargas de trabajo a la nube, las diferentes propiedades de las
suscripciones o una separación básica de las responsabilidades puede resultar en varias suscripciones en los
grupos de administración de producción y de no producción. Aunque este enfoque proporciona una separación
básica de cargas de trabajo, no aprovecha de manera significativa el modelo de herencia a la hora de aplicar
automáticamente directivas en un subconjunto de las suscripciones.
Estrategia de categoría de aplicación
A medida que crece la superficie en la nube de la organización se crean normalmente suscripciones para admitir
aplicaciones que tienen diferencias fundamentales con respecto a importancia para la empresa, requisitos de
cumplimiento, controles de acceso o necesidades de protección de datos. En las suscripciones de producción y
de no producción, las suscripciones que admiten estas categorías de aplicaciones se organizan en el grupo de
administración de producción o de no producción según corresponda. Normalmente, el personal de
operaciones de los equipos de TI centrales no solo es quien posee estas suscripciones, sino también quien las
administra.
Cada organización categorizará las aplicaciones de forma diferente, a menudo separarán las suscripciones
basadas en aplicaciones o servicios específicos o en arquetipos de aplicación. Esta categorización a menudo está
diseñada para admitir cargas de trabajo que es probable que consuman la mayor parte de los límites de
recursos de una suscripción, o bien cargas de trabajo críticas independientes, con el fin de asegurarse de que no
compiten con otras cargas de trabajo dentro de estos límites. Entre las cargas de trabajo que pueden justificar
una suscripción independiente se incluyen:
Cargas de trabajo críticas.
Aplicaciones que forman parte del coste de bienes vendidos (COGS) dentro de la empresa. Por ejemplo,
todos los widgets fabricados por una empresa contienen un módulo de Azure IoT que envía datos de
telemetría. Esto puede requerir una suscripción dedicada para fines de contabilidad o gobernanza como
parte del COGS.
Aplicaciones sujetas a requisitos legales (como HIPAA o FedRAMP).
Estrategia funcional
La estrategia funcional organiza las suscripciones y cuentas a lo largo de líneas funcionales como finanzas,
ventas o soporte técnico de TI, mediante una jerarquía de grupos de administración.
Estrategia de la unidad de negocio
Esta estrategia agrupa las suscripciones y cuentas en función de categorías de pérdidas y ganancias, unidades
de negocio, divisiones, centros de beneficios o estructuras empresariales similares mediante una jerarquía de
Estrategia geográfica
Para organizaciones con operaciones globales, la estrategia geográfica agrupa las suscripciones y cuentas en
función de las regiones geográficas mediante una jerarquía de administración de grupos.
Estrategias de suscripciones mixtas

Las jerarquías de los grupos de administración pueden incluir hasta seis niveles de profundidad. Esto le
proporciona flexibilidad para crear una jerarquía que combina varias de estas estrategias para satisfacer sus
necesidades organizativas. Por ejemplo, el diagrama siguiente muestra una jerarquía organizativa que combina
una estrategia de unidad empresarial con una estrategia geográfica.
Varias capas de gobernanza en grandes empresas
Varias regiones geográficas
Pasos siguientes
El diseño de suscripciones es solo uno de los principales componentes de infraestructura que requieren
decisiones de arquitectura durante un proceso de adopción de la nube. Visite la introducción a las guías para la
toma de decisiones arquitectónicas para más información sobre las estrategias adicionales que se usan al tomar
decisiones de diseño para otros tipos de infraestructura.
Guía de decisión de identidad
En cualquier entorno, ya sea local, híbrido, o solo en la nube, el departamento de TI necesita controlar qué
administradores, usuarios y grupos tienen acceso a los recursos. Los servicios de Administración de identidad y
acceso (IAM) le permiten administrar el control de acceso en la nube.
Vaya a: Determinación de los requisitos de integración de identidades | Base de referencia en la nube |

Sincronización de directorios | Servicios de dominios hospedados en la nube | Servicios de federación de
Active Directory (AD FS) | Más información
Hay varias opciones disponibles para administrar la identidad en un entorno en la nube. Estas opciones varían
en cuanto a costo y complejidad. Un factor decisivo para estructurar los servicios de identidad basados en la
nube es el nivel de integración necesario con la infraestructura de identidad local existente.
Azure Active Directory (Azure AD) proporciona un nivel básico de control de acceso y administración de
identidades para los recursos de Azure. Si la infraestructura de Active Directory local de la organización tiene
una estructura de bosque compleja o unidades organizativas (OU) personalizadas, las cargas de trabajo de la
nube pueden requerir la sincronización de directorios con Azure AD para tener un conjunto coherente de
identidades, grupos y roles entre el entorno local y el de la nube. Además, la compatibilidad con aplicaciones
que dependen de mecanismos de autenticación heredados podría requerir la implementación de
Active Directory Domain Services (AD DS) en la nube.
La administración de identidades basada en la nube es un proceso iterativo. Para la implementación inicial,
podría comenzar con una solución nativa en la nube con un pequeño conjunto de usuarios y sus roles
correspondientes. A medida que madure la migración, es posible que deba integrar la solución de identidades
mediante la sincronización de directorios o agregar servicios de dominios como parte de las implementaciones
de nube. Vuelva a visitar su estrategia de identidad en cada iteración del proceso de migración.
Determinación de los requisitos de integración de identidades

SERVIC IO S DE
DO M IN IO SERVIC IO S DE
L ÍN EA B A SE EN L A SIN C RO N IZ A C IÓ N DE H O SP EDA DO S EN L A F EDERA C IÓ N DE
P REGUN TA N UB E DIREC TO RIO S N UB E A C T IVE DIREC TO RY
¿Actualmente carece Sí No No No
de un servicio de
directorios local?
¿Las cargas de No Sí No No
trabajo necesitan
usar un conjunto
común de usuarios y
grupos entre el
entorno en la nube y
el local?
¿Sus cargas de No No Sí Sí
trabajo dependen de
mecanismos de
autenticación
heredados, como
Kerberos o NTLM?
¿Necesita el inicio de No No No Sí
sesión único entre
varios proveedores
de identidad?
Como parte del planeamiento de la migración a Azure, deberá determinar la mejor manera de integrar sus
servicios actuales de administración de identidad y de identidad en la nube. A continuación presentamos
escenarios de integración comunes.
Línea base en la nube
Azure AD es el sistema de administración de identidades y acceso (IAM) nativo para conceder acceso a los
usuarios y grupos a las características de administración en la plataforma de Azure. Si la organización no tiene
una solución de identidades significativa en el entorno local y planea migrar las cargas de trabajo para que sean
compatibles con los mecanismos de autenticación basados en la nube, debería comenzar a desarrollar la
infraestructura de identidades con Azure AD como base.
Suposiciones de la línea de base en la nube: El uso de una infraestructura de identidad puramente nativo
de la nube asume lo siguiente:
Los recursos basados en la nube no tendrán dependencias de servicios de directorio locales o servidores de
Active Directory o las cargas de trabajo se pueden modificar para eliminar esas dependencias.
Las cargas de trabajo de servicio o aplicación que se están migrando admiten mecanismos de autenticación
compatibles con Azure AD o se pueden modificar fácilmente para admitirlos. Azure AD se basa en
mecanismos de autenticación por Internet como SAML, OAuth y OpenID Connect. Es posible que haya que
refactorizar las cargas de trabajo existentes que dependen de métodos de autenticación heredados que usan
protocolos como Kerberos o NTLM antes de migrarlas a la nube mediante el patrón de línea de base en la
nube.
TIP
Migrar completamente los servicios de identidad a Azure AD elimina la necesidad de mantener su propia infraestructura
de identidades, con lo que se simplifica de manera significativa la administración de los servicios informáticos.
Pero Azure AD no sustituye completamente una infraestructura de Active Directory local tradicional. Es posible que
algunas características de los directorios, como los métodos de autenticación heredados, la administración de equipos o la
directiva de grupos no estén disponibles si no se han implementado previamente herramientas o servicios adicionales en
la nube.
Para escenarios donde es necesario integrar las identidades locales o los servicios de dominio con las implementaciones en
la nube, consulte los patrones de sincronización de directorios y de servicios de dominio hospedados en la nube que se
explican a continuación.
Sincronización de directorios
Para organizaciones con una infraestructura de Active Directory local existente, la sincronización de directorios
suele ser la mejor solución para conservar los usuarios existentes y la administración del acceso
proporcionando al mismo tiempo las funcionalidades de IAM necesarias para administrar recursos en la nube.
Este proceso replica continuamente la información de los directorios entre Azure AD y los servicios de directorio
locales, lo que permite credenciales comunes para los usuarios y un sistema de identidades, roles y permisos
coherente en toda la organización.
NOTE
Es posible que las organizaciones que han adoptado Microsoft 365 ya hayan implementado la sincronización de
directorios entre su infraestructura de Active Directory local y Azure Active Directory.
Suposiciones de sincronización de directorios: Con el uso de una solución de identidad sincronizada se

asume lo siguiente:
Debe mantener un conjunto común de cuentas de usuario y grupos en la nube y la infraestructura de TI local.
Los servicios de identidad locales admiten la replicación con Azure AD.
TIP
Las cargas de trabajo basadas en la nube que dependen de mecanismos de autenticación heredados proporcionados por
servidores de Active Directory locales y que no son compatibles con Azure AD, seguirán necesitando conectividad con
servicios de dominio locales o servidores virtuales en el entorno en la nube que ofrecen estos servicios. El uso de servicios
de identidad locales también presenta las dependencias en la conectividad entre las redes en la nube y local.
Servicios de dominio hospedados en la nube

Si tiene cargas de trabajo que dependan de la autenticación basada en notificaciones, que usen protocolos
heredados como Kerberos o NTLM y que no se puedan refactorizar para que acepten protocolos de
autenticación modernos, como SAML o OAuth y OpenID Connect, es posible que necesite migrar algunos de los
servicios de dominio a la nube como parte de su implementación en la nube.
Este patrón implica la implementación de máquinas virtuales que ejecutan Active Directory en las redes
virtuales basadas en la nube para proporcionar Active Directory Domain Services (AD DS) para los recursos en
la nube. Todas las aplicaciones y servicios existentes que se migran a la red en la nube deben ser capaces de
utilizar estos servidores de directorio hospedados en la nube con modificaciones menores.
Es probable que los directorios y los servicios de dominio existentes sigan usándose en su entorno local. En este
escenario, también debería usar la sincronización de directorios para proporcionar un conjunto común de
usuarios y roles tanto en el entorno local como en la nube.
Suposiciones de ser vicios de dominio hospedados en la nube: La realización de una migración de
directorios asume lo siguiente:
Las cargas de trabajo dependen de la autenticación basada en notificaciones que utilizan protocolos como
Kerberos o NTLM.
Las máquinas virtuales de su carga de trabajo deben estar unidas al dominio para la administración o
aplicación de la directiva de grupo de Active Directory.
TIP
Mientras que una migración de directorios combinada con servicios de dominio hospedados en la nube ofrece una gran
flexibilidad al migrar las cargas de trabajo existentes, el hospedaje de máquinas virtuales dentro de la red virtual en la
nube para proporcionar estos servicios aumenta la complejidad de las tareas de administración de TI. A medida que crezca
su experiencia de migración en la nube, examine los requisitos de mantenimiento a largo plazo del hospedaje de estos
servidores. Considere si la refactorización de cargas de trabajo existentes para ofrecer compatibilidad con proveedores de
identidades en la nube como Azure Active Directory puede reducir la necesidad de estos servidores hospedados en la
nube.
Servicios de federación de Active Directory

La federación de identidades establece relaciones de confianza entre varios sistemas de administración de
identidades para permitir las funciones más comunes de autenticación y autorización. Así, puede admitir
capacidades de inicio de sesión único entre varios dominios dentro de su organización o sistemas de identidad
administrados por los clientes o socios comerciales.
Azure AD admite la federación de dominios de Active Directory locales con los Servicios de federación de
Active Directory (AD FS). Para más información sobre cómo se puede implementar en Azure, consulte Extensión
de AD FS a Azure.
Más información
Para más información acerca de los servicios de identidad en Azure, consulte:
Azure AD . Azure AD proporciona servicios de identidad basados en la nube. Permite administrar el acceso a
sus recursos de Azure y controlar la administración de identidades, el registro de dispositivos, el
aprovisionamiento de usuarios, el control de acceso de la aplicación y la protección de datos.
Azure AD Connect . La herramienta Azure AD Connect le permite conectarse a instancias de Azure AD con
sus soluciones de administración de identidad existentes, permitiendo la sincronización del directorio actual
en la nube.
Control de acceso basado en rol de Azure (Azure RBAC) . Azure RBAC administra de forma eficaz y
segura el acceso a los recursos en el plano de administración. Los trabajos y las responsabilidades se
organizan en roles, y los usuarios se asignan a estos roles. Azure RBAC permite controlar quién tiene acceso
a un recurso, junto con las acciones que un usuario puede realizar en ese recurso.
Azure AD Privileged Identity Management (PIM) . PIM reduce el tiempo de exposición de los privilegios
de acceso de recursos y aumenta la visibilidad de su uso mediante alertas e informes. Limita a los usuarios a
que solo acepten sus privilegios "just-in-time" (JIT) o mediante la asignación de privilegios por un período de
tiempo más corto, tras el cual se revocan automáticamente.
Integración de dominios locales de Active Director y con Azure Active Director y . Esta arquitectura
de referencia proporciona un ejemplo de sincronización de directorios entre los dominios de Active Directory
local y Azure AD.
Extensión de Active Director y Domain Ser vices (AD DS) a Azure . Esta arquitectura de referencia
proporciona un ejemplo de cómo implementar servidores de AD DS para ampliar los servicios de dominio a
los recursos basados en la nube.
Extensión de Ser vicios de federación de Active Director y (AD FS) a Azure . Esta arquitectura de
referencia configura Servicios de federación de Active Directory (AD FS) para realizar la autenticación
federada y la autorización con su directorio Azure AD.
Pasos siguientes
La identidad es solo uno de los principales componentes de infraestructura que requieren decisiones de
arquitectura durante un proceso de adopción de la nube. Para obtener información sobre patrones o modelos
alternativos que se usan cuando se toman decisiones acerca del diseño de otros tipos de infraestructura,
consulte la introducción a las guías para la toma de decisiones arquitectónicas.
Introducción a las guías para la toma de decisiones arquitectónicas
Guía de decisiones sobre el cumplimiento de
directivas
La definición de una directiva de la organización no será eficaz a menos que se pueda aplicar en la organización.
Un aspecto clave a la hora de planear cualquier migración a la nube consiste en determinar la mejor manera de
combinar las herramientas que ofrece la plataforma de nube con los procesos de TI ya existentes para
maximizar el cumplimiento de la directiva en todo el patrimonio de la nube.
Vaya a: Procedimientos recomendados de la base de referencia | Supervisión del cumplimiento de la directiva |

Cumplimiento de la directiva | Directiva para toda la organización | Cumplimiento automatizado
A medida que crece el entorno en la nube, se tendrá que enfrentar con la correspondiente necesidad de
mantener y aplicar las directivas en una amplia matriz de recursos y suscripciones. A medida que el entorno se
amplía y aumentan los requisitos de directivas de la organización, el ámbito de los procesos de cumplimiento de
directivas se debe expandir para garantizar un cumplimiento coherente de la directivas y una detección de
infracciones rápida.
Los mecanismos de cumplimiento de directivas que proporciona la plataforma en el nivel de recurso o en el de
suscripción normalmente son suficientes para entornos en la nube menores. Las implementaciones más
grandes justifican un ámbito de cumplimiento mayor y podrían necesitar aprovechar las ventajas de
mecanismos de cumplimiento más sofisticados que implican estándares de implementación, agrupación de
recursos y organización y la integración del cumplimiento de directivas con los sistemas de registro e informes.
Los principales factores para determinar el ámbito de los procesos de cumplimiento de directivas son los
requisitos de gobernanza en la nube de la organización, el tamaño y la naturaleza del entorno en la nube y
cómo se refleja la organización en el diseño de suscripciones. Un aumento de tamaño del entorno o una mayor
necesidad de administrar de forma centralizada la aplicación de directivas pueden justificar un aumento en el
ámbito del cumplimiento.
Procedimientos recomendados de seguridad

Para una sola suscripción e implementaciones sencillas en la nube, se pueden aplicar muchas directivas
corporativas mediante características que son nativas a los recursos y las suscripciones de Azure. El uso
coherente de los patrones descritos en las guías de decisión de Cloud Adoption Framework puede ayudar a
establecer un nivel de línea de base de cumplimiento de directivas sin inversión específica en cumplimiento de
directivas. Estas características son:
Las plantillas de implementación pueden aprovisionar recursos con una estructura y una configuración
estándar.
El etiquetado y las normas estándar de nomenclatura pueden ayudar a organizar las operaciones y a
respaldar los requisitos empresariales y de contabilidad.
La administración del tráfico y las restricciones de las redes se pueden implementar mediante redes
definidas por software.
El control de acceso basado en rol de Azure puede proteger y aislar los recursos en la nube.
Inicie la planeación del cumplimiento de la directiva de la nube mediante el análisis de cómo la aplicación de los
patrones estándar descritos en estas guías puede ayudarle a cumplir con los requisitos organizativos.
Supervisión del cumplimiento de la directiva

Un primer paso más allá de la simple confianza en los mecanismos de cumplimiento de directivas
proporcionados por la plataforma de Azure es garantizar la posibilidad de comprobar que las aplicaciones y
servicios basados en la nube cumplen con la directiva de la organización. Esto incluye la implementación de
funcionalidades de notificación para alertar a las partes responsables si un recurso no logra el cumplimiento. El
registro y notificación eficaz del estado de cumplimiento de las cargas de trabajo de la nube es una parte
fundamental de una estrategia de cumplimiento de la directiva corporativa.
A medida que crece el patrimonio de la nube, hay herramientas adicionales como Azure Security Center que
ofrecen seguridad y detección de amenazas integrada, y que ayuda a aplicar una administración centralizada de
la directiva y a enviar alertas sobre el estado de los recursos locales y en la nube.
En Azure, también puede aplicar opciones de configuración y reglas de creación de recursos en el nivel de grupo
de administración, suscripción o grupo de recursos para ayudar a garantizar la alineación con las directivas.
Azure Policy es un servicio de Azure para crear, asignar y administrar directivas. Dichas directivas aplican
distintas reglas y efectos a los recursos, con el fin de que estos sigan siendo compatibles con los estándares
corporativos y los acuerdos de nivel de servicio. Azure Policy evalúa los recursos que incumplen las directivas
asignadas. Por ejemplo, puede que desee limitar el tamaño de SKU de las máquinas virtuales del entorno. Tras
implementar la directiva correspondiente, se evalúa el cumplimiento tanto de los recursos nuevos como de los
existentes. Con la directiva correcta, se puede conseguir el cumplimiento de los recursos existentes.
Directiva para toda la organización

A medida que crece su patrimonio en la nube y abarca muchas suscripciones que requieren cumplimiento,
deberá centrarse en una estrategia de cumplimiento que abarque a todo el patrimonio para garantizar la
coherencia de las directivas.
El diseño de las suscripciones debe tener en cuenta la directiva en relación a la estructura organizativa. Además
de ayudar a admitir una organización compleja dentro del diseño de suscripciones, los grupos de
administración de Azure se pueden usar para asignar reglas de Azure Policy en varias suscripciones.
Cumplimiento automatizado
Aunque las plantillas de implementación estándar son eficaces a una escala menor, Azure Blueprints permite un
aprovisionamiento estándar a gran escala y la orquestación de la implementación de las soluciones de Azure.
Las cargas de trabajo de varias suscripciones se pueden implementar con valores de directiva coherentes en
cualquier recurso que se cree.
En entornos de TI que integran recursos locales y en la nube, puede que necesite usar sistemas de registro y
notificación que ofrezcan funcionalidades de supervisión híbridas. Los sistemas de supervisión operativa
personalizados o de terceros pueden ofrecer otras funcionalidades adicionales de cumplimiento de directivas.
Para entornos en la nube mayores o más maduros, analice cómo integrar mejor estos sistemas con los recursos
en la nube.
Pasos siguientes
El cumplimiento de directivas es solo uno de los principales componentes de infraestructura que requieren
toma de decisiones arquitectónicas para obtener información sobre patrones o modelos alternativos que se
usan cuando se toman decisiones de diseño para otros tipos de infraestructura.
Guía de decisiones de la coherencia de recursos
El diseño de suscripciones de Azure define cómo organizar los recursos en la nube en relación con la estructura
de la organización, las prácticas contables y los requisitos de las cargas de trabajo. Además de este nivel de
estructura, abordar los requisitos de directivas de gobernanza organizativa en todo el entorno en la nube
requiere la capacidad de organizar, implementar y administrar los recursos dentro de una suscripción de forma
coherente.
Vaya a: Agrupación básica | Coherencia de implementación | Coherencia de directivas | Coherencia jerárquica |

Coherencia automatizada
Las decisiones relativas al nivel de los requisitos de coherencia de los recursos del entorno en la nube se rigen
principalmente por estos factores: el tamaño del patrimonio digital posterior a la migración, los requisitos del
entorno o del negocio que no encajan claramente dentro de los enfoques de diseño de suscripción existentes o
la necesidad de aplicar gobernanza a lo largo del tiempo una vez implementados los recursos.
Con el aumento de la importancia de estos factores, las ventajas de garantizar la implementación, agrupación y
administración de los recursos basados en la nube de forma coherente se vuelve más importante. Lograr
niveles de coherencia de los recursos más avanzados para satisfacer las crecientes necesidades requiere más
esfuerzo invertido en automatización, herramientas y la aplicación de la coherencia y esto da como resultado
más tiempo invertido en la administración y el seguimiento de cambios.
Agrupación básica
En Azure, los grupos de recursos son un mecanismo principal de organización de recursos para agrupar
lógicamente los recursos dentro de una suscripción.
Los grupos de recursos actúan como contenedores para los recursos con un ciclo de vida común, así como
restricciones de administración compartidas, como los requisitos de la directiva o del control de acceso basado
en rol de Azure (Azure RBAC). Los grupos de recursos no pueden anidarse, y los recursos solo pueden
pertenecer a un solo grupo de recursos. Todas las acciones del plano de control actúan sobre todos los recursos
de un grupo de recursos. Por ejemplo, al eliminar un grupo de recursos, también se eliminan todos los recursos
de ese grupo. El patrón preferido para la administración del grupo de recursos debe tener en cuenta lo
siguiente:
1. ¿Se desarrollan los contenidos del grupo de recursos de forma conjunta?
2. ¿Se administran, actualizan y supervisan de forma conjunta los contenidos del grupo de recursos? ¿Realizan
esas operaciones las mismas personas o equipos?
3. ¿Se retiran los contenidos del grupo de recursos de forma conjunta?
Si respondió no a cualquiera de las preguntas anteriores, el recurso en cuestión debe colocarse en otra parte, en
otro grupo de recursos.
IMPORTANT
Los grupos de recursos también son específicos de cada región; sin embargo, es habitual que los recursos estén en
regiones diferentes, aunque dentro del mismo grupo de recursos, ya que, cómo se indicó anteriormente, se administran
de forma conjunta. Para más información sobre la selección de regiones, consulte Varias regiones.
Coherencia de implementación
Creadas sobre el mecanismo de agrupación de recursos base, la plataforma de Azure proporciona un sistema
para usar plantillas para implementar los recursos en el entorno en la nube. Puede usar plantillas para crear
convenciones de nomenclatura y organización coherentes al implementar cargas de trabajo, reforzando esos
aspectos del diseño de la implementación y la administración de recursos.
Las plantillas de Azure Resource Manager permiten implementar repetidamente los recursos en un estado
coherente mediante una estructura de grupos de recursos y una configuración predeterminada. Las plantillas de
Resource Manager ayudan a definir un conjunto de estándares como punto de partida para las
implementaciones.
Por ejemplo, puede tener una plantilla estándar para la implementación de una carga de trabajo de servidor
web que contiene dos máquinas virtuales como servidores web combinadas con un equilibrador de carga para
distribuir el tráfico entre los servidores. A continuación, puede volver a usar esta plantilla para crear un conjunto
de máquinas virtuales con un equilibrador de carga estructuralmente idénticos cada vez que se necesita este
tipo de carga de trabajo, solo cambiando el nombre de la implementación y las direcciones IP implicadas.
También puede implementar estas plantillas mediante programación e integrarlas con los sistemas de CI/CD.
Coherencia de directivas
Para asegurarse de que se aplican las directivas de gobernanza cuando se crean recursos, parte del diseño de
agrupación de recursos implica el uso de una configuración común al implementar recursos.
Mediante la combinación de grupos de recursos y plantillas de Resource Manager estandarizadas, puede aplicar
estándares para los parámetros que son necesarios en una implementación y las reglas de Azure Policy que se
aplican a cada grupo de recursos o recurso.
Por ejemplo, puede existir el requisito de que todas las máquinas virtuales implementadas dentro de su
suscripción se conecten a una subred común administrada por el equipo de TI central. Puede crear una plantilla
estándar para implementar máquinas virtuales de carga de trabajo para crear un grupo de recursos
independiente para la carga de trabajo e implementar allí las máquinas virtuales necesarias. Este grupo de
recursos tendría una regla de directiva para permitir solo que las interfaces de red dentro del grupo de recursos
se unan a la subred compartida.
Para obtener una explicación más detallada de la aplicación de las decisiones de directiva dentro de una
implementación en la nube, consulte Aplicación de directivas.
Coherencia jerárquica
Los grupos de recursos permiten niveles adicionales de jerarquía dentro de la organización y suscripción,
aplicando reglas de Azure Policy y controles de acceso en un nivel de grupo de recursos. A medida que crece el
tamaño del entorno en la nube, es posible que deba admitir requisitos de gobernanza en varias suscripciones
más complicados que pueden admitirse mediante la jerarquía de empresa, departamento, cuenta y suscripción
del contrato Enterprise de Azure.
Los grupos de administración de Azure le permiten organizar las suscripciones en estructuras organizativas más
sofisticadas mediante la agrupación de suscripciones en una jerarquía distinta de la jerarquía del contrato
Enterprise. Esta jerarquía alternativa le permite aplicar mecanismos de control de acceso y cumplimiento de
directivas en varias suscripciones y los recursos que contienen. Las jerarquías de grupos de administración se
pueden utilizar para hacer coincidir las suscripciones del entorno en la nube con los requisitos de gobernanza
del negocio o las operaciones. Para más información, consulte la Guía de decisiones de suscripción.
Coherencia automatizada
Para las implementaciones de nube de gran tamaño, la gobernanza global pasa a ser más importante y más
complejo. Es fundamental aplicar y exigir automáticamente los requisitos de gobernanza al implementar
recursos, así como satisfacer requisitos actualizados para las implementaciones existentes.
Azure Blueprints permiten a las organizaciones admitir la gobernanza global de entornos de nube de gran
tamaño en Azure. Los planos técnicos van más allá de las capacidades proporcionadas por las plantillas estándar
de Azure Resource Manager para crear orquestaciones de implementación completa capaz de implementar los
recursos y aplicar reglas de directiva. Los planos técnicos son compatibles con el control de versiones, la
capacidad de actualizar todas las suscripciones en las que se usó el plano técnico y la capacidad de bloquear las
suscripciones implementadas para evitar la creación y la modificación no autorizadas de recursos.
Estos paquetes de implementación permiten que los equipos de TI y de desarrollo implementen rápidamente
nuevas cargas de trabajo y recursos de red que cumplan con los requisitos cambiantes de la directiva
organizativa. Los planos técnicos también se pueden integrar en canalizaciones de CI/CD para aplicar los
estándares de gobernanza revisados a las implementaciones cuando se actualizan.
Pasos siguientes
La coherencia de recursos es solo uno de los principales componentes de infraestructura que requieren
Guía de decisiones de nomenclatura y etiquetado
de recursos
La organización de los recursos basados en la nube es una tarea crucial TI, salvo que solo se realicen
implementaciones simples. Estos son los motivos por los que se recomienda usar los estándares de
nomenclatura y etiquetado para organizar los recursos:
Administración de recursos: los equipos de TI deberán ubicar rápidamente los recursos asociados a
cargas de trabajo específicas, entornos, grupos de propiedad u otra información importante. Organizar
los recursos es fundamental para la asignación de roles de la organización y los permisos de acceso para
la administración de recursos.
Optimización y administración de costos: para que los grupos empresariales conozcan el consumo
de recursos en la nube es preciso que el personal de TI sepa qué recursos y cargas de trabajo usa cada
equipo. Los temas siguientes tienen el soporte de las etiquetas relacionadas con los costos:
Modelos de contabilidad en la nube
Cálculos de rentabilidad de la inversión
Seguimiento de costos
Presupuestos
Alertas
Informes y seguimiento de gastos periódicos
Optimizaciones posteriores a la implementación
Tácticas de optimización de costos
Administración de operaciones: la visibilidad del equipo de administración de operaciones en lo
referente a los compromisos empresariales y de nivel de servicio es un aspecto importante de las
operaciones en curso. Para una buena administración, es obligatorio el etiquetado de la importancia de
cada misión.
Seguridad: la clasificación de los datos y del impacto en la seguridad es un punto de datos vital para el
equipo si se producen vulneraciones o cualquier otro problema de seguridad. Para operar de forma
segura, es preciso un etiquetado para la clasificación de datos.
Gobernanza y cumplimiento normativo: el mantenimiento de la coherencia entre los distintos
recursos ayuda a identificar cualquier desviación de las directivas acordadas. La guía prescriptiva para el
etiquetado de recursos muestra de qué forma puede ayudar uno de los patrones siguientes al
implementar prácticas de gobernanza. Existen patrones similares para evaluar el cumplimiento
normativo mediante etiquetas.
Automation: Además de facilitar la administración de los recursos para TI, un esquema organizativo
correcto le permite aprovechar las ventajas de la automatización como parte de la creación de recursos,
la supervisión operativa y la creación de procesos de DevOps.
Optimización de las cargas de trabajo: el etiquetado puede ayudar a identificar patrones y a resolver
problemas amplios. Las etiquetas también puede ayudar a identificar los recursos necesarios para admitir
cargas de trabajo individuales. El etiquetado de todos los recursos asociados a cada carga de trabajo
permite realizar un análisis más profundo de las cargas de trabajo críticas para tomar decisiones
arquitectónicas sólidas.
Guía de decisiones de identidades
Vaya a: Convenciones de nomenclatura de línea de base | Patrones de etiquetado de recursos | Más información
El enfoque del etiquetado puede ser simple o complejo, con un énfasis que puede ir desde la admisión de que
los equipos de TI administren cargas de trabajo en la nube hasta la integración de la información relativa a
todos los aspectos del negocio.
El uso del etiquetado alineado con TI, como el etiquetado en función de la carga de trabajo, la aplicación, la
función o el entorno, reduce la complejidad de la supervisión de los recursos y simplifica la toma de decisiones
de administración según los requisitos operativos.
Los esquemas de etiquetado que incluyen un centro de atención alineado con el negocio, como la contabilidad,
la propiedad del negocio o la importancia empresarial, pueden requerir una mayor inversión de tiempo para
crear estándares de etiquetado que reflejen los intereses del negocio y conserven esos estándares a lo largo del
tiempo. Esta inversión produce un sistema de etiquetado que proporciona una mejor contabilidad de los costos
y el valor de los recursos de TI a la empresa en general. Esta asociación del valor de negocio de un recurso a su
costo operativo es uno de los primeros pasos para cambiar la percepción del centro de costo de TI dentro de
una organización mayor.
Convenciones de nomenclatura de línea de base

Una convención de nomenclatura estandarizada es el punto de partida para organizar los recursos hospedados
en la nube. Un sistema de nomenclatura estructurado correctamente permite identificar con rapidez los recursos
para la administración y la contabilidad. Si existen convenciones de nomenclatura de TI en otras partes de la
organización, considere si las convenciones de nomenclatura en la nube deben alinearse con ellas o si debe
establecer estándares basados en la nube independientes.
NOTE
Las reglas de nomenclatura y sus restricciones varían el función del recurso de Azure. Las convenciones de nomenclatura
deben cumplir estas reglas.

Para una organización más sofisticada que la que solo una convención de nomenclatura coherente puede
proporcionar, las plataformas de nube admiten la capacidad de etiquetar los recursos.
Las etiquetas son elementos de metadatos asociados a recursos. Las etiquetas constan de cadenas de pares de
clave y valor. Los valores incluidos en estos pares dependerán del usuario, pero la aplicación de un conjunto
coherente de etiquetas globales, como parte de una directiva completa de nomenclatura y etiquetado, es una
parte fundamental de una directiva de gobernanza general.
Como parte del proceso de planeación, utilice las siguientes preguntas para ayudar a determinar el tipo de
información que deben admitir las etiquetas de recursos:
¿Es necesario integrar las directivas de nomenclatura y etiquetado con las directivas organizativas y de
nomenclatura existentes dentro de la organización?
¿Va a implementar un sistema de contabilidad chargeback o showback? ¿Necesitará asociar los recursos con
información contable por departamentos, grupos de negocio y equipos con más detalle que un desglose de
nivel de suscripción simple?
¿Es necesario que el etiquetado represente detalles tales como los requisitos de cumplimiento normativo de
un recurso? ¿Qué sucede con los detalles operativos tales como los requisitos de tiempo de actividad, las
programaciones de aplicación de revisiones o los requisitos de seguridad?
¿Qué etiquetas serán necesarias para todos los recursos en función de la directiva de TI centralizada? ¿Qué
etiquetas serán opcionales? ¿Los equipos individuales pueden implementar sus propios esquemas de
etiquetado personalizados?
Los patrones de etiquetado comunes que se enumeran a continuación proporcionan ejemplos de cómo se
puede usar el etiquetado para organizar los recursos en la nube. Estos patrones no están diseñados para ser
exclusivos y se pueden usar en paralelo, lo que proporciona varias maneras de organizar los recursos según las
necesidades de la empresa.
T IP O DE ET IQ UETA E JEM P LO S DESC RIP C IÓ N
Funcional app = catalogsearch1 Clasifique los recursos en relación con

tier = web su finalidad dentro de una carga de
webserver = apache trabajo, el entorno en el que se
env = prod implementaron u otra funcionalidad y
env = staging
detalle operativo.
env = dev
clasificación confidentiality = private Clasifica un recurso por la forma en

SLA = 24hours que se usa y las directivas que se le
aplican.
Control department = finance Permite asociar cualquier recurso a

program = business-initiative grupos concretos de una organización
region = northamerica para la facturación.
Asociación owner = jsmith Proporciona información sobre los

contactalias = catsearchowners usuarios (fuera de TI) relacionados con
stakeholders = el recurso, o que pueden verse
user1;user2;user3 afectados por él de cualquier otra
forma.
Propósito businessprocess = support Alinea los recursos con las funciones

businessimpact = moderate empresariales para dar más soporte a
revenueimpact = high las decisiones de inversión.
Más información
Para obtener más información sobre la nomenclatura y etiquetado en Azure, consulte:
Convenciones de nomenclatura para los recursos de Azure. Consulte esta guía para convenciones de
nomenclatura recomendadas para los recursos de Azure.
Uso de etiquetas para organizar los recursos de Azure y la jerarquía de administración. Puede aplicar
etiquetas en Azure en los niveles de grupo de recursos y de recurso individual, lo que ofrece flexibilidad en la
granularidad de los informes de contabilidad en función de las etiquetas aplicadas.
Pasos siguientes
El etiquetado de recursos es solo uno de los principales componentes de infraestructura que requieren
Guía de decisiones sobre cifrado
El cifrado de datos protege contra accesos no autorizados. Una directiva de cifrado correctamente
implementada proporciona niveles adicionales de seguridad para las cargas de trabajo basadas en la nube y
protege contra atacantes y otros usuarios no autorizados dentro o fuera de su organización y sus redes.
Vaya a: Administración de claves | Cifrado de datos | Más información
La estrategia de cifrado en la nube se centra en directivas corporativas y en las órdenes de cumplimiento
normativo. El cifrado de recursos es deseable y muchos servicios de Azure, como Azure Storage y Azure SQL
Database, habilitan el cifrado de forma predeterminada. Pero el cifrado tiene unos costos que pueden aumentar
la latencia y el uso global de los recursos.
Para las cargas de trabajo más exigentes, encontrar el equilibrio adecuado entre el cifrado y el rendimiento, y
determinar cómo se cifran los datos y el tráfico puede ser fundamental. Los mecanismos de cifrado pueden
variar en costo y complejidad, y los requisitos técnicos y de directivas pueden influir en las decisiones sobre
cómo se aplica el cifrado y cómo se almacenan y administran los secretos y claves críticos.
La directiva corporativa y el cumplimiento de terceros son los factores más importantes a la hora de planear
una estrategia de cifrado. Azure proporciona varios mecanismos estándar que pueden satisfacer los requisitos
comunes de cifrado de datos tanto en reposo como en tránsito. Para aquellos requisitos de directivas y
cumplimiento que exijan controles más estrictos como, por ejemplo, secretos estandarizados y administración
de claves, cifrado en uso o cifrado específico de datos, será preciso que desarrolle una estrategia de cifrado más
sofisticada que admita estos requisitos.
Administración de claves
El cifrado de datos en la nube depende del almacenamiento, administración y uso operativo seguros de las
claves de cifrado. Tener un sistema de administración de claves es fundamental para que la organización pueda
crear, almacenar y administrar claves criptográficas así como contraseñas importantes, cadenas de conexión y
otra información confidencial de TI.
Los sistemas de administración de claves actuales como, por ejemplo, Azure Key Vault, admiten el
almacenamiento y administración de claves protegidas de software para el uso de desarrolladores y de pruebas,
y de claves protegidas del módulo de seguridad del hardware (HSM) para ofrecer la máxima protección de las
cargas de trabajo de producción o de la información confidencial.
Al planear una migración a la nube, la tabla siguiente puede ayudarle a decidir cómo almacenar y administrar
las claves de cifrado, los certificados y los secretos que son fundamentales para crear implementaciones en la
nube seguras y fáciles de administrar:
P REGUN TA N AT IVO DE L A N UB E B RIN G Y O UR O W N K EY H O L D Y O UR O W N K EY
¿Su organización carece de Sí No No

administración centralizada
de claves y secretos?
P REGUN TA N AT IVO DE L A N UB E B RIN G Y O UR O W N K EY H O L D Y O UR O W N K EY
¿Necesitará limitar la No Sí No
creación de claves y
secretos para dispositivos al
hardware local, pero se
usarán en la nube?
¿Su organización cuenta No No Sí

con reglas o directivas
vigentes que podrían
impedir que las claves se
almacenen externamente?
Nativo de la nube
Con la administración nativa de claves en la nube, todas las claves y los secretos se generan, administran y
almacenan en un almacén basado en la nube como Azure Key Vault. Este enfoque simplifica muchas tareas de TI
relacionadas con la administración de claves, como la copia de seguridad, el almacenamiento y la renovación de
claves.
Supuestos nativos de la nube: En el uso de un sistema de administración nativa de claves en la nube se da
por hecho lo siguiente:
Confía en la solución de administración de claves en la nube para crear, administrar y hospedar los secretos y
las claves de su organización.
Permite el acceso al sistema de administración de claves en la nube a todas las aplicaciones y los servicios
locales que dependan del acceso a los secretos o servicios de cifrado.
Traiga su propia clave (BYOK )
Con el enfoque "Bring Your Own Key" puede generar claves en el hardware del HSM dedicado en el entorno
local para transferirlas, posteriormente, a un sistema de administración basado en la nube, como Azure Key
Vault, para el uso de los recursos hospedados en la nube.
Supuestos del enfoque "Bring Your Own Key": La generación de claves en el entorno local y su uso con un
sistema de administración de claves basado en la nube incluye estas suposiciones:
Confía en la infraestructura subyacente de seguridad y control de acceso de la plataforma de nube para
hospedar y usar sus claves y secretos.
Las aplicaciones y servicios hospedados en la nube pueden acceder y utilizar claves y secretos de una
manera sólida y segura.
Está obligado por ley o por una directiva de la organización a mantener la creación y administración de los
secretos y claves de la organización en el entorno local.
Local (mantenga su propia clave )
Determinados escenarios pueden tener motivos técnicos, normativos o de directivas para prohibir el
almacenamiento de claves en un sistema de administración de claves basado en la nube. En ese caso, deberá
generar las claves mediante el hardware local, almacenarlas y administrarlas mediante un sistema de claves
local y establecer una forma de que los recursos basados en la nube acceder a las claves para realizar el cifrado.
Tenga en cuenta que es posible que mantener su propia clave no sea compatible con todos los servicios basados
en Azure.
Suposiciones para la administración local de claves: En el uso de un sistema de administración de claves
local se da por hecho lo siguiente:
Está obligado por ley o por una directiva de la organización a mantener la creación, la administración y el
hospedaje de los secretos y las claves de su organización en el entorno local.
Todas las aplicaciones y los servicios locales que dependan del acceso a los secretos o servicios de cifrado
pueden acceder al sistema de administración local de claves.
Cifrado de datos
Tenga en cuenta los diferentes estados de los datos, con sus diferentes necesidades de cifrado, a la hora de
planear la directiva de cifrado:
ESTA DO DE LO S DATO S DATA
Datos en tránsito Tráfico de red interno, conexiones a Internet, conexiones

entre centros de datos o redes virtuales
Datos en reposo Bases de datos, archivos, unidades virtuales,

almacenamiento de PaaS
Datos en uso Datos cargados en la memoria RAM o en las memorias

caché de la CPU
Datos en tránsito
Los datos en tránsito son aquellos que se transfieren entre los recursos de la red interna, entre centros de datos
o las redes externas o a través de Internet.
Normalmente, para cifrar los datos en tránsito se requieren los protocolos SSL/TLS para el tráfico de red. Cifre
siempre el tráfico entre los recursos hospedados en la nube y las redes externas o la red pública de Internet. Los
recursos de PaaS normalmente aplican el cifrado SSL/TLS de forma predeterminada. Tanto los equipos de
adopción de la nube como los propietarios de las cargas de trabajo deben considerar la posibilidad de aplicar el
cifrado al tráfico que existe entre los recursos de IaaS hospedados en sus redes virtuales.
Suposiciones sobre el cifrado de datos en tránsito: Al implementar una directiva de cifrado para los datos
en tránsito, se da por hecho lo siguiente:
Todos los puntos de conexión accesibles públicamente en su entorno de nube se comunicarán con la red
pública de Internet mediante los protocolos SSL/TLS.
Al conectar redes en la nube con un entorno local u otra red externa mediante la red pública de Internet, se
usan protocolos de VPN cifrados.
Al conectar redes en la nube con un entorno local u otra red externa mediante una conexión WAN dedicada,
como ExpressRoute, se usará una VPN u otro dispositivo de cifrado local emparejado con el correspondiente
dispositivo de red virtual o de cifrado implementado en la red en la nube.
Si tiene datos confidenciales que no deberían incluirse en los registros de tráfico u otros informes de
diagnóstico visibles para el personal de TI, se cifrará todo el tráfico entre los recursos de la red virtual.
Datos en reposo
Los datos en reposo son aquellos que no se están moviendo ni procesando activamente; incluye archivos, bases
de datos, unidades de máquina virtual, cuentas de almacenamiento de PaaS o recursos similares. El cifrado de
datos almacenados protege los archivos o dispositivos virtuales contra el acceso no autorizado, ya sea por
intrusión desde la red externa, usuarios internos deshonestos o liberaciones accidentales.
Por lo general, los recursos de almacenamiento y base de datos de PaaS aplican el cifrado de forma
predeterminada. Los recursos de IaaS se pueden proteger mediante el cifrado de datos en el nivel de disco
virtual o mediante el cifrado de la cuenta de almacenamiento completa que hospeda las unidades de disco
virtuales. Todos estos recursos pueden usar las claves administradas por Microsoft o por el cliente que están
almacenadas en Azure Key Vault.
El cifrado de datos en reposo también incluye técnicas de cifrado de base de datos más avanzadas, como el
cifrado en el nivel de columna y en el nivel de fila, que ofrece mucho más control sobre qué datos se protegen.
Los requisitos generales de directiva y cumplimiento, la confidencialidad de los datos almacenados y los
requisitos de rendimiento de las cargas de trabajo determinarán qué recursos necesitan cifrado.
Suposiciones sobre el cifrado de datos en reposo
Para el cifrado de datos en reposo se da por hecho lo siguiente:
Almacena datos que no están destinados al consumo público.
Las cargas de trabajo pueden aceptar el costo de latencia agregada que supone el cifrado de los discos.
Datos en uso
El cifrado de datos en uso implica proteger datos en un almacenamiento no persistente, como la RAM o la
memoria caché de la CPU. Usa tecnologías como el cifrado de memoria completo o tecnologías de enclave,
como Intel Secure Guard Extensions (SGX). Esto también incluye técnicas de cifrado, como el cifrado
homomorfo, que puede usarse para crear entornos de ejecución seguros y de confianza.
Suposiciones sobre el cifrado de datos en uso: Para el cifrado de datos en uso se da por hecho lo
siguiente:
Necesita que la propiedad de los datos sea independiente de la plataforma de nube subyacente en todo
momento, incluso en el nivel de RAM y CPU.
Más información
Para más información acerca del cifrado y administración de claves en Azure, consulte:
Introducción al cifrado de Azure : Descripción detallada de cómo utiliza Azure el cifrado para proteger los
datos en reposo y en tránsito.
Azure Key Vault : Key Vault es el principal sistema de administración de claves para almacenar y administrar
claves de cifrado, secretos y certificados dentro de Azure.
Procedimientos recomendados de cifrado y seguridad de datos en Azure . Un análisis sobre los
procedimientos recomendados de cifrado y seguridad de datos en Azure.
Computación confidencial en Azure : La iniciativa de computación confidencial de Azure ofrece
herramientas y tecnología para crear entornos de ejecución de confianza u otros mecanismos de cifrado para
proteger los datos de uso.
Pasos siguientes
El cifrado es solo uno de los componentes principales de infraestructura que requiere decisiones de arquitectura
durante el proceso de adopción de la nube. Para obtener información sobre patrones o modelos alternativos
que se usan cuando se toman decisiones acerca del diseño de otros tipos de infraestructura, consulte la
introducción a las guías para la toma de decisiones arquitectónicas.
Introducción a las guías para la toma de decisiones arquitectónicas
Guía de decisiones sobre redes definidas por
software
Redes definidas por software (SDN) es una arquitectura de red diseñada para permitir la funcionalidad de redes
virtualizadas que se pueden administrar, configurar y modificar a través de software. SDN permite la creación de
redes basadas en la nube con los equivalentes virtualizados de enrutadores físicos, firewalls y otros dispositivos
de red que se usan en redes locales. SDN es fundamental para crear redes virtuales seguras en plataformas en
la nube pública como Azure.
Guía de decisiones sobre redes
Vaya a: Solo PaaS | Nativa de la nube | Red perimetral en la nube | Híbrida | Modelo en estrella tipo hub-and-
spoke | Más información
SDN proporciona varias opciones con diversos grados de complejidad y precios. La guía de detección anterior
proporciona una referencia para personalizar rápidamente dichas opciones, con el fin de ajustarlas lo mejor
posible a estrategias empresariales y tecnológicas concretas.
El punto de inflexión de esta guía depende de varias decisiones clave que ha tomado el equipo de estrategia en
la nube antes de tomar decisiones acerca de la arquitectura de red. Las más importantes de estas decisiones son
aquellas que tienen que ver con la definición del patrimonio digital y el diseño de suscripciones, que también
pueden requerir aportaciones de las decisiones tomadas relacionadas con la contabilidad de la nube y las
estrategias de los mercados globales.
A las implementaciones pequeñas, que se realizan en una sola región, de menos de 1 000 máquinas virtuales es
menos probable que les afecte de manera considerable este punto de inflexión. Por el contrario, a los trabajos de
adopciones de gran tamaño, con más de 1000 máquinas virtuales, varias unidades de negocio o varios
mercados geopolíticos, podrían verse afectados considerablemente tanto por la decisión de SDN como por este
punto de inflexión clave.
Elección de las arquitecturas de red virtual adecuadas

Esta sección amplía la guía para la toma de decisiones, con el fin de ayudarle a elegir las arquitecturas de red
virtual adecuadas.
Hay muchas maneras de implementar tecnologías de SDN para crear redes virtuales en la nube. Tanto la forma
en que se estructuren las redes virtuales que se usen en la migración cómo la forma en que dichas redes
interactúan con la infraestructura de TI existente dependerán de una combinación de requisitos de las cargas de
trabajo y requisitos de gobernanza.
Al planear la arquitectura de red virtual o la combinación de arquitecturas que hay que tomar en consideración
al planear una migración a la nube, tenga en cuenta las siguientes preguntas, ya que ello le ayudará a
determinar lo que es más apropiado para su organización:
RED EN EST REL L A

N AT IVO DE L A P ERIM ET RA L EN T IP O H UB - A N D-
P REGUN TA SO LO PA A S N UB E L A N UB E H ÍB RIDO SP O K E
¿Va a usar la Sí No No No No
carga de trabajo
solo los servicios
de PaaS y no va
a requerir
funcionalidades
de red que
vayan más allá
de las
proporcionados
por los propios
servicios?
¿Requiere la No No Sí Sí Sí
carga de trabajo
integración con
las aplicaciones
locales?
¿Se han No No No Sí Sí
establecido
directivas de
seguridad
maduras y una
conectividad
segura entre las
redes local y en
la nube?
¿Requiere la No No No Sí Sí
carga de trabajo
servicios de
autenticación
que no se
admite a través
de servicios de
identidad en la
nube o se
necesita acceso
directo a
controladores de
dominio locales?
RED EN EST REL L A
N AT IVO DE L A P ERIM ET RA L EN T IP O H UB - A N D-
P REGUN TA SO LO PA A S N UB E L A N UB E H ÍB RIDO SP O K E
¿Va a ser preciso No No No No Sí

implementar y
administrar un
gran número de
máquinas
virtuales y
cargas de
trabajo?
¿Se va a No No No No Sí
necesitar
proporcionar
administración
centralizada y
conectividad
local al delegar el
control sobre los
recursos a los
equipos de las
cargas de trabajo
individuales?
Arquitecturas de red virtual

Más información sobre las arquitecturas de red principales definidas por el software:
Solo PaaS : la mayoría de los productos de plataforma como servicio (PaaS) admiten un conjunto limitado
de características de redes integradas y es posible que no necesiten una red definida por software
explícitamente para cumplir los requisitos de las cargas de trabajo.
Nativas de la nube : una arquitectura nativa de la nube admite cargas de trabajo basadas en la nube con
redes virtuales basadas en funcionalidades de redes definidas por software predeterminadas de la
plataforma en la nube, sin necesidad de depender de recursos locales o externos.
Red perimetral en la nube : admite una conectividad limitada entre la red local y en la nube que se
protege mediante la implementación de una red de perímetro que controla estrechamente el tráfico entre los
dos entornos.
Híbrida : la arquitectura de red en la nube híbrida permite a las redes virtuales de entornos en la nube de
confianza acceder a los recursos locales y viceversa.
En estrella tipo hub-and-spoke : La arquitectura en estrella tipo hub-and-spoke permite administrar
centralmente la conectividad externa y los servicios compartidos, aislar cargas de trabajo individuales y
superar los límites de suscripciones posibles.
Más información
Para más información acerca de las redes definidas por software en Azure, consulte:
Azure Virtual Network. En Azure, Azure Virtual Network proporciona la funcionalidad de SDN principal, que
actúa como un análogo en la nube a las redes locales físicas. Las redes virtuales también actúan como límite
de aislamiento predeterminado entre los recursos de la plataforma.
Procedimientos recomendados de seguridad de la red de Azure. Recomendaciones del equipo de seguridad
de Azure para configurar las redes virtuales de forma que se reduzcan los puntos vulnerables de seguridad.
Pasos siguientes
Las redes definidas por software son solo uno de los principales componentes de infraestructura que requieren
Red definida por software: solo PaaS
Al implementar un recurso de plataforma como servicio (PaaS), el proceso de implementación crea

automáticamente una red asumida subyacente con un número limitado de controles a través de dicha red,
como equilibrio de carga, bloqueo de puertos y conexiones a otros servicios PaaS.
En Azure, varios tipos de recursos PaaS se pueden implementar en una red virtual o conectarse a una, de modo
que estos recursos se integran en la infraestructura de red virtual existente. Otros servicios, como App Service
Environment, Azure Kubernetes Service (AKS) y Service Fabric deben implementarse dentro de una red virtual.
En muchos casos, para cumplir los requisitos de conectividad y administración de tráfico de una carga de
trabajo, basta con tener una arquitectura de red solo PaaS, basada exclusivamente en las capacidades de red
nativas predeterminadas proporcionadas por los recursos PaaS.
Si se plantea la opción de usar una arquitectura de red solo PaaS, asegúrese de validar que las suposiciones
necesarias están en consonancia con los requisitos.
Suposiciones solo PaaS

Para la implementación de una arquitectura de red solo PaaS, se supone lo siguiente:
La aplicación que se va a implementar es una aplicación independiente o solamente depende de otros
recursos PaaS que no necesitan una red virtual.
Los equipos de operaciones de TI pueden actualizar sus herramientas, formación y procesos para admitir la
administración, configuración e implementación de aplicaciones PaaS independientes.
La aplicación PaaS no forma parte de un trabajo de migración a nube más amplio que incluirá recursos IaaS.
Estas suposiciones son calificadores mínimos alineados con la implementación de una red solo PaaS. Aunque
este enfoque puede estar en consonancia con los requisitos de una implementación de una sola aplicación, cada
equipo de adopción de la nube debería tener en cuenta estas preguntas a largo plazo:
¿Se ampliará el ámbito o la escala de esta implementación para requerir acceso a otros recursos no PaaS?
¿Se han planeado otras implementaciones PaaS más allá de la solución actual?
¿La organización tiene planes de realizar otras migraciones a nube futuras?
Las respuestas a estas preguntas no impedirían que un equipo elija una opción solo PaaS, pero deben tenerse
en cuenta antes de tomar una decisión definitiva.
Red definida por software: Nativo de la nube
Se requiere una red virtual nativa en la nube para implementar recursos de IaaS, como las máquinas virtuales,
en una plataforma en la nube. El acceso a redes virtuales de orígenes externos, similares a la web, se debe
proporcionar explícitamente. Este tipo de redes virtuales admiten la creación de subredes y reglas de
enrutamiento, así como firewalls virtuales y dispositivos de administración de tráfico.
Una red virtual nativa en la nube no depende de los recursos locales de la organización ni de otros recursos que
no sean de nube para admitir las cargas de trabajo hospedadas en la nube. Todos los recursos necesarios se
aprovisionan en la propia red virtual o mediante ofertas PaaS administradas.
Supuestos de la red virtual nativa en la nube

En la implementación de una red virtual nativa en la nube se da por hecho lo siguiente:
Las cargas de trabajo que se implementan en la red virtual no dependen de aplicaciones o servicios a los que
solo se puede acceder desde dentro de la red local. A menos que proporcionen puntos de conexión
accesibles en la red pública de Internet, los recursos hospedados en una plataforma de nube no pueden
utilizar las aplicaciones y los servicios hospedados internamente en el entorno local.
La administración de identidades de la carga de trabajo y el control de acceso dependen de los servicios de
identidad de la plataforma de nube o de los servidores IaaS hospedados en su entorno en nube. No
necesitará conectarse directamente a los servicios de identidad hospedados en el entorno local o en otras
ubicaciones externas.
Los servicios de identidad no necesitan admitir el inicio de sesión único (SSO) con directorios locales.
Las redes virtuales nativas en la nube no tienen dependencias externas. Esto hace que sean fáciles de
implementar y configurar y, como resultado, esta arquitectura es a menudo la mejor opción para experimentos
u otras implementaciones más pequeñas, autónomas o de iteración rápida.
Entre los temas adicionales que el equipo de adopción de la nube debe tener en cuenta al hablar de una
arquitectura de red virtual nativa en la nube, se incluyen los siguientes:
Las cargas de trabajo existentes diseñadas para ejecutarse en un centro de datos local pueden necesitar una
amplia modificación para aprovechar la funcionalidad basada en la nube, como los servicios de
almacenamiento o autenticación.
Las redes nativas en la nube se administran únicamente con las herramientas de administración de la
plataforma de nube lo que, con el tiempo, puede dar lugar a divergencias en la administración y las directivas
con respecto a los estándares de TI existentes.
Pasos siguientes
Para más información sobre las redes virtuales nativas en la nube en Azure, consulte:
Guías de Azure Virtual Network: De forma predeterminada las redes virtuales de Azure que se acaban de
crear son nativas de nube. Use estas guías para ayudar a planear el diseño e implementación de las redes
virtuales.
Acerca de los límites de red: Cada red virtual y sus recursos conectados existen en una suscripción única.
Estos recursos están limitados por los límites de la suscripción.
Red definida por software: Red perimetral en la
nube
La arquitectura de red permite un acceso limitado entre la red local y la basada en la nube, y utiliza una red
privada virtual (VPN) para conectar las redes. Aunque los modelos de red perimetral se usan normalmente
cuando se desea proteger el acceso externo a una red, la arquitectura de red perimetral en la nube que se
describe aquí está pensada específicamente para proteger el acceso a la red local desde los recursos basados en
la nube y viceversa.
Esta arquitectura está diseñada para admitir escenarios en los que su organización desea comenzar a integrar
cargas de trabajo basadas en la nube con cargas de trabajo locales pero puede que no tenga directivas de
seguridad en la nube completamente maduras o no haya adquirido una conexión WAN dedicada segura entre
los dos entornos. Como resultado, las redes en la nube deben tratarse como una DMZ para garantizar que los
servicios locales sean seguros.
La red perimetral implementa aplicaciones virtuales de red (NVA) para aplicar la funcionalidad de seguridad,
como firewalls e inspección de paquetes. El tráfico que circula entre aplicaciones o servicios locales y basados en
la nube debe pasar a través de la red perimetral, donde se puede auditar. Las conexiones de VPN y las reglas que
determinan qué tráfico se permite a través de la perimetral están estrictamente controladas por los equipos de
seguridad de TI.
Suposiciones de la red perimetral en la nube

En la implementación de una red perimetral en la nube se da por hecho lo siguiente:
Sus equipos de seguridad no han alineado completamente las directivas y los requisitos de seguridad locales
y basados en la nube.
Sus cargas de trabajo basadas en la nube requieren acceso a un subconjunto limitado de servicios
hospedados en sus redes locales o de terceros, o los usuarios o aplicaciones del entorno local necesitan
acceso limitado a los recursos hospedados en la nube.
La implementación de una conexión VPN entre las redes locales y el proveedor de servicios en la nube no se
ve impedida por la directiva corporativa, los requisitos normativos o los problemas de compatibilidad
técnica.
Sus cargas de trabajo no requieren múltiples suscripciones para omitir los límites de recursos de suscripción,
o implican múltiples suscripciones pero no requieren una administración central de la conectividad o los
servicios compartidos utilizados por los recursos distribuidos entre varias suscripciones.
El equipo de adopción de la nube debe considerar los siguientes problemas al considerar la implementación de
una arquitectura de red virtual perimetral en la nube:
Conectar redes locales con redes en la nube aumenta la complejidad de los requisitos de seguridad. Aunque
se proteja la conexión entre las redes en la nube y el entorno local, deberá cerciorarse de que los recursos en
la nube están seguros. Todas las direcciones IP públicas creadas para acceder a las cargas de trabajo basadas
en la nube deben protegerse correctamente mediante una red perimetral de acceso público o Azure Firewall.
La arquitectura de la red perimetral en la nube se usa comúnmente como punto de partida, mientras que la
conectividad se protege aún más y la directiva de seguridad se alinea entre las redes locales y en la nube, lo
que permite una adopción más amplia de una arquitectura de red híbrida a gran escala. También puede
aplicarse a implementaciones aisladas con necesidades específicas de seguridad, identidad y conectividad
que la estrategia de la red perimetral en la nube satisface.
Más información
Para más información acerca de cómo implementar una red perimetral en la nube en Azure, consulte:
Implementación de una zona DMZ entre Azure y el centro de datos local Este artículo aborda el proceso para
implementar una arquitectura de red híbrida segura en Azure.
Red definida por software: Red híbrida
La arquitectura de red en una nube híbrida permite a las redes virtuales acceder a los recursos y servicios
locales y viceversa, mediante una conexión WAN dedicada, como ExpressRoute o cualquier otro método de
conexión que conecte directamente las redes.
Al crear en una arquitectura de red virtual nativa en la nube, la red virtual híbrida está aislada en el momento de
su creación. El hecho de incorporar la conectividad al entorno local concede acceso a la red local y desde esta,
aunque el resto del tráfico entrante con destino a recursos de la red virtual deberá permitirse explícitamente.
Puede proteger la conexión mediante dispositivos de firewall y reglas de enrutamiento virtuales para restringir
el acceso, o puede indicar a qué servicios se puede acceder específicamente entre las dos redes mediante
características de enrutamiento nativas para la nube o la implementación de aplicaciones virtuales de red (NVA)
que administren el tráfico.
Aunque la arquitectura de red híbrida es compatible con las conexiones VPN, se prefieren conexiones WAN
dedicadas, como ExpressRoute, debido a un mayor rendimiento y a una seguridad mejorada.
Suposiciones sobre la red híbrida

La implementación de una red virtual híbrida incluye las siguientes suposiciones:
El equipo de seguridad de TI se ha alineado con una directiva de seguridad de red local y otra basada en la
nube que garantiza que las redes virtuales basadas en la nube sean de confianza para poder comunicarse
directamente con sistemas locales.
Sus cargas de trabajo basadas en la nube requieren acceso al almacenamiento, las aplicaciones y los
servicios hospedados en sus redes locales o de terceros, o sus usuarios o aplicaciones del entorno local
necesitan acceso a los recursos hospedados en la nube.
Debe migrar las aplicaciones y servicios existentes que dependen de recursos locales, pero no desea gastar
los recursos en un nuevo desarrollo para eliminar esas dependencias.
La conexión de las redes locales a los recursos en la nube a través de VPN o WAN dedicada no se evita
mediante directivas corporativas, requisitos de soberanía de datos ni otros temas de cumplimiento
normativo.
Las cargas de trabajo o no requieren varias suscripciones para omitir los límites de recursos de suscripción o
incluyen varias suscripciones, pero no requieren una administración central de la conectividad ni los
servicios compartidos usados por los recursos distribuidos entre varias suscripciones.
El equipo de adopción de la nube debe tener en cuenta los siguientes problemas al considerar la
implementación de una arquitectura de red virtual híbrida:
Conectar redes locales con redes en la nube aumenta la complejidad de los requisitos de seguridad. Ambas
redes deben protegerse frente a vulnerabilidades externas y accesos no autorizados desde ambos lados del
entorno híbrido.
Escalar el número y el tamaño de las cargas de trabajo dentro de un entorno de nube híbrida puede agregar
una complejidad significativa a la administración del enrutamiento y el tráfico.
Deberá desarrollar directivas compatibles de administración y control de acceso para mantener una
gobernanza coherente en toda la organización.
Más información
Para obtener más información sobre las redes híbridas en Azure, vea:
Arquitectura de referencia de una red híbrida. Las redes virtuales híbridas de Azure usan un circuito de
ExpressRoute o una VPN de Azure para conectar la red virtual con los recursos de TI existentes de la
organización no hospedados en Azure. En este artículo se describen las opciones para crear una red híbrida
de Azure.
Red definida por software: En estrella tipo hub-and-
spoke
El modelo de redes en estrella tipo hub-and-spoke organiza la infraestructura de la red en la nube basada en
Azure en varias redes virtuales conectadas. Este modelo le permite administrar los requisitos comunes de
comunicación o seguridad de manera más eficaz, así como gestionar las posibles limitaciones de suscripción.
En el modelo en estrella tipo hub-and-spoke, el centro de conectividad es una red virtual que actúa como
ubicación central para administrar la conectividad externa y los servicios de hospedaje que las diversas cargas
de trabajo utilizan. Los radios son redes virtuales que hospedan las cargas de trabajo y se conectan al centro de
conectividad central a través del emparejamiento de redes virtuales.
Todo el tráfico que pasa hacia dentro o fuera de las redes radiales de carga de trabajo se enruta a través de la
red del centro de conectividad donde se puede enrutar, inspeccionar o administrar mediante reglas o procesos
de TI administrados centralmente.
Este modelo tiene como objetivo abordar las preocupaciones siguientes:
Ahorro en costos y eficiencia de la administración . La centralización de los servicios que se pueden
compartir entre varias cargas de trabajo, como las aplicaciones virtuales de red (NVA) y los servidores DNS,
en una única ubicación permite que TI minimice los recursos redundantes y el esfuerzo de administración en
varias cargas de trabajo.
Superación de los límites de las suscripciones. Las cargas de trabajo grandes basadas en la nube
pueden requerir el uso de más recursos que los permitidos en una sola suscripción de Azure. El
emparejamiento de redes virtuales de carga de trabajo de distintas suscripciones con un centro de
conectividad central puede superar estos límites. Para más información, consulte los límites de red de Azure.
Separación de intereses . La capacidad de implementar cargas de trabajo individuales entre los equipos de
TI central y los equipos de las cargas de trabajo.
En el diagrama siguiente se muestra un ejemplo de arquitectura en estrella tipo hub-and-spoke, incluida la
conectividad híbrida administrada centralmente.
La arquitectura en estrella tipo hub-and-spoke se usa a menudo junto con la arquitectura de red híbrida, lo que
proporciona una conexión administrada centralmente para el entorno local compartido entre varias cargas de
trabajo. En este escenario, todo el tráfico realizado entre las cargas de trabajo y el entorno local pasa a través del
centro de conectividad, donde puede administrarse y protegerse.
Suposiciones de redes en estrella tipo hub-and-spoke

En la implementación de una arquitectura de red virtual en estrella tipo hub-and-spoke, se da por supuesto lo
siguiente:
Las implementaciones en la nube implicarán cargas de trabajo hospedadas en entornos de trabajo
independientes, como desarrollo, prueba y producción, y todos ellos se basan en un conjunto de servicios
comunes, como DNS o servicios de directorio.
Las cargas de trabajo no necesitan comunicarse entre sí, pero tienen requisitos comunes de comunicaciones
externas y servicios compartidos.
Las cargas de trabajo requieren más recursos de los que están disponibles en una sola suscripción de Azure.
Deberá proporcionar a los equipos de carga de trabajo derechos de administración delegada sobre sus
propios recursos mientras conservan el control de seguridad central sobre la conectividad externa.
Redes en estrella tipo hub-and-spoke

Las arquitecturas en estrella tipo hub-and-spoke normalmente se implementan con redes virtuales
implementadas en la misma región de Azure para minimizar la latencia entre redes. Puede que las grandes
organizaciones con presencia global necesiten implementar cargas de trabajo en varias regiones para satisfacer
los requisitos normativos, de disponibilidad o de recuperación ante desastres. El modelo de hub-and-spoke
puede usar el emparejamiento global de redes virtuales de Azure para extender la administración centralizada y
los servicios compartidos entre regiones y admitir cargas de trabajo distribuidas en todo el mundo.
Más información
Para información sobre las arquitecturas de referencia que muestran cómo implementar redes en estrella tipo
hub-and-spoke en Azure, consulte:
Implementación de una topología de red en estrella tipo hub-and-spoke en Azure
Implementación de una topología de red en estrella tipo hub-and-spoke con servicios compartidos en Azure
Guía de decisiones sobre registros e informes
Todas las organizaciones necesitan mecanismos para informar a los equipos de TI sobre los problemas de
rendimiento, tiempo de actividad y seguridad antes de que se conviertan en problemas graves. Una correcta
estrategia de supervisión permite comprender cómo funcionan los componentes individuales que componen la
infraestructura de red y las cargas de trabajo. En el contexto de una migración en la nube pública, la integración
de registros e informes con cualquiera de los sistemas de supervisión existentes, al presentar métricas y eventos
importantes al personal de TI adecuado, es fundamental para garantizar que su organización cumple los
objetivos de tiempo de actividad, seguridad y cumplimiento de directivas.
Vaya a: Planeamiento de una infraestructura de supervisión | Nativo de la nube | Extensión local | Agregación de
puerta de enlace | Supervisión híbrida (local) | Supervisión híbrida (en la nube) | Nube múltiple | Más
información
El punto de inflexión al determinar una estrategia de generación de informes y registro en la nube se basa
principalmente en las inversiones que una organización haya realizado en los procesos operativos y, hasta cierto
punto, en los requisitos que hay que cumplir para respaldar una estrategia de nube múltiple.
Las actividades en la nube se pueden registrar y notificar de varias maneras. El registro nativo en la nube y el
centralizado son dos opciones de servicio administrado habituales basadas en el diseño de la suscripción y en el
número de suscripciones.
Planeamiento de una infraestructura de supervisión

Al planear la implementación, debe pensar en dónde se almacenarán los datos de registro y en cómo integrará
los informes basados en la nube y los servicios de supervisión con las herramientas y los procesos existentes.
SUP ERVISIÓ N A GREGA C IÓ N DE

P REGUN TA N AT IVO DE L A N UB E EXT EN SIÓ N LO C A L H ÍB RIDA P UERTA DE EN L A C E
¿Dispone de una No Sí Sí No
infraestructura de
supervisión local
existente?
SUP ERVISIÓ N A GREGA C IÓ N DE
P REGUN TA N AT IVO DE L A N UB E EXT EN SIÓ N LO C A L H ÍB RIDA P UERTA DE EN L A C E
¿Existen requisitos No Sí No No
que impidan
almacenar los datos
de registro en
ubicaciones de
almacenamiento
externas?
¿Necesita integrar la No No Sí No
supervisión en la
nube con sistemas
locales?
¿Necesita procesar o No No No Sí
filtrar datos de
telemetría antes de
enviarlos a los
sistemas de
supervisión?
Nativo de la nube
Si una organización no dispone de sistemas de registro y generación de informes establecidos, o si la
implementación planeada no necesita integrarse con los sistemas de supervisión locales existentes u otros
externos, la opción más sencilla es una solución SaaS nativa en la nube, como Azure Monitor.
En este escenario, todos los datos del registro se graban y almacenan en la nube, mientras que las herramientas
de registro y generación de informes que procesan y muestran la información al personal de TI se proporcionan
por la plataforma Azure y Azure Monitor.
Las soluciones de registro personalizadas basadas en Azure Monitor se pueden implementar según sea
necesario para cada suscripción o carga de trabajo en implementaciones más pequeñas o experimentales. Estas
soluciones se organizan de forma centralizada para supervisar los datos de registro en todos los recursos de la
nube.
Supuestos nativos de la nube: Al usar un sistema de registro y generación de informes nativo de la nube, se
asume lo siguiente:
No es necesario integrar los datos de registro de las cargas de trabajo de la nube en los sistemas locales
existentes.
No usará los sistemas de informes basados en la nube para supervisar los sistemas locales.
Extensión local
El uso de soluciones de registro y generación de informes en la nube, como Azure Monitor, puede requerir un
considerable esfuerzo de desarrollo para las aplicaciones y servicios. En esos casos, plantéese la posibilidad de
que estas cargas de trabajo sigan enviando datos de telemetría a los sistemas locales existentes.
Para admitir este enfoque, los recursos en la nube deben comunicarse directamente con los sistemas locales
mediante una combinación de redes híbridas y servicios de dominio hospedados en la nube. Gracias a esto, la
red virtual en la nube funciona como una extensión de red del entorno local. Por tanto, las cargas de trabajo
hospedadas en la nube pueden comunicarse directamente con el sistema local de registros e informes.
Este enfoque saca el máximo rendimiento a la inversión existente en herramientas de supervisión con una
modificación limitada de todos los servicios o las aplicaciones implementados en la nube. Este enfoque a
menudo es el que menos tarda en dar soporte a la supervisión durante una migración mediante lift-and-shift.
Pero no capturará los datos de registro creados por los recursos de PaaS y SaaS basados en la nube y omitirá
los registros relacionados con las máquinas virtuales generados por la plataforma de la nube, como el estado de
dichas máquinas. Como resultado, este patrón debe ser una solución temporal hasta que se implemente una
solución de supervisión híbrida más completa.
Suposiciones sobre entornos locales solo:
Debe mantener los datos de registro solo en el entorno local, bien para satisfacer los requisitos técnicos o
para cumplir las disposiciones legales o de las directivas.
Los sistemas locales no admiten soluciones híbridas de registros e informes o agregación de puerta de
enlace.
Las aplicaciones basadas en la nube pueden enviar los datos de telemetría directamente a los sistemas
locales de registro, o los agentes de supervisión que envían al entorno local pueden implementarse en las
máquinas virtuales de la carga de trabajo.
Las cargas de trabajo no dependen de servicios PaaS o SaaS que requieren registro y generación de
informes basados en la nube.
Agregación de puerta de enlace
En los escenarios en que haya gran cantidad de datos de telemetría basados en la nube o en que los sistemas de
supervisión locales necesiten modificar los datos de registro para poder procesarlos, es posible que sea
necesario un servicio de agregación de puerta de enlace para los datos de registro.
Se implementa un servicio de puerta de enlace en el proveedor de servicios en la nube. A continuación, se
configuran las aplicaciones o los servicios pertinentes para que envíen datos de telemetría a la puerta de enlace
en lugar de a un sistema de registro predeterminado. A continuación, la puerta de enlace puede procesar los
datos: agregarlos, combinarlos o darles formato antes de enviarlos al servicio de supervisión para su ingesta y
análisis.
Además, se puede utilizar una puerta de enlace para agregar y preprocesar datos de telemetría destinados a
sistemas híbridos o nativos en la nube.
En una agregación de puerta de enlace, se da por hecho lo siguiente:
Espera volúmenes altos de datos de telemetría de los servicios o las aplicaciones basados en la nube.
Necesitar dar formato u optimizar los datos de telemetría antes de enviarlos a los sistemas de supervisión.
Los sistemas de supervisión tienen API u otros mecanismos disponibles para la ingesta de datos de registro
después de que la puerta de enlace los procese.
Supervisión híbrida (local)
Una solución de supervisión híbrida combina los datos de registro de los recursos locales y los recursos en la
nube para proporcionar una visión integrada del estado operativo del entorno de TI.
Si ya ha realizado una inversión en sistemas de supervisión local y le resultaría difícil o caro sustituirlos, puede
que necesite integrar los datos de telemetría de las cargas de trabajo en la nube en las soluciones de
supervisión locales preexistentes. En un sistema de supervisión local híbrida, los datos de telemetría locales
siguen usando el sistema de supervisión local existente. Los datos de telemetría basados en la nube se envían
directamente al sistema de supervisión en la nube, o bien los datos se envían a Azure Monitor y luego se
compilan e ingieren en el sistema local a intervalos regulares.
Supuestos de la super visión híbrida local: Al usar un sistema de registros e informes local para una
supervisión híbrida, se da por hecho lo siguiente:
Deberá usar los sistemas de informes locales existentes para supervisar las cargas de trabajo en la nube.
Debe mantener la propiedad local de los datos de registro.
Los sistemas de administración locales tienen API u otros mecanismos disponibles para la ingesta de datos
de registro de los sistemas basados en la nube.
TIP
Como parte de la naturaleza iterativa de migración a la nube, el paso de una supervisión local y nativa de la nube
claramente diferenciadas a un enfoque híbrido parcial se puede realizar cuando madure la integración de servicios y
recursos en la nube en un entorno de TI general.
Supervisión híbrida (basada en la nube )

Si no tiene una necesidad imperiosa de mantener un sistema de supervisión local o desea reemplazar los
sistemas de supervisión locales por una solución centralizada basada en la nube, también puede elegir la opción
de integrar los datos de registro locales con Azure Monitor para proporcionar un sistema de supervisión
centralizado basado en la nube.
Mediante la creación de un reflejo del enfoque centrado en un entorno local, las cargas de trabajo basadas en la
nube de este escenario enviarían los datos de telemetría directamente a Azure Monitor, mientras que los
servicios y aplicaciones locales enviarían los datos de telemetría directamente a Azure Monitor o agregarían
dichos datos de forma local para que los ingiera Azure Monitor a intervalos regulares. Azure Monitor podría
actuar como sistema de supervisión y generación de informes principal para todo el entorno de TI.
Suposiciones para la super visión híbrida basada en la nube: Al usar sistemas de registros e informes
basados en la nube para una supervisión híbrida, se da por hecho lo siguiente:
No depende de los sistemas de supervisión locales existentes.
Las cargas de trabajo no tienen requisitos de directiva o normativos para almacenar los datos de registro
localmente.
Los sistemas de supervisión basados en la nube tienen API u otros mecanismos disponibles para la ingesta
de datos de registro de aplicaciones y servicios locales.
Nube múltiple
La integración de las funcionalidades de informes y registros en una plataforma de varias nubes puede resultar
complicada. Los servicios ofrecidos entre las plataformas no suelen ser comparables directamente, y las
funcionalidades de registro y telemetría proporcionadas por estos servicios también varían.
La compatibilidad con el registro de nube múltiple requiere que el uso de servicios de puerta de enlace
procesen los datos de registro en un formato común antes de enviarlos a una solución híbrida de registros.
Más información
Azure Monitor es el servicio de informes y supervisión predeterminado para Azure. Ofrece:
Una plataforma unificada para recopilar datos de telemetría de aplicaciones, telemetría de host (como
máquinas virtuales), métricas de contenedor, métricas de la plataforma Azure y registros de eventos.
Herramientas de visualización, consultas, alertas y análisis. Pueden proporcionar información sobre las
máquinas virtuales, los sistemas operativos invitados, las redes virtuales y los eventos de aplicaciones de
carga de trabajo.
API REST para la integración con servicios externos y automatización de los servicios de supervisión y
alertas.
Integración con muchos proveedores externos populares.
Pasos siguientes
El registro y la generación de informes no es más que uno de los componentes de la infraestructura central que
requieren decisiones arquitectónicas durante un proceso de adopción en la nube. Visite la introducción a las
guías para la toma de decisiones arquitectónicas para obtener información sobre patrones o modelos
alternativos que se usan cuando se toman decisiones de diseño para otros tipos de infraestructura.
Guía para la toma de decisiones de las herramientas
de migración
La estrategia y las herramientas que usa para migrar una aplicación en Azure dependerán considerablemente de
sus motivaciones empresariales, estrategias tecnológicas y escalas de tiempo, así como de tener un profundo
conocimiento de la carga de trabajo y los recursos reales (infraestructura, aplicaciones y datos) que se van a
migrar. El siguiente árbol de decisión sirve como guía de alto nivel para seleccionar las mejores herramientas en
función de las decisiones que se tomen durante la migración. Este árbol de decisión se puede usar como punto
de partida.
La opción de usar las tecnologías de plataforma como servicio (PaaS) o infraestructura como servicio (IaaS) se
toma debido al equilibrio entre costo, tiempo, la deuda técnica existente y las devoluciones a largo plazo. A
menudo, IaaS es la ruta más rápida hacia la nube y la que menor cantidad de cambio en la carga de trabajo
necesita. PaaS puede requerir que se realicen modificaciones en las estructuras de datos o en el código fuente,
pero genera importantes ventajas a largo plazo, ya que reduce los costos operativos y aumenta la flexibilidad
técnica. En el diagrama siguiente, el término modernizar se usa para reflejar la decisión de modernizar un
recurso durante la migración y migrar el recurso modernizado a una plataforma PaaS.
Preguntas clave
Responder a las preguntas siguientes le permitirá tomar decisiones basándose en el árbol anterior.
¿La modernización de la plataforma de aplicaciones durante la migración resultaría ser una
buena inversión económica, de tiempo y esfuerzo? Las tecnologías de PaaS, como Azure App Service
o Azure Functions, pueden aumentar la flexibilidad de la implementación y reducir la complejidad de la
administración de máquinas virtuales para hospedar aplicaciones. Las aplicaciones pueden requerir una
refactorización para poder aprovechar estas funcionalidades nativas de la nube, lo que puede aumentar
considerablemente el tiempo y costo necesarios en esfuerzo de migración. Si una aplicación puede migrar a
las tecnologías de PaaS con muy pocas modificaciones, es probable que sea buena candidata para la
modernización. Si se requiere una extensa refactorización, es posible que sea mejor realizar la migración
mediante máquinas virtuales basadas en IaaS.
¿La modernización de la plataforma de datos durante la migración resultaría ser una buena
inversión económica, de tiempo y esfuerzo? Igual que sucede con la migración de aplicaciones, las
opciones de almacenamiento administrado de PaaS de Azure, como Azure SQL Database, Azure Cosmos DB
y Azure Storage, ofrecen considerables ventajas en cuanto a administración y flexibilidad, pero la migración a
estos servicios puede requerir la refactorización de los datos existentes y las aplicaciones que usan dichos
datos. Normalmente, las plataformas de datos requieren menos refactorización que la plataforma de
aplicaciones. Por consiguiente, es habitual que la plataforma de datos se modernice, aunque la plataforma de
aplicaciones siga siendo la misma. Si los datos se pueden migrar a un servicio de datos administrados con
un mínimo de cambios, son buenos candidatos para la modernización. Es posible que los datos cuya
refactorización para poder usar los servicios de PaaS requiera mucho tiempo o costo, sea mejor migrarlos
mediante máquinas virtuales basadas en IaaS, con el fin de que se ajusten mejor a las funcionalidades de
hospedaje existentes.
¿Se ejecuta la aplicación actualmente en máquinas vir tuales dedicadas o compar te hospedaje
con otras aplicaciones? Las aplicaciones que se ejecutan en máquinas virtuales dedicadas se pueden
migrar más fácilmente a las opciones de hospedaje de PaaS que las aplicaciones que se ejecutan en
servidores compartidos.
¿Superará la migración de datos el ancho de banda de la red? La capacidad de la red entre los
orígenes de datos locales y Azure puede ser un cuello de botella en la migración de datos. Si los datos que
necesita transferir se enfrentan a limitaciones de ancho de banda que impiden que la migración se realice en
el momento oportuno y de forma eficaz, es posible que deba buscar mecanismos de transferencia
alternativos o sin conexión. En el artículo acerca de la replicación de migraciones de Cloud Adoption
Framework explica de qué forma pueden afectar los límites en la replicación a los esfuerzos de migración.
Una parte de la valoración de la migración consiste en consultar a los equipos de TI si el ancho de banda
local y de la WAN puede cumplir los requisitos de la migración. Consulte también el escenario de migración
para el control de los requisitos de almacenamiento que superan la capacidad de la red durante una
migración.
¿Hace uso su aplicación de una canalización de DevOps existente? En muchos casos Azure Pipelines
se puede refactorizar fácilmente para implementar aplicaciones en entornos de hospedaje basados en la
nube.
¿Tienen los datos requisitos de almacenamiento de datos complejos? Las aplicaciones de
producción normalmente requieren un almacenamiento de datos que tenga una alta disponibilidad y que
ofrezca tanto la funcionalidad Always On como características de continuidad y tiempo de actividad del
servicio similares. Las opciones de bases de datos administradas basadas en PaaS de Azure, como Azure SQL
Database, Azure Database for MySQL y Azure Cosmos DB ofrecen contratos de nivel de servicio de tiempo
de actividad del 99,99 %. Por el contrario, una instancia de SQL Server basada en IaaS en una máquina
virtual de Azure ofrece contratos de nivel de servicio de instancia única del 99,95 por ciento. Si los datos no
se puede modernizar para usar las opciones de almacenamiento de PaaS, lo que garantiza que un mayor
tiempo de actividad de IaaS implicará escenarios de almacenamiento de datos más complejos, como la
ejecución de clústeres Always On de SQL Server y la sincronización continua de datos entre instancias. Esto
puede implicar importantes costos de hospedaje y mantenimiento, por lo que es mantener un equilibrio
entre los requisitos de tiempo de actividad, el esfuerzo de modernización y el impacto general en el
presupuesto es importante al considerar las opciones de migración de datos.
Innovación y migración
En consonancia con el énfasis que hace Cloud Adoption Framework en los trabajos de migración incremental,
una decisión inicial acerca de las herramientas y la estrategia de migración no descarta que los futuros
esfuerzos de innovación por actualizar una aplicación para aprovechar las oportunidades que ofrece la
plataforma Azure. Aunque un esfuerzo de migración inicial podría centrarse principalmente en volver a realizar
hospedaje mediante un enfoque de IaaS, debería planear volver a visitar su cartera de aplicaciones hospedadas
en nube con regularidad para investigar las oportunidades de optimización.
Más información
Aspectos básicos de la nube: introducción a las opciones de proceso de Azure : Proporciona
información acerca de las funcionalidades de las opciones de proceso de Azure IaaS y PaaS.
Aspectos básicos de la nube: Elija el almacén de datos apropiado : Describe las opciones de
almacenamiento de PaaS disponibles en la plataforma Azure.
Procedimientos recomendados de migración: Los requisitos de datos superan la capacidad de
la red durante un esfuerzo de migración : Describe mecanismos de migración de datos alternativos para
escenarios en los que migración de datos se ve dificultada por el ancho de banda de red disponible.
SQL Database: Elija la opción de SQL Ser ver correcta en Azure : Explicación de las opciones y las
justificaciones comerciales para elegir hospedar las cargas de trabajo de SQL Server en una infraestructura
administrada (IaaS) o en un entorno de servicios administrados (PaaS).
El Modelo de funcionamiento en la nube es ahora
parte del Marco de adopción de la nube para
Azure
A comienzos de 2018, Microsoft lanzó el modelo operativo de la nube (COM). COM era una guía que ayudaba a
que los clientes entendieran qué era la transformación digital y sus causas. Esto contribuyó a que los clientes
conocieran todas las áreas que se debían abordar: la estrategia empresarial, la estrategia cultural y la estrategia
tecnológica. Lo que no se incluyó en COM fueron los pasos de procedimiento concretos, lo que dejó a los
clientes preguntándose qué hacer a partir de ahí.
Microsoft Cloud Adoption Framework para Azure se ha diseñado para ayudarle a comprender el qué y el por
qué , así como para proporcionar orientación unificada sobre el cómo a fin de ayudar a acelerar los trabajos de
Empleo de procedimientos del Modelo de funcionamiento en la nube

en el Marco de adopción de la nube
Para un enfoque similar al de COM, comience con uno de los siguientes elementos:
Primeros pasos: Creación e innovación en la nube
Consecución del éxito con un modelo operativo sólido
El scaffolding empresarial de Azure ahora es
Microsoft Cloud Adoption Framework for Azure
El scaffolding empresarial de Azure se ha integrado en Microsoft Cloud Adoption Framework for Azure. Ahora,
los objetivos de scaffolding empresarial se abordan en la metodología de preparación de Cloud Adoption
Framework. El contenido de scaffolding empresarial ha quedado en desuso.
Para empezar a usar Cloud Adoption Framework, consulte:
Introducción a la preparación
Consideraciones sobre la zona de aterrizaje
Si necesita revisar el contenido en desuso, consulte Scaffolding empresarial de Azure.
Centro de datos virtual de Azure
Se han creado una implementación y una arquitectura de plataforma más sólidas para compilarlas en el
enfoque anterior del centro de datos virtual de Azure (VDC). Las zonas de aterrizaje a escala empresarial en
Microsoft Cloud Adoption Framework para Azure son ahora el enfoque recomendado si se van a realizar
mayores esfuerzos para la adopción en la nube.
Esta guía es una parte importante de la base para las metodologías de preparación y gobernanza de Cloud
Adoption Framework. Para ayudar a aquellos clientes que quieran realizar esta transición, se han archivado los
siguientes recursos y se mantendrán en un repositorio de GitHub independiente.
Centro de datos virtual de Azure: en este libro electrónico se muestra cómo implementar cargas de trabajo
empresariales en la plataforma de nube de Azure, al tiempo que se respetan las directivas existentes de red y
de seguridad.
Centro de datos virtual de Azure; guía para una migración lift-and-shift: en estas notas del producto se
explica el proceso empresarial que el personal de TI y los responsables de la toma de decisiones pueden usar
para identificar y planear la migración de las aplicaciones y los servidores a Azure mediante un enfoque de
tipo lift-and-shift, para minimizar otros costos de desarrollo adicionales y optimizar las opciones de
hospedaje en la nube.

01 Documentación de Microsoft Cloud Adoption Framework para Azure

Cargado por

Copyright:

Formatos disponibles

01 Documentación de Microsoft Cloud Adoption Framework para Azure

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

01 Documentación de Microsoft Cloud Adoption Framework para Azure

Cargado por

Copyright:

Formatos disponibles

Contents

Cloud Adoption Framework para Azure

Estrategia: define la justifica Planeamiento: alinea los

Listo: Prepare el entorno en Migración: Migre y

Innovación: Desarrolle Control: Controle el

Administración: Organizar: Alinee los

Descripción del ciclo de vida

Uso de la Plataforma de adopción de la nube de Microsoft para Azure

JO URN EY DESC RIP C IÓ N

Contenedores modernos La modernización de los contenedores permite conseguir

SAP en Azure Como parte de nuestro compromiso OneMigrate

A RT ÍC ULO DESC RIP C IÓ N

¿Qué es el aprendizaje automático? Hemos actualizado y ampliado la guía de procedimientos

Procedimientos para enfocar las operaciones de

A RT ÍC ULO DESC RIP C IÓ N

Definición de su convención de nomenclatura

M Ó DULO DESC RIP T IO N

Módulo Información general Introducción básica del marco de trabajo.

Módulo Introducción Presentación de las guías de introducción para acelerar la

Zonas de aterrizaje de Azure Antes de compilar el entorno de nube, comprenda los

Ejemplos de resultados de sostenibilidad Obtenga información sobre cómo la informática en la nube

A RT ÍC ULO DESC RIP C IÓ N

A RT ÍC ULO DESC RIP C IÓ N

Términos Términos que es probable que aparezcan al hablar del

Zonas de aterrizaje de Azure: Opciones de implementación adicionales

A RT ÍC ULO DESC RIP C IÓ N

Opciones de implementación Se ha actualizado para agregar las opciones de zona de

Implementaciones de referencia de escala empresarial Se ha actualizado para agregar una implementación de

A RT ÍC ULO DESC RIP C IÓ N

Windows Virtual Desktop Este escenario permite potenciar la productividad y acelerar

Azure Stack Aprenda a implementar Azure en el centro de datos

Análisis en Cloud Adoption Framework :

A RT ÍC ULO DESC RIP C IÓ N

Inteligencia ar tificial en Cloud Adoption Framework :

A RT ÍC ULO DESC RIP C IÓ N

Inteligencia artificial responsable Obtenga información sobre los principios de inteligencia

A RT ÍC ULO DESC RIP C IÓ N

A RT ÍC ULO DESC RIP C IÓ N

Introducción a la escala empresarial Información general sobre la escala empresarial

Arquitectura de escala empresarial Descripción de la arquitectura subyacente de la escala

Guías de implementación Revise las actividades requeridas para una implementación

A RT ÍC ULO DESC RIP C IÓ N

Administración de la alineación de la organización Establezca estructuras organizativas bien dotadas de

A RT ÍC ULO DESC RIP C IÓ N

Herramientas y plantillas Encuentre las herramientas, plantillas y evaluaciones que

A RT ÍC ULO DESC RIP C IÓ N

Actualizaciones de la metodología de preparación:

A RT ÍC ULO DESC RIP C IÓ N

Refactorización de zonas de aterrizaje Nuevo ar tículo: extraído de los talleres de metodología de

Expansión de la zona de aterrizaje Nuevo ar tículo: se basa en la sección iteraciones paralelas

Mejora de la gobernanza de la zona de aterrizaje Nuevo ar tículo: lista de procedimientos recomendados en

Inicio a escala empresarial Nuevo ar tículo: Demostración de un enfoque que muestra

A RT ÍC ULO DESC RIP C IÓ N

A RT ÍC ULO DESC RIP C IÓ N

Desarrollo e implementación de aplicaciones Nuevo ar tículo: proporciona listas de comprobación,

Diseño y operaciones de clústeres Nuevo ar tículo : proporciona listas de comprobación,

Seguridad de clústeres y aplicaciones Nuevo ar tículo: proporciona listas de comprobación,

A RT ÍC ULO DESC RIP C IÓ N