¿Quién recibe crédito por el éxito del código abierto?

relay_teamwork_coordination_cooperation_continuity

Como muchos proyectos ganadores, Cortex de Weaveworks es el resultado de una cadena larga y sinuosa de inspiración e innovación de código abierto.

por Matt Asay

Contenido
relay_teamwork_coordination_cooperation_continuity

Hace más de 2000 años, el historiador romano Tácito observó que “todos reclaman la victoria”, o, como dicen algunas traducciones, “el éxito tiene muchos padres”. El código abierto es similar. Por ejemplo, AWS trabajó recientemente con Grafana Labs para crear y lanzar un servicio Prometheus administrado: dos empresas que se unen para ofrecer el software de monitoreo de código abierto como un servicio en la nube. Suena simple, ¿verdad?

Incorrecto. 

Para llegar a ese servicio de Prometheus, varias empresas y comunidades de código abierto desempeñaron un papel importante: SoundCloud, que dio origen a Prometheus; Hyperic, la inspiración detrás de Cortex (a través de Scope ); SpringSource, que reconoció el valor comercial de la supervisión. Ah, y en el centro de todo, Weaveworks, la compañía quizás más conocida por GitOps pero que también creó Cortex.

Enterrado en la historia de Cortex hay una lección sobre la distribución del crédito de código abierto. El tl; dr? Es complicado. También es difuso. Y así es exactamente como se supone que funciona el código abierto.

Dinero y código abierto

En el caso de Cortex, realmente comenzó con dinero. O, mejor dicho, la necesidad de ganar dinero.

Como lo expresó el director ejecutivo de Weaveworks, Alexis Richardson, en una entrevista: “Recuerdo haber tenido una conversación con Rod [Johnson, director ejecutivo de SpringSource] y me dijo que su mayor arrepentimiento empresarial en términos del camino que había tomado SpringSource era no adquirir Hyperic inmediatamente y dejar que creciera en valor…. Ese comentario se quemó en mi cabeza “.

Como lo cuenta Richardson, le quedó claro que la clave para monetizar el código abierto era a través del monitoreo y la administración, algo que eventualmente lo llevó a dejar Pivotal, donde manejaba los productos Spring y vFabric (sin mencionar otros, como RabbitMQ) y iniciar Weaveworks en 2014.

Richardson pensó que el mundo de los contenedores Docker sería similar al mercado de aplicaciones Spring: la supervisión y la gestión serían importantes. Esto dio lugar a Weave Scope , una forma de visualizar hosts, contenedores y servicios de Docker en tiempo real. Scope es un proyecto de código abierto genial. Pero me estoy adelantando, porque Scope no comenzó en Weaveworks. Realmente no.

Mientras Weaveworks había estado pensando en formas de mapear y visualizar aplicaciones en contenedores, entrevistaron al ex ingeniero de SoundCloud Peter Bourgon y descubrieron que había estado trabajando en paralelo en algunas ideas que coincidían estrechamente con las suyas. Mientras estaba en SoundCloud, Bourgon se asoció con su amigo David Kaltschmidt (que entonces dirigía su propia empresa, Type Type Type) en una solución de monitorización y visualización que llamó la atención de Richardson. Ambos se unieron a Weaveworks y su trabajo de monitoreo inicial se convirtió en Scope.

El alcance fue excelente, pero podría mejorar con métricas. Bourgon, recién llegado de su tiempo en SoundCloud, impregnado de Prometheus, pidió a la compañía que adoptara Prometheus como una forma de entregar esas métricas. Sin embargo, el problema de agregar Prometheus a Scope era que alguien tenía que pagar para activar una instancia de Amazon EC2 cada vez que querían ver las métricas de su aplicación. Podría resultar caro. El viaje de Cortex de Weaveworks comenzó con la necesidad de ganar dinero (¡Prometheus!), Y ahora la compañía necesitaba descubrir cómo ahorrar dinero para que su servicio fuera aceptable (¡no Prometheus!).

La empresa necesitaba probar algo diferente. Necesitaba un servicio que se pareciera a Prometheus pero que permitiera a Weaveworks ofrecer métricas similares a las de Prometheus sin incurrir en el costo de hacer girar las instancias de Prometheus cada vez que alguien quería ver esas métricas.

Una forma diferente de hacer girar Prometheus

Ese “algo diferente” fue Cortex, que utilizó un diseño radicalmente diferente. Cortex, dice Richardson, trae “un montón de código de Prometheus, pero es más como Apache Cassandra en su enfoque”. Es decir, no ha compartido nada, atributos fragmentados, con todos los datos yendo a diferentes puntos del sistema, sin cooperar para almacenar los datos. El servicio Weaveworks se parecía a Prometheus y podía conectarse a él, utilizando el mismo estilo de métricas, pero estaba diseñado de manera diferente.

Promoviendo este “¿Dónde comienza y termina el crédito de código abierto?” En el tema, el equipo de diseño de Weaveworks incluyó al líder de diseño Tom Wilkie, quien ahora está en Grafana Labs, donde continúa su desarrollo de Cortex (matices del “mismo equipo, diferentes compañías” de Kelsey Hightower ). Pero llegó a Weaveworks con una importante experiencia en Cassandra, lo que ayudó a dar forma al diseño de Cortex. Ese equipo también incluía a Julius Volz, cofundador de Prometheus en SoundCloud, y actual asesor de Weaveworks.

Los fundadores de la empresa pensaron que Prometheus sería un éxito cuando Kubernetes despegara y Cortex permitiría una ruta de monetización de SaaS. Sin embargo, la realidad es que desarrollar tanto la tecnología como el negocio llevó tiempo. Hablando con Bryan Boreham, ingeniero distinguido de Weaveworks, hizo hincapié en el esfuerzo que se hizo para guiar a Cortex hacia su éxito actual:

Cortex ha llevado años y ha pasado por extensas reescrituras y reestructuraciones. Es como el barco de Teseo. Las vigas se han reemplazado varias veces. Ha estado en producción continua durante años en Weaveworks. El equipo básico era sólido, pero en términos del lado NoSQL, estamos en la versión 11 del esquema. Repensamos y repensamos y repensamos y, de hecho, en su mayoría hemos reemplazado las cosas de NoSQL con algo más inspirado en la época de Prometheus. -Base de datos de la serie.

A pesar de lo prometedor que fue Cortex en sus inicios, también fue notablemente más lento que Prometheus, a pesar de ejecutarse en un “sistema vasto y distribuido”, señala Boreham. Weaveworks hizo un trabajo significativo para acelerarlo (agregando almacenamiento en caché, rastreo de Jaeger para detectar puntos de desaceleración, etc.), y Cortex ha corrido más rápido que Prometheus durante al menos los últimos dos años.

Richardson identifica cuatro elementos clave que impulsaron los esfuerzos de la compañía para convertir la promesa de Cortex en realidad. La primera es que se ha trabajado mucho para ejecutar un servicio real para el público. “La ejecución de un servicio Cortex para proporcionar Prometheus a pedido definitivamente nos enseñó mucho sobre [cómo operarlo en el mundo real]”, dice Richardson. ¿El segundo? “Resuelve un problema real. Hacer esto de otras formas es muy difícil “. En tercer lugar, Weaveworks y la floreciente comunidad de Cortex, que ahora incluía ingenieros que participaban activamente de DigitalOcean y de otros lugares, tomaron una decisión consciente de desacoplar Cortex de su back-end DynamoDB / Amazon S3 original. “Esto lo hizo más útil porque se puede ejecutar en más lugares y no lo vincula completamente a AWS”. ¿Y cuarto? “La magia del código abierto”. Weaveworks incorporó a Cortex al CNCF,

Hoy esa magia significa que Weaveworks, que sigue siendo uno de los contribuyentes más importantes de Cortex , ya no necesita cargar con todo el peso. Grafana Labs es ahora el mayor contribuyente de Cortex (Weaveworks es el segundo), pero muchos otros también se han intensificado , incluidos Red Hat, Robinhood, Splunk y DigitalOcean. Esta es una señal de la notable “magia” del código abierto, así como de la exitosa catalización de Weaveworks de un verdadero modelo de gobierno comunitario de código abierto, sin un solo proveedor al mando.

Así es como se supone que funciona el código abierto. Proyectos como Loki (un proyecto de registro de código abierto inspirado en Prometheus) o Envoy se originan en una empresa, se desarrollan más en otra y se ponen en funcionamiento y mejoran en muchas otras. Loki fue conceptualizado por Tom Wilkie en Weaveworks pero desarrollado en Grafana Labs. Envoy fue iniciado por Matt Klein en Lyft, pero Google se ha convertido en el mayor contribuyente durante el año pasado . Vemos el mismo patrón en muchos otros proyectos de código abierto.

No es un error. Es una característica. Es la indicación más clara de que estás haciendo lo correcto con el código abierto.

Leer más sobre código abierto:

Fuente: https://www.infoworld.com/article/3602610/who-gets-credit-for-open-source-success.html

Tagged:

Deja una respuesta