 Good morning, good morning, everyone. Well, and good afternoon, good night. Today we have a kind of international show because we go in New Zealand for our special guest, Mandy Boswell. I let introduce herself in a moment because I also would like to welcome everyone to the OpenShift Coffee Break show here in Imiya's morning, usually with me, Natale Vinto, Product Marketing Manager for OpenShift and my friend Tero Ahonen. Hi, Devo Sky from Wangol, former Red Header. It's the permanent guest in here. Yeah, yeah, for former but always Red Datter in the soul. And we have also another great Red Datter this morning. Welcome Mandy, how are you? And good afternoon, good night. What time is it there? It's evening, it's nine p.m. So I'm actually on Milo instead of coffee. I hope that's okay. Kia ora everyone. So yeah, so I'm a specialist sujubilition architect down in New Zealand or Aotearoa. Yeah, five year Red Header actually, just about to have my birthday. Wow, wow. Congratulations, congratulations Mandy. So did you say something in before, what was that? I said Kia ora. So that's how you say hello and Maori, which is the native language for New Zealand. Nice. So Kia ora. I learned something new today. Yeah. Yeah, we should, if, let us know in the chat from where you are attending. I know this is a kind of the mea time zone show. Thanks Mandy for being here so late in your time zone. But today we're global. So let us know where are you attending and Kia ora everyone. Today topic, Mandy and Tehro is something that I like very much. So we were discussing with Mandy, hey yeah, we should talk about how to teach an old programmer the old cloud native tricks. And actually we say, hey, why don't we talk about it in a show in the OpenShift TV show? I know Tehro is very excited about this topic because as a DevOps, he'd like to automate everything. So I was wondering how to automate all these, let's say old or vintage stuff and convert to cloud native. I was saying that I'm old. No man, never. But it's a good point that you've been writing goals for same way, like 20 years, 22 years of Java coding. And then you see new Java releases and you see new kind of code that you don't understand anymore. And you see so many layers on top of layers and you don't understand anymore anything. So you have to learn again, things that you already know. And then like Mandy will explain later that how many different layers there are now in the programming. It's just not writing the code. There's everything else. It's scary. Constant learning. Yeah. And which we love, right? We love learning new stuff, but sometimes your brain just gets a little bit full. And I watched my son. My son is seven and he's doing coding school at the moment. He's learning scratch coding and it's a really high abstracted language with blocks that you just drag and I'm looking at it going, wow, your first experience is in this paradigm. And I was thinking, geez, I wonder what it's gonna be like for him in 50 years time when he's going, oh man, what do I do now? It's gonna be, who knows what it'll be like. But my intro to programming was basic. And in fact, I made this timeline. Is it right if I share my little timeline, Natali? Should I put that out for everyone? Yeah, but please. You said about blocks, according to blocks. Do you remember IPM created Visual Studio for Java or something like that? Yes. And they introduced dragging objects to code. Like you drag a string of objects in there. So it was kind of similar, but no one actually used that. But they tried to introduce that kind of idea. Well, you know, we often have, because I work with our middleware technology. And so Fuse is a classic example where we have people often ask about no code interfaces. And as I think, you know, we have developer shortages and developers are kind of getting older as well. And so this idea of having these drag and drop interfaces to build things is kind of, is really attractive. But it doesn't quite succeed ever because it's still those high layers of abstraction. So I was trying to help them out and scratch. All I wanted to do was convert like a string to uppercase. You can't do that. There's no blocks to do that. There's, you know, and then there's no way of getting underneath the code to actually start doing that. And then even trying to, we were gonna make a fun thing where you put your name in and then the computer says it backwards. So it'd be kind of like just a fun. But even trying to do that is the blocks to do that is like this long and really painful. There's no just one light, one little thing to go reverse string or something like that. It's quite a process. So, you know, those abstractions, those drag and drops only get you so far, but it's a good way to start. And in fact, with OpenShift, that whole GUI interface, which I personally am in love with the console of OpenShift was a way for immediate to really get around actually even the container release kind of and packaging and idea. But let me show you, I wanna show you all like, let me just share my screen. Yes, this one here, share. Hopefully you can see that. Can you see my timeline? Yes, yes, I can see that. So it starts in 1985. And I started to learn basic and I was really hooked at that point because I love logic, you know, it just fits my brain. So I'm learning, so it's basic on a, you know, a black terminal with green lighting. And then in 1989, I started learning PL-1. So I was actually a sysadmin on a mainframe, didn't have to load cards, but I just passed that. So I was still doing tapes and dot matrix printouts overnight and stuff like that. But I'm doing PL-1 in assembler. And then I get my first real job as a COBOL in 1990. So my kind of, you know, I guess true foundation is this structured, imperative programming language of COBOL. And I do that for two years. Then I go for my OEM, do data entry and a bunch of stuff. In 1995, I started doing web design. So suddenly kind of go into this HTML 1.1, which is kind of crazy now, but JavaScript and working with a browser called Netscape. And I also retrained at that point C plus programming because I was told I needed to do that if I wanted to continue programming. So then I moved in in 96. I got a programming job as a C plus programmer, but I ended up doing data warehousing and Java development. And I never did any C programming at all. What's interesting here is that first Java development I did was with one of those drag and drop IDEs for Java. So it was like an enterprise application server, but it used drag and drop functions for Java. And so that's how I kind of first learned. And I actually learned object orientated here, but the only way I learned it was I did rational rows, UML modeling class. And that's where I suddenly just kind of got object orientated programming, which is kind of, I took a bit to really sink in. Cause my whole, you think, you know, this is like what 10 years plus of procedural kind of language, functional programming, functional procedural programming. And then I moved into doing web and mobile programming, three-tiered architectures, little bit of Java EE, but I always call myself like a Java hat. Cause, you know, people would say to me, oh, what language do you code in? I go, oh, what do you want me to code in? Like it didn't matter cause logic's logic, right? You just learn syntax. But at this point as well, I'm now a consulting architect. So I'm moving away from being hands-on. So I'm kind of, I still know what I'm supposed to do, but I'm not as hands-on anymore. So a lot of it's, you know, theoretical. And then by the next 16 years, I stay in the same organization. And at the end of that, I'm doing Perl and PHP development, which is still very scripted kind of languages. And as I said, I kind of think of myself as a bit of a Java hack and doing GUI customization. And there's all these kind of frameworks that come up, but they kind of are passing me by because I'm where I'm kind of working. And then I move and then 2016, I joined Red Hat. And so suddenly I've gone from, you know, into Kubernetes and middleware and clouds and there's more frameworks and microservices and all this stuff. So then the interesting thing I like about this kind of career that I had as well is that if you look at this, it kind of, you can really see the kind of evolutions and software architecture as well. And I saw this great kind of meme around, around according to pasta. So, you know, in the nineties, we got spaghetti. And in the 2000s, we started getting into these layered monoliths or three-tiered architecture. And then we get into microservices now. And in 2020s, it's like, well, who knows what's next? I have an idea, which I'll share with you all. But I always say like, I was really proud of the pasta I made, you know? Like quite often people go monoliths, ooh, they're evil and stuff. But man, I'm really proud of all the monoliths I made. And, you know, the pasta, I stacked that. Each individual piece of pasta is stacked by me, you know? And I handcrafted that sauce. And I was really proud of the skill it required to do all those things. And now kind of everyone's like, oh, no, that's not the way to do it anymore. So, you know, for me- What did you say that you are proud of your pasta? I'm also proud of your pasta in general. Yeah, and if you think about 1990s and copy pasting, it was way harder. You didn't have stack overflow sites. You didn't have that many corners to hitting the same problem. Now you just Google and you can basically code with command C, command V. Everything is in the Google. Yeah, that's one, I used, you know, when I would have to learn another language, I'd just go get a book, right? So, you know, you learn something, I'd just go get a book to teach myself. Because now it's just everything's on Google. It's amazing how easy and stack overflow is just a lifesaver. And when you find a problem that you are the first one to hit, then you are like, what can I do? Because I don't know what is happening underneath the code. So, I don't know how to figure this out. It's so hard. I saw that you had a struts, which was like mind-blowing at the time. With struts, you still knew what was underneath. You hacked the abstract requests of six. But now with Quargo's rest, you have no clue if something is wrong. You cannot go down there and check what is wrong. So, you are kind of, you don't, you can do anything. You just have to wait for the fix. Yeah, and that's the bit on the other side is, even though, like I understand it, but these kind of the layers above, like you can't, like you said, it's like I used to be able to, in that spaghetti, and even my lasagna, like I can look in all the layers and I can get underneath them and I can see everything or just stop sharing. You know, I can see all those pieces, but now it's like, I don't even know where some of those things are. Like if I was doing web development, I would just, you know, right click and view source. And, but now it's not even there. Like, where is this thing that it's doing? It's not actually on the source anymore. It's some magic thing that just is appearing. And it's really hard to then try and teach yourself because I would learn by testing something out and then look underneath, you know, look in logs or look on, you know, do view source and find out what things said, but that's not there anymore. And it's really hard to kind of work out, you know, what's happening? And I seriously, I really don't get these annotations and in Quarkus and other Java languages now. It's really- Oh wow, that's a, I know there's said be in the chat there was a fox in the chat, that's a statement. You don't like the annotation. Why don't you like the annotation? It's because you like to express this dependency in another way or what? It's because I don't know where to find out what it means. So I think, yeah. I think in some ways it's how you learn the syntax. Like I said before, I used to just go and get a book to learn something. And then we moved to Googling things or viewing source or looking in logs. But these annotations, I don't, yeah, I don't even know where to go. Like there's not even a library that I can just read that's part of the package that I've got, if that makes sense. It's, where is it? So I can go and Google it obviously, but I want to actually even look at the lines of codes that I can understand what it's going to do. Does that make sense? Right. There is a different, but there is a difference in annotations. Let's, if we compare like, we all know web.dot.xml. And then they introduced an annotation to annotate the template with the exact same attributes in the annotation that match the web.dot.xml. You kind of understood what was happening. It was easier, less controversial at.xml. But let's compare, do you have an annotation like method so that you get metering from one single rest call from Quarkus? You have no clue what kind of code actually does that, what is happening in there? So that is kind of, I think that, but Mandi like tried to explain that that's the magic. So there is, it might be slow code, bad code, a lot of code, you just annotate and you trust that it works. And it's good when you know, you know, this idea of trusting it's one thing, but even just trying to learn it, you know, and get how am I gonna use it and what's actually happening. Like, if you have to debug something and you're trying to understand what's happening inside of it, it's quite a different, I guess the mindset, you know, is a little bit different too, is I would be used to actually just being able to read everything and go in and look at all the layers. And I can see where all the layers are, but now it's like a whole different paradigm for me. It's a big leap, you know. Interestingly, my leap to containers, when I was doing Perl programming, I was making these, I was doing a mass email migration. So we're talking about seven million email accounts that had to be migrated from one provider Yahoo actually off to back home to my company's email platform. And so I did all these Perl scripts in order to scale them, we had to put more virtual machines. So we had to copy the Perl code onto more machines and then each time we put the code into production, any libraries that we'd use, of course had to be installed on the virtual machine and often they wouldn't be so you'd have that doesn't work in production, you know, works on my machine. So we solved this problem by packaging it in a fancy zip file. And we put all the libraries inside this fancy zip file and then we would ship that. And if we needed to scale, we'd just add another virtual machine and copy the zip file. And so when I came to Red Hat and I discovered OpenShift and this container things and images, I was like, ah, that's just my zip file. So it was like brilliant. It was a really easy thing for me to anchor. You know, it's actually a cheap file. It actually is a cheap file. It's a tarbo file, but it's a... Basically, yeah. Compressed file. Compressed file. Managed in a format, which is universal. But yeah, I think it was the same concept with no virtual machine. Probably this is the biggest advantage. So no virtual machine overhead. Or right now you could also have a virtual machine as we know in the container, Q-Virt if you like to also for some use cases, but definitely, definitely the port, probably the portability of the software is the big plus. If you think about from zip and virtual machine and then container image, I think it's a very big improvement. Exactly. And so that was an easy transition for me, right? I could anchor that quite well on something that I knew. And everything's been fine for, and in fact, my first projects on OpenShift were a PHP program. So I could take PHP code and get... Oh, that was the other thing, get. Oh my goodness. I'd come from a company where we'd be using things like Subversion or it's file.nextversion or newest. Your version control was just stored on your local machine and iterate it with .nextfile kind of or the date. I'd create fancy ways of version control. So it's a PHP app, which was just on GitHub. And it was great because it was code I understood and it was a packaging system, I understand. And so for the last kind of five years, everything's been okay. And even Jenkins and Ansible, that's all kind of scripting that is very much something quite comfortable for me because I wrote to release things with these fancy zip files. I'd have scripts to automate the install of them and the configuration of them. So it was all very, very normal. But now we have, so I'm working in an OpenShift platform. It's a development space. I'm using the GUI to put my images there. And now they've got to get to a production server though. And I've got to use this tecton or I've got to turn the configuration that I've coded in a GUI into YAML files and into essentially kind of really low level machine code almost to push it to production. And it's kind of, it goes out away from again, this idea. So I'm using this kind of GUI learning to piece things together. And now I've got to like make this leap across and to get ops and take all the stuff I'm doing with drag and drop into actual lines of code underneath. And that I'm finding, that's the point now that I'm finding is really quite challenging for me to work out how I get there. Cause there's nothing that I can't right click, make a GitOps pipeline or something like that to just automatically happen for me. I've got to try and work out how to do this all in code or something. And it's quite, and it's a leap but also it's quite manual. So we've done all these things to kind of automate stuff and bring these layers of abstractions so that we're missing out on human error and stuff but now we're going back to almost having to write scripted commands to operate. Which- We are packing copy pasting. Yeah, exactly. Yeah. When you boost a project with YAML files, you just copy paste that to a new project. And we are packing the spaghetti copy paste. It's just the different entities that we copy paste. Oh, by the way, it's a stack overflow. I think they made a keyboard with a control C, control V and another button that you click and open a stack overflow. Just talking about copy paste, spaghetti code. It's always kind of, you move the bottlenecks, right? You've moved the, it's like there's all, the bottleneck is always there, just moving to another place. And now it's, you know, it's now moved to this kind of release process, I think, into production. I know, Tere, how do you help me get there? I always said when I visited customers, when I worked in the pre-sales trade-out, I said that how do you move application from dev to production? OC get minus all, save them for file, and then OC create minus as. That's basically it. But that is a cap. It's not yet, like there is no bridge for that. You have awesome tools. Let's say for quadros. You have awesome tools to bootstrap YAML files. Do everything. And then you can deploy it to open, if it's Maven scripts, but you don't deploy that to production with Maven. You will have to do something. When you are finished, you add those YAML files to your source code, you put them to a KAS folder in your source code, you create a KITOPS application, or you can see the application, and then you have to kind of have two flows. How do you like, how's the process when you want to increase replica number? What's the process when you want to make a new release? Because you might have a different approvals. So it's, we are not yet there. It's us. We are still learning. And also, there is a, let's say if you go to the, like the GUI way of managing the Kubernetes entities, you create a secret. You use the GUI, you create name, key, value, so on and so forth. That's easy. You have to change the secret. You go there, you change the secret. But when you go to production, you have to seal, let's say you use sealed secret, so that you can put the secrets in the Git repo. You have to modify the secret. You first take the secret out, then you seal the secret, then you store the secret to Git, and then you use Argo CD to sync the secret. So even that it's automation, and it is like awesome, nice flow, but it's way more complex. So how you try to sell the idea that it takes five seconds to change it, or it takes five minutes to do everything with the GitOps way and sealing secrets and encrypting and everything. So it's hard to sell it because everything you sell now is need to be more effective, faster, better quality. And this is actually slower. Okay, it's more secure, but yeah. Yeah. And I also think that one of the things about the GUI is that it means that the person who's coded the functions that you're doing on the GUI has an understanding of what happens, has to happen underneath, right? And it's sort of a way of automating it and making it repeatable and making it safe, right? So you put in the value in this form input and it saves in the right place in the right way, et cetera. And then we go to this thing where we have to put that into YAML file OC commands or something that when we're now a GitOps or a DevOps engineer or something has to now really understand that what's happening underneath. And so it'd be quite good to be able to code from this, I mean, when I talk to customers with OpenShift and I'm surprised at how many times developers actually don't have access to OpenShift clusters. So they build, they actually just code normally and then they push, create an image like with a Docker file or something and then that gets pushed onto OpenShift they might never see it. And I might put the amazement for developers being able to see their apps running as containers on the platform and easily look at their logs and troubleshoot and see scale and all of those things you want your developers to be able to do that. And it's almost like, and for maintaining the cluster like I understand the point of GitOps in that you give the same advantages to the operational process or configuration of a cluster that you have with releases and source control and things like that for applications now I understand that, but it's almost like it would be good rather than having to start from the manual file that it starts, you could go into the GUI and you make a change and it sinks to the Git repo. You know what I mean? So it's always kind of being it's not like I have to go to the Git and then sink it to my cluster I can make the change on the cluster and then it kind of sinks. I don't know, that would be, that's how I'd like to work it because then I trust that what the GUI or even the OC commands or anything like that they already know what they're doing. And it's not me suddenly having to control it under the hood, it's far too complex. Yeah, and in addition to that you have always the group of developers that don't care about containers or components and you still have to provide them tools to actually do that they push code and it is deployed. And they can verify that it's deployed even that they don't know that it's a container or it's Kubernetes. So you have to kind of serve the bold words those who like to create them fast and those who hate them. And yeah, go on. I was gonna say a funny thing about YAML files like I, you know, the pearl versus Python debate, right? Now my pearls always tidy our minds always lined up and stuff like that. I don't need punctuation to make mine, you know I don't need to be forced to indent in order to make my scripts nice. So YAML I find quite frustrating as well because it's like, you know the structure of it's so mission critical and where things are placed inside the files. So it's almost like we've kind of gone backwards a bit as well to, and a previous time where you have this less abstraction because you have to put it in a certain way and there's gonna be so many spaces and all this. And you know, that for me was a little bit it's like, haven't we moved on from that? Can't we just, should they just know? I think that the HEP2 and the XML entity pins that those were the golden times maybe we should take the XML back. Yeah, maybe. Yeah, at least it can be validated. Well, that's interesting, Mandib because I also used to be a pearl monger. So I know you're feeling moving from pearl to Python and you're all those YAML stuff. But probably you, in this way you are forced to indent the code so it's more readable or maintainable. I don't know. Personally, I like pearl, still love pearl but probably this YAML really enforces you to be ordered. And yeah, if you miss one space, it's... You can still use JSON, could be the support JSON also. Yeah, if you really like to, I think it's better to use YAML but if you really like to have a quote and stuff like that and you can use JSON, that could be an option. You know, pros and cons. YAML, one space, you're lost, indentation, tabs, whatever but then you are forced to be readable. I don't know, what do you think? I find it a little bit less readable because probably, well, it's weird and I would say because it's so long and because you've got to, because you're the paragraphs that you're in, the indentation about... So what you come underneath of that makes sense. You can sometimes have to go up and up and up and there's how many versions of the same thing like specs there multiple times or there's different paragraphs with the same name. So it can be hard to find the right place to put your thing, which is weird I say that because if you look at something like COBOL and PL1 and things which are very structured and you have like a head and a main and functions all in separate locations and they're also one big long file and I talk about the stack of pasta and being really proud of understanding that. I guess in some ways these big YAML files are kind of the same like there are massive lines of structured spaghetti, I don't know, embedded little pockets of like spaghetti inside of the spaghetti. So it's kind of strange, but I mean, in COBOL you can spend hours looking for a full stop that was missing, which is the same thing as a space but you maybe had some tools to help you find stuff whereas YAML, I mean, we've just got YAML linters now but as we kind of move forward we're missing some of the old tools that we had to help us with some of the older languages and stuff, maybe those are some things that need to come back for each of these individual things to help us debug but it's good example about you mentioned the spec template spec like deployment, you have a spec and then you have a template for the container and the container spec and a good example is that of course you can have in the pipeline that you validate you do client side validation of the YAML that does the cluster actually accept the YAML file but it can be valid but it has wrong content. Good example is if you try to use annotation to inject the Istio proxy, Cerescent proxy you have to, if you put the annotation to the under the first spec, it doesn't work you have to put it to second spec or other way around but you don't see an error, it just doesn't work. So that's the kind of idea that it's valid it works fine but it just doesn't do what it's supposed to do. So this is kind of the problem that there might be a YAML file and at the end of the day, those YAML files are part of the code. They need to be tested, they need to be verified and reviewed so that they don't do anything bad. So it is, we need to start reading them like source code. And I think we need to get to a point where some of this becomes almost defaults that it happens first almost like these methods for debugging or packaging or abstracting or whatever kind of happen with the technology that comes out. And the reason why I say that is because as we get more complex and as we go into things like edge architectures, we start to get to the point where we're already saying that we have developers who are people like me who need a little bit more drag and drop help or a little bit more stuff and we're gonna get more of that. So as we start deploying applications out on the edge, the provider edge, device edge, et cetera the people that are actually running those are gonna even have less desire to understand YAML files or release processes than say someone like myself. Yeah, that's interesting point, Mandi. And we have also some interaction with each other and as a YAML supposed to be closer to us in terms of human readability, which I think is true. And I would like to encourage everyone doing your questions so we will try to answer in the stream. So please feel free to ask questions. What do you think about this YAML? What do you think about the, if you like more YAML or JSON, let us know in the chat because I think it's a cool interesting discussion. So in general, Tero and Mandi, what do you use for your OpenSheet Kubernetes? YAML, JSON, Qtl, OC, web console, what do you use? Web console for me first. Yay. Yeah, I love it. And I have it up. I think you just asked me if we could try there's a COBOL Docker thing, which I've never tried, but I can try if you want. Well, you know, Tero teach us always live demos. So we're just following his path. But before going there, Tero, what do you use? Web console, YAML or CLI? The web console is part of it, but it is YAML and GitOps now because it has to be a way of just, you have to treat the YAML as code. So the web console is out of the question when you modify something. You can, it's good for, let's say, testing when you try to push up something. But when you move forward from sandbox, it is YAML and version control always. There is no other way to do it, unlike with quality and with auditability. Yeah, that's a good point. Moreover, in the GitOps, let's say, paradigm or methodology. So it looks we are some live demos from Mandi. Of course, she didn't try ever this stuff. No, I never tried it. She's gonna try it like, and you know what? I really like your stickers, Mandi. You have more stickers than Tero, for sure. More than me. Your computer, your laptop is very nice. If you look. Oh, yes, my laptop. My, yeah. And, yeah. And also, I had to go underneath and inside as well. There's some stickers. But you are missing really relevant sticker that I have. Which one do you other? It's always DNS. It's very, very relevant this week. This day is really, really relevant. Can you do another one with BGP? So now we have a new complex. And yeah, I have my new sticker on my like, this is my new project as well. It's called Octopods. Octopods, nice. Octopods, yeah. So I just had them made up. Do you have any links so we can share in chat? You know what? There is, the Git repo is being built. So I can share it, but it's being built. So you won't find anything there yet. No, no, we will share next time, no problem. We can share next time, yeah. It's an edge project. It's really quite exciting. So here, shall I share my screen again? Yeah, please. Okay, let's try this. Okay. Now, you told me I need to make the screen bigger. Yes, please. And this is live demo, but you can also try it live if you like to. If you go into chat, there's the link to use OpenShift Developer Sandbox. This is a free OpenShift account that you can use to start coding for free and OpenShift 30 days renewable for free. If you'd like to follow the demo, the live demo also together with us, please take your Developer Sandbox account and you will have an OpenShift cluster like the one Mandi now is using. And she's also using a very nice feature that will come in the Developer Sandbox in a very few next days. This is the web terminal. So you don't need to install anything like in your workstation. There's a web cli where there's OC or Qubectl. So this is very nice. So what we are doing now, Mandi. I'm gonna, I was seeing you, I love the, I wanted to show this because this is one of two things that I just love on the new features in 4.8, this and search. So I was seeing you project and what should I call it, Blue Ocean? Or should I call it Cobol? Yeah. Cobol, how about Cobol Blue? Just one. There we go. So now, let me find my project Cobol Blue. Here we go. I didn't realize that Cobol is a form of blue. So it's kind of cool. Okay, so what should I do? Start building, I'm gonna add and we're gonna add this repo, right? So this is a Cobol app. This is an IBM project, right? And Cobol, they're basically containerizing Cobol, yeah? Yeah, I was looking for some Cobol example with Docker file that we can use for these live demos. So yeah, that's an example. Just found, let's see if that works and let's see converted to cloud native. So what do you recognize to do? Should I just like try adding the Docker file? So here's a Docker file. I like the sound of that. Plus native Cobol. Cloud native Cobol, let's see if you can increase a little bit your screen, your phone, sorry. So it's more visible. I was thinking we can just, you do like from the web console, the Ociniu app or just from web console, the app, no? You can point to a repo with the Docker file. There's the section from Docker. This one, and we can try it. It's running as root, it doesn't work. Let's see, it's all live, it's all live. We don't know, we don't know. People are lazy, people are lazy. Okay, so I'll go raw and then take that, yes? I think the search to image is gonna point just to the git repo. So you can copy the git repo of this and it's gonna do the build. So in this way, probably we could simulate our, let's say, Cobol programmer or let's say vintage programmer can start doing the cloud native. So deployment, look, I could even create my own pipeline automatically as well. And let's go, let's push create, see what happens. Let's see what happens. We don't know, it's all new for us, for me. Oh, look, we have an alert already. This is, yeah, this is the, I think this is a- The normal one. As I'll say, hey, we're trying to build in the wild. There's no pod running, but I think it's a little bit, we should work on it. Yeah, so here's my build config. Here's my, if I go to admin and I go to workloads and pods, I should see my build. Here we go. Yeah, that's just the, so this is the build. It's running. So let's go in and look at the logs. Wow. It's got that Ubuntu word in there. It's doing something. It's doing stuff. It's doing stuff. At the end, from the, I think from the topology view, we can also see what is going on. What I like from web console, I don't know, Mandy, what do you think about the topology view? It's really neat because you can see immediate visualization. What is happening under the hood? I also really love the fact that I can toggle between the two as well. Right. So the build is running. So it is like a monolith probably. So it might take a little bit. And look at the code. I will share also in the chat for people who would like to test in their developer sandbox. Well, it's just this hello world, right? Hello world and sorry. Yeah, it's an hello world in Cobble. Hello app platform. This is Cobble. I like what you've done with the place. That is the string that we should see at the end of this build. But as a programmer with no cloud-native knowledge, no Kubernetes knowledge, no knowledge at all of the new tool, you can create a container from a Git repo and you can have your app running. And also it could be exposed as a URL. I think this is a nice thing. Look at that. It's there. I would just make it bigger. That's it. Let's see if that works. It does. Wow. Can you increase a little bit the phone? Yeah, you can see it, eh? Fantastic. This is awesome. We did a cloud-native Cobble demo. I'm really excited for that. Fantastic. That was pretty amazing, actually. So do you think, Amanda, this could be the first step for, let's say, all programmer going into cloud-native or we need more methodology or more steps? No, I think, look, I'll also, so this is Cobble. I could put PHP in here. I could do Perl stuff in here. And this is actually the way that I learned to make container images. I did just that. I think that there's probably some work on the actual, you know, you might need to look at the program, but I think what's cool about this is that, because we often talk about OpenShift as a way to run microservices, monoliths, you know, many, many services, many microservices, nano services, many services, monoliths. And so this is kind of a way that you could just creep, you could just wrap your Cobble in a container, cuddle it, you know, cuddle it in a little container blanket and have it running. And you can get the advantage of containerization without having to break down the spaghetti. You know, it's like I'm putting my pasta inside of a little lunchbox and shipping it around, you know, it's pretty cool. So I think it's a great way, one, to be able to understand that container world, but it also means I don't have to get into the spaghetti and try and break it up and turn it into ravioli or anything, you know, because I'm never probably going to be able to rebuild that spaghetti and make ravioli out of it, right? You can't like backwards reverse engineer your spaghetti and turn it into ravioli. And good thing is that now that the food is in the box, now you can use food or our vault to deliver it. So you have same way of monitoring, like is there a container, it starts, are the containers running out of this space, are they running out of CPU memory? And it doesn't matter, is it couple of parallel in Java or C, so you have the same tools, you just have to define how you measure that your application is running as it should. What are the SLOs? And then you just run it and then it doesn't matter what is the workload, what's in the container, because you work with containers, not with binaries that are written with language X or Y. And that abstracts the, let's say, from the SRE team point of view, it makes it way easier to run application in production. Exactly. And I thought I would do, this is the first app that I ever did on OpenShift. I thought I would throw that up while we were talking as well, which is the cat of the day one, because the other thing is it taught me about environment variables and that concept of build variables, environment variables, deployment variables, and how they change through the process going from dev to production. So for me, look, I love the GUI. I've said that quite a few times. I'm the GUI girl. And the thing is this is a great way to learn, being able to do it from within the GUI as well. But I really think that there is still this missing link that we should be able to have a tighter connection and not have to go backwards into YAML files and stuff. I should be able to, you know, even that, you know, OC get all and then there's a tool for tidying them, right? And then, you know, something we need, there's a missing link here that, you know, it'll happen, I'm sure. I think I may have already put in a feature request on the console, get repo for such a thing. That's interesting, Mandi, thanks for saying that because if you see, this is all open source also. If you like the, also, if you like the open shift, if you like, if you see that something is missing, if you like to contribute or suggest something, you can do like Mandi did. So going into the repo and open an issue of GitHub and add a feature request in the spirit of open source, we can improve also the platform and all the tools inside the platform, which are all open source, of course. Yeah, exactly. So yeah, and the other, you know, when we get, we have new technology come out. So for example, I put in, I haven't put in the right click feature so I won't be able to do it as easily as I'd like, but you know, one of the things I put on this cluster was serverless and when we have this new innovation and stuff that happens, for me, when it comes into open shift and it comes into the GUI, I can easily learn it. So that COBOL app, the Blue Ocean one that we just did, I could turn that into something serverless as well. Are you saying you could do serverless COBOL? Yeah. Wow. That's a dream. I don't know. And I don't know whether we have time, but I could try. Can you, Tera, can you remember the configurate? Oh, it's not this one, is it? It's a custom resource definition for setting the take preview features, feature gate. Yeah, feature gate. Great. So if I go on here, like this is, I know I have to go into YAML here and edit YAML, but I can do that in the console as well, which is kind of good. Oh, I know what I need to do. Instances, cluster. Do you remember what it is though? Someone Google it for me quick. Well, there isn't like a trap in here. There are some default feature gates that are open. And if you just put single feature gate in here, it will actually overwrite those default ones with the single one that you put in here. Yeah. So you have to basically get the Qplit configuration for the feature gates that are active and add also those. I did that in one POC and I broke the environment. So learning by doing. I've done, so I've got a, it's one in here to turn on the take preview ones. It's a feature gate. Yeah, here we go. I just kind of remember what the code is. 4.8, what am I, 4.8? So live, not prepared. We're just doing it on the fly, this one here. So I just have to put that one into here. What do I have to say though? Enabled, do I have to put true or something? There mustn't be a sample. Yeah. Yeah, that's what I need to put. So if I do this into here, and go save, and then I think I might need to reload. Let's just make sure it's there. Yeah, it's there. Let's just refresh this. Fingers crossed. What this should give me. Another live, that was. Yeah. So what this should give me, if I go back to developer preview, and let me do it on the other project first, just cause it's a little smaller thing. And if I go here, and actions, no, not there, there, and actions, I'm looking for the make serverless. Is it there? It's not there. Hope I don't have to log out and log back in again. Probably it's because the application is refreshing. Probably we can try with an application with a lightness probe, okay. Readiness probe, okay. Okay. Because deployment was ongoing. Oh, right, okay. Yeah, let's see now if there's anything. No, it's not there, but add. Yeah, probably refresh thing. Yeah. So but everyone might just have to trust me as we're running. So what I could do in this case is that workloads pods. So it's there. Let me try the other one. You have to check that the console pod has to be redeployed. Okay, right, that's probably, so that hasn't happened yet, okay. So, but what's gonna happen is this, I'm gonna get an option here to say make serverless. And I just say save, and then that app will now become a serverless app. And so my blue ocean app could become serverless. Just like that. Impressive. So serverless with all the benefits, like scaling to zero when not invoked, auto-scaling when massive traffic going on, like you say the edge use case, lots of traffic going on. So you can have your cobble backend kind of monolith that you're bringing to cloud native and they can coexist with the modern microservices or whatever. Exactly. So, and I wanted to, just as we were kind of closing up, I wanted to actually show you my, one of my last slides here. So what do I think is 2020 pasta? This is my thingy into the future. So we went from like spaghetti, monolith, microservices, and now it's this on-demand serverless functions edge and printed pasta. This is a real thing. You can use your 3D printer and you put like filament in it that is insect-based, basically insect protein and you can print pasta. That's amazing. I can imagine what Italians will say about that. Well, it depends on the way you cook it. But I love it. So you can, with this analogy, you can build your own pasta, build your own shape, your own software architecture at convenience with the cobble example we did or with other kind of stuff that need to co-exist. Well, that is cool. And Sebi is saying in the chat, my next K-native serverless demo, I deploy a cobble revision, a Quarkus revision to do some traffic splitting. So, Mandi, you inspired our evangelist to do demos on cobble and serverless. That's huge. And think about the opensives that runs the K-native is actually running on IP and power so that it can still, and then maybe there will be cube mainframes in the future so that you can run mainframes on Kubernetes that run on mainframes. That would be awesome. That would be quite wild, wouldn't it, to have that, I love that idea. Wow. I love it. Yeah, yeah. So, Mandi, we have seen an architectural evolution in software. We have seen how traditional programmer, traditional line can be bring into a, say, cloud-native at ease with a web console. Any final consideration closing this fantastic episode that really loved the live demos and discussion? I think that, I think if, you know, for people to have a little bit of empathy, I guess, for us old programmers and kind of that mindset of where we come from because we're often, we're the ones who are making the decisions around what gets bought. And so it's, we might not understand necessarily what exactly is happening and why this stuff is so important now and why is it so, you know, because everything used to work, it used to still work, right? So why do I need to buy this new thing or why do I need to go in this new direction? So hopefully, you know, that could maybe even just help with a little bit of empathy towards how we have to kind of wrap our heads around the new changes and the, you know, the new world of the magic underneath the covers that happens now. And then I guess, you know, it's really exciting. I mean, it's kind of cool. I say, I kind of make, you know, light of being an old programmer, but I'm really, I'm so happy that I've still hands on, you know, and I still get to do this stuff because it's, the technology is changing like daily. Every moment there's a new open source project, you know, there's a new thing around the corner. It used to take years for anything to change and now it's changing just constantly. And that's, it's so exciting, I think. But you don't have to use all of those. If you have, if you're happy, your stack is working, you don't have to change, it's just to be cloud native. Yeah. And you know what? I still, you know, copy's paste is still awesome and no bad plus plus is still a great editor. Indeed. Well, yeah, you don't know. Oh, it's a VI. VI, yeah. VI is the old way or VI-M. Either, take your flavor with the M or without. That's cool. So, yeah, Mandy, I agree with you. There's lots of technology. Probably tell them we don't have to use all, but we have to choose which to use. Something could be convenient. So it's hard to keep the face with all this technology push that we have. If we have some help or even some methodology that could be really helpful, I guess. Yeah, yeah. I mean, I say just like pick the vendor and just go with them. Obviously, I'm sitting in the red hat camp. So, you know, I'd say just go with red hat. Just take their lead, right? Cause making those choices yourself is difficult, right? Just go with someone who's like right there and in the forefront and that's their job. But of course, you know, I have my fedora and, you know, I'm an open shift. And your stickers. And my stickers, you know. If you come to me to my office and with those stickers, I would trust you 100%. So I said, she know what to say. She know the fact. Somebody said the ones that stickers for developers, they are like present tattoos. I agree. So, folks, to wrap up. So thanks, Mandi, for joining us today at the OpenShift Coffee Break. It's a MIA show that we did in Napa. I'm really excited about it. So thanks for joining a little bit late over there. I think it's nine 10-ish PM. So thanks very much for joining us. We would love to have you next time. Probably we could also build a series of, you know, cloud native tricks for programmers. That would be also interesting. But I really liked the show today. So I would like to thank you for joining us. Thanks, Tero, for being present and joining us as well. Quick reminder of what we have today in the calendar. You see in the chat, don't miss the level up and Haskell admin show. You have the OpenShift TV streaming calendar in the chat. And the OpenShift TV Coffee Break show will come back in two weeks, Tero. Wednesday, October the 20th. We will come back with another topic, another show. But for today, thanks everyone for having joined. I really love this live demo, Mandi. And Mandi, how to say goodbye or ciao over there. So you can say Namihi, which means thank you very much. So Namihi Mandi for joining us. Thank you. Thank you, everyone, attending Austin, New Zealand. And see you soon. We will lie really to have you back here at OpenShift TV. Bye. Bye.