三、产品能力
从早期开发的 Elasticsearch 到之后 ELK Stack 的发布，Elastic 在此期间经历了辉煌发展，也有混乱的时期，随后又推出了 Elastic Stack，并迎来了新的时代。
2000年
源自查找菜谱的 APP
伦敦的公寓内，Shay Banon 正在忙着寻找工作，而他的妻子正在蓝带 (Le Cordon Bleu) 烹饪学校学习厨艺。在空闲时间，他开始编写搜索引擎来帮助妻子管理越来越丰富的菜谱。
他的首个迭代版本叫做 Compass，第二个迭代版本就是 Elasticsearch（基于Apache Lucene开发）。之后，他将 Elasticsearch 作为开源产品发布给公众，并创建了#Elasticsearch IRC通道，剩下来就是静待用户出现了。
产品正式发布后，公众反响十分强烈，用户自然而然地就喜欢上了这款软件。由于使用量急速攀升，此软件开始有了自己的社区，并引起了人们的高度关注，尤其引发了几位创始人StevenSchuurman、Uri Boness 和 Simon Willnauer 的浓厚兴趣。最终，他们四人共同组建了一家搜索公司。
2012年
Search Inc.阶段
在 Elasticsearch Inc.成立前后，另外两个开源项目也正在跨越式发展。
Jordan Sissel 当时正在开发 Logstash，这是一款开源的可插拔数据采集工具，可将日志文件发送至用户选择的“储藏库”。除此之外，他还在开发一款 UI，以实现日志数据的可视化，但这一产品的稳定性却实在让人难以恭维。
幸运的是，还有其他人也在潜心钻研可视化这个难题。这个人就是 Rashid Khan，他当时在开发一款名为 Kibana 的开源 UI。
Shay、Jordan 和 Rashid 彼此已认识了一段时间，对各自的产品也颇为了解，所以他们最终决定携手共同发展，ELK Stack 正式面世，即：Elasticsearch、Logstash 和 Kibana Stack。
不久之后，Elasticsearch Inc.就推出了两个商用插件：一是用于监测的 Marvel，二是用于防护的 Shield。
2015年
更名为 Elastic，喜纳 Found
在 2015 年于旧金山举行的 Elastic{ON} 大会上，Elastic 宣布了两项重要决定：第一，将公司品牌更名为 Elastic，新的品牌名称能够更好地代表逐渐扩大的产品生态系统和用例套件；第二，Elastic 与在 AWS 上提供 Elasticsearch 主机托管服务的公司 Found 实现了合作。通过这一合作，Elastic 能够提供市场上最简单、最全面的产品组合。
最初发展的问题
早期，Elastic 开发和发布软件时采用的是工程师各自为战的方法：工程师可以在任何时候推出任何喜欢的版本，唯一的要求就是产品要好。Kibana 有公测版，Logstash 采用里程碑，
Elasticsearch 则采用数字编号。如果工程师高兴，还可以推出插件。尽管十分混乱，但是一切还算行得通，直到最后无法使用。
随着用户通过产品来完成越来越多的任务，Elastic 需要开发更好的产品来为用户提供更多帮助，所以添加了更多功能，开发了新插件和扩展。产品的确变得越来越好了，然而也越来越复杂，技术栈变得越来越混乱。
例如，如果运行的 Elasticsearch 是1.7版本，而运行的其他插件是 2.3 版本，则软件不能自动检测二者是否兼容，也无法验证插件是否在无预警的情况下已不能正常使用。
在 Elastic，也开始听到内部员工说：“如果想使用 Shield，需要使用 Elasticsearch 1.4.2，但前提是不能使用 Watcher。如果使用 Watcher 的话，则需要使用 Elasticsearch 1.5.2。而如果使用 Elasticsearch 1.5.2 的话，其仅能与 Kibana 4.0.x、Logstash1.4.x、Shield 1.2.x 和 Watcher 1.0.x 兼容。”
Elastic 的版本控制做得一团糟，必须得研究对策；同时，支持矩阵也表现欠佳。
调整业务步伐，推出 Beats
就在产品团队为版本编号忙得团团转的时候，另外一个产品故事正在拉开序幕。Elastic 在2015年迎来了 Packetbeat，这是一家夫妻档公司，致力于开发一种轻量化方式来将网络数据发送至 Elasticsearch。
这启发了当时的 Elastic：如果开发一系列单一用途的轻量化数据传送工具，将网络数据、日志、指标、审计数据等从边缘机器传输到 Logstash 和 Elasticsearch，结果会怎样？就这样，
Beats 应运而生了。
