According To Ali

GPUs are a critical yet expensive commodity for AI workloads. Justifying their high cost requires maximizing utilization. To keep things in focus, we are not discussing token consumption or tokeneconomics here; This is about GPU optimisation (at the infra and platform). In this post I will describe an approach to building an optimized GPU-as-a-Service using the below key components: GPU Sharing : Increases workload density and optimising GPU usage. Model As A Service (MaaS) : Standardizes and centralizes model deployment and consumption. Kueue : Controls prioritisation, duration and placements of GPU workloads. Self serve : Enables different roles to self serve to utilise GPUs available within the organisation for usecases. GPU Sharing + MaaS + Kueue + Self-Serve = GPU-as-a-Service Solution overview: The big picture: The above goal translates to below high level overview: Demonstration of GPU-as-a-Service in action: Let's dive into the bits now. GPU Sharing: GPUs were des...

AI agents are rapidly transforming software engineering—introducing new architectural patterns, terminology, and operational workflows designed to automate repetitive tasks. One of the most compelling emerging use cases is Agents for Ops . In this post, I share my journey building a Kubernetes namespace monitoring agent. Think of it as a digital intern performing Level 1 SRE tasks: it monitors K8s workloads and automatically remediates failures strictly within the guardrails of a provided knowledge base—nothing more, nothing less. I built 2 agents: 1 for K8s namespaces per cluster and 1 for VMs fleet; but to keep this post short I will focus on the k8s-namespace-monitoring-agent.   The Demo: OpenClaw: Kagenti: The usecase: My usecase is simple: The Environment: Two workloads (a web server and a database-backed microservice) running on OpenShift, with a "Chaos Monkey" injecting random failures to simulate real life application failures. The Knowledge Base: A mapping of known...

Really!! Are there could native way to deploy, LCM VMs and add Self Serve on top ???? In this post I will describe an art of the possibility using the below tools: RHDH: Red Hat Developer Hub (Open source project: Backstage ) OCP Virtualization: Red Hat OpenShift Virtualization (Open source project: KubeVirt ) AAP: Red Hat Ansible Automation Platform (Open source project: Ansible / AWX ) RHEL BootC: Image mode for Red Hat Enterprise Linux (Open source project: bootc ) GitOps: Red Hat OpenShift GitOps (Open source project: ArgoCD ) Quay Registry or any other OCI compliant registry All of these projects can be run on Red Hat OpenShift (Open source project: OKD ) OR on other Kubernetes distribution or on VMs (you pick your underlying infra. For this post I have used OpenShift for simplicity of deployment, integrated tools and narrowly focusing on the usecases instead of the deployment of the tools).  The main goal here is to: Easily deploy and lifecycle applications and stuffs ...

I wanted to build a Homelab for some time but it was taking a backseat as I always had access to cloud environments (eg: cloud accounts, VMware DC etc) and the use cases I was focusing on didn't really warrant for one. But lately, some new developments and opportunities in the industry triggered the need to explore use cases in a bare-metal server environment, ultimately leading to the built of my own homelab, called MetalSNO. In this post, I will discuss some of my key reasons for building a homelab, the goals I set for it, and the process I followed to building one from scratch. I'll conclude with some reflections on whether it was truly worth it and what I plan to do with it going forward. Compelling reasons (The Why ) My uses cases for a homelab weren't about hosting plex server, home automation etc (I have them on Raspberry PIs for some years now). My Homelab is really about exploring technologies and concepts that are on par with industry trend. Below are some of the ...