 Thank you again for swapping in your lunch for my talk. We're going to talk about the developer sandbox. And so this ego slide can't really be missed in my presentations at least. It always gives me the minute to breathe and find my room on the stage and talk a little bit about me. So I'm one of the old guys, like literally, I'm in the industry since almost 18 years. I started out on the Java application server side, worked with Java versions that nobody can even find on an archived website anymore. And I wrote some books. I did work a lot with customers. I've sweat, blood, and tears implementing systems. And you're more than happy to follow me on Twitter, on Mastodon, wherever your social journey takes you. You will find me under my nickname, which is My Fear. And that is probably a story for a beer or a glass of wine or a glass of water, depending on, which I will absolutely invite all of you who are interested to, to grab me and talk to me about it. Who has not seen this slide, this picture ever before? Okay, congratulations, you are lucky. So this is the overview picture, the landscape of what supposedly we as developers are using when we're developing and working with Kubernetes. This is the famous CNCF, like Cloud Native Foundation Landscape. And it's basically categorized into various feature blocks and every feature block, if you go to that website that I did link deliberately down here in the slides in like almost unreadable text, then you can drill down into each of these blocks and you'll find company logos and products and open source projects. And for every need that you could eventually ever face on Kubernetes, you will find a solution or 20 or 100, various solutions for the same category. So this is, it turned out to be my nemesis because as an architect, I'm always responsible to like pick the right things for the right job. Hey, my life was so easy 10 years ago when I had like an application server and two or three vendors pretty much delivering the same standards. So it was comparably easy, I knew what I get. Today, if I have to build an application from scratch, I really literally all I know is it's potentially going to be Kubernetes underneath, but everything else is gonna be something that I need to solve on the way getting to my solution. So why did I put all these little texts down there? So obviously for your reference, so you can download the slides afterwards, hopefully. And it's so small because I used to call it homework. That is something that my girls hate for a living and they always push it off or write like teensy little notes during class, what they have to do at home. So, and because it's so small, I decided to call it your homework. So whatever you see down in the slides is like a comment, you can look it up afterwards, dive down into specific topics or learn more information about it. So what do we do with this, like with this landscape? Honestly, there's a ton of people who actually want to explain how this is supposed to work. And if you've written one or two applications or even more, if you're a seasoned developer, you know exactly how that guy here feels because he had to explain choices, technology choices to an audience, mostly to his team maybe or like try to defend the decision being made in one of these fancy DevOps teams today. So it's all been a congratulation and interpretation of non-functional requirements and how they could be put into software. That is a really lengthy process from time to time. And given the amount of choice that we have today as developers, as DevOps engineers, as platform engineers, as operations people, as even architects, if they still exist out there, it is a tough job, right? And this guy's probably smoking for a reason. So honestly, as a developer, this is what I really want. I just, I want to code. Like that's a famous joke that I found on Twitter and I used to have a screenshot in here that I removed for obvious reasons, but it basically tells the story of why developers want to earn so much money because all we want to do is we buy a cabin in the woods with fiber connection to like sit somewhere in a basement and write code and not be disturbed. Like this is the only reason, right? I want to be productive as a developer. I don't want to care about landscapes. I don't like necessarily want to have choice. I have my frameworks that I do understand, that I love, that I can work with. And all I want to do is put business requirements into this beautiful language of choice. And me being a Java champion, this obviously is Java with or without emojis. So you have to put up with the fact that I am deeply in love with Java and I'm taking every single fight I can with anybody talking about JavaScript. So if you're up for it, take me up for it. So there's plenty of approaches to tackle on complexity. One of the approaches is to deliver an architectural framework, something that you might have in your company or see in your customers. Some call it blueprints, some call it master architectures and it's always something very universe-like. So some people invested a lot of thoughts around how this could look like or not and the result may or may not be practical, ultimately. What I do think it really takes in terms of managing complexity is making choices. So at the root of our problems today coming down from this large landscape into something that is still manageable is managing complexity. And one way that you could look at, and this is what this session is about today, is managing complexity by embracing an opinionated view. And this is exactly what we're gonna talk about. So we're gonna talk about an opinionated developer experience with all the tools Red Hat has to offer. And if you've been sitting in one or two of the sessions earlier or if you will be sitting in the next sessions coming up in this room, you will experience one or the other tool. What I'm trying to do is give you a head start, something that you can take with you and just play with for a specific scenario. So the slide you're looking at basically pictures a developer experience view onto a Kubernetes infrastructure. So why is this developer oriented? Because it basically starts at the very top with what developer experience is about. So you see something like development in your IDE. You see Quarkus as like the JVM framework of choice. You also see Podman Desktop, that was a session before, which helps you containerize your applications and put them into pods and all the way into Kubernetes clusters. You also see something like version control because that's obviously the other thing that we also interact with on a regular basis. Developer Hub, we had a session about that which basically is like the developer portal. Red Hat has an offering in a Dev Preview which is called Red Hat Developer Hub. You can like look it up, take a look at the slides later on and give it a test drive yourself. That's all nothing I wanna talk about today. What I wanna talk about is this whole picture, like how do I as an individual developer manage to get into all of these technologies that obviously are already a smaller choice of the bigger landscape and still stay productive? Like how do I manage this complexity? This is the biggest challenge, isn't it? And to just give you an idea how this looks like, if I distribute all these various tools onto a software development lifecycle, we'll have the inner loop to the left, which basically is everything you do on your left. So that is crafting your beautiful source code in whatever language except JavaScript, containerizing everything, making sure it runs locally, trying to find some mini Kubernetes maybe to test at least a little bit of the configuration. If you're brave enough, you go all the way into some like XML configurations and do your own magic, but that's up to you. Then you'll start like local debugging cycles and do whatever is necessary to the point it works on your machine or on my machine, right? And that's the point where we all hit the big green button and push directly to, depending on how brave you are, either master branch or your feature branch, and off it goes, right? So then we'll sit there, hit refresh and see what the built magic is doing. And this is the outer loop, right? So outer loop is basically not my responsibility as a developer, it does magic and the result should be something introduction at some point or in test for the sake of or in like some kind of staging environment. But there's so much more, there's compliance, there's security and whatever. Still the right part somewhat hard to set up, like on a developer laptop, almost impossible and mine's already pretty large from like a physical footprint and size, but ultimately it's impossible, right? You need a playground, literally a sandbox and ideally that should be something that is at your disposal because honestly, you wanna know when I learn? I learn when the kids are in bed, like literally in the evening hours. So I do not learn while I'm working, which is a pity, but it just, there's no time to fit it in. At the end of the day, I wanna have a full blown ecosystem that I can play with whenever I want. So my personal sandbox and this is exactly what the developer sandbox is and the full name is fancy and not fancy. So it's the Red Hat OpenShift developer sandbox. It's like an always on environment that you can access and play around with. You have your private namespace, nobody else can access that. You can do whatever you want in that namespace. There's a couple of administrative functions that are not available from like an OpenShift feature perspective, but ultimately in that namespace, you're free to do whatever you want. It has a comfortable 14 gigabytes of RAM at your disposal and 40 gig of storage. And we just bumped that up a couple of weeks ago. So that should be more than enough to even try out a little bit more complex scenarios at that point. And the fun part is you do not have to configure it. Like literally that sandbox comes with all the buckets and all the toys. It's all pre-installed for you. So all you have to do is sign up and get your 30 days free trial. That's pretty much what you can do with it. And this is just an excerpt of what's available in the sandbox in terms of operators. We are not gonna talk a ton about these operators today. So let me at least talk about the web terminal operator, which is one of my most favorite operators in OpenShift at all. So it basically is an operator that spins up an instance where you can like use Qtl and everything you ever need in terms of Kubernetes tools without having to have it installed locally. So it like it's your terminal view into your namespace at that point. So what that basically allows you to do is take one of these fancy new flip phones, open your sandbox browser instance and just start playing and working with it while you're in the park walking the dog or something else, right? So it gives you full flexibility and all the tools that you might need are directly at your disposal. And there's even more because we also have the depth spaces operator that basically spins up an Eclipse J installation. So you can use Eclipse J as a browser based IDE directly for all your projects. You might have seen that earlier and you will see this over the turn of the day but that frees you to take with you in terms of like developing development devices, whatever small size you ever dreamt of. So no real need to carry these heavy bricks around and still be able to play. Yeah, and this is obviously demo time, right? So we'll see how that goes. And if my window breaks or not, I was actually brave enough to, let's see if we can do that. So developers, redhead.com is like the sandbox and this is literally all you need. You have a red big button over here where you can sign up, which I already did. So this process should be a little bit faster but it does not require you to put in any information at all. Like literally no credit card, no nothing. It's protected by Google capture. So as soon as everything is set up and the system believes that you're not a robot or an AI, you're more than happy to absolutely proceed. And this is what you'll be greeted with. This is your OpenShift namespace. And as you can see, I'm directly jumping into this project. It's a fancy combination of my first and my last name and I get a lot of comments about it. But yeah, let's do that offline later. And you can also see that there's no resources found. So this obviously is an empty cluster, which is perfect. The sandbox itself knows two user personas. We have the developer persona who we all are and we also have the administrator. Love them or hate them, we might need them sooner or later. So never talk bad about them. That's what I'm also not gonna do today. What I wanted to show you in the administrator view is that you have a ton of operators at your disposal and you can see the full list of already available and installed operators by just clicking here and scrolling through. Some familiar names, Camel, has ever heard about Camel and played around with it. It's more like on the Java integration side. And yeah, again, I'm a Java guy, so apologize for that. Another one is the GitOps Prima operator. It is part of the upstream Conveyor IO community. So imagine you playing around with a sandbox for 30 days setting up your beloved pet project and you're about to lose access because after 30 days, we'll just terminate your free engagement. I'm sorry for that in advance. But the GitOps Prima operator basically allows you to export everything you configured. So you can literally take your YAML with you in your teensy little bag and make sure it's being safe and secured and deployed to another cluster whenever you wanna have a chance. Okay, what else can we do? Obviously, if we have no resources, we need to start adding some. So there's a variety of options and let's talk to the UX guys at some point about what should be done first here. What I wanted to show you first is definitely the guided documentation that's available. This is always a good step for new users. So you can get a grasp about what's health checks, how can I add health charts from the repository? How can I deploy a Quarkus container image, which is my favorite JVM framework? And it's all guided. So you get your little sidebar and you get a step-by-step explanation of what you do. But if that's all already too much and if you don't wanna navigate that, you can also start from pre-existing and reticurated container images. And I do actually, I did that before. Guess what? Because I was afraid it's gonna break like in Elon's demo. But we'll see how far I get today. I wanna spin up a MySQL database just for the fun of it. And obviously, this is not supposed to be a serverless deployment. And I also wanna make sure I have a couple of deployment information in here. And because I could not learn them by heart, I still need to copy and paste. So we need our MySQL user and password to prime the image. We also need a root user and root password. And we need to quickly define a database. Let's see. Password, can you already guess what kind of application we're gonna get started with? You can, right? So let's create, oh, MySQL database. Real quick, and the topology view instantly shows you that something is happening. And obviously you can dig into this. You've seen the little blue circle that indicated that this pot scaled from zero to one. And obviously it's now up and running. All the deployments are here, perfect. You can look into all the deployment details. But let's forget about this for a while because spinning up a database is interesting but not really a developer task. So we only need that for our application, right? So what we really wanna do is bring our application source code into this, right? So let's import from Git. I think that's what we all know. So we have our nice little application sitting somewhere in Git. And in this case, it's the Spring Pet Clinic demo. And yes, everybody's excited, it's red on screen. Yes, I was scared to death, man. If I've seen that the first time. So let's switch the build strategy that's employed here. Our source to image feature, which is basically what we're doing. We're taking source code and letting the sandbox turn this into a container image. So that's kind of what's happening behind the scenes. And there's various strategies to get to that final image. You can use a dev file, which is more or less known, a full description of your project. You could use the standard Docker file, or you could use one of the predefined builder images that come with the OpenShift developer sandbox. And in this case, did I mention that I'm a Java guy? Who else is programming in Java? Love you. Shoot out to all of you. So let's take UBI 17, which is like the universal base image, which is a rel version that you are free to use. And it has an OpenJDK 17 baked in. So let's just use that. I am pretty sure that we need to tweak a couple of things here. So that's also not a serverless deployment. And we also wanna make sure that we have a little bit of a build configuration in here because this thing needs, oh, that's not gonna work. This thing needs to know where our database sits and how that profile in the application in spring is actually gonna be activated. So we'll add the MySQL URL here. Anything else we need? I don't think so. So let's create. And the deployment was created successfully in this case. And as you can witness, this is basically starting a build in the developer sandbox. So you don't really need to build your images locally. You directly work off your Git repository and the OpenShift developer sandbox takes care for the rest, literally. And this takes a while. We can actually take a look into this part if I'm not completely mistaken. This is the build. This is not where I want it to be. Anyway, let's not mess around. Downloading Maven dependencies, making sure everything's in place, the application should be up and running at some point. And when that point is reached, you can ultimately also access this here. Guess what? When I tried this earlier, this was not taking as long. But anyway, you did understand the concept behind all of what I wanted to show you. And for the sake of this presentation, this is the tutorial where you can play around and try for yourself, like the full Spring Pet Clinic demo. Just go there, take a brief, deep dive into the OpenShift developer sandbox. But if we'd only had one tutorial that would not really be helpful, right? So as a matter of fact, there's a ton more that you could do besides the guided documentation inside the sandbox. There's also a ton of tutorials available that you could just walk through. And you can also learn the basics of Kubernetes because that's not an artificial pass that you've just looked at. It is a full-blown Kubernetes system. So if you're new to that world, if you wanna get started, if you wanna learn the basics around like pots, labels, deployments, all that coming together, ultimately to form a full-blown application and its infrastructure, this is exactly where you can start. And if that isn't enough, you can also take it to the next level and think about some specific architectures on Kubernetes. Obviously, it's meant for and built for fully distributed microservice-like architectures. So taking maybe JDK 17 and Quarkus for a spin, developing a couple of microservices and having them all run, seeing how autoscaling works in Kubernetes with the topology view that I showed you earlier, all this is beautifully crafted in these tutorials and you could easily just walk through. And the best part is when the kids are in bed, you're also more than welcome to do this next to a glass of wine, which will make learning a lot easier, according to my information. OpenShift Pipelines, that is a fancy way of saying we also support Tecton as an open source build system. It's pretty Kubernetes native. So it gives you a feel how build steps are actually executed on top of Kubernetes pods. So it makes it a lot easier to scale your build infrastructure. And if you ever wondered what Tecton is and how that works, that is another great tutorial for you to actually take a look at. We did briefly talk about the application exporter, like the GitOps primer. And I have like the fancy four letters Rosa on here. OpenShift Developer Sandbox is just the entry level free offering. Whenever you're convinced and you're like, hey boss, I need this thing. And you wanna tell your boss what to buy, it's not the Developer Sandbox. Your boss needs to buy OpenShift on AWS. And the short form is Rosa. So keep that wonderful acronym in the back of your head. And whenever your boss asks you what next to buy, send them there, forget everything else. So wrapping it up a little bit faster because I'm already over time, import your code directly, use existing images, run available images of choice out of the curated catalog. Build and run your containers on a Kubernetes environment that is reasonably bigger than your local laptop and gives you a lot more features and tooling outside of the plain Kubernetes infrastructure. So it gives you like visual guidance, lets you explore all the details, gives you terminal access to the individual plots without even like going crazy on Stack Overflow. Like it's all pre-baked in here. So this is what we have today is like on the left. You can get a sneak peek of the developer experience features of the whole Red Hat ecosystem with the Developer Sandbox. You also have access to the API management and obviously also there's a data science part in it. That is Jupyter Notebook. So not really a Java kind of guy thingy, but if you ever thought about, yeah, give me a notebook. I wanna play around with it and see how that AI data science thing works. That is also something that you can do as of today with the Developer Sandbox. Next, you'll be able to try out the Developer Hub. So if you ever thought about testing out backstage on top of like this curated stack, the Red Hat Developer Hub is gonna be your next big bet. And you will see more stuff coming. And this is like as usual, no guarantees, no promises, this is no roadmap. So it's just like a sneak peek into what might be coming. This is the slide you can screenshot if you want. It takes you directly to developers.redhat.com slash sandbox. And it is really, really easy as you've seen. It's just a matter of clicks and a little bit of waiting. And you'll be at the point of your dreams where you have your own Kubernetes cluster at your disposal. And if everybody's pulling the cameras down, I will also make sure to hint you to the developer program in general where we have like 100 interactive sessions. That is something that doesn't even require the Developer Sandbox, but comes like with learning experiences being spun off for you as you start your session. It's fully guided. So there's ton of topics from everything like Jakarta E development, Node.js development and all that kind of stuff. You just pick and choose where you wanna learn more and it will be available. And yeah, blunt pitch. So during Corona, one of my friends and I decided to actually spend the time wisely and not be angry about shit. So we wrote a book which was published at O'Reilly and it's also translated in traditional Chinese which I'm personally very proud of. And you can get it. So either via this link as like a PDF downloadable edition, the GitHub repository has all the source code if you wanna play around with the examples in the book. It basically guides you from like traditional 10 year old architectures on a Java application server all the way into modern serverless deployments. So yeah, play it around whenever you like. And this is the big surprise. So we'll have print out copies like hot copies here. And if you come by tomorrow afternoon-ish 12 10 to be precise as a German, you'll be able to maybe snack a copy that gets signed by me and Natale. Natale's sitting there, Natale Wave. So yeah, we too did this. It's not gonna be this big. So it's more like this big, but you'll still enjoy it. And it has a ton of valuable information in it. What else, don't forget to register for the Reddit developers program. There's a ton more books about Potman, about security, about trusted application pipelines. Literally the basics, Unix cheat sheets, if you wanna learn more about Linux and how their commands work, and it's all free. Like free as in free beer, as in open source, as in community, we like sharing is caring. And that is exactly what you get if you register here. My standard reminder, after the tough times we've all been through, don't forget to close your internal browser tabs, please. All this stuff that's going on right now everywhere in politics, in personal lives, in wherever, is something that we need to cope with. And this is my general reminder, please take care for your health, make sure you're prioritizing yourself, and learning is part of this. So make sure you will learn a little bit and grow personally and stay healthy on that journey. Thank you all so much for being here, and I'm looking forward to talking to you.