The Gap Between Keynotes and Reality
Red Hat Summit 2026 in Atlanta was incredible. The keynote announcements showcased AgentOps, llm-d, and AI agents with guardrails. The AgentOps lab demonstrated MLflow tracing, SPIFFE/SPIRE agent identity, and live red teaming with 6,055 audience prompts.
But between sessions, walking the expo floor, sitting in labs, and talking to real practitioners — I heard a very different story. Here are 13 things enterprises actually told me they need.
1. One Person Running All of Kubernetes
The most common pattern I encountered: a single engineer responsible for the entire Kubernetes or OpenShift platform. One person. One brain. One point of failure.
When that person goes on vacation, gets sick, or leaves the company — the entire platform strategy is at risk. Nobody else knows how the clusters are configured, why certain decisions were made, or how to troubleshoot production issues.
The fix: Cross-training, runbooks, and platform engineering practices that distribute knowledge. If your Kubernetes platform depends on one hero, you do not have a platform — you have a liability.
2. Running Unsupported OpenShift Versions
Multiple conversations about running unsupported OpenShift versions and hoping AIOps would somehow compensate. The logic: “We can’t upgrade because we don’t have time, but maybe AI can help us manage the problems.”
This is putting AI on a crumbling foundation. Unsupported versions mean no security patches, no bug fixes, and no vendor support when things break. AIOps cannot fix what outdated software introduces.
The fix: Prioritize the upgrade. Create a rolling upgrade plan. If you are more than two minor versions behind, treat it as a P1 project — not a someday task.
3. Legacy Deployment Templates
Still using OpenShift DeploymentConfig templates instead of standard Kubernetes Deployments. DeploymentConfigs were deprecated in OpenShift 4.14. They worked well in the OpenShift 3.x era, but they lock you into OpenShift-specific patterns and prevent portability.
The fix: Migrate to standard Kubernetes Deployments, StatefulSets, and Jobs. Use Helm charts or Kustomize overlays. Future-proof your workloads by staying close to upstream Kubernetes APIs.
4. Patchy Ad-Hoc Releases to Production
No CI/CD pipeline. No GitOps. Just manual, ad-hoc deployments — “releasing to the world in the current patchy way.” Every deployment is a snowflake. No rollback strategy. No audit trail.
The fix: Start with a simple pipeline. Even a basic GitHub Actions or Tekton pipeline that builds, tests, and deploys is infinitely better than manual oc apply commands. Add ArgoCD or Flux for GitOps once the basics are solid.
5. OpenShift Virtualization Migration
The ongoing hypervisor initiative — migrating from VMware to OpenShift Virtualization (KubeVirt). Since the Broadcom acquisition, enterprises are scrambling to find alternatives. OpenShift Virt is the natural destination for Red Hat shops, but the migration is complex.
The fix: Start with non-critical workloads. Build a migration factory with repeatable patterns. Use MTV (Migration Toolkit for Virtualization) to automate VM-to-KubeVirt conversions. Plan for networking and storage differences early.
6. No Feedback Environment
No proper staging, QA, or pre-production environment. Changes go from development directly to production with no validation layer in between.
The fix: At minimum, create a single staging environment that mirrors production topology. Use namespace-based isolation on the same cluster if a dedicated cluster is too expensive. Test every change before it touches production — every single time.
7. XLD (XebiaLabs Deploy) Design
Still architecting around XebiaLabs Deploy (now Digital.ai Deploy) — a legacy deployment orchestration tool. It works, but it creates vendor lock-in and adds complexity that modern GitOps tooling eliminates.
The fix: Evaluate whether XLD is adding value or adding friction. For Kubernetes workloads, ArgoCD or Flux provide native GitOps with lower operational overhead. Migration does not have to be big-bang — start with new workloads on GitOps and migrate legacy over time.
8. Ansible Automation Platform Execution Mode
Questions about execution environments in Ansible Automation Platform — the shift from the old ansible-playbook execution to containerized execution environments. This is a fundamental architectural change that trips up teams used to the controller-centric model.
The fix: Build custom execution environments with ansible-builder. Start with the supported base images and layer in your collections and dependencies. Test execution environments in a dev AAP instance before promoting to production. Check out my Ansible tutorial for detailed guides.
9. Spinning Up a Production Cluster
Enterprises needing help to spin up a production-grade OpenShift cluster from scratch. Not a proof of concept. Not a dev sandbox. A real, hardened, production-ready cluster with proper networking, storage, authentication, and monitoring.
The fix: Use the OpenShift installer with a tested, documented configuration. Define your infrastructure requirements upfront: node sizing, network topology, storage backend, identity provider. Do not treat cluster installation as a one-time activity — automate it so you can rebuild reproducibly.
10. Standing Up Deployment Pipelines
Related to point 4, but more forward-looking: enterprises that know they need pipelines but do not know where to start. “Stand up deployment” was the request — build the entire CI/CD infrastructure from zero.
The fix: Start simple. A pipeline that builds a container image, pushes it to a registry, and deploys it to a namespace. Then add testing, security scanning, and promotion gates incrementally. Tekton is native to OpenShift. ArgoCD handles the GitOps side.
11. Operator Configuration
“The easy one” — except it never is. Installing and configuring Kubernetes Operators correctly requires understanding CRDs, RBAC, resource limits, and the operator lifecycle. Misconfigured operators cause cascading failures that are hard to debug.
The fix: Read the operator documentation. Check resource requirements before installing. Set resource limits. Monitor operator pods. Use OLM (Operator Lifecycle Manager) for upgrades and channel management. Test in a non-production namespace first.
12. Container Configuration
Getting container configurations right: resource requests and limits, security contexts, image pull policies, health checks, and volume mounts. The gap between “it works in Docker on my laptop” and “it runs reliably in production on OpenShift” is vast.
The fix: Define resource requests AND limits for every container. Set readinessProbe and livenessProbe. Run as non-root. Drop all capabilities. Use SecurityContextConstraints (SCCs) to enforce policies. Check out my Kubernetes workshops for hands-on training.
13. Plan Together
The most telling request of all: “plan together.” Not “do it for me.” Not “give me a document.” Just sit down, look at what we have, and figure out a path forward — collaboratively.
This is what enterprises actually need. Not another vendor pitch. Not another product demo. A trusted advisor who understands the technology, listens to the constraints, and helps build a realistic plan.
That is exactly what I do. Book a free consultation and let us plan together.
The Pattern
All 13 points connect. One overworked person managing OpenShift → no time to upgrade → versions fall behind → no time to build proper CI/CD → manual patchy releases → no feedback environment → production incidents → call for help.
The fix is not one tool or one product. It is building platform engineering maturity: distributing knowledge, automating processes, and creating feedback loops. It starts with an honest assessment of where you are and a realistic plan to get where you need to be.
Red Hat Summit 2026 showed the future with AI agents and guardrails. But for most enterprises, the path to that future starts with getting the fundamentals right.
Want to close these gaps in your organization? Book a free consultation or explore my services.
