Shay Banon saß in einem Londoner Appartement und suchte nach einer Stelle, während seine Frau die Kochschule im Le Cordon Bleu besuchte. In seiner Freizeit begann er mit der Programmierung einer Suchmaschine für ihr wachsendes Rezeptverzeichnis.
Seine erste Iteration hieß Compass. Die zweite war Elasticsearch (mit Apache Lucerne). Er wählte den Open Source-Ansatz für Elasticsearch, erstellte den IRC-Kanal #elasticsearch und wartete darauf, dass Benutzer auftauchen würden.
Die Reaktion war überwältigend. Benutzer fanden den Umgang natürlich und anwenderfreundlich. Die Akzeptanz ging durch die Decke, eine Community begann sich zu bilden und die Menschen nahmen den Kanal war — allen voran Steven Schuurman, Uri Boness und Simon Willnauer. Zusammen gründeten sie ein Suchunternehmen.
In etwa zur Gründungszeit von Elasticsearch Inc. kamen auch zwei andere Open Source-Projekte auf den Markt.
Jordan Sissel arbeitete an Logstash, einem anschließbaren Open Source-Datenverkehrstool zum Senden von Protokollen an den vom Nutzer gewünschten „Stash“, von denen einer Elasticsearch war. Darüber hinaus entwickelte er zur Visualisierung von Protokolldaten eine Benutzeroberfläche für Logstash – die aber bestenfalls hakelig war.
Glücklicherweise bewältigte jemand anderes die Visualisierungsherausforderung. Und zwar Rashid Khan, der an einer Open Source-Benutzeroberfläche namens Kibana arbeitete.
Shay, Jordan, und Rashid kannten einander und ihre Projekte bereits seit einiger Zeit, als sie beschlossen, ihre Kräfte zu vereinen und aus Elasticsearch, Logstash und Kibana Stack den ELK Stack zu formen.
Kurze Zeit später brachten wir zwei kommerzielle Plug-ins heraus: Marvel für das Monitoring und Shield für die Sicherheit.
Bei Elastic{ON} 2015 in San Francisco machten wir zwei große Ankündigungen. Erstens: Wir benannten das Unternehmen in Elastic um. Der neue Name repräsentierte unser wachsendes Produktökosystem und die Vielzahl der Anwenderfälle besser. Zweitens: Wir taten uns mit Found zusammen, einem Unternehmen, das das Hosted und Managed Elasticsearch auf AWS bereitstellte. Durch die Zusammenarbeit konnten wir das anwenderfreundlichste und umfassendste Angebot auf dem Markt bereitstellen.
In den Anfängen erstellte und veröffentlichte bei Elastic jeder Techniker für sich Software: egal, welche Version wann geliefert wurde – Hauptsache, sie war fantastisch. Kibana hatte Beta-Versionen, Logstash Meilensteine, Elasticsearch Nummern. Plugins wurden nach Belieben generiert. Es war chaotisch, funktionierte aber ... bis nichts mehr ging.
Als die Nutzer das Produkt intensiver verwendeten, mussten wir ein Produkt generieren, das mehr für die Nutzer tat. Wir fügten mehr Fähigkeiten hinzu, reichten mehr Pull-Anfragen ein, erstellten neue Plugins und Erweiterungen. Das Produkt wurde immer großartiger, alles wurde komplexer und für unseren Technologie-Stack wurden die Dinge problematisch.
Wenn bei Ihnen beispielsweise Elasticsearch Version 1.7 und Version 2.3 eines Plugins ausgeführt worden wären, hätte es keinen Automatismus gegeben, um festzustellen, ob die beiden Versionen kompatibel sind oder ob das Plugin insgeheim nicht funktionierte. Das war eindeutig ein Fehler.
Und auch unsere eigenen Ausführungen waren recht wirr: „Wenn Sie Shield nutzen möchten, brauchen Sie Elasticsearch 1.4.2….es sei denn, Sie nutzen Watcher. In diesem Fall benötigen Sie Elasticsearch 1.5.2. Und wenn Sie Elasticsearch 1.5.2 verwenden, dies ist nur mit Kibana 4.0.x, Logstash 1.4.x, Shield 1.2.x und Watcher 1.0.x kompatibel.“
Wir sahen uns mit unserer ganz persönlichen Versionierungshölle konfrontiert und die Supportmatrix sah auch nicht viel besser aus. Es war an der Zeit für Veränderungen.
Während die Produktteams mit den Versionsnummern kämpften, entfaltete sich eine andere Produktstory. 2015 begrüßten wir mit Packetbeat ein Team, das aus einem verheirateten Pärchen aus Berlin bestand, die eine leichte Methode entwickelt hatten, Netzwerkdaten an Elasticsearch und somit an die Elastic-Familie zu senden.
Das brachte uns ins Grübeln: Was wäre, wenn wir eine Familie aus „Data Shippers“ für den leichten Datentransfer hätten, um Netzwerkdaten, Protokolle, Metriken, Auditdaten uvm. von Edge-Maschinen an Logstash und Elasticsearch zu senden? Und damit war Beats geboren.
Der Oktober 2015 stellte einen Wendepunkt hinsichtlich unserer Probleme mit der Produktversionierung und der Kompatibilität dar.
Dies war das erste Mal, dass all unsere Produkte – Elasticsearch 2.0, Logstash 2.0, Watcher 2.0, Shield 2.0 und Kibana 4.2 – am selben Tag ausgeliefert wurden: Eine wahre „Release-Bonanza! (Beats 1.0 kam dann erst einen Monat später.)
Die Koordination dieser Aktion war nicht leicht. Die Engineering-Teams mussten die Art, in der sie zum Entwickeln und Testen der Produkte zusammenarbeiteten, komplett ändern. Aber es hat sich gelohnt. Der Wechsel machte es für die Nutzer leichter, den Einstieg in unsere Produkte zu finden. Und unsere Produkte wurden verlässlicher, sodass die Nutzer Erstaunliches damit leisten konnten.
Das Ausrichten der Release-Kadenz mit Elasticsearch 2.0 war der erste Schritt zu einem ausgereifteren Produktangebot. Die Einführung der Version 5.0 war der zweite Schritt. Dabei setzte das Unternehmen auf ein besser integriertes, intensiver getestetes und anwenderfreundllicheres Erlebnis bei den ersten Schritten mit dem Produkt.
Bei der Version 5.0 wurden zudem all unsere kommerziellen Plug-ins (die zu jener Zeit Shield, Marvel und Watcher hießen) in einer einzelnen Erweiterung – X-Pack – gebündelt. Sie umfasste Features, wie Security, Monitoring und Alerting für unsere Kernprodukte und wurde später, als wir das Unternehmen Prelert mit Sitz in London in die Elastic-Familie aufnahmen, um Machine Learning erweitert.
In Version 5.3 (im März 2017 veröffentlicht) führte Filebeat formell das Konzept von „Modulen“ oder einem Satz sicherer Konfigurationen zum Versenden, Parsen, Speichern, Analysieren und Visualisieren von allgemeinen Protokollformaten (z. B. Apache, Nginx, MySQL usw.) in den Elastic Stack ein. Module vereinfachten die ersten Schritte und den Übergang vom Datensatz zum Dashboard.
Metricbeat und Packetbeat hatten je ihre eigenen Modularten. Monate später führte Logstash eigene Module für ArcSight- und NetFlow-Daten ein.
Von Anfang an hatten wir eine Vision, wie wir die Bereitstellung von Elastic in den Organisationen der Nutzer vereinfachen können. Wir wählten die Technologie, mit der wir unseren eigenen Elastic Cloud Dienst verwalten, und veröffentlichten Elastic Cloud Enterprise (ECE), damit Groß- und Kleinunternehmen unser gehostetes Angebot herunterladen, selbst ausführen und sein volles Potenzial ausschöpfen konnten. ECE ermöglichte eine nahtlose Verwaltung, ganz gleich ob von einem oder von tausenden von Clustern, und optimiert dabei das Management und die Koordination von Elastic-Produkten und -Lösungen in jeder Umgebung.
Während die Module immer vielfältiger wurden, wurden die ersten Schritte zur Bewältigung eines bestimmten Anwenderfalls, wie Logging oder Metriken, mit dem Elastic Stack immer leichter. Und das Unternehmen gewann noch mehr an Fahrt, als wir uns mit Opbeat, einem APM (Application Performance Monitoring)-Unternehmen mit Sitz in Kopenhagen, und einige Monate später mit Swiftype, einem in San Francisco ansässigen Site- und Enterprise-Suchunternehmen, zusammentaten. Beide Unternehmen wurden Teil von Elastic.
Zu diesem Zeitpunkt hatte sich unser Unternehmen so weit entwickelt, dass wir optimierte Methoden zur Lösung allgemeiner Probleme anbieten konnten. Dies brachte uns dazu, unsere Lösungen offiziell einzuführen. Zwar bieten wird bei unseren Lösungen eine ganze Spanne von rudimentär bis hin zu ausgeklügelt an, hinter jeder der Lösungen, die sich innerhalb weniger Minuten bereitstellen lassen, steckt jedoch ein reales Produkt.
Von Open Source zu offener Kommunikation – offen zu sein, das ist der Mittelpunkt von allem, was wir tun. Deshalb haben wir die Entscheidung getroffen, den Code zu unseren kommerziellen X-Pack-Features zu öffnen, um so die Entwicklungszeit zu verkürzen und das Engagement innerhalb der Community zu steigern, sodass jeder etwas beitragen kann, etwas kommentieren kann und unseren Code inspizieren sollte.
Infolge dessen wurden die ersten Schritte mit dem Elastic Stack noch einfacher. Alle X-Pack-Features wurden nun standardmäßig mit Elasticsearch, Kibana, Beats und Logstash geliefert. Durch diese Änderung fiel kein Apache 2.0 Code weg, sondern wir verdoppelten unsere Bemühungen, Open Sources zu verwenden.
Mit dem Läuten der Eröffnungsglocke der New Yorker Börse am 5. Oktober um 9:30 Uhr Ortszeit begann für Elastic ein neues Kapitel: Wir sind jetzt offiziell ein börsennotiertes Unternehmen. Die 230 Elastic-Mitarbeiter auf dem Börsenparkett – eine Rekordzahl in der Geschichte der Wall Street – feierten zusammen mit Hunderten von Mitarbeitern in aller Welt das gemeinsame Erreichen dieses bemerkenswerten Meilensteins. Auch wenn dieser Tag nur das Ende einer Etappe unserer langen Reise war, wird er lange im Gedächtnis bleiben.
Unsere Story ist noch lange nicht zu Ende. Bleiben Sie bei uns und erfahren Sie, wie sich unser Abenteuer entwickelt.