Microservices and Red Hat OpenShift

Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

Jason: Hello, everyone, and welcome to another episode of Learn With Jason. Today on the show we are waiting for my API to load. Look at this. Oh, there it goes. What's up, everybody? So, we have David Nugent with us today. We are going to learn about so many things that I'm just completely out of the loop on. So, I'm actually really excited about this. But before we talk about that, let's talk about David. For those of us who aren't familiar with your work, you want to give us a little background on yourself?

David: Oh, yeah. So, we met years ago at like conferences and stuff. I used to run a lot of JavaScript conferences before they became socially irresponsible, to get a bunch of people in the same room. Even before, it was pretty irresponsible to talk about JavaScript. Now it's even worse with COVID and everything. But yeah, also doing developer advocacy for a bunch of startups. For the last three years, I've been at a really big startup called IBM, which is we're up to like 350,000 people. I think we're going to go IPO soon. And we just acquired Red Hat a couple years ago for like $34 billion.

Jason: That sounds like a startup.

David: Yeah, yeah. So I thought I should talk to Jason about Red Hat. That's what I thought.

Jason: You know, IBM, though, is trying to get that startup vibe going. I remember I worked there years ago. They had bean bag chairs and ping-pong tables. They had the boxes checked.

David: Yeah, I was on the bean bag committee for a few years, actually. It was about $15 million, and we had quarterly meetings. No, I'm just kidding.

Jason: (Laughter)

David: But you believed me for a second, didn't you?

Jason: I mean, the thing about companies at a large enough scale is you can say literally anything had a committee and I'd be like, yeah, they probably did.

David: It's actually really fun. I love that we've acquired Red Hat because they have so many cool products and the Open Source ethos and everything. It's a lot of fun for me to talk about.

Jason: Yeah, for sure. So one of the things that Red Hat brings is OpenShift. So, OpenShift is something that I really don't know anything about. You know, like full disclosure, I once upon a time was a full-stack dev. I would build and deploy servers. These last few years, I've moved very much to the front end. The deepest I go now is I write a ton of serverless functions but don't really get into server deployments unless I have a very specific need. So I'm really out of the loop. I don't really use Kubernetes. I don't really know how docker containers work. I don't mess with any of that stuff. So this is going to be a very new area of content for me. I'm really excited to learn about it.

David: No, that's awesome. I also don't know anything about it. I thought you were teaching me. How does this workshop work again?

Jason: Oh, this is going to go poorly for both of us. Okay. So let's get to Google.

David: To be honest, I'm not actually worried from the technical side. I'm just having trouble centering my head in the frame, but I think I'm getting there. I think we're going to be good. Yeah, so Kubernetes is something -- a lot of people are probably using it, even if they don't know about it already. It's taken over the world, right. I'm an application developer myself, too. I don't do very much DevOps stuff. I come at all this from I want to deploy a Java application or a JavaScript application. So that's sort of like my intro to Kubernetes. So one of the cool things about OpenShift is it lets you deploy applications like super, super easily in an enterprise environment. I'm just going to ignore that.

Jason: Thank you for the sub. I saw Luke subscribe earlier. Thank you for that. Sorry, did I warn you ahead of time that this show gets really noisy? The chat is going to troll us.

David: I'm really glad for that. I just hate people taking themselves too seriously. But I wanted to say about the application, normally enterprise companies pay for OpenShifts they can manage their multi-cloud deployments. It's a product. It's not an Open Source project like Kubernetes is. So there's license fees and stuff like that. If you're a startup or big company and your application depends on Kubernetes, then you're happy to pay for it. So one of the cool things about the link I sent you is we have this lab environment where we'll give you Red Hat OpenShift cluster for free. So you'll actually be able to go in, spin up the cluster, deploy an application. You can actually deploy your own application if you want. It doesn't have to be the one in the lab. Then you can see it running on your Kubernetes cluster. So anybody in the audience, if they wanted to, could actually follow along and get their own cluster and deploy it. So that's one of the cool things about working in dev education and IBM. You get to give people free stuff.

Jason: (Laughter) Yeah, that's a perk of the job, kind of having that IBM-sized marketing budget.

David: I got lots of clusters. Who wants a cluster today?

Jason: Cluster Oprah over here. Okay. So let's talk a little bit about -- okay. So we know that -- I hear terms like cluster. When we're talking about, like you said if you're a startup, you'd be happy to pay for this service. I'd love to talk about why. So what makes -- I guess what's the purpose of a Kubernetes cluster in general? Why would one need that?

David: Yeah. Like, I have a whole presentation with diagrams and stuff like that, but I'll just make little diagrams with my hands. So I'm old, and when I was a young'n, you'd deploy an application by putting it in a server and running it on that server, but that was super inefficient because then what if nobody is using your application or what if too many people are using your application. You've heard all the stories about startups in the '90s, like eBay. They'd be like, too many people are using eBay. We need to buy a bigger computer, but we can't buy a big enough computer. So then they started getting into like virtualized deployments and stuff like that. Then you had dual operating systems. It was pretty inefficient. Then containers came around and it was like, wow, this is great. We can actually use the same Linux operating system but securely constrain the resources so one container can't modify the resources of another container. So super, super lightweight. It also gives you this nice separation of concerns between application developers like us and the people who do the real work keeping the servers up and running, like the DevOps folks. As application developers, we care about the application, the binaries, are all the dependencies working, is everything being pulled in correctly. Then from an operations perspective, they care more about up time and stuff like that. You know, are the network ports configured correctly. So the container is a nice way to ship all that data from one side to the other and separate those concerns. So if you have infrastructure on your dev team side where you can actually build containers and you have infrastructure on your ops side, that can take those containers and deploy them, then you can end up with this really cool, really efficient infrastructure. So Kubernetes, it was a project -- actually, it started out at Google. They open sourced it. I think it was originally called Google Borg or something like that.

Jason: Borg. (Laughter)

David: That's a little too mean. We'll call it Kubernetes. It means helmsman. It's like Greek for helmsman.

Jason: Wait, is it really?

David: Yeah. There's like a logo.

Jason: I thought somebody just looked for a word they could trademark. Let's just make up some sounds and trademark that.

David: It's probably both.

Jason: I'm also learning today how to pronounce it because I've heard Kuber-neats, Kuber-nay-tays. Kuber-noodles. Cuddle noodles.

David: I do tell people if I haven't met them before, I always make sure to tell them it's pronounced Kuber-noodles and see how they react.

Jason: Exactly. Cuddlenetties. Excellent. And if you've ever been browsing technical content, you've seen the abbreviation K8S. People are talking about Kubernetes when they use that abbreviation.

David: Oh, absolutely not. That's something totally different, Jason. Why are you spreading rumors? No, that's right. Yeah.

Jason: Nooberkoodles. That's a good one. Chat's got it going today. So if we've got Kubernetes and we know that Kubernetes is a way to take containers and kind of -- to maybe oversimplify this, if the original problem was we had an actual server machine in our office that we needed to hook up to, to send things out to the internet, and as our business got more popular, we had to have more machines to handle all that incoming traffic, which is impractical and complicated. So, containers made it so each machine ran exactly the same. Kubernetes made it so we didn't have to talk about the machines themselves. They would kind of auto scale or contract when they weren't under load so we can say I have this server image, and I want this to run under any load indefinitely without costing me a million dollars. Kubernetes is a way to say -- or I guess without costing me a billion dollars. I guess you could have a million-dollar deployment if you're a big enough company.

David: Yeah, by the way, if you are looking to spend a billion dollars on Kubernetes, let me give you my card.

Jason: I forgot how software sales work. You walk in and you're like, hey, I'd like to buy some software. How much does it cost? The sales team is like, well, how much do you have? (Laughter) But so --

David: No, you're totally right about that. The only caveat to that would be that it actually -- the problem that Kubernetes solves is pretty specific. So the problems that you mentioned about all the servers running the same code and the network being configured, there are whole ecosystems out there of other products that work with Kubernetes to still solve those problems. So one of the nice things about the project is that it's not like it tries to solve every problem. It tries to solve some very specific problems. Those problems are usually around, you know, as containers became more and more popular, you started to see them more and more in production. Then you needed to orchestrate them and manage, like you said, I've got these hardware resources and I've got these containers that I want to run with this level of resiliency. I've got this budget. I can't use more than this CPU, this amount of RAM. How can I do automatic packing to fit these containers? So it definitely does all of that, but it doesn't do a lot of the other stuff. It doesn't define any application middleware. It doesn't do a lot of stuff with logging or monitoring or alerting. There's a whole ecosystem of other tools that obviously works with Kubernetes since it's like the standard, and all of those tools form this nice ecosystem. So one of the things that Red Hat OpenShift does to sort of separate us from the Kubernetes open source project in people's minds, I guess, or if I could do that, if I could separate it a little bit, they provide an opinionated stack. The stack involves Kubernetes, right, on top of core OS. Then a bunch of extra features. So if you wanted to, say, run a service mesh, Kubernetes would be like, great, we've got one built in. If you want to deal with a particular CI/CD pipeline -- or I'm sorry, OpenShift would be like, we've chosen one for you. Even if you don't end up paying the license fee for OpenShift, you can learn a lot from the sort of resources that OpenShift has chosen. Also, even if you don't use OpenShift, there's something called the Distribution Origin Community, which is free and open to everybody.

Jason: Well, that answers a question from the chat, which is what is OKD? Excellent. So, this is cool. I see some new faces in the chat. Thank you all for showing up. Good to see you here. So I think at this point, we could talk about it, but honestly, we're starting to get into some conceptual layers, and there's only so many layers of an onion I can get into before I need to look into it. I'm going to switch us over into pair programming mode. While we're doing that, let's look at our live captioning. We've got Rachel here from White Coat Captioning today, who is writing down all the things we say, which is great for everybody except probably Rachel. So thank you, Rachel, for putting up with us today. And that is made possible through the support of our sponsors. We've got Netlify, Fauna, Hasura, and Auth0, all kicking in to make this show more accessible to more people, which we very much appreciate. And with us today on the show is David Nugent. If you're not following David on Twitter, you can head on over there and do that. Don't do it.

David: Not worth it.

Jason: We're going to be working with IBM Cloud a little today, but it sounds like we're starting here, which is with kind of a starter kit that's going to let us jump right in. This is the one that you wanted to work with here.

David: Yeah, is this link shared in the chat?

Jason: I just dropped it in the chat.

David: Oh, sweet. Okay, nice. So yeah, I wanted to be able to share this with everybody, as well as Jason. First of all, the link there you're seeing, if you complete these three labs and do a little quiz at the end to make sure you were paying attention and weren't just copying off of Jason, you'll get a little badge you can share on your social media or tell your boss so that if your boss is like, hey, how come you're just watching Twitch streams all day, you can be like, I earned a badge, back off! You could do that here through the link. Also, I wanted to gamify it because I know Jason can lose interest and start slacking off.

Jason: It's true. I do wander off midstream. Okay. So to do that, I'm going to just click on this button here. Does it matter what I use?

David: No.

Jason: I'm going to use GitHub. I'm going to promise not to them them you didn't capitalize the H.

David: That's probably another trademark issue. (Laughter)

Jason: Okay. So we are signed into that. These things all match up. I'm going to create my account.

David: So the idea with this, probably as a developer advocate for IBM, I should be encouraging you to sign up for an IBM account. Realistically, you can use any of these. I just want you to get through the labs. Once you're registered, you should see this nice little site here, which is the challenge. The challenge is you get these three labs you can do. There's also a leader board. So you can earn points and get on the leaderboard. Personally, I don't care about that at all. If you care about that, then yeah, go for it. So once you're signed in, you can click each one. It'll take a hot second to spin up a cluster. So I think you have to click login to access again.

Jason: Launching my quick lab. I'm not a robot.

David: Oh, you passed. Okay, good.

Jason: I was worried they were going to ask me to identify photos of things. Sometimes they'll do those, and it's like identify all the pictures of boats. I'm like, I don't know. I'm surprisingly bad at identifying boats in photographs apparently. I miss that one all the time.

David: Never going to make it to VP level at this rate, Jason. That's becoming a huge requirement of software engineering.

Jason: That's true. Boat identification is a large part of what I do in my day-to-day.

David: See if I can endorse you on LinkedIn for boat identification. One time I was able to endorse my boss on LinkedIn for gluten intolerance.

Jason: Is it still just open ended? You can endorse for literally anything.

David: No, there was like a list, and gluten intolerance is in the list.

Jason: What an interesting skill to have. Okay. So I think we're in good shape here. I have a standing rule on Learn With Jason, which is whenever there's onboarding but I also have somebody teaching me things, I refuse to read. I'm going to make you be my onboarding instead.

David: This is actually really fun because normally in the lab when I do these labs, I'm like you can ignore most of the text, especially in the Java lab. Java is such a verbose language. I think whoever wrote the lab really likes Java, so there's a lot of text.

Jason: Is this like an integrated VS Code environment too?

David: Yeah.

Jason: That's cool.

David: So the important thing here is that you click continue. Jason, you're already at step two. You're so good at this. I mean, you're not a robot and you're at step two. This is amazing.

Jason: Yep. Turning complete over here.

David: So I think what you can do is hit terminal there in the upper right and do new terminal.

Jason: All right.

David: So the idea of this lab, lab one because there's three labs, three ways to win big. I don't know, is that -- am I being market-y enough now? So lab one is super simple. It's basically I want to deploy an application that I've already written on to my OpenShift cluster. So you remember OpenShift is running on top of Kubernetes. When your application is deployed to Red Hat OpenShift, it's going to be running on Kubernetes. So what if I had an application that was just sitting in a Git repo, sitting out there on GitHub, and I want to deploy it as fast as possible. So there's this tool called source to image that allows you to do that. Using this environment, we'll clone it down to the local environment, as you have so.

Jason: Just started it. Now I'm going to move into it. Getting some comments. Solid one from Jessisunderwater. Three ways to win big with Kubernoodles. Very, very excited.

David: This is really great. If I don't get fired at the end of this, it'll be amazing.

Jason: (Laughter) And yes, this hat, I love this hat. I found this out at the Oregon coast. I was very happy to find it. But I don't know how you can get one. You have to go to the Oregon coast, I guess. Okay. So now I'm in here. I am in here, and what do we have? Oh, cat our Dockerfile.

David: Yeah, you can. If you're super interested in Dockerfiles, you can look at the whole thing. Is it interesting? I don't find it particularly interesting, but you can see some of the stuff it's doing. It's saying I want a specific image. So one of the things you'll be thinking as an application developer is the code in the GitHub repo is just a tiny portion of, you know, my deployment. I also have to tell it like, hey, I want you to run Node or run this JVM or something. One of the nice things about sourced image and OpenShift is they have all these different environments preconfigured. So you can say hey, node ten, do it. Then in the same way, what directory do you want to be in, what commands do you want to execute. You want to run npm install. That's basically what this Dockerfile is telling it to do.

Jason: Nice. Okay. So it's saying here we want to do oc new-build. What is oc?

David: So, oc is sort of the command line equivalent to the sort of kub-ctl command.

Jason: Cuddle control.

David: Yeah, there you go.

Jason: I like that one. Cuddle control is my favorite. People argue about the pronunciation of that, but kub-ctl is my favorite.

David: Do you like cuddle fish? Like just as a snack. They're an amazing --

Jason: I do. Hold on. I'm going on a tangent. I have a thing that I made. It was the first meme that I ever made in my entire life. It was this one. I'll make that the right size. I sent that to my partner. Look how weird its eyes are. Anyway, cuddlefish are cool.

David: Oh, yeah. Now I should probably talk.

Jason: (Laughter)

David: So there's this command that reminds me of cuddlefish. So oc is sort of like the OpenShift equivalent. One of the cool things about these labs is that you've got OpenShift, and you can use your command line if you want to be cool and pretend that you're not just sitting and wasting time on a Twitch stream. There's also the OpenShift console, which is this user interface you can use to interact with your OpenShift deployment. There's actually a tab up there that you can click if you want to explore that. I mean, you might as well, right? I think it'll pop up another window.

Jason: Okay, here we go.

David: So it's like two ways of interacting with the exact same cluster, same node, same applications, same everything. Except this is the user interface, like the visual way to do it. Then on the command line, we're sort of doing the command line thing. For example, when you go in and create a new image on the command line, you can see it reflected in real-time through this user interface.

Jason: Got it, okay.

David: You can see on the left there's a ton of UI, right. Operator workloads, networking, all this stuff. If you scroll to the top, there's administrator. If you click on that, you can change it to developer. So there's two contexts, I call them, two ways of looking at the application. So as you deploy more applications, as you create more end points and stuff, you'll actually end up with this little directed graph here. It's a topology view, they call it. You can scroll around and zoom in and out, like Google Maps style and see all your different applications, see their status, when they're deploying, when they're re-deploying, all that stuff. So when we're in the command line -- this isn't part of the lab, just something I thought was cool. When we're in the command line and start creating stuff, you'll actually see it be reflected in this topology in real-time, which is pretty cool.

Jason: Nice. Yeah, I'll keep that open so we can play with it. So I've copied this command in here, which is going to do a new build.

David: New build. We're going to use the node ten image and call it example health. You'll see that. So you can run that. You'll see that in the UI. So let's just scroll down a little more in the lab.

Jason: Oh, gotcha. Okay.

David: It'll say like, it should look like this. Yeah, cool. Then you'll run that oc start-build command for example-health.

Jason: Just going to copy that so nobody has to watch me type.

David: Love it. Yeah, so the nice part for me from the user interface side is first of all, sometimes you like to just click around so you don't make some typos. Also f there's people interacting with your cluster who aren't necessarily super command line oriented, they can actually get access just to certain parts of the administrator context. So they can go around create users, stuff like that, and you don't have to worry about them accidently removing one of your deployments or something.

Jason: Okay. All right. And so it's doing stuff.

David: So all this stuff -- also, if you go back to the UI, you might be able to see it building at this point.

Jason: There it goes.

David: So if you go back -- you can feel free to click around wherever you want. It shouldn't affect anything. It's mostly just sort of like read only. Not creating it yet.

Jason: Still doing stuff over here.

David: Still doing stuff.

Jason: It's not actually pushing the layers yet. Oh, dang. What just happened? Ben. Benjamin. Benjamin Code Zen. Thank you very much for the gifted subs. Welcome, everybody, to the boop crew. Remember, now you have access to the boop emote, which means you can cause complete and utter chaos if you so choose. And remember with great power comes great responsibility. If you start a boop drop and you don't finish it, a Corgi gets sad. So anyway, okay. Storing signatures. Things are happening now. What's up, prince? How you doing?

David: There are a lot of boops on the screen now.

Ah, behold, my bucket!

David: This is unrelated to your OpenShift license. If there are any enterprise customers of IBM watching here, this is not something that'll happen to your application. It's purely a Twitch thing.

Jason: (Laughter) Yes, that is fair.

David: If a VP in my organization is watching right now --

Jason: The boops have nothing to do with OpenShift.

David: Nothing is going wrong. It's all planned.

Jason: Wait a minute, I thought we were going to teach IBM things. They're talking about boops and cuddles. What's going on here? (Laughter)

David: The IBM Cloud boop is the most resilient boop on the internet.

Jason: I don't know why I just pictured this, but I pictured your skip level SVP as being like the chief of police from a children's cartoon where he's like, damn it, Nugent, what's going on out there?

David: I should mention I'm just kidding. They're very supportive. But I am also a little scared.

Jason: (Laughter) All right. Now we're copying config. Push. There we go. Now we should see this out there if I reload.

David: Now you should probably see something on your topology, hopefully. You are also looking at a specific project, I believe.

Jason: Am I? I don't actually know what I'm doing here.

David: That's okay. Let's just go back to the lab. I don't want to confuse anyone too much.

Jason: All right. Let's go back to the lab. Here we go.

David: Sweet.

Jason: And we're not deployed yet.

David: Yeah, so now we'll actually want to deploy the application. If you go through the UI, this is like a one-step process. It's multiple steps on the command line because you get more flexibility to change it up and make mistakes. But you know, it wouldn't be one of these shows if I wasn't baiting Jason into making typos and causing chaos.

Jason: Okay. So now we've got -- did it work now? There it is. We had to deploy it first. Now we've got ourselves an actual topology. It's got an arrow. I don't know where that goes.

David: If you click on it, you should get a little context. It should tell you the current state of the application.

Jason: Cool.

David: Yep.

Jason: We've got logs. We've got an overview. This is nice.

David: Yeah, not bad. So one other thing I should mention is the cluster that we're assigning to you, it's like a full-fledged cluster. You can go in, go through all the context menus, deploy applications and everything, but it's not super powerful. That's just a resource consideration on our end. I think you get two nodes or something like that. If you were running this in an enterprise environment, you could have thousands of nodes, and they'd be across multiple clouds and all that stuff. So now what you can do is actually expose a route to the outside world so that people could actually use your application. I find that takes a certain amount of confidence in your coding and deployment ability.

Jason: I have the utmost faith in my ability to copy/paste.

David: Sometimes I like to keep my applications to myself. You know, just running on my own laptop and not let anyone access them. But once you do that, you get a big host and port number there that you can copy. Actually, anybody could copy this. It's now running.

Jason: So this will get us out to -- look at it go. Demo health. Look, chat. You can go look. Everybody go look at my cluster.

David: This is a quite dull application, but it is a node application that's running on a node ten environment in Jason's cluster that he was assigned as part of this lab. If you go back to the lab, there is actually --

Jason: Oh, interesting. It's telling people that it's not available. This might be Twitch doing something weird with links, too. Sometimes it'll break up long links.

David: Oh, interesting. I wonder if it has something to do with the port number.

Jason: Oh, if you go https, it's not going to work. So remove the "S" because we haven't added a certificate yet. That'll take you to the app. But it's not going to have a cert yet.

David: And I believe there's some login information in the lab. You can actually log in and see all of Jason's health, his private health information.

Jason: Okay. Let's try this. Let's go in and poke at it.

David: There's all sorts of UI. You could change his blood pressure, turn off his pacemaker.

Jason: Please don't. (Laughter) Hey, what's up, Alex and the front-end horse crew? We're playing with OpenShift today. I just deployed my own Cuddlenoodles and we're looking at it now.

David: The most marginally work safe of memes.

Jason: That's work safe.

David: It's work safe sending it to your partner. If you sent it to my skip level VP --

Jason: They'd be very confused. All right. Fair enough.

David: So the idea of this is that it was just super straightforward. You just copied a few commands. If you went through the interface, you can deploy it yourself. Actually, do you mind if we sort of skip out of the lab and just go into the interface and you can see how that works?

Jason: Yeah, let's do it.

David: So if you go to, I believe, add over there on the left.

Jason: Okay.

David: You can see that you can add applications in a ton of different ways. The way that we were doing it is from Git, but you can do it from a container image you've got. You can say, hey, here's a link to Docker Hub. You'll see there's a UI that corresponds to a lot of the commands that we were using before. So what's the Git repo URL? What builder image do you want to use? And if you go farther down, there's tons of other sort of things you can do. Right down there at the bottom, there's those links for routing built configuration. If you click on each of those, you get even more configuration options. So it makes it really easy. If you want to see, hey, how can my application I'm writing today deploy to Kubernetes, it makes it super, super simple.

Jason: You know, and what I do like is that you did abstract away that stuff you don't have to fill out instead of showing me 10 million forms and being like, well, it's up to you to figure out which one of these is required. So that's nice. By default, I can throw in a Git repo and choose my image, like choose the node image and just fill out some basics.

David: I was working at a university, and there was a guy whose whole job was maintaining this Windows application he wrote. It was just a rectangle of a ton of check boxes and acronyms and pull-down. You had to get everything set exactly correctly. It was terrible user interface but great job security. He worked there until he wanted to retire.

Jason: (Laughter) So this, we did this using the CLI. For everybody who just joined, what we're actually doing here is we're doing this lab. I'll link to the resources for everybody who just joined. But we're doing this lab right here of completing a series of three labs. This is lab one. What we've done is we've deployed this node app. This node app is running in a Docker container on a Kubernetes cluster that is powered by OpenShift via IBM and Red Hat.

David: Yeah. Sponsored by Netlify, captioned by White Coat Captioning, starring Jason Lengstorf with a hat he found on the Portland coast. Or the Oregon coast.

Jason: Yes, narrated by David Nugent.

David: Special guest David Nugent, who marginally understands what's going on now.

Jason: (Laughter) But so what, we took probably ten-ish minutes in between screwing around to get this whole app up and running. It's functional, and we've got this dashboard over here that we can see of what our applications are. So here's our running app. This is pretty slick stuff. We've got good information here about what's going on. We can see it's running. We have a quick jump to the logs. So as far as getting an app up online, if I need to build a node service, this seems like a pretty straightforward way to get that up on the internet.

David: Yeah, yeah. I think, you know, if you're looking for ease of use, you'll probably end up using another solution just because OpenShift, the real value is if you have this app running in a multi-cloud environment and you want to manage all of those resources. Or if you have a bunch of microservices that are communicating together and you want to deploy all those. So this, I think -- the point of this exercise was to show even though this thing is super powerful, it still is this easy to deploy one extra application, right. So your 1,001st application.

Jason: Right. And a question in the chat is, is this similar to Heroku? It sounds like this is enterprise flavored Heroku.

David: Yeah, I love Heroku. It's super, super cool. I would say for each -- I'm not going to say one is better or worse.

Jason: Sure.

David: But I would say the difference between them is that Heroku is also super developer focused, right, makes things really easy for developers who are trying to deploy applications. OpenShift also allows a lot of flexibility for that sort of developer focus but also with a lot more flexibility for running it on multiple clouds. So you could run it on your private data center. You could run it on IBM Cloud, Azure, AWS, GCP, one of the international providers. You could run it on the Edge. You could run it on your local device. You could actually manage all those deployments from this console. So it's kind of like your own personal developer-focused Kubernetes platform. So in that sense it's nice because you're not really tied into any vendor. This particular one that we're running just has two nodes that are running on IBM Cloud, but that's just because I can't get stuff on GCP and AWS.

Jason: (Laughter)

David: I mean, it's free, right? It works great. Let's do it. But once you get OpenShift, you can deploy it wherever you want. A lot of our customers have, you know, financial services companies and they're like this particular data has to be on our servers, on this continent, in this regulatory framework. This other data is, you know, end points for our iPhone application, and that can be syndicated anywhere. Anyway, sorry, I hope that wasn't into enterprise-y and boring.

Jason: No, it's important to understand. I think the thing that gets challenging, especially as you start to scale up in businesses, is understanding why would somebody move from a free service or a cheap service. Like, I've got a $5 a month digital ocean droplet. What's the reason my business would move from that to the $10,000 a month, $50,000 a month, $1 million a month deployments? Why would you spend that much on ops? There is a reason for that, and it is that as things scale, they get so much more complex to manage. Typically, you start paying for the orchestration, the management, the service agreement like somebody who's willing to respond to your email at any time of day. You know, the guarantees of that availability of multi-cloud. This is actually something that one of the big things Netlify does. We put content on a multi-cloud CDN so that if AWS has an outage, your website stays up. You know, that's the sort of stuff -- that's why people pay. That's what you're paying for, dependability and easier management. So it's worth having those conversations about the differences between the cheap thing and the enterprise thing. It starts to be less about, well, this runs an app and that runs an app, and it starts to be a lot more about okay, this runs an app, but what happens when my billion-dollar business depends on this app and something goes wrong?

David: By the way, I'm really excited to see how Netlify has grown. I used to hang out at that office all the time when it was like a much smaller company. I've been using Netlify since you had to go down the hall to use the toilet. Like, that's how long I've been a customer. So, yeah.

Jason: Now we don't even have an office anymore. We've gone fully remote at Netlify.

David: No toilets. You're full circle.

Jason: You have a toilet in your own house now because that's where you're working from. But you don't have to share it with anybody. Unless, you know, your family is wanting to use the toilet.

David: I did see that note you don't have to share a toilet with anybody on your careers page. Thank you for clearing that up for me. It's a weird marketing standpoint. I respect it.

Jason: Indeed.

David: I saw somebody was asking in the chat are there system requirements to run locally. Yeah, there are. It's actually pretty lightweight because in the end you're just running Kubernetes on top of core OS. So you can -- as of OpenShift 4.7, you can run on Edge devices, which tend to be, you know, more power constrained, resource constrained. So they're definitely moving in that direction.

Jason: Nice. Nice. Okay. Well, let's keep on trucking then. We got about 45 minutes left. Let's see how far we can get.

David: All right. So we're pretty much done with step two. I think step three is just like if you want to run some commands to spin down your application because your cluster is not super powerful. So when we start getting into the microservice stuff, it's nice to have all of your resources to yourself. So you could run cleanup.

Jason: I'm just going to copy/paste all of these. Boom, boom, boom, boom, boom. Gone.

David: So fast.

Jason: And the last one. Done. All right. And there it is. It's out. And that was nice in real-time. I thought I had to refresh the page. Apparently I didn't have to do that. So now this is lab one. We've completed lab one.

David: You've completed lab one. Congratulations. You're one-third of the way to getting your badge, which I know is your only real motivation for doing this, Jason. So I appreciate you paying attention.

Jason: Look, I'm not showing up here to learn, I'll tell you that much. (Laughter) No, so this is great. We've walked through the basics. We had an existing Docker container. We got the thing deployed and were able to look at it on the web. This one, it looks like we're going to do like an API.

David: Yeah, this is sort of like a microservice based application. Oh, this is the hardest question.

Jason: No boats.

David: No whammies for lab three.

Jason: Okay. So now we have -- here we go. We've got our environment. I don't care about that. You're my onboarding.

David: There's a lot of stuff in this lab, to be totally honest, that I simply don't care about. Maybe I'm not the best person to give this lab, but some of it still is important. So yeah, you can -- I think that one is important. So anybody out there watching -- if there is anybody watching, I'm not just sure because I'm just looking at Jason in a Zoom meeting, does anybody do Java development? This one is using microservices in a Java development environment. It uses OpenLiberty, which is this open framework for Java.

Jason: Can we get a J in the chat if you use Java? This is a mostly front-end stream.

David: If they don't use Java, can we get a sad face because now they have to watch people programming Java?

Jason: We have some Java users. There's one.

David: Okay, yeah. So it's kind of cool. They're taking -- I use the JavaScripting language. That's good.

Jason: J and also sad face. (Laughter) Oh, good. Good, good. I'm just continuing to skip over everything here.

David: Yeah, seriously. Just keep going.

Jason: So I don't need any of this?

David: I feel like we've absorbed it through osmosis. So that's fine.

Jason: All right.

David: As anyone who's worked with Java knows, you've got, you know, your language, but then on top of that you've got your framework. Then on top of that, you've got your build environment. There's so much stuff. So there's lots of details in this project sort of walking you through how each of these is configured. If we walked through each of them, then it would just take forever. So I think it's more interesting to just talk about what we're changing. So there's a few things that you need to change. You just need to separate the overview steps from the stuff you actually need to change. So this one actually says update the config files. You've got it open. I think it says add the above to the properties section and a new line at the end of line 21.

Jason: So I'm just dropping this right in here.

David: Yep.

Jason: And we're giving it a context root of liberty project, which is not currently existing here, but I assume Java knows what it's doing.

David: Oh, yeah. Yeah.

Jason: Yeah, that seems right.

David: So I think you want to save this.

Jason: Then docker finish, source, main, liberty, config.

David: I should mention Java developers get paid by the subdirectory, which is why you see a lot of these really expand.

Jason: Oh, okay, okay.

David: So this was probably written by a senior developer.

Jason: This is one of those things. You know, teasing Java aside, the reason that Java does this is because Java is like library dependent. So everything -- organizing your files is a big part of making Java usable because you have to include everything.

David: Right, yeah. And the included paths map to a lot of the text you write in the includes in your code. So I think this one -- update the server config file.

Jason: Yeah, so I'm just adding that there.

David: Context root is the same there. Liberty project. I think we'll be using that later when we actually test the project.

Jason: Got it, got it.

David: Then you can save that one.

Jason: Okay. So let's move into finish. I'm there. Until I'm there. All right.

David: I like that step. Make sure you ran that demand.

Jason: Is mvn short for maven?

David: Cuddlefish? No, it's maven. That's right.

Jason: Okay. So we're going to do maven.

David: This is why I don't use JavaScript.

Jason: So maven like a build tool for Java?

David: Yeah, yeah.

Jason: Okay, okay. It's building. Look at it go. Oh, it's going so fast.

David: Is it though? (Laughter)

Jason: We're moving along. Here we go.

David: I'm sorry. I used to be a Java developer. So I still have a very like snarky, caustic attitude about Java. I love it. It's great. But I feel like sometimes I need to take the piss out of it a little bit.

Jason: You have to laugh at your pain or else you'll cry, right? That's me in all code I write.

David: Except your hat. I mean, that's just all smiles. That's an amazing hat.

Jason: Also didn't write the code for this hat. (Laughter) Somebody else wrote the code for this. I can be proud of that.

David: Are the number of people watching going down as the maven build?

Jason: Just cratering. Everybody is like, all right, time for lunch.

David: Oh, my god. I love this so much.

Jason: Okay. So as we are letting that run, we're going to --

David: Yeah, the downside to this lab, I'll ruin the surprise for you. The upside is that it's really cool. Running open liberty, open source, great, love it. The downside is that the actual application that's being deployed is something that looks into the system properties, takes a bunch of data, and relays it back as a restful response to your end point call in JSON. So at the end of this lab, it's not going to be a really cool example health node JS application where we can mess around with Jason's vital signs. It's going to be a big JSON blob of boring properties. So I want to set the expectation low. Even though it's really cool infrastructure wise, at the end it's like, oh, a JSON message that might be an error message. Sweet.

Jason: That's okay. We're going to be okay. I'm ready. So now I'm going to launch application.

David: Yes. Then you just want to make sure your port is correct. I think it wants you to put in 9080 there.

Jason: Oh, 9080. Right. I told you I wasn't going to read.

David: Don't do it, man. It's a slippery slope.

Jason: Open this one. Oh, this is a fun graphic. I like that. They seem so unconcerned about what's happening. This is maybe not the moment to be chill. (Laughter) Okay. So then I'm going to go to -- it looked like there was a route that I wanted to hit. So let's hit that route.

David: Copy that. And append it to your thing there.

Jason: Okay.

David: Hey!

Jason: And this is our data about our thingy.

David: This is your super boring JSON file that I was promising you.

Jason: But it's good. We can see our Java spec. We're looking at -- you can see IBM. You can see the vendor.

Ah, behold, my bucket!

Jason: Exactly. See, the chat's into this. No, I like it. Being able to see this stuff, the fact we were able to get this up and running.

David: Ah, but Jason, we're only one step into lab two.

Jason: There are more steps. Okay. So now I run mvn liberty stop. There it goes. Okay. Mvn liberty -- oh, or from entering into another -- I don't need to do both.

David: Now you can click continue. You can see we are step four of five.

Jason: Oh, my goodness. Okay. So let's do mvn package. What does this do? I don't know. Let's just run it.

David: This gives you time to go get a soda. Just like every maven command. No, I'm sorry. We have a lot of Java customers. I should really stop crapping on Java all the time.

Jason: You're going to just get some very grumpy emails from the maven maintainers. How dare you.

David: Okay. I apologize in advance if any Maven maintainers are on the stream. When you finish typing that email in three or four days, which is how long it's going to take you based on how long it takes Maven to do anything --

Jason: Wow! Wow! Couldn't even get through the apology without shade. Oh, my goodness. Oh, geez.

David: Is anyone hiring a developer advocate, by the way? I know OpenShift and Kubernetes.

Jason: He just became available. (Laughter)

David: My boss tells me I no longer work there. Okay.

Jason: All right. So now I'm going to use the OpenShift cluster command to build our REST app. What we did before is ran it ourselves. We were doing local development. What we're doing now is we are saying we actually want to deploy this on OpenShift.

David: Let's actually ship it, yeah.

Jason: So let's ship it. I am shipping. Here we go. I have shipped. All right. So then we're going to start. Okay. We're saying where the start directory is. It's the home directory. And here we go.

David: As you remember from the previous time, each of these steps takes a minute. Also, I should mention a lot of this waiting time, you know, some of it is just because of the resource constraints of these free clusters we're giving you. Maybe if Netlify could pony up a little more money, we could give them three node cluster.

Jason: But it's a factor of the memory and the stuff on the machine. Effectively, the more we pay, the more power the nodes have that we use?

David: So I think for this particular task, it's not particularly resource intensive. It's just the really constrained amount of resources that we've given you in the cluster. But yeah, generally, most of the time when we do a lab, we'll do like three or four or five or six nodes. So it looks like you are in your get build. Nice. So you can scroll down a little bit, hopefully.

Jason: Down to here. Looks like it's supposed to look. This will give us logs for it, right?

David: Yeah. And so the log should end with push successful message. It might take between two and three minutes to complete.

Jason: Oh, so this is just us tailing the process.

David: Yeah, yeah. So this is another good time to, you know, get a beverage, do like one of those boop showers, share more of your not-safe-for-work cuddlefish memes. There's all sorts of stuff. Jason's like, where's the command to get Dave off the screen?

Jason: Just kick. Yeah. But yeah, okay. Chris does bring up a good point. It's all fun and games, but it has to be done with love. You can't make fun of a project maliciously, right.

David: No, that's really a good point. And I want top say that I am saying all this in jest. I would feel terrible if somebody was actually maintaining one of these projects and took offense, especially because each of these projects is working for, you know, hundreds of thousands or millions of developers out there across the planet. For every one person who says, ah, it's a little slow, there's a ton of people who want to make sure that it works on different platforms and in different languages, works on different versions of the JVM and works with different deployment models and works with different infrastructure. So it has to take all of that into account. Plus, a lot of these projects are open source. So some of the maintainers aren't being paid as part of their day job, or perhaps they aren't being paid at all or just paid through community contributions. So yeah, I definitely don't want to come across as a total jerk.

Jason: No, and it's fun to tease, right? But there's a line. I think it's just important to remember, like, we love to -- like, we're here because we join coding. Nobody is watching this show because they're like, man, I hate coding. This is a place where you go if you like to code, if you want to learn about coding. What I hope the chat will take away from this is it's fun to joke about our own pain. Then we just don't want to cross that over into being mean to the maintainers themselves. They do a ton of work. They don't -- a lot of them don't get compensated for it. So we want to make sure they feel the love from us, not -- you know, we should never make them feel bad for doing work. There's so many considerations there.

David: Thank you for bringing that up, Chris. I appreciate that.

Jason: Oh, hey. And we're done. Perfect. You know what, that was such a good "and now let's take a moment to remember all the people in open source."

David: No, no, it was. Absolutely.

Jason: But yeah. Okay. So, perfect. We are now -- we've pushed. We are at the next step, which is -- this just starts it?

David: Yeah, you're going to create your new application. This is the thing that'll get it popping up into your topology view.

Jason: Ah, yes.

David: Now you're going to expose the route so everybody can view the app on your cluster. Sweet. So now if you do your oc get routes command, you should see what the route actually is.

Jason: And it all happens so fast here. So here's our route.

David: I think you missed an R at the beginning there.

Jason: No, I'm going to need that. Okay. Oh, no, no, no. Sorry. I'm doing this wrong. Give me that R. Then dot cloud and slash quick rest lab.

David: I believe that's right.

Jason: No, I did it wrong!

David: I think it's longer than that. You want to go back to the lab? There's some instructions there.

Jason: Okay. All right. Here we go. This one? Your app URL will look like this. That's what I got.

David: Yeah, yeah. You got that, but you want to go to slash liberty project. You see that farther down?

Jason: Oh. I misunderstood. Okay. So this route is not --

David: That's yours. That's just the base.

Jason: I understand. So I'm just -- liberty project. Cool. Then in here, go back to the lab.

David: There you go. System properties.

Jason: Properties new. Hey! There it is again.

David: This should be the system properties of your console, of your OpenShift cluster that you were actually able to -- that we're pulling that data from. We took that same application you were running in your little visual studio environment, and we shipped it over to your cluster. Now it's getting the data from that cluster.

Jason: Yeah. Yeah, yeah, yeah. So we've now -- and I think we can go back to our topology. There it is. We've got our rest quick lab. We can see it. We can look at our logs. All sorts of good things going on here. So this is pretty powerful stuff. Like, I'm pretty excited to see just how -- here's the thing that I think is important to note here. If you are a developer, if you're a node developer, Java developer, whatever, building the service locally is your job. Getting that service up on to the internet has, in my experience, you end up needing to go through a back-end team and a DevOps team and a bunch of other teams to all get that stuff actually through to the finish line. Part of that is just necessary you want safeguards. You want people checking on your stuff and doing quality checks. But part of it is just that it falls so far outside of the job description. I remember being at IBM. I was hired as a front-end developer. In order to get a front-end on to the internet, we had to get the front-end into a node microservice, into a docker container, into a Kubernetes cluster, and then up on to our deployment into production. What tools like this do is takes some of that out. We can kind of use a preconfigured, look, just get it up on the internet. Here we are now without me having to understand how Kubernetes works, without me having to understand the intricacies of doing -- like, there are words I don't even understand. Connection pooling. I don't know what those are. I don't want to know what those are. That's not my job. But I do want to be able to put things on the internet without having them fall down or cause me a bunch of pain or get me in trouble, get me paged, stuff like that. So that's, I think, the thing that's exciting about tools like this, especially if you're trying to build back ends right now. You want a back end to go up and just work. This is a great tool for making that problem just go away. You get to deploy the thing. Then you just look at your dashboard and go, is it up? Oh, good, it's up. Then you go on about your business.

David: I definitely love the topology view, too. Once you start getting more microservices up there, just having one way to see which ones are currently deploying, which are up, which ones are having issues.

Jason: And presumably, I'd get a red X here if it was down. So I'd be able to see very quickly which of my services are unhealthy right now.

David: And you'd be able to dig into it. Or potentially, somebody in your supervisory chain or somebody else who might not necessarily be super familiar with the command line. So it's great to allow a lot of people to get information about and access the system without being more danger than they're allowed to be.

Jason: And I can just rebuild it, too. If it crashed, I could be like, ah, just build it again.

David: Yeah, all that information is in there.

Jason: That's really nice. Okay.

David: You want to see if we're finished with lab two? I think the only other thing to do is to --

Jason: Clean up after ourselves, right?

David: Yeah, clean up after ourselves.

Jason: Here we go. Did I do this stuff? Where am I? So, troubleshooting. If we wanted to see how things are breaking, which they're not currently, we could do all of those things. Get pods, that's similar to if you're using cuddle control, right? Yeah. Cube cuddle, whatever it is. Cuddle cube. These we're not going to need. So let's continue. Nice work! I did it. So let's get back here.

David: By the way, if anyone is following along and wants to get the badge, it may help to have the questionnaire. There's sort of a quiz at the bottom after lab three. It may help to have that questionnaire up as you're completing the labs. Sometimes it wants you to copy and paste some data from the lab into the quiz. So if you have interested in getting the badge, that's one way to do it. Pull up the quiz, and as you're completing the lab, you can fill in the answers. I feel like Jason already has his favorite badge, which is the flag on his hat. So he probably doesn't need the Build Smart on Kubernetes badge. So we can go to lab three.

Jason: We have about 20 minutes. Is that enough time?

David: To be totally honest, every lab that I've done -- every time I've done this lab, I always schedule an hour. In one hour, we're only able to get through the first two labs. So I literally have no idea how long lab three is going to take.

Jason: Great.

David: I've done it before, but not in this environment. Yeah.

Jason: Should take you approximately 30 minutes. We're going to have to go faster than that. So let's go new terminal. We're doing a speed run, everybody. Strap in. We need like danger music. Oh, I need to -- okay. Somebody find me royalty free danger music so I can make that happen. That sounds like so much fun. Okay. Let's go into our model prediction. This one we're going to do object, which is pretty exciting. (Elevator music)

Jason: That's not danger music.

David: (Laughter)

Jason: Okay. Max object detector microservice. So is this a Watson thing?

David: We have this model asset exchange online where we have a bunch of useful models that you can just download and use. So this is what we're going to be doing. We're going to take one of those models, train it, give it some data, and seeing what happens.

Jason: Okay. So I've opened my console. Switch to the developer view. I'm there. I'm ready. Okay. So to do that -- oh, we're going to use the thing.

David: Yeah, we're using the UI to do this part.

Jason: Okay.

David: Nice that we did a walkthrough of the UI already. And we're actually not going to be using a -- I think we're actually going to be using an image. Oh, gosh. Actually, I hope that we're able to get this image because if I remember right, this is from the team. I don't know if they've paid, so I think the number of images is throttled. Fingers crossed we can get this image.

Jason: Okay. Let's find out. This one.

David: Nice.

Jason: Okay. Does it matter what I call it?

David: I think you can call it whatever you want.

Jason: View the deployment. General. Name is pre-populated. Yeah, I can just leave all that. We'll do a deployment. Thank you for gifting a sub. And thank you for subbing. I appreciate it, Jessisunderwater. Advanced, we're going to create a route. Okay. So under create a route, there it is. Good. It didn't actually open.

David: Oh, if you click on routing there.

Jason: Oh, routing. Path, target. Those all seem right. Then click the deployment link. And we are just setting cors enabled to true. We don't want to argue with cors today.

David: Just the Maven open source team.

Jason: Scaling, replica is one. Okay.

David: Nice.

Jason: Resources, we want to have two and two. Two, two.

David: And I think it's Gi, not Mi.

Jason: Okay. Glad you caught that. I definitely wouldn't have. Click create. All right. You've got a sub. Boop it up. Look at this thing go. And a friend. (Laughter) I love it. That's what this stream is all about, making friends. Dropping boops. Okay.

David: A lot of times if it gives you an error, it just means it's currently in the build process. So it's an error just because it's not reporting its status yet. So if you just leave it -- just leave it alone for a second, Jason. Geez. No, just kidding.

Jason: Give it a second. It's going to space.

David: (Laughter) But yeah, if you go back to the lab, does it want us to do anything else or just wait until it's done?

Jason: Open configuration.

David: Lunch truck it here.

Jason: Select the resources tab. So let me go back. Click the label. Resources tab. Route, okay. Make sure the pod status is running, which I don't think it is right now.

David: It is not.

Jason: Okay. So let's try to keep a peek on those logs.

David: Since you don't have any logs, it still looks like it's in the deployment process. That is just my understanding. Let me see if I can look it up and see if there's --

Jason: Failed to pull image. Uh-oh. Error reading, manifest denied. I need authentication.

David: This might be because of -- I feel like maybe we hit a limit with Docker Hub. This is a good question.

Jason: Let's see here. View the deployment. Yeah, doesn't look like we're going to get -- there's no extra bits. Think we got rate limited?

David: Might be. Let's see. Deployment options. Well, we could pull it from -- you know, let's go back to topology. Yeah, back to the topology. Then if you click on that and then actions. Wow, that's annoying. Edit deployment.

Jason: YAML, YAML, YAML.

David: Oh, god. Can we go to overview?

Jason: Overview.

David: Then autoscale scaled to one. Maybe it's just easier to delete this and re-create it with a different --

YAML, YAML, YAML, YAML, JSON, JSON.

David: Wow, apropos.

Jason: So I want to delete this one.

David: Yeah, sorry. So we have had this issue.

Jason: Knowing full well we're roughly ten minutes from the end here.

David: Yeah, eff it. Delete it. Can I say that?

Jason: Eff it, yeah. We can go with that. Got to do it like Battlestar Galactica. Frack.

David: Rockets!

Jason: Let's try -- so I'm going in here, going to add. You wanted to use Quay?

David: Yeah, so there's this -- I don't know. Where should I send it?

Jason: Throw it into Twitter DMs. That's going to be the fastest way.

David: Twitter DMs. This is where I'm pulling it from --

Jason: Okay. So we're going to --

David: That's the article I'm trying to pull something from.

Jason: Okay. So this is what we got. Then for me to pull this, I would do -- oh, you got another link for me that I wasn't looking at.

David: Sorry. I'm dealing with my own nonsense here. Yeah, so that's the thing. This is the Docker Hub location. But this is the one we tried that didn't work, right?

Jason: Right. This is the one we pulled, and it failed on us.

David: Don't like it. Don't like it.

Jason: So let's talk about what would be different about this particular lab versus the previous one that we just did. Because I think we're not going to have enough time to solve this.

David: Curse you, internet gods. Sorry, everybody. Yeah, this is actually a really cool lab because we're taking a public model, and we would actually be pulling it in and using it to classify image data. We are running into a fairly simple error, but it's something that is also difficult for me to troubleshoot remotely. What I can do is try to troubleshoot this on my own and come back with a solution, which I'm sure will be really simple. The idea here is that instead of taking an image that is -- instead of building a container image from scratch given, you know, data about a microservice or given a GitHub repo with some JavaScript, for example a health application, taking that, building a docker container, or just a container in general, and deploying it on to Kubernetes, getting a route, and viewing the application. With this one, we'd actually be taking a publicly available image, in this case from Docker Hub, but it could be from a private registry, some other container registry, and deploying that directly to the cluster. That might be something that you would do maybe even more often if you were using this in an enterprise environment. Maybe you'd have a procedure for building your containers that didn't involve just pulling from GitHub and using an existing container image.

Jason: Right because I can imagine you would have a container that's like a pre-configured box to handle whatever. Like some kind of business logic that needs to be shared across every team. You can start there and configure in. Those types of workflows -- I mean, honestly, I don't use Docker very much, so I'm not sure how configuration works after you get an image. I can see this one being useful, for example, if I wanted to do any kind of user input. It could be useful if I had a machine learning image that I could call that would look for problematic language or not suitable for work images, or things that would at least help kind of auto mod, so at least flag stuff if it's questionable so a person can go look at it and go, oh, yeah, that one's fine, but these ones are spam or inappropriate. And not having to deploy that myself, being able to just grab the -- like, hey, this is our company's policy, we use this model and these settings to check for content appropriateness. If you are taking any user input, stand up this microservice, send all the content that comes in through it, and you'll get back an auto modded kind of thing. I can see a lot of use cases where that would be helpful.

David: Also, we kind of got pretty deep into Red Hat OpenShift and the console and the UI and everything in labs one and two. If we hadn't, then this lab would also be an exposition into creating a new application and end point through the user interface. But of course, we sort of came ahead and did that already, so it wasn't a surprise to us. But it is also a cool reminder to check out the model asset exchange. There's a lot of really cool machine learning models out there that should be free for use.

Jason: Yeah. Yeah, yeah. That's great. And thank you, Ben, for the sub. One-year anniversary this month. Thank you for watching the show for a whole year.

David: Wow.

Jason: Holy crap.

David: I thought it had only been on for 90 minutes. That's awesome.

Jason: (Laughter) In the name of Jay, welcome to the boop crew. Spam that boop emote. And with that, I think maybe this is a good point to say for someone who wants to go deeper here, what is a good next step? I think I will kick us off by saying this lab is probably a great starting point if you want to go and take your first steps with OpenShift and try things out.

David: I like how every time you paste that link, a bunch of boops come up totally independently. It really seems like a causal relationship.

Jason: (Laughter) So where else should one go if they are interested? We need to go deeper.

David: No, absolutely. So this is a great lab to get started. Also, because we give you a cluster to play around with. If you want to build something on your own, you'll get this cluster for something like four hours or six hours. Try to deploy your own application on it. Dig around. See what other stuff is out there. Try to build something with service mesh or try to get your CI/CD pipeline up and running in the same way that your organization does it. If you're looking for more -- like, less self-directed but more directed learning, we actually do a ton of workshops of a similar format. We give you a little bit more of a powerful cluster, but our IBM developer Crowd Cast channel has a ton of workshops that focus on Red Hat OpenShift. So check that out. Also, Red Hat themselves have a developer education platform.

Jason: Oh, here we go. Get ready.

David: I'm getting ready.

Jason: Where did they go? What is -- so, that's embarrassing. We got the beginning of a stampede and nothing happened. What have I done? I broke it, everybody. I'm so sorry. Aw. There was supposed to be a stampede of Corgis jumping across the screen.

You can do it. Come on, little compooper.

Jason: That's a tragedy. (Laughter)

David: That's always the best way to end a Twitch session, with a tragedy.

Jason: Utter failure of the robots to bring us joy. Corgos MIA. So, Crowd Cast. Likes like there's a bunch of things coming in here. Building on Kubernetes, containers in Kubernetes, all sorts of fun stuff there.

David: Yeah, a lot of these are given by me. You'll see some duplicated stuff, but mostly that's just creating the clusters. Actually, in those sometimes you get the clusters for like 48 or 72 hours.

Jason: Ah, there you go. Always a good call if you want to get free stuff.

David: Hi, Lizzie.

Jason: And you should probably hang out with David for more than just the free stuff. Even if you don't like him very much, just get the free stuff.

David: I love that in the poster for this, it's like your face from your Twitter and my face from my Twitter, but the biggest face by far is my mom's dog, who's just like crowding out.

Jason: That's pretty on brand for this particular stream.

David: Oh, hey! It's happening!

Jason: There's the stampede! All right. I don't know what happened last time, but I'm glad it worked this time. I wasn't going to have time to go fix it. (Laughter) All right. So let me get this out of the way. I don't know why that's popped open. Thanks, Twitter UI, for being so helpful. But this is a good place to go if you want to get more information as it becomes available. Anywhere else that you want to send people?

David: Then also just check out the Red Hat developer education events. They do stuff. They're still totally separate from IBM. They want to maintain their neutrality, platform independence, all that jazz. So they have a bunch of great stuff on their site. I don't have a particular thing to point you to because there's so many of them, but a lot of other great knowledge sharing and stuff about Kubernetes and Red Hat OpenShift is actually on their site. They have free resources. They also have paid training. So if you do hit something where they ask you for $2500 to do training, just go back a few steps.

Jason: Okay. So I'm going to drop a link to developers.redhat.com as just a general purpose get in there and learn some things because I don't know where else to send you. With that, man, I think we're in good shape. What do you think, Mr. Nugent?

David: Yeah, it was great. Sorry I made fun of you so much. I do really like your hat.

Jason: Thank you. Thank you very much. I didn't even notice you were making fun of my, now I'm retroactively sad.

David: Apologies to the project maintainers and the Java programming language and just everyone on the streaming channel.

Jason: Just a general blanket apology. We're so sorry.

David: Sorry, computer science.

Jason: Sorry for all of it. All right. So that, I think, is a good stopping point. Just another shout out to our sponsors. I guess, first, to our captioner. We've had Rachel here today from White Coat Captioning. Thank you so much, Rachel. That is made possible by our sponsors, Netlify, Fauna, Hasura, and Auth0, all kicking in to make this show more accessible to more people. Every week, twice a week, we're here streaming. You can watch those captions on the home page. While you're checking out things, head over to the schedule. We have an absolute banger of a schedule coming up. We've got automating tasks with node CLIs later this week. Ahmad Awais, he does a lot in the community. Then we're getting Pachi in. She's going to team us HTML and CSS best practices for beginners. This is qualified as for beginners, but I know a lot of devs who really haven't gotten the basics of HTML and CSS because no one ever teaches it in the context of building real projects. So get in here. Learn this. It's going to be so good. We're going to learn about MongoDB Atlas, which is a way to get it on a site very quickly. We're going to play a game called Battlesnake that I'm so excited about because I have idea what this is or how it works. But we're going to learn. Streaming data model. There's so, so much. I can't even wait for all these episodes. Make sure you get over there. Check these out. Get on the list. You can add this to your Google calendar so you can always see the episodes on there happening, or you can follow on Twitch to make sure you get notified when we go live. Either way, I hope to see you on streams in the future. With that, we're going to call this thing done and cooked. We're going to send you over to watch somebody else. David, any parting words before we wrap this thing up?

David: I really hope Battlesnake doesn't eat any of the Corgis.

Jason: I didn't even consider that. This could be a safety issue.

David: I'm going to have to watch just in case.

Jason: We'll have to be careful there. Y'all, thank you so much for hanging out. David, thank you for teaching us today. Chat, thank you for hanging out. Stick around. We're going to find somebody to raid. And we will catch you next time.

David: Thanks, everybody.