0:00 Again, if it's just you and I, it doesn't really matter. But I'm so frustrated. Well, hello again. Alright. We're now live again. My audio is working. I have no idea what happened. Hopefully, few of you see this, but we're gonna continue with the demo because that was just getting good. And I was actually you you were doing a Docker Compose demo, and I was trying to throw questions at you. And I was like, he's just ignoring me. That's awfully rude. That's right. That is the best way to do a demo. Just, yeah, just gonna keep going and not stop. Yep.

0:25 Managing Builders & Service Model Question

0:31 Alright. So I've I did have a few questions. I thought I've been able to manage the builders via Buildx on the CLI and so the UI is obviously a nice touch. But it does make me wonder, you know, how much you know, there are different types of organizations out there. For me, I want you to manage the builder. I don't have to care about it. I probably wanna pack how much RAM or CPU. I don't even know if I get that much control. We didn't get to go into that much detail. But what about for larger customers enterprises?

0:58 I mean, are they able to provision these managed things in their own cloud? Like, how does that work for depending on a startup and enterprise? Yeah. Great question. So with this being the initial release, what we have today is a a product that we manage everything for you. And so we we manage the builders, and right as of today, depending on which tier, there's a and this is on the the product page as well too, but there's really only two different machine configurations, and it's really based on whether you're personal or whether you're enterprise customer.

1:06 Docker Build Cloud Service Model (Managed & Roadmap)

1:34 And you can have multiple builders. Of course, there's gonna be additional cost. So if you're on a, you know, an enterprise that's got a hundred developers or a thousand developers, obviously, you're not gonna wanna share the same machine. You can you can set up additional builders. But as of today, yes, we do manage all the infrastructure. It is on the road map to provide the ability to to provide additional offerings, whether to run those builders within your own infrastructure or even to continue to use our builders within our our own infrastructure, but maybe connect to resources that

2:08 require VPN access or, you know, inside of your corporate networks and that kind of stuff. So there's a lot of different variants on the road map here. But, yeah, this is just the initial release that provides the fully managed, we run it for you infrastructure. Okay. And when you ran the Docker Compose up, curious, you know, what's actually happening there? Is that tearing up my local directory, sending it to the builder as doing the build, and then we're pulling down the image? Like, is that the kind of workflow that's happening? Yeah. So, actually, how about that? So I'll bring it back

2:22 Build Process Workflow Question

2:44 up, and we can I'm just gonna have to change scene in case it mutes me again, but let's see what happens. Alright. I can still hear you. Yeah. Although, I've never got random videos showing up by me. You wanna share your screen? Yep. And there it is. K. Alright. Good to go? Yeah. I mean, I'm sure I'll work out how to get rid of our big faces behind us at some point, but right now, it's not I'm I'm not gonna fix it. Sounds good. Alright. Then I'll I'll just continue on. So when I do and and this

3:35 Build Process & Context Transfer Explained

3:37 is actually the case for any build. So even if I'm doing a local build, and I'll I'll just run this and we can see what's kinda happening here. So what ends up happening is, first off, it has to connect to, in this case, it's connecting to the the Build Cloud service because that's the builder that I'm using. It's the driver. But even if I were using the local driver, it's gonna have to connect to the local BuildKit engine that that's running. K? And then from there, it's basically gonna load the Dockerfile, and then based on the

4:06 Dockerfile, so and the Docker ignore file, it's gonna transfer context for what's what do I actually need to do this build? So in this particular case, since I'm just doing a a build and there's not actually any copies that are occurring for the the dev stage, I'm just setting the work directory and and whatnot, that's why there's only two bytes. And, honestly, I'm not sure why there's even two bytes there, but whatever. While while if I do a a, you know, the full build, what we'll see here is that the context that it's gonna be sending

4:37 is a a little bit larger, but even then, there's not that much because it's all cached. So it's computing all the check sums and everything to to find out, do I have cache hits or misses or whatnot before it actually has to transfer the actual files. So in this case, if I were to tweak this, and let's just, I don't know, turn it to question marks. K? Now what that's gonna do is invalidate that layer, and so what we'll see is that there's gonna be more cache that more context that's sent because that particular layer,

5:09 let it finish building here. The copy source, since that layer needs to be rebuilt, it's only gonna send basically this the files for this particular layer. So it tries to be really smart about what is actually needed to be transferred, because obviously, if you end up transferring everything, then that's gonna slow down things, especially for larger projects and and whatnot. So it it does try to be really smart of, hey, we're not gonna send files for cache hits. We're only gonna send things for the the layers that need to be rebuilt, and then even then, only the source directory

5:42 in combination with what's in the Docker ignore file. So even though, like, I've got the node modules and everything else here locally on my machine, well, the node modules aren't in the source directory, but it's, again, being smart about what am I actually shipping to the builder. And it does the same thing even with the local builder, but you just don't notice it as much because it's all just local file moving at that point. Then once it's done, it does Did just send that one file, or did it send the whole source directory? Good question. So it does send the whole

6:10 source directory in in this case. Yep. So it's gonna and that's actually I wanna say that that our build team is looking at how it can make that smarter as well too. But as of today, yeah, it's sending the basically, just, yeah, the the contents of the the source side here, in this case, the whole source directory. Yep. Okay. And then from there, yeah, it builds the images remotely, and then it basically downloads it just as as if it were a registry. So you will see that all these layers were already on my local machine. It's only the the

6:34 Image Download/Pull Process

6:46 last layer that changed, and so I'm only pulling down this, you know, almost 81 and a half kilobytes worth of content here. Yep. Nice. Yeah. There's already improvements performance improvements from that workflow. Yeah. Just put the way that that works and speeding things up, especially when a lot of the network intensive stuff and even the compilation stuff for different types of languages. You know, that all happens in the cloud, which is really what we wanna be seeing here. So I like that. Yeah. And I and I've seen with, you know, projects that have lots of dependencies or

6:56 Performance Benefits & Anecdotes

7:18 having to download lots of files. I mean, the the advantage, again, with the Build Cloud environment is that it's using the the network pipeline the network pipes that exist on the remote build service rather than what I have at home. And I know we've all seen, you know, YARN dependencies or REST dependencies or really any dependencies can just take a long time to download everything. But having fat fat network pipes in the cloud make that go much faster. Yeah. I mean, like I said earlier, with the the dance class, you know, Monday nights are when I'm there, and I had to

7:50 work from there this Monday. And it does an NPM install, and it literally took about thirty six minutes. That's kind of what I'm like. These things I don't need to run over my tethered connection to my phone and some concrete building with very poor connection. So Yeah. Well, and and and a good point there. I mean, so there's a good chance that even with the the Dockerfile, again, just depending on what you're building, you may still be downloading all the the the contents there, but with, you know, you're doing an NPM install and it's having to

8:21 download every package, like, every single one of those libraries is yet another network connection and TLS negotiation and everything that has to occur there. Well, if this happens in your build, then your final image has all that kind of packaged together, and so you're just downloading, at the end the day, a single tarball that has all that rather than having to make those thousands of network connections and everything else. So even if you were downloading the same net content, it's gonna be faster just because you're having to even just do that many fewer network connections.

8:54 Yeah. Definitely. So I haven't played with Docker Build Cloud yet. So if I ask you a question, it doesn't make any sense. Feel free to shoot me down. Sure. Go for it. I do see that we can view the build details and that's Docker desktop link. I'm assuming, do we get to understand cache invalidations on what's happening from Docker desktop and from the web UI? Yeah. So actually, if I click on this here, which I seen that okay. Maybe the the Versus Code integration isn't opening up, but I can just jump over to it. So if we jump

9:15 Docker Desktop Build Details Demo

9:25 jump over to Docker Desktop, what that's gonna do is take me to the builds tab here and basically just open up the the build that just ran. K? And this gives me a a lot of details, and I'll admit, there's it almost feels like there's too much details, and so we're still doing a lot of massaging of what's the right way to present some of this so it's not too overwhelming. But it does give you a lot of good insights in, okay, where even this this build that took six point four seconds, where was the build?

9:54 Where where was the time spent? Was it spent on the the actual build or pulling the layers? And, you know, the so there's the the context transfer we were talking about earlier and whatnot. So it gives me a lot of good details here, cache usage as well too, how much cache is being used. So there's there's quite a bit here on the the initial screen. It does tell me, hey. There here's the dependencies. And what what's cool about this is, you know, if I jump back to the the Docker file that we actually used here

10:25 let me make this a little bit smaller here. I'm doing a multistage build or I'm doing from node, but my final engine is NGINX, yet in my build output here, it it understands that this was a multistage image, and, hey, you actually had multiple images part of this. So I can kinda see what were all the different images, the base images that were used in order for me to to do my build here. And if I had additional provenance or SBOM attachments, etcetera, I can see all that down here as well too. There's even some open telemetry traces as well

10:58 too. So there there's a lot that comes in here. Any questions on the screen? Otherwise, I'll jump to some of the other ones. No. This is great visibility so far. I'm I'm looking at it. K. And so, yeah, source basically just here's the Docker file that was built. Logs, you know, I think we've all had builds in which, you know, the the build ran and something failed, and oops, the error message got collapsed or swallowed up somewhere else or or whatnot, and going into the the log output here, we could see the all the output that

11:32 occurred as part of the build. It's all the console output, and and you get it in its full entirety, and you can also see again, here are the layers that were cached. This particular one took four seconds. Here was all the the output here. Looks like we got some anti character stuff showing up here too, but but again, I I can see the full log output. And then finally, the the tree. This gives me a little bit of details of kind of this particular project over time. So, you know, this was build number six, and this was a

12:03 build that occurred, you know, ten minutes ago, and then another build that occurred about fifteen minutes before that. And so it's kinda just grouping it based on the the project name here, but I can see, you know, how's cache usage over time. So the first time I built this, it took forty seconds, but now all my subsequent builds are, you know, four to six second range. And then I can troubleshoot and debug in into some of those builds as well. So pretty cool. Yeah. This feels like one of those things that the more you use these builders, the longer

12:29 Value Proposition: Shared Cache

12:35 they live, the more they do the cash optimizations that these charts are really gonna start to show you things that, like, that performance is gonna be undeniable after Yeah. Four weeks, five weeks, especially as software's accurate. Right? It's not like we're doing major rewrites, I hope, every We're we're changing, adding a little bit of debugging, adding a trace, adding whatever, a new environment variable and seeing that progression of the cache being used over long periods of time. Mhmm. Yeah. That's gonna be super useful. Instead of like what I do right now, I am a sucker. I don't know if I'm

13:11 a sucker, but I always just delete every Docker image I've got every week, every other week or whatever. I I clean things up, I tidy up, I get rid of caches and, you know, pushing all that to the cloud where I don't even need to worry about it anymore. And I'm still getting that shared cache over long periods of time. And again, especially with a team that are able to reuse these caches. Like, why should 10 developers all do the same compute every single morning when it's just not that necessary? I mean, I'm already sold. I

13:39 see the value of this kind of setup, which is pretty nice. Yeah. And and so to to even build on since you were talking about the the team collaboration usage. Alright. So let's let's go back to my my Docker file here, and let's let's break it here. Okay? Let's say I spelled public with two c's accidentally. Okay? And and now when I build this, okay, obviously, is gonna break my build. Okay? And when I when I do this build, k, I I get my error message here, and I what I can do is if we jump

13:43 Collaborative Debugging Demo

14:12 back to Docker Desktop, first off, I'm still in the the build output from the previous one, and it's already telling me, hey, there was a failed build that that occurred that's now, I guess, kind of future in the history of from the build that I was initially looking at. But I can see the the failed output here. And while I know all these were for myself, but if what what's cool here is that the build history is the build history for that builder, not just for myself. And so if any of my colleagues built this and created it, you know, during

14:43 this build, they ran into failure, they could say, hey. I'm stuck with this. Hey, Michael. Can you help me out here? And I can look into the log output and say, hey. Here's where you here's where it's messed up, and I can help walk them through. So it's a collaborative debugging experience as well in which, again, any team member, because it's a shared runner, all these outputs, all this this log, all all this stuff here is is tied to the builder, and, again, I can help troubleshoot and debug, which is really cool. Actually, I'll I'll show

15:12 if I go to active builds, don't have an active build, I'll just jump back over to the I won't switch the screens here, but I'm gonna add more question marks to our React component. And now if I kick off a build, which I just press enter here, we can see that it shows me that there's the the active build running right now. So I can see kinda live here at all the build builds that are running on this in this particular environment, and then I can see, yep, I I fixed the build, and there it is. So, again, it's trying to

15:45 help me have visibility across my entire team with the shared runner, what's working, what's failed, and and help troubleshoot. Because one of the things that we see quite often is that they're on teams, there are the experts, and then there's honestly, to to be completely honest, there's those that don't care a squat for containers. They're just like, just spin up the containerized environment, get it out of my way, and let me just focus on my code. And so if something doesn't work right, this gives them the opportunity to say, hey, you know, Docker expert on my team, can you help me

16:14 troubleshoot why my build's not working here? And now there's a a mechanism for them to to be able to do that together. So Nice. Great. We've got a question in the comments. The question is, how does this differ from export Docker host equals and pointing it to some sort of SSH or remote Docker engine? Yeah. Good question. So, I mean, in that case, you you kinda have a shared runner, okay, in which you're assuming you share that SSH builder with with everybody on the team, you're, you know, you've got a shared cache. So you're getting some of that advantage there.

16:22 Comparison to SSH Remote Docker Engine

16:52 But the disadvantage is, well, now you have to manage that machine. You're having to keep track of, okay, what versions of of the operating system is it running? Is it using the latest version of the the Docker Builder? And, you know, just all the tooling. Like, that's that's infrastructure you have to control, you have to manage, and and everything, which, you know, for some teams, that that's totally fine, and and you can certainly do that. The other thing is then to and I know we haven't done any multi architecture demos yet, but if I wanted to build natively for AMD

17:21 sixty four and ARM sixty four, now you could technically still do that with SSH builders, but it's it's a little bit more complicated, and you're having to, again, how do I scale this across my team? Here's a bunch of configuration that you're gonna have to set up across all your team and whatnot. So this just is a little bit more of a turnkey solution. It's fully managed, fully ready to go, and you can just get up and going, and, again, you you don't have to worry about the infrastructure. Can Can we dive into that a little

17:46 Multi-Architecture Build Question

17:47 bit? Because I think that's a really compelling use case. You know, so far what we've done is you set your Docker default builder to be a remote builder, which I'm assuming is a single architecture machine. Right? It's not running two CPUs and two kernels. So if I want to do a multi architecture build and I've got my default builder set to an AMD sixty four somewhere, what is actually what's happening for the ARM? How does it delegate that? Yeah. So let let's actually let's give it a shot here. So I'll just jump back to Versus Code. We'll use

18:13 Multi-Architecture Builds: Local (Emulation & BuildKit) + Docker Name Generator

18:18 the terminal here. Alright. So let's let's go back to the the default builder here. K? And if I do a build x build, and let's specify multiple platforms here, Linux AMD sixty four, Linux ARM 64, I'll just tag this sample React app. K. Now when I do this right now, it's actually gonna fail at first. K? And this is actually something we're we're doing internally to without getting too much under the hood, the image store that Docker Desktop uses predates containerd, and predates multi architecture and everything else. And so it doesn't actually have support to be

19:02 able to store multiple architectures of the same image as of today. But there's been a lot of work, and you've probably seen this show up in the settings to be able to use, for example, if we jump over there, to use containerd for pulling and storing of images. Like, this is work to be able to do that, but as you can imagine, there's a lot of plumbing in Docker Desktop that has to get replaced in order to use this tooling here. And so once that's in place, then, yes, this will work as you expect. K? But

19:31 with emulation. Right? What? I'm sorry. What was that? But it builds it with emulation when it's using the container store. So so, yeah, what what I have to do is, first, I have to create basically a new builder. K? And what this is gonna do is it basically creates a container engine that that BuildKit's gonna run-in. And let's just say, let's use that, Nostalgic Einstein, which is such a fun name, which actually maybe let's take a quick little tangent, shall we? Just a fun trivia fact here. For folks that that don't know, all those names

20:09 come from here's the go code, the name generator. And there's a you know, it takes a random adjective from the left and then a a random scientist or notable scientists or hackers. There's a specifically call a specific call out, please, for any amazing man you add to the list, consider adding equally amazing woman to it and vice versa. And there's lots of information about it. So if you're kinda like, wait. Who is this random name that just showed up here? Here's where you can find out. But the fun trivia fact, k, if we go down

20:40 to the code at the bottom here where it actually generates the names, get random name, it gets the random left, gets the random right, and if the final name is boring Wozniak, Steve Wozniak is not boring, go back and get a new name. So there's your random trivia fact for the day. The only valid use of go to I think I've ever seen. So Yeah. Exactly. Alright. So I once got an angry, and I that was the highlight for me. Because it's totally true. Yeah. Exactly. So anyways, now you know if if you're ever in a, you know, Docker trivia, and it's

21:14 like, is never allowed to be boring? You know it's Steve Wozniak. So alright. So going back here, I so what I've done is I've basically built a new Buildx engine that's gonna use, basically, a container to do this build now, and it then it's gonna use inside of that, it has container d, and it's gonna be used in the image store. Now what's happening here is it's basically bootstrapping this builder, and then you'll see all the different steps. I'll try to get it so it doesn't scroll around too much. But each of the the steps will have

21:47 okay. Is this the ARM sixty four or AMD sixty four? Now since I'm on an Apple Silicon machine, downloading right now, so who knows what my network connection looks like right now. Yeah. You just started upload a download everything here. Alright. It'll get there. Yep, it's getting there. Okay. So now we just discovered a new reason for Docker Build Cloud. Delegate all of your builds to the cloud so you can do live streams without worrying about your bandwidth. It's it's it's an important concern. I'm with you. It it is. Alright. So it's almost finishing downloading here. Oh, that sounds

22:56 weird. We're doomed now. That's it. Russ just put in the comments. So it was a perfect pause because I am on Apple Silicon machine audio cuts out. Yeah. Good call. Good call. Alright. So what's happening here is you see that it's doing this YARN install, and it's doing it both for AMD sixty four and ARM sixty four. Yep. And since I'm on Apple Silicon, the ARM 64 will run natively, and so you'll see that that step took about twenty six seconds. K? And, whoops, looks like I got a error of some sort. And but you'll see even just with this,

23:59 k, the ARM 64, it it finished in twenty six seconds to download everything, while the AMD sixty four variant was still at forty six seconds and and failed. K? So and it would have taken I think, at least in previous testing, it takes about two to three minutes for it to to do that yarn install while emulating, and it it's just because it has to emulate the AMD sixty four environment. I don't have a AMD sixty four chip on my machine here. And so, yeah, it kinda stinks. And I would say it's even more so

24:35 profound in, like, GitHub actions where I'm building my pipeline. In the in those cases, I'm most likely on AMD sixty four machine, and then I'm having to emulate the ARM side of things. And those builds can take a long time as well. Yeah. I've got an open source project written in Rust called Contrail that we build for a whole bunch of different architectures. And because it it can pretty much run on anything and there's people doing weird para PC stuff with it. But regardless, the just doing cross compilation is is a very, slow process, particularly in

25:12 GitHub actions. So, you know Yep. It it really is. Need better tooling in this space. Yeah. So And so And how how so how do we do this with with Build Cloud then? Great question. So with Build Cloud, what's nice about this is here. Let me just do Buildx LS, and I'll just show here all the builders that I have on my machine here. And what we'll see is that I've got a builder. K? And this is that that DevRel builder that we had before, and it has already configured. Here's an ARM sixty four and then the

25:22 Multi-Architecture Builds: Docker Build Cloud (Native)

25:45 the AMD sixty four. And so what's what's happening is, basically, there's kinda two sub endpoints. And so now if I let's say alright. Let's use that builder, and let's do that same build. Oops. Let's do push. Yep. It's because I need to tag that with my actual username here. Oh, well, now a lot of it's cache, But, again, it's it's gonna be using the native node for AMD sixty four and a native node for ARM 64, and so there's no emulation that has to occur. It's delegating the work to the right machine. Yeah. I still think I appreciate that when

26:36 we created the builder earlier. I don't so it's actually every time you create a Docker build cloud builder, it's creating a two node setup for AMD sixty four and ARM 64. Is that right? Correct. Yep. Okay. Yeah. Okay. So, yeah, we saw that the ARM 64 was cached, but the AMD sixty four, since I I haven't done one of those builds locally, okay, that took, you know, about twelve seconds to do the the whole build there. And for both architectures, including image pools and everything else, and and pushing to to Docker Hub in thirty seven

27:09 seconds. So, yeah, not too bad there. I like it. Yeah. So you you mentioned also or we talked about GitHub actions for just a second, so I can segue to that for and show for this particular project. I have a GitHub action, and all I had to do is and and this looks pretty consistent with what a lot of folks will have for a container image build using the the Docker action. So, you know, I log in to Docker Hub, and then a lot of folks will have this set up Buildx, especially if they're gonna

27:13 CI Integration (GitHub Actions)

27:44 do multi architecture build. The only thing I I had to swap out here, and this was from a previous demo, but I specified, you know, the driver for Buildx is gonna be cloud, and then here's the the endpoint. Now in this particular case, I would have, you know, Docker slash DevRel if I wanted to use the same builder. Thank you, Copilot, for giving me a suggestion. That is not valid. And and so now if I were to build with, you know, commit this and push it, my GitHub action would use the same builder that we were just building with here

28:15 on on my local machine, which means my CI pipeline gets all the same caches or will populate caches, etcetera, and leverage that same builder. And then I can do, again, the the native multi architecture build, and it's gonna use those native nodes. So now in my GitHub action, it's no longer going to be, you know, emulating those. And, actually, if I jump over to the browser here I know this was a little while ago when I did the builds, but this first commit was not using Docker Build Cloud, and so the build took about three minutes

28:50 because, again, it had to emulate everything on the ARM side of things. While once I used Build Cloud, it it dropped the build to about twenty six seconds. And, again, for just a little sample React app, that's a pretty significant savings. Now I know you've been, you know, talking about Rust projects and whatnot, and so, yeah, the more complex the project is, the more you're gonna see the benefits that come out with it. So and it doesn't take much config. It's just two lines of additional config I had to provide. So Alright. Well, I mean, I I don't think

29:21 Pricing and Tiers Explained

29:23 there's any doubt in my mind that people are watching this and going, I don't want this. Like, I think this makes a lot of sense to personal developers, hobbyists, as well as teams and enterprises. So why don't you leave the bad news on us? How much does it cost? Yeah. There's always that question, So I'll jump back to the product page, and and so what we've got is there's a a couple different tiers here. K? And so there's the personal, and then you can actually see the the different builder sizes. So, again, these aren't different sizes that you can

29:54 choose from. It's basically you're you're gonna get the size for the the different tier that that you've got right now. And and so you'll see, okay, even for personal, it's eight core, 16 gig of RAM, and then it changes once you get up to the team. Everybody gets the the native AMD and ARM builders, and and the way that billing works is by minutes of usage. Now the the the one caveat I'll mention is when you're doing multi architecture builds, since you're building on two nodes, even if you're you're taking one minute, if it's multi architecture,

30:26 that's technically two minutes because you're using it on two machines at at that point in time, so just be aware of that. And so you you get a certain number of minutes. You can buy additional minutes, and then there are kind of throttles for the number of parallel builds based on the the tier that you have, and then you can purchase additional minutes as well too. So and all of the pricing, everything is is on the let's see. Let's actually go up here. Go to my personal one here. So, yeah, as of right now Now you can start turn free.

31:07 Yeah. So as of right now, we're we're trying to encourage people to to try it out. And so so, yeah, the starter again, fifty minutes will go really quickly. And so, yeah, you can try it out for free. And then from there, the team the the build team, Build Cloud team. Gosh. I can get words right. It starts at $6 per user per month, and then that gives you additional two hundred minutes, and then you can buy reserve minutes that then let you kinda pull those minutes and whatnot. So Okay. Alright. I'm gonna ask the hard question now.

31:39 Team Minute Sharing Clarification

31:43 Go for it. Well, this pricing is per user per month. Right? Now assume I'm on a starter plan, which of course, I think everyone should just go and try it because it's free. Right? Yep. Does that just mean I get one builder, or can I have 10 builders as long as I don't have over fifty minutes? I just So, yeah, we we do limit right now the the the free starter ones. You you get one builder. Oh, okay. We we thought about that loophole ourselves too. Yep. You you do just get one builder. And, actually, one

32:13 of the things I'll mention too is the $6 per user per month. Okay? So if I've got five users, yeah, okay, I'm I'm paying $30 a month, but each user gets two hundred build minutes. So I'm I'm actually getting a thousand minutes at that point. So you're getting 200 build minutes per user as well, which I know isn't quite crystal clear looking at this, but that's how that's working. Okay. Yeah. I think it's one of these things people can put their toe in the water, see if they get you a set of it, and then Yep. You know, $6 per

32:48 user. When you look at those charts over time and I'm not I'm not in sales, but I just see the the value here. But when you look at those charts, that that seems like a no brainer for me. $66 per user per month for all of those cool things that you're getting. So, yeah, I hope people And I had I had to find it, and so I I've got this for you just just to to have it since we talked about it earlier. So yeah. There's there really is an s k c d forever, but I I particularly love this

33:14 one just because throughout my my entire career, it's always been applicable to bar wanting to build and container energies, doing get ups, compelling. It's just Yep. Always there back at my mind. It's so true. Awesome. Alright. Well, let's give people in the audience a few minutes. If you have any questions, please feel free to drop them into the chat. I see that we have another one from Russell, so I'll pull that up in a second. I'm gonna move us back over to big facey mode. And before we get to any questions as the as the trickle in, as the trickle

33:27 Docker Future Roadmap & Vision

33:44 in, maybe you can tell us some super top secret things that's happening in Docker. What are we gonna see over the next three, or nine months? Yeah. Good question. So, you know, I I think as we started off this this conversation with, you know, looking for opportunities to continue and just invest and make things easier and continue to, I mean, add new products and and new capabilities to the the things that we have. You know, we we've we started off, you know, talked a little bit about Scout, and so I expect to see more in that

34:14 space and, you know, secure software supply chain. I know there's we've thrown out a couple teasers around container image signing and verification, so, you know, be on the lookout for for things in that space. You know, in the local development, we've we've talked a little bit about Docker debug and the ability to kinda attach debuggers and bring your own tools to images that don't have tools already installed in. And and I actually am a really big fan of that because that means my final production images can be really small, really lightweight without having to package

34:46 all my debug tooling into it, and I can bring it in along. So expect more in that space, how we can continue to help debug and troubleshoot. And then finally, just, again, thinking about this kind of, as I talked about earlier, RemoCal experience, you know, Build Cloud, you know, Build is just one area that, you know, we've we've been able to to make better, but continue to look more in that space as well too of how we can continue to to help just the development experience be a little bit easier. And and, personally, one of the things I'm

35:16 trying to to look for as well, especially with developer relations and training, education, like, how do we just make this whole space easier to understand and because there's a lot. It's there's a large mental model you have to have in your head even really just to get going. So how can we continue to make that easier for people? Yeah. You're right. It's a very volatile space. It's constantly evolving, and, you know, I feel like I have to really put in a lot of effort to keep up with all the advancements. And then, I mean, I think about the people

35:33 Discussion: Industry Complexity & Acquisitions (Testcontainers)

35:44 that are been in this business for less than three years or students coming out of university. It's a lot. So It is. And and, you know, and I didn't even talk about, okay, you know, the the atomic jar acquisition test containers, which I'm That was my next question. It's like Did you do it? Well, there's more than one acquisition. Right? I mean, was it two years ago? There was tell, you've got the test container stuff now, and I'm looking at this along with Docker Build Cloud. And what I see is a really compelling future for integration tests and CICD

36:12 and local developer experience, like merging composed with tell test containers. I mean, I would love to have all those people in one room and just watch them for a couple of days. I figured that would be super exciting. Imagine there's good stuff coming there, definitely. Yeah. And and I'm excited too. Even just actually earlier today, seeing some of the demos with what the test containers team is doing with some of these integration points and and everything. They're like, you know, there's things we thought about before, but now that we're under the same roof as the rest of the Docker

36:39 team, like, there's some pretty cool stuff. And I wish I could share more, but you'll just have to stay tuned. Awesome. Alright. Let's get to Russell's question. First, he says Docker Scout is awesome. That's awesome. Sweet. And then he says, I wanna I'm gonna put words in his mouth. He wants to understand how these minutes are shared at a team dynamic if someone is off on leave for a month in this five hundred minutes. Can you just maybe dive into that a little a little bit more? So so as of today, each of those users are are basically contributing minutes to

36:44 Final Q&A & Conclusion

37:09 a shared pool for that builder. And so, yeah, if you've got three users and each of them are bringing two hundred minutes or whatever, that that six hundred minutes shared for the entire pool of users for that that builder. So they're not carved out. Okay. User one has this much. User two has that much, etcetera. It's it's a it's a shared pool. Awesome. Alright. Well, thank you so much for taking time out of your day. Apologies to everyone who had to change stream that way through. I still have no idea what's happening there. But what

37:40 I'm gonna do is download all the bites from both videos, join them together, and then I'll reupload this as a single artifact. So yeah. Sounds good. Would be confusing for people later at all, but, you know That's right. It'll work. Any last words, anything you wanna share before we say goodbye? No. I just wanna say, you know, thanks for having me, and thanks for the the conversations and questions. And thanks for those that are tuning in and asking questions and kinda keeping us on our toes. We're we're always excited to to demo the things that we're talking about

38:09 and and and but also probably more important to hear the feedback of, like, what would you like to see? What would you you know, what would actually help solve your pain points? So keep that coming along as well too. And I see Russell put in, thanks for the demo. It was great even with the light themed IDE. I get it. I get it. I I I'm personally a dark themed IDE person, but I have found that when it comes to presentations, I think the light screen the light themes tend to give better contrast for screen sharing and projection and all that

38:38 kind of stuff. Yeah. I'm starting to yeah. A person follow my system. So during the day, I typically have a light themed IDE. And I think for the first time in years, I streamed at lunchtime, like, two weeks ago. And the first comment was, can you use Docker? I'm like, actually, I'm trying this thing where I just let the computer decide what's best. And I I'm enjoying it. I'm liking the the change. So, anyway Yep. Yep. Absolutely. So thanks again. It's been a pleasure. Yeah. Thank you so much. As everyone watching, thank you for tuning in. Thank you for your questions,

39:10 and we'll see you all next time. Have a great day. Alrighty. Thanks all.