 Sweet. All right. Hello, my name is Kira. I work for Pivotal on Cloud Foundry, and I wanted to tell you about Bosch, which is a simple solution for complex systems. What this talk is going to employ is it's going to give us a view of how complicated doing deployments is. Like, you have your component, you have your product, and it's really complicated to have to deploy that, and then how Bosch can help you simplify that and make it a solution for that particular problem. All right. So first thing I want to talk about was the old world. So you're like, great, I have my product, and I want to deploy it to one of these different platforms. I want to deploy it to AWS, Azure, OpenStack, whatever. You're like, maybe I want to even deploy it to Docker. But you're like, how do I do that? So you have your first component. So you wrote a little bit of code. You're like, great, I'm going to put that on an AWS instance. That's running. And then you're like, oh, but I have another component. So you say you write a little bit more code. You're like, great, now that's running on an AWS instance. And then you realize you have a lot more components than they need to talk to each other. So pretty soon, you're writing code, deploying things to all these different AWS instances, and then you have to make a change. And you're like, oh, crap, was that component one? Was that component 27? Was that component X? Is that even on AWS? And it gets really complicated really fast. And then when you have to manage that, say if you were using AWS, you have to go in. You have to look at this lovely page here in EC2 instances. You have to use ES3. You have to use the AWS CLI. And it's really, it's just a big pain in the butt. I've had to use it myself, and I hate it. And I'd much rather use something else. That's something else. I'm sure you've already guessed, is Bosch. So the big question of the day is what is Bosch? So Bosch simply stands for Bosch Outer Shell. It is a tool for release engineering. It's really, it's useful for doing deployments. It's life cycle management. What's great about Bosch is that it supports all these different IaaSes. It supports like Google Compute Engine, AWS OpenStack, VCloud, Apache CloudStack. It supports all of these things now. And it was used originally to deploy Cloud Foundry. I mean, you're all here, you probably know, if you've ever tried to deploy Cloud Foundry, you would have had to look at something called Bosch. But what's really cool about Bosch is that it's not just for Cloud Foundry. You can use it to deploy things like RabnamQ and Hadoop. Or you're just like, OK, I don't want any of those things. I want to deploy my own thing. And what's cool about Bosch is that you can use it for that too. So what are some key principles of Bosch? The first of these are the identifiability. So this means you want to be able to identify all of your source, your tools, your environment. And you want to be able to see all of these things that make up your particular release. Once you get that, you want to be able to reproduce it. So Bosch allows you to say, oh, I have all of these configurations. And you're going to deploy it to like OpenStack or AWS or whatever. And I want to be able to do that again and again and again and again and again. I'm not going to give it to just one customer. I'm going to give it to multiple customers. And Bosch gives you the opportunity to do that. But more than just being reproducible, Bosch is also really good about consistency. So you're going to reproduce it multiple times. And you want to assume that when you reproduce this multiple times that customer A isn't going to have some different weird configuration compared to customer B. And you want to make sure that you're getting the same result. What's great about that too is not only is it identifiable reproducible consistent, it's also fast. Compared to that situation I described earlier where you have all of your different instances and you're just like, I don't know what to do. Bosch has it all contained. And it just says, oh, I'm done with the first step. I'm going to do the second. I'm going to do the third. I'm going to do the fourth. And you don't have to think about it. And Bosch is going to do it. And it's really useful on the software continuous integration. So what makes up a Bosch release? So you're saying, I have my component. I have my product. What do I have to do in order to get there? So a really easy overview of kind of how you envision Bosch is that you first have a stem cell. So a stem cell is a versioned OS in IaaS packaging. So you have your Ubuntu, you have like your Ubuntu AWS HVM, you have all of these different kinds of operating systems. And it's packaged in this little bare bones. It doesn't have anything else in it except what you would need in order to run it and install software or do whatever you would like. So once you have that stem cell, you build what's called a release. So the release is put on top of that stem cell. It's basically just a version collection of all your properties, all your configs, all your startup scripts, all your source code, your binaries, anything required in order to make your thing go. And then with that release, Bosch needs to know, hey, I need instructions for how to do this. So that set of instructions is in a file called manifest. And I'm gonna go into kind of what makes up a manifest later. That's where you have the most controlling power in Bosch. But once you have all of these things, all of those things together, make up what we call a deployment. And like I said, it has all of your configuration, your stem cell, pretty much this makes up like your product being on Bosch. So basically what you can do, you can take this whole configuration and simplify it down to like this simple command. That sounds really great and all, but the process to all of you or those of you who aren't familiar with Bosch, I'm sure is how do I get there? So I wanted to start with saying, first you gotta download the Bosch director. So you have to get your environment, get something that you wanna deploy Bosch with. So whether that's like AWS, even your local machine, Bosch allows you to do that too. And you have to install the Bosch CLI. It's very simple to find on the Bosch.io. If you haven't heard of Bosch.io, it's pretty much like the definitive source for Bosch. And I highly recommend it. They've got tutorials and such as well. They have a Bosch gem. So all you have to do is you gem install the Bosch CLI. You can install it with no RI or no RDOC. It just makes it a little faster if you do it this way. And then you create a Bosch manifest to deploy Bosch. So it's pretty cool. You can take this tar file as your stem cell and you basically say, hey, I'm going to deploy Bosch using whatever's defined in this Bosch stem cell there. So it's kind of like you're using Bosch to deploy Bosch and it's kind of like a mini Boschception. And then you can do all of your other, what you'd prefer to do. So I mentioned a stem cell and that it's, you know, just a version of OS. Why is a stem cell so interesting? So look at it from an example, say, if you're coding on a Mac, I code on a Mac. There was a scare with a heart bleed coming out. So you're like, great. Now, if I have to upload all of my like AWS instances, I realize Mac wouldn't be the operating system you would choose for your AWS instances. But say for example, it was, you're like, great, I have to go through and I have to upgrade all of these different things. I have like, you know, between 10 and 100 different instances. I have to do all those individually. Bosch says, you know what, you have this OS update and you have to do it on your Amazon instances. I don't want you to do that yourself. That's really lame. So you can basically, you can go to Bosch.io and pardon, download a new stem cell and in your Bosch manifest, like I said, I'll mention this later, you can have that new stem cell in your Bosch manifest and you can run that Bosch deploy that I mentioned earlier and it'll go through all of those instances, update each of them individually and bam, you no longer have a security hole and that's why stem cells are really useful, really awesome, pretty amazing. Now, since I already jumped the gun. The next part I wanted to talk about was the Bosch releases. So I'm gonna start off by saying, you wanted to create your own Bosch release first and then go into some of the more cooler aspects. So you created a new product, you're like, I wanna deploy this using Bosch and no, I wanna deploy it using Bosch, so how do I get started with that? There's a specific structure, don't know what it is. Bosch allows you this really cool command, you can do Bosch and knit release with the name of your release and it's gonna generate for you all of these empty files, like these folders are empty and there's nothing in any of these directories, but it says, hey, this is the format, this is what I'm looking for. So a quick rundown, so that Blobs directory is something that your source code would need to compile. So say you wrote a Java program and you need a Java server in it and it needs the JDK to compile. It's gonna work great on your local machine because you already have the JDK installed, but if you deploy it somewhere else, you have to think about, oh, well, how am I gonna do that? You use Blobs to do that. So you upload the JDK blob into that directory, it's gonna upload that to your Bosch director, so anything that's going to be deployed on your Bosch director now has access to that JDK and can use it however they want. So then a job, that jobs directory is going to show you all of the units of work that your deployment needs in order to run. So I had component one, component two, component three, you had all of your components. Those can be easily separated into, oh, I have job one, job two, job three and all of the specific configuration that you might have for all of those are going to exist in that jobs directory and you can define the startup scripts for that job and everything's just in this one easy place for you to access however you please. You can change it very simply, you just go in there, you say, oh, well, I wanna change job one, I'm gonna change that config, Bosch deploy and it's going to update that for you. So your packages on the other hand are all of the compiled code that you would need to have in your Bosch deployment and then of course the source directory is just gonna be your normal product code. So say you don't wanna create your own release, you're like, I'm using Cloud Foundry, I'm using console, I'm using all of these different things and I know that people have done it before so a place that you can look is the Bosch community. So if you go to Bosch.io slash releases there's a lot of pre-compiled releases that you can access and you can download and you can say, hey, okay, fine, I'm gonna Bosch create this release, Bosch upload this release and you don't have to deal with all of that tree structure or do any of that creating yourself. Again, once you download this release, you have it, you can fork it if you want, edit it and as long as you upload that to your Bosch director, Bosch knows what to do with it and it's like, hey, we're good to go. Now that we've talked about releases, I wanted to give a quick overview of the Bosch manifest because if any of you have worked with Bosch, you see this huge big file, this is not even like a third of it where you see like, oh, there's all these words is in this weird YAML format, what do I do with it? How do I parse it? What does all this stuff mean? So basic overview, you have all of your different components are separated into different jobs in your Bosch manifest. You have to define all of your configuration here. You have to define any properties that your component might have, any of the resources it might be using. If you're using AWS or some other thing, you'll have to define the IP ranges, you'll define the subnets, and you'll just define like anything that your product could need and that you would have to manage manually, you can define in here and Bosch will know what to do with it. So like if you say run out of IP ranges for your product, you can go into Bosch, make sure that you aren't using it for another product first and upload, sorry, change these IP ranges inside of Bosch and then re-upload and it'll read in those changes. So, quick rundown of, I'm gonna take a very simple Bosch manifest, like it's gonna just be, as you can see here, like it's very generic, it's not gonna deploy anything that you're familiar with. I tried to genericize it very much just to kind of explain what the different pieces were. So I'm gonna start off very obviously, you can choose the name of your deployment. You have your Bosch directory UUID. So I mentioned earlier that you're gonna deploy Bosch and when you target your Bosch director, you can run a simple command which is Bosch status, attack UUID and that's gonna give you back some kind of alphanumeric string like you see up there and you can simply take that value, put it in the manifest and then Bosch knows, oh, I'm gonna deploy to this Bosch director. So say if you had Bosch deployed somewhere else as well, you could take that UUID and say, I wanna deploy my component to this Bosch and then you can change this ID and say, now I wanna deploy it to this Bosch and as long as everything lines up right with the rest of your config, it's as easy as that. So then you can also define your release version. So I mentioned earlier that so this release version is the release that we created earlier. So you can view any of the releases you have available using this Bosch releases command and what this is gonna do is it's gonna give you a view of all of the releases you have deployed and not only that but all of the versions you have deployed so as you can see up here, I have CF deployed in my environment but I have all of these different dev versions and I'm like, okay, I was on this dev version and I faced a problem so I'm gonna try this older dev version or you had a customer on an older version and you wanted to simulate some behavior that you're seeing so you can change this dev version and then deploy it and then you'll be able to see actively what a customer might be using with that version of your deployment. Then the last piece is you have your resource pool. So your resource pool is gonna have a collection of all your VMs. They're gonna all be using the same stem cell that you define in your environment. They're gonna have the same config and say when you do your stem cell updates they're all gonna be able to be affected at the same time because they're all in the same resource pool. Apologies. And then finally we have our stem cell version which finally I've been talking about it all this time. This is where you define that. So when you get a stem cell update you download it from Bosch IO with the new stem cells you have a point version now because it's got a new CVE update. You go into this file, you say, okay, now I'm like 0.7 and then you have another update. Now I'm 0.8 and then you do a Bosch deploy and Bosch says, okay, I have this new stem cell now. I'm going to use this updated version instead of this older version and you no longer have your security hole. All right, next piece of the Bosch manifest. Just like I said, very, very simple generic. These are things required for like, kind of bare modes minimum for a Bosch manifest. You have to define your networks. So the thing about Bosch, you have to make sure that these networks are available. You can't just say, oh yeah, I wanna use this network here and then I wanna use this other project with the same network. It's gonna have to follow real rules if you were deploying manually. You can't have things sharing the same IPs they get angry with each other. But you just give all of that configuration here to make sure that they don't step on each other's toes. Then you have the compilation VM. So the compilation VM is you have all of your source code and it's dependent on a particular machine architecture. So you say you make a change to your source code, Bosch is gonna have to compile that into an executable and then inside of the Bosch deployment that's running, it's gonna have to be able to execute it. So these compilation VMs take all of that source code and do the compiling for you. And once they finish doing all that compilation, they're gonna go away. And then you don't have to have that VM living for very long. It's not gonna affect your cost or anything. It just kind of offsets the machine power to where it's needed. Last piece of this is we have what's called the canaries. So if any of you are familiar with the idea of canaries being brought into the coal mines and the poor coal miners didn't wanna die from the gas. So they're like, oh, we're gonna have these canaries die instead and then if the canary dies then we know to get out of there before we all die of inhalation. And that's kind of the similar idea with Bosch. So Bosch is going to tentatively deploy a component of your code and make sure that it doesn't just completely fall over and just die. And if it completely falls over and dies, this canary is gonna alert and say, hey, you did a breaking change. I'm not gonna actually deploy this to your product and I'm going to fail your Bosch deploy and say you need to go back and fix this. So if you deploy, say, bad code, you're not going to be having downtime for your customers because you try to push up a bad change that canary could fail and say, hey, go back and fix it and you'll be like, great. Now I'm not gonna have to worry about something else bad happening. All right, last piece of the deployment manifest is simple enough, your jobs are kind of synonymous with the components of your system. You have any particular config for how to run it and say you have each of these components, like component one and component two would share the same property. You can define that as a global property so if you're defining your job, you can say, hey, this is shared between the two of them, I'm not going to define it twice, I'm gonna use this shared property instead. So then if you had to go back and edit it, for example, you wouldn't have to change it in multiple places, you could just reference the one. So with all of this said, I've said Bosch is super simple and you can learn a lot of it and it's very powerful but I do have to give the caveat that there is a learning curve. Learning curve kind of looks like this. When I first started using Bosch and I work on Cloud Foundry, so I kind of use Bosch almost every single day, hated Bosch. You know, a little more time passed, still hated Bosch. Still hated Bosch and then I was like, eh, you know, it's Bosch. And then I was like, you know, this Bosch thing is kind of cool and now that I've used it, I'm like, this Bosch thing is the best thing ever. You can do so much with Bosch, there's a lot of configuration, you can just, I can't even explain to you how amazing I think Bosch is and I'd highly recommend that you go through some of the tutorials, go through some of the pain initially required with learning Bosch just to see how powerful, how amazing it really is. Another really cool thing about Bosch is that Cloud Foundry loves Bosch. Like I mentioned earlier that if you've tried to use Cloud Foundry, you've probably heard about Bosch and it's for a very good reason, like Cloud Foundry was built to use Bosch. So in order to deploy Cloud Foundry using Bosch, if you're doing it on your own, you can generate a deployment manifest, you're gonna upload a stem cell and then you can do Bosch upload stem cell, create release, upload release and deploy. Or as mentioned earlier, there was a nice releases site and you could go and say, hey, I'm just gonna download Cloud Foundry, upload Cloud Foundry and then deploy it and it's very simple and it saves a lot of time. All right, and I had a little demo about kind of how to use it, but in the interest of time, I'm going to skip over it. It's basically just a simple, how easy it is to deploy Bosch. You can find a very similar demo on Bosch.io. I'll give a link for the online tutorial at the end of the talk. So another thing that's really cool about Bosch is that it's not just used for Cloud Foundry. I mentioned earlier you can use it for like Hadoop and RabbitMQ, you can also use it for things like MySQL, you can use it for Redis, you can use it for React, you can use it again for Rabbit, you can use it in Docker, you can use it in Jenkins, you can even use it to deploy Concourse. And I also said you can also use it to deploy your own software even. So where do I find all of these things? You're like, oh, you're telling me that there's all of these releases for all of these really cool Bosch things. Where do I find them? I don't wanna have to figure out how I need to Boschify all of these products that we're already using. So it's really cool. The Cloud Foundry community is awesome for this. You can go to Cloud Foundry community, it's on Git, and you can see just pages upon pages upon pages of all of the different people that have already created these releases for you. And for example, I had to use Kafka for one of our products and Kafka is not on the Cloud Foundry community. So I'm like, great, I'm gonna have to figure out how to make a Bosch release for Kafka. It's gonna have to spend the time to do that. But before I did that, I went and did this. And so if it's not in the Cloud Foundry community, there's a really good chance that if it's something useful and people like it, there's other people who have made these releases for you and you can go in and it saves you a lot of time, a lot of work, a lot of effort and you can then just start using it. You don't have to think about it, you don't have to do anything else, it's just there. All right. And with that, I promise that there would be links at the end of my slide. Like it's got the Bosch online tutorial at the top. I really highly recommend looking through the documentation. There's the links for the community, how to deploy Cloud Foundry. Oh, and then there's this really cool thing I didn't mention called Bosch Lite. You're like, I don't wanna pay for AWS, I don't wanna pay for Google, I don't wanna pay for any of these services. How do I just test if I like Bosch? So if you go to that URL and type in Bosch Lite, you can actually get Bosch up and running on your local machine and deploy Cloud Foundry and play around with Cloud Foundry however you'd like. I can tell you I have a four gigabyte Mac up here and it's a little laggy, but you can do it. So highly recommend that. And with that, the closure of my talk and I'm open to any questions if there are any. I'm not sure how much time I have left. A really good number, at least from what I've seen, if you have a compilation machine for each of your components, it'll, it's useful for, so like, I'm sorry. For, let me rephrase. Maybe each of your jobs is a good number because like I said it compiles that source code and makes it executable on Bosch. So if you have a compilation machine for each of your jobs that are gonna have a different configuration and different executable, that's usually a good estimate. Say that again. I don't know if there's a tutorial for how to create your own stem cells. There is a list of all of the available stem cells. I didn't put it on here. It's Bosch.io slash stem cells. And they usually try to be very up to date with the OS's they support. But you could, if you wanted to create your own, you could try to ping the Bosch Slack channel and they might have more information for you. I think it depends on how much time you're, or like how much you're willing to invest in the idea that Bosch is a good solution. Cause if you're just like, you're going in and I'm like, you're kind of tentative about Bosch. It can seem like it's a lot longer, but cause I had to use Bosch every day. I'm just like, I was very frustrated, but I started to see the same problems. And if you're with somebody who's used it, the Bosch channel is a good place to check or you could check other online sources as well. I've Googled a lot of problems I've had with Bosch before and you're able to find relative solutions. After that, like using Bosch is easy, but mastering Bosch is what's hard if that answers your question. All right. Thank you very much.