Virtual Elephant

Why does it seem easier to adopt a new platform than to fix how we work?

Over the past 10 years, I’ve seen a familiar pattern:

A new CIO or CTO comes in with a sweeping mandate like “cloud first” or “containers first” — long before they really understand where the company is today from an engineering and operational standpoint.

I’ve also watched leaders latch onto a new technology (Kubernetes is a popular one) after being convinced by vendors that going all-in on a new platform will solve all their problems.

And to be fair, it does look good at first:

• The first 1–2 years often go well
• There are shiny dashboards, new teams, new titles
• Execs can talk about “modernization” on earnings calls and in board decks

Then the shine wears off.

Suddenly they realize they’ve simply rebuilt the same dysfunctional system…on a brand new platform.

So why does this happen over and over?

Because the old technology was rarely the real constraint.

It’s easier to:
• Buy a new platform than to challenge entrenched processes
• Launch a “cloud first” slogan than to rebuild incentives and accountability
• Fund a big transformation program than to do the unglamorous work of operational discipline

The core issue is that most organizations never strategically leverage their platform — public cloud, private cloud, hypervisor, containers, or Kubernetes — to drive operational maturity in engineering and IT.

In 2025, you’d be hard-pressed to convince me that a disciplined organization couldn’t use almost any modern platform to achieve its strategic goals.

The question is rarely, “Did we pick the right platform?” It’s almost always, “Are we willing to do the hard work to operate it well?”

#PlatformEngineering #DevOps #TechLeadership #CloudStrategy #OperationalMaturity #Execution #SRE #DigitalTransformation #CIO #CTO

1 week ago | [YT] | 2

Virtual Elephant

Most Kubernetes ingress stacks are still built on ingress-nginx + some mix of L4/L7 load balancers.

That worked for a while… but as we scale:
• We want consistent policy across clusters
• We want native BGP integration with the network
• We want to align with what the Kubernetes Networking SIG is investing in long term

In my new video, I walk through how I’m wiring this up in a real lab:
• Using Cilium as CNI + BGP control plane
• Configuring CiliumLoadBalancerIPPool for VIP management
• Defining BGPClusterConfig and BGPPeerConfig to talk to Cisco Nexus
• Exposing apps through Gateway API, not ingress-nginx
• Verifying end-to-end: Cilium → Nexus → pfSense → smoke-test app

This is aimed at practitioners – platform engineers, SREs, and infra leads who:
• Own production clusters
• Need to plan for an eventual ingress-nginx → Gateway API migration
• Want to understand the traffic flow all the way to the core network

If you’re designing or refactoring your Kubernetes network stack for the next 3–5 years, this is the kind of pattern you’ll be looking at.

#Kubernetes #Cilium #BGP #GatewayAPI #PlatformEngineering #SRE #CloudNative #VirtualElephant #Networking

2 weeks ago | [YT] | 2

Virtual Elephant

Getting Started with AI Isn’t as Hard as You Think

Too many technology leaders are being told that deploying #GenAI models is complex, risky, and something that only large enterprises with massive AI/ML budgets can pursue.

That narrative is outdated—and more importantly, it's holding your organization back.

In my latest video, I break down how you can get started with CodeLlama, a powerful, open-source LLM developed by Meta, using a clean and intuitive front-end called Open WebUI—all deployed inside a containerized environment using Docker. No GPU clusters. No cloud dependency. No vendor lock-in.

This isn’t just a home lab experiment—it’s a blueprint for how any modern engineering org can begin to own their AI strategy.

Here’s why it matters:
1. You Own the Model. You Own the Data.
Running models like CodeLlama on-prem or in your own environment puts you in full control of your IP, telemetry, and model outputs. No third-party risk. No data leaks. That’s non-negotiable when you’re building proprietary systems or operating in regulated industries.

2. Deployment Doesn’t Have to Be Complex.
With containerized solutions and pre-trained models, the heavy lifting is already done. In the video, I demonstrate how to go from zero to a functional #GenAI coding assistant in minutes—using nothing more than Docker and a few config files. This is something your platform team could prototype in a single sprint.

3. It's a Practical First Step Toward Responsible AI Adoption.
Not every org is ready to train their own #LLM. But deploying a fine-tuned model like CodeLlama-7B-Python is an actionable way to explore AI-assisted development, internal automation, or code understanding—without jumping straight into the deep end.

The Strategic Opportunity for Leaders

CTOs and CIOs should be asking:
How can we quickly prove value with AI while maintaining control and alignment with our long-term architecture strategy?

This video answers that question with a practical example.

Whether you're exploring internal dev tools, documentation automation, or intelligent code reviews, #GenAI can offer huge leverage—but only if your organization has the confidence to start.

6 months ago | [YT] | 0

Virtual Elephant

Over the past two weeks, I’ve been publishing a deep-dive video series documenting the buildout of a full VMware Cloud Foundation (VCF) 5.2.1 environment in my home lab — from bare metal to a fully operational multi-platform Kubernetes infrastructure.

Why?
Because modern architecture teams are expected to design for hybrid, multi-cloud, and multi-runtime realities. And for me, there’s no better way to stay sharp than building it myself — end to end.

This isn’t just another “How I built my home lab” series.

It’s a blueprint for how you can build your own Software-Defined Data Center (SDDC) that mirrors real enterprise deployments—using NSX, BGP, vSAN, and load balancing services — while supporting multiple Kubernetes platforms, including:

Red Hat OpenShift (RHOS)

Rancher (SUSE)

VMware Tanzu Kubernetes Grid (TKG/Supervisor Cluster)

Open-source K8s deployed to VMs via kubeadm

Here’s a quick breakdown of what the series covers so far:

Parts 1–5 (already live):

Physical leaf-spine topology with Cisco Nexus 3064-X

pfSense firewall deployment & outbound NAT configuration

Pi-hole DNS with Unbound

ESXi host configuration, certificates, NTP

Deploying VMware Cloud Foundation via Cloud Builder

Parts 6–10 (just released):

Part 6: Deploying the NSX Edge Cluster & Tier-0 Gateway

Part 7: Configuring BGP across NSX-T, Cisco Nexus, and pfSense

Part 8: Deploying the vSphere Supervisor Cluster (TKG) with NSX networking

Part 9: Deploying NSX Advanced Load Balancer (Avi) for K8s Ingress & L4/L7 services

Part 10: Performing a Day 2 lifecycle activity using SDDC Manager

If you're a home-labber, SRE, enterprise architect, or just someone who believes in learning through doing, this series is for you. The videos include real-world troubleshooting, design rationale, and insights into what works (and what doesn’t) when building a scalable, modern Kubernetes platform.

Whether you're prepping for certifications (VCDX, VCIX-NV, or CKA), building a career in platform engineering, or running your own lab at home—this content will help level up your infrastructure game.

Let me know in the comments what platform you’re running in your lab — or what you’re thinking of building next.

#VMware #VCF #NSX #Kubernetes #HomeLab #OpenShift #Rancher #Tanzu #TKG #SRE #CloudFoundation #EnterpriseArchitecture #VirtualElephant #PlatformEngineering #vSphere #BGP #vSAN #NSXAdvancedLoadBalancer #Multicloud #K8s #DevOps #CKA #VCDX

8 months ago | [YT] | 0

Virtual Elephant

To go along with the new VCF Home Lab Series, I wanted to share a few design diagrams of the various layers and components making up the entire infrastructure (virtual & physical). Attached here is a physical design diagram for the Cisco Spine-Leaf topology and how the servers are connected to the Leaf switches, how everything is interconnected, and how the Leafs operate as Border Leafs and connect through to the pfSense Netgear 8200 firewall.

8 months ago | [YT] | 6