Depuis les premiers pas d'Elasticsearch jusqu'à la naissance d'ELK, qui sera suivie d'une période absolument fabuleuse (quoique un tantinet chaotique)... Sans oublier le lancement de la Suite Elastic et l'avènement d'une nouvelle ère de l'open source... Il s'est passé tant de belles choses, que nous avons eu envie de les partager.
Alors en recherche d'emploi à Londres pendant que son épouse suit des cours à l'école de cuisine Le Cordon Bleu, Shay Banon a l'idée de développer un moteur de recherche pour l'aider à s'y retrouver dans son impressionnante liste de recettes.
Sa première itération est baptisée Compass. La deuxième ? Elasticsearch (et sous le capot : Apache Lucene). Il lance Elasticsearch en open source, crée le canal IRC #elasticsearch et attend de voir... si la mayonnaise prend.
La réaction est impressionnante. Les utilisateurs l'adoptent aussi facilement que naturellement. Le nombre de téléchargements monte en flèche et une communauté commence à prendre forme. Elasticsearch ne laisse pas indifférent. En tout cas pas Steven Schuurman, Uri Boness et Simon Willnauer. Ensemble, ils fondent une entreprise centrée sur la recherche.
Elasticsearch Inc. à peine fondée, deux autres projets open source commencent à prendre forme.
Jordan Sissel travaille sur Logstash, un outil d'ingestion open source compatible avec le système de stockage préféré de l'utilisateur, comme Elasticsearch. Il se lance aussi dans le développement d'une interface utilisateur permettant de visualiser les logs – ce qui n'était pas une mince affaire.
Mais il n'est pas le seul à s'intéresser à la visualisation, et quelqu'un d'autre vient lui prêter main forte : c'est Rashid Khan. Celui-ci travaille à une interface open source qui n'est autre que Kibana.
C'est ainsi que Shay Banon, Jordan Sissel et Rashid Khan qui échangeaient au sujet de leurs projets depuis un certain temps, décident de faire équipe. Ensemble, ils associent Elasticsearch, Logstash et Kibana. ELK était né.
Quelque temps après, deux plug-ins commerciaux font leur entrée : Marvel pour le monitoring et Shield pour la sécurité.
La conférence Elastic{ON} 2015 de San Francisco était l'occasion d'annoncer deux grandes nouvelles. D'abord, nous rebaptisions notre entreprise pour l'appeler Elastic. Ce nouveau nom reflétait mieux notre écosystème, qui ne cessait de s'enrichir de nouveaux produits et cas d'utilisation. Ensuite, l'union faisant la force, nous nous rapprochions de Found, une entreprise qui proposait un service d'hébergement et de gestion d'Elasticsearch sur AWS. Faire équipe avec Found nous permettait de proposer l'offre la plus simple et la plus complète du marché.
Quelque part aux alentours de l'âge de pierre d'Elastic, un vent de liberté et de douce anarchie soufflait sur le développement et la publication de logiciels : chacun y allait de sa version quand bon lui semblait. L'essentiel était de créer des logiciels fabuleux. Kibana était déployé en versions bêta, Logstash employait des jalons, et Elasticsearch avait des versions numérotées. La même ambiance un peu bohème régnait du côté des plug-ins, qui apparaissaient au petit bonheur. Bref, c'était un joyeux désordre, mais cela fonctionnait... Jusqu'au jour où cela n'a plus fonctionné.
Les utilisateurs en demandaient de plus en plus à notre produit. Nous devions développer un produit qui en fasse plus pour eux. Nous avons donc intégré de nouvelles fonctionnalités, envoyé un plus grand nombre de requêtes d'extraction, créé de nouveaux plug-ins et de nouvelles extensions. Nos logiciels étaient encore plus fabuleux. Mais les choses devenaient complexes et notre suite technologique pâtissait de ce désordre.
Par exemple, si on exécutait la version 1.7 d'Elasticsearch et la version 2.3 de tel plug-in, il n'existait aucun moyen de vérifier automatiquement si les deux versions étaient compatibles ou si cela entraînait un échec silencieux du plug-in. C'est ce qu'on appelle un bug.
Puis nous avons commencé à avoir des dialogues surréalistes. Par exemple : "Pour utiliser Shield, il faut exécuter Elasticsearch 1.4.2… À moins d'utiliser Watcher. Dans ce cas, il faut lancer Elasticsearch 1.5.2. Mais Elasticsearch 1.5.2 n'est compatible qu'avec Kibana 4.0.x, Logstash 1.4.x, Shield 1.2.x et Watcher 1.0.x".
La gestion des versions était devenue cauchemardesque. Et la matrice de prise en charge n'allait guère mieux. Il était temps de changer notre façon de faire.
Pendant que les numéros de version donnaient du fil à retordre aux équipes produit, un couple d'ingénieurs installé à Berlin allait donner naissance à un autre produit. En 2015, nous avons accueilli Packetbeat, un agent léger conçu pour le transfert des données réseau vers Elasticsearch et les solutions Elastic.
De là, nous est venue l'idée de proposer un ensemble d'agents légers dédiés au transfert des données réseaux, des logs, des indicateurs, des données d'audit, et plus encore, depuis des machines en périphérie vers Logstash et Elasticsearch. Les agents Beats étaient nés.
Octobre 2015 marque un tournant dans notre façon de gérer nos versions et les questions de compatibilité.
Avec la "version bonanza" (en référence à l'une des plus longues séries télévisées américaines), c'est la première fois que nous publions l'ensemble de nos produits (Elasticsearch 2.0, Logstash 2.0, Watcher 2.0, Shield 2.0 et Kibana 4.2) le même jour. (La plateforme Beats 1.0, quant à elle, devait encore attendre un petit mois.)
Coordonner nos efforts n'a pas été une mince affaire. Les équipes techniques ont dû revoir leur façon de collaborer pour développer et tester les produits. Mais le jeu en valait la chandelle. Pour les utilisateurs, la prise en main de nos produits devenait plus simple. Sans compter que les produits eux-mêmes gagnaient en fiabilité, permettant du même coup aux utilisateurs de placer la barre plus haut.
Aligner le rythme des publications sur Elasticsearch 2.0 était la première étape si nous voulions proposer une offre plus mature. La version 5.0 était la seconde étape. Elle inaugurait une expérience plus intégrée, mieux testée et plus simple à prendre en main que jamais.
La version 5.0 regroupait aussi tous nos plug-ins commerciaux (à l'époque appelés Shield, Marvel et Watcher) en une seule extension baptisée X-Pack. Celle-ci intégrait à nos produits phares des fonctionnalités telles que Security, Monitoring et Alerting. À ces fonctionnalités vint ensuite s'ajouter Machine Learning quand la société londonienne Prelert rejoignit la famille Elastic.
Avec la version 5.3 (publiée en mars 2017), Filebeat officialise le concept de "modules", autrement dit, un ensemble de configurations sûres, qui permettent le transfert, l'analyse, le stockage, l'examen et la visualisation dans la Suite Elastic de formats de log courants (par exemple, Apache, Nginx ou MySQL). Avec les modules, le passage des ensembles de données aux tableaux de bord devient plus simple et l'expérience des nouveaux utilisateurs s'en trouve facilitée.
Metricbeat et Packetbeat intègrent aussi leurs propres modules. Quelques mois plus tard, Logstash propose à son tour des modules pour les données ArcSight et NetFlow.
Depuis le tout début, nous avions une idée en tête : simplifier le déploiement d'Elastic pour les entreprises. Nous avons donc exploité la technologie que nous utilisons pour gérer notre propre service Elastic Cloud et l'avons mise au service d'Elastic Cloud Enterprise (ou ECE). L'objectif ? Permettre à toutes les entreprises, des plus grandes aux plus petites, de télécharger tous les avantages de notre offre hébergée et de l'exécuter elles-mêmes. Avec ECE, la gestion d'un seul cluster ou de milliers de clusters devient simplissime. Et elle permet de rationaliser la gestion et l'orchestration des produits et solutions Elastic dans n'importe quel environnement.
Avec la multiplication des modules, se lancer avec la Suite Elastic pour répondre à un cas d'utilisation donné (logging ou indicateurs, par exemple) devient de plus en plus simple. Une dynamique qui continue avec l'arrivée d'Opbeat, et, quelques mois plus tard, de Swiftype : la première est une société danoise spécialisée en monitoring des performances applicatives (APM), la seconde, une société californienne spécialisée en solutions de recherche pour sites web et entreprises. Les deux entreprises font maintenant partie d'Elastic.
À ce stade, notre entreprise avait gagné en maturité et s'était armée de méthodes rationalisées pour résoudre les problèmes courants. Nous étions en mesure de présenter officiellement nos solutions. Et si celles-ci vont de la solution en libre service laissant l'utilisateur libre de bidouiller, jusqu'à des solutions clés en main, chacune est adossée à un vrai produit et son déploiement ne prend que quelques minutes.
De l'open source à la communication ouverte, l'ouverture nous tient décidément à cœur. C'est pourquoi nous avons décidé d'ouvrir le code de nos fonctionnalités commerciales X-Pack à la lecture. L'idée est d'accélérer le processus de développement et de booster l'engagement de la communauté – chacun pouvant contribuer à notre code, l'inspecter et nous faire part de ses commentaires.
Résultat : se lancer avec la Suite Elastic devient encore plus simple – toutes les fonctionnalités intégrées à X-Pack étant maintenant disponibles avec les distributions par défaut d'Elasticsearch, Kibana, Beats et Logstash. De plus, nous n'avons pas touché au code Apache 2.0, qui reste disponible. À la place, nous avons préféré doubler la dose d'ouverture. On ne se refait pas.
Le 5 octobre à 9:30 sonnantes, la cloche de Wall Street a retenti, faisant officiellement d'Elastic une société ouverte. Avec 230 salariés d'Elastic présents dans la salle de marché (du jamais vu) et des centaines d'autres sur les quatre continents, notre entreprise distribuée à fêté ce grand événement. Ce n'était qu'un jour parmi tous ceux qui nous attendent encore, mais c'était un grand jour. Avouons-le.
Notre histoire ne fait que commencer. Restez connecté pour ne rien manquer de l'aventure.