So, hi everybody, thanks for coming. My name is Amaya, she is Sara, and we are two female developers that been working as a developer for more than 20 years already. I want to clarify that I start coding with two years. Yeah, okay. Apart from that, we are here just to share some experiences from us as female developers and for our colleagues, also female developers in the tech. We guess that you will be wondering why why we choose this title for the presentation, not the women in the tech part, but the women restroom queues are longer than women's. That's based on a real experience that we live. Some years ago when we went to a PHP conference during the break we were surprised because when we went to the restroom the women's was totally empty and there was a huge queue in the men's one, so yeah based on that real history. We will be using a Google Cloud for this session. You will find one first question now and you will see that there will be more questions in the future because we want to know. The first thing we want to know is which is the restroom that you are choosing in this venue right now? So yeah, you can see everything related to the resrooms. The goals for the session, it's like we are not trying to fix anything in that session. It's a pity that we don't have super power to do it, but it's like we are not trying to do this. We want to share some experiences as I said before that some of our colleagues, women, has shared with us. We will talk about things that might seem normal but when you see them you will think, oh that's pretty normal, why they are talking about that. But they may feel comfortable with some people, so even you think that they are normal. They still remember now, and they happened a long time ago, so that's important for you to see that they are not normal, it's not normal for everybody. At the end of the session we will be super satisfied if just one single person in the whole room can reflect on any of them. That's all. So first we're going to start with some road data that we find about some research and statistics in the internet related to women in tech. So you're going to find in the slides you have the source of the research and statistics. You want to check more or look for some more numbers or data or whatever. Less than 30% of software programmers are women in the US, and they earn less money for the same roads and jobs than men. And another thing, another data that was curious for us, is that only 4% of the funding went to female funded startups or only 60% of 16% to mixed teams, even though the startups founded or co-founded by women get most revenue. So when they go revenue, they get less funding. So about open source contributors or open source world, that is our world. Women represent only 5% of the Apache Sewer Foundation, only 9% of Linus Kerner, 10% of OpenStack, and only 9% of the Github users are women. And what about Moodle? In Moodle, in the total number of employees, there is 40%, which is not bad. It's a lot of people. But then if we start looking deeper and we look at the technical departments like the product one, which by the way is leaded by a woman, is Marie. We have a 33%, which is lower. And then if we look just the developers, we are talking about five people. So, yeah, 11% which is not too high. And with the Moodle community, the numbers are quite similar to the ones that Amaya shared before. In the Moodle top 100 contributors, there are only eight women, which is OK, but it could be better. And in the particularly helpful Moodle, in the forums, in the Moodle.org, we have a 10%, which is also it's similar to other open source projects. So, yeah, now we're going to share specific cases, real cases that our colleagues share with us.  So it could happen some years ago. You can use the same book club if you want to share with us. If you feel represented, no matter the gender, of course, if you feel represented in any of those cases, Julia will help us with the book club. Thanks, Julia, by the way, for all your help preparing this presentation. So, we're going to start saying that we want to make it clear we are not judging. OK, we are just sharing and we would like you to think about them, but that's it, we are not judging anything. So, the first case is something related to something that happened and at least in Spain has been very well known. Because I don't know if you know, but the Spanish female football team has been a champion in the World League. So, during the celebration of the championship, one of the managers of the federation grabbed a genuine Moso's head, one of the players, and gave her a kiss with no consent. So, here at least was very well known, I don't know, in the rest of the world. But this is something very specific that has been in all the news and everywhere. But this is something that still happens, OK? So, there are experiences that some of our colleagues share with us related to that.  Running like a girl was a campaign run like 10 years ago. And it was like to say, because before, it's like sometimes when we are running like a girl, it's something bad. But it's like, I'm going to explain you a secret. We are girls. So, sometimes we do things like girls. I think it's normal, it's OK, it's not bad. And in fact, related to girls running, I want to share with you an experience. Last weekend, in my town, we were organizing a competition for children from zero to 14 years old, three competitions, and do you know who was the winner of the three competitions? Three different girls. So, girls can run and girls can also go green. So, yeah, have you ever been told that you do things like a girl? Yeah, this is another experience, very common. It's important and we know that it's very important to keep people hydrated. We have nothing against that. But it's usually, have you been constantly asked to bring water or coffee or even tea, you know, to the meetings? Yeah, forever young, remember, I'm young. Yeah, I must confess that I am not 22. Yeah, but sometimes people think that I am still 22, and they call and it's like this. So, sometimes when people call and it's a women, the one taking the phone, answering the phone, they think that you are a secretary, but we are not, we are developers. So, yeah, have you ever been mistaken for some one secretary or intern, even when that someone is younger? Yeah, another point, parenthood is not easy. OK, we know that, but it's not easy for everybody, whatever you are, male, female or whatever. But during the hiding process, have you ever been asked if you want to have children or have you ever been password-promoted just because you have children?  And if we are too assertive, somebody can tell us that we are posse. But on the other side, there were also some people sharing with us that they had the imposter syndrome. So it's like, it's like, OK, if we are too assertive, we are called posse. But on the other side, we don't feel confident enough. And even when people are saying to us all the time that we are capable or doing things great, we have the syndrome. So, yeah, that's tricky. That's why we call it quality artifact. So have you ever been called posse for being assertive? Another point that has been shared is that numbers are important, but people are much more important. So we should keep the respect to the people more than the numbers. So have you been asked to participate in something to just fulfill a gender quota? And this is the last one. It's like some of our colleagues shared with us that the majority of their colleagues in IT having women and it was like, oh, that's shocking. That's very different to what is happening now to us. So does it mean that maybe the IT is not something biological and there is something cultural or educational? Yeah. So can you see, can you say that the majority of your colleagues in IT having women? Is that something that you can affirm? So, yeah, those are all the cases that we wanted, the summary of the cases that we want to share with you. So now, apart from the book club, if you want, of course, we are not pushing anyone to say anything. But regardless of your gender, how do you feel reflected in any of the causes that we share? So can you raise your hand? OK, so this is to see that we are not alone. You are not alone. This is normal. It happens to everybody. It's OK to share. It's OK to talk about it because we didn't do anything else, anything wrong. So it's OK to talk about it. And that's a kind reminder for the goal of the consultation. Just to check that if I cover everything. Remember, we didn't try to fix anything. We were only sharing some experiences, some real experiences that some colleagues were sharing with us and women. Thanks to all the women that helped us to prepare this presentation. Yeah, because it was for them. And it's like if any of you have a perfect on them, we consider ourselves super satisfied. It's not true. If there are any experiences that you want to share with us, if you don't have any experience, we can always meet in the restrooms queue and talk about them. No, please. Let's meet in the restrooms. No, no, no. Cachiz, cachiz. Cachiz. Cachiz. OK, so gender equity is everywhere. But every time I answer a sales call for Moodle, I invariably get told, but can we speak to your technical person? So I said, no, I am the technical person. No, no, no, but there must be someone else. So that's one. And in another one of a demo, a client got very offensive. And he said, who's your boss? So I wanted to tell him that I am the boss. I own the company. But I didn't say that. So I think gender equity is everywhere. And I mean, you are all living in far more progressive countries than some of us. So there are far fewer women in open source and tech in countries like India. And the patriarchy is so strong that the men just cannot believe that you will answer questions on Moodle hosting or size of server or things like that. So it's a daily thing. But I mean, you have to confront it so that they change their mindset. And you cannot sort of let it pass. So the next time he says, OK, if he has a technical question, he should come back to me. So it's a daily issue. Yeah, it is. Thanks for sharing. It is sufficient. Salih, it is. I'll also just share. So a few years ago, I actually worked as a computer and technology sales company. So it's basically any PC parts, any accessory, stuff like that. And often I'd just be on the pickup desks, but I was brought over to the sales and people would queue. And obviously men were more predominant coming in to get parts. They would look at the people across the desk and whoever was next would go to the next available. They would see you were a woman and you could see in their eyes that they were just like, I don't want to be served by you. Or if they were and they sat down, they questioned everything you said and every recommendation because they just couldn't believe that the advice you were giving would be actually good or correct. And they would want to get that verified by a man on the desk there.  Yeah, thank you. Thanks again for sharing. I think we've got time for one more. I guess I'll share an experience that's kind of similar to that one. Very shortly after I started my job that I'm doing now, we had a professor come on campus who he is extremely technologically illiterate. And it is my job to help people no longer be technologically illiterate. And he had the impression that every woman he has ever met is his secretary, which played really nice with our entirely female executive team. Yeah, he no longer works for us. But there was a moment where he and I were on a troubleshooting call and he just started screaming at me that he didn't understand what was going on and why aren't I fixing this and blah, blah, blah, blah. I finally was like, you need to stop. I am literally trying to explain to you how to solve this problem right now. But you won't let me speak. So I can't tell you how to fix it. But that's it. Thank you. Thank you. Thank you.


Yeah. Hey, welcome back to Los Angeles. TheCube is live here at KubeCon and CloudNativeCon 2021. We're so excited to be here in person. Lisa Martin with Dave Nicholson, and we are here with Priyanka Sharma, the executive director of CNC. Yeah, Priyanka, welcome to the program. Thank you so much for having me. First of all, congratulations on doing an event in person in such a safe, clean way. I was really impressed when I walked in this morning and was asked for my vaccination record, my temperature was scanned. You're proving you can do these events safely. This is rocket science. So agreed. And I'm so glad you appreciate all the measures we've put in place because this is how we can do it. In-person interaction is essential for us as human beings, for us as professionals. And so we owe it to each other to just do the right thing. Have a vaccine requirement, wear your masks, have these what I call the traffic light system, where if you have a green band, it means people can come a little closer, it's okay. Red means please at least six feet of distance. And these things go a long way in making an event successful in times like this. They do, I love that when I saw that. Mine keeps falling off, I'm cold. So it keeps falling, I'm green. Just so you know I'm green. Yes, I know you're green. What about you? I'm green here. Can I have yours? You can borrow it for a second. What a guy. That's my favorite. And you know, you- I fell off again. I had the three folks that came up who were like co-chairs. Co-chairs, yeah. Yeah, and they did almost a little skit. Yes. That on the surface, people could say, well, that's ridiculous. And it's like, no, it's not. It's giving everybody the guidelines so that everyone can be comfortable. Because when I see your green wristband, I understand that you are comfortable. Yes. Because I don't want to accidentally reach out to give you a fist bump when you might be particularly- Of course. Yeah. Visual cues. Make it easy. Yes. Very, very easy. Very comfortable. Talk about the energy at the event. This is the second full day. Yes. Keena was standing in Ramonli yesterday. Give us an overview of the energy and some of the things that are happening since you can't replicate those hallway networking conversations on video conference. I know exactly what you mean. Man, it is so lovely to be in person, to meet people. And you know, for those who are comfortable, there's like the fist bumps and the hugs and the big smiles. And that energy, I haven't seen it in almost two years.  I've done three cube cons already, but this was my first in person. And being on that stage, experiencing the energy of the people in that room, like when I asked everyone during my keynote, I was like, are you all proud to be team cloud native? And I got a resounding, yes, back from the audience. That's what I'm talking about, you know? It was amazing. What's some of the news that's breaking? Lots of stuff going on, obviously. You said first one in person in almost two years, but talk to me about some of the news that's breaking here at the event. Yes, so much new stuff to share. From our side on CNCF, our journey has been very much about celebrating our culture and welcoming more and more people into it, so that we can have more folks in team cloud native to take various jobs, to find fulfillment, and all those great things, right? And all of our announcements are around that theme of people finding a place here, people paying it forward in this community and building the culture. The first one I would like to share is the announcement of the Kubernetes and cloud native associate certification. So this is an exam that is going to go live end of the year. So people sign up, apparently the beta signups went away like this after I announced it. It was really cool. Wow, popular by demand. Yeah, very, very popular. And it's an exam for folks who are brand new to cloud native. And the studying for it, you'll go through, you know, the fundamentals of Kubernetes, what is the CNCF landscape, what are the key projects, and ultimately, you will actually deploy an application using kubectl commands. And it's such a great primer. So how brand new can someone be? When you say brand new, are you talking about someone who already has a PhD in computer science but hasn't done anything in the Kubernetes space? Tell me, how brand new can you be? That's a very good question. And it is literally, you can come with zero knowledge. You would of course have to study for the exam and like go through that journey. But the idea is that it is the gateway. And so it is possible you are a PhD in computer science but you've studied some esoteric part of computer science that's very unconnected to what we do. Sure, go ahead and take it. But maybe most likely you would like the more advanced certifications better. But if you're, let's say, a marketer looking to break into the cloud native industry, this is the move. Take this exam and suddenly all these employers, you speak their language, they'll be impressed that you took it. And it's an opportunity to advance your career. Community is huge. I was looking at the website the other day, 138,000 contributors from more than 177 countries. 186 is the latest number. 186, awesome, 289 plus million lines of code written. This community is really so productive and so prolific and it's great that you're offering more folks that don't have the background like you were saying to be able to get in and get started. Absolutely, it's our whole thing of bring in more people because as you all probably know, there's so much demand for cloud native skill sets across job functions. So that's why we're here to help them. Yeah, I want to double click on this as we say because you hear the word inclusive associated with this whole community so much. You're talking about something that is a certification, yeah, a marketer, okay, fine. But we're really talking about anyone who has the drive to potentially completely transform their lives. And in this age where things can be done remotely, you don't necessarily have to live in Silicon Valley or Cambridge, Massachusetts to do this or in one of the other global centers of technology. Anywhere, yeah. So that's the kind of energy that's part of this that isn't a part of any large industry focused conference because you really are making opportunities for people of all backgrounds to change their lives. So I don't know, am I extending a virtual thank you from all of those people whose lives have been changed and will be changed in the future? Maybe I am. But talk about inclusiveness from other perspectives. Yes, I think that talent, drive, skills, none of these are exclusive to a certain zip code, you know? People everywhere have great qualities and deserve chances and why shouldn't they be part of a community that as you said is especially inclusive, feels especially nice to be a part of. And that's what I've exhorted the community to do in my keynote yesterday, which is that our ranks will grow and we should go out of our way to make sure our ranks grow and we do that by shining a light on our culture, telling people to join in, lending a hand and letting people's personalities shine even when they'll be different from who we are, whether in terms of job function or skillset, whatever. And I think that's the top level paradigm that we want to have, right? Where we are always welcoming people. When we think of inclusiveness, it is, you know, there is certifications like KCNA did do a great job. There are also efforts that we must always be doing. So something that we work on constantly, consistently, is contributor strategy where we're working on creating ladders and pathways for folks to become open source contributors. It is known now that open source contributions lead to job advancement in your career, right? And so the whole goal is bring people in, not just to hang out, not just to talk, but to actually grow. And actually KubeCon, CloudNativeCon is a great example of another little thing we do, which is we award underrepresented minorities and people who need need-based funds, scholarships to attend. Nice. Yeah, and it's changed 1,518 lives already. And we actually, in this event, have announced that we are renaming the scholarship to the Dan Kahn Scholarship Fund. Do you folks know Dan? Yes, yes. Did you know Dan? So Dan, he breathed life into Team CloudNative, right? He builds this organization to have the impact that it does today. And all the while, he was relentlessly focused on diversity, equity, inclusion. So it was just like, the idea came from within the team and the minute someone said it, it just struck a chord with all of us. We're like, we're doing this, no question. And it was one of the fastest decisions we've ever made. I saw some results of a DEI micro survey on the website where 75% of respondents say, this community is becoming more inclusive. There's obviously work to go, but as a female in technology, you feel that, you see that as well? Yes, I think, I'm very proud of that survey that we did, by the way, because it's our way, we're gonna keep doing it. It's our way to keep a pulse on the ecosystem because you can keep doing initiatives, right? But if people are not feeling great, then who cares? And so, but yes, I think DEI is a journey. There is no destination, right? Always we have to be thinking harder, trying harder to, you know, I think for example, something CNCF's done a great job, is identifying particularly gender diverse folks who are in the community and maybe could deserve a role of high responsibility. So I'm really proud that our technical oversight committee, which is our really the top technical people in the ecosystem who decide project stuff, they are led by a woman. There's many women on that and it's they're all very exemplary, awesome technologists. And so I think the diversity survey gives us like a hint into like the things people do like. And I mean the fact remains, we need to do more to source more people to come into the ecosystem. We need to always be changing and evolving with the needs of the community. Right, as I mentioned, the community is 138,000 strong, 6.8 million plus contributions so far. You can imagine by opening that DEI door, just the thought diversity that comes in alone and the number of projects that will come from folks that just come in with a different mindset. Oh, 100%, we are already seeing that. We started off as folks who had, you know, lots of projects from the great big tech companies, people who had web scale problems, as I call it. And that was great. But in recent years, the end users who were initially just consuming this technology and that too slowly are now hook, line and sinker in. And we have like Argo CD came from Intuit, which is an end user. Backstage came from Spotify, which is an end user. So this trend is growing and the diversity, as you said, is continuing. Yeah, I'm particularly interested in the dynamic where you have people who have their day job, if you will, where their employer is absolutely 100% encouraging them to participate in the community, to develop things that will not only help the employer and that mission, but also building solutions for everyone and providing enrichment for the person. And I'm gonna make a little bit of a prediction. I wanna get your thoughts on this. I think that one of the silver linings of what we've been through in the pandemic, having a lot of people at home, having that relationship with your primary employer, be just a little bit different and just a little bit more removed. I think everyone is realizing that, you know what? We all need a passion play to be a part of, in addition to whatever we're doing to put bread on the table in the immediate future. And so I think, but I wanna hear your thoughts, there's gonna be an explosion in contributions from people and hopefully a lot more openness on the part of employers to let people dedicate their time to this. Do you see that? Do you think that? Yes, I think you're really onto something here. Something I mentioned in my keynote, right, was this conversation I've had with so many that we in this community, our identity is cloud native first. So we're folks who are in team cloud native before we are working at insert company name, you know, Google, AT&T, Spotify, whatever. It's not a dig on the companies, they're actually a celebration of those companies because they are liking the developments that happen in open source. They are appreciating the value these people are creating and they're employing them. So absolutely, there is this ongoing trend of folks seeing great value in folks who understand this cloud native projects in particular. And of course, right, because we have been such a great place for industry collaboration, lots of vendors have great products, make lots of money on these projects and that's as it should be. And so the value of the people contributing to these projects is very high. And we'll only continue to grow, I imagine. So here we are in Los Angeles at KubeCon cloud native con 21, what's next? Well, the good news is this was the first of many to come hybrid events in person plus virtual and the next one is happening in end of May in Valencia for Europe 22, Valencia, Spain. And I have heard beautiful weather, very nice people, amazing food. So just for that. That alone is worth registration. Yes, I know, but it's gonna be amazing. That's awesome. I'm so excited and I hope I will see you folks there. Sign me up. I've never been to Spain, I'm there. Me too, I'm so excited. Let's do it, let's do it. For Spanish speaking viewers, I will say, claro que sí, es la verdad.  You can do it all. You can speak Spanish on the queue, we can host this show. I know, I was like, I'm impressed, I'm impressed. I can't do that and you donated your green card so thank you so much. So nice. Franco, congratulations on the event. Thank you. For growing the community, for growing the diversity of it and for the projects that are going on now and we're sure many more to come. We look forward to seeing you in Valencia in May. Thank you so much, see you in Valencia. All right, we'll see you there. For Dave Nicholson, I'm Lisa Martin. We are live in Los Angeles. The queue is covering KubeCon and CloudNativeCon at 21. Stick around, we'll be back after a short break with our next guest.


Well, hello and welcome to another Dev Nation. I'm super excited to talk to you guys today because we have some really cool things to show you. We're going to be talking about containers. If you are familiar with the concept of the Linux container, or even if you're not familiar with the concept of the Linux container, we have a lot of great things to talk to you about. We're going to be diving in things like UBI and Podman, and we have an expert here at Red Hat on this specific topic. Scott McCarty has been working on this for years. He's known as FatherLinux on Twitter. So definitely check him out on Twitter. I'll actually provide the link later. And if you have questions, throw them into our chat. Feel free to just jump questions to the chat. We'll queue them up. I'll try to answer ones in real time, but at the same time, we'll save some for Scott later in the session. We're going to be moving fast today. It's only a 30-minute session, so just be prepared for that. And remember, if you can't hear, which you can't hear or you can't see, refresh the browser. That's always the secret sauce when it comes to working with us in these presentations. All right, let me turn it over to Scott. He's going to be live demoing all this great stuff. Ready, Scott? I am. Thanks for having me, Burr. So I'm going to share my screen. Do you guys see my screen OK? So I'm going to, this will be about 85% demo, but I do have just a few slides to kind of keep us on track and keep us where we want to be in the use case. So I'm going to do this use case-based.  And I kind of stick to that model to find, run, build, share, and then deploy is kind of what I'm going to walk through today. So I've been doing this for about six years. And six years ago, when I first started with Docker, was the first container engine that I had used that I really kind of changed the way I thought about doing operations work and development work. And the first thing we did was do a Docker find. And we would go out and find all these container images.  What do we do with them? How do we determine if they're good? Sometimes we'd get a gut feeling about it. We'd run some of them. And then at some point, we'd say to ourselves, I want to do more than just run some base image that I find out there or some application that somebody else wrote. I want to add to it. And the way we do that is we build upon those images because they're built in layers. And we would go through this fine run build cycle a lot. And then at some point, we'd build something valuable and we'd say to ourselves, OK, I want to share. I need to share this work that I've done with somebody else because what's the point in doing work or creating value and adding that value to a body of work if you're not going to share it? And then at some point, you'd say to yourself, oh, OK, that's great. I've shared it. Some other people have contributed some work to that body I have. And now we want to deploy this thing in production. And so that was the journey that I've seen people taking. I'm going today to walk through this entire journey with some demoing of Podman, Quay, and OpenShift. So let me just jump over to the terminal because I think it'll be best to just walk through. So I have scripted this out so that hopefully this demo, the demo gods, will be kind to us. I have scripted out and we're going to basically walk through the fine run build, share, deploy process. So the first thing that we do when we start to think about standards are like, all right, let me go find a base image that I can use.  I need some place to start. And so in this case, I'm showing, I'm going to show you a command where we got, and we kind of searched the Red Hat Container Catalog. The command that I ran there was a Podman search, registry, blah, blah, blah. You see the long URL. And then what comes back is a whole bunch of container images that we have out on the Red Hat Container Catalog. And you'll see, OK, you would say to yourself, maybe I trust these container images. I trust Red Hat. They usually do pretty decent work. But I'm not 100% sure I trust them. So what I want to do is I want to show you there's actually another way to verify this, right? Not only can you just search on the command line, but a lot of times you're like, I need a little more information. I need to go out and kind of verify that these container images are what I'd really want. So in that scenario, you'd go out to the Red Hat Container Catalog here. And we provide a really nice command line, or a web-based interface to this. So let me put this in Red Hat Universal Base Image. And then what comes up is a list of container images that we have out here. And in particular, I was looking at the UBI-8 Red Hat Universal Base Image 8. We refer to it UBI as shorthand because it's easier. And then you'll see we provide actually a bunch of information about these container images. So in this case, the most important things I'd point out is we provide a bunch of different tags, and we grade these tags. So containers age like cheese, not like wine, is what I like to say. As they get older, they become less cheese is not so great, a month old cheese, two month old cheese gets less great, wine gets better, but cheese gets worse. And container images, basically as they get older, they're read only, they're static blobs essentially. And so as they age, more and more CVEs and problems are discovered with them. And so often, there will be security problems with them. And so what we do in the container catalog is we actually rate them and kind of give you a shorthand way to figure out if these are container images that you should or shouldn't be using. And generally I try to, I recommend people should always kind of try to be going for a goal of A, right? So I just want to kind of show that we actually have this tooling, this helps you kind of figure it all out. I'm going to actually go back to the terminal and then we're gonna start using these UBI 8, the UBI 8, which is based on rel 8 image. So fine, we've went up to the container catalog, we've realized that latest tag has a grade of A, we're happy, we trust that we think this is good. Cool, let's run one, right? So all right, I'm in a container, this is easy, all right? In a Red Hat, if you look inside the container, it looks like I'm in a Red Hat Enterprise Linux box. That's cool, this is Red Hat Enterprise Linux 8. I can see a more extensive version of this with OS release. You can see a whole bunch of things, different pieces of metadata about this operating system. Okay, but this is kind of boring because what is the point of running, there's a saying back in the day, nobody runs an operating system just to run an operating system. What's really important is the application or the workload that you're running on the operating system, right? So now we start to move from fine, I found a quality base image, but now we're into run, we got through run, just running a base container image. But now what we really wanna do is we wanna build upon that. We wanna start to build more value on top of that. And so we're gonna actually use a little Docker file here that I created. And notice here, we're gonna do a podman build. We're gonna tag it with this special tag here that you're seeing, quate.io slash fatherlinux slash UBI dash sharing. And then the dash f just means use this Docker file. So we just go through a little build process here where if you notice in step three, we just add a few utilities. I wanted to add a few utilities to the container image that I can kind of demo it and we can get into there and muck around and show you kind of some networking, et cetera. Just make it kind of useful. If it was a full fledged application, you would obviously build more on it. Now let's see, when we're done building that, okay. We do a podman images, we can see locally here, we have this container image that's saved locally in my cache and you see it's latest tag and it was created three hours ago because actually I'm just recreating an image that I already had there because I ran through the demo before this. But you'll see now, once we have it cached locally and we say, okay, let's imagine that I've iterated on that a few times and added enough stuff that I feel like there's value here that I've created. I wanna go share this with somebody. How do I share it? Well, you can't share it locally from your laptop. You have to push it somewhere, right? So you'll notice this podman push command. We're actually gonna push it out to a registry server called quate.io in the my user account and this is actually a live image. You could go pull this down and use it today. And since I was using Red Hat Universal Base Image, there's no end user license restrictions on this. You can go use this for whatever you want. You can use it for open source pools. You can use it for products if you're a ISV or a partner of Red Hat or even if you're not a partner of Red Hat, you're just some ISV that sells software. You can totally go use it, UBI. But once you push that out there, now this is actually live for anybody on the internet to use. But really even that hasn't gotten us to where we truly wanna be. How do we deploy this? How do we do something real with this, right? So the question is, in production, there are typically like scalability and high availability requirements, right? Like you can't, running it on a single node is probably not what we wanna do. I mean, a single node for a small web server for maybe my personal blog, that's no problem. But as you get into real world workloads, you need something that provides high availability and scalability so you can scale up, maybe up to 10s or hundreds of containers, maybe in thousands of containers. So Kubernetes has kind of hands down won this race of container orchestration and providing this high availability and the scaling capability. And so I'm gonna show you OpenShift, which is Red Hat's version of, it's Red Hat's distribution of Kubernetes. And to do that though, how do we get there? That's the question, right? So I would say a lot of people kind of sag, they kind of get, they kind of lull and they get a little bit scared when you go from Podman to Kubernetes because Kubernetes has a lot more concepts and things. But I'm gonna show you that we can actually make it really easy to do this. We can use a feature in Podman called Podman Generate Kube. So to do this, I'm gonna show you a very simple container here. So you see, I'm running, I'm just running that container image that I created. I'm gonna run bash in it, but I'm running it in the background. That's what that dash ID means. It means detach. I mean, don't have it connected to a terminal. And you'll see, okay, that little tag that we got back, that big long string of numbers and letters, that's the identity of this container that we just created. We can see it running. You'll see here, if we do a Podman PS, we can see it running. And then this is where the magic happens. We do this Podman Generate Kube. I'm gonna call it Tron because the entire theme of my talk was around Tron. We're gonna write it out to that file and then we're gonna take a look at it. So if you have ever kind of taken a foray into Kubernetes, you'll notice this is a lot, you're biting off a lot more to write out this entire file, right? Like it's not super complex, but it is a lot harder than just typing Podman Run. But actually I was able to just type Podman Run, export and get something that I can basically go take over to Kubernetes and run it as is. And so you'll see in here, this is a pod definition. If you look under this kind to some metadata around the names, but the important bits in here are you'll notice it's using the same image that I was using in that Podman Run command. It's using the same name that I used and it's actually using the same command that I used to run. So you'll see the command is bash. Now let's get out of here and then let's actually use this. We're gonna use an environment that I actually have fired up right here called Code Ready Containers. You'll see in this virtual machine over here, I have something called Code Ready Containers. This provides me a full fledged Kubernetes environment and this is basically gonna let me simulate a full fledged production Kubernetes environment. It's only a single node. In a real life scenario, you might have tens or hundreds of worker nodes out on a cluster, but it would look identical. Once you've gotten it into this tron.yaml, you could submit this to a cluster like this with a single node or you could submit it to a cluster that has a thousand nodes. It's irrelevant to you. And that's the beauty of getting to this Kubernetes format. So let's go take a look at Code Ready Containers. You can see we have a single node here. It's been up for a few days. This is version 1.14 of Kubernetes running inside of this. And then let's look inside.  You'll see this looks just like a production OpenShift environment. You can see there's a bunch of different projects. We're gonna create a separate project for this particular demo. And we're gonna create one called Tron. It succeeded, you can see. And we're now actually, it automatically when we create this project, it makes the OC command, which is OpenShift command. It's basically the command. It's very similar to KubeCuttle. It puts us into that project automatically. So now when we look, you can see we have a new project called Tron and we're going to submit, we're gonna use a very simple OC create command to basically use that YAML that Podman created and then submit it to that Kubernetes API. And then we're gonna watch as magic happens. So you'll see after a few seconds, we'll go from container creating to running. So what just happened right now is we actually just ran a command, ran a simple, simple container with Podman, exported it, created some YAML, submitted that to Kubernetes environment. And now in this Kubernetes environment remotely, in this code-rated containers workspace, or in this code-rated containers environment, we have a running container that is exactly the same as the one that we had locally running in Podman. We didn't have to do any of the work of going and writing all that YAML. So let's look at this. You can see when you do an OC described, you can actually see this entire thing. There's a lot more metadata when you run something in Kubernetes. You can see I have an IP address on this network inside. You can see it's running on the OpenShift SDN. But again, the important bits are, it's using that same container image that I was using. You can see here, look, it pulled the container image down in that Kubernetes environment, and it is using the same command that I ran. So basically, this is the same definition of a container that I ran with that simple Podman command, but I was able to run it in a Kubernetes environment in seconds without having to write any Kubernetes. So now let's look, you can see it was running for about 78 seconds. But let's move on to a more advanced use case.  But what if I'm gonna do more complex stuff? Well, Podman also has the ability to run what are called pods. So a pod is a way to run multiple containers while sharing namespaces. And if you're not familiar with namespaces, namespaces are little pieces of the Linux kernel that are essentially virtualized. And so each container thinks it has its own version of these data structures. So for example, if you look at the process ID table or you dump the contents, as we say, of the process ID table on a system, you will see all the processes on that system. But if you do it in a container and that process ID table is virtualized for only that container, you'll only see the processes that are running in that container and we call that a namespace. So we're gonna create a pod and what that's gonna do is allow us to create all these namespaces. Then we're gonna add a container to it called Flynn. And if you remember the movie Tron, Flynn was Jeff Bridges' character. This is one of my favorite movies of the kids. So I like to reconstruct it. And also by the way, the recognizer was that very large hovering kind of intimidating vehicle that would fly around and smash people with its flat feet and kill the programs that were loose on the grid. We're gonna add Flynn and we're gonna add Bit because we don't want him to be alone in the recognizer as he's hunting through the grid looking for other free programs. And then once we have, now what we have here is we have a pod and then we have two containers running inside that pod. And this is a really cool command, this pod list. We're gonna show you some really interesting things here. So this over here is the pod ID. You can see it's running. It's been up for 45 seconds. But what's really interesting here is they're sharing all three of these containers. You'll see them over here, container name. It's called bit is here, Flynn is here. And then this infra container, this is what is called a pause container. It's an empty container that doesn't really do anything. It's actually just a process that sits there and hangs. It does nothing other than keep those namespaces open so that we can then add those other two containers later. This is the exact same structure. This concept of a pod is what's used in Kubernetes. And in fact, in Podman, we just implemented a version of this. But you'll see these three containers all share the same net namespace, IPC namespace, C groups and UTC. So essentially, think of this as these containers can all see each other's memory and they're kind of sharing a virtual environment together. So let's take a look at Recognizer. This is internal JSON structure that lib pod, which is the underlying library for Podman users to keep track of a pod. So you'll see here, there's three different containers running. There's the pause container and then there's two IDs for the different ones that I created myself. And so if you do a Podman PS, that will show us the containers that are running. You'll see one is, you see I have the Tron one that I ran originally and then you have Flynn and Bit. But Flynn and Bit are together as part of this pod. But the beauty here is, I don't have to do a lot of work to take this exact pod that I've constructed with three simple commands on a single node here on my laptop. I can now use the same kube generate command. I use this, I'm adding a little more stuff here. I'm adding the dash S, which is actually gonna go create a kubernetes service. And then I'm actually using that pod as the name. So I'm actually just gonna grab everything that's in that pod, all the containers that are running, and then export them into this recognizer.yaml. And then we're gonna take a look at that. Now you'll notice here, this is a much bigger yaml file. This is one that I really wouldn't wanna write by hand to be honest with you. This is kind of hard. It has two pod, it has one pod definition up here, but it has two containers. Here's a container. And you'll see this is in this recognizer pod. And then if we go down, here's another container, flin, here's flin and bit was up there. And then down here, even better, we've created what's called a kubernetes service. And it's what gives us network access inside of kubernetes. So the service layer is what inside at a low level is kind of what lets all these containers talk to each other when they're spread out all over tens or thousands of nodes within a big kubernetes cluster. So let's use this yaml to fire up all these containers basically. So first we're gonna create a separate project and then we're gonna look here. We have the original Tron project that was just the simple one that we just ran a single container. And then we have the Tron Legacy one, which was the later Tron movie. I thought that was my little play on the Tron series of movies. So now in this one, I'm going to add, I'm going to use this yaml that I generated and actually create a much more complex setup. And then I'm gonna use the same OC get pods demand. This is a dash w allows it to just keep watching. So it's literally pulling the kubernetes API and say, hey, tell me when these containers run. Okay, look, just within a few seconds, both of these containers fired up. So let's get out of here. And then let's do it again here, what we did. I should go back and show here. We use this OC describe pod. What we're doing is we're asking the kubernetes API, hey, tell me, tell me about this pod and all these things are running in it. And you'll see got an IP address. Again, they're sharing the net namespace. So all both these containers share this IP address. And then you'll see that like it has the Flynn and bit containers are running inside of the same pod. And then you'll see here, you can kind of see through the log, you know, started Flynn started bit. They pulled the images, both these folder images.  But if this was a large kubernetes cluster with a thousand nodes, we would, we would just, you know, it would get scheduled wherever it gets scheduled in this big cluster. But the level of work for you would be identical. You don't have to do anything. You can literally just do this pod minute kubernetes and then push it off to a kubernetes cluster and let it run. So here we go. Let's go look at these pods. You'll see there's one pod called recognizer. It's been up for 82 seconds. And then the really beautiful part is this OC get service. The beauty here is we've actually given an IP address. We put it on the network. It's even got a port up. Now if we were running some kind of network-based application, this would be all up and running inside of this pod. And if we wanted to scale this up, we could scale it up. We wanted to scale it down. We could scale this up to 10 containers down to one. It doesn't matter. We can do all that because now we have all that, all that capability in the kubernetes API, which is much more powerful than just standalone podman sitting on a, you know, a single node.  This is a little known capability of podman. There is a podman generate system D. So I'm going to go back to the simple tron example that I did at the first at the beginning. That was one container, right? But when we run this command, what we get is actually a, there are times when we don't want to go all the way to kubernetes. We just want to run a simple service locally on our system. And it would be really nice and easy to start out, you know, a single container with system D. And it just so happens to be that if you look at this, here's a unit file that was generated. I can literally copy this unit file or podman is actually even nicer to you than that. You can actually just run the dash dash files option to this sub command. And it will actually just generate a file and dump it in the directory. It will actually generate a service file for you. And you can copy this into the directory where system D wants to find it, reload, let system D find it. You can literally do a system D enable and actually run this. You may be asking yourself, well, why don't you just show us that Scott? Well, the reason why, and I'm going to clean up, I'm going to let this clean up and then I'm going to show you why. It's a really interesting thing here that I've been doing that I didn't tell you about. So that's the end of the demo. I've cleaned up everything, but notice where I'm at. I am on a terminal shell and I am running as Father Linux. I'm not running as root. I did this entire demo. I did everything that I just did here as a regular user. There was no root involved. If you look at the history of containers, this was never true. We always had to be root on the local system when we were running containers or we had root even if we didn't realize we had root. I don't have actually the ability to go copy that system to unit file into the shared directory where the, I would need to be root. I would have to sue you to do that, but I can still generate the system file and hand it off to my sys admin and say, hey sys admin, will you please go add this system to unit file and go fire up this container every time the system boots? But this is a really powerful thing that I think a lot of people don't quite realize. It's really valuable to be able to run all of this as just a regular, as a developer. I don't want extra root power on my system. I don't want to be running as root because I don't want some hacker tricking me into running some command that destroys my system or hacks me somehow. So being able to build, find, run, build, share and deploy containers as a non-root user is really, really powerful. It's probably one of the most exciting features in Podman, if you ask me. So with that, I'm going to actually just jump back to share a little tiny bit of information at the end here. You'll notice that throughout this demo, I talked about a lot of technologies. I talked about Podman. I talked about Red Hat Universal Base Image. I talked about Red Hat Container Catalog. I talked about Kway.io and Kway Enterprise is actually a registry server where if you want to do this internally and you don't want to share this with the world, Kway.io is out on the internet. Kway Enterprise is something you buy and deploy locally. I talked about OpenShift, which is our enterprise distribution of Kubernetes. And then I talked about co-ready containers, a technology that allows you to run an entire OpenShift environment locally on your laptop. And so there's a lot of different technologies I dragged in, but I showed how easy to use them all together. It's not that hard. It's actually quite simple. And then I wanted to leave with you a few links. So if you're interested in going out and looking at the Red Hat Container Catalog, that's the first link. If you want to use Podman on a Red Hat Enterprise Linux system, you can actually do that for free. A lot of people don't know that.   And then when you hand that container off to them, it will just, you know, they'll be happy with it. They won't be annoyed that it's something that you download off the internet. It will be, you know, something that's enterprise ready. Finally, again, if you want to run Kubernetes locally, you can go out and check out co-ready containers. Super easy. It takes like two commands. That VM that I showed you that had co-ready containers in it, that takes like two commands to fire up. And then finally, if you're interested in my demos, you can go out here to GitHub. I've actually saved all the stuff out here. Here's the Podman, you know, all the YAML that I generated. And then if you really want to see the start script that basically is the entire demo that I did.  So with that, I think I will turn it back over to Burr to see if there are any questions. All right, there are some questions, Scott. We actually had a ton of interaction. There's a huge number of people on the line today to listen to this talk. So it's super popular. One, could you quickly and one more time, you know, really nail the, what is, how is Podman different than Docker? That was one question that came up. How is Podman different than Docker? Why is it better? Just articulate that one more time. Yeah, I didn't dig into that deeply because I was walking through a use case, but Podman is a really elegant architecture in that it's just a single command. You can think of Podman as very similar to Bash. Like when you fire up Bash, you're just in this terminal, right? You type commands and you don't realize what's happening, but Bash is talking to the kernel to go create these processes on your behalf. Every command you type is a different process. Podman is like Bash, but instead of creating regular processes, it creates containers. And so basically when you run anything with Podman, it's like using Bash to create other processes except that you're creating actual containerized processes. And so the beauty of Podman is that you can run it as I showed there as a regular user. You don't have to have this client-server interaction where you have this daemon out there and then you have a client and then you have to go talk to the daemon. Then the daemon has to go talk to a registry server. You simplify the interaction. And there's a few other places where this really shines. Like when, for example, you're doing remote inspection of a registry server, Podman is going directly out and talking to that registry server. And other tools that Podman leverages, one called Scopio in particular is really nice because it can go directly out to a registry server, copy a container image from one registry server to another registry server without ever actually copying it locally on your system. And so again, it doesn't need root. It can just like move these images between registry servers. As long as you have access to these two registry servers, you can do that kind of thing. So the architecture of Podman is really elegant. That's probably its biggest capability over something like Docker. But on a service, it's actually quite similar to Docker. It has a very, very similar command line interface. And I think that's what people noticed when they saw you doing the demo. They're like, hey, that looks a lot like Docker. How is it different than Docker? Another question that came up from Ibrahim, he wanted to know if the Podman generator of the cube files was using the same technology that Quarkus is using, and there's actually J-Shift that's part of Quarkus and Decorate that's part of Quarkus. Are we sharing and reusing this cube file generation technology across these different projects? I don't know the answer to that, but I don't think so. Ours is written in Golang. I think that's written in Java. So I think they're different. Yeah, I think so too. So that was my response. I'm pretty sure they're different, but I thought it asked. Yeah, I'm pretty sure they're different. I mean, our sprint team worked on this in Podman and we probably created this, Brett Bode worked hard on this in the last four or five, six months. I've never seen any interaction with a Quarkus team, but that's cool if they're doing something similar. That's really cool. Yeah, yeah. I use the other tools myself to do the same kind of thing. Now, Dwayne had a great question right at the very beginning of our session. I want to make sure we get to it and we're basically out of time here, but he's having trouble with his REL7 box and using Sudu. He always finds that he has to do Sudu to make Podman work. Do you have any insights on that? Yeah, I do. I have a lot of insights on that. So the short answer is, are you updated to REL77? Because in REL77, you should be able to do it as a regular user. Rootless should work out of the box. Technically, it is tech preview, so it is not guaranteed to work, but I still use it all the time. I use Rootless. I've actually gone from the point where I'll fully admit, six years ago, I started with Docker. About a year and a half ago, I started using Podman a lot because I'm on the team and I'm like, I should start using it.  I still wanted to have Docker installed and it's like feel warm and fuzzy and I kind of felt secure. And then after a while, I was like, I guess I really don't need Docker anymore. And so I started using Podman daily and for about a year and a half, I haven't had Docker installed. Then in about the last two months, I went from, I used to run Podman as Root because I was just used to running it as Root. And then I started running it Rootless more and more and more. And now I've realized in about the last two months, I don't run it as Root anymore. That is absolutely possible in RHEL 7.7. It's possible in RHEL 8. And we're targeting generally available in RHEL 7.8 in RHEL 7.8 and in RHEL 8.1. So if you're using CentOS or something like that, you're going to have to wait a while because it'll be downstream, it'll take a while to roll down. I've noticed some questions in the forums and things where people are asking about CentOS. The first thing that I'd say is update to the latest one. If you can get to 7.7, you're going to be able to use Rootless. There's one downside to the Rootless in 7.7. It uses what's called the VFS driver. And it will not, so you will use up a lot of disk space and actually the containers will run a little bit faster. They're actually a little bit faster in real-time but they do use up more disk space. When we release RHEL 7.8, we're going to use what's called use overlay. So it's a way of running overlay FS in user space so that regular non-root users can do this. Down the road, we're looking at other technologies like ref links and all kinds of other things that we might use, but for today, use overlay is going to be the thing. And I would say keep your eyes peeled in RHEL 7.8. You should be seeing that drop. Okay. And we are now out of time, but one last question I think we can get to is what about Docker Compose? What's our position on Docker Compose? Does it work with Podman? Doesn't work with Podman? What's the answer there? The short answer is we keep looking at it. We keep trying to decide if it's something that we could support well. There are other upstream projects that basically are trying, there is like a Podman Compose. There's other upstream projects. And the short answer is we'd welcome other people to take that on if they're really excited about it, but it's not an open standard. And it's not the API that seems to be winning long term. I personally think that Kubernetes YAML that I showed you, I didn't show a feature that is called Podman Play. So there is a generate and then there's a play. I can actually play Kubernetes YAML with Podman. So I can like take the Kubernetes YAML, export it from OpenShift, run it with Podman. And then as I showed in the demo, I can generate it locally with Podman and then run it in OpenShift. I actually think it's much better to use that Kubernetes YAML as the definition that we share around to each other to develop as opposed to Compose. And people will say, well, the Compose YAML is really easy and I can write it by hand. And I get that, I totally understand that, but you don't have to write it. Like Podman exports it for you. So like why even write it at all? I would say just export it, hand that to somebody else, let them play it and like forget about writing YAML and JSON files. Like it's just not worth it. That would be my, that's my personal view on it. Well, unfortunately we're out of time. Thank you so much, Scott. Awesome demonstration and great way to present this topic. We have a lot of more questions where we just simply don't have time to get to them today. I apologize for that. We'll have to come up with a future presentation maybe that's more of a Q and A type session with you. That would be a lot of fun, I think for people. And we can advertise that widely for people who really are more interested in diving deeper into what's happening with system D, what's happening with when I'm at port. So I see those questions guys and I apologize, we just want to have time for today. Time for today. But thank you so much. Thank you for being here for another Dev Nation. It was a great time, great topic. I learned a lot. Hopefully you all learned a lot as well. And Scott, awesome job. Thank you so much.


Good afternoon. My name's Sean from a company called IHS. We're a global company doing data and analytics. I'm actually from Canada, although we do have an office here in Bangalore. And what I want to talk about today is Agile architecture. More specifically, what is the potential role of an architect in Agile? Do they have a role? What does that look like? And this is an experienced report. This was an actual story that we went through in a small part of our organization that I was involved with. And so I'm not going to pretend anything in here is the right way to do things or how you should do things. This is our story of discovery and what we learned in our own process. And maybe there's something in there to take away. Quick question. Who was at my talk about building a sustainable organization a few days ago? If not, that's fine. I'm not offended. Is there anybody here who is a handful? I'm just curious because I might make a couple references, so I just wanted to know how much background I need to have. This presentation actually really isn't mine or doesn't belong to me. It really belongs to my friend and colleague, Chris. He's kind of the guy who will be referencing a lot. Unfortunately, he wasn't able to be here, but he will be giving this presentation at the Agile conference in Washington, D.C. this summer. So if you're going to tweet it all, you can include his Twitter handle and wake him up at four in the morning back home. So I was actually really inspired by Dave's talk this morning. And then there was a question afterwards about, well, there's a lot of terms here and there's a lot of sponsors, I believe they were called. And maybe it wasn't immediately applicable, how do you apply this? I thought it was a really great talk, but I started thinking, well, how can I apply it? And one of the things I talked about a couple of days ago was leading by example and modeling the behaviors we want in our teams. We want teams and we want people who can accept risk, take a bit of risk, not afraid to fail early. And I thought, okay, well, how can I personally do that? So what I did is I said, okay, well, I thought Dave's talk was really interesting. Is there any way I can apply it? I know very, nothing more than about the Kinefin framework than what I saw in the talk this morning, but I frantically worked over lunch to figure out, well, okay, what concepts from there might be applicable to our own experiences. There's some way I can tie it together. So I'm taking a bit of a risk here. We'll see how it goes and I'm sure I'll be wrong and I'll learn about it, but I hope by being able to take that leap of faith myself, I can encourage everybody that it's okay to maybe take a bit of risk once in a while. So without further ado, this is myself.


Watch me write a grade 9 GCSE paragraph for Romeo and Juliet. Step 1. Start with a point. Always embed your evidence. 3. Explain your evidence, mention technique, and include context. Step 4. Link back to the question. Done! Here's my point. Here's my evidence. Here's my explanation. Here's my link.


Let's talk about these skill moves. I know you guys love all the fancy tricks. If you've been following me for a while, you know what I always talk about. Get over the flash. Fancy tricks are cool, but only if they work in a game. The idea behind developing these skills is so you can beat players. If you're trying really complicated things and you're losing the ball every time, it doesn't matter how good your skills are.  It doesn't matter how good your skills are. So whenever I do skill videos, I want to show you real moves that actually work in games. So these are a few that I use. Some have a bit of flair. Some are super simple. I promise if you stick to them, you become confident going right and left. You're going to beat so many more players. So let's talk through it. I will try to remember all nine. Number one, I just did a body faint. So dribbling out of the defender, I'm just going to fake with my entire body and do a hard step. And I'm going to try to send his body control, send all his weight to this side. And then I'm going to attack the other space. So I'm dribbling out of him, hard cut, push into the other space. If I was going right, I would step left, push right. So there's a big difference between this and this. So I need to start selling my fakes, selling my fakes. Sometimes you might do a lot of skills, but it doesn't actually trick the defender. In order to really get him to shift his weight so you can create space over here, I need to put a little more emphasis on the movement. I need to step a bit harder, get a bit lower to ground, throw with my shoulders.  And also being down in this position is creating leverage here. I'm allowing myself, I'm helping myself explode, explode into the new space that I've created. So when you're doing your fakes, I want you to think about getting a little lower to the ground and actually trying to sell it with the shoulders, with the upper body movement, with the eyes, be more deceiving with your movements. So in the video I did, in the demonstration I did, a single, but I also did a double. And I mean you can go as many as you want, just don't get yourself in the habit of doing too much because you have to be aware of the defender. You might have already beat him, you might have already sold him with one movement. So if I take another one here, now I'm going back into the space that I already created over here. So look at the defender, if he's shifted, boom I can go. If he's staying with me, maybe I have to lose him again and I can come over here. So body faint, heart sell, quick explosion. Next is a, I'm calling it a cradle step over because instead of just putting my foot around the ball, instead of doing a normal step over, I'm actually starting the skill with this touch.  Because I'm not actually touching it with the inside of my foot, I'm cradling it into that space. So cradle the touch. So I'm going to cradle, then I'm going to step over. So I'm basically faking this movement. I'm faking this, and I would explode there. But instead of exploding away, I would go into this space here. So again, with all these skills, I want you to practice right and left. Right, touch with the inside, step over. And again, where is my body positioning when I do the step over? Is it up here? Or is it down here? And then I can explode quickly. You have to have the ability to go both ways. And the ability to control your body.  Unless you have way more pace than me, unless you have way more skill, I want you to start being able to go both ways, right and left. So work on these skills with both feet. Next I did a multiple step over. In the video I was actually doing like a triple. But double step over. If you get caught up in it, you can go triple. Like you can do as many as you want, just think about what I said before. There's no point in doing skills if you've already created the space. Once you see the space, boom, explode. All these skills, it doesn't matter so much what you do with the ball. It's what you do with your movement after you create the space. How many times you've played with, maybe a teammate or against a guy, he doesn't have the best skills, but he beats so many players because he just explodes. He has like one touch and he just sprints with the ball. He creates the space and he sprints with it. Maybe he doesn't even do skills. He just sees the space and he goes. Keep it simple, create the space, go, attack the net, go forward with the ball. The fourth skill that I did was called a Ronaldo step over. So it's kind of two movements. It's roll, step. So it's like a scissors, a scissors to a step over. And I'm starting with this roll here. Out into space. If I went the other way, roll, step, come on. So start slow, get the movement and then it'll go. I want you to always look, a lot of times I do this, different skills, but it's the escaping touch afterwards. So if I come here and now this touches forward rather than side, I'm a lot more likely to get tackled. So I want you to think about that touch when you're trying to escape from someone. It's this touch. I'm getting away, I'm going like a triangle, right angle, rather than he puts his leg out and I just put my escaping touch there. So again, both feet, Ronaldo step over. After that I went into some simple moves and I put them in the middle because I know so many players are going to look at these and they're not as flashy as the other skills. So they're going to overlook them. But realistically, these are the most effective ones. These are the ones you can count on the most and they're going to help you beat the most amount of players. First was the croquette. So it's inside, inside. Now let's really break down the skill because there's much more to it than two touches. Number one, it's the direction of this touch. Just like I talked about with the escaping skip. I don't want to put that touch here because that's easy for him to tackle. I want to put it across my body and even more so, if I can put it backwards into myself, it's going to be much harder for the defender to reach the ball. Okay, so think of the direction of that touch and then also the speed and the force, the pace of that touch. If this touch is slow, it's easy for the defender to get the ball. If it's quick, he can still lunge for it but it's going to be too slow to get the ball. And also I'm really stretching my leg because I don't want to receive it here. I want to receive the ball here away from the defender. And all these skills, it's being able to do it while running with the ball. So you'll see me and a lot of good dribblers, when they're approaching the defender, it's these little quick touches. Because if this touch is heavy, now my time is off, my spacing is off, I can't make the move at the right time. Keep that ball close and then when it's time to go get away. Keeping it simple and effective, the next skill is just that skip. So remember we talked about the escaping touch. Well that is self, it's one of the best moves in the game. Watch Messi do it. Robin used to be so good at it for Bayern in so many years. I mean he's still so good at it. Wherever he's playing in the other ones, I forget the team.  Okay, so dribbling, skip forward. And you'll notice it's a bit of a jump. I'm not just like here, here, here. I'm actually jumping out of the tackle and moving forward with the ball. Forward and then with pace, attack. I want you guys to get in the habit of when you're dribbling, if there's space there, just sprint in a straight line towards the goal until someone tries to tackle you. You don't have to beat him and then beat him and then beat him and then beat him. All you have to do is sprint with the ball in a straight line until someone tries to close you down. Then you use your skills to escape. But if the space is there, don't hesitate. Don't drop with the ball when you should sprint. In that habit of being more directly to dribbling, you're going to be way more dangerous. Next skill, keeping on pace with those simple ones. This is another simple one, but extremely effective. I was just calling it a hard cut. So if I want to get into that space, I'm going to dribble here and I'm going to do a hard cut. Now it's the weight of that touch is so important. The direction of it and the weight of it. And my body movement. So think about beating players with fewer touches. What's more effective?  If I take too many unnecessary touches, more defenders are going to close me down. What's more effective? That or this? And now I'm already in the space. So a hard cut. So dribbling there, hard chop. And I want a better cut than that. Okay, so think about target change in direction. And like I said before, it's what you do after the cut. After I make this cut, am I coming up and then jogging or am I practicing my acceleration skills? Staying low and getting away. Be direct. The ability to go both ways. Accelerate after the movement. I'm not even talking about the technique of the skill. I'm talking about what you do, the mindset of dribbling. Next was a spin I called it. So dribbling at the defender. Basically here, I'm going to turn away from him and I'm going to try to make him get close to me. When he gets tight to me, I want to spin the opposite direction. Okay? Because once you do this, he thinks he's going to be able to get tight to you. And he might slow down, he might be a little lighter off the feet or a little heavier on his feet, I should say. And when he does that, he gets tight to you. Spin into the space that you created. Okay, so there's two ways to do it. And before, sorry, yeah, before we talk about the skill, this one especially, but all these movements, when you're doing that change of direction, you have to get low. Because if I'm trying to spin up here, I have no balance, I have no power, I have no acceleration. So here, here, can I just stay low on the ground, use your arms? So when he gets tight, I'm actually going to spin him. I'll put my hands on him, spin, give him a little, a little push in the opposite direction. Obviously not enough to get yourself in trouble as far as a foul. But put your hands on players, learn to protect yourself. So many players just play like this. You have to learn to get your hands up, use your hands, use your upper body as well. So two ways to do it. First was the outside cut, next was an inside cut, super low, hands up, protect yourself. Once he gets tight, make that spin. Now if you go to do this movement and you don't feel him coming close, or don't see him coming close, then you probably can't spin back into him. Okay, but I could turn on him and use a different skill to get past the defender. Last one that I wanted to show you was, it's a move that uses kind of different than running straight at a player. It's like you're drilling, you have one on your back, you're trying to lose them. Maybe you're on the wing or you're on the side.  So I'm basically faking this movement. There's a couple of different ways to do it. Okay, but I'm faking that I'm going to push the ball backwards and then I'm going to dribble into that space. So it's like we're both running together, I can't quite lose him. So I want to get him to stop running. I want him to be running with me and then think that I'm going backwards. Get that half stutter step and then you can create that inch of space to get past him. So a couple of ways. One would be, let me do it here for you to see. I could roll back and tap with the inside. I could just roll with the sole. Let me do that better on my left. Roll with the sole like that. I could go super fancy and something like that. Okay, but more so than the touch, it's selling it like we just did with that body faint.  And then I would get past the defender. So think about those skills, but like I've talked about so many times throughout this video, it's not so much about the skill, it's what you do after the skill.