Wer bekommt die Anerkennung für Open-Source-Erfolg?

Wie so viele erfolgreiche Projekte ist auch Weaveworks' Cortex das Ergebnis einer langen und gewundenen Kette von Open-Source-Inspiration und -Innovation. [...]

Vor über 2000 Jahren beobachtete der römische Historiker Tacitus, dass „der Sieg von allen beansprucht wird“ – oder, wie es einige Übersetzungen ausdrücken: „Der Erfolg hat viele Väter.“ Bei Open Source ist es ähnlich.

Zum Beispiel hat AWS kürzlich mit Grafana Labs zusammengearbeitet, um einen verwalteten Prometheus-Service zu entwickeln und einzuführen – zwei Unternehmen, die sich zusammengetan haben, um die Open-Source-Überwachungssoftware als Cloud-Service bereitzustellen. Klingt einfach, oder?

Falsch.

Um zu diesem Prometheus-Service zu kommen, spielten eine Reihe von verschiedenen Unternehmen und Open-Source-Communities eine Rolle: SoundCloud, das Prometheus ins Leben gerufen hat; Hyperic, die Inspiration hinter Cortex (über Scope); SpringSource, das den geschäftlichen Wert von Monitoring erkannt hat. Oh, und im Zentrum von allem, Weaveworks, das Unternehmen, das vielleicht am besten für GitOps bekannt ist, aber auch Cortex entwickelt hat.

Vergraben in der Geschichte von Cortex ist eine Lektion über die Verteilung von Verdiensten im Bereich Open Source. Die Kurzfassung? Es ist kompliziert. Es ist außerdem diffus. Und es ist genau so, wie Open Source funktionieren soll.

Geld und Open Source

Im Fall von Cortex fing es wirklich mit Geld an. Oder besser gesagt, mit dem Bedürfnis, Geld zu verdienen.

Der CEO von Weaveworks, Alexis Richardson, sagte in einem Interview: „Ich erinnere mich an ein Gespräch mit Rod [Johnson, dem CEO von SpringSource], in dem er sagte, dass er es am meisten bedauert, dass SpringSource nicht sofort Hyperic übernommen hat, um den Wert von Cortex wachsen zu lassen. …. Diese Bemerkung hat sich in meinem Kopf eingebrannt.“

Wie Richardson erzählt, wurde ihm klar, dass der Schlüssel zur Monetarisierung von Open Source im Monitoring und Management liegt, was ihn schließlich dazu veranlasste, Pivotal zu verlassen, wo er die Spring- und vFabric-Produkte leitete (ganz zu schweigen von anderen, wie RabbitMQ) und 2014 Weaveworks zu gründen.

Richardson ging davon aus, dass sich die Docker-Container-Welt ähnlich entwickeln würde wie der Markt für Spring-Anwendungen: Monitoring und Management würden eine Rolle spielen. So entstand Weave Scope, eine Möglichkeit, Docker-Hosts, Container und Services in Echtzeit zu visualisieren. Scope ist ein cooles Open-Source-Projekt. Aber ich greife mir selbst vor, denn Scope hat nicht bei Weaveworks angefangen. Nicht wirklich.

Während Weaveworks über Möglichkeiten nachdachte, containerisierte Anwendungen abzubilden und zu visualisieren, interviewten sie den ehemaligen SoundCloud-Ingenieur Peter Bourgon und entdeckten, dass er nebenbei an einigen Ideen gearbeitet hatte, die sich mit ihren eigenen deckten. Während seiner Zeit bei SoundCloud arbeitete Bourgon zusammen mit seinem Freund David Kaltschmidt (der damals seine eigene Firma Type Type Type betrieb) an einer Überwachungs- und Visualisierungslösung, die Richardson auffiel. Beide schlossen sich Weaveworks an, und aus ihrer frühen Monitoring-Arbeit wurde Scope.

Die Open Source Security Foundation ist endlich da

Scope war großartig, könnte aber bei den Metriken noch besser sein. Bourgon, frisch aus seiner Zeit bei SoundCloud, durchdrungen von Prometheus, setzte sich dafür ein, dass das Unternehmen Prometheus als eine Möglichkeit zur Bereitstellung dieser Metriken einbezog. Das Problem beim Einsatz von Prometheus in Scope war jedoch, dass jemand jedes Mal, wenn er Metriken für seine App sehen wollte, für das Hochfahren einer Amazon EC2-Instanz bezahlen musste. Das könnte teuer werden. Weaveworks‘ Cortex-Reise begann mit der Notwendigkeit, Geld zu verdienen (Prometheus!), und nun musste das Unternehmen herausfinden, wie es Geld sparen konnte, um seinen Service schmackhaft zu machen (nicht Prometheus!).

Das Unternehmen musste etwas anderes ausprobieren. Es brauchte einen Dienst, der wie Prometheus aussah, aber es Weaveworks ermöglichte, Prometheus-ähnliche Metriken anzubieten, ohne dass die Kosten für das Hochfahren von Prometheus-Instanzen anfielen, wenn jemand diese Metriken ansehen wollte.

Eine andere Art, Prometheus zu betreiben

Dieses „etwas andere“ war Cortex, das ein radikal anderes Design verwendete. Cortex, sagt Richardson, bringt „einen Haufen Code von Prometheus mit, aber es ist in seinem Ansatz eher wie Apache Cassandra.“ Das heißt, es hat nichts geteilt, sondern Attribute gesplittet, wobei alle Daten an verschiedene Stellen im System gehen, ohne dass sie zusammenarbeiten, um die Daten zu speichern. Der Weaveworks-Dienst sah aus wie Prometheus und konnte sich mit diesem verbinden, wobei er den gleichen Stil von Metriken verwendete, aber eine andere Architektur hatte.

Um das Thema „Wo beginnt und endet die Anerkennung von Open Source?“ fortzusetzen, gehörte zum Weaveworks-Designteam Design Lead Tom Wilkie, der jetzt bei Grafana Labs ist und dort seine Cortex-Entwicklung fortsetzt (Anklänge an Kelsey Hightowers „same team; different companies“). Aber er kam zu Weaveworks mit signifikanter Cassandra-Erfahrung, die das Cortex-Design mitgestaltet hat. Zu diesem Team gehörte auch Julius Volz, der Mitbegründer von Prometheus während seiner Zeit bei SoundCloud und derzeitiger Berater von Weaveworks.

Die Firmengründer dachten, dass Prometheus mit dem Aufkommen von Kubernetes ein Erfolg werden würde und Cortex einen SaaS-Monetarisierungspfad ermöglichen würde. Die Realität ist jedoch, dass die Entwicklung sowohl der Technologie als auch des Geschäfts Zeit brauchte. Im Gespräch mit Bryan Boreham, Distinguished Engineer bei Weaveworks, betonte er, wie viel Mühe es gekostet hat, Cortex zu seinem heutigen Erfolg zu führen:

Cortex hat Jahre gebraucht und ist durch ziemlich umfangreiche Umschreibungen und Neu-Architekturen gegangen. Es ist wie das Schiff des Theseus. Die Balken wurden ein paar Mal ausgetauscht. Es wird seit Jahren bei Weaveworks kontinuierlich produziert. Das Grundgerüst war solide, aber was die NoSQL-Seite angeht, sind wir auf Schema-Version 11. Wir haben umgedacht und umgedacht und umgedacht, und tatsächlich haben wir das NoSQL-Zeug größtenteils durch etwas ersetzt, das mehr nach dem Muster der Prometheus-eigenen Zeitreihen-Datenbank aufgebaut ist.

So vielversprechend Cortex zu Beginn auch war, es war auch merklich langsamer als Prometheus, obwohl es auf einem „riesigen, verteilten System“ lief, bemerkt Boreham. Weaveworks hat erhebliche Anstrengungen unternommen, um die Geschwindigkeit zu erhöhen (Hinzufügen von Caching, Jaeger-Tracing zum Aufspüren von Bremspunkten usw.), und Cortex läuft zumindest in den letzten zwei Jahren schneller als Prometheus.

Sicher, dass Sie dieses Projekt zur Open Source machen wollen?

Richardson identifiziert vier Schlüsselelemente, die die Bemühungen des Unternehmens, das Versprechen von Cortex in die Realität umzusetzen, vorangetrieben haben. Das erste ist, dass die Arbeit mit dem Betrieb eines echten Dienstes für die Öffentlichkeit verbunden wurde. „Der Betrieb eines Cortex-Dienstes zur Bereitstellung von Prometheus auf Abruf hat uns definitiv eine Menge darüber gelehrt, [wie man ihn in der realen Welt betreibt]“, sagt Richardson. Das zweite? „Es löst ein echtes Problem. Dies auf andere Weise zu tun, ist sehr schwierig.“ Drittens trafen Weaveworks und die aufkeimende Cortex-Community, an der inzwischen auch Ingenieure von DigitalOcean und anderen Anbietern aktiv beteiligt sind, eine bewusste Entscheidung, Cortex von seinem ursprünglichen DynamoDB/Amazon S3-Backend zu entkoppeln. „Dadurch wurde es nützlicher, weil es an mehr Orten ausgeführt werden kann und nicht komplett an AWS gebunden ist.“ Und viertens? „Die Magie von Open Source.“ Weaveworks brachte Cortex in die CNCF, was ihm Sichtbarkeit und eine viel höhere Traktion verschaffte.

Heute bedeutet diese Magie, dass Weaveworks, immer noch einer der wichtigsten Mitwirkenden an Cortex, nicht mehr die ganze Last tragen muss. Grafana Labs ist jetzt der größte Cortex-Beitragende (Weaveworks ist der zweitgrößte), aber eine ganze Reihe anderer sind ebenfalls aufgestiegen, darunter Red Hat, Robinhood, Splunk und DigitalOcean. Dies ist ein Zeichen für die bemerkenswerte „Magie“ von Open Source sowie für Weaveworks‘ erfolgreiche Katalysierung eines echten Open-Source-Community-Governance-Modells, bei dem kein einzelner Anbieter die Kontrolle hat.

So sollte Open Source auch funktionieren. Projekte wie Loki (ein Open-Source-Protokollierungsprojekt, das von Prometheus inspiriert wurde) oder Envoy haben ihren Ursprung in einer Firma, werden in einer anderen weiterentwickelt und in vielen anderen operationalisiert und verbessert. Loki wurde von Tom Wilkie bei Weaveworks konzipiert, aber bei Grafana Labs entwickelt. Envoy wurde von Matt Klein bei Lyft ins Leben gerufen, aber Google hat im letzten Jahr den größten Beitrag geleistet. Wir sehen, dass sich das gleiche Muster bei vielen anderen Open-Source-Projekten abspielt.

Es ist kein Bug. Es ist ein Feature. Es ist der deutlichste Hinweis darauf, dass Sie Open Source richtig machen.