Posts

This is the second post in the series where I translate AI into the language of infrastructure engineers. In the first post, I showed that AI is just another workload and that your infra skills already prepare you more than you think. Now for the bottleneck everyone ignores: storage. It is the hidden villain behind performance problems in almost every AI project I’ve seen. tl;dr Storage is usually the first bottleneck in AI training. Keep durable data in Blob or Data Lake, but cache the active working set on local NVMe. Check GPU, disk, and network metrics together before blaming the model or the GPUs. The midnight call You did everything right. The ML team asked for a GPU cluster and you delivered: eight NVIDIA A100s across two nodes, high-bandwidth networking, CUDA drivers up to date. Clean deployment. The team kicked off their first training job Friday at 6 PM and you went home feeling good. ...

This is the first post in a series where I’ll translate the world of AI into the language that infrastructure engineers already speak. If you’re the kind of professional who configures VMs, builds CI/CD pipelines, and gets woken up at 2 AM when Nagios fires, this content is for you. The series is based on my open-source book AI for Infrastructure Professionals, adapted and expanded here on the blog. tl;dr AI is another workload with different performance, cost, and data patterns. Infrastructure engineers already own the hard parts: compute, networking, security, observability, and cost control. If you can run production infrastructure well, you already have the foundation to support AI systems. The Monday morning message It’s 8:47 AM on a Monday. You’re halfway through your coffee, reviewing a Terraform plan for a network redesign, when a Slack message lights up your screen. It’s from the data science team lead: ...

Had a 1:1 last week. Nothing unusual, just a regular conversation, catching up on things. But there was one moment that stayed with me after the call ended. At some point he said he usually thinks about people in four different ways. Not as an official framework or anything like that, just how he personally sees it. And I don’t know, the way he explained it felt simple, but it kind of stuck. ...

Over the past year, I’ve been working closely with some of the bigger and more visible AI customers in Microsoft’s ecosystem. Large platforms. Fast-moving teams. High expectations. High stakes. On paper, that kind of visibility sounds exciting. In reality, it comes with a weight that’s hard to explain unless you’ve been there. Because being close to impact also means being close to consequence. Visibility changes everything When you work with smaller teams or early-stage projects, mistakes are usually contained. You can recover. You can explain. You can iterate. ...

…and why that’s not an accident. If you have worked with both Azure and AWS long enough, you have probably felt it. AWS feels straightforward. Azure feels… heavier. Not worse. Not broken. Just harder to reason about. The console feels denser. The mental model feels less obvious. The number of “extra” concepts feels higher. This is not a beginner problem. Senior engineers feel it too. And the most interesting part is this: that friction is not accidental. ...

For years, “cloud-first” has been treated as a badge of honor. Companies proudly announce that everything is in the cloud, architects optimize for migrations instead of outcomes, and teams equate progress with how little infrastructure they still own. But after working with dozens of real systems, across different industries and at different scales, one thing becomes clear. Cloud maturity is not about being 100% cloud. It is about knowing why each workload is where it is. ...

Throughout my career, I’ve had countless conversations about career paths with colleagues, mentees, and professionals in transition. In those talks, I often share practices that have helped me personally along the way. But this article is different. It’s transparent and honest. Although I’ve spoken about parts of my story with people close to me, this is the first time I’m sharing it so openly, including my mistakes, lessons, and reflections in a public space. ...

It’s easy, even comforting, to blend in with your badge. We introduce ourselves with our name followed by the company. We join meetings carrying that title. We post with the credibility it gives. But at the end of the day, the company is just where you are, not who you are. You are what you’ve built. What you’ve learned, and taught. You are the reputation that stands when your name shows up alone. You are the value that stays when the badge is gone. ...

This article was originally published at https://cloud.redhat.com/experts/aro/private-cluster/ A Quickstart guide to deploying a Private Azure Red Hat OpenShift cluster. Prerequisites Azure CLI Obviously you’ll need to have an Azure account to configure the CLI against. MacOS See Azure Docs for alternative install options. Install Azure CLI using homebrew brew update && brew install azure-cli Install sshuttle using homebrew brew install sshuttle Linux See Azure Docs for alternative install options. Import the Microsoft Keys sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc Add the Microsoft Yum Repository cat << EOF | sudo tee /etc/yum.repos.d/azure-cli.repo [azure-cli] name=Azure CLI baseurl=https://packages.microsoft.com/yumrepos/azure-cli enabled=1 gpgcheck=1 gpgkey=https://packages.microsoft.com/keys/microsoft.asc EOF Install Azure CLI sudo dnf install -y azure-cli sshuttle Prepare Azure Account for Azure OpenShift Log into the Azure CLI by running the following and then authorizing through your Web Browser az login Make sure you have enough Quota (change the location if you’re not using East US) az vm list-usage --location "East US" -o table See Addendum – Adding Quota to ARO account if you have less than 36 Quota left for Total Regional CPUs ...

When working with development or test environments in Azure, a common need is secure access to internal resources without exposing them directly to the internet. While VPN solutions are a robust way to achieve this, they can often be overkill for simple use cases, especially when you just want to access a few VMs or services for testing. A jump host combined with sshuttle offers a simple, VPN-like solution that can be quickly deployed and used to tunnel traffic to your Azure resources—without the overhead of setting up a full VPN. ...