Hablamos de los dos principales proveedores de servicios Cloud, pero pongámonos primero en el contexto de lo indiscutible: Amazon Web Services es el actual líder de mercado de los servicios cloud. Lo viene siendo desde hace años, fue el “early adopter” de los servicios cloud, y el resto de compañías vinieron después.

Azure es el rival más fuerte, aunque sigue siendo segundo en las quinielas. Lo que sí ha sido remarcable es la velocidad con la que Azure ha ido ganando mercado hasta poder competir más de tú a tú con el indiscutible líder pese a lanzarse como vendor de Cloud Services varios años más tarde. Veamos un cuadro comparativo de 2016 de una encuesta sobre distintos servicios de Cloud. AWS tiene una posición muy consolidada, sin embargo, la intención de uso y la experimentación por parte de las empresas con Azure es mayor, y podría, en el futuro ir ganando cuota de mercado.

¿Qué ha propiciado tal ascenso de Azure? Lo fácil sería irnos a https://azure.microsoft.com/es-es/overview/azure-vs-aws/ y dejar que el marketing haga lo demás. Pero vamos a intentar excavar y llegar un poco más al meollo de la cuestión, aunque sea en lo que se refiere al concepto general de ambos vendors.

AWS y Azure: Cuestión de bricolaje infraestructural.

En este Amazon Summit 2018, el Dr. Werner Vogels, CTO de la compañía, dio una conferencia de apertura, en la que utilizó un interesante punto de comparación, en el que creo que podrían pivotar varias cuestiones en lo referente al distinto enfoque entre AWS y Azure: Comentó que hay vendors de servicios Cloud que venden “casas prefabricadas”, mientras que definía AWS como una serie de herramientas para que la gente pudiera construir su vivienda a medida.

Esta filosofía parecía impregnar todo el Summit. No se hablaba tanto de “plataformas” como tal, sino de “servicios” que se unían unos a otros para desarrollar aplicaciones, automatizar tareas, securizar datos y sobre todo, la piedra angular del cloud computing: adaptar la infraestructura a la demanda, flexibilizando la capacidad del hardware para reducir costes y facilitar la escalabilidad si así fuese necesario.

No hay que olvidar que esa S de AWS viene de Services, y que como tales, vienen muchas veces de third-parties, compañías que desarrollan servicios y los implementan en el Marketplace de AWS para ampliar todavía más esa “caja de herramientas” de la que nos habla Vogels. Si bien es cierto que en cuestión de “soluciones” (parece que así llaman a los Services) AWS cuenta con un catálogo más amplio que Azure (cosa lógica, por otra parte, dado su amplio rodaje en el mundo del Cloud).

Pero ¿Qué enfoque tiene Azure? ¿Tiene algún punto fuerte sobre el rival a batir?

Azure presenta más posibilidades de PaaS. Tiene más modelos de “casas prefabricadas”, a costa de menos “herramientas” en la caja de herramientas. Tiene menos integración de soluciones third-party. Pero eso ¿Es malo? Seguramente para aquellos que quieren una solución más tailor-made, puede ser problemático, porque se reducen las opciones, pero para un despliegue más rápido de soluciones ya configuradas, podría ser ventajoso, siempre y cuando sea ese esquema de aplicaciones ya hechas el que se desea.

Otra cuestión importante a tener en cuenta por parte del contendiente Cloud de Microsoft es que, la contrapartida de no tener tantas soluciones third-party es que se ha enfocado más a la integración de otros productos de Microsoft. Algunos de ellos muy extendidos en entornos corporativos como Office, dando pie a implementaciones potentes de entornos híbridos con tales aplicaciones corporativas.

Sin embargo, el “approach” es algo que puede cambiar (y de hecho cambia, y cambia muy a menudo), de forma que ambos vendors van poco a poco ofreciendo propuestas similares a su rival. Azure busca más implementación de soluciones third-party, mientras mantiene su integración con los productos de Microsoft ya conocidos (y no solo Office, también la integración con Windows y con Active Directory, presentes ambos en entornos empresariales), y AWS busca soluciones que intenten cerrar el “gap” de necesitar especialistas en AWS, así como especialistas en diversas áreas de desarrollo para alcanzar esa “casa hecha a medida” que menciona Vogels (el regreso a modelos gestionados de Kubernetes daba la sensación de que AWS busca el difícil equilibrio entre la facilidad de entrega y la customización por parte del cliente, mientras que Azure juega con el también truculento balance de ofrecer lo ya conocido, pero con vistas a diversificarlo en integraciones de terceros). Porque al final, hay situaciones y «situaciones», en las que tal vez puedas construir la casa, o tal vez te venga mejor la estructura ya hecha. Es todo cuestión de cómo enfoquemos este bricolaje de la infraestructura.

https://www.simplilearn.com/aws-vs-azure-cloud-certification-article

 

Comparativa de Data Lakes: Amazon Data Lake Solutions / Azure Data Lake

¿Data Lake? ¿Qué es y para qué puede servir?

Arranquemos por lo básico. El llamado Big Data busca extraer información valiosa (a veces descriptiva, teniendo una visión global de un conjunto complejo de datos y a veces predictiva, a partir de la información conocida) a partir de un conjunto de datos muy numeroso (hablamos de Petabytes de datos). Estos datos “per se” no son información valiosa, pero sí son la materia prima con la que se obtendrá esa información valiosa, a través de diferentes métodos de análisis (Técnica estadísticas, reglas de asociación, clasificaciones, integraciones de datos multi-fuente, ensemble learning…).

Lo problemático está en que al no saber qué análisis se realizarán o se podrían realizar sobre ese conjunto de datos, a veces es conveniente simplemente guardar los datos “brutos” en grandes espacios de almacenamiento a la espera de decidir o definir los métodos de análisis que se les aplicarán. Estos datos brutos, en tanto que pueden provenir de diversas fuentes, tienen diversos formatos, y necesitan espacios en los que tengan cabida datos no estructurados, tanto relacionales como no relacionales. Aquí es donde entran en acción los llamados Data Lakes.

Esto de Data Lake suena bonito pero ¿No parece otra forma de llamar al almacenamiento que ya conocemos?

Es algo más que almacenamiento. Además del necesario espacio para guardar tal cantidad de datos, en tanto que la intención es analizar esos datos, se necesitan también herramientas para desglosarlos y tratarlos de múltiples maneras (ya se mencionó que en los Data Lakes no tienen por qué entrar datos estructurados ni relacionales, pero de cara a labores de análisis, es necesario procesarlos en mayor o menor medida), ya que las soluciones de Data Lake se hacen siempre con vistas al análisis de datos, no exclusivamente para “mantenerlos ahí” hasta que se integre una herramienta de análisis a posteriori.

Ante las capacidades flexibles y adaptativas del Cloud, Azure y Amazon han lanzado sus soluciones de Data Lake. Vemos algunos parecidos y diferencias.

Azure Data Lake: Storage y Analytics es la pareja de ases.

El formato de Microsoft sigue la filosofía de dar soluciones más “terminadas” a costa de tener menos “abanico” de piezas. Data Lake Store y Data Lake Analytics parecen los dos principales pilares del servicio (luego tiene HDInsights: su solución OpenSource optimizada para otros frameworks como Hadoop). Con el formato de Microsoft a la hora de ofrecernos las soluciones Data Lake, tal vez podamos entender mejor la morfología de estas soluciones.

Data Lake Store es la parte estrictamente de storage (tal vez nos tengamos que retractar sobre el párrafo anterior, ya que Data Lake Store es principalmente eso: almacenamiento), y todo lo que ello conlleva: escalado dinámico para maximizar el rendimiento en función de los requisitos (en este caso, de la carga de trabajo), y la seguridad de esos datos, tanto en reposo como en tránsito, respaldándose en certificaciones SSL así como en otra pieza de Azure: los Key Vaults.

Para la gestión del Data Lake Store Azure dispone de su portal, pero también se puede gestionar por AzureCLI, por PowerShell (módulo AzureRM) y permite también el uso de .NET, Java y NodeJS.

La segunda pieza es Data Lake Analytics, que es la parte encargada de tratar y analizar estos macrodatos que tenemos almacenados usando lenguajes conocidos como .NET, Ruby o Python, agregando en este caso un lenguaje de queries llamado U-SQL para poder llevar a cabo diferentes tareas de análisis.

Dado que permite crear programas para tratar estos datos, Microsoft Insights también entra en juego, ayudando a depurar el código, previendo posibles fallos a medida se ejecutan. Data Lake Analytics permite también integrar datos desde otras fuentes como bases de datos Azure SQL.

Amazon Data Lake: Toda una baraja para los artesanos del código.

AWS sin duda parte de otra mentalidad, la idea de que una solución debe ser “óptima”, no necesariamente “inmediata”. Desplegar un DataLake de AWS implica levantar una serie de servicios mucho más completa y compleja: Amazon Cognito hace de app de autenticación, pero luego, el Data Lake que se muestra hacia el usuario a través de una API Gateway va conectado a un AWS Lambda, que gestiona múltiples microservicios, no sólo el Data Lake S3 como tal, sino también los servicios de roles IAM, los logs con CloudWatch, una base de datos (el ejemplo usa DynamoDB) y Amazon ElasticSearch. Pero puede usar más soluciones desarrolladas para Big Data como Clusters EMR o DataWarehouses Amazon Redshift.

Como base del Data Lake, queda este esquema, que además es únicamente el esquema del Data Lake con los parámetros por defecto.

 

La idea es que, una vez desplegados e integrados estos microservicios, la consola de uso (la Data Lake CLI que figura abajo a la izquierda) permite usar sus propios comandos o APIs REST.

Aquí, el “bucket” donde se guardan los datos es el S3, que es el almacenamiento seguro de AWS (Simple Storage Service). Se mantiene la DB como un registro de cambios en la metadata, y gracias a ElasticSearch se puede empezar a trabajar en el análisis de estos datos. El almacenamiento presenta opciones para replicación multi-zona, y gracias a Amazon Macie, se identifica de forma automática la información que puede considerarse confidencial, con opciones de cifrado usando el Key Management Service y cifrados que permiten integrar más servicios de AWS aparte de los presentes en el ejemplo. Permite también automatizar los despliegues usando scripts de CloudFormation, que admite YAML y JSON. También se pueden importar datos desde Amazon Athena a almacenamiento S3 usando SQL estandarizado.

Una vez desplegado el entorno, las labores de análisis se dejan más en manos de ElasticSearch en este caso, aunque existen muchas más soluciones de análisis de Big Data en el catálogo de Amazon, y probablemente cada una tenga sus propios métodos, herramientas, comandos y casos de uso.

A priori, una conclusión que podríamos sacar comparando ambos modelos es que para las cuestiones de almacenamiento, ambos cuentan con soluciones potentes y escalables, y en materia de seguridad y disponibilidad, los dos vendors parecen mantener unos estándares de calidad muy elevados. Las diferencias en temas de storage son mínimas entre uno y otro, si bien hay pequeñas características como Amazon Macie que, en comparación con el resto de aspectos, quedan un poco más en segundo plano.

Las diferencias afloran cuando se habla de implementación y tareas de análisis: Azure ofrece un producto más compacto y accesible a nivel de los conocimientos necesarios para desplegarlo, pero como contrapartida, es más hermético. Amazon, un pack de posibilidades que, para poder explotarlas, se necesita un expertise mayor y probablemente, un tiempo más largo de integración de los distintos servicios para dar, al cambio, un producto más ajustado al cliente.

Azure presenta una solución de análisis “ya hecha”, y Amazon presenta múltiples “piezas” con las que entrar a analizar los datos, no solo ElasticSearch, también las otras soluciones de Big Data y análisis de datos: Athena, EMR (que es un cluster de Hadoop) son otras opciones, pero en cuanto a lenguajes, todos parecen ofrecer facilidades con lenguajes ya conocidos, sobre todo con SQL, pero también con Python, YAML o JSON. En ese aspecto, no muestran muchas discrepancias.

Las ventajas que se muestran en ambos vendors son, dados los parecidos entre ambos modelos, ventajas inherentes a la adopción de infraestructura cloud: adaptabilidad de almacenamiento, de recursos, de capacidad de proceso y una forma de “ajustar los precios” con la filosofía de “pagar por lo que se usa”, si bien Amazon cuenta con más rodaje en lo que es el campo de los servicios Cloud para dar más posibilidades a la hora de implementar Data Lakes para el análisis de macrodatos, Microsoft se antoja como un vendor que ofrece menos alternativas, pero tal vez con más facilidad para el despliegue.

 

Autor: Gabriel Piuzzi

Curso: Microsoft MCSA Windows Server + Microsoft MCSE Cloud Platform & Infrastructure

Centro: Tajamar

Año académico: 2017-2018

Leave a Comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.