 Well, thank you very much for making that less loud. This is about how much I talk and I yell, I have children, I have a wife, they all need yelling at. You know that's not true. Yelling at children doesn't work. I have, I am not, this is the core update track. I will mention in a minute that I am not one of the members of the core team. I have the wonderful opportunity to share with you the status of where we're up to as a group and as a user base because when I started to look at some of the new stuff that's in Bosch at the beginning of this year, so February, it happened to be in Toronto and I met the core team and they laughed at me for not using some of the new Bosch 2 stuff. You know, you sort of get used to it, like all those hard bits you sort of find your way around like every software we ever suffer through. And I finally sat down and I started looking at it and it was just so exciting. And so this year has been a wonderfully, a year of renewal for me and my love for Bosch and what it can do because I've been at this for five years of using it. And so I was pretty excited to be able to share. And this is my sort of way of looking at where we're at, like is it simple and specifically bootstrapping. A little bit about me. Prior to finding Bosch, I was VP of Technology Engine Yard and when I wrote this slide, I didn't know that I would say all of this on stage early this morning. But anyway, it's still true. And so while I was in Engine Yard, I was looking for solutions to the problems that we had, even though they were poorly defined and we were scratching, both a configuration management problem, a provisioning problem. We were thinking about being multi-cloud but we really had no way of doing it. If you've ever written any software where you have the idea of being multi-something but you really wrote it for one thing, you have no abstraction capacity. And so we had all these subtle, even though we worked on Fog, which is like a Ruby cloud library and Fog was multi-cloud, in so many small ways Engine Yard's product was like Amazon specific. And so it's going to be a big project. So I was pretty excited for anything. And it's interesting. 2012, Bosch came out, 2013, 14, 15, 16, 17, nothing else has come out, really. It's pretty incredible that I can still, with the same enthusiasm and unison, kind of like a multi-level marketing thing, it's like it is now is the right time to get started. You were not too late to get in on the ground floor of Bosch. So later that year I started a consulting company and through to the, you know, basically it's more representative of the excessive cloud foundation, the foundation, Pivotal and my customers that we grow and start growing as a list of lovely people who make me very happy to know them and work with them. And through all the things I do professionally as a CEO and still use Bosch most days, because why not, except when I CF push, because ideally you don't use Bosch. Like as much as I love it, you shouldn't use it. There's a takeaway just in case you want to change rooms. Like don't use it if you don't have to, like CF push, CF push is awesome. I'm going to talk about the book we're writing. I say we because that makes it sound like someone else might write some of it. That would be awesome. Like while I'm here, like three new chapters. This is incredible. The book I started writing and when I converted it from a big long read me on GitHub to a web app, that took an hour. And then it took an hour to go and get a DNS from being a simple to set up Cloudflare for the setting up the names of everything and see if pushing to CloudFantry. Like I did not deploy the book about Bosch on Bosch. I'm sorry if that hurts any of the Puritans in the world. Like, you know, use the right technology. But I still, for everything we do, there's so many things we do with Bosch at Stark and Wayne of Customers. A bit of an overview. This is what we're going to do. We're going to talk about what it is. Why is it hard to bootstrap Bosch as opposed to distinctly using it? Why this is a topic's interesting. What is the history of how hard this has been? And is it any better yet? All right, why Bosch? It's kind of a rhetorical question perhaps. But if you were given the task of deploying CloudFantry and you had your own set of things that have worked for you, you're a professional, it's not like you had a history of failing. But in your world, you'd been successful. And someone said, we want to run CloudFantry. Well, we have a 28 VM footprint. What was your plan? Was your set of tools for doing it? Now you might set up configuration management, certainly back in the early days. CloudFantry was configured and described as chef. But what about upgrading? What were you going to do about that? And then what about scaling? And then, I guess, the big one, and this is super exciting. And scaling, upgrading isn't just about the software, but those OS patches that are super popular. You know, I mean, here's American news right now. Trump did something stupid. Trump did something stupid. Trump said something stupid. And American businesses leaked all your data. And then Trump did something stupid. But other than that, that's pretty much the world news right now if you can sort of stop reading it. And so Bosch allows us a whole tool chain to help us, you know, survive this era. Obviously, there's more to it than where the fixes come from, all credit to Canonical and the rest of the ecosystem for the very open process of notification of bugs, of resolving them and then pushing them out. But it's irrelevant if Canonical patches things and then you don't push them out to your system. As Chip said that we have, and through the Bosch part of that life cycle, the Bosch call team within 48 hours will have CVEs pushed out into new stem cells. Means nothing for you and your customers if you don't push them out. So, you know, it's still your onus to do this stuff. But, you know, with CI and everything, this becomes really simple with Bosch. Anyway, resurrection, if you lose machines, or you don't know how Bosch works and you think, I'll just shut them all off and save money. And then three minutes later, they're all back again. That's highly entertaining. Or worse, you don't find out about that until the morning. Because, you know, why would you wait around to find out if they're going to come back again? So, this for us, if we solve all these problems with Bosch. I'm going to look confused at the moment about the logo. There is this new logo. I'm not sure if that's the logo for Bosch, or if that's the logo for Bosch, or perhaps if this is the logo for Bosch, or that one. I don't know any more. I'm pretty confused about branding in general. So, here's how it works if you're learning and you're new. And you really, I mean, like anything, you don't need to know how cars work to use them. You shouldn't need to know how Bosch works to use it. But it can be helpful to understand. So, when we do a Bosch deploy, we upload a bunch of YAML to an API with a director. It then hands it off to the CPI, which currently is like a little CLI sitting on the same machine. So, it's just as a call out, gives it some JSON. That may change in the future, but that's how it works now. The CPI has all the behavior specific to the cloud of your choice, from where you find your bespoke VMs, of which we have many. The ones listed there are mostly external things, and we'll get to the Bosch light story in a second. That cloud will then give you the VM of your choice. Okay, there's more arrows, but it calls home, says, hey, I'm here. The Bosch director starts telling it to do stuff. We have an agent on that machine. The reason we have stem cells is because we want there to be an agent and monitor and a few other things that we expect there to be there, in addition to, that allows us to have that whole security story, and it will then go and fetch blobs and move on with this life. The bootstrapping story is actually very similar. We have a local CPI because we don't have a director yet. This is the bootstrapping problem. We'd love to use Bosch to deploy Bosch, but we don't have a Bosch to do that, and it gets icky at that point. We lack the purity of an Ubuntu-based machine with Bosch running on it to do all its things. We have whatever's on your laptop, and I'm pretty sure your laptop's different from my laptop, and so a whole bunch of work recently, the last few years has been into the external CPIs, which are allowed for local CPIs, and we'll get to it soon, but the local CPI will talk to the same cloud, bring up that machine, and a variation of that story takes place. The machine that Bosch is running on is the same stem cell-y type VM that Bosch will later on use. So what is running on a Bosch VM, the Bosch environment, as we're calling it now, is deploy kind of the same way we deploy everything else, and you can debug Bosch the same way you debug the rest of your stuff. It's just job templates running with packages that came from a Blobstore. But this problem is the story of getting all this done is the hardest thing, I think, in the world of Bosch, because at this point, if you're doing this, you don't know everything. You just can't download Bosch and have fun. We do have a Bosch Light Story, and so you can do that, but if you were gonna get started with Google or Amazon or whatever, there's all this other stuff you need to know or set up or prepare. That's often the boundary of organizations and often, sadly, even now, there is still territory of who owns what, controls what, and you come along and you say, oh, we're gonna use Bosch, and we're gonna build all our VMs. There's gonna be someone in that organization that says, buddy, what? I'm the VM guy! You come to me, I'll get you some VMs, and then you can do whatever on it. Or there's a networking person. They're my favorite. They're all sociopaths. They may get paid by your employer. I don't know who they all work for, really. Masons, I don't know. My favorite joke, there's many jokes about networking people, but this is like their tagline is, my job's not done till you can't do your job. And they'll just turn off stuff that they don't know what it's for. And software's hard enough to rise as it is, let alone, we write software thrilled that it works at all. What we don't write software for is, like if case is just in case some idiot networking person turned off a port and now it doesn't work anymore. So when networking doesn't work, life gets sad and hard to debug. And this is the whole story that Bosch sort of owns. We sit on the boundary of these old ideas. We've still got networking people literally touching things. There's Terraform fellows, ladies and gentlemen, any networking, I'm not sure the sex or the species of networking people. But please networking, if you know a networking person, please sit down with them, explain professional software development, and get checking in your work, audit trails being responsible for the outcome of your company. So anyway, this is where Bosch gets hard because we sit on the edge of this. On the flip side, and this is the whole Cloud Foundry story, like we are the last people to have to deal with pain in IT. Because everyone that uses our stuff, anyone that uses Bosch doesn't have a whole lot of pain to live with anymore. Anyone that uses Cloud Foundry, these people that use Cloud Foundry will never know what it's like to ask for a domain name and SSL and then wondering what happens next. When's that person gonna get rid of my certificate? And when are they gonna set up DNS? Like, gotta find the person, I don't know if you remember what it's like, to find the person that knows where the binding machine is. So set up, we are the last people to suffer, which is sad because we're the ones suffering, but we are the last ones. So this is what makes setting up Bosch harder because networking people. Anyway, bootstrapping. So I can't say that the story around the rest of the world has gotten easier. If anything, you go back five years, Amazon had its classic networking. That was cool, you know, you just bring up a machine as an IP address and life is good. I don't know why subnets is better, not as a human being. I don't, and OpenStack had Nova networking and now they have, shit now I can't remember what's cool, but they're more complex networking. It doesn't make me feel any better about the world. Anyway, all right, but Bosch itself, this is the story. When Bosch came out, if you wanted to get started with Bosch, Bosch is the director's written in Ruby. There was a Postgres, there was Redis at the time, there was a health monitor, there was a bunch of software. It was just software, and some software the Bosch team wrote, and some software the Bosch team didn't write, which is pretty much described as computers. And just as there was a Chef cookbook, that was in the root of the Bosch repo, and you would bring up a machine, I don't remember using Knife or however we did it, and you'd run the cookbook and it was Bosch. And then you would use that machine, which run like Bosch, perhaps to deploy, because the Bosch team would then want to deploy their Bosch release for Bosch, and at this point it gets really complicated. So now we're using the Bosch deployed by Chef, perhaps to deploy another Bosch, which we might then use to deploy Cloud Foundry. And that idea, as we go through this story, didn't go away for years, even though it really just comes from what we wanted to, it's really a developer of Bosch story as opposed to us. We don't have to do that. If your organization is using a Bosch to deploy another Bosch, you can stop doing that, tell them I said so. So 2012, 2013, the bot core team started to make a thing called MicroBosch. And thus starts the story of convoluted language and misunderstanding. MicroBosch is the Bosch micro deploy. This is the story of the CPI coming onto our local machine to spin up the machines, and it was a different code path, even though it was written in Ruby, it was different from the director, even though we did a lot of the same stuff. It was hard to maintain. We had the complex stem cells. The CPIs were baked into the core of the project, so if you wanted to add another CPI, it was, you know, basically told you just don't. It was really hard. You know, there's some old stem cell projects, which are CPI projects, which literally were forks of all of Bosch just to make them work. To my mind, happy times came when we had vagrant up. Now, unfortunately, vagrant up was just for Bosch light, but vagrant up and you had a Bosch, and you could deploy things. It was awesome. Not 100% sure why we didn't have that for all uses of Bosch. That's kind of cool. Bosch up provisioner, AWS. Bosch up provisioner, Google, could have been done. I only thought of it while I was writing slides, so it's not fair really to criticize. I'm not sure what the reason that I could ask Dimitri and the others if they ever thought about it. And about 2014, there was this terrible blight on our profession, which is, as I discussed this morning, it's like, why didn't you do it in Docker? For any topic. I'm going out for lunch. You're using Docker. It's like, settle down. It's getting a sub. But I do want to quickly cover this with some pictures. All right, so this is Bosch. This is the, in Australia, this is the, as I learned it, the food pyramid of healthy living. If you eat this way, you will live a long and happy life. I assume cigarettes are not part of it, but it doesn't say explicitly. It says no salt and sugar doesn't say, you know, other stuff. So anyway, a lot of vegetables, they're very good for you. You've got some grains, you've got some milk, dairy products, you should have some of that, but not too much. And obviously you want some healthy fats, but you want to avoid sugar, and you want to avoid salt. That's the healthy food target. And if you eat that way, you will live a long, happy life. You might want to also exercise, not watch a lot of TV, don't read the media, and there's a bunch of other things. Try not to put social media on your phone. That's not part of the healthy living food pyramid, so that is one of the other pyramids. Anyway, this is Bosch, metaphorically. If you build, use Bosch, you have a healthy food pyramid. With Docker, it's more like, it's really sweet and it's available everywhere, but you know, I spent many years making fun of other people's products and really shouldn't, you shouldn't. I was wrong. I had made fun of Chef earlier today, so it was only fair that I picked on someone else. And if we talk for long enough, eventually I'll get to Mongo, and then I should be spent. Anyway, and then 15, we had Bosch in it. So Bosch in it was, we rewrote Bosch, it was almost, it was the beginning of the move to go CLI. I don't know if you've ever had to, you know, last year, if you downloaded the Bosch CLI, you didn't get to just download the Bosch CLI. It's actually a lot of fun to take a normal sysadmin type person and say, all right, I want you to download the Bosch CLI because you need Ruby. And that means they're gonna try and find out how to install Ruby. And let me give you a clue, apt get install Ruby, that's not the right way. Friends don't let friends install languages with package managers. It's a long quote, but it's, it's, you know. So Bosch in it deploy was the start of external CPIs. So we started to get more clouds at this point. And life started to get a little bit better. So where are we at now? Aside from the year being very, very large. All right, so now, if you go to Bosch now, we have a new Bosch CLI. You no longer use the Ruby CLI. It's no longer called Bosch 2. Bosch CLI is Bosch. And every command you'll see, me type will assume you're using Bosch. We'll still call Bosch 2 just to make sure it's clear, but we'll perhaps call the old one Bosch 1. The Ruby Bosch is gone. Bosch in it is gone. What was in Bosch in it? So we've got merge and can you see a lie? We have a new project. And fundamentally, this project, the Bosch deployment repo, is kind of the basis of what I wanted to share and what it's arguably made, owning and operating Bosch simpler. And then the jumpbox deployment. I'm not gonna talk about the jumpbox deployment again. I would like to, except I forgot. And I'm just thinking about it right now. I should add more slides. But the same way that we do Bosch Create Env to bring up Bosch, it doesn't have to actually run Bosch. You could use Bosch Create Env and run nothing, which is code name for a bastion. So that's another path. How do you get that first machine? We always have the inception problem of where's that first machine come from. And if you create bastions with whatever your favorite way of creating VMs is, you'll have all your favorite problems of owning and operating infrastructure for the rest of your life. Ages, we wanna patch it, all that stuff. If you create your jumpbox with the same tools that you use to create Bosch, you can upgrade it and make it healthy and happy. So there is a project called jumpbox deployment, but I'm gonna spend all this time talking about Bosch deployment. All right, this is it. This is the excitement. And if you've ever looked at this stuff, you might have, with one eye closed, copy and pasted some examples, you might not have understood what's going on here. And so I'm gonna walk through it and you're gonna come out feeling like you actually know what's going on and feel good about it, without showing you the YAML. That makes everyone sad. And YAML is the sort of thing you put on a slide, basically to put a wall somewhere down the room because the YAML has to be a certain font size and that basically says, all right, about the middle, anyone forward of that can see my slides, anyone back cannot. This is the YAML separator of the audience. And I don't wanna do that because some people just like seeing at the back. And they should be allowed to sit at the back and I shouldn't use YAML as a way of making them feel bad. All right, so the Bosch.YAML file is like a base deployment manifest. I'm gonna take a little tangent. All the repos that, because we're not gonna talk about using Bosch for the most part in this talk is bootstrapping. But a lot of the CF deployment repo is a wonderful canonical example of where we're going with Bosch projects that you know, you're Bosch deploy them. Bosch deploy CF deployment.YAML needs one variable and it just works. It is awesome. Now there's a bunch of little operator files that modifies it, but you don't have to. We're moving to a world where we just want new people to have success and then iterate towards what they might want over the long term as opposed to having to come up with a complex convolution of properties and which is in every ecosystem a problem, defaults versus explicit. Bosch, we went down a long path of being explicit thinking we were right about that, but then no one could figure out what was going on. So now we have a lot of defaults, things that just work. And so similarly, Bosch.YAML is a pretty good starting point for deploying Bosch, but you need a couple of other things to add into it. One is we need to pick a CPI. So there's a bunch of subfolders for every different sort of cloud provider interface, CPI, Google, AWS, Azure, OpenStack, FeSphere, and then the local ones, VirtualBox, Docker, et cetera. You pick one of those. Now at this point we start to need to know a little bit more because the simple stuff you need to know like, what's my password to my cloud? That's got to go in there somewhere. Or if it's IAM roles or service accounts, what's the reference we're using? And networking, we're gonna need to put that in there. We'll get back to that. So next, we have this inception problem of where does state go? The world doesn't exist yet. I can't put my state about the world, into the world, the world doesn't exist. So that state is gonna go on my laptop. Where it goes from there is kind of a team issue. Do you put it in Git? Do you refactor it into something else? But initially it's gonna dump it onto that machine and use it to manage that. This is why you typically put this stuff on a shared jump box. So the team can come to this and iterate. Or you manage it through CI. Another cool thing that came out in Bosch too, you might hear more about it from the sort of the cred hub story of managing configuration. You might have been the type of person that wondered why did we make cred hub when Vault existed? I don't know either. Bosch, CLI, has some of that functionality inside it as well. So there's a whole bunch of variables in the bosch.yaml and the cpi.yaml that you just don't care about. You want a password for the director. You do not care what that password is. Just make it for me. It's the cred hub haiku. I want other people not to touch my stuff. I don't care how. Please don't touch my stuff. I don't know. I don't know how to do haiku's. So that cred.yaml will be a bunch of generated credentials, certificates, and other things. And again, you might want to put that in a Git repo in parallel. And then the variables, minus v, and there's another flag for options. And that's going to be what my networking is, any names, any credentials, sorry, cloud credentials. I can't randomly generate a A to S password. All right. Once we have our bosch, you will probably want to use cloud config. This is how we're going to make using bosch easy for everyone else that comes along. The cloud config is going to describe your networking, the set of VM types you're happy for everyone to use. When you think of it that way, it's kind of like, please don't use GP2s and anything really expensive. But anyway, that's kind of it. Here's the set of interesting VMs. What did I put at the bottom there? Very simple to add. We'll come back to that. Sorry, that's an error. And we'll come back to that slide soon. All right, so that's the normal bosch. So we use bosch createM to bring up a VM on Amazon. And inside that VM, we'll have the CPI for bringing out more stuff on Amazon. This is two CPIs. And this is where it gets not simple. It's like, if I don't mention it, the sound is simple, right up until I want to introduce Bosch Lite. So there are two CPIs. The one on your local laptop or your jump box, which we'll talk to Amazon, Google, VirtualBox. And then the one that's inside the director, which we'll talk to Amazon, Google, Docker or Garden or whatever. All right, and that's the main distinction. So Bosch Lite used to be that idea but hidden inside of a vagrant image. But we have some blog posts on this topic. We've done this for years. We run Bosch Lite on vSphere using another Bosch. So we run a fleet of them for our CI and everything. Bosch Lite is just running Bosch with a different CPI to the provisions locally. We hid that all behind vagrant up. Now, vagrant up was fantastic except you didn't learn anything. You could use Bosch Lite all you liked. You hadn't learned a thing about Bosch. So that's all gone. There's no more vagrant up. Bosch Lite is just a variation of what we just did. So we're gonna have a local CPI for Amazon, Azure, vSphere or VirtualBox. And so the VirtualBox CPI is the replacement for the Bosch Lite story. And then when we bring that machine up, inside it will be a different CPI. That will be either Run-C, GrootFS, Docker. And that's what these other manifests you basically pick and choose what you want. So there's a base one called Bosch Lite, which is kind of like a CPI, you know, changer. So because we now need two CPIs, we need to pick a CPI for where the host machine is gonna go that will run Bosch. And then we need to change the internal CPI to be some sort of container system. And you just pick one of these. That's probably, you'll copy and paste it from somewhere. But at least now you can kind of understand what these are for. All right, and then there's gonna be variables, et cetera. And so here is the example. If you go to Maria Sharapova's, I feel like I've just mispronounced her last name. Is that correct? No, Maria, if we all think so, except it's recorded. Amiria, if I mispronounce your last name, sorry. Shouda Binye, yeah, sorry. She has a, if you go to Bosch.io, at the top there's like a guide. This is, you know, her guide has been updated for Bosch 2 and has this in it. So it kind of looks long, of which I can't apologize, it just is. Because there is still some sort of virtual boxy type things we need to describe of how we wanna post it on your local laptop, IPs, et cetera. But you're learning more about Bosch while you do this. And to my mind, that's better. All right, so this is Bosch Creative. Now watch for the subtle distinction as we update it. You change the background color of your terminal. It's always very important. And then you remove all the bold. And that's it, it's the same thing. Because the only thing you've probably done is you've done a Git pull on the Bosch deployment repo. That'll have some new manifests, which reference new Bosch releases, new CPI updates, new versions of Bosch, new versions of Credhub, whatever. Although I haven't got Credhub yet in this example. But any of those things are just managed by the Bosch team. You could so easily put this in CI. And then deleting it is literally taking the exact same expression and changing from createMf to deleteMf. There is, okay, so at that point you start to wonder, why do I have to remember all these flags? That's a really good conversation that we're having of that URL. It's not obvious why we can't just get rid of the flags, like where do they go, who has to look after them, how do you know what you actually did. But so one of the sort of wrapper solutions is to whatever works for you to make your Bosch, put it in a shell script, and now you own that expression of how to manage yours. So Git pull on Bosch deployment, run createMf up you go, works a treat. It would be nicer if we had this update command, but there is no obvious understanding that we'd all share on what that means. All right, you will hear about Credhub all week. And you know what? It is easier to add Credhub to Bosch than to live without it. It is easier to add the UAA and all the flexibility of teams, even if you never use them, than to make their distinction and not use it. So it does two YAML files, just throw those in and your Bosch will be updated to have, like even if your Bosch now isn't using Bosch deployment repo, you're doing it the micro Bosch way or the Bosch init way, you just replace it with this and it'll just update. And then you can start adding UAA and Credhub. The Jumpbox user is I guess a new distinction of what is the user password or the key to be able to SSH through the Bosch and get out to the other machines if that's what you want, or how to SSH in the machines. And again, you just throw it in there and you'll have a gateway user set up for you. Another approach which we've been toying with is called Buc, I'm a bit of a fan of this, so I do want to share it because if you sort of see that, you might say, is there another way to do this? And so Rubin and Rahman and Justin, a few others have been working on this. It's called Buc and it's an acronym for Bosch, UAA, Credhub and Concourse, which is perhaps a new idea. You might say, well, why would I put concourse in Bosch? And here's an idea. Perhaps users should not be running the command Bosch deploy. Perhaps users should not actually be typing CF push. Perhaps only CI should be running those things. But if we make CI this other thing you have to do, perhaps you won't get around to it. So what if we just make CI a first class right up front citizen of your entire universe? And so concourse is included so that you're encouraged to move straight to using CI. And like it just wraps up these ideas. So everything we just talked about is sort of encapsulated in this Buc up, white command, and then yeah, you get your shiny virtual box. There are CPI support looks very much like. And so either you can live with Buc entirely for forever or you can use it as a getting started point. As you start to learn Bosch and start to feel comfortable with what's going on and then you can have to unwrap it if you choose. And then it has a bunch of other helpers to set up Credhub, to set up the concourse fly, et cetera. So I like it and I've started using it and but I will never forget how this all gets built. So I guess back to the topic that you've all wondered is it simple yet? It's like well no networking people are still employed. Bosch doesn't solve that's out of scope. As much as the broad scope of Bosch is, the unwieldy scope, it does not manage destroying people's LinkedIn profiles so they're only employable. Never thought of it that way but it's probably a Bosch release you could make. But it is literally, you know, it is mentally simple to think of it as like this layer plus this layer plus this layer and you could put anything else, you could put monitoring, et cetera. And then using Bosch after you added your cloud config is so easy. Bosch 2 links, the cloud, sorry, yeah, the cloud config just make Bosch so simple to use. And a lot of the Bosch releases are becoming simple. CF deployment, Kubo is pretty simple. They'll get rid of the wrapper script so it sort of makes it more obvious that it is simple to run Kubo. And so yeah, I'm very excited about that anyone who comes to Bosch, they might not need to know what we just talked about but if you give them a Bosch, show them how a deploy works, you'd be incredibly impressed by how fast they become productive as they're still learning, perhaps the nuances. A writing book. There is no segue. Let's practice the segue. No, I got nothing. So I mentioned this before earlier this morning. So I became excited again about the idea of re-explaining what I love and how I imagined this to be learned. This is, whilst gloriously titled The Ultimate Guide to Bosch, what my dear hope is, is the start of a continuation of other people writing their own way of explaining it. Because when I went off to learn really complex things like making the blanky light work on Arduino's or to understand neural networks and try to figure out how TensorFlow works, which I still don't, nor did the lady talking on stage, apparently. That's cool. So what I really appreciate was a diverse ecosystem who all were having a crack at explaining something. And so I do want to do videos because that's kind of where my motivation came from but I did start writing this. And I hope that it, you know, useful to you and your team. We start with talking about deployments. It assumes you already have Bosch. So I skip the bootstrapping thing because it's hard. It's simple but it's still hard and it's where you might lose people. So let's just assume you've already got Bosch. Let's assume that's all working and let's use it. Let's debug it and then we'll come down the stack. So that's the approach I'm taking. Super happy, there's lots of people who've made little help fix most spelling. There's a couple of hard line issues. We are using British English because it is the best English. A lot better than Trump English, which is every sentence just, you know how you have like the active, passive grammar checker? I just had this idea earlier of the grammar, of the Trump grammar checker, which takes any sentence that says, you know, that sentence isn't enough about you. You should change that sentence. So it's like a personal story about how you're awesome. And that would be the Trump grammar checker coming to Microsoft Word soon. And the Oxford comma. That's about the only major constraints that we're going with to pass on proper English to you fine folk. So hopefully that's useful. I'm very excited about Bosch. I always have been, but you know, we do come and go from things. But what I've seen and what the core team's doing and the new, like the velocity that they've had this year has been inspiring. So if you've not been playing with it or you've just been using whatever's lying around in your team, I highly recommend looking at upgrading all your Bosch's, bringing Cread Hub and moving to a wonderfully more secure environment. So thank you very much.