Dependiendo de tu política, economía de goteo nunca funcionó tan bien en los Estados Unidos bajo el presidente Ronald Reagan. Sin embargo, en el software de código abierto parece funcionar bien.
En realidad, no me refiero a políticas económicas, por supuesto, sino más bien a equipos de ingeniería de software de élite que lanzan código que termina impulsando a la corriente principal no tan elitista. Tomemos como ejemplo Lyft, que liberó al enviado popular proyecto. O Google, que le dio al mundo Kubernetes (aunque, como he argumentado, el objetivo no eran sutilezas caritativas, sino más bien una estrategia corporativa para flanquear a la AWS dominante). Airbnb descubrió una manera de ir más allá orientado por lotes cron
Planificación, regalándonos Apache Airflow y canalizaciones de datos como código.
Hoy en día, una amplia gama de empresas tradicionales dependen de Airflow, desde Walmart hasta Adobe y Marriott. Aunque es comunidad incluye desarrolladores de Snowflake, Cloudera y más, la mayor parte del trabajo pesado lo realizan ingenieros de Astrónomo, que emplea a 16 de los 25 principales confirmadores. Astronomer hace un buen uso de esta administración y experiencia, operando un servicio Airflow totalmente administrado llamado Astro, pero no es el único. Como era de esperar, las nubes se han apresurado a crear sus propios servicios, sin un código de respaldo acorde, lo que plantea la preocupación por la sostenibilidad.
Ese código no se escribirá solo si no puede pagarse por sí solo.
¿Qué es un canal de datos?
Hoy en día todo el mundo habla de modelos de lenguajes grandes (LLM), generación de recuperación aumentada (RAG) y otras siglas de IA generativa (genAI), al igual que hace 10 años no nos cansábamos de Apache Hadoop, MySQL, etc. Los datos cambian, pero los datos permanecen, con la preocupación siempre presente de cuál es la mejor manera de moverlos entre sistemas.
Aquí es donde entra en juego el flujo de aire.
En cierto modo, Airflow es como una versión seriamente mejorada. cron
programador de trabajos. Las empresas comienzan con sistemas aislados, que eventualmente deben unirse. O, mejor dicho, los datos deben fluir entre ellos. Como industria, hemos inventado todo tipo de formas de gestionar estos canales de datos, pero a medida que aumentan los datos, proliferan los sistemas para gestionarlos, sin mencionar la sofisticación cada vez mayor de las interacciones entre estos componentes. Es una pesadilla, como escribió el equipo de Airbnb cuando abrió Airflow: “Si consideras un equipo de datos de tamaño mediano y de ritmo rápido durante algunos años en una infraestructura de datos en evolución y tienes una red enormemente compleja de trabajos de computación en tus manos , esta complejidad puede convertirse en una carga importante para que los equipos de datos la administren, o incluso la comprendan”.
Escrito en Python, Airflow habla naturalmente el lenguaje de los datos. Piense en ello como un tejido conectivo que brinda a los desarrolladores una forma consistente de planificar, organizar y comprender cómo fluyen los datos entre cada sistema. Una parte importante y creciente de Fortune 500 depende de Airflow para la orquestación de la canalización de datos, y cuanto más lo usan, más valioso se vuelve. El flujo de aire es cada vez más crítico para las cadenas de suministro de datos empresariales.
Así que volvamos a la cuestión del dinero.
El código no se escribirá solo
Existe una comunidad sólida en torno a Airflow, pero quizás el 55% o más del código sea aportado por personas que trabajan para Astronomer. Esto coloca a la empresa en una excelente posición para respaldar a Airflow en la producción para sus clientes (a través de su servicio Astro administrado), pero también pone en riesgo el proyecto. No, no porque Astrónomo ejerza una influencia indebida en el proyecto. Los proyectos de Apache Software Foundation, por definición, nunca son proyectos de una sola empresa. Más bien, el riesgo proviene de que Astronomer decida potencialmente que no puede justificar financieramente su nivel de inversión.
Aquí es donde las acusaciones de “tirarse de la alfombra del código abierto” pierden su potencia. Como He discutido recientemente, tenemos un problema de aprovechamiento gratuito de un billón de dólares en código abierto. Siempre hemos tenido algo parecido a este problema. Ninguna empresa contribuye por caridad; es siempre sobre el interés propio. Un problema es que las empresas pueden tardar mucho en comprender que su propio interés debería obligarlas a contribuir (como ocurrió cuando Elastic cambió su licencia y AWS descubrió que tenía que proteger miles de millones de dólares en ingresos bifurcando Elasticsearch). Este reconocimiento tardío se exacerba cuando alguien más paga la factura del desarrollo.
Es demasiado fácil dejar que otra persona haga el trabajo mientras usted se queda con las ganancias.
Pensemos en Kubernetes. Se considera, con razón, un ejemplo de comunidad, pero mire qué tan concentradas están las contribuciones de la comunidad. Desde sus inicios, Google ha contribuido con el 28% del código. El siguiente mayor contribuyente es Red Hat, con un 11%, seguido de VMware con un 8% y luego Microsoft con un 5%. Todos los demás tienen un error de redondeo relativo, incluido AWS (1%), que eclipsa a todos los demás en cuanto a los ingresos obtenidos de Kubernetes. Esto es completamente justo, ya que la licencia lo permite. Pero, ¿qué sucede si Google decide que no es de interés propio para la empresa seguir desarrollando tanto para beneficio de otros?
Una posibilidad (y los datos de los contribuyentes pueden respaldar esta conclusión) es que las empresas recalibrarán sus inversiones. Por ejemplo, en los últimos dos años, la participación de Google en las contribuciones cayó al 20% y la de Red Hat al 8%. Microsoft, por su parte, aumentó su participación relativa en las contribuciones al 8%, y AWS, aunque todavía relativamente pequeña, saltó al 2%. ¿Quizás las buenas comunidades se autocorrigen?
Lo que nos lleva de nuevo a la cuestión de los datos.
Es el mundo de Python
Debido a que Airflow está construido en Python, y Python parece ser el segundo lenguaje de cada desarrollador (si no el primero), es fácil para los desarrolladores comenzar. Quizás lo más importante es que también les resulta fácil dejar de pensar en los canales de datos. Los ingenieros de datos realmente no quieren mantener los canales de datos. Quieren que esas tuberías pasen a un segundo plano, por así decirlo.
Cómo lograr que esto suceda no es inmediatamente obvio, particularmente dado el caos absoluto del panorama actual de datos/IA, como capturado por FirstMark Capital. Airflow, particularmente con un servicio administrado como Astro de Astronomer, hace que sea sencillo preservar la opcionalidad (muchas opciones en ese gráfico de FirstMark) al tiempo que agiliza el mantenimiento de las tuberías entre sistemas.
Este es un gran problema que seguirá creciendo a medida que proliferen las fuentes de datos. Ese «gran problema» debería aparecer más en la tabla de contribuyentes. Hoy en día, los desarrolladores de Astronomer son la fuerza impulsora detrás de los lanzamientos de Airflow. Sería fantástico ver a otras empresas aumentar sus contribuciones también, de forma proporcional a los ingresos que sin duda obtendrán de Airflow.
Copyright © 2024 IDG Communications, Inc.