This year I’ve totally revamped my home lab to focus on Red Hat technologies. I joined Red Hat in November of 2025 as a Solutions Architect and now its time to dust off my lab for some blogs related to my new endeavor. I’ve repurposed some old hardware, and bought a little bit more so that I can focus more on the OpenShift platform. I’m tracking those post in this series if you care to follow along. But this post focuses on the home lab running in the basement of my house. ...

This post is part of the Red Hat Platform series. If you want the full picture of what we’re building toward, start there. Well, these days it’s hard to consider myself a technologist unless there is some AI stuff on my blog. So, in this post we’ll focus on an introduction to OpenShift AI specifically on inferencing. AI has taken the world by storm for better or worse. It’s not just technologists who are buzzing about how AI is going to impact them, the whole world has an opinion on it. While the debates rage on, technologists are trying to find ways to make AI easier to manage. Many people use the SaaS based way to get access to AI models. They use an AI endpoint from Claude (Anthropic), ChatGPT (Microsoft), or Gemini (Google) and pay for each request through the allocation of tokens, and it’s simple to get started. But as your workloads consume more and more tokens, and the SaaS providers charge more and more money for those tokens, this way of leveraging AI gets very expensive very quickly. So you look to buy your own GPUs and servers and plan to host your models yourself. Now we’re met with new problems. How do I lifecycle my models and replace old models when new ones are available? How do I change model types without updating my applications for a new API spec each time? How do I match my finite GPUs to the right models, and how do I keep users from accessing models they don’t need? The challenge is daunting… unless you have OpenShift AI. ...

This post is part of the Red Hat Platform series. If you want the full picture of what we’re building toward, start there. What if we had a situation where our application didn’t run as a container for some reason. What if the Brix Pizzaria ran virtual machines instead? Will our OpenShift platform be capable of managing these as well as our containerized workloads? The short answer is yes. In this post we’ll focus on OpenShift Virtualization and how we can leverage this solution to run our VMs on our existing OpenShift cluster. ...

This post is part of the Red Hat Platform series. If you want the full picture of what we’re building toward, start there. In this post we’ll focus on OpenShift Dev Spaces. Dev Spaces I’d love to tell you that Dev Spaces is a fun new store where you try out the latest ergonomic gadgets. Standing desks with built-in treadmills, kneeling chairs, and expensive vertical mice that look like a clay sculpture would be just some of the things in these pop-up stores. Those of us tied to a desk for way too many hours a day could check out the latest in geek comfort. I hope a place like this exists somewhere, but that’s not what we’re talking about today. ...

This post is part of the Red Hat Platform series. If you want the full picture of what we’re building toward, start there. Here we’re focused on continuous deployment using OpenShift GitOps, which is Red Hat’s supported distribution of ArgoCD. GitOps This post is really about continuous deployments of our sample Brix Pizza application. In a previous post we build a CI/CD pipeline that built our container image automatically after we made changes to the source code and committed it to git. In this case we want to get our application deployed to our Kubernetes cluster. ...