Here you do not quit. There is no quitting at the Naval Special Warfare Preparatory School. It's all about the humble professional, all right? That's who we're looking for here. The coaches are great. They're actually positive motivators. The advice I would give to somebody who wanted to go through this program is to definitely come to the prep course. The evolutions we do every day, it's more than you do on your own. The bottom line mission of PTRR is getting them ready for buds, getting them ready for first phase, second phase, third phase, physically, mentally. The basic mission of the Naval Special Warfare Center is to train, seal, and switch candidates. BCT is a crash course into some of the basic fundamental boat guy skills, the physical fitness, and navigation is the biggest thing, some basic seamanship skills.  I always thought the seals were the finest unconventional warriors the United States of America has, so I just wanted to be part of them. The small, quiet brotherhood of SWCC really appealed to me. I knew it was going to be hard, but it's just like a whole other level. Buds is hard, and for some it makes it even possible. For some they're going to fall on their faces a bit, but I think that is setting them up for success. The body aches and pains, but it's worth it. You start playing mind games with yourself and you just have to talk yourself out of it. Seals can't be mass produced. It takes time for you to develop a competent seal. It's all about teamwork. One guy doesn't keep up with the rest of the group, makes it a lot harder for the other six guys in your boat crew, so timing and teamwork. We're not here for attrition. We're here to make sure that the right guys make it to the seal teams, and who knows better what is needed in the seal teams than a guy that was there.  You're looking for character. Things that you really can't teach, things that are just there. Things that's there, you can form everything around that. My heart's in it. There's just nothing that's going to stop me, so this is a job I want to do, and I'm not going to lose this opportunity in my life. Some of the evolutions are actually pretty fun. Rock portage is a favorite of mine. Coming in, riding the waves in, and getting the boat up and over, it's a good time. They can endure 10, 15, 20 times the amount of pain and discomfort that they thought they could. When a light bulb comes on, they realize that we really can't hurt them. That they can push past any amount of pain and discomfort and physical barrier that we put in front of them, that they can attain the standard that we're looking for. When that light bulb starts to come on, it's pretty impressive. This is a monumental challenge. We're just at the beginning of it, and it's just going to get bigger and better as it goes on from here. What we do is we start off with them in a classroom environment, with the equipment in front of them, bare bones, basic, and we put it together from attaching the battery to an antenna, pushing each button, and we do it alongside them with them. It's a reward when you see that they actually picked up your knowledge. I wanted to do something a bit more exciting, and this, every day, it fulfills my appetite for excitement. We're kind of close to the home stretch. Out through buds, jump school, seer school, all the other schools we have to go to before we get to SQT.  The sense of brotherhood is what I want them to leave here with, because when they leave here, they're representing us. They're representing a small unit, an elite unit that has a huge heritage and history behind it, and a lot of respect from a lot of people. So when they go forth and go out in the world and meet people, they're not only representing themselves, they're representing every one of us, and the tradition that the CO teams have been built on. The idea here is to get guys ready for cold weather training, and we're setting guys up to be able to move through anything they might face, learn to survive, ready to fight anytime you need to. The training we're doing out here is real, I mean it's intense, it's not the instructors kind of, they teach you everything they need to know, but there's a certain point where you're on your own and it's you and your guys. Well this week out here we were learning pretty much how to stay safe and shoot movement, communicate together as a team, and how to check your buddies to the left and right of you, how to stay safe and pretty much work as a team. Today is the culmination of 64 weeks of the most physically and mentally challenging training conducted within the U.S. military and the free world. You know I pretty much earned the trident for America and I got to earn it for my team. Any time you can put the skill set that he has together with passion, you see what the product is, and I'm extremely proud of him.   Well I do love this country and I'm very patriotic and I'm proud to serve the military, but at the same time I knew what I wanted to do, how to be the pinnacle of what I can perform and joining the Naval Special Warfare was exactly what I was looking for. I wanted to be the best of the best.


Welcome to Microterrorz. Scary stories for kids. Where it's always the spooky season. Full of chills. Thrills. And spine-tingling spooks. Microterrorz are family-friendly frights for those ages 8 and up. And while our stories are for younger years, we are still talking about things that go bump in the night. And some children may not be able to handle what others can. Parental consent is recommended. Now for tonight's Microterrorz. The Eyes by Scott Donnelly It was a snowy January evening when the eyes first arrived. Well, they didn't really arrive. A parasite did. One that lived within a meteorite that came from space. It had crash-landed somewhere in the Rocky Mountains, close to a fire lookout post. There was one man, one unlucky man, named Jose Roberto, who was working the post that night. He saw the meteorite burn through the heavy layer of clouds above, soar through the wintery night sky, and crash just over a nearby snowy ridge. Afraid it would cause a forest fire, he quickly radioed into his command center and reported the event. As the minutes passed by with no fire, the cause for alarm quickly faded. Jose's curiosity, however, didn't. Jose descended from his fire lookout post, hopped on a snowmobile, and rode through the frigid conditions. More snow was just beginning to fall as he made his journey. Within ten minutes he had arrived at the crash site.  He radioed in once more to describe what he was seeing, and that was the last anyone ever heard from Jose. Knowing what we know now, twelve months later, he must have inspected the debris too closely. The remains of the meteorite were cracked open and oozing a sticky substance. Within the oozy matter, tiny parasites, translucent and smaller than the average earthworm, emerged and clung to Jose. They went for his eyes, which they were easily able to nestle into and killed all of the nerve endings. Jose's eyes fell from his head and his body fell into the snow, where it would not be recovered for several months. His eyes, however, now vessels controlled by the alien parasites, began to move on their own. Something within our planet's atmosphere interacted with their genetic makeup, causing them as well as the human eyes they now seized to grow in size. By the end of the first day, they were the size of baseballs. By the end of the first week, they were the size of basketballs. Within the eyes, the parasites multiplied, driving themselves out of the sclera whenever they crossed paths with another human.  It was an unnatural, unstoppable and vicious cycle. The eyes had taken over Colorado and the surrounding states within two months of the first meteorite crashing. Within six months, the eyes had taken most of the country. Some of them had even grown to be the size of bounce houses, rolling through city streets, suburban neighborhoods, deserts and beach resorts. The military attempted several times to engage and fight back, but the natural toughness in which the eyes had now adapted made it nearly impossible. Some of the smaller ones were able to be wiped out, but anything larger than a beach ball was nearly impossible to injure, let alone annihilate.  Those they chose not to infect for whatever reason, they would instead intimidate by landing an uncomfortable gaze upon them and emit a low-pitched droning thrum that would send a frightening warning rippling through their nervous system. It would force them to feel fear, force them to obey and accept that Earth now belonged to them and they had no intention of ever leaving. As a full 12 months since the initial meteorite crash has now come, there was a lot of information out there on the eyes. They may be a physical presence in the world, but as far as their technological skills go, they are less than primitive. That has allowed communication between humans who are still alive. Whether it be through phone calls, texts or internet exchanges, the eyes seem unaware of that angle of our way of life. Most humans have reduced to staying indoors these days, studying the eyes from out windows and from remote controlled drones. The invasion has spread worldwide, with Antarctica the only place allegedly not being touched by the eyes. Those are just rumors, though. Aside from quick missions and expeditions by scientists who have military escorts, leaving our homes is basically against the law at this point. Our survival depends on it. And even those scientific expeditions usually end with only a fraction of the team returning and more eyes ending up out in the world. There is no plan currently to rid our planet of the eyes. They have made that hope nearly impossible. We may very well be looking down the scope at the end of humanity as we know it, but with survivors around the world secretly working behind their backs within the digital world, passing ideas back and forth, desperately searching for weaknesses, the hope might one day be there. But until then, we need to stay vigilant and determined. We need to stay focused on survival and work together. We need to continue to operate within the shadows, within the digital realm, until we have the solution. Because if we show our hand too soon, or act too hastily, it could all backfire. The eyes learn quickly. They adapt. Within a year, they have grown to monstrous sizes and figured out how to dominate the human race with mental intimidation and an obscene physical presence. Who knows what another year could do for them? For now, though, we'll continue to study, research and plan for our survival. We just need to be as cautious as possible and do it all off their radar. Because they are always watching. Word searches, mysterious mazes and more. Microterrors.com is also where you can find us on your favorite social media, and even send in your own scary story for us to tell. Plus, you'll learn more about our author, Scott Donnelly, who has other horrors for both young and old. I hope you'll join me again soon for Microterrors, scary stories for kids.


Thank you very much from the bottom of our heart. We appreciate you awarding us or honoring us with this award It helps us raise our profile and it's definitely going to help us reach girls around the world more girls around the world Increasing young girls participation in the technology sector is key to our future and a Technovation we're trying to do exactly that I forgot my prop there, but anyway, this is a phone this device right the mobile device is how more and more people in the world are going to access the internet and We've taken the connection of the mobile device to young girls and you said how can we make them? shapers and creators of the technology of tomorrow and we think we've hit a sweet spot our program has now been in Has been running for four years where we're a startup In the valley, but we're growing. We have the key metrics of the successful startup We're growing. We're scaling and our costs are so low So so that success in our mind we've reached girls in 60 countries from Afghanistan to Zimbabwe and what we do is we empower the girls to Identify a problem in their own community and then give them the tools that they would need to solve that problem locally and When you do that when you when you shift that mindset in a young girl that find a problem and will help you solve it and in the process Will help you think like an entrepreneur? So we'll make sure that you understand that you're not the only one who's solving the problem that you should look around to see if There's competitors and if so, how are you going to get better than them? And how are you going to grow and how are you going to pitch and how are you going to present? And that process is like watching girls bloom in front of your eyes and I started off with tech innovation as a mentor four years ago Today and in the last four years. I worked Dedicated my work to making sure that the program grows as a global ambassador This three-month program has changed or at least touch lives of thousands of girls Many of them are now at university, you know We did a look back study for four years and many of those girls are now pursuing Computer science and technology role. So you think we're doing what we set out to do, but we haven't done it alone I whenever I pitch and I'm pitching just in case you're not getting it Technology has needs three things access to girls access to mentors and access to space right and The mentors are usually women who've got two or more years of work experience They have they don't have to have any technology background because the curriculum will teach them that and that the space is where businesses come in and Those three things are really making tech innovation into a movement because we've got young girls. We've got Women in companies right and we've got companies who are supporting these women You bring those things together and you've got a nice mix And then what happens is communities get together because then communities come in and say, okay We will support your regional pitch event or we'll give you money for the reception or we'll give you money for t-shirts And we're making this into a movement. So in Kenya Technification is supported by Safari comm and that was because this mix has really worked And we're hoping to replicate that around the world So at the moment we're in 60 countries with this award and with all of you movers and shakers of New York I'm going to put you all in my role of that and then reach out to you tomorrow We hope to take this program worldwide. There are a hundred and ninety three countries or a hundred and ninety four Depending on which year you're in we would like to reach every Country in the world by 2018. That's our goal And I really hope that you will help us do that and again I think the ITU and the UN women who really helped us with this award. Thank you very much


All right, everybody, welcome back to another OpenShift Commons briefing. Today we have Ricardo Zanini, who's from Red Hat and a senior software engineer. And we're going to have a topic that I don't really know a lot about because I haven't heard a lot about it, which is why we invited him here to talk about event-driven applications using Pageto serverless workflows and K-Native. And so K-Native, we've had a lot of talks about, but Pageto is, I think I'm pronouncing it, mashing up the name wrong, but we'll let Ricardo tell us a lot more about this, and then we'll have live Q&A after the presentation and the demo that he's going to give. So take it away, Ricardo, and introduce yourself. Tell us what you do at Red Hat and tell us all about this. Sure, yeah, thanks for having me, guys. Well, my name is Ricardo, like Diana said. Today we're going to talk about event-driven applications and how we can create those business applications using the serverless workflow specification and the K-Native platform. Well, I'm a software engineer. I work with the K-Native, actually, project, and I'm also helped in the CNSTF serverless workflow project specification as well. So we work in the both ends in doing the specification side, you know, specifying the workflow, the SL, and also in the implementation in the K-Native engine. Well, let's get it started. Let me see if I can. All right. In the agenda today, I'm going to introduce to you guys the serverless workflow specification and what we are doing there. You know, just a brief introduction to the project. I will try to not talk too much about it, because there's a lot of surities that you should take a look in the specification and figure yourself for all other details. And about the implementation itself that we are working on right now, that is the Coach2Project that we call. It is a business application project for designing and creating business applications. And after that, I will introduce a small use case, you know, for someone to feel comfortable. It is like our online store or the processing. So it is a super simple use case. Everyone is super familiar, I hope so. And we are going to run a super short demo as well. It's simplifying how the workflow is reacting upon events and what he is doing on a creative overall platform. So about the CNCF serverless workflow specification, we say CNCF because the serverless workflow project, it is a sandbox project on CNCF institutions. So you can go there in the sandbox project and you see the serverless workflow specification project in there. And we are accepting contributions and then it is open source, pass to license, you can go there and then figure things out, ask questions and maybe introduce some new features that you like. Or if you're keen to implement the specification as well, we can help. We have SDKs, we have a lot of tools around the specification that can help you and to understand, to implement, maybe use the specification in your company as well. So what it is, the serverless workflow specification, it is something that we are targeting, it is to create a declarative workflow language so based and to target for specifically serverless computing technology domain. So that means reading events, producing events, consuming events, correlating them, call functions outside the scope. Have all those things run, it's more fully, we can out escalate the functions up and down and do all those features that you already know about serverless computing. But having these in mind in the in the in the workflow language as well. This quote I brought from the website so you can go there and visit the website, understand what it is with more details about that. Why? Why we started with this crazy project? Why it is important for us? Well, first that we believe that workflows can capture and organize business requirements. So what it is, you can instead of grab your maybe Java, Go or Python code and bring to our business analysts and explain to them, hey, here's what we are doing in this service. Here's what is going on there. You know, look at these these conditionals here. We're doing this and that. Instead of that, you can just now bring the workflow to your business, your business person and explain to them what is happening there and they can understand. They can even help you design the workflow or they can even create a workflow themselves and handle it to you in order to have that run into a runtime, maybe. So that's one of the the the idea behind it. The specification also targets to be a vendor neutral platform independent workflow languages. So what this means means that we do not tie the specification with a specific vendor. It is not code. There's not anything like that. It is just the specification. Anyone out there can take the specification and implement in your runtime and have a workflow runtime running, you know, based on the specification. It is platform dependent because we're not tied with a specific technology. We do not say, hey, the workflow must be implemented in Java, for instance, this is not the case. So anyone can just bring the specification and share and use that as they please in their in their implementations. So imagine that having this common way of describing a workflow, we can, you know, potentialize and creating creating some common libraries to be shared among all the the the runtime is the implement the implementations itself. We can create tooling around the infrastructure around that around all the workflow and having all of them, you know, to have a common way to describe something and create something together. That's the the the the nice of the being no unopened source specification. So like like I said, being vendor neutral, we increase productivity, productivity and learning curve. You don't have to learn all of those workflow language that is that is out there because nowadays if you go in the IT news, you see that every day, every week we have a new workflow engine out there. So instead of that, we are proposing this like on a specification that can be run in lots of runtimes and those runtimes can be, you know, offered by you run on Kubernetes and OpenShift, you know, Google Cloud can have a runtime for the specification as well. AWS, Azure, whatever cloud provided out there, they can offer their own workflow service based on the specification. That's a win-win situation that we believe, you know, that everyone implements the same DSOL for specifying workflows. So the users would gain a lot of that. The specification is based on standards. So we looked around and saw lots of standards out there. So for instance, to define an event, like I want to consume this event in order to start my workflow or I want to produce an event at the end of my workflow or I want to produce an event if I go through this branch on my workflow. And we use the cloud events specification to define this event in the workflow definition file in the workflow definition itself. You can also run and not run but call external RESTful services for instance, using the workflow specification. And we use the OpenEPI to declare how you can create those calls from the workflow itself. So when you, for instance, you want to call, when you receive an order, you want to call an external service to validate your order to do something else. And it is a RESTful endpoint. You can express that call using the OpenEPI specification. So you bring the OpenEPI interface into the workflow when you specify which function in there that is defined in the OpenEPI specification that you wish to call using the workflow DSO. Also, it is of course based on workflow patterns. So there is execution handle order or handling management data transformation. So there's lots of patterns that we envisionize in the, that we view as useful to be, to have in the DSO in the specification itself. You can see lots of all those information in this link here that it goes to the specification and you'll see all of the features that we have in there. Well, the workflow itself, it is based on a state machine diagram. I say that it's based because we have start and end conditions in our workflow. So when you start and you go from state to state, in a fluent manner, so each state is responsible to do something. It is responsible, for instance, to produce an event or to call an external function or to decide to split between two brands or to go to one branch or to go to another branch. I can call another sub flow, for instance, and there's a lot of type of states that we have in the specification. As I said, you can go to the specification to see in the details, everyone that we support that we have in there. And if you feel like that we don't have something that it might be interesting, you can propose a PR or send or which are odd to us and say, hey, this should be nice to have in the specification and we can talk together and figure that out. For the data processing itself, it is like you enter with data and you go out with data. So in between, you have this pipeline of states, going through one after each other and then you can have like a data processing with the data that you're expecting to receive on your workflow. The specification has like those three main, this is the backbone of a workflow, let's say this way, we have functions, events, and of course the control logic of the workflow. The first thing is the functions. We define the functions as, for instance, a call to a restful service or a call to a GRC API as well. So you can define the functions, the spec file of the open API, for instance, the idea of the function that you'd like to call in this section of the workflow. In the event section, you declare how you're going to consume and how you're going to produce those events within your workflow. So for instance, you are listening to our ordered event and you're producing maybe shipping events or you're producing approved events or in a scenario like a bid service you were listening to bid events and you're producing maybe notifications for users that are listening to that bid, for instance.  And it states it is not the least important part of the workflow control launch that is where you describe the workflow and what this workflow is doing, like the data processing and how things are going to go. They're like calling these functions or producing these events that you're declaring there or consuming events that you declare or branching the workflow, the run of the workflow into more sub flows of whatever control logic that it'll come up with or your business need in this part, this section of the workflow. As always, all these slides that I linked here to a specific session in the specification. So you can go there and see for yourself all of the details of each session and understand more in details of what we are trying to express in here. I'll try to be brief because the presentation can be long if I stay on one or other details. Well, every time that we present the specification, talk about specification events, people ask about implementations. So, well, it is nice to have a specification and it is also nice to have an implementation, right? Because that's the point of having a specification. We don't just create a specification to be in there. You create a specification to be implemented. So we took the specification. Now, talking about the Cogito project, we took the specifications and said, hey, there's a petition here when we can actually implement a specification and offer to our users a way of then to declare the workflow using JSON or EMO files. In a declarative way, and also if there are other vendors out there implementing the specification, they can migrate to Cogito easily, using the same thing that they learn with this DSL in other implementations with Cogito as well. So it's a work in progress. So we are in tech preview actually right now, community-wise, of course. There is some limitations of the implementation that we are working towards to implement, but the basic things are there and I'm going to show you guys. A little bit about the Cogito itself. It is, I like to call this like a cloud-native solution. It is a product with lots of components. So I'm calling like a cloud-native solution for you to build business applications. So business applications that you can solve business problems and then what I mean by that. It is like we have an engine that is capable to process rules in a specific domain driven DSL.  Lots of computations and calculations that it is more or less cumbersome to have that in your code base. So you're externalizing rules and you have all of them defined on those rules and you can give to the engine in order to run it. You have also, we have also an engine capable to run complex decisions based on the DMN standard. We have of course, serverless orchestration feature that is super brand new, something that we are working now that is the implementation of the CNSF serverless workforce in a specification. We also have an agent capable to run BPMN based files and we offer some tools focused on cloud. So for you can bring everything all of your business applications that you created with Codege to the cloud. So we have a specific tooling for that. We have like editors. So it is a business application driven project. It is of course, we have editors for you to design and create your BPMN process for you to create and design your DMN decisions as well, your rules and that you can download on a VS code mark at place. We have an online editor as well. If you go BPMN.new or DMN.new you see our online editor there and you can start scratching your process or your DMN right away. You can also download it from our website, just download the editors. We are an agent, like I said, based on Druze, BPMN, OptiPlanar.  Like Druze, BPMN, they are super famous. Yeah, popular, let's see. That's correct, the correct word. They're super popular frameworks out there, Druze and Druze and process based on BPMN. We are also working on supporting services capable of giving support for your business application. So for instance, if you run a process and you'd like to see what is happening inside that process, we have some supporting services that is capable to run on cloud that can give you a glimpse of the process itself and what's going on out there or even a user task, for instance, in a given process, you can go in this supporting service and see the tasks and then approve a task or go forward with a process and et cetera. So there is a lot of features out there in those supporting services as well. And like I said, some cloud tools. We have a specific Kubernetes operator for deploying code to applications on OpenShift or on Kubernetes. And I'm going to use the operator in the demonstration. So we bring and pack this all together and that's what we call the Code to Project. So this is a feature of a handful components to help you design and create your business applications and deploy it on the cloud. Let's go to the use case straightforward. It is, you mentioned that you have this online store, right? And after new orders, you create an event in your architecture. Every new order we create a new event and then this event is being consumed by this order approval service. So the services will be some sorts of rules and some sort of business requirements. They say if it's approved or not. So that's the state of the architecture right now. And John Doe, the CEO come to you and say, hey, before approving the order, I'd like to go through a shipping and fraud verification first. So whatever comes a new order before approving it using whatever features that you have now do a shipping and a fraud verification for me, please. And I'd like to run that in parallel because we can then concentrate the approval in the end of this order processing. So it came up with, okay, so what about like creating a pre-processing workflow? So when it comes a new order event, we are able to split this process inside like, two events. You can create two events after this workflow within this workflow. We create a shipping hand list event and a fraud evaluation event. So it's component in the architecture can listen to this event and react upon it and do whatever they want with that. So in our example, we have the International Shipping Validation Service and we have the Domestic Shipping Validation Service that are listening for the shipping events and we have the Fraud Evaluation Service that is listening for the Fraud Evaluation Service. Also we finish with the shipping validation, we meet a new event saying like shipping verified or something like that.  And in the end we have our order approval service again and you can correlate all those events by like for instance the order ID and say, hey, I received the shipping approval, I received the evaluation approval and I received this new order event. So I can correlate the three of them and then they can proceed doing whatever they want. So this is a small, I excerpt for a small processing use case in our example. So I have like five services running around, none of them knows about each other, they just listen about events. So that can be an event-driven architecture, an event-driven applications. They are just reacting upon events and meeting new events and they can add new components in your architecture. So you have this flexibility of creating things around your architecture, removing an event, adding another. So for instance, tomorrow you won't ship internationally anymore and you just remove the international shipping validation service. There's no use anymore, right? You won't have to code something new or anything like that. Just remove an event from your, you just remove a service from your architecture and you stop doing that thing. Or no, well, I wish to add some new capabilities. So I add a new service in order to listen to this event and do whatever they want. So this is more or less what an event-driven architecture can, the benefits of an event-driven architecture can give to you, you know, async processing, this kind of flexibility, you know, composition and orchestration of events. That's why we are talking today, you know, like about the workflows for instance. So let's try to zoom in into this first service, the word preprocessing workflow. Let's see how it is doing its thing. So I draw this workflow like in order to pre-process my order. So I receive this new order event and I will process the order. I split into two parallel states saying I will handle fraud in one state and I will handle shipping in another state. So I can figure if I, which kind of events I need to, you know, produce for my architecture. So this is happening inside that preprocessing workflow service. So this is more or less what looks like my workflow. Let's see how this workflow works. And it is described, how I'm describing this workflow in a Yable format using the service workflow specification. So I broke the workflow into three workflows. I have the main workflow, the water workflow and I have one state here that we call the parallel state, you know, calling those two sub-flows, the fraud handling workflow, the shipping handling work. So let's take a look at it. The first part of the workflow, it is the, I call the headers, you know, when we describe, we give some information about the workflow. So the name of the workflow, the identification of the workflow version for you to control the version of the workflow, some description for it. And I will say which state I will start my workflow in this case, the receive order. The second part, I have the events definition when I define how I will consume that event. So let's say that in this particular use case, I have the order event type, cloud event type. So someone out there, you know, any service out there is creating, is producing this ordered event, cloud event for me and I'm capable of listening to it. So the first state that receives the receive order, it is capable of, you know, listening to this event, the order event here that we tie with the name, like order event name. I have the event by his name, it is the order event here. And when I receive this event, I say transition to process order. And this state process order, which I call type parallel, I will create the branch fraud handling, shipping handling. Let's say my engine will call, you know, at the same time in parallel those two sub flows. And as they finish, I end my workflow. And to create those workflows, I'm using the serverless workflow plugin and you can download it in the VS code marketplace. It is maintained by the serverless workflow community, specification community and you can go there, see the source code, do whatever you want, download it and please hate five in the plugin itself. And we have this nice feature that is you can generate diagram using any workflow file. So it uses the, you know, this as simplification of, the event diagram not from the UML. So we have a start, we receive the order. It is an event state. We process the order in a parallel state and we create two branches. So let's take a look into the first one, the fraud handling workflow, same thing. I have the name, which state I will start, the version and the events that I'm going to produce. So I'm going to produce a type event orders dot fraud evaluation. And let's take a look into the states. So we have a data conditioning here, which is when we start this workflow, we analyze the data inside the input of my workflow and we perform a JSON path expression into this data. And if the total of my order is greater than 1000, I would say that we need fraud verification. If it is under 1000, I won't need fraud verification. Of course, this is super lame. Next example, in real use case, you won't do things like that. You can like create an estate before that. Like you can call a service to evaluate some aspects of taxes or behavior of the customer, whatever thing you want. And then you can say to the workflow, hey, this order looks like that they need to perform is to be validated the fraud or something like that. So for this case, to simplify the conditions, we have this event type switch and I have these conditions in here, very lame, but it is super nice. And I inject into my data state a new attribute to my workflow, the fraud evaluation equals true. And then I produce the event fraud evaluation. And this event contains in the data attribute everything that I created here in the workflow. So it goes with the fraud evaluation equals true and the order information as well. So anyone that is interested in the orders that fraud evaluation event can do something with it. All right, so let's do the same thing that we did and let's generate diagram using the plug-in. And as you see, we see that we have like a fraud handling sweet state and depending on the condition, I'm going to say that we can produce a fraud evaluation. If not otherwise, we just end our workflow. Well, very simple and hopefully you could understand what is happening there. The other workflow is the shipping handling workflow that is being executed at the same time as the other one. More or less the same thing, we have now two types of events. We have international shipping order event and we have domestic shipping order event. So depending on the context of my order, I will emit, I will produce an event like an international shipping order event or a domestic shipping event. And more or less the same thing that we did there, we have also a sweet state case here. And the first condition it is like, if it is within US, it is a domestic shipping. If it is not, it is an international shipping. So again, super lame example in a real use case, you can like call a shipping, maybe you can call it maybe a Google service for localization to find the address, the correct address and then to figure some other things out of whatever and enhance your order data with some output for this service, for instance. But in this case, if we realize that this is a US order, so we transition to domestic shipping, if it is outside US, we handle for international shipping. So for the domestic shipping, I'm going to add a new attributes to my data that is shipping domestic, otherwise I'm adding shipping international to my data and I will produce an international shipping order and I will produce a domestic shipping order. Again, super simple, but you can see the powerful of something. So imagine that you're talking with a business person and you can bring the DSR to them and explain, hey, this is what is happening inside this microservice. This is what, which kind of events that we are creating, that we are consuming and what we are doing with it. So for instance, in a real use case, you can say, hey, I'm calling this Google service and we can receive this kind of information and we can process this information as we please using the workflow. Let's see how it looks seeing the generated diagram here. So we have the shipping handling state. It is a sweet state and there you go. It can be a domestic shipping or it can be an international shipping as well. As you see, in the end, we are going to produce an event being international or domestic shipping whatsoever and we are going to win. Well, that's what's looked like the event when you see it in this perspective. And of course, this is the, when you are designing and we are creating your workflow. When it turns out to deploy and into a Kubernetes or on a ROP ship cluster, for instance, or in the cloud, you can use the capabilities of the Kojito. We have CLI. So in this case, you can deploy the workflow using this command line like Kojito deploy, that is the action, the verb of what we are doing or the server's workflow, that is the name of the server that I gave and you can add all those YAML files into the CLI and the CLI will push in this case to an open ship cluster. And in there, we are going to generate code based on those files and we will create an image, a Kojito process runtime image into your internal web registry and the Kojito operator will be capable to create the Kubernetes resources and the Kojito resources to deploy and have this to manage this workflow running within the platform itself. And of course, for this use case specifically, for this working with events with Kojito, we need the server's platform. This also works on Kubernetes, but on Kubernetes, you can build within a cluster. You have to build the image yourself and then push the image to the cluster and the Kojito operator will take your image and it will perform the same steps. You've created the Kubernetes resources, you've created the Kubernetes resources for you and for your servers to be connected with the Kubernetes broker in this case. Then I see that we have some chat going on there. You'd like me to stop here and or we can answer the questions after the... Let's answer the questions at the end and most of the chat is me trying to get people to ask questions. So this is a good point. If people have questions, type them into chat and we'll make it happen at the end. Thanks. All right, no problem. Yeah, I know if I'm rushing or not. So you tell me, all right. When also we have the service deployed on OpenShift, this is more, sorry about all the technical details, but this is how it looks like from the Codjito operator perspective, how we deploy the service in there. So our service will be like an event source or this event source can be any other thing. In this case, we have the serverless workflow in here and we are listening to the new ordered events coming from the KineDev broker and we're consuming using KineDev event in triggers and that triggers an event for us to listen to it. So the ordered event comes here into the broker and we listen to it and we start our workflow. Our workflow will produce events to the broker using sync bindings. So we produce events to the KineDev broker and any other service out there, any other, can be a KineDev service, can be any deployable pod or anything else, in the spectrum of the KineDev server platform to be listening to this event and to react to it. And this is what we are going to see in this short demonstration. Let's me see. I think this is not, let me try to zoom that. Well, can you guys see this? Yep, looks great. All right. So I'm producing an event to the platform and indeed the country is US, the total value is 1,001 and it's an iPhone 12 order. So I'm going to push this event to the platform and you see what will happen in there. So in this terminal here, I have three listeners of our KineDev, of our workflow event producing events. So in the top most, we have the fraud evaluation service. So we are listening to the events from the fraud evaluation service. We have the, I'm sorry, the shipping international here in the left and the domestic shipping here in the right. So once one event comes to the, either through the fraud evaluation or to the international or domestic shipping services, you will see the produced event in here. So let me push the event. It is like a fire and forget type of event. It's taking some time because my internet connection is not that good. So I push the event and we can see that we didn't have any pods and listen to that because those are KineDev services. And we receive a fraud evaluation because the value is above $1,000. And we received a domestic shipping because the country that we shipped our iPhone, it is within US, it is a word from US. So that's why it is a domestic shipping and you can see it in there. And with we go to the OpenShift cluster, you can see, hopefully you can see if my international connection helps, help, help. It is a live demo down. Yeah, you already saw those like, because I'm fetching for the pods of the shipping international service and you'll see there is no resources in there. And yeah, I don't know what is happening. I don't know if I need to refresh this, but whatever. And you'll see that is this event coming in here and this event coming in here. So there is some extensions as well. So we have some information about the process itself. And here you can see that the fraud evaluation service received the fraud evaluation equals true and the domestic shipping service received the shipping domestic. And this shipping domestic it is not, it is in here but the fraud evaluation is not in here because we run one after the other. Well, I see, yeah, we can see the pods in here and because we were talking, Connecticut will destroy the pods because they are not being used. So that's why we are seeing terminating me here. So let's say that we have, I don't know, maybe a new order from Italy and that's above $1,000 as well when I'm gonna send it. Quickly this time, because the pods are right there. I'm creating the shipping international pod in order to listen to this event and react upon it. And the same thing, you won't see fraud nor domestic here because we entered in that branch that we just received from the international shipping. So now try to imagine this in a real use case where you have to equalize your resources. You have to save resources in order to have a more profit company. So in this case, let's say that you receive, I don't know, maybe 9% of your orders, they are domestic. So you don't have to have the international shipping handling services be up there all the time. You can have the workflow to control all the logics and you can break through into categories. You can break your domain into more specific things and be flexible enough to distribute your services around your architecture. And you won't have all the, you won't waste resources into something that you won't need for some times. So this is a nice example, a nice use case for YouTube and maybe reevaluate some of those things that we are doing. Because normally people create like, oh, huge microservices, they are doing lots of things. And maybe sometimes it is nice to just break into specific parts and make them run into this fashion. Like I can create like lots of domestic orders or lots of international orders and having this part of my system not producing services, not producing events, not whatsoever. So I can reduce my cost and sometimes that will help a lot. Well, let's get back. There's some much more things that I'd like to discuss. There is lots of details and strategies about it. I know that it was super quick and brief things. I introduced lots of concepts like the cloud events. Sorry, the service workflow specification, the code to project, how to deploy it, the K-native. There's lots of things out there. And also lots of resources. You can go there on our websites and see what we are doing and the use case that we are capable to help you solve your business problem. So reach out to me as well. I have Twitter account. You can send me DM message or send an email or reach out into GitHub or whatever. I'm up there. You can see. I would like also to ask you guys to take a look in the blog as well. We are trying to update the blog twice a week with new content and to give people an understanding of what we are doing in Codito and the business applications in general and how you can solve your business problems. And if you're curious about the demonstration, the example itself, you can go into this we're holding here and see all the source code. You see the workflow. I create some scripts in there for you to deploy in your Kubernetes instance. We have the image already in there. No, the Docker file, sorry. Already in there. So you can go download the Docker file, run, view the image, run the image locally. You can play around this demonstration whatever you want. And I would like to invite you to see the presentation from last year that Tihomir and I did. Tihomir is much better than me explaining the serverless workflow specification in there. We go through more details about the specification and if you're curious about it, just go in there. And of course, the serverless workflow.io website, you have all the links that you need to know there, our Slack channel, our mailing list, our weekly meeting and everything else you see in the resources, okay? Well, thank you. That's it. I don't know if we have any questions or not. We've got some time for questions and there's a couple of them in the chat. So, and I'm gonna try and I'm gonna do them in reverse order because I think you answered some of the earlier questions already and Eric is asking, why was K-Native chosen to increase the workload capabilities and not an auto-scaler? Well, just for the demonstration purpose actually, we can use auto-scaler. That's not a restriction whatsoever. I just found that more simpler to show to users what we can do. And then in the example, you will see all the K-Native resources for you to replicate the exact same thing into the, in your environment as well. So, yeah, no, not particularly any reason whatsoever. But for the K-Native event in part, it is because the Kojta engine actually, we have these connectors and the Kojta operator as well is coded and we have this support for the K-Native event in platform. So we created a specific K-Native event in resources for it. So for the K-Native event in part, that's why. But for the K-Native serving part, no, can be whatever thing, the auto-scaler or it can be no regular deployments, whatever. That's no particular reason. Cool. All right. And that there's one other question from Ilian. Is it possible to create custom code? Oh, yeah, of course. Cause this is a Java project. It's a straight through maybe in Java project. In our, in the example itself, I have a redmi file here that I explained how, let's see, how you can create this server's workflow Kojta project from the scratch using Java. So you have to know Java, but yeah, you can add a custom code and you can call this custom code using a workflow. We have a specific in the Kojta implementation.  So you can call any Java being from the workflow. So yeah, you can do it. But from the, from the specification point of view, we have the JQ capabilities. So you can, you can like create a function expression and then, you know, externalize this. We can define here the function that is an expression as a function function.  You can just create the expression and in here in the workflow itself and that it will work. And then we'll, insert. Yes. So he's assuming you can call out to other services during execution. And Julian would like to be able to call out to fraud prevention API that they have. So. Yeah, absolutely. Let me, let me share. Let me, let me show you the specification itself. Yeah, you can, you can call any, any, any functions. You know, we have three in the specification. We, we, we expect the RESTful service invocation or C service invocation and also expressions. Like I said before, in the RESTful, you can define like a function like this. Let's say it's same order confirmation and the operation of this function, it is a, an open API definition file. And after the hashtag here, you have the, the, the method, the operation ID of that particular open API. So for, for example, let me see if I can find it. Oh, the famous, the famous pet store. Yeah, yeah. So imagine that you have like this one here, you know, this open API spec here and you would like to call the least pets function. So you just say, hey, this is my file and this is my operation ID. So the code engine will, will, will read this, this, this specification and will generate code client code to call this REST service. So yeah, you can call it, you know, a third party API and do whatever it wants within your workflow. So after receiving the, the, the payload of the, the, the response of the least pets, you can do whatever you want in your workflow. Yeah. That's correct. Okay. And so someone's now asking, where are correlation keys state stored if used? Well, this, the correlation ID, it is, we are working on the stateful implementation. So we don't have it yet on code to site. But in the specification, we have the part where we define, let me see if I can find it real quickly. Oh, very on top of the hour. But let me, what was the, yeah, here. In the events, you can, you declare the correlation in here. So in this, in this use case that I, that I brought, in the end, in the final order process. So if that process would be like a workflow service as well, because I don't know what it is. It is just an example that I gave, but if it is a workflow as well, you can, you can create the correlation in here in the workflow and say the event, say, hey, the attribute name, it is ordered ID, for instance.  In Kojito, we don't have a stateful yet for the, for the, for the server's workflow, but we are working on it. But in this case, we are going to handle that in memory. So we receive that at the same time, we correlate and we do all the other stuff. But we are looking forward to make it stateful. Cool. All right. Well, there's one earlier question. I think you might have answered it, but someone's asking for an understanding of how this relates or differs to camel K. Well, camel is for, I'd say integration more, most of the time, implementations of integrations. And we do not target integrations. So you cannot like FTP a file or send an email or those things like that. It is not what we are discussing in here. And of course you can implement a pipeline in camel K. This is not the idea. But from our perspective, it is more of a declarative workflow of a feature that we are implementing in here. It is not like dealing with integration side of the things. You know, I understand that is some things that they can interconnect or we can implement an integration in here. Like for instance, you can call a Twitter API using the REST function, of course, or you can, in the camel K, you can create a route that you go through every step as we created in here, of course. But each, I understand that each feed, each tool has its particular strengths and you should leverage from that. So from the workflow side, sorry. I'd say that for this kind of declarative workflows, business applications that we have, this is a suitable application for this kind of use case. That's my point in there. Okay, cool. All right. And so we are almost to the top of the yard. And the very first question was, where did the name come from? Well, that's something that people ask sometimes ended. Yeah, oh, I'm sorry. You, you know, I can't explain it exactly why the founders, they come up with this name. But everything that we do in Cojito, it is like related to knowledge. So we call ourselves the key. So the knowledge is everything. That's our motto.  And it is, I believe it's based on, of course, the founders can explain it much better than I, but from this quote, Cojito ergo son from Renee, this card is, you can read the week, but yeah, and the K cause Kubernetes, you know, it is a cloud-based platform. So that's why that's called Cojito. I don't know if I answered your question, hopefully. I think that's great. You know what the best part is? It's not a Greek or a navigation term. So that's really the most wonderful thing. It's like we have completely run out of K words and we're starting it in the Kubernetes cloud native space. So you've done well. So we've got like four minutes left. Is there some new features or what's in the roadmap that what's coming up next that we should be watching out for? Well, like I said, Cojito is a working progress of the serverless workflow specification. So the workflow specification is going super in the community. We are creating great things in there, great big companies are interested in the specification. This is a very nice thing from the community side. We are about to release 1.0 in the specification. So this is a nice thing. Hopefully we will see more people trying to implement it. And from Cojito side, we are keen to implement everything that is there in the specification to be 100% compatible with the specification. We are about to bring a JQ to the engine. So you can create JQ expressions in your workflow. And so you can transform or do whatever you want with the data within the workflow. And of course state, this is a very important thing that we are looking for, to implement in the engine as well. As well as a handling compensation and all of those workflow patterns that we don't have yet from the workflow, from the serverless workflow perspective. But yeah, there's a lot of work to do in there and from the specification and the implementation side. So if you can share again that resources page because I think that's a great way to end. And if people want to get involved, then follow the link. Oh, please. Yeah. Yeah, in the front page of the specification, if you go here in the specification, you'll see our GitHub page. And you can see, oh, I'm sorry, all the information that you need. Mainly how to engage with the community. We have a Slack channel under the CNSF Slack. So please go there and say hello. And if you have any other questions, just reach out to us there. We are keen to help. And looking for contributors as well. Well, thank you for making this really interesting and engaging talk. Ricardo will definitely have you back to celebrate maybe 1.0 release. And just keep us in mind there were plenty of great questions today. So thank you everybody for tuning in. And Chris Short for producing in the background there. So really pleased to have you here, Ricardo. Definitely come back and keep us posted enough to date. And everybody, join us on the community Slack channel if you have questions that he didn't answer today. We'll try and get them there. All right. Well, thank you everybody. And again, Ricardo, thank you. I love the hand waving while you're talking. The most aggressive virtual event so far. Yeah, I'm trying hard. All right. Well, take care and thanks everybody. Take you guys. Bye.


SuperYOT Audio Visual Installation, a guide to Luxury YOT AV installation. A Luxury YOT, by its very definition, should use quality in every area. And a Luxury YOT should always have a strong emphasis on entertainment. Therefore, you need to invest in the best AV multimedia solutions. Now, the world of AV equipment is a complex one, and SuperYOT AV installation comes with particular nuances. However, spectacular marine audio visual solutions can easily be achieved, and will transform your YOT almost instantly. Installing a Luxury YOT AV and onboard entertainment systems. There's no reason why SuperYOT AV installation shouldn't be able to match the high-end specifications of a home AV system, particularly if you focus on the following. 1. Available Space. A Luxury YOT will always have space constraints. And this can present a problem, when it comes to marine audio visual solutions. The complexity of an AV system and its build, means that it can take up a lot of room. Always start a Luxury YOT AV installation, by running a thorough survey on available space. You can then base your equipment and cabling routes and install around these dimensions. 2. Secure Everything. A home AV system is unlikely to experience movement, and will comfortably sit still over its lifetime. But it's very different on a Luxury YOT. The unpredictability of the sea means that, even in calm waters, a YOT will frequently be moving. And this is why everything needs to be secured. Equipment and cables all need to be fixed down securely, to prevent him from falling and causing damage. So, once your AV equipment has been decided on, start investigating the best way to secure it. 3. Integrate Automation. Operating a YOT is a 24-7 concern, so anything that makes this easier is appreciated. Marine and YOT automation systems are critical for the smooth running of a YOT. And AV systems are more than capable of meeting this need. Smart AV systems allow you to simplify the operation of complex AV systems. Customizable hubs can easily be installed, to help you manage your entire AV system from one screen. This allows you to get the best out of your AV system, while operating a YOT at the same time. 4. Waterproofing. The arch enemy of SuperYOT AV equipment is water, you will be surrounded by it. Waterproofing, therefore, will be essential. You won't, of course, need to waterproof everything. Protecting a speaker in an internal room, for example, is a rather redundant exercise. But cabling, which may run all over the YOT, should be made as waterproof as possible. And, don't forget, remote controls and devices such as tablets, can easily make their way to external areas of the YOT, and need strong protection from water. You want your SuperYOT AV installation, to be the very best it can be. But it's difficult to deliver a world-class installation, without a wealth of knowledge. Thankfully, this knowledge is easily accessible, when you team up with professionals. With their years of experience, they can bring a level of expertise which will ensure that your AV installation delivers on every front. For a free quotation, please visit our website, nmcabling.co.uk, or call at 019 23 888 588.


I think it is 11 o'clock and time to get started. So today we're going to talk about fun with continuous compliance. So the agenda for today is first, we're going to do an intro to what fun is and what not fun is. Then we'll talk about why and what continuous compliance. And then I will talk a little bit about how we're dealing with this at Shopify. And then Zia will finish up with Oskal and a little bit more on how you can use that for continuous compliance. So, this photo was actually taken over two years ago. This was actually the last time Zia and I saw each other in person. We were speaking at a conference in London, so hopefully we'll get this updated with pictures from here. So I am, I'm Anne Wallace. I am a senior manager for security engineering and compliance at Shopify. And... Buenos dias. My name is Zia and I am a security solutions manager with Google Cloud and I specifically focus on compliance and compliance modernization. Cool. So, what is fun and what is not fun? So, this here is a reference to the fun scale. So this is often used by outdoor enthusiasts to describe the kind of enjoyment they get from adventures or misadventures as the case may be. But this can also be used for life or in the case of this presentation, compliance. So let's look at each type of fun. So, type one fun is simply having fun. So, good fun. This is like hanging out with friends, going to CubeCon, drinking sangrias. Type two fun is miserable why it's happening but fun in retrospect. So, this type of fun usually begins with the best intentions but things get carried away. So this might be like Friday deployments or doing crazy ultramarathons. Type three fun is just miserable when it's happening. It's not even fun in retrospect.  Somebody please stop me. So this might be a friend once or coworker wants to go on some epic trip and you're on call for them for six weeks or manual evidence gathering for your yearly audit. So, really the kind of the title of this talk came from somebody told me that compliance isn't fun. And that might be true if your idea of compliance is manually gathering evidence yearly and hoping nothing bad is found. This is definitely not fun. But if you think of compliance as a set of requirements that you as a developer or a security engineer and it's your job to figure out how to meet these requirements as you would with like any other software engineering problem, then compliance can be fun. In this presentation we want to introduce you some new concepts and ways of thinking and looking at compliance to make it less burdensome and dare I say fun. I do need to make a confession. I run ultramarathon so like 100 kilometers or longer for fun. So I kind of have a warped idea of what fun is. There's a lot of type two fun in my life. So maybe this is why I enjoy compliance. I don't know. So I'm gonna hand this over to Zeal and she's gonna get into the why and the what here. Thank you Ann. Okay, so let's talk through. Okay, so let's look at some of the macro indicators in the industry when it comes to compliance and the future. We are headed towards an automated compliance future. There are several indicators in the industry that point towards this. We see that security inclusive of risk and compliance is modernizing itself to keep up with the modernization with the overall IT. So a couple of observations. On the left hand side is an excerpt from an article that McKenzie came out in summer of last year where CISOs from all major cloud providers, including Phil Venables from our side at Google opined on using or leveraging automation and code to express security requirements, compliance requirements earlier inside your development lifecycle. And then number two on the right hand side is something that regulatory bodies NIST is working to bring this to fruition. So NIST in conjunction with industry peers like us has developed OSCAL. OSCAL stands for Open Security Controls Assessment Language. So what OSCAL is, OSCAL is a set of format expressed in a machine readable format like XML, JSON, and YAML that allows for exchange of evidence data. So these formats provide machine readable files where your controls and control requirements, your control baselines from NIST 853 specifically is expressed in YAML or in XML. And so you can validate them throughout your CI CD pipeline. And I'll be talking about OSCAL later in the presentation on what are the potential hooks where you can insert inside with your DevOps pipeline. So when it comes to security and compliance, there is a Ticotomi. There's a vicious cycle of rework caused by misalignment amongst teams involved in demonstrating compliance requirements. This is not new to us. Developers are often left to interpret arcane compliance requirements that don't always become, are not relevant to cloud configurations. The SecOps teams, they work with many tools that creates a lot of noise, a lot of fatigue, making it difficult to evaluate the right compliance implication of an alert. And then compliance analysts, they tend to work in a silo and the environment is getting more and more decentralized. So evidence collection becomes cumbersome or becomes hard. So with that as a background, this is why compliance is scored or continuous compliance is relevant. Continuous compliance is about having a right balance of preventative controls, which are green, along with remedial controls when detections arise from your cloud environment. There are obvious benefits or merits to having continuous compliance, but what I really want to emphasize over here is that a certification or an audit that you perform yearly is not sufficient source of assurance anymore. Secondly, going through a point in time audit is costly. It is cumbersome. It taxes your resources. So it's time to move from point in time evidence collection or point in time compliance to continuous compliance. And obviously, this change requires a lot of cultural change that needs to happen within an organization. Moving on, with all this as a backdrop, we launch risk and compliance as code, our solution on Google Cloud. I can speak about it, find me in the hallway, but the key building blocks of the solutions or the message that we want to drive is to build your tool set, build your automation tool set in each of these categories and starting with the harmonized controls. And I'll speak about harmonization of controls later in the presentation. What I want to drive again here is that this transformation from point in time compliance to continuous compliance is a multi-year journey as you build your maturity in each of these building blocks. Speaking about maturity levels, here's a roadmap of capabilities, team alignment and skill sets that should be introduced over a period of time. To truly get to a truly transformational state. And with that, I would like to hand over to Ann to speak about Shopify. Okay, cool. Yes, so Shopify and continuous compliance. All right. So if you don't know who Shopify is, it's very likely that you have bought or purchased something from one of the millions of merchants who use our platform. So we're making commerce better for everyone. We offer a platform. So folks, small, medium, large businesses can build their e-commerce platform. We do payments and everything's done in a compliant and secure way. So those are some big numbers on the last slide and able to support that amount of merchants. These are some of the statistics. So lots of GKE clusters, tons and thousands of Kubernetes services and even more builds a month and GCP projects. And this is a couple of months old. So this is probably even much larger now. So anyone who's a part of a compliance team or audit team might see these numbers and that's when panic might set in. So just a level set on the compliance programs that we have at Shopify. So PCI, Sarbanes Oxley, SOC2 and Swift. Just one more slide on numbers. So and again, you can imagine managing the security for this amount of containers could become an issue. And then thinking about compliance as well. This is really starting to sound like type three fun, just not fun at all. So let's look at how we build these containers. So these on this particular build slide, there's some specific Shopify tools and lingo in here, but this support or this type of deployment pipeline is probably familiar to a lot of folks. And this is what I would call type one fun. So it's a built out functioning pipeline. So you push your code, all the checks happen and boom, you're in production. That's fun. So for the rest of this talk, we're kind of gonna focus on this triangle area for making compliance fun. All right. So we're gonna talk about in that triangle, we have some stuff like binary authorization and voucher, which is an open source project by Shopify and I'll get into that. So just to kind of walk through the pipeline. So first developer or anyone pushes a change to GitHub. Secondly, build kite. So this is our container builder. Build kite is used to create Docker containers to encapsulate the new application code. When the build complete successfully, build kite will then push that to Google container registry or GCR. And then the build metadata is stored in container analysis or the open source version of that is Grapeus. And then voucher scans the images in the registry and signs those images if they meet the specific voucher policies and I'll get into that in the next slide, next couple of slides. So and then the signature is pushed to Grapeus or the metadata storage and signatures are based on the digest of the version of the image. So then we get into deploy time. So Kubernetes receives a change to a deployment. And then we have another, this is a Shopify specific tool called Shabas. So it's an emission controller. It receives the event from Kubernetes and their views and manifest received converting those image tags into digest. And as I mentioned, the signatures are based on the digest of the image, which means that we need to look up the digest associated with a tag. And then we have binary authorization or the open source version of this is Cretus, which is also an emission controller and it receives a manifest after Shabas and checks for valid signatures in Grapeus and then blocks any invalid images. If the image is not blocked and Kubernetes pulls the image from GCR. So what is voucher? So voucher is a tool that examines container images and runs checks against it. For every check that passes voucher, then signs the image with the checks associated maybe open PGP key or KMS key and then pushes the new signatures into Grapeus or an image data storage. These signatures are also known as attestations. So we use vouchers DIY check, which is used to ensure that only images built by Shopify's infrastructure and approved third party images can be run in our clusters. So now let's look at some compliance controls and see how we can leverage our current security tooling to meet compliance requirements. So maybe you deal with PCI. So when talking to an assessor for PCI about 6.1, you might hear something like that you need to classify risk as high, medium, or low because this allows organizations to prioritize and address the highest risk vulnerabilities faster. The risk rating should be based on industry best practices. So maybe something like taking into account a CVSS baselines or manufacturer classifications.  So let's make it fun. So going back to what we have that we're already using with voucher, how do we meet this compliance control? So again, kind of looking what comes out of the box of voucher, we have the snake oil check, so which voucher can make sure images are free of known security vulnerabilities. So to implement this in our current environment, what we need to do is edit the voucher config file. First here, we are enabling that it would fail on anything that comes back with a high ranking. And then we're enabling snake oil here. And then thirdly, we are configuring the keys. In this case, it's KMS that will sign the attestations. And then for binary authorization or CREDIS, we create a policy that requires the testers to sign before deployment. So to go into this, we have a default rule that has evaluation mode of require attestation, which binary authorization to allow the images, it has to be assigned, or it has to be authorized by the signed attestors, which is in the required attestation by, sorry, my tongue got tied on attestation. So if that is not true, then the deployment is blocked if they're not signed. So again, we have this flow here. And let's see how this works with the snake oil policy. So first, a vulnerability scan is ran when a new image is put into the registry. The results of these scans are stored as metadata. Then the voucher policy checks to make sure there are no high vulnerabilities. If there are, the image is not attested to, and a log is written to the audit log. Otherwise, it is attested. And so then we go into deployment. So let's say someone tries to deploy this image or this container. Credits and checks if the image was signed by the, if there is a signed attestation. If not, the deployment is stopped and an audit log is written. See, again, I have a warp sense of what's fun, but we're taking something we're already doing, and just with a couple lines of code, we're starting to meet compliance requirements. And not only did we did that, we did it with little effort. And the vulnerability scanning continually happens, so anything bad is found in logs. And auditors really love to see this shit, especially the audit logs of things getting blocked. All right, so let's have a little bit more fun. So here's another PCI requirement. So this control is really about incorporating security throughout the software development lifecycle. This also applies to software developed internally, as well as bespoke or custom developed software from third parties. So again, we have stuff out of the box of Voucher. One of the ways that we can satisfy this particular control is making sure things come from known sources and are built by trusted sources or your team. So luckily, Voucher has checks for this, DIY in Providence, so this is really a two for one. So again, similar to what we did for Snake Oil, the DIY checks here are in green. We need to enable them. And then the valid repo option in the configuration is used to limit which repositories an image can come from. The option takes a list of repos and are prepared against the repos that the image live in, if the image will pass if it starts with any of these items. And then the Providence check, which is in blue, works by attaining a build information from the metadata. And the image from Grafayas. And then verifying that both come from a trusted project and is built by a trusted builder. So in this example, this image has to be built from the project, compliance images, and either built by Anner's at Shopify or by this particular service account. This will not pass if it doesn't come from this compliance images project, regardless of who built it. So, and again, just like Snake Oil, we just need to add the attestors to binary authorization so we can block this or prove it during deploy time. So a couple more. I think you see the pattern we're going for here. So again, here's another PCI requirement about restricting access, along with making sure we're using least privilege. In this case, we wanna make sure that the containers are being run by a unique accounts and limited and not as root. So yep, we have a check for that. So that's the nobody check, which makes sure an image was built to be run as a non-root user. And then just for funsies, let's do one more. So this is a SOC2 requirement that we have that makes sure that CITES has to run to cover security prior to deployments. And you might have guessed, yes, we have a check for that. It's our approved check. So again, you can just see the matter of a few lines of YAML and enabling several checks and attestations. We've satisfied quite a few different compliance requirements. So let's have some fun together. As you've noticed, Voucher has just a few out-of-the-box checks. We would love more. So please contribute to making compliance more fun, type one or type two fun. So here is the GitHub for this. So now I'm gonna hand it over to Zeal to talk about OSCAL. Yes, thank you. So if you go back to the talk from Ann, and if you look at her slides, most of the evidence that was collected by open source tool, or most of the evidence was XML or YAML based. And so the question is, can we take this and convert it into an OSCAL format, which is again, a XML or YAML based, and use the evidence that is collected at the time of your CI-CD pipeline and use it to push it, have the evidence dump into a report. So I'd mentioned about OSCAL, and so I'm going to talk about it. That's the whole basis why OSCAL makes it, makes continuous compliance easy and drives down some of the paperwork. So some of the common asks from our customers around continuous compliance, compliance modernization, as they transform on our platform, I'm sure everyone would recognize this. The box that I really want to drive your attention is the last box in gray, how to decrease compliance paperwork. Most importantly, how do you reduce the audit fatigue? How do you generate evidence faster? How do you populate certain sections of an audit report automatically based on the evidence collected? Is there a way where you can exchange data with your GRC tools based on the evidence that is generated inside your CI-CD pipeline? And so this is the last block is where OSCAL or the goal of OSCAL is to help out. So what is OSCAL? OSCAL is a format, as I mentioned earlier, it is a machine readable format that allows GRC tools to exchange data in the form of evidence and artifact that is generated. So today security controls and control baselines, whether it is 853 or 27,000 one or PCI DSS, it requires data conversion and a manual effort, lots of cycles to interpret a specific implementation of that control. If you have a control implemented, it needs to be manually interpreted, it needs to be manually checked with the auditor and the evidence has to be exchanged. That requires a number of Word documents or spreadsheets. So this is where OSCAL can help. The goal of OSCAL is to move the security controls and control baselines from a text-based manual approach to a set of standardized and machine readable formats. With the systems, when the security requirements are standardized, the monitoring of evidence becomes easy. And there are a number of examples of open source OSCAL efforts to improve the adoption of it within the cloud native and compliance community to make it more mainstream. This is really why we are doing this talk to drive awareness about OSCAL and have people contribute to it. So I spoke about OSCAL, I spoke about continuous compliance and when I speak to customers, the natural question from them is that, how do I get started? What sort of data set should be OSCALized or what should be converted into an OSCAL format? So here's a reference architecture that enables you to develop this capability. The starting point of this architecture is the top box, the directional controls or director controls. That is nothing but a harmonized controls library and the control requirements can come from a number of sources, your threat landscape, your internal governance requirements, your internal security policies and procedures, the compliance requirements that you have to meet externally. So when you harmonize controls across these different areas, you get to a technical control library, which is the red box in between and that becomes an input and a guiding principle for your preventative controls, your detections and then certain responsive controls or remedial actions. The key point I want to drive over here is that building this technical control library, it takes some time. It's an effort that you would have to invest your resources into and it would be great if you can start to think about oscalizing that technical control library. Now how would this technical control library work with engineers? So let's take a look at the path. So for every directive control in your control library, you would have a corresponding preventative control and to stop non-compliant resources from getting into your environment. Next, you have detections to look over the environment to constantly scan for non-compliant resources and then finally, you have certain responsive controls where applicable to bring the drift back to their original state. So every policy evaluation should have a feedback loop to the engineers, to the people who write the code, who write applications. A prompt and a meaningful feedback loop like this would provide better engineering experience and would drive down the velocity, or sorry, would increase the velocity of your applications. You'll be writing faster code, you'll be shipping faster code and securely. Sir Ann talked about the CI-CD pipeline and DevOps tooling at Shopify. This is something similar. What I want to draw your attention to is are these red boxes or red circles as when the code progresses through the pipeline, it gets evaluated at these checkpoints which are marked in red. And most of the results from these evaluations are XML or YAML based and these are perfect examples for the results to be converted into an R-scale format. And if when these results are properly integrated with your DevOps tooling, such as your Kubernetes configuration files are converted to R-scale format, or your policies are converted to an R-scale format, you'd probably get to a truly continuous compliance nature. And with that, I wanted to drive this call to action. If you're interested in contributing more to R-scale, if you are interested in building that control library, there is a Kubernetes policy working group that has started mapping out technical controls from 853. That library can guide your closed loop of preventative and detective controls. So feel free to catch with me. We have a number of efforts at Google to even drive the adoption of R-scale. And with that, I would like to hand over to Ann to close off. All right, so there's a survey that you can tell us if you thought this was type one, two, or three fun. So I would appreciate that. So I always have to put my dog in. So yeah, we have time for questions or not questions or if you wanna have fun. Yes. Ah, we have a crown. In the center. Oh, thank you. Sorry, I had to push the button. That was my bad. Okay. There was a question over here? Yes. We'll start there. Thank you. Thank you for the talk. This question is for Ann. I wanted to ask you why you choose to scan for vulnerabilities when you send the images to the registry instead of doing it in the build pipeline, for example. I mean, is there a particular reason for that? So part of Google Container Registry is, what is that called? There's vulnerability scanning built into that. So it's just out of the box. All the images are scanned and that's stored in the image metadata. What was the question? Why we were choosing to scan the images where we were. Because part of GCR is the, yeah. Well, first some of it. I think there was a question over here. Yes, thank you. I don't see any questions online at the moment, so. I'm also happy to answer things on Slack later, Twitter, whatever. Be sure to ask on Slack. Happy to talk about type three fun adventures I've had. Jet lag seems like type two fun. Thank you for the talk. I have a question. I get monthly auditors on my address and asking a lot of information about the system, the applications, but also about the documentation. Is a service account could describe in a documentation? How do you look to automate that? How can I automate that? That I have to scan a lot of documents to look where it is described. That's by the way a government policy in the Netherlands. That everything is well documented. Automation through service accounts. How would you handle that? Sorry, I was trying to, how do we handle automation through service accounts? No, it's about documentation. Documentation where service accounts is generating. Yeah, you use a service account, but the government policy in the Netherlands, you must describe the service account in a document and you have to prove that a document is exist and that the user is there in the document. How do you scan that? It's all word documents. Excel, it's several language. How can I? How do you explain service accounts to auditors? How do you explain service accounts to auditors? Yeah. Yeah. So coming from an audit background, service accounts or a robot accounts or automatic accounts, you would have to spend some time explaining them, how they get created and how you're restricting them. Once they have an idea about what restrictions you have around service accounts, you should be able to demonstrate your flow of one, you're following up the least privilege and then whatever attestations your service account is signing, it can be used as the evidence. Does that make sense? Yeah. Yeah, we have internal tools that we walk our auditors through on how we limit the scope of service accounts and how long a service account has access to things. So we have built some tooling around what Google does. Yeah, that sounds like it got it. So there are a couple of questions online, so I'll do those real quick. Does the continuous compliance reference architecture allow for approved exceptions or how would you recommend dealing with that? I could not hear it. Sorry, the mask makes it hard I think. So how does the reference architecture for continuous compliance? Does the continuous compliance reference architecture allow for approved exceptions? So approved exceptions, yes. Yeah, there are break glass scenarios, so yes. But with compliance all of that needs to be documented and you have the evidence to show to auditors on why that happened, why the break glass or whatever you might call it happens, but yes. Lovely. Any other questions in the room? Yes. Thanks for the talk. Just a question for Ann. Around the snake oil flow, I can see the stuff you're doing and how it successfully ensures compliance for new images going into the environment. I was wondering what your flow looks like for detecting and automatically responding to if vulnerability gets discovered the next day, which affects the same image. In particular, I'd be interested to know what the automatic response looks like, because pulling it obviously isn't going to be, could affect your service. I am so sorry, I'm having such a hard time. I could not. So yeah, it's... Yeah, the snake oil, the one that... Yeah, I was wondering if you have an automated process for discovering vulnerabilities after the image has been deployed, if vulnerability gets discovered in a package that's already in that image and what your automatic response would look like in that case? I'm so sorry. Why can't you go? So if you have an image that's already deployed, then you detect... How do you detect vulnerabilities in that and how do you deal with those types of situations? That's a good question. So images that are currently deployed, so container registry, so anything that's in the Google Container Registry are continually scanned. So that can leverage things that are currently deployed, so you can map that one to another. But I don't have a good answer for you. I can follow up on Slack on how we're actually doing that. Good enough? All right. And there is another question online, and I'll make my way over here. The one online is very, very quick. I believe it's for the Googler on the stage, which is, why do you use pirates as the persona for devs? Which I have my own take on. Why do you use pirates as the persona for devs? Oh, well, I can answer that, too, because I worked at Google. Google has a tool that you can just generate little images. So, and the thing that happens is people create slides at Google and they have these images in there and they think they're cute and it just gets reused. So, there was nothing that we wanted to use a pirate, or I don't want to speak for you. It was a generated thing, I don't know. I'm pretty sure that it's a group of icons that the design team at some point made. There's a service that we can... For disability visibility. So it's someone without an eye, there's someone with like a hearing aid and just the one with the eye patch gets used a lot. There's one here as well, yeah, go ahead. Thank you very much for the talk. Also, not used into DCI and fun being together. So, your advice for a new company that might want to go through the process of compliance, because I know that the PCI DSS is not exactly up to date with cloud providers sometimes. So, what would you advise someone that maybe wants to go through the process by automating some part of it, but maybe not being prepared for questions from auditors that might not understand the whole concept of automation in compliance. So, do you mind paraphrasing a little bit? I got some portion of it. So, just to rephrase it, advice to new companies that need to go through compliance steps. When they have prepared the automation, but their compliant officer is not ready to transfer that into PCI DSS items. Like, what was the challenges of introducing this automation maybe in the compliance process for you? And what can you advise some new companies that might want to do that as well? Awareness and education. Any sort of new change will drive. You wouldn't need to drive awareness and education about how automation actually simplifies and makes the code more secure and more compliant. Once the conversation flips in that direction, usually whoever is opposing it gets on board. And we're a couple minutes over, but I'll ask this one last question online in case anyone can stick around for it. Welcome to go, of course, though. The continuous compliancy model looks really great. What happens when deployments do not meet the compliance check, but you do need to fix a production incident? That's a good question. I think that I'm trying to think of a scenario where it wouldn't meet a compliance requirement and we would deploy it anyways. I think there's always exceptions. And as long as it's documented well enough and why that happened, and then you go back and fix it so it does meet the compliance requirement, you're probably okay. Hopefully you have a good enough relationship with your auditors so you understand what their tolerance is for that stuff.  I mean, anyone who's dealt with auditors know that. I mean, it comes up all the time. They want it documented. We recently did a cutover from AWS and GCP and we're taking screenshots of everything for our SOX environment. So leave a paper trail and document it. Yeah, yeah. So we're happy to answer. I know you had a question. We're happy to answer questions out in the hallway. So thank you all who stuck around. And yeah, have fun. Thank you.