The Motley Fool Discussion Boards

Previous Page

Investment Analysis Clubs / Saul’s Investing Discussions


Subject:  Re: An Elastic technical review. Date:  5/14/2019  12:41 PM
Author:  CMF_muji Number:  55703 of 69241

An Elastic technical review.

1 - Overview
2 - Elastic Overview
3 - Compare to MDB

PART 2 <<<
4 - Strengths, in Haiku

5 - Use Cases
6 - Final Takeaways


"With Better Search
An ever expanding TAM
To Infinity"
- muji, TMF Poet Society, May 2019


Elasticsearch provides much, much richer SEARCH and ANALYTICS capabilities compared to document stores like MongoDB. Elasticsearch has a more of a learning curve (having a more convoluted API format, and more complexity in setup and usage), but that is for a reason -- it does a LOT more.

Relational database has an engine that can host separate databases, each having a set of tables containing rows, columns (fields), indexes. Think of it as an Excel workbook (database), having multiple workbooks (tables) full of rows and columns. Each row has a statically defined set of fields in columns, and typically has a unique identifier (primary key) used for retrieving that row. Each table has indexes, that allow for faster filtering & sorting capabilities across its rows in predefined ways. "Relational" is about how data is able to join together - in Excel, it would mean the workbooks would be able to reference the rows in other workbooks. You query, insert, update and delete data via a "structured query language" (SQL), which is standardized across the industry. You can calculate statistics via aggregations in an ad-hoc way via SQL (GROUP BY, SUM, AVG, MIN, MAX, nested sub-selects, joins, etc). But it's not capable of advanced analytics - the data would need to be exported into another package for that.

MongoDB is an engine that can host multiple databases that contains one or more collections (tables) of like documents (rows), each with a set of fields (columns) that can be varied. Each individual document (row) can be looked up via its assigned uuid (primary key). It can also have pre-determined indexes of specific fields, for faster searching. Being NoSQL, there aren't really "relations" (joins) unless they are manually looked up in a followup query, or embedded as a sub-object in the document itself. (v3.2 did finally add a simple join mechanism that allows retrieving a child document from a separate collection.) You can group and calculate statistics via an aggregation pipeline, which is a set of instructions to filter and group rows then calculate statistics over each group.

Elasticsearch is an engine that does ALL those same things MongoDB does. It is a cluster (database) that hosts multiple indexes (tables). Each index has multiple documents (rows) comprised of fields (columns) that can be varied. Each document has an assigned uuid (primary key) to retrieve that document. From there, however, the search, aggregation, and analytic capabilities are greatly improved in Elasticsearch's indexes over MongoDB's collection indexes. It too has an aggregation pipeline capability, where you can nest logic to filter, sort, group and analyze results. However, its analytical capabilities are much greater than standard NoSQL data stores.

Why is the search so much better? It's built on top of Apache Lucene, an indexing system that allows for quick lookups. Lucene started as a full-text search engine, but has greatly improved over the years in handling numerical indexes as well, including time-stamp and geo-location fields. In particular, the numerical and geospatial indexing in Lucene has greatly improved over the past few years - helped by Elastic developers, who are major committers to the Apache Lucene project.

Where Elasticsearch really starts to shine is in AD-HOC filtering and aggregations. When you set up traditional indexes in a relational database, everything must be rigidly defined. MongoDB loosens up that rigidity a bit, but still requires pre-defining fields in indexes. Elasticsearch can act as ONE GIANT INDEX over your data that doesn't require pre-defining how you are going to look at and search on that data. Data can be any combination of structured (rigid collection of objects with schema defining each property) or unstructured (loose collection of objects with varied properties).

For analytics, Elasticsearch's aggregation capabilities are incredibly flexible, and allows for very custom nested aggregations. Aggregations can be done over search queries, to bucket the results into groups based on a criteria (repeatedly, if desired, in a nested hierarchy). You can either retrieve the raw data, or then extract statistics about each resulting aggregated group. For example, you can group results by year & month, then by city, then aggregate statistics for each resulting nested sub-group (like 2019-01, Denver). Time-series based data can be grouped into smaller time slices, like calculating a rolling 5 minute avg of a metric over a month span. Geo-locations (long/lat) can be grouped into shapes and regions.

Elasticsearch does full-text searching through a scoring & ranking system. It exposes a wide variety of search methods over textual data (word proximity, text variation matching, top X ranking, pattern matching, fuzzy text matching, account for misspellings, etc). The other search type is structured searching, exact matching or range matching on text or numerics. This includes many numeric use cases, like timestamps, IPs or geo-locations. Numerics really open up the use cases - searching and analyzing time-series data (like sensor data) and geospatial datasets (like sensor locations) really shine within Elasticsearch, where grouping and aggregating by time period or by geo-location is handled incredibly fast. It is hands down better than relational database indexes over columns, and the improvement widens further as the size of the data grows.

As data is imported into Elasticsearch and being indexed, it can be set up to go through different text analyzers & tokenizers to split an incoming document into relevant search terms. This allows you to customize how the search internals work based on how you plan to use your data. It supports structured or unstructured data, and you can provide the structured layout (schema) as desired. You can also embed child data within a parent document and search through that.

Multiple indexes and aliases:

One big strength of Elasticsearch is the ability to search over multiple indexes in a single query, including the use of wildcard. This allows you sub-divide your indexes into natural ways you plan on querying or managing it. For example, you can create a new index per month for the same core index name. Break up your data by month, and you can then query over any number of monthly indexes as desired. For ease of crafting queries, you can set up aliases that cover multiple indexes, so you only reference one alias instead of multiple indexes each time. Aliases can keep your query static over time, such as using an alias for trailing 12 months that you shift each turn of the month, and the alias will control what monthly indexes that covers each time you query.


First thing you set up in your query is what is the overall data you want to view (filter) and what order you want results (sort). You can filter and sort by any field within the index, like a timespan or US State -- however you want to slice and dice the data. Once you isolated that desired filtered results, you can then expand that filtered query with additional nested filters, sort it, or then add aggregations.

There are 2 overall modes of searching:

* Full-text searches attempt to match the most relevant documents to your filter. It can use relevance and token analysis, combined with boolean logic ops (like must, must_not, should), in order to generate a ranking score per document. You can create +/- score adjustments based on criteria, called "boosts", to better hone your results (ie searching on "tests", but not wanting "unit tests" also matched, so you demote it).

* Structured searches make a boolean determination (a yea or a nea) per document. It allows matching against exact text (categories, tags, names, ids) or numerics (number, dates, times, geospatial locations). You can search by exact match or ranges, and use logic operations.

There are multiple types of queries over those modes.

- Full-text queries = ranked full-text scoring (match, match phrase, multi-match, synonyms, stemming, bigram matching, phrase matching, fuzzy matching, misspellings) and span matches (word proximity, order of words)
- Term queries = yea/nea text matches (exact terms, ranges, wildcards, and regex) like searching over tags, usernames, locations, etc
- Numeric queries = range matches against numeric operations (greater than, less than, between) including over date, timestamp, geospatial and IP fields
- Geo queries = geospatial location matches (within distance of a point, or within one or multiple bounding shapes)
- Join queries = search nested child rows in document

Beyond the large number of filters available in Elasticsearch, if you have highly specialized needs, you can use a custom embedded script to create your own.


After performing a search (filtered query) you can also specify one or more aggregations, to group the search results into buckets and/or generate statistics. The power of aggregations is that they can be nested. For example, bucketing search results on state, then bucketing those results (per state) on city, then aggregating count on each group (per state & city).

- Bucketing = Group data on criteria based on field(s), like term matchin, histograms, date histogram, geospacial bounds, term matching, etc.
- Metrics = Compute analytical stats over group
- Matrix = Group multiple fields into matrix
- Pipeline = Aggregate results from other aggregations

All these filter and aggregation features, and the ability to nest them together in complex queries, open the door to all kinds of search & analytical capabilities.


We live in a technological world where datasets are ever-growing, as you pull in time-series data feeds from monitoring IoT sensors or infrastructure. In some cases, data can get stale and need to be discarded -- either archived, rolled up (summarized), or dropped. In other cases, especially around analytics, you want the entire dataset kept as a "data lake" (a pool of all your raw data) containing all your internal knowledge and data. The cloud allows this, as you can scale up your compute & disk capacity as needed. [There is still a place for "data warehouses", which is more a pool of processed, filtered, or rolled-up data, as opposed to raw data. DreamerDad has mentioned Snowflake before, a cloud-hosted SaaS data warehouse service. I would definitely look closer at them if and when they are go public.] Regardless, most company's data needs are large now, and only going to continuously grow from here.

There are 2 ways to increase the capacity of a data engine. Vertical scaling is increasing a server's capabilities (giving it more disk, more RAM, increasing network bandwidth). This is what you were limited to in the "olden days" of relational databases. However, if the data engine is capable of running as a cluster, comprised of one or more nodes (individual systems), you can horizontally scale, which is increasing the number of nodes in that cluster. Each additional node added to the cluster increases capacity and capabilities. Both MongoDB and Elasticsearch are clustered data engines that utilize replicated shards. (Though, to be clear, MongoDB can run standalone for smaller datasets. Elasticsearch's setup for production use requires 3 nodes minimum. It was built for clustering from the start.)

Sharding (also called partitioning) is a way to split up a data set across a cluster, to allow you to 1) horizontally split your data, to be able to scale the performance and size of your cluster, and 2) allows you to distribute and parallelize operations across shards located across cluster nodes, to improve performance & throughput. So, as an example, say your dataset has 5 shards, each containing 1/5 of your data. Those shards can be located across multiple nodes within your cluster, splitting up the work load and the compute, memory & disk use.

An important aspect that shards enable is shard replication. Each shard is a fraction of your dataset, and by replicating that portion of your dataset across nodes, you are able to 1) scale your querying capabilities (each node does searching and aggregating on shards it holds) and 2) prevent data loss by always having a replica to fall back to ("high availability"). As search queries come in, they can go to any node in the cluster that has a copy of that replicated (read-only) shard. A replication factor of 2 means each shard is replicated 2 additional times, to 2 different nodes than the one the primary shard resides on, so that a total of 3 copies of that data always exist. That replication factor would triple the concurrent search requests that can occur simultaneously (splitting up the load between the shard replicas, and so between nodes of the cluster). It would also allow for up to 2 nodes to simultaneously fail without data loss occurring -- if a node goes down, a replicated shard on another node can turn into the primary shard (that new data is written to and that is cloned to the other replicas), and a new replica is created to take its place.

Scale (enabled by shards and replication) is everything when dealing with clustered data engines. The primary reason folks are moving off of SQL databases is the lack of horizontal scale capabilities in today's data driven world. Huge volumes of incoming data means your cluster needs a large ingest capability. Large data sets require a lot of disk and memory to handle it. Having a constant stream of continual queries means your cluster needs a large search capability and network bandwidth. Relational databases, unfortunately, have really been left in the dust here -- there are tricks you can play with read-only replication, but there are very few clustered SQL engines that can horizontally scale. MemSQL is the only one that comes to mind, and it's in-memory only (no disk) and not open-source. You have to go to NoSQL for this kind of capability, such as Cassandra, MongoDB or Elasticsearch.

Taking clustering capabilities a step further, an "elastic" cluster is a "smart" cluster, one that knows when nodes are added and removed from the cluster, and is able to balance the data across all the available nodes. It gives "high availability" by being able to keep search and ingest continuously available during node outages, plus is able to balance shard data across new nodes as they are added, or shift replica shards to primary when a node disappears, and, in either case, reshuffle the replicas across the cluster. I think you can tell where Elasticsearch gets its name.

Unlike MongoDB, Elasticsearch also provides the ability to scale indexes (tables) internally. An individual "dataset" in Elasticsearch can and should be MORE THAN ONE INDEX. That gives developers a huge improvement in how they manage scale of individual datasets within the cluster, and to control how those massive datasets are segmented for queries.

Within a given dataset, you can split indexes on a time frame (say, spawn a new index daily). You can specify multiple indexes per query, plus use wildcards in order to search over split indexes in a controlled way. As an example, you can roll a base "system-metrics" into a new index per day, tracked as a suffix on the base index name (e.g. 2018-01-01). 2018 data can easily be queried via a wildcard search to "system-metrics.2018-*", or just query the first quarter via "system-metrics.2018-01*,system-metrics.2018-02*,system-metrics.2018-03*" (which would search over 90 different daily indexes of that dataset). You can utilize aliases in Elasticsearch, that are mapped to a specific grouping of indexes. So that last example above could be more easily referenced in the future as "system-metrics-2018q1".

A dataset could be set up as one giant index that contains all the data and you would use query filters to narrow the timespan of your search. However, splitting indexes across time period (or other factors) greatly enhance SCALE and MAINTENENCE of that index. This provides many ways Elastic Stack users can gain huge improvements in speed. In using honed queries that are optimized to your split index strategy, you can greatly reduce how much data within that dataset to search through. So instead of searching over the one big "uber" index containing all the data over time (say, 20B documents), you can isolate your searches to query only the subset of the time period you need (say, the month of April, which is only 10M documents). As new data arrives, it can get split up into individual indexes per time period (known as Rolling Index strategy), so datasets can ever-grow (scale continuously) by creating new indexes once a new time period is reached as a split point. This greatly helps a user manage the lifecycle of their indexes, by allowing them to curate their data as it continues to stream in. As data ages, you can trim stale or archived data very easily, by simply removing the specific split indexes covering the time periods you wish to trim (instead of the traditional SQL method, of having to do a filtered delete query). Or you can set latest data to be on the fast hardware and older, less referenced data to be on slower systems (known as Hot/Warm strategy).

Add up all the scale capabilities, and Elasticsearch is a data engine capable of storing and querying a massive amount of data in "near real-time". It can handle a fire-hose of incoming data (indexing it in a shard quickly, then replicating it to other nodes) so as to make the incoming data immediately available to ad-hoc searches and aggregations. This makes Elastic Stack very relevant for "Do-It-Yourself" style use cases like monitoring. You can make your own Splunk or New Relic clone to monitor your apps and infrastructure, and greatly reduce ongoing costs.


So they have search and analytical capabilities that can elastically expand as a company's needs grow. Now that we have all that technical talk out of the way, let's talk strategy.

One huge difference in their business strategies is that Elastic hasn't been afraid to acquire its tooling. Kibana and Logstash were both acquired in 2012 to form the base ELK Stack. Packetbeat in 2015 provided the foundation of Beats. Found in 2015 was integrated as Elastic Cloud and Elastic Cloud Enterprise.

MongoDB is catching up here in terms of ecosystem. In 2015-2016 they added Compass (data exploration and mgmt console) and backup & mgmt tool Ops Manager, but it took until v4 release in mid-2018 for them to add Charts (viz dashboards), and to begin expanding their tooling into a cloud platform with Stitch. MDB made Atlas themselves in 2016, then later acquired mLab in 2018 to acquire their customers and migrate them to Atlas.

MDB has created a great company, and has created many new tools, but wasn't always focused on creating a unified platform. Elastic has a large number of bolt-on acquisitions, where it acquired all the pieces and parts of its ecosystem. This has allowed it to move much faster than MDB; but then again, it needs to, given it's more limited use cases.

Licensing changes:

Let's take a minute to talk about all the open-source licensing changes that have occurred in these enterprise companies built around a specific open-source database. Jay Kreps, CEO of Confluent (company around Apache Kafka), explained the thought process in his blog post about Confluent's changes.

The major cloud providers (Amazon, Microsoft, Alibaba, and Google) all differ in how they approach open source. Some of these companies partner with the open source companies that offer hosted versions of their system as a service. Others take the open source code, bake it into the cloud offering, and put all their own investments into differentiated proprietary offerings. The point is not to moralize about this behavior, these companies are simply following their commercial interests and acting within the bounds of what the license of the software allows.

As a company, one solution we could pursue would be for us to build more proprietary software and pull back from our open source investments. But we think the right way to build fundamental infrastructure layers is with open code. As workloads move to the cloud we need a mechanism for preserving that freedom while also enabling a cycle of investment, and this is our motivation for the licensing change.

I don't he meant that to be so either-or; companies can expand their open-source core as well as proprietary offerings. There are two different strategies these "open-source" enterprise companies are employing:
* Attack on the edges, by differentiating on the surrounding modules/tools in the platform. (Elastic, Confluent)
* Attack at the core, by preventing others from direct cloud-hosting. (Redis, MongoDB)

MDB is not leading the charge on the cloud front, either with cloud hosting services nor with fighting the cloud providers. Elastic bought Found in 2015 to make Elastic Cloud; a year and a half later, MDB released Atlas in mid-2016. Elastic made licensing changes in March 2018. Redis next followed suit in August 2018, but with a different strategy; they instead changed the license on the open-source core, to try to prevent cloud-providers from hosting it. MDB followed Redis's path in October 2018. Confluent followed Elastic's path in December 2018. Redis later changed their licensing AGAIN, in March 2019, to better clarify things. Which is the better or worse strategy here? Only time will tell, but thus far, we can see in their numbers that MDB and Elastic are having huge success with their managed cloud services, regardless of approach. Does MDB have to follow Redis again and change the license a second time, given the OSS community backlash? Elastic doesn't seem to mind their backlash, but they have a different strategy, and their core remains open-source (albeit still tightly controlled by them as sole contributors). [As we'll get in to soon enough, I pontificate as to how their strategy completely enables a whole new front in Elastic's new product lines.]

Elastic's acquisitions that added tools or SaaS services in their ecosystem:

* Kibana (2012) - Visualization dashboard app, that worked over Elasticsearch. Became part of core ELK Stack. Still here as Kibana, but its been greatly expanded with modules (Timelion, APM, security, ML, etc) and cluster mgmt interfaces.

* Logstash (2012) - Log collection app that converts log files into data objects, and imports them into Elasticsearch. Became part of core ELK Stack.

* Found (2015) - A managed vendor-neutral Elastic Stack cloud hosting service. Was integrated and renamed as Elastic Cloud service and Elastic Cloud Enterprise for the "on-premise cloud" version.

* Packetbeat (2015) - A real-time network packet analytics system, built on ELK Stack, to monitor distributed systems. Integrated and expanded as the Beats product.

* Prelect (2016) - Predictive behavioral analytics firm, focused on cybersecurity, fraud detection, and IT operational analytics. Now likely integrated as the ML modules in Kibana.

* OpBeat (2017) - APM system for Javascript apps. Integrated now as APM Server app and into Kibana for the APM UI.

* Swiftype (2017) - Startup providing hosted SaaS search service for enterprises to easily add search capabilities to their website or app. Elastic re-branded these offerings as Elastic App Search and Elastic Site Search SaaS services. These services directly compete against Google Search Appliance [RIP] and it's replacement, the Google Enterprise Search SaaS service, as well as Google Site Search [RIP] and it's replacement, Google Custom Search Engine. It recently followed those up with another - the Elastic Enterprise Search SaaS service just announced, which competes against the Google Cloud Search service (which recently expanded from searching G-Suite to include other 3rd party SaaS tools). This acquisition marked a turning point in their acquisition strategy; instead of tooling, they are moving towards SaaS services built on the Elastic Stack!

* (2018) - Startup with a developer-focused SaaS tool for creating a search interface over your source code. Supports a wide variety of modern programming. It's not just full-text search -- it has semantic understanding of the code, so provides intelligence over your code base. Supports code cross-referencing, class hierarchy, functional understanding of logic & structure. [Wow! I could use this!] This seems an essential service for software development shops, allowing them to tie "code intelligence" over their APM, logging and infrastructure monitoring that Elastic Stack already excels at. I haven't seen any particular Elastic-branded module or service appear yet from this acquisition [but I am watching now]. Sounds like it is something that would be kept as a SaaS service, and compete in the same developer-focused SaaS space that Atlassian is in.

Let's review those acquisitions above -- Bolt on, bolt on, bolt on, bolt on... check check check check. I am way more impressed with Elastic than MDB here. Very natural expansion of product line and TAM as they consume apps and services around or, even more excitingly, built UPON Elasticsearch. Kind of like the Borg. I'm not sure I can come up with an example of company doing this before -- making a database platform for developers and IT staff to use, then starting to run SaaS services built upon it that are enabled by that database, that are solving the same use cases but without the need to maintain or interface with that database or require any custom development.

MDB is trying to move into the same ecosystem - enterprise plug-ins with a premium cost, mgmt interfaces, and (finally) a viz dashboard and improving analytical capabilities. But they are moving way slower than Elastic, and are never going to catch up to start stealing business from Elastic for search & analytical use cases. I think they are playing it safe & conservative, as they already have a wide set of use cases. Any collection of data in a modern web or mobile app can use MongoDB. You don't build a financial transaction service upon it, perhaps, but most everything else, surely!

As I said in "MDB Goes Mobile" post: MDB just had an acquisition, their third. Their prior one, mLab in Oct 2018, cost $68M, and allowed them to convert customers from an Atlas competitor (managed cloud-hosted MongoDB instances) into Atlas customers. While that last acquisition was a customer and team acquire, they just bought Realm for $39M to acquire product lines that help them jump start their new mobile initiatives.

MDB had an acquisition to buy customers (mLab). They already had their own mobile database product and had a mobile sync service in beta -- yet they NOW decide, after that development effort, to purchase Realm as a bolt-on (and, I'm guessing, scrapping their efforts thus far towards mobile and sync). I can't tell why MDB is intent to keep moving so slow by building everything themselves. Charts, their new SaaS visualization dashboard service, was new in v4 released a year ago... yet is still in beta nearly a year later. Not impressive! They could have easily bolted on a viz dashboard long ago, but instead they built it from scratch. (Taking, what, maybe a year, maybe more, to develop? Make that two... it's been 11 months since release and still is marked BETA.) And, a step farther, I don't see MDB making enterprise SaaS tooling of products based on MongoDB, either.

Elastic on the other hand, is expanding their platform to help them find more and more appropriate use cases for Elastic Stack ... AND to find new successful SaaS services built on top of Elastic Stack. Either way, they expand use cases and expand the potential TAM. There is NOTHING stopping them from making a competing services to Splunk, New Relic, or DataDog -- but for now they are focused more on enabling others to do that.

Or are they? Look where Elastic is starting to acquire or create new business-focused SaaS services. Swiftype, a hosted search service acquired in late 2017, is the incubator of these impressive new business-facing SaaS services. Elastic is now "eating its own dog food", as we say in the software biz (aka consuming its own services), by creating SaaS tools built on top of itself!! Elastic now has new SaaS services based on Elastic Stack under the hood. I linked to both branding pages, as Elastic seems to be leaving Swiftype segment on its own - perhaps for existing customers and word-of-mouth. Pricing tiers have document and use limits, with upcharges for more. Each come with one search engine per customer, but can be upsized for higher content indexing or searching needs.

New SaaS or Hybrid Services:

* Elastic Site Search Service
SaaS search service to add site indexing & search capabilities to your web site or app. Provides embeddable search bar with autocomplete. Can leverage the power of Elasticsearch for text searches (spell correction, similar word matching, synonyms, phrase matching). Great for e-commerce, knowledge bases, media content. Okta and Shopify both listed as customers. They highlight Twilio using it in their API docs.

* $79/mo Standard - crawl up to once/day, multi-lingual (5k doc limit; 50k request limit; 1 search engine)
* $199/mo Pro - crawl up to once/hr, PDF/DOCX indexing, cross-domain, analytics (10k doc limit; 100k request limit; 1 search engine; 1 domain)
* $??/mo Premium - dedicated hardware & support, SLA

* Elastic App Search Service
SaaS search service built over Elastic Stack. Allows companies to feed in data from a variety of sources (like their own databases), either on-premise or in the cloud, in order to allow search capabilities within their app over that data. [Someone tell The Motley Fool, that right there is their new content & board search tool!]

* $49/mo Standard - basic searches & analytics, 7d history, unlimited users (50k doc limit; 500k request limit; 1 search engine)
* $199/mo Pro - advanced searches & analytics, multi-lingual, 6mo history, cross-domain (100k doc limit; 1M request limit; 1 search engine)
* $??/mo Premium - dedicated hardware & support, SLA

* Elastic Enterprise Search
New beta service JUST ANNOUNCED LAST WEEK (no pricing shown yet), that again emanated from the Swiftype team. SaaS search service that provides an enterprise search capabilities over all of their SaaS team tools (Salesforce, Github, Dropbox and Google Drive content, Slack, Zendesk, etc). Maintains data security as a user can only search the content they can view natively in those SaaS services. Wide variety of SaaS services supported, and you can +/- boost the search priority of each. If your tool isn't supported, they have the ability to add it via a custom connector. Fantastic expansion of the Swiftype platform. I expect the number of services it integrates with to increase from here, Okta style.

As Darthtaco discovered in the blog post announcing it, you can run this on Elastic Stack yourself with the Platinum tier enterprise license. So it's a Hybrid product that is both a SaaS offering as well as a module in the Elastic Stack. Their marketing maintains a great balance - basically saying "we can do this as a SaaS service for you, or build it yourself with Elastic Stack". Great way to upsell the enterprise support licensing (like they did with ML features, which require Platinum tier). Given it ties into Github, I wonder if they will tie in the "code intelligence" platform from, or if that becomes its own SaaS service.

All of these new services have enormous potential as enterprise SaaS apps in their own right. Perhaps not as sticky as Okta, considering it competes with Google on all of them. But it seems like just the tip of the iceberg as far as what Elastic could do here, in terms of enterprise-focused SaaS tools for search & analysis. It is interesting to consider that the lack of changing the licensing of the core ELK Stack is enabling this angle -- they can let SaaS companies build search and analytical services upon their stack. Once they are successful and if they apply to a use case Elastic is targeting, they could acquire them to bring them into the ever growing ecosystem of search-related SaaS services they can provide to customers that don't want the hassle of using the Elastic Stack platform itself.

To be continued, in Part 3 (due to TMF post size limit)...

long ESTC (7%)
Copyright 1996-2020 trademark and the "Fool" logo is a trademark of The Motley Fool, Inc. Contact Us