Las 3 plataformas más famosas del mundo para tener infraestructura en la nube son claramente AWS de Amazon, Azure de Microsoft y Google Cloud de... mmm, bueno, de Google.
En esta ocasión vamos a facilitarles la toma de decisiones con el poder de los datos, ahora aplicado a cómo entender qué opciones tenemos cuando se trata de infraestructura en la nube. De más está decirles que las 3 opciones seleccionadas (Microsoft, Amazon y Google) son todas muy buenas, aunque dado que son las 3 más grandes y famosas, hay elementos que valen la pena más en unas que en otras.
Si bien entendemos que no siempre puedes escoger la nube que más te gustaría, ya que a veces ya hay una política corporativa que indica cuál utilizar y te tendrás que adaptar a lo que tienes a tu disposición y lo cierto es que siempre hay una solución para cada problema.
Esta es la razón principal por la que en Analytics Town somos agnósticos de nube, para poder adaptarnos al escenario que tenga cada uno de nuestros clientes de forma independiente (aunque les confieso que hemos hecho muchos más proyectos en Azure que en las otras).
En vista de todo lo anterior, compartimos un diagrama muy ejemplificador (créditos a Satish Gupta) sobre qué opciones tenemos para trabajar distintos tipos de bases de datos en las nubes más famosas:
Si vamos a ser "simplistas", podríamos dividir nuestras opciones de la siguiente manera:
Para Datos Estructurados, podríamos necesitar trabajar con una tabla relacional de tipo OLTP (la que funciona en tiempo real y debe estar conectada en ambos puntos del data-point), ya que cuando necesitamos trabajar algún caso donde precisamos que la información esté disponible y actualizada en el momento de forma inmutable (como, por ejemplo, un movimiento bancario donde debe quedar registrada una transacción tanto en el extremo del usuario que usó su tarjeta en un punto de venta como en la base del banco que debitó el dinero de la cuenta correcta). Para estos casos podemos utilizar RDS en AWS, Azure SQL en Azure y Cloud SQL o Spanner en Google Cloud.
Así también para casos de datos estructurados pero del tipo OLAP (los que utilizan datos agregados históricos que en algún momento pudieron ser OLTP) para trabajar tablas basadas en columnas que permitan darnos la capacidad de hacer Analytics del bueno y BI del mejor cuando trabajamos con AWS Redshift, Azure Synapse con Microsoft o Google Big Query en GCP.
Si, por el contrario, lo que necesitamos es trabajar con datos No-Estructurados, podemos aprovechar las capacidades que las nubes nos brindan para reacondicionar los datos. Por ahora vamos a centrarnos más que nada en el storage (almacenamiento) para no desenfocarnos, pero este caso de uso es compatible perfectamente con Amazon S3 en AWS, los Blob Storage de Azure y Cloud Storage de Google Cloud. Básicamente estamos hablando de unidades de almacenamiento.
Aquí queremos hacer una breve pausa, porque si estás corto de dinero y estás buscando algo por fuera de las nubes tradicionales, tienes también opciones de tecnología "agnóstica" que puedes hacerlas correr incluso sin necesidad de ninguna nube.
Tal es el caso de una de nuestras favoritas: el sistema de ficheros distribuidos HDFS, la solución de Big Data de Hadoop. Esta tecnología es posible correrla con algunas máquinas conectadas al mismo cluster, las cuales dividirán entre ellas la capacidad de procesamiento, almacenamiento y delivery de los datos. Incluso en Analytics Town hemos hecho algunos experimentos donde pusimos a correr un cluster con máquinas virtuales dentro de la misma computadora y funcionó.
Después hablamos de performance, que es otra historia. ¡Y vamos! que no nos puedes negar que uno de los mejores atributos de HDFS y Hadoop es la ternura que produce su logo de elefantito amarillo, que es de lo más simpático.
Y finalmente llegamos al momento más largo y escabroso de esta historia: los datos semi-estructurados. Para estos casos hay una gran variedad, que tratatemos de comentar brevemente.
Si precisas armar diccionarios Key-Value (o clave valor) podrías utilizar DynamoDB en AWS, CosmoDB en Azure y Big Table de Google Cloud.
Si más bien necesitas utilizar diccionarios de tipo In-Memory construyendo caché, te puede servir muy bien ElastiCache de AWS, Azure Cache for Redis (Azure) y Memory-Store de Google Cloud.
En los casos en los cuales desees aplicar tablas con columnas amplias (Wide Column) bajo un formato Key-Value de 2 dimensiones, puedes utilizar Keyspaces de AWS, CosmoDB en Azure y Big Table con Google Cloud.
Por lo pronto, si lo que estás trabajando es una base de series de tiempo (Time-Series), perfectamente podrías utilizar Timestream de AWS, CosmoDB en Azure y Big Table o Big Query en Google Cloud.
Ahora bien, si lo que estás construyendo son bases inmutables de tipo "Audit Trail", vas a querer conocer Quantum Ledger Database (QLDB) en Amazon Web Services, Azure SQL Database Ledger en Microsoft (sí, el nombre es más largo de lo nos gustaría) y en este caso Google no tiene una solución nativa para esto (o al menos nosotros no la conocemos).
Si ese fuera el caso y sí o sí tienes que utilizar Google Cloud, siempre podrías armarte una máquina virtual y ponerle a correr Hyperledger Fabric que es tecnología agnóstica, aunque ya pasamos Halloween como para estar armando Frankensteins extraños.
Asimismo, cuando tu caso de uso pasa por armar bases de geolocalización y armados geo-espaciales, puedes utilizar Keyspaces de AWS, CosmoDB de nuevo en Azure o Big Table/Big Query del "Big" Google que tanto le importa el tamaño. Cualquier cosa, conocemos a colegas cercanos que utilizaron una base en MongoDB con GeoJSON y con eso se sentían cómodos.
Para ir cerrando este diagrama, nos quedan 2 elementos que son más o menos nuevos, pero que creemos que van a cobrar una relevancia gigantesca en los próximos años.
Para entidades relacionales que requieran de poner a correr Graphos (nos ha pasado con proyectos de Knowledge Mining) podrías utilizar Neptune de AWS, Otra vez CosmoDB en Azure y Janus Graph en Google Cloud.
Por otro lado, podríamos correr motores de búsqueda en texto (sí, tipo un Google o Bing) con OpenSearch / Cloud Search de AWS, Cognitive Search de Azure o Search Apis de Google sobre el DataStore (como que Google supiera algo de motores de búsqueda, jeje).
Y bueno... después de toda esta laaarga jornada explicando qué servicios o aplicativos podrían usar para distintos casos de uso en la tres nubes (y sumar un puntito a nuestro elefantito amarillo favorito) podemos pasar a comparar un poco de performance entre las 3 nubes en batalla.
¿A quién erigirías si tuvieras alguna de las siguientes necesidades de infraestructura?
Y el ganador es...
En un estudio hecho por el equipo de The Stack en 2021 probaron y pusieron a competir los servicios de las 3 nubes bajo condiciones extremas en laboratorio, arrojando los resultados que pueden ver en la imagen arriba. Para tomar esta determinación realizaron en cada laboratorio unos 1000 test para establecer la performance de cada proveedor en esa cantidad de evaluaciones.
De las 12 categorías testeadas, verás que el que más victorias obtuvo para quedarse en el primer lugar fue Google Cloud. El que logró mayor incidencia como segundo lugar fue nuevamente Google y el que logró la mayor cantidad de 3eros lugares fue Amazon.
Claramente cuando vimos estos resultados nos quedamos bastante sorprendidos, puesto que sinceramente no lo esperábamos. Si nos hubieran preguntado que creíamos que sería el resultado (puramente de estómago, súper subjetivo) hubiéramos respondido que Azure o AWS, pero ni en nuestros mejores sueños pensamos que Google daría ese resultado.
Por otro lado, cuando lo que comparamos es la Performance de múltiples Core o GPU, el escenario cambia. En este caso el ganador es claramente AWS.
Y si lo que buscas es la capacidad de lectura y escritura de los documentos, bases de datos y demás, el que gana en esa categoría es Microsoft Azure.
Por lo tanto, aquí podemos interpretar al menos 2 situaciones:
1- Los test de laboratorio comparan escenarios que no necesariamente van a suceder en vida real, pero qué bueno es poner a prueba los equipos y ver hasta dónde llega su capacidad.
2- Dependiendo de qué necesites hacer es que podrías llegar a elegir la nube correcta, aunque lo más seguro es que termines utilizando aquella que tenga convenio con la compañía con la que trabajas, independientemente de las prestaciones.
!Todas son buenísimas! Aunque tomemos en cuenta que no hay una sola respuesta para todo.
No existe tal cosa como "¿cuál nube es mejor?" porque todas son la mejor en algo y todas son la peor en algo. Todo dependerá de cuál sea tu caso de uso y de qué forma vayamos a encarar el proyecto o necesidad que se presente.
Si te resultó confuso algo de todo lo que está aquí expuesto, no dudes en ponerte en contacto con nosotros, ya que todo el equipo de Analytics Town estará dispuesto a ayudarte.