Big data, NoSQL y Google versus AWS

La serie de superhéroes Serverless con Lynn Langit

¡Bienvenido a "Superhéroes sin servidor"!
En este espacio, converso con los fabricantes de herramientas, innovadores y desarrolladores que navegan por el valiente mundo de las aplicaciones en la nube "sin servidor".

Para la edición de hoy, conversé con Lynn Langit, una arquitecta de Big Data y Cloud. Lynn es un experto en desarrollo de Google Cloud, un héroe comunitario de AWS y un ex empleado de Microsoft. La siguiente entrevista ha sido editada y condensada para mayor claridad.

Forrest Brazeal : La mayoría de las personas que conozco se enfocan en una sola nube, ¡pero pareces ser bueno en todo! Habla en todo el mundo y trabaja con clientes en AWS, Azure y Google Cloud Platform. ¿Qué significa la palabra "sin servidor" para usted y sus clientes?

Lynn Langit : La definición común es "el cliente final no es responsable del servidor". De hecho, he elevado esa definición aún más. He estado trabajando estrechamente con un amigo llamado Anton Delsink que trabaja con Azure Stack.

Condujimos juntos por Noruega en un viaje reciente y se nos ocurrió esta definición de "sin servidor": "un servicio que abstrae la gestión de los contenedores". Por lo tanto, nuestra nueva palabra de moda es "sin contenedor".

¡Me acabas de volar la cabeza! Entonces, ¿cuál es el futuro de los contenedores? ¿No cree que los clientes querrán traer sus propios contenedores a las plataformas FaaS?

Tengo una respuesta mordaz: no me importa. Para mí, los contenedores son las nuevas máquinas virtuales. Todo este frenesí de los contenedores, y más específicamente de los sistemas de gestión de contenedores: mira, alguien tiene que gestionar las cosas. Quiero pagarles a los proveedores de la nube para que lo hagan, así que no es necesario.

Ahora, en realidad, todavía no creo muchas soluciones puras sin servidor para los clientes. Algunas personas aún prefieren contenedores a servidores, y sus razones son generalmente la portabilidad y el control. Si no tiene una necesidad apremiante de esas opciones, y puede obtener valor de los servicios sin servidor, siga ese camino.

Eres un experto en datos en la nube, y siempre he pensado que el concepto de "sin servidor" se vuelve bastante resbaladizo en la capa de datos. Para mí, parte del punto de las arquitecturas "sin servidor" es que pagas solo por la capacidad que usas, pero muchos servicios de datos te cobran por hora (RDS) o por la capacidad de aprovisionamiento (DynamoDB) para que pagues si su servicio no recibe tráfico ¿Crees que un servicio de pago por consulta como AWS Athena es el futuro?

Creo que Google está liderando aquí. Durante años, han proporcionado soluciones de datos sin servidor o casi sin servidor de forma inmediata. Quiero decir, BigQuery ha estado fuera desde 2011. Es una solución de tipo NoOps SQL-on-files. Incluso Cloud Spanner: configura una instancia, pero la única perilla que tiene que activar es para utilizarla.

Una vez que alcanzas un cierto número, recomiendan obtener más nodos, pero eso es todo. Es muy interesante que, como Google está tratando de agregar funcionalidades de almacenamiento de datos empresariales a BigQuery, cosas como la seguridad granular y la transmisión, AWS ha integrado Athena con tanta rapidez y ha agregado integraciones con servicios como Glue.

Así que mi predicción es que, a medida que Google amplía su cartera de datos, como lo hicieron al agregar BigTable, va a presionar a los otros proveedores de la nube como AWS para que ofrezcan ajuste automático, menos perillas para RDS y RedShift y EMR. Y creo que lo verán más pronto que tarde, porque Google realmente los está presionando, y hemos visto que AWS responde muy rápidamente ante cualquier tipo de amenaza competitiva a su dominio de la nube.

Correcto, que es probablemente la razón por la que han invertido tanto en Aurora como un RDBMS patentado. Mencionaste a Athena, con la que he jugado un poco. Ese servicio se vuelve costoso muy rápido si no lo usa de manera óptima, diseñando sus datos de una manera específica en columnas. ¿Limita esto la utilidad del servicio o va a cambiar la forma en que las personas acceden a datos sin servidor?

Bueno, Athena es más adecuada para cierto tipo de datos. Consultas ad hoc en archivos de registro, realmente. Si quieres un gran volumen, debes tener algún tipo de compresión.

Pero al igual que Docker y Lambda son difíciles de entender para los desarrolladores de aplicaciones, y es por eso que tenemos eventos como ServerlessConf . Creo que es aún más difícil para los profesionales de los datos concentrarse en implementaciones "sin servidor" o "server-lite". Porque existe toda esta historia de administradores de bases de datos que administran clusters y demás. Entonces, el nuevo paradigma da miedo, y creo que los DBA tienden a hundirse en sus talones y resistirse.

De hecho, creo que eso ha perjudicado la adopción de BigQuery, razón por la cual ha existido desde 2011 y solo en 2016 Amazon sintió la necesidad de salir con Athena. Tú y yo sabemos que podrían haberlo creado antes, pero el mercado no estaba allí.

Creo que mucha gente (incluidos algunos de los DBA excavadores de talones) tienden a asociar "sin servidor" con "NoSQL". De hecho, conozco personas que creen que la base de datos relacional se está quedando en el camino, dar o tomar algunas cosas, como aplicaciones financieras que necesitan coherencia transaccional. ¿Crees que es una suposición justa? ¿Por qué o por qué no?

La tendencia NoSQL de los últimos años ha sido realmente interesante para mí. Después de todo, cuando trabajaba en Microsoft escribí libros sobre SQL Server. Hice un montón de data warehousing tradicional con OLTP y OLAP y todo eso. Cuando dejé Microsoft y me independicé en 2011, hubo mucho bombo en torno a Hadoop y NoSQL. Y lo que a menudo encuentro es que no se ha cumplido.

La mayoría de mis trabajos de consultoría son sobre datos en la nube. La gente dice "¿pueden ayudarnos a obtener valor comercial de NoSQL Database X?" Y para muchas pequeñas y medianas empresas, no puedo. No tienen el personal, la voluntad, la necesidad, para cambiar.

Hoy, si un cliente dice que quiere implementar su propia pila NoSQL, realmente los desafío. Quiero decir, a veces tienen talento de Cassandra realmente fuerte o algo así, pero esa es una excepción bastante rara. Veo NoSQL como muy sobrevalorado y con muy poco valor comercial. Me levanta una gran bandera roja, y he recuperado muchas implementaciones NoSQL fallidas, las convertí a RDS.

Entonces, para aclarar, cuando hablamos de que NoSQL genera banderas rojas, ¿se refiere a personas que administran sus propias implementaciones en lugar de depender de los servicios administrados de un proveedor de la nube?

Parcialmente. Para ser sincero, creo que muchos de los productos independientes de NoSQL desaparecerán. O Amazon o Microsoft o Google los comprarán o no podrán competir. Va a ser un espacio realmente pequeño. Creo que Redis sobrevivirá, porque tienen algunos aspectos realmente únicos en su implementación. Cassandra, no estoy seguro.

Quiero decir, pasé por un período en el que estaba obsesionado con NoSQL. Hice presentaciones – "NoSQL para el desarrollador de SQL" – Realmente pensé que era el futuro. Pero he llegado a la conclusión de que, al igual que los contenedores, las implementaciones de NoSQL son una distracción. Omitir contenedores: vaya a las funciones. Skip Cassandra: diríjase a DynamoDB o a un servicio relacional administrado.

Por lo tanto, parece que no se da por vencido en las bases de datos relacionales para sistemas sin servidor.

De ningún modo. Si un cliente tiene un caso de uso para NoSQL, recomendaré el NoSQL del proveedor de la nube. Pero recuerdo que una vez fui arquitecto en una solución AWS IoT, donde incluso la arquitectura de referencia usaba DynamoDB.

Pero estaban teniendo todo tipo de problemas, y un día decidí cambiarme a Aurora. Asombró a todo el mundo – dijeron, "¿Qué estás haciendo?" Le dije: "¿Qué estamos haciendo? Estamos enviando un producto ". Y lo hicimos.

Digamos que quería crear una aplicación que necesita administrar datos transaccionales y de estado de usuario en tiempo real, así como también proporcionar data warehousing y procesamiento de big data en el back-end. Y no quería tener que administrar ningún servidor de base de datos. Si pudieras mover mágicamente una varita y juntar los mejores servicios de varios proveedores de la nube para hacer esto, ¿cómo diseñarías la capa de datos?

Comencemos con el almacenamiento de objetos. Aunque AWS ha realizado grandes mejoras en el proceso de administración del ciclo de vida S3, una de las cosas que me encanta de Google es que tienen una API unificada para Google Cloud Storage. El concepto de AWS Glacier está incluido, por lo que tiene almacenamiento nearline, coldline, multi- y single-regional todo envuelto, y se presenta de manera muy simple. Lo que no me gusta es que le faltan algunas características de S3: registro, control de versiones, métricas. Por lo tanto, es una especie de lanzamiento entre un lago de datos en Google Cloud Storage o S3.

Siguiente cosa: ingesta de transmisión. Esta es un área en la que estoy trabajando mucho en este momento. Los sistemas que existen parecen estar funcionando en Kafka. Personalmente me gusta Kinesis, rápido, fácil y simple, y Google Cloud Pub / Sub también es bueno. Pero hay una diferenciación de características entre Kafka y las tuberías de la nube. Me gustaría que los vendedores de la nube tuvieran más características de Kafka. Estoy buscando eso en re: ¡Inventar este año!

Para ETL, algunas cosas interesantes están sucediendo. Todavía no he trabajado demasiado en AWS Glue. De hecho, me encanta un producto ETL hecho por Matillion . Puede obtener su AMI en AWS Marketplace. Es algo así como SQL Server SSIS en un navegador, por lo que tiene una representación visual de las transformaciones, y su DBA de la vieja escuela dice "¡Oh, eso se parece a mi herramienta ETL!"

Lo largo y lo corto es: si eres ETL-ing o ELT-ing, prefiero una herramienta en lugar de una API. Amazon realmente brilla allí. Realmente no me gusta su Data Pipeline nativo, pero brillan debido a vendedores como Matillion. Por otro lado, Google requiere que codifique todo en comparación con sus API, generalmente en Java.

Y eso ha sido un gran negativo: Google es una nube tan enfocada en los desarrolladores. Primero codifica todo, y luego las herramientas vienen después, si es que alguna vez lo hacen. A pesar de que su nube es realmente poderosa y realmente escalable, ese no es el paradigma. Mientras que AWS es una nube de DevOps, y creo que ha sido uno de los factores que han impulsado su éxito, especialmente en lo que respecta a los datos, porque los administradores de red y los DBA tienen más referencias.

En la capa relacional, realmente me encanta Aurora y el resto de las implementaciones de RDS. Estoy interesado en Spanner, pero nuevamente es un caso en el que Google toma sus propios productos y los libera, sin entender que el resto del mundo no funciona en Google.

Como el hecho de que Spanner no admite claves externas, y luego no hay una herramienta de importación y conversión de esquemas. ¿Quién tomará una aplicación empresarial existente y cambiará el esquema relacional? Simplemente no está sucediendo. Y el hecho de que Google ni siquiera se ocupe de eso me entristece, porque el hecho es que Spanner es una tecnología asombrosamente bella.

Esta falta de creación de un producto completo, a pesar de que Google ofrece más en el espacio de datos, me hace enfocarme en Amazon. Aunque mantengo un ojo en lo que Google está haciendo, porque lo que realmente está haciendo Google es forzar a Amazon a hacer mejores productos. Bueno para los clientes, malo para Google.

Y, finalmente, en el ámbito del procesamiento de big data, es un lanzamiento real entre EMR y Cloud Dataproc. Las VM de Google están precalentadas y son tan rápidas que aparecen en cuestión de segundos. Hago muchos prototipos, así que eso es genial para mí. Si está realizando cargas de trabajo en ráfagas, puede usar Preemptible, la versión de Google de Spot. Ojalá AWS actualizara EMR, lo hiciera un poco más moderno, estoy buscando eso en re: Invent también. Para ser honesto, en este momento tiendo a usar DataBricks .

¿Cuáles son algunas de las otras formas en que crees que un servidor no puede transformar datos grandes, y viceversa?

ETL sigue siendo el problema grande y malo en el mundo de los datos. Me gustaría ver más herramientas ETL que incluyen aprendizaje automático y estadísticas. "Parece que esta información necesita X." "Este esquema es A y este esquema es B. Parece que necesita transformaciones de ABC." La aplicación de cálculos regulares, pero el aprendizaje automático en particular, a los problemas de ETL será mágico. Será interesante ver qué sucede con la salida de Glue.

La otra cosa es la democratización del aprendizaje automático. Siempre confieso cuando las cosas son difíciles, eso es parte de mi marca. He estado trabajando en la comprensión de cómo construir modelos de TensorFlow y MXNet que proporcionan valor de negocio real durante más de seis meses. Hasta ahora no puedo hacerlo. Y la mayoría de las personas con las que hablo, si son honestas, tampoco pueden hacerlo. La mayoría de las personas puede completar los ejemplos de Hello World-level, pero falta una capa de traducción entre las muestras y la creación de modelos comerciales.

Estoy realmente fascinado con el espacio, porque en el aprendizaje automático hay excelentes servicios sin servidor, Rekognition API y Polly y Lex, y seguirá habiendo más de esos. ¿Pero cómo llegamos a donde la API y las herramientas son lo suficientemente maduras como para que una persona de negocios que entiende las estadísticas pueda hacer un modelo? Creo que hay mucho trabajo de API, herramientas y visualización que hacer aquí.

¿Cómo crees que en el espacio de la nube podemos ayudar a que los servidores sean más accesibles para los nuevos alumnos?

Una forma de aprender sin servidor es crear un caso de uso de IoT. Realmente me gusta construir con Alexa: lo he hecho en todo el espectro con niños, maestros de escuela e incluso desarrolladores gruñones. Me gusta el Simple Beer Service también. Ponga a la gente en un entorno que sea divertido, que tenga un bajo costo de entrada, y ellos van a decir: "¡Oh, realmente puedo hacer esto!". Traigo Echo Dots porque desarman a las personas.

Este es el único aspecto sin servidor que no podemos perder de vista: esta tecnología trae consigo una gran cantidad de cambios. Da miedo; es disruptivo El hecho de no reconocer eso solo está frenando las oportunidades.

Vuelve pronto para otra edición de Serverless Superheroes.