Elastic N.V. (ESTC) Earnings Call Transcript & Summary

Hello, and welcome to the Elastic Observability Update Metrics Call. Today's call is being recorded. [Operator Instructions] I would now like to pass the call to Alex Kurtz, Vice President of Investor Relations. Please proceed.

Good morning, everyone. Welcome. I'm Alex Kurtz, Vice President of Investor Relations here at Elastic. Thank you for joining us today for a deep dive into our new metrics offering. Joining me are Baha Azary, General Manager of Observability and Santosh Krishnan, Senior Vice President of Security and Observability Solutions. For today's agenda, Baha will start with a brief presentation followed by a short customer video, and then we'll open the floor to Q&A. But first, let me quickly run through our legal disclaimer. Our presentation today will include forward-looking statements, which may include predictions and expectations regarding the market and demand for our products and solutions as well as expected capabilities of our products and solutions. These forward-looking statements are based on factors currently known to us, speak only as of the date of this presentation are subject to risks and uncertainties that could cause actual results to differ materially. We disclaim any obligation to update or revise these forward-looking statements unless required by law. Please refer to the disclaimer of risks and uncertainties shown here as well as those more fully described in our filings with the Securities and Exchange Commission. With that, I'll hand it over to Baha.

Thank you, Alex. Let me go to the next slide, Ken. All right. Hey, everyone. I'm Baha, I'm the General Manager of Observability here at Elastic. I have been at Elastic for 11 years, and it's a pleasure for me today to present you with our new metrics offering. So our new metric offering has been launched almost at the beginning of our fiscal year in June. And so what we've done with this new metric offering is entering this market with a solution that is not only meeting our customer requirements but also surpassing some of the best metric solution in the market. And so you will see in this presentation how we did it. But in the high-level lines, we rearchitectured the Elastic Search 4 metrics, and we are also meeting our customers where they are. And we also make sure that we are preparing our -- we're building our metric solution for what our customers are doing today, namely looking at AI workloads. And so three characteristic of our metric solution. First, it's blazing fast. If you enter the metrics market, you have to be fast, and that's one of the guiding principle for a solution. We looked at benchmark against competition, competitive solution, such as Pomitas and Mimir. I'll get into the numbers more in detail later in this presentation. The other thing we've done is we don't want our customers to go from one solution to another when they have their logs, their traces and their metrics with us. They need to stay in the same platform. The data store should be the same. It's completely transparent for them to store all those signals with us when they do Observability as well as when they acquire the data in Elastic or they go through the different experiences we have for observability. Everything leaves in the same platform. And lastly, we build it for AI. When the workload shape has changed with AI, having now agents, more than [indiscernible] application, it brings much more signals, much more data and much more metrics than before. So we thought about our metric solution to be as efficient as possible to cope with that new type of workloads. But before I get into more details about what we've done, just level setting with everyone, if you're not familiar with what the metrics are metrics is the main signal in Observability. That is literally what wakes up engineers at 3AM in the morning when there is an incident, page people when there is something to look at. And so when you use an Observability solution, you create rules. Those rules are triggering alerts and 99% of the time, those rules are based on metrics. And so a couple of examples here on the screen. You can create -- say you have an application, a web application and you're looking at the traffic on this application, you will look, for example, at the number of HTP requests. This application relies on an infrastructure on an application stack. There's different technology involved and resources that are allocated to this app. And so you will look at the resource utilization, such as the CPU or you can also look at things like the latency of the request going into the APIs you're exposing through this application. So a lot of those characteristics of your application are emitting metrics, your application, your infrastructure are emitting metrics. Those metrics are capturing Observability solution, and then you create rules that triggers alerts that then page people. The thing that has changed is when you look at a traditional application, say, a banking application, and you go yourself as a user in your bank account and you look at your statement, you scroll through the statement, you click on the [indiscernible]. All of those are predefined path transaction into those applications that are quite traditional. You have front end, the back end and data store, database, micro services, cloud deployments, all of that, I put this into the bucket of a traditional application. And so not only those transactions are well known and in addition to this, like I said, this emits traces, logs and metrics and so there is a predictable volume you could expect for it. But for agents, it's very different. AI is really causing an explosion in metrics. And when I say AI, you can think about the different type of workload or things you need to observe such as LLM calls, GPU cycles, right queries, agent and harnesses all of that is creating a new set of Observability signals that needs to be captured. But then the challenge is, as you all know, when you interact with an LLM, there is reasoning steps and those reasoning steps, it depends on what you're asking for. It goes into tool calls. Those tools are not necessarily known in advanced. And so now you have agent calling your traditional application probably exposed through MCP and it's really unpredictable amount of turns you will get with agents. So that goes now a new paradox for customers. First, customers have to think about -- how am I going to cope with all that data. And we know that there is a solution out there that are penalizing customers and they are not able to keep all the data. The problem with this is, then they will -- they start to have blind spots. They have to compromise on the number of data they can keep. And then when there is an incident, they don't get the full fidelity on what happened and then -- and it becomes difficult for them to understand what the root cause is. So new challenges with AI. And so when we started to think about how we will go to market with this new matrix offering, we set a couple of guiding principles, and I will explain those more in details in later slides. But first, we introduced a new way to store metrics and not only to store them but also to manage them. So it comes with functionalities that will automatically roll up, down sample or compress the data. Second, we wanted to make sure that users of metric solution will feel familiar when they land with Elastic and use our metrics offering. And so we put a particular attention to support standard in the market, such as PromQL and we will see that. And lastly, Again, we build it for the AR scale. So you saw that AI is bringing more data and new things to observe. And we build it for that with the efficiency that is required to cope with that workload. And so you know that -- you know Elastic probably for logs, our customers are trusting us for their messy logs. We're more than happy to receive all that unstructured data. We are -- at the core, we are a search engine, so very good for structured and unstructured data. Logs are flowing in. They get into a document store. We extract those fields and then we make them available for aggregation. We can fall take search on it. So that's our story on logs and how we do it. We use a document store. For metrics, the game is very different. Because the metrics have different shape on logs. There are numbers. They come with labels. So for example, you have something like a number that represents the CPU usage, you have the time stamp, you have dimensions. It belongs to this host that is deployed on this [indiscernible] part that is deployed on this region of the world that is deployed on this cloud provider, et cetera, et cetera. So many different dimensions. And so -- for this to cope with metrics, we completely rearchitectured Elastic search for it, and we build a corner store within Elasticsearch because metrics are coming with their own challenges. I just talked about the dimensions. First, the dimensions is something that is very hard to manage for existing metric solution in the market. And we wanted to make sure that we were not limiting our customers in terms of the cardinality. Those are the words you will hear a lot with metric solution out there, cardinality is something we don't want to limit. So you can have as many dimensions as you want. But then we say that and then our users are like, okay, but what does that do in inquiry? Because when you have a lot of dimensions, it starts to be difficult to manage all that data in memory and so [indiscernible] store really well architecture, it's a great fit for metrics. Let's say you have 30 dimensions, going through 30 dimension when you query has its own challenge. When you go to 2 dimension out of the 30, you need to just take those 2 dimensions and not parse the data for the 28 left. And so that creates some challenges in memory that we actually solved with techniques like [ Dim Filter ]. We also solved how we can manage the data on storage and make sure that it's efficient by tuning our codecs. So we use a lot of techniques as many techniques as we can to make sure that our [indiscernible] store is efficient for acquiring and for storage. And the numbers are telling. We have documented our benchmarks. They are available online. You have them in Gita open source code, so you can run it and verify those numbers. So what we've done for logs, we've done it also for metrics, and we're very proud of it. We're benchmarking regularly against the noted competitors here to be 30x faster than [ Prometeineer ], 8x faster than [indiscernible] and get storage efficiency for our customers. So when they think about consolidating their metrics alongside their logs they have with us, they see immediately performance gain and immediately storage efficiency. So like I said, we have logs that goes into document store. We have metrics, [indiscernible] document store. We have metrics that goes to [indiscernible] store. We have vectors that goes into vector store. But what does that mean for Observability? We have this platform with integrated stores that benefits our users for Observability. And how we do that, imagine that question on the right-hand side, why is checkout slow? And imagine that a user will ask it through our AI agent or directly an AI agent through investigation as this type of question in natural language through the reasoning. Those are going through many data layers, metrics, it goes down to traces, looks at the signals in traces and services and then drill down into logs. And maybe the customer will bring their knowledge base, and this knowledge base is vectorized and so you can see that bringing all those data store in an integrated way and an efficient way allows us to be ready for this type of reasoning that is done with AI through Agentic [indiscernible] with our users through chat. And so we are enabling our users to RCA this way with those different data store degrading together. And so like I said, we build it for AI scale, but we also build it for a product that we've been cooking for quite some time, and you probably have seen that recently, we made the acquisition of a company called deductive AI that is specialized in RCA investigation with agents. And so if you're there in New York on the eighth of October, you will hear from us one of our biggest announcements in Observability. We've done -- we worked quite a lot on our AI story solution. So we're very excited to share this with you. Stay tuned and come and attend our Elastic con on the eighth of October in New York [indiscernible]. So we launched our metrics offering. I've talked a little bit about our storage efficiency and performances, but our matrix offering is also coming with a ton of functionality which I tried to categorize for this webinar into those 3 categories with functionalities that are -- that relates to meeting our customers where they are with PromQL, giving our customers with rich content, so they don't have to rebuild anything when they use our metrics offering and integrating this with different consumption surface than our UI for our customers harness and agents and making sure that our AI agent is also ready to serve with metrics insight within our solution. I'll go through some of it now. So the first thing we wanted to make sure we had is PromQL-native support with our Elastic metrics offering, which means that a user can take their PromQL queries, copy and paste it into Kibana, and they will just work. And to do this, we're using the most popular dashboards out there that are using PromQL and making sure that we're bringing 100% compatibility. We reached the 90%, and we are on track to get to 100%. So now our users feel familiar with our Metrix offering by acquiring with PromQL and also can use our AI agent to generate those queries directly into the solution. The other thing that our customers are asking us and specifically, the log customers we have that wants to bring their metrics alongside their lots with us is to help them migrate and of course, we have a professional services team that does that, but we felt that we needed also to have tools in the solution that will help customers to migrate from their solution to us. So we're delivering this as part of the solution today. The experiences with [indiscernible] we actually think about the existing experience we have and adapt it for Metrics. We actually rebuild them for Metrics. And so when I say rebuild and experience, that means delivering content out of the box and content is dashboard, visualization, alerts, SLO, skills, machine learning jobs, workflow all of that comes into an experience. They're fully loaded. We started with Kubernetes, which is -- which has the highest demand. We have AWS, we're working on other integration today. We even went above and beyond in terms of how we think an experience should be with, for example, integration with technology partner like Temporal, Super bays and Versal, where we have not only experiences as shown on the screen, but we also have managed endpoint. What does that mean? It means that a user that use, for example, Versal can point to our metrics endpoint, send their metrics, and we will manage that in just for them. It will scale as the data comes through. they will land into our solution and immediately have the experience they need for Versal. So this is the type of end-to-end experience that we're building for our customers. So not only we have specific technology endpoints to manage that intake of data, but we also have hotel and PromQL prompometers, endpoints to bring the data into our metrics offering. The other thing we want to do is to democratize metrics for any users. So if you're not a PromQL user and you don't have necessarily that expertise, and you want to be able to query the data, you can do that in natural language directly into our agents. More importantly, our users start to tell us that they -- on day zero, the way the consumer Observability is not necessarily into our UI. They're directly going into their agents and calling the tools and skills that we expose for them to consume the insight they have into our Observability solution. And so we are fully embracing this. We're, like I said, we're delivering MCP server, tools, skills, but also MCP app. What you see on the screen is our Observability MCP app. You can interact with it. It will give you insight on the anomalies that exist in your system, the blast radius of an incident. And so all of this can be done outside of UI in cloud, for example, in cursor, you name it, the harness that our users are using is where we're going to meet them. Lastly, in terms of go-to-market, we have 3 plays. First, we want to make sure that we're going and seeing our locks customers and attaching metrics to it because this is one of the demand that our customers have. They want to be able to investigate through their observability signals, all into the same place versus going into different solutions. So that alone is a huge opportunity for us. Second, we also have the PromQL shop, so users of [indiscernible] and PromQL, who wants to see immediately efficiency in terms of the query, efficiency in terms of the storage, but also scalability and not limited cardinality. This is also a place where we go and help our customers to consolidate in Elastic. And then the last play is for the customers that are being penalized to either keep metrics for a longer time or bring their own bringing customer metrics or just use metric solution. Some of the solutions out there are really penalizing in terms of the pricing that then creates the consequences that I've said at the beginning, blind spots which is not ideal when you have incidents. And so we want to win on the economics and go after that portion of the market as well. All right. With that, I'm finished. I will hand it over to Alex.

Yes. Thanks, Baha. And now we're going to present a quick Elastic customer video from Nouryon Bank discussing their observability strategy and their use of our new metrics offering. And then after that, we'll proceed to Q&A.

My name is Talinga, and I'm an observability platform engineer at Nordea Bank. My role is to make sure our engineered teams have the visibility they need to understand and operate their services reliably. We support multiple development teams across the organization helping them troubleshoot faster, improve reliability and get better insights into how the applications behave in the production environment and test the CI and so on.

So I'm [indiscernible] Anderson, observability platform engineer at Norian Bank. I've been part of the Noriomfamily now for almost 4 years, first as a consultant now full time. Our team runs the observability platform that the rest of the bank builds on. So in just the elastic infrastructure itself and tooling around it and helping teams out with any problems they may have.

Yes. One of the biggest challenges today is simply the amount of data, modern environments generate huge volumes of logs, metrics and traces. And the challenge isn't to collect data anymore. It's it's turning the data into actionable insights.

A few challenges. We have, I would say, one of the obvious for us being a bank is the compliance versus velocity. So Doran GDPR, which are regulatory systems mean that every change and pretty much every log line is auditable, and that pulls against the delivery speed that the business wants. Then there's the telemetry volume. Our data grows faster than the value we get out of it. So we're constantly making calls on what to keep and for how long, that's without going blind the moment something breaks or when we're reviewing a past incident. But I would say that our main concern. My main concern is that the question often becomes how do we get -- make this cheaper instead of how does this get us out of incidents faster.

We at [indiscernible] have been using Elastic for 8 years, I think give or take. And our usage has grown significantly over the time. Initially, we focused primarily on centralized logging. As our Observability maturity increased. We expanded into metrics, APM distributed tracing and open telemetry and so on. So today, Elastic plays a much broader role in our observability strategy instead of looking at the individual signals in isolation, we can correlate logs, metrics and traces in the same platforms.

Two things that's very positive about Elastic Search to me is Elastic Common Schema. So instead of correlating logs across systems is becoming a query instead of an integration project, which has been for us. And then there's the range of Elastic search. I mean the same building box goes to a small single node hobby project cluster to what we have, that is a multi-cluster production setup.

We really appreciate is having a unified platform as Elastic is our engineers don't need to jump between multiple tools and understand what's happening in our production environment or when they're testing new applications. They can move seamlessly between logs, metrics and traces and so I'm doing investigation on a potential incidental or...

We have tested some of Elastic new metrics features. Specifically, I'm quite impressed with time series data streams. So we built a small collector for our Azure DevOps pool cues and adjusted it into a time series data stream. And the storage savings we saw just after a month was substantial. So metric is really the only signal cheap enough to collect from everything continuously. So that gives us a very good baseline on what to alert on. So I mean, logs and traces explain why something breaks. But metrics tells us that it's starting to break and how bad it's getting. So for us, many of the failure modes we look at is things like heat this quarter marks in just lags and that sort of thing. And those are mostly gradual and show up in metrics long before any user notices anything wrong. We pay a lot of money for this and being able to and have the data, it's very important for us to be able to quickly identify when something is breaking because, I mean, even though observability costs a lot. It does so due to the fact that we will have a very good tool to see that things are breaking before and being able to sort of circumvent them. Sensors data works by declaring the dimensions. Let's -- it lets Elastic search co-locate and sort series together, so compression gets much better without really costing any query performance. And our new nonproduction environment that is eventually going to be our entirely new setup. We have integrated communities using Elastic agent to monitor and collect logs from pods and so forth. So yes, the experience is that it works really well. Nothing more to say. It just works.

[Operator Instructions] Our first question today comes from Rob Owens at Piper Sandler.

Great. Thank you very much, and thank you for doing this. Maybe you can, at a high level, just talk about how long it took you to rearchitect this solution in terms of either dollars man hours? And what type of competitive moats this provides you relative to the competition and for how long?

Thanks for that question. I can definitely address that. So this has been in R&D for a good I want to say, 12 to 18 months at least. So we launched this in June, and it was probably in development for a good 18 months prior to that. In terms of the competitive moat, Baha touched upon this a little bit. But we always get an asymmetric advantage whenever we add innovation to the platform. So as you're all aware, we have had a very strong platform when it comes to dealing with unstructured messy logs. And what we have done over here is we have extended that kind of a benefit to brand-new use case, where some of our customers had been using us in some capacity in the past, but this is the first time we have introduced a purpose-built solution right in the platform for the proliferation of metrics which is happening. So that's where we expect our sustainable advantage to be.

Our next question today comes from Howard Ma at Guggenheim Securities.

Great. Thanks. Can you help us bridge customer adoption of Elastic for metrics today to a future steady state? I believe about 2/3 of the business today is tied to logs either operational logs or SIM. How are you aggressively marketing metrics of that entire base? And on a related note, too, how do you think Elastic will be used alongside other metrics platforms? Will it be incremental to usage of other metrics platforms? Or more importantly, how do you ensure Elastic becomes a primary metrics engine versus the competition out there?

Definitely. It's a great question, Howard. So the way to think about our proliferation today in customers, so you did mention adoption in logs as well as on the SIM side in security. Where this offering plays is really on the first part, of course. So it's more towards SRE teams who have been using us as a centralized logging platform. If we look at that customer base today, most of them use a second and third tool for doing things like infrastructure monitoring, et cetera. and the, let's call it, the economic value of that may even far exceed the value that we are providing when it comes to log analytics. So that is what presents the opportunity for us to go after a part of what you mentioned, so the log analytics platform for SREs and then go to that customer base and attach metrics to it. So that's really the, let's call it, the shortest opportunity. Now to your second question on do we anticipate other tools as well? Practically speaking, these kind of adoptions are gradual. So in some sense. This is a newer product for us in terms of our purpose-built solution over here, which we launched only at the end of June. So practically speaking, we will see a gradual kind of adoption over there. And we do expect some coexistence with other tools in the short term. Our goal, of course, is to provide a consolidated solution for all of our customers' logs, metrics and traces.