 My name is Kira, I'm on a project called Cloud Foundry. Cloud Foundry needed a awesome piece of software. It's a really massive system to deploy all of their VMs consistently, quickly. It was just a big hassle for them to have to handle. So they created a open source software called Bosch, and that's what this talk is gonna be about, kind of like, what is Bosch? Why can it be a good solution for you? How can you use it to buzzword, you know, continuously deploy your own deployments in your own companies? So, to start off, say you have a shiny, happy product, that can be any product, you know, we use Cloud Foundry, you can have CoreOS, you can be using Kubernetes, Redis, Kafka, Grafana, basically whatever. You have something you need to deploy, and you need to deploy it to some IaaS. You're like, I wanna use AWS, and I do, but it's too expensive. I'm gonna use vSphere, GCloud, I mean, pick your poison. Bosch is actually supported on all of these IaaSes, but you're like, I don't know what I wanna do. So, take a very simple example, say one part of your big product deployment uses a Redis cluster that needs to connect to Grafana, and you're like, I don't know how to connect to Redis. So you found this great blog post online that says, hey, you know, I'm gonna use this thing called Flocker, and I'm gonna use Kubernetes and Flocker to deploy my Redis cluster to AWS, and it's gonna be great, except you go through this blog post, and it's great, and it's step by step, and you're like, yeah, I can do this, except it involves doing all of these VMs on AWS by hand in order to get Kubernetes and Flocker set up, and then you have to go into AWS and mess with the CLI, and then you have to use the command line, which I'm sure nobody likes to use the command line ever. But with Bosch, there is a better way. Bosch itself stands for Bosch Outer Shell. It is a not very descriptive term for what Bosch actually does. So the big question is, what is Bosch? Bosch is, like I said, open source. It can be deployed on multiple IaaSes, that's you can use Apache, you can use OpenStack, you can use AWS. There is a concept of a stem cell, which I'm gonna discuss a little later, that you can use to basically pick your stem cell for whatever IaaS you choose. Choose whatever product you wanna use, whether that's Cloud Foundry or whatever you wanna do, and you wrap all of these things up, you take the stem cell, you take all of your network config, you take anything you'd need, all of your product information, and you say, yeah, so we're gonna deploy it. You don't have to use an already existing product though. You say you're wanting to create the next Grafana. You're wanting to create the next awesome database. So you can also use Bosch to deploy a new release, new product out there. Some of the key principles of Bosch are that it's identifiable. So what that means is that you're gonna have a big thing called a manifest that's gonna have all of your information, it's gonna have your network properties, it's gonna have what components are in your system, it's gonna have all of that displayed in one big happy file. So you can be like, okay, well I have this product over here that takes all of these configurations, and I have that product over there that takes all of these configurations. Instead of having to remember which one is which, you can look at this file and everything's gonna be laid out and easy for you to see. In addition to that, it really prides itself on being reproducible and consistent. And what that means is so you're gonna have your manifest file, it's gonna have all your information, all your network information, and you decide one day, hey, you know, I deployed this thing, it was just a test. What happens if I delete it, reinstall it, and I wanted to, I don't know, make sure that this error I had before wasn't due to a network failure. So Bosch gives you that ability to reproduce the same deployment and do it consistently every time so that when you're trying to troubleshoot your product, you're not sitting here like, well, was this a fluke of something else? Was this because I wrote the product wrong? No, it's gonna take your manifest, it's gonna deploy it exactly the same every single time you do it. And in addition to doing it that way, it also prides itself on being very fast, which in, you know, we're at DevOps days, we're a culture where we're like, we have to deploy things quickly, we wanna do the continuous delivery, and Bosch gives you that ability. So say you make a small change in this spot, instead of having to dig through and figure out, oh, I have to change A and B and anything like that, you basically take your source code, you version it to the next version, you can tell Bosch, use this newer version of my code, and then tell Bosch to deploy it up there, and it will honor your decision and deploy it up there, and it's way faster than having to do anything by hand. So little overview, you can kind of, I kind of like viewing Bosch as a Russian nesting doll with all the little components. At the very core, you're gonna have a stem cell, you're gonna have a large number of releases, and you can have one, you can have four, you can have 20, and those are all going to be built on top of a stem cell, or using a stem cell, and then you're gonna have a long manifest that's gonna define all of your properties, all of your network settings, or all of the configuration for each of your releases, and then when you get all of those pieces together, you're gonna get the outer shell, which can be defined as a deployment. Great, so you can take all of this mess, and take your manifest, and put everything in your deployment, and then do a Bosch deploy, which sounds great, but everybody always wants to show off their software and then don't really show you how you can get there. So easy first way to do it, so you have to get your environment first, you can do AWS Azure, any of those supported things, and then there's also a really nice thing that Bosch allows you to do called Bosch Light, so you could actually get it running on your computer, so you wouldn't even have to pay for it if you wanted to just download it, and play around with it, and see what's going on. So you get your environment, you're gonna install the Bosch CLI, you can either do that from the Bosch IO, I think there's instructions here, but in essence you're gonna need Ruby, and you're gonna need to be able to install Gems. So to install the Bosch CLI, you're basically just gonna run this here, and that'll install Bosch on your system, and then you're going to go to Bosch IO, and download a stem cell for your Bosch release, because what you're gonna do, is you're gonna use this Bosch gem, and use it to deploy Bosch, using a pre-compiled manifest. So, what is a stem cell? A stem cell is basically a micro-compressed, like little operating system, very common one we like to use is Ubuntu trustee, so it's a very simplistic version of an operating system, nothing important on it, doesn't have like, network, anything, it's just a most basic version of an operating system you can have, and why is this useful? So say you wanna do an OS update, you are either being the good developer that you are, saying, you know, I just wanna use the most recent thing always, or you know, you have a more realistic thing, like a security vulnerability attack like Heartbleed, or what's that big one that Linux had? Can't remember what it was, Heartbleed's the one that sticks in my mind, and so you need to do an OS update for all of your individual VMs. Now, you can use something, maybe you have a script to do this for you, but if you don't have a script, you have to figure out how to get this OS update on everything you have deployed, and you know, it's perfectly fine if you have like two or three, because you're like, yeah, sure, I'll just go and update it, but you know, take two or three and bring that up to 10, bring that up to 20, bring that up to 30, suddenly you know, this very menial task turns out to be this big cluster of, I don't wanna do this. So Bosch allows you to go and download a new stem cell and define what stem cell your Bosch deployment should be using, so you don't have to do this. So you don't have to go to each individual thing and do all of those updates. You basically download that stem cell, upload that stem cell to your Bosch director, and then do a new deploy. So what is a Bosch release? If you're creating one from scratch, it's basically gonna have, this command here will generate for you this nifty tree, and your source code obviously is gonna have all of your source code, you're gonna write that as normal, it's not gonna have any changes, but the big Bosch specific things you have here are blobs. So a blob, if you think of it like, say you have a product that needs to use Java, so that means you're gonna have to have the JDK deployed on your box somewhere. So you basically tell Bosch that I rely on the open JDK, so you download the JDK, you upload that as a blob to Bosch, and suddenly you can use Java in your environment. Job is just a very simplistic way of saying a unit of work. So for example, you have a component that has two pieces, and each piece, like one does reading in from, like the command line, the other takes that information and puts it to a database. You know you could put those together, but first, simplicity, let's just say, they're two separate objects, and so you'd have one job that would read in, one job that would read out, and you would define any specific configurations that you need inside of this jobs directory. And you also have packages. So packages is, at its most simplistic form, going to be your compiled source code. And if you need any specific packaging instructions in order to compile that source code, you can write scripts in there. That Bosch will read and compile that source code for you, so you don't have to do any of that locally. So you say, I'm already using these awesome softwares. I don't want to have to go through that Bosch, create release, go through all the configs, upload blobs, like I don't know what all these dependencies are, I don't wanna deal with it. Great thing about Bosch is that it's got this amazing community. So if you go to Bosch.io slash releases, you get this awesome list, like this is maybe like not even a quarter of all of the releases, it's maybe like an eighth. There's tons and tons and tons of releases that are already existing within the community that people have already made. So you basically can go, hey, download this release and upload that to Bosch and then you can just use it. Again, this is a command in order to upload the releases. So you're like, great, I went through Bosch.io slash releases and I still couldn't find what I was looking for. So another great thing, this is something I've experienced a lot at my own job, like your, I think Kafka is the example I wanna use. Doesn't have a Bosch release on Bosch.io and it was something very pivotal to what we were doing for our project. So we just did a Google search wherever it went. We did a Google search and it comes up with a list of responses of people on GitHub that were like, here I have a release already so you can go to their GitHub, download their release that way and use it. Like you're not constrained to just a single website for the community. So what is a Bosch manifest? A Bosch manifest is basically a long list of pretty much anything and everything that makes up any particular deployment. As you can see from just this little snippet, this was actually from my Cloud Foundry manifest which I mentioned is very, very big, lots of VMs. So as you can see, line 200, it can get very long depending on how big your project is but if you have a really big project, you have to manage a lot more things which makes being able to see everything that you're deploying all in one place super helpful. So you have all of your components are separated into things called jobs which are basically just small units of work that you want Bosch to perform for you. And in this manifest you have to define any configuration that you need, any properties that you might wanna set, any resources that you're going to use like whether you're gonna use a T2 small in Amazon or something similar. Defines any IP ranges. So like you reserved this awesome subnet that has this specific IP range but your higher ups say you're not allowed to use more than this many IPs. So you define what range you're allowed to use and Bosch will actually yell at you if you start trying to grab more IPs than you've defined for it to use. And here's where you also define your subnets. So you give it your specific name and it's able to connect to Amazon or Google Cloud or like whatever you're using. And you know of course the list goes on and on depending on how specific you want to get into your configuration. So Bosch Manifest is really big. I'm gonna take a super small simplistic example of a manifest that just has some dummy data in it to kind of explain some of the bigger concepts that are in the manifests and kind of what to define. So first off you have the name of your deployment. This can be whatever you want it to be. You just have to be consistent with it because when you wanna talk to Bosch you can say, hey Bosch what are my deployments? And it's going to give you a list of everything you've deployed and it's going to reference this name. So naming it deployment one might not be the best idea in hindsight. The next one's your Bosch director UUID. This is really, really important. When you have Bosch deployed you're gonna run a Bosch status, this command and it's going to give you back one of those weird number strings that we have here. And what this does is it says this deployment is going to deploy to this particular director which is awesome in that you say you have a testing environment and you have a staging or a prod environment like deployed to the same IaaS but you're just like, I wanna make sure that this goes to the testing environment. So you define the UUID as testing in that, sorry I lost my train of thought. You define the testing environment in the Bosch UUID and then you do a deploy and you can make sure that you're able to go between environments but know which one you're deploying to. It's a unique identifier. You're gonna have your list of releases. So that can be one, that can be three, that can be just however many you need. What's cool about this is that you can also define the version. So you have a product that has three pieces. You know, a piece A, the only one that works with your product is version three. But versions B, but components B and C you wanna use the latest every time. So you can tell Bosch, only use version three of component A. And Bosch will say, oh bro, as long as that's on my servers then I know what I'll do. Or you can tell it to use the latest release of anything you have up there and it'll say, okay cool, this is the latest version, I'm gonna deploy it. If you wanna see what releases you do have available on your Bosch director, you can run a Bosch releases. And it's gonna give you a list of all of your releases and all of the versions you have deployed. And again, if you wanted to find new releases, you can go to Bosch.io slash releases. It has pre-compiled stuff for you and all you have to do is upload it. What you also have next is your resource pool. And that's gonna have basically just small clusters of VMs that are all gonna share very similar properties. So for example, in here, the system servers resource pool wants to have all things using the same stem cell. They wanna have M1 mediums, but you have another resource pool that you want to say, you know what, this is a database, this needs a large. So you can define another resource pool. So any of your components can reference this a particular resource pool and have those properties predefined so you don't have to do it like four different times in your manifest. And of course we have the stem cell version defined here, which I mentioned, you can very quickly get a new stem cell and deploy everything with that new stem cell. This is what you're gonna change. So you're gonna download the stem cell, upload it to Bosch, and then change your manifest to use this new stem cell. And then all you have to do is do Bosch deploy and it'll say, great, I have this new stem cell, I'm gonna redeploy everything with this new stem cell. Next piece of the manifest is where you define the components of your system, also known as a job. So your jobs are basically gonna have all of their individual pieces that are necessary. You're gonna define their resource pool, you're gonna define what network it's gonna use. You can also define specific properties, so instead of reading in a system environment variable, for example, you'd set that here and then Bosch could help you translate that into your component. You can also set global properties, so you're just like, yeah, you know, my max connections, I want 10 for every component in my system, but I don't wanna have to write that 10 different times for each of my components. So you can make it a global property and reference whatever you need within the components themselves, so you're simplifying your code, keeping it all in one place. Last bit of the Bosch manifest, you're gonna have your networks. Unfortunately, there might be some manual work you might have to go through in whatever I as in order to make sure that nobody else is gonna use this network, but you just tell Bosch, hey, I'm using this and Bosch is like, cool, it has all the information and this is all that I care about, I don't care about anything else in the world. You have your compilation VMs. So compilation VMs are very, very, very short-lived. Basically what they do is they're gonna spin themselves up, they're going to compile any source code you have and then they're going to spin themselves down. Canaries are super awesome, so I don't know if you guys know much about mining, so they used to take canaries down into caves when they were coal mining to make sure that there was no methane gas around so that they wouldn't asphyxiate and die, so they'd have these little canaries and cages and when the canaries died, because they have less awesome lung systems than we do, they'd say, oh crap, we got a GTFO and that's kind of similar to what the canaries in Bosch do, so they're basically going to take and try to deploy your system by deploying canaries first and if the canary can't even deploy, like you have something catastrophically wrong, it goes, oh crap, nope, we're gonna back out this deployment and we're not gonna destroy what's there, this is not okay, so it's kind of like a, I don't wanna say fail safe because you can still screw up other things, but it's a good, tries to help protect you for some of the more basic problems you might have. So you have this awesome, you're fitting together the puzzle pieces, you're like I have my stem cell, that connects to releases, that connects to my manifest, all of these things together make up a particular deployment, so it's easy, right? You know, it's not a ton of information and no, no, it's not really easy. I've been working at Cloud Foundry for two years now and when I first started, I had to use Bosch on a mostly day-to-day basis. The learning curve kind of looked like that, I was more going into work every day, I hate Bosch, I hate it so much, I was like I don't understand what's going on, what the crap is released, how do I build one and then the next day I was like okay, I know what a release is, how come this deployment failed, why is my canary saying I'm red? And then I'd have to go yep, I still hate this thing, I understand what it's doing, I don't like it and then I'd be like eh, you know what, this Bosch thing's kind of cool, I'm kind of wrapping my head around what's going on. It's better than doing things manually, I guess, but so then you get to the point where, this is kind of cool, this is kind of cool, this Bosch thing and at the point where I'm at now, I still sometimes struggle with Bosch but I personally think it's one of the best things ever, like it simplifies a lot when you're trying to create your deployments and tell it, I want it to have these properties, I want it to deploy to AWS now and then we had to change from AWS to Google Cloud recently and all we had to do was, all of our properties got to stay exactly the same for our product and all we had to do was say, how do I set up these new networks because this Google thing is weird and Bosch said oh yeah, okay, I'm gonna fail as you're trying to define these networks wrong but it made it very, very, like we spent about a day, I think, transferring from AWS to Google and that's pretty awesome, I think. So great thing about Bosch is that it's, there's tons of people that can help you figure out what's going on with Bosch. I've personally looked at blog posts from Stark and Wayne, Pivotal and Altaros. They have lots of really great information if you don't understand what's going on. There's, it's very, very well documented so you can look through just the basic documentation but sometimes if you have a more complex topic you can try Googling how to do X and chances are you're gonna find like a really good blog post or a Stack Overflow question or anything like that that will answer your question and can sometimes even walk you step by step into understanding what's going on. So, another great resource is the Cloud Foundry community which is going to have all of your lists of like Bosch releases and you can ask lots of, I don't think you can ask questions here but you can basically see all of the different repos of everybody who's using Cloud Foundry, you're like, I wanna do X things so you can look through any repos that people have been using in Cloud Foundry, see how they're using Bosch and figure out how to set up your own product to use Bosch and maximize your time instead of wasting it doing things that might be more confusing. This link is here, that's where that slide went. Anyway, so the big question is Bosch right for me. I tried to mention earlier that Cloud Foundry is a really, really big system. It has lots of moving pieces, lots of microservices that need to talk to each other. So, you have this little, little tiny product, you have your one little plant and a little pot and using Bosch could kind of be like creating a massive greenhouse to house your little teeny, tiny pot. Yeah, it's gonna work but it might take you a lot more time than necessary in order to get there. That being said, if you are building a small project and you're planning to make a bigger project and you know it's going to only get bigger, it would definitely be worth your time to get to learn Bosch because then it would save you all of that hassle of trying to convert this thing that, you know, Jeff created scripts to deploy and then Bob came over and came to build on those and then Angie came and went, oh, those both suck, we're gonna use this instead and then nobody knows exactly what's going on whereas you can look at a Bosch manifest and say, yeah, I know exactly what's going on. This is what's being deployed, this is what I can see. So, list of useful links and tutorials. You've got the one on the top is an online tutorial for Bosch. You have all of the documentation listed there. That's, again, the CF community link I posted earlier. There's a quick, if you're interested in Cloud Foundry, there's a way to deploy, how to deploy Cloud Foundry with Bosch. And I mentioned earlier that you didn't have to use an IaaS in order to deploy Bosch. So you just wanted to try it out. There's this great thing called Bosch Lite that you can have spun up on your computer. Bosch is kind of beefy, so if you only have four gigs, you might only be able to run Bosch Lite, but you still can do it. So, just keep that in mind. And I'm gonna leave this up, but that is the end of my presentation if anybody has any questions. The question was, how does Bosch compare to CloudFormation templates? You can actually use them in conjunction with one another. So you can set up a CloudFormation template to create all of the resources you might need and then use Bosch to reference those resources directly. So you could, I think there's really good plugs to hook up Bosch directly into CloudFormation, so you don't even have to think about what you're putting in there. Does that answer your question? The question was, is there's any plan to add Docker support? And the answer is, there already is. Like, there is actually a Docker release for Bosch, so you can deploy Docker using Bosch if you wanted to. Okay, the question was how Bosch can integrate with third-party systems that you use for security? Yeah, for firewalling, et cetera. That's a good question. I believe it's more set up with when you're defining your networks, if you have a firewall set up, you have to make sure that the ports that Bosch is using are acceptable by, or are, I forgot the word I wanted, that your firewall can accept those Bosch ports. There actually is a, you mentioned VMware in your question, and Bosch can be deployed to VMware, so if you didn't want to access an external IaaS, you could keep it all internal, and then you wouldn't have to deal with it at all. The question was, if there's any tie with Kubernetes, and the answer is yes. Just in the past week or two, there was a big Kubo, so Kubernetes Bosch release, so it's being officially supported by the Bosch community, or yes, Kubernetes is being actively supported now by the Bosch community. The question was, how does Bosch deal with secrets? Bosch deals with secrets, kind of you'd have to put in your secrets in the Bosch manifest if they were referenced by your components, that doesn't sit well with me and most people, but you can use different software like there's Spiff and Spruce that I've heard of, that you can use to say, oh well, I have all my passwords stored in this vault, I'm gonna read from that from the command line, and then I'm going to merge that into my manifest, and you can keep things fairly secretive that way, so you basically would keep all of the information critical separate, and then you'd have to merge those in, like whenever you were using it. Does that answer your question? Thank you.