Este artículo surge con la intención de compartir la experiencia que he adquirido participando en diferentes proyectos relacionados con transformación a Cloud, y el conocimiento que he conseguido durante la preparación de las certificaciones de Arquitecto de Soluciones de Azure, AWS y GCP.

He podido observar que es posible aprovechar los parecidos existentes entre las tres nubes para aumentar el conocimiento de las mismas, y he identificado las principales diferencias y semejanzas que hay que tener en mente tanto para preparar las certificaciones como para trabajar con las mismas.

Este será el primer artículo de una serie que abarcará como mínimo los siguientes puntos:

• Conceptos generales (jerarquía de recursos, regiones y zonas de disponibilidad y modelo de servicio)
• Redes
• Identidad y Seguridad
• Almacenamiento y Bases de Datos
• Proceso
• Integración y otros

Conceptos generales

Hasta la fecha, el mercado mundial de la nube está dominado por diferentes proveedores Cloud como Azure, Amazon, Alibaba, Google, IBM y Oracle, esta serie de artículos se va a centrar en comparar diferentes características de las tres plataformas cloud proporcionadas por Azure, Amazon y Google. No se van a dar recomendaciones de cómo construir aplicaciones en este caso os recomiendo consultar los marcos de buena arquitectura de los tres proveedores, ni de cómo llevar a cabo una transformación a cloud con éxito, si estáis interesados en este último aspecto podéis echar un vistazo a este whitepaper https://www.atsistemas.com/es/novedades/White-Papers/white-paper-cloud-native.

En este primer documento voy a entrar en contacto con las tres plataformas cloud analizando conceptos que serán fundamentales para entender la organización y extraer el máximo provecho de las mismas, primero explicaré la jerarquía de recursos, después detallaré la distribución de dichos recursos en regiones y zonas de disponibilidad, a continuación explicaré los diferentes modelos de servicio en los que se ofrecen estos recursos, y finalmente comentaré como iremos analizando el precio de los mismos a lo largo de esta serie de artículos.

Jerarquía de recursos

El primer contacto que se tiene con una plataforma cloud está relacionado con su jerarquía de recursos, aunque no seamos conscientes de ello desde el momento que se empieza a utilizar la plataforma ofrecida por uno de los proveedores cloud ya hemos hecho uso de su jerarquía, entender y planificar el uso de esta jerarquía cobra una gran importancia cuando el volumen de activos en la nube escala.

Una vez conocida la jerarquía es necesario planificar la organización de los recursos, la cual se puede llevar a cabo en función de diferentes enfoques o mediante una combinación de ellos, por ejemplo:

• Por ciclo de vida planificando la organización para que todos los recursos se agrupen de forma que se puedan crear o eliminar al mismo tiempo.
• Agrupando por tipo, que es lo más adecuado para los servicios que no están asociados con una aplicación.
• Organizando por aplicación es adecuado cuando todos los recursos tienen las mismas directivas y ciclo de vida.
• Planificando por entorno desarrollo, pruebas, producción, permitiendo tener una mayor separación entre los mismos.
• Agrupando por departamento, agrupar por ubicación (región) o agrupar por facturación (centro de costos). Estas estrategias de agrupación no son comunes, pero pueden resultar útiles en alguna situación.
• Generalmente lo mejor es utilizar una combinación de estrategias organizativas.

AWS

En AWS la organización es la siguiente (Mas información en https://docs.aws.amazon.com/es_es/organizations/latest/userguide/orgs_getting-started_concepts.html)

• Organización es una entidad que se crea para consolidar las cuentas AWS. Cada cuenta puede estar directamente en el nodo raíz o colocarse en una de las unidades organizativas de la jerarquía. Una organización tiene la funcionalidad determinada por el conjunto de características habilitadas.
• Nodo raíz es el contenedor principal de todas las cuentas de la organización. Si se aplica una política al nodo raíz, esta se aplica a todas las unidades organizativas y cuentas de la organización. En estos momentos solo se puede disponer de un solo nodo raíz que AWS Organizations crea automáticamente cuando se crea la organización.
• Unidad organizativa (OU), es un contenedor para las cuentas de un nodo raíz. Una unidad organizativa también puede contener otras unidades organizativas. Cuando se asocia una política a uno de los nodos de la jerarquía, esta se transmite y aplica a todas las ramas (unidades organizativas) y hojas (cuentas) que se encuentran debajo. Una unidad organizativa puede tener uno y solo un nodo raíz y cada cuenta puede ser miembro de exactamente una unidad organizativa.
• Cuenta contiene los recursos AWS y las identidades que pueden acceder a esos recursos. El uso de los recursos de AWS requiere tener una cuenta de AWS, ya que todos los servicios se crean, habilitan o utilizan dentro de una cuenta.

Una cuenta de AWS no es lo mismo que una cuenta de usuario. Un usuario de AWS es una identidad que se crea usando AWS Identity and Access Management (IAM) y toma la forma de Usuario de IAM con credenciales a largo plazo, o un rol de IAM con credenciales a corto plazo. Una sola cuenta AWS puede, y normalmente contiene muchos usuarios y roles.

Hay dos tipos de cuentas en una organización: una cuenta única que se denomina la cuenta de administración y una o más cuentas miembro.

 - La cuenta de administración es la cuenta que usa para crear la organización.

 - Las cuentas de miembros componen el resto de cuentas de una organización. Una cuenta no puede pertenecer a más de una organización a la vez.

• Recursos son los diferentes elementos que se pueden crear y administrar ofrecidos por AWS.

Azure

En Azure existen cuatro niveles de administración: grupo de administración, suscripciones, grupos de recursos y recursos (Mas información en https://learn.microsoft.com/en-us/azure/governance/management-groups/overview)

• Los Grupos de Administración permiten 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. Existe un Grupo de administración raíz opcional que agrupa a todos los grupos de administración y suscripciones que se integran en él.
• Las Suscripciones asocian lógicamente las cuentas de usuario con los recursos que crean. Cada suscripción tiene límites o cuotas con respecto a la cantidad de recursos que puede crear y usar. Para usar Azure es necesario disponer de una suscripción, y al menos un grupo de recursos.
• Un Grupo de Recursos es un contenedor lógico en el que se implementan y administran recursos de Azure como aplicaciones web, bases de datos y cuentas de almacenamiento.
• Los Recursos son instancias de servicios ofrecidos por Azure.

GCP

En GCP existen cuatro niveles: organización, carpeta, proyecto y recurso (Mas información en https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy)

• La Organización cuando está presente es el nodo raíz en la jerarquía de recursos de Google Cloud. Es el recurso principal de los recursos de carpetas y proyectos. Las políticas de control de acceso de IAM aplicadas en el recurso de organización se aplican en la jerarquía de todos los recursos de la organización. Los usuarios de Google Cloud no necesitan tener un recurso de organización, pero algunas funciones de Resource Manager no se podrán usar sin uno.
• Las Carpetas que son opcionales proporcionan un mecanismo de agrupación adicional y límites de aislamiento entre proyectos. Estas se consideran suborganizaciones dentro del recurso de organización. Las carpetas se pueden usar para modelar diferentes entidades legales, departamentos y equipos dentro de una empresa. Requiere el uso del recurso organización.
• El Proyecto es la entidad organizadora básica. Los recursos de organización y carpeta pueden contener varios proyectos. Se requiere un recurso de proyecto a fin de usar Google Cloud, y forma la base para crear, habilitar y usar todos los servicios de Google Cloud, administrar las API, habilitar la facturación, agregar y quitar colaboradores, y administrar permisos. Cuando el recurso de la organización no existe, los proyectos son propiedad del usuario que creó el proyecto. En cambio, cuando existe el recurso de la organización, los proyectos son propiedad de la organización.
• Los Recursos son los servicios ofrecidos por GCP y que se pueden crear y utilizar.

Comparación

A continuación voy a comparar los diferentes niveles de la estructura jerárquica, según su semejanza.

AWS	Azure	GCP
Organización/Nodo Raiz	Grupo de Administración raíz	Organización
Unidad organizativa (OU)	Grupo de Administración	Carpetas
Cuentas	Suscripciones	Proyecto
	Grupo de recursos
Recursos	Recursos	Recursos

Leyenda

Opcional

Necesario

Recursos

Dentro de este nivel se encuentra todo el ecosistema de elementos administrables que están disponibles a través del proveedor cloud, estos elementos están agrupados en diferentes categorías que iremos analizando en esta serie de artículos, como por ejemplo elementos de proceso, de almacenamiento y base de datos, de seguridad, de gestión de red, etcétera.

Grupo de recursos

El grupo de recursos como elemento de la estructura jerárquica solo existe en Azure. Existe en AWS como agrupación lógica pero no pertenece a la estructura jerárquica, aun así lo incluyo en la comparativa. En GCP el proyecto se podría asemejar al grupo de recursos pero he optado por tratarlo en el siguiente nivel.

• Un recurso de AWS se puede asignar a varios grupos de recursos, mientras que un recurso de Azure solo se puede asignar a un grupo de recursos
• Los recursos de AWS se pueden agrupar en grupos de recursos a través de etiquetas, mientras que los grupos de recursos de Azure no se pueden crear a través de etiquetas.
• La eliminación de un grupo de recursos de AWS no afectará a los recursos, mientras que la eliminación de un grupo de recursos de Azure eliminará todos los recursos que se encuentran en él.

AWS(Cuenta)-Azure(Subscripción)-GCP(Proyecto)

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.

Una cuenta de AWS puede tener varios grupos de recursos. Con o sin grupos de recursos, una cuenta de AWS puede tener múltiples recursos creados y vinculados a ella. Y es lo mismo para las suscripciones de Azure, como una suscripción de Azure para muchos grupos de recursos (opcional) y para muchos recursos.

Desde el aspecto de la agrupación de grupos de recursos, no hay mucha diferencia en este nivel.

AWS(Unidad organizativa)-Azure(Grupo de administración)-GCP(Carpeta)

Este nivel es opcional en las tres plataformas cloud, ofreciendo mecanismos de agrupación adicional del nivel descrito en el párrafo anterior sobre el nivel que describo a continuación.

AWS(Organización/Nodo Raíz)-Azure(Grupo de administración raiz)-GCP(Organización)

Tanto las organizaciones de AWS como las de Google Cloud controlan no solo los recursos creados, sino también toda la cuenta, incluida la administración de identidad y acceso (IAM) . Por el contrario, los grupos de administración de Azure solo controlan las suscripciones (recursos) en la cuenta (inquilino de Azure AD) .

El recurso de la organización de Google Cloud no consolida varias cuentas de Google Cloud en una organización, como lo hacen las organizaciones de AWS .

Regiones y zonas de disponibilidad

Una de las principales preocupaciones para conseguir que las aplicaciones sean más fiables es la gestión de los errores hardware. Los errores tienen diferente alcance, puede existir un problema en un disco, que afecta a un único equipo host, errores que afectan a todo un centro de datos, como un problema de alimentación, o problemas por los que toda una región dejaría de estar disponible.

En este caso es necesario tener en mente otros dos conceptos que es importante entender por las implicaciones que tiene en diversos aspectos como la alta disponibilidad, el precio, la recuperación ante desastres, etc.

Son las regiones y las zonas de disponibilidad, que se pueden considerar como abstracciones lógicas de recursos físicos que se proporcionan en uno o más centros de datos físicos, para entender ambos conceptos y de una forma general se pueden definir como sigue:

• Región: ubicación física donde el proveedor ubica múltiples zonas de disponibilidad.
• Zonas de disponibilidad: centros de datos aislados, alojados en edificaciones independientes, cada uno con su propia estructura de alimentación, refrigeración, redes y conectividad de fibra óptica pertenecientes a una región.

En el momento de escribir este artículo la infraestructura global de Azure comprende más de 60 regiones y 140 zonas (fuente https://learn.microsoft.com/en-us/training/modules/azure-architecture-fundamentals/regions-availability-zones), la de AWS tiene disponibilidad en 31 regiones geográficas con 99 zonas (fuente https://aws.amazon.com/es/about-aws/global-infrastructure/?p=ngi&loc=1), y la de Google Cloud, es de 35 y 106 zonas (fuente https://cloud.google.com/about/locations?hl=es#regions), respectivamente.

En función de la definición de región y zona, los recursos se pueden clasificar en:

• Zonales operan solo en una zona por lo que una interrupción en la zona de disponibilidad afectará a los recursos ofrecidos en esa zona, un recurso zonal suele ser una máquina virtual.
• Regionales son servicios que ofrecen la posibilidad de implementarse de forma redundante en varias zonas de una región.
• Multirregionales son aquellos recursos que admiten la posibilidad de redundancia entre distintas regiones.

Durante el análisis de los diferentes servicios existentes se indicará las opciones de redundancia que admiten.

En el momento de decidir qué región utilizar es necesario tener en cuenta una serie de factores:

• Distribución de los usuarios de la aplicación (usuarios a nivel global o locales), para reducir las latencias y aumentar la proximidad.
• Coste de los recursos debido a que el coste de los mismos varía entre regiones.
• Seguridad, privacidad y cumplimiento normativo deberán ser tenidos en cuenta si el tipo de aplicación lo necesita.
• Los SLA comprometidos pueden tener un gran impacto en la arquitectura del proyecto.

Otro aspecto importante relacionado con las regiones es la distribución de los diferentes recursos, aunque de forma general están disponibles a nivel global, es necesario conocer los casos en los que esto no se cumple, ya sea por la no disponibilidad de un determinado recurso o la no disponibilidad de todas sus características, porque tiene un impacto directo a la hora de tomar decisiones en el diseño de las aplicaciones.

Modelo de servicio

El modelo de servicio está relacionado con el grado de responsabilidad en diferentes características del recurso entre el usuario y el proveedor, tal como se ve en la siguiente tabla.

Destacan 3 modelos de servicios:
IaaS (Infrastructure as a Service) es un modelo de servicio cloud que consiste en proveer y gestionar recursos de computación (servidores, almacenamiento, redes y virtualización) por Internet. Un ejemplo de IaaS son las máquinas virtuales (por ejemplo AWS EC2, Azure Virtual Machines o Google Compute Engine), las cuales pueden ser creadas a partir de multitud de imágenes existentes o personalizadas, y en las que se puede instalar el software necesitado.

PaaS (Platform as a Service), proporciona un entorno de desarrollo listo para usar en el que los desarrolladores pueden centrarse en escribir y ejecutar código de calidad para crear aplicaciones personalizadas. Un ejemplo de PaaS es Azure App Service, Google App Engine o AWS Elastic Beanstalk.

SaaS (Software as a Service), consiste en distribuir aplicaciones en el Cloud a usuarios a través de Internet. El software se aloja en línea y se pone a disposición de los clientes con un modelo de pago por suscripción o compra. Ejemplos de SaaS son Gmail u Office 365.

Por lo general el modelo de servicio en el que se ofrecen recursos semejantes de las diferentes clouds es el mismo, en el análisis comparativo que vamos a ir desarrollando indicaremos cada caso.

Gestión de costes

El coste es un aspecto que toma una gran importancia cuando se hace uso de la nube, también es cierto que muchas veces genera frustración por que se tiene la expectativa de obtener un abaratamiento de costes y en muchos casos no se llega a percibir. Esto puede ocurrir porque se comparan dos casos diferentes, por ejemplo, una instalación on-premise sin alta disponibilidad, sin opciones de escalabilidad y con carencias en observabilidad, con una instalación en cloud que nos proporciona la alta disponibilidad requerida, que es escalable en función de la demanda y altamente observable, por lo que una diferencia en el coste es perfectamente entendible.

Es de suma importancia llevar a cabo una correcta gestión de costes, debido a que al estar disponibles para uso multitud de servicios que pueden empezar a ser utilizados de manera rápida y sencilla, existe el riesgo de costos inesperados que superan el presupuesto planificado.

Existen tres factores principales que determinan el costo de los servicios de computación en la nube.

• Capacidad de cómputo: la gran mayoría de los recursos disponibles necesitan capacidad de cómputo, el tiempo de uso necesario, además del número de CPUs, GB de memoria, sistema operativo tienen una repercusión directa en el coste.
• Uso de red: la cantidad de datos transferidos hacia o desde el servicio influyen en el coste del mismo.
• Capacidad de almacenamiento: al igual que con la capacidad de cómputo muchos recursos requieren almacenamiento, afecta al precio final dependiendo de tipo de datos, tamaño de almacenamiento, requisitos de redundancia.

Además, el precio se ve influido por multitud de variables que influirán en los costos, lo que hace que las comparaciones directas entre los proveedores sean un verdadero desafío, entre otras opciones se debe de tener en consideración:

• Modelo de suscripción: compra por segundo, minuto, hora, día, mes o año.
• Modelo de pago: optando por el pago por uso, instancias reservadas o un modo de contrato a largo plazo.
• Ubicación: donde se encuentra su centro de datos.
• Nivel del servicio: además de lo indicado anteriormente cada servicio se proporciona en diferentes niveles, con costes y prestaciones variables, teniendo que hacer una estimación del uso previsto para poder seleccionar el nivel mas apropiado.

Los tres proveedores ofrecen diferentes herramientas que permitirán una correcta gestión de costes buscando obtener las prestaciones que se necesitan a un coste adecuado. La gestión costes ayuda a optimizar el uso de los recursos para aprovecharlos al máximo.

Estas herramientas se pueden agrupar en calculadoras de precios, y gestión de costes.

Mediante las calculadoras de precios siempre y cuando se conozcan los recursos de la nube que se necesitan, se puede dar el primer paso para construir una estimación de precios:

• Calculadora de precios de GCP
• Calculadora de precios del Azure
• Calculadora de precios de AWS

Además de estas calculadores de precios, existe herramientas especificas para la gestión de los costes

• Herramienta de gestion de costes de Azure
• Explorador de costes de AWS
• Gestión de costes de GCP

A lo largo de estos artículos cuando se estudien los diferentes servicios se compararán los precios entre las tres plataformas cloud, y se indicará como se puede actuar para optimizar los costes.

Conclusión

Este primer post me ha permitido mostrar las similitudes y diferencias entre las tres plataformas cloud que estoy tratando.

La comparación ha comenzado con la jerarquía de recursos, que tiene una importancia fundamental cuando escala el uso de la cloud, aunque se pase por alto su existencia, sobre todo en los inicios, la jerarquía en los tres casos esta organizada por niveles, que tienen una consideración diferente en cada una de las plataformas.

He comentado lo que son las regiones y zonas de disponibilidad concepto que empezó utilizando Amazon y ha sido aplicado con pocas modificaciones por Azure y GCP, siendo con pocos matices igual en las tres.

Uno de los puntos que se irá tratando durante la serie será el coste de las diferentes opciones existentes en AWS, Azure y GCP, en este primer artículo he indicado los puntos que repercuten en el precio.

Además, he tratado el concepto modelo de servicio que será de utilidad cuando se comparen los recursos ofrecidos por los tres proveedores. Es importante tenerlo en cuenta porque servicios semejantes, pero con distinto modelo de servicio implican cambio de responsabilidad entre usuario y proveedor, modificando el tratamiento del mismo.