 Okay so I fully recognize that I am between you and beer so we're going to make this kind of nice and quick nice and simple because that's kind of the way that it should be when we're actually working with operators so for anyone who actually was in a little bit of this afternoon's keynote there's a whole concept of operators that were brought into play and so this afternoon I'm gonna spend about next call it 10-15 minutes explaining why operators are actually really really cool this is based on personal information personal experience that I have in actually creating one we'll see what some of that code looks like we'll actually use it in the real world so if I go back to the basics of containerized environments container design is really about well how we would put together a complex system so automotive is a pretty good example of that we have the engineers who are designing how this whole thing is going to play out we have the production assembly line that's going to take all of the pieces from various binary repositories maybe a system that is upstream so it's a base image we're going to run it through a variety of tests we're going to make certain that for example there's no bad coding patterns there's no API issues of one form or another that are going to put in place and then this application this vehicle it's going to be delivered into some form of repository so in our case a registry a car lot for the sake of automotive scenario and some point somebody's going to take delivery of this they're going to bring it down to their system and then they're going to deploy it according to their rules and eventually we're going to have to manage and patch this thing and we're going to have some governance regs that get put in place around it but effectively what we're talking about is a system but when we actually decompose all of this into the container realm and we bring it into a container native cloud native paradigm we lose a little bit of that systems level viewpoint so if I go and take a look at for practical purposes any enterprise application I'm effectively looking at something known as a monolith I have this great system that may have been decomposed into a few things but now there's an initiative within the organization to go and take that and bring it into a cloud native form so we're going to bring in say pods which is a unit of schedulability within an open shift environment I'm going to have many pods I'm going to scale these things horizontally is replicas and effectively that is a method of gaining scale that is method of building out my system now internally we have applications within black duck that are built out as containers but those multiple containers that are part of that set so if I want to scale something horizontally I can apply something known as horizontal pod scaling and it's a reactionary model I can look at say CPU or memory or some other metric and say I don't have enough of these I want to have more now the problem with that model is that it makes an assumption the assumption being that if I want more I'm really measuring the same quantity of thing a web request a logon request query result a new entry into a database all those things are roughly equivalent in size so if I have something that's processing logons within the container well having more of those that's a linear scale it's a pretty straightforward model and when we start to add state because after all enterprise applications have an awful lot of state associated with them they're still also represented as pods what we really need to do is look at a microservices model in terms of service level agreements what are we wanting to guarantee under what conditions that are going to be effectively what the world is going to look like so that's where an operator really comes into play I want to enforce a set of relationships between the pods so I've got pod a and all of its replicas it implements a container image maybe even multiple container images those things are related to other things in my quote unquote and tiered application that is distributed around I want to make certain that I established floors for my scalability I can go and define replication controllers and replica sets and all of these kinds of things and I can scale them up but there's nothing that says that somebody can't scale them down and when they scale them below some floor well I've now violated whatever my SLA is going to be I also want to ensure that out of band modification doesn't occur that some human who has access to the UI can't go and say I only want to have three of something that should have six I want to have a hundred of something that should also only have six that type of enforcement of what the the operational paradigm should be that's part of the operator itself I want to make certain that it's a very prescriptive scenario so it's not just reacting to the environment but I can go and say I need to have this capacity for reason X now I'm going to use the black duck for open shift platform as an example of how this is actually going to work out so last year at Red Hat Summit we introduced an application integrated directly within the open shift environment to scan for all the container images independent of the registry wherever they came from and so that gives us the ability to see where events are coming from whether they be a pod event an image stream bring it into an environment and automatically scan everything that's associated with this so this effectively becomes a very complex system one where we have not just the components which are inside of the open shift environment the scan controllers arbiter scan engines and so forth but also the analytics engine and the analytics engine is something where if I have more than one cluster I'm going to need additional capacity associated with that reality inside the analytics engine we have obviously the scams that are going to be coming in and a bunch of other activities that are going to occur a new scan goes into a container that we call a hub scan and its job is to persist some information to a database and build out a queue and through that queue kick off a series of jobs which are going to process those scan data elements and the hub scan well it's a scalable entity a job runner which is effectively the thing that actually runs the jobs that's a scale entity the bigger the cluster the more jobs that can come in because the more pods the more images that it's going to be able to process I might have a centralized analytics engine for both dev prod and production so that's now three separate clusters potentially and they all need to play into each other very well and of course on the back end we have our knowledge base where all of the metadata around open source risks are contained this analytics engine in the real world actually is 13 separate container images represented in 11 pods or 11 deployments so I now have some entities that are going to have a scale of one in other words I only ever want to have one instance some entities that are going to have a variable scale dependent upon the actual number of scans that are occurring the hub scan and some pods that are going to be based on the quantity of jobs that need to be performed the job runners the amount of memory that's going to be associated with each pod is going to also vary and this is a function of both the quantity of activity that I want to run in but also well the activity of the moment how many scans that I have coming in and so that effectively boils down to what should the world look like and so in an operator paradigm this becomes pretty straight for I'm going to start out with the finding a custom resource my hub capacity my analytics engine capacity so it's going to have a name and it's going to have a spec now in this case actually hard coded something here I say that I want to have six job runners and two scan clients at the bottom that's the status that's the representation of the real world as it stands right now so those job runners are actually running that's the amount of RAM that's associated with the environment similarly I have two scanners and that's the amount of RAM that's associated with them if I wanted to scale these up I would simply go and reapply this YAML so an OC apply dash that YAML that gives me a way to define an SLA that's still a human scenario but the operator SDK allows us to do is make this more programmatic so this is all of the code that is necessary to actually implement a new operator so it starts out with saying that I'm going to have a hub capacity I'm going to have what's known in this code as a reconciliation loop the goal of the reconciliation loop is very straightforward if their system doesn't agree with what this says fix it so he puts the wrong version so he puts the wrong amount of RAM so many goes and delete some pods somebody goes and adds too many pods some system goes away this is what this would all end up looking like and so well I'm going to make this really really simple and really really boring so let's see if I can do this one handed here I'll put the mic down so right here I have a black duck installer and I just need to see what I've got here so I'm just going to do a simple LS so I'm going to run the install for Kubernetes because I know that this is actually a raw Kubernetes environment I'm going to answer a couple questions in here so the demo gods are willing once this install completes what's going to end up happening is that you're going to see the scan and job runner counts increased from four to nine and so effectively what's happening is that I'm going to generate an additional capacity for this system in real time so today when I started this environment and now we have four and eleven I had one cluster with four nodes another cluster with five nodes another cluster with three nodes and I've just added another cluster a Kubernetes cluster to this system and it dynamically scaled itself up so that it has the capacity to handle all of the image activity that we anticipate to have from this new cluster all with a centralized analytics engine all configured at install time all done with an operator if I want to get really fancy I could go in here and actually try and decrement the count and it will automatically reconcile itself for that's the power of an operator that's why the operator SDK is really cool that's why you should be looking into them as well maintaining system state across container images across pods in a distributed system is a little bit of a complex task with an operator SDK it becomes a whole lot simpler I'm here to answer any questions afterwards but this is this is what operator SDKs bring to the the system I'm happy to talk about anything related to container security or as a result of this and maintaining overall system state and open source risk thank you