According To Ali

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...

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 ...

A source code's (an application) destination is to get deployed to a target environment (eg: dev, uat, integration, staging, prod etc) so that the end users can consume it. (that's a no brainer).  The source to production path can be implemented using different ways with different tools typically following a concept called CI and CD and then adding other terminologies such as DevOps, DevSecOps, Pipelines, Supply Chains, Orchestrations, Choreography etc etc. And these are not unnecessary. As the dynamics of modern applications are shifting from monolith to service oriented (and/or microservices) so is evolving the tech layers for defining CI and CD. In this post I will describe my views on some of the draw backs I have found in tradition pipelines and how the concept of Supply Chain (its the new thing) can resolve it.  Table of contents: Concepts for path to production Pipeline and its drawbacks Functional Specs of source to target environment path Cloud Native Supply Chain usi...