 So thank you, Thor, for giving us a recount of your experience on the game day, and congratulations on being a part of the winning team. That is the exciting part, and I'm literally, I can't find my slides, so. Yeah, we're doing it this way. And I just accept that. Yeah. Yes, Inter Newbug is definitely on there. So, what's that? Sorry, I got one. Yeah, right. I broke my glasses yesterday. So, okay. So we start off the game, this is a game scenario, right? So the whole concept of the game itself is to ensure that we have a concept, and a part of an idea for people to latch onto. So there's role play, and the concept of the role play is to get up and to just basically be the CFO of a startup, right? So you just walk up and you're like, you guys are all, I don't know if you know it, but you were all fired from your jobs yesterday, and that's why you're here now. And then we give a little bit of information that's associated with the experience like, hey, we were running this company really great, but then a couple things happened, some people quit, like all of them, and then we've started to get some customer feedback. And the concepts there are to get into the specific quests. Now, a quest has an objective, right? So in this case, what we wanted to do is create a social aspect. You want to make sure that you can create, generate some sort of common application that can be shopped around to other teams. So if you want a good experience, right, you want to build in that connection, right? So what we do is we build a game. That game is then served out from a, like in this case, an instance, we were using Red Hat Enterprise Linux on the Cloudy Hops. And then you're capable of playing the game, but then you're also capable of getting other people to play the game. And when other teams play the game, you get points. So you want to shop around to make sure that happens. And effectively, that gives the, each one of the team members, an opportunity to participate, regardless of the level, right? So the reason you want the social aspect is because you're going to have people who have zero level experience with the products that you're trying to showcase, and you're going to have people who are expert level. And you want to make sure that you've covered, you know, the gambit of things that can be, that can be associated. So somebody has to choose a more social role, they still can. And that kind of goes along. I mean, in my opinion, that goes along with the sentiments of the way that we handle most things in the open source community. So you want to make sure everyone stays included. This one, so that was, this one, the Cloudy Hops. That's, this has a modified Flappy Bird in it, by the way, that has a red hat hat as the Flappy Bird. Right, that's right, that's right. That's right, yeah. Doesn't work, yeah, yeah, that's right. Hence this customer experience, right? So good thing you were there. And then this one, the Goldfish, we actually did a, there was a Rick and Morty Concentration Game. And we took the Rick and Morty Concentration Game and then rebranded it as a red hat concentration game. So we used a lot of red hat icons to build out the structure for it. The way that those, the way that that, you know, translates is you expose it on the, on the OpenShift or like, I mean, in this case on a rail box. But the concept is to expose that interface for, for access and then to make that social experience happen. This game is built on Ansible and Ansible Playbooks and centers around the experience of having emerged conflict that you've got to figure out how to resolve in the, in the configuration. There's a team dashboard. The dashboard has all the information, provides the, the experience. And this is what it looks like. You end up with a, a hash on that screen that takes you, that basically takes you to your own console. So once you put the hash in, you get a table number, which is so everybody can use that. Thor said he thought they should use one laptop instead of having two laptops. The one laptop would have the, the team dashboard on it. But with two laptops, you can have the same team dashboard on two laptops. If you, if you have four players, those four players can do that. And the way that the, the, the event engine that we use is established. You can do that with teams that are in different, different countries effectively, right? So the, the concept of the game day is not something that is localized. It's something that we can in fact bring to all of the, the members of a team, even if they're not geographically located in the same, same place. When you log in, you end up with access to the quest itself. And since I'm having trouble with my slides, the, the quest is effectively the part that is the interaction for the players. So we have a event engine that effectively covers the whole thing, right? And then we have multiple accounts for each one of the, each team gets their own account. So for one table, so if you have, if you have, you know, one table with four seats, and everyone is playing on this table, that's one, one player account, right? So if you, if you look at that, you would think about it as one AWS account. Now the event engine has a master account. So this main account here includes all of the, the requirements for the game. So you would see one cloud, we, we do this with dev ops, of course. So you get one cloud formation template that deploys the entire infrastructure for, for the main account. And that main account becomes the control, the command and control for the entire game. And then as a developer, as someone who is developing for the game day, you're, you're building out a cloud formation template that has all the, the content in it. Now for our internal games, right? This may, it would probably be more, this would be all that you would do. But for Red Hat, we've, we determined that there are some things that we can't deploy in, into the configuration here based on policy requirements. And so instead of just using the team accounts here, we're working with the demo team. And the demo team at, at Red Hat has provided us the ability to stand up additional customer resources. So that as we, as we interface here, right? So this basically is an event loop, right, with a dashboard in it. So, so the dashboard, the dashboard for the game is, is exposes the, the the content from the cus, the, the team account to the, to the main account. The main account then can do monitoring. It can do command and control in the association. And then you get back a score. So with all of this, with all, with the way this works, we'll have, we'll have resources here that are monitoring and managing the game. This is where your event engine is. So as, as the players make changes to each one of the individual quests. And the quests are actually here deployed in the master, in this main account where the, the players don't have access. The players have access to all the resources that are down here. This is where you're deploying instances. And you're, you have different kinds of, of applications running on top of having the ability to have an open shift configuration on this side that's deployed through Agnostic D. And if you haven't, if you haven't seen Agnostic D, this is the tool that the demo team is using to create all of the configurations that they provide through the demo portal. So any of you who are looking to learn about services, right, on top, on Red Hat would probably go to the demo portal. So you'll understand the infrastructure that we're using for the game because it is immediately available. So as a, as someone who's wants to build a quest, if you want to build your own Goldy Fish, right, you would create a template using the, the development kit. Now the development kit provides you an entire configuration that, that lives instead of in two accounts, right, instead of being set up in main and team, the, it combines the two so that as you're working, as you're making modifications to the, to the configuration, like let's say you wanted to build out an open shift configuration on the demo portal, you build that out, it's successful, you deploy it, you deploy the infrastructure to support connecting to it, right, like instances that you can use through terminal or, or a, or through a, a graphic display, you would then be able to take that, that entire configuration and deploy it in a single account while you're doing your development process. So what we do is we carry the development process in a single get repository, and then that way we can split out what goes into the main account for control, and we can split out what goes into the team account into two different templates. Any questions so far? So one of the other things that we wanted to cover is scoring. In the gameplay, we want to make sure that people are engaged and that the experience is something that makes them, that they feel their progress. So you want to have various stages of scoring. Each one of the opportunities for, for building score can be greater or lesser, it all depends. Usually they're attached to actions. So if we go back to looking at the quest itself, these quests will have individual components, like for example, the first thing you do in the, in the Cloudy Hops game is to identify the endpoint that the game will be, will be served from, right? So that's identifying what the URI is for that specific server. When you identify what the URI is successfully, you get points, right? When you, when that URI, when that URI is identified and the Cloudy Hops no worky, then you get, you get no points. So, so you have to determine exactly what parts, what component parts are, are functional, what, what or not. And then add hints. So now, now that I know that my score is greater or lesser based on success, right? Then I can say if I want, if I want to score for an endpoint, so you gave me an endpoint, I give you a thousand points. You ask for a hint because you don't know what the endpoint is. I give you negative six, right? Something like that. And that's not, that, you know, this represents like a very small, like a, like a basic hint, right? And incrementally, you know that everybody's going to get a thousand points for the, for the, for the endpoint, but not everybody is going to really realize exactly what needs to happen to get that endpoint in place. So they're going to take one of those little hints. And then you, maybe they need a bigger hint and a bigger hint. And just that subtraction of like the smaller amount of points, you end up with very interesting variations on the scoring. And we saw that yesterday. The first thing, was it you, Thor, who was like, how did we get? No, it was Marcel who said, how do we get negative points? But it didn't matter. It got a couple million after that. So, and this represents like a first, so, you know, these are first attempts. Game complexity is in the next step in our process, right? Is understanding that you have, if you've achieved one thing, that can't be the end of the game, right? We want this to go on. We want people to feel the, the experience and the, and the warmth of an actual production, right? We don't want them to, to be able to rest. So as you build out these quests, we don't, no rest for you. That's right. Well, I mean, if you're going to win the game, come on. Like if you're going to, if you're going to mean, if you're going to maintain their attention and the commitment, there has to be some next level. And so what we do is we build out multiple layers for each one of the individual games. For Cloudy Hopson and Goldy Fish, we don't have as many levels as we would like to have. We're working on that, right? So love to have your help in doing that. And then the, so the complexity means you have to layer in more of the, more of the company vision, right? So a lot of what we do there is, so to add networking complexity, we have a team, a security team, we call Threat Slayer. And we use Threat Slayer for a lot of things, like Threat Slayer comes in and actually has to, you know, has to apply policy. And if you've ever worked in a cloud environment, there's identity access controls, there are firewalls, there are access control lists that are so independent of the, of the expectations of, like a basic instance that the hunt can, you know, can be quite complex in itself. So we add complexity with our metal band turned security team. And, and we use other, you know, other opportunities, natural disasters, complicated, complicated action. So what we would like to have in that process is, is something, some next level of complexity so that those who are actually achieving at the lower levels can move upwards in that game. We can do a game day for up to 72 hours. So the more complex, the higher number of quests that we have, the easier it is for us to sustain attention and entertaining, entertainment value in those, in those 72 hours. It's really helpful to have, to have a goal in mind that is directly associated with a specific service. Cloudy hops obviously is, is structured around two things, which is just basic service enablement, right, and, and, Essie Linux controls. And then their container based system has, or I'm sorry, the Goldyfish configuration has a, a goal of building container, a container based system that is managed on your, on, on a rail work, a rail system, a rail server. With the added complexity of ensuring that you have an Ansible playbook that is fully functional for the, for the process. And building out and running the Ansible is kind of the, the strongest methodology that we want to, we want to pass through on best practices. But that doesn't mean that the winner is going to use that Ansible playbook. And that is kind of one of the other things that I wanted to talk about is there's a seemingly random pathway to success. And part of building out this game is discovering how people shortcut your, your practices. And then how that, how that, how, how to score that, right. So for us, the idea is to help people along in the context of the best practices. So, and we know those, they're observable, but that doesn't mean everyone is going to be able, is going to know exactly where to look. We were laughing about this yesterday is that they're, they're almost everything that we had, if you followed the, if you had gone to the rail, the rail documentation, you actually would have found the steps to fix, you know, to fix the problem. But nobody went to the documentation. So, so as a result, we saw a lot of different things. And there was a, we, we had an interesting debate, you know, just, just by having someone solve a problem in a way that was non-standard. One of the, one of the teams literally stood up secondary architecture and wanted to, you know, like, rebuild everything on CentOS Stream 7 and then did a deployment. And so the deployment, the deployment was effective. It worked, but it didn't score them any points. And the interesting part of that was that this was, you know, because this happens in, in a, in a cloud environment, one of the principles of building out cloud, cloud infrastructure is to remain lean, right? So they actually extended the architecture, they doubled the infrastructure requirement by standing up a secondary instance. So there was a question about whether or not this was, you know, they had achieved the goal. And, you know, we had, we sort of step back, looked at it from both sides, tried to determine what we thought was right. And then just generally agreed that this was an infrastructure mistake. So, and that brings me to the score, like the scoring events themselves are deterministic in that, in the basic way, but then there is some room for us to identify and apply some changes to those, to the, to the point structure, just to make sure that if someone is working and they're discouraged or they don't understand, that doesn't stop them from getting some sort of an advance, you know, that we, you know, to feel like they're still part of the game. And this is also a part of, of the, the structure and practice around this, is that you have to build some compassion into the experience, otherwise you may lose your audience. And lastly, before we just start generally talking about it, or maybe I can show you some code, is, is the, the prize structure. So obviously this is unicorn rentals, and unicorn rentals needs to have something that is mildly representative of unicorn, of the unicorn experience, right? So we try to put things together that are glittery and fun and not practical. Because one of the things that is interesting about the game is the, or the, the thing that is interesting about the game is the play. And it shouldn't be a competition. It should be something where everyone is excited to participate and everyone is, is happy when, when, you know, they finish and they, and they can they don't feel so heavily invested that there's a sense of fairness or, or, or complexity, complexity in their, in their vision of the game. So we don't want you to, we don't want you to feel like you're, you're missing out, right? Which is why we gave a baby unicorn and not a full-size unicorn to the winners this time. We rent them. A lot of times, you know. Yeah, that's right. Yeah. And that's, you know, that's a point that really made this business what it is today. So the prizes themselves need to be simple and they need to be, they don't need to be heavy investments. And my favorite one, my favorite prize to give out is having your name permanently taped to a, to a plastic unicorn statue. Okay. So with that said, configuration management is really the, the next step in this. And how we get to the configuration management is through what we call the Quest Development Kit. The Quest Development Kit has all the, the things that go in the main account, right? And that's a bunch of Lambda functions and some, some serverless configuration stuff that sets up all of the event-driven actions that come down here. So for Fargate, we, you know, there's a bunch of containerized applications that we use to do this. And we build them out in a serverless infrastructure so that there's, but it's fairly efficient. This part is kind of hard-coded. There's no, there's not a whole lot that you can change about how the events are structured, but what events are, are trigger points and how those are evaluated is part of the Quest experience that you would put in this, this command account. The command account interacts and executes within the context of the, of the player account. So the player account is leveraged for anything that is, that the user is, like, the player is capable of doing. So if you, if you wanted to have, Adam and I have talked about this before, if you wanted to have a full, you know, a full open build system in the cloud, right? We would set up the open build in the team account and then we would identify actions, notifications that would then trigger, trigger point scoring or identification of the, of the unlocking of specific tasks in the Quest until we get to such a point that we feel like that, that section of the task has been completed. Once that's completed, other things can happen. So a layer, a second layer, can be activated at a later time, right? So as you build, you build one and then you'll build a single action and then you can build a secondary action and a tertiary action and N number of actions, right? After that, that can be enabled in succession on that, on that same Quest. Yeah, the sky's the limit. Application space is built in Python, but there is a TypeScript version. So almost all of the work that you're going to do will either be in Python, CloudFormation scripts, Ansible or TypeScript. Although secondary actions, like if you have something that's functional inside of an application, you can do it from there. Um, Roadmap. So we really enjoyed building out two rail server configurations for the game day, but we are focused on ensuring that we cover the gambit of rail products so that we can make those available to the general, just generally. And we want to start with a modernization component. We have a slot for a Quest at AWS ReInvent this year and we're really looking forward to that. And we want that slot to be filled with an OpenShift configuration. So we are working diligently on building out support for the Corkus Coffee Shop as a component part of the Unicorn Games industry. We are working on the Unicorn Cafe. So the Unicorn Cafe will be our next Quest and that will include some modernization steps to get an application onto OpenShift using various components of the OpenShift infrastructure and we'll be using that for, using that to secondarily extend that into space, which is our edge component. So once we have a successful Unicorn Cafe, we'll launch the Unicorn Cafe into space. And we'd love to. Can I ask you questions before I go though? Sure. Well, so in the early days of the game, that happened a lot and it is quite possible for us to take that kind of action. One of the things that we're doing here is we're creating the social experience and you can bring that on and then in fact, if you've got, like let's say, from your main account, from your command center, your command center can make determinations based on anything. So like if one team had all, like if every other team was using one team as a central source for their game or for whatever it is, for whatever action, like we've built reverses. So literally we have like applications that are just reversers, right? Like you just throw, it just throws a word in, reverses the word and then provides a hash and so you get, the response is the hash and the reverse of the word and the hash gets you points. So if everybody was using the same reverser, right? So if the endpoint came from the same team, then you could probably, you could do something like hit the next level of the game, right? Like destroy all of their networking, right? And so that is definitely a part of the process. You can make those modifications. So the kit will allow you to do that and you can, we can do that in all in the same, you know, consistently in a single account. The, in terms of the technology that you can use, the, because we're connected to the demo team, we can use anything that's in the product suite associated with Braille and OpenShift and then, and actually we can extend that all the way up through the IBM suite. So plus everything that's associated with, with AWS, of course, right? Any secondary service or connected service, we could do that as well. Yeah. Any other questions? Yeah, thanks. Thanks for being here. Oh yeah, I understand. Yeah. Have you been using some kind of messaging system? Yeah, well, of course. So inside of Amazon, inside of AWS, the AWS infrastructure, there is a simple notification service. So we use a simple notification service to cross into, to cross from one account to another. And then we use a queuing system to identify, so that if there are messages that we need to, to carry into another application, we use what we call the simple queue service and the simple queue service is, is there for that. A lot of it is also fired off of the, some simple serverless, serverless applications. So there's Lambda functions and there are container based workloads that for, for larger scale decisions or chains of Lambda functions that, that in fact we'll do, we'll process some of those events in a way that's consistent with the score board and the game and update the databases that are associated. So there's like a bunch of dynamo, like DynamoDB, there's not only SQL configuration here, there's for the dashboard and for the users and for the hash, hash that are associated with the accounts. And that, that is the way that you get, you get support for that continuous feedback. We also have on this side, we have access to streaming services, so we can use Kafka over here, we can use standard message queue on the, on the demo side. So all of the work that we're doing that is connected to the, the Red Hat portal is, is communicates, communications from here and then we have an application endpoint. That application endpoint is something that's, it's not shared, right? So this is strictly set for each team. So each team has their own environment and that environment then is configured for providing information to them and then also feedback into the main, into the main account. So as you make changes here, we use an, we have an API that the, the OpenShift configuration can call and make, and, and make chain, you know, make updates or changes here. All the basic cruddle. Anything else? Well, I'm excited for anyone to do, to do the work. If, if you're interested, please drop us an email and we will, we will get back to you and make sure that you have everything you need in place to, to work with us on the quest. Thanks for being here. Yes. So if we, so, yes, we are, we are breaking everything in a way that is consistent with how, with how this works. And a little bit of history there is that Game Day is based on the, the application that, the way that we build applications like new services or new, new region launches. We, we establish a stress test for Amazon. This is like a basic practice for Amazon is you set up a, or it's a basic practice for anybody who's deploying a service for themselves. But you stress, we stress test pretty, pretty significantly. Test scale, test, test the application sustainability and, and resilience. And then, and then make determinations on what we need to change, right? So whatever fail, you know, you look at what failed or you stress it, you look at what failed and then, and then everything, you know, and then go back to the drawing board and figure out what you need to change in your design. Same thing here. You stand it up, you get other people to use it. That, you know, then we will either simulate that, that there has been a failure based on that stress test or we can, you know, in fact, we may have a stress that, that like literally kills, kills it, right? You might have an auto scaling group that's too small or something like that. And then ultimately, you would have to change it if you have enough people hitting your service, right? So as a social, as a social experiment, it can also be the thing that causes you to run into your own limitations and then have to make an evaluation on what you're going to do next. That is the, you know, that is the project plan. Now, the reason I wanted everybody to come to this talk was because I want them to think, to imagine those possibilities, to understand that from the perspective of being someone who develops a game and then takes that back and takes the development kit and provides us something that can fit into the game experience or, you know, inside of the community-based products that are associated with, you know, with the Red Hat ecosystem all the way up through, all the way up through the more advanced products. We chose to highlight Corkus because we think that that's a very good fit for the OpenShift experience and targets some people that we think are a little bit more, have a little bit less experience around modernization but really want to have more experience around modernization. So we think that they're, they're going to be very excited about the next, the next iteration of our games. I'm glad you had a great time. Any other questions? I think we can leave it, leave it at that then.