WEBVTT 00:00:00.000 --> 00:00:02.980 Welcome back to the Deep Dive. This is the show 00:00:02.980 --> 00:00:05.799 we build for you, the learner, the person who 00:00:05.799 --> 00:00:09.859 needs that concise but critically deep analysis 00:00:09.859 --> 00:00:12.900 of the technologies really shaping our world. 00:00:13.000 --> 00:00:14.859 That's right. We take all the source material, 00:00:15.099 --> 00:00:17.600 the research, the data, and we just try to deliver 00:00:17.600 --> 00:00:19.379 the essential knowledge, you know, without all 00:00:19.379 --> 00:00:22.539 the noise. Our mission today is a deep dive into 00:00:22.539 --> 00:00:25.260 a company called Datadog Inc. And this dive, 00:00:25.379 --> 00:00:27.969 it's... really not just about understanding another 00:00:27.969 --> 00:00:30.850 successful tech company. It's about grasping 00:00:30.850 --> 00:00:33.049 a fundamental architectural shift that's happened 00:00:33.049 --> 00:00:35.670 over the last decade. A huge shift. A huge one. 00:00:35.789 --> 00:00:37.530 I mean, Datadog didn't just capitalize on the 00:00:37.530 --> 00:00:40.070 cloud. They basically built the indispensable 00:00:40.070 --> 00:00:42.329 rearview mirror and the dashboard for it. So 00:00:42.329 --> 00:00:44.670 for anyone who's working in or even just investing 00:00:44.670 --> 00:00:47.549 in modern digital infrastructure, understanding 00:00:47.549 --> 00:00:50.600 their stories. Well, it's critical. It's absolutely 00:00:50.600 --> 00:00:52.619 critical. We've stacked all our sources. And 00:00:52.619 --> 00:00:54.700 the story of Datadog is just a masterclass in 00:00:54.700 --> 00:00:56.899 operationalizing foresight. It really is. That's 00:00:56.899 --> 00:00:59.159 it. They identified this looming organizational 00:00:59.159 --> 00:01:02.460 and technical crisis that was created by cloud 00:01:02.460 --> 00:01:05.140 adoption. And they built the solution right at 00:01:05.140 --> 00:01:07.480 that intersection, that sweet spot between development 00:01:07.480 --> 00:01:12.260 speed and operational stability. Let's just define 00:01:12.260 --> 00:01:14.560 them immediately for you. Datadog is an American 00:01:14.560 --> 00:01:17.319 company, and they provide what's called an observability 00:01:17.319 --> 00:01:21.219 service for cloud -scale applications. Observability. 00:01:21.420 --> 00:01:22.959 We're going to be using that word a lot. A lot. 00:01:23.120 --> 00:01:25.939 And they deliver this as a sauce -based data 00:01:25.939 --> 00:01:28.219 analytics platform. You can think of it as a 00:01:28.219 --> 00:01:30.879 single unified brain that monitors every crucial 00:01:30.879 --> 00:01:33.400 component of a system. Everything. Your servers, 00:01:33.540 --> 00:01:35.719 your databases, your tools, and especially the 00:01:35.719 --> 00:01:38.959 incredibly complex distributed microservices 00:01:38.959 --> 00:01:43.120 that power modern enterprise apps. sense of the 00:01:43.120 --> 00:01:45.019 scale here, let's just start with the snapshot 00:01:45.019 --> 00:01:48.340 facts, the vitals. Datadog was founded way back 00:01:48.340 --> 00:01:52.439 in 2010 in New York City by Olivier Pommel and 00:01:52.439 --> 00:01:55.459 Alexis Likwak. They're publicly traded on NASDAQ, 00:01:55.540 --> 00:01:58.819 ticker is DDOG. DDOG. And the market has certainly 00:01:58.819 --> 00:02:01.019 ratified their importance. I mean, they're already 00:02:01.019 --> 00:02:03.500 a key component of the NASDAQ 100. Which is big. 00:02:03.700 --> 00:02:06.420 It is. But maybe the most significant indicator 00:02:06.420 --> 00:02:09.650 of their corporate maturity is this. They are 00:02:09.650 --> 00:02:11.830 scheduled to be included in the prestigious S 00:02:11.830 --> 00:02:16.969 &P 500 index in July of 2025. That S &P 500 inclusion, 00:02:17.090 --> 00:02:19.349 I mean, that is a massive statement. It's a statement 00:02:19.349 --> 00:02:21.389 of market relevance, of financial stability. 00:02:21.550 --> 00:02:24.310 It essentially moves them from being just another 00:02:24.310 --> 00:02:28.919 high growth tech stock to. An indispensable piece 00:02:28.919 --> 00:02:31.860 of the U .S. economy for big institutional investors. 00:02:32.219 --> 00:02:33.900 Yeah. You have to buy it. You have to. And the 00:02:33.900 --> 00:02:36.360 numbers, they absolutely back up that status. 00:02:36.439 --> 00:02:39.840 As of 2024, they reported very robust revenue 00:02:39.840 --> 00:02:44.460 of $2 .8 billion. Right. And they employ approximately 00:02:44.460 --> 00:02:47.099 6 ,500 people globally. So that just shows you 00:02:47.099 --> 00:02:49.719 the sustained rapid scale over their, what, 15 00:02:49.719 --> 00:02:51.879 -year history? Okay. Let's unpack this. Yeah. 00:02:51.939 --> 00:02:54.599 By first exploring the core operational friction 00:02:54.599 --> 00:02:56.900 that made this entire platform necessary in the 00:02:56.900 --> 00:02:59.099 first place. You know, the story of massive value 00:02:59.099 --> 00:03:01.879 creation in tech, it almost always starts with 00:03:01.879 --> 00:03:04.680 identifying some specific, really visceral pain 00:03:04.680 --> 00:03:07.449 point. A pain point that customers are willing 00:03:07.449 --> 00:03:11.169 to pay billions to solve. For Datadog, that was 00:03:11.169 --> 00:03:14.650 the friction between developer teams and systems 00:03:14.650 --> 00:03:17.069 administration teams. The classic divide. The 00:03:17.069 --> 00:03:19.909 classic divide. So can you take us back to 2010? 00:03:20.150 --> 00:03:23.229 Tell us about the origins and what the founders, 00:03:23.469 --> 00:03:26.129 Olivier Pommel and Alexis Le Quoc, were really 00:03:26.129 --> 00:03:29.050 aiming to fix. So the origins are really rooted 00:03:29.050 --> 00:03:33.050 in shared history. institutional experience. 00:03:33.469 --> 00:03:35.969 Yeah. Pommel and Le Quoc were already a highly 00:03:35.969 --> 00:03:38.110 cohesive unit. They knew each other well. Very 00:03:38.110 --> 00:03:40.770 well. They met as undergraduates at the esteemed 00:03:40.770 --> 00:03:44.110 École Centrale Paris. And crucially, they worked 00:03:44.110 --> 00:03:46.270 side by side for nine years at a company called 00:03:46.270 --> 00:03:48.590 Wireless Generation. Right. The education tech 00:03:48.590 --> 00:03:50.810 company. Exactly. A technology company focused 00:03:50.810 --> 00:03:53.169 on education solutions. So nine years together 00:03:53.169 --> 00:03:56.449 in the trenches dealing with really complex IT 00:03:56.449 --> 00:03:59.409 systems. That's... I mean, that's a deep level 00:03:59.409 --> 00:04:01.610 of shared understanding. It is a shared understanding 00:04:01.610 --> 00:04:04.849 of the technical complexity, but maybe more importantly, 00:04:05.009 --> 00:04:07.210 of the organizational dysfunction that comes 00:04:07.210 --> 00:04:09.610 with it. And the catalyst for Datadog came right 00:04:09.610 --> 00:04:11.569 after News Corp acquired wireless generation 00:04:11.569 --> 00:04:15.250 in 2010. They had witnessed firsthand, you know, 00:04:15.270 --> 00:04:18.110 across a decade, the systemic failure point in 00:04:18.110 --> 00:04:21.189 enterprise IT. And what was that? It was the 00:04:21.189 --> 00:04:23.730 fundamental disconnect between the groups responsible 00:04:23.730 --> 00:04:26.730 for building software development or dev and 00:04:26.730 --> 00:04:28.600 the groups responsible. for keeping that software 00:04:28.600 --> 00:04:31.600 running operations or ops. The sources we looked 00:04:31.600 --> 00:04:35.399 at describe these two teams as often working 00:04:35.399 --> 00:04:38.720 at cross purposes. For you, our listener, what 00:04:38.720 --> 00:04:41.100 did that actually look like on the ground? How 00:04:41.100 --> 00:04:43.360 did this, you know, this organizational friction 00:04:43.360 --> 00:04:47.040 manifest as a real technical and financial problem? 00:04:47.319 --> 00:04:49.779 It was a conflict of incentives, a conflict of 00:04:49.779 --> 00:04:51.800 metrics even. The dev team, they're measured 00:04:51.800 --> 00:04:54.420 on speed. Right. How fast can you ship? Features. 00:04:54.480 --> 00:04:56.420 Exactly. How fast can we push out new features 00:04:56.420 --> 00:04:58.819 and updates? But the ops team, they're measured 00:04:58.819 --> 00:05:01.519 on stability. How consistently can we maintain 00:05:01.519 --> 00:05:03.740 reliability, security, and uptime? So they're 00:05:03.740 --> 00:05:05.959 pulling in opposite directions. Completely. So 00:05:05.959 --> 00:05:08.339 in the pre -cloud era, when something failed, 00:05:08.399 --> 00:05:11.399 a database lagged, a server went down, the debugging 00:05:11.399 --> 00:05:13.579 process was just a nightmare of finger pointing. 00:05:13.779 --> 00:05:15.399 Because they were looking at completely different 00:05:15.399 --> 00:05:17.420 data sets, right? They had their own tools, their 00:05:17.420 --> 00:05:20.120 own dashboards. Exactly. They had no shared context. 00:05:20.279 --> 00:05:22.120 The developer would look at their application 00:05:22.120 --> 00:05:26.120 logs and say, The code is fine, must be the infrastructure. 00:05:26.560 --> 00:05:28.920 And the ops team. The ops team would look at 00:05:28.920 --> 00:05:31.420 their CPU utilization charts and say, the server 00:05:31.420 --> 00:05:33.740 is fine, the new feature update must be buggy. 00:05:34.199 --> 00:05:37.639 They lacked a single unified view of the system's 00:05:37.639 --> 00:05:40.899 health. It forced them into these siloed, almost 00:05:40.899 --> 00:05:44.120 tribal warfare situations. And all that time 00:05:44.120 --> 00:05:47.399 spent arguing is money down the drain. It's incredibly 00:05:47.399 --> 00:05:50.279 expensive. The time spent debugging and resolving 00:05:50.279 --> 00:05:53.060 incidents, what the industry calls mean time 00:05:53.060 --> 00:05:56.860 to resolution or MTTR, it was just agonizingly 00:05:56.860 --> 00:06:00.399 long. So Datadog's initial mandate was born directly 00:06:00.399 --> 00:06:02.879 from this organizational gap. Right. To create 00:06:02.879 --> 00:06:05.339 a cloud infrastructure monitoring service that 00:06:05.339 --> 00:06:07.660 could finally bridge that divide. Well, it wasn't 00:06:07.660 --> 00:06:09.620 just monitoring. It was about creating unified 00:06:09.620 --> 00:06:12.560 visibility. The early solution, it focused on 00:06:12.560 --> 00:06:14.579 collecting metrics from all across the stack. 00:06:14.660 --> 00:06:16.680 From everywhere. And presenting. them through 00:06:16.680 --> 00:06:19.500 clear dashboards, sophisticated alerting based 00:06:19.500 --> 00:06:22.560 on anomaly detection, and these unified visualizations. 00:06:22.879 --> 00:06:26.439 By providing a single source of truth, a dashboard 00:06:26.439 --> 00:06:29.319 both dev and ops could look at and agree on, 00:06:29.480 --> 00:06:32.399 they could immediately pivot from who is to blame 00:06:32.399 --> 00:06:35.639 to what is broken. That shift is everything. 00:06:36.000 --> 00:06:38.439 It is. And this foundational mission gave them 00:06:38.439 --> 00:06:41.290 just perfect market timing. As companies began 00:06:41.290 --> 00:06:43.709 migrating away from their stable monolithic servers 00:06:43.709 --> 00:06:45.910 and into the dynamic distributed environment 00:06:45.910 --> 00:06:48.810 of the public cloud, that friction must have 00:06:48.810 --> 00:06:51.329 just intensified tenfold. It absolutely did. 00:06:51.490 --> 00:06:52.910 I mean, cloud environments, they're characterized 00:06:52.910 --> 00:06:55.410 by ephemeral resources, constantly changing server 00:06:55.410 --> 00:06:58.350 IDs, containerization, auto -scaling. It's controlled 00:06:58.350 --> 00:07:01.069 chaos. And it makes traditional fixed monitoring 00:07:01.069 --> 00:07:03.790 tools completely irrelevant. The complexity of 00:07:03.790 --> 00:07:06.050 a distributed system where a single click from 00:07:06.050 --> 00:07:07.949 a user might touch 20 different microservices, 00:07:08.149 --> 00:07:11.149 it made that dev. DevOps disconnect, well, catastrophic. 00:07:11.529 --> 00:07:13.930 So Datadog was built for that world. From the 00:07:13.930 --> 00:07:17.069 ground up, built to handle this elastic cloud 00:07:17.069 --> 00:07:19.750 -first reality, which positioned them perfectly 00:07:19.750 --> 00:07:22.779 to be the indispensable control layer. That meant 00:07:22.779 --> 00:07:25.000 early integration with the emerging cloud giants 00:07:25.000 --> 00:07:27.480 was absolutely essential, right? They needed 00:07:27.480 --> 00:07:29.620 to be cloud agnostic to capture the enterprise 00:07:29.620 --> 00:07:31.779 market. And they were just relentless about it. 00:07:31.839 --> 00:07:34.100 They didn't limit themselves to one vendor, which 00:07:34.100 --> 00:07:37.540 was a very smart move. Their early strategy involved 00:07:37.540 --> 00:07:40.980 deep integration with all three major cloud providers, 00:07:41.220 --> 00:07:45.699 Amazon Web Services, AWS, Microsoft Azure, and 00:07:45.699 --> 00:07:48.370 Google Cloud Platform. But they didn't stop there. 00:07:48.589 --> 00:07:50.209 They went for the enterprise platforms, too. 00:07:50.350 --> 00:07:52.550 Right. They also integrated with things like 00:07:52.550 --> 00:07:56.269 Red Hat OpenShift, VMware, and OpenStack. This 00:07:56.269 --> 00:07:58.750 universality, it was a very deliberate choice 00:07:58.750 --> 00:08:00.790 to make sure they could service any enterprise, 00:08:01.089 --> 00:08:03.949 regardless of its hybrid or multi -cloud strategy. 00:08:04.410 --> 00:08:06.569 And that early confidence, that kind of strategic 00:08:06.569 --> 00:08:08.870 positioning, it must have required some serious 00:08:08.870 --> 00:08:10.730 capital, even back in those early years. Oh, 00:08:10.769 --> 00:08:13.240 for sure. They secured a successful seed round 00:08:13.240 --> 00:08:16.079 in 2010, which brought on initial backing from 00:08:16.079 --> 00:08:17.800 some crucial early investors. It was involved. 00:08:18.439 --> 00:08:21.480 Firms like NYCC, Contour Venture Partners, and 00:08:21.480 --> 00:08:25.040 IA Ventures. This capital, it validated the belief 00:08:25.040 --> 00:08:27.660 that the cloud complexity problem was solvable. 00:08:28.139 --> 00:08:30.959 And, more importantly, that the market was ready 00:08:30.959 --> 00:08:33.879 for a centralized visibility solution. So you 00:08:33.879 --> 00:08:36.220 can really trace their entire trajectory, their 00:08:36.220 --> 00:08:39.200 whole multi -billion dollar valuation, back to 00:08:39.200 --> 00:08:42.340 this one core insight. can. Unified metrics are 00:08:42.340 --> 00:08:45.299 the antidote to decentralization and organizational 00:08:45.299 --> 00:08:48.200 friction. That's the thesis. OK, so we've established 00:08:48.200 --> 00:08:51.240 the why, the organizational necessity. Now let's 00:08:51.240 --> 00:08:54.200 get into the what and the how. The market terminology, 00:08:54.539 --> 00:08:57.080 as we mentioned, it has evolved from just simple 00:08:57.080 --> 00:09:00.639 monitoring to comprehensive observability. What 00:09:00.639 --> 00:09:02.759 is the technical distinction there, and how does 00:09:02.759 --> 00:09:05.000 Datadog's product portfolio align with that modern 00:09:05.000 --> 00:09:07.220 concept? The shift is massive, and it's really 00:09:07.220 --> 00:09:09.059 critical for you, the learner, to understand 00:09:09.059 --> 00:09:11.539 this difference. Monitoring traditionally involves 00:09:11.539 --> 00:09:13.620 checking known variables and metrics. Like, is 00:09:13.620 --> 00:09:16.600 the CPU over 80 %? Exactly. Is the queue depth 00:09:16.600 --> 00:09:19.659 exceeding X? Is the server CPU spiking above 00:09:19.659 --> 00:09:22.500 Y? If you don't already know what question to 00:09:22.500 --> 00:09:25.179 ask, monitoring often fails you okay so what's 00:09:25.179 --> 00:09:28.639 observability observability by contrast is the 00:09:28.639 --> 00:09:31.320 ability to understand the internal state of a 00:09:31.320 --> 00:09:34.100 complex system just by looking at its external 00:09:34.100 --> 00:09:36.940 outputs it's the ability to ask any arbitrary 00:09:36.940 --> 00:09:39.460 question about your system's performance even 00:09:39.460 --> 00:09:42.200 questions you didn't anticipate and you do that 00:09:42.200 --> 00:09:45.240 using three core pillars of data and those three 00:09:45.240 --> 00:09:48.129 pillars Metrics, logs, and traces. That's what 00:09:48.129 --> 00:09:50.529 Datadog has engineered its entire platform around. 00:09:50.769 --> 00:09:54.690 Absolutely. Metrics are your numerical time series 00:09:54.690 --> 00:09:57.740 data. Think CPU usage, request counts, error 00:09:57.740 --> 00:09:59.659 rates. They tell you that something is wrong. 00:09:59.840 --> 00:10:02.399 The what. The what. Then you have logs. These 00:10:02.399 --> 00:10:04.940 are discrete textual event data messages generated 00:10:04.940 --> 00:10:07.200 by code, system events, transaction details. 00:10:07.460 --> 00:10:09.700 They tell you the context of what happened. The 00:10:09.700 --> 00:10:11.960 why. The why, exactly. And finally, you have 00:10:11.960 --> 00:10:14.320 traces. These are records of the end -to -end 00:10:14.320 --> 00:10:16.639 user path, showing how a single request travels 00:10:16.639 --> 00:10:19.259 across dozens of different microservices. They 00:10:19.259 --> 00:10:21.620 tell you the flow and where a bottleneck or latency 00:10:21.620 --> 00:10:24.539 was introduced. So Datadog's core product is 00:10:24.539 --> 00:10:26.200 the user. unified platform that connects all 00:10:26.200 --> 00:10:28.740 three of those data types into one single cohesive 00:10:28.740 --> 00:10:31.580 narrative. That's the magic. Okay, so if they're 00:10:31.580 --> 00:10:35.059 providing this comprehensive observability, what 00:10:35.059 --> 00:10:37.799 are the primary product categories that engineering 00:10:37.799 --> 00:10:40.679 teams are actually buying from them? The portfolio, 00:10:40.779 --> 00:10:43.820 it really covers the entire application and infrastructure 00:10:43.820 --> 00:10:47.100 lifecycle. The foundation is still infrastructure 00:10:47.100 --> 00:10:49.559 monitoring, you know, tracking the basic health 00:10:49.559 --> 00:10:52.519 of containers, servers, cloud resources. The 00:10:52.519 --> 00:10:54.980 bread and butter. The bread and butter. But their 00:10:54.980 --> 00:10:58.080 growth required expanding vertically. So they 00:10:58.080 --> 00:11:00.940 offer network performance monitoring and network 00:11:00.940 --> 00:11:03.799 device monitoring. This is essential because 00:11:03.799 --> 00:11:06.980 in distributed systems, the network latency between 00:11:06.980 --> 00:11:09.519 all those little microservices often accounts 00:11:09.519 --> 00:11:11.759 for the vast majority of performance degradation. 00:11:11.960 --> 00:11:14.360 Right. It's not the code. It's the wire between 00:11:14.360 --> 00:11:17.259 the services. Often, yes. And their expansion 00:11:17.259 --> 00:11:19.679 seems to have perfectly mirrored the big technology 00:11:19.679 --> 00:11:23.059 shifts happening in the cloud. Exactly. As organizations 00:11:23.059 --> 00:11:25.700 adopted serverless architectures, where code 00:11:25.700 --> 00:11:27.580 runs in these ephemeral functions that might 00:11:27.580 --> 00:11:30.759 exist for just milliseconds, they needed serverless 00:11:30.759 --> 00:11:33.120 monitoring. Because traditional agent -based 00:11:33.120 --> 00:11:35.899 monitoring wouldn't work there. It fails completely. 00:11:36.120 --> 00:11:38.700 The function is gone before the agent can even 00:11:38.700 --> 00:11:42.019 report back. So Datadog adapted, providing visibility 00:11:42.019 --> 00:11:45.559 into transient workloads like AWS Lambda, allowing 00:11:45.559 --> 00:11:48.299 customers to track execution time, cold starts, 00:11:48.519 --> 00:11:50.840 things like that. And critically, they also moved 00:11:50.840 --> 00:11:53.450 into cost control. Yes, with cloud cost management, 00:11:53.789 --> 00:11:56.990 this was a brilliant move. You simply can't separate 00:11:56.990 --> 00:11:59.289 performance from financial expenditure in the 00:11:59.289 --> 00:12:02.269 cloud. Tracking your resource usage meticulously 00:12:02.269 --> 00:12:05.129 right alongside your technical performance, it's 00:12:05.129 --> 00:12:07.269 mandatory for maintaining cost effectiveness 00:12:07.269 --> 00:12:09.850 and avoiding those, you know, shocking monthly 00:12:09.850 --> 00:12:12.389 bills. Okay, that's what they sell. Now for the 00:12:12.389 --> 00:12:16.039 engine room, the how. DataDog has to ingest, 00:12:16.120 --> 00:12:19.159 analyze, and visualize just petabytes of data 00:12:19.159 --> 00:12:21.840 from thousands of customers in real time. What's 00:12:21.840 --> 00:12:23.720 the technical architecture that enables that 00:12:23.720 --> 00:12:25.879 kind of scale? The architecture is really defined 00:12:25.879 --> 00:12:28.899 by two key parts, the agent and the backend stack. 00:12:29.080 --> 00:12:31.080 The agent is the lightweight piece of software 00:12:31.080 --> 00:12:33.279 that lives on the client's infrastructure. So 00:12:33.279 --> 00:12:35.580 you install this on your servers? Correct. It 00:12:35.580 --> 00:12:37.440 pulls for metrics, it collects logs, it gathers 00:12:37.440 --> 00:12:39.860 traces, it acts as the local data collector and 00:12:39.860 --> 00:12:41.860 transmission unit. And there's an interesting 00:12:41.860 --> 00:12:44.220 history to the agent itself, isn't there? There 00:12:44.220 --> 00:12:46.860 is. It was originally Python -based. It was actually 00:12:46.860 --> 00:12:49.399 derived from a fork of the agent used by a company 00:12:49.399 --> 00:12:52.399 called Server Density back in 2009. And Python 00:12:52.399 --> 00:12:54.559 is great for quick development. But when you're 00:12:54.559 --> 00:12:57.200 dealing with massive scale and you need really 00:12:57.200 --> 00:13:00.259 low memory overhead and high efficiency across 00:13:00.259 --> 00:13:03.220 thousands and thousands of machines, constraints 00:13:03.220 --> 00:13:05.820 start to appear. It's just not built for that 00:13:05.820 --> 00:13:07.960 kind of hyper -efficient performance. Which is 00:13:07.960 --> 00:13:10.500 why the massive rewriting effort in 2018 was 00:13:10.500 --> 00:13:13.720 so incredibly significant. Yes. For their major 00:13:13.720 --> 00:13:17.919 version 6 .0 .0, released in February 2018, the 00:13:17.919 --> 00:13:21.379 Datadog agent was rewritten entirely in Go. Go 00:13:21.379 --> 00:13:24.230 or Golang. Right. And this is a really crucial 00:13:24.230 --> 00:13:27.830 detail for you, the learner. Go excels at high 00:13:27.830 --> 00:13:30.309 performance concurrent processing, which makes 00:13:30.309 --> 00:13:33.210 it absolutely ideal for the agent. It has a tiny 00:13:33.210 --> 00:13:35.490 memory footprint and it compiles into a single 00:13:35.490 --> 00:13:38.470 binary. That means it's fast to deploy and it 00:13:38.470 --> 00:13:40.850 runs with minimal impact on the monitored application 00:13:40.850 --> 00:13:42.730 itself. So it's not slowing down with the thing 00:13:42.730 --> 00:13:45.490 it's supposed to be watching. Exactly. This transition 00:13:45.490 --> 00:13:48.129 to Go allowed Datadog to significantly increase 00:13:48.129 --> 00:13:50.309 the volume and the frequency of data collection 00:13:50.309 --> 00:13:52.909 without burdening the customer's own resources. 00:13:53.490 --> 00:13:56.370 Okay, so the efficient Go agent gathers the data. 00:13:56.409 --> 00:13:58.730 Now let's talk about that massive analytical 00:13:58.730 --> 00:14:01.669 engine that has to process this incoming torrent 00:14:01.669 --> 00:14:05.070 of metrics, logs, and traces. What's powering 00:14:05.070 --> 00:14:08.539 the backend stack? The backend stack uses a powerful 00:14:08.539 --> 00:14:11.639 mixed architecture. It leverages the best of 00:14:11.639 --> 00:14:14.700 both open and closed source technology. When 00:14:14.700 --> 00:14:16.720 you're dealing with time series data metrics 00:14:16.720 --> 00:14:19.320 arriving every single second, you need specialized 00:14:19.320 --> 00:14:21.960 systems built for high velocity ingestion and 00:14:21.960 --> 00:14:23.659 retrieval. Right. And that's where components 00:14:23.659 --> 00:14:26.120 like Apache Cassandra and Kafka come into play. 00:14:26.259 --> 00:14:28.200 Let's elaborate on those two because they really 00:14:28.200 --> 00:14:31.379 define cloud scale data processing. Why Kafka? 00:14:31.460 --> 00:14:34.480 Why Cassandra? So Kafka is the circulatory system. 00:14:34.659 --> 00:14:36.980 It's a distributed event streaming platform, 00:14:37.220 --> 00:14:39.340 and it's used to handle the extreme velocity 00:14:39.340 --> 00:14:41.539 of incoming data. It's like a shock absorber 00:14:41.539 --> 00:14:43.480 for the data firehose. That's a great way to 00:14:43.480 --> 00:14:46.399 put it. Metrics and logs arrive constantly, and 00:14:46.399 --> 00:14:48.340 Kafka ensures that none of these data points 00:14:48.340 --> 00:14:51.519 are lost. It acts as a highly durable sequential 00:14:51.519 --> 00:14:54.399 buffer. This is essential for time series data, 00:14:54.500 --> 00:14:56.480 which is meaningless if the events are out of 00:14:56.480 --> 00:14:59.460 order or, worse, just dropped. And Cassandra 00:14:59.460 --> 00:15:02.240 for the story. aspect. Yes. Apache Cassandra 00:15:02.240 --> 00:15:05.159 is a highly scalable distributed NoSQL database. 00:15:05.580 --> 00:15:08.500 It's perfect for the sheer volume of data, especially 00:15:08.500 --> 00:15:11.379 logs and metrics, because it handles writes and 00:15:11.379 --> 00:15:14.559 eventual consistency extremely well across multiple 00:15:14.559 --> 00:15:17.480 data centers. So it can grow as big as they need 00:15:17.480 --> 00:15:19.759 it to. Infinitely, for all practical purposes. 00:15:20.080 --> 00:15:23.159 It allows Datadog to store trillions of timestamped 00:15:23.159 --> 00:15:25.600 events and retrieve them with very low latency 00:15:25.600 --> 00:15:28.519 for visualization, which is critical when an 00:15:28.519 --> 00:15:30.879 engineer is in the middle of the firefight, debugging 00:15:30.879 --> 00:15:33.100 an ongoing outage. And they use other things 00:15:33.100 --> 00:15:35.820 too, right? Oh, sure. They also use PostgreSQL 00:15:35.820 --> 00:15:38.720 for more structured data and things like D3 for 00:15:38.720 --> 00:15:40.940 generating those rich interactive dashboards 00:15:40.940 --> 00:15:42.940 that the users rely on. Here's where it gets 00:15:42.940 --> 00:15:45.759 really interesting. Because all this sophisticated 00:15:45.759 --> 00:15:49.299 backend tech is basically useless if they can't 00:15:49.299 --> 00:15:52.059 connect to the user's entire environment. Their 00:15:52.059 --> 00:15:55.100 competitive advantage, their moat, is arguably 00:15:55.100 --> 00:15:57.779 the breadth of their integration ecosystem. That 00:15:57.779 --> 00:15:59.539 is their definitive competitive moat, and the 00:15:59.539 --> 00:16:02.580 scale of it is just staggering. As of October 00:16:02.580 --> 00:16:06.500 2024, the company supports over 750 integrations. 00:16:06.559 --> 00:16:09.659 750. Just think about that number. A modern enterprise 00:16:09.659 --> 00:16:12.740 tech stack isn't just AWS and a database. It 00:16:12.740 --> 00:16:15.899 involves dozens of niche tools, specific caches 00:16:15.899 --> 00:16:19.220 like Redis or Memcached, various container orchestrators 00:16:19.220 --> 00:16:21.580 like Kubernetes, esoteric security scanners, 00:16:21.720 --> 00:16:24.320 queuing systems like RabbitMQ. The list goes 00:16:24.320 --> 00:16:26.620 on and on. So for a potential customer who's 00:16:26.620 --> 00:16:29.340 evaluating Datadog versus a competitor, the number 00:16:29.340 --> 00:16:32.139 of integrations, it massively reduces the cost 00:16:32.139 --> 00:16:34.960 and complexity of adoption. Absolutely. It dramatically 00:16:34.960 --> 00:16:37.379 lowers the switching cost. If you're an enterprise 00:16:37.379 --> 00:16:39.840 with a highly customized tech stack, you do not 00:16:39.840 --> 00:16:41.720 want to assign an engineering team to write custom 00:16:41.720 --> 00:16:43.600 collection code for every single component. It 00:16:43.600 --> 00:16:47.090 would take years. It would. With Datadog, the 00:16:47.090 --> 00:16:49.750 integration for your specific MongoDB version 00:16:49.750 --> 00:16:53.129 or your custom web server is likely already written, 00:16:53.289 --> 00:16:56.590 tested, and maintained by Datadog. This breast 00:16:56.590 --> 00:16:59.389 of connectivity, it turns Datadog into the universal 00:16:59.389 --> 00:17:02.289 data translator for infrastructure health. And 00:17:02.289 --> 00:17:04.930 it just solidifies their position as the de facto 00:17:04.930 --> 00:17:07.369 observability standard. The technology explains 00:17:07.369 --> 00:17:10.589 the utility, but the massive growth, that explains 00:17:10.589 --> 00:17:13.769 the valuation. This company, it wasn't content 00:17:13.769 --> 00:17:16.009 to just dominate New York. They were aiming for 00:17:16.009 --> 00:17:18.710 global scale almost from the get go. Oh, yeah. 00:17:18.890 --> 00:17:20.589 So let's look the physical and the financial 00:17:20.589 --> 00:17:22.890 scaling velocity. The physical scaling gives 00:17:22.890 --> 00:17:24.970 you immediate evidence of their commitment to 00:17:24.970 --> 00:17:27.390 growth. They recognized that a global market 00:17:27.390 --> 00:17:29.990 presence required global talent. So they established 00:17:29.990 --> 00:17:32.230 a dedicated research and development office in 00:17:32.230 --> 00:17:35.309 Paris in 2015. Tapping into that European engineering 00:17:35.309 --> 00:17:37.829 expertise. Exactly. And back in New York, the 00:17:37.829 --> 00:17:39.990 demand for physical space quickly became a symbol 00:17:39.990 --> 00:17:42.089 of their rapid ascension within the city's tech 00:17:42.089 --> 00:17:45.069 ecosystem. Right. In 2016, they moved their New 00:17:45.069 --> 00:17:48.109 York City headquarters into a full floor of the 00:17:48.109 --> 00:17:50.630 iconic New York Times building. A move that really 00:17:50.630 --> 00:17:53.490 symbolized their graduation from a startup. to 00:17:53.490 --> 00:17:56.710 a major enterprise fixture. And crucially, they 00:17:56.710 --> 00:17:58.930 needed that space because the team literally 00:17:58.930 --> 00:18:01.650 doubled over the course of that one single year. 00:18:01.789 --> 00:18:04.990 Wow. And by 2024, the headcount explosion had 00:18:04.990 --> 00:18:08.230 stabilized at around 6 ,500 employees, which 00:18:08.230 --> 00:18:10.750 reflects the massive operational support required 00:18:10.750 --> 00:18:15.710 for a $2 .68 billion revenue business. And their 00:18:15.710 --> 00:18:17.650 global footprint reflects that enterprise client 00:18:17.650 --> 00:18:19.910 base. I mean, offices spanning North America, 00:18:20.069 --> 00:18:23.529 Europe, Paris, Dublin, Amsterdam. and the APAC 00:18:23.529 --> 00:18:27.470 region with Japan, Australia, Singapore. They're 00:18:27.470 --> 00:18:29.490 building a follow the sun operation to serve 00:18:29.490 --> 00:18:32.190 global enterprises. And this massive expansion 00:18:32.190 --> 00:18:35.069 was fueled by a rapid sequence of increasingly 00:18:35.069 --> 00:18:37.750 larger funding rounds, each one marking a new 00:18:37.750 --> 00:18:41.190 stage of validation and scaling ambition. Let's 00:18:41.190 --> 00:18:43.029 just recount those financial milestones leading 00:18:43.029 --> 00:18:45.150 up to the IPO. The initial validation came pretty 00:18:45.150 --> 00:18:47.069 early. Following that seed round we mentioned, 00:18:47.230 --> 00:18:50.230 they secured a substantial $6 .2 million Series 00:18:50.230 --> 00:18:53.630 A in 2012. It was co -led by Index Ventures and 00:18:53.630 --> 00:18:56.450 RTP Ventures. This really validated their initial 00:18:56.450 --> 00:18:59.079 product market fit. Then by 2014, the product 00:18:59.079 --> 00:19:02.400 was clearly resonating. That led to a $15 million 00:19:02.400 --> 00:19:06.279 Series B led by Openview Venture Partners. That 00:19:06.279 --> 00:19:08.279 money was likely deployed to accelerate their 00:19:08.279 --> 00:19:10.099 sales and marketing infrastructure. And then 00:19:10.099 --> 00:19:12.880 we see this shift into hyperscale funding, which 00:19:12.880 --> 00:19:15.640 is what's necessary to fund global R &D and really 00:19:15.640 --> 00:19:18.220 go for market dominance. The acceleration is 00:19:18.220 --> 00:19:21.430 just evident. $31 million for a Series C in 2015, 00:19:21.730 --> 00:19:23.910 again with index ventures participating heavily. 00:19:24.349 --> 00:19:29.269 Then the pivotal $94 .5 million Series D in 2016, 00:19:29.509 --> 00:19:32.990 led by IconiQ Capital. And that was a huge round 00:19:32.990 --> 00:19:35.150 for New York at the time. It was noteworthy. 00:19:35.150 --> 00:19:37.609 One of the largest funding events in the New 00:19:37.609 --> 00:19:40.170 York City tech scene that year. This capital 00:19:40.170 --> 00:19:42.910 infusion, it signaled that Datadog was no longer 00:19:42.910 --> 00:19:45.410 just scaling up. It was preparing for a massive, 00:19:45.470 --> 00:19:48.509 potentially global public market entry. that 00:19:48.509 --> 00:19:51.349 strategic funding led to this high stakes, almost 00:19:51.349 --> 00:19:54.109 cinematic moment that perfectly encapsulated 00:19:54.109 --> 00:19:56.150 the founder's conviction in their market opportunity. 00:19:56.490 --> 00:19:58.970 This is maybe the most telling anecdote about 00:19:58.970 --> 00:20:02.150 Datadog's belief in its own future. So prior 00:20:02.150 --> 00:20:05.950 to their IPO in September 2019, the company was 00:20:05.950 --> 00:20:08.349 the subject of a massive acquisition attempt 00:20:08.349 --> 00:20:12.309 by Cisco, who offered over seven billion dollars 00:20:12.309 --> 00:20:19.039 to buy Datadog outright. Seven billion. Offered 00:20:19.039 --> 00:20:21.299 by a networking and infrastructure titan like 00:20:21.299 --> 00:20:23.539 Cisco? I mean, that would have provided immediate 00:20:23.539 --> 00:20:26.420 liquidity and reduced risk for every single investor 00:20:26.420 --> 00:20:28.420 and founder. Everybody would have been very rich. 00:20:28.579 --> 00:20:31.579 And yet, they rejected it. What does that decision 00:20:31.579 --> 00:20:34.279 tell you about... their internal assessment of 00:20:34.279 --> 00:20:36.299 the observability market. I mean, it just speaks 00:20:36.299 --> 00:20:39.279 volumes about the exponential growth they foresaw. 00:20:39.480 --> 00:20:41.440 They were essentially betting that the total 00:20:41.440 --> 00:20:43.960 addressable market, the TAM for Unified Cloud 00:20:43.960 --> 00:20:46.660 Observability, was so massive and their market 00:20:46.660 --> 00:20:49.119 share position so dominant that going public 00:20:49.119 --> 00:20:51.319 and maintaining independent control would yield 00:20:51.319 --> 00:20:53.920 a valuation significantly higher than $7 billion 00:20:53.920 --> 00:20:56.339 in the very near term. It was a calculated risk. 00:20:56.480 --> 00:20:58.880 A huge one, based on supreme confidence in the 00:20:58.880 --> 00:21:00.940 durability of the cloud adoption curve. And the 00:21:00.940 --> 00:21:04.509 market. It validated that belief almost instantly. 00:21:05.809 --> 00:21:08.930 Let's look at the IPO. The public debut on Nasdaq 00:21:08.930 --> 00:21:12.210 September 19th, 2019. It was a blockbuster event. 00:21:12.430 --> 00:21:16.309 They raised $648 million by selling 24 million 00:21:16.309 --> 00:21:20.049 shares, which valued the company at $8 .7 billion 00:21:20.049 --> 00:21:23.109 at the initial offering price. So already way 00:21:23.109 --> 00:21:25.269 over the Cisco offer. Before the market even 00:21:25.269 --> 00:21:28.460 opened. And crucially, the public investors shared 00:21:28.460 --> 00:21:31.500 the founders' confidence. The stock price surged 00:21:31.500 --> 00:21:34.880 by approximately 37 % on the first day of trading. 00:21:35.019 --> 00:21:37.259 Incredible. Catapulting the market capitalization 00:21:37.259 --> 00:21:40.980 to nearly $10 billion by market close. The rejection 00:21:40.980 --> 00:21:43.880 of the $7 billion offer was proven shrewd within 00:21:43.880 --> 00:21:46.319 hours. So their independent trajectory was deemed 00:21:46.319 --> 00:21:48.359 to be worth 30 % more than the acquisition offer 00:21:48.359 --> 00:21:50.160 before the first full day of trading was even 00:21:50.160 --> 00:21:54.500 complete. That level of conviction is just, it's 00:21:54.500 --> 00:21:57.329 rare. It is, and their subsequent performance 00:21:57.329 --> 00:21:59.490 has really solidified their transition from a 00:21:59.490 --> 00:22:02.109 high growth disruptor to an industry staple. 00:22:02.970 --> 00:22:05.829 Being selected for the S &P 500, which is slated 00:22:05.829 --> 00:22:09.190 for July 2025, That's not just a badge of honor. 00:22:09.329 --> 00:22:11.670 It has really practical implications. How so? 00:22:11.890 --> 00:22:14.670 Well, many passive index funds and institutional 00:22:14.670 --> 00:22:18.130 portfolios, they track the S &P 500. It means 00:22:18.130 --> 00:22:20.450 that Datadog stock becomes a mandatory holding 00:22:20.450 --> 00:22:22.650 for a huge segment of the investment community, 00:22:22.789 --> 00:22:25.369 which guarantees demand and further stability. 00:22:25.809 --> 00:22:28.410 It's the ultimate recognition of maturity, size, 00:22:28.549 --> 00:22:30.970 and financial health. So let's review that financial 00:22:30.970 --> 00:22:33.450 health using the latest available data. What 00:22:33.450 --> 00:22:35.210 are the metrics that support this kind of prestige? 00:22:35.869 --> 00:22:38.710 The 2024 figures, they confirm continuous operational 00:22:38.710 --> 00:22:42.150 strength. Revenue reached $2 .68 billion. And 00:22:42.150 --> 00:22:44.109 while they continue to invest very heavily in 00:22:44.109 --> 00:22:46.849 R &D and acquisitions, they still maintain profitability. 00:22:47.470 --> 00:22:49.890 Operating income is reported at $54 million in 00:22:49.890 --> 00:22:52.509 2024. And if you look back at the previous year, 00:22:52.690 --> 00:22:55.569 they had a significant net income of $184 million 00:22:55.569 --> 00:22:59.029 in 2023. And the balance sheet, I assume, reflects 00:22:59.029 --> 00:23:02.460 a stable, massive operation. It does. Total assets 00:23:02.460 --> 00:23:06.779 are reported at $5 .79 billion, which significantly 00:23:06.779 --> 00:23:09.200 outweighs their liabilities, and their total 00:23:09.200 --> 00:23:13.240 equity is at $2 .71 billion. These are the metrics 00:23:13.240 --> 00:23:16.140 of a mature, well -capitalized enterprise that 00:23:16.140 --> 00:23:18.859 is successfully navigating that transition from 00:23:18.859 --> 00:23:21.259 rapid scale -up to sustained growth and profitability. 00:23:21.680 --> 00:23:23.920 That level of financial discipline is impressive, 00:23:24.140 --> 00:23:26.880 but given their massive acquisition pace, which 00:23:26.880 --> 00:23:29.940 we are about to dive into… How are they managing 00:23:29.940 --> 00:23:31.819 the internal integration of so many different 00:23:31.819 --> 00:23:34.480 corporate cultures and technology stacks? Because 00:23:34.480 --> 00:23:36.559 that is often a major pitfall in tech growth. 00:23:36.740 --> 00:23:39.480 Is there any evidence of friction there? That 00:23:39.480 --> 00:23:41.180 is the critical question, and you're right to 00:23:41.180 --> 00:23:43.640 ask it. The high frequency of M &A inherently 00:23:43.640 --> 00:23:46.359 carries integration risk, both technically and 00:23:46.359 --> 00:23:49.140 culturally. The key strategy Datadog appears 00:23:49.140 --> 00:23:51.740 to employ is focusing on acquisitions that are 00:23:51.740 --> 00:23:54.460 either, one, highly specialized niche solutions 00:23:54.460 --> 00:23:56.420 that can be quickly integrated into their Go 00:23:56.420 --> 00:23:59.240 -based agent and Kafka backend. Things like Logmatic 00:23:59.240 --> 00:24:03.480 or Auscode. Exactly. Or two, tools focused on 00:24:03.480 --> 00:24:05.910 workflow and collaboration like... CoScreen, 00:24:05.990 --> 00:24:08.269 that just improved the core product's stickiness. 00:24:08.589 --> 00:24:11.049 Their continued financial success suggests they 00:24:11.049 --> 00:24:12.970 have been largely effective at swallowing these 00:24:12.970 --> 00:24:15.009 new technologies without internal rejection. 00:24:15.450 --> 00:24:18.250 They seem to be focusing on unifying the data 00:24:18.250 --> 00:24:20.849 and the user experience above all else. They 00:24:20.849 --> 00:24:23.190 are acquiring pieces of the DevOps workflow, 00:24:23.509 --> 00:24:26.289 not competing platforms. That strategic focus 00:24:26.289 --> 00:24:29.250 on integration is the perfect segue. We've established 00:24:29.250 --> 00:24:31.990 that Datadog solved that initial monitoring problem. 00:24:32.230 --> 00:24:35.029 But to become an observability powerhouse, they 00:24:35.029 --> 00:24:37.609 realized they needed to control the entire workflow, 00:24:37.789 --> 00:24:40.269 from code analysis and security all the way to 00:24:40.269 --> 00:24:42.910 A -B testing and business impact. And they achieved 00:24:42.910 --> 00:24:44.950 this by systematically acquiring specialized 00:24:44.950 --> 00:24:47.730 technology. This acquisition timeline, it's not 00:24:47.730 --> 00:24:49.690 just a list of purchases. You should really see 00:24:49.690 --> 00:24:52.309 it as a blueprint for market consolidation. It 00:24:52.309 --> 00:24:54.569 shows Datadog's calculated, very disciplined 00:24:54.569 --> 00:24:57.529 move to achieve true full -stack monitoring and 00:24:57.529 --> 00:25:00.029 unified data across every single technical function. 00:25:00.289 --> 00:25:02.730 So let's start with the immediate need they had 00:25:02.730 --> 00:25:05.619 post -initial growth. bridging that gap between 00:25:05.619 --> 00:25:08.720 the time series metrics and the logs. The early 00:25:08.720 --> 00:25:11.220 focus was all about maximizing data utility. 00:25:11.599 --> 00:25:14.259 So in February 2015, they acquired a company 00:25:14.259 --> 00:25:17.299 called Mortar Data. This was key because it moved 00:25:17.299 --> 00:25:20.440 them beyond just raw metric visualization and 00:25:20.440 --> 00:25:23.480 into advanced analytics. It allowed users to 00:25:23.480 --> 00:25:26.079 perform deeper statistical analysis on their 00:25:26.079 --> 00:25:28.420 performance data. Laying the foundation. It laid 00:25:28.420 --> 00:25:30.180 the foundation for sophisticated correlation 00:25:30.180 --> 00:25:32.519 analysis. And then came the critical need for 00:25:32.519 --> 00:25:34.920 logging, which was really driven by the shift 00:25:34.920 --> 00:25:37.380 toward microservices. Yeah, that gap was filled 00:25:37.380 --> 00:25:40.480 in September 2017 with the acquisition of Logmatic. 00:25:41.169 --> 00:25:43.609 Previously, metrics and logs lived in totally 00:25:43.609 --> 00:25:46.069 separate silos, often managed by different teams 00:25:46.069 --> 00:25:48.970 using different tools. The rise of microservices 00:25:48.970 --> 00:25:51.089 meant application events and troubleshooting 00:25:51.089 --> 00:25:53.470 contexts were just exploding in volume, which 00:25:53.470 --> 00:25:56.230 required centralized log management. Logmatic 00:25:56.230 --> 00:25:59.130 provided a robust platform agnostic service for 00:25:59.130 --> 00:26:02.250 querying and visualizing logs, allowing an engineer 00:26:02.250 --> 00:26:05.230 to correlate a CPU spike, which is metric data. 00:26:05.690 --> 00:26:08.150 With the exact error message that caused it, 00:26:08.210 --> 00:26:11.250 which is the log data. Exactly. A huge step toward 00:26:11.250 --> 00:26:14.630 true unified observability. Okay. So the next 00:26:14.630 --> 00:26:17.970 phase, starting around 2019, shows Datadog recognizing 00:26:17.970 --> 00:26:20.990 that they needed to shift left to get visibility 00:26:20.990 --> 00:26:23.529 and control earlier in the development lifecycle. 00:26:24.140 --> 00:26:26.019 Moving into application testing and security. 00:26:26.359 --> 00:26:28.660 Exactly. They wanted to prevent problems before 00:26:28.660 --> 00:26:31.440 they were ever deployed. February 2019 brought 00:26:31.440 --> 00:26:34.420 the acquisition of Modumbo, an AI -based application 00:26:34.420 --> 00:26:36.900 testing platform. This was a proactive move. 00:26:37.220 --> 00:26:39.759 Instead of just monitoring failure, they could 00:26:39.759 --> 00:26:42.220 use AI to test new features against performance 00:26:42.220 --> 00:26:44.420 baselines before they went live. So integrating 00:26:44.420 --> 00:26:46.720 observability directly into the testing phase. 00:26:46.980 --> 00:26:48.900 Right. And the focus on the developer workflow 00:26:48.900 --> 00:26:51.440 continued, especially around how code moves into 00:26:51.440 --> 00:26:53.059 production. That's where Undefined Labs came 00:26:53.059 --> 00:26:56.309 in. In August 2020, they acquired Undefined Labs. 00:26:56.670 --> 00:26:59.650 This specifically focused on testing and observability 00:26:59.650 --> 00:27:02.430 for the CI -CD pipeline, the developer workflows. 00:27:02.730 --> 00:27:05.150 It deepened their ability to track code changes, 00:27:05.470 --> 00:27:08.049 testing results, and deployment health, ensuring 00:27:08.049 --> 00:27:10.710 that observability data wasn't just infrastructure 00:27:10.710 --> 00:27:13.369 -centric, but deeply connected to the actual 00:27:13.369 --> 00:27:15.849 code being deployed. And then came the heavy 00:27:15.849 --> 00:27:18.690 strategic investment in security, recognizing 00:27:18.690 --> 00:27:21.430 that security visibility is just another form 00:27:21.430 --> 00:27:23.910 of operational data. That was a huge insight. 00:27:24.130 --> 00:27:26.369 Security is no longer a perimeter defense. It 00:27:26.369 --> 00:27:29.009 lives inside the application code itself. So 00:27:29.009 --> 00:27:32.369 in February 2021, they acquired Screen, a robust 00:27:32.369 --> 00:27:35.269 application security platform. This was a massive 00:27:35.269 --> 00:27:37.630 move. A massive move. It immediately bundled 00:27:37.630 --> 00:27:40.890 advanced security monitoring like RASP or runtime 00:27:40.890 --> 00:27:43.630 application self -protection into the Datadog 00:27:43.630 --> 00:27:46.329 platform. It meant customers no longer needed 00:27:46.329 --> 00:27:48.609 a separate security dashboard. Vulnerability 00:27:48.609 --> 00:27:50.930 data, threat detection, performance metrics, 00:27:51.069 --> 00:27:52.599 they could all be viewed together. which really 00:27:52.599 --> 00:27:54.900 streamlined security operations. And following 00:27:54.900 --> 00:27:57.279 up on that application visibility, they doubled 00:27:57.279 --> 00:27:59.799 down on debugging solutions. Yeah. In November 00:27:59.799 --> 00:28:03.039 2021, they acquired Auscode. This focused on 00:28:03.039 --> 00:28:05.400 solving the immediate problem of failure in production. 00:28:06.019 --> 00:28:08.779 Auscode provided a live debugging solution with 00:28:08.779 --> 00:28:11.380 code level visibility. So an alert could fire 00:28:11.380 --> 00:28:13.720 and the engineer could immediately see the exact 00:28:13.720 --> 00:28:16.099 variables and the stack trace at the moment of 00:28:16.099 --> 00:28:18.180 failure without needing to reproduce the bug 00:28:18.180 --> 00:28:20.480 locally. Which, again, just crushes that mean 00:28:20.480 --> 00:28:22.279 time to resolution we talked about. It drastically 00:28:22.279 --> 00:28:25.200 reduces it. Yeah. And their commitment to continuous 00:28:25.200 --> 00:28:27.460 security testing was solidified even further 00:28:27.460 --> 00:28:31.200 in 2022. Right. May 2022, they acquired HDEV 00:28:31.200 --> 00:28:34.109 security. Yes, adding more security testing software, 00:28:34.329 --> 00:28:37.089 particularly focused on preventing runtime vulnerabilities 00:28:37.089 --> 00:28:39.849 in the deployed application. Again, this just 00:28:39.849 --> 00:28:41.849 reinforced the belief that security validation 00:28:41.849 --> 00:28:44.269 has to be an integral, continuous part of the 00:28:44.269 --> 00:28:46.569 full observability loop, not a once -a -month 00:28:46.569 --> 00:28:49.009 scan. Okay, moving into advanced observability 00:28:49.009 --> 00:28:51.670 and collaboration. The focus seems to shift to 00:28:51.670 --> 00:28:55.369 internal efficiency and architectural visualization 00:28:55.369 --> 00:28:58.109 for these really complex API -driven environments. 00:28:58.569 --> 00:29:02.109 August 2022 brought Secret. an api observability 00:29:02.109 --> 00:29:05.470 platform as applications decomposed into dozens 00:29:05.470 --> 00:29:09.069 or hundreds of microservices the apis themselves 00:29:09.069 --> 00:29:11.430 became the critical failure points the connections 00:29:11.430 --> 00:29:14.289 between them the connections secret allowed engineering 00:29:14.289 --> 00:29:17.089 teams to monitor the performance the health and 00:29:17.089 --> 00:29:19.809 the contract enforcement of every single internal 00:29:19.809 --> 00:29:23.450 and external api endpoint it provided visibility 00:29:23.450 --> 00:29:25.910 into the digital glue holding their architecture 00:29:25.910 --> 00:29:28.789 together and then a slightly unconventional acquisition 00:29:28.789 --> 00:29:31.759 for a monitoring company collaboration software. 00:29:32.000 --> 00:29:35.140 Right. October 2022, the acquisition of CoScreen. 00:29:35.259 --> 00:29:38.940 This is pure workflow optimization. If an alert 00:29:38.940 --> 00:29:41.279 fires, engineers need to collaborate instantly 00:29:41.279 --> 00:29:44.700 sharing screens, terminals, code. CoScreen provided 00:29:44.700 --> 00:29:47.519 that robust real -time collaboration tool integrating 00:29:47.519 --> 00:29:49.799 directly into the incident response workflow. 00:29:50.059 --> 00:29:52.079 So it's an acquisition focused on reducing that 00:29:52.079 --> 00:29:53.940 initial DevOps friction by making real -time 00:29:53.940 --> 00:29:56.519 problem solving just seamless. Exactly. And for 00:29:56.519 --> 00:29:58.559 organizations dealing with massive sprawling 00:29:58.559 --> 00:30:00.680 cloud infrastructure, our Architectural understanding 00:30:00.680 --> 00:30:03.059 is just a constant battle. That's where Cloudcraft 00:30:03.059 --> 00:30:05.660 came in. They were acquired in November 2022. 00:30:06.599 --> 00:30:08.819 Cloudcraft specializes in infrastructure modeling. 00:30:09.180 --> 00:30:12.220 It allows users to dynamically create and maintain 00:30:12.220 --> 00:30:15.000 architecture diagrams based on real -time data 00:30:15.000 --> 00:30:17.039 from their cloud accounts. It's always up to 00:30:17.039 --> 00:30:19.980 date. Always. For an enterprise with an immense, 00:30:20.160 --> 00:30:23.779 constantly changing AWS or Azure footprint, Cloudcraft 00:30:23.779 --> 00:30:26.700 automated the visualization of what talks to 00:30:26.700 --> 00:30:29.180 what, integrating that visual mapping directly 00:30:29.180 --> 00:30:31.900 into the monitoring data. It's invaluable for 00:30:31.900 --> 00:30:33.940 incident response and compliance checks. Their 00:30:33.940 --> 00:30:36.559 final acquisitions in 2023. showed a deepening 00:30:36.559 --> 00:30:38.980 commitment to static analysis and also business 00:30:38.980 --> 00:30:42.119 integration. In April 2023, they acquired Codiga, 00:30:42.299 --> 00:30:44.859 focusing on static code analysis across the development 00:30:44.859 --> 00:30:47.859 lifecycle. This is the ultimate shift -left move. 00:30:48.119 --> 00:30:50.359 It's about catching issues like performance anti 00:30:50.359 --> 00:30:53.039 -patterns, security flaws, or code maintainability 00:30:53.039 --> 00:30:55.440 problems right as the developer writes the code, 00:30:55.599 --> 00:30:58.039 long before it even enters the CICD pipeline. 00:30:58.339 --> 00:31:00.119 And then bridging that technical data with the 00:31:00.119 --> 00:31:03.740 business office. That was the November 2023 acquisition 00:31:03.740 --> 00:31:07.410 of ActionDesk. Action Desk is a cloud -based 00:31:07.410 --> 00:31:09.789 spreadsheet application that integrates directly 00:31:09.789 --> 00:31:13.250 with live data sources, including Datadog's own 00:31:13.250 --> 00:31:16.529 massive data stores. Wow. This bridges the gap 00:31:16.529 --> 00:31:19.210 between raw monitoring data and business analytics. 00:31:19.650 --> 00:31:22.890 Non -engineering teams, product managers, finance, 00:31:23.250 --> 00:31:26.430 operations leads, they can now leverage Datadog's 00:31:26.430 --> 00:31:29.109 data without needing direct access to complex 00:31:29.109 --> 00:31:31.390 dashboards. So they can answer questions like... 00:31:31.660 --> 00:31:33.900 How did the cost of running this specific feature 00:31:33.900 --> 00:31:36.579 change after the last deployment? Precisely. 00:31:36.640 --> 00:31:38.579 The strategy is just undeniably comprehensive. 00:31:39.160 --> 00:31:41.680 It's to acquire the tools necessary to make Datadog 00:31:41.680 --> 00:31:44.160 the single pane of glass for all technical and 00:31:44.160 --> 00:31:46.299 operational data, from the initial line of code 00:31:46.299 --> 00:31:48.420 to the final financial ledger. It creates an 00:31:48.420 --> 00:31:50.839 incredibly powerful flywheel effect. The more 00:31:50.839 --> 00:31:53.099 parts of the business Datadog observes, the harder 00:31:53.099 --> 00:31:55.559 it is to rip out and replace. And this holistic 00:31:55.559 --> 00:31:58.200 strategy is fully exemplified by their most forward 00:31:58.200 --> 00:31:59.920 -looking acquisitions, the ones scheduled for 00:31:59.920 --> 00:32:02.539 2025. which really demonstrate where they see 00:32:02.539 --> 00:32:04.819 the future of observability leading. Right, to 00:32:04.819 --> 00:32:08.059 AI and advanced experimentation. These two 2025 00:32:08.059 --> 00:32:11.259 acquisitions, they signal a move beyond traditional 00:32:11.259 --> 00:32:14.500 IT and into data reliability and business optimization. 00:32:14.900 --> 00:32:17.200 It's a whole new frontier for them. Let's start 00:32:17.200 --> 00:32:21.319 with Metaplane, scheduled for April 2025. What 00:32:21.319 --> 00:32:24.200 does AI -powered data observability even mean? 00:32:24.519 --> 00:32:26.839 This signals a strategic shift from monitoring 00:32:26.839 --> 00:32:28.819 the health of the application to monitoring the 00:32:28.819 --> 00:32:31.680 health of the data itself. As companies increasingly 00:32:31.680 --> 00:32:35.079 rely on massive, complex data pipelines for crucial 00:32:35.079 --> 00:32:36.960 business intelligence and machine learning models, 00:32:37.160 --> 00:32:39.539 if the data is wrong, the business decision is 00:32:39.539 --> 00:32:42.599 wrong. Garbage in, garbage out. Exactly. Metaplane 00:32:42.599 --> 00:32:45.799 uses AI to monitor data quality. This includes 00:32:45.799 --> 00:32:48.380 tracking data freshness, is the pipeline running 00:32:48.380 --> 00:32:50.980 on time? Volume, are we processing the expected 00:32:50.980 --> 00:32:53.579 number of records? And schema changes, did someone 00:32:53.579 --> 00:32:55.759 accidentally rename a column and break all the 00:32:55.759 --> 00:32:57.960 downstream dashboards? So integrating this into 00:32:57.960 --> 00:33:00.539 existing platform means an engineer can now see 00:33:00.539 --> 00:33:02.900 if an application deployment broke the data pipeline 00:33:02.900 --> 00:33:05.539 and the application all in one place. All in 00:33:05.539 --> 00:33:07.579 one place. It connects the two worlds. And the 00:33:07.579 --> 00:33:10.420 final acquisition listed, EPPO, scheduled for 00:33:10.420 --> 00:33:13.740 June 2025. This one seems to push Datadog directly 00:33:13.740 --> 00:33:16.039 into the product management and business optimization 00:33:16.039 --> 00:33:19.599 space. EPPO is a game changer. It provides experimentation 00:33:19.599 --> 00:33:22.740 infrastructure. It integrates a modern data stack, 00:33:22.980 --> 00:33:26.299 AI features, and critically, tools derived from 00:33:26.299 --> 00:33:28.920 causal inference literature. Okay, for the learner, 00:33:29.079 --> 00:33:31.519 what does that mean? Causal inference. This is 00:33:31.519 --> 00:33:34.099 the key differentiator. Traditional A -B testing 00:33:34.099 --> 00:33:36.579 can show you a correlation. After we launched 00:33:36.579 --> 00:33:39.240 FeatureX, sales went up. Right. But you don't 00:33:39.240 --> 00:33:41.099 know if feature X caused it. You don't know for 00:33:41.099 --> 00:33:44.059 sure. Causal inference, however, uses rigorous 00:33:44.059 --> 00:33:46.599 statistical methods to prove that feature X caused 00:33:46.599 --> 00:33:49.160 the business outcome, isolating the impact and 00:33:49.160 --> 00:33:51.359 eliminating all the other noise. So Datadog is 00:33:51.359 --> 00:33:53.539 moving into a role where they can not only ensure 00:33:53.539 --> 00:33:56.059 the feature deploys safely and performs efficiently, 00:33:56.359 --> 00:33:58.359 but also help the product team scientifically 00:33:58.359 --> 00:34:01.339 analyze its actual business impact. Did it increase 00:34:01.339 --> 00:34:03.880 conversion? Did it decrease churn? Precisely. 00:34:04.160 --> 00:34:06.720 It closes the entire loop. They acquire the whole 00:34:06.720 --> 00:34:09.739 journey. A developer uses Codiga to write secure 00:34:09.739 --> 00:34:13.079 code, deploys it via undefined labs, monitors 00:34:13.079 --> 00:34:15.960 its performance and security using the core Datadog 00:34:15.960 --> 00:34:18.760 platform and screen, monitors the data quality 00:34:18.760 --> 00:34:21.960 using Metaplane, and finally analyzes the true 00:34:21.960 --> 00:34:24.519 causal impact on the business using EPPO. It 00:34:24.519 --> 00:34:26.900 transforms Datadog from a system maintenance 00:34:26.900 --> 00:34:29.460 tool into an enterprise optimization engine. 00:34:29.800 --> 00:34:31.300 That's what they're building. The acquisition 00:34:31.300 --> 00:34:34.300 timeline is a truly remarkable testament to a 00:34:34.300 --> 00:34:37.659 unified, long -term strategic vision. Hashtag, 00:34:37.659 --> 00:34:40.380 hashtag, outro. So what does this all mean? Okay, 00:34:40.440 --> 00:34:43.079 so we've traced Datadog from its origins, solving 00:34:43.079 --> 00:34:45.840 that internal organizational friction all the 00:34:45.840 --> 00:34:47.800 way to its current status as a billion -dollar 00:34:47.800 --> 00:34:50.760 public giant defined by these strategic acquisitions. 00:34:50.940 --> 00:34:53.219 Let's summarize the key takeaways for you, the 00:34:53.219 --> 00:34:55.570 learner. Datadog's explosive growth was really 00:34:55.570 --> 00:34:58.090 contingent on perfect timing. They solved that 00:34:58.090 --> 00:35:00.489 dev versus ops conflict by creating a single, 00:35:00.610 --> 00:35:03.150 unified plane of glass for metrics, logs, and 00:35:03.150 --> 00:35:05.809 traces. That made these distributed cloud environments 00:35:05.809 --> 00:35:07.710 finally manageable. That was the fundamental 00:35:07.710 --> 00:35:10.210 insight that let them capture the market. And 00:35:10.210 --> 00:35:12.789 furthermore, the company's decade -long M &A 00:35:12.789 --> 00:35:16.250 timeline is not haphazard at all. It's a disciplined, 00:35:16.449 --> 00:35:19.989 strategic move to unify data across every technical 00:35:19.989 --> 00:35:23.369 silo monitoring, testing, security, the developer 00:35:23.369 --> 00:35:26.630 workflow, everything. This continuous expansion 00:35:26.630 --> 00:35:29.670 justifies their massive valuation because they're 00:35:29.670 --> 00:35:31.909 now selling not just a product, but a necessary 00:35:31.909 --> 00:35:34.769 integrated operating system for the modern cloud 00:35:34.769 --> 00:35:37.170 enterprise. They moved from being a monitoring 00:35:37.170 --> 00:35:40.050 tool to an observability platform. And now I 00:35:40.050 --> 00:35:42.030 think you can argue they're transitioning into 00:35:42.030 --> 00:35:44.510 a business intelligence and operational optimization 00:35:44.510 --> 00:35:47.630 platform. They own the data required to answer 00:35:47.630 --> 00:35:49.889 nearly every critical technical and financial 00:35:49.889 --> 00:35:52.090 question within a modern organization. So what 00:35:52.090 --> 00:35:54.050 does this all mean? It means Datadog defined 00:35:54.050 --> 00:35:56.369 and now dominates a field that is only growing 00:35:56.369 --> 00:35:59.730 in importance. As businesses become 100 % digital, 00:35:59.929 --> 00:36:02.630 the ability to see, to understand, and to troubleshoot 00:36:02.630 --> 00:36:04.389 these distributed systems is just foundational 00:36:04.389 --> 00:36:07.429 to survival. Their success demonstrates the immense 00:36:07.429 --> 00:36:10.269 financial value created by solving complex organizational 00:36:10.269 --> 00:36:13.289 inefficiencies through superior integrated data 00:36:13.289 --> 00:36:16.329 visibility and operational control. And here's 00:36:16.329 --> 00:36:18.630 the final provocative thought for you, the learner, 00:36:18.789 --> 00:36:21.570 something to mull on. The company famously bet 00:36:21.570 --> 00:36:24.309 against a $7 billion acquisition from Cisco, 00:36:24.449 --> 00:36:28.030 and they won big, demonstrating absolute confidence 00:36:28.030 --> 00:36:31.909 in the future of unified observability. Given 00:36:31.909 --> 00:36:34.590 their strategic move into AI -powered data quality 00:36:34.590 --> 00:36:36.849 with Metaplane and advanced business experimentation 00:36:36.849 --> 00:36:39.510 with EPO, they are clearly expanding the definition 00:36:39.510 --> 00:36:42.369 of what they do. If they are moving into data 00:36:42.369 --> 00:36:44.869 governance and causal business inference, how 00:36:44.869 --> 00:36:47.210 far will the boundaries of observability be pushed 00:36:47.210 --> 00:36:50.010 in the future? What new operational category, 00:36:50.329 --> 00:36:53.010 maybe IT finance optimization or regulatory compliance, 00:36:53.369 --> 00:36:55.769 will they swallow next to integrate even more 00:36:55.769 --> 00:36:57.949 deeply into the enterprise decision -making? 00:36:58.280 --> 00:37:00.019 workflow. They've proven that they are willing 00:37:00.019 --> 00:37:01.980 to buy the entire loop. The real question is, 00:37:02.019 --> 00:37:04.300 where does that loop end? The consolidation continues 00:37:04.300 --> 00:37:06.559 and we are tracking every step. We hope you feel 00:37:06.559 --> 00:37:08.539 thoroughly informed and ready to discuss the 00:37:08.539 --> 00:37:11.000 Datadog journey with confidence. That was the 00:37:11.000 --> 00:37:12.239 Deez Dove. We'll see you next time.