 All right, everyone, I know it's a last session. One thing that I can assure you, it's not a change APT generated presentation. It's why humans, for humans, all right? So let's get started. Then we're talking today about how do you deliver a cloud native application or complex software with open component model or OCM and Flux. And before we get into it, let's talk about the humans in the room. So, Dan, how about you get started? So I'm Dan Small. I'm an expert software engineer at SAP. Been there for several years and been in the industry for 27-ish years, whatever. So obviously, bounced around quite a bit, done a lot of pipeline stuff, et cetera, et cetera. So that's me, Mo. Also, thank you, Dan. So my name is Mohamed Ahmed, or you can call me Mo and VP of developer platform at WeWorks. We are the creators of Flux and we coined the term GitOps, which you're gonna hear a bit about it today. In addition to being the main maintainers of Flux, we have a set of tools built on top of it. If you're interested, feel free to reach out after this session. That's not what we're going to talk about today. Hopefully more interesting stuff. All right, so let me go quickly through what's the roadmap of this presentation. It consists of three main parts. We're gonna make it simple. Again, since it's the end of the day and you guys probably working 25% capacity until you get to the party, we're gonna start with just the challenges. Why OCM? Why did this start? And why SAP and WeWorks work together on making this happen and presenting it to the community? And then we're gonna talk a bit about the basic concepts or the building blocks of OCM. And then Dan is gonna do the real work here and the cool stuff by showing us all a demo end to end showing how the OCM plus Flux can work together. But let's start exploring actually the topic together. How do you deliver a cloud native app everywhere? And any cloud infrastructure without jeopardizing security, without having the luxury of being connected as in public clouds and an air gap environment. That's the first question that came to the OCM creator's mind. And actually it happened as a result of free scenarios. And there's one basic concept that they have in mind that cloud native applications there should be cloud native everywhere. They should be running with the same high security standards and same processes that you would implement in highly connected or fully connected infrastructure such as the public cloud. So the three main keywords that I actually want you to come out of this presentation today. How do you describe? How do you transport? And how do you deploy those applications? And this is what's all the OCM about. Just to make it simple. And this is what big companies, enterprises like ACP wanted to do. But the challenge here is not only how to do these, it's also about how do you do them at different environments? Public cloud is something that we all know about. But government cloud, sovereign clouds, private clouds, these are environments with their own special requirements and they are challenged in the way that they're being connected and the standards that you need to apply to those environments. Probably three out of the four here are common. Anyone knows what sovereign cloud is? Any idea? Government cloud, public cloud. Public cloud, we all know it. Government cloud is working for the government. Sovereign cloud is just a fancy name of a cloud that is disconnected from everything around it. Including the metadata, including the operations. No one is allowed to do anything on this cloud outside of certain geography. And this is just a term that's becoming hot these days because of the geopolitical situation that the world is going through right now. And private clouds, you know, private clouds, but not necessarily as stringent in their requirements as sovereign clouds. And some other interesting scenarios as well that the OCM creators thought about is how do I deploy a single application into infrastructure at the same time between first structure environments? Public cloud, private cloud, same application need to go at the same time to those environments and behave in the same exact way and maybe with some tweaks. And same, of course, for the edge cloud. Now, you may think and say, well, I have the container images and I have the AMM files. I can just take them and throw them, you know, over the wall to that other cloud and I just deploy them. Well, in reality, it's not about that. You wanna make sure that you move your standards, you move your tools, you move all what you want to achieve in your deployment or delivery to any cloud. Again, any one of those clouds need to happen. You need to have the same standard, the same way to do it. And it's all about actually having orchestrated delivery and have a secure supply chain for your application delivery. And to do that, there are three main concepts that you usually have in mind or anything would have in mind that has happened in SAP and then it's gonna show us this today as well. How do you do compliance scans? How do you sign and verify your components or building blocks? And of course, how do you have proper traceability and attestation of your artifacts? These are just minimum requirements, I would say, to have your cloud native application deployable or can be delivered anywhere. And that's all the OCM about. OCM is about just bringing all those together in one declarative model and flux is working in tandem with it to deliver all of these in a seamless way regardless where you're running your application. So the OCM or the open component model, the main building block is what we call the component descriptory YAML file. And that YAML file provide multiple values, but I would maybe focus on the three of them here. One of them is how do you do a complete description of your delivery related resources? I wanna just describe what is exactly my application? Everything around it. And the second one is how do I separate, how do I name or identify the component to where it's actually running? This is also another important piece. Anyone since we're in the open source summit, Linux is a big thing. Anyone used to work with linkable objects on Linux? Or... So the concept of OCM actually are immutable IDs that is like linkable objects in a single DM world. Back in the early 2000s and 90s, if you wanna develop a somehow dynamic application that consists of an executable file in the library, you would usually define some sort of flinks inside that library or inside that executable file that would reference a DLL or reference an object file that doesn't exist yet. And then when they both come together, in the runtime, the operating system does a resolution and connects the executable with your object file. So the same idea here, but happens at the cloud native. It's the same concept being reincarnated for distributed systems and cloud native applications. So that you focus at the end of the day on the delivery of the artifacts. And this is what's now called the software bill of delivery or is BODs. If you will. And this is basically how you bring everything in one single file to say this is how my application is going to be delivered to the other end of my environment. Now, the use cases are relatively simple. If we think of the workflow and about to be done and we're gonna get to the interesting stuff by then, is how do you deploy? First of all, you typically would go through the development, do the building. Everything is in your repository. You have a bunch of other artifacts and they're all now sitting there. You're waiting for them to be glued together. And that's what's again OCM. And just think of this one as a visual of what I just mentioned. And then from that point, okay, I brought everything together. How do I now build my own processes on top of it? And a typical process would be scanning your infrastructure. You know, you do some assessments. Maybe you do some build reports and so on. So there are a lot of things that you can do before you actually have your final output, which is typically an OCI image and make it ready to run on that other environment. And actually after that with the flux, with the help of flux, and this is something we're gonna see today, you can do even further verification and do any other processes for you to guarantee that your artifact is actually running according to your standards. I did not mention this at the beginning, but I joined WeWorks as part of an acquisition. My startup was called Magalix and we were policy as code. And we usually run those policies on artifacts either before building them or after building them. This is an example here of what kind of post deployment processes or checks that you can do or run. So you can do that with your overall package. Now, again, if we continue exploring the topic, how do I automate these? You know, OCM, as I described it at the beginning, it's just a YAML file, a big YAML file. Now, this is what flux integration does here. So flux has its own controller called OCM controller that brings all of these together. It orchestrates the process of compiling, if you will, compiling those artifacts into one big OCI image. And in summary, it just makes, it makes sure that your process is running in a standardized way in a consistent way regardless of your environment. But there's one more challenge. Remember at the beginning, I mentioned that I can reference components by ID. How do I do that resolution piece? Remember the objects and executables? If an executable is referencing an object, there's a symbol that need to be resolved at runtime. This is basically also what GitOps or flux does in that case. And the concept called localization is basically it does that mapping between the IDs and the actual objects and bring them all together so that at the end of the day, I'm not just transferring everything as separate objects and then I have to scramble making sure that they're being transferred in the same standardized way. I'm just bringing them all together and with the localization concept so that they appear as one big OCI image. And with that, actually I would maybe end it over to Dan, the interesting part and the smart stuff here. Maybe I've just got to. Yeah, you do something like that and then I will. Cool, all yours. Pop it in here. Okay, so demo. All right, so in our demo, what we're gonna do is we're going to look at applying these principles. So we're going to describe a simple software component, then transfer it across a boundary. And then on the other side, we're going to deploy that software component and apply the GitOps localization. We're gonna do this twice so we can see the process is repeatable. We're gonna do a V1 and a V2. And we'll take a quick look at signing so we can see how OCM can help with securing your supply chain. For our boundary, we're gonna have a public and a private org in a Git T server. And while this isn't truly air gap, that doesn't matter because OCM is perfectly capable of storing any number of component versions in a tar file, which you could then put into a USB fob, transfer into a secure location, and then upload the version components there into a waiting OCM registry, and then just insert that process into the middle of what I'll be showing here. For expediency's sake, now I've done a number of things in advance. We've got one version component already in the public org and source code and Docker images already there. And in the private org, we have all of the boilerplate customized files that are going to take care of the actual deploy. Now, while these things already exist, we will take a moment to take a look at the resources that are relevant to what we're actually gonna be showing here. Now, on this slide, we've got a few of the moving parts that are involved. Not on here is the CLI. So there's a CLI for OCM. I will be using it during the demo. And I guess with that, let's start looking at some resources. Okay, so we'll begin with a deployment manifest, and you should see here on line 26, we actually have a placeholder where we'd normally have an image reference of some sort. And the get ops localization will be filling that in later. So we don't need that here. And here we have a component descriptor, and you'll recognize a couple of the elements from the slide that Moe was showing earlier. Now, this begins our described portion of the show. So in here, we have our ID for this version, this component version, and we have our resource list. Now, we're not using aggregation, but something that OCM does support is a notion of nesting components if you need that. But in this little simple example, we're not doing that. What we do have is a reference to a director that has some manifest. That deployment YAML is one of those manifests. We have a config data YAML in here. I'll get to that in a moment. And then, of course, we need an image, so there's our image. Now, this file that we're looking at, this descriptor, it doesn't need to be checked in to get. It is in this case just for expediency's sake, but the Gardner Group and SAP, for example, they generate these on the fly. Their pipeline just builds this on the fly. They don't actually have one of these checked in. But here, it's expedient. Moving on, next resource. So I mentioned the config data, so this isn't actually part of the OCM spec. Well, the previous file, that's something that's part of the OCM spec. This is not. The OCM spec does say that during deployment, it's required that localization happens, but it doesn't say anything about how that localization happens. And that's because your deployment technology can vary. Here, we're talking about deploying with Flux, so Helm or Customize, but OCM's extensible, so you could be working with RPMs or whatever other stuff instead, in which case the rules would be different. So for this file, okay, so this is something that is going to be looked at by the OCM controller, this resource. And it's going to tell the OCM controller some information it needs in order to perform the localization. So we have here what's gonna be localized. Deployment YAML, what part of that YAML is gonna be localized, you can see the path there. And then what's gonna happen is whatever the location of the image is for this component, that's gonna be fed into that value. All right, so that's gonna conclude the described portion of the show. And if we move over here real quick before we switch away to talk about the transfer stuff, we'll see that, okay, in this private org, we currently don't have any things in the OCI registry. So let's switch over to the command line here. All right, so I said we were gonna take the time to actually add an additional version to that public repo. So we'll have two versions there for transferring. So I'm gonna begin by running this first script here. What this is gonna do is this is gonna make a component archive on disk. And I'll run it and we'll see what it executes. So the first command that was run was this OCM add component versions. And so what that's doing is taking that component descriptor that we looked at a moment ago and it's building into a directory on the file system there, a representation of all that, basically an OCI representation of that. And then the next thing that happens is we run this OCM get resources, which is basically just listing what's in there. All right, so next up is we're gonna take a look at the signing. So I'm gonna execute this script here and we'll see it runs a couple of OCM commands. First one being OCM sign component. So you see here we've passed in the keys and the name of the signature that we're applying and it spits out a bunch of the digests and it applies the signature. And then the second command was OCM verify and you see okay, it's just verifying what was actually in that archive. Okay, so now what we're gonna do is we're gonna transfer that component, the contents of that component archive up into our public org. We're gonna get that second version into the OCI registry of our public org. We're also gonna verify. So you can see that the second command that ran the OCM verify component command there, we passed it the public OCI registry and then also the path to the actual image that just got put up. So that image there is basically just the descriptor for this component version stored as an OCI. All right, so this is where it's gonna get interesting. So in our public org, we have a component. There's two versions. Now we want it in our private org. Now this runs a little longer and the reason why is if we look at that first command, OCM transfer component, it's taking, we're giving it a dash V switch which means copy by value. So in the first repo in the OCI registry, the OCI registry for the public org, what we had, it was an OCI image that described our component, but it just had pointers to wherever that image happened to be according to that space. But over in the private org, we need to have it, that has to have its own copy of the image. So by passing this dash V, it makes sure that any resources that are referenced by that component version, when this transfer happens, those resources will also end up in the target registry where we're putting this stuff. And then finally, we have the verification again. So we're just checking in the destination, if you see the verify component, it's actually private org. So we're confirming that whatever landed in the target OCI registry is in fact what we want. So if we take a moment now and we go over to here, to our private registry, sorry, this one here, where we had nothing, now we have something. And then while I'm in my browser, we'll just take a look at a few of the resources that are in the Git repo for this private org. So first off, we have this component version here. And what this does is this realizes the component versions, the OCM component versions that we've been talking about in the Kubernetes API server as objects, where the OCM controller, so part of the OCM flex integration, will become aware of them. We've got a version spec, so this is going to only work with anything that's home, well, version 001 or higher. And then an important piece here is the verify. So we're telling the OCM controller, hey, you need to check the signatures of anything that you're processing in this registry. So it kind of makes what we ran on the command line a little redundant, but even if you skip that step for whatever reason, you can count, okay, the OCM controller isn't, if you've got that stands in there, the OCM controller isn't going to touch anything that isn't passing verification, it isn't signed. We also have in here a localization. Oops, localization. And this is telling the OCM controller, hey, I need you to create an OCI registry that will have the localized resources we saw before where the localization meant. It's gonna have localized resources in it, and it's gonna add it as a flux source, which means that you can now have a customized influx that is going to refer to that OCI registry and start deploying your localized resources. And you can see here that last stands of where it's saying create flux source, that's what actually makes that happen. And then, finally, we have this customization. Now this is just kind of a vanilla customization, there isn't really anything special about it, other than it's referencing the OCI registry that our localization is producing. So now if you drop back to the command line here, we should see, in a moment or two hopefully, if everything's working. If it's not, then I'm screwed. Let's see here, customization. Okay, we've got our customizations, oh. Registry pod info deployment localized, not found. Okay, so the controller has decided to not cooperate. OCM system, it's died on me for some reason here. Let us, do I want to do this? Okay, you know what, I think I'm going to punt on that. I'm not going to try to debug something on camera here. So we'll give it back to you, Mo. What we should have seen this morning was that it actually deployed. And what I can do is, let's do this. Okay, so we'll just pretend that version one actually got deployed. I don't know what happened there. But the next step would be, okay, that I run this script here, which is bringing over version two, and then verifying that version two landed properly. And while our deployment didn't work, what we can do is over here, we can drill down where we didn't have anything before. We can see, okay, we do have our two images. So this is the private org. It's the OCI registry for it. And like I said, where we had nothing before, okay, we now have these two versions. And I apologize for not having a deployment that worked, but that is life in the big city. So with that, I've seen that. I've seen it working. Would you like to close this out? Do you want me to bring the slide up? Well, thank you, Dan, actually. Any questions? So I asked track GPT, what question should I ask you? And there's one question for you, all of you guys. Hopefully if you were able to follow up with us today with the 25% capacity that you have already, one of the three main keywords, that I said at the beginning that you need to go away with. And I'm gonna give you either my five years old sticker or my cars to the party so that you bring a friend with you. Which one? That's right. Okay. Transfer. Thanks, Brent. Third one. Yeah, the bit that didn't work. All right, you get to choose a sticker or the party cards. That would tell me a lot about who you are. Any other questions? Any questions? Well, cool. Well, thank you very much, everyone. Thank you. Again, the OCN is all about these three key words is how do you describe with the SBOT as we mentioned the software delivery bill of material. As we called it. And the second one is the transport is how do you take all of these and compile them together again, quote unquote. And finally, how do you deliver all of these? That's the whole idea behind OCN. Again, we're here just to get you excited about it. We know that you wanna go and study it by your own. Feel free to just reach out to us after the session. We're happy to help you with any questions. Thank you very much, everyone. Thank you. Good night.