Speaker 1: You ever feel like software development is just this relentless treadmill,
Speaker 1: you know, new releases, features, patches, It just never stops. Yeah, absolutely,
Speaker 1: And for so many teams it feels less like build
Speaker 1: ship learn and more like build ship burnout.
Speaker 2: That burnout is real.
Speaker 1: But what if there was like a shortcut, a way
Speaker 1: to make things smoother, faster, more reliable.
Speaker 2: That's the million dollar question, isn't it.
Speaker 1: Well, today we're diving deep into Roman Verrel's book New Ops.
Speaker 1: How AI agents are reinventing DevOps and software. It's pretty
Speaker 1: insightful stuff. Our mission here is to sort of unpack
Speaker 1: that journey. How do we get from these you know,
Speaker 1: fragmented systems we have today to a future where software
Speaker 1: almost runs.
Speaker 2: Itself, freeing up people for the really interesting.
Speaker 1: Work, exactly, freeing you up to focus on what only
Speaker 1: humans can do, which is innovate. So we'll explore why
Speaker 1: traditional DevOps well sometimes it just isn't enough, how standardization
Speaker 1: kind of leads the groundwork, and then crucially, how generative
Speaker 1: AI steps in to revolutionize pretty much everything, coding, infrastructure,
Speaker 1: the works. It's a big shift, it really is. So Okay,
Speaker 1: let's unpack this. How can we actually get there. How
Speaker 1: does the drudgery melt away?
Speaker 2: The foundation from DevOps evolution to standardization.
Speaker 1: Okay, before we jump into like reinventing the future, let's
Speaker 1: glance back for a second. Remember the old days, the
Speaker 1: rigid walls between devs and ops.
Speaker 2: Oh yeah, that thrown over the wall, mentality.
Speaker 1: Role nightmare, right, Yeah, long release cycles, constant finger pointing.
Speaker 2: It really was. Now Agile started breaking down those silos
Speaker 2: within development, which was a good start.
Speaker 1: But OPS was still often the bottleneck, definitely.
Speaker 2: And then you know, DevOps as a term started gaining traction.
Speaker 2: Patrick de Bois, the DevOps Days conferences.
Speaker 1: And that flicker talk ten plus deployees per day back
Speaker 1: in two thousand and nine, right.
Speaker 2: All spaw and Hammond. That was like a real light
Speaker 2: bulb moment for a lot of people.
Speaker 1: And then the Phoenix project came along in boom. It
Speaker 1: really brought CICD, shared responsibility, all that stuff into the mainstream.
Speaker 2: Yeah, collaboration, automation, measurement, learning, those became the core ideas.
Speaker 1: And the results. I mean, look at the door reports,
Speaker 1: elite teams deploying hundreds of times a day.
Speaker 2: It's incredible. Think Amazon, Netflix, It's.
Speaker 1: Not just faster. It's a whole different way of operating,
Speaker 1: adapting almost in real time exactly.
Speaker 2: But here's the catch. Despite all that promise, so many
Speaker 2: organizations are still struggling to get there.
Speaker 1: Yeah, why is that? If the path is clear, why
Speaker 1: are people stuck?
Speaker 2: Well, the book points to a few things, new pressures
Speaker 2: and emerging challenges, like cultural resistance. That's a big one.
Speaker 2: Up to forty five percent of initiative stalled just on culture.
Speaker 1: Wow, nearly half.
Speaker 2: Yeah, and then skill gaps and kind of ironically, this
Speaker 2: thing called tool sprawl.
Speaker 1: Okay, tool sprawl, let's dig into that. So if you've
Speaker 1: adopted DevOps but you still feel stuck, this sounds like
Speaker 1: a big part of the.
Speaker 2: Why it often is. It's this sort of ironic outcome
Speaker 2: of DevOps. You want the best tool for each makes sense,
Speaker 2: So you get get for version control, Jenkins for CI,
Speaker 2: maybe Terraform for your infrastructure, Splunk for monitoring, all good
Speaker 2: tools on their own, all great tools. But suddenly you've
Speaker 2: got twenty thirty maybe even more, different tools you're trying
Speaker 2: to juggle.
Speaker 1: Okay, I can see how that gets messy.
Speaker 2: Fast, And the book cites this figure. Over fifty percent
Speaker 2: of enterprises using more than twenty DevOps tools. That creates
Speaker 2: what VORL calls.
Speaker 1: A tool tax cool tax, meaning.
Speaker 2: Meaning significant license costs. Yeah, but also constant integration headaches
Speaker 2: and developers just burning time context switching between all these
Speaker 2: different interfaces.
Speaker 1: Right, jumping from one UI to another, trying to remember
Speaker 1: how this.
Speaker 2: One works exactly. And then there are the data.
Speaker 1: Silos, so each tool keeps its own data separately pretty much.
Speaker 2: Build logs are over here, test results are there, deployment
Speaker 2: record somewhere else.
Speaker 1: Entirely, which leads to that visibility gap you mentioned precisely.
Speaker 2: The book says seventy four percent of teams lack that
Speaker 2: end to end visibility. So when something breaks, good luck
Speaker 2: figuring out what happened quickly.
Speaker 1: Ouch, So incident response times just go through the roof they.
Speaker 2: Do, and it creates these DevOps ironies. Like you tried
Speaker 2: to break down silos between devnops, but now you've got
Speaker 2: new silos based on who knows which specific tool.
Speaker 1: So more friction, duplicate effort.
Speaker 2: Yeah, that whole choose your own tool culture sounds great
Speaker 2: for innovation initially, but it often just spirals into fragmentation
Speaker 2: and hidden costs slower time to market, more errors.
Speaker 1: The book had that example, right, the financial services firm.
Speaker 2: Oh yeah, that was a painful one to read about.
Speaker 1: Yeah.
Speaker 2: Eight different CI pipelines, three.
Speaker 1: Code repositories, different logging systems.
Speaker 2: Imagine being an engineer there just trying to track down
Speaker 2: which version of a micro service was deployed when something
Speaker 2: went wrong. Hours wasted, and.
Speaker 1: It wasn't just the pipelines, right, It went down to
Speaker 1: the developers machine.
Speaker 2: Absolutely, multiple IDEs vs. Code intelliga eclipse. It fragments the
Speaker 2: whole developer experience, harder to enforce, standards, harder to collapse.
Speaker 1: And ultimately, you said, it hurts AI.
Speaker 2: Readiness critically, that's the connection to the future. Why does
Speaker 2: all this fragmentation matter so much for AI? Okay, why
Speaker 2: because AI, especially generative AI, thrives on data consistent, complete,
Speaker 2: high quality.
Speaker 1: Data right, garbage in garbage.
Speaker 2: App Exactly If your logs, metrics test results are scattered
Speaker 2: everywhere in different formats, any AI trying to find anomalies
Speaker 2: or generate code is basically working with blind.
Speaker 1: Spots, so it just can't see the whole picture.
Speaker 2: It can't. Fragmentation is like the number one enemy of
Speaker 2: advanced AI. And DevOps.
Speaker 1: Okay, so the path forward becomes well obvious. I guess standardization, standardization.
Speaker 2: But it's not about stifling innovation, right, It's about creating
Speaker 2: a unified, repeatable, and data friendly framework like.
Speaker 1: A golden pipeline, a curated set of tools that work together.
Speaker 2: Exactly that streamline collaboration, less operational overhead. The book calls
Speaker 2: it the anti tool tag. Stronger security, better compliance.
Speaker 1: And crucially getting ready for AI.
Speaker 2: That's the big payoff. You provide that uniform structured data
Speaker 2: that these autonomous AI agents need to function effectively. Vorrel
Speaker 2: puts it bluntly. Without standardization, AI driven automation will never
Speaker 2: reach its full potential.
Speaker 1: So standardization is the blueprint. What about the foundation? The
Speaker 1: book talks a lot about Cloud Native. Why is that
Speaker 1: so important here?
Speaker 2: Because Cloud native architecture is basically designed for this kind
Speaker 2: of dynamic, automated world from the get go. Ah, Well,
Speaker 2: you're using things like micro services, containers think Docker, dynamic
Speaker 2: orchestration like Kubernetes, infrastructure as code with tools like Terraform.
Speaker 1: Okay.
Speaker 2: All that enables systems to scale automatically, to self heal
Speaker 2: when things go wrong, to spin up temporary environments easily.
Speaker 2: It's the technical underpinning you need for AI agents to
Speaker 2: really manage things effectively.
Speaker 1: Got it. So it provides the flexibility and resilience AI.
Speaker 2: Needs exactly, and that connects directly to needing data centric
Speaker 2: architectures and observes.
Speaker 1: Meaning getting all that data in one place, logs, metrics, traces.
Speaker 2: Yes, and tagging it consistently so you actually have deep visibility,
Speaker 2: real time feedback loops. That's the fuel for the AI,
Speaker 2: and tools.
Speaker 1: Like OPS are come in here helping aggregate all that right.
Speaker 2: The book mentions ops A specifically because it provides platform
Speaker 2: agnostic analytics. It integrates with like over eighty different nosec
Speaker 2: ops tools, wow, eighty plus Yeah, pulling all that data
Speaker 2: into unified dashboards so leaders can actually see things like
Speaker 2: deployment frequency, MTTR lead time, regardless of the specific tools.
Speaker 1: Underneath, seeing the whole forest, not just the trees. Like
Speaker 1: you said, precisely, that Retail Giant case study really showed
Speaker 1: the impact, didn't it. Monthly to daily deploys outages way down.
Speaker 2: And their observability shot up. That immediately paved the way
Speaker 2: for them to start piloting AI for anomaly detection lay
Speaker 2: the foundation see the benefits quickly.
Speaker 1: So if we're aiming for this autonomous future, what does
Speaker 1: GOOD have actually look like? Is there a reference architecture?
Speaker 2: Yeah, the book outlines what GOOD looks like. It's a
Speaker 2: unified architecture covering everything from requirements all the way to
Speaker 2: monitoring and production.
Speaker 1: And key features are.
Speaker 2: Self service for developers, self healing capabilities, security embedded right
Speaker 2: from the start, not bolted on later, and.
Speaker 1: The practical way to get there. That paved road concept exactly.
Speaker 2: Part I offers this practical paved road. It's about deliberately
Speaker 2: choosing a lean stack, often centered around something like gethub
Speaker 2: Enterprise Cloud maybe with actions for the pipelines, get Hub,
Speaker 2: Advanced Security gaks for shifting security left okay, OPS area
Speaker 2: for the analytics and visibility layer we just talked about,
Speaker 2: and then standardizing the developer workspace, maybe on something like vs.
Speaker 1: Code, so collapsing maybe dozens of tools down to a core, cohesive.
Speaker 2: Set right, creating that clean telemetry foundation that you need
Speaker 2: for autonomous new OPS. It's about intentional simplicity driving complex automation.
Speaker 1: Okay, sounds good rate in theory, but how do you
Speaker 1: actually do it? People listening might be thinking, my setup
Speaker 1: is chaos. Where do I even start?
Speaker 2: Yeah, it can feel overwhelming. The book provides an implementation
Speaker 2: guidance playbook which is pretty helpful.
Speaker 1: What are the steps.
Speaker 2: It starts with forming an AI gild Tiger team, a
Speaker 2: dedicated group to lead this. Then baseline your current tool sprawl.
Speaker 2: You need to know how bad it.
Speaker 1: Is first, Okay, measure the mess.
Speaker 2: Measure the mess. Then importantly freeze new tool purchases for
Speaker 2: a while. Stop adding to the problem makes sense. Publish
Speaker 2: clear standards for co depositories, tagging things like that. Then
Speaker 2: you systematically migrate teams and projects onto the paved road
Speaker 2: and track progress absolutely, track ey KPIs, lead time, MTTR,
Speaker 2: toolcount reduction, even licensed cost savings, and surface all of
Speaker 2: that in a tool like opserra so everyone can see
Speaker 2: the progress. It's methodical.
Speaker 1: Generative AI transforms the software development life cycle.
Speaker 2: Okay, so we've built this solid, standardized runaway. The foundation
Speaker 2: is there. Now the book really takes off into the
Speaker 2: revolutionary part generative AI, not just helping operations but actually
Speaker 2: changing how we write the code itself.
Speaker 1: Right, This is where it gets really exciting the rise
Speaker 1: of AI coding assistance like Gethub. Copilot is just a
Speaker 1: massive game changer.
Speaker 2: More than just autocomplete right, oh, way more.
Speaker 1: The book calls it going from autocomplete to intelligent pair programming.
Speaker 1: It works directly inside VS code, deeply integrated with GitHub.
Speaker 2: And the productivity james are real.
Speaker 1: They seem to be. We're talking ten to thirty percent
Speaker 1: boosts generally, but some studies show developers finishing tasks thirty
Speaker 1: even up to forty seven percent faster. Wow, that's significant,
Speaker 1: it really is. Think about the example of adding that
Speaker 1: O off to middleware.
Speaker 2: Yeah, thirty three percent faster with copilot. Yeah, because it
Speaker 2: suggested code helped with unit.
Speaker 1: Tests exactly, instant code suggestions, scaffolding for tests. It saves
Speaker 1: a ton of time, especially on repetitive or boilerplate tasks.
Speaker 2: But it's not perfect, right, There must be pitfalls.
Speaker 1: Oh definitely. The book is clear about the challenges AI
Speaker 1: hallucinations where it just makes stuff up. Uh, security risks
Speaker 1: if it suggests vulnerable code, and just the danger of
Speaker 1: developers becoming overreliant not thinking critically.
Speaker 2: So how do you manage that? You can't just let
Speaker 2: the AI run wild?
Speaker 1: No way, Yeah, best practices are crucial, always human the
Speaker 1: loop reviews. People need to check the AI's work. Okay,
Speaker 1: you need to write clear prompts to guide the AI,
Speaker 1: and you absolutely integrate the AI generated code and tests
Speaker 1: into your existing CI pipelines. Security tools still need to.
Speaker 2: Scan everything, so it's augmentation not replacement.
Speaker 1: Augmentation not application that's the key.
Speaker 2: Okay, so unit tests. But let's talk about the really
Speaker 2: thorny stuff, functional and integration testing, especially with micro services,
Speaker 2: that's always been a huge bottleneck.
Speaker 1: Huge, and this is where AI gets really interesting again.
Speaker 1: Tools like functionize are mentioned.
Speaker 2: Functionize what do they do differently?
Speaker 1: They use AI to automatically generate functional and integration tests
Speaker 1: just by watching how users actually interact with the application.
Speaker 2: Okay, observing user flows.
Speaker 1: But here's the really critical part. They can also self.
Speaker 2: Heal the tests self heal, meaning.
Speaker 1: Meaning if a minor UI element changes or a button
Speaker 1: moves slightly, things that would normally break a traditional test script,
Speaker 1: the AI adapts the test script automatically.
Speaker 2: WHOA Okay, that tackles the massive test maintenance burden exactly.
Speaker 1: That's often where teams spend most of their testing effort
Speaker 1: just fixing broken tests.
Speaker 2: The e commerce case study nailed this right. Sixty percent
Speaker 2: reduction in test maintenance.
Speaker 1: Yeah, a sixty percent drop, and they got better coverage
Speaker 1: on critical paths like checkout. That directly speeds up feature
Speaker 1: delivery because testing isn't such a drag anymore.
Speaker 2: And looking even further ahead, the book mentions open AI operator.
Speaker 1: Yeah, that's more experimental, but fascinating. It's an AI agent
Speaker 1: that interacts with an app like a human would, literally
Speaker 1: using a built in browser, so it looks at the page,
Speaker 1: It interprets the page, visually, understands high level concepts. It
Speaker 1: doesn't rely on fragile things like HTMs locators or specific
Speaker 1: API end points, so it can adapt to changes much
Speaker 1: more like a person would.
Speaker 2: That's kind of mind blowing. It really feels like a
Speaker 2: step towards true intelligent automation.
Speaker 1: It does. It's early days, but the potential is huge.
Speaker 2: Okay, so AI is helping write code, helping test code.
Speaker 2: What about the infrastructure it all runs on? Can AI
Speaker 2: manage that too?
Speaker 1: Yes? Absolutely, generative AI is moving into infrastructure as code
Speaker 1: iac and also data.
Speaker 2: Provisioning, so it can write my terraform for me.
Speaker 1: Pretty much. You give it a high level description. I
Speaker 1: need a standard web server. Setup with these specs, and
Speaker 1: it can generate the terraform or claudformation scripts. The book
Speaker 1: suggests this can cut INFRA provisioning time by over sixty percent.
Speaker 2: Sixty percent that's huge for standing up new environments.
Speaker 1: It is, but it's not just about the initial setup, right.
Speaker 2: What about keeping things running smoothly preventing those annoying configured
Speaker 2: drifts or scaling issues.
Speaker 1: That's the next level. AI enables predictive scaling. It analyzes
Speaker 1: past usage pa terns and scales resources before the spy kits,
Speaker 1: not after.
Speaker 2: Proactive not reactive.
Speaker 1: Nice and drift remediation. The AI constantly watches the live environment,
Speaker 1: compares it to the IEC definition.
Speaker 2: And if something's changed someone tweaked a setting manually.
Speaker 1: It can either flag it for review or even automatically
Speaker 1: correct it to bring it back in line with the
Speaker 1: code definition. Viral highlights how this ensures compliance without constant
Speaker 1: manual checks. It's like having an automated compliance officer.
Speaker 2: That fintech startup example sounded great. Faster environment spin up
Speaker 2: and better PCI compliance through automated data masking.
Speaker 1: Right. It freeze up the ops team from that reactive
Speaker 1: firefighting to think more strategically.
Speaker 2: Which brings us to this stay in the flow idea.
Speaker 2: What's that about.
Speaker 1: It's about bringing these capabilities directly into the developers or
Speaker 1: operator's main workspace, usually their ide like vs code.
Speaker 2: So instead of switching tools, you just talk to the
Speaker 2: AI essentially.
Speaker 1: Yeah. Using natural language processing and LP, you could type
Speaker 1: something like create a masked copy of production data for
Speaker 1: this staging environment, okay, or generate terraform for a new
Speaker 1: micro service based on our standard template. The AI figures
Speaker 1: it out, proposes the scripts or actions, and.
Speaker 2: You review it right there, maybe in a pool request.
Speaker 1: Exactly, all without leaving your development context. It removes that friction,
Speaker 1: keeps you focused. Okay.
Speaker 2: That sounds incredibly powerful. So finally, the CICD pipeline itself
Speaker 2: the heart of DevOps. How does AI make the pipeline smarter?
Speaker 1: Several ways? One big one is optimizing the pipeline run itself.
Speaker 1: AI can do intelligent test.
Speaker 2: Selection, meaning it doesn't just run all the tests every
Speaker 2: single time, right.
Speaker 1: It analyzes the specific code changes in a commit and
Speaker 1: figures out which subset of tests are actually relevant to run.
Speaker 2: That could save a lot of time, especially on big
Speaker 2: test suites.
Speaker 1: Huge amounts that e commerce company, example, they cut their
Speaker 1: forty minute pipeline runs down to twenty minutes just with this.
Speaker 2: Wow half the time. That massively speeds up the feedback
Speaker 2: loop for developopers.
Speaker 1: Instantly they know much faster if their change broke something.
Speaker 1: And when feedback is that fast, developers feel more confident
Speaker 1: making smaller, more frequent changes.
Speaker 2: It changes the whole dynamic.
Speaker 1: It really does. And it goes further with predictive failure
Speaker 1: analysis and remediation.
Speaker 2: Okay, what's that.
Speaker 1: The AI is watching the pipeline run in real time
Speaker 1: logs metrics. It can spot anomalies that suggest a test
Speaker 1: might be flaky or a build environment is misconfigured, and
Speaker 1: then it might automatically retry a step or even apply
Speaker 1: a known fix. It can also get smarter about deployments.
Speaker 1: How So, based on the risk profile of the code change,
Speaker 1: how big it is, what areas it touches, the AI
Speaker 1: could dynamically choose the best deployment strategy, maybe a slow
Speaker 1: canary release for a risky change, or a faster rolling
Speaker 1: update for something simple.
Speaker 2: And it watches the deployment, watches.
Speaker 1: The real time telemetry. If it sees aerror rate spike
Speaker 1: or performance tank. It can trigger an automatic rollback.
Speaker 2: So the pipeline becomes truly adaptive, not just the dumb
Speaker 2: script runner.
Speaker 1: Exactly intelligent, adaptive self healing.
Speaker 2: And this also ties into stay in the flow.
Speaker 1: Yes, a developer could be in their ID and type
Speaker 1: deploy this branch to Canary with ten percent traffic, watch
Speaker 1: for anomalies.
Speaker 2: And AI just handles it, triggers the right pipeline monitors,
Speaker 2: it gives feedback.
Speaker 1: That's the vision. The AI interprets the intent, orchestrates the
Speaker 1: actions and reports back, maybe even suggesting a rollback if needed.
Speaker 1: It's this frictionless pipeline guided by human intent but executed
Speaker 1: largely by AI. That's the core of NUOPS. According to
Speaker 1: the book.
Speaker 2: Wow, that final section in part two, Catalyst to Autonomy,
Speaker 2: really paints a picture of it all coming together.
Speaker 1: It does an AI first paved road, copilot and VS
Speaker 1: code helping write the code functionize I as creating and
Speaker 1: healing the tests, AI agents managing the infrastructure via.
Speaker 2: IAC and all the data feeding back.
Speaker 1: Every suggestion, every healed test, every drift correction, tagged and
Speaker 1: streamed into that unified analytics platform like opsrac iktives get
Speaker 1: real time visibility into velocity, quality.
Speaker 2: Cost savings, and security gets pushed even further left.
Speaker 1: Right to the keyboard. Essentially, issues blocked by copilot or
Speaker 1: caught by automated security in the pipeline ideally never even
Speaker 1: make it close to production. That's a massive security posture
Speaker 1: improvement outro.
Speaker 2: What an incredible journey really from that fragmented, often frustrating
Speaker 2: world of traditional DevOps to this potential future driven by standardization, cloud,
Speaker 2: native thinking, and wow, generative AI creating real autonomy.
Speaker 1: It really feels like we're on the cusp of transforming
Speaker 1: all that repetitive toil and software delivery into something much
Speaker 1: more intelligent, almost self managing.
Speaker 2: Yeah. But the key takeaway, it seems, isn't that humans
Speaker 2: become obsolete?
Speaker 1: Right, Not at all. The book really emphasizes this as
Speaker 1: AI takes on the drudgery the human role shifts. It
Speaker 1: elevates to what to higher level design, to strategy, to
Speaker 1: focusing on the next innovation, not just the current lights on.
Speaker 1: It's about freeing up human potential, and of course there's
Speaker 1: always more to learn as this tech.
Speaker 2: Of all so fast, absolutely so for everyone listening, what
Speaker 2: does this all mean for your role? How can you
Speaker 2: start thinking about embedding AI, making it like muscle memory
Speaker 2: in your team or org.
Speaker 1: How do you get from that burnout cycle to maybe
Speaker 1: build chip and wonder, wonder what's next exactly.
Speaker 2: We really encourage you to explore these ideas, maybe pick
Speaker 2: up Vorl's book and just identify one or two places
Speaker 2: where AI could start elevating your daily work.
Speaker 1: Start small, build momentum.
Speaker 2: Yeah, well, thank you so much for joining us on
Speaker 2: this deep dive into the future of software development.
Speaker 1: My pleasure.
Speaker 2: We hope this exploration empowers you, gives you some ideas,
Speaker 2: and helps you pave your own road towards a more autonomous, efficient,
Speaker 2: and ultimately more innovative future.