From DevOps to Systems Maestro: Orchestrating AI and Governance

Everyone is talking about AI in DevOps right now. But I think a lot of the discussion is happening at the wrong level. To me, the interesting question is not whether AI can generate a Dockerfile or help write a Kubernetes manifest. That is nice, of course. But it is not the part that matters most. The more interesting question is this: can AI help us make better decisions when we run containerized systems in the real world? For example, can we use historical Prometheus metrics to predict load and scale a service before latency goes up and before users start to feel the problem? That is where AI starts to become truly useful. Not as decoration. Not as magic. And not as a replacement for good engineering. It becomes useful when it builds on a solid foundation. If your container images are badly designed, your deployment process is fragile, your observability is weak, or your Kubernetes setup is not well understood, then adding AI on top will not fix that. It will only add another layer of complexity. That is one of the ideas behind my book, The Ultimate Docker Container Book, Fourth Edition. In the book, I do not jump straight into AI. I start with the basics and build from there. We begin with containers, Docker, images, volumes, configuration, debugging, testing, and day-to-day productivity. From there, we move into networking, Docker Compose, logging, monitoring, security, Kubernetes, cloud deployment, and troubleshooting in production. Only after that do we look at AI and automation. This is important to me, because AI in DevOps only makes sense when the reader first understands the platform it is supposed to improve. And when the book gets to AI, it stays practical. It includes hands-on work around AI and automation in DevOps, such as building a predictive autoscaler, learning from Prometheus metrics, deploying the supporting pieces into Kubernetes, and automating model refresh with Argo Workflows. The book also covers many of the things teams really struggle with in practice. It looks at how to write better Dockerfiles, how to use multi-stage builds, how to scan images and verify where they come from, how to harden containers, how to manage secrets, how to work effectively with Docker Compose, and how to understand Kubernetes objects such as Pods, Deployments, Services, probes, rollouts, and security controls. It also covers observability with Prometheus, Grafana, OpenTelemetry, and Jaeger, as well as running applications on AKS, EKS, and GKE. So this is not a book just about commands. It is a book for people who want to understand how to build, ship, run, secure, monitor, and improve containerized applications in a professional way. And that is exactly why AI belongs in it. Because AI becomes useful only when the engineering underneath it is already solid. That is where the real value starts. #Docker #Kubernetes #AI #DevOps #PlatformEngineering #Containers #Observability #Automation #CloudNative

The DevOps I trained for is unrecognizable now. And the shift isn't "AI helps engineers code faster." That framing is too shallow. What's actually changing is the control plane around software delivery. For years, DevOps automation was deterministic — CI/CD, IaC, GitOps, runbooks, alert rules. We're now adding a probabilistic execution layer on top. AI agents reading telemetry, calling tools, correlating incidents, generating remediation plans, executing bounded actions. MCP matters because it eliminates bespoke glue between models and operational systems. The model stops being a chatbot. It becomes an orchestrator over Kubernetes, cloud APIs, CI/CD, observability, and incident platforms. DevOps gets more technical here, not less. The real work now: defining which tools an agent can call, constraining scope with RBAC, designing approval boundaries for prod tasks, building traceability for agent decisions, protecting against prompt injection and context poisoning. Govern it wrong — you're not automating operations. You're creating a new failure domain. Most companies aren't ready. AI-native operations require maturity most teams treat as optional: clean service ownership, accurate CMDB, strong secrets hygiene, least-privilege access, high-signal observability. Without those foundations, agents don't create intelligence. They amplify ambiguity. Noisy monitoring → noisy agent context. Stale docs → stale decisions. Broad permissions → wider blast radius. I've seen a 2-year DevOps engineer say "the agent fixed it" with zero understanding of what actually broke. That's not automation. That's a liability. Even in mature companies, the cons are real: hallucinated root cause passing shallow review, prompt injection turning untrusted context into unsafe actions, cost going nonlinear when agents loop, operator judgment eroding on novel incidents. The architecture that's emerging: → Deterministic — CI/CD, IaC, GitOps, policy-as-code → Agentic — reasoning, orchestration, incident correlation → Governance — approval gates, tracing, tool permissions, audit trails → Observability — agent telemetry: tool calls, decision traces, token cost, failure modes The next DevOps engineer needs to think like a platform engineer and a safety engineer. Not just: "How do I automate this?" But: "How do I expose this as a safe, observable, policy-bounded capability for an agent?" Companies that benefit most won't be the fastest to deploy agents. They'll be the ones treating agents like production systems — observable, governed, least-privileged, designed for rollback. Many teams are using 2023 operating models to manage 2026 tooling. That gap is where the real risk lives. #DevOps #SRE #PlatformEngineering #AIOps #MCP #AIAgents #CloudNative #Kubernetes #Observability #DevSecOps #InfrastructureAsCode #GitOps #IncidentManagement #ReliabilityEngineering #CloudEngineering

What I got wrong about DevOps (and what I'm rethinking). A few years in, I thought I had DevOps figured out. Turns out, I was wrong about some fundamental things. I thought DevOps was about tools. I spent so much energy mastering Kubernetes, Terraform, monitoring stacks. I treated them like the endgame. What I missed: Tools are just the vehicle. DevOps is actually about reducing friction between development and operations. You could do that with shell scripts if your team communicated well. You can fail with all the right tools if your culture is broken. The best DevOps engineers I know aren't the ones with the deepest Kubernetes knowledge. They're the ones who understand why their team needs automation and how to build it in a way people actually use. I thought experience was everything. "You need 5+ years to really get it," I used to say. What I've learned: Experience helps, but curiosity matters more. I've seen junior engineers solve problems that 10-year veterans couldn't because they asked better questions and weren't trapped by "that's how we've always done it." Years teach you patterns. Curiosity teaches you to question patterns. I thought DevOps was a team. I imagined a "DevOps team" that owned infrastructure, and that would solve everything. Reality check: DevOps works when it's a practice, not a team. When developers understand production. When operators understand code. When both care about reliability. Siloing DevOps into a team often makes things worse—creates bottlenecks instead of solving them. I thought burnout was just part of the job. "Welcome to on-call," I'd say. "This is what you signed up for." I was wrong. Burnout isn't a feature. It's a failure. It means your systems, your processes, or your culture isn't sustainable. And sustainable infrastructure requires sustainable people. What I'm rethinking now: DevOps isn't about being a hero who saves the day at 3 AM. It's about building systems so solid that 3 AM emergencies become rare. It's not about knowing every tool. It's about understanding problems and choosing tools wisely. It's not about experience or credentials. It's about thinking clearly and caring deeply about reliability. And it's definitely not worth your health or your sanity. The best DevOps engineers I know now? They're the ones still learning, still questioning, still thinking about how to make things better for their teams. What did you get wrong early in your DevOps journey? What have you learned that changed how you approach the work? #DevOps #CareerGrowth #SRE #Engineering #Reflection

DevOps Professional Services is about to be reshaped - and most PS companies aren't ready. In my previous post "Who is a DevOps engineer in 2026?" I argued AI is already redefining the role internally. The Professional Services market hasn't caught up yet. It will. Soon. The state of the market today Most companies converged on similar stacks. In Israel, 80% of startups run some variation of: AWS + EKS (or ECS) + RDS + ElastiCache + S3 + GitHub. How do startups build infrastructure today? Path 1: Hire a senior DevOps early. Expensive, and no guarantee the hire builds a real best-practice environment from business needs. Usually the result is "the most popular setup," not the right one. Path 2: Hand the role to a backend developer who needs to ship fast. Public subnets, IAM Users, static credentials, no Landing Zone. Both paths end at the same place: Path 1 - "we need to reduce infrastructure cost" Path 2 - "we need to migrate and modernize before this breaks" The most efficient solution is a Professional Services company (ideally an AWS Partner) with deep experience in your stack - faster delivery, fewer mistakes, real best practices. But PS companies need to change too. The traditional PS model - 250 hours per engagement, 3-6 month delivery - is built for a world before AI. I've already built (and recommend every PS company build) an AI-powered platform that compresses delivery: - Cloud Discovery Session - max 1 hour deep dive - PDF proposal generated automatically, with hour estimates and success criteria - Detailed SoW generated after approval Terraform main.tf and vars.tf generated from customer inputs, using proven internal modules End result: one person, in a few hours, produces a Cloud Discovery Session, signed-ready SoW, and production-grade Terraform files. What's left for the DevOps engineer? terraform apply, application testing, data migration. A 250-hour project becomes a 25-hour project. The market shift this triggers For now, PS companies keep selling 250-hour packages. But the market always corrects: - Project hour counts compress - customers stop paying for work AI eliminates - One-time projects give way to retainers - e.g. 8 hours/week of expert DevOps on demand - Retainers replace full-time hires at early stages - cheaper than a senior salary, outcomes in days, not 6 months The PS company that wins turns delivery into reusable LEGO blocks: Terraform modules for example: - VPC - EKS & Pod-Indentity - RDS - ElastiCache - S3 Snap them together per customer, deliver in a fraction of the time. Bottom line: The future of DevOps PS isn't bigger projects - it's smaller, faster, AI-assisted, retainer-based engagements built on reusable modules. For startups - best-practice infrastructure becomes dramatically more accessible. Are you building your LEGO set yet? #AWS #DevOps #CloudArchitecture #AI #Terraform #FinOps

🚀 The future of DevOps isn’t coming… it’s already here At Aquaware, we’ve been exploring some of the most impactful shifts happening right now across cloud, AI, and infrastructure — and one thing is clear: 👉 DevOps is evolving faster than ever. Here are 7 key trends shaping what’s next: ☁️ 1. Storage is evolving beyond storage With Amazon S3 Files, object storage starts behaving like a file system. No more download → modify → upload cycles. Now, applications can interact with data directly — simplifying pipelines, AI workflows, and legacy integrations. 💥 2. Resilience is built, not assumed Chaos Engineering is becoming essential. By intentionally injecting failures, teams can validate systems before real incidents happen. 👉 Strong systems aren’t the ones that never fail — they’re the ones prepared to. 🚨 3. AI introduces a new attack surface Recent findings show how tools like Claude Code can be manipulated through simple config files. The takeaway? 👉 In AI-driven environments, configs are no longer passive — they’re part of your security perimeter. 🤖 4. From automation → autonomy With AWS DevOps & Security Agents now generally available, we’re entering a world where: • Incidents are investigated automatically • Systems self-heal • Monitoring becomes proactive DevOps engineers are no longer just operators — they’re orchestrators of intelligent systems. 🧠 5. AI is becoming truly accessible With models like Gemma 4, we’re seeing a powerful shift: • Open-weight models • Local execution • Multimodal capabilities • Full control over data and pipelines 👉 The rise of “sovereign AI” is real. 🔌 6. MCP is becoming the “USB for AI” With 97M+ installs, the Model Context Protocol is quickly becoming the standard for connecting AI agents to tools and systems. This unlocks a new development paradigm: 👉 Developers design systems — agents execute them. ⚙️ 7. Tools > memorization Even at the operational level, the mindset is changing. Tools like K9s simplify Kubernetes management with real-time visibility and fast actions — no need to memorize endless commands. 👉 Great engineers don’t just know commands — they know how to move faster with the right tools. 🎯 Final thought We’re witnessing a major shift: From reactive → proactive From manual → autonomous From tools → intelligent systems The question is no longer if DevOps will change… 👉 but how ready we are to evolve with it. 💬 Which of these trends are you already exploring in your team? #DevOps #Cloud #AI #Kubernetes #AWS #MCP #Gemma #ChaosEngineering #PlatformEngineering #Aquaware

What My Pug Trufa Taught Me About DevOps (And Why Most Teams Get It Wrong) My 7-year-old pug, Trufa, follows me everywhere. She knows my movements before I make them. She communicates with sounds, expressions, posture, touch. She understands some words… and all of my emotions. We don’t “translate” anymore. We just understand. Unfortunately, many DevOps teams don’t communicate this well. Not even close. We say we value collaboration, feedback loops, and shared understanding. But what do we actually build noisy alerts, fragmented tools, delayed feedback and misinterpreted signals. Trufa doesn’t have dashboards. She has something better: high-fidelity signal clarity. Every signal she sends is intentional, context-aware and immediately understood. Every signal she receives from me is observed, interpreted, and acted on No tickets. No handoffs. No ambiguity. This is what real DevOps should look like: Signals are clear, feedback is immediate, context is shared, and understanding is mutual Clear signals require respect fo the person sending the signal, the person receiving it, and the system that carries it. Without respect, signals degrade. People stop speaking clearly. Others stop listening carefully. And that’s when something dangerous begins to accumulate: Human Debt Human Debt builds when: People don’t speak up. Signals are ignored or dismissed. Feedback is delayed or distorted. Teams optimize tools instead of understanding. Over time, the system fills with: Noise instead of meaning. Alerts instead of insight. Activity instead of alignment. At that point, DevOps doesn’t fail because of tooling. It fails because the human system stopped working. Let me say this plainly: DevOps is not a tooling problem. It’s a communication system problem. And communication systems are built on: 👉 Respect 👉 Trust 👉 Shared understanding Trufa didn’t learn this from frameworks or certifications. She operates on something far more fundamental: Respect first. Trust always. She respects my signals. I respect hers. That’s why understanding is effortless. Now compare that to most systems: Signals are generated…But not respected. Feedback is available… But not trusted. Communication exists…But understanding does not. And in that gap… Human Debt grows Until eventually, you get the illusion of DevOps: dashboards everywhere. alerts firing constantly. pipelines running perfectly...on a system no one truly understands. So here’s the real lesson from a pug: If your system cannot do this: signal → understanding → response (without friction)Then you don’t have DevOps, you have noise. And in the end… .. Trust is the control plane.. Respect is the foundation and Human Debt is the risk you can’t ignore. Read more from our book "Engineering Respect and Trust - The Human Architecture of Intelligent Systems". Available on Amazon.

why you should learn YAML, In your DevOps journey → Not Kubernetes. → Not CI/CD. → Not Infrastructure as Code.  Because behind all these tools, there’s one silent layer controlling everything: YAML: Most beginners think DevOps is about tools. Kubernetes. Docker. Jenkins. GitHub Actions. But here’s the reality  Those tools are just engines. YAML is the instruction manual. So what exactly is YAML?  YAML is a human-readable data format used to define configurations, workflows, and infrastructure. It doesn’t execute logic. It doesn’t run code. Instead, it answers one powerful question:  “What should the system look like?” Why YAML became the backbone of DevOps Modern DevOps is built on 3 core ideas: → Automation → Consistency → Reproducibility YAML enables all three. Because instead of manually setting up systems… You define everything as code: → Infrastructure → Deployments → Pipelines → Policies This is what we call Infrastructure as Code (IaC), and YAML is one of its core formats. → Where YAML actually runs your world You don’t “use” YAML once. You use it everywhere: Kubernetes → Defines pods, deployments, services (desired state) CI/CD (GitHub Actions, GitLab, Azure DevOps) → Defines pipeline steps and automation flows Ansible → Defines automation tasks (playbooks) Docker Compose → Defines multi-container applications Cloud (AWS, Azure) → Defines infrastructure templates simple story:  YAML is the glue connecting your entire DevOps ecosystem. The harsh truth about YAMAL It's totally looks easy. And that’s exactly why it’s dangerous. Because: It relies completely on indentation One wrong space = broken deployment No obvious errors sometimes Silent failures are common Even in real systems: Wrong indentation → Kubernetes fails to deploy Missing fields → CI/CD pipeline breaks Misconfigured permissions → security risks  YAML is not a programming language (and that’s the point) No loops. No conditions (mostly). No logic-heavy operations. It’s purely:  Structure over logic And that’s why it scales so well. → Because every tool can read it. → Every team can understand it. → Every system can follow it. The real skill is NOT writing YAML Here’s where most people get it wrong: You don’t need to memorize YAML. You need to understand: → How systems are structured → How tools interpret configuration → How infrastructure is defined Because YAML is just a representation of your thinking.  → Learn YAML once… And you unlock the entire DevOps ecosystem. #yaml #yamal #devops #aws #Devopsroadmap #cloud #gcp #Iac #k8s #git

🚀 The DevOps Team Delusion: A Manifesto Ah, the "DevOps Team." I hear the whispers in the hallways every day: "I’ll check with the DevOps team," or the ever-popular, "We need to hire a DevOps Engineer." It’s charming, really. It’s like saying, "I’ll check with the Team of Happiness" or "We need to hire a Professional Politeness Officer." It sounds lovely in a brochure, but it fundamentally misses the point of the revolution. 🛠️ Culture, Not a Cubicle Let’s get one thing straight: DevOps is a culture, not a tool, and certainly not a department. You cannot "install" DevOps by buying a Jenkins license, nor can you "contain" it within a specific row of desks near the server room. When we treat DevOps as a separate team, we aren't solving the silo problem—we’re just building a shiny new silo with a cooler name. The Reality Check: DevOps is a philosophy of shared responsibility. If you have a "DevOps Team" standing between your developers and your operations, you haven’t achieved synergy; you’ve just added a middleman in a North Face vest. 🎯 The True North: Business Domains Instead of obsessing over who owns the YAML files or splitting our people into "Front-end" and "Back-end" tribes, we should be glorifying a much more potent idea: Domain Alignment. The magic happens when we stop organizing by technology stack and start organizing by business purpose. Why have a front-end team wait on a back-end team just to change a login button? Instead, give a single team the entire Account Module. When one team owns the domain from top to bottom, they focus on the business logic, not the handovers. If they need to evolve the Account experience, they just do it. They don’t bother the other teams, and they don't get bogged down in cross-departmental bureaucracy. The technical friction simply melts away. ✨ Why This Matters (The "Glorious" Part) When you align by business domain: ❤️ Empathy reigns supreme: The team cares about the User's Account, not just a React component or a SQL query. 🔓 Autonomy is unlocked: The team has the power to ship an entire feature without asking for permission from the "DevOps Overlords" or waiting for the "API Team." 📈 Success is measured in profit and joy, rather than how many Kubernetes clusters you managed to spin up before lunch. So, the next time someone tells you they’re "doing DevOps," ask them if they’re building a bridge or just charging a toll. DevOps is the air we breathe, not the oxygen tank we carry. Let’s stop hiring for a "team" and start building a culture where the technology serves the business, and the business finally understands the technology. #DevOps #TechCulture #SoftwareEngineering #BusinessDomains #PlatformEngineering #Agile

🚀 The Ultimate DevOps Cheat Sheet for 2026 🚀 Whether you are transitioning into DevOps, preparing for an interview, or just need a quick refresher, keeping the core concepts straight is essential. Here is a high-level breakdown of the modern DevOps ecosystem. 👇 🧠 1. The Core Philosophy (CALMS) DevOps isn't just tools; it's a culture. Culture: Collaboration between Dev and Ops. Automation: Remove manual, repetitive tasks. Lean: Focus on delivering value and eliminating waste. Measurement: Track everything (metrics, logs, performance). Sharing: Open communication and shared responsibilities. 🔄 2. CI/CD (Continuous Integration / Continuous Delivery) The engine of modern software delivery. CI: Automatically building and testing code every time a team member commits changes (e.g., Jenkins, GitHub Actions, GitLab CI). CD (Delivery): Ensuring the code is always in a deployable state. CD (Deployment): Every change that passes automated tests is deployed to production automatically. 🏗️ 3. Infrastructure as Code (IaC) Managing and provisioning computing infrastructure through machine-readable definition files. Provisioning: Terraform, AWS CloudFormation (Setting up the servers, networks, databases). Configuration Management: Ansible, Chef, Puppet (Installing software and managing configurations on those servers). 🐳 4. Containers & Orchestration Packaging software to run reliably anywhere. Docker: Packages an application and its dependencies into a standardized unit (container). Kubernetes (K8s): The conductor. Automates deployment, scaling, and management of containerized applications across clusters of hosts. 📊 5. Observability & Monitoring You can't fix what you can't see. The three pillars: Metrics: System numbers (CPU, memory, request rates). Tools: Prometheus, Datadog. Logs: Immutable records of discrete events. Tools: ELK Stack (Elasticsearch, Logstash, Kibana), Splunk. Traces: Tracking a single request as it flows through a distributed system. Tools: Jaeger, OpenTelemetry. ☁️ 6. Cloud Providers Where the magic happens. AWS: The market leader (EC2, S3, EKS). Azure: Deep enterprise integration (AKS, Azure DevOps). GCP: Google Cloud, known for strong data and Kubernetes (GKE) offerings. Pro-Tip: You don't need to master every tool. Focus on understanding the underlying concepts (e.g., how orchestration works) rather than just memorizing a specific tool's CLI commands. Tools change; concepts scale. What is your go-to DevOps tool that you can't live without right now? Let me know in the comments! 👇 #DevOps #Tech #SoftwareEngineering #CloudComputing #Kubernetes #Terraform #CICD #TechCareers #Programming

SRE vs. Platform vs. DevOps: If you’re confused, look at the "Customer." In a massive enterprise, these roles have clear boundaries. But in a startup? They usually live in the same person’s brain. To understand the difference, don't look at the tools (Terraform or K8s). Look at who the engineer is trying to make happy. 1. The DevOps Engineer  • The Customer: The Business & the Culture.  • The Mission: Shorten the SDLC and improve DevEx  • The Reality: DevOps is the most common job-title out there but in reality it is a philosophy. If you have this title, you’re likely bridging the gap between "it works on my computer" and "it works in production". 2. The Site Reliability Engineer (SRE)  • The Customer: The End User (production).  • The Mission: Ensure the app is fast, available, and reliable.  • The Key Metric: It has metrics, error budgets, SLIs, SLOs. When checkout latency spikes at 2 AM, the SRE is the one who gets paged. Blameless postmortems are also their thing. 3. The Platform Engineer  • The Customer: The Internal Developer.  • The Mission: Reduce "Cognitive Load."  • The Output: Creating an Internal Development Platform so a dev can deploy a microservice in 2 clicks instead of 20 tickets. It's all about self-service and standardization. Think of it as DevOps turned into a product. The Startup Reality: The "All-in-One" Engineer In a scaling startup, you don't have the luxury of three separate departments. You have a "Product Infrastructure" person or a tiny Ops team. Monday morning: You’re an SRE because the database is on fire. Monday lunch break: You’re a DevOps Evangelist trying to convince everyone that "Quality is a shared responsibility." Monday evening: You’re a Platform Engineer because devs are struggling with CI/CD. And that's a regular Monday. The Intersection: Regardless of the title, the goal remains the same: Shipping value safely and quickly. In the early days, you don't need "perfectly defined roles." You need engineers who understand that Stability (SRE) and Developer Velocity (Platform) are two sides of the same Cultural coin (DevOps). If you're a PM or CTO, ask yourself: do you know who your infra team's customer is? If the answer is vague, your investment in that team probably is too. 𝗣𝗦: 99.37% of the time they are all cloud engineers. #SoftwareEngineering #DevOps #SRE #PlatformEngineering #CloudNative #Startups