 Well, good afternoon, everyone. My name is Rick Ross. I'm an advisory platform architect with Pivotal. Guna. Hello, everybody. My name is Guna Vijayatnam. Also a platform architect with Pivotal. And today we're going to be talking about customize your Windows experience. Pick your own journey. But before we begin, we have to read this fire and exit announcement. So please locate the location. Please note the locations of the surrounding emergency exits and located near the nearest lit exit sign to you. In the event of a fire alarm or other emergency, please calmly exit to the public concourse area. Emergency exit stairwells leading to the outside of this facility are located along the public concourse. For your safety and in an emergency, please follow the directions of the public safety staff. So let's go ahead and get going. So what are we going to cover here? So here's the agenda for this afternoon. And we're going to be talking about, first of all, what problem are we trying to solve, right? There are specific inherent challenges when you deploy Cloud Foundry that you may want to take advantage of. Then we'll talk about some options, both good and bad, and why they're good or bad. Then we'll talk about a decision so you have these choices. How do you go about even thinking about which option to choose? Then Guna's going to come up and do a demo, and we'll wrap it up with some questions and answers. So what problem do we want to try to solve? Well, when you install Pivotal Cloud Foundry, I'll make this generic, you get a really good out of the box experience. But a lot of times what happens is, in large enterprises, there's additional concerns that need to be taken care of. And so you have a couple of options on how you might try to proceed, right? And so there's different ways of looking at this from both the platform concerns, which are usually more low level, right? More at a virtual machine concerns, things about enterprise security. And then there's things from an application developer perspective that you need to be concerned with on an app level. And there's this notion of either extending or modifying, meaning there's a way to actually do this in a way to modify what you need to do or extend it. And we'll see later which one's the better choice. So from a platform operations perspective, the goals that they're typically concerned about are all oriented around enterprise security, generally speaking. So things like IPsec to ensure that traffic is encrypted inside of Pivotal Cloud, inside of Cloud Foundry. Perhaps you need to install antivirus software. Who here is an enterprise would ever want to install a Windows server that's connected to the internet without antivirus? Yeah, exactly right. So there's some challenges there, right? Out of the box, you don't get that. You have to do some extra work. Compliance, sometimes our security team say, hey, we need to show this login banner. So when people hit it, they get warned about it. I don't know how effective that is, but that's a different story. And then IPv6, right? Sometimes we have to install some additional capabilities to do that. From a developer perspective, however, they're really more focused on an application. What are the dependencies my app requires in order to deploy it? So the classic example is I have a .NET framework application. And I need to use an Oracle driver, for example. How do I get that dependency so my application can work? So the other interesting, what I call a cloud native antipattern is this notion of multiple languages. And you probably say, what are you talking about, Rick? Well, let's say you have a .NET framework application that uses Oracle, but also you're using something like Flyway to take care of the database changes. Well, Flyway uses Java. How are you going to deploy that? And then the last part here is this notion of plugins you want at an application level. And the classic example here is for application performance management. Maybe for monetary reasons, you don't want to actually install something across all the virtual machines. Maybe you only want to pick and choose the applications who want to do that. So let's talk about options now. So let's say we have our Windows application that needs to install that Oracle driver. Couple options you have. The first option is to modify or fork the existing HWC build pack. And you put those dependencies in there. Alternatively, you could take your Windows base image, install the driver, and then you have to worry about maintaining that down the road. So the challenge here is the maintenance of this. So when you have a new build pack, when Cloud Foundry releases a new build pack, you have to update yours to match. And similarly, when Patch Tuesday comes around, you have to modify your stem cell or your base image to handle the whole thing. So the important point here is don't do it this way, really. Another scenario is we want to install third-party agents like in any virus software. So one approach you can have is get your Windows base image, install the virus software on there, and build the stem cell from it. And again, there's a way you can do it. Is it the most powerful way? Probably not, because what happens? Again, you have got the virus software installed. They have their own updates. You've got stem cell updates. And so these are tightly coupled, and it really becomes a maintenance nightmare. How do you do that, right? And then there's potential port conflicts or actually potential with any virus software scanning components of the actual containers that would maybe trigger a false alarm. So again, don't do that, really. So if we don't do it that way, what are our options? There's two ways we can approach this. Number one, we could do a Bosch add-on, right? Or the other approach is using build packs. And so using a Bosch add-on is all about extending the stem cell in a way where it's not going to be a maintenance nightmare. So Bosch add-ons are applied from the Bosch director, and they're applied most importantly to all the virtual machines or those sets of virtual machines you want it to apply to. And then from a build pack perspective, probably everybody here has ever pushed an application, whether they realize that they're not as using a build pack, but the build pack is really that component that handles the promise of, here's my application running in the cloud for me, I don't care how. And the build pack is that how, right? So this build pack allows developers to just focus on writing their applications. They don't have to worry about infrastructure. It also gives them the software they need in order to run their application. And then of course, what it does is ultimately it's creating that image, that container image that we call a droplet. So when we look at Bosch add-ons for Windows in more depth and Guna through his demo, after the demo, he's gonna actually go into this a little bit more. But the really key idea here, it's really just a Bosch release. It's really not that different than what you might be doing if you're managing Bosch alone right now. So the other thing is is for those Windows developers and admins who love PowerShell, the jobs, you use PowerShell. So it's something right within your frameworks that you're used to using. From a build pack perspective, the legacy way now is what I call monolithic. So I don't know how many people realize that the build pack approach is actually changing a little bit. And so I call the legacy way of doing things monolithic because they're really kind of heavy. When you take a look at something like the Java build pack and all the different, all the capabilities that you can do in configuration, there's a lot in there, right? And so what that, when you're trying to do something like a fork, you're gonna be having this maintenance nightmare. What's in a build pack, it's really easy. There's a detect, compile, and release. And can I handle the application? How do I actually, what does the app need to run? And then how do I actually run the app? So there's these three scripts. While the new way of doing build packs, really what I call it, more cloud native build packs or really more modular way of approach, they're called extension build packs. And what they've done is taken the compile and split it up into two pieces, supply and finalize. So supply now is responsible for those dependencies that I need to run. And I can actually have multiple supply build packs in there. And then finalized takes all those dependencies and prepares it. Prepares your application in order to run. So very, very powerful addition. So okay, great, we've talked about build packs. We've talked about Bosch add-ons. How do we know when to choose? And it's pretty straightforward. Basically you wanna choose an add-on when you wanna affect everything at a virtual machine level, right? You wanna install in the virtual machine things that don't work inside of a container. So these are typically lower level things like at the network level or any virus, certain types of agents, maybe security agents that you're running. And the teams that are gonna actually doing this is your operations team. So you choose an extension build pack when you wanna affect something at the container level. Something like a dependency, frameworks or libraries, maybe the Microsoft Visual C++ runtime, maybe an Oracle driver or something else, and certain types of agents. And in general, it's the development teams that are gonna be focused on using the build packs. All right, so I'm gonna hand it over to Gunah and he's gonna walk through the demo. Okay, so for today's demo, what we're gonna do is we're gonna look at the operator use case specifically. So Rick talked about the two versions of the extension for the developer and the extension for the operator. So for this particular example, we're gonna talk about customizing your windows deployments using two specific things. So first of all, we are going to create a custom Bosch add-on, a window specific Bosch add-on that's going to basically deploy a data dog agent on our VMs. So the goal here is once we deploy those windows VMs, we want those to automatically register back to data dog so we can actually monitor those. And we wanna do that only for our windows VMs, not everything else. So that's the first use case. The second one is the antivirus usage we talked about. So this is an out-of-the-box add-on that's already available on network.pivotal.io, for example, is also available in the community. And this is using an open source ClamAV antivirus software. So what we wanna do at the end of the day here is we wanna basically take the runtime, the windows runtime that we have, we wanna layer these two add-ons on top of it and then deploy that out using Bosch. Okay, so could you also flip the video? Okay, so there's a lot of different moving parts here. So let me just kind of walk you guys through, oh, actually can you go back to the slides for me? Okay, yeah, thanks. So there's a lot of different moving parts here. So let's kinda walk through the different steps just so you follow me along when I'm doing the demo. So first of all, what we're gonna do is we're gonna create the custom add-on. Once we create the custom add-on, the next step is we're actually gonna upload the add-on to our Bosch director. So in order for anything to get pushed out by Bosch, it has to exist inside Bosch, inside the Bosch repository. So once we've already done that, then the next thing we're gonna do is we're gonna take our ClamAV anti-virus add-on as well and do the same thing, push it into the Bosch director. Once both these releases are available in the Bosch director, then the next step is we actually have to tell Bosch how to deploy these two things. So that's where the runtime config is gonna come in and I'll kinda give you a, but we'll walk through that point a little bit more. Okay, so once we update the runtime config, now Bosch is ready to do its job. So at the end of the day that this is what we're gonna do, we're using the updated runtime config, we're actually gonna push out the Bosch deployment and the Bosch deployment is basically going to take the out-of-the-box Windows runtime releases that we have, layer on those two add-ons and then selectively apply that only on the Windows stem cells. And then that will get pushed into IS, in our case AWS. Okay, so let's take a look at this. So, might be a little bit hard to see and for the interest of time there's actually a pre-recorded demo, but I'll make sure I'll punctuate it in specific spots just to highlight different things. So the first thing you wanna do is we wanna log into a machine that has the Bosch CLI attached. The next thing is we're going to go ahead and create an add-on, right? So in this case, I'm actually pulling the add-on down from a repository that I already have and this will all be part of our material. So you can go in and check this out at a... Yeah, it's a pre-recorded demo, we can't, but it's gonna flat out the right spot, so hopefully we'll be able to see it. So let me pause you for a second. So the key thing I wanna point out here is as part of every add-on, we have this thing called jobs. So a release, a Bosch release can have one or more jobs, okay? And the job is basically gonna determine the life cycle of something that we're looking to deploy. So in this case, we have a Datadog Windows agent job and we also have this thing called a monit process. Okay, monit process is basically what allows Bosch to be able to manage your processes that are running as part of the job. So I'll show you guys what that looks like. The other thing is also this thing called the spec. So the spec file basically defines metadata about your job. So specific information about the scripts that are gonna run, metadata about maybe key value properties that you wanna pass to your job, packages, so on and so forth. And then finally inside templates, we have a list of all of the different life cycle events for your job. So start script, pre-start script allows you to hook into different life cycle points of your job. So this is basically the framework of a job and we'll look at some of them in a more specific detail. Okay, so let's take a look at the first one, which is our pre-start script. So again, I'm not gonna go into specifics on the script, but basically this is the PowerShell script that's doing all the job for us. So what it's gonna do is it's gonna go to Datadog, it's gonna see okay, what is the latest version of the Datadog agent that I have, pull it down onto a specific location and then install it and then configure it so that it operates the way we want it to operate, right? So again, the key point here is this is just a standard shell script. So for all the Windows admins out there who basically automate their jobs with shell scripts, it's really just taking those shell scripts and then hooking it into the job life cycle and you basically get that same level of functionality. Okay, so once the script basically runs, at this point, our agent will be installed. The second part here is the spec file, again, you can't see that all that well, but basically what the spec file will do is you can define, again, like I said, metadata about your job, right? So here's potentially properties that you wanna pass to your job without actually hard coding it, also potentially packages that your job relies on, all those things are defined inside of the spec file. And then last but not least, the monit file. Basically, the monit file is the one that's actually gonna define the processes that's part of the job. And this is how Bosch knows how to monitor the process and if the process dies, Bosch knows how to restart the process. So I'm gonna look at the actual process once they're pushed out. Okay, so now that we have our job, the next step is we are going to build a deployment, right, so this is the part that we use the create release to actually generate the release that we're gonna push into Bosch. Remember the slides earlier, the first part, we're actually gonna push the release. So this step here is actually gonna create the release that Bosch understands. So once we do that, the release is created. The next step we wanna do is we wanna actually now start pushing the releases into the Bosch director. So we have our claim AV release, we have our built Bosch add-on, the custom add-on and now we're gonna log into the director. So this part, we're actually gonna just log in, basically give our credentials, log into the director as an admin so we have the rights to push releases onto them at this point and then right now we are authorized to go and let's give it a second. Okay, so now the next step is we are going to now start pushing the release. So first of all, we're gonna start with the claim AV release, okay? So now we're gonna push the claim AV release into the Bosch director, okay? So the claim AV is there. The next thing we're gonna do is we're gonna now push the actual add-on, same thing there, right? We just basically go into our add-on, the jobs folder and push that as well. So now Bosch director in its repository has got both add-ons available. So now we're gonna actually go in and look at the releases just to make sure that the releases are there. So if you go back into the actual Bosch director and introspect the actual releases, you will now see that, yep, now you will see that there's the claim AV release, 145, as well as the data dog Windows release. So both of the releases that we created are now pushing to the Bosch director. One of the other things to note here is that one of the nice things about Bosch is it actually maintains multiple versions of a release. So if you push a release and you actually update the release, it will actually maintain versions of them. So the nice thing is if you had a mistake in one of the releases, it's easy to roll back and then go back to a different version if you have to. Okay? So once the release is out, now we have to actually tell Bosch how to deploy this. So this is the part where we're gonna actually look at the runtime config. So the runtime config is basically a global setting that Bosch allows you to define what type of jobs you wanna run across all deployments of a certain type. So in this case, the way you work is you basically define the set of releases that you're interested in. So in this case, I've defined the claim AV and the data dog release. The second step is we are going to define the actual add-ons. So the add-ons section is gonna basically reference the release and it's also gonna determine which you can actually tell it which job to run, right? And the other not a powerful thing about this is the whole include section. So remember earlier we said that when we deploy these two add-ons, we only want it to apply to the Windows environment and not anything else. So that's how you determine, that's how you instruct Bosch to only deploy this on Windows through the include option. Now this is also quite powerful, you can also do other things. Like for example, you can say if I'm in a certain network, do something or based on some other criteria, you wanna, or based on a certain deployment, do something or you can also do excludes based on those kind of criteria. So it's a very powerful feature that allows you to be very specific about which types of releases we'll get the add-ons. And then finally, we will also do the same thing for the ClayMavy release. So again, the ClayMavy Windows release, that's the job that we're running and we're gonna target it to our Windows stem cells. So at this point, we have set up the, we've told Bosch what to do, now we have to basically do the update runtime config, right? So with that, we are actually, so Bosch again is gonna come back and say, remember this is actually declarative, so Bosch has the current state and the target state. So the current state says that I'm running a different version, I'm gonna actually delete that and I'm gonna bring it to the target state that you've asked me to bring it to. So it's quite intelligent in that way, so we are now gonna get rid of an older version, install the new version on both of them. And at this point, we accept it and now we are ready to roll our changes out. So you're probably wondering, okay, well why am I in the web browser at this point? And in full disclosure, you could probably have done this whole thing through the Bosch director. So once you actually pushed all your releases into the Bosch director, you could have done a deploy directly from there. But I'm actually using the pivotal ops manager to now roll out the changes and the reason is, you can actually gonna see some debugging. It's a little bit easier to see some actual debugs that will happen as we roll out the changes. So we come in the pivotal ops manager, we apply the changes, now we're gonna start running through the process, fast forward a little bit, all the way down to the updating the runtime for Windows. And now we're gonna see some key things. So first of all, it's gonna target only our Windows deployments, okay? Secondly, it's basically got again, that's what it's doing, that the thing that we saw earlier with bringing in from current state to target state. And then finally, once it actually applies the changes at the bottom that you probably can't see that, but basically what it does is, it's applying it, it's updating all the Windows stem cells, all the Windows instances are now being updated with this change. So fast forward, apply successfully. Now we can actually go in and validate that the changes that we made are there. So we come back into Bosch releases. Now you can see that the Clam AV and the Datadog for Windows are actually been installed. Now you see a little star next to them, which means that those are the active versions that are out there. So Bosch successfully rolled out the old ones and it's actually put in the new ones. Okay, so that looks good. And if we go back and look at our actual processes, same thing there, right? We can see that the Clam D process is running and then our Bosch Datadog add-on is also running. So Bosch is now going through that monitor script that we showed you earlier. Through that monitor script, now Bosch is able to detect that all the processes that are part of that job are running. So everything is in functioning state. Now we can come back in and we'll do the final check on it. Okay, so we're good there. Now if you're gonna go, let's go to the IS real quick. So this is on AWS. Those are the two Windows VMs that Bosch spun up. Now let's take some identifiers on them. So first of all is the 10-004-36 and 10-004-35, those are the two VMs that was spun up. So at this point, the VMs have been spun up and we wanna now make sure that these VMs are gonna show up on Datadog, right? So by right, the agents have been running on these VMs, they should be now connected back to Datadog. So now let's flip over to Datadog. All right, so Datadog will now show us the two VMs that have now been basically registered back to the actual Datadog console. You notice that they're both Windows VMs and if we actually go in and do an inspection on it, we should see that those are the four 35 and the four 36 VMs that we saw. So that's the four 35 and the second one is now the four 36. And again, so basically both those VMs from Bosch are now registered back to Datadog. We can actually come in and we can actually introspect it and so on and obviously, if you wanna do a slightly more complicated deployment, you can also come in, set up your own configurations to do live process monitoring, so on and so forth, okay? So at this point, Datadog has seen what Bosch has put out in terms of Windows VMs. So got a few minutes left, I'm gonna quickly wrap this up. So in summary, these are the two options we have, right? So the add-ons and the build-back. So obviously add-on shows us a way to really build very extensible add-ons, modules that your sys admins would probably use to basically affect a very specific type of behavior inside Bosch. So Bosch, even though it's closed off, gives you this great opportunity to really extend that sort of functionality. And then from a build-back perspective, if you have specific action that you want on an application basis, the build-backs will give you that as well. So these are the two options that obviously we recommend for those two personas, whether you're the operator or the developer. And again, we have our information, we'll make sure you put links out to the video and so on so you guys can try this out on your own as well. So that's all we have. Anybody have any questions? So I went through the process of actually doing a supply build-back. So if you look on the first link up there, you can take a look at that. It's fully functional on Linux. Windows, it's about 95% there. The reason is that there's no current build-backs on Windows that have that finalized script yet. So as soon as we have that, it should work, just needs to be tested out. What was the Bosch command you ran to show those processes? So it was Bosch, show process dash PS or something like that. Yeah, but basically it's, yeah, it'll be on the website, you can definitely see it. But yeah, it will show the full set of processes and all the instances and all the associated processes. Yeah, exactly. Any other questions? So that's a good point. So the question is, is build-backs and this new extension build-back, is that something new? And yeah, it is kind of new. Earlier I talked about how build-backs are kind of monolithic in design. And so they refactored the compile script into supply and finalize. And when you're using the supply and finalize, it actually requires a v3 push. And there's a couple of steps. If you go to the get repo, it'll walk you through those steps. Does that answer your question? Yeah. Okay. Yeah. So the question is, do you use that to lay down other dependencies? And the answer is, yeah, absolutely. That's really what it's for. So the question is, is there a way to have every container be forced to use a specific extension? Not really, because that happens when you push it. So currently the v3 push doesn't support manifests. So you've got to do everything on the command line. So there's not yet, not currently. You'd have to do that through a CI CD pipeline. Any other questions? Yeah, so I guess the question is, what is the process for continuously adding add-ons to your Bosch director? So the way I would say you could do it is, so the Bosch, all the add-ons completely can be checked to the source code and you can run unit tests against them and so on. So the best way to do it would probably be to do some sort of a CI against your add-ons. So you can push in as many versions of add-ons as you wanted to Bosch director. And one of the nice things, like I said, is Bosch director will actually maintain versions of them. So you can always say that, okay, I might have version 1.0 that's being pushed out, but I can continuously push different versions aside from that, but only the one that's gonna be deployed will be 1.0 because that's what's been defined in my manifest. So when you are ready, then you can actually go back in and flip it out to a different version, maybe from go from one order tool and then deploy that. So you could do that way. Correct, yes, exactly. So once you apply the runtime config and you do a Bosch deploy, it will see the current version that's out there. What is your intended version? And it will merge it and make sure that it writes current state. Any other questions? Okay, so here's a discount code if you want to come to spring one, save $100. So thank you for your time and attention. Appreciate it.