 So, this topic of adoption of technology is something I'm quite interested in. So, I've been working with our data science teams the last couple of years on reports about how various technologies are being adopted and being used by our customers at Datadog. Today, we're going to dive into the most recent study that was published this morning that focuses on orchestration, Kubernetes and ECS to be specific, but orchestration in general. But before I get to the study, I think it's important to often offer context about who I am and what I do and why any of the data I give you today should matter and why you should trust anything I say or not. So we'll take a quick detour just to talk about who Datadog is and who I am and where the heck I got all this information I'm about to dump on you. So any folks that are familiar with Datadog, probably stop by or booth down in the sponsor showcase hopefully. Anybody using it today in your environments for monitoring Kubernetes, containers, anything else? Cool. Awesome. That's a lot of hands. It makes me feel good because it means that my work is actually getting used somewhere, which is awesome. So for those of you that didn't raise your hand, we're a SaaS-based monitoring service. We're collecting metrics, logs, and traces from thousands of organizations around the world. Our goal is to help you make sense of all your application, infrastructure, and business data as you're trying to make decisions about your environments, whether it's are they up or are they down, do I need to scale it out? Was this event, I'm running a success? How many folks were on call for Black Friday this past week? Cool. So there's folks in the room that were wiping sweat from their brow as people checked out on online shopping carts. That's the kind of stuff that we help monitor. Now my role, I work on the product and open source teams at Datadog. I spend most of my time split between two things. The first is ensuring that we're good open source citizens. So that might be showing up at things here like KubeCon or we joined the CNCF on Monday, making sure that when we're participating in things like open tracing that we're doing so in a transparent and genuine manner. Making sure that pull requests from our community get merged on time, things like that. But the other half of my time, I spend working with our customers in our community and learning and identifying the technologies that they're using and trying to figure out how best to help them gain visibility into it. So lately that's been working mostly with containers and orchestrators, some cloud providers, but it feels like every day I'm spending my time thinking about Docker or Kubernetes or something similar. And so when I say we try to figure out all the things that our customers are monitoring, I really mean everything. It's everything from caches to containers to queues to cloud providers and everything else in between. We really want to help you collect everything because we think if you have that all in one place it's much more effective as a tool than if you're looking at five different systems across different monitoring systems or different technologies. But so of course we're here at Cloud Native Cons, so I'll talk about the things that at least from the CNCF ecosystem that we either use or adopt or monitor. We have a logging product that we launched about a month ago that integrates with Fluent D quite a bit. So we love Fluent D. We also can monitor Fluent D from our monitoring solution. Kubernetes, we've been playing with Kubernetes and Docker and Container D since pre-1.0 for all of them. And then again on Monday we launched our open tracing solution for Go and Python and other languages are coming very soon. So we're adding more things all the time. It's about 250 things out of the box that we monitored today, which is quite comprehensive. But you're not here for a data dog pitch. You're here for Kubernetes adoption data, so we'll keep going. So as we're going to get ready to jump into the study, I want to do a couple of quick trivia questions, see what your thoughts are on what's being adopted. And then we'll see if you're right as we dive through the study. So just again, another show of hands. You're going to be raising your hands a lot today. It's going to be like being in back being in grade school. Apologize in advance. So by a show of hands, I'm kind of curious which of these technologies you all think is most likely to be used in a Kubernetes cluster that we're monitoring. So the first is Postgres. Think that one? Not a single hand in the house? My SQL? You could, but then it's hard. Apache. All the hands go up for Apache? OK. We'll see if you're right. Let's keep going. So again, as I mentioned, we're always looking to better understand what technologies our customers are using and the trends that the industry is taking. And we want to be able to help monitor them, be able to tie into them, make sure our customers can be successful with them. So how do I decide on what to focus next? Turns out there's a couple of signals I can pretty reliably count on as I'm trying to figure out the maturity or adoption of a given technology. The first and most important one is always hacker news. I just stop a search in there, look at the numbers, and if they're high, clearly that's what I should be writing my applications in, and you're likely writing yours in. Just follow the latest trend. It's called hacker news-driven development. It's very successful in Silicon Valley companies. I've been through a few of them that take this approach. I don't know about you all. Anybody have coworkers that do this? Nobody wants to raise their hand for that one. I promise the camera's not pointing at you. It's pointing at me. They'll never know. But if we look at the numbers, it turns out containers are pretty awesome. Like, the numbers are high up there. They're higher than most things I search for. Whether it's Docker, ECS, or Kubernetes, it turns out according to this I should be packaging all my stuff in Docker and running it on Kubernetes, who knew? Then again, it turns out that Rust and Uber are cooler. And so apparently I need to pivot and stop worrying about containers, start worrying about infrastructure, and just build a really rusty ride sharing service. And I'm going to be a millionaire. But anyways, we'll keep going. So again, we're at Cloud Native Con. The other thing I could do is I could pull the audience at events like this, where they'd be at meetups or something like that, like we did at the start. I guess that's semi-scientific to figure out if things matter, because I see that you all paid to be here and it's interesting to you. And I can tell that it's important. But there's a bit of selection bias. I can't tell if it's, I mean, you may be early adopters. You all may say that you're using Kubernetes or using Docker and then you go back home and you're still running things on-prem and VMs or whatever it might be. So polls are not the perfect way. Another thing I can do is look at the age of these technologies and kind of dive in. And so it's important to remember that almost everything we've talked about today is quite young. And it's moving pretty quickly. If we look at this, Linux was released in 94. Let's look at that as an example of a technology and how quickly it was adopted. I know this is a bit of an eye chart, but Linux was released in 94. And it took about what, seven years before? Well, 1.0 was in 94. It was released earlier than that. But it took about seven years before we got some serious business adoption. This is the first time. 2001 was the first time that IBM jumped in and said, we're going to put a billion dollars into Linux. Anybody remember the commercials with a little kid? We'll teach him. We'll raise him. He'll be awesome. His name is Linux or something like that. So that took about seven years. That took a while for people to really get on the open source and on the Linux bandwagon. But here we're at KubeCon. And I go to ExpoFloor. And obviously, I think Datadog's awesome. But you wander around and you see huge organizations there. You see IBM. You see Microsoft. You see Cisco. You see Intel. They're all jumping in with both feet on this containers thing and this Kubernetes thing. So seems like we're moving a little bit more quickly. I don't know if it's our love for the cloud or the need for dynamic infrastructure now or what. But it's weird that after only three to four years, everybody is talking about this. And really, as we'll see in the study, a lot of people are actually using it as well. For us, our first signal, the real thing is when customers ask for it. So in 2014, we got our first pull request. Docker hadn't even hit 1.0 yet. And some customer was scared about this enough to actually write a Docker integration for Datadog and start collecting metrics. And it's like, well, if they want to do it, I guess. If they wanted enough to write the integration for it, then clearly it's important to somebody. And so we dove in on it. We started partnering with them. We took the Datadog agent, shoved it in a container at this point. We've collaborated with our community. We've got, I think, over 5,000 contributors at this point on our various open source projects. And what built a containerized agent, you can drop it on Kubernetes or ECS or plain old Docker or anywhere else that you might want. And it collects metrics and monitors your applications and does all the right things. So for us, that's important. Much like everybody else, we're also adopting containers. We've been using them in CI forever. We've been using ECS for about as long. We're starting to use Kubernetes in other places now. So lots of containers everywhere at Datadog, too. But again, all this is really anecdotal. You might ask, where's the data? We are Datadog. Data's in our name. If I didn't show up with data, you'd probably laugh me out of the room. So we kind of have to go back and fact check all this. I can't just kind of do this poll, go back to my boss and say, let's drop all that. Everything else from the roadmap, it's all Kubernetes moving forward. So I start to look at other data. I can look at maybe polls from Docker Hub. Every year at DockerCon, Docker talks about how many images have been pulled from their service. In 2014, it was about a million. It took about over a year. It increased significantly from a million to a billion. 2016 was 6 billion. 2016, they just announced when I was in Copenhagen, was 24 billion poll requests. Sorry, image polls. And that's just from public Docker images. We're not talking about all the private registries that you all might be using, or Red Hat has a new container or image service that they offer, all other places that it might be. So clearly, containers are taking off. For us, though, we realize we have real data. And so remember, we're monitoring infrastructure all over the world for thousands of organizations, and it all comes back to our hosted service. And so about a few years back, we started looking at that data in a fairly rolled up and anonymous fashion. We're not digging into any individual person's data, but we look at it in aggregate. And we realize that we can tell from these workloads, from these trillions of data points per day, once we aggregate all that data, we can see technology trends in the tech world around us, pretty accurately and pretty quickly, we can see as things shift. So we started as putting out these reports. We put the first one out in 2015, and we looked at the first year of Docker since 1.0 and dove into Docker adoption. And we saw some pretty interesting stats. We refresh it annually now. So every year at DockerCon, we put this out. But we're at KubeCon, so we'll keep going. But what did we see in the last report? We saw things like containers being up 40% in our customer base over the previous year. And that had been 5x up the year before that. So that's clearly some good data. These are folks that are paying us to monitor Docker. Clearly that's some production use case. You don't tend to pay somebody to monitor things you don't care about. We then looked at it again, and we saw things like 15% of the hosts we monitored at the time were running some amount of Docker on them. Nowadays, it's actually closer to 35%. If you look at organizations over 500 hosts, you're pretty much guaranteed to be running some amount of Docker. But if you're over 500 hosts, about 35% of you are running some amount of Docker. So that's growing. Again, that's real data there. Let's dive into orchestrators, though, right? That's what we're here for. We're here at KubeCon and CloudNativeCon. So we raised hands before for Docker orchestrators in general. Anybody just still running just Docker? Like, you're Docker running everywhere? You got Ansible or something else kicking off Docker runs for you? Couple of you? So we were curious about the same, right? We saw this Docker adoption. We wanted to see how are folks using it. And again, this is from about six, eight months ago. We dug into it, and we found that about 40% of organizations at the time were running some form of orchestration if they ran Docker. This is as of April. And when we dove in and looked at it even further, one of the things that we found was that if you were over 25 hosts running Docker, your probability ran up. You moved up to about 50% of the users running something. Once you hit 165 and beyond that, you're basically guaranteed to be running some sort of orchestrator. Turns out when you're running at scale, you don't like SSH-ing in a for loop or whatever crazy Rube Goldberg machine you put together is for launching containers and rescheduling them. You actually want something to do this for you. So another interesting stat. About 5% of you all are apparently running two or more orchestrator technologies. Who's got this Frankenstein environment out there? Raise your hand, a couple of you. Migration story? Yeah, I'm going to meet up here. Cool? Yeah, you guys have a really cool case study with Google, up on the Google site about how are you using GK. So if folks are looking for how this guy here is doing all kinds of awesome stuff with Kubernetes, it's up on the Google site. Thank you. So yeah, I think usually I hear about people that it's migration stories. Other times it's folks like where there's acquisitions or mergers or just large organizations where there's different teams. I can't possibly use what you're using. So it's a little bit of everything. This dysfunction does come with us even as we move into the new generation of technologies. But again, let's talk about the new data, where I've been telling you all about this old data that's, I don't know how old April's not that long ago, but it's old compared to the stuff I released three hours ago. So what's new? Today we released a new report. Again, it was mostly focused on Kubernetes and ECS. We see lots of other orchestrators as well. We see Nomad. We see Mesos. We see Swarm. We see other things. But really, I think Kubernetes and ECS were the ones we've had the most conversations about. So we wanted to dive into those specifically. And so the first thing is there's some pretty good news for Kubernetes in terms of adoption. In the first nine months of the year, so again, I had this data is up through October September. Had to go back and put together. But again, through as of October 2017, about 41% of all Docker environments that we monitor are using Kubernetes to orchestrate them. That's quite high. Again, a minute ago, we just talked about only 40% of our customers that were using Docker even use orchestrators. That was from last year. Now we're saying over 41% of them are actually using Kubernetes. It turns out that these days it's about 2 thirds of organizations are using some number of orchestrators, one or more. That's huge growth. The other thing to keep in mind is that the number of Docker users that we have, remember, we saw that growth curve that Docker was on? That's not slowed down. That's at the same pace. So if you talk about percentage of 30% here versus 40% here, that's more than an 11% gain. That's a huge gain. That's a lot of people jumping into Kubernetes. So I don't think you all are alone as you looked around the room and you're like, who's got your hands up? You all have your hands up because everybody's running Kubernetes. But the real question is how does this impact your workloads? How does this impact what we do? Kelsey was yesterday on stage giving a keynote and you reminded us all. Nobody cares about your Kubernetes cluster. They care about the business services that you offer. They care about the products you deliver to your customers. I mean, you care about your Kubernetes service. But at the end of the day, keep it up, move on, go back to building product. Keep it boring, he said. So I think the other question is, is Kubernetes and is Docker helping us do that? Well, we found some interesting stats around what it did to host churn and container churn. Usually, we see hosts that we monitor live about 23 days if they don't involve any amount of containers. But once we introduce containers, it drops to 17 days. Once we add orchestrators like ECS or Kubernetes, they vary a little bit by a couple of days. But it's about 10 days on average that an ECS or Kubernetes host will be around for. And I think that's telling. It shows that Kubernetes and ECS make it pretty easy to drain workloads off your machines, kill those machines, bring up new machines, have those workloads show up somewhere else. You don't really feel bad about terminating those hosts and bringing them back up. And this is above and beyond what folks were already doing with VMs, where they already were probably using auto scaling groups, probably using some other dynamic method for provisioning their systems. So I think that's one sign that it's helping us move faster. But not surprisingly, it also helps our containers be more dynamic. Remember that SSH for loop around Docker run? It's pretty slow. It makes it hard to make changes quickly. Folks that are doing blue-green deployments, that kind of stuff, are not doing that. So once you start diving into something like Kubernetes, it's just an assumption that you're going to be able to move faster, reschedule them faster, deploy faster. So one interesting stat we found here was that containers running on Kubernetes live only about one and a half days on average. ECS, on the other hand, which is, I think, the next most popular container orchestrator we see, lasts about 12 days on average for a container. So I don't know what you all think that means about Kubernetes versus ECS workloads. I don't have to point at Kubernetes jobs or the cron scheduler or other things that are bringing pods up for very short periods of time, which ECS doesn't have. Or if it's that people are just using ECS as an artifact deployer, not necessarily as a real container orchestrator. It's interesting. I'm curious to see what all the Fargate stuff that they announced at the keynote earlier this week with Adrian Co-Croft will change things too, especially since I won't be able to see the hosts anymore. It's just containers, right? But it'll be interesting. So the next thing that we've all talked about, we talk about speed when we talk about containers and we talk about orchestrators, but the other thing we talk about is density and efficiency, right? How many folks are doing this for bin packing reasons? Like you really want really efficient, 100% utilized all your infrastructure. You don't want to leave one cent on the table, right? A couple of people raised their hands, right? We want to stop moving things like this where we've got a lot of empty space around. We're kind of shoving things between boxes, trying to make use of those workloads, and be a lot more efficient, a lot more standardized, right? So when we did our Docker report, we found that folks were running about seven containers per host. So I'm curious, is folks on average, are you running more or less? More, a couple more, a couple less? So what do you think Kubernetes does to this? Do you think it's gonna give us more containers or less containers per host? So you're right, it's more. So when we dove into Kubernetes, we see closer to nine application containers per host. And what do I mean by application containers? Well, I mean your workloads. So when I looked at this, I thought, I don't really care, I mean, you're not really deploying Kube DNS for the sake of deploying Kube DNS, that's like a utility, that's a system container for you. You're not deploying all of the Kubernetes system, control plane stuff as your own containers, that's part of the orchestration system. So we hadn't grept all that out, excluded that from our report, and so that's only nine. If I put all that back in, it's like 14 to 15 containers per host, but most of that again is Kubernetes itself. So it feels a little weird to give Kubernetes credit for just existing, right? Like if you could have a completely idle Kubernetes cluster and you likely have like five containers running on that box, it's like, I can't really count that, right? So we're excluding all that, just because it turns out Kubernetes uses a lot of containers itself, which is cool. ECS on the other hand tends to only have three containers on average. If I throw the fourth container in there, it's gonna be ECS agent. I just, I gripped that, I pulled that one out as well because again, for the same reason, nobody's intentionally paying to run the ECS agent, just like nobody's intentionally paying to run their Kubernetes control plane. I don't know really what that says. I mean, that's three X more density. Again, I think it's sort of telling about the types of workloads people do on ECS versus Kubernetes, but it needs to dive into it more. So if you have your own thoughts, I'd love to love your hypothesis so I can go dive into it and prove it with data. Cool. So let's go back to that trivia question. Let's play a little game of family feud. What would the survey, you know, we had before folks were saying what we said Apache was the most popular technology that's running in, of the three that I mentioned, running in Kubernetes. Is there any other things you think are almost guaranteed to be running there, something that you're sure will be on this list when I flip the cards? Engine X, okay, anything else? Message queues, any specific message queues? Rabbit, okay. Redis, okay. Cool. So it turns out it's things like Engine X, so I don't know if I had socks or something, I tossed it at whoever said Engine X, but I don't, so come by the booth later, maybe we have, I think we probably have some shirts for ya. RabbitMQ was on there. Elasticsearch, MongoDB, Postgres, MySQL, right? They're all in there. Who said Apache before? It was all of you, right? Apache's not even on the list. It doesn't even fall into the top 15 things that I find in container environments. I don't know why that is. I spent so many years automating Apache deploying Apache, running Apache. I think I could, on a whiteboard here, write a tactically correct Apache config file for ya, and nobody's using it in container environments. And I don't know why, I mean maybe it's, maybe it's just a little heavier weight, I don't know. What I do find really interesting is the number of databases that are on there, right? How many of you all are doing stateful workloads in your Kubernetes clusters? Couple hands, but it's not, generally folks, I run into folks, the mass majority, like if I asked you how many of you guys are running state list services on your Kubernetes clusters, all the hands are gonna go up, right? So it's just interesting the number of, when we look at this, the number of folks that are doing it. So to give you a sense of the ranking in Kubernetes at least, you know, Nginx of course by far, I think pretty much everybody's using it as a reverse proxy here, but you know, the others are well within each other's range in terms of the data stores. There's quite a few of them. What do you think it looks like across other orchestrators? Do you think it's about the same across things that are running containers or things that are running ECS? It's the same technologies again. The difference though is that, what I see in ECS is that most people are running their own custom built images. They're not building things off the shelf or things that they've built from. They're building, they're mostly their own applications. I think that's because when you run in something like Google or you run in something like ECS with Amazon, they already give you all the services. Why would you run a Redis server if they, like they already give you a reliable Redis server that you just, you pay less for and don't have to worry about operating? You just, you take advantage of that whole ecosystem. So I think that's the real reason why on ECS everything's smaller, the stacks. On Docker, again, it's about the same. It's just, again, the scales are slightly different, but it's about the same. You know, I started to look at also at container registries this morning. I wish it was actually interesting. It turns out that if you're in Google, you're using the Google Container Registry. If you're in, if you're in Amazon using the Amazon Container Registry and then all of you are using some amount of Docker Hub because it's the thing that everybody uses. But if we talk about the best practices around some of that, how many folks are pulling latest from like Docker Hub all the time? None of you? Nobody? Nobody? I see some people going, sometimes. Yeah? Yeah, that's what our docs say, right? So you better be doing that. Yeah. How many of you guys are mirroring, how many of you all are mirroring things back into your own registries or into private registries? I see three hands, four hands. Okay, so not a lot of folks. Do you think most people are, do you think most people are doing about the same as you or better or worse, somewhere in the middle? Yeah. So it turns out it's a pretty healthy mix. I mean, it's a scary mix, but it's a pretty healthy mix, right? About 74% of you all are doing a mix of good things and bad things. About 10% of you all are doing only the good things, which is like mirroring your containers or grabbing specific versions and not letting me break you when I release a new thing. Sort of like, I mean, how many, did we not learn our lesson? Like who didn't lock their bundle file, their gem files or their requirements files and like in Python or Ruby back in the day and like have everything blow up on them on the next deployment? Did we not learn anything in the last 10 years? Anyways. So about 16% of you are doing like the right, again, doing the right thing and only deploying the wrong thing and only deploying latest, which I guess that's, those cowboys we always hear about, right? So yeah, that's the facts I got for you today. I think I've got a couple of minutes left here to answer any questions and dive into anything I maybe didn't cover. If there's some metrics I didn't report on or something I was supposed to talk about that I said in the abstract and didn't cover here today, you can quiz me on it, grill me on it, throw some tomatoes, whatever it might be. Feel free to tweet at datadog or myself. I saw you all taking pictures of the graphs. They're all online. So just, I'll tweet them out in a second. They'll be linked here as well. It's up on the datadog website. You can check it out. We also have it down in the booth if you wanna check it out on the big screen. I've got a bunch of resources here in the slides about how to monitor Kubernetes, how to monitor Docker, how to work in the cloud, a whole bunch of other things there. The original Docker report, I'll put these up on the slides for the KubeCon site in just a few minutes. But yeah, if there's any questions, happy to answer them. We've got about, I think about eight minutes left. So I finished just in time for that, you know? All right, it's been fun. School's out.