Compartir vía


Azure para profesionales de Google Cloud

En este artículo se ayuda a los expertos en Google Cloud a conocer los conceptos básicos de las cuentas, la plataforma y los servicios de Microsoft Azure. También cubre las principales similitudes y diferencias entre las plataformas Azure y Google Cloud [tenga en cuenta que Google Cloud antes se llamaba Google Cloud Platform (GCP)].

Aprenderá a realizar los siguientes procedimientos:

  • Cómo se organizan las cuentas y los recursos en Azure
  • Cómo se estructuran las soluciones disponibles en Azure
  • Diferencias entre los principales servicios de Azure de los de Google Cloud.

Azure y Google Cloud han creado sus funcionalidades de manera independiente a lo largo del tiempo, por lo que tienen importantes diferencias tanto en implementación como en diseño.

Introducción a Azure para Google Cloud

Al igual que Google Cloud, Microsoft Azure se crea en torno a un conjunto básico de servicios de proceso, almacenamiento, base de datos y red. En muchos casos, ambas plataformas ofrecen una equivalencia básica entre los productos y servicios que ofrecen. Tanto Google Cloud como Azure permiten crear soluciones de alta disponibilidad basadas en hosts de Linux o Windows. Por lo tanto, si está acostumbrado a desarrollar con tecnología de Linux y OSS, ambas plataformas pueden servir.

Aunque las funcionalidades de ambas plataformas son similares, los recursos que proporcionan dichas funcionalidades con frecuencia se organizan de forma diferente. No siempre están claras las relaciones exactas uno a uno entre los servicios necesarios para crear una solución. Existen otros casos donde un determinado servicio puede ofrecerse en una plataforma, pero no en la otra.

Administración de cuentas y suscripciones

Azure tiene una jerarquía de grupos de administración y suscripciones y grupos de recursos para administrar los recursos de forma eficaz que es similar a la jerarquía de carpetas y proyectos para los recursos de Google Cloud.

En el diagrama se muestra una estructura de árbol con grupos de administración como raíz, suscripciones y grupos de recursos como nodos hoja.

Niveles de Azure del ámbito de la administración

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

Los servicios de Azure se pueden adquirir mediante varias opciones de precios, según el tamaño y las necesidades de su organización. Consulte la página de información general de precios para más información.

Las suscripciones de Azure son una agrupación de recursos con un propietario asignado que es responsable de la facturación y de la administración de los permisos.

Un proyecto de Google Cloud es conceptualmente similar a la suscripción de Azure, en términos de facturación, cuotas y límites. Sin embargo, desde una perspectiva funcional, un proyecto de Google Cloud es más parecido a un grupo de recursos en Azure. Es una unidad lógica en la que se implementan los recursos en la nube.

Tenga en cuenta que, a diferencia de Google Cloud, no hay un número máximo de suscripciones a Azure. Cada suscripción de Azure está vinculada a un único inquilino de Microsoft Entra (una cuenta, en términos de Google Cloud). Los inquilinos de Microsoft Entra pueden contener un número ilimitado de suscripciones, mientras que Google Cloud tiene un límite predeterminado de 30 proyectos por cuenta.

Las suscripciones se asignan a tres tipos de cuentas de administrador:

  • Administrador de cuenta. El propietario de la suscripción y la cuenta a la que se facturan los recursos usados en dicha suscripción. El administrador de cuenta solo puede cambiarse mediante la transferencia de propiedad de la suscripción.
  • Administrador de servicios. Esta cuenta tiene los derechos necesarios para crear y administrar recursos en la suscripción, pero no es responsable de la facturación. De forma predeterminada, el administrador de cuenta y el administrador de servicios se asignan a la misma cuenta. El administrador de cuenta puede asignar un usuario distinto a la cuenta del administrador de servicios para administrar los aspectos técnicos y operativos de una suscripción. Solo se asigna un administrador de servicios por suscripción.
  • Coadministrador. Puede haber varias cuentas de coadministrador asignadas a una suscripción. Los coadministradores no pueden cambiar el administrador de servicios, pero, por lo demás, tienen control total sobre los recursos de la suscripción y los usuarios.

Para la administración del acceso específico a los recursos de Azure, puede usar el control de acceso basado en rol de Azure (Azure RBAC), que incluye más de 70 roles integrados. También podemos crear nuestros propios roles personalizados.

Por debajo del usuario de nivel de suscripción también se pueden asignar roles y permisos individuales a recursos concretos. En Azure, todas las cuentas de usuario están asociadas con una cuenta Microsoft o una cuenta de organización (una cuenta administrada mediante Microsoft Entra ID).

Las suscripciones tienen límites y cuotas de servicio predeterminados. Para ver una lista detallada de estos límites, consulte Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure. Estos límites se pueden aumentar hasta el máximo mediante la presentación de una solicitud de soporte técnico en el portal de administración.

Consulte también

Administración de recursos

El término "recurso" en Azure significa cualquier instancia de proceso, objeto de almacenamiento, dispositivo de red u otra entidad que se puede crear o configurar dentro de la plataforma.

Los recursos de Azure se implementan y administran mediante uno de estos dos modelos: Azure Resource Manager o el modelo de implementación clásica de Azure que es más antiguo. Los nuevos recursos se crean mediante el modelo de Resource Manager.

Grupos de recursos

Además, Azure tiene una entidad llamada "grupos de recursos" que organiza los recursos, como máquinas virtuales, almacenamiento y dispositivos de red virtuales. Un recurso de Azure siempre está asociado a un solo grupo de recursos. Un recurso creado en un grupo de recursos se puede mover a otro grupo, pero no puede estar en dos grupos a la vez. Para más información, consulte Traslado de recursos de Azure entre grupos de recursos, suscripciones o regiones. Los grupos de recursos son la agrupación fundamental que se usa en Azure Resource Manager.

Los recursos también se pueden organizar mediante etiquetas. Las etiquetas son pares de clave-valor que le permiten agrupar los recursos de su suscripción con independencia de la pertenencia al grupo de recursos.

Interfaces de administración

Azure ofrece varias maneras de administrar los recursos:

  • Interfaz web. Azure Portal proporciona una interfaz de administración completa basada en web para los recursos de Azure.
  • API DE REST. La API de REST de Azure Resource Manager proporciona acceso mediante programación a la mayoría de las características disponibles en Azure Portal.
  • Línea de comandos. La CLI de Azure proporciona una interfaz de la línea de comandos capaz de crear y administrar recursos de Azure. La CLI de Azure está disponible para Windows, Linux y macOS.
  • PowerShell. Los módulos de Azure para PowerShell permiten ejecutar tareas de administración automatizadas mediante un script. PowerShell está disponible para Windows, Linux y macOS.
  • Plantillas. Las plantillas de Azure Resource Manager proporcionan funcionalidades de administración de recursos basadas en plantillas JSON.
  • SDK. Los SDK son una colección de bibliotecas que permite a los usuarios administrar e interactuar con los servicios de Azure mediante programación.

En cada una de estas interfaces, el grupo de recursos ocupa un lugar central en la creación, la implementación o la modificación de los recursos de Azure.

Además, muchas herramientas de administración de terceros como Terraform, de Hashicorp, y Netflix Spinnaker, están también disponibles en Azure.

Consulte también

Regiones y zonas de disponibilidad

El alcance de los errores puede variar. Algunos errores de hardware, como un problema en un disco, pueden afectar a un único equipo host. Un error en un conmutador de red podría afectar a todo un bastidor del servidor. Menos frecuentes son los errores que afectan a todo un centro de datos, como los problemas de alimentación. En situaciones excepcionales, una región completa podría dejar de estar disponible.

Uno de los mecanismos para conseguir que una aplicación sea resistente es la redundancia. Sin embargo, esta redundancia debe planearse al diseñar la aplicación. De igual forma, el nivel de redundancia necesario depende de los requisitos empresariales. No todas las aplicaciones necesitan redundancia entre regiones para protegerse frente a una interrupción regional. En general, existe un equilibrio, ya que una mayor redundancia y confiabilidad implica una mayor complejidad y unos costos más elevados.

En Google Cloud, una región tiene dos, o más, zonas de disponibilidad. Una zona de disponibilidad se corresponde con un centro de datos físicamente aislado en la región geográfica. Azure dispone de muchas características para proporcionar redundancia de aplicación en todos los niveles de posibles errores. Entre estas características cabe destacar los conjuntos de disponibilidad, las zonas de disponibilidad y las regiones emparejadas.

En la tabla siguiente se resume cada opción.

Conjunto de disponibilidad Zona de disponibilidad Región emparejada
Alcance del error Bastidor Centro de datos Region
Enrutamiento de solicitudes Load Balancer Equilibrador de carga entre zonas Traffic Manager
Latencia de red Muy baja Bajo Media-alta
Redes virtuales VNet VNet Emparejamiento de VNet entre regiones

Conjuntos de disponibilidad

Para protegerse frente a errores de hardware localizados, como un error en un conmutador de red o un disco, implemente dos o más máquinas virtuales en un conjunto de disponibilidad. Un conjunto de disponibilidad se compone de dos o más dominios de error que comparten una fuente de alimentación y un conmutador de red. Las máquinas virtuales incluidas en un conjunto de disponibilidad se distribuyen entre los dominios de error, por lo que, si un error de hardware afecta a un dominio de error, el tráfico de la red puede enrutarse a las máquinas virtuales de otros dominios de error. Para más información acerca de los conjuntos disponibilidad, consulte Administración de la disponibilidad de las máquinas virtuales Windows en Azure.

Cuando se agregan instancias de máquina virtual a conjuntos de disponibilidad, también se asignan a un dominio de actualización. Un dominio de actualización es un grupo de máquinas virtuales que están configuradas para eventos de mantenimiento planeado al mismo tiempo. Distribuir máquinas virtuales entre varios dominios de actualización garantiza que, en cualquier momento dado, los eventos de actualización planeada y aplicación de revisiones solo afectan a un subconjunto de estas máquinas virtuales.

Los conjuntos de disponibilidad se deben organizar mediante el rol de la instancia de la aplicación para garantizar que una instancia de cada rol esté operativa. Por ejemplo, en una aplicación web de tres niveles, puede crear conjuntos de disponibilidad diferentes para los niveles de front-end, aplicación y datos.

Diagrama que contiene los conjuntos de disponibilidad para un nivel web con instancias web, un nivel de aplicación con instancias de aplicaciones y un clúster de datos con instancias de bases de datos.

Conjuntos de disponibilidad

Zonas de disponibilidad

Al igual que en Google Cloud, las regiones de Azure pueden tener zonas de disponibilidad. Una zona de disponibilidad es una zona separada físicamente dentro de una región de Azure. Cada zona de disponibilidad tiene una fuente de alimentación, una red y un sistema de refrigeración distintos. Cuando las máquinas virtuales están implementadas en diferentes zonas de disponibilidad, es más fácil proteger una aplicación frente a errores que afectan a todo el centro de datos.

Diagrama que muestra una implementación de máquina virtual con redundancia de zona con una región que contiene tres zonas con una subred que cruza las tres zonas.

Implementación de máquina virtual con redundancia de zona en Azure

Para obtener más información, consulte Recomendaciones para el uso de zonas de disponibilidad y regiones.

Regiones emparejadas

Para proteger una aplicación frente a una interrupción regional, puede implementar la aplicación en varias regiones y utilizar Azure Traffic Manager para distribuir el tráfico de Internet en las distintas regiones. Cada región de Azure está emparejada con otra región. Juntas, forman un par regional. A excepción del Sur de Brasil, los pares regionales se encuentran en la misma ubicación geográfica para, de este modo, cumplir los requisitos de residencia de datos a efectos de jurisdicción fiscal y aplicación de las leyes.

A diferencia de Availability Zones, que son centros de datos físicamente alejados, pero que pueden estar relativamente cerca de áreas geográficas, las regiones emparejadas suelen estar alejadas unas de otras 500 km como mínimo. Este diseño garantiza que los desastres a mayor escala solo afectarán a una de las regiones del par. Los pares vecinos pueden establecerse para sincronizar los datos del servicio de base de datos y almacenamiento, y están configurados de tal modo que las actualizaciones de la plataforma solo se implementan en una región del par a la vez.

El almacenamiento con redundancia geográfica de Azure se copia automáticamente en la región emparejada apropiada. En el caso de todos los demás recursos, la creación de una solución completamente redundante mediante regiones emparejadas implica la creación de una copia completa de la solución en ambas regiones.

En el diagrama se muestran los pares de regiones en Azure, en el que la geografía contiene un par de regiones, que contiene dos regiones, cada una de las cuales contiene centros de recursos.

Pares de regiones en Azure

Consulte también

Servicios

Para obtener una lista de cómo se asignan servicios entre plataformas, consulte la comparación entre los servicios de Google Cloud y los de Azure.

No todos los servicios y productos de Azure están disponibles en todas las regiones. Consulte la página Productos por región para más información. Las garantías de tiempo de actividad y las directivas de crédito de tiempo de inactividad de cada producto o servicio de Azure pueden encontrarse en la página Acuerdos de Nivel de Servicio.

Pasos siguientes